В предыдущей статье мы показали, как коллективный подход со стороны групп разработки и эксплуатации помогает определить набор нефункциональных требований (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. Среда тестирования доступности
- Лабораторные ресурсы: лабораторные ресурсы - это строительные блоки для среды тестирования. Это могут быть физические или виртуальные машины. В своей спецификации среды тестирования RQM нам нужно определить ресурсы для ее построения. На рисунке 4 (ниже) и рисунке 5 показан тест доступности, а на рисунке 6 ― тесты времени отклика. Обратите внимание, что определение лабораторных ресурсов может быть гораздо сложнее, чем в наших таблицах; однако при определении среды тестирования мы сосредоточились только на тех характеристиках, которые важны для нашей цели тестирования, т.е. на тестах, относящихся к нашим эксплуатационным требованиям.
Рисунок 4. Лабораторные ресурсы для тестов доступности
Увеличенный вариант рисунка 4.
Рисунок 5. Определения лабораторных ресурсов в Rational Quality Manager
Увеличенный вариант рисунка 5.
Рисунок 6. Лабораторные ресурсы для тестирования времени отклика
- Машины и установки: машины - это представление реальных или виртуальных тест-систем. Доступ к машинам можно получить с помощью резервирования. (Реальная) среда тестирования для данного теста представляет собой набор тест-машин, который называется тест-установкой (test cell). Тест-установка представляет собой физическую реализацию среды тестирования. Машина ― это физическая реализация лабораторных ресурсов с соответствующими характеристиками.
- Контрольные примеры: требования, сценарии и среда тестирования вместе составляют контрольные примеры RQM. Контрольный пример позволяет проверить требование, связывая соответствующую среду тестирования с выполнением функций, которые нагружают систему надлежащим образом. Отслеживая выполнение полученных в результате контрольных примеров, мы проверяем соблюдение наших производственных требований.
Теперь вы сможете провести качественные лабораторные испытания (... и, будем надеяться, перейти к беспроблемной производственной эксплуатации)!
Мы рассмотрели, как определить лабораторные испытания с имитацией реальных условий нагрузки на новую систему. Мы использовали методы определения того, какие нефункциональные требования взаимосвязаны, создали случай нагрузки для новой системы, а затем определили необходимые контрольные примеры для ее адекватного тестирования.
Затем мы использовали Rational Quality Manager для перевода случая нагрузки в сценарии тестирования и среду тестирования для наших испытаний, гарантировав, что тест адекватно проверит ожидаемые нагрузки и ограничения времени выполнения новой системы.