Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 62
Текст из файла (страница 62)
4. Они обеспечивают повторяемость выхода. Определенный выход (например, Открыть Файл) может соответствовать множеству различных переходов, Это могло бы потребовать отдельного состояния для каждого случая и, следовательно, привело бы к увеличению размера модели. 5. Их таблица представления проще. Представление модели с конечным числом состояний в виде таблицы проще для моделей Мили, чем для моделей Мура. Эти две модели теоретически эквивалентны. Каждой модели Мура соответствует модель Мили и наоборот. Зачем тогда нужны эти разговоры? Согласно моим наблюдениям, в случаях, когда модели с конечным числом состояний используются в проектировании, например, при объектно-ориентированном подходе, чаще используют модель Мура, а не Мили.
Вы не должны смешивать два типа моделей. Выберите один из них (я настоятельно рекомендую Мили) и придерживайтесь его. Читатели, знакомые с графико-теоретическими моделями, обратят внимание на то, что я отдаю предпочтение моделям со взвешенными связями, а не моделям со взвешенными узлами. Модель Мура, разумеется, относится к последним, если рассматривать выходы. Модель Мура имеет определенные преимущества при описании последовательно переключающихся схем, особенно асинхронных. Обе модели были изначально созданы в рамках теории переключающихся схем и теории автоматов.
Однако мы имеем дело с программным обеспечением, а не с последовательно переключакицимися схемами. В большинстве случаев доказательства теорем проще проводить для моделей со взвешенными узлами, чем со взвешенными связями, и этим объясняется превалирование первых в научных работах.
Тем не менее, когда дело доходит до построения реальных инструментов, в которых графы представляются в виде списка связей, или при использовании алгоритма сокращения числа узлов (см. [ВЕ1290]), модели с взвешенными связями имеют неоспоримые преимущества. 9.3.3. Таблицы переходов Графическая форма представления моделей полезна скорее для обучения, а не как рабочий инструмент. Вы можете использовать представление в виде списка связей, так же как и для любого другого графа, и, разумеется, мы часто видим подобное представление моделей с конечным числом состояний в проектных документах. Альтернатива этому — использование табличного представления. В этом Таблица 9.1.
Таблица состояний корабля Елгегрпае Состояние з>з з>п п>п п>з п>р р>р р>п з>р р>з ЗН 30 ЗВ ПН ПО ПВ РН РО РВ ЗН ПН ЗН ПО 30 ПВ ПН ЗН РН ПО 30 РО ПВ ЗВ РВ РО ПН РВ ПО РВ ПВ Я оставил пустыми ячейки, содержащие запрещенные комбинации (состояние — вход). Они невозможны в корректно реализованной системе. В данном примере некоторые переходы запрещены в соответствии с законами физики. Другие входы, такие как зар и раз запрещены из-за технических ограничений, накладываемых оборудованием — системой управления двигателем. Рассмотрите„однако, вопросы 2, 3 и 4 в конце этой главы. В этом примере я не задал выходы.
Какие выходы могли бы быть в модели корабля Епгегрг)зе? Наверное, запуск топливного насоса и зажигание. Различие между разгоном вперед и задним ходом могло бы заключаться в том, какой из топливных клапанов (носовой или кормовой) открыт. Топливный насос и зажигание должны активироваться для обоих направлений двигателя. Поэтому несколько выходных функций могут соответствовать множеству различных переходов. При тестировании состояний мы основное внимание уделяем проверке состояний и переходов, а потом уж выходам. В менее фантастическом примере модели меню мы можем закрывать и открывать файлы во множестве различных пунктов меню.
Безусловно, мы должны проверить отг<рьгтие и закрытие файла. Но если файл открывается, как и должен, и мы в этом убедились, то у нас нет необходимости проводить тестирование открытия файла для всех случаев (то есть всех переходов), когда это открытие может случиться. случае мы могли бы начертить таблицу и х и (где и — это число состояний) и в каждую ячейку записать соответствующую ей комбинацию вход/выход. Могли бы, но не станем этого делать, поскольку такая таблица (для большей части программного обеспечения) будет почти целиком пуста. Вместо этого мы используем таблицу состояиий-переходов, или коротко таблицу состояний. В таблице состояний каждому состоянию соответствует одна строка, а каждому входу один столбец.
Фактически мы можем начертить две таблицы с одинаковой разбивкой: таблицу состояний-переходов и таблицу выходов. В ячейку первой таблицы мы записываем СЛЕДУЮЩЕЕ СОСТОЯНИЕ. Во вторую таблицу мы заносим соответствующий код выхода (сслн он есть) для данного перехода. Иногда бывает удобно комбинировать эти две таблицы, записывая и следующее состояние и выходные данные в одну и ту же ячейку, например, в виде следующее состояние!код ви. 248 Глава 9 ° Тестирование систем с конечным числом состояний 9.3.4. Вложенные автоматы Обсуждаемая выше таблица достаточно сложна: она имеет 81 ячейку (девять состояний и девять входов).
Пример меню на рабочем столе еще более сложен. Я насчитал 12 пунктов в строке меню и выбрал те пункты, которые могут быть активированы нажатием на обычную клавишу — 23 пункта для 26-буквенного алфавита и плюс еще девять цифр, всего — 32 входных кода. Для представления этого в виде одной таблицы нам нужна таблица 12*32 = 382 ячейки. Мы могли бы построить такую большую таблицу, но мы не станем этого делать. На это есть несколько причин. !. Слишком много входов.
Слишком много возможностей для ошибки при проектировании тестов. 2. Слишком много пустых ячеек. Е~це больше возможностей для ошибки. 3. Слишком много запрещенных комбинаций состояние/вход. 4. Есть лучший способ Под лучшим способом я подразумеваю вложенные автоматы. Этого, что большинство людей делает интуитивно. Меню панели управления %1пг(оез включает в себя три пункта: Панель управления, Ыастройки и Справка. Мы можем построить автомат с четырьмя состояниями: по одному состоянию для каждого из трех пунктов меню и еще одно состояние, соответствующее случаю, когда ни одно меню не активно. Мы строим модель этого уровня, исследуем все способы переключения между меню, активации и деактивации меню и так далее, но ничего не делаем и не выбираем в рассматриваемых меню.
Далее для каждого из трех меню мы строим отдельную модель с конечным числом состояний, которая описывает то, как данное меню работает и какие опции в нем можно выбирать. То же относится к выбору значка в начальном состоянии (ни одно меню не открыто) базовой модели. Продолжим рассмотрение нашего примера вложенной системы и исследуем меню самого верхнего уровня Настройки. Мы имеем модель со следующими опциями: Цвет, Шрифты, Порты, Мышь, Рабочий стол, Клавиатура, Принтеры, Региональные установки, Дата/Время, 38б-улучшенный, Драйверы, Звук и Выход. Подчеркнутые буквы показывают, какую клавишу надо нажать, чтобы выбрать данный пункт. Итак, для обработки данного меню нам требуется другая модель.
Если в этой модели мы делаем какой-либо выбор, то, как правило, активируется еше одно меню, со своими пунктами, а значит и со своей моделью и так далее. 9.3. Отношения и модель 249 Вложенные автоматы — это, по сути, единственный практический способ работы со сложными системами.
Если вы исследуете стандартный проект, построенный на основе автоматов с конечным числом состояний, то увидите, что хорошие разработчики поступают точно так же. Они используют вложение своих моделей. В результате реализация проекта имеет те же самые вложения. Практика показывает, что без специальных инструментов очень трудно работать с таблицами состояний, имеющими более нескольких сотен входов.
Это не очень много — всего 10 состояний и 20 входных кодов, Большие автоматы с сотнями входов постоянно используются в программном обеспечении, управляющем работой телефонных узлов, но некоторые подобные таблицы требуют сотен лет работы одного человека для создания, тестирования и отладки. 9.3.5. Улучшаем модель Вероятность возникновения ошибок при создании модели достаточно велика. На практике модели на основе автоматов с конечным числом состояний требуют больших трудозатрат.
Вы должны уметь различать ошибки модели, ошибки в тестах, основанных на этой модели, и ошибки системы. Легче избавиться от ошибок моделирования до того, как вы начали разрабатывать тест, чем потом искать их во время тестирования. Ниже описаны некоторые вещи, которые стоит поискать в моделях, и то, как их искать. Здесь нам сильно облегчает задачу то, что для таких моделей разработана теория, на основе этой теории созданы алгоритмы, и во многих случаях существуют инструментальные средства, основанные на этих алгоритмах.
Однако не спешите радоваться. Данная теория выходит за рамки этой книги, а алгоритмы, если они реализованы в инструментах, почти всегда предназначены для аппаратного обеспечения и должны быть адаптированы для использования в программных моделях, 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
