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

На правах рукописи

ГРИППА Генри Леонидович

Автоматизация тестирования программных приложений методом ключевых состояний

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

Автореферат

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

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

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

Научный руководитель - доктор технических наук, профессор Черноруцкий Игорь Георгиевич

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

Александров Анатолий Михайлович - кандидат технических наук Зотов Алексей Алексеевич

Ведущая организация - Санкт-Петербургский институт информатики и автоматизации Российской академии наук

Защита состоится 18 мая 2006 г. в 16 часов на заседании диссертационного совета Д 212.229.18 в ГОУ ВПО "Санкт-Петербургский государственный политехнический университет" по адресу: 195251, Санкт-Петербург, Политехническая ул., д.29,9 уч. корп., ауд. 325.

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

Автореферат разослан 17 апреля 2006 г.

Ученый секретарь диссертационного совета

Шашихин В.Н.

Общая характеристика работы

Актуальность

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

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

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

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

Все вышеизложенное свидетельствует об актуальности данной работы.

Цель и задачи работы

Целью работы является создание метода разработки автоматизированных тестов, удовлетворяющего следующим требованиям:

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

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

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

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

Научная иовизна работы

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

1. Создан метод разработки автоматизированных тестов программных приложений.

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

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

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

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

Практическая значимость работы

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

4

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

Апробация работы

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

Внедрение

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

Публикации

По материалам диссертации сделаны доклады на трех межвузовских конференциях и опубликовано 7 печатных работ.

Структура и объем работы

Диссертация содержит 153 страницы основного текста, 19 рисунков, 6 таблиц и состоит из введения, трех глав, заключения, списка литературы и двух приложений.

Содержание работы

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

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

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

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

функциональностью, которые тестируются не в контексте всей программы, а как самостоятельное приложение.

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

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

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

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

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

Программные средства автоматизации тестирования, такие как Rational Robot, Mercury Interactive WinRunner, Mercury Interactive QuickTest, Segue SilkTest и др., позволяют производить запись последовательности действий пользователя (специалиста по тестированию) и в дальнейшем воспроизводить эту последовательность автоматически неограниченное число раз.

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

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

Диаграмма действий для воспроизведения тестового скрипта современными программными средствами автоматизации тестирования, построенная в соответствии с требованиями спецификации языка объектно-ориентированного моделирования UML (Unified Modeling Language) версии 2.0 представлена на рис. 1.

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

В то же время все подобные современные продукты объединены общим набором существенных недостатков.

Во-первых, современные продукты подобного рода, как уже говорилось, при записи действия пользователя запоминают, по сути дела, события операционной системы и объекты GUI, на которых данное событие было сгенерированно. Однако, объекты, события на которых данные инструменты в состоянии записывать, изначально ограничены достаточно стандартным набором типов. И, несмотря на то, что, как правило, подобные продукты позволяют расширять этот список внесением описания своих собственных графических компонентов, на практике это работает только лишь в исключительных случаях. Связано это с тем, что подобные продукты не имеют доступа к API тестируемой системы, без использования которого в большинстве случаев просто невозможно описать нестандартный графический компонент. Так, к примеру, в большинстве графических редакторов все компоненты на поле графического редактора являются отдельными объектами с точки зрения самого редактора, но для операционной системы представляют один большой графический образ.

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

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

И, наконец, одним из

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

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

Краткие характеристики описанных методов указаны в сводной таблице 1.

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

тестируемой системы на произведенное действие.

Рис. 1 Диаграмма действий для воспроизведения одного шага тестового скрипта современными программными средствами автоматизации.

Новый подход к разработке автоматизированных тестов сродни идее ипй-тестирования, но в отличие от ипИ-тестов оперирует не физическими, а, в каком-то смысле, логическими модулями тестируемой системы.

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

Рис. 2 Диаграмма действий для выполнения одного шага тестового скрипта.

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

9

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

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

Диаграмма действий, составленная в терминах языка объектно-ориентированного моделирования UML версии 2.0 и описывающая исполнение одного шага тестового скрипта - тестирования одного логически завершенного действия, изображена на рис. 2.

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

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

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

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

