Comments 16
Спасибо за статью, добавил в избранное.
Очень жду вторую часть с техническими аспектами, особенно про сравнение файлов и интеграцию с ELK.
Также хотелось бы узнать технологии и фреймворки(помимо тех, которые называли), которые используются на проекте.
Очень жду вторую часть с техническими аспектами, особенно про сравнение файлов и интеграцию с ELK.
Также хотелось бы узнать технологии и фреймворки(помимо тех, которые называли), которые используются на проекте.
Во второй части это будет описано более подробно, хотя эти публикации относятся в первую очередь к вопросам организации работ и кода. ИМХО информации о том как кодировать разные функции достаточно, а вот как запустить машину проекта по конвеерной разработке автотестов я в сети не встречал. По технике…
Интеграция с ELK операция простая — мы просто пишем в Logger форматированную JSON строку, которая попадает в stdout, который перехватывает Bamboo и далее читает Logstash.
Что касается сравнения файлов то тут мы просто создаем файлы сами или парсим то что получили из системы любыми подходящими фреймворками. Технической проблемой было как файл к себе забрать… и об этом будет написано подробно во второй части
Интеграция с ELK операция простая — мы просто пишем в Logger форматированную JSON строку, которая попадает в stdout, который перехватывает Bamboo и далее читает Logstash.
Что касается сравнения файлов то тут мы просто создаем файлы сами или парсим то что получили из системы любыми подходящими фреймворками. Технической проблемой было как файл к себе забрать… и об этом будет написано подробно во второй части
Интересно, спасибо. А как происходит изменение тестов при изменении приложения? Вот скажем заказчик меняет весь процесс авторизации в пользу какого-нибудь auth сервиса. Условных 500 тестов, которые содержат авторизацию в своих шагах, меняются в одном месте или все 500 потребуют изменения?
Это как раз одна из фишек нашей реализации.
Все сделано так чтобы в этом случае изменить только два объекта — спецификацию конкретного тест-кейса «Логин» и конкретного класса Login + LoginPage, которые его реализуют. Попробую описать чуть подробнее чем это есть в подразделе «Спецификация задач на разработку». На примере…
Мы автоматизируем кейс «Подтверждение получения товара» со следующими шагами:
1. Залогиниться
2. Создать заказ
3. Подтвердить получение заказа
Ну а далее легко видеть, что при изменении сценария Логин, нам надо поправить только сценарий Логин.
В коде реализован аналогичный подход: Тест-Класс включает множество Сценарий-Классов, которые включают множество Активности-Методов. Таким образом нам надо будет поправить только один класс Login+LoginPage. Об этом написано во второй части, которая будет опубликована скоро.
Все сделано так чтобы в этом случае изменить только два объекта — спецификацию конкретного тест-кейса «Логин» и конкретного класса Login + LoginPage, которые его реализуют. Попробую описать чуть подробнее чем это есть в подразделе «Спецификация задач на разработку». На примере…
Мы автоматизируем кейс «Подтверждение получения товара» со следующими шагами:
1. Залогиниться
2. Создать заказ
3. Подтвердить получение заказа
В Testlink создается сценарий «Подтверждение получения товара» по следующему шаблону:
- Предусловие 1. Выполнить Логин с пользователем типа Х
- Предусловие 2. Выполнить «Создать заказ»
- Шаги основного кейса «Подтверждение получения товара»…
Таким образом для конкретного теста мы детализируем только шаги уникальные для этого теста. Например, тест «Отменить заказ» превращается в тестлинке в:
- Предусловие 1. Выполнить Логин с пользователем типа Х
- Предусловие 2. Выполнить «Создать заказ»
- Шаги основного кейса «Отменить заказ»…
Ну а далее легко видеть, что при изменении сценария Логин, нам надо поправить только сценарий Логин.
В коде реализован аналогичный подход: Тест-Класс включает множество Сценарий-Классов, которые включают множество Активности-Методов. Таким образом нам надо будет поправить только один класс Login+LoginPage. Об этом написано во второй части, которая будет опубликована скоро.
Интересно, что в статье ничего не говорится про сбор покрытия клиентского и BE кода. По моему мнению, большое количество мёртвого, не используемого кода становится проблемой для больших проектов, и такая комплексная автоматизация могла бы анализировать и находить участки кода в которые управление не доходит. А это значит либо этот код не нужен — устарел или на него нет ещё теста либо нет требований на этот участок кода.
Решение этих вопросов не входило в скоп нашего проекта. Более того, автотесты которые мы делали являются отдельным приложением, которое ничего не знает о коде и организации самой системы. Все взаимодействие только через браузер. Мы, как группа автоматизации UI E2E тестов также не оценивали ни покрытие, ни полноту. Эта часть работы относится к компетенции группы функционального тестирования, которая является для нас, группы автоматизации, внутренним заказчиком.
Спасибо за статью! Концепция очень привлекательна, и очень актуальна для многих. Оч ждем продолжения, особа хочется, чтобы была рассмотрена часть подготовки тестовых данных и реализация хранения локаторов.
Из нюансов хотел бы обратить внимание, что Junit 4 и java 8 устарели, а проблем с переходом на новые версии быть не должно. Возможно Вам понравятся некоторые рюшички junit 5 и новая модульная система java более поздних версий.
Из нюансов хотел бы обратить внимание, что Junit 4 и java 8 устарели, а проблем с переходом на новые версии быть не должно. Возможно Вам понравятся некоторые рюшички junit 5 и новая модульная система java более поздних версий.
Отвечу сразу по пунктам
Хранение локаторов — каким-то отдельным способом мы их не храним. Сделано достаточно просто — класс SomeConcretePage инициализирует веб-элементы как атрибуты класса c прямым указанием локаторов. Группы типовых веб-элементов (например — пагинатор или модалки) оформляются как отдельный класс который хранится в общем пакете (мы их называем — виджеты) и также инициализируются в SomeConcretePage. Я рассматривал идею сделать библиотеку веб-страниц и элементов через Spring @Configuration & Bean Annotations, но особых преимуществ не увидели. А вот стоимость разработки со спрингом — выше.
Подготовка тестовых данных — мы смогли минимизировать этот процесс. Фактически для любого теста нам нужен только существующий пользователь и существующие в системе НСИ данные, например, почтовые адреса до улицы. Далее тест самостоятельно через средства системы создает все требуемые промежуточные данные. Например для теста получения заказа тест последовательно создает Гражданина, добавляет ему адрес доставки, логинится от его имени, набирает заказ, апрувит его и так далее… Это имеет свои недостатки, но в целом этот подход себя оправдал.
Хранение локаторов — каким-то отдельным способом мы их не храним. Сделано достаточно просто — класс SomeConcretePage инициализирует веб-элементы как атрибуты класса c прямым указанием локаторов. Группы типовых веб-элементов (например — пагинатор или модалки) оформляются как отдельный класс который хранится в общем пакете (мы их называем — виджеты) и также инициализируются в SomeConcretePage. Я рассматривал идею сделать библиотеку веб-страниц и элементов через Spring @Configuration & Bean Annotations, но особых преимуществ не увидели. А вот стоимость разработки со спрингом — выше.
Подготовка тестовых данных — мы смогли минимизировать этот процесс. Фактически для любого теста нам нужен только существующий пользователь и существующие в системе НСИ данные, например, почтовые адреса до улицы. Далее тест самостоятельно через средства системы создает все требуемые промежуточные данные. Например для теста получения заказа тест последовательно создает Гражданина, добавляет ему адрес доставки, логинится от его имени, набирает заказ, апрувит его и так далее… Это имеет свои недостатки, но в целом этот подход себя оправдал.
Хотел уточнить несколько вопросов:
1.Как в такой подход ложиться пирамида тестирования?
2.Возможна ли а таком подходе непрерывная поставка продукта? Или регрешн проводится по определенному расписанию с исправлением сразу всех найденых багов
3.Сколько времени занимает исправление багов?
1.Как в такой подход ложиться пирамида тестирования?
2.Возможна ли а таком подходе непрерывная поставка продукта? Или регрешн проводится по определенному расписанию с исправлением сразу всех найденых багов
3.Сколько времени занимает исправление багов?
Давайте посмотрим по пунктам:
1. В пирамиде тестирования проект Автотесты отвечает за "Системное тестирование". Таким образом — это высшая или последняя стадия тестирования перед выдачей в продуктив.
2. Я считаю что в целом вполне возможна и более того, только автоматизация системного тестирования может реально дать нам всем убежденность что продукт рабочий в целом и обеспечить ту самую непрерывную доставку. В нашем проекте Автотесты позволяют сделать непрерывную доставку на стенд системного тестирования как конечную точку автопоставки. Так что у нас «регрешн» проходит по рассписанию. НО!!! ограниченные объемы тестов сейчас активно используются в пайплайнах для QA скрининга в процессе разработки. ИМХО если у вас ограниченное количество бизнес сценариев или вы можете их «уложить» в 15-30 минут — это хорошый старт, чтобы внедрить системное тестирование в пайплайн.
3. Если вопрос касается исправления багов в системе, которые показали Автотесты, то на этот вопрос я не отвечу ибо NDA -)
1. В пирамиде тестирования проект Автотесты отвечает за "Системное тестирование". Таким образом — это высшая или последняя стадия тестирования перед выдачей в продуктив.
2. Я считаю что в целом вполне возможна и более того, только автоматизация системного тестирования может реально дать нам всем убежденность что продукт рабочий в целом и обеспечить ту самую непрерывную доставку. В нашем проекте Автотесты позволяют сделать непрерывную доставку на стенд системного тестирования как конечную точку автопоставки. Так что у нас «регрешн» проходит по рассписанию. НО!!! ограниченные объемы тестов сейчас активно используются в пайплайнах для QA скрининга в процессе разработки. ИМХО если у вас ограниченное количество бизнес сценариев или вы можете их «уложить» в 15-30 минут — это хорошый старт, чтобы внедрить системное тестирование в пайплайн.
3. Если вопрос касается исправления багов в системе, которые показали Автотесты, то на этот вопрос я не отвечу ибо NDA -)
1.Если я правильно понял других типов тестов на проекте нет?
2.Да системное тестирование может дать высокую степень уверенности, что продукт рабочий. Но имеет обратную сторону — позднее время обнаружения багов и, соответственно, самую высокую стоимость исправления
непрерывная доставка подразумевает:
то есть тестирование по расписанию никак не укладывается в такой подход. Только наличие пирамиды(unit -> component -> contract -> api -> UI: список каждая команда выбирает сама) решает вопрос
2.Да системное тестирование может дать высокую степень уверенности, что продукт рабочий. Но имеет обратную сторону — позднее время обнаружения багов и, соответственно, самую высокую стоимость исправления
непрерывная доставка подразумевает:
это практика разработки программного обеспечения, когда при любых изменениях в программном коде выполняется автоматическая сборка
то есть тестирование по расписанию никак не укладывается в такой подход. Только наличие пирамиды(unit -> component -> contract -> api -> UI: список каждая команда выбирает сама) решает вопрос
Я так понял, что есть, но пишутся другими людьми
Итого, назначением Автотестов является автоматизация ручного Е2Е-тестирования. Это «внешняя» система, которая не принимает участия в процессе разработки тестируемой Системы и никак не связана с модульными или интеграционными тестами, используемыми разработчиками.
Я даже не заметил как ввел вас в заблуждение -)
1. Конечно есть. Но это не в моей зоне ответственности и не тема этой статьи. Я тут как автоматизатор наиболее трудоемкой и дорогой части в тестировании.
2) Здесь вы сами решаете где остановить процесс непрерывной доставки ИМХО. Наше решение можно встроить в процесс и оно встроено в ограниченной части, но есть особенность — 1500 тестов мы можем позволить себе только в 60 потоков и занимает это около 4х часов. Мы приняли осознано такое решение
В целом эти вопросы выходят за скоп этой статьи, которая описывает пример автоматизации лишь одного конкретного шага тестирования.
1. Конечно есть. Но это не в моей зоне ответственности и не тема этой статьи. Я тут как автоматизатор наиболее трудоемкой и дорогой части в тестировании.
2) Здесь вы сами решаете где остановить процесс непрерывной доставки ИМХО. Наше решение можно встроить в процесс и оно встроено в ограниченной части, но есть особенность — 1500 тестов мы можем позволить себе только в 60 потоков и занимает это около 4х часов. Мы приняли осознано такое решение
В целом эти вопросы выходят за скоп этой статьи, которая описывает пример автоматизации лишь одного конкретного шага тестирования.
Просто в нашей команде при любом пул риквесте запускается вся пирамида тестов и каждый разработчик контролирует качество своего кода.
API, UI тесты пробует продебажить и пофиксать(свой код или тесты, смотря какая причина фейла) сам девелопер
Предыдущая архитектура включала только UI тесты, но время от нахождения бага до фикса отличается в разы. Плюс некачественный код не может попасть в общую бренчу
API, UI тесты пробует продебажить и пофиксать(свой код или тесты, смотря какая причина фейла) сам девелопер
Предыдущая архитектура включала только UI тесты, но время от нахождения бага до фикса отличается в разы. Плюс некачественный код не может попасть в общую бренчу
Sign up to leave a comment.
Автоматизация End-2-End тестирования комплексной информационной системы. Часть 1. Организационная