Презентация Григория Сенина

Test Process Framework
Тестирование в узком и широком смысле


Тестирование в узком смысле, иначе -- динамическое
тестирование, предполагает выполнение кода
программы (программного продукта)
Тестирование в широком смысле часто называют
верификацией; оно включает и другие методы
(например, просмотр программного кода)
Мы посвятим некоторое время изучению понятия верификации, но
будем пользоваться, в основном, первым значением термина
‘тестирование’
Отладка не является тестированием
Отладка направлена на установление точной
природы известной ошибки
Отладку понимают как процесс поиска и
исправления ошибок, факт наличия которых
устанавливается при тестировании
Верификация
Чтобы понять, что нечто наступило, нужно уметь
его померить
Энди Грув, корпорация Интел

Верификация («правильно ли мы делаем?»)
–
в. продукта: критерии готовности (readiness criteria)
–
в. деятельности: критерии завершения (exit criteria)
Здесь мы что-то делаем
Здесь мы проверяем,
сделали или нет
Верификация и валидация


Верификация
–
verus верный => “правильность”
–
отвечает на вопрос: «правильно ли мы делаем работу?»
Валидация
–
validus здравый => “польза, ценность”
–
отвечает на вопрос: «правильную ли работу мы делаем?»
Верификация и валидация

ИСО 9000/2000 (не только программный продукт):
–
Верификация – проверка продукта на соответствие входным
данным (~ проектным требованиям, спецификациям)
–
Валидация – проверка продукта на соответствие потребностям
пользователя
верификация
Потребности
пользователя
Входные
данные
Проектирование
и разработка
валидация
Выходные
данные
Статические и динамические методы
Unit/Integration testing,
Prototype/Intermediate release testing,
Subsystem and System testing
Verification:
static techniques
Testing: dynamic
Technical Reviews, Formal Inspections,
Walkthroughs, Desk checks, Audits
techniques
Разработка
Требования
Архитектура
Проектирование
Реализация
Внедрение
Цель тестирования
Общепринятое определение:

Цель тестирования – снизить неопределённость
нашего представления о качестве программного
продукта
–
Другими словами, обнаружить ошибки до того, как это сделает
Заказчик
Цель тестирования (другое определение)
Более широкое определение:

Цель тестирования – распознать дефекты в объекте
тестирования и увеличить вероятность того, что он
при любых обстоятельствах будет работать
надлежащим образом в соответствии с
установленными требованиями
–
–
Роль тестирования состоит в получении объективной
информации, способствующей принятию более качественных
деловых решений.
Роль тестирования - держать в курсе всех проблем, имеющих
отношение к поставке продукта!
Testing is independent. What does it mean?

Developers are never responsible for testing (except unit
testing)

Test completion criteria are set before testing starts

Tests are developed from requirements

Defects are reported to the senior management as well as to the
project manager
Анатомия тестирования
цикл тестирования
develop
раунд тестирования
исправлений
product
product
test
test
failures?
failures?
fix
fix
Failure -- расхождение с ожидаемым результатом, отказ
Fix/debug -- поиск изъянов в продукте (причин отказа) и
их исправление
better
product
No failures!
Вариации доработок



Fix1 -- изъян в коде программы; переделывается только код
Fix2 -- изъян в спецификациях (технический дизайн);
меняются и спецификации, и код
Fix3 -- изъян в архитектуре/функциональном дизайне;
меняются архитектура, спецификации и код
Requirements
cause of
failure
Fix1:
‘failed’
product
Fix2:
Build
changed
product
Func design
Design
Design
cause of
failure
Design
cause of
failure
Func design
Fix3:
Build
Build
‘failed’
product
changed
product
‘failed’
product
changed
product
Тестирование в V-модели
Requirements
Architecture
fix4
Acceptance test
fix3
System test
Design
fix2
Integration tests
Construction
fix1
Development
Unit tests
Testing
Доработка как улучшение


V-модель:
–
доработка = «систематическое исправление»
–
возникает «предсказуемо» (уровень), но слишком поздно…
Итеративная/эволюционная модель:
–
доработка = «улучшение» (increment, enhancement)
–
является маленьким каскадом, или итерацией
с предыдущей
итерации продукт
требования
проектирование
реализация
тестирование
итерация
улучшенный
продукт
на следующую
итерацию
Фазы в традиционном и итеративном ЖЦ


Традиционный ЖЦ
–
предполагается, что определённая деятельность должна
завершиться, прежде чем начнётся другая (Requirements, потом
Design, потом Implementation…)
–
в каждой фазе ровно один вид деятельности; фазы именуются в
соответствии с ним
Итеративный ЖЦ
–
каждая фаза включает, вообще говоря, все виды деятельности (в
разных пропорциях)
–
название фазы обозначает не вид деятельности, а состояние, в
котором находится проект
Тест-проектирование в V-модели
Requirements
Acceptance test design
Architecture
System test design
Design
Integration test design
Construction
Unit test design
Development
Test design
Acceptance test
System test
Integration tests
Unit tests
Test execution
Фазы проекта* и состав работ по тестированию
Inception
–
test strategy (optional)
–
acceptance criteria and
procedures
–
review PMP
Elaboration
Requirements:
–
test strategy
–
study, review Reqs
–
outline test plan
Construction
Design 2, Implementation
- detail/refine test plan
- prepare/revise test data
- develop automatic test suites
(e.g. build acceptance suite)
System Testing
- perform testing rounds
- perform documentation testing
Acceptance Testing
Architecture (Design 1):
–
study specifications
–
draft test plan
–
design test data
* возможна как итеративная, так и
каскадная (waterfall) модель разработки
Rational Unified Process
Две основные стадии ЖЦ

Инженерная (исследовательская)


завершается, когда есть ясное понимание, КАК делать продукт
(архитектура)
Производственная

состоит главным образом в изготовлении продукта
Рубеж между стадиями - главный рубеж проекта
 соотношение сроков и ресурсов между стадиями определяется
спецификой проекта
 Чёткая граница и оптимальный баланс между двумя стадиями
характерны для большинства успешных проектов
Rational Unified Process
Четыре фазы, ортогональные циклу разработки

Inception: концепция = ясно, ЧТО нужно сделать
Инженерная
стадия

Elaboration: архитектура = ясно, КАК сделать

Construction: полноценный продукт разработки («бета»)

Transition: отшлифованный продукт у Заказчика
Главные
рубежи
Основной результат
каждой фазы
Концепт.
Концепт.
проработка
проработка
Производственная
стадия
Эскизная
Эскизная
проработка
проработка
Реализация
Реализация
время
Внедрение
Внедрение
Rational Unified
Process (RUP)
Фаза
Основные инженерные процессы
Inception
Elaboration
Construction
Transition
Требования
Показывает, КОГДА мы выполняем какую-то работу
Проектирование
Реализация
Тестирование
Внедрение
Rational Unified
Process (RUP)
Фаза
Требования
Проектирование
Реализация
Тестирование
Внедрение
Показывает, КАКОГО рода
работа выполняется
Основные инженерные процессы
Inception
Elaboration
Construction
Transition
Rational Unified
Process (RUP)
Фаза
Основные инженерные процессы
Inception
Elaboration
Construction
Transition
Подробный планграфик
Проектирование
тестов
Подготовка
тестовых данных
Автоматизация
тестирования
Анализ CR и PR
Проведение
тестирования
Отслеживание
дефектов
Приемосдаточные
испытания
Требования
Проектирование
Реализация
Планирование
тестирования
Тестирование
Установка
инструментов
тестирования
Стратегия
тестирования
Набросок тестплана
Подготовка
тестовой среды
Просмотр
требований
Внедрение
Анализ
дефектов,
обнаруженных в
ходе приемосдаточных
испытаний
Уточнение плана
регрессионного
тестирования
Iterations achieve demonstrable results
Inception
Elaboration
Proof-of-concept prototype
Architectural prototype
Alpha release (all critical use cases)
Construction
Transition
Beta release
Final product
Итерация -- каскадный «подпроект»
Запланированный
«слой»
функциональности
Результаты с
предыдущей итерации
Управление требованиями
Проектирование
Реализация
Тестирование
Внедрение
Результаты для
следующей итерации
Анатомия типичной итерации в середине ЖЦ
Прошлая
итерация
Текущая итерация
Детализация
СИС
Проектирование
Реализация
версия
версия
test
results
test
results
Критерии
оценки
Функциональная добавка
(СИС)
Стратегия
разработки и
тестирования
План
тестирования
План
итерации
Выполнение тестов
Оценка
промежуточного
продукта
Решение о завершении
итерации и её оценка
Следующая
итерация
Вариации моделей ЖЦ
Спиральная и итеративная модели являются
наиболее общими, рамочными описаниями
процесса разработки
Несколько известных моделей являются их
частными случаями

incremental development
–

progressive build (частный случай предыдущего)
–

каждая очередная итерация наращивает функциональность
анализ требований выполняется один раз; каждая следующая итерация
наращивает функциональность
прототипирование
–
в первой итерации строится прототип будущего продукта, используется как
proof-of-concept и затем выбрасывается; основная цель: уточнить у Заказчика
требования путём демонстрации
–
следующая итерация м.б. архитектурным прототипом и т.д.
Цена качества
Слагаемые затрат на качество:
 затраты на предупредительные меры
 например, выстраивание инженерных процессов по CMM
 затраты на выявление дефектов
 затраты на корректирующие меры (включая
потери от выпуска некачественного продукта):
 внутренние:
 исправление дефектов, найденных при тестировании
 потери от этого внутри Компании (дополнительное регрессионное
тестирование, потери и упущенная выгода от позднего выпуска
продукта, моральный климат и др.)
 внешние:
 расходы на дополнительное обслуживание, анализ рекламаций
 потери, понесённые от претензий и исков клиентов (в том числе
дополнительная разработка и тестирование, ущерб имиджу и др.)
Цена качества по Juran
Безупречный продукт:
Некачественный продукт:
высокие затраты на тестирование
высокие потери от рекламаций
Затраты
Суммарные затраты
на качество
минимум
затрат
на исправление,
плюс потери от
оставшихся дефектов
на предупреждение
и выявление
Уров ень качеств а
Основной вопрос тестирования
Вопрос: Сколько нужно тестировать?
Ответ: Чуть-чуть меньше, чем слишком много.
Из фольклора тестировщиков
Какой объём тестирования достаточен?
Когда продукт готов к выпуску?
Аналогия для размышления:
Какой объём лечения достаточен?
Когда пациент готов к выписке?
Когда завершать тестирование
Тестирование следует продолжать до тех пор, пока
затраты на обнаружение и исправление дефектов
НИЖЕ, чем будущие потери от сбоев продукта при
его эксплуатации
Тим Комен, Мартин Пол, 1999
Risk-based testing

Define risky product area
 critical requirements/use cases
 new technology
 complex component
 frequently used
 recent failure
 ...

Adjust test effort to the risk levels
 Risk areas => Test priorities

Use combined test completion criteria
 serious defect may be accepted in a low-risk area
Различные классификации тестирования


исполняется или не исполняется программный код
–
статическое vs динамическое
–
подклассификация статических методов
используется или нет знание о способе реализации
–

по «уровню»
–

функциональность, производительность, совместимость, надёжность,
удобство, ...
по природе объекта тестирования/приложения
–

unit, integration, subsystem, system, beta, acceptance
по свойствам объекта тестирования
–

чёрный ящик vs прозрачный ящик
mainframe, client-server, ОO, Web , real-time, scientific, E-business…
по способу разработки тестов
–
методы тест-проектирования
Уровни тестирования

Автономное
–

Интеграционное
–

отдельные модули
стыковка модулей




база тестирования -- дизайн,
внутренние интерфейсы
mainly developers
white & black box
покрытие кода
«Подсистемное»
–
–
–
промежуточный
выпуск

функциональный
компонент

«инкремент»


Системное

Приемочное

база тестирования -- внешние
функции
mainly testers
black box
покрытие требований
Уровни тестирования
подсистема
модуль
модуль
компонент
готовый
модуль
Автономное
тестирование
Приемка
готовых модулей
система
Интеграционное
тестирование
Тестирование
подсистем
Системное
тестирование
Уровень тестирования
Характеристика уровней тестирования
Автономное
Проводится разработчиками после того, как завершена разработка кода модулей/блоков.
Тестирование выполняется в конце работ по созданию порученного модуля. Программист
проводит тестирование, чтобы убедиться, что он завершил выполнение задания - критерий
завершения удовлетворен. Комбинация методов прозрачного и черного ящиков.
Интеграционное
Тестирование проводится, когда происходит интеграция нескольких модулей в более
крупные компоненты. Происходит объединение модулей, а для временно отсутствующих
элементов системы создаются заглушки. Для имитации окружения компонентов создаются
тест-драйверы. Серый ящик.
«Подсистемное»
Система разбита на функциональные (или архитектурные) части или слои, которые
тестируются по отдельности. Каждая из них «квалифицируется» в соответствии с объёмом
функциональности, которую она реализует. Возможно использование тест-драйверов.
Регрессионное тестирование. Чёрный ящик.
Системное
Системное
Система интегрирована целиком. Проведено полное функциональное тестирование.
Группа разработки занята исправлением дефектов, обнаруженных в ходе тестирования.
Регрессионное тестирование.
Чёрный ящик
Приемосдаточные
испытания
Заказчик проводит собственное тестирование, чтобы убедиться, что система удовлетворяет
требованиям.
Обычно план приемо-сдаточных испытаний известен группе системного тестирования
заранее. «Валидация».
СопроСопровождение
вождение
Проводится ненавязчивое тестирование системы в ходе эксплуатации для измерения
параметров качества, в том числе производительности, использования системных
ресурсов, а также для определения корректирующих действий.
Заглушки и тест-драйверы


Тест-драйвер подменяет ту часть
системы (или внешней среды),
которая вызывает объект
тестирования
–
обеспечивает передачу входных данных в
объект тестирования
–
отображает результаты вызова или
проверяет их правильность
Заглушка подменяет часть
системы, вызываемую объектом
тестирования
–
имеет тот же интерфейс (API), что и
подменяемая часть
–
возвращает результат того же типа
драйвер
объект
тестирования
объект
тестирования
заглушка
Заглушки и тест-драйверы


Тест-драйверы и заглушки НЕ в полной мере
имитируют поведение недостающих компонентов
На разработку (и тестирование!) тех и других
требуются дополнительные ресурсы, что может
сделать их неоправданным
Типы тестирования по качествам продукта

Наиболее распространённые типы тестирования
Функциональное тестирование
соответствие (под)системы внешним спецификациям
Тестирование удобства использования
Тестирование производительности (нагрузочное)
быстрота отклика системы под нагрузкой
Тестирование установки
правильность и удобство установки системы на целевые платформы
Конфигурационное тестирование
совместимость с различными типами оборудования и ПО (напр.,
принтерами, навигаторами)
работа в разной операционной среде/на разных платформах
Подпроект тестирования
Тестирование -- подпроект в рамках проекта разработки




имеет относительную самостоятельность
(независимость тестирования)
представляет собой отдельный проект, если
выполняется независимой организацией
тест-менеджер -- менеджер подпроекта тестирования
группа тестирования под его управлением выполняет
все работы по тестированию
Виды работ при тестировании

Планирование и управление

Спецификация/проектирование

Подготовка среды и средств тестирования

Выполнение тестов

Анализ и отчетность

Рецензирование
Группа тестирования: роли и обязанности




Тест-менеджер
–
стратегия тестирования
–
планирование и управление
Тест-проектировщик
–
разработка тестовых сценариев и тестов
–
проектирование тестовых данных
–
проектирование тест-драйверов
Тестировщик
–
подготовка тестовых данных
–
выполнение тестов
–
автоматизация тестирования (скрипты)
–
bug/trouble reports
Программист
–
разработка тест-драйверов, генераторов данных и др.
Функции тест-менеджера

На начальной фазе проекта
–
–
–
–
–

вырабатывает/анализирует/согласует с руководителем
проекта критерии и процедуры приёмки;
участвует в составлении плана-графика проекта в части,
касающейся работ по тестированию
разрабатывает стратегию тестирования
определяет инструментарий тестирования и управления
ошибками (Robot, CQ)
определяет необходимость разработки специального ПО
для тестирования (e.g. test drivers)
В дальнейшем
–
–
организует работы по тестированию в соответствии со
стратегией тестирования и планом-графиком проекта
еженедельно отчитывается перед руководителем проекта и
начальником отдела
Функции тест-проектировщика

разрабатывает планы тестирования
–
–
–

детализирует планы тестирования после
–
–

сценарии тестирования
тесты
данные для тестирования
уточнения проектных решений
получения ОТ
корректирует планы тестирования
–
–
в соответствии с изменениями требований и проектных
решений
с учётом обнаруженных ошибок
Функции тестировщика

выполняет работы по тестированию, порученные
ему тест-менеджером
–
–

проведение тестирования
автоматизация тестов
оформляет результаты тестирования
–
–
протоколы тестирования
описания дефектов (Bug reports)
Продукция группы тестирования

Стратегия тестирования

План тестирования

Тестовые сценарии

Тестовые данные, драйверы, скрипты

Протоколы тестирования/отчеты о дефектах

Отчётность о ходе тестирования: метрики, индикаторы

Итоговый отчет
Роли по уровням тестирования

Автономное тестирование модулей -- unit testing
программист -- разработчик модуля

Интеграционное, «сборочное» тестирование -integration testing
разработчики и в некоторых случаях тестировщики

Тестирование подсистем -- subsystem testing
тестировщики

Системное тестирование -- system testing
тестировщики

Приемочное тестирование -- acceptance testing
заказчик с участием МП и тестировщиков
Объекты тестирования

ПП в целом является объектом системного
тестирования = «конечным» ОТ
–


проект может предусматривать разработку и промежуточных
объектов, подвергаемых тестированию
ОТ при итеративной разработке:
–
прототипы
–
функциональные подсистемы, получаемые наращиванием
Каждая итерация заканчивается созданием
промежуточного продукта, который становится
объектом тестирования
Тестирование в итеративном процессе разработки
Текущая итерация
Прошлая
итерация
Требования к
системе,
стратегия
разработки
Критерии
выпуска ОТ
План
итерации
Проектирование
План
тестирования
Реализация
версия
версия
test
results
test
results
тестраунд
Выполнение
тестов
Оценка результатов
тестирования
Критерии оценки ОТ
Следующая
итерация
Проведение тестирования

Во второй половине итерации
–

по готовности ОТ (завершена разработка)
Задание на тестирование – «контракт» тестменеджера с группой разработки
–
рамки, сроки, объект тестирования
–
критерии завершения ~ критерии качества ОТ
–
ресурсы и глубина тестирования

Выполнение контракта=цикл тестирования

Оценочное тестирование
–
вне цикла тестирования: «незрелый» ОТ
Тест-раунд -- тестирование определённой версии ОТ


версия ОТ (=Build)
–
передаётся из группы
разработки
–
отвергается, если не
проходит приёмочное
тестирование
приёмочное
тестирование
–
реализуется сценарием
плана тестирования
–
может
автоматизироваться
–
включает проверку
номера версии

объём тестирования в
каждом тест-раунде
–
может варьироваться в
зависимости от сроков,
ресурсов, качества ОТ
–
минимум: проверка
только что исправленных
ошибок
–
типично: регрессионное
тестирование (не
всплывают ли ранее
исправленные ошибки?)
–
максимум: полное
тестирование в
соответствии с ПТ