Методы тестирования. Требования. Тестирование основанное на требованиях

1. Методы тестирования

Лекция 3

2. Информация!

1. 1 апреля - экзамен
2. 31 марта - консультация

3. Требования. Тестирование основанное на требованиях

Лекция 3

4. Зачем тестировать документацию?

Ошибки, допущенные на стадии
сбора требований, составляют от
40 до 60% всех дефектов
проекта

5. Определение требований к ПО

Описание ожиданий заказчика в формализованном, документированном виде

6. Источники требований

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

7. Основные элементы для рассмотрения

1.
2.
3.
4.
5.
Вводы системы
Выводы системы
Функции системы
Атрибуты системы
Атрибуты системной среды

8. Уровни требований

1. Бизнес-требования
2. Требования пользователей
3. Системные требования

9.

Виды требований
Программные
требования
Ограничения
разработки
Функциональные
требования
Нефункциональные
требования
Уровни требований:
1. Бизнес-требования
2. Требования пользователей
3. Системные требования

10. Функциональные и нефункциональные требования

11. Нефункциональные требования

1. Требования к продукту
2. Организационные требования
3. Внешние требования

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

Скорость
Размер
Простота эксплуатации
Надежность
Устойчивость к сбоям
Переносимость

13. Структура SRS. IEEE Standard 830.http://habrahabr.ru/post/52681/

Introduction
o
Purpose
o
Document conventions
o
Intended Audience and Reading
Suggestions
o
Project scope
o
References
Overall Description
o
Product perspective
o
Product features
o
User classes and characteristics
o
Operating environment
o
Design and implementation
constraints
o
User documentation
o
Assumptions and dependencies
System features
o
System feature X (таких блоков
может быть несколько)
Description and
priority
Stimulus/Response
sequences
Functional
requirements
External interface requirements
o
User interfaces
o
Software interfaces
o
Hardware interfaces
o
Communication interfaces
Non functional requirements
o
Performance requirements
o
Safety requirements
o
Software quality attributes
o
Security requirements
Other requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues list

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

1.
2.
3.
4.
5.
6.
7.
Спецификации
Псевдокод
Конечные автоматы
Таблицы решений
Диаграммы деятельности
Таблицы сущность-связь
Схемы потоков данных

15. Визуализация требований

UML диаграммы
Схемы
Mind map
Мокапы

16. Критерии качества требований к ПО

1.
2.
3.
4.
5.
6.
7.
8.
9.
Корректные требования
Недвусмысленные требования
Полнота набора требований
Непротиворечивость набора требований
Упорядоченность требований по их важности и стабильности
Проверяемые требования
Модифицируемый набор требований
Трассируемые требования
Понимаемые требования

17. Явные и неявные требования

Помните машину с непрозрачным лобовым стеклом и квадратными колесами?

18. Что если нет документации?

19. Что может помочь?

Код приложения
Носители знаний
Прототипы
Тест-кейсы
Авто-тесты
Любая другая информация

20. Методы выявления требований

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

21. С какими проблемами мы сталкиваемся

Требования неполные
Частые изменения
Требования изменяются в последний момент
Не верно трактовали

22. От требований к тестированию

Пользовательские требования
Аналитик
Функциональные
требования и модели
анализа
Технический дизайн и
разработка
пользовательского
интерфейса
Тестировщик
Сравнение
Варианты тестирования
и сценарии
Сравнение
Процедуры
тестирования и
сценарии

23. Тестирование, основанное на требованиях (Requirements Based Testing)

24. Характеристики качественного процесса тестирования

1.
2.
3.
4.
Тестирование должно быть своевременным
Тестирование должно быть действенным
Процесс тестирования должен быть эффективным
Тестирование должно быть управляемым

25. Фазы процесса тестирования, основанного на требованиях

● просмотр на наличие неоднозначностей
● выведение причинно-следственных связей

26. Обзор на предмет неоднозначностей

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

27. Обзор на предмет неоднозначностей

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

