Test Process Framework презентация

Содержание

Тестирование в узком и широком смысле Тестирование в узком смысле, иначе -- динамическое тестирование, предполагает выполнение кода программы (программного продукта) Тестирование в широком смысле часто называют верификацией; оно включает и другие

Слайд 1

Test Process Framework

Слайд 2Тестирование в узком и широком смысле
Тестирование в узком смысле, иначе --

динамическое тестирование, предполагает выполнение кода программы (программного продукта)
Тестирование в широком смысле часто называют верификацией; оно включает и другие методы (например, просмотр программного кода)

Мы посвятим некоторое время изучению понятия верификации, но будем пользоваться, в основном, первым значением термина ‘тестирование’

Слайд 3Отладка не является тестированием
Отладка направлена на установление точной природы известной ошибки

Отладку

понимают как процесс поиска и исправления ошибок, факт наличия которых устанавливается при тестировании

Слайд 4Верификация
Чтобы понять, что нечто наступило, нужно уметь его померить
Энди Грув, корпорация

Интел

Верификация («правильно ли мы делаем?»)
в. продукта: критерии готовности (readiness criteria)
в. деятельности: критерии завершения (exit criteria)




Здесь мы что-то делаем

Здесь мы проверяем, сделали или нет

Слайд 5Верификация и валидация
Верификация
verus верный => “правильность”
отвечает на вопрос: «правильно ли мы

делаем работу?»
Валидация
validus здравый => “польза, ценность”
отвечает на вопрос: «правильную ли работу мы делаем?»

Слайд 6Верификация и валидация
ИСО 9000/2000 (не только программный продукт):
Верификация – проверка продукта

на соответствие входным данным (~ проектным требованиям, спецификациям)
Валидация – проверка продукта на соответствие потребностям пользователя

Слайд 7Разработка
Статические и динамические методы
Требования
Реализация
Testing: dynamic techniques
Архитектура
Проектирование
Verification: static techniques
Technical Reviews, Formal Inspections,

Walkthroughs, Desk checks, Audits

Внедрение


Unit/Integration testing, Prototype/Intermediate release testing, Subsystem and System testing

Слайд 8Цель тестирования
Общепринятое определение:
Цель тестирования – снизить неопределённость нашего представления

о качестве программного продукта
Другими словами, обнаружить ошибки до того, как это сделает Заказчик

Слайд 9Цель тестирования (другое определение)
Более широкое определение:
Цель тестирования – распознать дефекты

в объекте тестирования и увеличить вероятность того, что он при любых обстоятельствах будет работать надлежащим образом в соответствии с установленными требованиями
Роль тестирования состоит в получении объективной информации, способствующей принятию более качественных деловых решений.
Роль тестирования - держать в курсе всех проблем, имеющих отношение к поставке продукта!

Слайд 10Testing 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

Слайд 11Анатомия тестирования
цикл тестирования
develop

product

test
better product

fix
test

раунд тестирования исправлений

Failure -- расхождение с ожидаемым результатом,

отказ
Fix/debug -- поиск изъянов в продукте (причин отказа) и их исправление

fix






No failures!

Слайд 12Вариации доработок
Func design
Design
Build
Build
changed product

Design
Build
changed product

Design
Func design
Fix1:
Fix2:
Fix3:
Requirements
Fix1 -- изъян в коде программы;

переделывается только код
Fix2 -- изъян в спецификациях (технический дизайн); меняются и спецификации, и код
Fix3 -- изъян в архитектуре/функциональном дизайне; меняются архитектура, спецификации и код

Слайд 13

Тестирование в V-модели
Requirements
Design
Construction


Testing

Development
Unit tests
Integration tests
Acceptance test

Architecture

System test

Слайд 14Доработка как улучшение





продукт


требования
проектирование
реализация
тестирование
с предыдущей итерации
на следующую итерацию
итерация
V-модель:
доработка = «систематическое исправление»


