Программные продукты и системы

Известно, что участники проекта программного изделия (ПИ) в ходе его выполнения всегда допускают ошибки [1]. Допустимое количество ошибок в проекте ПИ зависит от уровня качества разработки, от размера нового кода ПИ и уровня качества поставляемого ПИ [2]. Часть допущенных ошибок в проекте ПИ находится и устраняется на фазах жизненного цикла разработки ПИ во время проведения плановых обзоров продуктов проекта [3], а оставшаяся часть ошибок превращается в дефекты разработки, которые переходят в дефекты программного кода ПИ и дефекты сопровождающей этот код документации (переходят в дефекты ПИ).

Для обнаружения оставшихся в ПИ дефектов с целью их последующего устранения сами разработчики подвергают ПИ нескольким видам тестирования [5]: модульному, интеграционному и тестированию работоспособности. Эти виды тестирования предназначены для отладки сборки версии ПИ и подтверждения соответствия отлаженной версии ПИ спецификациям функционального проектирования. В литературе процесс модульного, интеграционного тестирования и тестирования работоспособности называют верификацией ПИ.

ПИ также подвергают системному тестированию. Этот вид тестирования используют для подтверждения работоспособности поставляемого ПИ и его соответствия требованиям заказчика. Системное тестирование, как правило, выполняет специальная группа системного тестирования. Процесс системного тестирования в литературе часто называют валидацией ПИ.

Рассмотрим более подробно процесс обнаружения дефектов во время проведения всех видов тестирования. Для этого обратимся к рисункам 1 и 2.

На рисунке 1 представлено распределение обязанностей между разработчиками ПИ и системными тестировщиками во время тестирования ПИ, принятое в АОЗТ ИДУ.

На рисунке 2 представлено распределение трудоемкости отдельных фаз жизненного цикла разработки ПИ и распределение количества ошибок, которое допускают участники проекта на этих фазах. Распределения получены на реальных данных АОЗТ ИДУ [2]. График представлен для случая выполнения разработки ПИ с уровнем качества 4 сигма и уровнем качества поставляемого ПИ 5 сигма [6].

По оси абсцисс последовательно отложены трудоемкости (в %) фаз жизненного цикла разработки ПИ (без учета фазы "Системное тестирование"). Отдельно выделен этап 4. Трудоемкость этапа 4 представляет собой сумму трудоемкости выявления и устранения ошибок в проекте; выявления и устранения некоторого числа, необязательно всех дефектов на каждой из фаз разработки ПИ (модульное и интеграционное тестирование, тестирование работоспособности); устранения всех дефектов, обнаруженных в процессе системного тестирования.

Трудоемкость выявления ошибок на фазах 1, 2, 3 представляет собой сумму трудоемкости проведения обзоров продуктов проекта, трудоемкости выявления и анализа причин возникновения ошибок в прошлом и трудоемкости по выработке мер для устранения обнаруженных причин возникновения ошибок в будущем.

По оси ординат графика отложены значения оценок допустимого на различных фазах разработки ПИ числа ошибок (в % от величины оценки допустимого количества ошибок в проекте) – возрастающая часть графика – и оценка количества обнаруженных и устраненных ошибок и дефектов на тех же фазах – нисходящая часть графика.

Первым видом тестирования, которому подвергается ПИ разработчиками (рис. 1), является модульное тестирование. Вероятность обнаружения дефектов в модулях достаточно велика, поскольку ошибок и дефектов еще много (рис. 2). После завершения модульного тестирования, когда устранены все обнаруженные дефекты в тестируемых программных модулях, вероятность присутствия каждого из оставшихся дефектов в модулях повышается. Однако вероятность обнаружения оставшихся дефектов в ПИ на этапе интеграционного тестирования за счет уменьшения их коли-чества меньше, чем на этапе модульного тестирования.

Тестирование работоспособности ПИ является заключительным этапом отладки (рис. 1) и предназначено для выяснения работоспособности ПИ и соответствия его спецификациям проектирования (осуществляется окончательная верификация ПИ). При этом вероятность обнаружения оставшихся дефектов меньше, чем на этапе интеграционного тестирования, также за счет уменьшения их числа в программном коде.

После завершения отладки базовой версии ПИ (рис. 1) в ней, как правило, устранены все обнаруженные дефекты. Вероятность присутствия каждого из оставшихся дефектов в отлаженной базовой версии ПИ, передаваемой на системное тестирование, увеличивается по сравнению с вероятностью присутствия каждого дефекта в сборке ПИ на этапе ее отладки. Однако вероятность обнаружения дефектов в ней уменьшается.

