Test Process Framework

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

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

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

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

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

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

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

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

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 test failures? better product fix test failures? product раунд тестирования исправлений Failure -- расхождение с ожидаемым результатом, отказ Fix/debug -- поиск изъянов в продукте (причин отказа) и их исправление fix No failures!

Вариации доработок Func design Design Build changed product Design Build changed product failed product Design cause of failure Func design Fix 1 : Fix 2 : Fix 3 : changed product Requirements cause of failure Fix 1 -- изъян в коде программы; переделывается только код Fix 2 -- изъян в спецификациях (технический дизайн); меняются и спецификации, и код Fix 3 -- изъян в архитектуре/функциональном дизайне; меняются архитектура, спецификации и код

Тестирование в V-модели Requirements Design Construction Testing Development Unit tests Integration tests Acceptance test ArchitectureSystem test fix 1 fix 2 fix 4 fix 3

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

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

Тест-проектирование в V-модели Requirements Design Construction Test execution Development Unit tests Integration tests Acceptance test ArchitectureSystem test Acceptance test design System test design Integration test design Unit test design Test design

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

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

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

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

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

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

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

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

Выполнение тестов Анатомия типичной итерации в середине ЖЦ Прошлая итерация Следующая итерация Текущая итерация Проекти- рование Реализация План итерации План тестирования версия 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 динамическое – подклассификация статических методов используется или нет знание о способе реализации – чёрный ящик vs прозрачный ящик по «уровню» – unit, integration, subsystem, system, beta, acceptance по свойствам объекта тестирования – функциональность, производительность, совместимость, надёжность, удобство,... по природе объекта тестирования/приложения – 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 Оценка результатов тестирования Требования к системе, стратегия разработки Критерии оценки ОТ тест- раунд

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

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