возникает «предсказуемо» (уровень), но слишком поздно…
Итеративная/эволюционная модель:
доработка = «улучшение» (increment, enhancement)
является маленьким каскадом, или итерацией

Слайд 15Фазы в традиционном и итеративном ЖЦ
Традиционный ЖЦ
предполагается, что определённая деятельность должна

завершиться, прежде чем начнётся другая (Requirements, потом Design, потом Implementation…)
в каждой фазе ровно один вид деятельности; фазы именуются в соответствии с ним
Итеративный ЖЦ
каждая фаза включает, вообще говоря, все виды деятельности (в разных пропорциях)
название фазы обозначает не вид деятельности, а состояние, в котором находится проект

Слайд 16

Тест-проектирование в V-модели
Requirements
Design
Construction


Test execution

Development
Unit tests
Integration tests
Acceptance test

Architecture

System test

Acceptance test design
System test

design

Integration test design

Unit test design

Test design

Слайд 17Фазы проекта* и состав работ по тестированию
Inception
test strategy (optional)
acceptance criteria and

procedures
review PMP
Elaboration
Requirements:
test strategy
study, review Reqs
outline test plan
Architecture (Design 1):
study specifications
draft test plan
design test data


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

* возможна как итеративная, так и каскадная (waterfall) модель разработки

Слайд 18Rational Unified Process
Инженерная (исследовательская)
завершается, когда есть ясное понимание, КАК делать продукт

(архитектура)
Производственная
состоит главным образом в изготовлении продукта
Рубеж между стадиями - главный рубеж проекта
соотношение сроков и ресурсов между стадиями определяется спецификой проекта

Две основные стадии ЖЦ

Чёткая граница и оптимальный баланс между двумя стадиями характерны для большинства успешных проектов

Слайд 19Rational Unified Process
время

Концепт. проработка
Эскизная проработка
Реализация
Внедрение
Главные рубежи
Инженерная стадия
Производственная стадия

Концепт. проработка
Эскизная проработка
Реализация
Внедрение
Основной результат каждой фазы
Inception:

концепция = ясно, ЧТО нужно сделать
Elaboration: архитектура = ясно, КАК сделать
Construction: полноценный продукт разработки («бета»)
Transition: отшлифованный продукт у Заказчика

Четыре фазы, ортогональные циклу разработки

Слайд 20Внедрение
Тестирование
Реализация
Проектирование
Требования
Основные инженерные процессы
Фаза
Rational Unified
Process (RUP)
Показывает, КОГДА мы выполняем какую-то работу




Слайд 21Основные инженерные процессы
Rational Unified
Process (RUP)
Показывает, КАКОГО рода работа выполняется





Внедрение
Тестирование
Реализация
Проектирование
Требования
Фаза

Слайд 22Rational Unified
Process (RUP)




Планирование тестирования
Установка инструментов тестирования
Подробный план-график
Стратегия тестирования
Набросок тест-плана
Подготовка тестовой среды
Просмотр

требований

Приемо-сдаточные испытания
Анализ дефектов, обнаруженных в ходе приемо-сдаточных испытаний
Уточнение плана регрессионного тестирования

Проектирование тестов
Подготовка тестовых данных
Автоматизация тестирования
Анализ CR и PR
Проведение тестирования
Отслеживание дефектов

Transition

Construction

Inception

Elaboration

Фаза

Основные инженерные процессы

Внедрение

Тестирование

Реализация

Проектирование

Требования

Слайд 23Iterations achieve demonstrable results
Proof-of-concept prototype
Architectural prototype
Alpha release (all critical use cases)
Beta

release

Final product

Inception

Elaboration

Construction

Transition

Слайд 24Итерация -- каскадный «подпроект»
Запланированный «слой» функциональности

Результаты с предыдущей итерации



Результаты для следующей

итерации


Основные инженерные процессы

