Автоматизация тестирования

В автотесте код открытия браузера, авторизации и проверок смешан в одном сценарии. Какой архитектурный принцип позволит изменить жизненный цикл запуска, не переписывая проверки?

В проекте много сторонних библиотек: какой автоматизированный контроль выявит известные уязвимости до запуска приложения?

В тестовом наборе результат зависит от порядка запуска, но при последовательном прогоне это незаметно. Какой механизм поможет выявить скрытую зависимость тестов?

При ограниченном времени CI как расставить порядок автотестов, чтобы раньше получить наиболее важный сигнал?

При поэтапном обновлении сервиса старая и новая версии одновременно работают с одной базой. Какой подход к автотестам выявит несовместимую миграцию схемы до переключения трафика?

После переименования файлов CI остаётся зелёным, но число выполненных тестов резко упало. Какой контроль должен обнаружить такую потерю тестов?

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

Проектирование нового компонента начинается с автотестов для ещё не реализованного поведения. Какой основной риск снижает такой подход «сначала тесты»?

Задача CI — автоматически выявлять нарушения доступности веб-интерфейса: какой механизм следует встроить в автотесты?

В долгом прогоне автотестов память процесса постепенно растёт: какой механизм поможет доказать утечку ресурсов в тестовой инфраструктуре?