Тестирование программ является одним из самых длительных и ответственных этапов разработки. Особое значение придается ему в парадигмах структурного и надежного программирования.
При тестировании самыми важными являются два вопроса: в каком порядке тестировать модули и как готовить и задавать тестовые данные.
Трудоемкость тестирования связана с количеством самих ошибок, в связи с чем, надо четко выделить основные причины их появления:
- неудовлетворительное организационное, методическое обеспечение всего процесса разработки;
- большое число требований и их изменений по ходу работы;
- недостаточная квалификация разработчика.
Тест — это набор контрольных входных данных совместно с ожидаемыми результатами. Выделим следующие этапы тестирования:
- Тестирование модулей, которое производится в случае, если модуль может быть проверен автономно от других модулей. При этом необходимо убедительно продемонстрировать, что модуль работает корректно во всех граничных условиях.
- Тестирование подсистем, целью которого является проверка сопряжения между собой модулей, входящих в подсистему, корректную передачу данных между ними.
- Тестирование системы. На этом уровне выявляются ошибки сопряжения, сложные ошибки быстродействия и емкости, логические ошибки.
Для обнаружения всех ошибок в программе необходимо выполнить исчерпывающее тестирование. Чаще всего тестирование и отладка программного обеспечения проводится по знанию внутреннего объекта тестирования (рис. 1).
Рис. 1. Виды тестирования по знанию системы
Белый ящик — это техника тестирования, которая позволяет проверить внутреннюю структуру программы, ее логику и корректность работы. Проводя тестирование Белого ящика, специалист руководствуется определенными знаниями программного кода, чтобы изучить значения выходных данных. Определяя принцип работы программы, он замечает отклонения программы от своей цели. При работе специалист имеет доступ к коду, тем самым тестируя внутреннюю структуру программы.
Серый ящик — это техника тестирования, которая позволяет проверить не только что делает программа, но и как она это делает. Знания о внутреннем устройстве программы, позволяют специалисту более точно подбирать входящие значения и проверять выходящие, тем самым покрывать тестами более обширную область возможных дефектов. В этом случае специалист имеет доступ к внутреннему устройству программы, но тестирование производит с точки зрения конечного пользователя.
Чёрный ящик — это техника тестирования, которая позволяет оценить функциональность системы, руководствуясь её спецификацией. Специалист при проведении тестирования программы ограничивается прогонами на небольшом подмножестве всех возможных данных. Для этого он выбирает наиболее подходящие подмножества (подмножества с наивысшей вероятностью обнаружения ошибок). Здесь специалист использует только внешние рычаги взаимодействия с программой: с помощью пользовательского интерфейса или подключившись к тестируемой системе.
Если не известна тестируемая система, то используется метод Чёрного ящика. Если известны все детали реализации тестируемой программы, то используется метод Белого ящика. Если известны только некоторые особенности реализации тестируемой системы, то используется метод Серого ящика. Суть этих методом не сложная, но эффективность тестирования с помощью каждого из них требует хороших знаний и навыков.
При конструировании программы необходимо определить адекватный способ задания исходных данных — с клавиатуры (в текстовом или графическом режиме) или из файла.
При тестировании реальной программы набор возможностей задания данных должен быть существенно расширен, что позволяет выполнять тестирование более гибко, эффективно и с меньшими затратами. Можно отметить несколько различных способов задания исходных данных, использованных при создании демонстрационных программ, которые рекомендуется применять при тестировании пользовательских программ:
- ввод с клавиатуры в текстовом режиме (в ответ на программный запрос, указывающий содержательное название данного и множество допустимых значений);
- генерация в программе случайных чисел, задающих, как правило, элементы составных данных (массивов, файлов);
- генерация данных определенной структуры или с определенными свойствами с помощью генераторов тестов;
- тестовые файлы небольшого размера, содержащие специально подобранную последовательность элементов, на которых наглядно демонстрируется исполнение алгоритма;
- тестовые файлы большого размера (с произвольными или обладающими определенными свойствами данными) для получения количественных оценок алгоритма;
- произвольные пользовательские файлы, имена которых запрашиваются программой;
- графические объекты, вводимые с помощью графического курсора и клавиш.
В зависимости от целей программы исходные данные могут отображаться на экране программой или оставаться скрытыми от пользователя. В одной и той же программе можно предусмотреть несколько способов задания исходных данных.
Рассмотрим следующие правила тестирования программ:
− Правило № 1.
Тестирование является ключевой задачей разработки потому, оно не только является довольно длительным процессом, а потому что тестирование — очень ответственный этап разработки, и от того, как оно будет происходить зависит правильность и надёжность получаемой в итоге программы.
Кроме того, как правило, в процессе тестирования учебных программ выясняется необходимость выполнения ряда доработок программы, связанных с оценкой:
- интерфейса (удобства ввода данных и их контроля, точности и полноты выдаваемых сообщений);
- приемлемости времени исполнения программы;
- необходимого представления (типа) данных и точности вычислений.
− Правило № 2.
Цели тестирования для учебных программ весьма скромны — показать, что программа при ее исполнении ведет себя правильно, в соответствии с решаемой задачей, т. е. выдает правильные результаты для допустимых исходных данных и сообщает о невозможности их обработки (желательно на ранней стадии обработки) для неверных данных или их недопустимой комбинации. Осознание этих целей должно побудить разработчика (или тестировщика) спланировать достаточно полный пакет тестов, а также сроки разработки с учетом сложности тестирования программы.
− Правило № 3.
Оценка ожидаемых выходных данных основана на определении теста как двух наборов данных — исходных данных и ожидаемых результатов работы программы. Даже если тестирование не документируется (например, если исходные данные теста вводятся с клавиатуры, а результаты выдаются на экран), то перед тем, как вводить данные или в процессе их ввода, нужно обязательно предсказать ожидаемые результаты работы программы.
− Правило № 4.
Подготовка тестов как для правильных, так и для неправильных входных данных является важной частью. Под правильными данными здесь понимаются данные таких типов, диапазонов, форм задания, размеров (для агрегатных данных), которые допускает программа. Однако, программа будет правильной (надежной), если она будет адекватно воспринимать и недопустимые данные, т. е. контролировать правильность задания данных как в отдельности, так и в совокупности (возможные наборы значений), и в случае неправильного задания данных, выдавать об этом вразумительные сообщения или выполнять некоторые действия.
− Правило № 5.
Пакет тестов представляет собой совокупность тестов (исходные данные и ожидаемые результаты), по возможности охватывающих все случаи задания исходных данных задачи.
Это, в частности, означает, что в пакете тестов должны быть тесты, задающие как допустимые, так и недопустимые программой значения исходных данных, находящиеся:
- внутри допустимого интервала (множества),
- на каждой из границ интервала,
- вне допустимого интервала.
Кроме того, должны быть рассмотрены все «вырожденные» случаи задания исходных данных:
- пустые строки, множества и файлы,
- последовательности (представляемые массивами) нулевой длины и длины, превышающей допустимую программой (по каждому из измерений массива).
− Правило № 6.
Когда исходные данные теста задаются для того, чтобы посмотреть, «что получится» — это бессмысленная работа. Даже если прогон теста не документируется, ввод его исходных данных с клавиатуры должен быть осмысленным: это должны быть данные, которые можно воспроизвести еще раз, т. е. представления данных (числовые, строковые) должны быть короткими, однообразными, подчиненными каким-либо правилам, одним словом, запоминающимися.
− Правило № 7.
Детальное изучение результатов каждого теста необходимо. Лучшим средством анализа результатов тестирования является документирование результатов (запись их в файл) и последующее их сравнение с ожидаемыми (тоже задокументированными) результатами. Это сравнение нетрудно выполнять автоматически некоторой программой, даже если сравниваемые данные могут совпадать не в точности, а с некоторой прогнозируемой погрешностью (например, вещественные числа). Но если делается даже простой визуальный анализ выдаваемых на экран значений, он должен быть тщательным и исчерпывающим. Непременным требованием при этом должно быть сохранение на экране исходных данных теста (а иногда и формулировки задачи) для того, чтобы можно было воспроизвести ожидаемые результаты.
− Правило № 8.
По мере того, как число обнаруженных ошибок увеличивается, растет также относительная вероятность существования в ней необнаруженных ошибок.
Возрастание числа обнаруживаемых ошибок в программе при ее тестировании обычно обуславливается следующими обстоятельствами.
- Программа изначально составлена (спроектирована) очень плохо, так что никакие ее локальные исправления, выполняемые при тестировании и отладке, не могут ее скорректировать. В этом случае необходимо вернуться к ее перепроектированию, отбросив, возможно полностью, старый вариант программы;
- Неправильные изменения программы в процессе ее тестирования, причем с каждым изменением программа может все более отдаляться от правильного варианта.
Выход из этой ситуации — вернуться к одному из предыдущих вариантов программы. Для этого рекомендуется при тестировании и отладке время от времени (перед существенным ее изменением) сохранять вариант текста программы, как-то идентифицируя (например, номером) разные его варианты.
Сегодня существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
Литература:
- http://www.gateslab.com/ Тестирование «Белого ящика».
- http://www.galight.com/ Тестирования методом серого ящика.
- http://www.wikiwaqnd.com/ Тестирование по стратегии чёрного ящика.
- http://www.programmer-lib.ru/ Тестирование программ.
