Уровни тестирования

Пирамида тестирования (Test Pyramid)

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

Уровни тестирования(Testing Levels)

• Unit/component/program/module testing - тестируется минимально-атомарный модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего;
• Integration testing - несколько модулей программы тестируются вместе;
• System testing - вся программа тестируется полностью;
• Acceptance testing - программа принимается заказчиком на соответствие заявленным требованиям либо тестировщики проходят end-to-end сценарии с точки зрения пользователя;

Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)

С этими терминами часто происходит путаница. Если ссылаться на глоссарий ISTQB, то все они - синонимы:

• Модуль, юнит (module, unit): См. компонент.
• Модульное, юнит тестирование (module testing, unit testing): См. компонентное тестирование.
• Компонент (component): Наименьший элемент программного обеспечения, который может быть протестирован отдельно.
• Компонентное тестирование (component testing): Тестирование отдельных компонентов программного обеспечения (IEEE 610).

Тем не менее, некоторые источники описывают ситуацию несколько иначе и я решил выписать другую точку зрения.

Модульное тестирование (оно же юнит-тестирование) используется для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками. Целью тестирования модуля является не демонстрация правильного функционирования модуля, а демонстрация наличия ошибки в модуле, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Изоляция тестируемого блока достигается с помощью заглушек (stubs), манекенов (dummies) и макетов (mockups).

Компонентное тестирование - тип тестирования ПО, при котором тестирование выполняется для каждого отдельного компонента отдельно, без интеграции с другими компонентами. Его также называют модульным тестированием (Module testing), если рассматривать его с точки зрения архитектуры. Как правило, любое программное обеспечение в целом состоит из нескольких компонентов. Тестирование на уровне компонентов (Component Level testing) имеет дело с тестированием этих компонентов индивидуально. Это один из самых частых типов тестирования черного ящика, который проводится командой QA. Для каждого из этих компонентов будет определен сценарий тестирования, который затем будет приведен к Test case высокого уровня -> детальным Test case низкого уровня с предварительными условиями.

Исходя из глубины уровней тестирования, компонентное тестирование можно классифицировать как:

• Тестирование компонентов в малом (CTIS - Component testing In Small): тестирование компонентов может проводиться с или без изоляции остальных компонентов в тестируемом программном обеспечении или приложении. Если это выполняется с изоляцией другого компонента, то это называется CTIS;
• Тестирование компонентов в целом (CTIL - Component testing In Large) - тестирование компонентов, выполненное без изоляции других компонентов в тестируемом программном обеспечении или приложении;

Другой источник:

По-существу эти уровни тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном/unit тестировании - конкретные значения.

*В контексте юнит-тестирования еще можно встретить понятие golden testing. Оно означает те же юнит тесты, но с ожидаемыми результатами хранящимися в отдельном файле. Таким образом после прогона выходные значения тестов сравниваются с golden (эталонным) файлом.

*Иногда юнит-тесты называют одинокими (solitary) в случае тотального применения имитаций и заглушек или общительными (sociable) в случае реальных коммуникаций с другими участниками.

*Правило трех А(AAA) (arrange, act, assert) или триада «дано, когда, тогда» - хорошая мнемоника, чтобы поддерживать хорошую структуру тестов.

Интеграционное тестирование (Integration testing)

Интеграционное тестирование (integration testing): Тестирование, выполняемое для обнаружения дефектов в интерфейсах и во взаимодействии между интегрированными компонентами или системами. См. также тестирование интеграции компонентов, системное интеграционное тестирование. (ISTQB)

Системное интеграционное тестирование (system integration testing): Тестирование интеграции систем и пакетов программ, тестирование интерфейсов связи с внешними системами (интернет и т.д.). (ISTQB)

Интеграционное тестирование в малом (integration testing in the small): См. тестирование интеграции компонентов. (ISTQB)

Интеграционное тестирование в целом (integration testing in the large): См. системное интеграционное тестирование. (ISTQB)

