Реферат: Технологии тестирования программного обеспечения - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Технологии тестирования программного обеспечения

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 18 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

2.1. Введение. Понятия процесса программирования качеств е нно изменились. Производство программ приобрело массовый характер , существенно увеличились их объем и сложность . Разр аботка программных комп- лексов потребовала значительных усилий б ольших коллективов специалистов . Программы перестали быть то лько вычи слительными и начали выполнять важнейшие функции по управлению и обработке информации в различных отраслях. Развитие и применение технологий прое ктирования комплексов программ приводит к необходимости измерен ия и сравнения их эф- фективности прежде вс его по степе ни влияния на качество прог- раммного продукта. Обеспечение высокого качества сложных комплексов программ связано со значительными затратами труда разработчиков . Затра- ты на создание программ быстро увели чиваются при возрастании требова ний , причем для сложных ко мплексов весьма сложно дос- тичь высокого качества функционирования , и после обеспечения общей работоспособности могут понадобится годы труда для полу- чения необходимых показателей качества . П оэтому уже сегодня требуются методы и средства , которые позволили бы заметно по- высить качество программ программ при относительно невысоких затратах труда. 2.2. Обоснование выбора технологии тестирован ия. Как известно , при создании типичного программного проекта около 5 0% общего времени и более 50% общей стоимости расходу- ется на проверку (тестирование ) разрабатыв аемой программы или системы . Кроме того , доля стоимости те стирования в общей стои- мости программ имеет тенденцию возрастать при увеличении слож- ности компл ексов программ и повыш ения требований к их качест- ву. Учитывая это , при отработке технологии тестирования прог- рамм следует четко выделять определенное (по возможности не очень большое ) число правил отладки , о беспечивающих высокое качество пр ограммного продукта и снижающих затраты на его соз- дание. Тестирование - это процесс исполнения п рограммы с целью обнаружения ошибок . Одним из способов изучения поставленного вопроса является исследование стратегии т естирования , называе- мой стр атегией черного ящика , тес тированием с управлением по данным , или тестированием с управлением по входу-выходу . При использовании этой стратегии программа р ассматривается как черный ящик . Тестовые данные используются только в соответст- вии со спе цификацией программы (т. е . без учета знаний о ее внутренней структуре ). При таком подходе обнаружение всех ошибок в программе яв- ляется критерием исчерпывающего входного тестирования . Послед- нее может быть достигнуто , если в качестве тестовых н аборов использовать все возможные наборы входных данных . Следователь- но , мы приходим к выводу , что для исчерпывающего тестирования программы требуется бесконечное число тес тов , а значит постро- ение исчерпывающего входного теста невозм ожно . Это подтвержд а- ется двумя аргументами : во-первых , нельзя создать тест , гаран- тирующий отсутствие ошибок ; во-вторых , разр аботка таких тес- тов противоречит экономическим требованиям . Поскольку исчерпы- вающее тестирование исключается , нашей це лью должна стать мак- с имизация результативности вложения к апиталовложений в тести- рование (максимизация числа ошибок , обнару живаемых одним тес- том ). Для этого необходимо рассматривать внутреннюю структуру программы и делать некоторые разумные , но , конечно , не облада- ющие полной гарантией достоверности предположения. Стратегия белого ящика , или стратегия тестирования , управ- ляемого логикой программы , позволяет иссл едовать внутреннюю структуру программы . В этом случае тес тирующий получает тесто- вые данные путем анал иза логики программы. Сравним способ построения тестов при данной стратегии с исчерпывающим входным тестированием стратеги и черного ящика. Неверно предположение , что достаточно пос троить такой набор тестов , в котором каждый оператор исп олняе тся хотя бы один раз . Исчерпывающему входному тестированию может быть поставле- но в соответствие исчерпывающее тестирова ние маршрутов . Подра- зумевается , что программа проверена полно стью , если с помощью тестов удается осуществить выполнение эт ой прог раммы по всем возможным маршрутам ее потока (графа ) передач управления. Последнее утверждение имеет два слабы х пункта : во-первых, число не повторяющих друг друга марш рутов - астрономическое ; во-вторых , даже если каждый маршрут мо жет быть проверен , сама программа может содержать ошибки (наприме р , некоторые маршруты пропущены ). В результате всех изложенных выше замечаний можно отме- тить , что ни исчерпывающее входное тес тирование ни исчерпываю- щее тестирование маршрутов не могут с тать полезным и стратегия- ми , потому что оба они не реализуе мы . Поэтому реальным путем, который позволит создать хорошую , но , конечно не абсолютную стратегию , является сочетание тестирования программы несколь- кими методами. 2.3. Разработка технологического п роцесса тестирования. Если отказаться от тестирования всех путей , то можно пока- зать , что критерием покрытия является выполнение каждого опе- ратора программы по крайней мере один раз. В качестве примера тестирования возь мем модуль Param. П редназначение модуля - разбирать кома ндную строку с парамет- рами на отдельные параметры. Объектом тестирования изберем правило ParamStr объекта Parameters. function Parameters.ParamStr(ParamNum : byte) : string; begin if ParamNum = 0 then if Delux then ParamStr:='' else if Lo(DosVersion) >= 3 then ParamStr:=system.ParamStr(0) else ParamStr:='' else ParamStr:=OptionStr(ParamNum); end; Схема алгоритма этой функции : --------------------¬ ¦ Начало ¦ L---------T---------- ¦ / \ / \ нет /ParamNum \ ----------------¬ \ = 0 / ¦ \ / ----------+---------¬ \ / да ¦ ParamStr = ¦ ¦ ¦ OptionStr(ParamNum)¦ / \ L---------T---------- да / \ ¦ -<-----------/ Delux \ ¦ ¦ \ = true / ¦ ----------+-------¬ \ / ¦ ¦ ParamStr = '' ¦ \ / нет ¦ L---------T-------- ¦ ¦ ¦ / \ ¦ ¦ / Lo( \ нет ¦ ¦ /DosVersion --------------¬ L--------¬ ¦ \ ) >= 3 / ¦ ¦ ¦ \ / ¦ ¦ ¦ \ / да ¦ ¦ ¦ -----------+---------¬ ---------+--------¬ ¦ ¦ ¦ ParamStr = System.¦ ¦ ParamStr = '' ¦ ¦ ¦ ¦ ParamStr(0) ¦ L--------T--------- ¦ ¦ L---- ------T---------- ¦ ¦ L---------------->+<-------------------+<---------- ----------+---------¬ ¦ Конец ¦ L-------------------- Рис 2.1. Табл . 2.1. г ===T==================T===================T====================¬ ¦ N ¦ Входные данные ¦Ожидаемый резуль тат¦Полученный результат¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 1 ¦ ParamNum = 1 ¦ ParamStr = ¦ ParamStr = ¦ ¦ ¦ ¦ OptionStr(ParamNum)¦ OptionStr(ParamNum) ¦ ¦ ---+------------------+-------------------+--------------- -----¦ ¦ 2 ¦ ParamNum = 0 ¦ ParamStr = '' ¦ ParamStr = '' ¦ ¦ ¦ Delux = true ¦ ¦ ¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 3 ¦ ParamNum = 0 ¦ ParamStr = ¦ ParamSt r = ¦ ¦ ¦ Delux = false ¦ System.ParamStr(0)¦ System.ParamStr(0) ¦ ¦ ¦ Lo(DosVersion)=3 ¦ ¦ ¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 4 ¦ ParamNum = 0 ¦ ParamStr = '' ¦ ParamStr = '' ¦ ¦ ¦ Delux = false ¦ ¦ ¦ ¦ ¦ Lo(DosVersion)=2 ¦ ¦ ¦ L===¦ ==================¦ ===================¦ ====================- Данный критерий тестиров ания хуже , чем кажется на первый взгляд . Например , если условие Lo(DosVersion) >= 3 будет оши- бочно записано Lo(DosVersion) > 3. При тестировании по данно- му критерию эта ошибка не будет о бнаружена. Более сильный критерий покрытия логик и программы изв естен как покрытие решений , или покрытие пе реходов . Согласно данно- му критерию должно быть записано дост аточное число тестов , та- кое , что каждое решение на этих те стах примет значение истина и ложь по крайней мере один раз. Можно показать , что пок рытие р ешений обычно удовлетворяет критерию покрытия операторов . Поскольку к аждый оператор лежит на некотором пути , исходящем из опера тора перехода , либо из точки входа программы , при выполнении каждого направления пе- рехода каждый оператор должен быть выполнен . Следовательно, тесты приведенные выше подходят и для этого критерия. Однако существуют исключения , например , оператор case. В этом операторе возможны не двузначные решения. CASE условие OF m1 : оператор 1; m2 : операт ор 2; m3 : оператор 3 ELSE m4 : оператор 4 END Критерием для таких случаев является выполнение каждого возможного результата всех решений по крайней мере один раз. Лучшим критерием по сравнению с пр едыдущим является покры- тие условий . В этом случае запис ывают число тестов , достаточ- ное для того , чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз. Рассмотрим пример на функции OptionStr. function Parameters.OptionStr(ParamN um : byte) : string; var I, Len : Byte; begin Len := 0; I := OptPosition(ParamNum); if I <> 0 then while (I <= SLen) and not (ParStr[I] in OptDelim) do begin Inc(Len); OptionStr[Len] := ParStr[I]; Inc(I); end; OptionStr[0] := Char(Len); end; Алгоритм этой функции : --------------------¬ ¦ Начало ¦ L---------T---------- ----------+---------¬ ¦ Len = 0; ¦ ¦ I = OptPosition( ¦ ¦ ParamNum) ¦ L---------T---------- / \ / \ да / I = 0 \ ----------------¬ \ / ¦ \ / ¦ \ /нет ¦ ----------------+ ¦ ¦ / \ ¦ ¦ / \ ¦ ¦ /I <= SLen\ да ¦ ¦ / и не \ ------------->+ ¦ \ParStr(I) в / ¦ ¦ \ OptDelim / ¦ ¦ \ / ¦ ¦ \ / нет ¦ ¦ ----------+--------- ¬ ¦ ¦ ¦ Len = Len + 1; ¦ ¦ ¦ ¦ OptionStr(Len) = ¦ ¦ ¦ ¦ ParStr(I) ¦ ¦ ¦ L---------T---------- ¦ L----------- ----- ¦ ------------------------ ----------+---------¬ ¦ Конец ¦ L-------------------- Рис 2.2. Функция сод ержит три условия : I=0, I<=SLen, not (ParStr[i] in OptDelim). Следовательно , требуется достаточное число тестов , такое, чтобы реализовать ситуации , где I=0, I<>0 в п ервом условии и I<=SLen, I>SLen, (ParStr[i] in OptDelim)=true, (ParStr[ i] in OptDelim)=false во втором условии. Тесты , удовлетворяющие критерию покрытия условий пиведены в таблице 2.2. (пусть стока параметров им еет вид : MAIN.GRM /Q/P, SLen=13, ParamNum=1): Табл . 2.2. г ===T==================T===================T====================¬ ¦ N ¦ Входные данные ¦Ожидаемый резуль тат¦Полученный результат¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 1 ¦ I = 0 ¦ OptionStr(0) = 0 ¦ Option Str(0) = 0 ¦ ¦ ¦ ¦ ¦ ¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 2 ¦ I = 1 ¦ OptionStr(0) = 0 ¦ OptionStr(0) = 0 ¦ ¦ ¦ (ParStr[i] in ¦ ¦ ¦ ¦ ¦ OptDelim) = true¦ ¦ ¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 3 ¦ I = 1 ¦ OptionStr(0) = 8 ¦ OptionStr(0) = 8 ¦ ¦ ¦ (ParStr[i] in ¦ ¦ ¦ ¦ ¦ OptDelim)=false ¦ ¦ ¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 4 ¦ I = 11 ¦ OptionStr(0) = 0 ¦ OptionStr(0) = 0 ¦ ¦ ¦ (ParStr[i] in ¦ ¦ ¦ ¦ ¦ OptDelim) = true¦ ¦ ¦ ¦ ---+------------------+-------------------+--------------------¦ ¦ 5 ¦ I = 11 ¦ OptionStr(0) = 0 ¦ OptionStr(0) = 0 ¦ ¦ ¦ (ParStr[i] in ¦ ¦ ¦ ¦ ¦ OptDelim)=false ¦ ¦ ¦ L===¦ ==================¦ ===================¦ ====================- Хотя применение критерия покрытия ус ловий на первый взгляд удовле творяет критерию покрыт ия решений , это не всегда так . Если тестируется решение if A and B then ... то при критерии покрытия условий т ребовались бы два теста : A = true, B = false и A = false, B = true. Н о в этом случае не выполнялось бы then-п редложение оп ератора if. Существует еще один критерий , названн ый покрытием реше- ний /условий . Он требует такого достат очного набора тестов, чтобы все возможные результаты каждого условия в решении вы- полнялись по крайней мере один раз , все ре зультаты каждого ре- шения выполнялись по крайней мере оди н раз и каждой точке вхо- да передавалось управление по крайней мере один раз. Недостатком критерия покрытия решений /условий является не- возможность его применения для выполнени я всех резул ьтатов всех условий ; часто подобное выполнение имеет место в следст- вии того , что определенные условия скр ыты другими условиями. Например , если условие AND есть ложь , то никакое из последую- щих условий в выражении не будет выполнено . Аналогично , ес ли условие OR есть истина , то никакое из последующих условий не будет выполнено . Следовательно , критерии п окрытия условий и покрытия решений /условий недостаточно чу вствительны к ошибкам в логических выражениях. Критерием , который решает эти и н екоторые другие пробле- мы , является комбинаторное покрытие услов ий . Он требует созда- ния такого числа тестов , чтобы все возможные комбинации резу- льтатов условия в каждом решении и все точки входа выполня- лись по крайней мере один раз. Рассмот рим правило CheckTreeNil в модуле TmObejct объекта Main. procedure Main.CheckTreeNil; var tn : boolean; begin tn := (GetPtrOfClass(SCl)=nil) and (GetPtrOfClass(UCl)=nil) and (GetPtrOfClass(ACl)=nil); if tn then Error('не найден ни о дин нетерминал '); end; Алгоритм процедуры : --------------------¬ ¦ Начало ¦ L---------T---------- ¦ /\ / \ / \ / G(SCl)=nil \ / и \ нет / G(UCl)=nil \ -----------¬ \ и / ¦ \ G(ACl)=nil / ¦ \ / ¦ \ / ¦ \ / да ¦ ¦ ¦ --------------------+------------------¬ ¦ ¦ Error('не найден ни один нетерминал ')¦ ¦ L-------------------T------------------- ¦ +<---------------------- ----------+---------¬ ¦ Конец ¦ L-------------------- Рис 2.3. Для того , чтобы протестировать эту процедуру необходимо восемь тестов , хотя она покрывается всего двумя путями. Табл . 2.3. г ===T===========================T============T============¬ ¦ N ¦ Входные данные ¦ Ожидаемый ¦ Полученный ¦ ¦ ¦ ¦ резул ьтат ¦ резу льтат ¦ ¦ ---+---------------------------+------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) = nil ¦ ¦ ¦ ¦ 1 ¦ GetPtrOfClass(UCl) = nil ¦ tn = true ¦ tn = true ¦ ¦ ¦ GetPtrOfClass(ACl) = nil ¦ ¦ ¦ ¦ ---+---------------------------+------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) <> nil ¦ ¦ ¦ ¦ 2 ¦ GetPtrOfClass(UCl) = nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) = nil ¦ ¦ ¦ ¦ ---+------ ---------------------+------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) = nil ¦ ¦ ¦ ¦ 3 ¦ GetPtrOfClass(UCl) <> nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) = nil ¦ ¦ ¦ ¦ ---+---------------------------+------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) <> nil ¦ ¦ ¦ ¦ 4 ¦ GetPtrOfClass(UCl) <> nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) = nil ¦ ¦ ¦ ¦ ---+------------ ---------------+------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) = nil ¦ ¦ ¦ ¦ 5 ¦ GetPtrOfClass(UCl) = nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) <> nil ¦ ¦ ¦ ¦ ---+---------------------------+ ------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) <> nil ¦ ¦ ¦ ¦ 6 ¦ GetPtrOfClass(UCl) = nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) <> nil ¦ ¦ ¦ ¦ ---+---------------------------+------------+--- ---------¦ ¦ ¦ GetPtrOfClass(SCl) = nil ¦ ¦ ¦ ¦ 7 ¦ GetPtrOfClass(UCl) <> nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) <> nil ¦ ¦ ¦ ¦ ---+---------------------------+------------+------------¦ ¦ ¦ GetPtrOfClass(SCl) <> nil ¦ ¦ ¦ ¦ 8 ¦ GetPtrOfClass(UCl) <> nil ¦ tn = false ¦ tn = false ¦ ¦ ¦ GetPtrOfClass(ACl) <> nil ¦ ¦ ¦ L===¦ ===========================¦ ============¦ ============- В случае циклов число тестов для удовлетворения критерию комбинаторного покрытия условий обычно б ольше , чем число пу- тей. Легко видеть , что набор тестов , удо влетворяющий критерию комбинаторного покрытия условий , удовлетворяе т также и крите- риям покрытия решен ий , покрытия ус ловий и покрытия решений /ус- ловий. Таким образом , для программ , содержащих только одно усло- вие на каждое решение , минимальным яв ляется критерий , набор тестов которого : - вызывает выполнение всех результатов каждого решения по крайней мере один раз ; - передает управление каждой точке вход а (например , опера- тор CASE). Для программ , содержащих решения , каждо е из которых имеет более одного условия , минимальный критери й состоит из набора тестов , вызывающих всех возможны х комбинаций результатов усло- вий в каждом решении и передающих управление каждой точке вхо- да программы по крайней мере один раз. В свете всего вышеизложенного , можно изобразить алгоритм выбора минимального критерия , по которому необходимо тестир о- вать программу (см . рис . 2.4.). --------------------¬ ¦ Начало ¦ L---------T---------- --------------------------------->+ ¦ ------- ---+---------¬ ¦ ¦ Выбрать оператор ¦ ¦ ¦ условного перехода¦ ¦ L---------T---------- ¦ /\ ¦ / \ ¦ / \ нет ¦ /Это оператор\ ---------¬ ¦ \ IF / ¦ ¦ \ / ¦ ¦ \ / ¦ ¦ \ /да ¦ ¦ ¦ ¦ ¦ /\ ¦ ¦ / \ ¦ ¦ да /Условие \ нет ¦ ¦ ----------/ содержит \--------->+ ¦ ¦ \ более одного / ¦ ¦ ¦ \ комп-та / ¦ ¦ ¦ \ / ¦ ¦ ¦ \ / ¦ ¦ ----------------+---------------¬ ----------------+-------------¬ ¦ ¦ Набор тестов , вызывающий все ¦ ¦ Набор тестов , вызывающий ¦ ¦ ¦ возможные комбинации резуль- в ¦ ¦ выполнение всех результатов ¦ ¦ ¦ условий в каждом решении н е ¦ ¦ каждого решения не менее ¦ ¦ ¦ менее одного раза . ¦ ¦ одного раза . ¦ ¦ L---------------T---------------- L---------------T-------------- ¦ L--------------->T<---------------- ¦ /\ ¦ /Это \ ¦ нет /последн.\ L---------------------------/ оператор \ \ у словного / \ перехода / \ / \ /да ----------+---------¬ ¦ Конец ¦ L-------------------- Рис 2.4.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
- Папа! Он назвал меня безмозглой самовлюблённой курицей!
- Успокойся, доченька! Он, конечно, не прав. Я только пока не пойму, в чём.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Технологии тестирования программного обеспечения", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru