2. Введение, документация
Тестируемые элементы
Тестируемые / нетестируемые функции
Подход, виды и принципы тестирования
Критерии прохождения тестов и/или
приостановки и возобновления работ
Необходимое оборудование, версия ПО, права
доступа
Необходимый персонал и обучение,
ответственность
Календарный план
Риск и непредвиденные обстоятельства
Утверждение
6. Просмотр, обзор (review)
Анализ объекта тестирования человеком
(тестировщиком, программистом,
заказчиком)
Статический анализ (static analysis)
Тестирование (анализ) с использованием
инструментов
7. Объект тестирования должен иметь
формальную структуру
Чаще всего используется программистами в
компонентном или интеграционном
тестировании
Позволяет обнаружить «аномалии» в
потоках данных
Должно выполняться перед review
8. Использование переменной без
присвоенного ей значения
Неиспользуемые переменные, части кода
Несоответствие стандартам языка
программирования (синтаксис)
Уязвимые места с точки зрения
безопасности
Несовместимость компонентов
9. Чаще всего направлен на анализ
документации (требований, дизайнов, тест-
планов)
Может использоватся на всех этапах
жизненного цикла разработки ПО
Зависит от квалификации и
«совместимости» инспекторов
12. Менеджер
Модератор
Автор
Инспектора
Секретарь
13. Качественное планирование
Четкое определение задачи
Нацеленность на улучшение документа
(объекта), а не критику автора
Предварительная подготовка (в т.ч.
дополнительное обучение)
Постоянное улучшение процесса, «работа
над ошибками»
Правильно подобранные инспектора
(reviewers)
14. Пользователя (консультанта, аналитика)
Тестировщика
Программиста
Службы поддержки (сопровождения)
Маркетинга
15. Статическое тестирование позволяет
обнаружить дефекты, которые являются
результатом ошибки и привести к сбоям в
программном обеспечении.
Динамическое тестирование позволяет
продемонстрировать непосредственно сбои
в программном обеспечении.
16. Dynamic testing Static testing
Покрытие, высокая Используется на ранних этапах
продуктивность разработки ПО
Возможность отлеживания Сокращение времени на
причины (debugging) разработку
Использование «реальных» Низкая стоимость как процесса
сценариев тестирования, так и исправлений
Editor's Notes
Баг-трекеры, статусы ошибок, жизненный цикл ошибок
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)
Анализ без выполненияОбъект должен иметь формальную структуруUML, проверка орфографии, HTML, XMLКомпиляторы, синтаксис, аномалии потока данных, управления потоком данных (например, используется переменная Х значение которой нигде не присваивается)