Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 55
Текст из файла (страница 55)
Первые восемь пунктов в атом списке составляют от 50 до 75 процентов всей работы, затрачиваемой на проведение синтаксического тестирования. Обратите внимание, насколько я был требователен к деталям, в частности, не пользуясь предположением о взаимозаменяемости букв верхнего и нижнего регистров. Не делайте подобных допущений, поскольку операционная система, а, следовательно, и тестируемое вами приложение различают такие вещи. 222 Глава 8 ° Синтаксическое тестирование Наш следующий набор тестов направлен на проверку циклов. Вам надо проверить каждый цикл для следующего количества итераций: О, 1, 2, типичного, шах-1, шах и шах+ 1.
Мы не можем пройти цикл ноль раз, по крайней мере, в рамках чистого теста, так как это нарушило бы описанную в спецификации синтаксическую структуру. Все ли циклы были протестированы для случая 1? Если да, тогда в других тестах нет необходимости. Типичные значения различны для различных приложений, поэтому нет смысла тестировать их без знания статистики. Кстати, типичные значения обычно не особо перспективны для поиска ошибок, они нужны скорее в политических целях, чтобы убедить (без статистического подтверждения) людей в работоспособности системы. А как насчет максимальных и близких к ним значений? В операторах + и ' скрыто прямое приглашение поискать ошибки.
В компьютере все числа конечны, а значит, должны быть и максимальные значения. Например, в реально существующей спецификации оговаривается, что ни одна команда или оператор не могут состоять более чем из 255 символов. Вы должны найти правило, вне зависимости от того, скрытое оно или явное, и спроектировать тесты для этих случаев. Давайте предположим, что у нас есть следующее простое правило: <вещественное <испо>;- цифра>' '<Ч.<цифра>' тт><и<Пер!о ЧЧ - цифра>' а> Эта спецификация может быть проверена для случаев шах — 1 и мах при помощи следующихтестов:123456789.12345678901е12,1234567890.123456789012е123.
Почему я комбинирую по три значения шах — 1 и шах в отдельных тестах? Не лучше ли будет отказаться от комбинации значений для трех полей и проверить цикл по каждому полю отдельно? Стоит задать себе вопрос, какие ошибки вы ожидаете здесь встретить. Вы ожидаете встретить ошибку такую, что программа будет работать, если два из трех ее полей превышают свои допустимые значения, и не будет работать, если все три поля меньше этих пределов.
Мне кажется, что это не слишком похоже на естественную ошибку. Какие типы ошибок мы ищем, когда проверяем операторы ф и "? Было время, когда работа программного обеспечения могла нарушиться всего лишь из-за неправильной реализации предельных значений. Однако вероятность встретить подобную ошибку в современном программном обеспечении невелика. Программисты знают об атой проблеме и стараются ее избегать. Чаще всего ошибка возникает, если у двух или более программистов существуют различные нотации максимальной величины. Один программист берет предел равным 512, другой 65 536, а третий вообще считает, что 20 вполне достаточно. Ожидаемая в данном случае ошибка возникает вследствие несогласованности в нотациях вычислительно бесконечных циклон. Например, программист ограничил ввод 65 536 цифрами.
В более поздней программе, обрабатывающей это число, разрешено не более 20 цифр и некорректно предполагается, что предыдущая программа тоже ограничивает свой ввод 20 цифрами. 8.4.4. Грязное синтаксическое тестирование Используя грязное синтаксическое тестирование, мы решаем одновременно две задачи; пытаемся нарушить работу программного обеспечения, подбирая подхо- 8.4. Методы 223 дящий пример отдельных синтаксических ошибок для всех команд, и добиваемся вызова всех диагностических сообщений, связанных с этой командой. Если мы хорошо справились с первым заданием, то есть шанс, что н второе задание тоже окажется выполненным, однако в любом случае это неплохо бы проверить. Давайте сначала закончим тестирование циклов.
Мы должны рассмотреть случай нулевого числа итераций для каждого цикла. Вот некоторые из моих тестов:.05, 1., 1.1е. В случае грязного теста, я беру значения шах ч 1 равными: 12345678901.1, 1.1234567890123, 1.1е1234. Обратите внимание, что в грязных тестах я делаю только по одной ошибке, а для всех остальных полей выбираются самые простые значения. К этому моменту чистые тесты должны быть уже пройдены, поэтому программа должна читать и интерпретировать все символы при условии отсутствия ошибок.
Для грязных тестов ситуация иная, поскольку если, например, первое поле содержит слишком много илн слишком мало цифр, то число отбрасывается и ошибочный код для второго поля уже не будет выполняться. Я хочу убедиться, что вне зависимости от способа реализации весь код будет протестирован. Если при тестировании возникает более одной ошибки, то какой бы ни была ошибка, обнаруженная первой, она инициирует запрет исполнения текущей команды, и последующий (возможно ошибочный) код не будет протестирован. Поскольку мы не можем сказать, не глядя в код программы, какое поле будет обрабатываться в первую очередь, наиболее безопасно иметь только одну ошибку в каждом поле. Существуют и другие, более веские причины иметь одновременно не более одной ошибки при проведении грязного тестирования, но их я буду обсуждать позже.
Грязное синтаксическое тестирование достаточно простой метод. Надо всего лишь соблюдать нескольких простых правил: Каждая БНФ-спецификация представляет собой дерево (на самом деле — порожденный подграф). Выполняя тестирование, мы начинаем с вершины н заканчиваем листьями — реальными символами. Дерево поделено на уровни. На вершине дерева (например, дерева <вещественное число>) мы имеем несколько синтаксических элементов, определенных непосредственно, а также другие элементы, которые заданы в спецификациях на более низких уровнях дерева. Мы вносим какую-либо одну ошибку в определенное поле или откладываем определение ошибки этого поля на более низкий уровень.
Мы продумываем ошибки для каждого уровня так, чтобы иметь одновременно только одну ошибку в одном поле. В каждое поле мы можем внести ошибку сразу или отложить ее внесение на более низкий уровень. Вносимые нами ошибки делятся на синтаксические или семантические. Ниже приведена БНФ-спецификация (упрощенная для ясности) для команды СОРУ в М5-РО5 6.2. Оригинал фактически полностью идентичен предложенной БНФ-спецификации, за исключением небольших различий в обозначениях. Я не стал рассматривать некоторые усложняющие моменты, такие как ограничение обшей длины команды, различные ограничения, накладываемые на длину строки <путь>, допустимые и обязательные типы и положения разделителей между полями н переключателями IА и IВ. Я разрабатывал спецификацию последовательно сверху вниз, по одному уровню за раз, именно так, как я собираюсь строить тесты. 224 Глава 8 ° Синтаксическое тестирование ( ече1 1: <сору> ;.= СОРУ о [IУ1)-У](+ <иотсчНИК>)'" [о <конечнав цель>][)У] [2: <источник> .
= [<иня носителя> ] [<путь>][<иня файла>] [2: <конечная цель> .;= [<имя носителя> ] [<путь>К<иня файла>1 [3: <имя носителя> :.- а(Ь!.,а]А(В! 2 [3: <путь> ;- (Учиня нат >)' Ч [3. <иня файла> :;- <ф буквы>'"[.<расе>] [4 <имв кат> - <нат буквы>' '[ <расш>] [4 <расш> :.- <ф буквы>'' [5: <мат бунвы> ;= <а(Ь(с - г! Я(В(С - 2(0(1]2 - 9 ! " ! В ! — ! . '! ()! У ! В! - -! (! ! !! ! ((! ». [5 <ф буквы> : = <кат буквы>/ < 9 ! '!' > Несколько слов об уровнях.
Поле <раск> возникло на уровне 4, поскольку именно столько определений мне пришлось ввести, для того чтобы дать это определение. Но в то же время это поле фигурирует в определении <инй кат>, из чего следует, что его определение должно даваться на уровне 5. Какой из этих двух вариантов правильный? Оба. Дело в том, что зто дерево определений представляет собой частично упорядоченную структуру, в то время как понятие «уровень»вЂ” строго упорядочено и неприменимо к частично упорядоченным графам, таким как наше дерево определений.
Вы можете возразить, что появление одного поля в двух различных местах и в различных контекстах может стать причиной ошибки из-за различия в обработке этих двух случаев. Все правильно. В хорошем программном обеспечении такая вероятность мала, и поэтому не стоит беспокоиться по поводу одного или двух пропущенных случаев. Если же вы имеете дело с настоящей халтурой, тогда действительно это может быть хорошим тестом.
При проверке недоброкачественного программного обеспечения необходимо большее число тестов для достижения полного покрытия, но оно ломается при любом систематическом тестировании. В первом поле находится ключевое слово СОРУ. Если бы это была моя первая тестируемая команда, то я бы должен был начать с работы над этим ключевым словом. Все команды в М3-[)03 начинаются с ключевых слон. Если распознавание ключевых слов не действует, то вряд ли какие-либо другие команды будут работать. Существует вероятность, что такое тестирование в этом проекте уже проводилось.
Какие ошибки стоит внести в ключевое слово, если мы собираемся его проверить? 1. Оставить поле пустым. 2. Написать почти правильно, пропустив один символ, например, СОР. 3. Написать слишком длинно, например СОРУМЕ. 4. Взять правильное ключевое слово, но не относящееся к этой команде, например, СОМР. Подобные ошибки вряд ли встретятся в хорошем программном обеспечении, но для недоброкачественного программного обеспечения имеет смысл попробовать проверить пункты 2 и 3. Оставшаяся часть команды должна быть свободна от ошибок, поэтому в итоге получаем следующие тесты; Т1.1.1: СОР о а:"." и Т1.1.2; СОР'т'М Е о а:".'. 8.4. Методы 225 Несколько комментариев относительно этих двух тестов. Вы, лолжно быть, заметили, что я выбрал самый простой вариант, исключив максимально возможное число последующих полей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
