Slide 1 Количественные критерии качества тестирования. - презентация

1 Slide 1 Количественные критерии качества тестирования

2 Slide 2 Соотношение качества программы и времени разработки l Good Enough Quality vs. Absolute Quality l Интуитивно кажется, что чем больше времени затрачивается на разработку, тестирование и отладку, тем лучше качество получаемой программы l Однако оказывается, что существует точка оптимального соотношения "цена/качество" программы (см. след. график)

3 Slide График Время разработки % исправленных ошибок 95 "Applied Software Measurement", Capers Jones, 1991

4 Slide 4 Неожиданные свойства качества l Получается, что проекты с небольшим количеством допустимых ошибок также являются проектами с минимальным временем выполнения l Проекты, в которых ошибок больше минимально допустимого, тратят много времени на доводку продукта (причем стоимость исправления ошибок в таких проектах выше) l Итак, существует некоторое оптимальное качество программного обеспечения. Оно соответствует исправлению ~95% найденных ошибок

5 Slide 5 Точка оптимального качества l Точка 95% представляет собой достижение уровня, на котором большинство проектов достигает минимального времени выполнения затрачивает минимальные усилия достигает приемлемого качества продукта l Таким образом, можно сформулировать первый критерий управления качеством: если после выпуска продукта обнаруживается более 5% ошибок, то вашу организацию преследуют проблемы, связанные с качеством, и кроме того, с большой вероятностью вы тратите больше времени на разработку продукта, чем это необходимо

6 Slide 6 Недостаток времени l Чаще всего проблемы с качеством ПО возникают в проектах, выполняющихся в спешке l Синдром "десяти дней до сдачи" и срезания углов при разработке: впоследствии все равно приходится все перерабатывать, что связано с большим количеством повторной работы l Практика показывает, что в проектах с чрезмерными требованиями по времени возникает в 4 раза больше ошибок, чем в нормальных. Таким образом, решение в начале проекта не тратить слишком много времени на обеспечение качества продукта просто перекладывает эти задачи на более позднюю часть проекта

7 Slide 7 Об абсолютном качестве l С другой стороны, концепция "абсолютного качества", которую мы будем понимать как требование обнаружения и исправления более 98% ошибок, действительно замедляет проект (см. график) l Нахождение и исправление "почти всех" ошибок – трудоемкий и дорогостоящий процесс l "Абсолютное качество" имеет смысл только для проектов с повышенными требованиями к надежности ПО (mission-critical software) l Актуально в таких областях, как системы управления и контроля, аэрокосмические приложения и т.п.

8 Slide 8 Критерий 6Σ l Традиционная формализация требований "абсолютного качества" – критерий 6Σ (например, Motorola) l По определению, Σ означает единицу стандартного отклонения при нормальном распределении вариативности в каком-либо процессе. l Критерий 6Σ фиксирует максимально допустимое отношение количества допущенных ошибок к общему количеству возможностей допустить ошибку l Для обычных тиражируемых продуктов этот критерий можно записать как максимальное приемлемое отношение числа дефектных экземпляров к общему числу выпущенных

9 Slide 9 Применимость 6Σ к ПО l Неясно, как применить этот критерий к программному обеспечению l Программное обеспечение состоит из тысяч или миллионов строк кода, и каждая строчка потенциально может содержать ошибку. l Получается, что каждая буква и каждое слово являются потенциальным источником ошибки l По этой причине критерий 6Σ еще не получил общепринятого определения в программировании

10 Slide 10 6Σ как "плотность ошибок" l Чаще всего критерий шести сигм формулируют в терминах максимально допустимого количества ошибок на фиксированный объем строк ("плотность ошибок") l Для того, чтобы можно было сравнивать плотности ошибок в программах, написанных на разных языках программирования, исходный код программы предварительно приводится к эквивалентному ассемблерному коду путем применения стандартных масштабирующих коэффициентов В следующей таблице приведено среднее количество ошибок на миллион строк эквивалентного ассемблерного кода, соответствующие различным критериям сигмы

11 Slide 11 Сигмы и количество допустимых ошибок на миллион строк кода l Средний программный продукт содержит при выпуске ~10 ошибок на 1,000 строк кода. Предположим, что мы писали на Паскале, тогда нам надо разделить количество ошибок на 3.5 для получения среднего количества ошибок на одну строчку ассемблерного кода. Это даст нам 2.9 ошибок на 1,000 строк, или 2,900 ошибок на миллион строк. Таким образом, качество среднего продукта хуже критерия 6Σ в 850 раз l Более крупные системы обычно содержат большее количество ошибок! l Для соответствия критерию шести сигм типичная система, написанная на С и состоящая из 100,000 строк, должна содержать не более одного дефекта Σошибки 1697, , ,810 46,

