Тестирование и отладка

Тема 4. Тестирование и отладка ПО. Вопросы 1, 2, 3. Файл 308828014.
С. 1 из 5
Если вы думаете, что разработка и кодирование программы
– вещь трудная, то вы еще ничего не видели1
Тема 4. Тестирование и отладка ПО
1. Основные термины и их соотношение
2. Статические методы устранения ошибок
3. Функциональное тестирование (тестирование «черного ящика»)
4. Структурное тестирование
4.1. Критерии качества структурного тестирования
4.2. Построения тестов для базовых конструкций
4.3. Построения тестов для вложения конструкций
5. Нисходящее тестирование и отладка в процессе нисходящей разработки
6. Восходящее тестирование как альтернатива нисходящему. Соотношение подходов
1. Основные термины и их соотношение
Определения понятий тестирования и отладки были даны в теме 1 при обзоре этапов жизненного
цикла ПО (см. тему 1, вопрос 3). О нисходящей отладке и тестировании как составляющей процесса нисходящей разработки речь шла в теме 1 при обзоре принципов современной технологии разработки ПО (см. тему 1, вопрос 4). О взаимосвязи процессов нисходящего проектирования и нисходящей отладки говорилось в теме 3 при оценке нисходящего подхода (см. тему 3, вопрос 3).
Пример нисходящей разработки с тестированием приведен в вопросе 2 темы 3. Справочный материал для практической работы был выдан на семинарских занятиях. Все упомянутые положения
имеют смысл только в рамках создания программного продукта, работающего в конкретной программной среде (в отличие, например, от проектирования), в силу чего они (положения) и приводились по ходу изложения в разных контекстах. Однако эти положения являют собой компоненты
отдельной темы, объединяющей их в единую структуру.
В разработке ПО вопросы отладки и тестирования в силу их важности представляют собой отдельное направление. Технология структурного тестирования базируется на формальном аппарате (строго говоря, не одном), разрабатываемом как самостоятельное теоретическое направление.
Технологии функционального тестирования и отладки в целом не столь формализованы, однако
наборы соответствующих эмпирических правил представляют собой целые руководства или значительную часть источников, посвященных разработке ПО. Из всего этого многообразия мы рассматриваем только самые существенные и необходимые положения.
 Общие понятия отладки и тестирования
Для обеспечения целостности изложения некоторые положения предшествующих тем будут повторно воспроизведены.
Отладка – процесс изменения программы с целью исправления ошибок. Цель отладки – получение работоспособной программы.
Тест – совокупность специально подобранных входных и соответствующих им выходных данных,
используемая для контроля правильности программы, или, проще, заранее заготовленная пара
«вход – выход». Выходные данные теста формируются вручную или программным путем, но только не с помощью тестируемой программы.
Содержание тестов определяется спецификацией задачи и логикой ее решения.
Тестирование – исполнение программы на наборе тестов на компьютере. Тестирование является
основным процессом, обеспечивающим надежность программы. Его цель – проверка правильности функционирования программы и выявление возможных ошибок.
Принципиальная трудность проектирования тестов состоит в практической невозможности составления всех тестовых наборов данных для всех возможных режимов работы разрабатываемой программной системы. Поэтому задача проектирования тестов сводится к проектированию ограни-
1
Г. Майерс. Искусство тестирования программ. – М., Финансы и статистика, 1982. – 176 с. С. 55.
Тема 4. Тестирование и отладка ПО. Вопросы 1, 2, 3. Файл 308828014.
С. 2 из 5
ченного их набора, гарантирующего с достаточной достоверностью правильную работу программы во всех практически значимых режимах.
Отладка включает тестирование, так как предполагает анализ и исправление программы без ее
выполнения (анализ без применения компьютера и исправление синтаксических ошибок в результате компиляции). Так, в кн. Р. Гласса1 все методы поиска ошибок подразделяются на статические,
включающие анализ программы без ее выполнения, и методы тестирования.
Понятие отладки применимо к программе на стадии разработки.
Приведенные понятия теста и тестирования относятся к программе в целом, независимо от аспекта ее рассмотрения (как «черного ящика» или с точки зрения структуры; тестирование разработчиком или заказчиком).
 Виды тестов
