ТЕСТИРОВАНИЕ, ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ ПРОГРАММ
УДК 004.92+004.94
ЛОКАЛИЗАЦИЯ ОШИБОК МЕТОДОМ ПОСТРОЕНИЯ СОКРАЩЕННЫХ ТРАСС
© 2009 г. С. Г. Грошев
Институт системного программирования РАН 109004 Москва, ул. Солженицына, 25 E-mail: sgroshev@ispras.ru Поступила в редакцию 28.12.2007 г.
В статье предложен метод построения на основе существующего теста UniTESK, находящего ошибку в тестируемой системе, минимального теста, обнаруживающего ту же ошибку. Полученный минимальный тест может использоваться для локализации ошибки в реализации тестируемой системы. Рассмотрены две стратегии построения такого теста, проведен сравнительный анализ их достоинств и недостатков и предложена оптимальная. Приведено математическое обоснование метода. Предложен алгоритм, реализующий его, и доказана корректность алгоритма. Описана реализация предложенного метода для инструментария тестирования CTESK.
1. ВВЕДЕНИЕ
Для удовлетворения непрерывно возрастающих потребностей пользователей и поддержки стабильного развития современного общества требуется разрабатывать все более сложное программное обеспечение (ПО). Разработка всегда включает в себя множество циклов вида "тестирование - обнаружение ошибок - исправление ошибок - проверочное тестирование". Чем сложнее становится разрабатываемое ПО и чем более серьезные задачи оно решает, тем больше в нем может происходить разнообразных внутренних и внешних взаимодействий, и в результате могут возникать все более изощренные ошибки. Некоторые из них проявляются только при сложных комбинациях внутренних и внешних условий, в результате их гораздо сложнее своевременно обнаруживать, локализовывать в реализации и исправлять, и тем выше их потенциальная опасность.
Существуют технологии тестирования, позволяющие тестировать ПО с заданной степенью полноты тестового покрытия. Например, ишТЕЯК [1-4] - технология автоматизации функционального тестирования на основе формальных методов, разработанная в Институ-
те системного программирования РАН. Однако чем сложнее сама тестируемая система и разработанные для нее тесты, тем больше информации о наблюдаемом поведении приходится анализировать в случае обнаружения ошибки, и тем сложнее понять, какая часть этой информации имеет непосредственное отношение к обнаруженной ошибке, а какая - нет. Данная статья посвящена методу, позволяющему локализовы-вать ошибки за счет автоматического нахождения минимальных условий, необходимых для их воспроизведения.
2. ПОСТАНОВКА ЗАДАЧИ
Применяемые для тестирования методы зависят от сложности тестируемой системы. В простейших системах внутреннее состояние отсутствует или несущественно для поставленной задачи тестирования, а реакции, которые выдают такие системы, однозначно определяются полученными воздействиями (стимулами). В этом случае при обнаружении ошибки для ее воспроизведения достаточно повторить такой же тестовый стимул, а для ее локализации в коде достаточно проверить только код, выполняющийся при обработке данного стимула.
35
3*
Но гораздо чаще поведение системы зависит не только от полученного стимула, но и от ее внутреннего состояния, которое, в свою очередь, зависит от предыстории взаимодействий с системой. Тогда для воспроизведения ошибки необходимо тем или иным образом привести систему в то же состояние и применить тот же тестовый стимул, что и при ее обнаружении, а для локализации - проверить код, обрабатывающий данный стимул в данном состоянии.
Для тестирования таких систем широко применяется подход, при котором тестируемая система моделируется конечным автоматом (КА) [5]. Состояния такого автомата соответствуют состояниям этой системы (обычно одно модельное состояние соответствует целому классу реализационных), входной алфавит - набору всех возможных тестовых стимулов, выходной алфавит - набору всех возможных реакций системы, а начальное состояние - состоянию, в котором тестируемая система находится (или в которое приводится) в начале теста. Задача построения тестовых последовательностей при этом сводится к построению на графе переходов модельного КА набора путей, удовлетворяющего заданным требованиям к покрытию.
Методы тестирования на основе КА можно условно поделить на два класса: off-line и on-line тестирование [6, 7]. В off-line методах граф состояний и переходов КА полностью известен заранее, на основе этой информации сначала строится набор тестов, обеспечивающий заданное тестовое покрытие, и только потом эти тесты выполняются. В on-line методах тестирования граф состояний КА строится по мере его обхода, и выбор очередного тестового воздействия осуществляется на основе информации о графе, собранной при выполнении предыдущих тестовых воздействий. Такие методы обладают большей гибкостью и зачастую позволяют существенно сократить трудоемкость разработки тестов, так как избавляют от необходимости целиком описывать модельный КА.
В технологии тестирования UniTESK используются моделирование с помощью КА и on-line метод построения тестов. При этом для создания тестового сценария необходимо описать только способ вычисления состояния модельного КА из состояния реализации, а также способ перебора
применяемых тестовых стимулов в зависимости от состояния [6]. Всю работу по построению обхода графа переходов КА, обеспечивающего создание конкретной тестовой последовательности, берет на себя библиотечный компонент тестовой системы, называемый обходчиком, который автоматически строит граф переходов модельного КА по мере его обхода [5, 6]. Тестовый сценарий содержит функцию вычисления состояния модельного КА и набор сценарных методов. Сценарный метод содержит набор итерационных переменных (возможно, пустой), правила перебора их значений и способ отображения набора значений итерационных переменных в конкретное тестовое воздействие. Входной алфавит модельного КА состоит из упорядоченных пар вида (имя сценарного метода, набор значений его итерационных переменных).
В процессе выполнения тестовый сценарий ишТЕЯК автоматически генерирует трассу, содержащую различную информацию о работе тестовой и тестируемой систем. В дальнейшем мы будем предполагать, что в трассе содержится информация о единственном тестовом сценарии, сценарные методы которого запускаются последовательно в единственном потоке управления. Если в трассе встречается информация о нескольких не взаимодействующих между собой сценариях, то мы можем выделить информацию об одном из них и рассматривать только ее; для случая, когда тестовые воздействия на одни и те же элементы состояния тестируемой системы осуществляются параллельно в нескольких потоках управления [8], рассматриваемый метод неприменим.
Для проверки корректности работы тестируемой системы используются формальные спецификации требований к ней. Каждый раз после применения очередного тестового стимула полученные от тестируемой системы реакции анализируются на соответствие спецификации, и определяется новое состояние модельного КА. Несоответствие наблюдаемой реакции или наблюдаемого состояния целевой системы описанным в спецификации требованиям считается ошибкой и требует дальнейшего анализа. В результате анализа может быть принято решение о существовании ошибки в реализации или о некорректности спецификационной модели. Далее мы бу-
дем исходить из предположения, что спецификация уже отлажена и корректна, а все расхождения между наблюдаемым и специфицированным поведением тестируемой системы вызваны ошибками в ней.
Поскольку зачастую состояние системы имеет достаточно сложную структуру, а единственный способ его изменить - подавать те же стимулы, которыми пользовался тест, то возникает естественный способ приведения системы в то же состояние для воспроизведения ошибки: полное или частичное повторение последовательности стимулов, которые подавал тест, обнаруживший эту ошибку. Последовательность применяемых стимулов при этом извлекается из сгенерированной тестом трассы, а процесс их последовательного повторения называется воспроизведением трассы (trace replay). В силу используемого в технологии UniTESK способа описания модельного КА, этот способ надежнее повторного прогона тестов, так как программный контракт обходчика UniTESK не гарантирует тот же порядок обхода дуг графа.
Более того, в реальных проектах часто нет возможности во время тестирования точно определить внутреннее состояние тестируемой системы. В этом случае она моделируется как черный ящик [6], состояние которого не получается напрямую из состояния тестируемой системы, а вычисляется на основании предыстории взаимодействий с ней. При этом после каждого тестового воздействия новое состояние модели вычисляется на основании предыдущего состояния, поданного стимула и полученных реакций. По разным причинам (это могут быть как ошибки реализации, так и ошибки спецификации) со временем состояние модели может перестать соответствовать состоянию реализации. Это приводит к расхождению между ожидаемым и наблюдаемым поведением тестируемой системы, причем такое расхождение может проявиться не сразу, а только в реакциях на последующие стимулы, то есть момент совершения ошибки и момент ее обнаружения могут различаться. В этом случае задачи воспроизведения и локализации ошибки существенно усложняются: поскольку у нас нет достоверного знания о внутреннем состоянии системы в момент проявления
ошибки, необходимо точно воспроизводить всю последовательность тестовых стимулов из трассы теста, обнаружившего ошибку, и проверять весь код, который был активирован ими, и все элементы состояния реализации, которые были при этом затронуты.
Кроме вышеуказанных достоинств on-line методов тестирования, у них есть и свои недостатки. Зачастую off-line методы позволяют построить набор коротких тестов, покрывающих всю тестируемую функциональность, и в случае обнаружения таким тестом ошибки ее обычно достаточно легко локализовать. В отличие от них, on-line методы тестирования обычно строят длинные тесты: так, обходчик UniTESK стремится построить один путь по графу модельного КА, покрывающий все его переходы. В результате может возникнуть такая ситуация, что к моменту обнару
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.