Программные продукты и системы

В тестировании программного обеспечения можно выделить два основных подхода: структурное и функциональное тестирование.

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

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

Путевой критерий технически упирается в проблему бесконечности путей для циклов типа while, поэтому он в основном имеет теоретическое значение в тестировании.

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

Однако при всем удобстве и простоте этого метода для цикла типа while это мало что дает. Поставив счетчик, практически можно убедиться только в том, что программист вошел в цикл, но не всегда в том, что он вышел из него. Поэтому в последнее время делается много попыток соединить два альтернативных подхода, то есть объединить метод счетчика для ветвевого тестирования при структурном подходе с идеями функционального тестирования.

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

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

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

Инструментарий, поддерживающий такой подход, состоит из трех основных разделов: лексический анализ, анализ вложенности условий и циклов и раздел генерации тестовых данных.

Раздел лексического анализа включает в себя функции: определения ключевых терминов, характеризующих структуру программы, выявления мест расстановки мониторов (в частности, счетчиков или маркеров), практического размещения мониторов (счетчиков).

Работа раздела лексического анализа заключается в посимвольном считывании тестируемой программы и одновременном определении ключевых слов (if, then, else, for, while и т.д.). Сами по себе ключевые слова, кроме статистической информации, ничего не дают, поэтому после их определения производится расстановка счетчиков, которые в дальнейшем помогут тестировать программы по ветвевому критерию. Именно эти счетчики дадут информацию о том, сколько каждая ветвь отработала в тестируемой программе. Эта информация может оказаться очень полезной, так как достаточно сложно отследить, какой фрагмент программы никогда не будет выполняться.

В качестве примера приведем фрагмент программы без счетчиков (слева) и со счетчиками (вариант справа):

При любом наборе тестовых данных вложенное условие if(Array[i]= =x) никогда не будет выполнено, об этом просигнализирует счетчик b2, равный 0.

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

Раздел анализа вложенности условий и циклов выполняет функции выборки вложенных условий и циклов для дальнейшего анализа, а также определения глубины вложенности условий и циклов.

Если степень вложенности условий является принципиальной, можно рекомендовать использование оператора case. Глубина и вложенность условий и циклов, предложенная инструментарием на данный момент, ограничивается числом 4.

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

If(y<5)

{

   If(y<2)

{…}

   If(y<3)

{…}

}

При анализе приведенного фрагмента программы тестирующая программа подсчитает фигурные скобки, обработав знак и значение условия, выделит диапазон (– ¥; 5) и проверит, что значения 2 и 3 попадают в выделенный диапазон. На основе проделанной работы (подсчета фигурных скобок и анализа условий) будет принято решение о том, что в данном фрагменте программы присутствуют 2 вложенных условия: if(y<2) и if(y<3).

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

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

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

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

Авторы благодарят доктора технических наук профессора Кораблина Ю.П. (Российский государственный социальный университет, г. Москва ) за замечания по поводу нахождения области невыполняемых ветвей программ при автоматической генерации тестовых последовательностей.

Литература

1. Edward Kit, Software Testing In The Real World:Improving The Process.

2. Bogart T.G., Fundamentals of software testing