'

Test Process Framework

Понравилась презентация – покажи это...





Слайд 0

Test Process Framework


Слайд 1

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


Слайд 2

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


Слайд 3

Верификация Чтобы понять, что нечто наступило, нужно уметь его померить Энди Грув, корпорация Интел Верификация («правильно ли мы делаем?») в. продукта: критерии готовности (readiness criteria) в. деятельности: критерии завершения (exit criteria) Здесь мы что-то делаем Здесь мы проверяем, сделали или нет


Слайд 4

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


Слайд 5

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


Слайд 6

Разработка Статические и динамические методы Требования Реализация 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


Слайд 7

Цель тестирования Общепринятое определение: Цель тестирования – снизить неопределённость нашего представления о качестве программного продукта Другими словами, обнаружить ошибки до того, как это сделает Заказчик


Слайд 8

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


Слайд 9

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


Слайд 10

Анатомия тестирования цикл тестирования develop product test better product fix test раунд тестирования исправлений Failure -- расхождение с ожидаемым результатом, отказ Fix/debug -- поиск изъянов в продукте (причин отказа) и их исправление fix No failures!


Слайд 11

Вариации доработок Func design Design Build Build changed product Design Build changed product Design Func design Fix1: Fix2: Fix3: Requirements Fix1 -- изъян в коде программы; переделывается только код Fix2 -- изъян в спецификациях (технический дизайн); меняются и спецификации, и код Fix3 -- изъян в архитектуре/функциональном дизайне; меняются архитектура, спецификации и код


Слайд 12

Тестирование в V-модели Requirements Design Construction Testing Development Unit tests Integration tests Acceptance test Architecture System test


Слайд 13

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


Слайд 14

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


Слайд 15

Тест-проектирование в 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


Слайд 16

Фазы проекта* и состав работ по тестированию 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) модель разработки


Слайд 17

Rational Unified Process Инженерная (исследовательская) завершается, когда есть ясное понимание, КАК делать продукт (архитектура) Производственная состоит главным образом в изготовлении продукта Рубеж между стадиями - главный рубеж проекта соотношение сроков и ресурсов между стадиями определяется спецификой проекта Две основные стадии ЖЦ Чёткая граница и оптимальный баланс между двумя стадиями характерны для большинства успешных проектов


Слайд 18

Rational Unified Process время Концепт. проработка Эскизная проработка Реализация Внедрение Главные рубежи Инженерная стадия Производственная стадия Концепт. проработка Эскизная проработка Реализация Внедрение Основной результат каждой фазы Inception: концепция = ясно, ЧТО нужно сделать Elaboration: архитектура = ясно, КАК сделать Construction: полноценный продукт разработки («бета») Transition: отшлифованный продукт у Заказчика Четыре фазы, ортогональные циклу разработки


Слайд 19

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


Слайд 20

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


Слайд 21

Rational Unified Process (RUP) Планирование тестирования Установка инструментов тестирования Подробный план-график Стратегия тестирования Набросок тест-плана Подготовка тестовой среды Просмотр требований Приемо-сдаточные испытания Анализ дефектов, обнаруженных в ходе приемо-сдаточных испытаний Уточнение плана регрессионного тестирования Проектирование тестов Подготовка тестовых данных Автоматизация тестирования Анализ CR и PR Проведение тестирования Отслеживание дефектов Transition Construction Inception Elaboration Фаза Основные инженерные процессы Внедрение Тестирование Реализация Проектирование Требования


Слайд 22

Iterations achieve demonstrable results Proof-of-concept prototype Architectural prototype Alpha release (all critical use cases) Beta release Final product Inception Elaboration Construction Transition


Слайд 23

Итерация -- каскадный «подпроект» Запланированный «слой» функциональности Результаты с предыдущей итерации Результаты для следующей итерации Основные инженерные процессы Управление требованиями Проектирование Реализация Тестирование Внедрение


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

Цена качества по Juran на предупреждение и выявление на исправление, плюс потери от оставшихся дефектов минимум затрат Суммарные затраты на качество Некачественный продукт: высокие потери от рекламаций Безупречный продукт: высокие затраты на тестирование


Слайд 28

Основной вопрос тестирования Вопрос: Сколько нужно тестировать? Ответ: Чуть-чуть меньше, чем слишком много. Из фольклора тестировщиков Какой объём тестирования достаточен? Когда продукт готов к выпуску? Аналогия для размышления: Какой объём лечения достаточен? Когда пациент готов к выписке?


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

Уровни тестирования Автономное отдельные модули Интеграционное стыковка модулей «Подсистемное» промежуточный выпуск функциональный компонент «инкремент» Системное Приемочное база тестирования -- дизайн, внутренние интерфейсы mainly developers white & black box покрытие кода компонентное квалификационное база тестирования -- внешние функции mainly testers black box покрытие требований


Слайд 33

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


Слайд 34

Проводится разработчиками после того, как завершена разработка кода модулей/блоков. Тестирование выполняется в конце работ по созданию порученного модуля. Программист проводит тестирование, чтобы убедиться, что он завершил выполнение задания - критерий завершения удовлетворен. Комбинация методов прозрачного и черного ящиков. Тестирование проводится, когда происходит интеграция нескольких модулей в более крупные компоненты. Происходит объединение модулей, а для временно отсутствующих элементов системы создаются заглушки. Для имитации окружения компонентов создаются тест-драйверы. Серый ящик. Системное Сопро-вождение Уровень тестирования Система интегрирована целиком. Проведено полное функциональное тестирование. Группа разработки занята исправлением дефектов, обнаруженных в ходе тестирования. Регрессионное тестирование. Чёрный ящик Заказчик проводит собственное тестирование, чтобы убедиться, что система удовлетворяет требованиям. Обычно план приемо-сдаточных испытаний известен группе системного тестирования заранее. «Валидация». Проводится ненавязчивое тестирование системы в ходе эксплуатации для измерения параметров качества, в том числе производительности, использования системных ресурсов, а также для определения корректирующих действий. Система разбита на функциональные (или архитектурные) части или слои, которые тестируются по отдельности. Каждая из них «квалифицируется» в соответствии с объёмом функциональности, которую она реализует. Возможно использование тест-драйверов. Регрессионное тестирование. Чёрный ящик. Характеристика уровней тестирования


Слайд 35

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


Слайд 36

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


Слайд 37

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


Слайд 38

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


Слайд 39

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


Слайд 40

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


Слайд 41

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


Слайд 42

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


Слайд 43

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


Слайд 44

Продукция группы тестирования Стратегия тестирования План тестирования Тестовые сценарии Тестовые данные, драйверы, скрипты Протоколы тестирования/отчеты о дефектах Отчётность о ходе тестирования: метрики, индикаторы Итоговый отчет


Слайд 45

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


Слайд 46

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


Слайд 47

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


Слайд 48

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


Слайд 49

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


×

HTML:





Ссылка: