Курс, который я читала в МГТУ им. Баумана

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

2. Тестирование ПО 207/18/14
Введение в тестирование ПО
 Жизненный цикл разработки ПО
 Цели и задачи процесса тестирования
 Основные понятия. Полный цикл тестирования. Фазы
тестирования
 Роли участников группы тестирования
 Анализ требований к ПО с точки зрения пригодности
к тестированию
 Составление тестов на основе требований
 Оценка рисков требований, ранжирование тестов
 Изменение требований в процессе разработки

3. Тестирование ПО 307/18/14
Жизненный цикл разработки ПО

4. Тестирование ПО 407/18/14
Жизненный цикл разработки ПО
 Жизненный цикл проекта – ключевое
понятие в разработке ПО
 Жизненный цикл – соглашение,
облегчающее планирование проекта и
координацию усилий его участников
 Различные стандарты по-разному
определяют это понятие

5. Тестирование ПО 507/18/14
Жизненный цикл разработки ПО
 Четыре обобщенные фазы жизненного
цикла
1. концепция (инициация, идентификация, отбор)
2. определение (анализ)
3. выполнение (практическая реализация или
внедрение, производство и развертывание,
проектирование или конструирование, сдача в
эксплуатацию, инсталляция, тестирование и т.п.)
4. закрытие (завершение, включая оценивание
после завершения)

6. Тестирование ПО 607/18/14
Жизненный цикл разработки ПО
 Определения модели жизненного цикла программной
системы в различных вариантах стандартов ГОСТ:
 Модель жизненного цикла – структура, состоящая из
процессов, работ и задач, включающих в себя разработку,
эксплуатацию и сопровождение программного продукта,
охватывающая жизнь системы от установления требований
к ней до прекращения ее использования [ГОСТ 12207, 1999].
 Жизненный цикл автоматизированной системы (АС) –
совокупность взаимосвязанных процессов создания и
последовательного изменения состояния АС, от
формирования исходных требований к ней до окончания
эксплуатации и утилизации комплекса средств
автоматизации АС [ГОСТ 34, 1990].

7. Тестирование ПО 707/18/14
Уровни жизненного цикла ПО
 По Скотту Амблеру (Scott W. Ambler) [Ambler,
2005], автору концепций и практик гибкого
моделирования (Agile Modeling) и Enterprise
Unified Process (расширение Rational Unified
Process):
 Жизненный цикл разработки
программного обеспечения – проектная
деятельность по разработке и
развертыванию программных систем
 Жизненный цикл программной системы
– включает разработку, развертывание,
поддержку и сопровождение
 Жизненный цикл информационных
технологий (ИТ) – включает всю
деятельность ИТ-департамента
 Жизненный цикл организации/бизнеса –
охватывает всю деятельность
организации в целом

8. Тестирование ПО 807/18/14
Модели жизненного цикла ПО
 Каскадная модель: переход на следующий этап означает полное завершение
работ на предыдущем этапе.
 Итеративная и инкрементальная – эволюционная (гибридная, смешанная,
поэтапная модель с промежуточным контролем): разработка ПО ведется
итерациями с циклами обратной связи между этапами. Межэтапные
корректировки позволяют уменьшить трудоемкость процесса разработки по
сравнению с каскадной моделью, но время жизни каждого из этапов
растягивается на весь период разработки.
 Спиральная модель: особое внимание уделяется начальным этапам
разработки: выработке стратегии, анализу и проектированию, где
реализуемость тех или иных технических решений проверяется и
обосновывается посредством создания прототипов (макетирования). Каждый
виток спирали предполагает создание некой версии продукта или какого-либо
его компонента; при этом уточняются характеристики и цели проекта,
определяется его качество и планируются работы следующего витка спирали.

9. Тестирование ПО 907/18/14
Модели жизненного цикла ПО
Каскадная (водопадная) модель

10. Тестирование ПО 1007/18/14
Модели жизненного цикла ПО
Каскадная (водопадная) модель
«Основное заблуждение каскадной
модели состоит в
предположениях, что проект
проходит через весь процесс
один раз, архитектура хороша и
проста в использовании, проект
осуществления разумен, а
ошибки в реализации
устраняются по мере
тестирования. Иными словами,
каскадная модель исходит из
того, что все ошибки будут
сосредоточены в реализации, а
потому их устранение происходит
равномерно во время
тестирования компонентов и
системы»
(Ф. Брукс)
 составление плана действий по
разработке системы;
 планирование работ, связанных
с каждым действием;
 отслеживание хода выполнения
действий с контрольными
этапами

11. Тестирование ПО 1107/18/14
Модели жизненного цикла ПО
Итеративная и инкрементальная модель –
эволюционный подход

12. Тестирование ПО 1207/18/14
Модели жизненного цикла ПО
Итеративная модель

13. Тестирование ПО 1307/18/14
Модели жизненного цикла ПО
Итеративная и инкрементальная модель –
эволюционный подход
 разбиение жизненного цикла проекта на
последовательность итераций;
 цель каждой итерации – получение работающей
версии программной системы, включающей
функциональность, определенную интегрированным
содержанием всех предыдущих и текущей итерации

14. Тестирование ПО 1407/18/14
Модели жизненного цикла ПО
 можно очень рано начать
тестирование
пользователями;
 можно принять стратегию
разработки в соответствии с
бюджетом, полностью
защищающую от
перерасхода времени или
средств (в частности, за счет
сокращения второстепенной
функциональности)
 Эволюционная модель: не только
сборка работающей (с точки зрения
результатов тестирования) версии
системы, но и её развертывание в
реальных операционных условиях с
анализом откликов пользователей для
определения содержания и
планирования следующей итерации.
 “Чистая” инкрементальная модель не
предполагает развертывания
промежуточных сборок (релизов)
системы и все итерации проводятся по
заранее определенному плану
наращивания функциональности, а
пользователи (заказчик) получает только
результат финальной итерации как
полную версию системы.
Итеративная и инкрементальная модель –
эволюционный подход

15. Тестирование ПО 1507/18/14
Модели жизненного цикла ПО
Спиральная модель

16. Тестирование ПО 1607/18/14
Модели жизненного цикла ПО
Спиральная модель
 На этапах анализа и проектирования создаются прототипы для
проверки реализуемости технических решений и степени
удовлетворения потребностей заказчика
 Каждый виток спирали соответствует созданию
работоспособного фрагмента или версии системы. Это
позволяет уточнить требования, цели и характеристики проекта,
определить качество разработки, спланировать работы
следующего витка спирали.

17. Тестирование ПО 1707/18/14
Модели жизненного цикла ПО
Спиральная модель: преимущества
 Модель уделяет специальное внимание раннему анализу возможностей
повторного использования
 Модель предполагает возможность эволюции жизненного цикла, развитие и
изменение программного продукта
 Модель предоставляет механизмы достижения необходимых параметров
качества как составную часть процесса разработки программного продукта.
 Модель уделяет специальное внимание предотвращению ошибок и
отбрасыванию ненужных, необоснованных или неудовлетворительных
альтернатив на ранних этапах проекта
 Модель позволяет контролировать источники проектных работ и
соответствующих затрат
 Модель не проводит различий между разработкой нового продукта и
расширением (или сопровождением) существующего
 Модель позволяет решать интегрированный задачи системной разработки,
охватывающей и программную, и аппаратную составляющие создаваемого
продукта.

18. Тестирование ПО 1807/18/14
Жизненный цикл разработки ПО
 Методологии разработки ПО
 Практика поэтапного создания продукта: стандарты ГОСТ
(Россия) и 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,...)

19. Тестирование ПО 1907/18/14
Фазы разработки
программного обеспечения
Осознание проблемы  Идея
Исследование и постановка задачи
 Анализ
Выработка вариантов решения задачи
Выбор варианта решения  Проектирование
Реализация решения
 Программирование
 Тестирование
 Внедрение
 Поддержка

20. Тестирование ПО 2007/18/14
Бизнес-моделирование
и системный анализ
Проектирование Пилотное внедрение Развертывание
Управление качеством на каждом из этапов
жизненного цикла разработки ПО
• Требования к
качеству ПО
• План
тестирования
• Сценарии
тестирования
• Отчет(ы) о
тестировании
• Метрики
•
Статистические
отчеты
Определение
заинтересованных
лиц;
Определение
критериев качества
Нахождение
решения,
удовлетворяющего
критериям
Проверка,
удовлетворяет ли
решение критериям
качества
Анализ полученных
результатов;
Формирование
базы знаний
 Внутреннее тестированиеВнутреннее тестирование
(участники проекта разработки
ПО)
Проектирование, пилотное
внедрение, развертывание
 Внешнее тестированиеВнешнее тестирование