Функциональные тесты составляются на уровне спецификации, до решения задачи. Будущий
алгоритм рассматривается как «черный ящик» - функция с неизвестной (или не рассматриваемой)
структурой, преобразующая входы в выходы. Суть функциональных тестов: каким бы способом ни
решалась задача, при заданных входных значениях должны получиться соответствующие выходные значения.
Структурные тесты составляются для проверки логики решения, или логики работы уже готового алгоритма. Логика определяется последовательностью операций, их условным выполнением
или повторением (т.е. композицией базовых конструкций). Совокупность структурных тестов должна обеспечить проверку каждой из таких конструкций.
Чаще всего совокупность тщательно составленных функциональных тестов покрывает множество
структурных тестов.
Приведенные понятия различаются тем, что первое рассматривает программу только с точки зрения входов и выходов, тогда как второе относится к ее структуре; но оба понятия не касаются процесса организации тестирования.
 Общая последовательность разработки тестов
Наиболее рациональная процедура заключается в том, что сначала разрабатываются функциональные тесты , а затем – структурные.
 Способы организации отладки и тестирования в процессе разработки
Нисходящая отладка напрямую связана с нисходящим проектированием и предполагает кодирование проекта и отладку всей программы на каждом уровне разработки.
Отладка начинается с отладки взаимосвязи подзадач самого высокого уровня (отладки интерфейсов подзадач). Для этого программа, помимо алгоритмов подзадач, сразу пишется полностью. Алгоритмы подзадач заменяются заглушками – простейшими операциями, имитирующими решение
подзадачи.
На последующих уровнях по такой же схеме разрабатываются и отлаживаются алгоритмы подзадач.
Восходящая отладка предполагает на начальном этапе разработку и отладку отдельных процедур. Поскольку процедуры самостоятельно выполняться не могут, для каждой из них пишется своя
специальная отладочная программа – драйвер, которая по крайней мере должна обеспечить процедуру входными значениями фактических параметров и вывести выходные значения.
На следующем этапе процедуры объединяются в блоки, решающие более крупные подзадачи.
Соответствующие программы также отлаживаются через посредство драйверов и т.д. В итоге все
блоки объединяются в программу, решающую задачу в целом.
Приведенные понятия рассматривают взаимосвязь процессов разработки и тестирования, но не
касаются видов тестирования – функционального или структурного.
Здесь можно сделать следующие уточнения.
При рассмотрении отдельной подзадачи ее тестирование по входу-выходу можно расценивать как
функциональное (для этой подзадачи), хотя на практике понятие функционального тестирования
применительно к компоненту программы не используется. Тестирование логики решения, т.е. вы-
1
Р. Гласс. Руководство по надежному программированию. – М., Финансы и статистика, 1982. – 256 с.
Тема 4. Тестирование и отладка ПО. Вопросы 1, 2, 3. Файл 308828014.
С. 3 из 5
полнение тестов, обеспечивающих проверку выполнения отдельных структур алгоритма подзадачи, является структурным тестированием.
В рамках общей задачи подзадача тестируется структурными тестами общей задачи как «черный
ящик».
2. Статические методы устранения ошибок
Эти методы основываются на анализе кода и документации программы.
 Проверка за столом
Этот метод наиболее традиционен, но при этом совершенно необходим, хотя такая проверка не
вызывает восторга и ее иногда стараются избежать.
Термин «проверка за столом» характеризует неавтоматизированную деятельность, к которой
наиболее часто относят:
- анализ текста программы на наличие ошибок;
- выполнение программы вручную («сухую прокрутку»).
 Коллективная проверка (контроль программы, сквозной просмотр)
Это процесс, при котором бригада программистов тщательно просматривает программу или ее
часть в порядке инспекции. Программа проверяется с разных точек зрения с целью поиска ошибок,
ускользнувших при менее широком подходе.
Коллективную проверку лучше проводить после исключения синтаксических ошибок программы и,
возможно, после предварительного тестирования. Предпочтительно, чтобы коллектив проверяющих включал трех-четырех разработчиков (не руководство!), заинтересованных в качестве разрабатываемой программы (например, проверяющие разрабатывали бы программу, взаимодействующую с проверяемой).
Последовательность действий по проверке вырабатывается самими участниками.
 Структурный анализ
Это автоматизированный анализ текста программы с помощью специальных программ – структурных анализаторов. Примеры обнаруживаемых с их помощью ошибок:
- переменные не описаны или описаны неправильно;
- переменные используются прежде, чем им было присвоено значение, или присвоенное значение никогда не используется;
- используются недопустимые языковые формы;
- неправильное вложение конструкций;
- несоответствие формального и фактического параметров процедур;
- невыполнимые условия; потенциально бесконечные циклы и др.
Как самостоятельное средство поиска ошибок такого рода программы широкого распространения
не получили, однако большинство перечисленных функций включено в современные компиляторы. .
 Доказательство корректности (верификация)
