Приложение D (справочное). Классификация признаков дефектов программного обеспечения

Приложение D
(справочное)

Классификация признаков дефектов программного обеспечения

D.1 Общие положения

Ортогональная классификация дефектов (ODC) - это метод, используемый для сбора и группировки информации о неисправностях программного обеспечения в терминах свойств дефектов программного обеспечения. Процесс ODC обеспечивает возможность выявления отличительных признаков дефектов и определения работоспособности процесса разработки программного обеспечения. Классификация основана на том, что известно о дефекте. Если неисправность или дефект обнаружены, то обычно известен и способ, которым дефект был обнаружен, и его влияние на пользователя. Таким образом, могут быть классифицированы особенности ODC, такие как действие, триггер и воздействие. Точно также, если неисправность диагностирована и устранена, детали восстановления известны. Могут быть классифицированы особенности ODC, такие как цель, тип, квалификатор, источник и возраст дефекта. Дополнительные особенности, не относящиеся к ODC, такие как плановый этап проекта (на котором был найден дефект), значимость и компонент, которые фиксируют в любой системе отслеживания неисправностей или дефектов, могут быть использованы вместе с анализом на основе ODC. ODC не навязывает конкретную структуру. Ниже сделано обобщение классификации особенностей дефектов программного обеспечения на открытие, закрытие и действия триггера.

D.2 Открытие

Открытие предназначено для классификации особенностей при обнаружении неисправности.

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

Таблица D.1 - Классификация особенностей дефектов программного обеспечения при обнаружении неисправности

Действия а по устранению неисправностей (при обнаружении)	Триггер b (обнаружения)	Воздействие c (влияние и значимость)
- Анализ проекта - Проверка кода - Тестирование модулей - Тестирование функций - Тестирование системы - Приемочные испытания - Квалификационные испытания - Испытания на повышение надежности	- Соответствие проекту - Совместимость - Параллельность - Охват - Последовательность - Взаимодействие - Конфигурация	- Возможность установки - Удобство обслуживания - Целостность/ безопасность/ защищенность - Безотказность - Обслуживание - Доступность - Удобство использования
Примечание 1 - Неисправности программного обеспечения часто трудно воспроизвести. Важно зафиксировать обстоятельства и условия, приводящие к неисправности. Примечание 2 - Требуется прослеживаемость требований; либо прослеживаемость требований к программному обеспечению, либо прослеживаемость конкретного тестового примера.
а Действия: фактические действия, выполняемые в момент обнаружения неисправности. b Триггер: среда или условие, которые должны существовать для появления неисправности. с Воздействие: для неисправностей разработки воздействие оценивают как возможное влияние и значимость для пользователя; для неисправностей, зарегистрированных в эксплуатации, воздействие - это последствие и значимость отказа для пользователя.

D.3 Закрытие

Закрытие предназначено для классификации особенностей устранения неисправности.

Когда неисправность устранена, то известны точный характер неисправности и объем необходимых исправлений. Типичные сведения о неисправностях, собираемые при устранении неисправности, приведены в таблице D.2.

Таблица D.2 - Классификация сведений о дефектах программного обеспечения при устранении неисправности

Цель a	Тип b	Квалификатор c	Возраст d	Источник e
Проект/код	Инициация Проверка Функция Синхронизация Интерфейс	Отсутствие Некорректность Несовместимость	Основной Новый Улучшенный	Разработано внутри компании Разработано при помощи аутсорсинга Повторно использован из библиотеки Портирован
а Цель: верхнеуровневая идентификация объекта исправления. b Тип: особенности фактической коррекции, которая была сделана. с Квалификатор: (применяется к типу дефекта): описывает элемент либо отсутствия, либо некорректности, либо ошибки, либо несовместимого выполнения. d Возраст: идентифицирует историю цели (проект/код), в которой обнаружен дефект. е Источник: определяет происхождение цели (проект/код), которая имела дефект.

D.4 Составление карты триггеров и действий

Составление карты действий и триггеров группирует применимые триггеры, относящиеся к деятельности, связанной с анализом контроля и тестированием проекта программного обеспечения. В таблицах D.3, D.4, D.5 и D.6 приведено несколько общих примеров составления карт действий и триггеров.

Таблица D.3 - Составление карты действий и триггеров для анализа проекта и контроля кодов

Действия

Триггеры

Анализ проекта/ контроля/ кодирования Пересмотр проекта или сравнение проектной документации с известными требованиями

