Методы тестирования Лекция 3 1. 1 апреля —

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

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

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

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

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

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

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

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

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

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

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

Introduction Purpose Document conventions Intended Audience and Reading Suggestions Project scope References Overall Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План тестирования (Test Plan) Набор тест кейсов и тестов (Test Case & Test suite)

Это самая маленькая часть тест документации, это ситуация которая проверяет конкретно взятое условие

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

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

Логические Test Case - составляются после разработки плана тестирования Низкоуровневые Test Case - пишутся

ID - номер кейса или номер вместе с какой-то абривиатурой к примему «PD_Sync_123» Summary

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

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

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

Место хранения тестов, отметок о результатах прохождения тестов и дате проведения теста трассировка к

Отчет об ошибке - это инструмент! Тестировщики производят отчеты об ошибках! Лучше

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

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

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

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

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

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

Скачать презентацию Методы тестирования Лекция 3 1. 1 апреля —

Osnovy_testiroavnija._lekcija_5,_zadanija_4.pptx

Количество слайдов: 58

>Методы тестирования Лекция 3 Методы тестирования Лекция 3

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

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

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

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

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

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

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

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

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

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

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

>Introduction Purpose Document conventions Intended Audience and Reading Suggestions Project scope References Overall Description 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 Мокапы Визуализация требований UML диаграммы Схемы Mind map Мокапы Визуализация требований

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Ошибки Ошибки

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

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

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

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

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

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

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

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