Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 38
Текст из файла (страница 38)
Транзакция, которая позже всех поступила в очередь, будет обработана раньше всех. Подобная очередь является обрабатывающим стеком, 158 Глава б ° Тестирование потоков транзакций в котором входящие транзакции помещаются на вершину стека и удаляются с вершины. Пакет. При возникновении определенных условий, таких как определенное число транзакций в очереди, или же в оговоренный момент времени обрабатываются все транзакции в очереди в пакетном режиме. При атом во время обработки новые транзакции накапливаются в новой очереди.
Случайное обслуживание. Обслуживание осуществляется случайным образом — возможно, на основе вероятностного распределения по некоторой величине в контрольной записи транзакции. Очередь по приоритету. Каждая транзакция имеет свой приоритет. Этот приоритет может быть фиксированным или зависеть от свойств транзакции, например, от ее возраста. Каждая группа транзакций с данным приоритетом обрабатывается как отдельная очередь, причем очередь с наибольшим приоритетом обрабатывается первой.
Внутри отдельной группы транзакций с данным приоритетом сервис может осуществляться по принципу Нг О, 1гг О и т. д. Множественная обработка. Для обработки очереди может использоваться один сервер (односерверная очередь) или несколько серверов (многосерверная очередь). Кроме правила упорядочения конкретной очереди, может существовать правило выбора сервера. Например, в супермаркете можно выбрать, в какую из очередей к кассам встать, В билетной кассе аэропорта, на почте, в банке нужно стоять в основной очереди и ожидать обслуживания до тех пор, пока работник учреждения не скажет «Следующий!» Далее термин простая очередь будет использоваться для оГ>означения односерверной очереди без приоритета, обслуживаемой по принципу НЕО.
Если правило упорядочения не оговорено, то наиболее вероятно, что это простая очередь. За ней следует очередь, обслуживаемая по принципу НЕО в зависимости от приоритета. Очередь с данным приоритетом обрабатывается по принципу НЕО, но первой обрабатывается очередь с наибольшим приоритетом, затем очередь с более низким приоритетом и т. д. Если вы имеете дело с очередью, не являющейся простой, то убедитесь, что очередность приоритетов и, если необходимо, правило выбора сервера реализованы правильно.
б.ЗМ. Слияние и поглощение Существование узлов слияния и поглощения создает дополнительные проблемы при тестировании. Становятся необходимыми тесты синхронизации. Чаще всего возникают новые проблемы и вопросы, которые следует себе задать. 1. Правильные ли типы транзакций объединились? 2. В случае двух транзакций А и В, которые объединяются (или для А, поглощающей В), появляются пять дополнительных ситуаций, которые необходимо протестировать: А приходит, а  — никогда не приходит (А).
° В приходит, а А — никогда не приходит (В). ° А приходит раньше В (А, В). 6.3. Отношения и модель 159 а В приходит раньше А (В, Л). Обе транзакции приходят одновременно (тоесть в пределах оговоренного времени) (АВ). 3. Правилен ли тип выходящей транзакции? Для поглощения это хищник, а для объединения — дочерняя транзакция. При тестировании необходимо рассмотреть каждый из этих случаев. Для узла слияния, имеющего три связи, потребуется протестировать 25 возможных вариантов. Для обозначения одновременных входов транзакций в узел слияния мы будем использовать совместное написание, а для раздельных — запятые. Например, (АВ, С) означает, что А и В приходят в узел одновременно, а за ними следует С.
Необходимо рассмотреть 25 тестовых вариантов. Ниже следуют тестовые варианты для поглощения илн слияния, в котором участвуют три транзакции. Каждая транзакция по отдельности: (А), (В), (С). Две транзакции за раз: (Л, В), (А, С), (В, С), (В, А), (С, А), (С, В), (АВ), (АС), (СВ). Три транзакции за раз: (А, В, С), (В, А, С), (С, А, В), (Л, С, В), (В, С, А), (С, В, А), (А, ВС), (В, АС), (С, АВ), (ВС, А), (АС, В), (АВ, С), (АВС). Число необходимых тестов быстро возрастает для узлов слияния с несколькими объеднняющимися транзакциями. Проектирование тестов легко автоматизировать, но трудно заставить транзакции приходить в определенные узлы в определенном порядке. Так как слиянию и поглощению подвергаются чаще всего транзакции, которые уже прошли через какие-то операции обработки, в отличие от транзакций, пришедших извне, то выполнение этих тестов практически невозможно.
6.3.5. Циклы С одной стороны, циклы в потоках транзакций, строго говоря, создают проблемы. А с другой стороны, они встречаются редко, и если встречаются, то они просты и встречаются нечасто. Цикл, который чаще всего можно обнаружить в потоке транзакций,— это цикл повторения обработки после обнаружения ошибки ввода данных.
Так, например, банкомат дает вам три попытки ввода вашего личного идентификационного номера. Можно ожидать, что похожие циклы повторения будут встречаться в большинстве интерфейсов, таких как каналы связи с другими системами, драйверы устройств и т. д. Очереди, обслуживаемые как пакет, очевидно, содержат цикл для обработки пакетов. Сходным образом каждый узел обработки, обслуживаюший очередь, работает в составе цикла для того, чтобы обрабатывать каждый последующий элемент в очереди и продолжать работу далее. Таким образом, он активируется каждый раз до тех пор, пока очередь не иссякнет. Такие циклы следует тестировать отдельно для каждого узла обработки на более низком уровне интеграции и тестирования.
А это означает, что необходимо выполнять тестирование циклов различных узлов обработки транзакций в контексте компонентного тестирования этих узлов обработки. 6.3.6. Фокус и иерархические модели Модель потока транзакций можно использовать при различных степенях детализации, вплоть до кода. Однако создавать модели потока транзакций на уровне 1бО Глава б ° Тестирование потоков транзакций исходного кода — отнюдь не самая лучшая идея. Узлы на графах потока транзакций могут представлять собой не только действия программного обеспечения. Термин чобработка данных» был использован в обшем смысле для обозначения любого вида работы с данными, вне зависимости от того, выполняется ли эта работа компьютером, людьми или другими системами.
Модель потока транзакций обычно используется как высокоуровневая модель. Наиболее часто ее используют в системном тестировании. Корректную работу компонентов следует проверить при компонентном тестировании, обычно это делают на предшествующей стадии интеграции. Разделение сложного действия на компоненты представляется в модели потока транзакций лишь выборочно. Но при этом следует учитывать некоторые детали.
Е Компоненты модели имеют интерфейсы, через которые происходит передача данных. Обратите внимание, что глобальные данные могут соответствовать этому требованию. 2, Компоненты могут взаимодействать только через свои интерфейсы. Если есть такие компонентьк сгруппируйте их и моделируйте группу как отдельный объект.
3. Поведение компонента определяется типом и состоянием транзакции. 4. Поведение узла обработки не зависит от предыстории транзакции, если только предыстория не влияет на тип и состояние транзакции. Отдельный процесс должен быть марковским. 5. Можно проверить корректность поведения узла обработки путем проверки выходяШих транзакций (или их контрольных записей) каждого процесса в модели.
6. При наличии соответствуюших средств тестирования можно полностью протестировать один компонент в отдельности. При тестировании потока транзакций первоочередное внимание следует обращать не на корректную работу отдельных процессов, а на систему в целом. Особенное внимание следует уделять корректности интерфейсов между компонентами, корректности маршрутизации транзакций между компонентами, организации и дисциплине очередей (если зто не правила упорядочения НРО), узлам слияния, поглошения, расщепления и порождения, синхронизации, одновременности, созданию и уничтожению транзакций, а также дублированию и потере транзакций. б.4. Методика 6.4.1.
Основы Предположим, что у нас нет циклических транзакций. Если же вы встретите такие, будем надеяться, что их применение в данном случае является обоснованным, н их можно протестировать в пределах субмодели, включающей цикл. Для 6.4. Методика 161 любых циклов, которые невозможно обработать на более низком уровне, нужно будет использовать методики тестирования циклов, описанные в главе 4. 1. Проверьте спецификацию. 2. Идентифицируйте и дайте имя всем транзакциям, которые должна обработать система.
У вас не должно возникнуть проблем с «нормальными» транзакциями, так как они все должны присутствовать в спецификации, Трудности обычно возникают с транзакциями, которые подразумеваются в спецификации, но не сделаны явными. Ниже приведены примеры транзакций, которые часто пропущены в спецификациях, но должны присутствовать в вашей модели. ° Подтверждения о приеме, уведомление, отрицательное квитирование. ° Специальные транзакции для установки и отладки. ° Специальные транзакции для диагностики действий.
° Транзакции, выполняющие аудит других транзакций. ° Транзакции, используемые в режиме обучения персонала. ° Транзакции инициализации или перенастройки для всех внешних интерфейсов. ° Транзакции, используемые при восстановлении системы. ° Транзакции, используемые для измерения характеристик системы. ° Транзакции, используемые для проверки обеспечения безопасности системы. ° Транзакции, используемые в протоколах, не упомянутых выше. ° Транзакции, используемые для запроса о статусе других транзакций.
° Ответы на запросы о статусе транзакций. ° Транзакции, создаваемые вашей системой для восстановления других транзакций. ° Транзакции восстановления, полученные из внешних систем, 3. Определите иерархию типов транзакций, которая включает все транзакции, описанные выше в пункте 2. Как правило, вы можете использовать ту же иерархию, что и разработчики.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
