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

1.

Тестирование как часть процесса
верификации программного обеспечения.
Основные понятия

2.

Основные понятия

3.

Основные понятия

4.

Основные понятия

5.

Основные понятия
- Отладка(debugging) направлена на
установление точной природы известной
ошибки, а затем - на исправление этой
ошибки;
- результаты тестирования являются исходными
данными для отладки.
Отладка = Тестирование + Поиск ошибок + Редактирование

6.

Две задачи тестирования
Первая задача тестирования – подготовить набор тестов и
применить к ним ПС, чтобы обнаружить в нём по возможности
большее число ошибок.
Вторая задача тестирования - определить момент окончания
отладки ПС (или отдельной его компоненты).
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

7.

Виды отладок. Виды ошибок

8.

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

9.

Виды ошибок.
Ошибки анализа.
Связаны либо с неполным учетом ситуации (например,
пренебрежение возможностью появления отрицательных
значений переменных, малых и больших величин), либо с
неверным решением задачи, из которых можно назвать:
1. Отсутствие заданий начальных значений переменных.
2. Неверные условия окончания цикла.
3. Неверную индексацию цикла.
4. Отсутствие задания условий инициирования цикла.
5. Неправильное указание ветви алгоритма для
продолжения процесса решения задачи.

10.

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

11.

Ошибки физического характера.
Можно назвать несколько типов ошибок, вызываемых
неверными действиями программиста:
1. Пропуск некоторых операторов.
2. Отсутствие необходимых данных.
3. Непредусмотренные данные.
4. Неверный формат данных.

12.

Обнаружение ошибок.
Ситуации, по которым мы определяем, что в программе
есть ошибка:
1. Отсутствует уверенность в том, что программа начала
выполняться.
2. Программа начала выполняться, но произошел
преждевременный останов с выдачей или без выдачи
сообщений о системной ошибке.
3. Программа начала выполняться, но зациклилась.
4. Программа выдала неправильную информацию.
Любая из этих ситуаций требует от программиста
проверки последовательности выполнения команд.

13.

Как искать ошибку
1 Поймите задачу
В графе «Что»
описываются основные
симптомы, в графе «Где»
описываются точки, где
замечены симптомы, в графе
«Когда»-возможные догадки,
когда симптомы проявляются, а
когда нет, в графе «Уточнения»
указывается область действия
симптомов.
Столбцы «Да» «Нет»
описывают отличия и
противоречия, что позволит
создать гипотезу

14.

Как искать ошибку
2 Разработайте план. Построить одну или несколько гипотез об
ошибке и разработать план проверки этих гипотез.
3 Выполните план, стараясь доказать гипотезу
4 Проверьте решение. Выполните еще несколько проверок,
прежде чем исправить ошибку. Проанализируйте, может ли
предполагаемая ошибка давать в точности известные симптомы

15.

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

16. Как исправлять ошибки

17.

Методы отладки
Методы отладки можно разделить на
методы "грубой силы" и методы,
основанные на обдумывании.

18. Метод грубой силы

Наиболее популярный класс методов,
ибо не требуют значительного внимания
и умственных затрат
Основные типы методов:
Отладка с использованием дампов
памяти
Отладочные печати
Отладка с использованием
автоматических средств

19. Отладка с использованием дампов памяти

Наименее эффективный метод (по Майерсу),
тем не менее дожил до наших дней и с успехом
используется хакерами
Основные проблемы:
Сложно установить соответствие между
адресом в памяти и переменной
Большой объем данных, в том числе
неиспользуемых
Дамп – статическое состояние, а может
потребоваться динамическое
Сложно поймать дамп именно в нужный
момент, часто получается либо до, либо после
момента ошибки
Отсутствие методик

20. Метод отладочных печатей

Позволяют отследить динамику
выполнения программы
Этим методам характерны следующие
недостатки:
Работа методом проб и ошибок
Часто возможна ситуация, когда
требуется проанализировать большой
объем данных
В программу вносятся изменения
Большая стоимость для больших систем

21.

Отладочная печать
● Состоит в выводе на экран значений интересующих
переменных.
● Применяется, если:
– значение переменных сложных структурированных
типов сложно посмотреть во время останова программы;
–хотите получить быстрый «снимок» состояний
переменных в нескольких контрольных точках, чтобы
определить, в какой части программы ошибка;
– программа не может быть остановлена, т.к. она
взаимодействует в реальном времени с другой
программой или физическим устройством.

22. Использование автоматических средств отладки

Основные инструменты:
Дебагеры
Трейсеры
Общая схема работы:
Устанавливаем точку прерывания
Проверяем внутреннее состояние программы (стек
вызовов, значения переменных)
Данные методы наиболее часто используемые
Недостатки:
Сложность при отладке больших систем
Метод проб и ошибок для класса ошибок расхождения
результатов

23.

Пошаговое выполнение (трассировка)
● Цель трассировки программы — получить
представление о том, каким образом изменяются
переменные на каждом шаге ее выполнения.
● Единицей (шагом) выполнения программы при
трассировке является строка, а не оператор.
● Место начала трассировки задается с помощью
точки останова.

24. Методы, основанные на обдумывании

25. Метод индукции

1. Метод индукции. Индукция - это анализ от частного к
целому. Просматривая симптомы ошибки, установленные
одним или несколькими тестами и взаимосвязи между
ними, можно обнаружить причину ошибки.

26. Метод дедукции

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

27. Обратное отслеживание логики

Эффективный метод отладки для
небольших программ (Майерс)
Реально данный метод один из
самых используемых. Сначала идет
локализация критического участка
методом грубой силы, далее –
обратное отслеживание логики.

28.

Понятие тестирования. Классификация
тестирования

29. Взаимосвязь разработки и тестирования (V-диаграмма)

30. Тестирование ПО

Тестирование программного обеспечения (Software
Testing) - проверка соответствия между реальным и
ожидаемым поведением программы, осуществляемая на
конечном наборе тестов, выбранном определенным
образом. [IEEE Guide to Software Engineering Body of
Knowledge, SWEBOK, 2004] В более широком смысле,
тестирование - это одна из техник контроля качества,
включающая в себя активности по планированию работ
(Test Management), проектированию тестов (Test Design),
выполнению тестирования (Test Execution) и анализу
полученных результатов (Test Analysis).

31. Тестирование ПО

План Тестирования (Test Plan) - это документ, описывающий весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и
окончания тестирования, до необходимого в процессе работы оборудования, специальных
знаний, а также оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и
создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями
качества и целями тестирования.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных
условий и параметров, необходимых для проверки реализации тестируемой функции или её
части.
Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или
последовательность действий приведшую к некорректной работе объекта тестирования, с
указанием причин и ожидаемого результата.
Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования,
представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Детализация Тест Кейсов (Test Case Specification) - это уровень детализации описания
тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение
времени прохождения к тестовому покрытию
Время Прохождения Тест Кейса (Test Case Pass Time) - это время от начала прохождения
шагов тест кейса до получения результата теста

32.

Классификация тестирования

33. Основные технологии тестирования

Технологий тестирования существует
целое множество. Условно их можно
отнести к статическим или к
динамическим.

34.

Статическое тестирование – это процесс, который
обычно ассоциируют с анализом ПО.
Статическим тестированием пользуются для
верификации практически любого артефакта
разработки: программного кода компонент,
требований, системных спецификаций,
функциональных спецификаций, документов
проектирования и архитектуры программных систем и
их компонентов, и т.д.
Использование статических методов тестирования –
один из наиболее эффективных способов обнаружения
дефектов на ранних стадиях разработки ПО.
Действительно, статическое тестирование – это
единственный способ тестирования без запуска
программного кода приложения.

35.

Динамическое тестирование – процесс
тестирования, производимый над работающей
системой или подсистемой.
Оно не может быть осуществлено без
запуска программного кода приложения
Динамическое тестирование состоит из:
1. запуска системы или подсистемы;
2. вызова необходимых функциональных
элементов или модулей;
3. сравнения через графический интерфейс
пользователя поведения системы с ожидаемым
результатом поведения.

36. Уровни Тестирования Программного Обеспечения

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

37. Уровни Тестирования

Компонентное или Модульное тестирование
(Component Testing or Unit Testing)
Интеграционное тестирование (Integration
Testing)
Системное тестирование (System Testing)
Приемочное тестирование (Acceptance
Testing)

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

Виды тестирования
Виды тестирования программного обеспечения,
в зависимости от преследуемых целей, можно условно
разделить на следующие группы:
1. Функциональные
2. Нефункциональные
3. Связанные с изменениями

39. Функциональные виды тестирования

Функциональные тесты базируются на функциях и
особенностях, а также взаимодействии с другими
системами, и могут быть представлены на всех
уровнях тестирования:
компонентном или модульном (Component/Unit
testing),
интеграционном (Integration testing), системном
(System testing) и
приемочном (Acceptance testing). Функциональные
виды тестирования рассматривают внешнее
поведение системы.

40. Функциональные виды тестирования

Самые распространенные виды функциональных
тестов:
Функциональное тестирование (Functional testing)
Тестирование безопасности (Security and Access
Control Testing)
Тестирование взаимодействия (Interoperability
Testing)

41. Нефункциональные виды тестирования

Нефункциональное тестирование
описывает тесты, необходимые для
определения характеристик
программного обеспечения, которые
могут быть измерены различными
величинами. В целом, это тестирование
того, "Как" система работает.

42. Нефункциональные виды тестирования

Основные виды нефункциональных тестов:
Все виды тестирования производительности:
нагрузочное тестирование (Performance and Load Testing)
стрессовое тестирование (Stress Testing)
тестирование стабильности или надежности (Stability /
Reliability Testing)
объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and
Recovery Testing)
Конфигурационное тестирование (Configuration Testing)

43. Связанные с изменениями виды тестирования

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

44. Связанные с изменениями виды тестирования

Виды тестирования, которые необходимо проводить
после установки программного обеспечения, для
подтверждения работоспособности приложения или
правильности осуществленного исправления дефекта:
Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка
согласованности/исправности (Sanity Testing)

45.

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

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

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

47. Классификация видов тестирования

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

Модульное тестирование (Автономное или Unit-тестирование)
Входные требования — Архитектура компонентов или модель
“нижнего уровня” системы (Component Design или Low Level Design)
Объект тестирования — Разработанные компоненты
Определение: На данном уровне тестируются по отдельности
небольшие элементы системы, максимально отделенные от других
элементов и, в то же время, пригодные для тестирования. Такое
тестирование обычно проводится сразу же вслед за разработкой
каждого из элементов и направлено на оценку соответствия
функциональности каждого из компонентов спроектированной
“модели компонентов”.

49.

Комплексное тестирование (Сборочное тестирование,
integration testing или interface testing)
Входные требования — Архитектура системы или модель
“верхнего уровня” системы (System Design или High Level
Design)
Объект тестирования — Собранная из компонентов
система или подсистема
Определение: На данном уровне тестируются
объединенные элементы (компоненты или подсистемы)
общей системы, чаще всего некоторая взаимодействующая
между собой группа элементов.
Комплексное тестирование направлено не на проверку
функционирования каждого из компонентов, а на проверку
взаимодействия компонентов в соответствии с «Архитектурой
системы».

50.

Системное тестирование (system testing)
Входные требования — Системные спецификации (System
Specification)
Объект тестирования — Разработанная система
Определение: После того, как система собрана из
составляющих компонентов, она должна быть протестирована
на соответствие “Системным спецификациям” – реализованы
ли все функциональные и нефункциональные требования к
разрабатываемой системе.
На данном уровне тестируется приложение или система (одно
или более приложений) целиком.

51.

Приемочное тестирование (Приемо-сдаточное тестирование
или acceptance testing)
Входные требования — Требования (Requirements)
Объект тестирования — Разработанная система
Определение: На данном уровне завершенное приложение
(система) тестируется Заказчиком, конечными пользователями
или соответствующими уполномоченными с целью
определения соответствия системы “Требованиям Заказчика” и
готовности системы к внедрению. Приемосдаточные
испытания оформляют процесс передачи продукта от
Разработчика Заказчику. В зависимости от особенностей
продукта и от требований Заказчика они могут проводиться в
различной форме. Например, в виде альфа- или бетатестирования.

52.

Приемочное тестирование схоже с системным
тестированием, но со следующим различием:
Системное тестирование проверяет, что
разработанная система соответствует специфицированным
требованиям;
Приемочное тестирование проверяет, что
разработанная система удовлетворяет запрошенным
Заказчиком требованиям с упором на нужды конечных
пользователей в данной предметной области.

53.

Операционное тестирование (Release Testing)
Входные требования — Бизнес модель (Business Case или
Business Model)
Объект тестирования — Разработанная система
Определение: Даже если система удовлетворяет всем
требованиям, важно убедиться в том, что она удовлетворяет
нуждам пользователя и выполняет свою роль в среде своей
эксплуатации, как это было определено в бизнес-модели
системы. Следует учесть, что и Бизнес модель может
содержать ошибки. Поэтому так важно провести
операционное тестирование как финальный шаг Валидации.

54.

Инсталляционное тестирование (Installation testing)
Определение: В процессе инсталляционного тестирования
проверяется корректность установки и деинсталляции
программного продукта в среде максимально приближенной к
эксплуатационной. Проверка правильности установки
программного продукта должна быть обязательным
элементом проекта по тестированию любого продукта.
Цель: Основная цель состоит в том, чтобы убедиться, что
продукт может быть установлен/деинсталлирован при
различных условиях – таких как: новая инсталляция,
усовершенствование системы (upgrade), установка по
умолчанию, полная установка, установка по выбору.

55.

Дымное тестирование (проверка на дым, Smoke testing)
Определение: Первый прогон программы (после написания
или после внесения существенных изменений). Как правило,
используется для определения, готова ли программа для
проведения более обширного тестирования.
Цель: Выявление проблем «лежащих на поверхности» –
тестируется чаще всего основная бизнес логика программы
Короткий тест, проверяющий основную
функциональность программного продукта и
его работоспособность, ограниченный по
времени, по результатам которого ведущий
инженер по тестированию принимает
решение о приемке версии ПП на
тестирование.

56.

Функциональное тестирование (Functional testing)
Определение: Проверка соответствия продукта
функциональным требованиям и спецификациям
Цель: Проверка соответствия продукта функциональным
требованиям и спецификациям

57.

Регрессионное тестирование (Regression testing)
Определение: Повторное тестирование после внесения
изменений в программное обеспечение или в его окружение
(в новой версии приложения), чтобы убедиться в том, что
функции, которые работали в предыдущей версии системы,
по-прежнему работают так, как ожидалось, а найденные
дефекты успешно исправлены (все протестированное ранее
тестируется повторно)
Цель: Выявление потенциальных проблем, которые могли
возникнуть в результате изменений. Проверка исправления
найденных ранее дефектов.

58.

Интеграционное тестирование (Integration testing)
Определение: Проверка скомбинированных компонентов
прикладной программы с целью определения корректности их
совместного функционирования
Цель: Выявление потенциальных проблем в совместном
функционировании компонент
Тестирование графического интерфейса пользователя
(User Interface testing)
Определение: Тестирование интерфейса – экранов, кнопок и
т.д. Большая часть функциональности ПО реализуется, как
правило, через пользовательский интерфейс.
Цель: Обнаружение ошибок в интерфейсе и поиск ошибок в
функциональности посредством интерфейса

59.

Тестирование производительности (Performance
testing)
Определение: Проверка скорости работы системы
(время отклика, частота транзакций и другие
зависящие от времени) в имитационной и реальной
средах
Цель: Установить реальную производительность
программного продукта

60.

Нагрузочное тестирование (Load testing)
Определение: Это те же тесты производительности, при
которых система подвергается различным нагрузкам; при этом
цель этого тестирования – оценить способность системы
правильно функционировать при некотором превышении
планируемых нагрузок при реальной эксплуатации (система
имеет некоторый «запас прочности»)
Цель: Убедиться в том, что система работает соответственно
ожидаемым рабочим нагрузочным параметрам (какой предел
работоспособности)

61.

Стресс тестирование (Stress testing)
Определение: Является одним из разновидностей
тестирования на производительность. Проверяется поведение
системы при недостатке ресурсов (дискового пространства,
обрывов сети и т.д.).
Цель: Проверка того, что система адекватно реагирует на те
или иные стрессовые ситуации

62.

Стрессовое тестирование
(Stress testing)
Один из видов тестирования программного обеспечения,
которое оценивает надёжность и устойчивость системы в
условиях превышения пределов нормального
функционирования. Стресс-тестирование особенно
необходимо для «критически важного» ПО, однако также
используется и для остального ПО.
62
GDC © 2015

63.

Конфигурационное тестирование (Configuration testing)
Определение: Конфигурационное тестирование – тестирование
работы на различных платформах. Различные варианты
аппаратной конфигурации, версии операционной системы и
окружения.
Цель: Проверить работоспособность системы при различных
конфигурациях

64.

Тестирование надежности (reliability) ПО производится с
целью проверки нефункциональных требований, что
приложение работает, как и ожидалось, устойчиво к падениям и
т.п. Здесь применяются интеграционные тесты, тесты
структуры, стрессовые тесты и другие.
Тестирование удобства использования (usability) ПО
(нефункциональные требования) производится с целью
удостовериться в том, что приложение удобно для
использования его конечным пользователям. Включает в себя
тесты на человеческий фактор, эстетику интерфейса и его
непротиворечивость, наличие и качество оперативной и
контекстной помощи, руководств и учебных материалов.

65.

Тестирование производительности (performance) ПО
выполняется с целью удостовериться, что функционирование
приложения обеспечивается в то время, когда выполняются
нефункциональные требования к приложению по работе в
реальных условиях. Включает в себя оценку временных
профилей, времени отклика, операционной надежности и
некоторых других характеристик. Основные виды тестирования
приведены ниже.

66.

Приемочный тест (Smoke test) – первый и самый короткий
тест, призванный проводить проверку основных элементов
программного продукта и его работоспособности в целом. В
случае функционального тестирования – проверяется основной
функционал приложения. Тест занимает 1-4 часа в зависимости
от сложности тестируемого продукта. На основе результатов
данного теста принимается решение о приемке версии
программного продукта и продолжении тестирования текущей
версии продукта более серьезными тестовыми испытаниями.

67.

Критический тест (Critical path test) – основной тип тестовых
испытаний, во время которого значимые элементы и функции
приложения проверяются на предмет правильности работы при
стандартном их использовании. Как правило, на данном уровне
тестирования проверяется основная масса требований к
продукту.
Расширенный тест (Extended test) – вид углубленного
тестирования, при котором проверяется нестандартное
использование программного продукта, границы переполнения
массивов данных, ввод специальных символов и т.п.

68.

Принципы тестирования
Стратегии тестирования

69.

Основные принципы тестирования ПС
Принципы оптимальной стратегии проектирования тестов
1. На каждую используемую функцию или
возможность – хотя бы один тест;
2. На каждую область и на каждую границу
изменения какой-либо величины – хотя бы один
тест;
3. На каждую особую (исключительную)
ситуацию – хотя бы один тест;
4. Каждая команда каждой программы ПС должна
поработать хотя бы на одном тесте.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

70.

Основные принципы тестирования ПС
К основным принципам организации процесса
тестирования программ традиционно относят следующие
1. Тестирование считается ключевой задачей
разработки ПС, оно должно быть поручено самым
квалифицированным программистам.
2. Нежелательно тестировать свою собственную
программу.
3. Хорош тот тест, для которого высока вероятность
обнаружить ошибку, а не тот, который демонстрирует
правильную работу программы.
4. Необходимо разрабатывать тесты как для
правильных, так и для неправильных данных.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

