Быстрое тестирование [Роберт Капбертсон] (pdf) читать онлайн

Оглавление
Предисловие

11

Часть I. Процесс быстрого тестирования

15

Глава 1. П о н я т и е о технологии быстрого тестирования

16

Глава 2. Анализ требований и тестирование

35

Глава 3. Планирование и с п ы т а н и й

56

Глава 4. Проектирование и разработка тестов

98

Глава 5. Системные и с п ы т а н и я

• 118

Глава 6. Вопросы объедин ен ия процессов тестирования
и кадрового обеспечения

142

Часть П. Технологии быстрого тестирования и с о в е т ы

159

Глава 7. Введение в технологии тестирования и с о в е т ы

160

Глава 8. Совместная разработка требований к п р и л о ж е н и ю (JAR):
метод в ы р а б о т к и требований с применением
быстрого тестирования

173

Глава 9. Технологии статического тестирования и с о в е т ы

183

Глава Ю.Технологии динамического тестирования и советы

211

Глава 11. Разработка и использование показателей тестирования:
моделирование и прогнозирование ошибок

241

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

264

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

293

Глава 13. П р и м е р формулирования требований

294

Глава 14. П р и м е р плана тестирования

313

Глава 15. П р и м е р ы п р о е к т и р о в а н и я и разработки тестов

328

Глава 16. П р и м е р сводного отчета по системным и с п ы т а н и я м

368

Литература

377

Предметный указатель

380

Содержание
Предисловие
Ключевые особенности
Структура книги
Об авторах
Благодарности

11
11
12
13
14

Часть I. Процесс быстрого тестирования

15

Глава 1. Понятие о технологии быстрого тестирования

16

Основные определения в области тестирования программного обеспечения
Что такое быстрое тестирование?
Персонал
Процесс комплексных испытаний
Статическое тестирование
Динамическое тестирование
Разработка стратегии быстрого тестирования
Процесс разработки программного обеспечения
Каскадный процесс тестирования
Анализ требований
Планирование испытаний
Проектирование тестов, реализации и отладка
Системное тестирование
Приемочные испытания
Сопровождение
Связь тестирования и разработки
Что дальше
Глава 2. Анализ требований и тестирование
Процесс формулирования требований
Выявление требований
Определение требований
Спецификация требований
Матрица прослеживаемости требований
Тестирование требований
Критерии, используемые при тестировании требований
Использование прототипов
Тестирование в рамках жизненного цикла эволюционного
прототипирования
Что дальше
Глава 3. Планирование испытаний
Стратегия тестирования
Определение объемов тестовых работ

17
19
20
21
21
21
22
22
25
26
28
29
29
30
30
31
34
35
37
39
42
45
47
47
49
50
52
54
56
58
59

Содержание

7

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

62
64
66
69
69
71
73
74
75
77
79
83
85

Глава 4. П р о е к т и р о в а н и е и р а з р а б о т к а т е с т о в
Разработка тестов
О п р е д е л е н и е целей теста
Определение спецификаций ввода
Определение конфигурации средств т е с т и р о в а н и я
Документ проектов тестов
Разработка тестовых случаев
Разработка детализированных методик т е с т и р о в а н и я
Определение ожидаемых результатов
Установка и очистка — тестирование из известного состояния
Шаблон тестового случая
Управление конфигурацией тестового случая
П е р е с м о т р и отладка тестов
Автоматизация тестовых случаев
Ч т о дальше

Глава 5. Системные испытания
Обнаружение и отслеживание д е ф е к т о в
Определение состояний дефектов
Базовые характеристики системы отслеживания дефектов
Как составлять сообщения о дефектах
Анализ обнаруженных дефектов
П р о г о н тестов
Вход в системные испытания
Ц и к л ы тестирования
Регистрация результатов т е с т и р о в а н и я
Составление отчетов по результатам т е с т и р о в а н и я
О т ч е т о ходе работ по тестированию

86
86
95
96
98
99
102
103
103
104
105
107
110
110
111
113
114
115
116

118
120
120
123
128
129
131
131
132
134
135
136

8

Содержание

О т ч е т об устранении дефектов
О т ч е т н ы й доклад
К р и т е р и й выхода из испытаний и готовность выпуска
программного продукта
Ч т о дальше
Глава 6 . В о п р о с ы о б ъ е д и н е н и я п р о ц е с с о в т е с т и р о в а н и я
и кадрового обеспечения
Ч е л о в е ч е с к и й ф а к т о р и тестирование
Качества, которыми должен обладать специалист по тестированию,
чтобы успешно справляться со своими обязанностями
Характерные о ш и б к и
Как проводить о п р о с ы претендентов
Совершенствование процесса тестирования
Модель развития функциональных возможностей
программного обеспечения СММ
Как модель СММ соотносится с быстрым тестированием
Возможности совершенствования процессов
Ч т о дальше

137
138
139
140
142
143
143
145
147'
149
150
153
155
156

Ч а с т ь II. Т е х н о л о г и и б ы с т р о г о т е с т и р о в а н и я и с о в е т ы

159

Глава 7. В в е д е н и е в т е х н о л о г и и т е с т и р о в а н и я и с о в е т ы

160

Область п р и м е н е н и я технологий тестирования
Ж и з н е н н ы й цикл разработки
Преимущества быстрого тестирования
Определение статического тестирования
Определение динамического тестирования
Ж и з н е н н ы й цикл д е ф е к т а
Формальные этапы т е с т и р о в а н и я
Обязанности членов команды тестирования
Ч т о дальше
Глава 8. С о в м е с т н а я р а з р а б о т к а т р е б о в а н и й к п р и л о ж е н и ю (JAR):
метод выработки требований с применением
быстрого тестирования
Методология JAR
Роль специалистов по тестированию в процессе JAR
Резюме
Глава 9. Т е х н о л о г и и с т а т и ч е с к о г о т е с т и р о в а н и я и с о в е т ы
Цикломатическая сложность и ее взаимосвязь с выполнением тестирования
П р и м е р представления проекта модуля в виде графа
Формальная о ц е н к а
П р и м е н е н и е к о н т р о л ь н ы х перечней
Аудит
И н с п е к ц и и / к р и т и ч е с к и й а н а л и з / экспертные о ц е н к и
Распределение р о л е й и обязанностей в группе в ы п о л н е н и я инспекций
О т ч е т н о с т ь о процессе выполнения инспекций

160
161
164
165
166
167
169
170
172

173
174
181
182
183
184
185
189
191
192
195
195
198

Содержание

Показатели процесса и н с п е к ц и и
Использование э л е к т р о н н о й почты или другого электронного
приложения для ускорения процесса инспекции
Формальная в е р и ф и к а ц и я
Языки на основе с п е ц и ф и к а ц и й
Автоматизированное доказательство теорем
Средства автоматизации тестирования
Прослеживаемость т р е б о в а н и й
Программа к о н т р о л я единиц измерения ф и з и ч е с к и х величин
Символьное в ы п о л н е н и е
Листинги перекрестных ссылок
Программы улучшенной печати
Средства сравнения версий
Тестирование алгоритмов
Диспетчер тестирования
Базы данных материалов совместного использования
Резюме
Глава 10. Т е х н о л о г и и д и н а м и ч е с к о г о т е с т и р о в а н и я и с о в е т ы
Функциональное т е с т и р о в а н и е и анализ
Разделение по классам эквивалентности
Анализ граничных з н а ч е н и й
Отрицательное т е с т и р о в а н и е
Тестирование на основе определения степени риска
Определение полноты охвата ветвей п р и т е с т и р о в а н и и
Тестирование случаев использования
Псевдоотладка/видоизменение
Т р а с с и р о в к а / т р а с с и р о в к а снизу в в е р х / мгновенные д а м п ы / п о с т п е ч а т ь
Создание точек п р е р ы в а н и я / п р а в к и
Тестирование потока данных
Тестирование на предмет утечек памяти
•Тестирование и н т е р ф е й с а "человек-компьютер"
Тестирование нагрузочной э ф ф е к т и в н о с т и
Тестирование конфигурации п л а т ф о р м ы
Резюме
Глава 11. Р а з р а б о т к а и и с п о л ь з о в а н и е п о к а з а т е л е й т е с т и р о в а н и я :
моделирование и прогнозирование ошибок
Определение показателей и данных измерений
Использование стандартных показателей для внесения усовершенствований
Показатели т е с т и р о в а н и я
Плотность ошибок (количество ошибок на тысячу
эквивалентных ст р о к кода)
Проектно-ориентированная модель ошибок
Программа оценки ошибок программного обеспечения (SWEEP)
Резюме

9

198
198
200
201
201
202
202
202
203
204
204
205
205
208
210
210
211
213
214
215
215
217
220
224
226
227
228
230
231
233
234
238
240
241
242
251
255
256
257
259
263

10

Содержание

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

264
268
287
290

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

293

Глава 13. Пример формулирования требований

294

Набор инструментальных средств управления тестированием. Версия 1.0
Глава 14. Пример плана тестирования
Набор инструментальных средств управления тестированием. Версия 1.0
Глава 15. Примеры проектирования и разработки тестов
Набор инструментальных средств управления тестированием. Версия 1.0
Глава 16. Пример сводного отчета по системным испытаниям
Набор инструментальных средств управления тестированием. Версия 1.0

296
313
315
328
333
368
370

Литература

377

Предметный указатель

380

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

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

12

Предисловие

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

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

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

Предисловие

13

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

План тестирования

•

С п е ц и ф и к а ц и я тестовой процедуры

•

Сводный отчет о тестировании.

Об авторах
Роберт Калбертсон (Robert Culbertson) имеет о п ы т р а б о т ы в технических областях,
в сфере разработки и тестирования программного обеспечения, а также опытом ру­
ководства разработкой различных проектов. Работая в компаниях Cisco Systems,
Texas Instruments, IBM, в Техасском университете, в компании DSC Communications,
он приобрел л и ч н ы й опыт работы с тем, что составляет быстрое тестирование. Ро­
берт имеет ученые степени бакалавра электротехники и электроники (B.S.E.E.) и ма­
гистра электротехники и электроники (M.S.E.E.), полученные в Техасском универси­
тете в Остине, а также степень доктора ф и л о с о ф и и в области электротехники и элек­
т р о н и к и от Бирмингемского университета в Англии.
Гэри К о б б (Gary Cobb) в т е ч е н и е 25 лет поднимался сразу по двум служебным ле­
стницам, как преподаватель и как специалист, р а б о т а ю щ и й в промышленной зоне
города О с ти н . Он занимался преподавательской деятельностью в Техасском универ­
ситете в О с т и н е на отделениях математики, компьютерных наук, электротехники и
производства компьютеров. Гэри также вел курс мультимедиа-систем на факультете
компьютерных наук в Юго-западном университете штата Техас, в котором занимал
пост руководителя л а б о р а т о р и и мультимедиа-систем. Его послужной список в про­
мышленности включает работу на ответственных должностях в компаниях Texas In­
struments Inc., Lockheed Martin и Dell C o m p u t e r Corporation. Он читает краткие кур­
сы в институте качества программного обеспечения при Техасском университете,
который выступил спонсором его разработки к р и т е р и е в программного обеспечения,
увенчавшейся присуждением ему премии Greater Austin Quality Award (Победитель по
качеству в О с т и н е ) . Гэри имеет степень доктора ф и л о с о ф и и в области математики,
полученную в Техасском университете в Остине.
Крис Браун (Chris Brown) работает в компьютерной индустрии и индустрии про­
граммного обеспечения более 20 лет. Занимаясь вопросами тестирования, он работал
на различных должностях в таких компаниях, как Advanced Micro Devices, Cisco Sys­
tems, C o m p a q C o m p u t e r Corporation и IBM. В компании Advanced Micro Devices он
отвечал за системные испытания результатов генерации кремниевых компиляторов
и за проверку на совместимость всех конфигураций аппаратных и программных
средств. В компании C o m p a q Крис отвечал на построение тестовых сценариев и тес­
тирование прототипов и опытных образцов систем для отделения портативных ком­
пьютерных продуктов. Будучи сотрудником компании IBM, Крис возглавлял команду
тестирования администратора баз данных O S / 2 , администратора передачи данных и
администратора локальной сети. Он был п р е з и д е н т о м / г л а в н ы м администратором в
Computer Security Corporation, компании, которая поставляла программные средства
защиты от вирусов военно-воздушным силам США, а также компаниям Prudential,

14

Предисловие

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

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

Процесс быстрого
тестирования

Понятие о
технологии быстрого
тестирования
Темы, рассматриваемые в главе:
•

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

•

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

•

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

•

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

•

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

•

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

•

Что дальше

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

Глава 1. П о н я т и е о технологии быстрого тестирования

•

17

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

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

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

18

Часть I. П р о ц е с с быстрого тестирования

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

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

ТМТ-ТР-10

Идентификатор документа: ТМТ-ТР-10
Версия: 0.8
Авторы: Крис Браун (Chris Brown)
Джеймс Варне (James Barnes)

Набор инструментальных средств управления тестированием
Версия 1.0

План тестирования
Хронология версий
Версия

Дата

Автор

Описание

0.1

09/02/2001

Крис Браун

Эскиз плана тестирования для документа
определения требований: TMT-RS-05

0.2

09/03/2001

Крис Браун

Доводка и синхронизация с: TMT-TS-05

0.3

09/03/2001

Крис Браун

Начато построение детализованных тестовых
случаев

0.4

09/05/2001

Крис Браун

Построение тестовых случаев завершено.
Окончательная доводка

0.5

09/06/2001

Крис Браун

Основная доводка и очистка, дополнительные
тестовые случаи, заключительный формат

0.6

09/07/2001

Крис Браун

Заключительная синхронизация с TMT-RS-07,
добавлены тесты многопользовательского
режима

0.7

09/09/2001

Крис Браун

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

0.8

09/10/2001

Джеймс Варне

Конфигурации тестов, оценка трудозатрат и
календарный график

Утверждено
Отдел

Дата утверждения

Маркетинга

Чак Д. Клут (Chuck D. Klout),
директор отдела маркетинга

09/11/2001

Программирования

Сюзанна Перл (Suzanna Perl),
менеджер отдела программирования

09/12/2001

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

Брит Гейтер (Bret Gater),
менеджер отдела тестирования

09/12/2001

315

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

ТМТ-ТР-10

