Лекция 6 Количественные критерии качества тестирования Соотношение качества

Скачать презентацию Лекция 6 Количественные критерии качества тестирования Соотношение качества Скачать презентацию Лекция 6 Количественные критерии качества тестирования Соотношение качества

14488-tpo_08.ppt

  • Количество слайдов: 24

>Лекция 6 Количественные критерии качества тестирования Лекция 6 Количественные критерии качества тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Елки-палки, когда же заканчивать тестирование? Полезные критерии окончания тестирования все-таки существуют: График ошибок Статистика Елки-палки, когда же заканчивать тестирование? Полезные критерии окончания тестирования все-таки существуют: График ошибок Статистика затрат на исправление ошибок Методика подсадки ошибок Методика тестирования двумя группами Все эти методы основаны на статистических предсказаниях количества неисправленных (или даже ненайденных!) ошибок

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

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

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

>Предсказание плотности ошибок Предпредыдущий проект – GigaTron 1.0:  100,000 строк кода 650 ошибок Предсказание плотности ошибок Предпредыдущий проект – GigaTron 1.0: 100,000 строк кода 650 ошибок было найдено до выпуска версии 50 ошибок было найдено после выпуска версии Средняя плотность ошибок – 7 штук на 1,000 строк (KLOC) Предыдущий проект – GigaTron 2.0 Дописали еще 50,000 строк 450 ошибок было найдено до выпуска версии 75 ошибок было найдено после выпуска версии Средняя плотность ошибок – 9.5 на 1,000 строк (KLOC) GigaTron 3.0: 100,000 новых строк кода 600 ошибок уже найдено (6 ошибок на 1,000 строк кода) Пора ли уже заканчивать тестирование?

>Тестирование независимыми группами 400 багов  (250 только в А) 350 багов  (200 Тестирование независимыми группами 400 багов (250 только в А) 350 багов (200 только в B) DefectsTotal = (DefectsA * DefectsB) / DefectsA+B

>Подсадка ошибок DefectsTotal = (DefectsSeeded / DefectsSeededFound) * DefectsFoundSoFar Подсадка ошибок DefectsTotal = (DefectsSeeded / DefectsSeededFound) * DefectsFoundSoFar

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

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