В связи с применением средств вычислительной техники во всех областях человеческой деятельности актуальна проблема надежности программного обеспечения (ПО). Использование современных технологий в программировании направлено, в основном, на создание высококачественного программного обеспечения, характеризуемого временем исполнения, требуемым объемом оперативной памяти и т д. Однако внедрение новых эффективных организационных и методологических правил проектирования программных комплексов не предотвращает появления ошибок при эксплуатации программ. Кроме того, очень часто современная практика создания программ базируется лишь на квалификации и интуиции специалистов, что приводит к наличию большого количества не выявленных при тестировании ошибок и низкому качеству программного продукта. В настоящее время достаточно внимания уделяется решению вопросов организации эффективного тестирования программ, появились работы в области оценки надежности и качества программных средств, разрабатываются теоретические основы диагностирования программных модулей [1-3]. Однако формализованный подход к решению задач диагностирования ограничивается, как правило, обнаружением факта существования дефектов программ, без локализации места их возникновения. Под термином дефект будем понимать программную ошибку, приводящую к несоответствию ожидаемых результатов выполнения программного продукта и фактически полученных результатов. После обнаружения дефекта необходимо подвергнуть его анализу с целью определения его природы - представляет ли он неисправность теста, ошибку в программном коде или является дефектом в проектных спецификациях.
Данная работа посвящена вопросам обнаружения и устранения ошибок в программных кодах. Предлагается формализованный подход к проблеме диагностирования структуры программных модулей, заключающийся в локализации кратных ошибок кода программного модуля, обнаруженных во время тестирования.
После принятия решения об устранении обнаруженных проблем, связанных с дефектами программного кода, разработчик вносит соответствующие изменения в программный код и проводит контрольное тестирование с целью подтверждения правильности работы исправленного кода. При этом довольно часто принимается априори решение о том, что дефект программы вызван существованием единственной ошибки, что на практике встречается довольно редко. Такой подход приводит к неверным результатам корректировки программ и значительно затрудняет поиск и устранение ошибок кода. Это связано с тем, что проявленный дефект работы программы может быть следствием не одной, а сразу нескольких ошибок. Кроме того, часто исправление одной из ошибок приводит к тому, что программа начинает работать значительно хуже, что связано с эффектом компенсации ошибок друг другом. Поэтому задача поиска дефекта кода должна рассматриваться как задача поиска всех возможных кратных ошибок на данном наборе тестов [4]. Отметим, что проблема построения тестов в данной работе не рассматривается.
Постановка задачи. Одним из признаков высокого качества технического проектирования является его модульность. В условиях модульного проектирования система разбивается на отдельные компоненты, при этом каждый компонент имеет свое назначение и четко определенные входы и выходы. Структуру программного модуля представим графом по управлению [1]. Каждая вершина такого графа соответствует линейному участку программы, который может заканчиваться оператором ветвления, а дуги отражают связи по управлению между линейными участками. Линейный участок характеризуется единственным входом и единственным выходом и сосредотачивает все операторы, исполняемые без разветвлений. Предполагается, что исходный граф программы ацикличен и корректен, т.е. не содержит тупиковых и висячих вершин.
Ввод контрольных точек в исполняемые маршруты позволяет реализовать принятую стратегию тестирования. Под контрольной точкой понимается место в программе, где она останавливается для отладки. Программисту становится доступной дополнительная информация, помогающая локализовать ошибки - значения переменных в этой точке, распределение памяти и регистры.
Требуется выделить реализуемые маршруты тестирования программы в соответствии с заданным критерием и назначить минимальное множество точек контроля на выделенных реализуемых маршрутах для определения ошибок произвольной кратности.
Алгоритм построения графа маршрутов тестирования. В графе по управлению определим отношение порядка таким образом, чтобы каждая направленная дуга выходила из вершины с меньшим номером и входила в вершину с большим номером. Чтобы автоматизировать процесс тестирования, необходимо построить математическую модель графа маршрутов тестирования.
Маршрутом программы назовем последовательность вида v1, (v1,v2), v2, (v2,v3) ,..., (vn-1,vn), vn, где vi - исполняемый блок программы, (vi,vi+1) - передача управления.
Графом маршрутов назовем граф G, в котором множество вершин является объединением множеств вершин выделенных маршрутов тестирования, и i-я и j-я вершины соединяются дугой, если существует соответствующая дуга хотя бы в одном выделенном маршруте, при этом направление дуги не меняется.
Существуют различные критерии выделения маршрутов для тестирования структуры программного модуля: α1 - выделение минимального множества тестируемых маршрутов программ, охватывающего все направления передач управления; α2 - выбор маршрутов тестирования на основе анализа базовых маршрутов в программе, формируемых и оцениваемых на основе определения цикломатического числа исходного графа программы; α3 - выделений полного состава базовых структур графа программы - нахождение всех существующих ациклических маршрутов, представляющих собой полное сочетание всех дуг в исходном графе программы. Очевидно, что тестирование программного модуля по критерию α3 позволяет обеспечить его максимальную корректность. Однако данный метод тестирования не получил практического развития из-за следующих причин: на практике существует сложность реализации всех тестовых воздействий; некоторые маршруты могут оказаться нереализуемыми из-за несовместимости условий, которые последовательно обрабатывались в разных вершинах. Это приводит к необходимости предварительного тщательного анализа совместимости условий в программах и отсеивания таких маршрутов перед построением программ тестирования.
В данной работе предложен автоматизированный метод тестирования программных модулей по критерию a3 и показаны преимущества его использования, причем нереализуемые в программных модулях маршруты определяются в процессе тестирования, что в некоторой степени упрощает процедуру их выявления.
В качестве математического эквивалента граф-модели используется матрица смежности его вершин. Алгоритм выделения тестируемых маршрутов по критерию a3 заключается в следующем.
На первом этапе определяется полное множество маршрутов графа программы без анализа совместимости условий в вершинах ветвления. Этот процесс полностью автоматизирован и включает следующие шаги:
1. Исходный ациклический мультиграф программы представляется его математической моделью - матрицей смежности С = ||сij||, где сij ( i, j = 1, 2, . . . , n) равно количеству дуг, инцидентных вершинам i и j.
2. Строится приведенная матрица смежности С* мультиграфа программы. При этом количество возможных маршрутов в графе равно сумме элементов первой строки матрицы С* (для многовходовых граф-моделей - сумме элементов первых строк, соответствующих входам).
3. По матрице смежности С исходного графа программы строится матрица смежности 
графа всех возможных маршрутов программы. Данный алгоритм формализован и автоматизирован. Построенная матрица является математическим эквивалентом графа маршрутов программы, выделенных по критерию α3. По матрице однозначно строится граф маршрутов программы 
на n вершинах. Количество маршрутов в программе равно сумме элементов строк матрицы *, являющимися входами графа маршрутов (номера входных вершин - номера нулевых столбцов матрицы ).
4. Строится матрица маршрутов В = ||bij|| размерностью (m x n), m строк которой соответствуют проверяемым маршрутам, n столбцов - вершинам графа маршрутов . Алгоритм ее построения полностью формализован. Если построенная граф-модель тестируемых маршрутов имеет несколько входов, она приводится к виду, имеющему один вход и один выход добавлением фиктивных вершин.
Предполагается, что на вход при тестировании подается тестовое воздействие, с выхода снимаются результаты работы программы.
На втором этапе проводится тщательный анализ совместимости условий программы, входящих в каждый маршрут матрицы В. В результате выявляются нереализуемые маршруты, которые удаляются из матрицы В.
Алгоритм назначения минимального множества точек контроля. В качестве контрольных точек будем использовать выход программного модуля и промежуточные результаты работы программы на выходах ее линейных блоков, соответствующих выходам вершин графа.
Проведем тестирование по всем маршрутам матрицы В. Маршруты, для которых имеем неверные результаты на выходе, перепишем в новую матрицу Вer - матрицу маршрутов, содержащих некорректные блоки.
Процедура поиска кратных ошибок П = {
} будет заключаться в последовательной подаче тестовых воздействий для исполнения маршрутов . Блок, соответствующий структурной компоненте программы, содержит ошибку, если результаты на его выходе не соответствуют заданным эталонным значениям. При тестировании блока проверяются все направления передач управления. Реализация маршрута 
обнаруживает ошибку блока is при реализации k-й передачи управления в случае положительных результатов исполнения всех предыдущих маршрутов 
, охватывающих блоки с меньшими номерами i1<is, i2<is, . . . , и маршрутов , тестирующих передачи управления 1, 2, . . . , k-1. Ошибка, содержащаяся в данной структурной компоненте, устраняется.
После локализации и устранения обнаруженных ошибок следует выполнить контрольное тестирование, задача которого состоит в подтверждении правильности выполненной корректировки программы.
Процедура контрольного тестирования заключается в повторении тестирования маршрутов, содержащих блок is для всех передач управления. При этом проверяются также маршруты, содержащие блок is, но не вошедшие в матрицу Ber, т.к. при корректировке блока могли быть внесены новые ошибки, проявляющиеся при реализации ранее верно работающих маршрутов.
Назовем строку матрицы маршрутов определяющей, если в ней содержится только один ненулевой элемент. Для локализации ошибки блока is очередной тестируемый маршрут должен давать определяющую строку в матрице маршрутов, множество ненулевых столбцов которой соответствует множеству непроверенных блоков программы.
Разработанный алгоритм последовательного выделения определяющих строк матрицы тестируемых маршрутов определяет порядок подачи тестовых воздействий для обнаружения ошибок произвольной кратности. При этом построенная процедура тестирования программного модуля включает тестирование для обнаружения ошибок и контрольное тестирование правильности выполненных корректировок.
Очевидно, что рассматриваемая проблема устранения ошибок программного кода далеко не тривиальна, но предложенная методика локализации кратных ошибок отличается простотой реализации и способствует повышению эффективности обнаружения и устранения дефектов программных модулей.
Список литературы
- Майерс Г. Искусство тестирования программ. - М.: Финансы и статистика, 1982. -178с.
- Липаев В.В. Надежность программных средств. -М:Синтег, 1998.-232С.
- Калбертсон Р., Браун К., Кобб Г. Быстрое тестирование. -М.:Вильямс, 2002.-383с.
- Сагунов В.И., Соколова Э.С., Бушуева М.Е. О поиске кратных ошибок в программных модулях // Контроль и диагностика, №8, 2001г. С. 11-13.