Изоляционное тестирование (isolation testing): Тестирование отдельных компонентов в изоляции от окружающих компонентов в окружении компонентов, которые при необходимости эмулируются заглушками и драйверами. (ISTQB)

Попарное интеграционное тестирование (pairwise integration testing): Вид интеграционного тестирования, нацеленного на пары компонентов, работающих совместно соответственно графу вызовов. (ISTQB)

Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). С технологической точки зрения интеграционное тестирование является количественным развитием компонентного, поскольку также оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки (Stub) на месте отсутствующих модулей. Основная разница между компонентным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов, например, вызовов функций или методов, или анализ использования интерфейсных объектов, таких как глобальные ресурсы, средства коммуникаций, предоставляемых операционной системой.

Уровни интеграционного тестирования:

• Компонентный интеграционный уровень (CIT - Component Integration testing): Проверяется взаимодействие между компонентами одной системы после проведения компонентного тестирования. Программные компоненты или модули могут быть определены в разное время совершенно разными группами спецификаций, component integration testing выполняется чтобы убедиться, что даже после различий в разработке модулей интеграция всего работает вместе. В этом случае также важно учесть отрицательные случаи, так как компоненты могут делать предположения относительно данных;
• Системный интеграционный уровень (SIT - System Integration testing): - это полное тестирование всей системы, состоящей из множества подсистем. Основная цель SIT - обеспечить правильное функционирование всех зависимостей программных модулей и сохранение целостности данных между отдельными модулями всей системы. SUT (System Under Test) может состоять из аппаратного обеспечения, базы данных, программного обеспечения, комбинации аппаратного и программного обеспечения или системы, требующей взаимодействия с человеком (HITL - Human in the Loop Testing). SIT имеет предварительное условие, при котором несколько базовых интегрированных систем уже прошли системное тестирование. Затем SIT проверяет необходимые взаимодействия между этими системами в целом. Результаты SIT передаются в UAT (пользовательское приемочное тестирование);

Интеграция может быть как программной, так и софт-железо:

• HSIT - Hardware Software Integration Testing: представляет собой процесс тестирования компонентов компьютерного программного обеспечения (CSC - Computer Software Components) на предмет функциональности высокого уровня в целевой аппаратной среде. Тестирование черного ящика - это основной тип тестирования, используемый на этом уровне тестирования. Целью тестирования интеграции аппаратного / программного обеспечения является проверка поведения разработанного программного обеспечения, интегрированного в аппаратный компонент. Цель тестирования интеграции аппаратного и программного обеспечения на основе требований (Requirement based Hardware-Software Integration Testing) - убедиться, что программное обеспечение на целевом компьютере удовлетворяет высокоуровневым требованиям (high-level requirements);
• SSIT - Software Software Integration Testing: это Computer Software Component Testing, работающего в среде целевого компьютера при моделировании всей системы (других CSC), и на функциональности высокого уровня. Оно фокусируется на поведении CSC в смоделированной среде хоста / цели. Для проверки интеграции программного обеспечения используются разные подходы;

Подходы к интеграционному тестированию:

• Подход Большого взрыва (Big Bang Approach): “Вид подхода к интеграционному тестированию, при котором элементы программного или аппаратного обеспечения, или и то и другое, собираются в компонент или в целую систему сразу, а не по этапам.” ( IEEE 610). Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если Test case и их результаты записаны неверно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования;
• Инкрементальный подход (Incremental Approach): при таком подходе тестирование выполняется путем объединения двух или более логически связанных модулей. Затем другие связанные модули поэтапно добавляются и тестируются для правильного функционирования. Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы. Осуществляется разными методами:
  • Нисходящий подход (Top-Down Approach): Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Преимущества: Локализация неисправностей проще. Возможность получить ранний прототип. Основные недостатки дизайна могут быть найдены и исправлены в первую очередь. Недостатки: Нужно много заглушек. Модули на более низком уровне тестируются недостаточно;
  • Восходящий подход (Bottom-Up Approach): В восходящей стратегии каждый модуль на более низких уровнях последовательно тестируется с более высокоуровневыми модулями, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. Пример низкоуровневого модуля - модуль, который заведует хранением токенов авторизации. Высокоуровневый - модуль авторизации, в состав которого помимо прочего входит модуль токенов. Преимущества: Локализация ошибок проще. Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва. Недостатки: Критические модули (на верхнем уровне архитектуры ПО), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам. Ранний прототип невозможен;
  • Гибридный/сэндвич-подход(Sandwich/Hybrid/Bi-Directional Approach): Представляет собой комбинацию восходящего и нисходящего подходов. Здесь целью является средний слой, в то время как драйверы заменяют верхний слой, а заглушки нижний пока компоненты этих слоев не будут разработаны;

Критерии начала и окончания Integration Testing:

Обычно при выполнении интеграционного тестирования используется стратегия ETVX (Entry Criteria, Task, Validation, Exit Criteria).

• Критерии начала:
  • завершено модульное тестирование;
• На входе:
  • Software Requirements Data;
  • Software Design Document;
  • Software Verification Plan;
  • Software Integration Documents;
• Действия:
  • На основе требований высокого и низкого уровня (High and Low-level requirements) создайте test cases and procedures;
  • Комбинируйте сборки низкоуровневых модулей, которые реализуют общую функциональность;
  • Разработайте тестовую обвязку (test harness);
  • Протестируйте сборку;
  • После прохождения теста сборка объединяется с другими сборками и тестируется до тех пор, пока система не будет интегрирована как единое целое;
  • Повторите все тесты на целевой processor-based platform и получите результаты;
• Критерии выхода:
  • Успешное завершение интеграции Программного модуля на целевое Hardware;
  • Правильная работа программного обеспечения в соответствии с указанными требованиями;
• На выходе:
  • Integration test reports;
  • SVCP - Software Test Cases and Procedures;

Test Harness- (тестовая обвязка): Тестовое окружение, включающее в себя заглушки и драйверы, необходимые для проведения теста. (ISTQB)

Test Driver и Test Stub являются искусственными заменами компонентов программы на время тестов по аналогии с моками в тестировании API. Тестовый драйвер - то, что вызывает тестируемый компонент. Тестовая заглушка - то, что возвращает тестируемому компоненту фиктивный ответ. Т.е. заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с тестируемым модулем.

Тестирование интерфейса - это тип интеграционного теста, который проверяет, правильно ли установлена ​​связь между двумя различными программными системами или их частями (модулями). Соединение, которое объединяет два компонента, называется интерфейсом. Этот интерфейс в компьютерном мире может быть чем угодно, как API, так и веб-сервисами и т. д. Тестирование интерфейса включает в себя тестирование двух основных сегментов:

• Интерфейс веб-сервера и сервера приложений
• Интерфейс сервера приложений и базы данных

Тестирование потоков (Thread testing) - это вид тестирования программного обеспечения, который проверяет основные функциональные возможности конкретной задачи (потока). Обычно проводится на ранней стадии фазы интеграционного тестирования. Тестирование на основе потоков является одной из дополнительных стратегий, принятых в ходе System Integration Testing. Поэтому его, вероятно, следует более правильно назвать «тестом взаимодействия потоков» (thread interaction test).

Thread Testing подразделяется на две категории:

• Однопоточное тестирование (Single thread testing) включает одну транзакцию приложения за раз;
• Многопоточное тестирование (Multi-thread testing) включает одновременно несколько активных транзакций;

Как проводить Thread Testing:

• Тестирование на основе потоков является обобщенной формой тестирования на основе сеансов (session-based testing), в котором сеансы являются формой потока, но поток не обязательно является сеансом;
• Для тестирования потока, поток или программа (небольшая функциональность) интегрируются и тестируются постепенно как подсистема, а затем выполняются для всей системы;
• На самом низком уровне оно предоставляет интеграторам лучшее представление о том, что тестировать;
• Вместо непосредственного тестирования программных компонентов требуется, чтобы интеграторы сосредоточились на тестировании логических путей выполнения в контексте всей системы;

