2. Теория тестирования программного обеспечения

Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis)[1].

Основная цель – устранение ошибок в ПО на этапе разработки и тестирования, указание сути проблемы и обоснования ее устранения.

Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Выделяется:

• Модульное тестирование (Unit testing)

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

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

2.1. Виды, методы и инструменты тестирования

В теории тестирования существует множество видов, методов и инструментов тестирования.

Виды тестирования:

• Приёмочное тестирование,

• Установочное тестирование

• Альфа и бета тестирование

• Функциональноые тесты тесты соответствия

• Достжение и оценка надежности

• Тестирование производительности

• Нагрузочное тестирование

• Сравнительное тестирование

• Восстановительные тесты

• Конфигурационное тестирование

• Тестирование иудобства и простоты использования

• Разработка управляемая тестированием

Методы тестирования:

• Черный, белый, серый ящики

• Тестирование спецификации требований

• Позитивное и негативное тестирование

• Классы эквивалентности

• Граничные значения

• Тестирование переходов между состояниями

• Таблица решений

• Парное тестирование

Инструменты тестирования:

• test-case

• test-design

• тест-план

• тестовый случай

• виды тестирования

• тест-набор.

Верификация – подтверждение того, что все функции ПО выполняются, что работает старый и новый функционал, проверяется наличие критических ошибок (поверхностное тестирование)[4].

Регрессионное тестирование – проверка работы старого функционала – углубленное тестирование старого функционала.

Тестирование нового функционала – углубленное тестирование нового функционала, при этом не уделяется внимания проверке старого функционала.

Верификация – это верхний уровень над регрессией и тестированием нового функционала.

2.2. Характеристики технического задания

Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования [2].

Техническим заданием так же называют постановку и спецификацию.

Характеристики требования:

1. Корректность – наиболее полно определяется степенью ее соответствия предъявляемым к ней формальным требованиям программной спецификации.

2. Недвусмысленность - могут ли два разных человека неоднозначно понять одни и те же требования. Проверять ветвистость требований. Поиск того, что не прописано явно. Избегать ветвления требований. Интерпретировать в виде таблиц с различными вариантами требований.

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

4. Непротиворечивость набора требований – не очевидна на первый взгляд.

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

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

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

Если трассировка сделана не правильно, то будет визуально заметно несоответствие связей.

7. Понимаемость - нужно разбираться в предметной области для специалистов более низкого уровня. Технические детали – выносятся на более низкий уровень. В верхнем уровне выделять обобщенную информацию. Нужно обращать внимание на детали [5].

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