случае тестирования многооконного текстового редактора необходимо проверить, что при открытии второго файла не было внесено никаких изменений в отношении первого открытого файла, что он не был изменен, удален или закрыт. Для этого вводится некая буферная конструкция, именуемая динамической коллекцией состояний. Ее задача заключается в хранении информации о результатах воздействия предшествующих действий на состояние тестируемой системы. По окончании проведения проверок результата воздействия последнего совершенного над тестируемой системой действия проводится проверка результатов воздействия предшествующих действий, совершенных над тестируемой системой ранее, информация о которых добавляется в динамическую коллекцию состояний после каждого совершенного действия и хранится там до окончания выполнения скрипта Кроме того, должна быть реализована возможность запоминания внутренних состояний описанной динамической коллекции и последующее обращение к ним. Это необходимо для тестирования воспроизведения действий, обратных предшествующим (таких как undo/redo).

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

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

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

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

Данная модель описывает кластерное представление произвольных состояний в системах, которая позволит на их основании построить систему распознавания узловых состояний.

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

Пусть О - множество всевозможных тестируемых объектов, то есть, систем. IV = ..,■»>„} - множество состояний системы. Задача построения контекстного представления состоит в том, чтобы для некоторого априорно заданного множества атомарных состояний гипотетической области Я найти отображение задающее для каждого объекта и каждого состояния е5 некоторую меру

принадлежности состояния данному объекту с1. Множество таких отображений обозначим через Г(Д,5). Контекстное представление объекта основано на объединении его состояний в контекстные группы и определения родов состояний, характерных системе, на основе этих групп. Контекстные группы формируются на основе близости этих явлений в объекте. При этом принимается гипотеза о том, что явления, соседствующие в объекте, зависят друг от друга и вместе образуют узлы предметной области.

Обозначим через множество всех конечных последовательностей состояний из