Содержание
1. Введение
2. Тестируемые элементы
3. Свойства, которые должны тестироваться
4. Свойства, которые не должны тестироваться
5. Применяемый подход
5.1. Тестирование свойств
5.2. Регрессионное тестирование
5.3. Установка продукта
5.4. Резервное копирование и восстановление
5.5. Тестирование графического интерфейса пользователя
6. Критерий успешных и неудачных испытаний
7. Критерий приостановки испытаний и требования возобновления испытаний
8. Выходные результаты тестов
9. Задачи тестирования
10. Конфигурации тестов
11. Распределение ответственности
12. Подбор кадров и подготовка персонала
13. Календарный график
14. Риски и непредвиденные обстоятельства
Ссылки
Приложение 1 —Список аббревиатур
Приложение 2 — Определение терминов
Приложение 3 — Сообщения электронной почты от утверждающих лиц
От: Чак Д. Клут (Chuck D. Klout) [cdklout@tmtco]
От: Сьюзи Перл (Suzie Perl [spent@tmtco.com]
От: Брит Гейтер (Bret Gater) [bgater@tmtco.com]

316
317
317
318
318
318
318
319
319
319
319
319
320
320
323
323
324
324
325
325
326
326
326
326
327
327

1. Введение
Назначение этого документа состоит в детализации процедур тестирования, которые должны атте­
стовать функциональные возможности программного продукта ТМТ. Свойства, на которые произво­
дятся ссылки в этом документе, находятся в документе определения требований, именуемого "На­
бор инструментальных средств управления тестированием, Определение требований". Документ,
определяющий требования, имеет идентификатор TMT-RD-10 и находится под управлением систе­
мы контроля документов на Web-сайте:
http//www .tmtcointernal.com/usr/www/docstores/desiqn/reauirements/TMT-RD-10.doc
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. Клиентские и серверные операционные системы
Клиентская операционная система

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

Microsoft Windows

Microsoft Windows

- Windows 85

- Windows NT 3.51 и выше

- Windows 98

UNIX

- Windows ME

- Sun Solaris 2.6 и выше

- Windows XP

- HPUX 10.x и выше

- Windows NT 3.51 и выше

- Open BSD

- Windows 2000

- AIX 2.4.1. и выше

Apple

- SCO Open Desktop

- MAC OS 9.x и выше

- Linux Red Hat 6.x и выше

Как показано в таблице 9.1, имеется семь клиентских и семь серверных операционных систем, упо­
мянутых в определении списка требований. При этом необходимо, чтобы использовалась только
одна операционная система из списка, куда входят Windows NT, Solaris 2.6, OS9.X и Linux 6.x. Следо­
вательно, существует 49 возможных комбинаций клиентских и серверных операционных систем.
Установка каждой комбинации системы клиент/сервер требует в среднем 5 часов. Общее время,
необходимое для тестирования процесса установки продукта, составляет 5 х 49 = 245 часов, или
около 30 рабочих дней. Обратите внимание, что процесс предполагает установку операционной сис­
темы, приложения реляционной базы данных и приложения ТМТ для клиента и сервера, а также
установку клиентского браузера. Если запланировать тестирование свойств и резервного копирова­
ния для всех 49 комбинаций, объемы времени, необходимого для тестирования ТМТ, возрастут до
немыслимых размеров.
Вследствие больших временных затрат на тестирование всех возможных комбинаций, во время
выполнения тестирования процесса установки продукта используют лишь подмножество комбинаций
клиент/сервер, которое показано в таблице 9.2.
Таблица 9.2. Выбранные комбинации операционных систем, применяемые при
тестировании установки продукта
Комбинация

Клиентская операционная система

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

1

- Windows 95

- Windows NT 3.51

2

- Windows 98

- Sun Solaris 2.6

3

- Windows ME

-HPUX 10.1

4

- Windows XP

- Open BSD

5

- Windows NT 3.51

- AIX 2.4.1 и выше

6

- Windows 2000

- Linux 6.5

7

- MAC OS 9.0

- SCO Open Desktop

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

321

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

ТМТ-ТР-10

вания/восстановления количество комбинаций клиент/сервер может быть сокращено до двух конфи­
гураций (см. таблицу 9.3).

Таблица 9.3. Выбранные комбинации операционных систем, применяемые при
тестировании свойств и резервного копирования/восстановления
Комбинация

Клиентская операционная система

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

1

- Windows 98

- Sun Solaris 2.6

2

- Windows 2000

- Linux 6.5

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

Таблица 9.4. Оценки трудозатрат для каждого цикла тестирования
Задача

Время (часы)

Тестирование процесса установки продукта

35

Прогон тестов свойств и построение отчетов по ошибкам

16

Верификация исправлений ошибок

24

Тесты резервного копирования и восстановления

24

Тестирование графического интерфейса пользователя

16

Отчет о состоянии тестирования

16

Ведение обзоров по ошибкам

8
Итого

322

139

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

ТМТ-ТР-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", руководимые Дж. Барнсом (J.Barnes). Все обучение должно
завершиться до передачи разработчиками первой программной сборки в команду тестирования.
Таблица 12.1. Персонал тестеров
Сотрудник

Должность

Ответственность

Доступность

Дж. Варне

Руководитель отдела
тестирования

Координация тестирования,
построение отчетов и
тестирование свойств

100 %

Д. Нгуен

Тестировщик

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

100%

С. Скефиди

Тестировщик

Тесты резервного
копирования/восстановления

50%

К. Тейлор

Тестировщик

Тесты графического интерфейса
пользователя

50%

Б. Вилер

Разработчик

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

100 %

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

324

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

ТМТ-ТР-10

Таблица 13.1. Календарный график тестирования продукта ТМТ
Задача

Дата
начала

Дата
завершения

Установка и отладка тестовых конфигураций #1 и #2

10/1

10/12

Испытание герметичности на предварительной сборке

10/15

10/19

Цикл тестирования #1

10/22

11/2

Цикл тестирования #2

22/5

11/16

Цикл тестирования #3

11/19

11/30

Пересмотр степени готовности

12/3

12/3

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

14. Риски и непредвиденные обстоятельства
В таблице 14.1 перечислены риски, связанные с процессом тестирования продукта ТМТ, вместе с
оценочными значениями вероятностей их возникновения, влиянием и кратким описанием плана
смягчения этого влияния.

Таблица 14.1. Идентификация рисков и меры по смягчению их воздействия
Риск

Вероятность

Влияние

Смягчение влияния

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

75%

Основное

Руководитель команды
тестирования должен
постоянно принимать
участие во встречах
разработчиков и по мере
получения новой
информации
пересматривать тестовые
случаи.

К. Тейлор может отсутствовать
на работе в течение всего
ноября по семейным
обстоятельствам. Ее
отсутствие привело бы к
смещению графика на 2 дня в
каждом тестовом цикле.

50%

Незначи­
тельное

Один из разработчиков
графического интерфейса,
Р. Карини (R. Carini),
согласился выполнить его
тестирование, а С.
Скефиди должен
подготовить обзор
результатов прогона
тестов, если Тейлор будет
отсутствовать.

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

20%

Незначи­
тельное

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

325

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

ТМТ-ТР-10

Ссылки
Chris Brown, Test Management Toolkit, Requirements Definition (Набор инструментальных средств
управления тестированием, Определение требований). Документ TMT-RD-10, который размещает­
ся под управлением системы контроля документов по адресу:
http://www.tmtcointemal.corn/usr/www/docstores/desian/reauirements/TMT-RD-10.doc

Приложение 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 (Международная организация по стандартизации)
PPC — 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@tmtco.com
От:

Сьюзи Перл

(Suzie Perl [spent@tmtco.com]

Отправлено: четверг 9/12/2001 09:30
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: План тестирования ТМТ 1.0
Привет всем,
Хорошая работа! Я просмотрела план тестирования ТМТ-ТР-10, версия 8, для первой версии ТМТ и
утверждаю его в том виде, в котором он написан.
С наилучшими пожеланиями,
Сьюзи
Сюзанна Перл
Менеджер, отдел программирования
ТМТСО

От: Брит Гвйтер (Bret Gater) [bgater@tmtco.com]
Отправлено: четверг 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 и затем помещены в документ опи­
сания спецификаций.

> На системные испытания
Рис. 15.1. Проектирование и реализация тестов

Процесс проектирования тестов в рассматриваемом примере тесно завязан на
формат, определенный в главе 4, который для удобства приводится на рис. 15.2.
Рассматриваемая в данной главе таблица имеет сходство с матрицей прослеживаемости требований (Requirements Traceability Matrix, RTM), которая обсуждалась в

330

Часть III. Процесс быстрого тестирования

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

Идентификатор
системного
тестового случая

Входные
данные
теста

Конфигурация
теста

Цель
теста

RD2.2.1

ST2.2.4

TP_lnput1.doc

ТС2.0

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

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

Глава 15. Примеры проектирования и разработки тестов

331

подчеркнуть факт сохранения идей, лежащих в основе шаблона тестового случая,
последний еще раз приводится на рис. 15.3.
Основными элементами шаблона тестового случая являются:
• Идентификатор тестового случая — включает номер версии.
• Владелец теста — имя и фамилия того, кто поддерживает тест (это не всегда ав­
тор теста).
• Дата создания последней версии — помогает уточнить, является ли версия теста
актуальной.
• Имя теста — описательное название теста, которое упрощает его поиск и пони­
мание его содержания. Не рекомендуется использовать имена, не имеющие
смысловой нагрузки, наподобие "xxxLLL0123.tst".
• Расположение теста — полный путь, включая имя сервера.
• Тестируемое требование — должен указываться уникальный идентификатор
требования из документа описания требований.
• Цель тестирования — краткое и ясное изложение цели, которая достигается
данным тестом. Более подробную информацию можно найти в разделе "Опре­
деление целей теста" главы 4).
• Конфигурация теста — спецификации входных и выходных данных, а также
описание среды тестирования.
• Установка теста — по аналогии с процедурой тестирования, описываются дей­
ствия, которые должен выполнять тестировщик, и ожидаемые результаты. Ес­
ли процесс установки автоматизирован, то сама установка может принимать
форму единственной команды, например, run setupSC03 . p i .
• Процедура тестирования — описание действий, которые должен выполнить
тестировщик, и ожидаемый результатов.
• Взаимозависимости тестовых случаев — определение тестовых случаев, кото­
рые необходимо выполнить перед данным тестовым случаем, чтобы достигнуть
известных начальных условий.
• Очистка теста — если система переводится в нестабильное состояние или же ей
передаются преднамеренно запорченные данные, то при помощи очистки
можно выполнить откат.

332

Часть Ш. Процесс быстрого тестирования

Информация о тестовом случае
Идентификатор тестового случая

SC03 ver3.0

Владелец теста

Джин Дуглас (Jean Douglas)

Местонахождение теста (путь)

TestServer:D:\TestProject\TestSuite\SC03.doc

Дата последнего пересмотра

Месяц/день/год

Тестируемое требование

SC101

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

ST02

Взаимозависимость тестовых случаев

Выполнить прогон теста SC01 и его настройку
перед прогоном данного теста.

Цель теста

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

Не проводится

Настройка на прогон теста

Шаг

Действие

Ожидаемый результат

Отметка (V)

1.

Щелкнуть на элементе "Стоимость
доставки" в главном меню.

Отображается меню "Стоимость
доставки"

(V)

2.

Ввести "101" в поле веса
доставляемого груза

Сообщение об ошибке
"Неправильно указан вес
доставляемого груза"

(V)

3.

Ввести "0" в поле веса
доставляемого груза

Сообщение об ошибке
"Неправильно указан вес
доставляемого груза"

X

4.

Ввести "100" в поле веса
доставляемого груза

Указан вес доставляемого груза
"100 унций"

(V)

5.

Ввести " 1 " в поле веса
доставляемого груза

Указан вес доставляемого груза
"1 унция"

(V)

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

Не производится

N/A

Результаты теста
Тестировщик: JD

Дата прогона теста: месяц/день/год

Результат теста (P/F/B): F

Примечания:
- Тест потерпел неудачу на шаге 3.
- При возникновении неисправности выдается код ошибки BR1011.

Рис. 15.3. Пример тестового случая

Спецификация тестовой процедуры ТМТ

TMT-TPS-10

Идентификатор документа: TMT-TPS-10
Версия: 0.5
Авторы: Крис Браун (Chris Brown)
Джеймс Барнс (James Barnes)

Набор инструментальных средств управления тестированием
Версия 1.0

Спецификация тестовой процедуры
Хронология версий
Версия

Дата

0.1

08/29/2001

Джеймс Барнс

Описание
Проекты тестов

0.2

09/03/2001

Крис Браун

Начато создание детализованных тестовых
случаев

0.3

09/05/2001

Крис Браун

Завершено создание тестовых случаев

0.4

09/06/2001

Крис Браун

Основная доводка после пересмотра тестовых
случаев

0.5

09/10/2001

Джеймс Барнс

Обсуждение тестов графического интерфейса
и процесса установки

Утверждено
Дата утверждения
Программирования

Сюзанна Перл (Suzanna Perl),
менеджер отдела программирования

09/11/2001

Маркетинга

Чак Д. Клут (Chuck D. Klout),
директор отдела маркетинга

09/12/2001

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

Брит Гейтер (Bret Gater),
менеджер отдела тестирования

09/12/2001

333

Спецификация тестовой процедуры ТМТ

TMT-TPS-10

Содержание
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@tmtco.com]
От: Брит Гейтер (Bret Gater) [bgater@tmtco.com]
334

335
335
336
338
338
339
340
340
341
341
341
341
352
353
354
354
355
355
356
356
356
357
357
358
358
358
359
359
360
360
361
361
362
362
363
363
364
364
364
365
365
366
366
367
367
367
367
367

Спецификация тестовой процедуры ТМТ

TMT-TPS-10

1. Введение
Целью создания этого документа является подробное описание тестовых процедур, разработанных
для аттестации функциональных возможностей программного продукта, именуемого набором инст­
рументальных средств управления тестированием (Test Management Toolkit, ТМТ). Свойства, на ко­
торые производятся ссылки в этом документе, находятся в документе определения требований,
именуемого "Набор инструментальных средств управления тестированием, Определение требова­
ний". Документ, определяющий требования, имеет идентификатор TMT-RD-10 и находится под
управлением системы контроля документов на Web-сайте:
httD//www.tmtcointernal.com/usr/www/docstores/desian/reauirements/TMT-RD-10.doc
Разработка тестов основывается на плане тестирования ТМТ, который находится в документе ТМТТР-10, расположенном на Web-сайте:
http//www,tm tcointernal.com/usr/www/docstores/desian/reauirements/TMT-TP-10.doc
Проекты тестов описаны в разделе 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. В таблице
приведены идентификаторы требований, идентификаторы тестов, входные данные и конфигурация
для тестов, а также цели прогона каждого теста. Некоторые функциональные возможности, такие как
экспорт данных и экраны справочной системы, вынесены за пределы основной массы тестов функ­
циональных возможностей, поскольку в первой сборке они не реализованы. Эти возможности
рассматриваются в разделе "Дополнительные возможности".
Таблица 3 . 1 . Разработка тестов свойств
Цель
проведения
теста

Идентификатор
требования

Идентификатор
системного
тестового случая

Входные
данные
теста

RD3.1.1

ТСЗ.1.1

Нет

Тестовая
конфигурация
#1

Проверка доступности поль­
зовательского интерфейса
ТМТ путем вызова главного
меню

RD3.1.2

ТСЗ. 1.2

Нет

Тестовая
конфигурация
#1

Проверка доступности поль­
зовательского интерфейса
ТМТ путем навигации в рам­
ках меню

RD3.1.3

ТСЗ. 1.3

Учетные
записи
пользо­
вателей

Тестовая
конфигурация
#1

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

RD3.1.4

ТСЗ. 1.4

Учетные
записи
админи­
страторов

Тестовая
конфигурация
#1

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

RD3.1.5

ТСЗ. 1.5

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

Тестовая

конфигурация

336

Спецификация тестовой процедуры ТМТ

TMT-TPS-10
Продолжение табл. 3.1

Идентификатор
требования

Идентификатор
системного
тестового случая

Входные
данные
теста

Тестовая
конфигурация

RD3.1.6

ТСЗ. 1.6

Пример
данных по
проекту

Тестовая
конфигурация
#1

Проверка возможности про­
смотра завершенных проек­
тов аутентифицированными
пользователями

RD3.1.7

ТСЗ. 1.7

Пример
данных
инфор­
мации
теста

Тестовая
конфигурация
#1

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

RD3.1.8

ТСЗ. 1.8

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.9

ТСЗ. 1.9

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.10

ТСЗ.1.10

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.11

ТСЗ.1.11

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.12

ТСЗ.1.12

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.13

ТСЗ.1.13

Пример
данных по
проекту

Тестовая
конфигурация
#1

Проверка возможности заре­
гистрированного пользова­
теля отображать (просмат­
ривать) тестовые случаи,
связанные с проектом

RD3.1.14

ТСЗ.1.14

Пример
данных по
проекту

Тестовая
конфигурация
#1

Проверка возможности заре­
гистрированного пользова­
теля отображать (просмат­
ривать) тестовые наборы,
связанные с проектом

RD3.1.15

ТСЗ.1.15

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

337

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

Спецификация тестовой процедуры ТМТ

TMT-TPS-10
Окончание табл. 3.1

Идентификатор
требования

Идентификатор
системного
тестового случая

Входные
данные
теста

Тестовая
конфигурация

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

RD3.1.16

ТСЗ.1.16

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.17

ТСЗ.1.17

Пример
данных по
проекту

Тестовая
конфигурация
#1

Проверка возможности соз­
дания списка прогона для
проекта

RD3.1.18

ТСЗ.1.18

Пример
данных по
проекту

Тестовая
конфигурация
#1

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

RD3.1.19

ТСЗ.1.19

Пример
данных по
ошибкам

Тестовая
конфигурация
#1

Проверка возможности ото­
бражения (просмотра) заре­
гистрированным пользова­
телем списка всех ошибок
проекта

RD3.1.20

ТСЗ.1.20

Пример
результа­
тов про­
гона теста

Тестовая
конфигурация
#1

Проверка возможности ото­
бражения (просмотра) заре­
гистрированным пользова­
телем результатов прогона
тестового случая

RD3.1.21

ТСЗ. 1.21

Пример
результа­
тов про­
гона теста

Тестовая
конфигурация
#1

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

RD3.1.22

ТСЗ. 1.22

Пример
данных по
требован
иям

Тестовая
конфигурация
#1

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

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

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

338

Спецификация тестовой процедуры ТМТ

TMT-TPS-10

Проекты тестов для резервного копирования и восстановления показаны в таблице 3.2. В таблице
отражены идентификаторы требований, идентификаторы тестов, входные данные и конфигурация
для тестов, а также цели прогона каждого теста.

Таблица 3.2 Разработка теста операций резервного копирования/восстановления
Идентификатор
требования

Идентификатор
системного
тестового случая

Входные
данные
теста

Тестовая
конфигурация

RD3.1.23

ТСЗ. 1.23

Пример
тестовых
данных

Тестовая
конфигурация
#1

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

RD3.1.24

ТСЗ. 1.24

Пример
тестовых
данных

Тестовая
конфигурация
#1

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

RD3.1.25

ТСЗ. 1.25

Пример
тестовых
данных

Тестовая
конфигурация
#1

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

RD3.1.26

ТСЗ. 1.26

Пример
данных для
резервного
копирова­
ния

Тестовая
конфигурация
#1

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

RD3.1.27

ТСЗ.1.27

Пример
данных для
резервного
копирова­
ния

Тестовая
конфигурация
#1

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

RD3.1.28

ТСЗ. 1.28

Пример
данных для
резервного
копирова­
ния

Тестовая
конфигурация
#1

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

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

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

339

С п е ц и ф и к а ц и я тестовой процедуры Т М Т

TMT-TPS-10

Таблица 3.3. Разработка теста для дополнительных свойств
Цель
проведения
теста

Идентификатор
требования

Идентификатор
системного
тестового случая

Входные
данные
теста

Тестовая
конфигурация

RD3.1.29

ТСЗ.1.29

Пример
тестовых
данных

Тестовая
конфигурация
#1

Проверка возможности
зарегистрированного
пользователя экспортиро­
вать одиночный тестовый
случай

RD3.1.30

ТСЗ. 1.30

Пример
тестовых
данных

Тестовая
конфигурация
#1

Проверка возможности
зарегистрированного
пользователя экспортиро­
вать тестовый набор во
внешнее приложение

RD3.1.31

ТСЗ. 1.31

Пример
тестовых
данных

Тестовая
конфигурация
#1

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

RD3.1.32

ТСЗ. 1.32

Нет

Тестовая
конфигурация
#1

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

RD3.1.33

ТСЗ. 1.33

Пример
данных для
проекта и
теста

Тестовая
конфигурация
#1

Проверка возможности
одновременной работы 5
пользователей

3.4. Установка

продукта

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

графического

интерфейса

пользователя

При тестировании графического интерфейса продукта ТМТ используется следующий подход:
•

Графический интерфейс пользователя тестируется в браузерах Netscape Navigator и Microsoft
Internet Explorer. При этом должен быть просмотрен полный состав интерфейса, а также про­
тестированы возможности навигации в обоих браузерах.

•

Все действия по тестированию выполняются в ручном режиме.

340

Спецификация тестовой процедуры ТМТ
•

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 Projects'1 ("Текущие проектьГ'У
Ожидаемый результат 1:
Отображается экран, озаглавленный "Current Projects"("TeKym,He проекты"), который содержит проект
или несколько проектов.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие текущих проектов (если данный
тестовый случай выполняется до создания проектов).
В окне браузера щелкните на стрелке назад для возврата в главное меню.
Ожидаемый результат 3:
Пользователь должен вернуться в главное меню.
Случай 4
В главном меню выберите пункт "Completed Projects" ("Завершенные проектьП.
Ожидаемый результат 1:
Отображается экран с заголовком "Completed Projects"("3aBepLueHHbie проекты"), который содержит
проект или несколько проектов.
Ожидаемый результат 2:
Отображается сообщение об ошибке, указывающее на отсутствие текущих проектов (если данный
тестовый случай выполняется до создания проектов).
В окне браузера щелкните на стрелке назад для возврата в главное меню.
Ожидаемый результат 3:
Пользователь должен вернуться в главное меню.
Случай 5
В главном меню выберите ПУНКТ "Project Maintenance" ("Сопровождение проекта^.
Ожидаемый результат 1:
Отображается экран с заголовком "Project Ма1п1епапсе"("Сопровождение проекта").
Ожидаемый результат 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.

350

Спецификация тестовой процедуры ТМТ

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

Userl

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" ("Введено невер­
ное имя пользователя или пароль").
Введите "Userl" для имени пользователя, а в качестве пароля укажите "pickle".
Ожидаемый результат 4:
Отображается сообщение об ошибке "You entered an invalid Username or Password" ("Введено невер­
ное имя пользователя или пароль").
Введите "Userl" для имени пользователя, а в качестве пароля укажите "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

Введите "Userl" для имени пользователя, а в качестве пароля укажите "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" ("Введено невер­
ное имя пользователя или пароль").
Введите "Userl" для имени пользователя, а в качестве пароля укажите "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

Спецификация тестовой процедуры ТМТ
5.23. ТС

3.1.23

Резервное

TMT-TPS-10

копирование/Результаты

прогона

тестов

После регистрации в системе пользователь получает возможность выполнить резервное копирова­
ние результатов прогона тестов. Для этого необходимо в меню 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

Спецификация тестовой процедуры ТМТ

5.25. ТС

3.1.25

TMT-TPS-10

Восстановление/Тестовые

наборы

После регистрации в системе пользователь получает возможность восстанавливать тестовые набо­
ры по оригинальному их расположению. Для этого необходимо в меню 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

Спецификация тестовой процедуры ТМТ
5.27. ТС

3.1.27

Экспорт/Тестовые

TMT-TPS-10

случаи

После регистрации в системе пользователь имеет возможность выполнять экспорт тестовых случаев
для использования их в других приложениях. Для этого необходимо в меню 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. Пользователи User-!, User2. User3. User4 и User5 в произвольном порядке создают проект,
тестовые случаи и наборы.
Ожидаемый результат 1:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.
Случай 2
18:15. Пользователи Userl. User2. User3. User4 и User5 в произвольном порядке вводят результаты
тестирования для тестовых случаев и наборов.

365

Спецификация тестовой процедуры ТМТ

TMT-TPS-10

Ожидаемый результат 1:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.
Случай 3
18:30. Пользователи User-!, User2. User3. User4 и User5 выдают запросы на получение отчетов на
уровне проекта, тестового набора и результатов прогона тестовых случаев.
Ожидаемый результат 3:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.
Случай 4
18:45. Пользователи Userl, User2. User3. User4 и User5 выводят на принтер результаты запросов.
Ожидаемый результат 4:
Предполагается, что каждый пользователь сможет исполнить свои функции без каких-либо заметных
отклонений.
Успешное завершение этого теста подтверждает возможность выполнения приведенных выше
действий без сбоев в работе системы. Потенциальные отклонения в функционировании системы
должны быть описаны дополнительно. Неудовлетворительный результат тестирования свидетель­
ствует о невозможности выполнения указанных функций. Если такая проблема существует, для по­
лучения характеристики отказа следует начать с одного пользователя и добавлять каждый раз по
одному до тех пор, пока не возникнет системный отказ. Предполагается, что все указанные действия
исполняются без каких-либо заметных отклонений.

Ссылки
Chris Brown, Test Management Toolkit, Requirements Definition (Набор инструментальных средств
управления тестированием, Определение требований). Документ TMT-RD-10, который размещает­
ся под управлением системы контроля документов по адресу:
http://www.tmtcointernal.com/usr/www/docstores/design/requirements/TMT-RD-10.doc
Chris Brown and J. Barnes, Test Management Toolkit, Test Plan (Набор инструментальных средств
управления тестированием, План тестирования). Документ ТМТ-ТР-10, который размещается под
управлением системы контроля документов по адресу:
http://www.tmtcointernal.com/usr/www/docstores/design/plans/TMT-TP-10.doc

Приложение 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
Тема: Тестовые процедуры, версия TMT 1.0
Уважаемые члены команды,
Я просмотрел документ спецификации тестовых процедур, TMT-TPS-10, версия 5, и пришел к выво­
ду, что он весьма точно покрывает тестирование требований в данной версии. Я утверждаю этот
документ в том виде, в котором он написан. Сокращенный список оборудования и операционных
систем, которые будут участвовать в тестировании, обсужден с несколькими заказчиками и утвер­
жден в своей первой версии.
Спасибо, Чак
Чак Д. Клут
Директор отдела маркетинга
ТМТСО

От: Сьюзи Перл (Suzie Perl [spent@tmtco.com]
Отправлено: четверг 9/12/2001 09.30
Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco
Копия: marketing@tmtco; customersupport@tmtco
Тема: План тестирования ТМТ 1.0
Привет всем,
Мы вместе с командой просмотрели тестовые процедуры TMT-TPS-10, версия 5, для первой версии
приложения ТМТ и утверждаем их в том виде, в котором они были написаны.
С наилучшими пожеланиями, Сьюзи
Сюзанна Перл
Менеджер, отдел программирования
ТМТСО
От:

Брит

Гейтер

(Bret Gater) [bgater@tmtco.com]

Отправлено: четверг 9/12/2001 07:30
Кому: Крис Браун [cbrown@tmtco]; test@tmtco; development@tmtco
Копия: marketing@tmtco; costumersupport@tmtco
Тема: План тестирования ТМТ 1.0
Уважаемые члены команды,
Я просмотрел тестовые процедуры TMT-TPS-10, версия 5, и утверждаю его для использования ко­
мандой тестеров в том виде, в котором они написаны.
С наилучшими пожеланиями, Брит
Брит Гейтер
Менеджер, отдел программирования
ТМТСО

367

Пример сводного
отчета по
системным
испытаниям
В главе 5 подробно обсуждался этап системных испытаний процесса разработки про­
дукта. Там же отмечалось, что этот этап выглядит подобно дню соревнований для
спортсмена либо дню представления для театрального актера. Большая часть опера­
ций по планированию и тестированию уже выполнена, "установлены подмостки" и
наступило время действий. На рис. 16.1 показан этап системных испытаний.
В соответствии с рис. 16.1, первой задачей, выполняемой на этапе системных ис­
пытаний, является в е р и ф и к а ц и я на предмет того, что все подготовлено и можно
приступать к выполнению дальнейших действий. Эта задача решается путем приме­
нения набора входных критериев системных испытаний, которые были определены
в плане тестирования. Если удовлетворены входные критерии, этап системных ис­
пытаний может начинаться.
В процессе тестирования выполняется прогон тестов, определенных в плане тес­
тирования. По мере прогона тестов выявляются ошибки, создаются о т ч е т ы по ошиб­
кам, а данные, имеющие отношению к процессу отслеживания ошибок, заносятся в
специальную базу данных. Между тестировщиками и разработчиками поддерживает­
ся н е п р е р ы в н ы й диалог на основе промежуточных отчетов.
После начала процесса тестирования важно сообщать о состоянии тестирования
разработчиками и менеджерам. Подобное общение поддерживается через составле­
ние периодических отчетов о состоянии тестирования, а также благодаря подготовке
сводного отчета о тестировании в конце ф а з ы системных испытаний. В главе рас­
сматривается пример такого отчета, подготовленного к концу системных испытаний
для вымышленного набора инструментальных средств управления тестированием
(Test Management Toolkit, TMT).
В главе 5 упоминалось, что назначение сводного отчета о тестировании заключа­
ется в ответе на следующие вопросы:
•

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

•

Насколько фактические действия по проведению тестированию отклонились
от плана тестирования?

•

Как график и трудозатраты согласуются с планом тестирования?

•

Какие ошибки были найдены?

•

Какие ошибки остались на момент завершения тестирования и как они будут
обработаны?

Глава 16. Пример сводного отчета по системным испытаниям

k

369

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

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

Сводный отчет по тестированию ТМТ

TMT-TPS-10

Идентификатор документа: TMT-TSR-10
Версия: 0.2
Авторы: Джеймс Барнс (James Barnes)

Набор инструментальных средств управления тестированием
Версия 1.0

Сводный отчет по тестированию
Хронология версий
Версия

Дата

Автор

Описание

0.1

12/02/2001

Дж. Барнс

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

12/03/2001

Дж. Барнс

Изменения, основанные на пересмотрах

0.2

Утверждено
Дата утверждения
Тестирования

Брит Гейтер (Bret Gater),
менеджер отдела тестирования

370

12/03/2001

TMT-TPS-10

Сводный отчет по тестированию ТМТ

Содержание
1. Введение

371

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

371

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

375

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

375

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

376

6. Соблюдение графика

376

7. Ссылки

376

Приложение 1 — Список аббревиатур

376

Приложение 2 — Определение терминов

376

Приложение 3 — Сообщения электронной почты от утверждающих лиц
От: Брит Гейтер (Bret Gater) [bgater@tmtco.com]

376
376

1. Введение
Назначение этого документа заключается в представлении отчета о результатах системных испыта­
ний набора инструментальных средств управления тестированием (Test Management Toolkit, ТМТ).
Тесты производились в соответствии с документом "Набор инструментальных средств управления
тестированием, План тестирования":
http://www.tmtcointernal.com/usr/www/docstores/desion/Dlans/TMT-TP-10.doc.
Свойства, на которые производятся ссылки в этом документе, находятся в документе определения
требований, именуемого "Набор инструментальных средств управления тестированием, Определе­
ние требований":
httD://www.tmtcointernal.com/usr/www/docstores/desian/reauirements^MT-RD-10.doc.

2. Сводка по результатам тестирования
Три завершенных цикла тестирования, которые были проведены для профаммного продукта ТМТ, на
100% реализуют комбинированное тестирование системы. К моменту прогона заключительного теста
было пройдено 95% тестов, причем катастрофические ошибки обнаружены не были. Используя по­
лученные результаты, команда тестирования рекомендует утвердить выпуск этого программного
продукта.
Сводка по ошибкам, остающимся актуальными к концу тестирования, приводится в таблице 2.2.
Накопительная сводка по ошибкам, найденным во время тестирования профаммного продукта ТМТ,
показана в таблице 2.3. Сводка по ошибкам также представлена в виде гистограммы на рис. 3.1.

371

Сводный отчет по т е с т и р о в а н и ю Т М Т

TMT-TPS-10

Таблица 2.1. Отчет о состоянии тестирования
Тестовый набор

# тестов

# про­
шедших

# непро­
шедших

# не вы­
полненных

% выпол­
ненных

3.1.1. Пользовательский
интерфейс

20

18

2

0

100%

3.1.2. Навигация

25

24

1

0

100%

3.1.3. Аутентификация
пользователей — клиент

12

12

0

0

100%

3.1.4. Аутентификация
пользователей —
администратор

12

12

0

0

100%

3.1.5. Текущие проекты

15

15

0

0

100%

3.1.6. Завершенные проекты

15

15

0

0

100%

3.1.7. Создание проекта

12

12

0

0

100%

3.1.8. Изменение проекта

12

12

0

0

100%

3.1.9. Удаление проекта

12

12

0

0

100%

3.1.10. Создать тестовый
случай или набор

15

15

0

0

100%

3.1.11. Измени тестовый
случай или набор

15

15

0

0

100%

3.1.12. Удалить тестовый
случай или набор

15

15

0

0

100%

3.1.13. Показать тест

10

10

0

0

100%

3.1.14. Показать тестовый
набор

10

10

0

0

100%

3.1.15. Прогнать одиночный
тест

10

10

0

0

100%

3.1.16. Прогнать тестовый
набор

10

10

0

0

100%

3.1.17. Сводный отчет по
ошибкам

12

11

1

0

100%

3.1.18. Результаты
тестирования/Одиночный тест

15

15

0

0

100%

3.1.19. Результаты
тестирования/Тестовый набор

15

15

0

0

100%

3.1.20. Создать матрицу
прослеживаемости

10

9

1

0

100%

3.1.21. Резервное
копированиеЯестовые случаи

12

12

0

0

100%

3.1.22. Резервное
копирование/Тестовые наборы

12

12

0

0

100%

372

Сводный отчет по тестированию ТМТ

TMT-TPS-10
Окончание табл. 2.1

Тестовый набор

# тестов

# про­
шедших

# непро­
шедших

# невы­
полненных

% выпол­
ненных

3.1.23. Резервное
копирование/Результаты
прогона тестов

12

12

0

0

100%

3.1.24. Восстановление/
Тестовые случаи

12

12

0

0

100%

3.1.25. Восстановление/
Тестовые наборы

12

12

0

0

100%

3.1.26. Восстановление/
Результаты прогона тестов

12

12

0

0

100%

3.1.27. Экспорт/Тестовые
случаи

12

11

1

0

100%

3.1.28. Экспорт/Тестовые
наборы

12

11

1

0

100%

3.1.29. Экспорт/Результаты

12

11

1

0

100%

3.1.30. Справка

18

18

0

0

100%

3.1.31. Многопользователь­
ские функциональные
возможности

10

10

0

0

100%

408

400

8

0

100%

прогона тестов

373

Сводный отчет по т е с т и р о в а н и ю Т М Т

TMT-TPS-10

Таблица 2.2. Отчет об открытых ошибках
Инструментарий по управлению тестированием
Сводка по открытым ошибках
Дата просмотра: 30-11-02
Посетители
Иденти­
фикатор
ошибки

Состояние

Серьез­
ность

Дата обна­
ружения

Сводка по ошибке

Действие

В3.1.1А

Назначено

Малая

15-10-01

Ошибка в метке поля "Test
Identifier". Tset Identifier

Исправлено
в 1.0

В3.1.1В

Назначено

Малая

16-10-01

Ошибка в метке поля "Test
Name". *Test Nnme

Исправлено
в 1.0

ВЗ.1.2

Назначено

Малая

17-10-01

Пропущена метка меню
"Utility Menu"

Исправлено
в 1.0

ВЗ.1.16

Назначено

Малая

20-10-01

Наложение полей Pass
(Пройдено) и Fail (Сбой)

Исправлено
в 1.0

ВЗ.1.19

Назначено

Малая

22-10-0.1

Попытка выбора матрицы
трассировки в корневом
каталоге. Должен быть
каталог /Trace

Исправлено
в 1.0

ВЗ.1.26

Назначено

Большая

01-11-01

При экспорте "Test Case"
(Тестовый случай) данные
оказываются
разрушенными

Отложено
до версии
1.1

ВЗ.1.27

Назначено

Большая

01-11-01

При экспорте "Test Suite"
(Тестовый набор) данные
оказываются
разрушенными

Отложено
до версии
1.1

ВЗ.1.28

Назначено

Большая

01-11-01

При экспорте "Test Result"
(Результаты прогона
тестов) данные
оказываются
разрушенными

Отложено
до версии
1.1

Примечания: ВЗ.1.26, ВЗ.1.27 и ВЗ.1.28 — для решения проблемы требуются архитектурные
изменения, которые будут выполнены в следующей версии программы

Таблица 2.3. Сводка по ошибкам, найденным во время тестирования
Неделя 1

Неделя 2

Неделя 3

Неделя 4

Неделя 5

Неделя 6

Катастрофические

5

6

4

4

2

0

Крупные

6

7

5

4

3

0

Мелкие

25

32

18

7

3

2

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, который размещает­
ся под управлением системы контроля документов по адресу:
http://wvvw.trntcointernal.corn/usr/www/docstores/clesiqn/reauirernents/TMT-RD-10.doc
Chris Brown and J. Barnes, Test Management Toolkit, Test Plan (Набор инструментальных средств
управления тестированием, План тестирования). Документ ТМТ-ТР-10, который размещается под
управлением системы контроля документов по адресу:
httD://www.tmtcointernal.com/usr/www/docstores/desiqn/plans/TMT-TP-10.doc
Chris Brown и J. Barnes, Test Management Toolkit, Release 1.0. Test Procedure Specification (Набор
инструментальных средств управления тестированием, Спецификация тестовой процедуры
ТМТ). Документ TMT-TPS-10, который размещается под управлением системы контроля документов
по адресу:
httD://www.tmtcointernal.com/usrAwww/docstores/desiqn/plans^MT-TPS-10.doc

Приложение 1 —Список аббревиатур
Отсутствует

Приложение 2 — Определение терминов
Отсутствует

Приложение 3 — Сообщения электронной почты от утверждающих лиц
От: Брит Гейтер (Bret Gater) [bgater@tmtco.com]
Отправлено: четверг 9/10/2001 07:30
Кому: Дж. Варне [jbarnes@tmtco]; test@tmtco; development@tmtco
Копия: marketing@tmtco; costumersupport@tmtco
Тема: Сводка по тестированию ТМТ 1.0
Уважаемые члены команды,
Я просмотрел сводный отчет по тестированию TMT-TSR-10, версия 2, и утвердил его, поскольку он
точно представляет результаты тестирования. Команда тестирования рекомендует утвердить выпуск
программного продукта ТМТ, версия 1.0. Поздравляю разработчиков и тестировщиков с достигнутым
успехом!
С наилучшими пожеланиями, Брит
Брит Гейтер
Менеджер, отдел программирования
TMTCO

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­
neering 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, and T. L. Hannan. (1979). "Central Flow Control Software Devel­
opment: A Case Study of the Effectiveness of Software Engineering Techniques," Proceed­
ings from the Fourth Summer 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 Cliffs, NJ: Prentice-Hall, Inc.

7.

Boehm, Barry W. (1988). "A spiral model for software development and 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, and 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 the Illinois Institute of Technology, where
work on the 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, and Neil Iscoe. (1987). "On building software
process models under the lamppost." Proceedings of the 9th International Conference on Software
Engineering (pp. 96-103). Monterey, CA: IEEE Computer Press Society.
14. DeMarco, Tom, and Timothy Lister. (1987). Peopleware: Productive Projects and Teams. New
York: Dorset House Publishing.
15. Dustin, Elfriede, Jeff Rashka, and 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 reduce errors in program 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, and D. F. Hare. (1978). "Certifi­
able Minicomputer Project, ICSCA," Report on the Language Gypsy, Version 2.0. Technical
Report ICSCA-CMP-10, The 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: Addison-Wesley.
21. Humphrey, Watts S. (2000). Introduction to the Team Software Process. Reading.MA: AddisonWesley.
22. IEEE. (1983). IEEE Standard 829: IEEE Standard for Software Test Documentation. Los Alamitos,
CA: IEEE Computer Society Press.
23. IEEE. (1984). IEEE Standard 830: The IEEE Guide to Software Requirements Specifications. Los
Alamitos, CA: IEEE Computer 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 Thompson Computer Press.
27. Kaner, Cem, Jack Falk, and Hung Quoc 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, and Martin Pol. (1999). Test Process Improvement. Reading, MA: AddisonWesley.
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, and 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, 15 (Ъ), 182-211.
35. Musa, J o h 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, GlenfordJ. (1977). "An Extension to the Cyclomatic Measure of Program Complex­
ity." SIGPLAN Notices.
38. Paulk, Mark, Charles Weber, and Bill Curtis. (1995). The Capability Maturity Model: Guidelines
for Improving the Software Process. Reading, MA: Addison-Wesley.
39. Paulk, Mark. "Using the Software CMM with Small Projects and Small Organizations." In
Eugene McGuire (1999), Software Process Improvement: Concepts and Practices. Hershey, PA:
Idea Group Publishing.
40. Perry, William E. (2000). Effective Methods for Software Testing(2nd ed.). New York: Wiley.
41. Perry, William E., and Randall W. Rice. (1997). Surviving the Top Ten Challenges of Software
Testing. New York: Dorset House Publishing.
42. Pfleeger, Shari Lawrence. (2001). Software Engineering: Theory and Practice (2nd ed.). Upper
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 James Robertson. (1999). Mastering the Requirements Process. Read­
ing, MA: Addison-Wesley.
45. Schulmeyer, G. Gordon and Garth R. Mackenzie. (2000). Verification and Validation of Modern
Software-Intensive Systems. Upper Saddle River, NJ: Prentice Hall.
46. Software Productivity Consortium (1993). Software Error 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. The Standish Group. (1994). The CHAOS Report. Dennis, MA: The Standish Group.
49. The Standish Group. (1995). The Scope of Software Development Project Failures. Dennis, MA:
The Standish Group.
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 8c
MacKenzie. © 2000. Reprinted by permission of Pearson Education, Inc., Upper Saddle
River, NJ.
52. pp. 6~7, 73 From Rapid Development: Taming Wild Software Schedules by Steve McConnell.
Copyright 1996. Reproduced 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 reprinted 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., Upper 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 regarding the content and format of requirements documents is re­
printed 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 AddisonWesley, 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 John 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, SO Information regarding the content and format of test documents is reprinted 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 reporting is reprinted with permission from
IEEE Std. 1044-1993: IEEE Standardfor Software Anomalies, Copyright 1993 by IEEE.