тестирование программного обеспечения

Тестирование программного обеспечения

Введение в тестирование программного обеспечения

Тестирование ПО 204/13/23

Введение в тестирование ПО

Жизненный цикл разработки ПО Цели и задачи процесса тестирования Основные понятия. Полный цикл тестирования. Фазы

тестирования Роли участников группы тестирования Анализ требований к ПО с точки зрения пригодности

к тестированию Составление тестов на основе требований Оценка рисков требований, ранжирование тестов Изменение требований в процессе разработки


Жизненный цикл разработки ПО



Жизненный цикл проекта – ключевое понятие в разработке ПО

Жизненный цикл – соглашение, облегчающее планирование проекта и координацию усилий его участников

Различные стандарты по-разному определяют это понятие



Четыре обобщенные фазы жизненного цикла

1. концепция (инициация, идентификация, отбор)2. определение (анализ)3. выполнение (практическая реализация или

внедрение, производство и развертывание, проектирование или конструирование, сдача в эксплуатацию, инсталляция, тестирование и т.п.)

4. закрытие (завершение, включая оценивание после завершения)



Определения модели жизненного цикла программной системы в различных вариантах стандартов ГОСТ: Модель жизненного цикла – структура, состоящая из

процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999].

Жизненный цикл автоматизированной системы (АС) – совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990].


Уровни жизненного цикла ПО По Скотту Амблеру (Scott W. Ambler)

[Ambler, 2005], автору концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process): Жизненный цикл разработки

программного обеспечения – проектная деятельность по разработке и развертыванию программных систем

Жизненный цикл программной системы – включает разработку, развертывание, поддержку и сопровождение

Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента

Жизненный цикл организации/бизнеса – охватывает всю деятельность организации в целом


Модели жизненного цикла ПО Каскадная модель: переход на следующий этап означает полное завершение

работ на предыдущем этапе. Итеративная и инкрементальная – эволюционная (гибридная, смешанная,

поэтапная модель с промежуточным контролем): разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью, но время жизни каждого из этапов растягивается на весь период разработки.

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


Модели жизненного цикла ПОКаскадная (водопадная) модель


Модели жизненного цикла ПОКаскадная (водопадная) модель

«Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы»

(Ф. Брукс)

составление плана действий по разработке системы;

планирование работ, связанных с каждым действием;

отслеживание хода выполнения действий с контрольными этапами


Модели жизненного цикла ПОИтеративная и инкрементальная модель –

эволюционный подход


Модели жизненного цикла ПОИтеративная модель


Модели жизненного цикла ПО

Итеративная и инкрементальная модель – эволюционный подход

разбиение жизненного цикла проекта на последовательность итераций;

цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации


Модели жизненного цикла ПО

можно очень рано начать тестирование пользователями;

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

Эволюционная модель: не только сборка работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации.

“Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы.

Итеративная и инкрементальная модель – эволюционный подход


Модели жизненного цикла ПОСпиральная модель


Модели жизненного цикла ПОСпиральная модель

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

Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали.


Модели жизненного цикла ПОСпиральная модель: преимущества

Модель уделяет специальное внимание раннему анализу возможностей повторного использования

Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта

Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта.

Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта

Модель позволяет контролировать источники проектных работ и соответствующих затрат

Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего

Модель позволяет решать интегрированный задачи системной разработки, охватывающей и программную, и аппаратную составляющие создаваемого продукта.



Методологии разработки ПО Практика поэтапного создания продукта: стандарты ГОСТ

(Россия) и ISO (Европа, Россия), CMM (Capability Maturity Model — распространен в США), регламентирующие данный процесс

Rational Unified Process (RUP) Enterprise Unified Process (EUP) Microsoft Solutions Framework (MSF) версия 3 и версия 4 в

обоих представлениях: MSF for Agile и MSF for CMMI (анонсированная изначально как “MSF Formal”)

Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM,...)


Фазы разработки программного обеспечения

Осознание проблемы Идея

Исследование и постановка задачи

Анализ Выработка вариантов решения задачи

Выбор варианта решения Проектирование

Реализация решения

Программирование

Тестирование

Внедрение

Поддержка


Бизнес-моделированиеи системный анализ

Проектирование Пилотное внедрение Развертывание

Управление качеством на каждом из этапов жизненного цикла разработки ПО

• Требования к качеству ПО

• План тестирования• Сценарии тестирования

• Отчет(ы) о тестировании

• Метрики• Статистические отчеты

Определение заинтересованных лиц; Определение критериев качества

Нахождение решения, удовлетворяющего критериям

Проверка, удовлетворяет ли решение критериям качества

Анализ полученных результатов;Формирование базы знаний

Внутреннее тестированиеВнутреннее тестирование (участники проекта разработки ПО)

Проектирование, пилотное внедрение, развертывание

Внешнее тестирование Внешнее тестирование (пользователи продукта)

Пилотное внедрение, развертывание

1-20


Управление конфигурацией

Прослеживание и контроль сборок и версий программного продукта Версия программного продукта (результат в конце

итерации) Сборка программного продукта (регулярная

процедура)

Доступность «истории» продукта


Виды тестирования


Виды тестирования

Тестирование требований Функциональное тестирование Тестирование по нефункциональным

требованиям отказоустойчивость производительность переносимость


Виды тестирования Unit-тестирование (модульное тестирование) –

тестирование отдельных модулей приложения Функциональное тестирование – убедиться в

надлежащем функционировании объекта тестирования

Тестирование БД – проверка работоспособности БД при нормальной работе приложения, в моменты перегрузок и в многопользовательском режиме


Категории тестированияКатегории

тестирования Описание категории Виды тестирования

Текущее

тестирование Набор тестов, выполняемый для определения работоспособности добавленных новых возможностей системы.

нагрузочное тестирование; тестирование бизнес циклов;

Стресс-тестирование

Регрессионное

тестирование Проверка того, что добавления к системе не уменьшили ее возможностей, т.е. тестирование проводится согласно требованиям, которые уже были выполнены перед добавлением новых возможностей.

нагрузочное тестирование; тестирование бизнес циклов; Стресс-тестирование


Подкатегории тестированияПодкатегории тестирования

Описание вида тестирования

Подвиды тестирования

Нагрузочное

тестирование

Тестирования всех или выбранных функций приложения для определения поведения приложения под нагрузкой

unit-тестирование (модульное тестирование); функциональное тестирование; тестирование интерфейса; тестирование БД

Тестирование бизнес циклов

Тестирование функций приложения в последовательности их вызова пользователем. Например, имитация всех действия бухгалтера за 1 квартал.

функциональное тестирование; тестирование интерфейса; тестирование БД

Стрессовое

тестирование

Определить рамки стабильной работы приложения

функциональное тестирование; тестирование интерфейса; тестирование БД


Артефакты тестирования Сводная оценка результатов тестирования Двухуровневый план тестирования

Общий план тестирования План тестирования итерации (может быть связан с Планом

обеспечения качества) Список идей тестов Комплект тестов (Test suite) Тестовые сценарии

Пошаговые инструкции по выполнению теста Дефект Модель рабочей нагрузки Спецификация тестового интерфейса Архитектура автоматизации тестов


Цели и задачи процесса тестирования


Определение тестирования Тестирование программного обеспечения – это

процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов

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

Р.Калбертсон, К.Браун, Г.Кобб Быстрое тестирование, 2002

IEEE Std 829 – 1998 IEEE Standard for Software Test Documentation

1-29


Два вида тестирования

Статическое тестирование Анализ результатов разработки программного

обеспечения (артефактов) Артефакты могут включать любую документацию и код

Проверка программных кодов, контроль и проверка программы без запуска на машине

Динамическое тестирование Запуск программного продукта и запуск тестов

1-30


Цели и задачи процесса тестирования Определения

Ошибка Возникает в результате деятельности людей, связанной с разработкой

программного обеспечения Ошибка в требованиях, ошибка в дизайне, ошибка в коде

Дефект Несоответствие поведения программы требованиям или ожидаемому

поведению или несоответствие документации требованиям Отказ

Проявление дефекта в ходе эксплуатации программы Аварийный отказ – невозможность продолжать эксплуатацию

программы

Иногда термины «ошибка» (error, bug) и «дефект» используют взаимозаменяемо


Цели и задачи процесса тестирования

человек

совершает

ошибкуведущую к

дефекту

обнаруживаемого, возможно, другим

человеком

проявляемому в виде

отказа


Предотвращение и минимизация

До выпуска (релиза) Переработка Повторное проектирование Ремонт Стоимость анализа

После выпуска (релиза) Идентификация причин –

Рекламации Возвраты Поддержка Гарантийная работа

} Это влияет

на текущий график

} Это влияет

на будущие графики


Проблемы менеджмента качества в разработке ПО

Комплексность Большой объем артефактов, подлежащих контролю Большое число возможных состояний

Соответствие Базируется на абстрактной (математической) модели, не

на физических законах Влияние человеческого фактора

Изменчивость Последствия изменения неизвестны Непредсказуемость

Невидимость


Эффективность тестирования

Число ошибок, обнаруженных в ходе инспекции

Общее число ошибок в продукте до инспекции

Х 100%

Дефекты, обнаруженные тестированием или инспекцией

Дефекты, имеющиеся во время тестирования или инспекции

Х 100% =

Обнаруженные дефекты

Обнаруженные дефекты + необнаруженные дефекты

Х 100%=

(обнаруженные позже)

Джонс (1986)Джонс (1986)

Фаган (1976)Фаган (1976)


Эффективность тестирования

Число дефектов, обнаруженных до релиза

Число дефектов до релиза + после релиза

Число ошибок фазы

Число ошибок фазы + число дефектов фазы

TDCE =

PCEi =

TDCE – Total Defect Containment Effectiveness (общая эффективность

устранения дефектов)

PCEi – Phase Containment Effectiveness (эффективность устранения дефектов фазы)

МоторолаМоторола


Действия, приводящие к появлению и устранению дефектовФаза разработки Внесение дефекта Устранение

дефектаТребования Сбор требований и разработка

функциональных спецификацийАнализ и обзор требований

Высокоуровневый дизайн Работа по дизайну Инспекция высокоуровневого дизайна

Низкоуровневый дизайн Работа по дизайну Инспекция низкоуровневого дизайна

Кодирование Кодирование Инспекция кода

Интеграция/сборка Процесс интеграции и построения сборки

Тестирование построения сборки

Unit тестирование Плохое исправление дефектов Тестирование

Компонентное тестирование Плохое исправление дефектов Тестирование

Системное тестирование Плохое исправление дефектов Тестирование

1-37


Роли участников группы тестирования


Задачи тестировщика

Определение миссии тестирования Проверка подхода к тестированию Проверка стабильности выпуска (build) Тестирование и оценка Достижение приемлемого результата миссии Совершенствование методов и средств

тестирования


Участники процесса тестирования

Менеджер проекта – обеспечение ресурсами, координация работ

Разработчик, технический писатель – исправление найденных ошибок

Архитектор – обеспечение целостности проекта в процессе исправления ошибок

Интегратор – контроль и выпуск версий ПО Аналитик – установка приоритетов, связанных с

необходимостью и сложностью исправления найденных дефектов

Тестировщик – несет ответственность за процесс тестирования в целом


Роли участников группы тестирования Руководитель группы тестирования (Test manager) – представляет

ключевую роль тестировщика в рабочей группе, несет ответственность за организацию процесса тестирования в проекте, планирование и контроль действий по тестированию.

Тестировщик-аналитик (Test analyst) – несет ответственность за формирование тестовых спецификаций, и анализ итогов тестирования.

Разработчик тестов (Test developer) – несет ответственность за разработку автоматизированных тестов, предусмотренных в плане тестирования, установку и сопровождение инфраструктуры тестирования, создание стенда для проведения тестирования в соответствии с планом тестирования.

Исполнитель тестов (Test operator) - несет ответственность за фактическое исполнение тестов и документирование выявленных дефектов.


Особенности требований к ПО


Особенности требований к ПО

Каждое требование должно быть снабжено уникальным идентификатором

Требования должны быть представлены с точки зрения пользователя системы

Должны быть включены Функциональные и Нефункциональные требования

Документ определения требований должен находиться под управлением конфигурациями


Критерии при тестировании требований Полнота Непротиворечивость Осуществимость Проверяемость (возможность

тестирования) Однозначность Релевантность


Матрица отслеживаемости требований

ID требован

ия

ID функции

ID компонента в.у.

ID программн

ого компонент

а

ID unit теста

ID интеграционного

теста

ID системного теста

ID приемочного теста

RD2.2.4 RS2.2.4.1 D2.2.4.1 CC2.2.4.1 UT2.2.4.1 IT2.2.4 ST2.2.4 AT2.2.4


Доступность (отказоустойчивость) Частота недоступности системы в пределах временного интервала,

который используется для определения доступности Продолжительность недоступности системы Доступность по расписанию

5 х 8 (рабочие дни, рабочие часы) 7 х 24 (все дни недели, 24 часа) 365 х 24 (все дни года, 24 часа)

Доступность пять «9» или 99,999% - стремление индустрии Например, производители серверов Достигнутый результат – 99,998% для кластеров (10 минут

недоступности в течение года) ПК – 97,5% доступности в среднем (219 часов в год)


Надежность и доступность Операционная мера надежности – MTTF (Mean Time

To Failure – среднее время до отказа или наработка на отказ)

Измеряется в часах Частота отказов

Среднее время на устранение отказа – MTTR (Mean Time To Repair)

1

MTTF


Связь между плотностью дефектов и значениями MTTF

Дефектов на KLOC

MTTF

Больше 30 Меньше 2 минут

20-30 4-15 минут

10-20 5-60 минут

5-10 1-4 часа

2-5 4-24 часа

1-2 24-160 часов

Меньше 1 неопределенно


Производительность

Число операций в секунду MIPS – миллионы инструкций в секунду

Число транзакций в секунду TPC-App для серверов приложений и веб-сервисов TPC-C для операций многих пользователей с базой данных TPC-E – новый OLTP тест. Эмулирует брокерскую компанию с

клиентами, которые генерируют торговые транзакции. Компания взаимодействует с финансовыми рынками

TPC-H для поддержки принятия решений. Набор произвольных бизнес-запросов и параллельная модификация данных


Тестирование производительности При заданных параметрах системы

Число серверов Процессоры Память Дисковая подсистема Сеть

При заданном объеме базы данных Число записей того или иного сорта, например, число позиций на складе или

число счетов в банковской системе или число полисов в страховой системе

При меняющемся числе параллельно работающих пользователей Например, 1 – 10 – 100 – 1000 – 10000

Время отклика системы на воздействие Он-лайн запросы Пакетные запросы (отчеты)


Переносимость Операционные системы

Windows XP vs Windows Vista Windows vs Linux vs Unix (HP-UX, AIX, Solaris) AS/400, MVS, VAX

Сервера приложений Web Logic (BEA) vs Web Sphere (IBM) vs Tomcat vs IIS

Браузеры Microsoft IE 6 vs IE7 vs Mozilla vs Opera vs

Базы данных MS SQL vs Oracle vs DB2 + версии

Среда виртуальных машин VM Ware


Тестирование конфигураций (системные требования)

Процессор Память Диск Разрешение монитора Видеоплата Звуковая карта и т.п.

2-52


Изменение требований к ПО в процессе разработки


Управление требованиями


Анализ влияния изменений

Анализ влияния изменения включает оценку:технической осуществимостисоответствия бизнес целяммасштаба влиянияцены выполнения изменения последствий отклонения


Оценка затрат (пример 1)

Тип элемента Название элементов Трудоемкость

Формы FC_001, FC_013, FC_022 2

Отчеты RP_01, RP_07 1

Таблицы CLIENT, SUPPL 1

Тесты T002 0.1

Процедуры

Документы CRM-UG1-02 0.5

ИТОГО 4.6

Z013. Адрес Email. Увеличить размер адреса до 50 символов


Заказчик Разработчик

Маркетолог

Оценка изменений

Спецификациятребований

Запрос наизменение

Принятое изменение

Новая редакция

Управление изменениями


Цена изменения требований

Отн

осит

ельн

ая с

тоим

ость

ис

прав

лен

ия о

шиб

ок в

тре

бов

ания

х

20

40

60

80

100

Требования ИспользованиеПроект Кодирование Тестирование

Фазы разработки [Карл Видгерс]

Evgenia Vladimirskaya

Похоже, это "Количество выявляемых ошибок"? Или стоимость исправления ошибок?