работа с требованиями

ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Тест-дизайн
2008, v.2.6
Почему чем позже, тем дороже?
Удельная стоимость исправления дефектов быстро растет
по мере продвижения продукта к стадии эксплуатации.
Так, в статье B. Boehm and V. Basili «Software Defect
Reduction Top 10 List» (IEEE Computer, IEEE Computer
Society, Vol. 34, No.1, January 2001, pp. 135-137.) показано,
что стоимость исправления дефекта после ввода системы в
эксплуатацию вдвое превышает аналогичную стоимость
на стадии тестирования продукта и более чем в тысячу
раз — в период выработки требований к продукту.
Тест-дизайн
2
Стоимость исправления ошибок
•
•
Задачи тестирования ПО – снизить стоимость разработки путем
раннего обнаружения дефектов;
Тест дизайн – самая ранняя фаза, на которой тестирование
врезается в разработку
Тест-дизайн
3
Сколько это будет стоить исправить?
•
•
•
Невозможно представить себе разработку ПО, которое было
бы свободно от тех или иных ошибок.
По данным, опубликованным Национальным институтом
стандартов (NIST 2002 RTI Project 7007.011), основное
количество ошибок в продукте (70%!) закрадывается на
стадии выработки требований и построения дизайна.
А обнаруживается подавляющее большинство дефектов
либо в процессе тестирования (около 60%), либо уже при
эксплуатации (21%).
Тест-дизайн
4
АВТОРСКИЙ КОЛЛЕКТИВ
Вячеслав Панкратов
http://pankratov.org.ua/
Дмитрий Лысенко
http://dmitrylysenko.info/
Тест-дизайн
РАСПИСАНИЕ: 10.00-17.00
I день
Входное анкетирование
Качество информационных систем
Процесс тестирования ПО
Место практики «Тест-дизайн»
Обзор роли: дизайнер тестов
Связь проектных артефактов
Тест, тестовый набор, покрытие, стратегия
Работа с требованиями
II день
Техники тестирования
Практика
Финальное анкетирование
СОДЕРЖАНИЕ КУРСА
Процесс тестирования ПО и место практики «Тест-дизайн»
Преимущества и недостатки методов тест дизайна
Определение роли дизайнера тестов: зона ответственности
Активности разработки/дизайна тестов
Практические соображения работы с требованиями
Обзор артефактов тест дизайнера
Практические примеры
БАЗОВЫЕ ПОНЯТИЯ
Качество информационных систем
Процесс тестирования ПО
Тест-дизайн: определение и практика
Место практики «Тест-дизайн»
Связь проектных артефактов
Тест-дизайн
8
Характеристики качества ПО
Функциональность, надежность, производительность
 Надежность — работает ли приложение без сбоев,
«зависаний» или вызова исключений
 Функциональность — делает ли приложение то, что от
него требуется
 Производительность — работает ли приложение с
приемлемой скоростью при доступе к нему многих
пользователей
Тест-дизайн
9
Эволюция представлений о тестировании
•
2004
Проверка соответствия между реальным поведением
программы и ее ожидаемым поведением на конечном
наборе тестов, выбранном определенным образом.
[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK,
2004]
•
1999
Техническое исследование программы для получения
информации о ее качестве с точки зрения
определенного круга заинтересованных лиц. [С. Kaner,
1999]
•
1990
Это не действие. Это интеллектуальная дисциплина,
имеющая целью получение надежного программного
обеспечения без излишних усилий на его проверку.
[B. Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand
Reinhold, 1990]
•
1987
Процесс наблюдения за выполнением программы в
специальных условиях и вынесения на этой основе
оценки каких-либо ее аспектов. [ANSI/IEEE standard 610.121990: Glossary of SE Terminology. NY:IEEE, 1987]
•
Процесс выполнения программы с намерением найти
ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир, 1980]
1980
Тест-дизайн
10
Определение: Тестирование ПО
Тестирование ПО – процесс проверки соответствия
заявленных к продукту требований и реально
реализованной функциональности, осуществляемый
путем наблюдения за его работой в искусственно
созданных ситуациях и на ограниченном наборе
тестов, выбранных определенным образом
Тест-дизайн
11
Место тестирования в процессе разработки ПО
Development Process
Testing Process
Анализ
требований
Анализ
требований
Спецификации
(Specification)
Планирование
процесса тестирования
Программная
архитектура
(Software Architecture)
Программирование
(Coding)
Поддержка
Проектирование тестов
Версия
Результат
(build)
(test result)
Выполнение
тестов (testing cycles)
Отладка тестов
Приемочные испытания
(Acceptance Testing)
Системное тестирование
(System testing)
Поддержка
12
Стадии тестирования
Тестирование
программного продукта
Анализ требований
Изучение спецификаций, функциональных
требований к системе. Получение данных для
составления плана проведения тестирования
Планирование
процесса тестирования
Определение объемов тестирования,
подходов, ресурсов и расписание
выполнения намеченных действий
Проектирование тестов
Стадии
статического
тестирования
Определение цели тестирования,
спецификации входных данных,
архитектуры тестов для
упорядочивания тестов по группам
>>
13
Стадии тестирования
Выполнение
тестов (testing cycles)
Отладка тестов
Стадии
динамического
тестирования
Непосредственная проверка спроектированных
тестов, анализ всевозможных тестовых случаев
Пересмотр и отладка тестовых случаев
Системное тестирование
(System Testing)
Функциональная проверка, тестирование
для определения рабочих характеристик
Приемочные испытания
(Acceptance Testing)
Эксплуатация и
поддержка
Альфа-тестирование,
Бета-тестирование
Проверка результатов,
исправление дефектов.
14
BUC-UC-TC и другие страшные слова
• BUC/BR – business use case или business rule, бизнестребование или бизнес-правило
• UC – use case, сценарий использования
• TC – test case, сценарий тестирования
Тест-дизайн
15
Тест-дизайн
Определение и практика
 Тест-дизайн – это этап процесса тестирования ПО,
который включает создание/проектирование тестовых
сценариев и определение необходимых типов тестов,
для достижения заданного уровня тестового покрытия
приложения или системы под тестом
 Тест-дизайн – это техника, кардинально влияющая на
стоимость тестирования, так как задаёт объёмы работ
и границы проекта по тестированию
 Тест-дизайн – это попытка найти баланс между
трудозатратами на тестирование и приемлемым
уровнем доверия к результатам тестирования
Тест-дизайн
16
ОБЗОР РОЛИ: ДИЗАЙНЕР ТЕСТОВ
Круг ответственности
Круг активностей
Артефакты роли
Тест-дизайн
Тестирование в картинках (RUP)
Тест-дизайн
18
Тест дизайн в картинках (RUP)
19
Тест-аналитик: внимание, совмещаем!
 Определяет, приоритизирует и обеспечивает
разработку тестовых случаев
 Ответственность:
 Разрабатывает модель тестирования
 Оценивает эффективность тестирования
Тест-дизайн
20
Тест-дизайнер
 Устанавливает и определяет операции,
атрибуты и связи тестовых классов
 Ответственность:
 Устанавливает и определяет тестовые классы
 Устанавливает и определяет тестовые наборы
(пакеты)
Тест-дизайн
21
Обзор артефактов тестирования
Аналитик





Дизайнер
Test Case
Test-Ideas List
Workload Analysis Model
Test Data
Test results
 Test Strategy
 Test Automation Architecture
 Test Environment
Configuration
 Test Suite
Тест-дизайн
22
ТЕСТ, ТЕСТОВЫЙ НАБОР, СТРАТЕГИЯ
Определения
Тест, тестовый набор, тестовое покрытие
Стратегия тестирования
Тест-дизайн
23
Определение теста и тестового набора
• Тест – последовательность действий, которая
переводит систему из одного состояния в другое
 Триплет ISO, где:
 I - is input data or action (входные данные или
действия)
 S - is State of system at which data will be input
(состояние системы, которая получает входные
данные или воздействие)
 O - is the expected Output (ожидаемые Выход,
выходные данные или выходной состояние
системы)
Тест-дизайн
24
Определение теста и тестового набора
• Тестовый набор
 Набор тестов, реализующих бизнес-задачу,
выполняемую тестируемой системой
 Тестовый набор включает кроме тестовых
сценариев еще и тестовые данные или
правила их генерации
Тест-дизайн
25
Определение теста и тестового набора
• Разработка тестовых сценариев –
практические соображения
 Формальные методы разработки тестовых
сценариев
 На основе сценариев использования
 На основе ортогональной классификации
дефектов
 Формальные методики оценки объемов работ
 Метод расчета цикломатической сложности,
основанный на метрике МакКаби (McCabe)
 Смешанные методики – комбинация подходов
Тест-дизайн
26
Тестовое покрытие
Requirements-based Test Coverage
 Метрика покрытия, основанная на анализе
тестовых требований,
 Собирается несколько раз в течении одного цикла
тестирования для анализа завершенности
тестирования
 Вычисляется как соотношение всех
запланированных, имплементированных и
выполненных тестовых случаев к количеству
тестовых требований, существующих для
тестового цикла
Тест-дизайн
27
Тест дизайн, как этап тестирования
На этапе тест-дизайна выясняется и определяется
– Список тестируемых функций и модулей
– Тестируемость каждой функции и модуля
– Наиболее оптимальный подход (техника) для проверки
каждой функции, модуля или подсистемы
– Набор типов тестов
– Последовательность проведения и критерии завершенности
тестирования
Основные артефакты:
тест кейс и стратегия тестирования ПО
Тест-дизайн
28
Стратегия тестирования
 Типы тестирования
 Тестирование данных и целостности базы
данных
 Функциональное тестирование
 Тестирование бизнес-циклов
 Тестирование пользовательского интерфейса
 Нагрузочное тестирование
 Тестирование безопасности и управления
доступом
 Конфигурационное тестирование
 Инсталляционное тестирование
 Инструментальные средства
Тест-дизайн
29
Типы тестирования: целостность данных
 Цель: убедиться в невозможности создания
«несвязных данных» - данных, которые могут быть
созданы-отредактированы-агрегированы при
нормальной работе системы или при
возникновении сбоев в работе.
 Обращайте внимание:
 На включение-отключение триггеров и ограничений при
импорте-экспорте данных
 На включение-отключение триггеров и ограничений при
переводе системы в production режим
 На включение-отключение триггеров и ограничений при
операциях архивирования и завершении бизнес-циклов
 На поведение системы относительно данных при
разрывах соединений клиент-сервер-БД в любых
сочетаниях
Тест-дизайн
30
Типы тестирования: функциональное тестирование
 90% нашего с вами рабочего времени
 Проверка функциональных требований: логики и
бизнес-правил приложения или системы
 Как правильно полноценное
системное/функциональное тестирование является
самым трудоёмким процессом и может занимать
(Ф.Брукс) до 80% всего бюджета проекта по
тестированию
 Обращайте внимание:
 На невозможность полного покрытия – всегда надо
выбирать
 На необходимость постоянно отслеживать
приоритетность требований от версии к версии:
требования меняются, приоритеты тоже
Тест-дизайн
31
Типы тестирования: бизнес циклы
 Бизнес-циклы: сущность, которая описывает и
задаёт следующий уровень функционального
тестирования и служит про проверки
корректности работы алгоритмов и механизмов,
автоматизирующих не столько пользовательские
операции, сколько естественную цикличность
любого бизнеса, завершающуюся отчётами,
архивированием данных, выполнением нетипичных
для системы операций.
 Закрытие месяца, закрытие года, получение
очередной крупнооптовой партии товаров, расчёт
пени, реструктуризации долгов и т.п.
Тест-дизайн
32
Типы тестирования: GUI, usability
 Обычно данный тип тестирования не обладает
формальным признаком запрета выпуска версии
 Результатом выполнения данного типа тестов
является список рекомендаций и предложений по
улучшению
 Основной для проведения данного типа тестов
могут являться принятые в компании/проекте
стандарты оформления пользовательских
интерфейсов или общепринятые User Interface
Guidelines:
 Например, Microsoft Windows XP/2000 User Interface
Guidelines
Тест-дизайн
33
Типы тестирования: производительность
 Производительность: способность совершать
определённое количество операций в единицу
времени
 Тестирование производительности: нормальная,
ожидаемая модель нагрузки
 Нагрузочное: предельная или превышающая
нормальную модель нагрузки
 Стрессовое тестирование: сознательное
превышение нагрузок или урезание ресурсов с
целью посмотреть «как будет падать и
подниматься»
 Объёмное тестирование: тестирование способности
обработки больших объёмов операционных или
хранения архивных данных
Тест-дизайн
34
Типы тестирования: безопасность и доступ
 Выделяют два больших типа тестов:
 Разграничение прав доступа к данным и
операциям и соотв. невозможность
несанкционированного доступа к данным и выполнению
операций
 Устойчивость системы к внешним проникновениям,
несанкционированным вызовам функций, инъекциям
исполняемого кода, вызова нештатных ситуаций,
переполнений и т.д.
 Применяют как средства анализа кода, так и
накопленную (зачастую внешнюю) экспертизу
Тест-дизайн
35
Типы тестирования: конфигурационные тесты
 Тестирование системы на различных
конфигурациях программно-аппаратного стенда
 Цели:
 Проверка-выявление списка поддерживаемых окружений
 Подбор минимальных-оптимальных-рекомендуемых
параметров аппаратного обеспечения
 Обращайте внимание на составления «матрицы
покрытия»
 Очень ресурсоёмкий и затратный тип тестов
 Относиться в основном к тестированию
функциональности, но также может затрагивать и
вопросы тестирования производительности
Тест-дизайн
36
Типы тестирования: тестирование инсталляций
 Школа жизни для тестировщика 
 Современные инсталляции умеют очень глубоко
залазить в систему и на лету менять её компоненты
 Развёртывание – вариант инсталляции
 Инсталляция – отдельное и потенциально
достаточно сложное приложение, которое требует
отельного планирования и выполнения тестов
 Для тестирования инсталляций характерно
выделять отдельный список поддерживаемых
окружений и проводить отдельный цикл
конфигурационного тестирования
Тест-дизайн
37
РАБОТА С ТРЕБОВАНИЯМИ
Работа с изменяющимися требованиями
Пример нетестируемого требования
Пример тестопригодного требования
Почему не все могут и должны заниматься дизайном
Что было написано в требовании
• SRS-01 (до изменения)
– Форма регистрации нового пользователя в
системе “InfoSecurityManagement” позволяет
вводить в реестр пользователей данные о
пользователе и его роли:
•
•
•
•
Тест-дизайн
Имя,
Доменное имя,
Должность,
Полномочия в системе
39
Что изменилось в требовании
•
SRS-01.1 (после изменения)
– Форма регистрации нового пользователя в системе
“InfoSecurityManagement” позволяет вводить в реестр
пользователей данные о пользователе и его роли:
•
•
•
•
Имя,
Доменное имя,
Должность,
Полномочия в системе
– Если такой пользователь уже существует в реестре системы
“InfoSecurityManagement”, на форме ввода появляется его Email адрес.
Тест-дизайн
40
Практический кейс




Что должно произойти в тест-кейсах?
Кто это должен сделать?
Когда это может происходить?
Вы уверены, что ваш рядовой тестер понимает глубину
задачи?
Тест-менеджмент
41
Работа с требованиями
•
Пример нетестируемого требования
производительности ПО
– Время отклика системы должно находится в
приемлемых рамках
– Время отклика (Отклика на какой операции?)
системы (что такое система в этом требовании: UI,
DB, client + server + network?) должно находится
(Условия? Нагрузка?) в приемлемых рамках
(Цифры?)
42
Работа с требованиями
•
Пример тестопригодного требования
– Время отклика системы с точки зрения конечного
пользователя (end-to-end) во время продуктивной нагрузки
(50 пользовательских сессий в режиме «менеджер» / 15
пользовательских сессий в режиме «аналитик») при
загруженности пропускного канала от клиентской системы
до сервера приложений в пределах 50% для сети 100
Mb/sec и утилизации ресурсов сервера приложений (CPU,
RAM) в рамках 70-80%, а клиентской машины в рамках 4060%, не должно превышать 1 секунды для операций
создания записи (сущности) и 3 секунд для операций
поиска.
– Время выполнения аналитических отчётов определяется
отдельно для каждого отчёта
43
Работа с требованиями
•
•
Что мы упустили в требовании?
– Время отклика … при загруженности пропускного канала …,
не должно превышать 1 секунды … время выполнения …
Что с ресурсами?.. Какими они должны быть?
44
Работа с требованиями
•
Пример тестопригодного требования
– Время отклика системы с точки зрения конечного пользователя
(end-to-end) во время продуктивной нагрузки (50
пользовательских сессий в режиме «менеджер» / 15
пользовательских сессий в режиме «аналитик») при
загруженности пропускного канала от клиентской системы до
сервера приложений в пределах 50% для сети 100 Mb/sec, не
должно превышать 1 секунды для операций создания записи и
3 секунд для операций поиска записи.
– Время выполнения аналитических отчётов определяется
отдельно для каждого отчёта.
– Объём используемой оперативной памяти должен оставаться
стабильным.
45
Работа с требованиями
•
Практические соображения
– Изменения в требованиях должны однозначно
отражаться в изменении функциональности системы
и покрывающего тестового набора
– Анализ покрытия требований рекомендуется
проводить на этапе проектирования тестов, при
условии что процесс гарантирует фиксированные
требования в рамках итерации
46
Работа с требованиями
•
Практические соображения
– При условии «плавающих» требований, анализ покрытия
производится по факту поставки версии системы, в которую
включается набор актуальных требований. Данный подход
увеличивает общее время отведённое на тестирование за
счёт технологических простоев
– Каждое требование должно быть протестировано (иметь
тест)
– Каждый тест должен относиться к какому-либо требованию
47
Работа с требованиями
•
Практические соображения
– Требования могут порождаться тестами (при
использовании agile-методологий)
– Требования обязательно должны находиться под
версионным контролем
48
ЭКВИВАЛЕНТНОЕ РАЗБИЕНИЕ
Что значит «протестировать полностью»?
Классы эквивалентности
Виды тестовых сценариев
Тест-дизайн
Что значит «протестировать полностью»?
50
Полное тестирование это –
 Когда покрыты все:
 строки кода программы
 ветви кода в программе
 пути в коде
 входные данные и все их возможные комбинации
 последовательности комбинаций входных данных
 ...
51
Почему нельзя полностью протестировать программу
 Количество всех возможных комбинаций входных
данных слишком велико, чтоб его можно было
проверить полностью
 Количество всех возможных последовательностей
выполнения кода программы также слишком велико,
чтобы его можно было протестировать полностью
 Пользовательский интерфейс программы (включающий
все возможные комбинации действий пользователя и
его перемещений по программе) обычно слишком
сложен для полного тестирования
52
Виды тестовых сценариев




Позитивные сценарии
Негативные сценарии
Граничные сценарии
Исследовательские сценарии:
 «А что должно быть если…»
53
Техники тестирования. Эквивалентное разбиение
•
•
Чтобы избежать ненужного тестирования, разбейте
область входных значений на группы эквивалентных
тестов
Два теста считаются эквивалентными если они
настолько похожи, что проводить оба бессмысленно
54
Техники тестирования. Эквивалентное разбиение
•
•
Если тест с некоторым значением из данного класса
эквивалентности обнаруживает ошибку, то было
бы разумно ожидать обнаружения той же ошибки
тестом с любым другим значением из данного класса
эквивалентности
Выберите одно входное значение из каждого класса
эквивалентности в качестве представителя целой
группы значений
55
Техники тестирования. Эквивалентное разбиение
Рассмотрим пример
– Программа складывает два целых числа
– Каждое из слагаемых – не более чем целое
двузначное число
– Программа запрашивает у пользователя два числа и
выводит результат
• Предлагайте тесты >>
56
Классы эквивалентности
Классы корректных
данных
Классы некорректных
данных
Граничные и
специальные значения
Первое
слагаемое
от -99 до -10
от -9 до -1
0
от 1 до 9
от 10 до 99
> 99
< -99
0, 1, -1, 9, -9
10, -10
99, -99
100, -100
Второе
слагаемое
-”-”-
-”-”-
-”-”-
Сумма
от -198 до -100
от -99 до -1
0
от 1 до 99
от 100 до 198
> 198
< -198
(-99, -99)
(-49, -51)
(99, 99)
(49, 51)
57
Техники тестирования. Эквивалентное разбиение
Порядок действий
• Перечисляются все переменные (как входные, так и
выходные)
• Для каждой переменной определяется разбиение на
классы
• Строятся все возможные комбинации классов
• В качестве представителей берутся граничные,
приграничные или специальные значения
58
Техники тестирования. Эквивалентное разбиение
Какие еще сущности можно разбивать на классы
эквивалентности
•
•
•
•
•
•
•
•
•
числа
символы
количество (записей в БД, строк)
длина строки
размер файла
объем памяти
разрешение экрана
версии операционной системы, библиотек
объем передаваемых данных
59
Техники тестирования. Эквивалентное разбиение
Практические примеры
«Треугольник»
 Программа запрашивает три числа
 Определяется тип треугольника, имеющего стороны
введенной длины: равносторонний,
равнобедренный, разносторонний
 Предлагайте тесты >>
60
Техники тестирования. Эквивалентное разбиение
• Корректный разносторонний треугольник
• Корректный равносторонний треугольник
• Три корректных равнобедренных треугольника (a=b,
b=c, a=c)
• Одна, две или три стороны равны нулю (5 тестов)
• Одна сторона отрицательная
• «Почти» выполняется правило треугольника (три
варианта a+b=c, a+c=b, b+c=a)
• Не выполняется правило треугольника (три варианта
a+b<c, a+c<b, b+c<a)
• Нецелое число или не число
• Неправильное количество аргументов
61
ТЕСТИРОВАНИЕ НА ОСНОВЕ СЦЕНАРИЕВ
И РИСКОВ
Пользователь прежде всего
Немного agile и экстрима
Когда страшно это хорошо
Тест-дизайн
Техники: тестирование на основе сценариев
• Суть метода – тестировщик выполняет сценарии
пользователей
• Разновидности сценариев:
– Истории пользователя
– Варианты использования (use cases)
– Тестовые сценарии (test cases)
63
Техники: тестирование на основе сценариев
• Сценарии могут использоваться как в разработке,
так и в тестировании
• При использовании их в тестировании
– Тестировщики следуют сценариям, которые
использовались при разработке
– Создают новые сценарии путем комбинации
имеющихся
64
Техники: тестирование на основе сценариев
 Сценарии, использовавшиеся при разработке:
 Уже проверены самими разработчиками
 Не учитывают нестандартные случаи, намеренно
неправильное использование
 Новые сценарии:
 Возможно никогда не встретятся в реальной
эксплуатации
 Требуют время на написание
65
Техники: тестирование на основе рисков
Подходы к тестированию на основе рисков
• Приоритезация требований в соответствии с оценкой
рисков; проверка требований соглано приоритетам
• Приоритезация проблемных областей в соответствии с
оценкой рисков; целенаправленный поиск ошибок
определенного типа
66
Техники: тестирование на основе рисков
Как понять что такое «рискованная область»
• Рисуем схему приложения
– Сайт бронирования билетов
•
•
•
Определяем веса узлов и переходов
Контролируем основные и альтернативные пути
«Где тонко – там и рвётся»
67
Техники тестирования. Проблемы выбора
• Не рекомендуется ограничиваться какой-либо одной
техникой тестирования. Как правило, используются
их сочетания
• В общем случае комбинация техник такова:
 Определить зоны высшего риска
 Выделить сценарии и их параметры
 Создать тестовые сценарии
 Разбить параметры на классы эквивалентности
68
Техники тестирования. Проблемы выбора
•
Контрольные вопросы при использовании
комбинации техник тестирования:
– Какие области наиболее рискованы? Как будут
приоритезированы требования?
– Какие есть сценарии использования для этих
областей?
– Какие параметры есть у этих сценариев?
– На какие классы эквивалентности их можно
разбить?
– И наконец: какие тест-кейсы нужно составить?
69
Практические примеры
Описание тестируемого функционала:




Поле для ввода названия папки
Кнопка «Сохранить»
Название папки не должно превышать 64 символа
Ваши предложения?
70
Практический пример
Диалог сохранения файла
71
«Фиксируем шаги»
•
•
•
•
Сначала выделяем наиболее рискованные (и
важные) области – собственно сохранение , выбор
нужного места, сохранение с длинным именем, с
национальными символами, перезапись и т.п.
Потом выясняем какие сценарии использования (use
case)
Выясняем классы эквивалентности
Пишем тест-кейсы (позитивные, негативные,
исследовательские)
72
Способы снижения количества тестов
Рассмотрим пример
• Окно поиска в текстовом редакторе
73
•
•
•
•
Подсчитаем количество тестов
5 переменных:
– Find what (FW) – строка
– Match whole words only (MW) – Boolean
– Match case (MC) – Boolean
– Regular expression (RE) – Boolean
– Direction (D) – перечисляемый тип (Up, Down)
Тестовые значения
– FW = {‘lower’; ‘UPPER’; ‘MiXeD’}
– MW, MC, RE = {Yes; No}
– В = {Up; Down}
Итого: 3 х 2 х 2 х 2 х 2 = 48 тестов
Способы снижения количества тестов
•
•
•
Выбор комбинаций
Для данного случая методы выбора на основе рисков и
на основе сценариев малопригодны
Оптимальнее использовать механический перебор по
некоторой системе:
– Полный перебор
– Все пары (каждый с каждым)
– Все значения хотя бы по разу
75
Способы снижения количества тестов
Полный перебор (все Nки)
FW
MW
MC
RE
D
1
L
Y
Y
Y
Up
2
U
Y
Y
Y
Up
3
M
Y
Y
Y
Up
4
L
Y
Y
Y
Up
5
L
N
Y
Y
Up
…
…
…
…
…
…
47
M
N
N
N
Up
48
M
N
N
N
D
76
Способы снижения количества тестов
Все значения хотя бы по разу
FW
MW
MC
RE
D
1
L
Y
N
Y
Up
2
U
N
Y
N
D
3
M
Y
Y
N
Up
3 теста, а не 48
77
Способы снижения количества тестов
Все пары (каждый с каждым)
FW
MW
MC
RE
D
1
L
Y
N
Y
Up
2
L
N
Y
N
D
3
U
Y
Y
N
Up
4
U
N
N
Y
D
5
M
N
N
N
Up
6
M
Y
Y
Y
D
Этот метод является «золотой серединой»
 Метод «всех пар» хорошо работает для независимых переменных
 Зачастую случайное тестирование хорошо приближается к методу «всех пар»

78
Тест управляемый данными

Форма валидации введенного значения
 Требование: если введено целочисленное
значение от 0 до 9 (включительно),
возвращается значение TRUE
 Предлагайте тесты (я записываю)
Тест-дизайн
79
Тест управляемый поведением

Форма заказа sushi
 Требование: пользователь может
оформить или отредактировать
сформированный ранее в разделе «Меню»
заказ. Счёт формируется с учётом
накопительных скидок, выбранного
способа оплаты и доставки.
 Предлагайте тесты (я записываю)
Тест-дизайн
80
«Фиксируем подход»
• Разработка тестов
 Определение типа теста: «поведение» или
«данные»
 Logic-driven или data-driven test case
 Если тест управляется логикой поведения
 Составление путей и «узлов»
 Определяется основной «путь»
 Определяются и ограничиваются альтернативные «пути»
 Если тест управляется данными
 Составляется набор данных
 Данные приоретезируются
 Допустимые значения
 Граничные значения
 Значения за границами диапазона
Тест-дизайн
81
Практические примеры
Входные данные
 Бизнес по продаже апельсинов, имеющий
несколько представительств в различных
городах.
Задача
 Разобраться в системе и разработать пакет
тестовых сценариев
Тест-дизайн
82
Практические примеры
Центральное отделение
Сервер
приложений
БД
se
qu
e
re
sp
ns
on
re
st
po
ue
es
t
re q
re s
Оператор
Оператор
Оператор
Регион 1
Регион N
Сервер
приложений
Сервер
приложений
[1..10]
БД
БД
Регион 2
Оператор
Оператор
Оператор
...
[11..20]
Регион N-1
Оператор
Оператор
Оператор
[N..N+10]
Тест-дизайн
83
Анализ архитектуры
Архитектура
 Сервер приложений
 Сервер БД
 «Толстые» клиенты, около 10 операторов
Первые выводы и вопросы
 Большинство операций происходит на стороне клиента
 Тестируем клиентскую часть и сервер приложений
 Сервер приложения может работать со своей БД и с БД
центрального отделения
 БД не содержит никакой логики – только хранилище?
Тест-дизайн
84
Анализ конфигурационных требований
Требования к конфигурациям
 Клиентская часть поддерживается на 4-х ОС
 Сервер приложения поддерживается на 2-х ОС
 Локализация – система поддерживает два языка
 На тестирование выносится 20 функциональных
требований к клиентской части и 10 функциональных
требований к серверной части
Тест-дизайн
85
Пытаемся планировать
Вопросы к обсуждению
 Какие виды тестов будем проводить?
 Нагрузочного тестирования не будет, 10 операторов –
это не та нагрузка, которую стоит проверять (или
будет?)
 Что стоит автоматизировать, что нет?
 Какие окружения выделяем для тестирования?
Тест-дизайн
86
Попробуем прикинуть трудоёмкость
Допущения
 Допустим, на одно функциональное требование мы
предполагаем написать 5 тестовых сценариев
 Допустим, на прохождение 1-го тестового сценария
мы предполагаем потратить 5 минут
Посчитайте сами и ответьте на следующие вопросы:
 Сколько всего окружений получается?
 Сколько всего тестовых сценариев будет в системе?
 Время затраченное на проведение 1-го раунда
тестирования?
Тест-дизайн
87
Считаем окружения
Окружений: 16
 4 клиентские ОС * 2 языка = 8 клиентских конфигураций
* 2 серверные ОС = 16 окружений
Тестовых сценариев в системе: 150
 (20 клиентских требований + 10 серверных требований)
* 5 тестовых сценариев на одно требование = 150.
Сколько всего тестовых сценариев для проведения 1-го
раунда тестирования?
Тест-дизайн
88
Считаем время
Расчеты
Всего тестовых сценариев: 16 окружений * 150 тестовых
сценариев = 2400
Время на проведение 1-го раунда тестирования: (2400
тестовых сценарев * 5 минут) / 60 = 200 часов или 5
недель
Тест-дизайн
89
Давайте подумаем
Что мы не учли?
 Требования относятся к функциональности
(логике приложения) или к окружению
(системные функции, работа с ресурсами ОС и
т.д.).
Тест-дизайн
90
Разбор тестируемых функций
Что зависит обычно от окружения на клиенте и
сервере?
 Вход, выход, печать форм, получение языка ОС,
получение цветовой гаммы ОС, работа с
протоколами общения между серверами
приложений
Что не зависит от окружения?
 Получение информации из БД, запрос на сервер
приложения, анализ полученных данных на
клиенте и т.д.
Тест-дизайн
91
Подбиваем баланс по группам требований
Получаем:
 5 требований зависят от окружений на клиенте
 5 требований зависят от всех окружений
 5 требований зависят только от окружений сервера
приложений
 15 требований относятся к функциональности и не
зависят от окружений
Тест-дизайн
92
Пересчитываем
Итого:
 25 тестовых сценариев * 8 = 200 тестовых
сценариев зависящих от окружения на клиенте
 25 тестовых сценариев * 16 = 400 тестовых
сценариев зависящих от всех конфигураций
 25 тестовых сценариев * 2 = 50 тестовых
сценариев зависящих от окружения на сервере
приложений
 75 тестовых сценариев относятся к
функциональным тестам
200 + 400 + 50 + 75 = 725 тестовых сценариев
Тест-дизайн
93
Сила тест-дизайна
Расчеты
 Всего тестовых сценариев: 725
 Время на проведение 1-го раунда тестирования:
(725 тестовых сценариев * 5 минут) / 60 = 60,5
часов или 1,5 недели
Было: 200 часов или 5 недель
Стало: 60,5 часов или 1,5 недели
Экономия достигается за счёт
принимаемых допущений и связанных
с ними рисков
Тест-дизайн
94
Рекомендуемая литература
•
•
•
•
•
Введение в тестирование программного
обеспечения
Луиза Тамре
Introducing Software Testing
Издательство: Вильямс, 2003 г.
В этой книге изложены:
 Последовательность вхождения в процесс
тестирования с акцентом на ключевых функциях;
 Определение недостающих сведений и проведение
адекватного тестирования при недостаточно четких
требованиях;
 Изучение различных форматов документации для
регистрации тестовых примеров.
Рекомендуемая литература
•
•
•
•
•
Быстрое тестирование
Роберт Калбертсон, Крис Браун, Гэри
Кобб
Издательство: Вильямс, 2002 г.
Технология быстрого тестирования находит
`золотую середину` между соблюдением сроков и
гарантией высокого качества. Описанию этой
технологии и посвящена книга.
Книга написана с учетом громадного опыта работы
авторов в области тестирования ПО. Она окажет
несомненную пользу всем специалистам, которые
работают как в крупных, так и в небольших
организациях, занимающихся созданием ПО.
Рекомендуемая литература
97
•
•
•
•
Тест-дизайн
Тестирование dot com
Роман Савин
Издательство: Дело, 2007 г.
Этот курс лекций создан для тех, кто
хочет обучиться тестированию, понять,
как вести себя в корпоративном
окружении, и добиться
профессионального и личностного
роста. Он будет интересен и участникам
процесса разработки программного
обеспечения, рекрутерам, людям,
связанным с интернетом или пишущим
о нем, и просто всем желающим понять
кухню интернет-стартапов
Слава Панкратов
«Тест-дизайн»
http://pankratov.org.ua
slava@pankratov.org.ua
icq: 109882167