71.

Основные принципы тестирования ПС
К основным принципам организации процесса
тестирования программ традиционно относят следующие
(продолжение)
5. Никогда не нужно изменять программу, чтобы
облегчить её тестирование;
6. Необходимо реализовывать заново все тесты,
связанные с проверкой работы какой-либо
программы ПС или её взаимодействия с другими
программами, если в неё были внесены
изменения.
Главный принцип – найти ошибки, а не доказать
их отсутствие
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

72.

Стратегии тестирования
Различие задач и целей тестирования на протяжении жизненного
цикла продукта приводит к необходимости разрабатывать и
реализовывать различные стратегии тестирования.
Каждая такая стратегия определяет:
1. итерации, на которых используются стратегия тестирования и цели
тестирования на каждой итерации;
2. стадии тестирования для каждой итерации;
3. критерий успешного завершения тестирования;
4. типы используемых тестов;
5. набор методов и инструментальных средств, необходимых для
проведения тестирования и оценки качества;
6. критерии оценки тестов.

73.

Стратегии тестирования
Тестирование «белого ящика» и «чёрного ящика»
В терминологии профессионалов тестирования, фразы
«тестирование белого ящика» и «тестирование чёрного
ящика» относятся к тому, имеет ли разработчик тестов
доступ к исходному коду тестируемого ПО, или же
тестирование выполняется через пользовательский
интерфейс либо прикладной программный интерфейс,
предоставленный тестируемым модулем.

74.

Стратегии тестирования
При тестировании белого ящика (англ. white-box
testing, также говорят — прозрачного ящика),
разработчик теста имеет доступ к исходному коду
программ и может писать код, который связан с
библиотеками тестируемого ПО. Это типично для юниттестирования (англ. unit testing), при котором
тестируются только отдельные части системы. Оно
обеспечивает то, что компоненты конструкции —
работоспособны и устойчивы, до определённой степени.
При тестировании белого ящика используются метрики
покрытия кода.

75.

Тестирование белого ящика
( White (Glass box, structural) Box Testing
Противоположность методу Черного ящика
Тестирование производится на основании
информации, как устроена
система изнутри
Обычно производится самими
программистами
75
GDC © 2015

76.

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

77.

Тестирование черного ящика
(Black Box (closed box, opaque box,
behavioral) Testing
Тестировщик производит тестирование не
имея информации о том, как устроена
система изнутри.
Идеи для тестирование идут от
предполагаемого поведения
пользователей.
77
GDC © 2015

78.

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

79.

Тестирование серого
ящика
Grey Box Testing
Подход сочетает в себе как белый, как и черный ящик
Это информированное тестирование, ориентированное на
пользователя
79
GDC © 2015

80.

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

81.

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

82.

Покрытие, основанное на спецификации или на
требованиях (Specification-Based Coverage or
Requirements-based Test Coverage).
Этот критерий оценивает степень покрытия, принимая во
внимание требования Заказчика или системные спецификации. Основой
может быть, например, таблица требований, use case модель и
диаграмма состояний-переходов. Набор тестов должен покрывать все
или конкретно определенные функциональные требования.
На практике это чаще всего реализуется следующим образом:
Заказчик (или системный аналитик) составляет набор требований,
которые могут быть переведены в тестовые сценарии. После чего эти
сценарии могут быть проверены на правильность и полноту.
Таким образом, данный критерий показывает в процентном
отношении количество покрытых тестами требований. Чаще всего
данный критерий используется при тестировании методом «черного
ящика».

83.

Покрытие, основанное на коде (CodeBased Coverage) имеет отношение к потоку
управления и потоку данных программы. Чаще
всего данный критерий используется при
тестировании методом «белого ящика».

84.

Основные критерии покрытия тестирования кода
следующие:
Покрытие строк (Line Coverage) – мера измерения
покрытия кода, указывающая процентное отношение строк
программы, затронутых тестами, к общему числу строк. Это
очень неточная метрика, потому что даже стопроцентное
покрытие по ней пропускает много ошибок.
Покрытие ветвей (Branch Coverage). Это мера
измерения покрытия кода указывает в процентном
отношении, сколько ветвей потока управления было
протестировано во время теста. Она надежнее предыдущей
метрики, но снова стопроцентное покрытие не гарантирует
отсутствие ошибок.

85.

Покрытие путей (Path Coverage). Эта единица
измерения характеризует процент всевозможных путей
(и/или комбинаций ветвей), которые покрываются
тестами. Однако, даже не смотря на 100-процентное
покрытие (достичь которого практически нереально в
коммерческих системах) все еще могут присутствовать
скрытые ошибки.
Метрики и критерии тестирования определяются
в стратегии тестирования наряду с остальными
составляющими процесса.

86. Автономная отладка

87.

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

88.

Основные аспекты организации
автономного тестирования ПС
Виды автономного тестирования
1. Восходящее тестирование.
2. Нисходящее тестирование.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

89. Пошаговое тестирование Восходящее тестирование

4
3
2
1
Процесс повторяется до тех пор, пока не будет
достигнута вершина.

90. Пошаговое тестирование Восходящее тестирование

91.

Основные аспекты организации
автономного тестирования ПС
Достоинства восходящего тестирования
1. Простота подготовки тестов.
2. Возможность полной реализации
плана тестирования модуля.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

92.

Основные аспекты организации
автономного тестирования ПС
Недостатки восходящего тестирования
1. Тестовые данные готовятся, как правило,
не в той форме, которая рассчитана на
пользователя.
2. Большой объём отладочного
программирования.
3. Необходимость специального тестирования
сопряжения модулей.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

93. Пошаговое тестирование Нисходящее тестирование

1
2
3
4
Процесс повторяется до тех пор, пока не будут
собраны и проверены все модули.

94. Пошаговое тестирование Нисходящее тестирование

95. Пошаговое тестирование Нисходящее тестирование

Достоинства:
1) метод совмещает тестирование модуля,
тестирование сопряжений и частично тестирование
внешних функций.
2) когда модули ввода-вывода уже подключены,
тесты можно готовить в удобном виде
3) выгоден, когда есть сомнения относительно
осуществимости программы в целом или когда в
проекте программы могут оказаться серьезные
дефекты.
4) отсутствие необходимости в драйверах; вместо
драйверов вам просто следует написать «заглушки».

96.

Пошаговое тестирование
Нисходящее тестирование
Недостатки:
1)модуль редко тестируется досконально сразу
после его подключения.
2)может породить веру в возможность начать
программирование и тестирование верхнего уровня
программы до того, как вся программа будет
полностью спроектирована.

97.

Основные аспекты организации
автономного тестирования ПС
Достоинства нисходящего тестирования
1. Большинство тестов готовится в
форме, рассчитанной на пользователя.
2. Во многих случаях относительно
небольшой объём отладочного
программирования.
3. Отпадает необходимость
тестирования сопряжения модулей.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

98.

Основные аспекты организации
автономного тестирования ПС
Недостатки нисходящего тестирования
1. Тестовое состояние информационной
среды готовится косвенно – как
результат применения уже отлаженных
модулей к тестовым данным или
данным, выдаваемым имитаторами.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

99. Пошаговое тестирование Метод сандвича

Тестирование методом сандвича представляет
собой компромисс между восходящим и нисходящим
подходами.
При использовании этого метода одновременно
начинают восходящее и нисходящее тестирование,
собирая программу как снизу, так и сверху и
встречаясь в конце концов где-то в середине.

100.

Пошаговое тестирование
Метод сандвича
1
2
3
2
1
Метод сандвича сохраняет такое достоинство
нисходящего и восходящего подходов, как начало
интеграции системы на самом раннем этапе.

101. Пошаговое тестирование Модифицированный метод сандвича

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

102. Монолитное тестирование Метод «большого скачка»

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

103. Монолитное тестирование Метод «большого скачка»

Для крупных программ метод «большого
скачка» обычно губителен

104. Сравнительная характеристика методов тестирования

С точки зрения надежности программного обеспечения эти
методы можно оценить по следующим восьми критериям:
1. Время до момента сборки модулей
2. Время до момента создания первых работающих
“скелетных” версий программы
3. Необходимость драйверов и других инструментов
тестирования
4. Необходимость заглушек
5. Мера параллелизма
6. Возможность тестировать отдельные пути
7. Возможность планировать и контролировать
последовательность
104 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта

105. Сравнительная характеристика

Восходящий
Нисхо- Модиф. больш.
дящий Нисх.
скачка
Сандвича
Модиф.
Cандв.
Рано
Рано
Поздно Рано
Рано
1 Рано
Поздно Рано
Рано
2 Поздно Рано Рано
Нет
Да
Да
Частично Да
3 Да
Да
Да
Да
Частично Частично
4 Нет
5 Средний Слабый Средний Высокий Средний Высокий
6 Легко Трудно Легко Трудно Средне Легко
7 Легко Трудно Трудно Легко Трудно Трудно
105 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта

106. Оценка подходов

Оценка подходов зависит от конкретного проекта. Рассмотрим
вариант очень грубой оценки. Прежде всего, следует взвесить
относительное влияние каждого из семи критериев на
надежность программного обеспечения. Ранняя сборка и
раннее получение работающего каркаса программы, а также
возможность тестировать любые конкретные условия
представляются наиболее важными, поэтому им дается
коэффициент 3. Сложность подготовки заглушек, а также
сложность планирования и управления последовательностью
тестов получают вес 2. Необходимость драйверов, вес 1 ввиду
доступности общих инструментов тестирования. Критерий,
связанный с параллелизмом работы имеет вес 1, потому что он
на надежность сильно не влияет.
106 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта

107. Результаты оценок

