Выбор фреймворка и подхода к автоматизации тестирования

Доброго времени суток. Надеюсь что сможете подсказать и навести на путь истинный вы выборе подхода и фрейморка.

Приложение (web) дает пользователям возможность оформить билеты из пункта А в пункт Б, будь то самолёт, автобус или железная дорога. Приложение очень масштабное, есть десятки провайдеров и сотни перевозчиков, тонны бизнес схем, логики, стран покрытия и к сожалению полностью отсутствует автоматизация тестирования, по крайнее мерее в том сегменте и проекте где участвую я.

У меня есть небольшой опыт написание фреймворка используя java + webdriver + pagefactory, так как это было на добровольных началах вышел сплошной спагети-код. Сейчас же к этому хотелось бы подойти более осмыслено и ответственно, смотрел в сторону jbehave-подобных решений, но возникает много вопросов:

  1. как в таких сценариях таскать кучу данных с первого шага и до конца теста, насколько это правильно и не противоречит ли вообще BDD подходу написания сценариев, так как в каждом сценарии надо проверять не только существование какого-то предложения из пункта А в пункт Б и возможность оформить заказ, а и правильную цену, которая зависит от кучи параметров, большинство из них приходят по soap, какие-то % и курсы валют из БД, ещё что-то в виде скидок и купонов формируется по всему пути формирования заказа.
  2. как можно имплиментировать такую ситуация как отсутствие предложений из какого-то забитого пункта А в забитый пункт Б на конкретную дату из-за того что рейс там раз в 3 дня, при этом бы не хотелось чтобы тест падал, а ходил бы по диапазону 1-3 дня, всю эту логику оформлять под step definitions и опять же не будет ли это костылями и не правильным использованием подхода?
  3. кроме UI есть ещё и вэбсервисы, с помощью javax.xml.soap.* я уже начеркал пару тестов, но вот как раз в
    вебсервисах проблема таскания значения полученного из одного soapAction в другое становится совсем боком или это всё реализуемо используя BDD подход

Подскажите, возможно я вообще не в ту сторону смотрю и стоит задать себе какие-то другие вопросы чтобы построить фреймворк для подобного приложения?

Советую вот такое видео про эффективное тестирование: http://sqadays.com/ru/talk/25882

Прежде всего, выбор фреймворка не особо играет роль. Тут процесс надо ставить.

4 лайка

Спасибо за ссылку. Я уже некоторое время подозревал, что автоматизация тестов при помощи эмуляции пользователя, это на самом деле и не автоматизация по большому счету. Это все равно, что на автомобильном конвейере у робота было бы пять пальцев, и он бы брал отвертку, вставлял в нее насадку, и придерживая мизинцем гайку, закручивал болт. Это смешно.

У меня как раз такая ситуация, я, без опыта qa, попал в компанию тестировать веб-проект. И политика как раз заключается в том, чтобы тестировщик делал это с точки зрения черного ящика… В результате я сейчас потратил кучу времени на то, чтобы WebDriver фреймворк корректно работал с UI элементами DevEx. А на прошлой неделе я узнал, что на второе полугодие запланирован новый дизайн, без DevEx.

А ведь логично было бы иметь один-два теста в бот-стиле, которые бы проверяли корректность работы интерфейса, а тест логики был бы уже совсем другой песней.

В общем, благодаря этому докладу, надеюсь, получится донести свои мысли до руководителей.

Еще раз спасибо.

2 лайка

Рад, если принёс пользу!
Про робота с пятью пальцами классная аналогия!

Очень знакомая ситуация. Так же пришел в компанию совсем без опыта QA. На тот момент у нас не было ни одного авто-теста, все покрывали руками нескольких человек, которые не задумывались о движении куда-либо в сторону от привычных практик. Мне ручное тестирование оч быстро надоело и показало свою неэффективость во многих аспектах. Стал присматриваться к автоматизации, смотреть что и как можно заавтоматизировать у себя, и понял, что дьявол кроется буквально за каждым углом) Огромное количество фреймворков, библиотек, подходов и тд и тп просто взрывало мой неокрепший мозг. Было реально трудно, так как заинтересованность что-то менять на проекте отсутствовала или находилаль очень низко. Соответственно желание помогать мне отсутствовало тоже.

Сейчас ситуация немного изменилась, так как профит от автоматизации стал заметен, манки-тестеров разогнали, но мои проблемы как были, так и остались: посоветоваться особо не с кем, я часто борюсь с проблемами, которые можно решить оперативно и без особых затрат, будь рядом кто-то опытнее + времени под автоматизацию выделяется мало и тд. Но, как говорится, Per aspera ad astra!

Кстати пользуюсь отличным фреймворком @asolntsev http://selenide.org/ и во многом разделяю его взгляды на подходы к тестированию.

2 лайка

Присоединяюсь к @asolntsev, что нужно в первую очередь наладить процессы разработки, написать тесты для низких уровнях, а только потом уже переходить к высокоуровневым тестам.

Но все же по вопросам:

