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

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

При проектировании тестов для тестирования модулей должны быть доступны два источника информации: спецификация модуля и его текст. Спецификация обычно содержит описание входных и выходных параметров и его функций.

Последовательность применения методов «черного» и «белого» ящиков.

1. Сначала применение метода «функциональных диаграмм».

2. Затем метод «разбивки на классы или области эквивалентности».

3. Следующий метод «анализ граничных значений входных данных».

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

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

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

Интеграционные тесты должны быть направлены на проверку:

-основных компонентов корректного взаимодействия;

-соответствия всех данных, которыми обмениваются основные компоненты через интерфейс, своим спецификациям;

-реализации необходимых потоков управления.

Задачи, которые возникают в процессе тестирования модулей.

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

· Разработка тестов

· Формирование отладочных заданий

· Собственно тестирование

· Обработка результатов тестирования

Существуют две методики тестирования взаимодействия модулей.

· Монолитное тестирование.

· Пошаговое тестирование.

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

Когда все модули протестированы, они собираются вместе и тестируется вся программа в целом.

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

Существует две стратегии реализации тестирования:

· нисходящее, при котором тестирование начинается с верхнего головного модуля программы,

· восходящее, предполагающее тестирование с терминальных (не вызывающих других модулей).

Стратегии последовательности подключения модулей:

а) сначала подключаются модули наиболее важные с точки зрения тестирования, а именно, занесения, изменения и удаления информации, которая используется в ПО;

б) затем подключаются модули, обработки информации, проверки доступа пользователя и модули, реализующие функциональные требования к ПО, с учётом их приоритета.

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

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

В этом документе определяется содержание работ по проектированию и выполнении тестирования программного продукта.

Разделы тестового плана определяются стандартом IEEE 829 и указаны ниже.

Идентификатор тестового плана. Это уникальное имя или номер плана.

Введение. В этом разделе приведены ссылки на объединенные стандарты, а также плановые документы на программный продукт.

Тестируемые элементы – э то подлежащие тестированию программные компоненты – функции, модули, возможности и т.д.,

Тестируемые функции. Их следует обеспечить ссылками на спецификацию комплекса тестов.

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

Критерии прохождения тестов. Способы определения про­шло ли ПО конкретный тест.

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

Документация. Это список всех тестовых документов, которые дол­жны быть составлены для спецификации данного продукта.

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

Необходимое оборудование. Перечень всего необходимого для работы аппаратное и программное обеспечение, лабораторное оборудование и т.д.

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

Календарный план. Ключевые даты, сроки выполнения работ, сроки поставки необходимых ресурсов

Риск и непредвиденные обстоятельства. Перечень наихудших пред­положений, касающихся выполнения тестового плана, меры, которые будут предприняты в этом случае.

Утверждение. Руководитель, который утверждает тестовый план и место для его подписи.

План интеграционного тестирования

В этом плане обязательно надо дополнительно указать.

Объект тестирования: модули системы и взаимосвязь между ними.

Цель интеграционного тестирования:

· проверка информационных связей модулей;

· проверка наличия таблиц и связей между ними;

· нахождение ошибок в интерфейсе между модулями;

· нахождение ошибок в интерфейсах между функциями и модулями.

Критерий окончания – отсутствие ошибок в информационных связях при прохождении тестирования.

Стратегию (последовательность) подключения модулей.

Модули, потенциально содержащих максимальное число ошибок.