Вес Крит Восх.
Модиф. Больш.
Метод
Нисх.
скачка
сандвича
Рано + Поздно - Рано +
Модиф.
сандвича
Рано +
Рано + Рано + Поздно - Рано +
Нет + Да
- Да
- Частично
Да
- Да
- Да
- Частично
Слабый - Средний Высокий Средний
+
6
Легко + Трудно - Легло + Легко + Средне
7
Легко + Трудно - Трудно - Легко + Трудно
Итог +6
-1
+4
-3
+4
Рано +
Да
Частично
Высокий
+
Легко +
Трудно
+7
3
1
3
1
2
1
2
3
4
5
3
2
Рано +
Нисх.
Рано +
Поздно Да
Нет
+
Средний
Модифицированный метод сандвича и восходящий метод
оказываются наилучшими подходами, а метод большого
скачка — наихудшим.
107 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта

108. Основные аспекты организации автономного тестирования ПС

109.

Основные аспекты организации
автономного тестирования ПС
Основные этапы разработки сценария автономного тестирования
1. На основании спецификации отлаживаемого
модуля подготовить тесты для
- каждой логической возможности ситуации;
- каждой границы областей возможных
значений всех входных данных;
- каждой области недопустимых значений;
- каждого недопустимого условия.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

110.

Основные аспекты организации
автономного тестирования ПС
Основные этапы разработки сценария автономного тестирования
(продолжение)
2. Проверить текст модуля, чтобы убедиться, что
каждое направление любого разветвления будет
пройдено хотя бы один раз. Добавить недостающие
тесты.
3. Проверить текст модуля, чтобы убедиться, что для
каждого цикла существуют тесты, обеспечивающие,
по крайней мере, три следующие ситуации
- тело цикла не выполняется ни разу;
- тело цикла выполняется один раз;
- тело цикла выполняется максимальное число раз;
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

111.

Основные аспекты организации
автономного тестирования ПС
Основные этапы разработки сценария автономного тестирования
(продолжение)
4. Проверить текст модуля, чтобы
убедиться, что существуют тесты,
проверяющие чувствительность к
отдельным особым значениям входных
данных. Добавить недостающие тесты.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

112. Критерии и принципы построения тестового набора. Организация процесса тестирования

Требования к идеальному критерию:
1. Критерий должен быть достаточным, т.е. показывать,
когда некоторое конечное множество тестов
достаточно для тестирования данной программы.
2. Критерий должен быть полным, т.е. в случае ошибки
должен существовать тест из множества тестов,
удовлетворяющих критерию, который раскрывает ошибку.
112
GDC © 2015

113.

3. Критерий должен быть надежным, т.е. любые два
множества тестов, удовлетворяющих ему, одновременно
должны раскрывать или не раскрывать ошибки
программы
4. Критерий должен быть легко проверяемым, например
вычисляемым на тестах
113
GDC © 2015

114.

Основные аспекты организации автономного
тестирования ПС
Специальный документ – матрица покрытия требований тестами
(Test Traceability Matrix).
Тестовое покрытие –
это одна из метрик оценки качества тестирования, представляющая из
себя плотность покрытия тестами требований либо исполняемого кода
Требования
Тесты
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
1
2
3
4
1
0
1
1
0
2
1
0
0
0
3
0
0
1
0
4
1
0
0
0
5
0
1
1
0
6
0
1
1
1

115.

Комплексная отладка ПО

116. Комплексная отладка программного средства.

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

117. Модульное тестирование

В тестирование многомодульных программ можно
выделить четыре этапа:
1) тестирование отдельных модулей;
2) совместное тестирование модулей;
3) тестирование спецификации программы;
4) тестирование всего комплекса в целом.
На первых двух этапах используются методы
структурного тестирования, последующие этапы
тестирования ориентированы на обнаружение
ошибок различного типа, которые не обязательно
связаны с логикой программы.
117 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта

118. Интеграция модулей

Последовательность слияния всех модулей в систему
или программу является вторым по важности аспектом
тестирования (после проектирования тестов).
Выбор этой последовательности является одним из
самых жизненно важных решений, принимаемых на
этапе тестирования, поскольку он определяет форму, в
которой записываются тесты, типы необходимых
инструментов
тестирования,
последовательность
программирования модулей, а также тщательность и
экономичность всего этапа тестирования.
118 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта

119. Сборка модулей

Подходы к комбинированию модулей
1) Пошаговое тестирование
2) Монолитное тестирование

120.

Основные аспекты комплексного
тестирования ПС
Этапы комплексного тестирования
1. Тестирование архитектуры ПС;
2. Тестирование внешних функций ПС;
3. Тестирование качества ПС;
4. Тестирование документации по
применению ПС;
5. Тестирование определения требований к
ПС.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

121. Тестирование архитектуры ПС.

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

122. Тестирование внешних функций.

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

123. Тестирование качества ПС.

Целью тестирования является поиск
нарушений требований качества,
сформулированных в спецификации
качества ПС.
Это наиболее трудный и наименее
изученный вид тестирования.

124. Тестирование документации по применению ПС.

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

125. Тестирование определения требований к ПС.

Целью тестирования является выяснение, в
какой мере ПС не соответствует предъявленному
определению требований к нему.
Особенность этого вида тестирования
заключается в том, что его осуществляет
организация-покупатель или организацияпользователь ПС как один из путей преодоления
барьера между разработчиком и пользователем.
Обычно это тестирование производится с
помощью контрольных задач - типовых задач, для
которых известен результат решения.

126.

Ручное и автоматизированное
тестирование

127.

Ручное
Автоматизированное
Смешанное\полуавтоматическое

128.

Ручное тестирование
Выполняется без привлечения средств
автоматизации
Выполняется, обычно, по подготовленным тест
кейсам
128
Internal use only
GDC © 2015

129.

Автоматизированное
тестирование
Выполняется с использованием
специализированных
программных продуктов
Требуется высокая
квалификация тестировщиков и
навыки программирования
129
GDC © 2015

130.

131.

132.

133.

134.

135.

136.

137.

138.

139. Циклы тестирования

140. Циклы тестирования

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

141. ЦИКЛЫ ТЕСТИРОВАНИЯ

• Полный цикл тестирования обычно совпадает с итерацией
разработки или соответствует ее определенной части.
Очевидно, что, в случае разработки программного продукта
по каскадной модели, полный цикл тестирования скорее
всего будет иметь только одну итерацию
• Частный цикл тестирования, как правило, проводится для
конкретной сборки объекта тестирования (системы,
подсистемы или отдельного компонента

142. ЧАСТНЫЙ ЦИКЛ И ЕГО ЗАДАЧИ

1. Определить цели тестирования. Включает выбор тестируемых фрагментов и
формулирование задач тестирования (например, определить пригодность
архитектуры, проверить реализацию основной функциональности конкретного
Сценария использования или проверить выполнение требований Заказчика в полном
объеме).
2. Верифицировать метод тестирования. Настройка среды и инструментов
тестирования, выполнение отдельных тестов, подтверждение возможности
реализовать задачи и цели тестирования.

143. ЧАСТНЫЙ ЦИКЛ И ЕГО ЗАДАЧИ

3.
Подтвердить правильность сборки. Прежде, чем приступить к
детальному тестированию выбранной сборки, проводятся ее тесты “на
дым”. Эти тесты должны показать, что сборка не содержит явных
ошибок, делающих ее дальнейшее тестирование просто
нецелесообразным. Для “проходных” сборок, в которых не реализован
достаточный объем новой функциональности, тестирование может на
этом и заканчиваться.

144. ЧАСТНЫЙ ЦИКЛ И ЕГО ЗАДАЧИ

• 4.
Тестировать и оценивать. Разрабатываются (уточняются)
необходимые тесты, после чего тесты выполняются в ручном или
автоматическом режиме и проводится оценка результатов. Достичь
приемлемого уровня достижения целей тестирования. Оценивается, с
одной стороны, качество и эффективность тестирования, а, с другой
стороны, качество тестируемой системы и ее соответствие
требованиям, предъявляемым на данном этапе разработки проекта

145. ЧАСТНЫЙ ЦИКЛ И ЕГО ЗАДАЧИ

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

146. ЧАСТНЫЙ ЦИКЛ И ЕГО ЗАДАЧИ

Частный цикл тестирования, проводимый для отдельной сборки объекта тестирования
на текущем этапе ЖЦ ТП

147. Лекция 13 Полный цикл и артефакты тестирования

148. Полный цикл тестирования и его задачи

Рассмотрим более подробно существующие активности/задачи связанные с
тестированием:
1) планирование тестов:
•
определение требований к тестам;
•
оценка рисков;
•
выбор стратегии тестирования;
•
определение ресурсов;
•
создание расписания/последовательностей;
•
разработка Плана тестирования;

149. Полный цикл тестирования и его задачи

2) дизайн тестов:
•
анализ объёма работ;
•
определение и описание тестовых случаев;
•
определение и структурирование тестовых процедур;
•
обзор и оценка тестового покрытия;
3) разработка тестов:
•
запись или программирование тестовых скриптов;
•
определение тесто-критичной функциональности в Дизайне и Модели
реализации;
•
создание/подготовка внешних наборов данных;

150. Полный цикл тестирования и его задачи

4) выполнение тестов:
•
выполнение тестовых процедур;
•
оценка выполнения тестов;
•
восстановление после сбойных тестов;
•
проверка результатов;
•
исследование неожиданных результатов;
•
запись ошибок;
5) оценка тестов:
•
оценка покрытия тестовыми случаями;
•
оценка покрытия кода;
•
анализ дефектов;
•
определение критериев завершения и успешности тестирования.

151. Полный цикл тестирования, определяющий основные активности специалистов

152.

Артифакты тестирования
• Выполнение задач жизненного цикла
сопровождается разработкой различных артефактов
(документов, моделей и других материалов проекта).
• Разработка артефактов может проводиться в разной
форме с разными требованиями к способу
выполнения, рецензированию и качеству
оформления.
• Основные рабочие артефакты тестировщиков, в той
или иной форме связанные со Сценариями
использования. Эти документы стоит готовить в
достаточно аккуратном виде, поскольку, скорее
всего, придется неоднократно к ним возвращаться
самим, а часто еще и передавать их Заказчику или
группе сопровождения и технической поддержки

