Тестирование программных средств Сафронов Сергей, 2008 год

реклама
Тестирование
программных средств
Сафронов Сергей,
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
Мы знаем, какие проблемы могут быть в проекте и
постараемся предотвратить их до того, как они
проявятся
Скачать