Теоретически это происходит потому, что дефекты, присутствующие в ПИ, сколько бы их ни было, можно рассматривать как случайные несовместные события, составляющие полную группу [6]. Таким образом, сумма вероятностей присутствия оставшихся дефектов в сборке ПИ всегда равна единице:

,                                                    (1)

где Pi – вероятность присутствия i-го оставшегося дефекта в сборке ПИ; n – число оставшихся дефектов.

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

Как следует из рисунка 2, после модульного тестирования 0.23N<< n <6.21N, а после интеграционного тестирования и тестирования работоспособности число оставшихся дефектов в ПИ становится меньше этого значения. Поэтому вероятность обнаружения любого из оставшихся дефектов в сборке ПИ на этапе системного тестирования меньше, чем на этапе отладки. И эта вероятность тем меньше, чем меньше осталось дефектов в сборке ПИ после ее отладки:

                                                (2)

где Pk – вероятность обнаружения одного оставшегося дефекта в сборке ПИ на этапе системного тестирования; Pi – вероятность присутствия i-го оставшегося дефекта в сборке ПИ, переданной для проведения системного тестирования; n – число оставшихся дефектов в сборке ПИ, переданной для проведения системного тестирования, 0.23N> n (рис. 2).

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

Соотношение (2) показывает также, что с увеличением числа обнаруженных при системном тестировании дефектов вероятность обнаружения оставшихся в ПИ дефектов уменьшается (это справедливо для ПИ большого размера – сотни и тысячи KELOC). Когда в сборке ПИ в результате системного тестирования остается очень мало дефектов (n < 0.23N), сумма вероятностей их присутствия в сборке все равно равна единице, а вероятность обнаружения любого из них близка к нулю. Поэтому практически невозможно выявить все дефекты в тестируемом ПИ, а системное тестирование выполняется циклически, и для принятия решения об окончании системного тестирования используют специальные критерии [4].

Здесь необходимо заметить, что во время системного тестирования для обнаружения дефекта всегда приходится много раз (иногда десятки тысяч раз и более) охватывать тестами весь объем кода ПИ. Это происходит потому, что во время системного тестирования ПИ тестированию подвергаются многие (иногда практически все) пути ветвления программы, а при высокой логической сложности ПИ таких путей может быть десятки и сотни тысяч.

Наш опыт показывает, что для достижения целей системного тестирования, обеспечения высокого качества поставляемого ПИ и эффективного управления процессом обнаружения и устранения ошибок и дефектов в проекте ПИ следует ввести специальные метрики разработки ПИ. В соответствии с рисунком 2 – это число найденных (предъявленных), неустраненных (открытых) и устраненных (закрытых) ошибок и дефектов. Необходимо также обеспечить регулярный сбор этих метрик во время выполнения проекта ПИ с его начала и до его окончания, а по результатам метрических данных строить график (рис. 3).

График целесообразно обновлять еженедельно. При этом следует стремиться к тому, чтобы к окончанию любой фазы жизненного цикла разработки, показанной на рисунке 2, было найдено и закрыто такое количество ошибок и дефектов, которое соответствовало бы метрикам стандартного процесса этой фазы [4].

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

В заключение отметим, поскольку во время системного тестирования ПИ большого размера (сотни тысяч KAELOC) вероятность обнаружения последних дефектов очень мала, то для их обнаружения потребуется очень много времени. Поэтому практически нецелесообразно выполнять системное тестирование до победного конца, то есть до обнаружения последнего дефекта. А для определения момента завершения системного тестирования следует использовать специальные критерии, например так, как изложено в [6].

Список литературы

1. Barry W. Boehm. Software Engineering Economics. 1981 by Prentice-Hall, Inc., Englewood Cliffs, N.J. 07632.

2. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ. //Программные продукты и системы. – 1998. - №2. - С.2-6.

3. Домарацкий А.Н. Управление улучшением стандартного процесса и качеством программных изделий. //Программные продукты и системы. – 1998. - № 4. - С. 20-24.

4. Домарацкий А.Н., Никифоров В.В. Критерии завершения тестирования ПИ. //Там же . - С. 30-33.

5. Myers G.J. The Art of Software Testing. - New York: John Wiley & Sons, 1979. - 177 p.

6. Пугачев В.С. Теория случайных функций. - М.: Гос. изд. физ.-мат. лит., 1960. - 883 с.