Содержание
- 2. 1. 1 апреля - экзамен 2. 31 марта - консультация Информация!
- 3. Требования. Тестирование основанное на требованиях Лекция 3
- 4. Зачем тестировать документацию? Ошибки, допущенные на стадии сбора требований, составляют от 40 до 60% всех дефектов
- 5. Описание ожиданий заказчика в формализованном, документированном виде Определение требований к ПО
- 6. Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения) Нормативное обеспечение организации (регламенты, положения, уставы, приказы) Текущая
- 7. Вводы системы Выводы системы Функции системы Атрибуты системы Атрибуты системной среды Основные элементы для рассмотрения
- 8. Бизнес-требования Требования пользователей Системные требования Уровни требований
- 9. Виды требований Программные требования Ограничения разработки Функциональные требования Нефункциональные требования Уровни требований: Бизнес-требования Требования пользователей Системные
- 10. Функциональные и нефункциональные требования
- 11. Требования к продукту Организационные требования Внешние требования Нефункциональные требования
- 12. Количественные показатели нефункциональных требований
- 13. Introduction Purpose Document conventions Intended Audience and Reading Suggestions Project scope References Overall Description Product perspective
- 14. Спецификации Псевдокод Конечные автоматы Таблицы решений Диаграммы деятельности Таблицы сущность-связь Схемы потоков данных Формальные методы спецификации
- 15. UML диаграммы Схемы Mind map Мокапы Визуализация требований
- 16. Корректные требования Недвусмысленные требования Полнота набора требований Непротиворечивость набора требований Упорядоченность требований по их важности и
- 17. Явные и неявные требования Помните машину с непрозрачным лобовым стеклом и квадратными колесами?
- 18. Что если нет документации?
- 19. Код приложения Носители знаний Прототипы Тест-кейсы Авто-тесты Любая другая информация Что может помочь?
- 20. Интервью, опросы, анкетирование Мозговой штурм, семинар Наблюдение за производственной деятельностью, «фотографирование» рабочего дня Анализ нормативной документации
- 21. Требования неполные Частые изменения Требования изменяются в последний момент Не верно трактовали С какими проблемами мы
- 22. От требований к тестированию Пользовательские требования Технический дизайн и разработка пользовательского интерфейса Функциональные требования и модели
- 23. Тестирование, основанное на требованиях (Requirements Based Testing)
- 24. Тестирование должно быть своевременным Тестирование должно быть действенным Процесс тестирования должен быть эффективным Тестирование должно быть
- 25. просмотр на наличие неоднозначностей выведение причинно-следственных связей Фазы процесса тестирования, основанного на требованиях
- 26. “В случае попытки вскрытия, банкомат должен послать сигнал тревоги в отдел информационных технологий. Когда банкомат пытаются
- 27. “В случае попытки вскрытия, банкомат должен послать сигнал тревоги в отдел информационных технологий. Когда банкомат пытаются
- 28. просмотр на наличие неоднозначностей выведение причинно-следственных связей Причинно-следственные связи - это наши функциональные диаграммы, которые впоследствии
- 29. Тестовая документация
- 30. Этапы процесса тестирования
- 31. Этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с
- 32. План тестирования (Test Plan) Набор тест кейсов и тестов (Test Case & Test suite) Дефекты /
- 33. Это самая маленькая часть тест документации, это ситуация которая проверяет конкретно взятое условие из требований. Одно
- 34. Перевод продукта в нужное состояние Верификация того, что подлежит проверке Перевод продукта в исходное состояние Хороший
- 35. Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и т.д.). Декомпозиция требований\функций. Выявление всех условий,
- 36. Логические Test Case - составляются после разработки плана тестирования Низкоуровневые Test Case - пишутся при наличии
- 37. ID - номер кейса или номер вместе с какой-то абривиатурой к примему «PD_Sync_123» Summary - краткое
- 38. Пример Тест Кейса Проверка успешного входа в систему Администратора при условии что его логин и пароль
- 39. http://www.protesting.ru/testing/templates.html Еще пример
- 40. Группа связанных Test cases Тестовый набор (Test Suite)
- 41. Место хранения тестов, отметок о результатах прохождения тестов и дате проведения теста трассировка к требованию информация
- 42. Ошибки
- 43. Отчет об ошибке - это инструмент! Тестировщики производят отчеты об ошибках! Лучше всего вас запомнят по
- 44. Поднимает проблему и дает все необходимые данные для принятия решения Идеальный отчет об ошибке
- 45. Баг ваш или программиста?
- 46. Мотивация и случаи,когда баг исправляться не будет
- 47. Изменяйте свое поведение (изменяйте условия путем изменения своих действий) Изменяйте настройки программы Изменяйте программное и аппаратное
- 48. Баги не будут исправлены пока они не будут определены как критические или не будут демонстрировать новые
- 49. Методы тестирования. Диаграммы состояний и переходов
- 51. Диаграммы состояний и переходов (State-Transition Testing)
- 56. http://www.slideshare.net/DmytroProtsenko/ss-40217587 Ссылка на источник
- 57. На основе имеющейся спецификации подготовить: Список недочетов спецификации (лист Questions) Набор требований и фич приложения Набор
- 59. Скачать презентацию