Главная
Попытка заменить пчелу
Предложения советских рационализаторов
Радиоэлектронные собеседники животных
Роботехника в производстве и в быту
Тайна профессора Рентгена
Деталь сама себя обрабатывает и охлаждает
Желтый подводный робот
Ледяные корабли
Открытия и наблюдения советских ученых
Новаторская перевозка грузов
Перпетуум мобиле с Алексеем Воробьёвым-Обуховым
Пишущая машинка стенографирует и расшифровывает
Шахматная махина маэстро кэмпелена
Роторно-винтовые ледоколы
Русскому керосину - 160 лет
Спасение в воздушных просторах
Что умеют машины
|
Главная - Литература ГЛАВА 22 Тестирование, выполняемое разработчиками Содержание mtp: cc2exom/2261 22.1. Тестирование, выполняемое разработчиками, и качество ПО 22.2. Рекомендуемый подход к тестированию, выполняемому разработчиками 22.3. Приемы тестирования 22.4. Типичные ошибки 22.5. Инструменты тестирования 22.6. Оптимизация процесса тестирования 22.7. Протоколы тестирования Связанные темы Качество ПО: глава 20 Методики совместного конструирования: глава 21 Отладка: глава 23 Интеграция: глава 29 Предварительные условия конструирования: глава 3 Тестирование - самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих приложений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие - специализированные группы. Виды тестирования перечислены ниже. Блочным тестированием называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы. Тестирование компонента - это тестирование класса, пакета, небольшого приложения или другого элемента системы, разработанного несколькими программистами или группами, выполняемое в изоляции от остальных частей системы. Интеграционное тестирование - это совместное выполнение двух или более классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами. Этот вид тестирования обычно начинают проводить, как только созданы два класса, которые можно протестировать, и продолжают до завершения работы над системой. Регрессивным тестированием называют повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов. Тестирование системы - это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами. Предметом тестирования в этом случае являются безопасность, производительность, утечка ресурсов, проблемы синхронизации и прочие аспекты, которые невозможно протестировать на более низких уровнях интеграции. В этой главе «тестированием» я называю тестирование, выполняемое разработчиками, которое обычно включает три первых вида тестирования из приведенного списка, но иногда может включать также регрессивное тестирование и тестирование системы. Многие другие виды тестирования обычно выполняют не разработчики, а специализированный персонал: в качестве примеров можно привести бета-тестирование, тестирование системы на предмет одобрения заказчиком, тестирование производительности, тестирование конфигурации, платформенное тестирование, тестирование в стрессовом режиме, тестирование удобства использования и т. д. Эти виды тестирования мы рассматривать не будем. Тестирование обычно разделяют на две обширных категории: «тестирование методом черного ящика» и «тестирование методом белого (прозрачного) ящика». В первом случае тестировщик не владеет сведениями о внутренней работе тестируемого элемента. Очевидно, что это не так, если вы тестируете собственный код. При тестировании методом белого ящика внутренняя реализация тестируемого элемента тестировщику известна. Тестируя собственный код, вы используете именно этот вид тестирования. Оба вида имеют свои плюсы и минусы; В данной главе основное внимание уделяется тестированию методом белого ящика, потому что именно его выполняют сами разработчики. Порой термины «тестирование» и «отладка» используют взаимозаменяемо, но внимательные программисты различают два этих процесса. Тестирование - это средство обнаружения ошибок, тогда как отладка является средством поиска и устранения причин уже обнаруженных ошибок. Эта глава посвящена исключительно обнаружению ошибок. Об исправлении ошибок см. главу 23. Тема тестирования не ограничивается тестированием во время конструирования. Информацию о тестировании системы, тестировании в стрессовом режиме, тестировании методом черного ящика и других вопросах, ориентированных на специалистов по тестированию, можно найти в работах, указанных в разделе «Дополнительные ресурсы» в конце главы. 22.1. Тестирование, выполняемое разработчиками, и качество ПО перекрестна!} €0ыш 06 обзо- Тестирование - важная часть любой программы контроля pax ПО см. гпаву 21. качества, а зачастую и единственная. Это печально, так как разнообразные методики совместной разработки позволяют находить больше ошибок, чем тестирование, и в то же время обходятся более чем вдвое дешевле в расчете на одну обнаруженную ошибку (Card, 1987; Russell, 1991; Kaplan, 1995). Каждый из отдельных этапов тестирования (блочное тестирование, тестирование компонентов и интеграционное тестирование) обычно позволяет найти менее 50% ошибок. Комбинация этапов тестирования часто приводит к обнаружению менее 60% ошибок Qoics, 1998). Программы т mm, а ошиб- У программиста спросить, какой из этапов разработки - ш микробы: программа не менее всего похож на другие, он наверняка ответит: может ишашьой ошибок, об- «Тестирование». По ряду описанных ниже причин большин-щайсь с другими дефектными ство разработчиков испытывают при тестировании затруд-программами. Ошибки всегда нения допускают программиотьк Ха лай Мтт " тестирования противоположна целям других эта-(ИшШ Mills) разработки. Его целью является нахождение ошибок. Успешным считается тест, нарушающий работу ПО. Все остальные этапы разработки направлены на предотвращение ошибок и недопущение нарушения работы программы. Тестирование никогда не доказывает отсутствия ошибок. Если вы тщательно протестировали программу и обнаружили тысячи ошибок, значит ли это, что вы нашли все ошибки или в программе все еще остались тысячи других ошибок? Отсутствие ошибок может указывать как на безупречность программы, так и на неэффективность или неполноту тестов. Тестирование не повышает качества ПО - оно указывает на качество программы, но не влияет на него. Стремление повысить качество ПО за счет увеличения объема тестирования подобно попытке снижения веса путем более частого взвешивания. То, что вы ели, прежде чем встать на весы, определяет, сколько вы будете весить, а использованные вами методики разработки ПО определяют, сколько ошибок вы обнаружите при тестировании. Если вы хотите снизить вес, нет смысла покупать новые весы - измените вместо этого свой рацион. Если вы хотите улучшить ПО, вы должны не тестировать больше, а программировать лучше. Тестирование требует, чтобы вы рассчитывали найти ошибки в сво-Jllfl ем коде. В противном случае вы, вероятно, на самом деле их не найдете, но это будет всего лишь самоисполняющимся пророчеством. Если вы запускаете программу в надежде, что она не содержит ошибок, их будет слишком легко не заметить. В исследовании, которое уже стало классическим, Гленфорд Майерс попросил группу опытных программистов протестировать программу содержащую 15 известных дефектов. В среднем программисты нашли лишь 5 из 15 ошибок. Лучший программист обнаружил только 9. Главной причиной неэффективного обнаружения ошибок было недостаточно вниматель- 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.0024 |