Управление требованиями

Проектирование

Реализация

Тестирование

Внедрение

Слайд 25
Выполнение тестов
Анатомия типичной итерации в середине ЖЦ
Прошлая итерация
Следующая итерация
Текущая итерация
Проекти- рование
Реализация
План итерации
План тестирования
версия
версия
test results
test results
Оценка промежуточного продукта
Детализация СИС


Критерии

оценки

Решение о завершении итерации и её оценка

Стратегия разработки и тестирования

Функциональ-ная добавка (СИС)

Слайд 26Вариации моделей ЖЦ
Спиральная и итеративная модели являются наиболее общими, рамочными описаниями

процесса разработки
Несколько известных моделей являются их частными случаями
incremental development
каждая очередная итерация наращивает функциональность
progressive build (частный случай предыдущего)
анализ требований выполняется один раз; каждая следующая итерация наращивает функциональность
прототипирование
в первой итерации строится прототип будущего продукта, используется как proof-of-concept и затем выбрасывается; основная цель: уточнить у Заказчика требования путём демонстрации
следующая итерация м.б. архитектурным прототипом и т.д.

Слайд 27Цена качества
Слагаемые затрат на качество:
затраты на предупредительные меры
например, выстраивание инженерных

процессов по CMM
затраты на выявление дефектов
затраты на корректирующие меры (включая потери от выпуска некачественного продукта):
внутренние:
исправление дефектов, найденных при тестировании
потери от этого внутри Компании (дополнительное регрессионное тестирование, потери и упущенная выгода от позднего выпуска продукта, моральный климат и др.)
внешние:
расходы на дополнительное обслуживание, анализ рекламаций
потери, понесённые от претензий и исков клиентов (в том числе дополнительная разработка и тестирование, ущерб имиджу и др.)

Слайд 28Цена качества по Juran
на предупреждение и выявление
на исправление, плюс потери от

оставшихся дефектов

минимум затрат

Суммарные затраты на качество

Некачественный продукт: высокие потери от рекламаций

Безупречный продукт: высокие затраты на тестирование

Слайд 29Основной вопрос тестирования
Вопрос: Сколько нужно тестировать?
Ответ: Чуть-чуть меньше, чем слишком

много.
Из фольклора тестировщиков

Какой объём тестирования достаточен?
Когда продукт готов к выпуску?

Аналогия для размышления:
Какой объём лечения достаточен?
Когда пациент готов к выписке?

Слайд 30Когда завершать тестирование
Тестирование следует продолжать до тех пор, пока затраты на

обнаружение и исправление дефектов НИЖЕ, чем будущие потери от сбоев продукта при его эксплуатации
Тим Комен, Мартин Пол, 1999

Слайд 31Risk-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

Слайд 32Различные классификации тестирования
исполняется или не исполняется программный код
статическое vs динамическое
подклассификация статических

методов
используется или нет знание о способе реализации
чёрный ящик vs прозрачный ящик
по «уровню»
unit, integration, subsystem, system, beta, acceptance
по свойствам объекта тестирования
функциональность, производительность, совместимость, надёжность, удобство, ...
по природе объекта тестирования/приложения
mainframe, client-server, ОO, Web , real-time, scientific, E-business…
по способу разработки тестов
методы тест-проектирования

Слайд 33Уровни тестирования
Автономное
отдельные модули
Интеграционное
стыковка модулей

«Подсистемное»
промежуточный выпуск
функциональный компонент
«инкремент»
Системное
Приемочное

база тестирования -- дизайн, внутренние интерфейсы
mainly

developers
white & black box
покрытие кода

компонентное

квалификационное

база тестирования -- внешние функции
mainly testers
black box
покрытие требований

Слайд 34Уровни тестирования















модуль
модуль
готовый модуль
компонент
подсистема
система
Автономное тестирование
Приемка готовых модулей
Интеграционное тестирование
Тестирование подсистем
Системное тестирование

Слайд 35Проводится разработчиками после того, как завершена разработка кода модулей/блоков.
Тестирование выполняется в

конце работ по созданию порученного модуля. Программист проводит тестирование, чтобы убедиться, что он завершил выполнение задания - критерий завершения удовлетворен. Комбинация методов прозрачного и черного ящиков.

Тестирование проводится, когда происходит интеграция нескольких модулей в более крупные компоненты. Происходит объединение модулей, а для временно отсутствующих элементов системы создаются заглушки. Для имитации окружения компонентов создаются тест-драйверы. Серый ящик.

Системное

Сопро-вождение

Уровень тестирования

Система интегрирована целиком. Проведено полное функциональное тестирование.
Группа разработки занята исправлением дефектов, обнаруженных в ходе тестирования.
Регрессионное тестирование.
Чёрный ящик

Заказчик проводит собственное тестирование, чтобы убедиться, что система удовлетворяет требованиям.
Обычно план приемо-сдаточных испытаний известен группе системного тестирования заранее. «Валидация».

Проводится ненавязчивое тестирование системы в ходе эксплуатации для измерения параметров качества, в том числе производительности, использования системных ресурсов, а также для определения корректирующих действий.

Система разбита на функциональные (или архитектурные) части или слои, которые тестируются по отдельности. Каждая из них «квалифицируется» в соответствии с объёмом функциональности, которую она реализует. Возможно использование тест-драйверов. Регрессионное тестирование. Чёрный ящик.

Характеристика уровней тестирования

Слайд 36Заглушки и тест-драйверы
Тест-драйвер подменяет ту часть системы (или внешней среды), которая

вызывает объект тестирования
обеспечивает передачу входных данных в объект тестирования
отображает результаты вызова или проверяет их правильность

Заглушка подменяет часть системы, вызываемую объектом тестирования
имеет тот же интерфейс (API), что и подменяемая часть
возвращает результат того же типа


драйвер


заглушка

Слайд 37Заглушки и тест-драйверы
Тест-драйверы и заглушки НЕ в полной мере имитируют поведение

недостающих компонентов
На разработку (и тестирование!) тех и других требуются дополнительные ресурсы, что может сделать их неоправданным

Слайд 38Типы тестирования по качествам продукта
Функциональное тестирование
соответствие (под)системы внешним спецификациям
Тестирование удобства использования
Тестирование

производительности (нагрузочное)
быстрота отклика системы под нагрузкой
Тестирование установки
правильность и удобство установки системы на целевые платформы
Конфигурационное тестирование
совместимость с различными типами оборудования и ПО (напр., принтерами, навигаторами)
работа в разной операционной среде/на разных платформах

Наиболее распространённые типы тестирования

Слайд 39Подпроект тестирования
Тестирование -- подпроект в рамках проекта разработки
имеет относительную самостоятельность (независимость

тестирования)
представляет собой отдельный проект, если выполняется независимой организацией
тест-менеджер -- менеджер подпроекта тестирования
группа тестирования под его управлением выполняет все работы по тестированию

Слайд 40Виды работ при тестировании
Планирование и управление
Спецификация/проектирование
Подготовка среды и средств тестирования
Выполнение тестов
Анализ

и отчетность
Рецензирование

Слайд 41Группа тестирования: роли и обязанности
Тест-менеджер
стратегия тестирования
планирование и управление
Тест-проектировщик
разработка тестовых сценариев и

тестов
проектирование тестовых данных
проектирование тест-драйверов
Тестировщик
подготовка тестовых данных
выполнение тестов
автоматизация тестирования (скрипты)
bug/trouble reports
Программист
разработка тест-драйверов, генераторов данных и др.

Слайд 42Функции тест-менеджера
На начальной фазе проекта
вырабатывает/анализирует/согласует с руководителем проекта критерии и процедуры

