2.1. Введение. Понятия процесса программирования качественно изменились.Производство программ приобрело массовый характер, существенноувеличились их объем и сложность. Разработка программных комп-лексов потребовала значительных усилий больших коллективовспециалистов. Программы перестали быть только вычислительнымии начали выполнять важнейшие функции по управлению и обработкеинформации в различных отраслях. Развитие и применение технологий проектирования комплексовпрограмм приводит к необходимости измерения и сравнения их эф-фективности прежде всего по степени влияния на качество прог-раммного продукта. Обеспечение высокого качества сложных комплексов программсвязано со значительными затратами труда разработчиков. Затра-ты на создание программ быстро увеличиваются при возрастаниитребований, причем для сложных комплексов весьма сложно дос-тичь высокого качества функционирования, и после обеспеченияобщей работоспособности могут понадобится годы труда для полу-чения необходимых показателей качества. Поэтому уже сегоднятребуются методы и средства, которые позволили бы заметно по-высить качество программ программ при относительно невысокихзатратах труда. 2.2. Обоснование выбора технологии тестирования. Как известно, при создании типичного программного проектаоколо 50% общего времени и более 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---------- да / ¦ -= 3 / ¦ ¦ ¦ / ¦ ¦ ¦ /да ¦ ¦ ¦ -----------+---------¬ ---------+--------¬ ¦ ¦ ¦ ParamStr = System.¦ ¦ ParamStr = '' ¦ ¦ ¦ ¦ ParamStr(0) ¦ L--------T--------- ¦ ¦ L----------T---------- ¦ ¦ L---------------->+= 3 будет оши-бочно записано Lo(DosVersion) > 3. При тестировании по данно-му критерию эта ошибка не будет обнаружена. Более сильный критерий покрытия логики программы известенкак покрытие решений, или покрытие переходов. Согласно данно-му критерию должно быть записано достаточное число тестов, та-кое, что каждое решение на этих тестах примет значение истинаи ложь по крайней мере один раз. Можно показать, что покрытие решений обычно удовлетворяеткритерию покрытия операторов. Поскольку каждый оператор лежитна некотором пути, исходящем из оператора перехода, либо източки входа программы, при выполнении каждого направления пе-рехода каждый оператор должен быть выполнен. Следовательно,тесты приведенные выше подходят и для этого критерия. Однако существуют исключения, например, оператор case. Вэтом операторе возможны не двузначные решения. CASE условие OF m1 : оператор1; m2 : оператор2; m3 : оператор3 ELSE m4 : оператор4 END Критерием для таких случаев является выполнение каждоговозможного результата всех решений по крайней мере один раз. Лучшим критерием по сравнению с предыдущим является покры-тие условий. В этом случае записывают число тестов, достаточ-ное для того, чтобы все возможные результаты каждого условияв решении выполнялись по крайней мере один раз. Рассмотрим пример на функции OptionStr. function Parameters.OptionStr(ParamNum : byte) : string; var I, Len : Byte; begin Len := 0; I := OptPosition(ParamNum); if I 0 then while (I + ¦ ParStr(I) в / ¦ ¦ OptDelim / ¦ ¦ / ¦ ¦ / нет ¦ ¦ ----------+---------¬ ¦ ¦ ¦ Len = Len + 1; ¦ ¦ ¦ ¦ OptionStr(Len) = ¦ ¦ ¦ ¦ ParStr(I) ¦ ¦ ¦ L---------T---------- ¦ L---------------- ¦ ------------------------ ----------+---------¬ ¦ Конец ¦ L-------------------- Рис 2.2. Функция содержит три условия: I=0, I0 в первом условии иISLen, (ParStr[i] in OptDelim)=true, (ParStr[i] inOptDelim)=false во втором условии. Тесты, удовлетворяющие критерию покрытия условий пиведеныв таблице 2.2. (пусть стока параметров имеет вид: MAIN.GRM/Q/P, SLen=13, ParamNum=1): Табл. 2.2.г===T==================T===================T====================¬¦ N ¦ Входные данные ¦Ожидаемый результат¦Полученный результат¦¦---+------------------+-------------------+--------------------¦¦ 1 ¦ I = 0 ¦ OptionStr(0) = 0 ¦ OptionStr(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------------------- ¦ + 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