Управление эксплуатационными требованиями: Часть 2. Создание контрольных примеров для тестирования

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

Фабио Кастильони, старший ИТ-архитектор, IBM

Фото Фабио КастильониФабио Кастильони (Fabio Castiglioni) ― старший ИТ-архитектор отделения продаж и распространения продукции IBM в Италии. У него 13-летний опыт работы в исследовательской лаборатории, где он занимал технические и руководящие должности в международных проектах. В 1995 году был назначен техническим директором научно-исследовательского проекта по OO-технологиям. В 1998 году стал главным ИТ-архитектором IGS и работал над крупными государственными проектами. Фабио ― один из преподавателей курсов компонентного моделирования для архитекторов IBM. В 2005 году он выступал на конференции по SOA и Web-сервисам, а в 2006 и 2008 гг. - на конференции TLE.



Джулия Кальяри, ИТ-архитектор программного обеспечения, IBM

Фото автораДжулия Кальяри (Giulia Caliari) ― ИТ-архитектор программного обеспечения IBM Software Group в Италии. Проработав шесть лет в сфере научных и параллельных вычислений, стала консультантом по хранилищам данных и бизнес-анализу, оказывая техническую поддержку по разработке и реализации крупных инфраструктур хранилищ данных. С 1998 по 2006 г. занималась техническим маркетингом, поддержкой и консультированием по ряду инструментов и технологий управления контентом и данными на платформах Informix и IBM, а также внесла вклад в разработку важных проектов.



21.05.2012

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

Для минимизации рисков при внедрении новой системы в ИТ-номенклатуру и инфраструктуру нужно определить тесты, которые докажут надежность новой системы и убедят в ее адекватности для использования на предприятии.

Прежде всего, каждое нефункциональное требование является техническим следствием того или иного бизнес-требования, определенного участниками процесса создания новой системы (см.Rozansy и Losacco). Например, когда заказчики говорят: "Одна категория пользователей должна иметь доступ к системе в любое время и в любой день года", то в терминах ИТ это означает, что эта система должна быть доступной круглосуточно. Для других пользователей, которые работают с системой из офиса в рабочее время, могут потребоваться другие окна доступности. Если топология физической архитектуры включает в себя отдельные каналы для интернет-соединений и связи с офисом, то требование круглосуточной доступности не повлияет на Web-серверы, на которых работает канала бэк-офиса.

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

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

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

Определение тестов

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

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

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

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

Рисунок 1. Схема контекста эксплуатации электронного аукциона
Схема контекста эксплуатации электронного аукциона

Увеличенный вариант рисунка 1.

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

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

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

Изучение нефункциональных требований

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

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

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

Рисунок 2. Таблица противоречивых требований
Таблица противоречивых требований

Увеличенный вариант рисунка 2.

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

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

Определение условий для случаев нагрузки

На втором этапе процесса определяется функциональное состояние, которое приводит к возникновению данного случая нагрузки. Функции, как правило, представлены через примеры использования, так что мы начнем со списка (подходящих) примеров использования. Для каждого случая использования определим NFR, которые могут повлиять на работу системы. Например, пример использования "Предложение цены за товар" (Bid Item) реализуется действующим лицом "Зарегистрированный поставщик". В данном случае 200 пользователей могут выставлять цену на одном и том же аукционе в одно и то же время.

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

«Хороший» список примеров использования для испытаний должен соответствовать следующим критериям:

  • охватывать все перечисленные NFR;
  • включать в себя все основные функции новой системы;
  • включать все важные функции или функции с высокой степенью риска.

Определение примеров использования

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

Чтобы воспроизвести этот сценарий, нужны, по крайней мере, следующие примеры использования: "Предложение цены за товар" (Bid Item), "Повторный заказ товара" (Reorder Item) и "Просмотр аукциона" (Browse Auction). Все эти случаи должны обслуживаться одновременно.

С другой стороны, некоторые ситуации требуют еще более сложного суждения: требование "До 200 одновременно работающих пользователей с доступом для чтения и записи" можно проверить только с помощью нескольких примеров использования. Чтобы сделать хороший выбор, нужно принять во внимание актуальность этих примеров и вероятность создания ими конкретных условий нагрузки при реальных операциях. В некоторых ситуациях для адекватной проверки случая нагрузки может потребоваться более одного контрольного примера (например, тест на основе Bid Item и тест на основе списка активных аукционов (List Active Auctions)). Кроме того, оба теста для проверки требования "До 200 одновременных пользователей R/W" должны иметь сценарий "шума", который выполняется параллельно и создает уровень фоновой нагрузки, необходимый для данного случая нагрузки.

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

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

В остальной части статьи мы рассмотрим возможности Rational Quality Manager по решению этой задачи.

Управление тестированием с помощью Rational Quality Manager

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

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

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

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

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

Перевод случаев нагрузки в контрольные примеры

Для создания плана тестирования мы использовали несколько функций и ресурсов Rational Quality Manager.

  • Требования: наши тесты должны подтвердить, что новая система действительно отвечает производственным требованиям. Как мы видели до сих пор, производственные требования ― это сочетание взаимосвязанных нефункциональных требований. На этом этапе мы прослеживаем не тесты отдельных примеров использования или NFR, а покрытие тестами случаев нагрузки. Вот наши требования по управлению качеством продукции в реальном времени (RQM).
  • сценарии: Сценарии переводят примеры использования в последовательность ручных или автоматических действий. Сценарии используются, чтобы нагрузить тестовую среду до того уровня, который проверяет данный случай нагрузки. Когда примеры использования, необходимые для воспроизведения наших условий нагрузки, определены, нужно составить ручные и автоматизированные сценарии их осуществления.
  • Условия тестирования: отдельные NFR становятся характеристиками нашей среды тестирования. Например, с помощью информации из строки RS1 таблицы можно построить график (см. рисунок 3 ниже), который служит описанием ключевых элементов нашей среды тестирования доступности. Мы используем такие графики, как общий вид среды тестирования, которую нужно создать.
Рисунок 3. Среда тестирования доступности
Среда тестирования является следствием NFR
  • Лабораторные ресурсы: лабораторные ресурсы - это строительные блоки для среды тестирования. Это могут быть физические или виртуальные машины. В своей спецификации среды тестирования RQM нам нужно определить ресурсы для ее построения. На рисунке 4 (ниже) и рисунке 5 показан тест доступности, а на рисунке 6 ― тесты времени отклика. Обратите внимание, что определение лабораторных ресурсов может быть гораздо сложнее, чем в наших таблицах; однако при определении среды тестирования мы сосредоточились только на тех характеристиках, которые важны для нашей цели тестирования, т.е. на тестах, относящихся к нашим эксплуатационным требованиям.
Рисунок 4. Лабораторные ресурсы для тестов доступности
Лабораторные ресурсы, составляющие среду тестирования

Увеличенный вариант рисунка 4.

Рисунок 5. Определения лабораторных ресурсов в Rational Quality Manager
Каждый ресурс имеет свой собственный набор определений

Увеличенный вариант рисунка 5.

Рисунок 6. Лабораторные ресурсы для тестирования времени отклика
Второй пример среды тестирования
  • Машины и установки: машины – это представление реальных или виртуальных тест-систем. Доступ к машинам можно получить с помощью резервирования. (Реальная) среда тестирования для данного теста представляет собой набор тест-машин, который называется тест-установкой (test cell). Тест-установка представляет собой физическую реализацию среды тестирования. Машина ― это физическая реализация лабораторных ресурсов с соответствующими характеристиками.
  • Контрольные примеры: требования, сценарии и среда тестирования вместе составляют контрольные примеры RQM. Контрольный пример позволяет проверить требование, связывая соответствующую среду тестирования с выполнением функций, которые нагружают систему надлежащим образом. Отслеживая выполнение полученных в результате контрольных примеров, мы проверяем соблюдение наших производственных требований.

Теперь вы сможете провести качественные лабораторные испытания (... и, будем надеяться, перейти к беспроблемной производственной эксплуатации)!

Заключение

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

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

Ресурсы

Научиться

  • Оригинал статьи
  • Страница Rational Quality Manager портала IBM® developerWorks®: ссылки на документацию, статьи, учебники, курсы, загружаемые материалы и другие полезные разделы. Дополнительные материалы есть также на странице Rational Quality Manager Information Center с документацией продукта и на странице IBM Quality Management.
  • Повышайте свою квалификацию. Каталог учебных и сертификационных курсов по Rational, содержащий множество курсов по широкому кругу тем. Некоторые из них можно посещать в любое время и в любом месте, причем многие курсы для начинающих предоставляются бесплатно.
  • Заметки в Википедии по синтезу форм: о книге Кристофера Александра (Christopher Alexander) 1964 года, посвященной процессу проектирования.
  • Manage operational requirements for production by Caliari and Castiglioni (developerWorks, март 2011 г.): первая статья этого цикла: Четыре шага, гарантирующие согласование нефункциональных требований группами разработки и эксплуатации.
  • The operational context diagram by Castiglioni and Losacco (developerWorks, февраль 2009 г.): о технике, дополняющей SCD нефункционально-ориентированной схемой контекста эксплуатации.
  • Analyze requirements for complex software systems in a new, holistic way by Castiglioni and Cripps (developerWorks, февраль 2009 г.): способ разрешения конфликтующих функциональных и нефункциональных требований.
  • Software Systems Architecture - Working With Stakeholders Using Viewpoints and Perspectives by Rozanski and Woods: практическое руководство по разработке и реализации эффективной архитектуры информационных систем. Это и доступное введение в архитектуру программного обеспечения, и бесценный справочник с практическими рекомендациями.

Получить продукты и технологии

Обсудить

  • Присоединяйтесь к форуму по Rational Quality Manager, где обсуждается также Rational Test Lab Manager.
  • Оцените или оставьте рецензию на программное обеспечение Rational. Это быстро и легко. Правда.
  • Поделитесь своими знаниями и помогите другим пользователям программного обеспечения Rational, написав статью в developerWorks. Вы получите всемирную известность, распространение через RSS, публикацию своего имени и биографии, а также преимущества профессионального редактирования и издания в разделе Rational портала developerWorks. Что делает статью developerWorks хорошей, и как ее написать.
  • Следите за новостями о программном обеспечении Rational на Facebook, Twitter (@ibmrational) и YouTube, добавляя свои комментарии и пожелания.
  • Задавайте вопросы и отвечайте, накапливайте опыт, участвуя в посвященных Rational форумах , кафе и вики.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=816966
ArticleTitle=Управление эксплуатационными требованиями: Часть 2. Создание контрольных примеров для тестирования
publish-date=05212012