-
Тестирование вариантов использования
В ходе тестирования мы проверяем правильность реализации системой первоначальной спецификации. Мы создаем модель тестирования, которая состоит из тестовых примеров и процедур тестирования, а затем выполняем тестовые процедуры, чтобы удостовериться, что система работает так, как мы и ожидали. Тестовый пример — это набор тестовых исходных данных, условий выполнения и ожидаемых результатов, разработанный с определенной целью, например, реализовать некий путь выполнения варианта использования или проверить соблюдение определенного требования. Тестовая процедура — это описание подготовки, выполнения и оценки результатов конкретного тестового примера. Тестовые процедуры могут быть получены из вариантов использования. Для локализации проблемы обнаруженные дефекты следует проанализировать. Затем определяется приоритетность обнаруженных проблем, и они решаются в порядке их важности.
Опишем, как проверить, что варианты использования были осуществлены правильно. В каком-то смысле в этом нет ничего нового. Разработчики всегда проверяли варианты использования, даже раньше, чем появился сам термин «вариант использования». Тестирование возможности использования системы осмысленным для пользователей способом было традиционным способом проверки функций системы. Но, с другой стороны, это и новый подход. Новым является то, что мы идентифицируем тестовые примеры (как варианты использования в рабочем процессе определения требований) до начала проектирования системы и что мы уверены, что наш проект действительно реализует варианты использования.
Пример. Определение тестового примера на основе варианта использования. На рисунке 3.13 изображен тестовый пример Снять деньги со счета основной процесс, который описывает порядок проверки основного процесса варианта использования Снять деньги со счета.
Заметим, что сейчас мы ввели новый стереотип для вариантов использования, а именно крест. Это сделано для того, чтобы иметь возможность отображать эти варианты использования на диаграммах.
Тестовый пример определяет исходные данные, ожидаемый результат и другие условия, необходимые для проверки основного процесса варианта использования Снять деньги со счета.
Исходные данные:
-
Счет клиента банка имеет номер 12-121-1211 и на балансе счета $350.
-
Клиент банка идентифицирует себя верно.
-
Клиент банка запрашивает к выдаче $200 со счета 12-121-1211. В банкомате достаточно денег (минимум $200).
Результат:
-
Баланс счета 12-121-1211 Клиента банка уменьшается до $150.
-
Клиент банка получает из банкомата $200.
Условия:
Никакие другие варианты использования в ходе выполнения тестового примера не имеют доступа к счету 12-121-1211. Отметим, что этот тестовый пример основан на описании варианта использования Снять деньги со счета, описанного в подразделе «Варианты использования определяют систему». Рано определяя варианты использования, мы рано начинам планировать тестирование и рано находим эффективные тестовые примеры. Эти тестовые примеры могут усложняться по ходу проекта, по мере того, как мы расширяем наше понимание осуществления системой вариантов использования. Некоторые утилиты вообще генерируют тестовые примеры по модели проектирования вручную остается ввести только тестовые данные, необходимые для запуска теста.
Тестирование варианта использования может проводиться как с позиции актанта, для которого система является черным ящиком, так и с позиции проекта, когда тестовый пример строится для проверки того, что экземпляры классов, участвующих в варианте использования, делают то, что им положено. Тесты по методу черного ящика могут быть определены и запланированы сразу же, как только требования хоть в какой-то степени определятся.
-
Резюме
Варианты использования управляют процессом. В течение рабочего процесса определения требований разработчики могут представлять требования в виде вариантов использования. Менеджеры проектов могут планировать проект в понятиях вариантов использования, с которыми работают разработчики. В ходе анализа и проектирования разработчики создают реализации вариантов использования в понятиях классов или подсистем. Затем разработчики реализуют компоненты. Компоненты объединяются в приращения, каждое из которых реализует свой набор вариантов использования. Наконец тестеры проверяют, осуществляет ли система нужные пользователям варианты использования. Другими словами, варианты использования связывают воедино все деятельности, входящие в разработку, и управляют процессом разработки. В этом, вероятно, заключается наиболее важное преимущество использования подобной технологии.