Соответствие проекта Проверяющий инспектор обнаруживает неисправность, сравнивая проверяемый элемент проекта или сегмент кода с его спецификацией, установленной на предыдущем этапе. Проверка может охватывать проектную документацию, кодекс, практику разработки и стандарты, а также гарантировать, что требования проекта не будут пропущены или не будут неопределенными. Логика/поток Инспектор использует знание основных методов программирования и стандартов для изучения логики потока или данных, чтобы гарантировать их правильность и полноту. Обратная совместимость Инспектор использует обширный опыт работы с продуктом/компонентом для выявления несовместимости функции, описанной в проектной документации или кодах, и более ранними версиями того же продукта или компонента. С точки зрения эксплуатации приложение пользователя, которое успешно работало в предыдущем выпуске, отказывает в текущем выпуске Горизонтальная совместимость Инспектор, обладающий обширным опытом, обнаруживает несовместимость функции, описанной в проектной документации или кодах, и другими системами, продуктами, услугами, компонентами или модулями, с которыми функция должна взаимодействовать. Параллельность Инспектор рассматривает организацию серийного производства, необходимую для управления общим ресурсом при обнаружении неисправности. Это включает в себя организацию серийного выпуска большого количества функций, потоков, процессов или контекстов ядра, а также наложение и снятие блокировок. Внутренний документ Наличие неверной информации, несоответствий или неполноты во внутренней документации. Прологи, комментарии к коду и планы тестирования представляют собой некоторые примеры документации, которая подпадает под эту категорию Языковая зависимость Разработчик обнаруживает дефект при проверке специфических для языка деталей выполнения компонента или функции. Стандарты языка, проблемы компиляции и эффективность конкретных языков являются примерами проблемных областей Побочные эффекты Инспектор использует обширный опыт и знание продукта, чтобы предвидеть поведение какой-либо системы, продукта, функции или компонента, которое может возникнуть в результате рассматриваемого проекта или кода. Побочные эффекты характеризуют результат общего использования или конфигураций, в том числе за пределами области действия компонента или функции, с которыми связан рассматриваемый проект или код Редкая ситуация Инспектор использует обширный опыт и знание продукта, чтобы предвидеть некоторое поведение системы, которое не учитывается или не рассматривается в исследуемом документированном проекте или коде и обычно связано с необычными конфигурациями или использованием. Отсутствующее или неполное восстановление неисправностей, как правило, не классифицируют как триггер редкой ситуации, но, скорее всего, относят к соответствию конструкции, если неисправность обнаружена во время пересмотра/проверки

Таблица D.4 - Карты действий и триггеров для тестирования модулей

Действия

Триггеры

Тестирование модулей Тестирование белого ящика на основе детального знания внутренних компонентов кода

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

Таблица D.5 - Карты действий и триггеров для тестирования функций

Действия

Триггеры

Тестирование функций Выполнение тестирования черного ящика на основе внешних спецификаций функций

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

Таблица D.6 - Карты действий и триггеров для тестирования системы

Действия

Триггеры

Тестирование системы Тестирование или запуск полной версии системы в реальных условиях, требующих всех ресурсов

Рабочая нагрузка/повышенная нагрузка Система работает на некотором пределе ресурсов, верхнем или нижнем. Эти ограничения ресурсов могут быть созданы с помощью различных механизмов, включая выполнение малых или больших нагрузок, нескольких продуктов одновременно, работу системы в течение длительного периода времени. Восстановление/исключение Систему тестируют с целью активации обработчика исключений или какого-либо типа кода восстановления. Дефект не проявился бы, если бы не произошел какой-то более ранний вызов обработки исключений или восстановления. С точки зрения обнаружения дефектов в условиях эксплуатации этот триггер мог быть выбран, если бы был обнаружен дефект в способности системы или продукта быть восстановленным после отказа. Запуск/перезапуск Система или подсистема инициализировалась или перезапускалась после некоторого более раннего завершения работы или отказа системы в целом или подсистемы. Конфигурация аппаратных средств Систему тестируют для обеспечения корректного выполнения функций в определенных конфигурациях аппаратного обеспечения. Конфигурация программного обеспечения Систему тестируют для обеспечения корректного выполнения функций в определенных конфигурациях программного обеспечения. Блокированный тест (нормальный режим) Продукт работает хорошо в пределах ресурсов, а дефект обнаруживают при попытке выполнить сценарий тестирования системы. Этот триггер используют, когда сценарии не могут быть запущены из-за базовых проблем, которые препятствуют их выполнению. Этот триггер не должен быть использован для дефектов, обнаруженных заказчиком (потребителем)