Home

Материал подготовлен компанией SimbirSoft

Оригинальная публикация

О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (Kristin Jackvony), где графически показан еще один метод – колесо автоматизации. 

Автоматизация тестирования, как правило, наиболее необходима в масштабных приложениях с большим количеством бизнес-функций, при внедрении CI/CD и регулярных релизов. Подробнее об этом мы рассказывали в статье «Что даёт автоматизация тестирования».

С разрешения Кристин Джеквони – автора блога Think Like a Tester и ряда популярных материалов о тестировании – мы перевели статью «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel). В конце статьи рассмотрим пример проверок из практики наших специалистов по автоматизации тестирования (SDET).

Каждый, кто занимался автотестами, слышал о Пирамиде автотестов. Обычно она имеет три слоя: тесты UI, API и Unit. Нижний слой, самый широкий, занимают Unit-тесты – это означает, что таких тестов должно быть больше, чем прочих. Средний слой – это API-тесты; идея в том, что их нужно запускать меньше, чем Unit-тестов. Наконец, верхний слой – это UI-тесты. Их должно быть меньше, чем остальных, т.к. они требуют больше времени на прохождение. Кроме того, UI-тесты наиболее нестабильные.

Пример пирамиды автотестов на Хабре. Метод описан в книге Майка Кона «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).

С моей точки зрения, в этой пирамиде две проблемы:

• описывает далеко не все типы автотестов;
• говорит о том, что именно количество тестов – лучший индикатор качества тестового покрытия.

Я предлагаю другой подход к автоматизированному тестированию – Колесо автоматизации.



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

Unit-тесты (Unit Tests)

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

• с аргументом 0 метод возвращает True;
• с аргументом 1 метод возвращает False;
• со строковым аргументом метод возвращает ожидаемую ошибку.

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

Компонентные тесты (Component Tests)

Эти тесты проверяют разные сервисы, от которых зависит код. Например, если мы используем API GitHub, то можно написать компонентный тест для проверки того, что запрос на данный API получает ожидаемый ответ. Или это может быть просто пинг до сервера, проверка доступности базы данных. Должен быть хотя бы один компонентный тест на каждую используемую в коде службу.

Примечание: например, у нас в SimbirSoft к компонентным тестам, помимо проверки ответов сторонних сервисов, относятся проверки модулей одной системы, если её архитектура представляет собой набор таковых.

Сервисные тесты (Services Tests)

Такие тесты проверяют доступность веб-сервисов, к которым обращается приложение. Чаще всего работа с ними организована через использование API запросов.

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

Тесты пользовательского интерфейса (User Interface Tests, UI Tests)

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

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

Визуальные тесты (Visual Tests)

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

Тесты безопасности (Security Tests)

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

Примечание: с сервисными тестами эти проверки роднит только способ вызова служб – через http-запросы. Цель таких тестов – исключительно в проверке защищенности системы и пользовательских данных от действий злоумышленника.

Тесты производительности (Performance Tests)

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

Тесты доступности (Accessibility Tests)

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

Как выбрать методы проверки

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

После выхода статьи «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel) вышел список факторов, помогающих определить необходимую долю тестов каждого типа в колесе автоматизации:

• От какого количества сторонних сервисов зависит ваше приложение? Если таких сервисов много, нужно больше компонентных тестов.
• Насколько сложен ваш пользовательский интерфейс? Если он содержит всего одну или две страницы, вам потребуется меньше тестов пользовательского интерфейса и визуальных тестов.
• Насколько сложна ваша структура данных? Если вы имеете дело с большими объектами данных, вам потребуется больше API-тестов для проверки правильности обработки операций CRUD (Create, Read, Update, Delete).
• Насколько безопасным должно быть ваше приложение? Приложение, которое обрабатывает банкинг, будет нуждаться в гораздо большем количестве тестов безопасности, чем приложение, которое сохраняет фотографии котят.
• Какой должна быть производительность вашего приложения? Игра в пасьянс не обязательно должна быть такой же надежной, как кардиомонитор. Соответственно, от этого критерия зависит процент тестов производительности.

Преимущество колеса автоматизации [в сравнении с пирамидой тестирования] заключается в том, что оно может быть адаптировано ко всем типам приложений. Рассматривая каждую спицу в колесе, мы будем уверены, что создаем надежное автоматизированное тестовое покрытие. И наоборот: как невозможно полагаться на велосипед при отсутствии спиц в колесе, так нельзя полагаться и на автоматизацию в CI/CD, если вы не уверены в том, что все аспекты системы покрыты автотестами.

Из практики SimbirSoft

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

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

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

• Unit Tests

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

• Component Tests

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

• Services Tests

Мы проверяли API, через которое в предыдущем примере отправляются запросы к базе данных. Отправляли GET-запрос на получение номера расчетного счета и проверяли ответ на него. Обязательно отправляли какой-либо некорректный запрос, например, с несуществующим id клиента, и проверяли, что ответ соответствует ожидаемому.

• UI Tests

Например, мы проверили корректную реакцию системы на заполнение полей счета, а также ответ системы на нажатие кнопки «Открыть вклад».

• Visual Tests

Мы протестировали устройства с разными версиями iOS и Android и диагональю экрана и проверили расположение элементов приложения. Эта проверка была нужна, чтобы убедиться, что при любом сочетании этих параметров кнопки не наезжают на логотип и не скрываются за ним, становясь недоступными для нажатия.

• Security Tests

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

• Performance Tests

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

• Accessibility Tests

Проверили голосовой поиск и отображение элементов разметки с активированным режимом для слабовидящих.

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

Спасибо за внимание! Надеемся, что перевод был вам полезен.

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