Тестирование_Лекция№3

1. Тестирование программных продуктов

Лекция №3
Тестирование документации и
требований
1

2. Программная инженерия Ядро знаний SWEBOK

Программная инженерия – это область компьютерной науки и
технологии, которая занимается построением программных
систем, настолько больших и сложных, что для этого требуется
участие слаженных команд разработчиков различных
специальностей и квалификаций.
SWEBOK (software engineering body of knowledge) – основной
научно-технический документ по программной инженерии,
отображающий знания и накопленный опыт специалистов по
программной инженерии.
2

3. Ключевые вопросы программной инженерии

Охватывает 10 областей знаний SWEBOK:
1.
Software requirements – программные требования
2.
3.
Software design – дизайн (архитектура)
Software construction – конструирование программного обеспечения
4.
Software testing – тестирование
5.
Software maintenance – эксплуатация (поддержка) программного
обеспечения
Software configuration management – конфигурационное управление
Software engineering management – управление в программной
инженерии
Software engineering process – процессы программной инженерии
Software engineering tools and methods – инструменты и методы
Software quality – качество программного обеспечения
6.
7.
8.
9.
10.
3

4. Основные области знаний SWEBOK

4

5. Что такое «требование»

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

6. Важность требований

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

7. Важность требований

7

8. Типичный проект с плохими требованиями

8

9. Виды документации

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

10. Виды документации

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

11. Виды документации

Проектная документация
• Пользовательскую и сопроводительную
документацию, такую как встроенная помощь,
руководство по установке и использованию,
лицензионные соглашения;
• Маркетинговую документацию для продвижения
продукта на рынке.
11

12. Источники и пути выявления требований

12

13. Уровни и типы требований

13

14. Уровни и типы требований

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

15. Уровни и типы требований

Пользовательские требования описывают задачи, которые
пользователь может выполнять с помощью разрабатываемой
системы (реакцию системы на действия пользователя, сценарии
работы пользователя). Пользовательские требования
оформляются в виде вариантов использования (use cases),
пользовательских историй (user stories), пользовательских
сценариев (user scenarios).
•При первом входе пользователя в систему должно отображаться
лицензионное соглашение.
•Администратор должен иметь возможность просматривать список
всех пользователей, работающих в данный момент в системе.
•При первом сохранении новой статьи система должна выдавать
запрос на сохранение в виде черновика или публикацию.
15

16. Уровни и типы требований

Бизнес-правила описывают особенности принятых в предметной
области (и/или непосредственно у заказчика) процессов,
ограничений и иных правил. Эти правила могут относиться к
бизнес-процессам, правилам работы сотрудников, нюансам
работы ПО.
•Никакой документ, просмотренный посетителями сайта хотя бы один
раз, не может быть отредактирован или удалён.
•Публикация статьи возможна только после утверждения главным
редактором.
•Подключение к системе извне офиса запрещено в нерабочее время.
16

17. Уровни и типы требований

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

18. Уровни и типы требований

Функциональные требования описывают поведение системы,
т.е. её действия (вычисления, преобразования, проверки,
обработку и т.д.).
• В процессе инсталляции приложение должно проверять остаток
свободного места на целевом носителе.
• Система должна автоматически выполнять резервное копирование
данных ежедневно в указанный момент времени.
• Электронный адрес пользователя, вводимый при регистрации, должен
быть проверен на соответствие требованиям RFC822.
18

19. Уровни и типы требований

Нефункциональные требования описывают свойства системы
(удобство использования, безопасность, надёжность,
расширяемость и т.д.), которыми она должна обладать при
реализации своего поведения.
• При одновременной непрерывной работе с системой 1000
пользователей, минимальное время между возникновением сбоев должно
быть более или равно 100 часов.
• Ни при каких условиях общий объём используемой приложением памяти
не может превышать 2 ГБ.
• Размер шрифта для любой надписи на экране должен поддерживать
настройку в диапазоне от 5 до 15 пунктов.
19

20. Уровни и типы требований

Ограничения представляют собой факторы, ограничивающие
выбор способов и средств (в том числе инструментов) реализации
продукта.
• Все элементы интерфейса должны отображаться без прокрутки при
разрешениях экрана от 800x600 до 1920x1080.
• Не допускается использование Flash при реализации клиентской части
приложения.
• Приложение должно сохранять способность реализовывать функции с
уровнем важности «критический» при отсутствии у клиента
поддержки JavaScript.
20

21. Уровни и типы требований

Требования к интерфейсам описывают особенности
взаимодействия разрабатываемой системы с другими системами и
операционной средой.
• Обмен данными между клиентской и серверной частями приложения
при осуществлении фоновых AJAX-запросов должен быть реализован в
формате JSON.
• Протоколирование событий должно вестись в журнале событий
операционной системы.
21

22. Уровни и типы требований

