Файл: Руководство по стилю программирования и конструированию по.pdf

ГЛАВА 22 Тестирование, выполняемое разработчиками
507
печать электронной таблицы, имеющей «максимальный размер», заявленный в рекламных материалах. В случае текстового процессора — сохранение докумен- та максимального рекомендованного размера. У нас максимальная нормальная конфигурация определяется максимальным нормальным числом сотрудников. Если бы оно равнялось 500, вы добавили бы в набор такой тест:
Номер теста
Описание теста
17
Группа из 500 сотрудников. Тестирование максимальной нормальной конфигурации.
Последний вид тестирования нормальных данных — тестирование совместимо- сти со старыми данными — вступает в игру при замене старого приложения или метода на новый вариант. При вводе старых данных новый метод должен выда- вать те же результаты, что и старый метод, за исключением тех ситуаций, в кото- рых старый метод работал ошибочно. Этот вид преемственности версий лежит в основе регрессивного тестирования, призванного гарантировать, что исправле- ния и улучшения поддерживают достигнутый уровень качества, не вызывая про- блем. В нашем примере критерий совместимости не добавил бы никаких тестов.
Используйте тесты, позволяющие
легко проверить результаты вручную
Допустим, вы пишете тест для проверки расчета зарплаты; вам нужно ввести зарпла- ту, и один из способов сделать это — ввести числа, которые попадаются под руку.
Попробуем:
1239078382346
Отлично. Это довольно большая зарплата — более триллиона долларов, но если ее
«обрезать», можно получить что-то более реалистичное: скажем, 90 783,82 доллара.
Теперь предположим, что этот тест успешен, т. е. указывает на ошибку. Как узнать,
что вы обнаружили ошибку? Ну, вы можете вычислить правильный результат вруч- ную и сравнить его с результатом, полученным на самом деле. Однако если в вы- числениях фигурируют такие неприятные числа, как 90 783,82 доллара, вероят- ность допустить ошибку в вычислениях не менее высока, чем вероятность обна- ружения ошибки в программе. С другой стороны, удобные круглые числа вроде
20 000 долларов делают вычисления сущим пустяком. Нули легко набирать, а ум- ножение на 2 большинство программистов способны выполнять в уме.
Возможно, вы считаете, что неудобные числа чаще приводят к обнаружению ошибок, но это не так: при использовании любого числа из одного и того же класса эквивалентности вероятность нахождения ошибки одинакова.
22.4. Типичные ошибки
Главная идея этого раздела в том, что для достижения максимальной эффективно- сти тестирования мы должны как можно больше знать о нашем враге — ошибках.

508
ЧАСТЬ V Усовершенствование кода
Какие классы содержат наибольшее число ошибок?
Естественно предположить, что дефекты распределяются по коду равно- мерно. Если код содержит в среднем 10 дефектов на 1000 строк, вы мог- ли бы ожидать, что класс из 100 строк будет иметь один дефект. Это ес- тественное предположение, но оно ошибочно.
Кейперс Джонс сообщает, что в результате принятой в IBM программы повыше- ния качества 31 из 425 классов системы IMS получил статус «подверженный ошиб- кам». Эти классы были исправлены или полностью разработаны заново, благода- ря чему менее чем через год частота обнаружения дефектов в IMS клиентами сни- зилась в 10 раз. Общие расходы на сопровождение системы снизились пример- но на 45%. Мнения клиентов о качестве системы изменились с «неприемлемо» на
«хорошо» (Jones, 2000).
Большинство ошибок обычно концентрируется в нескольких особенно дефект- ных методах. Типичные отношения между ошибками и кодом таковы:
쐽
80% ошибок содержится в 20% классов или методов проекта (Endres,
1975; Gremillion, 1984; Boehm, 1987b; Shull et al., 2002);
쐽
50% ошибок содержится в 5% классов проекта (Jones, 2000).
Эти отношения могут казаться не такими уж и важными, пока вы не узнаете не- сколько следствий. Во-первых, 20% методов проекта обусловливают 80% затрат на разработку (Boehm, 1987b). Это не значит, что 20% самых дорогих методов явля- ются одновременно и самыми дефектными, но такое совпадение настораживает.
Во-вторых, какой бы ни была точная доля расходов, приходящихся на разработку дефектных методов, эти методы очень дороги. В классичес- ком исследовании, проведенном в 1960-х, специалисты IBM проанали- зировали операционную систему OS/360 и обнаружили, что ошибки не были рас- пределены равномерно между всеми методами, а были сконцентрированы в не- скольких методах. Был сделан вывод, что эти методы — «самые дорогие сущнос- ти в программировании» (Jones, 1986a). Они содержали целых 50 дефектов на 1000
строк кода, а их исправление часто оказывалось в 10 раз дороже разработки всей системы (затраты включали поддержку пользователей и сопровождение системы на месте).
В-третьих, дорогие методы оказывают очевидное влияние на процесс разработки. Как гласит старая пословица, «вре- мя — деньги». Справедливо и обратное: «деньги — время»,
и, если вы можете исключить почти 80% затрат, избежав проблемных методов, вы можете сэкономить и много вре- мени. Это наглядно иллюстрирует Главный Закон Контро- ля Качества ПО: повышение качества сокращает сроки и снижает общую стоимость разработки системы.
В-четвертых, проблемные методы оказывают не менее очевидное влияние на со- провождение программы. При сопровождении программистам приходится сосре- доточиваться на идентификации методов, подверженных ошибкам, их перепро- ектировании и переписывании с нуля. В вышеупомянутом проекте IMS после за- мены дефектных классов производительность труда при разработке новых вер- сий IMS повысилась примерно на 15% (Jones, 2000).
Перекрестная ссылка Другим типом методов, часто содержа- щих много ошибок, являются слишком сложные методы. Об идентификации таких методов и их упрощении см. подраздел
«Общие принципы уменьшения сложности» раздела 19.6.

ГЛАВА 22 Тестирование, выполняемое разработчиками
509
Классификация ошибок
Некоторые ученые попытались классифицировать ошибки по типу и определить распространенность ошибок каждо- го типа. У каждого программиста есть свой список наибо- лее неприятных ошибок: ошибки занижения или завыше- ния на 1, невыполнение повторной инициализации переменной цикла и т. д.
В контрольных списках я указал и многие другие типы ошибок.
Борис Бейзер объединил данные нескольких исследований и пришел к исключи- тельно подробной классификации ошибок по распространенности (Beizer, 1990).
Вот резюме его результатов:
25,18%
Структурные ошибки
22,44%
Ошибки в данных
16,19%
Ошибки в реализации функциональности
9,88%
Ошибки конструирования
8,98%
Ошибки интеграции
8,12%
Ошибки в функциональных требованиях
2,76%
Ошибки в определении или выполнении тестов
1,74%
Системные ошибки, ошибки в архитектуре ПО
4,71%
Другие ошибки
Бейзер сообщил свои результаты с точностью до двух разрядов после запятой, но исследования типов ошибок в целом не позволяют сделать окончательный вывод.
Разные ученые сообщают о разных ошибках, а результаты исследований похожих типов ошибок иногда различаются на 50%, а не на сотые доли процента.
Из-за таких больших различий выполненное Бейзером объединение результатов ряда исследований, вероятно, не способно дать нам точной информации. Но даже если имеющиеся данные неокончательны, на их основе мы можем сделать несколь- ко общих выводов.
Большинство ошибок имеет довольно ограниченную область ви-
димости Одно исследование показало, что в 85% случаев исправление ошибки требовало изменения только одного метода (Endres, 1975).
Многие ошибки не связаны с конструированием Опрос 97 разработчиков позволил выяснить, что тремя наиболее частыми причинами ошибок были пло- хое знание прикладной области, изменения или конфликты требований, а также неэффективность общения и плохая координация действий разработчиков (Curtis,
Krasner, and Iscoe, 1988).
Как правило, ошибки конструирования лежат на со-
вести программистов В двух давнишних исследовани- ях было установлено, что из всех ошибок 95% были допу- щены программистами, причиной 2% было системное ПО
(компилятор и ОС), еще 2% — другое ПО, а оставшегося 1%
— оборудование (Brown and Sampson, 1973; Ostrand and
Weyuker, 1984). Системное ПО и инструменты разработки ис- пользуются сегодня гораздо шире, чем в 1970-х и 1980-х,
Перекрестная ссылка Список всех контрольных списков при- веден после содержания книги.
Если вы видите следы копыт,
думайте о лошадях, а не о зеб- рах. Скорее всего ОС работает нормально. С базой данных тоже, наверное, все в порядке.
Энди Хант и Дэйв Томас
(Andy Hunt and Dave Thomas)

