Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 [169] 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

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

Ниже приведены некоторые мои выводы.

В небольших проектах дефекты конструирования составляют большинство всех ошибок В одном исследовании ошибок кодирования, допущенных в небольшом проекте (1000 строк кода), было обнаружено, что 75% дефектов пришлось на этап кодирования, тогда как на этап выработки требований - 10%, а на этап проектирования - 15% Qs, 198ба). По-видимому, такое распределение ошибок характерно для многих небольших проектов.

Дефекты конструирования составляют минимум 35% всех дефектов независимо от размера проекта. В крупных проектах доля дефектов конструирования не так велика, как в небольших, но и тогда она равна минимум 35% (Beizer, 1990; Jones, 2000). Некоторые ученые сообщают, что даже в очень крупных проектах дефектами конструирования являются около 75% всех ошибок (Grady, 1987). Обычно чем лучше разработчики знают прикладную область, тем лучше они проектируют общую архитектуру системы. В этом случае на детальное проектирование и кодирование приходится еще больший процент ошибок (Basili and Perricone, 1984).

Хотя ошибки конструирования и дешевле исправлять, чем ошибки выработки требований и проектирования, это все равно дорого. Исследование двух очень крупных проектов, проведенное в Hewlett-Packard, показало, что стоимость исправления среднего дефекта конструирования составляла 25-50% от стоимости исправления средней ошибки проектирования (Grady, 1987). При учете большего числа дефектов конструирования общая стоимость их исправления могла вдвое превышать стоимость исправления дефектов проектирования.

Вот примерное отношение между объемом проекта и распределением ошибок (рис. 22-2):

100%

Процент ошибок, соответствующий каждому этапу


Выработка требований

В некоторых проектах этот процент ошибок также может приходиться на этап конструирования

128К

512К

Объем проекта в ароках кода

Рис. 22-2. По мере увеличения объема проекта доля ошибок, допускаемых во время конструирования, снижается. Тем не менее ошибки конструирования составляют 45-7596 всех ошибок даже в самых крупных проектах



Сколько ошибок можно ожидать?

Ожидаемое число ошибок зависит от качества вашего процесса разработки. Вот некоторые соображения по этому поводу

Средний для отрасли показатель таков: примерно 1 -25 ошибок на 1000 JJUfl строк кода в готовом ПО, разрабатывавшегося с использованием разных методик (Boehm, 1981; Gremillion, 1984; Yourdon, 1989а; Jones, 1998; Jones, 2000; Weber, 2003). Проекты, в которых обнаруживается 0,1 от указанного числа ошибок, редки; о случаях, когда ошибок в 10 раз больше, предпочитают не сообщать (вероятно, такие проекты даже не доводят до конца!).

Отделение прикладного ПО компании Microsoft сообщает о таких показателях, как 10-20 дефектов на 1000 строк кода во время внутреннего тестирования и 0,5 дефекта на 1000 строк кода в готовой продукции (Moore, 1992). Для достижения этого уровня применяется комбинация методик чтения кода, описанных в разделе 21.4, и независимого тестирования.

Харлан Миллз придумал «разработку методом чистой комнаты» - методику, позволяющую достигнуть всего лишь 3 дефектов на 1000 строк кода во время внутреннего тестирования и 0,1 дефекта на 1000 строк кода в готовой системе (Cobb and Mills, 1990). В нескольких проектах - например, в проекте разработки ПО для космических кораблей - благодаря сочетанию методик формальной разработки, обзоров кода коллегами и статистического тестирования был достигнут такой уровень, как О дефектов на 500 ООО строк кода (Fishman, 1996).

Уотте Хамфри (Watts Humphrey) сообщает, что группы, применяющие методику Team Software Process (TSP), достигают уровня 0,06 дефекта на 1000 строк кода. Главный аспект TSP - обучение разработчиков изначальному предотвращению дефектов (Weber, 2003).

Результаты проектов TSP и проектов «чистой комнаты» подтверждают Jflf 1 другую версию Главного Закона Контроля Качества ПО: дешевле сразу создать высококачественную программу, чем создать низкокачественную

программу и исправлять ее. Производительность труда в случае одного полностью проверенного проекта из 80 ООО строк, разработанного методом «чистой комнаты», оказалась равной 740 строкам кода на человеко-месяц. В то же время средняя для отрасли скорость разработки полностью проверенного кода, учитывающая все затраты, не связанные с кодированием, близка к 250-300 строкам на человеко-месяц (Cusumano et al., 2003). Экономия затрат и повышение производительности труда при использовании методик TSP или «чистой комнаты» объясняются тем, что эти методики почти исключают затраты времени на отладку. Что? Исключают затраты времени на отладку? Это действительно стоящая цель!

Ошибки самого тестирования

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



вые данные. Эврика! Ошибка в тестовых данных! Как глупо тратить часы на поиск ошибки, если она кроется в тестовых данных, а не в коде!

, Это довольно распространенная ситуация. Зачастую сами тесты содер-

iffflt, жат не меньше, а то и больше ошибок, чем тестируемый код (Weiland, 1983;

Jones, 1986а; Johnson, 1994). Объяснить это легко, особенно если разработчики сами пишут тесты. Тесты обычно создают на ходу, не уделяя должного внимания проектированию и конструированию. Их часто считают одноразовыми и разрабатывают с соответствующей тщательностью.

Ниже дано несколько советов по снижению числа ошибок в тестах.

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

Планируйте тестирование програжны так же, как и ее разработку

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

Храните тесты Посвятите немного времени проверке качества тестов. Сохраните их для регрессивного тестирования и для работы над будущими версиями программы. Связанные с этим проблемы легко оправдать, если вы знаете, что собираетесь сохранить тесты, а не выбросить.

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

22.5. Инструменты тестирования

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

Создание лесов для тестирования отдельных классов

Термин «леса» (scaffolding) пришел в программирование из строительства. Строительные леса создаются для того, чтобы рабочие получили доступ к определенным частям здания. В программировании леса создаются исключительно для упрощения тестирования кода.

Одним из типов лесов является объект, используемый дру-

. Двйошитедиые смдения Пе-

гим, тестируемым объектом. Такой объект называется «под-

дельным объектом» (mock object) или «объектом-заглушкой» шжйо найти е шь Джона

(stub object) (Mackinnon, Freemand, and Craig, 2000; Thomas бентли «А Small Matter of Prog-

and Hunt, 2002). С аналогичной целью можно создавать и ramming в книге Programming

низкоуровневые методы, называемые «заглушками». Подцель- (Bentley 2000).

ные объекты или методы-заглушки можно делать более или



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 [169] 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0022