Она привила здоровую привычку думать о тестировании и установила общий язык в отрасли. Тесты добавляются на каждом уровне по мере развития проекта и добавления новых функций. Поддержка набора тестов растет энтропийно по мере увеличения одной или нескольких категорий усилий. Команда, которая пренебрегает поддержкой своего набора тестов, вскоре может оказаться в красной зоне. В «Трофее тестирования» приоритеты расставлены по-другому.
На этом уровне ПО проверяется на соответствие заявленным требованиям. Приемка может быть как внешней (проводит заказчик), так и внутренней (проводят свои специалисты). Проводить ее имеет смысл, когда ПО достигло нужного уровня качества и есть план приемки. После завершения юнит- и интеграционного тестирования наступает этап системного тестирования.
End to end тесты
Для системных тестов и системных интеграционных тестов мы хотели бы использовать pact.io в будущем, поскольку он уже используется в нашем наборе веб-инструментов. Мы также хотели бы избежать поддержки выделенной тестовой среды и напрямую использовать стэйджинг среду со всеми связанными с этим ограничениями. Вы узнаете цену зависимости от внешних сервисов для ваших тестов. Некоторые из них предоставят вам доступ к специальной тестовой среде, которая поможет вам. Доступ только к стэйджинг или, что еще хуже, только к рабочей среде стороннего сервиса может сделать невозможным тестирование системной интеграции.
- Предпочтительными методами являются тесты пользовательского интерфейса и контрактные тесты.
- Сегодня мы поговорим про Пирамиду тестирования и ее уровни.
- Михаил работает и пишет статьи, связанные с IT-индустрией.
- В большинстве случаев должно быть много юнит-тестов, меньше интеграционных тестов и еще меньше системных тестов.
- Юнит-тесты могут быть лучшим вложением в начале проекта.
Кент Доддс (Kent C. Dodds) — один из таких людей, который предложил «Трофей тестирования» в качестве альтернативного способа структурирования тестов при разработке фронтенда. Чтобы понять, как пирамида приобрела свою форму, мы должны разобраться в тонкостях каждого типа тестов. Введенная Майком Коном в его книге Succeeding with Agile (2009), пирамида — это метафора для мышления о тестировании в программном обеспечении. Эта идея настолько прижилась, что и по сей день является отраслевым стандартом в инженерных кругах. Если мы говорим о модель С4 (Контекст, Контейнеры, Компоненты, Код), я бы посоветовал, чтобы кто-то знал, по крайней мере, о деталях уровня C3 продукта, над которым мы работаем. В итоге, исходя из потребности и интереса, можно перейти на уровень С4.
Почему QA должен быть осведомлен об архитектуре проекта?
Проведение этих тестов гарантирует, что без влияния внешних неблагоприятных воздействий приложение работает так, как ожидается. Это дает уверенность в том, что по крайней мере работает логика внутри приложения. Для всех новых функций приложения мы сразу же добавляем компонентные тесты. Однако у нас ещё остаются сквозные тесты, которые можно перенести на нижние уровни пирамиды. Мы провели анализ и нашли подходящие для этого сценарии. Поскольку я QA-инженер, мне чаще приходится иметь дело с руынм тестированием и высокоуровневыми сквозными тестами.
Юнит-тесты могут быть лучшим вложением в начале проекта. Но после стабилизации функций может потребоваться изменить баланс, добавив больше тестов E2E и удалив некоторые из других категорий. Это должно повысить уверенность при одновременном снижении или, по крайней мере, сохранении уровня усилий. По сравнению с пирамидой, модульные тесты отходят на второй план, их заменяют инструменты статического тестирования, такие как ESLint и JSHInt. Они сканируют код, предлагая предложения и находя потенциальные проблемы, такие как использование небезопасных операторов или несоблюдение правил именования переменных. Они гарантируют, что ваше приложение работает должным образом без каких-либо внешних помех.
Переносим сквозные тесты на компонентный уровень
Оставляем тесты системной интеграции, системные тесты и даже тесты приложений для типичных критических сценариев нашего приложения. Чтобы представить себе это в перспективе, сегодня для приложения Bumble на iOS у нас около 900 сквозных сценариев в различных наборах тестов. Подавляющее большинство из них выполняется на симуляторах параллельно (насколько это возможно) и относительно быстро. Последние измерения показывают, что в среднем выполнение сквозного теста на симуляторе iOS занимает от 30 до 90 секунд (включая настройку и удаление). Следовательно, выполнение полного набора тестов займёт 20—30 минут. Кроме того, мы делаем тестовые запуски и на реальных iOS-устройствах.
Модульные тесты (модульное тестирование) (unit тесты, юнит тесты) — это тесты, которые обычно пишут разработчики, чтобы убедиться, что код работает так, как они написали. Мы всё ещё активно улучшаем тестовое покрытие и добавляем тесты на все уровни пирамиды. Наша главная цель — разместить нужные тесты на нужных уровнях.
Пишем низкоуровневые тесты
Это вид тестирования программного обеспечения, который выполняет проверку системы в целом. Поэтому к стандартной тестовой пирамиде «присоединяются» последующие процессы Logging-Monitoring-Alerting. Пирамида тестирования разделяется на уровни по модульному принципу. Обычно больше всего тестов проводится на модульном уровне, затем идут интеграционный, системный и приемочный. На этом уровне тестируется один модуль программы (компонент, функция, метод и т.п.). Поэтому здесь тесты имеют узкую область применения и мало зависят от других модулей (на то они и модульные).
Ну и как мы видим ui автотестов или ручных ui тестов, которыми и занимаются тестировщики их должно быть меньше всего, а самых стабильных и быстрых тестов unit тестов должно быть больше всего. Некоторые считают эту концепцию «антипаттерном» тестирования, в то время как другие так не считают, относятся вполне серьезно автоматизация тестирования и применяют на практике, и проблем не испытывают. Такая структура обусловлена тем, что модульные тесты разрабатываются и запускаются в работу быстрее. В то же время, тесты верхнего уровня больше зависят от внешних факторов (сервера, интерфейс, окружение, сценарии пользователя и т.п.), поэтому сложнее и дороже.
Пирамида тестирования: раскладываем по уровням
Пирамида тестов — это абстракция, которая отражает группировку тестов программного обеспечения по разным уровням детализации. Также она характеризует относительное количество тестов в каждой группе. Сегодня я расскажу об автоматизации тестирования в iOS, потому что на протяжении всей своей карьеры в Badoo я плотно занимался тестированием наших нативных iOS-приложений, которые написаны на Objective-C и Swift. Хотя кое-где я буду упоминать характерные для iOS инструменты и термины (например, XCTest), общие принципы и подходы универсальны. Так что, даже если в вашем проекте используется совсем другой стек, статья будет вам полезна.
Когда ваш CI/CD приблизится к критической 10-минутной отметке, вам придется реорганизовать конвейер и оптимизировать все медленные тесты, чтобы сохранить жизненно важный цикл обратной связи быстрым и проворным. Как разные сервисы взаимодействуют друг с другом (например, REST API или с помощью любого асинхронного режима с помощью Kafka или любого другого инструмента) и проверить производительность соответственно. (например, микросервисы против монолитных архитектур, их преимущества и недостатки, различные паттерны проектирования).
