Дизайн тестов на основе вариантов использования

Дизайн тестов на
основе вариантов
использования
Алексей Баранцев
Software-Testing.Ru
Заголовок слайда
Текст слайда, рисунки. Старайтесь не захламлять текст лишними данными,
параметрами. Вот немного тезисов:
• Для демонстрации используются плазмы – соотношение сторон 16:9!;
• Залы будут длинными (в среднем около 20 метров), поэтому текст
должен быть заметным;
• Код на слайде – плохая идея, он плохо читается издалека;
• Не забывайте выделять ключевые моменты;
• Формат презентации – Microsoft Power Point (как 2003, так и 2007) и PDF.
План
•
•
•
•
Что такое варианты использования?
Как из них делать тесты?
Какие могут возникнуть осложнения?
Некоторые практические замечания
Что такое
варианты
использования?
Варианты использования: UML
Действующие
лица
+
Варианты
использования
Варианты использования: UML
Тестирование на основе ВИ
Нарративная форма
UML недостаточно!
Нарративная форма «по Коберну»
UC 4: Place an order
1. The clerk identifies the customer, each item and quantity.
2. System accepts and queues the order.
Extensions:
1a. Low credit: Clerk takes prepayment
2a. Low on stock: Customer accepts reduced quantity...
Нарративная форма «по Коберну»
•
•
•
•
•
Название
Цель
Краткое описание
Действующие лица
Предусловия
•
•
•
•
•
Постусловия
Триггеры
Основной сценарий
Альтернативы
Бизнес-правила
ВИ: цель + сценарии
Actor
has
Goal
names
calls out
Use case
contains
Scenario
conditions
oucome
ВИ: цель + сценарии
Название ВИ – формулировка цели:
“ Order product from catalog”
• Scenario 1: Everything works out well ...
• Scenario 2: Insufficient credit ...
• Scenario 3: Product out of stock …
ВИ: цель + сценарии
Subgoal:
Establish
... credit
... stock
Goal: “Place order”
sc1 sc2
S
S
S
F
sc3
F
S
S
(Success scenarios)
sc4
sc5
sc6
S
sc7
F
F
F
...
F
(Failure sc.)
Как делать тесты
из вариантов
использования?
Тестирование = анализ наоборот
• Вариант использования
– это свёртка сценариев
• А для тестирования
– нужна развёртка
варианта использования
Вариант использования: пример
1.
2.
3.
4.
5.
6.
+
П. набирает номер
П. инициирует соединение
Т. устанавливает соединение
П. говорит
П. инициирует разрыв соединения
Т. разрывает соединение
2a. П. передумал
Альтернативы
2a1. П. сбрасывает номер X
3a. Т. не может установить соединение
3a1. Т. сообщает об этом П. X
3b. На счету П. недостаточно средств
3c1. Т. сообщает об этом П. X
5a. Т. теряет соединение
5a1. Т. сообщает об этом П. X
5b. Абонент разрывает соединение
5b1. Т. сообщает об этом П. X
5с. На счету П. заканчиваются средства… 
5c1. Т. сообщает об этом П. X
Развёртка ВИ в набор сценариев
1
2
3
4
5
6
+
2a X
3a X
3b X
5a X
5b X
5c X
1 1 1 1 1 1 1
2 2a 2 2 2 2 2
3
X 3a 3b 3 3 3
4
X X 4 4 4
5a 5b 5c
5
6
X X X
+
Развёртки – заготовки для тестов
1. П. набирает номер
2. П. инициирует соединение
3a. Т. не может установить соединение
3a1. Т. сообщает об этом П. X
1. П. набирает номер
2. П. инициирует соединение
3. Т. устанавливает соединение
4. П. говорит
5с. На счету П. заканчиваются средства… 
5c1. Т. сообщает об этом П. X
Почему это ещё не совсем тест?
1. П. набирает номер
2. П. инициирует соединение
3a. Т. не может установить соединение
3a1. Т. сообщает об этом П. X
Выделяем параметры
как?
какой?
1. П. набирает номер
2. П. инициирует соединение
почему?
3a. Т. не может установить соединение
как?
3a1. Т. сообщает об этом П. X
Параметризуем тест
• Какой номер?
– мобильной / фиксированной связи
– своего / чужого оператора
– в своей сети / в роуминге
– короткий / прямой / с федеральным кодом
– через «8» / через «+7»
– спецслужбы
Параметризуем тест
• Почему не может установить соединение?
– сеть недоступна
– неправильно набран номер
– абонент недоступен
– абонент заблокирован
– абонент занят
– абонент свободен, но не отвечает (таймаут)
– абонент свободен, но «сбрасывает» звонок
Миксуем – и получаем тест
Тест = сценарий + параметры
но главнее – действующее лицо и его цель!
Какие могут
возникнуть
осложнения?
Неглавное действующее лицо
Primary Actor
System under test
Responsibility
(Interaction 1)
- Goal 1
- Goal 2
Responsibility
... action 1
- Goal 1
.
...action 1
:
Secondary Actor
(Interaction 2)
Responsibility
Система защищает интересы всех
заинтересованных лиц
“Совершить
звонок”
ГДЛ хочет...
ЗЛ хотят...
System
under
Test
Мораль для тестировщиков
• Недостаточно проверять
только то, что написано в
отдельно взятом ВИ
• Нужно иметь в виду сразу
все цели всех ЗЛ
Фатальные и нефатальные отклонения
UC1: Разместить заказ
• Идеальная ситуация:
– Деньги есть, товар есть -> принять заказ.
• Нефатальные отклонения (s2, s3):
– Денег мало -> можно дать кредит? (да) -> принять.
– Товара мало -> можно уменьшить количество? (да) -> принять.
• Фатальные отклонения (s4, s5):
– Денег мало -> можно дать кредит? (нет) -> отказать.
– Товар отсутствует -> отказать
Мораль для тестировщика
• нефатальные отклонения
удлиняют сценарии, увеличивают
вариативность, могут приводить к
появлению циклов
• с ними нужно работать наиболее
тщательно
ВИ используют другие ВИ
как?
1. П. набирает номер
UC 21: Набрать номер на клавиатуре
UC32: Выбрать абонента из записной книжки
UC43: Выбрать абонента из списка звонков
UC54: Выделить номер из SMS-сообщения
Системы-матрёшки
company
computer system
Our Sys.
other
company
other
dept.
other
System
subsystem
Иерархия ВИ
project goal
Strategic Goals
“white”
advertise
order
invoice
“blue”
User Goals
set up
promotion
reference
promotion
Subfunctions
identify
promotion
monitor
promotion
register user
place
order
identify
product
create
invoice
identify
customer
send invoice
“indigo”
Мораль для тестировщика
• Нужно сосредоточить
внимание на одном уровне
детализации и не опускаться
ниже
• В большинстве случаев нужно
сидеть «на уровне моря»
ВИ – это ещё не все требования
• Не все требования удаётся записать в виде
вариантов использования
– нефункциональные требования
• Не все функциональные требования удаётся
записать в виде вариантов использования
– бизнес-правила
– описания интерфейсов
– описания конфигураций
Нефункциональные требования
Use case
set up promotion
Frequency
Performance
10 / mo
interactive
reference promotion 500 / day
enter an order
80 / day
sub-second
create an invoice
80 / dy
3 seconds
send an invoice
1600/mo
interactive
420/hr (10 sec.)
...
Бизнес-правила
1. Order sum = order item costs * 1.06 tax
2. Promotions may not run longer than 6 months.
3. Customers only become Preferred after an
initial 6 month period.
4. A customer has one and only one sales contact.
5. An order item may use many promotions.
Описания интерфейсов
Use case
set up
promotion
reference
promotion
enter
an order
create
an invoice
send
an invoice
Form
In
Out
on-line
products, dates
new promotion
on-line
promotion #
promotion value
on-line
new order
database
customer,
products,...
order number
tape
invoice #
paper or EDI
new invoice
Описания конфигураций
1. Place an order - using standard pricing.
2. Place an order - using Preferred pricing.
3. Place an order - do not check credit limit.
1. Выполнить вызов - тоновый набор
2. Выполнить вызов - импульсный набор
Списки заинтересованных лиц
Use case
set up
promotion
reference
promotion
enter
an order
create
an invoice
send
an invoice
Users
Marketing managers
Managers, order clerks, other subsystems
Managers, order clerks, other subsystems
Managers, invoicing subsystem
Managers, invoicing subsystem
Укладка требований и тестов
Спасибо!
Алексей Баранцев
Software-Testing.Ru
Форум для тестировщиков
Портал для тестировщиков
Тренинги для тестировщиков
Консультации по тестированию ПО