И. Соммервилл - Инженерия программного обеспечения (1133538), страница 106
Текст из файла (страница 106)
При проверке программы в качестве тестовых данных необходимо взять последовательности с ключевыми элементами, расположенными на границах этих областей. Граецы пассов эанмлентностн Средний злвент Рис. 20. 7. Квасом вквивпввианосаи для бинориого поиски Тестовые данные, представленные в табл. 20.7, необходимо изменить, посколысу эле. менты входного пассива должны быть отсортировапы в возрастающем порядке. Кроме того, следует добавить тестовые данные, где коючсвой элемент расположен возле среднего элемента массива. Полученное множество тестовых данных для программы бинарного поиска представлено в табл. 20.2. Таблица 20.2.
Тестовые данные для программы бинарного поиска Ключ (Кеу) Результат (Роипб, Е) Входной массив (Т) 17 45 23 21 23 25 20.1.4. Тестирование ветвей Это метод структурного тестирования, при котором проверяются все независимо вы. полнлсмые ветви компонента или программы. Если выполняются все независимые ветви, то н все операторы должны выполняться по крайней мере один раз. Более того, все условные операторы тестируются как с истинными, так и с ложными значениями условий.
В объектпо.ориентированных системах тестирование ветвей используетсл для тестированил методов, ассоциированных с объектами. 17 17 17, 21, 23, 29 9, ! Гь 18, 30, 31, 41, 45 17, 18, 21, 23, 29, 38, 41 17, 18, 2 1, 23, 29, 33, 38 12, 18, 21, 23, 32 21, 23, 29, 33, 38 тгпе, 1 Га!зе,?? тгпс, 1 тгпе, 7 сгпе, 4 тгпе, 3 сгпе, 4 Га!эе,?? 20. Тестирование программного обеспечения 413 Количество ветвей в программе обычно пропорционально ее размеру.
После интеграции программных модулей в систему, методы структурного тестирования оказываются невыполнимыми. Поэтому методы тестирования ветвей, как правило, используются при тестировании отдельных программных элементов и модулей. При тестировании ветвей не проверяются все возможные комбинации ветвей программы.
Не считая самых тривиальных программных компонентов без циклов, подобная полная проверка компонента оказывается нереальной, так как в программах с циклами существует бесконечное число возможных комбинаций ветвей. В программе мокнут бьггь дефекты, которые проявляются только при определенных комбинациях ветвей, даже если все операторы программы протее гированы (т.е.
выполнились) хотя бы один рзэ. Метод тестирования ветвей основывается на графе потоков управления программы. Этот граф представляет собой скелстную модель всех ветвей программы. Граф потоков управления состоит из узлов, соответствующих ветвлениям решений, и дуг, показывающих поток управления. Если в программе нет операторов безусловного перехода, то создание графа — достаточно простой процесс.
При построении графа потоков все последовательные операторы (операторы присвоения, вызова процедур и ввода-вывода) можно проигнорировать. Каждое ветвление операторов условного перехода (!Ийеп-е(ве или сазе) представлено отдельной ветвью. а циклы обозначаются стрелкамн, концы которых замкнуты на узле с условием цикла. На рис. 2ВВ показаны циклы и ветвления в графе потоков управления программы бинарного поиска. Рис 20 В. Г~мф яаиияим уи)кммния ярограннм биипрнего яоискп Цель структурного тестирования — удостовериться, что каждая независимая ветвь программы выполняется хотя бы один раэ. Независимая ветвь программы — это ветвь, кото.
рая проходит по крайней мере по одной новой дуге графа потоков. В терминах программы это означает ее выполнение при новых условиях. С понощью трассировки в графе потоков управления программы бинарного поиска можно выделить следующие независимых ветвей. 414 Часть Ч. Верификация и аттестация 1,2,8,8,9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 8, 4, 6, 7, 2, 8. 9 Если все зти ветви выполняются, можно быть уверенным в том, что, во.псрвых, каждый оператор выполняется па крайной мере один раз и, во-вторых, каждая ветвь выполняется при условиях, принимающих как истинные, так и ложные значения.
Количество независимых вствсй в програиме можно определить, вычислив цикломатичсскос чигло графа потоков управления программы [282). Цикломатнческос число С любого свлзанного графа О вычисляется по формуле С (О) = количество дуг — количество узлов + 2. Для программ, нс содержащих операторов безусловного парохода, значснис цикломатичсского числа всегда больше количества проверяемых условий. В составных условиях, содержащих более одного логического оператора, следует учитывать каждый логический оператор. Напримср, если в программе шесть операторов й н один цикл вгг1йе, то цикло. матичсскос число равно 8.
Если одно условное выражснис является составным выражением с двумя логическими операторами (объединснными операторами епб или ог). то цикломатичсскос число будет равно 10. Цикломатичсскос число программы бинарного попс. ка равно 4. Посла опрсдслсння количества независимых вствсй в программе путом вычисления цикломатичсского числа разрабатываются контрольные тесты длл проверки каждой ветви.
Минимальное количество тестов, требующееся для проверки всех ветвей программы, равно цнкломатичсскому числу. Проектирование контрольных тестов для программы бинарного поиска нс вызывает затруднений. Однако, если программы имеют сложную структуру ветвлений, трудно пред. сказать, как будет выполняться какой-либо отдельный контрольный тост. В таких случаях используется динамический анализатор программ для составлснил рабочего профиля программы. Динамические анализаторы программ — зто инструментальныс срсдства, которые ра.
ботают совместно с компиляторами. Во время компилирования в сгенерированный код добавляются дополннтсльщас инструкции, подсчитывающие, сколько раз выполнястся каждый оператор программы. Чтобы при выполнении отдельных контрольных тестов увидеть, какис ветви в программе выполнялись, а какие нет, распсчатывастся рабочий профиль программы, где видны непроверенные участки. 20.2. Тестирование сборки После того как протсстированы все отлсльныс программныс компоненты, выполняет.
сл сборка системы, в результате чсго создается частичная илн полная система. Процссс ннтсграции системы включает сборку н тсстированил получснной системы, в ходе которого выявллются проблемы, возникающие при взаимодействии компонентов. Тесты, цровсряющнс сборку системы, должны разрабатываться па основе системной снсцификацин, причем тсстнроаанис сборки следует начинать сразу после создания работоспособных версий компонентов системы. Во время тестирования сборки возникает проблема локализации выявленных ошибок. Между компонентами системы существуют сложные взаимоотношсния, и при обнаружа.
нни аномальных выходных данных бывает трудно установить источник ошибки. Чтобы облегчить локализацию ошибок, слсдуст гюпользовать пошаговый метод сборки и тсстн- 20. Тестирование программного обеспечении 415 роваиия системы. Сначала следует создать минимальную конфигурацию системы и сс протестировать. За-гсм в минимальную конфигурацию нужно добавить новые компоненты и снова протестировать, и так далее ло полной сборки системы. В примере на рис. 20.9 последовательность тестов Т1, Т2 н ТЗ сначала выполняпгся в системе, состоящей из модулей А и В (минимальная конфи~урания системы).
Если во время тестирования обнаружены дефекты, оии исправляются, Затем в систему добавляется модуль С. Тесты Т1, Т2 и ТЗ повторяются, чтобы убедиться, что в новой системс нет ника. ких неожиданных взаимодействий между модулями А и В. Если в холе тестирования появились какие-то проблемы, то, вероятно, они возникзи во взаииодействиях с новым модулем С. Источник проблемы локализован, таким образом упрощается определение дефекта и его исправление. Затем система запускается с тестами Т4. На последнем шаге добавляется модуль 0 и система тестируется еще раз выполнлсмыми ранее гостами, а затем новыми тестами Тб. Последовательность Последователыкхчь тестов 1 тестов 2 Ркс 20 9.
Тестировпнис сборок и Последовательность тестов 3 30.2.1. Нисходящее и восходящее тестирование Методики нисходящего и восходящего тестирования (рис. 20.10) отражают разные подходы к системной интеграции. При нисходящей интеграции компоненты высокого уровня интегрируются и тестируются еще до окончания их проектирования н реализации. При восходящей интеграции перед разработкой компонентов более высокого уровня гначала интегрируются и тестируются компоненты нижнего уровня.
Конечно, на практике редко встречаются такие простые модели. Функции системы могут быть реализованы в нескольких компонентах. Тестирование позой функции, таким образом, требует интеграции сразу нескольких компонентов. В этом случае тестирование может выявить ошибки во взаимодействиях между этими компонеитамн и другими частя. ми системы.
Исправление ошибок может оказаться сложным, так как в данном случае ошибки влияют на целую группу компонентов, реализующих конкрстпухз функцию. Балсс того, при интеграции нового компонента может измениться структура взаимосвязей между уже протестированными компонентами. Вследствие этого могут выявиться овщбкп, которые не были выявлены при тестировании более простой конфигурации. 416 яасть лг.
Верификация и аттестация йосходящвв твстнрованнв сборни Твс Послаяоатымпсть тпстированш Твс дрз Рне. 20.! О. Листпйяктее и ппеппйячнп тпшпутпппние гтюрки Нисходящее тсстированис являстся нсотьсмлсмой частью процесса нисходящей раз. работки систем, при котором сначала разрабатываются компоненты верхнего уровня, а затем компоненты, находящисся на нижних уровнях иерархии. Программу можно представить в виде одного абстрактного компонента с субкомпонснтами, являющимися заглушками. Заглушки имеют такой жс интерфейс, что и компонент, по с ограниченной функциональностью. Поспи того как компонспт верхнего уровня запрограммирован и протсстпровап, таким жс образом рсалнзуютсл и тестируются сто субкомпонснты. Процесс продолжается до тсх пор, пока нс будут рсализованы колтпонснты самого нижнего уровня.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