28. Фазы процесса тестирования, основанного на требованиях

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

29. Тестовая документация

30. Этапы процесса тестирования

30

31. Тест дизайн (Test Design)

Этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в
соответствии с определёнными ранее критериями качества и целями тестирования

32. Типы тестовой документации

1. План тестирования (Test Plan)
2. Набор тест кейсов и тестов (Test Case & Test suite)
3. Дефекты / Баг Репорты (Bug Reports / Defects)
http://www.protesting.ru/testing/templates.html

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

Это самая маленькая часть тест документации, это ситуация которая проверяет
конкретно взятое условие из требований. Одно условие может проверятся
несколькими Тест Кейсами (позитивными и негативными)

34. Хороший Test Case состоит из

1. Перевод продукта в нужное состояние
2. Верификация того, что подлежит проверке
3. Перевод продукта в исходное состояние

35. Обнаруживаем тесты

● Тщательное изучение и анализ требований (описания функции, модуля,
спецификации, и т.д.).
● Декомпозиция требований\функций.
● Выявление всех условий, входных и выходных данных (что)
● Анализ поведения (как)
● Использование различных техник для выделения определенных тестов
● Использование накопленных знаний о выполненных проектах
(оттестированных продуктах)
● Интуиция
● Анализ\просмотр выявленных тестов и добавление новых

36. Логический и низкоуровневый

Логические Test Case - составляются после разработки плана тестирования
Низкоуровневые Test Case - пишутся при наличии или очень детальной спецификации
или когда уже можно проводить динамическое тестирование

37. Основные поля Тест Кейса

ID - номер кейса или номер вместе с какой-то абривиатурой к примему «PD_Sync_123»
Summary - краткое описание проблемы
Precondition - шаги перевода программы в нужное состояние
Steps (Actions) - шаги, для того чтобы востроизвести баг
Expected Result - ожидаемый результат
Pass/Fail - поле для проставления статуса каждому тест кейсу

38. Пример Тест Кейса

Проверка успешного входа в систему Администратора при условии что его
логин и пароль = 'Login' и '12345'

39. Еще пример

http://www.protesting.ru/testing/templates.html

40. Тестовый набор (Test Suite)

Группа связанных Test cases

41. Test Matrix

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

42. Ошибки

43. Отчеты об ошибках

Отчет об ошибке - это инструмент!
Тестировщики производят отчеты об ошибках!
Лучше всего вас запомнят по тем ошибкам, которые вы нашли!
Надо суметь “продать” найденную вами ошибку!

44. Идеальный отчет об ошибке

Поднимает проблему и дает все необходимые данные для принятия
решения

45. Баг ваш или программиста?

46. Мотивация и случаи,когда баг исправляться не будет

47. 3 типа дополнительного тестирования

1. Изменяйте свое поведение (изменяйте условия путем изменения своих действий)
2. Изменяйте настройки программы
3. Изменяйте программное и аппаратное окружение

48. Новый ли баг для этой версии?

Баги не будут исправлены пока они не будут определены как критические или не будут
демонстрировать новые проявления на исправленном коде

49. Методы тестирования. Диаграммы состояний и переходов

50.

51. Диаграммы состояний и переходов (State-Transition Testing)

52.

53.

54.

55.

56. Ссылка на источник

http://www.slideshare.net/DmytroProtsenko/ss-40217587

57. Задание 1

На основе имеющейся спецификации подготовить:
Список недочетов спецификации (лист Questions)
Набор требований и фич приложения
Набор тест-кейсов

58. Задание 2: тестирование инструмента в графич.приложении

Приложение рисует контуры на плоскости. Контуры можно складывать, вычитать,
объединять.
Реализован новый инструмент SPLIT – разрезает контур пополам. Пользователь задает
ширину разреза (допустимые значения 0,1 – 10 метров).
Нужно протестировать работу инструмента SPLIT. Допускается графическое оформление
части тест-кейсов (на ваше усмотрение).