Home

Автор: Екатерина Курач

Классификация ODC (Orthogonal Defect Classification — ортогональная классификация дефектов) — это метод, разработанный корпорацией IBM с целью сбора информации о типах неисправностей, которые имеют место в разрабатываемых программных системах. Этот метод полезен при сборе и анализе тестовой информации с тем, чтобы направить усилия совершенствования процесса разработки в нужном направлении. Можно воспользоваться стандартной классификацией, разработанной авторами ODC, в качестве основы для отбора тестовых случаев.

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

1. Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
2. Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
3. Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

В настоящее время наблюдается несколько методологий разработки тест кейсов. Они отличаются и теоретическим подходом, и практической реализацией.

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

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

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

Идея ODC заключается в разделении всех дефектов на типы. Когда программист исправляет дефект, то обычно он исправляет какой-то определенный тип дефекта. Тип определяется видом конечного исправления. Назначение типов является очевидным для программистов. В каждом случае различие проявляется в том, является ли источником ошибки пропущенная часть кода или неправильная часть кода. По методу ODC выделяются следующие типы дефектов:

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

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

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

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

Ошибки синхронизации/сериализации — это те ошибки, которые устраняются путем улучшенного управления распределенными ресурсами и ресурсами в реальном времени.

Ошибки билда/пакета/соединения описывают ошибки, которые случаются из-за ошибок в библиотеках, управлении изменениями или контроле версий.

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

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

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

Список дефектов и соотношение этих дефектов с любой стадией разработки

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

Матрица: виды дефектов/стадии процесса верификации

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

Другим основным понятием классификации ODC является понятие «триггеров отказов». Грубо говоря, триггер отказа — это условие, при котором ошибка проявляется. Например, когда продукт собран, предполагается, что все его функции протестированы. Однако, оказывается, что новые ошибки возникают при использовании продукта на другом тестовом окружении, при использовании других аппаратных средств. Таким образом, хоть тип дефекта и тот же самый, необходимо задействовать различные типа триггеров отказов для того, чтоб он проявился. При проявлении ошибки, триггер может быть определен инженером или кем-то, кто разбирается в проблемном диагнозе.

Вот список шести категорий причин отказов, распознаваемых методом ODC:

1. Рабочий объем/Повышенная нагрузка
2. Нормальный режим
3. Восстановление/Исключение
4. Пуск/Повторный пуск
5. Конфигурация аппаратных средств
6. Конфигурация программных средств.

Метод целенаправленной проверки использует несколько таких триггеров в качестве ориентиров для выбора тестовых случаев. Нам необходимо быть уверенными в том, что нам удалось построить тестовые случаи, которые позволяют задействовать каждый из этих триггеров дефектов. Некоторые из категорий, такие как Пуск или Нормальный режим, вряд ли удастся избежать. В то же время категория Исключение напоминает нам, что каждая исключительная ситуация на системном уровне должна быть покрыта тестовыми случаями. Слово Восстановление в названии этой категории также напоминает, что ожидаемые ситуации захвата исключительной ситуации должны быть четко описаны. Однако не всегда возможно продолжать выполнение операций в результате возникновения некоторых исключительных ситуаций, например таких как «File not found». Каждая хорошо спроектированная программа должна быть способной справиться с такой ситуацией.

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

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

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

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

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

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

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО "ТИД «ДС»", 2002.—432 с.
3. Официальный сайт Chillarege Inc: http://www.chillarege.com/index.html