Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 42
Текст из файла (страница 42)
Ошибки, отрицательное квитирование н восстанавливающие транзакции из других систем. Это было моим прош<ятием. Вы не можете получить эти транзакции, не заставив другую систему вести себя неправильно. Вам необходима транзакция нз другой системы, информирующая вас, что один из ваших блоков данных был утерян или искажен. Однако вы не можете послать ей блок данных или искаженный блок, поскольку такие оцп<бк«могут быть об- 172 Глава б ° Тестирование потоков транзакций наружены промежуточными системами.
Вам придется заставить другую систему послать вам сообщение об ошибке, хотя на самом деле ошибки не было, Вы пытаетесь наладить сотрудничество, но в ответ вам с пафосом заявляют: «Наша система никогда не посылает сообщения об ошибках!а Вы пытаетесь как-то решить эту проблему, а заканчивается все тем, что вы объясняете разгневанному чиновнику в полосатом костюме из государственного департамента в Вашингтоне, что не собирались раздуть международный скандал'. На этот случай я не знаю приемлемого технического решения, поскольку это не техническая проблема.
В крайнем случае вам придется построить имитаторы всех таких недружественных интерфейсов и протестировать все случаи, используя эти имитаторы. А потом остается только надеяться на лучшее. 2. Внутренние транзакции, связанные с восстановлением системы и нелогичными условиями. Система должна иметь защиту от аварий, таких как отказы программного или аппаратного обеспечения. Вы не сможете протестировать защитные ме.
анизмы, не создав в точности такую же ситуацию, против которой система должна себя защищать. Следует точно узнать, принимаются ли необходимые меры по защите. Вы должны сломать доктрину безопасности. Проверить, предусмотрено ли в вашем случае аварийное восстановление состояния системы и данных. Вы должны имитировать все механизмы аварий и порожлаемые ими транзакции. 3. Внутренние транзакции для восстановления данных и нелогичных условий. Если система обнаруживает потерянные или дублированные транзакции, то и тестировшик должен иметь возможность терять или дублировать транзакции.
Любой механизм восстановления данных рассчитан на определенный сценарий их потери или искажения. Вы должны воспроизвести каждый такой сценарий для соответствующих транзакций. На практике задача активизации заключается в том, чтобы правильно генерировать и внедрить необходимые вам для проверки системы транзакции. Единственный разумный способ зто сделать — это встроить в систему генератор транзакций на ранней стадии проектирования. Минимум действий, которые должен уметь выполнять встроенный генератор транзакций, выглядит следующим образом. 1.
Создание любых заданных транзакций, как корректных, так и некорректных. 2. Размещение эти транзакций в любом месте заданной очереди. 3. Удаление выбранных транзакций из очереди. 6.4.8. Предсказание итогов Нашей задачей прн проведении тестирования не является детальная проверка данных в транзакциях. Цель системного тестирования (в контексте модели потока транзакций) заключается в проверке корректного прохождения транзакций, в том числе их порождения, завершения и так далее. Ожидаемым итогом в этом случае Это реальный факт на коей нрактнкн. бЯ. Методика 173 является определение того, какие транзакции в каких очередях должны находиться до и после тестирования — предсказание конечного состояния транзакции при заданном начальном состоянии. На практике, однако, перед тестировшиком стоит задача не предсказать итог, а проверить его. Вы должны сравнить все включенные в процесс очереди до и после проведения теста.
По меньшей мере вам необходимо иметь возможность, проведя тестирование, заморозить систему, или, как альтернативный вариант, уметь делать моментальную запись всех интересующих вас очередей. Здесь подразумевается использование инструментов тестирования, и лучц1е всего, если они будут встроены в проект. 6.4.9. Проверка соответствия пути На самом деле если существуют слияния или порождения, то это будет проверкой соответствия порожденного подграфа.
Проблема заключается не в том, чтобы убедиться в правильности пути, а в том, чтобы найти способ встроить в систему инструменты, которые это будут делать. Существует два основных источника необходимых данных, и в обоих случаях вам, возможно, придется создавать достаточно продуманную программу, поскольку вероятность того, что в универсальных инструментах предусмотрены все возможности ваших транзакций, весьма мала. 1. Существующие записи. Системы обработки транзакций обычно включают в себя запись активности транзакций, которая требуется в различных приложениях. Например, информацию о счетах, журнал безопасности, резервные и архивные данные.
Эти данные записываются в узлах, которые чаще всего и являются целью тестировщика. Например, в системах восстановления данных обычной практикой является запись состава всех активных очередей. Прежде чем вы потребуете расширить возможности регистрации данных в системе, исследуйте все журналы регистрации и записи, необходимые в приложении, и подумайте, могут ли эти данные помочь вам проверить исследуемый путь. 2. Встроенная регистрация. Обсуждаемое в предыдущем пункте дополнение данных, предоставляемых приложением, необходимо для устранения белых пятен.
Постарайтесь ограничиться минимальными добавлениями, чтобы дополнительная регистрация данных не влияла существенно на поведение системы. Как правило, это вполне реально осушествить, и часто объем ресурсов, достаточный лля проведения самой полной регистрации транзакций не превышает нескольких процентов от общего объема доступных ресурсов.
Как правило, такие возможности регистрации должны встраиваться сразу, поскольку сделать это задним числом будет очень сложно. 3. Действия в режиме трассировки. Это наиболее приятный способ регистрации. Транзакции вполне могут запускаться в режиме трассировки. Это означает, что производится постоянная запись всех процессов, в которых участвовали эти транзакции, и всех очередей, в которых они стояли. Разумеется, такая возможность тоже должна быть встроена в систему. В~е зависимости 174 Глава б ° Тестирование потоков транзакций от того, насколько важен режим трассировки для тестировщика, он вполне оправданно считается отличным инструментом для отладки системы.
6.5. Рассмотрение приложений 6.5.1. Индикаторы приложений Насколько хорошо вы сможете описать поведение системы при таком моделировании? Критериями применимости данного метода могут служить положительные ответы на приведенные ниже вопросы. 1. Выполняется ли работа дискретными единицами? 2. Распределяются ли единицы работы между обрабатывающими модулями при помощи очередей или подобных интерфейсов? 3. Существуют ли в вашем случае множественные серверы? 4.
Выполняются ли ваши процессы квазипараллельно? 5. Существует ли между процессами связь в виде сообщений? 6.5.2. Предположения об ошибках Основное предположение должно быть следующим — каждый отдельный процесс работает корректно (был проверен со всех сторон на более ранней стадии интеграции), а ошибки, которые мы ищем, возникают вследствие некорректной реализации связи между компонентами или как побочный эффект многозадачности.
Типичный список предположений об ошибках включает в себя несколько стандартных пунктов. 1. Некорректные очереди. Пропуск очередей, лишние очереди, неправильные типы очередей. 2. Некорректные порождения или расщепления. Система использует порождения транзакций неправильного типа, неверный порождающий элемент, создание копий. 3. Некорректные слияния или поглощения. Неправильные слияния или поглощения, потери. 4. Ошибки маршрутизации очереди. Соединение выходов с неверными входными очередями. 5. Ошибки в правилах упорядочения.
Действует неверное правило упорядочения. 6.5.3. Ограничения и предостережения Мы предполагаем, что наш проект обладает правильным дизайном. Он имеет иерархическую структуру, в нем существует ясное разделение между обработкой 6.6. Рассмотрение приложений 175 данных и управлением очередями, транзакции однозначно делятся на типы, осуществляется явная запись управления транзакциями, и маршрутизация транзакций производится централизованно.
Чем лучше проект, тем легче будет обеспечить полное покрытие при помощи тестирования потоков транзакций. Это означает, что тестировщик сможет сделать обоснованные предсказания (проведя соответствующие тесты) о приголности программы к использованию.
Предположим теперь, что у вас плохой проект. Значит ли зто, что тестирование потоков транзакций будет бесполезно? Нет, оно все равно будет очень полезно. Обсуждаемые здесь тесты легко сломают программу, основанную на плохом проектировании, Елинственное, что вы не сможете слелать лля плохого проекта, — это статистически оправданно предсказать его пригодность к использованию. Единственное важное ограничение лля этой модели — это требование марковского повеления от каждого узла. В случае немарковского поведения у вас не будет другого выбора, кроме как тестировать каждый возможный путь лля каждой возможной транзакции, поскольку поведение будет зависеть не только от пан ных, солсржащихся в транзакции, но и от предыстории ее поведения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
