Home

Автор: Виктор Славчев (Viktor Slavchev)

Оригинал статьи: https://mrslavchev.com/2018/03/30/hindsight-lessons-about-automation-layers-of-automation/

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

Усилия по тестированию прилагаются на различных уровнях автоматизации в приложении. Вот некоторые из них, которые я, согласно личному опыту, нахожу интересными:

• Автоматизация на юнит-уровне – она редко касается кого-либо, кроме разработчиков, и я считаю, что это правильно. В норме цель юнит-тестов – это предоставление быстрой обратной связи о правильности работы кода. Конечно, они подвержены тем же болезням, что и автоматизация в целом – "утверждающе-демонстративному" образу мышления при создании тестов. Даже если тесты используются в методологии управления через тестирование, они не особенно полезны, если сообщают только о том, что продукт работает. Фактически любой тест, который не подвергает систему суровым испытаниям с целью выявления проблем – это просто показуха.

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

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

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

• Автоматизация на уровне веб-служб. Веб-службы и API медленно набирают привлекательность для автоматизации, и о них заговорили на конференциях. Единственное, что я хочу спросить, так это почему это заняло так много времени, черт возьми? Тестирование API и служб выглядит как идеальный кандидат для автоматизации: тут используются протоколы, мы "запрашиваем" данные в определенном, жестко установленном формате, и фактически имеем дело только с данными и форматом, не связываясь с неизведанным миром презентационного уровня. Имеет прямой смысл вкладывать время в создание хорошего набора проверок сервисного уровня.

К несчастью, мало что написано о тестировании служб и API, не хватает объяснений принципов хорошего API-тестирования – как с технической точки зрения, так и с точки зрения тестирования.

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

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

Иногда нужно даже не "сгенерировать" данные – для определенных задач вполне достаточно "собрать" данные из релизного или подготовительного окружения, обфусцируя то, что нам нельзя использовать (персональные данные, почты, адреса, данные карт). Это нетрудно, очень помогает, экономит время и дает возможность сосредоточиться на значимых задачах тестирования, а не на вторичных.

• Автоматизация на уровне интерфейса. Этот тип автоматизации – заноза в заднице тестирования, и, удивительное рядом, он используется для того, чтобы затащить тестировщиков в автоматизацию. Глупо вдаваться в подробности, что это такое и как это делается, потому что любой тестировщик, пишущий в блог и умеющий писать "Hello world" на Java, пишет руководства по UI-автоматизации. Дам, однако, ряд полезных советов:
  • Инструменты записи и воспроизведения могут разочаровать вас на длинной дистанции, будьте осторожны.
  • Большая часть (9 из 10) фреймворков UI опирается на Selenium, поэтому просто изучите API.
  • Думайте о себе как о тест-разработчике, а не как о программирующем тестировщике, это вам сильно поможет.
  • Мнемоника KISS (keep it simple, silly) – не усложняйте ваши тесты сверх меры, они и так достаточно сложны.

Я еще буду говорить о UI-автоматизации в дальнейших статьях, поэтому пока достаточно (я тоже умею писать "Hello, world" на Java).

• Мобильная UI-автоматизация. У меня нет опыта подобного тестирования, но я и не планирую давать советы по ней – я просто упоминаю об этом, чтобы вы знали, что такое тестирование существует. Мобильное тестирование – это сложная штука: бороться приходится не только с кросс-браузерной совместимостью, как в веб-тестировании, но и со спецификой операционных систем разных устройств. Вам также нужно знать, как строить фреймворк, повторно использующий вашу тест-логику в двух (или более) различных база кода (Android, iOS), как взаимодействовать с различными элементами интерфейса, и т. д.

• DevOps. Если ни один из вышеперечисленных типов автоматизации вас не привлекает, то знайте, что существует целое движение, DevOps, нацеленное на получение быстрой обратной связи и автоматизацию поддающихся этому задач в деплое, разработке, тестировании, вписать нужное. Это может включать также конфигурацию и настройку окружений, управление ими, управление внешними зависимостями, непрерывную интеграцию/деплой, и другие модные современные штуковины.
• Живой мониторинг и "рука на пульсе". Это стигма тестирования на проде, и все мы виновны в том, что она все еще жива. Даже я еще недавно верил, что тестирование заканчивается, когда мы входим в прод, и тестировать на проде нельзя ни под каким видом. Это самообман: я прочитал "Тестирование микросервисов разумным путем" Синди Шридаран и узнал много всего, проходившего прямо под моим носом незамеченным.

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

Поэтому очень глупо упускать возможность протестировать его и убедиться, что мы собираем всю полезную для нас информацию. Надо только четко понимать, что мы не можем тестировать так же, как и в тестовом/подготовительном окружении – это просто другой тип тестирования. Вот что можно автоматизировать на проде:

• Тесты "пульса" – неагрессивные тесты, проверяющие, что базовые функциональности работоспособны, не оставляющие следов и не создающие значительных нагрузок.
• Работа с логами: наши системы создают множество данных и порождают множество ошибок. У нас есть выбор – мы можем все это игнорировать и ждать, пока о проблеме сообщит клиент, или следить за этим и исправлять ошибки до того, как о них узнает пользователь.
• Визуальное тестирование. Визуальные дефекты – это зачастую мелочи, однако крупные проблемы отображения отвратительно смотрятся на проде. Представьте, что главная страница Nike грузится с битой картинкой? Или без стилей? Это уродливо и непрофессионально, и именно так выглядим мы, если допускаем, что подобное происходит с нашими клиентами. Мы легко можем применить автоматизацию для простого сравнения изображений, чтобы проверить стили, разметку, визуальные компоненты и удостовериться, что они смотрятся как надо.

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

Этот список предназначен для перечисления возможностей, которыми могут воспользоваться автоматизаторы, заинтересованные в тестировании с точки зрения программирования. Автоматизация – это не только тестирование через UI или Selenium. При ее помощи можно сделать массу интересных вещей.

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

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