автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Методы генерации тестовых сценариев на основе структурированных UCM-моделей проектируемой системы

Воинов Никита Владимирович

Методы генерации тестовых сценариев на основе структурированных иСМ-моделей проектируемой системы

Специальность 05.13.11 -Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

Автореферат

диссертации на соискание ученой степени кандидата технических наук

2- 8 ДПР 2011

Санкт - Петербург - 2011

4844654

Работа выполнена в Государственном образовательном учреждении высшсгр профессионального образования «СанкчЧ1етербургскнй государственный иолигехиический университет».

Научный руководитель - кандидат технических наук, профессор Котляров Всеволод Павлович

Официальные оппоненты — доктор технических наук, профессор

Никифоров Виктор Викеитьевич доктр технических наук, профессор Сафонов Владимир Олегович

Ведущая организация - Федеральное государственное унитарное предприятие «Научно-производственное объединение «Импульс»

Зашита состоится « 12» 2011 г. в {£\ Л" часов на заседании

диссертационного сонета Д 212.229,18 при ШУ ВПО «Санкт-Петербургский государственный политехнический университет» но адресу: 195251, Санкт-Петербург, Политехническая ул., д.29, 9 уч. корп., ауд. 325.

С диссертацией можно ознакомиться в Фуиламентальной библиотеке ГОУ ВПО «Санкт-Петербургский государственный иол технический университет».

Автореферат разослан « £ СиЦ'ЛсСЛ, 2011 г.

Ученый секретарь

диссертационного совета Васильев А.Е.

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

Анализ предметной области показал, что на данный момент большинство промышленных инструментов тестирования на основе моделей в качестве формальной нотации используют такие языки, как UML, SDL и конечные автоматы. Безусловно, перечисленные нотации, например, UML, предлагают достаточно наглядную и удобную форму представления поведения разрабатываемой системы, однако требуют, во-первых, элементарных знаний языка UML, его конструкций, видов диаграмм и т.д., во-вторых, детализацию модели уже на самых ранних этапах разработки, когда детали еще неизвестны. Как показывает практика, ранняя детализация моделей в нотациях UML, SDL не очевидна и является слишком низкоуровневой, в частности для контроля заказчиком этапа дизайна проектируемой системы. Поэтому не всегда согласование заказчиком и исполнителем использованного подхода в дизайне системы проходит гладко и эффективно, что приводит к последующим изменениям системы и как следствие к дополнительным расходам на разработку ПО.

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

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

Настоящая работа посвящена разработке методов генерации тестовых сценариев на основе высокоуровневых UCM-моделей проектируемой системы. В качестве базового инструментария в работе используется технология VRS/TAT (Verification of Requirements Specifications (VRS) - инструментарий верификации требований; Test Automation Toolset (TAT) - инструментарий автоматизации тестирования), которая является одним из наиболее перспективных современных инструментов верификации и автоматизации тестирования на основе моделей. Реализованные в работе методы позволили сократить трудоемкость процесса разработки тестовых сценариев путем автоматизации ручных этапов, устранив следующие недостатки и ограничения в инструментарии VRS/TAT: трудоемкая ручная формализация модели базовых протоколов; отсутствие методов структурирования модели для возможности ее анализа по частям и на разных уровнях абстракции; генерация трасс осуществляется по всему дереву поведения модели, что приводит к большому количеству ненужных трасс и длительному времени генерации; отсутствует возможность отслеживать соответствие между отдельными требованиями и элементами создаваемой модели и как следствие сложность определения покрытия требований в полученных тестовых сценариях.

Цели и задачи диссертационном работы. Целью диссертационной работы является сокращение трудоемкости процесса разработки тестовых сценариев путем применения высокоуровневых UCM-моделей, контролируемых заказчиком. Сокращение трудоемкости осуществляется автоматизацией следующих этапов: преобразование UCM-моделей в модели базовых протоколов; структурирование модели базовых протоколов; поиск определенных сценариев поведения модели; отслеживание соответствия между требованиями и элементами модели; поиск покрытия требований полученными тестовыми сценариями. Для достижения цели в работе решены следующие задачи:

• обоснование выбора высокоуровневой формальной нотации для контролируемого заказчиком описания программной системы на стадии ее дизайна;

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

работают инструменты верификации и автоматизации тестирования (например, VRS/TAT);

• разработка методов структурирования формальной модели для возможности пошагового анализа по компонентам и на различных уровнях абстракции;

• формулировка критериев покрытия тестовыми сценариями набора функциональных требований на систему с возможностью отслеживания соответствия между требованиями и элементами модели;

• разработка методов и инструментальных средств построения тестовых сценариев, удовлетворяющих заданному критерию, на основе анализа формальной модели;

• разработка методов и инструментальных средств сокращения полученного набора тестовых сценариев;

• интеграция инструментальных средств, реализующих разработанные методы, в технологическую цепочку VRS/TAT;

• применение предложенных инструментальных средств в составе технологической цепочки VRS/TAT в крупных промышленных телекоммуникационных проектах. Предметом исследования являются методы и инструментальные средства

тестирования на основе моделей.

Методы исследования. Для решения поставленных в работе задач используются теория инсерционного программирования, аппарат формальных спецификаций. Применяются стандарты языков Use Case Maps (UCM) и Message Sequence Charts (MSC).

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

Научные результаты и их новизна.

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

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

базовых протоколов. Данный метод позволяет заменить ручное создание базовых протоколов их генерацией по высокоуровневой UCM-модели и анализировать поведение модели по компонентам и на различных уровнях абстракции.

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

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

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

Практическая значимость работы. На базе полученных научных результатов разработан комплекс программных средств, интегрированный в технологию VRS/TAT. Усовершенствованная технология VRS/TAT после интеграции разработанных методов была применена в ряде промышленных телекоммуникационных проектов и доказала свою высокую эффективность для обеспечения проверки качества разрабатываемого ПО, позволив сократить более чем на 60% трудоемкость разработки тестовых сценариев по сравнению с существующим подходом.

Апробация работы. Основные положения и результаты диссертационной работы доложены и обсуждены на международных научных конференциях "The Third Spring Young Researchers' Colloquium on Software Engineering" (Moscow, 2009), Motorola Technology Day (SPb, 2007, 2010), "Технологии Microsoft в теории и практике программирования" (СПб, 2008, 2009, 2010), XXXVI неделя науки СПбГПУ (СПб, 2007), XXXIX неделя науки СПбГПУ (СПб, 2010).

Публикации. Основные положения диссертации изложены в 9 печатных работах, в том числе в двух работах в журналах из перечня ВАК.

Внедрение. Разработанные методы внедрены в компаниях ЗАО "Моторола ЗАО", ООО "ИЦ "Северо-Западная лаборатория" и использованы при разработке учебно-

методического комплекса СПбГПУ по курсам "Технология разработки программного обеспечения" и "Индустриальные технологии разработки ПО" на кафедре "Информационные и управляющие системы". Практическое использование представляемых на защиту результатов подтверждено соответствующими актами о внедрении.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы и трех приложений. Общий объём диссертации с приложениями - 169 страниц машинописного текста, содержит 62 рисунка, 11 таблиц, список литературы содержит 125 наименований.

СОДЕРЖАНИЕ РАБОТЫ

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

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

Рассмотрены особенности тестирования на основе моделей, проведен обзор методов создания тестовых сценариев на основе моделей, проанализированы достоинства и ограничения применимости данного подхода.

Проведен сравнительный анализ следующих инструментов тестирования на основе моделей, являющихся наиболее распространенными на рынке и информация по которым доступна в открытых источниках: GOTCHA-TCBeans, mbt, MOTES, TestOptimal, AGEDIS, ParTeG, Qtronic, Test Designer, Spec Explorer, UniTESK, инструментарий верификации и автоматизации тестирования VRS/TAT.

На основе проведенного анализа были сделаны следующие выводы по состоянию дел в области тестирования на основе моделей:

• Рассмотренные инструменты не используют высокоуровневые формальные нотации.

• Большинство изученных инструментов не поддерживает полный процесс проверки

качества ПО на основе моделей, состоящий из создания модели, ее верификации,

построения и исполнения тестов, анализа результатов тестирования, ограничиваясь реализацией только отдельных этапов этого процесса.

• По результатам сравнительного обзора современных инструментов тестирования на основе моделей инструментарий УК^/ТАТ был оценен как наиболее перспективный. Он объединяет целый набор методов и инструментов в единую технологическую цепочку, в которой каждый из инструментов реализует отдельный этап в рамках процесса создания модели, ее верификации, тестирования и анализа результатов тестирования.

• Технология УЯЭ/ТАТ имеет следующие ограничения и недостатки:

о трудоемкая ручная формализация модели базовых протоколов, которая к тому

же сложна для согласования с заказчиком; о отсутствие методов структурирования модели для возможности ее анализа по частям и на разных уровнях абстракции, что затрудняет применение технологии при работе с крупными проектами; о генерация трасс осуществляется по всему дереву поведения модели, что приводит к большому количеству ненужных трасс и длительному времени генерации;

о отсутствует возможность отслеживать соответствие между отдельными

требованиями и элементами создаваемой модели; о как следствие предыдущего пункта - сложность определения покрытия

требований в полученных тестовых сценариях, созданных по модели; о отсутствует возможность сокращения полученного набора трасс, поэтому исполняемый тестовый набор может содержать большое число избыточных тестов, покрывающих требования, уже покрытые другими тестами. Во второй и третьей главах представлены концепция, реализация и интеграция в технологию УЯв/ТАТ методов генерации тестовых сценариев на основе высокоуровневых иСМ-моделей, позволивших сократить трудоемкость процесса получения тестовых сценариев путем автоматизации отдельных этапов технологической цепочки и тем самым устранить отмеченные выше недостатки данной технологии.

В технологии УНБ/ТАТ в качестве высокоуровневой формальной нотации была выбрана нотация иСМ для описания последовательности действий системы в ответ на внешние воздействия пользователей или программных систем. Варианты использования отражают функциональность системы с точки зрения описания ее архитектуры. Дизайн системы в нотации иСМ представляет собой набор взаимодействующих между собой

диаграмм. В свою очередь, каждая из диаграмм сосредоточена на описании взаимодействия компонентов (агентов, процессов системы), объектов, наблюдателей и подсистем. Каждый компонент или подсистема содержит элементы ответственности (Responsibilities), соответствующие событиям в системе, а также упорядоченную последовательность их возникновения. Таким образом, совокупность компонентов и диаграмм дает пользователю наглядное представление поведения системы и взаимодействий между ее компонентами. На рис. 1 изображена одна из UCM-диаграмм проекта автомобильного радио, на которой описано взаимодействие двух компонентов: пользователя (User) и радио (Radio). Сценарии взаимодействия изображены линиями поведения, нагруженными элементами UCM (например, Responsibility, Timer, Stub), порядок следования которых определен направленностью линий. При нажатии пользователем кнопки включения радио (событие Button_On) радио начинает работу (событие Radio On), происходит инициализация настроек (поведение описывается на диаграмме Stublnitialize). После этого пользователю становятся доступны следующие функции работы с радио: изменение громкости, частоты, переключение диапазонов, автопоиск станций, сохранение станций в памяти радио. Сценарии поведения при выборе каждой из функций описываются на отдельных UCM-диаграммах соответствующих элементов Stub. При нажатии пользователем кнопки выключения радио (событие Button_Off) радио завершает работу (событие Radio Off).

Рис. 1. liCM-диаграмма проекта автомобильного радио

Инструменты верификации и автоматизации тестирования в технологии VRS/TAT работают с формальными моделями, представленными в нотации базовых протоколов на основании принципов инсерционного программирования, разработанного A.A. Летичевским. Базовый протокол описывает переход в модели и определяется тройкой а —к Р > ß, где а и ß - пред- и постусловие соответственно, а Р - процесс базового протокола. Условия а и ß представляются с помощью логических выражений некоторого базового языка и определяют условия на множестве состояний модели.

Последовательность базовых протоколов (трасса) определяет историю функционирования модели, характеризующую ее поведение: s0——h''2 где so,

.vi ... - состояния модели; bp\, bpi - базовые протоколы. Каждая трасса может быть использована в качестве тестового сценария.

Основные преимущества UCM по сравнению с нотацией базовых протоколов -близость к формулировке исходных требований, понимание и возможность контроля заказчиком, согласование с ним в терминах событий различных режимов поведения разрабатываемой системы. Недостатки - отсутствие инструментальной поддержки проверки корректности создаваемой модели поведения и автоматической генерации из нее тестовых сценариев. Преимущества нотации базовых протоколов - возможность доказательства свойств модели, проверка ее корректности с помощью мощных инструментов верификации VRS и автоматическое создание символических тестовых сценариев по проверенной корректной модели для последующей генерации исполняемых тестов. Недостатки -сложность для создания, визуального восприятия и согласования с заказчиком и специалистами в предметной области. Интеграция двух нотаций их взаимно дополняет, т.е. недостатки одной модели устраняются преимуществами другой. К тому же возможность автоматического преобразования UCM в нотацию базовых протоколов сокращает трудозатраты в случае корректировки исходных требований.

В рамках подхода с двумя формальными моделями в единой технологии тестирования были разработаны методы генерации тестовых сценариев на основе структурированных UCM-моделей проектируемой системы, интегрированные в технологическую цепочку VRS/TAT. Всего можно выделить 6 методов, каждый из которых устраняет одно из сформулированных выше ограничений данной технологии и позволяет сократить трудоемкость процесса получения тестовых сценариев путем автоматизации соответствующего этапа. На рис. 2 приведена схема обновленной технологической цепочки VRS/TAT после интеграции с разработанными методами, выделенными жирными линиями.

Рис. 2. Внедрение разработанных автором методов в технологическую цепочку VRS/TAT

Метод 1 - автоматическое создание формальной модели базовых протоколов но

нотации UCM заключается в преобразовании компонентов и элементов UCM в базовые протоколы. При этом используются метаданные, которые могут быть добавлены практически ко всем элементам UCM-диаграммы, что позволяет перенести всю необходимую информацию из требований в UCM-дизайн. Метаданные представляют собой неограниченный набор расклассифицированных маркерами данных формата: "Маркер" -"Текстовая информация заданного типа", где каждый маркер соответствует определенному типу информации и управляет созданием определенного элемента базового протокола.

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

Метод 2 - структурирование формальной модели заключается в преобразовании UCM-модели, факторизованной элементами Stab, в модель базовых протоколов, факторизованную расширенными протоколами, интерпретирующими эти элементы Stub.

Когда UCM-диаграмма, изображающая поведение всей системы или ее фрагмента, становится слишком сложной для визуального восприятия и анализа, она структурируется с

помощью элементов Stub. Часть описания поведения системы выносится на отдельную диаграмму, его место занимает элемент Stub и исходная UCM-диаграмма верхнего уровня рассматривается как главная диаграмма, а остальные диаграммы - как поддиаграммы. Поддиаграммы могут также содержать элементы Stub. Чем сложней поведение системы, тем больше будет создаваться уровней вложенности, реализуемых элементами Stub.

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

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

Структурирование состоит из трех основных этапов.

1) Для каждой UCM-диаграммы из исходного проекта создается директория в проекте базовых протоколов с соответствующим именем:

VDMC, е S_PROJ,DIRDIíG = CREATE_DIR(DIAG¡),DIRDUa¡ e T PROJ

где DIA G( UCM диаграмма исходного проекта, S PROJ- исходный проект, DIRmíG -директория целевого проекта, Т PROJ- целевой проект.

В директорию DIRduc помещаются базовые протоколы, соответствующие элементам Responsibility на исходной диаграмме DIA Gi.

2) Если UCM-диаграмма содержит один или несколько элементов Stub, то в соответствующей директории создается директория ЕР:

VDIRDUGi е T_PROJ,DIRDMG ,,,, = CREATE _DIR(DIAG _ЕР:), DIR UUG tv, е T_PROJ где DIRdug - директория целевого проекта, DIRdiag и, - директория целевого проекта

внутри директории DIRüiag , Т _PROJ - целевой проект.

В директорию DIRBUC помещаются расширенные протоколы, которые представляют детальное поведение, описываемое внутри элементов Stub, на диаграмме более высокого уровня, т.е. на той диаграмме, где элемент Stub расположен.

3) Если UCM-диаграмма содержит несколько компонентов, то в соответствующей директории DIRduo создается директория ¡Connectors:

4DIRduü е Т _PROJ,DIRdiic. сощ = CREA ТЕ _ DIR(DIA G ^ CONN,), DIRl)Ua сащ s Т _PROJ

где DIRdiag - директория целевого проекта, DIRIMC r()vv - директория целевого проекта

внутри директории DIRÜUC , Т PROJ - целевой проект.

В директорию DIRoua сош помещаются протоколы-коннекторы, которые сохраняют поток управления при переходах между компонентами. В трассах эти протоколы-коннекторы будут связывать базовые протоколы, полученные по элементам Responsibility, принадлежащим разным компонентам на UCM-диаграмме.

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

Метод 3 - автоматическое создание эвристик для генерации по ним тестовых сценариев. Поведение модели S(P), представленной базовыми протоколами, в состоянии ОС описывается уравнением, выведенным А.А.Летичевским:

S« = XprocO^Tta.p^A^S.,.^ + £proc(p)*(T(a,p): A)*(ST(a„, +&)

ре Г* la) /«/•"(«)

где ргос(р) - процесс базового протокола; Т(а,р) = Tr(a,post(p)) - предикатный трансформер, позволяющий учитывать изменение состояния модели после применения базового протокола; post(p) - постусловие базового протокола.

Графически данное уравнение представляет собой пучок трасс, в котором каждое следующее состояние системы раскладывается в новый пучок трасс. Поведение системы описывается пучками трасс, в которых переходы являются базовыми протоколами. Если представить дерево поведения высоты L, вершинами которого являются состояния системы S, а стрелки, выходящие из вершины, помечены базовыми протоколами, которые могут быть применимы к соответствующему состоянию, то количество трасс будет равно количеству листьев этого дерева. Например, пусть система описана N базовыми протоколами и в каждом состоянии системы (на каждом шаге поведения) может примениться любой из этих N базовых протоколов, тогда общее количество трасс оценивается экспонентой NL. Даже в случае относительно небольшой системы, формализуемой N=100 базовыми протоколами, общее количество трасс длины L=10 базовых протоколов будет равно 100111. Задача полного обхода такого дерева поведения нереальна, также как и получение и исполнение набора тестов для всех поведений системы. Для выбора среди них тех, которые считаются (по согласованию с заказчиком) основными, критическими, покрывающими наиболее важные сценарии функционирования системы, А.В.Колчиным был разработан язык эвристик, позволяющий пользователю задавать направление поиска трасс для тестовых сценариев при обходе пространства поведения модели. Таким образом, существенно ограничивается пространство поиска от одной промежуточной цели до другой, т.е. от одного события в тестовом сценарии до другого. При использовании эвристик количество получаемых трасс оценивается с помощью формулы:

N^ +Nlh~k' +N2k,'k* + ... + JV,i~t|, k, < L,N, < N где к, - уровень глубины дерева поведения, на котором задан элемент, через который должен пройти трассовый генератор, /V - количество базовых протоколов, применимых между двумя промежуточными точками, I - количество заданных промежуточных точек. Таким образом, чем подробней эвристика, тем быстрее будет сгенерирован соответствующий тестовый сценарий.

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

Метод создания эвристик по набору MSC-диаграмм.

1) По UCM-диаграммам автоматически создаются наборы MSC, каждая из которых описывает одно из возможных поведений на UCM-диаграмме.

2) Каждая эвристика формируется в соответствии с последовательностью базовых протоколов в одной MSC-диаграмме.

3) По эвристикам создается файл с эвристиками:

\fMSC, е MSC_ DIR J, GUIDE №С = CREA TE _ GUIDE(MSCl ), GUIDE MSC/ e GUIDES _ FILEmc ш где MSCt - MSC-диаграмма из директории MSC_ DIRj, GUIDEюс - эвристика,

полученная по диаграмме MSC;, GUIDES FILEMSC Dm- файл с эвристиками по всем

MSC-диаграммам директории MSC_DIRf.

Таким образом, количество эвристик будет равняться количеству MSC-диаграмм, т.е. числу возможных поведений на каждой UCM-диаграмме.

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

1) Для каждой критериальной цепочки из файла с цепочками по всей структуре директорий с MSC-диаграммами, полученными по целому UCM-проекту, осуществляется поиск последовательности базовых протоколов, указанной в цепочке.

2) Если последовательность будет найдена, то сгенерируется эвристика, соответствующая данной критериальной цепочке, иначе соответствующая эвристика сгенерирована не будет:

VCHAIN, 6 FILE_CHA¡NS:

IF(CHAIN, 6 {MSCMSCj}),THEN(GUIDEalw = CREATE_GUlDE(CHAINi)), GUIDE CII!IN e GUIDES _FlLEmE_aum

где CHAIN, - критериальная цепочка из файла с цепочками FILE CHAINS, GU1DECUUS -эвристика, соответствующая цепочке CHAINп GUIDES FILEVUL aWfts- файл с эвристиками по всем критериальным цепочкам, которые были найдены во всех MSC-диаграммах {MSC,,...,MSC, полученных по UCM-проекту.

3) При этом в методе поддерживается структурирование модели: если базовые протоколы цепочки находятся на UCM-диаграммах разных уровней абстракции и, соответственно, в MSC-диаграммах, расположенных в различных директориях, то данный факт будет учтен, и поиск выполнится на всех уровнях абстракции.

Инкрементальный метод создания эвристик.

1) Для каждой MSC-диаграммы, созданной как для UCM-диаграммы верхнего уровня, так и для UCM-диаграмм элементов Stob, в терминах исходных требований формулируется поведение, покрываемое в данной MSC-диаграмме.

2) Пользователь выбирает детальность, которая ему необходима в тестовом сценарии, и отмечает отдельным идентификатором те уровни детализации и поведения модели на этих уровнях, которые он хочет увидеть в эвристике и, соответственно, в трассе, которая в дальнейшем будет получена по данной эвристике.

3) По поведениям, отмеченным одинаковым идентификатором на различных уровнях детализации модели, будет получена одна эвристика:

V/D, ID е int:

IF(DEFINED({MSCi,...,MSCj}id s {UCMk,...,UCM¡}),{VCMk,..UCMS _PROJ),

THEN0GUIDE,o:CHAIN,MSCi.....e GUIDEid)

где ID - идентификатор эвристики, {MSCn...,MSCj}ID - набор отмеченных поведений, по которым требуется создать эвристику, {UCMk,...UCM,} - UCM-диаграммы исходного UCM-проекта S_PROJ, GUIDEю - получаемая эвристика, содержащая поведения, которые описаны в {MSCi,...,MSCj},ü.

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

Метод 4 - отслеживание соответствия между требованиями и элементами модели.

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

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

3) Отслеживается соответствие между событиями, характеризующими требования в терминах исходных спецификаций, и элементами модели (базовыми протоколами):

VREQ, е REQ_ВООК: V EVENT, е REQ, ,3 BP, s BP _ PRO J

где REQ, - требование из исходного документа требований REQ BOOK, EVENT, ~

наблюдаемое событие, характеризующее требование, BP/ - базовый протокол из проекта

базовых протоколов BP PROJ.

Разработанный автором метод позволяет однозначно определять тестовые сценарии, которые содержат элементы модели, связанные с выбранными требованиями; идентифицировать, каким сценарием покрывается то или иное требование; выявлять требования, которые еще не проверены ни одним сценарием.

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

\/CHAIN, е FILE CHAINS,VTRACE, e TRACES: IF (CHAIN, e TRACE ]), THEN(REQawfl = COVERED,,,,,, ), IF(CHA!N, g TRACES) jnEN(REQa,U4 =UNCOVEREDtkaces)

где CHAIN, - критериальная цепочка (последовательность базовых протоколов) из файла с

цепочками FILE_CHAINS, TRACEf - трасса из набора сгенерированных трасс TRACES ,

REQauis, ~ требование, проверяемое критериальной цепочкой CHAIN,, состояние

COVEREDmia; означает покрытие требования в трассе TRACE,, состояние

UNCO VEREDrKt(ls означает, что требование не было покрыто ни одной из трасс набора TRACES .

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

Метод 6 - сокращение тестового набора. Если трасса покрывает требования, уже учтенные в другой трассе, покрывающей большее количество требований, то первая трасса исключается из рассмотрения, таким образом, сокращая итоговый набор тестов: V TRA СЕ,, TRA СЕ/ е TRA CES : IF((REQÏ°!™:d с REQΙÏw)a (TRACE, > TRACE,)) THEN (TRA CE, i TRA CES0PT )

где TRACE,,TRACE j - трассы из набора сгенерированных трасс TRACES, - требования, покрытые в трассах TRACE,,TRACE, соответственно, TRACESоп- - оптимизированный набор трасс.

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

В четвертой главе представлены результаты внедрения разработанных методов в технологию верификации и автоматизации тестирования VRS/TAT. Проанализированы показатели эффективности применения в четырех различных проектах.

t Требования :ha проектируем^ j систем-/

1

и С м-мед ель **2

С тргуктууи риванна модель системы d виде Сазсаых протоколев __

ныв ||

—т

1_

Результат иценм покрытия требований а трассэ» по критериальным цепочкам ___

Hafijp трасс с символическими параметрами

оптимизированный набор трасс t символическими параметрами^

| Автоматическая генерация тестов

Исполнение тестов i-

диализ результатов тестирования

Оптимизированный нзСзр трасс с иим ц и ал нэ и рос эчи & ми параметрами

Рис. 3. Обобщенная схема применения разработанных методов

На рис. 3 приведена обобщенная схема применения разработанных методов, которая обеспечивает создание набора тестовых сценариев, покрывающих исходные требования на систему.

По требованиям на проектируемую систему вручную создается иСМ-модель системы (1), по которой автоматически генерируется структурированный набор базовых протоколов (2). Для каждого требования вручную создаются критериальные цепочки, т.е. формулируются последовательности событий, выполнение которых в указанном порядке свидетельствует о покрытии соответствующего требования (3). Затем автоматически генерируется файл с эвристиками (4), как на основании критериальных цепочек, так и по МБС-диаграммам, полученным по иСМ-модели, в зависимости от выбранного метода генерации. По эвристикам средствами УИЗ создается набор трасс (тестовых сценариев) с символическими параметрами (5). С помощью методов отслеживания соответствия между требованиями и элементами модели и поиска покрытия требований в соответствии с критерием цепочек выполняется оценка покрытия исходных требований (6). В случае неполного покрытия требований необходим анализ причин наличия непокрытых требований (7). Это может быть результатом некорректного создания иСМ-модели или же пробелов в формулировке критериальной цепочки. После коррекции модели или цепочек процесс повторяется с пункта (2) или (4) соответственно. Если степень покрытия требований удовлетворяет пользователя, то применяется метод сокращения набора символических трасс для получения оптимизированного набора (8).

Дальнейшие этапы инициализации символических сценариев конкретными значениями (9) и генерации по инициализированным сценариям исполняемых тестов, исполнения тестов на целевой платформе и анализа результатов тестирования (10) осуществляются средствами инструмента автоматизации тестирования ТАТ.

Предложенные в работе методы и реализующие их программные средства проверены на работоспособность в четырех реальных промышленных проектах: базовая станция системы, реализующей технологию СОМА (характеристики модуля: 148 требований, 205 базовых протоколов, порядка 10" возможных сценариев поведения; всего в проекте порядка 9000 требований); С ИОиТЕЯ - компонент телекоммуникационной сети, связывающий базовые станции с администратором базовых станций (характеристики компонента: 107 требований, 163 базовых протоколов, порядка 108 возможных сценариев поведения; всего в проекте порядка 5000 требований); модуль МРМ, решающий проблему совместимости между интерфейсами модемов и контроллера станции приемопередатчика, в рамках проекта WiMAX (характеристики модуля: 51, 283, Ю10; всего в проекте порядка 12000 требований);

8_НМ1 - проект электронного табло в кабине машиниста поезда метрополитена (57, 497, 10'2).

Полученные результаты приведены в таблице 1 (колонка 1 - Трудоемкость разработки тестовых сценариев на основе моделей при использовании технологии УЯЗ/ТЛТ после интеграции разработанных методов (человеко-недель); колонка 2 - Трудоемкость существующей разработки тестовых сценариев без использования моделей (человеко-недель); колонка 3 - Трудоемкость создания формальной иСМ-модели и генерации модели базовых протоколов с помощью разработанного метода (человеко-дней); колонка 4 -Трудоемкость создания формальной модели базовых протоколов вручную (человеко-дней); колонка 5 - Кол-во трасс, покрывающих требования; колонка 6 - Оптимизированный набор трасс):

Таблица 1. Результаты применения разработанных методов

Проект 1 2 Оценка сокращения трудоемкости (%) 3 4 Оценка сокращения трудоемкости (%) 5 6 Оценка сокращения набора трасс (%)

С_ЯОиТЕЯ 1,8 5,9 69 4 6 33 113 49 56

СОМА 2,2 5,7 61 5 8 37 163 26 84

МРМ 2,1 6,3 67 5 10 50 51 51 0

3_НМ1 2,8 7 60 7 18 61 223 195 12

1. Преимущество применения технологической цепочки УЯЗ/ТАТ (после интеграции разработанных методов) по сравнению с традиционным подходом к разработке тестовых сценариев без использования моделей: 60%-ное сокращение трудоемкости (рис. 4).

Н1 5 з *

Р Л « в * 1

И 4

* а 2

I1*

8 Я 2,

I *

° г-з3 I *

♦"^»Трудов м кость

Р = = рз5оТКИТ£СТСБЫ*. гцгнаркеенз 0::гр£« моделей при н:пользовании технологии \«й5/ТАТ после интеграция pj.jp» Вотанных методов

•"'^«■■•Трудоемкость существу кхце й р зз рз 5откн тестс 5а* ецгмариевбез ИьП0ЛЬ5С-вания.

моделей

м 3,3 I*

§ 7Э

Я

* Опенка сокращения трудоемкости

(%)

С.аОШЕЙ СОМА мам

Название проекта

Рис. 4. Сравнение трудоемкости разработки тестовых сценариев при различных подходах 2. Сокращение в среднем на 45% трудоемкости создания формальной модели базовых протоколов инструментом 11СМ2ВР по сравнению с ручной разработкой (рис. 5). При

этом с увеличением количества базовых протоколов показатель сокращения трудоемкости растет (рис. 5), так как при ручном создании формальной модели трудоемкость увеличивается быстрее, чем при автоматизированном построении модели.

Трудоемкость создания формальной модели с псмошью разработанного метода (человеко-дней) ~@~Трудое\гт сть создания формальной модели вручную (человйсо-днеЙ)

Количество базовых протоколов

—«—Оценка

сокращенпя .............. трудоемкости

.............. <Н)

............... • • • • • Аппроксимация

............................сокращения

............... трудоемкости

О 200 4СС 6С0 SCO

Количество базовьп: протоколов

Рис. 5. Сравнение трудоемкости создания формальной модели

3. В итоговом наборе тестовых сценариев количество трасс, сгенерированных по эвристикам, было сокращено более чем на 80% в проекте CDMA. Данный показатель зависит от длины критериальных цепочек и детальности эвристик по отношению к критериальным цепочкам. Если цепочки короткие (один или несколько протоколов), а эвристика описывает длинный сценарий поведения, то возможно покрытие трассой, полученной по данной эвристике, сразу нескольких цепочек. В случае же длинных подробных цепочек эвристика будет совпадать с цепочкой по количеству базовых протоколов, и существенное сокращение количества тестовых сценариев станет невозможным.

4. Трудоемкость повторного цикла применения технологической цепочки для получения новых актуальных тестовых сценариев при изменениях в исходных требованиях значительно сокращается.

5. Применение UCM-моделей на начальном этапе формализации требований позволяет гораздо эффективней взаимодействовать с заказчиком для согласования дальнейших этапов проверки качества разрабатываемого ПО.

ЗАКЛЮЧЕНИЕ

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

Основные результаты, полученные в ходе выполнения работы:

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

2. Разработаны и интегрированы в технологию VRS/TAT методы сокращения трудоемкости процесса получения тестовых сценариев:

• автоматическое построение по UCM-модели структурированной формальной модели в виде базовых протоколов;

• автоматическое создание эвристик;

• отслеживание соответствия между требованиями и элементами модели;

• поиск покрытия требований в соответствии с критерием цепочек наблюдаемых событий;

• сокращение набора тестовых сценариев.

3. Усовершенствованная технология VRS/TAT после интеграции разработанных методов была применена в четырех крупных телекоммуникационных проектах в компаниях ЗАО "Моторола ЗАО" и ООО "ИЦ "Северо-Западная лаборатория" и доказала свою высокую эффективность для обеспечения проверки качества разрабатываемого ПО, обеспечив более чем 60%-ное сокращение трудоемкости разработки тестовых сценариев по сравнению с традиционным подходом без использования моделей.

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

СПИСОК ПУБЛИКАЦИЙ ПО ТЕМЕ ДИССЕРТАЦИИ

1. Воинов Н.В., Котляров В.П. Верификация и автоматизация тестирования UML-проектов // Научно-технические ведомости СПбГПУ. №3(80). СПб.: Изд-во Политехнического ун-та. - 2009. - С. 220-225. (издание из перечня ВАК)

2. Воинов Н.В., Котляров В.П. Применение метода эвристик для создания оптимального набора тестовых сценариев//Научно-технические ведомости СПбГПУ. №4(103). СПб.: Изд-во Политехнического ун-та. - 2010. - С. 169-174. (издание из перечня ВАК)

3. Воинов Н.В., Веселое А.О., Котляров В.П. Автоматизация тестирования UML проектов // Вычислительные, измерительные и управляющие системы. Сборник научных трудов. СПб.: Изд-во Политехнического ун-та. - 2007. - С. 57-65.

4. Воинов Н.В., Котляров В.П. Методика автоматизации тестирования проектов, специфицированных средствами UML//Технологии Microsoft в теории и практике программирования. Материалы межвузовского конкурса-конференции студентов, аспирантов и молодых ученых Северо-Запада. 17-18 марта 2009 г. СПб.: Изд-во Политехнического ун-та. - 2009. - С. 84-85.

5. Воинов Н.В., Котляров В.П. Применение метода оптимизации обхода пространства поведения формальной модели для генерации тестовых сценариев//Технологии Microsoft в теории и практике программирования. Материалы межвузовского конкурса-конференции студентов, аспирантов и молодых ученых Северо-Запада. 16-17 марта 2010 г. СПб.: Изд-во Политехнического ун-та. - 2010. - С. 139-140.

6. Воинов Н.В., Веселов А.О., Котляров В.П. Технология генерации тестовых наборов из UML спецификаций // Технологии Microsoft в теории и практике программирования. Материалы межвузовского конкурса-конференции студентов, аспирантов и молодых ученых Северо-Запада. 11-12 марта 2008 г. СПб.: Изд-во Политехнического ун-та. - 2008. - С. 22-24.

7. Здробилко С.Н., Воинов Н.В. Автоматизированная формализация функциональных требований ХМРР сервера // XXXVIII Неделя науки СПбГПУ. Материалы межвузовской научно-технической конференции. 30 ноября - 5 декабря 2009 г. СПб.: Изд-во Политехнического ун-та. - 2009. - С. 100-102.

8. Синицкий Г.Ю., Воинов Н.В. Применение UCM нотации для автоматизации тестирования программного продукта//XXXIX Неделя науки СПбГПУ. Материалы межвузовской научно-технической конференции. 06-11 декабря 2010 г. СПб.: Изд-во Политехнического ун-та. - 2010. - С. 93-95.

9. Voinov N.. Kotlyarov V. Verification and Testing Automation of UML Projects // Proceedings of the Third Spring Young Researchers' Colloquium on Software Engineering. Vol. 3. Moscow, 2009. P. 41-45.

Лицензия ЛР № 020593 от 07.08.97

Подписано в печать 06.04.2011. Формат 60x84/16. Печать цифровая. Усл. печ. л. 1,0. Уч.-изд. л. 1,0. Тираж 100. Заказ 7437b.

Отпечатано с готового оригинал-макета, предоставленного автором, в Цифровом типографском центре Издательства Политехнического университета. 195251, Санкт-Петербург, Политехническая ул., 29. Тел.:(812)550-40-14 Тел./факс: (812) 297-57-76

Введение.

Глава 1. Обзор методов и средств тестирования на основе моделей.

1.1 Подходы к тестированию в промышленных программных проектах.

1.1.1 Подходы к повышению качества ПО.

1.1.2 Виды тестирования.

1.1.3 Обзор инструментов тестирования.

1.2 Тестирование на основе моделей.

1.2.1 Особенности подхода к тестированию на основе моделей.

1.2.2 Методы создания тестовых сценариев на основе моделей.

1.2.3 Преимущества и ограничения тестирования на основе моделей.

1.3 Сравнительный обзор инструментов тестирования на основе моделей.

1.3.1 Покрытие определенных элементов дерева поведения модели.

1.3.2 Покрытие входных значений переменных.

1.3.3 Отслеживание покрытия требований.

1.3.4 Поддержка работы с моделью и тестирования.

1.3.5 Автоматическое создание окружения тестирования.

1.3.6 Результаты сравнения инструментов тестирования на основе моделей.

1.4 Выводы.

Глава 2. Концепция методов генерации тестовых сценариев и их интеграция в технологии VRS/TAT.

2.1 Технологическая цепочка VRS/TAT и схема интеграции методов генерации тестовых сценариев.

2.2 Формальные модели в нотациях UCM и базовых протоколов.

2.2.1 Применение двух формальных нотаций в рамках одной технологии.

2.2.2 Основы нотации UCM.

2.2.3 Нотация базовых протоколов.

2.2.4 Преобразование компонентов и элементов UCM в базовые протоколы.

2.3 Метод структурирования пространства поведения формальной модели.

2.3.1 Генерация трасс.

2.3.2 Метод расширенных протоколов.

2.3.3 Факторизация поведения UCM-модели с помощью элемента Stub.

2.3.4 Интерпретация элемента Stub в виде расширенного протокола.

2.3.5 Подключение расширенного протокола к общему сценарию поведения системы с помощью протоколов-коннекторов.

2.3.6 Факторизация пространства поведения модели базовых протоколов.

2.4 Оценка сложности пространства поведения формальной модели и метод его сокращения для генерации тестовых сценариев.

2.4.1 Описания поведения системы, представленной в виде базовых протоколов.

2.4.2 Комбинаторный взрыв числа состояний.

2.4.3 Метод эвристик.

2.5 Формулировка критерия покрытия функциональных требований.

2.5.1 Измеряемость требований.

2.5.2 Структурный критерий покрытия требований.

2.6 Выводы.

Глава 3. Реализация методов генерации набора тестовых сценариев по структурированным формальным моделям.

3.1 Реализация методов создания и структурирования формальной модели.

3.1.1 Инструмент UCM2BP.

3.1.2 Режим UCM2MSC.

3.1.3 Структурирование формальной модели.

3.2 Реализация методов создания эвристик для получения тестовых сценариев.

3.2.1 Метод создания эвристик по набору MSC-диаграмм.

3.2.2 Метод создания эвристик по набору MSC-диаграмм и критериальным цепочкам

3.2.3 Инкрементальный метод создания эвристик.

3.3 Реализация методов оценки критериального покрытия и сокращения тестового набора

3.3.1 Реализация метода отслеживания соответствия между требованиями и элементами модели.

3.3.2 Реализация метода поиска покрытия требований в трассах.

3.3.3 Реализация метода сокращения тестового набора и разметка требований в трассах

3.4 Выводы.

Глава 4. Результаты применения разработанных методов генерации тестовых сценариев.

4.1 Обобщенная схема применения разработанных методов.

4.2 Применение разработанных методов в проекте CDMA.

4.3 Анализ результатов применения разработанных методов.

4.4 Выводы.

Актуальность работы. Одной из основных проблем разработчиков программного обеспечения (ПО) является проверка корректности функционирования ПО. Требования, предъявляемые к качеству ПО, становятся все более критичными, поскольку от функционирования автоматизированных систем управления зависит не только эффективность производства, но и жизни людей - особенно в таких областях, как транспорт, телекоммуникации, медицина и т.п. Из практики промышленного производства ПО известно, что проверка качества программного обеспечения начинается с разработки требований к проектируемой системе, продолжается до момента вывода системы из эксплуатации и занимает до 50% времени всего жизненного цикла ПО [32]. Этим определяется повышение требований к полноте и производительности подобных проверок.

Стоимость исправления ошибок в пределах жизненного цикла продукта растет экспоненциально в соответствии с фазой разработки [32]. Отсюда, самой эффективной стратегией является поиск и исправление большего числа ошибок на фазе разработки требований и спецификаций.

Рис. 1 Стоимость исправления ошибок в зависимости от стадии проекта

Как показывает рис. 1, гораздо сложнее исправить дефекты, которые найдены при эксплуатации продукта, чем в процессе его создания [33].

Следовательно, предотвращение ошибок в требованиях и обнаружение их на ранних этапах проекта сильно уменьшает объём корректировок продукта и таким образом сокращает общую стоимость разработки ПО. Поэтому возникает целевая установка: концентрироваться на поиске ошибок на самых ранних фазах жизненного цикла ПО, не дожидаясь их обнаружения в процессе тестирования готовой реализации [22]. Отвечая этой установке, в последнее время активно развиваются методы и инструменты тестирования на основе моделей.

Построение тестовых сценариев на основе моделей (model-based testing) использует формальные модели требований и спецификаций. Получаемые в результате тестовые сценарии обычно слабо связаны со специфическими особенностями кода тестируемой системы, но содержат представительный набор ситуаций с точки зрения исходной модели [17]. Несмотря на то, что реализации систем отличаются уровнем абстракции от своих моделей, такой подход позволяет автоматизировать процесс генерации тестов из формальных спецификаций системы и значительно сокращает трудозатраты на тестирование.

Однако создание формального описания систем — весьма трудоемкий процесс. Во-первых, свойственная на ранних стадиях проекта неполнота и изменчивость исходных требований затрудняет построение модели, требует перманентной коррекции формализации, и как следствие, привносит значительные временные затраты в выполнение проекта. Во-вторых, высокий уровень необходимых знаний в области математической логики, предъявляемый исполнителям, является дополнительным ограничивающим фактором, усложняющим внедрение формальных методов в процесс индустриальной разработки ПО. В-третьих, существует проблема крупных размеров современных систем, порождающая комбинаторный взрыв числа состояний модели при её проверке. Состояние проверяемой модели включает большое количество переменных и процессов. Даже если число процессов конечно и переменные могут принимать только конечное число значений, общее число состояний может быть очень большим. Реальные системы обычно используют параллельные процессы, а число состояний моделей параллельной системы растет экспоненциально с числом компонентов [16]. Как создание, так и анализ дерева поведения модели такой системы практически невозможны.

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

Сформулируем требования к подобным нотациям:

• во-первых, они должны предоставлять возможность внедрения методов для сокращения пространства поведения модели путем укрупнения детализации описания поведения, факторизации, композиции состояний;

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

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

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

Однако вопрос о том, в каком соотношении находятся показатели тестового покрытия модели и показатели покрытия основных требований к целевой системе, как правило, не рассматривается с точки зрения их семантического соответствия [16].

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

Отметим, что отдельно методы структурирования модели и отслеживания соответствия между требованиями и элементами модели для определения покрытия требований реализованы в различных инструментах тестирования на основе моделей (разделы 1.3.3 и 1.3.4). Однако эти инструменты не поддерживают другие важные функции, например, создание модели или исполнение тестов (разделы 1.3.1-1.3.5). В результате, рассмотренные в этих разделах инструменты не покрывают все этапы процесса проверки качества ПО, начиная от создания модели и заканчивая анализом результатов тестирования. Альтернативный подход - технология УЯБ/ТАТ, покрывающая все этапы процесса проверки качества, изложена в работах [1,2,48,11,12,19,20,29,30,31,69-72,121]. Основным преимуществом данной технологии является интегрирование целого набора методов и инструментов верификации и тестирования, каждый из которых реализует отдельный этап в рамках процесса создания модели, ее верификации, тестирования и анализа результатов тестирования, в единую технологическую цепочку. Такой подход делает УЯБ/ТАТ полностью самодостаточной технологией и избавляет пользователей от необходимости обращения к разработкам других фирм на отдельных этапах проверки качества разрабатываемого ПО. Результаты сравнительного анализа представленных на рынке инструментов тестирования на основе моделей (таблица 1.5 в разделе 1.3.6) свидетельствуют о более широких возможностях, предоставляемых УЯЗ/ТАТ в области проверки качества ПО.

Следует отметить пробелы, существовавшие в данной технологии до выполнения настоящей работы:

• отсутствие возможности отслеживания соответствия семантики между исходными требованиями и элементами создаваемой модели;

• как следствие, сложность определения покрытия требований в полученных тестовых сценариях, созданных по модели;

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

Реализация автором данных методов позволила усовершенствовать технологию УЯЗ/ТАТ и сделала ее применение более удобным и эффективным.

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

Настоящая работа посвящена разработке методов генерации тестовых сценариев на основе высокоуровневых иСМ-моделей проектируемой системы. В качестве базового инструментария в работе используется технология УЯЗ/ТАТ, которая является одним из наиболее перспективных современных инструментов верификации и автоматизации тестирования на основе моделей. Реализованные в работе методы позволили сократить трудоемкость процесса разработки тестовых сценариев путем автоматизации ручных этапов, устранив некоторые недостатки и ограничения в инструментарии УЯЗ/ТАТ и сделав его применение более эффективным.

Цели и задачи диссертационной работы. Целью диссертационной работы является сокращение трудоемкости процесса разработки тестовых сценариев путем применения высокоуровневых иСМ-моделей, контролируемых заказчиком. Сокращение трудоемкости осуществляется автоматизацией следующих этапов: преобразование иСМ-моделей в модели базовых протоколов; структурирование модели базовых протоколов; поиск определенных сценариев поведения модели; отслеживание соответствия между требованиями и элементами модели; поиск покрытия требований полученными тестовыми сценариями. Для достижения цели в работе решены следующие задачи:

• обоснование выбора высокоуровневой формальной нотации для контролируемого заказчиком описания программной системы на стадии ее дизайна;

• разработка методов и инструментов автоматического преобразования высокоуровневой формальной модели в формальную модель в нотации, с которой работают инструменты верификации и автоматизации тестирования (например, УЯ8/ТАТ);

• разработка методов структурирования формальной модели для возможности пошагового анализа по компонентам и на различных уровнях абстракции;

• формулировка критериев покрытия тестовыми сценариями набора функциональных требований на систему с возможностью отслеживания соответствия между требованиями и элементами модели;

• разработка методов и инструментальных средств построения тестовых сценариев, удовлетворяющих заданному критерию, на основе анализа формальной модели;

• разработка методов и инструментальных средств сокращения полученного набора тестовых сценариев;

• интеграция разработанных методов в технологическую цепочку УЯЗ/ТАТ;

• применение и проверка работоспособности предложенных методов и инструментальных средств в составе технологической цепочки VRS/TAT в крупных промышленных телекоммуникационных проектах. Предметом исследования являются методы и инструментальные средства тестирования на основе моделей.

Методы исследования. Для решения поставленных в работе задач используются теория инсерционного программирования, аппарат формальных спецификаций. Применяются стандарты языков Use Case Maps (UCM) и Message Sequence Charts (MSC).

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

Научные результаты и их новизна.

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

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

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

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

• Для применения критерия цепочек наблюдаемых событий были разработаны новые методы отслеживания соответствия между требованиями и элементами модели базовых протоколов и оценки покрытия требований набором тестовых сценариев по данному критерию, позволяющие определить качество покрытия до этапа создания исполняемых тестов и их исполнения на целевой платформе. Практическая значимость работы. На базе полученных научных результатов разработан комплекс программных средств, интегрированный в технологию VRS/TAT. Усовершенствованная технология VRS/TAT после интеграции разработанных методов была применена в ряде промышленных телекоммуникационных проектов и доказала свою высокую эффективность для обеспечения проверки качества разрабатываемого ПО, позволив сократить более чем на 60% трудоемкость разработки тестовых сценариев по сравнению с существующим подходом.

Апробация работы. Основные положения и результаты диссертационной работы доложены и обсуждены на международных научных конференциях "The Third Spring Young Researchers' Colloquium on Software Engineering" (Moscow, 2009), Motorola Technology Day (SPb, 2007, 2010), "Технологии Microsoft в теории и практике программирования" (СПб, 2008, 2009, 2010), XXXVI неделя науки СПбГПУ (СПб, 2007), XXXIX неделя науки СПбГПУ (СПб, 2010).

Публикации. Основные положения диссертации изложены в 9 печатных работах, в том числе в двух работах в журналах из перечня ВАК.

Внедрение. Разработанные методы внедрены в компаниях ЗАО "Моторола ЗАО", ООО "ИЦ "Северо-Западная лаборатория" и использованы при разработке учебно-методического комплекса СПбГПУ по курсам "Технология разработки программного обеспечения" и "Индустриальные технологии разработки ПО" на кафедре "Информационные и управляющие системы". Практическое использование представляемых на защиту результатов подтверждено соответствующими актами о внедрении.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы и трех приложений. Общий объём диссертации с приложениями - 169 страниц машинописного текста, содержит 62 рисунка, 11 таблиц, список литературы содержит 125 наименований.

Основные результаты, полученные в ходе выполнения работы:

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

2) Разработаны и интегрированы в технологию VRS/TAT методы сокращения трудоемкости процесса получения тестовых сценариев:

• автоматическое построение по UCM-модели структурированной формальной модели в виде базовых протоколов;

• автоматическое создание эвристик;

• отслеживание соответствия между требованиями и элементами модели;

• поиск покрытия требований в соответствии с критерием цепочек наблюдаемых событий;

• сокращение набора тестовых сценариев.

3) Усовершенствованная технология VRS/TAT после интеграции разработанных методов была применена в четырех крупных телекоммуникационных проектах в компаниях ЗАО "Моторола ЗАО" и ООО "ИЦ "Северо-Западная лаборатория" и доказала свою высокую эффективность для обеспечения проверки качества разрабатываемого ПО, обеспечив более чем 60%-ное сокращение трудоемкости разработки тестовых сценариев по сравнению с традиционным подходом без использования моделей.

Общий объем разработанного ПО, реализующего разработанные методы, составил около 600 килобайт на языках Perl и Java. Объем документации на разработанное ПО - более 100 страниц.

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

Заключение

Целью, достигнутой в результате диссертационной работы, являлось сокращение трудоемкости процесса разработки тестовых сценариев путем применения высокоуровневых иСМ-моделей, контролируемых заказчиком. Для достижения цели в работе решены следующие задачи:

1) Проведен сравнительный анализ 11 современных инструментов тестирования на основе моделей, выявлены основные недостатки и преимущества по сравнению с технологией УКЭ/ТАТ.

2) В качестве высокоуровневой формальной нотации выбрана нотация иСМ, изучены ее возможности и проанализированы преимущества перед другими формальными нотациями.

3) Разработан метод и инструменты автоматического преобразования иСМ-модели в формальную нотацию базовых протоколов, с которой работают инструменты верификации и автоматизации тестирования УКД/ТАТ.

4) Разработан метод структурирования формальной модели для возможности ее анализа по частям и на различных уровнях абстракции.

5) Применен критерий покрытия требований, основанный на выполнении последовательностей наблюдаемых событий, характеризующих требования.

6) Для оценки покрытия требований разработаны методы и инструменты отслеживания соответствия между требованиями и элементами модели и поиска покрытия требований в соответствии со сформулированным критерием.

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

8) Разработан метод и инструментальные средства сокращения полученного набора тестовых сценариев.

9) Разработанные методы интегрированы в технологическую цепочку VRS/TAT.

10) Для проверки работоспособности разработанные методы и инструментальные средства в составе технологической цепочки VRS/TAT были применены в четырех крупных промышленных телекоммуникационных проектах.

1. Баранов С.Н., Дробинцев П.Д., Летичевский A.A., Котляров В.П. Верификационная технология базовых протоколов для разработки и проектирования программного обеспечения // Программные продукты и системы. 2005. № 1(69). С. 25-28.

2. Бурдонов И.Б., Косачев A.C., Пономаренко В.Н., Шнитман В.З. Обзор подходов к верификации распределенных систем. Препринт Института системного программирования РАН, № 16, 2006. 61 с.

3. Веселов А.О., Котляров В.П. Автоматизация тестирования проектов в области телекоммуникаций // Научно-технические ведомости СПбГПУ. № 4. СПб.: Изд-во Политехнического ун-та, 2010. С. 180-185.

4. Веселов А.О., Иванов A.C., Тютин Б.В., Котляров В.П. Автоматизация тестирования телекоммуникационных приложений // Научно-технические ведомости СПбГПУ. № 3. СПб.: Изд-во Политехнического ун-та, 2009. С. 208212.

5. Воинов Н.В., Веселов А.О., Котляров В.П. Автоматизация тестирования UML проектов // Вычислительные, измерительные и управляющие системы. Сборник научных трудов. СПб.: Изд-во Политехнического ун-та. 2007. - С. 57-65.

6. Воинов Н.В., Котляров В.П. Верификация и автоматизация тестирования UML проектов // Научно-технические ведомости СПбГПУ. № 3. СПб.: Изд-во Политехнического ун-та, 2009. С. 220-225.

7. Воинов Н.В., Котляров В.П. Применение метода эвристик для создания оптимального набора тестовых сценариев // Научно-технические ведомости СПбГПУ. № 4 (103). СПб.: Изд-во Политехнического ун-та. 2010. - С. 169174.

8. Дробинцев П.Д. Интегрированная технология обеспечения качества программных продуктов с помощью верификации и тестирования. Диссерт. на соискание уч. ст. канд. техн. наук. СПб.: СПбГПУ, 2006. 238 с.

9. Карпов Ю.Г. Model Checking. Верификация параллельных и распределенных программных систем. "БХВ-Петербург", 2010. 560 с.

10. Кознов Д.В., Арчак H.A. Апробация технологии тестирования UniTesK // Системное программирование. / Под ред. проф. А.Н.Терехова и Д.Ю.Булычева. СПб : Изд СПбГУ, 2004. С. 335-348.

11. Колчин A.B. Разработка инструментальных средств для проверки формальных моделей асинхронных систем. Диссерт. на соискание уч. ст. канд. физ.-мат. наук. Киев, 2009. 140 с.

12. Кулямин В.В. Методы верификации программного обеспечения // Всероссийский конкурсный отбор обзорно-аналитических статей по приоритетному направлению "Информационно-телекоммуникационные системы". 2008. 117 с.

13. Кулямин В.В., Петренко А.К., Косачев A.C., Бурдонов И.Б. Подход UniTesK к разработке тестов // Программирование. 2003. - №29(6). С. 25-43.

14. Летичевский A.A. Верификация и тестирование интерактивных систем, специфицированных базовыми протоколами. Диссерт. на соискание уч. ст. канд. физ.-мат. наук. Киев, 2005. 138 с.

15. Летичевский A.A., Капитонова Ю.В., Волков В.А., и др. Спецификация систем с помощью базовых протоколов // Кибернетика и Системный Анализ. 2005. №4. С. 3-21.

16. Никифоров И.В., Петров A.B., Юсупов Ю.В. Генерация формальной модели системы по требованиям, заданным в нотации Use Case Map // Научно-технические ведомости СПбГПУ. № 4. СПб.: Изд-во Политехнического ун-та, 2010. С. 191-195.

17. Петренко А.К., Бритвина E.H., Грошев С.Г., Монахов A.A., Петренко О.Л. Тестирование на основе моделей // Открытые системы. 2003. - № 9. http://www.osp.ru/os/2003/09/183388/*

18. Abrial J.-R. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. 813 p.

19. AGEDIS // http://www.agedis.de/

20. Последняя проверка актуальности приведенных ссылок 22.02.2011

21. Ambert F., Bouquet F., Chemin S., Guenaud S., Legeard B., Peureux F., Vacelet N., Utting M. BZ-TT: A tool-set for test generation from Z and B using constraint logic programming. Proc. of FATES'2002 August 2002. P. 105-119.

22. Ammann P., Black P. E. Abstracting formal specifications to generate software tests via model checking. Proc. of 18-th Digital Avionics Systems Conference, IEEE, October 1999 Vol.2. P. 10.A.6-1-10.A.6-10.

23. Artisan Studio // http://www.artisansoftwaretools.com/products/artisan-studio/

24. Boehm B. Software risk management: principles and practices. Software, IEEE, 8(1), 1991. P. 32-41.

25. Booch Gr., Maksimchuk R., Engel M., Young B., Conallen J., Houston K. Object-Oriented Analysis and Design with Applications. Addison-Wesley Professional; 3rd edition, 2007. 720 p.

26. Borland Together // http://www.borland.com/us/products/together/index.html

27. Boyapati C., Khurshid S., Marinov D. Korat: automated testing based on Java predicates. Proc. of International Symposium on Software Testing and Analysis, 2002. P. 123-133.

28. Brinksma E. A theory for the derivation of tests. Proc. of 8-th International Conference on Protocol Specification, Testing and Verification, North Holland, 1988. P. 63-74.

29. Broy M., Jonsson B., Katoen J.-P., Leucker M., Pretschner A. (eds.). Model Based Testing of Reactive Systems. LNCS 3472, Springer, 2005. 659 p.

30. Buhr R. J. A., Casselman R. S. Use Case Maps for Object-Oriented Systems, Prentice Hall, 1995. 302 p.

31. Eclipse // www.eclipse.org/

32. Engel C., Hahnle R. Generating unit tests from formal proofs. Y. Gurevich, B. Meyer, eds. Proc. of TAP 2007. LNCS 4454, Springer-Verlag, 2007. P. 169-188.

33. Enterprise Architect // http://www.sparxsvstems.com.au/

34. Enterprise JavaBeans // http://www.oracle.com/technetwork/topics/eib3Q-092128.html

35. Everette R. Keith. Agile Software Development Processes: A Different Approach to Software Design. 25 p. www.cs.nvu.edu/courses/spring03/V22.0474-001/lectures/agile/AgileDevelopmentDifferentApproach.pdf

36. Farchi E., Hartman A., Pinter S. S. Using a model-based test generator to test for standard conformance. IBM Systems Journal, 41(1), 2002. P. 89-110.

37. Fernandez J.-C., Jard C., Jeron T., Viho C. Using On-the-Fly Verification Techniques for the Generation of Test Suites. Proc. of 8-th International Conference on Computer Aided Verification, LNCS 1102, Springer, 1996. P. 348-359.

38. Futatsugi K., Goguen J. A. Principles of OBJ2. In: 12th ACM Symp. on Principles of Programming Languages. - New Orleans, 1985. P. 52-66.

39. Gargantini A., Heitmeyer C. Using model checking to generate tests from requirements specifications. ACM SIGSOFT Software Engineering Notes, 24(6), November 1999. P. 146-162.

40. GOTCHA-TCBeans // www.haifa.ibm.com/proiects/verification/gtcb/index.html

41. Gotlieb A., Botella B., Rueher M. Automatic test data generation using constraint solving techniques. ACM SIGSOFT Software Engineering Notes, 23(2), 1998. P. 53-62.

42. GraphML // http ://graphml. graphdrawing.org/51 . GraphXML // http://strategoxt.org/Transfon-n/GraphXML

43. Gurevich Y. Evolving Algebras: An Introductory Tutorial. Bulletin of the European Association for Theoretical Computer Science 43:264-284, February 1991.

44. Guttag J., Horning J. Larch: Languages and Tools for Formal Specification. -Heidelberg: Springer-Verlag, 1993. 250 p.

45. HP QuickTest Professional //https://hl0078.wwwl.hp.com/cda/hpms/display/main/hpms content.jsp?zn=bto&cp:= 1-11-127-24A1352 4000 100

46. Hoare C.A.R. Communicating sequential processes, Prentice Hall, London, 1985.260 p.

47. Huima A., Invited Talk: Implementing Conformiq Qtronic. Lecture Notes in Computer Science, 2007, Volume 4581, Testing of Software and Communicating Systems. P. 1-12.

48. IBM Rational SDL Suite http://www-01 .ibm.com/software/awdtools/sdlsuite/

49. IBM Rational Software Architect (RSA) // http://www-01 .ibm.com/software/awdtools/architect/swarchitect/

50. IBM Rational Software Modeler (RSM) // http://www-01 .ibm.com/software/awdtools/modeler/swmodeler/

51. IBM Rhapsody // http://www-01.ibm.com/software/awdtools/rhapsody/

52. ISO TC97/SC21, Estelle—A Formal Description Technique Based on an Extended State Transition Model, 1988. International Standard 9074.

53. ITU-T Recommendation Z.100, CCITT Specification and Description Language (SDL), 03/93.

54. ITU Recommendation Z.120. Message Sequence Charts (MSC), 11/99.

55. JUnit II http://www. junit.org/

56. Kull A. PhD Thesis: Model Based Testing of Reactive Systems, Thesis, Tallinn University of Technology, Faculty of Information Technology, 2009. 101 p.

57. Larman C., Basiii V. Iterative and Incremental Development: A Brief History, Computer, vol. 36, no. 6, June 2003. P. 47-56.

58. Letichevsky A.A., Kapitonova J.V., Volkov V.A., Vyshemirskii V.V., Letichevsky Jr. A.A. Insertion Programming // Cybernetics and Systems Analysis, Volume 39, Issue 1 (January 2003). P. 16-26.

59. Letichevsky A.A., Kapitonova J.V., Volkov V.A., Letichevsky Jr A.A., Baranov S.N., Kotlyarov V.P., Weigert T. System Specification with Basic Protocols // Cybernetics and Systems Analysis, Volume 41, Issue 4 (July 2005). P. 479-493.

60. LoadRunner // http://software-testing.rU/library/vendors/l41 -loadrunner/

61. MDL // http://verifV.stanford.edu/dill/murphi.html

62. MessageMagic // http://www.elvior.ee/messagemagic/general

63. Microsoft Solutions Framework (MSF) // http://www.microsoft.com/rus/msdn/msf/

64. Milner R. Communication and Concurrency. Prentice Hall, 1989. 272 p.80. MOTES // www.elvior.ee

65. Myers G. J. The Art of Software Testing. John Wiley & Sons, 1979. 192 p.

66. NUnit // http://www.nunit.org/

67. Objecteeing // http://www.obiecteering.com/

68. OCL // http://lcm.csa.iisc.ernet.in/soft arch/OCL.htm

69. OMG Unified Modeling Language http://www.omg.Org/spec/UML/2.2/

70. ParTeG // http://parteg.sourceforge.net

71. Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software, version 1.1. // CMU/SEI-93-TR-024, February, 1993. 82 p.

72. Pezze M., Young M. Software Testing and Analysis: Process, Principles and Techniques, Wiley, 2007. 488 p.

73. Pex: Microsoft Research // http://research.microsoft.com/en-us/projects/pex/

74. Poseidon // http://www.gentleware.com/91. QARun //http://supportline.microfocus.com/documentation/ASQ/QARunDocs.aspx/

75. Qtronic // www.conformiq.com

76. RAISE // http://www.iist.unu.edu/raise

77. Rational Robot // http://www-01 .ibm.com/software/awdtools/tester/robot/

78. Rising L, Janoff NS. The scrum software development process for small teams. IEEE Software, 2000;(4):2-8.

79. RUP (Rational Unified Process ) //http://www.augustana.ab.ca/~mohri/courses/2000.winter/csc220/papers/rupbestpra ctices/rup bestpractices.html

80. Sen K., Agha G. CUTE and jCUTE: Concolic unit testing and explicit path model-checking tools. Proc. of Computer Aided Verification, Aug 2006. P. 419-423.

81. Shafique M., Labiche Y. A Systematic Review of Model Based Testing Tool Support. Carleton University, Technical Report, May 2010. 21 p.99. SOATest//http://www.parasoft.com/isp/solutions/soa solution.isp;jsessionid-aaa7EAlvipZLSd? itemld=319

82. Spec Explorer: Microsoft Research // http://research.microsoft.com/specexplorer

83. Spec Explorer: MSDN // http://msdn.microsoft.com/en-us/library/ee62041 l.aspx

84. Spy editor // http://www.altova.com/xml-editor/

85. Telelogic TAU G2 // http://www.telelogic.com/products/tau/tau/index.cfm/

86. Telelogic TTCN Suite // http://www.telelogic.com/products/ttcn/index.cfiTi/

87. TestArchitect // http://www.logigear.com/services/test-automation/turnkey-global-test-automation-with-testarchitect.html/

88. TestOptimal // www.testoptimal.com

89. Test Designer // www.smartesting.com

90. Test RealTime // http://www-01 .ibm.com/software/awdtools/test/realtime/

91. TopCased // http://www.topcased.org/

92. Tretmans J. A Formal Approach to Conformance Testing. PhD thesis, University of Twente, Enschede, The Netherlands, 1992. 282 p.

93. Tretmans J., Belinfante A. Automatic testing with formal methods. Proc. Of 7th European Conference on Software Testing, Analysis and Review, Barcelona, Spain, November 1999. P. 8-10.

94. The Z Notation: a reference manual // http://spivey.oriel.ox.ac.uk/mike/zrm/

95. UniTESK // http://www.unitesk.ru/

96. UPPAAL // http://www.uppaal.com/

97. Uppaal CORA // http://www.es.aau.dk/~behrmann/cora/

98. Use Case Map Navigator http://iucmnav.softwareengineering.ca

99. Utting M., Pretschner A., Legeard B. A Taxonomy of Model-Based Testing. Technical Report, Department of Computer Science, The University of Waikato, New Zealand, 2006. 17 p.

100. Utting M., Legeard B. Practical Model-Based Testing: A Tools Approach. Morgan-Kaufmann, 2007. 456 p.

101. VDM // http ://www.vienna.cc/e/evdm.htm

102. Visser W., Pasareanu C. S., Khurshid S. Test input generation with Java PathFinder. ACM SIGSOFT Software Engineering Notes, 29(4), July 2004. P. 97107.

103. Voinov N., Kotlyarov V. Verification and Testing Automation of UML Projects // Proceedings of the Third Spring Young Researchers' Colloquium on Software Engineering. Vol. 3. Moscow, 2009. P. 41-45.

104. WinRunner // http://www.cbueche.de/WinRunner%20User%20Guide.pdf

105. XMI // http://www.omg.org/spec/XMI125. yED // http://www.vworks.com