Gui Тесты занимают слишком много времени - каков ваш подход?

Question

У нас есть типичный стек веб-приложений. есть 120 тестов селена (webdriver), которые выполняются против приложения. это занимает около 1 часа. мы выполняем их как часть нашей сборной цепочки «компилируем» модульный тест> интеграционный тест> тесты gui ». тесты gui занимают много времени, и нам интересно, как их лучше структурировать. в настоящее время они являются «счастливыми случаями и несчастными». они довольно стабильны, то есть они не сбой из-за ошибок программиста.

Мы хотим получить время сборки вниз, а самая большая часть - тесты gui. мы хотим сделать это на основе «поездок клиентов», то есть указать (вместе с деловыми людьми) некоторый типичный пример использования и проверить их (счастливый путь) вместо тестирования слишком много .....

как вы, ребята, структура ваши тесты gui? вот некоторые идеи, которые пришли на мой взгляд

• выполнять только счастливый путь испытаний
• сделать «тест путешествие клиента», то есть сделать несколько счастливых испытаний пути в одном («веб-страниц»)
• только брать «10 лучших», указанных в бизнес-(критически важные)
• топ-10 + «все прочие», как ночные сборки (один раз)

я был бы признателен ваши идеи

благодаря Marcel

Answer 1

Ночное идеальное время для Selenium тестов - вы просто должны помнить, чтобы положить «Не превращайте меня!» липкая заметка на вашем компьютере :).

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

У нас есть несколько тестов suites, которые применимы к различным ситуациям. Перед крупным выпуском (для тестирования, для предварительной работы, для производства) все работает. Обычно (ежедневно или даже ежечасно в часы пик) запускается только пакет «Ускоренный нормальный путь пользователя через приложение». И если кто-то «исправляет» большую ошибку, тогда выполняются тесты, связанные с этой частью приложения.

Answer 2

. Час кажется мне совершенно прекрасным.

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

С учетом сказанного, наш занимает около 2 часов - единственная проблема возникает, когда один тест потерпел неудачу, вы исправили его, зафиксировали, но затем должны ждать очень долгое время, чтобы проверить, что он установлен на сервере CI.

Answer 3

TeamCity позволяет запускать сборки параллельно на одной машине, поэтому тесты gui не должны быть в цепочке сборки вместе с модульными и интеграционными тестами. Тесты пользовательского интерфейса должны иметь отдельную базу данных и отдельную сборку, чтобы они не теряли времени для разработчиков или ручных тестеров или любых других заинтересованных сторон. TeamCity будет собирать всю статистику, отправлять электронную почту по сбоям сборки и так далее.
Следующий шаг - распараллеливание.Как Slanec сказал, что вы можете использовать Grid (несколько машин не обязательно) с Mbunit (C#) или TestNG (java). С помощью Grid вы можете уменьшить время выполнения тестов, например. в 10 раз, поэтому для выполнения всех ваших тестов потребуется всего 6 (!) мин.
Также вы можете комбинировать некоторые из ваших тестов в больших (но это приведет к увеличению времени, чтобы обнаружить причины сбоя и затруднить выполнение тестов).
После этих шагов тесты Gui могут быть выполнены после каждого фиксации источника и обеспечения быстрого ответа на состояние ошибок приложений.

Answer 4

Большой вопрос, отличные ответы.

Дополнительное соображение состоит в том, что вы можете расставить приоритеты в тестах 120 gui: вы можете запускать их в таком порядке, чтобы сначала выполнялись самые важные или те, которые с наибольшей вероятностью потерпят неудачу. Это не поможет сократить время сборки, но это поможет быстрее получить полезную обратную связь от сборки.

Эта приоритизация (ваши лучшие 10) не обязательно должна быть исправлена, но может быть изменена за выпуск/итерацию/завершенную историю/день и т. Д. Например, вы можете сначала запустить новейшие тесты gui. Или те, которые были изменены совсем недавно. Или те, которые охватывают большую часть кода, который был недавно изменен.

Невозможно наладить и ускорить разработку, насколько я знаю, хотя в области определения приоритетности теста есть довольно некоторые (академические) исследования.