Тестирование программного обеспечения

7.5. Заглушки

Часто возникает необходимость тестировать модули, использующие процедуры других модулей, которые могут влиять на результат тестирования или значительно усложнять его получение. Допустим, имеется функция climatControl, обрабатывающая информацию с датчика температуры и управляющая нагревателем. Значение температуры она получает при помощи функции getTemperature, которая в свою очередь опрашивает температурный датчик. Пусть имеется следующее требование: "Если температура становится ниже 23 °C, то функция climatControl должна включить нагреватель". Для тестирования этого требования необходимо передать функции некое значение температуры, меньшее 23, допустим 20. Но эта величина не является входным значением функции climatControl, она задается возвращаемым значением функции getTemperature. Один из путей - "заставить" функцию getTemperature возвратить нужное значение, например подключив реальный датчик температуры и охладив его до 20°С. Но при этом нет гарантии, что датчик и сама функция getTemperature работает правильно. А что если она возвращает значение температуры в фаренгейтах (20°С равно 68°F, т.е. функция вернет 68 вместо ожидаемых 20)? Это приведет к тому, что функция climatControl не включит нагреватель, даже если не содержит в себе ошибок.

В таких ситуациях реальная функция getTemperature заменяется новой функцией, которая разрабатывается специально для конкретного (конкретных) тестового примера, и выполняет только то, что необходимо для теста, возвращая нужное значение. Т.е. в данном примере функция getTemperature заменяется на функцию, которая не будет опрашивать датчик, а сразу вернет значение 20. Функции или программы, которыми заменяются используемые при тестировании SUT функции и программы, называют заглушками.

Стоит отметить, что если SUT использует какие-либо функции, которые не заменяются заглушками в ходе тестирования, то такие функции также должны быть предварительно протестированы. Это приводит к так называемому "восходящему" тестированию. Что, в свою очередь, предполагает такую же последовательность реализации модулей системы. Чаще как раз подобные getTemperature процедуры реализуются в последний момент, так как зависят от периферийного оборудования, которое не изготавливается, а закупается или характеристики которого специально подгоняются под условия эксплуатации системы. В этих случаях написание моделей (заглушек) программ неизбежно.

7.6. Процесс тестирования

Как уже говорилось, тест состоит из набора тестовых примеров. Перед написанием теста необходимо подготовить сценарий каждого тестового примера. Такие сценарии описываются в тест-плане. Тест-план представляет собой документ, последовательно определяющий всю совокупность тест-примеров с указанием конкретных значений всех входных данных, действий, а также ожидаемых значений выход-ных данных (см. выше про то, что включает в себя тестовый пример).

В тест-плане отражается основная логика тестирования, а сам тест (набор тестовых примеров) является реализацией тест-плана. Вполне возможно построить универсальный тест-драйвер, который будет использовать в качестве входных данных тест-план, создавать на его основе все необходимые условия для каждого тестового примера и выполнять заданные сценарии, сравнивая реальные выходные значения с ожидаемыми. Этот подход часто применяется для автоматизации процесса тестирования.

Если в тест-плане для каждого тестового примера указываются ссылки на тестируемые им требования, то можно говорить о трассировке или о соответствии тестового примера тест-плана требованию. Аналогично при кодировании теста для каждого тест-примера удобно указывать ссылку на номер его описания в тест-плане.

Такая трассировка позволит при выявлении ошибки каким-либо тестовым примером определить, перейдя к тест-плану, при каких условиях проявилась ошибка, и далее, перейдя к требованиям, выяснить, какие требования нарушены. Так как в ходе разработки документация может меняться, то при трассировке необходимо сохранять соответствие версий трассируемых документов. Это, в свою очередь, позво-ляет определять область влияния внесенных изменений, например определить, какие тесты должны быть модифицированы или перепроверены при изменении части требований к системе.

Результатом выполнения теста является отчет о прогоне теста, в котором отражается, сколько всего было выполнено тестовых примеров, сколько ошибок найдено, какие тестовые примеры выявили ошибки. Удобно помещать в отчет о прогоне теста ожидаемые и ре-альные значения всех выходных данных после выполнения каждого тестового примера, чтобы в случае выявления ошибки можно было их сравнить.

7.7. пример верификации (продолжение примера разделов 2 и 6)

Третий этап работы

6. Тестирование программной реализации

Соображения

Общие требования к тест-плану состоят в определении входных воздействий на программу достаточных для контроля всех требований по проверке функций программной реализации как "черного ящика" (полнота покрытия требований). Дополнительно желательно определить входные воздействия, обеспечивающие выполнение всех ветвей программной реализации (программа проверяется как "белый ящик"). Часто удобно представлять тест-план в виде таблицы.

Выводы

Далее приведен неполный пример тест-плана (табл. 7.2).

Замечание

Приведенный выше тест-план не проверяет (явно) вывод предупреждающего сообщения о вводе новой строки. Такое требование не было явно определено в разделе 4. Это недоработка требований по проверке функций программной реализации. Хороший тестировщик должен сам включить подобную проверку в свой тест-план. Дополнительные пункты плана явно зависят от конкретного программного кода и поэтому не приведены в данном примере.

Вопросы и задачи для самостоятельного решения

• Определите понятие покрытия тестами исходного текста модуля.
• В чем разница тестирования требований спецификации на программный модуль и тестирования исходных текстов программного модуля?
• Может ли быть несколько тестовых примеров для проверки одного тест-требования? А один тест-пример для проверки нескольких тест-требований?
• Напишите тест-план на функцию вычисления периметра треугольника.

• Напишите тест-план на функцию вычисления максимума трех чисел для покрытия следующего кода

  1. по операторам;
  2. по условиям:

     int max3(int a, int b, int c)
     {
       int max;
       max = a;
       if (b > max) { max=b; };
       if (c > max) { max=c; };
       return max;
     }      
               
• Напишите тест-план на функцию int Compare(int A, B), если в функциональных требованиях сказано, что функция должна сравнивать на равенство числа в пределах от - 76 до +77 и возвращать 0 при совпадении значений параметров.