Содержание к диссертации
Введение
1 Обзор современных подходов к процессу тестирования и его автоматизации 14
1.1 Тестирования программного обеспечения 14
1.1.1 Определение тестирования 14
1.1.2 Место тестирования в процессе разработки программного обеспечения 16
1.1.3 Различные подходы к тестированию 19
1.2 Количественные критерии качества тестирования 22
1.3 Модульное тестирование 27
1.3.1 Способы тестирования взаимодействия модулей 28
1.3.2 Стратегии выполнения пошагового тестирования 29
Нисходящее тестирование 29
Восходящее тестирование 31
1.3.3 Принципы тестирования структуры программных модулей 32
Показатели корректности тестирования структуры программных модулей 33
Оценка достигаемой корректности программ 35
1.4 Регрессионное тестирование 38
1.5 Автоматизированное тестирование 40
1.5.1 Unit-тестирование 40
1.5.2 Программные средства автоматизации тестирования 42
1.6 Выводы 47
1.6.1 Актуальность темы 47
1.6.2 Цель работы 49
2 Метод ключевых состояний автоматизации тестирования программных приложений 51
2.1 Описание метода и методики его применения 51
2.2 Разработка математической модели контекстного представления множества произвольных состояний 57
2.3 Разработка метода формирования множества понятий предметной области (кластеров) 62
2.4 Разработка метода классификации контекстных групп 68
2.5 Разработка метода контекстного распознавания архитипических систем 74
2.6 Теоретическое обоснование преимуществ разработанного метода .. 75
2.7 Язык описания тестов 79
2.7.1 Скрипт 79
2.7.2 Акции (действия) 80
2.7.3 Состояния 81
2.7.4 Проверка множества состояний 84
2.7.5 Динамические состояния 85
2.7.6 Динамические коллекции состояний 86
2.7.7 Сохранение состояния 87
2.7.8 Процедуры 88
Создание объектов 89
Удаление объектов 91
Изменение свойств объектов 92
2.7.9 Фабрики состояний 93
2.7.10 Фильтры состояний 94
2.7.11 Модификаторы параметров состояний 96
2.7.12 Примеры 98
Пример простейшего скрипта 98
Пример декларации действия 115
Примеры определения состояния 116
Пример описания проверки 117
Пример процедуры 119
2.8 Система поддержки автоматизированных тестов 121
2.9 Расширение нового метода автоматизации тестирования 125
3 Результаты применения разработанных методов 128
3.1 Анализ применения разработанных методов и средств 128
3.2 Выводы 135
Заключение 139
Литература
- Место тестирования в процессе разработки программного обеспечения
- Разработка математической модели контекстного представления множества произвольных состояний
- Теоретическое обоснование преимуществ разработанного метода
- Расширение нового метода автоматизации тестирования
Введение к работе
Актуальность темы исследования. Появление первых компьютеров повлекло за собой и появление их непременных спутников - компьютерных программ (программных продуктов). Программирование, как и любая человеческая деятельность, каковым оно является, практически невозможно без ошибок. И если на ранних этапах развития процесс отладки программ, в силу их достаточной примитивности не представлял большой проблемы, то в настоящее время картина происходящего резко изменилась.
Как известно, в процессе разработки программных продуктов программы подвергаются изменениям. Как бы хорошо они ни были написаны первоначально, в них вносятся изменения, обусловленные необходимостью исправления существующих ошибок, выявленных в процессе их выполнения, или же желанием внести в программу дополнительные изменения. Расширение областей применения старых программ приводит к появлению новых функциональных требований, не учтенных изначально.
Все вышесказанное привело к тому, что контроль над изменениями приобрел статус критического фактора для сохранения полезности программ [35], т.е. фактора, ставшего по степени значимости доминирующим, что не могло не привлечь внимания специалистов.
Исследование причин неудач при реализации больших программных проектов, проведенное в 80-х годах прошлого века [76], показало, что число ошибок в спецификациях на программы значительно превышает их количество в программных кодах. Так около 56% ошибок допускаются на этапе формулировки требований к программе, при этом расходуется в
среднем 82% всех усилий, затраченных коллективом на устранение ошибок проекта, в то время, как на этапе кодирования программ допускается соответственно 7% ошибок и тратится 1% усилий на их ликвидацию [76].
Кроме того, можно выделить пять наиболее важных этапов жизненного цикла программного средства:
спецификацию;
проектирование;
кодирование;
отладку;
сопровождение.
По затратам времени, человеческих и машинных ресурсов все эти этапы не одинаковы. Наиболее "дорогими", в этом смысле, являются этапы, связанные с поиском ошибок в программах. Затраты ресурсов на них могут быть равными или даже превосходить совокупные затраты ресурсов на остальных этапах. В стандарте DOD-STD-2167-A около 30% требований, документов и соответствующих им процессов непосредственно связаны с отладкой, тестированием и испытаниями программ. Данный стандарт является обязательным при выполнении заказов Министерства обороны США [26]. Эти затраты быстро увеличиваются при возрастании требований к качеству программного продукта. Следует учитывать, что значительная часть работ, выполняемых на этапе сопровождения, связана с поиском и устранением оставшихся в программе ошибок. Исследования [23, 63, 69] показали, что на долю устранения ошибок и сопровождение программного продукта приходится почти 75% всех затрат. Кроме того, и в случае внесения новых ошибок в программу на этап сопровождения приходятся огромные затраты.
Безусловно, подобная ситуация была неприемлема, поэтому существовавший стандартный процесс разработки программного
7 обеспечения подвергся некоторой модернизации. Было сформулировано
предложение, что для случаев повторной проверки корректности
существующей функциональности программы, унаследованной, к примеру,
в процессе разработки из предыдущей версии, необходимо использование
регрессионного тестирования [46, 52] - повторного тестирования части
программы, зависящей от внесенных изменений. Регрессионное
тестирование прекрасно подходит как для проверки корректности
изменений, внесенных в тестируемую систему, так и для проверки
корректности добавленных к системе новых компонентов и
функциональных возможностей. Кроме того, регрессионное тестирование
позволяет проверить, что внесенные в код программы изменения корректны
и не воздействуют неблагоприятно на остальные ее части. В случае же
обнаружения в программе новых ошибок считается, что в системе
появились регрессионные ошибки [56, 61]. Ввиду того, что поведение новой
версии программы должно совпадать с поведением предыдущей версии, за
исключением ситуаций, обусловленных внесением изменений,
соответствующих новым требованиям к системе, регрессионные системные
тесты можно рассматривать как частичные требования к новым версиям
системы. В большинстве случаев вместо регрессионного тестирования для
проверки того, что качество новой версии программы не ухудшилось,
выполняется множество всех тестов, используемых на этапе системного и
функционального тестирования продукта.
Регрессионное тестирование относится к необходимым методам
профилактического сопровождения и применяется в ходе процесса
разработки и модификации программного продукта. Однако, такой род
деятельности является крайне ресурсоемким и, как следствие,
дорогостоящим. Это обусловлено необходимостью проводить
регрессионное тестирование в случае внесения даже малейших изменений в
8 код программы, в то время, как процесс регрессионного тестирования может
включать в себя исполнение достаточно большого количества тестов на
скорректированной версии программы. И несмотря на то, что усилия,
требуемые для внесения небольших изменений, как правило, минимальны,
они могут требовать достаточно больших усилий для проверки качества
измененной программы [42, 43]. Тем не менее, надежная и эффективная
разработка и сопровождение программного обеспечения невозможны без
регрессионного тестирования [55]. Одним из очевидных решений здесь
является автоматизация процесса тестирования, помогающая ускорить
создание продукта и улучшить его качество.
Степень разработанности проблемы. На сегодняшний день существуют два общеизвестных способа автоматизации подобного тестирования. Одним из них является использование unit-тестов, начиная с начальных этапов разработки продукта. Вторым - использование на более зрелых этапах разработки различных программных инструментов автоматизации тестирования, так называемых, инструментов записи и воспроизведения тестов.
Использование программных инструментов автоматизации тестирования на сегодняшний день является довольно распространенным способом автоматизации тестирования приложений с графическим интерфейсом. На рынке компьютерных технологий предлагается довольно большое количество подобного рода инструментов. Неотъемлемой и, пожалуй, одной из основных частей функциональности таких продуктов является функциональность, позволяющая производить "запись" и "воспроизведение" автоматизированных тестов в различных средах. При "записи" тестов фиксируются нажатия клавиш и манипуляции мышью, совершаемые тестировщиком, в результате в фоновом режиме
9 автоматически создается скрипт на языке высокого уровня. Полученная
запись и является той компьютерной программой, которую принято называть тестовым скриптом. Однако скрипт, полученный путем записи действий тестировщика, в большинстве случаев невозможно применить для использования в автоматизации регрессионного тестирования, он требует дальнейшей доработки. Для этого данные инструменты обладают достаточно гибким языком описания тестов и возможностью внесения изменений в "записанные" тесты или же написания таких тестов без помощи механизма "записи".
В то же время, практическое применение описанных инструментов автоматизации в условиях крупных промышленных проектов показывает, что они далеко не всегда обеспечивают нормальное тестирование и даже далеко не всегда применимы при тестировании подобных проектов. Дело в том, что как при "записи", так и при "воспроизведении" автоматизированных тестов инструмент автоматизации в состоянии работать только с фиксированным набором стандартных типов элементов графического интерфейса приложения. И в случае, когда тестируемая система содержит нестандартные элементы графического интерфейса, инструменты автоматизации подобного рода дают сбои не только при "записи", но и при "воспроизведении" тестов, иначе говоря, являются несовместимыми с тестируемой системой.
Целью исследования работы является создание методики разработки автоматизированных тестов, лишенной недостатков существующих методов и средств автоматизации тестирования и удовлетворяющей следующим требованиям:
универсальность в плане применения при автоматизации любого программного продукта;
высокая эффективность разрабатываемых автоматизированных тестов;
10 относительно низкая трудоемкость.
Цель диссертационной работы - разработка нового метода
автоматизации тестирования программных приложений, лишенного
недостатков существующих методов. Метода, который бы являлся
высокоэффективным, универсальным, в плане возможности применения при
автоматизации тестирования любого программного продукта, а также не
требовал бы значительных трудозатрат для своего применения.
Объектом исследования выступают различные группы современных инструментов автоматизации тестирования приложений с графическим интерфейсом.
Предметом исследования являются реляционные отношения, возникающие в процессе формирования и дифференциации состояний тестируемых систем.
Методологической и теоретической основой диссертации
послужили фундаментальные труды отечественных и зарубежных программистов, изучающих проблемы безошибочного программирования основывающегося на реализации процессов автоматизации всех этапов жизненного цикла программных продуктов от проектирования и кодирования программ до документирования и их сопровождения. К таким средствам относятся: CASE-средства, объектно-ориентированное программирование, методы логического программирования. Особое место занимают методы визуального программирования, поскольку приближение формы представления программы и способов ее кодирования к образному способу мышления человека в значительной степени сокращает число ошибок, допускаемых человеком при разработке программ, и повышает надежность программирования [27].
Кроме того, основой диссертации послужили публикации научной и периодической печати.
Исследование строилось на принципах системного подхода, логического моделирования процессов дифференциации. Эмпирическую базу диссертационной работы составили материалы обследования существующих методов тестирования, а также имеющиеся в периодической печати фактические данные по теме научного поиска.
Научная новизна диссертационного исследования состоит в:
разработке нового подхода к вопросам организации тестирования приложений с графическим интерфейсом, позволяющего автоматизировать процесс тестирования, задав информационную потребность иерархическим множеством категорий и обучив соответствующую модель на имеющихся состояниях. При этом распределенная архитектура разрабатываемой системы является масштабируемой и позволяет обеспечить высокую скорость обработки;
распознавании ключевых состояний тестируемых систем, в связи с чем решена задача системной классификации множества произвольных состояний;
разработке нового подхода к классификации кластеров выделенного множества состояний, построение на основе этого динамической библиотеки состояний;
разработке универсального метода автоматизации регрессионного тестирования, обеспечивающего высокую эффективность автоматизированного тестирования, и требующего относительно малых трудовых затрат на реализацию;
разработке языка описания тестов;
создании инструментария, поддерживающего процесс автоматизации
регрессионного тестирования на основе разработанного метода.
Практическая значимость полученных результатов заключается в том, что:
разработан метод, являющийся универсальным методом автоматизации регрессионного тестирования больших промышленных программных продуктов, и обеспечивающего высокую безопасность и эффективность;
разработан язык описания тестов;
создан инструментарий, позволяющий применение нового метода;
практическое подтверждение постулированных в работе положений в ходе автоматизации регрессионного тестирования реальных промышленных программных продуктов.
Применение разработанного метода на практике позволило существенно снизить трудоемкость процесса регрессионного тестирования и улучшить качество выпускаемых продуктов.
Стоит отметить, что описанный метод можно использовать не только при автоматизации регрессионного тестирования, но и при автоматизации функционального и системного тестирования [11].
Разработанный метод, язык описания тестов и инструментарий поддержки данного метода были внедрены в производственный процесс Филиала Корпорации "Борланд Лабе, Инк.".
Результаты работы
проведен анализ существующих методов и средств регрессионного
тестирования программного обеспечения и выбор требований к
системе;
разработан новый метод автоматизации регрессионного тестирования;
разработан язык описания тестов, работающих по новому методу;
создан инструментарий, поддерживающий процесс автоматизации регрессионного тестирования на основе разработанного метода;
показана перспективность нового метода путем разработки расширения нового метода, ориентированного на применение при автоматизации не только регрессионного, но и системного тестирования;
проанализированы результаты применения предложенных методик и инструментального пакета при регрессионном тестировании программных продуктов.
Место тестирования в процессе разработки программного обеспечения
До начала 80-х годов процесс тестирования программного обеспечения был разделен с процессом разработки: вначале программисты реализовывали заданную функциональность, а затем тестировщики приступали к проверке качества созданных программ. Однако, такой подход создает множество проблем. Например, разработка программ может оказаться достаточно длительной, в то время, как тестировщики будут вынуждены бездействовать, ожидая появления первого рабочего прототипа будущей системы.
Другая, более серьезная, проблема заключается в плохой предсказуемости результатов такого процесса разработки. Ключевой вопрос таков: сколько времени потребуется на завершение продукта, в котором существует 500 известных ошибок? На самом деле, предугадать это совершенно невозможно, так как разные ошибки будут требовать разного времени на исправление, а исправление известных ошибок будет неизбежно связано с внесением новых. Steve McConnell приводит в своей книге [67] следующую мрачную статистику: даже однострочное изменение в программе с вероятностью 55% либо не исправляет старую ошибку, либо вносит новую. Если же учитывать изменения любого объема, то, в среднем, менее 20% изменений корректны с первого раза.
Сложившаяся ситуация становилась нетерпимой, особенно, учитывая постоянное возрастание как объема вновь разрабатываемых программных продуктов, так и увеличение степени их сложности. В связи с этим в 90-х годах появилась другая методика разработки, называемая zero-defect mindset. Основная идея этой методики заключается в том, что качество программ проверяется не post factum, а постоянно, в процессе разработки. Например, программист не может перейти к разработке новой функциональности, если существуют известные ошибки высокого приоритета в частях, разработанных им ранее.
При такой постановке вопроса тестирование становится центральной частью любого процесса разработки программ.
С другой стороны, zero-defect mindset предъявляет существенно более высокие требования к квалификации инженера тестирования: теперь в сферу его ответственности попадает не только функциональное тестирование, но и организация процесса разработки (процесс ежедневной сборки, участие в инспекциях, сквозных просмотрах и обычное чтение исходных текстов тестируемых программ). Поэтому идеальной кандидатурой на позицию тестировщика становится наиболее опытный программист в команде, закаленный в многочисленных боях ветеран, которому, возможно уже надоело кропать обычный код в (п+1)-ом проекте. Такой специалист мог бы не просто существенно улучшить качество создаваемого продукта, но и передать свой опыт младшим товарищам [24].
Тестирование само по себе является затратной деятельностью, отнимающей значительные средства и ресурсы. Поэтому в большинстве случаев разработчики программного обеспечения заранее формулируют какой-либо критерий качества создаваемых программ (определяют, так называемую, планку качества), добиваются выполнения принятого критерия и после этого прекращают тестирование, выпуская продукт на рынок. Такая концепция получила название Good Enough Quality (достаточно хорошее программное обеспечение) в противовес более очевидной концепции Best Possible Quality (максимально качественное программное обеспечение).
К сожалению, принцип Good Enough Quality зачастую понимают неправильно, ближе к формулировке Quality - If Time Permits (качество -если будет время). Конечно, выпуск плохо протестированного продукта из-за недостатка времени - это плохая практика. Действительность показывает, что пользователи склонны, со временем, забывать даже значительные задержки с выпуском продукта, но плохое качество выпущенного продукта запоминается на всю жизнь.
На самом деле, Good Enough Quality - это просто поиск разумного компромисса между затратами на тестирование, длительностью разработки продукта и его качеством.
Тестирование принципиально отличается от программирования по своим психологическим характеристикам. Дело в том, что программирование носит конструктивистский характер, а тестирование программного обеспечения - деструктивно по своей природе. Можно сказать, что программист строит что-то, создает из ничего нечто, а тестировщик отыскивает недостатки этих построений.
Разработка математической модели контекстного представления множества произвольных состояний
Научной новизной данного системного подхода является распознавание ключевых состояний тестируемых систем, в связи с чем возникает задача системной классификации множества произвольных состояний.
Многие подходы к решению задач классификации основаны на байесовской теории решений [32]. Решающие правила, синтезированные с помощью этой теории, обладают тем свойством, что обеспечивают наименьшую вероятность ошибки классификации при выбранном редставлении. Однако байесовский подход требует наличия возможности описания категорий как вероятностных распределений на множестве векторов признаков, что является сложной задачей в некоторых случаях. Если считать, что каждая категория с описывается вероятностным распределением Р(х\с) векторов признаков с, то байесовский классификатор присваивает объекту d категорию с, такую, что c. argmax/3(clx ) = argmaxP P 1 - (2.2.1) d с d с P(xd)
При этом, поскольку величина Р(х,) постоянна на протяжении процесса классификации d, ею обычно пренебрегают.
Основная проблема при работе с байесовскими классификаторами состоит в нахождении распределений Р(х\с), которые бы хорошо описывали категории. В случае классификации состояний тестируемых систем проблема становится еще большей в силу большой размерности пространства признаков.
Данная модель описывает кластерное представление произвольных состояний в системах, которое позволит на их основании построить систему распознавания узловых состояний.
Предлагаемая модель основана на использовании информации о совместном появлении исследуемых состояний вблизи друг от друга. При этом группы часто встречающихся состояний образуют роды, являющиеся, согласно рассматриваемой модели, атомарными смысловыми единицами, которые отображаются в виде динамической библиотеки состояний. Таким образом, необходим метод определения наиболее часто соседствующих состояний и построения множества узловых состояний тестируемой системы.
Пусть D - множество всевозможных тестируемых объектов, то есть, систем. W = {w.,...,w„} - множество состояний системы. Задача построения контекстного представления состоит в том, чтобы для некоторого априорно заданного множества атомарных состояний гипотетической области S найти отображение y.DxS— R, задающее для каждого объекта CIGD и каждого состояния SES некоторую меру принадлежности состояния данному объекту d. Множество таких отображений обозначим через T(D,S). Контекстное представление объекта основано на объединении его состояний в контекстные группы и определения родов состояний, характерных системе, на основе этих групп. Контекстные группы формируются на основе близости этих явлений в объекте. При этом принимается гипотеза о том, что явления, соседствующие в объекте, зависят друг от друга и вместе образуют узлы предметной области.
Обозначим через FQV) множество всех конечных последовательностей состояний из W. Тогда можно считать, что на множестве объектов D задано отображение TJ .D— FQV}, ставящее в соответствие каждому объекту d, принадлежащего D, некоторую последовательность состояний.
Контекстные группы либо формируются по принципу одинакового количества элементов в них, либо соответствуют определенным типам исследуемых в системе состояний. Для простоты будем рассматривать стратегию разбиения, основанную на равном количестве элементов. Каждая стратегия А задает отображение h. . F(JV) — F(F(Wy), где F(W) множество всех последовательностей состояний, соответствующих системам, F(FQy) - множество всех последовательностей контекстных групп, которые, в свою очередь, также соответствуют последовательностям состояний. На этом этапе, поскольку контекстные зависимости уже учтены при построении данного разбиения, можно далее не учитывать информацию о последовательности состояний и контекстных групп, и ввести отображение 3, вида задающее для каждой последовательности контекстных групп и каждого состояния области их S меру принадлежности данного состояния этой контекстной группе. Однако для построения этого отображения необходимо сначала рассмотреть каждую контекстную группу в отдельности и определить состояния, содержащиеся в ней.
Теоретическое обоснование преимуществ разработанного метода
Задача классификации контекстных групп состоит в нахождении вероятностных распределений состояний предметной области P(jS, / .), к = \,...,К для данной контекстной группы f.. Поскольку на момент работы алгоритма по данному методу нам известны значения апостериорных вероятностей P(w. Is,), j = \,...,M, k = \,...,K, задающие вероятностные распределения состояний области коллекции состояний, можно записать распределение состояний контекстной группы f., предполагая значения P{s,\f?) известными, в виде смеси распределений: P jU UPWUdP jU ) К к=\ Далее, поскольку контекстная группа рассматривается как включающая в себя набор состояний, инцидентных соответствующей части системы, то f.S, = S, . Отсюда следует выполнение равенства р(т=ЇРШі)р(мк). (2.4.1) j к=\ j Задача классификации контекстной группы состоит в том, что по известной контекстной группе f документа d необходимо определить значения P{s, У.) фигурирующие в (2.4.1). Рассмотрим данную задачу как задачу разделения смеси распределений в (2.4.1). Для этого обозначим неизвестные вероятности P(sk\f.) = (X,., к = \,...,К, / = 1,...,7V\
Вероятность состояний, входящих в контекстную группу f., при условии их независимости, согласно (2.4.1), будет иметь вид: где W. - множество состояний, содержащихся в контекстной группе f., через Л. обозначен вектор неизвестных значений Л. = (.,...,#„.). Для решения задачи разделения смесей )= П ІДШЖн .І -шІаи (2.4.2) w.zW.k=\ Л- k=l используется модификация ЕМ-алгоритма. Ее работа основана на введении скрытых переменных у., где j выбираются так, чтобы W.E.W.. Эти переменные соответствуют состояниям W.GW., принимают значения из множества \,...9К и определяют принадлежность соответствующего состояния одному из «родовых» состояний S.sS, k = \,...,K. Обозначим совокупность скрытых переменных через Y. и рассмотрим функцию логарифмического правдоподобия L(W.Y.\A.)=\nP(W.Y.\A.)= J) \nP(Wjyj)= WjeW. J l J I
Вектор значений Y. при этом неизвестен. Однако, считая его случайным, можно найти распределения его компонент P(y\W.A) У У У =i Y а также вероятность всего вектора / при известных значениях параметров л. P(Y\WA.)= П P(yjWA). w.eWt Решение исходной задачи максимизации функции правдоподобия (2.4.3), согласно данному методу, сводится к итерационной максимизации функции Q(A.,Л!)=M(L(W.Y Лр Л.). Здесь через M(L(WY.\A.)\A.) обозначено математическое ожидание функции L(W.Y\A[) относительно неизвестного /. при фиксированном Л.. На каждом шаге итерации по известному значению Л. путем максимизации функции (2(Л.,Л.) вычисляется новое значение Л.=Л:.
Затем происходит повторение данной процедуры. Найдем далее выражения для новых значений Л.. Для этого подставим LQV.Y. Л.) в выражение для Q(A.,A.).
Расширение нового метода автоматизации тестирования
Допустим, после совершения нескольких действий и соответствующих проверок между действиями мы выполняем следующее действие, которое завершается корректно, однако, приводит в иное состояние другие объекты, не связанные с данным действием. Например, при создании одного элемента происходит ошибочное удаление другого, созданного ранее. Для выхода из подобной ситуации введена возможность накапливания проверок состояний ф в некотором общем состоянии системы. И проверять необходимо не атомарные состояния, а состояние системы в целом. Синтаксис вызова: action name- stateCheck" state states state name="StateNamel"/ state name="StateName2"/ /states /state /action
Данный вызов проверит два состояния (StateNamel, StateName2). Однако, необходимо, чтобы указанные состояния были описаны ранее с полностью определенными значениями параметров. Т.е. для каждого проверяемого объекта должно существовать описание состояния для его ф проверки с конкретными значениями параметров. 2.7.5 Динамические состояния.
Использование множеств состояний приводит к тому, что описания состояний начинают занимать достаточно много места, а использоваться всего единицы раз. Для избежания подобных ситуаций вводится понятие динамических состояний, которые можно создавать или удалять в теле описания самого скрипта. action name="createState" state name- StateName " states /states checkers /checkers property name="propertyNamel" value- propertyValue 1 "/ /state /action
Действие с именем "createState" позволяет динамически создавать состояния в скриптах. Внутренне содержимое тэга state полностью совпадает с обычным описанием состояния. Действие с именем "removeState позволяет удалять динамические состояния: action name="removeState" statename- StateName "/ /action
Состояния, описанные не в скриптах, удалить нельзя. Это сделано для того, чтобы исполняемые скрипты не нарушали описанную иерархию состояний и скрипты, запущенные после выполнения других скриптов, выполнялись так, будто до них не происходило никаких действий.
Динамические коллекции состояний.
Для проверки всего состояния большой системы может быть создано большое число атомарных состояний, и не разумно с точки зрения размеров скриптов указывать после некоторой операции проверку всех атомарных состояний. Однако, в начале выполнения скрипта можно создать пустое состояние, и после выполнения действия добавлять необходимые проверки других состояний в это общее состояние системы, а затем выполнять проверку не большого числа атомарных состояний, а одно большое состояние системы, состоящее из атомарных состояний. Такой подход позволит уменьшить объем скриптов. Следующие действия позволяют добавлять и удалять состояния из динамических состояний. action name="addToState" state name="StateName" states state name="StateNamer7 state name="StateName27 /states /state /action action name="removeFromState" state name="StateName" states Щ state name- StateName 17 state name- StateName27 /states /state /action Здесь рассмотрены вызовы из скрипта процедур добавления и удаления двух состояний {StateNamel, StateName2) из другого состояния {StateName). Однако, добавлять и удалять состояния из нединамических состояний нельзя по причинам, изложенным в предыдущем пункте.
Сохранение состояния.
Иногда требуется сохранять и восстанавливать некоторое состояние, например, для тестирования undo/redo действий. Особенно полезным данное поведение будет применительно к динамическим коллекциям состояний, содержимое которых постоянно меняется с каждым шагом выполнения скрипта. Для реализации подобного поведения существуют так называемые undoable состояния, с которыми возможны операции запоминания текущего внутреннего состояния, восстановления ранее запомненного и очистки какого-либо ранее запомненного состояния.
