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