Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 43
Текст из файла (страница 43)
Такое тестирование редко осуществимо на практике. Сколько-нибуль разумное понятие покрытия бесполезно прн отсутствии марковского поведения. Если у вас случай именно такого поведения и вы выполните предложенные здесь песты, то ничего не побьетесь, кроме ошибочной уверенности. Немарковское повеление может быть сколь уголно сложным, поэтому любое выполняемое вами покрытие охватит лишь небольшую часть возможных вариантов.
Что вам следует лелать при встрече с не- марковским поведением? 1. Избавиться от него путем перепроектирования. В любом случае это лучший выбор. В большинстве случаев можно обойтись без немарковского повеления. Оно возникает, когда люди нелостаточно хорошо разобрались в вопросе. 2. Изолировать его. Вам, возможно, придется это слелать, если ваша модель описывает поведение человека или поведение других, не контролируемых вамп систем.
Процедура изоляции может заключаться в наложении ограничений на действия (изменение спецификации) илн выделении подобного поведения в отдельную субмодель, которую вам придется проверить очень тщательно, прежде чем вы перейдете к тестированию системы более высокого уровня. 3. Смириться с риском. Иногда это допустимо. То, что приемлемо в развлекательных программах, не может быть приемлемо в жизненно важном программном обеспечении. б.5Я.
Автоматизация и инструментальные средства рассмотрим отдельно автоматизацию выполнения тестов и автоматизацию их проектирования. 1. Автоматизация выполнения тестов. Необходимость автоматизации выполнения частично была рассмотрена выше в разделах 6А.7-6А.9. Что ка- 176 Глава б ° тестирование потоков транзакций сается коммерчески доступных инструментов тестирования, то системы покрытия/воспроизведения и языки подготовки сценариев являются наиболее подходящими инструментами для автоматизации выполнения тестов. Однако в большинстве систем разработки, о которых стоило бы говорить, наличие встроенных средств тестирования — обязательное условие.
2. Автоматизация разработки тестов. Системы автоматизации могут варьироваться от тривиальных до сложнейших. Языки и системы, предназначенные для создания генераторов тестов, широко распространены (как коммерческис, так и частные). Имеет смысл потратить пять лет работы, чтобы создать специализированный генератор автоматического тестирования транзакций для проекта, разработка которого потребует 100 лет общих трудозатрат. Хотя здесь редко встречаются непреодолимые технические трудности, я допускаю, что может быть достаточно трудно убедить нужных людей, что инструменты тестирования подобного рода стоят потраченных на них времени и сил.
6.6. Резюме Модель потока транзакций является эффективной моделью, применяемой в высокоуровневом системном тестировании большого количества систем. Моделирование начинается с идентификации интересующих нас транзакций, особенно мест, где они порождак>тся н завершаются и обстоятельств, при которых это происходит. Модель основана на допущении о марковском процессе'. В ней так же предполагается, что подробные модели обработки были созданы и использовались на более низком уровне компонентного тестирования, на стадии, предшествующей интеграции. Основное внимание при тестировании потоков транзакций уделяется очередям, и маршрутам транзакций в системе.
Мы рассмотрели эвристическую иерархию покрытия, основанную на порожденном подграфе. 6.7. Вопросы для самопроверки 1. Дайте определение (в контексте тестирования потоков транзакций) следующих терминов: узел поглощения, обслуживание пакета, покргцтие порождениятгзавершения, стартовый узел, ограниченная очередь, узел ветвления, предикат ветвления, управляющая входящая связь, дочерняя транзакция, узел завершения, ГСГВ, Г1ГО, узел соединения, 1СГВ, 11ГО, покрытие связей, маркировка, марковский узел, марковский потоковый граф, узел слияния, материнская транзакция, множественный сервер, очередь, покрытие узлов, покрытие зарождения/выхода, узел зарождения, родительская ' Иными словами полагают, что поток транзакций является л~арковским процессом (процессом без послелействия), в которол~ булугисе повеление транзакции зависит только от текугиего состояния и ис зависит от прслыстории ироцссса.
— При иею иакяи. ред. 6.7. Вопросы для самопроверки 177 транзакция, транзакция — хищник, транзакция — жертва, очередь по приоритету, тестирование приоритетов, правило упорядочения, тестирование правила упорялоченця, тесты очереди, случайное обслуживание, правило выбора сервера, односерверная очередь, порожденный подграф, тестирование сортировки, узел расщепления, тесты синхронизации, залача, действия в режиме трассировки, транзакция, узел ветвления транзакции, предикат ветвления транзакции, управляющая запись транзакции, узел соединения транзакций, регистрация транзакций, тестирование выбора транзакции, состояние транзакции, маркер транзакции, тип транзакции.
ми на транспортные средства. Считайте, что число транспортных средств ограничено п. Вводя соответствующие данные для кажлого транспортного средства (От1, Фр!, Ак!, с1! з) имейте в виду, что вы можете вволить фактические расходы и амортизацию, только если вы являетесь владельцем транспортного срелства; однако вы не обязаны лекларировать фактические расходы. Если же вы это делаете, то не обязаны декларировать амортизацию.
Считайте, что вы нашли способ получить максимальные льготы (выбрав между стандартными и фактическими льготами). Введите в эту субмодель данные для всех транспортных средств и получите одно число общих льгот на транспортные средства (тсуи). Разработайте модель, выберите пути, активизируйте их, определите, что вы хотите проверить, исследуйте синхронизацию для слияния транзакций, и так далее.
Проводите только чистые тесты. Разработайте грязные тесты для задачи 2. Рассмотрите потерю, дублирование, искажение Ланных о транспортном средстве. Учтите, что вы не можете декларировать фактические расходы для олного транспортного средства, а амортизацию лля другого. Все данные о транспортном средстве (Ог1, Фр1, Ак1) должны являться частью соответствующего набора для данного транспортного срелства. Для проверки слияния двух транзакций необходимо пять контрольных тестов, в случае трех транзакций таких тестов должно быть уже 25. Сколько тестовых вариантов потребует проверка слияния четырех транзакций? А сколько потребует слияние и транзакций? Разработайте модель потока транзакций для формы 1040; (а) строки 7-22, (б) строки 23-30, (в) строки 32-40, (г) строки 41-45, (л) строки 47-53, (е) строки 45 — 60. В кажном случае считайте, что все входные значения вводятся в виде единой транзакции, возможно, из предылущего блока строк.
Молелируйте эти вычисления как елиный элемент обработки, который не надо тестировать. Рассматривайте каждую встречающуюся форму или бланк как транзакции, которые могут порождаться и/или поглощаться как положено. Включите в модель логику лля определения того, нужны или не нужны в ней ланныс формы. Например, в строке 14 в случае существования «дополнительных дохолов» будет создана форма 4797, которая потом будет возвращена заполненной соответствующим образом и поглощена формой 3. 4. 2. Разработайте подробную модель части формы 2106, связанной с расхода 178 Глава б ° Тестирование потоков транзакций 1040, то же самое будет с Ю2, бланком В, бланком С, формой 3903 и так далее. Не пытайтесь моделировать эти формы.
Создавайте пустые формы, как того требует логика, отправляйте их на соответствующий узел обработки форм, затем принимайте данные формы обратно в соответствующие строки формы 1040. Разработайте следующие типы тестов: покрытие узлов, покрытие связей, покрытие порождения/завершения. 6. Выполните задачу 5 в предположении, что вспомогательные формы могут быть сначала открыты, а затем оставлены незаполненными, поскольку оказалось, что в них нет необходимости. 7.
Выполните еще раз задачу 5 в предположении, что различные строки могут заполняться в произвольном порядке при условии, что сушествуют требуемые данные (то есть вы не можете добавлять числа, пока они не введены). Разработайте необходимые тесты синхронизации, считая, что входяшие формы поступают по очереди, но в произвольном порядке. Тестирование доменов 7.1. Обзор Тестирование доменов используется для проверки такого программного обеспечения или его частей, в которых преобладают численные вычисления.