Оценка качества тестирования ПО. Часть 1: Введение

В следующую среду мне предстоит доклад на семинаре отдела. Есть интересная мне тема, но нет времени готовиться. Помимо семьи-ремонта-баш.орга еще и в блог хочется писать. Так будем же совмещать приятное с полезным, благо тематика позволяет. Попробую из промежуточных результатов подготовки сделать несколько заметок на тему оценки качества тестирования ПО. Если не справлюсь — хоть будет стыдно перед вами, уважаемые читатели. Если справлюсь — тоже будет, потому что занудность темы для стороннего наблюдателя — выше среднего. И все-таки очень надеюсь на ваши комментарии.
Как сказал на одном из концертов Олег Медведев, «ну что ж, приступим, помолясь».


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

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

Для решения первой задачи требуется набор тестов. Каждый тест представляет собой вариант взаимодействия с тестируемой системой с проверкой корректности поведения системы. Способ взаимодействия определяется интерфейсом системы, например:

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

В любом случае, придется решать две основные задачи — выбор тестовых данных и анализ корректности поведения системы. Ладно, худо-бедно — с этой задачей вы справились. Переходим ко второй проблеме — как убедить заказчика, что вы свой бутерброд с икрой заработали?

Идеальный случай — проверены все варианты взаимодействия (полное или исчерпывающее тестирование) — на то и идеальный, чтобы не встречаться в действительности. Уж очень этих вариантов много. Значит, придется выбирать, искать компромисс между трудоемкостью тестирования и качеством результата. На этом этапе все соглашаются с тем, что искать ошибки с помощью тестирования можно, но гарантировать отсутствие ошибок — увы, нельзя.

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

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

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

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

В следующий раз будем рассматривать и классифицировать существующие критерии покрытия.

06.11.2007  Метки:   Рубрики: Разработка, Тестирование

Один комментарий

  1. Оценка качества тестирования ПО. Часть 2: Классификация критериев тестового покрытия » софт, хард и интERнет - 10.11.2007

    […] Предыдущая часть закончилась выводом о необходимости использования метрик для оценки качества тестирования и обещанием классифицировать используемые метрики (они же — критерии тестового покрытия). Обещания надо выполнять. Майерс безусловно прав, определяя тестирование, как процесс исполнения программы с целью обнаружения ошибок [1]. Хотя с моей точки зрения, позитивные определения тоже имеют право на существование, при попытке их проверки “от противного” как раз и получается определение Майерса. […]

Написать комментарий