Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 64

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 64)

Однако какой бы путь вы ни выбрали, вы должны убедиться в том, что ваши выходные коды соответствуют последовательности действий в реальной программе и объяснить все расхождения, если такое соответствие отсутствует. 3. Находитесь ли вы в начальном состоянии? Методы, обсуждаемые в этой книге, предполагают существование хотя бы одного начального состояния, а также то, что в него можно попасть. В сложных системах может быть несколько начальных состояний. Например, начальное состояние для операции, выполняемой одиночным пользователем, скорее всего, будет отличаться от начального состояния для сетевой операции.

Вы не можете начать тест, пока вы не обнаружили и не исследовали начальное состояние. Сообщений программы, что вы находитесь в начальном состоянии, недостаточно. В конце концов, это может быть как раз та ошибка, которую вы ищете. Начальное состояние обладает определенными свойствами, такими как список открытых файлов, используемые ресурсы, активные программы и так далее.

Проверьте это. Если ваше начальное состояние представляет собой что-нибудь вроде начальной загрузки или загрузки в память, то вы должны проверить каждое состояние и каждый переход в этом наборе состояний. Это может быть достаточно сложно, если вы не используете соответствующие инструментальные средства для вашей разработки тестов, так как подобные последовательности часто выполняются автоматически. Пошаговое отслеживание переходов необычайно полезно при тестировании. 4.

Доступны ли вам все выходные состояния? Как правило, программы содер жат более одного выходного состояния или набора выходных состояний. При попадании в такое состояние запускается процедура выхода из вашей модели. Наипростейший пример — состояние, в котором закрывается тестируемая программа. Однако далеко не всегда все так просто. К примеру, если я решил закрыть свой текстовый редактор, меня просят подтвердить это. Если я подтверждаю свой выбор и у меня есть какие-либо открытые файлы, которые не были предварительно сохранены, программа спросит меня, хочу ли я сохранить изменения. Это уже нетривиальный набор выходных состояний.

5. Проверьте состояния. Все ли требуемые состояния существуют? Целью об хода через выбранное состояние является проверка существования состояния и его доступности. Разумеется, вы должны иметь в распоряжении надежные средства, при помощи которых вы сможете владеть информацией о состоянии в любой момент времени. Обычно при тестировании программ такая возможность существует, особенно если есть явный счетчик состояний и если разработчики позаботились об удобстве тестирования. Если у вас нет средств для идентификации состояния, тестирование, хотя в принципе и возможно, становится гораздо более сложной задачей, и его описание лежит за рамками данной книги. 6.

Нет ли лишних состояний? Это тяжело определить, как теоретически, так и практически. Однако при помощи эвристического метода, описанного 254 Глава 9 ° Тестирование систем с конечным числом состояний ниже в разделе 9А.З, вы, скорее всего, сможете обнаружить лишние состояния, если они существуют. 7. Проверьте каждый переход. Каждому переходу соответствует потенциальный выход. Точнее говоря, существует итог каждого перехода.

Переход состоит из двух вещеи: нового состояния и выхода, если он есть. Если существует пустой «выход», соответствующий переходу, он также должен быть проверен. Вы задали кодирование состояний. Это означает, что у вас есть подробные характеристики, которые будут однозначно идентифицировать состояния. Проверьте каждый компонент кодирования состояния. Однако вы можете быть введены в заблуждение вероятностью существования лишних состояний, обсуждаемых в следующем разделе.

Также вы должны проверить каждое выходное действие, определенное в кодировании выхода вашей модели, и особенно соответствукнцее пустому выходу. Убедитесь, что при пустом выходе на самом деле ничего не происходит. Если вы перешли в корректное состояние и ваши выходы (включая пустой) для атого перехода также были корректными, то с хорошей уверенностью можно сказать, что и переход был корректным. 9Я.З. Проверка лишних состояний В конечных автоматах, например, в реализации аппаратных средств, проблема поиска лишних состояний в общем виде необычайно сложна, хорошо проработана и потому не рассматривается в данной книге. Однако в тестировании программного обеспечения мы имеем дело не с общей проблемой, а с более простыми частными случаями.

Для частного случая мы делаем допущения, которые не могут быть сделаны в общем случае например, мы можем знать, в каком состоянии в данный момент находимся. В другом случае задачу упрощает природа ошибок состояний в программе. Когда у нас в программном обеспечении есть лишние состояния, лишь в очень редких случаях их число ограничивается одним или двумя.

Чаще мы сталкиваемся с удвоением числа ожидаемых состояний илп даже числом состояний, превышающим ожидаемое в 1000 раз. Лишние состояния возникают из-за скрытых закономерностей в поведении систем с конечным числом состояний. Один дополнительный бит, дающий вклад в поведение состояния, удваивает общее число состояний. На рисунке рассматривается наглядный пример.

Нижний автомат с конечным числом состояний — это то, что, как мы полагаем, мы тестируем. Однако либо из-за ошибок, либо из-за неполноты модели где-то возникает иной фактор, о котором мы не догадываемся. Из-за ошибки, произошедшей во время одного из наших тестовых обходов, вместо перехода из А в В мы на самом деле переходим из А в В', в параллельное гиперпространство. К слову, в программном обеспечении мы, как правило, имеем дело не с одним гиперпространством, а с тысячами н миллионами их. Если все эти параллельные гиперпространства идентичны друг другу во всех отношениях (за исключением фактора, являющегося источником всех этих лишних состояний), то, скорее всего, мы не сможем их обнаружить при помощи конечного числа тестов.