IV. Тогда можно считать, что на множестве объектов В задано отображение т]: О -> Р(}¥), ставящее в соответствие каждому объекту (1 е О некоторую последовательность состояний.

Контекстные группы либо формируются по принципу одинакового количества элементов в них, либо соответствуют определенным типам исследуемых в системе состояний. Для простоты будем рассматривать стратегию разбиения, основанную на равном количестве элементов. Каждая стратегия А задает отображение Ил : -> F(F(W)), где F(^K) - множество всех последовательностей состояний, соответствующих системам, ^(^(РГ)) - множество всех последовательностей контекстных групп, которые, в свою очередь, также соответствуют последовательностям состояний. На этом этапе, поскольку контекстные зависимости уже учтены при построении данного разбиения, можно далее не учитывать информацию о последовательности состояний и контекстных групп, и ввести отображение 3, вида 3: Р(Р(№))х$II, задающее для каждой последовательности контекстных групп и каждого состояния области их меру принадлежности данного состояния этой контекстной группе. Однако для построения этого отображения необходимо сначала рассмотреть каждую контекстную группу в отдельности и определить состояния,

12

содержащиеся в ней. Для этого необходимо ввести отображение Е,: F(W)—> R, задающее для каждой последовательности состояний каждой контекстной группы меру принадлежности состояний этой контекстной группе. Объединяя результаты действия этого отображения на контекстные группы системы, можно получить образ системы при отображении Э, задаваемом при помощи отображения . Объединяющее отображение <р производит построение окончательного вектора признаков системы. При этом каждая контекстная группа путем действия отображения £ преобразуется в вектор признаков сг, ,...,(т( , где / = 1,...,п. Отметим, что действие отображения £ для каждой контекстной

группы можно рассматривать как получение вектора признаков системы, перенумеровав признаки, которыми в данном случае являются роды исследуемой области и рассмотрев векторное пространство, размерности которого соответствуют этим признакам. Затем отображение <р производит построение окончательного вектора признаков системы, состоящего из значений v,,...,vn, соответствующих элементам множества узлов исследуемой области S. Представленная модель имеет абстрактный характер в силу того, что зависит от отображений £ и <р, вид которых не был конкретизирован. Выбор этих отображений основан на использовании вероятностного подхода к классификации контекстных групп и документа. Каждая контекстная группа /, в результате действия отображения отображается на вероятностное распределение P(st\ f:), к = \,...,К родов в области на данной контекстной группе.

Отображение <р производит обобщение полученных при помощи £ классификационных данных. Результатом его действия является вероятностное распределение P(sk | d) состояний гипотетической области родовых состояний динамической библиотеки состояний на рассматриваемой системе d. Данное отображение действует, опираясь на априорно равную вероятность всех контекстных групп в системе, выражающуюся в результатах проведения опыта по случайному выбору контекстной группы системы. Эта априорная равновероятность при рассмотрении вероятностных представлений контекстных групп означает одинаковую информативность контекстных групп и равный их вклад в общую характеристику системы.

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

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

Основными конструкциями данного разработанного языка являются

■ декларации акций, описывающие действия, производимые над системой;

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

■ множества состояний - множества атомарных состояний системы;

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

• динамические коллекции состояний - множества динамических состояний;

■ процедуры - блоки скриптового кода выделенные в отдельные скригты с возможностью их вызова из основного кода;

■ фабрики состояний, создающие динамические коллекции состояний;

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

* модификаторы параметров состояний.

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

8 9 10

количество тестов

Рис. 3 Время разработки тестов в зависимости от их количества.

Метод автоматизации тестирования

ипк-тесты

программные автоматизации тестирования

Разработанный метод

средства

ш Я И

В|

г |

5» в

а

е &

1 э

72% 47%

||| | И! 1

80% 0%

50% 5%

28% 16% 115%

Таблица 1 Функциональные и технические характеристики методов автоматизации тестирования.

используемые методы

Критерия

инвариантность относительно языка реализации продукта

02 тестирование целостного продукта

тестирование на уровне внутренних подсистем продукта д4 тестирование через

пользовательский интерфейс <35 трудоемкость

трудоемкость при переносе на другие платформы 07 эффективность

<?з

0,01 0,02

0,01

0,15 0,08 0,03 0,70

Р|

Рг

?, программны« шН< средства § тесты автоматизации тестирования

0

0 0 1

0 0 0

0,41

1 0 1

0,57 1 0

Рз

разработанный

метод

Таблица 2 Нормализованные критерии оценки методов автоматизации тестирования.

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

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

Краткие сравнительные характеристики отражены в таблице 1. В таблице 2 указаны критерии, нормализованные по следующим формулам

q(N,L)=Q(N'L)_~Qm" , если Q -> шах; q(N,L) = ~ Q{N'L), если Q -> min (1),

Qmix ~ Öinin ßm» Qmm

где {Q(N,L)} - множество критериев, N - номер варианта, L - номер критерия, q(N,L) -нормализованный критерий.

unit-тесты

программные разработанный средства метод

Рис. 4 Диаграмма аддитивных сверток критериев.

аддитивная свертка нормализованных критериев = где (2)

при этом несложно заметить, что /•'(a,3)>F(£^í,l) Уа б{ог,| =1}, а также то, что /-■(«,3) < 2) <=> а6 >5 (а, +а3 +0.43 а, +а7)> 5-а,. Последние два утверждения означают, что разработанный метод эффективнее метода ипк-тестов при любом наборе весовых коэффициентов. А также всегда эффективнее методов с применением программных средств автоматизации за исключением случаев, когда весовой коэффициент критерия

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

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

Основные результаты работы

Для достижения поставленной цели в работе были решены следующие задачи:

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

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

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

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

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

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

7. Создан инструментарий, поддерживающий процесс автоматизации регрессионного тестирования на основе разработанного метода.

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

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

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

Публикации:

1. Гриппа Г.Л., Черноруцкий И.Г. Современные методики тестирования компьютерного программного обеспечения. Автоматизация тестирования // Материалы межвузовской научной конференции "XXXI неделя науки СПбГПУ". Ч. 6. СПб.: Издательство СПбГПУ, 2003.-С. 24-25.

2. Гриппа Г.Л. Проблемы автоматизации тестирования приложений с графическим интерфейсом // Вычислительные, измерительные и управляющие системы.: Сборник научных трудов аспирантов и молодых ученых факультета технической кибернетики. СПб.: Изд-во Политехи, ун-та, 2004. - С. 141-142.

3. Гриппа Г.Л. Метод action-тестов автоматизации тестирования приложений с графическим интерфейсом // Вычислительные, измерительные и управляющие системы.: Сборник научных трудов аспирантов и молодых ученых факультета технической кибернетики. СПб.: Изд-во Политехи, ун-та, 2004. - С. 142-146.

4 Гриппа Г.Л. Система поддержки action-тестов. Язык action-тестов // Вычислительные, измерительные и управляющие системы.: Сборник научных трудов аспирантов и молодых ученых факультета технической кибернетики. СПб.: Изд-во Политехи, ун-та, 2004. - С. 146156.

5. Гриппа Г.Л. Расширенный метод action-тестов автоматизации тестирования приложений с графическим интерфейсом // Вычислительные, измерительные и управляющие системы.: Сборник научных трудов аспирантов и молодых ученых факультета технической кибернетики. СПб.: Изд-во Политехи, ун-та, 2004. - С. 156-157.

6. Гриппа Г.Л., Черноруцкий И.Г. Автоматизация тестирования программных приложений. Метод логических модулей // Технологии Microsoft в теории и практике программирования. Материалы межвузовского конкурса-конференции студентов, аспирантов и молодых ученых Северо-запада. СПб.: Изд-во Политехи, ун-та, 2005. - С. 20-22.

7. Гриппа Г.Л., Черноруцкий И.Г. Автоматизация тестирования программных приложений. Метод логических модулей // XXXIII Неделя науки СПбГПУ: Материалы Всеросийской межвузовской научно-технической конференции студентов и аспирантов. Часть V. СПб.: Изд-во Политехи, ун-та, 2005. - С. 20-22.

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

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

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

- 87 63

СОДЕРЖАНИЕ.

ВВЕДЕНИЕ.

1 ОБЗОР СОВРЕМЕННЫХ ПОДХОДОВ К ПРОЦЕССУ ТЕСТИРОВАНИЯ И ЕГО АВТОМАТИЗАЦИИ.

1.1 Тестирования программного обеспечения.

1.1.1 Определение тестирования.

1.1.2 Место тестирования в процессе разработки программного обеспечения.

1.1.3 Различные подходы к тестированию.

1.2 Количественные критерии качества тестирования.

1.3 Модульное тестирование.

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

1.3.2 Стратегии выполнения пошагового тестирования.

Нисходящее тестирование.

Восходящее тестирование.

1.3.3 Принципы тестирования структуры программных модулей.

Показатели корректности тестирования структуры программных модулей.

Оценка достигаемой корректности программ.

1А Регрессионное тестирование.

1.5 Автоматизированное тестирование.

1.5.1 Цпк-тестирование.

1.5.2 Программные средства автоматизации тестирования.

1.6 Выводы.

1.6.1 Актуальность темы.

1.6.2 Цель работы.

2 МЕТОД КЛЮЧЕВЫХ СОСТОЯНИЙ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ПРОГРАММНЫХ ПРИЛОЖЕНИЙ.

2.1 Описание метода и методики его применения.

2.2 Разработка математической модели контекстного представления множества произвольных состояний.

2.3 Разработка метода формирования множества понятий предметной области (кластеров).

2.4 Разработка метода классификации контекстных групп.

2.5 Разработка метода контекстного распознавания архитипических систем.

2.6 Теоретическое обоснование преимуществ разработанного метода.

2.7 Язык описания тестов.

2.7.1 Скрипт.

2.7.2 Акции (действия).

2.7.3 Состояния.

2.7.4 Проверка множества состояний.

2.7.5 Динамические состояния.

2.7.6 Динамические коллекции состояний.

2.7.7 Сохранение состояния.

2.7.8 Процедуры.

Создание объектов.

Удаление объектов.

Изменение свойств объектов.

2.7.9 Фабрики состояний.

2.7.10 Фильтры состояний.

2.7.11 Модификаторы параметров состояний.

2.7.12 Примеры.

Пример простейшего скрипта.

Пример декларации действия.

Примеры определения состояния.

Пример описания проверки.

Пример процедуры.

2.8 Система поддержки автоматизированных тестов.

2.9 Расширение нового метода автоматизации тестирования.

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

3.1 Анализ применения разработанных методов и средств.

3.2 Выводы.

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

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

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

Исследование причин неудач при реализации больших программных проектов, проведенное в 80-х годах прошлого века [76], показало, что число ошибок в спецификациях на программы значительно превышает их количество в программных кодах. Так около 56% ошибок допускаются на этапе формулировки требований к программе, при этом расходуется в среднем 82% всех усилий, затраченных коллективом на устранение ошибок проекта, в то время, как на этапе кодирования программ допускается соответственно 7% ошибок и тратится 1% усилий на их ликвидацию [76].

Кроме того, можно выделить пять наиболее важных этапов жизненного цикла программного средства:

• спецификацию;

• проектирование;

• кодирование;

• отладку;

• сопровождение.

По затратам времени, человеческих и машинных ресурсов все эти этапы не одинаковы. Наиболее "дорогими", в этом смысле, являются этапы, связанные с поиском ошибок в программах. Затраты ресурсов на них могут быть равными или даже превосходить совокупные затраты ресурсов на остальных этапах. В стандарте ОСЮ-8ТО-2167-А около 30% требований, документов и соответствующих им процессов непосредственно связаны с отладкой, тестированием и испытаниями программ. Данный стандарт является обязательным при выполнении заказов Министерства обороны США [26]. Эти затраты быстро увеличиваются при возрастании требований к качеству программного продукта. Следует учитывать, что значительная часть работ, выполняемых на этапе сопровождения, связана с поиском и устранением оставшихся в программе ошибок. Исследования [23, 63, 69] показали, что на долю устранения ошибок и сопровождение программного продукта приходится почти 75% всех затрат. Кроме того, и в случае внесения новых ошибок в программу на этап сопровождения приходятся огромные затраты.

Безусловно, подобная ситуация была неприемлема, поэтому существовавший стандартный процесс разработки программного обеспечения подвергся некоторой модернизации. Было сформулировано предложение, что для случаев повторной проверки корректности существующей функциональности программы, унаследованной, к примеру, в процессе разработки из предыдущей версии, необходимо использование регрессионного тестирования [46, 52] - повторного тестирования части программы, зависящей от внесенных изменений. Регрессионное тестирование прекрасно подходит как для проверки корректности изменений, внесенных в тестируемую систему, так и для проверки корректности добавленных к системе новых компонентов и функциональных возможностей. Кроме того, регрессионное тестирование позволяет проверить, что внесенные в код программы изменения корректны и не воздействуют неблагоприятно на остальные ее части. В случае же обнаружения в программе новых ошибок считается, что в системе появились регрессионные ошибки [56, 61]. Ввиду того, что поведение новой версии программы должно совпадать с поведением предыдущей версии, за исключением ситуаций, обусловленных внесением изменений, соответствующих новым требованиям к системе, регрессионные системные тесты можно рассматривать как частичные требования к новым версиям системы. В большинстве случаев вместо регрессионного тестирования для проверки того, что качество новой версии программы не ухудшилось, выполняется множество всех тестов, используемых на этапе системного и функционального тестирования продукта.

Регрессионное тестирование относится к необходимым методам профилактического сопровождения и применяется в ходе процесса разработки и модификации программного продукта. Однако, такой род деятельности является крайне ресурсоемким и, как следствие, дорогостоящим. Это обусловлено необходимостью проводить регрессионное тестирование в случае внесения даже малейших изменений в код программы, в то время, как процесс регрессионного тестирования может включать в себя исполнение достаточно большого количества тестов на скорректированной версии программы. И несмотря на то, что усилия, требуемые для внесения небольших изменений, как правило, минимальны, они могут требовать достаточно больших усилий для проверки качества измененной программы [42, 43]. Тем не менее, надежная и эффективная разработка и сопровождение программного обеспечения невозможны без регрессионного тестирования [55]. Одним из очевидных решений здесь является автоматизация процесса тестирования, помогающая ускорить создание продукта и улучшить его качество.

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

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

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

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

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

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

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

Методологической и теоретической основой диссертации послужили фундаментальные труды отечественных и зарубежных программистов, изучающих проблемы безошибочного программирования основывающегося на реализации процессов автоматизации всех этапов жизненного цикла программных продуктов от проектирования и кодирования программ до документирования и их сопровождения. К таким средствам относятся: САБЕ-средства, объектно-ориентированное программирование, методы логического программирования. Особое место занимают методы визуального программирования, поскольку приближение формы представления программы и способов ее кодирования к образному способу мышления человека в значительной степени сокращает число ошибок, допускаемых человеком при разработке программ, и повышает надежность программирования [27].

Кроме того, основой диссертации послужили публикации научной и периодической печати.

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

Научная новизна диссертационного исследования состоит в:

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

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

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

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

• разработке языка описания тестов;

• создании инструментария, поддерживающего процесс автоматизации регрессионного тестирования на основе разработанного метода.

Практическая значимость полученных результатов заключается в том, что:

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

• разработан язык описания тестов;

• создан инструментарий, позволяющий применение нового метода;

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

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

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

Разработанный метод, язык описания тестов и инструментарий поддержки данного метода были внедрены в производственный процесс Филиала Корпорации "Борланд Лабе., Инк.".

Результаты работы

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

Основные результаты работы докладывались и обсуждались на следующих конференциях:

- XXXI неделя науки СПбГПУ;

- XXXIII неделя науки СПбГПУ;

- Технологии Microsoft в теории и практике программирования 2005.

По материалам диссертационной работы опубликовано 7 печатных работ.

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

На защиту выносятся:

1. Метод ключевых состояний автоматизации тестирования программных приложений.

2. Язык описания тестов.

3. Инструментарий, поддерживающего процесс автоматизации регрессионного тестирования на основе разработанного метода.

ЗАКЛЮЧЕНИЕ.

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

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

Научная новизна диссертационного исследования состоит в:

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

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

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

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

• разработке языка описания тестов;

• создании инструментария, поддерживающего процесс автоматизации регрессионного тестирования на основе разработанного метода.

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

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

Разработанный метод, язык описания тестов, и инструментарий поддержки данного метода были внедрены в производственный процесс Филиала Корпорации "Борланд Лабе., Инк.".

1. Аграновский A.B., Арутюнян Р.Э., Куликов J1.C. Метод контекстного представления при обработке документов // Научная мысль Кавказа, Приложение, №7 (61) 2004., стр. 118-125.

2. Аджиев В. MS: корпоративная культура разработки ПО // Открытые системы, 1998, №1.

3. Ахо, Ульман Введение в теорию компиляции // М. Мир, 1978.

4. Боэм Б., Браун Дж., Каспар X. Характеристики качества программного обеспечения. М.: Мир, 1981.

5. Бромберг И. Автоматизация тестирования // http://www.newport-group-inc.com/PDF/!mercury.pdf.

6. Вендоров М. Практические рекомендации по освоению и внедрению CASE средств // Открыте системы, 1997, №1.

7. Гинкул Г. П., Соловьев С. Ю., Сотников А. Н., Шабанов Б. М. Проблема 2000 года и задача реконструкции дат // Автоматизация и проектирование, 1999, №2.

8. Гриппа Г.Л., Черноруцкий И.Г. Современные методики тестирования компьютерного программного обеспечения. Автоматизация тестирования // Материалы межвузовской научной конференции "XXXI неделя науки СПбГПУ". Ч. 6. СПб.: Издательство СПбГПУ, 2003. С. 24-25.

9. Гриппа Г.Л. Система поддержки action-тестов. Язык action-тестов // Вычислительные, измерительные и управляющие системы.: Сборник научных трудов аспирантов и молодых ученых факультета технической кибернетики. СПб.: Изд-во Политехи, ун-та, 2004.

10. Дубова Н, Знак качества программному продукту // Открыте системы, 1998, №6.

11. Дуда Р., Харт П. Распознавание образов и анализ сцен // Пер. с англ. -М.Мир, 1976.-511с.

12. Журавлев Д. Большие проекты // http://www.training.ru/russian/publication 1.

13. Илья Бромберг, журнал "Открытые системы", #05, 2002.

14. Липаев В.В. "Тестирование программ", М. Радио и связь, 1986.

15. Липаев В.В. Качество программного обеспечения. М.: Финансы и статистика, 1983.

16. Маейрс Г. Надежность программного обеспечения. "Мир", Москва, 1980.

17. Майерс Г. "Искусство тестирования программ", М. Финансы и статистика, 1982.23. "Тестирование программного обеспечения" // http://se.math.spbu.ru/Courses/Testing/Testing.html.

18. Разработка программ с использованием Microsoft English Query: оснастите возможностями естественного языка запросов ваши веб-узлы и приложения // СУБД, специальный выпуск, посвященный Microsoft SQL Server 7.0, 1998.

19. Сван Т. Программирование для Windows в Borland С++. M.: БИНОМ, 1995.

20. Современные технологии разработки и тестирования ПО // http://www.ssau.ni/struct/kafedry/ist/tp/l.html.

21. Суркис А. С. Y2K от проблемы к решению! //http://www.digdes.spb.ru/about/advertising/current/articles/ComPress/y2kdd.ht ml.

22. Тестирование приложений пользователя, измененных с учетом проблемы 2000 года // Министерство транспорта Российской Федерации, 1998.

23. Тестируйте приложения клиент/сервер в процессе их разработки! //• Сети, 1994, №37.

24. Технология программирования // http://csd.ehu.by/librar/prog/sofl/p5.asp.

25. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях.- Киев: Диалектика, 1993.

26. Юфа В. Что такое "Проблема 2000" // Банковские технологии, 1999, №5-6.

27. Agrawa Н., Horgan J. R. Automated regression testing of graphical user interface based application // Proceedings of the Conference on Software Maintenence, 1993, pp. 348-357.

28. Ahmed N., Liu H., Sung K. Incremental Learning with Support Vector Machines // Proceedings of the fifth International Conference on Knowledge Discovery and Data Mining, ACM Press (1999), pp. 317-321.

29. Andreas J. R. Automated regression testing of graphical user interface 4 based application // Proceedings of the Twenty-four Annual Hawaii1.ternational Conference on System Sciences, 1991, Vol. 2, p. 101.

30. Aubrey Ch. Breakthrough to World Class Service Levels with Six Sigma. Proc 44th EOQ Congress, Budapest, 2000. v.l, p.175-178.

31. B. Beizer. Software Testing Techniques. New York: International Thomson Publishers, 1990.

32. Beck K. Simple Smalltalk Testing With Patterns // http://www.xprogramming.com/testfram.htm.

33. Binkley D. Reducing the cost of regression testing by semantics guided • test case selection // Proceedings of the International Conference on Software

34. Maintenance, 1995, pp. 251-260.

35. Binkley D. Semantics guided regression test cost reduction // IEEE Transaction on Software Engineering, 1997, Vol. 23, №8, pp. 498-516.

36. Binkley D. Using semantic differencing to reduce teh cost of regression testing // Proceedings of the Conference on Software Maintenance, 1992, pp. 41-50.

37. Blakeslee J.A. Implementing the Six Sigma Solution. Quality Progress,1999. July, p. 77-85.

38. Forgacs I., Hajnal A., Takacs E. Regression slicing and its use inregression testing // Proceedings of the Twenty-second Annual International Computer Software and Applications Conference, 1998, pp. 464-469.

39. Granja I., Jino M. Techniques for regression testing: selecting test case sets tailored to possibly modified functionalities // Proceedings of the Third European Conference on Software Maintenance and Reengineering, 1999, pp. 211.

40. Hahn G.J. et al. The Impact of Six Sigma Improvement A Glimpse into the Future of Statistics. The American Statistician. 1999. August.(www.amstat.org/publications/tas/ abstracts % 5 F99/various.html).

41. Harrold M. J., Rosenblum D. S., Rothermel G., Weyuker E. J. Empirical studies of a prediction model for regression test selection // IEEE Transaction on Software Engineering, 2001, Vol. 27, №3, pp. 248-263.

42. Harry M.J. Six Sigma: A Breakthrough Strategy for Profitability. -Quality Progress, 1998, May, p.60 64. Пер.: Методы менеджмента качества,2000.№6, с.8-14.

43. Hoerl R.W. Six Sigma and the Future of the Quality Profession. Quality Progress, 1998. June, p.35 42.

44. Hoskins J., Stuart B., Taylor J. Statistical Process Control.• Motorola, 1991.-31 p.

45. IEEE Standard 610.12-1990, p. 61.

46. IEEE Standard 610.12-1990, p. 74.• .

47. IS Integration White Paper. Test automation. Ensuring a return on yourinvestment // http://www.isintegration.co.uk/Documents/White papers/ROI forAutomatedTools.pdf.

48. Jeon T., Von Mayrhauser A. A knoewledge\based approach to regression testing // Proceedings of the First Asia-Pacific Software Engineering Conference, 1994, pp. 144-153.

49. Jeron T., Jezequel J. M., Le Traon Y., Morel P. Efficient strategies for integration and regression testing of OO systems // Proceedings of the 1 Oth1.ternational Symposium on Software Reliability Engineering, 1999, pp. 260269.

50. Jones C. Applied Software Measurement, 1991.

51. Jones C. Assessment and Control of Software Risks, Yourdon Press Computing, Hardcover, 1994.

52. Jones C. Programming Productivity, McGraw-Hill.

53. Kaner C. Software negligence and testing coverage // #; http://www.kaner.com/coverage.html.

54. Le Traon Y., Jeron T., Jezequel J. M., Morel P. Efficient object-oriented integration and regression testing // IEEE Transactions on Reliability, 2000, Vol. 49, №1, pp. 12-25.

55. Leung H. K. N., White L. J. A cost model to compare regression test strategies // // Proceedings of the Conference on Software Maintenance, 1991, pp. 201-208.

56. Lientz B. P., Swanson E. B. Software maintenance management // Addison-Wesley, 1980.

57. Maguire M. Cowboy Quality. Quality Progress, 1999, October, p. 27-34.• 64. Marash S.A. Six Sigma: A Quality Philosophy for the Next Millennium. Proc. 44th EOQ Congress, Budapest, 2000. v.l, p. 168-174.

58. Rothermel G., Harrold M. J. Analysing regression test selection techniques // IEEE Transaction on Software Engineering, 1996, Vol. 22, №8, pp. 529-551.

59. S. McConnell "Code Complete", Microsoft Press, 1993. 858 p.

60. Schach S. Software engineering with Java // McGraw-Hill, 1996, 640pp.

61. Snee R.D. Why Should Statisticians Pay Attention to Six Sigma? An examination for their role in the six sigma methodology. Quality Progress, 1999. September, p. 100-103.

62. Stacey D. A. Software testing techniques //http://hebb.cis.uoguelph.ca/~deb/27343/Lectures/testing.html.

63. Taneja I., Pardo L., Morales D., Mendez M. On generalized information and divergence measures and their applications: A brief review // Questiio, 13, pp. 47-73.

64. Taylor B. J., Cukic B. Evaluation of regressive methods for automated generation of test trajectories // Proceedings of the 11th International Symposium on Software Reliability Engineering, 2000, pp. 97-109.

65. Theodoridis S., Koutroumbas K. Pattern Recognition //. Elsevier Science (USA), 2003.

66. Tomkins R. GE Beats Expected 13% Rise. Financial Times, Oct. 10, 1997. p.22.

67. Von Mayrhauser A., Mraz R. T., Walls J. Domain based regression testing // Proceedings of the International Conference on Software Maintenance, 1994, pp. 26-35.

68. Wegner P. Notes on object-oriented programming. Dansk Datamatic1. Ntf1. Center, May 1987.

69. Ye W., Chen M. H., Kao H. M. Regression testing on object oriented programs // Proceedings of the 10th International Symposium on Software Reliability Engineering, 1999, pp. 270-279.