Этапы и стратегии тестирования
Автономное тестирование модулей выполняется по мере их готовности.
Комплексное, или интеграционное тестирование допускает три стратегии:
Восходящее тестирование применяется последовательно к постепенно наращиваемым снизу-вверх совокупностям модулей. Оно требует написания специальных кодов-оболочек (отладочных программ) и заглушек, подменяющих еще не готовые модули.
Нисходящее тестирование, наоборот, начинается с интеграции модулей верхнего уровня. Оно не требует специальных отладочных программ, но заглушки нужны.
Обычно стратегия тестирования согласована со стратегией разработки.
Целостное тестирование – «разовый штурм»: до полной интеграции системы ее модули не проходят особо тщательного тестирования. Это наиболее экономная стратегия (не нужны заглушки и оболочки), но в целом наименее эффективная. Вопрос 5.
Документирование и анализ ошибок
Вариант структуры отчета об ошибке (Вug report), рекомендуемой в [2]:
<А. Пункты, заполняемые сотрудником, обнаружившим ошибку >
№ ошибки
Программа (с указанием версии и даты выпуска)
Тип отчета (1- 6)
Ошибка кодирования
Ошибка проектирования
Предложение
Расхождение с документацией
Взаимодействие с аппаратурой
Вопрос
Степень важности (1-3)
Фатальная
Серьезная
Незначительная
Приложения (да/нет)
Распечатки результатов, копии экрана, тестовые программы или данные.
Проблема
Краткое описание сути проблемы
Воспроизводимость (да, нет, не всегда)
Подробное описание проблемы и способ ее воспроизведения
Описание входных данных и действий, приводящих к ошибке. Если ошибка не воспроизводится, описание попыток воспроизвести ее снова.
Предлагаемое исправление (необязательный пункт)
Сотрудник (фамилия)
Дата обнаружения
(Отчет об ошибке следует составлять немедленно при ее обнаружении.)
<Б. Пункты, предназначенные в основном для разработчиков>
Функциональная область Категория ошибки с точки зрения разработчиков
Поручено Ответственный за исправление (заполняется руководителем проекта)
Комментарии Поле для обсуждения сотрудниками
Состояние (1-2)
Открыто (начальное состояние при написании отчета)
Закрыто (устанавливается тестером, подтверждающим исправление)
Приоритет (1-6) заполняется руководителем проекта
Исправить немедленно – ошибка задерживает работу остальных
Исправить как можно быстрее
Исправить в текущей версии
Исправить до выхода окончательной версии
Исправить, если возможно
Не обязательно исправлять
Резолюция (1-6)
Рассматривается (устанавливается руководителем проекта)
Исправлено (устанавливается программистом)
Не воспроизводится (устанавливается программистом)
Отложено (устанавливается руководителем проекта)
Соответствует проекту (устанавливается программистом или руководителем проекта)
Нужна дополнительная информация (у программиста есть вопросы к тестеру)
Исправленная версия № и дата версии
Рассмотрено/дата Сотрудник, решивший проблему
(он устанавливает резолюцию «Исправлено»)
Проконтролировано/дата Тестер, согласный с резолюцией
(он устанавливает состояние «Закрыто»)
Исходное состояние отчета – «Открыто». В состояние «Закрыто» его переводит тестер, проверивший исправление или согласившийся с резолюцией «Соответствует проекту». На рис. 10-4 приведена диаграмма состояний и переходов пункта «Резолюция», где у каждого перехода указано, кто его инициирует. Вопрос 6.
Рук. проекта Рук. проекта
Исходное
Рук. проекта
Тестер
Не
воспро- изводится или
Есть вопросы
Соответст- вует
проекту
Исправле- но
Отложено
Рассматри- вается
Тестер Руков. Тестер Программист
проекта
Рис. 10-4. Диаграмма состояний и переходов пункта «Резолюция» отчета об ошибке
В безбумажной системе отчеты накапливаются в базе данных коллективного доступа (существуют специальные системы управления ими, напр., Bugzilla). Вопрос 7. Такая база данных является ядром системы отслеживания проблем и управления качеством продуктов.