153. Основные артефакты тестирования

План тестирования. Основной документ, определяет стратегию тестирования на
каждой итерации. В него входят описание целей и задач тестирования в текущей
итерации, перечни тестов, которые должны и не должны использоваться,
формируемые начальные и конечные метрики и критерии тестирования.
Сценарий тестирования (тест кейс или тестовый случай). Это один из основных
документов, с которыми имеет дело тестировщик. По сути, упрощенное описание
теста. То есть входной информации, условий и последовательности выполнения
действий и ожидаемого выходного результата. Учитывая, что даже успешно
прошедшие тесты в RUP выполняются неоднократно в ходе регрессионного
тестирования, наличие таких описаний необходимо. Однако уровень формальных
требований к их оформлению может меняться в очень широких пределах.

154. Основные артефакты тестирования

Тестовые данные. Призваны определять наборы (обычно формальных) входных данных
для тестов, а также ожидаемые результаты, с которыми полученные результаты выполнения
тестов должны сравниваться как с эталонными. Тестовые данные должны храниться в одном
месте, желательно в центральном хранилище данных. Очень рекомендуется собирать вместе
данные для каждой определенной группы тестов
Тестовый скрипт. Обычно говорят о программной реализации теста, хотя скрипт может
описывать и ручные действия, необходимые для выполнения конкретного тест кейса.
Набор тестов. Как правило, сценарии тестирования объединяются в пакеты или наборы. Вопервых, это просто способ группирования тестов со сходными задачами, а, во-вторых, в
такой набор можно включать зависимые тесты, которые должны выполняться в
определенном порядке (поскольку последующие тесты используют данные,
сформированные в ходе выполнения предыдущих).

155. Основные артефакты тестирования

Список идей тестов. Использование в RUP для анализа и проектирования Системы
Сценариев использования существенно упрощает задачу разработки необходимого набора
тестов. Основной объем тестов строится как проверка различных вариантов выполнения
каждого сценария использования. Однако тесты не сводятся к Сценариям использования,
как и задачи тестирования не сводятся только лишь к проверке функциональных требований
к системе. Проверка нефункциональных требований может потребовать использования
специальных приемов и подходов. Соответствующие тесты не всегда очевидны. Для таких
ситуаций и создается Список идей тестов. В него все желающие могут записать Что и/или
Как стоит еще проверить. Этот список является внутренним рабочим документом группы
тестирования.

156. Основные артефакты тестирования

Результаты тестирования. Представляют собой суммарную информацию о прохождении
тестов, на основе анализа которых и сравнения с ожидаемыми результатами выполняется
детальная оценка качества тестируемого продукта и текущего статуса процесса
тестирования. Рекомендуется записывать и сохранять результаты тестирования для каждого
этапа как один из важнейших артефактов тестирования.
Дефекты. Основополагающие артефакты процесса тестирования – описывают
обнаруженные факты несоответствия системы предъявляемым требованиям. Являются
одним из подтипов запросов на изменение, описывающих найденную ошибку или
несоответствие на всех этапах тестирования. Желательным является использование
специализированного инструментального средства, которое позволяет передавать
информацию об обнаруженных дефектах от тестировщиков к разарботчикам, а в обратную
сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о
тенденциях изменения количества обнаруживаемых и устраняемых дефектов.

157. Лекция 14 Единая система программной документации Документ «Программа и методика испытаний»

Единая система программной документации
Документ «Программа и методика
испытаний»

158. Планирование тестов

159. Процесс тестирования

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

160. Процесс тестирования

Как только разработчики подготовили билд, вы должны провести дымовое
тестирование, по результатам которого делается вывод о возможности и
целесообразности дальнейшего тестирования:
В случае если "smoke test failed!!!", вы отправляете приложение на доработку.
Если же "smoke test passed!!!", то вы переходите к следующему виду тестирования регрессионное тестирование (Regression testing) и санитарное тестирование (Sanity
testing).

161. Процесс тестирования

Открыв багтрекер, вы должны перепроверить дефекты, которые разработчики
перевели в статус Fixed (Исправлено), Rejected, Can't Reproduce и т.д. Заметим, что
статусы Rejected и Can't Reproduce для вас самые неприятные - это явное
свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не
очень понятно описали шаги для воспроизведения, либо разработчик поленился
воспроизвести ситуацию.
Покончив с закрытием и пере-открытием дефектов, вы переходите к основной
работе - централизованному тестированию по тест кейсам и/или (если вы адепт
исследовательского тестирования) вы начинаете "исследовать" приложение.

162. Процесс тестирования

Когда все, что было запланировано, пройдено, вы имеете результаты прогона тест
кейсов, баг репорты, вопросы к аналитикам и заметки на полях своих тетрадей.
Основываясь на всем этом, вы составляете отчет по проведенному тестированию и
отправляете его на проектную группу.
Подобный процесс проходит от версии к версии, и через какое-то время результаты
тестирования сойдутся, с прописанными в плане тестирования критериями
окончания тестирования. На этом основная работа, связанная с непосредственно с
тестированием, окончена, и вы можете приступить к передаче приложения
заказчику.

163. Условия для проведения тестирования

«необходимые и достаточные условия для проведения тестирования».
Рассмотрим определения требуемых понятий:
Необходимыми условиями истинности утверждения А называются условия, без
соблюдения которых А не может быть истинным.
Достаточными называются такие условия, при наличии (выполнении,
соблюдении) которых утверждение А является истинным.

164. Необходимые условия:

Наличие объекта тестирования, доступного для проведения испытаний
Наличие исполнителя(ей) (в зависимости от вида проводимых испытаний им
может быть как человек, так и машина или комбинация человек+машина)

165. Достаточные условия:

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

166. Тестовые Артефакты

Во время проведения тестирования создается и используется определенное количество тестовых
артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами
являются:
• План тестирования (Test Plan) - это документ описывающий весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и
окончания тестирования, до необходимого в процессе работы оборудования, специальных
знаний, а также оценки рисков с вариантами их разрешения.
• Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по
которой можно проверить соответствует ли тестируемая функция установленным
требованиям.
• Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или
последовательность действий приведшую к некорректной работе объекта тестирования, с
указанием причин и ожидаемого результата.

167. Планирование тестов Рекомендации по написанию Тест Плана

Рекомендации по написанию Тест
Плана
Форматы оформления планов тестирования. Шаблоны тест планов от RUP
(Rational Unified Process) и стандарт IEEE 829:
• Test Plan Template RUP
• Test Plan Template IEEE 829
оба документа описывают одно и тоже

168. Планирование тестов Рекомендации по написанию Тест Плана

хороший тест план должен как минимум описывать следующее:
Что надо тестировать?
описание объекта тестирования: системы, приложения, оборудования
Что будете тестировать?
список функций и описание тестируемой системы и её компонент в отдельности
Как будете тестировать?
стратегия тестирования, а именно: виды тестирования и их применение по отношению к
объекту тестирования

169. Планирование тестов Рекомендации по написанию Тест Плана

Когда будете тестировать?
последовательность проведения работ: подготовка (Test Preparation), тестирование
(Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз
разработки
Критерии начала тестирования:
• готовность тестовой платформы (тестового стенда)
• законченность разработки требуемого функционала
• наличие всей необходимой документации
...

170. Планирование тестов Рекомендации по написанию Тест Плана

Критерии окончания тестирования:
результаты тестирования удовлетворяют критериям качества продукта:
• требования к количеству открытых багов выполнены
• выдержка определенного периода без изменения исходного кода приложения Code
Freeze (CF)
• выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
...

171.

Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у
вас на руках уже есть хороший черновик документа по планированию тестирования.
Далее, чтобы документ приобрел более менее серьезный вид, предлагаем дополнить
его следующими пунктами:
Окружение тестируемой системы (описание программно-аппаратных средств)
Необходимое для тестирования оборудование и программные средства
(тестовый стенд и его конфигурация, программы для автоматизированного
тестирования и т.д.)
Риски и пути их разрешения

172. Виды тест планов

Мастер Тест План (Master Plan or Master Test Plan)
Тест План (Test Plan), назовем его детальный тест план)
План Приемочных Испытаний (Product Acceptance Plan) - документ,
описывающий набор действий, связанных с приемочным тестированием
(стратегия, дата проведения, ответственные работники и т.д.)

173.

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест
план является более статичным в силу того, что содержит в себе высокоуровневую
(High Level) информацию, которая не подвержена частому изменению в процессе
тестирования и пересмотра требований. Сам же детальный тест план, который
содержит более конкретную информацию по стратегии, видам тестировании,
расписанию выполнения работ, является "живым" документом, который постоянно
претерпевает изменения, отражающие реальное положение дел на проекте.
В повседневной жизни на проекте может быть один Мастер Тест План и несколько
детальных тест планов, описывающих отдельные модули одного приложения.

174. Рецензия и Утверждение

Для увеличения ценности вашего тест плана рекомендуется
проводить его периодическое рецензирование со стороны участников
проектной группы. Это можно сделать просто договорившись между собой
или же реализовать в виде "процедуры утверждения". Как пример, приведем
список участников проектной группы, утверждение которых мы считаем
необходимым:
• Ведущий тестировщик
• Тест менеджер (менеджер по качеству)
• Руководитель разработки
• Менеджер Проекта
Каждый из перечисленных участников проекта, перед утверждением,
проведет рецензию и внесет свои комментарии и предложения, которые
помогут сделать Ваш тест план более полным и качественным.

175. Тестовый случай

176. Тестовый случай (Test Case)

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,
конкретных условий и параметров, необходимых для проверки реализации тестируемой
функции или её части.
• Под тест кейсом понимается структура вида:
Action > Expected Result > Test Result
Пример:

177. Виды Тестовых Случаев

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

178. Структура Тестовых Случаев (Test Case Structure)

