БЫСТРОЕ

ТЕСТИРОВАНИЕ

Роберт Капбертсон
Kpuc Браун
Гэри Кобб

Издательский дом "Вильямс "

Москва • Санкт-Петербург • Киев
2002
ББК 32.973.26-018.2.75
К17
УДК 681.3.07

Издательский до м "Виль ям с "

Зав. редакцией С.Н. Тригуб

По общим вопросам обращайтесь в Издательский дом "Вильямс" по адресу:

info@[Link], [Link]

Калбертсон, Роберт, Браун, Крис, Кобб, Гэри.

К17 Быстрое тестирование. : Пер. с англ. — М. : Издательский дом "Вильямс",
2002. — 384 с. : ил. — Парал. тит. англ.

ISBN 5-8459-0336-Х (рус.)

Жесткая и серьезная конкуренция на рынке готового программного обеспечения (ПО)
заставляет искать способы, целью которых является как минимизация сроков разработки
новых продуктов, так и повышение их надежности. Как известно, высокое качество и
надежность гарантирует адекватно выполненное тестирование. Технология быстрого тести­
рования находит "золотую середину" между соблюдением сроков и гарантией высокого
качества. Описанию этой технологии и посвящена книга. Книга написана с учетом громадного
опыта работы авторов в области тестирования ПО. Она окажет несомненную пользу всем
специалистам, которые работают как в крупных, так и в небольших организациях, зани-
мающихся созданием ПО. Б Б К
. . .018.2.75
32 973 26

Все названия программных продуктов являются зарегистрированными торговыми марками соответствую­

щих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было
форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование
и запись на магнитный носитель, если на это нет письменного разрешения издательства Prentice Hall PTR.
Authorized translation from the English language edition published by Prentice Hall PTR,
Copyright © 2002
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic
or mechanical, including photocopying, recording or by any information storage retrieval system, without permission
from the Publisher.
Russian language edition published by Williams Publishing House according to the Agreement with R&I Enter­
prises International, Copyright © 2002

ISBN 5-8459-0336-Х (рус.) © Издательский дом "Вильяме", 2002

ISBN 0-13-091294-8 (англ.) © Prentice Hall PTR, 2002
Оглавление
Пред ис ло в и е 11
Час т ь I . Пр о це с с б ы ст р о г о т е с т и р о в а н и я 15
Глав а 1. П он я т и е о техно лог и и б ы ст р о г о тес ти р о ван и я 16
Глава 2. Анализ треб ован и й и тестирован и е 35
Глав а 3. Пл а н и р о в а н и е и с п ы т а н и й 56
Глав а 4. П р о е к т и р о в а н и е и разработк а тесто в 98
Глава 5. Системны е и с п ы т а н и я 118
Глав а 6 . Вопрос ы о б ъе д ин е н и я процесс о в тести р ова н и я
и кадровог о обеспечен и я 142
Час т ь П . Технолог и и б ы ст р о г о тес ти р ова н и я и со в е т ы 159
Глав а 7. Введени е в технолог и и тест и ро ван и я и со в е т ы 160
Глав а 8. Совместна я разработ к а требован и й к п р и л о ж е н и ю (JAR):
мето д в ы р а бо т к и требов ани й с при ме нен и е м
быстрог о т е с т и р о в а н и я 173
Глава 9. Технолог и и статическог о тестир ов ан и я и со в е т ы 183
Глав а 10.Технологи и динамическог о тест и ро ван и я и со в е т ы 211
Глава 11. Разработ к а и испо льзова н и е показателе й т е с т и р о ва н и я :
моделирован и е и п р о г н о зи р о ва н и е о шиб о к 241
Глав а 12. Технолог и и оценк и трудозатра т на тестирован и е и со в е т ы 264

Ч ас т ь I II . П р и м е р ы в ы п о л н е н и я быст р о г о тест и ро ван и я 293

Глава 13. П р и м е р фо рм у ли ро ван и я требован и й 294
Глава 14. П р и м е р план а те с т и р ов а н и я 313
Глава 15. П р и м е р ы п р о е к т и р о в а н и я и разработ к и тесто в 328
Глава 16. П р и м е р сводног о отчет а по системн ы м и с пы тан и я м 368
Литерату р а 377
П р е д м е т н ы й указател ь 380
Содержание
Предисловие 11
К л ю ч е вы е ос об е н н ос т и 11
Структура книг и 12
Об автора х 13
Благодарности 14
Ч а с т ь I . П р о ц е с с б ы с т р о г о т е с ти р о в а н и я 15
Глава 1 . П о н я т и е о т е х н о л о г и и б ы с т р о г о т е ст ир о в а н и я 16
О с н ов н ы е о п р е д е л е н и я в област и т е с т и р о в а н и я п р о г р а м м н о г о об е с п е ч е н и я 17
Ч т о та к о е б ы с т р о е т е с т и р о в а н и е ? 19
П е рс он а л 20
П роц е с с компле ксн ы х и с п ы т а н и й 21
Статическое тестирован ие 21
Д и н а мич е с к о е т е с т и р о в а н и е 21
Разработк а стр атег и и быстр ог о т е с т и р о в а н и я 22
П роц ес с р а з р а б о т к и п р о г р а м м н о г о о б е с п е ч е н и я 22
Каскадн ы й процес с т е с т и р о в а н и я 25
Анали з т р е б о в а н и й 26
Планирование испытаний 28
П р о е к т и р о в а н и е тестов , реализац и и и отладк а 29
Систем но е т е с т и р о в а н и е 29
Приемочные испытания 30
С оп ров ож д ен и е 30
Связ ь т е с т и р о в а н и я и р аз р а б о т к и 31
Ч т о дальш е 34
Глава 2 . Анали з т р е б о в а н и й и т е с т и р о в а н и е 35
П р о ц е с с ф о рм у ли р о в ан и я требовани й 37
Вы явл ен и е т р еб о в ан и й 39
Опр еде лен и е т р еб о в ан и й 42
С п е ц и ф и к а ц и я тр ебо ван и й 45
Матриц а прослеживаемост и требовани й 47
Тес ти р о ва н и е т р еб о в ан и й 47
К р и т е р и и , используемы е пр и т ест и р ов а н и и т ре б о ва н и й 49
Ис п о л ь з о в а н и е п р о т о т и п о в 50
Т е с т и ров а н и е в рамка х жиз не нн ог о цикл а эв олюц ион н о г о
прототипирован ия 52
Ч т о дальш е 54
Глава 3 . П л а н и р о в а н и е и с п ы т а н и й 56
Стратег и я т е с т и р о в а н и я 58
О п р е д е л е н и е о б ъе м о в тестовы х рабо т 59
 Содер жан и е 7

О п р е д е л е н и е подхода к т е с т и р о в а н и ю 62
О п р е д е л е н и е критерие в т е с т и р о в а н и я и т о ч е к контро л я качеств а 64
О п р е д е л е н и е стратег и и ав т о м а т из а ц и и 66
О п р е д е л е н и е стратег и и т е с т и р о в а н и я 69
Архитектур а тест о в 69
Инструментальн ы е средств а т е ст и р о в а н и я 71
Сред а т е с т и р о в а н и я 73
К он фи г ура ц и и аппаратны х средст в т е с т и р о в а н и я 74
О ц е н к а трудозатра т н а т е с т и р о в а н и е 75
О п р е д е л е н и е задач 77
О п р е д е л е н и е трудозатра т 79
О п р е д е л е н и е пр одо лжите л ьност и задач и и построен и е гра фик а ра б о т 83
О ц е н к а рис ко в , св язанны х с г ра фи к о м р аб о т 85
П о дг от ов к а и пер ес м о т р документов , сод ерж ащ и х план ы
проведения испытаний 86
Ф орм а т план а п р о ве де н и я и с п ы т а н и й 86
П р о в е р к а вы п олн ен и я план а п р о в е д е н и я и с п ы т а н и й 95
Ч т о дальш е 96
Глава 4 . П р о е к т и р о в а н и е и р азр а бот к а т е с т о в 98
Разработ к а тесто в 99
О п р е д е л е н и е целе й тест а 102
О п р е д е л е н и е с п е ц и ф и к а ц и й ввода 103
О п р е д е л е н и е конфигурац и и средст в т е с т и р о в а н и я 103
Докумен т проект о в тест о в 104
Разработ к а тестовы х случаев 105
Разработ к а де т а л из и р о в а н н ы х методи к т е с т и р о в а н и я 107
О п р е д е л е н и е ожидаемы х результато в 110
Установк а и очистк а — т е ст ир о в ан и е из известног о сос то ян и я 110
Ша б л о н тестовог о случая 111
Управлени е конфигураци е й тестов о г о случая 113
П е р е с м о т р и отладк а тесто в 114
Автома тиза ц и я тес тов ы х случаев 115
Ч т о дальш е 116
Глава 5 . С ис т е м н ы е ис п ы та н и я 118
Обнаружен и е и отслеживан и е деф ект о в 120
Опр еде лен и е состоян и й де фект о в 120
Б аз о в ы е характеристи к и систем ы отсле жив ан и я дефекто в 123
Ка к составлят ь сообщени я о де ф е кт а х 128
Анали з обнаруженны х д ефе кт о в 129
П р о г о н тес т о в 131
Вход в системн ы е исп ыт ани я 131
Ци к л ы т е сти р о ва н и я 132
Регистраци я результато в те сти р о ва н и я 134
Составлени е отчет о в п о результата м т е с т и р о в а н и я 135
О т ч е т о ход е раб о т п о т е с т и р о в а н и ю 136
8 Содержание

О т ч е т о б у ст р а н е н и и д е ф е к т о в 137
О т ч е т н ы й докла д 138
К р и т е р и й выход а и з испы т ани й и готовност ь выпуска
п р о г р а м м н о г о продукт а 139
Ч т о дальш е 140
Глава 6 . В о п р о с ы о б ъ е д и н е н и я п р о ц е с с о в т е с т и р о в а н и я
и кадрового обеспеч ения 14 2
Ч е л о в е ч е с к и й ф а к т о р и т е с ти р о в а н и е 143
Качества , к от оры м и долже н обладат ь специалис т п о те с т и р о в а н и ю ,
чтоб ы успешн о сп р ав л ят ь с я с о своим и об яза нн ост я м и 143
Х а р а к т е р н ы е оши б к и 145
Ка к п р о в о д и т ь оп ро с ы п р е т е нд е н т о в 147
С ов е рш е нс т в ов а н и е процесс а т е с т и р о в а н и я 149
Модел ь р аз в и т и я функциональн ы х в оз м о жн ос т е й
п р о г р а м м н о г о о б е с п е ч е н и я СММ 150
Ка к модел ь СМ М со о т н о с и т с я с быстры м т е с т и р о в а н и е м 153
В оз м ож н ос т и с о в е р ш е н с т в о в а н и я проц ес со в 155
Ч т о дальш е 156
Ч а ст ь II . Т е х н о л о г и и б ы с т р о г о т е с т и р о в а н и я и с о в е т ы 15 9
Глава 7 . В в е д е н и е в т е х н о л о г и и т е с т и р о в а н и я и с о в е т ы 16 0
Област ь п р и м е н е н и я т е хн ол о г и й т е с т и р о в а н и я 160
Ж и з н е н н ы й цик л р а з р а б о т к и 161
П р еи м ущ е ст в а б ы с т р о г о т е с т и р о в а н и я 164
О п р е д е л е н и е стати че ск о г о т е ст и р о в а н и я 165
Определение динамического тестирован ия 166
Ж и з н е н н ы й цик л д е ф е к т а 167
Ф орм а л ьн ы е этап ы т е с т и р о в а н и я 169
Об я з а н н о с т и член о в команд ы тестиро ван и я 170
Ч т о дальш е 172
Глава 8 . Со в ме с т н а я ра з ра бот к а т р е б о в а н и й к п р и л о ж е н и ю (JAR):
м е т о д в ы р а б о т к и тр е б ов ан и й с п р и м е н е н и е м
б ыс трог о тестирования 173
Методологи я JA R 174
Рол ь специали ст о в по те сти р о ва н и ю в процесс е JA R 181
Резюм е 182
Глава 9 . Те х н о л о г и и стат ическо г о те сти р о в ан и я и с о в е т ы 183
Ци кл о мат и че с к а я сложност ь и ее взаимосвяз ь с в ы п о л н е н и е м тестирова н и я 184
П р и м е р представлени я проект а модуля в вид е г р а ф а 185
Форма льна я о ц е н к а 189
П р и м е н е н и е к о н т р о л ь н ы х пе р е чн е й 191
Аудит 192
И н с п е к ц и и / к р и т и ч е с к и й а н а л и з / экс пе ртн ы е о ц е н к и 195
Расп реде лен и е р о л е й и обязанност е й в группе в ы п о л н е н и я инспекци й 195
О т ч е т н о с т ь о проце сс е в ы п ол н е н и я и н с п е к ц и й 198
 Содержание 9

Показател и процесс а и н с п е к ц и и 198

Использовани е э л е к т рон н о й почт ы ил и другого эле ктронн о г о
прил ожени я для у с к о р е н и я процесс а и н с п е к ц и и 198
Формальна я в е р и ф и к а ц и я 200
Язык и н а основ е с п е ц и ф и к а ц и й 201
А в т о м а т и з и р о в а н н о е доказательств о тео ре м 201
Средств а а в т о м а т из а ц и и т е с т и р о в а н и я 202
Прослеживаемость требований 202
Программ а к он т ро л я е д ин и ц изме рен и я фи з и ч е с к и х ве ли ч и н 202
Символьно е в ы п ол н е н и е 203
Л и с т и н г и п е ре к ре ст н ы х ссыло к 204
Прог ра мм ы улучшенно й пе ч ат и 204
Средств а с ра вн ен и я в е р с и й 205
Т е ст и рова н и е алг о ри тм о в 205
Диспетчер тестирования 208
Баз ы данны х мате р иа л о в со вместн ог о использовани я 210
Резюм е 210
Глава 10. Т е х н о л о г и и д и н а м и ч е с к о г о т е с т ир о в а н и я и с о в е т ы 211
Функциональн о е т е с т и р о в а н и е и анали з 21 3
Разделени е п о классам экв и вал ентн ос т и 214
Анали з граничны х з н а ч е н и й 215
Отрицательное тестирован ие 215
Тестиров ани е н а осн ов е о п р е д е л е н и я степе н и ри с к а 217
О п р е д е л е н и е п ол н о т ы охват а ветве й п р и т е с т и р о в а н и и 220
Тестиров ан и е случаев использован и я 224
П с е в д оот л а д к а / в и д ои з м е н е н и е 226
Т ра с с и р о в к а / т ра с с и р ов к а снизу в в е р х / мгн ов енны е д а м п ы / п о с т п е ч а т ь 227
Создани е точ е к п р е р ы в а н и я / п р а в к и 228
Тес ти р о ва н и е поток а д а н н ы х 230
Тестир ова н и е н а предме т утече к памят и 231
Тестир ова н и е и н т е р ф е й с а "человек-компьютер " 233
Тестир ова н и е нагрузочн о й э ф ф е к т и в н о с т и 234
Тестир ова н и е кон ф игу р ац и и пл ат ф о р м ы 238
Резюм е 240
Глава 11 . Разр абот к а и и сп о ль з о в ан и е п ок азат ел е й т е с т и р о в а н и я :
мод е ли р о в ан и е и п р о г н о з и р о в а н и е о ш и б о к 241
Определен и е показателе й и данны х и з м е р е н и й 242
Исп ользован и е стандартн ы х показателе й для внесени я усовершенствовани й 251
По казател и те ст ир о в ан и я 255
Пл отност ь ошибо к (количеств о ошибо к н а тысяч у
эквивалентн ы х стр о к кода) 256
Пр о е к т н о - о р и е нт и р о в а нн а я модел ь ошибо к 257
Программ а о ц е н к и ошиб о к программног о обеспе чени я (SWEEP) 259
Резюм е 26 3
10 Содержание

Глава 12. Технологии оценки трудозатрат на тестирование и советы 264

Применение математических методов для оценки
программного обеспечения 268
Технология функциональных баллов 287
Резюме 290
Часть III. Примеры выполнения быстрого тестирования 293
Глава 13. Пример формулирования требований 294
Набор инструментальных средств управления тестированием. Версия 1.0 296
Глава 14. Пример плана тестирования 313
Набор инструментальных средств управления тестированием. Версия 1.0 315
Глава 15. Примеры проектирования и разработки тестов 328
Набор инструментальных средств управления тестированием. Версия 1.0 333
Глава 16. Пример сводного отчета по системным испытаниям 368
Набор инструментальных средств управления тестированием. Версия 1.0 370
Литература 377
Предметный указатель 380
 Предисловие
В данно й книг е даетс я оп и с а ни е практическог о подход а к те ст и р о в а н и ю программ­
ног о обеспечения , п р и это м основн о е внимани е уделяетс я процесса м те ст ир о в а н и я
н а ф о н е стремительн о г о ускор ен и я процесс а р аз р а б о т к и п ро гр а мм н ог о обеспечени я .
Эт о т подход орие нт и ров а н н а п ри м ен ен и е специалистам и п о те с т и р о в а н и ю про­
граммног о об е сп е ч ен и я и руководителям и тестовы х работ . П р и ег о оп ис ан и и приво­
дитс я множест в о советов , технолог и й и примеров , к от ор ы е могут использовать с я дл я
повышени я э ф фе к т и в н ос т и и сокращен и я срок о в т е с т и р о в а н и я програм мно г о обес­
печен ия . Данна я книг а предназначен а и для тех, кт о реш и л на ч ат ь сво ю служебную
карьеру с т е с т и р о в а н и я пр ог ра м мн ог о обеспечени я . О н а со дер жи т об ши рн ы й набо р
ссылок , к оторы е могут ока затьс я полезным и как дл я уже сфо р ми р о ва в ши х с я профес ­
сионалов , та к и для тех , к от ор ы е тольк о начинаю т сво ю трудовую деятельность .
Скорост ь и э фф е к т и в н ос т ь раз ра бо т к и пр ог р ам мн ог о о б е с п е ч е н и я завися т о т то­
го, наскольк о удачно процес с т е с т и р о в а н и я вписыв а ет с я в общ и й ж из н е н н ы й цик л
ра зр а бо т к и п р ог р ам мн о г о продукта и о т э ф ф е к т и в н о с т и использован и я технологи й
тестировани я . В книг е п оказано , как увеличит ь ск о р ос т ь и э ф ф е к т и в н о с т ь тестиро ­
вания , уделив осн овн о е в ни ма н и е следующим вопросам :
• Начин ат ь ж и з н е н н ы й цик л т е ст и р о в а н и я необходим о одновремен н о с начало м
стади и формулирован и я техниче ск и х т р е б о в а н и й , чт об ы д е ф е к т ы можн о был о
обнаруживат ь ка к можн о раньш е и та к ж е р а н о начинат ь планирован и е и реа­
лизаци ю тестовы х случаев.
• П ри м е н я т ь э ф ф е к т и в н ы е технолог и и стати че ск о г о тести рова ни я , таки е как
инспекци и и ск возн о й контроль , для т е с т и р о в а н и я промежуточны х продуктов,
кот оры е создаютс я н а п ротяж е н и и жизне нн ог о цикл а ра зр а бо тк и .
• П р и м е н я т ь э ф ф е к т и в н ы е технолог и и динамическо г о тестиро ван и я для обна­
ружени я д ефе кт о в н а стадия х проверк и взаимодействи я и фу нк ци они р ов ан и я
компонентов , системны х и приемо чн ы х испытани й .

Ключевые особенности
По высит ь э ф ф е к т и в н о с т ь тестиров ан и я программног о обеспече н и я помогут сле­
дующие отличительны е осо бенност и данно й книги :
• Осн овно е вни ман и е уделяется настрой к е процесс а тестиров ан и я так, чтоб ы
достич ь цел и наи ск о р ей ш е г о выхода н а р ы н о к пр и сохранен и и качеств а про­
граммног о продукта.
• Тестиро ван и е программног о обеспечени я рассматривает с я в контекст е общег о
ж изне нн ог о цикл а разработ к и программног о обесп ечени я . Ж и з н е н н ы й цикл
разработ к и программног о обеспечен и я рассматриваетс я с точк и зре ни я , вы­
годной для специалис т а п о тестировани ю . Рассматриваютс я такж е модели, та­
ки е как п острое н и е эв олю ционн ы х п р о т о т и п о в , а та кж е спирал евидн а я и тра­
диционн а я каскадна я модель .
12 Предисловие

• Представ лен ы технолог и и статическог о тестировани я , которы е могут исполь­

зоватьс я дл я подкл юч ен и я группы тести ро в ан и я н а ранни х стадия х жизненно ­
г о цикла раз р аб от к и про граммног о обеспечени я . П ри м е н е н и е статическог о
т е ст и р о в а н и я позволяе т обнаруживат ь д е ф е к т ы н а ранни х стади я х ж из н и про­
граммног о продукта и тогда ж е дае т возможн ос т ь составлят ь план ы п р о в е д е н и я
испытан и й и создават ь тестовы е случаи.
• Книг а содержи т прим ер ы ключевы х результато в процесс а испыта ний .

Структура книги
Книг а состои т из тре х часте й и организован а следующим образом :
Часть I. Процесс быстрого тестирования. В это й част и дан ы определен и я основны х
понят и й и терминов , имеющи х от ноше ни е к т ест и р о ва ни ю . В не й опи сан ы про­
цессы быстрог о те стиров а ни я , к оторы е тесн о интегрирован ы с общи м жизнен ­
ны м цикло м разработ к и програм мног о обеспечения . Рассматривает с я традиц и ­
онна я каскадная модел ь р а з р а б о тк и программны х продуктов, равн о как и жизнен ­
ны е циклы , в основу к оторы х п ол ожен ы инкрементальн ы е поставк и и построен и е
эв ол юц ион н о развивающихс я п р о т о т и п о в . Каждая стади я процесс а р а з р а б о т к и
пр ог р ам мн о г о продукта исследуется с т о ч к и зрени я специалист а п о тестирова ­
нию , пр и это м даетс я опи с ан и е методо в обнаружен и я и предупреждени я д е ф е к т о в
как средст в повышени я э ф фе к т и в н о с т и тестировани я .

Часть II. Технология быстрого тестирования и советы. В это й част и подробн о описа­
ны совет ы и технологии , кот оры е могут быт ь использован ы для внедрени я про­
цесса быстрог о тестировани я . Здес ь представле н ы метод ы выявлени я и анализ а
техниче ск и х т р еб о ва ни й , оц ен к и трудозатра т н а т ес тир о в ан и е и р а з р а б о т к и гра­
ф и к о в выполнени я тестовы х работ , провед ен и я инспекци й и п ерепров еро к , раз­
р а б о т к и гестов тип а ч ер н ог о ящика . В эт о й части обсуждается ши рок и й спект р
технологи й динамическог о тестировани я , включая функциональны й анализ , раз­
биени е н а классы эквива ле нтност и , анали з граничны х зна че ний , проверк а утечек
памят и , тестиров ан и е случаев использовани я и характеристи к производи ­
тельности .
Часть III. Примеры выполнения быстрого тестирования. В тр ет ь е й части приводят с я
п р и м е р ы реализац и и процессо в и технологий , кото ры е обсуждались в двух пре­
дыдущих частя х книги . В основ е эти х приме ро в лежи т набо р инструментальны х
средст в управлени я тестировани е м (Test Manage men t Toolkit, TM T ) , которы й яв­
ляетс я чист о учебным прилож ением . Продук т ТМ Т позволяе т руководителя м тес­
товы х рабо т и специалиста м п о тестирован и ю осуществлять план ы проведен и я
исп ыт ани й , оглашать сообщени я о дефектах , результаты тестирова н и я и другую
и н форм а ц и ю , имеющую от ноше ни е к т ест и р ов ан и ю . В условиях Web-приложен и й
появляетс я возможност ь однов рем енн о й работ ы нескольки х пользователе й над
несколькими проектами независимо от их географического удаления друг от друга.
 Пр едислов и е 13

Существуют ч е т ы р е ра бо ч и х продукта, имеющи х от н ош е н и е к процесс у тестиро ­

вани я :
• Докумен т оп р е д е л е н и я т р е б о в а н и й
• Пла н т е с т и р о в а н и я
• С п е ц и фи к а ц и я тестово й процедур ы
• Сводны й о т ч е т о тестирова ни и .

Об авторах
Р о б ер т К албертс о н (Robert Culbertson) имее т опы т р аб о т ы в техническ и х областях ,
в с фе р е р а з р а б о т к и и т е с т и р о в а н и я п р ог ра м мн о г о обесп ечени я , а т ак ж е о п ыт о м ру­
ководства р а з р а б о т к о й ра зличны х п ро е кт о в . Работ а я в компани я х Cisco Systems,
Texas Instr ume nt s , IBM, в Техасско м университете , в к ом п а н и и DSC Communicati ons ,
о н приобре л л и ч н ы й оп ы т ра б от ы с тем , чт о составляе т б ы ст р о е т е ст и р о в а н и е . Ро­
бер т имее т учены е с т е п е н и бакалавр а э л е кт ро те х ни к и и эле кт рон и к и (B.S.E.E.) и ма­
гист р а э л е к т р о т е х н и к и и э ле кт рони к и (M.S.E.E.), получ енн ы е в Техасско м универси­
тет е в О стине , а так ж е ст е пе н ь доктор а ф и л о с о ф и и в област и эле кт р оте х ни к и и элек­
т рон и к и о т Бирмингемс ко г о университет а в Англии.

Гэр и К о б б (Gary Cobb) в т е ч е н и е 25 ле т поднималс я сразу по двум служебным ле­

стницам , как п репо дав ате л ь и как специалист , р а б о т а ю щ и й в п ром ыш л ен но й зо н е
город а О стин . О н занималс я препода ватель ск о й деят ельн ост ь ю в Техасско м универ­
ситет е в О с т и н е н а от де л ен и я х математики , к омп ь ютерн ы х наук, э л е к т р о т е х н и к и и
производст в а ко м пь ют е р о в . Гэр и такж е вел курс мультимедиа-систем на факультет е
компьютерны х наук в Юго-западном университет е штат а Техас , в которо м занима л
пос т руководител я л а б о р а т о р и и мультимедиа-систем. Его послужно й списо к в про­
мышленност и включае т работу н а ответственн ы х д о л жн о ст я х в компания х Texa s In­
strument s Inc. , Loc k h ee d Marti n и Dell Co m p u t e r Co r p o r at i o n . О н читае т кратки е кур­
с ы в институт е качеств а программног о обеспечен и я пр и Техасско м универс итете ,
которы й выступил сп о нс о р о м его разработ к и к рит е ри е в программног о обеспечени я ,
увенчавшейс я присуждение м ему пре ми и Gr e ate r Austin Qualit y Award (Победител ь п о
качеству в Ос ти не ) . Гэр и имее т степен ь доктор а ф и л о с о ф и и в област и математики ,
полученную в Техасско м университет е в Остин е .
Кри с Браун (Chris Brown) работае т в компьютерно й индустри и и индустри и про­
граммног о обеспече н и я боле е 2 0 лет. Зан им ая с ь вопросам и тестировани я , о н работа л
на различны х должностя х в таки х компаниях , как Advance d Micr o Devices, Cisco Sys­
tems , Co mp a q C o m p u t e r Corpor ati o n и IBM. В ко мп ани и Advanc e d Micr o Devices о н
отвеча л з а системны е испытани я результатов генера ц и и кремниев ы х компиляторо в
и за проверк у на совместимост ь всех конфигурац и й аппаратн ы х и программн ы х
средств. В ко мп ан и и Co m p a q Кри с отвеча л на постро ен и е тестов ы х сценарие в и тес­
тир о ва н и е п ро то ти п о в и опыт ны х образцо в систе м для отделени я портативн ы х ком­
пьютерны х продуктов . Будучи сотруднико м к о м п ан и и IBM, Кри с возглавлял команду
тестирован и я администратор а баз данны х OS / 2 , администратор а пер едач и данны х и
администрато р а л окальн о й сети . О н был п ре з и д е н т ом / г л а в н ы м ад ми ни ст р ат ор о м в
C om put e r Security C or por a ti o n , компании , к о т о р а я поставлял а программн ы е средств а
защит ы о т вирусо в военно-воздушным сила м США, а такж е компани я м Prude ntial ,
14 Предисловие

Boeing и другим крупным компаниям и лабораториям. Крис также занимал посты ре­
гионального менеджера и вице-президента в компании Dataserv Computer Mainte-
nance/BellSouth, где отвечал за техническое обслуживание и ремонт в процессе экс­
плуатации 40000 компьютеров. Крис имеет степень бакалавра в области электроники
и степень магистра по менеджменту.

Благодарности
Авторы остаются в неоплатном долгу перед Алом Дейлом (Al Dale), основателем ин­
ститута SQI (Software Quality Institute— институт качества программного обеспече­
ния), за его поддержку, оказанную этой книге и серии в целом. Мы также хотели бы
выразить свою благодарность Полу Петралия (Paul Petralia) за его моральную под­
держку в период написания и издания этой книги. Наша признательность распро­
страняется также и на влиятельных сотрудников института SQI и коллектива изда­
тельства Prentice Hall за их постоянную поддержку и профессиональную помощь.
Джессика Болч (Jessica Balch) и весь производственный коллектив компании Pine
Tree Composition проделали большую работу, чтобы вдохнуть в книгу жизнь; мы по­
лучили огромное удовольствие от сотрудничества с ними.
Роберт Калбертсон хочет выразить благодарность всей своей семье — Терри,
Шилли и Майклу — они поддерживали своего папу тем, что не были ему помехой во
время написания книги. Роберт благодарит свою маму Лорин и брата Лоренса за их
неизменную помощь и поддержку. Роберт также выражает свою признательность
всем менеджерам, инженерам и преподавателям, которые были для него одновре­
менно и наставниками, и коллегами в течение многих лет. В частности, эти благодар­
ности направлены в адрес Боба Маринконза (Bob Marinkonz), Марка Шервуда (Mark
Sherwood) и многих других.
Гэри Кобб благодарит свою жену Мерилин за ее терпение и заботу в течение дол­
гих часов, потребовавшихся для написания его части книги. Он также благодарит
своих детей Гленна Кобба, Молли Пирсон, Стивена Кобба и Мередит Макларти за
оказанную поддержку. В числе людей, оказавших ему помощь в служебном росте, Гэ-
ри прежде всего желает поблагодарить своих родителей, преподавателей и коллег по
работе.
Процесс быстрого
тестирования
 Понятие о
технологии быстрого
тестирования
Темы, рассматриваемые в главе:
• Основн ые определен ия в области тест ирования
программного обеспечения
• Что такое быстрое тестирование?
• Разработка стратегии быстрого тести рова н ия
• Процесс разработки программного обеспечения
• Каскадный процесс те сти рован ия
• Связь тести рован ия и разработки
• Ч т о дальше

З а последни х два десятилети я компьюте рн ы е систем ы и выполняемо е н а ни х про­

гр ам мн о е о бе сп е ч ен и е п рон и к л о в о все област и человеческо й деят ельн ост и . Про ­
гр ам мн о е о бе с пе ч ен и е присутствует в автомобилях , духовках, сот овы х т е л е ф о н а х ,
игра х и на рабочи х местах. О н о являетс я движущей сило й бухгалтерских систем , сис­
те м обмен а данными , сое динен и й с I nt er ne t . Распр остранен и е программн ы х систе м
достиг л о тако й стадии , когда к о р п о р а т и в н ы е и нацио нальн ы е экономик и впадаю т в о
все большую зависимост ь от успешно й разработ к и и доставк и программног о обес­
пе чени я .
П о мер е возрастан и я ставо к н а р ы н к е программног о обеспечени я , все отч ет лив е й
вырисовывает с я потребнос т ь разработк и большег о числа программны х продукт о в з а
меньши е промежут к и времени . Эт о обстоятельств о предъявляе т п ов ы ш енн ы е требо ­
вани я к разработчика м и тестиров щик а м программног о обеспе чен и я не тольк о в
план е ускоренног о производств а программн ы х продуктов, но и в план е обеспе чен и я
должног о уровн я и х качества , к от о р о е смогл о б ы удовлетворит ь потребителей .
В силу этог о обстоятельст в а к специалиста м по тестирован и ю современног о про­
граммног о обеспечени я предъявляютс я следующие основны е требовани я :
• Необходим о тес тир ов а т ь быстро , соблюда я жестки е ср о к и поставк и про­
граммны х продуктов.
 Глава 1. Пон яти е о технологи и бы ст рог о тестирован и я 17

• Необходим о обеспечиват ь достаточн о высоко е качеств о тестирован ия , кото­

р о е б ы гарантир ова л о , чт о д е ф е к т ы , приводящи е к разрушительны м последст­
виям , н е п р ос о ч ат с я н а ко м пь ют е р ы конечны х пользов ателе й .
Проблем а связан а с тем , ч тоб ы удовлетворит ь каждое т р е б о в а н и е бе з ущерба для
другого. Цел ь настояще й к ниг и заключает с я в нахожден и и э ф ф е к т и в н о г о тестовог о
процесс а и представ лен и и таки х практически х технологий , к от ор ы е удовлетворял и
б ы обои м требованиям . М ы начне м с изучени я фундаментальны х ос но в р а з р а б о т к и и
т е ст и р о в а н и я програм мно г о обеспечени я .

Основные определения в области

тестирования программного обеспечения
П р е жд е чем приступит ь к обсуждени ю процесс а р а з р а б о т к и пр ог р ам м но г о обеспече­
ния , дадим о пр е де л ен и я ряд а ос нов ны х термино в и п он ят и й . П о логик е вещ е й лучше
всего начат ь с определени я , чт о собо й представляе т т е с т и р о в а н и е програм мно г о
обеспечени я .
Тестирование программного обеспечения (software testing) — эт о процес с анализ а ил и
эксплуатаци и програм мно г о о б е с п е ч е н и я с целью выявлени я д е ф е к т о в .
Несм от р я н а всю простот у этог о определени я , в не м содержат с я пункты, котор ы е
требу ю т дальнейш и х п ояс н е н и й . Слов о процесс (process) используетс я дл я того , чтоб ы
подчеркнуть , чт о т е с т и р о в а н и е суть плановая , упорядо ченн а я деятельност ь . Это т
момен т очен ь важен , есл и м ы заинтересова н ы в бы стро й р а з р а б о т к е , иб о хорош о
продуманный , си ст е мат и ч ес к и й подход быстре е приводи т к обнар ужен и ю про­
граммн ы х ошибок , че м плох о спланирова нн о е те сти р о ва ни е , к тому же пров оди м о е в
спешке .
Согласн о этому о п р е д е л е н и ю , те сти р о ва н и е предусматривае т "анали з " ил и "экс­
плуатацию " програ ммно г о продукта. Тестова я деятельность , связанна я с анализо м
результато в разработ к и программног о обеспечения , называет с я статическим тести­
рованием (static testing). Статическо е тестировани е предусматрива е т проверк у про­
граммны х кодов, сквозн о й конт рол ь и проверну программы без запуска на машине, т.е.
проверку за столом (desk checks). В отличи е от этого , тестова я деятельност ь , предусмат­
ривающа я эксплуатацию программног о продукта, носи т названи е динамического тес­
тирования (dynamic testing). Статическо е и динамическо е те ст ир о в ан и е дополняю т
друг друга, и каждый из эти х т ип о в тестирован и я реализуе т собственн ы й подход к
выявлени ю ошибок .
Последни й пункт опред еле ни я , требующи й дополнительн ы х пояснени й — эт о по­
нят и е дефекта (bug). Гов ор я простым и словами, программна я о ши бк а — н и чт о иное ,
как изъя н в разработ к е программног о продукта, к о то р ы й вызывае т несоответстви е
ожидаемы х результатов вы по лн ен и я программног о продукта и фа кти чес к и получен­
ны х результатов. Де ф е к т може т возникнут ь н а стади и кодир овани я , н а стадии фор ­
мулирования требовани й ил и н а стади и проектир ован и я , либ о ж е ег о п ри чи н а може т
крытьс я в нек о р ре кт н о й конфигур ац и и или данных . Де ф е к т о м може т быт ь такж е
что-то другое, чт о не соответствуе т ожидани я м заказчик а и чт о може т быть , а може т
и н е быт ь опр ед е ле н о в с п е ц и ф и к а ц и и программног о продукта . Боле е подр обн о е
оп ис ан и е т е р м и н о л о г и и д е ф е к т о в приводит с я в о врезк е 1.1.
 18 Част ь I. Проц ес с быстрог о тестировани я

ДОЛГОВЕЧНОСТЬ ДЕФЕКТ А
Долговечность дефекта м оже т быть описана следующим образ о м . Дефек т возникает в
результате того , что человек допускает ошибку (error), осуществляя некоторы й вид
деятельности, который имеет отношение к разработк е программ н ог о обеспечения. К
упомянуты м видам деятельности относятся, например, формулирование требований,
проектирование программ ы или написание про грамм но г о кода . Эта ошибка вкрадывает-
ся в рабочий продук т (перечень требований, проектный докумен т или программны й код )
в виде неисправности (fault).
До тех по р пока эта неисправность (известная еще как дефект (bug, defect)) присутст­
вует в рабоче м про дукте , она м о ж е т служить причиной появления других дефектов . На-
пр им е р , если неисправность, допущенная в перечне требований, остается нео б наруже н -
ной , вполне вероятно, что это приведет к возникновению соответствующих ошибо к в
проект е системы, в проект е про граммы , в про грам мно м коде и даж е в документации
для пользователя.
Де фе к т остается необнаруженны м до тех пор , пока не произойдет отказ . Ведь именно
тогда пользователь или тестировщик замечает, что система не выполняет возложенных на
нее функций . На стадии системных испытаний цель специалиста по тестированию со ­ стоит
в т о м , чтобы вызвать сбой пр о гр ам м ы , обнаружить и задокументировать связан­ ные с
ни м дефекты , а затем удалить их из системы . В идеальном случае долговечность дефекта
ограничена м ом е нт ом , когд а он обнаруживается средствами статического или
динамического тестирования и успешно устраняется.
Врезка 1.1

О д н о и з практически х последстви й определен и я процесс а те стиров ан и я заключа­

етс я в том , чт о пере д специалистам и п о т ести рован и ю и разработчика м и поставлен ы
п роти в оп ол ож н ы е цели . Цел ь разработчик а состои т в том, чтоб ы создат ь программ ­
н ы й код бе з де ф ек то в , к о т ор ы й соответствуе т назн а чен и ю программног о продукт а и
отве ча е т требования м заказчика . Разработч и к пытает с я "сделат ь " п рог ра ммн ы й код.
Це л ь тестировщик а связан а с анализ о м код а и эксплуатацие й программы , ч т о в ко­
нечн о м итог е до л ж н о вест и к вскрыт и ю де фе кт о в , затаившихс я в программн о м коде ,
к от ор ы е проявляютс я в о в ре м я ег о ин тег ри ров ан и я , конфигури рован и я и выполне ­
н и я в различн ы х средах. Тестировщ и к предп рини ма е т поп ыт к и "разломат ь " про­
граммн ы й код. В данно м к онтекст е хор ош и м результато м для разработчи к а с чит ает с я
успешно е прохо жден и е теста , в т о врем я как дл я тестировщик а успешны й результа т
означае т отка з программ ы н а то м ж е само м тесте . В конечно м итог е и разработчи к , и
тестировщ и к стрем ят с я к едино й цели : получит ь тако й программны й продукт, кото­
р ы й хо ро ш о работае т и удовлетворяе т требовани я м заказчика .
Т е ст и рова н и е программно г о обеспечен и я выполняе т две базовы х функции : ве­
р и ф и к а ц и ю и аттестацию . В [45] функци и в е ри фи к а ц и и и аттестац и и (verification
a n d validation , V&V) опреде ляют с я следующим образом :
Верификация (verification) обе спечи вае т соответстви е результато в к он к рет н о й ф а з ы
процесс а разработ к и требовани я м данно й и предшествующе й стадий .
Аттестация (validation) ест ь гарант и я того , чт о программн ы й продукт удовлетво­
р я е т системны м требованиям .
Це л ь атт ес та ц и и заключаетс я в том , чт о систем а должн а отвечат ь всем предъяв­
ляемы м требованиям , та к чтоб ы пр ои с хо ж де н и е каждо й функци и м ож н о бы л о про­
следит ь д о конкретног о т ребовани я заказчика . Другим и словами , атте ста ц и я дае т
гарант и ю того , чт о стр оит с я прави льны й продукт.
 Глава 1. Поняти е о технологи и бы ст р о г о тестировани я 19

В е ри фи к а ц и я в больш е й мер е сосредоточе н а н а де йстви я х в рамка х к он к ре т н о й

стади и процесс а р аз р а б о т к и . Н ап р им е р , одн а и з целе й системног о т е с т и р о в а н и я за­
ключает с я в о б е с п е ч е н и и соответстви я проект а систем ы требованиям , к от ор ы е был и
использован ы ка к входны е данны е для стади и п рое к т и ров а н и я систем ы . Дл я под­
твер жден и я с оот ветст в и я между проекто м п р ог ра м м ы и проект о м систем ы м ож н о
воспользоватьс я модульным тестировани е м и п р ов е р к о й взаимодействи я и функцио ­
ни рова н и я к ом п он ен т о в систем ы . П р о щ е говоря , в е ри фи к а ц и я дае т гарант и ю того ,
чт о продукт строит с я правильно . В последующих главах, паралл ельн о с прохождени ­
е м всех стади й процесс а раз ра б отк и , будут прив одить с я соответствующи е п ри м е р ы
в е р и фи к а ц и и и атте ст ац и и .
Остает с я дат ь о п р е д е л е н и е ещ е одног о д о п о л н и т е л ь н о г о п он ят и я — п он ят и я каче­
ства. П од обн о таком у свойству, как красот а , качест в о — во много м субъективно е по­
нятие , поэтом у т о ч н о е оп р ед е ле н и е дат ь ему д о ст ат о ч н о трудно . Опреде ли м качеств о
програм мно г о о б е с п е ч е н и я с использование м т р е х ф а к т оро в : отказо в н а мест е экс­
плуатаци и продукта, надежност и и ст еп е н и удовлетворенност и заказчика . Говорят ,
чт о программны й продукт обладае т хорош и м качеством (quality), если :
• П р и раб от е пользовател я с программны м продукто м возникае т небольш о е чис­
л о отказов . Эт о т ф ак т свидетельствует о том , чт о н а рабоч е е мест о просочи ­
лос ь лиш ь небольш о е числ о деф ек то в .
• П рог ра м м н ы й продукт надежен , а эт о озн а ча ет , ч т о ег о прого н редк о заверша­
етс я ав а ри йн ы м отказ о м ил и чт о о н редк о демонстрируе т непредсказуем о е по­
ведени е п р и работ е в сред е заказчика .
• П рог ра м мн ы й продукт удовлетворяе т треб ова ни я м большинст в а пользо­
вателей .
О д н о и з следстви й прив ед ен но г о оп р ед е ле н и я заклю чаетс я в том , чт о тестова я
группа н е то ль к о дол жн а п р и н ят ь мер ы к п р е д о т в р а щ е н и ю и обнаружен и ю д е ф е к т о в
в процесс е разраб от к и программног о продукта, н о такж е сконцентри ро ва т ь сво и
усилия на пов ы ш ени и ег о надежности , удобства и пр ос тот ы использовани я .

Что такое быстрое тестирование?

В данно й книг е т е рм и н "быстр о е тестировани е " используетс я как дополнен и е поня­
ти я "быстра я ра зра ботка " . Ка к отмечалос ь в [33] , для разны х люде й быстра я разра­
ботк а означае т ра зл и чн ы е вещи. Не к о т о р ы е поним аю т эт о как быстро е создани е
прототипов . Други е представляю т е е как н е к от о р о е сочетани е инструментальны х
средст в CASE, активног о участия пользовател я и жестки х временны х огр ан и че н и й . В
редакци и Макк оннел а [33] пр и определен и и быстро й разработ к и н е упоминаютс я
специальны е инструментальны е средств а ил и методы :
Быстра я разработ к а — эт о обобщ енн ы й терм ин , к от о р ы й означае т т о же , чт о "ус­
ко р енн а я разработка " и "сжаты е срок и разработки" . О н означае т разработк у про­
граммног о продукта з а меньше е время , че м эт о делалос ь д о сих пор . Та ки м обра­
зом , "проек т быстро й разработки " означае т люб о й проект , пр и которо м особо е
знач ен и е им ее т с р о к р аз р а бот к и .

В то м же ключе , быстрое тестирование (rapid testing) означа е т вы пол не н и е тестиро ­

вани я пр ог р а мм но г о об е сп е че н и я в боле е быстро м темпе , че м эт о делаетс я в настоя-
20 Част ь I . П ро ц е с с быст рог о тестировани я

щи й момен т , п р и услови и с о х ра не н и я ил и п ов ышен и я уровн я качества . К сожале­

нию , п ро ст ы х путей д о с ти ж е н и я э т о й цел и н е существует. Н а р ис . 1.1 показан а упро­
щенна я схема, представляющ а я быстр о е т е сти р о ва н и е ка к структуру, построенн у ю н а
фундамент е и з четы ре х компонент ов . Если хот я б ы оди н и з эти х к омп онент о в ослаб­
лен , э ффе к т и в н ос т ь те с т и р о в а н и я существенно снижается . В соответстви и с рис . 1.1,
к четыре м компонентам , к от ор ы е должн ы быт ь опти миз и ров а н ы дл я целе й быстрог о
тестиров ани я , относят с я персонал , процес с комплексны х исп ыта ни й , статическо е
т е ст и р о в а н и е и дина миче с к о е т е сти р о ва ни е . Дале е п ри в од ит с я к ратк и й анали з всех
четы ре х компон енто в .

Персонал
Кажды й менедже р п о т е с ти ро в ан и ю знает , чт о нужные специалис т ы представляю т
собо й не п ре ме нн о е услов и е быстр ог о тестировани я . Мн ог о чи с ле нн ы е исследовани я
показывают , чт о производительност ь разработчи к о в программног о обеспечен и я
различаетс я в предела х 10:1 и даж е больше. То же можн о сказат ь и в отно ш ен и и спе­
циалисто в п о тести р о ва н и ю — далек о н е кажды й специали с т облада е т навыками ,
опыто м ил и хар а ктер о м , чтоб ы стат ь хороши м специалисто м п о тестированию . В
частности , для вып о лн ен и я бы стр ог о тестирован и я нужны хор ош о подготовленны е
и гибки е исполнители , способн ы е работат ь в условиях жестки х временн ы х ограни­
чени й и быт ь полезны м и партнер ам и для разраб отчик о в н а ранни х стадиях жизнен ­
ног о цикла разработки . Не см от р я н а т о чт о в это й книг е основн о е внимани е уделяет­
ся процессу и те хно л ог и и тестиро вани я , в главе 6 предлагаютс я нек оторы е идеи , ка­
сающиес я персонала , к о т о р ы й долже н выполнят ь тестирование .

Процесс комплексных испытаний

Независи м о о т того , наскольк о высок а к ва ли фи ка ц и я персонала , есл и он и н е распо­
лагаю т систематич еск и м и от л аж е нн ы м процессо м т е с т иров а ни я , он и н е смогут ра­
ботат ь с максимально й э ффе к т и вн ост ь ю . В основу процесс а т е с т и р о в а н и я должн ы
 Глава 1. Поня т и е о технолог и и бы ст рог о тест ирован и я 21

бы т ь положен ы устойчивы е , фундамента льн ы е п ри н ц и п ы , а сам процес с тестиров а ­

ни я долже н быт ь тесн о и н т ег р и р о в а н с общи м процессо м р аз р а б о т к и пр ог р ам мн о г о
обеспечени я . В част и I это й книг и больш о е вн и ма н и е уделяется опи с а н и ю способ о в
сове ршен ствов ан и я процесс а те стировани я . Вопр о с ы п ри м ен ен и я практ ически х
технолог и й и рекомендац и и по реализац и и рассматриваютс я в част и II. В ц е нт р вни­
мани я проводимог о нам и анализ а попадае т исследовани е вопросо в боле е органично ­
г о интегрирован и я процесс а р аз р а б о т к и и тестирован и я .

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

Динамическое тестирование
Част о , когда специалист ы думают о тестировани и , он и имею т в виду динами ческ о е
тестирование , в рамка х которог о предусматривает с я эксплуатаци я систем ы с цель ю
выявл ен и я дефектов . Если статическо е тестиро ван и е н е предусматрива е т прогон а
программног о продукта, т о динамическо е тестир ован и е бе з таког о прогон а обойти с ь
н е может . Вообще говоря , динамическо е тестирован и е состои т и з прогон а програм­
мы и сравнени я ее фактическог о поведени я с ожидаемым . Если ф а кт и че с к о е поведе­
ни е отлича етс я о т ожидаемого , эт о значит , чт о обнаруже н дефект . Ка к будет показа­
но в последующих главах, динамическо е тестиров ан и е применяет с я для в ып о лн ен и я
тес т о в различны х типов , таки х как функциональна я проверка , исп ыт ани я для опре ­
делени я рабочи х характеристи к и тестиров ан и е в предельны х режимах . Динамиче ­
ско е тестиро ван и е являетс я центральн ы м звено м процесс а тестиров ан и я программ­
ног о обеспечени я , и если планирова ни е , прое ктиров ани е , р аз р аб от к а и в ып ол не н и е
динамическог о тестирован и я выпо лнен ы недостаточн о хор ошо , т о процес с тестиро ­
вани я н е може т быт ь э ф ф е к т и в н ы м . Дин а ми чес к о е тестир ован и е выпол няе т с я н е
тольк о силам и тестов о й группы; тес тов а я группа должн а быт ь часть ю коллектив а
разраб отчик о в и совместн о с ним и пр ини м ат ь участие в прове рк е взаимодействи я и
ф у н к ц и о н и р о в а н и я компоненто в системы .
22 Част ь I . Про ц ес с бы ст рог о тестировани я

Разработка стратегии быстрого тестирования

Если б ы пере д вами был а поставл ен а задач а исследоват ь текущи й процес с р а з р а б о т к и
пр ог р ам мн о г о о б е с п е ч е н и я с цель ю найт и способ ы повыше н и я э ф ф е к т и в н о с т и тес­
т и ров а н и я , т о кака я част ь процесс а в первую очеред ь привлекл а б ы ваш е внимание ?
Н а ч н е т е л и в ы эт и исслед о ван и я с анализ а того , как планируетс я вып олн ят ь тестиро ­
вание? С анализ а средст в и метод о в автоматизаци и разработ к и программног о обес­
печени я ? Ч т о можн о сказат ь о б используемо й вами систем е о тс л е жи в ан и я дефекто в ?
П р и н я т ы й в это й книг е подхо д предусматривае т исследовани е каждо й ф а з ы про­
цесс а р аз р а б о т к и п р о г р а м м н о г о об е сп е че н и я с поз иц и й специалист а п о тестиров а ­
нию . Основна я цел ь заключаетс я в оп р ед ел е н и и возможны х способ о в ускорен и я
процесс а т е с т и р о в а н и я пр и услови и со х р ан ен и я ил и даж е п ов ыш ен и я качеств а про­
граммног о продукта. П р и это м в озникае т х а ра к те р н ы й об ра з специалист а п о тести­
ров а н и ю , к оторы й сид и т на вращающем с я стуле и п о во р а чи в ае т с я лиц о м к каждому
аспект у процесс а р а з р а б о т к и , оп ре д ел я я , чт о можн о сделать , даб ы эт а стади я процес ­
с а р аз р а б о т к и н е стал а источ ни к о м де фе кт о в , либ о выясн яя , м ож н о л и получит ь н а
э т о й стади и и н ф ор м а ц и ю , к о т о р а я позволи т ускорит ь процес с тестировани я .
П р е ж д е че м приступи т ь к подробном у анализу каждо й стади и процесс а разработ ­
к и программн ог о о б е с п е ч е н и я в перспекти в е тестировани я , потребуетс я заложит ь
о п р е д е л е н н ы й фундамен т . В э т о й главе даютс я о п р е д е л е н и я ос нов ны х т е рм ин о в и
п он ят и й т е с т и р о в а н и я п р ог ра м мн ог о обеспечения . З ат е м п р о в од ят с я исследован и я
кажд о й ф а з ы тип о во г о процесс а р аз р аб от к и , котор ы е имею т цель ю определи т ь воз­
можны е способ ы у ск о р ен и я процесс а т е с т и р о в а н и я и пов ыш ен и я ег о эффе к т и в н о ­
ст и . В о врем я исслед ован и я каждо й стади и раз ра б о т к и м ы ра сс читыв ае м получит ь
ответ ы н а следующие вопросы :
• Може т л и тестова я группа предп рин ят ь н а данно й стади и какое-либо действие ,
способно е пр е до т в ра ти т ь утечку дефектов ?
• М о ж е т л и тестова я группа предп ринят ь н а данно й стади и какое-либо действи е ,
позволяюще е уменьшит ь рис к нарушени я временног о гра ф и к а разработок ?
• Мож н о л и получит ь какую-либо ин ф о р м а ц и ю н а текущей стади и разработки ,
котора я позволил а б ы тес тов о й группе ускорит ь пл а ни ро в ан и е тестировани я ,
разработк у тес тов ы х случаев ил и выполнен и е тестов?
Если тестов ы й процес с разработ а н с учетом ответо в н а эт и вопросы , т о эт о долж­
н о вызват ь пов ы ш ен и я темпо в тестировани я , равн о как и качеств а конечног о про­
граммног о продукта.

Процесс разработки программного обеспечения

Д о сих п о р м ы говори л и о б исследовани и процесс а разработ к и программног о обес­
пе чени я , н е указывая к о н к р е т н о , чт о и з этог о следует. Одн а и з п р и ч и н избегат ь од­
нозн а чн ы х утверждени й заключаетс я в том , чт о н е существует процесс а разработки ,
к от о р ы й наилучшим образ о м подходи л б ы для всех бы с т р о разрабатываемы х проек­
тов . На п р и м е р , в ст р ое нн ы й контр олле р для кардиостимулятор а долже н создаватьс я
"максимальн о быстро" , тогда как интеракти вн ы й словар ь для вашег о сосед а вря д л и
долже н разрабатыв ать с я стол ь ж е быстры м и темпам и .
 Глава 1. Поняти е о технологи и бы ст рог о тестировани я 23

В [42] процесс {process) опре деле н как " последовательн ос т ь шагов, в то м числ е дей­
ствия , огранич ени я и ресурсы , к о т о р а я прив оди т к желаемом у результату определен ­
ног о рода" . И з пр ед л о ж ен но г о П ф л и г е р о м [42] списк а атрибуто в процесс а выдели м
следующие:
• В рамка х процесс а предварительн о оп ис ы ва ю т с я все основн ы е действи я .
• В процесс е задействуются ресурсы , с к от оры м и связан а не кот ор а я совокуп­
ност ь ог ра н ич ен и й (например , ра с пи са ни е ) , и генерируютс я про ме жуто чн ы е и
к он ечн ы е результаты .
• П роц ес с може т состоят ь и з н е к о т о р о г о числ а подпроцессо в , связанны х между
собо й оп р ед ел е нн ы м обра зом . П роц ес с можн о опре дели т ь как некотору ю ие­
ра рхи ю процессов , организованн ы х так , ч т о кажды й подпроцес с о пи сы в ае т с я
со б ст ве нн о й модель ю процесса .
• С кажды м действи е м процесс а связан ы к рит е р и и входа и выхода, та к чт о из­
вестн о , когда оп р ед е ле нн о е действи е начинает с я и когда завер шается .
• Дей стви я выполняютс я последователь н о ил и параллель н о п о от н ош е н и ю к
другим независимы м подроцессам , поэтом у легк о определить , когда н е к от ор о е
действи е выполняет с я относ ит е ль н о других действи й .
• Кажды й процес с управляетс я не к от ор ы м наборо м руководящи х п ри н ц и п о в ,
оп р ед е ля ю щ и х цел и каждого действи я .
• К дей стви ю , ресурсу ил и результату могут применять с я ограничени я ил и ди­
рект ивы . Н а п ри м е р , бюдже т ил и пла н накладывае т ограниче н и я н а промежу­
то к времени , в те ч е н и е к о то р ог о вып олн яет с я т о ил и ино е действие , а некото ­
р о е инструментальн о е средств о може т накладыват ь ограниче н и я н а спосо б ис­
пользовани я опреде ленно г о ресурса.

Когд а процес с имее т от н ошен и е к создани ю тог о ил и иног о продукта, эт о час т о

называетс я ж и з н е н н ы м циклом . П о то й ж е п р и ч и н е разработ к а программног о про­
дукта называет с я жизненным циклом программного продукта (software life cycle). Жиз не н ­
ны й цик л программног о продукта може т бы т ь описа н разным и способами , в т о ж е
врем я для это й цел и част о используетс я модель, котора я представляе т ос н ов н ы е
свойств а процесса , сопровождаемы е определ енн ы м сочетание м текст а и иллюст­
раций.
Одно й и з первы х была использован а каскадна я (ил и водопадная) модель жизнен ­
ног о цикл а программног о продукта, пок азан н а я на р ис . 1.2. Осно в но е свойств о кас­
кадно й модел и заключаетс я в том , чт о каждая стади я ил и компонен т модел и заверша­
етс я пере д начало м следующей стадии . Пр о ц е с с начинает с я с определен и я требова ­
н и й к системе . В каскадно й модел и э т и тр ебо ван и я выявляются , анализируютс я и
записываютс я в специальн ы е документы ещ е д о того , как начнутся ра бот ы п о проек­
тировани ю . Пр о е к т и р о в а н и е системы , п р о е к т и р о в а н и е программ , кодир ова н и е и
различн ы е виды тестиро в ан и я суть самодостаточны е и тщательн о документирован ­
ны е стади и процесса . Следует, однако , заметить , чт о обычн о некото ры е стади и вы­
ступают под разли чны м и именами ; нап ри ме р , стади я системног о п р о е к ти р о в а н и я
част о называет с я "п ро е ктн ы м заданием " ил и "эскизн ы м проектом" , в т о врем я н а ка к
стади ю р аз р а б о т к и програм м ы зачастую ссылают с я как н а "рабочи й план" .
24 Част ь I . Про ц ес с бы ст рог о тестировани я

У каскадно й модели имеютс я сво и кр и ти к и . Оди н из аргументов , к которы м о н и

пр ибега ю т , касаетс я возможност и фи кс а ц и и всех требован и й н а начальн о й стади и
проект а . Предположи м , чт о вас по пр о си л и высказат ь все сво и требовани я к новому
автомобил ю до того , как он будет спрое ктиро в а н и построен . Ка к заказчику, вам бу­
де т трудн о сформулироват ь эт и треб ов ан и я с то й степень ю детализации , ко тора я
необходим а для про е кти р о ва н и я и построен и я автомобил я " с нуля". Им е н н о таки е
запрос ы предъявляе т каскадна я модел ь к заказчик у и программисту-аналитику на на­
чально м этап е каскадного процесса .
В [13] и [42] утверждается , чт о главны м недостатко м каскадно й модел и являетс я
т о , чт о он а н е трактуе т программн о е обеспечени е как процес с ре ш ени я задачи . Кас­
кадна я модел ь заимствова н а и з област и р а з р а б о т к и аппаратн ы х средств . О н а ото­
бр а жа е т к о н в ей е р н ы й п ри нц и п разработк и программног о обеспечени я , п о условиям
которог о ком по не н т сначал а разрабатываетс я , а зате м многократн о тира жир уетс я .
Однак о создани е программног о обеспе чен и я — это , прежд е всего, творчески й , а от­
нюд ь н е производственн ы й процесс . Становл ен и е программног о обеспе чен и я про­
исходи т п о спирал и п о мер е того , как ра ст е т п он и м ан и е задачи . В рамка х данног о
процесс а проис ход я т не од нок ратн ы е п родвиже н и я впере д и возв рат ы о б р а т н о , п р и
это м пробуютс я различн ы е вариант ы с цель ю выбор а и з ни х наилучшего . Другим и
 Глава 1. Поня т и е о технологи и бы ст рог о тестирован и я 25

словами, невозмож н о по с т р о и т ь точну ю модель процесс а р а з р а б о т к и програ мм но г о

продукта в виде н е к о т о р о г о набор а автономны х стади й , а и м е н н о эт о и предполага е т
каскадная модель. Други е модели , в частности , спир аль , п оэт а пн а я передача , эволю­
ционирующ а я п рот от ип н а я модель, горазд о лучше отр а ж а ю т и т е р а т и в н ы й хара кт е р
ра зр а бо т к и программн о г о обеспечени я . Ит е рат и вн ы е модел и боле е подробн о рас­
сматриваютс я в главе 2.
Если вы работал и в качест в е специалист а по т е с т и р о в а н и ю в условиях каскадны х
моделе й разр аб от к и , вы , с коре е всего, имеет е оп ы т ре ш е н и я друго й задачи , ко то р а я
довольн о част о встречаетс я в каскадны х моделях. Если н е п ре д п ри н я т ь специальны х
пр ед о ст о ро ж н ос те й , все ошибки , допущенны е пр и форм ули рова н и и тр еб о в ан и й ,
пр и проекти рова н и и систем ы и пр и нап ис ан и и программн ы х кодо в перете к аю т в
организац и ю тестов . В случае п рим е не н и я каскадно й модел и тестова я группа може т
обнаружит ь массу д е ф е к т о в пе р е д самым оконча ние м р аз р аб от о к — де ф ек то в , воз­
ни кн ове н и е к оторы х п ро сле жив ает с я вплот ь д о стади й формулирован и я требова ­
ний , прое ктиров ан и я ил и кодировани я програм мно г о продукта. Возвра т к началу
каскадног о процесс а р а з р а б о т к и сопряж е н с существенны м и трудностям и и больши­
м и затратам и вр е ме н и и средств , поскольку все р а б о ч и е продукты , котор ы е якоб ы
уже прошл и за ве р ш а ющ и е стадии , должн ы подвергнутьс я п овт орн о й проверке .
Несм от р я н а все п ор о ж да е м ы е пробле м ы , каскадна я модел ь дост ой н а того , чтоб ы
е е изучить, поскольку он а соде рж и т основн ы е к омп оне нт ы , необходим ы е для разра­
бот к и программны х продуктов . Незави си м о о т используем о й модели , р аз р а бот к а
програм мно г о об е сп е че н и я должн а начинатьс я с п он и м а н и я того , что нужно постро­
ить , другими словам и , с в ыявлени я и анализ а тр е б о в а н и й . П роц е с с р аз р аб от к и дол­
же н включат ь п рое к т и ров ан и е , кодировани е и т е с т и р о в а н и е невзира я н а то , выпол­
няютс я л и он и в вид е л и н е й н о й последовательност и , чт о х а р а к т е р н о для каскадно й
модели , ил и в рамка х ит е р а т и в н о й последовательност и , х а р а кт е рн о й для моделе й
эволюционног о п рот от и пиров а н и я и поэтапн о й пе ре дачи . М ы используем каскадную
модель в качеств е контекс т а для обсуждения, как добитьс я улучшения процесса , од­
нак о базовы е п ри н ци п ы быс тр ог о тестирован и я должн ы пр и ме нят ь с я независим о о т
выбранн о й модел и ж из н е н н о г о цикла.

Каскадный процесс тестирования

В тр ади ци он н о й каскадн о й модел и (см. рис . 1.2) рол ь орг ан иза ц и и тесто в остаетс я
нея сн о й д о стади й системног о тестирован и я и п р и е м о чн ы х испытани й . Больша я
част ь видов деятельности , характерны х для ранни х стадий , таки х как проектирова ­
ние , кодирован и е и модульное тестировани е , в первую оч ер ед ь связан о с коллекти­
вом разработ чико в программног о обеспечени я . П о эт о й п р и ч и н е имее т смысл по­
строит ь соответствующую модел ь ж изн енн ог о цикл а процесс а тестировани я . И з то­
го, чт о разработ к а динамическ и х тесто в являетс я процессом , в о много м совпадаю­
щим с процессо м разработ к и программног о обеспечени я , следует, чт о каскадная мо­
дель ж изн ен ног о цикл а динамическог о тестиров ан и я довольн о сильн о похож а н а мо­
дель, котора я обсуждалась в предыдущем разделе . П р и м е р каскадн о й модели жизнен ­
ног о цикла процесс а тести рова н и я приводитс я н а рис . 1.3. Обр а т и т е внимани е н а то т
факт , ч т о данна я модел ь описывае т динамическо е т е с т и р о в а н и е , однак о в не й н е от­
ра ж е н о статическо е т е с т и р о в а н и е .
26 Часть I. Процесс быстрого тестирования

Сводка входных и выходных данных для каждой стадии каскадного процесса от­
ладки представлена в таблице 1.1. Далее будет дано краткое описание действий, вхо­
дов и выходов для каждой стадии каскадного процесса тестирования. Другие подроб­
ности рассматриваются в оставшихся главах первой части.

Анализ требований
На этапе анализа требований цели, которые преследует группа специалистов по тес­
тированию и коллектив разработчиков, различаются в ряде аспектов. Обоим коллек­
тивам нужны четкие, недвусмысленные спецификации требований, которые служат
входными данными для их работы. Разработчики желают получить полный набор
требований, которыми можно воспользоваться для формулирования функциональ­
ных требований к системе и которые позволили бы проводить работы по проектиро­
ванию и кодированию программного продукта. С другой стороны, тестовой группе
нужен набор требований, который позволил бы им составить план проведения испы­
таний и выполнить системные и приемочные испытания.
 Глава 1. Поня т и е о технологи и бы ст рог о тестирован и я 27

Оче н ь полезны м вы ходны м документом стади и анализ а требовани й , как для раз­
работчиков , та к и для тес тов о й группы, являетс я матриц а прослеживаемост и требо ­
ваний . Матрица прослеживаемости требований (requirements traceability matrix) представля­
е т собо й документ, к от ор ы й отобра жае т каждое требов ан и е н а промежуточн ы е ре­
зультаты процесс а разрабо тк и , таки е как ко мп он ен т ы проект а , модули программног о
обеспе чен и я и результат ы тестировани я . О н а може т быт ь представлен а в виде элек­
т р о н н о й таблицы , таблиц ы текстов ог о процессора , баз ы данн ы х или Web-страницы.
Матриц а прослеживаемост и требовани й и ее рол ь в "со ед ин ен и и " различны х видов
дея тельнос т и процессо в разработ к и и тестиров ан и я подроб н о рассматриваетс я в
главе 2.
28 Част ь I . Проц ес с быст рог о тестировани я

Планирование испытаний
По д п л ан и ров а ни е м и спы тани й понимает с я оп р е д е л е н и е объемо в и сп ыт ан и й , под­
ходов , ресурсо в и распис ан и я в ы п ол н ен и я н а м ече нн ы х действи й . Дл я тог о чтоб ы
т е ст и р о в а н и е был о э ф ф е к т и в н ы м , необходим о п о т р а т и т ь значительн ы е средств а и
усилия н а пл ан и рова ни е , а такж е быт ь готовы м пере сматри ва т ь это т пла н в динами ­
ке, с о о т в е т с т в е н н о изме н ени я м в требо вани я х , расчета х ил и программны х кода х п о
ме р е вы яв лени я д е ф е к т о в . О ч е н ь важн о , чтоб ы все т р е б о в а н и я подвергли с ь тестиро ­
ванию , л и б о же , есл и т ре б о ва н и я в ы ст ро е н ы п о н е к от ор о й систем е п р и о р и т е т о в , п о
к ра йн е й ме ре , д о л жн ы быт ь п ров е ре н ы т р е б о в а н и я с максимальным и п ри орит ет а м и .
Матриц а пр о сл е ж ив а ем о с т и т р е б о в а н и й явл я ет с я полезны м инструментальн ы м
средство м н а стади и пл а ни рова н и я и сп ыт ан и й , поскольк у он а може т использова ть с я
пр и рас чет е об ъем о в тестировани я , необходимо г о дл я охвата важнейши х тре­
бовани й .
В идеальн о м случае плани рован и е и сп ыт а н и й дол жн о принимат ь в расче т ка к ста­
ти че с к ое , та к и динамическ о е т е ст и р о в а н и е , н о поскольк у процес с т е с т и рова н и я ,
о т р а ж е н н ы й на рис . 1.3 и в табли ц е 1.1, отдае т п р е д п о ч т е н и е динамическом у тести­
рованию , в р е м е н н о остави м статическо е т е с т и р о в а н и е в пок ое . Де й ст ви я , выпол­
няем ы е н а стади и планирован и я исп ытани й , представляю т собо й подг ото вите льн ы е
этап ы дл я этапо в системны х и при ем очны х и сп ыт ан и й , которы е р а с п о л о ж е н ы бл и ж е
к концу каскада, и должн ы включать :
• О п р е д е л е н и е тог о , чт о подлежи т т е с т и р о в а н и ю , и подхода, к от ор ы й п р и это м
будет использоватьс я .
• О т о б р а ж е н и е тесто в н а требования .
• О п р е д е л е н и е критери е в входа и выхода дл я каждо й стади и процесс а тестиро ­
вания .
• О ц е н к а персонала , необходимог о дл я вы пол не ни я тестовы х работ , п о квали­
ф и к а ц и и и степ е н и занятости .
• Оц е н к а врем ен и , необходимог о дл я вып о лн ен и я рабо т п о тестировани ю .
• Пл а н и р о в а н и е основны х этапо в работ .
• Опреде лен и е тес тов о й систем ы (аппаратн ы х и программны х средства) , необ­
ходим о й для проведен и я тестиров ани я .
• Опреде лен и е рабочи х продуктов для каждо й ф а з ы тестировани я .
• Оц е н к а риско в , связанны х с тестир овани е м , и пла н по их уменьшению .
Промежуточны е результаты ил и выходы, являющиес я результатами эти х дейст­
вий , могут бы т ь включен ы в пла н проведен и я исп ыта ни й , кот о р ы й , как правило , со­
стои т и з одног о ил и большег о числа документов. Бо ле е подробн о п лан и ро в ан и е ис­
пыт ани й будет рассматриватьс я в главе 3, а с п р им е р о м план а проведени я и с п ы т а н и й
можн о ознакомитьс я в тр етье й част и книги .

Проектирование тестов, реализации и отладка

Дин а ми чес ко е тестиров ан и е основан о н а вы по лн ен и и заданног о набор а оп е р а ц и й н а
конк ретн о м модуле прогр аммног о продукта и срав не ни и фактичес к и полученн ы х
результато в с ожидаемым и . Если посл е прогон а получе н ожидаемы й результат, счи-
 Глава 1. Поня ти е о технологи и бы ст рог о тестировани я 29

тается , чт о модуль проше л тест . Если зафи кс и рова н о аномально е п о в ед ен и е , тес т

считаетс я неудачным, однак о о н може т оказать с я успешны м в смысл е обнаружени я
де ф ек т а . Зад анны й набо р выполняемы х опе ра ци й образуе т тестовы й случай. Следует
подчеркнуть , ч т о тестовы е случаи должн ы быт ь спроект иров ан ы , закодирован ы и
отла жен ы д о того , как и х м ож н о будет использовать .
П рое к т и ров а н и е тест о в с о ст ои т из двух компонентов : архитекту р ы тесто в и под­
робны х плано в тестов . Архитекту р а тесто в упорядочива е т тест ы п о группам, таки м
ка к функциональны е тест ы , испыт ан и я для оп р ед ел е н и я р а б о ч и х ха р а кте р ист и к ,
проверк а безопасн ост и и т.д. О н а такж е описывае т структуру и соглашен и я по име­
нова н и ю хранили щ а тестов . П од роб н ы е план ы тест о в опи с ыв а ю т н азн ач ен и е каждо­
г о теста , те хн и ч ес к и е средств а и данные , необходим ы е дл я в ып ол не н и я теста , ожи­
даем ы е результат ы каждог о теста , а так ж е указываю т н а т р е б о в а н и е , н а подтвержде­
ни е выполне ни я кот о ро г о ори е нт ир у ет с я данны х тест . Между т ре б ов а н ия м и и пла­
нам и тест о в должн о существовать, п о меньше й мере , отн оше ни е оди н к одному.
Н а основ е плано в тест о в могут быт ь р аз р аб от а н ы под робны е мет о ди к и проверк и .
Уровен ь детализаци и , нео бходи м ы й дл я представ ле н и я м ет о ди к и п ров е р к и в вид е
письменног о документа, зависи т о т квал и фи к ац и и и уровн я з н а н и й персонала , вы­
полняющег о прого н тестов . Следует найт и компромис с между вре м ен е м , необходи­
мы м дл я написани я подробной , последовательно й методики , и временем , которо е
заинтерес ов анн о е л и ц о т р а т и т н а обучени е правильном у в ы п ол н е н и ю тестов . Даж е
есл и тес т долже н быт ь авт ом ат изи р о ва н , в обще м случае зат рат ы в р е м е н и н а заблаго­
вре мен н о е подробн о е опи с ан и е методи к и проверк и оправдываютс я , поскольку пере д
специалисто м п о а вт ом ат иза ц и и ставитс я четка я и однозначн а я задач а автоматиза­
ци и теста .
Ка к тольк о методи к а т е с т и р о в а н и я будет описана , е е потребуетс я п р о в е р и т ь н а
каком-либо модуле п ро гр а мм н о г о продукта. Поскольку, ск оре е всего , это т тес т будет
пр о ве р ят ь с я н а "изобилующе й ошибками " программ е , особ о вниматель н о следует
анализироват ь случаи, когда тес т н е проходит , чт о позволи т опр еделит ь , где нахо­
дитс я п ри чи н а неудачи — в тестир уемо м коде ил и в самом тесте .

Системное тестирование
Н а б о р завершенных , отла женн ы х тес т о в може т использоватьс я и на следующей ста­
ди и каскадного процесс а тестиро вани я , т.е. н а этап е системны х исп ыта ни й . Систем­
но е тестир ован и е проводитс я для удостоверени я того , чт о програм мн о е обеспечен и е
делае т име нн о то , чт о о т нег о ожидае т пользователь . Существуют два основн ы х тип а
системны х испытаний : функциональна я проверк а и исп ыт ани я для опред елен и я ра­
бочи х характеристик .
Функциональная проверка (functional testing) не требуе т от те ст и ровщ и к а знан и й
п ри н ц ип о в работ ы п р ог р а мм н о г о продукта, в т о ж е врем я он а требу е т знани й функ­
циональны х требовани й , предъявляемы х к системе . Он а используе т набо р тестов ,
которы е определяют , вып олняе т л и систем а все то , чт о он а должн а делат ь с точк и
з ре н и я пользователя .
По с л е того , как тестиров а н и е подтвердил о адекватност ь базово й функциональн о ­
ст и систем ы , задаче й т е с т и р о в а н и я становит с я проверка , наскольк о х ор о ш о систем а
выполня е т свои функци и . В рамка х испытаний для определения рабочих характеристик
(performance testing) выполняют с я таки е проверки , ка к т е с т и р о в а н и е в предельн ы х ре-
30 Част ь I . Проц ес с бы ст рог о тестировани я

жимах , нагрузочны е и спы тания , контрол ь си н хрон и зац и и и пров ер к а восстанавли­

ваемости . И с п ы т а н и я н а надежность , н а эксплуатационну ю готовност ь , проверк а
приспособленнос т и к техническом у обслуживани ю такж е мож н о включит ь в числ о
испытани й для о п р е д е л е н и я ра бо ч и х характери сти к .
Пом и м о функци она льн о й прове рк и и испытан и й дл я о п р е д е л е н и я р аб о ч и х харак­
те ри сти к , возможн ы ра з ли чн ы е допо лн ит ел ьн ы е прове рки , про в ед ен и е которы х
може т понадобить с я на стади и системны х и спытани й . В их числ о могут входит ь про­
верк а безопасности , установочн а я проверка , провер к а н а совместимост ь , проверк а
удобства и пр о ст от ы использовани я , проверк а воз м о жн о ст е й наращи вани я . Боле е
подробн о системно е т е ст и р о в а н и е рассматриваетс я в главе 5 и в главах вт о р о й части .

Приемочные испытания
П о завершени и системно г о т е ст и р о в а н и я продукт може т бы т ь переда н пользовател ю
для провед ен и я прие мочн ы х исп ытани й . Если пользовател и принадл еж а т то й ж е
компании , чт о и р а з р а б о т ч и к и , тако е т ес ти р ов а н и е об ы ч н о называет с я альфа-
тестированием (alpha testing). Если пользователя м и явля ют с я заказчики , готовы е рабо­
тат ь с программны м продукто м ещ е д о его офи ци а ль н о й готовн ост и , т о та к о е тести­
ровани е называетс я бета-тестированием (beta testing). И альфа-, и бета-тестировани е
представляю т собо й соответствующи е ф о р м ы контрольных испытаний (pilot tests), в
условиях к оторы х систем а устанавливаетс я на экспериментальн о й баз е с цель ю выяв­
ле ни я деф е кт о в .
Друго й фо рм о й приемоч ны х испытан и й являют с я аттестационные испытания
(benchmark test), когда заказч и к выполня е т заране е оп р е д е л е н н ы й набо р тестовы х слу­
чаев , имитирующ и х т и п овы е условия, в которы х систем а будет работ ат ь посл е ввода
в эксплуатаци ю . Дл я аттестацион н ы х испытан и й могут быт ь использован ы тестовы е
случаи, кот оры е р а з р а б о т а н ы и отлажен ы ваш е й тестирующе й орг анизаци е й и кото­
р ы е в т о ж е врем я был и п ров е ре н ы и одоб р ен ы заказчиком . П о зав ерше ни и кон­
тр о ль н ы х и аттестационн ы х испыта ни й заказчи к долже н уведомит ь вас, каки е требо ­
вани я н е удовлетворены , а каки е должн ы быт ь изменены , чтоб ы можн о был о пер ей т и
к заключительны м испытаниям .
Заключительн ы м типо м пр ие м о чн ы х испытани й являетс я установочная проверка
(installation test), по условиям к от о р о й завершенна я верси я программног о продукта
устанавливаетс я на площадках заказчик а с целью получить от нег о подтверждение ,
чт о программн ы й продукт соответствуе т всем требовани я м и заказчи к согласен на
его поставку.

Сопровождение
Сопровожден и е программног о продукта част о стави т разработ чик о в и тестировщи -
ко в пере д необходимость ю реш ени я оп ре де л ен н ы х задач. Сопровожден и я для разра­
ботчик а — эт о исправлен и е дефектов , которы е был и обнаружен ы заказчико м в о вре­
мя эксплуатаци и программног о продукта, а такж е ра с ши ре н и е функциональны х воз­
можносте й продукта, кото ро е приз ван о удовлетворит ь возросши е требовани я заказ­
чика. Ч т о касаетс я ор ган и зац и и тестировани я , т о сопровожден и е означае т проверк у
результатов исправ лен и я дефектов , тестирован и е ра с ши р ен н ы х функциональн ы х
возможн ост е й и выполнени е регрессионных тестов (regression tests) на новы х версия х
 Глава 1. По ня т и е о технологи и быстрог о тестирован и я 31

програм мно г о продукта. Цел ь всег о этог о заключает с я в полу чен и и подтверж ден и я
того , чт о ране е исправн о ра б ота в ш и е функциональны е средств а н е пострадал и о т
внесени я изменени й в программн ы й продукт.
Каким и б ы н и был и ва ж ны м и прие мочн ы е испытани я и со п р о в о ж д е н и е про­
граммног о продукта, в дан но й книг е о н и подроб н о н е обсуждаются. Баз овы е принци ­
п ы рег р ес си о нн о г о т е с т и р о в а н и я и в е ри фи к а ц и и де ф е к т о в хо р о ш о вписывают с я в
эт и ф а з ы жизненног о цикла . З а подробны м анализо м с оп р о в о жд ен и я програм мног о
об е сп е че н и я в перспектив е т е с т и р о в а н и я рекомендуе м обр атитьс я к [30 ] .

Связь тестирования и разработки

В нескольки х предыдущих раздела х бы л и опис ан ы каскадны е модел и процесс а разра­
бот к и програ ммног о об е сп е че н и я и процесс а тестировани я . У обои х моделе й общи е
исходны е и кон ечны е точки , однак о группы р аз р а б о т ч и к о в и тестировщи к о в все
врем я зан ят ы различным и видам и деятельности . В это м раздел е д а н ы оп и с а н и я двух
моделей , которы е связыва ю т об а э т и вида деятельност и воедин о .
О ди н и з способо в п ро де м он ст ри р о ва т ь , как соотносятс я т е с т и р о в а н и е и разра­
ботка, показа н на V-образной диаграмм е , изображенн о й на рис . 1.4. В э т о й модели, на
котору ю такж е ссылаютс я как н а шарнирно-каскадную , оба вида деят ельн ост и , анали з
и проекти рова ни е , образую т левую сторон у V. Коди ров ан и е находит с я в само й ниж­
не й то ч к е диаграммы , а т е с т и р о в а н и е образуе т е е правую сторону . Дл я пр ост от ы из­
ложен и я , вид деятельности , подобны й сопр о в о жд ен и ю , н а диаграм м е н е показан .
32 Част ь I . Про ц ес с быстрог о тестировани я

П ун кт ирн ы е л и н и и с о стрелкам и н а конца х оп ред ел яю т отношени я между видом

тестово й деятель нос т и н а право й ст орон е и видом п рое кт н о й деятельност и н а левой .
Сама я верхня я пунктирна я ли ни я с о ст ре л к ам и показывает , чт о цел ь приемочн ы х
ис п ыта ни й заключает с я в подтверждени и т р е б о в а н и й , а сам и п ри е м оч н ы е испыта­
ни я осн ова н ы н а требова ния х . Аналогично , системны е испыта н и я служат для про­
верк и проект а систем ы , а системны е тест ы получен ы п о результатам проектиров ан и я
систем ы . Следовательн о , одн о из назначен и й V-диаграммы состои т в том , чтоб ы по­
казат ь , каков а цел ь видо в тестово й деятельн ос т и в терм ина х конт ро л я и аттестац и и
н а ра н н и х стади я х р аз ра б о тк и .
Н е с м от р я н а т о чт о V-диаграммы служат ил л ю ст ра ци е й отношени й , связывающи х
разработ к у и т е с т и р о в а н и е , он а н е от ра жа е т двух параллельны х потоко в деятельн о ­
сти , к от ор ы е две эт и группы специалисто в осуществляю т в процесс е р а з р а б о т к и . Ил­
л ю ст р ац и е й одног о и з способ о в показат ь отдельны е действи я , связанны е с разработ ­
ко й и тести р о ва ни е м , служит параллельн а я каскадна я модел ь на рис . 1.5.
Эт а диаграмм а нескольк о сложн е е предыдущи х моделей , однако , он а обладае т не­
скольким и важны м и свойствами , котор ы е оправдываю т налич и е д о п о л н и т е л ь н о й
сл о ж но ст и .
• О т ч ет л и в о видн ы параллельн ы е поток и ра з р а б о т к и и тестировани я .
• Стрелка , соединяюща я системно е т е с т и р о в а н и е и проекти рован и е систем ы ,
го в ор и т о том , чт о цел ь стади и системно г о те ст ир о ва н и я заключает с я в про­
верк е прое кт а систем ы .
• Стре лка , соединяюща я прие м очн ы е и сп ыт ан и я с требованиями , показы вае т ,
чт о н азн ач ен и е приемочны х и сп ыт ан и й заключает с я в подтвержден и и требо ­
ва ни й .
• Аналогичн ы е стрелк и говоря т о том , чт о назначе ни е т е с ти р о в а н и я модулей и
п ров е р к и взаимодействи я и функ ци они ров ан и я компонент о в систем ы заклю­
чает с я в контрол е р азр а бо т к и програм м ы , а цел ь отладк и тест о в состои т в кон­
тр о л е разработ к и тестов .
• Кажда я оставшаяс я стади я поток о в разработк и и тестиро ван и я имее т "пет л и
обратно й связи" , назна че ни е которы х заключаетс я в проверк е того , чт о про­
межуточны е результат ы системног о пр о ект и ро в ан и я , пр ое кти р о ва н и я про­
грамм , пла ни р о ва н и я ис п ыта ни й и тому подобного , соответствую т требовани ­
ям, предъявленн ы х к ним в начал е соответствующ е й стадии. Така я пров ерк а
выполняет с я в рамка х статическог о тестиро вани я .
Н е с л о ж н ы й анали з рис . 1.5 показывает , почему тестирован и е программног о обес­
пе чени я являет с я стол ь ответственн о й и трудоемко й задачей . Да ж е пр и работ е в тра­
д и ц и о н н о й каскадн о й сред е группа специалисто в п о отладк е должн а уметь вып о л нят ь
ш и р о к и й спект р действий , каждое и з кото ры х зависи т о т результатов деятельн ос т и
коллектив а разработчико в . Между потокам и разработк и и тестирован и я этог о про­
цесса долже н надежн о поддерживатьс я обме н данными , и каждая группа должн а уча­
ствоват ь в некоторы х контрольн ы х действия х другой группы. На п р и м е р , группа тес-
ти р о в щ и к о в должн а участвовать в ко нтр о л е системног о пр ое кт ир о ва ни я , а группа
разраб отчик о в — пр ини м ат ь участие в про верк е план а тестировани я .
Глав а 1 . П о н я т и е о т е х н о л о г и и б ы с т р о г о т е с т и р о в а н и я 33
34 Часть I. Процесс быстрого тестирования

Что дальше
В этой главе были даны определения основных понятий тестирования программного
обеспечения. Идея быстрого тестирования представлена как способ ускорения тес­
тирования без ущерба для качества программного продукта. Мы установили, на­
сколько важна роль персонала, собственно процесса, статического тестирования и
динамического тестирования для организации эффективного процесса быстрой от­
ладки. Были исследованы каскадный процесс разработки программного обеспечения
и динамический процесс тестирования, и в результате обнаружено, что оба они
должны быть тесно интегрированы, если мы заботимся о высокой эффективности
работ по тестированию. Наконец, были рассмотрены V-диаграмма и параллельная
каскадная модель как средства, связующие воедино процессы разработки и тестиро­
вания.
Интеграция процессов тестирования и разработки была начата с построения па­
раллельной каскадной модели, однако впереди еще предстоит проделать большую
работу, прежде чем определение процесса быстрого тестирования будет окончатель­
но сформулировано. Потребуется проанализировать каждую стадию процесса тести­
рования на предмет возможной оптимизации ее скорости и эффективности. Эта ра­
бота будет начата в следующей главе.
 Анализ требований
и тестирование
Темы, рассматриваемые в главе:
• Процесс формулирования требовани й
• Тестирование требовани й
• Чт о дальше

В предыдущей главе мы установили, что в целях ускорения производства программ­

ного продукта, разработка и все виды тестовой деятельности должны тесно интегри­
роваться. Такая интеграция разработки и тестовой деятельности должна начинаться
на ранних стадиях процесса разработки, когда формулируются требования к разраба­
тываемому программному продукту при непосредственном участии пользователя. Для
проектирования системы программного обеспечения коллективу разработчиков не­
обходим четкий набор требований, в то же время группе специалистов по отладке
также необходимы четко сформулированные, однозначные требования, что даст
возможность составить план тестирования и проекты тестов. Если оба коллектива
вступают в сотрудничество на ранних стадиях процесса разработки, то велика веро­
ятность того, что им удастся сформулировать необходимые требования уже на ран­
них этапах временного графика.
Другая причина привлечения к сотрудничеству группы специалистов по тестиро­
ванию на стадии формулирования и анализа требований к программному продукту
продиктована необходимостью проведения статического анализа этих требований. В
отчете группы Standish Group по обследованию более чем 350 компаний, опублико­
ванном в 1994 году, сообщается, что только 9% из свыше 8000 проектов создания
программных продуктов были выполнены в срок и уложились в финансовую смету
[48]. Тридцать один процент всех проектов были аннулированы еще до их заверше­
ния. Последующие исследования [49] проводились с целью выявления причин не­
удачных проектов. Исследование основных факторов, вызвавших перерасход средств
на создание продукта или неудачу проекта в целом, показали, что более чем в 50%
случаев эти факторы имеют отношение к процессу выработки требований к про­
граммному продукту. Основные факторы, имеющие отношение к процессу формули­
рования требований, перечисляются ниже; там же указано и процентное отношение
36 Част ь I . Про ц ес с бы строг о тестировани я

проектов, дл я которы х соответствующа я проблем а стала факторо м , повлекш и м з а

собо й прова л проект а :
• Н е п ол н о т а тр е б о в а н и й (13.1%)
• Неучаст и е пользовате л я в разр аб от к е т р е б о в а н и й (12.4%)
• Н е ре а л и с т и ч н ы е ожидани я (9.9%)
• И зм е н е н и е тр е б о в а н и й и с п е ц и фи к а ц и й (8.7%)
• Отпал а п о т р е б н о с т ь в систем е (7.5%) .
Одни м и з результато в этог о отчет а являет с я вывод о том , чт о больш о е числ о де­
фе к т о в мо же т быт ь внесен о в продукт уже н а стади и формулирован и я т р е б о в а н и й .
Когда д е ф е к т ы попадаю т в требования , возникае т и х волнообразн о е распр ост ран е ­
ни е н а весь процес с р аз р а бот к и , устранен и е последстви й кот о р ог о требуе т больши х
затра т средст в и времени . Бое м (B oeh m ) и П а п а чч и о (Papaccio ) (кот оры е цитируют­
ся в [42] ) утверждают , чт о есл и затрат ы на обнаружен и е и устранен и е д е ф е к т а на ста­
ди и формули рован и я т р е б о в а н и й составляю т $1 , т о н а стади и п рое к ти ров ан и я эт и
затрат ы увеличиваютс я до $5, на стади и кодировани я — $10, на стади и модульного
т е ст и р о в а н и я — $20, а посл е поставк и п р ог ра м мн о г о продукта заказчик у ст ои мо ст ь
раб о т п о у ст р ан ен и ю тог о ж е де ф ек т а достигае т $200. Диаграмм а , иллюстриру ющ а я
затрат ы н а у ст ра н ен и е деф ек т а н а разны х стади я х р а зр аб от ки , показан а н а рис . 2.1 .
П о больше й част и така я эскалаци я затр а т связан а с необходимост ь ю п о в т о р н о г о вы­
п ол н е н и я р аб о т н а стадии , предшествующе й т о й , н а к от ор о й это т д е фе к т бы л обна­
руже н и устранен .
 Глава 2. Анализ требовани й и тестировани е 37

Опубликованны й группо й Standis h G r o u p анали з данны х , к от о р ы й имее т цель ю

определит ь п ри ч и н ы неудачног о завершен и я проекто в и стоим о ст ь устранени я де­
фект о в не на ранних , а на поздни х стадиях цикла раз р аб от к и , недвусмысленн о свиде­
тельствует в пользу п рим е н ен и я статическо г о т е ст и р о в а н и я н а стади и формулирова­
ния тр е бо в ан и й с тем , чтоб ы пред отв рати т ь п рон и к н ов е н и е д е ф е к т о в н а боле е позд­
ние стадии .
Дв е прич и н ы для привлеч ени я тестово й группы дл я участи я н а ра нн е й стади и
формулировани я тр е б о в а н и й могут быт ь опр ед ел е н ы следующим образом :
• Тестова я группа заинте рес ов а н а в как можн о боле е ран не м получен и и макси­
мальн о т о ч н о й с п е ц и ф и к а ц и и , н а основ е кот ор о й м ож н о составлят ь план тес­
тировани я и п р о е к т и р о в а т ь тест ы . Эт о основно е условие , бе з выполнен и я ко­
тор ог о те ст и р о в а н и е н а ра н ни х стадиях н е дае т по л о ж ит е л ь н о г о э ф фе к т а .
• Тестова я группа должн а прово ди т ь статическо е т е с т и р о в а н и е сп е ц и фи к а ц и й
т р е б о в а н и й с тем , чтоб ы пред отвр ати т ь попадани е д е ф е к т о в н а боле е поздни е
стади и раз р аб от к и . Успешн о е статиче ск о е т е с т и р о в а н и е н а стади и формулиро ­
вани я т р е б о в а н и й позволяе т сэкономи т ь врем я и зат ра т ы .
В данно й главе мы обсуждаем процес с формулирова н и я т р е б о в а н и й с т о ч к и зре­
ни я специалист а по т е с т и р о в а н и ю . Обсуждение начинает с я с опрос а пользовател я с
целью выявлени я тр е б о в а н и й и анализ а задач, оп ре д ел ен и я к он крет н ы х рабочи х
продуктов и точе к этог о процесса , в которы х можн о п ри м е н и т ь стат и че с к о е тестиро­
вание. Мы также рассмотри м тип ы требований , необходимых для обеспечен и я полноты,
и предложим возможны е способы тестирован и я требовани й . Кром е того, обсуждается
возможность использования прототипо в программного продукта пр и анализе требова­
ний, равн о как и рол ь тестирован и я жизненног о цикла, основанног о на прототипах.

Процесс формулирования требований

Пр о ект ы п о создани ю программног о обеспечен и я на чи на ю т сво й ж и з н е н н ы й цикл,
когда у заказчик а возникае т необходимос т ь заменит ь существующую систему ил и по­
требност ь в совер шен н о ново й системе . Заказчико м може т бы т ь люб о й отдел ваше й
компании , отдельна я комп ани я ил и агентств о , которо е заключае т с вами догово р н а
выполнени е работ . В качеств е заказчик а може т такж е выступат ь р ы н о к товаро в мас­
совог о производств а с активны м спросо м на готовы е програм мн ы е продукты. По­
требност и заказчик а могут бы т ь представлен ы наборо м т ре б о ва ни й , где под требова­
нием {requirement) понимает с я о пис ан и е того , чт о способн а вы п ол н ят ь система, либ о
описан и е нек оторы х условий ф ун кц ио ни ро в ани я , к о то р ы е необходим о обеспечит ь с
тем, чтоб ы систем а могла вып ол н ят ь свои задачи. Тр еб о ва н и я определяю т то , что
должн а выполнят ь система , н о н е то , как он а должн а эт о выполнят ь . Последне е озна­
чает, чт о в центр е вним а ни я требовани я находитс я задач а заказчик а и его деловая
активность , н о н е то , как достигаетс я е е решение .
Рисунок 2.2 служит иллюстрацие й процесс а формулирован и я требован и й к систе­
м е программног о обеспечени я . М ы исследуем это т процес с с т оч к и з р е н и я специали­
сто в п о тестировани ю , ко т о р ы е стремятс я получить и н ф о р м а ц и ю , поддерживающ у ю
планирова н и е т е с т и р о в а н и я н а ра н ни х стадиях раз р аб от к и , ст рем ят с я обнаружит ь
д е ф е к т ы уже в сами х тр еб овани я х , чтоб ы о н и н е и ни ци иров а л и лавину ошибо к н а
боле е поздни х стади я х раз р аб от ки .
38 Часть I. Процесс быстрого тестирования

Первым на рис. 2.2 показан опрос заказчика с целью выявления требований, ко­
торые он предъявляет к программному продукту. Выявление требований выполняет­
ся в форме вопросов и ответов. С использованием слайдов, макетов и прототипов
заказчику предлагаются различные варианты. Сбор пожеланий со стороны заказчика
может осуществляться в виде серии интервью или путем использования технологии
FAST (Facilitated Application Specification Techniques - технология упрощенной спе­
цификации приложения), представляющей собой специальный тип собеседований с
заказчиком, который облегчает выявление его требований.
По мере получения от пользователя, требования должны фиксироваться в виде
документа, известного как документ определения требований (requirements definition docu­
ment). Этот документ оформляется в виде списка требований, сформулированных в
результате собеседований с заказчиком. Он представляет собой соглашение между
заказчиком и организацией, выполняющей разработки, о том, что должно создавать­
ся. Определение требований представляет собой письменный документ на естест­
венном языке, вполне понятный как заказчику, так и коллективам, которые занима­
ются разработкой и сопровождением системы.
Достоинство документа определения требований состоит в том, что его легко по­
нять, но в то же время ему не хватает точности и технических деталей, необходимых
для проектирования и разработки программного продукта. В силу этого обстоятель­
ства должен быть подготовлен другой документ, известный как спецификация требова­
ний (requirement specification) или функциональная спецификация (functional specification).
Хорошим пособием для первого знакомства с основными понятиями и терминологи-
 Глава 2. Анализ требований и тестирование 39

ей, используемой при подготовке спецификаций требований, могут служить публи­

кации [47], [43] и [42].
Как только документ определения требований и спецификации требований будут
готовы, можно приступать к построению матрицы прослеживаемости требований (re­
quirements traceability matrix). Назначение этой матрицы состоит в том, чтобы поставить
в соответствие каждому требованию тесты, компоненты проекта и программный код.
В идеальном случае в этой работе принимают участие коллективы разработчиков и
специалистов по тестированию, в результате чего со временем появятся связанные с
каждым требованием проектные компоненты, тесты программных модулей, тесты
комплексных и приемочных испытаний. При правильном использовании матрица
прослеживаемости требований представляет собой инструментальное средство, ко­
торое помогает каждому специалисту, принимающему участие в процессе разработ­
ки, выполнять работу, непосредственно связанную с потребностями заказчика, и не
тратить понапрасну время на решение ненужных задач. С точки зрения группы тес­
тирования этот инструмент может с успехом использоваться для планирования тес­
тирования и проектирования тестов, обеспечивающих хорошее тестовое покрытие.
В нескольких следующих разделах мы проведем более подробное изучение видов
деятельности и рабочих продуктов процесса формулировки требований в перспекти­
ве тестирования.

Выявление требований
Обмен информацией между заказчиком и разработчиком в процессе определения
требований к программному продукту настолько важен для успеха всего проекта, что
для достижения его эффективности затрачиваются значительные усилия и средства.
Одним из факторов, способных снизить эффективность такого обмена, является не­
достаточный объем знаний заказчиком методов разработки программных продуктов.
Довольно часто заказчик не настолько разбирается в процессе разработки программ­
ного обеспечения, чтобы быть способным выразить свои требования в форме, по­
нятной специалисту по разработке системы.
Процесс определения системы программного обеспечения можно сравнить с
проектированием дома по индивидуальному проекту: может случиться так, что вы не
настолько хорошо разбираетесь в строительстве, чтобы точно сказать, что вам нуж­
но. Обмен мнениями, по всей видимости, должен включать осмотр уже построенных
домов, изучение планировки помещений с целью выбора понравившейся, а также
изучение некоторого множества других индивидуальных проектов и чертежей. Что
касается систем программного обеспечения, то часто полезно продемонстрировать в
работе существующее программное обеспечение, ознакомиться с соответствующими
документами или прототипами программного продукта и обсудить рабочую среду, в
которой будет использоваться программный продукт. Результаты такой работы с за­
казчиком вызывают непосредственный интерес и у группы, проводящей тестирова­
ние. Специалисты этой группы желают знать, как заказчик намерен использовать
программное обеспечение, дабы спроектировать реалистичные тесты для системных
и приемочных испытаний.
Один из классов методов, которые могут быть использованы для выявления тре­
бований, получил название технологии FAST (Facilitated Application Specification
Techniques— упрощенной спецификации приложения). Наиболее распространен-
40 Част ь I . П ро ц е с с быстрог о тестировани я

ны м подходо м в рамка х реализ аци и технолог и и FAST яв ля ет с я разра бота нн ы й ком­

пание й IBM метод JAD (Join t Applicatio n Develop m en t — совместн а я р азр а бо т к а при­
ложения ) [43] . Друго й метод , JAR (Joint Applicatio n R e qui r e m e n t — совместн а я разра­
ботк а т р е б о в а н и й к п ри л ож е ни ю ) , был предложе н Гэр и Коббо м (Gary Cobb ) и описа н
в главе 8.
О б ы ч н о в о врем я сеанс а технолог и и FAST рекомендуетс я следоват ь тому ил и
иному набор у услови й и з числ а приведенны х ниж е [43] :
• И заказчики , и ра з р а б о т ч и к и при н им аю т участи е в совещании , посвященн о м
вопр оса м о п р е д е л е н и я тре бо в ан и й .
• Установлен ы правил а подготовк и и участия в совещании , которы м следуют об е
стороны . Д о л ж н а быт ь установлен а ат мо с ф ер а , содействующа я успеху совеща­
ния .
• Совещани е п р о в о д и т с я под управлени е м посредника . Так и м посреднико м мо­
же т быт ь заказчик , раз ра ботчи к ил и кто-то п ост орон ни й , приемлемы й дл я
обеи х сторон .
• Дл я фи к с а ц и и т р е б о в а н и й используются таки е средства , как л е к ц и он н ы е пла­
ка т ы с ре й к о й , н аст е нн ы е ин ди к ат орн ы е панел и ил и пр о ст а я л ен т о ч н а я бумага.
• Цел ь совещан и я — опре дели т ь задач и ил и п от р е б н о с т и заказчика , предл ожи т ь
решени е , обсудить различны е подходы и определи т ь набо р тр е бо в ан и й .
Настояте льн о рекомендует с я участие в это м совещан и и специалист а п о отладк е
ил и даж е нескольк о упростит ь регламен т совещани я п о технолог и и FAST с таки м
расчетом , чтоб ы в это м совещани и могли использ овать с я элемент ы статическог о
тестиров ани я . Т е хн о л ог и я JAR, описанн а я в главе 8, о со б о благоприятствуе т встро­
енном у статическом у т е ст и р о в а н и ю , кот оро е в т е р м и н о л о г и и JAR называет с я "вспо­
могательна я поддержка" .
Одни м и з вид о в и н фо р м а ц и и , котору ю можн о извлеч ь в результате пр о в ед ен и я
м е роп ри ят и й п о выявле ни ю тр еб о ва ни й , являет с я соглашени е между заказчико м и
разраб отчик о м относитель н о пр ио р ит ет о в требован и й . На п р и м е р , каждое требова ­
ни е може т быт ь отн е се н о в одну и з следующих катего р и й :
• На и б о л е е важн ы е требовани я .
• Тре б ов ан и я , в ы п о л н е н и е которы х крайн е жела т ел ь н о .
• Тр еб о ва ни я , вып о лн ен и е которы х жела тельн о , н о н е обязательно .
Благодар я такому распределени ю п р и о р и т е т о в упрощаетс я выполнен и е план а
разработок . На п р и м е р , можн о составит ь план , к о т о р ы й стави т выполнен и е наиболе е
важны х требовани й в рамка х перво й верси и программног о продукта, реализац и я же­
лательны х тре бов ан и й во второ й верси и и всех остальны х — в тр етье й версии . Ана­
логично , группа тес ти р о ва н и я може т начат ь разработк у тесто в для требован и й с наи­
больши м п р и о р и т е т о м в первую очередь . Та к о й ти п нарастающи х поставо к ил и по­
ставо к версиями , час т о используетс я в те х случаях, когда решающе е зна чен и е имее т
соблюдени е временн ог о график а работ .
Нужн о рас с мотр е т ь специальн ы й случай, когда о т специалисто в п о тестир ован и ю
требуется провест и испы т ани е программны х продуктов , к которы м н е предъявлен о
никаки х т р е б о в а н и й , л и б о случай, когда н е вс е т р е б о в а н и я выявлены . К с о ж а ле н и ю ,
 Глава 2. Анализ требовани й и тестировани е 41

упомянутые ситуац и и встречаютс я довольн о част о ; достат оч н о вспомнит ь да нны е

группы Standis h G ro u p , приведенн ы е в начал е главы, в которы х перво й и з п рич и н
неудачи проект а ил и нарушени е сроко в ег о разработ к и был а назван а непол нот а тре­
бований. Од и н и з а вт ор о в это й книг и вспоминае т исключительн у ю ситуаци ю , когда
специалисту по тестировани ю передал и компакт-диск с программо й и поп роси л и вы­
полнить е е тестирован и е — н о там н е был о никак о й документации , н е говор я уже о б
описани и набор а требовани й .
В ситуации , когда сп ецифи каци я требован и й отсутствует, у вас, возможно , не ос­
тается другого выбора , ка к тольк о написат ь с обст вен н ы й докумен т определени я тре ­
бований . В зависимост и о т того , скольк о времен и выделен о н а Завершени е тесто вы х
работ, полученно е определен и е требован и й мо же т оказатьс я н е таки м исчерпыва ю ­
щим, как этог о б ы хотелось , н о очен ь важно , чтоб ы был и о пр е де л ен ы все ключевы е
требования . Не в оз м ож н о тестироват ь программн о е обеспечени е , есл и не т более-
менее т оч н ы х опред еле н и й необходим ы х функ ци он а ль н ы х средств . Если в ы столкну­
лись с затруднениям и п р и определени и требован и й , возможно , потребуетс я провес­ ти
JAR-сеанс с генеральны м разработчико м и, желательн о , с представител я м и группы
маркетинг а и заказчико м . По меньше й мере , можн о будет взят ь интервь ю у предста­
вителе й разработчи к а и группы маркетинг а и сф о рм у ли р о ва т ь по возможност и пол­
ные определени я требовани й , наскольк о эт о позволяе т отпущенно е вам время .

ВЫЯВЛЕНИЕ ТРЕБОВАНИЙ ПРИ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ РАЗРАБОТКЕ

В условиях объектно-ориентированного похода требования определяются через случаи
использования. Случай использования (use case) есть описание т ого , ка к функция
должна выполняться с точки зрения внешнего пользователя или системы. Совокупность
всех возможны х случаев использования описывает функциональные возможност и систе­
мы в ц е ло м .
Каждый случай использования обычно представлен в формат е диаграммы , показываю-
j щей используемые объекты плюс текстовое описание (получившее название текста сце ­
нария) т о го , как выполняется соответствующая функция . Обычно прощ е всего опреде-
лить системные испытания через случай использования, поскольку такой случай не дает
никакого представления о т о м , как система выполняет соответствующую функц и ю , зато
четко определяет, какие функциональные возможност и должн ы быть реализованы. Сле­
довательно, в основу проекта системных испытаний непосредственно м огу т быть поло­
жен ы случаи использования, при это м для к а ж д о г о случая использования разрабатывает­
ся, по меньшей м е р е , один тест.
Информация о тестировании случаев использования изложена в главе 10.
Врезка 2.1
42 Часть I. Процесс быстрого тестирования

Определение требований
Документ определения требований содержит все требования, предъявляемые к сис­
теме и сформулированные на естественном языке, благодаря чему они становятся
понятными и заказчику, и тем, кто принимает участие в разработке проекта. В пер­
спективе тестирования мы заинтересованы в получении из этого документа инфор­
мации, достаточной для того, чтобы иметь возможность приступить к планированию
и разработке тестов. Для наших целей определения требований должны обладать
следующими свойствами:
• Каждое требование должно быть снабжено уникальным идентификатором,
чтобы можно было однозначно ссылаться на него при планировании тестового
покрытия, при проектировании тестовых случаев и в отчетах по результатам
тестирования.
• Требования должны быть представлены с точки зрения пользователя системы.
Системные и приемочные испытания должны быть спроектированы на основе
определений требований, следовательно, эти определения должны быть сфор­
мулированы в перспективе системного уровня. Этот принцип препятствует по­
явлению требований, затрагивающих внутренние свойства системы и требую­
щих детальных знаний программного кода для успешного тестирования. Такие
требования должны возникать на поздних стадиях разработки и охватываться
модульным тестированием и проверкой взаимодействия и функционирования
компонентов системы.
• Должны быть включены как функциональные (Junctional), так и нефункциональные
(nonfunctional) требования. Функциональные требования суть требования, опи­
сывающие услуги и функции, которые должна выполнять разрабатываемая сис­
тема. Нефункциональные требования описывают ограничения, накладываемые на
работу системы, например, количество одновременно работающих пользо­
вателей, и стандарты, которым должна соответствовать система.
• Документ определения требований должен находится под управлением конфи­
гурациями. Это, по меньшей мере, означает, что данный документ подпадает
под управление версиями и что все версии документа должны быть помещены в
безопасное хранилище, подобное, например, каталогу, содержимое которого
обычно дублируется. Если требования подвергаются изменениям, мы должны
иметь возможность проследить, чтобы соответствующие изменения были вне­
сены в тестовые случаи системных и приемочных испытаний.
Оглавление одного из возможных вариантов документа, содержащего системные
требования, представлено на рис. 2.3. Это оглавление соответствует стандарту IEEE
Standard 830: The IEEE Guide to Software Requirements Specifications [23] — Руководящие
принципы IEEE по составлению спецификации требований к программному обеспе­
чению. Пример документа определения требований, соответствующего рис. 2.3, при­
водится в третьей части книги. Этот пример может принести определенную пользу,
если вы окажетесь в ситуации, когда необходимо будет составить собственный доку­
мент определения требований. Кроме того, он может оказаться полезным при прове­
дении статического тестирования различных документов, основанных на определе­
нии требований.
 Глава 2. Анализ требований и тестирование 43

Документ определения требований, показанный на рис. 2.3, включает общее опи­

сание, которое показывает, какими достоинствами обладает данный продукт перед
другими продуктами этого типа, и описание его функциональных возможностей. В
нем дано краткое описание основных свойств продукта и указано, какой квалифика­
цией должен обладать пользователь, чтобы работать с ним. В то же время документ
не содержит подробного описания функциональных средств. Раздел специальных
требований содержит определения функциональных требований, требований к про­
изводительности, к интерфейсам и ряд других требований. Рассматриваемый доку­
мент должен содержать определения сокращенных обозначений (акронимов) и тех­
нической терминологии, используемой для описания продукта.
Как только документ определения требований будет написан, он должен быть
подвергнут статическому тестированию с целью проверки требований на полноту,
непротиворечивость, осуществимость, контролепригодность, однозначность и реле­
вантность.
Т и п ы т р ебован и й . Выше мы определили требования как описание того, что
способна сделать система, либо как условия эксплуатации, которые необходимо
обеспечить для того, чтобы система была способна выполнять возложенные на нее
задачи. Это подразумевает использование широкого диапазона различных сведений,
44 Част ь I . Про ц ес с быстрог о тестировани я

поэтом у полез н о разб и т ь тр е б о в а н и я н а ка те го р и и . П р и м е р набор а таки х к а т е г о р и й

представле н следующим списком :
• Функциональные средства . Это т набо р требовани й определяет , каки е функ­
ц и и долже н выполнят ь да нны й програм мн ы й продукт н а системно м ил и поль­
зовательс ко м уровне . Дл я ясност и мо же т быт ь указано , чег о н е должен делат ь
данны й продукт.
• И нт е р фей с ы . Эт а кате го ри я т р е б о в а н и й описывае т входы , получаемы е и з
внешни х систем , и выходы , направляемы е в о внешн и е системы . Накладывают ­
с я л и н а эт и и н т е рфе й с ы какие-то огран ич ен и я , связанны е с ф о р м а т а м и дан­
ны х и носителям и ин форма ци и ?
• Данные . Эт и треб ов а н и я опи сы в а ю т входны е и выходны е данны е систем ы .
Како й п р и это м используетс я формат ? Каки е данны е нужно сохранять ? Как о й
объе м данны х поступает в систему и из систем ы , и с како й скоро ст ь ю передачи ?
С как о й точн ост ь ю до лжн ы выполнять с я вычисления ?
• Производительность . Требо вани я это й кат ег ор и и описываю т проблем ы мас­
штабирова н и я и син хрон изаци и , н ап рим е р , скольк о пользовател е й одновре ­
м е н н о должн а обслуживать систем а , скольк о тра нз ак ц и й должн а вы полнят ь
систем а в единиц у времени , как долг о пользовате л ь долже н ждат ь ответ а н а
сво й запрос . Следует соблюдат ь особую осто р о жн о с т ь пр и в ы р а ж е н и и эти х
т р е б о в а н и й в числовы х значениях , поскольк у в дальнейш е м их придетс я под­
тверждать .
• Пользовател и и человечески й фактор . Эт а категор и я т р е б ов а н и й предъявля ­
етс я к тем , кт о будет работат ь с систем о й в смысл е их к в а л и фи к а ц и и и опыт а .
О н и так ж е оп реде ля ю т необходимы й уровен ь удобства и пр о ст от ы использо ­
вани я програ ммно г о продукта, н ап рим е р , скольк о отдельны х дейст ви й требу­
етс я дл я вып олнен и я рути нн о й оп е ра ц и и в системе? Наск оль к о от ч етли в о вы­
р а ж е н а о б рат н а я связ ь посл е каждог о действи я ?
• Физическа я среда. Эт а категори я требован и й определяет , где должн о функ­
ци они р о ват ь оборудование . Установлен о л и оборудовани е боле е че м в одно м
месте? Име ю т л и мест о ог ра ни чен и я п о температур е , влажност и ил и другие ог­
р а н и ч е н и я , связанн ы е с окружающ е й средой ?
• Безопасность . Эта категори я требован и й описывает , как осуществляетс я дос­
туп к систем е и как ос уществляетс я управлени е ее данными . Данна я категори я
являет с я подходящи м место м для оп ис ани я , как должн ы дублироватьс я систем­
н ы е данные . Ка к част о следует выпо лнят ь дублирование? Н а каки х носителя х
сохраняютс я дублированны е данные ?
• Документация. Эт а категори я треб ов ан и й связан а с документацие й и тем ,
должн а ли он а быт ь представлен а в печатно м виде ил и выдаетс я в интерактив ­
но м режиме . Кром е того , здесь ж е определяет с я категори я лиц , для которы х
эт а документаци я предназначен а .
• Устранени е неисправностей . Эт а категори я требовани й описывает , как сис­
тем а реагируе т н а возни кн ов ен и е неисправносте й . Будет л и систем а обнару­
ж ив а т ь неисправн ос т ь и выдават ь а в а р и й н ы е сигналы? Како й должн а бы т ь
 Глава 2. Анализ требовани й и тестировани е 45

средня я длительност ь промежутк а в р ем е н и между двумя неисправностями ? Ка­

ки м должн о быт ь максимально е врем я простоя ?
и С о п р о в о ж д е н и е . Эт и т р е б о в а н и я определяют , как производит с я у ст ра не н и е
проблем , обнаруженн ы х в систем е , ка к усов ерш енств ованн ы е в е р с и и с ис те м ы
поставляют с я заказчик у и как пользовател и до лжн ы переходит ь н а усовершен­
ствованну ю верси ю систем ы .
• Пла н поставк и версий . Если тр е бов а н ия м н аз н ач е н ы п р и о р ит е т ы , возможно ,
необходим о будет определ и т ь време нн о й гра фи к поставк и версий , к от о р ы й
показыва ет , реализац и и каки х т р е б о в а н и й уделяется вни ма н и е в к он к ре т н о й
версии .
Выполня я статическ о е т е с ти р о в а н и е н а документа х с форму лир овк а м и тр ебо в а -
ний , возможно , возникн е т же ла н и е воспользовать с я приведенны м выш е списко м с
целью об е с п е ч е н и я полнот ы тести ровани я . Если в ы ведет е п р е д ы с т о р и ю статиче ­
ского т е с т и р о в а н и я сразу нескольки х п р о ект о в , это т списо к можн о расширит ь таки м
образом , чтоб ы о н соответствова л номенклату р е программны х продуктов , создавае­
мых ваше й компанией . Если обстоятельств а заставля ю т вас пр о в од и т ь т е с т и р о в а н и е
в условия х неполног о набор а т р е б о в а н и й , н а основ е п ре д ло ж ен н о г о списка , скоре е
всего, придет с я определит ь , каки е тест ы нужны помим о тех , чт о образую т п ок р ы т и е
задокументированн ы х т ре б о ва ни й .

П р и м е р ы т р е б о в а н и й . П р и м е р , содержащ и й нескольк о ф унк ц ио н ал ь н ы х

тр еб о ва ни й , приводит с я н а рис . 2.4. Эт о т п ри м е р отн ос ит с я к гипотетичес ко м у про­
дукту, к от ор ы й м ы будем "разрабатыват ь " н а п рот яж е н и и пра ктичес к и все й книг и .
Указанны й де монстраци онн ы й п рог ра ммн ы й продукт, к от ор ы й м ы назове м ком­
плект о м Т М Т (Test M a n a g e m e n t Toolki t — инструментальн ы е средств а управ лен и я
тестами ) , представляе т собо й при ложе ни е , предназначенн о е дл я тестовы х групп,
которы м необходи м ы авт омат изирова нн ы е инструментальны е средств а дл я под­
дер ж к и планирован и я тестировани я , разработк и тестовы х случаев и вы п ол н ен и я
тестов . Определени е требовани й к комплекту Т М Т можн о найт и в тр е т ь е й част и
книги .
Тр е б о в а н и я , представленны е н а ри с . 2.4, касаютс я некото ры х ключевы х свойст в
программног о продукта.

Спецификация требований
Сп ец и фи ка ц и я требован и й описывае т т о же , чт о и документ опред елен и я требова ­
ний , однак о с п ец и ф и к а ц и я предназначен а для системны х разработчик о в и представ­
лен а н а язык е ил и в обозначениях , о р и е н т и р о в а н н ы х н а разработчиков . Специфика ­
ци ю требо ван и й част о называю т системн о й функц иональн о й с п е ц и ф и к а ц и е й , не­
смотр я н а т о ч т о е е област ь действи я расп рост раня ет с я з а предел ы н а функциональ ­
ны х тр ебо ван и й системы .
Сп ец и фи ка ц и я требований , ил и функциональн а я специфи каци я , — эт о далек о н е
п р и м ит и в н ы й перево д опр еделен и й тре бо ван и й н а технически й язык . Специфика ­
ци я може т про води т ь дальнейш е е разбиени е т р е б о в а н и й п о категориям , а та к ж е до­
бавлят ь подр обност и з а сче т формулирован и я н е к о т о р о г о набор а производны х тре ­
бовани й . Н а п ри м е р , в исходно м о п р е д е л е н и и т р е б о в а н и й може т быт ь указан о , чт о
46 Часть I. Процесс быстрого тестирования

система должна работать в заданном диапазоне температур, в то время как в специ­

фикации могут быть определены различные режимы эксплуатации системы в раз­
личных температурных диапазонах. В какой-то мере определение требований пред­
ставляет собой объявление того, что заказчику необходимо и что он хотел бы полу­
чить, а спецификация есть ответное предложение группы специалистов, содержащее
описание того, что будущая система будет способна делать.

Составители спецификации требований могут использовать естественный язык

либо выбрать язык или обозначения из широкого набора языков, разработанных
специально для написания спецификации требований. Поскольку термины в естест­
венном языке могут интерпретироваться различными способами, их применение
может усилить взаимное непонимание между заказчиком и разработчиком, если не
предпринять специальных мер по уточнению значений отдельных слов, таких как,
например, "производительность", "практичность", "надежных" и т.п. Особенности
привлечения для формулирования требований языков, отличных от естественных,
описано в [42].
Готовая формальная спецификация требований должна быть подвергнута стати­
ческому тестированию с целью проверки, что каждое требование, зафиксированное
в документе определения требований, отражено в спецификации требований, а каж­
дое требование одного документа отображается или отслеживается из другого доку­
мента. Окончательная редакция спецификации должна пройти статическое тестиро­
вание с тем, чтобы убедиться, что требования спецификации обладают свойствами
полноты, непротиворечивости, осуществимости, контролепригодности, однознач­
ности и релевантности.
 Глава 2. Анализ требований и тестирование 47

Матрица прослеживаемости требований

Назначение матрицы прослеживаемости требований заключается в отображении
каждого требования на проектные компоненты, программные коды и тестовые слу­
чаи. Пример матрицы прослеживаемости требований показан на рис. 2.5. В этом
примере каждое требование, фигурирующее в документе определения требований,
отображается на одно или большее количество требований из спецификации, на
проектные компоненты и программные коды, а также на тестовые случаи модульного
тестирования, проверки взаимодействия и функционирования компонентов про­
граммного продукта, системных и приемочных испытаний. Для нумерации требова­
ний используется "десятичная нотация Дьюи". Эта нотация позволяет отобразить
исходные требования из документа определения требований на производные требо­
вания и различные виды тестов в отношении "один-ко-многим" (например, одно тре­
бование соотносится с некоторым множеством системных тестов). Даже если про­
ектная информация и данные о программных кодах не включены в эту матрицу, по­
лезно поддерживать ее упрощенный вариант, который соотносит каждое требование
с соответствующими системными и приемочными тестами.

Тестирование требований
Завершающим действием процесса формулирования требований является статиче­
ское тестирование требований. Одна из целей статического тестирования преду­
сматривают проверку требований на полноту, непротиворечивость, осуществимость,
а также на возможность тестирования (статического или динамического) в процессе
реализации. Дополнительная цель такого статического тестирования заключается в
проверке того, что требования, представленные в окончательном виде, соответству-
48 Част ь I . Про ц ес с быстрог о тестировани я

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

вильн о вып олне нн о е ста т ич е с к о е т е с ти р о в а н и е об о ра чив ает с я с е рь езн ы м выигры­
ше м в смысл е экономи и средст в и времени . Напомним , ч т о согласн о данны м группы
Standish , рассматри ваем ы м в начал е главы, проблемы , возникающ и е н а этап е форму­
л и ров а н и я треб о ва ни й , п о рож да ю т боле е 50 % п рое к тны х ошибо к и перерасход а ре­
сурсов. Статическо е т е ст и р о в а н и е т р е б о в а н и й представляе т собо й наиболе е э ффек ­
ти в н ы й спосо б обнаружени я эти х д ефе кт о в ещ е д о того , как он и окажут неблагопри ­
ят н о е вли яни е н а план ы в ы пол не н и я ра б о т и сметн ы е расходы .
Существует множест в о спо собо в в ы п ол н ен и я статическог о т ести рован и я , однак о
тр ем я наиболе е расп ространенн ы м и я в ля ю т с я инспекции , сквозно й конт ро л ь и экс­
п е ртн ы е оценки . Иногд а названи я эти х методо в звучат по-другому; ин сп ек ци и из­
вест н ы как техническ и й анализ , а эк сп е ртн ы е оц ен к и не р ед к о называю т "партнер ­
ски м контролем" . Ха р а кт е рн ы е особенност и каждого и з эти х типо в статическог о
т е ст и р о в а н и я приводят с я в табли ц е 2.1 . Боле е подробную и н фо р м а ц и ю о метода х
статическо г о те сти р о ва н и я можн о найт и во врезк е 2.2 и в главе 9.

И з таблиц ы 2.1 следует, ч т о в т о время , как затра т ы н а проведен и е инспекци й

больше , че м н а реализац и ю других методов , он и обеспечиваю т наивысшую эффек ­
тивност ь обнаружени я деф ект о в в проверяем о м рабоче м продукте. Поскольку очен ь
важн о найт и как можн о больш е д ефе кт о в н а стади и формулирован и я требова ни й , м ы
настоятельн о рекомендуем инспекци и как осно вн о й мето д анализ а требо вани й .
 Глава 2. Анализ требовани й и тестировани е 49

СТАТИЧЕСКИЕ М ЕТОД Ы ТЕСТИРОВАНИЯ

Наиболее распространенными методами статического тестирования являются инспекции,
сквозной контроль и экспертные оценки . Основные характеристики каж д о г о метода
приводятся ниж е в данном разделе.
Инспекции
Основной организационной фо р мо й инспекции является совещание, на кот ор о м рабочий
продукт анализируется с целью обнаружения дефектов . Каждый участник специально
готовится к совещанию, а само совещание проводится в соответствии со специальным
набором правил. Обнаруженны е дефекты документир уютс я , итоги совещания публику­
ются. Практика показала высоку ю эффективность таких сообщений с точки зрения обна­
ружения дефектов . Данные, опубликованные Бое мо м [ 2 8 ] , показывают, что если на ин­
спекции приходится 20 % трудозатрат на программирование , то из инспектируемого про ­
граммног о кода будет изъято примерно 8 0 % ошибок на уровне программных модулей .
Первоначально рекомендации по проведению инспекций были сформулированы Ф ейг а -
ном [16 ] из компании IBM, причем с течением времени други е организации приняли их в
качестве стандартов или рекомендаций для практической деятельности.
Сквозной контроль
Сквозной контроль представляет собо й мене е формальное мероприятие, че м инспек­
ции, в т о м смысле, что ни от одного из ег о исполнителей не требуется специальной под­
готовки, за исключением разве что презентатора. К ро м е т ог о , никаких итоговых отчетов
при этом не требуется . Поскольку сквозной контроль формализован в меньшей степени,
нежели инспекции, то он м о ж е т охватывать больше материала. В то же время он не об-
ладает такой эффективностью обнаружения и документирования дефектов, как инспекции.
Экспертные оценки
Экспертные оценк и требую т немного больше, че м прост о передача рабочего продукта
коллеге по работе и выслушивание е г о мнения по этом у поводу. Экспертная оценка
може т быть выражена словесно либо передана по электронной почте. Формальн ы е
процедуры экспертных оце но к отсутствуют, эффективность поиска и документирования
дефектов, свойственная этому методу, меньше, чем эффективность двух других методов.
Врезка 2.2.

Критерии, используемые при тестировании требований

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

П о л н о т а . Н а б о р требовани й считает с я полным , есл и все ег о составны е част и

представлен ы и каждая така я част ь выполнен а в полно м объеме . П р и тести ров ан и и
набор а требова ни й н а полнот у необходим о о б р а ти т ь особо е внимани е н а следующие
моменты :
• Т ре б ова н и я н е должн ы содержат ь вы раж ени й тип а "подлежи т опр едел ени ю " ,
" и та к далее" , " и прочие " и и м подобны х .
• Требова ни я не должн ы ссылатьс я на несуществующую справочн у ю информа ­
цию , такую как, наприме р , несуществующая с пец ификаци я .
• Требова ни е н е должн о ссылатьс я н а фун кц и он ал ь н ы е средства, которы е ещ е
н е оп р ед е ле н ы .
50 Часть I. Процесс быстрого тестирования

Од н о з н а ч н о с т ь . Каждое требование должно быть точно и ясно сформулирова­

но; оно должно допускать единственное толкование. Требование должно быть удобо­
читаемым и понятным. Если требование отличается особой сложностью, для облег­
чения понимания может быть привлечен вспомогательный материал, такой как, диа­
граммы или таблицы. Если для пущей убедительности используются выражения на­
подобие "это очевидно" или "само собой разумеется", то вполне возможно, что автор
пытается отвлечь ваше внимание от того или иного двусмысленного утверждения.
Н е п р о ти в о ре ч и в о с т ь . Требования не должны противоречить друг другу или
действующим стандартам. Если требования конфликтуют друг с другом, то нужно
вводить приоритеты с целью разрешения таких конфликтов. Умение обнаруживать
дефекты, обусловленные противоречиями требований, предполагает хорошее зна­
ние всего документа, содержащего требования, и знакомство с существующими стан­
дартами или другими внешними техническими условиями.
П рос л е ж ив аем ос т ь . Каждое требование должно иметь уникальный иденти­
фикатор, который позволяет прослеживать его разработку на протяжении всего
жизненного цикла. В рабочих продуктах, которые появляются на более поздних эта­
пах жизненного цикла, таких как план тестирования, каждая ссылка на свойство сис­
темы должна прослеживаться до определения и спецификации требований. Матрица
прослеживаемости требований, обсуждавшаяся ранее в этой главе, является отлич­
ным инструментальным средством для решения упомянутой задачи.
Ос у щ ес тв и мос т ь . Каждое требование должно ставить перед системой задачу
обеспечить такие средства, которые целесообразно разрабатывать и поддерживать.
Если заказчик предъявляет к системе нереальные требования в смысле затрат време­
ни и средств на разработку тех или иных функций либо же требует разработки функ­
ций, которые окажутся ненадежными и опасными в эксплуатации, необходимо опре­
делить риски и принять соответствующие меры. По сути дела, разрабатываемая сис­
тема должна быть экономически осуществимой, надежной, удобной в эксплуатации и
сопровождении.
Контрол епри годн ост ь . Мы должны уметь разрабатывать экономически обос­
нованные и удобные для использования тесты для каждого требования с целью про­
демонстрировать, что тестируемый программный продукт обладает необходимыми
функциональными возможностями, рабочими характеристиками и соответствует
действующим стандартам. Это означает, что каждое требование должно быть изме­
ряемым или поддаваться количественному определению и что тестирование должно
выполняться в приемлемых условиях.

Использование прототипов
В качестве дополнения к методам статического тестирования для проверки и под­
тверждения требований с большой пользой могут быть использованы прототипы
программного продукта. Прототип {prototype), будь то макет на бумаге или модель про­
граммного продукта, дает вам возможность предложить заказчику варианты и полу­
чить обратную реакцию, которая позволяет сделать формулировки требований более
точными. Прототипы часто позволяют выявить дефекты в полноте, непротиворечи-
 Глава 2. Анализ требований и тестирование 51

вости или в осуществимости спецификаций требований, и в силу этого обстоятельст­

ва могут служить хорошим дополнением статического тестирования.
Существуют два подхода к использованию прототипов. В рамках одного из них
производится построение одноразового прототипа (throwaway prototype), который
используется исключительно для определения требований; прототип не поставляет­
ся заказчику в виде программного продукта. Второй подход предусматривает созда­
ние эволюционного прототипа (evolutionary prototype), который применяется на на­
чальной стадии процесса для выявления и анализа требований, и в то же время под­
вергается многократным усовершенствованиям, постепенно превращаясь в продукт,
который уже можно поставлять заказчику. Тестирование эволюционного прототипа
программного продукта рассматривается в следующем разделе.
Один из способов встраивания прототипа в жизненный цикл разработки показан
на рис. 2.6 [42]. В рамках этого подхода прототипы могут быть построены на стадии
формулирования требований и на стадии проектирования цикла разработки. Прото­
типы используются во время анализа требований для уточнения и тестирования тре­
бований. На стадиях системного проектирования и проектирования программ раз­
работчики могут применять прототипы для оценки альтернативных стратегий про­
ектирования. Программный код, разработанный для прототипа, в такой модели раз­
работки может как использоваться, так и отбрасываться за ненадобностью.
52 Част ь I. Про ц ес с быст рог о тестировани я

Чтоб ы получит ь преимуществ о в начал е тестовы х работ , тестова я группа може т

воспользоваться прототи п ами , разработанны м и н а стади и анализ а тре б ов а ни й .
Можно раз раб отат ь пр ед в а рит е ль н ы е испытан и я и выполнит ь их на прототип е с це­
лью подтверждени я пр а ви ль н ос т и основны х т р е б о в а н и й . Эт и тест ы будут совершен ­
ствоваться н а боле е поздн и х стадия х в процесс е фо рм и ро в а н и я ключевог о набор а
тестов для этапо в системн о г о т ест и р ов ан и я и при ем очны х и спытани й . П одобн о то­
му, как п р от от и п помогае т сделат ь треб о ва н и я "боле е ре али стичны м и " с т о ч к и зре­
ния заказчик а и р азр а бо т ч ик а , это т п р о т о т и п позволяе т тестово й группе "увидеть",
как следует определ ят ь набо р тест о в дл я систем ы . Если прототип о м являет с я модел ь
н а бумаге ил и набо р эскизов , т о ему придет с я п рой т и долги й путь, пок а о н на чне т
приносит ь тестово й группе реальну ю помощ ь в п он и м а н и и тог о , как получить полез­
ный набо р тестов .
П ри м е н е н и е п р от от и п о в н е то ль к о помогае т получит ь тестово й группе преиму­
щества н а старте , о н о поддержива е т статичес к о е ил и динамическо е т е с т и р о в а н и е н а
стадии формулирован и я тр е б о в а н и й . П рот от и п ы могут использовать с я в качест в е
вспомогательног о средств а дл я о п ре де л ен и я полнот ы , н еп р о т и в о р е ч и в о с т и , осуще­
ствимости и р е л е в а н т н о с т и треб о в ан и й .
П рототи п ы использую т в моделя х жиз не нн ы х циклов , о тл и чн ы х о т каскадных. П о
существу, в случае эв олюц и онн о г о прототип а он о може т стат ь осново й процесс а раз­
работки . Од н о й и з наиболе е сложн ы х моделе й жизн ен н ог о цикл а являет с я спираль ­
ная модель, р а з р а б о т а н н а я Боемо м [42] . Спиральна я модел ь реализуе т подход, учи­
тывающи й риски , он а разбива е т проек т н а некотору ю последовательност ь "мини -
проектов" , кажды й из которы х решае т ту ил и иную крупную задачу. Посл е тог о как
все основны е ри ск и будут учтены , модель завершает с я об ыч н о й каскадно й разработ ­
кой конечног о прог ра м мн о г о продукта.

Тестирование в рамках жизненного цикла эволюционного

прототипирования
Создание эвол юционн ы х прототип о в представляе т собо й мето д поэта пн о й разработ­
ки системы , пр и это м кажды й эта п определяетс я ответно й ре ак ци е й заказчик а и ре­
зультатами тестиров ани я . П р о т о т и п ы особен н о полезны , когда в ы испытывает е за­
труднения пр и определ ен и и основны х требован и й на начально й стадии проект а и в
т о ж е врем я имеет е возможност ь многократн о конта ктиров а т ь с заказчиком , чтоб ы
понять , чт о ему нужно. Н а каждо й итераци и цикл а разработ к и приходитс я прибегат ь
к помощи как статического , та к и динамическог о тест иров ани я . Пр и м е р жизне н ног о
цикла показа н на рис . 2.7.
В эв ол юц ио нн о й модел и разработк а начинает с я с определен и я исходного прото­
типа. Если разработ к а ведетс я по спирально й модели , то в цент р е внимани я исход­
но й модел и може т находитьс я оценк а основны х ри ск о в проекта . В других случаях
исходным прототипо м може т быт ь макет пользовательског о инт е р фе йс а , в условиях
которог о пользовател и образую т обратную связ ь в рамка х функциональн ы х возмож­
носте й и удобства и простот ы обслуживания системы . Статическо е тестирован и е
следует при м ен ят ь в о тн о ш е н и и разработ к и исходног о прототи п а в виде эксперт и з
или совместног о с заказчик о м рабочег о совещани я , на при ме р , JAR-сеанса.
Глав а 2 . Ана ли з т р е б о в а н и й и т е с т и р о в а н и е 53
54 Част ь I . Про ц ес с быстрог о тестировани я

Ка к тольк о о п ре де л ен и е п р о т о т и п а завершается , группа р аз р а б о т ч и к о в выполня­

е т проекти рован и е , кодирован и е и т ест и ро в ан и е п р от оти п а , в т о врем я ка к группа
те сти р ов а н и я параллельн о разр абаты ва е т план ы тест ир о ва ни я , создае т тест ы и вы­
полн яе т и х прогон . Эт а модел ь требуе т тесног о взаимодействи я между коллективо м
ра зр а бо т чи к о в и группо й т е ст и р о в а н и я с тем , чтоб ы кажды й п р от о т и п подвергс я
те сти р ов а н и ю в дост ато чн ы х объема х пере д ег о д ем он ст р аци е й пользователю . Если
функциональны е в оз м ож н ос т и систем ы возрастаю т с каждо й и т е р а ц и ей , группа тес­
тирован и я должн а имет ь в озм о жн о ст ь выполнит ь р е г р е с с и о н н о е т е ст и р о в а н и е н а
каждом шаге цикл а раз р аб от к и . Другим и словами , необходим о прогонят ь специаль­
ны е тесты , чтоб ы убедиться , ч т о ст а ры е функциональн ы е средств а н е разрушен ы ил и
н е деградировал и в результат е добавлени я новы х функци ональны х возможносте й .
Автоматизаци я може т оказатьс я исключительн о полезно й дл я рег р ес си о нн о г о тес­
тировани я . Если количест в о тестов , выполняем ы х вручную, возрастае т с каждым
цикло м р аз ра б от ки , трудоз атрат ы н а т ест и р ов ан и я существенн о возрастаю т и требу­
ют все больше и больш е вр е ме н и .
П о заве р ш ен и и достаточн о большог о числ а цикло в р аз р аб от к и пере д передаче й
конечног о програм мно г о продукта заказчику потребуетс я прове ст и завершающ и е
системн ы е и при ем очн ы е испытани я продукта. И з пример а 2.7 нетрудн о видеть, чт о
все основны е функци и динамиче ског о т ест и ро в ан и я (планиров ан и е т ес ти р ов а ни я ,
проектировани я , р е а л и з а ц и и и выполнение ) выполняют с я в рамка х жизненног о
цикл а эволюционног о прототипиров ани я , н о о н и выполня ют с я в ит е рат и вн о м ре­
жиме , чт о обусловливае т необходимост ь регрессионн о г о т е ст и р о в а н и я .

Что дальше
В данно й главе был и пр о веде н ы исследован и я стади и фор м ул и ро в ан и я треб о ва н и й
процесс а раз раб от к и с т о ч к и з ре н и я специалис т а п о т е ст и р о в а н и ю систем . М ы обна­
ружили два основны х фа к тора , обусловливающих участи е групп ы те сти р о ва н и я н а
стади и фор м у ли р ов ан и я тр е б о в а н и й :
• Необходимост ь получени я специ фи ка ци й , служащих осново й плано в тести­
ровани я и п рое кт и ров а н и я тестов .
• Необходимост ь статиче ског о тест и р ов ан и я с п е ц и фи к а ц и й т р е б о в а н и й с цель ю
предотв ращ ен и я перет ек ан и я де фе кт о в н а боле е поздни е стади и разработки .

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ

В продаж е м о ж н о найти несколько программных инструментальных средств, которы е
м о ж н о использовать на этапе формулирования требований. Программны е инструмен-
тальные средства особенн о полезны в плане выявления требований и обеспечения про ­
слеживаемости требований на протяжении процесса разработки . Примерам и средств
управления требованиями являются DOORS и Requisite Pro. Инструментарий DOORS - это
инструментальное средство, разработанное компанией Quality System and Software
(QSS) L t d . Еще одно средство — это модуль Requisite Pro, которы й продается компани­
ей Rational Software. Компания Atlantic Systems Guild, Inc. занимается независимыми ис-
следованиями инструментальных средств управления требованиями, результаты которых
публикуются на Web-сайте hffp://[Link].
Врезка 2.3
 Глава 2. Анализ требований и тестирование 55

Мы выявили три вида рабочих продуктов, которые создаются на стадии формули­

рования требований:
• Документ определения требований, который представляет собой изложение
требований заказчика к программному продукту, сформулированное на естест­
венном языке.
• Спецификация требований, которая еще называется функциональной специ­
фикацией, представляющая собой технические требования, выраженные в но­
тации, которая может использоваться для разработки программных продуктов.
• Документ, отслеживающий требования, который может применяться для ото­
бражения теста на требование, послужившее причиной появления этого теста.
В результате обеспечивается возможность тестирования всех требований.
Мы описали содержимое каждого из этих документов и выдвинули некоторые
идеи относительно того, как их проверять. Более подробную информацию о приме­
нении статического тестирования на стадии формулирования требований, включая
описание методики проведения JAR-сеансов, можно найти в главе 8. Наконец, мы
обсудили роль прототипирования на стадии формулировки требований и рассмотре­
ли, как выполняется тестирование в рамках жизненного цикла эволюционного про­
тотипа.
В следующей главе мы более подробно рассмотрим, что происходит после выяв­
ления всех требований к программному продукту. В центр внимания выдвигаются
планирование тестирования и оценка трудозатрат.
 Планирование
испытаний
Темы, рассматриваемые в главе:
• Стратегия тестирования
• Определен ие стратегии тест ирования
• О ц е н ка трудозатрат на т ест и ро в ан и е
• Подг от ов ка и п ересм о т р документов,
сод ер жа щ и х планы п р о в е д е н и я и с п ы т а н и й
• Что дальш е

Ка к отмечалос ь с самог о начал а книг и , основн о й принци п быстрог о тес т и р о в а н и я

предусматрива е т максимальн о тесну ю связ ь с раз р аб о тк о й на п рот яж е н и и всего жиз­
не нн ог о цикл а програм мн о г о продукта. В о врем я выявлени я и анализ а т р е б о в а н и й
подобно е интегриров ан и е достигаетс я з а сче т использовани я технолог и и статиче­
ског о тестировани я . Последн я я предусматривае т п е р ес м от р т р е б о в а н и й с цель ю об­
наружени я дефектов , а такж е участи е специалисто в по тестирован и ю в процесс е
формулирован и я требовани й с цель ю боле е раннег о получения с п е ц и ф и к а ц и й , что , в
сво ю очередь , позволяе т задействова т ь требовани я в о врем я планир ован и я испыта­
ний . При н ц и п интегрировани я разработ к и и тестовы х действи й долже н соблюдатьс я
и в процесс е планиро ван и я и опреде лен и я трудозатрат. Тестиров ан и е программног о
обеспе чен и я представляе т собо й дорогостоящ ую , ресурсоемкую работу, н а выполне­
ни е к от о р о й расходуется д о поло вин ы сметно й стоимост и проекта . Высока я эффек ­
тивност ь планиро ван и я ис пыт ан и й и правильна я оценк а трудозатра т в значительн о й
мер е содействует успеху всего процесс а тестировани я , в то врем я как неудачи на это й
стади и могут привест и к пре в ы ше н и ю сметно й стоимост и проект а и нарушени ю гра­
ф и к а работ .
Диаграмм а видов деятельности , связанны х с планирование м исп ыт ани й , показан а
на рис . 3.1. Входными для процесс а планирован и я будут документы, к от ор ы е содер­
жа т требов ани я , описа нн ы е в главе 2. Ка к упоминалос ь в главе 2, есл и документы с
формулировкам и требовани й отсутствуют, придетс я самостоятельн о составить , п о
меньше й мере , сокра щенн ы й вариан т таки х документов. Не в о з м о ж н о провест и не­
обходимо е т е сти р о ва н и е пр ог р ам мн о г о продукта, н е име я п р ед ст а вл е н и й о функ­
циональн ы х возможностя х продукта и связанны х с ним и ожидани й заказчика .
 Глава 3. Планировани е испытани й 57

Выходны м результато м действи й исполнителе й , осуществляющих п л ан и ров а н и е

тестировани я , явля ет с я документ ил и набо р документов , к оторы й долже н быт ь про­
вере н тестово й группой, группой р а з р а б о т ч и к о в и персоналом , осуществляющи м
управлен и е р а з р а б о т к о й и сопров ождени е м програм м . В план е прове ден и я испыта­
ний указаны ресурсы , необходимы е для тестир ован и я программног о продукта, опре ­
делено, ч т о подлежи т тестировани ю , как должн о проводитьс я тестиро ван и е и каки е
выходы ил и выходны е результаты будут получен ы по итога м тестировани я . Содер­
жимо е и ф о р м а т план а исп ытан и й обсуждаются дале е в это й главе.
Пр оц ес с планиро ван и я испытани й образуетс я и з следующих основн ы х видо в дея­
тельности :
• Опр еде лен и е стратеги и тестирован и я
• Опреде лен и е состава и структуры испытательн о й систем ы (аппаратн ы х и про­
граммны х средств )
• Оц е н к а трудозатра т (ресурсы и гра фи к работ )
• Оц е нк а рис к о в невыпо лнен и я гра фи к а рабо т и подготовк а плана м е р о п р и я т и й
п о смягчени ю последстви й о т овеществлени я эти х рисков .
• Подготовк а и пересмот р (утверждение ) документо в с плано м проведен и я ис­
пыт ан ий .
Кажды й и з указанны х выш е видо в де ятель нос т и подр обн о обсуждается в данно й
главе. Техн олог и я оц е н к и трудозатра т исследуется в главе 12. П р и м е р план а прове-
58 Часть I. Процесс быстрого тестирования

дения испытаний приложения ТМТ приводится в третьей части книги. Несмотря на

то что на рис. 3.1 показана линейная последовательность основных видов деятельно­
сти, зачастую они выполняются одновременно или по итерационной схеме. И хотя
порядок выполнения видов деятельности может меняться, важно, чтобы все они бы­
ли частью процесса планирования испытаний.
Планирование тестирования можно сравнить с луковицей, т.е. это многоуровне­
вый процесс. Планирование начинается с определения стратегии тестирования на
концептуальном уровне, после чего добавляются уровни дальнейшей детализации,
которые описывают архитектуру тестирования, условия испытаний, а также тесто­
вые случаи до тех пор, пока не будет составлен план проведения испытаний в его
окончательном виде. После того, как план проведения испытаний будет оформлен в
виде документа и утвержден, процесс планирования не прекращается, поскольку воз­
можны изменения требований, изменения в графике работ и другие виды изменений,
которые влекут за собой коррекцию плана проведения испытаний. План проведения
испытаний должен поддерживаться на всем протяжении процесса разработки про­
граммного продукта как динамически развивающийся документ. Он должен хранить­
ся в безопасном хранилище и поддаваться управлению версиями.

Стратегия тестирования
Первое действие в планировании испытаний предусматривает разработку стратегии
тестирования на высоком уровне. В общем случае стратегия тестирования должна
определять объемы тестовых работ, типы методик тестирования, которые должны
применяться для обнаружения дефектов, процедуры, уведомляющие об обнаружении
и устраняющие дефекты, критерии входа и выхода из испытаний, которые управля­
ют различными видами тестирования. Реализуя принцип тесного интегрирования
разработки и тестирования с целью оптимизации графика разработки, стратегия
тестирования должна отображать различные виды тестовой деятельности на жиз­
ненный цикл разработки. При формулировании общей стратегии должно быть пре­
дусмотрено как статическое, так и динамическое тестирование.
Если для поддержки различных видов тестовой деятельности используется авто­
матизация, стратегия автоматизации должна рассматриваться как составная часть
общей стратегии тестирования. Автоматизация требует выполнения независимых
параллельных работ, которые должны тщательно планироваться и выполняться
только в тех случаях, когда это не приводит к снижению эффективности.
Мы предлагаем следующий подход к формулированию стратегии тестирования:
1. Определить объемы тестовых работ путем анализа документов, содержащих
требования к программному продукту (технические условия), дабы выяснить,
что нужно тестировать. Рассмотреть виды тестирования, которые не следуют
непосредственно из документов с требованиями, такие как тестирование воз­
можности установки и наращивания возможностей программного продукта,
удобство и простота обслуживания продукта, а также способности к взаимо­
действию с другими видами аппаратных средств из среды заказчика.
2. Определить подход к тестированию за счет выбора статических и динамиче­
ских тестов, связанных с каждой стадией разработки. Здесь потребуется
 Глава 3. Планировани е испытани й 59

включит ь описан и я всех ра б о чи х продуктов , котор ы е должн а подготовит ь

тестова я группа.
3. О п р е д е л и т ь крит е ри и входа и выхода дл я каждо й стади и тести ровани я , равн о
ка к и все точ к и конт р ол я качества , дл я чег о потребуетс я участи е специали ­
сто в п о т ест и ро в ан и ю .
4. О п р е д е л и т ь стратеги ю автоматизац и и в случае, есл и планирует с я использо ­
вани е автоматизаци и какого-либо вида тестово й деяте льност и . Автоматизац и я
требуе т проведени я независимы х параллельны х работ , к от ор ы е до л ж н ы тща­
те ль н о планироватьс я и выполнятьс я тольк о в те х случаях, когда эт о не при­
води т к сн иж ен и ю э ф фе к т и в н о с т и .

Определение объемов тестовых работ

Пр и опреде лени и объемо в тестовы х р а б о т важн о ра ссмотр е т ь вопрос , кака я част ь
программног о продукта должн а подвергатьс я т ес ти р ов ан и ю . В област и те стиров ан и я
программног о обеспечени я давн о установл е н то т факт , чт о программу, реализующую
большую част ь функциональн ы х возможностей , невозможн о п р о т е ст и р о в а т ь полно­
стью. Это т ф а к т исследуется в о врезк е 3.1 "Мо жн о л и выполнит ь исчерпывающ е е
тестировани е программы ? " Ответо м , котор ы й м ы получаем н а основ е эт о й врезки ,
будет "Нет !" . Конечно , можн о в ыполни т ь достаточн о исчерпывающ е е тести ров ан и е
старой д о б ро й программы , выдающ е й фраз у "hello , world " (привет , мир!) , котора я
содержит всего лиш ь нескольк о строк , н е имее т условных переходов , GUI-
интерфей с а (Graphica l Use r Interface — графич ес ки й инт е рфе й с пользователя) . Т е м
н е менее , дл я программ , реализующи х реальны е задачи , всегда ха р а кте р н а опреде­
ленна я сп ецифик а входных данны х , какие-то комбин ац и и входных последовательн о ­
стей ил и ветвлени е кода, д о пров е рк и которы х прост о н е доходя т руки.

М О Ж Н О Л И ВЫПОЛНИТЬ ИСЧЕРПЫВАЮЩЕЕ ТЕСТИРОВАНИЕ П Р О Г Р А М М Ы !

Первое, что потребуется предпринять, прежд е че м приступить к проектированию тес­
тов, — это определить общий объ е м работ по тестированию. Н ужн о ли попытаться вы­
полнить исчерпывающее тестирование прогр ам мн о г о обеспечения, или же существуют
фундаментальные ограничения относительно того , что мож н о ожидать от тестовых ра ­
бот? В данной врезк е мы проведе м анализ пример а компонента программ но г о обеспе ­
чения, исходя из поставленного выше вопроса.
Рассмотрим программны й компонент , которы й вычисляет стоимость перевозк и некото ­
рог о продукта с известным весо м по заданному почтовому индексу получателя. В про ­
грамм е имеется GUI-интерфейс, через которы й м ож н о вводить почтовый индекс (наряду
с другими данными, имеющими отношение к обрабатываемой транзакции). В это м слу­
чае расходы на перевозку представляются промежуточным и результатами вычислений,
которые пользователю не отображаются . Для тог о чтобы увидеть результаты вычисле­
ний, потребуется отправить запрос в базу данных.
Базовая идея представлена на блок-схеме , изображенно й на рис. 3.2. На этой диаграм ­
ме показано лишь отношение, связывающее ввод и вывод, поэтому не придется вникать
в подробности, относящиеся к GUI-интерфейсу и базе данных.
Для простоты п о ло жи м , что в качестве стандартного почтового индекса м ож е т исполь­
зоваться любо е пятизначное положительное целое число. Другим и словами, входные
величины принимают значения из диапазона от 00000 до 99999.
60 Ч а с т ь I. Проц ес с быстрого те ст и р ов а н ия

Для каждог о входного значения программ а вычисляет стоимость перевозки , которая к о ­

леблется в пределах от $5 до $20. Отображение входа на выход описывается отношени­
ем "многие-к-о дн ом у" , а это означает, что несколько почтовых индексов могу т поро ­
дить одну и ту же стоимость перевозки .
Теперь, когда получено представление о то м , как работает эта часть программ н ог о
обеспечения, м о ж н о вернуться к вопросу о возможност и исчерпывающего тестирования
рассматриваемой пр о гр а ммы . В данном случае мы конкрет н о хотим знать, м ож н о ли
проверить эту про гра мм у на всех возможны х значениях входных данных.
Существуют два класса ввода: допустимый и недопустимый. Пятизначные положитель­
ные целые числа суть допустимый ввод, в то же время отрицательные целые числа, чис­ ла
с десятичной точкой , букв ы алфавита, управляющие коды и пробелы не рассматри­
ваются как допустимый ввод.
Простой подсчет количества допустимых почтовых индексов говорит о то м , что числом
допустимых вводов будет 100000 (пятизначные числа, не разрешенные почтовой служ ­
бой , игнорируются). Пре дп оло жи м , что автоматизация в данном случае не применяется,
т.е . тестирование про гра мм ы выполняется в неавтоматизированном реж им е . Процедура
тестирования требует от тестировщика вручну ю вводить допустимые входные значения,
отправлять запросы в базу данных для получения стоимости перевозки , сравнивать вы­
численные значения стоимости перевозок и фиксировать полученные результаты. М о ж ­
но запросто потратить 3 минуты на один ввод, так что на проверк у всех допустимых
входных значений буде т затрачено 5000 часов, что составляет более 2 лет напряженной
работы. К р о м е то го , подобну ю проверку , во зм ож н о , придется выполнить несколько
раз , поскольку каждая новая версия должна тестироваться совершенно аналогично.
По сути дела, все во змо жны е входные значения проверить просто невозможно . Картина
меняется, если реализовать автоматизацию рассматриваемого вида тестирования, но
даж е и в этом случае вряд ли захочется тратить время на автоматизацию и тестирование
каждог о в озм ож но г о ввода. В главах 4 и 11 будет показано , ка к сузить диапазон тесто­
вых входных данных и получить компактный, управляемый набор эквивалентных значений
с помощь ю методики разбиения на классы эквивалентности.
Если дополнительно принять во внимание и все недопустимые значения, диапазон ещ е
больше расширится. М о ж н о та к ж е запланировать проверк у ввода на предмет недопус­
тимости для отрицательных целых чисел, чисел с десятичной то чкой , нечисловых значе­
ний. Это ещ е больше увеличит количество возможны х вводов/поэтом у вероятность вы-
полнения абсолютно всех таких попыток станет ничтожно низкой . На основе проведен­
ных рассуждений мы приходим к фундаментальному ограничению тестирования:
Ограничение тестирования: Исчерпывающее тестирование компьютерной программ ы
невозможно .
Занимаясь аналогичными исследованиями, Прессман в [ 43 ] привел в качестве примера
программ у на языке С, состоящую из 100 стро к с двумя вложенными циклами, причем
каждый цикл выполняется от 1 до 20 раз . Во внутреннем цикле находятся четыре конст­
рукции if-end-else. В своей работе Прессман доказал, что на автоматизированное тести­
рование этой пр огр ам м ы при условии, что на проверк у каж д о г о из 10 1 4 возможны х пу­
тей будет тратиться одна миллисекунда, потребуется 3170 лет.
Приведенный приме р с почтовыми кодам и показал, что исчерпывающее тестирование
вводов невозможно , а приме р Прессмана дает право утверждать, что даж е в условиях
автоматизированного ввода исчерпывающее логическое Тестирование оказывается нере­
альным. Становится ясно, что одним из непременных условий быстрог о тестирования яв­
ляется разумный о тб о р тестов для выполнения.
Врезка 3.1
 Глава 3. Планировани е испытани й 61

Поскольку подвергнуть т е с ти р о в а н и ю абсолютн о все невозможно , важност ь вы­

бора того , чт о нужно прот естир ов ат ь , сомнен и й н е вызывает . Если допустит ь "пере ­
бор " в тестировани и , т.е., есл и те сто во е пок рыт и е будет избыточным , т о дл я отладк и
программног о продукта потребуетс я зна ч ит ел ьн о е время , чт о постави т по д угрозу
срок сдач и проекта . Если т е ст и р о в а н и е окажетс я недостаточн ы м (т о чн е е , недоста­
точны м будет тестово е п ок ры т и е ) , т о увеличитс я рис к пропуска тог о ил и иног о де­
фекта, устранен и е к от ор о г о будет стои т ь очен ь дорого , особенн о посл е сдач и про­
граммного продукта в эксплуатаци ю . О т ы с к а т ь нужный балан с между этим и двумя
крайностям и помож е т оп ы т и спосо б изме ре н и я успешност и те стиров ани я .
Вот нескольк о пр е дл о ж ен и й п о р аз р а б о т к е стратеги и тестировани я , к от ор ы е по­
могут в поиск е оптимально г о тестовог о пок рыт ия .
Тестируйт е в перву ю о чер ед ь требовани я с наивысшим приорит ет ом . Предпо ­
ложим , чт о в вашем ра с п оряж е н и и имеет с я документ оп р ед е ле н и я т р е б о в а н и й , в
которо м требовани я м п ри св оен ы п р и о р и т е т ы . Выб ери т е т е и з них , к оторы е
представляю т дл я заказчик а наибольш у ю важность , л и б о к от ор ы е п ри ч и н я т за­
казчику наибольши е не п риятн ост и в случае выхода прогр аммног о продукта из
строя . Если запланирова н о т е с т и р о в а н и е всех тр е бо ва ни й , и ресурс ы эт о позво­
ляют , естественн о , придет с я тщатель н о пр ов е ри т ь выполн ен и е всех тр еб о ва ни й .
В случае нехватк и ресурсов , п е ре д отправко й продукта заказчик у необходи м о
тщательн о прот естир ов а т ь т р е б о в а н и я с наивысши м и приоритет ами . Возможн о ,
стои т получить согласи е заказчик а н а т о , чт о треб ова ни я , к от ор ы е п ров е ре н ы
частичн о ил и не прове рен ы вообще , не будут поддерживатьс я вплот ь до следую­
щей верси и продукта.
Тестируйт е новы е функциональны е в о з мо ж н о с т и и программный код, кото­
рый изменялся с целью исправлени я или совершенствован и я стары х функ­
циональных средств. Эвристич ес к о е правил о гласит: есл и п рог ра ммн ы й код
подвергалс я исправлениям , ег о необходим о протестироват ь . В начальн о й верси и
программног о продукта новы м являетс я все. Однак о есл и верси я являетс я оче­
редны м обновление м ил и эксплуатационно й версией , особо е вни ма ни е следует
уделить новому коду. И м е й т е в виду, чт о любы е из м е н е ни я , внес ен ны е в про­
граммн ы й код, могут исказит ь даж е т е част и програм м ы , к от ор ы е непосредстве н ­
но "н е затрагиваются " изм ене ни ям и . В это м случае лучше всего как можн о чаще
выполнят ь регрессионн ы е тес т ы для все й функциональност и программы , каким и
бы ни был и измен ен и я в коде.
Используйт е разбиени е на эквивалентные классы и анализ граничны х значе­
ни й дл я снижени я трудозатра т н а тестировани е . Эт и тех но лог и и опи сан ы в гла­
вах 4 и 10; об е технологи и могут использовать с я для выявлени я максимальног о
62 Част ь I . Про ц ес с бы ст рог о тестировани я

тестовог о п ок ры т и я з а сче т опр ед е л ен и я поднабор а входны х зн ач ен и й в о врем я

т е ст и р о в а н и я компоне нт о в ввода/вывода .

Тестируйт е т е участки, в которы х наиболе е вероятн о присутстви е проблем.

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

Соср едоточь т е сво е внимание на функция х и конфигурациях , с которым и

наиболе е част о буде т иметь дел о конечны й пользователь. Если в спе ц и ф и к а ц и и
т р е б о в а н и й применяет с я методи к а случаев использовани я ил и ж е есл и у вас име­
етс я доступ к функционально м у разрез у конечног о пользовател я (т.е. математиче ­
скому ожидани ю использован и я каждо й функции ) , в ы получает е доп о лн ите л ьн ы й
источни к и н ф о р м а ц и и дл я установк и п р и о р и т е т о в т естиров ани я . Больша я част ь
времени , отведенног о н а т ес ти р ов ан и е , должн а затрачивать с я н а проверк у наибо­
ле е част о используемы х конфигураци й и операци й . Проблем ы тест и р ов ан и я
множественн ы х конфигурац и й будут подроб н о обсуждаться в раздел е "Тестовы е
кон фигураци и " дале е в эт о й главе.
Оди н и з доп ол нит е ль н ы х подходо в придат ь системному т е с т и р о в а н и ю большую
э ффе кт и вн ос т ь состои т в том , чтоб ы убедить р аз ра бот ч и к о в тщат ель н о выполнят ь
модульное т е с т и р о в а н и е и проверк у взаимодейств и я и фун к ци он и рова н и я компо­
нентов , прежд е че м передават ь программны й код тестово й группе. Слишко м част о
передач а тестово й группе то й ил и ино й программно й конструкци и завершает с я кон­
статаци е й о нев оз мо ж н ос т и е е установки , ил и тем , чт о посл е установк и конструкци я
н е работает . Значител ьн у ю част ь времен и н а т е с т и р о в а н и е можн о сэкономить , есл и
ввести в действи е н е к от ор ы е к р и т е р и и приемки , н е допускающи е передачу тес тов о й
группе неработающи х программн ы х кодов.
Объе м тестиро ван и я долже н определятьс я документами, регламентирующим и
план проведени я испытани й . П р и м е р фор мат а плана проведен и я испытан и й приво­
дитс я далее в главе. П р и м е р план а проведени я испытани й мо жн о найт и в тр етье й
части .

Определение подхода к тестированию

Втор о й разде л формулировк и стратеги и тестирован и я касаетс я определени я похода
к тестировани ю . По с т р о е н и е подхода к тестирован и ю начинает с я с исследовани я
каждой стади и жизне нн ог о цикл а разработ к и с целью отбор а тест о в статическог о и
динамическог о тестир ован и я , которы е могут быт ь использован ы н а соответствую­
щей стадии. П р и это м н е имее т зна че ни я , какая модель жиз не нн ог о цикла разработ­ ки
используется: каскадная, спиралевидна я ил и модель с итеративны м и версиям и — для
отбор а э ф ф е к т и в н ы х тест о в можн о исследоват ь этап ы люб о й пере чис ленн о й модели
. В качест в е при мер а возьм е м каскадную модел ь и выясним , каки е виды тести­ ровани я
могут для не е использоватьс я .
 Глава 3. Планирование испытаний 63

Стадия формулирования требований. Определите все документы, которые со­

держат требования и генерируются на данной стадии, а также все документы, со­
держащие итоги инспекций, которые получены как результат статического тести­
рования. Если вы составляете план проведения испытаний на стадии формулиро­
вания требований, этот шаг может оказать помощь при составлении плана и гра­
фика выполнения необходимых инспекций. Назначьте членов группы тестирова­
ния, которые должны принимать участие в проведении инспекций. Выберите
хранилище для результатов инспекций.
Стадия системного проектирования. Определите все проектные документы, ко­
торые составляются на данной стадии и план участия группы тестирования в свя­
занных с этим инспекциях. В документах, формулирующих требования (докумен­
ты технического задания), указано, что должно тестироваться, а документы эс­
кизного проекта помогут получить представление о том, как проводить тестиро­
вание.
Стадии тестирования проектов программ, программных кодов, модульного
тестирования и комплексных испытаний. Если группа тестирования принимает
участие в статическом или динамическом тестировании любых из указанных выше
видов деятельности, потребуются соответствующие планы. Время от времени,
группа тестирования прогоняет тесты с целью выявления утечек памяти или про­
верки цикломатической сложности тестирования на стадиях модульного тестиро­
вания и комплексных испытаний. Если этот так, то планы таких испытаний долж­
ны учитываться в общем плане испытаний. Если ответственность за эти стадии
возлагается только на коллектив разработчиков, их роль должна определяться в
форме предположения.
Системные испытания. Опишите запланированные вами виды тестирования:
функциональная проверка, нагрузочные испытания, испытания под нагрузкой,
проверка безопасности, проверка наращиваемости, проверка удобства и простоты
обслуживания и другие. Сформулируйте высокоуровневые цели для этих видов
тестирования и укажите, как проследить их связь с породившими их требования­
ми и функциональными спецификациями. Если какие-то виды тестирования опус­
каются, дайте логическое обоснование их пропуска и оцените связанные с этим
риски.
Приемочные испытания. Дайте описание плана приемочных испытаний, вклю­
чая альфа-, бета- и другие виды тестирования. Часто бывает полезно составить от­
дельный план приемочных испытаний, а в нем указать объемы работ и ограниче­
ния, накладываемые на тестирование, критерии включения и исключения из ис­
пытаний и условия испытаний. Поскольку нередко цель приемочных испытаний
состоит не только в том, чтобы продемонстрировать заказчику функциональные
возможности программного продукта, но и в обнаружении дефектов, план прие­
мочных испытаний целесообразно рассматривать как документ, направленный
извне.
Регрессионное тестирование. Укажите в плане регрессионного тестирования,
составлен ли он для эксплуатационных версий или же является частью стратегии
итеративного выпуска версий. Опишите, как выбираются и разрабатываются рег­
рессионные тесты, какое должно использоваться оборудование и какова страте-
64 Часть I . Про ц ес с быст рог о тестировани я

гия автоматизац и и р ег ре с с ио нн о г о тестировани я . Исход я и з предположения , чт о

тестам и покрыва ют с я н е все функциональн ы е возмо жност и , укажит е объем ы рег­
рессионног о т е с т и р о в а н и я и риски , связанны е с тем , чт о не к оторы е участки будут
пропущен ы и останутс я неп ок ры ты м и .
Подхо д к т е с т и р о в а н и ю долже н отражатьс я в документах, содержащ и х план ы
провед ен и я испытани й . Од и н и з способ о в показа н н а прим ер е шаблон а дале е в это й
главе. П ри м е р план а п р о ве д ен и я испытани й для п ри л ож ен и я Т М Т приводит с я в
третье й част и книг и .

Определение критериев тестирования

и точек контроля качества
Цел ь оп ре де л ен и я к ри т е ри е в те ст и ро в ан и я заключает с я в установк е н а мест е заказ­
чик а набор а правил , регламентирующи х пото к тест ирован и я . О ч е н ь важн о опреде­
литьс я с к рит е ри я м и т е с т и р о в а н и я д о начала исп ытан и й . Посл е того , как в ы присту­
пил и к вып олне ни ю план а испытаний , поздн о объявлят ь к рите рии , инициирующи е
ил и останавливающ и е т е с т и р о в а н и е . Напри ме р , есл и в ы рассчитывает е н а то , чт о
программны й продукт успешн о пройде т модульное т е с т и р о в а н и е и комплексн ы е ис­
пытани я , в ы должн ы заяв ит ь о б это м заране е в подготовленн о м план е испытани й .
Посл е этог о пла н долже н быт ь п р о ве р е н и утвержде н людьми , к оторы е будут зани­
маться модульным т е с т и р о в а н и е м и комплексны м и и спытаниям и . Ввод в действи е и
выполнен и е крите ри е в т е с т и р о в а н и я помогае т проект у выдерживат ь намеченны е
срок и за сче т исключени я временны х потерь , кот оры е будут неизб еж н ы в случае, ко­
гда на испытательн ы й сте н д попадае т программны й продукт, не готовы й к испыта­
ниям , либ о в ситуаци и , когда продолж аютс я испытани я продукта, которы й нужно
отправл ят ь на переделку.
Поскольку к ри т е р и и т е ст и р о в а н и я затрагива ю т и н т е р е с ы других групп, он и н е
могут односторонн е устанавливатьс я группой тестировани я . П ри м е н е н и е критерие в
должн о быт ь согласован о с о всеми заинтересованным и сторонами . К ри те ри и могут
быт ь установлены для модульного тестирован и я и комплексны х испытаний , однак о
таки е критери и обычн о определяют с я организацией-разработчико м . Рассматривае­
мые здесь кр ите ри и те ст и р ов а н и я применяютс я главным образо м в отношен и и сис­
темног о тестировани я .
Существует пят ь ти п о в кр итериев , которы е могут определятьс я пере д началом
системног о тестиро вани я .
Критери й входа описывает , чт о нужно сделать пере д начало м тестировани я . На­
пример , возможно , потребуетс я располагат ь документами технич еског о задани я в
окончательн о й ф о р м е . Мо жн о поставит ь задачу, чтоб ы программн ы й продукт был
упакован в то м же виде, в како м он будет поставлятьс я заказчику. Во врем я тести­
ровани я може т возникнут ь необходимос т ь в служебных программа х , конфигура­
ционны х ф а й л ы ил и данных , которы м и будет пользоватьс я заказчик . Если на вас
возложен а ответственност ь з а проверку документации , сопровождающе й про­
граммны й продукт, он а такж е должн а быт ь доступна в о врем я тестировани я . Оди н
из способо в выполнен и я к р ит е р и я входа предусматривае т проверк у готовност и к
испытаниям . Эт а про вер к а использует контрольну ю таблицу элемент о в действий ,
которы е другие группы согласились передать как входные данны х для тестирования .
 Глава 3. Планировани е испытан и й 65

Критери й выхода описыва е т то , чт о в ы считает е необходимы м для з ав е р ш е н и я

ис п ыта ни й . Несмот р я н а т о чт о группы т е ст и р о в а н и я част о пыт ают с я сделат ь
к ри т е р и й выхода условием поставк и программно г о продукта, эт о нереально . Ре­
шени е н а поставку принимает с я и должн о приниматьс я высши м руководство м
ра зр а бо то к . К ри т е р и й выхода и з испытан и й долже н звучать п р и м е р н о так : "все
запланированн ы е тест ы выполн ены , все исправленн ы е д е ф е к т ы п ров е ре н ы , уве­
домлен и я о всех обнаруженн ы х новы х д е фе кт а х был и выдан ы . Н е в ы п ол н е н н ы е
пункты плана , таки е как неудачны й п р ог о н н е к о т о р о г о набор а тест о в из-за неис­
правност и оборудовани я , задокументированы " . Ка к и в случае к ри т е р и я входа в
испытани я , допускается пр ов е де н и е п рове рк и гото вност и , к о т о р а я об е сп е чи т
полн о е выполнени е всех тестов , и о ц е н к и готовност и п р ог р ам мн о г о продукт а к
поставка м н а баз е результато в тестировани я .
Критери й приостановки /возобновлен и я описывает , чт о про изо й д е т , есл и п о
п ри ч и н е из-за деф е кт о в п р од о л же н и е т е с т и р о в а н и я окажет с я невозможны м . Дру­
гим и словам и , есл и дела складываютс я настольк о неудачно, чт о з ап л ан и ров а нн ы е
испытани я провест и н е удается, и х необходим о п р е к р а т и т ь д о те х по р , пок а обна­
руженн ы е де ф ек т ы не будут устранен ы .

Кри тер и й успешного/неудачног о прохождени я теста. Про го н каждог о тест а

долже н дават ь заране е известны е результаты . Если получен ожи дае м ы й результат,
считается , чт о продукт успешно проше л тест , в противно м случае прох ожд е н и е
тест а завершает с я неудачно. В т о ж е врем я може т случиться так , чт о п р о г о н неко­
т о р о й группы тесто в н е выполняется , поскольку о н и ли б о искажен ы ил и заблоки­
рован ы дефектам и , ли б о необходимы е для и х прогон а ресурс ы отсутствуют. Целе­
сообраз н о определит ь за р а не е , чт о делат ь с тестам и , к оторы е н е удалось выпол­
нить . Возможн о , будет запла н иров ан о п ом ет и т ь каждый н е в ы п ол н е н н ы й тес т бук­
во й " N " в итогово м отчет е и объяснит ь в пол е ком ме нтари я , чт о случилось и чт о
был о предп рин ят о в контекст е ре ш е н и я пробл ем ы . Може т быть , в ваш и план ы
входи т замен а искаженн ы х тест о в специальны м видом те с т и р о в а н и я и регистра ­
ци я результатов в специально м акт е об испытаниях .
Други е критерии, определяемы е процессо м или стандартами. Если программ­
ны й продукт долже н соответств ова т ь некотором у стандарту ил и ваша ко м пан и я
предъявляе т определенн ы е требовани я к выполняемом у процессу, скоре е всего,
придетс я учесть ря д дополнительн ы х критериев . На п р и м е р , в вашем локальн о м
процесс е могут быт ь определен ы к о н к р ет н ы е средства, выдающи е сооб щени я о б
обнаруженны х дефекта х ил и отч ет ы п о результатам ис пытаний .
В д оп о лн ен и е к приведенны м выш е критерия м , полезн о определит ь к р и т е р и й
тестировани я и подготовит ь контрольну ю таблицу готовност и в рамка х план а прове­
дения испытаний . Это т момен т отобра ж е н в опи сан и и плана проведен и я исп ыт ани й
далее в главе и в пример е плана проведен и я ис пыт ан и й в тр етье й част и книги .

Определение стратегии автоматизации

При наличи и реальны х плано в и разумны х предположен и й использован и е автомати­
зированны х инструментальны х средст в и автоматизированн ы х тестов ы х случаев
представляет собо й прекра сн ы й спосо б сни же н и я вре менны х за тра т н а тестиров ан и е
программног о продукта. Люба я многократ н о выполняема я задач а я в л яет с я кандида-
66 Част ь I . П ро ц е с с быст рог о тестировани я

то м н а а вт ом ат иза ци ю . О днак о обыч н о н а а вт о ма т иза ц и ю задач и уходит намног о

больше времени , че м н а е е вып олн ени е , поэтом у дл я каждо й задачи , к от о р а я може т
быть авто м атиз ир о в ан а , це ле с о об р аз н о пр о в ес т и тща те л ьны й анали з потенциально ­
г о выиг р ы ш а о т автоматизаци и . Выполн я я анали з возможн ы х выгод, следует пом­
нить , чт о для само й а вт о м атиз ац и и характере н с о бст ве нн ы й автономны й ж и з н е н н ы й
цикл. Э ф ф е к т и в н а я автом ат изац и я требуе т специально й подготов к и персонала , раз­
работки , отладк и и в е р и ф и к а ц и и , как и люб о й другой пр ое к т разработ к и программ­
ного об еспеч ени я . Бесп ла нова я и плох о в ып ол не н н а я автоматизац и я означа е т н е
тольк о на п ра с ны й расхо д ресурсов, он а даж е може т пр ив е ст и к нарушени ю гра фи к а
выполняем ы х работ , есл и врем я будет тратить с я на отладку средст в автоматизации , а
не на т е ст и р о в а н и е .
Да ст и н (D ustin) , Раш к а (Rashka) и Пауль (Paul ) в [15] приводя т наиболе е распро ­
страненн ы е необ осн ова нн ы е предположени я , связанны е с примене ни е м автомати­
зированног о т е ст и ров ан и я , равн о ка к и р еа л ьн ы е выгоды , н а кот ор ы е можн о рассчи­
тывать , есл и а в т о м а т из а ц и и выполнен а правильн о и следует строгому процессу. Не­
обоснованны е п р е д п о л о ж е н и я (ожидания ) сведен ы в табл . 3.1, а до сти ж им ы е выгод ы
от ав то м атиз ац и и п е р е ч и с л е н ы в табл. 3.2.
Если вы все-таки решил и с ь вложит ь средств а в а вт о м атиз ац и ю тестировани я , сле­
дует проана лизиров а т ь все последстви я этог о ре ш е н и я в рамка х выбранно й страте ­
гии тестировани я . Н а п р и м е р , задач а фор м и ро в а н и я тестово й сред ы може т зависет ь
от того , ка к будет осуществлятьс я прого н т ест о в — в автоматич еск о м ил и в ручно м
режим е . Поскольк у и дл я задач , решаем ы х в ручном р е ж и м е , и для задач, реш ае м ы х в
автоматическ о м р е ж и м е , необходим о п ри о б ре т а т ь одн и и т е ж е аппаратны е средст­
ва, соединят ь их между с о бо й кабелями , подключат ь к компьютерн ы м сет я м и вво­
дит ь их в эксплуатаци ю , возможно , имее т смысл сделат ь автоматизированн у ю тесто­
вую среду п о с т о ян н о действующе й конфигурацией . П од обн ы й подход позволи т вы­
полнят ь автоматизи рова нн ы е тест ы бе з вмешательств а с о сторон ы оп е р ат ор а . Если
предполагает с я выпол нят ь прого н автоматизированны х тест о в в рамка х регрессив ­
ных исп ыт ан и й ил и дл я целе й технич еског о обслуживания , имее т смысл построит ь
специализированну ю стационарну ю испытательну ю установку, котора я будет нахо­
дитьс я н а р а б оч е й площад к е вес ь период , пок а поддер жива етс я программн ы й про­
дукт. Однак о тако е р е ш е н и е влече т з а собо й существенно е увеличени е расходо в н а
установку соответствующ и х аппаратн ы х средст в и на помещ ени я , в которо м распола­
гается испытательн ы й стенд . В случае неавтоматизированно г о режим а тестиро ван и я
конфигураци я технически х средст в создается п о ходу дела.
Другая проблема , связанна я с разработко й с тр а тег и и автоматизации , имее т отно­
шени е к процессу. Х ор о ш о известно , чт о тестир ова н и е программног о обеспечен и я
должн о бы т ь с ф о р м и р о в а н н ы м д о п р ин я т и я р е ш е н и я п о поводу автоматизации . Тер ­
мин " с ф о р м и р о в а н н ы й " означает , чт о тестир ован и е интегрир ова н о в ж и з н е н н ы й
цикл программног о обеспечени я , чт о в основу целе й испыт ан и й и тестовы х случаев
положен ы требо вани я , и чт о существует автономна я организац и я тестов . По п ы т к а
использоват ь автоматизац и ю в условиях ха отич ног о процесс а тестирован и я едва л и
окажетс я успешной . Автоматиза ци ю лучше всего внедрят ь как част ь непре ры вног о
процесс а совершенствовани я процесс а тестиров ан ия , н о н е применят ь подход
"большого взрыва", требующий автоматизации всего и сразу. (Боле е подробную инфор ­
мацию, касающуюся совершенствован и я процесса тестирования , можн о найт и в главе 6).
Глава 3. Планирование испытани й 67
68 Част ь I. Процесс быстрого тестирования
 Глава 3. Планирование испытаний 69

Планы относительно автоматизации процесса тестирования должны быть вклю­

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

Определение стратегии тестирования

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

Архитектура тестов
Архитектура тестов имеет отношение к организационной структуре тестовых случа­
ев. На практике целесообразна такая организация тестов, когда каждый тест рассчи­
тан на проверку некоторой четко заданной части функциональных возможностей
программного продукта. Если тест закончится неудачей, разработчик легко может
повторно прогнать этот тест и воспроизвести обнаруженный дефект, затем проана­
лизировать его и попытаться выявить причину. В идеальном случае границы обсле­
дования теста должны быть сужены, а сам тест должен выполнять некоторый мини­
мальный набор действий, необходимых для того, чтобы вызвать отказ системы.
Если основой проводимых испытаний служат требования к программному про"
дукту, то практическим правилом для определения границ обследования конкретного
теста может служить критерий, по условиям которого на каждое такое требование
полагается, по меньшей мере, один тест. Помимо того, что это правило определяет
эффективные размеры тестов, принцип "по меньшей мере, один тест на требование"
упрощает поддержку планирования проведения испытаний. На основе анализа тех-
70 Часть I. Процесс быстрого тестирования

нического задания можно получить представление о том, сколько нужно новых тес­
тов для испытания нового программного продукта. Если составлять тесты, руково­
дствуясь этим принципом, несложно оценить, какое время отымет разработка и про­
гон тестов, основанных на ранее полученных результатах.
Испытания по описанному выше принципу позволяют систематизировать органи­
зацию тестов. Требования обычно объединяются в группы по функциональным при­
знакам. Вы можете организовать свои тесты по такому же принципу. Тесты, осущест­
вляющие проверку готовности к работе технических средств заказчика, могут быть
объединены в одну группу; точно так же тесты, проверяющие механизмы установки и
наращивания возможностей системы, образуют другую группу. Группа родственных
тестов называется тестовым набором (test suite).
Каждое требование может состоять из нескольких компонентов. Например, тре­
бование, регламентирующее процедуру редактирование элементов базы данных кон­
кретного заказчика, может определять несколько различных сценариев. Тестовый
случай (test case) есть набор входных данных тестов, условий выполнения тестов и
ожидаемых результатов, который ориентирован на достижение конкретной цели.
Тестовый случай представляет собой минимальный тестовый модуль, допускающий
независимое выполнение от начала до конца. Отношения, связывающие тестовые
наборы, тесты и тестовые случаи, показаны на рис. 3.3 и в табл. 3.3.

После того, как удалось определить организационную структуру тестов, возникает

необходимость дать описание хранилища для хранения тестов и средств управления
версиями для последующего воспроизводства тестов. Это хранилище должно обла­
дать определенными характеристиками:
• Специалисты по тестированию, разрабатывающие и осуществляет прогон тес­
тов, должны иметь простой доступ к хранилищу. Часто в качестве хранилища
используется сетевой дисковый накопитель коллективного доступа.
 Глава 3. Планирование испытаний 71

• С этого хранилища регулярно снимаются копии, а полученные резервные ко­

пии файлов периодически восстанавливаются с целью проверки правильности
функционирования средств копирования и восстановления. Необходимость
дублирования всех планов проведения испытаний, тестовых случаев, результа­
тов тестирования очевидна, тем не менее, зачастую такое дублирование игно­
рируется.
• Должно быть налажено управление версиями, что обеспечит простое выявле­
ние более старых тестов. Управление версиями при необходимости обеспечи­
вает воспроизведение любого теста, который когда-либо выполнялся на про­
граммном продукте.

Инструментальные средства тестирования

В начале этой главы отмечалось, что решение перейти на автоматическое тестирова­
ние оказывает влияние на всю стратегию тестирования. В этом разделе основное
внимание будет уделяться инструментальным средствам тестирования. Общая стра­
тегия автоматизации тестирования не ограничивается лишь одним программным
продуктом; эта стратегия должна быть глобальной, распространяющаяся на многие
проекты, и тщательно интегрированной с процессом тестирования.
Таким образом, план проведения испытаний конкретного программного продукта
определяет, какой фрагмент общей стратегии автоматизации будет реализован в те­
кущем проекте. Возможно, потребуется добавить автоматизированное испытание
программного продукта под нагрузкой, либо автоматизировать тестирование GUI-
интерфейса. Может быть, возникнет желание воспользоваться автоматизированным
генератором отчетов, который пересылает результаты тестирования и метрики про­
граммного продукта на Web-страницу. После определения затрат времени и средств,
связанных с оценкой и приобретением (или построением) инструментария, который
необходим для завершения автоматизации, и последующей оценки трудозатрат на
обучение новому инструментальному средству, скорее всего, будет принято решение
о включении в проект только одного-двух инструментальных средств подобного рода.
Включение большего числа новых инструментальных средств мало того, что непро­
дуктивно, но еще и требует существенных затрат.
Существует широкое разнообразие инструментальных средств, служащих для под­
держки тестирования. Некоторые из этих средств перечислены в табл. 3.4. Эта таб­
лица отображает инструментальные средства на этапы жизненного цикла разработ­
ки, где они могут использоваться.
72 Часть I. Процесс быстрого тестирования

Более подробную информацию по инструментальным средствам тестирования

можно найти в [15], [30] и [40]. Каждый перечисленный источник содержит также
полезную информацию, связанную с плакированием испытаний.
 Глава 3. Планировани е испы т ан и й 73

Среда тестирования
Среда тестирован и я состои т и з физ и че с к и х средст в тестиров ани я , о п е р а ц и о н н о й
системы, под управление м к от о р о й выполняетс я программны й продукт, и вычисли­
тельно й платфо рмы , н а к от о р о й эксплуатируетс я программн ы й продукт. Многи е
компании, занимающиес я тестирование м программн ы х продуктов , обзавелис ь собст­
венными испытательны м и лабо ратор иям и . Ка к и автоматизаци я , раз в е рты в ан и е хо­
рошей испытательн о й л аб орат ори и связан о с долгосрочным и инвестициям и , кото­
рые ложатс я на множеств о прое кт о в и требую т отдельны х усилий . Разумеется , хоро­
шего качеств а тестирован и я можн о добитьс я и на одно м компьютере , установленно м
в отдельн о м крохотно м по мещени и , однак о об щ еп р ин ят о й н о р м о й стал о создани е
испытательны х лаборатори й , обеспечивающи х настройк у тес тов о й сред ы и условий,
в рамках которы х производитс я оце нк а качеств а программног о продукта.
Рек с Бле к (Rex Black) в [33] разверну л дискуссию вокруг вопросо в оснащен и я и
организаци и испытательн ы х лабо рат ори й . О н предлагае т следующее: прежд е чем
принимат ь решени е о т н о с и т е л ь н о необходимост и создават ь специализированн у ю
испытательную ла б о р ат о ри ю , потребуетс я дат ь ответ ы н а приводимы е ниж е вопро -
74 Часть I. Процесс быстрого тестирования

сы. К созданию специализированной испытательной лаборатории можно присту­

пать, если вы ответите "да" на хотя бы один из следующих вопросов:
• Существует ли необходимость в крупногабаритном стационарном оборудова­
нии, таком как, например, камера искусственного климата, генераторы данных
и анализаторы или приборы измерения электромагнитного излучения?
• Должны ли предприниматься специальные меры безопасности по защите кон­
фиденциальной информации или крупных вложений?
• Нужно ли тщательно следить за условиями, в которых проводятся испытания, и
регулировать их? Это может, например, означать, что персонал, не прини­
мающий непосредственного участия в испытаниях, не должен иметь доступа к
системным испытаниям во имя предотвращения изменений в условиях испы­
таний.
• Требуется ли поддерживать некоторый набор фиксированных тестовых кон­
фигураций в течение продолжительного периода времени, например, при под­
держке итеративного набора версий?
Планируя тестирование конкретной версии программного продукта, следует оп­
ределить, какой аспект общей стратегии построения испытательной лаборатории
нужно реализовать. Например, может возникнуть необходимость добавить опреде­
ленное оборудование, генерирующее данные, либо дополнительные платформы для
испытания программного продукта под нагрузкой или при перегрузках.

Конфигурации аппаратных средств тестирования

Предположим, что тестируемый программный продукт, в соответствии со специфи­
кацией, должен выполняться на широком наборе сетевых конфигураций, использует
несколько различных конфигураций клиентских машин, должен работать под управ­
лением различных операционных систем и быть доступным из разных браузеров.
После исследований числа возможных конфигураций оборудования, могут быть по­
лучены, например, такие комбинации:
• 5 сетевых конфигураций
• 10 сочетаний браузеров и операционных систем
• 20 комбинаций клиентских конфигураций (центральный процессор, жесткие
диски, видеоадаптеры и периферийные устройства)
Таким образом, количество возможных тестовых конфигураций есть
5 х10х20=1000. Если вы рассчитываете на то, что два специалиста по тестированию
способны провести запланированные системные испытания на одной конфигурации,
то для полного завершения тестирования всех конфигураций вам потребуются
240000 человеко-часов, или 125 человеко-лет! Если необходимые средства и большой
штат специалистов по тестированию отсутствует, либо же если просто нет достаточ­
ного времени, подобное тестирование не имеет смысла.
В начале главы мы сформулировали основной принцип тестирования, который
гласит: исчерпывающее тестирование программы провести невозможно. То же самое
справедливо и в случаях, когда приходится выполнять тестирование нескольких ком­
бинаций возможных конфигураций системы: невозможно полностью протестировать
 Глава 3. Планирование испытаний 75

абсолютно все конфигурации системы. Основной способ состоит в установке соот­

ветствующих приоритетов конфигурациям. А вот дальше уже можно решать, какие
конфигурации нужно подвергать полной отладке, а к каким применять частичное
тестирование.
Установка приоритетов для конфигураций обычно зависит от следующих фак­
торов:
• Частота использования: сколько экземпляров заданной конфигурации скорее
всего будет использоваться?
• Риск отказа в работе системы: существуют ли ответственные конфигурации для
важных заказчиков?
• Вероятность отказа системы: фиксировались ли в прошлом отказы конкретных
конфигураций?
После определения конфигурации для полного или частичного тестирования сле­
дующим действием должно быть определение, какие тесты необходимо выполнить на
конфигурациях, подлежащих частичному тестированию. Предполагая, что приори­
теты тестам уже присвоены (см. раздел "Определение объемов тестовых работ" ранее
в главе), можно выполнять прогон только тестов с высокими приоритетами на неко­
торых конфигурациях и тестов с высокой вероятностью отказа на конфигурациях, на
которых имели место проблемы в прошлом.
После идентификации тестируемых конфигураций потребуется определить их во
всех деталях, чтобы специалисты по тестированию могли их установить и воспроиз­
вести в момент, когда возникнет необходимость прогона тестов. Каждая конфигура­
ция средств тестирования может быть определена при помощи блок-схемы и специ­
фикации запасных частей или, если связность между компонентами системы очевид­
на, конфигурацию можно задать списком компонент.

Оценка трудозатрат на тестирование

Одной из наиболее важных компонент планирования является оценка трудозатрат и
времени, необходимых для тестирования. Затраты на тестирование могут составлять
существенную часть сметной стоимости проекта, при этом жизненно важно для успе­
ха этой операции, чтобы тестирование проводило достаточное число специалистов и
у них было достаточно времени на качественное выполнение своих задач.
Получение оценки трудозатрат на выполнение проекта можно разбить на пять
этапов:
1, Определение задач, которые должны быть выполнены. Эта оценка начи­
нается с определения работ, которые необходимо выполнить для того, чтобы
тестирование программного продукта считалось состоявшимся. В рамках не­
которых методологий на этом этапе вполне достаточно разбить работу на за­
дачи. Если используются менее формальные методы, то результатом этого
этапа может быть простой список задач.
2. Оценка трудозатрат на решение отдельных задач и всего жизненного цик­
ла тестирования. Каждая задача, выявленная на первом этапе, требует для
своего решения определенных трудозатрат, представляющих собой объем ра­
бот, необходимых для выполнения соответствующей задачи. Трудозатраты
76 Част ь I . Про ц ес с быст рог о тестировани я

представлен ы в вид е произведени я количест в а исполнителе й н а зат р а че нн о е

им и врем я и и з м е р я е т с я в таки х единица х как человеко-ден ь ил и человеко-
месяц . Существуют раз лич ны е метод ы оц ен к и трудозатрат , част ь и з которы х
рассматривает с я дале е в разделе .

3. Определени е времени , требуемог о дл я решени я каждо й задачи и длитель­

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

4. По стро ени е подробн о г о расписания и поэтапног о график а каждо й тесто­

во й задачи. Н а основ е результато в тре х предыдущи х этапо в можн о по ст р ои т ь
графи к в ып олн е н и я работ , возможно , в виде диаграм м ы Гант а (Gantt) , и вы­
числит ь сумму наиболе е важны х временны х зн ач ен ий .

5. Оценк а риско в невыполнени я графика рабо т и формулировк а планов и х

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

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

понять , наскольк о т о ч н ы м и могут быт ь наши оц ен к и . В само м начал е проект а (пере д
выявлени е м и изучени е м т р е б о в а н и й ) очен ь трудно опред елит ь , како й окажет с я
стоимост ь проекта . Фактическа я стоимост ь проект а становит с я известно й толь к о н а
заверш аю щ е й стади и проекта . Н а начально й стади и проект иров ан и я може т имет ь
мест о ка к недооценка , та к и п ере оцен к а фак тич е ск о й с то им о с т и проекта , прич е м
приблизитель н о в ч е т ы р е раза . П осл е того , как все т р е б о в а н и я будут проанализиро ­
ван ы и начальна я ф а з а плани р о ва н и я завершена , оц ен к а стоимост и проект а об ычн о
отлича етс я о т окон чатель н о й , факт и че ск о й стоимост и проект а п р и м е р н о в два раз а
[40] . Точност ь оц е н к и иллюстрир уетс я графиком , пок азанн ы м н а рис . 3.4.
Ввиду нето чностей , свойственн ы х процессу оценки , целесообраз н о периодическ и
возвращатьс я к о ц ен к е трудозатра т и гр аф и к а в ып о лн ен и я рабо т и считат ь э т о не­
отъ емлемо й часть ю о рг а н из а ц и и рабо т п о тестировани ю . Если за тр а т ы времен и и
трудозатрат ы начина ю т превышат ь исходные оценки , жела тель н о как можн о быст­
р е е поставит ь в известност ь об это м факт е руководство проекта , а не ждать, когда эт а
ситуация переродитс я в настоящи й кризис .
Следующие нескольк о ра здело в данно й главы даю т обз о р процесс а оценки . Пред­
лагаютс я альтернативн ы е стра тег и и выполнени я тр е х основны х действи й и з приве­
денног о выш е списка , при че м вмест е с о всеми з а и против . Бол е е подробн о техноло­
ги и оцен ки , ос об енн о т е и з них , которы е относят с я к категори и алгоритмическо й
оценки , будут рассматриватьс я в главе 12. Хороши м справочн ы м пособие м по оценк е
являетс я уже ставша я классико й [40] . Кром е того , внимани е заслуживает такж е и от­
носительн о недавня я публикаци я [33] , в кот о р о й описывает с я модел ь оц е нк и
С О С О М О II .
 Глава 3. Планирование испытаний 77

Определение задач
Простейший способ получения списка задач предусматривает просмотр документов,
в которых сформулированы требования, и выписывание всех выполняемых работ,
чтобы затем проверить функции, определенные этими требованиями. Как только
список будет определен, составляющим его задачам присваиваются приоритеты. В
качестве руководящих принципов в отношении приоритетов функций должны ис­
пользоваться документы, содержащие формулировки требований. В то же время мо­
гут возникать и дополнительные соображения, оказывающие влияние на выбор при­
оритета. Например, некоторые из программных кодов, реализующих ту или иную
функцию, при переходе на новую версию программного продукта могут претерпевать
лишь незначительные изменения, тогда как другие функции в новой версии появля­
ются впервые. По-видимому, новому программному коду имеет смысл посвятить повышен­
ное внимание, нежели модифицированному коду. Кроме того, придется уделить больше
времени на проверку проектньгх решений и структуры, а также на отладку нового кода.
В дополнение к обычному просмотру требований необходимо учесть задачи, ко­
торые не имеют прямого отношения к документам с требованиями, но то же время
делают тестирование возможным. Например, неплохо было бы включить в указан­
ный выше список такие задачи:
• Составление плана проведения испытаний
• Пересмотр плана проведения испытаний
• Разработка тестовых случаев
• Отладка тестовых случаев
• Проверка исправления дефектов
• Определение тестов и показателей программного продукта и процесса их сбо­
ра и использования
78 Часть I. Процесс быстрого тестирования

• Статическое тестирование: проверка и пересмотр проектов программных

средств и кодов
• Реализация выбранной стратегии автоматизации тестирования в разумных
пределах
• Пересмотр пользовательской документации
• Приобретение оборудования, необходимого для реализации данного проекта,
как составная часть стратегии создания универсальной испытательной лабора­
тории
• Прием на работу специалистов по различным профилям тестирования необхо­
димой квалификации
• Освоение специалистами по тестированию новых технологий и новых инстру­
ментальных средств
• Прогон тестов и отчеты по результатам тестирования
• Проведение проверок готовности
• Оценка выполнения проекта.
После построения исходного списка полезно его просмотреть вместе с группой
тестирования и мысленно пройти через полный цикл разработки жизненного цикла,
определяя необходимые компоненты и задачи, которые должны выполняться для
нужд группы тестирования. По всем признакам список задач является динамическим
документом, претерпевающим изменения на стадии планирования и, скорее всего, на
протяжении всего жизненного цикла тестирования по мере роста понимания того,
что должно быть сделано.
Список задач имеет еще одно название — список WBS (Work Breakdown Structure —
декомпозиция работ). Декомпозиция работ часто менее формальна, чем описанный
выше список задач, с другой стороны, она может выглядеть как иерархически упоря­
доченный список видов деятельности, в которых каждой задаче присваивается "деск­
риптор" или идентификатор. Дескриптор позволяет отслеживать задачу на протяже­
нии всего жизненного цикла разработки и предоставляет возможность связывать
измерения трудозатрат или расходов с различными задачами. Благодаря этому можно
снимать наборы показателей, характеризующих фактические затраты на протяжении
всего проекта. Разумеется, больше формальностей и больше отчетности означают
большие накладные расходы в смысле времени и стоимости, поэтому следует найти
разумный компромисс между уровнем детализации планирования и организацией
проекта. Обычно компромисс в таких случаях достигается за счет использования ин­
струментальных средств организации проектов, подобных, например, Microsoft Pro­
ject, во время планирования и отслеживания трудозатрат на тестирование. Отдавая
предпочтение тому или иному инструментальному средству, следует убедиться, что
его вход и выход совместимы с инструментальными средствами, которые применяют
другие группы.
Для целей быстрого тестирования список задач должен быть точным и содержать
все крупные задачи, особенно те, которые требуют времени на подготовку, напри­
мер, приобретение необходимого оборудования, прием на работу квалифицирован­
ного персонала или его обучение, а также проектирование тестов. Игнорирование
этапа подготовки к выполнению крупной задачи перед тестированием может привес-
 Глава 3. Планировани е испытани й 79

ти к сбоя м в гра фи к е сдачи проекта . Другим полезны м объе кт о м п ри л ож е н и я усили й

н а этап е планирован и я являетс я к оорд ин ац и я в ып олн ен и я опреде ленн ы х зада ч с
другими группами-участниками проекта . Т очн а я формулировк а зада ч и наз нач ен и е
ответственн ы х з а выпол не н и е каждой задач и списк а способствую т соблюд ен и ю гра­
фик а работ , особенн о когда вы ра с с чит ы ва ет е , чт о кто-то, не входящи й в вашу груп­
пу, долже н выполнит ь опре деле нн ы е задач и из списка.

Определение трудозатрат
После определени я задач, кот оры е необходи м о в ыполнит ь в процесс е те стиров ан и я
программног о продукта, следующее действи е н а этап е пла ни ров ан и я заклю чает с я в
получение оценк и трудозатра т н а вы п ол не н и е задач и з списка . Трудозатрат ы могут
быть выражен ы в человеко-часах, человеко-месяцах и человеко-годах. Каким и бы
единицам и измерени я м ы н е пользовались , трудозатрат ы (effort) ест ь мер а потребно ­
сти в персонал е и времен и для реш ен и я кон кретног о набор а задач. Нужн о соблюдат ь
определенну ю ос то р о жн о с т ь п р и оценк е необходим ы х трудозатрат , поскольк у част о
возникаю т ситуации, когда об ы кн ове нн а я а ри фм ет и к а н еп ри м ен им а . Классическа я
ошибка, котора я получила широк о е рас п рост ра не н и е пр и п л а н и ров а н и и , сост ои т в
следующем. И з факта , чт о не к от ора я задача може т быт ь выполнен а одни м исполни ­
телем з а ч еты р е недели , делаетс я вывод , чт о че ты р е исполнител я смогут вып олнит ь
эту же задачу за одну неделю , поскольку в то м и другом случае трудозатрат ы одинако ­
вы. Несост оятельност ь таког о "подхода" обсуждается во врезк е 3.2.

НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ О ШИ БК И ПРИ ОЦЕНК Е ТРУД ОЗ А Т Р А Т

Независимо от того, какая методика применяется для оценки трудозатрат, имеет место целый
ряд факторов, вносящих неточности в эти оценки. Ниже рассматриваются некоторые из фак­
торов, приводящих к возникновению классических ошибок в процессе оценивания:
• Неполный набор требований
• Изменения, внесенные в требования
• Переоценка времени, затрачиваемого исполнителями на выполнение конкретно й
задачи
• Не учитывается время , затрачиваемое на интегрирование системных компоненто в
• Не учитывается время, затрачиваемое на исправление обнаруженных дефектов
• Не учитывается время , затрачиваемое на решение непредусмотренных пробле м
• Не учитывается время, затрачиваемое на подготовку персонала
• Включение сверхурочного времени в первоначальный план
• Неполучение ожидаемых результатов от персонала, исполняющего работу
• Необоснованное привлечение дополнительных трудовых ресурсо в в попытке сократить
срок и решения задачи.
Первые две позиции списка относятся к требованиям. Далеко не достаточно заявить, что
для процесса планирования и оценк и большое значение имеет полный набо р требований,
и если они продолжаю т изменяться, то после их "фиксации" планирование придется вы­
полнить е щ е р аз . Остальные позиции рассматриваемого списка относятся к категорий
нереалистичных ожиданий.
80 Часть I. Процесс быстрого тестирования

Например, нет никаких оснований полагать, что кажды й исполнитель посвятит поручен-
ной плановой задаче 40 и более часов в неделю на протяжении всего срока разработки
проекта. В тако м случае не останется времени на совещания, подготовку и обме н ин-
формацией. Необходимо располагать временем на отладочные тесты, на решение ме-
дицинских пробле м и да ж е пробле м личного характера.
Последняя позиция списка требует дополнительных пояснений. Пр е ж д е че м дополни-
тельно подключать людей с целью сокращения сро ко в решения той или иной задачи,
следует определить, ка к у ю задачу можно разделить на подзадачи [ 4 0 ] . Например,
движущимся автомобилем м о ж е т управлять только один человек, поэтом у задача
управления автомобилем не допускает разбиения на подзадачи. Для задач, которы е
можн о разбить на подзадачи, необходимо исследовать две составляющих накладных
расходов: подготовку исполнителей, дополнительно привлеченных к решению задачи, и
'о бм е н информацией м е ж д у исполнителями, которы е одновременно работают над од­
ной и той же задачей. Процесс подготовки исполнителей не допускает разбиения на час­
ти, так что трудозатраты на подготовку большего числа исполнителей возрастают в ли-
нейной зависимости от количества привлеченных исполнителей.
Возможные пути обмен а информацией м еж д у исполнителями показаны на рис. 3.5. Если
над задачей работает один исполнитель, то накладные расходы, обусловленные необхо-
димостью обмен а информацией, отсутствуют. Если дополнительно привлекается один
исполнитель, то м еж д у двумя исполнителями добавляется двунаправленный компонент
обмена информацией. Если к решению задачи привлекается третий исполнитель, трудо -
затраты на о бм е н информацией возрастают втрое по сравнению со случаем участия
двух исполнителей. Трудозатраты, связанные с о бм е н о м исполнителями информацией,
не подчиняются линейной зависимости от количества привлеченных исполнителей, но
возрастают в соответствии по формул е n ( n - 1 ) / 2 [ 4 0 ] .
В об ще м случае, две наиболее распространенных ошибки , связанные с привлечением
дополнительных работников для сокращения сроко в сдачи проекта , заключаются в при­
влечении работников к решени ю задач, не допускающих разделения на подзадачи, и
пренебрежение накладными расходами на подготовку новых исполнителей и обме н ме-
жд у ними информацией.
Существуют следующие способы преодоления перечисленных выше трудностей и полу-
чения более точных оценок :
• Начинать следует с однозначно определенных "зафиксированных" требований.
• Основывать предположения и планы снижения рисков на результатах аналогичных
проектов, выполненных ранее
• Использовать реалистичные оценки ожидаемо й экономии времени от привлечения к
решению конкретных задач дополнительного персонала.
Врезка 3.2.

Ниже даются описания ряда распространенных технологий оценивания трудоза­

трат в порядке возрастания их сложности. Однако следует иметь в виду, что более
сложные технологии не обязательно дают более точные оценки. Любая технология
оценивания зависит от квалификации и опыта использующего ее работника, и для
того, чтобы получить представление о точности той или иной технологии необходи­
мо проверить ее на статистических данных.
 Глава 3. Планировани е испы т ан и й 81

1. Учет ограничений, накладываемых финансово й см ето й или графико м вы­

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

2. Аналогия с предыдущим и проектами. Если разрабатываем ы й программн ы й

продукт являетс я очередн о й версие й и з последовательност и итеративн ы х
верси й ил и имее т мног о общег о с некоторы м зав ершенн ы м программны х
продуктом, то в ряд е случаев можн о воспользоватьс я статистически м и дан­
ны м ране е разработанног о проекта . П р и это м важно , чтоб ы был и известн ы
фа кт и че ск и е издержк и н а разработк у старог о проект а , а услов и я разработ к и
старог о проект а должн ы максимальн о соотв етств ов а т ь условиям разработ к и
новог о проекта . На п р и м е р , над обоим и проектам и должн о работат ь одн о и т о
ж е числ о исполнител е й либ о исполнител и должн ы обладат ь одно й и то й ж е
кв ал и фи кац ие й .
3. Экспертная оценка. Количест в о исполнителе й ил и сроки , необходимы е для
выполнени я требуемы х задач, подсчитываю т оди н ил и больше е числ о экспер­
тов . Это т метод може т выглядет ь очен ь просто , когда эк сп е р т записывае т
свою оценку н а листи к е бумаги, ил и ж е очен ь сложно , когда требуетс я консен­
сус всех принимающ и х в не м участие (примеро м може т послужит ь технологи я
Wideban d Delphi) . Кр ат ко е описа ни е технологи и Wi deba n d Delph i приводит­
ся во врезк е 3.3.
82 Часть I. Процесс быстрого тестирования

4. Методы декомпозиции. Если программный продукт достаточно крупный и

сложный, по всей вероятности, получение оценок трудозатрат на разработку
и тестирования этого продукта, потребует больших затрат времени и усилий.
Вполне вероятно также, что в данной ситуации будет назначен руководитель
проекта, ответственный за соблюдение финансовой сметы и графика выпол­
нения работ всего проекта, а от группы тестирования потребуется предостав­
лять руководителю проекта исходные данные в специальном формате. Руко­
водитель проекта может поручить каждой группе специалистов дать собст­
венную оценку затрат с применением одной из описанных выше технологий.
С другой стороны, руководитель может воспользоваться более унифициро­
ванным подходом, в рамках которого программный продукт разбивается на
блоки либо по количеству строк кода, либо по функциональным баллам, а затем
к блокам применяется некоторый оценочный алгоритм. Если используется
именно такой подход, то группе тестирования целесообразно получить собст­
венную независимую оценку, скажем, экспертную, и убедиться в том, что при­
менение алгоритмического подхода имеет смысл.
5. Модели эмпирического оценивания. Существует множество моделей оцени­
вания, которые могут использоваться для вычисления затрат на разработку
проекта по созданию программного продукта. В основу этих моделей положе­
но количество строк программного кода (LOC — number of lines) или функ­
циональные баллы (FP— functional points), причем для одних и тех же исход­
ных данных эти модели дают разные результаты. Ключевым условием внедре­
ния любой из моделей является калибровка модели относительно локальных
условий за счет ее применения на завершенных проектах и настройка ее на
фактические данные так, чтобы она выдавала предсказуемые результаты. В
главе 12 можно найти подробную информацию о широко распространенной
технологии оценивания СОСОМО.

ПОДГОТОВКА ОЦЕНКИ ЗАТРАТ НА ТЕСТИРОВАНИЕ

Действия, которые рекомендуется выполнять при проведении оценочных работ, пере­
числены ниже. Рассматриваемая процедура, представляющая собой версию процесса
Wideband Delphi Estimation Process, должна осуществляться на раннем этапе процесса
планирования. Это будет гарантировать, что вас окажется достаточно времени на выпол­
нение каждого действия.
Подготовка. Подготовьте формуляры для входных данных, предназначенные для сбора и
документирования оценок. Подготовьте краткий пояснительный материал, объясняющий
исполнителям, как проводить соответствующие работы и что от них ожидать.
Вступительное совещание. Созовите вступительное совещание для консультаций по про-
цессу оценивания и распределите новые обязанности между членами рабочих групп,
чтобы они смогли разобраться с этими обязанностями и при необходимости объяснять
их во время рабочих совещаний. Покидая это совещание, члены групп исполнителей
должны иметь в своем распоряжении списки элементов, подлежащих оценке, и пони­
мать, как оценка выполняется. Хорошо подумайте, прежде чем пропускать это дейст­
вие — оно ставит исполнителей в равные условия и препятствует возникновению ошибок
из-за нечеткого понимания самого процесса либо оцениваемых элементов.
Надомная работа. Исполнители делают индивидуальные оценки. Предоставьте участни­
кам время, достаточное для ознакомления с новыми функциями очередной версии про-
граммного продукта.
 Глава 3. Планир овани е испытани й 83

. . . . . . . .

В то же время , крайне нежелательно, чтобы кто-то из исполнителей размышлял дольше

других и не мо г обмениваться данными с другим и . Убедитесь в т о м , что члены исполни-
тельных груп п понимают, что оценивают количество часов (или дней), необходимых для
решения той или иной задачи при условии, что ресурс ы для решения этой задачи у ж е
имеются. К р о м е т о го , убедитесь, что исполнители знают, как пользоваться единицами
измерения (человеко-часы, человеко-дни).
Рабочее совещание. Созовите рабочее совещание для проверк и и пересмотра оценок .
Председатель совещания производит сбо р оцено к и заносит их в специальный сводный
формуляр оценок . Сводные оценки возвращаются группе исполнителей для обсуждения
и пересмотра . Группа проводит обсуждени е оценок , приче м кажды й член тр уп п ы м о ­
же т иметь на этот счет собственное мнение, после чег о пересмотренная оценка воз ­
вращается председателю совещания. Процесс м о ж е т продолжаться до тех по р , пока
никто из участников не захочет менять свои оценки , либо оценк и окажутс я в пределах
разумног о компром ис са , либо время, отпущенное на рабочее совещание, истечет. Со-
вещание таког о р о д а не м ож е т длиться дольше двух ч а с о в — если он о длится дольше,
то ег о результаты окажутс я размытыми . Во время рабочег о совещания могу т возникать
новые проблемы , которы е нельзя решить в ходе совещания. Назначьте ответственных за
их решение.
Решение проблем. Если после рабочего совещания остаются нерешенные проблемы ,
примите м е р ы по их решению либо созовите ещ е одно рабочее совещание, либо, если
они затрагивают интересы не очень многих исполнителей, обсудите нову ю информацию
с подгруппами , ко тор ы е осведомлены в соответствующих вопросах. Скорректируйт е
оценки на баз е новой информации.
Получение общей оценки. Изучите сводный формул я р оцено к и отыщите для ка ждо й
задачи минимальную и максимальную оценки затрат. Возм ожн о , на основе собственно
го опыта или статистических данных по друг и м проекта м удастся отбросить р е з к о отли­
чающиеся значения ка к нереалистичные. Сложите максимальные и минимальные оценки
для получения оценк и трудозатрат в масштабах всего проекта . В этом случае получают-
ся два результата: оптимистическая, или "агрессивная", оценка (минимальное значение)
и пессимистическая, или "умеренная" , оценка трудозатрат (максимальное значение).
Задокументируйте все предложения, которы е были сделаны в процессе получения
окончательной оценки .
Преобразование оценки в график работ. Теперь, когда имеется оценка требуемых тру-
дозатрат, настала очередь ответа на вопрос, на которы й вы обязаны ответить. Когда бу -
дет закончена работа? Одно из эмпирических правил ( [ 3 3 ] , с.! 83 ) выглядит так:
Продолжительность графина работ в месяцах = 3,0 * человеко-часы 1/3

Разумеется, имеет смысл получить более точные срок и , нежел и те , что вычисляются по
этой незамысловатой формуле .
Врезка 3.3.

Определение продолжительности задачи

и построение графика работ
После того , как задач и определ ен ы , а трудозатрат ы на каждую задачу подсчитаны ,
потребуется о п р е д е л и т ь врем я решени я кажд о й задач и и исследова т ь первы й р а з р е з
график а работ . Время , необходим о е для в ып олн ен и я задачи , называемо е такж е про­
должительность ю , зависи т о т количест в а исполнител е й , могущих трудиться над ней .
Если ест ь возможност ь привлеч ь к вып олн ен и ю то й ил и и н о й задач и боле е одног о
исполнителя , убедитес ь сначала, чт о эт а задач а допускае т разб ие н и е н а подзадач и —
другими словами , выполнени е м эт о й задач и могут одн ов ре м ен н о заниматьс я боле е
одного исполн ител я . Н е к от ор ы е работ ы , подобны е ж а р к е бифштекса , н е будут вы-
84 Част ь I . П ро ц е с с быстрог о тестировани я

полне н ы бы ст р е е , есл и к ни м вмест о одног о привле ка ют с я нескольк о человек . Боле е

подробн ы й анали з этог о вопрос а можн о найт и в о врезк е 3.2.
Посл е назначени я на каждую задачу конкретны х исполнителе й следовало бы выяс­
нить, какие задачи могут выполняться одновременно , а какие — только в определенн о й
последовательности. Одни м из факторов , которы е должн ы исследоваться пр и составле­
ни и плана выполнени я задач, является использование одного и того же оборудования. В
вашем распоряжени и может оказаться достаточн о исполнителей , готовых выполнять
работ ы одновременно , но вы должн ы также принят ь во внимание, насколько доступным
будет оборудование. П р и наличи и достаточного количества едини ц совместно исполь­
зуемого оборудования, возможно , придется построит ь графи к использования этог о обо­
рудования ил и базу данны х обслуживания, котора я будет контролироват ь работу испол­
нителей, степен ь использовани я оборудования и время тестирования . Вопрос создания
баз данны х обслуживания подробн о рассматривается в [33].
Задачи , выд ел ен н ы е ресурсы (врем я и оборудовани е ) и продолжительност ь вы­
полн ен и я можн о гра фиче с к и отоб рази т ь н а гистограмме , при ме р к оторо й показа н н а
рис . 3.6. Така я гистограмм а може т использовать с я дл я ото бр а ж ен и я ключевы х этапо в
проекта , связанны х с о "зна ме на те л ьн ым и " соб ытия м и в жиз н и проекта , ка к то : нача­
л о тести рован и я , к о н е ц т е с т и р о в а н и я ил и дат а поставк и програм мно г о продукта. Н а
рис . 3.6 эт и этап ы помече н ы значко м +. На диаграмме , представ ленн о й на ри с 3.6,
привод ят с я т о ль к о назван и я зада ч и связанны е с н и м и даты . Н а боле е п од р об н о й
гистограм м е могут бы т ь показан ы ресурсы, в ыд е ле н н ы е для задачи , тексты , указы­
вающ и е начальны е и к он е чн ы е даты , а та кж е другая и н форм а ц и я , имеющ а я отноше ­
ни е к управлен и ю вы п ол н е ни е м проекта .
 Глава 3 . Планировани е испытан и й 85

Ч ас т о знаменательн ы е дат ы проект а сводятс я в отдельну ю таблицу, ко то р а я полу­

чила название поэтапног о графика . Примеро м поэтапног о графика , которы й может ис­
пользоваться руководством и персоналом, проводящим испытания , служит таблица 3.4.

Оценка рисков, связанных с графиком работ

Как тольк о будет получен а оце н к а количест в а исполн ителе й , оборудовани я и време­
ни, необходимог о для те с ти р о в а н и я програм мног о продукта, потребуетс я оценит ь
риски , связанны е с этим и оценк ами . Эт о делаетс я исходя и з предположени я , чт о мо­
жет вый т и и з стро я в о врем я пр ов ед е н и я испыта ни й . Дале е неслож н о составит ь пла н
устранени я возникающи х проблем . Объе м трудозатрат , необходимы х для смягчени я
последствий от овеще ствле нн ы х рисков , даст представлен и е о том , насколь к о полу­
ченны е оц ен к и могут отклонятьс я о т фактичес ки х з н а ч е н и й за т ра т време н и и
средств. Риски , встроенн ы е в полученн ы е оце н ки , — эт о пер во е , о че м следует доло­
жит ь вышестоящем у руководству в процесс е пересм от р а оценок .
Н и ж е приводятс я п р и м е р ы рисков , которы е оказываю т слия ни е н а графи к рабо т
по тестировани ю :
• Аппаратны е средства, необходимы е для проведени я тестиро вани я , отсутству­
ю т н а начально й стади и испытан и й
• Тестир уемы й програ мм н ы й продукт не поступил на исп ыт ан и я
• Тестовы е случаи не готов ы к началу испытани й
• Исполнители , которы м поручен о проведени е испытани й , н е могут приступит ь
к тестирован и ю
• Внесени е измен ен и й в требовани я в процесс е разработк и тест о в ил и во врем я
испытани й
• Изменени е пользовательски х и н т е р ф е й с о в в процесс е разработк и тесто в или
в о врем я испытан и й
• Освоени е персонало м новы х средст в тестиро ван и я не завер шен о к началу ис­
пытани й
Анали з риско в част о влече т з а собо й разработ к у план а смягчени я последстви й о т
овеществлен и я риско в . Н а п ри м е р , есл и в ы убеждаетесь в том , чт о те сто вы е случаи н е
86 Част ь I . Про ц ес с быстрог о тестировани я

готов ы к о в ре м ен и п р о в е д е н и я испытании , появл я ют с я все основани я предложит ь

привле ч ь к испытани я м д о по лн ит ел ьн ы е трудовые ресурсы . Если работ ы по тестиро-
вани ю завися т о т поставк и новог о оборудования , необходимог о для реализаци и про-
екта, то , за л о жи в эту зависимост ь в графи к рабо т и дава я оценку связанны х с ней
рисков , в ы ста ви т е в из в е стн о ст ь руководство прое к т а о том , чт о сроко м поставки
новог о оборудовани я д ол ж н о быт ь начал о испытани й , а н е дат а ег о отгрузки.
Обы чн а я пр акт ик а управлени я пр и допущени и риск а предусматрива е т связ ь каж-
дого риск а с в е р о я т н о с т ь ю осуществлени я этог о риск а и ме р ы воздействи я на проект,
есл и рис к все ж е случится . Н а п ри м е р , возможно , вск р оет с я т о т фа кт , что , скор е е все-
г о ( с в е р оя тн ос т ь ю 9 0 % ) , основны е специалист ы п о те м ил и и н ы м п ричина м н е смо­
гут приступ ит ь к т е с т и р о в а н и ю в зап лани ров анн ы е с роки , поэтом у возможн ос т ь на­
рушен и я гра фи к а р аб о т оц ен ив а ет с я как критическа я (по шкал е критическая , высо­
кая, средняя , малая) . Риск , к оторы й оказывае т больш о е вл иян и е н а вы пол нени е про­
ект а и характеризуетс я высоко й веро ятност ь ю осуществлени я , относит с я к катего­
р и и те х рисков , в случае воз ни кн ове н и я которы х у вас долже н быт ь пла н дополни­
тельн ы х м е роп ри ят и й . В подобно й ситуации, возможно , потребуетс я обсудить воз­
можн ост ь внесени я и з м е н е н и й в пла н рабо т ил и изменит ь очере дно с т ь подключени я
специалист о в р а з л и ч н ог о п ро фи л я , участие которы х необходи м о для проведени я
испытани й .
П р е д п о л а г а е м ы й п е р е ч е н ь действи й дл я оц е н к и ри с к о в выгляди т следующим об­
разом :
• Соста ви т ь списо к все х рисков , какие , по вашему мн е ни ю , представляю т угрозу
в ып олн е н и ю г ра фи к а р аб о т п о т е сти р о ва ни ю . П р о в е д и т е анали з статистиче­
ски х данных , та ки х ка к оц е н к и вы полн ен и я прое кт о в ил и и н ф ор м а ц и я о не­
обычны х случаях сбоев , имевших мест о п р и вы п ол не н и и предыдущих проек­
тов . Получи т е оценк у зависимост и о т других групп, обсудив с ним и вероят­
ност ь того , чт о о н и выполнят ь пр ед л о же нн ы е вам и к ри т е р и и вхождени я в ис­
пытания .
• Дат ь оценку веро ятнос т и осуществления каждого выявленног о риска .
• Да т ь оценку последстви й осуществления рис к а в о тн о ш е н и и выполнимост и
план а исп ыт ани й . Дл я оп иса ни я этог о влияни я воспользуйтес ь шкалой крити­
ческое , высо кое , среднее , малое.
• Разработат ь пла н сни ж ени я вероятност и осуществлени я риско в или их влия­
ни я , на чи н а я с т е х и з них , которы е обладаю т высок о й вероятност ь ю осуществ­
л е н и я ил и ч р ев а т ы тяжелым и последствиями .
Существует мног о литерату р ы п о вопроса м управлени я п р и допущени и риска . Для
поп о лн ен и я свои ъ зн а н и й рекомендуе м обратитьс я к [43] , [42] и [30] , которы е со­
дер жа т краткую, н о в т о ж е врем я весьма полезную и н ф о р м а ц и ю .
 Глава 3. Планирование испытаний 87

Подготовка и пересмотр документов,

содержащих планы проведения испытаний
Формат плана проведения испытаний
После выбора стратегии тестирования, определения испытательной системы и
оценки трудозатрат можно приступать к составлению плана проведения испытаний.
План проведения испытаний представляет собой документ или некоторый набор до­
кументов, представляющих собой результат выполнения определенных видов дея­
тельности по планированию испытаний. Этот документ не является раз и навсегда
установленным планом, он меняется по мере изменения требований. Полезные ре­
комендации по разработке плана проведения испытаний предлагает стандарт IEEE
Standard 829: IEEE Standard for Software Test Documentations [22] (стандарт IEEE по со­
ставлению документированию испытаний программного обеспечения). Конечно,
можно воспользоваться другим форматом, однако потребуется оформить все мате­
риалы, рекомендуемые указанным выше стандартом IEEE в любом подходящем фор­
мате. Другие идеи и форматы рассматриваются в [15], а также в [30], [40] и [33]. В
данном разделе при построении шаблона плана проведения испытаний будет исполь­
зоваться стандарт IEEE Standard 829.
Согласно рассматриваемому стандарту, план проведения испытаний должен со­
держать 16 разделов:
1. Идентификатор плана проведения испытаний
2. Введение
3. Компоненты, которые должны тестироваться
4. Характеристики и свойства, которые должны тестироваться
5. Характеристики и свойства, которые не должны тестироваться
6. Подход
7. Критерий успешных и неудачных испытаний
8. Критерий приостановки испытаний и требования возобновления испытаний
9. Выходные результаты тестов
10. Задачи тестирования
11. Требования окружающей среды
12. Распределение ответственности
13. Подбор кадров и подготовка персонала
14. График работ
15. Риски и непредвиденные обстоятельства
16. Утверждение плана проведения испытаний.
Если внимательно проанализировать этот список, несложно понять, чем этот
план не является — он не представляет собой подробное описание того, как должен
выполняться прогон тестов, и не является местом сосредоточения результатов тес-
88 Част ь I . П роцес с быстрог о тестировани я

тирова ни я . Н е к о т о р ы е организаци и , специализир у ющие с я н а т е ст и р о в а н и и про­

граммн ы х продуктов , объе диняю т оди н ил и больш е е числ о пунктов списк а с содер­
жимы м план а п ро в ед ен и я испытаний , те м самы м организу я всю тестову ю документа­
цию в одно м месте . Эт о може т дат ь п рек ра сн ы е результаты , однак о в данно й книг е
м ы преследуе м цел ь д ос ти ж ен и я больше й модульности комплект а документов , кото­
рая совпадае т с цель ю упомянутого выш е стандарт а .
То т фа кт , чт о указанны й стандар т направле н н а разделени е плано в проведени я
испытаний , процеду р и результатов, становит с я очев идн ы м из содержащихс я в нем
оп р ед е ле н и й следующих документо в [22] .
План проведени я испытаний. Эт о докумен т описывае т возможности , подход, ре­
сурсы и г ра ф и к исполне н и я различны х видо в тестово й деятельност и . О н опреде­
ляе т об ъект ы тест ирова ни я , функции , кот ор ы е должн ы тестироваться , тестовы е
задания , исполнителе й каждого тестовог о задания , и любо й и з рисков , требую­
щий п ла ни рова н и я н а случай непредвиденны х обстоятельств .
Спецификаци я методик и тестировани я . Это т документ описывае т последова­
тельност ь действи й пр и вы полнен и и к онк рет ног о теста .
Отчетн ы й докла д о тестировании . Это т докумен т обобщае т виды тестово й дея­
тельно ст и и и х результаты . О н такж е с оде ржи т оценку соответствующи х тестовы х
объектов .
С п е ц и ф и к а ц и я методик и т е ст и р о в а н и я изучаетс я в главе 4 как част ь работ , вы­
полняемы х пр и р а з р а б о т к е тестов , а о т ч е т н ы е доклады о те сти р о ва н и и рассматри ­
ваются в главе 5, в к оторо й реч ь иде т о в ып ол не н и и тестов . В идеально м случае все
эт и документ ы должн ы быт ь связан ы в эффе ктивн у ю , скоординированну ю систему,
котора я поддерживае т процес с т е ст и р о в а н и я о т начал а д о конца .
В данно м раздел е м ы проведе м анали з содер жимо г о плана проведен и я исп ытан и й
и опти м иза ц и ю ег о структуры для целе й быст рог о тестировани я . П о каждому пункту
этог о план а м ы по пы та е м с я найт и приемлемы й спосо б быст р о и э ф ф е к т и в н о удовле­
творит ь его требова ни я . Разумеется, н е к от ор ы е предложенн ы е решени я не будут со­
ответствова т ь вашим потребностям , н о тогда в ы должн ы будете выполнит ь тако й ж е
анализ в контекст е собственно й сред ы разработк и .
Кажды й пронумерованн ы й ниж е пункт соответствуе т пункту эскиз а плана, приве­
денног о в предыдущем разделе . П р и м е р ы план а проведени я испытаний , специфика ­
ции методик и тестирован и я и отчет а о тестиро ван и и приводятс я в тр етье й части
книги.

1. Идентификат о р плана проведени я испытаний. В долгосрочно й перспектив е

можно с э к о н о м и т ь время , если присвоит ь всем тес товы м документам идентификато ­
ры , кото ры е нетрудн о отслеживать . П о существу, возможност ь отслеживан и я доку­
ментов позволяе т получить следующие преимущества :
• Н а л и ч и е уникальног о ид ен тиф ик ат о р а каждог о тестовог о документа позволяе т
воспрепятствоват ь тому, чт о кто-либо и з исполнителе й напрасн о затрати т вре­
м я н а изучени е н е тог о документа, чт о надо . Та к и м идент и фи кат о р о м може т
быт ь ал ф ав итн о-ц и фр о ва я строка , котора я може т содержа т ь данные , отобра­
ж а ю щ и е назван и е продукта, номе р версии , дату и любую другую и н форм а ц и ю ,
позволяющ у ю отслеживат ь это т документ. Рекомендуетс я отдават ь предпочте -
 Глава 3. Планировани е испытани й 89

ни е идентификатора м , к отор ы е вписывают с я в общую систему управлен и я до­

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

2. Введение. Цел ь введен и я заключаетс я в том , чтоб ы дат ь краткую и н фо р м а ц и ю для

любого исполнителя , желающег о воспользоватьс я плано м п р о в е д е н и я и спыта ни й .
Суть состои т в необходимост и указани я во вводно м раздел е план а пр о в ед ен и я испы­
таний исходны х документов , служащих входным и данным и выполняемог о тести­
рования .
Напри мер , можн о состави т ь списо к документо в с требовани ям и и функциональ ­
ных с п е ц и фи к а ц и й для тестируемог о програм мног о продукта. П р и составлен и и это­
го списка желательн о указат ь расположен и я документо в (путь в сетево м дисково м
накопител е ил и URL-адрес Web-страницы ) , чт о даст воз мо ж н ос т ь быст р о получить к
ним доступ. Наиб оле е подходящи й спосо б заключаетс я в п омещ е ни и в пла н проведе­
ния испытани й ссылк и на исходны й документ, благодар я к от ор о й пользовател ь смо­
жет переходит ь и з недокументальн о й копи и план а н а соответствующи е справочны е
материалы. Преимущест в о таког о подхода связ ан о с в озм о жн о ст ь ю автоматическог о
выхода пользовател я на последню ю верси ю входного документа.
Другим аспектом , к от о р ы й совер шен н о не связа н с обеспе чени е м быстрог о поис­
ка входных документов, являетс я минимизац и я врем енн ы х за тра т на написани е вве­
дения. П р и м е р , сопровождающи й стандар т IEEE Stan dar d 829, с одер ж и т цел и плана
проведения испытаний , предварительны е данны е о программн о м продукте, объем
тестирования , предусмотренны й плано м проведени я исп ыт ани й , и перечен ь ссылок.
Размер таког о документа н е превышае т половин ы стр ани ц ы . Если пр и это м имеютс я
ограничения , оказывающи е влия ни е н а процес с п л а н и р о в а н и я , нап ри м ер , сро к вы­
хода продукта на р ы н о к , их можн о перечислит ь здесь же .

3 . Компоненты , которы е дол ж н ы тестироваться . Здес ь приводят с я высокоуровне­

вые списк и компонент , к о то р ы е вы намерен ы тестир оват ь . В это м раздел е будут упо­
мянуты некото ры е из них:
• Ид е нт и ф и к а т о р вып у ск а/в е рси и тестируемог о программног о проект а
• Исп ра в ле н и я дефектов , обнаруженны х в предыдущей версии . Если список де­
фек то в приводит с я в с п е ц и ф и к а ц и и функций , необходи м о указать ссылку н а
с п е ц и ф и к а ц и и функ ц и й и н е дублироват ь и х здес ь
90 Часть I. Процесс быстрого тестирования

• Описание среды, используемой для распределения программного продукта

(например, компакт-диски, Web- или ftp-сайты)
• Документы для конечного пользователя, такие как руководство пользователя,
инструкции по установке, примечания по версии продукта.

Обратите внимание на тот факт, что это перечень представляет собой ни что
иное, как входные данные для выполняемого тестирования. Все эти материалы
должны быть получены своевременно, чтобы не нарушать сроки тестирования, по­
этому в плане они помечаются как зависимости. Следует обладать полной ясностью
относительно того, что тестируется, дабы ничто не смогло ускользнуть из внимания.
Например, существует вредная привычка до последней минуты "забывать" проводить
тестирование документов для пользователя. Пытаясь исправить подобную забывчи­
вость в конце разработки проекта, легко допустить срыв графика работ и, что еще
хуже, поставить заказчику продукт с необнаруженными дефектами.

4. Характеристики и свойства, которые должны тестироваться. Стандарт IEEE

Standard 829 предлагает следующее определение свойства программного обеспечения
(software feature): это отличительная характеристика программного компонента, на­
пример, производительность, переносимость или функциональные возможности.
Это очень общее определение, поскольку оно должно охватить большое количе­
ство понятий. Возможно, имеет смысл давать определения' свойств в бизнес-
терминах. Рассмотрим свойство быть тем, "что может продаваться заказчику". На­
пример, если приложение работает медленнее, чем это нужно заказчику, то увеличе­
ние быстродействия его наиболее часто используемых функций может подаваться
как свойство. Более совершенный новый способ ввода ускорения ввода данных или
запроса в базу данных также может продать как свойство.
Ключевым моментом для специалистов по тестированию является то, что если
что-то было обещано заказчику, оно должно быть отражено в плане проведения ис­
пытаний с тем, чтобы протестировать его до поставки объекта заказчику. Основным
источником, позволяющим узнать, что было обещано заказчику, служат документы
определения требований, на которые существуют ссылки во введении.
Перечень свойств в этом разделе предоставляет в ваше распоряжение контроль­
ную таблицу для вычисления трудозатрат, необходимых для проведения испытаний
программного продукта. Каждая позиция этого списка соответствует конкретным
пунктам документов описания требований, в то же время каждой такой позиции дол­
жен соответствовать один или большее число тестов, определенных в спецификации
методики тестирования.

5. Характеристики и свойства, которые не должны тестироваться. Этот раздел

предназначен для того, чтобы заблаговременно и однозначно определить, какие объ­
екты не должны охватываться тестированием. В число объектов, объявляемых как
"не подлежащие тестированию", могут входить следующие:
• Функции, реализация которых отложена до последующих инкрементальных
версий продукта
 Глава 3. Планирование испытаний 91

• Конфигурации компьютерных средств, которые невозможно проверить по

причине отсутствия необходимого оборудования. Иногда используются на­
столько дорогостоящие конфигурации компьютерного оборудования, что их
невозможно продублировать в условиях испытательных лабораторий. Если вы не
можете воспроизвести операционную среду, но в то же время можете ее
смоделировать, об этом потребуется сообщить в разделе "Подход". Если вы во­
обще не можете проводить испытания в операционной среде, этот вопрос сле­
дует рассмотреть в разделе, в котором обсуждаются "риски".
• Комбинации настроек или конфигурации аппаратных средств, которые не мо­
гут быть испытаны за время, выделенное для выхода программного продукта на
рынок. Если принято решение ограничить объем тестирования некоторого
конкретного свойства, необходимо обсудить данные ограничения и обосновать
их в этом разделе.
На завершающих стадиях проекта, когда, как правило, на группу тестирования
оказывают давление в плане поторопиться с окончанием работ, очень полезно иметь
в своем распоряжении документ, в котором оговаривается, что планируется тестиро­
вать, а что нет. В пылу предфинишной лихорадки люди склонны забывать, какие со­
глашения были достигнуты — совсем неплохо опереться на этот раздел плана прове­
дения испытаний при ответах на вопросы, почему то или иное свойство не охвачено
тестированием. Разумеется, если проблема возникнет в области, которая не подвер­
галась тестированию в вашей лаборатории, она должна быть устранена и проверена
после выпуска очередной версии программного продукта. Поскольку стоимость ис­
правления дефектов после сдачи программного продукта в эксплуатации очень вели­
ка, важно получить по возможности точную оценку рисков, прежде чем принимать
решение не проводить испытаний того или иного свойства или конфигурации.

6. Подход. Этот раздел плана проведения испытаний предназначен для описания на

высоком уровне, как вы намерены проводить испытания программного продукта. Это
описание не является подробной спецификацией всех методик испытаний, которые
планируется использовать. Подход, описание которого включено в план проведения
испытаний, должен быть основано на соображениях, рассмотренных в одном из пре­
дыдущих разделов, а именно, в разделе "Определение подхода к тестированию". В
этот раздел можно включить, например, такие темы:
• Статическое тестирование требований и проектная документация
• Статическое и динамическое тестирование, которое должно проводиться на
стадиях тестирования программных кодов, модулей и проверки взаимодейст­
вия и функционирования компонентов системы
• Тестирование свойств
• Испытания при перегрузках/испытания под нагрузкой/тестирование произ­
водите льности
• Проверка средств защиты
• Тестирование установки/обновления программного продукта
• Тестирование средств дублирования/восстановления
• Тестирование GUI-интерфейса
92 Част ь I. Процесс быстрого тестирования

• Регрессивное тестирование
• Приемочные испытания: альфа-, бета- и другие виды испытаний на месте
• Проверка результатов устранения дефектов
• Прерывание испытаний, проводимых в автоматизированном и неавтоматизи­
рованном режимах
• Виды тестирования, проведение которых поручается сторонним организациям
• Использование системы отслеживания дефектов для ввода сообщений о неис­
правностях.
Если реализуется лишь некоторая часть той или иной долгосрочной стратегии,
например, автоматизация процесса тестирования и тестовых случаев, можно опреде­
лить, какие конкретные аспекты соответствующего долгосрочного плана будут реа­
лизованы в текущем проекте проведения испытаний, и сослаться на документ, в ко­
тором описывается стратегия автоматизации. Например, возможно, планируется
применение некоторого инструментального средства или впервые предпринимается
попытка автоматизации тестирования GUI-интерфейса. Кроме того, может планиро­
ваться использование услуг сторонних тестовых организаций для проведения испы­
таний продукта под нагрузкой и в условиях перегрузки. Этот раздел представляет со­
бой подходящее место для описания плана на концептуальном уровне и ссылок на
любые письменные соглашения, которые удалось заключить со сторонними органи­
зациями.
При выполнении тестирования инкрементальных версий программного продукта
подход к тестированию каждой версии, по всей видимости, будет одним и тем же. Вы
должны обладать возможностью экономить время за счет заимствования больших
фрагментов того же раздела плана проведения испытаний, составленного для преды­
дущих версий, но в то же время тщательно анализировать последствия любых изме­
нений, внесенных в текущую версию программного продукта.

7. Критерии успешного/неудачного прохождения испытаний. Два критерия ус­

пешного/неудачного прохождения испытаний заслуживают особого внимания при
тестировании. Первый относится к индивидуальным тестам. Все тестовые случаи
должны снабжаться наборами ожидаемых результатов; по существу, если получены
ожидаемые результаты, итог прогона теста считается успешным, если нет — результат
прогона теста расценивается как неудачный. Критерии успешного/неудачного про­
хождения отдельных тестов должны быть включены в сами тестовые случаи, в связи с
чем их не следует помещать в план проведения испытаний. Однако не лишним будет
указать в этом плане, что определение критериев успешного/неудачного прохожде­
ния испытаний является неотъемлемой частью тестового случая.
Второй тип критериев успешного/неудачного прохождения испытаний имеет
отношение к тестированию всего программного продукта. С самого начала вы долж­
ны определить, что следует считать успешным прохождением стадии тестирования,
т.е. когда можно прекратить испытания продукта и наладить его поставку. В некото­
рых случаях критерий выхода из испытаний определяется в программе испытаний
или даже в документе, который содержит формулировки требований, предъявляемых
к программному продукту. Вне зависимости от того, что служит источником этих кри­
териев, полезно дать их четкую формулировку в плане проведения испытаний.
 Глава 3 . Планировани е испытани й 93

Разумеется, нереальн о ожидать , чт о любы е к ри т е ри и , объявленн ы е в план е проведе­

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

8. Критери й приостановк и испытани й и требован и я возобновлен и я испытаний.

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

9 . Выходные результат ы тестов . Это т разде л план а проведени я ис п ыт а н и й являетс я

тем местом, в кот ор о м оп р едел я ют с я выходны е д а н ны е рабо т по т е ст и р о в а н и ю , на­
пример, можн о предло жи т ь следующий список :
• Пла н п р ов е де н и я испыт ани й
• Документы , регламентирующи е п рое к т и ров а н и е тест о в
• Документ , с оде ржа щ и й с п е ц и фи к а ц и ю тест о в
• Сообщени я о результата х прогон а тесто в
• Сообщени я об обнаруженны х дефекта х
• Пр и м е ча н и я по выпуску программног о продукт а (есл и эт о вменяетс я вам в обя­
занн о сти ) .
Всегда полез н о напомнит ь ответственны м исполнител я м ко нк р етн ы х документ о в
предельные ср ок и о ф о р м л е н и я документа. Чт об ы исключит ь напрасную трат у вре­
мени на боле е поздни х стадиях, можн о подготовит ь шаблоны , ил и "козы" , эти х доку­
ментов на этап е составлени я план а проведен и я исп ыт ани й , а зате м установит ь связ и
или ссылки на " ф и к т и в н ы е " документы. На п р и м е р , може т оказатьс я полезн ы м зара­
нее подготовит ь шабло н отчет а по результатам тестир ован и я и заполнят ь ег о тесто­
выми данным и по мер е их готовности . Кро м е того , шабло н проект а тест а може т ус­
корить р а б о т ы п о пр ое кт и р ов ан и ю тестов . Удивительно , как мног о врем ен и можн о
понапрасну тер я т ь , спор я о ф о рм ат е и содержани и любог о из перечисленн ы х выш е
документов.
Определен и е и согласовани е того , чт о в ы намереваетес ь опубликовать п о завер­
шении тестиро ван и я н а ранне м этап е ж и з н е нн о г о цикла , може т стат ь хор ош е й прак­
тикой, поскольку в это м случае упрощаетс я п о ст р ое н и е реалистичног о план а работ .
Дабы не закладыват ь в пла н рабо т неоправданн ы х накладны х расходов , нежелатель -
94 Часть I. Процесс быстрого тестирования

но отображать в плане результаты работ, которые не существенны для достижения

конечной цели, каковой в рассматриваемом случае является максимально быстрая
поставка программного продукта.

10. Задачи тестирования. Если план проведения испытаний применяется для обос­
нования произведенной оценки трудозатрат на тестирование, этот раздел является
подходящим местом для определения индивидуальных задач, которые необходимы
для подготовки и выполнения тестирования. Еще лучше, если вы занесете вашу оцен­
ку в динамическую электронную таблицу. Другой способ предполагает использование
программы управления проектами, например, Microsoft Project, для того, чтобы в
этом разделе плана организовать ссылку на другой документ. Это еще один подходя­
щий момент, чтобы указать ссылку на справочный документ или, по крайней мере,
путь к соответствующему файлу или сетевому дисковому накопителю.

11. Информация о конфигурации средств тестирования (требования окружаю­

щей среды). Дайте описание аппаратных и программных средств, необходимых для
проведения испытаний, и начертите диаграммы, показывающие, как аппаратные
компоненты соединяются друг с другом. Этот раздел предназначен для того, чтобы
позволить любому другому заинтересованному лицу построить такую же испытатель­
ную установку в случае необходимости воспроизведения неисправности или провер­
ки, что неисправность устранена. Данный раздел плана проведения испытаний дол­
жен составляться на базе анализа, проведенного в разделах "Среда тестирования" и
"Конфигурации средств тестирования" ранее в этой главе. Возможно, потребуется
расширить рамки этого раздела и включить в него архитектуру тестов (т.е. как орга­
низованы тесты) и инструментальные средства тестирования, которые вы намерены
использовать. Обе темы затрагиваются в разделе "Определение испытательной сис­
темы" в начале главы.

12. Распределение ответственности при проведении тестирования. Если возмож­

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

Если ни одна из упомянутых ситуаций не имеет места, в этом разделе можно по­
местить стандартную фразу, дескать, организация XYZ, специализирующаяся на тес­
тировании, будет проводить испытания программного продукта и сообщать об обна­
руженных дефектах разработчикам. В этом разделе не указываются служебные обя­
занности конкретных инженеров и техников; для этой цели предназначен следующий
раздел плана проведения испытаний.

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

14. График работ. Этот раздел обычно не является местом, в котором оглашается
подробный график проектных работ — для таких целей существует общий план про­
ектных работ или самостоятельный файл, который может подвергаться изменениям
независимо от плана проведения испытаний. В конце концов, подробный план работ
может быть очень динамичным документом, однако содержимое того, что вы тести­
руете, кадровые проблемы, рабочие продукты тестирования и другие компоненты
плана проведения испытаний остаются достаточно статичными.
Скорее всего, в план проведения испытаний потребуется включить краткий спи­
сок ключевых этапов тестирования, например, срок начала тестовых работ, когда
бета-версия продукта должна поступить к первым пользователям и когда завершатся
испытания. С другой стороны, можно просто принять решение обращаться к планам
проектных работ или самостоятельному плану работ, используя для этих целей ссыл­
ку на Web-странице или путь к сетевому дисковому накопителю.

15. Риски и непредвиденные обстоятельства. Риски могут описываться в таблице, в

которой указываются риски, вероятность овеществления этого риска, влияние этого
риска и план мероприятий по снижению от овеществления рисков. Процесс по­
строения такой таблицы описан в разделе "Оценка рисков невыполнения графика
работ".

16. Утверждение плана проведения испытаний. Для решения этой задачи на ти­
тульном листе плана проведения тестовых работ потребуется составить список лиц,
утверждающих план, и получить их одобрение. Можно также отправить утверждаю­
щему лицу по электронной почте копию плана проведения испытаний и получить
ответ с утвержденным планом. Хранить сообщения и ответы электронной почты ре­
комендуется в совместно используемом сетевом каталоге, который дублируется через
регулярные промежутки времени, либо присоединить все ответы и подтверждения к
специальному приложению к плану проведения испытаний.
96 Часть I. Процесс быстрого тестирования

Проверка выполнения плана проведения испытаний

План проведения испытаний — это важный рабочий продукт жизненного цикла раз­
работки, в силу чего он должен быть подвергнут тщательной проверке. По возможно­
сти он должен пройти формальную проверку (см. раздел "Методы статического тес­
тирования" в главе 2 и раздел "Проверки/сквозной контроль/экспертные оценки" в
главе 9, где содержится более подробная информация о проверках). В проверках
должны участвовать не только члены группы тестирования, но и представители кол­
лективов разработчиков, групп маркетинга и руководства (по меньшей мере, через
электронную почту). Проверки преследуют сразу несколько целей:
• Все исполнители, принимающие участие в разработке программного продукта,
должны понимать и одобрять цели, покрытия, ограничения и риски, связан­
ные с проведением тестирования.
• Подход к тестированию должен быть пересмотрен с целью обеспечения его
технической корректности и обеспечения проверки им всех требований, вы­
полнение которых было обещано заказчику.
• Критерии входа и выхода из испытаний должны правильно пониматься всеми
исполнителями, принимающими участие в проекте. Любые зависимости от
деятельности других групп должны быть четко зафиксированы, а группы, от­
ветственные за те или иные этапы разработки, в установленные сроки должны
предоставлять группе тестирования соответствующие рабочие продукты.
Несмотря на то что обмен информацией между группой тестирования и другими
группами должен поддерживаться в течение всего процесса разработки программно­
го продукта, периодические проверки хода выполнения плана проведения испыта­
ний представляют собой прекрасную возможность обеспечить согласованное выпол­
нение проектных работ на ранних стадиях жизненного цикла. Любые недоразумения
и ошибки при выборе тестового покрытия, которые останутся незамеченными при
проверке хода выполнения плана проведения испытаний, могут серьезно помешать
проведению испытаний в запланированные сроки.

Что дальше
В этой главе мы обсудили планирование работ по тестированию и получение оценок.
Затраты времени и усилий на планирования могут серьезно повлиять на способность
вашей группы успешно реализовать план тестирования и достичь его целей. Ключе­
выми этапами процесса составления плана тестирования являются:
• Определение стратегии тестирования
• Определение состава и структуры испытательной системы (аппаратные и про­
граммные средства)
• Оценка трудозатрат на проведение тестирования (необходимые ресурсы и
график работ)
• Оценка рисков и выполнения графика работ и подготовка планов смягчения
последствий от овеществления рисков
• Подготовка и проверка документов плана проведения испытаний.
 Глава 3. Планировани е испытан и й 97

Выходные результат ы эти х этапо в представляю т собо й набо р документов , опре­

деляющих пла н провед ен и я и спытани й , кот оры й используютс я пр и управлен и и
дальнейшими испытани ям и .
В следующей главе мы познакомимся , с че м придет с я столкнуться во врем я разра­
ботки тестов . Стратег и я тестирова ни я , архитектур а тест о в и конфигураци и средст в
тестирования, оп р ед е ле н и я которы х был и дан ы н а стади и планировани я , играю т
важную рол ь пр и разр а бо т к е набор а э ф ф е к т и в н ы х тестовы х случаев.
 Проектирование
и разработка тестов
Темы, рассматриваемые в главе:
• Разработка тестов
• Р а з р а б о т к а т е с т о в ы х случае в
• П ерес мо т р и отладка т естов
• Автоматизац ия т е с т о в ы х случае в
• Что дальш е

Клю ч к успешны м испытания м л е жи т в э ффе к т и в н ос т и выбранны х тестовы х случаев.

Ка к был о показан о в главе 3, чет к о е план ирован и е и подготовк а т е с ти р о в а н и я игра­
ют большую роль , но в условиях проведен и я окон чате льно г о анализ а в ы б ра н н ы е слу­
ча и т е с т и р о в а н и я должн ы обеспе чи т ь обнаружен и е д е ф е к т о в в программно м про­
дукте, инач е все плани ров ан и е и подготовк а окажутся напрасным и . Цел ь данно й гла­
вы заключаетс я в том , чтоб ы подготовит ь базу для пр ое кти р о ва н и я и разработ к и на­
дежны х динамически х тес товы х случаев, которы е могут использоватьс я дл я систем­
ны х и приемочн ы х испытани й .
Диаграмм а действий , обеспечивающи х про ект и ро в ан и е и разработк у тестов , по­
казан а н а рис . 4.1 . Осн о вн ы м и входным и данным и для этог о процесс а являет с я набор
документов , составляющи х план проведен и я испытаний , которы е был и опис а н ы в
главе 3 . Пл а н проведени я исп ыт ани й долже н дат ь описани е подхода, к от о р ы й преду­
сматриваетс я задействова т ь пр и проведени и тестировани я , а такж е объ ем ы трудоза­
тра т на тестировани е . В нем должн а быт ь определен а архитектур а тес тов , т.е., по
меньше й мере , должн ы быт ь определен ы соответствующ и е набор ы тестов . В нем
такж е долже н быт ь опр еделе н набо р конфигураци й средст в тестирова ни я , вокруг
кот оры х проектируютс я тесты .
Выходным и результатам и таки х видов деятельности , как п р о е к т и р о в а н и е и раз­
работка , являютс я набо р перес мотре нн ы х и отлаженны х тестов ы х случаев, которы е
готов ы дл я использован и я в системны х и приемо чн ы х испытаниях . До лж н о быть
обеспечен о обратно е отображен и е тестовы х случаев н а технически е требования .
К р о м е того , тестов ы е случаи должн ы обеспечит ь х ор о ш е е п о к р ы т и е тестами , п о
меньше й мере , всех технически х требовани й с наивысшим и п ри о р ите та м и , а в иде­
альн о м случае — абсо лют н о все х тр е б о в а н и й заказчика . Т е ст о вы е случаи должн ы
 Глава 4. Проектировани е и разработк а тесто в 99

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

Как показан о на рис . 4.1 , с разработко й тестовы х случаев связа н собственны й

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

Разработка тестов
Как отмечалос ь в главе 3, подготовк а к тестиро ван и ю подобн а разделен и ю луковицы
на чешуйки — эт о многоуровневы й процес с последовательно й к о н к р е тиз а ц и и усло­
вий. Подготовк а начинаетс я с концептуальног о определен и я с тр а тег и и тестирова­
ния, зате м к нему добавляютс я все больше е количеств о слое в детализаци и , которы е
описывают архитектуру те с ти р о в а н и я и условия испытаний . В конечн о м итог е будут
100 Част ь I . Про цес с быстрог о тестировани я

р а з р а б о т а н ы п ров е ре нн ы е и отла ж ен н ы е методи к и тестировани я , собран а испыта­

тельна я систем а , посл е чег о можн о смел о приступат ь к системны м испытания м .
Разработк у тестовы х случаев можн о сравнит ь с о снятие м одног о сло я луковицы.
П рое к т ы тест о в содержа т в себе больш е п о др о бн о ст е й , нежел и концептуальн ы й план
пост роен и я тестов , н о в т о ж е врем я он и ещ е н е предусматриваю т конк ретны х дейст­
вий , необходимы х для прогон а к онк ретног о теста . Многоуровнев ы й подход к разра­
ботк е тест о в подобе н подходу, используемому п р и р а зр аб от к е програ ммног о обеспе­
чения . В рамка х высок отехнол огичн о г о процесс а ра зр а бо т чи к и н е переход я т о т
формулирован и я т р е б о в а н и й н еп о ср е дст в ен н о к написан и ю программны х кодов.
Сначал а он и выполняю т п ре д ва р ите л ьн ы й ил и системны й проект , в которо м опре­
деляю т к он ц е п ц и ю программно г о продукта, посл е чег о составляю т програм м у или
р а б о ч и й план , в которо м огов ари ва ют с я все детал и прое ктировани я . В област и тес­
тирован и я пла н пр о ве д ен и я испытани й играе т такую ж е роль , чт о и п рое кт н о е зада­
ни е в област и р аз р а б о т к и програм мног о обеспечения , а проек т тест а соответствует
рабочем у проект у програ м мно г о обеспечени я .
Одни м и з п риз н а к о в высоког о качеств а те хни че ско г о прое ктиров ан и я являетс я
ег о модульность. В условиях модульного п рое кт и ров ан и я систем а разбиваетс я на от­
дельны е к ом п он ент ы , пр и это м кажды й комп оне н т имее т сво е назначени е и четко
о п р е д е л е н н ы е входы и выходы . П р и н ц и п ы модульного проектирован и я част о при­
меня ют с я п р и проекти ров ан и и прогр аммно г о обеспечени я ; он и та к ж е хор ош о под­
ходя т и для проекти рова н и я тестов . Модульным компонент о м в т е с т и р о в а н и и явля­
етс я тестовы й случай. Эт о означает , чт о пер е д каждым тестовы м случаем должн а
быт ь постав лен а четк о сформулированна я цель , чтоб ы бы л о ясно , чт о подвергаетс я
т е ст и р о в а н и ю . Дл я каждого тестовог о случая должн а быт ь строг о определ ен а среда
т е ст и р о в а н и я с известны м и начальным и условиям и , благодар я чему можн о рассчи­
тыват ь н а то , чт о п р и каждом прогон е к онк рет н ы й тес т будет выдават ь одн и и т е ж е
результаты . Наконец , кажды й тестовы й случай долже н давать строг о оп р ед ел е нн ы й
ожид аем ы й результа т (выход) с тем , чтоб ы можн о был о воспользоватьс я однознач­
ны м критерие м успешного/неудачног о исп ыт ани я .
Другим свойство м модульного п р о е к т и р о в а н и я являетс я то , чт о модули организу­
ются в иер ар хи ю . Ие ра р х и я ест ь результат раз би ен и я систем ы на комп онент ы , и она
позволяе т в каждый к он к р ет н ы й момен т времен и работат ь с одни м уровнем системы .
Эт о обстоя тельств о отражаетс я н а архитектур е тестов , котора я може т включ ат ь в
себя нескольк о тестов ы х наборов , о р и е нт и р о в а н н ы х н а проверк у высокоуровневы х
функцион альн ы х свойст в системы , а такж е тес тов ы е набор ы ил и тест овы х случаи,
служащих для пров ерк и детализированн ы х функциональн ы х свойст в системы . На­
пр им ер , може т быт ь оди н тес тов ы й набор , пр едн а зна че нн ы й дл я прове рк и GUI-
инте р ф ей с а , и ещ е оди н тес т для прове рк и средст в обеспечени я безопасност и систе­
мы. В соста в тестовог о набор а могут быт ь включены , с одно й стор оны , тесты , кото­
р ы е р а бота ю т с эк р а н а м и ввода сп е ц и ф и че с к и х данны х ил и с экр ана м и дл я опреде­
ле ни я запросов . Тестовы й набо р отобра жа ет с я н а одн о конк р етн о е требовани е или
н а н е к о т о р ы й набо р логическ и связанны х требо вани й , в т о время как боле е детали­
зи р о в а н н ы е тес тов ы е случаи отобр а жа ютс я н а элемент ы функциональн о й специфи ­
каци и системы . Боле е подробн о вопрос ы структурировани я тесто в рассматриваютс я
в раздел е "Архитектура тестов " в главе 3.
 Глава 4. Проектировани е и разработк а тесто в 101

И последнее , чт о необходим о сказат ь о модульности, эт о то , чт о он а способствуе т

обнаружению дефект о в н а ранни х стади я х цикл а разработки . Т е оре тич е с к и кажды й
из уровней, на которы е ра збит а систем а , долже н проверятьс я на предме т присутст­
вия дефект ов , а тольк о посл е этог о становит с я возможны м перехо д на следующи й
уровень. Н а практик е план проведени я испытан и й може т пере сматри вать с я и кор­
ректироваться пере д переходо м н а следующий уровень , коим являетс я проектирова ­
ние тестов . П р ое к т ы тесто в могут пере сматрив ать с я и корректировать с я до того , как
начнется работ а над детализированны м и тест овы м и случаями. Эт и проме жуто чн ы е
контрольные т очк и препятствую т рас п рост ран е н и ю де фе кт о в рабочи х вариа нт о в
тестов далее п о жизненном у циклу тестиров ани я , чт о може т служить п р и ч и н о й воз­
никновения проблем , приводящи х к срыва м рабочег о графика .

О Д И Н КРУПНЫ Й ТЕСТ? — БОЛЕЕ ПОД РОБ Н О ОБ АРХИТЕКТУРЕ ТЕСТОВ

В принципе, м о ж н о разработать гигантский тест, которы й покрыл бы все аспекты тести­
руемого пр о гр ам мн о г о про дукта , однак о существует несколько причин, в силу которы х
эту идею нельзя реализовать на практике. Предпо ло жим , что в результате прогона это-
го гигантского теста обнаруже н о сразу несколько дефектов. Когда разработчик пред­
принимает попытку воспроизвести один из этих дефектов , дабы отыскать основную при­
чину возникшей проблемы и устранить ее , то ка к же е м у поступить в такой ситуации?
Неужели снова выполнять про го н этого большого теста? Предпо ло жим , что всеми прав­
дами и неправдами е м у все-таки удалось устранить неисправность. Как теперь прове­
рить, что дефек т и в само м деле устранен — опять-таки прогонять тот же самый супер -
тест? Очевидно, что это явно не самый эффективный подход.
Поэтому лучше всего выбрать таку ю структур у , чтобы каждый тест охватывал конкрет ­
ную часть функциональных возможносте й тестируемог о програм мн о г о продукта . Если
прогон таког о теста завершается неудачей, то разработчику нетрудно будет ещ е раз
прогнать этот тест и воспроизвести дефект , затем провести анализ результатов тестиро­
вания и устранить неисправность. В идеальном случае объе м таког о теста сводится до
минимального набора действий, необходимог о для выявления неисправности.
Если в основу тестирования пр о гр а мм но г о продукта положен ы предъявляемые к нем у
технические требования, то эмпирическое правило для определения объем а теста со ­
стоит в т о м , что на ка жд о е техническое требование долже н приходиться, по меньшей
мере, один тест. Принцип "по меньшей м е р е , один тест на одно техническое требова­
ние" не только позволяет выбирать размерность теста в разумных пределах, но и под­
держивает разработк у плана проведения испытаний. На базе пересмотра перечня техни­
чески х требований м о жн о оценить, скольк о новых тестов потребуется для тестирования
•нового про гра м мн ог о продукта . Как только вы начнете создавать тесты, руководствуясь
этим принципом, вы сможет е подсчитать, скольк о времени потребуется на разработк у и
прогон теста на основании ранее полученных результатов.
Тестирование на базе технических требований позволяет качественно организовать испы­
тания. Технические требования обычно объединяются в группы по функциональным
свойствам. Свои тесты м о ж н о организовать по то м у же принципу. Тесты, относящиеся к
подготовке к работе технических средств заказчика, м ож н о объединить в одну группу ,
равно как и тесты, предназначенные для проверк и средств установки и наращивания
возможностей про гра мм но г о продукта . Как следует из главы 3, групп ы логически свя­
занных тестов могу т быть помещены в один тестовый набор (test suite).
Для тестирования конкретног о технического требования може т понадобиться более од -
jHoro сценария. Например, если вы тестируете техническое требование, регламенти­
рующее ввод данных заказчика, то требуемы й тип данных и их количество м ож е т м е ­
няться в зависимости от того , принадлежит ли заказчик к "серебряном у классу", "золо ­
тому классу" или "платиновому классу". Тест для проверки этого требования придется
модифицировать в соответствии с классом заказчика.
102 Часть I. Процесс быстрого тестирования

Один из способов разрешения подобного рода ситуаций заключается в создании трех

различных тестовых случаев, по одному для каждого класса заказчика. Тестовый случай
(fast case) представляет собой совокупность входных данных теста, условий выполнения и
ожидаемых результатов, которые разработаны для конкретной цели. Тестовый случай
представляет наименьшую единицу тестирования, которую можно самостоятельно вы­
полнить от начала до конца.

Определение целей теста

Самой первой задачей, с которой начинается проектирование теста, является стро­
гая формулировка его целей или назначения. Предположим, что вы разрабатываете
тесты для приложения ТМТ, описание которого приводится в главе 2 и в третьей
части книги. Одно из технических требований этого приложения выглядит следую­
щим образом (другие требования представлены на рис. 2.4 в главе 2):
2 . 2 . 1 . Приложение должно пр ед о ст ав и т ь ср ед ст в а с о зд а н ия , модифи­
кации , просмотра , хранени я и поиск а документо в , имеющих отноше­
ние к плану проведени я испытаний .
Техническое требование 2.2.1 распространяется на широкий набор функциональ­
ных свойств, но все они относятся к управлению документами, содержащими план
проведения испытаний. Один из способов свести воедино тесты, относящиеся к это­
му требованию, предусматривает создание набора под названием "Test_Plans" ("Пла-
ны_проведения_испытаний") и сбор в нем всех тестов, предназначенных для про­
верки требования 2.2.1. Например, перед тестами, входящими в этот набор, можно
поставить следующие цели:
1. Проверить, что программа предоставляет квалифицированному пользовате­
лю средства создания всех действующих типов документов, которые имеют
отношение к плану проведения испытаний.
2. Проверить, что квалифицированный пользователь может сохранять и оты­
скивать любой составленный план проведения испытаний.
3. Проверить, что программа предоставляет квалифицированному пользовате­
лю средства модификации всех документов с планом проведения испытаний,
которые были составлены и сохранены в памяти.
4. Проверить, что квалифицированный пользователь может отыскать и пере­
смотреть любой документ, содержащий план проведения испытаний, который
был составлен и сохранен в памяти.
Каждая цель теста устанавливает, что тест будет делать, но отнюдь не то, как он
это будет делать. Как— это дело подробной методики тестирования, которая разра­
батывается в виде части соответствующего случая тестирования. Цели теста пред­
ставляют собой уточнение плана проведения испытаний, другими словами, тест дол­
жен быть ориентирован на проверку технического требования 2.2.1. Другим отличи-
ем проекта теста от тестового случая является то, что проекты тестов обычно созда­
ются с использованием спецификации технических требований. Тестовые случаи,
требующие более подробного знакомства с программным продуктом, требуют, по
 Глава 4. Проектировани е и разработк а тесто в 103

меньшей мере , функци она л ьн о й с пе ц и фи к а ц и и или , в озможн о , доп о лн ите л ьн о й ин­

формации и з п рое к т н о й документаци и п о программном у продукту.
Обр ати т е вниман и е н а т о обстоятельство , чт о п ри м ер ы целе й т е с ти р о в а н и я тре­
бует некот оро й разъясн ите льн о й ин форм а ц и и , когда даетс я оп ре де л ен и е следующе­
г о "слоя луковицы" . Ц е л ь н оме р 1 теста , на при м ер , н е дае т о п ре д ел ен и я "квалифици ­
рованного пользовате л я " — т.е. уточнени я , кот ор о е зависи т о т того , как спроект иро ­
вано управлени е доступом к программ е . Д о л жн ы быт ь построен ы тесть;, проверяю ­
щие, могут ли получит ь доступ к данны м к ва л и фи ци рова нн ы е пользователи , и в то же
время н ек в а ли фиц и ров ан н ы е пользовател и н е могут. Цел и тест а такж е ничег о н е
говорят о том , чт о собо й представляю т "действующи е т и п ы документо в с плано м
проведения испытаний " , однак о наличи е это й фо р м у л и р о в к и подсказыва е т специа­
листу по т е ст и р о в а н и ю , ч т о нужно рас см отре т ь в кач ест в е случаев как действующих,
так и не действующи х тип о в документов, есл и установле н ы конкретн ы е к ри т ер и и
применимости .
По сути дела, в процесс е формулировани я целе й т е с т и р о в а н и я следует пользо­
ваться следующими рекомен дациям и :
• Ч ет к о сформули ро ва т ь назначени е каждог о теста .
• Опре дел и т ь модульную структуру для тестов , та к чтоб ы каждый тес т име л
единственн у ю цель , и чтоб ы ег о можн о был о от о б р аз и т ь н а помеченно е требо ­
вани е в с п е ц и ф и к а ц и и тех ничес к и х т р е б о в а н и й . Од н ак о имейт е в виду, чт о дл я
т е ст и р о в а н и я н е к о т о р о г о конк ретног о т р е б о в а н и я може т понадобитьс я боле е
одног о теста .
• Указать, чт о долже н делат ь тест , н о в т о ж е врем я н е следует объяснять , как эт о
достигаетс я — эт о должн о быт ь указано в тестово м случае.

Определение спецификаций ввода

Спецификаци и ввода регламентирую т форм а т ы фа й л о в входны х данных , записе й баз
данных, конфигурационн ы х файлов , оборудовани я ил и других входных данных , не­
обходимых дл я того , чтоб ы привест и испытательну ю систему в требуемо е состо ян и е
для выполнени я тестов . Спецификац и и ввода не охватыва ю т ввод с клавиатуры ил и
ввод пр и помощ и мыши , к от о р ы й производитс я в процесс е тестировани я ; таки е ви­
ды ввода должн ы описывать с я в подробны х методика х исп ыт ани й .
Каждому входному файл у ил и образу долже н быт ь присвое н уникальны й иденти­
фикатор, приче м он и должн ы хранитьс я в среде , обеспечивающ е й управлени е вер­
сиями и регулярно е дублирование . Хранилищ е входны х данны х должн о быт ь описа­
но в плане проведени я испытаний , а в с п е ц и ф и к а ц и и ввода тест а должн ы присутст­
вовать ссылк и н а эт о хранилище . Нап р им ер , набо р документов , содержащи х пла н
проведения испытани й , мож е т понадобить с я дл я тестов , опи са нн ы х в предыдущем
разделе. О н и могут имет ь имен а TP _ i n p u t l . d o c , TP_i n put 2. d o c и т.п., и хранитьс я в
каталоге, нап ри м ер , D:\Tes t\Proje ct_Na me \Te st_Pla n\ Input s .

Определение конфигурации средств тестирования

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

программног о продукта и начально е состоян и е систем ы до л жн ы быт ь определены .

Как отмечалос ь в главе 3, работ а по составлени ю план а пров еден и я и с п ы т а н и й долж­
н а предусматриват ь анали з разли чн ы х вариант о в к онфигурац и и средст в тестирова­
ни я и выбо р и з ни х кон фигураци й , пригодны х для системн ы х и сп ы т а н и й .
Задач а заключает с я в том , что б ы н а стади и п рое к т и ров а н и я к он к ре т н ог о теста
выбрат ь одну ил и нескольк о конфигураци й , кот ор ы е можн о использоват ь для дости­
жени я целе й этог о теста . Зачасту ю оди н и то т же тес т нужно выполнит ь на некото­
ро м множеств е конфигураци й , чтоб ы смоделирова т ь раз ли чн ы е ра боч и е условия
заказчика . Н а п р и м е р , крупны й заказчи к може т использоват ь преимущественн о стан­
дартны е конфигурац и и оп е ра ц и он н о й системы , процессора , на копит е л я н а жестких
дисках, сетево й о п е ра ц и о н н о й систем ы и оп е рати в н о й памят и — такую конфигура­
цию мож н о смодели ров ат ь в лаб ораторн ы х условиях с высоко й степень ю точности .
Оди н и з способо в отслеживан и я конфигураци й предусматрива е т и х описани е в
плане проведени я исп ыт а н и й с прис в ое ни е м каждой конфигурац и и уникальных
идентифи каторо в . В тако м случае в план е проведени я и с п ы т а н и й горазд о проще
ссылаться н а одну ил и нескольк о изб ра нн ы х конфигураци й .

Документ проектов тестов

Назначени е документ а проек т о в тест о в состои т в том , чтоб ы с о б ра т ь в одно м месте
всю и н форм а ц и ю , порожденну ю в результат е различны х видо в тест ов о й деятельно­
сти. Документ п роек т о в тес т о в може т быт ь представл е н в виде э л е к т ро н н о й таблицы ,
в виде таблиц ы текстовог о проц есс ор а ил и в виде баз ы данны х . Если вы пользуетесь
инструментальны м средство м автоматизированног о управлени я т ре б ова ни ями , его
можн о п ри ме нит ь для сбор а и н ф о р м а ц и и о проект е теста . П р и м е р запис и в докумен­
т е проект о в тест о в показ а н в таблиц е 4.1 .

Эта таблиц а в какой-то сте пен и похож а на матрицу RTM ( Re q u i r e me n t Traceability

matri x — матриц а прослеж иваемос т и требо ваний ) , ко тора я рассматривалас ь в главе 2
(см. рис . 2.5). Два первы х столбц а таблиц ы должн ы соответствоват ь вхождени я м в
матрицу RTM, остальны е столбц ы соответствую т данным , описанны м в тр е х преды­
дущих разделах да н но й главы.
Как тольк о п р о е к т н ы й документ тест о в будет готов, ег о нужно про в ер и т ь в кон­
текст е связанны х с ни м материалов : документа определени я т ре б ова н и й (техниче-
 Глава 4. Проектировани е и разработка тесто в 105

ского задания) , оп р ед е ле н и я входны х данны х тест а и конфигураци и средст в тести­

рования. Ц е л и та к о й проверк и связан ы с необходимость ю убедиться:
• Ч т о рассм атрива ем ы м документом прое кт о в тест о в был и охвачен ы все техни ­
чески е требовани я . Если т о ил и ино е тр е б о в а н и е н е тестируется , в матриц е
RTM ил и в документе проект о в тест о в должн а присутствоват ь запись , пояс­
няющая , почему соответствующе е тр е б о в а н и е н е покрывает с я тестом .
• Чт о кажды й тестовы й случай поддерживает с я соответствующим и входным и
данными .
• Ч т о дл я каждог о тестовог о случая имеетс я подходяща я конфигурация , прич е м эт
и конфигурац и и н е являют с я избыточными .
Документ проект о в тесто в служит осново й дл я раз р аб от к и детально й методи к и
тестирования . В результат е ег о п е р ес м от р а тест ы могут распределятьс я сред и испол­
нителей группы те ст и р о в а н и я для дальнейш е й д ета л из ац и и .

Разработка тестовых случаев

Тестовый случай представля е т со б о й осн овн о й ком п он е н т динамич еск о г о тестиро ­
вания. По сути дела, эта п системног о т е ст и р о в а н и я — едва ли что-то большее , не ж ел и
просто п р ог о н тестовы х случаев н а н е к от ор о й последовательност и программн ы х
сборок с цель ю обнаружен и я и устранен и я д е ф е к т о в . Эт о означает , чт о осн ов на я
обязанность специалист а по т е с т и р о в а н и ю заключает с я в написани и и прогон е тес­
товых случаев. В это м раздел е мы обсудим, как п р о е к ти р о в а т ь и создават ь высокока­
чественные тестовы е случаи.
В главе 1 был о дан о оп р е де л ен и е т е ст и р о в а н и я программно г о об ес пе ч е н и я как
процесса анализ а ил и эксплуатаци и прог р а мм но г о о бе сп е ч ен и я с цель ю выявлени я
дефектов. Тест (test) представляе т собо й набо р оп е ра ц и й , предназначенны х для полу­
чения одног о ил и большег о числа ожидаемы х результато в в некот ор о й программн о й
системе. Если получены все ожидаемы е результаты , считается , чт о тес т проше л (т.е.
выполнен успешно) . Если ф а к т и че с к и й результа т отличаетс я о т ожидаемого , счита­
ется, чт о тес т не проше л (т.е. завершилс я неудачно) .
Первое , чт о следует отмети т ь в приведенн о м определе ни и , та к эт о то , чт о кажды й
тест состои т из двух компонентов : (1) совокупност ь выполняем ы х вами действи й и (2)
последовательност ь событий , которы е должн ы про из ойт и в результат е эти х дей­ ствий.
Выполняемы е действи я суть тес тов ы е действия , которы е в совокупност и об­ разуют
методику тестировани я . Последовательност ь событий , происходящи х в ре­ зультате
эти х действий , называютс я ожидаемым и результатами . Чтоб ы тес т бы л эф­
фективным, должн ы быт ь четк о и однозначн о определен ы как методика , та к и ожи­
даемые результаты .
Во-вторых, есл и методи к а т е с т и р о в а н и я и о жид ае м ы е результат ы о п р е д е л е н ы
правильно, тес т долже н давать результат, п о котором у можн о сделать од ноз на чн ы й
вывод относительн о успеха или неудачи испыт ан и я . П р и вводе в программу двух чи­
сел с целью получени я их суммы тес т считаетс я про йденны м , если на выход е про­
граммы будет получен ко р р ект н ы й результат; в противн о м случае тес т рассматрива­
ется как не пр ойд ен ны й .
 106 Часть I. Процесс быстрого тестирования

Как отмечалось ранее, для удобства выполнения тесты можно и далее разбивать на
тестовые случаи. Если некоторый тест требует выполнения пространной методи­ ки
тестирования с множеством ожидаемых результатов, имеет смысл разбить такой тест
на тестовые случаи. Однако при этом следует иметь в виду, что тестовый случай есть
наименьший модуль тестирования, и что с каждым тестовым случаем должен
быть связан, по меньшей мере, один ожидаемый результат.
В силу того, что целью тестирования является выявление дефектов, хорошим тес­
том считается тест с высокой вероятностью обнаружения дефекта. Чтобы спроекти­
ровать тест, обладающий высокой вероятностью обнаружения дефекта, специалист по
тестированию должен стать на позицию "конструктивного разрушения" про­
граммного продукта. "Конструктивное разрушение" означает выявление проблем в
программном продукте с целью их устранения. Сложность при этом связана с тем,
что в задачи специалиста по тестированию не входит выявление обстоятельств, при
которых программный продукт работает; наоборот, тестировщик пытается обнару­
жить такие ситуации, при которых продукт не работает. При проектировании тесто­
вого случая важно не делать никаких предположений относительно того, что та или
иная функция программного продукта работает исправно. Вы не должны рассчиты­
вать на то, что какая-либо сборка программного кода будет установлена правильно,
или на то, что структура базы данных соответствует проекту, или что программа са­
мостоятельно восстановится после потери напряжения в электросети. Нельзя также
рассчитывать и на то, что если программа успешно работает на заданной платформе,
то она будет работать столь же хорошо и на компьютере с меньшим пространством
памяти или под управлением другой операционной системы.
Другое свойство хорошо спроектированного теста— его повторяемость. Если
прогон теста завершился неудачей, очень важно воспроизвести точные условия, при
которых это произошло. По этой причине важно, чтобы начальное состояние систе­
мы было определено тестовым случаем в терминах используемой версии программ­
ного продукта, конфигурации аппаратных средств, количества пользователей систе­
мы и т.д. Важно также, чтобы была известной точная методика, используемая при
выявлении неисправностей. В идеальном случае должна фиксироваться точная по­
следовательность нажатых клавиш, щелчков мыши или другие события, которые
привели к отмеченным отклонениям от ожидаемых результатов. На практике все эти
подробности могут оставаться неизвестными, возможно, из-за того, что методика
тестирования не расписана во всех подробностях, или из-за того, что произошло ка­
кое-то неконтролируемое случайное событие без ведома тестировщиков. Вот почему,
когда происходит сбой, важно, не жалея времени, немедленно воспроизвести неис­
правность, подробно фиксируя при этом действия, которые привели к сбою, если
только они явно не расписаны в методике испытаний.
Хорошо спроектированный тест снабжен одним или большим числом четко опре­
деленных ожидаемых результатов и четко определенными критериями успеш­
ных/неудачных испытаний. Обычно ожидаемые результаты и критерии успеш­
ных/неудачных испытаний тесно связаны. Если ожидаемый результат или некото­
рый набор ожидаемых результатов будет получен, когда система переводится из од­
ного заданного состояния в другое, то тестовый случай проходит. Если ожидаемые
результаты не удается зафиксировать после выполнения заданных действий, тест не
проходит. Например, предположим, что в поле ввода данных вводится значение поч-
 Глава 4. Проектирование и разработка тестов 107

тового индекса, и при этом ожидается, что на экран будет выведено название соот­
ветствующего штата после щелчка на кнопке "Укажите штат". Если после ввода неко­
торого набора почтовых индексов для каждого из них появляется правильное назва­
ние штата, это значит, что тест получает ожидаемые результаты и поэтому проходит.
Если же при вводе почтового кода Сиэтла на экране отображается штат Флорида,
считайте, что вам повезло в плане обнаружения дефекта, поскольку ожидаемый ре­
зультат не был получен.
Следует отметить, по меньшей мере, один дополнительный признак хорошо
спроектированного тестового случая — он не должен быть избыточным. Оптималь­
ный рабочий график тестирования требует, чтобы вы выполнили объем тестирова­
ния, достаточный для обнаружения всех неисправностей перед поставкой программ­
ного продукта заказчику, но вы не должны тратить время на прогон избыточных тес­
тов. В рассмотренном выше примере вы не должны тратить время на отображение на
экране названия штата для каждого известного почтового индекса, если эта функция
не критична для бизнес-операций заказчика. Если с отображением на экране почто­
вых индексов связана крупная неприятность, наверняка потребуется потратить вре­
мя на тестирование функции отображения. Кроме того, следует задуматься над во­
просами автоматизации этой утомительной задачи. Но если это свойство реализуется
из соображений удобства, возможно, потребуется лишь проверить какой-нибудь до­
пустимый и несколько недопустимых индексов, дабы подтвердить правильность ба­
зовых функциональных свойств. Эта тема обсуждается в разделе "Разбиение на экви­
валентные классы" далее в этой главе, а также в главе 10.
Резюмируя, можно утверждать, что с тестовым случаем должны быть связаны сле­
дующие признаки:
• Он должен обладать высокой вероятностью обнаружения дефекта.
• Он должен быть воспроизводимым.
• Он должен обладать четко определенными ожидаемыми результатами и крите­
риями успешного или неудачного выполнения теста.
• Он не должен быть избыточным.

Разработка детализированных методик тестирования

Детализированные методики тестирования могут быть разработаны на основе про­
ектов тестов. Уровень детализации методик тестирования, представленных в пись­
менном виде, зависит от квалификации и знаний исполнителей, которые выполняют
прогон тестов. Вы планируете привлечь к выполнению системного испытания про­
граммного продукта исполнителей, мало знакомых с этим продуктом? Если это так,
то они должны пройти определенную подготовку, а методика тестирования должна
быть четко сформулирована с тем, чтобы они выполняли корректные тестовые дей­
ствия. В случае, когда тестировщики обладают подробными знаниями программного
продукта, методика тестирования может быть менее детализированной. Решение
относительно того, каким должен быть уровень детализации методик тестирования,
имеет большое значение, ибо можно напрасно потратить время на описание излиш­
них подробностей для подготовленного пользователя. С другой стороны, напрасно
потратить время можно и на обучение неподготовленных тестировщиков тому, как
108 Част ь I . П ро ц е с с бы ст ро г о тестировани я

пров оди т ь испытания , есл и методи к а н е содержи т необход имы х деталей . Та к или
инач е , желательн о найт и разумн ы й компромисс .
Отдельног о р а сс м от р ен и я заслуживае т оди н специальны й случай. Если тес т за­
служивает того , чтоб ы б ы т ь автоматизированны м , це ле с о об р аз н о выделит ь врем я н а
предварительну ю разработ к у д ет ал изи р о ва нн о й методик и тести рова ни я , с помощью
к от ор о й и н ж е н е р п о а в т о м а т из а ц и и сможе т однознач н о сфор мул ир ова т ь задачу ав­
томатизаци и . Расплывч ат а я методи к а тестировани я , скоре е всего , привед е т к появ­
л е н и ю неточны х ил и н е э ф ф е к т и в н ы х автоматизированн ы х тестов . Рекомендуемый
уровен ь д ета л иза ц и и м ето ди к и т е с т и р о в а н и я проясн ит с я посл е дальнейшег о обсуж­
дени я ожидаемы х результатов .
Существует ши рок и й в ыб о р технологий , которы е могут использовать с я для тес­
тирован и я программны х продуктов . В это й главе мы будем рассматриват ь техноло­
ги и т е ст и р о в а н и я методо м че р но г о ящика . Тести рован и е методо м ч е рн ог о ящика
представляе т собо й т е с т и р о в а н и е н а системно м уровне , кот оро е имее т дел о только
с о "внешними " аспекта м и программ ы . Те стиров ан и е методо м ч ер н ог о ящик а н е
предполагае т каких-либо з на н и й о внутренне м функ ци они ров ан и и программног о
продукта и проводит с я с использование м тольк о внешни х и н т е рфей с о в , таки х как
пользовательски е и н т е р фе й с ы ил и и н т е рфе й с ы API (Application P r o g r a m m i n g Inter­
face — и н т е рфе й с п рог рам миров ан и я п ри л ож е н и й ) . Боле е п одробн ы й анали з тести­
рова ни я методо м ч е р н ог о ящик а можн о найт и в [17] , [15] и [27] . Боле е подробную
и н форм а ц и ю о т е с т и р о в а н и и с использование м метода ч е рн ог о ящик а можн о найти
в главе 10 настояще й книг и .
Двумя широ к о рас прост ра ненны м и технологиям и р а зр аб от к и тест о в для тестиро­
вани я методо м че рн о г о ящик а являют с я разбиени е на классы эквивалентност и и ана­
ли з граничны х зн ач ен и й . Об е технологи и помогаю т уменьшит ь обще е количество
тестовы х случаев ил и п роверяе мы х условий, которы е необходи м ы для полног о по­
крыт и я функциональны х в оз мо ж н ост е й программ ы . Вполн е п он ят н о , ч т о эт и методы
явл яют с я ц ен н о й часть ю пон ят и я быстрог о тестировани я , иб о че м меньш е требуется
разр абаты ва т ь и прогон ят ь тест о в с цель ю получен и я тог о же функциональног о по­
кр ыт и я , тем э ф ф е к т и в н е е становитс я тестирование .

Разбиени е на классы эквивалентности. Разбиени е на классы эквивалентност и пред­

ставляе т собо й технологи ю пр о ект ир о в ан и я тестов , ориентированн у ю н а снижени е
общег о числа тестов , необходимы х для подтверждени я кор ректн ос т и функциональ­
ных возможносте й программы . Осн овна я идея, стояща я за разбиени е м на классы эк­
вивалентности , заключаетс я в том , чтоб ы разбит ь област ь ввода программ ы на клас­
сы данных . Если проекти р ова т ь тест ы для каждого класса данных , но не для каждого
член а класса, т о обще е количест в о требуемы х тесто в уменьшается .
В качеств е п ри ме р а рассмотри м программ у отображени я почтовы х индексов , ко­
т ор а я рассматривалас ь р а н е е в главе. Предположи м , чт о когда пользовател ь вводит
пят изна чн ы й почтовы й индек с и общую массу отправляемог о груза в унциях, про­
грамма возвращае т стоимост ь доставк и пакета. Обла сть ю ввода дл я это й программы
являютс я почтовы е индекс ы и масса брутто отправляемог о груза. Област ь ввода поч­
товог о кода може т быт ь разбит а на класс допустимых вводов и класс недопустимых
вводо в следующим образом :
 Глава 4. Проектир овани е и разработк а тесто в 109

• Допустимым и вводами я в ля ю т с я все п ятиз на чн ы е набор ы ц и ф р ов ы х символов ,

образующи х раб о ч и й по чт о вы й ко д
• Недопустимы м и вводами являются :
• Н а б о р ы ц и фров ы х символов , сод ер жащ и е мене е пят и символо в
• Н а б о р ы цифров ы х символов , содержащи е боле е пят и символо в
• На б о р ы и з пят и символов , н е являющиес я рабочи м почтовы м кодо м
• Н а б о р ы и з неци фровы х символов .
Аналогично е разбиен и е може т быт ь построен о и дл я массы брутто отп р а вл я е мо г о
груза. Н а п р и м е р , требуется программ а , р абота ющ а я тольк о с грузами, масса кот оры х
находится в диапазон е от 1 до 100 унций . В это м случае числовы е значения , попа­
дающие в диапаз о н от 1 до 100, включа я и кон ечн ы е точки , являют с я допустимыми .
Все значени я меньш е 1 и больш е 100, от р и ц а т е л ь н ы е значен и я и н е ц и ф р ов ы е значе­
ния образую т недопустимы е классы ввода.
Нужно спро е кти р о в а т ь таки е тесты , к от ор ы е выполняю т проверку , п о меньш е й
мере, одног о представител я каждог о допустимог о класса ввода и, по меньше й мере ,
одного представите л я недопустимог о класса ввода. В результате т е ст и р о в а н и я с при­
менением допустимы х вводов д ол ж н ы б ы т ь получен ы однознач н о о п р е д е л е н н ы е и
ожидаемые результаты . Дл я почтовог о кода 78723 и массы в 20 унци й ожидаетс я по­
лучить к он к ре т н о е значени е стоимост и , и э т о значе ни е должн о б ы т ь оп р е д е л е н о в
функциональны х требования х . В случае ввода недопустимых данны х д олж н о быт ь
получено соответствующе е сообщени е о б ошибке , есл и о н о оп р ед е л ен о в техниче ­
ских требования х и спецификациях . П р и вводе недопустимы х данны х программ а , по
меньшей мере , н е должн а завершатьс я а в а ри йн о , вызыват ь искажени е данны х ил и
вести себ я непредсказуемы м образом .
Боле е по д р обн о е обсуждение разбие н и я н а классы эквивалентност и можн о найт и
в главе 10, а такж е в [ 3 6 ] , [27] , [43] , [28] и [17] .

Анализ граничны х значений. Анали з гранич н ы х з нач ен и й представляе т собо й тех­

нологию пр ое кт ир о ва н и я тестов , котора я являетс я дополнение м разби ен и я н а клас­
с ы эквивалентности . Вместо тог о чтоб ы выбират ь некото ры й к о н к р е т н ы й эле мен т
класса эквивалентности , анали з гран и чн ы х зна че ни й предлага е т проектировщик у
теста выбрат ь элементы , которы е находятс я "н а границе " класса. Эксперимента ль н о
было доказано , чт о дефект ы имею т тен де нц и ю концентрировать с я н а гр ан иц е облас­
ти ввода, а не в ее центре . Не особенн о ясно , почему так получается, эт о всего лиш ь
установленный факт .
На п р и м е р , в случае программы , котора я для почтов ог о индекс а и веса отправляе ­
мого груза вычисляе т стоимост ь доставки , анали з граничны х зн а че н и й позволяе т
применят ь в качеств е тестовы х зн а че н и й минимально е и максимально е зна че ни е ве­
са (1 унци я и 100 унций) , а такж е ближайше е значен ие , меньшее минимальн о допус­
тимого (0 унций) , и ближайше е зна че ни е , больше е максимальн о допустимог о (101
унция). Эт и значен и я позволяю т прове ри т ь границ ы диапазон а допустимы х значе­
ний, а такж е зна че ни я , выходящи е з а предел ы этог о диапазона . Бол е е подробн у ю
информац и ю по анализу граничны х зна че н и й можн о найт и в главе 10, а такж е в [36] ,
[27], [43 ] и [17] .
110 Част ь I . П ро ц е с с быст рог о тестировани я

Определение ожидаемых результатов

Основу д ин ам и ч ес к о г о т е с ти р о в а н и я составляе т пр ог о н управляемог о набор а опера­
ци й н а к он к ре т н о й сборк е прогр аммн ог о продукта и с ра в не ни е полученн ы х резуль­
тато в с о жида емы м и результатами . Если получен ы о жи д ае м ы е результаты , т о тес т
считаетс я прошедши м н а эт о й сборке ; есл и з а фи к с и р ов а н о аномально е поведен и е , т о
считаетс я , ч т о тес т н а э т о й сборк е н е прошел , в т о ж е вре м я это т тест , возможно ,
позволи л обнаружит ь очередну ю неисправность . Н е п ре м е н н ы м условием для опре­
деления , прош е л ил и н е прош е л к он к рет ны й тест , я вл я ет с я однозначн о е определе­
ни е ожидаемы х результато в этог о теста .

Фрагмен т тестовог о случая для программ ы , котору ю рассматривает с я в качест в е

пример а и в ы чи сл я е т с то и мо ст ь доставк и по почтовом у индексу груз с заданны м ве­
сом, приводит с я в т а б л и ц е 4.2. Ш аг и методик и т е с т и р о в а н и я пронумерован ы в пер­
вом столбц е . К ра т к и е оп и с а н и я действи й , выполняемы х тестировщиком , дан ы в о
второ м столбце , а и с ч е р п ы в а ю щ и е опи са ни я ож ида ем ы х результато в находятс я в
третье м столбц е . П р ед п ол аг ает с я , чт о в это м п ри м е р е п р и п р ов ед е н и и испы тани й
будет использоватьс я тверда я (ил и интерактивна я ) копи я эт о й таблицы , в связ и с чем
в не й предусмотр е н ч етв ер т ы й столбец , в котор о м тестировщи к може т отмеч ат ь ка­
жды й вып о лн енн ы й шаг. В дальнейше м мы покажем , чт о следует предпринимат ь в
случае, если какой-то тес т н е проходит . Особо е вн им ан и е следует обра ти т ь н а то ,
чтоб ы н а каждом шаг е методик и тестирован и я предоставлялис ь четки е оп ис ани я
ожидаемы х результатов .

Установка и очистка — тестирование из известного состояния

Оди н из основны х п ри н ц ип о в тестирован и я заключаетс я в том , чт о всегда необхо­
дим о знать , в како м с ост о ян и и находится тестируема я система . Если обнаружен де­
фект , но тестировщи к не знает , каки е действи я привел и к сбою, в таком случае воз­
никаю т трудност и пр и воспроизведени и этог о сбоя . Необходимост ь проводит ь тес­
тир о ва н и е и з известног о состояни я означает , чт о кажды й тес тов ы й случай долже н
привест и аппаратн ы е и программн ы е средств а в известно е состояни е . Эт о отню д ь н е
означает , чт о тестир ов щи к обяза н обес точ и т ь систему, перезагрузит ь е е и запускать
программ у с самог о начал а — ка к и в любы х других ситуаци я х п р и тестировани и , все
имее т сво и пред елы .
 Глава 4. Проектировани е и разработк а тесто в 111

В о избежани е переход а исп ыт ы в а е м о й систем ы в состояни я , к от ор ы е невозмож ­

н о воспроизвест и , существует ря д практически х мер . О д н о й и з ни х являет с я выпол­
нение э не рг ет и че с к о г о цикл а систем ы пере д начало м т е с т и р о в а н и я — это , по-
видимому, следует делат ь в начал е каждог о рабочег о дня . Другая мер а предусматри­
вает периодическо е обнов лени е ба з данны х и удаление тестовы х каталогов . Если
применяетс я ав то м атиз а ц и я тестирова ни я , т о очистк у ба з данны х и каталог о в дан­
ных можн о проводит ь част о и не тр а ти т ь на эт о мног о времени . Возможно , чт о тес­
тируемая систем а производи т изменен и я в о встроенн ы х программн ы х средствах.
Если эт о так , т о встроенн ы е пр ог р ам м ы потребуетс я перезагрузит ь л и б о д о запуска
логически связанны х тестов , л и б о в начал е каждого рабочег о дня , чт о об е сп е чи т тес­
тировани е неис каженн о й ве р с и и встроенн ы х программны х средств . В идеально м
случае для сох ранен и я текущего состоян и я тестируем о й систем ы в специально м хра­
нилище, для рег ис тр а ц и и р а з л и ч н о г о род а откл онен и й и для перевод а тестировщи -
ком систем ы в нужное сос тояни е используютс я автоматизиров анн ы е инструменталь ­
ные средства.
Существуют два подхода к ин и ц и а л из а ц и и теста . Оди н из ни х предусматривае т
применение специальн о й пр ог ра м м ы настройки , ко то р а я пер е д начало м тестирова ­
ния приводи т систему в известно е состояние , и использовани е ста нд а ртн ы х про­
грамм очистки , которы е "аннулируют " изменения , вн есенн ы е в процесс е тестирова ­
ния. Другой подход предусматривае т тольк о настройк у и никако й очистки . Если пе­
ред прогоно м каждого тест а выполняет с я соответствующа я оп е ра ц и я настройки , т о не
имеет значения , чт о произ ойде т в конц е тест а — все равн о до прогон а следующего теста
известны е условия будут восстанавливатьс я , пр и это м усилия, з ат рач е нн ы е на очистку,
могут оказатьс я напрас ным и . Разумеется, могут возникнут ь пр об ле м ы в си­ туациях,
когда добавляет с я н ов ы й тест , не ра ссчитан н ы й на настройку , а выполнен ­
ные ране е тест ы перевел и систему в непред усм отренн о е состояни е .
Рекомендуемы й в таки х случаях практически й мето д предусматривае т выполне­
ние очист о к посл е прогон а теста , к от ор ы й внутренн е пе ре в од и т систем у в непреду­
смотренное состояние . Н а п ри м е р , есл и в ы переполняет е катало г данных , иска жает е
базу данны х или переводи т е систему в состоян и е сбоя , то наилучшим решен и е м будет
восстановление систем ы в е е нормально м состоян и и п о о к о н ч а н и и теста . Аналогич­
но, если осуществляется прого н теста , о которо м известно , чт о он зависи т от началь­
ного состояни я системы , то лучше всего будет воспользоватьс я установочно й проце­
дурой для иниц иа лиз ац и и тестир уем о й системы .

Шаблон тестового случая

Все предложени я , касающиес я пр ое кт ир о ва н и я тестовог о случая, обсуждавшиеся до
сих пор , могут быт ь сведен ы в едины й шаблон тестовог о случая. Возможно , возник­
нет желан и е создат ь собств енн ы й шаблон , те м н е менее , стои т об р ат и т ь вниман и е н а
один и з вариант о в таког о шаблона , пок азан н ы й н а р ис . 4.2. Тестов ы е случаи, осно­
ванные на это м шаблоне , можн о распечата т ь для целе й неавтоматизированног о тес­
тирования , либ о за сче т о р ганиз ац и и отображени я в браузер е их HTML-верси й поя­
вится возможност ь прогон а тес т о в в интерактивн о м режиме .
112 Част ь I. Процесс быстрого тестировани я
 Глава 4. Проектировани е и разработк а тесто в 113

Основным и элемента м и шаблон а тестовог о случая являются :

• И д е н т и фи к а т о р тестовог о случая — включае т номе р ве рс и и теста .
• Владелец тест а — им я ил и иниц иа л ы лица , эксплуатирующег о тес т (он о може т
не совпадат ь с имене м автор а теста) .
• Дат а последнег о пе ре с м от р а — эт а и н ф о рм а ц и я позволи т определит ь , явля ет с я
л и тес т актуальным.
• Н а и м е н ов а н и е тест а — описательн о е им я теста , к от ор о е позволяе т легк о оты­
скат ь тес т и п он я т ь ег о на значени е . П р и м е н е н и е имен , н е несущих смыслово й
нагрузки, н а при ме р , "[Link]", н е рекомендуется .
• Местона хож ден и е тест а — эт о полно е им я пути, включа я се рв ер .
• Тестируем о е те хн и ч е ск о е треб о ва н и е — эт о долже н быт ь уникальны й иденти­
фи к а т о р , к от ор ы й отображает с я н а документ ы с тех ни ч ес к и м и требованиям и .
• Цел ь т е ст и р о в а н и я — кратка я и четка я фо р м ул и р о в к а того , чег о долже н дос­
тич ь данны й тест . Боле е подробн а я и н ф о р м а ц и я изложен а выше , в раздел е
"Опр едел ен и е цел е й теста" .
• Конфигураци я средст в те сти р ов а н и я — с п е ц и фи к а ц и я ввода, сп е ц и фи к а ц и я
вывода, услови я исп ытани й .
• Наст рой к а н а пр ог о н тест а — эт а процедур а подобн а методи к е тестирования .
Он а предусматривае т описани е действи й , выполняемы х тестировщиком , и
ожидаем ы х результатов . Если настрой к и а вт о мат изи р о ва н ы , эт о може т выгля­
дет ь как ru n [Link].
• Методик а т е с т и р о в а н и я — оп ис ан и е действи й , выполняемы х тестировщиком , и
ожидаем ы х результатов .
• Взаимозависимост ь тестовы х случаев — и д е н т и фи к а ц и я любог о тестовог о слу­
чая , прого н к о т о р о г о долже н предшествоват ь прогон у данног о теста , даб ы вы­
полн ен и е данног о тест а начиналос ь пр и заданны х условиях.
• Очист к а тест а — есл и систем ы был а переведен а в неустойчиво е состояни е ил и
данны е оказ алис ь разрушенными , очистк а предостави т шанс устранит ь подоб­
ны е ситуации .

Управление конфигурацией тестового случая

Во время прогон а тест а необходим о выполнит ь заданн ы й набо р операц и й на задан­
ной конфигураци и системы . Эт о обстоятельств о гарантирует , чт о тес т можн о вос­
произвести и чт о он осуществляет проверк у заданны х функциональны х возможно­
стей. По мер е того , как меняетс я программн ы й продукт в результате исправлени я
обнаруженных д е ф е к т о в ил и п о причи н е и з м е н ен и й , внесенны х в те х ни ч ес к и е тре ­
бования, тес т ы такж е требую т изме не ни й . Функциональны е возможност и программ­
ного продукта и тес т ы должн ы синхрон н о р еа гир ова т ь на таки е измен ен и я , в про­
тивном случае тест ы приведут к неверн ы м результатам.
Управлени е направлени е м измен ен и я программног о продукта осуществляется
благодаря использовани ю инструментальны х средст в CM (Configuratio n Manage­
ment — управлени е конфигурациями) , таки х ка к инструмента льн ы е средств а CVS
(Control Versio n System — систем а управлени я версиями ) ил и ClearCase. С помощь ю
114 Часть I. Процесс быстрого тестирования

упомянутых средств файлы, содержащие программные коды, проверяются при со­

хранении и при модификации. Эти средства обеспечивают управление версиями,
при этом предыдущие версии файла архивируются и, в случае необходимости, легко
могут быть найдены.
Такой тип СМ-систем очень хорошо работает как в условиях неавтоматизирован­
ных, так и автоматизированных тестовых случаев. Он позволяет идентифицировать
некоторый набор тестов так, что с некоторой группой тестов ассоциируется номер
версии. Например, версия 3.0 набора тестов по вводу данных может использоваться
для испытаний версии 3.0 тестируемого программного продукта.

Пересмотр и отладка тестов

После написания или автоматизации тест необходимо проверить на наличие дефек­
тов с целью их немедленного устранения, и затем испытать на некоторой сборке про­
граммного продукта. Статическое тестирование тестовых случаев можно проводить с
применением той же технологии, которая используется для проверки выполнения
технических требований, т.е. обследования, сквозного контроля или экспертных
оценок (см. раздел "Методы статического тестирования" в главе 2). Эти методы могут
применяться в различных сочетаниях, если сложность тестов такова, что необходи­
мо тщательное статическое тестирование. Например, экспертные оценки можно ис­
пользовать в методиках, а формальное обследование — в автоматизированных сцена­
риях, реализующих методики тестирования.
При проверке тестовых случаев необходимо обратить внимание на ряд следую­
щих моментов:
• В какой мере соответствует тест или тестовый набор функциональным воз­
можностям, заявленным в технических требованиях?
• Покрывает ли тестовый набор все технические требования?
• Организованы ли тесты достаточно эффективно, чтобы можно было обходить­
ся минимальными конфигурациями средств тестирования?
• Включены ли тесты в систему управления конфигурациями?
• Есть ли среди тестов избыточные? Можно ли устранить эту избыточность?
• Достаточно ли подробно разработана методика тестирования, чтобы стала воз­
можной ее автоматизация?
• Снабжен ли каждый шаг тестирования четко определенными ожидаемыми ре­
зультатами (критерий удачного/неудачного исхода испытаний)?
• Правильно ли воспроизводят автоматизированные тесты неавтоматизирован­
ные шаги тестирования?
Если вы провели статическое тестирование плана проведения испытаний, то пе­
ресмотр тестовых случаев пойдет намного проще, поскольку вопросы, касающиеся
покрытий технических требований тестами, должны решаться во время пересмотра
плана проведения испытаний. Вопросы, касающиеся избыточности тестов и эффек­
тивного использования конфигурации средств тестирования, также должны быть
затронуты в процессе пересмотра плана проведения испытаний, во всяком случае, на
уровне предварительных решений. Тщательные пересмотры планов проведения ис-
 Глава 4. Проектирование и разработка тестов 115

пытаний и тестовых случаев, равно как и статическое тестирование программного

продукта, содействуют раннему обнаружению дефектов в тестах и позволяют сокра­
тить затраты времени на отладку тестовых случаев.
В рамках такого пересмотра каждый новый тест нужно прогнать на некоторой
сборке программного продукта, дабы удостовериться, что методика тестирования
позволяет получить ожидаемые результаты. Поскольку этот тест, по-видимому, будет
прогоняться на программном коде, в изобилии содержащем дефекты, необходимо
соблюдать определенную осторожность при анализе неудачных исходов прогона тес­
та в плане, что является источником проблемы — программный код или сам тест. От­
ладка тестового случая часто требует от исполнителей такого же инженерного искус­
ства и аналитических способностей, которые так необходимы разработчикам про­
граммного обеспечения во время отладки кода программного продукта.

Автоматизация тестовых случаев

В главе 3 отмечалось, что при правильном планировании и разумных ожиданиях ис­
пользование автоматизированных инструментальных средств и автоматизированных
тестовых случаев представляет собой хороший способ снижения затрат времени на
тестирование программного продукта. В этой главе мы кратко обсудим некоторые
руководящие принципы, регламентирующие автоматизацию тестовых случаев. Авто­
матизация тестов — это вид деятельности по разработке программного обеспечения,
для выполнения которого нужно обладать таким же опытом и квалификацией, как и
при создании любого другого программного продукта. Если вы планируете потратить
средства и усилия на автоматизацию тестовых случаев, рекомендуем ознакомиться с
материалами [15] и [17].
Ниже перечисляются некоторые руководящие принципы автоматизации тесто­
вых случаев. Разумеется, приводимые ниже принципы следует привязать к конкрет­
ным условиям.
• Выполняйте автоматизацию только тех тестовых случаев, которые будут по­
вторяться достаточно большое количество раз, чтобы такая автоматизация бы­
ла рентабельной с точки зрения стоимости. Если вы намерены автоматизиро­
вать тесты, которые должны выполняться всего несколько раз, стоимость ав­
томатизации в смысле времени и финансов может превзойти ожидаемую выгоду.
• Разрабатывайте сначала неавтоматизированную версию тестового случая и
только после этого переходите к его автоматизации. Контрольные примеры
должны быть отлажены с тем, чтобы убедиться, что неавтоматизированная ме­
тодика испытаний определена верно, а конфигурация тестового случая работа­
ет правильно. Попытки одновременной отладки методики тестирования и про­
граммного кода, который автоматизирует эту методику, могут оказаться неэф­
фективными, более того, в худшем случае они могут стать причиной появления
ошибок в тестовом случае. Если неавтоматизированный тестовый пример под­
вергается отладке первым, он становится базисом, с которым можно сверять
автоматизированный тестовый случай.
• Предназначенная для автоматизации неавтоматизированная методика тести­
рования должна быть четко сформулирована и должна допускать однозначное
толкование с тем, чтобы инженер по автоматизации мог сосредоточиться на
116 Част ь I . Проц ес с быст рог о тестировани я

р а з р а б о т к е прог р ам м но г о кода, а не задумываться над тем , как долже н выпол­

нятьс я то т ил и и но й тестовы й шаг.
• Оп р ед е л и т е стандартну ю практик у к одирован и я и п р ид е р жи в айт е с ь ее требо­
ваний . Автоматизаци я представляе т собо й программно е обе с пе ч ен и е , которо е
дол жн о разр абаты вать с я стол ь ж е аккуратн о , как и тестируемы й программны й
продукт. Если планирует с я использовани е автоматизированн ы х сценарие в в
качеств е р ег ре с си вн ы х тестов , т о вполн е возможно , чт о он и будут нужны в
т е ч е н и е пр од олж итель но г о времени . В к онечн о м итог е може т случиться так,
чт о исполнитель , эксплуатирующи й тестовы й сце на ри й , и ег о р азр абот чи к —
ра з н ы е лица . В подобны х ситуаци я х ч ет к о н а п и са н н ы й и правильн о
задокум ентиро ванн ы й программны й код ест ь не пре м ен н ы м условием его
э ф ф е к т и в н о й эксплуатации .
• А в т о м а т и зи р о в а н н ы е тест ы долж н ы п р о в е р я т ь с я н а соответстви е неавто­
матизированн ы м тестам , о т которы х он и произ р а ст а ю т . Пере см от р ы про­
граммн ы х кодо в сц ена ри е в прин ос я т большую пользу пр и выявлени и ошибо к в
ав то м атиз ац и и и п р и кон трол е соблюдени я т р е б о в а н и й стандартов . Полна я
проверк а авт о м атиз и ро в ан но г о сце нар и я должн а подтвердить , чт о о н предос­
тавляе т т е ж е функцион а льн ы е свойства , чт о и ег о неавтоматизированн ы й
прот отип , и эт а п рове рк а должн а проводить с я в л а б о р а т о р н ы х условиях. Пр и
это м выполняет с я паралл е льн ы й п р ог о н неавтоматизированн о й и автоматизи­
рова нн о й ве р с и й тест а н а всех запланирован н ы х конфигураци я х тестовы х
средст в и в запл ан и рова нн ы х условиях.

• А в т о м а т и з и р о в а н н ы е тестовы е сцена ри и до лжн ы находитьс я под управление м

систем ы подде рж к и множест в а конфигураци й в то й ж е структуре каталогов,
чт о и не авт оматизи рова нн ы е тесты . Систем а управлени я версиям и ил и конфи­
гурациям и дол жн а следит ь з а тем , чтоб ы в кажды й к он к ре т н ы й момен т време­
н и был а а кти в но й т о л ь к о одн а с ан кц и они рова нн а я верси я сценария . Управле­
ни е версиям и обеспечива е т воспроизводимост ь и повторяемост ь каждого тес­
та. П р и воспроизведен и и дефектов , п р и прове рк е исправлени й дефектов , а
такж е пр и вып ол не н и и регрессивног о тестиров ани я очен ь важны м условием
являетс я на ли ч и е единственно г о известног о теста , о ри ен ти р ов а нн о г о н а вы­
явлени е заданног о дефект а .

Что дальше
В это й главе обсуждались п р о е к т и р о в а н и е и разработ к а тестов . Ключевым и пунктами
в процесс е п р о е к т и р о в а н и я и разработ к и тесто в являются :
• Определени е целе й тест а (совершенствовани е подхода к тестирован и ю и уточ­
нени е объем а т е ст и ров ан ия ) .
• Определени е с п е ц и ф и к а ц и й ввода дл я каждого теста .
• Определен и е тес тов о й конфигурац и и дл я каждог о теста .
• Пр о в е р к а п р о е к т н ы х р е ш е н и й тесто в н а предме т обеспечен и я необходимог о
уровн я п о к р ы т и я и техническо й точно ст и .
 Глава 4. Проектирование и разработка тестов 117

• Разработка методики тестирования, обладающей требуемым уровнем дета­

лизации.
• Автоматизация часто используемых тестов, требующих больших затрат
времени.
• Перевод тестовых примеров под управление конфигурациями.
• Определение настройки и очистки тестов с учетом их взаимозависимости.
• Пересмотр методик тестирования.
• Проверка автоматизированных тестов с использованием статических и дина­
мических средств.
В результате выполнения всех этих действий будет получен набор отлаженных
тестовых случаев, который может использоваться для проведения системных испы­
таний. В следующей главе мы рассмотрим, что требуется для прогона тестов, доку­
ментирования выявленных дефектов и составления отчетов по результатам выпол­
нения тестов.
 Системные
испытания
Темы, рассматриваемые в главе:
• Обнаружение и отслеживание дефекто в
• Прого н тесто в
• Составление отчето в по результатам тестировани я
• Критери й выхода из испытаний и готовность
выпуска программного продукта
• Чт о дальше

Для профессионального тестировщиков программного обеспечения стадия систем­

ных испытаний — это то же, что игровой день для футболиста или день спектакля для
театрального актера. Проделана большая работа по планированию, все подготови­
тельные работы завершены, наступило время действовать. Как показано на рис. 5.1,
первое, что нужно сделать, это проверить, все ли на месте и все ли готово. Все эти
мероприятия могут быть дополнены применением критериев входа в системные ис­
пытания, определения которых включаются в план проведения испытаний. Крите­
рий входа в испытания принимает форму опросного листа: составлен ли, пересмот­
рен и утвержден план проведения испытаний? Завершила ли группа разработчиков
запланированное тестирование модулей и проверку взаимодействия и функциониро­
вания компонентов программного продукта? Проведены ли испытания "на герме­
тичность" с целью удостовериться в том, что тестируемая программа может быть ус­
тановлена и, по меньшей мере, способна продемонстрировать открытый экран?
Если достигнуто соответствие критериям вхождения в испытания, тестирование
системы можно начинать. Начало тестирования обычно представляет собой важный
этап графика проектных работ. В идеальном случае задержка системных испытаний
преобразуется в задержку поставки программного продукта, хотя группу тестирова­
ния часто просят отыскать возможности ускорить испытания, чтобы программный
продукт был поставлен во время. Несмотря на риск использования слишком многих
аналогий, добавим еще одну: если сравнить разработку программного продукта с эс­
тафетой, то группа тестирования пробегает последний этап гонки. Если бегуны на
предыдущих этапах проигрывают своим соперникам, то нереально надеяться на то,
что спортсмен, бегущий на последнем этапе, — это супермен, способный наверстать
 Глава 5. Системные испытания 119

ранее упущенное. Реально это или нереально, но на практике ситуация, складываю­

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

Основу тестирования составляет прогон тестов, включенных в план проведения

испытаний. В результате прогона тестов обнаруживаются различные дефекты и вы­
даются сообщения об обнаруженных дефектах. При этом данные, обеспечивающие
возможность отслеживания дефектов, вводятся в специальную базу данных, в кото­
рой хранится информация, предназначенная для отслеживания дефектов. В следую­
щем разделе, "Обнаружение и отслеживание дефектов", эти аспекты тестирования
рассматриваются более подробно.
Во время прогона тестов результаты тестирования должны передаваться другим
подразделениям организации. Все, кто принимает участие в разработке, маркетинге
или в руководстве проектом, должны знать, как продвигается тестирование, сколько
и какие типы дефектов были обнаружены. По окончании тестирования должен быть
подготовлен отчет, в котором подводятся итоги тестирования. В этом отчете должен
использоваться набор критериев для оценки готовности программного продукта к
выпуску. Например, если были выполнены все запланированные тесты, но еще оста­
ется какое-то допустимое число неустраненных дефектов, группа тестирования мо­
жет утверждать, что программный продукт соответствует требованиям, предъявляе­
мым к нему заказчиком, благодаря чему можно начинать поставки.
120 Част ь I . Про ц ес с быстрог о тестировани я

Обнаружение и отслеживание дефектов

Цел ь те с т и р о в а н и я заключает с я в нахождени и д е ф е к т о в . Одна к о недостаточн о толь­
к о отыскат ь д е ф е к т ы . О б и х наличи и должн ы м об р аз о м дол жн ы быт ь оповещен ы
ра зр а бо т чи к и , чтоб ы о н и смогл и эт и д е ф е к т ы устранить , а сведен и я о результатах
выполненны х им и и справ лен и й доводятс я д о з аинте рес ов анн ы х служб с тем , чтобы
графи к разработк и программног о продукта н е нарушался. Любы е неэ ф ф ект ивн ы е
действи я пр и оповеще ни и о дефектах , о б и х от с ле ж ив ан и и , устранен и и и контрол е
приводя т к п о т е р е времени .
В связ и со сказанны м выше , следующие два вида де ятел ьност и считаютс я основ­
ным и пр и выявлени и д е ф е к т о в . Пе рв ы м и з ни х явл я ет с я п р о г о н тесто в в соответст­
ви и с плано м пр о в ед ен и я ис п ыта н и й для в ы ясн ен и я , имеютс я л и какие-либо расхож­
дени я между ожи дае мы м и и фа кт иче с ки м и результатам и тестировани я . Вторы м ви­
дом деятельност и явл яет с я качественн о е документи р ован и е в систем е отслеживани я
де ф ек т о в всех от кл оне н и й , обнаруженн ы х в о врем я тестиров ани я . Хорош е е качество
документац и и важн о по двум причина м — во-первых, раз р аб от ч ик а м нужна достовер­
ная и надежна я и н ф о р м а ц и я дл я того , чтоб ы снят ь все поро ждаемы е неисправностя­
м и проблем ы , и , во-вторых, тестировщи к и дол жн ы им ет ь возможн ос т ь воспроизве­
сти проблем ы , чтоб ы убедиться , чт о внесенны е из ме не н и я устранил и дефект . Систе­
ма, при меняем а я дл я доку ментиров а ни я и отс л е жи в а н и я д е ф ект о в , представляе т со­
бо й важн о е инструм ентал ьн о е средств о те с ти р о в а н и я программн ог о обеспечения .
Нескольк о последующи х раздело в посвящают с я изучени ю систем ы отслеживан и я
дефектов , анализу с ост оян и й де ф е кт ов , из м е не н и ю с ост ояни й д е ф е к т о в и изучению
других важны х аспект о в документирован и я и от сл е жи ва н и я д е ф е к т о в .

Определение состояний дефектов

В главе 1 отмечалось , чт о д е ф е к т о м явл яет с я ошибк а в раб о че м документе, тако м как
техническ и е тре бовани я , пла н пров еден и я ис пытан и й ил и программн ы й код. Дефек т
остаетс я необнаруженны м до те х пор , пока рабочи й продукт не будет подвергнут пе­
ресмотр у или н е будет выполн е н прого н программы , в о врем я которог о программа
выдаст ожидаемы е результаты .
Посл е нахождени я д е ф е к т подвергаетс я анализу с цель ю определения , представ­
ляе т ли он неисправност ь теста , ошибку в программно м коде ил и дефек т в проектны х
спецификациях . Если исто чнико м проблем ы являетс я тест , а не программны й код, то
тес т долже н быт ь исправлен , а обнаруженны й д е ф е к т "проигнорирован" . Проверяет­
с я также , наскольк о с ер ьез е н дефект : принадлежи т л и рассматриваемы й дефек т к
категори и катастрофически х , подлежащи х обязательном у устранени ю пере д постав­
ко й программног о продукта? Являетс я л и возникша я проблем а настольк о серьезной ,
чт о он а существенн о снижае т функциональн ы е в оз м о жн о ст и программног о продук­
та, н о пр и это м все ещ е остаютс я открытым и обходны е пути, позволяющи е продол­
жат ь процесс ы тестирован и я и разработки ? Либ о ж е эт а проблем а н е настольк о кри­
тична , чт о ее ре ше ни е нельз я отложи т ь до будущих выпусков программног о про­
дукта?
Пр ог ра м мн ы й код, содержащи й обнаруженны й дефект , долже н быт ь направлен
разработчика м дл я исп рав лени й . Нужн о внимательн о следит ь з а стадиям и исправле­
ния, чтоб ы н е п о т е р я т ь и з виду сам де ф ек т . Оди н и з э ф ф е к т и в н ы х способ о в отсле-
 Глава 5. Системны е испыт ани я 121

живания де ф е к т а состои т в че тк о м о п р е д е л е н и и явны х с ост ояний , к от ор ы е може т

принимать д ефек т н а пути о т ег о обнару жен и я д о завершающег о т е с ти ров а ни я . Каж­
дое состояни е должн о быт ь недвусмысленны м и обладат ь наборо м о п р е д е л е н и й
критерие в входа и выхода из испытани я .
В таблиц е 5.1 показ а н при ме р оп р ед е ле н и я с остояни й де ф е кт а . Н а з в а н и я состоя­
ний в каждой компан и и могут быт ь свои , возможн ы такж е д о п о л н ит е л ь н ы е состоя­
ния, которы е н е указан ы в это й таблице . В не й показ а н об общенн ы й наб о р названи й
и состояний , который , возможно , ст ои т использоват ь как отправну ю точку п р и соз­
дании систем ы от с ле ж ив а н и я д е ф е к т о в " с нуля".

Отслеживани е дефект а н а п р о т я ж е н и и ег о жизн ен ног о цикла, о т ег о обнаружени я

до устранени я и пров ерк и правильност и исправлени я , показывает , чт о он меняе т
свое состояни е в соотв етств и и с некот оры м наборо м правил . На рис . 5.2 приведе н
пример изменени я состоян и й дефекта . Де ф е к т обнаруживаетс я в о врем я пересмот р а
или в процесс е системны х исп ыт ани й и попадае т в систему отслеживан и я дефектов ,
будучи в состояни и "нов ый " . Ему присваиваетс я уровен ь серьезност и , посл е чег о он
передается на рассмотрен и е в группу анализ а дефектов . Группа анализ а дефект о в
(известная в некоторы х кругах как группа контрол я за внесение м из м е н е н и й в техни­
ческую документацию) определяет , нужно ли исправлят ь де ф е к т в рамка х текущего
выпуска ил и отл ожи т ь э т о до будущих версий . Если группы р а з р а б о т ч и к о в и тести-
ровщиков п р ов е л и дальнейш и й анали з уже посл е того , ка к д е фе к т бы л зафи к си рова н ,
и пришли к закл юч ени ю , чт о в программн ы й код не соде рж и т каких-либо проблем ,
122 Часть I. Процесс быстрого тестирования

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

обращать на него внимания. Действие, предпринятое группой анализа дефектов, до­
кументируется, а сам дефект может находиться в состоянии "исправить", "отложить"
или "игнорировать".
Если принято решение исправлять дефект, то эта работа поручается разработчи­
ку, который вносит соответствующие изменения в программный код и проводит тес­
тирование, дабы удостовериться, что исправленный код работает правильно. Как
только разработчик придет к выводу, что дефект устранен, он меняет состояние де­
фекта на "исправлено" и включает исправленный код в сборку, направляемую на сис­
темные испытания. Если тестировщик убеждается в том, что дефект устранен, то по­
следний переходит в окончательное состояние "исправлено и проверено".
 Глава 5. Системные испытания 123

Если вы не обладаете опытом тестирования или работаете в компании, которая не

использует мощных промышленный средств отслеживания дефектов, возможно, воз-
никнет впечатление, что методология отслеживания дефектов, в основе которой ле­
жит состояние дефекта, чересчур избыточна и громоздка. Если вы занимаетесь раз­
работкой программного продукта, выпуски которого редко когда содержат более 40
или 50 дефектов, то вы, скорее всего, правы. Однако в условиях разработки множест­
ва различных проектов количество дефектов, требующих отслеживания, достигает
многих сотен и даже тысяч. Если система отслеживания неэффективна, или если хо-
тя бы всего лишь несколько заметных серьезных дефектов просочатся в поставляе-
мый программный продукт, руководству вашей испытательной лаборатории пред-
стоят довольно-таки неприятные объяснения с заказчиком.
По причине исключительной важности системы отслеживания дефектов для тес-
тирования программного обеспечения, следующие несколько разделов посвящаются
обсуждению ее базовых характеристик.

Базовые характеристики системы отслеживания дефектов

В момент самого первого столкновения с дефектом необходимо собрать о нем боль
шую порцию информации, чтобы облегчить задачу его последующего устранения
Пример информации о вновь обнаруженном дефекте, которую необходимо записать
в системе отслеживания дефектов, приводится в таблице 5.2. В этой таблице приво-
дится список параметров с кратким описанием каждого параметра и причины необ-
ходимости его регистрации. Если для отслеживания дефектов применяются инстр\
ментальные средства управления базами данных, параметры, представленные в пер
вом столбце, соответствуют полям базы данных.
124 Част ь I. Пр оцес с быс трог о тестировани я
 Глава 5. Системны е испытани я 125

Кажды й де фек т получает в баз е данны х о тс л е жи в ан и я д е ф е к т о в уникальны й

идентификатор , та к называемы й и д е н ти фи к ат о р деф ект а . И д е н т и ф и к а т о р д е ф е к т о в
представляет собо й ключ, к от ор ы й поддерживае т запросы , поступающи е в базу дан­
ных с таки м расчетом , чтоб ы можн о бы л о получить и н ф о рм а ц и ю о ег о состояни и ,
которо е можн о рассматрив ат ь ка к показате л ь продвижени я рабо т п о ег о устранени ю .
В базе данны х отс л е жи в ан и я д е ф е к т о в до лжн ы хранитьс я сведен и я о том , кт о обна­
ружил дефект , когда он бы л обнаружен , уровен ь серь езнос т ь д е ф ект а , а та кж е под­
робное опис ан и е проблем , к от ор ы е о н вызвал. Если д е фе к т бы л обнаруже н в о врем я
системных испытан и й , должн а быт ь записан а и н фо р м а ц и я , касающаяс я теста , кото­
рый выяви л это т дефект . Дл я х о ро ш о документированног о тестовог о случая вполн е
достаточн о запомнит ь т о ль к о и д е н ти фи к ат о р теста . Если тес т н е задокументиров а н
должным образ о м ил и есл и д е фе к т бы л обнаруже н в результат е специализированного
(ad hoc) тести ровани я , необходи м о записат ь ин форм а ц и ю о конфигурац и и средст в
тестирован и я и о специальны х действиях , выполненны х для обнару жен и я этог о де­
фекта. П р и м е р отчет а о д е ф е к т е , к от ор ы й може т использовать с я для целе й докумен­
тировани я , приводит с я дале е в раздел е "Ка к составлят ь сообщени я о дефектах" .
Данны е о деф е кт е , попадающ и е в базу данны х отсл еживан и я д е ф е к т о в , долж н ы
быть изучен ы группой анализ а обнар уженн ы х д е ф е к т о в (ил и группо й контрол я з а
внесением изме не ни й ) с цель ю оп р е д е л е н и я степ е н и с ер ь езн о с т и де ф ек т а . Н а самом
л и деле эт о дефект ? Прави льна я л и ст е п е н ь серьезно ст и был а прис вое н а обнаружен­
ному дефекту? Долже н ли он быт ь устран е н в текущем выпуске п р ог ра мм н ог о продук­
та? И нфор ма ц ия , кот о ра я должн а быт ь внесен а в базу данны х от сл е жи в ан и я дефек­
тов по результатам р абот ы группы анализ а деф е кт о в , показан а в т а бл и ц е 5.3. В ре­
зультате анализ а дефек т перевод ит с я в одн о и з следующих тре х с ос т ояни й :
• Исправит ь (fix) — д е фе к т переход и т в эт о состояние , есл и группа анализ а ре­
шит , чт о данны х д е фе к т долже н бы т ь исправле н в текущем выпуске.
• Отложит ь (defer) — д е фе к т пе ре водит с я в эт о сос тояни е , есл и группа анали з а
реш и т отло жи т ь устранен и е этог о д е ф ек т а д о последующих выпуско в про­
граммног о продукта.
• Игнорироват ь (trash) — д е фе к т пере х од и т в эт о состоян ие , есл и группа анали­
з а решила , чт о дефек т бы л внесе н п о ошибке .
В зависимост и от итоговог о со ст о ян и я дефекта , в базу данны х отслеживан и я де­
фектов вводятс я разли чн ы е данные . На п р и м е р , если дефек т двигаетс я в направле н и и
состояния "исправить" , следует ввест и им я исполнителя , ответственног о з а устране­
ние дефекта . Если и н ф о р м а ц и я относител ь н о дефект а готовитс я для пер еда ч и заказ­
чикам, долже н быт ь введен текс т пояснительн о й записк и по выпуску. Боле е подроб­
ная и н ф о р м а ц и я , касающаяс я анализ а дефектов , будет изложен а в раздел е "Анализ
дефектов".
Как пок аза н о в таблиц е 5.4, окон чате льн ы й набо р данны х нужно вводит ь в систе­
му отслеживани я дефект о в во врем я исправлен и я дефекта . Необходи м о зафи кс ир о ­
вать имя исполнител я , исправляющег о дефект , дату исправлен и я и и д е н т и ф и к а т о р
сборки, в которо й производилос ь исправление . Должн о быт ь дан о подробно е объяс­
нение основно й п р и чи н ы проблемы , чтоб ы группа разработ к и могла воспроизвест и
и устранить проблему.
126 Част ь I. Процесс быстрого тестировани я
Глава 5. Системные испытани я 127
128 Част ь I . Проц ес с быстрог о тестировани я

В таблиц а х с 5.1 по 5.4 дан о кратко е оп и с а н и е некоторы х основны х свойст в , кото­

р ы м и должн а обладат ь систем а о т с л е ж и в а н и я де ф е кт о в . М ож н о п о с т р о и т ь собствен­
но е инструментальн о е средств о отс ле ж ив а н и я де фе к то в , те м н е менее , существуют
ра з ли чн ы е с е ри й н о выпускаемы е инструм ентальн ы е средства, позволяющ и е сэконо­
мит ь массу вре мен и и усилий, к оторы е пришлос ь б ы потрати т ь н а разраб отк у эффек ­
тивно й систем ы отсле жива н и я д е ф е к т о в . Н а б о р возможно ст е й и удобство и простот а
использовани я ваше й систем ы от с л е жи ва н и я д е ф е к т о в существенн о влияе т н а эф­
фе к т и вн ос т ь применяем о й организаци и тестиров ан и я , поэтому выб о р систем ы от­
слеживан и я де ф е к т о в следует пр оиз в од и т ь максимальн о аккуратно .
В следующем раздел е дан о оп и с а ни е форм а т а сообщени я о д е ф е к т е , к от ор ы й хо­
р о ш о вписывает с я в тольк о чт о приведенн у ю общую схему.

Как составлять сообщения о дефектах

Ка жд ы й р аз , когда обнаруживаетс я н ов ы й д е ф ек т , должн о составлятьс я письменно е
сообщен и е о б это м д е ф е к т е . Если и н ф о р м а ц и я о д е ф е к т е н е будет получен а доста­
т о ч н о оп е рат и вн о , могут возникнут ь трудност и пр и восстановлени и обстоятельств ,
кот оры е п ри в е л и к воз ни к нове н и ю пробле м ы . Эт о те м боле е справедливо , есл и при­
ме н я ют с я сп ец и ал изи ров а нн ы е вид ы тести рова ния . Если выполняет с я пр о г о н доку­
менти рован но г о тестовог о случая, т о ег о исход може т быт ь о боз н а че н как неудач­
ный , а о т л и ч и я фа ктичес к и х результато в тест о в о т ожидаем ы х могут быт ь зарегист­
р и ров а н ы как составн а я част ь прогон а теста . Ка к тольк о сп ец и ал изи ров ан н ы й вид
т е ст и р о в а н и я обнаруживае т проблем у ил и как т о ль к о прого н тест а завершен , должно
быт ь составлен о сообщени е о де ф е к т е .
П р и м е р шаблон а сообщен и я о д е ф е к т е показа н н а рис . 5.3. Это т шабло н может
быт ь представле н в ф ор м е пе ч ат но г о бланка , к от ор ы й вручную заполняет с я тести-
ровщиком , в вид е шаблон а ввода данны х в Web-формат е ил и как част ь баз ы данных
систем ы от с ле ж и ва н и я д е ф е к т о в . Т а к о й шабло н сообщени я о д е ф е к т е представляе т
со б о й средств о сбор а тестовы х данны х , кот оры е отображаютс я в табли ц е 5.2.
О т умени я специалисто в п о тестирован и ю составит ь толково е сообщен и е о де­
ф е к т е в значительн о й мер е зависи т успех и х деятельности . Част о время , затрачивае­
мо е тестиро вщи ка м и н а изучени е сооб щен и й о дефектах , которы е был и составлены
и х орган иза ци ям и в о врем я разработ к и аналогичны х проектов , пр и н о си т большую
пользу. В идеально м случае имеетс я набо р "золоты х примеров" , ко то р ы й дае т воз­
можност ь тестировщика м , н е имеющи м дос та точ но г о опыта , получить понимани е
того , чт о тако е высококачественно е сообщен и е о дефект е и каки е ф а к т о р ы делают
тако е сооб щени е н е э ф ф е к т и в н ы м .
Вообщ е говоря , сообщен и е о деф ект е сч ита етс я плох о составленны м ил и неэф­
ф е к т и в н ы м , если :
• О н о составлен о по ошибк е — д е ф е к т , оп и с а н н ы й в сообщени и , не существует.
• Возникша я проблем а представлен а в о п и с ан и и нечетк о ил и неоднознач н о -
проблема , возможно , и существует, но в то же врем я он а описан а настолько
плохо , чт о поведени е систем ы н е ясно .
• О н о н е содер жи т и н ф о р м а ц и и , необходимо й разработчик у для воссоздания
проблем ы — пр изна к и проблем ы описа н ы , н о пр и это м отсутствуют пояснени я
к действиям , которы е послужили п ри ч и н о й воз ни кн ове н и я проб лем ы .
 Глава 5. Системные испытания 129

Правильно составленное сообщение о дефекте обладает совершенно другими

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

Анализ обнаруженных дефектов

Если бы процесс обнаружения и исправления дефектов был совершенным, то необ­
ходимость в анализе дефектов отпала бы сама по себе. К сожалению, человеческий
фактор вступает в действие уже на стадии системных испытаний, впрочем, как и на
других этапах цикла разработки. Ошибки могут неожиданно обнаружиться в тесто­
вых случаях, в конфигурациях средств тестирования или в интерпретации данных
тестирования. Когда обнаружен дефект, необходимо проследить за тем, чтобы свое­
временно был назначен исполнитель, ответственный за его устранение, что обеспе­
чит исправление дефекта и проверку результатов этого исправления.
Один из способов проверки результатов тестирования и предотвращения возник­
новения ошибок при отслеживании дефектов предусматривает еженедельный анализ
дефектов, обнаруженных во время системных испытаний. Назначение анализа де­
фектов состоит в том, чтобы:
130 Часть I. Процесс быстрого тестирования

• Выявить все очень серьезные дефекты, требующие немедленного внимания

• Выявить все дефекты, которые требуют более глубокого исследования или не
могут быть воспроизведены.
• Определить изменения состояний дефектов.
Анализ дефектов проводится не так, как пересмотр программных кодов или дру­
гих рабочих продуктов. В большинстве случаев экономически нецелесообразно вести
учет времени, затраченного исполнителями на подготовку к анализу, к тому же роли
участников не расписаны так же четко, как в случае перепроверки программных ко­
дов и тестовых случаев. Тем не менее, полезно выработать подходящую процедуру
проведения анализа дефектов. Часто в испытательных лабораториях совещания, по­
священные анализу дефектов, проводят ведущие инженеры, при этом дефекты, тре­
бующие анализа, представлены в рамках отчетного доклада, который можно рас­
сматривать как высокоуровневую информацию о дефектах. Пример формата отчет­
ного доклада, посвященного дефектам, показан на рис. 5.4.
 Глава 5. Системные испытания 131

В примере сообщения на рис. 5.4 приводится список всех дефектов с указанием их

идентификаторов, а также содержится информация об их состоянии, степени серь­
езности и дате обнаружения. Дается краткое описание проблем, но если потребуется
подробное описание конкретного дефекта, возникает потребность в первоначальном
сообщении о дефекте. Одним из ключевых полей в отчете является столбец "Дейст­
вие". В поле предполагаемого действия можно определить какое-то значение еще до
того, как будет выполнен анализ, однако основной результат совещания заключается
в определении конкретных состояний, которые должны быть указаны в этом
столбце.
В сообщении, приведенном на рис. 5.4, резервируется место для ввода данных
анализа, для перечисления участников, а также поле "Примечания", которое может
использоваться для документирования обоснования решений, принятых на совеща­
нии. Если по результатам анализа все поля заполняются корректно, итоговый отчет
послужит источником для того, чтобы расписать совещание по минутам.

Прогон тестов
До сих пор основное внимание уделялось дефектам, ибо обнаружение дефектов явля­
ется основной причиной для прогона тестов. Далее мы сосредоточимся на изучении
самого процесса тестирования, следуя обзорной диаграмме, которая показана на рис. 5.1.

Вход в системные испытания

При передаче группе тестирования новой сборки применяется некоторый набор
критериев входа в испытания. Перед началом системных испытаний должен быть
разработан и утвержден план проведения испытаний и тестовые случаи. Группа раз­
работки должна закончить тестирование модулей и проверку взаимодействия и
функционирования компонентов этой сборки. Они должны исправить все катастро­
фические дефекты, обнаруженные во время испытаний, и только затем передавать
сборку группе тестирования.
Первый тест, прогоняемый на новой сборке, — это обычно тест "на герметич­
ность", который служит для проверки возможности установки программы на целевой
платформе, возможности успешного обновления и определения факта работоспо­
собности, по меньшей мере, базовых функций. Причина проведения теста на герме­
тичность довольно проста: если программа не работает на целевой платформе, ее
просто невозможно тестировать.
К сожалению, нередки случаи, когда новая сборка не проходит испытания на гер-
метичность, особенно если перед ее передачей тестировщикам проверка взаимодей­
ствия и функционирования компонентов была выполнена в недостаточных объемах.
Разработчики могли настолько сосредоточиться на том, чтобы заданные функции
'успешно работали в среде разработки, что до проблем системного уровня, таким как,
!скажем, установка программы и ее работа в среде заказчика, просто не доходили
руки.
132 Часть I. Процесс быстрого тестирования

Циклы тестирования
Вход в системное тестирование должно означать начало совместных работ при уча­
стии групп разработчиков и тестировщиков. Тестировщики выполняют прогон за­
планированных тестов, выявляют дефекты и пишут сообщения о дефектах. Разра­
ботчики читают сообщения о дефектах, воспроизводят проблемы и исправляют про­
граммный код. Вопрос заключается вот в чем: как исправления передаются в группу
тестирования?
Ответ на этот вопрос зависит от цикла создания программного обеспечения. Раз­
работчики регистрируют проделанные исправления в системе управления конфигу­
рациями в рамках подготовки к периодическим построениям сборок. Построение
сборки обычно выполняется на базе ежедневного или еженедельного цикла, после
чего блок передается группе тестирования в соответствии с их потребностями.
Возникают различные вопросы относительно того, как часто группа тестирова­
ния может принимать новые сборки. Если сборки приходят слишком часто, устойчи­
вость среды тестирования может оказаться нарушенной — потребуется время на уста­
новку новых сборок, прогон тестов на герметичность и проверку того, что дефекты,
которые были обнаружены в предыдущей версии сборки, исправлены. Если "смесь
сборок" будет излишне "пестрой", то попросту не хватит времени на прогон доста­
точного количества тестов, дабы обеспечить эффективное обнаружение дефектов в
соответствии с выбранной методологией тестирования.
С другой стороны, если сборки поступают слишком медленно, то и в этом случае
нельзя достичь высокой эффективности обнаружения дефектов. Довольно часто из­
менения, вносимые в программный код, приводят к тому, что обнаруживаются новые
дефекты, либо выявляются дефекты, которые и раньше были в сборке, но были за­
маскированы теперь уже устраненными дефектами. Это значит, что включать новые
сборки в цикл тестирования нужно достаточно часто, чтобы можно было обнаружить
следующую партию дефектов.
То, как часто доводится принимать новые сборки от разработчиков, зависит от
нескольких факторов, в том числе и от сложности программного обеспечения, от
численности штата тестировщиков, от процентного отношения автоматизированных
тестов к общему числу тестов. Например, если можно прогнать все тесты в течение
трех дней, вероятно, имеет смысл принимать новые сборки каждые четыре-пять
дней. В этом случае три дня можно отвести на прогон тестов, а день или около того —
на проверку исправлений дефектов, на прогон специализированных тестов в некото­
рых многообещающих областях, на подготовку отчетов об устранении дефектов и на
регулярный анализ дефектов.
В идеальном случае цикл тестирования (test cycle) состоит из прогона полного набо­
ра тестов на некоторой сборке программного обеспечения. План проведения испы­
таний обычно предусматривает выполнение некоторого количества циклов тестиро­
вания, причем на каждый цикл затрачивается определенное время. Например, этот
план может предусматривать выполнение трех или четырех циклов длительностью в
одну или две недели каждый.
На практике тестирование не всегда проводится с соблюдением плана проведения
испытаний. Первый цикл тестирования может продолжаться одну-две недели, однако
может потребоваться большое число сборок, чтобы тестирование оказалось доста­
точно устойчивым и можно было прогнать большую часть тестов. Когда очередная
 Глава 5. Системны е испытани я 133

новая сборк а поступает н а т е с т и р о в а н и е , принимает с я решение , нужно л и выпол­

нить повторны й прого н всех тесто в с самог о начал и или продолжат ь т е с т и р о в а н и е в
прежней последовательност и . О б ы ч н о боле е э ф ф е к т и в н о й оказыва ет с я в ы б о р о ч н а я
проверка н ов о й сборки , к от о ра я дае т возможн ос т ь убедиться в том , чт о е е м ож н о
установить и запустит ь в работу, а обнаруженн ы е ране е де ф е кт ы уже устранен ы . По­
сле этог о т е с т и р о в а н и е продолжает с я бе з п овт о рн о г о прогон а всех тестов . Подходя­
щим момент о м для очередног о запуска т е с ти р о в а н и я може т служить начал о но вог о
тестового цикла. Эт о означает , чт о може т п рои з ой т и так , ч т о н а п ром еж уто чн о й
сборке н е будет выполне н полн ы й набо р тестов . Исключени е м и з эт о й стратег и и яв­
ляется завершающ а я сборк а прогр аммн ог о обеспечени я , та к называе м а я "золот а я
сборка", н а кот ор о й прогон яют с я все тест ы .
Оди н и з способо в от с ле ж и ва н и я тестов , п ро г о н которы х выполне н н а заданно й
сборке, предусматривае т веден и е списк а прогон а тесто в н а сборк е дл я каждо й сборк и
тестируемого програ ммно г о обеспечени я . П р и м е р списк а прогон а тест о в н а сборк е
показан на рис . 5.5. В это м списк е в качест в е заголовк а указан и д е нти фи к ат о р сборк и
и дата прогон а теста ; списо к прогон а тестов , по существу, представля е т соб о й списо к
того, "чт о нужно сделать " каждому специалист у п о тести р о ва ни ю . Если планируетс я
применени е испытательн ы х комплексо в ил и рабочи х станци й коллективног о поль­
зования, это т списо к позволи т избежат ь к он фли кт о в , есл и в нем для каждог о специа­
листа п о тести р о ва н и ю будет указыватьс я исп ытательн ы й комплекс , н а котор о м
должны запускаться тесты . Если ж е возникну т к он фл и к т ы т р е б о в а н и й н а использо ­
вание испытательно г о комплекса , то в таки х случаях може т потребовать с я разработ ­ ка
рабочег о гра фи к а для комплексов . В списк е прогон а тесто в на сборк е оди н стол­ бец
резервируетс я под кратко е изложени е результато в тестировани я .
 134 Часть I. Процесс быстрого тестирования

Список прогона тестов на сборке может оказаться исключительно полезным при

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

Регистрация результатов тестирования

Когда тестировщик получает задание прогнать некоторую последовательность тестов на
конкретной сборке, он должен следовать пошаговой методике тестирования, ого­
воренной в тестовом случае, и протоколировать результаты тестирования. Как видно
из примера тестового случая, приведенного в главе 4 (рис. 4.2), в нем отводится спе­
циальное место, куда тестировщик заносит результаты выполнения каждого шага,
равно как и исход испытания (прошел, не прошел). Кроме того, выделяется также и
место, куда заносится идентификатор любого дефекта, обнаруженного во время ис­
пытаний. Один из способов регистрации результатов прогона тестов предусматрива­
ет использование формата тестового случая, который показан на рис. 4.2.
Другой способ заключается в применении журнала испытаний, изображенного на
рис. 5.6. Этот журнал испытаний удобен для сведения воедино результатов всех тес­
тов, выполненных одним специалистом по тестированию на одной сборке. В нем
также есть место для регистрации общего результата "прошел/не прошел/тест не
выполнялся", а также для идентификатора любого дефекта, обнаруженного во время
прогона теста. Предусматривается также место для комментариев — обычно в нем
протоколируется информация, которая может впоследствии оказаться полезной при
воспроизведении проблемы или для понимания условий, в которых проблема наблю­
далась.
Независимо от того, какой метод будет использоваться для регистрации результа­
тов тестирования, очень важно, чтобы результат каждого теста был зарегистрирован
и сохранен в безопасном архиве. Заархивированные результаты тестирования могут
позже понадобиться в силу различных причин: подтверждение факта проведения
тестирования, поддержка воспроизведения проблемы или хронологические записи,
обосновывающие трудозатраты на разработку программного продукта.
Шаблоны списка прогона тестов на сборке, тестовых случаев и журналов испыта­
ний приводятся в данной книге в форме текстовых документов, тем не менее, их
можно реализовать и как часть системы ввода данных через Web либо инструмен­
тальных средств организации испытаний. Использование автоматизированных
средств для сохранения тестовых случаев, прогона тестов и генерации отчетов по
испытаниям может существенно повысить качество построения эффективной стра­
тегии системных испытаний.
 Глава 5. Системные испытания 135

Составление отчетов по результатам

тестирования
Обычно требуются два вида отчетов по результатам тестирования. Первый из них —
это регулярный доклад о ходе тестирования, который часто делается на еженедель­
ных совещаниях. На таких совещаниях представители всех коллективов, ответствен­
ных за успех проекта, отчитываются о проделанной работе. Доклад о ходе тестиро­
вания обычно состоит из отчета о ходе работ по тестированию и отчетного доклада
об обнаруженных дефектах. Доклад о ходе работ должен дать ответ на вопрос "на­
сколько далеко мы продвинулись в тестировании?". Отчетный доклад об обнаружен­
ных дефектах предназначен для выяснения степени успешности тестовых мероприя­
тий в контексте обнаружения дефектов. Одна из его целей состоит в получении те­
кущей оценки качества тестируемого программного продукта. Эти отчеты рассмат­
риваются в двух следующих разделах.
136 Част ь I. Процесс быстрого тестирования

Второй тип доклада по результатам тестирования представляет собой формаль­

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

Отчет о ходе работ по тестированию

Отчет, показанный на рис. 5.7, дает представление о ходе работ по тестированию. Из
информации о дате, идентификаторе сборки и цикле тестирования видно, какой
программный продукт проходит тестирование и приблизительно насколько прово­
димое тестирование отклоняется от плана. Последний столбец отчета, % Run ("про­
цент прогонов"), есть мера того, сколько прогонов тестов было выполнено относи­
тельно общего количества запланированных тестов. Число тестов, прогон которых
завершился неудачно, указывается в столбце "# Fail" (тест не прошел) — этот показа­
тель дает приближенные данные о том, сколько дефектов будет зафиксировано в
проверяемом программном продукте. Столбец "# Not Run" (тест не выполнялся) по­
казывает, сколько тестов заблокировано по причине неустраненных дефектов или
других проблем. Общее количество тестов приводится в столбце "# Tests", а количе­
ство успешно пройденных тестов - в столбце "# Pass".

Отчет об устранении дефектов

Другим видом анализа положения дел в тестировании является отчет об устранении
дефектов, пример которого представлен на рис. 5.8. В этом отчете показано общее
число неустраненных дефектов как функция от времени в неделях. Временная ось
 Глава 5. Системны е испытани я 137

часто градуируется в датах, а не в "недел я 1", "недел я 2" и т.д. Количест в о деф е кт о в
заданной серь езн о ст и (катастрофически е , крупны е и незначите льн ы е ) в это м отчет е
выглядит как столби к соответствующе й высот ы в выбранно м масштабе , а такж е ука­
зывается явн о в число во й фор м е . На п ри м е р , н а трет ье й и чет ве рт о й недел е тестиро ­
вания в программно м продукт е был о за фи к си рова н о 4 катастрофиче ск и х дефек т а , а
на второ й недел е —32 незначительн ы х дефект а .
Обще е количеств о неустраненны х дефект о в ест ь показател ь качеств а программ­
ного продукта. Вполн е п он ятн о , чт о больш о е коли че ст в о д е ф е к т о в высоког о уровн я
серьезност и не говори т в пользу качеств а програм м но г о продукта. Окончательн ы м
определителе м качеств а программн о г о продукта являе т с я то , наскольк о о н устраива­
ет заказчика . Разумеется, заказчи к вря д ли будет доволен , есл и в предо ставл енн о й ему
версии продукта присутствует слишко м мног о де ф е к т о в . Иногд а имеют с я смягчаю­
щие вину обстоятельства , когда наиболе е важн о й яв ляет с я ск о ро ст ь поставк и про­
дукта, а заказчи к согласе н даж е на верси ю с де ф е кт ам и , лиш ь бы что-то работало .
П о мер е тог о как раб от ы п о тест ир о в ан и ю при бл и жа ют с я к заве р ш ени ю , ест ь все
основания ожидать , чт о числ о неустраненны х д е ф е к т о в будет уменьшаться , посколь­
ку р аз ра б от чи к и исправляю т их, а тестировщи к и пр о в е р я ю т , наскольк о правильн о
были выполнен ы испра вле ни я . Степен ь се р ьез н ос т и д е ф е к т о в п о мер е продвижени я
тестирован и я такж е имее т тенденци ю к снижени ю . П ри м е р , п р ед ста в л ен н ы й н а рис .
5.8, необы че н тем , чт о к о ли ч е ст в о неустраненны х к атастрофичес к и х и крупных де­
фектов остаетс я практическ и н а одно м уровне , в т о врем я ка к числ о незначительны х
дефекто в существенно снижается . Боле е ти пич н ы м случаем являет с я быстр о е устра­
нение дефе кт о в с высоки м уровне м серьезност и , в то врем я ка к мене е с е рь ез н ы е де­
фекты остаютс я н е устраненны м и в т е ч е н и е боле е д лительн ог о времени ; возможн о
даже, чт о их устранен и е откладывает с я до будущих выпусков.
138 Част ь I. Процесс быстрого тестирования

Другой отчет, который часто используется при анализа состояния проекта, — от­
чет об анализе дефектов, представленный в таблице 5.5. Диаграмма на рис. 5.4 доста­
точно точно характеризует ход тестовых работ и служит показателем качества про­
граммного продукта, однако все решения относительно того, исправления каких де­
фектов будут включаться в выпуск, и в каком порядке дефекты будут устраняться,
требуют более подробной информации о неустраненных дефектах. В некоторых
компаниях функции анализа проекта и анализа дефектов объединены, причем оба
вида анализа регулярно ставятся на повестку дня заседаний группы контроля за вне­
сением изменений ССВ (change control board). Как правило, в состав группы ССВ
входят представители руководства, отдела маркетинга, организаций, которые зани­
маются разработкой и тестированием.

Отчетный доклад
В отчетном докладе должны быть отражены следующие моменты:
• Какой программный продукт тестировался
• Насколько фактические работы по тестированию отклонились от плана прове­
дения испытаний
• Насколько график работ и трудозатраты отличаются от соответствующих пока­
зателей в плане проведения испытаний
• Какие дефекты были обнаружены
• Какие дефекты остались неустраненными по завершении тестовых работ и что
с ними делать дальше.
Отчетный доклад по результатам тестирования не обязательно должен содержать
результаты прогона каждого теста, в то же время он может ссылаться на такие ре­
зультаты, если они где-то накапливаются и архивируются. Сбор и архивирование
всех тестовых результатов — это одно из преимуществ, которое дает использование
серийных инструментальных средств управления тестированием. Если это инстру­
ментальное средство сводит результаты тестирования в единый документ, то на этот
документ можно сослаться в отчетном докладе.
Один из способов указать, какой продукт подвергается тестированию, предусмат­
ривает использование набора окончательных вариантов журналов испытаний (рис.
5.6) на каждом цикле испытаний. Этот способ позволяет показывать результаты про­
гона каждого теста без использования пошагового отчета наподобие приведенного
на рис. 4.2 в главе 4. Другой полезный отчет можно получить за счет компиляции
полного набора данных о ходе работ по тестированию (см. рис. 5.7).
Важно понять, насколько фактический процесс тестирования отклоняется от
плана проведения испытаний, поскольку план проведения испытаний представляет
собой утвержденное определение объемов тестирования и соглашение о том, сколь­
ко сотрудников принимают участие в этих работах, и сколько времени будет затраче­
но на выполнение работ. Особенно важно отметить, какие области не были охвачены
тестированием в полном объеме, поскольку эти области являются источниками рис­
ков снижения качества программного продукта и источниками распространения де­
фектов в различные части продукта. Если тестирование проходит в соответствии с
планом, этот факт можно просто отметить в отчетном докладе; если имеют место
 Глава 5. Системные испытания 139

заметные отклонения от плана, необходимо отметить их в специальном заявлении.

Эта информация полезна при учете затраченных ресурсов, и в то же самое время
служит исходными данными для дальнейшего планирования. Если производится сбор
представительных статистических данных для сравнения запланированных и факти­
ческих трудозатрат, то она благоприятствует возможности повышения точности бу­
дущих оценок.
Несмотря на то что база данных отслеживания дефектов должна содержать пол­
ный набор данных о дефектах, обнаруженных во время тестирования программного
продукта, сводку дефектов, обнаруженных во время системных испытаний, целесо­
образно включить в отчетный доклад. В таком случае всем сторонам, заинтересован­
ным в успехе разработки, не потребуется обращаться в базу данных дефектов за све­
дениями о ходе работ по тестированию и о качестве программного продукта. Окон­
чательная версия отчета по результатам анализа дефектов (рис. 5.4), в котором пока­
заны все обнаруженные дефекты и их окончательные состояния, а также оконча­
тельная редакция отчета о категориях неустраненных дефектов (рис. 5.8) являются
полезными дополнениями отчетного доклада о тестировании.
Отчетный доклад о результатах тестирования должен содержать список всех не-
устраненных дефектов с указанием того, будут ли они исправлены в более поздних
выпусках или же их исправление откладывается на неопределенное время. Дальней­
шие выпуски программного продукта все еще будут содержать неустраненные дефек­
ты до тех пор, пока они не будут исправлены. В силу этого обстоятельства желательно
вести за такими дефектами наблюдение, чтобы не тратить дополнительные усилия на
их выявление в будущих выпусках продукта. В плане проведения испытаний будущих
выпусков должны присутствовать ссылки на список неустраненных дефектов; это
позволит тестировщикам понять, что их ожидает во время тестирования нового вы­
пуска программного продукта.
Пример отчетного доклада о результатах тестирования, котором реализованы все
идеи из этого раздела, включен в третью часть книги.

Критерий выхода из испытаний и готовность

выпуска программного продукта
Существует множество способов определить подходящий момент для останова испы­
таний, одни из них простые, другие же — очень сложные. Вот некоторые из условий,
которые используются для принятия решения о прекращении испытаний:
• Время, отведенное на тестирование, истекло. Если зафиксирован некоторый
предельный срок, неизбежно наступает день, когда вы просто прекращаете все
работы, связанные с тестированием, и задаете себе вопрос: "Насколько плох
программный продукт?". Любой другой метод останова придает гораздо боль­
шую уверенность в качестве поставляемого программного продукта.
• Завершены все запланированные циклы тестирования. Если план проведе­
ния испытаний предусматривает три цикла, то в конце третьего цикла вы, по-
видимому, зададите тот же вопрос: "Насколько плох программный продукт?"
Если план проведения испытаний выполнен, то тестовое покрытие, скорее
140 Част ь I . Про ц ес с быстрог о тестировани я

всего , будет лучше, че м в случае, когда прост о не хватил о времен и для доведе­
н и я т е с т и р о в а н и я д о конца .
• Пр оф ил ь дефекто в соответствуе т критери ю выход а и з испытаний. Если в
результат е вып олн е н и я алгоритм а SWEEP (Software Erro r Estimatio n Pr og ra m -
Прог ра мм а оц ен к и ошибочност и программн о г о продукта) становит с я ясно,
чт о предел , т.е. коли чест в о неустраненны х ошибо к н а тысячу стро к программ­
ног о кода, достигнут, появляют с я все основани я пр е к рат и т ь тестировани е .
(Под робн у ю и н ф ор м а ц и ю по алгоритм у SWEEP можн о найт и в главе 11.) В по­
до бн о й ситуаци и опять-таки придет с я задатьс я вопросом : "Наскольк о плох
прог ра ммны й продукт?"

Пр ин им а я ре ш е н и е пр е к р а т и т ь работ ы п о тес т и р о в а н и ю , следует учесть несколь­

к о фа к т оро в , к от ор ы е играю т важную р о л ь пр и оц ен к е готовност и программног о
продукта к поставкам . О б ы ч н ы м наборо м факт оров , кот оры е определяю т готовност ь
програм мно г о продукта к поставкам , являются :
• Количест в о катастрофическ и х д е ф ект о в , обнару женн ы х в процесс е тестиро ­
вания , к от ор ы е остаютс я неиспра влен ны м и
• Общ е е к о ли ч е ст в о дефе ктов , кот ор ы е н е был и исправлен ы
• П р оц е н т н о е от н ош ен и е количест в а тестов , к от ор ы е завершилис ь успешным
исходом , к числу всех запланированн ы х тест о в
• Количест в о тестов , прого н которы х н е може т быт ь выполнен , поскольку они
заблоки рован ы деф е кт ам и .
С цель ю в ы ра б от к и оц е н к и готовност и выпуска о тл а ж енн о г о прогр аммног о про­
дукта провод ят с я специальн ы е совещания . В некот оры х организаци я х оценку готов­
ност и опр ед е ля е т группа тестировани я ; в других орг анизаци я х совещани е проводи т
руководител ь проект а л и б о руководител ь разработки . В любо м случае в задачу группы
т е ст и р о в а н и я входи т пре дставлен и е результато в т е с т и р о в а н и я и выраб от к а реко­
мендаци й от н о с и т е л ь н о готовност и продукта к поставкам . Хот я оценк а готовност и
може т проводитьс я ф о рм ал ьн о , подобн о тому, как выполняетс я инспекци я про­
граммног о кода, в любо м случае потребуетс я з а ф и к с и р о в а т ь имен а участнико в и при­
нят о е им и решение , касающеес я поставо к программног о продукта. Чтоб ы оценк а
готовност и содер жал а результаты и рекомендац и и организаци и , проводивше й тес­
тировани е , эт а оц ен к а должн а содержат ь ссылку н а о тчетн ы й доклад п о результатам
тестировани я .

Что дальше
В это й главе мы обсуждали вопрос ы отслеживан и я дефектов , проведени я системны х
исп ыт ан и й и составлен и я отч ет о в п о результатам тестиро ван ия . Рассматривалис ь
следующие ключевы е моменты :
• Об з о р системны х испытани й
• Обнаружени е и отслеживани е дефекто в
• Опред ел ен и е состояни я дефект о в
• О с н ов н ы е особен нос т и от сл е жи в ан и я де ф е к т о в
 Глава 5. Системные испытания 141

• Составление сообщений о дефектах

• Анализ дефектов
• Прогон системных тестов
• Вход в системные испытания
• Циклы тестирования
• Регистрация результатов прогона тестов
• Отчетность по результатам тестирования
• Отчет о ходе выполнения тестовых работ
• Отчет по результатам тестирования
• Критерии выхода из испытаний и оценка готовности
Необходимыми условиями для проведения системных испытаний являются план
проведения испытаний в его окончательном виде, набор готовых к прогону тестовых
случаев и отлаженный испытательный комплекс в требуемой конфигурации. Резуль­
тат выполнения тестовых работ представляет собой совокупность результатов тести­
рования, которые позволяют руководству проекта и коллективу разработчиков выра­
ботать оценку готовности программного продукта к выпуску.
В первых пяти главах книги даны определения множества процессов, которые ох­
ватывают тестирование программного обеспечения от этапа выявления требований
до завершения системных испытаний. Если вы впервые сталкиваетесь с тестирова­
нием или пытаетесь открыть новую испытательную лабораторию, трудно будет реа­
лизовать все эти процессы сразу; их необходимо разворачивать постепенно, как часть
долгосрочной программы совершенствования процессов. В следующей главе будет
показано, как построить интегрированный процесс тестирования, воспользовавшись
подходом долгосрочного совершенствования.
 Вопросы объединения
процессов
тестирования и
кадрового обеспечения
Темы, рассматриваемые в главе:
• Человечески й факто р и тестировани е
• Совершенствование процесса тестировани я
• Чт о дальше

В главе 1 мы говорили о быстром тестировании как о структуре, построенной на ос­

нове следующих факторов:
• Исполнители
• Интегрированный процесс тестирования
• Статическое тестирование
• Динамическое тестирование.
До сих пор основное внимание уделялось второму строительному блоку структу­
ры, а именно, процессу комплексных испытаний. Одна из причин повышенного вни­
мания этому процессу связана с тем, что независимо от квалификации исполнителей,
если они не имеют в своем распоряжении систематической, упорядоченной методи­
ки тестирования, то не смогут работать с максимальной отдачей. В первой части дан­
ной главы мы перенесем акцент на изучение человеческого фактора при тестирова­
нии. Следует отметить, что исследованию проблем, привносимым человеческим
фактором в разработку программного обеспечения, посвящено немало книг, одной
из которых является [41]. В своей книге Peopleware (Кадровое обеспечение) [14], которая
стала классикой, Демарко (DeMarco) и Листер (Lister) рассматривают проблему че­
ловеческого фактора с точки зрения его влияния на разработку программных про­
дуктов. В первой части данной главы будут обозначены наиболее важные аспекты
этой темы, которые могут содействовать успеху тестовых работ, но в равной степени
могут стать основной причиной их неудачи.
Несмотря на то что многие аспекты процесса отладки уже были обсуждены, при­
дется затронуть еще один вопрос. В конце главы 5 отмечалось, что весь процесс тес­
тирования нельзя кардинально перестроить. Совершенствование процесса тестиро-
 Глава 6. Вопросы объединения процессов тестирования... 143

вания должно быть планомерным процессом, разбитым на отдельные этапы. Вторая

часть этой главы представляет собой обзор мероприятий, направленных на совер­
шенствование процесса отладки.
Статическое и динамическое тестирование образуют третий и четвертый строи­
тельные блоки рациональной и эффективной методики тестирования. Эти две тех­
нологии тестирования основательно обсуждались во второй и третьей главах, а более
подробное их исследование будет продолжено в главах 9 и 10.

Человеческий фактор и тестирование

Барри Боем (Barry Boehm) в [21] утверждает, что личные качества исполнителей и
отношения, установившиеся в коллективе, представляют собой резерв для повыше­
ния эффективности программного обеспечения. Другими словами, человеческий
фактор оказывает гораздо большее влияние на эффективность программного обес­
печения, чем любой другой отдельно взятый фактор. Боем доказывает это утвержде­
ние, применяя инструментальное средство СОСОМО для оценки трудозатрат сис­
темного аналитика и программиста, при этом производительность каждого из них
изменялась в 4 раза. Как показывает опыт, накопленный авторами, именно такой
разброс производительности возможен во время выполнения тестовых работ, при
разработке тестов и даже при прогоне тестов (т.е. при обнаружении дефектов). Если
есть намерения выявить фактор, оказывающий максимальное влияние на способ­
ность вашего коллектива выполнять тестирование программных продуктов быстро и
эффективно, в этом плане потребуется подвергнуть исследованиям в первую очередь
деловые и личные качества членов группы тестирования.
В этом разделе мы покажем, какими качествами должен обладать тестировщик,
дабы успешно справляться со своими обязанностями, Затем мы составим список
ошибок, приводящих к снижению эффективности работ по тестированию, которые
могут допускать тестировщики. Кроме того, будет рассмотрен ряд технологий опро­
са, ориентированных на специалистов по тестированию.

Качества, которыми должен обладать специалист по

тестированию, чтобы успешно справляться со своими
обязанностями
Среди тестировщиков есть яркие представители, которые могут служить истинными
примерами специалиста по тестированию программного обеспечения. Однако более
привычным является вариант высококвалифицированной группы, которую состав­
ляют специалисты, обладающие различными навыками. В этом разделе будет состав­
лен список качеств, которыми должен обладать идеальный тестировщик. Следует
отдавать себе отчет, что в то время, как ни один человек не может быть носителем
всех необходимых качеств, группа тестирования, будучи единым целым, может во­
площать максимально возможное количество требуемых качеств. В основу этого спи­
ска положен опыт и наблюдения, но отнюдь не достоверные данные научных иссле­
дований; возможно, возникнет желание нарисовать собственный портрет идеального
тестировщика, воспользовавшись предлагаемым списком в качестве отправной точ­
ки. На наш взгляд, идеальный тестировщик:
144 Часть I. Процесс быстрого тестирования

• Должен уметь разрушать программные продукты, не чувствуя при этом никаких

угрызений совести. Поскольку тестирование выполняется с целью обнаруже­
ния дефектов, тестировщик не должен испытывать дискомфорта, обнаруживая
ошибки в работе другого исполнителя.
• Должен уметь разрабатывать и выполнять пошаговые процедуры.
• Должен уметь описывать последовательность событий и конфигурацию систе­
мы, которые приводят к возникновению проблемы. Это включает способность
четко документировать процедуры и результаты, умение устно передать ин­
формацию разработчикам, другим тестировщикам и руководству.
• Уметь критиковать и корректно воспринимать критику (например, умение так
объяснить разработчикам суть дефектов, что с его слов их можно устранить).
• Обладать способностью приносить разработчикам и руководству плохие ново­
сти. Если в одиннадцать вечера выясняется, что не удается достичь готовности
выпуска программного продукта, тестировщик должен быть готов сообщить
руководству эту печальную новость.
• Уметь противостоять неослабевающему давлению (тестирование всегда явля­
ется завершающей стадией любого процесса разработки и, как правило, проте­
кает в стрессовых обстоятельствах).
• Обладать незаурядными умственными способностями, т.е. легко и быстро ос­
ваивать новые технологии.
• Быть терпеливым — быть готовым выполнять прогоны тестов столько раз,
сколько нужно для того, чтобы снять проблему, после чего повторно выпол­
нить тесты, чтобы убедиться в корректном устранении проблемы. (Между про­
чим, существенную помощь в этом случае оказывает именно автоматизация!)
• Обладать гибким мышлением — быть способным быстро переключиться на тес­
тирование нового программного продукта или даже отказаться от испытания
одного продукта в пользу другого, обладающего более высоким приоритетом.
• Обладать способностью одновременно видеть общую панораму и уметь при не­
обходимости сосредоточиться на деталях; иметь широкий и динамичный кру­
гозор.
• Быть экспертом в нескольких областях — группе тестирования могут потребо­
ваться специалисты по базам данных, по коммуникациям, по сетевым техноло­
гиям, по тестированию GUI-интерфейсов, по инструментальным средствам
тестирования, по сценариям автоматизации, а также специалисты из других
областей.
Этот перечень достоинств высококвалифицированного тестировщика может с
пользой применяться при приеме людей на работу и при оценке кандидатов на ту или
иную должность. Если вы формируете коллектив для работы над новым проектом,
рекомендуется подбирать людей таким образом, чтобы они соответствовали, по воз­
можности, максимальному числу требований, фигурирующих в приведенном выше
списке. Более подробную информацию о создании производственных коллективов
можно найти в [14] и [33].
 Глава 6 . Вопро с ы о бъ един ен и я процессо в тестирования... 145

Характерные ошибки
Если бы все группы те с ти р о в а н и я проявлял и качества , упомянутые в предыдущем
разделе, пробле м п р и про в еден и и испытан и й был о б ы зн а чит е ль н о меньше . Однак о
лишь немноги е коллектив ы тестировщико в в то й ил и ино й мер е п р иб ли ж а ю т с я к
идеалу, в связ и с че м имее т смысл проанализироват ь наиболе е ра спрост ран ен н ы е
ошибки, которы е допускают тестировщи к и и к от ор ы е ведут к снижен и ю эффе к тив ­
ности усилий, затр а чи в а ем ы х н а т е сти р ов а ни е . Иногд а до стато чн о простог о предос­
тережени я в адре с па ртне р о в по работ е (ил и самому себе ) о возможност и таки х оши­
бок и форм и ров а н и я стратеги и совместног о устранен и я последстви й эти х ошибок .
Вот списо к некоторы х классически х ошибок , допускаемы х тестировщиками :
• Пр едположение , что программа работае т корректно . Т ест и р о в щ и к всегда
долже н предполагать , чт о программ а раб ота е т некорректно. Его обязанност и за­
ключаютс я в том , чтоб ы отыскат ь т е момент ы , кот оры е програм м а вып олн яе т
неправильно, а н е т о , чт о он а делае т правильн о . Л юбо е отклонен и е о т ожидае­
мого результата, вне зависимост и о т ег о значимост и , должн о рассматриватьс я
как потенциальн ы й призн а к де ф ек т а . Н ез ав и си м о о т того , наскольк о преду­
предительн ы м и компетентн ы м може т быт ь програм мист , вы не должн ы отда­
вать сво и симпати и этому программист у в ситуаци и , когда возникаю т подозре ­
ни я о налич и и дефект а .
• Нежелани е регистрироват ь каж ду ю обнаруженну ю проблему. Подобны е си­
туации част о возникаю т в о врем я прогон а п род ол жит ельн о г о теста . В ы сталки­
ваетес ь с некот оро й незначительн о й про бл е мо й , однак о двигаете с ь дальше ,
надеяс ь н а то , чт о запомнил и до стато чн о сведени й , даб ы зафикс ироват ь и х
позже . Когда эт о "позже " наступает, в ы либ о забывает е о б это й проблеме , л иб о
н е может е восп роизвес т и действи я , которы е к не й приводят . Х о р ош и й спосо б
не допускать таки е ошибк и состои т в ведени и специальног о журнала записей , в
которо м фиксир уют с я незначительн ы е отк л он ен и я о т нормы , даж е те , кото­
р ы е н а первы й взгляд н е имею т отн о ше н и я к тестировани ю . Если вести точны е
записи , то в конц е тест а можн о вернуться к обнаруженно й проблем е и провес­
т и специальны е исследовани я с целью опр еделит ь , дефек т л и эт о н а самом
деле.
• Игнорировани е или даж е сокрыти е проблемы. Эт а ошибк а являетс я частны м
случаем двух первы х видов ошибок . Он а чр ева т а весьма пагубными последст­
виями . В это м случае известно , чт о програ ммн ы й продукт содержи т дефект ,
однак о почему-то принимаетс я ре ше ни е игнори ров а т ь его. Возможно , чт о в
следующей сборк е этог о дефект а н е будет. Возможно , чт о о н н е играе т никако й
роли . Возможно , п о пр и чин е огр ан и че н и й в о времен и проведени е исследова­
ни й дефект а невозможно . Така я ошибк а може т привест и к тяжки м последстви­
ям , в то м числе и вызват ь проса чиван и е де фект а в среду заказчика . Всегда сле­
дует помнить , чт о любо й обнаруженны й д е фе к т може т скрыват ь з а собо й це­
лы й ря д других, скрыты х дефектов , если тольк о последовательн о н е бор отьс я с
тем и из них, которы е находятся на виду.
• В ы позволяет е разработчик ам уговорит ь с е б я н е составлять сообщ ен и й о
дефекта х или игнорироват ь имеющиес я соо б щ ен и я о дефектах , н е име я н а
т о достаточны х оснований. Не т ничег о предосудительног о в том , чтоб ы пого-
146 Часть I. Процесс быстрого тестирования

ворить с разработчиком и позволить ему убедить себя в том, что дефект при­
сутствует в самом тесте, или же в том, что конфигурация тестовых средств не
соответствует вероятной среде заказчика. Однако прежде чем принимать ре­
шение игнорировать тот или иной дефект, следует быть уверенным в правиль­
ности этого решения. В случае малейших сомнений относительно желания
разработчика отказаться от регистрации дефекта или игнорировать то или
иное сообщение о дефекте, нужно обсудить логику его рассуждений с коллегой-
тестировщиком или с другим разработчиком.
• Стремление не обострять отношения с разработчиком. Этот вид ошибки
имеет отношение к предыдущему типу, в то же время формы ее проявления мо­
гут быть другими. Если вы находите ошибку в чьей-то работе, это значит, что
дефект засел в программном продукте, выпускаемом вашей компанией, и вся
группа тестирования только выигрывает от того, что об этом ей стало извест­
но, ибо чем раньше дефект будет устранен, тем лучше. Одним из достоинств
эффективной системы отслеживания дефектов и еженедельных анализов де­
фектов является то, что они позволяют избегать конфликтов между людьми.
Личные обиды, которые возникают, когда кто-то находит недостатки в чужой
работе, можно сгладить, если профессионально применять соответствующие
инструментальные средства и процедуры анализа дефектов.
• Недостаточное внимание, которое уделяется планированию испытаний. Ес­
ли ваш процесс не поддерживается планированием испытаний, то элементарно
может случиться так, что у вас останется слишком мало времени на подготовку
к тестированию следующей сборки. Может также иметь место спешка при
оценке затрат времени и ресурсов, необходимых для выполнения конкретной
тестовой задачи. Планы, составляемые в спешке, обычно приводят к возникно­
вению больших проблем при проведении испытаний.
• Написание пространных отчетов о несуществующих проблемах. Подобный
вид бездарной траты времени находится на противоположном конце спектра по
отношению к большинству рассмотренных выше ошибок. Вам спустили сверху
квоту на отлов дефектов? Оценка вашего труда как-то связана с количе­ ством
обнаруженных дефектов? Если это так, то иногда трудно устоять перед
искушением представить в качестве дефектов несуществующие проблемы. По­
иск дефекта в программе, которая работает в соответствии с замыслом, требует
больших непроизводительных затрата времени. Вы не только понапрасну тра­
тите время на формулирование проблемы, вы отнимете время разработчиков и
руководства проектом, которое они вынуждены будут отдать отслеживанию не­
существующего дефекта и попыткам воспроизвести проблему. Тестировщики
должны неукоснительно фиксировать каждую реальную проблему, с которой
они сталкиваются, но ни а коем случае не поддаваться соблазну фиксировать те
проблемы, которые, по их убеждению, будут проигнорированы. Если более
10% дефектов, обнаруженных конкретным тестировщиком, попадают в число
несуществующих и будут игнорироваться, то этот тестировщик либо намеренно
купился на эту уловку, либо ему явно не хватает знания деталей тестируемой
программной системы.
 Глава 6. Вопросы объединения процессов тестирования... 147

Как проводить опросы претендентов

Одним из способов формирования дееспособной группы тестирования является на­
ем квалифицированных тестировщиков. И хотя подробное обсуждение стратегий и
технологий опроса выходит за рамки данной книги, мы дадим краткую характери­
стику технологий опроса, ориентированных на специалистов по тестированию, ко­
торые, по мнению авторов данной книги, обеспечивают неплохие результаты. Все
они представляют собой простые идеи, основанные на здравом смысле, однако если
ранее ими пользоваться не доводилось, возможно, информация, полученная благода­
ря применению этих технологий, вызовет некоторое удивление.
• Выясните, каким опытом работы в тестировании обладает кандидат. Участ­
вовал ли он когда-либо в составлении планов проведения испытаний? Если это
так, то какая информация учитывалась в этом плане? Приходилось ли ему ото­
бражать тестовые случаи на технические требования? Пользовался ли они
формальной системой отслеживания дефектов? Несколько вопросов с после­
дующим их обсуждением позволяют достаточно быстро дать оценку опыта ра­
боты кандидата с процессами тестирования.
• Если кандидат претендует на квалификацию в некоторой предметной об­
ласти, спросите его, как он применял знания этой предметной области во
время тестирования программного продукта. Легко освоить технический
сленг и рассуждать о предметных областях, однако толковое объяснение того,
как кандидат разрабатывал сценарии автоматизации или конфигурировал ло­
кальную сеть или как использовал различные инструментальные средства, по­
зволяют дать оценку его знаниям конкретных технологий.
• Задайте вопросы, которые могут продемонстрировать, обладает ли канди­
дат перечисленными выше качествами, которые необходимы для того, что­
бы успешно справиться со своими обязанностями. Обычно вопросы, подоб­
ные "Достаточно ли вы умны для выполнения такой-то работы?" или "Доста­
точно ли вы терпеливы, чтобы выполнять обязанности, на которые претендуе­
те?", едва ли дадут нужную информацию. Разумеется, можно предложить кан­
дидату рассказать о предыдущей работе в других местах; такой рассказ может
пролить свет на некоторые из этих качеств. Например, можно поинтересо­
ваться: "Приходилось ли вам менять проектные приоритеты в тех случаях, ко­
гда требовалось немедленно перейти от тестирования продукта А к тестирова­
нию продукта В? Если да, то как это все происходило? Были ли у вас какие-либо
затруднения при изучении технологии, связанной с продуктом В? С учетом
приобретенного опыта, что у вас получилось хорошо? Что бы вы хотели изме­
нить?" Если для формирующейся группы тестирования подыскивается работ­
ник, обладающий одним или несколькими из перечисленных выше качеств,
стоит заблаговременно подготовить набор вопросов для выяснения области
интересов кандидата.
• Если вы хотите нанять работника, отвечающего конкретным требованиям,
можно предложить ему составить план действий в гипотетической ситуа­
ции и проанализировать предложенное им решение. Например, если требу­
ется исполнитель, умеющий составлять планы проведения испытаний и тесто­
вые случаи для некоторого специального вида программного продукта, можно
148 Часть I. Процесс быстрого тестирования

разработать простой набор технических требований и спросить кандидата, ка­

кими видами тестов он воспользуется. Пребывая в поисках нужного решения
вместе с кандидатом и делая при необходимости наброски на бумаге или устно
обсуждая различные детали проблемы, следует получить представление о том,
насколько хорошо кандидат справляется с задачей написания тестов.
• Дайте оценку того, насколько кандидат склонен совершать перечисленные
выше классические ошибки, создав ему соответствующие ситуации и про­
анализировав его ответы. Например, можно поставить кандидата в ситуацию,
когда на группу тестирования оказывается давление с целью сокращения сро­
ков тестирования. Далее неплохо было бы задать ему приблизительно такие
вопросы. Откажетесь ли вы от плана проведения испытаний в пользу проведе­
ния специализированного тестирования? Будете ли регистрировать проблемы,
с которыми столкнетесь в процессе прогона тестов, или же только факты ус­
пешного или неудачного исхода? Удосужитесь ли вы потратить некоторое вре­
мя на составление плана, указывающего, прогон каких тестов будет выполнять­
ся на завершающей сборке программного продукта, либо же сломя голову при­
ступите к прогону тестов в надежде все завершить до того, как прозвенит за­
вершающий звонок? Какие решения принимались в прошлом в аналогичных
ситуациях?.. Можно предложить и другие ситуации, которые предполагают
конфликт с разработчиками, или в которых требуется принять решение, если
вдруг возникает подозрение, что коллега сообщает о несуществующих дефектах
и проблемах.

В этом разделе затрагивается лишь несколько аспектов, имеющих отношение к

кадровому обеспечению процесса тестирования. В то же время, несмотря на крат­
кость изложения, нам удалось коснуться трех из пяти базовых принципов кадрового
обеспечения, сформулированных Боемом (Boehm) [21]:
• Профессиональная пригодность
• Распределение работ в соответствии с квалификацией
• Продвижение по службе
• Пропорциональное распределение ресурсов внутри группы тестирования
• Постепенное сворачивание работ (с устранением несоответствий).
Принцип подбора кадров по профессиональной пригодности отражен в приве­
денном выше списке качеств идеального специалиста по тестированию. В этом спи­
ске также отражаются вопросы распределения работ в соответствии с квалификаци­
ей и пропорционального распределения ресурсов внутри группы тестирования. Не
следует забывать о том, что ни один исполнитель не может обладать всеми профес­
сиональными качествами, которые требуются от группы тестировщиков, в связи с
чем кадровый состав группы тестирования должен быть сбалансирован так, чтобы
покрывать все требования, предъявляемые к квалификации кадрового состава
группы.
Принцип постепенного сворачивания работ предусматривает освобождение от
обязанностей исполнителей, не способных внести положительный личный вклад в
деятельность группы тестирования. Примером отрицательного вклада может слу­
жить ситуация, когда исполнитель своими действиями вносит такой беспорядок в
 Глава 6. Вопрос ы объ един ен и я пр оцесс о в тестирования.. . 149

работу группы, чт о за тр а ч ив а ем ы е на ег о устранен и е усилия приводя т к существен­

ному снижен и ю про изв о ди те ль но с т и группы в целом . По-видимому, таки е исполни­
тели совершаю т н ек оторы е ошибки , о которы х ре ч ь шла выш е . Ск оре е всего , он и н е
обладают качествам и , кот оры е нужн ы специалист у п о т е ст и р о в а н и ю , даб ы успешн о
справлятьс я с о своим и обязанностям и .
П р и н ц и п продвижени я п о служебно й лестниц е играе т важную р о л ь в тестирова ­
нии программног о обеспечения . Человек , которог о принима ю т на работ у в группу
тестирования , долже н знать , кака я служебная карьер а ег о ожидает . Все больш е е чис­
ло компани й и специалисто в рассматрива ю т т ест и р о ва н и е как впол н е подходящую
перспективу для служебного прод вижен ия , в рамка х к о т о р о г о от ры в а ют с я возмож­
ности совер шенств ов ан и я в тех ни ч ес к и х областя х и пр ио б р ет а ет с я опы т руководя­
щей раб от ы . Тестирован и е прог р а мм но г о обеспеч ен и я — эт о удачно е мест о для изу­
чения производст в а программны х продукто в н а системно м уровне . Поскольк у он о
затрагивае т все аспект ы продукци и комп ании , он о може т служить хор ош е й старто ­
вой позицие й для дальнейш е й к а р ь е р ы разработчи ка , а такж е специалист а п о сопро­
вождению продукта н а площадка х заказчика , п о техн иче ск о й поддержк е пользовате ­
лей ил и п о техническо м у маркетингу .

Совершенствование процесса тестирования

Э ффе к т и в н ы й и отл а ж ен н ы й процес с т е с т и р о в а н и я нельз я получит ь в одночасье .
Требуются месяцы , и даж е годы плани ров ан и я и нап ряж ен н о й раб от ы , чтоб ы создат ь
хорошо функционирующу ю организаци ю , способную выполнят ь ра б от ы п о тестиро ­
ванию. П р и любо й попыт к е усовершенствоват ь установившийс я процес с тестирова ­ ния
с самог о ег о основани я нужно п ри н я т ь во внимани е следующие мом ен т ы :
• Тести рова н и е н е може т быт ь изолирован н ы м процессом . Т е с ти ров ан и е про­
граммног о об е сп е ч ен и я мо же т быт ь э ф фе к т и в н ы м то льк о то м случае, есл и он о
интегри рова н о в ж и з н е н н ы й цикл раз р аб от к и прогр аммног о обе спечен и я . Эт о
означает , чт о попытк и усовершенствова т ь сам процес с дадут мало пользы , по­
скольку совершенствовани е процесс а тестирован и я должн о выполнятьс я в
рамка х более масштабных и всеобъемлющи х работ .
• Э ф ф е к т и в н ы й процес с тестиров ан и я може т быт ь создан тольк о з а с ч е т ег о по­
ст р ое н и я п о стадиям. Существует нескольк о функциональн ы х стади й ил и уров­
не й любог о процесс а разработки . Эт и уровни могут быт ь представлен ы моде­
лям и развития , к которы м относятся : модель СММ (Capability Maturit y Mode l —
модель развити я функциональн ы х возможностей ) программног о обеспечени я ,
разработанн а я институто м технолог и и программног о обеспечен и я SEI (Soft­
ware Engineerin g Institute) , модел ь ТМ М (Test Maturity Mode l — модел ь развити я
тестовы х возможностей) , разработанн а я Иллинойски м технологически м ин­
ститутом, и модель ТМ М (Test Process Impr ove me n t — модель совершенствова ­
ни я процесс а тестир овани я) . Перехо д с одног о уровня модел и р аз вит и я на дру­
гой долже н происходит ь упорядоченн о . Н и одна организац и я н е може т перей ­
т и с нижнег о уровня разви т и я сразу н а верхни й з а сче т адаптаци и всего лиш ь
нескольки х процедур ил и инструментальны х средств; продви жен и е должн о
происходит ь постепенн о , уровен ь за уровнем, и без каких-либо пропусков .
150 Часть I. Процесс быстрого тестирования

• Успешное совершенствование процесса затрагивает людей, которые с ним свя­

заны. Организация процесса того или иного процесса — это далеко не академи­
ческое или техническое мероприятие; она требует от персонала внести опре­
деленные коррективы в свои рабочие обязанности и заставляет руководство
пересмотреть свои взгляды на то, что можно ожидать от подчиненных. Для то­
го чтобы любая инициатива, касающаяся улучшения процесса, оказалась ус­
пешной, в ее реализацию должны вносить посильный вклад все службы компа­
нии, от высшего руководства до исполнителей, занимающихся прогоном тес­
тов в испытательной лаборатории. Как только процесс будет определен, пер­
сонал, которому надлежит его использовать, должен пройти специальную под­
готовку, дабы достичь необходимого уровня согласованности и производи­
тельности.
Первый пункт, утверждающий, что процесс тестирования не является независи­
мым, очевиден на протяжении всего жизненного цикла разработки. В качестве при­
мера взаимной функциональной зависимости рассмотрим процесс выявления и фор­
мулирования технических требований. Как уже говорилось в предыдущих главах,
тестирование должно начинаться с проверки формулировок требований. Формули­
рование требований представляет собой широкую межфункциональную деятель­
ность, в которой принимают участие представители руководства высшего уровня,
групп маркетинга, разработчиков, производителей и поддержки на стороне заказчи­
ка. Представители других групп, кроме группы маркетинга, могут не принимать уча­
стие в прямом обмене данными с заказчиком; в то же время совершенно ясно, что
сформулированные требования оказывают влияние на работу всей группы разработ­
ки программного продукта.
Вторая особенность, связанная с тем, что эффективный процесс может строиться
только постепенно, от стадии к стадии, рассматривается ниже, в контексте модели
развития функциональных возможностей. Мы не будем исследовать все уровни и
ключевые области процесса тестирования сквозь призму модели СММ, тем не менее,
сосредоточимся на тех областях СММ, которые имеют отношение к принципам про­
цессам тестирования, которые рассматриваются в данной книге. Упомянутые выше
модели развития подробно рассматриваются в [19], [41], [38] и [29].
Третий пункт показывает, каким путем достигается совершенствование процесса
тестирования. Исследованию этих вопросов посвящена завершающая часть данной
главы.

Модель развития функциональных возможностей

программного обеспечения СММ
Институт технологий программного обеспечения SEI (Software Engineering
Institute) — это проектно-исследовательская организация, основанная в 1984 году Ми­
нистерством обороны США и финансируемая федеральным правительством США.
Она поддерживается университетом Карнеги-Меллон. Информацию, касающуюся
института SEI и модели СММ, можно получить на Web-сайте института SEI по адресу:
www. sei. сmu. edu.
Модель развития функциональных возможностей является основой, которая мо­
жет использоваться для получения оценки, в какой степени заданная организация
 Глава 6. Вопросы объединения процессов тестирования... 151

способна изготовлять программное обеспечение. Она классифицирует процесс раз­

работки программного обеспечения по пяти уровням развития: начальный, повто­
ряемый, определяемый, управляемый и оптимизирующий. Краткие характеристики
каждого из этих уровней приводятся в таблице 6.1.
Характеристики, перечисленные в таблице 6.1, описывают ключевые свойства
уровней 1-5. Уровень детализации, предложенный в таблице 6.1, намеренно выбран
низким. Подобный выбор обусловлен необходимостью дать общее представление об
организациях, находящихся на каждом из пяти уровней. Например, организация,
расположенная на уровне 1 модели СММ, т.е. на начальном уровне, разрабатывает
программное обеспечение с использованием неопределенных и непланируемых про­
цессов. Скорее всего, эта организация не способна соблюдать сроки разработки, об­
наруживать и устранять все дефекты программного продукта перед его выпуском и
укладываться в рамки сметной стоимости. Организации, достигшие уровня 2 модели
СММ, вложили существенные средства в совершенствование реализуемых ими про­
цессов, и во время планирования, оценки и составления календарных планов руково­
дствуются четкими принципами управления ходом проектирования, тем самым дос­
тигая поставленных целей. Можно вполне рассчитывать на то, что организации вто­
рого уровня, по сравнению с организациями первого уровня, лучше справляются с
задачами соблюдения срока разработки, обнаружения и исправления дефектов, рав­
но как и более точно управляют окончательной стоимостью проекта.
По сравнению с хаосом, присутствующим на уровне 1, уровень 3 привносит суще­
ственные улучшения. На уровне 3, т.е. на определяемом уровне, тестирующая органи­
зация, скорее всего, реализует большую часть методов, обсуждаемых в данной книге,
а именно: управление требованиями, достоверные оценки, составление графиков
работ, управление конфигурациями, а также инспекции и пересмотры. Согласно мо­
дели СММ, определяемый уровень представляет собой высокий уровень эффектив­
ности организации, однако управление процессом осуществляется скорее на основе
качественных, а не количественных оценок. На этом уровне все еще не установлены
надежные системы измерений, пригодные для оценки качества программного про­
дукта или эффективности процесса.
Два последних уровня модели СММ предусматривают плановые и текущие изме­
рения качества продукта и эффективности процесса. Основные различия между
уровнями 4 и 5 заключаются в том, что основное внимание на уровне 5 уделяется не
качеству программного продукта, а эффективности процессов. Продвижение к уров­
ню 5 означает, что организация собрала достаточное количество данных, позволяю­
щих ей воспользоваться средствами настройки своих процессов на достижение оп­
тимальной эффективности. Одним из ключевых свойств уровней 4 и 5 является при­
менение метрик тестирования. Использование упомянутых метрик подробно обсуж­
дается в главе 11.
В дополнение к описанию пяти уровней функционального развития организаций,
занимающихся разработкой программного обеспечения, модель СММ определяет 18
областей обработки, распределенных по всем пяти уровням. Области КРА (Key Proc­
ess Areas— ключевые области обработки) для заданного уровня функционального
развития суть полностью действующие процессы, которые в любой момент времени
должны находиться в полной функциональной готовности. Они направлены на то,
чтобы организация могла претендовать на соответствующий уровень.
152 Част ь I. Процесс быстрого тестирования
 Глава 6. Вопросы объединения процессов тестирования... 153

Например, названиями областей КРА для уровня 2 [38] являются:

• Управление требованиями
• Планирование проекта программного обеспечения
• Контроль и отслеживание разработки проекта программного обеспечения
• Управление договорами с субподрядчиками на разработку программного обес­
печения
• Обеспечение качества программного обеспечения
• Управление конфигурацией программного обеспечения.
Подробное описание областей КРА мы оставляем на публикации, посвященные
моделям СММ. В то же время может оказаться полезным концептуальное отображе­
ние областей КРА уровня 2 на процессы тестирования, описание которых было дано
в предыдущих главах настоящей книги. Попытка такого отображения предпринима­
ется в следующем разделе.

Как модель СММ соотносится с быстрым тестированием

Путь от уровня 1 к уровню 2 в соответствии с моделью СММ лежит через реализацию
областей КРА, список которых можно найти в предыдущем разделе. Первым рас­
сматривается процесс управления требованиями. Роль, которую играет группа тестиро­
вания в управлении техническими требованиями, была главной темой главы 2. В этой
главе отмечалось, что группа тестирования должна получить доступ к точным специ­
фикациям требований на ранних этапах разработки программного продукта, чтобы
иметь основу для составления плана проведения испытаний и для проектирования
тестов. Были приведены аргументы в пользу участия группы тестирования в процессе
формулирования технических требований за счет выполнения статического тести­
рования требований на предмет полноты, непротиворечивости, осуществимости и
контролепригодности. Кроме того, была также обоснована необходимость использо­
вания матрицы прослеживаесмости требований с целью отображения каждого тре­
бования на тесты, отдельные компоненты проекта и на программные коды.
В главе 8 приводится описание процесса JAR, представляющего собой методоло­
гию выявления требований, которая в полной мере интегрирует статическое тести­
рование и процесс формулирования требований. Интегрирование статического тес­
тирования с определением и прослеживанием требований на этапах планирования
154 Часть I. Процесс быстрого тестирования

испытаний и разработки тестовых случаев— это базовые принципы, которыми сле­

дует руководствоваться при определении роли группы тестирования в управлении
требованиями.
Вторая область КРА, согласно модели СММ принадлежащая уровню 2, — это пла­
нирование проекта. Применительно к организациям, занимающимся тестированием,
эта область охватывает оценку трудозатрат, разработку графиков работ и планов
проведения испытаний. Составление плана проведения испытаний и оценка трудоза­
трат достаточно подробно рассматривались в главе 3, а вот дополнительная инфор­
мация по технологиям оценки трудозатрат содержится в главе 12. Пример плана про­
ведения испытаний представлен в главе 14. В результате обсуждения вопросов, свя­
занных с планированием испытаний, был сделан вывод, что к основным видам дея­
тельности, которые составляют процесс планирования испытаний, относятся:
• Определение стратегии тестирования
• Определение состава испытательного комплекса (программные и аппаратные
средства)
• Оценка трудозатрат (трудовые ресурсы и графики работ)
• Оценка рисков срыва графиков работ и подготовка плана смягчение последст­
вий от овеществления рисков
• Подготовка и пересмотр документов, содержащих план проведения испы­
таний.
В то время как очередность, в которой организация рассматривает области КРА,
зависит от локальных условий, есть все основания сначала решать вопросы управле-
ния требованиями, а после этого переходить к планированию проекта. Причина
очень проста — в основе этого плана лежат требования. По мере изменения требова­
ний, план должен модифицироваться, дабы соответствовать произведенным изме­
нениям.
Третьей областью КРА в модели СММ является контроль и отслеживание разработки
проекта программного обеспечения. Для группы тестирования это означает, что инфор­
мация о ходе тестирования и ожидаемом качестве продукта в том виде, в каком она
представлена в сообщениях о дефектах, должна в любой момент быть доступной ру­
ководству. Эти вопросы рассматривались в главе 5 при обсуждении отчета о ходе ра­
бот по тестированию и отчета об обнаруженных дефектах. Если быть точным, то но­
вейшая информация доводится до сведения заинтересованных лиц на еженедельных
(а в критических ситуациях, ежедневных) совещаниях. Если эта информация пере­
сылается на внутренний Web-сайт, то действия группы тестирования должны соот-
ветствовать предназначению этой области КРА. Поскольку для отслеживания проек­
та должен существовать план, вполне очевидно, что эта область КРА зависит от кор-
ректного выполнения КРА, предусмотренного планированием проекта.
Область КРА, именуемая управлением договорами с субподрядчиками на разработку про-
граммного обеспечения, до сих пор еще не рассматривалась. Тем не менее, она может
иметь очень важное значение для групп тестирования, которые используют услуги
субподрядчиков во время выполнения различных видов тестовых работ: при состав­
лении планов проведения испытаний, при разработке тестов и/ил и при прогоне
тестов. Нередки случаи, когда одна или большее число географически удаленных
групп заключают договор на выполнение определенной части работ по тестирова-
 Глава 6. Вопросы объединения процессов тестирования... 155

нию. Необходимо отметить три соображения относительно привлечения субподряд­

чиков. Во-первых, они могут привлекаться к сотрудничеству с целью оценки трудоза­
трат и планирования испытаний на начальной стадии проекта. Желательно, чтобы
они принимали активное участие в работах по оценке и планированию. Во-вторых,
все ожидаемые результаты планов должны быть включены в договор, который согла­
сован и утвержден всеми заинтересованными сторонами. Наконец, задача контроля и
отслеживания разработки проекта должна включать работу субподрядчиков.
Пятой областью КРА, которая фигурирует в списке для уровня 2 модели СММ, яв­
ляется обеспечение качества. Основной функцией поддержки качества на уровне 2 яв­
ляется текущий контроль разработки программного продукта с тем, чтобы обеспе­
чить строгое соблюдение требований процесса и получить оценку качества про-
граммного продукта. Группа обеспечения качества служит для руководства своего
рода окном, позволяющим получить представление о том, как создается проект.
Группа обеспечения качества не должна зависеть от разработки и управления в том
смысле, что она должна обеспечить независимый, объективный взгляд на положение
вещей. Под "независимым" понимается тот факт, что группа обеспечения качества
предоставляет отчеты руководству отдельно от группы разработки. И хотя группу
тестирования могут попросить выступать в роли группы обеспечения качества, в
рамках данной книги подобная роль не предполагается ни в одном из процессов. Все
виды тестовой деятельности, такие как формальные инспекции и неформальные пе­
репроверки, в данном случае рассматриваются как составные части статического тес­
тирования.
Последней областью КРА в списке для уровня 2 модели СММ является управление
конфигурацией. Основное назначение управления конфигурацией состоит в размеще­
нии избранных рабочих продуктов в безопасном хранилище, которое контролирует­
ся механизмом управления версиями. Естественно, под управление конфигурациями
должны подпадать документы с техническими требованиями, проектные документы
и программные коды. В перспективе тестирования план проведения испытаний, тес­
товые случаи и результаты тестирования (включая сообщения о дефектах) так же
передаются под управление конфигурациями. Мы обсуждали это в главах 3, 4 и 5,
равно как и напоминали о том, что инструментальное средство управления тестиро­
ванием является хорошим вкладом для решения конкретных задач управления кон­
фигурацией силами группы тестирования.

Возможности совершенствования процессов

Независимо от того, используется ли в качестве базы совершенствования процессов
модель СММ, или принят какой-то другой подход, для решения задачи совершенст­
вования процессов обычно применяется систематизированный и упорядоченный
подход, который предусматривает выполнение следующих действий:
• Оценка состояния текущего процесса. Первое, что следует предпринять, так
это определить, где вы находитесь по отношению к принятой базовой структу­
ре. Для получения оценки можно привлечь консультантов извне, которые
прошли специальную подготовку и способны дать оценку организации в кон­
тексте модели развития функциональных возможностей, подобной СММ. С
другой стороны, внутреннюю оценку можно провести в форме послепроектно-
го обзора, который часто предназначен не только для праздничного подведе-
156 Част ь I . П р о ц е с с бы ст рог о тестировани я

ни я итог о в ок он ч а н и я проекта , н о и для того , чтоб ы определить , чт о сделано

хорошо , а чт о должн о совершенствоваться . Об е оце нк и , внутрення я и внеш­
няя , требую т полн о й поддержк и с о сторон ы верхнег о эшелон а руководства ор­
ганизаци и и участи я специалистов , которы м надлеж и т внедрит ь предлагаем ы е
изм е не ни я и пользоватьс я им и в дальнейше м .
• Определени е областей , требующи х совершенствования . П о результатам
оценк и текущего процесс а долже н быт ь составле н списо к ег о областей , в кото­
р ы х необходи м о провест и усовершенст вовани я . П р и это м важн о определит ь их
п р и о р и т е т ы и зафиксирова т ь это т порядо к в соответствующ и х планах. По­ пытк
и внест и изменени я сразу во все област и этог о списк а част о приводя т к
глубоким разочаров ан и ям .
• Планировани е рабо т п о совершенствовани ю процессо в . Необходи м о при­
влеч ь к п лани ров ан и ю специалистов , занимающихс я внедрени е м усовершенст­
вований , чт о позволи т учесть их пр е дл о ж ен и я и заручитьс я их поддержкой .
Та ко й пла н долже н предусматриват ь внедрени е средст в измере ни я степен и
продвижени я по направлени ю к целя м с о в ер ш ен ст в о ва н и я процесса . В контек­
ст е модел и р а з в ит и я функциональн ы х возмо жносте й , эт а мер а продвижени я к
цел и п о п р о ш е с т в и и 1 2 ил и 1 8 месяце в мож е т п ри н я т ь форм у другой формаль­
но й оцен ки , с промежуточным и контрольным и точками , позволяющим и от­
слеживат ь д в и ж е н и е вперед .
• Внедр ени е изменени й и мониторин г и х эфф ективност и . Посл е создания
плана, внедрен и я всех ег о пунктов, получени я отдач и и выяснени я корректи в
следует всяческ и сохранят ь дви ж ен и е вперед , установи в ег о в качеств е основ­
ног о курса разв ити я .
Дл я с ов е р ше нс тв о в ан и я процесс а необходим о время . На перехо д с уровн я 1 на
уровен ь 2 у крупны х организаци й уходит от двух до тре х лет . Продвижен и е неболь­
ших организаци й може т оказатьс я боле е быстры м (анали з совершенствован и я не­
больших проект о в и орг ан и зац и й можн о найт и в [38]) .

Что дальше
Данна я глава завершае т первую часть, посвященну ю подходу к тестирован и ю про­
граммного обеспечени я , на которы й мы ссылаемс я как на быстро е тестировани е . Бы­
стро е тестир ован и е ест ь структура, построенн а я н а основе :
• Персона л а
• Ин т ег р и р о в а н н о г о процесс а тестирован и я
• Статическог о тест иро ва ни я
• Динамическог о тестировани я .
В это й главе мы обсуждали кадровы й аспек т тестиров ан и я и проблем ы совершен­
ствовани я самого процесс а тестировани я . Касаем о персонал а был представле н спи­
сок качеств , к от о ры м и долже н обладать специалис т п о тестировани ю , перечислен ы
ошибки , к от о р ы е част о допускают тестиро вщи к и , и дан ы совет ы п о интервьюирова­
ни ю потенциальн ы х работников . Все эт о являет с я предпос ылка м и создани я сбалан­
сированно й группы тестирова ни я .
 Глава 6. Вопросы объединения процессов тестирования... 157

Выше отмечалось, что какой бы высокой квалификацией ни обладали специали­

сты, если в их распоряжении не будет систематизированного и упорядоченного про­
цесса тестирования, они не смогут работать с максимальной отдачей. Мы сформули­
ровали три базовых принципа, которые следует иметь в виду, реализуя свои стремле­
ния усовершенствовать процесс тестирования:
• Тестирование не может быть независимым процессом.
• Эффективный процесс тестирования может быть построен только постепенно,
стадия за стадией.
• Чтобы совершенствование процесса привело к успеху, необходимо учитывать
мнение конечных исполнителей.
В качестве примера пошагового подхода к совершенствованию процесса приво­
дилась модель СММ программного обеспечения, разработанная институтом SEI. При
этом некоторые ключевые области обработки были отображены на тестирование.
В следующей части книги предлагаются хорошо зарекомендовавшие себя на прак­
тике советы, технологии и примеры, которыми можно воспользоваться для повыше­
ния эффективности тестирования. Однако, как мы убедились на базе материала этой
главы, процесс разработки программного обеспечения не поддается быстрым изме­
нениям. Практически воплощая идеи, изложенные в первых двух частях книги, на­
верняка возникнет желание воспользоваться плановым пошаговым подходом к со­
вершенствованию. При этом изменения в первую очередь будут вноситься в те части
процесса, которые обеспечат наибольший эффект. Примеры организации ключевых
тестовых работ можно найти в третьей части книги.
 Технологии быстрого
тестирования и советы
 Введение
в технологии
тестирования
и советы
Темы, рассматриваемые в главе:
• Область применения технологий тестирования
• Жизненны й цикл разработки
• Преимущества быстрого тестирования
• Определение статического тестирования
• Определение динамического тестирования
• Жизненны й цикл дефект а
• Формальные этапы тестировани я
• Обязанности членов команды тестирования
• Чт о дальше

Область применения технологий тестирования

Для более наглядного представления области применения технологий тестирования
в таблице 7.1 приводится список технологий, которые используются при разработке
тестовых задач. Некоторые из них являются статическими, другие — динамическими
технологиями тестирования. Но можно ли с первого взгляда определить, к какой ка­
тегории относится та или иная технология? Хотя этот список явно неполон, он при­
зван убедить, что при использовании только нескольких из этих технологий в проек­
те могут быть допущены программные ошибки, которые легко могли бы быть обна­
ружены в случае применения одной из других технологий.
В следующих пяти главах приведены описания этих терминов, цели применения
технологий и примеры использования части из них в проектах. Чтобы читателям
было легче решить, когда следует применять те или иные технологии, в некоторых
главах рассматриваются примеры, взятые из реальной жизни или построенные на
основе опыта авторов.
 Глава 7. Введение в технологии тестирования и советы 161

Жизненный цикл разработки

Диаграмма шарнирно-каскадной модели, представленная на рис. 7.1, помогает по­
нять, когда следует применять статическое тестирование, а когда — динамическое
тестирование. Эта диаграмма шарнирно-каскадной модели не противоречит приве­
денной в конце главы 1, хотя рис. 7.1 и содержит несколько дополнительных аббре­
виатур, которые представляют основные термины, используемые в этой и последую­
щих главах. Документация, служащая основой для проведения комплексных, систем­
ных и приемосдаточных испытаний, создается, соответственно, на этапах рабочего
проектирования, эскизного проектирования и разработки технического задания.
Данная взаимозависимость показана двунаправленными стрелками, и именно на этих
этапах некоторые проекты испытаний начинают давать сбои. Если код не удовлетво­
ряет требованиям технического задания, причиной программных ошибок могут по­
служить следующие три обстоятельства:
• Технические требования были изменены, но это не было отражено в доку­
ментации
• Один из случаев тестирования, сценариев тестирования или результатов испы­
таний содержал ошибку, которая привела к ложному обнаружению отказа
• Код содержит программную ошибку
162 Часть II. Технологии быстрого тестирования и советы

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

средствами статического тестирования. Эти ошибки возникают вследствие несоблю­
дения жизненного цикла разработки. Персонал, выполняющий быстрое тестирова­
ние на ранних этапах разработки программного обеспечения (от разработки техни­
ческого задания до написания кода), обеспечит наилучшую гарантию предотвраще­
ния подобных неудач в процессе тестирования.
В качестве общего правила можно утверждать следующее: технологии динамиче­
ского тестирования должны применяться разработчиками программного обеспече­
ния, начиная с проверки вновь созданного кода на этапе тестирования кода и моду­
лей (ТКМ) или раньше, если предполагалось создание прототипа. Технологии стати­
ческого тестирования применяются как на этапе разработки, так и на этапе тести­
рования.
Во время разработки некоторых проектов тестировщики не приступают к работе
до тех пор, пока не будет завершен этап тестирования кода и модулей (ТКМ) и пока
полностью не будет написан исходный код. Фактически, иногда тестировщики начи­
нают свою деятельность лишь после частичного завершения этапа комплексных ис­
пытаний (КИ). Если в вашей организации используется именно такой поход, значит,
в ней не исповедуется философия быстрого тестирования. Если специалисты по тес­
тированию не участвуют в разработке планов испытаний, случаев тестирования, сце­
нариев тестирования, не занимаются анализом результатов тестирования и статиче­
ским тестированием документации до и во время этапа ТКМ, стоит задуматься о на­
прасных потерях времени разработки, которые вызваны необходимостью устране­
ния ошибок, допущенных на ранних этапах жизненного цикла разработки программ­
ного обеспечения. Кое-кто полагает, что источником всех ошибок является исходный
код. Это совершенно неверно. Например, ошибки, допущенные на этапе разработки
технического задания (ТЗ), могут вылиться в месяцы напряженной работы над архи­
тектурными интерфейсами, низкоуровневого проектирования, создания кода и на-
 Глава 7. Введен и е в технологи и тестировани я и со вет ы 163

писания документации . И л иш ь пото м ста н е т ясно , чт о полу ченн ы й результа т — вовс е

"не то , чт о на м требовалось " ил и чт о "эт о выполняетс я н е так , как на м требовалось" .
М ы част о упрекае м команду р а з р а б о т к и техническо г о задания , н о кт о и з е е персонал а
способен обнаружит ь подобны е ошиб к и и избежат ь и х н а этап е р а з р а б о т к и ТЗ ? При ­
ходится лиш ь стыдиться , чт о ни к т о и з тестировщико в н е принима л участи я в р аб от а х
этого этап а и , соответстве нн о , попрост у н е мог обнаружит ь и устранит ь таки е ошиб­
ки прост ы м зачеркивани е м ил и отправ ко й лист а бумаги в корзину . Скольк о денеж­
ных средст в расходуется на прасн о т ол ь к о потому, чт о тести ровщи к и не участвуют в
ранних этапа х жиз не нн ог о цикл а разработки ? В главе 8 рассматривает с я технолог и я
статическог о тестировани я , получивш а я названи е со вместн о й р а з р а б о т к и требова­
ний к при лож ени ю (joint applicatio n re q u i re m e n t s , JAR) , к от о р а я служит пример о м
следования ф и л о с о ф и и быстрог о те стиров ани я , т.е. того , как необходим о сочетат ь
выработку техничес ки х т р е б о в а н и й с и х тщательн ы м те сти р о ва ни е м .
Н а ра н ни х этапа х жизн ен ног о цикл а для описани я того , чт о пр едп о л о жит е ль н о
должно выполнят ь программн о е о б е с п е ч е н и е (т.е. треб ов ани я) , используютс я слов а
обычног о языка . Эт и слов е сн ы е оп и с а ни я превращаютс я в п р ед ст ав л ен н ы е в т о й ил и
иной гра фиче ско й фо р м е архитектурн ы е диаграммы . Подсистем ы и подблок и опре­
деляются соответствующим и оп и сат е ль ны м и ф р аг ме нта м и Т З . В ход е дальнейшег о
жизненног о цикл а р а з р а б о т к и пот ок и оп е ра ц и й и данны х о пи сы в а ют с я другим и гра­
фически м и форм а ми . Эт о ж е касает с я и табли ц , описывающи х имен а и от н ош ен и я ,
которы е будут положен ы в основу ба з данны х и запросов . Посл е того , как логик а про­
граммы полност ь ю опреде лен а , для пров ер к и полно т ы о т р а ж е н и я програ ммис та м и
всех возможны х ситуаци й част о используютс я диаграмм ы с остояни й . О ш и б к и вно­
сятся в о врем я каждог о таког о преобразов ан и я и з одног о язык а оп и с ан и я задач и в
другой. Задаче й тестировщик о в являет с я обнаружен и е ошибо к подобног о рода .
Страт ег и и р аз ра бо т к и тестовы х случаев естественн ы м об раз о м делятс я н а дв е ка­
тегории , в зависимо ст и о т того , с че м тестировщик у приходит с я име т ь дело :

1. Тестирован и е "черног о ящика". Если извест н ы конкретны е функци и , кото­

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

2. Тестировани е "белог о ящика". Если известн ы особенност и внутренне й ра­

бот ы продукта, можн о выполнит ь тесты , подтверждающие , чт о внутрення я
работ а продукта происходи т в с оотв етс тв и и со с п е ц и ф и к а ц и е й , а все внут­
р е н н и е компонен т ы используютс я правильн о . Те рм и н "белы й ящ и к " означа­
ет, чт о пр и разработ к е тес тов ы х случаев тестировщи к и использую т любы е
доступны е сведени я о внутренне й структуре ил и коде. Технологии , приме­
няемы е в о врем я тестиро ван и я "белог о ящика" , обычн о называю т техноло ­
гиям и статическог о тестир овани я , и многи е из них исследуются в главе 9.
Н а поздни х этапа х ж изне н ног о цикл а программног о обеспечени я , к от ор ы е пред­
ставлены право й половин о й шарнирно-каскадн о й модели, ско мп и ли р ов ан н ы й про­
граммный код используетс я для управл ен и я компьютерн о й системо й , п е ри фе ри й н ы -
164 Част ь II. Технологи и быст рог о тестирован и я и сов ет ы

ми устройствам и и подсист ема м и обмен а данным и с цель ю реализац и и всех функций,

кот оры е задокум ентиро ва н ы как требования . П р и это м должн ы удовлетворятьс я все
архитектурн ы е и п р ое к т н ы е с п е ц и фи к а ц и и . Ч а ст о и м е нн о н а эт о м эт ап е приложени е
запускается п е р в ы й ра з и мож е т быт ь подвергнут о и спытани я м п о производительно ­
сти , совместимост и с неск ольк и м и платформами , применим ост и , пригодност и к ус­
тановк е и другим ф орм а м и технологи я м динами чес ко г о т е с т и р о в а н и я из рассмот­
ренны х в главе 10. Т е п е р ь все подсистем ы и подблоки , о п и с а н н ы е в архитектурн о й и
прое ктн о й документ ации , реализ ов ан ы и скрыт ы внутр и ко м п ь ю т е р н о г о кода.

Преимущества быстрого тестирования

Многи е технолог и и быстр ог о т ест и ро в ан и я могут применятьс я н а ран ни х этапах
жизн ен н ог о цикл а р а з р а б о т к и програ ммно г о обесп ечени я , ка к то ль к о становятся
известн ы т е х н и ч е с к и е тре бов ани я . В т о ж е время , к он к ретн ы е в ариант ы эти х техно­
логи й статическог о т е с т и р о в а н и я част о повт о р я ют с я н а боле е поздни х этапа х жиз­
ненног о цикл а (глава 8 посвящен а технологи и быстрог о т е ст и р о в а н и я н а этап е опре­
делен и я техничес ки х т ребов а н и й ) . Естественн о , воз никае т вопрос : " Н е связан о л и
привлечен и е специалист о в п о тести р о ва н и ю н а ра н ни х этапа х жиз не н ног о цикла
ра зр а бо т к и с увеличени е м затрат?" . Н а рис . 7.2 показан а модел ь оце н к и стоимост и
р а з р а б о т к и п р ог ра м мн ог о о б е с п е ч е н и я (исследования м э т о й модел и оц е н к и стоимо­
ст и программн о г о о б е с п е ч е н и я посвящает с я глава 12), кот о р а я наиболе е т о ч н о со­
гласуется с эк спе рим ента л ьны м и данным и п о с оотн ошен и ю зат ра т дл я случаев обыч­
ног о и быстрог о т е ст ирова н и я . Сумма значени й трудозатра т (в пр оц ент а х ) , приве­
денны х в табли ц е слев а о т этог о рисунка, превы шае т 100%. Сумма трудозатра т этапо в
ра зр а бо тк и , а и м е н н о — Э П , РП , ТК М и К И , составляе т 100%, и на диаграмм е эти
суммарны е трудозатрат ы представлен ы областью , ра с пол оженн о й ниж е кри во й "раз­
работ к а — трудозатраты" . Т ра д и ц и о н н о пр и это м трудозатрат ы н а разработ к у Т З н е
учитываются , поскольк у ра зр аб от к а Т З должн а быт ь завершен а д о того , как можно
будет планироват ь трудозатра т ы этапо в разработки . З н а ч е н и е трудозатрат , плани­
руемых для этап а р азраб от к и Т З , составляе т 8 % для быс тр ог о тестиров ан и я проти в
7 % для обычног о те сти р о в ан и я , приче м эт о зна чени е рассчитывает с я п о отношени ю
к трудозатрата м , представленны м область ю под криво й "ра зра бот к а — трудозатраты" .
В структуре трудозатра т на разработк у программног о обеспечени я традиционн о
п р и н я т о такж е н е учитыва т ь тр удозатрат ы в течени е первог о года посл е поступления
продукта н а р ы н о к (иногд а это т эта п называю т этапо м эксплуатаци и и сопровожде­
ни я (ЭиС)) . Планируем ы е трудозатра т ы этог о этап а составляю т 10 % для быстрог о
тестиров ан и я и 1 5 % дл я о бычно г о тестир ован и я (в пр о це нт а х от обще й суммы тру­
доза тра т н а разработку) .
О бр а ти т е вн и м а ни е , ч т о хот я н а диаграмм е этап ы ра зработ к и дл я случаев быстро­
г о и об ы ч н о г о т е с т и р о в а н и я совпадают , и з секторно й диаграмм ы видно , чт о общая
сумма тр удозатра т п р и исп ользован и и технологи и бы стр ог о тестиров ан и я составля­
е т 56,25 % о т обще й суммы трудозатра т в случае п р и м е н е н и я обычног о тестировани я
( 3 6 %/ 6 4 % ) . Поскольк у трудозатрат ы на разработк у прое кт о в с применени е м быст­
р ог о тестиров ан и я меньш е тр удозатра т н а разработк у прое кт о в с применение м
обычног о тестирован и я , врем я поставк и программны х продукто в н а р ын о к также
существенно сокращается .
 Глава 7. Введение в технологии тестирования и советы 165

Представьте себя в качестве руководителя разработки проекта с использованием

технологии быстрого тестирования. Вы ведете беседу с руководителем проекта, в
котором применяется обычное тестирование. Вы: "Время разработки и объем трудо­
затрат моего нового проекта примерно в два раза меньше времени и трудозатрат,
требуемых на создание программного продукта примерно такого же объема." Руково­
дитель другого проекта: "Ха, готов поспорить, что качество вашего продукта никуда
не годно." Вы: "На самом деле, как это ни странно, в программе оказалось всего около
одной трети скрытых ошибок, из числа допущенных в предыдущем проекте анало­
гичного объема." Руководитель другого проекта: "Во имя всех святых, но как вы этого
добиваетесь?" Вы: "Мы применяем технологию быстрого тестирования с первого до
последнего дня разработки, параллельно и в комплексе с самой разработкой. И это
действительно окупается. Мы перехватываем контракты у конкурентов, и наши ко­
нечные пользователи также остаются в выигрыше!"

Определение статического тестирования

При статическом тестировании для визуальной экспертизы или автоматической об­
работки документации/кода программы с целью обнаружения ошибок используются
только текстуальные и/ил и графические формы программного обеспечения. Тек­
стовые или графические процессоры наподобие компиляторов, программ проверки
перекрестных ссылок, эмуляторов дискретных событий, программ вывода на печать,
программ статического контроля, программ распечатки ветвей и счетчиков цикло-
матической сложности — все они относятся к одной категории и носят название ста­
тических процессоров. Многие из них представляют собой исключительно важные
инструментальные средства тестировщика программного обеспечения. Существует
166 Часть II. Технологии быстрого тестирования и советы

ряд выполняемых вручную процессов, применяемых при таких видах статического

тестирования, как экспертизы, контрольные списки и оценка проектов. Этим вопро­
сам посвящена глава 8. Ошибки желательно обнаруживать до или в момент их внесе­
ния в жизненный цикл разработки программного обеспечения. Хорошим примером
своевременного выявления/исправления ошибок может служить программа дина­
мической проверки орфографии, выполняющаяся внутри текстового процессора.
Эта программа активно ищет текстовые строки, отсутствующие в текущем словаре, и
после обнаружения такой строки, заменяет ее наиболее близким по написанию сло­
вом или выделяет ее, чтобы пользователь смог выбрать правильное слово из списка
слов с аналогичным написанием. Хотя статическое тестирование может применяться
в течение всего жизненного цикла разработки и сопровождения, оно особенно по­
лезно на этапах, которые предшествуют созданию выполняемого кода.

Определение динамического тестирования

Динамическое тестирование суть обнаружение ошибок с помощью компьютера или
эмулятора компьютера, предназначенного для выполнения программы, которая была
создана разработчиками в соответствии с техническими требованиями. Динамиче­
ское тестирование соответствует естественному стремлению, возникающему при на­
личии выполняющей программы. А именно — предоставить компьютеру возможность
помочь в обнаружении ошибок путем выполнения ряда примеров или сценариев, ор-
ганизованных в форме тестовых случаев. Ориентированные на пользователя экраны,
которые, быть может, высмеивались на этапах разработки ТЗ и проектирования, не­
ожиданно начинают оказывать влияние на характеристики производительности, ко­
торые, возможно, были неясны во время проводимого ранее анализа архитектуры. В
процессе выполнения динамических тестов тестировщик действительно может по­
ставить себя на место пользователя и выполнить тест так, как любой пользователь
будет использовать программу. Сначала специалисты по тестированию могут обра­
тить внимание на временную синхронизацию и точность результатов выполнения
программы. В случае разработки новой подсистемы, прежде всего, активизируются
другие подсистемы, обеспечивающие доступ к базе данных совместного использова­
ния, обмен данными между подсистемами или выполнение любых других функций,
добавленных новой подсистемой.
Тестирование на совместимость предполагает выполнение одних и тех же тестов
для программы на нескольких компьютерных платформах и/ил и на нескольких кон­
фигурациях. Для сравнения, выполнение регрессивных тестов предполагает прогон
одних и тех же тестов по отношению к (я+1)-ой версии программы и сравнение полу­
ченных результатов с результатами тестирования n-ной версии. Вводя различные
входные данные и наблюдая за изменением выходных данных, поведением и измене­
нием производительности компьютерной системы, тестировщики могут решить, го­
това ли программа к началу использования конечными потребителями. Не всегда это
столь просто, как кажется, поскольку необходимо учитывать очень много перемен­
ных, таких, например, как правильность работы оборудования, корректность функ­
ционирования компиляторов, кода динамической поддержки и операционной сис­
темы, под управлением которой выполняется приложение, пригодность данных для
приложения и множество других факторов. Каждый из них может служить одной из
 Глава 7. Введен и е в технологи и тест ировани я и сов ет ы 167

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

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

Жизненный цикл дефекта

Чтобы можн о был о избавить с я о т блокирово к пр и те стирова ни и , для р а з р а б о т ч и к о в
программног о о бе с пе ч ен и я пре д ел ьн о важн о исправлят ь программн ы е ошибк и как
можно быстре е н а этапа х ди на м и че с к о г о тестировани я . Ка к правило , блокировк и
при т е ст и р о в а н и и вызываютс я л ог и че с ки м и ошибками , кот оры е препятству ю т обра­
ботке тестовы х данны х соответствующим и строк ам и кода. Н а ра н ни х этапа х динами­
ческого те с т и р о в а н и я вполн е ест ес тв ен н о , чт о тестировщи к и и ра з р а б о т ч и к и тру­
дятся в тесн о м содружестве , обнаружива я и исправля я программны е ошибки . Но на
последних этапа х т е с т и р о в а н и я ил и п р и работ е над боле е крупным и п роекта м и р о л ь
координатора , контроле р а и расстановщик а п р и о р и т е т о в играе т группа контрол я з а
внесением изменени й ( ch a n g e contro l review bo ar d — CCRB) , чт о иллюстрируетс я
рис. 7.3. Н а это м рисунк е показа н ж и з н е н н ы й цикл программно й ошибк и в о врем я
динамического тестир ован и я . Когда программн ы й модуль гото в к тестировани ю , ве­
дущий разработчи к , тесн о взаимодействующи й с диспетчеро м кон фигурац и и про­
граммного обеспечени я ( ДК ПО ) , вып о лн яе т опе р ац и ю сборки . В результат е создает­
ся выполняема я верси я программног о продукта, и исходны й ко д обновляетс я до но­
вой версии .
Пер сон а л группы тестиро ван и я отвечае т з а установку испытательн о й сред ы для
данной выполняемо й программы , включа я создани е компьютерн ы х систем , опера­
ционных систем , баз данных , коммуникационн ы х л и н и й и т.п . Кр о м е того , это т пер­
сонал выбирае т подходящи й набо р тестовы х случаев. П р и выбор е тестовы х случаев
учитывается природ а и размещен и е в код е программны х ошибок , обнаруженны х мо­
дулем. В соответстви и с о сц ен а ри я м и т ест и р ов ан и я специалис т п о те с т и р о в а н и ю
исследует программу и последовательн о сравнивае т промежуточны е результат ы с
результатами тестиров ани я , к от о р ы е задокументирован ы в тестов о м случае. Несов­
падение реальны х и ожидаемы х результато в свидетельствует либ о о необходимос т и
обновления ожидаемы х результато в тестовог о случая реальным и результатам и , либ о
о б обнаружени и ещ е одно й ош иб ки . По с л е прогон а выбранног о набор а тестовы х
случаев п о отношени ю к создаваемо й верси и выполняетс я ре гр е сс и вн о е тестирова -
168 Част ь II. Технологи и быстрог о тестировани я и совет ы

ни е с цель ю в ы яс не ни я , не разруши л и ли последни е изменени я какую-либо из функ­

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

Н а рис . 7.3 показа н такж е обходн о й путь для продолжен и я те сти р о в ан и я это й ж е
верси и . О н пролегае т ч ер е з процес с пр ав ки /о б хо д а ошибки . Группе тестировани я
може т потребоватьс я раздели т ь тес тов ы е случаи, к от о р ы е все ж е должн ы прогонять­
ся для текущей версии , на те , чт о столкнутся с это й же ошибкой , и на те , которы е не
должн ы быт ь подвержен ы е е воздействию . Эт о позволяе т выполн ят ь тестировани е
до те х пор , пок а де ф е к т не будет исправле н в будущих версиях . Иногд а для продол­
ж ени я тестирован и я требуетс я использовани е правк и (patch ) исполняе мог о модуля.
В случае в о зн и к н о в е н и я бло к ир о вк и в о врем я тести рова н и я п р и о р и т е т исправлени я
ошибк и повышаетс я д о наивысшег о уровня. Те м самым задач а немедленног о исправ­
л е н и я ошибк и становит с я п е р в о о ч е р е д н о й .
Т о , чт о группа т ес ти р о ва н и я занят а динамически м тестиро вание м , н е препятст­
вует реализац и и отдельны м и членам и группы дополнительн ы х технолог и й статиче­
ског о тестир овани я . Все тех но л ог и и статическог о тестиров ан и я полность ю приме­
ним ы в о врем я в ып ол не н и я динамическог о тестирова ния . Н а п р и м е р , результаты
ряд а динамически х тест о в могут сравниватьс я с ожидаемым и результатами . Эт а срав­
нительна я оцен к а мож е т б ы т ь авто ма тизи р о в а н а ил и ж е в ход е е е вып ол не н и я может
 Глава 7. Введени е в технологи и тестирован и я и сов ет ы 169

использоватьс я процес с статическог о те стиров ани я , аналогичн ы й э к с п е рт н о й оцен­

ке. В нескольки х компани я х был о установлен о , ч т о нек оторы е и з чл ен о в и х групп
тестирован и я н е п ри м ен я ю т адекватны е технолог и и статическо г о т е с т и р о в а н и я пр и
анализе результатов . В эти х компани я х говорят , чт о многи е и з специалистов , заня­
тых динамически м тести р о ва ни е м , обладаю т ментали тето м , к от ор ы й мож н о харак­
теризоват ь следующим высказыванием". " Ч т о ж , это т тес т действитель н о н е при ве л к
отказу этог о компьютера ! " Под обны й менталит е т позволяе т ошибка м оставатьс я не­
замеченным и в о врем я вы полнен и я дин ам и ч ес к о г о тестиров ани я , не с м от р я н а то ,
что сами п о себ е тестовы е случаи обеспе чи ва ю т возможн ос т ь обнару жен и я и ра н е е
неизвестны х ошибок .
По хо же , чт о менталит е т наподоби е "... эт о н е п р ив е л о к отказу к ом пь ю те р а " пре­
обладает так ж е сред и персонала , з ан им а ю щ ег о с я динамически м т е с т и р о в а н и е м про­
дуктов, в кот оры х используется обм е н данным и ч е р е з модемы . О бме н данным и по­
средством модемо в имее т долгую и ст о р и ю , и приоб ре л репутаци ю с оп ряже н но г о с
такими сбоями , как генераци я сигнал о в занят ост и , несоответств и е ск ор о ст и переда­
ч и данны х отвечающег о и запрашив аю ще г о модемо в ил и даж е ошибк и и з к а т е г о р и и
"прочие" , к от оры м и тестировщи к и склонн ы объ ясн я т ь любо е бе с п рич ин н о е зависа­
ние отвечающег о модема. Н е сообщ а я о подобны х ошибках , те стировщи к и подвер­
гают сво ю компан и ю риску продолжат ь поставл ят ь тестируемы й продукт с неустра-
ненными коммуникационным и ошибками . П ре дположи м , чт о подобны й продукт бы л
продан и установле н в нескольки х пом ещени я х боль ниц ы . Эт и загадочны е сбо и тип а
"отвечающи й модем прост о зависае т бе з видим о й п ри ч и н ы " будут как ра з таким и
сбоями, к от ор ы е станов ят с я осн овн о й п ри ч и н о й н а р е к а н и й с о с т оро н ы сотруднико в
больницы, сов ерше н н о справедлив о полагающих , чт о модем ы дол жн ы немедленн о
обеспечиват ь соответствующую ско р ос т ь обмен а данным и и соединени е (пр и отсут­
ствии сигнал а занят ости ) . Так и е сбо и н е т о л ь к о ста новят с я п рич ин о й об раще н и я в
службы техн и ч ес к о й поддержк и больницы , т е л е ф он н о й компани и и фи рм ы -
изготовител я модема, н о зачастую служат п р и ч и н о й прет енз и й в адре с ком па ни и ,
которая выпустила ил и продал а программн ы й продукт.

Формальные этапы тестирования

Динамическо е тестирова н и е може т начинатьс я с этап а тестировани я модулей и за­
вершаться пр ие м о чн ы м и испытаниям и . Стратеги и динамическог о те ст ир о в ан и я де­
лятся на две категори и : а им ен н о на те ст и р ов ан и е "черног о ящика " и те сти р о ва н и е
"белого ящика" . Ка к правило , стратеги я те ст ир о в ан и я "белог о ящика " пр им ен я ет с я
на этапа х тестир ован и я модулей и комплексн ы х испы тани й , в то врем я как с тр а тег и я
тестировани я "ч ер ног о ящика " — н а этапа х системног о тестиро ван и я и п р и е м о чн ы х
испытаний .
Цел ь тестиров ан и я модулей состои т в том , чтоб ы убедиться в реализац и и в код е
всех зап р ое кти р о ва нн ы х функци й и в устойчив ос т и воспроизведени я общи х воз­
можносте й и непроти вор е чиво с т и в ып о лн ен и я программног о модуля. П р и тестиро ­
вании модулей для управлени я тесто м в о врем я выполнен и я част о примен яют с я
драйвер ы и заглушки, в то врем я как пр и комплексн ы х испытани я х дл я управлени я
комплексным и функциям и , образованны м и нескольким и модулями ил и подсистема­
ми, как правило , используетс я GUI-интерфейс .
170 Часть II. Технологии быстрого тестирования и советы

Цель. комплексных испытаний является необходимость убедиться в соответствии

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

Обязанности членов команды тестирования

Специалисты по тестированию выполняют подготовку к тестированию, прогоняют
тесты и докладывают о результатах тестирования. Существует много должностей,
необходимых для обеспечения полноценной работы команды тестирования. Эти
должности, особенно в небольших проектах, могут занимать лица, обладающие
подготовкой в нескольких областях. Краткий перечень должностей приведен в
таблице 7.2.
Глава 7. Введение в технологии тестировани я и совет ы 171
172 Часть II. Технологии быстрого тестирования и советы

Что дальше
В главах 8 и 9 подробно рассматриваются технологии статического тестирования.
Глава 10 посвящена технологиям динамического тестирования. В главах 11 и 12 ос­
вещены показатели тестирования и модели оценки затрат на тестирование. Вот на­
звания этих глав:
8. Совместная разработка требований к приложению (JAR): метод выработки
требований с применением быстрого тестирования
9. Технологии статического тестирования и советы
10. Технологии и советы по динамическому тестированию
11. Разработка и использование показателей тестирования: моделирование и
прогнозирование ошибок
12. Технологии оценки трудозатрат на тестирование и советы
 Совместная
разработка требований
к приложению (JAR):
метод выработки
требований с
применением быстрого
тестирования
Темы, рассматриваемые в главе:
•М е т о д о л о г и я JAR
• Р о л ь с п е ц и а л и с т о в п о т е с т и р о в а н и ю в п р о ц е с с е JAR
• Резюме

Одно из основн ы х услови й успешно й разработ к и программног о обеспечен и я — дос­

тижени е по н и м ан и я требо ван и й клиентов . Ка к бы л о п о к аз ан о в главе 2 , четко е опре­
деление технически х требовани й служит отправно й т о чк о й э ф ф е к т и в н о г о процесс а
разработк и программног о обеспечени я .
Существуют различн ы е методы , пр из в а н н ы е улучшить обме н и н ф о р м а ц и е й между
клиентом и командо й разработчиков . Оди н класс методов , используемы х дл я выра­
ботки технически х требо вани й , называетс я техно логи е й ускоренн о й разработ к и
спе ци фи ка ц и и п р и л о ж е н и я (fast applicati o n specification techniques , FAST), котора я
кратко описывалас ь в главе 2. Совместна я разработк а треб ов ан и й к при л о ж ен и ю
(Joint Application Req uire ment s , JAR) — эт о технолог и я FAST, котора я предназначен а
для обеспечен и я пол но й интеграци и статическог о те сти р о ва н и я с процессо м выра­
ботки требо вани й . Ин т ег р а ц и я статическог о те ст и ро ва н и я в процес с JAR в вид е ег о
составной част и достига етс я з а сче т выполн ени я действий , известны х под название м
совершенно й поддержки . Со вер шенн а я поддержк а — э т о о рг а н из о в а н н ы й спосо б ин­
терактивног о анализ а и пересмотр а выработанн ы х т р еб о ва ни й . Действия , связанны е
с совершенно й подд е р жк о й , оп ис ан ы дале е в это й главе.
Результатом JAR-сеанса явл яет с я набо р тщательн о проан а лиз иров ан н ы х требова ­
ний, кот оры е согласован ы с пользователя м и конечног о продукт а ил и и х представи-
174 Част ь П. Технологии быстрого тестирования и совет ы

телями. Требования, выбранные в JAR-сеансе, включают в себя как функциональные,

так и подходящие нефункциональные требования. Например, сюда может входить
календарный план поставки продукта по этапам.

Методология JAR
Участвующие в JAR-сеансе образуют комиссию, составленную из представителей ко­
манды разработчиков, нескольких пользователей, знакомых с различными функцио­
нальными возможностями, которые должны присутствовать в конечном продукте,
представителя клиента/покупателя и председателя комиссии JAR. Как правило, для
проведения заседаний комиссии JAR на одну-две недели выделяется просторный
конференц-зал. Одна из возможных схем расположения мест в конференц-зале с уче­
том ролей приглашенных для участия в JAR людей показана на рис. 8.1.

Обратите внимание, что в состав комиссии не входят ни менеджеры, ни вице-

президенты, ни представители отдела обеспечения качества, ни представители отде­
ла снабжения, ни представители отдела поставки. Если кто-то из представителей этих
подразделений появляется на одном из заседаний комиссии, председатель должен
попросить их покинуть зал на период обсуждения вопросов совершенной поддержки,
которые будут описаны позже. Члены комиссии не должны пропускать заседания и
их не должны отвлекать сообщениями или телефонными звонками.
Роль председателя состоит в постоянно удерживать в центре внимания команды
три следующих задачи: выработка требований, четкая формулировка требований и
уточнение требований. Накануне заседания комиссии JAR председатель должен про­
вести установочное совещание для ознакомления членов комиссии со стоящими пе­
ред ней целями и правилами работы. В ходе этого установочного совещания члены
 Глава 8. Совместная разработка требований к приложению (JAR) 175

комиссии должны дать свое согласие действовать в соответствии со следующими

правилами:
• Не допускать личных нападок. Например, не пренебрегать и не дискредитиро­
вать идеи, высказанные другими участниками.
• Помнить, что одновременно может высказываться только один человек.
• Прежде чем предлагать какую-то идею, подумать о том, какова ее ценность, и
окажет ли она влияние на конечный продукт.
• Тщательно формулировать свои предложения, и после их анализа документи­
ровать их в заключительном документе.
• Задавать вопросы только председателю.
• Подавать председателю сигнал о необходимости перерыва в заседании (напри­
мер, скрестив руки), принятый в комиссии на случай возникновения непредви­
денных ситуаций/перерывов (например, при необходимости перерыва для от­
дыха или если был замечен какой-либо личный выпад).
• Во время заседания комиссии JAR не допускать проявления никаких внешних
отвлекающих факторов (сообщений электронной почты, вызовов по пейджеру
или телефону).
• Присутствовать на заседаниях, быть внимательным, творческим и полезным.
Председатель знакомит членов комиссии с целями и ограничениями проекта по
созданию программного обеспечения, а также определяет цели работы комиссии
JAR, в числе которых:
• Сбор сведений о потребностях и ожиданиях пользователей, а также определе­
ние показателей эффективности.
• Анализ потребностей и ожиданий пользователей для выработки словесного
описания функционирования системы и отдельных функций, которые должны
выполняться продуктом.
• Выработка требований по поставке и модернизации продуктов, которые долж­
ны устанавливаться и модернизироваться на рабочих местах пользователей.
• Разработка формулировок всех разделов требований, которые должны быть
освещены в итоговом документе.
• Получение от клиента и пользователей подтверждений того, что формулиров­
ки требований удовлетворяют их потребности и ожидания.
• Составление поэтапного графика поставки продукта с расширяющимся набо­
ром возможностей с целью удовлетворения текущих и долговременных по­
требностей и ожиданий пользователей, а также определение показателей эф­
фективности этих поэтапных поставок.
В состав комиссии должны входить опытные эксперты по исходным материалам
(source matter expert, SME), обладающие глубокими познаниями в области бизнес-
правил, областей применения и потоков данных, которые должны учитываться во
время разработки новой системы. Приходящие эксперты по исходным материалам
приглашаются на интервью, посвященные выработке требований, каждое из кото­
рых длится около 1,5 часов. На эти интервью могут приглашаться до двадцати экс-
176 Часть II. Технологии быстрого тестирования и советы

пертов, по двое одновременно. По окончания каждого интервью комиссии выделяет­

ся время на документирование требований, которые были выработаны на основе
доклада эксперта, и для отражения мероприятий по совершенной поддержке на пла­
катах, которые применяются для фиксации требований.
Типовой календарный график работы комиссии JAR типа "когда, кто и почему"
показан в табл. 8.1. В этом примере представлены семь отдельных заседаний: устано­
вочное, три дня интервью с экспертами по исходным материалам, два рабочих дня и
один день подготовки материалов для формальной документации. Поскольку в ходе
каждого заседания, посвященного интервью с экспертами, беседа проводится с двумя
из них, в этом примере в заседаниях комиссии JAR всего принимают участие 24 экс­
перта. Прежде чем начнутся рабочие заседания, комиссии может потребоваться пол­
дня для реорганизации настенных плакатов. С целью минимизации ощущения избы­
точности может потребоваться объединение аналогичных плакатов. Кроме того, мо­
жет возникнуть необходимость определить приоритеты требований в двух наборах,
например, разделение требований на те, что могут быть реализованы на первом эта­
пе представления проекта, и те, которые должны быть реализованы на втором этапе.
Поскольку каждое рабочее заседание проходит в среде, подобной библиотечной, на
каждое из 6 рабочих заседаний приглашаются только по 4 эксперта по исходным ма­
териалам. Кроме экспертов по исходным материалам, на рабочие заседания в качест­
ве наблюдателей могут быть приглашены несколько лиц, чье служебное положение
не позволяет им входить в состав комиссии. Между рабочими заседаниями члены ко­
миссии выполняют процедуры совершенной поддержки для включения комментари­
ев экспертов по исходным материалам в основной набор плакатов.
 Глава 8. Совместная разработка требований к приложению (JAR) 177

Опытный председатель комиссии JAR запасется, по меньшей мере, несколькими

сотнями чистых листов бумаги формата 8,5x11 дюймов (А4), десятком катушек лип­
кой ленты, несколькими десятками разноцветных шариковых ручек, подставкой для
документов, разноцветными маркерами, ножницами, наклейками и целлофановой
лентой. Эти материалы будут использоваться во время подготовки и поддержки на­
стенных плакатов, на которых отражаются требования.
Расположение плакатов на стенах конференц-зала должно соответствовать струк­
туре документа описания требований. На заглавных листах могут быть напечатаны
названия разделов этого документа. Они могут подвешиваться на верхней части сте­
ны, через равные промежутки, и должны располагаться по часовой стрелке в соот­
ветствии со структурой документа.
Каждый плакат будет иметь соответствующий заглавный лист. На шаблоне плака­
та, приведенном на рис. 8.2, показано, как вводить требование и с помощью клейкой
ленты прикреплять этот лист под соответствующим заглавным листом. Инструктаж по
созданию подобного плаката из чистого листа бумаги, должен проводится на уста­
новочном заседании. Шаблон не должен содержать заранее впечатанной информа­
ции, поскольку это будет препятствовать спонтанности, которую автор должен про­
являть во время заполнения плаката с требованиями. Прикреплять листы формата
8,5x11 дюймов на стенку следует только за верхние углы, соблюдая альбомную ориен­
тацию. Это позволит при необходимости поднимать плакаты вверх и перемещать их на
другую часть стенки, если потребуется сгруппировать их с другим требованием.
178 Часть II. Технологии быстрого тестирования и советы

Строка названия темы должна совпадать с заглавным листом, помещенным на

стенку. Если плакат перемещается в набор плакатов, расположенных под другим за­
главным листом, эта строка должна быть изменена. Формулировка — это краткое из­
ложение формулируемого требования. Она может представлять собой уточнение об­
ласти действия требования, описание применяемых интерфейсов или касаться лю­
бых других вопросов, требующих прояснения. В правой части плаката размещается
диаграмма, в которой требование представляется в графическом виде. В одном слу­
чае это может быть диаграмма взаимодействий, в которой показаны соединения ме­
жду элементами. В другом случае это могут быть фигурки беседующих людей, изобра­
жающие процесс опроса вручную. В третьем — диаграмма взаимодействия одной под­
системы компьютерной программы с другой через базу данных. Обычно под графи­
ческой диаграммой помещается ее название.
Выполняя действия по совершенной поддержке, членам комиссии приходится
часто подходить к стенам помещения. Эти действия не отражаются в календарном
графике JAR, поэтому по мере необходимости председатель должен время от време­
ни требовать от членов комиссии, чтобы они подходили к стенам, внимательно изу­
чали каждый плакат и фиксировали предложения по изменениям, наклеенные непо­
средственно на плакаты. Эта форма ревизии тесно связана с процессом выработки
требований. Обоснование написания наклеек приведено на рис. 8.3. Они служат для
того, чтобы всем участникам стало понятно, что пора оказать помощь в обнаружении
ошибок в требованиях или же четче сформулировать требования, а то и вовсе изме­
нить их расположение на стенке. На этом этапе совершенной поддержки изменения
в самих плакатах не допускаются.

В процессе выполнения этих действия стенка обычно приобретает цвет приколо­

тых примечаний, поэтому председатель приостанавливает выполнение всех дейст­
вий, дабы перейти к следующему этапу процесса совершенной поддержки. Первона­
чальный владелец плаката, на котором имеются наклейки, выполняет указанные ими
обновления, периодически восклицая: "Чье это предложение по такому-то требова­
нию?" Часто автор наклейки и автор плаката обмениваются мнениями с целью выра­
ботки приемлемого решения. Этот процесс обеспечивает достижение двух важных
целей: формулировки требований улучшаются в смысле четкости выражений и неза­
висимости от других требований, а вклад всех членов комиссии и экспертов по ис­
ходным материалам реализуется совершенно естественным образом. Подобная со­
вместная работа благотворно сказывается на проекте, гарантируя соответствие про­
дукта реальным требованиям пользователей. Во время создания программного про­
дукта будет возникать множество ситуаций, когда команда разработки должна взаи-
 Глава 8. Совместная разработка требований к приложению (JAR) 179

модействовать с группой пользователей или с экспертами по исходным материалам.

Такие ситуации отражаются в следующем списке:
• Организация работы рабочей группы управления взаимодействием
• Организация работы рабочей группы технического управления
• Выполнение промежуточных пересмотров программы
• Работа с опросными листами, интервью, эксплуатационными сценариями, по­
лученными от конечных пользователей (случаи использования на языке UML)
• Создание прототипов и моделей
• Наблюдение за существующей системой, средами и конфигурациями техноло­
гических процессов
• Принятие или заимствование решений и осуществление последующего выбора
• Альфа-тестирование
• Бета-тестирование
Это взаимодействие будет более плодотворным и качественным, если все члены
этой сборной команды научатся работать вместе и будут знать основные требования.
Результатом работы комиссии JAR должен быть набор плакатов, содержащих функ­
циональные и некоторые нефункциональные требования, предъявляемые к новому
проекту. Напряженная работа участников JAR по уточнению формулировок, графи­
ческого материала, приоритетов и заголовка каждого требования позволяет опытно­
му техническому оформителю без особого труда заполнить шаблон для создания за­
вершенного документа с требованиями.

ПРИМЕР: УСПЕШНАЯ РАЗРАБОТКА JAR (ГЭРИ КОББ (GARY COBB))

Несколько лет назад мне довелось столкнуться с разработкой очень важного проекта по
электронной торговле, календарный план которого был очень плотным. Этот проект был
явным кандидатом на применение технологий быстрого тестирования. Основная задача
формулировалась как быстрая разработка интерфейса программирования приложений
(API) между системой заказов товаров по Internet и стандартной системой размещения
заказов компании. Выделенные руководством денежные средства предполагали ведение
разработки шестью разработчиками, включая руководителя/ведущего разработчика, в
течение 3 месяцев. Руководитель проекта выделил 6 недель из 16-недельного календар­
ного плана на документирование требований и поручил эту работу двум разработчикам,
в то время как остальные должны были приступить к созданию прототипа API. Тогда я
выступил с заявлением, что если бы в проекте был использован процесс JAR, то я смог бы
предоставить полностью протестированный документ описания требований за 2 неде­ ли —
на целый месяц раньше планового срока. При этом в нем были бы полностью уч­ тены
пожелания пользователей, и было бы меньше ошибок, чем при выполнении 6-
недельной работы, за которую они были готовы взяться.
В четверг руководитель проекта и его подчиненные согласились принять мое предложе­
ние по применению JAR, и пятницу я начал с проведения вводного собрания, во время
которого группа составила список из 28 экспертов по исходным материалам. Во время
вводного собрания было выбрано также рабочее помещение, а четыре наиболее знаю-
щих эксперта были рекомендованы как члены команды на следующую неделю (еже
дневно с 8:00 до 17:00). Были расписаны также часы бесед с остальными 24-мя экспер­
тами (12 бесед с двумя экспертами ежедневно, с понедельника по среду следующей
180 Ча сть II. Технологии быстрого тестирования и советы

Легки й утренний завтрак и послеобеденные освежающие напитки должн ы были пода­

ваться в о б щ е м помещении, однак о п ро ме жут о к с полудня до 13:00 оставался свобод­
ным , чтобы члены группы могли пообедать и ответить на сообщения.
У т р о м в понедельник члены комиссии мучались над созданием плакатов для ряда фун­
даментальных требований. Ряд споров велось по поводу элементов архитектуры систе­
м ы , эксплуатационных характеристик и применимости, производительности и требований
к внешним коммуникациям . Зате м после полудня состоялись два первых интервью с
экспертами по исходным материалам. По завершении интервью, во вторник состоялась
первая половина заседания по совершенной поддержке . В результате вся стена окраси ­
лась в розовы й закатный цвет, поскольк у председатель располагал только розовым и на­
клейками . До проведения первого интервью с эксперто м по исходным материалам в
среду авторы плакатов обработали поставленные вопросы и стена вновь стала белой . За
втору ю половину среды , в процесс е подготовки к первому рабочем у заседанию, кото ­ ро
е до лжн о было состояться в четверг, сеанс совершенной поддержк и был завершен, и члены
комиссии сложили часть плакатов под поручнями кресел , те м самы м признав, что эти
требования имеют более низкий приоритет и должны быть выполнены п о з ж е . Одно-
в р е м е н н о один из членов комиссии завершил уточнение глоссария. В полдень четверга
д в у м ме не дже ра м было предложе н о оставить свои замечания на стене с пустыми р о з о -
выми наклейками. Члены комиссии были весьма горд ы похвальными отзывами, остав-
ленными обоим и ме не джер ам и .
К пятнице помещение JAR было проветрено , а комиссия, за исключением председателя
и руководителя проекта , кото р ы е остались для беседы с техническим оформителе м ,
была распущена. Руководитель проект а согласился к понедельнику пересмотрет ь кален­
дарный план с учето м более раннего начала проектирования. Технический оформитель
согласился ко вторнику подготовить черновик документа с требованиями и новый кален-
дарный план разработк и проекта .
Во время этой разработки JAR были запланированы три последовательных поставки вер­
сий пр о гр а м м ы , причем первая должн а была быть создана по истечении первых трех
месяцев. Эта версия должна была, ка к и планировалось ранее, передавать Internet-
заказы в систему размещения заказов . Второй этап, разработка к от ор о г о должн а была
выполняться параллельно первому , ориентировался на создание ASP-системы, запускае­
мо й во время формирования Internet-заказа, ка к средства предотвращения попадания
неверно оформленных заказов в систему размещения заказов. На третьем этапе, раз­
рабатываемом параллельно с первы м и вторы м этапами, планировалась разработка
Web-систем ы отслеживания заказов , предназначенной для автоматизации получения ин­
формаци и о состоянии заказов Internet-клиентов. Поставки версий програм м ы на всех
этих этапах выполнялись своевременно и были с радость ю встречены пе ре гр уже нны м
работой персоналом отдела обработк и заказов, кото ро м до этог о приходилось вводить
и обрабатывать заказы вручную .
Наиболее примечательное замечание, впоследствии услышанное м н о ю от одног о из об­
работчиков заказов, звучало так: "После получения программ ы члены этой команды
разработчиков учили нас выполнять работ у с п о мо щ ь ю данного прог рам мн ог о обеспе­
чения, но да ж е сами разработчики не смогл и заставить программ у работать во время
обучения. Когда они поставили п р о г р а м м у , мы и сами знали, ка к ее использовать, по­
скольку она полностью соответствовала нашим потребностям. Удивляло лишь то , что в
пр о гра мм е было очень мало о ш ибо к , и что на всех этапах поставка выполнялась точно
по графику. " Отойдя в сторону , я сказал се б е : " Да ! Вот вам результат одновременного
выполнения разработки и тестирования!" Иначе говоря , таков результат быстрог о тести-
 Глава 8. Совместная разработка требований к приложению (JAR) 181

Роль специалистов по тестированию

в процессе JAR
В процессе JAR специалисты по тестированию играют три роли. Они (1) участвуют в
совершенной поддержке, (2) знакомятся с требованиями к тестированию, которые
должны стать обоснованием требований по выделению ресурсов для персонала про­
ведения испытаний и (3) во время интервью с экспертами по исходным материалам
задают вопросы относительно используемых в настоящее время процедур тестирова­
ния. Один из разделов документа с требованиями должен быть посвящен требовани­
ям к тестированию продукта, и именно специалист по тестированию должен первым
ратовать за то, чтобы этот раздел был максимально полным и точно сформулирован­
ным. Вполне вероятно, что впоследствии он окажется тем тестировщиком, которому
придется преобразовывать эти требования к тестированию в требования к ресурсам по
обеспечению тестирования, общий план тестирования и множество тестовых слу­ чаев
со сценариями и результатами тестирования. Во время интервью с экспертами по
исходным материалам тестировщик должен прояснить каждый из перечисленных ниже
вопросов:
• Расскажите о режимах, приводящих к отказам используемых систем, наиболее
часто отмечаемые пользователями.
• Пожалуйста, опишите методику взаимодействия пользователей с группой раз­
работки во время документирования, исправления и тестирования ошибок в
используемой системе.
• Опишите, как пользователи осуществляют переход к новой версии, выпущен­
ной группой разработчиков.
• Назовите некоторые из стандартов, которые пользователи желают выдвинуть
разработчикам нового продукта.
• Пожалуйста, помогите описать некоторые платформы и языки, в сочетании с
которыми новый продукт должен функционировать, а также любые конкрет­
ные соображения по поводу окружающей среды компьютерных систем, вклю­
чая доступность для обслуживания, ремонта и т.п.
При рассмотрении тестирования на этапе выработки требований в рамках жиз­
ненного цикла разработки следует помнить, что во время JAR-сеанса выбираются и
помещаются в итоговый документ как функциональные, так и нефункциональные
требования, при этом они должны быть максимально полными и четко сформулиро­
ванными. Но они не являются единственными, которые должны быть удовлетворены
во время разработки, равно как и единственными, которые должны тестироваться.
Ниже приведен перечень ряда дополнительных требований, которые должны быть
учтены персоналом разработки:
• Стандарты разработки проекта. Это требования к процессам и процедурам,
которым персонал разработки должен будет следовать на этапах разработки
проекта. Весьма вероятно, что эти установки и процедуры будут стандартными
для всех разрабатываемых проектов, поэтому персонал тестирования должен
располагать инструментальными средствами и тестовыми случаями, которые
позволят проверить каждый продукт на предмет соответствия этим требованиям.
182 Часть II. Технологии быстрого тестирования и советы

• Производные требования. В течение JAR-сеанса эксперт по исходным мате­

риалам может заявить, что новый продукт должен быть выполняемой про­
граммой, запускаемой на одном из сетевых клиентских компьютеров, рабо­
тающих при нормальных рабочих условиях окружающей среды. Видя это тре­
бование, проектировщики программного обеспечения могут включить в код
параметр для комнатной температуры и поискать значения верхней и нижней
границ температуры в стандарте, который определяет нормальные рабочие ус­
ловия окружающей среды. При создании тестового случая для проверки соот­
ветствия исходному требованию, чтобы воспроизвести испытательные условия
окружающей среды для тестируемого продукта, специалистам по тестированию
придется обратиться к производному требованию, выдвинутому проектиров­
щиками программного обеспечения.
• Требования к интерфейсу. Занимаясь реализацией нового продукта, проекти­
ровщики программного обеспечения могут принимать решения по созданию
или приобретению тех или иных компонентов. Чтобы можно было взаимодей­
ствовать с приобретенными подсистемами, конструкция должна удовлетворять
дополнительным нефункциональным требованиям. При создании тестовых
случаев для тестирования интерфейсов на предмет их соответствия специфи­
кациям тестировщики будут применять тесты к интерфейсу этой подсистемы
так, как это определено в документации, поставляемой вместе с подсистемой.

Резюме
Подводя итоги сказанному в этом разделе, который был посвящен объединению тес­
тирования с выработкой требований, следует отметить, что в действительности
JAR — всего лишь один из множества методов выработки требований. Основная идея
состоит в том, что вся команда разработки оценит роль тестирования только тогда,
когда с самого начала оно будет интегрировано в процесс разработки. Разработчики
смогут оценить преимущества того, что не придется проектировать и реализовать
сложный программный продукт лишь для того, чтобы выяснить, что основные поль­
зователи не в состоянии понять принципы его применения, а покупатели не желают
расставаться со своими деньгами.
Тестировщики системы также оценят избавление от необходимости разрабаты­
вать и реализовывать сложные тестовые случаи для этой сложной конструкции. Пер­
сонал отдела маркетинга оценит отсутствие необходимости конкурировать с более
дешевым продуктом, появившимся на рынке раньше, поскольку он не содержит
сложных компонентов. И, наконец, поэтапная поставка версий продуктов является
общепринятой нормой в промышленности программного обеспечения, а сложные
компоненты, исключенные из первоначальных требований, могут послужить реаль­
ным усовершенствованием, которое привлечет симпатии клиентов, если они будут
добавлены и реализованы в форме существенной модернизации.
 Технологии
статического
тестирования
и советы
Темы, рассматриваемые в главе:
• Цикломатическая сложность и ее взаимосвязь
с выполнением тестировани я
• Приме р представления проекта модуля в виде графа
• Формальная оценка
• Применени е контрольных перечне й
• Аудит
• Инспекции/критически й анализ/экспертн ы е оценки
• Распределение ролей и обязанностей в группе
выполнения инспекций
• Отчетность о процессе выполнения инспекций
• Показатели процесса инспекции
• Использование электронно й почты или другого
электронного приложения для ускорения процесса
инспекции
• Формальная верификация
• Языки на основе спецификаций
• Автоматизированное доказательство теорем
• Средства автоматизации тестирования
• Прослеживаемость требований
• Программа контроля единиц измерения
физических величин
• Символьное выполнение
• Листинги перекрестных ссылок
• Программы улучшенной печати
• Средства сравнения версий
• Тестирование алгоритмов
• Диспетчер тестирования
• Базы данных материалов совместного использования
• Резюме
184 Част ь II. Технологи и быстрог о тестировани я и совет ы

Существует мн о же ст в о технологий , в кот оры х используетс я анали з архитектур ы и

структуры программны х р азработо к . В эт о й главе описа н ря д таки х технологий . В
соответств и и с к он ц еп ц и е й быстрог о т е с ти р о в а н и я эт и технолог и и должн ы приме­
нятьс я н а максимальн о ра н н и х этапа х ж изн ен н ог о цикл а р аз ра б отк и , и большинств о
и з них може т использоватьс я ещ е д о начал а создани я каких-либо кодов. Известно , чт
о высока я сложност ь неизбеж н о приводи т к большому количеств у ошибок , поэтому
в это й главе внимани е уделяется, прежд е всего, вопроса м уменьшени я сложности.
Основн о й п обочны й э ф ф е к т измерени я цикломатическ о й сложно ст и состои т в том,
чт о он о позволяе т группе т е ст и р о в а н и я оц е н и т ь кол ичест в о прогоно в программног о
объект а , к от ор о е потребуетс я для хот я б ы одн о к рат н о г о т е с т и р о в а н и я каждо й ветви
програм м ы . Эт о мо же т служить ори е н т и р о м ка к для пла нирован и я трудозатра т н а
т е ст и р о в а н и е , та к и дл я создани я упорядо ченн ы х наб оро в случаев использовани я .
Форма льн ы е оц е н к и , ин сп ек ц и и и аудиты позволяю т убедиться в том , чт о каждый
и з ра з р а б о т ч и к о в приде рж ивает с я наборо в установок , процедур , руководст в п о сти­
лю и других стандартов , используемы х в организаци и . Кром е того , о н и явля ют с я эф­
фек ти вн ы м средство м обнаружен и я ошибок . В главе такж е рассматриваютс я техно­
логии , которы е дол жн ы применятьс я для организац и и и проведен и я оцено к и ин­
спекци й .

Цикломатическая сложность и ее взаимосвязь

с выполнением тестирования
На л ич и е нескольки х ветве й в програм м е существенн о повышае т в е р о я т н о с т ь оши­
бок, и поэтом у тестировщи к и уделяют им особо е внимание . Вполн е естественн о , что
многи е р аз р а б о т ч и к и про граммно г о о б ес пе ч ен и я с чита ю т о п е р а т о р ы G O T O , т.е.
безусловны е переходы , конструкцие й языка , кот о р а я затрудняе т пони м ан и е кода.
О п е р а т о р G O T O исклю че н и з большинст в а структурированны х яз ы к о в программи­
ро ва ни я . Те м н е менее , точк и пр и н ят и я р е ш е н и й являютс я обязательным и конст­
рукциями даж е в таки х языках . На п р и м е р , и конструкци я IF(...), и конструкци я DO
WHILE(...) с одер ж и т точку п р ин я т и я р е ше ни я .
В процедурны х языка х ветвь определяетс я как перехо д в процесс е вычислений ,
начина ющий с я от то чк и входа в модуль ил и то чк и п р и н я т и я реш ени я и заканчиваю­
щийся точко й выхода из модуля ил и т о чк о й п р и н я т и я ре ше ни я . В некото ры х рабо­
тах, пос вя щ ен н ы х это й тем е , ав тор ы называю т ветв ь DD-ветвью (от decision-to-
decisio n pat h — ветв ь "от-решения-до-решения"). Поэтом у типи чн а я конструкц и я IF-
THEN-ELSE-ENDIF с одер ж и т две ветви , которы е о бы ч н о называютс я ветвям и THE N
и ELSE, приче м об е он и завершаютс я ключевы м слово м ENDIF конструкции . В мате­
матик е и в те о р и и гр а ф о в был о показано , чт о гр а ф структурированно й программы
являетс я планарн ы м (плоским) . И наоборот , все неструктурированны е программы
имею т неп л ан ар н ы е граф ы . Уже н а зар е програм м иров ан и я стал о при вы чн ы м для
упрощени я п он и м а н и я логи к и вычислени й вычерчиват ь л ин и и , соединяющи е точк и
п р ин я т и я ре ш ени й . Тогд а ж е стал при в ы чны м отка з о т попыто к разобратьс я в про­
граммах, содержащи х слишко м мног о ветвей , и раз би ен и е их на доступны е дл я пони­
мани я фр аг м ент ы .
Вполн е есте ст в енн о , чт о проблем а сл о жн о ст и программн ог о об ес пе ч ен и я уже
давн о привлекае т вниман и е испытателе й . Руководител и различны х ранг о в весьма
 Глава 9. Технологи и статическог о тест ирован и я и совет ы 185

довольны , когда представите л ь отдел а т е с т и р о в а н и я заявля е т : "Да, мы, п о кра йне й

мере, оди н р а з п р о т е с ти р о в а л и каждую строку кода". Тома с М аккей б (Thoma s
McCabe) и Ч а р л ь з Б ат л е р (Charle s Butler ) [32] в качеств е п ок аз ат е л я оп ред ели л и чи­
словое значени е цикломатическ о й сл ож н ос т и V g Эт о значе н и е може т быт ь вычисле­
но по одному из тре х способов :

1. Путем подсчет а количеств а областе й планарног о графа , к от о р ы й представля­

е т процес с структурированно й програм м ы .

Пример представления проекта модуля

в виде графа
Показанны й н а рис . 9.1 п л ан а рн ы й гра ф дели т плоскост ь н а пят ь областей , пронуме­
рованных ци фра м и от 1 до 5, поэтом у ег о цикломатическа я с л о жн о ст ь V=5. Попы­
тайтесь найт и ч еты р е пред икат а в коде и в соответствующе м ему г р а ф е процесса . В
заключение оп ред ели т е ко личест в о тестовы х случаев, которы е п от р еб о ва л и с ь бы, п о
меньшей мере , для одн о к р а тно г о т е ст и р о в а н и я каждо й строк и кода.
186 Часть II. Технологии быстрого тестирования и советы

Значение цикломатической сложности для тестирования программ состоит в том,

что V. представляет собой минимальное количество независимых ветвей, которые
должны быть проверены для тестирования всей программы. Испытатель должен
быть в состоянии применить это свойство к графу "а", представленному в левой части
рис. 9.2, и разработать минимальное количество тестовых случаев, которые должны
быть выполнены для полного охвата всего приложения, соответствующего данному
графу. При этом возникает ряд вопросов. Обеспечивают ли два приведенных тесто­
вых случая полное тестирование всех ветвей? Нет ли какой-либо ветви, которая оста­
лась неохваченной тестовыми случаями 1 и 2? И если да, то каким должен быть до­
полнительный тестовый случай?

В [18] Питер Чейз Белфорд (Peter Chase Belford) описал, как в рамках одного из
выполненных им проектов в корпорации Computer Science Corporation при помощи
показателя цикломатической сложности удалось снизить стоимость проекта и одно­
временно повысить качество программного продукта за счет снижения сложности
кода.

ПРИМЕР: ПРОЕКТ CENTRAL FLO W CONTROL

Эти учебные пример ы заимствованы из [ 1 8 ] . В проекте Central Flow Control (CFC) для
документирования алгоритмов использовался псевдокод. Для языка разработки псевдо­
кода (pseudocode design language, PDL) была создана программ а синтаксического ана­
лиза, в которо й был реализован счетчик цикломатической сложности.
 Глава 9. Технологии статического тестировани я и совет ы 187

Стоимость разработки каждо й модели и соответствующее ей значение показателя иик-

ломатической сложности наносились на график, и для полученных данных определялась
наиболее подходящая S-образная кривая. S-образная кривая Белфорда показана на рис.
9.3. Из приведенного рисунка видно, что существовал диапазон цикломатических значе­
ний модулей — например, вблизи линейного участка кривой, — которые отражали при­
емлемую стоимость разработки, выраженную в часах. В то же время другая область
представляла неприемлемое возрастание стоимости. В ходе разработки проекта CFC
постоянно выполнялось повторное: проектирование модулей, для которых показатель
цикломатической сложности PDL превышал 30.
На основе анализа процесса разработки этой программы Белфорд пришел к следую­
щим выводам:
• Лучше использовать меньшие модули.
• Сложность системы разработки программного обеспечения лучше измерять количест­
вом ветвей принятия решений, чем количеством выполняемых операторов в исходном
коде.
• Использование современных методов программирования способствует повышению
степени понятности и надежности системы, а также делает процесс разработки более
управляемым.
• Надежность программного обеспечения повышается с увеличением времени, которое
тратится на проектирование.
В некоторых проектах применяются стандарты, в которых предпринимается попытка ог­
раничить размер каждого из модулей до некоторого приемлемого объема кода. На
рис. 9.4 показано, как определить набор эвристических правил и представить его в
форме дерева принятия решений, подтверждающего выводы Белфорда и других иссле-
дователей. Эти стандарты могут использоваться персоналом службы тестирования при
разработке автоматизированных средств оценки всего проекта или отдельных про­
граммных модулей.
188 Част ь II. Технологи и быстрог о тестирован и я и совет ы

Формальная оценка
Имее т смы с л пе риодичес к и проводи т ь фор мальн у ю оценк у каждого аспект а проекта
разработ к и программног о обеспечени я . Може т возникнут ь вопрос , како е отношени е
периоди че ск и е ф о р м а л ь н ы е оц е н к и имею т к быстром у тестировани ю . Быстро е тес­
тир о ва н и е — эт о метод , в основ е которог о лежи т вы по лн ен и е каждой задач и на как
можн о боле е ран не м этап е жиз не нн ог о цикл а и одновременн о е обнаружени е и уст­
р а н ен и е любы х недостатков , могущих возникат ь в процесс е решен и я каждой задачи.
Как правило , ф ор м а ль н а я оц ен к а проводитс я наканун е завершени я какого-либо эта­
па, и объектам и таки х оцен о к становятс я результаты , баз ы данны х показателе й про­
екта, календарн ы е планы , пере чн и недостатко в и тому подобны е документы, полу­
ченн ы е н а каждом этап е жи знен ног о цикла разработк и .
Це л ь ф о р м а л ь н о й оц е н к и состои т в ознак о мл ен и и отдельны х члено в команды
разработ к и с о ц е н к о й всех аспекто в достигнуты х результато в разработ к и с точк и
зре ни я руководства. Кажды й разработчи к долже н увидеть и понят ь взаимозависимо­
ст и между всем и полученным и результатами, в особенност и между теми , за получе­
ни е которы х он несе т ответственность . Кажды й разработчи к долже н увидеть и по­
нять , каки е показател и содержа т и н ф о р м а ц и ю , имеющую отн о ше н и е к выполняемо й
и м работ е . Специалист ы п о тестирован и ю должн ы обр а ти т ь особо е внимани е н а
элементы , к от ор ы е долж н ы оцениваться . Н а п ри м е р , н а состояни е выпол нен и я зака­
з а н а поставку испы тат е ль но г о оборудовани я ил и дат ы готовност и ново й документа-
 Глава 9. Технолог и и статическог о тестирован и я и совет ы 189

ции, поскольку эт а и н ф о рм а ц и я м ож е т влият ь н а пла н вып олнен и я т е с т и р о в а н и я или

разработк у тестовог о случая. И н ач е говоря , кажды й участни к в ы п ол н е н и я формаль ­
ной оц е н к и оценивае т результат ы этап а с т о ч к и зре ни я и х готовност и к использова ­
нию. Хот я кое-кто може т заявит ь , чт о эт и обз о р ы служат для осуществлени я контро ­
л я над ходом р аз ра б от к и пр ог р ам мн о г о о б ес пе ч е ни я с о сторон ы руководства , м ы
смотри м н а это т вопро с нескольк о инач е . Данн ые , полученн ы е о т чл ен о в команды ,
наряду со спискам и н е д о с т а т к о в / н е р е ш е н н ы х вопросо в должн ы компилировать с я и
упорядочиватьс я руководителям и различны х уровней . Эт о позволи т передат ь эт и
данные команд е р аз ра б от ч ик о в , чтоб ы ч ле н ы команд ы могл и увеличит ь сво ю произ­
водительност ь ил и улучшить качеств о получаемы х результатов .
Дл я програм мног о обеспе чени я , разрабатываемог о п о контракт у , в ходе каждо й
формально й оце нк и с участие м клиент а оце ни в ает с я соблюден и е с роко в и услови й
контракта . Резюм е эти х оц ено к могут представлятьс я клиенту, к от ор ы й долже н быт ь
уверен в корректн ос т и веден и я р а з р а б о т к и в рамка х выделенно г о бюджет а и огово­
ренных сроков . Н иж е приведе н п е р е ч е н ь вопросов , к от ор ы й може т подготови т ь и
отслеживат ь руководител ь р а з р а б о т к и программн о г о об ес пе ч е н и я ил и специалис т
по вопроса м о бе сп е ч ен и я качества , и к от ор ы й може т быт ь представле н в ходе фор ­
мальной оц ен к и :
• Да н ны е о р аз ме р е программны х продукт о в или объем е изм е не ни й в программ­
ны х продуктах отслеживаются , и в случае необходимост и п р е д п р и н и м а ю т с я
к ор р е кти р у ю щ и е действи я .
• Разме р программн ы х продукт о в ил и объе м изменени й в програ ммны х продук­
та х регулируются в соответ стви и с задокум ентиров анн о й процедурой .
• Данн ы е по трудоемкост и и затрат а м на разработ к у програм м ы отслеживаютс я ,
и в случае необходимост и п р е д п р и н и м а ю т с я корре кти рую щ и е д ей ст ви я .
• Трудоемкост ь и затрат ы на разработ к у программ ы регулируются в соответст­
ви и с задокументир ованн о й процедурой .
• Кр и т и чн ы е для вып о лн ен и я проект а компьютерн ы е ресурс ы отслеживаются , и
в случае необходимос т и пре дпринима ют с я корректирующи е действия .
• Кр и т и чн ы е для вып о л нен и я проект а компьютерн ы е ресурс ы управляютс я в
соответств и и с задокументированно й процедурой .
• Календарн ы й план разработ к и программног о обеспечен и я проект а отслежива­
ется , и в случае необходимост и предпринимают с я корректирующ и е действия .
• Календарн о е планир ов ан и е и управлени е разработко й к р ит и чн ы х связе й и
критичны х ветве й программ ы выполняет с я в соответств и и с задокументиро­
ванно й процедурой .
• Технически е действи я п о разработ к е программног о обеспечен и я отлеживают ­
ся, и в случае необходимос т и предп ринима ют с я корректирующ и е действия .
• Отслеживаютс я ве р о ят ны е про счет ы в программно м обеспе чени и , кото р ы е
могут сказаться на затратах , ресурсах, календарно м план е и технически х
аспектах.
190 Часть II. Технологии быстрого тестирования и советы

• Вероятные просчеты в программном обеспечении, которые могут сказаться на

затратах, ресурсах, календарном плане и технических аспектах, идентифици­
руются, оцениваются и документируются.
• Критичные взаимозависимости между разработками программного обеспече­
ния идентифицируются, согласуются и отслеживаются в соответствии с задо­
кументированной процедурой.
• Вероятные просчеты в программном обеспечении проекта идентифицируют­
ся, оцениваются, документируются и контролируются в соответствии с задоку­
ментированной процедурой.
В число присутствующих на формальной оценке могут входить представители
компании/организации, выполняющей основную разработку, представители коман­
ды субподрядчика/партнера, команды организации-покупателя и команды потенци­
альных пользователей. Проведение формальной оценки позволяет руководству орга­
низации/проекта контролировать процесс разработки, в том числе просматривая
отчеты и предпринимая корректирующие действия в отношении затрат, человече­
ских ресурсов, компьютерных ресурсов, технических проблем, критичных взаимоза­
висимостей и вероятных просчетов. Секретарь должен записать действия, по кото­
рым достигнуты соглашения во время встречи, и по ее окончании перечень выбран­
ных действий должен быть распространен среди исполнителей и отслеживаться
вплоть до момента реализации всех действий. По окончании встречи перечень дей­
ствий будет проработан руководителями нижнего уровня, способными устранить лю­
бые конфликты, которые могут возникнуть между группами. Независимо от того, яв­
ляется ли организация главным подрядчиком или субподрядчиком (в наше время в
деловом языке чаще употребляется термин "партнеры"), важно проводить хорошо
организованные совместные формальные оценки. Главное достоинство проведения
хорошо организованных формальных оценок — это возможность согласовывать уси­
лия и делиться приобретенным опытом.
Для команды тестирования формальные оценки ценны в первую очередь тем, что
позволяют гарантировать применение всеми партнерами одних и тех же критериев
прохождения/непрохождения тестов, создание во всех организациях-партнерах со­
вместимых тестовых сред, разработку средств для немедленного распространения
информации обо всех обнаруженных ошибках и просчетах, поддержание календар­
ных планов последовательной поставки версий продукта с устраненными ошибками
и достижение соглашений по условиям прекращения тестирования.

Применение контрольных перечней

Поскольку управление разработкой программного обеспечения может оказаться
очень сложным, большое распространение получила практика применения сборни­
ков извлеченных уроков и наиболее эффективных методик, оформленных в виде
контрольных перечней. Контрольные перечни служат удобным напоминанием о дей­
ствиях, которые должны выполняться в процессе жизненного цикла разработки.
Обычно они документируются в форме утвердительно-вопросительных предложений
типа "если... то... ?". Контрольные перечни не следует искать в Internet, выбирая те,
которые кажутся подходящими. Более того, контрольные перечни не должны ис­
пользоваться в качестве стандартов организации. Если контрольный перечень не
 Глава 9. Технологи и статическог о тест ирован и я и совет ы 191

разработ а н н а основ е уроков , извлеченны х в рамка х данног о проекта , польз а о т нег о

будет невелика . В то же время , правильн о с о ст ав л е нн ы е к онтрольн ы е п е ре ч н и слу­
жат мощны м средство м сни жени я в е р о я т н о с т и пр о с ч е т о в в ходе раз р аб от к и проекта .
П р и в ы п ол н е н и и быстрог о тестиров ани я , в за ви си м о ст и о т выбранног о жизнен ­
ного цикл а р азр а бо тк и , язык а и средств , используем ы х для раз р аб от к и , и множест в а
других фа к т оро в , контроль н ы е перечни , созданн ы е дл я данног о проекта , могут имет ь
различно е назна чен и е . Ни ж е приведен ы п р и м е р ы пунктов контрольног о пер е чн я :
• Если тр е б о в а н и я включаю т в себя т р е б о в а н и я п о доступности , т о долже н л и
используем ы й в проект е текс т подвергатьс я прове рк е н а предме т соответстви я
стандарт у к омп ан и и , предусматривающем у манипуляци и доступностью?
• Если т р е б о в а н и я включаю т в себ я т р е б о в а н и я по доступности , то от ра же н ли в
план е т е ст и р о в а н и я ф а к т при ме н ен и я средст в тес ти р ов ан и я доступност и про­
ект а н а предме т соответстви я стандарту?
• Если требуетс я п ри м ен ен и е процесс а ин сп е кт ирова н и я н а предме т соответст ­
ви я стандарта м компании , то прош л и ли все участвующие в ин с пе кт и ров а н и и 4-
час ов ы й курс обучени я и сдали ли выпускно й экзамен ?
• Если температур а являет с я о б яз ате л ьн ы м парам е тром , т о обеспечиваетс я л и
в озм о жн о ст ь выбор а пользовател е м от о б р а ж е н и я температур ы п о шкал е Цель­
си я ил и Фаренгейт а ?
• Если "abc " — выбранно е средств о управлен и я конфигурацией , кот ор о е будет
использовать с я в проект е , т о заблоки рова н ы л и все верси и исходны х модулей,
к о т ор ы е в настояще е врем я пр о в е р я ю т с я н а предм е т обновлени я ?

Автора м доводилос ь встречат ь баз ы данны х пунктов контрольны х пе речн ей , в ко­

торых утверждени е отделялос ь о т вопрос а и к от ор ы е содержал и д о п о л н и т е л ь н ы е
поля, используемы е в качеств е ключе й с ортиров ки . Т е м самы м достигалас ь возмож­
ность изм ен ен и я ф о р м ы печат и контрольн ы х п е р е ч н е й в зависимос т и о т текущег о
этапа и наз на че ни я пе речн ей . П ов т ор и м е щ е р аз : главное , чтоб ы п р и в оз н и к н ов е н и и
проблемы все член ы команд ы сделали все возможно е для создани я пункта контроль ­
ного перечня , в которо м был о б ы указано, чт о должн о быт ь сделано данно й командо й
для устранени я дан но й проблемы , есл и он а в оз н и кн е т снова .
Как создаютс я пункты контрольног о перечня ? Процедур а состои т в следующем:
если п ри чи н а жалоб ы клиент а отражен а в в ер хн е й част и диаграмм ы Па р е т о , то су­
ществует ли пункт контрольно г о пер е чн я , в утв ердительно й части которог о оп иса н а
причина жа лоб ы клиента , а в вопросительн о й — правил о устранени я ос н ов но й при­
чины неполадки ? Да , дл я создани я таког о пе р е ч н я требуетс я т е р п е н и е и методич­
ность, н о выгода о т ег о п р и м е н е н и я огромна .

Аудит
Для тог о ч тоб ы убедиться в соблюдени и инструкций , процеду р и стандарто в органи­
зации, необходим о выполнит ь аудит в рамка х орган изаци и . П р и отсутстви и утвер­
жденных инструкций , процедур и стандарт о в аудит лише н смысла и лиш ь создавал бы
значительные неудобства. Уведомление , пл ани р о ва н и е , беседы и составлени е отче­
тов по результата м аудита — все эт о действия , имеющи е решающе е зна че ни е дл я ус­
пешного п р о в е д е н и я аудита. Бесед ы до л жн ы пла ни р о в ать с я так , чтоб ы из о л и р о в ат ь
192 Часть II. Технологии быстрого тестирования и советы

друг от друга следующие производственные уровни: руководство и функции поддерж­

ки (например, управление конфигурированием), обеспечение качества, клиен­
ты/спонсоры/бизнес-аналитик, управление производством, администратор баз дан­
ных и другие непосредственные исполнители разработки/тестирования. В каждой
беседе должны участвовать ведущий аудитор и второй аудитор. Ведущий аудитор ве­
дет беседу, и оба аудитора фиксируют все сказанное в ходе нее. Между беседами ауди­
торы могут меняться ролями. Советы по выполнению каждого из основных действий
приведены в таблице 9.1.
 Глава 9. Технологии статического тестирования и советы 193

В 1999 году нам довелось провести аудиторские проверки более 25 команд разра­
ботчиков, дабы удостовериться, что эти команды, занимавшиеся внесением измене­
ний, решающих проблему 2000-го года, полностью выполнили соответствующее тес­
тирование и аттестацию, и эта проблема должна быть решена к первому кварталу
2000 г. Результаты, полученные в ходе аудита проектов программного обеспечения,
свидетельствовали о высоком профессионализме аудиторов во время проведения
бесед и о точности сделанных выводов, которые указывали на любые возможные
проблемы в ходе производственных процессов. Ценность проведения этой проверки
для компании заключалась в том, что аудиторская проверка 10% команд разработчи­
ков позволила в ходе выполнения проекта по решению проблемы 2000-ного года
прийти к правильному заключению: изменения, внесенные в программное обеспече­
ние производственного процесса в период между тестированием и аттестацией, не
привели к созданию несовместимого программного обеспечения.
194 Часть II. Технологии быстрого тестирования и советы

Инспекции/критический анализ/
экспертные оценки
Экспертные оценки в той или иной форме используются в большинстве проектов по
разработке программного обеспечения. Одна из задач персонала подразделений
обеспечения качества состоит в выполнении статистических выборок, чтении и по­
метках пользовательской или клиентской документации. Эти действия квалифици­
руют как экспертную оценку. Иногда программист направляет листинги исходного
кода только что созданного модуля и его проектную документацию другому програм­
мисту с просьбой прочесть код и снабдить его пометками. Это также называется экс­
пертной оценкой. Программисты также делятся друг с другом отладочной информа­
цией с целью устранения особо трудно обнаружимых ошибок. Участие в таком свое­
образном клубе обмена информацией об ошибках тоже считается экспертной оцен­
кой. Хотя эти неформальные действия позволяют исправить множество ошибок, су­
ществует множество ошибок, которые остаются незамеченными, в основном из-за
недостаточной полноты и тщательности при проведении экспертной оценки. Спе­
циалисты по тестированию могут использовать экспертные оценки во время разра­
ботки сценариев тестирования, получения данных тестов и оценки результатов тес­
тирования.
С целью совершенствования методов экспертной оценки в качестве более полных
и тщательных средств поиска, документирования и исправления ошибок были разра­
ботаны методы формализованного критического анализа и инспекций. Критический
анализ предполагает, что автор документа или исходного кода программы представ­
ляет коллегам свой подход к использованию данного компонента программного про­
дукта. Группа коллег обсуждает предложенные автором подходы/алгоритмы, интер­
претации требований или метод документирования, задавая автору вопросы или
прося пояснений, пока вся группа не будет удовлетворена предложенными решения­
ми. Тестировщики могут также использовать критический анализ во время планиро­
вания тестов, подготовки тестовых случаев, получения данных и оценки результатов
тестирования.
Майкл Фаган впервые определил понятие инспекции во время работы в компании
IBM [34]. Инспекции определяется в качестве одной из форм экспертной оценки и
обладают рядом общих черт с неформальным просмотром кода и критической оцен­
кой. Инспекции начинаются с представления автором листинга исходного кода и
проектной документации модуля координатору инспекций.

Распределение ролей и обязанностей в группе

выполнения инспекций
Координатор инспекций выбирает четыре-пять инспекторов, один из которых на­
значается председателем комиссии по инспекциям. Координатор выбирает также
время и место проведения инспекций. Он подготавливает для команды проведения
инспекций четыре или пять пакетов документации, включающих в себя копии лис­
тингов модуля и соответствующей проектной документации, несколько форм ин­
спекций и соответствующих данному этапу контрольных перечней, составленных на
 Глава 9. Технологии статического тестирования и советы 195

базе опыта предыдущих инспекций. Эти пакеты документации передаются членам

комиссии не позже, чем за два дня до проведения заседания комиссии. Каждый член
комиссии по инспекциям должен быть тщательно подготовлен. Председатель комис­
сии и ее члены должны знать, что они должны потратить от одного до двух часов на
ознакомление с представленными на инспекцию материалами до начала заседания
комиссии. Каждый из инспекторов может делать пометки на листингах исходного
кода, а остальные комментарии вносятся в формы инспекций, входящие в состав па­
кета документации. Формы инспекций частично заполняются каждым членом комис­
сии до прихода на заседание. В том числе это относится к перечню возможных оши­
бок, областей, в которых возможны усовершенствования, замечаниям о несоблюде­
нии соответствующих стандартов и т.п. Накануне заседания председатель комиссии
должен предложить каждому члену комиссии еще раз убедиться в том, что они завер­
шили просмотр материалов, и сообщить уточненное время и место проведения засе­
дания. Календарный план типичной инспекции приведен в таблице 9.2, но при необ­
ходимости сроки выполнения отдельных этапов можно сократить до одного дня.

В ходе заседания председатель комиссии рассаживает участников заседания в со­

ответствии с рис. 9.5. Решение о количестве разработчиков и специалистов по тести­
рованию в составе комиссии принимается координатором инспекций и зависит от
характера пакета представляемой на инспекцию документации. Например, если это
план тестирования, в комиссии должны участвовать один-два специалиста по тести­
рованию и ни одного или один разработчик программного обеспечения. В то же вре­
мя, если представленный на инспекцию пакет содержит исходный код на языке C++,
196 Часть II. Технологии быстрого тестирования и советы

диаграмму потоков данных и диаграмму отношений объекта, за столом комиссии мо­

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

Задача председателя комиссии по инспекции состоит в выполнении функций,

способствующих проведению заседания комиссии. В этом качестве председатель ко­
миссии обеспечивает, чтобы снабженный документацией и развернутый в соответст­
вии с ранее упоминавшейся подготовкой процесс инспекций был выполнен в полном
объеме. Задача регистратора недостатков заключается в фиксации всех обнаружен­
ных комиссией дефектов, удаление любых дублированных замечаний, руководство
процессом уточнения формулировок каждого из обнаруженных просчетов, класси­
фицирование ошибок по уровню серьезности и присвоение им номера SEV перед
тем, как они будут внесены в формы инспекции и представлены координатору. Зада­
чи регистратора показателей сводятся к обеспечению учета дефектов (ошибок) и
возможных основных причин их возникновения или этапов жизненного цикла, на
которых они, скорее всего, были допущены. Кроме того, в задачи входит и фиксация
любых других текущих показателей инспекции проекта, таких как: общее время, за­
траченное членами комиссии на подготовку к инспекции, количество инспекторов в
комиссии, общее время, затраченное на инспекции, общее количество ошибок, све­
дения о которых были введены в базу данных недостатков, и т.п. Эти данные вводят­
ся в формы инспекций. Председатель собирает формы у всех комиссии, после чего
 Глава 9. Технологии статического тестирования и советы 197

обновляет базы данных дефектов, показателей и контрольных перечней и представ­

ляет печатную копию сводного пакета документации координатору инспекций.

Отчетность о процессе выполнения инспекций

Координатор инспекций обеспечивает максимально быстрый ввод сведений об
ошибках, зафиксированных в пакете документации по инспекции, в общую базу дан­
ных дефектов проекта. Еще одна отличительная черта быстрого тестирования за­
ключается в том, что некоторые из этих недостатков помечаются как "блокирующие",
т.е. данная ошибка непосредственно препятствует дальнейшему тестированию кон­
кретной функции. О выявлении блокирующих ошибок и ошибок уровня SEV 1 (ката­
строфических) следует немедленно сообщать команде разработки, чтобы она смогла
выполнить отладку.
Основная цель быстрого тестирования состоит в обнаружении и исправлении
ошибок в кратчайшие строки. Сохранение данных о каждой ошибке может сущест­
венно повысить точность и значимость процесса инспекции. Контрольный пере­
чень, составленный на основе полученного опыта, должен создаваться для каждого
этапа жизненного цикла. Эти сгруппированные по этапам контрольные перечни
должны стать действующими документами, отражающими данные о новых ошибках,
которые получаются в результате какой-либо инспекции. Комиссия по инспекции
может выполнить общий анализ каждой ошибки с целью выяснения этапа, на кото­
ром она была допущена. Эта комиссия должна добавить полученные сведения в кон­
трольный перечень данного этапа, чтобы следующая комиссия, выполняющая ин­
спекцию материалов в рамках этапа, наверняка обнаружила ошибку, аналогичную
обнаруженной ранее. Такая обратная связь, реализуемая для каждой ошибки, делает
контрольный перечень инспекций постоянно совершенствующимся документом. А
это, в свою очередь, является отличительной чертой организации, которая обучается
на собственных ошибках.

Показатели процесса инспекции

Показатели, полученные в результате проведения инспекций, непосредственно за­
гружаются в модель ошибок проекта. Количество дефектов на тысячу исходных строк
кода объединяется с другими показателями инспекций, получаемыми в течение оп­
ределенного периода времени, например, ежедневно, еженедельно или в течение
этапа разработки, и добавляется к входным данным программы оценки погрешности
программного обеспечения (Software Error Estimation Program, SWEEP). Программа
SWEEP подробно описывается в главе 11.

Использование электронной почты или другого

электронного приложения для ускорения
процесса инспекции
Для обеспечения быстрого тестирования на протяжении всего жизненного цикла
проекта разработки программного обеспечения должны интенсивно использоваться
разнообразные способы повышения эффективности. Существует несколько техноло-
198 Часть II. Технологии быстрого тестирования и советы

гий, которые применяются не только к процессу инспекции, как описано в этом раз­
деле, но и к другим процессам в рамках цикла разработки. Предполагается, что ко­
манда разработки программного обеспечения создает исходный код на компьютерах,
которые связаны между собой локальными сетями (local area networks — LANs). За
счет использования серверов локальной сети или архитектуры типа сервер-
хранилище данных (storage area network, SAN) любой участник проекта должен иметь
возможность доступа к общим хранилищам данных проекта. В таких сетях поддержи­
ваются структуры каталогов, которые должным образом организуют данные по раз­
работке и тестированию. При этом предусматривается их регулярное резервное ко­
пирование в соответствии с установленным календарным планом. В качестве альтер
нативы технологии LAN/SAN управление хранилищем данных проекта может осу­
ществляться также с помощью некоторого электронного приложения, действующего
на Web-сайте проекта в рамках корпоративной сети организации. Это приложение
должно заботиться о сохранении документации по разработке в системе управления
конфигурациями, которая реализует строгий контроль версий и регулярно, в соот­
ветствии с календарным планом, выполняет резервное копирование.
Используя встроенный календарь и обмен сообщениями по электронной почте
локальной сети организации, персонал, занятый проектированием, может резерви­
ровать конференц-залы и приглашать участников каждой инспекции. Во время раз­
работки проекта, при которой задействованы методы быстрого тестирования, по­
добное повышение эффективности ведет к уменьшению временных затрат коорди­
натора инспекций на резервирование конференц-зала и приглашение всех инспекто­
ров на время, не связанное с какими-либо накладками. Соблюдение этого условия
обеспечивается координатором, который при выборе подходящего времени и места
заседания может просматривать календарные планы всех кандидатов в инспекторы.
Корпоративная инфраструктура, образующая корпоративную сеть организации, пре­
доставляет также доступ к пакету документации по инспекциям, который может быть
оформлен в виде набора гиперссылок в сообщениях электронной почты на доступ­
ные только для чтения версии форм и документов в общих хранилищах данных. Кро­
ме того, копии одних и тех же общих файлов могут добавляться в виде присоедине­
ний к календарным назначениям, рассылаемым всем инспекторам.
Инспекция — это инструмент статического тестирования, который может приме­
няться для всех программных документов, начиная с этапа разработки требований и
заканчивая этапом приемочных испытаний. Быстрое тестирование предполагает
постоянный контроль на предмет возникновения ошибок, которые должны быть об­
наружены и исправлены как можно скорее после их возникновения. Поскольку ин­
спекции должны выполняться применительно к документу, который разрабатывается
на данном этапе жизненного цикла, все обнаруженные в ходе инспекций дефекты
должны отслеживаться вплоть до основной причины их возникновения. Затем ко­
миссия по инспекциям должна обновить контрольные перечни данного этапа, чтобы
будущие комиссии не пропустили эти же или аналогичные ошибки. Ниже приведены
характеристики инспекций, которые соответствуют требованиям быстрого тестиро­
вания:
• В результате инспекций создаются списки ошибок, каждой из которых присво­
ен номер уровня серьезности, характеризующий приоритет процесса ее устра-
 Глава 9. Технологии статического тестирования и советы 199

нения. Список ошибок вносится в базу данных дефектов и используется при

внесении изменений в систему, положенную в основу будущих версий.
• В результате инспекций создаются версии контрольных перечней для одного
или более этапов, на основе которых инспекторы выполняют анализ основных
причин возникновения дефектов. Эти контрольные перечни полностью гото­
вы к использованию во время следующего выполнения данного этапа в рамках
текущего или другого проекта.
• В результате инспекций определяются показатели, которые управляют харак­
теристической моделью ошибок проекта и служат входными данными для про­
граммы оценки погрешности программного обеспечения (SWEEP), используе­
мой для прогнозирования скрытых дефектов, остающихся в самом программ­
ном продукте. Эти показатели служат также основой для постоянного совер­
шенствования процесса выполнения инспекций. Программа SWEEP подробно
описывается в главе 11.
• Инспекции способствуют повышению квалификации инспекторов, которые,
возвращаясь к выполнению своих обязанностей разработчика, имеют более
глубокие знания о продукте или требованиях, архитектуре, проекте и запро­
граммированных алгоритмах, а также о типах ошибок, которые следует отсле­
живать во время работы над их собственными рабочими продуктами.
Из этого определения процесса инспекции, которое было разработано специаль­
но для быстрого тестирования, должно быть понятно, как именно объединять эту
форму статического тестирования с реальным процессом разработки, и какое значе­
ние придается быстрому повышению качества результирующего продукта. Процесс
инспекции, выполняемый в ходе быстрого тестирования, сокращает календарные
сроки за счет исправления ошибок в ходе разработки, а не ближе к ее завершению.

Формальная верификация
Верификация — это действия по проверке выполнения на пом этапе разработки того,
что было запланировано на (п-1)-ом этапе. Во время создания архитектуры системы
и при определении требований производительности специалист по тестированию
должен сравнивать обусловленные архитектурой ресурсы производительности с об­
щими требованиями. Во время тестирования рабочей проектной документации тес-
тировщик будет сверять эту документацию с документацией по архитектуре, которая
была разработана на этапе высокоуровневого проектирования. На этапе создания
кодов тестировщик будет проверять код, сравнивая его с рабочей проектной доку­
ментацией. Например, в соответствии с рабочей проектной документацией для реа­
лизации некоторой функции должны быть созданы пять модулей, причем одним из
них является комплекснозначный алгоритм быстрого преобразования Фурье (БПФ).
В такой ситуации среди множества тестовых случаев должен существовать случай,
ориентированный на проверку кода БПФ во время выполнения и обеспечивающий
оценку точности, эффективности и всех встроенных функций, которые могут при­
сутствовать.
200 Часть II. Технологии быстрого тестирования и советы

Языки на основе спецификаций

Одно из средств в инструментальном наборе специалиста по тестированию носит
название программного доказательства. Данное средство относится к категории
формальной верификации, поскольку при этом подтверждается соответствие кода
его рабочему проекту. Программное доказательство начинается с формулировки на
специальном языке теоремы или леммы (называемой спецификациями) непосредст­
венно в основном коде, а именно — в заголовках каждого главного блока кода. Затем
пользователь интерактивно взаимодействует с автоматизированным средством дока­
зательства теоремы с целью определения соответствия кода приведенной теореме
или лемме. Такого рода языки называют языками на основе спецификаций или язы­
ками утверждений, а на инструментальное средство ссылаются как на средство фор
мальной верификации. Хотя в настоящее время подобные средства редко применя­
ются при промышленной разработке программного обеспечения, тем не менее, они
заслуживают того, чтобы включить их в арсенал инструментов тестирования.

Автоматизированное доказательство теорем

У нас имеется определенный опыт выполнения программных доказательств с ис­
пользованием компьютеризованной утилиты доказательства теорем Gypsy [18] для
проверки приблизительно тысячи строк кода. Принцип работы утилиты Gypsy за­
ключается в следующем. Сначала тестировщик помещает формулировки теорем и
лемм вместе с блоками кода, написанного на языке Gypsy (один из вариантов языка
Pascal). Затем встроенный в Gypsy модуль доказательства теорем проверяет правиль­
ность реализации блоком кода всех утверждений, сформулированных в теоремах и
леммах. Алгоритм, корректность работы которого довелось доказывать с помощью
этого средства формальной проверки, носил название Collision Avoidance (исключе­
ние столкновений). В настоящее время упомянутый алгоритм реализован в компью­
терных системах Федерального авиационного агентства США для предупреждения
самолетов о грозящих столкновениях. Для достижения этой цели на самолетах, а
также на высоких зданиях и горах устанавливаются радиомаяки-ответчики. Эти мая­
ки-ответчики передают цифровые пакеты, содержащие данные о таких динамиче­
ских характеристиках полета, как высота, скорость и направление полета. На базе
математических моделей динамики полета выполняется имитационное моделирова­
ние для данных из полученных цифровых пакетов, цель которого заключается в оп­
ределении вероятности столкновения, а также в выработке необходимой тактики
предотвращения столкновения. Эти данные автоматически и заблаговременно пере­
даются на борт самолетов с пересекающимися траекториями полета и позволяют
предотвратить столкновение. Таким образом, очевидно, что код алгоритма исключе­
ния столкновений должен быть корректным, причем доказуемо корректным.
Вначале программа исключения столкновений была переведена на язык Gypsy, и
для каждого блока кода были сформулированы теоремы. Затем при помощи возмож­
ностей Gypsy по доказательству теорем было установлено, что все теоремы в коде
реализованы. В ходе процесса была обнаружена одна программная ошибка, после
чего в исходный код были внесены соответствующие исправления. Процесс оказался
безболезненным и действительно эффективным.
 Глава 9. Технологии статического тестирования и советы 201

Средства автоматизации тестирования

Существует множество средств автоматизированного статического тестирования.
Большинство из них являются специализированными средствами, а не одним уни­
версальным инструментом, которое могло бы применяться во всех случаях. Еще одна
отличительная особенность этих средств статического тестирования — их зависи­
мость от языка. Обнаружение ошибок в исходном языке или в языке документации
предполагает выделение ошибок, в том числе орфографических, синтаксических,
ошибок, связанных с неопределенными переменными и указателями, незакрытыми
программными конструкциями, неопределенными ссылками, включая Internet-
адреса, и т.д.

Прослеживаемость требований
Прослеживаемость требований означает сохранение формулировки требования от
момента его указания до момента выполнения. Из главы 8 уже должно быть известно,
что результатом совместной разработки требований к приложению (Joint Application
Requirement, JAR) является набор требований к программному обеспечению. После­
дующие требования разбивают исходные на набор производных требований, кото­
рые, как правило, документируются в спецификации проекта программного обеспе­
чения (Software Design Specification, SDS). Мы уже рассмотрели существующие воз­
можности статического тестирования этой переформулированной версии требова­
ний, которые позволяют обнаружить пропущенные, неверно сформулированные,
двусмысленные и попарно конфликтующие требования, приводящие к ошибкам в
спецификации проекта программного обеспечения. Обнаружение ошибок в требова­
ниях — наибольший выигрыш, даваемый всеми формами тестирования. В рамках па­
радигмы быстрого тестирования определяется матрица прослеживаемости требова­
ний (Requirements Traceability Matrix, RTM), за счет использования которой группа
разработки, включая тестировщиков, демонстрирует свою заинтересованность в со­
блюдении и полноте тестирования требований. При этом на протяжении всего жиз­
ненного цикла разработки применяются как статические, так и динамические сред­
ства тестирования.
С другой стороны, если применяется методика, отличная от быстрого тестирова­
ния, и тестирование начинается лишь тогда, когда разработка программного обеспе­
чения подходит к концу, то для получения RTM, которая будет использоваться для
планирования тестирования в ходе оставшейся части жизненного цикла разработки,
придется выполнить реконструирование требований.

Программа контроля единиц измерения

физических величин
Огромную помощь в разработке научных программ оказывает программа контроля
единиц измерения физических величин. Эта программа представляет собой статиче­
ский препроцессор исходного кода, который проверяет, что результат каждого ма­
тематического выражения выражается в соответствующих единицах измерения фи­
зических величин. Рассмотрим выражение для определения частоты (R) или скоро-
202 Часть II. Технологии быстрого тестирования и советы

сти: R1= D1/T1, где D1 — пройденное расстояние, а T1— время передвижения. Это
выражение справедливо только в том случае, если единицы измерения физических
величин совместимы. Иначе оно будет неверным. Например, если расстояние
выражается в километрах, а время — в минутах, то скорость, вычисляемая в
соответствии с этим выражением, должна выражаться в км/мин. Если это значение
скорости необходимо вставить в другое выражение, в котором скорость должна
выражаться в милях в час (миль/ч), вначале потребуется выполнить преобразование
R1 (км/мин) в R2(миль/ч).
При реализации в качестве статического средства контроля программа контроля
единиц измерения физических величин содержит дополнительные спецификации
ввода всех переменных, хранящих физические величины, которые определены в
специально сформатированных строках исходного кода. При каждом использовании
или определении этих переменных формулы проверяются на предмет того, что пе­
ременные в левой части выражения (результаты) получают единицы измерения на
основе вычислений и на базе объявленных единиц измерения, которые связаны с
переменными из правой части (входные переменные).

Символьное выполнение
Символьное выполнение — это технология подстановки символов в формулы, зако­
дированные внутри языка программирования с выполнением алгебраического объе­
динения символов в соответствии с алгоритмом. Рассмотрим код функции вычисле­
ния синуса SINE, приведенный на рис. 9.6. Этот алгоритм содержит минимальное
количество произведений, как показано в следующем выражении:
sin(x) = х*(1 - х *(1/3 ! - х *(1/5 ! - х *(1/7 ! - х *(...))))).
2 2 2 2
 Глава 9. Технологии статического тестирования и советы 203

Программа символьного выполнения осуществляет математические упрощения

для реализации приведенных в таблице 9.3 шагов алгоритма, который представляет
собой известный метод разложения в ряд Тейлора.
Полученные результаты можно сравнить со значением функции sin(x), получен­
ным из большинства математических справочников, а именно:
sin(x) = х- x /3!+x /5! + x /7!...
3 5 7

Повторимся еще раз: из этого описания понятно, почему символьное выполнение

является средством статического тестирования. Это связано с тем, что для выполне­
ния алгоритма не требуется ввод числовых данных.

Листинги перекрестных ссылок

Листинги перекрестных ссылок — это зависящее от языка средство тестирования и
отладки, которое индексирует использование переменных внутри каждого модуля.
Некоторые перекрестные ссылки включают в себя список строк исходного кода, в
которых переменные используются или определяются. Это позволяет тестировщику
выявлять неправильно введенные имена переменных, приводящие к возникновению
программных ошибок. Неправильно введенная переменная будет либо неопределен­
ной, либо использоваться в вычислении, в котором присутствовать не должна. В
большинстве компиляторов такая функция реализована.

Программы улучшенной печати

Программы улучшенной печати — это зависимое от структурированного языка сред­
ство тестирования, обеспечивающее корректное завершение каждой структурной
конструкции. Например, если в конструкции IF-THEN-ELSE-ENDIF отсутствует клю­
чевое слово ENDIF, при улучшенной печати структура будет выглядеть неправильно
выровненной. Это часто приводит к ошибке, поскольку часть ELSE может содержать
выражение, которое не должно выполняться. Во многих компиляторах структуриро­
ванных языков такая функция реализована.
204 Часть II. Технологии быстрого тестирования и советы

Средства сравнения версий

Средства управления конфигурациями обеспечивают выбор в качестве последней
версии такой, которую можно проверить на предмет изменений. Эти средства служат
для упрощения работы создателей программного обеспечения. Например, если два
разработчика проверяют одну и ту же версию исходного кода и начинают вносить в
нее изменения, то когда они одновременно делают попытку вернуться обратно к
проверке, возникает дилемма. Определить, какая версия должна проверяться пер­
вой, может помочь только какой-нибудь механизм блокировки, предоставляемый
средством управления конфигурациями. После этого оба автора могут прийти к со­
глашению о способе объединения конфликтующих изменений. Еще одно применение
средства сравнения версий связано с проверкой на полное совпадение файла и одной
из версий, поддерживаемых системой управления конфигурациями.
Ряд дополнительных функций средства управления конфигурациями помогают
испытателям определить, вносились ли изменения в исполняемый код или в файлы
данных между двумя последовательными версиями. Эти функции называются средст­
вами сравнения версий. Средство сравнения версий осуществляет сравнение одной
ячейки за другой, выделяя различия между двумя ячейками. При этом термин "ячей­
ка" может означать строку исходного кода или поле данных внутри записи. Специа­
листы по тестированию и разработчики должны обмениваться информацией об об­
ластях изменений в новых версиях. Как правило, это делается при помощи записей.
Это же средство может использоваться и в качестве инструмента предотвращения
ошибок во время проверки измененных областей. Естественно, неизменные области
могут потребовать регрессивного тестирования для обнаружения возможных побоч­
ных эффектов, но тестовые случаи, предназначенные для проверки неизмененных
областей кода, наверняка не потребуют повторного выполнения. Таким образом, ис­
пользование средства сравнения версий может привести к повышению эффективно­
сти работы персонала, занятого быстрым тестированием.

Тестирование алгоритмов
Если перед тестировщиком поставлена задача тестирования модуля, который реали­
зует преобразование данных по определенному алгоритму, наиболее строгий подход
предполагает разработку входных и ожидаемых результирующих данных, которые
позволят испытать возможности, варианты выполнения и условия возникновения
ошибок алгоритма. Например, если перед специалистом по тестированию стоит за­
дача проверки алгоритма быстрого преобразования Фурье, проверке должны под­
вергаться несколько свойств этого преобразования. Поскольку быстрое преобразо­
вание Фурье является линейным, тестировщик создает тестовый случай для проверки
равенства T(a*f1 + b*f2) = a*T(f1) + b*T(f2). Поскольку быстрое преобразование Фурье
является обратимым, тестировщик может выполнить прямое преобразование от­
дельных частот в спектральную функцию, а затем подвергнуть эту спектральную
функцию обратному преобразованию и убедиться в совпадении результата с исход­
ными отдельными частотами, т.е. в том, что Т-1[T(f)]=f. На этом этапе тестировщик
может прийти к выводу, что код реализует обратимое линейное преобразование, но
вопрос о том, является ли алгоритм действительно преобразованием Фурье, остается
 Глава 9. Технологии статического тестирования и советы 205

открытым. Специалисту по тестированию наверняка придется создать данные для

фиксированной частоты, для которой спектральная функция имеет только одну не­
нулевую составляющую на выбранной частоте, и убедиться, что ее амплитуда имеет
правильное значение. За этим тестовым случаем могут прогоняться случаи для сле­
дующей "чистой" частоты и так далее, пока не будут протестированы все частоты и
амплитуды.
Однако этот строгий подход относится к категории динамического тестирования,
которое представляет собой тему главы 10. Значительно больший объем тестирова­
ния этого алгоритма можно предпринять во время его разработки с одновременным
использованием статического тестирования. При разработке требований упомяну­
тый алгоритм формулируется, например, так: "Пользователь должен располагать
утилитой, которая будет выполнять быстрое преобразование Фурье для комплексных
данных, длина которых составляет степень двух, вплоть до 2 включительно". Эта
10

формулировка понятна персоналу инженерной или физической лаборатории, но

разработчик программного обеспечения может не обладать достаточной математи­
ческой подготовкой. Во время эскизного проектирования это требование должно
быть разбито на более понятные части. Прежде всего, входные и выходные данные
помещаются в два двумерных массива длиной n, имеющие тип COMPLEX и макси­
мальную длину 2 , во флаг ошибки типа INTEGER и в переменную N типа INTEGER,
10

значение которой лежит в интервале [2,10]. Приведенная информация эскизного

проекта определяет пользовательский интерфейс, который дает возможность подго­
товить прототип, или заглушку, для помещения ее в графический интерфейс пользо­
вателя на этапе эскизного проектирования до того, как будут получены необходимые
разъяснения от персонала инженерной или физической лаборатории.
На этапе рабочего проектирования алгоритм быстрого преобразования Фурье
должен быть тщательно проанализирован. Здесь же понадобиться выбрать либо его
оригинальную версию, разработанную Кули (Cooley) и Туки (Tukey) в 1965 году [12],
либо какую-нибудь другую модификацию из более новых. Потребуется принять ряд
решений относительно порядка обработки. Например, нужно ли применять обрат­
ный порядок следования разрядов выходных данных перед завершением преобразо­
вания, или предварительно сортировать таблицу данных синусов и косинусов с ис­
пользованием алгоритма с обратным порядком следования разрядов, после чего со­
хранять данные в фиксированной области памяти с тем же обратным порядком сле­
дования разрядов. Необходимо также принять решения относительно требования к
точности алгоритма. Это решение должно подкрепляться задокументированными
ссылками на техническую литературу, которая обосновывает требования по тестиро­
ванию точности результирующего алгоритма преобразования. Кроме того, нужно
определить и требования ко времени выполнения преобразования, чтобы можно
было проанализировать, достаточно ли будет скалярного процессора, или же потре­
буется процессор, в архитектуре которого реализованы векторные инструкции и дру­
гие функции обработки массивов.
Этапы проектирования программного обеспечения служат фундаментом для раз­
работки требований, и все тестирование, выполняемое во время проектирования, за
исключением динамического тестирования прототипов, является статическим. Мно­
гие решения, которые должны быть приняты во время рабочего проектирования,
могут оказаться ошибочными и вести к значительным перерасходам средств или к
206 Часть II. Технологии быстрого тестирования и советы

формулированию требований, которые не могут быть выполнены. Подход к этому

вопросу с использованием быстрого тестирования заключается в сосредоточении
усилий на поиске компромиссных решений на этапе рабочего проектирования. Затем
компромиссные решения могут использоваться в качестве средства предотвращения
изменчивости требований — одной из основных причин повышения затрат в ходе
разработки с традиционным каскадным жизненным циклом. Компромиссные реше­
ния — это форма оптимизации перед утверждением окончательного варианта проек­
та, которая предотвращает многократное выполнение дорогостоящих разработок и
динамического тестирования для отброшенных проектов/реализаций. В большинст­
ве финансовых оценок Института технологий программного обеспечения (Software
Engineering Institute, SEI) финансовые инспектора фиксируют многочисленные на­
рушения в области проектирования программного обеспечения. Мы называем это
явление "выбоинами" процесса разработки — "ямами" на дороге, которые иногда мо­
гут повредить движущийся по ней проект. Быстрое тестирование — это искусство
расстановки по всему жизненному циклу разработки специалистов по тестированию,
которые обнаруживают и сообщают о недостатках, как только они появляются.

ПРИМЕР: АН А ЛИ З ОБЩ Е Й ОШИ БК И ОКРУГЛЕНИЯ (ГЭРИ КОББ)

Еще одна область применения статического тестирования, которая особенно характерна
для сфер ы научного программирования, — это анализ общей ошибки округления. Для
то г о чтобы убедить в необходимости выполнения этой ф о р м ы тестирования, стоит лишь
сослаться на один реальный случай из личной практики. В начале семидесятых компания,
в которо й я работал, заключила с одним из клиентов контракт на перенос их програм м ­
ного обеспечения из скалярного компьютер а в векторный . В части контракта, касающей­
ся приемк и конечных продуктов , было оговорен о следующее условие: на векторном
компьютере преобразованные программы будут выполняться в 256 раз быстрее и выдавать
те же шестнадцатеричные результаты, что и при выполнении на скалярном компьютере.
К момент у назначения меня на должность руководителя группы преобразования про­
гр а м м н о г о обеспечения, я выполнил оценк у основных характеристик каждо й из основ­
ных преобразуемы х систем, как с точки зрения времени выполнения, так и в плане по­
лучения распечаток входных и выходных переменных при прогоне програ м м для данных,
которы е владельцы приложений считали типовыми. Мн е казалось, что это должн о было
помочь выполнить условия получения приемлемой производительности для выбранного
метода преобразования. Вскоре после начала преобразования программн ог о обеспече­ ния
один из моих сотрудников пришел к шутливому выводу: одно из выходных шестна-
дцатеричных значений было названо W W M , что означало "worldwid e mass" ("масса
земн ог о шара"). Это значение было результатом суммирования масс всех ячеек сетки
наброшенной на весь земной шар. После совместной работы мы установили, что такое
вычисление приводило к переполнению значения с плавающей точкой при обходе при­
мерн о половины земног о шара, поскольку накапливаемая сумма становилась настолько
большой, что добавление массы остальных ячеек сети не вело к изменению с ум м ы . Бо­
лее того , скалярный компьюте р выполнял 36-разрядные операции с плавающей точкой , в
то время как векторный компьюте р мог выполнять 32- или 64-разрядные векторные
операции с плавающей точкой. Мы явно оказались в проигрышной позиции. Если выпол­
нять сложение с одинарной точностью, переполнение возникло бы прежде , чем удалось
добраться даж е до середины сетки (т.е . шестнадцатеричный результат отличается от
получаемого на скалярном компьютере) . Если же выполнять суммирование с двойной
точностью, вычисление выполнялось бы медленнее (невозможн о было получить 256-
кратное увеличение производительности), и переполнение начинало бы возникать при
обходе примерно 3 / 4 сетки (шестнадцатеричный результат отличается от первоначаль-
 Глава 9. Технологии статического тестирования и советы 207

Для того чтобы отстоять примененный нами мето д достижения оговоренной в контракте
производительности в данном случае, пришлось доказать, что базовая программ а полу-
чает неверное значение массы земног о шара и поэтому преобразованная программ а не
должна получать такой же ошибочный результат.
Приложение анализа общей ошибки округления суть технология статического тестирова-
ния, берущая свое начало из области численного анализа, которы й подробно преподает­
ся на университетских курсах по теории вычислительных машин и систем . В этой теории
каждая переменная входных данных имеет связанный с ней векто р ош ибо к . Если
Xi=Ci+ci, а У i =D i +d i то ошибка E определяется следующи м выражением :
SUM ( X i + Y i )= S UM( C i + D i ) + E(N) для i = 1 , ..., N, где E(N)=SUM(c i + d i ) для i=1, ..., N
Далее, поскольку при считывании входных значений ком пьют е р всегда усекает действи­
тельные значения Xi и Y i значения сi и di всегда будут неотрицательными усеченными
значениями. Следовательно, функция ошибо к E(N) монотонн о возрастает и является не-
ограниченной сверху. Этот численный анализ м о ж е т быть выполнен применительно к бо ­
лее сложны м алгоритмам для проверки их ограничений по стабильности.
Подводя итог этому реальному приме ру , отметим следующее : тестировщики, имеющи е
дело с научными приложениями, должн ы уметь выполнять численный анализ сложных
алгоритмов, чтобы определить граничные условия компьютерных имитаций, в которы х
задействованы эти сложные алгоритмы. Хотя упомянутые требования могу т казаться не­
померно высокими для тестировщиком, они помогаю т показать ценность специалистов,
обладающих подготовкой в области численного анализа или общей математической под­
готовкой. Такие специалисты по тестированию смогу т обнаружить нестабильные алго­
ритмы и отыскать для них стабильные альтернативы, которы е окажутс я горазд о более
предпочтительными для компьютерных имитаций, особенно в сфер е научного
программирования.

Диспетчер тестирования
Роль диспетчера тестирования заключается в организации и направлении повсе­
дневного продвижения и отслеживании состояния тестирования с использованием
подхода быстрого тестирования. В небольших проектах эту роль может выполнять
руководитель проекта. В средних проектах эта должность может называться "руково­
дитель тестирования". В случае очень больших проектов, во время динамического
тестирования эти обязанности могут выполняться отдельным, полностью занятым
только этой работой лицом, работающим с командой тестирования, специалистами
по сетям, администраторами баз данных, техниками лаборатории тестирования и
бизнес-аналитиками, которые представляют интересы сообщества пользователей.
При выполнении тестирования применимости эта должность может называться за­
ведующим лабораторией применимости. Такой заведующий призывает посетителей
из сторонних организаций испытать новый набор продуктов и технологий на пред­
мет удобства его использования в реальных сценариях.
Роль диспетчера тестирования заключается в изучении планов тестирования про­
екта и реализации следующих координационных действий:
• Определение и управление календарными графиками загрузки персонала, ко­
торые потребуются для прогона полного набора тестовых случаев.
• Обеспечение соответствия порядка выполнения тестов потоку данных в про­
граммном обеспечении.
• Документирование сценариев тестирования.
208 Часть II. Технологии быстрого тестирования и советы

• Проектирование форм отчетности по тестированию, которые будут запол­

няться, анализироваться и сравниваться с данными результатов прогона тес­
тов.
• Сбор данных о состоянии тестов, выполняемых в реальном времени, и состав­
ление соответствующих отчетов.
Как видите, роль диспетчера тестирования в чем-то аналогична роли режиссера
кинофильма или мультимедиа-продукта. Без диспетчера тестирования отдельные
тестировщики, каждый из которых работает с собственным поднабором тестов, соз­
давали бы хаос из-за недостаточной согласованности календарного графика выпол­
нения тестирования, тестовых платформ, недостаточно полного совместного ис­
пользования файлов, отсутствия "снимков" результатов тестирования и резервных
копий, которые потребуются для генерирования среды каждого тестового случая.
Параллельное выполнение тестирования несколькими специалистами с использова­
нием независимых и разделяемых сетевых ресурсов требует наличия организованно­
го плана, согласованного выполнения и обобщения результатов. Защита интересов
конечных пользователей, выполняется ли она бизнес-аналитиками, сопровождаю­
щими большие действующие информационные системы, или псевдо-конечными
пользователями коммерческого продукта, требует присутствия специально назна­
ченного лица, а именно диспетчера тестирования. Диспетчер должен обеспечивать
готовность календарных графиков, ресурсов и данных к моменту начала тестирова­
ния, а по завершении тестирования тот же диспетчер должен составлять списки про­
блем с их приоритетами и передавать все материалы в команду разработки.
Часто планы тестирования требуют тестирования совместимости для нескольких
конфигураций, например, Wintel PC, MAC, Linux и PDA, каждая из которых имеет
множество периферийных устройств типа сканеров, принтеров, модемов, дисково­
дов CD-RW, видеокамер, джойстиков и удаленных клавиатур или игровых устройств
ввода/вывода. Кроме того, тестовое оборудование может потребоваться для тести­
рования нескольких проектов, поэтому между сеансами тестирования возникает не­
обходимость в сборке или разборке конфигураций. С целью оптимизации и эффек­
тивного управления лабораторией тестирования создается должность диспетчера
тестирования, которому часто помогают несколько техников этой лаборатории.
Диспетчер дает указания техникам по установке тех или иных аппаратных и про­
граммных платформ и сетевых ресурсов, задействованных в нескольких проектах. Он
же планирует время работы лаборатории и обслуживающего персонала. В подразде­
лениях информационных технологий эта задача может оказаться очень сложной и
должна выполняться несколькими диспетчерами тестирования. При этом должны
использоваться компьютерные системы на базе мейнфреймов и множества термина­
лов или ПК для бизнес-аналитиков, которые соединяются между собой через гло­
бальную корпоративную сеть. Кроме того, для имитации реальной производственной
среды корпоративная сеть должна иметь соединения электронного обмена данными
(electronic data interchange, EDI) со множеством серверов бизнес-партнеров; подоб­
ные соединения получили название телекоммуникаций типа "бизнес-бизнес" (busi­
ness-to-business, В2В).
 Глава 9. Технологии статического тестирования и советы 209

Базы данных материалов совместного

использования
Когда команда тестирования обнаруживает проблему в программном обеспечении,
последняя должна быть зарегистрирована, должен быть определен ее приоритет,
установлен календарный график ее устранения командой разработки, определен
график подготовки версии к тестированию, выполнено повторное тестирование на
предмет устранения первоначальной проблемы и возникновения побочных эффек­
тов. Простейший способ решения этих проблем заключается в использовании базы
данных материалов совместного использования. Каждая запись в этой базе данных
представляет одну проблему и имеет поля, заполняемые каждым сотрудником, кото­
рый сталкивался с данной проблемой. Для обеспечения эффективного поиска нуж­
ных материалов база данных материалов совместного использования может быть
отсортирована и разбита на отдельные базы данных по каждой программной подсис­
теме, по штату разработки каждой программы, по используемому программному
обеспечению других организаций и по каждому типу проблем. Кроме того, админи­
страторы базы данных должны часто выполнять вставку обновленных записей в базу
материалов совместного использования.
Для проверки того, что проблемы отслеживаются, а сведения о них сообщаются
всеми организациями-участниками разработки, необходимо выполнять периодиче­
ские просмотры и оценки состояния базы данных. Как правило, команды разработки
сопровождают несколько версий результирующего продукта. В некоторых случаях
сопровождение или создание версии может выполняться отдельным лицом, назы­
ваемым создателем версии. Для этих версий должны составляться календарные пла­
ны и предусматриваться повторное тестирование, при этом база данных материалов
совместного использования будет обновляться текущими данными таких сеансов по­
вторного тестирования.
Современной реализацией базы данных материалов совместного использования
должен быть защищенный Web-сайт, управляемый базой данных, который находится
в экстрасети, принадлежащей генеральному подрядчику. Для обеспечения возможно­
сти обновления и внесения изменений в соответствующие записи базы данных со
стороны персонала каждого проекта потребуется создать программы обслуживания
приложений (application service program, ASP) с механизмом транзакций. Подобная
реализация обеспечивает полностью авторизованное сотрудничество партнеров по
разработке, поддерживая отсортированные по приоритетам списки проблем. Имен­
но поэтому описанная система рассматривается как успешная реализация концепции
быстрого тестирования.

Резюме
В этой главе был исследован набор реальных технологий, которые тестирующая ор­
ганизация должна немедленно взять на вооружение, если она желает ступить на путь
быстрого тестирования. На основании главы 7 можно сделать вывод, что сильным
аргументом в пользу применения технологий быстрого тестирования служит воз­
можность завершения разработок вдвое быстрее при использовании вдвое меньшего
количества людей и при допуске вчетверо меньшего количества скрытых дефектов в
210 Часть II. Технологии быстрого тестирования и советы

конечном продукте. Основная идея этой главы, посвященной статическому тестиро­

ванию, состоит в том, что в рамках жизненного цикла разработки необходимо как
можно раньше приступать к поиску ошибок и вводу отчетов об ошибках в базы дан­
ных совместного использования. Точно так же быстро следует исправлять ошибки и
извлекать соответствующие уроки, помещая сведения об ошибках в контрольные пе­
речни и модели надежности. В конце концов, эффективность проделанной работы
должна оцениваться, прежде всего, на основе количества обнаруженных ошибок. По­
стоянное совершенствование процесса разработки приводит к снижению числа до­
пускаемых просчетов, уменьшает количество персонала, необходимого для этапов
динамического тестирования и снижает количество рекламаций со стороны
клиентов.
 Технологии
динамического
тестирования
и советы
Темы, рассматриваемые в главе:
• Функциональное тестировани е и анализ
• Разделение по классам эквивалентности
• Анализ граничных значени й
• Отрицательное тестировани е
• Тестирование на основе определени я степени риска
• Определение полноты охвата ветвей
при тестировании
• Тестирование случаев использования
• Псевдоотладка/видоизменени е
• Трассировка/трассировк а снизу вверх /
мгновенные дампы/постпечат ь
• Создание точек прер ыва ния / правк и
• Тестирование потока данных
• Тестирование на предмет утечек памяти
• Тестирование интерфейс а "человек-компьютер"
• Тестирование нагрузочной эффективност и
• Тестирование конфигурации платформы
• Резюме
212 Часть II. Технологии быстрого тестирования и советы

У читателей может возникнуть вопрос: "Какие ошибки могут остаться незамечен­

ными после интенсивного применения технологий статического тестирования, ти­
пичных для методики быстрого тестирования?" Ответ очень прост: скрытые ошибки.
Скрытые ошибки — это ошибки, которые существуют, но не обнаружены. В среднем
программы, попадающие к конечным пользователям, содержат от 0,2 до 20 скрытых
ошибок на тысячу инструкций исходного кода (К delivered source instructions, KSDI).
В случае интенсивного применения технологий статического тестирования при раз­
работке проекта, к началу динамического тестирования количество скрытых ошибок
должно снизиться на 65—80%. Остальные 20—35% скрытых ошибок должны быть об­
наружены на этапах тестирования модулей (ТМ), комплексных испытаний (КИ), сиес-
темных испытаний (СИ), приемочных испытаний (ПИ) и сопровождения.
В течение динамического тестирования обнаруживаются ошибки, которые были
допущены во время процессов определения требования технического задания (ТЗ),
эскизного проектирования (ЭП), рабочего проектирования (РП) и кодирования. Еще
одним, иногда упускаемым из виду, источником скрытых ошибок является повторно
используемое программное обеспечение. К возможными типам ошибок относятся: I
логические ошибки, простые опечатки, ошибки организации данных, ошибки, '
влияющие на эффективность, ошибки применимости, ошибки запросов баз данных, I
ошибки доступа к файлам, дефекты интерфейсов, ошибки управления загрузкой, от-
сутствующие функции, ошибочные алгоритмы, проблемы обмена данными, дефекты I
сценариев тестирования, неверное вычисление результатов тестов и множество дру-
гих. Короче говоря, последовательное накопление ошибок, которые все еще остают­
ся скрытыми на момент начала динамического тестирования, происходит на всех
предыдущих этапах проектирования. За счет применения методики быстрого тести­
рования, которая позволяет максимально быстро выявить и исправить большинство
скрытых ошибок, можно сэкономить время и существенно снизить трудозатраты.
На этапах ТЗ и ЭП жизненного цикла разработки функциональные требования
объединяются с нефункциональными. Примерами нефункциональных требований
могут служить календарный план поставки продукта, состав установочного комплек­
та, требования по заполнению базы данных, временные характеристики алгоритма,
человеческий фактор, требования к поддерживаемым конфигурациям, коммуника­
ционная инфраструктура, требования к обеспечению безопасности, надежность и
т.п. Большинство из этих требований разрабатывается на основе стандартов про­
граммирования или руководств по стилю, действующих в конкретной организации.
Как правило, стандарты программирования создаются на базе опыта работы органи­
зации. Извлеченные в процессе деятельности уроки, наряду с результатами марке­
тинговых исследований программной продукции конкурирующих организаций,
оформляются в виде стандартов программирования, иногда называемых руково­
дствами по стилю. Если ваша организация готова инвестировать определенные сред­
ства в тестирование, имеет смысл вкладывать их в автоматизацию тестирования
стандартов программирования или руководств по стилю. После такого инвестирова­
ния персонал, занимающийся быстрым тестированием, может повысить скорость
работы за счет многократного использования существующих планов тестирования,
тестовых случаев, сценариев и средств тестирования, которые разработаны для про­
верки выполнения нефункциональных требований. Однако специалистам по тести­
рованию все еще придется разрабатывать тестовые случаи, сценарии тестирования,
 Глава 10. Технологии динамического тестирования и советы 213

методы обработки результатов тестов и средства тестирования при подготовке к ис­

пытаниям новых функций продукта, т.е. выполнения функциональных требований.
В этой главе исследуется множество технологий динамического тестирования.
Тем не менее, представленный в ней набор технологий не является исчерпывающим.
Цель применения этих технологий заключается в планомерном и эффективном
уменьшении количества скрытых ошибок в программном продукте. Во время плани­
рования своей работы члены команды тестирования должны самостоятельно опре­
делять подходящий количественный и качественный состав применяемых техноло­
гий. Результатами выполнения задач по разработке тестов, которые имеют исключи­
тельно большое значение для достижения цели планомерного выявления скрытых
ошибок, являются планы тестирования, тестовые случаи, сценарии тестирования и
методы обработки результатов тестирования.

Функциональное тестирование и анализ

Функции, на которые иногда ссылаются как на функциональные возможности, — это
именно то, разработку чего оплачивают пользователи. Часто в литературе, посвя­
щенной торговле и маркетингу, эти функции представляют в виде маркированных
перечней, которые сравниваются с аналогичными перечнями конкурирующих про­
дуктов. Эти перечни функций продукта определяются на этапе разработки требова­
ний и тщательно отслеживаются в ходе выполнения этапов проектирования и коди­
рования, например, в матрице прослеживаемости требований (Requirements Trace-
ability Matrix, RTM). Эти функции являются побочным результатом так называемого
пошагового уточнения, и они представляют собой фрагменты исходного кода, обра­
зующие модули или объекты.
Функциональный анализ представляет собой действия по описанию характери­
стик функции, влияющих на процесс ее проектирования и тестирования. Предполо­
жим, что имеется разложение в ряд Тейлора для функции y(x)=sin(x) (см. раздел
"Символьное выполнение" в главе 9). На этапах проектирования следовало бы вы­
полнить функциональный анализ для определения точности вычисления разложения
как в плане указания размера слова, требуемого для хранения используемых пере­
менных с плавающей точкой, так и в плане любых промежуточных результатов. На­
пример, для некоторых функций можно показать, что точность частичного разложе­
ния для переменной у(х) будет повышаться с увеличением количества членов ряда
Тейлора. Важно отметить, что если на этапах проектирования функциональный ана­
лиз не выполнялся, его придется выполнить во время подготовки к динамическому
тестированию. Организации, откладывающие оценку точности алгоритма до момен­
та начала динамического тестирования, не могут быть отнесены к тем, которые ис­
поведуют стратегию быстрого тестирования. В организациях, взявших на вооруже­
ние методику быстрого тестирования, во время разработки тестовых случаев, подго­
товки тестовых данных, сценариев тестирования и технологий обработки результа­
тов тестов специалисты, ответственные за подготовку к динамическому тестирова­
нию, просто ссылаются на документацию по функциональному анализу.
214 Част ь II . Технологии быстрого тестировани я и советы

ПРИМЕР: НЕОБНАРУЖЕННОЕ ПЕРЕПОЛНЕНИЕ

ПРИ ВЫПОЛНЕ НИ И ОПЕРАЦИ Й С П Л А В А Ю Щ Е Й ТОЧКО Й (ГЭРИ КОББ )
Автор вспоминает ситуацию, когда ем у довелось столкнуться с реализацией метода ко­
нечных разностей для решения системы дифференциальных уравнений в частных произ-
водных, причем пришлось вплотную заняться функциональным анализом влияния округ ­
ления и усечения на промеж уточн ы е результаты. В ходе этого исследования выяснилось,
что исходный ко д вычисляет интеграл по сетке значений переменной с именем mass
(масса). По мер е добавления отдельных масс, промежуточны й результат становился на-|
столько большим, что при достижении приблизительно середины сетки добавление ос­
тальных масс переставало влиять на значение с у м м ы , которо е представлялось значени­
ем с плавающей точкой . Это было связано с быстрым увеличением показателя степени
промежуточно й с ум м ы , что приводило к тому , что инструкция выравнивания показателя
степени (используемая при работе со значениями с плавающей точкой) компьютера
пренебрегала массами, показатели степени которых были малы по сравнению с показа­
телем степени промежуточно й суммы . К упомянутому функциональному анализу при­
шлось прибегнуть, когда тестирование позволило сделать вывод, что программ а будет
выдавать различные результаты при выполнении ее с использованием инструкций работы
со значениями с плавающей точкой одинарной и двойной точности либо при запуске на
компьютерах, в среде которых длины слов отличаются.

Разделение по классам эквивалентности

Принадлежность двух элементов данных к одному и тому же классу эквивалентности
просто означает, что с каждым из них функция выполняет одни и те же операции.
Принадлежность двух элементов данных к различным классам эквивалентности оз­
начает, что существует, по меньшей мере, одна строка кода, требуемая для обработки
одного элемента данных, которая не будет использоваться при обработке другого
элемента данных. Часто данные, принадлежащие к одному из двух классов эквива­
лентности, называют правильными данными, а данные второго класса эквивалентно­
сти — неправильными данными для данной функции. Ветви кода, которые используются
для обработки правильных данных, называются удачными ветвями, в то время как вет­
ви, выполняемые функцией при обработке неправильных данных, называются не­
удачными ветвями. В проектной документации для большинства функций определены
правильные и неправильные входные данные. Для определения классов эквивалентно­
сти данных для каждой функции тестировщики должны прочесть проектную доку­
ментацию. Если эта информация отсутствует в проектной документации, тестиров-
щику придется применить функциональный анализ и восстановить информацию о
классах эквивалентности снизу-вверх. В некоторых случаях в проектной документа­
ции может использоваться также термин допустимых и недопустимых данных для дан­
ной функции. Операции тестирования во время ввода неправильных данных доста­
точно точно называются отрицательным тестированием. Неправильные данные вы­
бираются с тем, чтобы убедиться в наличии в каждой функции обработчиков исклю­
чений, выполняющих обработку неправильных данных. Отрицательное тестирова­
ние не ограничивается одним лишь выполнением операций тестирования для случая
неправильных данных (обратитесь к разделу, посвященному отрицательному тести­
рованию, далее в этой главе).
Одна из принципиальных отличительных черт специалиста по тестированию,
применяющего технологии быстрого тестирования, состоит в том, что при оценке
вероятности наличия скрытых ошибок, которые могут препятствовать эффективно-
 Глава 10. Технологии динамического тестирования и советы 215

му использованию конечной программы, он всегда учитывает широту и степень по­

крытия тестирования. Чтобы гарантировать тестирование как удачных, так и не­
удачных ветвей внутри каждой функции, тестировщик должен уделять пристальное
внимание классам эквивалентности входных данных функций.

Анализ граничных значений

Весьма перспективной областью для поиска ошибок являются границы классов экви­
валентности функции. Как правило, анализ, который ведет к определению классов
эквивалентности, определяет и эти границы. Включение нескольких пограничных
значений в тестовые случаи для данной функции поможет проверить удовлетворение
ожиданий (требований) пользователя. Кратко рассмотрим причины ошибок разра­
ботчиков при кодировании граничных значений. Причины появления в программ­
ных продуктах ошибок, связанных с граничными значениями, достаточно легко по­
нять, анализируя количество преобразований, которые выполняются с момента раз­
работки требований до момента начала динамического тестирования. Прежде всего,
все требования создаются на высоком уровне. Они содержат не слишком много под­
робностей. Как правило, на этапе рабочего проектирования (РП) проектировщики
программного обеспечения добавляют в RTM так называемые производные требова­
ния, преобразуя исходные требования в подробные и точные с точки зрения вы­
числений.
В организациях, занимающихся быстрым тестированием, уже осознали важность
этапа РП для команды тестирования. Если производные требования отсутствуют или
разработаны неправильно, то персоналу, занятому кодированием или тестировани­
ем, в ходе планирования, соответственно, придется дополнять высокоуровневый
проект архитектуры и исходные требования этими документально оформленными
подробностями рабочего проекта, в том числе и определяющими поведение про­
граммы на границах классов эквивалентности. В качестве примера рассмотрим кон­
струкции IF. По прошествии ряда лет многие исследователи в области компьютерных
наук отметили, что утверждения в конструкции IF — это те программные элементы, в
которых ошибки встречаются наиболее часто. Решение об использовании условия
"меньше чем" или "меньше или равно" в утвердительной части конструкции IF часто
принимается на этапе РП. В противном случае отсутствие этих спецификаций долж­
но быть выявлено во время инспекций, выполняемых на этапе РП.

Отрицательное тестирование
Отрицательное тестирование означает всего лишь подход, при котором тестиров­
щик, рассматривая программный продукт в качестве "черного ящика", определяет
способы, как заставить продукт выдавать неверные ответы или вообще прервать вы­
полнение. Выяснив у проектировщиков, какие требования должны быть выполнены
перед запуском программы, хороший специалист по тестированию может опреде­
лить набор тестовых случаев для выяснения реакции программного продукта на не­
соблюдение одного из этих предварительных условий. Рассматривая программу под
этим непривычным углом зрения, тестировщик предпринимает попытки ее вы­
полнения:
216 Часть II. Технологии быстрого тестирования и советы

• на платформах, на которых ее выполнение не планировалось;

• при отсутствии коммуникационных линий или при вводе неправильных вход­
ных данных;
• при отсутствии файлов данных, при отсутствии записей в базах данных или
при произвольно переставленных данных в файлах данных;
• при неверно введенных именах ссылок или при неопределенных, неправиль­
ных или отсутствующих конфигурационных параметрах;
• при выключенных периферийных устройствах типа принтеров, сканеров,
внешних дисководов компакт-дисков или CD-RW, внешних жестких дисков,
внешних динамиков и т.п.
Как уже упоминалось в разделе "Разделение по классам эквивалентности", к отри­
цательному тестированию относится также и ввод неправильных данных. Эти непра­
вильные данные могут поступать в форме недопустимых данных, введенных пользова­
телем, случайно заполненных данными коммуникационных буферов, недопустимых
значений в индексных файлах, переполненных журнальных файлов, в которых указа­
тель находится в конце файла, и т.д.
Устойчивость программы — это ее способность выдержать без сбоя отрицатель­
ное тестирование. Естественно, существует определенный предел устойчивости, тем
не менее, разработчики программного обеспечения должны критично относится к
коду и тестировать его как с правильными, так и с неправильными данными. Они
должны предусмотреть самопроверку на предмет присутствия минимально допусти­
мой системной конфигурации и ее готовности выполнить приложение. Это самотес­
тирование должно предприниматься в начале выполнения программы, поскольку с
момента установки продукта конфигурация могла измениться. Недостаточно выпол­
нять самотестирование конфигурации только во время установки приложения.
Персонал, занимающийся тестированием, располагает широким спектром конфи­
гураций оборудования, на котором может выполнять тестирование системы. С пер­
соналом разработки, который использует типовые компьютеры, дела обстоят иначе.
Важно, чтобы все члены команды тестирования осознали свою ответственность за
проверку того, что продукт работает и дает одинаковые результаты во всех конфигу­
рациях, которые указаны в документе требований. Помимо обязательных конфигу­
раций, персонал, ответственный за тестирование, должен выполнить проверку обя­
зательных конфигураций, поддержка которых была отключена или которые были
как-то расширены. Если во время тестирования эти конфигурации приводят к гене­
рации исключений, то, как минимум, документация по продукту должна содержать
предупреждение о недопустимых конфигурациях.
Стратегия отрицательного тестирования никогда не должна напоминать стрельбу
наудачу. Напротив, планы тестирования должны быть тщательно продуманными,
непротиворечивыми, завершенными и эффективно обеспечивать обнаружение оши­
бок. Штат, занятый разработкой методов тестирования, должен быть полностью
укомплектован для разработки тестовых случаев, обеспечивающих соблюдение стра­
тегии тестирования, которая задокументирована в плане тестирования. При соблю­
дении этих условий тестирование системы будет эффективно в плане обнаружения и
устранения в продукте множества ошибок.
 Глава 10. Технологии динамического тестирования и советы 217

Тестирование на основе определения

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

Для каждой подсистемы конечного программного продукта организуется группа

контроля за внесением изменений, занимающаяся сопровождением, отслеживанием
состояния и утверждением версий, в которых устранены отдельные поднаборы за­
фиксированных ошибок. В организациях часто ведется база данных ошибок, которая
существует под эгидой группы контроля за внесением изменений, но используется
совместно (с предоставлением доступа только по чтению) командами разработки и
тестирования. Персонал этих команд исправляет и повторно тестирует ошибки, за­
планированные для устранения в будущих версиях конечного продукта. Эта инфра­
структура поддерживает подход к быстрому тестированию на основе определения
степени риска, который может обеспечить поэтапную передачу конечного продукта
заказчику. Инфраструктура подходит также для двух партнеров по разработке про­
граммного обеспечения, географически расположенных в различных точках земного
шара.
Стандарт IEEE Standard 1044 института инженеров по электротехнике и электро­
нике (Institute of Electrical and Electronics Engineers — IEEE) [24] устанавливает до­
полнительные определения, действия и процессы во время отслеживания ошибок.
Этот стандарт возлагает на тестировщиков ответственность за классификацию
ошибки во время ее обнаружения (распознавание). Ошибка, о которой сообщается в
документации по тестированию, анализируется на предмет оказываемого ею влия­
ния, и для нее предлагается значение меры степени риска (влияние распознавания).
218 Часть II. Технологии быстрого тестирования и советы

Команда разработки или сопровождения предпринимает шаги (исследование), чтобы

удостовериться в повторяемости ошибки, и пытается определить ее основную при­
чину. Затем делаются уточнения предложенного значения меры степени риска и пла­
на, в том числе выделенных ресурсов, первой версии, в которой данная ошибка будет
устранена, и оцениваются затраты (влияние исследования). В ходе выполнения этого
плана предпринимаются действия по корректировке, и команда тестирования снова
обращается к тестовому случаю, во время прогона которого ошибка была обнаружена
впервые. Кроме того, команда выполняет набор регрессивных тестов, чтобы удосто­
вериться в том, что исправление ошибки не привело к появлению других ошибок. На
основе результатов повторного тестирования заключительные выводы документи­
руются в примечании по реализации той версии, которая вначале содержала ошибку.
Краткое описание этого процесса приведено в таблице 10.2
Диаграмма информационных потоков, приведенная на рис. 10.1, помогает упоря­
дочить подпроцессы на каждом из этапов и увязать их со всем процессом. Типовые
группы контроля за конфигурацией и технологическим циклом, которые в настоящее
время используются во многих организациях, могут обеспечить удобное сопровож­
дение этого процесса отслеживания ошибок. Для того чтобы закрыть проблему, свя­
занную с ошибкой, потребуется согласовать и программу, и ее документацию, в том
числе требования, эскизную и рабочую документацию по проекту, а также руково­
дство пользователя.
Глава 10. Технологии динамического тестировани я и совет ы 219
220 Част ь II . Технологии быстрого тестирования и совет ы

Определение полноты охвата ветвей

при тестировании
В области проектировании программного обеспечения существует несколько опре­
делений тестирования ветвей. Наиболее традиционное определение гласит, что
ветвь — это последовательность выполнения операторов исходного кода, начинаю­
щаяся с точки входа или условного разветвления и заканчивающаяся следующим ус­
ловным разветвлением или точкой выхода. Такие ветви были названы DD-ветвями
(от decision-to-decision path — ветвь типа "решение-решение"). Теоретики подхода
быстрого тестирования признают бесперспективность попыток обеспечить при
тестировании полный охват всех DD-ветвей и рекомендуют вместо этого
использовать программное средство автоматизации документирования всех DD-
ветвей в исходном коде. Кроме того, на этапе тестирования блоков или
комплексных испытаний необходимо определить приоритеты тестирования,
чтобы испытания обязательно охватывали поднабор DD-ветвей, в которых
вероятность наличия ошибки наиболее высока.
Листинг программы, приведенный на рис. 10.2, был создан в период 1979-1981г.г.,
когда авторы разрабатывали систему тестирования программного обеспечения (Soft­
ware Testing System, STS). Эта система предназначалась для внутреннего использова­
ния в корпорации Texas Instruments, Inc., основанной организацией Advanced Soft­
ware Technology (AST). STS была программным инструментом, который позволял
программистам на языке Fortran выполнять перечисление ветвей исходного кода.
Для тестировщика STS служила удобным средством определения нужных значений
переменных программы для перемещения программного счетчика по конкретной
DD-ветви. STS могла устанавливать зонды в каждой DD-ветви. Во время выполнения
эти зонды регистрировали номера DD-ветвей по мере их выполнения. После не­
скольких запусков программы анализ журнальных файлов позволял выяснить, какие
DD-ветви не выполнялись. В случае аварийного прерывания выполнения программы
журнальный файл, содержащий трассировку ветвей, объединялся с файлом с прону­
мерованными строками исходного кода, что позволяло генерировать отчеты, содер­
жащие строки исходного кода в порядке, обратном выполнению. Этот файл был
очень полезен во время отладки, поскольку его можно было загрузить в текстовый
редактор и выполнять поиск имен переменных, которые были связаны с прерывани­
ем программы.
Глава 10. Технологии динамического тестировани я и совет ы 221
222 Часть II. Технологии быстрого тестирования и советы
Глава 10. Технологии динамического тестировани я и совет ы 223
22 4 Част ь II. Технологи и быст рог о тестировани я и совет ы

Дл я тог о чтоб ы можн о был о пр о ч е ст ь листин г ветвей , потребуетс я ввест и сле­

дующие опреде лен и я :
• <номе р строки > — номер , помещаемы й п ро гр а мм о й в каждую строку кода
• J U M P <номе р строки > озна ч ае т какую-либо форм у конструкци и G O TO,
ENDD O ил и I F
• T H R U <ном е р строки > включае т все с т ро к и вплот ь д о строк и <номе р строки >
• <номе р строки > А означ ае т част ь T H E N конструкци и I F
• <номе р строки > В означ ае т част ь ELSE конструкци и IF
• ЕО Р указывае т к он е ц ветв и
Кром е того , п р и чт ен и и этог о ли сти н г а необходим о обрати т ь вниман и е н а пару
вычис лен н ы х и о т о б р а ж е н н ы х зн ач ен и й п о к азат е л я цикломатическо й сложности.
Числ о слев а о п р е д е л е н о Томасо м Дж . Маккейбо м (T hom a s J . McCabe ) в [31] . Значе­
ни е справ а — эт о показат ел ь цикломатическо й слож ност и , о п р е д е л е н н ы й Гленфор-
до м Дж . М айерсо м (Glenfor d J . Myers) [37] в от ве т н а первоначальн у ю публикацию
Маккейб а . Вспомнит е , чт о показател ь цикломатическ о й сложн ост и — эт о минималь­
но е ко ли ч е ст в о отдельны х запусков модуля, к от ор о е потребуетс я для хот я б ы одно­
к рат н ог о в ы п олн ени я каждой строк и кода. Дан на я и н ф ор м а ц и я може т оказатьс я по­
лезно й п р и прог н ози ров а н и и затра т н а т е с т и р о в а н и е . Можн о попытать с я найт и все
ветв и в одно м из таки х модулей и прочувствоват ь ценност ь описываем о г о программ­
ног о средств а с то ч к и зрени я обеспе чивае м о й и м эконом и и времени .
Большинст в о те о р е т и к о в программирован и я сходятс я в о м не ни и , ч т о свыш е по­
л овин ы ошибо к в ново м коде являют с я результато м ошибо к в логик е построен и я ко­
да. Т е с ти ров ан и е ветве й выявляе т логическу ю структуру кода и позволяе т тестиров-
щику со с р е до т о чит ь внимани е на ее правильност и . Однак о арсена л специалис т а по
т е с т и р о в а н и ю н е долже н ограничи вать с я то л ь к о одни м эти м средством , поскольку
строк и кода в част и T H E N конструкци и I F все ж е могут содержат ь ошибки , которые
приводя т к получени ю неправильны х результато в ил и аварийном у пр ер ы ва н и ю про­
граммы .
Кр о м е того , следует учитывать, чт о многи е ветв и в программ е являют с я тупико­
выми. Эт о пон и ма ю т очен ь немног и е тестиров щик и . Как правило , разработчики ,
создающи е отладочн ы й код, управляю т ег о выполне ни е м пр и помощ и переменной ,
зна че н и е к от ор о й п о умолчани ю устанавливаетс я таким , чт о отключае т отладку. С
момент а поставк и кода и в течени е всего времен и ег о использовани я клиенто м это
зна че н и е по умолчани ю остаетс я в состоян и и откл юченн о й отладки . В следующем
раздел е приведен а схема снижен и я трудоемкост и вы полнени я полног о тестировани я
DD-ветвей, основанна я н а использовани и п ри о рит ет о в .

Тестирование случаев использования

В наш е врем я в объектно-ориентированно м программирован и и част о используется
технолог и я п ро е кти р ов а н ия , называема я п ро е кти р ов ан и е м случаев использования
(см. ри с . 10.3). В случаях использовани я отр а жа етс я взаимодействи е отдельны х эле­
менто в друг с другом на основ е конкретног о сцен а ри я . Популярны е сце на ри и случаев
использован и я находя т свое отражен и е в большинств е проектов . Строг о е отображе­
ни е с ц ен а ри е в н а случаи использовани я позволяе т сделат ь вывод о существовании
 Глава 10. Технологи и динамическо г о тестировани я и сов ет ы 225

набора популярны х случаев использовани я в рамка х различны х п р ое кт о в . В [35] бы­

л а отмечен а така я взаимосвяз ь и п редп рин ят а п оп ыт к а связат ь да нны е частот ы
использовани я с диаграммам и случаев использовани я . Д а н н ы е частот ы исполь­
зования могут быт ь вы р а же н ы в процент а х о т общег о коли чест в а случаев
использования . Име я такую и н ф о рм а ц и ю о п рое кт е продукта, специалист ы п о
быстрому т е ст и р о в а н и ю могут выделят ь боле е 50 % времени , в т е ч е н и е к о т о р о г о
создаются тес товы е случаи, н а мене е че м 5 0 % кода, характеризующегос я самым
частым при мене нием , т.е. н а популярны е случаи использовани я .

Другой аналогичн ы й подход заключаетс я в зондиров ан и и DD-ветвей, как описы­

валось в предыдущем разделе . Пос л е тог о как зонд ы вставлен ы в код, необходим о
выполнит ь большо й объе м тестовы х случаев и отсортироват ь полученны е журналь­
ные ф а й л ы выполн ени я ветве й п о номера м зондов . Количеств о тест о в должн о опре­
деляться исходя из требовани й , и н ф о р м а ц и о н н ы х потоко в и возможног о опыт а ис­
пользовани я в технологическ о м цикл е существующих систем . DD-ветви, номер а зон­
дов которы х встречаютс я наиболе е часто , образую т эм п и р и че с к и й прогно з часто т
основного использования . Оп и с а н н ы й процес с относит с я к технолог и и бы стр ог о
тестирования , поскольку его назн а че н и е состои т в экономи и времен и и по вы ш ен и и
эф ф ект ив но с т и обнаружени я ошибок . Ч т о може т быт ь хуже, чем когда нескольк о
специалисто в п о тестировани ю тратя т массу врем ен и н а разработк у тес тов ы х случаев
для нескольки х ветве й новог о ф р а г м е н т а кода, лиш ь тольк о дл я того , чтоб ы выяс-
226 Часть II. Технологии быстрого тестирования и советы

нить, что код является невыполнимым и поэтому не может быть протестирован. Или,
скажем, в принципе новый код является выполняемым, но выполняется только при
удовлетворении какого-то маловразумительного условия. Какое бессмысленное рас­
ходование времени и ресурсов с нулевой эффективностью, поскольку ни одна ошибка
не обнаруживается!
Проектирование случаев использования и прогнозирование частоты использова­
ния каждого из них позволяет определить приоритеты тестовых случаев. Чтобы
можно было оптимизировать ресурсы и эффективность тестирования, эти приори­
теты должны быть положены в основу разработки тестовых случаев и порядка их
прогона.
Прежде чем применить к тестированию подход, основанный на случаях использо­
вания, тестировщики и разработчики должны обеспечить гарантированное соответ­
ствие случаев использования списку требований и коду. Несоответствие документа­
ции по требованиям и кода — это недостаток, который часто отмечается во время
аудита многих проектов по созданию программного обеспечения. В некоторых орга­
низациях документации по программе уделяется не такое пристальное внимание, как
документации для пользователя. Иногда случаи использования, разработанные на
основе исходных требований, передаются группе тестирования без проверки на со­
ответствие текущим требованиям. Однако за это время исходные требования могли
претерпеть изменения. В таких ситуациях тестировщики, используя информацию о
случаях использования, могут получить ложное обнаружение ошибок. В ходе даль­
нейших исследований выяснится, что код удовлетворяет списку требований, но не
случаям использования. Вероятность наличия ошибок в тестовом случае и результа­
тах будет высокой, а усилия, потраченные на разработку тестового случая, окажутся
напрасными.

Псевдоотладка/видоизменение
Псевдоотладка (bebugging), являющаяся одной из форм видоизменения программы, -
это способ определения эффективности стратегий тестирования, применяемых в
проекте. Прежде чем приступать к псевдоотладке, необходимо заручиться поддерж­
кой и тестировщиков, и разработчиков. Как бы вы ответили на вопрос, часто зада­
ваемый руководителем разработки: "Когда можно ожидать выявления большинства
ошибок в этой версии?". Обычно руководитель тестирования задает встречный во­
прос: "А сколько мелких ошибок нам нужно найти?" Основным показателем прогрес­
са тестирования должно быть процентное отношение числа найденных ошибок к
числу скрытых ошибок, которые нужно найти. Проблема, связанная с вычислением
упомянутого показателя, состоит в том, что и числитель, и знаменатель этого отно­
шения неизвестны.
Псевдоотладка заключается в преднамеренном внесении ошибок в программу. Да­
лее полученная версия тестируется, и после этого определяется эффективность тес­
тирования путем сравнения обнаруженных и искусственно созданных ошибок. От­
ношение числа обнаруженных искусственно созданных ошибок к числу созданных
ошибок должно быть равно отношению числа найденных ошибок к числу скрытых
ошибок в продукте. Этот метод позволяет оценить показатель прогресса тестирова­
ния, определенный чуть выше.
 Глава 10. Технологи и динамическо г о тестировани я и совет ы 227

Организа ци и , в к оторы х применяет с я быстро е т е ст и р о в а н и е , находят , чт о псев­

доотладка може т ускорит ь провед ен и е т е с т и р о в а н и я благодар я оп р ед е л ен и ю услови й
его п рек ращени я . Фактически , процес с преднамеренно г о внесени я ошибо к требуе т
творческог о подхода. Если искусственно созданн ы е ошибк и распределяютс я п о ти­
пам в соот ветст ви и с историчес к и сложившей с я модель ю ошибо к аналогичны х раз­
работок, с использование м тог о ж е язык а прог ра мми ровани я , и есл и обнар уже нн ы е
ошибки таки м ж е о б раз о м распр едел ен ы п о типам , т о анали з прогресс а т е с т и р о в а н и я
можно выполнит ь п о типам . В это м случае можн о н е то л ь к о с о всей о п р е д е л е н н о с т ь ю
ответит ь н а вопрос : "Когда можн о ожидат ь выявлен и я большинст в а ошибо к в это й
версии?", но и сказат ь : "М ы нашл и большинст в о логичес ки х ошибо к в програм м е , а
теперь за н ят ы р а з р а б о т к о й дополнительн ы х тестовы х случаев для проверк и надеж­
ности модулей об р аб от к и ошибок" . Аналогичн о , все искусственн о созданны е ош ибк и
могут быт ь ра сп р ед е ле н ы по уровня м с ер ь езн о ст и . И тогда, есл и обнару же нн ы е
ошибки такж е р асп ред ели т ь п о уровня м с е рь езн о ст и , можн о н е тольк о от вети т ь н а
заданный вопрос , но и сказать : "М ы нашл и большин ст в о ошибо к с уровням и серьез ­
ности 1 и 3, а сейча с разрабатывае м д оп о лн ите л ьн ы е тестовы е случаи дл я обнаруже­
ния ошибо к с уровн ям и сер ьезнос т и 2 и 4".
Аналогичн ы е подход ы к видоизменени ю п р ог ра м м ы могут использовать с я в от­
ношении ошибок , к оторы е не связан ы с исходны м кодом , в то м числ е неправильн ы х
данных в баз е данны х , некачественны х коммуникационн ы х л и н ий , п о в ре ж де нн ы х
данных, неправильн ы х данных , вводимы х пользоват елем , ненадежны х и н т е рф е й с о в
между процессам и и т.п. Видоизменени е програм м ы представляе т собо й э ффе к ти в ­
ное средство , к от ор о е може т использовать с я раз раб а тываю щ е й организацие й , кото­
рая повторн о используе т код и з другого проекта . Ч а ст ь ю процесс а п о вт о рн ог о ис­
пользования исходног о кода являет с я ег о со пр о в о жд е ни е . Псевдоотлад к а може т
применятьс я дл я прове рк и хода этог о сопровождени я , оп р ед е л я я к он ечн ы е ц е л и тес­
тирования, которы е будут использоваться пр и разраб от к е новы х тестовых случаев.

Трассировка/трассировка снизу вверх/

мгновенные дампы/постпечать
Специалисты п о тестиро ван и ю могут воспользоватьс я рядо м инструментальны х
средств, кот о р ы е существуют и применяют с я в совре менн ы х разработка х . Четы рьм я
из этих средст в являютс я трассировка , трассировк а снизу вверх, мгновенн ы е дамп ы и
постпечать. О п ы т н ы е программисты , помнящи е времен а больших компьютеров , мо­
гут решить , чт о это т разде л посвяще н выводу на печат ь ил и чтени ю системно й диаг­
ностической и н ф о р м а ц и и , в то м числ е шестнадцатеричны х системны х дампо в и со­
общений редактор а связей , для определен и я прир о ды , места и исходног о уровн я
причины системно й ошибки . Н а самом дел е эт о н е так . Несмот р я н а сходны е терми ­
ны, мы определяе м технологии , исходя из сов рем е нн ы х сп е ци ф и к а ц и й и средств .
Например , в программу, основанную на п р и м ен е н и и транзакци й , пр о ект и ро в щи к и
часто включаю т функци ю трассировк и тр анз ак ци й , котора я може т избиратель н о
включаться любы м пользователем , выбирающи м эту опц и ю в свое й конфигурации .
Эта опци я создае т фа й л трассировк и с отображени е м входны х и выходны х данны х
транзакци и и форм а ти рова н н ы е мгновенны е дамп ы данны х запроса . Естестве нн о ,
испытатель долже н тестирова т ь систему бе з включени я эт о й опц ии , поскольку дл я
228 Част ь II. Технологи и бы ст рог о тестировани я и совет ы

пользовате л я п о умолчан и ю выбирает с я им ен н о это т режи м . Н о есл и кажется , что в

п р и л ож е н и и вып ол не н и я т ра н з а к ц и й что-либо н е в порядке , те с т и р о в щ и к должен
п р о в е р и т ь наличи е оп ц и и тр а с с и р о в к и транзакц и й , включи т ь е е и сохранит ь жур­
нальн ы й файл , чтоб ы ошибк у можн о был о повторит ь . Результат ы т р ас си р о в к и долж­
ны быт ь приобщен ы к отчет у об ошибке , чт о упрост и т воспроизведен и е условий ее
возникновени я .
П р и обнаружен и и ошиб к и недостаточн о черкнут ь в блокн от е : " Н е удалось загру­
зи т ь фа й л" , ил и включит ь подобную заметку в сообщени е э л е к т р он н о й почт ы , на­
правленн о е автору кода. Большинст в о т е о р е ти к о в т е ст и р о в а н и я п р из ы в а ю т разде­
л я т ь задач и те с т и р о в а н и я и раз ра б от ки , чтоб ы те ст и р ов щ и к бы л независимым и отве­
чал тольк о з а обнару жен и е ошибок . Осн овн о й принци п быстрог о тест и ро в ан и я за­
ключает с я в объединен и и эти х р о л е й в т о й мере , пок а эт о способствуе т ускорению
процессо в обнаруж ени я и устранен и я ошибок . Тестировщи к и могут поместит ь эк­
р а н н ы е снимки , н ап ри ме р , в докумен т Microsoft Word , и снабдит ь их рабочи м и по­
меткам и ил и указателям и н а с ц е н а р и и тест ир о в ан и я (см. рис . 10.4).
Отче т о б ошибк е
Вре мя /д ат а : 9:40 пополудн и 6 / 1 3 / 2 0 0 1
Дат а отчета : 9:50 пополудни 6 / 1 3 / 2 0 0 1 п о эле кт ронн о й по чт е в
support@groove.c om
Суть отказа :
В окн е Groov e M a i nt e na n c e U p d a t e (Обновлени е п р ог ра м м ы Groove ) я выбрал
ссылку " U p d a t e Gr o o v e " ("Обновит ь Groove" ) и получил сообщен и е об ошибке , в ко­
т о р о м говорилось , ч т о н е удалось найт и URL-адрес. Эт о сообщени е повторялось
трижд ы , после чего , пр и че тве рт о й попытке , я сделал следующую копи ю экрана .
В п рим ере , п рив еде нн о м н а рис . 10.4, представлен а неповторяющая с я ошибка.
Ч е р е з нескольк о дне й посл е отправ к и отчет а п о это й ошибк е т е с т и р о в щ и к повторил
это т тест . URL-адрес бы л найден , и загрузка выполнилас ь успешн о . П р и это м исполь­
зовалос ь т о ж е клиентско е программн о е обеспечение . Свидетельствуе т л и эт о о том,
чт о никако й ошиб к и н е было? Не т , в момен т получени я э к р а н н ог о снимк а ошибка
имел а место. Отсутстви е ошибк и в клиентско й программ е означае т лиш ь то , что
ошибк а был а исправлен а на с ерв ер е , посл е чего все стал о ра бота т ь правильно . В сис­
тема х с архитектур о й к л и е н т / с е р в е р ошибк и распределяютс я по двум программным
базам, и обслуживани е таки х систе м отличаетс я от обслуживани я автономны х про­
грамм. Эт и различи я будут тем о й одног о и з последующих разделов .

Создание точек прерывания/правки

Точка прерывания (breakpoint) опре дел яет с я как спосо б останов а пр ог ра м мн ог о счетчи­
ка в какой-либо точк е исходног о кода. Отладчики , в случае их пр и м е н е ни я к про­
грамма м на язык е ассемблера , позволяю т устанавливать то ч к и п р е р ы в а н и й дл я полу­
чени я и н ф о р м а ц и и о сост о ян и и памят и и регистров . Эт о дае т возможност ь изменить
данны е в памят и ил и собр ат ь и н ф о р м а ц и ю о распределени и памяти , котора я помо­
ж е т отыскат ь спосо б исправлен и я ошибки .
 Совместная
разработка требований
к приложению (JAR):
метод выработки
требований с
применением быстрого
тестирования
Темы, рассматриваемые в главе:
• М е т о д о л о г и я JAR
• Р о л ь с п е ц и а л и с т о в п о т е с т и р о в а н и ю в п р о ц е с с е JAR
• Резюме

Одно из основн ы х услов и й успешно й разработ к и программног о обеспечен и я — дос­

тижени е по н и м а н и я треб о ван и й клиентов . Ка к бы л о п о к аз ан о в главе 2 , четко е опре­
деление технически х требо вани й служит отправн о й т о чк о й э ф ф е к т и в н о г о процесс а
разработк и программног о обеспечени я .
Существуют разли чн ы е методы , п р из в ан н ы е улучшить обме н и н ф о р м а ц и е й между
клиентом и командо й разработчиков . Оди н класс методов , используемы х дл я выра­
ботки технически х требо вани й , называетс я техно логи е й ускоренн о й разработ к и
спе ци фи ка ц и и п р и л о ж е н и я (fast applicatio n specification techniques , FAST), котора я
кратко описывалас ь в главе 2. Совместна я разработк а тр ебо ван и й к прил о ж ен и ю
(Joint Application Re qui re ment s , JAR) — эт о технолог и я FAST, котора я предназначен а
для обеспечен и я по лн о й интеграци и статическог о т е сти р о ва н и я с процессо м выра­
ботки треб овани й . Ин т е г р а ц и я статическог о т е сти р о ва н и я в процес с JAR в вид е ег о
составной част и достигаетс я з а сче т выполнен и я действий , известны х под название м
совершенно й поддержки . Со вер шенн а я поддержк а — э т о о р г а ни з о в а н н ы й спосо б ин­
терактивног о анализ а и пересмотр а выработанн ы х т р еб о ва ни й . Действия , связанны е
с совершенно й подд е р жк о й , оп ис ан ы дале е в это й главе.
Результатом JAR-сеанса явл яет с я набо р тщательн о проан а лиз иров ан н ы х требова ­
ний, кот оры е согласован ы с пользователя м и конечног о продукт а ил и и х представи-
230 Часть II. Технологии быстрого тестирования и советы

сти диагностирования и исправления ошибок, особенно тех, которые задерживают

реализацию тестирования. Иногда тестировщик обнаруживает ошибку, которая пре­
пятствует выполнению дальнейшего тестирования в области данной ошибки. Такие
ошибки, как определено в главе 5, называются блокирующими. Если подобную ошиб­
ку не исправить в кратчайшие сроки, это приведет к остановке всего процесса тести­
рования. Более чем для 95% ошибок, о которых сообщается команде разработки для
их исправления, вполне приемлемо дождаться, пока группа контроля за внесением
изменений определит приоритет и запланирует ресурсы для устранения каждой
ошибки. Однако менее 5% блокирующих ошибок требуют немедленных действий,
целью которых будет определение быстрого способа обхода заблокированных вет­
вей. Разработчик может предоставить временный способ исправления дефектного
объекта с последующим частичным изменением связей, чтобы вернуть эту промежу­
точную/измененную версию персоналу тестирования. Это временное исправление
будет повторно реализовано и протестировано в будущей полной версии, но пока
группа тестирования может сохранить высокую эффективность обнаружения других
ошибок в остальной части программы, начиная с точки блокирующей ошибки.

Тестирование потока данных

Один из способов создания тестовых случаев для ошибок, связанных с потоками дан­
ных, которые проходят через невзаимодействующую с пользователем часть програм­
мы — это создание базовой копии файлов данных первоначального запуска програм­
мы. Затем выполняется сравнение результатов всех последующих запусков програм­
мы, при условии, что программа прогоняется с той же самой копией файлов данных.
Наконец, в исходный код программы вставляются зонды, которые вносят в журнал
уникальный номер зонда после выполнения каждого оператора ввода/вывода про­
граммы. Сравнивая номера зондов, записанные в журнал при каждом запуске про­
граммы, можно определить, остается ли поток данных через зонды неизменным для
каждого теста, который выполняется при использовании одной и той же базовой ко­
пии файлов данных первоначального запуска. Затем этот тестовый случай может
применяться для проверки неизменности потока данных и в новой версии.
Более распространенным способом тестирования потоков данных является под­
ход, который используется для тестирования приложений, ориентированных на
транзакции, например, систем ввода заказов, систем обработки заказов, технологи­
ческих систем, систем выписки счетов, поставки и возврата продукции. Данные, по­
лученные в результате каждой тестовой транзакции, могут отслеживаться в каждом
из этих процессов и подтверждаться промежуточными результатами тестирования,
выполняемого между процессами.
В случае тестирования изменений существующих систем планирование и выпол­
нение тестирования потоков данных не связано с особыми сложностями, поскольку
снимки системы можно сделать до и после того, как каждый процесс впервые исполь­
зуется существующей системой. Впоследствии, после внесения изменений в новую
версию и ввода в нее тех же самых данных, новые результаты можно сравнить (ино­
гда автоматически) с предыдущими результатами тестирования существующей сис­
темы.
 Глава 10. Технологии динамического тестирования и советы 231

Еще одним примером блокирующей ошибки, которая также влияет на поток дан­
ных, может послужить оператор:
IF (I > J) THEN B ( I ) = A(J ) ELSE В ( I ) = 0 ENDIF .
Если символ операции "больше чем" (>) указан по ошибке и вместо него должен
присутствовать символ операции "меньше или равно" (<=), обнулится неверная часть
массива В. Все вычисления, следующие за этим оператором IF будут иметь дело с эти­
ми обнуленными значениями В, в то время как они должны выполняться с ненулевы­
ми значениями, скопированными из массива А. Это означает, что все результаты тес­
та, зависящие от В, окажутся неверными. Поэтому тестировщик не сможет опреде­
лить, содержит ли ошибки остальная часть программы (та, что следует за показанным
оператором IF). Тестировщик мог бы проследить поток данных для всех значений I и
J или их некоторого поднабора. Имея информацию о потоке данных через несколько
процессов, специалист по тестированию может извлекать промежуточные результа­
ты, тем самым ускоряя процесс выявления и последующего воссоздания ошибок.

Тестирование на предмет утечек памяти

Утечка памяти — это тип ошибки, которая приводит к тому, что приложение посте­
пенно заполняет всю виртуальную память, управляемую операционной системой.
Множество современных языков организуют в виртуальной памяти стек и кучу, обес­
печивая более эффективное и удобное управление временной областью памяти.
Утечки памяти имеют несколько других названий, в числе которых паразитное рас­
пределение памяти, разрушение стека, разрушение памяти, квазипереполнение. Ос­
новная причина возникновения ошибки утечки памяти — невозможность освобожде­
ния виртуальной памяти, которая динамически запрашивается приложением. Не су­
ществует никаких внешних средств устранения утечки памяти, за исключением избе­
жания рабочей области приложения, вызывающей утечку памяти. Большинство со­
трудников служб технической поддержки просто рекомендуют прервать выполнение
приложения или перезагрузить операционную систему. На рис. 10.5 показан пример
сообщения группы технической поддержки компании Microsoft относительно утечки
памяти в поступившей в продажу версии операционной системы Windows 95.
Компания Microsoft поместила средства обхода и исправления этих ошибок утеч­
ки памяти на соответствующие Web-сайты.
Как правило, утечка памяти происходит в небольшой функции, которая правиль­
но написана для своей удачной ветви, но неправильно — для неудачной ветви. Если вы­
деление виртуальной памяти выполняется во время запуска функции, но ввод данных
пользователем приводит к прерыванию программы, обработчик ошибок для данного
прерывания может быть не запрограммирован для освобождения виртуальной памя­
ти. Независимо от того, велик или мал объем выделяемой памяти, повторяющийся
характер функции, в конечном счете, обусловит уменьшение объема доступной вир­
туальной памяти, и программа больше не сможет функционировать. Особенно уяз­
вимы в этом отношении приложения, которые выполняются круглосуточно в тече­
ние всех семи дней недели. Даже самые малые утечки памяти со временем приведут к
разрушению программы или системы.
232 Часть II. Технологии быстрого тестирования и советы

Утечки памяти особенно трудно выявить в объектно-ориентированных исходных

кодах. Тем не менее, при помощи трассировки и отслеживания гистограммы объектов
(Object Histogram), разработчик может выяснить, какой объект выделяет и освобождает
память и какие вызовы присутствуют между этими вызовами диспетчера памяти. Пе­
ред загрузкой и запуском сомнительной Java-программы саму среду следует запустить
с параметром -tracepopulation. Как только объект, вызывающий утечку памяти, локали­
зован, не забудьте воспользоваться технологией статического тестирования для ус­
корения выяснения основной причины. Еще важнее разобраться в коде и любых воз­
можных прерываниях в удачной ветви, которые могут помешать объекту освобождать
память. В C++ существует объект debug_malloc, который может оказаться очень полез­
ным для трассировки утечки памяти. Хотя утечки памяти не носят перемежающийся
характер, они быстрее проявляются в бездисковых системах с небольшим объемом
памяти, нежели в конфигурациях с большим объемом оперативной памяти и диско­
вого пространства, перезагрузка которых выполняется редко (например, в сервер­
ных приложениях).
Исходя из концепции быстрого тестирования, можно дать следующий совет. Как
только разработчик обнаружил и устранил утечку памяти, он должен проверить но­
вый код на предмет наличия в этой области других ошибок, могущих привести к
утечкам памяти. Достаточно часто, столкнувшись с первым проявлением ошибки,
разработчик считает ее единственной, упуская из виду другие ситуации, когда этот же
код может не освобождать динамически распределяемую память. Этот совет проти­
воречит также призывам большинства инструкторов по тестированию и менеджеров
конфигурации заниматься устранением только той проблемы, которая указана в от­
чете об ошибке. Если вы хотите следовать советам по быстрому тестированию, ино­
гда приходится отказываться от трафаретного подхода и просто заниматься повтор
ным проектированием и реализацией приложения.
 Глава 10. Технологи и динамическо г о тестировани я и сов ет ы 233

Тестирование интерфейса
"человек-компьютер"
Инт ерфе й с "человек-компьютер " ( h um a n - c o m put e r interface , HCI ) в современны х
компьютера х може т охватыват ь широк о е множест в о различны х п е ри фе ри й н ы х уст­
ройств, таки х как клавиатура, клавишна я панель , мышь, светово е пер о , монито р с
сенсорны м э к ра н о м , р еч ев о й и н т е рфе й с , с к ане р и многи е другие. Кром е того , в слу­
чае использовани я больш и х систе м управлен и я производство м , работающи х на осно­
ве больши х вычислител ьн ы х машин , для раб от ы с програм м о й може т требоватьс я
большое к о ли ч е ст в о оп е р а то р о в , кажды й и з которы х имее т собств енн ы й персональ­
ный к о мп ь ют е р , действующи й как термина л больш о й в ы чи сл ит ел ьн о й машины.
Планирован и е т е ст и р о в а н и я искл ючите ль н о важн о для координа ц и и тестиро в ан и я
интерфей с а "человек-компьютер" , поскольку, возможно , эт о — единственн о е тести­
рование , п р и кот ор о м продукт рассматривает с я полн ост ь ю с т о ч к и з ре н и я пользова­
теля. Ч е р е з это т и н т е рфе й с доступн ы дл я те ст и р о в а н и я многи е функциональн ы е тре­
бования пользовате л я , а им ен н о эт о и ест ь основна я це л ь системны х испытаний .
П р и использован и и интерфей с а "человек-компьюте р " для выполн ен и я тестиро­
вания с т о ч к и з ре н и я пользовател я следует учитыват ь одн о важн о е обстоятельство .
Если команд а т е с ти р о в а н и я начинае т т е ст и р о в а н и е с этап а системны х испытани й и
при это м инт ен с ив н о использует и н т е р фе й с "человек-компьютер" , диапаз о н тести­
ровани я будет оч е н ь ограничен . Т е с ти ров а н и е и н т е р фе й с а "человек-компьютер " —
лишь оди н из множест в а способ о в вып олн ени я быстрог о т е ст и р о в а н и я с целью об­
наружения ошибок . Фактически , как правило , процес с те сти р о ва н и я интерфе йс а
"человек-компьютер " оказы ваетс я н е слишко м э ф фе к т и в н ы м п р и поиск е даже наибо­
лее общи х ошибок , поскольку это т процес с больш е о ри е нт и ров а н на проверк у мар­
шрута прохожден и я поток а данны х по продукту, а эт о т маршрут уже подвергался ин­
тенсивному поблочном у т е с т и р о в а н и ю , выполняемом у п о тщательн о разработанны м
сценариям.
П р и о рга низ ац и и тестирован и я и нт е р ф е й с а "человек-компьютер " всегда полезно ,
чтобы с членам и команд ы тестиро ван и я сотруднича л администрат о р баз данных и
несколько кон е чн ы х пользователей . О н и могут ра зра ба тыва т ь тестов ы е случаи, сце­
нарии тестиро ван и я и методику обработ к и результато в тестиров ан и я для проверк и
правильност и отображени я входных данны х н а эк р ан е . Дале е така я ин ф ор м ац и я со­
храняется в соответствующ и х запися х баз ы данных , обра батываетс я и участвует при
составлении отч етов . Администрато р баз данны х и пользовател и могут такж е созда­
вать тес тов ы е случаи, сценари и тестир ован и я и методику обработк и результатов тес­
тировани я для прове рк и правильност и ф о р м а т и р о в а н и я выходны х данны х и их пе­
редачи на соответств ующ и й носител ь ил и в коммуник а ционн ы е буферы .
Ко н е чн ы е пользовател и могут оказат ь существенную помощь, сотрудничая с груп­
пой тестирова н и я пр и разработ к е объективног о приемочног о теста . В больших ор­
ганизациях существует должност ь бизнес-аналитика . Ка к правило , бизнес-аналитик
выполняет рол ь своег о род а конечног о пользователя , к от о р ы й оплачивае т работ ы и з
фонда прое кт а и организуе т тестирован и е и нт е р ф е й с а "человек-компьютер" , при­
званное определит ь приемлемост ь данн о й верси и программног о обеспечения .
Приемочны е тест ы , выполняемы е к он ечн ы м и пользователям и , как правило , будут
выполняться в соответстви и с опре д ел ен н ы м сценари е м и будут исследоват ь только
234 Часть II. Технологии быстрого тестирования и советы

удачные ветви программы. Тестовые случаи, сценарии тестов и методики обработки

результатов тестирования, разработанные конечными пользователями, могут быть
не такими строгими, как применяемые в ходе выполнения проекта. Но, несмотря на
это, найденные ими ошибки документируются, исправляются и повторно тестируют­
ся командой тестирования. Затем внесенные изменения, ориентированные на ис­
правление ошибок, снова тестируются конечными пользователями в ходе дополни­
тельных приемочных испытаний. С другой стороны, для обеспечения высокой на­
дежности версии программы и того, чтобы тестовые случаи, сценарии тестов и мето­
дики обработки результатов тестирования отражали основные случаи использова­
ния, тестирование, предпринимаемое бизнес-аналитиком, должно охватывать как
удачные, так и неудачные ветви.

Тестирование нагрузочной эффективности

Эффективный с точки зрения затрат способ расширения приложений заключается в
использовании распределенных вычислений. Существует два основных компонента
сетевой архитектуры: сервер и клиент. Сеть может иметь тысячи серверов и десятки
тысяч настольных персональных компьютеров, переносных компьютеров, беспро­
водных и карманных клиентов, каждый из которых подключается к серверам по сети.
Системы клиент/сервер являются одними из наиболее широко распространенных, и
огромная доля выполняемого в наши дни тестирования связана со средами типа кли­
ент/сервер/сеть. Тестирование требований безопасности и доступа относится ско­
рее к тестированию системы, чем к тестированию приложения. Для баз данных могут
потребоваться процессы создания экземпляров, поскольку приложение, выполняю­
щееся в одном городе/стране, при запросе базы данных должно получать те же ре­
зультаты, что и это же приложение, одновременно выполняющееся в другом горо­
де/стране.
Тестирование приложений типа клиент/сервер требует глубокого понимания ар-
хитектуры программного обеспечения, в том числе серверов хранилищ данных, ха­
рактеристик путей передачи информации и серверов балансирования нагрузки. Час­
то для успешности тестирования первостепенную важность имеет определение тес­
товых данных. В этом разделе приведены лишь несколько примеров, но соответст­
вующие аналогии можно найти и в других приложениях.
При тестировании приложений, в которых интенсивно используется обмен дан­
ными, должны применяться два подхода: использование тестовых шаблонов и ран­
домизированных потоков данных. Если основной целью тестирования является про­
верка надежности коммуникационного пути, то можно задействовать тестирование с
использованием шаблонов. Выявить искажение в повторяющемся графическом шаб­
лоне значительно легче, чем просматривать распечатку со значениями данных для
выяснения того, присутствует ли в них какая-то ошибка. Инженеры по электронике
аналогичным образом используют осциллографы, просматривая осциллограммы
сигналов тестовых частот для проверки правильности функционирования соедине­
ния или процесса. Специалисты по тестированию должны использовать эту техноло­
гию в ходе процесса самотестирования коммуникационного пути во время начально­
го запуска системы. Как только коммуникационный путь проходит процесс самотес­
тирования при начальном запуске, по нему можно передать заранее известный набор
 Глава 10. Технологии динамического тестирования и советы 235

данных транзакции, что позволит проверить правильность выполнения транзакции

и производительность процессора транзакций. Выходные данные, сохраненные в
выходных записях или журнальных файлах, можно автоматически сравнить с ожи­
даемыми результатами. Как правило, такие тесты разрабатываются в форме
регрессивных тестов для систем выполнения транзакций, которые постоянно
обновляются из-за добавления в производственную среду новых транзакций.
Приложения клиент/сервер поддерживают возможность применения тестовой
конфигурации, в которой программируются и загружаются сервер эмуляции высоко­
го темпа передачи данных и тестовый эмулятор хранилища данных. При такой кон­
фигурации можно проводить испытания банка производственных серверов, которые
подключаются к системе через сервер балансирования нагрузки, как показано на рис.
10.6. Сервер имитации высокого темпа прогоняет данные транзакций по альтерна­
тивному пути к серверу балансирования нагрузки, который, в свою очередь, прогоня­
ет эти данные через банк производственных серверов со скоростью, превышающей
обычные рабочие скорости передачи данных. Этот тест может выявить узкие места с
точки зрения производительности. При наличии ветви обратной связи от тестового
эмулятора хранилища данных к серверу имитации высокого темпа передачи, воз­
можно автоматическое сравнение выходных данных транзакций производственного
сервера с ожидаемыми выходными данными тестов. Эта замкнутая система может
использоваться для проведения лабораторных испытаний новых версий перед их
погружением в производственный процесс. Данная технология непосредственно
применима и к большинству Web-приложений.
236 Част ь II . Технологии быстрого тестирования и советы

ПРИМЕР: СОЗДАНИЕ ТЕСТОВЫХ ДАННЫХ (ГЭРИ КОББ)

Когда я работал в составе группы разработки программного обеспечения (Software En­
gineering Process Group, SEPG), ко мне подошел один из инженеров по тестированию и
спросил, что мне известно о силах Кориолиса. Я сообщил ему, что, насколько мне из­
вестно, это сила, возникающая в результате вращения Земли, которая оказывает влия­
ние на любое движущееся тело на ее поверхности или в толще земной коры, вызывая
отклонение от курса. Мы говорили о том, Что силы Кориолиса вызывают отклонение су­
дов и самолетов вправо от курса в северном полушарии и влево — в южном. Эта сила
оказывает также влияние на морские и воздушные течения.
Инженер по тестированию спросил меня, не согласился бы я помочь в создании входных
данных для тестовых случаев, которые будут использоваться во время тестирования не-
давно разработанной бортовой системы прогнозирования погоды. Я согласился и решил
при разработке данных воспользоваться электронными таблицами. Одной из причин та­
кого выбора послужило то, что в электронных таблицах все числовые вычисления выпол­
няются в 64-разрядном модуле арифметических операций с плавающей точкой. Все тес­
товые данные, которые были нужны инженеру по тестированию, показаны на рис. 10.7.
Глава 10. Технологии динамического тестировани я и совет ы 237
238 Часть II. Технологии быстрого тестирования и советы

Использование таких электронных таблиц при разработке данных для тестовых

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

Тестирование конфигурации платформы

Вариации в конфигурации существенно осложняют тестирование. Одним из таких
осложняющих факторов могут рассматриваться периферийные устройства. Каждое
периферийное устройство поставляется с драйвером фирмы-изготовителя, который
выбирается из набора драйверов для различных операционных систем. Именно по­
этому персональные компьютеры являются персональными. Из-за сложности и высо­
кой стоимости операционных систем и периферийных устройств тестирование при­
ложения для всех возможных конфигураций персональных компьютеров оказывает­
ся слишком дорогостоящим. Тестировщик, занимающийся быстрым тестированием,
должен относится к нему, как к тестированию ветвей, где полный охват не возможен,
и применять тестовые случаи только к преобладающим комбинациям операционных
систем и периферийных устройств.
Для того чтобы упростить управление набором тестовых платформ, можно вос­
пользоваться технологией разработки матрицы тестовых конфигураций, которая
ускоряет планирование и реализацию процесса тестирования и способствует органи­
зации процесса составления отчета по результатам. Предлагаемый формат матрицы
тестовых конфигураций показан в таблице 10.3. Элементы, приведенные в столбцах
H1 и Н2, должны иметь подробные спецификации файла, описывающего номера
версий программно-аппаратного обеспечения и положений переключателей для лю­
бого реконфигурируемого оборудования.
Если матрица платформ большая и сложная, она может быть базой данных, обес­
печивающей датирование транзакций и регистрацию в журналах для реализации
управления конфигурациями. Для отражения изменений в аппаратном обеспечении
можно с заданной периодичностью выполнять проверки этой матрицы, призванные
дать ответ на вопрос: выполняется ли тестирование оборудования на самых совре­
менных платформах, занимающих такое же место на рынке, как и тестируемый про­
граммный продукт? Эта матрица или база данных тестовых конфигураций должна
совместно использоваться всеми партнерами, несущими ответственность за тестиро­
вание конечного программного продукта.
Обычно при поставке программного продукта на общий потребительский рынок
принято перечислять основные требования к платформе. Пример требований к
платформе, указываемых при поставке на потребительский рынок, приведен в таб­
лице 10.4. Информация из этой таблицы не совпадает с данными, приведенными в
матрице тестовых конфигураций. Например, при указании операционной системы
для тестовой конфигурации необходимо упоминать номер версии и уровень сервис­
ного пакета. Кроме того, жесткие диски должны указываться вместе с названием
фирмы-изготовителя, версии программно-аппаратного обеспечения, версии драйве­
ра и любых других параметров. Тестировщикам придется разработать отрицатель­
ные тесты для нескольких конфигураций с отсутствующими или неподходящими
компонентами. Это даст возможность задокументировать то, как приложение обра­
батывает каждую из неподдерживаемых конфигураций.
Глава 10. Технологии динамического тестировани я и советы 239
240 Часть II. Технологии быстрого тестирования и советы

Резюме
В дополнение к технологиям и советам по статическому тестированию, упомянутым в
главе 9, в главе 10 освещены дополняющие их технологии и советы по динамическо­
му тестированию. Каждый специалист по тестированию должен поэкспериментиро­
вать с этими технологиями и оценить, насколько каждая из них применима для кон­
кретных целей тестирования. Неплохо описать собственный опыт по использованию
новой технологии и добавить этот материал к рассмотренному в данной главе. В этой
главе было показано, что несмотря на то, что много участников тратят массу времени
на тестирование продукта с точки зрения пользователя и с помощью графического
интерфейса, существует ряд очень важных тестовых случаев, которые должны быть
разработаны с целью оценки аспектов продукта, отличных от графического интер-
фейса. Расширяемость, устойчивость к ошибкам, пригодность к высокому темпу пе­
редачи данных, возможность использования в средах поврежденных платформ и
точность результатов считаются наиболее важными областями выявления ошибок в
конечном продукте. Параллельное выполнение тестовых случаев требует координи­
рования и, в ряде случаев, участия назначенного координатора тестирования. При­
менение технологий статического тестирования к результатам тестирования для тща­
тельной их проверки на предмет возможных ошибок представляется разумной
тратой времени на последнем этапе разработки.
Памятуя об этом, приходится лишь удивляться, когда известие в какой-то органи­
зации о том, что продукт прошел приемочные испытания, вызывает восторг, а зачас­
тую и удивление. Так не должно быть. Каждый член команды разработки должен не­
сти достаточную ответственность за выполнение тестирования, чтобы иметь уверен­
ность в том, что конечный продукт полностью соответствует требованиям пользова­
телей, и в будущем будет способствовать процветанию организации.
 Разработка и
использование
показателей
тестирования:
моделирование и
прогнозирование ошибок
Темы, рассматриваемые в главе:
• Определени е показателей и данных измерени й
• Использование стандартных показателей
для внесения усовершенствований
• Показатели тестировани я
• Проектно-ориентированная модель ошибок
• Программа оценки ошибок программного
обеспечени я (SWEEP)
• Резюме

При планировании нового проекта кто-то обязательно задает вопрос: "А где какие-
либо фактические данные наших предшествующих проектов?" Может возникать и
вопрос: "Какая связь между планом и данными измерений?" План полезен только в
том случае, если он расходится с действительностью не более чем на +/-20%. Данные
измерений полезны, только если они применимы к проекту, условия которого анало­
гичны условиям предыдущего проекта, когда эти данные были получены.
Представьте себе, что вы являетесь владельцем небольшой океанской яхты и со­
бираетесь плыть из Атлантик-Сити, Нью-Джерси, на Багамы. Вам пришлось бы по­
добрать карты атлантического побережья с отображением морских путей, глубин,
портов и маяков. Вам потребовалось бы выбрать маршрут и подсчитать время путе­
шествия с учетом быстроходности яхты и любых ограничений скорости, указанных в
навигационных картах. При планировании необходимо выполнить ряд вычислений с
учетом скорости расходования различных припасов. Вам следовало бы решить,
сколько человек планируется взять с собой в путешествие. Промежуточные результа­
ты, подобные количеству дней путешествия, определяют количество порций завтра­
ков, обедов или ужинов, которые потребуются, чтобы прокормить присутствующих
242 Часть II. Технологии быстрого тестирования и советы

на борту яхты людей. В соответствии с этим планом вы запасетесь соответствующим

количеством топлива, питьевой воды, пищи и других припасов. Эта информация на­
ходит свое отражение в навигационном и продовольственном планах, в судовой дек­
ларации и карте маршрута.
В море капитан яхты будет сверяться с навигационным планом, записывая такие
данные измерений, как скорость и текущий курс. На основе этих данных он вычисля­
ет время, когда следует начинать высматривать конкретный порт или маяк. Назначе­
ние этого набора фактических данных измерений состоит в привязке навигационно­
го плана к известным пунктам маршрута. Отслеживая эти данные измерений и срав­
нивая их с контрольными пунктами, капитан может ответить на такие наиболее ти­
пичные вопросы, как "Мы еще не сбились с курса?" или "Не выбились ли мы из
графика?".
Применительно к проектам разработки программного обеспечения процесс пла­
нирования заключается в объединении выбранного жизненного цикла разработки и
его этапов (навигационные карты и маршрут), набора функциональных требований
(протяженность путешествия в милях), нормативов по количеству строк кода, кото­
рые должны быть созданы за час работы (предварительно определенная скорость
яхты, выраженная в милях/ч), графика загрузки персонала по месяцам (маршрут) и
промежуточных сроков выполнения проекта (маяки и порты).
В ходе разработки руководитель проекта фиксирует фактические данные, напри­
мер, полученные в течение текущей недели данные по количеству вариантов исполь­
зования, количеству строк кода, количеству обнаруженных и устраненных ошибок и
процентному отношению выполненных тестовых случаев к общему их количеству.
Кроме того, руководитель разработки программного обеспечения просматривает
план проекта и его календарный график, чтобы иметь возможность ответить на ти­
пичный вопрос: "Не срываются ли сроки выполнения проекта?"
В главе 11 приведены определения показателей и описаны способы сбора и ана­
лиза данных измерений. Глава 12 посвящена вопросам определения необходимого
штата и календарного графика выполнения работ для стандартного жизненного цик­
ла с использованием стандартной модели оценки затрат. Концепция быстрого тести­
рования предполагает применение программных показателей, разработанных на ос­
нове сбора и использования данных измерений, полученных в ходе выполнения пре­
дыдущих проектов быстрого тестирования. В результате достигается постоянное со­
вершенствование процессов, повышение качества, снижение затрат и сокращение
плановых сроков поставки продукта.

Определение показателей и данных измерений

Программный показатель — это стандартный способ измерения какой-либо характе­
ристики процесса разработки программного обеспечения. Данные измерений — это
числовые данные, собранные и зафиксированные в единицах измерения, определен­
ных для показателя. Например, если показателем является количество скрытых оши­
бок на тысячу строк кода (К lines of code, KLOC), то набор данных измерений мог бы
выглядеть следующим образом: {Программа А: 2,6 ошибок/KLOC; программа В: 12,1
ошибок/KLOC; программа С: 5,8 ошибок/KLOC}.
 Глава 11. Разработк а и использовани е показателе й тестировани я 243

Ос н ов н ы е преимуществ а примен ени я прог ра ммн ы х показателе й заключаютс я в

следующем:

• В возм о ж но ст и использовани я исходны х ср а вни т ел ьн ы х данны х совм ест н о с

другим и проектам и разраб отки .

• В в оз мо ж н ос т и сбор а данны х о с остояни и , выражаемы х в одни х и те х же еди­

ницах , в о все й организац и и для о п р е д е л е н и я успешност и в ыполнен и я ст о я щ е й
задачи .

• В возм о ж но ст и выполнит ь прог н ози ров ан и е сравн ительн ы х трудозатрат .

• В возм о жн о ст и оц е ни т ь трудоемкост ь ил и календарн ы й план , исход я из имею­

щегос я опы т а разработок .

• В возм о жн о ст и во врем я формальны х пе р е с м о т р о в составлят ь отчет ы по дан­

ным , характеризующи м тенденци и процесса .

Да нн ы е и з м е ре н и й програ м м ы должн ы быт ь получен ы или п р е о б р а з о в а н ы в чи­

словые един иц ы из м е ре ни я , о п ре де л ен н ы е для п р ог ра м мн ог о показателя . Эт и дан­
ные д ол жн ы хар акте ризо в а т ь атрибут ы про гр а мм н о г о процесса , ег о результат ы ил и
календарны й пла н ил и ресурсы проект а р а з р а б о т к и . Неск оль к о прим еро в программ ­
ных показателей , разделен н ы х п о стандартн ы м пром ышленн ы м категориям , приве­
ден о в табли ц е 11.1.
Пр ежд е всего , следует уяснить, чт о существуют т ы с я ч и возможны х программн ы х
показателе й . П р и изм е ре н и и большинств а и з ни х необходим а методичност ь и боль­
шие затрат ы времени , и для одно й к онк рет но й группы раз ра б от к и о н и могут оказать­
с я эк оном иче с к и н е э фф е к т и в н ы м и . В обще м случае выбо р показател е й и з списка ,
подобног о приведенном у в таблиц е 11.1, може т быт ь сродн и хождени ю п о минном у
полю, есл и т о ль к о не подходит ь к процесс у о п р е д е л е н и я и использовани я показате ­
лей оч ен ь пр аг ма ти чн о . В это м смысле не я в л я ют с я исключение м и показател и тес­
тировани я . Ни ж е приведе н практически й п р и м е р , представляющи й точку з р е н и я
одного из авторо в и иллюстрирующи й при м ен яе м ы й им подход к определен и ю пока­
зателей , к от ор ы й удовлетворяе т потребност и о рга низ ац и и и пр и это м н е становитс я
обузой ни для одног о из проект о в внутри орг ан изац и и . В данно м случае терми н "ор­
ганизаци я " употребляетс я в отно ш ен и и нескольки х прое кт о в разработ к и программ­
ного обеспечени я , выполняемы х под одни м и те м же руководством (на пр и ме р , в ка­
ком-нибудь подразделени и боле е крупно й комп ании) .
244 Част ь I I . Технологии быстрого тестирования и совет ы
 Глава 11. Разработка и использование показателей тестировани я 245

ПРИМЕР: ПРОГРАММА ОПРЕДЕЛЕНИЯ ПОКАЗАТЕЛЕЙ (ГЭРИ КОББ)

В течение примерно шести лет автору довелось выступать в роли координатора разра­
ботки программных показателей в организации, занимающейся созданием программно-
го обеспечения, в которой трудились около 450 разработчиков. Будучи членом группы
координации процесса разработки программного обеспечения (Software Engineering
Process Group — 5EPG), функции которой определены в модели развития функциональ­
ных возможностей (Capability Maturity Model, CMM V1.1) института технологий про­
граммного обеспечения SEI, мне пришлось изучить более 400 Программных показате­
лей, предлагаемых SEI. На основе этого исследования я пришел к выводу, что в кон-
кретной организации следует стандартизировать лишь небольшое количество показате-
лей. Основная масса показателей должна разрабатываться, отбираться, анализироваться
||и использоваться каждой группой в зависимости от этапа разработки.
При определении программы создания показателей для нескольких независимых проек-
тов разработки программного обеспечения я установил ряд общих стандартов показате­
лей, отчеты о которых Должны были поступать из всех проектов и анализироваться в
SEPG. Но одновременно мною был создан процесс; который позволял в каждом проек-
те определять и использовать собственные показатели, которые не нужно было вклю-
чать в отчет или переносить в другие проекты. Стандартный набор из четырех про-
граммных показателей, который был предложен, утвержден и принят для использования
во всех проектах разработки программного обеспечения, описан в таблице 11.2.

Ожидалось, что фактические данные по каждому из этих показателей будут сообщаться

в ходе формального пересмотра, проводимого на каждом из основных промежуточных
этапов жизненного цикла разработки. Эти основные промежуточные этапы и связанные
с ними формальные пересмотры соответствуют основным этапам каскадной модели
жизненного цикла. В их число входят эскизное проектирование (ЭП), рабочее проекти­
рование (РП), тестирование кода и модулей (ТКМ) и комплексные и системные испыта-
ния (КИ). В качестве примера на рис. 11.1 приводится диаграмма показателя размера
программы, которую можно представить во время формального пересмотра на этапе
ТКМ. Часто большая система допускает разложение на основные подсистемы, пред-
оставленные на диаграмме отдельными слоями. В приведенном примере размер про-
граммы в значительной степени изменяется от одного этапа к другому. Не вдаваясь в
подробности, можно утверждать лишь следующее. На этапе разработки требований
был определен приемлемый размер проекта, но на этапе ЭП предполагалось, что свы­
ше 100000 строк кода будут использоваться повторно. Впоследствии, по завершении
этапа ЭП выяснилось, что фактически код повторно использоваться не может. В резуль­
тате оценки размеров модулей были пересмотрены, что и нашло свое отражение в диа­
грамме, начиная С этапа РП.
На рис 11.2 приведена диаграмма фактических данных по занятости персонала, на ко-
торой показана фактическая загрузка персонала в течение первых четырех месяцев
(т.е. 16 недель) и предполагаемая загрузка до окончания проекта (начиная с 16-ой не­
дели). В случае выполнения масштабных проектов данные измерений загрузки персона-
ла разбиваются по этапам и/или характеру выполняемых работ.
246 Част ь II . Технологии быстрого тестировани я и советы

В данном случае такими этапами являются: эскизный проект (ЭП), рабочий проект (РП),
программирование (П), тестирование модулей (ТМ) , системные испытания (СИ), прочие
работы (Пр) и вспомогательные работы (ВР). В процессе анализа этой диаграммы за­
груз к и персонала у руководителя разработк и до лж е н был бы возникнуть естественный
вопрос: "Что на четвертом месяце привело к уменьшению количества занятых в проекте
людей?" Судя по представленным данным, в течение 12-й, 13-й и 14-й недели разработ­
ки имели мест о потери персонала, за ко т о р ы м последовало р ез к о е увеличение ег о к о ­
личества. Будучи руководителем , следует вскрыть причину столь странного поведения
показателя и выяснить, было ли это естественным отражение м особенностей процесса
разработк и или же признаком наличия проблемы , ко т ор у ю необходимо решить немед­
ленно, а не когд а делать это будет у ж е поздно .
На рис. 11.3 показана диаграмма загрузк и персонала по месяцам , на которо й представ­
лены следующие этапы: разработка требований (ТЗ), эскизное проектирование (ЭП),
рабочее проектирование (РП), тестирование кода и модулей (ТКМ) и объединенные
комплексные и системные испытания (КИ). К р о м е того , в верхней части диаграммы
мечены формальные пересмотры , проводимые в конце соответствующих этапов,
именно: заключение договора (ЗД) , пересмот р эскизного проекта (ПЭП), критически
пересмот р проекта (КПП), пересмотр готовности к тестированию (ПГТ) и приемочный
пересмот р (Поставка). Месяцы, в течение которых разрабатываются требования, имеют
отрицательную нумерацию , поскольку проводить какое-либо прогнозирование не воз­
м о ж н о до тек пор , пока требования не определены, и, как правило, отсчет времени
разработки начинается с момента заключения договора .
Обратите внимание, что на четвертом месяце диаграммы происходит переход от этапа ЭП к
этапу РП, который длится около половины месяца. Именно в течение этого периода по пла-
ну должно быть произведен пересмотр эскизного проекта (ПЭП). Если учесть, что эта диа-
грамма была создана по окончании завершении проекта, то из сроков промежуточных эта-
пов (включая поставку) становится ясно, что разработка этого проекта выполнялась в со<
ветствии с календарным планом (промежуточные этапы приходятся на те же месяцы, в
торых происходил переход от одного этапа к другому) . Соответствие плану можн о опреде -
пить, наложив диаграмму с измененными сроками промежуточных этапов, и, следователь-
но, с измененными плановыми сроками, на диаграмму загрузки персонала.
На практике м о ж н о руководствоваться следующим эмпирическим правилом: смещение
или удлинение плановых сроков м о ж н о считать номинальным, если это изменение не
превышает 10%. Для плана проекта, предусматривающего выполнение проекта за 20
месяцев, завершение проекта в период м е ж д у 18 и 22 месяцем оказалось бы номи­
нальным. Изменения плановых сроков отдельных промежуточных этапов должн ы приво­
диться к ближайшему полумесячному с р о к у . Аналогично, если бы план предусматривал
выполнение проекта в течение 20 недель, завершение разработки в период м еж д у 18 и
22 неделями было бы номинальным, причем изменения отдельных промежуточны х эта-
пов должны приводиться к ближайшему полунедельному срок у .
На рис. 11.4 приведено графическое представление измеренных данных показателя ка­
чества, а именно — количества обнаруженных ошибок на тысячу предполагаемых ис­
ходных строк кода (К of estimated source lines of code , KESLOC). Количество ошибок на
тысячу строк кода , обнаруженно е на кажд о м этапе жизненного цикла разработки , со­
общается по завершении каждог о из этих этапов. В данном случае этапы соответствуют
этапам каскадной модели жизненного цикла разработки программног о обеспечения, а
именно разработке требований (ТЗ), эскизном у проектированию (ЭП), рабочем у п р о
тированию (РП), тестированию кода и модулей (ТКМ) , комплексным испытаниям
системным испытаниям (СИ) и приемочным испытаниям (ПСИ).
В случае больших програм м количество ошибок м ож е т определяться отдельно для каж­
дой категории серьезности ошибок и отображаться в виде накладывающих одна на дру­
г у ю столбчатых диаграмм . Анализ значений данных этой столбчатой диаграммы показы­
вает, что данный проект является проектом , в ко т о р о м применяется быстрое тестирова­
ние. Почему? 4 1 % ошибок были обнаружен ы в ходе статического тестирования еще до
начала этапа ТКМ , 36,3% ошибок были обнаружен ы на этапе ТКМ , и 22,7% — метода­
ми динамического и статического тестирования после завершения этапа ТКМ . Большинс-
 Глава 11. Разработка и использование показателей тестировани я 247

тво ошибок (77%) было обнаружено и устранено на наиболее эффективном с точки

зрения затрат этапе жизненного цикла разработки, а не после завершения этапа ТКМ.
На основе анализа этого конкретного случая SEPG и руководство института пришли к за-
ключению о целесообразности того, что руководители всех проектов должны сообщать
одни и те же четыре программных показателя (размер программы, количество занято-
го персонала, календарный план и качество). При этом они должны были делать это в
графической форме, используя одни и те же определения и единицы измерений. Это
позволило главному менеджеру и директорам сравнивать проекты между собой и зада
вать менеджерам разработки программного обеспечения более уместные вопросы.
На рис. 11.5 представлены двухуровневый набор показателей и программа составления
отчетов, которые использовались в названной организации более 5 лет. Элементы верх­
него уровня уже были полностью описаны. Соответствующие отчеты могут составляться
на основных этапах, например, во время пересмотра эскизного проекта (ПЭП), крити-
ческого пересмотра проекта (КПП), пересмотра готовности к тестированию (ПГТ) и по
завершении заключительного тестирования качества (ЗТК). Нижний уровень представляет
собственные показатели проекта, которые были отобраны, проанализированы и включе­
ны в отчет с целью удовлетворения специальных требований проекта.
248 Част ь II . Технологии быстрого тестирования и советы
 Глава 11 . Разработк а и использовани е показателе й тестировани я 249

В следующем практиче ск о м при м ер е мы познакоми мс я с технологи е й определе­

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

ПРИМЕР: ПРИМЕНЕНИЕ ПРОЦЕССА ЦВП ДЛЯ ОПРЕДЕЛЕНИЯ ПОКАЗАТЕЛЕЙ

ПРОЕКТА (ГЭРИ КОББ)
В SEPG команды разработки были обучены применять специализированные показатели,
соответствующие требованиям каждого отдельного проекта и клиента. Для членов ко­
манд был прочитан обучающий курс по процессу "цель-вопрос-показатель" (ЦВП), в ос­
нову которого были положены исследования Базили (Basil!) и Вейса (Weiss) [6], Метод
ЦВП состоит в определении целей (goal) измерения каждого из показателей, формули-
ровании вопросов (questions), на которые измерения должны дать ответ, и определении
нормализованной формулы показателя (metric), который может масштабироваться в
зависимости от размерности разработки. Примерами вопросов, относящихся к тестированию,
ответы на которые могут быть получены в ходе выполнения процесса ЦВП, являются:
• Каково качество программного проекта?
• Каков фактический коэффициент переделок?
• Каков коэффициент закрытия отчетов о дефектах?
250 Част ь II. Технологии быстрого тестирован и я и советы

• Каково соотношение фактического коэффициента ошибок и прогнозируемого, норма-

тивного и среднего значений этого показателя?
• Для каких компонентов потребуется дополнительное тестирование?
• С какими областями связано преобладающее большинство проблем?
Профессор Виктор Базили {Victor Basil!) и доктор Девид Вейс (David Weiss) из универси­
тета Мериленда сформулировали принцип ЦВП в конце семидесятых годов, работая над
проектами в центре космических полетов Годдарда, NASA. Свою работу, посвященную
ЦВП [6] , они опубликовали в 1984 г, Рини ван Сояингем (Rini van Solingen) и Эгон Бергхот
(Egon Berghout) [50] продолжили разработку концепций ЦВП, сделав их составной ча­
стью принципа повышения качества (см. рис. 11.6).
На первом шаге команде разработки рекомендовалось записать цели, которые ставятся
перед командой руководством института, организацией, осуществляющей руководство
проектированием, лицами, принимающими решения, и любыми другими организациями
(подразделениями), участвующими в управлении проектом. К характеристикам, которые
могут быть сформулированы в качестве целей, могут относиться рентабельность, эф-
фективность, качество продукта, степень удовлетворения требований клиента, объем
программного кода и производительность разработки.
На втором шаге организуется совещание, в ходе которого занятый в разработке проек­
та персонал проводит "мозговой штурм" по перечню вопросов или проблем, которые
должны быть выяснены, чтобы принимающие решения лица могли эффективно сплани­
ровать проект. Примерами вопросов, которые связаны с возможностью срыва плановых
сроков, могут служить:
• Влияют ли последние изменения в бюджете на сроки выполнения тестирования?
• Соблюдаются ли плановые сроки тестирования?
• Какие события оказывают решающее влияние на действующий в настоящее время ка­
лендарный график тестирования?
• Каковы последствия срыва календарного графика?
На третьем шаге предполагается обсуждение данных проекта, которые должны быть
собраны (или сбор которых планируется), и того, можно ли на основе этих данных и их
анализа получить ответы на вопросы, поставленные на втором шаге. Эти данные изме­
рений могут собираться на уровне проекта или же быть внешними данными, такими как
ресурсы, фактические затраты, сроки каждого из промежуточных этапов, распределе­
ние дефектов продукта по уровням серьезности или перечень сгруппированных по
сборкам задач, которые должны быть решены. Таблица 11.1 содержит множество про­
ектных показателей, относящихся к тестированию.
Подводя итоги анализа двух приведенных примеров, можно отметить следующее. Двух­
уровневая программа определения показателей была полностью одобрена всеми ко­
мандами выполнения отдельных проектов. Им импонировало иметь свободу при созда­ нии
собственных наборов показателей, по которым можно было составлять внутренние %
отчеты или отказываться от их использования. Разделение функций между коллекцией
показателей SEPG (для сбора данных измерений на общеинститутском уровне) и про-
ектной коллекцией показателей (для сбора данных измерений на уровне отдельного
проекта) оказалось ключевым фактором успешной деятельности института, его проек-
тов и сохранения базы клиентов.
 Глава 11. Разработка и использование показателей тестирования 251

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

внесения усовершенствований
Простое выполнение в рамках одной организации множества проектов по разработ­
ке, направленных на совершенствование процесса, еще не гарантирует создание про­
граммного обеспечения мирового класса. Если каждая команда выбирает собствен­
ное направление совершенствования процесса или продукта, оптимизация процесса
будет носить случайный характер. В этом случае локальная оптимизация выливается
в одно из направлений глобальной оптимизации. Для обеспечения быстрой оптими­
зации программного обеспечения усилия должны быть согласованы в рамках всей
организации с соблюдением общего для нее подхода. Успешность совершенствова­
ния управления процессом разработки программного обеспечения определяется сле­
дующими факторами:
• Точным прогнозированием взаимосвязи между функциональными возможно­
стями программного обеспечения и его объемом, количеством занятого в раз­
работке проекта персонала, календарным графиком и качеством проекта.
• Определением задач и ресурсов/качества/стандартов, необходимых для ре­
шения каждой задачи.
• Обеспечением успешности и требуемой производительности при выполнении
каждого шага процесса.
• Максимально быстрым выявлением дефектов после их появления.
• Обработкой дефектов таким образом, чтобы обеспечить максимально быстрое
эффективное устранение наиболее важных дефектов.
252 Част ь II. Технологи и быстрог о тестировани я и совет ы

Рекомендуем а я стратег и я создани я сопров ожд аю щ е й документац и и п о это й мето­

дик е опр ед е ле н и я программны х показателе й с ост о и т и з двух частей :

1. П р и м е н е н и е стандартног о набор а о п р е д е л е н и й пока зателе й и последующий

сбо р и анали з данны х программны х и з м е ре н и й в рамка х всех выполняемы х в
орга низаци и пр о е кт о в .

2. П р и м е н е н и е процесс а п ри н ят и я ре ш е н и й "цель-вопрос-показатель" для выбо­

р а п рое кт ны х программны х измерений .

О д н о и з наиболе е э ф ф е к т и в н ы х действи й , ведущих к сов ерш енство ван и ю про­

цесса — эт о управлен и е способ о м прог н ози рова н и я ресурсо в с цель ю повышени я его
то чн о ст и . Если прогнозир уем ы е значени я нанест и н а диаграмму процесс а разработ -
ки с при вяз к о й к каждому из основны х промежуточн ы х этапов , после чег о сравнит ь
совпадени е кривы х обучен и я с фа ктически м и д ан н ы ми , можн о отслеживат ь точност ь
прог н ози ров ан и я . П р и м е р примене ни я это й технолог и и к прогнозирова н и ю загруз­
к и персонал а п оказ а н н а рис . 11.7, к от ор ы й взя т и з [6] . Прогнозируемы е данные
приводят с я к среднем у зн а чен и ю А и наносятс я на диаграмму, по горизонтальн о й оси
кот оро й отс читыв ает с я врем я в месяцах. Круглы е т о ч к и представляю т нормализо­
ванны е прогнозир уем ы е зн ачени я , прич е м последн е е прогнозиру ем о е зн ач ен и е при­
ходитс я на к он е ц 7-го месяца . На диаграмму можн о н а л о жи т ь кривы е функц и й U и L
(обозначенн ы е квадратиками ) и те м самы м оп р е де л и т ь показател ь э кс поне н т ы В.
Че м выш е зн ач ени е В , т е м быстр е е прогнозируем ы е знач ен и я начинаю т совпадать с
фактичес ким и .
 Глава 11. Разработк а и использовани е показателе й тестир овани я 253

Н а основ е значен и й , полученн ы х в ход е предыдущи х раз ра б от о к , м ож н о создат ь

обеспечивающу ю приемлем у ю то ч н ост ь модел ь п рог ноз и ров а н и я коли че ст в а персо­
н а л а/ к а л е н д а рн ы х с рок о в р а з р а б о т к и п р ог р ам мн о г о обеспечени я , к о т о р а я пред­
ставляетс я не л и н е й н о й функцие й о т объем а програм м ы . Результат ы к о рре к т н о вы­
полненног о модели ро ван и я могут избави т ь руководителе й о т сложн ы х проблем , воз­
никающи х пр и использовани и п р о ст о й л и н е й н о й модел и прогн ози ров ан и я трудоем­
кости и времени , требующегос я дл я вып о лн ен и я проекта . На п р и м е р , в с оотв етс тв и и
с пр о ст о й л и н е й н о й моделью , есл и нова я разр аб от к а вдвое превосходи т п о объему
предыдущую, е е бюдже т долже н вдвое превосходит ь стоимост ь предыдуще й разра­
ботки . В действительност и ж е зависимос т ь между затрата м и и объемо м р а з р а б о т к и
н е ли не й на , и пр и использован и и неподходящ е й модел и ошибк а прог ноз и ров ан и я
може т оказатьс я весьма значительной .
П р е жд е че м можн о будет воспользовать с я не л и н е й н о й модель ю зав ис им о ст и о т
объема программног о обеспечения , потребуется выполнит ь следующие четы р е задачи:

1. С об р ат ь данные , полученн ы е в ходе вып олн ени я предшествующи х прое ктов ,

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

2. По аналоги и с предыдущим и проектам и р аз р аб от ат ь оц е н к и , сравнива я тру­

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

3. Создат ь календарны й граф и к выполн ен и я основны х промежуточны х этапов ,

н а баз е которог о создат ь календарны й графи к выпол нен и я всег о проект а п о
месяцам .

4. За в е рши т ь оценку, оп р ед е ли в колич ест в о персонала , необходимог о для вы­

полн ен и я каждо й задачи , и ра спр еде ли т ь загрузку персонал а п о соответст­
вующим этапам календарног о гра фи к а разработки .
Со общен и е всеми группами разработк и таки х данны х изм е ре ни й , ка к показател и
объема, занятост и персонала , стоимост и и качества , в центральну ю о рга низ ац и ю на­
подобие SEPG обеспечивае т проверк у различн ы х проект о в н а предме т единообраз и я
выполнени я . Кром е того , эт и данн ы е изм е ре н и й поддер жива ю т н е л и н е й н о е модели­
ровани е обще организацио нн ы х процессо в разработки , которы е определен ы н а ос­
нове фак ти че с ки х данны х изме ре ний , полученны х в ходе вып о лн ен и я предыдущих
проекто в в аналогично й сред е разработки . То чн о е пр огн ози р о ва н и е характеристи к
новых проект о в направлен о на рез ко е сн и ж е н и е хаос а в орг ан изац и и , и сбо р и ана­
лиз данны х изме рен и й эти х стандартн ы х показателе й в з н а ч и т е л ь н о й ст е п е н и спо­
собствует достижени ю так о й цели . Об щ и й дл я к он к р ет н о й орг ан изац и и процес с
управления данным и изм е ре ни й долже н включат ь в себя каждый из пят и видо в дея­
тельности , перечисленн ы х в таблиц е 11.3.
254 Част ь II. Технологи и быстрог о тестирован и я и совет ы

Если п рое к т ы р азр а бо т к и програ ммног о об е сп е ч ен и я поддерживаютс я общеор­

ганизационны м и функция м и сбор а и анализ а данны х измерений , эт о позволяет
управлят ь совер шенств ова ни е м процесс а и сра вни в ат ь ег о результат ы с результата­
ми, полученным и в ходе ране е выполнявшихс я р аз ра бот о к . В результате снижается
дол я спец и ал изи ров ан н ы х ил и скоропалительн ы х измен ени й , которы е препятствуют
организац и и пов ы ша т ь качеств о ил и с о к ра щ ат ь сро к и поставк и программны х про­
дуктов на ры н о к . Календарн ы е сроки , качеств о и з атрат ы — основны е показатели
коммерческо й деятельност и . Поэтому, чтоб ы органи заци я , занимающаяс я разработ­
ко й прог р а мм но г о обеспечени я , смогла вы жи т ь в условиях конкуренции , процессы
создани я п р ог ра м мн ог о о б ес пе ч е н и я д ол жн ы оценив а ть с я именн о с таки х коммерче­
ских пози ци й . При н ц и п быстр ог о тестиро ван и я обеспечивае т совершенствовани е
процесс а в следующих областях:

• Календарног о планиро ван и я — путем выделени я дополнительны х ресурсов для

действи й п о тестиров ан и ю д о начал а этап а ТКМ , чт о позволяе т ужать кален­
дарны е ср ок и выполнен и я действи й п о тестиро ван и ю н а последующих этапах
и способствуе т ускорени ю поставк и на р ын о к очередны х выпусков программ­
ны х продуктов .
• Качеств а — путем обнаружени я и устранени я большег о количеств а дефектов,
чт о снижае т п р о це н т скрыты х дефект о в в выпущенны х продуктах.
• Стоимост и — путем снижен и я одноразовы х затрат , объе м которы х выше в тех
проектах , где обнаружени е и устранени е де фект о в откладываетс я до заключи­
тельны х этап о в жизн ен н ог о цикла.
 Глава 11. Разработка и использование показателей тестирования 255

Показатели тестирования
Если вспомнить концепцию двухуровневой программы определения показателей,
может возникнуть вопрос о ее применимости к показателям тестирования. Относят­
ся ли показатели тестирования к более высокому, общеорганизационному уровню,
или же к проектно-зависимому уровню этой двухуровневой программы? Как будет
показано в этом разделе, почти все показатели тестирования относятся к категории
проектно-зависимых показателей. Примеры показателей тестирования, используе­
мые в проектах, приведены в таблице 11.4.

Разработка эффективной программы определения показателей требует строгой

дисциплины при выполнении измерений, анализе результатов этих измерений и по­
строении отчета о тенденциях, о которых свидетельствует анализ. Требуемые для
этого усилия и дисциплина могут существенно увеличить трудоемкость программы
разработки показателей, но эти дополнительные усилия очень важны для успеха лю­
бой инициативы по совершенствованию процесса. Когда изменения для совершенст­
вования процесса вносятся в ходе выполнения проекта, измерения будут единствен­
ным способом определить ценность проделанных усовершенствований процесса.
При сравнении одного проекта с другим сравнение полученных в ходе выполнения
проекта данных — единственный способ выявления различий между проектами.
256 Часть II. Технологии быстрого тестирования и советы

Плотность ошибок (количество ошибок на тысячу

эквивалентных строк кода)
Наиб оле е в а жн ы е показат е л и т е с т и р о в а н и я связан ы с ошибкам и (дефектами ) . Для
проект а представляет с я вполн е ест е ст ве нн ы м выполнени е конк ретизац и и ошибок,
ра зд ел е н и е и х п о п р и о р и т е т а м и категориям . Ка к правило , разделен и е ошибо к п о
п р и о р и т е т а м выполняет с я в соотв етств и и с нормативам и по оп р ед е ле н и ю уровня
се р ьез н ос т и ошибок , как показан о в т аб л и ц е 11.5. О б ра ти т е внимание , чт о номер
уровн я се рь езн о ст и присваивает с я таки м образом , чт о 1 соответствуе т категории
ката строфич еск и х ошибок , а 5 — ка тег о р и и не п ри ят н ы х ошибок . О п р е д е л е н и я серь­
езност и , перечис ленн ы е в табли ц е 11.5, совпадаю т с определениям и из табли ц ы 5.2 в
главе 5.

Сбо р данны х о д е фе кт а х и создани е гистограмм ы с использование м номеро в серь­

езност и , присвоенн ы х каждому дефекту , позволяе т аналитику описат ь качеств о вы­
пуска программы , ко то р ы й будет проверятьс я в о врем я формальны х пересмотров.
П р и м е р гистограмм ы плотност и ошибок , сгруппированны х по номера м уровня серь­
езност и , показа н на рис . 11.8. О бр а ти т е вни ман ие , чт о эт и данны е приведен ы к ожи­
даемому объему программы , выраженном у в тысяча х стро к эквивалентног о кода.
И з приведенн ы х н а рис . 11.8 данны х видно , чт о большо й объе м ошибо к бы л обна­
ружен н а ранни х этапа х жи знен ног о цикл а разработки . И з эти х данны х пон ятн о , что
для обнаружени я ошибо к на этапа х разработк и требовани й , про е кти р ов ан и я и коди­
рован и я применял ос ь статическо е тестирование . Об ра ти т е такж е внимание , что н а
этапа х РП и кодировани я был о обнаружен о больш е серьезны х ошибок , чем на этапе
К И . Эт о означает , чт о тщательно е тестирован и е продукта был о начат о задолго д о
этап а К И — подход, кот оры й являет с я о т л и ч и т е л ь н о й черт о й быстрог о тестирова­
ния . Если создат ь программу опр еделе н и я показателей , котора я обеспечивае т под­
сче т и составлени е отч ет о в об ошибках , обнаруженны х на каждом из этапо в жизнен­
ног о цикл а разработк и , можн о оц ен ит ь и отобразит ь э ф ф е кт и в н о с т ь усовершенство­
вани й процесс а п о мер е и х внесени я о т проект а к проекту.
 Глава 11. Разработк а и использовани е показателе й тестировани я 257

Проектно-ориентированная модель ошибок

Отдельные язык и программирован и я могут быт ь боле е чувствительн ы к некоторы м
типам ошибок , че м другие. Н а п ри м е р , какой-либо яз ы к программирован и я може т
генерироват ь код, к от ор ы й особенн о трудно сопр ов ожд а т ь ил и повторн о использо­
вать в других программах . Код , генерируемы й другим язык о м , може т оказатьс я боле е
пригодным для сопровождени я ил и повторног о использовани я , н о може т характер и ­
зоваться боле е низко й производительностью . Оди н и з способо в определен и я чувст­
вительности проект а к различны м типа м ошибо к предполагае т создани е модел и
ошибок для данног о проекта . Пр о е к т ы , в которы х используетс я оди н и то т же язы к
программировани я , могут сравниваться , тольк о есл и в ни х используетс я та же самая
модель ошибок . Если п р и сравнени и с моделью ошибо к выясняется , чт о в данно м
проекте вер оятно ст ь в оз н и к н о в ен и я конкр етног о тип а ошибо к высока, эт о може т
служить призн ак о м налич и я систематическо й проблем ы в метод е разработ к и про­
граммного обеспечения . Ина ч е говоря , анали з данны х ошибо к скоре е ведет к обна­
ружению просчет о в в процесс е разработки , а не в самом продукте.
Пе ре чен ь известны х ист о чни ко в ошибо к приведе н в таблиц е 11.6. Ошибк и могут
быть разделен ы по категори я м в ходе процесс а пересмотров , когда комисси я прихо­
дит к согласию относител ь н о категори и основн о й п р и ч и н ы проблемы . На п р и м е р ,
если основна я п р и чи н а относит с я к категори и ошибо к прослеживаемост и (TR) , ко­
миссия п о пересмотр у определяе т эта п ж изн ен ног о цикл а проекта , н а которо м эт а
ошибка была внесен а ( н ап рим е р , эта п эскизног о п рое к т и рова н и я (ЭП )) . Эт и катего­
рии могут быт ь предста вл е н ы графическ и и п роа нал и зи ров а н ы , как показ ан о на
258 Част ь II. Технологи и бы строг о тестировани я и совет ы

рис.11.9 . Гистограмма , полученн а я в результат е анализа , будет х а р а к т е р н о й для дан­

ног о язык а программирован и я и дл я данног о жизнен ног о цикл а програм мно г о обес­
печ ен и я .

Еще одн о преимуществ о анализ а данны х ошибо к состои т в возможност и автома-

тическог о сравнени е следующего проект а с предыдущим. Эт о веде т к двум важным
последствиям : во-первых, в ход е пересмотро в внима ни е можн о с оср едоточ и т ь н а о б
наружени и наиболе е вероятн ы х ошибо к и, во-вторых, можн о имет ь представлени е о
том , оказывае т л и не кот ор о е из м ен е ни е в процесс е желаемо е влияни е н а снижение
веро ятнос т и определенно г о тип а ошибок .
Вообщ е говоря , анали з ос новны х п ри чи н возник но в ен и я ошибок , подобны й вы­
полненном у пр и определени и модел и ошибо к проекта , являетс я мощны м средством
совершенствован и я процесса . Ид е н т и ф и к а ц и я пробле м в процесс е разработки , их
устранен и е и оценк а э ф ф е к т и в н о с т и процесс а устранени я представля ю т собо й ос­
н ов н ы е цел и создани я прог рам м ы для выбор а жестки х по к аза те л е й тестиров ани я .
 Глава 11. Разработк а и использовани е показателе й тестировани я 259

Программа оценки ошибок программного

обеспечения (SWEEP)
Программа оц е н к и ошибочност и программн о г о об е сп е ч ен и я (Software Erro r Estima­
tion Program , SWEEP), разработанн а я консорциумо м Software Productivity Cons or tium ,
является средство м пр огн ози р ов ан и я для расчет а коэ ффи ц и е н т о в ошибок , в то м
числе и с кр ы ты х . Скрыто й ошибко й считаетс я люба я ошибка , остающаяс я в про­
граммном продукте, т.е. така я ошибка , котора я существует, но еще не обнаружена .
Ценность модел и SWEEP состои т в том , чт о он а упрощае т управлени е и прогнозиро ­
вание ошибо к в система х с интенсивн ы м использование м программног о обеспече ­
ния. Эт а модель поддержива е т определен и е целе й обнаружени я ошибо к в о врем я
разработк и программног о обеспечени я и помогае т отс лежива т ь продвижен и е по пу­
т и реализац и и эти х целей . З а сче т пр огн ози р о ва н и я количеств а ошибок , остающ ихс я
в программн о й системе , SWEEP осуществляет м о н ит о р и н г и помогае т контрол иро ­
вать качеств о программны х продуктов. Ни ж е приведе н пере чен ь допущений , лежа­
щих в основ е модели :
• Все обнаруженны е ошибк и должн ы быт ь записан ы в момен т их обнаружения .
• Ошибк и исправляютс я посл е их обнаружения , и во врем я устранени я обнару­
ж енн ы х ошибо к н е вносятс я новы е ошибки .
• Трассир овк а ошибо к должн а выполнятьс я единооб раз н о в течени е всех этапо в
жизн ен н ог о цикла.
260 Част ь П . Технологи и быстрог о тестировани я и совет ы

• Ошибк и в документац и и должн ы отслеживать с я отдельн о от программных

ошибок .
• Входны е данны е прог р ам м ы SWEEP должн ы регулярн о п р о в е р я т ь с я и обнов­
ляться .
• Т о ч н о с т ь результато в в ып ол не н и я програм м ы SWEEP будет повышатьс я про­
порци онал ьн о вводу фак т иче с ки х количест в ошибок , полученны х на других
этапа х процесс а разработк и .
О п р е д е л е н и я тре х р е ж и м о в использовани я програм м ы SWEEP приведен ы в таб­
л и ц е 11.7.

Тестировщика м прог ра м м но г о об е сп е че н и я SWEEP предлагае т п он ят н о е графи­

ческо е представлен и е обна руж енн ы х ошибо к и прогноз а оставшихс я ошибок . Кроме
того , он а дае т возможн ос т ь пользовател я м выполнят ь сравнени е с ране е полученны­
м и данными , чт о делае т р е ал ьн о й точну ю оценку состав а скрыт ы х ошибо к н а различ­
ны х этапа х ж изн енн ог о цикла . Руководител ю подразделени я обеспечени я качества
программ а SWEEP позволяе т то ч н о прогнозироват ь количест в о цикло в тестирова­
ни я , которы е потребуютс я для удовлетворени я требовани й заданног о стандарта ка­
чества . Пр и м е р модел и SWEEP, в к от о р о й используетс я при в яз к а к этапам , приведен
на рис . 11.10. О бр а т и т е вн им ани е , ч т о в данно м проект е тольк о ч т о завершилас ь ин­
спе кц и я начальног о исходног о кода н а предме т его соответств и я ра боч е й проектной
документации , в ходе к от о р о й бы л о обнаружен о 3,48 ошибо к на тысяч у стро к кода.
Наибольш е е совпадени е р элеев ско й криво й распределени я ошибо к с фактическими
данным и наблюдаетс я для момент а получени я самы х последни х данных , и ему соот­
ветствует зна чени е , равн о е 3,48. Зн а ч е н и я 3,3 и 7,8, полученные , соответственн о она
этапа х эскизног о и ра боч ег о пр о ект и ро в ан и я , проходя т ч ер е з эт о ж е зна чени е 3,48. В
соответстви и с это й рэлеевско й крив о й распределени я на следующем этап е тестиро­
вани я блоко в следует ожида т ь обнаружени я окол о 2,12 ошибо к на тысяч у строк ис­
ходног о кода. В случае сохранен и я то й же тенденц и и в момен т поставк и клиенту про­
граммны й продукт долже н содер жат ь мене е 0,07 ошибо к н а тысячу с тр о к кода.
 Глава 11. Разработк а и использовани е показателе й тестировани я 261

Следующим логиче ск и м шагом процесс а был о б ы усреднени е для большог о числ а

проекто в фа ктич е с к и х данны х о колич ест в е ошиб ок , приходящихс я н а тысяч у стро к
кода, к от о р ы е обнаружен ы н а каждом и з этапо в (ЭП , РП , ТКМ , К И и С И ) . В следую­
щем п рое кт е должн а иметьс я возможно с т ь использовани я эти х данных , обозначен ­
ных на рис . 11.11 как "Номинальн ы е значения" , в качест в е мер ы коли чест в а ошибок ,
обнаружени е к оторы х следует ожидат ь пр и вып олне н и и проект а с таки м ж е уровне м
качества, ил и даж е мер ы прек ращени я дальнейшег о т е с т и р о в а н и я в о имя повы шени я
производительност и инспе кций . Верхни й и н и ж н и й предел ы уровня контрол я каче­
ства могут быт ь установлены , нап ри м ер , равным и тр е м сигма о т номинальн ы х значе­
ний данных .
Рэлеевска я функц и я распределени я ошибо к представляе т собо й важны й инстру­
мент в арсенал е инж ен ер а системног о тестиров ани я . Н а этап е системног о тестиро ­
вания все существующие случаи тестирован и я примен яют с я методичн о ден ь з а днем ,
в ходе выполнени я тестир ован и я новы х подсисте м и регрессивног о тес ти р о в ан и я
новых сборок , в которы х устранен ы ошибки , обнаруженны е в предыдущих сборках .
На рис . 11.12 показан ы факти чес ки е данны е ошибо к , собранн ы е в ходе вып о лн ен и я
ряда системны х испытан и й кандидато в н а рол ь выпусков. Пр и это м сборк и выполня ­
лись еженедельн о , а обнаруженны е ошибк и наноси ли с ь на столбчатую диаграмму
ежедневн о . В ы ч е р ч и в а н и е огибающ е й был о в ып олн е н о а вто м ати ч е с к и п р и помощ и
модели с использование м привяз к и ко врем ен и программ ы SWEEP. О бр а т и т е внима­
ние, чт о есл и заран е е был о определен о допустимо е количеств о ошибо к н а тысяч у
строк кода, к от о р о е може т быт ь поставлен о клиенту, тестировщи к и могут смел о ис­
пользовать эту диаграмму для определен и я услови й пр ек р а ще н и я этап а системны х
испытани й .
262 Част ь II . Технологии быстрого тестирования и совет ы
 Глава 11. Разработка и использовани е показателе й тестировани я 263

Резюме
Проблем ы и их решени я , выбранны е для исследован и я в это й главе, связан ы с при­
менение м программн ы х п о ка зат е л е й к в ыполнени ю т е с т и р о в а н и я как с учето м инте ­
ресов данног о проекта , та к и с учето м инт е ре с а все й организаци и в целом . Н и ж е
приведен к ратки й п е р е ч е н ь вопрос ов , рассмотренн ы х в главе:
• Различи я между показателям и и данным и измерени й .
• Двухуровневый подход к сбору и анализу данны х изме рени й .
• П ол е з н ы е общеорганизационн ы е показатели , а именно : показател и объема ,
трудоемкости , календарног о гра фик а и качества .
• П р и н ц и п выбор а показ ателе й уровн я проекта , названны й п ри нц и п о м "цель-
вопрос-показатель " (ЦВП) .
• Использован и е показат еле й для управлен и я и совер шенств ован и я процесс а
р а з р а б о т к и программн о г о обеспечени я .
• П е реч е н ь показател е й т е с т и р о в а н и я (относящихс я к о второму уровню) .
• Разработ к а модел и ошибок , к от о р а я може т применятьс я пр и от с л е ж и в а н и и
процесс а и повышен и и качества .
• О п р е д е л е н и е к онечн о й цел и т ести ровани я , а именно : п ри ме не н и е прогноз и ­
ров ани я плотност и ошибок , использовани е програ м м ы SWEEP и д о с т и ж е н и е
конечног о качества , т.е. количест в а скрыты х ошибок , приходящегос я н а тыся­
ч у стро к кода, которы е поставляют с я конечном у пользовател ю .
Во многи х успешных проекта х показате л и используются для п ов ыш ен и я нагляд­
ности и ко нт р ол еп р иг од н ос т и календа рно г о графика , ха ра ктер ист и к качест в а и
стоимости . Л и ш ь в отдельны х неудачных проекта х примен ен и е показател е й приво ­
дило к разру шен и ю до ве ри тельн ы х от ноше ни й , стол ь необходимы х во врем я разра­
ботки программн ог о обеспечения . О сн овн о й п ри ч и н о й возн и кн ове н и я сбое в в про­
граммах определен и я показателе й проект а практиче с к и всегда являетс я "поис к ви­
новных". Поис к виновн ы х в ошибк е (будь то отдельны й исполнител ь ил и группа лиц ,
принимавши х участие в разработке ) вовсе не являетс я целью п р и м е не н и я показате­
лей. О н и предназначен ы исключительн о для э ф ф е к т и в н о г о управлени я разра б отк о й
программног о обеспечени я и качество м продукта.
 Технологии оценки
трудозатрат на
тестирование
и советы
•

Темы, рассматриваемые в главе:

• П р и м е н е н и е м а т е м а т и ч е с к и х м е т о д о в дл я о ц е н к и
программного обеспечения
• Техн ологи я функц и он альн ых баллов
• Резюме

Цель ю настояще й главы являет с я описани е то чног о метод а прогн оз и ров ан и я кадро­
вог о об е сп е ч ен и я по месяца м для подготовк и т е с т и р о в а н и я и прогон а тестов , кото­
ро е обычн о называетс я в е р и ф и к а ц и е й и аттестацие й (verification a n d validation,
V&V). Выбранны й нам и подход основа н на изучени и последовательност и примеров,
в рамка х которы х используетс я набо р инструментальны х средств , разработанных
авторами .
Существует целы й ря д методо в построен и я гра фи к о в рабо т и календарног о пла­
нир о ва н и я ресурсов для проведен и я тестировани я проекта . Пр о с т е й ш и й метод по­
лучил названи е п р ог н о з и р о в а н и е с использование м модел и с базисо м оцено к (basis of
estimates, BOEs). Оц е н к а п о аналоги и (by-analogy estimate ) основан а н а фактических
данны х о распределени и ресурсов на некоторо м множеств е прошлы х проекто в ана­
логичн о й архитектур ы , с одним и и тем и же языкам и программирован и я и аналогич­
ным и подходами к тести ро вани ю . Оце н к и будущего проекта , есл и в их основу поло­
жен ы оц ен к и по аналогии , строят с я на правдоподоби и за сче т использован и я эмпи­
рически х фа кт о в с инкре ментальн ы м совершенствованием , к от о р ы е основаны на
объединен и и р е ш е н и й мелког о масштаба. Инк р ем ент ал ьн о е совершенствовани е уве­
личивае т точност ь пр огн о зир о ва ни я . В числ о предлагаемы х приме ро в входит клас­
сифи каци я программны х продукто в по их размера м и оцен к а ресурсов групп под­
де р ж ки , напри ме р , группы обе сп е ч ен и я качества , группы управлен и я конфигурацией
и руководств о р аз р а б о т к о й программ ы .
 Глава 12. Технологии оценки трудозатрат на тест ир ова н и е и совет ы 265

ПРИМЕР 1. П О Д Х О Д К ОЦЕНК Е (ГЭРИ КОББ)

Одним прекрасны м утр о м я получил по электронной почте письмо, которо е начиналось
! та к : " М о ж е т е ли вы предложить какие-либо методы оценки объемов трудозатрат и не-
'»обходимых ресурсо в для проведения работ по тестированию программ но г о обеспече­
ния, а такж е для расчета графика этик работ?" Далее в письме говорилось: "Наша груп ­ па
разработала таблицу результатов, в кот о р у ю сводятся результаты измерений харак­
теристик нашего процесса и прогноз ы относительно текущег о состояния проекта в це ­
лом , в зависимости от которых ем у присваивается "красн ое" , "же лто е " или "зеленое "
состояние . Чтобы осуществить это мероприятие, мы назначили некоторы м из наших
I групп статус ведущих, в то время как Другие получили такие названия, как , например ,
консультант PCQA (Product Certification and Quality Assessment •— сертификация и управ­
ление качеством программн ог о продукта) . Принимая во внимание состояние наших по­
следних разработок , м о ж е т е ли вы предложить какой-то способ оценки объемо в тру ­
дозатрат и ресурсов , необходимых для проведения работ по тестированию прогр а м м ­
ного обеспечения, а такж е для расчета графика этих работ?"
В ответ я направил следующее предложение : мето д оценки качества програм мн о г о
обеспечения, который , по м о е м у мнению , м о ж н о будет внедрить в вашем подразделе-
нии, принимает следующий вид (з а цель принимается уровень качества):
1. Разбейте весь персонал разработчиков по исполняемым ка жд ы м сотруднико м ролям
'. (т.е . специалисты по формулированию технических требований, архитекторы программ ­
ного обеспечения, разработчики, кодировщики, тестировщики, руководитель разработ­
ки , персонал, управляющий конфигурацией средств тестирования, персонал, выполняю-
щий сертификацию программного продукта, группа контроля качества и другие).
2. Воспроизведите полный рабочий график двух последних успешно завершенных про ­
е кт о в / н а пр им е р , поставленных заказчику в установленные ср оки , бе з перерасхода
сметной стоимости и приемлемого качества, и распределите временной ресур с и
финансовую смет у по ролям , определенным в пункте 1.
3. Вычислите величину показателя LOE (Level Of Effort — уровень трудозатрат) для ка ­
ж д о й р о ли , т.е . LOE(j) для ка ж д о г о j = 1,...,n, гд е n есть число ролей , выраженно е
через временной эквивалент FTE (Full-Time-Equivalent — эквивалент полного рабочег о
дня) в человеко-месяцах.
4. Вычислите с ум м у S в человеко-месяцах для ка ж д о г о из этих показателей LOE по ка ­
ж д о м у проекту . Подсчитайте, какая доля в процентном отношении от общих трудо ­
затрат приходится на ка жду ю таку ю роль, например , ка к LOE(j)/S, для j = 1,...,n в
рамка х ка ж д о г о проекта, и сравните об е таблицы процентных отношений.
5. Вычислите среднее значение LOE(j)/S, для j = 1, ,n для обоих проектов , чтобы ка ­
либровать модель значений LOE(j), предназначенную для прогнозирования значений
LOE(j) для новых проектов .
6. Оцените раз ме р програ ммног о продукта в тысячах строк KESLOC (Estimated Source
Lines Of Codes — предполагаемое количество стро к исходного кода) для каж д о г о
проекта . KESLOC м о ж н о получить путе м прямог о подсчета стро к исполняемого к о ­
да, отличных от комментариев, включая строк и всех сценариев, которы е не являются
частью продукта , но были разработаны для вспомогательных целей. В качестве аль­
тернативы м о ж н о подсчитать все функциональные баллы (рассмотренные далее в
главе) и при помо щ и таблицы перевода Кейперса Дж онс а (Capers Jones), котора я
приводится в таблице 1 2. 1 , получить KESLOC для функциональных баллов.
7. Вычислите коэффициент EAF (Effort Adjustment F a c t o r — коэффициент уточнения
трудозатрат) из уравнения EAF = S/(2.4*(KE5LOC** 1,05)). Отсюда м ож е т быть вы-
ведена формул а перевода размер а продукта в трудозатраты:
S = EAF*2.4*(KESLOC**1,05),
где EAF получена на основании базиса оценок , a KESLOC прогнозируется на основе
задокументированных требований.
266 Часть II. Технологии быстрого тестирования и советы

На мо й первый ответ по электронной почте пришло письмо следующег о содержания: "Я

благодарю вас за то , что вы не пожалели своего времени, чтобы ответить мне , однако
ваш ответ привел меня в е щ е большее замешательство. Вот почем у я так долг о не от­
вечал в а м — я д а ж е не знаю , что больше всего меня озадачило. Предложенный вами
подход хор ош , однако он предполагает, что необходимые данные находятся где-то ря­
д о м . В то же время у нас нет доступа к данным о трудозатратах, а т о , что у нас есть,
особо й ценности не представляет. Единственное, что приходит в голову , так это найти
аналогичный завершенный проек т и воспользоваться фактическим количеством строк
кода в не м как оценко й текущег о проекта . Находите ли вы м о е суждение имеющим
смысл?"
Я отправил по электронной почте второе послание, в котор о м заметил: " Д а , это один из
способов стабилизации вашей оценки , например, с помощь ю базиса оценки программ ­
ного кода предыдущего проекта . Вы такж е м ож ет е собрать меньшие оценк и уровней
LOE для используемого набора ролей и количество исполнителей на каждо й роли, на­
приме р , число руководителей проектов , программистов, тестировщиков различных спе­
циальностей, специалистов по управлению конфигурациями, лиц, ответственных за каче-
ство программног о продукт а , специалистов по подготовке с боро к , по проведению ис-
пытаний, лиц, осуществляющих контроль производством и прочих. Сюда следует вклю­
чить и расширенные группы , такие как группа подготовки документации, группа инст­
рукторов , занимающихся обучением пользователей, группа специалистов, проводящих
пробные испытания, группа экономистов , решающих вопросы ко нъюнктур ы , группа суб­
подрядчиков и т. п . Если вы располагаете такими сведениями, разделите соответствую­
щие значения на обще е число сотрудников, чтобы получить процентное отношение тру­
дозатрат, а затем воспользуйтесь этими данным для нового подсчета трудозатрат. Точ-
ность этих расчетов находится в пределах 30% . М еж д у прочим , 30 % — это , на мой
взгляд, несколько лучше, че м ошибки в 2 или даж е в 4 раза, которы е допускают раз­
работчики програм мног о обеспечения, раздувая сметну ю стоимость и трудозатраты.
Удачи."

Формулы, используемые в этом исследовании, заимствованы из модели СОСОМО,

предложенной Боемом (Boehm). Описанные выше семь шагов используют для полу­
чения коэффициента EAF скорее метод инженерного анализа, а не подход д-ра Бое-
ма, описание которого можно будет найти далее в главе.
При получении оценок возможны просчеты, причина которых кроется в стати­
стических данных за прошлый период:
• В предыдущем и текущем проектах могли использоваться различные языки
программирования, различные этапы жизненного цикла, различные техноло­
гии экспертных оценок и т.д. Из-за несоответствий в упомянутых областях
применение статистических данных может привести к получению неточных
рабочих графиков и оценок затрат.
• Часто трудно противиться желанию вычислять временные затраты и трудоза­
траты, исходя из предположения их линейной зависимости от производитель­
ности, вычисленной для прошлого проекта. Например, в рамках прошлого
проекта была достигнута производительность в размере 1 строки программно­
го кода за один рабочий час на программе в 5 KESLOC, следовательно, для раз­
работки программы, состоящей из 50 KESLOC, при производительности 1
строка программного кода за один рабочий час, потребуется в 10 раз большее
время. Это неверно, поскольку с увеличением размеров программы трудозатра­
ты возрастают по экспоненциальному закону, а не по линейному.
 Глава 12. Технологии оценки трудозатрат на тестирование и советы 267

Вывод, который непосредственно можно получить из этого исследования, заклю­

чается в том, что в условиях мелкомасштабных проектов каждый исполнитель знает
все, что происходит ежедневно, а члены команды поддерживают друг друга, помогая
решать сложные проблемы, разбираться в кодах и отлаживать модули. Ни у кого не
возникает необходимости в документировании процесса, поэтому никто не задумы­
вается над тем, чтобы упаковать данные измерений. В условиях небольших проектов
каждый член группы вынужден брать на себя ответственность за судьбу всего проек-
268 Част ь II. Технологи и быстрог о тестировани я и сов ет ы

та . Испол нит е л ь в это м конк рет н о м прим ер е ощущает настоятельн у ю необходимость

им ет ь в свое м ра с п оряж е н и и процес с оц е н к и трудозатра т н а т е с т и р о в а н и е для новых
небольши х п р о ект о в . Но в то же само е время , в соста в предыдущи х проект о в не вхо­
дил и процесс ы сбор а данны х для бази с а оценок .
П р и переход е от мелкомасштабн ы х проект о в к крупномасштабны м возникае т на­
стоятельн а я пот р еб н ос т ь ф о р м а л и з о в а т ь обме н данными , отч етност ь , руководящие
действи я , орга низ ац и он н ы е роли , подготовку кадро в и промы шл е нн ы е стандарты.
Другим и словам и , возникае т необходимост ь в оп р ед е ле н и и и использован и и полно­
сть ю документи ров анно г о процесса . В нескольки х следующих главах будут показаны
последовательност и техн о логи чес к и х оп ераци й процесс а р а з р а б о т к и современног о
пр ог р ам мн о г о обеспечени я , п р и это м упо р будет делатьс я н а процес с тестиро ва н и я и
ид ент и фи к ац и ю ег о задач .

Применение математических методов для

оценки программного обеспечения
П р и мод е ли р ов а н и и проц есс а р а з р а б о т к и програ м мно г о о б е с п е ч е н и я необходимо
прин и мат ь в о внимани е т о т факт , чт о различны е модел и ж и з н е н н о г о цикл а разра­
бот к и имею т дел о с современ ны м и моделям и . В некот ор ы х прое кт а х определен ы
те хни ч е с к и е треб овани я , в ыяв ленн ы е н а начально й стади и проект а , и он и остаются
неизменны м и н а п рот яж ен и и всех этапо в разработк и . М иним альн ы х затр а т требует
каскадны й процес с р а з р а б о т к и программн ог о обеспечения . Каскадн ы й (ил и "водо­
падный" ) процес с показа н на рис . 12.1. Он получил свое назв ани е по аналоги и с по­
токо м самог о процесса , поскольку и н ф ор м а ц и он н ы е поток и в диаграмм е потоков
данны х направлен ы сверху вниз , подобн о струям воды в водопаде . Стрелки , которые
указываю т в об р атн о м н ап рав л ен и и , суть поток и в е р и фи к а ц и и . О н и отвечаю т н а во­
прос ы наподобие : соответствуе т л и исходны й ко д тому, че м о н долже н быт ь согласно
деталь н о й п рое к т н о й документации .
Стади я тестировани я , пок азанн а я н а диаграмм е каскадног о процесса , включает
комплексные , системн ы е и при е мо чн ы е испытани я , в то врем я как стади я реализа­
ции , котора я такж е показан а на диаграмме , содержи т задачи , относя щие с я к тести­
р ов ан и ю модулей. Пере д пер едач е й программног о кода независимы м организациям ,
занимающимс я тестиров ан ие м , разра ботчи к и должн ы выполнит ь тестирован и е про­
граммны х модулей. Пр и р е ш е н и и задач н а стадии тес тирован и я каскадног о процесса
применяют с я технологи и статическог о и динамическог о т е сти р о ва ни я , рассмотрен­
ны е в главах 3, 10 и 11 .
Друго й популярно й модель ю ж и з н ен н о г о цикл а программн ог о обеспечен и я явля­
етс я модель, получивша я н аз в а ни е спиралевидног о процесса , к от о р ы й показа н н а
рис . 12.2. Это т процес с впервы е бы л использова н п р и разработ к е п р от оти п о в с це­
ль ю пов ышени я ст е п е н и д о в е ри я к набору тр е бо в ан и й и о б е с п е ч е н и я возможност и
эк сп ер и ме нти р ов ан и я с человеко-машинны м инте рф е йс ом , структурой баз ы данных,
простото й использовани я , производительность ю и удобством установки . Чтоб ы дать
пользователя м возможност ь поупражнятьс я и получить от ни х отзывы , создаются
инкрементальн ы е сборки . Та к и е сборк и являютс я должн ы обязательн о тестировать­
ся , однак о слишко м час т ы е инкрементальн ы е сборк и иногд а н е позволяю т группе
т е ст и р о в а н и я по лн о ст ь ю за в е р ш и т ь пр о г о н всег о тестовог о набора .
Глава 12. Технологии оценки трудозатрат на тес ти р ова н и е и совет ы 269
270 Част ь II. Технологи и быстрог о тестировани я и совет ы

В силу этог о обстоятельств а , задаче й наивысшег о п р и о р и т е т а ст ан о ви т с я обнару­

ж е н и е д е ф е к т о в в о внов ь до ба в л енн о й функциональност и , н о это , в сво ю очередь,
прив оди т к спешк е в р аз р а б о т к е и реализац и и сове ршенн о нов ы х тестовы х случаев,
тестовы х сценарие в и ожидаем ы х результато в прогон а тестов . Э т о т процес с набира­
ет таки е темп ы , чт о стано вит с я хаоти чн ы м как для р а з р а б о т ч и к о в , та к и для тести-
ровщиков . Если все этап ы раб о т не будут тщательн о выв е ре н ы и распланированы , то
п о п ри ч и н е недостат к а в р е м е н и н и раз ра б от чи к и , н и тестировщи к и н е успеют за­
верши т ь работу и проа нал и зирова т ь е е результаты д о появ лен и я следующе й сборки .
Наилучш е й моделью ж и зне н н о г о цикла р аз ра б от к и пр ог р ам мн о г о обеспечения ,
к от ор о е должн о поступат ь н а р ы н о к с ограниченн ы м наборо м функциональны х воз­
мо ж н ост е й с цель ю м и н и м из а ц и и рисков , явля ет с я спирале видн а я модель . Спирале­
видна я модел ь обеспечив а е т плановы й набо р выпусков, благодар я чему переделка
каких-либо пользовательск и х и н т е рфе й с о в , структур баз данны х ил и повышение
пр ои зв о дит е ль но с т и неоптимальн ы х алгоритм о в може т выполнять с я в боле е позд­
ни х выпусках продукта.
Эт а же модель поддержива е т наилучши й процес с в условиях, когда требования
не ч ет к о сфо рму лиро ва н ы л и б о отсутствуют прототи п ы продукта. Поставк а предва­
р и т е л ь н ы х сборо к будущего п ро гр а мм н о г о продукта уменьшае т рис к неудачи всего
проект а благодар я возм о ж но с т и заручитьс я поддержко й к онечн ы х пользовател е й н а
ра н н и х стадиях р азр а бо тк и . Спиралевидна я модель наилучшим об р аз о м подходи т для
проект о в с изменчивы м и треб ова ниям и , поскольку добавление , удалени е и измене­
ни е т р е б о в а н и й можн о в ст р ои т ь в следующие сборки , паралле ль н о занимая с ь сопро­
вождени е м и раз ра б от к о й нов о й сборки .
Вы, скоре е всего, слышал и част о употребляемы й деви з д о с т и ж е н и я качества : "де­
ла й правильн о с п е р в о й п о п ы т к и " . Если эт о относит с я к текущему тип у проект а про­
граммног о продукта, т о наилучши м решением , требующи м к тому ж е минимальных
затрат , будет каскадная модель . Если пользовате л и не знают , чег о они , в конц е кон­
цов , хотят , или есл и може т случиться так , чт о окончательна я верси я программного
продукт а когда-то в отд а л ен н о м будущем не удовлетвори т ожидани я заказчика , то
наилучшим подходом к р е ш е н и ю эт о й задачи , к от о р ы й минимизируе т рис к неудачи,
будет спиралевидна я модель.
В р ан е е рассмотренн о м ж и з н е н н о м цикл е разработ к и програм мног о обеспечени я
возможн ы изм ен ени я , обусловленны е необходимость ю привл ече н и я внешни х ресур­
сов субподрядчико в на п р о е к т и р о в а н и е , кодировани е и те ст и ро в ан и е модулей. На
рис . 12.3 показан а диаграмм а шарнирно-каскадно й модели, котора я демонстрирует
распределени е ответственнос т и в соотв етств и и с пр ом ы ш ле нн ы м и стандарта м и ме­
жду генеральны м подрядчико м и субп о др я д чи ка ми /п а ртн е ра м и .
И з приведенны х приме ро в , иллюстрирующи х шир ок о е многообраз и е моделей
ж и зн е н н о г о цикла разраб отки , можн о сделать вывод, чт о требо вани я , предъявляе­
мы е к стоимостн о й модели , должн ы быт ь разбит ы н а блоки . Модел ь должн а быть
дос та точ н о гибкой, чтоб ы делит ь сметную стоимост ь рабо т на стоимост ь работ, вы­
полняемы х генеральны м подрядчиком , и стоимост ь работ , выполняем ы х субподряд­
чиком , рав н о как и в меру гибкой , чтоб ы выделит ь трудозатра т ы на тестирование ,
нап р им ер , и з за тра т н а управлени е разработко й и сопровождени е м програм м или и з
за тра т на кодирование . Эт о приводи т к проекту, кот оры й рассматриваетс я далее на
прим ер е изучени я последовательност и конкретн ы х случаев.
 Глава 12. Технологии оценки трудозатрат на тестирование и советы 271

В [6] на примере 63 успешно выполненных проектов по разработке программного

обеспечения выделяется три группы проектов, а именно: организованные, полуорга­
низованные и встроенные. Тем же, в [6], были разработаны три модели вычисления
сметной стоимости: базовая, промежуточная и рабочая. В группу организованных
проектов попадают те из них, в рамках которых работают небольшие группы, выпол­
няющие хорошо известную им работу, такую как, например, добавление сообщений в
программе на языке COBOL. В группу встроенных проектов попадают проекты, в
разработке которых участвовали группы с большим числом исполнителей и рисками,
связанными с недостаточной осведомленностью в области программирования, не­
достаточными знаниями условий испытаний, нестабильностью требований, сокра­
щенным графиком работ, отсутствием необходимых инструментальных средств, же­
сткими ограничениями по производительности и качеству. Группу полорганизован-
ных проектов образуют проекты, которые находятся где-то посередине между груп­
пами встроенных и организованных проектов. На рис. 12.4, который представляет
сводку уравнений модели СОСОМО (Constructive Cost Model — конструктивная стои­
мостная модель), предложенную Барри Боемом (Barry Boehm), эти три группы назы­
ваются режимами.
Для того чтобы упростить понимание различий между уравнениями организован­
ных, полуорганизованных и встроенных режимов, на рис. 12.5 показаны графиче­
ские диаграммы этих трех уравнений в тысячах строк KELOC (Equivalent Lines Of
Code— эквивалентные строки кода). Диаграммы выглядят несколько запутанно, по­
скольку из них следует, что чем выше риск, связанный с программой, тем быстрее
она завершится. По всей видимости, это можно объяснить тем, что руководство под­
бирает специалистов по разработке с таким расчетом, чтобы этот персонал смог ус-
272 Част ь II. Технологи и быстрог о тестировани я и совет ы

пешн о вып о лн я т ь п р о е к т ы с высоки м и рискам и либ о в условиях недостаточности

ресурсов .
 Глава 12. Технологи и оценк и трудозатра т н а т е с ти р ов а н и е и сов ет ы 273

В промежуточны х и д е т а л из и р о в а н н ы х моделя х С О С О М О п ри м е н яет с я коэффи ­

циен т EAF (Effort Adjustmen t Fac t or — к о э ф ф и ц и е н т уточнен и я трудозатрат) , пред­
ставля ющ и й собо й произведен и е т а б л и ч н ы х з нач е ни й д ра й в е ро в с т о и м о ст и про­
граммног о обеспечения , сведенны х в таблиц у 12.2.
В базо в о й модел и С О С О М О к о э ф ф и ц и е н т EAF (Effort Adjustmen t F a c t o r — коэф ­
ф и ци е н т уточн ен и я трудозатрат ) н е используется . Единственно е различ и е между
промежуточно й и детализированн о й моделям и С О С О М О заключаетс я в том , чт о в
промежуточно й модел и С О С О М О н а всех стади я х применяет с я оди н и т о т ж е коэф ­
ф и ци е н т EAF, в то врем я как в д ет а л и з и р о в а н н о й модели С О С О М О п е р е м н о ж а ю т с я
различн ы е драйв ер ы стоимост и . В результат е для каждо й стади и получаетс я сво й
к о э ф ф и ц и е н т EAF, кот ор ы й приме няет с я н а соответствующе м этап е вычислен и я
трудозатрат . Единственно е различ и е между моделью С О С О М О и модель ю REVIC
(Revised a n d Improve d С О С О М О — пе ре см отренн а я и улучшенная модел ь С О С О М О )
связан о с тем , каки е к о э ф ф и ц и е н т ы и э к сп он е н т ы присутствуют в уравнения х для
вычислени я количест в а человеко-месяце в (MM A d j ) и времен и р аз р а б о т к и (TDEV).
На рис . 12.6 значени е TDEV откладывает с я на временно й ос и график а ; в рассмат­
риваем о м случае площадь, ограниченн а я 18 месяцам и и криво й , представля ющ е й
изменен и я значени й трудозатра т (MM A d i ) , ест ь суммарное количе ст в о персонал а з а 1 8
месяцев . Главн ы й д рай ве р стоимост и модел и C O C O M O / R E V I C — э т о чи с л о KLO C
(Lines O f Co d e — тысяч и стро к программн о г о кода) , изображ енн о е в центр е диаграм­
мы на рис . 12.6 в ф о р м е о твер ст и я монет опри емни к а . О ст ал ьн ы е д р ай в е р ы стоимо­
сти показан ы в виде циф е рб л ат о в , ст р ел к и к от ор ог о указываю т н а и з б ра н н ы й атри­
бут др ай в ер а стоимости . В это м случае к о э ф ф и ц и е н т EAF ест ь произведе н и е значе­
ний , связанны х (чере з поискову ю таблицу ) с каждой установко й ц и ф е р б л а т а . Подоб­
ное изображени е , вып олн енн о е в духе г р а ф и ч е с к о г о пользовательског о и н т е рфе й с а ,
упрощае т разработчи к у модел и пон и м а н и е последовательност и с о б ыт и й этог о про­
цесса. Во-первых, необходим о установит ь показани я циф е рб л ат о в , зате м опустит ь
число KLO C в отверст и е м он ет опри ем ни к а , запустит ь модель в работу и на выход е
получить готово е произведение . Г ра фи к выч ер чи ва е т з н аче н и я человеко-месяцев ,
при это м площадь под криво й представляе т собо й общи е трудозатраты , ко то р ы е по­
требуются н а реализаци ю всех видов деятельност и , которы е необходи м о выполни т ь
пр и разработ к е программног о продукта. Врем я на разработк у (TDEV) откладываетс я
п о горизонтальн о й ос и графика . Это т процес с повторяет с я для различны х дра йв ер о в
стоимости , достаточн о ввест и соответств ующ и й дра йв е р либ о ввест и нов ы е значе­
ни я размеро в и запустить модель.
Следует отметить , чт о существует пряма я связ ь между трудозатрата м и (MM A d j ) и
временем , затрачиваемы м н а разработк у (TDEV), котора я проявляетс я в том , чт о пр и
уменьшени и KLO C снижаютс я и трудозатраты , которые , в свою очер ед ь , приводя т к
уменьшению времен и до поставки . И наоборот , если составител ь модел и узнает, чт о
работу на д проекто м прек ращае т специалис т п о ключевы м систем а м проект а , кото­
ры й разрабатывае т архитектуру и сам программн ы й проект , необходим о скорректи ­
роват ь по каза ни я цифе рбл ат о в АСАР и АЕХР, вследствие чег о тр удозатрат ы (MM A d j )
могут возрасти , что , в сво ю очередь , приведе т к увеличени ю времен и на разработк у
(TDEV). И , наконец , если для вычислени й используется средня я стоимост ь едини ц ы
персонала , занимающего с я р а з р а б о т к о й , т о эт а стоимост ь находитс я в л и н е й н о й за­
висимост и о т вычисленны х трудозатрат .
274 Част ь II . Технологии быстрого тестирования и совет ы
 Глава 12. Технологи и оценк и трудозатра т н а т е с т и р о в а н и е и совет ы 275

Ка к отмечалос ь ра не е , одн о и з треб о ва ни й , предъявл яем ы х к модел и сметн о й

стоимост и прогр аммн о г о обеспечени я , обусловливае т е е модульность. Составите л ь
тако й модели , п о меньше й мере , долже н имет ь возможност ь делат ь разрез ы трудоза­
трат ы п о стадия м разработки , п о роля м раз р аб от чи к о в и п о сборкам . Н а рис . 12.7
приводитс я уравнени е рэлеевско й кривой , а такж е трудозатра т ы (количеств о персо­
нала) п о месяцам , описываем ы е криво й кадровог о обеспечени я . Эта крива я обладае т
дополнительны м свойством , которо е заключаетс я в том , чт о он а разбит а н а ти по в ы е
стадии разраб отки : R E Q (документировани е т ре б ов а ний ) , P D (эскизно е проектиро ­
вание) , D D (рабоче е п р о е к ти р о в а н и е ) , C U T (тестиро ван и е кода и модулей), I T (ком­
плексны е и системн ы е испыт ани я) . Вычислени е сметно й стоимост и проект а невоз­
можно , пок а не будет завершен а стади я REQ , поэтом у в соответств и и с соглашение м
о разметк е ос и абсцисс , первы й меся ц стадии PD помечаетс я 1, в то врем я как метка­
ми двух месяцев , предшествующих стадии PD , когда выполняетс я REQ , будут 0 и -1.
В случае спиралевидны х процессо в разработ к и на стади и R E Q должн ы выполнятьс я
общие требовани я для всех сборок , таки м образом , несло жн о обнаружить , чт о стади я
R E Q отделен а о т стади и P D н а н е к от о р ы й пе рио д задержки .
TDEV, время , затрачиваемо е на разработку, и ММ, человеко-месяцы, вычисляютс я
п о формулам , приведенн ы м н а рис . 12.6. Staffing(t) представляе т собо й количест в о
персонала ; з н а ч е н и е этог о показател я указываетс я н а рис . 12.7 для каждог о месяца ,
при это м t изменяет с я от -1 до 19.
276 Част ь II. Технологи и бы ст рог о тестировани я и совет ы

И хот я модел ь С О С О М О н е предназначен а для получения за тр а т н а эксплуатацию

для унаследованны х систем , вариант , показанны й на рис . 12.8, обеспечива е т доста­
т оч н о т оч н ы е результаты . За т ра т ы н а эксплуатаци ю MM M a i n l в течени е т ре х ле т после
выпуска унаследованно й систем ы могут быт ь подсчитан ы н а основ е интенсивнос т и
годичны х изменений , кот ора я согласн о эмпирическ ом у правилу, составляе т в сред­
нем , соответственн о , 15% , 10% и 5% от трудозатра т на создани е унаследованно й сис­
темы . П ри м е р , представленны й на р ис . 12.8, построе н для программ ы объе м о м в 50
KLOC , на разработк у кот о ро й потребовалос ь 362 человеко-месяца, пр и это м в тече­
ни е перв ы х 12 месяце в 4,525 человек а был и занят ы поддержко й унаследованно й сис­
темы . Т а к о й подход можн о п р и м е н и т ь в случае, когда подрядчи к получает но в ы й про­
граммн ы й COTS-продукт (commercial-off-the-shelf, доступный в продаже ) таког о же
объем а (50 KLOC) .
Пр ед по л о жи м , чт о подрядчи к настаивае т н а добавлени и новы х функциональн ы х
свойст в в COTS-продукт, на осуществлени е которог о потребуетс я не мене е двух лет.
Это т подрядчи к долже н требоват ь новы х разработ о к объемом X KLOC , интегриро­
ванны х в сборку размеро м X + 50 KLOC , и добавит ь к соответствующи м трудозатра­
та м 4,525 человеко-месяца на п е р в ы й год и 3,017 человеко-месяца на втор о й год к
тр удозатрата м на эксплуатаци ю COTS-продукта. Име я средню ю оплату $55 за челове­
ко-час, ил и $8305 за человеко-месяц, п ри мит е , чт о оди н меся ц состои т из 151 оплачи­
ваемог о часа. Стоимост ь трудозатра т за два года состави т в это м случае $8305 * 7,542 =
$62636. Обрати т е внимани е на то обстоятельство , чт о в данно м случае ни чег о не ска­
зан о п о поводу того , чт о каки е средств а был и потра чен ы н а унаследованны й COTS-
продукт ег о поставщиком , поскольку зн а че н и е 362 человеко-месяца был о вычислен о
н а ос н ов а н и и к о э ф ф и ц и е н т а EAF ваше й компании , которы й определялс я с учетом
ос об е н н ос т е й процесс а р азраб от к и программног о обеспечен и я внутр и компании .
 Глава 12. Технологии оценки трудозатрат на тестирование и советы 277

Предположим, стало известно, что конкуренту вашей компании потребовалось

четыре года, чтобы завершить COTS-продукт объемом в 50 KLOC. В соответствие с
контрактом, который заключила ваша компания, этот продукт является основой для
внесения усовершенствований. Несут ли эти сведения информацию, которая могла
бы укрепить ваши позиции в конкурентной борьбе? Имея в своем распоряжении
уравнения математической модели, можно восстановить значение
(MMAdj) из уравнения для TDEV. Далее, имея значение (ММAdj) и учитывая то, что
объем COTS-продукта равен 50 KLOC, единственной неизвестной величиной в урав­
нении для (MM Adj) остается коэффициент EAF. Зная величину коэффициент EAF для
COTS-продукта у конкурента, можно определить его затраты на выполнение следую­
щего проекта, скажем, объемом в 75 KLOC. Постоянно совершенствуя драйверы
стоимости, которые используются для вычисления значений коэффициент EAF, ваша
компания сможет победить в конкурентной борьбе, создавая программные продукты
за более низкую цену. Последовательно управляя математической моделью, ваша
компания в конечном итоге с полным правом сможет сказать: "Мы можем поставлять
программный продукт в более сжатые сроки и за меньшую цену".
278 Част ь II . Технологии быстрого тестирования и советы

ПРИМЕР 2. ПОСТРОЕНИЕ М О Д Е Л И COCOREV (ГЭРИ КОББ )

Математическое моделирование жизненног о цикла программног о обеспечения всегда
вызывало у меня повышенный интерес. Следствием такой заинтересованности стали
краткий о бз о р различных случаев использования моделей составления смет , которые
мне удалось обнаружить, и исследование гибкости этих моделей. С само г о начала я от -
дал предпочтение структур е электронной таблицы, поскольку она обладала модульно­
стью и графическим интерфейсом, необходимыми для достижения поставленных целей.
Я принял решение написать для наиболее сложных случаев программ у детализированной
модели С О С О М О , в которо й на каждо й стадии применяются собственные коэффициен­
ты EAF. В модели COCOREV используются параметризованные коэффициенты и экспо­
ненты для вычисления значений (ММAdj) И TDEV, благодаря чему одна и та же электрон-
ная таблица применяется для решения уравнений модели REVIC. Мы решили назвать эту
модель, в основу которо й положена электронная таблица, табличной моделью
COCOREV. Модель COCOREV предоставит примеры использования математической
модели для составления сметы затрат на разработку программног о обеспечения. В рав­
ной степени найдут применение и уравнения для полуорганизованных проектов (режи м
2) полученные Барри Б о е м ом , а в промежуто чно й модели вычисления сметной стоимо­
сти принимается, что для всех стадий разработки используется одно и то же значение
коэффициента EAF, равное 0,5.
В рассматриваемом конкрет н о м пример е м о ж н о выделить три части:
• Спиралевидный жизненный цикл с пятью сборкам и о б ъе мо м 15 KLOC , которы е ин­
тегрируются в программны й к о д существующе й системы и создаются последова­
тельно.
• Каскадный жизненный цикл с одной сборкой объемо м 75 KLOC, создаваемой один раз.
• Многоярусный спиральный жизненный цикл с пятью сборкам и о б ъе м о м 15 KLOC, ко ­
торые интегрируются в программны й к о д существующе й системы, при это м спирали
создаются кажды е два месяца.
С итоговыми результатами этого анализа, проводимого с целью выбора компромиссно -
го решения, м о ж н о будет познакомиться после тог о , как будут представлены данные
третьей части. На рис. 12.9 показаны допущения, принятые для первой части примера .
Модель COCOREV представляет собой рабочий журнал , содержащий некоторо е мно­
жество рабочих страниц. Главная страница, именуемая Титульным листом , содержи т все
входные данные модели и сводку всех выходных результатов пяти страниц, на которых
уравнения модели COCOREV применяются к индивидуальным сборка м , помеченным как
Сборк а 1, Сборка 2, Сборка 3, Сборк а 4 и Сборка 5. Еще одна рабочая страница, по­
меченная ка к Таблицы, содержи т фиксированные константы рассматриваемой модели.

Пример - Часть 1
• Допущения
- 5 сборок
- 1 5 KDSI каждая
- Каждая сборка интегрируется с промежуточными результатами предыдущих
сборок
- Для реализации каждой сборки используется язы к программирования C++
- В рамках одной сборки подробно рассматриваются:
• Планирование тестирования
• Верификация и аттестация

Рис.12.9. Список допущений для части 1 примера

•',
 Глава 12. Технологии оценки трудозатрат на тестирован и е и совет ы 279

На рис. 12.10 показан блок входных данных Титульного листа, подробн о описывающий
к а ж д у ю из сборо к о б ъе м о м в 15 KELOC. Сборк а интегрируется сама с собой или с
предыдущими унаследованными сборкам и и реализуется на языке C + + со значением
коэффициента EAF, равным 0,5, для всех стадий разработки . Мы выбираем р е ж и м 2,
кот о р ом у соответствует полуорганизованная модель С О С О М О . Столбец KDSI (thou ­
sands of delivered instructions — тысячи поставленных инструкций) Титульного листа за­
полняется значениями, которы е начинаются со сборк и о б ъе м о м в 15 KDSI и с каждо й
строко й возрастают на 15 KDSI. Задержк а начала работ в начале равна 0, а затем воз­
растает на 10 месяцев с каждо й сбо р ко й . Это делается для тог о , чтобы показать, что на
разработку каждо й сбо р к и будет затрачиваться не более 10 месяцев.

Рис. 12.11 является частью комплексног о вывода на Титульном листе модели COCOREV.
Поскольку с началом работ над сбор к о й 1 задержк и не было, они начинаются на меся­
це 1, в то время как работы над сборк о й 2 были начаты с задержко й на 10 месяцев,
т.е . они начнутся в течение месяца 11 и т.д. Стадия описания требований (REQ) для всех
пяти сборо к происходит в течение месяцев -1 и 0, а все пять сборо к будут завершены
|'до наступления месяца 50. В то время ка к пики всех пяти кривых кадровог о обеспечения
появляются в начале фазы CUT, несложно заметить, что пики кадровог о обеспечения
монотонно возрастают от сборк и 1 до сборк и 5, что объясняется объемам и интегри­
руемых программных модулей и тестовых работ, возрастающих с увеличением KSDI.
Короч е говоря , это отнюдь не пять идентичных сборок , выполняемых последовательно.
Если вас интересует, "в ка к у ю с у м м у обойдутся четыре года разработки программно г о
обеспечения", то ответом будет $1,593 миллиона, если предположить, что средняя ча-
280 Част ь II . Технологии быстрого тестирования и советы

совая оплата труда разработчиков останется на уровне $55 на протяжении всего четы­
рехлетнего периода работы . Это ещ е один ответ, который м о ж н о найти на Титульном
листе. Итак, в сводке Титульного листа появляется итоговое значение 28968 человеко-
часов, разбитое по стадиям и представленное в человеко-месяцах следующи м образ ом :
REQ = 14,83, PD = 32,50, DD = 41,92 , CUT = 60,54 , IT = 42,05, что а с ум м е составляет
191,94 человеко-месяца.
В центре внимания рис. 12.12 находится только распределение ресурсов во время соз-
дания сбо рк и 1. Обратите внимание на то обстоятельство, что REQ = 2,75 человеко-
месяца и что это составляет справедливую дол ю от общег о значения REQ = 14,83 чело­
веко-месяца, затраченных на документирование всего продукта со множеств о м сборок .
Общая стоимость разработки после формулирования требований составляет 34,18 минус
2,75, затраченных на REQ, что дает 31,43 человеко-месяца, и это значение совпадает с об­
щим значением, указанным в правом столбце. Из графика загрузки персонала, полученного
с помощью модели COCOREV, следует, что преимущество программного обеспечения с
точки зрения используемого персонала в этом проекте должно возрасти с 2 исполнителей
до 4,5 при пике нагрузки и снизиться до 1,5 на протяжении последнего месяца.
Аналог сбор к и 1, а именно, сборк а 2, представлен на рис.12.13. В ч е м состоят различия
м е ж д у сбор ко й 1 и с бор к о й 2? Итак, во-первых, прежд е че м с бор к у 2 м о ж н о будет
поставлять, она должна быть интегрирована со сборко й 1, после чего об е сборк и долж­
ны быть подвергнуты совместном у тестированию. Второе отличие заключается в том ,
что разработка сборк и 2 задержана на 10 месяцев. Это означает, что ее разработка
начинается на 11-м месяце, т.е . по истечении 1,5 месяцев после выпуска сборк и 1. Дру ­
гими словами, требования, предъявляемые к сбо рк е 2, жду т своего часа око л о 10 ме­
сяцев, а за это время требования вполне мо гу т претерпеть определенные изменения,
причем совершенно бесплатно, пока кто-нибудь не возьмет на себя обязанности сопро ­
вождения документо в с формулировка м и требований. В данном случае выражение "со ­
вершенно бесплатно" является доказательством того , что приверженцы спиралевидного
подхода обычно принимают мер ы в подд ержк у своего утверждения о т о м , что спирале-
видный процесс уменьшает риски самопроизвольных изменений требований. В силу ка­
ких причин затраты на требования в случае сборк и 2 выше, чем затраты на требования в
случае сбор к и 1 (соответственно, 2,9 и 2,7 человеко-месяца)? Это объясняется более
высокой сложност ь ю требований сборк и 2 к интегрированию со сборко й 1.
Из соображени й краткости мы не б уде м показывать аналогичные графики для сборо к 3
и 4. На рис. 12,14 представлена кривая кадровог о обеспечения для последней из пяти
с бо р о к . Сравнивая эту криву ю кадровог о обеспечения с аналогичной кривой для сборк и
1, м о ж н о отметить, что суммарны е трудозатраты, за вычетом затрат на документиро ­
вание требований, составляют 38,22 - 31,33 = 6,89 человеко-месяцев. Для проекта , на
разработку ко т о р о г о уходит немноги м более 9 месяцев, для создания сборк и 5 требу­
ется на одног о исполнителя больше (количество персонала), чем для сборк и 1. Опять-
таки, эти расчеты подтверждают тот факт, что наличие в случае сборк и 5 унаследован­
ног о код а достаточно большого объем а обусловливает большие затраты времени и уси­
лий по сравнению со сборко й 1, у которо й вообщ е нет унаследованных кодов .
В начале этой главы мы поставили перед собой задачу дать по возможност и более точ­
ное описание способа прогнозирования трудозатрат на подготовку и выполнение тесто­
вых работ с разбивкой по месяцам , которо е обычно называется верификацией и атте­
стацией ( V & V ) . После предварительного описания возможносте й модели COCOREV мы
продолжи м рассмотрение примера с последовательностью из пяти сборо к , уделяя ос-
новное внимание упомянутым дву м тестовым функциям . Обратимся снова к сбор к е 1 и
разделим работы по тестированию на две категории: планирование испытаний
(рис. 12.15) и верификация и аттестация (рис.12.16) . Эти данные содержатся в электрон­
ной таблице сборк и 1 в рабоче м журнал е модели COCOREV. Термин персонал тести-
рования (fest staff) означает совокупность персонала, составляющего планы проведения
испытаний, и персонала, выполняющего верификацию и аттестацию, например, совокупное
число исполнителей, представленных на графиках, изображенных на рис. 12.15 и 12.16.
Г л а в а 12. Т е х н о л о г и и о ц е н к и т р у д о з а т р а т н а т е с т и р о в а н и е и с о в е т ы 281
282 Част ь П. Технологии быстрого тестирования и совет ы
 Глава 12. Технологии оценки трудозатрат на тестировани е и совет ы 283

Что собой представляет персонал, включенный в состав группы, формулирующей техни­

ческие требования? Модель COCOREV выделяет персоналу, проводящему тестирование,
некоторое количество часов для участия в документировании требований на протяжении
месяцев -1 и 0, предшествующих началу разработки сборки 1. Персонал тестирования
требует от авторов требований дать пояснения, что Означают эти требования примени­
тельно к тестированию каждой важной функции, создавая тем самым основу для со­
ставления персоналом тестирования соответствующих планов проведения испытаний,
тестовых случаев и результатов прогона тестов. На некоторых стадиях разработчикам
полезно также время от времени освежать в памяти технические требования на прове­
дение тестирования, чтобы можно было включать различные специализированные тесто­
вые процедуры в проекты и далее встраивать их в программное обеспечение.
284 Част ь II . Технологии быстрого тестирования и совет ы

Примерами специализированных тестовых процеду р могу т служить регистрация тран-

закций, откат всех транзакций баз данных, ведение файлов предыстории, в которы х на­
капливается хронология изменения данных, последовательность прохода ветвей кода или
выхода бе з заказа из пользовательских корзи н на Web-сайтах электронной коммерции .
Исполнители из числа персонала тестирования с их зараженностью на обнаружение де-
фектов, должн ы ознакомиться с эскизной и вспомогательной документацией, чтобы об­
наружить и задокументировать дефект ы в требованиях. В конечно м итоге , это наиболее
подходящее мест о для экономическ и эффективного отлавливания дефектов — когда
при наличии всех мощных аппаратно-программных средств для устранения всех этих де­
фектов достаточно будет только карандаша и резинки .
При сравнении приведенных выше графиков несложно заметить, что в качестве стадий в
обоих выбраны одни и те же месяцы, и что анализ ресурсов благоприятствует планиро-
ванию на ранних стадиях, а верификацию и аттестацию (V& V ) лучше выполнять поз ж е ,
на стадии комплексных испытаний (IT). Это не расходится с предназначением каждо й за-
дачи, например, планирование обнаружения дефектов во время использования техноло­
гий статического тестирования на стадиях REQ, PD, DD и CUT с последующи м выполне­
нием планов проведения испытаний, обнаружение м и документированием дефектов с
использованием динамических технологий тестирования на стадиях IT и приемочных ис­
пытаний. Модель COCOREV не поддерживает точку зрения некоторых руководителей,
которы е утвержда ют , что после то го , как разработчики построят готовый к запуску
программный продукт , м о ж н о подключать к работе независимую команд у тестирова-
ния, поставив перед ней задачу отыскания всех дефектов . Напротив, удачными считают­
ся такие проекты , во время разработк и которых планирование тестовых работ и прогон
тестов осуществляются на всех стадиях. Внимательность и осторожност ь при о б нар уже -
нии и исправлении дефектов с использованием статических средств на первых трех ста­
диях разработки — вот на че м делается акцент в технологии быстрог о тестирования.
Допущения анализируемого примера 2 представлены на рис.12.17 . Они мало чем отли­
чаются от допущений примера 1, однако на этот ра з мы намерены изменить одно важ­
ное условие для исследования отношения риски/вы игрыш , а именно, выбрать в качестве
жизненного цикла вместо спиральной каскадную модель. Для этог о поставим перед со­
бой задачу объединить все 75 KLOC в сбо р к у 1 и интегрировать ее саму с собой (75
KDSI), разумеется , отказавшись от использования четырех остальных сборо к модели
COCOREV.
После применения модели COCOREV на сборк е 1 были получены следующие результа­
ты , разбитые по стадиям и выраженные в человеко-месяцах: REQ = 11,84, PD = 38 50
DD = 42,85 , CUT = 58,86, IT = 51,54, что в совокупности дает 204,5? человеко-месяца.
Это составляет 30983,7 человеко-часов, учитывая, что месяц приравнивается к 151 опла­
чиваемому человеко-часу. В пересчете на денежные единицы получается $1,699 мил­
лиона, исходя из предположения, что стоимость человеко-часа составляет $55. График,
изображенный на рис.12.18 , показывает, что на разработк у проекта потребуется более
16 месяцев, при это м работы над проекто м начинаются после трехмесячного периода
формулирования требований. Пик кривой кадрового обеспечения приходится на стадию
CUT на уровне 15 человек в течение трех месяцев.
Пример - Часть 2
• Допущения
- 1 сборка
-75KDSI
- Для реализации каждой сборки используется язы к программирования C++
- В рамках одной сборки подробно рассматриваются:
• Планирование тестирования
• Верификация и аттестация

Рис. 12.17. Список допущений для части 2 примера

 Глава 12. Технологии оценки трудозатрат на тестирован и е и совет ы 285

:На рис.12.19 и 12.20 показаны, соответственно, кривые трудозатрат на составление пла­

нов проведения испытаний и на верификацию и аттестацию. Большая часть трудозатрат
на планы проведения испытаний приходится на стадии PD, DD и CUT, при этом в течение
девяти следующих подряд месяцев потребуется 0,8 человека каждый месяц. Наиболь­
шее количество персонала, занимающегося верификацией и аттестацией, приходится на
стадию IT и составляет 2,5 человека в течение трех месяцев подряд.
Этим заканчивается изучение части 2 примера. На рис. 12.21 представлен список допу-
286 Часть II. Технолог ии быстрого тестирования и советы

Пример - Часть 3
• Допущения
- 5 сборок, выполняемых каждые 2 месяца
- 15 KDSI каждая
- Каждая новая сборка интегрируется с результатами предыдущих
сборок
- Для реализации каждой сборки используется язы к программирования C++

Рис. 12.21. Список допущений для части 3 примера

Результаты этой части иллюстрируются гр а ф и ко м / к о т о р ы й показан на рис. 12.22. Кад­

ровое обеспечение ка ждо й стадии выглядит следующим образ о м : REQ = 1 4 , 8 3 , PD =
32,50, DD = 41,94, CUT = 60,54 , IT = 42,05 , что в совокупности дает 191,86 человеко-
месяца. Это составляет 28971,7 человеко-часов. Полагая, что меся ц содержи т 151 оп ­
лачиваемый 151 час, то в пересчете на денежные единицы получается $1,593 миллиона
при стоимости человеко-часа $55 .
Поскольку на ка ждо й стадии разработки программног о п р о дукта , а именно, на стадиях
PD, DD, CUT, IT, трудится персонал, прошедший специальную подготовку и получивший
сертификат на выполнение всех необходимых задач, конкретно е значение многоярусно­
го спиралевидного жизненног о цикла состоит в т о м , что персонал м ож е т завершить со­
ответствующую стадию на одной сборк е и перейти к выполнению той же стадии на сле­
дующе й сбо р ке . При это м кажды й исполнитель будет непрерывно занят решением сво­
ей задачи на протяжении года . Д р у г о е важное значение многоярусног о спиралевидного
жизненного цикла связано с т е м , что пользователи начинают работать с первой частью
новой системы примерно на полпути многоярусног о спиралевидного жизненного цикла и
регулярно продолжаю т получать выпуски с дополнительной функциональностью на про
тяжении остальных 10 месяцев жизненног о цикла.
С точки зрения персонала, составляющего планы проведения испытаний и выполняющего
верификацию и аттестацию, получение нового выпуска м о ж н о спланировать к конц у ка ­
ж д о г о двухмесячного периода из десяти последних месяцев жизненног о цикла.
 Глава 12. Технологии оценки трудозатрат на тестирование и советы 287

С финансовой точки зрения подход с использованием спиралевидной модели жизненно -

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

Технология функциональных баллов

В [1] предложена методология классификации программного обеспечения по разме­
рам, которая построена на предположении, что производительность разработки
программного обеспечения каким-то образом связана с функциональными возмож­
ностями. Области функциональных возможностей, которые при этом учитываются,
называются значениями информационного домена, часть из которых перечислена
ниже:
• Количество вводов пользователя — подсчет числа вводов пользователя. Учиты­
вается каждый ввод пользователя, который представляет пользователю отли­
чающуюся информацию, связанную с приложением. Вводы должны отделяться
от запросов, которые учитываются отдельно.
288 Част ь II. Технологи и быстрог о тестировани я и совет ы

• Количеств о выводо в для пользовател я — подсче т числ а выводо в дл я пользова­

теля . Учитываетс я кажды й выво д для пользовател я , предоста вля ющ и й отли­
чающуюся и н ф о рм а ц и ю из при л ож ен и я . В это м контекст е по д выводам и пони­
маются отчет ы , э к ра н ы , сообщени я об ошибка х и тому подобное . Индивиду­
альны е элемент ы данны х внутр и отчето в отдельн о н е подсчитываютс я .
• Количест в о запросо в пользовател я — запро с определяет с я как интерактивны й
ввод, вызыва ющ и й ту ил и иную немедленну ю ре а кц и ю программно г о обеспе­
чени я в ф о р м е инте ра ктив но г о вывода.
• Количеств о фай ло в — учитываетс я каждый л оги ч е ск и й главн ы й ф а й л (т.е. ло­
гическ и сгруппированны е данные , которы е могут быт ь часть ю крупно й базы
данных , состоя щ е й и з отдельны х фа й л ов) .
• Количеств о внешни х и н т е рфе й с о в — учитываютс я все машиночитаем ы е ин­
т е р ф е й с ы (напри ме р , фа й л ы данны х н а некот оры х носителях , используемых
для передач и в другие си ст ем ы ) .
Введите полученн ы е чи с л о вы е значе ни я в столбе ц "Ко лич ест во " таблиц ы , изо­
браженн о й на рис . 12.24.
На рис . 12.23 представле н п е р в ы й эта п двухэтапного процесс а подсчет а функцио­
нальны х баллов (functio n points , FP) . Эта п 1 начина е т исполнитель , имеющи й опыт
оц ен к и методом функци он альн ы х баллов . Исп олните л ь долже н ответи т ь н а вопросы
специальн о й анкет ы , используя п р и это м числа, указанны е в заголовк е анкеты . После
получен и я ответ о в на все 14 вопросо в анкеты , необходи м о сложит ь все числа, пред­
ставляющ и е ответы , и передат ь полученную сумму на следующий шаг.
На шаге 2 потребуетс я п е р е м н о ж и т ь эт и числа на соответствующи е веса, которые
указаны в столбцах, помеченн ы х ка к "Пр ост ой " , " С р е д н и й " и "Сложный" , просумми­
роват ь полученны е произв еден и я и поместит ь сумму в пол е "Обща я сумма" в соответ­
стви и с инструкциями , приведенны м и в начал е раздела . И, наконец , воспользуйтесь
формулой , пок азан н о й в ни жн е й част и рис . 12.24. В качеств е сомножите л я SUM(F i)
необходим о подставит ь сумму ко э ф фи ц и е н т о в уточнени я сложности , полученных на
шаге 1.
Функциональны й балл представляе т собо й взвешенную метрику индексног о типа,
предназначенну ю для изм е н ен и я объем а функциональност и программног о пакета,
каким его видит к о н е чн ы й пользователь . В начал е семидесятых , ра бота я в компании
IBM, Аллан Альбрехт (Allan Albrecht ) ввел пон ят и е функциональног о балла. Он пола­
гал, чт о функциональны е возможност и программног о пр и ло ж ен и я представляе т со­
бо й боле е важную характеристик у размер а программног о обеспечени я , нежел и число
LO C (Lines O f Co d e — с тр о к программног о кода) , которо е бы л о тогда традиционно й
единице й измерени я объем а программног о продукта. Функциональны е баллы ставят­
ся в оди н ря д с функци ям и о б р а б о т к и ин фор м а ц и и , к от ор ы е поставляютс я пользова­
телям . Функциональн ы е балл ы представ ляю т собо й средств о изме ре н и я размеров
программног о продукта, кот о р ы е н е завися т о т методо в разработки , технологи й и
языко в програм миро вани я . Ка к метрик а размеро в программног о обеспечения , зна­
чени я в функциональны х баллах обладаю т больше й надежность ю и могут опреде­
лятьс я н а ранни х стадия х ж из н е н н о г о цикла разработ к и программног о продукта.
Глава 12. Технологии оценки трудозатрат на тест ир ова н и е и совет ы 289
290 Част ь II . Технологии быстрого тестирования и советы

Метрика в функциональных баллах, равно как и число строк программных кодов

(LOC), в определенной степени противоречива. Убежденные противники функцио­
нальных баллов утверждают, что в этом случае имеет место некоторая подмена поня­
тий, поскольку рассматриваемые вычисления основаны скорее на субъективных, не­
жели на объективных данных. Они же утверждают и то, что эти данные с трудом со­
гласуются с фактическими показателями, полученными по завершении проекта.
Кроме того, функциональные баллы не имеют физического содержания, каким обла­
дает LOC. Сторонники этого метода приводят аргумент в их пользу, что функцио­
нальные баллы обладают преимуществом независимости от языков программирова­
ния. Это делает их более ценными по сравнению с числом LOC в отношении языков
программирования четвертого поколения, которые являются непроцедурными и не
связаны с понятием строки кода. Функциональные баллы можно получить непосред­
ственно из технических требований, в то время как число LOC может быть получено
на момент определения концепций только по аналогии с ранее разработанными про­
ектами.
В настоящее время существует группа IFPUG (International Function Point Users
Group — Международная группа пользователей функциональных баллов), которая
была создана около десяти лет тому назад с целью стандартизации определений и
использования рассматриваемой технологии. Есть и другие организации, занимаю­
щиеся разработкой программного обеспечения, которые применяют технологию
функциональных баллов. В подавляющем большинстве проектов, которые выполняла
наша организация, размеры программных продуктов оценивались числом строк про­
граммного кода, хотя для оценки размеров двух проектов были успешно применены
функциональные баллы. При помощи таблицы перевода Кейперса Джонса (Capers
Jones), представленной на рис. 12.1, можно перевести функциональные баллы в числа
LOC для широкого спектра применяемых в настоящее время языков программи­
рования.

Резюме
В процессе планирования работ по выполнению проекта программного продукта
необходимо решить следующие задачи:
• Выбрать жизненный цикл разработки программного обеспечения.
• Достичь глубокого понимания предварительных требований и основных огра­
ничений.
• Спрогнозировать трудозатраты и календарный график работ, а также дать
оценку размеров и затрат средств на разработку, взяв за основу статистические
данные по существующим программным продуктам.
• Воспользоваться подходом "разделяй и властвуй" с целью распределения задач
среди предполагаемых исполнителей в соответствии с их квалификацией.
Соответствующий процесс получения оценки предусматривает следующие дей­
ствия:
• Сбор входной информации, в том числе построение матрицы оценки размера
программного обеспечения, и принятие решений относительно жизненного
цикла разработки.
 Глава 12. Технологии оценки трудозатрат на тестирование и советы 291

• Получение оценки общих трудозатрат (в часах) на основе статистических дан­

ных по существующим программным продуктам.
• Распространение оценки общих трудозатрат на каждую задачу и каждый рабо­
чий график, соблюдая при этом границы основных стадий. Если возможно,
оценку трудозатрат необходимо распространить и на различные сборки спи­
ральной модели жизненного цикла.
• Документирование в форме электронной таблицы каждой задачи, трудозатрат
на ее выполнение, графиков работ, включая информацию о базисе оценок и
списки реальных условий, в которых реализуется жизненный цикл.
• Пересмотр оценок для передачи их руководству и выполнение предложенных
коррективов в соответствии с действующими требованиями.
 Примеры выполнения
быстрого тестирования
 Пример
формулирования
требований
Глава 2 была посвящена процессу определения требований. В ней же приводилась
диаграмма процесса формулирования требований, которая для удобства показывает­
ся еще раз на рис. 13.1.
В документе определения требований все системные требования излагаются на
обычном разговорном языке. В результате упрощается работа с документом со сторо­
ны заказчиков, что позволяет их привлекать к процессу разработки продукта. Вход­
ными данными для документа определения требований является набор требований,
сформированный в течения взятия неформальных интервью у заказчиков. Кроме
того, проводятся более строгие совещания и целенаправленные сеансы, посвящен­
ные совместной разработке требований к приложению (JAR); организация JAR-
сеансов подробно рассматривалась в главе 8.
 Глава 13. Пример формулирования требований 295

В главе 2 упоминалось о том, что определениям требований присущи следующие

характеристики:
• Каждое требование должно быть снабжено уникальным идентификатором,
чтобы можно было однозначно ссылаться на него при планировании тестового
покрытия, при проектировании тестовых случаев и в отчетах по результатам
тестирования.
• Требования должны быть представлены с точки зрения пользователя системы.
Системные и приемочные испытания должны быть спроектированы на основе
определений требований, следовательно, эти определения должны быть сфор­
мулированы в перспективе системного уровня. Этот принцип препятствует по­
явлению требований, затрагивающих внутренние свойства системы и требую­
щих детальных знаний программного кода для успешного тестирования. Такие
требования должны возникать на поздних стадиях разработки и охватываться
модульным тестированием и проверкой взаимодействия и функционирования
компонентов системы.
• Должны быть включены как функциональные (Junctional), так и нефункциональные
{nonfunctional) требования. Функциональные требования суть требования, опи­
сывающие услуги и функции, которые должна выполнять разрабатываемая сис­
тема. Нефункциональные требования описывают ограничения, накладываемые на
работу системы, например, количество одновременно работающих пользо­
вателей, и стандарты, которым должна соответствовать система.
• Документ определения требований должен находится под управлением конфи­
гурациями. Это, по меньшей мере, означает, что данный документ подпадает
под управление версиями и что все версии документа должны быть помещены в
безопасное хранилище, подобное, например, каталогу, содержимое которого
обычно дублируется. Если требования подвергаются изменениям, мы должны
иметь возможность проследить, чтобы соответствующие изменения были вне­
сены в тестовые случаи системных и приемочных испытаний.
Структура документа определения требований может основываться на специфи­
кациях, определенных в стандарте IEEE Standard 830: The IEEE Guide to Software Require­
ments Specifications (дополнительные сведения по применению этого стандарта можно
найти в главе 2).
Сейчас мы предлагаем приступим к изучить пример документа определения тре­
бований, который был подготовлен для вымышленного набора инструментальных
средств управления тестированием (Test Management Toolkit, ТМТ). Это приложение
позволяет менеджерам и инженерам, специалистам в области тестирования управ­
лять планами тестирования, отчетами о дефектах, результатами тестирования, а так­
же другой информацией, связанной с тестированием программного обеспечения.
ТМТ представляет собой Web-приложение, благодаря чему несколько географически
удаленных пользователей могут одновременно участвовать в нескольких проектах по
тестированию. Проект разработки приложения ТМТ приводится в качестве приме­
ра, который рассматривается на протяжении всей третьей части книги. В следующей
главе содержится пример плана тестирования, который основан на требованиях к
приложению ТМТ, определенных в данной главе.
Определение требований ТМТ TMT-RD-10

Идентификатор документа: TMT-RD-10

Версия: 0.8
Автор: Крис Браун (Chris Brown)

Набор инструментальных средств

управления тестированием

Версия 1.0

Определение требований

296
Определение требований ТМТ TMT-RD-10

Содержание
1. Введение 298
1.1. Назначение 298
1.2. Область применения 299
1.3. Обзор 299
2. Общее описание 299
2.1. Перспективы применения продукта 299
2.2. Функции продукта 299
2.2.1. Тестовые планы 299
2.2.2. Список прогона 299
2.2.3. Тесты 299
2.2.4. Выполнение тестов 299
2.2.5. Отчеты об ошибках 300
2.2.6. Итоговые отчеты 300
2.2.7. Резервное копирование и восстановление 300
2.2.8. Безопасность 300
2.2.9. Удаленное администрирование 300
2.2.10. Матрица прослеживаемости требований 300
2.3. Пользовательские характеристики 300
2.4. Общие ограничения 300
2.5. Допущения и зависимости 300
2.5.1. Операционные системы 301
2.5.2. Браузеры 301
2.5.3. Реляционные базы данных 301
2.5.4. Сервер Web-страниц 301
2.5.5. Зависимость от процессора 301
3. Специальные требования 301
3.1. Функциональные требования 302
3.1.1. Пользовательский интерфейс 302
3.1.2. Навигация 302
3.1.3. Аутентификация пользователей — клиент 303
3.1.4. Аутентификация пользователей — администратор 303
3.1.5. Текущие проекты 303
3.1.6. Завершенные проекты 303
3.1.7. Создание нового проекта 303
3.1.8. Изменение проекта 304
3.1.9. Удаление проекта 304
3.1.10. Создание тестового случая или набора 304
3.1.11. Изменение тестового случая или набора 304
3.1.12. Удаление тестового случая или набора 305
3.1.13. Отображение теста 305
3.1.14. Отображение тестового набора 305
3.1.15. Прогон одиночного теста 306
3.1.16. Прогон тестового набора 306
3.1.17. Создание списка прогона 306
3.1.18. Выполнение списка прогона 306

297
Определение требований ТМТ TMT-RD-10

3.1.19. Сводный отчет по ошибкам 306

3.1.20. Результаты тестирования — одиночный тест 307
3.1.21. Результаты тестирования — тестовый набор или список прогона 307
3.1.22. Создание матрицы прослеживаемости 307
3.1.23. Резервное копирование тестовых случаев 307
3.1.24. Резервное копирование тестовых наборов 307
3.1.25. Резервное копирование результатов прогона тестов 308
3.1.26. Восстановление тестовых случаев 308
3.1.27. Восстановление тестовых наборов 308
3.1.28. Восстановление результатов прогона тестов 308
3.1.29. Экспорт тестовых случаев 308
, 3.1.30. Экспорт тестовых наборов 308
3.1.31. Экспорт результатов прогона тестов 309
3.1.32. Справка 309
3.1.33. Многопользовательские функциональные возможности 309
3.2. Требования к внешнему интерфейсу 309
3.3. Требования к производительности 309
3.3.1. Возможность поддержки нескольких пользователей 309
3.4. Ограничения проекта 309
3.5. Структура данных 309
3.6. Атрибуты 309
3.7. Прочие требования 309
Ссылки 311
Приложение 1 — Слисок аббревиатур 311
Приложение 2 — Определение терминов 311
Приложение 3 — Адреса электронной почты утверждающих лиц 311
От: Чак Д. Клут (Chuck D. Klout) [cdklout@tmtco] 311
От: Сьюзи Перл (Suzie Perl [spent@[Link]] 312
От: Брит Гейтер (Bret Gater) [bgater@[Link]] 312

1. Введение

1.1. Назначение
Целью создания этого документа является определение набора требований к программному продук­
ту, именуемому набором инструментальных средств управления тестированием (Test Management
Toolkit, ТМТ). Документ предназначен для сотрудников отделов маркетинга, программирования, тес­
тирования, а также для технического персонала, осуществляющего поддержку программных продук­
тов. Документ организован таким образом, что обеспечивает возможность выделять, идентифициро­
вать и выбирать отдельные требования. Требования излагаются на таком уровне детализации, что
на их основе разработчики могут создавать программный продукт, а тестировщики — выполнять
аттестацию этого продукта. Программный продукт ТМТ может использоваться для упрощения про­
цессов тестирования оборудования, программного обеспечения и системы в целом. С целью упро­
щения все примеры применения ТМТ ограничиваются тестированием программного обеспечения.
Этот документ предназначен только для внутреннего использования.

298
Определение требований ТМТ TMT-RD-10

1.2. Область применения

Приложение ТМТ обеспечивает для менеджеров и инженеров по тестированию возможность управ­
ления планами тестирования, отчетами о дефектах, результатами прогона тестов и другой инфор­
мацией, связанной с тестированием программного обеспечения. ТМТ представляет собой Web-
приложение, благодаря чему несколько географически удаленных пользователей могут одновре­
менно участвовать в нескольких проектах по тестированию.

1.3. Обзор
Первые разделы документа содержат общее описание приложения ТМТ, а в следующих разделах
приводится список детализованных требований к этому программному продукту. Каждое требование
снабжено уникальным идентификатором, благодаря чему разработчики могут прослеживать трудо­
затраты на разработку и тестирование обратно в направлении требований. Дескрипторы требований
представлены в форме заголовков разделов. Например, раздел 2.2.1 представляет требование,
которое определяет методику применения приложения ТМТ для обработки документов, связанных с
планом тестирования. На дескриптор "2.2.1" можно ссылаться в других проектных документах. В
результате появляется гарантия, что более поздние ссылки на это требование могут отслеживаться
в обратном направлении вплоть до исходного требования, которое содержится в данном документе.

2. Общее описание
2.1. Перспективы применения продукта
Приложение ТМТ предназначено для упрощения тестирования программного обеспечения. Это при­
ложение может оказать существенную помощь при разработке, выполнении и отслеживании тести­
руемых программ. Этот документ описания требований направляет непосредственно на свойства,
которыми должен обладать коммерческий продукт, ориентированный на применение в области раз­
работки и тестирования программного обеспечения.

2.2. Функции продукта

В этом разделе описываются высокоуровневые функциональные свойства программного продукта
ТМТ. Более подробное описание требований находится в разделе 3.0.
2.2.1. Тестовые планы
Продукт ТМТ должен обеспечивать средства создания, изменения, просмотра, сохранения и выбор­
ки документов, описывающих тестовые планы.
2.2.2. Список прогона
Продукт ТМТ должен поддерживать средства создания, изменения, просмотра, сохранения и выбор­
ки набора тестов для прогона. В рамках данного документа этот набор тестов именуется "списком
прогона".
2.2.3. Тесты
Продукт ТМТ должен обеспечивать средства создания, изменения, просмотра, сохранения и выбор­
ки отдельных тестов, которые могут включать такие компоненты, как процедуры установки, списки
оборудования, процедуры тестирования, тестовые данные, а также процедуры, обеспечивающие
окончательную доводку (очистку) данных и результатов прогона тестов.
2.2.4. Выполнение тестов
Продукт ТМТ должен поддерживать средства запуска на выполнение тестов из списка прогона. При
этом для каждого теста могут создаваться свои результаты и журнальные файлы.

299
Определение требований ТМТ TMT-RD-10

2.2.5. Отчеты об ошибках

Продукт ТМТ должен поддерживать средства создания, изменения, просмотра, сохранения и выбор­
ки отчетов об ошибках.

2.2.6. Итоговые отчеты

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

2.2.7. Резервное копирование и восстановление

Продукт ТМТ должен иметь средства, предназначенные для резервного копирования и восстановле­
ния как тестов, так и результатов тестирования.

2.2.8. Безопасность
Продукт ТМТ должен поддерживать средства создания учетных записей и паролей для пользовате­
лей приложения. Для запуска тестов на выполнение и просмотра результатов прогона требуется
аутентификация пользователей.

2.2.9. Удаленное администрирование

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

2.2.10. Матрица прослеживаемости требований

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

2.3. Пользовательские характеристики

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

2.4. Общие ограничения

Ниже перечислены ограничения, могущие повлиять на возможности команды разработчиков про­
граммного обеспечения:
• Регулирующие политики.
• Ограничения, связанные с оборудованием.
• Интерфейсы с другими приложениями.
• Требования, накладываемые языками высокого уровня.
• Протоколы.
• Критический режим функционирования продукта.

2.5. Допущения и зависимости

В этом разделе описаны допущения и зависимости, связанные с программным продуктом ТМТ. С
целью упрощения будущих ссылок каждое допущение или зависимость помечается специальным
идентификатором (заголовком раздела). Перечисленные допущения следует принимать во внимание
во время создания конфигураций тестируемых систем с использованием ТМТ.

300
Определение требований ТМТ TMT-RD-10

2.5.1. Операционные системы

Предполагается, что пользователь выполняет клиентское приложение на компьютере, работающем
под управлением одной из следующих операционных систем:
Microsoft
• Windows 95
• Windows 98
• Windows Millennium Edition
• Windows XP
• Windows NT 3/51 или выше
• Windows 2000.
Apple
• MAC OS 9.x или выше.
Предполагается, что серверное приложение выполняется на компьютере, работающем под управле­
нием одной из следующих операционных систем:
Microsoft
• Windows NT 3.51 или выше.
UNIX
• Sun Solaris 2.6 или выше
• HPUX 10.x или выше
• Open BSD
• AIX 2.4.1 или выше
• SCO Open Desktop
• Linux Red Hat 6.x или выше.

2.5.2. Браузеры
Предполагается, что пользователь на клиентском компьютере использует один из следующих брау­
зеров: Netscape версии 4.0 или выше, Internet Explorer версии 5.0 или выше.

2.5.3. Реляционные базы данных

Предполагается, что на хост-компьютере (сервере) выполняется программное обеспечение реляци­
онных баз данных, которое допускает использование множественной индексации. Также предпола­
гается, что программное обеспечение баз данных обладает свойством блокирования записей. Кроме
того, необходимо, чтобы это программное обеспечение включало в свой состав библиотеки API,
совместимые со стандартным языком SQL. В начальной версии продукта ТМТ предполагается ис­
пользование баз данных Oracle. В будущих версиях ТМТ могут применяться другие системы управ­
ления базами данных, что должно регламентироваться отзывами пользователей, касающимися пер­
вой версии продукта.

2.5.4. Сервер Web-страниц

Предполагается, что на хост-компьютере (сервере) выполняется серверное приложение Web-
страниц, например, Apache или Microsoft Internet Information Server.

2.5.5. Зависимость от процессора

Приложение не зависит от типа применяемого процессора. Перечисленные ранее допустимые опе­
рационные системы могут использоваться на платформах с процессорами х86, RISC, SPARC, Mo­
torola или РРС.

3. Специальные требования

В этом разделе представлены детализованные требования, относящиеся к программному продукту ТМТ.

301
Определение требований ТМТ TMT-RD-10

3.1. Функциональные требования

3.1.1. Пользовательский интерфейс

Пользовательский интерфейс для клиента ТМТ создается с использованием языка HTML и отобра­
жается в окне Web-браузера. Применение HTML уменьшает степень зависимости от браузеров.

3.1.2. Навигация
Главное меню программного продукта ТМТ включает следующие пункты:

Current Projects (Текущие проекты)

Completed Projects (Завершенные проекты)
Project Maintenance (Сопровождение проекта)
Create New Project (Создать новый проект)
Modify Project (Изменить проект)
Remove Project (Уделить проект)
Help (Справке)
Test Case Maintenance (Сопровождение тестовых случаев)
Create Test Case or Suite (Создать тестовый случай или набор)
Modify Test Case or Suite (Изменить тестовый случай или набор)
Remove Test Case or Suite (Удалить тестовый случай или набор)
Display Test (Показать тест)
Display Suite (Показать тестовый набор)
Help (Справка)
Test Case Execution (Выполнение тестовых случаев)
Run Single Test (Прогнать одиночный тест)
Run Suite (Прогнать тестовый набор)
Create Run List (Создать список прогона)
Execute Run List (Выполнить список прогона)
Test Results (Результаты тестирования)
Bug Summary (Сводный отчет по ошибкам)
Single Test (Одиночный тест)
Suite or Run List (Тестовый набор или список прогона)
Help (Справка)
Utilities (Утилиты)
Create Trace Matrix (Создать матрицу прослеживавмости)
Backup (Резервное копирование)
Test Cases (Тестовые случаи)
Test Suites (Тестовые наборы)
Test Results (Результаты прогона тестов)
Help (Справка)
Restore (Восстановление)
Test Cases (Тестовые случаи)
Test Suites (Тестовые наборы)
Test Results (Результаты прогона тестов)
Help (Справка)
Export (Экспорт)
Test Cases (Тестовые случаи)
Test Suites (Тестовые наборы)
Test Results (Результаты прогона тестов)
Help (Справка)

302
Определение требований ТМТ TMT-RD-10

3.1.3. Аутентификация пользователей — клиент

Клиентский сеанс открывается после регистрации на хост-системе через Internet или интрасеть ком­
пании. Для прогона тестов и просмотра результатов пользователи должны вводить свои имена и
пароли. Имя пользователя и пароль должны быть уникальными и присваиваться администратором.
Имя и пароль не могут изменяться самим пользователем.

3.1.4. Аутентификация пользователей — администратор

Менеджер, руководитель и администратор должны вводить имя пользователя и пароль для того,
чтобы получить доступ к пользовательской информации либо выполнить администрирование базы
данных. Имя пользователя и паропь должны быть уникальными и могут изменяться только админи­
стратором.

3.1.5. Текущие проекты

После регистрации в системе пользователь получает возможность просматривать активные и теку­
щие проекты. В результате выбора этой опции из главного меню отображается список активных про­
ектов. В названии проекта отображается связанное с ним общее количество тестов либо тестовых
наборов. После общего числа тестов/тестовых наборов указывается процент выполненных тес­
тов/тестовых наборов. Затем выводится количество тестов, которые прошли. Далее выводится про­
центное отношение количества пройденных тестов к общему их числу. Затем отображается количе­
ство тестов, завершившихся неудачно. После информации о количестве тестов, завершившихся
неудачно, выводится их процентное отношение к общему числу тестов. Далее отображается общее
число заблокированных тестов. После общего числа заблокированных тестов указывается их про­
центное отношение к общему числу тестов. Затем выводится время, оставшееся до завершения
данного проекта.
Время, которое осталось до завершения проекта, может описываться как "Not Known" ("Неиз­
вестное") ипи же указываться в часах и минутах. Время выполнения теста определяется временем
его последнего прогона. Оставшийся запас времени представляет собой общее значение времени
(сумма по всем тестам) минус время, затраченное на уже выполненные тесты.

3.1.6. Завершенные проекты

После регистрации в системе пользователь получает возможность просматривать завершенные
проекты. В результате выбора этой опции из главного меню отображается список завершенных про­
ектов. После названия проекта указывается общее количество тестов или тестовых наборов, связан­
ных с проектом. Затем, после общего числа тестов/тестовых наборов отображается процент выпол­
нения данного проекта. Следом за процентом выполнения указывается количество успешно прой­
денных тестов. После количества пройденных тестов отображается их процент в общем количестве
тестов. За значением процента следует число тестов, потерпевших неудачу. После этого отобража­
ется их процентное отношение к общему количеству тестов, а затем — общее число заблокирован­
ных тестов. После общего количества заблокированных тестов указывается их процентное отноше­
ние к общему числу тестов. Наконец, отображается время прогона всех тестов для данного проекта.

3.1.7. Создание нового проекта

После регистрации в системе пользователь получает возможность создавать новый проект. Процесс
создания проекта начинается непосредственно после выбора пользователем опции "Create New
Project" ("Создать новый проект") из меню "Project Maintenance" ("Сопровождение проекта"). Вначале
предлагается ввести имя нового проекта. После ввода имени проекта отображается список всех
доступных тестовых случаев и наборов.
После выбора тестовых случаев и/или тестовых наборов, пользователь должен получить воз­
можность сохранить проект или отменить действия и вернуться в главное меню. При выборе сохра­
нения список тестовых случаев и/или тестовых наборов должен быть сохранен как проект.

303
Определение требований ТМТ TMT-RD-10

3.1.8. Изменение проекта

После регистрации в системе пользователь должен иметь возможность изменять существующий
проект. Процесс изменения начинается после выбора элемента "Modify Project" ("Изменить проект")
из меню "Project Maintenance" ("Сопровождение проекта"). На этом этапе отображается запрос на
ввод имени проекта, а также предлагается список доступных проектов, среди которых можно произ­
вести выбор. Пользователь должен либо ввести имя проекта, либо дважды щелкнуть на соответст­
вующем имени проекта в списке.
В случае отсутствия проектов отображается сообщение "No Projects Have Been Created" ("Соз­
данные проекты отсутствуют"). На этом этапе пользователь должен иметь только один вариант вы­
бора, которым служит кнопка "ОК", щелчок на которой закрывает окно сообщения и приводит к воз­
врату в главное меню.

3.1.9. Удаление проекта

Процесс удаления проекта начинается после выбора пользователем элемента "Remove Project"
("Удалить проект") из меню "Project Maintenance" ("Сопровождение проекта"). Пользователю выдает­
ся запрос об имени удаляемого проекта, а также список доступных проектов, в котором можно произ­
вести выбор. Пользователь должен иметь возможность либо ввести имя удаляемого проекта, либо
дважды щелкнуть на имени соответствующего проекта в списке.
В случае отсутствия проектов отображается сообщение "No Projects Have Been Created" ("Соз­
данные проекты отсутствуют"). На этом этапе пользователь должен иметь только один вариант вы­
бора, которым служит кнопка "ОК", щелчок на которой закрывает окно сообщения и приводит к воз­
врату в главное меню.

3.1.10. Создание тестового случая или набора

После регистрации в системе пользователь должен иметь возможность создавать новые тестовые
случаи или наборы. Процесс создания начинается после выбора пользователем опции "Create Test
Case or Suite Test" ("Создать тестовый случай или набор ") из меню "Test Case Maintenance" ("Сопро­
вождение тестовых случаев").
Если проект уже идентифицирован, пользователь должен получить запрос на ввод имени проек­
та либо выбрать его из списка. Если до этого момента не было идентифицировано ни одного проекта
или тестового набора, пользователь должен указать, является ли его целью создание одиночного
тестового случая или части тестового набора. При выборе одиночного тестового случая отображает­
ся запрос на ввод его имени. Если выбран тестовый набор, потребуется ввести имя этого набора.
Тестовый случай:
Для пользователя выводится интерфейс в виде формы с предварительно определенными полями, в
которые потребуется ввести необходимые данные. На этом этапе форма именуется "корзиной", и
она является представлением создаваемой структуры типа записи. После ввода данных в запись,
пользователь должен иметь возможность сохранить тест или отменить действие. В случае выбора
сохранения, запись данных помещается в базу данных. Кроме того, пользователь должен иметь
возможность распечатать тестовый случай.
Тестовый набор:
Если пользователь выбирает тестовый набор, отображается запрос на ввод имени набора. Затем
отображается список доступных (уже созданных) тестовых случаев. Достаточно будет выбрать тес­
товые случаи, установив соответствующие флажки. После выбора пользователь должен иметь воз­
можность сохранить тестовый набор или отменить действие. Если выбрано сохранение, создается
тестовый набор, который помещается в базу данных. Кроме того, пользователь должен иметь воз­
можность распечатать тестовый набор.

3.1.11. Изменение тестового случая или набора

После регистрации в системе пользователь должен иметь возможность изменять существующие
тестовые случаи или наборы. Процесс изменения начинается после выбора опции "Modify Test Case

304
Определение требований ТМТ TMT-RD-10

or Suite" ("Изменить тестовый случай или набор ") в меню "Test Case Maintenance" ("Сопровождение
тестовых случаев").
Далее пользователь должен ввести имя теста или тестового набора. При этом должна быть воз­
можность выбора соответствующего имени из списка. В случае отсутствия тестов или тестовых на­
боров отображается сообщение "There are no Test Cases or Suites to Modify" ("He существует тесто­
вых случаев или наборов для изменения").
Тестовый случай:
Пользователь должен получить доступ к тесту, который находится в том же формате, что и в момент
создания. При этом поддерживается интерфейс в виде формы с предварительно определенными
полями, содержащими предварительно определенные данные. Если тестовый случай изменялся,
пользователь должен иметь возможность сохранить измененный тест или отменить действие. При
выборе операции сохранения запись помещается в базу данных. Кроме того, должна существовать
возможность распечатки тестового случая.
Тестовый набор:
Если пользователь выбирает тестовый набор для изменения, отображаются все доступные тесты, в
число которых входят и уже выбранные. Последние идентифицируются отмеченными флажками.
Пользователь может выбрать дополнительные тесты либо исключить ранее выбранные. По
завершении процесса выбора должны быть доступны три возможности. Измененный тестовый набор
можно сохранить под тем же именем либо определить для него новое имя. После выбора операции
сохранения тестовый набор закрывается, а изменения помещаются в базу данных. Кроме того, поль­
зователь должен иметь возможность прервать действие и отменить все проделанные изменения. В
дополнение должна существовать возможность распечатки тестового набора.

3.1.12. Удаление тестового случая или набора

Процесс удаления инициируется после выбора пользователем опции "Remove Test Case or Suite"
("Удалить тестовый случай или набор ") из меню "Test Case Maintenance" ("Сопровождение тестовых
случаев"). В результате появляется возможность удалить отдельный тестовый случай или целый
набор. Выбор производится в отображаемом списке тестовых наборов и тестовых случаев, при этом
с каждым элементом связан отдельный флажок. Пользователю потребуется просто отметить те тес­
ты, которые должны быть удалены.
Далее у пользователя есть возможность удалить выделенные тесты либо отменить действие.
После выбора операции удаления отображается дополнительный запрос "Are you sure?" ("Вы увере­
ны?"). Пользователь может выбрать опцию "Yes, Delete the selected entries" ("Да, удалить выделен­
ные элементы") или отменить действие. В случае выбора удаления происходит действительное уда­
ление соответствующих записей. Список удаляемых файлов можно вывести на печать.

3.1.13. Отображение теста

Эта опция обеспечивает возможность просмотра детальной информации, связанной с тестовым
случаем. После выбора пользователем из меню "Test Case Maintenance" ("Сопровождение тестовых
случаев") опции "Display Test" ("Показать тест") отображается список доступных тестов. Для про­
смотра теста достаточно выполнить двойной щелчок кнопкой мыши на его имени. Тестовый случай
будет отображаться в том формате, в котором он пребывал на этапе создания. Выводимые данные
можно только просматривать, но не изменять. Кроме того, тестовый случай можно распечатать.

3.1.14. Отображение тестового набора

Эта опция обеспечивает возможность просмотра тестового набора. После выбора пользователем
элемента "Display Suite" ("Показать тестовый набор") из меню "Test Case Maintenance" ("Сопровож­
дение тестовых случаев") отображается список доступных тестовых наборов. Для просмотра тре­
буемого тестового набора необходимо дважды щелкнуть кнопкой мыши на его имени. После этого
тестовый набор выводится в форме списка тестовых случаев, при этом будут отображаться только
те тестовые случаи, для которых были отмечены флажки во время создания. Данная опция обеспе-

305
Определение требований ТМТ TMT-RD-10

чивает только просмотр, поэтому внесение каких-либо изменений в состав тестового набора невоз­
можно. Тестовый набор можно вывести на печать.

3.1.15. Прогон одиночного теста

Эта опция активизируется после выбора пользователем элемента "Run Single Test" ("Прогнать оди­
ночный тест") из меню "Test Case Maintenance" ("Сопровождение тестовых случаев"). Для пользова­
теля должен выводиться список доступных тестов. Требуемый тестовый случай выбирается двой­
ным щелчком кнопкой мыши. Прогонять можно как автоматизированные, так и тесты, выполняемые
вручную.
Тестирование, выполняемое вручную:
Тестовый случай отображается в режиме только для чтения со множеством опций в нижней части
экрана. Предполагается, что специалист по тестированию выполнит действия, детально описанные в
тестовом случае, и посмотрит на полученные результаты. В частности, доступны опции "Pass"
("Прошел"), "Fail" ("He прошел") либо "Blocked" ("Заблокирован"). После выбора опции "Fail" или
"Blocked" выводится запрос о причинах, который содержит текстовое поле для описания причин не­
успешного прогона тестового случая. Совершенно аналогично вводятся детали для тестового случая
с признаком "Blocked". После описания причин неудачного прогона теста пользователь должен вы­
брать опцию "Finish" ("Готово"), в результате чего результат регистрируется.
Автоматическое тестирование:
Если тест является автоматизированным, после двойного щелчка кнопкой мыши запускается сцена­
рий, реализованный на Perl, TCL или другом языке написания сценариев. Тестовый случай выполня­
ется, а результаты регистрируются автоматически.

3.1.16. Прогон тестового набора

Эта опция активизируется после выбора из меню "Test Case Execution" ("Выполнение тестовых слу­
чаев") элемента "Run Suite" ("Прогнать тестовый набор"). Для пользователя отображается список
доступных тестовых наборов. Для запуска на выполнение требуемого тестового набора тестов дос­
таточно выполнить двойной щелчок кнопкой мыши на его имени. В результате будет иметь место
одно из двух возможных действий. Тестовые наборы могут быть предназначены для прогона в руч­
ном режиме и отображаться по очереди. Пользователю предоставляется возможность выполнить
все шаги вручную и указать результат в форм "прошел/не прошел". Затем отображается следующий
тест и все повторяется сначала.
Если тестовые наборы являются автоматизированными, все тестовые случаи прогоняются, а
результаты регистрируются.
Кроме того, возможны комбинации автоматизированных тестов и тестами, прогоняемых вручную.
Все зависит от деталей отдельных тестовых случаев, выбираемых во время создания тестового
набора.

3.1.17. Создание списка прогона

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

3.1.18. Выполнение списка прогона

Данная опция дает возможность пользователю выбрать и запустить на выполнение любой ранее
сохраненный список прогона.
г
3.1.19. Сводный отчет по ошибкам
В результате выбора этой опции пользователь получает запрос относительно выбора текущего или
завершенного проекта для его анализа. Опция находится в меню Tests Results (Результаты тестиро­
вания). В случае выбора из текущих проектов, отображается список текущих проектов, а в случае

306
Определение требований ТМТ TMT-RD-10

выбора из завершенных проектов - соответственно, список завершенных проектов. Для анализа

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

3.1.20. Результаты тестирования — одиночный тест

Эта опция приводит к выводу списка результатов прогона тестового случая. Опция находится в меню
Tests Results (Результаты тестирования). Отображаемая информация может сортироваться по иден­
тификатору теста, дате тестирования, времени тестирования и состоянию теста, которым может
"pass" ("прошел"), "fail" ("не прошел") и "blocked" ("заблокирован"). Допускается выделять диапазоны
тестов и генерировать итоги.

3.1.21. Результаты тестирования—тестовы й набор или список прогона

Эта опция дает возможность получить список тестовых наборов или списков прогона, которые вы­
полнялись или выполняются в настоящий момент. Опция доступна через меню Tests Results (Ре­
зультаты тестирования). В результате отображаются итоги по тестам, которые завершились удачно,
неудачно и были заблокированы, а также процент завершения тестирования.

3.1.22. Создание матрицы прослеживаемости

Эта опция предоставляет возможность генерации матрицы прослеживаемости требований (Require­
ments Traceability Matrix), которая используется на этапах планирования и выполнения тестов. Акти­
визация опции выполняется после выбора пользователем элемента "Create Trace Matrix" ("Создать
матрицу прослеживаемости") из меню "Utilities" ("Утилиты"). Пользователю выдается запрос на ввод
имени проекта. При этом можно просто ввести имя проекта либо дважды щелкнуть на требуемом
имени в отображаемом списке доступных проектов. Создается экранный отчет с уже определенным
списком требований и местами для помещения информации, связанной с тестовыми случаями. На
этом экране также имеется возможность отправить матрицу на принтер или сохранить ее в формате
электронных таблиц, совместимых с Excel.
Если еще не было создано ни одного проекта, отображается сообщение "No Projects Have Been
Created" ("Созданные проекты отсутствуют"). На этом этапе пользователю доступна только одна
возможность - выполнить щелчок на кнопке "ОК" и после чего вернуться в главное меню.

3.1.23. Резервное копирование тестовых случаев

Эта опция дает возможность пользователю создавать архивные резервные копии тестовых случаев.
Опция активизируется в результате выбора элемента "Backup/Test Cases" ("Резервное копирова­
ние/Тестовые случаи") из меню "Utilities" ("Утилиты"). Пользователь получает запрос на ввод имени
резервной копии и целевого носителя. Эти данные отличаются от системы к системе. В среде Win­
dows отображается стандартный список физических, логических и подключенных сетевых дисков. В
системе UNIX можно получить список псевдонимов смонтированных томов, в рамках которого и про­
извести свой выбор. Учитывая размеры файлов резервного копирования, обыкновенные дискеты
редко когда подходят. В системах, в состав которых входят дисководы CD/R или CD/RW, можно про­
сто выполнить резервное копирование на такое устройство, не используя при этом специализиро­
ванного программного обеспечения для записи CD/RW.

3.1.24. Резервное копирование тестовых наборов

Данная опция предоставляет пользователю возможность создавать архивные резервные копии тес­
товых наборов. Опция активизируется после выбора пользователем элемента "Backup/Test Suites"
("Резервное копирование/Тестовые наборы") из меню "Utilities" ("Утилиты"). Пользователь получает
запрос на ввод имени резервной копии и целевого носителя. Эти данные отличаются от системы к
системе. В среде Windows отображается стандартный список физических, логических и подключен­
ных сетевых дисков. В системе UNIX можно получить список псевдонимов смонтированных томов, в

307
Определение требований ТМТ TMT-RD-10

рамках которого и произвести свой выбор. Учитывая размеры файлов резервного копирования,
обыкновенные дискеты редко когда подходят. В системах, в состав которых входят дисководы CD/R
или CD/RW, можно просто выполнить резервное копирование на такое устройство, не используя при
этом специализированного программного обеспечения для записи CD/RW.

3.1.25. Резервное копирование результатов прогона тестов

Эта опция предоставляет пользователю возможность создавать архивные резервные копии резуль­
татов прогона тестов. Опция активизируется после выбора пользователем элемента "Васkuр/Test
Results" ("Резервное копирование/Результаты прогона тестов") из меню "Utilities" ("Утилиты"). Поль­
зователь получает запрос на ввод имени резервной копии и целевого носителя. Эти данные отлича­
ются от системы к системе. В среде Windows отображается стандартный список физических, логиче­
ских и подключенных сетевых дисков. В системе UNIX можно получить список псевдонимов смонти­
рованных томов, в рамках которого и произвести свой выбор. Учитывая размеры файлов резервного
копирования, обыкновенные дискеты редко когда подходят. В системах, в состав которых входят
дисководы CD/R или CD/RW, можно просто выполнить резервное копирование на такое устройство,
не используя при этом специализированного программного обеспечения для записи CD/RW.

3.1.26. Восстановление тестовых случаев

Эта опция дает возможность восстанавливать тестовые случаи, для которых ранее создавались
резервные копии. Опция активизируется после выбора элемента "Restore/Test Cases" ("Восстанов­
ление/Тестовые случаи") из меню "Utilities" ("Утилиты"). Пользователь должен выбрать источник рас­
положения и имя восстанавливаемой резервной копии.

3.1.27. Восстановление тестовых наборов

Эта опция дает возможность восстанавливать тестовые наборы, для которых ранее создавались
резервные копии. Опция активизируется после выбора элемента "Restore/Test Suites" ("Восстанов­
ление/Тестовые наборы ") из меню "Utilities" ("Утилиты"). Пользователь должен выбрать источник
расположения и имя восстанавливаемой резервной копии.

3.1.28. Восстановление результатов прогона тестов

Эта опция дает возможность восстанавливать результаты прогона тестов, для которых ранее созда­
вались резервные копии. Опция активизируется после выбора элемента "Restore/Test Results" ("Вос­
становление/Результаты прогона тестов") из меню "Utilities" ("Утилиты"). Пользователь должен вы­
брать источник расположения и имя восстанавливаемой резервной копии.

3.1.29. Экспорт тестовых случаев

Эта опция предоставляет возможность экспортировать выбранные тестовые случаи в файлы ASCII-
формата с разделителями-запятыми. Опция активизируется после выбора элемента "Export/Test
Cases" ("Экспорт/Тестовые случаи") из меню "Utilities" ("Утилиты"). В результате отображается список
всех доступных тестовых случаев. Для выполнения экспорта пользователю достаточно просто дваж­
ды щелкнуть на имени требуемого тестового случая. Далее выдается запрос на указание целевого
местоположения и имени выходного файла. Пользователь должен иметь возможность отправлять
данные экспорта на принтер.

3.1.30. Экспорт тестовых наборов

Эта опция предоставляет возможность экспортировать выбранные тестовые наборы, разделенные
на отдельные тестовые наборы, в файлы ASCII-формата с разделителями-запятыми. Опция активи­
зируется после выбора элемента "Export/Test Suites" ("Экспорт/Тестовые наборы") из меню "Utilities"
("Утилиты"). В результате отображается список всех доступных тестовых наборов. Для выполнения
экспорта пользователю достаточно просто дважды щелкнуть на имени требуемого тестового набора.
Далее выдается запрос на указание целевого местоположения и имени выходного файла. Пользова­
тель должен иметь возможность отправлять данные экспорта на принтер.

308
Определение требований ТМТ TMT-RD-10

3.1.31. Экспорт результатов прогона тестов

Эта опция предоставляет возможность экспортировать выбранные результаты прогона тестов в
файлы ASCII-формата с разделителями-запятыми. Опция активизируется после выбора элемента
"Export/Test Results" ("Экспорт/Результаты прогона тестов") из меню "Utilities" ("Утилиты"). После
этого отображается список всех доступных результатов прогона тестов. Для выполнения экспорта
пользователю достаточно просто дважды щелкнуть на имени требуемого результата прогона тестов.
Далее выдается запрос на указание целевого местоположения и имени выходного файла. Пользова­
тель должен иметь возможность отправлять данные экспорта на принтер.

3.1.32. Справка
Для каждого элемента меню должен существовать экран с соответствующей справочной информа­
цией по возможностям, реализуемым тем или иным элементом меню. Содержимое справочного эк­
рана всецело зависит от меню, из которого он вызывается.

3.1.33. Многопользовательские функциональные возможности

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

3.2. Требования к внешнему интерфейсу

Какие-либо требования к аппаратным или программным внешним интерфейсам отсутствуют.

3.3. Требования к производительности

В этом разделе описывается требования к производительности программного продукта ТМТ.

3.3.1. Возможность поддержки нескольких пользователей

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

3.4. Ограничения проекта

В начальной версии продукта ТМТ используется приложение базы данных Oracle. Проектирование и
реализация программного продукта должны быть совместимы с Oracle.

3.5. Структура данных

Проект структуры данных для тестового случая показан в таблице 3.1, а активные индексы — в
таблице 3.2.

3.6. Атрибуты
Какие-либо требования к сопровождению и переносимости отсутствуют.

3.7. Прочие требования

Прочие требования в настоящий момент отсутствуют.

309
Определение требований ТМТ TMT-RD-10

310
Определение требований ТМТ TMT-RD-10

Ссылки
Ссылки отсутствуют

Приложение 1 —Список аббревиатур

API — Application Programming Interface (Интерфейс программирования приложений)
ASCII — American Standard Code for Information Interchange (Американский стандартный код обмена
информацией)
CDR — Compact Disc Recordable (Записываемый компакт-диск)
HTML — Hypertext Markup Language (Язык гипертекстовой разметки)
ISO — International Organization for Standardization (Международная организация по стандартизации)
РРС — Power PC (Процессор Power PC)
RISC — Reduced Instruction Set Computing (Сокращенный набор вычислительных инструкций)
SQL — Structured Query Language (Язык структурированных запросов)
SPARC — Scalable Processor Architecture (Масштабируемая процессорная архитектура)
TCL — Tool Command Language (Инструментальный командный язык)
ТМТ — Test Management Toolkit (Набор инструментальных средств управления тестированием)
Х86 — Процессоры серии Intel

Приложение 2 — Определение терминов

Отсутствует

Приложение 3 — Адреса электронной почты утверждающих лиц

От: ЧакЦ,. Клут (Chuck D. Klout) [cdklout@tmtco]
Отправлено: Среда 9/7/01 14:23
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: Определения требований к приложению ТМТ, версия 1.0
Уважаемые члены команды,
Я просмотрел определения требований для первой версии приложения ТМТ и пришел к выводу, что
этот документ весьма точно соответствует требованиям, выдвинутым нашими заказчиками. Я одоб­
ряю определения требований к приложению ТМТ (код TMT-RD-10) в том виде, в котором они были
составлены.
Я должен собираюсь встретиться со своими заказчиками на будущей неделе с целью уточнения
списка обязательного оборудования. Я также хочу получить своевременный ответ, чтобы выполнить
пересмотр плана тестирования.
Заранее благодарен, Чак

311
Определение требований ТМТ TMT-RD-10

Чак Д. Клут
Директор отдела маркетинга
ТМТСО
cdklout@[Link]

От: Сьюзи Перл (Suzie Perl [spent@[Link]]

Отправлено: Четверг 9/9/2001 09:30
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: Определение требований ТМТ 1.0
Привет всем,
Хорошая работа! Я просмотрела определение требований к приложению TMT-RD-10 (версия 8) и
одобрила его использование в процессе разработки в том виде, в каком оно было записано.
С наилучшими пожеланиями,
Сьюзи
Сюзанна Перл
Менеджер, отдел программирования
ТМТСО

От: Брит Гейтер (Bret Gater) [bgater@[Link]]

Отправлено: Четверг 9/9/2001
Кому: Крис Браун [cbrown@tmtco]; test@tmtco; development@tmtco
Копия: marketing@tmtco; costumersupport@tmtco
Тема: Определение требований ТМТ 1.0
Уважаемые члены команды,
Я просмотрел определение требований TMT-RD-10 (версия 8) и одобрил его использование коман­
дой тестирования в том виде, в котором он написан.
С наилучшими пожеланиями,
Брит
Брит Гейтер
Менеджер, отдел программирования

312
 Пример плана
тестирования
В главе 3 отмечалось , чт о э ф ф е к т и в н о е плани рован и е те с т и р о в а н и я явля ет с я ключе­
вым факторо м успеха проект а , оценива емог о в термина х соответств и я график у и
бюджету. Дл я удобства на р ис . 14.1 повторн о прив оди т с я диаграмм а из главы 3, кото­
ра я отражае т действи я , выполняемы е в о врем я составлен и я плано в тестировани я .
Исходным и данным и для процесс а планирован и я яв ляют с я документ ы оп ис ан и я
тр еб о ва ни й , к от ор ы е бы л и под р об н о описан ы в главе 2. В главе 13 приводит с я доста­
т о ч н о ре а ль н ы й приме р документ а определ ен и я т р е б о в а н и й . Результатом выполне ­
ни я действи й , связанны х с планированием , являет с я пла н тести рова ни я . Это т пла н
представляе т собо й докумен т ил и набо р документов, к от ор ы е до лжн ы периодическ и
просматривать с я командам и тестиро вщик о в , р аз р а б о т ч и к о в и менеджерам и про­
граммн ы х продуктов. В план е т е ст и р о в а н и я ид е н т и ф и ц и р у ю т с я ресурсы, которы е
необходим о п р ив л е ч ь для т е ст и р о в а н и я програ ммно г о продукта, определяют с я цел и
тестировани я , методи к а ег о проведения , а такж е указывается , каки е результат ы и
промежуточны е продукт ы дол жн ы подвергатьс я те с т и р о в а н и ю . Содер жим о е и фор ­
ма т план а т е ст и р о в а н и я обсуждаются в главе 3, а при ме р пла н т е с т и р о в а н и я предла­
гаетс я в данно й главе.
П ол езн ы е рекомендац и и п о разраб от к е плана т е с т и р о в а н и я содержатс я в доку­
мент е IEEE Standard 829, IEEE Standard for Software Test Documentation (дополнительны е
сведени я вопрос у можн о найт и в главе 3) . Ко н е чн о , можн о воспользоватьс я и аль­
тернативн ы м фо рматом , н о п р и это м н е следует забыват ь относитель н о включени я
всех необходимы х документов , диктуемых стандарто м IEEE. В это й главе в качеств е
основ ы для при м ер а плана тестиров ан и я был выбра н стандар т IEEE Standar d 829.
Структура план а тестиро в ани я , определяема я стандартом , включае т в себя 16
компонент :
1. И д е н т и ф и к а т о р план а проведени я испытани й
2. Введени е
3. Ко м п о н е н т ы , к от о р ы е должн ы тестир оватьс я
4. Характеристи к и и свойства , которы е должн ы тес тир ов атьс я
5. Характеристи к и и свойства , которы е не должн ы тестир ова тьс я
6. Подхо д
7. К р и т е р и й успешны х и неудачных испытани й
8. К р и т е р и й при ос тан о в к и испытани й и требовани я возобновлен и я испытани й
9. Выходны е результат ы тесто в
10. Задач и т е ст и р о в а н и я
314 Часть III . Процесс быстрого тестирования

11. Требования окружающей среды

12. Распределение ответственности
13. Подбор кадров и подготовка персонала
14. График работ
15. Риски и непредвиденные обстоятельства
16. Утверждение плана проведения испытаний.

При внимательном изучении приведенного выше списка можно заметить, чем не

является стандартный план тестирования. Он не суть детализованная спецификация,
описывающая методику выполнения тестов, а также не место фиксации результатов
тестирования. В некоторых организациях, занимающихся тестированием, с содер­
жимым плана комбинируются один и большее количество указанных выше пунктов. В
результате появляется возможность собрать и сохранить всю документацию в одном
месте. Подобный подход вполне оправдан. Тем не менее, в этой книге рассматрива­
ется модульный набор документов, который в дальнейшем подпадает под стандарт.
В оставшейся части главы предлагается пример плана тестирования, подготов­
ленный для вымышленного набора инструментальных средств управления тестиро­
ванием (Test Management Toolkit, TMT). В качестве исходных данных для плана тес­
тирования служит документ определения требований к продукту ТМТ, который был
рассмотрен в главе 13.
План тестирования программного продукта ТМТ ТМТ-ТР-10

Идентификатор документа: ТМТ-ТР-10

Версия: 0.8
Авторы: Крис Браун (Chris Brown)
Джеймс Барнc (James Barnes)

Набор инструментальных средств управления тестированием

Версия 1.0

План тестирования

315
Пл а н т е с т и р о в а н и я про гр а мм н о г о продукт а ТМ Т ТМТ-ТР-10

Содержание
1. Введение 316
2. Тестируемые элементы 317
3. Свойства, которые должны тестироваться 317
4. Свойства, которые не должны тестироваться 318
5. Применяемый подход 318
5.1. Тестирование свойств 318
5.2. Регрессионное тестирование 318
5.3. Установка продукта 319
5.4. Резервное копирование и восстановление 319
5.5. Тестирование графического интерфейса пользователя 319
6. Критерий успешных и неудачных испытаний 319
7. Критерий приостановки испытаний и требования возобновления испытаний 319
8. Выходные результаты тестов 320
9. Задачи тестирования 320
10. Конфигурации тестов 323
11 . Распределение ответственности 323
12. Подбор кадров и подготовка персонала 324
13. Календарный график 324
14. Риски и непредвиденные обстоятельства 325
Ссылки 325
Приложение 1 — Список аббревиатур 326
Приложение 2 — Определение терминов 326
Приложение 3 — Сообщения электронной почты от утверждающих лиц 326
От: Чак Д. Клут (Chuck D. Klout) [cdklout@tmtco] 326
От: Сьюзи Перл (Suzie Perl [spent@[Link]] 327
От: Брит Гейтер (Bret Gater) [bgater@[Link]] 327

1. Введение
Назначение этого документа состоит в детализации процедур тестирования, которые должны атте­
стовать функциональные возможности программного продукта ТМТ. Свойства, на которые произво­
дятся ссылки в этом документе, находятся в документе определения требований, именуемого "На­
бор инструментальных средств управления тестированием, Определение требований". Документ,
определяющий требования, имеет идентификатор TMT-RD-10 и находится под управлением систе­
мы контроля документов на Web-сайте:
http//[Link]. со m/usr/www/docstores/desiqn/requirements/[Link]

316
План тестирования программного продукта ТМТ ТМТ-ТР-10

2. Тестируемые элементы
Ниже приводится перечень высокоуровневый список компонентов продукта, на которые имеются
ссылки в этом план тестирования:
• Тестируемая версия — Этот элемент связан с функциональными возможностями программного
продукта ТМТ версии 1.0.
• Исправление ошибок — Это первая версия программного продукта, поэтому в ней отсутствуют
исправления ошибок, которые найдены в предыдущих версиях, требующих тестирования. Все
найденные и исправленные в ходе тестирования ошибки должны быть верифицированы.
• Носитель, на котором распространяется продукт— Начальная версия программного продукта
может выгружаться из Web-сайта разработчиков. Заказчики, заинтересованные в приобретении
этого продукта, могут получать его на CD-ROM. Тестированию должны подвергаться оба типа рас­
пространения.
• Документы для конечного пользователя — Предполагается, что клиент и сервер находятся в
различных местах, поэтому требуются два отдельных модуля, для каждого из которых должна
предусматриваться собственная программа установки. Документы для конечного пользователя,
такие как руководство пользователя, руководство по установке и примечания к версиям, могут вы­
гружаться отдельно, чтобы заказчик мог иметь возможность просматривать системные требования
и процедуры установки. Для достижения приемлемого уровня точности должно выполняться тес­
тирование процессов установки и создания пакетов, а также просматриваться соответствующая
документация.

3. Свойства, которые должны тестироваться

Для того чтобы удостовериться в том, что программный продукт ТМТ удовлетворяет требованиям,
указанным в спецификации требований ТМТ, необходимо протестировать следующие требования:
• Требование 3.1.1. Пользовательский интерфейс
• Требование 3.1.2. Навигация
• Требование 3.1.3. Аутентификация пользователей — клиент
• Требование 3.1.4. Аутентификация пользователей — администратор
• Требование 3.1.5. Текущие проекты
• Требование 3.1.6. Завершенные проекты
• Требование 3.1.7. Создание нового проекта
• Требование 3.1.8. Изменение проекта
• Требование 3.1.9. Удаление проекта
• Требование 3.1.10. Создание тестового случая или набора
• Требование 3.1.11. Изменение тестового случая или набора
• Требование 3.1.12. Удаление тестового случая или набора
• Требование 3.1.13. Отображение теста
• Требование 3.1.14. Отображение тестового набора
• Требование 3.1.15. Прогон одиночного теста
• Требование 3.1.16. Прогон тестового набора
• Требование 3.1.17. Создание списка прогона
• Требование 3.1.18. Выполнение списка прогона
• Требование 3.1.19. Сводный отчет по ошибкам
• Требование 3.1.20. Результаты тестирования — одиночный тест
• Требование 3.1.21. Результаты тестирования—тестовый набор или список прогона

317
П л а н т е с т и ро в а н и я програ ммн о г о продукт а Т М Т ТМТ-ТР-10

• Требование 3.1.22. Создание матрицы прослеживаемости

• Требование 3.1.23. Резервное копирование тестовых случаев
• Требование 3.1.24. Резервное копирование тестовых наборов
• Требование 3.1.25. Резервное копирование результатов прогона тестов
• Требование 3.1.26. Восстановление тестовых случаев
• Требование 3.1.27. Восстановление тестовых наборов
• Требование 3.1.28. Восстановление результатов прогона тестов
• Требование 3.1.29. Экспорт тестовых случаев
• Требование 3.1.30. Экспорт тестовых наборов
• Требование 3.1.31. Экспорт результатов прогона тестов
• Требование 3.1.32. Получение справки
• Требование 3.1.33. Многопользовательские функциональные возможности

4. Свойства, которые не должны тестироваться

Ниже приводится список функциональных свойств и/или конфигураций системы, которые не должны
тестироваться.
• В план тестирования не включается описание функциональных возможностей и процесса установ­
ки реляционной базы данных. Предполагается, что база данных установлена и функционирует.
Также предполагается, что структура данных точно определена и содержит обязательные поля с
типами и размерностью, которые определены в спецификации требований. Эти требования под­
робно излагаются в руководствах по подготовке и установке.
• В плане не предусматривается непосредственное тестирование Web-сервера (Apache или IIS).
• План тестирования не предполагает интенсивного расширенного тестирования архитектуры кли­
ент/сервер. Функциональные возможности, обеспечивающие работу в многопользовательском ре­
жиме, тестируются через работу пяти реальных пользователей, что определено минимальной
многопользовательской конфигурацией.

5. Применяемый подход
Подход, предполагающий всеобъемлющее тестирование, включает тестирование свойств, регресси­
онное тестирование, тестирование процесса установки продукта, резервного копирования и восста­
новления, а также тестирование графического интерфейса пользователя. В этом разделе подробно
описывается каждый упомянутый вид тестирования.

5.1. Тестирование свойств

Все свойства, описанные в определении требований TMT-RD-10 должны тестироваться на выбран­
ных комбинациях конфигураций клиент/сервер, описанных в разделе 10. Тестирование свойств
предполагает функциональное и отрицательное тестирование (попытка выполнения операций и
ввода данных, не предусмотренных разработчиками).

5.2. Регрессионное тестирование

Поскольку это первая версия программного продукта, отсутствует потребность в верификации на
предмет проявления ошибок, устраненных в предыдущих версиях. Данная версия программы отли­
чается тем, что ошибки, исправленные на этапе системного тестирования, не разрушают ранее ра­
ботоспособные функциональные возможности.
Для регрессионного тестирования первой версии программного продукта предлагается следую­
щий подход:

318
План тестирования программного продукта ТМТ ТМТ-ТР-10

• Исправление ошибок должно осуществляться по мере их обнаружения. Для каждой программной

сборки, переданной в команду тестировщиков, должны прогоняться тесты, что обеспечивает га­
рантию того, что устраненные ошибки не проявятся снова. Другими словами, в сборке должно
проверяться каждое исправление ошибки.
• Если программный продукт функционирует устойчиво, а тестовые случаи прошли успешно, перед
выполнением просмотром готовности должен быть выполнен последний проход регрессионного
тестирования.

5.3. Установка продукта

Каждая программная сборка, переданная команде тестировщиков, устанавливается в соответствии с
процедурой установки, которую будет использовать заказчик. Однако для каждой сборки модули
клиента и сервера устанавливаются только на подмножестве всех возможных комбинаций платформ
и операционных систем, которые указаны в спецификации требований. Предполагается, что успеш­
ная установка на одной платформе UNIX создает прецедент для успешной установки для всех ос­
тальных UNIX-подобных платформ. То же справедливо и для платформ Windows. Этот подход ут­
вержден у заказчика (см. сообщение электронной почты утверждающего лица из отдела маркетинга).

5.4. Резервное копирование и восстановление

Функционирование резервного копирования и восстановления тестируется для проектов, тестовых
случаев, тестовых наборов и результатов прогона тестов. При этом должны использоваться как фи­
зические, так и логические устройства, которые являются автономными либо сетевыми. Сетевое
резервное копирование является наиболее предпочтительным сценарием для заказчика, поэтому
ему будет уделяться повышенное внимание.

5.5. Тестирование графического интерфейса пользователя

При тестировании графического интерфейса продукта ТМТ используется следующий подход:
• Графический интерфейс пользователя тестируется в браузерах Netscape Navigator и Microsoft
Internet Explorer. При этом должен быть просмотрен полный состав интерфейса, а также протести­
рованы возможности навигации в обоих браузерах.
• Все действия по тестированию выполняются в ручном режиме.
• Все дефекты отслеживаются и устраняются с помощью корпоративной системы отслеживания
дефектов. Такой подход предполагает нахождение недоработок в графическом интерфейсе поль­
зователя в ходе проведения различных оценок после завершения работы над проектом.

6. Критерий успешных и неудачных испытаний

Критерий успешных и неудачных испытаний для каждого тестового случая описывается через ожи­
даемые результаты. Если после прогона тестового случая получен ожидаемый результат, значит,
тест пройден успешно. Если же после прогона теста ожидаемый результат не получен, считается,
что тест потерпел неудачу. Если же тест не может быть прогнан вследствие блокирующей ошибки в
сборке, результат тестирования именуется "заблокированным".
Для того чтобы продукт ТМТ смог успешно пройти фазу системного тестирования, 100% тестов
из данного плана тестирования должны выполниться, по крайней мере, на одной программной сбор­
ке. 100% всех прогнанных тестов должны завершиться успешно, а по завершении тестирования не
должна остаться неустраненной ни одна серьезная ошибка.

7. Критерий приостановки испытаний и требования возобновления

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

319
План тестирования программного продукта ТМТ ТМТ-ТР-10

должен продолжаться, если только обнаруженные ошибки не столь серьезны и не заблокировано

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

8. Выходные результаты тестов

Перечисленные ниже элементы представляют собой рабочие продукты, которые появляются в ре­
зультате выполнения тестирования:
• Данный план тестирования.
• Матрица прослеживаемости требований.
• Документ со спецификациями тестов.
• Отчеты по результатам прогона тестов.
• Ежедневные обновления состояния тестирования, направляемые менеджерам по тестированию и
разработке.
• Отчеты о дефектах (ошибках).
За примечания по версии несут ответственность разработчики; однако, примечания по версии долж­
ны просматриваться и одобряться командой тестирования до пересмотра готовности продукта.

9. Задачи тестирования
Ниже перечислены задачи, которые должны выполняться во время тестировании продукта ТМТ:
• Выполнение тестирования процесса установки продукта.
• Прогон тестов для свойств и построение отчета об ошибках.
• Верификация фактов устранения ошибок.
• Выполнение тестов резервного копирования и восстановления.
• Выполнение тестирования графического интерфейса пользователя.
• Ведение обзоров по ошибкам.
• Подготовка отчетов о состоянии тестов.
• Написание отчета по результатам тестирования.
В этом разделе оцениваются временные затраты (в человеко-часах), которые потребуются для вы­
полнения перечисленных выше задач. Эти оценки трудозатрат основаны на прошедшем 09.01.2001
сеансе Wideband Delphi. Фактором, оказывающим наибольшее влияние на объем времени и ресур­
сов, которые необходимы для тестирования продукта ТМТ, является количество клиентских и сер­
верных операционных систем, оговоренное в документе определения требований. Сводку по опера­
ционным системам можно найти в таблице 9.1.

320
План тестирования программного продукта ТМТ ТМТ-ТР-10

Как показано в таблице 9.1, имеется семь клиентских и семь серверных операционных систем, упо­
мянутых в определении списка требований. При этом необходимо, чтобы использовалась только
одна операционная система из списка, куда входят Windows NT, Solaris 2.6, OS9.X и Linux 6.x. Следо­
вательно, существует 49 возможных комбинаций клиентских и серверных операционных систем.
Установка каждой комбинации системы клиент/сервер требует в среднем 5 часов. Общее время,
необходимое для тестирования процесса установки продукта, составляет 5 х 49 = 245 часов, или
около 30 рабочих дней. Обратите внимание, что процесс предполагает установку операционной сис­
темы, приложения реляционной базы данных и приложения ТМТ для клиента и сервера, а также
установку клиентского браузера. Если запланировать тестирование свойств и резервного копирова­
ния для всех 49 комбинаций, объемы времени, необходимого для тестирования ТМТ, возрастут до
немыслимых размеров.
Вследствие больших временных затрат на тестирование всех возможных комбинаций, во время
выполнения тестирования процесса установки продукта используют лишь подмножество комбинаций
клиент/сервер, которое показано в таблице 9.2.

Сокращение количества комбинаций должно приводить к экономии ресурсов, затрачиваемых на тес­

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

321
План тестирования программного продукта ТМТ TMT-TP-10

вания/восстановления количество комбинаций клиент/сервер может быть сокращено до двух конфи­

гураций (см. таблицу 9.3).

Предполагая что использование выделенных комбинаций операционных систем, которые показаны в

таблицах 9.2 и 9.3, в таблице 9.4 приводятся оценки трудозатрат для каждого цикла тестирования
приложения ТМТ. Обратите внимание, что одиночный цикл тестирования включает выполнение все­
го набора запланированных тестов на кандидате на программную сборку. Для тестирования прило­
жения ТМТ необходимо воспользоваться тремя циклами тестирования, поэтому общие трудозатраты
сводятся к утроенному объему трудозатрат, перечисленных в таблице 9.4.

322
План тестирования программного продукта ТМТ ТМТ-ТР-10

10. Конфигурации тестов

Диаграмма для тестовой конфигурации # 1 , показанная на рис. 10.1, будет использоваться во время
тестирования свойств, резервного копирования/восстановления и графического интерфейса пользо­
вателя. В этой тестовой конфигурации присутствуют два сервера и пять клиентов, причем серверы и
клиенты подключены к общей сети. Тестовая конфигурация #1 основывается на выделенных комби­
нациях операционных систем клиент/сервер, которые приведены в таблице 9.3. Предполагается, что тес­
товая конфигурация #1 будет первичной конфигурацией, используемой во время верификации ошибок.
Несмотря на то что на рис. 10.1 это явно не показано, все серверы и клиенты выполняют
приложение баз данных Oracle как систему реляционных баз данных, которая задействована в
продукте ТМТ. Это ограничение тестовой конфигурации должно быть включено в примечания по
версии. Предполагается, что при будущем тестировании будут использоваться другие системы
управления базами данных.
Также на рисунке явно не указано, что в качестве приложения браузера для клиентов 1, 3 и 5
выбран Internet Explorer, а для клиентов 2 и 4 - Netscape Navigator. На рис. 10.2 показана диаграмма
для тестовой конфигурации #2. Эта конфигурация предназначена для тестирования процесса уста­
новки продукта, но при необходимости может использоваться и для другого тестирования. Обратите
внимание, что тестовая конфигурация #2 является единственной, которая поддерживает тестирова­
ние на платформе Apple Macintosh.

11. Распределение ответственности

В этом разделе обсуждается ответственность за тестирование на организационном уровне; здесь не
рассматриваются роли и ответственность отдельных инженеров по тестированию, поскольку это
служит материалом следующего раздела.
Ответственность команды разработки
• Объединение тестируемых свойств на этапе их создания.
• Выполнение комплексных испытаний на свойствах перед их упаковкой в форме сборки для коман­
ды тестирования.
• Подготовка программных сборок для команды тестирования в сроки, устанавливаемые на ежене­
дельных собраниях команд разработки и тестирования.
• Помощь тестировщикам в обосновании результатов тестирования и, при необходимости, в харак-
теризации ошибок, чтобы в систему отслеживания дефектов вводились точные отчеты.
• Устранение ошибок, информация о которые введена в систему отслеживания дефектов.

323
План тестирования программного продукта ТМТ ТМТ-ТР-10

• Подготовка примечаний по версии для тех ошибок, которые не устранены в версии, поставленной
заказчику.
• Реализация обходного пути "малого влияния на заказчика" для тех ошибок, которые не были уст­
ранены, но упоминаются в примечании по версии.
Ответственность команды тестирования
• Прогон запланированных тестов и ввод сообщений об ошибках в систему отслеживания дефектов
в случае получения аномальных результатов.
• Помощь разработчикам в воспроизведении ошибок.
• Ведение регулярных обзоров ошибок на этапе системных испытаний. Обзоры должны составлять­
ся еженедельно, если только команды тестирования и разработки не придут к выводу, что отчеты
необходимо составлять чаще.
• Проверка успешности устранения ошибок, которая позволяет удостовериться в том, что исправ­
ленное программное обеспечение демонстрирует ожидаемое поведение (удовлетворяет опреде­
ленным требованиям).
• Подготовка еженедельных отчетов о состоянии процесса тестирования и обнаружении ошибок.
• Подготовка отчета по результатам прогона тестов в конце этапа системных испытаний. Резюме
этого отчета будет присутствовать в обзоре степени готовности продукта. Резюме должно вклю­
чать в себя определение, достигнут ли критерий завершения тестирования, обозначенный в
разделе 6.

12. Подбор кадров и подготовка персонала

Роли и ответственности персонала во время тестирования приложения ТМТ показаны в таблице 12.1.
Д. Нгуен (D. Nguyen) должен обучиться администрированию баз данных Oracle, а К. Тейлор (С.
Taylor), новичок в компании, должна пройти внутренние курсы обучения по тестированию программ­
ного обеспечения "Software Testing 101", руководимые Дж. Барнсом ([Link]). Все обучение должно
завершиться до передачи разработчиками первой программной сборки в команду тестирования.

13. Календарный график

Календарный график системного тестирования продукта ТМТ показан в таблице 13.1. Испытание
герметичности, показанное на графике, выполняется во время предварительного знакомства с про­
граммным обеспечением. В течение этого испытания обеспечивается обнаружение в приложении
основных блокирующих ошибок, а также дефектов в конфигурациях тестов и тестовых случаях. Ис­
пытание герметичности должно состоять из подмножества тестовых случаев установки и свойств.

324
План тестирования программного продукта ТМТ ТМТ-ТР-10

Предполагается, что тестирование модулей и комплексные испытания были реализованы до уста­

новки тестовой конфигурации #1 и все катастрофические ошибки, обнаруженные в ходе этого тести­
рования, устранены до начала стадии системного тестирования.

14. Риски и непредвиденные обстоятельства

В таблице 14.1 перечислены риски, связанные с процессом тестирования продукта ТМТ, вместе с
оценочными значениями вероятностей их возникновения, влиянием и кратким описанием плана
смягчения этого влияния.

325
План тестирования программного продукта ТМТ ТМТ-ТР-10

Ссылки
Chris Brown, Test Management Toolkit, Requirements Definition (Набор инструментальных средств
управления тестированием, Определение требований). Документ TMT-RD-10, который размещает­
ся под управлением системы контроля документов по адресу:
[Link]

Приложение 1 —Списо к аббревиатур

API — Application Programming Interface (Интерфейс программирования приложений)
ASCII — American Standard Code for Information Interchange (Американский стандартный код обмена
информацией)
CDR — Compact Disc Recordable (Записываемый компакт-диск)
HTML — Hypertext Markup Language (Язык гипертекстовой разметки)
ISO — International Organization for Standardization (Международная организация по стандартизации)
РРС — Power PC (Процессор Power PC)
RISC — Reduced Instruction Set Computing (Сокращенный набор вычислительных инструкций)
SQL — Structured Query Language (Язык структурированных запросов)
SPARC — Scalable Processor Architecture (Масштабируемая процессорная архитектура)
TCL — Tool Command Language (Инструментальный командный язык)
ТМТ — Test Management Toolkit (Набор инструментальных средств управления тестированием)
Х86 — Процессоры серии Intel

Приложение 2 — Определение терминов

Отсутствует

Приложение 3 — Сообщения электронной почты от утверждающих лиц

От: ЧакД. Клут (Chuck D. Klout) [cdklout@tmtco]
Отправлено: Среда 9/11/01 16:40
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: План тестирования ТМТ, версия 1.0

Уважаемые члены команды,

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

ний и плана тестирования для данной версии программного продукта. Я утверждаю план тестирова­
ния ТМТ-ТР-10, версия 8, в том виде, в котором он написан.

Я встречался с нашими заказчиками для определения обязательного перечня сертифицированного

оборудования для данной версии программного продукта. Утверждения, проведенные в плане тес­
тирования в связи с предполагаемой совместимостью с ограниченным числом комбинаций операци­
онных систем, имеют смысл. В связи с этим мы можем продолжать работы с сокращенным списком
оборудования и операционных систем, на который имеются ссылки в разделах 9 и 10 при рассмот­
рении конфигураций тестов. Такая комбинация аппаратного и программного обеспечения покрывает
и те конфигурации, которые заказчики используют в настоящее время, так и те, которые планируется
установить в будущем.

Спасибо,
Чак

326
План тестирования программного продукта ТМТ ТМТ-ТР-10

ЧакД. Клут
Директор отдела маркетинга
ТМТСО
cdklout@[Link]

От: Сьюзи Перл (Suzie Perl [spent@[Link]]

Отправлено: четверг 9/12/2001 09:30
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: План тестирования ТМТ 1.0

Привет всем,

Хорошая работа! Я просмотрела план тестирования ТМТ-ТР-10, версия 8, для первой версии ТМТ и
утверждаю его в том виде, в котором он написан.

С наилучшими пожеланиями,
Сьюзи

Сюзанна Перл
Менеджер, отдел программирования
ТМТСО

От: Брит Гейтер (Bret Gater) [bgater@[Link]]

Отправлено: четверг 9/12/2001 7:30
Кому: Крис Браун [cbrown@tmtco]; test@tmtco; development@tmtco
Копия: marketing@tmtco; costumersupport@tmtco
Тема: План тестирования ТМТ 1.0

Уважаемые члены команды,

Я просмотрел план тестирования ТМТ-ТР-10, версия 8, и утверждаю его использование командой

тестирования в том виде, в котором он написан.

С наилучшими пожеланиями,
Брит

Брит Гейтер
Менеджер, отдел программирования

327
 Примеры
проектирования и
разработки тестов
В главе 4 упоминалось, что процесс создания сценариев эффективных тестовых слу­
чаев состоит из двух частей. Исходя из предположения, что непротиворечивые оп­
ределения требований готовы, а план тестирования в соответствие с требованиями
составлен, разработка тестовых случаев сводится к выполнению следующих этапов:
• Проектирование тестов
• Разработка детализованных тестовых процедур
• Верификация и отладка тестовых процедур.
Этот общий подход можно применять для тестов, выполняемых как в ручном, так
и в автоматическом режимах; реально получается так, что сначала лучше разработать
и отладить процедуры вручную, а затем добавить возможности автоматизации.
На рис. 15.1 показана диаграмма, отображающая действия по проектированию и
разработке тестов. Первичными входными данными для процесса разработки явля­
ется набор документов, описывающие план тестирования, который обсуждался в гла­
ве 3. В плане тестирования предлагается подход, а также определяется круг задач,
которые должны быть решены в ходе тестирования. Потребуется определить архи­
тектуру тестов, что означает определение, по меньшей мере, тестовых наборов. Кро­
ме того, необходимо будет определить набор тестовых конфигураций, на которые
будут ориентироваться создаваемые тесты. Пример плана тестирования был пред­
ставлен в предыдущей главе.
Результатом действий по проектированию и разработке тестов является набор
просмотренных и отлаженных тестовых случаев, готовых для использования в сис­
темных и приемочных испытаниях. Тестовые случаи должны отображаться на требо­
вания, сформулированные заказчиком. Они должны обеспечивать хорошее покры­
тие за счет тестирования, по меньшей мере, всех высокоприоритетных требований, а
в идеале — абсолютно всего перечня требований. Тестовые случаи также должны
осуществлять хорошее покрытие кода путем прохода большинства, если не всех, ло­
гических ветвей кода.
Если в распоряжение специалиста по тестированию поступают спецификация
требований и план тестирования, он может приступить к проектированию тестов.
Этот процесс связан с подготовкой следующих действий:
• Определение целей тестирования
• Определение входных данных, необходимых для прогона каждого теста
 Глава 15. Пр и мер ы проект ирован и я и разработк и тест о в 329

• О п р е д е л е н и е конфигураци и , необходимо й для каждог о тест а

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

Все перечи сле нн ы е э тап ы по др о бн о р ас смат рива ют с я в главе 4 . П о завершен и и

процесс а п рое к ти ров ан и я тесто в появл яют с я два рабочи х документа: докумен т п о
проект а м тест о в и документ п о с п е ц и ф и к а ц и и тестов . Эт и документы можн о скомби­
ни ро в ат ь , ка к п оказ ан о в п рим ере , представл енн о м в данно й главе.
Н а з н а ч е н и е документа, включающег о оп и с а н и е проек т о в тестов , состои т в охват е
абсо лют н о все й и н ф ор м а ц и и , к ото р а я получаетс я в результат е вып ол не н и я действи й
п о п рое к ти ров а н и ю тестов . Это т документ може т приним ат ь форм у э л е к т рон н о й
таб ли ц ы , та б лиц ы , генерируем о й тек сто вы м процесс ором , ил и ж е форм у баз ы дан­
ных . О н мож е т быт ь результатом , к от ор ы й генериру е т инструментальн о е средств о
а в т о м а т из а ц и и управлени я требованиям и и тестами , прич е м полученн ы е в т ак о м
случае тест ы основ ыва ют с я н а треб ован ия х . В при ме р е документа, содержащег о спе­
ц и ф и к а ц и и тестовы х процедур , к от ор ы й представле н дале е в главе, п роект ы тест о в
был и сге не риров ан ы п р и помощ и Microsoft Excel и зате м помещен ы в документ опи­
са ни я с п е ц и фи к а ц и й .

Пр о ц е с с пр ое кт ир о ва н и я тесто в в рассматриваемо м при ме р е тесн о завяза н н а

фор мат , оп р ед е л ен н ы й в главе 4, к от о р ы й для удобства приводитс я на рис . 15.2.
Расс матрив аем а я в данно й главе табли ц а имее т сходств о с м а т р и ц е й прослежи ­
ваемост и т р е б о в а н и й (Requirem en t s Traceabilit y Matrix , RTM ) , к о т о р а я обсуждалась в
330 Часть III. Процесс быстрого тестирования

главе 2 (см. рис. 2.5). Первые два столбца таблицы должны соответствовать записям в
RTM-матрице, а остальные столбцы связаны с данными, которые рассматривались в
предыдущих трех разделах этой главы. Из-за подобия таблиц разработок и RTM-
матрицы пример самой матрицы не приводится.
Непосредственно после создания документа с проектами тестов необходимо пе­
ресмотреть связанные с ним материалы, т.е. документ определения требований, оп­
ределения входных данных для теста и конфигурации самих тестов. Как упоминалось
в главе 4, назначение такого обзора связано с выполнением следующих верификаций:
• Верификация на предмет того, что при составлении документа проекта тестов
учтены все требования. Если требование не тестируется, в RTM-матрице или в
документе по разработке теста должна появиться соответствующая запись,
описывающая причину, почему данное требование не тестируется.
• Верификация на предмет того, что с каждым тестовым случаем связан соответ­
ствующий набор входных данных.
• Верификация на предмет того, что с каждым тестовым случаем связана подхо­
дящая конфигурация, а тестовые конфигурации не являются избыточными.
Документ с проектами тестов служит основанием для создания детализированных
тестовых процедур. Как указано в обзоре, детализированную разработку тестов мож­
но поручить специалистам команды. Примеры детализованных тестовых процедур
содержатся в документе, озаглавленном "Спецификация тестовой процедуры", кото­
рый можно найти в конце главы.

Детализованные тестовые процедуры, рассматриваемые в примере, записаны в

виде пар "действие/ожидаемый результат". Это означает, что тестировщик должен
выполнять определенные действия, такие, например, как щелчок на элементе меню и
сравнение результата этого действия с ожидаемым. Если ожидаемый результат полу­
чен, тест считается пройденным; в противном случае результат прогона теста рас­
сматривается как неудачный.
С целью экономии пространства тестовые случаи не записываются в формате
шаблона тестовых случаев, который рассматривался в главе 4. Тем не менее, дабы
 Глава 15. Примеры проектирования и разработки тестов 331

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

последний еще раз приводится на рис. 15.3.
Основными элементами шаблона тестового случая являются:
• Идентификатор тестового случая — включает номер версии.
• Владелец теста — имя и фамилия того, кто поддерживает тест (это не всегда ав­
тор теста).
• Дата создания последней версии — помогает уточнить, является ли версия теста
актуальной.
• Имя теста - описательное название теста, которое упрощает его поиск и пони­
мание его содержания. Не рекомендуется использовать имена, не имеющие
смысловой нагрузки, наподобие "[Link]".
• Расположение теста — полный путь, включая имя сервера.
• Тестируемое требование — должен указываться уникальный идентификатор
требования из документа описания требований.
• Цель тестирования — краткое и ясное изложение цели, которая достигается
данным тестом. Более подробную информацию можно найти в разделе "Опре­
деление целей теста" главы 4).
• Конфигурация теста — спецификации входных и выходных данных, а также
описание среды тестирования.
• Установка теста — по аналогии с процедурой тестирования, описываются дей­
ствия, которые должен выполнять тестировщик, и ожидаемые результаты. Ес­ ли
процесс установки автоматизирован, то сама установка может принимать
форму единственной команды, например, ru n setu pSC0 3 . pl.
• Процедура тестирования — описание действий, которые должен выполнить
тестировщик, и ожидаемый результатов.
• Взаимозависимости тестовых случаев — определение тестовых случаев, кото­
рые необходимо выполнить перед данным тестовым случаем, чтобы достигнуть
известных начальных условий.
• Очистка теста — если система переводится в нестабильное состояние или же ей
передаются преднамеренно запорченные данные, то при помощи очистки
можно выполнить откат.
332 Част ь I II . Процес с быстрого тестирования
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Идентификатор документа: TMT-TPS-10

Версия: 0.5
Авторы: Крис Браун (Chris Brown)
Джеймс Барнс (James Barnes)

Набор инструментальных средств управления тестированием

Версия 1.0

Спецификация тестовой процедуры

333
Спецификация тестовой процедуры ТМТ

Содержание
1. Введение
2. Свойства, которые должны тестироваться
3. Проекты тестов
3.1. Регрессионное тестирование
3.2. Резервное копирование и восстановление
3.3. Дополнительные возможности
3.4. Установка продукта
3.5. Тестирование графического интерфейса пользователя
4. Информация о конфигурации тестов
5. Тестовые случаи
5.1. ТС 3.1.1 Пользовательский интерфейс
5.2. ТС 3.1.2 Навигация
5.3. ТС 3.1.3 Аутентификация пользователей — клиент
5.4. ТС 3.1.4 Аутентификация пользователей — администратор
5.5. ТС 3.1.5 Текущие проекты
5.6. ТС 3.1.6 Завершенные проекты
5.7. ТС 3.1.7 Создание проекта
5.8. ТС 3.1.8 Изменение проекта
5.9. ТС 3.1.9 Удаление проекта
5.10. ТС 3.1.10 Создать тестовый случай или набор
5.11. ТС 3.1.11 Изменить тестовый случай или набор
5.12. ТС 3.1.12 Удалить тестовый случай или набор
5.13. ТС 3.1.13 Показать тест
5.14. ТС 3.1.14 Показать тестовый набор
5.15. ТС 3.1.15 Прогнать одиночный тест
5.16. ТС 3.1.15 Выполнение набора тестов
5.17. ТС 3.1.17 Сводный отчет по ошибкам
5.18. ТС 3.1.18 Результаты тестирования/Одиночный тест
5.19 ТС 3.1.19 Результаты тестирования/Тестовый набор
5.20. ТС 3.1.20 Создать матрицу прослеживаемости
5.21. ТС 3.1.21 Резервное копирование/Тестовые случаи
5.22. ТС 3.1.22 Резервное копирование/Тестовые наборы
5.23. ТС 3.1.23 Резервное копирование/Результаты прогона тестов
5.24. ТС 3.1.24 Восстановление/Тестовые случаи
5.25. ТС 3.1.25 Восстановление/Тестовые наборы
5.26. ТС 3.1.26 Восстановление/Результаты прогона тестов
5.27. ТС 3.1.27 Экспорт/Тестовые случаи
5.28. ТС 3.1.28 Экспорт/Тестовые наборы
5.29. ТС 3.1.29 Экспорт/Результаты прогона тестов
5.30. ТС 3.1.30 Справка
5.31. ТС 3.1.31 Многопользовательские функциональные возможности
Ссылки
Приложение 1 —Списо к аббревиатур
Приложение 2 — Определение терминов
Приложение 3 — Сообщения электронной почты от утверждающих лиц
От: Чак Д. Клут (Chuck D. Klout) [cdklout@tmtco]
От: Сьюзи Перл (Suzie Perl [spent@[Link]]
От: Брит Гейтер (Bret Gater) [bgater@[Link]]

33 4
Спецификация тестовой процедуры ТМТ TMT-TPS-10

1. Введение
Целью создания этого документа является подробное описание тестовых процедур, разработанных
для аттестации функциональных возможностей программного продукта, именуемого набором инст­
рументальных средств управления тестированием (Test Management Toolkit, ТМТ). Свойства, на ко­
торые производятся ссылки в этом документе, находятся в документе определения требований,
именуемого "Набор инструментальных средств управления тестированием, Определение требова­
ний". Документ, определяющий требования, имеет идентификатор TMT-RD-10 и находится под
управлением системы контроля документов на Web-сайте:
http//[Link].соm/usr/www/docstores/desiqn/requirements/[Link]
Разработка тестов основывается на плане тестирования ТМТ, который находится в документе ТМТ-
ТР-10, расположенном на Web-сайте:
httD//[Link]/usr/www/docstores/desian/requirements^[Link]
Проекты тестов описаны в разделе 3, а тестовые процедуры представлены в разделе 5.

2. Свойства, которые должны тестироваться

Для того чтобы удостовериться в том, что программный продукт ТМТ удовлетворяет требованиям,
указанным в спецификации требований ТМТ, необходимо протестировать следующие требования:
• Требование 3.1.1. Пользовательский интерфейс
• Требование 3.1.2. Навигация
• Требование 3.1.3. Аутентификация пользователей — клиент
• Требование 3.1.4. Аутентификация пользователей — администратор
• Требование 3.1.5. Текущие проекты
• Требование 3.1.6. Завершенные проекты
• Требование 3.1.7. Создание нового проекта
• Требование 3.1.8. Изменение проекта
• Требование 3.1.9. Удаление проекта
• Требование 3.1.10. Создание тестового случая или набора
• Требование 3.1.11. Изменение тестового случая или набора
• Требование 3.1.12. Удаление тестового случая или набора
• Требование 3.1.13. Отображение теста
• Требование 3.1.14. Отображение тестового набора
• Требование 3.1.15. Прогон одиночного теста
• Требование 3.1.16. Прогон тестового набора
• Требование 3.1.17. Создание списка прогона
• Требование 3.1.18. Выполнение списка прогона
• Требование 3.1.19. Сводный отчет по ошибкам
• Требование 3.1.20. Результаты тестирования — одиночный тест
• Требование 3.1.21. Результаты тестирования — тестовый набор или список прогона
• Требование 3.1.22. Создание матрицы прослеживаемости
• Требование 3.1.23. Резервное копирование тестовых случаев
• Требование 3.1.24. Резервное копирование тестовых наборов
• Требование 3.1.25. Резервное копирование результатов прогона тестов
• Требование 3.1.26. Восстановление тестовых случаев
335
Спецификация тестовой процедуры ТМТ TMT-TPS-10

• Требование 3.1.27. Восстановление тестовых наборов

• Требование 3.1.28. Восстановление результатов прогона тестов
• Требование 3.1.29. Экспорт тестовых случаев
• Требование 3.1.30. Экспорт тестовых наборов
• Требование 3.1.31. Экспорт результатов прогона тестов
• Требование 3.1.32. Получение справки
• Требование 3.1.33. Многопользовательские функциональные возможности

3. Проекты тестов
Применяемый подход предполагает регрессионное тестирование, а также тестирование функцио­
нальных возможностей, процесса установки, резервного копирования и восстановления и графиче­
ского интерфейса пользователя. Каждый тип тестирования подробно рассматривается в данном
разделе.
Проекты тестов для проверки функциональных возможностей показаны в таблице 3.1. В таблице
приведены идентификаторы требований, идентификаторы тестов, входные данные и конфигурация
для тестов, а также цели прогона каждого теста. Некоторые функциональные возможности, такие как
экспорт данных и экраны справочной системы, вынесены за пределы основной массы тестов функ­
циональных возможностей, поскольку в первой сборке они не реализованы. Эти возможности
рассматриваются в разделе "Дополнительные возможности".

336
Спецификация тестовой процедуры ТМТ TMT-TPS-10

337
Спецификация тестовой процедуры ТМТ TMT-TPS-10

3.1. Регрессионное тестирование

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

3.2. Резервное копирование и восстановление

Функционирование резервного копирования и восстановления тестируется для проектов, тестовых
случаев, тестовых наборов и результатов прогона тестов. При этом должны использоваться как фи­
зические, так и логические устройства, которые являются автономными либо сетевыми. Сетевое
резервное копирование является наиболее предпочтительным сценарием для заказчика, поэтому
ему будет уделяться повышенное внимание.

338
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Проекты тестов для резервного копирования и восстановления показаны в таблице 3.2. В таблице
отражены идентификаторы требований, идентификаторы тестов, входные данные и конфигурация
для тестов, а также цели прогона каждого теста.

3.3. Дополнительные возможности

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

339
Спецификация тестовой процедуры ТМТ TMT-TPS-10

3.4. Установка продукта

Каждая программная сборка, переданная команде тестировщиков, устанавливается в соответствии с
процедурой установки, которую будет использовать заказчик. Однако для каждой сборки модули
клиента и сервера устанавливаются только на подмножестве всех возможных комбинаций платформ
и операционных систем, которые указаны в спецификации требований. Предполагается, что успеш­
ная установка на одной платформе UNIX создает прецедент для успешной установки для всех ос­
тальных UNIX-подобных платформ. То же справедливо и для платформ Windows. Этот подход ут­
вержден у заказчика (см. сообщение электронной почты утверждающего лица из отдела маркетинга).
Для процесса установки какие-либо специальные тестовых случаи не создаются. Причина заклю­
чается в том, что непосредственно за документом по установке продукта, который передается заказ­
чику, следует тестирование. После успешной установки продукта можно приступать к прогону тестов
функциональных возможностей, перечисленных в таблице 3.1.

3.5. Тестирование графического интерфейса пользователя

При тестировании графического интерфейса продукта ТМТ используется следующий подход:
• Графический интерфейс пользователя тестируется в браузерах Netscape Navigator и Microsoft
Internet Explorer. При этом должен быть просмотрен полный состав интерфейса, а также про­
тестированы возможности навигации в обоих браузерах.
• Все действия по тестированию выполняются в ручном режиме.

34 0
Спецификация тестовой процедуры ТМТ TMT-TPS-10

• Все дефекты отслеживаются и устраняются с помощью корпоративной системы отслежива­

ния дефектов. Такой подход предполагает нахождение недоработок в графическом интер­
фейсе пользователя в ходе проведения различных оценок после завершения работы над
проектом.
Какие-то специальные тесты для графического интерфейса пользователя не разрабатываются. При­
чина состоит в том, что применение интерфейса подразумевается во всех тестах свойств, а также в
тестах резервного копирования/восстановления, которые описаны в табл. 3.1, 3.2 и 3.3. Если какой-
либо из этих тестов завершается неудачно, то причина будет связана либо с графическим интер­
фейсом пользователя, либо с функциональными возможностями, которые доступны через этот ин­
терфейс.

4. Информация о конфигурации тестов

Проекты тестов, перечисленные в таблицах 3.1, 3.2 и 3.3, связаны со специальными тестовыми
конфигурациями. Диаграммы тестовых конфигураций # 1 и # 2 находятся в плане тестирования ТМТ,
документ ТМТ-ТР-08.

5. Тестовые случаи
В разделе представлены процедуры для всех тестов, приведенных таблицах 3.1, 3.2 и 3.3. Каждый
тестовый случай должен выполняться в Netscape Navigator, а затем повторно в Microsoft Internet Ex­
plorer.

5.1. ТС 3.1.1 Пользовательский интерфейс

Сервер приложений должен иметь имя и IP-адрес. Для целей тестирования имени приложения и
серверу присваивается псевдоним "ТМТ".

Случай 1
Запустите Netscape Navigator. Введите URL-адрес "ТМТ" и нажмите клавишу "Enter".
Ожидаемый результат:
Отображается главное меню ТМТ.

5.2. ТС 3.1.2 Навигация

Случай 1
Запустите Netscape Navigator. Введите URL-адрес "ТМТ" и нажмите "Enter".
Ожидаемый результат:
Отображается главное меню ТМТ (Toolkit Main Menu).

Случай 2
Меню должно содержать "кнопки" или ссылки на другие страницы. Главное меню должно содержать
следующие ссылки:
Current Projects (Текущие проекты)
Completed Projects (Завершенные проекты)
Project Maintenance (Сопровождение проекта)
Test Case Maintenance (Сопровождение тестовых случаев)
Test Case Execution (Выполнение тестовых случаев)
Test Results (Результаты тестирования)
Utilities (Утилиты)
Help (Справка)
Ожидаемый результат:
Меню имеет описанные выше метки.

341
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Случай 3
Выберите в главном меню ПУНКТ "Current Prelects" ("Текущие проекты").
Ожидаемый результат 1:
Отображается экран, озаглавленный "Current Projects"("Teкущиe проекты"), который содержит проект
или несколько проектов.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие текущих проектов (если данный
тестовый случай выполняется до создания проектов).
В окне браузера щелкните на стрелке назад для возврата в главное меню.
Ожидаемый результат 3:
Пользователь должен вернуться в главное меню.

Случай 4
В главном меню выберите ПУНКТ "Completed Projects" ("Завершенные проекты").
Ожидаемый результат 1:
Отображается экран с заголовком "Completed Projects"("3aвершенніе проекты"), который содержит
проект или несколько проектов.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие текущих проектов (если данный
тестовый случай выполняется до создания проектов).
В окне браузера щелкните на стрелке назад для возврата в главное меню.
Ожидаемый результат 3:
Пользователь должен вернуться в главное меню.

Случай 5
В главном меню выберите пункт "Project Maintenance" ("Сопровождение проекта").
Ожидаемый результат 1:
Отображается экран с заголовком "Project Маintenanсе"("Сопровождение проекта").
Ожидаемый результат 2:
Должны стать доступными следующие пункты:
Create New Project (Создать новый проект)
Modify Project (Изменить проект)
Remove Project (Удалить проект)
Help (Справка)

Случай 6
В меню Project Maintenance выберите ПУНКТ "Create New Project" ("Создать новый проект").
Ожидаемый результат 1:
Появляется экран с запросом имени создаваемого проекта.
В окне браузера щелкните на стрелке назад для возврата в меню Project Maintenance.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Project Maintenance.

Случай 7
В меню Project Maintenance выберите ПУНКТ "Modify Project" ("Изменить проект").
Ожидаемый результат 1:
На экране появляется запрос имени изменяемого проекта, а также выводится список доступных про­
ектов.

342
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 2:
Появляется сообщение об ошибке, указывающее на отсутствие проектов, доступных для изменения
(если данный тест выполняется до создания проектов).
В окне браузера щелкните на стрелке назад для возврата в меню Project Maintenance.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Project Maintenance.

Случай 8:
В меню Project Maintenance выберите ПУНКТ "Remove Project" ("Удалить проект").
Ожидаемый результат 1:
На экране появляется запрос имени удаляемого проекта, а также выводится список доступных про­
ектов.
Ожидаемый результат 2:
Появляется сообщение об ошибке, указывающее на отсутствие проектов, доступных для удаления
(если данный тест выполняется до создания проектов).
В окне браузера щелкните на стрелке назад для возврата в меню Project Maintenance.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Project Maintenance.

Случай 9
В меню Project Maintenance выберите ПУНКТ "Help" ("Справка").
Ожидаемый результат 1:
Отображается экран с подробным описанием всех пунктов меню Project Maintenance (в следующих
версиях программы будет реализована контекстно-зависимая справочная система с индексами и
возможностью поиска).
В окне браузера щелкните на стрелке назад для возврата в меню Project Maintenance.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Project Maintenance.

Случай 10
В главном меню выберите ПУНКТ "Test Case Maintenance" ("Сопровождение тестовых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком "Test Case Maintenance" ("Сопровождение тестовых случаев").
Ожидаемый результат 2:
Должны стать доступными следующие пункты:
Create Test Case or Suite (Создать тестовый случай или набор)
Modify Test Case or Suite (Изменить тестовый случай или набор)
Remove Test Case or Suite (Удалить тестовый случай или набор)
Display Test (Показать тест)
Display Suite (Показать тестовый набор)
Help (Справка)

Случай 11
В меню Test Case Maintenance выберите ПУНКТ "Create Test Case or Suite" ("Создать тестовый случай
или набор").
Ожидаемый результат 1:
На экране появляется запрос имени проекта, для которого создается новый тестовый случай или
набор. Пользователь может дважды щелкнуть на имени существующего проекта.

343
Сп е ц иф ика ц и я тестово й процедур ы Т М Т TMT-TPS-10

Ожидаемый результат 2:
Пользователь получает запрос на выбор между опциями Test (Тест) или Suite (Набор). Если выбрана
опция Suite (Набор), поступает запрос об имени набора. Если выбрана опция Test (Тест), выдается
запрос об имени тестового случая. В этот момент должен отобразиться экран, на котором будут вно­
ситься данные, связанные с тестом.

Случай 12
В меню Test Case Maintenance выберите ПУНКТ "Modify Test Case or Suite" ("Изменить тестовый слу­
чай или набор").
Ожидаемый результат 1:
На экране появляется запрос об имени проекта, содержащего тестовый случай или набор, которые
необходимо изменить. Пользователь может дважды щелкнуть на имени существующего проекта.
Ожидаемый результат 2:
Если проект идентифицирован, пользователь получает запрос на выбор между опциями Test (Тест)
или Suite (Набор).
Если пользователь выбирает опцию Suite (Набор), поступает запрос на ввод имени тестового набо­
ра. Пользователь может дважды щелкнуть на имени существующего тестового набора.
Ожидаемый результат 3:
Отображается экран, указывающий, что доступные для изменения тестовые наборы отсутствуют
(если этот тест выполняется до создания тестовых наборов).
Ожидаемый результат 4:
Если пользователь выбирает опцию Test (Тест), выдается запрос на ввод имени теста, который не­
обходимо обновить. Пользователь может дважды щелкнуть на имени существующего проекта.
Ожидаемый результат 5:
Отображается экран, указывающий, что доступные для обновления тесты отсутствуют (если этот
тест выполняется до создания тестовых случаев).
В окне браузера щелкните на стрелке назад для возврата в меню Test Case Maintenance.
Ожидаемый результат 6:
Пользователь должен вернуться в меню Test Case Maintenance.

Случай 13
В меню Test Case Maintenance выберите ПУНКТ "Remove Test Case or Suite" ("Удалить тестовый слу­
чай или набор").
Ожидаемый результат 1:
На экране появляется запрос об имени проекта, содержащего тестовый случай или набор, которые
необходимо удалить. Пользователь может дважды щелкнуть на имени существующего проекта.
Ожидаемый результат 2:
Если проект идентифицирован, пользователь получает запрос на выбор между опциями Test (Тест)
или Suite (Набор).
Если пользователь выбирает опцию Suite (Набор), поступает запрос на ввод имени тестового набо­
ра. Пользователь может дважды щелкнуть на имени существующего тестового набора.
Ожидаемый результат 3:
Отображается экран, указывающий, что доступные для удаления тестовые наборы отсутствуют (ес­
ли этот тест выполняется до создания тестовых наборов).
Ожидаемый результат 4:
Если пользователь выбирает опцию Test (Тест), выдается запрос на ввод имени теста, который не­
обходимо удалить. Пользователь может дважды щелкнуть на имени существующего проекта.

344
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 5:
Отображается экран, указывающий, что доступные для удаления тесты отсутствуют (если этот тест
выполняется до создания тестовых случаев).
В окне браузера щелкните на стрелке назад для возврата в меню Test Case Maintenance.
Ожидаемый результат 6:
Пользователь должен вернуться в меню Test Case Maintenance.

Случай 14
В меню Test Case Maintenance выберите пункт "Help" ("Справка").
Ожидаемый результат 1:
Отображается экран с подробным описанием всех пунктов меню Test Case Maintenance (в следую­
щих версиях программы будет реализована контекстно-зависимая справочная система с индексами
и возможностью поиска).
В окне браузера щелкните на стрелке назад для возврата в меню Test Case Maintenance.

Случай 15
В меню Test Case Maintenance выберите пункт "Display Test" ("Показать тест").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени теста, который необходимо отобразить (просмотреть).
Ниже этого запроса находится список всех доступных тестов. Пользователь может дважды щелкнуть
на требуемом тестовом случае.
Ожидаемый результат 2:
Появляется экран с сообщением о том, что доступные для просмотра тестовые случаи отсутствуют
(если тест выполняется до создания тестовых случаев).

Случай 16
В меню Test Case Maintenance выберите пункт "Display Suite" ("Показать тестовый набор").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени тестового набора, который необходимо отобразить
(просмотреть). Ниже этого запроса находится список всех доступных тестов. Пользователь может
дважды щелкнуть на требуемом тестовом наборе.
Ожидаемый результат 2:
Появляется экран с сообщением о том, что доступные для просмотра тестовые наборы отсутствуют
(если тест выполняется до создания тестовых наборов).

Случай 17
В меню Test Case Maintenance выберите ПУНКТ "Help" ("Справка").
Ожидаемый результат 1:
Отображается экран с подробным описанием всех пунктов меню Test Case Maintenance (в следую­
щих версиях программы будет реализована контекстно-зависимая справочная система с индексами
и возможностью поиска).
В окне браузера щелкните на стрелке назад для возврата в меню Test Case Maintenance.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Test Case Maintenance.

Случай 18
В главном меню ТМТ выберите пункт "Test Case Execution" ("Выполнение тестовых случаев").
Ожидаемый результат:
Отображается экран с заголовком "Test Case Execution Menu" ("Меню выполнения тестовых случа­
ев"). На экране должны присутствовать следующие пункты меню:

345
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Run Single Test (Прогнать одиночный тест)

Run Suite (Прогнать тестовый набор)
Create Run List (Создать список прогона)
Execute Run List (Выполнить список прогона)
Help (Справка)

Случай 19
В меню Test Case Execution выберите ПУНКТ "Run Single Test" ("Прогнать одиночный тест").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени тестового случая, который требуется выполнить. Ниже
этого запроса выводится список доступных тестовых случаев. Пользователь имеет возможность
ввести имя прогоняемого тестового случая или дважды щелкнуть на существующем имени.
Ожидаемый результат 2:
Отображается экран с сообщением об отсутствии ранее созданных тестовых случаев (если тест
выполняется до создания тестовых случаев).
Щелкните на стрелке назад в браузере.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Test Case Execution.

Случай 20
В меню Test Case Execution выберите пункт "Run Suite Case" ("Прогнать тестовый набор").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени тестового набора, который необходимо выполнить.
Ниже этого запроса выводится список доступных тестовых наборов. Пользователь имеет возмож­
ность ввести имя прогоняемого тестового набора или дважды щелкнуть на существующем имени.
Ожидаемый результат 2:
Отображается экран с сообщением об отсутствии созданных тестовых наборов (если тест выполня­
ется до создания тестовых наборов).
Щелкните на стрелке назад в браузере.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Test Case Execution.

Случай 21
В меню Test Case Execution выберите ПУНКТ "Create Run List" ("Создать список прогона").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени создаваемого списка прогона. Ниже этого запроса
отображаются имена доступных списков прогона.
Щелкните на стрелке назад в браузере.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Test Case Execution.

Случай 22
В меню Test Case Execution выберите ПУНКТ "Execute Run List" ("Выполнить список прогона").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени списка прогона, который необходимо выполнить. Ниже
этого запроса отображаются имена доступных списков прогона.
Щелкните на стрелке назад в браузере.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Test Case Execution.

346
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Случай 23
В меню Test Case Execution выберите пункт "Help" ("Справка").
Ожидаемый результат 1:
Отображается экран с подробным описанием всех пунктов меню Test Case Maintenance (в следую­
щих версиях программы будет реализована контекстно-зависимая справочная система с индексами
и возможностью поиска).
В окне браузера щелкните на стрелке назад для возврата в меню Test Case Execution.
Снова щелкните на стрелке назад в браузере.
Ожидаемый результат 2:
Пользователь должен вернуться в главное меню Test Management Toolkit.

Случай 24
В главном меню Test Management Toolkit выберите ПУНКТ "Test Results" ("Результаты тестирования").
Ожидаемые результаты:
Пользователь должен получить доступ на экран с заголовком Test Results Menu (Меню результатов
тестирования).

Случай 25:
В меню Test Results выберите ПУНКТ "Bug Summary" ("Сводный отчет по ошибкам").
Ожидаемый результат 1:
Это самое высокоуровневое визуальное представление, поэтому пользователю выдается запрос на
ввод имени анализируемого проекта. Ниже этого запроса отображается список доступных проектов,
как текущих, так и завершенных. Пользователь имеет возможность ввести имя проекта или же про­
сто дважды щелкнуть на существующем имени.
Если пользователь выбирает прошлый или текущий проект, отображается экран, на котором
выводится общее количество тестов, успешно и неудачно пройденных тестов, заблокированных
тестов, общие затраты времени, а также дата прогона.
Ожидаемый результат 2:
Отображается экран с сообщением об отсутствии доступных результатов тестирования (если тест
выполняется до выполнения или завершения проекта).
В окне браузера щелкните на стрелке назад для возврата в меню Test Results.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Test Results.

Случай 26
В меню Test Results выберите ПУНКТ "Single Test" ("Одиночный тест").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени тестового случая, который необходимо проанализиро­
вать. Ниже этого запроса выводится список всех доступных тестовых случаев, которые уже выпол­
нены. Пользователь имеет возможность ввести имя теста или просто дважды щелкнуть на сущест­
вующем имени.
Ожидаемый результат 2:
Отображается экран с сообщением об отсутствии доступных результатов тестирования (если тест
выполняется до выполнения или завершения тестового случая).
В окне браузера щелкните на стрелке назад для возврата в меню Test Results.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Test Results.

347
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Случай 27
В меню Test Results выберите ПУНКТ "Suite or Run List" ("Тестовый набор или список прогона").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени тестового набора, который необходимо проанализи­
ровать. Ниже этого запроса выводится список всех доступных тестовых наборов, которые уже вы­
полнены. Пользователь имеет возможность ввести имя тестового набора или просто дважды щелк­
нуть на существующем имени.
Ожидаемый результат 2:
Отображается экран с сообщением об отсутствии доступных результатов тестирования (если тест
выполняется до выполнения или завершения тестового набора).
В окне браузера щелкните на стрелке назад для возврата в меню Test Results.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Test Results.
В окне браузера щелкните на стрелке назад для возврата в главное меню Test Management Toolkit.
Ожидаемый результат 4:
Пользователь должен вернуться в главное меню Test Management Toolkit.

Случай 28
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемые результаты:
Пользователь получает доступ на экран с заголовком Utilities Main Menu (Меню утилит), в котором
доступны следующие пункты:
Create Trace Matrix (Создать матрицу прослеживаемости)
Backup Project (Резервное копирование проекта)
Backup Test Suite (Резервное копирование тестового набора)
Backup Test Case (Резервное копирование тестового случая)
Backup Test Results (Резервное копирование результатов прогона теста)
Restore Project (Восстановление проекта)
Restore Test Suite (Восстановление тестового набора)
Restore Test Case (Восстановление тестового случая)
Restore Test Results (Восстановление результатов прогона теста)
Export Project (Экспорт проекта)
Export Test Suite (Экспорт тестового набора)
Export Test Case (Экспорт тестового случая)
Export Test Results (Экспорт результатов прогона теста)
Help (Справка)

Случай 29
В меню Utilities выберите пункт "Create Trace Matrix" ("Создать матрицу прослеживаемости").
Ожидаемый результат 1:
Пользователь получает запрос на ввод имени документа описания требований для его анализа. Ни­
же этого запроса отображается список всех доступных документов описания требований. Пользова­
тель имеет возможность ввести имя или дважды щелкнуть на существующем имени. После выбора
документов на экран выводится созданная матрица прослеживаемости, которую можно вывести на
принтер или экспортировать в формат электронной таблицы.
Ожидаемый результат 2:
Пользователь получает сообщение об ошибке, указывающее, что каталог по умолчанию не содержит
документов описания требований. Причина связана с тем, что документы либо не создавались, либо
не находятся в нужном каталоге.
В окне браузера щелкните на стрелке назад для возврата в меню Utilities.

348
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 30
В меню Utilities выберите пункт "Backup Project" ("Резервное копирование проекта").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Project Backup (Резервное копирование проек­
та). После этого отображается запрос на ввод имени копируемого проекта со списком всех доступ­
ных проектов. Пользователь имеет возможность ввести имя проекта или дважды щелкнуть на суще­
ствующем имени. После идентификации проекта отображается запрос на ввод местоположения ре­
зервной копии.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее, что доступные для резервного копирования
проекты отсутствуют. Причиной может заключаться в том, что не было создано ни одного проекта.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 31
В меню Utilities выберите ПУНКТ "Backup Test Suite" ("Резервное копирование тестового набора").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Suite Backup (Резервное копирование тестово­
го набора). Отображается запрос на ввод имени копируемого тестового набора. Под этим запросом
выводится список всех доступных тестовых наборов. Пользователь имеет возможность ввести имя
тестового набора или дважды щелкнуть на существующем имени. После идентификации тестового
набора отображается запрос на ввод местоположения резервной копии.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее, что доступные для резервного копирования
тестовые наборы отсутствуют. Причиной может заключаться в том, что не было создано ни одного
тестового набора.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 32
В меню Utilities выберите пункт "Backup Test Case" ("Резервное копирование тестового случая").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Test Case Backup (Резервное копирование
тестового случая). Отображается запрос на ввод имени копируемого тестового случая. Под этим
запросом выводится список всех доступных тестовых случаев. Пользователь имеет возможность
ввести имя тестового случая или дважды щелкнуть на существующем имени. После идентификации
тестового случая отображается запрос на ввод местоположения резервной копии.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее, что доступные для резервного копирования
тестовые случаи отсутствуют. Причиной может заключаться в том, что не было создано ни одного
тестового случая.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

349
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Случай 33
В меню Utilities выберите ПУНКТ "Backup Test Results" ("Резервное копирование результатов прогона
теста").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Test Results Backup (Резервное копирование
результатов прогона теста). Отображается запрос на ввод имени копируемых результатов прогона
теста. Под этим запросом выводится список всех доступных результатов прогона тестов. Пользова­
тель имеет возможность ввести имя результатов прогона теста или дважды щелкнуть на сущест­
вующем имени. После идентификации результатов прогона теста отображается запрос на ввод ме­
стоположения резервной копии.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее, что доступные для резервного копирования
результаты прогона тестов отсутствуют. Причиной может заключаться в том, что не было получено
ни одного результата прогона тестов.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 34:
В меню Utilities выберите пункт "Restore Project" ("Восстановление проекта").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Restore Project (Восстановление проекта). Вы­
дается запрос на ввод имени резервной копии для восстановления. После идентификации резервной
копии пользователь получает запрос на ввод местоположения, куда требуется восстановить резерв­
ную копию. Поддерживается информация по умолчанию.
В окне браузера щелкните на стрелке назад для возврата в меню Utilities.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Utilities.

Случай 35
В меню Utilities выберите пункт "Restore Test Suite" ("Восстановление тестового набора").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Restore Test Suite (Восстановление тестового
набора). Выдается запрос на ввод имени резервной копии для восстановления. После идентифика­
ции резервной копии пользователь получает запрос на ввод местоположения, куда требуется вос­
становить резервную копию. Поддерживается информация по умолчанию.
В окне браузера щелкните на стрелке назад для возврата в меню Utilities.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Utilities.

Случай 36
В меню Utilities выберите пункт "Restore Test Case" ("Восстановление тестового случая").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Restore Test Case (Восстановление тестового
случая). Выдается запрос на ввод имени резервной копии для восстановления. После идентифика­
ции резервной копии пользователь получает запрос на ввод местоположения, куда требуется вос­
становить резервную копию. Поддерживается информация по умолчанию.
В окне браузера щелкните на стрелке назад для возврата в меню Utilities.

35 0
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 2:
Пользователь должен вернуться в меню Utilities.

Случай 37
В главном меню Utilities выберите пункт "Restore Test Results" ("Восстановление результатов прогона
теста").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Restore Test Results (Восстановление резуль­
татов прогона теста). Выдается запрос на ввод имени резервной копии для восстановления. После
идентификации резервной копии пользователь получает запрос на ввод местоположения, куда тре­
буется восстановить резервную копию. Поддерживается информация по умолчанию.
В окне браузера щелкните на стрелке назад для возврата в меню Utilities.
Ожидаемый результат 2:
Пользователь должен вернуться в меню Utilities.

Случай 38
В меню Utilities выберите пункт Export Project (ЭКСПОРТ проекта).
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Export Project (Экспорт проекта). Отображается
запрос на ввод имени проекта, который необходимо экспортировать. Ниже этого запроса выводится
список всех доступных проектов. Пользователь имеет возможность ввести имя проекта или дважды
щелкнуть на существующем имени. После идентификации проекта пользователь получает запрос о
том, куда следует поместить экспортированный проект.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие проектов, доступных для экспорта.
Причина может заключаться в том, что ни один проект еще не создавался.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 39
В меню Utilities выберите пункт "Export Test Suite" ("Экспорт тестового набора").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Export Test Suite (Экспорт тестового набора).
Отображается запрос на ввод имени тестового набора, который необходимо экспортировать. Ниже
этого запроса выводится список всех доступных тестовых наборов. Пользователь имеет возмож­
ность ввести имя тестового набора или дважды щелкнуть на существующем имени. После иденти­
фикации тестового набора пользователь получает запрос о том, куда следует поместить экспортиро­
ванный тестовый набор.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие тестовых наборов, доступных для
экспорта. Причина может заключаться в том, что ни один тестовый набор еще не создавался.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 40
В меню Utilities выберите ПУНКТ "Export Test Case" ("ЭКСПОРТ тестового случая").

351
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Export Test Case (Экспорт тестового случая).
Отображается запрос на ввод имени тестового случая, который необходимо экспортировать. Ниже
этого запроса выводится список всех доступных тестовых случаев. Пользователь имеет возможность
ввести имя тестового случая или дважды щелкнуть на существующем имени. После идентификации
тестового случая пользователь получает запрос о том, куда следует поместить экспортированный
тестовый случай.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие тестовых случаев, доступных для
экспорта. Причина может заключаться в том, что ни один тестовый случай еще не создавался.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 41
В меню Utilities выберите пункт "Export Test Results" ("Экспорт результатов прогона теста").
Ожидаемый результат 1:
Пользователь получает доступ на экран с заголовком Export Test Results (Экспорт результатов про­
гона теста). Отображается запрос на ввод имени результатов прогона теста, которые необходимо
экспортировать. Ниже этого запроса выводится список всех доступных результатов прогона теста.
Пользователь имеет возможность ввести имя результатов прогона теста или дважды щелкнуть на
существующем имени. После идентификации результатов прогона теста пользователь получает
запрос о том, куда следует поместить их экспортированную версию.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие результатов прогона теста, дос­
тупных для экспорта. Причина может заключаться в том, что ни один результат прогона теста еще не
был получен.
В окне браузера щелкните на стрелке назад для возврата в главное меню Utilities.
Ожидаемый результат 3:
Пользователь должен вернуться в меню Utilities.

Случай 42
В главном меню Utilities выберите опцию Help.
Ожидаемый результат 1:
Отображается экран с подробным описанием всех пунктов меню Utilities (в следующих версиях про­
граммы будет реализована контекстно-зависимая справочная система с индексами и возможностью
поиска).
В окне браузера щелкните на стрелке назад для возврата в меню Utilities.
Снова щелкните в окне броузера на стрелке назад для возврата в главное меню Test Management
Toolkit.
Ожидаемый результат 2:
Пользователь должен вернуться в главное меню Test Management Toolkit.

5.3. ТС 3.1.3 Аутентификация пользователей — к л и е н т

Для проведения этого теста создаются следующие учетные записи:

352
С п е ц и ф и к а ц и я тестово й процедур ы Т М Т TMT-TPS-10

Идентификатор
пользователя Пароль
Admin Admin
User1 password
User2 password
User3 password
User4 password
User5 password

Случай 1
После набора в адресной строке браузера ТМТ и нажатия клавиши Enter пользователь должен полу­
чить запрос на ввод имени и пароля. Инициируйте процесс регистрации, набрав в строке псевдоним
ТМТ и нажав клавишу Enter.
Ожидаемый результат 1:
В центре экрана открывается окно с запросом User Name (Имя пользователя) и Password (Пароль).
Введите "User9" и нажмите клавишу Enter, не набирая пароль.
Ожидаемый результат 2:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "User9" для имени пользователя, а в качестве пароля введите "password".
Ожидаемый результат 3:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "User1" для имени пользователя, а в качестве пароля укажите "pickle".
Ожидаемый результат 4:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "User1" для имени пользователя, а в качестве пароля укажите "password".
Ожидаемый результат 5:
Отображается главное меню Test Management Toolkit.

5.4. ТС 3.1.4 Аутентификация пользователей —администратор

Клиентская сторона
Случай 1
После набора в адресной строке браузера ТМТ и нажатия клавиши Enter пользователь должен полу­
чить запрос на ввод имени и пароля. Инициируйте процесс регистрации, набрав в строке псевдоним
ТМТ и нажав клавишу Enter.
Ожидаемый результат 1:
В центре экрана открывается окно с запросом User Name (Имя пользователя) и Password (Пароль).
Введите "User9" и нажмите клавишу Enter, не набирая пароль.
Ожидаемый результат 2:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "User9" для имени пользователя, а в качестве пароля укажите "password".
Ожидаемый результат 3:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
353
С п е ц и ф и к а ц и я тестов о й процедур ы Т М Т TMT-TPS-10

Введите "User1" для имени пользователя, а в качестве пароля укажите "pickle".

Ожидаемый результат 4:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "Admin" для имени пользователя, а в качестве пароля укажите "Admin".
Ожидаемый результат 5:
Отображается главное меню Test Management Toolkit.

Серверная сторона
Случай 2
После набора в адресной строке браузера TMTADMIN и нажатия клавиши Enter пользователь дол­
жен получить запрос на ввод имени и пароля. Инициируйте процесс регистрации, набрав в строке
псевдоним TMTADMIN и нажав клавишу Enter.
Ожидаемый результат 1:
В центре экрана открывается окно с запросом User Name (Имя пользователя) и Password (Пароль).
Введите "User9" и нажмите клавишу Enter, не набирая пароль.
Ожидаемый результат 2:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "User9" для имени пользователя, а в качестве пароля укажите "password".
Ожидаемый результат 3:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "User1" для имени пользователя, а в качестве пароля укажите "pickle".
Ожидаемый результат 4:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "Admin" для имени пользователя, а в качестве пароля укажите "Admin".
Ожидаемый результат 5:
Отображается главное меню Test Management Toolkit.

5.5. ТС 3.1.5 Текущие проекты

После регистрации в системе пользователь имеет возможность просматривать текущие проекты,
Для этого необходимо из главного меню Test Management Toolkit выбрать пункт "Current Projects"
("Текущие проекты").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Current Projects" ("Текущие проекты").
Ожидаемый результат:
Отображается экран с заголовком Current Projects (Текущие проекты). С именами проектов связано
общее количество тестов, количество пройденных тестов, а также количество сбойных, заблокиро­
ванных и прошедших тестов. Если тесты уже прогнаны и соответствующие данные собраны, для
проектов отображается также время, оставшееся до конца тестирования, и общее время вы­
полнения.

5.6. ТС 3.1.6 Завершенные проекты

После регистрации в системе пользователь имеет возможность просматривать текущие проекты.
Для этого необходимо из главного меню Test Management Toolkit выбрать пункт "Completed Projects"
("Завершенные проекты").

354
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Случай 1
В главном меню Test Management Toolkit выберите пункт "Completed Projects" ("Завершенные про­
екты").
Ожидаемый результат:
Отображается экран с заголовком Completed Projects (Завершенные проекты). С именами проектов
связано общее количество тестов, количество пройденных тестов, а также количество сбойных, за­
блокированных и прошедших тестов. Отображается также и общее время в часах и минутах.

5.7. ТС 3.1.7 Создание проекта

После регистрации в системе пользователь имеет возможность создавать новые проекты. Для этого
необходимо в меню Project Maintenance выбрать пункт "Create New Project" ("Создать новый проект").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Project Maintenance" ("Сопровождение про­
екта").
Ожидаемый результат 1:
Отображается экран с пунктами меню Project Maintenance (Сопровождение проекта).
В меню Project Maintenance (Сопровождение проекта) выберите пункт "Create New Project" ("Создать
новый проект").
Ожидаемый результат 2:
Пользователю выдается запрос на ввод имени нового проекта. После ввода имени нового проекта
отображается запрос о добавлении индивидуальных тестовых случаев или наборов.
Пользователь имеет возможность просматривать список доступных тестовых случаев и наборов.
Пользователь имеет возможность выбирать любой тестовый случай или набор, а также выбирать
все тестовые случаи или наборы.
По завершении выбора появляется возможность сохранить проект (Save) или отменить действия
(Cancel).
Независимо от выбранной опции пользователь возвращается в меню Project Maintenance.

5.8. ТС 3.1.8 Изменение проекта

После регистрации в системе пользователь имеет возможность изменять проекты. Для этого необ­
ходимо в меню Project Maintenance выбрать пункт "Modify Project" ("Изменить проект").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Project Maintenance" ("Сопровождение про­
екта").
Ожидаемый результат 1:
Отображается экран с пунктами меню Project Maintenance (Сопровождение проекта).
В меню Project Maintenance выберите пункт "Modify Project" ("Изменить проект").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени проекта, который требуется изменить.
Пользователь также получает список всех доступных проектов.
Пользователь имеет возможность водить имя изменяемого проекта или просто дважды щелкать на
существующем имени.
После внесения изменений в проект появляется возможность сохранить проект (Save) или отменить
действие (Cancel).
Независимо от выбранной опции пользователь возвращается в меню Project Maintenance.

355
Спецификация тестовой процедуры ТМТ TMT-TPS-10

5.9. ТС 3.1.9 Удаление проекта

После регистрации в системе пользователь имеет возможность удалять проекты. Для этого необхо­
димо в меню Project Maintenance выбрать пункт "Remove Project" ("Удалить проект").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Project Maintenance" ("Сопровождение про­
екта").
Ожидаемый результат 1:
Отображается экран с пунктами меню Project Maintenance (Сопровождение проекта).
В меню Project Maintenance выберите пункт "Remove Project" ("Удалить проект").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени проекта, который требуется удалить.
Пользователь также получает список всех доступных проектов.
Пользователь имеет возможность водить имя удаляемого проекта или просто дважды щелкать на
существующем имени.
Далее пользователь возвращается в меню Project Maintenance.

5.10. ТС 3.1.10 Создать тестовый случай или набор

После регистрации в системе пользователь имеет возможность создавать тестовые случаи. Для
этого необходимо в меню Test Case Maintenance выбрать пункт "Create Test Case or Suite" ("Создать
тестовый случай или набор").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Case Maintenance" ("Сопровождение
тестовых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком Test Case Maintenance (Сопровождение тестовых случаев).
Выберите пункт "Create Test Case or Suite" ("Создать тестовый случай или набор").
Ожидаемый результат 2:
Пользователь получает запрос на выбор между созданием тестового случая (Test Case) или тестово­
го набора (Test Suite).
После того, как пользователь определился с тем, что создает, выдается запрос на ввод имени теста.
После ввода имени тестового случая или набора появляется экран ввода данных.
Ожидаемый результат 3:
Отображается форма для ввода данных.
После ввода всей необходимой информации, связанной с тестом, пользователю предоставляется
возможность сохранить тест (Save) или отменить действие (Cancel).
Независимо от выбранной опции, пользователь возвращается в меню Test Case Maintenance.

5.11. ТС 3.1.11 Изменить тестовый случай или набор

После регистрации в системе пользователь получает возможность изменять тестовые случаи. Для
этого необходимо в меню Test Case Maintenance выбрать пункт "Modify Test Case or Suite" ("Изменить
тестовый случай или набор").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Case Maintenance" ("Сопровождение
тестовых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком Test Case Maintenance (Сопровождение тестовых случаев).
Выберите пункт "Modify Test Case or Suite" ("Изменить тестовый случай или набор").
356
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая или набора, который требуется из­
менить. Отображается список всех доступных тестовых случаев и наборов. Пользователь имеет
возможность ввести имя тестового случая или набора либо дважды щелкнуть на существующем
имени.
Ожидаемый результат 3:
После выполнения всех необходимых действий пользователю предоставляется возможность сохра­
нить изменения (Save) или отменить действия (Cancel).
Независимо от выбранной опции, пользователь возвращается в меню Test Case Maintenance.

5.12. ТС 3.1.12 Удалить тестовый случай или набор

После регистрации в системе пользователь получает возможность удалять тестовые случаи. Для
этого необходимо в меню Test Case Maintenance выбрать пункт "Remove Test Case or Suite" ("Уда­
лить тестовый случай или набор").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Case Maintenance" ("Сопровождение
тестовых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком Test Case Maintenance (Сопровождение тестовых спучаев).
Выберите пункт "Remove Test Case or Suite" ("Удалить тестовый случай или набор").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая или набора, который требуется уда­
лить. Отображается список всех доступных тестовых случаев и наборов. Пользователь имеет воз­
можность ввести имя тестового случая или набора либо дважды щелкнуть на существующем имени
для удаления.
Ожидаемый результат 3:
Независимо от выбранной опции, пользователь возвращается в меню Test Case Maintenance.

5.13. ТС 3.1.13 Показать тест

После регистрации в системе пользователь получает возможность отображать (просматривать) тес­
товые случаи. Для этого необходимо в меню Test Case Maintenance выбрать пункт "Display Test Case
or Suite" ("Показать тестовый случай или набор").

Случай 1
В главном меню Test Management Toolkit выберите ПУНКТ "Test Case Maintenance" ("Сопровождение
тестовых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком Test Case Maintenance (Сопровождение тестовых случаев).
Выберите пункт "Display Test Case or Suite" ("Показать тестовый случай или набор").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая или набора, который требуется ото­
бразить. Выводится список всех доступных тестовых случаев и наборов. Пользователь имеет воз­
можность ввести имя тестового случая или набора либо дважды щелкнуть на существующем имени.
Тестовый случай отображается в режиме только для чтения в том же формате, в котором он вво­
дился.
По завершении работы пользователю возвращается в меню Test Case Maintenance.

357
Спецификация тестовой процедуры ТМТ TMT-TPS-10

5.14. ТС 3.1.14 Показать тестовый набор

После регистрации в системе пользователь получает возможность отображать (просматривать) тес­
товые наборы. Для этого необходимо в меню Test Case Maintenance выбрать пункт "Display Test Case
or Suite" ("Показать тестовый случай или набор").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Case Maintenance" ("Сопровождение
тестовых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком Test Case Maintenance (Сопровождение тестовых случаев).
Выберите пункт "Display Test Case or Suite" ("Показать тестовый случай или набор").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового набора, который требуется отобразить. Вы­
водится список всех доступных тестовых наборов. Пользователь имеет возможность ввести имя
тестового набора либо дважды щелкнуть на существующем имени.
Не экране отображаются тестовые случаи, которые входят в набор. Пользователь имеет воз­
можность по двойному щелчку на тестовом случае просматривать связанную с ним информацию.
По завершении работы пользователю возвращается в меню Test Case Maintenance.

5.15. ТС 3.1.15 Прогнать одиночный тест

После регистрации в системе пользователь получает возможность прогонять тестовые случаи. Для
этого необходимо в меню Test Case Execution (Выполнение тестовых случаев) выбрать пункт "Run
Single Test" ("Прогнать одиночный тест").

Случай 1
В главном меню Test Management Toolkit выберите опцию "Test Case Execution" ("Выполнение тесто­
вых случаев").
Ожидаемый результат 1:
Отображается экран с заголовком Test Case Execution (Выполнение тестовых случаев).
Выберите пункт "Run Single Test" ("Прогнать одиночный тест").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая, который необходимо прогнать. Ото­
бражается список всех доступных тестовых случаев. Пользователь имеет возможность ввести имя
тестового случая или набора или дважды щелкнуть на существующем имени.
Ожидаемый результат 3:
Отображаются детальные шаги выбранного тестового случая. Пользователь выполняет указанные
задания, описанные в тестовом случае. Далее пользователь должен выбрать один из следующих
вариантов:
• Тест прошел, тест не прошел или тест заблокирован и прогнан быть не может.
• После выбора пользователем одного из вариантов выполняется возврат в меню Test Case
Execution.

5.16. ТС 3.1.15 Выполнение набора тестов

После регистрации в системе пользователь получает возможность прогонять тестовые наборы. Для
этого необходимо в меню Test Execution выбрать пункт "Run Suite" ("Прогнать тестовый набор").

Случай 1
В главном меню Test Management Toolkit выберите опцию "Test Case Execution" ("Выполнение тесто­
вых случаев").

358
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 1:
Отображается экран с заголовком Test Case Execution (Выполнение тестовых случаев).
Выберите пункт "Run Suite" ("Прогнать тестовый набор").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового набора, который необходимо прогнать. Ото­
бражается список всех доступных тестовых наборов. Пользователь имеет возможность ввести имя
тестового набора или набора или дважды щелкнуть на существующем имени.
Ожидаемый результат 3:
Отображаются детальные шаги тестовых случаев, входящих в выбранный набор. Пользователь вы­
полняет указанные задания, описанные в каждом тестовом случае. Далее пользователь должен вы­
брать один из следующих вариантов для каждого теста:
• Тест прошел, тест не прошел или тест заблокирован и прогнан быть не может.
• Результаты выполнения тестового набора носят накопительный характер. Необходимо вы­
полнить все тесты из выбранного тестового набора. Если прогон одного из тестов оказывает­
ся неудачным, таким же признается и прогон всего тестового набора.
После выбора пользователем одного из вариантов выполняется возврат в меню Test Case Execution.

5.17. ТС 3.1.17 Сводный отчет по ошибкам

Это представление состояния действий, связанных с тестированием, на уровне проектов. После
регистрации в системе пользователь получает возможность просматривать сводный отчет по ошиб­
кам (Bug Summary). Для этого необходимо в главном меню Test Management Toolkit выбрать пункт
"Test Results" ("Результаты тестирования").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Results" ("Результаты тестирования").
Ожидаемый результат 1:
Отображается экран с заголовком Test Results (Результаты тестирования).
В меню Test Results (Результаты тестирования) выберите пункт "Bug Summary" ("Сводный отчет по
ошибкам ").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени проекта, который необходимо проанализировать. Ото­
бражается список всех текущих и завершенных проектов. Пользователь имеет возможность ввести
имя проекта или дважды щелкнуть на существующем имени.
Вместе с именем проекта отображается общее количество пройденных тестов, тестов, которые не
прошли, и тестов, оказавшихся заблокированными. Каждое число отображается в форме процентно­
го отношения к общему количеству тестов.
По завершении выполняется возврат в меню Test Results.

5.18. ТС 3.1.18 Результаты тестирования/Одиночный тест

Это представление состояния действий, связанных с тестированием, на уровне тестовых случаев.
После регистрации в системе пользователь получает возможность просматривать результаты тести­
рования для одиночных тестов. Для этого необходимо в главном меню Test Management Toolkit вы­
брать пункт "Test Results" ("Результаты тестирования").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Results" ("Результаты тестирования").
Ожидаемый результат 1:
Отображается экран с заголовком Test Results (Результаты тестирования).
В меню Test Results (Результаты тестирования) выберите пункт "Single Test" ("Одиночный тест").

359
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая, который необходимо проанализиро­
вать. Отображается список всех доступных результатов прогона тестовых случаев. Пользователь
имеет возможность ввести имя тестового случая или дважды щелкнуть на существующем имени.
Вместе с именем тестового случая отображаются результат его прогона в виде "прошел"/"не про-
шелТзаблокирован".
По завершении выполняется возврат в меню Test Results.

5.19 ТС 3.1.19 Результаты тестирования/Тестовый набор

Это представление состояния действий, связанных с тестированием, на уровне тестовых наборов.
После регистрации в системе пользователь получает возможность просматривать результаты тести­
рования для тестовых наборов и списков прогона. Для этого необходимо в главном меню Test Man­
agement Toolkit выбрать пункт "Test Results" ("Результаты тестирования").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Test Results" ("Результаты тестирования").
Ожидаемый результат 1:
Отображается экран с заголовком Test Results (Результаты тестирования).
В меню Test Results (Результаты тестирования) выберите пункт "Suite or Run List" ("Тестовый набор
или список прогона").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового набора или списка прогона, которые необ­
ходимо проанализировать. Отображаются имена всех доступных результатов выполнения тестовых
наборов и списков прогона. Пользователь имеет возможность ввести имя тестового набора или спи­
ска прогона либо дважды щелкнуть на существующем имени.
Вместе с именем тестового набора или списка прогона отображаются результат его прогона в
виде "прошел"/"не прошел"/"заблокирован".
По завершении выполняется возврат в меню Test Results.

5.20. ТС 3.1.20 Создать матрицу прослеживаемости

После регистрации в системе пользователь получает возможность создать матрицу прослеживаемо­
сти требований. Для этого необходимо в меню Utilities (Утилиты) выбрать пункт "Create Trace Matrix"
("Создать матрицу прослеживаемости").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран с заголовком Utilities Menu (Меню утилит).
В меню Utilities (Утилиты) выберите пункт "Create Trace Matrix" ("Создать матрицу прослежи­
ваемости").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени документа описания требований, который должен
анализироваться.
Размещение этого документа жестко определено. На том же экране, где содержится запрос пользо­
вателя на ввод имени этого документа, указывается список всех доступных документов описания
требований. Пользователь имеет возможность вводить имя необходимого документа или дважды
щелкать на имени соответствующего файла.
Ожидаемый результат 3:
После выбора пользователем файла открывается новое окно, содержащее в одном столбце требо­
вания к продукту/проекту. Здесь будут присутствовать столбцы с соответствующими тестовыми слу-

360
Спецификация тестовой процедуры ТМТ TMT-TPS-10

чаями, доказывающими то или иное требование. Данная форма предназначена только для чтения и
может быть выведена на печать для ручного заполнения. Пользователь имеет возможность выво­
дить форму на принтер, а также экспортировать ее в формате электронной таблицы.
По завершении выполняется возврат в меню Utilities.

5.21. ТС 3.1.21 Резервное копирование/Тестовые случаи

После регистрации в системе пользователь получает возможность выполнить резервное копирова­
ние отдельных тестовых случаев. Для этого необходимо в меню Utilities выбрать пункт "Backup Test
Case" ("Резервное копирование тестового случая").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран с заголовком Utilities Menu (Меню утилит).
В меню Utilities выберите пункт "Backup Test Case" ("Резервное копирование тестового случая").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая, который должен копироваться. Ото­
бражается список всех доступных тестовых случаев. Пользователь имеет возможность вводить имя
тестового случая или дважды щелкнуть на существующем имени.
Ожидаемый результат 3:
После выбора пользователем тестового случая для копирования выдается запрос на ввод конечного
расположения резервной копии. Расположение резервной копии варьируется в зависимости от сис­
темы, однако им может быть гибкий диск, локальный жесткий диск, сетевой диск или магнитная лен­
та. В качестве вариантов также можно рассматривать дисководы CDR или CDRW. Кроме того, име­
ется возможность изменить имя резервной копии, которым по умолчанию является имя тестового
случая.
По завершении выполняется возврат в меню Utilities.

5.22. ТС 3.1.22 Резервное копирование/Тестовые наборы

После регистрации в системе пользователь получает возможность выполнить резервное копирова­
ние тестовых наборов. Для этого необходимо в меню Utilities выбрать пункт "Backup Test Suite" ("Ре­
зервное копирование тестового набора").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Backup Test Suite" ("Резервное копирование тестового набора").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового набора, который должен копироваться. Ото­
бражается список всех доступных тестовых наборов. Пользователь имеет возможность вводить имя
тестового набора или дважды щелкнуть на существующем имени.
Ожидаемый результат 3:
После выбора пользователем тестового набора для копирования выдается запрос на ввод конечного
расположения резервной копии. Расположение резервной копии варьируется в зависимости от сис­
темы, однако им может быть гибкий диск, локальный жесткий диск, сетевой диск или магнитная лен­
та. В качестве вариантов также можно рассматривать дисководы CDR или CDRW. Кроме того, име­
ется возможность изменить имя резервной копии, которым по умолчанию является имя тестового
набора.
По завершении выполняется возврат в меню Utilities.

361
Спецификация тестовой процедуры ТМТ TMT-TPS-10

5.23. ТС 3.1.23 Резервное копирование/Результаты прогона тестов

После регистрации в системе пользователь получает возможность выполнить резервное копирова­
ние результатов прогона тестов. Для этого необходимо в меню Utilities выбрать пункт "Backup Test
Results" ("Резервное копирование результатов прогона теста").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Backup Test Results" ("Резервное копирование результатов прогона
теста").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени результатов прогона теста, которые должен копиро­
ваться. Отображается список всех доступных результатов прогона тестов. Пользователь имеет воз­
можность вводить имя результатов прогона теста или дважды щелкнуть на существующем имени.
Ожидаемый результат 3:
После выбора пользователем результатов прогона теста для копирования выдается запрос на ввод
конечного расположения резервной копии. Расположение резервной копии варьируется в зависимо­
сти от системы, однако им может быть гибкий диск, локальный жесткий диск, сетевой диск или маг­
нитная лента. В качестве вариантов также можно рассматривать дисководы CDR или CDRW. Кроме
того, имеется возможность изменить имя резервной копии, которым по умолчанию является имя
результатов прогона теста.
По завершении выполняется возврат в меню Utilities.

5.24. ТС 3.1.24 Восстановление/Тестовые случаи

После регистрации в системе пользователь получает возможность восстанавливать тестовые случаи
по оригинальному их расположению. Для этого необходимо в меню Utilities выбрать пункт "Restore
Test Case" ("Восстановление тестового случая").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Restore Test Case" ("Восстановление тестового случая").
Ожидаемый результат 2:
Пользователь получает запрос о месте расположения резервной копии, которую необходимо восста­
новить.
Расположение резервной копии варьируется в зависимости от системы, однако им может быть гиб­
кий диск, локальный жесткий диск, сетевой диск или магнитная лента. В качестве вариантов также
можно рассматривать дисководы CDR или CDRW. После указания расположения пользователь по­
лучает запрос на ввод имени сохраненного тестового случая, который необходимо восстановить.
Отображается список всех доступных архивов тестовых случаев. Пользователь может либо вручную
ввести имя тестового случая, либо дважды щелкнуть на имени файла с резервной копией.
После выбора пользователем места расположения и файла, утилита восстанавливает тестовый
случай по месту его оригинального расположения.
По завершении выполняется возврат в меню Utilities.

362
Спецификация тестовой процедуры ТМТ TMT-TPS-10

5.25. ТС 3.1.25 Восстановление/Тестовые наборы

После регистрации в системе пользователь получает возможность восстанавливать тестовые набо­
ры по оригинальному их расположению. Для этого необходимо в меню Utilities выбрать пункт "Restore
Test Suite" ("Восстановление тестового набора").

Случай 1
В главном меню Test Management Toolkit выберите ПУНКТ "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Restore Test Suite" ("Восстановление тестового набора").
Ожидаемый результат 2:
Пользователь получает запрос о месте расположения резервной копии, которую необходимо восста­
новить.
Расположение резервной копии варьируется в зависимости от системы, однако им может быть гиб­
кий диск, локальный жесткий диск, сетевой диск или магнитная лента. В качестве вариантов также
можно рассматривать дисководы CDR или CDRW. После указания расположения пользователь по­
лучает запрос на ввод имени сохраненного тестового набора, который необходимо восстановить.
Отображается список всех доступных архивов тестовых наборов. Пользователь может либо вручную
ввести имя тестового набора, либо дважды щелкнуть на имени файла с резервной копией.
После выбора пользователем места расположения и файла, утилита восстанавливает тестовый
набор по месту его оригинального расположения.
По завершении выполняется возврат в меню Utilities.

5.26. ТС 3.1.26 Восстановление/Результаты прогона тестов

После регистрации в системе пользователь получает возможность восстанавливать результаты
тестирования по оригинальному их расположению. Для этого необходимо в меню Utilities выбрать
пункт "Restore Test Results" ("Восстановление результатов прогона теста").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Restore Test Results" ("Восстановление результатов прогона теста").
Ожидаемый результат 2:
Пользователь получает запрос о месте расположения резервной копии, КОТОРУЮ необходимо восста­
новить.
Расположение резервной копии варьируется в зависимости от системы, однако им может быть гиб­
кий диск, локальный жесткий диск, сетевой диск или магнитная лента. В качестве вариантов также
можно рассматривать дисководы CDR или CDRW. После указания расположения пользователь по­
лучает запрос на ввод имени сохраненных результатов прогона теста, которые необходимо восста­
новить. Отображается список всех доступных архивов результатов прогона теста. Пользователь
может либо вручную ввести имя результатов прогона теста, либо дважды щелкнуть на имени файла
с резервной копией.
После выбора пользователем места расположения и файла, утилита восстанавливает результа­
ты прогона теста по месту их оригинального расположения.
По завершении выполняется возврат в меню Utilities.

363
 Спецификация тестовой процедуры ТМТ TMT-TPS-10

5.27. ТС 3.1.27 Экспорт/Тестовые случаи

После регистрации в системе пользователь имеет возможность выполнять экспорт тестовых случаев
для использования их в других приложениях. Для этого необходимо в меню Utilities выбрать пункт
"Export Test Case" ("Экспорт тестового случая").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите ПУНКТ "Export Test Case" ("Экспорт тестового случая").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового случая, который необходимо экспортиро­
вать.
Ниже отображаются все доступные тестовые случаи. Пользователь имеет возможность либо ввести
вручную имя экспортируемого тестового случая, либо дважды щелкнуть на имени в списке.
После ввода имени тестового случая, который необходимо экспортировать, выдается запрос на вы­
бор целевого устройства. В зависимости от конкретной системы, им может быть гибкий диск, локаль­
ный жесткий диск, сетевой диск или магнитная лента. В качестве вариантов также можно рассматри­
вать дисководы CDR или CDRW.
После указания имени тестового случая и целевого расположения необходимо щелкнуть на
кнопке "Continue" ("Продолжить"), в результате чего выполняется экспорт.
По завершении выполняется возврат в меню Utilities.

5.28. ТС 3.1.28 Экспорт/Тестовые наборы

После регистрации в системе пользователь имеет возможность экспортировать тестовые наборы
для использования в других приложениях. Для этого необходимо в меню Utilities выбрать пункт "Ex­
port Test Suite" ("Экспорт тестового набора").

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Export Test Suite" ("Экспорт тестового набора").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени тестового набора, который необходимо экспортиро­
вать.
Ниже отображаются все доступные тестовые наборы. Пользователь имеет возможность либо ввести
вручную имя экспортируемого тестового набора, либо дважды щелкнуть на имени в списке.
После ввода имени тестового набора, который необходимо экспортировать, выдается запрос на
выбор целевого устройства. В зависимости от конкретной системы, им может быть гибкий диск, ло­
кальный жесткий диск, сетевой диск или магнитная лента. В качестве вариантов также можно рас­
сматривать дисководы CDR или CDRW.
После указания имени тестового набора и целевого расположения необходимо щелкнуть на
кнопке "Continue" ("Продолжить"), в результате чего выполняется экспорт.
По завершении выполняется возврат в меню Utilities.

5.29. ТС 3.1.29 Экспорт/Результаты прогона тестов

После регистрации в системе пользователь имеет возможность экспортировать результаты прогона
тестов для использования в других приложениях. Для этого необходимо в меню Utilities выбрать
пункт "Export Test Results" ("Экспорт результатов прогона теста").

364
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Случай 1
В главном меню Test Management Toolkit выберите пункт "Utilities" ("Утилиты").
Ожидаемый результат 1:
Отображается экран под заголовком Utilities Menu.
В меню Utilities выберите пункт "Export Test Results" ("Экспорт результатов прогона теста").
Ожидаемый результат 2:
Пользователь получает запрос на ввод имени результатов прогона теста, которые необходимо экс­
портировать.
Ниже отображаются все доступные результаты прогона тестов. Пользователь имеет возможность
либо ввести вручную имя экспортируемых результатов прогона теста, либо дважды щелкнуть на
имени в списке.
После ввода имени результатов прогона теста, которые необходимо экспортировать, выдается
запрос на выбор целевого устройства. В зависимости от конкретной системы, им может быть гибкий
диск, локальный жесткий диск, сетевой диск или магнитная лента. В качестве вариантов также можно
рассматривать дисководы CDR или CDRW.
После указания имени результатов прогона теста и целевого расположения необходимо щелк­
нуть на кнопке "Continue" ("Продолжить"), в результате чего выполняется экспорт.
По завершении выполняется возврат в меню Utilities.

5.30. ТС 3.1.30 Справка

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

Случай 1
В любом меню выберите пункт Help (Справка).
Ожидаемый результат:
Экран содержит записи для каждого пункта меню. Синтаксис и семантика фраз корректны.

5.31 . ТС 3.1.31 Многопользовательские функциональные возможности

В данном случае предпринимается попытка синхронизировать действия с целью обеспечения мак­
симальной нагрузки на определенные компоненты. Имеется тщательно скорректированная последо­
вательность действий, которая вызовет повышенную нагрузку на определенные компоненты. Датой
тестирования должно быть 8 октября. Для минимизации влияния со стороны сетевой среды тестиро­
вание должно начаться не ранее в 18:00.

Случай 1
18:00. Пользователи User1, User2, User3, User4 и User5 в произвольном порядке создают проект,
тестовые случаи и наборы.
Ожидаемый результат 1:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.

Случай 2
18:15. Пользователи User1, User2, User3, User4 и User5 в произвольном порядке вводят результаты
тестирования для тестовых случаев и наборов.

365
Спецификация тестовой процедуры ТМТ TMT-TPS-10

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

Случай 3
18:30. Пользователи User1, User2, User3, User4 и User5 выдают запросы на получение отчетов на
уровне проекта, тестового набора и результатов прогона тестовых случаев.
Ожидаемый результат 3:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.

Случай 4
18:45. Пользователи User1, User2, User3, User4 и User5 выводят на принтер результаты запросов.
Ожидаемый результат 4:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.
Успешное завершение этого теста подтверждает возможность выполнения приведенных выше
действий без сбоев в работе системы. Потенциальные отклонения в функционировании системы
должны быть описаны дополнительно. Неудовлетворительный результат тестирования свидетель­
ствует о невозможности выполнения указанных функций. Если такая проблема существует, для по­
лучения характеристики отказа следует начать с одного пользователя и добавлять каждый раз по
одному до тех пор, пока не возникнет системный отказ. Предполагается, что все указанные действия
исполняются без каких-либо заметных отклонений.

Ссылки
Chris Brown, Test Management Toolkit, Requirements Definition (Набор инструментальных средств
управления тестированием, Определение требований). Документ TMT-RD-10, который размещает­
ся под управлением системы контроля документов по адресу:
[Link]
Chris Brown and J. Barnes, Test Management Toolkit, Test Plan (Набор инструментальных средств
управления тестированием, План тестирования). Документ ТМТ-ТР-10, который размещается под
управлением системы контроля документов по адресу:
[Link]

Приложение 1 — Список аббревиатур

API — Application Programming Interface (Интерфейс программирования приложений)
ASCII — American Standard Code for Information Interchange (Американский стандартный код обмена
информацией)
CDR — Compact Disc Recordable (Записываемый компакт-диск)
HTML — Hypertext Markup Language (Язык гипертекстовой разметки)
ISO — International Organization for Standardization (Международная организация по стандартизации)
РРС — Power PC (Процессор Power PC)
RISC — Reduced Instruction Set Computing (Сокращенный набор вычислительных инструкций)
SQL — Structured Query Language (Язык структурированных запросов)
SPARC — Scalable Processor Architecture (Масштабируемая процессорная архитектура)
TCL — Tool Command Language (Инструментальный командный язык)
ТМТ — Test Management Toolkit (Набор инструментальных средств управления тестированием)
Х86 — Процессоры серии Intel

366
Спецификация тестовой процедуры ТМТ TMT-TPS-10

Приложение 2 — Определение терминов

Отсутствует

Приложение 3 — Сообщения электронной почты от утверждающих лиц

О т ; ЧакД. Клут (Chuck D. Klout) [cdklout@tmtco]
Отправлено: среда 9/11/01 14:23
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customerssupport@tmtco
Тема: Тестовые процедуры, версия ТМТ 1.0
Уважаемые члены команды,
Я просмотрел документ спецификации тестовых процедур, TMT-TPS-10, версия 5, и пришел к выво­
ду, что он весьма точно покрывает тестирование требований в данной версии. Я утверждаю этот
документ в том виде, в котором он написан. Сокращенный список оборудования и операционных
систем, которые будут участвовать в тестировании, обсужден с несколькими заказчиками и утвер­
жден в своей первой версии.
Спасибо, Чак
Чак Д. Клут
Директор отдела маркетинга
ТМТСО

От: Сьюзи Перл (Suzie Perl [spent@[Link]]

Отправлено: четверг 9/12/2001 09:30
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: План тестирования ТМТ 1.0
Привет всем,
Мы вместе с командой просмотрели тестовые процедуры TMT-TPS-10, версия 5, для первой версии
приложения ТМТ и утверждаем их в том виде, в котором они были написаны.
С наилучшими пожеланиями, Сьюзи
Сюзанна Перл
Менеджер, отдел программирования
ТМТСО

От: Брит Гейтер (Bret Gater) [bgater@[Link]]

Отправлено: четверг 9/12/2001 07:30
Кому: Крис Браун [cbrown@tmtco]; test@tmtco; development@tmtco
Копия: marketing@tmtco; costumersupport@tmtco
Тема: План тестирования ТМТ 1.0
Уважаемые члены команды,
Я просмотрел тестовые процедуры TMT-TPS-10, версия 5, и утверждаю его для использования ко­
мандой тестеров в том виде, в котором они написаны.
С наилучшими пожеланиями, Брит
Брит Гейтер
Менеджер, отдел программирования
ТМТСО

367
 Пример сводного
отчета по 16
системным
испытаниям
В главе 5 подробно обсуждался этап системных испытаний процесса разработки про­
дукта. Там же отмечалось, что этот этап выглядит подобно дню соревнований для
спортсмена либо дню представления для театрального актера. Большая часть опера­
ций по планированию и тестированию уже выполнена, "установлены подмостки" и
наступило время действий. На рис. 16.1 показан этап системных испытаний.
В соответствии с рис. 16.1, первой задачей, выполняемой на этапе системных ис­
пытаний, является верификация на предмет того, что все подготовлено и можно
приступать к выполнению дальнейших действий. Эта задача решается путем приме­
нения набора входных критериев системных испытаний, которые были определены
в плане тестирования. Если удовлетворены входные критерии, этап системных ис­
пытаний может начинаться.
В процессе тестирования выполняется прогон тестов, определенных в плане тес­
тирования. По мере прогона тестов выявляются ошибки, создаются отчеты по ошиб-
кам, а данные, имеющие отношению к процессу отслеживания ошибок, заносятся в
специальную базу данных. Между тестировщиками и разработчиками поддерживает­
ся непрерывный диалог на основе промежуточных отчетов.
После начала процесса тестирования важно сообщать о состоянии тестирования
разработчиками и менеджерам. Подобное общение поддерживается через составле­
ние периодических отчетов о состоянии тестирования, а также благодаря подготовке
сводного отчета о тестировании в конце фазы системных испытаний. В главе рас­
сматривается пример такого отчета, подготовленного к концу системных испытаний
для вымышленного набора инструментальных средств управления тестированием
(Test Management Toolkit, TMT).
В главе 5 упоминалось, что назначение сводного отчета о тестировании заключа­
ется в ответе на следующие вопросы:
• Что было протестировано?
• Насколько фактические действия по проведению тестированию отклонились от
плана тестирования?
• Как график и трудозатраты согласуются с планом тестирования?
• Какие ошибки были найдены?
• Какие ошибки остались на момент завершения тестирования и как они будут
обработаны?
 Глава 16. Пример сводного отчета по системным испытаниям 369

Сводный отчет по тестированию не обязательно включает детализованные ре­

зультаты прогона каждого теста, однако, он может содержать ссылки на эти результа­
ты в случае, если они были скомпилированы и архивированы. Сбор и архивирование
всех результатов тестирования — это одно из преимуществ коммерческого инстру­
ментария управления процессом тестирования. Если в результате применения по­
добного инструментария все тесты объединяются в рамках одного документа, свод­
ный отчет по тестированию будет содержать ссылки на этот документ.
В оставшейся части главы приводится пример сводного отчета по тестированию.
Обратите внимание на то, что в этом примере содержатся элементы, которые могут
использоваться в других отчетах. Такими элементами, в частности, являются:
• Отчет о состоянии тестирования.
• Отчет об открытых ошибках.
• Сводка по обнаруженным ошибкам по степени их серьезности.
Сводны й от че т п о т е с т и ров а н и ю ТМ Т TMT-TPS-10

Идентификатор документа: TMT-TSR-10

Версия: 0.2
Авторы: Джеймс Барнс (James Barnes)

Набор инструментальных средств управления тестированием

Версия 1.0

Сводный отчет по тестированию

370
Сводный отчет по тестированию ТМТ TMT-TPS-10

Содержание
1. Введение 371
2. Сводка по результатам тестирования 371
3. Свойства, которые должны тестироваться 375
4. Свойства, которые не должны тестироваться 375
5. Отклонения от плана тестирования 376
6. Соблюдение графика 376
7. Ссылки 376
Приложение 1 —Списо к аббревиатур 376
Приложение 2 — Определение терминов 376
Приложение 3 — Сообщения электронной почты от утверждающих лиц 376
От: Брит Гейтер (Bret Gater) [bgater@[Link]] 376

1. Введение
Назначение этого документа заключается в представлении отчета о результатах системных испыта­
ний набора инструментальных средств управления тестированием (Test Management Toolkit, TMT).
Тесты производились в соответствии с документом "Набор инструментальных средств управления
тестированием, План тестирования":
httD://[Link]/usr/www/docstores/desiQn/Dlans/[Link].
Свойства, на которые производятся ссылки в этом документе, находятся в документе определения
требований, именуемого "Набор инструментальных средств управления тестированием, Определе­
ние требований":
[Link]

2. Сводка по результатам тестирования

Три завершенных цикла тестирования, которые были проведены для программного продукта ТМТ, на
100% реализуют комбинированное тестирование системы. К моменту прогона заключительного теста
было пройдено 95% тестов, причем катастрофические ошибки обнаружены не были. Используя по­
лученные результаты, команда тестирования рекомендует утвердить выпуск этого программного
продукта.
Сводка по ошибкам, остающимся актуальными к концу тестирования, приводится в таблице 2.2.
Накопительная сводка по ошибкам, найденным во время тестирования программного продукта ТМТ,
показана в таблице 2.3. Сводка по ошибкам также представлена в виде гистограммы на рис. 3.1.

371
Сводный отчет по тестированию ТМТ TMT-TPS-10

Таблица 2.1. Отчет о состоянии тестирования

372
Сводный отчет по тестированию ТМТ TMT-TPS-10

373
Сводны й отч е т п о т е с т и р о в а н и ю Т М Т TMT-TPS-10

374
Сводный отчет по тестированию ТМТ TMT-TPS-10

3. Свойства, которые должны тестироваться

С целью обеспечения гарантии того, что программный продукт ТМТ удовлетворяет требованиям,
указанным в спецификации требований ТМТ, были протестированы следующие свойства:
• Требование 3.1.1. Пользовательский интерфейс
• Требование 3.1.2. Навигация
• Требование 3.1.3. Аутентификация пользователей — клиент
• Требование 3.1.4. Аутентификация пользователей — администратор
• Требование 3.1.5. Текущие проекты
• Требование 3.1.6. Завершенные проекты
• Требование 3.1.7. Создание нового проекта
• Требование 3.1.8. Изменение проекта
• Требование 3.1.9. Удаление проекта
• Требование 3.1.10. Создание тестового случая или набора
• Требование 3.1.11. Изменение тестового случая или набора
• Требование 3.1.12. Удаление тестового случая или набора
• Требование 3.1.13. Отображение теста
• Требование 3.1.14. Отображение тестового набора
• Требование 3.1.15. Прогон одиночного теста
• Требование 3.1.16. Прогон тестового набора
• Требование 3.1.17. Создание списка прогона
• Требование 3.1.18. Выполнение списка прогона
• Требование 3.1.19. Сводный отчет по ошибкам
• Требование 3.1.20. Результаты тестирования — одиночный тест
• Требование 3.1.21. Результаты тестирования — тестовый набор или список прогона
• Требование 3.1.22. Создание матрицы прослеживаемости
• Требование 3.1.23. Резервное копирование тестовых случаев
• Требование 3.1.24. Резервное копирование тестовых наборов
• Требование 3.1.25. Резервное копирование результатов прогона тестов
• Требование 3.1.26. Восстановление тестовых случаев
• Требование 3.1.27. Восстановление тестовых наборов
• Требование 3.1.28. Восстановление результатов прогона тестов
• Требование 3.1.29. Экспорт тестовых случаев
• Требование 3.1.30. Экспорт тестовых наборов
• Требование 3.1.31. Экспорт результатов прогона тестов
• Требование 3.1.32. Получение справки
• Требование 3.1.33. Многопользовательские функциональные возможности
• В ходе прогона тестов по всем свойствам получены результаты, которые описаны ранее, в
разделе 2.

4. Свойства, которые не должны тестироваться

Ниже приводится список функциональных свойств и/или конфигураций системы, которые не тести­
ровались.
• Web-сервер (Apache или IIS) непосредственно не тестировался.

375
Сводны й отч е т п о т е с т и ров а н и ю Т М Т TMT-TPS-10

• Не проводилось расширенное тестирование клиент/серверной архитектуры под большой на­

грузкой. Многопользовательские функциональные возможности тестировались для пяти ре­
альных пользователей, что является минимальной многопользовательской конфигурацией.

5. Отклонения от плана тестирования

Отклонения от плана тестирования не обнаружены.

6. Соблюдение графика
Тестирование было завершено по графику, хотя были обнаружены небольшие отклонения дат нача­
ла и завершения для индивидуальных циклов тестирования.

7. Ссылки
Chris Brown, Test Management Toolkit, Requirements Definition (Набор инструментальных средств
управления тестированием, Определение требований). Документ TMT-RD-10, который размещает­
ся под управлением системы контроля документов по адресу:
[Link]
Chris Brown and J. Barnes, Test Management Toolkit, Test Plan (Набор инструментальных средств
управления тестированием, План тестирования). Документ TMT-TP-10, который размещается под
управлением системы контроля документов по адресу:
[Link]
Chris Brown и J. Barnes, Test Management Toolkit, Release 1.0. Test Procedure Specification (Набор
инструментальных средств управления тестированием, Спецификация тестовой процедуры
ТМТ). Документ TMT-TPS-10, который размещается под управлением системы контроля документов
по адресу:
[Link]

Приложение 1 —Списо к аббревиатур

Отсутствует

Приложение 2 — Определение терминов

Отсутствует

Приложение 3 — Сообщения электронной почты от утверждающих лиц

От: Брит Гейтер (Bret Gater) [bgater@[Link]]
Отправлено: четверг 9/10/2001 07:30
Кому: Дж. Варне [jbarnes@tmtco]; test@tmtco; development@tmtco
Копия: marketing@tmtco; costumersupport@tmtco
Тема: Сводка по тестированию ТМТ 1.0
Уважаемые члены команды,
Я просмотрел сводный отчет по тестированию TMT-TSR-10, версия 2, и утвердил его, поскольку он
точно представляет результаты тестирования. Команда тестирования рекомендует утвердить выпуск
программного продукта ТМТ, версия 1.0. Поздравляю разработчиков и тестировщиков с достигнутым
успехом!
С наилучшими пожеланиями, Брит
Брит Гейтер
Менеджер, отдел программирования
ТМТСО

376
Литература
1. Albrecht, Allan J. (1979). "Measuring Application Development Productivity." Proceedings of
the IBM Application Development Symposium, 83-92.
2. Basili, V. R. and D. M. Weiss. (1984). "A Methodology for Collecting Valid Software Engi­
neerin g Data." IEEE Transactions on Software Engineering, SE-10 (6).
3. Beizer, Boris. (1995). Black-Box Testing: Techniques for Functional Testing of Software and Systems.
New York: Wiley.
4. Belford, P. C, R. A. Berg, an d T. L. Hannan . (1979). "Central Flow Control Software Devel­
opment : A Case Study of th e Effectiveness of Software Engineering Techniques, " Proceed­
ings from th e Fourth Summe r Software Engineering Workshop, SEL-79-005.
5. Black, Rex. (1999). Managing the Test Process. Redford, WA: Microsoft Press.
6. Boehm, Barry W. (1981). Software engineering economics. Englewood Cliff's, NJ: Prentice-Hall, Inc.
7. Boehm, Barry W. (1988). "A spiral model for software development an d enhancement. "
IEEE Computer, 21(5) (May): 61-72.
8. Boehm, Barry W. (1991). "Software risk management: Principles and practices." IEEE Soft­
ware, 8(1) (January): 32-41 .
9. Boehm, Barry W. (2000). Software Cost Estimation with COCOMO II. Englewood Cliffs, NJ:
Prentice Hall.
10. Brooks, Fred. (1982). The Mythical Man-Month: Essays on Software Engineering. Reading, MA:
Addison-Wesley.
11. Burnstein, Ilene, C.R. Carlson, an d T. Suwanassart. (1996). "Developing a Testing Maturity
Model." Proceeding of the Ninth International Software Quality Week Conference, San Francisco,
May, 1996. Note: Ilene Burnstein is affiliated with th e Illinois Institute of Technology, where
work on th e Testing Maturity Model is being conducted .
12. Cooley, J. W., and J. W. Tukey. (1965). "An Algorithm for Machine Calculation of Complex
Fourier Series." Mathematics of Computation, Vol. 19, pp . 297-301.
13. Curtis, Bill, Herb Krasner, Vincent Shen, an d Neil Iscoe. (1987). "O n building software
process models unde r th e lamppost." Proceedings of the 9th International Conference on Software
Engineering (pp . 96-103). Monterey, CA: IEEE Compute r Press Society.
14. DeMarco, Tom, an d Timothy Lister. (1987). Peopleware: Productive Projects and Teams. New
York: Dorset House Publishing.
15. Dustin, Elfriede, Jeff Rashka, an d J o h n Paul. (1999). Automated Software Testing: Introduction,
Management, and Performance. Reading, MA: Addison-Wesley.
16. Fagan, M.E. (1976). "Design and code inspections to reduc e errors in progra m develop­
ment. " IBM Systems Journal, 15(3): 182-210.
17. Fewster, Mark, and Dorothy Graham. (1999). Software Test Automation. Reading, MA: Addi­
son-Wesley.
18. Good, Donald I., R. M. Cohen, С G. Hoch, L. W. Hunter , an d D. F. Hare . (1978). "Certifi­
able Minicomputer Project, ICSCA," Report on the Language Gypsy, Version 2.0. Technical
Report ICSCA-CMP-10, Th e University of Texas at Austin, September 1978.
19. Humphrey , Watts S. (1990). Managing the Software Process. Reading, MA: Addison-Wesley.
378 Литература

20. Humphrey , Watts S. (1997). Introduction to the Personal Software Process. Reading, MA: Addi-
son-Wesley.
21. Humphrey , Watts S. (2000). Introduction to the Team Software Process. [Link]: Addison-
Wesley.
22. IEEE. (1983). IEEE Standard 829: IEEE Standard for Software Test Documentation. Los Alamitos,
CA: IEEE Compute r Society Press.
23. IEEE. (1984). IEEE Standard 830: The IEEE Guide to Software Requirements Specifications. Los
Alamitos, CA: IEEE Compute r Society Press.
24. IEEE. (1993). IEEE Standard 1044, IEEE Standard for Software Anomalies, © 1993 IEEE, New
York, NY.
25. Jones , Capers. (1986). Programming Productivity. New York: McGraw-Hill.
26. Jones , Capers. (1997). Software Quality: Analysis and Guidelines for Success. Boston: Interna­
tional Thompso n Compute r Press.
27. Kaner, Cem, Jack Falk, an d Hun g Quo c Nguyen. (1999). Testing Computer Software (2nd ed.) .
New York: Wiley.
28. Kit, Edward. (1995). Software Testing in the Real World: Improving the Process. Reading, MA:
Addison-Wesley.
29. Koomen, Tim, an d Martin Pol. (1999). Test Process Improvement. Reading, MA: Addison-
Wesley.
30. Lewis, William E. (2000). Software Testing and Continuous Quality Improvement. Boca Raton,
FL: Auerbach.
31. McCabe, Thomas J. (1976). "A Complexity Measure." IEEE Transactions on Software Engineering.
32. McCabe, Thomas , an d Charles W. Butler. (1989). "Design Complexity Measurement and
Testing." Communications of the ACM 32, 12 (December 1989): 1415-1425.
33. McConnell, Steve. (1996). Rapid Development: Taming Wild Software Schedules. Redmond , WA:
Microsoft Press.
34. Michael Fagan. (1976). "Design and Code Inspections to Reduce Errors in Program Devel­
opment," IBM Systems Journal, i5 ( 3) , 182-211.
35. Musa, J oh n D. (1993). "Operational Profiles in Software-Reliability Engineering." IEEE Soft­
ware, 14-19.
36. Myers, Glen. (1979). The Art of Software Testing. New York: Wiley.
37. Myers, Glenford J. (1977). "An Extension to the Cyclomatic Measure of Program Complex­
ity." SIGPLAN Notices.
38. Paulk, Mark, Charles Weber, an d Bill Curtis. (1995). The Capability Maturity Model: Guidelines
for Improving the Software Process. Reading, MA: Addison-Wesley.
39. Paulk, Mark. "Using th e Software CMM with Small Projects an d Small Organizations." In
Eugene McGuire (1999), Software Process Improvement: Concepts and Practices. Hershey, PA:
Idea Grou p Publishing.
40. Perry, William E. (2000). Effective Methods for Software Testing(2nd ed.). New York: Wiley.
41 . Perry, William E., an d Randall W. Rice. (1997). Surviving the Top Ten Challenges of Software
Testing. New York: Dorset Hous e Publishing.
42. Pfleeger, Shari Lawrence. (2001). Software Engineering: Theory and Practice (2nd ed.). Uppe r
Saddle River, NJ: Prentice Hall.
 Литератур а 379

43. Pressman, Roger. (1997). Software Engineering: A Practitioner's Approach (4th ed.). New York:
McGraw-Hill.
44. Robertson, Suzanne, and Jame s Robertson. (1999). Mastering the Requirements Process. Read­
ing, MA: Addison-Wesley.
45. Schulmeyer, G. Gord o n an d Garth R. Mackenzie. (2000). Verification and Validation of Modern
Software-Intensive Systems. Uppe r Saddle River, NJ: Prentice Hall.
46. Software Productivity Consortium (1993). Software Erro r Estimation Program (SWEEP)
User Manual, (SPC-92017-CMC), Version 02.00.10.
47. Sommerville, Ian. (1992). Software Engineering(4th ed.) . Reading, MA: Addison-Wesley.
48. Th e Standish Grou p . (1994). The CHAOS Report. Dennis, MA: Th e Standish Group .
49. Th e Standish Group . (1995). The Scope of Software Development Project Failures. Dennis, MA:
Th e Standish Grou p .
50. van Soligen, Rini, and Egon Berghout. (1999). The Goal/Question/Metric Method: A practical
guide for quality improvement of software development. Berkshire, England: McGraw-Hill Book
Company, UK.
51. p. 5 From Verification and Validation of Modern Software-Intensive Systems by Schulmeyer &
MacKenzie. © 2000. Reprinte d by permission of Pearson Education, Inc., Uppe r Saddle
River, NJ.
52. pp. 6-7, 73 From Rapid Development: Taming Wild Software Schedules by Steve McConnell.
Copyright 1996. Reproduce d by permission of Microsoft Press. All rights reserved.
53. pp. 10, 40 From Software Engineering: Theory and Practice, 2nd ed., by S. Pfleeger. © 2001. Ma­
terial is reprint e d by permission of Pearson Education, Inc.
54. pp. 25, 66, 134, 139 From Software Engineering Economics by Boehm, B.W. © 1981. Reprinted
by permission of Pearson Education, Inc., Uppe r Saddle River, NJ.
55. p. 28 From Software Engineering: A Practitioner's Approach, 4th ed., by R. Pressman. © 1997
McGraw-Hill, Inc .
56. p. 31 Information regardin g th e content an d format of requirement s document s is re­
printe d with permission from IEEE Std. 830-1993: The IEEE Guide to Software Requirements
Specifications. Copyright 1993 by IEEE.
57. p. 36 From Software Testing in the Real World: Improving the Process, by E. Kit. © 1995 Addison-
Wesley, Inc.
58. p. 55 From Automated Software Testing (pp. 32-38) by E. Dustin, J. Rashka, & J. Paul. © 1999
Addison Wesley Longman, Inc. Reprinted by permission of Pearson Education, Inc.
59. p. 61 Material excerpted from Managing the Test Process by permission of the author , Rex
Black; second edition in press by Joh n Wiley & Sons, Inc., ISBN 0-471-22398-0.
60. p. 70 From The Mythical Man-Month (p. 18) by F. Brooks, Jr . © 1999 Addison Wesley Long-
man, Inc. Reprinted by permission of Pearson Education, Inc.
61 . pp. 77, 80 Information regarding the content an d format of test document s is reprinte d with
permission from IEEE Std. 829-1983: IEEE Standard for Software Test Documentation. Copy­
right 1983 by IEEE.
62. pp. 214-215 Information regarding defect reportin g is reprinte d with permission from
IEEE Std. 1044-1993: IEEE Standard for Software Anomalies, Copyright 1993 by IEEE.
Предметный указатель
с анализ, 140
жизненный цикл, 160; 171
СОСОМО , 107; 123; 143; 268; 276; 277; категория, 121; 123
278; 281; 282; 285; 287 обнаружение и отслеживание, 118; 120;
COCOREV, 285; 286; 287; 291; 292; 293; 168
294; 295; 296; 297; 299; 301 составление сообщения, 132; 137
Constructive Cost Model. См. СОСОМ О Динамическое тестирование , 18; 22; 26;
33; 38; 77; 59; 151; 143; 160; 162; 211
F
анализ граничных значений, 124; 211
Facilitated Application Specification Tech­ интерфейса, 214
niques. См. Технология FAST конфигурации платформы, 211; 214
Технология FAST, 40; 43 матрица тестовых конфигураций, 214
нагрузочной эффективности, 211; 214
V определение полноты охвата
V&V. См. Верификация и аттестация, 20; ветвей, 211; 213
264; 294; 298 отрицательное тестирование, 211
V-диаграмма, 48; 49 отслеживание ошибок
стандартная терминология, 212
А потоки данных, 211; 214
Администратор тестирования, 178 псевдоотладка, 211; 213
Альфа-тестирование, 45 псевдоотладка/видоизменение, 211; 213
степень риска, 211
Архитектура тестов, 90
тестирование на основе определения
Аттестационные испытания, 45
степени риска, 211
Аттестация, 20
тестирование случаев
Аудит и управление, 176 использования, 211; 213
точки прерывания, 211; 214
Б
трассировка, 211; 213; 246; 270
Бета-тестирование, 45 утечек памяти, 211; 214
Быстрая разработка, 21; 183 функциональное тестирование и ана­
Быстро е тестирование, 14; 16; 21 ; 22; 183; лиз, 211
163; 213; 251 Долговечность дефекта, 18
преимущества, 160; 166
Ж
В Жизненны й цикл, 12; 30; 160; 161; 171
Верификация, 20; 207; 287; 300; 328; 333; дефекта, 160; 171
329; 330
Верификация и аттестация, 294 И
Выполнение списка прогона, 307; 322; Испытания для определения рабочих
337; 378 характеристик, 44

Г К
Группа тестирования, 123; 124 Каскадная модель, 12; 13; 31; 32; 33; 49;
51; 52; 274; 275
д Качество программного
Действие, 126 обеспечения, 246
Дефект , 18; 19; 121; 123; 124
 Пр едметны й указатель 381

Комплексные испытания, 23 категории ошибок, 267

организованный, 275
М полуорганизованный, 275
Матрица прослеживаемости Проектировани е
требований, 35; 36; 37; 40; 65; 112; 210; системы, 30
296; 300; 307; 342 тестов, 36; 40; 41; 329
Менеджер тестирования, 178 Проектно е задание, 30
Методика тестирования, 118 Прототип,73
разбиение на классы использование, 73
эквивалентности,121 определение, 73
Модульность; 101 эволюционный, 74
Процесс , 11; 12
О Планировани е тестирования. См. Пла­
Определения требований нировани е испытаний
документ, 14; 49; 51; 52; 54; 83; 295
Р
Отказ, 311;312
Отладчик, 178 Рабочий план, 30; 100
Ошибка, 211; 212; 375 Разделение по классам эквивалент­
ности, 211
П Разработка программы, 30; 50; 269
Персонал быстрого тестирования, 22; Разработчик программного обеспече­
163; 171; 189; 211; 212; 298; 339 ния, 177
План тестирования, 14; 316; 324; 344; Регрессионный тест, 47
345; 374; 376; 377; 371; 381 Результаты тестирования , 36
пример, 314
Планирование испытаний, 35; 37; 56
С
график работ, 128 Сводный отчет, 14; 370; 373; 378
риски,132 пример, 368
действия, 38 Сжатые срок и разработки, 22
диаграмма, 57 Системные испытания, 20; 33; 36; 42; 43;
дополнительные задачи, 108 44; 49; 77; 75; 78; 97; 114; 118; 146; 175;
оценка рисков, 58 272; 325; 326; 340; 341; 343
оценка трудозатрат, 58; 104 критерии, 78; 82
распространенные ошибки, 114 критерий входа, 78
технологии,118 критерий выхода, 79
пересмотр,58
критерий приостановки
проверка выполнения плана, 165
возобновления, 80
разделы плана, 141
критерий успешного/неудачного
стратегия тестирования, 56; 58; 90; 168;
прохождения теста, 81
175
Случай использования. См. Планирова­
структура испытательной системы, 58;
168 ние испытаний, 48; 58; 214; 287; 300
формат плана, 136 Сопровождение программного
Показатели тестирования, 241; 262 продукта, 46
Прогон Специалист по тестированию. См. Тес-
списка прогона, 303; 307; 322; 337; 351; тировщик, 124
352; 378 Сратегия тестирования, 59
тестового набора, 306; 321; 337; 377 Статическое тестирование, 18; 183
Программное обеспечение, 16 автоматизированное доказательство
Проект, 187; 296; 309 теорем, 183; 208
встроенный, 275 аудит, 176; 183; 196
382 Предметны й указатель

баз ы дан н ы х материалов , 183; 22 3 Т е с т п р о и з в о д и т е ль н о с т и , 8 8

инспекции/критическ ий анализ / Тестирование
э к с п е ртн ы е оценк и , 199 готовност ь продукт а к выпуску, 167
к он т р о ль н ы е п е ре ч н и , 183; 194 обеспечен и е качества , 176 ж ур на
ли с тинг и перекрестн ы х ссылок , 183; л и с п ы та н и й , 153
21 3 инструментальны е средства , 9 4
мет од ы , 6 8 испытательн а я ла б о ра то ри я , 9 9
инспекции, 68 исчерпывающе е тес ти рован и е , 6 1
сквозной контроль, 69 к ри те р и й выхода , 166
экспертные оценки, 69
об язан нос т и член о в команды , 160; 175
опреде лени е , 160; 168
отче т о ходе работ , 156; 157
от ч ет н ост ь , 183; 20 3
от ч е т о б устранени и дефек тов , 158
прог рамм а кон тро л я е ди н и ц
отче т п о результатам , 118; 156
и з м е ре н и я , 211
отче тн ы й докла д . См. Сводны й
прог ра мм ы улучшенн о й печати , 183; 214
отчет , 161
прослеживаемос т ь требовани й , 183; 210
оценк а трудозатр а т
символьн о е в ып олн е н и е , 183; 212; 213 ;
математические методы, 270
211 оценка по аналогии, 264
средств а автоматизации , 183; 20 9 показатели функциональных возможно­
средств а с ра в не н и я в е рси й , 183; 21 4 стей; 304
те с ти ров ан и е алгоритмов , 183; 21 5 прогнозирование с базисом оценок, 264
ф орм а ль н а я в е р и ф и к а ц и я , 183; 20 7 технологии,179
ф о р м а ль н а я оценк а , 183; 190 технология функциональных баллов, 264;
ти п ов ы е вопросы , 191 304
характеристик и инспекци й , 206 типовые просчеты, 268
показатели , 241 ; 26 2
циклома тич еск а я сложность , 183; 184;
качество, 246
185 плотность ошибок, 263
я з ы к и н а основ е спец ифика ци й , 183; программа оценки ошибок SWEEP, 269
20 8 производительность, 245
Стра теги я автоматизаци и, 82 размер, 245
д ос тиж и мы е выгоды , 8 4 трассировка ошибок, 246
не об ос н ов а нн ы е ож и д ан и я , 8 4 удобство сопровождения, 245
С т р а т е г и я т е с т и р о в а н и я , 56 ; 59 ; 16 8 показател и и совершенствова ни е , 25 7
каскадна я модел ь П ри ори те т ы кон фиг ураци й , 103
подход, 73 рис к и , 40; 120
рек ом е н д а ци и , 6 8 совершенс твован и е процесса , 163; 180
модель СММ, 165
т модель развития функциональных воз­
можностей, 165
Тест, 94 области КРА, 169
докумен т проекта , 111; 113 уровни КРА, 169
кон фиг ура ц и я средств , Н О среда , 98
оп ре де ле ни е , 114 технология , 160
оп ре де ле н и е ожидаемы х аппаратное тестирование, 161
результат ов , 125 аттестационные испытания, 161
оп ре де ле н и е целей , 104; 134; 141 ; 331 верификация, 161
входной контроль, 161
рекомендации, 108
имитационная проверка, 161
п е рес м о т р и отладка, 98; 137 испытания баз данных, 161
п р ог о н , 144 испытания в утяжеленном режиме. 161
п р ое к ти р о в а н и е и разработка , 9 8 испытания граничных значений, 161
пример, 329 испытания на долговечность при хране­
с п е ц и ф и к а ц и и ввода, 109; 141 нии, 161
установк а и очистка , 127
 П р е д м е т н ы й указатель 383

испытания на наличие побочных эффек­ кон фигура ци я , 135

тов, 161 пр изн ак и , 117
испытания на пригодность к обслужива­ разработка , 109; 98; 114
нию, 161 шаблон , 131
испытания на соответствие
Требование, 38
стандартам, 161
испытания надежности, 161 докумен т оп ре д е ле н и я требований , 40;
испытания последовательности 47; 52; 55; 61 ; 68; 83; 315; 330
событий, 161 категори и , 4 5
испытания работы в многозадачном ре­ к р и те ри и , 6 9
жиме, 161 контролепригодность, 73
испытания устойчивости, 161 непротиворечивость, 71
климатические испытания, 161 однозначность, 70
контроль синхронизации, 161 осуществимость, 72
контрольные испытания, 161 прослежнваемость, 71
логическое тестирование, 161 с п е ц и ф и к а ц и я тре б ов а н и й , 35; 36; 40;
нагрузочные испытания, 161 47; 64; 329
приемочные испытания, 12; 33; 161; 206 с п е ц и ф и к а ц и я тре б ов ан и й . См. Функ­
проверка ранее внесенных циона льн а я с пе ц иф ика ц ия , 8 3
изменений,161 ти п ы , 5 5
проверка точности,161 ф унк ц и он а ль н ы е , 50; 295
процедурное тестирование, 161
сбор претензии и пожеланий, 161
сравнительные испытания, 161
тестирование, 165 Ускоренная разработк а, 22
тестирование ветвей, 161; 213 У с та н ов оч н а я п р о в е р к а , 44 ; 4 6
тестирование возможностей установ­
ки, 161 Ф
тестирование документации,161
Формулирование требован ий
тестирование конфигурации, 161; 211; 214
оп р о с заказчик а , 3 9
тестирование модулей, 161; 340
тестирование на непротиворечи­ объ ек тн о- ори ен ти ров ан н а я
вость, 161 разработк а , 4 8
тестирование обращений к подпрограм­ п ри м е р , 294
мам, 161 технологи я FAST, 40; 43; 44
тестирование сегментов, 161 график совещаний JAR, 178
тестирование совместимости, 161 дополнительные требования JAR, 187
тестирование функциональных возмож­ интервью с экспертами JAR, 186
ностей, 161 метод JAD, 43
эксплуатационные испытания, 161 метод JAR, 43; 173; 174
требован и я к специалисту , 144 правила совещаний JAR, 175
идеальный тестировщик, 145 фак т о р ы, 36
опрос претендентов, 155 Фу н к ц и о н а л ь н а я п р о в е р к а , 4 3
характерные ошибки, 148 Фу н кц и он ал ьн а я с п е ц и ф и к а ц и я , 40 ; 6 1
цикл , 146; 155; 157; 168; 340; 341
человечески й ф а к то р , 142; 143
Т е с т и р о в а н и е п р о г р а м м н о г о об есп еч е ­
н и я , 12; 17; 20; 56 ; 162; 16 3 Х р а н и л и щ е те с то в , 9 3
Т е с т и р о в щ и к . См. С п е ц и а л и с т п о тести ­
р о в а н и ю , 19 Ш
Т е с тов а я группа . См. Групп а те с ти ров а ­ Ша р н и р н о - к а с к а д н а я модель , 48 ; 161
н и я , 2 1 ; 27 ; 28 ; 32 ; 76 ; 6 0
Тестовый набор, 92
Т е с т о в ы й случай , 3 6
Эскизн ый проек т, 30
автоматизация , 98; 138
 Научно-популярное издание

Роберт Калбертсон, Крис Браун, Гэри Кобб

Б ы с т р о е тестирован и е

Издательский дом "Вильямc".

101509, Москва, ул. Лесная, д. 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.

Подписано в печать 30.07.2002. Формат 70x100/16.

Гарнитура NewBaskerville. Печать офсетная.
Усл. печ. л. 30,96. Уч.-изд. л. 24,43.
Тираж 3500 экз. Заказ № 1078.

Отпечатан о с диапозитивов в ФГУП "Печатный двор "

Министерства РФ по делам печати,
телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.