Тестирование правильности.

Сравнение нисходящего и восходящего тестирования интеграции

Табл. 2.2.

	Нисходящее тестирование	Восходящее тестирование
Достоинства	Раннее тестирование главных управляющих функций	Упрощается разработка тестовых вариантов, отсутствуют заглушки
Недостатки	Необходимость заглушек и связанные с ними трудности тестирования	Система не существует как объект до тех, пока не будет добавлен последний модуль

 

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

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

Критические модули должны тестироваться как можно раньше. Кроме того, к ним должно применяться регрессионное тестирование (повторное выполнение ранее проведенных тестов в полном или частичном объеме).

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

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

Важным элементом подтверждения правильности является проверка конфигурации программного средства (а фактически и единственным действительно работающим способом проверки правильности).

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

1)системная спецификация;

2)план программного проекта;

3)спецификацию требований к ПС; работающий или бумажный макет;

4)предварительное руководство пользователя;

5)спецификация проектирования;

6)листинги исходных текстов программ;

7)план и методику тестирования; тестовые варианты и полученные результаты;

8)руководства по работе и инсталляции;

9)exe — код выполняемой программы;

10)описание базы данных;

11)руководство пользователя по настройке;

12)документы сопровождения; отчеты о проблемах ПС; запрос сопровождения; отчеты о конструкторских изменениях;

13)стандарты и методики конструирования ПС.

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

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

Альфа — тестирование проводиться заказчиком в организации разработчика. Разработчик фиксирует все выявленные заказчиком ошибки и проблемы использования.

Бета — тестирование проводиться конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает. Фактически, бета — тестирование — это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бета — тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПС и тем самым подготавливает продукт полностью на безе заказчика (это в теории, а на практике т.н. бета-тестирование заменяет собой все другие виды тестирования, а сообщения заказчика об обнаруженных проблемах разработчик спокойно отправляет в корзину, что и приводит к нынешнему катастрофическому уровню качества проприетарного ПО).