Файл: Технология разработки программного обеспечения.pdf

51

4 

ТЕСТИРОВАНИЕ

 
Проведение  тестирования — цель  второй  части  второй  ла-

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

 
4.1 

Общие

принципы

тестирования

 
Этап  тестирования  обычно  в  финансовых  затратах  состав-

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

В  процессе  тестирования  используются  данные,  характер-

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

Тестирование подразумевает три стадии:

−

автономное;

−

комплексное;

−

системное.

При автономном тестировании модуль проверяется с помо-

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

В  процессе  комплексного  тестирования  проводится  совме-

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

52

Системное  (или  оценочное)  тестирование — это  завер-

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

В  процессе  тестирования  для  определения  правильности 

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

1) каждый оператор должен быть выполнен, по крайней ме-

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

2) каждая ветвь программы должна быть опробована, и про-

грамма при этом должна выдать правильный результат;

3) каждый путь в программе должен быть испытан хотя бы 

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

4)  для  каждой  спецификации  программы  необходимо  рас-

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

Хотя критерии п.п. 1 и 2 кажутся схожими, в действитель-

ности  они  сильно  разнятся.  Например,  арифметический  опера-
тор IF в Fortran

IF (

Выражение) N

1

, N

2

, N

3

Критерий  п. 1 подразумевает,  что  IF  должен  быть  выпол-

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

1

, N

2

, N

3

 (т.е. пере-

дачу на эти метки).

В общем случае не существует единого программного кри-

терия, определяющего «хорошо проверенную» программу.

Тесно  связаны  с  тестированием  понятия  «верификация»  и 

«испытание».

Испытание  системы  осуществляется  посредством  тестиро-

вания. Цель такой проверки — показать, что система функцио-
нирует в соответствии с разработанными на нее спецификация-
ми.

53

Верификация заключается в выполнении доказательств, что 

программа удовлетворяет своим спецификациям.

Современный  процесс  разработки  программ  не  позволяет 

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

Общий процесс создания правильных программ с помощью 

процедур испытания и верификации называется аттестацией.

Различаются  три  вида  отклонения  системы  от  нормальной 

работы.

Сбой системы — это явление, связанное с нарушением сис-

темой установленных на нее спецификаций.

Данные, при обработке которых правильными алгоритмами 

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

Ошибка — это  алгоритмический  дефект,  который  создает 

выброс (программная ошибка).

Различают понятия «правильная» и «надежная» программа. 

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

Система  является  правильной,  если  в  ней  нет  ошибок,  а  ее 

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

54

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

 
4.2 

Организация

испытаний

программных

изделий

 
Под испытаниями понимают не отладку, призванную опре-

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

Группа  испытаний  оказывает  значительное  влияние  на  ка-

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

−

проведение испытаний;

−

выработка оценок;

−

участие в фазовых обзорах с целью влияния на ход раз-

работок. 

4.3 

Виды

испытаний

программного

изделия

. 

Стадии

испытаний

 
В общем случае, испытания проводятся в несколько стадий, 

разделенных по времени.

55

К  первой  стадии  относятся  испытания  класса A, которые 

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

Ко  второй  стадии  относятся  испытания  класса B, когда 

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

Испытания класса C осуществляются после того, как группа 

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

Пример.  Поскольку  написание  программы  завершено,  для 

проверки правильности работы программы выбран класс B (тес-
тирование  после  разработки).  Испытания  класса A (тестирова-
ние  в  процессе  разработки)  отвергаются,  а  класс C (предпро-
дажное тестирование) не может быть выбран потому, что тести-
руемая  программа  является  учебной  и  не  предназначена  для 
продажи. 

 
4.4 

Режимы

испытаний

программ

 
Испытания различаются в зависимости от того, кто их про-

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

Режим  I  испытаний  подразумевает  полный  цикл  деятельно-

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