6.3.5 Оценка посредством просмотра

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

Оценка посредством просмотра является методом оценки анонимной программы в терминах ее общего качества, ремонтопригодности, расширяемости, простоты эксплуатации и ясности. Цель данного метода — обеспечить программиста средствами самооценки. Выбирается программист, который должен выполнять обязанности администратора процесса. Администратор, в свою очередь, отбирает приблизительно 6—20 участников (6 — минимальное число для сохранения анонимности). Предполагается, что участники должны быть одного профиля (например, в одну группу не следует объединять программистов, использующих Кобол, и системных программистов, пишущих на Ассемблере). Каждого участника просят представить для рассмотрения две свои программы — наи­луч­шую (с его точки зрения) и низкого качества.

Отобранные программы случайным образом «распределяются между участниками. Им дается на рассмотрение по четыре программы. Две из них являются «наилучшими», а две — «наихудшими», но рецензенту не сообщают о том, какая про­грам­ма к какой группе относится. Каждый участник тратит на просмотр одной программы 30 мин и заполняет анкету для ее оценки. После просмотра всех четырех программ оценивается их относительное качество. В анкете для оценки проверяющему предлагается оценить программу по се­ми­балль­ной шкале (1 означает определенное «да», 7 — определенное «нет») при ответе, например, на следующие вопросы:

• Легко ли было понять программу?

• Оказались ли результаты проектирования высокого уровня очевидными и приемлемыми?

• Оказались ли результаты проектирования низкого уровня очевидными и приемлемыми?

• Легко ли для вас модифицировать эту программу?

• Испытывали бы вы чувство удовлетворения, написав такую программу?

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

6.4 Проектирование теста

Результаты психологических исследований, обсуждавшиеся в п. 6.2, показывают, что наибольшее внимание при тестировании программ уделяется проектированию или созданию эффективных тестов. Это связано с невозможностью «полного» тестирования программы, т.е. тест для любой программы будет обязательно неполным (иными словами, тестирование не может гарантировать отсутствия всех ошибок). Стратегия проектирования заключается в том, чтобы попытаться уменьшить эту «неполноту» настолько, насколько это возможно.

Если ввести ограничения на время, стоимость, машинное время и т.п., то ключевым вопросом тестирования становится сле­дую­щий:

Какое подмножество всех возможных тестов имеет наивысшую вероятность обнаружения большинства ошибок?

Изучение методологий проектирования тестов дает ответ на этот вопрос.

По-ви­ди­мо­му, наихудшей из всех методологий является тестирование со случайными входными значениями (стохастическое) — процесс тестирования программы путем случайного выбора некоторого подмножества из всех возможных входных величин. В терминах вероятности обнаружения большинства ошибок случайно выбранный набор тестов имеет малую вероятность быть оптимальным или близким к оп­ти­маль­но­му подмножеством. В настоящем разделе рассматривается несколько подходов, которые позволяют более разумно выбирать тестовые данные. В п. 6.2 бы­ло показано, что исчерпывающее тестирование по принципу черного или белого ящика в общем случае невозможно. Однако при этом отмечалось, что приемлемая стратегия тестирования может обладать элементами обоих подходов. Таковой является стратегия, излагаемая в этом разделе. Можно разработать довольно полный тест, используя определенную методологию проектирования, основанную на принципе черного ящика, а затем дополнить его проверкой логики программы (т.е. с привлечением методов белого ящика).

Методологии, обсуждаемые в настоящем разделе, представлены ниже:

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

Белый ящик Покрытие операторов Покрытие решений Покрытие условий Покрытие решений/условий Комбинаторное покрытие условий

Хотя перечисленные методы будут рассматриваться здесь по отдельности, при проектировании эффективного теста программы рекомендуется использовать если не все эти, то, по крайней мере, большинство из них, так как каждый из них имеет определенные достоинства и недостатки (например, возможность обнаруживать и пропускать различные типы ошибок). Правда, эти методы весьма трудоемки, поэтому некоторые специалисты, ознакомившись с ними, могут не согласиться с данной рекомендацией. Однако следует представлять себе, что тестирование программы — чрезвычайно сложная задача. Для иллюстрации этого приведем известное изречение: «Если вы думаете, что разработка и кодирование программы — вещь трудная, то вы еще ничего не видели».

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