Тут надо создавать более сложные data объекты с правильной абстракцией и дополнительной функциональностью чтобы конвертировать или легко вычитывать нужные данные из data объектов в нужных местах. Чтобы такое реализовать, надо задуматься над их разработкой ровно столько же как и над разработкой своего небольшого фреймворка. В общем, книга по архитектуре и дизайну тут поможет. В идеале, в самих тестах это будет просто объект, который передается между шагами и будет сохранять все нужные данные и состояния

Для каждого случая нужно понять правила, которые действуют для маршрутов, запрограммировать эти правила один раз и вычислять их динамически во время прохождения теста, а не хардкодить в самом тесте.

Во-первых, надо разделять такие тесты, как уже было сказано в докладе @asolntsev. Чем больше будет разделение и градация тестов, тем лучше. Ну и если будете использовать data объекты, то тогда к ним просто надо будет написать какие-то конверторы, которые из data объекта будет формировать нужную для вас структуру.

1 лайк

Спасибо за информацию, буду разбираться как бы процесс построить.

Андрей, подскажите, я вот глянул доклад ваш, для меня это конечно разрыв шаблона, отказ от длинных цепочек и тд, было очень интересно и познавательно, у меня остался вопрос, если отказываться от длинных цепочек как достигнуть нужных прекондишинов на примере инет.магазина:
залогиниться(доступ к кабинету)
выбрать товар
добавить в корзину
оформить заказ и оплатить
проверить что корзина пуста и статус у заказа изменился

Это длинная цепочка, мне действительно не интересны куча шагов “before”, а хочу допустим только проверить функционал корзины, вы перед началом прогонки всех тестов на моменте сетапа БД выполняете кучу sql скриптом для наполнения нужными данными базы? А уже потом мелкими атомарными тестами проходитесь по функционалу?
Или как достигается отказ от длинных тестов на 1-3 минуты.

1 лайк

Очень рад это слышать!

Да, мы перед каждым тестом подготавливаем базу в нужном состоянии. Да, если очень грубо, запускаем кучу SQL. Если вдаваться в подробности, то не прошиваем эти SQL прямо в тестах, а используем инструменты, позволяющие хранить и запускать скрипты централизованно. Например, LiquiBase. В этом проекте есть пример подготовки базы и тестовых данных с мощью LiquiBase: GitHub - selenide-examples/hangman: The hangman game written in Java

Попахивает чистым пиаром Selenide. Но нужно исходить из фразы “пришел на проект без опыта QA”. Пришел и наворотил дел, а в таком случае хоть ты космолет используй ничего хорошего не выйдет

:slight_smile: Пиар нужен айбиэмовским и оракловским тульям за тысячи долларов, а бесплатным опен-сорсным проектам пиар нафиг не нужен.

Так я в итоге не понял, какой же ваш совет? Изначально прозвучала просьба “подсказать и навести на путь истинный”, затем был вопрос “как делается сетап БД”. Ваш ответ - “ничего хорошего не выйдет”?

1 лайк

Пан @polusok уже ответил что делать дальше.

У меня тоже тесты состоят из длинных цепочек :pensive: Причем очень длинных.
Проблема в том, что я их даже разбить не могу, т.к. сайт очень сложный и важно проверять именно цепочку. И через базу не все создашь… Базу использую насколько возможно.

  • юнит тестов на проекте практически нет, и вряд ли когда-нибудь будут.
    В общем, печаль.
    Буду думать, как цепочки разбивать…

Помню название одной книги: “Алгоритмы + структуры данных = программы”. Для получения рабочей программы, а в нашем случае - тестов, можно усложнять оба слагаемых либо только одно. Насколько я понял, Андрей по сути предлагает сильное упрощение слагаемого “алгоритм” за счет усложнения слагаемого “структуры данных”. Прогон тестов проходит быстро, ок. А сколько занимает подготовка данных? Это ведь теперь получается далеко не тривиальное действие.

Не совсем так. Сложность алгоритма тут не при чём.
Суть в том, что в тесте вообще не должно быть никакого алгоритма.
Тест должен:

  1. Подготовить предусловия
  2. Сделать действие
  3. Проверить результат

И вот тут на шаге 2 нет места для условий (т.е. для алгоритма).
Если тестовый сценарий подразумевает, что надо кликнуть зелёную кнопку, то тест всегда должен кликать зелёную кнопку. Независимо ни от чего.

А условия в тестах (т.е. алгоритмы) появляются тогда, когда люди не умеют готовить шаг 1.
Они не подготавливают предусловия, а берут, скажем, существующую базу данных и пытаются как-то угадать, подходит ли она под их сценарий. Вот там и начинаются ветвления.

Андрей, по поводу алгоритма толковый словарь и википедия вас не поддерживают:

Алгори́тм — набор инструкций, описывающих порядок действий исполнителя для достижения некоторого результата

Т.е. тест априори содержит в себе некий алгоритм :wink:

ок, я имел в виду алгоритм без ветвлений. Можно сказать, “сценарий”.