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

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

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

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

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

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

Вводы системы
Выводы системы
Функции системы
Атрибуты системы
Атрибуты системной среды
Основные элементы для рассмотрения

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

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

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

Требования к продукту
Организационные требования
Внешние требования
Нефункциональные требования

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

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

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

UML диаграммы
Схемы
Mind map
Мокапы
Визуализация требований

Корректные требования
Недвусмысленные требования
Полнота набора требований
Непротиворечивость набора требований
Упорядоченность требований по их важности и стабильности
Проверяемые требования
Модифицируемый набор требований
Трассируемые требования
Понимаемые требования
Критерии качества требований к ПО

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

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

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

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

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

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

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

Тестирование должно быть своевременным
Тестирование должно быть действенным
Процесс тестирования должен быть эффективным
Тестирование должно быть управляемым
Характеристики качественного процесса тестирования

просмотр на наличие неоднозначностей
выведение причинно-следственных связей
Фазы процесса тестирования, основанного на требованиях

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

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

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

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

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

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

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

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

Перевод продукта в нужное состояние
Верификация того, что подлежит проверке
Перевод продукта в исходное состояние
Хороший Test Case состоит из

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

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

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

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

http://www.protesting.ru/testing/templates.html
Еще пример

Группа связанных Test cases
Тестовый набор (Test Suite)

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

Ошибки

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

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

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

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

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

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

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

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

http://www.slideshare.net/DmytroProtsenko/ss-40217587
Ссылка на источник

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