Computer Science МФТИ Changes    |    Index    |    Search
::: AdaptiveMAS :::
Parents: WebHome > AgentProjects
 
  ACM . Agent . AdaptiveMAS # Edit # Attach # Diffs # Printable # More :::

Main
• Register
• Users
• Site Map

Curriculum

Agent Web
• projects

Algorithms

Web Learn

Image Kit

ProgTech

Publishing

Самотестирование - способ построения защищенных от сбоев МАС

С. Иванов

Отказоустойчивость компьютерных систем

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

Одним из возможных ориентиров является опыт компании IBM — одного из ведущих разработчиков программ для оборонных проектов США. Известно, например, что в трех миллионах строк кода бортового ПО "шаттлов" содержится менее одной ошибки на десять тысяч строк.

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

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

Качество и надежность в комплексе обеспечивают высокие потребительские свойства ПО. В процессе создания программного продукта они одновременно и непрерывно контролируются и совершенствуются. Однако насколько реально обеспечить качество и надежность сложной многофункциональной системы при ограниченных сроках разработки? Для иллюстрации можно привести результаты опроса более тысячи крупных компаний, проведенного министерством торговли и промышленности Великобритании. Оказалось, что средняя частота отказов информационных систем составила: 1 отказ в год — 40% компаний, 1 отказ в месяц — 29%, 1 отказ в неделю — 15% компаний, 1 отказ в день — 7% и 5% компаний наблюдали у себя более одного отказа в день. При этом доля отказов и сбоев программного обеспечения в общем списке причин неработоспособности (простоев) информационных систем составляла 24% [3].

Тестирование как способ повышения надежности

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

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

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

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

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

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

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

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

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

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

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

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

Рост возможностей автоматизированного тестирования вызван ростом популярности ускоренной разработки приложения (RAD) - методологии разработки ПО, которая уделяет основное внимание сокращению сроков разработки, обеспечивая при этом возможность получения различных версий программного продукта все возрастающего объема с высокой частотой. Целью RAD является привлечение пользователя на всех этапах проектирования и разработки, начиная с самых ранних, при выпуске каждой версии с тем, чтобы усовершенстововать программное обеспечение, гарантируя при этом, что оно в наибольшей степени отражает потребности и предпочтения пользователя. В такой среде постоянных изменений и дополнений к программному обеспечению при переходе от одной версии к другой, когда поощряется развитие требований, тестирование приобретает итеративную природу. Каждая новая версия сопровождается значительным количеством новых тестов, а также переработкой существующих тестовых скриптов. Таким образом, автоматизированное тестирование программного обеспечения становится важным механизмом проверки, гарантирующим точность и стабильность программ по мере выпуска новых версий.

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

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

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

Адаптивная МАС

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

Для построения внедряемого модуля самотестирования в МАС предлагается подход Test Blocks. Тестирование распределенных систем – задача, состоящая из несколько аспектов. Это – отдельное тестирование изолированных компонент системы, а также тестирование взаимодействия компонент. В случае МАС подход Test Blocks охватывает вопрос как проверки поведений (логики) отдельных агентов, так и взаимодействия агентов между собой.

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

Два общих подхода к тестированию МАС - это online- и offline- тестирование. Online-тестирование предполагает внедрение в систему тестирующего агента. Offline-тестирование предполагает возможность проверки взаимодействия агента с другими агентами без запуска МАС. Для этого возможны два пути тестирования: - На основе заданных спецификаций взаимодействия, написанных на формальном языке. - С частичной подгрузкой других агентов системы, с которыми общается исследуемый агент. Также различаются «внутренний» и внешний (на основе спецификаций) подходы.

«Внутренний» подход (self-testing) – во всех агентов, участвующих в тестировании, встраивается тестирующий модуль, изменяющий их поведение агента. После дополнения модулем агент способен на самотестирование, засчет расширения его поведения будет возможна передача ему команды на самопроверку.. Формат и функциональность модуля четко определены заранее.

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

Программист, разрабатывающий агента, закладывает в него возможность тестирования, внутреннего либо внешнего. Только так будет возможным тестирование его функциональности. Для online-тестирования используется агент TestAgent? (TA). TA используется как для внутреннего тестирования, так и для «внешнего» тестирования (проверка взаимодействия с МАС) на основе спецификаций.

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

Attachment sort Action Size Date Who Comment
zambonelli00agentoriented.pdf manage 251.9 K 16 Mar 2004 - 19:19 SergeyIvanov? Agent-Oriented Software Engineering
jaamas2000.pdf manage 153.7 K 16 Mar 2004 - 19:21 SergeyIvanov? Gaia Methodology
cimasdai.pdf manage 531.6 K 15 Apr 2004 - 13:59 SergeyIvanov? Distributed AI and MAS
pcm-aug29.pdf manage 75.5 K 15 Apr 2004 - 14:02 SergeyIvanov? Adaptive Multimedia System Architecture
article75.pdf manage 300.3 K 15 Apr 2004 - 14:04 SergeyIvanov? ERP modeling: a comprehensive approach
FaultClassificationbyRandell.JPG manage 16.7 K 24 May 2004 - 17:21 SergeyIvanov?  

Rambler's Top100 Rambler's Top100


# Edit menu  

Topic revision r1.11 - 09 Jun 2004 - 16:52 GMT - SergeyIvanov?
Topic parents: WebHome > AgentProjects
Copyright © 2003-2017 by the contributing authors.