Тестирование программного обеспечения. Базовый курс. 3-е издание

Тест-план и отчёт о результатах тестирования
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 214/301 
Чтобы оперировать всеми этими числами (а они нужны не только для отчёт-
ности, но и для организации работы проектной команды), их нужно как-то вычис-
лить. Именно это и позволяют сделать метрики. Затем вычисленные значения 
можно использовать для: 
•
принятия решений о начале, приостановке, возобновлении или прекращении 
тестирования (см. выше раздел «Критерии» тест-плана); 
•
определения степени соответствия продукта заявленным критериям каче-
ства; 
•
определения степени отклонения фактического развития проекта от плана; 
•
выявления «узких мест», потенциальных рисков и иных проблем; 
•
оценки результативности принятых управленческих решений; 
•
подготовки объективной информативной отчётности; 
•
и т.д. 
Метрики могут быть как прямыми (не требуют вычислений), так и расчётными 
(вычисляются по формуле). Типичные примеры прямых метрик — количество раз-
работанных тест-кейсов, количество найденных дефектов и т.д. В расчётных мет-
риках могут использоваться как совершенно тривиальные, так и довольно сложные 
формулы (см. таблицу 2.6.1). 
Таблица 2.6.1 — Примеры расчётных метрик 
Простая расчётная метрика 
Сложная расчётная метрика 
𝑇
𝑆𝑃
=
𝑇
𝑆𝑢𝑐𝑐𝑒𝑠𝑠
𝑇
𝑇𝑜𝑡𝑎𝑙
∙ 100%
, 
где 
𝑇
𝑆𝑃
— процентный показатель успеш-
ного прохождения тест-кейсов, 
𝑇
𝑆𝑢𝑐𝑐𝑒𝑠𝑠
— количество успешно выпол-
ненных тест-кейсов, 
𝑇
𝑇𝑜𝑡𝑎𝑙
— общее количество выполнен-
ных тест-кейсов. 
Минимальные границы значений: 
•
Начальная фаза проекта: 10 %. 
•
Основная фаза проекта: 40 %. 
•
Финальная фаза проекта: 85 %. 
𝑇
𝑆𝐶
= ∑
(𝑇
𝐿𝑒𝑣𝑒𝑙
∙𝐼)
𝑅𝐿𝑒𝑣𝑒𝑙
𝐵
𝐿𝑒𝑣𝑒𝑙
𝑀𝑎𝑥𝐿𝑒𝑣𝑒𝑙
𝐿𝑒𝑣𝑒𝑙
, где 
𝑇
𝑆𝐶
— интегральная метрика прохождения тест-кейсов 
во взаимосвязи с требованиями и дефектами, 
𝑇
𝐿𝑒𝑣𝑒𝑙
— степень важности тест-кейса, 
𝐼
— количество выполнений тест-кейса, 
𝑅
𝐿𝑒𝑣𝑒𝑙
— степень важности требования, проверяемого 
тест-кейсом, 
𝐵
𝐿𝑒𝑣𝑒𝑙
— количество дефектов, обнаруженных тест-кей-
сом. 
Способ анализа: 
•
Идеальным состоянием является непрерывный рост 
значения 
𝑇
𝑆𝐶
. 
•
В случае отрицательной динамики уменьшение значе-
ния 
𝑇
𝑆𝐶
на 15 % и более за последние три спринта мо-
жет трактоваться как недопустимое и являться доста-
точным поводом для приостановки тестирования. 
В тестировании существует большое количество общепринятых метрик, мно-
гие из которых могут быть собраны автоматически с использованием инструмен-
тальных средств управления проектами. Например
339
: 
•
процентное отношение (не) выполненных тест-кейсов ко всем имеющимся; 
•
процентный показатель успешного прохождения тест-кейсов (см. «Простая 
расчётная метрика» в таблице 2.6.1); 
•
процентный показатель заблокированных тест-кейсов; 
•
плотность распределения дефектов; 
•
эффективность устранения дефектов; 
•
распределение дефектов по важности и срочности; 
•
и т.д. 
339
«Important Software Test Metrics and Measurements — Explained with Examples and Graphs» [
http://www.softwaretest-
inghelp.com/software-test-metrics-and-measurements/
] 

Тест-план и отчёт о результатах тестирования
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 215/301 
Как правило, при формировании отчётности нас будет интересовать не 
только текущее значение метрики, но и её динамика во времени, которую очень 
удобно изображать графически (что тоже могут выполнять автоматически многие 
средства управления проектами). 
Некоторые метрики могут вычисляться на основе данных о расписании, 
например метрика «сдвига расписания»: 
𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒 =
𝐷𝑎𝑦𝑠𝑇𝑜𝐷𝑒𝑎𝑑𝑙𝑖𝑛𝑒
𝑁𝑒𝑒𝑑𝑒𝑑𝐷𝑎𝑦𝑠
− 1
, 
где
𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒
— значение сдвига расписания,
𝐷𝑎𝑦𝑠𝑇𝑜𝐷𝑒𝑎𝑑𝑙𝑖𝑛𝑒
— количество дней до запланированного завершения работы,
𝑁𝑒𝑒𝑑𝑒𝑑𝐷𝑎𝑦𝑠
— количество дней, необходимое для завершения работы. 
Значение 
𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒
не должно становиться отрицательным.
Таким образом, мы видим, что метрики являются мощнейшим средством 
сбора и анализа информации. И вместе с тем здесь кроется опасность: ни при каких 
условиях нельзя допускать ситуации «метрик ради метрик», когда инструменталь-
ное средство собирает уйму данных, вычисляет множество чисел и строит десятки 
графиков, но… никто не понимает, как их трактовать. Обратите внимание, что к 
обеим метрикам в таблице 2.6.1 и к только что рассмотренной метрике 
𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒
прилагается краткое руководство по их трактовке. И чем сложнее 
и уникальнее метрика, тем более подробное руководство необходимо для её эф-
фективного применения. 
И, наконец, стоит упомянуть про так называемые «метрики покрытия», т.к. 
они очень часто упоминаются в различной литературе. 

жүктеу/скачать 5,03 Mb.

Достарыңызбен бөлісу: