Тестирование программных средств Сафронов Сергей, 2008 год
advertisement
Тестирование программных средств Сафронов Сергей, 2008 год Оглавление Модель СММ • История возникновения • Краткая характеристика Модель ТММ • Краткая характеристика Основные этапы СММ/ТММ Другие модели оценки зрелости тестирования История возникновения СММ CMM – Capability Maturity Model Разработан в 1987 году Институтом программной инженерии (SEI) совместно с корпорацией Mitre Предназначен для организации эффективного процесса управления разработкой ПО СММ определяет ЧТО надо сделать, но не определяет КАК Краткая характеристика этапов 1 Initial Начальный Chaotic, ad hoc, heroic (хаотичный, специфический, героический) 2 Repeatable Повторяемость Project management, process discipline (есть управление проектом и дисциплина проекта) 3 Defined Определенность Institutionalized (учрежденный) 4 Managed Управляемость Quantified (дискретный) 5 Optimizing Оптимизация Process improvement (постоянное улучшение процесса) Проблемные места СММ Отсутствие формальной теоретической базы Отсутствие/неясность эмпирических примеров (уровни 1, 4 и 5) СММ чтит процесс, но игнорирует людей Смещение акцента с улучшения процесса на переход на более высокий уровень зрелости Отсутствие инноваций (только 5 уровень, а таких организаций менее 10 в мире): требуется быть предсказуемым, тогда как успех часто связан именно с гибкостью (Agile) Самый яркий аргумент против: Существует много процветающих организаций, которых по СММ вообще не должно существовать TMM TMM – Testing Maturity Model ТММ была разработана как дополнение к модели СММ Организация, пытающаяся достигнуть некого уровня ТММ, должна обладать как минимум таким же уровнем СММ Хорошая программа тестирования не существует в вакууме – она является составной частью процесса разработки ПО Этап первый: начальный СММ: • • • • Процесс разработки не организован Нет никаких попыток улучшения Все зависит от исполнителей «Black box» project (На входе отдел программистов, на выходе – продукт) • Не получается укладываться в сроки и бюджет ТММ • • • • Хаотическое тестирование разработчиками Тестирование и отладка не различиются Цель – показать, что ПО работает Отдел тестирования отсутствует Этап второй: повторяемость СММ: • Начинается создание внутренних стандартов разработки ПО • Начинает внедряться планирование • Налаживается обратная связь с заказчиком • Процесс стандартизован только для конкретных областей • Проект разбивается на небольшие части и становится более понятен • Создаются информационные и функциональные модели • Проблемы решаются по мере возникновения Этап второй: повторяемость СММ: • Тестирование отделено от отладки • Тестирование – выполнение тестов, зависит от кода -> после кодирования • Цель тестирования– показать, что программа соответствует спецификации • Часть ошибок ловятся очень поздно, ибо тестирование не покрывает фаз анализа требований и проектирования Цели: • Определены задачи разработки и тестирования • Инициировать процесс планирования тестирования • Зафиксировать и описать базовые процедуры и методики Этап третий: определенность СММ: • Уровень мирового класса • Детальная стандартизация разработки ПО с учетом дальнейшего развития • Все процессы интегрированы в общий процесс разработки • Процесс улучшается каждый раз по завершению проекта • Отдельные личности перестают влиять на результат • Четкое определение функциональных обязанностей сотрудников • Возможность получить информацию о текущем состоянии проекта • Снижаются затраты и сроки реализации • Возможно оценить риски Этап третий: определенность ТММ: • Тестирование интегрировано во все фазы разработки ПО • Цели устанавливаются с учетом требований клиентов • Тестировани выделено в профессиональную деятельность • Определена организация процесса тестирования Цели: • Выделить тестирование в отдельную группу • Определить программу технического обучения для тестировщиков • Интегрировать процесс тестирования в процесс разработки • Контроль процесса тестирования Этап четвертый: управляемость СММ: • • • • • Все процессы унифицировны Выработаны критерии оценки результатов Полная документация по процессам Процесс легко управляем Основной упор – эффективное управление, за счет чего повышается качество и снижаются требования к ресурсам • Проблемы оказывают минимальное воздействие на проект • ПО разрабатывается в заданный срок с заданным качеством • Менеджеры не только понимают процессы, но управляют ими Этап четвертый: управляемость ТММ: • Тестирование – измеряемый и контролируемый процесс • Проверки на всех фазах жизненного цикла признаны работами по тестированию и контролю качества • Проект проверяется на такие атрибуты качества, как надежность, удобство использования и легкость поддержки • Существует централизованная база данных тестов для повторного и регрессионного тестирования • Классификация всех найденных дефектов Цели: • Внедрение процесса инспектирования на всех уровнях • Внедрить оценку качества ПО Уровень пятый: оптимизация СММ: • Непрерывная и неограниченная оптимизация • Определены четкие области применения для всех процессов, их сильные и слабые стороны • Улучшение поддается количественной оценке Уровень пятый: оптимизация ТММ: • Стоимость тестирования и его эффективность четко определены • Применяются на практике методы предотвращения возникновения ошибок и контроля качества • Постоянное повышение качества и гибкости тестирования • Автоматизированное тестирование – основной подход • Существует и постоянно улучается набор инструментов для всех основных процессов: разработка тестов, анализ результатов, разбор ошибок, сбор метрик качества, etc Цели: • Оптимизация процесса тестирования • Предотвращение ошибок • Контроль качества Другие модели зрелости ABCD-model: • D - Denial Зачем нам тестирование, мы лучше больше кода напишем! • C – Capable Ну, да – бывают проблемы, но их мы по ходу дела решать будем! • B – Break it Больше тестирования и больше просмотров – больше выявленных проблем! • A – Actualized Мы знаем, какие проблемы могут быть в проекте и постараемся предотвратить их до того, как они проявятся
