Комментарии 18
Добрый день, спасибо за статью, очень содержательно. Особенно удивили и порадовали масштабы проекта.
Вопрос по мониторингу, как-то отслеживаете тенденции по отчетам автотестов за длительный промежуток времени?
И по разбору ошибок, есть ли какая то интеграция с баг-трекерами и TMS-системами? И в среднем сколько уходит времени на разбор и документацию результатов?
И самый последний вопрос — дополнительно какими инструментами пользуетесь для проверки соответствия выгружаемых ПФ шаблонам?
Вопрос по мониторингу, как-то отслеживаете тенденции по отчетам автотестов за длительный промежуток времени?
И по разбору ошибок, есть ли какая то интеграция с баг-трекерами и TMS-системами? И в среднем сколько уходит времени на разбор и документацию результатов?
И самый последний вопрос — дополнительно какими инструментами пользуетесь для проверки соответствия выгружаемых ПФ шаблонам?
1) Отслеживание тенденций по автотестам в целом проводится через ELK стек, для чего в stdout мы логируем результат и тайминг каждого теста в json формате. Далее это уходит в Бамбу, где читается Logstash и далее уже средствами ELK. Эта фича используется мной как разработчиком для отслеживания деградации производительности. Также дополнительно мы по этому каналу сбрасываем все что требует статистического анализа. Для тестеров данная информация оказалась бесполезной.
2) И по разбору ошибок — не владею такой информацией, так как это зона работы группы Функционального тестирования. По интеграции — мы делали концепт по автогенерации тасков в Жиру прям по результатам тестов (для этого надо просто добавить новую TestRule реализацию). Но группа тестирования решила, что им нужно больше контроля над процессом.
3) для проверки соответствия выгружаемых ПФ шаблонам — не понял вопроса. Что такое ПФ?
2) И по разбору ошибок — не владею такой информацией, так как это зона работы группы Функционального тестирования. По интеграции — мы делали концепт по автогенерации тасков в Жиру прям по результатам тестов (для этого надо просто добавить новую TestRule реализацию). Но группа тестирования решила, что им нужно больше контроля над процессом.
3) для проверки соответствия выгружаемых ПФ шаблонам — не понял вопроса. Что такое ПФ?
Спасибо за ответы, под третьим пунктом имелись ввиду печатные формы, а именно библиотеки для сравнения выгружаемых файлов с шаблонами печатных форм. Например PDFutil или подобные инструменты.
Для контроля pdf мы используем itextpdf.com
Для генерации и контроля эксель файлов — apache.poi.xssf.usermodel.XSSFWorkbook
Для генерации и контроля эксель файлов — apache.poi.xssf.usermodel.XSSFWorkbook
Первую проблему мы решили, обернув метод-сценарий логина в балансировщик, который ограничивал максимальное количество операций логина заданной константой.
Почему просто не сделать пулл сессий, если нет жесткой привязки к воркфлоу по юзерам?
Вторая часть публикации ориентирована в первую очередь на лидеров групп автоматизации UI end-2-end тестирования и ведущих тест-автоматизаторов
Лидеры/ведущие автоматизаторы вам скажут(можете вот у разработчиков Selenide спросить), что покрывать e2e сценарии UI тестами — не лучший путь. Пирамида тестирования там… дороговизна покрытия и поддержки, скорость выполнения.
Время прохождения полного набора тестов (~ 1000 полноценных тестов) начало приближаться к критической отметке в 6 часов.
Ну и вот если вы будете использовать апи для е2е тестинга, тогда ваши 1500 тестов станут проходить всего минут за 30, а реально нужные и полезные проверки на UI у вас займут гораздо меньше времени и будут представлены в меньшем количестве
Жесткая привязка по юзерам есть. Кроме того мы ограничиваем именно операцию логина (10 потоков), а не все сессии (60 потоков). Это решение было максимально быстрым и заняло час времени.
Это именно то что нам было нужно. По бизнесу. Тесты полной системы от браузера до реальной базы.
Согласен. Дорого. Медленно. Можно раздельно тестить UI на фронтенд моках, можно тестить систему прямо через паблик api. Но задача была автоматизировать именно полные тесты от браузера до базы данных на полной копии продуктива.
В целом все что вы говорите совершенно верно. И нам именно так и говорили. Но тестить руками — еще дороже, еще медленней, еще не надежнее.
Это именно то что нам было нужно. По бизнесу. Тесты полной системы от браузера до реальной базы.
Согласен. Дорого. Медленно. Можно раздельно тестить UI на фронтенд моках, можно тестить систему прямо через паблик api. Но задача была автоматизировать именно полные тесты от браузера до базы данных на полной копии продуктива.
В целом все что вы говорите совершенно верно. И нам именно так и говорили. Но тестить руками — еще дороже, еще медленней, еще не надежнее.
Привет!
Есть статистика по затраченному времени на разработку фреймворка со всеми тестами?
Сколько времени уходит на разработку нового теста?
Как много изменений в коде требует разработка нового теста?
И еще вопрос по стабильности — сколько ошибок по вине тестового кода на 100 запусков тестов?
Спасибо!)
Есть статистика по затраченному времени на разработку фреймворка со всеми тестами?
Сколько времени уходит на разработку нового теста?
Как много изменений в коде требует разработка нового теста?
И еще вопрос по стабильности — сколько ошибок по вине тестового кода на 100 запусков тестов?
Спасибо!)
В целом, как было приведено в первой части, мы укладываемся в показатель 2-8 часов на каждый тест-сценарий (средняя статистика непосредственно кодера — 5,12 часа на тест) в зависимости от:
1) это первый тест для подсистемы — значит надо делать классы Page
2) как много шагов в тесте — типовой размер от 15 до 20 условных шагов
3) необходимо ли работать с эксель файлами, лезть в базы и тп
4) есть ли новые элементы — например мы потратили почти неделю пока отладили работу с яндекс-картой
Разработка нового теста практически не требует изменений в текущих тестах. Процесс устроен так:
1) создать новую Page или добавить в существующую новые элементы + добавить методы ввода-данных и проверки разметки. Мы стараемся не делать универсальные методы, а просто добавляем новые
2) создать новый Action для нового теста и добавить шаги вызова Page методов и бизнес проверки. У нас Action реализует всегда только один сценарий, даже если есть типа похожий
3) создать новый Test класс и собрать в нем требуемую цепочку вызовов Action классов
У меня еще будет опубликована третья часть с шаблонами наших классов и описанием всех TestRule которые мы используем
1) это первый тест для подсистемы — значит надо делать классы Page
2) как много шагов в тесте — типовой размер от 15 до 20 условных шагов
3) необходимо ли работать с эксель файлами, лезть в базы и тп
4) есть ли новые элементы — например мы потратили почти неделю пока отладили работу с яндекс-картой
Разработка нового теста практически не требует изменений в текущих тестах. Процесс устроен так:
1) создать новую Page или добавить в существующую новые элементы + добавить методы ввода-данных и проверки разметки. Мы стараемся не делать универсальные методы, а просто добавляем новые
2) создать новый Action для нового теста и добавить шаги вызова Page методов и бизнес проверки. У нас Action реализует всегда только один сценарий, даже если есть типа похожий
3) создать новый Test класс и собрать в нем требуемую цепочку вызовов Action классов
У меня еще будет опубликована третья часть с шаблонами наших классов и описанием всех TestRule которые мы используем
сколько ошибок по вине тестового кода на 100 запусков тестов — статистика по жире показывает счас что только около 3% всех задач имеют тип «баг». Это значит что причиной падения теста была либо системная ошибка (у нас это все рантайм эксепшины), или было найдено несоответствие в реализации теста. Если я вас правильно понял -)
Я правильно понял из текста, что вы проверки осуществляете исключительно в Page Object'ах?
Нет. В Page Object'ах проводятся структурные проверки связанные с интерфейсом и представлениями данных. В Action классах проводятся проверки бизнес логики.
Для примера. Проверка отображения профиля пользователя:
— пэйдж объект реализует метод гетЮзерПрофайл. В этом методе мы предполагаем что уже находимся на странице ЮзерПрофайл. Тут мы проверяем что все поля на странице показаны и имеют требуемый формат. Например — телефон это телефон, а ЮзерЛогин не пустой. После этого собираем данные в класс ЮзерПрофайлПейджИнфо и возвращаем в Action
— Action класс делает бизнес проверку — например сравнивает данные полученные со страницы с данными, которые должны быть такими, как задано в «тестовой сцене»
Это позволяет нам разделить логику и править только конкретный Пэйдж если изменился только дизайн и наоборот. А еще это в перспективе поможет нам легко заменить пэйдж объект на рест-api объект
Для примера. Проверка отображения профиля пользователя:
— пэйдж объект реализует метод гетЮзерПрофайл. В этом методе мы предполагаем что уже находимся на странице ЮзерПрофайл. Тут мы проверяем что все поля на странице показаны и имеют требуемый формат. Например — телефон это телефон, а ЮзерЛогин не пустой. После этого собираем данные в класс ЮзерПрофайлПейджИнфо и возвращаем в Action
— Action класс делает бизнес проверку — например сравнивает данные полученные со страницы с данными, которые должны быть такими, как задано в «тестовой сцене»
Это позволяет нам разделить логику и править только конкретный Пэйдж если изменился только дизайн и наоборот. А еще это в перспективе поможет нам легко заменить пэйдж объект на рест-api объект
Сколько времени занимает поддержка изменений бизнес-логики в тестах и как вы вычисляете какие кейсы надо править?
Какие тесты надо править «вычисляет» группа Функционального тестирования, которая правит тест-спецификации и скидывает нам задачи в жиру как «Доработка» «немедленно» или «к дате». Далее мы вычисляем что надо править:
1) сравниваем по пунктам тест-спецификации, какие шаги теста изменились\добавились\удалились
2) мы помним, что каждый шаг теста = конкретный метод в классе типа Action как SomeAction.someStep(someBusinessModel...). Поэтому мы правим конкретные методы + при необходимости конкретные SomePage(1..*), которые используются в данном методе.
3) При необходимости правим бизнес-модель которая определяет тестовую сцену, как конкретные классы, которые используются в SomeAction.someStep(someBusinessModel...)
Такая схема поддерживается 1) запретом горизонтальных депенденси между уровнями иерархии, 2) независимостью классов Action и Page от генерации тестовой сцены.
Таким образом мы всегда знаем точки изменений и какой уровень изменять
Поддержка бизнес логики занимает в целом не много времени, она проста и сводится к очечным изменениям. Хотя иногда приходится и переписывать все ибо поменялось все -)
1) сравниваем по пунктам тест-спецификации, какие шаги теста изменились\добавились\удалились
2) мы помним, что каждый шаг теста = конкретный метод в классе типа Action как SomeAction.someStep(someBusinessModel...). Поэтому мы правим конкретные методы + при необходимости конкретные SomePage(1..*), которые используются в данном методе.
3) При необходимости правим бизнес-модель которая определяет тестовую сцену, как конкретные классы, которые используются в SomeAction.someStep(someBusinessModel...)
Такая схема поддерживается 1) запретом горизонтальных депенденси между уровнями иерархии, 2) независимостью классов Action и Page от генерации тестовой сцены.
Таким образом мы всегда знаем точки изменений и какой уровень изменять
Поддержка бизнес логики занимает в целом не много времени, она проста и сводится к очечным изменениям. Хотя иногда приходится и переписывать все ибо поменялось все -)
Коллеги, все вы задаете правильные вопросы -) Понимаю, что без кода некоторые аспекты выглядят непонятно. У меня уже написана третья часть в которой приведены шаблоны классов BaseTest класс с RuleChain, Test класс и Action класс. И я рассчитываю что ее опубликуют до нового года. И некоторые вещи станут понятнее -)
Подскажите,
1) Есть ли оценка/понимание, какой объём ручного тестирования (в человекочасах или какой другой метрике) был закрыт автоматизацией?
2) Вы писали, что 3% от задач в Jire имеют статус «баг». А сколько это в количественном эквиваленте?
3) Как непосредственно разработчики ПО относятся к вашей системе автоматического тестирования?
1) Есть ли оценка/понимание, какой объём ручного тестирования (в человекочасах или какой другой метрике) был закрыт автоматизацией?
2) Вы писали, что 3% от задач в Jire имеют статус «баг». А сколько это в количественном эквиваленте?
3) Как непосредственно разработчики ПО относятся к вашей системе автоматического тестирования?
1) да, эффект есть, но реальные цифры под NDA. Давайте попробуем подсчитать абстрактно (данные условные) — 1000 тестов (обязательный регресс) проходят за (условно) 3 часа в 50 потоков = 3х50 = 150 часов чистого времени х 10 фиксов на релиз = 1500 часов. И я бы еще умножил на минимум 3 так как человек вводит данные медленнее чем робот. но не будем. Получаем — каждый релиз мы экономим 1500 часов ручного тестирования. Или 150 часов на каждый апдейт выходящий в продуктив.
ИМХО. Важнее тут не только экономия, а то что за 3 часа вы никакими реальными силами не пройдете 1000 тестов по всей системе.Это была главная конечно цель.
2) сейчас в жире 5700 задач = 171 баг
3) на первых этапах результат автотеста надо было воспроизвести обязательно руками для заведения база на разработку. Сейчас доверия поболее. Мы выстраивали эту работу.
ИМХО. Важнее тут не только экономия, а то что за 3 часа вы никакими реальными силами не пройдете 1000 тестов по всей системе.Это была главная конечно цель.
2) сейчас в жире 5700 задач = 171 баг
3) на первых этапах результат автотеста надо было воспроизвести обязательно руками для заведения база на разработку. Сейчас доверия поболее. Мы выстраивали эту работу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация End-2-End тестирования комплексной информационной системы. Часть 2. Техническая