Мысле трекер
Модульное, компонентное и юнит-тестирование
Reported at 15.05.2011
Молодость сферы тестирования приводит к тому, что многие термины различными людьми, организациями, книгами, статьями трактуются по-разному.
Модульное, компонентное и unit-тестирование — наглядный пример этой неразберихи.
«Да какая разница, как что называть, главное — правильно использовать!» — можете обоснованно сказать вы. Да! Именно так! Но чтобы знать, как что-то использовать, необходимо и знать о наличии такой техники, и иметь возможность найти краткий инструктаж.
Если в вашем проекте требуется (или полезно, или жизненно необходимо, или «было бы неплохо») модульное или компонентное тестирование, а вы никогда с ним не сталкивались, то вероятность найти подходящую информацию минимальна.
И самое страшное: осознать необходимость в использовании того или иного подхода, заранее о нём не зная, невозможно!
Я часто цитирую Абрахама Маслоу:
«Если в вашем распоряжении есть только молоток, то любая проблема покажется гвоздём».
В тестировании есть много инструментов, и чтобы уметь выбирать правильный, и уметь комбинировать подходы, вам нужно запастись целым набором инструментов. 
Давайте разберёмся, что такое модульное, компонентное и юнит-тестирование?
Глоссарий ISTQB даёт нам следующие определения:
Модульное тестирование (module testing, unit testing): см. компонентное тестирование
Компонентное тестирование (component testing): тестирование отдельных компонентов программного обеспечения (согласно IEEE 610)
Компонент (component): Наименьший элемент программного обеспечения, который может быть протестирован отдельно.
Выводы, которые можно сделать из этого глоссария: компонентное, модульное и unit тестирование — одно и то же. Так ли это?
Если попытаться найти определения словам «компонент» и «модуль» (а главное, отличия между ними), вы рискуете сойти с ума. Главным принципом компонентно-ориентированного программирования называют модульность, а Component diagram в UML чаще всего переводят как диаграммы модулей.
Общие понятия компонентно-ориентированного программирование изложены на вики, там же можно почитать про модульность.
Нас же будет интересовать более общее определение слов:
Компонент — (от лат. componens, родительный падеж componentis — составляющий), составная часть, элемент чего-либо.
Давайте на основании него введём определение компонентного тестирования: это тестирование составных частей программного комплекса по отдельности, изолированно.
Какими могут быть эти самые составные части? К примеру, у нас есть интернет-портал. На нём есть новостная лента, статьи и форум. И форум, и блок статей можно назвать отдельными компонентами — составными частями нашего продукта. При этом, и на форуме, и в CMS мы можем подключать отдельные модули, которые будут являться компонентами по отношения к родителям. Получается, компоненты могут иметь различные уровни вложенности. И отдельный класс, входящий в состав одного из модулей, тоже будет являться компонентом нашей системы.
При этом, компоненты всех уровней «общаются» между собой. Способы общения можно назвать интерфейсами, а взаимодействие компонентов — интеграцией.
Какие возможны «языки» для общения, интерфейсы? Это могут быть записи в БД, вызовы сервисов с различными параметрами, API, и даже файлики. Через XML-формат различные RSS-клиенты собирают информацию по множеству заданных источников — хороший пример интеграции независимых приложений.
А зачем вся эта ботва нужна ручному тестировщику?
Здесь начинается самое интересное. И вправду, как и когда нам нужно использовать компонентное тестирование?
Use-case #1: Затяжная разработка
Продукт начали разрабатывать в марте, а выйти в релиз планируется в сентябре. Первые сборки для тестирования появились в июле, но были неработоспособными. К августу появилась более-менее стабильная сборка, к сентябрю было заведено полтысячи дефектов. Руководство бегает в панике, разработчики пытаются вспомнить, что они там накодили в апреле, а тестировщики возмущаются плохому качеству. Хотя, вместо ковыряния в носу с марта по июль, они уже могли начать компонентное тестирование.
А как, если я не разработчик?
На самом деле, если вы хоть немного разработчик, то решение задачи компонентного тестирования пойдёт значительно лучше. Но если знаний не хватает, то всегда можно договориться с разработчиками об обеспечении testability отдельным компонентам: к примеру, создать простенький интерфейс, GUI или через cmd.
Use-case #3: Всем выйти из сумрака!
Зачастую пользователь через интерфейс не может сделать весь функционал, который реализован в продукте. Если где-то «внутри» есть баги, это ещё не баги продукта (пользователь столкнуться с ними не может). Но это повышенный риск их возникновения: в любой момент ограничения в UI будут сняты, и пользователь «поймает» ошибку.
Посмотрим простой пример: у нас на сайте есть форма регистрации, сохраняющая данные о пользователе в БД. После этого эти данные обрабатываются множеством компонентов системы. В форме регистрации есть ограничения на какие-либо поля, и мы не можем ввести больше, чем n символов. Зато, мы можем ввести их напрямую в БД, если её структура позволяет. Как поведёт себя система в этом случае? Записать данные в БД и проверить работу отдельных компонентов бывает особенно полезно, если поставщиком информации является не часть нашей системы, а какое-либо внешнее приложение.
Ну и последнее:
А что тогда такое unit-тестирование?
Это, пожалуй, единственный термин, который обзавёлся общепринятым значением. Юнит-тестами называют проверки отдельных классов нашего приложения, и это техника белого ящика. Так как классы тоже попадают под определение «составная часть, элемент чего-либо», то можно сказать, что юнит-тестирование — это разновидность компонентного тестирования, чаще всего выполняемая (а ещё точнее — чаще всего НЕ выполняемая) разработчиками.
Что такое компонентные тесты, и каково быть SDET’ом
Статья рассказывает о нетрадиционном, но полезном виде тестов, а также подводит итоги семилетней работы в разработке тестов.
Ведь есть, скажем, юнит-тесты, которые подробно тестируют потроха компонентов. Они досконально проверяют, что компонент работает в соответствии с замыслом разработчика. Но часто это проверка «пуговиц», а не того, как сидит костюм в целом. И не всегда поведение, задуманное программистом, совпадает с тем что хотел заказчик.
А еще есть, например, приемочные тесты. И они устраняют все указанные недостатки. Но, к сожалению, вносят новые. Они медленные, часто нестабильные, и обычно ручные. При этом они только свидетельствуют о проблеме, но не локализуют ее.
Очевидно, что напрашивается необходимость промежуточных тестов, которые станут золотой серединой между тестами модульными и приемочными. Этой серединой могут стать компонентные тесты.
Что такое компонентные тесты?
Это тесты на публичный API компонента. Соответственно, они пишутся на том же языке, что и компонент. Задача тестов:
Очевидно, что компонентные тесты имеют смысл, когда у вас есть выделенные компоненты с обширным интерфейсом. Например, динамическая библиотека или COM-объект. Тогда компонентные тесты дадут максимальный эффект.
Плюсы к-тестов:
Минусы к-тестов:
Резюме 1
Компонентные тесты хороши, но только если для них у вас есть все условия: широкий публичный API, правильный workflow, и подходящие люди в команде.
Каково быть SDET’ом?
Очевидно, что SDET — Software Development Engineer in Test — идеальный кандидат на написание компонентных тестов. Он умеет писать код, и умеет мыслить тестами. Он же обеспечивает второе мнение, что тоже повышает качество тестов и кода. Все это звучит интересно и заманчиво — возможно, вам уже хочется им быть. Здесь я тезисно расскажу, чем работа SDET’а отличается от работы чистого разработчика.
Плюсы работы SDET’ом:
Минусы работы SDET’ом:
Резюме 2
Как человек, который много лет работал разработчиком, потом на несколько лет ушел в SDET’ы, а затем снова вернулся в разработку, могу сказать следующее.
Я очень рекомендую провести SDET’ом хотя бы год-другой. Это весьма полезный опыт для любого разработчика. Но задерживаться там, на мой взгляд, не стоит.
От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте
О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали на Хабре. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (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-тесты:
Компонентные тесты (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) вышел список факторов, помогающих определить необходимую долю тестов каждого типа в колесе автоматизации:
Из практики SimbirSoft
Мы считаем, что колесо автоматизации – полезный способ визуализации типов тестирования. Безусловно, мы давно используем описанные тесты, но картинка помогает проанализировать покрытие системы и держать всё перед глазами.
Если у вас отлажен процесс тестирования и вы регулярно прогоняете автотесты, это минимизирует риск попадания дефектов в продакшен. К тому же, автотесты помогают оперативно выявлять проблемы, которые могут возникнуть в процессе работы системы. Например, с помощью планового ежедневного прогона автотестов можно контролировать свой сайт, чтобы защитить себя от взломов.
Какие использовать проверки и в каком количестве – зависит и от требований, и от самой проверяемой системы. Так, в одном из наших продуктов – банковском мобильном приложении – по требованию клиента были подготовлены автотесты всех перечисленных ранее видов. Рассмотрим их примеры далее.
Unit Tests
Мы позаботились о том, чтобы каждая функция в коде приложения была покрыта тестами, проверяющими все возможные пути. При этом активно использовали моки, заменяющие собой другие части системы. Например, проверяя функцию конвертации рублей в валюту, мы подавали на вход функции поддерживаемые ей рубли, чтобы проверить, что на выходе получим валюту. Сравнение происходило с эталонными величинами. Также проверяли реакцию функции на невалидные данные.
Component Tests
Здесь мы проверяли компоненты мобильного банка. Так как у нас микросервисная архитектура, нужно было проверить доступность всех микросервисов, а также, как пример, доступность базы данных. Для сервиса, ответственного за расчетные счета клиента, мы выполняли запрос к базе данных для получения расчетного счета и проверки того, что счет может быть получен.
Services Tests
Мы проверяли API, через которое в предыдущем примере отправляются запросы к базе данных. Отправляли GET-запрос на получение номера расчетного счета и проверяли ответ на него. Обязательно отправляли какой-либо некорректный запрос, например, с несуществующим id клиента, и проверяли, что ответ соответствует ожидаемому.
UI Tests
Например, мы проверили корректную реакцию системы на заполнение полей счета, а также ответ системы на нажатие кнопки «Открыть вклад».
Visual Tests
Мы протестировали устройства с разными версиями iOS и Android и диагональю экрана и проверили расположение элементов приложения. Эта проверка была нужна, чтобы убедиться, что при любом сочетании этих параметров кнопки не наезжают на логотип и не скрываются за ним, становясь недоступными для нажатия.
Security Tests
Мобильный банк – финансовая система, поэтому его безопасность нужно было обеспечить на всех уровнях. В числе прочего мы проверяли аутентификацию только по правильным данным на уровне пользовательского интерфейса и получение информации только в ответ на запрос с корректным токеном на уровне сервисов.
Performance Tests
Одним из тестов было сравнение с эталоном времени ответа сервера на запрос приложения. Также мы проверили работу приложения при максимально ожидаемом количестве одновременно работающих пользователей в системе.
Accessibility Tests
Проверили голосовой поиск и отображение элементов разметки с активированным режимом для слабовидящих.
О том, как можно организовать автоматизацию тестирования с нуля, мы расскажем подробнее в одной из следующих статей.
Спасибо за внимание! Надеемся, что перевод был вам полезен.
Уровни тестирования программного обеспечения
Тестирование на разных уровнях производится на протяжении всего жизненного цикла разработки и сопровождения программного обеспечения. Уровень тестирования определяет то, над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом. Проведение тестирования на всех уровнях системы — это залог успешной реализации и сдачи проекта.
Уровни Тестирования
1. Компонентное или Модульное тестирование (Component or Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks — каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System).
Один из наиболее эффективных подходов к компонентному (модульному) тестированию — это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-driven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор, пока все тесты не будут успешно пройдены.
Разница между компонентным и модульным тестированием:
По-существу, эти уровни тестирования представляют одно и тоже и разница лишь в том, что в компонентном тестировании, в качестве параметров функций, используют реальные объекты и драйверы, а в модульном тестировании — конкретные значения.
2. Интеграционное тестирование (Integration Testing)
Интеграционное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
Уровни интеграционного тестирования:
Подходы к интеграционному тестированию:
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сначала тестируются все высокоуровневые модули, затем постепенно, один за другим, добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем, по мере готовности, они заменяются реальными активными компонентами. Таким образом, мы проводим тестирование сверху вниз.
Все (или практически все) разработанные модули собираются вместе в виде законченной системы или ее основной части, а затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако, если тест-кейсы и их результаты записаны неверно, то сам процесс интеграции будет осложнен, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
3. Системное тестирование (System Testing)
Можно выделить два подхода к системному тестированию:
4. Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing)
Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing) — формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
Приемочное тестирование выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению.
Решение о проведении приемочного тестирования принимается, когда:
Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.
Схема классификации тестирования:
Рис. 2.2. Схема, на которой все способы классификации показаны одновременно
Уровни тестирования
Существует 4 уровня тестирования [1]:
В этой статье разберемся что такое уровни тестирования, зачем они нужны и что собой представляет каждый из них.
Начнем с простого примера.
Давай вспомним, что такое конструктор LEGO.
Это набор разноцветных деталей разной формы и размеров, которые после «магического» соединения превращаются в прикольную игрушку.
Обычно, процесс сборки игрушки выглядит так:
Программное обеспечение очень похоже на такой конструктор.
Но оно намного круче, ведь мы сами можем создавать любые детали и использовать детали (и даже блоки), созданные другими людьми (привет Open Source) 😉
Если посмотреть на процесс сборки с точки зрения тестирования, его можно описать так:
Суть процесса проста: проверка любой системы (будь то конструктор LEGO или мобильное приложение) начинается с ее наименьших элементов и двигается в сторону их объединения / увеличения до максимального размера.
Благодаря этому подходу ты никогда не попадешь в ситуацию, когда «колеса не того размера», «двери не от той машины» или «мы хотели самолет, а получили вертолет, платить не будем» 🙂
Теперь ты осознаешь уровни тестирования, но для эффективной работы этого недостаточно. Давай разбираться глубже)
Что такое уровень тестирования?
Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.
К характеристикам относятся:
Перед тем, как мы перейдем к рассмотрению каждого конкретного уровня и его характеристик, давайте рассмотрим реальный пример этапов тестирования ПО, который поможет нам совместить теорию и практику.
Пример реальной задачи по разработке
Предположим, перед вашей командой ставят задачу:
Создать страницу Contact Us на сайте Х. После отправки формы отдел поддержки должен получить Email, содержащий введенные данные и контактную информацию клиента.
Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)
Первым делом разработчики прорабатывают дизайн системы.
Он может представлять собой следующую схему:
Дизайн системы Contact Us
Далее, разработчики детализируют схему добавляя описание шагов:
* логика проверки (валидации данных) опущена для упрощения схемы. Но, это не означает, что ее нет!
** логика отправки Email опущена для упрощения схемы
Имея требования к странице, описание дизайна и логики работы, проект переходит на этап разработки. Разработчики начинают писать код, а тестировщики могут приступать к продумыванию тестов.
Как ты уже знаешь, процесс начинается с наименьших частей системы — модулей / компонентов.
Модульное / Компонентное / Unit тестирование
Модульное / Компонентное / Unit тестирование фокусируется на компонентах / модулях, которые должны быть проверены в изоляции, как самостоятельные, независимые блоки.
Module / Component / Unit testing: A test level that focuses on individual hardware or software components [ISTQB Glossary]
Характеристики модульного тестирования
Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок
Объект: модуль / компонент / unit
Базис: дизайн системы, код, спецификация компонента
Типичные ошибки: ошибка в реализации требований, ошибка в коде
Ответственный: разработчик (редко тестировщик)
На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях. Эти проверки всегда автоматизированы и выполняются очень быстро (несколько тысяч тестов в минуту).
Unit тесты, кроме поиска ошибок, также помогают оценивать качество кода, измерять покрытие кода тестами, сокращать время и затраты на тестирование.
Продолжая рассмотрение примера со страницей сайта, мы можем выделить следующие модули:
Для примера, рассмотрим модуль «страница Contact Us».
Требования:
В свою очередь, требования к модулю «Contact Us Controller»:
Все описанные выше требования должны проверяться Unit тестами.
Когда проверки компонентов закончены и мы уверены, что модули по отдельности работают как ожидалось, можем переходить на следующий уровень.
Интеграционное тестирование
Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / под-системами / системами.
Выделяют 2 подтипа:
Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. [ISTQB Glossary]
Component integration testing. Testing performed to expose defects in the interfaces and interaction between integrated components. [ISTQB Glossary]
System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet). [ISTQB Glossary]
Характеристики интеграционного тестирования
Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы
Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы
Базис: дизайн системы, архитектура системы, описание связей компонентов
Типичные ошибки: отсутствие / неправильные связи между элементами системы, неправильные передаваемые данные, отсутствие обработки ошибок, отказы и падения при обращениях к API
Ответственный: разработчик и тестировщик
Системные интеграционные тесты выполняются дольше (несколько десятков в минуту), чем модульные интеграционные тесты (несколько сотен-тысяч в минуту) и являются более творческими.
Продолжим рассмотрение примера.
Теперь, обратим внимание на связи между компонентами / под-системами:
Интеграционное тестирование
Начнем с компонентного интеграционного тестирования.
Обрати внимание на стрелки 5 и 7.
Они описывают связь между компонентами Contact Us Controller и Email Sender внутри под-системы Backend.
Contact Us Controller обращается к Email Sender с запросом для отправки Email сообщения (5), Email Sender отправляет письмо (6) и отвечает Contact Us Controller что все прошло удачно (7). Если при отправке (6) произошла ошибка, в ответе (7) вернется информация об ошибке.
В нашем случае интеграционные тесты проверят, что описанный выше процесс работает и что модуль Contact Us Controller инициирует отправку Email сообщения, а не SMS.
Тестирование интерфейсов (частично) и тестирование API являются примерами интеграционного компонентного тестирования.
В случае с тестированием API мы «имитируем» запрос от клиента — (3) и анализируем ответ сервера — (9), таким образом проверяя интеграцию всех задействованных модулей для конкретного API Endpoint внутри Backend.
Interface Testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB Glossary]
API testing. Testing performed by submitting commands to the software under test using programming interfaces of the application directly. [ISTQB Glossary]
Далее посмотрим на системное интеграционное тестирование.
Обрати внимание на стрелки 3 и 9.
Они описывают связь между двумя под-системами: Frontend, который формирует и отправляет запрос со страницы Contact Us с данными формы, и Backend, который обрабатывает и реагирует на запрос.
Тестирование на этом уровне показывает, что интеграция под-систем реализована в соответствии с заявленными требованиями.
В нашем случае для проверки правильности достаточно написать 1 тест: отправить форму Contact Us с ожидаемым результатом в виде показанного сообщения об успешной отправке — (10) и полученного Email сообщения с данными, оставленными с формы Contact Us.
Теперь, когда мы проверили интеграции компонентов внутри под-систем и интеграции под-систем, мы можем двигаться дальше.
Системное тестирование
Системное тестирование фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.
Внимание уделяется задачам, на решение которых направлена система. Также во внимание берется нефункциональное поведение системы (скорость работы, нагрузка, и т.п.) при выполнении бизнес-задач.
Системное тестирование может проверять выполнение стандартов или законодательных / нормативных требований.
Тестовая среда для системного тестирования должна быть максимально приближенной (в идеальном варианте — идентичной) к окружению для эксплуатации (production).
System testing The process of testing an integrated system to verify that it meets specified requirements. [ISTQB Glossary]
Характеристики системного тестирования
Цель: проверка работы системы в целом
Объект: система, конфигурации системы, рабочее окружение
Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции
Типичные ошибки: невозможность выполнять функциональные задачи, для которых создавалась система, неправильная передача данных внутри системы, неспособность системы работать правильно в среде эксплуатации, нефункциональные сбои (уязвимости, зависания, выключения)
Ответственный: тестировщик
Системное тестирование для нашего примера может включать в себя такие типы тестирования:
Системное тестирование системы Contact Us
* слово «тестирование» — убрано с изображения для упрощения 🙂
Помимо проверки отправки формы Contact Us, получения Email сообщения на почту суппорта и показа Success сообщения, в ходе системного тестирования мы должны ответить на вопросы:
На этом уровне тестирования создаются end-to-end тесты, имитирующие бизнес процессы, Use Cases и Use Stories от начала до конца.
Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п. — все здесь).
E2e тесты очень медленные (обычно 5-10 тестов в минуту) и коварные, с их автоматизацией нужно быть очень осторожным 😉
Системное тестирование — одна из самых творческих и объемных областей тестирования. Кроме end-to-end (e2e) тестирования, к этому уровню относятся все виды нефункционального тестирования.
Очень часто начинающие тестировщики видят только одно направление развития: автоматизация.
Но на самом деле направлений много.
Именно в системном тестировании можно развиваться бесконечно, становясь профессионалом в нагрузочном тестировании, юзабилити, тестировании безопасности, производительности и т.п. Конечно, автоматизация не помешает, но не все любят и хотят программировать 🙂
End-to-End Testing A type of testing in which business processes are tested from start to finish under production-like circumstances. [ISTQB Glossary]
После завершения тестирования всей системы нас ждет последняя проверка перед сдачей работы.
Приемочное тестирование
Приемочное тестирование фокусируется на готовности всей системы в целом.
Существуют несколько форм приемочного тестирования:
Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.
Контрактное приемочное тестирование — проводится в соответствии с критериями, указанными в контракте приемки специального ПО.
Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов.
Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.
Бета-тестирование проводится реальными пользователями системы.
Acceptance testing A test level that focuses on determining whether to accept the system. [ISTQB Glossary]
User acceptance testing (UAT) A type of acceptance testing performed to determine if intended users accept the system. [ISTQB Glossary]
Contractual acceptance testing A type of acceptance testing performed to verify whether a system satisfies its contractual requirements. [ISTQB Glossary]
Alpha testing A type of acceptance testing performed in the developer’s test environment by roles outside the development organization. [ISTQB Glossary]
Beta testing A type of acceptance testing performed at an external site to the developer’s test environment by roles outside the development organization. [ISTQB Glossary]
Характеристики приемочного тестирования
Цель: проверка готовности системы
Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика
Базис: системные требования, бизнес требования, сценарии использования, User Stories
Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта
Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик
Завершая рассмотрение примера можем написать приемочный тест, который выполнит заказчик:
Количество тестов на приемочном уровне намного меньше, чем на других уровнях, потому что в этот момент времени вся система уже проверена. Приемочные тесты практически никогда не автоматизируются.
В Agile разработке, конкретно в Scrum, для всех User Stories обязательно прописываются Acceptance Criteria. Именно они являются основой для приемочных тестов и показывают, что команда сделала именно то, что было нужно.
После завершения приемочного тестирования задача передается клиенту.
Резюме
В этой статье мы описали, что такое уровни тестирования, зачем они нужны и что собой представляет каждый из них.
Мы рассмотрели пример тестирования формы Contact Us.
Мы поняли, что тестирование нужно начинать с самых маленьких частей системы — компонентов / модулей.
Далее стоит проверить взаимосвязи между компонентами и всю систему в целом.
А завершает тестирование — заказчик, выполняя приемочное тестирование.
Для того, чтоб ты смог проверить себя — мы создали специальный тест! Он поможет тебе узнать, насколько хорошо ты разобрался в определениях уровней тестирования и подскажет, что нужно повторить)
🔥 А если ты готов к настоящему вызову и хочешь попробовать применить полученные знания на практике, мы подготовили практические задания по тестированию сайтов разной сложности, выполнение которых покажет, на сколько хорошо ты понимаешь и умеешь применять теорию, связанную с уровнями тестирования.
Если тебе интересна тема тестирования и ты хотел бы получать актуальную информацию по этой теме — подписывайся на наш Телеграм канал! Там интересно: статьи, тесты, опросы, нет спама 😉
Если ты хочешь продолжить разбираться с тестированием — узнай больше о тестировании в целом, разберись с типами тестирования или посмотри принципы тестирования ПО, которые являются основой для понимания тестирования ПО в целом.
Если у тебя возникли вопросы или есть предложения по статье — обращайся к нам в Телеграм, будем рады 🙂
Источники
Что такое уровень тестирования?
Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.
Что такое компонентное тестирование (unit testing)?
Компонентное / модульное / unit testing — фокусируется на компонентах / модулях / классах, которые могут быть проверены изолированно / отдельно.
Что такое интеграционное тестирование (integration testing)?
Интеграционное тестирование / integration testing — фокусируется на взаимодействии между компонентами / модулями, системами.
Что такое системное тестирование (system testing)?
Системное тестирование / system testing — фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.
Что такое приемочное тестирование (acceptance testing)?
Приемочное тестирование / acceptance testing — фокусируется на поведении всей системы в целом. Оно дает возможность оценить готовность системы к развертыванию и использованию.
