Нет. В Page Object'ах проводятся структурные проверки связанные с интерфейсом и представлениями данных. В Action классах проводятся проверки бизнес логики.
Для примера. Проверка отображения профиля пользователя:
— пэйдж объект реализует метод гетЮзерПрофайл. В этом методе мы предполагаем что уже находимся на странице ЮзерПрофайл. Тут мы проверяем что все поля на странице показаны и имеют требуемый формат. Например — телефон это телефон, а ЮзерЛогин не пустой. После этого собираем данные в класс ЮзерПрофайлПейджИнфо и возвращаем в Action
— Action класс делает бизнес проверку — например сравнивает данные полученные со страницы с данными, которые должны быть такими, как задано в «тестовой сцене»
Это позволяет нам разделить логику и править только конкретный Пэйдж если изменился только дизайн и наоборот. А еще это в перспективе поможет нам легко заменить пэйдж объект на рест-api объект
Какие тесты надо править «вычисляет» группа Функционального тестирования, которая правит тест-спецификации и скидывает нам задачи в жиру как «Доработка» «немедленно» или «к дате». Далее мы вычисляем что надо править:
1) сравниваем по пунктам тест-спецификации, какие шаги теста изменились\добавились\удалились
2) мы помним, что каждый шаг теста = конкретный метод в классе типа Action как SomeAction.someStep(someBusinessModel...). Поэтому мы правим конкретные методы + при необходимости конкретные SomePage(1..*), которые используются в данном методе.
3) При необходимости правим бизнес-модель которая определяет тестовую сцену, как конкретные классы, которые используются в SomeAction.someStep(someBusinessModel...)
Такая схема поддерживается 1) запретом горизонтальных депенденси между уровнями иерархии, 2) независимостью классов Action и Page от генерации тестовой сцены.
Таким образом мы всегда знаем точки изменений и какой уровень изменять
Поддержка бизнес логики занимает в целом не много времени, она проста и сводится к очечным изменениям. Хотя иногда приходится и переписывать все ибо поменялось все -)
В целом, как было приведено в первой части, мы укладываемся в показатель 2-8 часов на каждый тест-сценарий (средняя статистика непосредственно кодера — 5,12 часа на тест) в зависимости от:
1) это первый тест для подсистемы — значит надо делать классы Page
2) как много шагов в тесте — типовой размер от 15 до 20 условных шагов
3) необходимо ли работать с эксель файлами, лезть в базы и тп
4) есть ли новые элементы — например мы потратили почти неделю пока отладили работу с яндекс-картой
Разработка нового теста практически не требует изменений в текущих тестах. Процесс устроен так:
1) создать новую Page или добавить в существующую новые элементы + добавить методы ввода-данных и проверки разметки. Мы стараемся не делать универсальные методы, а просто добавляем новые
2) создать новый Action для нового теста и добавить шаги вызова Page методов и бизнес проверки. У нас Action реализует всегда только один сценарий, даже если есть типа похожий
3) создать новый Test класс и собрать в нем требуемую цепочку вызовов Action классов
У меня еще будет опубликована третья часть с шаблонами наших классов и описанием всех TestRule которые мы используем
Жесткая привязка по юзерам есть. Кроме того мы ограничиваем именно операцию логина (10 потоков), а не все сессии (60 потоков). Это решение было максимально быстрым и заняло час времени.
Это именно то что нам было нужно. По бизнесу. Тесты полной системы от браузера до реальной базы.
Согласен. Дорого. Медленно. Можно раздельно тестить UI на фронтенд моках, можно тестить систему прямо через паблик api. Но задача была автоматизировать именно полные тесты от браузера до базы данных на полной копии продуктива.
В целом все что вы говорите совершенно верно. И нам именно так и говорили. Но тестить руками — еще дороже, еще медленней, еще не надежнее.
1) Отслеживание тенденций по автотестам в целом проводится через ELK стек, для чего в stdout мы логируем результат и тайминг каждого теста в json формате. Далее это уходит в Бамбу, где читается Logstash и далее уже средствами ELK. Эта фича используется мной как разработчиком для отслеживания деградации производительности. Также дополнительно мы по этому каналу сбрасываем все что требует статистического анализа. Для тестеров данная информация оказалась бесполезной.
2) И по разбору ошибок — не владею такой информацией, так как это зона работы группы Функционального тестирования. По интеграции — мы делали концепт по автогенерации тасков в Жиру прям по результатам тестов (для этого надо просто добавить новую TestRule реализацию). Но группа тестирования решила, что им нужно больше контроля над процессом.
3) для проверки соответствия выгружаемых ПФ шаблонам — не понял вопроса. Что такое ПФ?
А ведь правильно сказали — ответственность во главе угла! Поэтому я за полирепозитории разделенные по ответственности. А иначе получается как правильно отметили — коллективная ответственность, которая быстро скатывается на коллективную безответственность, непрерывные мерж конфликты доходящие до мордобоя (и это не метафора), и потеря управляемости системы через отсутствие спецификаций ее работы. А зачем их писать, код посмотри да? Ну и вишенкой на торте постоянные разборки в стиле коммунальной квартиры кто чей API поломал. ИМХО все что деплоится отдельными артефактами и взаимодействует через «общие» протоколы (REST, очереди, журналы) должно жить в отдельных репо. Единственное где я вижу смысл монорепозитария — это в старом добром JEE REJB
мы не можем себе позволить делать для каждого реквеста полный регресс ибо 1500 тестов занимают 4 часа и съедают четыре сервера 12CPU + 24Gb
На полный регресс приходит сборка которая прошла все стадии юнит, компонентного и интеграционного тестирования
Я даже не заметил как ввел вас в заблуждение -)
1. Конечно есть. Но это не в моей зоне ответственности и не тема этой статьи. Я тут как автоматизатор наиболее трудоемкой и дорогой части в тестировании.
2) Здесь вы сами решаете где остановить процесс непрерывной доставки ИМХО. Наше решение можно встроить в процесс и оно встроено в ограниченной части, но есть особенность — 1500 тестов мы можем позволить себе только в 60 потоков и занимает это около 4х часов. Мы приняли осознано такое решение
В целом эти вопросы выходят за скоп этой статьи, которая описывает пример автоматизации лишь одного конкретного шага тестирования.
Давайте посмотрим по пунктам:
1. В пирамиде тестирования проект Автотесты отвечает за "Системное тестирование". Таким образом — это высшая или последняя стадия тестирования перед выдачей в продуктив.
2. Я считаю что в целом вполне возможна и более того, только автоматизация системного тестирования может реально дать нам всем убежденность что продукт рабочий в целом и обеспечить ту самую непрерывную доставку. В нашем проекте Автотесты позволяют сделать непрерывную доставку на стенд системного тестирования как конечную точку автопоставки. Так что у нас «регрешн» проходит по рассписанию. НО!!! ограниченные объемы тестов сейчас активно используются в пайплайнах для QA скрининга в процессе разработки. ИМХО если у вас ограниченное количество бизнес сценариев или вы можете их «уложить» в 15-30 минут — это хорошый старт, чтобы внедрить системное тестирование в пайплайн.
3. Если вопрос касается исправления багов в системе, которые показали Автотесты, то на этот вопрос я не отвечу ибо NDA -)
Отвечу сразу по пунктам
Хранение локаторов — каким-то отдельным способом мы их не храним. Сделано достаточно просто — класс SomeConcretePage инициализирует веб-элементы как атрибуты класса c прямым указанием локаторов. Группы типовых веб-элементов (например — пагинатор или модалки) оформляются как отдельный класс который хранится в общем пакете (мы их называем — виджеты) и также инициализируются в SomeConcretePage. Я рассматривал идею сделать библиотеку веб-страниц и элементов через Spring @Configuration & Bean Annotations, но особых преимуществ не увидели. А вот стоимость разработки со спрингом — выше.
Подготовка тестовых данных — мы смогли минимизировать этот процесс. Фактически для любого теста нам нужен только существующий пользователь и существующие в системе НСИ данные, например, почтовые адреса до улицы. Далее тест самостоятельно через средства системы создает все требуемые промежуточные данные. Например для теста получения заказа тест последовательно создает Гражданина, добавляет ему адрес доставки, логинится от его имени, набирает заказ, апрувит его и так далее… Это имеет свои недостатки, но в целом этот подход себя оправдал.
Решение этих вопросов не входило в скоп нашего проекта. Более того, автотесты которые мы делали являются отдельным приложением, которое ничего не знает о коде и организации самой системы. Все взаимодействие только через браузер. Мы, как группа автоматизации UI E2E тестов также не оценивали ни покрытие, ни полноту. Эта часть работы относится к компетенции группы функционального тестирования, которая является для нас, группы автоматизации, внутренним заказчиком.
Это как раз одна из фишек нашей реализации.
Все сделано так чтобы в этом случае изменить только два объекта — спецификацию конкретного тест-кейса «Логин» и конкретного класса Login + LoginPage, которые его реализуют. Попробую описать чуть подробнее чем это есть в подразделе «Спецификация задач на разработку». На примере…
Мы автоматизируем кейс «Подтверждение получения товара» со следующими шагами:
1. Залогиниться
2. Создать заказ
3. Подтвердить получение заказа
В Testlink создается сценарий «Подтверждение получения товара» по следующему шаблону:
Предусловие 1. Выполнить Логин с пользователем типа Х
Предусловие 2. Выполнить «Создать заказ»
Шаги основного кейса «Подтверждение получения товара»…
Таким образом для конкретного теста мы детализируем только шаги уникальные для этого теста. Например, тест «Отменить заказ» превращается в тестлинке в:
Предусловие 1. Выполнить Логин с пользователем типа Х
Предусловие 2. Выполнить «Создать заказ»
Шаги основного кейса «Отменить заказ»…
Ну а далее легко видеть, что при изменении сценария Логин, нам надо поправить только сценарий Логин.
В коде реализован аналогичный подход: Тест-Класс включает множество Сценарий-Классов, которые включают множество Активности-Методов. Таким образом нам надо будет поправить только один класс Login+LoginPage. Об этом написано во второй части, которая будет опубликована скоро.
Во второй части это будет описано более подробно, хотя эти публикации относятся в первую очередь к вопросам организации работ и кода. ИМХО информации о том как кодировать разные функции достаточно, а вот как запустить машину проекта по конвеерной разработке автотестов я в сети не встречал. По технике…
Интеграция с ELK операция простая — мы просто пишем в Logger форматированную JSON строку, которая попадает в stdout, который перехватывает Bamboo и далее читает Logstash.
Что касается сравнения файлов то тут мы просто создаем файлы сами или парсим то что получили из системы любыми подходящими фреймворками. Технической проблемой было как файл к себе забрать… и об этом будет написано подробно во второй части
Для генерации и контроля эксель файлов — apache.poi.xssf.usermodel.XSSFWorkbook
Для примера. Проверка отображения профиля пользователя:
— пэйдж объект реализует метод гетЮзерПрофайл. В этом методе мы предполагаем что уже находимся на странице ЮзерПрофайл. Тут мы проверяем что все поля на странице показаны и имеют требуемый формат. Например — телефон это телефон, а ЮзерЛогин не пустой. После этого собираем данные в класс ЮзерПрофайлПейджИнфо и возвращаем в Action
— Action класс делает бизнес проверку — например сравнивает данные полученные со страницы с данными, которые должны быть такими, как задано в «тестовой сцене»
Это позволяет нам разделить логику и править только конкретный Пэйдж если изменился только дизайн и наоборот. А еще это в перспективе поможет нам легко заменить пэйдж объект на рест-api объект
1) сравниваем по пунктам тест-спецификации, какие шаги теста изменились\добавились\удалились
2) мы помним, что каждый шаг теста = конкретный метод в классе типа Action как SomeAction.someStep(someBusinessModel...). Поэтому мы правим конкретные методы + при необходимости конкретные SomePage(1..*), которые используются в данном методе.
3) При необходимости правим бизнес-модель которая определяет тестовую сцену, как конкретные классы, которые используются в SomeAction.someStep(someBusinessModel...)
Такая схема поддерживается 1) запретом горизонтальных депенденси между уровнями иерархии, 2) независимостью классов Action и Page от генерации тестовой сцены.
Таким образом мы всегда знаем точки изменений и какой уровень изменять
Поддержка бизнес логики занимает в целом не много времени, она проста и сводится к очечным изменениям. Хотя иногда приходится и переписывать все ибо поменялось все -)
1) это первый тест для подсистемы — значит надо делать классы Page
2) как много шагов в тесте — типовой размер от 15 до 20 условных шагов
3) необходимо ли работать с эксель файлами, лезть в базы и тп
4) есть ли новые элементы — например мы потратили почти неделю пока отладили работу с яндекс-картой
Разработка нового теста практически не требует изменений в текущих тестах. Процесс устроен так:
1) создать новую Page или добавить в существующую новые элементы + добавить методы ввода-данных и проверки разметки. Мы стараемся не делать универсальные методы, а просто добавляем новые
2) создать новый Action для нового теста и добавить шаги вызова Page методов и бизнес проверки. У нас Action реализует всегда только один сценарий, даже если есть типа похожий
3) создать новый Test класс и собрать в нем требуемую цепочку вызовов Action классов
У меня еще будет опубликована третья часть с шаблонами наших классов и описанием всех TestRule которые мы используем
Это именно то что нам было нужно. По бизнесу. Тесты полной системы от браузера до реальной базы.
Согласен. Дорого. Медленно. Можно раздельно тестить UI на фронтенд моках, можно тестить систему прямо через паблик api. Но задача была автоматизировать именно полные тесты от браузера до базы данных на полной копии продуктива.
В целом все что вы говорите совершенно верно. И нам именно так и говорили. Но тестить руками — еще дороже, еще медленней, еще не надежнее.
2) И по разбору ошибок — не владею такой информацией, так как это зона работы группы Функционального тестирования. По интеграции — мы делали концепт по автогенерации тасков в Жиру прям по результатам тестов (для этого надо просто добавить новую TestRule реализацию). Но группа тестирования решила, что им нужно больше контроля над процессом.
3) для проверки соответствия выгружаемых ПФ шаблонам — не понял вопроса. Что такое ПФ?
На полный регресс приходит сборка которая прошла все стадии юнит, компонентного и интеграционного тестирования
1. Конечно есть. Но это не в моей зоне ответственности и не тема этой статьи. Я тут как автоматизатор наиболее трудоемкой и дорогой части в тестировании.
2) Здесь вы сами решаете где остановить процесс непрерывной доставки ИМХО. Наше решение можно встроить в процесс и оно встроено в ограниченной части, но есть особенность — 1500 тестов мы можем позволить себе только в 60 потоков и занимает это около 4х часов. Мы приняли осознано такое решение
В целом эти вопросы выходят за скоп этой статьи, которая описывает пример автоматизации лишь одного конкретного шага тестирования.
1. В пирамиде тестирования проект Автотесты отвечает за "Системное тестирование". Таким образом — это высшая или последняя стадия тестирования перед выдачей в продуктив.
2. Я считаю что в целом вполне возможна и более того, только автоматизация системного тестирования может реально дать нам всем убежденность что продукт рабочий в целом и обеспечить ту самую непрерывную доставку. В нашем проекте Автотесты позволяют сделать непрерывную доставку на стенд системного тестирования как конечную точку автопоставки. Так что у нас «регрешн» проходит по рассписанию. НО!!! ограниченные объемы тестов сейчас активно используются в пайплайнах для QA скрининга в процессе разработки. ИМХО если у вас ограниченное количество бизнес сценариев или вы можете их «уложить» в 15-30 минут — это хорошый старт, чтобы внедрить системное тестирование в пайплайн.
3. Если вопрос касается исправления багов в системе, которые показали Автотесты, то на этот вопрос я не отвечу ибо NDA -)
Хранение локаторов — каким-то отдельным способом мы их не храним. Сделано достаточно просто — класс SomeConcretePage инициализирует веб-элементы как атрибуты класса c прямым указанием локаторов. Группы типовых веб-элементов (например — пагинатор или модалки) оформляются как отдельный класс который хранится в общем пакете (мы их называем — виджеты) и также инициализируются в SomeConcretePage. Я рассматривал идею сделать библиотеку веб-страниц и элементов через Spring @Configuration & Bean Annotations, но особых преимуществ не увидели. А вот стоимость разработки со спрингом — выше.
Подготовка тестовых данных — мы смогли минимизировать этот процесс. Фактически для любого теста нам нужен только существующий пользователь и существующие в системе НСИ данные, например, почтовые адреса до улицы. Далее тест самостоятельно через средства системы создает все требуемые промежуточные данные. Например для теста получения заказа тест последовательно создает Гражданина, добавляет ему адрес доставки, логинится от его имени, набирает заказ, апрувит его и так далее… Это имеет свои недостатки, но в целом этот подход себя оправдал.
Все сделано так чтобы в этом случае изменить только два объекта — спецификацию конкретного тест-кейса «Логин» и конкретного класса Login + LoginPage, которые его реализуют. Попробую описать чуть подробнее чем это есть в подразделе «Спецификация задач на разработку». На примере…
Мы автоматизируем кейс «Подтверждение получения товара» со следующими шагами:
1. Залогиниться
2. Создать заказ
3. Подтвердить получение заказа
В Testlink создается сценарий «Подтверждение получения товара» по следующему шаблону:
Таким образом для конкретного теста мы детализируем только шаги уникальные для этого теста. Например, тест «Отменить заказ» превращается в тестлинке в:
Ну а далее легко видеть, что при изменении сценария Логин, нам надо поправить только сценарий Логин.
В коде реализован аналогичный подход: Тест-Класс включает множество Сценарий-Классов, которые включают множество Активности-Методов. Таким образом нам надо будет поправить только один класс Login+LoginPage. Об этом написано во второй части, которая будет опубликована скоро.
Интеграция с ELK операция простая — мы просто пишем в Logger форматированную JSON строку, которая попадает в stdout, который перехватывает Bamboo и далее читает Logstash.
Что касается сравнения файлов то тут мы просто создаем файлы сами или парсим то что получили из системы любыми подходящими фреймворками. Технической проблемой было как файл к себе забрать… и об этом будет написано подробно во второй части