510
ЧАСТЬ V Усовершенствование кода поэтому я думаю, что сегодня программисты несут ответственность за еще боль- ший процент ошибок.
На удивление распространенной причиной проблем являются
опечатки В одном исследовании было обнаружено, что 36% всех оши- бок конструирования были опечатками (Weiss, 1975). Исследование по- чти 3 000 000 строк приложения для расчета динамики полета, проведенное в 1987 г.,
показало, что опечатками были 18% всех ошибок (Card, 1987). В другом исследо- вании было установлено, что 4% всех ошибок были орфографическими ошибка- ми в сообщениях (Endres, 1975). В одной из моих программ коллега обнаружил ряд орфографических ошибок, просто проанализировав все строки исполняемо- го файла утилитой проверки орфографии. Внимание к деталям на самом деле важно. Если вы сомневаетесь в этом, учтите, что три самых дорогостоящих ошибки всех времен, приведших к убыткам объемом 1,6 миллиарда, 900 миллионов и 245
миллионов долларов, были вызваны изменением
одного символа в ранее коррек- тных программах (Weinberg, 1983).
Довольно часто причиной ошибок является неправильное понимание
проекта Компилятивное исследование Бейзера показало, что 16% ошибок было обусловлено неправильной интерпретацией проекта (Beizer, 1990). В другом ис- следовании было обнаружено, что неправильным пониманием проекта объясня- лось 19% ошибок (Weiss, 1975). Посвящайте анализу проекта столько времени,
сколько нужно. Это не обеспечивает немедленную выгоду (кому-то даже может показаться, что вы не работаете!), но в итоге окупается с избытком.
Большинство ошибок легко исправить Примерно в 85% случаев на исправ- ление ошибки требуется менее нескольких часов. Где-то в 15% случаев — от не- скольких часов до нескольких дней. И только около 1% ошибок требует больше- го времени (Weiss, 1975; Ostrand and Weyuker, 1984; Grady, 1992). Это подтвержда- ет и Барри Бом, заметивший, что на исправление около 20% ошибок уходит око- ло 80% ресурсов (Boehm, 1987b). Изо всех сил старайтесь избегать трудных оши- бок, выполняя предварительные обзоры требований и проектов. Исправляйте многочисленные мелкие ошибки так эффективно, как только можете.
Оценивайте опыт борьбы с ошибками в своей организации Разнообразие результатов, приведенных в этом подразделе, говорит о том, что каждая органи- зация имеет собственный, уникальный опыт борьбы с ошибками. Это осложняет использование опыта других организаций в ваших условиях. Некоторые резуль- таты противоречат интуиции; возможно, вам следует дополнить свои интуитив- ные представления другими средствами. Начните оценивать процесс разработки в своей организации, чтобы знать причины проблем.
Доля ошибок, обусловленных
неграмотным конструированием
Как и классификация ошибок, данные, соотносящие ошибки с разными этапами разработки, не окончательны. Но то, что с конструированием всегда связано боль- шое число ошибок, сомнений не вызывает. Иногда программисты утверждают, что ошибки конструирования дешевле исправлять, чем ошибки, допущенные при вы-