приёмки;
участвует в составлении плана-графика проекта в части, касающейся работ по тестированию
разрабатывает стратегию тестирования
определяет инструментарий тестирования и управления ошибками (Robot, CQ)
определяет необходимость разработки специального ПО для тестирования (e.g. test drivers)
В дальнейшем
организует работы по тестированию в соответствии со стратегией тестирования и планом-графиком проекта
еженедельно отчитывается перед руководителем проекта и начальником отдела

Слайд 43Функции тест-проектировщика
разрабатывает планы тестирования
сценарии тестирования
тесты
данные для тестирования
детализирует планы тестирования после
уточнения проектных

решений
получения ОТ
корректирует планы тестирования
в соответствии с изменениями требований и проектных решений
с учётом обнаруженных ошибок

Слайд 44Функции тестировщика
выполняет работы по тестированию, порученные ему тест-менеджером
проведение тестирования
автоматизация тестов
оформляет результаты

тестирования
протоколы тестирования
описания дефектов (Bug reports)

Слайд 45Продукция группы тестирования
Стратегия тестирования
План тестирования
Тестовые сценарии
Тестовые данные, драйверы, скрипты
Протоколы тестирования/отчеты о

дефектах
Отчётность о ходе тестирования: метрики, индикаторы
Итоговый отчет

Слайд 46Роли по уровням тестирования
Автономное тестирование модулей -- unit testing
программист -- разработчик

модуля
Интеграционное, «сборочное» тестирование -- integration testing
разработчики и в некоторых случаях тестировщики
Тестирование подсистем -- subsystem testing
тестировщики
Системное тестирование -- system testing
тестировщики
Приемочное тестирование -- acceptance testing
заказчик с участием МП и тестировщиков

Слайд 47Объекты тестирования
ПП в целом является объектом системного тестирования = «конечным» ОТ
проект

может предусматривать разработку и промежуточных объектов, подвергаемых тестированию
ОТ при итеративной разработке:
прототипы
функциональные подсистемы, получаемые наращиванием
Каждая итерация заканчивается созданием промежуточного продукта, который становится объектом тестирования

Слайд 48Тестирование в итеративном процессе разработки

Прошлая итерация
Следующая итерация
Текущая итерация
Критерии выпуска ОТ
Проекти- рование
Реализация
План итерации
План тестирования
Выполнение тестов
версия
версия
test results
test results
Оценка результатов тестирования
Требования к

системе, стратегия разработки

Критерии оценки ОТ


тест-раунд

Слайд 49Проведение тестирования
Во второй половине итерации
по готовности ОТ (завершена разработка)
Задание на

тестирование – «контракт» тест-менеджера с группой разработки
рамки, сроки, объект тестирования
критерии завершения ~ критерии качества ОТ
ресурсы и глубина тестирования
Выполнение контракта=цикл тестирования
Оценочное тестирование
вне цикла тестирования: «незрелый» ОТ

Слайд 50Тест-раунд -- тестирование определённой версии ОТ
версия ОТ (=Build)
передаётся из группы

разработки
отвергается, если не проходит приёмочное тестирование
приёмочное тестирование
реализуется сценарием плана тестирования
может автоматизироваться
включает проверку номера версии

объём тестирования в каждом тест-раунде
может варьироваться в зависимости от сроков, ресурсов, качества ОТ
минимум: проверка только что исправленных ошибок
типично: регрессионное тестирование (не всплывают ли ранее исправленные ошибки?)
максимум: полное тестирование в соответствии с ПТ

Похожие презентации

ЦДО ,,ЭВРИКА”РУССКИЕ КОСМОНАВТЫ 364
Суксунское Профессиональное училище №69 311
Нам дан во владение самый богатый, меткий, могучий и поистине волшебный русский язык К.Г.Паустовский 398
Эксплуатация скважин в осложненных условиях 1124
Технологический процесс изготовления сварной конструкции 512

Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика