Home

Автор: Мэтью Хессер (Matthew Heusser)

Оригинал статьи: http://techbeacon.com/8-ways-rev-your-app-testing

Перевод: Ольга Алифанова

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

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

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

1. Выкиньте лишние операции из GUI-тестов

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

Эти операции понадобятся и где-нибудь еще; они тут совершенно лишние. Добавьте установочные функции, чтобы быстро подготовиться к тесту, или заведите образцовую базу данных для тестов (мы еще поговорим об этом).

Наше следующее решение – сдвинуть эти тесты на уровень API.

2. Сдвиньте бизнес-логику к интеграционным тестам API

По сравнению с фронт-эндом веба, микросервисы и другие API достаточно прочны, вряд либудут меняться, и еще они очень быстрые. В отличие от других юнит-тестов, которые редко влияют на пользователя, API-тесты обычно могут быть выражены так, что их поймет пользователь, и могут быть привязаны к действиям пользователя. К примеру: ожидаем такого-то результата с учетом пользователя с этим типом данных и особого ввода данных.

С поиском это вообще проще некуда – заведите базу данных с известными заранее подготовленными данными, запустите поиск, ожидайте результатов. Храните запрос и ожидаемые результаты там, куда есть доступ у людей бизнеса и технарей – возможно, на том же уровне, что и GUI-тесты – и у вас будет исполняемая спецификация.

Эти тесты будут запускаться без старта браузера, ввода логина и пароля, клика на подтверждении, заполнении страницы поиска, и запуска любого JavaScript.

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

3. Создайте базу данных с образцами

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

Вместо этого я предпочел полезные функции, позволяющие экспортировать и импортировать базу данных. Если у вашего ПО есть такие сущности, как «учетная запись» или «группа», то вам может пригодиться экспорт части базы данных – возможно, всех пользователей этой учетки или группы. В дополнение к тестируемости, это также позволяет быстрое сохранение и восстановление, тестируемое автоматически, каждый спринт, самим тест-процессом.

Если тесты создают информацию – пользователей или заказы – возможно, можно экспортировать конечный результат и сравнить его с другой базой данных известных результатов при помощи функции «diff». Дифференцирование целой базы данных после прогона тестов может найти скрытые дефекты, которые тестировщики и не думали искать.

Импорт и экспорт заведомо «хороших» данных также позволяет ускорить настройку системы.

4. Ускорьте или избавьтесь от настройки и демонтажа.

Серьезная настройка и демонтаж между тестами – очень популярная идея. При условии небольших тестов и отсутствии «кровотечений» между ними ожидаемый результат легко определить, и дебаг проходит без проблем.

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

Самый простой способ ускорить настройку – это вообще ее не проводить, помечая ряд тестов как «только для чтения». Тест-фреймворк может прогнать любой тест, следующий за таким отмеченным тестом, без демонтажа или настройки.

Другой способ пропустить настройку – это создание пользовательских сегментированных учетных записей. К примеру, если тесту нужна запись данных, начните с создания учетной записи по имени «название_теста%%дата_время%%». Временная отметка даст вам уникальность учетки, и пока учетки не могут видеть данные друг друга, следующему тесту не потребуется демонтаж и настройка.

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

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

5. Оптимизируйте результаты клиентского браузера

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

Рассматривая самую первую, наиболее глубокую петлю тест-процесса, подумайте о запуске браузера без интерфейса. Браузер без интерфейса полностью контролируется программой и не создает пользовательский интерфейс.

Альтернатива запуску браузера без интерфейса – создание видео прогона теста. Это не ускорит выполнение теста, но уж точно ускорит дебаг! Видео-стратегия обычно приносит ценность на другом конце петли обратной связи – при ночных прогонах.

6. Устраняйте неприятные периоды ожидания

Ожидание появления элементов – классическая проблема тестирования пользовательских интерфейсов. Ленивый подход – заложить в код жесткое ожидание, что-то между 15 и 30 секундами. Когда эти тесты упадут (а они упадут), тестировщик просто удваивает время ожидания.

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

У большинства современных инструментов есть методы wait_for_element_present_ok method, или wait_for_page_load, или способность построить подобные методы внутри существующего тест-фреймворка. Боритесь за эту способность или терпите гигантское время прогона и ложноотрицательные результаты.

Куртис Петит, ведущий тестировщик и консультант, напомнил мне, что wait_for_element_present_ok и схожие методы могут быть закодированы как-нибудь так:

while (timeNotExpired) {
If (condition) return true;
else recalcTime;
} return false;

Построить такую функцию на чем-нибудь вроде JavaScript довольно легко. Единственный вопрос, поддерживает ли фреймворк поиск по условию.

7. Получайте преимущество от тегов

Когда я работал в Socialtext, системные GUI-тесты были выражены в форме wiki-страничек. Каждая страница могла быть помечена: к примеру, у нас были «тесты солнечного света», «тесты базы данных», «поисковые тесты» и «профильные тесты».

Тесты также размечались по браузерам, так как IE и Safari не поддерживали все функции наших инструментов. Тесты солнечного света прогонялись примерно полчаса и давали базовое покрытие всего приложения. Профильные и поисковые тесты также прогонялись быстро и давали глубокое покрытие специфической области. Тэги можно комбинировать – к примеру, запустить все поисковые тесты для IE, или все профильные тесты для Firefox.

Описание тестов при помощи тэгов (меток) позволяет программистам писать разумные запросы на то, какие тесты запустить, и это дает нам наиболее приемлемое покрытие за минимум времени.

8. Запускайте тесты параллельно на нескольких клиентах

И, напоследок, мы дошли до параллельности тестов.

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

Запуск параллельных тестов означает использование публичного или частного облака. Частное облако позволит запуск 10-20 одновременных тестов. Запуск 100 одновременных тестов на одном веб-сервере, скорее всего, приведет к временным проблемам и проблемам дебага. Тесты, не предназначенные для одновременного запуска, будут портить данные друг друга, и это приведет или к плохо написанным тестам, или – что более вероятно – большому труду по их переписыванию и пересмотру, чтобы они могли работать параллельно.

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

Полная картина

Основная стратегия, которую я предлагаю – тестировать меньше, избавляться от лишних тестов, ускорять элементы тест-прогона. Запускайте минимальное количество возможных тестов для быстрой обратной связи – до и после коммита – затем более крупный набор несколько раз в день, и полный набор ночью.

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

Не думайте об этом как о цели. Думайте об этом, как о направлении, делая шаг за шагом.

Обсудить в форуме