Фреймворк-независимое пособие по сокращению времени выполнения тестов 

Независимо от того, какую платформу для автоматизации тестирования вы используете, Cypress, Playwright, Selenium or WebDriver.IO, важным фактором является время выполнения тестов. 

В рамках подхода ”Shift left“ тестированию отводится большая роль в получении раннего фидбэка (feedback loop). Если более классический подход предусматривает достаточно длительные периоды тестирования, то при быстрых feedback loops для тестирования остается не так и много времени. 

При этом высокое покрытие регрессионным тестированием, очевидно, требует большого количества тестов. Как правило, в таких случаях применяются организационные “решения”. Длительное время выполнения часто сокращается за счет планирования выполнения тестов ночью или по выходным, то есть в нерабочее время. Очевидным недостатком является то, что результаты напрямую не связаны с изменениями, внесенными в рабочее время, а также медленный feedback loops. Это влечет за собой трудоемкую отладку. Итак, как действительно можно сократить время выполнения тестов, вместо того чтобы сдвигать его и принимать вышеупомянутые недостатки? 

Существует несколько возможных способов сократить время выполнения автоматических регрессионных тестов. Однако у каждого из них есть ограничения, которые нужно принимать во внимание. 

1. Параллельное тестирование (распараллеливание не сокращает время выполнения каждого тесткейса, но влияет на общее время их обработки). 

2. Использование динамического ожидания.

3. Применение positive assertions.

4. Объединение тесткейсов.

5. Предотвращение закрытия браузера.

6. Выбор браузера и конфигурации.

7. Использование бэкдор (backdoor) в приложениях.

8. Повторное использование сохраненных сеансов.

9. Настройка критериев сбоя.

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

Параллельное тестирование 

Параллельное выполнение всех тестов сокращает общее время выполнения до времени необходимого самому длинному тесту из набора. Однако это обходится дорого с точки зрения производительности. Для каждого параллельно запущенного теста требуется сессия браузера. Это означает, что если вы хотите запустить параллельно 200 тестов, то вам потребуется 200 сеансов браузера. Не следует недооценивать необходимые ресурсы. Поскольку ресурсы не требуются постоянно, вам следует подумать о временном выделении этих ресурсов, чтобы избежать затрат на ресурсы, которые большую часть времени простаивают. Если вы не в состоянии обеспечить необходимую настройку on-premise инфраструктуры, существует множество поставщиков облачных услуг. 

Использование динамического ожидания вместо статического 

Статическое ожидание - всегда плохая идея, и его следует избегать, где только возможно. Но если вы сейчас просмотрите свой тестовый код, я уверен, вы все равно найдете его. Заменив статические ожидания динамическими ожиданиями, можно сократить время выполнения тестов, которые зависят от медленных компонентов. Если, например, вы ввели статическое ожидание в 3 секунды, чтобы дать внешнему асинхронному компоненту время появиться перед продолжением теста, замените его динамическим ожиданием, которое непрерывно проверяет наличие компонента в DOM. В случае, если вы реализовали такое статическое ожидание на странице, результирующее сокращение времени выполнения может быть весьма значительным. Если вы спросите себя, почему вообще было реализовано статическое ожидание, то я могу дать вам простое объяснение; реализовать статическое ожидание намного проще и „быстрее“, чем реализовать динамическое ожидание. Но результат стоит затраченных усилий. 

Применение positive assertions 

Использование положительных утверждений вместо отрицательных также значительно сократит время выполнения теста. Представьте, что вы автоматизируете тестовый пример, который проверяет возможность удаления последнего товара из корзины в магазине электронной коммерции. Вы захотите подтвердить, что в корзине нет товаров. Если вы сделаете именно это и заявите, что определенный элемент отсутствует, базовая платформа автоматизации тестирования, скорее всего, перейдет в режим ожидания, пытаясь обнаружить присутствие элемента. Вместо этого попробуйте подтвердить наличие элемента, который присутствует в пустой корзине Таким образом, удается избежать тайм-аута и ускорить время выполнения тестового примера. 

Объединение тесткейсов 

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

Все это достигается за счет гранулярности. Тестовый скрипт, которому не удается добавить товар в корзину, не может быть продолжен и удалить этот товар из корзины на следующем шаге. Таким образом, неудачный тестовый сценарий приведет к пропущенным и безрезультатным тестам. 

Имейте в виду, что параллельное выполнение одновременно с комбинацией тесткейсов уменьшает потенциальный выигрыш во времени из-за увеличения времени выполнения каждого тестскрипта. 

Предотвращение закрытия браузера 

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

Выбор браузера и конфигурации 

Время инициализации, а также общая скорость в настоящее время довольно сильно различаются, если брать такие популярные браузеры как Chrome, Firefox, Safari, Edge и другими. Таким образом, выбор браузера, используемого для тестирования, также оказывает заметное влияние на время выполнения теста. Кроме того, такие опции, как Headless режим, еще больше ускоряют время инициализации. Но имейте в виду, что некоторые параметры также будут влиять на поведение браузера, что может повлиять на результат теста. 

Источник: https://www.cloudwards.net/fastest-browser/ 

Это сравнение основано на текущих версиях названных браузеров, которые постоянно совершенствуются. Чтобы получить соответствующее представление, следует периодически сравнивать время инициализации браузера. 

Примечание: Выбор браузера, очевидно, также будет зависеть от вашей стратегии кроссбраузерного тестирования. 

Использование бэкдор для выполнения предварительных условий 

Использование "бэкдор" для выполнения предварительных условий может происходить без использования браузера. бэкдор, имеющие прямой доступ к API-интерфейсам, предоставляемым серверной частью, позволяют выполнять действия, необходимые для успешного выполнения тесткейса. Если, например, вы хотите протестировать функциональность удаления товара из корзины в приложении онлайн продаж, то вам понадобится предварительно заполненная корзина в качестве предварительного условия. Обращение к соответствующему endpoint может заполнить корзину, не переходя на страницу товара и не нажимая на кнопку "Добавить в корзину". API в большинстве случаев отвечает в течение нескольких сотен миллисекунд, в то время как переход на страницу и взаимодействие с ней, скорее всего, займут несколько секунд. В некоторых случаях даже нет необходимости выполнять дополнительный шаг. Вместо этого можно открыть страницу корзины с набором параметров, определяющих добавляемые товары. Результатом является отображаемая корзина, заполненная заданными товарами, готовая к тестированию. В этом случае для выполнения требуемых предварительных условий используется существующая функциональность приложения. Это скорее короткий путь, чем использование бэкдор. 

Повторное использование сохраненных сеансов 

Если для выполнения тесткейсов требуется один и тот же набор предварительных условий, их можно сохранить и использовать повторно. Например, обычно для многих тестов требуется первоначальный вход в систему. Вместо выполнения входа в систему на этапе подготовки можно повторно использовать ранее сохраненный сеанс, содержащий успешно выполненный вход в систему. Из-за того, что сеанс хранится в браузере, эта стратегия не зависит от используемой тестовой платформы, до тех пор, пока сохраняется доступ к хранилищу сеансов браузера. Следуя этой стратегии, только первый тесткейс, требующий входа в систему, фактически выполнит вход в систему, и каждый последующий тесткейс сможет повторно использовать его, тем самым сокращая время выполнения. 

Настройка критериев сбоя 

Автор выражает благодарность своему коллеге Тобиасу Урбану за ценное замечание о том, что установка критериев сбоя также значительно повышает скорость обратной связи в случае возникновения серьезной ошибки. При настройке относительно низкого порогового значения запуск теста прерывается, когда определенное количество тесткейсов завершается неудачей, и выполнение дальнейших тестов не даст никакого дополнительного значения. Кроме того, это положительно влияет на потребление ресурсов, позволяя избежать избыточного использования вычислительной мощности. 

Примечание: хотя представленные подходы к ускорению выполнения тестов не зависят от используемых фреймворков, сами фреймворки также способны оказать значительное влияние. Однако на выбор фреймворка влияет и другие факторы, а не только скорость выполнения тестов. Существующие навыки и умения, доступность поддержки, наличная инфраструктура и так далее. не менее важны, что делает скорость выполнения лишь одним из многих факторов, которые необходимо учитывать при выборе “правильной” платформы. 

Заключение 

Существует множество возможностей значительно сократить время выполнения регрессионного тестирования интерфейса пользователя. Однако каждый из них сопряжен с определенными издержками, которые следует обдумать, прежде чем внедрять такие решения. Нахождение правильной комбинации и продуманное ее применение на самом деле может успешно сократить время выполнения обширного набора тестов с нескольких часов до нескольких минут, что позволяет использовать полный набор регрессионных тестов при сохранении быстрой обратной связи в процессе непрерывного тестирования. Тем не менее, имейте в виду, что фактическое сокращение количества выполняемых тестов, очевидно, резко сокращает общее время выполнения. Даже если это и прозвучало сомнительно - проверьте, так ли уж ценен каждый тест из вашего обширного набора?