Уровни тестов
В прошлом уроке вы познакомились с двумя видами тестирования — ручным и автоматизированным. В этом уроке поговорим об уровнях тестов и задачах и участников каждого из них.
Уровни тестов
Тестирование ПО состоит из нескольких последовательных этапов, которые называются уровнями тестов.
Уровень теста (test level) — это один из последовательных этапов тестирования, который, как правило, направлен на достижение определённых целей.
Выделяют следующие уровни тестов (этапы тестирования):
- Модульное/компонентное тестирование (component testing) или юнит-тестирование (unit) — это проверка функции модуля.
- Интеграционное тестирование (integration testing) — проверка взаимодействия между частями системы или между разными системами.
- Системное тестирование (system testing) — так называется проверка на соответствие функциональным требованиям и атрибутам качества.
- Приёмочное тестирование (acceptance testing) — проверка готовности системы к передаче пользователям.
Не всегда необходимо проводить тестирование на всех этих уровнях, но их последовательность, как правило, остаётся именно такой: от проверки отдельных компонентов до тестирования системы в целом.
Разберём подробнее каждый уровень тестирования.
Модульные тесты
Модульные тесты фокусируются на одном модуле программного кода. Цель модульного тестирования — убедиться, что модуль выполняет свою функцию в соответствии с требованиями к нему. Модульное тестирование — это по сути проверка того, насколько правильно разработчик понял и реализовал требования.
Модульное тестирование проводится разработчиком после того, как он написал программный код модуля. Или, иными словами, после того, как разработчик считает работу над модулем завершённой. Модульное тестирование помогает разработчику «отловить» ошибки до того, как модуль будет передан тестировщику.
Подходы к модульному тестированию
Выделяют два подхода к модульному тестированию:
- Тестирование «чёрного ящика» (black‐box testing) При этом подходе проверяется, выполняет ли модуль свою функцию: в ответ на определённые входные данные он должен возвращать ожидаемые выходные данные. Подход называется «чёрным ящиком», так как тестировщику неважно внутреннее устройство модуля. Источником информации для составления тест-кейсов в данном случае являются требования — модуль проверяется на соответствие им.
- Тестирование «белого ящика» (white‐box testing) Реже используется подход, в котором уделяется большее внимание внутреннему устройству модуля, то есть тестируется практически каждая строчка кода по отдельности. Этот подход подходит для модулей со сложным внутренним устройством. Источником для тест-кейсов выступает исходный код модуля.
Закрепим отличия двух подходов. Соотнесите характеристику на карточках с подходом к модульному тестированию.
Автоматизация модульных тестов
Часто разработчики автоматизируют модульные тесты. Автоматизированные модульные тесты обычно пишет сам разработчик модуля на том же языке программирования, на котором написан сам модуль.
Иногда разработчики сначала пишут программный код автоматизированного модульного теста, потом реализуют модуль, а затем запускают модульный тест. То есть разработчики думают о том, как они могут проверить функцию модуля, прежде чем приступить к его реализации. Такая техника называется разработкой через тестирование (test-driven development — TDD).
Автоматизированные модульные тесты помогают быстрее обнаружить ошибку, потому что они указывают разработчику на строку кода, в которой она произошла, в то время как тестировщик сможет сформулировать только саму проблему, например: «Результаты расчёта неверны».
Интеграционные тесты
Интеграционные тесты проверяют взаимодействие нескольких частей системы (в том числе модулей) или нескольких систем между собой.
Этот уровень тестов помогает убедиться, что интерфейсы и связи между разными частями системы работают корректно. К этому моменту каждый из модулей уже прошёл модульное тестирование, и теперь необходимо проверить их взаимодействие — порядок вызовов модулей и обмен данными между ними.
Например, в приложении для доставки цветов реализованы функции создания, поиска, отображения, изменения и удаления заказа. Каждая из этих функций может быть реализована в отдельных модулях. Меню заказов приложения также может являться отдельным модулем.
Во время интеграционного тестирования проверяется, как меню заказов взаимодействует с другими модулями программы. Корректно ли уходят запросы, отвечают ли модули, возвращают ли они всю необходимую информацию, чтобы отобразить её в интерфейсе.
Интеграционное тестирование проводят разработчики или тестировщики.
Выделяют четыре подхода к интеграционному тестированию:
- тестирование пользовательского интерфейса (user interface testing);
- тестирование сценария использования (use scenario testing);
- тестирование потока данных (data flow testing);
- тестирование системного интерфейса (system interface testing).
В большинстве случаев используются все четыре подхода.
Тестирование пользовательского интерфейса
Тестирование реализованного пользовательского интерфейса проводится на основании ранее созданного прототипа пользовательского интерфейса: они сравниваются между собой.
Тестирование — это стандартная процедура для любого ПО, у которого есть пользовательский интерфейс. Тестировщик проверяет все элементы интерфейса, продвигаясь снизу вверх или сверху вниз по экрану.
Тестирование сценария использования
При тестирование ПО на соответствие сценариям использования тестировщик проверяет все сценарии использования, чтобы убедиться, что они работают корректно.
Этот вид тестов совмещается с тестированием пользовательских интерфейсов, так как тестирование сценариев использования не позволяет проверить все экраны интерфейса ПО. Тестирование сценариев использования позволяет дополнительно проверить, что последовательность и количество шагов для выполнения действий совпадает со сценариями.
Тестирование потока данных
Этот подход применяется для систем, предназначенных для работы с данными. Тестирование проводится на основании диаграмм DFD, отображающих потоки данных между частями системы.
Не все модули (части системы, системы) могут быть закончены в одно время, поэтому разработчики пишут для незаконченных модулей заглушки (stub), чтобы можно было протестировать связанные модули.
Заглушка — это временный программный код, который, как правило, отображает на экране простое тестовое сообщение или возвращает какой-либо фиксированный (hardcoded) ответ, когда к нему обращаются.
Например, представьте, что в приложении доставки цветов модуль главного меню уже реализован. Протестировать его без других модулей невозможно, потому что меню заказов предназначено для перехода к другим модулям.
В этом случае разработчикам необходимо написать заглушки для каждого из этих модулей. Эти заглушки будут просто отображать сообщение на экране, например «Выполнен переход в модуль поиска заказа». Таким образом, можно протестировать модуль меню заказов до того, как реализация других модулей будет завершена.
Заглушки последовательно заменяются реализованными модулями. После каждой замены фактический результат тестирования сравнивается с ожидаемым. Если они совпадают, то следующая заглушка заменяется на реализованный модуль, и тест выполняется снова.
Тестирование системного интерфейса
Проводится, когда система не только хранит и обрабатывает данные, но и обменивается данными с другими системами.
Зачастую обмен данными между системами автоматизирован и пользователи его не контролируют. Поэтому необходимы тесты, которые подтверждают, что данные передаются корректно.
Так же как и тестирование потоков данных, тестирование системных интерфейсов проводится на основании диаграмм DFD.
Системные тесты
Системные тесты проверяют соответствие системы определённым функциональным требованиям, а также атрибутам качества, например, требованиям к удобству использования, защищённости и производительности.
Системное тестирование проводит вся команда разработки.
Выделяют четыре основных подхода к системному тестированию:
- Функциональное тестирование (functional testing) или тестирование требований (requirements testing).
- Тестирование удобства использования (usability testing), или юзабилити-тестирование.
- Тестирование защищённости (security testing).
- Тестирование производительности (performance testing).
Также системное тестирование может включать тестирование документации.
Функциональное тестирование
Система проверяется на соответствие функциональным требованиям.
Тестирование проводится на основании описания архитектуры системы и результатах модульных и интеграционных тестов. Тестировщики и системный аналитик проверяют, что в результате исправления ошибок на этапе интеграционного тестирования не появились новые ошибки. Они также часто проверяют, что система устойчива к ошибкам пользователей. Для этого при работе с системой совершаются заведомо некорректные действия.
Функциональное тестирование является стандартным этапом проверки всех программных продуктов.
Тестирование удобства использования
В процессе тестирования дизайнер интерфейсов проверяет, насколько быстро пользователи обучаются работе с интерфейсом и выполняют свои задачи, соответствует ли поведение пользователей созданным сценариям использования. Проверка проводится на основании прототипов интерфейсов и сценариев использования.
Тестирование защищённости
В ходе тестирования аварийного восстановления и защиты от неавторизованного доступа специалисты в области информационной безопасности проверяют защищённость системы от внутренних и внешних угроз.
Это тестирование проводится, когда система имеет критическое значение и её отключение может привести к крупным сбоям и убыткам, а также когда система содержит чувствительную информацию (персональные данные или данные не для общего пользования).
Тестирование производительности
Это проверка работоспособности системы при высоких нагрузках. Разработчики и тестировщики проверяют, что система выполняет свои функции в течение ограниченного времени и других ресурсов при большом количестве запросов.
Тестирование проводится в тех случаях, когда система имеет критическую важность и должна стабильно работать при высоких нагрузках.
Тестирование документации
К системным тестам также относится проверка системы на соответствие документации. Системный аналитик полностью или выборочно проверяет каждую страницу документации чтобы убедиться, что она описывает фактическую работу системы.
Тестирование является стандартным для всех приложений.
Приёмочные тесты
Цель приёмочного тестирования — убедиться, что система готова к передаче пользователям. Приёмочное тестирование проводят пользователи с участием команды разработки.
Опыт пользователей во время проведения приёмочного тестирования влияет на дальнейшее отношение пользователей к новой системе. Если в процессе тестирования пользователь обнаружит множество критических ошибок, он будет негативно настроен к системе даже после того, как ошибки будут исправлены. Поэтому команда разработки и системный аналитик должны стремиться к тому, чтобы приёмочное тестирование проводилось только после тщательной проверки системы путём проведения модульных, интеграционных и системных тестов.
Во время приёмочного тестирования аналитику также важно получить от пользователей обратную связь и быть готовым отвечать на их вопросы. Команде разработки следует учесть полученную обратную связь в будущих версиях системы.
Выделяют два подхода к приёмочному тестированию:
- Альфа-тестирование (alpha testing) Пользователи тестируют систему, используя специально подготовленные данные. Например, для тестирования системы бухучёта в неё загружаются подготовленные тестовые документы, содержащие несуществующую информацию о несуществующих пользователях, счетах и т. д.
- Бета-тестирование (beta testing) Пользователи тестируют систему, используя реальные данные. Например, это могут быть данные из реальной системы, которую должна заменить тестируемая система или оцифрованные данные с бумажных носителей.
Вы работаете над приложением для редактирования фото. В нём уже реализованы функции по добавлению текста на изображение и обрезке текста изображения. От пользователя пришёл запрос на добавление модуля для цветокоррекции изображения. Команда разработки реализовала этот модуль. Расположите в правильной последовательности этапы, по которым новая функциональность будет тестироваться.
Выбранная группа пользователей получает новую версию приложения для тестирования. В течении двух недель они работают на новой версии и сообщают обо всех ошибках и неудобствах, с которыми они столкнулись во время работы.
Этап 4
Пользователи приступают к тестированию на последнем этапе, когда команда завершила модульное, интеграционное и системное тестирование.
Тестировщик проверяет, что в интерфейсе появились новые кнопки, позволяющие скорректировать цвета изображения. Выполняется проверка корректности действий, выполняемых через интерфейс.
Этап 2
Тестирование пользовательского интерфейса происходит на этапе интеграционного тестирования. Этот этап происходит после проверки кода тестировщиками и до передачи продукта пользователям.
Интерфейс проверяется на соответствие требованиям: новые кнопки расположены согласно макетам, все новые функции работают корректно и согласно требованиям.
Этап 3
Проверка функциональности на соответствие требованиям — этап системного тестирования. Этот третий этап проверки, который происходит после модульных и интеграционных тестов и до приёмочных испытаний.
Проверяется работа нового модуля цветокоррекции, а именно, что изображение корректно инвертирует цвета, согласно полученным параметрам.
Этап 1
Тестирование работы конкретного модуля (модульное тестирование) является первым этапом тестировании.
Определите, о каком уровне тестирования идёт речь в следующих утверждениях
Системный аналитик проверяет, что в интерфейсе сервиса корректно реализована форма поиска билетов.
Системные тесты
Соответствие системы бизнес-требованиям и удобство для пользователей проверяется на уровне системных тестов.
В приложении по бронированию авиабилетов разработаны модули по поиску авиабилетов, бронированию билетов и истории бронирования пользователей. Разработчик написал тесты, чтобы проверить, что модуль истории бронирования предоставляет историю операций согласно контракту API.
Модульное тестирование
Когда тестируется одна программа или часть программы, которая отвечает за специфическую функцию, речь идёт о модульном тестировании.
Тестировщик убедился, что после успешного бронирования билетов модуль бронирования вызывает модуль истории заказов для создания новой записи в истории бронирований пользователя, а новая запись успешно сохраняется.
Интеграционные тесты
Потоки управления между модулями и обмен данными между ними — ключевая задача интеграционных тестов.
Тестировщик проверяет, что система стабильно работает при одновременной работе 10 000 пользователей.
Системные тесты
Проверка системы на соответствие требованиям безопасности и устойчивость к нагрузкам проверяется на этапе системных тестов.
Выбранная группа пользователей тестирует интерфейс и функции приложения на удобство и понятность.
Приёмочные тесты
Продукт передаётся для тестирования пользователям на этапе приёмочных тестов.
Подведём итоги
Перед тем как ПО попадает к пользователям, оно проходит четыре последовательных уровня тестирования.
- Модульные тесты проверяют, что модуль выполняет свою функцию в соответствии с требованиями к нему. Их проводят разработчики сразу после написания программного кода модуля.Тестировать модули можно с помощью двух подходов:
- тестирования «чёрного ящика»;
- тестирования «белого ящика».
- Интеграционные тесты проверяют взаимодействие нескольких частей системы (в том числе модулей) или нескольких систем. Интеграционное тестирование проводят разработчики или тестировщики.Выделяют четыре подхода к интеграционному тестированию:
- тестирование пользовательского интерфейса;
- тестирование сценария использования;
- тестирование потока данных;
- тестирование системного интерфейса.
- Системные тесты проверяют соответствие системы определённым атрибутам качества. В рамках системных тестов выделяют:
- функциональное тестирование, или тестирование требований;
- тестирование удобства использования, или юзабилити-тестирование;
- тестирование защищённости;
- тестирование производительности;
- тестирование документации.
Системное тестирование проводит вся команда разработки, включая системного аналитика. СА проверяет соответствие системы функциональным и нефункциональным требованиям, удобство использования, а также проверяет документацию. - Приёмочные тесты помогают убедиться, что система готова к передаче пользователям. В приёмочных тестах участвует группа пользователей, которая проверяет систему на наличие ошибок, удобство и понятность системы для пользователей.Проводить приёмочные тест можно с двумя видами данных:
- Альфа-тестирование использует специально подготовленные для тестов данные;
- Бета-тестирование использует реальные данные, которые будут использоваться в системе.
