close

Вход

Забыли?

вход по аккаунту

?

Тестирование распределенных приложений на основе построения моделей.

код для вставкиСкачать
С. М. Старолетов, Е. Н. Крючкова
Тестирование распределенных приложений
на основе построения моделей
Сегодня рынок программного обеспечения постепенно переходит от программ
ных систем, выполняющихся на одном настольном компьютере, к распределенным
системам, работающим на нескольких устройствах через локальную сеть организа
ции или глобальную сеть Интернет. Причем устройствами могут быть как обычные
компьютеры, так и «умное» оборудование (сотовые телефоны, КПК, банкоматы,
mp3плейеры, UP’n’Pэлектролампочки, джакузи с вебсервисами и многое другое).
В
настоящее время нередки случаи,
когда приложения состоят из компо
нентов, реализованных на различ
ных языках программирования и работаю
щих на разных платформах. Следователь
но, сложность программных систем резко
возрастает за счет межкомпонентного
(межпрограммного, межплатформенного)
взаимодействия. На рис. 1 в качестве при
мера показана схема сегодняшнего типово
го приложения по замыслу Sun Microsys
tems, которое включает серверную часть,
тонкие клиенты через браузер, настольный
клиент и ПО для мобильных устройств.
Рис. 1. Типовое современное приложение
(Sun Microsystems)
В связи со сложностью продуктов воз
растают и требования к качеству программ
ного обеспечения, и этого качества при
держиваться становится все труднее. Для
обеспечения качества программного про
124
дукта необходимо его обязательное тести
рование в процессе разработки, перед за
пуском в продажу и внедрением.
Тестирование — самая популярная мето
дика повышения качества, подкрепленная
многими исследованиями и богатым опы
том разработки коммерческих приложений.
Существует множество видов тестирова
ния: одни обычно выполняют сами разра
ботчики, а другие — специализированные
группы. Виды тестирования перечислены
ниже.
· Блочным тестированием называют
тестирование полного класса, метода или
небольшого приложения, написанного од
ним программистом или группой, выполняе
мое отдельно от прочих частей системы.
· Тестирование компонента – это тести
рование класса, пакета, небольшого при
ложения или другого элемента системы,
разработанного несколькими программи
стами или группами, выполняемое в изоля
ции от остальных частей системы.
· Интеграционное тестирование – это
совместное выполнение двух или более
классов, пакетов, компонентов или подсис
тем, созданных несколькими программи
стами или группами. Этот вид тестирования
обычно начинают проводить, как только
созданы два класса, которые можно про
тестировать, и продолжают до завершения
работы над системой.
Лаборатория R Испытание технологий
Во всех компаниях по производству
программного обеспечения цикл разра
ботки ПО включает фазу тестирования,
причем в некоторых методологиях процес
са разработки тестирование не выделя
ется в отдельную фазу, а ведется на всех
фазах разработки, и даже тесты пишут
ся до написания кода. Должность «тести
ровщик» (тестер, QA manager) — не ред
кость, а в крупных компаниях мирового
уровня эта профессия — одна из важных
и высокооплачиваемых. Однако по мере
возрастания сложности системы для га
рантии ее безошибочной работы будет
требоваться все больше тестеров, и может
наступить момент, когда рост числа людей
уже не сможет гарантировать качества
продукта [1]. Это означает, что необхо
димы автоматизированные средства тес
тирования сложных взаимодействующих
систем, причем на основе новых методо
логий.
Что тестируем?
В распределенных системах главное —
взаимодействие между компонентами, ко
торое происходит по каналам связи. В ре
зультате ошибок при соединениях логика
работы может быть нарушена. Следова
тельно, необходимо проверять соответст
вие ожидаемого и реального поведения
всей системы, определять узкие места сис
Лаборатория R Испытание технологий
темы во время взаимодействия и знать,
в каком состоянии находится система в лю
бой заданный момент времени.
Кроме того, приложение может содер
жать несколько экземпляров как клиентов,
так и серверов, и может случиться, что сис
тема при небольшом числе клиентов рабо
тает нормально, а при большом — дает
серьезные сбои или очень медленно реаги
рует на действия пользователей. Следова
тельно, необходимо произвести тестирова
ние на отказоустойчивость.
Подход
В статье предлагается использовать
подход к тестированию программ на основе
построения моделей [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), разработанная
профессором университета Мичиган Юри
ем Гуревичем (ныне — научный сотрудник
125
С. М. Старолетов, Е. Н. Крючкова
· Регрессивным тестированием назы
вают повторное выполнение тестов, на
правленное на обнаружение дефектов
в программе, уже прошедшей этот набор
тестов.
· Тестирование системы — это выпол
нение ПО в его окончательной конфигура
ции, интегрированного с другими про
граммными и аппаратными системами.
Предметом тестирования в этом случае яв
ляются безопасность, производительность,
утечка ресурсов, проблемы синхронизации
и прочие аспекты, которые невозможно
протестировать на более низких уровнях
интеграции.
Microsoft Research, Редмонд, штат Вашинг
тон).
В конце 1980х годов Гуревич расширил
тезис Тьюринга о том, что каждый алгоритм
симулируется соответствующей машиной
Тьюринга, тезисом ASM: каждый алгоритм,
не важно какой абстракции, шаг за шагом
эмулируется соответствующей ему маши
ной ASM [9].
Для тестируемой системы строится сле
дующая модельмашина:
M = ( S init , S , S acc , Obs, Ctrl , d ),
Тестирование распределенных приложений на основе построения моделей
где S — конечное множество состояний
системы1;
S init Ì S — непустое подмножество на
чальных состояний;
S acc Ì S — подмножество заключитель
ных состояний.
Acts — множество действий по переходу
из одного состояния в другое, оно разделя
ется на 2 подмножества: Acts = Obs È Ctrl,
где Obs — множество обозреваемых дейст
вий; Ctrl — множество контролируемых дей
ствий.
В [5] приводится аналогия «тестирова
ние как игра», игра с природой, в которой
мы делаем шаг (переход из состояния в со
стояние в результате работы логики про
граммы — контролируемое действие), и при
рода делает шаг (возникновение события
или исключение — обозреваемое действие).
Функция переходов имеет вид:
d Ì S × Acts × S.
Поведение системы (модель) в данной
методологии описывается на специальном
языке выполнимых спецификаций Spec#
(расширение C#) — в среде Visual Studio
или на языке ASML (Abstract State Mashine
Language) внутри документов Word.
Модель описывает переменные состоя
ний и переходы. Шаги машины (т. е. перехо
ды между состояниями) — выполнение ме
тодов модулируемой программы, которые
удовлетворяют данным предусловиям со
стояния. В результате Spec Explorer строит
конечный граф с состояниями и перехода
ми, которые представляют подмножества S
и Acts.
Поскольку в реальных системах пере
менных может быть много и они могут при
нимать большое количество значений, ито
говый граф системы будет хотя и конечным,
но с очень большим числом состояний и пе
реходов между ними. Работа с таким гра
фом затруднена, поэтому необходимо при
нимать специальные меры для сокращения
числа состояний.
Результатом работы Spec Explorer явля
ются автоматически сгенерированные тест
кейсы (test cases — тестовые наборы) пове
дения системы, которые могут быть запу
щены вместе с тестируемой системой для
проверки описанного и полученного пове
дения.
Spec Explorer поддерживает 2 вида тес
тов: офлайн и онлайн. Для офлайнтестиро
вания автомат модели сводится к автомату,
представляющему план тестирования (test
suite), который потом компилируется в от
дельную программу. Для онлайнтестирова
ния обзор модели и проверка соответствия
соединены в один алгоритм. Если тестируе
мая система представляет собой нераспре
деленную .NET программу, то тестпрограм
ма будет создана инструментом автомати
чески. В других случаях пользователю сле
дует написать обертку (wrapper) на .NET
языке, которая реализует актуальную реа
лизацию, используя средства .NET для
взаимодействия.
Итак, Microsoft Spec Explorer обеспечи
вает средства для автоматизированного
тестирования с построением моделей в ви
де конечных автоматов. Продукт пока ис
пользуется только внутри Microsoft и досту
1
Под состоянием в данном случае понимается набор значений выбранных переменных системы, которые
имеют наибольшее значение для логики работы программы. Изменение хотя бы одной переменной системы ве
дет к появлению нового состояния.
126
Лаборатория R Испытание технологий
С. М. Старолетов, Е. Н. Крючкова
Рис. 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++, Java и C# приложений,
а также специальные средства для тестиро
вания компиляторов.
Лаборатория R Испытание технологий
При тестировании с помощью UniTesK
система рассматривается в виде «черного
ящика», т. е. тестируется ее интерфейс —
набор классов или функций. Сами тесты ге
нерируются автоматически по специфика
ции системы и тестовым сценариям [10].
Спецификация системы пишется на одном
из разработанных языков — расширений
для языков Java, C, C# (языковые расшире
ния достаточно обширные — так, напри
мер, описание языка SeC занимает 188 с.)
и представляет собой набор пред, пост
условий, инвариантов, описывающих тре
бования к системе. Тестовый сценарий опи
сывает конечный автомат, определяющий
тестируемые состояния системы и воздей
ствия на систему в процессе тестирова
ния. В результате тестирования обходчик
UniTesK динамически строит конечный ав
томат пройденных состояний.
На рис. 3 приведен автомат, построен
ный обходчиком UniTesK после прогона тес
та [11].
На конференции MS Academic Days [1]
один из разработчиков системы В. Кулямин
рассказал о тестировании распределенных
систем с помощью технологии UniTesK.
Для описания систем предполагается
использовать контрактные спецификации
127
Тестирование распределенных приложений на основе построения моделей
Рис. 3. Автомат обходчика
(контракт — обязательство среды и компо
нента друг перед другом, предусловие опре
деляет обязательство среды перед компо
нентом, а постусловие — компонента перед
средой), в качестве расширения подхода
для распределенных систем — событийные
контракты (Event Contracts), поскольку со
бытия могут возникать асинхронно (преду
словие — предикат, который описывает,
в каких состояниях данное событие воз
можно, постусловие — в какие состояния
можно попасть из данного состояния после
возникновения события).
Сам процесс тестирования состоит
в воздействии на систему, но не последова
тельно, а последовательнопараллельно
(рис. 4). Осуществляется воздействие на
систему с малыми задержками между воз
действиями и получение ответов. Получен
ное множество состояний проверяется на
корректность заданных событийных кон
трактов. Если система удовлетворяет ак
сиоме чистого параллелизма (plain concur
128
rency axiom), т. е. результат параллельного
выполнения любого набора вызовов опера
ций такой системы такой же, как при выпол
нении того же набора вызовов в некотором
порядке, и если обработанные системой
воздействия и полученные от нее асинхрон
ные реакции можно линейно упорядочить
таким образом, что в полученной последо
вательности перед каждыми вызовом или
реакцией будет выполнено его/ее преду
словие, а после — постусловие (рис. 5), то
система ведет себя корректно (ее наблю
Рис. 4. Тестовое воздействие
на распределенную систему
Лаборатория R Испытание технологий
A = (Q, D, E , d, q0 , F ).
Рис. 5. Линейное упорядочение
даемое поведение не противоречит специ
фикациям) [12].
Если такого упорядочения построить
нельзя, значит, обнаружено несоответст
вие поведения системы спецификациям.
Таким образом, технология UniTesK по
зволяет проводить тестирование систем на
основе моделей, описываемых при помощи
спецификаций. Технология продается «в ко
робочном варианте», но о той части, кото
рая проводит тестирование распределен
ных систем, на официальном сайте не ука
зано (не указана и поддержка языка С# —
лишь C и Java). И не понятно, реализованы
ли эти идеи на практике. Главным аспектом,
тормозящим развитие технологии, является
сложность описания модели при помощи
пред и постусловий, особенно когда про
дукт представляет собой реальную систему
для автоматизации какогото процесса без
строгих требований к ней. Для работы с сис
темой UniTesK нужно высшее математиче
ское образование.
Предлагаемая математическая модель
В данной статье приводится описание
распределенных систем с помощью собст
венной математической модели, средств
для тестирования и моделирования для тес
теров и программистов без особой матема
тической подготовки.
Будем руководствоваться тезисом ма
шин абстрактных состояний и формиро
Лаборатория R Испытание технологий
Опишем подробно все указанные мно
жества применительно к тестируемой про
граммой системе.
Q — конечное множество состояний. Со
стояние системы — важный с точки зрения
логики работы системы участок кода, кото
рый выделяется разработчиком (или тесте
ром) вручную или с помощью разработан
ных средств. В этом коренное отличие
предлагаемого подхода от выше рассмот
ренных, в которых новое состояние созда
ется при изменении значения переменной
из набора ключевых переменных. Преиму
щества нашего подхода к выделению со
стояний заключаются в следующем: более
легкое описание для пользователей, что по
зволяет абстрагироваться от переменных и
сконцентрироваться на собственно взаимо
действии, а также более легкий способ об
работки описываемого автомата тестирую
щей системой.
q0 Ì Q — начальное состояние автомата,
точка входа в программу.
F Ì Q — множество заключительных со
стояний системы.
d — функция переходов, определим ее
следующим образом:
d : Q × (D È ( E È {e})) × P × ( N È {1}) ® 2Q ×( E È { 1}) ×W .
D — множество действий, идентифици
рующих переход из состояния в состояние.
Действие — это словесный тег, отвечаю
щий на вопрос «почему мы перешли из за
данного состояния в следующее задан
ное?». Действие — это надпись на дуге пе
рехода между двумя состояниями.
129
С. М. Старолетов, Е. Н. Крючкова
вать модель программной системы в виде
конечного автомата.
На основе анализа предметной области
было решено использовать вероятностный
конечный автомат и расширить его для опи
сания реальных взаимодействующих сис
тем с учетом событий и исключений.
Итак, вся взаимодействующая система
представляется в виде расширенного веро
ятностного конечного автомата:
Тестирование распределенных приложений на основе построения моделей
E — множество исключительных ситуа
ций или событий (по аналогии с Obs от
Microsoft Research). Во время выполнения
перехода из состояние в состояние возмож
ны генерация исключения или возникнове
ние события. События и исключения возни
кают асинхронно и описываются особенно.
P — вероятность перехода из заданного
состояния в следующее заданное. Предпо
лагаемая модель является вероятностной и
в отличие от модели Microsoft Research, где
вероятности присутствуют при «тестирова
нии как игре» [5], когда «природа» делает
шаг в соответствии с какойлибо вероятно
стью (т. е. случается событие), в нашей мо
дели вероятностные переходы осуществля
ются и при прямых переходах. Например,
для тестирования if (A) B; else C можно стро
ить систему пред и постусловий, а можно
поставить задачу прохождения ветви B с ус
ловной вероятностью P(B|A) и ветви C с ве
роятностью P(C | Ø A).
В нашей модели вероятности подразде
ляются на априорные и апостериорные.
Априорными (P0) называются вероятно
сти, которые могут быть определены до за
пуска системы — как примерное, ожидае
мое поведение системы.
Апостериорными (динамическими) явля
ются вероятности переходов, которые были
рассчитаны тестирующей системой для мо
дели в процессе выполнения системы для
каждой из пар (qi; qj), таких, что существует
дуга из iго состояния в jе, в какойто мо
мент времени. В процессе работы системы
вероятности меняются, поэтому можно счи
тать, что Pij = Pij(t), где t — время прогона, или
Pi j = Pij(k), где k — число совершенных пере
ходов, i, j <= |Q|. Подробнее про динамиче
ское тестирование будет сказано позднее.
N — кратность (по умолчанию кратность
равна 1). Для описания систем с нескольки
ми взаимодействующими друг с другом кли
ентами или многопоточных систем, логика
которых предполагает не просто взаимо
действие, а зависимость перехода в другое
состояние от подключенных клиентов (пото
ков), вводится понятие кратности — количе
130
Рис. 6. Переход по кратности 2
(2 клиента и сервер)
ства подключенных клиентов. Например, чат
может начинать работу, когда к нему под
соединятся два пользователя, в этом случае
имеем переход по кратности 2 (рис. 6).
В дальнейшем предполагается расши
рить описание модели и ввести примитивы
синхронизации.
W — флаг ошибки, или ошибочного со
стояния. Разработчик системы может опре
делить те состояния системы, попадание
в которые служит сигналом об ошибочной
работе. При попадании в эти состояния
система динамического тестирования учтет
этот факт и сообщит об этом.
Modelbased и antimodelbased
тестирование
В тестировании на основе моделей стро
ится модель системы по исходному коду, на
ее основе генерируются тестовые наборы,
производится сверка модели и системы.
В противовес тестированию на основе мо
делей (model based testing) в статье [13]
описывается шаблон тестирования (pattern)
antimodelbased testing, при котором систе
ма выполняется, и в процессе ее выполне
ния и мониторинга строится ее динамиче
ская модель — как работала тестируемая
система во время теста.
В данном исследовании предлагается
описывать модель тестируемой распреде
Лаборатория R Испытание технологий
Описание модели системы
для тестирования
Для описания модели системы предлага
ется использовать подход «код и модель —
единое целое». Модель будем описывать на
специально разработанном языке описа
ния моделей в специального вида коммен
тариях к исходному коду. При этом исход
ный код модулей системы может быть напи
сан на различных языках программирова
ния, тогда как модель описывается всегда
на одном языке, не зависящем от исполь
зуемого языка разработки. Для облегчения
синтаксической обработки языка описания
моделей, а также в связи с общей тенденци
ей в программировании было решено, что
язык описания моделей будет создан на ос
нове XML. Разработанный нами язык (Auto
matto XML, AXML) определяет теги для опи
сания состояний конечного автомата и пере
ходов в соответствии с функцией перехо
дов d. Атрибуты тегов — это дополнитель
ные свойства состояний, они определяются
функцией d.
Как было указано ранее, состояния авто
мата выделяются разработчиком/тестером
в комментариях к исходному модулю. Описы
вается состояние системы, внутри него — по
лезный код состояния (бизнеслогика работы)
и переходы из данного состояния в другие:
//<state name='state1' >
// код состояния на языке программирования
// условия
// переход
//<go state='state2' p='10%' on='connect'/>
//
//</state>
Лаборатория R Испытание технологий
Данному коду соответствует рис. 7.
Рис. 7. Переход между состояниями автомата
Набор атрибутов определяется сложно
стью перехода (см. описание математиче
ской модели) и впоследствии может быть
расширен.
Поскольку разработчики пишут код в сво
их привычных средах разработки, целесо
образно разработать модули поддержки
описания модели системы для популярных
сред программирования (addin для MS
Visual Studio, plugin для Eclipse).
Обработка данных описаний тестирую
щей системой должна происходить следую
щим образом:
· все значащие комментарии (т. е. со
держащие описание модели) из файлов
с исходным кодом различных модулей сис
темы в соответствии с предварительно соз
данным проектом собираются в один файл,
который содержит описания модели на язы
ке AXML для всей системы в целом и будет
использован для проведения офлайнтес
тирования;
· на местах описания состояний и пере
ходов по описанию модели генерируется спе
циальный код (уже зависящий от языка про
граммирования исходного кода модуля), кото
рый при работе отсылает данные о текущем
состоянии, о состояниях, в которые осуще
ствляется переход на многопоточный сервер
тестирующей системы. (В этом месте воз
можно применение аспектноориентирован
ной модели программирования [14]).
Организация процесса
офлайнAтестирования
В предыдущих разделах было описано,
как получить модель тестируемой системы.
Полученную статическую модель с перехо
дами будем считать ориентированным гра
фом системы, где состояния соответствуют
вершинам, а переходы — дугам.
131
С. М. Старолетов, Е. Н. Крючкова
ленной системы, затем проводить тестиро
вание модели системы (будем называть это
офлайн или статическим тестированием),
а также по работающей системе, используя
описание состояний, строить ее динамиче
скую модель и сравнивать ее со статиче
ской моделью (онлайн или динамическое
тестирование). Таким образом, предполага
ется реализация как modelbased, так и anti
modelbased тестирования.
Тестирование распределенных приложений на основе построения моделей
Одной из важных аспектов тестирования
является генерация тестовых наборов, при
чем важна полнота таких наборов. Преиму
ществом тестирования на основе моделей
является, вопервых, то, что тестовые набо
ры могут быть сгенерированы автоматиче
ски, и, вовторых, то, что можно исследо
вать свойства программной системы без ее
запуска.
Для поиска оптимальных сценариев тес
тирования обратимся к теории графов. До
пустим, нужно пройти все переходы систе
мы и совершить при этом минимальное чис
ло переходов. Данная проблема соответст
вует задаче ньюйоркского чистильщика
улиц (New York Street Sweeper Problem (Belt
rami, 1977; Bodin & Tucker, 1983)). Для ее ре
шения необходимо привести граф системы
условно к Эйлерову графу. Для начала для
каждой вершины (состояния) следует по
считать полярность как разницу между чис
лом входящих и исходящих дуг (переходов)
[3]. Ясно, что для всего графа суммарная
полярность всех вершин равна 0. Мы мо
жем «добавить» в граф дуги, которые изме
нят ненулевую полярность вершины, сде
лав ее 0, и при этом не изменят структуру
графа, только «добавив» еще дуги, парал
лельно дугам, которые уже есть. Это позво
лит пройти все дуги (возможно, проходя по
некоторым по нескольку раз — рис. 8). Ре
шение задачи (набор вершин состояний)
строится по модифицированному графу
с использованием алгоритма поиска Эйле
рового цикла в графе (сложность O(|Q|)).
По статической модели можно прово
дить также моделирование (симуляцию ра
боты системы) с использованием метода
«случайная прогулка» (Random Walk). Наша
Рис. 8. Задача чистильщика улиц и ее решение [3]
132
модель является вероятностной, поэтому
«случайности» будут происходить с задан
ной вероятностью.
Переведем модель в начальное состоя
ние и на каждом шаге будем совершать ве
роятностный переход в какоето состояние
в соответствии с моделью. Этот процесс
можно наглядно визуализировать. Отдель
но следует учитывать вероятности перехо
да по исключению и переход в состояния,
отмеченные флагом W. В результате можно
получить некоторую статистику «прогона»
модели.
Для анализа модели системы можно при
менять также статистические методы, свя
занные с Марковскими случайными про
цессами. Допустим, модель построена та
ким образом, что переход в следующее со
стояние зависит только от текущего, а не от
предшествующих (Марковская цепь). Если
P — матрица вероятностей переходов (pij —
вероятность перехода из iго состояния
в jе) и после первого шага вероятность по
пасть из iго состояния в j будет pij, после
2го шага — pij2 (т. е. матрица P возводится
в квадрат) и так далее, на Nм статистиче
ском шаге pijN .
Организация онлайнAтестирования
Онлайнтестирование проводится в про
цессе прогона системы при помощи много
поточного тестирующего сервера. Компо
ненты тестируемой программной системы
взаимодействуют друг с другом согласно ее
бизнеслогике. Кроме этого, они взаимодей
ствуют с сервером тестирующей системы —
отсылают на него состояние, в котором сис
тема находится, а также состояние, в кото
рое осуществляется переход (в соответ
ствии с моделью на языке AXML). Отсылку
состояний на сервер осуществляет код,
встроенный в места описания состояний
и переходов тестирующим препроцессором.
В отличие от языка AXML, который не за
висит от используемого языка программи
рования, код, осуществляющий передачу
состояний на сервер, зависит от языка про
граммирования, среды разработки (необ
Лаборатория R Испытание технологий
Нагрузочное тестирование
В настоящее время вопрос о тестирова
нии приложений при одновременной рабо
те с ними большого числа пользователей
Лаборатория R Испытание технологий
стоит очень остро. Применяемые при про
мышленном тестировании приложения (кро
ме, может быть, WebLoad) тестируют только
вебсайты.
Для сложных взаимодействующих сис
тем (совсем не обязательно вебсайтов)
предполагается расширить онлайнтести
рование на основе описанной модели, до
бавив средства для проведения нагрузоч
ного тестирования.
Для проведения нагрузочного тестиро
вания предлагается использовать метод
виртуального пользователя. Виртуальный
пользователь — это тоже модель.
Mв.польз Í Mдин Í Mстат .
Действия пользователя с системой запи
сываются один раз, а потом создается N
(большое число) виртуальных пользовате
лей, которые работают по записанному
сценарию.
Технически это возможно реализовать
при помощи средств в современных языках
программирования — Reflection и сериали
зации. Reflection позволяет в процессе ра
боты программы получить доступ ко всем ее
объектам, а сериализация — сохранить
какойто объект в памяти или на диске и по
том восстановить его.
Само тестирование при помощи тести
рующего сервера проводится следующим
образом: при записи действий пользовате
ля, перед тем как перейти в следующее со
стояние, запомнить состояние всех объек
тов системы на сервере и при входе в со
стояние при тестировании восстановить
объекты из запомненных данных. Для кор
ректной работы необходимо правильно вы
делить состояния, чтобы последователь
ность состояний системы образовывала
Марковскую цепь, т. е. поведение системы
зависело не от уже пройденных состояний,
а только от последнего состояния и функ
ции перехода.
Заключение
В данной статье рассмотрены методы
для тестирования программных систем на
133
С. М. Старолетов, Е. Н. Крючкова
ходимо подключать свои библиотеки в про
ект системы), а также от среды выполнения
(например, приложения для мобильных уст
ройств могут отсылать данные о состоянии,
используя Socket, HTTP соединения поверх
WAP, GPRS, EDGE; системы, ориентирован
ные на вебсервисы, могут использовать
удаленные вызовы на базе протокола SOAP,
а обычные настольные приложения — от
сылать данные через http).
Поскольку тестирующий сервер обраба
тывает множество запросов от потоков ра
ботающей системы, целесообразно снаб
дить данный сервер системой распределе
ния (балансировки) нагрузки.
В результате работы системы и тести
рующего сервера на любой момент време
ни строится динамическая модель совер
шенных переходов. Обозначим M = M( A) —
множество дуг автомата A. Тогда если дина
мически построенная модель является под
множеством статической модели, описан
ной в предыдущем разделе, M дин Í M стат , то
модель описана верно, и система работает
в соответствии со своей моделью. Иначе
либо модель описана неверно, либо систе
ма работает неправильно (это проявляется
в переходе в состояние, перехода в которое
из данного состояния нет в модели).
Онлайнтестирование позволяет также
вести статистику совершенных переходов
и, таким образом, отслеживать реальные
вероятности перехода из состояния в со
стояние.
Накопленные вероятности переходов
можно сравнивать с вероятностями, опи
санными при создании модели системы.
Кроме того, можно использовать скоррек
тированные в результате выполнения сис
темы вероятности переходов в качестве ба
зовых для проведения офлайнсимуляции
работы и статистического вероятностного
моделирования.
основе как уже имеющихся, так и разрабо
танных моделей.
В настоящее время проходит реализа
ция рассмотренных идей. Работа поддер
жана Фондом содействия развитию малых
форм предприятий в научнотехнической
сфере при поддержке Федерального агент
ства по науке и инновациям (программа
«Участник молодежного научноинноваци
онного конкурса»).
Предварительная реализация системы
показывает правильность полученных вы
водов.
После реализации системы будет прове
ден эксперимент над некоторыми реальны
ми распределенными системами с целью
построения их модели и проверки правиль
ности их работы.
Тестирование распределенных приложений на основе построения моделей
Список литературы
1. Материалы конференции Microsoft Acade
mic Days 2005 Russia. Режим доступа: http://www.
microsoft.com/Rus/AcademicDays2005/Default.mspx
2. ElFar. Modelbased, Software Testing / Ibra
him K. ElFar, 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/
ModelBasedSoftwareTesting.pdf
3. Robinson H. Graph. Theory Techniques in Mo
delBased Testing / Harry Robinson, Semantic Plat
forms Test Group, Microsoft Corporation. Режим
доступа: http://www.geocities.com/harry_robinson_
testing/graph_theory.htm
4. Campbell С. ModelBased Testing of Object
Oriented Reactive Systems with Spec Explorer / Colin
Campbell, Wolfgang Grieskamp, Lev Nachmanson,
Wolfram Schulte, Nikolai Tillmann, Margus Veanes.
May 2005. Technical Report MSRTR200559. Ре
жим доступа: http://research.microsoft.com/research/
pubs/view.aspx?type=Technical%20Report&id=912
5. Blass A. Play to Test/ Andreas Blass, Yuri Gu
revich, Lev Nachmanson, and Margus Veanes. Tech
nical Report MSRTR200504. Режим доступа:
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 Tes
ting Nondeterministic Systems / Lev Nachmanson
Margus Veanes, Wolfram Schulte, Nikolai Till
mann, Wolfgang Grieskamp. Microsoft Research,
One Microsoft Way, Redmond, WA Режим досту
па: http://research. microsoft.com/~schulte/Papers/
OptimalStrategiesForTestingNondeterminsticSystems
(ISSTA2004).pdf
8. Campbell С. Testing Concurrent ObjectOri
ented 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, 936. (ISBN
0198538545).
10. Кознов Д. В. Апробация технологии тести
рования UniTesK / Кознов Д. В., Арчак Н. А. // Сис
темное программирование: Сб. ст. / С.Петерб.
гос. унт. 2004. С. 335–347.
11. JavaTESK: Быстрое знакомство. Докумен
тация. Режим доступа: www.unitesk.ru
12. Баранцев А. В. Подход UniTesK к разработ
ке тестов: достижения и перспективы / А. В. Ба
ранцев, И. Б. Бурдонов, А. В. Демаков, С. В. Зеле
нов, А.С. Косачев, В.В. Кулямин, В.А. Омельченко,
Н. В. Пакулин, А. К. Петренко, А. В. Хорошилов.
Труды Института системного программирования
РАН. Режим доступа: http://www.ict.edu.ru/ft/005144/
unitesk.pdf
13. Bertolino A. Towards AntiModelbased Tes
ting / Antonia Bertolino and Andrea Polin, Istituto di
Scienza e Tecnologie dell'Informazione «A. Faedo»
(ISTICNR); Paola Inverardi and Henry Muccini,
Dipartimento di Informatica Universit'a dell'Aquila.
14. Kiczales G. Аспектноориентированное
программирование / Gregor Kiczales, John Lam
ping, Anurag Mndheker, Chris Maeda, Cristina Vi
deira Lopes, JeanMarc Loingtier, John Irwin. Euro
pean conference on ObjectOriented programming,
June 1997. Режим доступа: http://www.javable.
com/columns/aop/workshop/02/index.pdf
Лаборатория R Испытание технологий
Документ
Категория
Без категории
Просмотров
6
Размер файла
7 809 Кб
Теги
построение, распределенный, основы, моделей, тестирование, приложение
1/--страниц
Пожаловаться на содержимое документа