CC BY
149
N96(18)2008
С.М. Старолетов, Е.Н. Крючкова
Тестирование распределенных приложений на основе построения моделей
Сегодня рынок программного обеспечения постепенно переходит от программных систем, выполняющихся на одном настольном компьютере, к распределенным системам, работающим на нескольких устройствах через локальную сеть организации или глобальную сеть Интернет. Причем устройствами могут быть как обычные компьютеры, так и «умное» оборудование (сотовые телефоны, КПК, банкоматы, mp3-плейеры, UP'n'P-электролампочки, джакузи с веб-сервисами и многое другое).
В настоящее время нередки случаи, когда приложения состоят из компонентов, реализованных на различных языках программирования и работающих на разных платформах. Следовательно, сложность программных систем резко возрастает за счет межкомпонентного (межпрограммного, межплатформенного) взаимодействия. На рис. 1 в качестве примера показана схема сегодняшнего типового приложения по замыслу Sun Microsystems, которое включает серверную часть, тонкие клиенты через браузер, настольный клиент и ПО для мобильных устройств.
Database
»
Рис. 1. Типовое современное приложение (Sun Microsystems)
В связи со сложностью продуктов возрастают и требования к качеству программного обеспечения, и этого качества придерживаться становится все труднее. Для обеспечения качества программного про-
дукта необходимо его обязательное тестирование в процессе разработки, перед запуском в продажу и внедрением.
Тестирование — самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих приложений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие — специализированные группы. Виды тестирования перечислены ниже.
• Блочным тестированием называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы.
• Тестирование компонента - это тестирование класса, пакета, небольшого приложения или другого элемента системы, разработанного несколькими программистами или группами, выполняемое в изоляции от остальных частей системы.
• Интеграционное тестирование - это совместное выполнение двух или более классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами. Этот вид тестирования обычно начинают проводить, как только созданы два класса, которые можно протестировать, и продолжают до завершения работы над системой.
124
И96(18)2008
• Регрессивным тестированием называют повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов.
• Тестирование системы — это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами. Предметом тестирования в этом случае являются безопасность, производительность, утечка ресурсов, проблемы синхронизации и прочие аспекты, которые невозможно протестировать на более низких уровнях интеграции.
Во всех компаниях по производству программного обеспечения цикл разработки ПО включает фазу тестирования, причем в некоторых методологиях процесса разработки тестирование не выделяется в отдельную фазу, а ведется на всех фазах разработки, и даже тесты пишутся до написания кода. Должность «тести-ровщик» (тестер, QA manager) — не редкость, а в крупных компаниях мирового уровня эта профессия — одна из важных и высокооплачиваемых. Однако по мере возрастания сложности системы для гарантии ее безошибочной работы будет требоваться все больше тестеров, и может наступить момент, когда рост числа людей уже не сможет гарантировать качества продукта [1]. Это означает, что необходимы автоматизированные средства тестирования сложных взаимодействующих систем, причем на основе новых методологий.
Что тестируем?
В распределенных системах главное — взаимодействие между компонентами, которое происходит по каналам связи. В результате ошибок при соединениях логика работы может быть нарушена. Следовательно, необходимо проверять соответствие ожидаемого и реального поведения всей системы, определять узкие места сис-
темы во время взаимодеиствия и знать, в каком состоянии находится система в любой заданный момент времени.
Кроме того, приложение может содержать несколько экземпляров как клиентов, так и серверов, и может случиться, что система при небольшом числе клиентов работает нормально, а при большом — дает серьезные сбои или очень медленно реагирует на действия пользователей. Следовательно, необходимо произвести тестирование на отказоустойчивость.
Подход
В статье предлагается использовать подход к тестированию программ на основе построения моделей [2]. Это достаточно новый подход, при котором строится математическая модель всей системы, и по ней проводится тестирование. Данный подход требует специальных знаний тестировщи-ка, но уже сам факт перехода к моделированию в тестировании свидетельствует о серьезном отношении к качеству программных систем.
Естественно, производители ПО не обошли стороной тестирование на основе моделей и разработали некоторые средства для автоматизированного тестирования таким методом.
Microsoft Spec Explorer
Группа Semantic Platforms Test Group компании Microsoft Corporation в 1999 году [3], а затем Foundations of Software Engineering из Microsoft Research [4, 5, 6, 7, 8] c 2003 года серьезно прорабатывают вопросы тестирования ПО на основе моделей. В результате был создан продукт Spec Explorer, который используется в данной корпорации для тестирования компонентов среды .NET Framework, компонентов ОС и браузера Internet Explorer.
В разработках группы используется теория машин абстрактных состояний (ASM — Abstract State Mashines), разработанная профессором университета Мичиган Юрием Гуревичем (ныне — научный сотрудник
«о «
I
4
s
125
N96(18)2008
Microsoft Research, Редмонд, штат Вашингтон).
В конце 1980-х годов Гуревич расширил тезис Тьюринга о том, что каждый алгоритм симулируется соответствующей машиной Тьюринга, тезисом ASM: каждый алгоритм, не важно какой абстракции, шаг за шагом эмулируется соответствующей ему машиной ASM [9].
Для тестируемой системы строится следующая модель-машина:
M = (Sinit, S, Sacc, Obs, Ctrl, S),
где S — конечное множество состояний системы1;
Sint e S — непустое подмножество начальных состояний;
Sacc e S — подмножество заключительных состояний.
Acts — множество действий по переходу из одного состояния в другое, оно разделяется на 2 подмножества: Acts = Obs и Ctrl, где Obs — множество обозреваемых дейст-¡а вий; Ctrl — множество контролируемых дей-Ц ствий.
® В [5] приводится аналогия «тестирова-| ние как игра», игра с природой, в которой ji мы делаем шаг (переход из состояния в со-| стояние в результате работы логики про-g граммы — контролируемое действие), и при-§ рода делает шаг (возникновение события и или исключение — обозреваемое действие). Ч Функция переходов имеет вид:
1 Se S ■ Acts ■ S. g
[ï Поведение системы (модель) в данной g методологии описывается на специальном | языке выполнимых спецификаций Spec# | (расширение C#) — в среде Visual Studio или на языке ASML (Abstract State Mashine Sâ Language) внутри документов Word. su Модель описывает переменные состояло ний и переходы. Шаги машины (т.е. перехо-
!
U
ды между состояниями) — выполнение методов модулируемой программы, которые удовлетворяют данным предусловиям состояния. В результате Spec Explorer строит конечный граф с состояниями и переходами, которые представляют подмножества S и Acts.
Поскольку в реальных системах переменных может быть много и они могут принимать большое количество значений, итоговый граф системы будет хотя и конечным, но с очень большим числом состояний и переходов между ними. Работа с таким графом затруднена, поэтому необходимо принимать специальные меры для сокращения числа состояний.
Результатом работы Spec Explorer являются автоматически сгенерированные тест-кейсы (test cases — тестовые наборы) поведения системы, которые могут быть запущены вместе с тестируемой системой для проверки описанного и полученного поведения.
Spec Explorer поддерживает 2 вида тестов: офлайн и онлайн. Для офлайн-тестиро-вания автомат модели сводится к автомату, представляющему план тестирования (test suite), который потом компилируется в отдельную программу. Для онлайн-тестирова-ния обзор модели и проверка соответствия соединены в один алгоритм. Если тестируемая система представляет собой нераспределенную .NET программу, то тест-программа будет создана инструментом автоматически. В других случаях пользователю следует написать обертку (wrapper) на .NET языке, которая реализует актуальную реализацию, используя средства .NET для взаимодействия.
Итак, Microsoft Spec Explorer обеспечивает средства для автоматизированного тестирования с построением моделей в виде конечных автоматов. Продукт пока используется только внутри Microsoft и досту-
1 Под состоянием в данном случае понимается набор значений выбранных переменных системы, которые имеют наибольшее значение для логики работы программы. Изменение хотя бы одной переменной системы ведет к появлению нового состояния.
126
№6(18)2008
Рис. 2. Диалог выбора типа теста (Visual Studio 2008, Test Project)
пен для свободного скачивания с узла Microsoft Research (использование только для образовательных целей). Продукт так и не стал коммерческим, и даже в версию Visual Studio 2008 Team Edition for Software Testers ни он, ни язык спецификаций Spec# включены не были (рис. 2). Скорее всего, это объясняется тем, что от пользователя Spec Explorer требуются слишком глубокие знания теории автоматов, спецификаций, профессиональных технологий тестирования, платформы .NET. Microsoft считает, что этот инструмент не должен выходить на массовый рынок ПО, и предлагает более привычные виды тестов: Unit Test, Load Test, Database Test и их комбинации.
Технология промышленного тестирования UniTesK
Научная группа Института системного программирования РАН RedVerst (Research and development in Verification, Specification, and Testing) разработала технологию промышленного тестирования UniTesK, основанную на формальных спецификациях. Технология объединяет средства для тестирования C/C++, Java и C# приложений, а также специальные средства для тестирования компиляторов.
127
t I
I
При тестировании с помощью UniTesK система рассматривается в виде «черного ящика», т.е. тестируется ее интерфейс — набор классов или функций. Сами тесты генерируются автоматически по спецификации системы и тестовым сценариям [10]. Спецификация системы пишется на одном из разработанных языков — расширений для языков Java, C, C# (языковые расширения достаточно обширные — так, например, описание языка SeC занимает 188 с.) и представляет собой набор пред-, постусловий, инвариантов, описывающих требования к системе. Тестовый сценарий описывает конечный автомат, определяющий тестируемые состояния системы и воздействия на систему в процессе тестирования. В результате тестирования обходчик UniTesK динамически строит конечный автомат пройденных состояний.
На рис. 3 приведен автомат, построенный обходчиком UniTesK после прогона теста [11].
На конференции MS Academic Days [1] один из разработчиков системы В. Кулямин рассказал о тестировании распределенных систем с помощью технологии UniTesK.
Для описания систем предполагается использовать контрактные спецификации
Ne6(18)2008
! i
i о
Е^
о о ft <ъ со о
is
0
то %
1 &
а
I
t то
и
то со о
8
Рис. 3. Автомат обходчика
(контракт — обязательство среды и компонента друг перед другом, предусловие определяет обязательство среды перед компонентом, а постусловие — компонента перед средой), в качестве расширения подхода для распределенных систем — событийные контракты (Event Contracts), поскольку события могут возникать асинхронно (предусловие — предикат, который описывает, в каких состояниях данное событие возможно, постусловие — в какие состояния можно попасть из данного состояния после возникновения события).
Сам процесс тестирования состоит в воздействии на систему, но не последовательно, а последовательно-параллельно (рис. 4). Осуществляется воздействие на систему с малыми задержками между воздействиями и получение ответов. Полученное множество состояний проверяется на корректность заданных событийных контрактов. Если система удовлетворяет аксиоме чистого параллелизма (plain concur-
rency axiom), т. е. результат параллельного выполнения любого набора вызовов операций такой системы такой же, как при выполнении того же набора вызовов в некотором порядке, и если обработанные системой воздействия и полученные от нее асинхронные реакции можно линейно упорядочить таким образом, что в полученной последовательности перед каждыми вызовом или реакцией будет выполнено его/ее предусловие, а после — постусловие (рис. 5), то система ведет себя корректно (ее наблю-
s12 S11 ▼ ►
_s21
¿Up*
121.
Time 1
Рис. 4. Тестовое воздействие на распределенную систему
128
Нв6(18)2008
Рис. 5. Линейное упорядочение
даемое поведение не противоречит спецификациям) [12].
Если такого упорядочения построить нельзя, значит, обнаружено несоответствие поведения системы спецификациям.
Таким образом, технология UniTesK позволяет проводить тестирование систем на основе моделей, описываемых при помощи спецификаций. Технология продается «в коробочном варианте», но о той части, которая проводит тестирование распределенных систем, на официальном сайте не указано (не указана и поддержка языка С# — лишь C и Java). И не понятно, реализованы ли эти идеи на практике. Главным аспектом, тормозящим развитие технологии, является сложность описания модели при помощи пред- и постусловий, особенно когда продукт представляет собой реальную систему для автоматизации какого-то процесса без строгих требований к ней. Для работы с системой UniTesK нужно высшее математическое образование.
Предлагаемая математическая модель
В данной статье приводится описание распределенных систем с помощью собственной математической модели, средств для тестирования и моделирования для тестеров и программистов без особой математической подготовки.
Будем руководствоваться тезисом машин абстрактных состояний и формиро-
вать модель программной системы в виде конечного автомата.
На основе анализа предметной области было решено использовать вероятностный конечный автомат и расширить его для описания реальных взаимодействующих систем с учетом событий и исключений.
Итак, вся взаимодействующая система представляется в виде расширенного вероятностного конечного автомата:
А = (О, D, Е, 5, qo, F).
Опишем подробно все указанные множества применительно к тестируемой программой системе.
О — конечное множество состояний. Состояние системы — важный с точки зрения логики работы системы участок кода, который выделяется разработчиком (или тестером) вручную или с помощью разработанных средств. В этом коренное отличие предлагаемого подхода от выше рассмотренных, в которых новое состояние создается при изменении значения переменной из набора ключевых переменных. Преимущества нашего подхода к выделению состояний заключаются в следующем: более легкое описание для пользователей, что позволяет абстрагироваться от переменных и сконцентрироваться на собственно взаимодействии, а также более легкий способ обработки описываемого автомата тестирующей системой.
q0 с О — начальное состояние автомата, точка входа в программу.
Р с О — множество заключительных состояний системы.
5 — функция переходов, определим ее следующим образом:
5 :О• (О и(Е и {б}))• Р• (N и {1}) ^ 2О (Еи{1})ш.
О — множество действий, идентифицирующих переход из состояния в состояние. Действие — это словесный тег, отвечающий на вопрос «почему мы перешли из заданного состояния в следующее заданное?». Действие — это надпись на дуге перехода между двумя состояниями.
се
I &
СЦ !
129
№>6(18)2008
S »
I §
eu
I
S 1
I
! 8.
к
s
л
E — множество исключительных ситуаций или событий (по аналогии с Obs от Microsoft Research). Во время выполнения перехода из состояние в состояние возможны генерация исключения или возникновение события. События и исключения возникают асинхронно и описываются особенно.
P — вероятность перехода из заданного состояния в следующее заданное. Предполагаемая модель является вероятностной и в отличие от модели Microsoft Research, где вероятности присутствуют при «тестировании как игре» [5], когда «природа» делает шаг в соответствии с какой-либо вероятностью (т.е. случается событие), в нашей модели вероятностные переходы осуществляются и при прямых переходах. Например, для тестирования if (A) B; else C можно строить систему пред- и постусловий, а можно поставить задачу прохождения ветви B с условной вероятностью P(BA) и ветви C с вероятностью P(C I - A).
В нашей модели вероятности подразделяются на априорные и апостериорные.
Априорными (P0) называются вероятности, которые могут быть определены до запуска системы — как примерное, ожидаемое поведение системы.
Апостериорными (динамическими) являются вероятности переходов, которые были рассчитаны тестирующей системой для модели в процессе выполнения системы для каждой из пар (q; q), таких, что существует дуга из i-го состояния в j-е, в какой-то момент времени. В процессе работы системы вероятности меняются, поэтому можно считать, что Pij = Pij{t), где t —время прогона, или Pij= Pj(k), где k — число совершенных переходов, i,j<= IQI. Подробнее про динамическое тестирование будет сказано позднее.
N — кратность (по умолчанию кратность равна 1). Для описания систем с несколькими взаимодействующими друг с другом клиентами или многопоточных систем, логика которых предполагает не просто взаимодействие, а зависимость перехода в другое состояние от подключенных клиентов (потоков), вводится понятие кратности — количе-
Client::c1
Рис. 6. Переход по кратности 2 (2 клиента и сервер)
ства подключенных клиентов. Например, чат может начинать работу, когда к нему подсоединятся два пользователя, в этом случае имеем переход по кратности 2 (рис. 6).
В дальнейшем предполагается расширить описание модели и ввести примитивы синхронизации.
W — флаг ошибки, или ошибочного состояния. Разработчик системы может определить те состояния системы, попадание в которые служит сигналом об ошибочной работе. При попадании в эти состояния система динамического тестирования учтет этот факт и сообщит об этом.
Model-based и anti-model-based тестирование
В тестировании на основе моделей строится модель системы по исходному коду, на ее основе генерируются тестовые наборы, производится сверка модели и системы. В противовес тестированию на основе моделей (model based testing) в статье [13] описывается шаблон тестирования (pattern) anti-model-based testing, при котором система выполняется, и в процессе ее выполнения и мониторинга строится ее динамическая модель — как работала тестируемая система во время теста.
В данном исследовании предлагается описывать модель тестируемой распреде-
130
И96(18)2008
ленной системы, затем проводить тестирование модели системы (будем называть это офлайн- или статическим тестированием), а также по работающей системе, используя описание состояний, строить ее динамическую модель и сравнивать ее со статической моделью (онлайн- или динамическое тестирование). Таким образом, предполагается реализация как model-based, так и anti-model-based тестирования.
Описание модели системы для тестирования
Для описания модели системы предлагается использовать подход «код и модель — единое целое». Модель будем описывать на специально разработанном языке описания моделей в специального вида комментариях к исходному коду. При этом исходный код модулей системы может быть написан на различных языках программирования, тогда как модель описывается всегда на одном языке, не зависящем от используемого языка разработки. Для облегчения синтаксической обработки языка описания моделей, а также в связи с общей тенденцией в программировании было решено, что язык описания моделей будет создан на основе XML. Разработанный нами язык (Auto-matto XML, AXML) определяет теги для описания состояний конечного автомата и переходов в соответствии с функцией переходов 5. Атрибуты тегов — это дополнительные свойства состояний, они определяются функцией 5.
Как было указано ранее, состояния автомата выделяются разработчиком/тестером в комментариях к исходному модулю. Описывается состояние системы, внутри него — полезный код состояния (бизнес-логика работы) и переходы из данного состояния в другие:
//<state name='state1' >
// код состояния на языке программирования // условия // переход
//<go state='state2' p='10%' on='connect'/>
//
//</state>
Данному коду соответствует рис. 7.
С statel \
ч /
connect, Р=10%
f state2 \
ч /
Рис. 7. Переход между состояниями автомата
Набор атрибутов определяется сложностью перехода (см. описание математической модели) и впоследствии может быть расширен.
Поскольку разработчики пишут код в своих привычных средах разработки, целесообразно разработать модули поддержки описания модели системы для популярных сред программирования (add-in для MS Visual Studio, plugin для Eclipse).
Обработка данных описаний тестирующей системой должна происходить следующим образом:
• все значащие комментарии (т.е. содержащие описание модели) из файлов с исходным кодом различных модулей системы в соответствии с предварительно созданным проектом собираются в один файл, который содержит описания модели на языке AXML для всей системы в целом и будет использован для проведения офлайн-тес-тирования;
• на местах описания состояний и переходов по описанию модели генерируется специальный код (уже зависящий от языка программирования исходного кода модуля), который при работе отсылает данные о текущем состоянии, о состояниях, в которые осуществляется переход на многопоточный сервер тестирующей системы. (В этом месте возможно применение аспектно-ориентирован-ной модели программирования [14]).
Организация процесса офлайн-тестирования
В предыдущих разделах было описано, как получить модель тестируемой системы. Полученную статическую модель с переходами будем считать ориентированным графом системы, где состояния соответствуют вершинам, а переходы — дугам.
<0 со
i 4
S
131
Nq6(18)2008
Одной из важных аспектов тестирования является генерация тестовых наборов, причем важна полнота таких наборов. Преимуществом тестирования на основе моделей является, во-первых, то, что тестовые наборы могут быть сгенерированы автоматически, и, во-вторых, то, что можно исследовать свойства программной системы без ее запуска.
Для поиска оптимальных сценариев тестирования обратимся к теории графов. Допустим, нужно пройти все переходы системы и совершить при этом минимальное число переходов. Данная проблема соответствует задаче нью-йоркского чистильщика улиц (New York Street Sweeper Problem (Beltrami, 1977; Bodin & Tucker, 1983)). Для ее решения необходимо привести граф системы условно к Эйлерову графу. Для начала для каждой вершины (состояния) следует посчитать полярность как разницу между числом входящих и исходящих дуг (переходов) [3]. Ясно, что для всего графа суммарная полярность всех вершин равна 0. Мы мо-]| жем «добавить» в граф дуги, которые изме-Ц нят ненулевую полярность вершины, сде-| лав ее 0, и при этом не изменят структуру ! графа, только «добавив» еще дуги, парал-Ц лельно дугам, которые уже есть. Это позво-| лит пройти все дуги (возможно, проходя по g некоторым по нескольку раз — рис. 8). Ре-§ шение задачи (набор вершин состояний) ^ строится по модифицированному графу >| с использованием алгоритма поиска Эйле-S рового цикла в графе (сложность O(IQI)). § По статической модели можно прово-Ц дить также моделирование (симуляцию ра-g боты системы) с использованием метода И «случайная прогулка» (Random Walk). Наша
Рис. 8. Задача чистильщика улиц и ее решение [3]
132
модель является вероятностной, поэтому «случайности» будут происходить с заданной вероятностью.
Переведем модель в начальное состояние и на каждом шаге будем совершать вероятностный переход в какое-то состояние в соответствии с моделью. Этот процесс можно наглядно визуализировать. Отдельно следует учитывать вероятности перехода по исключению и переход в состояния, отмеченные флагом №. В результате можно получить некоторую статистику «прогона» модели.
Для анализа модели системы можно применять также статистические методы, связанные с Марковскими случайными процессами. Допустим, модель построена таким образом, что переход в следующее состояние зависит только от текущего, а не от предшествующих (Марковская цепь). Если Р — матрица вероятностей переходов (ру — вероятность перехода из /-го состояния в у-е) и после первого шага вероятность попасть из /-го состояния в у будет ру, после 2-го шага — р2 (т. е. матрица Р возводится в квадрат) и так далее, на N-м статистическом шаге рN.
Организация онлайн-тестирования
Онлайн-тестирование проводится в процессе прогона системы при помощи многопоточного тестирующего сервера. Компоненты тестируемой программной системы взаимодействуют друг с другом согласно ее бизнес-логике. Кроме этого, они взаимодействуют с сервером тестирующей системы — отсылают на него состояние, в котором система находится, а также состояние, в которое осуществляется переход (в соответствии с моделью на языке АХМ^). Отсылку состояний на сервер осуществляет код, встроенный в места описания состояний и переходов тестирующим препроцессором.
В отличие от языка АХМ^, который не зависит от используемого языка программирования, код, осуществляющий передачу состояний на сервер, зависит от языка программирования, среды разработки (необ-
ходимо подключать свои библиотеки в проект системы), а также от среды выполнения (например, приложения для мобильных устройств могут отсылать данные о состоянии, используя Socket, HTTP соединения поверх WAP, GPRS, EDGE; системы, ориентированные на веб-сервисы, могут использовать удаленные вызовы на базе протокола SOAP, а обычные настольные приложения — отсылать данные через http).
Поскольку тестирующий сервер обрабатывает множество запросов от потоков работающей системы, целесообразно снабдить данный сервер системой распределения (балансировки) нагрузки.
В результате работы системы и тестирующего сервера на любой момент времени строится динамическая модель совершенных переходов. Обозначим M = M(A) — множество дуг автомата A. Тогда если динамически построенная модель является подмножеством статической модели, описанной в предыдущем разделе, Mдин с Mстат, то модель описана верно, и система работает в соответствии со своей моделью. Иначе либо модель описана неверно, либо система работает неправильно (это проявляется в переходе в состояние, перехода в которое из данного состояния нет в модели).
Онлайн-тестирование позволяет также вести статистику совершенных переходов и, таким образом, отслеживать реальные вероятности перехода из состояния в состояние.
Накопленные вероятности переходов можно сравнивать с вероятностями, описанными при создании модели системы. Кроме того, можно использовать скорректированные в результате выполнения системы вероятности переходов в качестве базовых для проведения офлайн-симуляции работы и статистического вероятностного моделирования.
Нагрузочное тестирование
В настоящее время вопрос о тестировании приложений при одновременной работе с ними большого числа пользователей
№>6(18)2008
стоит очень остро. Применяемые при про- §
мышленном тестировании приложения (кро- ^
ме, может быть, WebLoad) тестируют только ^
веб-сайты. эё
Для сложных взаимодействующих сис- Ч
тем (совсем не обязательно веб-сайтов) £
предполагается расширить онлайн-тести- §
рование на основе описанной модели, до- is
бавив средства для проведения нагрузоч- ^
ного тестирования. tj
Для проведения нагрузочного тестирования предлагается использовать метод виртуального пользователя. Виртуальный пользователь — это тоже модель.
Мв.польз ^ Мдин ^ Мстат.
Действия пользователя с системой записываются один раз, а потом создается N (большое число) виртуальных пользователей, которые работают по записанному сценарию.
Технически это возможно реализовать при помощи средств в современных языках программирования — Reflection и сериали-зации. Reflection позволяет в процессе работы программы получить доступ ко всем ее объектам, а сериализация — сохранить какой-то объект в памяти или на диске и потом восстановить его.
Само тестирование при помощи тестирующего сервера проводится следующим образом: при записи действий пользователя, перед тем как перейти в следующее состояние, запомнить состояние всех объектов системы на сервере и при входе в состояние при тестировании восстановить объекты из запомненных данных. Для корректной работы необходимо правильно выделить состояния, чтобы последовательность состояний системы образовывала Марковскую цепь, т.е. поведение системы зависело не от уже пройденных состояний, а только от последнего состояния и функции перехода.
Заключение
В данной статье рассмотрены методы для тестирования программных систем на
^^v 133
N96(18)2008
основе как уже имеющихся, так и разработанных моделей.
В настоящее время проходит реализация рассмотренных идей. Работа поддержана Фондом содействия развитию малых форм предприятий в научно-технической сфере при поддержке Федерального агентства по науке и инновациям (программа «Участник молодежного научно-инновационного конкурса»).
Предварительная реализация системы показывает правильность полученных выводов.
После реализации системы будет проведен эксперимент над некоторыми реальными распределенными системами с целью построения их модели и проверки правильности их работы.
Список литературы
1. Материалы конференции Microsoft Academic Days 2005 Russia. Режим доступа: http://www. microsoft.com/Rus/AcademicDays2005/Default.mspx
2. El-Far. Model-based, Software Testing / Ibrahim K. El-Far, Whittaker J.A. Florida Institute of Tech-
Ц nology, Encyclopedia on Software Engineering (edi* ted by J.J. Marciniak). Wiley, 2001. Режим доступа: | http://www.geocities.com/model_based_testing/ ji ModelBasedSoftwareTesting.pdf о 3. Robinson H. Graph. Theory Techniques in Mo-<u del-Based Testing / Harry Robinson, Semantic Plat-| forms Test Group, Microsoft Corporation. Режим доступа: http://www.geocities.com/harry_robinson_ >s testing/graph_theory.htm
!g 4. Campbell С. Model-Based Testing of Object-<э Oriented Reactive Systems with Spec Explorer / Colin ¡1 Campbell, Wolfgang Grieskamp, Lev Nachmanson, S3 Wolfram Schulte, Nikolai Tillmann, Margus Veanes. | May 2005. Technical Report MSR-TR-2005-59. Ре-§ жим доступа: http://research.microsoft.com/research/ pubs/view.aspx?type=Technical%20Report&id=912 Ц 5. BlassA. Play to Test/ Andreas Blass, Yuri Gu-щ revich, Lev Nachmanson, and Margus Veanes. Tech-i§ nical Report MSR-TR-2005-04. Режим доступа:
СО
^ http://research.microsoft.com/research/pubs/view. § aspx?type=Technical%20Report&id=851 ^ 6. Barnett M. The Spec# Programming System: An Overview / Mike Barnett, K. Rustan M. Leino, and
134 у
Wolfram Schulte. Microsoft Research, Redmond, WA, USA Режим доступа: http://research.microsoft. com/~leino/papers/krml136.pdf
7. Nachmanson L. Optimal Strategies for Testing Nondeterministic Systems / Lev Nachmanson Margus Veanes, Wolfram Schulte, Nikolai Tillmann, Wolfgang Grieskamp. Microsoft Research, One Microsoft Way, Redmond, WA Режим доступа: http://research. microsoft.com/~schulte/Papers/ OptimalStrategiesForTestingNondeterminsticSystems (ISSTA2004).pdf
8. Campbell С. Testing Concurrent Object-Oriented Systems with Spec Explorer. Extended Abstract / Colin Campbell, Wolfgang Grieskamp, Lev Nach-manson,Wolfram Schulte, Nikolai Tillmann, and Mar-gus Veanes. Microsoft Research, Redmond, USA Режим доступа: http://www.win.tue.nl/ipa/archive/ springdays2006/Veanes(FM2005).pdf
9. Gurevich Y. Evolving Algebras 1993: Lipari Guide / E. Borger (ed.), Specification and Validation Methods, Oxford University Press, 1995, 9-36. (ISBN 0-198-53854-5).
10. Кознов Д. В. Апробация технологии тестирования UniTesK/Кознов Д. В., Арчак Н.А. //Системное программирование: Сб. ст. / С.-Петерб. гос. ун-т. 2004. С. 335-347.
11. JavaTESK: Быстрое знакомство. Документация. Режим доступа: www.unitesk.ru
12. БаранцевА.В. Подход UniTesK к разработке тестов: достижения и перспективы / А.В. Ба-ранцев, И. Б. Бурдонов, А. В. Демаков, С. В. Зеле-нов, А.С. Косачев, В.В. Кулямин, В.А. Омельченко, Н.В. Пакулин, А.К. Петренко, А.В. Хорошилов. Труды Института системного программирования РАН. Режим доступа: http://www.ict.edu.ru/ft/005144/ unitesk.pdf
13. BertolinoA. Towards Anti-Model-based Testing / Antonia Bertolino and Andrea Polin, Istituto di Scienza e Tecnologie dell'Informazione «A. Faedo» (ISTI-CNR); Paola Inverardi and Henry Muccini, Dipartimento di Informatica Universit'a dell'Aquila.
14. Kiczales G. Аспектно-ориентированное программирование / Gregor Kiczales, John Lamping, Anurag Mndheker, Chris Maeda, Cristina Vi-deira Lopes, Jean-Marc Loingtier, John Irwin. European conference on Object-Oriented programming, June 1997. Режим доступа: http://www.javable. com/columns/aop/workshop/02/index.pdf
