Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 21
Текст из файла (страница 21)
Начните с простейших неравенств, где у вас есть наибольшая свобода выбора и выберите входные значения для них. Потом подставьте эти значения в другие неравенства и упростите. Используйте простейшую арифметику для исключения переменных, комбинируя выражения путем их сложения и вычитания. Если вы не можете обойтись простейшими подстановками и упрощениями, то, прежде чем потратить время и силы на инвертирование матриц, проверьте спецификации и свои предыдущие действия.
Как правило, причины, толкающие вас на инвертирование матриц, кроются в ваших предыдущих ошибках и/или в ошибках, содержащихся в спецификации. Другой способ решения данной проблемы — поместить ваши неравенства и выражения в электронную таблицу и использовать встроенные методы решения систем уравнений для получения ответа. Например, инструменты для решения уравнений в 1ОТПБ-123 справятся с этим превосходно. Более того, они позволяют смешивать логические и алгебраические предикаты в одном наборе неравенств. 3.4.
Методика Я9 М8 008. Теперь требуется перенести ее на другие платформы. Хотя подобная переделка программы может вести к полному ее переписыванию, старая программа является превосходным оракулом. Запустите на ней свои тесты для нахождения ожидаемых итогов. Предыдущие версии. Даже если код, который вы тестируете, был переписан, как правило, для большинства путей корректные итоги могут быть получены из предыдущих версий программы. В худшем случае могут быть внесены изменения в небольшое количество путей, однако разница в итогах тестов для старой и новой версий программы легко прогнозируется. Используйте итоги, полученные для предыдущей версии, как отправную точку для поиска итогов для соответствующих путей в новой версии.
Прототипы и модельные программы. Вы можете построить прототип, достаточно подробный для того, чтобы получить с его помощью корректные итоги 18ТАК89). Хорошие прототипы, как правило, не лишены функциональности. Причина, по которой они не могут служить рабочей программой, кроется в том, что они или слишком медленные, или слишком большие, или просто не могут работать в заданной операционной среде.
Если у вас нет летально проработанного прототипа, вы можете получить оракула, построив модельную программу. Например, если бы мне надо было написать программу для заполнения декларации о подоходном налоге, я бы начал с того, что запрограммировал все формы в электронных таблицах, а алгебру и логику — на каком-нибудь простом языке, например, ВА81С. Это не то же самое, что писать код для реального продукта, поскольку вы не забиваете себе голову вещами, о которых должен заботиться программист, такими, как доступ к структурам данных, взаимодействие с операционной системой, ввод и вывод. В большинстве стандартных программных продуктов предусмотрено много вещей, не имеющих непосредственного отношения к прикладной задаче. Я не располагаю точными цифрами, но полагаю, что менее 10 процентов программного кода имеют непосредственное отношение к прикладной задаче.
Более того, эти 1О процентов кода зачастую являются наиболее простыми. Таким образом, построение модельных программ и использование их в качестве оракула не лишено смысла. Выбор простых вариантов. Иногда существует возможность выбрать входные значения так, чтобы они, с одной стороны, активизировали нужный нам путь, а с другой — упрощали вычисления. Например, установить все входные значения, кроме нескольких, равными нулю.
В примере, приведенном выше, мы могли выполнить все условия при помощи подбора значений А19, АЕ18 и А1.13. Остальные входные величины мы могли положить равными нулю. Вы можете возразить, что ситуация, когда на входе может быть так много нулей маловероятна, но это плохой аргумент. В тестировании существует неписаное (и неудачное) правило, гласящее, что входные значения должны быть реалистичны. Реализм — это установка, мешак>щая хорошему тестированию. Реализм нужен для демонстраций, но он не является целью тестирования, Реалистичные тесты, хотя и кажутся убедительными, как правило, на поверку оказываются слабыми, поскольку именно нх программист с большой вероятностью выполнит сам.
90 Глава 3 « Тестирование потока управления Реализм не слишком хорош при поиске ошибок, а первоочередной задачей тестирования является как раз поиск ошибок, а совсем не создание иллюзии доступности для простого человека. Если вы включили в свой допустимый набор входных значений такие маловероятные значения, как ноль, вы можете обнаружить, что предсказание итогов, интерпретация предикатов и последующая активизация становятся проще. Поскольку нереалистичные тесты, как правило, отличаются от тестов, проводимых программистами, они с большей вероятностью могут выявить ошибки. Конечная программа.
Вы можете использовать конечную программу в качестве оракула, если вы в ней уверены. Обычно проще проверить правильность итога, чем вычислять его самому, подменяя собой компьютер. Это особенно касается случаев, когда вы можете вывести на печать и проверить промежуточные значения величин. Под словом «уверены» я подразумеваю, что вы проводите анализ, подтверждаюгций корректность итогов.
Если вы просто принимаете итоги как они есть, без проверки, вы, мягко говоря, ошибаетесь. 3.4.6. Проверка соответствия пути Вам необходимо проверять пути из-за угрозы возникновения случайной корректности. Однако проверка пути при проведении тестирования черного ящика — непростая задача, поскольку мы имеем дело с моделями поведения. Пути в тестировании — это пути через спецификации поведения, и нет никакой уверенности (и даже необходимости), что аналогичные пути существуют в реальном программном обеспечении. Единственный способ убедиться в соответствии поведенческих путей в потоке управления, заключается в проверке корректности всех промежуточных вычислений, и особенно тех, которые обусловлены предикатами потока управления.
Если подобная проверка невозможна из-за отсутствия доступных промежуточных результатов обработки, то единственный способ их получить заключается во внедрении в программу (совместно с программистами) соответствующих логических операторов для проверки тестовых условий (АХРК81, СНЕХ78В). У вас нет необходимости проверять все вычисления. Найдите определение узла в начале этой главы: «один или более шагов обработки...». В большинстве приведенных моделей я, стремясь к наглядности, добавлял узлы и связи. Например, в модели на предыдущем рисунке узлы 34,1, 34.6, 34.8, 34.9, 34.10, 34.11, 34.14, и 34.15 несущественны.
Граф на следующем рисунке содержит ту же самую информацию. Любая последовательность узлов, не являющихся объединяющими узлами или предикатами (узламн выбора), может быть заменена одним узлом с одной исходящей связью. Такая сжатая модель будет проще, и ваша проверка сведется к проверке одного значения для каждой связи на выбранном пути, идентифицирующем данную связь. К примеру, можно проделать множество вычислений на пути 34.7 — 34.11-34,12, но все, что нам надо, это убедиться, что по данной связи проходит одно единственное значение 3,175 — льготы женатого человека, заполняющего раздельную с женой налоговую декларацию.
3.5. Рассмотрение приложения 91 Детализированные льготы7 Бланк д Поы графу Поы графу Раздельные'- Давайте посмотрим теперь на проблему проверки соответствия пути в перспективе. Проверка необходима из-за угрозы возникновения случайной корректности. С другой стороны, поведенческое тестирование потока управления далеко не единственный метод, который вам придется использовать. Поэтому проверяйте в пути все, что можете проверить.
То есть если промежуточные элементы обработки легко доступны и у вас есть инструменты тестирования для проверки соответствия пути, программисты будут рады сотрудничеству с вами и помогут вам, используя эту зац[иту от ошибок. Другой приемлемый способ зашиты от случайной корректности — это тестирование нескольких вариантов для одного и того же пути.
Мы к этому придем, рассматривая в дальнейшем другие методы тестирования, и особенно тестирование доменов. 3.5. Рассмотрение приложения 3.5.1. Индикаторы приложений Поведенческое тестирование потока управления применимо практически к любой программе и эффективно для большинства приложений. Это фундаментальный метод. Его используют обычно для тестирования относительно небольших программ или сегментов больших программ. Как будет видно из примеров, приведенных ниже, он, скорее всего, будет эффективен для индивидуальных форм ВНС, но использовать его для тестирования всего пакета налоговых документов было бы затруднительно. Эти трудности объясняются тем, что модель получается слишком громоздкой, а, следовательно, выбор пути и активизация настолько сложны, что результат ие оправдывает затраченных усилий. 92 Глава 3 Тестирование потока управления 3.5.2.
Предположения об ошибках Причиной большинства ошибок в программе могут являться ошибки потока управления, и, следовательно, возникающее при этом аномальное поведение может быть обнаружено путем тестирования потока управления. Однако основное предположение об ошибках, па поиск которых направлено тестирование потока управления, — это влцяние ошибок на прслнкаты потока управления или то, что поток управления сам по себе неправилен. В качестве примера можно привести ошибку в вычислении элемента, который в дальнейшем будет использоваться как часть предиката потока управления, например, использование >= вместо <. Примером грубой ошибки в потоке управления является ошибочное соединение узла 34.4 с узлом 34.14 вместо 34.12.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
