Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 54
Текст из файла (страница 54)
Узлы. Узлы — это точки, куда приходят входящие связи и откуда выходят исходящие. Это означает, что они являются узлами слияния или ветвления (как правило, и тем и другим). Узел ветвления заменяет оператор ИУ!И. Отношение (связь). Здесь мы рассматриваем отношение «соединетт с». Это означает, что если А соединен с В, то между А и В на графе рисуется связь. Веса связей. Веса связей являются важной частью БНФ-спецификаций. Вес связи может представлять собой имя другой части спецификации со своим собственным графом, или сам граф. Например, для первой строки в предыдущей спецификации весами будут <разделит> и <цифра> с соответствующими показателями. Вместо этого я могу написать следующее определение: <нон соц обесп> = <цифра>т<оЯ7><цифра>т< оГ-П ><цифра>' Или <ион соц обесп> : - <О/1г2(3~4гб~б'г7~8г9>т<а П гг><Ог1)2~3(4г5)б)7г8)9>т <он 7><0~!!2~3~4~5~5~7~8~9>" Показатели также включаются в веса циклов.
Как это часто бывает с подобными моделями, в первое время вам, возможно, будет удобно чертить графы в графической форме, но когда вы освоитесь с моделью, необходимость в этом отпадет. Вы будете уже работать с текстовым представлением графа. Вы неоднократно сможете убедиться нп практике, что текстовое В.4. Методы 219 представление графа может представлять собой страницу для одной единственной команды, в то время как эквивалентная графическая форма займет не одну страницу и будет больше путать, чем помогать, 8.3.2.
Комментарий о трудозатратах Не надо путать усилия, затрачиваемые на изучение БНФ-представления, с объемом работы, необходимой для тестирования реального программного обеспечения. Иногда идею довольно просто объяснить, но ее реализация требует массы усилий. Так, например, идея Великой Китайской стены сама по себе не слишком сложна. Если вы это понимаете, то, считая, что у вас есть достаточно хорошая спецификация, пускай не БНФ, но уже готовая, вы, возможно, сможете обрабатывать две типичные команды за час (например, команды МЯ-РОЯ).
Если вам приходится подробно исследовать команды, чтобы определить все поля и ограничения в этих полях, то разбор одной команды может занять день или больше. Большинство примеров и упражнений в этой главе должны занимать у вас около часа или двух. 8.4. Методы 8.4.1. Осноаы Кроме тестирования вводимых команд, синтаксическое тестирование применяют для решения большого количества задач, однако тестирование команд очень хорошо подходит для иллюстрации данного метода. Как обычно, мы начнем с рассмотрения спецификаций.
1. Потребуйте спецификацию команд (фактически строк), которые вы собираетесь тестировать в наиболее формальном виде. Такая информация должна существовать, иначе что же будет реализовывать программист и каким образом пользователь узнает, как ему управлять программой? Если речь идет об уже существующей системе, то вы можете найти нужную информацию в справочных файлах (подобных справке о командах в системе МЯ-РОЯ) или, на худой конец, изучить командный синтаксис экспериментально.
2. Просмотрите команды на предмет поиска в них повторяюшихся частей, которые встречаются в большом количестве команд. Например, в МБ-РОВ 6.2 следующие поля используются в множестве команд; <адрес>, <устройство>, <каталог>, <иня носителя>, <иня файла>, <целочисленный>, <ВКЛЮЧИТЬ ! ВЫКЛЮЧИТЬ>, <путь>, <вреня>. Это надо сделать, чтобы избежать повторяюшихся спецификаций для общих полей. Если вы дважды определяете одну и ту же сушность, то возникает вероятность что эти две спецификации не будут идентичны и, соответственно, повышается вероятность сделать ошибку в проекте теста. 3.
Ишите в командах ключевые слова, В МЯ-РОЯ каждая команда имеет ключевое слово, но в командах встречаются и другие ключевые слова, такие как АВТО, АОХ, СОИ1, СОИ2, СОИЗ, СОИ4, СОК, СРТ1, СРТ2, СРТЗ, Ой, ОГР, РАТИ, Рйй. Как и в предыдушем пункте, мы делаем это, чтобы избежать повторяющихся спецификаций и, соответственно, ошибок в тесте.
гго Глава 8 ° Синтаксическое тестирование 5. 6. 7. 8. 9. Начните формирование ваших определений с ключевых слов, посколь- ку именно они с иаиболыпей вероятностью будут модифицированы при лексических изменениях (например, при переходе с английского языка на французский). Это будет простой алфавитный список. <аиТо> ::= АОТО)АОТо)А0тО/ .!аиТо <аих> ::- АОХ!Ацх!АоХ/Аох|а0Х!аоХ!аох <поспеднее ключевое слово> Вам, возможно, удастся сэкономить время.
Вместо того чтобы выписывать все возможньзе комбинации букв верхнего и нижнего регистров, вам будет удобнее написать нечто вроде: <А>::=А(а, <В>::=В(Ь В таком случае спецификация для ключевого слова <аох> примет следующий вид: <анх>::= А 0 Х> Аббревиатуры команд используются во множестве систем.
ОЕЕЕТЕ может быть сокращено до ОЕЕ, ВЕЛ или ВЕЮТ. Тут не существует общих правил, вы должны самостоятельно решить, что в вашем случае допустимо, а что— нет. Создайте БНФ-спецификацию для общих полей, таких как <носитепь>. Составьте список команд в порядке возрастания сложности, где сложность определяется числом полей в команде и тем, как много определений более низкого уровня вам пришлось привлечь.
Сгруппируйте команды. Мы не объединяем команды по принципу производимого ими действия. Это может быть хорошо для демонстраций при продаже системы, ио ие для ее тестирования. Группируйте их в соответствии с их характеристиками, такими как использование общих ключевых слов, использование общих определений полей, похожих структур. Например, у нас могут быть команды, имеющие одну и ту же структуру. <кпючевое слово команды> ::= <имя носителя>: <путь> <разделитель> Е1<зн1>3 <разделитель>Е1<зн2>)<возврат> Правильный выбор групп упростит проектирование тестов и само тестирование, поможет избежать ошибок при разработке теста и сэкономит время, затрачиваемое на проектирование.
Для всех полей, содержание которых (например, численное, целочисленное, строковое и т, д.) может меняться, обычно существует семантическая спецификация (например, минимальное и максимальное значения). Определите все подобные семантические характеристики и решите, какой метод тестирования вы будете использовать. Спроектируйте тест. Для каждой команды нужен свой набор тестов — чистых и грязных. Каждый чистый тест будет соответствовать определенному пути в синтаксическом графе этой команды. Как обычно, вы выбираете емвиююв 8.4. Методы 221 8.4.2. Иерархия покрытия Покрытие узлов в данном случае вряд лн будет аффективным, поскольку узлы здесь не обладают интересными для нас свойствами.
Однако покрытие связей нам будет необходимо. Так как мы имеем дело с циклами, мы также будем использо- вать тесты для циклов. 8.4.3. Чистое синтаксическое тестирование Я считаю правильным разбить синтаксическое тестирование на две части: и грязное. Чистое тестирование означает обеспечение покрытия (связей) фе, плюс дополнительные тесты для циклов. Это легче показать, чем расс На рис. 8.1 показана спецификация для строки «вещественное число> в языке чья БНФ задается следующим образом: <вещественное число> :.-<цифра>+<Ц .<цифра»+<Л~<пе 0~0 Л~ Ч - цифра +> <цифра> г.=01П2~3!а)5(бпт10!9 Здесь я привожу мой тестовый набор, обеспечивающий покрытие (иск специальные случаи для циклов): 01, 2.34, 5.6Е78, 9.0е+1, 0.01)-000, ОЮ.
Эти тестовых вариантов (и еще фактически бесконечное число зквнвалентных т обеспечивают полное покрытие связей. Простейший способ убедиться в зто прочертить заданные пути на копии зтого рисунка, чистое на граказать. Рааса!, лючая шесть естов) зтом— Рнс. В.Х. Синтаксический граф длл строки <вещественное число> путь, активизируете его, предсказываете выход, определяете критерии соответствия, убеждаетесь в правильности выхода и т. д. Вы должны выполнить первые восемь шагов вне зависимости от того используете ли вы автоматический генератор тестов, или делаете зто вручную.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
