Критерий оценки

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

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

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

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

Принцип 7. Критерий оценки. Самое важное свойство стратегии тестирования — это число обнаруженных ошибок как функция времени.

Функция обнаружения, то есть число ошибок в зависимости от времени fc (t), полезна по двум причинам — используя программную базу с известными ошибками, можно оценить стратегию, посмотрев, сколько ошибок база позволит обнаружить за данное время. Менеджеры проектов могут добавить fc (t) в модель надежности для оценки того, сколько еще ошибок осталось, и ответить на старый вопрос «Когда заканчивать тестирование?»

***

Мы старались не отходить от темы статьи: первый принцип говорит о том, что тестирование — это порождение неудач; последний — о количественном подтверждении этого общего соображения, что также лежит в основе всех других принципов. n

Бертран Мейер ([email protected]) — профессор программной инженерии Высшей политехнической школы (Цюрих, Швейцария) и главный архитектор компании Eiffel Software (Санта-Барбара, Калифорния).

Дата добавления: 2015-05-10