Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx

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

В процессе разработки программного обеспечения тестирование поводится на разных стадиях, так как ПО разрабатывается шаг за шагом, компонент за компонентом. Как только компонент готов, его необходимо протестировать.

Разработка на основе тестов имеет другой подход, где тесты пишутся в первую очередь и функционал строится на основе этих тестов. Тестирование на определенных уровнях называют уровнями тестирования и эти уровни разрастаются от индивидуальных модулей до объединенных и скомбинированных в отдельные компоненты. Простые проекты могут состоять из одного или двух уровней, когда сложные могут иметь более шести [4]². На рисунке 1 приведена схема V-модели процесса разработки ПО.



Рис. 1. V-модель процесса разработки ПО

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

Модульное тестирование проверяет внутреннюю логику и структуры данных в индивидуальных компонентах при помощи тестирования их в изолированных окружениях. Модульное тестирование использует спецификацию для компонентов уровня как инструкцию. На данном уровне необходимо использование заглушек и драйверов [1]³. На рисунке 2 приведена структура использования драйверов и заглушек.


Рис. 2. - Использование драйверов и заглушек

Согласно стандарту IEEE 1008-1987, модульное тестирование включает в себя планирование общего подхода, ресурсов и графика, выбор функционала для тестирования, уточнение Общего плана, разработку набора тестов, реализацию плана, выполнение тестов, оценку трудозатрат и модулей.

---

Как только отдельные модули объединяются, повышаются риски появления ошибок в интерфейсах между модулями, так как интегрированные модули могут не выполнять желаемых функций, данные могут теряться между интерфейсами, может выявиться неправильное вычисление и другие ошибки, которые нельзя выявить при помощи модульного тестирования. Эти ошибки могут быть идентифицированы при использовании интеграционного тестирования. В этом случае могут быть использованы различные походы к тестированию, а именно: интеграция сверху-вниз, интеграция снизу-вверх, двунаправленная интеграция. Ниже приведены иллюстрации процессов интеграции снизу-вверх и сверху-вниз соответственно (рис. 3, рис. 4).


Рис. 3. - Интеграция снизу-вверх


Рис. 4. - Интеграция сверху-вниз

Целью тестирования на системном уровне является проверка, соответствует ли разработанное программное обеспечение всем требованиям, которые указаны в спецификации. Системное тестирование сфокусировано на уровне требований.

Приемочное тестирование обычно проводится представителем пользователей, заказчиком или представителем заказчика. Как правило, оно включает в себя тесты из фазы системного тестирования или тесты, определенные самим заказчиком.

3. Типы тестирования

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

Автор данной работы вывела классификацию по типам тестирования (рис. 5).



Рис. 5. - Типы тестирования

Первый уровень классификации это: функциональное и нефункциональное тестирование.

---

Каждый из этих типов включает в себя список других типов. Ниже в таблице (см. Таблица 1 Приложение 1) приводятся определения типов тестирования.

4. 1   2   3   4   5   6   7   8   9   ...   31

---

Артефакты тестирования

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

1. 
   Стратегия тестирования.
   

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

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

2. 
   План тестирования
   

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

---

При разработке плана нужно учесть следующие факторы:

• 
  цель;
  
• 
  охват тестирования;
  
• 
  подход к тестированию;
  
• 
  критерий для начала тестирования;
  
• 
  ресурсы;
  
• 
  задачи/обязанности;
  
• 
  критерий для окончания тестирования;
  
• 
  график;
  
• 
  требования к программному обеспечению;
  
• 
  риски и планы по смягчению последствий;
  
• 
  артефакты тестирования;
  
• 
  ссылки;
  
• 
  история изменений;
  
• 
  подписи.
  

3. 
   Тестовый сценарий
   

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

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

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

4. 
   Тестовый случай (Тест-кейс).
   

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

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

К примеру, у нас есть текстовое поле, которое принимает только положительные числовые значения от 1 до 100 включительно. Позитивным тестом для этого поля будет ввод любого числа от 1 до 100, например, 45. Негативным – любое значение, не входящее в эти рамки, в том числе строковое, например, «НТ29».

Стандартно Тестовый случай должен содержать:

---