Это процесс, имеющий целью показать с помощью математического аппарата соответствие проекта и программы предъявляемым к ним требованиям. Программа разбивается на логические сегменты, определяются входные и выходные утверждения для каждого сегмента и доказывается,
что если все входные утверждения при работе программы истинны, то и все выходные утверждения также будут истинны. Входное утверждение описывает характеристики входных данных сегмента, а выходное утверждение – характеристики результатов.
Аппарат и процедуры верификации подробно описаны, например, в ранее упоминавшейся книге Р.
Лингера и др.
Реально метод может быть применен только для доказательства правильности небольших структурированных программ и представляет скорее теоретический интерес.
3. Функциональное тестирование (тестирование «черного ящика»)
При функциональном тестировании выявляются следующие категории ошибок:
Тема 4. Тестирование и отладка ПО. Вопросы 1, 2, 3. Файл 308828014.
С. 4 из 5
- некорректность или отсутствие функций;
- ошибки интерфейса;
- ошибки в структурах данных;
- ошибки машинных характеристик (нехватка памяти и др.);
- ошибки инициализации и завершения.
Техника тестирования ориентирована:
- на сокращение необходимого количества тестовых вариантов;
- на выявление классов ошибок, а не отдельных ошибок.
 Разбиение на классы эквивалентности
Это самый популярный способ. Его суть заключается в разделении области входных данных программы на классы эквивалентности и разработке для каждого класса одного тестового варианта.
Класс эквивалентности – набор данных с общими свойствами, в силу чего при обработке любого
набора данных этого класса задействуется один и тот же набор операторов1.
Классы эквивалентности определяются по спецификации программы. Тесты строятся в соответствии с классами эквивалентности, а именно: выбирается вариант исходных данных некоторого
класса и определяются соответствующие выходные данные.
Самыми общими классами эквивалентности являются классы допустимых и недопустимых (аномальных) исходных данных. Описание класса строится как комбинация условий, описывающих
каждое входное данное.
Условия допустимости или недопустимости данных задают возможные значения данных и могут
описывать:
1. некоторое конкретное значение; определяется один допустимый и два недопустимых класса
эквивалентности: заданное значение, множество значений меньше заданного, множество
значений больше заданного;
2. диапазон значений; определяется один допустимый и два недопустимых класса эквивалентности: множество значений в границах диапазона; множество значений, выходящих за левую
границу диапазона; множество значений, выходящих за правую границу диапазона;
3. множество конкретных значений; определяется один допустимый и один недопустимый
класс эквивалентности: заданное множество и множество значений, в него не входящих.
Такие классы можно описать языком логики, например, языком исчисления предикатов. Описания
более сложных условий и соответствующих классов (например, элементы массива должны находиться в некотором диапазоне и при этом массив не должен содержать нулевых элементов) могут
быть построены на основании приведенных выше условий.
В примере, приводимом в вопросе 2 темы 3, при построении тестов неформально использовался
описанный метод. В методических целях были выделены только основные класс тестов. Кроме
того, исходя из условия задачи, были выделены классы эквивалентности внутри класса правильных данных.
 Анализ граничных значений
Этот способ построения тестов дополняет предыдущий и предполагает анализ значений, лежащих
на границе допустимых и недопустимых данных. Построение таких тестов часто диктуется интуицией.
Основные правила построения тестов:
1. если условие правильности данных задает диапазон, то строятся тесты для левой и правой
границы диапазона; для значений чуть левее левой и чуть правее правой границы;
2. если условие правильности данных задает дискретное множество значений, то строятся тесты для минимального и максимального значений; для значений чуть меньше минимума и
чуть больше максимума;
Здесь видна связь структурного и функционального тестирования, поскольку набор операторов – это элемент структуры программы, которая, по определению функционального тестирования, игнорируется.
1
Тема 4. Тестирование и отладка ПО. Вопросы 1, 2, 3. Файл 308828014.
С. 5 из 5
3. если используются структуры данных с переменными границами (массивы), то строятся тесты для минимального и максимального значения границ.
Согласно этим правилам для упомянутого примера следовало бы построить тесты для значений
данных, лежащих на границах диапазонов; кроме того, следовало бы рассмотреть массив из одного и из 50 элементов и, соответственно, матрицу из такого же количества строк и столбцов.
 Диаграммы причин-следствий
Взаимосвязь классов эквивалентности и соответствующих им действий описывается формально в
виде графа на основе автоматного подхода. Граф преобразуется в таблицу решений, столбцы которой в свою очередь преобразуются в тестовые варианты.