Умение разбираться с нестабильными тестами критически важно в тестировании, потому что автотесты с плавающими результатами замедляют скорость всей разработки.
Если вы не сталкивались с нестабильными тестами, обязательно прочтите эту статью, поскольку в ней делается попытка систематизировать причины возникновения нестабильности в тестах. Если вы сталкивались с нестабильными тестами, посмотрите сколько из них попадает в перечисленные области.
Данная статья призвана рассказать как бороться с каждой из причин.
За прошедшие годы я не раз сталкивался с нестабильными тестами, но вместо того чтобы рассматривать конкретные случаи, давайте попробуем сгруппировать причины возникновения нестабильности по задействованным при выполнении автотестов компонентам:
Сами тесты;
Фреймворк для запуска тестов;
Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк;
Операционная система и устройство с которым взаимодействует фреймворк автотестирования.
На рисунке 1 показан стек оборудования / программного обеспечения, который поддерживает тестируемое приложение или систему. На самом низком уровне находится оборудование. Следующий уровень - это операционная система, за которой следуют библиотеки, обеспечивающие интерфейс с системой. На самом высоком уровне находится промежуточное программное обеспечение, уровень, который предоставляет интерфейсы для конкретных приложений.
Однако в распределенной системе каждая служба приложения и службы, от которых она зависит, могут находиться в другом аппаратном / программном стеке, как и служба, выполняющая тест. Это проиллюстрировано на рисунке 2 как полная среда выполнения теста
Как обсуждалось выше, каждый из этих компонентов является потенциальной областью нестабильных тестов
Сами тесты
Сами тесты могут вызвать нестабильность. Типичные причины:
Неправильная инциализация или очистка;
Неправильно подобранные тестовые данные;
Неправильное предположение о состоянии системы. Примером может служить системное время;
Зависимость от асинхроных действий;
Зависимость от порядка запуска тестов.
Фреймворк для запуска тестов
Ненадежный фреймворк для запуска тестов может привести к нестабильности. Типичные причины:
Неспособность выделить достаточно ресурсов для тестируемой системы, что приводит к ее сбою;
Неправильное планирование тестов, поэтому они "противоречат" и приводят к сбою друг друга;
Недостаточно системных ресурсов для выполнения требований тестирования.
Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк
Приложение (или тестируемая система) может быть источником нестабильности
Приложение также может иметь множество зависимостей от других служб, и каждая из этих служб может иметь свои собственные зависимости.
В этой цепочки каждый сервис может послужить причиной возникновения нестабильных тестов.
Типичные причины:
Состояние гонки;
Непроинициализированные переменные;
Медленный ответ или отсутствие ответа при запросе от теста;
Утечки памяти;
Избыточная подписка на ресурсы;
Изменения в приложении и в тестах происходят с разной скоростью.
Среды тестирования называются герметичными, если они содержат всё, что необходимо для запуска тестов (т.е. нет внешних зависимостей, таких как серверы, работающие в прод окружении).
Герметичная среда менее подвержена нестабильности.
Операционная система и устройство с которым взаимодействует фреймворк автотестирования
Наконец, оборудование и операционная система могут быть источником нестабильности тестов. Типичные причины включают:
Сбои или нестабильность сети;
Дисковые ошибки;
Ресурсы, потребляемые другими задачами / службами, не связанными с выполняемыми тестами.
Как видно из большого разнообразия сбоев, снижение нестабильности при автоматизированном тестировании может быть довольно сложной задачей. В этой статье описаны области и типы нестабильности, которые могут возникать в этих областях, поэтому она может служить шпаргалкой при локализации причины нестабильных тестов.
В следующих статьях мы рассмотрим способы решения этих проблем.
Ссылки на источники
Откуда берутся нестабильные тесты? (оригинал/ перевод статьи на хабре)
Нестабильные тесты в Google и как мы их исправляем (оригинал)
Мои тесты на Selenium не стабильны! (оригинал)
Избегайте нестабильных тестов (оригинал)
DNK1
Во время работы в разных компаниях у нас всегда возникала проблема с прекондишнами для UI тестов и всегда это было основной причиной "нестабильности". Если мы возьмем банальный пример, — у нас есть кнопка, после нажатия на которую фон становится зеленым. То есть, тест состоит из того, что заходит на страницу, кликает на кнопку и проверяет фон. Но проблема в том, к примеру, что чтобы нажать на кнопку, ее нужно активировать в админке. Заходим в админку, находим тогл, активируем, выходим (тратим на это минуту), заходим в систему, кликаем на кнопку, проверяем фон (тратим на это 20 секунд). Получается, что больше времени мы тратим на прекондишн для теста, чем на сам тест, а тестирование самого этого прекондишна является, как бы, сказкой другой ночи и проверяется в другом тесте… Пробовали использовать 2 варианта. 1й это заранее мануально приготовленные фикстуры, дампы БД с нужными настройками, которые накатываются перед выполнением теста, но, по-хорошему, для каждого теста нужен отдельный дамп, а поддерживать и обновлять их это ад. Вторым вариантом был вызов метода, который был написан заранее и который отправлял API запрос и сетил все нужные нам прекондишны на уровне API… Вопрос: как вы решаете подобные задачи на своих проектах? Спасибо
Boris_Lys Автор
Мы используем разные подходы:
Вариант 1 — Моки. Мы используем мок сервер для того чтобы тесты проходили стабильно и можно было получить нужное состояния для тестового сценария благодаря мокам.
Вариант 2 — Api запрос. Мы конфигурируем нужные нам предусловия, дергая метод перед прогоном тестов.
k_valiev
К ответу выше, я бы еще добавил: