Библиотека программиста

Все, что необходимо начинающему и опытному программисту

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

Тестирование программ является одним из самых длительных и ответственных этапов разработки. Особое значение придается ему в парадигмах структурного и надежного программирования. При тестировании самыми важными являются два вопроса: в каком порядке тестировать модули и как готовить и задавать тестовые данные.

Способы задания тестовых исходных данных

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

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

Отметим несколько различных способов задания исходных данных, использованных при создании демонстрационных программ, которые рекомендуется применять при тестировании пользовательских программ:

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

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

Правила тестирования программ

Требования к тестированию программ сформулированы в известной книге Г. Майерса в виде аксиом тестирования. Приведем здесь основные из этих аксиом и дадим рекомендации по их учету. Особое внимание обратим на такие аспекты тестирования, которые проявляются при тестировании небольших учебных программ.

Аксиома 1.
Считайте тестирование ключевой задачей вашей разработки.

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

Кроме того, как правило, в процессе тестирования учебных программ выясняется необходимость выполнения ряда доработок программы, связанных с оценкой

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

Вывод, который должен сделать для себя разработчик программы на основе этой аксиомы, состоит в том, что при планировании разработки программы нужно отводить больше времени и внимания данному этапу и очень ответственно выполнять его.

Аксиома 2.
Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей.

Цели тестирования для учебных программ весьма скромны — показать, что программа при ее исполнении ведет себя правильно, в соответствии с решаемой задачей, т.е. выдает правильные результаты для допустимых исходных данных и сообщает о невозможности их обработки (желательно на ранней стадии обработки) для неверных данных или их недопустимой комбинации. Осознание этих целей должно побудить разработчика (или тестовика) спланировать достаточно полный пакет тестов, а также сроки разработки с учетом сложности тестирования программы.

Аксиома 3.
Необходимая часть всякого теста - описание ожидаемых выходных данных.

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

Аксиома 4.
Подготовка тестов как для правильных, так и для неправильных входных данных.

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

Аксиома 5.
Проектирование тестов требует даже большего творчества, чем разработка программ.

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

Это, в частности, означает, что в пакете тестов должны быть тесты, задающие как допустимые, так и недопустимые программой значения исходных данных, находящиеся:

- внутри допустимого интервала (множества),
- на каждой из границ интервала,
- вне допустимого интервала.

Кроме того, должны быть рассмотрены все "вырожденные" случаи задания исходных данных:

- пустые строки, множества и файлы,
- последовательности (представляемые массивами) нулевой длины и длины, превышающей допустимую программой (по каждому из измерений массива).

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

Важно также включать в тесты такие максимальные значения исходных данных, которые контролируются программой и указываются в формулировке задачи.

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

Аксиома 6.
Нужно избегать невоспроизводимых тестов, не тестировать "с лету ".

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

Аксиома 7.
В пакете тестов не должно быть случайных или несущественных тестов.

Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

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

Аксиома 8.
Детально изучите результаты каждого теста.

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

Аксиома 9.
Никогда не изменяйте программу, чтобы облегчить ее тестирование.

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

Должно быть найдено объяснение всех результатов. И только после этого, поняв, как нужно исправить программу (не ухудшая ее экономичности и надежности), можно приступать к ее изменению. Изменения должны быть по возможности локальными, не менять общую логику программы и те ее части, которые уже отлажены. Радикальное изменение программы означает ее перепроектирование, т.е. возвращение на более раннюю стадию разработки. В любом случае, после каждого (даже сугубо локального) изменения программы должен быть повторен прогон всех использованных ранее тестов.

Аксиома 10.
По мере того, как число обнаруженных ошибок увеличивается, растет также относительная вероятность существования в ней необнаруженных ошибок.

Возрастание числа обнаруживаемых ошибок в программе при ее тестировании обычно обуславливается следующими обстоятельствами.

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

Выход из этой ситуации - вернуться к одному из предыдущих вариантов программы. Для этого рекомендуется при тестировании и отладке время от времени (перед существенным ее изменением) сохранять вариант текста программы, как-то идентифицируя (например, номером) разные его варианты.

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru