- •Лекция 18. Область знаний «ТЕСТИРОВАНИЕ ПО» SWEBOK
- •Источники литературы
- •Тестирование программных систем (в узком смысле)
- •Область знаний «Тестирование ПО»
- •Область знаний «Тестирование ПО»
- •Область знаний «Тестирование ПО»
- •1.Основы тестирования ПО
- •1.Основы тестирования ПО
- •1.1. Терминология тестирования
- •Англоязычная терминология – сложности перевода
- •Англоязычная терминология - 2
- •Англоязычная терминология – 3
- •Терминология тестирования - 2
- •Test Case (пример)
- •Test Case (окончание примера)
- •Test-Plan (пример)
- •Тестирование в узком и широком смысле
- •Верификация
- •Верификация и валидация
- •Верификация и валидация
- •1.Основы тестирования ПО
- •1.2.Ключевые вопросы
- •1.2.1 Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования
- •Основной вопрос тестирования
- •Когда завершать тестирование
- •1.2.2 Эффективность тестирования/Цели тестирования
- •1.2.3 Тестирование для идентификации дефектов
- •1.2.4Проблема оракула
- •1.2.5 Теоретические и практические ограничения тестирования
- •1.2.6 Проблема неосуществимых путей
- •1.2.7Тестируемость
- •1.Основы тестирования ПО
- •Отладка не является тестированием
- •1.3 Связь тестирования с другой деятельностью
- •Область знаний «Тестирование ПО»
- •2.Уровни тестирования
- •Тестирование в V-модели
- •2.1.1Модульное тестирование
- •2.1.2 Интеграционное тестирование
- •2.1.3 Системное тестирование
- •2.2. Цель тестирования
- •Цель, роль тестирования (более широкое определение).
- •Цели тестирования подробно:
- •2.2.1Приёмочное тестирование
- •2.2.2Установочное тестирование
- •2.2.3Альфа- и бета-тестирование
- •2.2.4 Функциональные тесты/тесты соответствия
- •2.2.5 Достижение и оценка надежности
- •2.2.6 Регрессионное тестирование
- •2.2.7 Тестирование производительности
- •2.2.8Нагрузочное тестирование
- •2.2.9 Сравнительное тестирование
- •2.2.10Восстановительные тесты
- •2.2.11 Конфигурационное тестирование
- •2.2.12 Тестирование удобства и простоты использования
- •2.2.13 Разработка, управляемая тестированием
- •Область знаний «Тестирование ПО»
- •3.Техники тестирования
- •Область знаний «Тестирование ПО»
- •4. Измерение результатов тестирования
- •4.1 Оценка программ в процессе тестирования
- •4.2.1 Метрики покрытия/глубины тестирования
- •Область знаний «Тестирование ПО»
- •5.Процесс тестирования
- •5.2Тестовые работы
- •5.2.1Планирование
- •5.2.2 Генерация сценариев тестирования
- •5.2.3 Разработка тестового окружения
- •5.2.4Выполнение тестов
- •5.2.5 Анализ результатов тестирования
- •5.2.6 Отчёты о проблемах/журнал тестирования
- •5.2.7 Отслеживание дефектов
- •Стандарты на тестирование программного обеспеченя
- •3.1.1 Специализированное тестирование
- •3.1.2Исследовательское
- •Источники литературы
- •3.2 Техники, базирующиеся на спецификации
- •3.2.2Анализ граничных значений
- •3.2.3Таблицы принятия решений
- •3.2.4 Тесты на основе конечного автомата
- •3.2.5 Тестирование на основе формальной спецификации
- •3.2.6 Случайное тестирование
- •3.3 Техники, ориентированные на код
- •3.3.1 Тесты, базирующиеся на блок-схеме
- •3.3.2 Тесты на основе потоков данных
- •3.3.3 Ссылочные модели для тестирования, ориентированного на код
- •3.4 Тестирование, ориентированное на дефекты
- •3.4.1 Предположение ошибок
- •3.4.2Тестирование
- •3.5 Техники, базирующиеся на условиях использования
- •3.5.1 Операционный профиль
- •3.5.2 Тестирование, базирующееся на надежности инженерного процесса
- •3.6 Техники, базирующиеся на природе приложения
- •3.7 Выбор и комбинация различных техник
- •3.7.1 Функциональное и структурное
- •3.7.1 Определенное или случайное
5.2.6 Отчёты о проблемах/журнал тестирования
•Во многих случаях, в процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии контекста конфигурационного управления) и т.п. Неожиданные или некорректные результаты тестов могут записываться в специальной подсистеме ведения отчетности по сбоям (problem-reporting system, обеспечивая формирование базы данных, используемой для отладки, устранения проблем и дальнейшего тестирования. Кроме того, аномалии (помехи), которые нельзя идентифицировать как сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения (change request) в рамках процессов конфигурационного управления (см. далее соответствующую область знаний “Software Configuration Management”).
5.2.7 Отслеживание дефектов
•Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками, присутствующими в тестируемой программной системе (также они могут быть следствием поведения операционного и/или тестового окружения). Такие дефекты могут (и, чаще всего, должны) анализироваться для определения момента и места первого появления данного дефекта в системе, какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования, некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые. Вся эта информация используется для определения того, как может быть улучшен сам процесс тестирования и насколько критична необходимость таких улучшений.
Стандарты на тестирование программного обеспеченя
• IEEE 829-1998 Standart for Software Test Documentation.
Описывает виды документов, служащих для подготовки тестов.
• IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing.
Описывает организацию модульного тестирования.
•ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 и ГОСТ Р-2000, также принят номером IEEE 1465-1998) Information
Technology. Software packages —
3.1.1 Специализированное тестирование
•Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.
•Данный вид тестирования может быть полезен для идентификации тех тестов, которые не охватываются рассматривавшимися выше более формализованными техниками.
3.1.2Исследовательское
тестирование
•Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение.
•Данный вид тестирования заранее не определяется в плане тестирования и такие тесты создаются, выполняются и модифицируются динамически, по мере необходимости.
•Эффективность исследовательских тестов напрямую зависит от знаний инженера, формируемых на основе поведения тестируемого продукта в процессе проведения тестирования, степени знакомства с приложением, платформой, типами возможных сбоев
идефектов, рисками, ассоциированными с
конкретным продуктом и т.п.
Источники литературы
•Орлик С. Программная инженерия. Тестирование программного обеспечения (на базе SWEBOK – 2004). http://www.sorlik.ru
•Орлов С. Технологии разработки программного обеспечения: Учебник/ — СПб.: Питер, 2002. — 464 с.: ил.
•Кулямин В. Технологии программирования. Компонентный подход – М.: Бином, 2007 г.
•Якобсон, Айвар; Буч, Грэди; Рамбо, Джеймс. Унифицированный процесс разработки программного обеспечения. СПб: Питер, 2002. 496 с.
3.2 Техники, базирующиеся на спецификации
3.2.1 Эквивалентное разделение <приложения>
•Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов эквивалентных классов (или наборов классов).
3.2.2Анализ граничных значений
•Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести (robustness testing) системы, проводимые с величинами, выходящими за рамки специфицированных пределов значений.
3.2.3Таблицы принятия решений
•Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями
(могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице.