Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (1015641), страница 19
Текст из файла (страница 19)
После просмотракаждому участнику передают анонимную анкету с оценкойдвух его программ. Участники получают статистическую сводку, которая содержит общую и детальную классификацию ихсобственных программ в сравнении с полным набором программ, и анализ того, насколько оценки чужих программ совпадают с оценками тех же самых программ, данными другимипроверяющими. Цель такого просмотра — дать возможностьпрограммистам самим оценить свою квалификацию.
Этотспособ представляется полезным как для промышленного, так идля учебного применения.1206.4 Проектирование тестаРезультаты психологических исследований, обсуждавшиеся в п. 6.2, показывают, что наибольшее внимание при тестировании программ уделяется проектированию или созданию эффективных тестов. Это связано с невозможностью «полного»тестирования программы, т.е. тест для любой программы будетобязательно неполным (иными словами, тестирование не можетгарантировать отсутствия всех ошибок). Стратегия проектирования заключается в том, чтобы попытаться уменьшить эту «неполноту» настолько, насколько это возможно.Если ввести ограничения на время, стоимость, машинноевремя и т.п., то ключевым вопросом тестирования становитсяследующий:Какое подмножество всех возможных тестов имеетнаивысшую вероятность обнаружения большинства ошибок?Изучение методологий проектирования тестов дает ответна этот вопрос.По-видимому, наихудшей из всех методологий являетсятестирование со случайными входными значениями (стохастическое) — процесс тестирования программы путем случайноговыбора некоторого подмножества из всех возможных входныхвеличин.
В терминах вероятности обнаружения большинстваошибок случайно выбранный набор тестов имеет малую вероятность быть оптимальным или близким к оптимальному подмножеством. В настоящем разделе рассматривается несколько подходов, которые позволяют более разумно выбирать тестовыеданные. В п. 6.2 было показано, что исчерпывающее тестирование по принципу черного или белого ящика в общем случае невозможно.
Однако при этом отмечалось, что приемлемая стратегия тестирования может обладать элементами обоих подходов. Таковой является стратегия, излагаемая в этом разделе.Можно разработать довольно полный тест, используя определенную методологию проектирования, основанную на принципе черного ящика, а затем дополнить его проверкой логики программы (т.е. с привлечением методов белого ящика).Методологии, обсуждаемые в настоящем разделе, представлены ниже:Черный ящикБелый ящик121Эквивалентное разбиениеАнализ граничных значенийПрименение функциональныхдиаграммПредположение об ошибкеПокрытие операторовПокрытие решенийПокрытие условийПокрытие решений/условийКомбинаторное покрытиеусловийХотя перечисленные методы будут рассматриваться здесьпо отдельности, при проектировании эффективного теста программы рекомендуется использовать если не все эти, то, покрайней мере, большинство из них, так как каждый из них имеет определенные достоинства и недостатки (например, возможность обнаруживать и пропускать различные типы ошибок).Правда, эти методы весьма трудоемки, поэтому некоторые специалисты, ознакомившись с ними, могут не согласиться с данной рекомендацией.
Однако следует представлять себе, что тестирование программы — чрезвычайно сложная задача. Для иллюстрации этого приведем известное изречение: «Если вы думаете, что разработка и кодирование программы — вещь трудная, то вы еще ничего не видели».Рекомендуемая процедура заключается в том, чтобы разрабатывать тесты, используя методы черного ящика, а затем какнеобходимое условие — дополнительные тесты, используя методы белого ящика.
Методы белого ящика, получившие болееширокое распространение, обсуждаются первыми.6.4.1 Тестирование путем покрытия логикипрограммыТестирование по принципу белого ящика характеризуетсястепенью, в какой тесты выполняют или покрывают логику (исходный текст) программы.
Как показано в п. 6.2, исчерпывающее тестирование по принципу белого ящика предполагает выполнение каждого пути в программе; но поскольку в программе сциклами выполнение каждого пути обычно нереализуемо, то тестирование всех путей не рассматривается как перспективное.6.4.1.1 Покрытие операторовЕсли отказаться полностью от тестирования всех путей,то можно показать, что критерием покрытия является выполнение каждого оператора программы, по крайней мере, один раз.К сожалению, это слабый критерий, так как выполнение каждо-122го оператора, по крайней мере, один раз есть необходимое, нонедостаточное условие для приемлемого тестирования по принципу белого ящика (рис. 6.5).aA>1AND B = 0cYesNoX = X/AbA = 2 ORX>1deYesNoX=X+1Рис.
6.5 — Алгоритм тестируемой программыПредположим, что на рис. 6.5 представлена небольшаяпрограмма, которая должна быть протестирована. Эквивалентная программа, написанная на языке PL/1, имеет вид:М: PROCEDURE (A,В,Х);IF ((А>1) & (В=0)) THEN DO;Х=Х/А;END;IF ((A=2) | (Х>1)) THEN DO;Х=Х+1;END;END;123Можно выполнить каждый оператор, записав один-единственный тест, который реализовал бы путь асе. Иными словами, если бы в точке a были установлены значения A = 2, B = 0 иX = 3, каждый оператор выполнялся бы один раз (в действительности X может принимать любое значение).К сожалению, этот критерий хуже, чем он кажется на первый взгляд. Например, пусть первое решение записано как или,а не как и.
При тестировании по данному критерию эта ошибкане будет обнаружена. Пусть второе решение записано в программе как X > 0; эта ошибка также не будет обнаружена. Кроме того, существует путь, в котором Х не изменяется (путьabd). Если здесь ошибка, то и она не будет обнаружена. Такимобразом, критерий покрытия операторов является настолькослабым, что его обычно не используют.6.4.1.2 Покрытие решенийБолее сильный критерий покрытия логики программы известен как покрытие решений, или покрытие переходов.Согласно данному критерию должно быть записано достаточное число тестов, такое, что каждое решение на этих тестах примет значение истина и ложь, по крайней мере, одинраз. Иными словами, каждое направление перехода должнобыть реализовано, по крайней мере, один раз. Примерами операторов перехода, или решений, являются операторы DO (илиPERFORM UNTIL в Коболе, REPEAT UNTIL, WHILE в Паскале, WHILE и DO WHILE в Си), IF, многовыходные операторыGO TO.Можно показать, что покрытие решений обычно удовлетворяет критерию покрытия операторов.
Поскольку каждыйоператор лежит на некотором пути, исходящем либо из оператора перехода, либо из точки входа программы, при выполнении каждого направления перехода каждый оператор долженбыть выполнен. Однако существует, по крайней мере, два исключения.
Первое — патологическая ситуация, когда программа не имеет решений. Второе встречается в программах илиподпрограммах с несколькими точками входа; данный операторможет быть выполнен только в том случае, если выполнение124программы начинается с соответствующей точки входа. Так какпокрытие операторов считается необходимым условием, покрытие решений, которое представляется более сильным критерием, должно включать покрытие операторов.
Следовательно, покрытие решений требует, чтобы каждое решение имело результатом значение истина или ложь и при этом каждый оператор выполнялся бы, по крайней мере, один раз. Альтернативный и более легкий способ выражения этого требования состоитв том, чтобы каждое решение имело результатом значение истина или ложь и что каждой точке входа должно быть переданоуправление при вызове программы, по крайней мере, один раз.Изложенное выше предполагает только двузначные решения или переходы и должно быть модифицировано для программ, содержащих многозначные решения.
Примерами такихпрограмм являются: программы на PL/1, включающие операторы SELECT(CASE) или операторы GO TO, использующие меткупеременную; программы на Фортране с вычисляемыми операторамиGO TO или операторами GO TO по предписанию; программы на Бейсике с вычисляемыми операторамиON — GOTO, ON — GOSUB; программы на Коболе, содержащие операторы GO TOвместе с ALTER или операторы GO ТО — DEPENDING — ON; программы на Паскале, использующие операторыCASE; программы на языке Си, использующие операторыSWITCH — CASE; любые программы с арифметическими операторами IF.Критерием для них является выполнение каждого возможного результата всех решений, по крайней мере, один раз ипередача управления при вызове программы или подпрограммыкаждой точке входа, по крайней мере, один раз.В программе, представленной на рис.
6.5, покрытие решений может быть выполнено двумя тестами, покрывающимилибо пути асе и abd, либо пути acd и аbе. Если мы выбираем125последнее альтернативное покрытие, то входами двух тестовявляются A = 3, B = 0, X = 3 и A = 2, B = 1, X = 1.Покрытие решений — более сильный критерий, чем покрытие операторов, но и он имеет свои недостатки. Например,путь, где Х не изменяется (если выбрано первое альтернативноепокрытие), будет проверен с вероятностью 50 %. Если во втором решении существует ошибка (например, Х<1 вместо Х>1),то ошибка не будет обнаружена двумя тестами предыдущегопримера.6.4.1.3 Покрытие условийЛучшим критерием по сравнению с предыдущим являетсяпокрытие условий.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
