Презентации / Lecture06p

Тестирование ПО

Основы программной инженерии

Кулямин В.В., ВМК МГУ

Тестирование

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

• Software Engineering Body of Knowledge

https://www.computer.org/education/bodies-of-knowledge/software-engineering

•Под это определение подходят методы, о которых будет рассказано

•Важные детали

•Разновидность верификации

«… соответствие требованиям …»

• Разновидность динамического анализа

«… реального поведения системы …»

•Отличается от других видов динамического анализа (мониторинг, профилирование) использованием заранее выбранных ситуаций в тестах

За рамками определения

• Cem Kaner использует другое определение

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

•Подходят вообще все виды верификации и даже анализа, нет специфики (тесты?)

•Анализ – дает обычно числовые или качественные характеристики, над которыми часто нужно думать дальше

•Верификация – дает ответ «соответствует» или «не соответствует», может быть степень несоответствия, «существенно» или «незначительно»

•Он же часто утверждает, что явные требования необязательны

•Без явных требований замечание об ошибке чаще всего превращается в спор с разработчиками

•Даже в случае «подразумеваемых требований» их экспликация повышает качество результатов и сокращает трудоемкость дальнейшей работы

•Иногда «подразумеваемые требования» некорректны

•Для системных библиотек аварийное завершение работы или зацикливание может быть в рамках требований

За рамками определения

•Тестирование удобства использования

•Описать достаточно точно и полно требования к удобству использования крайне тяжело

•Поэтому для его проверки используется валидация

•Действия

•Выделяются «типичные» виды пользователей с некоторыми характеристиками

•Набираются соответствующие люди

•Они выполняют определенный набор задач с помощью системы, находясь под незаметным наблюдением

•Ошибками признаются ситуации, в которых человек не находит средств для решения задачи, решает ее неправильно (несмотря на объяснения и инструкции) или слишком медленно

Связанные понятия

•Тестируемая система (system under test, SUT) – система, работа которой проверяется

•Тест (test) – сценарий проверки, в рамках которого формируется одна из нужных ситуаций, связанных с работой SUT, и выполняется проверка корректности поведения SUT в ней

•Тест = ситуация + проверка

•Частая ошибка – тестом называют только саму ситуацию

•Тестовая ситуация – ситуация, создаваемая одним из тестов

•Тестовый набор (test suite) – множество тестов, совместно решающих одну из задач оценки качества или разработки

•Тестируемая реализация (implementation under test, IUT) – та часть SUT, свойства которой нас интересуют при тестировании, обычно совпадает с SUT, но не всегда (не может работать сама, отдельно от SUT)

•При отличии нужны специальные усилия, чтобы тестовые ситуации были связаны с работой IUT, а не других частей SUT

Связанные понятия

Составляющие тестовых ситуаций

В тестовую ситуацию входят

•Тестовое воздействие (test action) – вызываемая функция, выполняемая команда, действие пользователя или посылаемое сообщение

•Тестовые данные – данные воздействия: аргументы функции, опции команды, данные формы, значения полей сообщения

•Внутреннее состояние системы

•Обычно в тестах управляется за счет создания последовательности воздействий – тестовой последовательности (test sequence)

•Состояние окружения – значимая его часть, способная влиять на поведение системы

•Состояние планировщика процессов и часов, влияющее на работу параллельных компонентов системы

•Все остальные характеристики окружения, которые система отслеживает и использует в своей работе

Создание тестовых ситуаций – окружение

•Параллелизм

•Приводит к недетерминированному поведению

•Обычно в тестах управляется за счет использования нескольких тестовых последовательностей, подаваемых на разные интерфейсы, с синхронизацией отдельных воздействий в них (ч.у.м. тестовых воздействий)

Нет гарантий достижения произвольной ситуации

•Реже – с помощью инструментации кода – вставок разнообразных задержек между синхронизациями

Это часто дает более широкий набор ситуаций, но гарантий все равно нет

• Внешнее окружение

•Как можно больше стараются заменить программными заглушками, специальной конфигурацией БД и пр.

Вместо датчика температуры – программный модуль, выдающий нужные значения

•Важно получать только реалистичные состояния окружения, для этого иногда нужны специальные модели компонентов окружения

•Модели, заглушки и реальные компоненты интегрируются на специализированных тестовых стендах

Цели тестирования

Цели тестирования – для чего оно нужно в рамках более широкого процесса разработки

•Выявление ошибок

•Наиболее понятная цель, но если считать ее единственной – неясно

•Что делать, если ошибки не находятся после тщательной работы над тестами

•Когда останавливаться

Нужны точные процедуры проверки требований (аккуратная модель поведения)

•Оценка качества системы

•Если тестирование аккуратное и систематическое, даже если ошибок не найдено, получаем высокую оценку качества

•Останавливаться можно, когда доверие к полученной оценке достаточно высоко, т.е., проверен достаточно представительный набор разнообразных ситуаций

Набор тестов д.б. как можно более представителен, покрывать как можно большее разнообразие возможных поведений системы и его возможных аспектов

Нужен критерий полноты

•Обеспечение стабильного развития системы

•Редко вспоминается

•Хороший набор тестов, развиваясь вместе с системой, становится инструментом контроля ее развития, отслеживания важных изменений

Отчеты о результатах тестирования

• Информация о полноте

• Какая полнота достигнута по нескольким критериям

100% требований + 75% ветвлений в коде + 95% интерфейсных операций

• Информация об ошибках

• Тип ошибки: что вообще случилось

Аварийное завершение, зацикливание, некорректный результат, слишком много памяти, запись неверных данных в БД и пр.

•Что некорректно: какая проверка не прошла, какое требование нарушено

•Условия возникновения: в какой ситуации случилась

•Как можно более короткий и как можно более детерминированный сценарий, демонстрирующий ошибку

•Детерминизм предпочтителен, но из полностью детерминированного сценария на 50 шагов и демонстрирующего ошибку с вероятностью 25% на 5 шагов во многих случаях лучше второй