(пользователи продукта)
Пилотное внедрение,
развертывание
1-20

21. Тестирование ПО 2107/18/14
Управление конфигурацией
 Прослеживание и контроль сборок и
версий программного продукта
 Версия программного продукта (результат в конце
итерации)
 Сборка программного продукта (регулярная
процедура)
 Доступность «истории» продукта

22. Тестирование ПО 2207/18/14
Виды тестирования

23. Тестирование ПО 2307/18/14
Виды тестирования
 Тестирование требований
 Функциональное тестирование
 Тестирование по нефункциональным
требованиям
 отказоустойчивость
 производительность
 переносимость

24. Тестирование ПО 2407/18/14
Виды тестирования
 Unit-тестирование (модульное тестирование)
– тестирование отдельных модулей
приложения
 Функциональное тестирование – убедиться
в надлежащем функционировании объекта
тестирования
 Тестирование БД – проверка
работоспособности БД при нормальной работе
приложения, в моменты перегрузок и в
многопользовательском режиме

25. Тестирование ПО 2507/18/14
Категории тестирования
Категории
тестирования
Описание категории Виды тестирования
Текущее
тестирование
Набор тестов, выполняемый
для определения
работоспособности
добавленных новых
возможностей системы.
нагрузочное тестирование;
тестирование бизнес циклов;
Стресс-тестирование
Регрессионное
тестирование
Проверка того, что добавления
к системе не уменьшили ее
возможностей, т.е.
тестирование проводится
согласно требованиям,
которые уже были выполнены
перед добавлением новых
возможностей.
нагрузочное тестирование;
тестирование бизнес циклов;
Стресс-тестирование

26. Тестирование ПО 2607/18/14
Подкатегории тестирования
Подкатегории
тестирования
Описание вида
тестирования
Подвиды
тестирования
Нагрузочное
тестирование
Тестирования всех или выбранных
функций приложения для определения
поведения приложения под нагрузкой
unit-тестирование (модульное
тестирование);
функциональное
тестирование;
тестирование интерфейса;
тестирование БД
Тестирование
бизнес циклов
Тестирование функций приложения в
последовательности их вызова
пользователем. Например, имитация
всех действия бухгалтера за 1
квартал.
функциональное
тестирование;
тестирование интерфейса;
тестирование БД
Стрессовое
тестирование
Определить рамки стабильной работы
приложения
функциональное
тестирование;
тестирование интерфейса;
тестирование БД

27. Тестирование ПО 2707/18/14
Артефакты тестирования
 Сводная оценка результатов тестирования
 Двухуровневый план тестирования
 Общий план тестирования
 План тестирования итерации (может быть связан с Планом
обеспечения качества)
 Список идей тестов
 Комплект тестов (Test suite)
 Тестовые сценарии
 Пошаговые инструкции по выполнению теста
 Дефект
 Модель рабочей нагрузки
 Спецификация тестового интерфейса
 Архитектура автоматизации тестов

28. Тестирование ПО 2807/18/14
Цели и задачи процесса
тестирования

29. Тестирование ПО 2907/18/14
Определение тестирования
 Тестирование программного обеспечения – это
процесс анализа или эксплуатации программного
обеспечения с целью выявления дефектов
 Процесс анализа программы для определения
расхождений между существующими и требуемыми
условиями (то есть для нахождения ошибок) и для
оценки свойств (характеристик) программы.
Р.Калбертсон, К.Браун, Г.Кобб Быстрое тестирование,
2002
IEEE Std 829 – 1998 IEEE Standard for Software Test
Documentation
1-29

30. Тестирование ПО 3007/18/14
Два вида тестирования
 Статическое тестирование
 Анализ результатов разработки программного
обеспечения (артефактов)
 Артефакты могут включать любую документацию и код
 Проверка программных кодов, контроль и
проверка программы без запуска на машине
 Динамическое тестирование
 Запуск программного продукта и запуск тестов
1-30

31. Тестирование ПО 3107/18/14
Цели и задачи процесса
тестирования
 Определения
 Ошибка
 Возникает в результате деятельности людей, связанной с разработкой
программного обеспечения
 Ошибка в требованиях, ошибка в дизайне, ошибка в коде
 Дефект
 Несоответствие поведения программы требованиям или ожидаемому
поведению или несоответствие документации требованиям
 Отказ
 Проявление дефекта в ходе эксплуатации программы
 Аварийный отказ – невозможность продолжать эксплуатацию
программы
 Иногда термины «ошибка» (error, bug) и «дефект» используют
взаимозаменяемо

32. Тестирование ПО 3207/18/14
Цели и задачи процесса
тестирования
человек
совершает
ошибку
ведущую к
дефекту
обнаруживаемого,
возможно, другим
человеком
проявляемому
в виде
отказа

33. Тестирование ПО 3307/18/14
Предотвращение и
минимизация
 До выпуска (релиза)
 Переработка
 Повторное проектирование
 Ремонт
 Стоимость анализа
 После выпуска (релиза)
 Идентификация причин –
Рекламации
 Возвраты
 Поддержка
 Гарантийная работа
} Это влияет на
текущий график
} Это влияет на
будущие
графики

34. Тестирование ПО 3407/18/14
Проблемы менеджмента
качества в разработке ПО
 Комплексность
 Большой объем артефактов, подлежащих контролю
 Большое число возможных состояний
 Соответствие
 Базируется на абстрактной (математической) модели, не
на физических законах
 Влияние человеческого фактора
 Изменчивость
 Последствия изменения неизвестны
 Непредсказуемость
 Невидимость

35. Тестирование ПО 3507/18/14
Эффективность тестирования
Число ошибок, обнаруженных в ходе
инспекции
Общее число ошибок в продукте до инспекции
Х 100%
Дефекты, обнаруженные тестированием или
инспекцией
Дефекты, имеющиеся во время тестирования или
инспекции
Х 100% =
Обнаруженные дефекты
Обнаруженные дефекты + необнаруженные
дефекты
Х 100%=
(обнаруженные позже)
Джонс (1986)Джонс (1986)
Фаган (1976)Фаган (1976)

36. Тестирование ПО 3607/18/14
Эффективность тестирования
Число дефектов, обнаруженных до релиза
Число дефектов до релиза + после релиза
Число ошибок фазы
Число ошибок фазы + число дефектов фазы
TDCE =
PCEi =
TDCE – Total Defect Containment
Effectiveness (общая эффективность
устранения дефектов)
PCEi – Phase Containment Effectiveness
(эффективность устранения дефектов фазы)
МоторолаМоторола

37. Тестирование ПО 3707/18/14
Действия, приводящие к
появлению и устранению дефектов
Фаза разработки Внесение дефекта Устранение
дефекта
Требования Сбор требований и разработка
функциональных спецификаций
Анализ и обзор требований
Высокоуровневый дизайн Работа по дизайну Инспекция высокоуровневого
дизайна
Низкоуровневый дизайн Работа по дизайну Инспекция низкоуровневого
дизайна
Кодирование Кодирование Инспекция кода
Интеграция/сборка Процесс интеграции и
построения сборки
Тестирование построения
сборки
Unit тестирование Плохое исправление дефектов Тестирование
Компонентное тестирование Плохое исправление дефектов Тестирование
Системное тестирование Плохое исправление дефектов Тестирование
1-37

38. Тестирование ПО 3807/18/14
Роли участников группы
тестирования

39. Тестирование ПО 3907/18/14
Задачи тестировщика
 Определение миссии тестирования
 Проверка подхода к тестированию
 Проверка стабильности выпуска (build)
 Тестирование и оценка
 Достижение приемлемого результата
миссии
 Совершенствование методов и средств
тестирования

40. Тестирование ПО 4007/18/14
Участники процесса тестирования
 Менеджер проекта – обеспечение ресурсами, координация
работ
 Разработчик, технический писатель – исправление найденных
ошибок
 Архитектор – обеспечение целостности проекта в процессе
исправления ошибок
 Интегратор – контроль и выпуск версий ПО
 Аналитик – установка приоритетов, связанных с
необходимостью и сложностью исправления найденных
дефектов
 Тестировщик – несет ответственность за процесс тестирования
в целом

41. Тестирование ПО 4107/18/14
Роли участников группы
тестирования
 Руководитель группы тестирования (Test manager) – представляет
ключевую роль тестировщика в рабочей группе, несет ответственность
за организацию процесса тестирования в проекте, планирование и
контроль действий по тестированию.
 Тестировщик-аналитик (Test analyst) – несет ответственность за
формирование тестовых спецификаций, и анализ итогов тестирования.
 Разработчик тестов (Test developer) – несет ответственность за
