Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 21 Совместное конструирование 487 Изучив результаты 13 обзоров, специалисты AT&T обнаружили, что важ- ность собраний, посвященных обзору, была относительно невысокой: 90% дефектов разработчики находили при подготовке к собраниям и только около 10% во время самих собраний (Votta, 1991; Glass, 1999). Презентация Презентацией (dog-and-pony show) называют обзор, при котором система демон- стрируется заказчику. Такие обзоры — обычное дело при разработке ПО для пра- вительственных организаций, которые часто требуют выполнения обзоров тре- бований, проектов и кода. Цель презентации — показать заказчику, что работа продвигается успешно, так что это обзор, выполняемый руководителями, а не технический обзор. Не рассматривайте презентации как способ повышения технического качества продукции. Подготовка к ним может оказывать косвенное влияние на техниче- ское качество, но обычно при этом больше времени тратится на подготовку эф- фектных слайдов, а не на повышение качества ПО. Для повышения технического качества ПО используйте инспекции, анализ или чтение кода. 21.5. Сравнение методик совместного конструирования Каковы различия между разными методиками совместного конструирования? Основные характеристики каждой методики указаны в табл. 21-1. Табл. 21-1. Сравнение методик совместного конструирования Парное Формальная Неформальный Характеристика программирование инспекция обзор (анализ) Назначаются ли участникам Да Да Нет конкретные роли? Проводится ли формальное Возможно Да Нет обучение исполнению конкретных ролей? Кто «управляет» Разработчик, сидящий Координатор Обычно автор сотрудничеством? за клавиатурой Фокус сотрудничества Проектирование, коди- Только обнаруже- Разный рование, тестирование ние дефектов и исправление дефектов Сфокусирован ли обзор? Действия фокусируются Да Нет Направляются ли усилия неформально, если на поиск наиболее частых вообще фокусируются типов ошибок? Выполняется ли контроль Да Да Нет исправления найденных ошибок? Предоставляется ли отдель- Это второстепенный Да Это второсте- ным программистам подроб- фактор пенный фактор ная обратная связь для сокращения числа ошибок в будущем? ( см. след. стр.) 488 ЧАСТЬ V Усовершенствование кода Табл. 21-1. (окончание) Парное Формальная Неформальный Характеристика программирование инспекция обзор (анализ) Используется ли анализ Нет Да Нет результатов для повышения эффективности процесса? Полезна ли методика Возможно Да Да не на этапе конструиро- вания? Типичный процент 40–60% 45–70% 20–40% обнаруживаемых дефектов В отличие от формальных инспекций эффективность парного программирова- ния не подтверждена десятилетиями исследований, но первоначальные данные свидетельствуют о том, что оно примерно эквивалентно инспекциям; отзывы компаний, использующих парное программирование, также положительны. Если парное программирование и формальные инспекции примерно эквивален- тны по показателям качества итогового кода, стоимости и быстроты разработки, при выборе одной из этих двух методик можно руководствоваться личными пред- почтениями, а не техническими аспектами. Кому-то нравится работать в одиноч- ку, лишь иногда отказываясь от этого режима для проведения инспекционных собраний. Кто-то предпочитает сотрудничество с коллегами. Выбрать методику можно на основе предпочтений конкретных членов группы, а подгруппам мож- но позволить самим выбрать способ выполнения большей части работы. Можете комбинировать разные методики, если это целесообразно. Дополнительные ресурсы Ниже я указал ряд работ, посвященных методикам совмес- тного конструирования. Парное программирование Williams, Laurie and Robert Kessler. Pair Programming Illuminated. Boston, MA: Add- ison Wesley, 2002. В этой книге подробно рассматриваются все аспекты парного программирования, в том числе соответствие личностей (например, эксперт и новичок, интроверт и экстраверт) и другие вопросы реализации. Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison Wesley, 2000. Кент Бек вкратце рассматривает парное программирование и пока- зывает, как его улучшить, дополнив другими методиками, такими как определение стандартов кодирования, частая интеграция и регрессивное тестирование. Reifer, Donald. «How to Get the Most Out of Extreme Programming/Agile Methods», Pro- ceedings, XP/Agile Universe 2002. New York, NY: Springer; pp. 185–196. В этой статье обобщен опыт использования экстремального программирования и методик гибкой разработки, а также указаны условия успешности парного программирования. http://cc2e.com/2106 ГЛАВА 21 Совместное конструирование 489 Инспекции Wiegers, Karl. Peer Reviews in Software: A Practical Guide. Boston, MA: Addison Wesley, 2002. В этой книге подробно рассматриваются разные виды обзоров, в том числе формальные инспекции и менее формальные методики. Она основана на тщатель- ных исследованиях, имеет практическую направленность и легко читается. Gilb, Tom and Dorothy Graham. Software Inspection. Wokingham, England: Addison- Wesley, 1993. В этой книге подробно обсуждаются инспекции, выполнявшиеся в начале 1990-х. Она имеет практическую направленность и включает исследова- ния конкретных инспекционных программ, проводившихся в нескольких орга- низациях. Fagan, Michael E. «Design and Code Inspections to Reduce Errors in Program Develop- ment». IBM Systems Journal, 15, no. 3 (1976): 182–211. Fagan, Michael E. «Advances in Software Inspections». IEEE Transactions on Software Engineering, SE-12, no. 7 (July 1986): 744–51. Две этих статьи написаны разработ- чиком методики инспекций. В них вы найдете суть того, что нужно знать для проведения инспекций, в том числе описание всех стандартных форм инспекций. Соответствующие стандарты IEEE Std 1028-1997 — стандарт обзоров ПО. IEEE Std 730-2002 — стандарт планирования контроля качества ПО. Ключевые моменты 쐽 Как правило, методики совместной разработки позволяют находить больше дефектов, чем тестирование, и делать это более эффективно. 쐽 Методики совместной разработки и тестирование приводят к обнаружению разных типов ошибок, поэтому программа контроля качества ПО должна вклю- чать и обзоры, и тестирование. 쐽 Главными аспектами формальной инспекции, обеспечивающими максималь- ную эффективность обнаружения дефектов, являются использование конт- рольных списков, подготовка, назначение хорошо определенных ролей и по- стоянное улучшение процесса. Формальная инспекция — более эффективный способ обнаружения дефектов, чем анализ проекта или кода. 쐽 Парное программирование и инспекции примерно эквивалентны по показа- телям расходов и качества итогового кода. Парное программирование может оказаться особенно полезным, если вы хотите сократить срок разработки си- стемы. Некоторые разработчики предпочитают работать в паре, а не самосто- ятельно. 쐽 Формальные инспекции можно использовать для проверки не только кода, но и других результатов труда, таких как требования, проекты и тесты. 쐽 Анализ и чтение кода — альтернативы инспекциям. Чтение кода позволяет каждому участнику более эффективно использовать свое время. 490 ЧАСТЬ V Усовершенствование кода Г Л А В А 2 2 Тестирование, выполняемое разработчиками Содержание 쐽 22.1. Тестирование, выполняемое разработчиками, и качество ПО 쐽 22.2. Рекомендуемый подход к тестированию, выполня- емому разработчиками 쐽 22.3. Приемы тестирования 쐽 22.4. Типичные ошибки 쐽 22.5. Инструменты тестирования 쐽 22.6. Оптимизация процесса тестирования 쐽 22.7. Протоколы тестирования Связанные темы 쐽 Качество ПО: глава 20 쐽 Методики совместного конструирования: глава 21 쐽 Отладка: глава 23 쐽 Интеграция: глава 29 쐽 Предварительные условия конструирования: глава 3 Тестирование — самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих прило- жений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие — специализированные группы. Виды тестирования пе- речислены ниже. 쐽 Блочным тестированием называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы. 쐽 Тестирование компонента — это тестирование класса, пакета, небольшого при- ложения или другого элемента системы, разработанного несколькими програм- мистами или группами, выполняемое в изоляции от остальных частей системы. http://cc2e.com/2261 ГЛАВА 22 Тестирование, выполняемое разработчиками 491 쐽 Интеграционное тестирование — это совместное выполнение двух или бо- лее классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами. Этот вид тестирования обычно начинают про- водить, как только созданы два класса, которые можно протестировать, и про- должают до завершения работы над системой. 쐽 Регрессивным тестированием называют повторное выполнение тестов, направ- ленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов. 쐽 Тестирование системы — это выполнение ПО в его окончательной конфигу- рации, интегрированного с другими программными и аппаратными система- ми. Предметом тестирования в этом случае являются безопасность, произво- дительность, утечка ресурсов, проблемы синхронизации и прочие аспекты, которые невозможно протестировать на более низких уровнях интеграции. В этой главе «тестированием» я называю тестирование, выполняемое разработ- чиками, которое обычно включает три первых вида тестирования из приведен- ного списка, но иногда может включать также регрессивное тестирование и тес- тирование системы. Многие другие виды тестирования обычно выполняют не раз- работчики, а специализированный персонал: в качестве примеров можно приве- сти бета-тестирование, тестирование системы на предмет одобрения заказчиком, тестирование производительности, тестирование конфигурации, платформенное тестирование, тестирование в стрессовом режиме, тестирование удобства исполь- зования и т. д. Эти виды тестирования мы рассматривать не будем. Тестирование обычно разделяют на две обширных категории: «тестиро- вание методом черного ящика» и «тестирование методом белого (про- зрачного) ящика». В первом случае тестировщик не владеет сведениями о внутренней работе тестируемого элемента. Очевидно, что это не так, если вы тестируете собственный код. При тестировании методом белого ящика внутрен- няя реализация тестируемого элемента тестировщику известна. Тестируя собствен- ный код, вы используете именно этот вид тестирования. Оба вида имеют свои плюсы и минусы; в данной главе основное внимание уделяется тестированию методом белого ящика, потому что именно его выполняют сами разработчики. Порой термины «тестирование» и «отладка» используют взаимозаменяемо, но внимательные программисты различают два этих процесса. Тестирование — это средство обнаружения ошибок, тогда как отладка является средством поиска и устранения причин уже обнаруженных ошибок. Эта глава посвящена исключитель- но обнаружению ошибок. Об исправлении ошибок см. главу 23. Тема тестирования не ограничивается тестированием во время конструирования. Информацию о тестировании системы, тестировании в стрессовом режиме, тес- тировании методом черного ящика и других вопросах, ориентированных на спе- циалистов по тестированию, можно найти в работах, указанных в разделе «До- полнительные ресурсы» в конце главы. 492 ЧАСТЬ V Усовершенствование кода 22.1. Тестирование, выполняемое разработчиками, и качество ПО Тестирование — важная часть любой программы контроля качества, а зачастую и единственная. Это печально, так как разнообразные методики совместной разработки позволя- ют находить больше ошибок, чем тестирование, и в то же время обходятся более чем вдвое дешевле в расчете на одну обнаруженную ошибку (Card, 1987; Russell, 1991; Kaplan, 1995). Каждый из отдельных этапов тестирования (блочное тести- рование, тестирование компонентов и интеграционное тестирование) обычно позволяет найти менее 50% ошибок. Комбинация этапов тестирования часто при- водит к обнаружению менее 60% ошибок (Jones, 1998). Если у программиста спросить, какой из этапов разработ- ки ПО менее всего похож на другие, он наверняка ответит: «Тестирование». По ряду описанных ниже причин большин- ство разработчиков испытывают при тестировании затруд- нения. 쐽 Цель тестирования противоположна целям других эта- пов разработки. Его целью является нахождение ошибок. Успешным считается тест, нарушающий работу ПО. Все ос- тальные этапы разработки направлены на предотвращение ошибок и недопу- щение нарушения работы программы. 쐽 Тестирование никогда не доказывает отсутствия ошибок. Если вы тщательно протестировали программу и обнаружили тысячи ошибок, значит ли это, что вы нашли все ошибки или в программе все еще остались тысячи других оши- бок? Отсутствие ошибок может указывать как на безупречность программы, так и на неэффективность или неполноту тестов. 쐽 Тестирование не повышает качества ПО — оно указывает на качество програм- мы, но не влияет на него. Стремление повысить качество ПО за счет увеличе- ния объема тестирования подобно попытке снижения веса путем более час- того взвешивания. То, что вы ели, прежде чем встать на весы, определяет, сколько вы будете весить, а использованные вами методики разработки ПО определя- ют, сколько ошибок вы обнаружите при тестировании. Если вы хотите снизить вес, нет смысла покупать новые весы — измените вместо этого свой рацион. Если вы хотите улучшить ПО, вы должны не тестировать больше, а програм- мировать лучше. 쐽 Тестирование требует, чтобы вы рассчитывали найти ошибки в сво- ем коде. В противном случае вы, вероятно, на самом деле их не найдете, но это будет всего лишь самоисполняющимся пророчеством. Если вы за- пускаете программу в надежде, что она не содержит ошибок, их будет слиш- ком легко не заметить. В исследовании, которое уже стало классическим, Глен- форд Майерс попросил группу опытных программистов протестировать про- грамму, содержащую 15 известных дефектов. В среднем программисты нашли лишь 5 из 15 ошибок. Лучший программист обнаружил только 9. Главной при- чиной неэффективного обнаружения ошибок было недостаточно вниматель- Перекрестная ссылка Об обзо- рах ПО см. главу 21. Программы — не люди, а ошиб- ки — не микробы: программа не может нахвататься ошибок, об- щаясь с другими дефектными программами. Ошибки всегда допускают программисты. Харлан Миллз (Harlan Mills) ГЛАВА 22 Тестирование, выполняемое разработчиками 493 ное изучение ошибочных выходных данных. Ошибки были видны, но програм- мисты их не заметили (Myers, 1978). Вы должны надеяться обнаружить ошибки в своем коде. Это может казаться неес- тественным, но лучше уж найти свои ошибки самому, иначе вам на них укажет кто-то другой. Один из важнейших вопросов состоит в том, сколько времени разработчикам следует уделять тестированию в типичном проекте. Часто говорят, что на все те- стирование уходит 50% времени разработки системы, но это может ввести в за- блуждение. Во-первых, это число охватывает и тестирование, и отладку; само же тестирование занимает меньше времени. Во-вторых, это число отражает время, которое обычно тратят на тестирование, а не время, которое следует тратить. В-третьих, это число включает и тестирование, выполняемое разработчиками, и независимое тестирование. В зависимости от объема и сложности проекта тестированию, выполняемому разработчиками, вероятно, следует посвящать от 8 до 25% общего времени рабо- ты над проектом. Это согласуется с данными многих авторов (рис. 22-1). Рис. 22-1. По мере увеличения объема проекта тестирование, выполняемое разработчиками, отнимает все меньшую часть общего времени разработки. О влиянии размера программы на конструирование см. главу 27 Другой важный вопрос: что делать с результатами тестирования, выполняемого разработчиками? Прежде всего вы можете сразу использовать эти результаты для оценки надежности разрабатываемой системы. Даже если вы не исправляете де- фекты, обнаруженные при тестировании, оно характеризует надежность ПО. Кроме того, результаты тестирования позволяют определить необходимые исправления. Наконец, со временем регистрация дефектов, обнаруженных при тестировании, помогает определить наиболее частые типы ошибок. Вы можете использовать эту информацию для выбора и проведения подходящих обучающих курсов, при под- готовке будущих технических обзоров и разработке будущих тестов. Тестирование во время конструирования В большом мире тестирования тему этой главы — тестирование методом белого (или прозрачного) ящика — иногда игнорируют. Как правило, проектировать 494 ЧАСТЬ V Усовершенствование кода классы следует так, чтобы они казались черными ящиками: пользователь класса должен обращаться к нему через интерфейс, не зная о деталях внутреннего уст- ройства класса. Однако при тестировании класса с ним выгодно обращаться как с прозрачным ящиком, анализируя внутренний исходный код, а также входные и выходные данные класса. Зная, что происходит внутри ящика, вы можете проте- стировать класс более тщательно. Конечно, при тестировании класса вы будете рассматривать его код под тем же углом зрения, что и при написании, поэтому тестирование методом черного ящика также имеет достоинства. Во время конструирования вы обычно пишете метод или класс, проверяете его в уме, после чего выполняете его обзор или тестирование. Какой бы ни была ваша стратегия интеграционного тестирования или тестирования системы, вы долж- ны тщательно тестировать каждый блок до его объединения с другими блоками. Если вы пишете несколько методов, тестируйте их по одному за раз. На самом деле так их тестировать не легче — зато гораздо легче отлаживать. Если вы объедини- те несколько непротестированных методов и получите ошибку, вы не сможете определить, какой из методов в ней повинен. Если же вы добавляете в набор про- тестированных методов по одному методу за раз, при возникновении ошибки вы будете знать, что она содержится в добавленном методе или обусловлена взаимо- действием старых методов с новым. Это облегчит отладку. Методики совместного конструирования имеют много достоинств, не характер- ных для тестирования. Однако частично это объясняется тем, что тестирование часто выполняют не так хорошо, как было бы можно. Разработчик может выпол- нить сотни тестов и все же достигнуть лишь частичного покрытия кода тестами. Чувство хорошего покрытия кода тестами не означает, что покрытие на самом деле адекватно. Понимание базовых концепций тестирования может повысить его эффективность. 22.2. Рекомендуемый подход к тестированию, выполняемому разработчиками Систематичный подход к тестированию, выполняемому разработчиками, позво- ляет находить максимальное число дефектов всех типов при минимуме усилий. Поэтому соблюдайте все правила, указанные в следующем списке. 쐽 Тестируйте программу на предмет реализации каждого существенного требо- вания. Планируйте тесты для этого этапа на стадии выработки требований или как можно раньше — лучше всего до написания тестируемого блока. Подумайте о тестах, которые позволили бы выявить распространенные пробелы в требо- ваниях. Уровень безопасности, хранение данных, процедура установки и на- дежность системы — все эти области тестирования часто упускаются на этапе выработки требований. 쐽 Тестируйте программу на предмет реализации каждого значимого аспекта проектирования. Планируйте тесты для этого этапа на стадии проектирования или как можно раньше — до начала детального кодирования метода или клас- са, подлежащего тестированию. |