12 Slide 12 Когда необходимо заканчивать тестирование программы? l Не представляется возможным определить, является ли найденная ошибка последней l Тем не менее, тестирование придется завершать, хотя бы по экономическим соображениям l Этот вопрос можно решать: либо волевым способом (решение руководителя), что очевидно не ведет к улучшению качества продукта либо с помощью некоторого критерия завершения тестирования (какого?)

13 Slide 13 Неудачные критерии завершения тестирования l Наиболее распространенными критериями завершения тестирования являются: истечение времени, отведенного на тестирование все тесты выполняются без выявления ошибок l Оба критерия никуда не годятся: Первый критерий может быть выполнен без каких-либо действий (т.е. он не содержит оценки качества тестирования) Второй не имеет смысла, поскольку не зависит от качества тестов и, следовательно, подсознательно побуждает к построению тестов с низкой вероятностью обнаружения ошибки. Люди всегда ориентируются на поставленную цель и, значит, тестеры, скорее всего, будут писать неудачные тесты

14 Slide 14 Критерии, основанные на методологии тестирования l Несколько лучше (но все же недостаточно хороши) критерии, основанные на использовании определенных методологий проектирования тестов l Например, можно потребовать исчерпывающего тестирования модулей с помощью тестов, получаемых двумя путями: удовлетворением комбинаторного критерия покрытия методом анализа граничных значений по спецификации интерфейса модуля l а также потребовать, чтобы все функции были протестированы следующими методами: методом функциональных диаграмм методом анализа граничных значений методом предположения об ошибке l Критерий: неудачное завершение всех этих тестов

15 Slide 15 Критика методологических критериев l Применение методологических критериев также проблематично: Во-первых, вместо того, чтобы поставить цель и дать возможность выбора наиболее подходящего пути ее достижения, рассмотренные критерии предписывают использование конкретных методологий проектирования тестов, но не ставят никакой цели Во-вторых, такое измерение субъективно, так как нет гарантии, что тестировщик использовал нужную методологию правильно и точно. l Поэтому такой подход к тестированию имеет лишь ограниченную ценность

16 Slide 16 Типичный сценарий выпуска ПО Beta Bug Convergence Zero-Bug Release Release Candidate Golden Release Release 0 Active Bugs Time

17 Slide 17 График ошибок Ошибки Время Найденные Открытые Исправленные

18 Slide 18 Статистика затрат на исправление ошибок l Полезно собирать данные о стоимости исправления тех или иных ошибок l В таком случае уже в середине проекта можно говорить, что "у нас есть 230 открытых ошибок и разработчики в среднем тратят на исправление одной ошибки 3 часа, следовательно, нам остается затратить около 700 часов на исправление известных ошибок" l Естественно, в реальной жизни надо также учитывать допущение и обнаружение новых ошибок l Кроме того, полезно собирать информацию о фазах проекта, в которых мы допускали ошибки

19 Slide 19 Тестирование независимыми группами 400 багов (250 только в А) 350 багов (200 только в B) Defects Total = (Defects A * Defects B ) / Defects A+B

20 Slide 20 Подсадка ошибок Defects Total = (Defects Seeded / Defects SeededFound ) * Defects FoundSoFar

21 Slide 21 Гипотеза о слабых модулях l Брукс: в 4% кода OS/360 найдено 47% ошибок. l Jones, 1991: IBM опубликовало данные о том, что в 7% модулей, созданных в процессе написания базы данных IMS, было найдено 57% ошибок. l Обычно справедливо правило 20/80 ("20% людей выпивают 80% пива"; "20% модулей содержат 80% ошибок") l Модули с большим количеством ошибок обходятся значительно дороже обычных: при разработке среднего модуля необходимо затратить от $500 до $1000 на один function-point

22 Slide 22 Переписывание слабых модулей l Зачастую такие модули проще переписать, чем отлаживать. При разработке плана проекта необходимо заранее выделить специальное время под подобную деятельность (от 5 до 10% от общего времени проекта, записать в риски проекта) l Затем в процессе инспекций необходимо обращать внимание на модули, в которых более 10 ошибок на 1,000 строк кода; возможно, эти модули подлежат переписыванию