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

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

 

 

 
 

56

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

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

 

Режим III реализуется без участия группы испытаний. Этот 

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

 

Пример. Тестирование будет выполняться в режиме II (вы-

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

 
4.5 

Категории

 

испытания

 

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

 

изделия

 

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

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

 

Демонстрация в действии. Во время демонстрации прого-

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

 

Аттестация.  Аттестация  призвана  гарантировать  способ-

ность  данного  программного  изделия  правильно  обрабатывать 


background image

 

 

 
 

57

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

 

Полная  функциональная  проверка.  Цель  этой категории 

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

 

Проверка новых свойств. Этим испытаниям подвергаются 

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

 

Эксплуатационные  испытания.  В  результате  этой  про-

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

 

Испытания  надежности.  Во  время  этих  испытаний  изде-

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

 


background image

 

 

 
 

58

Проверка  устойчивости.  Эти  испытания  призваны  гаран-

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

 

Возвратная проверка. В эту категорию испытаний входит 

проверка новой версии или редакции изделия, подтверждающая, 
что  ранее  замеченные  дефекты  исправлены  и  исправления  не 
привели к появлению новых ошибок. Возвратная проверка вхо-
дит в состав испытаний классов A и B.

 

Пусковые  испытания.  Эти  испытания  подтверждают,  что 

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

 

Конфигурационные испытания. Эти испытания призваны 

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

 

Стадии,  режимы  и  категории  испытаний  наглядно  можно 

представить в табличной форме по аналогии с таблицей из раз-
дела 2.6.3.1 СТ. 

 
4.6 

Технология

 

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

классы

 

эквивалентности

 

 
Одним  из  способов  изучения  поставленного  вопроса  явля-

ется  исследование  стратегии  тестирования,  называемой  страте-
гией  черного  ящика,  тестированием  с  управлением  по  данным 


background image

 

 

 
 

59

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

 

Стратегия  белого  ящика,  или  стратегия  тестирования, 

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

 

Тестирование  в  данной  курсовой  работе  должно  выпол-

няться по технологии черного ящика с использованием методо-
логии  эквивалентного  разбиения.  Разработка  тестов  методом 
эквивалентного разбиения осуществляется в два этапа:

 

1) выделение классов эквивалентности;

 

2) построение тестов.

 

Классы эквивалентности выделяются путем выбора каждо-

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

 

 

Таблица 4.1 — Форма таблицы для перечисления классов

 

эквивалентности 

 

Классы эквивалентности

 

Входные условия

 

Правильные

 

Неправильные

 

 

 

 

 

Отметим, что различают два типа классов эквивалентности: 

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


background image

 

 

 
 

60

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

 

Если  задаться  входными или  внешними  условиями,  то  вы-

деление  классов  эквивалентности  представляет  собой  в  значи-
тельной  степени  эвристический  процесс.  При  этом  существует 
ряд правил:

 

1.  Если  входное  условие  описывает  область  значений  (на-

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

 

2. Если входное условие описывает число значений (напри-

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

 

3.  Если  входное  условие  описывает  множество  входных 

значений  и  есть  основание  полагать,  что  каждое значение  про-
грамма трактует особо (например, «известны способы передви-
жения на АВТОБУСЕ, ГРУЗОВИКЕ, ТАКСИ, ПЕШКОМ или на 
МОТОЦИКЛЕ»),  то  определяется  правильный  класс  эквива-
лентности  для  каждого  значения  и  один  неправильный  класс 
эквивалентности (например, «НА ПРИЦЕПЕ»).

 

4.  Если  входное  условие  описывает  ситуацию  «должно 

быть» (например, «первым  символом  идентификатора  должна 
быть  буква»),  то  определяется  один  правильный  класс  эквива-
лентности (первый символ — буква) и один неправильный (пер-
вый символ — не буква).

 

5.  Если  есть  любое  основание  считать,  что  различные  эле-

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

 
4.7 

Построение

 

тестов

 

 
Процесс построения тестов включает в себя:

 

1) назначение каждому классу эквивалентности уникально-

го номера;