Примерная структура тест кейсов.
Каждый тест кейс должен иметь 3 части:
• PreConditions
Список действий, которые приводят систему к
состоянию пригодному для проведения основной проверки. Либо
список условий, выполнение которых говорит о том, что система
находится в пригодном для проведения основного теста состояния.
• Test Case Description
Список действий, переводящих систему из
одного состояния в другое, для получения результата, на основании
которого можно сделать вывод о удовлетворении реализации,
поставленным требованиям
• PostConditions
Список действий, переводящих систему в
первоначальное состояние (состояние до проведения теста - initial
state).

179. Структура Тестовых Случаев (Test Case Structure)

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

180. Пример тест кейса:

do A1, verify B1
do A2, verify B2
do A3, verify B3
В приведенном примере конечная проверка - В3. Это
значит, что именно она является ключевой. Значит, A1 и А2
- это действия приводящие систему в тестопригодное
состояние. А В1 и В2 - условия того, что система находится
в состоянии пригодном для тестирования.

181. Таким образом

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

182.

Теперь ответим на вопрос: "Почему данное разбиение удобно
использовать?"
Ответ: конечная проверка одна, т.е. в случае если тест провален (test
failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся
проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), изза того, что функцию не возможно привести в тестопригодное состояние
(состояние пригодное для проведения тестирования), но это не значит,
что тестируемая функция не работает.

183. Детализация описания тест кейсов (Test Case Specification)

Specification)
Бытует много разных мнений об уровне детализации при
написании тест кейсов, а также количестве проверок в одном тест
кейсе. Все они по своему правильные. Уровень детализации тест
кейсов должен быть таков, чтобы обеспечивать разумное
соотношение времени прохождения к тестовому покрытию. Т.е. до
тех пор пока покрытие тестами определенного функционала не
меняется, можно уменьшать детализацию тест кейсов.

184.

185. Пример тест кейса 2:

Название: Проверка отображения страницы
Действие: Открыть страницу "Вход в систему"
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке
1 (и прилагаем изображение страницы "Вход в систему")
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое
потребуется для прохождения, будет разным
Второй пример будет даже нагляднее.
Решение о виде тест кейса и детализации его описания принимает
человек, ответственный за его создание - Тест Дизайнер или Тест Аналитик,
обладающий необходимым опытом, и который знает тест дизайн не по наслышке
и имеет опыт практического применения техник тест дизайна. Во многих
компаниях эта роль не выделяется отдельно, а доверяется обычным
тестировщикам , что в случае недостаточной квалификации может привести к
переписке тест кейсов.

186. Баг Репорт (Bug Report)

Баг или дефект репорт - это документ, описывающий ситуацию
или последовательность действий приведшую к некорректной работе
объекта тестирования, с указанием причин и ожидаемого результата.
Прочитав короткое описание бага (Bug Summary), должены понять в чем
состоит проблема, прочитав детальное описание бага (Bug Description)
должены знать строку кода, которую править.

187. Структура бага

Рекомендованный шаблон баг репорта.

188. Структура бага

189. Серьезность и Приоритет Дефекта

Серьезность (Severity) - это атрибут, характеризующий влияние
дефекта на работоспособность приложения.
Приоритет (Priority) - это атрибут, указывающий на очередность
выполнения задачи или устранения дефекта. Можно сказать, что это
инструмент менеджера по планированию работ. Чем выше приоритет,
тем быстрее нужно исправить дефект.

190. Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние,
в результате которого дальнейшая работа с тестируемой системой или
ее ключевыми функциями становится невозможна. Решение проблемы
необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес
логика, дыра в системе безопасности, проблема, приведшая к
временному падению сервера или приводящая в нерабочее состояние
некоторую часть системы, без возможности решения проблемы,
используя другие входные точки. Решение проблемы необходимо для
дальнейшей работы с ключевыми функциями тестируемой системой.

191. Градация Серьезности дефекта (Severity)

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает
некорректно. Ошибка не критична или есть возможность для работы с
тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой
части приложения, очевидная проблема пользовательского
интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо
воспроизводимая проблема, малозаметная посредствам
пользовательского интерфейса, проблема сторонних библиотек или
сервисов, проблема, не оказывающая никакого влияния на общее
качество продукта.

192. Градация Приоритета дефекта (Priority)

• P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие
является критической для проекта.
• P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но
требует обязательного решения.
• P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не
требует срочного решения.
• Порядок исправления ошибок по их приоритетам: High -> Medium ->
Low

193. Требования к количеству открытых багов

багов
Определение требований к количеству открытых багов:
• Наличие открытых дефектов P1, P2 и S1, S2, считается
неприемлемым для проекта. Все подобные ситуации требуют срочного
решения и идут под контроль к менеджерам проекта.
• Наличие строго ограниченного количества открытых ошибок P3 и S3,
S4, S5 не является критичным для проекта и допускается в
выдаваемом приложении. Количество же открытых ошибок зависит от
размера проекта и установленных критериев качества.
• Все требования к открытым ошибкам оговариваются и
документируются на этапе принятия решения о качестве
разрабатываемого продукта.

194. Написание баг репорта

• Баг репорт - это технический документ и в связи язык описания
проблемы должен быть техническим. Должна использоваться
правильная терминология при использовании названий
элементов пользовательского интерфейса (editbox, listbox,
combobox, link, text area, button, menu, popup menu, title bar,
system tray и т.д.), действий пользователя (click link, press the
button, select menu item и т.д.) и полученных результатах
(window is opened, error message is displayed, system crashed и
т.д.).

195. Написание баг репорта

Требования к обязательным полям баг репорта
Обязательными полями баг репорта являются:
• короткое описание (Bug Summary),
• серьезность (Severity),
• шаги к воспроизведению (Steps to reproduce),
• результат (Actual Result),
• ожидаемый результат (Expected Result)..

196. Написание баг репорта

Короткое описание
В одном предложении надо уместить смысл всего баг
репорта, а именно: коротко и ясно, используя правильную
терминологию сказать что и где не работает.
Например:
• Приложение зависает, при попытке сохранения
текстового файла размером больше 50Мб.
• Данные на форме "Профайл" не сохраняются после
нажатия кнопки "Сохранить".

197.

Принцип "Где? Что? Когда?"
Составьте предложение, в котором факты дефекта изложены в
следующей последовательности:
• Где?: В каком месте интерфейса пользователя или архитектуры
программного продукта находится проблема. Причем, начинайте
предложение с существительного, а не предлога.
• Что?: Что происходит или не происходит согласно спецификации или
вашему представлению о нормальной работе программного продукта.
При этом указывайте на наличие или отсутствие объекта проблемы, а
не на его содержание (его указывают в описании). Если содержание
проблемы варьируется, все известные варианты указываются в
описании.
• Когда?: В какой момент работы программного продукта, по
наступлению какого события или при каких условиях проблема
проявляется.

198.

Серьезность
Если проблема найдена в ключевой функциональности
приложения и после ее возникновения приложение
становится полностью недоступно, и дальнейшая работа с
ним невозможна, то она блокирующая. Обычно все
блокирующие проблемы находятся во время первичной
проверки новой версии продукта (Build Verification Test,
Smoke Test), т.к. их наличие не позволяет полноценно
проводить тестирование. Если же тестирование может быть
продолжено, то серьезность данного дефекта будет
критическая. На счет значительных, незначительных и
тривиальных ошибок вопрос достаточно прозрачный и не
требует лишних объяснений.

199.

Шаги к воспроизведению / Результат / Ожидаемый результат
Очень важно четко описать все шаги, с упоминаем всех вводимых данных
(имени пользователя, данных для заполнения формы) и промежуточных
результатов.
Например:
Шаги к воспроизведению
1. Войдите в системы: Пользователь Тестер1, пароль xxxXXX
--> Вход в систему осуществлен
2. Кликните линк Профайл
--> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было
сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени
пользователя сохранено.

200.

Основные ошибки при написании багов репортов
• Недостаточность предоставленных данных
Не всегда одна и таже проблема проявляется при всех вводимых значениях и
под любым вошедшим в систему пользователем, поэтому настоятельно
рекомендуется вносить все необходимые данные в баг репорт
• Определение серьезности
Очень часто происходит либо завышение, либо занижение серьезности
дефекта, что может привести к неправильной очередности при решении
проблемы.
• Язык описания
Часто при описании проблемы используются неправильная терминология
или сложные речевые обороты, которые могут ввести в заблуждение
человека, ответственного за решение проблемы.
• Отсутствие ожидаемого результата
В случаях, если вы не указали, что же должно быть требуемым поведением
системы, вы тратите время разработчика, на поиск данной информации, тем
самым замедляете исправления дефекта. Вы должны указать пункт в
требованиях, написанный тест кейс или же ваше личное мнение, если эта
ситуация не была документирована.

201.

Заполнение полей баг репорта
В описанной ниже таблице представлены основные поля баг репорта и
роль работника, ответственного за заполнение данного поля. Красным
цветом выделены обязательные для заполнения поля:

202. Жизненный цикл бага

Допустим
нашли
баг
и
зарегистрировали его в баг трекинг
системе. Согласно блок-схеме он
получит
статус
“Новый”.
Тестировщик,
ответственный
за
валидацию новых баг репортов, или
координатор проекта (в зависимости
от распределения ролей в команде)
может перевести его в один из
следующих статусов:
•“Отклонен”, если
данный баг
невалидный или повторный, или же
его просто не смогли воспроизвести
•“Отсрочен”, если данный баг не
нужно исправлять в данной итерации
•“Открыт”, если исправление бага
необходимо

203.

1. Отклонен. В этом случае можно либо поспорить о судьбе
багрепорта, изменив статус на “Переоткрыт” либо закрыть его статус “Закрыт”
2. Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус
“Открыт”, когда потребуется исправление либо в статус “Закрыт”,
если уже не потребуется.
3. Открыт. Именно в таком состоянии разработчик получает баг
репорт для исправления. Он может отклонить (дальнейшие действия
смотрите в пункте 1) или исправить баг. Баг репорт в статусе
“Исправлен” переводится на тестировщика для проверки. В случае
если проблема все еще воспроизводится, выставляется статус
“Переоткрыт” и баг репорт направляется назад на доработку к
разработчику. Если же исправление было успешным, то баг репорт
переводится в статус “Закрыт”.

204. Автоматизация разработки технической документации

205. целями автоматизации разработки являются:

• повышение управляемости жизненного
цикла техдокументации;
• снижение трудоемкости и ресурсоемкости
процессов жизненного цикла технической
документации.

206. Техническая документация: ее назначение

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

207. Техническая документация: состав

• В
серьезных
компаниях,
работающих
на
рынке автоматизированных систем, поставляемых
солидным заказчикам, в состав техдокументации
входят:
1. техническая документация на автоматизированные
системы;
2. техническая документация на изделия;
3. техдокументация на программные изделия программная документация.

208. Техническая документация: жизненный цикл

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

209. Техническая документация: типичная реализация жизненного цикла

210. Техническая документация: предпосылки к автоматизации процессов жизненного цикла

• доступность специализированных средств разработки
текстовых документов, построенных на основе концепции
единого источника (исходника - single source) с
возможностью многократного повторного использования
текстов, графики, мультимедиа, гиперссылок и т.д.;
• замечательные особенности советской нормативнотехнической документации.

211. Специализированные средства разработки технической документации

• Специализированных средств разработки технической (да
и любой документации) множество. Производятся таковые
как отечественными компаниями, так и зарубежными.
Можно рекомендовать к применению при разработке
(сопровождении и т.д.) техдокументации программы
AuthorIT от AuthorIT Software Corporation Ltd.

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

(картинка
заимствована с сайта компании-производителя):
Электронная техдокументация
хранится в едином централизованном
хранилище – в базе данных. AuthorIT
позволяет применять в качестве базы
данных как MS SQL, так и отдельные
файлы библиотек.
Библиотеки структурно подразделяются на
книги, книги на разделы и подразделы,
пункты и подпункты (топики) - до девяти
уровней вложенности. Собственно топики и
являются атомарными модулями данных или
элементами данных, если по ГОСТ Р 52292.
Топики (модули данных), инкапсулируя в
себе содержимое разделов и подразделов
книг, содержат также и служебную
информацию - шаблоны разметки. Каждому
модулю данных присваивается уникальный
код (ключ) согласно системы кодирования
или название (силами пользователя).

213.

Подсистема Authoring является средством создания, редактирования,
отображения (представления) и сохранения текстов электронной
техдокументации - мощным текстовым процессором. При сохранении
текстов электронной технической документации подсистема
автоматически формирует модули (элементы) данных (согласно
созданной пользователем структуры разделов документа) и сохраняет
указанные модули в базе данных или в файле библиотеки.
Подсистема Importer обеспечивает возможность импорта документов из
файлов различных форматов (включая *.doc и *.htm) с сохранением
структуры и содержания разделов документа во внутреннем формате
AuthorIT. Есть нюансы: попытка импорта неправильно
структурированного вордовского документа не пройдет. Особенно, если
такой файл содержит кучу OLE-объектов (ActiveX) и сложные
колонтитулы.
Подсистема Publisher обеспечивает возможность сборки документов из
модулей (элементов) данных внутреннего формата AuthorIT, публикации
технической документации в различных форматах help-файлов, а также в
формате MSWord. Вордовые файлы получаются замечательными никаких проблем с кириллицей и т.п. Важно только настроить шаблон это просто.

214.

Подсистема Project Manager обеспечивает возможность управления проектом
разработки (сопровождения и т.д.) техдокументации – организацией и
назначением задач конкретным пользователям, управления продуктом в
целом.
Подсистема Administration обеспечивает возможность управления базой
данных, управления правами пользователей.
Таким образом, AuthorIT обеспечивает возможность одновременной работы
многих пользователей с библиотекой. Права и полномочия пользователей
разделены на основе аутентификации и авторизации. Иными словами,
изменения, внесенные в библиотеку конкретным пользователем, автоматически
фиксируются с указанием имени пользователя, даты, времени и характера
внесенных им изменений.

215. Состав нормативно-технической документации

для создания любого вида АС перечень НТД должен включать в себя:
ГОСТ 34.601-90, регламентирующий стадии и этапы создания АС - описание
процессов в их хронологическом порядке;
ГОСТ 34.201-89, регламетирующий виды, комплектность и обозначения
(наименования) документов, разрабатываемых на стадиях и этапах
проведения работ по созданию АС;
РД 50-34.689-90, регламентирующий требования к содержанию документов на
АС;
ряд ГОСТ 2 (ЕСКД), регламентирующих требования к содержанию и
оформлению документов на изделия, входящие в состав АС;
ГОСТ 2.601-95, регламентирующий требования к эксплуатационной
документации на изделия, входящие в состав АС;
ряд ГОСТ 19-й системы (ЕСПД), регламентирующих требования к содержанию
и оформлению документов на программные изделия, входящие в состав АС;
ряд ГОСТов, по которым можно оценить качество технической
документации - ГОСТ 28195-89, ГОСТ 28806-90;
плюс ГОСТы (технические регламенты) предметной области.

216. Лекция 18«Стандарты разработки программных средств»

1. Документирование ПС.
2. Стандарты ЕСПД.
3. Гост 19.102-77 ЕСПД. Стадии
разработки программных средств.

217. Документирование ПС.

218. Классификация программной документации:

Программная
документация
(по отношению
к пользователю)
Внешняя
Внутренняя

219.

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

220. Получив задание на программирование, перед руководителем проекта встают вопросы:

• Что должно быть сделано, кроме
собственно программы?
• Что и как должно быть оформлено в
виде документации?
• Что передавать пользователям, а что
— службе сопровождения?
• Как управлять всем этим процессом?
• Что должно входить в само задание на
программирование?

221.

Единая система программной
документации (ЕСПД) — это
комплекс государственных
стандартов, устанавливающих
взаимоувязанные правила
разработки, оформления и
обращения программ и
программной документации.

222. В состав ЕСПД входят:

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

223. К числу основных недостатков ЕСПД можно отнести:

• ориентацию на единственную «каскадную» модель жизненного
цикла ПС;
• отсутствие четких рекомендаций по документированию
характеристик качества ПС;
• отсутствие системной увязки с другими действующими
отечественными системами стандартов по ЖЦ и
документированию продукции в целом, например ЕСКД;
• нечетко выраженный подход к документированию ПС как
товарной продукции;
• отсутствие рекомендаций по самодокументированию ПС,
например, в виде экранных меню и средств оперативной помощи
пользователю;
• отсутствие рекомендаций по составу, содержанию и
оформлению перспективных документов на ПС, согласованных с
рекомендациями международных и региональных стандартов.

224. ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС. До пересмотра всего

комплекса многие стандарты
могут с пользой применяться в
практике документирования
ПС.

225. Эта позиция основана на следующем:

• стандарты ЕСПД вносят элемент упорядочения в
процесс документирования ПС;
• предусмотренный стандартами ЕСПД состав
программных документов вовсе не такой «жесткий»,
как некоторым кажется: стандарты позволяют
вносить в комплект документации на ПС
дополнительные виды программных документов
(ПД), необходимых в конкретных проектах, и
исключать многие ПД;
• стандарты ЕСПД позволяют вдобавок мобильно
изменять структуры и содержание установленных
видов ПД исходя из требований заказчика и
пользователя.

226.

Стандарты
ЕСПД.

227. Стандарты ЕСПД подразделяют на группы:

Код группы Наименование группы
Общие положения
0
Основополагающие стандарты
1
Правила выполнения документации разработки
2
Правила выполнения документации изготовления
3
Правила выполнения документации сопровождения
4
Правила выполнения эксплуатационной
5
документации
6
7
8
9
Правила обращения программной документации
Резервные группы
Прочие стандарты

228. Обозначение стандарта ЕСПД должно состоять из:

числа 19 (присвоенных классу
стандартов ЕСПД);
одной цифры (после точки),
обозначающей код классификационной
группы стандартов, указанной в
таблице;
двузначного числа (после тире),
указывающего год регистрации
стандарта.

229. Третий учебный вопрос:

Гост 19.102-77 ЕСПД.
Стадии разработки
программных
средств.

230.

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

231.

Стадия
Этап работы
Содержание работ
разработки
I.
Техническое
задание
1) Обоснование
необходимости
разработки
программы
Постановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев эффективности и
качества разрабатываемой программы.
Обоснование необходимости проведения научноисследовательских работ.
2) Научноисследовательские
работы
Определение структуры входных и выходных данных.
Предварительный выбор методов решения задач.
Обоснование целесообразности применения ранее
разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения
поставленной задачи.
3) Разработка и
утверждение
технического
задания
Определение требований к программе.
Разработка технико-экономического обоснования
разработки программы.
Определение стадий, этапов и сроков разработки
программы и документации на неё.
Выбор языков программирования.
Определение необходимости проведения научноисследовательских работ на последующих стадиях.
Согласование и утверждение технического задания.

232.

Стадия
Этап работы
Содержание работ
разработки
1) Разработка
II.
Эскизный эскизного
проекта
проект
Предварительная разработка
структуры входных и выходных
данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма
решения задачи.
Разработка технико-экономического
обоснования.
2)
Утверждение
эскизного
проекта
Разработка пояснительной записки.
Согласование и утверждение эскизного
проекта.

233.

Стадия
разработки
Этап
работы
Содержание работ
III.
1) Разработка
Технический технического
проект
проекта
Уточнение структуры входных и выходных
данных.
Разработка алгоритма решения задачи.
Определение формы представления
входных и выходных данных.
Определение семантики и синтаксиса
языка.
Разработка структуры программы.
Окончательное определение конфигурации
технических средств.
2)
Утверждение
технического
проекта
Разработка плана мероприятий по
разработке и внедрению программ.
Разработка пояснительной записки.
Согласование и утверждение технического
проекта.

234.

Стадия
Этап работы
Содержание работ
1) Разработка
программы
Программирование и отладка программы
2) Разработка
программной
документации
Разработка программных документов в
соответствии с требованиями ГОСТ 19.
101-77
3) Испытания
программы
Разработка, согласование и утверждение
программы и методики испытаний.
Проведение предварительных
государственных, межведомственных,
приемо-сдаточных и других видов
испытаний.
Корректировка программы и программной
документации по результатам испытаний.
разработки
IV.
Рабочий
проект

235.

Стадия
Этап работы
Содержание работ
разработки
V.
1)
Подготовка и передача
Внедрение Подготовка программы и
и передача программной
программы
документации для
сопровождения и (или)
изготовление.
Передача программы в
фонд алгоритмов и
программ.

236.

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ
ФЕДЕРАЦИИ (ГОСТ ИСО/МЭК ТО 9294-93)
Информационная технология
РУКОВОДСТВО ПО УПРАВЛЕНИЮ
ДОКУМЕНТИРОВАНИЕМ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ

237. ОБЛАСТЬ ПРИМЕНЕНИЯ

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

238. ОПРЕДЕЛЕНИЯ

В настоящем стандарте применяют следующие термины.
документ – Уникально обозначенный блок
информации для использования человеком, такой как
отчет, спецификация, руководство или книга.
документация – Набор из одного или более связанных
документов.
программная продукция – Результат процесса
разработки программного обеспечения, т. е.
программное обеспечение, выпускаемое для
использования.

239. ФУНКЦИИ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

Для эффективного управления
документированием программного обеспечения,
важно осознавать различные функции,
выполняемые документацией.
Программную документацию можно рассматривать
как имеющую шесть основных функций:
1. информация для управления;
2. связь между задачами;
3. обеспечение качества;
4. инструкции и справки;
5. сопровождение программного
обеспечения ;
6. исторические справки.

240. ФУНКЦИИ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

1. Информация для управления
Во время разработки программного обеспечения администрации
необходимо оценивать ход работы, возникающие проблемы и
вероятности развития процесса. Периодические отчеты, согласно
которым проверяют ход работ по графику и представляют планы на
следующий период, обеспечивают контрольные механизмы и обзор
проекта.
2. Связь между задачами
Большинство проектов разработки программного обеспечения
разделяется на задачи, зачастую выполняемые различными группами:
специалисты в предметной области начинают проект;
аналитики формулируют требования к системе;
проектировщики разрабатывают системный и программный проекты;
специалисты по изданиям создают пользовательскую документацию в
соответствии со стратегией и стандартами по документированию;
специалисты по обеспечению качества и ревизоры оценивают общую
полноту и качество функционирования программного обеспечения;
сопровождающие программисты улучшают эксплуатируемое
программное обеспечение и разрабатывают его изменения или
расширения.

241. ФУНКЦИИ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

3. Обеспечение качества
Требуется документация разработки и документация продукции для
выполнения задач, связанных с обязанностями по обеспечению качества
программного обеспечения.
4. Инструкции и справки
Документация, требующаяся операторам, пользователям, руководителям
и другим заинтересованным лицам для того, чтобы понимать и
использовать программную продукцию.
5. Сопровождение программного обеспечения
Сопровождающим программистам требуется детальное описание
программного обеспечения, такое, чтобы они могли локализовать и
корректировать ошибки и модернизировать или изменять программное
обеспечение соответствующим образом.
6. Исторические справки
Документация, требуемая в качестве исторической справки по проекту.
Данная документация может помочь в переносе и переводе
программного обеспечения в новое окружение.

242. УСТАНОВЛЕНИЕ СТРАТЕГИИ ДОКУМЕНТИРОВАНИЯ

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

243. УСТАНОВЛЕНИЕ СТРАТЕГИИ ДОКУМЕНТИРОВАНИЯ

Стратегия должна поддерживать основные элементы
эффективного документирования:
1) требования документации охватывают весь жизненный
цикл программного обеспечения.
Документация требуется на ранних стадиях проекта и должна
быть доступна и сопровождаться на всем протяжении
процесса разработки программного обеспечения. После
завершения процесса разработки документация необходима
для использования, сопровождения, модернизации,
преобразования или передачи программного обеспечения;
2) документирование должно быть управляемым.
Управление и контроль требуются для получения и
сопровождения документации. Руководители и специалисты
по изданиям должны подготовить подробные планы,
охватывающие документирование продукции, графиков,
обязанностей, ресурсов, обеспечения качества и процедур
проверок;

244. УСТАНОВЛЕНИЕ СТРАТЕГИИ ДОКУМЕНТИРОВАНИЯ

3) документация должна соответствовать ее читательской
аудитории.
Читателями могут быть руководители, аналитики, специалисты по
экспертным системам, сопровождающие программисты, канцелярский
персонал и т. д. В зависимости от выполняемых задач им требуются
различные степени детализации и различное представление материала.
4) работы по документированию должны быть объединены в общий
процесс разработки программного обеспечения.
Процесс разработки должен быть определен;
5) должны быть определены и использованы стандарты по
документированию.
По возможности, должны быть приняты существующие стандарты.
Когда подходящие стандарты отсутствуют, должны быть разработаны
требуемые стандарты и руководства;
6) должны быть определены средства поддержки.
Должны быть использованы там, где это экономически целесообразно,
средства, помогающие разработке и сопровождению программной
продукции, включая документацию.

245. ОПРЕДЕЛЕНИЕ СТАНДАРТОВ И РУКОВОДСТВ ПО ДОКУМЕНТИРОВАНИЮ

Внутри организации должны быть приняты стандарты и руководства
для:
модели жизненного цикла программного обеспечения;
типов и взаимосвязей документов;
содержания документа;
качества документа;
форматов документа;
обозначения документа.
Данные стандарты и руководства будут определять, как следует
выполнять задачи документирования, и будут обеспечивать
критерии для оценки полноты, полезности и соответствия
программной документации, создаваемой в организации.
По возможности, должны быть приняты действующие
международные и национальные стандарты. Если подходящие
стандарты отсутствуют, то организация должна разработать
собственные.

246. ОПРЕДЕЛЕНИЕ СТАНДАРТОВ И РУКОВОДСТВ ПО ДОКУМЕНТИРОВАНИЮ

1. Выбор модели жизненного цикла программного обеспечения
Существует ряд моделей жизненного цикла программного
обеспечения с отличающейся терминологией для различных стадий.
С точки зрения программной документации, не имеет значения, какая
модель выбрана, до тех пор, пока стадии и соответствующая им
документация четко определены, спланированы и выполняемы для
любого конкретного программного проекта.
2. Определение типов и содержания документов
Программные документы можно представить разделенными на три
категории:
1) документация разработки;
2) документация продукции;
3) документация управления проектом.

247. Документация разработки

Разработка документов преследует пять целей:
1) они являются средством связи между всеми вовлеченными в
процесс разработки. Они описывают подробности решений,
принятых относительно требований к программному
обеспечению, проекту, программированию и тестированию;
2) они описывают обязанности группы разработки. Они
определяют, кто, что и когда делает, учитывая роль
программного обеспечения, предмета работ, документации,
персонала, обеспечивающего качество, и каждого вовлеченного
в процесс разработки;
3) они выступают как контрольные пункты, которые позволяют
руководителям оценивать ход разработки.;
4) они образуют основу документации сопровождения
программного обеспечения, требуемой сопровождающими
программистами как часть документации продукции;
5) они описывают историю разработки программного
обеспечения.

248. Документация разработки

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

249. Документация продукции

обеспечивает информацию, необходимую для
эксплуатации, сопровождения, модернизации, преобразования и
передачи программной продукции.
Документация - продукции преследует три цели:
1) она обеспечивает учебную и справочную информацию для любого
использующего или эксплуатирующего программную продукцию;
2) она облегчает программистам, не разрабатывавшим программное
обеспечение, его сопровождение и модернизацию;
3) она помогает продаже или приемке программной продукции.
Документация продукции должна включать в себя материалы для
следующих типов читателей: пользователей, которые вводят данные,
восстанавливают информацию и решают задачи с помощью
программного обеспечения; операторов, которые «прогоняют»
программное обеспечение на вычислительной системе;
сопровождающих программистов, которые сопровождают,
модернизируют или изменяют программное обеспечение.

250. Документация продукции

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

251. Документация управления проектом

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

252. Определение качества документов

Понятия качества, применимые к содержанию, структуре и
представлению документации:
1) качество содержания можно измерять в элементах
точности, полноты и ясности;
2) качество структуры можно измерять легкостью, с которой
читатель имеет возможность определить местоположение
информации;
3) качество представления должно соответствовать типу
проекта. Например, руководство пользователя может иметь
форму набора машинописных страниц, скрепленных вместе, или
может быть типографской книгой с обширными иллюстрациями,
созданной специалистом по графике.

253. Определение форматов документов

Стандартизованные форматы документов важны для
контроля качества документов, для читаемости
документов и для облегчения их сопровождения.
Форматы документов могут различаться от проекта к
проекту. Они зависят от таких факторов, как объем
проекта, аудитория, для которой предназначены
документы, количество установленных стадий и бюджет
документирования.
В проектируемых форматах должны быть учтены
соображения о том, будут ли документы переводить для
международного распространения.

254. Установление процедур документирования

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

255. Распределение ресурсов для документирования

Основными ресурсами, требуемыми для
документирования, являются следующие:
персонал;
средства;
финансирование.

256. Персонал

Для процесса разработки программного- обеспечения
необходимы люди со знанием:
программирования – для разработки программного
обеспечения;
сути предмета – для представления информации о
применениях программного обеспечения;
документирования – для разработки документации
продукции,

257. Персонал

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

258. Распределение ресурсов для документирования

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

259. Планирование документирования

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

260. Планирование документирования

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

261. Планирование документирования

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