Как называется деятельность направленная на обнаружение и исправление ошибок

11

Лишь
та — ошибка, что
не
исправляется.

Конфуций

Основные
понятия. Стратегия проектирования
тестов. Заповеди
отладки.
Автономная отладка и тестирование
программного модуля.
Комплексная
отладка и тестирование программного
средства.

10.1. Основные понятия.

Отладка
ПС 
это деятельность, направленная на
обнаружение
и
исправление ошибок в ПС с использованием
процессов выполнения
его
программ. Тестирование
ПС 
это процесс выполнения его программ на
некотором наборе данных, для которого
заранее известен
результат
применения или известны правила поведения
этих программ. Указанный набор данных
называется тестовым
или просто тестом.
Таким образом, отладку можно представить
в виде многократного повторения трех
процессов: тестирования, в результате
которого может быть констатировано
наличие в ПС ошибки, поиска места
ошибки
в программах и документации ПС и
редактирования программ
и
документации с целью устранения
обнаруженной ошибки. Другими
словами:

Отладка = Тестирование
+ Поиск ошибок + Редактирование.

В
зарубежной литературе отладку часто
понимают [10.1-10.3]
только
как процесс поиска и исправления ошибок
(без тестирования), факт наличия которых
устанавливается при тестировании.
Иногда
тестирование и отладку считают синонимами
[10.4,10.5]. В
нашей
стране в понятие отладки обычно включают
и тестирование
[10.6
-10.8],
поэтому мы будем следовать сложившейся
традиции.
Впрочем,
совместное рассмотрение в данной лекции
этих процессов
делает
указанное разночтение не столь
существенным. Следует, однако, отметить,
что тестирование используется и как
часть процесса аттестации ПС (см. лекцию
14).

10.2. Принципы и виды отладки программного средства.

Успех
отладки ПС в значительной степени
предопределяет рациональная организация
тестирования. При отладке ПС отыскиваются
и
устраняются,
в основном, те ошибки, наличие которых
в ПС устанавливается при тестировании.
Как было уже отмечено, тестирование не
может доказать правильность ПС [10.9],
в лучшем случае
оно
может продемонстрировать наличие в нем
ошибки. Другими словами, нельзя
гарантировать, что тестированием ПС
практически выполнимым набором тестов
можно установить наличие каждой имеющейся
в ПС ошибки. Поэтому возникает две
задачи. Первая задача: подготовить такой
набор тестов и применить к ним ПС, чтобы
обнаружить в
нем по
возможности большее число ошибок. Однако
чем дольше продолжается процесс
тестирования (и отладки в целом), тем
большей
становится
стоимость ПС. Отсюда вторая задача:
определить момент
окончания
отладки ПС (или отдельной его компоненты).
Признаком
возможности
окончания отладки является полнота
охвата пропущенными через ПС тестами
(т.е. тестами, к которым применено ПС)
множества
различных ситуаций, возникающих при
выполнении программ ПС, и относительно
редкое проявление ошибок в ПС на последнем
отрезке процесса тестирования. Последнее
определяется в соответствии с требуемой
степенью надежности ПС, указанной в
спецификации его качества.

Для
оптимизации набора тестов, т.е. для
подготовки такого
набора
тестов, который позволял бы при заданном
их числе (или
при
заданном интервале времени, отведенном
на тестирование) обнаруживать большее
число ошибок в ПС, необходимо, во-первых,
заранее
планировать
этот набор и, во-вторых, использовать
рациональную
стратегию
планирования (проектирования [10.1])
тестов. Проектирование тестов можно
начинать сразу же после завершения
этапа
внешнего
описания ПС. Возможны разные подходы к
выработке стратегии проектирования
тестов, которые можно условно графически
разместить
(см. рис. 9.1) между следующими двумя
крайними подходами [10.1]. Левый крайний
подход заключается в том, что тесты
проектируются
только на основании изучения спецификаций
ПС
(внешнего
описания, описания архитектуры и
спецификации модулей). Строение модулей
при этом никак не учитывается, т.е. они
рассматриваются
как черные ящики. Фактически такой
подход требует полного перебора всех
наборов входных данных, так как в
противном случае некоторые участки
программ ПС могут не работать при
пропуске любого теста, а это
значит,
что содержащиеся в них ошибки не будут
проявляться. Однако
тестирование
ПС полным множеством наборов входных
данных практически неосуществимо.
Правый крайний подход заключается в
том,
что
тесты проектируются на основании
изучения текстов программ с
целью
протестировать все пути выполнения
каждой программ ПС. Если принять во
внимание наличие в программах циклов
с переменным
числом
повторений, то различных путей выполнения
программ ПС может оказаться также
чрезвычайно много, так что их тестирование
также
будет практически неосуществимо.

Рис. 10.1. Спектр
подходов к проектированию тестов.

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

• на
  каждую используемую функцию или
  возможность 
  хотя бы один тест,

• на
  каждую область и на каждую границу
  изменения какой-либо входной величины
  
  хотя бы один тест,

• на
  каждую особую (исключительную) ситуацию,
  указанную в спецификациях, 
  хотя бы один тест.

Во втором случае эта
стратегия базируется на принципе: каждая
команда каждой программы ПС должна
проработать хотя бы на одном тесте.

Оптимальную
стратегию проектирования тестов можно
конкретизировать на основании следующего
принципа: для каждого программного
документа (включая тексты программ),
входящего в состав ПС, должны проектироваться
свои тесты с целью выявления в нем
ошибок. Во всяком случае, этот принцип
необходимо соблюдать в соответствии с
определением ПС и содержанием понятия
технологии программирования как
технологии разработки надежных ПС (см.
лекцию 1). В связи с этим Майерс даже
определяет разные виды тестирования
[10.1] в зависимости от вида программного
документа, на основании которого
строятся тесты. В нашей стране различаются
[10.8]
два основных вида отладки (включая
тестирование): автономную и комплексную
отладку ПС.
Автономная
отладка ПС означает последовательное
раздельное тестирование различных
частей программ, входящих в ПС, с поиском
и исправлением в них фиксируемых при
тестировании ошибок. Она фактически
включает отладку каждого программного
модуля и отладку сопряжения модулей.
Комплексная
отладка означает тестирование ПС в
целом с поиском и исправлением фиксируемых
при тестировании ошибок во всех документах
(включая тексты программ ПС), относящихся
к ПС в целом. К таким документам относятся
определение требований к ПС, спецификация
качества ПС, функциональная спецификация
ПС, описание архитектуры ПС и тексты
программ ПС.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #

Отладка программы – это процесс поиска и устранения ошибок. Часть ошибок формального характера, связанных с нарушением правил записи конструкций языка или отсутствием необходимых описаний, обнаруживает транслятор, производя синтаксический анализ текста программы. Транслятор выявляет ошибки и сообщает о них, указывая их тип и место в программе. Такие ошибки называются ошибками времени трансляции или синтаксическими ошибками.

Ошибочные ситуации могут возникнуть и при выполнении программы, например, деление на нуль или извлечение корня квадратного из отрицательного числа. Такие ошибки называются ошибками времени выполнения.

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

Тестирование программы – это выполнение программы на наборах исходных данных (тестах), для которых известны результаты, полученные другим методом. Система тестов подбирается таким образом, чтобы

а) проверить все возможные режимы работы программы;

б) по возможности, локализовать ошибку.

При тестировании программы простой и действенный метод дополнительного контроля над ходом её выполнения – получение контрольных точек, т. е. контрольный вывод промежуточных результатов.

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

33. ВИДЫ ОШИБОК В ПРОГРАММАХ

Об ошибках в программе сигнализируют некорректная работоспособность программы либо ее полное невыполнение. В наше время для обозначения ошибки в программе используют термин «Баг» (с англ. Bug-жук).

Есть несколько типов ошибок:

1) Логическая ошибка. Это, пожалуй, наиболее серьезная из всех ошибок. Когда написанная программа на любом языке компилирует и работает правильно, но выдает неправильный вывод, недостаток заключается в логике основного программирования. Это ошибка, которая была унаследована от недостатка в базовом алгоритме. Сама логика, на которой базируется вся программа, является ущербной. Чтобы найти решение такой ошибки нужно фундаментальное изменение алгоритма. Вам нужно начать копать в алгоритмическом уровне, чтобы сузить область поиска такой ошибки. (пример: задача программы вывести сумму двух чисел а и b.

varc,a,b:integer;

Begin

readln(a,b);

c:=a-b; {нужнобылонаписатьc:=a+b;}

writeln(c);

readln;

end.

2) Синтаксическая ошибка.Каждый компьютерный язык, такой как C, Java, Perl и Python имеет специфический синтаксис, в котором будет написан код. Когда программист не придерживаться «грамматики» спецификациями компьютерного языка, возникнет ошибка синтаксиса. Такого рода ошибки легко устраняются на этапе компиляции.

begin

writln(‘helloworld!’); {вместоwritElnнаписаноwritln, чтоприведеткошибке}

readln;

end.

3) Ошибка компиляции.Компиляция это процесс, в котором программа, написанная на языке высокого уровня, преобразуется в машиночитаемую форму. Многие виды ошибок могут происходить на этом этапе, в том числе и синтаксические ошибки. Иногда, синтаксис исходного кода может быть безупречным, но ошибка компиляции все же может произойти. Это может быть связано с проблемами в самом компиляторе. Эти ошибки исправляются на стадии разработки.

vara,b:real;

begin

b:=7.5;

с:=b*3; {ошибка компиляции, мы присваиваем значениие несуществующей переменой}

writeln(a);

readln;

end.

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

vara:array[1..5] of integer;

begin

a[0]:=5; {ошибка в том, что мы вышли за предел массива}

writeln(a[0]);

readln;

end;

5) Арифметическая ошибка.Многие программы используют числовые переменные, и алгоритм может включать несколько математических вычислений. Арифметические ошибки возникают, когда компьютер не может справиться с проблемами, такими как «Деление на ноль», или ведущие к бесконечному результату. Это снова логическая ошибка, которая может быть исправлена только путем изменения алгоритма.

vara:real;

begin

a:=10/0; {ошибка, делениена 0}

writeln(a);

readln

end.

6) Ошибки ресурса. Ошибка ресурса возникает, когда значение переменной переполняет максимально допустимое значение. Переполнение буфера, использование неинициализированной переменной, нарушение прав доступа и переполнение стека — примеры некоторых распространенных ошибок.

vara:integer;

begin

a:=32768; {ошибка, максимальное значение переменной типа integer равно 32767}

end.

7) Ошибка взаимодействия. Они могут возникнуть в связи с несоответствием программного обеспечения с аппаратным интерфейсом или интерфейсом прикладного программирования. В случае веб-приложений, ошибка интерфейса может быть результатом неправильного использования веб-протоколов

Синтаксические ошибки – это ошибки в записи конструкций языка программирования (чисел, переменных, функций, выражений, операторов, меток, подпрограмм).

Семантические ошибки – это ошибки, связанные с неправильным содержанием действий и использованием недопустимых значений величин.

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

…

Читайте также:

©2015-2022 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-04-03
Нарушение авторских прав и Нарушение персональных данных



Поиск по сайту:

Мы поможем в написании ваших работ!

ТЕСТИРОВАНИЕ И ОТЛАДКА

Определение и принципы тестирования

Тестирование программного средства (ПС) — это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Тестирование программ является одной из составных частей более общего понятия — «отладка программ». Под отладкой по­нимается процесс, позволяющий получить программу, функциони­рующую с требующимися характеристиками в заданной области изменения входных данных.

Процесс отладки включает:

 действия, направленные на выявление ошибок (тестирование);

 диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);

 внесение исправлений в программу с целью устранения ошибок.

Из трех перечисленных видов работ самым трудоемким и дорогим является тестирование, затраты на которое приближаются к 45 % общих затрат на разработку ПС.

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

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

Тестирование оказывается довольно необычным процессом (поэтому и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего (тестовика) — заставить программу сбиться.

Программы, как объекты тестирования, имеют ряд особенно­стей, которые отличают процесс их тестирования от общепринято­го, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПС являются:

 отсутствие эталона (программы), которому должна соответ­ствовать тестируемая программа;

 высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

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

Существуют несколько эмпирических правил проведения тес­тирования программ, обобщающих опыт тестировщиков.

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

2. Необходимой частью тестового набора данных должно быть описание предполагаемых значений результатов тестовых прогонов. Тестирование как процесс многократного выполнения про­граммы проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных в результате очеред­ного тестового прогона данных, необходимо знать ожидаемый ре­зультат. Таким образом, тестовый набор данных должен включать в себя два компонента: описание входных данных, описание точного и кор­ректного результата, соответствующего набору входных данных. Этот принцип сложно, а в некоторых случаях и невозможно реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс этот трудоемкий даже для небольших про­грамм, так как он требует ручных расчетов, следуя логике алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует придерживаться логически, вытекает следующий.

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

4. Тесты для неправильных и непредусмотренных входных данных должны разрабатываться также тщательно, как для правильных и предусмотренных. Согласно этому принципу при обработке данных, выходящих за область допустимых значений, в тестируемой программе должна быть предусмотрена диагностика в виде сообщений. Если сообще­ние о причине невозможности обработки по предложенному алго­ритму отсутствует, и программа завершается аварийно или ведет себя непредсказуемо, то такая программа не может считаться ра­ботоспособной и требует существенной доработки. Тестовые наборы данных из области недопустимых входных значений обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным.

5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она того, чего не должна делать. Это утверждение логически вытекает из предыдущего. Необ­ходимо любую программу проверить на нежелательные побочные эффекты.

6. Следует тщательнее проверять те участки программ, где обнаруживается больше ошибок. Утверждается, что вероятность наличия необнаруженных ошибок в какой-либо части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Возможно, что те части программы, где при тестировании об­наружено большее число ошибок, либо были слабо проработаны с точки зрения системного анализа, либо разрабатывались програм­мистами более низкой квалификации.

Основные определения

Тестирование (testing) — процесс выполнения программы или ее части с целью найти ошибки.

Доказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предпола­гают прямого выполнения программы.

Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, но под ними подразумеваются разные виды деятельности.

Тестирование — это деятельность, направленная на обнаружение ошибок.

Отладка направлена на установление точной природы известной ошибки, а затем на исправление этой ошибки. Эти два вида деятельности связаны, т.к. результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (изолированно от всех остальных модулей).

Тестирование модуля иногда включает математическое доказательство.

Тестирование сопряжений (integration testing) — контроль сопряжений между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) — контроль внешнего поведения, определенного внешними спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям.

Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

Отношения между этими типами тестов и процессами проектирования показаны на рис. 15.

Стратегия проектирования тестов

В тестирование ПО входят постановка задачи для теста, проектирование, написание тестов, тестирование тестов, выполнение тестов и изучение результатов тестирования. Важную роль играет проектирование теста. Возможны следующие подходы к стратегии проектирования тестов:

1. Тестирование по отношению к спецификациям (не заботясь о тексте программы).

2. Тестирование по отношению к тексту программы (не заботясь о спецификациях).

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

Сторонники первого подхода проектирует тесты, исследуя внешние спецификации или спецификации сопряжения программы или модуля, которые он тестирует. Программа рассматривается как черный ящик. Логика их такова: «Меня не интересует, как выглядит эта программа, и выполнил ли я все команды. Я удовлетворен, если программа будет вести себя так, как указано в спецификациях». То есть в идеале проверить все возможные комбинации и значения на входе.

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

Ни одна из этих крайностей не является хорошей стратегией.

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

Интеграция модулей

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

Существует несколько подходов, которые могут быть использованы для слияния модулей в более крупные единицы. В большинстве своем они могут рассматриваться как варианты шести основных подходов, описанных ниже. Методы тестирования

Большая трудоемкость тестирования и ограниченные ресурсы приводят к необходимости систематизации процесса и методов тес­тирования. В практике тестирования используются следующие по­следовательно применяемые методы: статический, детерминиро­ванный, стохастический и в реальном масштабе времени.

Статическое тестирование — проводится без использова­ния ЭВМ путем просмотра текста программы после трансляции, проверки правил структурного построения программ и обработки данных. В качестве эталонов используются, во-первых, внутренние спецификации, а, во-вторых, коллективный опыт специалистов-тестировщиков. Применение статического тестирования достаточ­но эффективно. Для типичных программ, по данным фирмы IBM, можно находить от 30 % до 80 % ошибок логического проектирования и кодирования. Этот метод способствует существенному повыше­нию производительности и надежности программ, позволяет раньше обнаружить ошибки, а значит уменьшить стоимость ис­правления.

Детерминированное тестирование — это многократное выполнение программы на ЭВМ с использованием определенных, специальным образом подобранных тестовых наборов данных. При детерминированном тестировании контролируются каждая комбинация исходных данных и соответствующие результаты, а также каждое утверждение в спецификации тестируемой програм­мы. Этот метод наиболее трудоемкий, поэтому детерминирован­ное тестирование применяется для отдельных модулей в процессе сборки программы или для небольших и несложных программных комплексов.

Стохастическое тестирование предполагает использова­ние в качестве исходных данных множество случайных величин с соответствующими распределениями. Для сравнения полученных результатов используются также распределения случайных вели­чин. Стохастическое тестирование применяется в основном для обнаружения ошибок, а для диагностики и локализации ошибок приходится переходить к детерминированному тестированию с использованием конкретных значений исходных данных, из облас­ти изменения ранее использовавшихся случайных величин. Сто­хастическое тестирование наилучшим образом подвергается ав­томатизации путем использования датчиков случайных чисел (генераторов случайных величин) и применяется для комплексно­го тестирования ППП.

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

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

Восходящее тестирование

При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня («терминальные» модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжений программы.

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

Нисходящее тестирование

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

При этом подходе возникают два вопроса: что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули-заглушки, которые моделируют функции отсутствующих модулей. Фраза «напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания «заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксированные выходные данные, которые она всегда и возвращает. Иногда это оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощ­ренной, приближаясь по сложности к модулю, который она пытается моделировать.

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

Нисходящий метод имеет как достоинства, так и недостатки, по сравнению с восходящим. Его достоинство заключается в том, что этот метод совмещает тестирование модуля, тестирова­ние сопряжений и частично тестирование внешних функций. С этим связано и другое его достоинство — когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде.

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

Преимуществом нисходящего подхода часто считают отсутствие необходимости в драйверах; вместо драйверов следует написать «заглушки». Однако это преимущество спорно.

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

Второй недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит наоборот. Большинство опытных проектировщиков признает, что проектирование программы — процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже закончить проект и начать все сначала, потому, что разработчик увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то возникает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэкономить больше, чем те несколько дней или недель, которые рассчитывает выиграть проектировщик, приступая к программированию слишком рано.

Модифицированный нисходящий метод

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

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

Метод большого скачка

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

Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств.

Заглушки и драйверы необходимы для каждого модуля. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными.

Метод большого скачка значительно усложняет отладку.

Если программа мала и хорошо спроек­тирована, метод большого скачка может оказаться приемлемым. Однако для крупных программ он обычно неприемлем.

Метод сандвича

Тестирование методом сандвича — это компромисс между восходящим и нисходящим подходами; попытка воспользоваться достоинствами обоих методов, избежав их недостатков.

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

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

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

Модифицированный метод сандвича

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

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

Сравнение методов тестирования

С точки зрения надежности ПО стратегии тестирования можно оценить по семи критериям (табл. 9).

Первый критерий — время до момента сборки модулей, поскольку это важно для обнаружения ошибок в сопряжениях и предположениях модулей о свойствах друг друга.

Второй критерий — время до момента создания первых работающих «скелетных» версий программы, поскольку здесь могут проявиться главные дефекты проектирования.

Третий и четвертый критерии касаются вопроса о том, необходимы ли заглушки, драйверы и другие инструменты тестирования.

Пятый критерий — мера параллелизма, который возможен в начале или на ранних стадиях тестирования (но не концу цикла тестирования).

Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования.

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

Ранняя сборка и раннее получение работающего каркаса программы, а также возможность тестировать любые конкретные условия, представляются наиболее важными, им дается вес 3.

Сложность подготовки заглушек, планирования и управления последовательностью тестов также важны, они получают вес 2.

Третий критерий, необходимость драйверов — вес 1 ввиду доступности общих инструментов тестирования.

Критерий, связанный с параллелизмом работы, имеет вес 1 (он может быть важен по другим причинам, но на надежность сильно не влияет).

Шестой критерий — вес 3.

Седьмой критерий получает вес 2.

В табл. 10 приведены результаты этой оценки. В каждой графе таблицы вес берется со знаком плюс или минус либо не учитывается, в зависимости от того, благоприятно, неблагоприятно или безразлично проявляется соответствующий фактор при рассматриваемом подходе. Модифицированный метод сандвича и восходящий метод оказываются наилучшими подходами, а метод большого скачка — наихудшим. Если способ оценки оказывается близким к вашей конкретной ситуации, следует рекомендовать модифицированный метод сандвича для тестирования больших систем или программ и восходящий подход для тестирования программ малых и средних.

Этапы тестирования

Процесс тестирования ППП начинается проверкой правильно­сти работы отдельных модулей и заканчивается приемкой после испытания ППП при его сдаче заказчику или началом коммерче­ских продаж ППП. Рассмотрим типичные этапы работы тестировщиков.

Тестирование программных модулей — наиболее форма­лизованный и автоматизированный процесс тестирования.

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

Проверяется корректность структуры модулей и их конструктивных основных компонентов: процедур, циклов, блоков, условий и т.д.

Тестирование планируется с учетом структуры модулей и особенностей обработки информации и осуществляется преиму­щественно детерминировано.

Тестирование функциональных групп модулей предна­значено для проверки корректности решения крупных автономных Функциональных задач ППП. Проверяется правильность управ­ляющих и информационных связей между модулями, а также кор­ректность вычислений в процессе обработки информации. Значи­тельно возрастают сложность тестируемых объектов и соответственно объем тестов. Вследствие этого возрастают требования к автоматизации тестирования и затраты на его выполне­ние.

Детерминированным тестированием проверяются структура групп программ и основные маршруты обработки информации. В ряде случаев результаты получаются методами стохастического тестирования. Эти методы пока слабо формализованы, и их при­менение в значительной степени зависит от конкретных функций тестируемой группы программ.

Комплексное тестирование — сложный процесс, в котором завершается проверка корректности функционирования программ при правильных исходных данных, и осуществляются основные проверки при искажениях на входе.

Проверяются надежность функционирования всего ППП в реальных условиях, эффектив­ность средств программой защиты и восстановления. Определя­ются корректность использования программами ресурсов компью­тера и функционирование программ в критических условиях. Формализация процесса тестирования на этом этапе наиболее трудна, и оценка полноты тестирования осуществляется преиму­щественно по степени выполнения функций и по характеристикам надежности функционирования ППП. Для этого применяются пре­имущественно стохастическое тестирование и тестирование в ре­альном времени.

Прежде чем приступить к тестированию программного ком­плекса в целом, нужно, чтобы составляющие его части (отдельные модули или функциональные группы модулей) были тщательно от­тестированы.

Сборка модулей в программный комплекс может осуществляться двумя методами: монолитным и пошаговым.

По­шаговая сборка может, в свою очередь, быть восходящей (снизу-вверх) и нисходящей (сверху-вниз).

В качестве примера рассмотрим программный пакет, состоя­щий из девяти модулей (рис. 16).

Монолитный метод сборки предполагает тестирование каж­дого из девяти модулей отдельно, а затем их одновременную сборку и тестирование в комплексе.

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

Рис. 16. Структура пакета из 9 модулей

Для рассматриваемого примера модули-драйверы нужны для всех модулей, кроме модуля М1, а модули-заглушки нужны для всех модулей, кроме М5, М6, М7, М8, М9 (т.е. модулей самого низ­шего уровня).

Таким образом, при монолитной сборке необходимо разрабо­тать восемь модулей-драйверов и минимум девять модулей-заглушек.

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

Предположим, что тестируем сверху-вниз. Тогда для модуля М1 нужно разработать три заглушки. Далее подключается модуль М2, для которого нужно предварительно разработать две заглушки, и тес­тируются модули М1-М2. Затем заглушка М5 заменяется модулем М5 и тестируется цепочка М1-М2-М5.

Процесс продолжается до тех пор, пока не будет собран весь комплекс. Есть возможность неко­торого распараллеливания работ и автономного тестирования це­почек М1-М2-М5 (М6), М1-М3-М7, М1-М4-М8 (М9).

Оказывается, что при пошаговой сборке сверху-вниз нужно разработать девять заглу­шек, но не нужны драйверы.

При тестировании снизу-вверх процесс организуется следую­щим образом: тестируются модули низшего уровня — М5, М6, М7, М8, М9. Для каждого из них нужен драйвер.

Далее параллельно проводится тестирование М5-М2, М6-М2, М7-М3, М8-М4, М9-М4. Затем подключается модуль М1 и проводится комплексное тес­тирование всего пакета.

Таким образом, при восходящем тестиро­вании нужно будет разработать максимум восемь драйверов, но заглушки не потребуются.

Сравнивая монолитную и пошаговую сборки программ, можно отметить ряд достоинств и недостатков каждого из них.

Монолитная сборка требует больших затрат, так как предпола­гает дополнительно разработку драйверов и заглушек, в то время как при пошаговой сборке разрабатываются либо только заглушки, либо только драйверы.

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

Системное тестирование (или испытание программного комплекса) предназначено в основном для проверки соответствия пакета прикладных программ техническому заданию и для оценки его пригодности к регулярной эксплуатации и сопровождению.

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

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

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

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

Для таких коммерческих прикладных программ принято проводить испытания в два последовательных этапа, на­зываемых альфа- и бета-тестированием.

Эти испытания заключаются в нормальной и форсированной (стрессовой) опытной эксплуатации конечными пользователями программного продукта, в соответствии с сопроводительной документацией, и различаются количеством участвующих пользователей.

При альфа-тестировании привлекаются конечные пользо­ватели, работающие в той же компании, но не участвовавшие не­посредственно в разработке комплекса программ.

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

Только после успешной эксплуатации и бета-тестирования ограниченным контингентом пользова­телей, руководителем проекта или фирмы-разработчика принима­ется решение о передаче пакета прикладных программ в продажу для широкого круга поль­зователей.

В последнее время фирмы-разработчики стали выкладывать бета-версии программ на свои Web-сайты, позволяя всем желаю­щим скачивать их, тем самым, увеличивая контингент доброволь­ных тестировщиков. Обратная связь организуется либо через сис­тему конференций на сайте разработчика, либо посредством электронной почты. Отладка программного средства. Основные понятия

Лишь та ошибка, что не исправляется.

Конфуций

Отладка программного средства (ПС) — это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование.

Иногда тестирование и отладку считают синонимами.

Принципы и виды отладки программного средства

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

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

Рис. 17. Подходы к проектированию тестов

Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификаций ПС (внешнего описания, описания архитектуры и спецификации модулей). Строение модулей при этом никак не учитывается, т.е. они рассматриваются как черные ящики. Фактически такой подход требует полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать при пропуске любого теста, а это значит, что содержащиеся в них ошибки не будут проявляться. Однако тестирование ПС полным множеством наборов входных данных практически неосуществимо. Правый крайний подход заключается в том, что тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться много, так что их тестирование будет практически неосуществимо.

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

 на каждую используемую функцию или возможность — хотя бы один тест;

 на каждую область и на каждую границу изменения какой-либо входной величины — хотя бы один тест;

 на каждую особую (исключительную) ситуацию, указанную в спецификациях — хотя бы один тест.

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

Оптимальную стратегию проектирования тестов можно конкретизировать на основании следующего принципа: для каждого программного документа (включая тексты программ), входящего в состав ПС, должны проектироваться свои тесты с целью выявления в нем ошибок. Во всяком случае, этот принцип необходимо соблюдать в соответствии с определением ПС и содержанием понятия технологии программирования как технологии разработки надежных ПС. Различают два основных вида отладки (включая тестирование): автономную и комплексную отладку ПС.

Автономная отладка ПС означает последовательное раздельное тестирование различных частей программ, входящих в ПС, с поиском и исправлением в них фиксируемых при тестировании ошибок. Она фактически включает отладку каждого программного модуля и отладку сопряжения модулей.

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

Заповеди отладки программного средства

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

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

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

Заповедь 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить.

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Автономная отладка программного средства

При автономной отладке ПС каждый модуль на самом деле тестируется в некотором программном окружении, кроме случая, когда отлаживаемая программа состоит только из одного модуля. Это окружение состоит из других модулей, часть которых является модулями отлаживаемой программы, которые уже отлажены, а часть — модулями, управляющими отладкой (отладочными модулями). Таким образом, при автономной отладке всегда тестируется некоторая программа (тестируемая программа), построенная специально для тестирования отлаживаемого модуля. Эта программа лишь частично совпадает с отлаживаемой программой, кроме случая, когда отлаживается последний модуль отлаживаемой программы. В процессе автономной отладки ПС производится наращивание тестируемой программы отлаженными модулями: при переходе к отладке следующего модуля в его программное окружение добавляется последний отлаженный модуль. Такой процесс наращивания программного окружения отлаженными модулями называется интеграцией программы. Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы, от того, какой модуль отлаживается и, возможно, от того, какой тест будет пропускаться.

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

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

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

К достоинствам восходящего тестирования относятся:

 простота подготовки тестов;

 возможность полной реализации плана тестирования модуля.

Это связано с тем, что тестовое состояние информационной среды готовится непосредственно перед обращением к отлаживаемому модулю (ведущим отладочным модулем).

Недостатками восходящего тестирования являются следующие его особенности:

 тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программы);

 большой объем отладочного программирования (при отладке одного модуля приходится составлять много ведущих отладочных модулей, формирующих подходящее состояние информационной среды для разных тестов);

 необходимость специального тестирования сопряжения модулей.

К достоинствам нисходящего тестирования относятся следующие его особенности:

 большинство тестов готовится в форме, рассчитанной на пользователя;

 во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко — для всех, тестов);

 отпадает необходимость тестирования сопряжения модулей.

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

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

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

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

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

Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.

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

2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты.

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

4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты.

Комплексная отладка программного средства

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

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

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

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Далеко не каждый примитив качества ПС может быть испытан тестированием. Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено, если требуется получить какую-либо вероятностную оценку степени надежности ПС. Однако методика такого тестирования еще требует своей разработки. Могут тестироваться такие примитивы качества, как точность, устойчивость, защищенность, временная эффективность, в какой-то мере эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств. Каждый из этих видов тестирования имеет свою специфику и заслуживает отдельного рассмотрения. Легкость применения ПС (критерий качества, включающий несколько примитивов качества) оценивается при тестировании документации по применению ПС.

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

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

Испытание программных продуктов Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.

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

Испытание является завершающим этапом разработки. Ему предшествует этап статической и динамической отладки программ. Основным методом динамической отладки является тестирование. В узком смысле цель тестирования состоит в обнаружении ошибок, цель же отладки — не только в обнаружении, но и в устранении ошибок. Однако ограничиться только отладкой программы, если есть уверенность в том, что все ошибки в ней устранены, нельзя. Цели у отладки и испытания разные. Полностью отлаженная программа может не обладать определенными потребительскими свойствами и тем самым быть непригодной к использованию. Не может служить аль­тернативой испытанию и проверка работоспособности программы на контрольном примере, так как программа, работоспособная в условиях контрольного примера, может оказаться неработоспособной в других условиях применения.

В соответствии с ГОСТ 19.004-80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к исполь­зованию по своему назначению.

При отсутствии технического задания (ТЗ) на разработку программного средства (ПС) или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной.

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

Основными видами испытания программных продуктов (ПП) являются:

 предварительные;

 приемочные;

 эксплуатационные испытания, включая опытную эксплуатацию.

В зависимости от места проведения различают стендовые и полигонные испытания.

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

Если в основу стендовых испытаний положен принцип моделирования, то соответствующие испытательные стенды называют моделирующими.

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

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

По степени зависимости испытателей от разработчиков различают зависимые и независимые испытания.

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

Оценку результатов испытания производит комиссия при активном участии разработчиков.

Независимые испытания проводят специальные подразделения, не несущие ответственности за разработку программ и непосредственно не подчиняющиеся руководи­телям разработки.

Технологическая схема испытания

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

 знание назначения испытываемого ПС, условий его функционирования и требований к нему со стороны пользователей;

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

 ясное представление цели и последовательности испытания;

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

 систематический контроль, регулярное ведение протокола и журнала испытания;

 последовательное определение и выполнение плана испытания;

 сопоставление имеющихся ресурсов с предполагаемым объемом испытания;

 возможность обеспечения объективной количественной оценки полноты и достоверности результатов испытания на всех этапах.

Любому виду испытаний должна предшествовать тщательная подготовка.

В подготовку испытаний ПС входят следующие мероприятия:

 составление и согласование плана-графика проведения испытания;

 разработка, комплектование, испытание и паспортизация программно-технических средств, используемых при испытаниях;

 анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний;

 анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС;

 проверка и согласование с представителем заказчика конструкторской документации на ПС, предъявляемой при испытаниях;

 разработка, согласование и утверждение программ и методик испытаний;

 аттестация специалистов на допуск к проведению испытаний;

 приемка испытываемого опытного образца ПС на носителе данных и документации;

 проведение мероприятий, направленных на обеспечение достоверности испытаний.

Следует подчеркнуть необходимость заблаговременной разработки и испытания программно-технических средств, которые будут использоваться при проведении испытаний.

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

На основании изложенного можно определить следующие пять этапов испытания:

1. Обследование проектируемого ПС, анализ проектной документации.

2. Определение наиболее важных подсистем и функций проектируемого ПС, подлежащих испытанию.

3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания.

4. Разработка (освоение) испытательных программно-техничес­ких средств, библиотек тестов и баз данных (если они требуются).

5. Непосредственное проведение испытаний, анализ результатов, принятие решения.

В зависимости от специфики, условий применения, требований к качеству испытываемых ПС, испытания могут проводиться либо путем тестирования, либо путем статистического моделирования среды функционирования, либо на основе натурных и смешанных экспериментов. Часто полезно использование всех этих методов. Значения некоторых показателей качества могут быть получены экспертным путем.

На рис. 18 изображена технологическая схема в виде этапов подготовки и проведения испытания и их связи с этапами разработки ПС.

Планирование и оценка испытаний

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

1) анализируют диапазон входных данных. На основе анализа готовят множество комбинаций тестовых наборов данных, охватывающее наиболее харак­терные подмножества входных данных. Программу рассматривают как черный ящик. Испытания сводятся к последовательному вводу тестовых наборов данных и анализу получаемых результатов;

Рис. 18. Технологическая схема испытания ПС

2) анализируют множество ситуаций, которые могут возникнуть при функционировании ПС. Выбирают наиболее характерные. Каждую из них выражают через тестовый набор входных данных. Далее процесс испытания и анализа результатов сводится к п. 1;

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

4) ПС испытывают в реальной среде функционирования;

5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде.

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

Методика решения задачи планирования испытания включает в себя следующие этапы:

 нахождение всех путей реализации;

 выделение минимального подмножества путей, обеспечивающих проверку всех участков программы;

 разработка тестов для проверки выделенных путей.

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

N = 1 — n/К,

где n —	количество обнаруженных и устраненных ошибок;
К -	количество экспериментов.

С возрастанием количества экспериментов критерий интенсивности обнаружения ошибок будет асимптотически стремиться к единице.

Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаружении в последних двухстах экспериментах не более трех несуще­ственных ошибок. Идея выбора такого критерия основана на том, что частота обнаружения ошибок, выраженная отношением n/К, по мере увеличения количества экспериментов должна уменьшаться и к моменту завершения испытаний принять значение, близкое к нулю. Следует иметь в виду, что оценка уровня завершенности испытаний будет достоверной лишь в случае, если каждый эксперимент проводится в новых условиях и испытатели стремятся обнаружить ошибки, а не доказать их отсутствие.

Критерий заданного значения средней наработки на отказ (критерий Дж.Д. Муса). Предположим, что суммарное количество обнаруженных и устраненных дефектов в программе n (под дефектом понимается любая причина неудовлетворенности свойствами программы) описывается показательной функцией времени функционирования t

где N0 —	исходное количество дефектов в программе; ъ
М0 —	общее количество дефектов, которое может проявиться за время эксплуатации ПС;
Т0 —	средняя наработка на отказ в начале испытаний;
С —	коэффициент сжатия тестов.

Коэффициент С 1 тогда, когда абсолютная реактивность программы при прогоне тестов или статистических испытаниях отличается от абсолютной реактивности при работе программы в реальных условиях.

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

Коэффициент пропорциональности В = n/m называется коэффициентом уменьшения дефектов.

Если в ходе испытания обнаруженные ошибки устраняются, то текущее значение средней наработки на отказ будет увеличиваться.

В качестве критерия завершенности испытания можно принять достижение требуемого (заданного) значения средней наработки на отказ Т₀.

При планировании отладки и испытания программного обеспечения следует учитывать влияние следующих факторов:

 скорость выявления дефектов;

 скорость устранения дефектов;

 удовлетворенность машинным временем.

Первый фактор зависит от укомплектованности и квалификации испытателей, второй — от укомплектованности и квалификации группы программистов отладчиков, третий — от технической оснащенности разрабатывающей (испытывающей) организации.