Требования к данным описывают структуры данных (и сами
данные), являющиеся неотъемлемой частью разрабатываемой
системы. Часто сюда относят описание базы данных и
особенностей её использования.
• Все данные системы, за исключением пользовательских
документов, должны храниться в БД под управлением СУБД
MySQL
• Информация о кассовых транзакциях за текущий месяц должна
храниться в операционной таблице, а по завершении месяца
переноситься в архивную.
• Для ускорения операций поиска по тексту статей и обзоров
должны быть предусмотрены полнотекстовые индексы на
соответствующих полях таблиц.
22

23. Инженерия требований

Инженерия требований – процесс формулировки,
документирования и поддержки требований к ПО, а также
соответствующая область программной инженерии.
23

24. Составляющие инженерии требований

Извлечение информации из договоров;
Проведение собеседований;
Согласование с заказчиком.
24

25. Составляющие инженерии требований

Изучение потребностей и целей пользователей;
Требования к системе исполнения, аппаратуре
и ПО;
Устранение конфликтов между требованиями;
Определение приоритетов и принципов
взаимодействия с окружением.
25

26. Составляющие инженерии требований

Формальное описание требований;
Спецификация требований к структуре ПО,
функциям, качеству и документации;
Задание архитектуры и логики системы.
26

27. Составляющие инженерии требований

Проверка однозначности, непротиворечивости,
полноты и реализуемости требований.
27

28. Составляющие инженерии требований

Интеграция требований во все процессы ЖЦ;
Контроль реализации требований;
Необходимая корректировка требований.
28

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

Откуда берутся ошибки в требованиях:
1.Требования связаны между собой и с другими артефактами проекта – их
нельзя анализировать по одному, а приходится анализировать сразу
группу взаимосвязанных требований.
2.Требования часто относятся к нескольким функциональным областям
сразу – их трудно группировать.
3.Требования разнообразны по значимости (обязательность, риск,
важность, стабильность); традиционная группировка по функциям
оказывается неоднозначной.
4.Трудно отслеживать влияние изменившихся требований на другие.
5.Требования изменяются в процессе жизненного цикла создания ПО.
Снизить трудоемкость процесса и повысить качество управления
требованиями позволяют ПП (IBM Rational RequisitePro).
29

30. Инженерия требований

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

31.

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

32. Свойства качественных требований

32

33. Свойства качественных требований

Завершённость. Требование является полным и
законченным с точки зрения представления в нём всей
необходимой информации.
•Отсутствуют нефункциональные составляющие требования или
ссылки на соответствующие нефункциональные требования
(например: «пароли должны храниться в зашифрованном виде» — каков
алгоритм шифрования?).
• Указана лишь часть некоторого перечисления (например: «экспорт
осуществляется в форматы PDF, PNG и т.д.» — что мы должны
понимать под «и т.д.»?).
Способы обнаружения проблем: вопросы и использование
графического представления
Способы устранения проблем: получить недостающую информацию и
дописать её в требования.
33

34. Свойства качественных требований

Атомарность. Требование является атомарным, если его нельзя разбить
на отдельные требования без потери завершённости и оно описывает
одну и только одну ситуацию.
• В одном требовании, фактически, содержится несколько независимых
(например: «кнопка “Restart” не должна отображаться при остановленном
сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних
действиях пользователя»).
• Требование допускает разночтение в силу грамматических особенностей языка
(например: «если пользователь подтверждает заказ и редактирует заказ или
откладывает заказ, должен выдаваться запрос на оплату»).
Способы обнаружения проблем: Обдумывание, обсуждение с коллегами и
здравый смысл
Способы устранения проблем: Переработка и структурирование требований,
разбиение их на разделы, подразделы
34

35. Свойства качественных требований

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

36. Свойства качественных требований

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

37. Свойства качественных требований

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

38. Техники тестирования требований

Взаимный
просмотр
Вопросы
Тест-кейсы и
чек-листы
Прототипи рование
Исследование
поведения
системы
Рисунки

39. Техники тестирования требований

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

40. Техники тестирования требований

Вопросы. Если хоть что-то в требованиях вызывает непонимание
или подозрение нужно задать вопросы. Главное, чтобы вопрос был
сформулирован таким образом, чтобы полученный ответ позволил
улучшить требования.
Тест-кейсы и чек-листы. Хорошее требование является
проверяемым. Если можно быстро придумать несколько пунктов
чек-листа, это ещё не признак того, что с требованием всё хорошо
(например, оно может противоречить каким-то другим
требованиям). Но если никаких идей по тестированию требования
нет – это тревожный знак.
Исследование поведения системы. Здесь тестированию
подвергается, как правило, не одно требование, а целый набор.
Тестировщик мысленно моделирует процесс работы пользователя
с системой, созданной по тестируемым требованиям, и ищет
неоднозначные или вовсе неописанные варианты поведения
системы.

41. Техники тестирования требований

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

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

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

43. Техническое задание

Техническое задание (ТЗ) – основной документ,
содержащий требования заказчика к системе, в
соответствии с которыми осуществляется создание и
разработка конечного продукта.
Для чего нужно техническое задание?
Заказчику
- понять что ему необходимо;
- принять конечный продукт в соответствии с требованиями ТЗ.
Исполнителю
- понять и усвоить поставленную задачу;
- грамотно спланировать ресурсы;
- избежать излишней работы над проектом.
Конечному потребителю
- получить удовольствие от пользования качественным продуктом.

44. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

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

45. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

4. Требования к системе
5. Состав и содержание работ по созданию системы
выбор методологии, определяющий содержание стадий, этапов и фаз и
его конкретизацию для проекта (количество этапов и итераций, их
основное содержание).
6. Порядок контроля и приемки системы
распределяет роли Заказчика и Разработчика в подготовке системы к
испытаниям и проведению испытаний. Здесь уместно оговорить правила
проведения испытаний, сформулировать основные тестовые сценарии и
критерии приемки.
7. Требования к составу и содержанию работ по подготовке
объекта автоматизации к вводу системы в действие
проведения реинжиниринга предприятия, который необходимо
осуществить для того, чтобы добиться от внедрения АИС должного
эффекта

46. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

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

47. ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению 

ГОСТ 19.201-78 Техническое задание,
требования к содержанию и оформлению
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или
программному изделию;
5. Требования к программной
документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

48. IEEE 29148:2018  

IEEE 29148:2018
System Requirements Specification (SyRS) определяет
технические требования для выбранной системы и
удобства взаимодействия предполагаемой системы и
человека.
SyRS определяет высокоуровневые требования к
системе с точки зрения предметной области, а также
информацию об общей цели системы, ее целевой
среде и ограничениях, допущениях и
нефункциональных требованиях.
SyRS может включать в себя концептуальные модели,
спроектированные для иллюстрации содержания
системы, сценариев использования, основных
сущностей предметной области, данных, информаций и
рабочих процессов.

49. IEEE 29148:2018  

IEEE 29148:2018
1. Введение
- Назначение системы
- Содержание системы (границы системы)
- Обзор системы
- Термины и определения
2. Ссылки
3. Системные требования
- Функциональные требования
- Требования к юзабилити
- Требования к производительности
- Интерфейс (взаимодействие) системы
- Операции системы
- Состояния системы
- Физические характеристики
- Условия окружения
- Требования к безопасности
- Управление информацией
- Политики и правила
- Требования к обслуживанию системы на протяжении ее жизненного цикла
-Требования к упаковке, погрузке-разгрузки, доставке и транспортировке
4. Тестирование и проверка
5. Приложения

50. IEEE 29148-2018 

IEEE 29148-2018
SRS (Software Requirement Specification) –
спецификация для определенного
программного изделия, программы или набора
программ, которые выполняют определенные
функции в специфической среде.
SRS – специальная документация для ПО
которая содержит в себе информацию о том,
как должна себя вести система, какие функции
должна выполнять, какую нагрузку должна
выдерживать

51. IEEE 29148:2018  

IEEE 29148:2018
1. Введение
- Назначение
- Содержание (границы)
- Обзор продукта
- Взаимодействие продукта (с другими продуктами и компонентами)
- Функции продукта (краткое описание)
- Характеристики пользователей
- Ограничения
-Термины и определения
2. Ссылки
3. Детальные требования
- Требования к внешним интерфейсам
- Функции продукта
- Требования к юзабилити
- Требования к производительности
- Требования к логической структуре БД
- Ограничения проектирования
- Системные свойства ПО
-Дополнительные требования
4. Тестирование и проверка
5. Приложения

52. Документирование требований в MSF

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

53. Шаблон SRS в RUP

Введение.
1.1. Цель. Документ должен исчерпывающим образом описывать внешнее
поведение системы, а также нефункциональные требования и
ограничения.
1.2. Краткая сводка возможностей.
1.3. Определения, акронимы и сокращения.
1.4. Ссылки.
1.5. Краткое содержание.
Обзор системы
2.1. Обзор прецедентов. Содержит список имен и кратких описаний
вариантов использования и акторов с иллюстрациями в виде диаграмм
прецедентов.
2.2. Предположения и зависимости. Данная секция описывает ключевые
технические возможности, компоненты, подсистемы, связанные проекты,
которые могут влиять на жизнеспособность разрабатываемой системы

54. Шаблон SRS в RUP

Предположением (assumption) называется положение, которое считается
истинным при отсутствии доказательства или определяющей информации.
При определении зависимостей (dependencies) проекта от внешних
факторов, необходимо проанализировать, какие новые операционные
системы, регламенты бизнес-процессов, стандарты качества,
информационные системы могут появиться на предприятии внедрения и
как это может повлиять на функционирование изготовляемой АИС.
Описание требований
3.1. Описание вариантов использования. Параграф содержит описание
вариантов использования и связанных с ними нефункциональных
требований, либо ссылки на соответствующие артефакты.
3.2. Специальные требования. Параграф содержит описание
функциональных требований (не описанных в качестве вариантов
использования), а также описание нефункциональных требований общего
характера (не сопоставленных ни одному прецеденту в предыдущем
разделе), либо ссылки на соответствующие артефакты.