Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 41
Текст из файла (страница 41)
П IТсуа! С11а .От1/Фр!/Аа! Это два семейства тестов, поскольку для транспортных средств возникает много тестов. И поэтому мы должны проверить вопросы синхронизации и поведение очереди. 6.4.5. Тестирование синхронизации При слиянии двух илп более транзакций или если одна поглощает другую, мы всегда должны спроектировать и провести тестирование синхронизации. В нашей модели мы можем рассмотреть в качестве примера узел Сба или узел Т1. Оба они являются узлами поглогцения. Узел Сба незамысловат, и для его проверки нам необходимо пять тестов. Узел Т1 представляется более интересным и перспективным, поскольку в нем происходит слияние формы (льготы на транспортное средство), которая порождена в этой «ке модели. Посмотрев на эту модель, вы можете ошибочно заявить: «Мпе не нужно пяти тестовых вариантов.
Путь от Ф1д к Т1, очевидно, короче, чем путь, лежащий через процедуру обработки транспортного средства (от С11а до Тсум). Таким образом, я могу сделать вывод, что транзакция формы 2106 всегда приходит в узел Т1 раньше, чем данные о транспортном средстве, и ждет их там. Значит, у нас есть только 2 варианта для рассмотрения. Либо форма 2106 приходит раньше данных о транспортном средстве, либо данные о транспортном средстве отсутствуют». Если вы и в самом деле так считаете, то делаете ошибочное допущение и попадете в ту же ловушку, что и программисты, создавшие программу, которую вы тестируете. Это все рациональные приближения, однако природа ошибок не рациональна.
К тому же обе связи, входящие в Т1, могли бы представлять собой очереди (в данном примере это не так), и правило упорядочения может вызывать любые перестановки. Если вы не можете с уверенностью сказать, что возможен лишь один определенный порядок (например, форма 2106 приходит раньше данных о транспортном средстве), то вам будет лучше проверить все случаи. Система должна вести себя разумно для всех случаев. Я подразумеваю, что она не уничтожает, не изменяет и не теряет данные, а неполные транзакции она отвергает, уведомляя об этом пользователя илн иную систему, породившую транзакцию.
Насколько глубоко мы должны проверять синхронизацию? Должны ли мы учитывать взаимодействие одного узла слияния с другим, находящимся ниже 6.4. Методика 169 в исследуемом порожденном подграфе? Гипотетически — ла, но на самом деле не стоит этого делать. Число тестов растет экспоненциально, а продуктивность таких тестов синхронизации высокого порядка совсем не очевидна. Более того, проведение тестов для одного слияния уже является непростой задачей, проверка же последовательности слияний может оказаться невозможной.
А что, если один и тот же узел слияния встречается в нескольких порожденных подграфах? Следует ли повторять тесты синхронизации в каждом из них? Скорее всего, не следует, и главным образом потому, что зто приведет к быстрому росту числа тестовых вариантов. Но есть и другая причина. Вы, возможно, сможете проверить эти случаи быстрее и с меньшими усилиями путем автоматической генерации соответствующим образом подобранных случайных тестовых вариантов. 6.4.6.
Тестирование очереди Проверка любой, не слишком простой очереди требует применения целой группы тестов. Где это следует делать, в системном тестировании или на более низком уровне компонентного тестирования? Если узел имеет только одну входящую связь, и у меня есть причины считать, что этой очередью управляет представляемый этим узлом компонент, то я отдаю предпочтение тестированию очерели в контексте компонентного тестирования. Если узел является узлом слияния, поглощения или соединения (несколы<о входягцнх связей), то я буду должен проверить очередь на уровне компонентов, а затем повторить эти тесты при тестировании системы. Какие именно тесты вам нужны, зависит от правила упорядочения и правила выбора сервера, если он есть.
Ниже приводятся некоторые полезные виды тестов. 1. Тестирование пределов длины очереди. Максимальная длина очереди. Попытайтесь превысить предельно допустимое число элементов в очереди. Пустая очередь. Активизируйте обработку, когда в очереди ничего нет. Проверка циклов. Узел, обрабатывающий очередь, содержит цикл для обработки элементов очереди (особенно это касается групповых серверов). Используйте методы тестирования циклов для нескольких элементов в очереди. Динамические изменения длины очереди.
Попытка добавить транзакцию в очередь (особенно в очередь пакетной обработки) во время проведения обработки элементов является, очевидно, необходимым тестовым вариантом. Кроме этого, попробуйте улалить элемент из очереди, пока обработчик очереди активен, если система обработки это вам позволит. 2.
Тестирование сортировки и выбора. Часто правила упорядочения включают в себя процедуру сортировки. Например, правило может указывать, что в первую очередь обрабатываются наиболее старые транзакции. Это правило отличается от правила построения очереди Е1ЕО (Е1гэг 1п Е)гэг Оиг — первым прибыл, первым обслужен). Очередь Г1ГО строится на основе положения 170 Глава 6 ° Тестирование потоков транзакций элемента в очереди. За основу в правиле «старейшая транзакция обрабатывается первой» берется отметка времени в контрольной записи транзакции.
Поскольку транзакции проходят различные пути до того, как становятся в данную очередь, порядок Г1РО может отличаться от порядка отметок времени. Другой пример — это очереди с приоритетом, в которых существует внутренняя сортировка по степени приоритета. Обработка должна включать в себя явную процедуру сортировки или, если очередь не слишком длинная, может осуществляться сканирование всей очереди, чтобы выбрать следующий элемент для обработки. Оба этих варианта представляют собой неявную процедуру сортировки. Сортировка всегда происходит на основе реального или скрытого ключа.
Существуют элегантные способы тестирования процедур сортировки, но они лежат за рамками данной книги. Мы ограничимся некоторыми простыми, но эффективными эвристическими методами. Ниже приведено несколько случаев, которые стоит проверить. ° Правильное упорядочение. ° Все элементы имеют одинаковые ключи сортировки. Элементы располагаются в обратном порядке.
«Присутствует только один элемент в очереди. Проверьте все дискретные ключи сортировки (то есть приоритеты). Один элемент для каждого дискретного ключа сортировки. ° Для многоуровневых ключей (например, возраст внутри одного приоритета) рассмотрите комбинации приведенных выше тестов в контексте тестирования вложенных пиклов, 3. Тестирование упорядочения очереди. Если в вашем случае правило упорядочения отличается от Г1ГО, вы должны провести тестирование упорядочения очереди, чтобы убедиться, что оно было реализовано корректно. Если зто правило определяется неявной сортировкой (например, приоритетом), то используйте описанные выше тесты.
За исключением этого, дать общие рекомендации довольно трудно, поскольку правила упорядочения могут быть самыми разными. 4. Тестирование приоритетов. Следует различать многоуровневые приоритеты в одной очереди и отдельную очередь для каждого приоритета. В первом случае тестирование представляет собой проверку сортировки, основанной на приоритетах. Во втором случае необходимы некоторые дополнительные тесты: ° Существует только один приоритет. Рассмотреть этот случай для каждого приоритета. Присутствуют все приоритеты, берется по одному элементу на каждый приоритет. «Присутствуют все приоритеты, берется несколько элементов на каждый приоритет.
!четодика 171 Приоритеты меняются во время обработки (если это позволяет приложение). Протестируйте случаи повышения и понижения приоритета. Очереди по приоритету заслуживают особого внимания, особенно если существуют другие ключи, используемые в других процессах. Например, пусть в одной очереди ключ определяется в области значений, а в другой очереди ключ представляет собой степень секретности.
Для ключевых значений сначала обрабатываются транзакции, соответствующие наибольшим значениям, затем меньшим, и так далее. В очереди, упорядоченной по степени безопасности, первыми обрабатываются совершенно секретные транзакции, затем просто секретные, затем доверительные и так далее. Обе очереди являются очередями по приоритету, поскольку, хотя одно поле и называется «значение», а другое «степень секретности», поведение элементов в обеих очередях определяется приоритетом.
О чем тогда беспокоиться? Все дело в том, что прн возникновении подобной ситуации программист с большой вероятностью перепутает две очереди н использует неверный ключ. В моей практике я видел, как «конфиденцнальность» путали с «безопасностью» и оба эти понятия путали с «приоритетом». 5. Тестирование правила выбора сервера. Проверяйте множественные серверы с одной очередью путем низкоуровневого компонентного тестирования.
Если у вас есть несколы<о очередей, которые служат входными связями во множественный сервер, то правило выбора сервера должно быть проверено (или хотя бы перепроверено) при тестировании системы. Тестирование правила выбора сервера напоминает тестирование сортировки, и выполнять его надо очень тщательно при помощи следующих вариантов: » Все элементы в одной очереди. Во всех очерелях один элемент. Во всех очередях одинаковое число алементов. б.4.7. А1~ТИВИЗ~ЦИЯ Проблема активизации при тестировании потоков транзакций отличается от аналогичной проблемы в методах тестирования потоков управления или потоков данных. Задача заключается не в том, чтобы найти такие транзакции, которые проследуют по выбрашюму пути.
На самом деле суть проблемы — создать транзакции, выполняющие это условие, и ввести эти транзакции в систему. Хотя обычные транзакции, как правило, не слишком сложны, тнцы транзакций, представленные в разделе 6З.1, иногла бывает просто невозможно ввести. Ниже приведены некоторые характерные проблемы и возможные способы их решения. 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