разработку автоматизированных тестов, предусмотренных в плане
тестирования, установку и сопровождение инфраструктуры
тестирования, создание стенда для проведения тестирования в
соответствии с планом тестирования.
 Исполнитель тестов (Test operator) - несет ответственность за
фактическое исполнение тестов и документирование выявленных
дефектов.

42. Тестирование ПО 4207/18/14
Особенности требований к ПО

43. Тестирование ПО 4307/18/14
Особенности требований к ПО
 Каждое требование должно быть снабжено
уникальным идентификатором
 Требования должны быть представлены с
точки зрения пользователя системы
 Должны быть включены
 Функциональные и
 Нефункциональные требования
 Документ определения требований должен
находиться под управлением
конфигурациями

44. Тестирование ПО 4407/18/14
Критерии при тестировании
требований
 Полнота
 Непротиворечивость
 Осуществимость
 Проверяемость (возможность
тестирования)
 Однозначность
 Релевантность

45. Тестирование ПО 4507/18/14
Матрица отслеживаемости требований
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

46. Тестирование ПО 4607/18/14
Доступность
(отказоустойчивость)
 Частота недоступности системы в пределах временного
интервала, который используется для определения доступности
 Продолжительность недоступности системы
 Доступность по расписанию
 5 х 8 (рабочие дни, рабочие часы)
 7 х 24 (все дни недели, 24 часа)
 365 х 24 (все дни года, 24 часа)
 Доступность пять «9» или 99,999% - стремление индустрии
 Например, производители серверов
 Достигнутый результат – 99,998% для кластеров (10 минут
недоступности в течение года)
 ПК – 97,5% доступности в среднем (219 часов в год)

47. Тестирование ПО 4707/18/14
Надежность и доступность
 Операционная мера надежности – MTTF (Mean Time
To Failure – среднее время до отказа или наработка
на отказ)
 Измеряется в часах
 Частота отказов
 Среднее время на устранение отказа – MTTR (Mean
Time To Repair)
1
MTTF

48. Тестирование ПО 4807/18/14
Связь между плотностью
дефектов и значениями 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 неопределенно

49. Тестирование ПО 4907/18/14
Производительность
 Число операций в секунду
 MIPS – миллионы инструкций в секунду
 Число транзакций в секунду
 TPC-App для серверов приложений и веб-сервисов
 TPC-C для операций многих пользователей с базой данных
 TPC-E – новый OLTP тест. Эмулирует брокерскую компанию с
клиентами, которые генерируют торговые транзакции. Компания
взаимодействует с финансовыми рынками
 TPC-H для поддержки принятия решений. Набор произвольных
бизнес-запросов и параллельная модификация данных

50. Тестирование ПО 5007/18/14
Тестирование производительности
 При заданных параметрах системы
 Число серверов
 Процессоры
 Память
 Дисковая подсистема
 Сеть
 При заданном объеме базы данных
 Число записей того или иного сорта, например, число позиций на складе или
число счетов в банковской системе или число полисов в страховой системе
 При меняющемся числе параллельно работающих пользователей
 Например, 1 – 10 – 100 – 1000 – 10000
 Время отклика системы на воздействие
 Он-лайн запросы
 Пакетные запросы (отчеты)

51. Тестирование ПО 5107/18/14
Переносимость
 Операционные системы
 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

52. Тестирование ПО 5207/18/14
Тестирование конфигураций
(системные требования)
 Процессор
 Память
 Диск
 Разрешение монитора
 Видеоплата
 Звуковая карта
 и т.п.
2-52

53. Тестирование ПО 5307/18/14
Изменение требований к ПО в
процессе разработки

54. Тестирование ПО 5407/18/14
Управление требованиями

55. Тестирование ПО 5507/18/14
Анализ влияния изменений
Анализ влияния изменения включает
оценку:
технической осуществимости
соответствия бизнес целям
масштаба влияния
цены выполнения изменения
последствий отклонения

56. Тестирование ПО 5607/18/14
Оценка затрат (пример 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 символов

57. Тестирование ПО 5707/18/14
Заказчик Разработчик
Маркетолог
Оценка изменений
Спецификация
требований
Запрос на
изменение
Принятое изменение
Новая редакция
Управление изменениями

58. Тестирование ПО 5807/18/14
Цена изменения требований
Относительнаястоимость
исправленияошибоквтребованиях
20
40
60
80
100
Требования ИспользованиеПроект Кодирование Тестирование
Фазы разработки [Карл Видгерс]