Цель тестирования модуля или программной компоненты _ найти несоответствия между логикой и сопряжениями модуля, с одной стороны, и его внешними спецификациями (описанием функций, входных и выходных данных и внешних эффектов), с другой стороны. Компиляция модуля также должна рассматриваться как часть процесса тестирования, поскольку компилятор обнаруживает большинство синтаксических ошибок, а также некоторые семантические и логические ошибки.
Проектирование теста
Для иллюстрации сложности задачи проектирования тестов рассмотрим следующую задачу.
Есть небольшая программа, которая читает три целых числа, представляющих собой длины сторон треугольника. Программа исследует входные данные и печатает сообщение о том, является ли треугольник разносторонним, равнобедренным или равносторонним. Напишите тесты для полной проверки программы.
Следующий шаг при анализе тестов _ представить себе возможные ошибки в программе.
Гипотетические ошибки можно получить, убирая одну из проверок или каким-либо образом, изменяя ее. Типичные ошибки при составлении тестов - отсутствие проверки случая разностороннего треугольника. (При проверке случая равнобедренного треугольника, рассматривается случай 2–2–3, но упускаются случаи 2–3–2 и 0–2–2).
Заметьте, что сначала программа должна проверить, описывают ли входные данные вообще какой-нибудь треугольник, потому что, если бы она печатала “разносторонний” в ответ на входные числа 2–3–6, она допускала бы ошибку (отрезки с длинами 2–3–6 не образуют треугольника).
В качестве упражнения в проектировании тестов попробуйте написать тесты для подпрограммы, которая вычисляет корни квадратного уравнения.
Получая на входе значения A;Bи C, она находит два значения X, удовлетворяющие уравнению Ax2 + Bx + C = 0:
Сказанное призвано проиллюстрировать трудность высококачественного проектирования тестов. Должно стать ясным, что разработка тестов - творческий процесс, требующий не только особого искусства, но и в некотором смысле разрушительного склада ума. Имеется, однако, несколько простых правил, которыми можно пользоваться, чтобы составить разумный набор тестов. Они рекомендуют сначала рассмотреть модуль как черный ящик (левая граница спектра стратегий), а затем исследовать его внутреннее устройство для подготовки дополнительных тестов. Весь процесс состоит из следующих четырех шагов:
1. Руководствуясь внешними спецификациями модуля, подготовьте тест для каждой ситуации и каждой возможности, для каждой границы областей допустимых значений всех входных данных, областей изменения данных, для всех недопустимых условий.
2. Проверьте текст программы, чтобы убедиться, что все условные переходы будут выполнены в каждом направлении. Если необходимо, добавьте соответствующие тесты.
3. Убедитесь по тексту программы, что тесты охватывают достаточно много возможных путей. Например, для каждого цикла должен быть тест, соответствующий пути без выполнения тела цикла, с однократным его выполнением и максимальным числом повторений.
4. Проверьте по тексту программы ее чувствительность к отдельным особым значениям входных данных и, если необходимо, добавьте соответствующие тесты.
Первый шаг проектирования тестов предполагает подход к модулю как черному ящику и получение тестов за счет манипуляций с входными данными модуля. Именно на этом шаге в основном и требуются творческие способности (остальные три шага, в отличие от первого, довольно методичны). Если число различных входных значений модуля невелико (например, один из пяти запросов), приготовьте тест для каждого из них. Если входных параметров несколько и каждый имеет немного допустимых значений, приготовьте тесты для всех комбинаций.
Минимальный критерий при автономном тестировании модуля, по крайней мере, один раз выполнить все разветвления в каждом из возможных направлений.
Поскольку нас интересует лишь последовательность выполнения ветвей программы, подробная блок-схема не обязательна. Проще для этой цели использовать диаграмму управления: ориентированный граф, изображающий структуру ветвлений в программе. Каждая вершина графа (кружок) представляет линейный участок (последовательность операторов между точками ветвления, или принятия решения, на которую можно попасть только через первый из них). Дуги графа представляют связи между выполнением отдельных линейных участков программы.
Выполнение теста
После того как тесты для модуля спроектированы, можно перейти к следующим этапам _ написать их, тестировать и выполнить. Форма представления тестов зависит от принятого метода сборки модулей. Для нисходящих методов тесты сначала пишутся в виде конкретных наборов выходных данных, вырабатываемых заглушками, а затем уже в виде внешних входных данных, задаваемых пользователем. Для восходящих методов или при автономном тестировании модулей тесты приобретают вид ведущих программ (драйверов) или операторов языка тестирования (если используются специальные инструменты тестирования модулей). В следующем разделе мы рассмотрим некоторые из таких инструментов. А пока будем предполагать, что они не используются.
Процесс написания тестов (в отличие от их проектирования) носит в основном рутинный характер и представлен здесь, поэтому лишь вкратце. Например, если нужен драйвер, пишется небольшая программа, вызывающая тестируемый модуль. Каждый тест представляется вызовом этого модуля и передачей ему конкретного набора входных данных. Чтобы облегчить повторное выполнение теста в будущем и избежать проблем типа “глаз видит то, что хочет видеть”, следует попытаться сделать тесты самопроверяемыми. Вместо того чтобы печатать выходные данные для каждого теста, следует, где это возможно, включать непосредственно в драйвер сверку полученных и ожидаемых результатов.
В идеальном случае тесты сами должны быть проверены перед их использованием для тестирования реальной программы. Обычно это неосуществимо; единственная возможность проверить правильность теста (кроме просмотра человеком) _ действительно выполнить его. Однако при тестировании следует иметь в виду, что сами тесты могут содержать ошибки.
Критический момент в выполнении тестов _ анализ результатов, будь то с помощью программы либо визуально. Распространенная нелепость потратить часы на проектирование изощренных тестов и затем не заметить ошибку только потому, что результаты теста удостоены лишь беглого взгляда. Чрезвычайно важно тщательно изучить результаты каждого теста, выискивая малейшие тревожные признаки. Здесь-то уж жизненно важно определить, какие результаты вы ожидаете, прежде чем изучать реальные выходные данные.
Тесты для квадратного уравнения
Ниже перечисляются тесты для квадратного уравнения.
1. A=0, B=0, C=0. В этом случае уравнение сводится к виду 0=0 и не может быть разрешено относительно X. Пробовали ли вы этот тест для проверки поведения модуля при таких входных данных?
2. A=0, B=0, C=10. Это соответствует уравнению 10=0, которое не имеет решений. Интересный тест на ошибочные входные условия.
3. A=0, В=5, C=17. Соответствующее уравнение 5X + 17 = 0 не является квадратным. Справится ли с ним модуль? Этот тест может обнаружить также попытку деления на нуль.
4. А =6, B=1, С=2. Это один из нескольких “нормальных” тестов, которые вам следует выполнить. Не забыли ли вы заранее вычислить результат для каждого теста?
5. A=3, B=7, С=0. Еще один “нормальный” тест. Проверяется ситуация, когда один из корней равен нулю.
6. A=3, B=-2, C=5. Помните ли вы, что квадратное уравнение может иметь комплексные корни?
7. A=7, B=0, C=0. Этот тест проверяет, умеет ли модуль извлекать квадратный корень из нуля.
8. Полезны также тесты, проверяющие границы диапазонов арифметических значений и точность модуля.
