Оценка программ в процессе тестирования

Оценка программ в процессе тестирования

Степень покрытия тестами - не то же самое, что высокое качество тестируемой системы. Чем выше степень покрытия, чем больше вероятность обнаружения скрытых дефектов. Когда мы говорим о результатах тестирования, мы должны подходить к их оценке, как оценке самой тестируемой системы.

Измерения являются инструментом анализа качества. Измерение результатов тестирования касается оценки качества получаемого продукта – программной системы.

Данные измерения могут базироваться на размере программ (например, в терминах количества строк кода или функциональных точек) или их структуре (например, с точки зрения оценки ее сложности в тех или иных архитектурных терминах). Структурные измерения могут также включать частоту обращений одних модулей программы к другим.

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

Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”.

• Плотность дефектов

Тестируемая программа может оцениваться на основе подсчета и классификации найденных дефектов.

Для каждого класса дефектов можно определить отношение между количеством соответствующих дефектов и размером программы (в терминах выбранных метрик оценки размера).

• Жизненный цикл тестов, оценка надежности

Статистические ожидания в отношении надежности программной могут использоваться для принятия решения о продолжении или прекращении (окончании) тестирования, исходя из заданных параметров приемлемого качества (например, плотности дефектов заданного класса).

• Модели роста надежности

Данные модели обеспечивают возможности прогнозирования надежности системы, базируясь на обнаруженных сбоях. Модели такого рода разбиваются на две группы – по количеству сбоев и времени между сбоями.

Оценка выполненных тестов

• Оценка выполненных тестов
• Оценка выполненных тестов
• Оценка выполненных тестов
• Оценка выполненных тестов

• Метрики покрытия/глубины тестирования

Критерии “адекватности” тестирования требуют систематического выполнения тестов для определенных набора элементов программы, задаваемых ее архитектурой или спецификацией. Соответствующие метрики позволяют оценить степень охвата характеристик системы (например, процент различных тестируемых параметров производительности) и глубину их детализации (например, случайное тестирование параметров производительности или с учетом граничных значений и т.п.). Такие метрики помогают прогнозировать вероятностное достижение заданных параметров качества системы.

• Введение искусственных дефектов

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

Данная техника должна использоваться с максимальной осторожностью опытными специалистами, хорошо представляющими общую архитектуру тестируемой программной системы и разбирающимеся во её внутренних связях

• Оценка мутаций

Получаемое в процессе тестирования мутаций отношение “убитых” к общему числу сгенерированных мутантов помогает измерить эффективность выполняемых тестов. В силу специфики такой техники тестирования, количественные оценки мутаций имеют практическое значение только для определенных типов систем.

Тестовые работы

Тестовые работы

• Планирование

Также как и другие аспекты управления проектами, работы по тестированию должно планироваться заранее. Как минимум, на уровне организации соответствующего процесса. Ключевые аспекты планирования тестовой деятельности включают:

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

• Генерация сценариев тестирования

Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования.

Тесты должны находиться под управлением системы конфигурационного управления и описывать ожидаемые результаты тестирования.

• Разработка тестового окружения

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

4. Выполнение тестов

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

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

Ряд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 1008-87.

• Анализ результатов тестирования

Для определения успешности тестов их результаты должны оцениваться и анализироваться.

Успешность тестирования подразумевает, что тестируемое программное обеспечение функционирует так, как ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не все такие последствия обязательно являются сбоями, они могут восприниматься как “помехи”.

Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те усилия, которые необходимы для анализа проблемы, отладки и устранения.

Это позволит в дальнейшем обеспечить б о льшую глубину измерений, а, соответственно, в перспективе, иметь возможность улучшения самого процесса тестирования.

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

• Отчёты о проблемах/журнал тестирования

В процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии контекста конфигурационного управления) и т.п.

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

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

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

Отчёты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения в рамках процессов конфигурационного управления

7. Отслеживание дефектов

Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками, присутствующими в тестируемой программной системе (также они могут быть следствием поведения операционного и/или тестового окружения). Такие дефекты должны анализироваться для определения момента и места первого появления данного дефекта в системе, какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования, некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые.

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