Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 30
Текст из файла (страница 30)
Подобный критицизм заслуживает внимания, по из того, что структура программы размыта, не следует того, что плохо структурированное тестирование будет более эффективным. Не следует доверять поимку вора вору. Необходимо работать систематично. Как можно повысить эффективность использования скудного времени, отпущенного на проектирование тестов? Существует гораздо больше способов спроектировать программное обеспечение плохо, чем способов сделать это хорошо. Если вы решили придерживаться неструктурированного проектирования тестов в попытке найти некоторые ошибки, вы можете также ошибиться в предположениях о коде, как и прн хорошо структурированном проектировании.
Вы обманываете самих себя. Единственный способ сделать обоснованные допущения о коде, на которых можно основать проектирование тестов, — это посмотреть на код и построить дизайн ваших тестов в соответствии с его структурой. Но это уже нельзя назвать тестированием черного ящика. Приняв структурированную модель, вы увеличиваете вероятность того, что ваши позитивные тесты будут обеспечивать покрытие требований, Такой набор тестов более объективен и при создании негативных тестов. Например, разделяя тесты на уровне файла и полей записи, вы можете яснее увидеть, какая имеется возможность для грязных тестов, в которых эти уровни перемешаны.
Проектирование грязных тестов будет проще и потребует меньшего количества предположений об ошибках, так что работу будет проще оценить. 5.3. Отношения и модель 127 5.3.4. Упорядочение, совмещение потока управления и потока данных, циклы 5.3.4.1. Упорядочение Ссылки на материал, описанный в этом разделе, можно встретить в [ВПСС791 Данная книга рекомендуется для дополнительного ознакомления с рассматриваемыми концепциями. Граф потока данных содержит мало указаний о порядке обработки, продиктованном используемыми языками программирования и аппаратным обеспечением.
Но некоторое упорядочение все же остается, и информация о некотором упорядочении будет уместна. Вот четыре общих вида упорядочения, которые могут встретиться в графе потока данных: удобное, но пе необходимое, необходимое, синхронизация, нтерирование.
Не необходимое, но удобное. У нас есть последовательность операций, которые рассчитывают значения вместе с промежуточными значениями. Вам необходимо знатьае~озтео дгоаа 1псояе (скорректированный общий доход)(строка31),для того чтобы рассчитать величину вашего налога, аОЗозтед дгоаа 1псоае (скорректированный общий доход) зависит от переменной соса) 1псояе (общий доход) (строка 22), которая, в свою очередь, зависит от других полей.
В конечном счете зти поля зависят от входных данных. Может показаться, что подобное упорядочение необходимо, по это не так. Каждая строка в налоговой декларации может быть (теоретически) выражена прямо в виде комбинации входных данных. Так поступить допустимо, но глупо, потому что каждая строка в налоговой форме в этом случае была бы суммой множества вводимых полей. Такое упорядочение удобно, по не необходимо. Если вы уберете все подобное упорядочение из типичной диаграммы потока данных, вы получите только входные узлы и (очень сложные) выходные узлы, Когда вы видите граф потока данных, содержащий между узлами входа и выхода еще другие узлы, проверьте эти промежуточные узлы, чтобы определить, являются ли они необходимыми или просто удобны.
Можно ли упростить или систематизировать ваш граф, удалив некоторые из этих упорядочений и выразив выходы более явно через входные данные? Это диаметрально противоположно тому, что вы делали, когда изучали псевдопеременные и иерархические разбиения в разделе 5.3.3, Необходимое. Иногда упорядочение необходимо. Вы не можете прочитать файл, до того как он создан (несмотря на то, что это хороший тест) или закрыть неоткрытый файл.
Вы должны понять, как работает приложение, чтобы узнать, является ли упорядочение в графе потока данных необходимым или нет. Не удаляйте необходимое упорядочение, потому что если вы это сделаете, вы пропустите полезные тесты и создадите бесполезные. Синхронизация. Если имеются параллельные процессы (например, в системах с общими данными или сетевых приложениях), тогда существует необходимое упорядочение и проблема синхронизации. Например, с: = а е Ь, где а и Ь берутся из разных мест. Проблема синхронизации приводит к пяти дополнительным тестовым вариантам, зависящим от последовательности собы- 128 Глава З ° Тестирование потоков данных тий (почему?), и ее мы обсудим в главе 6.
Если в вашем случае таких проблем достаточно много, может оказаться, что модель потока данных не подходит для данного случая, и лучше рассмотреть модель потока управления или модель потока транзакций. Итерирование. Если у вас есть узлы выбора, вы можете вернуть результат вычисления назад, в более раннюю точку на графе потока данных и создать цикл. Процесс повторяется до тех пор, пока (как мы надеемся) не выполнится условие прекращения. Циклы и способы их обработки в контексте модели потока данных обсуждаются в разделе 5.ЗА.З. 5.3.4.2.
Совмещение потока управления и потока данных Модели потока управления и модели потока данных плохо сочетаются [КАЧ187~. Каждая модель — это обособленная часть общей картины, сосредоточенная на одних аспектах проблемы и игнорирующая другие. Модель — это способ структурировать наше мышление, необходимый для получения полезных тестов. Если модель чересчур сложна, это только запутает нас.
Но как мы должны обрабатывать необходимое упорядочение в рамках модели потока данных? Вот некоторые соображения. Более одной модели. Сделайте отдельно модель потока данных и модель потока управления. Каждая приведет к различным тестам, и? как мы надеемся, при таком подходе не будет значительного перекрытия созданных тестов.
Возможно, вы предпочтете в качестве альтернативы модель с конечным числом состояний (глава 9). Поместите модель потока управления внутрь модели потока данных. У вас есть повторяющаяся процедура в модели, большей частью определяемой потоками данных. Например, вы должны найти файл, чтобы получить данные, которые затем используются в вычислении. Рассматривайте поиск файла как единичную операцию внутри модели потока данных.
Для поиска файла используйте модель потока управления. Поместите модель потока данных внутрь модели потока управления. Скажем, вы проделываете повторяющуюся обработку для каждой записи файла. Обработка моделируется при помощи графа потока данных. Расположите часть, представляемую потоками данных, внутри модели файла (либо модели потока управления или модели потока транзакций).
Рассматривайте файловую часть как модель потока управления, а обработку как модель потока данных. Когда вы проектируете тестовый вариант, никто не знает, как вы это делаете. Тестовый вариант состоит из исходных условий, вводимых данных, ожидаемых результатов. И история умалчивает (или должна умалчивать) о том, получили ли вы эти результаты, используя модель потока управления, модель потока данных или каким-то другим способом. 5.3.4.3.
Циклы Как бы вы ни моделировали проблему и какие бы ни были в ней циклы (необходимые или нет), вам следует использовать методы тестирования циклов из главы 4. К счастью, в потоковых моделях нам нечасто приходится иметь дело с циклами. Мы должны различать необходимые и несущественные циклы. 5.3. Отношения и модель 129 Причиной возникновения несущественных циклов является природа языков прог(таммирования. Если вы хотите добавить два массива, в болыцинстве компьютеров или языков вы, вероятно, проделаете это с помощью цикла. Цикл не необходим, потому что на параллельном компьютере вы могли бы проделать эту операцию параллельно. Большинство циклов, встречаемых нами в программном обеспечении, несущественны.
Большинство детерминированных циклов не являются необходимыми. Необходимые циклы реализуют итерационные или потенциально бесконечные процедуры. Решение уравнения с помощью итерационного процесса, такого как итерация Ньютона — Рафсона, — хороший пример. Поиск и сортировка файлов с неограниченной длиной — другие два примера. Большинство недетерминированных циклов являются необходимыми'. Если у вас есть какие-нибудь необходимые (или удобные) не очень сложные циклы (то есть не вложенные, без переходов в них или из них, без большого количества управляюШей логики в них), тогда простой и эффективный путь рассмотреть проблему цикла в рамках модели потока данных — это развернуть цикл. Рассмотрилг модель, приведенную на рисунке, пренебрегая пока что различиями между графами потока управления и графами потока данных. Итерационный процесс здесь зависит от входных переменных А, В и С.
В ходе этого процесса происходит вычисление функции Х и счетчика цикла 1. Рассчитав первый результат (Х,), программа переходит к узлу ЦИКЛ, где принимается решение о том, следует ли выйти или же продолжить. Управляющий предикат может быть функцией как Х, так и 1, либо обоих параметров. Нам необходимо знать исходное значение дтя Х, потому что выполняемое в узле Х вычисление зависит от предыдущего значения Х. Я назвал исходное ' МЫ все знаем, что подготовка наших налоговых Леклараций — повториююаяся процспура, которая производит нпечатлеиие бесконечной (до!5 апреля). Зная особенности бюрокрагического мышления, я очень надеялся найти много необхолимых циклов в цалогоных законах. Я прослютрел все формы н инструкции (это порядка 950 страниц терминологии ВНС) в моем налоговом пакете.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
