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

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

22.7. Протоколы тестирования

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

административное описание дефекта (дата обнаружения, сотрудник, сообщивший о дефекте, номер сборки программы, дата исправления);

полное описание проблемы;

действия, предпринятые для воспроизведения проблемы;

предложенные способы решения проблемы;

родственные дефекты;

тяжесть проблемы (например, критическая проблема, «неприятная» или косметическая);

источник дефекта: выработка требований, проектирование, кодирование или тестирование;

вид дефекта кодирования: ошибка занижения или завышения на 1, ошибка присваивания, недопустимый индекс массива, неправильный вызов метода и т. д.;

классы и методы, измененные при исправлении дефекта;

число строк, затронутых дефектом;

время, ушедшее на нахождение дефекта;

время, ушедшее на исправление дефекта.

Собирая эти данные, вы сможете подсчитывать некоторые показатели, позволяющие сделать вывод об изменении качества проекта:

число дефектов в каждом классе; все числа целесообразно отсортировать в порядке от худшего класса к лучшему и, возможно, нормализовать по размеру класса;

число дефектов в каждом методе, все числа целесообразно отсортировать в порядке от худшего метода к лучшему и, возможно, нормализовать по размеру метода;

среднее время тестирования в расчете на один обнаруженный дефект;

среднее число обнаруженных дефектов в расчете на один тест;

среднее время программирования в расчете на один исправленный дефект;

процент кода, покрытого тестами;

число дефектов, относящихся к каждой категории тяжести.

Личные протоколы тестирования

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



Дополнительные ресурсы

Федеральные законы об объективности информации заставляют меня признаться в том, что в нескольких других кни- ЫХрШсШоШШ гах тестирование рассматривается подробнее, чем в этой

главе. Например, в них можно найти материалы о тестировании системы и тестировании методом «черного ящика», которых мы не касались. Кроме того, в этих книгах более глубоко освещаются вопросы тестирования, выполняемого разработчиками. В них обсуждаются формальные подходы к тестированию (такие как создание причинно-следственных диаграмм), а также детали создания независимой организации, занимающейся тестированием.

Тестирование

Капег, Сет, Jack Falk, and Hung Q. Nguyen. Testing Computer Software, 2d ed. New York, NY: John Wiley & Sons, 1999. Наверное, это лучшая книга по тестированию ПО. Приведенная в ней информация касается в первую очередь тестирования программ, которые будут использоваться большим числом людей (например, крупных Web-сайтов и приложений, продаваемых в магазинах), но полезна и в общем.

Капег, Сет, James Bach, and Bret Pettichord. Lessons Learned in Software Testing. New York, NY: John Wiley & Sons, 2002. Эта книга хорошо дополняет предыдущую. Она разделена на 11 глав, включающих 250 уроков, изученных самими авторами.

Tamre, Louise. Introducing Software Testing. Boston, MA: Addison-Wesley, 2002. Эта несложная книга ориентирована на разработчиков, которым нужно понять тестирование. Несмотря на название («Введение в тестирование ПО»), некоторые из приведенных в книге сведений будут полезны и опытным тестировщикам.

Whittaker, James А. How to Break Software: A Practical Guide to Testing. Boston, MA: Addison-Wesley, 2002. В этой книге описаны 23 вида атак, которые тестировщики могут использовать для нарушения работы ПО, и приведены примеры каждой атаки с применением популярных программных пакетов. Из-за оригинального подхода эту книгу можно рассматривать и как основной источник информации о тестировании, и как дополнение других книг

Whittaker, James А. «What Is Software Testing? And Why Is It So Hard?» IEEE Software, January 2000, pp. 70-79- В этой статье можно найти хорошее введение в вопросы тестирования ПО и объяснение некоторых проблем, связанных с эффективным тестированием.

Myers, Glenford J. The Art of Software Testing. New York, NY John Wiley 1979. Эта классическая книга по тестированию ПО издается до сих пор (хотя и стоит немало). Ее содержание довольно простое: тестирование, основанное на самооценке; психология и экономика тестирования программ; анализ и обзоры программ; проектирование тестов; тестирование классов; тестирование более высокого порядка; отладка; инструменты тестирования и другие методики. Книга лаконична (177 страниц) и легко читается. Приведенный в ее начале тест поможет вам начать думать, как тестировщик, и продемонстрирует все разнообразие способов нарушения работы кода.



Тестовые леса

Bentley, Jon. «А Small Matter of Programming» in Programming Pearls, 2d ed. Boston, MA: Addison-Wesley, 2000. В этом эссе приведены хорошие примеры тестовых лесов.

Mackinnon, Tim, Steve Freeman, and Philip Craig. «Endo-Testing: Unit Testing with Mock Objects», extreme Programming and Flexible Processes Software Engineering - XP2000 Conference, 2000. Первая работа, посвященная использованию поддельных объектов при тестировании, выполняемом разработчиками.

Thomas, Dave and Andy Hunt. «Моек Objects» IEEE Software, May/June 2002. Эта статья представляет собой удобочитаемое введение в использование поддельных объектов.

www.junit.org. Это сайт поддержки разработчиков, использу-http: cc2e.com/2217 ющих среду JUnit. Аналогичные сайты см. по адресам срр-

unitsourceforge.net и nunitsourceforge.net.

Разработка с изначальными тестами

Веек, Kent. Test-Driven Development: By Example. Boston, MA: Addison-Wesley 2003. Бек описывает «разработку через тестирование» - подход, предусматривающий первоначальное создание тестов и последующее написание кода, удовлетворяющего тестам. Хотя местами Бек впадает в евангелический тон, его советы очень полезны, а сама книга лаконична и попадает точно в цель. Стоит отметить, что она включает серьезный пример, для которого приводится реальный код.

Соответствующие стандарты

IEEE Std 1008-1987 (RI993) - стандарт блочного тестирования ПО.

IEEE Std 829-1998 - стандарт документирования тестов ПО.

IEEE Std 730-2002 - стандарт планирования контроля качества ПО.

Контрольный список: тесты

Шр: сс2е,сот/2210 □ Каждому ли требованию, относящемуся к классу или методу, соответствует отдельный тест?

□ Каждому ли аспекту проектирования, относящемуся к классу или методу, соответствует отдельный тест?

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

□ Каждый ли путь «определение - использование» в потоке данных протестирован хотя бы одним тестом?

□ Проверили ли вы код на наличие в потоке данных путей, которые обычно ошибочны, таких как «определение - определение», «определение - выход» и «определение - уничтожение»?

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

□ Протестировали ли вы все простые граничные условия: максимальные, минимальные и граничные условия с завышением или занижением на 1?



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.004