Однако в этом случае ошибка не представляет опасности. 9.4. Методы 255 Если же альтернативные системы с конечным числом состояний хоть немного отличаются друг от друга, то мы это можем обнаружить. В чем тогда проблема? Ведь в итоге у нас есть всего лишь небольшое безобидное различие в поведении, которым можно легко пренебречь. Хороший вопрос, требующий ответа. Как я уже говорил, параллельных гиперпространств обычно не одно, а миллионы. В большинстве из нпх небольшие расхождения действительно безобидны, и с ними можно смириться, однако во многих гиперпрострапствах симптомы ошибок фатальны. Я всегда убеждался, что «безобидные» несоответствия в поведении вырастают в серьезные ошибки. Вы не сможете заставить разработчиков волноваться по поводу «безобидных» симптомов.

Если вы доложите им о мерцании экрана или о том, что курсор мышки ведет себя не так, как должен, они лишь пожмут плечами. Однако если, исследуя зти изменения в поведении, вы обнаружите ошибки, ведущие к аварии, и если вы будете делать это регулярно, то вы заставите их обратить на это внимание.

Ищите фатальные ошибки экспериментальным путем. Меняйте параметры (такие как длина файла, контрольные коды, опции и т. д.), которые не должны оказывать влияния на переход, и наблюдайте, не увеличится ли несоответствие в поведении. Например, уведите курсор мыши дальше илн заставьте экран моргнуть два раза. Следуйте в направлениях, в которых различие в поведении растет, и вскоре вы вычислите набор обстоятельств, ведущий к фатальной ошибке. Несколько часов тестирования и внимательного наблюдения за типичным РС-приложением, — и вы будете вознаграждены сбоем в программе или разрушенной базой данных (однако убедитесь сначала, что у вас есть хорошие средства резервирования и восстановления). Мы можем обнаружить лишние состояния в гнперпространстве, в точности повторяя каждый тест. Пройдите из начального состояния в заданное состояние и обратно (по возможности не используя команлу йЕ5Е Г).

Затем вы сравниваете все компоненты, имеющие отношение к текущему состоянию (например, открытые файлы, используемые ресурсы, состояние окна и т, д.), до прохождения теста с состоянием этих же компонентов после прохождения теста. Затем данный тест (в точности) воспроизводится, и каждый выход для каждого перехода сравнивается с предыдущим прогоном и со всеми остальными.

Каждое повторение изме- 256 Глава 9 ° Тестирование систем с конечным числом состояний пения в поведении записывается'. Любые отклонения в повелении, лаже если они безвредные, сигнализируют о наличии лишних состояний. Выполнение привеленных выше рекомендаций не гарантирует, что вы обнаружите лишние состояния, если таковые существуют. В общем случае полобное повеление можно распознать единственным способом, выбирая различные пути из начального состояния в заланное состояние. Повторение тестов — это не лучшее, что вы можете слелать, олнако это меньшее из того, что вы обязаны сделать. Если не повторять тесты, то вероятность обнаружения ошибки мала.

Принцип точного повторения тестов не должен ограничиваться тестированием поведения систем с конечным числом состояшгй. Воспроизведение любого теста описанным способом является превосхолной илеей, поскольку ошибки, порождающие нежелательное поведение, характерное лля системы с конечным числом состояний, не могут знать, какой метод мы используем.

Поэтому обязательно повторяйте свои тесты! 9.4.4. Иерархия покрытия Как и Лля других метолов тестирования, лля систем с конечным числом состояний существует иерархия покрытия. Покрытие узлов само по себе почти ничего не может сказать. Более того, если разработчики уже провели тестирование программы на нижнем уровне (например, было выполнено тестирование модулей), то, скорее всего, это тестирование обеспечит покрытие узлов.

Главный объект при тестировании систем с конечным числом состояний — это перехопы. Для тестирования переходов мы сначала должны убелиться в корректности состояний (обеспечить покрытие узлов). Поэтому, как и лля большинства методов тестирования, мы будем считать, что это минимум, необходимый лля достижения покрытия связей (перехолов). Есть ли что-нибуль еще, кроме покрытия связей? На самом деле есть еще масса различных вариантов исследования графа, но все они лежат за рамками данной книги и, что более важно, выхолят за рамки интересов большинства тестировщиков, использующих этот метол.

Иерархия покрытия здесь соответствует набору все более ллинных последовательностей тестов. Длина послеловательности теста опрелеляется числом перехоЛов (или, что эквивалентно, числом вхояных символов). Существует целый раздел литературы, описывающей методы тестирования конечных автоматов.

Я не буду останавливаться на описании этих методов (это заняло бы всю книгу), олнако я могу дать некоторый обзор причин, по которым эти метолы важны лля нас. Мы лелаем три важных прелположения при использовании методов тестирования систем с конечным числом состояний лля программного обеспечения. 1. Мы, как правило, знаем состояние, в котором мы цахолилисьдо каждого перехода и в котором будем находиться после него. В общем случае, например, при тестировании интегральных схем у нас нет другого способа узнать это, ' Это не так сложно, как может показаться.

Характеристики

Список файлов книги