Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 56
Текст из файла (страница 56)
Это само по себе уменьшает вероятность отмены выполнения этой команды по какой-либо другой причине. Я также использовал оператор произвольной последовательности символов ('), поскольку подозреваю, что обработка произвольной последовательности символов является характерной чертой, общей лля многих команд, и что она, возможно, использует область с путем, отличным от пути лля обработки данной команлы. Если я хочу избежать использования произвольной последовательности символов на этой стадии тестирования, то мне прилется использовать нечто вроде иня файла.тес и иметь в распоряжении полобный файл, который можно булет скопировать. Теперь рассмотрим слепующее поле — разделитель.
В сущности, условия при которых вам нужен или не нужен разлелитель (в нашем случае и), могут быть довольно запутанными, и моя модель это не отражает. Вам не нужен разделитель, если в качестве следующего символа используется обратная косая черта, применяющаяся лля переключения. Вообще существуют несколько типов разлелителей. Давайте не булем столь пунктуальны и предположим, что используется только о и что он обязателен, как показано в молели. Мы получаем лва следующих варианта теста: Т1.2.1: СОРУ а:*.* и Т1.2.2: СОРУ оо а:".' Первый тест отвергается, как и должно быть, однако второй прохолит гладко.
В чем дело? Либо спецификация, либо модель неверна. Неверна наша молель (БНФ вариант спецификации): в ней лолжно быть о'", гле 9 обозначает максимально лопустимое число разлелителей, равное общему числу символов в команле минус 127, то есть 118. Значит, по всей вилимости нам надо проверить это при помощи грязных и чистых тестов: с) = О, грязный; Т1.2.1; т)-1, чистый; с[-117, чистый; с)=118, чистый; т1-119, грязный.
Разберемся теперь с полем переключателя. Вот несколько вариантов: неверный переключатель в этой позиции, слишком много переключений, неверны оба переключателя. Эти варианты приволят к следующему набору тестов, каждый из которых должен определить наличие ошибки. Т1.3.!. СОРУ Iо А *,* Т1 3.2. СОРУ !/У П А.*.* Т1.3 3. СОРУ УУ о А:*.' Т!.3.4. СОРУ /У!-У и А:*.* 11 3 Ь. СОРУ УУУУ о А."." Т!,3 б. СОРУ /УУУ/У о А.*.* Выполняя эти тесты, я обнаружил, что не следую должным образом своей собственной модели.
Корректная спецификация отличается от привеленной. Я лобавлял знак + к кажлому источнику, хотя он нужен только в тех случаях, когда у нас больше олного источника. Следовательно, более корректная спецификация булет выглядеть следующим образом. <сору> .:-сОРу о' ' [/у(!-у)<источник>[+<источник>1>' [о<конечная цепь>1[/у) Какие ошибки мы можем внести в поле <источник>? Для начала обратите внимание, что поля файлов лля лвух источников связаны. Должен быть, как минимум, в з тто 226 Глава 8 ° Синтаксическое тестирование один источник.
Поскольку в конечную цель также входит имя файла, программа не сможет правильно обработать команду, если мы опустим имя файла источника, а взамен используем имя файла конечной цели. Поэтому нам придется опустить их оба в нашем грязном тесте. Тогда у нас есть следуюцше варианты: нет источника (и нет конечной цели), слишком много источников, синтаксическая ошибка в источнике, семантическая ошибка в источнике, изменение положений знака ч-. Т1.4.1. СОРУ Т! 4 2. СОРУ оА:Ут!е!.тхс Тт!е2 Схо Т!.4 3 СОРУ оА.Ут!е1.1хг ++Ут!е2.Схт Т1.4 4. СОРУ од;а+О+сгогегт д+Пчт+..+аа, !больше иаксикального предела числа источников, п1 Т1 4 5 - Т2.1. Синтаксическая ошибка в слецифииации источнииа П .4.6. = Т2 2. Сеиантическая ошибна в спецификации исто~ника В Т1А А я использовал очень короткие имена файлов без расширений, поскол ьку я хочу превысить максимально допустимое число исходных файлов в этой команде.
Мтте пришлось создать большое количество файлов с именами, состоящими из одного символа, затем с именами из двух символов и так далее. Выполняя этот тест, вам следует убедиться, что вы не превысили максимальную длину строки — 127 символов.
Тесты 1А.5 и 1А.6 фактически являются тестами следующего уровня. Я использовал систематическую схему нумерации тестов. Первая цифра обозначает уровень, вторая — тестируемое поле, а третья — способ внесения ошибки в это поле. Пропуск поля или использование слишком большого числа полей — это тесты первого уровня, Однако синтаксические и семантические ошибки в этих полях тестируются на следующем уровне. На этом уровне также были проделаны грязные тесты для поля конечной цели и его разделителей, так как спецификации для источника и конечной цели практически полностью совпадают.
Единственное, что мы можем сделать — протестировать синтаксические и семантические ошибки в спецификации целевого файла: Т! 5 1 - Т2.3 Синтаксическая ошибка в спецификации целевого файла т! 5 2 - т2 4. сеиантичесная ошибка в спецификации целевого файла Последний полезный тест, который мы можем сделать на этом уровне — поработать с переключателями, преимущественно тем же способом, который мы использовали для первого переключателя.
Т1.6.1 СОРУ оА:Ут!е.охсг' Т1.6.2 сбру оА.ут!е.схс оУ Т1.6.3 СОРУ оА Тт'!е.тхСГГ Т1.6 4 СОРУ аА:Ут!е ох!ГУГУ Т1 6.5. СОРУ сгАгбт1е Скотт Аналогичной последовательности надо придерживаться и для следующего уровня исследуемого нами дерева. Семантические ошибки в поле источника означают синтаксически корректное имя файла для несуществующего файла. Поле источника на самом деле более сложно, чем показано в нашей модели.
В него должно входить хотя бы одно поле с правильным именем. Это означает, что носитель и/ или путь и/или файл должны быть определены. Следовательно, более корректная спецификация будет выглядеть следующим образом: 8«ф. Методы 227 [<имя носителя»;[<путь>][<имя файла>] П [[<имя носителя»:]<путь> [<имя файла>]т П [«имя носителя» ][<путь>]<имя файла> Если у вас есть один из двух компонентов, то два других не обязательны.
В то же время в спецификации целевого файла все поля не обязательны. Ошибки второго уровня — это синтаксические и семантические ошибки в полях источника и целевого файла. Из-за того, что поля не обязательны, на этих уровнях встречается не так уж много синтаксических ошибок. Это означает, что нам достаточно иметь один из трех компонентов для источника. По всей видимости, единственное, что мы можем сделать на этом уровне, — поэксперилтентировать с двоеточием, использовать неверный символ (;), внести слишком много полей или вообще не указывать их.
За исключением семантических ошибок (отсутствие такого источника и отсутствие такого целевого файла), все остальные тосты мы можем сделать на следующем уровне. На уровне 3 мы экспериментируем с <имя носителя>, <путь> и <имя файла>. Число носителей, допустимое в МБ-РОЗ, и, следовательно, семантика и синтаксис имени носителя зависят от версии МБ-РОз. Поскольку поле <путь> не является обязательным, то единственные ошибки, которые мы можем сделать на этом уровне, это пропустить требуемый символ обратной наклонной черты в конце строки пути или ввести нх слишком ляного. Невсрный путь семантически рассматривается на следующем уровне. Я мог бы попробовать имя файла с точкой, но без расширения.
На четвертом уровне тестируются семантические и синтаксические ошибки в содержимом или в структуре имен каталогов и расширений. Здесь используется тот же набор, что и раньше. Пропустите какие-либо обязательные элементы, введите их слишком много, введите вместо них другой, неверный элемент, сделайте семантическую ошибку. Продолжайте в таком же духе, пока не дойдете до листьев дерева, то есть до того места, где вы вводите реальные символы. Я твердо придерживался правила делать не больше одной ошибки за раз. Для этого у меня есть две причины, и обе они важны. 1. Слишком много тестов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
