Содержание
- 2. Модульное тестирование Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на
- 3. Концепция модульных тестов Unit testing (юнит тестирование или модульное тестирование) — заключается в изолированной проверке каждого
- 4. Элементы unit тестирования Unit (Элемент) — наименьший компонент, который можно скомпилировать. Драйверы — модули тестов, которые
- 5. Заглушка (stub) Фиктивная подпрограмма, имитирующая одну или несколько функций отсутствующего модуля программного изделия. Обычно имеет точку
- 6. Изоляции в тестировании Идея изоляции является одной из центральных в модульном тестировании. Изоляция позволяет тестировать разрабатываемые
- 7. Мок обьекты Для изолирования используют паттерн Mock_Object (в виде заглушек, созданных вручную или автоматически генерируемых). Мок-объекты
- 8. Внедрение Мок объектов в код Базовые принципы, на которых основывается внедрение мок-объектов в тестовый код -
- 9. Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в
- 10. Техники реализации инверсии управления Фабричный метод (англ. Factory pattern) Service locator (англ. Service locator pattern) Внедрение
- 11. Пример инверсии управления Представьте себе, что имеется программа, которая получает некоторую информацию от пользователя с помощью
- 12. Если бы использовалась оконная система для похожей задачи, то необходимо было бы использовать элементы, которые работают
- 13. Фабричный метод Фабричный метод (англ. Factory Method) — порождающий шаблон проектирования, предоставляющий подклассам интерфейс для создания
- 14. Service locator Паттерн Service locator представляет собой хранилище сервисных объектов. Фактически это некоторого рода ассоциативный массив
- 15. Передача зависимого объекта через конструктор. Constructor Injection Инъекция с помощью конструктора использует конструктор для ассоциирования объекта
- 16. Setter Injection Инъекция при помощи set-метода требует определения отдельного set-метода для каждого из инъецируемых объектов. От
- 17. Interface Injection Interface injection использует интерфейсы для осуществления связывания объектов. Во-первых, задаются интерфейсы, которые определяют методы
- 18. Interface Injection Таким образом, сервисы сами внедряют себя в зависимый объект посредством установленного интерфейса: reader =
- 19. Пример выделения тестовых случаев. Система рассылки массовых информационных сообщений выпускникам факультета должна формировать список рассылки на
- 20. ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- 21. Тестовые требования Необходимо определить тестируемую область системы - указать часть проектной документации, исходных текстов, исполняемого кода,
- 22. Тестовые требования. Тестирование производится с точки зрения конечного пользователя, и разработанные тесты могут быть использованы для
- 23. Описание вариантов использования Описать роли пользователей в зависимости от уровня доступа и действий, которые они могут
- 24. Описание вариантов использования. Для более полного покрытия тестовых случаем рассмотрим диаграмму вариантов использования, которая представлена на
- 25. Рисунок 1 – Диаграмма вариантов использования программного обеспечения автоматизированной рассылки информационных сообщений выпускникам факультета. ГИБКИЕ ТЕХНОЛОГИИ
- 26. Объекты тестирования для каждой роли пользователя Содержит список тех объектов (Use-Case-ов, функциональных требований, нефункциональных требований), которые
- 27. Объекты тестирования для каждой роли пользователя. В результате проведенного анализа диаграммы вариантов использования были выделены следующие
- 28. Стратегия тестирования Главными вопросами тестовой стратегии являются техники тестирования, которые будут использоваться, и критерий, по которому
- 29. Стратегия тестирования Уровни тестирования: Системное, с точки зрения конечного пользователя для тестирования вариантов использования ПО. Стратегия
- 30. Разработка позитивных и негативных тестовых случаев (test case). Основное требование к контрольному примеру – описание проверки
- 31. Разработка контрольных примеров тестирования (test case). Тестовый случай (Test Case) описывает совокупность шагов, конкретных условий и
- 32. Контроль автоподстановки шаблонов – проверка автоматической замены шаблонов в теле сообщения на соответствующие значения из списка
- 33. Описание корректных и некорректных тестовых данных для каждого тестового случая. Тестовые случаи разделяются по ожидаемому результату
- 34. Описание корректных и некорректных тестовых данных для каждого контрольного примера тестирования. В таблице 1 представлен тестовый
- 35. ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- 36. Условия, при которых каждый тест кейс должен быть проверен. Каждый тест кейс должен иметь 3 части:
- 37. Критерии прекращения тестирования. Определить метрики измерения полноты тестируемого функционала системы: Тестовое Покрытие Детализация Тест Кейсов Время
- 38. Условия, при которых каждый тест кейс должен быть проверен. Позитивный тестовый случай для теста Проверка формирования
- 39. Позитивный тестовый случай для теста Контроль полового признака записи по окончанию фамилии
- 40. Позитивный тестовый случай для теста Контроль нормализации поля ФИО
- 41. Позитивный тестовый случай для теста Контроль разбиения электронных адресов
- 43. Скачать презентацию