ГОСТ Р 56922-2016/ISO/IEC/IEEE 29119-3:2013. Национальный стандарт Российской Федерации. Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

Приложение G

(справочное)

 

ОТЧЕТ О ХОДЕ ТЕСТИРОВАНИЯ

 

G.1 Пример 1 - Корпорация Agile

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

 

Сводный Отчет о Ходе Тестирования для: Новая система подписки (NSS). Версия: Итерация 3. Покрытие: Результаты завершенной итерации NSS 3. Прогресс по сравнению с Планом Тестирования: Тестирование было сделано в итерации на пяти историях пользователя для этой итерации. Для одного высокого риска покрытие операторов достигло 90% истории, и для других было достигнуто в среднем 68% покрытия операторов. Неразрешенных дефектов с уровнем серьезности 1 и 2 нет, но презентация показала, что продукт имеет 16 дефектов с уровнем серьезности 3. Факторы, блокирующие прогресс: Нет. Показатели тестирования: Были разработаны 6 новых процедур тестирования, а 2 другие процедуры тестирования были изменены. Тестирование в итерации заняло приблизительно 30% времени. Тестирование заняло приблизительно 2 1/2 часа. Новые и измененные риски: Риски для историй были обработаны удовлетворительно. Новых рисков не идентифицировано. Запланированное тестирование: Согласно Плану Тестирования. В портфель добавлено: 16 дефектов (серьезность 3).

 

G.2 Пример 2 - Traditional Ltd

Traditional Ltd - небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Проект продукта - Блок для ПК UV/TIT-14 33a

Отчет о Ходе Тестирования системы V 1.0, 22.03.2004

Ход тестирования 22 марта 2004 г.

Отчетный период: 15 - 21 марта 2004 г.

Прогресс по сравнению с Планом Тестирования: Были проверены функциональности "XX" модуля приложения.

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

Числа записей в блоке: Нет.

Показатели тестирования:

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

 

 

В нижеследующих таблицах приводятся полученные показатели, где обозначены: P1, P2 ... P6 - приоритеты. P1 является самым высоким.

 

Ежедневные показатели выполнения контрольных примеров

 

&Описание&	&Количество&	&%&
Общее количество контрольных примеров, выполненных сегодня, фактически	30
Количество успешных контрольных примеров	27	90
Количество неуспешных контрольных примеров	3	10

 

Накопительные показатели выполнения контрольных примеров

 

&Описание&	&Количество&	&%&
Общее количество запланированных контрольных примеров	151	100
Общее количество контрольных примеров, выполненных на данный момент	38	25,17
Общее количество успешных контрольных примеров из числа выполненных	34	89,47
Общее количество неуспешных контрольных примеров из числа выполненных	4	10,53
Общее количество ожидающих контрольных примеров	113	74,83

 

Ежедневная сводка дефектов

 

&Описание&	Общее количество	P1	P2	P3	P4	P5	P6
Общее количество дефектов в течение дня	5	0	0	4	1	0	0
Количество новых дефектов	5	0	0	4	1	0	0
Количество повторно проверенных и закрытых дефектов	8	0	0	4	3	1	0
Количество повторно открытых дефектов	1	0	0	0	1	0	0

 

Накопительная сводка дефектов

 

&Описание&	Общее количество	P1	P2	P3	P4	P5	P6
Количество дефектов на данный момент	42	0	9	21	10	2	0
Количество отклоненных дефектов на данный момент	1	0	0	1	0	0	0
Количество дефектов, фиксированных на данный момент	31	0	7	16	6	2	0
Количество дефектов, повторно проверенных и закрытых на данный момент	32	0	7	16	7	2	0
Количество дефектов, открытых/ожидающих на данный момент	10	0	2	6	2	0	0

 

Новые и измененные риски: Нет.

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

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