Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 65
Текст из файла (страница 65)
Мы имеем а распоряжении ореносходные инструментальные средстаа (например, средства захвата/воспроизведения, си. главу 10) для аьн~олнения такого срааасиия. 9.4. Методы 257 кроме как путем наблюдения за поведением тестируемой системы (то есть за выходами). В некоторых случаях тестирования программного обеспечения (таких как при тестировании протоколов), при которых у вас нет информации о внутреннем состоянии (например, системы, с которой у вас установлена связь), определить внутреннее состояние тестируемой системы невозможно'.
Если у вас возникли проблемы с получением информации о состоянии, то основных методов, описанных в этой книге, будет недостаточно. Лучше всего разрабатывать программное обеспечение таким образом, чтобы эта информация была доступна. Выходные действия в аппаратном обеспечении в большинстве своем достаточно просты, например, подача выходного импульса на определенную ножку разъема. Однако таких переходов, которые могут вызывать возникновение подобного импульса, может быть не один и не два. В таком случае вы не сможете с легкостью определить, является ли ваш выход правильным. Это значит, что случайная корректность здесь не исключение, а правило, В программном обеспечении выходные действия сложны и часто однозначно соответствуют переходу. Из-за их сложности, зная выходное действие, легко можно определить соответствующий переход.
Если они эквивалентньг импульсам в линии, — например, такое может иметь место в программном обеспечении, управляющем протоколами, — тогда задача тестирования становится гораздо более сложной, и вам, возможно, пе будет хватать основных методов, описанных в этой книге. Рассмотрим природу интересуюших нас ошибок. Мы можем искать ошибки в спецификации. Это представляется проблематичным, и для этого тестирование систем с конечным числом состояний неприменимо.
Если разработчики выполнили гигантскую работу, реализуя некорректную систему с конечным числом состояний, то обнаружить это невозможно, какой бы метод тестирования вы ни использовали. Мы предполагаем, что наша моделысорректна и что ошибки содержатся только в реализации этой модели. Наиболее вероятной ошибкой в программе является не некорректное состояние или неправильный переход, а крупное явление, например, целые параллельные системы с конечным числом состояний, возникающие из-за скрытых параметров состояний.
В качестве простого примера можно рассмотреть программу, предназначенную делать резервные копии каждые несколько секунд, для того чтобы в случае сбоя в системе можно было восстановить информацию, используй рбйбрййые файлы. Предположим, программа не в состоянии очистить все эти данные при нормальном выходе. Она очищает резервные файлы, но оставляет ключевой параметр состояния без изменений. При следующем старте программа пытается провести восстановление (как ей сказано), однако «требуемые» резервные файлы не су- ' Заметим, что современные разработчики интегральных схем внслряют в свои изделия большое количество дополнительных схем, чтобы слелать зту информацию доступной для приборов, тестирующих продукцию. 258 Глава 9 ° тестирование систем с конечным числом состояний шествуют, что ведет к аварии, Один ошибочный байт данных означает 255 альтернативных пространств, одно 32-битное слово — 4,3 миллиарда таких пространств.
Если вы тщательно исследуете крошечные изменения в поведении, то можете узнать, в каком пространстве находитесь. 9.4.5. Активизация и предсказание итога Проблемы активизации и предсказания итога при тестировании систем с конечным числом состояний как таковой не существует, «Активизация» заключается во вводе команд или входов, которые инициируют желаемый переход. Предсказание итога означает проведение выходного кодирования.
Каждое из этих заданий требует существенных затрат усилий, однако они просты и для их выполнения не нужны специальные метолы. Они должны быть сделаны. Наибольшая ошибка, которую тестировщик может здесь допустить, — зто отнестись к этим пунктам невнимательно. Вы действительно должны определить все до мельчайших деталей. Это несложно сделать, используя соответствующие коммерческие инструментальные средства, такие как захват/воспроизведение, обсуждаемые в главе 10.
Тестирование систем с конечным числом состояний наиболее эффективно не при первоначальном тестировании программного обеспечения, а при его повторном тестировании, после внесения в него изменений в ходе сопровождения. Оно проводится с целью убедиться, что вещи, которые не должны были меняться, на самом деле остались неизменными. В таком случае предыдущий прогон теста дает нам как требуемые входы (обеспечивает активизацию), так и итоги. 9.4.6.
Подсчет состояний Наиболее важное дело тестировгцика (и особенно независимого) заключается в подсчете числа состояний, числа входных кодов, а затем и их произведения состояние-символ. Программисты, которые не учитывают поведение систем с конечным числом состояний, реализуют конечныс автоматы с триллионами состояний и миллиардами входных кодов. Они не могут быть протестированы должным образом ни сейчас, ни в будущем.
С точки зрения тестировщика, такие ущербные программы ломаются с необычайной легкостью. Системы с конечным числом состояний, основанные всего на нескольких переменных факторах, растут очень быстро. Рассмотрите задачу 6 из упражнений в конце главы, чтобы почувствовать это самим. Одно время я заниматься разработкой логики и усвоил, что должен проводить формальный анализ любого конечного автомата, если произведение состояние-символ превышает 12, так как ато число уже превышало границы моих возможностей интуитивного тестирования дизайна. Для проверки корректности конечного автомата с произведением состояние-символ порядка сотен необходимы месяцы работы, если только в состояниях и переходах не существует закономерностей.
В этих случаях совершенно необходим формальный анализ (остающийся за пределами данной книги). Затраты же на автоматы с произведением порядка тысяч превышают годы или века работы одного человека — здесь ничего нельзя сделать интуитивно. 9.4. Методы 259 Из вышесказанного можно сделать вывод о том, что имеет смысл делать, а что не имеет. Предположим, вы исследовали систему и определили, что поведение системы задается пятью факторами с 7, 13, 8, 4 и 3 возможными значениями каждого из них соответственно; вы также определили, что возможные выходы (после кодирования) включают 42 отдельных действия. Произведение этих чисел дает 366 912. Как тестировшик вы должны просмотреть документацию для каждого из этих переходов. Если это невозможно, то программа не тестируема и ненадежна.
Разумеется, разработчики могли бы реализовать вложенные машины, и мы надеемся, что они так и сделали. В этом случае вам надо будет протестировать шесть гораздо более простых автоматов. Поиск значения произведения состояние-символ (для не вложенных автоматов) — это самое простое и эффективное дело, которое вы можете сделать, тестируя системы с конечным числом состояний. Сделав это на первом этапе, вы сможете узнать, может ли ваша программа быть адекватно протестирована и, следовательно, будет ли она устойчива к сбоям.
9.4.7. Средства поддержки и тестируемость Это как раз та проблема, где программисты могут и должны отрабатывать свое жалование. Я решительно настаиваю на том, чтобы программисты использовали явные реализации конечных автоматов (то есть задаваемые таблицами), если произведение состояние-символ больше десяти. В [ВЕ!290~ описывается необходимый порядок работы.
Если это условие выполнено, а проект тшательно проработан и легко поддается анализу (и, следовательно, вероятность ошибок в нем невелика), то следуюшие характеристики существенно облегчат вам тестирование. 1. Явный счетчик состояний. Существует одна заявленная переменная, или адрес ячейки памяти, которые определяют состояние в любой момент времени. Эта информация доступна и может быть записана. Текущее состояние также всегда известно.
2. Основной сброс и сброс в определенное состояние. Существует множество вариантов сброса, например, основной сброс в начальное состояние. Он, в свою очередь, может представлять собой полный сброс (все заново инициализируется), только восстановление состояния (меняется только счетчик состояний, а статус файлов и прочее остаются без изменений) или возврат в определенное состояние. Сброс может быть достаточно тщательно проработан и может иметь достаточно много параметров, точно определяюших, что именно должно быть изменено (кроме счетчика состояний). Хорошие средства сброса чрезвычайно важны в больших автоматах состояний, где для того, чтобы попасть в заданное состояние без использования механизма сброса, пришлось бы пройти через множество других состояний.
3. Пошаговое выполнение. Это означает возможность пошагового прохождения графа состояний, по одному переходу за шаг, а в случае выполнения составных выходных действий — одно выходное событие за шаг. После каждого перехода предусматривается пауза, пользуясь которой, тестировшик, 260 Глава 9 ° Тестирование систем с конечным числом состояний если тест выполняется вручную, мог бы разобраться, что произошло.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
