Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 57
Текст из файла (страница 57)
Проверка команды МБ-РОЗ СОРУ потребовала приблизительно 75 — 100 тестов и потребовала бы гораздо больше, если бы в основе нашего тестирования лежала реальная БНФ-снецификация со всеми своими переключателями и другими сложностями. Вне зависимости от числа тестов, проводимых вами для единичной ошибки, для двойной ошибки количество требуемых тестов придется возвести в квадрат. Коммерческие инструментальные средства 1!РЕ!94, РОБТ941 проделывают все это, если только у вас есть БНФ-снецификация или ее эквивалент, Эти инструменты генерируют чудовищное число грязных тестов.
Для типичной системы, имеющей несколько сотен команд пользователя и оператора, вы можете с легкостью создавать около 100 000 тестов за день. Даже для автоматического выполнения это достаточно большое число. Для двойных ошибок это цифра вырастет до 10 000 000 000, а для тройных? 2. Потеря ошибок. Оказывается, что теоретически невозможно создать генератор грязных тестов, который гарантированно генерирует только грязные тесты. Специфика синтаксиса приведет к предположительно грязным тестам, которые будут легко проходиться. Система «пройдет» 228 Глава В е Синтаксическое тестирование подобный тест, и вам придется проводить расследование.
Если возникает слишком много ложных сигналов тревоги, то даже при наличии автоматизации польза, приносимая данным методом, сходит на нет. Если вы рассматриваете двойные ошибки, то возникает вероятность потери ошибок. Например, в выражении (х+у+(г — ч) пропущена правая скобка. Если я делаю две ошибки, чтобы получить либо х+у+(г — ч), либо (х+ у+ к — ч ), мы имеем в итоге две синтаксически корректные строки— ошибки были потеряны. Скобки и другие парные разделители (ВЕ61М-ЕМО, ОО.ЕМОО, 1Р-ЕМ01Р, РАКОО-ЕМОРАК) могут служить простыми примерами возможности потерь ошибок.
При проверке множественных ошибок стремительно растет число тестов, однако процентное соотношение ложных сигналов тревоги растет еще быстрее. 8 4.5. Предсказание итога Предсказание итога для чистых тестов зависит от тестируемой команды и семантики. Тут не существует общих правил, и вам придется придумать их самим. Для грязных тестов предсказание итога выглядит очень просто: КОМАНДА ОТВЕРГНУТА.
8.4.6. Хорошие и плохие разновидности тестирования Некоторые разновидности синтаксического тестирования могут облегчить вам работу, а некоторые могут, наоборот, существенно усложнить. Есть однако, и другая сторона медали. Программы, представляющие скверные разновидности, как правило, содержат наибольшее число ошибок, и, значит, синтаксическое тестирование в этом случае весьма перспективно.
1. Формальная структура. Некоторые командные язьщи, ~акис как в 1)1ч1Х, имеют формальную структуру. Вместо сотен специальных команд язык имеет относительно небольшое число командных сегментов, компонуя которые при соблюдении специальных правил, можно добиться желаемого эффекта. С другой стороны, операционные системы наподобие МВ-РОВ, которые не обладают такой формальной структурой в полной мере, тем не менее, обладают некоторыми ее аспектами, например, возможностью конвейеризации и переадресации.
Для командных языков, имеющих явную формальную структуру, обычно бывает достаточно проверить сегменты и правила их компоновки, вместо того чтобы проверять все множество возможных команд. Это особенно важно для грязного синтаксического тестирования, которое, как правило, не слишком продуктивно при проверке командных языков с формальной структурой. Если язык программирования обладает формальной структурой, то обычно не представляет труда найти полную, детальную спецификацию для всех команд, зачастую составленную в метаязыке, эквивалентном БНФ.
Поэтому хотя тесты легко проектируются, онн не слишком эффективны. Чистое тестирование требует, разумеется, гораздо меньших затрат. Командные языки, не обладающие формальной структурой или со структурой, возникшей в процессе сращивания, как правило, являются хороши- 8.4. Методы 229 .:= <ключевое слово><разделитепь1><попе1><разделитепь2><попе2> ..= о181-1 ЕСЛИ ключевое слово> = -ключевое слово список 1 ::- Х ЕСЛН <ключевое слово> = <ключевое слово список 2> :.= Ч т'1Н ~оР ~ ЕСЛИ <поле1> = <попе1 синтансис 1> Х ИНАЧЕ ::- <попе2 синтансис 1> ЕСЛИ <попе1> = "1" ::= <поле2 синтаксис 2> ЕСЛИ <поле1> = "2" <испанца> <разделитель'ь> <раздепитепь2> <попе2> :.= <лоле2 синтаксис 99> ЕСЛИ <попе1> = "99" <поле2> ми объектами для грязного синтаксического тестирования (и часто полны ошибок).
Наиболее печально известный пример языка такого типа — это т)ВАКЕ-ПттП1/1Ъ' — язык программирования баз данных для РС. Макрокомандные языки для РС часто также обладают этими неприятными особенностями. Специализированные языки, часто «проетст ируемые» без должного понимания, чтб за язык на самом деле строится, как правило, трудны для исследований, поскольку документация на команды в этих языках (и особенно на хитроумные исключения) крайне скудна.
Отсутствие структуры делает затруднительным автоматизацию разработки теста, и автоматичоский генератор грязных тестов выдает много неверных тестовых вариантов. Несомненным плюсом таких систем, содержащих командные языки с отсутствием структуры, является простота, с которой они ломаются. 2. Точная лексическая спецификация. Существуют командные языки с точной лексической спецификацией. Ключевые слова в них четко определены и не могут соответствовать, скажем, опциям внутри команд или строкам других команд, для которых они могут показаться естественными. Спецификация языка определяет четкие правила, касающиеся преобразований алфавита и ключевых слов.
Чем более ясным и логичным будет разделение между лексическими и синтаксическими аспектами, тем меньше вам придется тестировать. Полная проверка языка при помощи единого набора всеобъемлющих тестов для какой-либо одной лексической трансформации дает уверенность в надежности других лексических эквивалентов. В то же время, если существует четкая лексическая спецификация, то не составляет труда конвертировать набор чистых и грязных тестов из одной спецификации в другую. Как я уже неоднократно убеждался, качественные программы содержат меньше ошибок и их существенно легче тестировать.
Полной противоположностью чистой лексической спецификации являются языки, в которых лексические и синтаксические аспекты безнадежно перепутаны. Но хотя разработка тестов для них сложна и приходится прикладывать много усилий для исследований, их тестирование, тем не менее, приносит результаты. 3. Синтаксис, зависящий от контекста. В хороших командных языках существует четкое разделение между синтаксисом и семантикой.
В плохих языках эти аспекты безнадежно перемешаны. В качестве примера рассмотрим следующую спецификацию; Глава 8 ° Синтаксическое тестирование 8.5. Рассмотрение приложений 8.5.1. Индикаторы приложений Командные языки, для которых синтаксическое тестирование эффективно, явля- ются неотъемлемой функциональной частью большинства приложений. 1. 2. 3. Командные языки с синтаксисом, зависящим от контекста, обычно не столь четкие и структурированные, как в только что приведенном примере. Основные проблемы с этими спецификациями заключаются в том, что синтаксис какого-либо поля зависит от семантики другого поля. Дело усложняется еще и тем, что синтаксис определенного поля команды может зависеть от специфической синтаксической формы и/или от значений (семантики), приведенных в последующих полях.
Лучшее, что можно сделать с такими языками, — это похоронить их. Их почти невозможно использовать, невозможно поддерживать, на них очень трудно программировать, но их очень легко сломать. Как правило, в таких языках код, реализующий синтаксический анализатор, полностью скрыт и так же непоследователен, как и сам язык. Перед тестировщиками подобного мусора стоит задача убедить разработчиков, что необходимо внести изменения в этот язык. Так как исследования специфических хитросплетений — сложная задача, то нет смысла за нее браться.
Такую халтуру настолько легко сломать, что вы сможете легко сделать это вручную. Это один из немногих случаев, когда тестирование заставляет меня чувствовать вину за насилие нэд слабым, подобно тому, что должен чувствовать взрослый, обижающий ребенка или маленькуюю беззащитную зверюшку. Командно-управляемое программное обеспечение. Это наиболее очевидное приложение, и, по всей видимости, именно в него командные языки включаются чаще всего. Если система преимущественно командно-управляемая, то почти вся проверка может быть организована при помощи синтаксического тестирования.
Я считаю полезным использование синтаксического тестирования в подобных случаях. Программное обеспечение, управляемое при помощи меню. Широко распространенная альтернатива командно-управляемому программному обеспечению — это программное обеспечение, управляемое при помощи меню, в котором действия выполняются путем выбора определенных пунктов меню. Наиболее подходящий метод для тестирования программ, управляемых подобным образом, — это тестирование конечного автомата, рассматриваемое в главе 9. Вне зависимости, управляется программа при помощи меню или нет, всегда существуют поля с данными, и у этих полей есть определенный синтаксис, для проверки которого синтаксическое тестирование является вполне эффективным способом проверки. Делается это очень просто, поскольку дерево синтаксиса, как правило, небольшое. Макроязыки. Множество коммерческих программных пакетов для РС имеет встроенный макроязык, называемый также языком сценариев.
Он представляет собой язык программирования, который может использоваться 8.5. Рассмотрение приложений 231 для автоматизации повторяющихся операций. В качестве примеров можно привести командный язык пакетной обработки в МБ-()ОБ, оболочку Ыоггоп Псзкгор для языка сценариев чтг1пг1оьуз, макроязыки 1лгцз 123 и Юогг1рег(есц язык сценариев СгозвТа1к для САЯ.-1Ч. Эти языки часто реализуются в коммерческих пакетах не только для удобства пользователей, но и потому, что с их помощью удобнее всего реализовать множество сложных функций, таких как составление стандартных писем в текстовом редакторе.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