Советы:

• Протестируйте свою многопоточную программу, многократно выполняя ее с другим набором запущенных приложений;
• Протестируйте свою многопоточную программу, активировав одновременно несколько экземпляров программы;
• Выполняйте многопоточную программу на разных моделях оборудования с различными уровнями нагрузки и рабочими нагрузками;
• Инспекция кода;
• Собирайте только ошибки и сбои, которые произошли в потоках, отличных от основного;

Системное тестирование (System Testing)

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

Основное внимание уделяется следующему:

• Внешние интерфейсы;
• Многопрограммность и сложный функционал;
• Безопасность;
• Восстановление;
• Производительность;
• Гладкое (smooth) взаимодействие оператора и пользователя с системой;
• Возможность установки;
• Документация;
• Удобство использование;
• Нагрузка / стресс;

Зачем нужно системное тестирование?

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

Критерии начала системного тестирования:

• Система должна соответствовать критериям окончания интеграционного тестирования, то есть все test cases должны быть выполнены, и не должно быть открытых критических ошибок или ошибок с приоритетом P1, P2;
• System Test Plan должен быть одобрен и подписан;
• Test cases/scenarios/scripts должны быть готовы к выполнению;
• Все нефункциональные требования должны быть доступны, и для них должны быть созданы test cases;
• Среда тестирования должна быть готова;

Критерии окончания системного тестирования:

• Все test cases должны быть выполнены;
• В открытом состоянии не должно быть критических, приоритетных или связанных с безопасностью ошибок;
• Если какие-либо ошибки со средним или низким приоритетом находятся в открытом состоянии, они должны быть исправлены с согласия клиента;
• Отчет о выходе (Exit Report) должен быть отправлен;

Чем отличается системное тестирование от сквозного (E2E - end-to-end testing)?

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

Системное тестирование - этап предпоследний этап STLC и уровень тестирования, а E2E - подход к тестам. Обычно сквозные тесты выполняют после системного тестирования и перед приемочным, а также после внесения изменений (smoke и regression). E2E выполняется от начала до конца в реальных сценариях, таких как взаимодействие приложения с оборудованием, сетью, базой данных и другими приложениями. Основная причина проведения этого тестирования - определение различных зависимостей приложения, а также обеспечение передачи точной информации между различными компонентами системы.

Приемочное тестирование (AT - Acceptance testing)

Приемочное тестирование (acceptance testing): Формальное тестирование по отношению к потребностям, требованиям и бизнес процессам пользователя, проводимое с целью определения соответствия системы критериям приемки и дать возможность пользователям, заказчикам или иным авторизированым лицам определить, принимать систему или нет. (IEEE 610)

Эксплуатационное приемочное тестирование (operational acceptance testing): Эксплуатационное тестирование в фазе приемочного тестирования, обычно выполняемое пользователем и/или сотрудниками с администраторским доступом, в рабочей среде (возможно, стимулированной), фокусируясь на функциональных аспектах. Например, восстанавливаемость, поведение ресурсов, устанавливаемость и техническое соответствие. (ISTQB)

После того, как процесс тестирования системы завершен командой тестирования, весь продукт передается клиенту и/или нескольким его пользователям для проверки приемлемости (acceptability). Е2Е бизнес-потоки проверяются аналогично в сценариях в реальном времени. Подобная производственной среда будет тестовой средой для приемочного тестирования (Staging, Pre-Prod, Fail-Over, UAT environment). Это метод тестирования черного ящика, при котором проверяется только функциональность, чтобы убедиться, что продукт соответствует указанным критериям приемки.

Виды приемочного тестирования:

• Пользовательское приемочное тестирование (UAT - User Acceptance Testing, validation, end-user testing) выполняется пользователем или клиентом чтобы определить, может ли ПО быть принято (accepted) или нет и проверить ПО на соответствие бизнес-требованиям. Могут существовать такие бизнес-требования и процессы, которые известны только конечным пользователям, и они либо пропускаются, либо неправильно интерпретируются, поэтому приемочное тестирование выполняется конечными пользователями, знакомыми с бизнес-требованиями;
• Бизнес - приемочное тестирование (BAT - Business Acceptance Testing) необходимо для оценки того, соответствует ли Продукт бизнес-целям и задачам. BAT в основном фокусируется на бизнес-преимуществах (финансах), которые являются довольно сложными из-за меняющихся рыночных условий / прогрессирующих технологий, так что текущая реализация может претерпеть изменения, которые приведут к дополнительным затратам. Даже Продукт, отвечающий техническим требованиям, может не пройти BAT по этим причинам;
• Контрактное приемочное тестирование (CAT - Contract Acceptance Testing) - это контракт, который определяет, что после того, как Продукт будет запущен в течение заранее определенного периода, должен быть проведен приемочный тест, и он должен пройти все приемочные тест-кейсы. Подписанный здесь контракт называется Соглашением об уровне обслуживания (SLA), которое включает условия, по которым платеж будет производиться только в том случае, если услуги Продукта соответствуют всем требованиям, что означает, что контракт выполнен. Иногда этот контракт может заключаться до того, как Продукт будет запущен. В любом случае, контракт должен быть четко определен с точки зрения периода тестирования, областей тестирования, условий по проблемам, возникающим на более поздних этапах, платежей и т. д.;
• Правовое приемочное тестирование (RAT - Regulations/Compliance Acceptance Testing) необходимо для оценки того, нарушает ли Продукт правила и нормы, установленные правительством страны, в которой он выпускается. Это может быть непреднамеренным, но отрицательно скажется на бизнесе. Обычно разрабатываемый Продукт / приложение, предназначенный для выпуска во всем мире, должен пройти RAT, поскольку в разных странах / регионах действуют разные правила и положения, определенные его руководящими органами. Если какие-либо правила и нормы нарушаются для какой-либо страны, то этой стране или конкретному региону в этой стране не будет разрешено использовать Продукт и это будет считаться отказом (Failure). Вендоры Продукта несут прямую ответственность, если Продукт будет выпущен даже при наличии нарушения;
• Эксплуатационное приемочное тестирование (OAT - Operational Acceptance testing) - это тип тестирования программного обеспечения, который оценивает эксплуатационную готовность программного приложения до его выпуска в производство. Целью эксплуатационного тестирования является обеспечение бесперебойной работы системы в ее стандартной эксплуатационной среде (SOE - standard operating environment). В основном это тестирование восстановления, совместимости, ремонтопригодности, доступности технической поддержки, надежности, восстановления после сбоя, локализации и т. д (recovery, compatibility, maintainability, technical support availability, reliability, fail-over, localization);
• Альфа-тестирование (Alpha Testing) проводят для оценки продукта в среде разработки / тестирования специализированной командой тестировщиков, обычно называемой альфа-тестерами. Здесь отзывы и предложения тестировщиков помогают улучшить использование Продукта, а также исправить определенные ошибки;
• Бета-тестирование, полевые испытания (Beta Testing, Field Testing) проводят для оценки Продукта, предоставляя его реальным конечным пользователям, обычно называемым бета-тестерами / бета-пользователями, в их среде. Собирается постоянная обратная связь от пользователей, и проблемы устраняются. Кроме того, это помогает в улучшении Продукта, чтобы обеспечить удобство работы пользователей. Тестирование происходит неконтролируемым образом, что означает, что у пользователя нет ограничений на использование Продукта;

Уровни Тестирования 1. Модульное тестирование (Unit Testing) Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing) Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

3. Системное тестирование (System Testing) Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.

4. Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

5. Приемочное тестирование (Acceptance Testing) Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: • определения удовлетворяет ли система приемочным критериям; • вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.