Author: Тамре Л.
Tags: компьютерные технологии программное обеспечение тестирование
ISBN: 5-8459-0394-7
Year: 2003
Text
тестирование
программного
обеспечения
ЛУИЗА ТАМРЕ
ББК 32.973.26-018.2.75
Т17
УДК 681.3.07
Издательский дом “Вильямс”
Зав. редакцией А.В. Слепцов
Перевод с английского и редакция В.В. Марченко
По общим вопросам обращайтесь в Издательский дом “Вильямс” по адресу:
info@williamspublishing.corn, http://www.williamspublishing.com
Тамре Л.
Т17 Введение в тестирование программного обеспечения. : Пер. с англ. —
М.: Издательский дом “Вильямс”, 2003. — 368 с.: ил. — Парал. тит. англ.
ISBN 5-8459-0394-7 (рус.)
Данная книга служит руководством по организации процессов тестирования во
время разработки программного обеспечения. Она призвана помочь в принятии
решений при составлении и отборе тестовых примеров, имеющих целью повышение
эффективности процесса тестирования ПО. Здесь рассматриваются ключевые про-
цедуры, выполняемые на ранних этапах тестирования ПО, в частности, определение
недостающих сведений и оценка качества требований. Много внимания уделено также
различным методам составления тестовой документации, в том числе и ускоренным
методам сокращенного документирования тестовых примеров. В отдельных главах
подробно рассмотрены методы тестирования объектно-ориентированных и Web-
ориентированных приложений.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками
соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы
то ни было форме и какими бы то ни было средствами, будь то электронные или механические,
включая фотокопирование и запись на магнитный носитель, если на это нет - письменного
разрешения издательства Addison-Wesley Publishing Company, Inc
Authorized translation from the English language edition published by Pearson Education Ltd., Copy-
right © 2002
All rights reserved. No part of this book may be reproduced or transmitted in any form or by tiny
means, electronic or mechanical, including photocopying, recording or by any information storage re-
trieval system, w ithout pet mission from the Publisher.
Russian language edition published by Williams Publishing House according to the Agreement with
R&I Enterprises Internationa), Copyright © 2003
ISBN 5-8459-0394-7 (pyc.)
ISBN 0-201-71974-6 (англ.)
© Издательский дом “Вильямс”, 2003
© Pearson Education Limited, 2002
Оглавление
Введение 11
Глава 1. Лабиринты тестирования 19
Глава 2. Схемы тестов 47
Глава 3. От схемы тестов к тестовым примерам 85
Глава 4. Использование электронных и обычных таблиц 105
Глава 5. Другие типы таблиц 153
Глава 6. Тестирование объектно-ориентированного ПО 187
Глава 7. Тестирование Web-приложений • / 211
Глава 8. Сокращение числа тестовых примеров 251
Глава 9. Создание качественного ПО 275
Глава 10. Программные стандарты в тестовой документации 293
Приложение А 315
Приложение Б 345
Рекомендуемая литература 353
Предметный указатель
357
Содержание
Введение 11
Благодарности 17
Глава 1. Лабиринты тестирования 19
Введение 19
Пример приложения 20
Наращиваемый подход в тестировании 23
Стадия 1. Изучение 25
Стадия 2. Базовое тестирование 26
Стадия 3. Анализ тенденций 28
Стадия 4. Инвентаризация 30
Стадия 5. Комбинирование элементов инвентарных списков 34
Стадия 6. Граничные оценки 35
Стадия 7. Ошибочные данные 43
Стадия 8. Создание напряжений 44
Дальнейшие шаги 44
Резюме 45
Глава 2. Схемы тестов 47
Введение 47
Пример приложения 48
Выделение требований 49
Схематический подход 52
Разработка схемы теста 54
Категории тестов 56
Применение категорий тестов 62
Дополнительная информация о продукте 69
Последняя итерация 74
Оценка схемы < 79
Оценка календарного планг 81
Резюме 83
Содержание
7
Глава 3. От схемы тестов к тестовым примерам 85
Введение 85
Создание тестовых примеров 85
Упрощенный формат документации 96
Резюме 104
Глава 4. Использование электронных и обычных таблиц 105
Введение 105
Пример приложения 106
Документирование тестовых примеров 109
Ci юсобы составления документации 110
Сокращения в тестовой документации 127
Подробные описания тестов 142
Автоматическое создание тестовых примеров 150
Резюме 151
Глава 5. Другие типы таблиц 153
Введение 153
Конечный автомат 153
Создание тестовых примеров на основе таблицы состояний 158
Проведение теста и уровни тестирования 160
Таблица тестовых примеров с несколькими входными данными 162
Таблицы решений 165
Уменьшение размеров таблицы решений 166
Расширение таблицы решений 166
Анализ покрытия 172
Приложения со сложными данными 174
Управление тестами 180
Планирование тестов 180
Матрица тестовых i фимеров 181
Отслеживание проведения теста 184
Резюме 185
Глава 6. Тестирование объектно-ориентированного ПО 187
Введение 187
Сравнение объектно-ориентированного и процедурного
программирования 188
Объектно-ориентированная терминология 188
8 Содержание
Тестирование ПО 188
Пример тестирования системы 189
Тестовые примеры на основе схемы 193
Тестовые примеры на основе прецедентов 197
Поэлементное тестирование классов 200
Тестирование с использованием ортогональных массивов 200
Тестирование наследования 204
Сложности проведения тестов 206
Резюме ' 208
Глава 7. Тестирование Web-приложений 211
Введение 211
Образе! (I триложения 212
Сложности с функциональными возможностями и практичностью 214
Тестирование функциональных возможностей 214
Тестирование практичности 216
Тестирование навигации 219
Т естирование форм 221
Тестирование содержимого страницы 223
Тестирование конфигурации и совместимости 224
Надежность и доступность 227
Характеристики 229
Тестирование масштабируемости 234
Тестирование загруженности 234
Тестирование давления 236
Тестирование безопасности 238
Тестирование сквозных транзакций 239
Тестирование баз данных 240
Тестирование после реализации 242
Стратегия сопровождения 246
Временная шкала 246
Команда сопровождения 246
Таблица контрольных проверок теста на одобрение 247
Таблица контрольных i (роверок теста на загруженность 248
План отката , 248
Резюме 249
*
Глава 8. Сокращение числа тестовых примеров 251
Введение 251
Принципы расстановки приоритетов 253
Содержание
9
Схема приоритетных категорий 253
Анализ степени риска 255
Компоненты риска 255
Матрица риска 257
Анализ степени риска в реальном мире 260
Определение проблемных областей в ходе опроса 260
Сложности разработки 261
Сложности с заказчиком 264
Сложности управления 265
Сложности с персоналом 265
Комбинированные схемы 267
Отслеживание выбранных тестовых примеров 270
Матрица прослеживаемости требований 270
Матрица риска и тестовых примеров 271
Сокращенное документирование тестов 272
Резюме 272
Глава 9. Создание качественного ПО 275
Введение 275
Инфраструктура среды разработки 275
Требования 275
Проектный менеджмент 276
Конфигурационный менеджмент в разработке ПО 277
Обеспечение качества ПО 279
Пересмотры и аудиты 280
Среда тестирования ПО 281
Поэлементное тестирование 283
Тестирование сборки 284
Тестирование системы 285
Регрессионное тестирование 286
Тестирование одобрения 287
Задачи тестирования ПО 287
Планирование тестирования 287
Автоматизация тестов 288
Система составления отчета о неполадках 290
Составление отчета о тестировании 291
Резюме 292
Глава 10. Программные стандарты в тестовой документации 293
293
294
Введение
Общие элементы
10 Содержание
Конфигурационный менеджмент
295
Прослеживаемость требований 296
Промышленные стандарты 296
Стандарт ISO 9001 296
Стандарты ISO/IEC 12207 и IEEE/EIA12207 298
Стандарты разработки ПО IEEE 301
Модель Capability Maturity Model® для ПО 303
Соответствие стандартам 305
Резюме 314
Приложение А 315
Приложение А1 315
Приложение А2 316
Приложение АЗ 316
Приложение А4 318
Приложение А5 324
Приложение А6 338
Приложение Б 345
Приложение Б1 345
Приложение Б2 349
Рекомендуемая литература । 353
Предметный указатель 357
Введение
Хаос тестирования
Проект находится под угрозой срыва, а сроки его окончания быстро приближают-
ся. Руководство решает протестировать продукт лишь тогда, когда уже утрачены поч-
ти все возможности для повышения качества программного обеспечения. Если како-
го-то неудачливого программиста назначают на тестирование программного обеспе-
чения, и к тому же несчастному не дается никаких указаний и никто ничем в органи-
зации не может помочь, то обычно это рассматривается как “перевод в чистилище”.
Несмотря на плохое состояние требований, и другой документации, продукт разраба-
тывается и будет выпущен. Задача, поставленная перед тестером, заключается в том,
чтобы свести к минимуму количество неприятных сюрпризов, которые могут возник-
нуть после установки продукта у заказчика. Находясь под сильным давлением, непод-
готовленный тестер оказывается в сложной ситуации и не представляет себе, что де-
лать. Несведущий менеджер может купить какой-либо инструмент автоматического
тестирования несмотря на отсутствие пригодных для автоматизации тестов. Именно,
такое положение вещей способствует распрост ранению дурной славы о тестировании.
Тестирование программного обеспечения — это отдельная дисциплина, требую-
щая специальных навыков. Тестирование программного обеспечения не интуитивно;
кто-то должен знать, как это делается. Наивные менеджеры ошибочно полагают, что
тестирование программного обеспечения доступно любому программисту, — если он
может составлять программы, значит, может и тестировать продукт. Мотивом для на-
писания этой книги стало желание рассказать о поэтапном методе, дающем возмож-
ность начать собственно тестирование.
На сегодняшний день существует большое количество хороших книг по тестиро-
ванию программного обеспечения. В работах, которые посвящены проектированию
тестовых примеров, описываются такие проверенные методы, как анализ граничных
значений, разбиение на классы эквивалентности, таблицы решений, тестирование
синтаксиса, причинно-следственные диаграммы, потоковые методы и т.д. Некоторые
начинающие тестеры еще до применения перечисленных выше методов интересуют-
ся тем, как можно справиться с плохой спецификацией. Во многих работах утвержда-
ется, что для проведения тестирования необходимы хорошие требования (предпола-
гается, что они уже существуют), хотя автору этой книги не встречались такие рабо-
гы, в которых объяснялся бы переход от требований к тестовым примерам. В хаосе
разработки программного обеспечения адекватные требования редко бывают пред-
ставлены, а если они и есть, под вопросом остается их полнота и корректность. Ана-
лиз требований в большинстве случаев ложится на тестера, который должен перед
12
Введение
заданием каких-либо тестов рассмотреть проблемы, связанные с требованиями. В сжа-
тые сроки с ограниченными ресурсами нельзя провести всестороннее тестирование,
однако можно сделать разумный выбор и выполнить работу по тестированию с мак-
симально возможной эффективностью.
Основная цель тестера — изучить оптимальные подходы к задачам тестирования и,
в конечном счете, наладить рабочий процесс тестирования для будущих проектов.
Философия автора
Чтобы изложить идеи, касающиеся проведения тестирования, в этой книге рас-
сматривается несколько примеров с так называемыми “требованиями”. По определе-
нию, хорошие требования должны быть недвусмысленными и тестируемыми. Тот
факт, что представленные образцы требований неполны, не означает, что тестиро-
вание проводить нельзя. Слово “требования” здесь используется нестрого и прирав-
нивается к некоему виду описания продукта. Если предложенные образцы сценариев
тестирования неприемлемы для уже сформировавшихся организаций, занимающихся
производством ПО, они помогут отдельным тестерам в случае необходимости быстро
начать процесс тестирования. Основная задача здесь заключается в том, чтобы пока-
зать, что для начала тестирования можно использовать любую информацию о продук-
те, даже неполную.
Изложенные выше рассуждения не следует рассматривать как аргумент в пользу
работы с плохими требованиями. Правильный анализ требований позволяет испра-
вить многие упущения. Доказано, что пересмотры и инспекции с точки зрения за-
трат— наиболее эффективные методы для обнаружения проблем на ранних стадиях
цикла разработки. Автору часто приходилось сдерживаться, чтобы не высказать ме-
неджерам проекта свое негодование: “Требования совсем никуда не годятся и мы не
можем продуктивно проводить тестирование до тех пор, пока вы не проясните ситуа-
цию”. В действительности эта фраза обычно содержит непечатные идиоматические
выражения и произносится под чьи-то вздохи, однако несмотря ни на что, сроки вы-
пуска продукта стремительно приближаются.
Хотя здесь не будет отстаиваться идея “срезания углов”, все же существуют спосо-
бы сокращения рутинной деятельности, которые могут помочь документировать
процесс тестирования. Лучше иметь непродуманный список тестов, чем совсем ниче-
го. Самое меньшее, что нужно сделать — это документировать след, пусть даже эле-
ментарный, чтобы фиксировать работу, выполненную при тестировании, и иметь
возможность продемонстрировать то, что уже было сделано.
Последующая работа над тестированием даст возможность улучшить эти началь-
ные наработки путем создания тестовой документации и разработки процедуры тес-
тирования, которая будет в большей степени способствовать успешному завершению
процесса.
Само по себе знание того, с чего начать тестирование, является серьезным дости-
жением. Основная задача этой книги заключается в том, чтобы помочь тестеру по-
нять, как информация о продукте преобразуется в тестовые примеры. Существует
множество книг, в которых объясняются концепции и методы тестирования про-
граммного обеспечения. Чтобы не повторять того, что уже было написано другими
Введение
13
авторами, здесь будут сделаны ссылки на их работы. В первую очередь, эта книга
должна помочь начать тестирование. Данная книга дополняет существующую на сего-
дня литературу по тестированию программного обеспечения и представляет собой
введение к методикам тестирования ПО.
Предполагаемая аудитория
Эта книга может быть интересной:
• для специалистов, которые впервые занялись тестированием программного
обеспечения и которым нечем руководствоваться или же негде подучиться;
• для менеджеров или руководителей, которые сами могут быть опытными спе-
циалистами по тестированию или которые ищут возможности получить руко-
водство для начинающих тестеров;
• опытных программистов, занимающихся тестированием;
• опытных тестеров, ищущих новые идеи.
Если читатель не очень знаком с понятиями тестирования программного обеспе-
чения, он должен уметь обращаться с компьютером, а также уметь пользоваться тек-
стовым процессором и электронными таблицами.
Перечень должностных лиц
В книге используются следующие общие термины для описания должностных лиц.
Тестер Специалист, который описывает и проводит тесты.
Разработчик Специалист, который создает приложение (включая проект и исходный код), а также проводит окончательную интеграцию продукта.
Руководитель проекта Авторитетный специалист, занимающийся календарным планом и кадровым обеспечением.
Авторитетное лицо проекта Специалист по предметной области, обладающий достаточным опытом и авторитетом для составления и согласования требований.
Эти должности охарактеризованы без какой-либо привязки к структуре организа-
ции или к цепочке подотчетности служащих. Описание кадрового обеспечения и от-
ветственности за работу меняется от организации к организации.
В зависимости от того, как комплектуется штат проекта, тестер можег находить-
ся в одной группе с разработчиками или же принадлежать к отдельной группе тес-
тирования. В иных проектах может потребоваться, чтобы один и тот же человек
выполнял одновременно задачи разработки и тестирования, меняя, таким образом,
14
Введение
свое положение в проекте. В идеале работу, связанную с тестированием, выполняет
обученный специалист по тестированию программного обеспечения, однако в неко-
торых проектах на роль тестера назначают любого свободного специалиста.
Авторитетным лицом проекта может быть менеджер по маркетингу, руководитель
компании или же посредник, занимающийся поддержкой заказчиков. Эта роль необ-
ходима для определения содержания проекта и предотвращения дальнейшего хаоса.
Авторитетное лицо проекта отвечает за принятие решений относительно того, какие
функции будут включены в продукт; недостаток такого жесткого контроля выливается
в ряд проблем, возникающих при согласовании требований.
В организациях могут быть задействованы и другие должностные лица. Ключевым
моментом здесь является назначение сотрудников (каждый из которых должен иметь
специальные навыки) для выполнения необходимых задач.
Среда разработки программного
обеспечения: формирование и зрелость
Примеры, упомянутые в этой книге, содержат неполные сведения о продукте —
именно то, чего можно ожидать от несформировавшейся организации разработки
ПО. Автор постарается воздержаться от критики рабочей среды и от пропаганды
улучшения процесса разработки ПО. Реалии таковы, что многие компании функцио-
нируют в далеко не идеальных условиях. За исключением случая, когда полностью от-
сутствуют подходящие процессы разработки, продукт можно разрабатывать и сдавать
заказчику. Однако все же нужно провести хотя бы минимальное тестирование. При
плохих требованиях тестер тратит больше времени на обнаружение недостатков в
определении требований вместо того, чтобы выполнять задачи, связанные с тестиро-
ванием.
В компаниях, занимающихся эффективной разработкой ПО, наблюдаются опре-
деленные нормы. В ^сформировавшихся организациях часто не понимают, как
влияют на продукт:
• удобные требования и описания продукта;
• проведение пересмотров и инспекций;
• наличие точек выхода или контрольных точек между этапами;
• обучение и подготовка персонала;
• адекватное планирование времени и ресурсов для тестирования;
• перекрытие процессов тестирования и разработки;
• введение четких процессов разработки и тестирования ПО;
• конфигурационный менеджмент.
Тестирование — это ответственность, которую разделяет и остальная часть ко-
манды разработчиков. Взгляд на тестирование по схеме проектирование - написание
кода - тестирование никогда не даст хороших результатов. Деструктивный подход,
Введение
15
сопровождающийся соперничеством типа “разработчик против тестера”, часто яв-
ляется результатом игнорирования разработчиками процессов тестирования — еще
одно подтверждение того, что тестирование — это уникальная дисциплина. Обычно
тестер о программировании знает больше, чем разработчик о тестировании. Обоюд-
ное сближение тестеров и разработчиков способствует доброжелательной атмосфере
и хорошим отношениям в организации. Работая в постоянном контакте с тестерами,
разработчики больше узнают о тестировании программного обеспечения, а значит, и
о самом продукте. Эффективное тестирование программного обеспечения требует
объединения усилий всех членов проекта.
Краткий обзор
Глава 1 начинается с кошмара: специалист ничего не знает о тестировании, про-
дукт выпускается в следующую пятницу, а документация проекта неполна, неточна,
или, что еще хуже, ее вообще не существует. Предполагая, что в следующем проекте у
такого специалиста будет больше времени на проведение тестирования, в главе 2 по-
казано использование схем, которые также являются полезной методикой анализа
требований. В главе 3 схема преобразуется в тестовые примеры. Обычные и элек-
тронные таблицы — неотъемлемый инструмент, который используется специалиста-
ми по тестированию программного обеспечения, поэтому в главе 4 показано неско-
лько форматов таблиц и сокращенных форматов документирования тестовых приме-
ров. В главе 5 показано дополнительное применение таблиц. В приложениях, создан-
ных с помощью объектно-ориентированных методов, могут использоваться многие из
тех методов проектирования тестовых примеров, которые были рассмотрены в пре-
дыдущих главах. В главе 6 описаны некоторые конкретные сложности, возникающие
при тестировании объектно-ориентированных систем. В главе 7 анализируются про-
блемы, с которыми можно столкнуться при тестировании Web-приложений, хотя
многие из представленных здесь стратегий применяются аналогично клиент-
серверным технологиям.
Не существует единого метода тестирования программного обеспечения. В каж-
дом примере для создания тестов используется свой подход. Читателя может удивить,
почему в примере использовался именно этот метод, а не какой-нибудь другой. При-
чина проста: методы выбирались, исходя из опыта автора. Можно попробовать иные
подходы, которые могут оказаться весьма удачными при проведении тестирования.
В примерах охвачены различные типы приложений, но основная идея тестирования
программного обеспечения одинаково применима ко всем типам, а некоторые кон-
цепции неоднократно повторяются во всех главах. Автор рекомендует прочесть все
сценарии и не пропускать какие-либо темы только лишь потому, что в примере не
отображен интересующий вас тип приложения.
Следуя представленным далее идеям и методам, можно определить и документи-
ровать множество тестовых примеров. Глава 8 поможет читателю определиться с
наиболее подходящими тестами и снизить таким образом число проводимых тесто-
вых примеров. Создание набора тестовых примеров, которые нужно будет выпол-
нить, — это только часть общей картины. В главе 9 перечисляются другие задачи,
16 Введение
связанные с тестированием и качеством, которые необходимы для создания эффек-
тивного ПО.
Для организации, которая впервые рискнула пойти на методичное тестирование
программного обеспечения, данная книга — незаменимое руководство. Значительно-
го упорядочения предыдущих хаотических усилий еще недостаточно для соответст-
вия продукта промышленным стандартам. В главе 10 вкратце описаны некоторые из
наиболее общих стандартов разработки программного обеспечения и влияние каждо-
го из них на образцы тестовых примеров. Это, так сказать, отправная точка для усо-
вершенствования процесса тестирования.
Благодарности
На написание этой книги меня вдохновили люди, которые работали со мной в
проектах по тестированию программного обеспечения. Я училась тестированию
сложным путем: кое-как справляясь с ним, наблюдая за работой других тестеров, чи-
тая потрепанные копии книги Гленфорда Майерса (Glenford Myers) и Бориса Бейзера
(Boris Beizer). В конце концов, программисты и начинающие тестеры стали спраши-
вать меня о том, как нужно проводить тестирование. Я разработала ритуал отхода от
старых тестовых документов и демонстрации этапов задания тестов. Возможность
увидеть реальный пример вылилась в тысячи слов — это время, потраченное на опи-
сание предлагаемых методов и на то, чтобы поделиться ими с широкой аудиторией.
Несколько лет тому назад на конференции по тестированию ПО я встретила Сай-
мона Миллза (Simon Mills). Он — состоявшийся тестер, который прошел тем же пу-
тем, наделен богатым опытом и “боевыми шрамами”. Мы поговорили, поделились
идеями, а затем проверили их, разработав и представив курс, который поможет начи-
нающим тестерам. Без энтузиазма Саймона я, возможно, никогда и не подумала бы о
написании этой книги.
Чтобы отшлифовать ранние наброски, потребовалось много времени, опыта и на-
выков моих коллег. Я очень благодарна Джеймсу Бэчу (James Bach), Джиму Брею (Jim
Brei), Элис Брукс (Elise Brooks), Киерон Конвэй (Kieron Conway), Джерилинн Коул-
тер (Jerilynn Coulter), Биллу Дэйблеру (Bill Deibler), Брайану Форестеру (Brian
Forester), Дороти Грэхэм (Dorothy Graham), Тони Ховарду (Tony Howard), Владану
Джовановику (Vladanjovanovic), Рите Лэмпорт (Rita Lamport), Артуру На (Arthur Na),
Нэнси Пома (Nancy Poma), Линн Фредериксон Раго (Lynne Frederickson Rago), Роуз
Рейнхардт (Rose Reinhardt), Джоанне Ротман (Johanna Rothman), а также Ирен Рут-
вен (Irene Ruthven) за все то, что они для меня сделали.
Особенно я признательна Рите Лэмпорт и Джерилинн Коултер. Рита щедро поде-
лились своим опытом в области тестирования Web-приложений и описала его. Она
также помогла мне преодолеть трудности при написании главы по объектно-
ориентированному программному обеспечению. Джерилинн оказала поддержку в
разработке многих разделов в главе по тестированию Web-приложений, а также по-
могла разобраться с частями главы, касающейся объектно-ориентированных прило-
жений. Наше сотрудничество было поистине плодотворным.
В ходе многочисленных бесед Джоанна Ротман высказывала идеи относительно
опроса команды разработчиков для четкого освещения потенциальных проблемных
областей. Я прислушалась к ее словам, в результате чего появилась глава 8. Я испыты-
ваю огромную благодарность за то, что Д жоанна поделилась со мной своими идеями.
18 Благодарности
И наконец, я очень благодарна своему мужу, Брайану Форестеру, который поддер-
жал эту затею. Он дал мне возможность работать дома, и служил резонатором для бес-
счетного числа идей. Последний поцелуй я оставляю для моего маленького Джастина
(Justin), который вытерпел множество нянь. Однажды ты поймешь, почему мама не
всегда могла быть с тобой. Возможно, эта книга пригодится тебе, когда ты напишешь
свою первую программу!
ГЛАВА
Лабиринты тестирования
Введение
Не все проекты тестирования программного обеспечения начинаются с мажорной
ноты. Кому-то из участников тестирования, возможно, не хватает практики, или из
опытного программиста наивный менеджер собирается сделать хорошего тестера
(в особенности если эта работа не поручена никому конкретно). Как и другие техни-
ческие дисциплины, тестирование программного обеспечения — это специальная об-
ласть, требующая специфических навыков. Многие менеджеры ошибочно полагают,
что программист может эффективно тестировать программное обеспечение без
должной подготовки или наставлений.
Представьте себе человека, которому предстоит проделать большую работу по
тестированию, и который не знает, с чего начать, более того, ему не к кому обратить-
ся за помощью. Подобно путешественнику, который пробирается через лабиринт,
начинающий тестер знает, что где-то должен быть конец пути, но не знает, как его
достичь. К несчастью для тестера продукт выпускается в следующую пятницу, а доку-
ментация проекта неполна, неточна, или, что еще хуже, ее вообще не существует.
Это, конечно, лишь преувеличение. Хорошая среда разработки программного
обеспечения предполагает адекватное кадровое обеспечение и соответствующее вре-
мя на такую деятельность, как тестирование программного обеспечения, а также ру-
ководство персоналом, который им занимается. Однако условия работы некоторых
тестеров никак нельзя назвать идеальными — зачастую необходимо изучить и протес-
тировать новое приложение в нереальные сроки. Некоторые организации решают
выпустить продукт к определенной дате и хотят, чтобы тестеры подтвердили пригод-
ность продукта к использованию. Это далеко не самый лучший способ тестирования, но
у тестеров просто нет выбора, разве что стряхнуть пыль с резюме и попытаться по-
дыскать работу получше.
20
Глава 1
Эта глава служит руководством по прохождению ряда этапов тестирования и пред-
ставляет тесты для демонстрации правильной работы приложения. Однако сначала
рассмотрим тестируемые приложения.
Пример приложения
В этой главе используется пример налогового калькулятора на 2000-й налоговый
год, который был создан после того, как Налоговое управление США ввело феде-
ральный подоходный налог №1040. Данный пример иллюстрирует цели тестирова-
ния, а вовсе не описывает попытку реализации всего налогового кодекса. Читатели за
пределами США могут легко представить себя в роли тестеров, которые не знакомы с
приложением.
Пользователь вводит финансовую информацию, а налоговый калькулятор возвра-
щает значение, представляющее собой величину налога, взимаемого с налогопла-
тельщика. Приложение содержит много окон для ввода данных, четыре из которых
показаны ниже. В выходном окне перечисляются результаты. На следующих рисунках
показаны примеры моментальных снимков экрана.
Рис. 1.1 — информация о налогоплательщике и его статусе.
Рис. 1.2 — информация о доходах.
Рис. 1.3 — информация о статьях отчислений.
Рис. 1.4—другие налоги и кредиты, касающиеся налогоплательщика.
Рис. 1.5 — выходные данные налогового калькулятора.
Рис. 1.1. Налоговый калькулятор. Информация о налогоплательщике
Лабиринты тестирования 21
Рис. 1.2. Налоговый калькулятор. Информация о доходах
Рис. 1.3. Налоговый калькулятор. Информация о статьях отчислений
22
Глава 1
Рис. 1.4. Налоговый калькулятор. Информация о налогах и кредитах
Налоговый калькулятор: итоги за 2000-й налоговый год ВВЕЗ
Отчет по 2000-му -апогсг.-Агу году:
Общий налог: 0J
Всего к уплате: 0J
Количество возвращаемых средств: 2$
Задолженность: 0$
Размер пени, приблизительно: 0$
Готово
Рис. 1.5. Налоговый калькулятор. Вычисленные результаты
Задача тестеров заключается в том, чтобы убедиться, что приложение “Налоговый
калькулятор” готово к выпуску. В этот момент они еще не знают, как пользоваться
данным приложением. Что касается документации, то федеральное правительство
выпускает огромный документ, описывающий налоговое законодательство, который
объясняет, как вычислять результирующий налог, но отнюдь не помогает понять сугь
работы программного продукта. При тестировании иных приложений или в других
подобных ситуациях адекватной информации, касающейся проекта, может оказаться
Лабиринты тестирования
23
очень мало, а в некоторых случаях письменное изложение того, что должна делать
система, вообще отсутствует.
Как правило, встречаются следующие трудности.
• Большое и сложное приложение.
• Ограниченная осведомленность о приложении или же ее полное отсутствие.
• Неадекватная пользовательская документация.
• Слабые знания о тестировании программного обеспечения.
• Нет доступа к справке или руководству по тестированию программного обес-
печения.
• Нереальные сроки завершения тестирования.
Наращиваемый подход в тестировании
Для эффективной работы тестер программного обеспечения должен:
1. знать метод тестирования программного обеспечения;
2. знать тес тируемое приложение.
В каждом новом тестировании тестер должен посвятить какое-то время изучению
приложения. Неопытный тестер должен также изучить методы тестирования, вклю-
чая общие концепции тестирования и способ определения тестовых примеров. Эта
лава посвящена и тому, и другому. Основная задача заключается в составлении
подходящего набора тестов, которые можно провести в сжатые сроки.
Чтобы уложиться в эти сроки, тестирование приложения “Налоговый калькуля-
тор” будет разделено на восемь последовательных стадий. На первых стадиях путем
оценки точности результатов определяется, работает ли приложение в нормальных
’-словиях. На последних стадиях предпринята попытка вывести систему из строя.
В остальной части этой главы данные стадии обсуждаются более детально.
падия 1: Изучение
Целк Ознакомиться с приложением.
тадия 2. Базовый тест
Дик Разработать и реализовать простой тестовый пример.
'тадия 3: Анализ тенденций
Дик Определить, работает ли приложение так, как было задумано, когда
еще нельзя предварительно оценить реальные результаты.
'падия 4: Инвентаризация
Лык Определить различные категории данных и создать тесты
для каждого элемента категории.
24 Глава 1
Стадия Комбинирование элементов инвентарных списков
Цель Скомбинировать различные входные данные.
Стадия 6. Цели Граничные оценки Оценить поведение приложения при граничных значениях данных.
Стадия 7: Ошибочные данные
Цели Оценить отклик системы на ввод неправильных данных.
Стадия 8: Создание напряжений
Цели Попытаться вывести систему из строя.
Сроки очень короткие, так что возможности пройти через все стадии не будет.
Количество стадий тестирования, которое может провести один специалист, опреде-
ляется затраченным на тестирование временем исходя из запланированной даты вы-
пуска. После выполнения базового теста, если есть свободные тестеры, стадии можно
проходить одновременно.
Опираясь на идеи, рассматриваемые в этой главе, разбиение на такие стадии, как
инвентаризация, граничные оценки, ошибочные данные, создание напряжений в
среде без труда можно применять к любым проектам тестирования и эти концепции
будут снова возникать в последующих главах.
Для иллюстрации различных техник тестирования представлен образец тестового
примера только для одного поля, или области ввода данных. При определении тестов
для дополнительных полей нужно действовать аналогичным образом. При тестиро-
вании реальных приложений, для определения и реализации полного набора тесто-
вых примеров может оказаться недостаточно времени или других ресурсов. В такой
ситуации нужно определить, какие тесты наиболее важны и какие функции не будут
тестироваться. Анализ степени риска поможет сконцентрировать усилия при тести-
ровании на наиболее важных функциях приложения и выполнить наиболее уместные
тесты. В главе 8 представлена техника анализа степени риска, которую можно ис-
пользовать уже до начала составления тестовых примеров.
Тестеры, которым настолько “повезло”, что их пригласили в проект, в котором
предоставляется достаточно времени для надлежащего тестирования, могут сделать
следующее.
• Распланировать задачи тестирования.
• Спроектировать тесты, используя методы, описанные в последующих главах.
• Создать подходящую для проведения теста среду тестирования.
• Оценить, приобрести и установить инструменты автоматического тестирования.
• Hai тисать соответствующую документацию, связанную с тестированием.
Подключение тестера к проекту па очень поздней стадии, в особенности, когда сро-
ки завершения проекта уже близки, не позволяет спланировать тестирование надлежа-
щим образом, и ограничивает возможности приобретения полезных инструментов.
Лабиринты тестирования
25
В таких условиях нужно сконцентрироваться на разработке серии тестов, чтобы оп-
ределить, правильно ли функционирует приложение.
Теперь можно начать тестирование приложения “Налоговый калькулятор”.
Стадия 1. Изучение
Прежде чем тестер сможет выполнить какой-либо тест, он должен ознакомиться с
приложением. Такое изучение может принимать различные формы:
• ознакомления с любыми доступными учебными пособиями и материалами;
• чтения любой доступной документации — технической или предназначенной
для конечного пользователя;
• привлечения специалиста, который может продемонстрировать работу при-
ложения;
• вписывания случайных данных и команд;
• проверки всех возможностей приложения;
• принятия скептической позиции (“Только посмотрите, что оно вытворяет!”).
В ходе изучения тестеры узнактг, как работает приложение, наблюдая за его пове-
дением. Они также начинают чувствовать, что из себя представляют верные и невер-
ные входные данные. Если приложение выдает неожиданный результат, это может
свидетельствовать о потенциальных проблемах.
Изучение приложения и ознакомление с его функциями — это необходимый этап
обучения. Тестеры создают тесты на ходу, часто находясь под влиянием предыдущих
тестов. Этот подход, известный как исследовательское тестирование, — первый этап в
процессе принятия решения о том, что будет тестироваться. Очевидно, что гораздо
эффективнее работать в более формальной среде тестирования, в которой тесты оп-
ределяются заблаговременно. Изучение, хотя и является преимуществом, все же име-
ет свои недостатки. Во-первых, результаты, выданные приложением, могут повлиять
на решение тестера— он может поверить, что полученные результаты верны. Во-
вторых, когда тестер сталкивается с ошибкой, может оказаться, что для определения
верного пути в приложении или предыдущего состояния нет записи последователь-
ности нажатых перед этим кнопок. Это может усложнить воспроизведение ошибки.
Задача изучения заключается в том, чтобы как можно больше узнать о приложе-
нии, используя его функции. В главе освещается лишь один аспект исследовательского
тестирования. Всякий раз, когда тестер создает новый тест, основываясь на своих на-
блюдениях, полученных в ходе изучения текущего теста, он применяет метод исследо-
вательского тестирования (чтобы лучше ознакомиться с этим методом, можно обра-
титься к работам [Bach] и [Капег99]).
Еще одна важная задача заключается в поиске квалифицированного специалиста,
или авторитетного лица проекта, который бы хорошо знал приложение и мог разъяс-
нить требования, ведь в ходе тестирования возникает множество вопросов. Любые
решения, принятые авторитетным лицом проекта, или данные им разъяснения необ-
ходимо регистрировать и отмечать.
26
Глава 1
Стадия 2. Базовое тестирование
После изучения основных функций приложения тестер создает базовый тестовый
пример. Обычно базовый тест несложен: он основывается на простейшем пути в при-
ложении, в процессе которого используются установки по умолчанию или же другие
непосредственные входные данные. При заданных входных данных тестер должен
определить результирующие данные.
Результирующие данные состоят из любых наблюдаемых выходных данных (или
отсутствия таковых), которые были получены в результате тестирования. Следует от-
метить, что для некоторых тестов ожидается, что они не будуг вносить никаких изме-
нений в приложение, тогда результат, если он совпадает с ожидаемым, оказывается
верным. (Чтобы подробнее ознакомиться с различием между выходными и результи-
рующими данными, см. [Beizer 90] и [Beizer 95].) В зависимости от приложения суще-
ствует несколько источников определения ожидаемых результирующих данных.
1. Авторитетное лицо проекта или другой специалист по этому вопросу (ведущий
программист, проектировщик или менеджер проекта) будет знать, как опреде-
лить результирующие данные. В примере с налоговым калькулятором помочь
может также бухгалтер или налоговый поверенный.
2. Пример пользовательского сценария может содержаться в пользовательской
документации (если, конечно, она существует).
3. Необходимую информацию можно получить из документа, содержащего тре-
бования (если он существует).
4. Важные моменты могут содержаться и в другой, имеющей отношение к делу,
документации. В примере с налоговым калькулятором инструкции для налого-
плательщика содержат указания по вычислению результатов вручную.
5. Охарактеризовать ожидаемый результат может конечный пользователь.
В некоторых приложениях авторитетное лицо проекта определяет допустимый
предел погрешности. Например, некоторые вычисления могут варьироваться за счет
различных округлений. При введении данных Налоговое управление США позволяет
налогоплательщику округлять текущие значения до ближайшего целого значения,
вместо того чтобы сохранять центы в ходе вычислений и округлять конечный резуль-
тат. В этом примере предполагается, что вследствие округления результаты могут от-
личаться на+1$.
Определяя базовый тест путем перечисления входных данных и ожидаемых ре-
зультатов, тестеры должны также подготовиться к npi ведению этого теста. Необходи-
мо создать среду тестирования, чтобы запустить приложение с тестовыми данными.
Создание среды тестирования состоит из одного или нескольких перечисленных ни-
же этапов.
• Установка приложения.
• Установка и программирование инструментов автоматизации тестирования,
если в этом есть необходимость.
Лабиринты тестирования
27
• Настройка специальных файлов, включая занесение в них данных, необходи-
мых для тестирования.
• Создание утилит, которые поддерживают связь с приложением.
• Приобретение подходящего аппаратного обеспечения и необходимого обору-
дования.
Если время ограничено и у тестеров нет возможности выбрать, приобрести, уста-
новить, изучить и запрограммировать инструмент тестирования, они должны прово-
дить тест вручную.
Во время проведения теста реальные результаты сравнивают с ожидаемыми, что-
бы определить, пройден тест или нет. Проведение базового теста — это важное дос-
тижение, и на то есть несколько причин:
• тестеры исследовали приложение и теперь знают о нем достаточно, чтобы соз-
дать настоящий тест;
• для выполнения теста тестерам пришлось создать среду тестирования;
• этот базовый тест становится основой для создания последующих тестовых
примеров;
• приложение не смогло адекватно пройти этот тест, так как тестеры обнаружи-
ли серьезную проблему.
Приложение, которое не смогло адекватно пройти базовый тест, не пригодно к
использованию. Разработчики должны разобраться с проблемой и создать более на-
дежное приложение, однако тестеры могут воспользоваться преимуществами сло-
жившегося положения, чтобы определить и провести дополнительные тесты, перед
тем как в их распоряжении появится новая версия приложения, пригодная для тести-
рования.
В примере с налоговым калькулятором базовый тест подразумевает задание самого
простого типа налогоплательщиков с несложными финансовыми или деловыми опе-
рациями. Для данных в базовом тесте были подобраны следующие атрибуты.
• Одинокий человек, не имеющий материально зависимых лиц.
• Одна работа с оплатой $40 000 в год.
• Дополнительных доходов не имеет.
• Отчислений нет.
Исходя из приведенной выше информации следует ожидать, что налог с этого че-
ловека в 2000-м году составит $5 779 без учета налогового штрафа, который взимается
при исключении налогового отказа.
Для отслеживания входных данных и ожидаемых результатов (или результирую-
щих данных) используется табл. 1.1. Проводя тест, в эту простую таблицу можно запи-
сывать реальные результаты. В главе 4 показано множество форматов таблиц.
28
Глава 1
Таблица 1.1. Базовый тестовый пример
ID тестового Статус Заработок, ($) Величина Ожидаемые Реальный
Примера отчислений, результаты: результат
I W - ‘ z W-„Ч /<.($) 4 причитаюиЙ1йся>- Ж |
I , С . 'ч... ...'Ж ’ налог, ($) j
налог 1 одинокий 40 000 0 5 779
(-ая)
Стадия 3. Анализ тенденций
Анализ тенденций — это необязательная стадия, которая полезна тогда, когда вы-
полняется любое из следующих условий.
• Знакомство с приложением весьма поверхностно.
• Входные и выходные данные содержат численные значения.
• Неизвестны граничные значения данных.
• Сложно вычислить ожидаемые результаты.
• Имеется предположение относительно диапазона ожидаемых результатов.
В идеале, хотелось бы точно определить результирующие данные, минуя таким
образом анализ тенденций и переходя к стадии 4. Поскольку известно, как вычислить
ожидаемый налог при различных входных данных, эту стадию нужно было бы про-
пустить, однако для иллюстрации, к приложению “Налоговый калькулятор” все же бу-
дет применен анализ тенденций.
Характеризуя обычного налогоплательщика, базовый тестовый пример становит-
ся основой для анализа тенденций. На стадии анализа тенденций проводится отсле-
живание характера поведения путем изменения значения одной определенной чис-
ленной переменной. Даже если результат реальных выходных данных точно не из-
вестен, можно оценить, изменяются ли значения выходных данных в ожидаемом на-
правлении. Например, если постепенно увеличивать доход налогоплательщика, то,
очевидно, что суммарный налог будет возрастать пропорционально. Если в выходных
данных будут наблюдаться значительные скачки по сравнению с другими данными, то
проблема нуждается в дальнейшем исследовании. Такая стратегия является частью ис-
следовательского тестирования, поскольку перед началом тестирования не определя-
лись ожидаемые результаты. Однако этот подход все же дает информацию о предпо-
лагаемом поведении приложения.
В табл. 1.2 отслеживаются тенденции при возрастании заработка. Прежде всего,
определяются входные данные и ожидаемые тенденции, эта информация заносится в
таблицу, после чего вводятся входные данные, записываются реальные выходные
данные и оцениваются результаты. В этом примере заработок постепенно увеличива-
ется на $3000, ожидаемый результирующий налог возрастает монотонно. Похоже,
что до сих пор налоговый калькулятор работал верно, но что будет, если одно выход-
ное значение окажется нехарактерным в сравнении с остальными значениями в се-
рии? Будет ли считаться, что найдена проблема, если тестовый пример “тенденция 5”
Лабиринты тестирования
29
покажет в результате $10 500? Не обязательно. Ответ на этот вопрос даст авторитет-
ное лицо проекта. Возможно, возросший заработок переместил налогоплательщика в
более высокую налоговую категорию, увеличивая таким образом суммарный налог,
или, может быть, приложение сгенерировало неверное значение.
Таблица 1.2. Базовый тестовый пример
тестового Примера Статус Заработок, <$) Зеличина отчислений, ($) Ожидаемые результаты: причитающийся налог, ($) Реальный результат
налог 1 одинокий (-ая) 40 000 0 5 779 5 779
тенденция 1 одинокий (-ая) 43 000 0 тенденция к возрастанию 6 619
тенденция 2 одинокий (-ая) 46 000 0 7 459
тенденция 3 одинокий (-ая) 49 000 0 8 299
тенденция 4 одинокий (-ая) 52 ООО С ' ' 9139 *
тенденция 5 одинокий (-ая) 55 000 0 9 979
тенденция 6 одинокий (-ая) 58 000 0 10 819
тенденция 7 одинокий (-ая) 61 000 0 11 659
тенденция 8 одинокий (-ая) 64 000 0 12 499
Можно также проанализировать и другие тенденции:
• увеличение числа материально зависимых лиц приводит к снижению налога;
• увеличение дополнительной прибыли приводит к увеличению налога;
• увеличение статей отчислений уменьшает налог (кроме случаев, когда сущест-
вуют пороговые значения, ограничивающие допустимое число различных от-
числений).
Последний случай может служить иллюстрацией законов о налогообложении, ко-
торые ограничивают число статей отчислений. Когда тестеры замечают сильные из-
менения в тенденциях, это не всегда означает наличие проблемы. То, является ли
данный эффект результатом пересечения числовой границы или же это проблема в
приложении, будет решать авторитетное лицо проекта.
Хотя анализ тенденций действительно показывает, функционирует ли приложе-
ние должным образом, эта форма тестирования неэффективна по сравнению с дру-
гими методами разработки тестовых примеров. В главе 4 введены методы разбиения
на эквивалентные классы и методы анализа граничных значений, которые позволяют
проводить эффективное тестирование с широким диапазоном данных.
30
Глава 1
Стадия 4. Инвентаризация
Стадия инвентаризации состоит из определения типов данных, доступных в при-
ложении с последующей классификацией состояний, в которых может находиться
каждый элемент данных. Тестирование позволяет убедиться, что каждое состояние
используется по крайней мере один раз. Каждый набор состояний задает инвентар-
ный список.
На данном этапе по-прежнему используется базовый тест и за один раз модифици-
руется одно значение, чтобы можно было убедиться, что каждый элемент корректно
влияет на приложение. Рассмотрим два примера инвентарного списка: Статус и
Статьи отчислений, для этого нужно знать, какие результаты ожидаются для каждого
тестируемого состояния.
Инвентарный список Статус имеет пять возможных значений, перечисленных
ниже. Это взаимоисключающие категории, поскольку за раз используется только одно
значение. Каждое значение статуса влияет на вычисление суммарного налога. При-
менение инвентарного список Статус в базовом тесте приводит к созданию четырех
дополнительных тестовых примеров, показанных в табл. 1.3. Различные величины,
перечисленные в столбце Величина отчислений, представляют собой специфические
пороговые значения, связанные со статусом. Данные пороговые значения объяснены
в этом разделе позже.
Инвентарный список Статус:
• одинокий (-ая);
• женат (замужняя) с независимой декларацией доходов;
• женат (замужняя) с совместной декларацией доходов;
• глава семьи;
• вдовец (вдова).
Заметим, что каждый новый элемент в инвентарном списке влияет на результаты
именно так, как было задумано (не принимая во внимание то, логично это состояние
или нет). Кажется логичным, что три статуса требуют дополнительной информации.
Статус “глава семьи” требует включения нескольких материально зависимых лиц, а
оба статуса “женат (замужняя)” требуют информации о супруге. Кроме того, можно
вычислить изменение в налоге. В других приложениях состояния, полученные в ре-
зультате использования отдельных элементов в инвентарном списке, могут казаться
необычными. Однако их все-таки нужно протестировать, поскольку пользователь, ве-
роятно, введет те же нелогичные значения. Нужно убедиться в том, что приложение
верно обрабатывает данные. Сюда входят любые логические схемы обработки оши-
бок и сообщения об ошибках.
Лабиринты тестирования
31
Таблица 1.3. Тестовый пример, использующий инвентарный список Статус
ID тестового примера . Статус ''1 ' ' 5 чЖ £. * * ’ Заработок, ($) Величина от- числений, ($) Ожидаемые Реальный результаты: результат причитаю- щийся налог, (S)
налог 1 одинокий (-ая) 40 000 44 000 5 779
налог 2 женат (замужняя) с независимой декларацией до- ходов 40 000 3 675 6 537
налог 3 женат (замужняя) с совместной декларацией до- ходов 40 000 7350 4 061
налог 4 глава семьи 40 000 6 450 4 616
налог 5 вдовец (вдова) 40 000 7 350 4 481
Другую категорию инвентарных списков представляют статьи отчислений, кото-
рые не подразумевают взаимоисключений, поскольку налогоплательщик может уста-
новить любую комбинацию статей отчислений. 11есмотря на то, что можно использо-
вать различное число статей отчислений, чтобы убедиться, что каждый элемент ин-
вентарного списка корректно влияет на результирующие данные, поначалу за один
раз в базовом тесте нужно использовать одну статью отчислений. В табл. 1.4 были
внесены новые столбцы, чтобы отслеживать статьи отчислений и показать эти до-
полнительные тесты.
Инвентарный список статей отчислений.
• расходы на медицинское обслуживание и стоматологию;
• государственный и местный подоходный налог;
• налог на недвижимость;
• налог на движимое имущество;
• процент по закладной;
• пожертвования благотворительным организациям;
• невозмещенные затраты на содержание наемного работника;
• плата за подготовку налоговых документов;
• прочие отчисления.
Таблица 1.4. Тестовый пример, задействующий инвентарный список статей отчислений
ID Статус Заработок, (S) Тип статей отчислений Величина отчислений, (S) Ожидаемые результаты: причитающийся налог, ($) Реальные результаты Замечание: пределы статей рзеходов (налоговое законо- дательство)
тестового примера
налог 6 одинокий (-ая) 40 000 расходы на медицинское обслуживание и стоматологию 44 505 5 779 ограничивается до 7,5% от скорректиро- ванного валового дохода; вычету подлежит сумма 1405$
налог? одинокий (-ая) 40 000 государственный и местный подоходный налог 44 505 5765 применяется полностью
налог 8 одинокий (-ая) 40 000 налог на недвижимость 44 505 5 765 применяется полностью
налог 9 одинокий (-ая) 40000 налог на движимое имущество 44 505 5 765 применяется полностью
налог 10 одинокий (-ая) 40 000 процент по закладной 44 505 5 765 применяется полностью
налоги одинокий (-ая) 40 000 пожертвования благотворительным организациям 44 505 5 765 применяется полностью
налог 12 одинокий (-ая) 40 000 не возмещенные затраты на содержание наемного работника 44 505 5 779 ограничивается до 2% от скорректирован- ного валового дохода; вычету подлежит сумма $3 605
налог 13 одинокий (-ая) 40 000 плата за подготовку налоговых документов 44 505 5 779 ограничивается до 2% от скорректирован- ного валового дохода; вычету подлежит сумма $3 605
налог14 одинокий (-ая) 40 000 прочие разнообразные отчисления 44 505 5 765 применяется полностью
Лабиринты тестирования
33
Налоговое законодательство позволяет использовать либо статьи отчислений, ли-
бо стандартные отчисления — в зависимости от того, какая величина будет больше.
Для одинокого налогоплательщика в рассматриваемом базовом примере стандартное
отчисление составляет $4400. Чтобы использовать статьи отчислений, их сумма
должна превышать $4 400. Следовательно, в этом примере для каждого типа статей
отчислений будет использоваться сумма, равная $4 405. Однако не все типы статей от-
числений создаются равноценно; величину некоторых из них, как указано ниже, ог-
раничивают пороговые значения, зависящие от прибыли.
• Затраты на медицинское обслуживание и стоматологию должны превышать
7,5% скорректированного валового дохода. (Скорректированный валовой до-
ход получается путем суммирования всех заработков и прибылей с последую-
щим вычитанием допустимых затрат.) В базовом примере с заработком $40 000
первые затраты на медицинское обслуживание в размере $3 000 не подлежат
вычету. Следовательно, вычету подлежат только $1 405.
• Невозмещенные затраты на содержание наемного работника и на подготовку
налога предполагают ограничение в 2% от скорректированного валового дохо-
да. В базовом примере с заработком в $40 000 первые такие затраты в размере
$800 не подлежат вычету. Допускается вычет из $3 605.
После применения всех статей отчислений оказалось, что ожидаемый суммарный
налог составляет $5 765, принимая во внимание пороговые значения для отчислений
(которые в данном примере не превышают предельного значения), приводящие в ре-
зультате к налогу в размере $5 779. В табл. 1.4 показаны типы статей отчислений, ис-
пользуемые величины, а также введен дополнительный столбец, указывающий на то,
влияет ли предел на сумму.
Результатом инвентаризации является таблица контрольных проверок элементов.
В примере с налоговым калькулятором имеется значительно большее количество ин-
вентарных списков, которые также требуют тестирования (например, расходы по
сделке и источники доходов). Изолируя влияние каждого отдельного элемента ин-
вентарного списка, можно определить, корректно ли обрабатывает его приложение.
На данный момент было определено много тестов путем задания входных значе-
ний и ожидаемых результатов. При выполнении каждого теста наблюдались и запи-
сывались реальные результаты. Если реальные результаты отличаются от ожидаемых,
тест считается проваленным и возникает несоответствие, которое означает наличие
проблемы. Единственное, что можно сделать в данной ситуации, — это выдвинуть
предположение, что что-то неверно. Причин того, что тест не был пройден, может
быть несколько.
1. Неверное описание ожидаемых результатов. Такое случается, если требования
неясны, неправильно поняты или если ожидаемые результаты были неверно
рассчитаны (этот тип ошибки можно обнаружить при пересмотре тестового
примера. Описание пересмотров представлено в главе 9).
2. Ошибка возникла в ходе выполнения теста. Возможно, тестер ввел неверные
входные данные или же неисправно тестовое программное обеспечение (ко-
торое может иметь свои собственные дефекты).
3. В приложении действительно есть дефекты.
34
Глава 1
Что же делать? Необходимо убедиться, что ошибка произошла не из-за ввода тес-
тером неверного значения и что проблема не в тестовом программном обеспечении.
Тестеры не обязаны устранять дефекты, они должны составить список несоответст-
вий, а возможность решать предоставляется авторитетному лицу проекта. Причины
проблем могут быть следующими.
• Проблема возникла из-за требований: требование было пропущено; оно оказа-
лось двусмысленным, не вполне понятным; о требовании не сообщили тестеру.
• Тест оказался ошибочным из-за того, что неверно были определены ожидае-
мые результаты.
• Проблема возникла в ходе проведения теста (сложности с инструментальными
средствами тестирования или опечатка).
• В программном обеспечении действительно есть дефект.
• Авторитетное лицо не в состоянии повторно воспроизвести неполадку. В дан-
ном случае можно предположить, что сложности связаны с аппаратными кон-
фигурациями — они могут оказаться различными у тестера и у того, кто пытает-
ся воспроизвести неполадку (возможно, этому специалисту были предоставле-
ны неполные или неверные инструкции либо совсем другие тестовые данные.
Возможно также, что он не совсем точно следовал инструкциям).
После того как разработчики устранят проблему и создадут новую версию прило-
жения, тестеры должны повторно провести исходные тесты, запускаемые на преды-
дущих версиях, чтобы убедиться, что все функции в новом приложении работают так,
как было задумано. Когда времени мало или же иные ресурсы ограничены, тестеру
нужно решить, какие тесты будут использоваться повторно. В главе 8 предложено не-
сколько методов оценки степени риска и определены наиболее важные тестовые
примеры.
В примере с налоговым калькулятором использование определенных тестов зави-
сит от того, что в версиях приложения остается неизменным, поскольку ожидаемые
результаты будут изменяться из года в год согласно изменениям в налоговом законо-
дательстве.
Стадия 5. Комбинирование элементов инвентарных списков
Следующий этап тестирования представляет собой комбинирование элементов
инвентарных списков, чтобы можно было определить, предсказуема ли их совместная
работа. Для некоторых приложений может оказаться выгодным применение наращи-
ваемого подхода, в котором сначала сочетаются два элемента инвентарных списков, а
затем три, четыре и т.д. Другой наращиваемый подход заключается в использовании
таблиц тестовых примеров, в которых каждый последующий тестовьш пример — это
модификация предыдущего теста. Таким образом, последний из перечисленных выше
тестов содержит все накопленные из предыдущих тестов состояния.
Не все инвентарные списки содержат простые значения данных или состояния. Рас-
смотрим различные приложения, которые обрабатывают данные из файлов и руко-
водят управляемыми событиями прерываниями и для которых основной сложностью
Лабиринты тестирования
35
является пропускная способность. Наращиваемый подход состоит из следующих ти-
пов тестов.
• Индивидуальная обработка каждого файла.
• Обработка одного файла и генерация одного прерывания.
• Обработка двух файлов.
• Обработка двух файлов и генерация одного прерывания.
• Обработка двух файлов и генерация двух прерываний.
• И т. д.
При определении всех комбинаций получается огромное число тестовых приме-
ров — значительно больше, чем можно было бы выполнить в разумные сроки. Ключом
к разрешению ситуации служит анализ степени риска, определяющий наиболее важ-
ные функции приложения с последующим заданием схемы комбинаций, которая наи-
лучшим образом описывает отношения с высоким приоритетом.
В рассматриваемом примере налоговый калькулятор — это управляемое данными
приложение, каждый элемент в его инвентарном списке ранее был протестирован
изолированно, так что использование наращиваемого подхода для комбинирования
значений из инвентарных списков не кажется таким уж сложным. Инвентарные спи-
ски применяются в качестве таблицы контрольных проверок. Необходимо выбрать
типичные ус тановки, которые используются большинством налогоплательщиков. Те-
перь сосредоточимся на нормальном использовании системы, чтобы показать, что в
типичных условиях приложение работает как следует. Необычные комбинации дан-
ных будут рассмотрены позже.
В табл. 1.5 содержатся тесты с различными инвентарными списками. Столбцы с
заголовками, помеченными звездочкой (*), содержат те статьи отчислений, для кото-
рых существуют ограничения, связанные с величиной заработка. Формат таблицы
изменен, чтобы можно было лучше отследить все возможные комбинации.
Стадия 6. Граничные оценки
В тестах, выполняемых до настоящего момента, использовались типичные сцена-
рии, которые применяются чаще всего. Следующий этап заключается в исследовании
пределов возможностей приложения. Пределы возможностей приложения (или гра-
ницы) определяются данными. Эти пределы принимают множество форм в зависи-
мости от типа данных. Примерами могут служить:
• минимальные и максимальные значения диапазона данных;
• минимальный и максимальный размер поля (например, минимальное и макси-
мальное число символов);
• минимальный ц максимальный размер буфера.
Лабиринты тестирования
36
Таблица 1.5. Тестовый пример с комбинацией инвентаризации
Входные данные Статьи
ID Статус Заработок, Матерна- Налог на Государ- Налог на Налог на
тестового примера ($) льно зависи- мые лица медицину и стомато- логию», ($) ставимый и мест- ный на- лог,($) недви- жимость» <*)' движи- мое иму- щество» (S)
налог 15 одинокий (-ая) 40000 0 0 2200 1890 80
налог 16 женат (замужняя) с независи- мой декла- рацией доходов 60000 0 0 2200 1890 80
Общее правило тестирования границ — создать три тестовых примера, чтобы ох-
ватить следующие значения:
• граничное значение;
• граничное значение -1;
• граничное значение +1.
В налоговом калькуляторе предлагается использовать несколько границ, связан-
ных, например, со следующими моментами:
• для каждой налоговой категории определяется диапазон с минимальным и мак-
симальным значениями;
• как вычислять налог в зависимости от того, будет ли облагаемая налогом при-
быль больше или меньше $100 000;
• некоторые статьи отчислений О1'раничиваются 2% от скорректированного ва-
лового дохода;
• отчисления с разбивкой по статьям должны превышать стандар тное отчисление;
• по закону не существует верхнего предела на то, сколько человек может зарабо-
тать; количество материально зависимых лиц также неограничено. Минимум —
это, конечно, ноль.
Для большинства приложений типы данных имеют четко определенные верхние и
нижние границы. Очевидно, что нужно перечислить границы всех налоговых катего-
рий, а затем создать тест, использующий эти минимумы и максимумы. Однако налого-
вый кодекс США работает иначе. С помощью авторитетного лица проекта определя-
ются те i-раницы, которые влияют на вычисление налога для одинокого налогопла-
тельщика. Инструкции, предоставленные Налоговым управлением США, содержат
Лабиринты тестирования
37
отчислений <•’ 1 1 * , 4 ц J у, Выходные данные
Процент по Пожергеовэ- Нееовмвщен- Плата Прение Сумма Неаль-
закладной, ния йлагх/гао- ные затраты на за агчькле- отчие- результаты; ы»«ере-
($) рителыъм организа- циям, ($) содержание наемного ра- ботника»,^) подготовку налога, ($) НИЯ. ($) пении, (S) клцийся налог, ($) зуяьтаты
2800 500 100 50 0 7 470 4 911
2800 0 0 0 0 0 500 100 50 0 7470 11073
множество таблиц для вычисления налога. В табл. 1.7 показан список налоговых ста-
вок, который используется тогда, когда облагаемый налогом доход одинокого налого-
плательщика составляет $100 000 и больше. В основных инструкциях утверждается,
что налогоплательщик с облагаемым налогом доходом меньше $100 000 не может ис-
пользовать эту таблицу, однако данные инструкции составлены так, что налогопла-
тельщик может увидеть налоговую ставку, которая применяется на каждом уровне.
Такой список налоговых ставок определен для четырех диапазонов данных:
облагаемый налогом доход < $100 000
$100 000 < облагаемый налогом
доход <$132 600
$132 600 < облагаемый налогом
доход < $288 350
$288 350 < облагаемый налогом доход
использовать иной способ
для вычисления налога
налогоплательщик находится в налоговой
категории “31 %"
налогоплательщик находится в налоговой
категории “36%”
налогоплательщик находится в налоговой
категории “39,61%”
Диапазоны данных устанавливаются, исходя из суммы облагаемой прибыли. При-
близительно облагаемая прибыль состоит из суммы всех типов доходов, из которой
вычтены все разрешенные корректировки и отчисления. Существует множество спо-
собов получения результирующей облагаемой налогом прибыли. Чтобы не усложнять
объяснения, дальше будут вноситься изменения в базовый тестовый пример. Для
одинокого налогоплательщика, у которого нет материально зависимых лиц или от-
числений, облагаемая налогом прибыль получается путем вычитания из заработка
стандартного отчисления $4 400 и одного освобождения от налога в размере $2 800.
Это справедливо при условии, что скорректированный валовой доход меньше
$96 700, в противном случае величина освобождения от налога, которую можно
38 Глава 1
вычесть, ограничивается. Ключевым моментом здесь является определение входя-
щей финансовой информации, которая дает желаемую облагаемую налогом прибыль.
Таблица 1.7. Список налоговых ставок
для налогоплательщика со статусом "Одинокий (-ая)"
Список X - использовать, если статус "Одинокий (-ая)"
Только если облагаемая налогом прибыль (из формы 1040, строка 39) составляет $100 000
или больше.
Если величина Но не превышает, Ввести в форму №1040, строка , Из величины,;; '
в форме №1040, ($): •т:Л0,($):у i превышающей,
строка 39 "/ЛТт-
шает ($1:
0 26 250 + 15% 0
26 250 63 550 3937,50 + 28% 26 250
63 550 132 600 14381,50 + 31% 63 550
132 600 288 350 35787,00 + 36% 132 600
288 350 91857.00 + 39,6% 288 350
Источник: инструкция №1040 на 2000-й налоговый год, Налоговое управление, мини-
стерство финансов США
Когда определены диапазоны данных, следующим этапом становится разработка
тестовых примеров для тестирования границ. Поскольку эти границы узкие, т.е. два зна-
чения находятся на противоположных концах диапазона, понадобится только два
тестовых примера для каждой границы (пример разбиения на классы эквивалентности
описан в главе 4). Следовательно, тесты, перечисленные в табл. 1.8, используют зна-
чения в граничных точках и по ту сторону границы. В результате округления некото-
рые из ожидаемых результатов оказываются идентичными. Эти результаты отлича-
лись, если бы при вычислениях сохранялись значения с точностью до цента. Два до-
полнительных столбца используются исключительно с информационной целью. По-
скольку именно облагаемая налогом прибыль определяет тестируемые в данный мо-
мент границы (а также налоговую категорию), то эта информация будет включена
вместе с данными тестового примера.
Когда облагаемая налогом прибыль меньше $100000, для определения ставок ис-
пользуется справочная таблица. В табл. 1.9 показана справочная таблица для облагае-
мой налогом прибыли в диапазоне от $26 000 до $27 000. Налоговое управление США
предоставляет такие таблицы для каждого значения от $0 до $100000. Разбиение
справочной таблицы с шагом в $50, на каждом из которых определяется верхнее и
нижнее значение, требует ввода 2000 значений. Поскольку справочная таблица соз-
дана с шагом $50, возникает вопрос: какое же значение использовать для тестирова-
ния? Чтобы гарантировать, что каждое значение в таблице верное, в действительно-
сти нужно создать тест для каждого диапазона значений. Но такой подход непракти-
чен, поскольку отнимает очень много времени.
Таблица 1.8. Тестовый пример, использующий список налоговых ставок
ID тестового примера Статус &й Заработок, (S) ''fa' Материально зависимые лица Отчисления, (») Ожидаемые результаты: причитающийся налог, ($) Реальные Примечание: результаты . величина облагаемой налогом прибыли, ($) Примечание? метп д вычисления налога
налог 17 одинокий (-ая) 107200 0 0 25 681 100 000 налоговая категория "31%"
налог 18 одинокий ( ая) 139 519 0 0 35 787 132 599 налоговая категория "31%"
налог 19 одинокий (-ая) 139 520 0 0 35 787 132 600 налоговая категория "36%"
налог 20 оди юкий (-ая) 292749 0 0 91857 288 349 налоговая категория "36%"
налог 21 одинокий (-ая) 292 750 0 0$ 91 857 288 350 налоговая категория "39,о%"
40
Глава 1
Таблица 1.9. Таблица налогов для облагаемой налогом прибыли в диапазоне между $26 000 и $27 000
Если строка 39 (облагаемая налогом прибыль) составляет. и Вы:
по меньшей но меньше чем мере ОДИНОКИЙ (-ая) женат (замужняя) с независимой декларацией доходов* женат (замужняя) с совместной декларацией*- доходов глава семьи
Ваш налог составляет, ($): ’
26 000 26 050 3 904 3 904 4 437 3 904
26 050 26 100 3 911 3 911 4 451 3 911
26100 26150 3 919 3 919 4 465 3 919
26150 26 200 3 926 3 926 4 479 3 926
26 200 26 250 3 934 3 934 4 493 3 934
26 250 26 300 3 945 3 941 4 507 3 941
26 300 26 350 3 959 3 949 4 521 3 949
26 350 26 400 3 973 3 956 4 535 3 956
26 400 26 450 3 987 3 964 4 549 3 964
26 450 26 500 4 001 3 971 4 563 3 971
26 500 26 550 4 015 3 979 4 577 3 979
26 550 26 600 4 029 3 986 4 591 3 986
26 600 26 650 4 043 3 994 4 605 3 994
26 650 26 700 4 057 4 001 4 619 4 001
26 700 26 750 4 071 4 009 4 633 4 339
26750 26 800 4 085 4 016 4 647 4 316
26 800 26 850 4 099 4 024 4 661 4 024
26 850 26 900 4113 4 031 4 675 4 031
26 900 26 950 4127 4 039 4 689 4 039
26 950 27 000 4141 4 046 4 703 4 046
*Этот столбец также должен использовать вдовец (вдова)
Источник: инструкция №1040 на 2000-й налоговый год, Налоговое управление, мини-
стерство финансов США
Во время тестирования справочной таблицы необходимо:
• убедиться, что индекс предоставляет доступ к нужной части таблицы;
• удостовериться, что значения в таблице верны.
Лабиринты тестирования
41
Использование значения облагаемой налогом прибыли в качестве индекса в таб-
лице кажется совершенно логичным. Разработчики должны быть уверены в том, что
приложение предоставляет доступ к верной позиции в таблице, и, следовательно, по-
исковая часть работает правильно для всех индексов. Если это так, нужно вниматель-
но изучить первый диапазон в табл. 1.9. Это даст возможность ввести два дополни-
тельных теста, как показано в табл. 1.10.
Выполнение тестовых примеров “налог 22” и “налог 23” демонстрирует работо-
способность приложения по крайней мере, для двух отдельных значений. Можно
предположить, но не гарантировать, что приложение будет работать и для других
диапазонов. А как же насчет сохранности данных в таблице? Единственный реальный
способ проверить данные — создание тестов для каждого элемента справочной табли-
цы. Опять же, временные ограничения делают это невозможным. Предполагая, что
значения таблицы сохранены в файле какого-либо типа, самым эффективным путем
проверки значений таблицы будет проинспектировать их, т.е. сделать копии таблиц и
сравнить их с таблицами, предоставленными Налоговым управлением США Нельзя
сказать наверняка, какой подход нужно использовать. Какое бы ни было принято ре-
шение, следует убедиться, что авторитетное лицо проекта не возражает против тако-
го подхода.
Граничным значением облагаемой налогом прибыли, составляющим $100 000, оп-
ределяется то, будет ли для вычисления налога использоваться список налоговых ста-
вок или таблица налогов. Хотелось бы иметь тест, который бы устанавливал облагае-
м}то налогом прибыль в размере $99 999 и $100 000, как показано в табл. 1.11.
Если в тестовом примере “налог 24” приложение ошибочно использует при вы-
числениях для определения налога налоговую категорию 31%, вместо того, чтобы ис-
пользовать таблицу налогов, оно возвратит неверное значение $25 681. Этот тест дает
возможность получить обратную связь, чтобы проверить, использует ли приложение
для вычисления налога подходящий метод.
Конечно, нужно также протестировать нулевое значение для различных полей,
как это показано в табл. 1.12. Ожидается, что приложение “Налоговый калькулятор”
будет отлавливать отрицательные значения и отправлять сообщение об ошибке.
В тестовом примере “налог 30” доход составляет $7 200, что дает в результате значе-
ние облагаемой налогом прибыли, равное $0 и, следовательно, в столбце с причи-
тающимся налогом окончательное значение равно $0.
В ходе определения тестов были сделаны предположения относительно того, ка-
кими будут граничные значения для тестирования и какие значения из него исклю-
чаются. Анализ степени риска помогает удостовериться, был ли выбран подходящий
тест.
До сих пор рассматривалось только влияние данных на налогоплательщика со ста-
тусом “одинокий (-ая)”. Аналогичные наблюдения применимы и к другим статусам,
поскольку в списке налоговых ставок для различных статусов определяются различ-
ные граничные значения, а в таблицу налогов для различных статусов возвращаются
с азличные значения. Понадобится также определить тесты, которые будут касаться
~раниц других типов данных, аналогично тем, что касаются статей отчислений.
Таблица 1.10. Тестовый пример для поиска по облагаемой налогом прибыли
ю тестового примера Статус Заработок, (J) Материально зависимые лица Отчисление, ($) Ожидаемь»е результаты причитающийся налог, ($) Реальные результаты Примечание: величина облагаемой налогом прибыли, ($)
налог 22 одинокий (-ая) 33 249 0 0 3 904 26 049
налог 23 одинокий (-ая) 33 250 0 0 3 911 26 050
Таблица 1.11.1 естирование граничного значения облагаемой налогом прибыли в размере $100 000
ID Статус Заработок, Материально, Отчисления, Ожидаемые Реальные Примечание: Примечание: тестового ($} зависимые ($ . результаты: результаты величина об- метод лычис- примера. лица причитающийся латаемой на- пения налога налог, ($) логом прибыли, - __ (>> налог 24 одинокий (-ая) 107199 0 0 25 673 99 999 Справочная таблица налогов налог 25 одинокий (-ая) 107 200 0 0 25 681 100 000 налоговая ка- тегория "31%"
Таблица 1.12. Тест, проверяющий нулевую границу
ID Статус Заработок, ($) Материально Величина Ожидаемые результаты Реальные результаты тестового -- - \ : , зависимые лица отчислений, ($) причитающийся налог примера налог26 одинокий (-ая) 0 0 0 0 налог27 одинокий (-ая) -10 0 Ошибка налог 28 одинокий (-ая) 0 0 -1 Ошибка налог 29 одинокий (-ая) 0-1 0 Ошибка налог 30 одинокий (-ая) 7 200 0 0 0
Лабиринты тестирования
43
Стадия 7. Ошибочные данные
На следующей стадии тестирования делается попытка вывести приложение из
строя, создавая условия, в которых обычный пользователь, вероятнее всего, работать
не будет. Рассмотрим создание тестов следующих категорий.
• Данные не вводятся для того, чтобы проследить поведение приложения: обес-
печит ли оно прерывание или сгенерирует сообщение об ошибке.
• Вводятся неверные числовые данные (отрицательные значения или буквенно-
цифровые комбинации символов).
• Вводятся данные какого-либо формата, который для такого типа данных счита-
ется недопустимым.
• Используются необычные комбинации данных.
• Проверяется использование нулевого значения, если это еще не сделано в пре-
дыдущих тестах.
Необходимо дать текущим пользователям возможность поработать с новой систе-
мой. Нужно посмотреть, какие значения они вводят и как они интерпретируют под-
сказки системы.
Цель определения необычных комбинаций заключается в проверке приемлемого
поведения приложения, даже в том случае, если тестовые данные не описывают нор-
мального налогоплательщика. В пример с налоговым калькулятором можно включить
следующие необычные ситуации.
1. Очень низкий заработок плюс очень большое число материально зависимых лиц.
2. Очень высокий заработок при отсутствии отчислений.
3. Отчисления, превышающие величину суммарной прибыли.
При создании тестового примера с ошибочными данными в результате обычно
появляется сообщение об ошибке. Ожидается, что приложение отловит эти данные и
проинформирует пользователя об ошибке. При таких условиях тест считается прой-
денным, поскольку система, как и ожидалось, возвратила сообщение об ошибке.
В некоторых случаях предыдущую стадию тестирования можно обойти и всецело
сосредоточиться на том, чтобы вывести систему из строя и найти действительно до-
садные ошибки. Хотя у этого подхода есть свои преимущества, наилучшей тактикой
будет проанализировать риск, чтобы определить, в каком направлении следует при-
лагать усилия по тестированию и за счет отказа от тестирования каких функций это
нужно сделать. Когда на тестирование продукта назначено несколько человек, один
из них может посвятить свое время исключительно нахождению серьезных ошибок.
Фокусировка деятельности исключительно на нахождении серьезных дефектов соз-
дает некоторые сложности, так как многие проблемы не приводят к аварийным си-
туациям. Тестеры должны достаточно хорошо знать приложение, чтобы опреде-
лять, верны ли выходные данные. Попытки создать аварийную ситуацию в системе
часто состоят в поверхностном наборе команд. При этом, однако, могут возникнуть
44
Глава I
сложности, связанные с тем, что входная информация, которая привела к возникно-
вению неполадки, не была документирована.
В главе 2 представлена таблица контрольных проверок верных и неверных дан-
ных, помогающая определить ошибочные данные.
Стадия 8. Создание напряжений
На следующей стадии тестеры отходят от функций приложения и оценивают усло-
вия их реализации в терминах рабочих характеристик и восстановления системы.
Оценка рабочих характеристик обычно включает измерение времени, которое
уходит на выполнение отдельных операций. Характерные времена варьируются, если
приложение запускается в специализированной или полностью загруженной системе.
Еще один аспект, влияющий на рабочие характеристики системы, требует создания
во время тестирования напряжений в среде, в которой она работает. Данный аспект
включает следующие тесты.
• Уменьшение объема доступной памяти.
• Использование всего доступного дискового пространства.
• Параллельный запуск нескольких экземпляров приложения.
• Запуск приложения в момент, когда система выполняет резервирование.
• Генерация множества асинхронных, управляемых событиями процессов.
Иногда приложению приходится восстанавливаться после неполадок. Даже если
тестер перезагружает систему, после перезапуска все должно функционировать кор-
ректно. Тесты, наносящие вред среде, должны включать:
• выбрасывание приложения;
• разьединение кабелей;
• отключение питания.
Доказательством того, что приложению был нанесен сильный ущерб, служат:
• недоступные файлы;
• открытие заблокированных файлов;
• разрушенные базы данных;
• невозможность перезапуска приложения.
В описании категорий тестов в главе 2 определены другие методы создания на-
пряжений в среде.
Дальнейшие шаги
В образцах тестовых примеров представлено только использование значений дан-
ных в налоговом приложении. Естественно, для проверки функциональных возмож-
ностей других полей данных, которые не обсуждались в этой главе, нужны дополни-
тельные тесты.
Лабиринты тестирования 45
График выпусков достаточно сжат, поэтому в большинстве тестов в этой главе
внимание было сосредоточено на демонстрации того, что приложение работает так,
как было задумано. Хотя инвентаризация дает начало многим тестам, для полного изу-
чения системы требуются другие тесты. Использование методов схем (см. главы 2 и 3) и
таблиц (см. главы 4 и 5) поможет определить эти дополнительные тесты.
Подход на основе теории графов дает тестовые примеры, которые определяют все
возможные пути в приложении. Эти методы включают:
• тестирование управляющей логики;
• тестирование потока данных;
• тестирование операционных потоков.
Данный метод объяснен и очень детально проиллюстрирован в работе [Beizer 95].
В отличие от предварительных тестов, использованных в этой главе, приближения
теории графов приводят к исчерпывающему анализу программного обеспечения.
Совершенно разные категории тестов позволяют убедиться, что приложение не
делает того, что оно не должно делать. На предыдущей стадии были созданы тесты, в
которых была предпринята попытка вывести систему из строя (например, введение
запредельных значений данных). Однако нужны еще тесты, в которых можно будет
отыскать нежелательные побочные эффекты, такие как измененная память, разру-
шенные буфера или другие непредусмотренные результаты.
Стратегия, предложенная в данной главе, — это один из эффективных способов, с
помощью которого можно разобраться с проблемой тестирования плохо документи-
рованных приложений в сжатые сроки. За другими идеями относительно того, как
‘тестировать в темноте”, можно обратиться к работе [Rothman 99].
Успешное тестирование, — как и качество программного обеспечения, — зависит
от многих других дисциплин разработки ПО, включая:
• конфигурационный менеджмент, чтобы иметь возможность следить, какая версия
приложения в данный момент тестируется;
• составление отчетов о неполадках, чтобы работать со списком спорных вопросов
и проблем, найденных тестером;
• управление внесением изменений, чтобы иметь возможность отслеживать, какие
неполадки исправляются в текущем выпуске и чтобы сохранять список тех не-
поладок, которые не будут устранены в ближайшем будущем.
В главе 9 обсуждается важность этих тем для тестирования программного обеспе-
чения.
Резюме
Даже когда близится выпуск продукта, тестеры могут оценить критичные компо-
ненты приложения и подтвердить, что ключевые функции работают корректно. Есте-
ственно, тостеры могут обеспечить лучшую обратную связь, если в их распоряжении
46
Глава 1
достаточно времени. При тестировании приложения в сжатые сроки можно выде-
лить следующие основные этапы.
Каждая стадия базируется на предыдущих. Основная тактика — определить наибо-
лее типичный пользовательский сценарий и использовать эти данные в качестве ба-
зовых для создания дополнительных тестов. Изменяя за раз один параметр, тестер
может убедиться, что каждое изменение влияет на приложение так, как было задумано.
Стадия 1: Изучить приложение. Установить авторитетное лицо проекта.
Стадия 2: Определить базовый тестовый пример, для выполнения которого не- обходимо создать среду тестирования.
Стадия 3: Проанализировать тенденции, если сложно спрогнозировать результаты.
Стадия 4: Определить инвентарные списки. Исходя из списков, сгенерировать тестовые примеры.
Стадия 5: Скомбинировать данные из различных инвентарных списков.
Стадия 6: Сделать граничные оценки.
Стадия 7: Создать тесты с ошибочными данными, чтобы попытаться вывести систему из строя.
Стадия 8: Создать напряжение в системных ресурсах. Определить, как система справляется с аварийными ситуациями.
Иногда тестерам приходится выбирать, какие тесты будут заданы и выполнены,
поскольку для тестирования всех функций не хватает времени. Анализ степени риска
(см. главу 8) помогает определить наиболее важные для тестирования области даже
перед созданием какого-либо тестового примера.
Представленные здесь идеи помогут тестерам начать действовать. Для полного
тестирования системы требуется дополнительная работа. В последующих главах опи-
сываются методы планирования и создания дополнительных тестовых примеров.
ГЛАВА
Схемы тестов
Введение
Часть проекта, которая касается тестирования, может оказаться слишком трудной
для многих тестеров. Иногда проект кажется огромным, а данные беспорядочно-раз-
бросанными. В таком случае, очевидно, что многим тестерам сложно получить необ-
ходимую информацию и определить, какие дополнительные данные могут понадо-
биться для разработки тестовых примеров.
В этой главе будет рассмотрено типичное описание продукта вместе с далекими от
идеала требованиями. Даже если работа организации в области тестирования все еще
не налажена, можно продолжить разработку тестовых примеров на ранней стадии и
определить проблемы.
Вместо того чтобы жаловаться на несовершенные требования тестерам следует
поддерживать связь с командой разработчиков и попытаться усовершенствовать оп-
ределение продукта. Во время рассмотрения требований авторитетное лицо проекта
предоставляет дополнительную информацию (пользовательскую документацию и от-
веты на возникающие по ходу работы вопросы). В этой главе все действия тестеров
представлены в хронологическом порядке, чтобы показать, что для начала не обяза-
тельно нужна вся информация о приложении. В лучшем случае работа должна прово-
диться параллельно с разработчиками, когда тестовые примеры и программное обес-
печение разрабатываются одновременно. Со временем более детальная информация
о приложении становится доступной, так как тестер использует итеративный подход
к пониманию требований.
Работа тестера состоит в том, чтобы:
• узнать о новом приложении; ,
• перечислить возможности тестового примера;
• определить тестовый пример;
• выбрать, какие будут проводиться тесты;
48
Глава 2
• создать среду тестирования;
• провести тесты.
В примерах этой главы для работы на первых двух этапах используется схематиче-
ский подход. Тестовые примеры определены в главе 3, а в главе 8 выбраны наилучшие
из них. В главе 9 обсуждаются последующие этапы в цикле тестирования.
Пример приложения
Примером приложения служит контроллер духового шкафа, его функции кратко
описаны на рис. 2.1. На рис. 2.2 представлена диаграмма контекста, на которой пока-
заны входные и выходные данные для контроллера духового шкафа. Задача тестера —
проанализировать требования с последующим определением набора тестов.
Краткое описание приложения
Спроектировать контроллер для электрического духового шкафа, который по-
зволит пользователю выбирать нужную температуру приготовления и задавать
время. Духовой шкаф будет разогреваться и выключаться согласно введенной
пользователем информации.
Рис. 2.1. Описание приложения
текущая температура
духового шкафа-----
часы
время начала
время окончания
желаемая температура приготовления
команда начала/окончания
Контроллер
духового шкафа
нагревательный элемент
> включен/выключен
звуковой сигнальный элемент
> включен/выключен
> символы дисплея
Рис. 2.2. Диаграмма контекста контроллера духового шкафа
В дополнение к перечисленной выше информации о продукте предоставлен набор
так называемых “требований”, поскольку их содержимое не описывает реальных сис-
темных требований. В некоторых проектах приложения описываются более чем ту-
манно.
Требований явно не хватает, однако для того, чтобы продолжить разработку теста,
информации вполне достаточно. Для построения описания теста и его определения
несложно будет сконцентрировать внимание на проблеме с данными требованиями.
В идеале, кто-то должен провести анализ требований, чтобы убедиться, что они пол-
ные. Однако не каждая организация проходит через этапы, повышающие качество
системы. Несмотря на это серьезное упущение, можно все-таки установить наличие
проблем на ранней стадии цикла разработки, т.е. до того, как разработчики начнут
проектировать и писать код.
Схемы тестов
49
Контроллер духового шкафа будет работать при частоте 30 МГц (или выше) и
контролировать температуру в диапазоне от 200° Ф до 500° Ф, по умолчанию
задается 350° ф и значения температуры будут кратны 5, что определяется поль-
зователем на клавишной панели. Управление автоматическое или ручное, а вве-
денная пользователем температура поддерживается с точностью до 2° Ф. В кон-
це выпечки в духовом шкафу выключается нагревательный элемент и в автома-
тическом режиме подается звуковой сигнал. Программа духового шкафа начи-
нает работать, когда пользователь дает команду старта; в будущих выпусках она
будет управлять приготовлением в режиме гриль и в микроволновом режиме.
В автоматическом режиме пользователь задает время начала и окончания ра-
боты. Нагрев начинается тогда, когда наступает время начала работы и заканчи-
вается, когда время истекает или когда пользователь дает команду окончить ра-
боту; позже это будет применимо как для автоматического, так и для ручного
режимов. Часы отображают текущее время и отслеживают истекшее время. Руч-
ной режим включается тогда, когда пользователь вводит команду начала рабо-
ты, и заканчивается при введении команды ее окончания.
Рис. 2.3. Предъявленные требования
Выделение требований
Опытные разработчики, которые разбираются в специфических требованиях,
зозможно, захотят исправить изъяны в требованиях и усовершенствовать имеющую-
ся информацию, чтобы создать хорошие требования. Можно отложить подобные по-
сытки, чтобы продемонстрировать, что тестирование помогает находить сложности
з требованиях. Некоторые тестеры по различным причинам не сметут улучшить тре-
бования (например, если авторитетное лицо проекта не обладает достаточными зна-
'иями о написании требований, поджимают сроки, нарушена связь между авторитет-
ным лицом проекта и тестерами). Однако главная причина заключается в нехватке
зремени для тестирования. Автор этой книги отнюдь не настаивает на игнорирова-
нии анализа требований и этапов пересмотра, однако у некоторых тестеров может
росто не оказаться иного выбора, кроме как продолжать тестирование. Некоторый
еотъемлемый риск, связанный с игнорированием этапа усовершенствования требо-
заний, может состоят!, в следующем.
• Создание неправильного приложения.
• Неудовлетворение требований заказчика.
• Сложности с интеграцией и слиянием приложений.
• Отмена проекта.
Чтобы больше узнать о требованиях, можно обратиться к работам [Gause 89],
Hamlet 01], [IEEE 830], [Robertson 99] и [Wiegers99J.
Начинать процесс тестирования следует с преобразования обременительного,
'ивающего с толку абзаца в список из отдельных предложений или фрагментов,
жак это показано на рис. 2.4. Из-за неопределенности, которая содержится в описа-
нии приложения, при попытке разобраться с путаницей допускается некоторая
50 Глава 2
вольность. Естественно, что авторитетному лицу проекта следует определить, верна
ли сделанная интерпретация требований. Предполагается, что номер на каждом эле-
менте списка поможет обращаться к нему по мере продвижения работы. Это облегчит
оперативный контроль требований там, где можно будет отслеживать, как использу-
ется каждый элемент списка, а затем определять, какой тестовый пример образовался
из этого элемента.
Т-1 Духовой шкаф будет регулировать температуру в диапазоне от 200° Ф до 500° Ф с шагом 5° Ф.
Т-2 Контроллер духового шкафа будет поддерживать заданную температуру с точностью до ±2° Ф.
Т-3 Т-4 Т-5 Т-6 Духовой шкаф будет работать в ручном или автоматическом режиме. Пользователь будет определять температуру приготовления. По умолчанию температура приготовления будет составлять 350° Ф. В автоматическом режиме пользователь будет задавать время начала и время окончания работы.
Т-7 Автоматический режим начинает работать, когда пользователь выдаст команду начинать.
Т-8 Нагрев в ручном режиме будет начинаться, когда пользователь введет команду начала работы.
Т-9 Т-10 Нагрев в автоматическом режиме будет начинаться в указанное время начала. Ручной режим будет выключаться, когда пользователь выполнит команду окончания.
Т-11 Автоматический режим будет выключаться, когда истечет время или когда пользователь выполнит команду окончания.
Т-12 Т-13 При нагреве в духовом шкафу будет выключаться нагревательный элемент. При автоматическом выключении духовой шкаф будет подавать звуковой сигнал.
Т-14 Контроллер духового шкафа будет в состоянии управлять приготовлением в режиме гриль и микроволновом режиме в будущей версии.
Т-15 Т-16 Т-17 Т-18 Быстродействие процессора будет составлять по меньшей мере, 30 МГц. У пользовательского интерфейса будет буквенно-цифровой дисплей. Интерфейс ввода пользователем будет иметь вид клавишной панели. Температура духового шкафа и сообщения отсылаются на буквенно-цифровой дисплей.
•Т-19 Часы будут показывать текущее время и будут в состоянии контролировать истекшее время.
Рис. 2.4. Описание приложения с разбиением на пункты
Следующий этап заключается в разбиении требований на три типа: входные со-
стояния, ожидаемые результаты и проектные ограничения. Входная информация ис-
пользуется при разработке теста, выходная информация будет использована позже при
определении тестовых примеров, а проектные ограничения в тесты не включаются.
Схемы тестов
51
Ожидаемые результаты
Это общий термин, описывающий результирующее поведение системы, включая
внутреннее состояние или изменение памяти, которые пользователю наблюдать
гложно, в дополнение к образованию отдельных значений или набора результирую-
щих данных. Помимо значений выходных данных при выполнении тестов часто не-
; бходимо Оценивать и другие трансформации. На рис. 2.4 перечислены пять требо-
ваний, описывающих результаты; эти положения будут исключены из списка входных
тостояний.
Описание ожидаемых результатов
Т-2 Контроллер духового шкафа будет поддерживать заданную температуру
с точностью до ±2° Ф.
Т-9 Нагрев в автоматическом режиме будет начинаться в указанное время.
Т-12 При нагреве в духовом шкафу будет выключаться нагр< ва гельный элемент.
Т-13 При автоматическом выключении духовой шкаф будет подавать звуковой
сигнал.
Т-18 Температура духового шкафа и сообщения отсылаются на буквенно-
цифровой дисплей.
Проектные ограничения
Хотя проектные ограничения иногда и маскируются под требования, тестеры за
ж не отвечают. Проектные ограничения налагаются проектом системы, а не пред-
т >лагаемым ее поведением. Часто требования могут предусматривать некоторые бу-
птцие возможности или свойства системы, играя роль связующего звена с функция-
ми, которые еще не разработаны. Цель таких указаний — позволить инженерам соот-
етствующим образом адаптировать свои проекты. Пересмотр проекта позволяет оп-
ределить, насколько хорошо предложенная структура системы приспособится к бу-
~.тцим модификациям. В противном случае архитектура результирующего продукта
вжет оказаться неприемлемой. В других требованиях также перечисляются исполь-
емые специфические аппаратные компоненты или указывается, что система будет
' апускаться на предварительно установленной операционной системе. Проблемы,
обнаруженные в ходе пересмотра проекта или инспекции, гораздо легче исправить на
швей стадии цикла разработки, чем устранять в процессе тестирования системы,
г гда тестеры просто подтвердят, что система не может удовлетворить одно из тре-
бований.
В отдельных случаях подходящей стратегией тестирования может оказаться вари-
ант, когда тестеры действительно должны модифицировать продукт, чтобы упро-
сить добавление компонент. Этот подход особенно эффективен, когда у конечного
гхмьзователя будет возможность модифицировать продукт (например, программное
"гиложение, позволяющее конечному пользователю добавлять выборочные модули!
В гакой ситуации тестер должен подтвердить, что инструкции по добавлению опреде-
ленных пользователем модулей корректны. В рассматриваемом примере тестирование
52
Глава 2
наращиваемости не предусмотрено, поскольку конечный пользователь не будет мо-
дифицировать контроллер духового шкафа, чтобы добавить функции гриля и микро-
волнового режима.
Пять элементов из перечисленных на рис. 2.4 — это проектные ограничения, ко-
торые лучше всего проверять в ходе пересмотра проекта системы. В противном слу-
чае в продукте могут быть построены неверные компоненты. Таким образо.м, в списке
входных состояний будут пропущены следующие компоненты.
Описание проектных ограничений
Т-14 В будущей версии контроллер духового шкафа сможет управлять
приготовлением в режиме гриль и микроволновом режиме.
Т-15 Быстродействие процессора будет составлять по меньшей мере, 30 МГц.
Т-16 У пользовательского интерфейса будет буквенно-цифровой дисплей.
Т-17 Интерфейс ввода пользователем будет иметь вид клавишной панели.
Т-19 Часы будут показывать текущее время и контролировать истекшее время.
Таким образом, требования разбиты на категории входных состояний, ожидаемых
результатов и проектных ограничений. Теперь снова обратите внимание на список
входных состояний, поскольку он представляет основу для разработки схемы теста.
Схематический подход
Схематический подход — это метод, который используется для рассмотрения тре-
бований. Требования преобразуются в схемы для того, чтобы перечислить различные
условия теста. Схематический метод тестирования управляется процессами и не зави-
сит от содержания. Реально он поможет обнаружить отсутствующую в требованиях
информацию. Каждый элемент в схеме в конечном счете, будет определять входные
состояния для тестового примера.
Схема, как показано на рис. 2.5, представляет собой древовидную структуру, в ко-
торой между корнем и каждым листком существует однозначно определяемый путь.
Этот путь устанавливает специфический набор входных состояний, которые затем
будут использованы для определения тестового примера. Схема содержит узловые
точки, или точки ветвления, обозначающие подсказки, тип значения или входной ва-
риант. Нумерация узла обозначает специфическое входное состояние соответствую-
щего ему предка. Число листьев на дереве (или путей в схеме) дает приблизительное
число тестовых примеров, необходимых для тестирования всех функций. В зависи-
мости от структуры схемы можно иметь точное соответствие между каждым путем в
схеме и связанным с ним тестовым примером.
Создание схемы — это итеративный процесс. Начальный список образуется на ос-
нове требований, которые были выделены в категорию входных состояний. Номер
требования включен для того, чтобы облегчить оперативный контроль. Каждая по-
следующая схема является усовершенствованием предыдущей. Число итераций, не-
обходимых для создания окончательной версии, зависит от опыта и от проекта.
Схемы тестов
53
Каждый специалист продолжает делать свою работу. Последнюю итерацию тестеры
выполняют совместно с остальными разработчиками, поскольку именно из этой по-
бедней версии будет выводиться тестовый пример.
Последовательность версий схем — это именно то, что тестер должен разраба гы-
ъать в ходе одного или нескольких сеансов редактирования, каждый из которых мо-
кет занимать от двух минут до нескольких дней. Цель примера заключается в иллюет-
" ации мысленных процессов. На каждой итерации, представленной в следующем
римере, изображаются “путь редактирования” и продолжение предыдущего пут.
лзроводительное пояснение при описании мысленных процессов, которые при j i
полпенни могут отнять меньше минуты, может показаться чрезмерным. Между каж-
дой итерацией схемы не предполагается никаких пересмотров или инспекций. Пере-
мотр можно было бы запланировать на момент завершения последней итерации, по-
-ззанной в примере. В течение промежуточных итераций схемы тестер консультиру-
ется с авторитетным лицом проекта, чтобы получить ответы на вопросы, касающиеся
введения продукта.
Некоторым тестерам схематичный подход может показаться интуитивным, а дру-
~71м — утомительным. Преимущество схематического подхода заключается в том, что
н служит инструментом для дискуссий и помогает получить необходимую информа-
цию от команды разработчиков. Это инструмент организации мышления. Схема вы-
деляет основную часть в документации с требованиями, отфильтровывая лишние
_товесные выражения.
54
Глава 2
Все элементы в схеме сгруппированы логичным образом исходя из предпочтения
тестера. Порядок или группа, в которой определены элементы, не играют существен-
ной роли: результирующий набор листьев — важная информация, поскольку эти ли-
стья в итоге определяют тестовые примеры. Порядок выполнения тестовых приме-
ров не важен при условии, что определены все основные тесты.
Разработка схемы теста
При создании схемы теста будет использоваться список с отступами. Первый этап,
показанный на рис. 2.6, заключается в перечислении всех входных описаний из спи-
ска требований как отдельных элементов с определенной логической классификаци-
ей. Исходные группы в этом примере — температура духового шкафа, ручной и авто-
матический режимы.
1 Температура духового шкафа
1.1 [Т-1] Границы 200-500’Ф
1.2 [Т-1] Шаг5°Ф
1.3 [Т-5] По умолчанию 350°Ф
2 [Т-3] Ручной режим
2.1 [Т-4] Температура приготовления
2.2 [Т-8] Команда начала работы
2.3 [Т-10] Команда окончания работы
3 [Т-3] Автоматический режим
3.1 [Т-4] Температура приготовления
3.2 [Т-6] Время начала работы
3.3 [Т-6] Время окончания работы
3.4 [Т-7] Команда начвла работы
3.5 [Т-11] Окончание приготовления
3.5.1 [Т-11] Истекшее время
3.5.2 [Т-11] Команда окончания работы
Рис. 2.6. Итерация схемы № 1
Для создания итерации схемы №2 элемент температура духового шкафа (с п. 1.1 по
п. 1.3 на рис. 2.7) будет перемещен в область дополнительного описания температуры
приготовления в ручном и автоматическом режимах. Зачем это делается? Пользова-
тель работает с духовым шкафом в одном из двух режимов: автоматическом или руч-
ном. Температура может вести себя по-разному в зависимости от того, какой исполь-
зуется режим, так что в схеме пути должны разделяться, чтобы можно было различать
температуру приготовления в ручном и в автоматическом режимах. На рис. 2.8 пока-
зана модифицированная схема с выдвинутым на первый план влиянием элементов.
Схемы тестов
55
1 Температура духового шкафа
Ti [Т-1] Границы 200-500°Ф
1.2 [Т-1] Шаг5°Ф
1.3 [Т-5] По умолчанию 350’Ф
2 [Т-3] Ручной режим
2.1 [Т-4] Температура приготовления
2.2 [Т-8] Команда начала
2.3 [Т-10] Команда окончания
3 [Т-3] Автоматический режим
3.1 [Т-4] Температура приготовления
3.2 [Т-6] Время начала *
3.3 [Т-6] Время окончания
3.4 [Т-7] Команда начала
3.5 [Т-11] Окончание приготовления
3.5.1 [Т-11] Истекшее время
3.5.2 [Т-11] Команда окончания работы
Рис. 2.7. Переход от итерации схемы № 1 к итерации схемы № 2
1 Ручной режим
1.1 [Т-4] Температура приготовления
1.2 [Т-8] Команда начала работы
1.3 [Т-10] Команда окончания работы
2 Автоматический режим
2.1 [Т-4] Температура приготовления
2.1.1 [Т-1] Гребцы 200-500-С
2.12 [Т-1]Шяг5'Ф
2.1.3 [Т-5] По умслчв*.
2.2 [Т-6] Время начала работы
2.3 [Т-6] Время окончания работы
2.4 [Т-7] Команда начала работы
2.5 [Т-11 ] Окончание приготовления
2.5.1 [Т-11] Истекло время
2.5.2 [Т-11] Команда окончания работы
Рис. 2.8. Итерация схемы №2
Итерация схемы № 2 по-прежнему содержит информацию из исходных требований.
~.реимущество схематического подхода заключается в предоставлении иерархической
эуктуры, в которой аналогичные функции сгруппированы вместе. Естественно, что
56
Глава 2
1
разные тестеры будут создавать совершенно различные схемы, однако конечным
критерием будет согласие между структурой схемы и поведением приложения так, как
это описано в требованиях или других описаниях продукта. Несмотря на высокую ве-
роятность утраты некоторого смысла при переходе в описании, главная задача состо-
ит в определении основных функций, подлежащих тестированию.
Хотя итерации схемы № 2 для создания тестового примера не достает данных, это
очень важный промежуточный этап. Его текущая форма включает структуру, в кото-
рую добавляются категории тестов. Категории тестов содержат стандартный набор
условий теста, которые естественным образом вытекают из природы программного
обеспечения. Умение решать, какие условия тестирования добавить, приходит с опы-
том. Далее рассматривается набор категорий, который уже можно применять на
практике. Теперь отвлечемся от примера с контроллером духового шкафа и его схе-
мы, чтобы узнать о категориях тестов.
Категории тестов
Кажется, что опытные тестеры в состоянии сразу же создать оригинальные тесты,
так как они думают обо всех вариантах состояний ввода, вытекающих из категорий
тестов. Безусловно, применение категорий тестов ко всем возможным входным усло-
виям помогает определить тесты. Для каждой категории тестов тестер должен поду-
мать над таким вопросом: “Каких результатов следует ожидать при данных условиях?”.
Часто тестеры не могут ответить на этот вопрос, поскольку требования не описывают
поведение системы в данных специфических условиях. Таким образом, тестеру необ-
ходимо составить список вопросов, которые начинаются со слов “что если...?”, а за-
тем проконсультироваться с авторитетным лицом проекта. Конечно, не всякая кате-
гория применима в любых обстоятельствах.
Категории тестов, рассматриваемые при разработке тестовых примеров, включа-
ют следующие ситуации.
• Нет данных.
• Повторное выполнение.
• Верные данные.
• Неверные данные.
• Сброс.
• Потери мощности.
• Создание напряжений в системе.
• Тестирование характеристик.
Первые две категории {Нет данных и Повторное выполнение) перечисляются от-
дельно, поскольку в зависимости от приложения они могут представлять как верные,
так и неверные данные. Дальше будет рассмотрен смысл и интерпретация каждой из
этих категорий.
Схемы тестов
57
1
Категория тестов Нет данных
Возможные вопросы:
• Как можно “подвесить” систему?
• Что случится, если не ввести данные?
• Что означает утаивание данных?
• Каково значение или состояние по умолчанию?
В зависимости от типа приложения, утаенные данные могут означать нажатие кла-
виши ENTER на пустом поле, отправку пустого пакета, отправку нулевого указателя
или нулевых данных, ошибку при инициации транзакции или любую другую интер-
претацию отсутствия данных.
Хорошо, что требования определяют ожидаемые результирующие данные. Когда
данные отсутствуют, система может повести себя следующим образом.
• Отправить сообщение об ошибке.
• Установить значение, заданное по умолчанию.
• Повторно использовать предыдущие данные или состояние.
• Напомнить пользователю об отсутствии данных.
• Аннулировать транзакцию.
• Прервать выполнение и ввести сообщение в системный журнал.
Категория тестов Повторное выполнение
Возможные вопросы:
• Что случится, если два раза подряд будут представлены одни и те же данные
или же ввод будет сделан дважды?
• Что случится, если повторить предыдущее действие?
В зависимости от типа приложения дублирование данных может означать повтор-
я эе введение одних и тех же значений, двойное нажатие клавиши ENTER в одной
троке, повторную отправку одного и того же пакета данных, запуск одной и той же
>манды (т.е. любого действия, которое выполняется дважды).
Ожидается, что система может повести себя следующим образом.
• Отправить сообщение об ошибке.
• Перезаписать предыдущее значение или состояние.
• Предложить пользователю подтвердить перезапись предыдущего значения или
состояния.
• Проигнорировать второй случай.
• Обработать второй запрос как отдельное независимое событие.
58
Глава 2
Категория тестов Верные данные
Возможные вопросы:
• Что такое верные экземпляры этих данных?
• Каков диапазон верных значений входных данных?
• Каковы граничные значения данных?
• Каков формат верного пакета?
• Какая информация передается при верной транзакции?
Тестовый пример, построенный на основе верных данных, подтверждает, что
приложение корректно обрабатывает информацию. Значения неверных данных по-
падают в категорию Неверные данные.
Категория тестов Неверные данные
Возможные вопросы:
• Что означает “выход за границы”?
• Каковы будут последствия?
• Что порождает неправильные данные в тестируемом приложении?
Следует определить неверные экземпляры ошибочных данных. Часто категорий
для неправильных данных больше, чем для правильных.
Примеры неверных данных для числовых полей могут быть следующими.
• Значения вне допустимого диапазона.
• Отрицательные числа.
• Десятичные дроби.
• На первой позиции — ноль или пробел.
• Буквенно-цифровые сочетания знаков.
Примеры неверных данных для буквенно-числовых полей:
• На первой позиции — пробел.
• Отличные от буквенно-цифровых знаки.
• Нажатие специфических клавиш (например, комбинация клавиш <CONTROL>
<SHIFT>).
Примеры неверных данных для указателей могут быть следующими.
• Нулевой указатель.
• Неправильный адрес.
• Неинициализированный указатель.
• Верный адрес, указывающий на ненужную информацию в памяти.
Схемы тестов
59
Примерами неверных данных для пакетов данных могут служить:
• Неправильный заголовок.
• Неправильная длина пакета.
• Неправильный формат пакета.
• Неправильное значение циклической контрольной суммы.
Примеры неверных данных для управляемых сигналом входных данных могут
быть следующими.
• Неверная синхронизация спецификаций.
• Блокировка по времени.
• Неправильный сигнал.
• Отсутствие подтверждающего ответа.
• Неправильная контрольная сумма.
• Шум.
При неверных условиях система может вести себя следующим образом.
• Отправить сообщение об ошибке.
• Напомнить пользователю о корректных данных.
• Повторно использовать предыдущее верное значение или состояние.
• Отменить транзакцию.
• Прервать выполнение и внести сообщение в системный журнал.
• Проигнорировать случившееся и попытаться обработать запрос как есть.
Категория тестов Сброс
Возможные вопросы:
• Что случится, если пользователь нажмет клавишу <ESCAPE> или другой тип
клавиши с функцией “стоп”?
• Что случится, если пользователь активизирует последовательность сброса?
• Что произойдет при разрыве на линии связи?
• Что случится, если обработка данных остановится прежде, чем будет выполне-
на задача?
• Что случится, если будет выдернут кабель?
Один из возможных тестов — отсоединить, а затем заново подсоединить кабель и
ценить ответ системы. Некоторые безопасные в критических ситуациях системы
цслжны обеспечивать механизм резервирования, помогающий справиться с подобными
нарушениями, в то время как другие системы могут оказаться выведенными из строя.
Это может оказаться желательным при выведении из строя тестируемой системы;
60
Глава 2
однако нужно иметь возможность перезапустить приложение и привести его в рабо-
чее состояние. Это, в свою очередь, вызывает дополнительные вопросы.
• Какие этапы необходимы для восстановления системы после ее аварийного от-
ключения?
• Останутся ли какие-либо файлы в открытом или закрытом состоянии?
Восстановление системы может принимать различные формы, например:
• перезагрузка системы;
• выдача последовательности для повторного запуска;
• внесение изменений в метку состояния или системную переменную;
• использование средств восстановления;
• повторная инициализация приложения;
• переустановка приложения.
Категория тестов Потери мощности
Возможные вопросы:
• Что случится, если в ходе обработки данных будет отключено питание или
произойдет падение напряжения?
• Что случится, если при запуске или восстановлении последовательности про-
изойдет падение напряжения?
• Какие возможны сбои в аппаратном обеспечении?
Колебания напряжения и аварийные отключения — это реальность. Одни системы
требовательны к качеству подаваемого напряжения, в то время как другие могут до-
пускать его слабые колебания. В некоторые критичные системы встроены блоки ре-
зервного питания. Потери мощности могут быть также результатом сбоев в аппарат-
ной части или ее повреждений. Цель тестирования — определить, насколько хорошо
система справляется с деструктивными действиями.
Можно ожидать, что при потере мощности система поведет себя аналогично тому,
как это происходит на этапе восстановления в категории сброса.
Некоторые тесты, касающиеся потери мощности, могут оказаться перед дилем-
мой, если существует вероятность повреждения оборудования. Такие тесты обсужда-
ются со специалистами по системе и аппаратуре, и в результате проведение тестов,
причиняющих вред аппаратному обеспечению, может быть ими запрещено. Напри-
мер, повреждение в ходе тестирования единственного специального лентопротяжно-
го устройства, осуществляющего высокоскоростную перемотку, может подвергнуть
опасности всю среду тестирования и разработки. Другой подход — оценить потенци-
альный вред, создав прототип аппаратного обеспечения. По какому-то “преднамерен-
ному умыслу” гарантийные обязательства на внутренние компоненты могут быть от-
менены. Проблема не в том, есть ли санкция на проведение тестов с потерей мощности.
Схемы тестов
61
Необходимо изучить этот вопрос, документировать результаты обсуждений и спроек-
тировать тесты, которые будут определять потенциальные проблемы, если при этом
ле наносится вред критичному, дорогостоящему аппаратному обеспечению.
Категория тестов Создание напряжений в системе
Возможные вопросы:
• Что означает для тестируемой системы “слишком много”?
• Как. можно перегрузить систему?
• Что случится, когда другие процессы потребуют совместного использования
одного и того же ресурса?
• Какие существуют ограничения на обработку данных и на ресурсы?
• Можно ли в фоновом режиме запускать одновременно и другие процессы?
Понимание системных ограничений поможет тестерам сформулировать страте-
пи создания напряжений в системе и загрузки тестирования. В главе 9 объясняются
зги типы тестирования. Далее термин создание напряжений будет употребляться в об-
щем смысле.
Создать напряжения в системе можно при помощи следующих методов.
• Уменьшить доступную область памяти или дискового пространства.
• Запустить параллельно несколько экземпляров приложения.
• Создать значительное количество прерываний.
• Сгенерировать условия гонки.
• Очень быстро нажимать клавиши.
• Максимизировать или превысить граничные значения и параметры.
• Сгенерировать множество асинхронных управляемых событиями процессов.
• Сгенерировать максимально возможное количество данных (т.е. максимальное
количество пакетов данных и буферов).
• Выполнить огромное число повторений определенных действий или вводов.
• Отправить большой сложный запрос в систему баз данных.
• Запустить приложение, когда система выполняет резервирование.
Реакция системы, в которой возникло экстремальное напряжение, может быть
следующей.
• Отличия не наблюдаемы.
• Медленный ответ.
• “Подвешенные” задачи.
• Выход системы из строя.
• Состояние взаимоблокировки.
62 Глава 2
Категория Тестирование характеристик
Возможные вопросы:
• Как пользователь обычно взаимодействует с системой?
• Как долго может выполняться задача?
• С какой нагрузкой может справиться система?
Цель оценки характеристик —убедиться, что система может справиться с заданной
нагрузкой и объемом, а также определить, в какой точке такой параметр, как время
ответа системы, ухудшается или становится неадекватным.
Тесты на время позволяют оценить, попадает ли время, затрачиваемое на завер-
шение задачи, в заданные временные рамки. Большинство из этих пределов настоль-
ко малы, что человек может не заметить, что время истекло. Время выполнения зада-
чи могут отслеживать специальные инструменты тестирования. Выходные данные
тестов на время обычно имеют вид электронных таблиц, в которых перечисляется
время выполнения различных функций. Когда время выполнения функции очень ма-
ло, при многократном ее выполнении за один цикл достигается более высокая точ-
ность. Таким образом, отчет о затраченном времени — это отчет о том, сколько вре-
мени ушло на 100 или 1000 итераций выполнения функции.
Очевидно, что представленный список категорий нельзя назвать исчерпываю-
щим, однако перечисленные выше категории применимы к тестированию боль-
шинства приложений. Другие категории тестов (например, практичность, фоновая
работа, безопасность, установка, надежность и удобство обслуживания) для кон-
кретного приложения могут быть как существенными, так и неважными. За допол-
нительной информацией относительно категорий тестов можно обратиться к ра-
ботам [Beizer84] и [Капег99].
Применение категорий тестов
Возвратимся к примеру с контроллером духового шкафа. Следующий этап состоит
в применении этих категорий тестов к итерации схемы № 2. Задача — исследовать по-
ведение системы в каждом непредвиденном состоянии. Цель — спросить “что если?” и
затем определить, получился ли в результате подходящий тест. Если есть сомнения,
нужно добавить условия категории тестов в схему и провести обсуждение этого во-
проса. Не все элементы схемы станут тестовыми примерами. При наличии общих
представлений о контроллере духового шкафа интересными могут оказаться те кате-
гории тестов, которые тестерам кажутся наиболее важными.
Категория тестов Нет данных
Если пользователь не установил температуру приготовления, то из требований из-
вестно, что температура духового шкафа, заданная по умолчанию, равна 350° Ф.
В требованиях утверждается, что пользователь определяет время начала и время
окончания работы шкафа, но дальнейшая информация об этих двух значениях отсут-
ствует. Таким образом, требования неполны.
Вопросы, задаваемые авторитетному лицу проекта, следующие.
Схемы тестов
63
• Как пользователь устанавливает время начала и время окончания работы?
• Что случится, если пользователь не укажет время начала работы, время окон-
чания работы или оба эти значения?
Модификации итерации схемы № 2.
• Добавить структурный нуль для условия “нет данных” для каждого времени на-
чала и времени окончания работы.
• Каждая температура приготовления уже содержит ссылку на запись по умолча-
нию 350е Ф. Это позволяет определить условие “нет данных”, которое приме-
нимо и к температуре приготовления. Ничто не мешает добавить отдельную
компоненту для условия “нет данных”, которое в этой конкретной ситуации из-
быточно, поскольку задано значение по умолчанию. На первый взгляд эти дей-
ствия только загромождают схему, однако с позиции логики важно показать,
что случай “нет данных” был рассмотрен.
Категория тестов Повторное выполнение
Пользователь может ввести температуру приготовления, время начала и время
жончания работы духового шкафа; однако в требованиях не указано, что случится,
если каждый параметр будет введен дважды. Есть ли разница между введением одной
и той же температуры приготовления дважды и заданием двух разных температур?
Применимы ли подобные рассуждения ко времени начала и времени окончания ра-
боты? И снова в требованиях обнаружены “дыры”.
Вопросы, задаваемые авторитетному лицу проекта.
• Как пользователь устанавливает температуру приготовления, время начала и
время окончания работы духового шкафа?
• Что случится, если будет задано две температуры приготовления?
• Можно ли задать вторую температуру во время нагрева духового шкафа?
• Что случится, если будет задано два значения времени начала работы духового
шкафа?
• Что случится, если будет задано два значения времени окончания работы?
• Может ли пользователь ввести время в таком порядке: начало работы/нача-
ло работы/окончание работы/окончание работы и начало работы/начало ра-
боты/ начало работы/окончание работы?
Модификации итерации схемы № 2.
• Добавить структурный нуль для условия “повторный ввод” для каждого элемен-
та, изображающего значение данных, которые в этом примере должны быть
всевозможными ссылками на температуру приготовления, время начала и вре-
мя окончания работы духового шкафа.
64
Глава 2
Категория тестов Верные данные
Из требований известно, что верные данные для температуры приготовления —
это целые значения в диапазоне 200-500° Ф, кратные 5. Однако неясно, включает ли
этот диапазон крайние точки и все ли температуры измеряются по шкале Фаренгейта.
Можно предположить, что после введения верных входных данных духовой шкаф
со временем нагреется до желаемой температуры. В требованиях не указан времен-
ной интервал, за который должна будет достигаться заданная температура. Неизвест-
но также, существует ли минимальное значение времени работы — минимальный ин-
тервал между моментом начала и моментом окончания работы духового шкафа. Что
будет, если время окончания наступит раньше, чем температура духового шкафа дос-
тигнет заданного значения?
Ничего неизвестно и относительно значений времени начала и времени оконча-
ния работы, кроме того факта, что эти данные задает пользователь. В требованиях не
указано, должен ли пользователь задавать эти данные в определенном порядке.
В требованиях утверждается, что пользователь будет задавать команды СТАРТ и
ОТМЕНА без каких-либо пояснений того, как этого можно достичь. Нужно также оп-
ределение пользовательского интерфейса.
В требованиях упоминается о ручном и автоматическом режиме, но не дано ника-
ких чегких определений.
Вопросы, задаваемые авторитетному лицу проекта:
• Действительно ли предполагается, что все значения температур измеряются по
шкале Фаренгейта?
• Включены ли в диапазон граничные значения 200° Ф и 500° Ф? Или же реаль-
ный диапазон 205-495° Ф?
• Каков формат и диапазон времени начала и окончания работы духового шкафа?
• Допускается ли в значениях нуль на первой позиции?
• Что описывают значения время начала работы = Он время окончания работы = О?
Не будет ли это ошибкой?
• Время будет задаваться по часам с 12- или 24-часовой шкалой?
• Будет ли временной параметр включать также день и дату?
• Каков формат команд СТАРТ и ОТМЕНА?
• Существует ли минимальный промежуток между временем начала и временем
окончания работы духового шкафа?
• Как быстро должен нагреваться духовой шкаф, чтобы достичь заданной темпе-
ратуры приготовления?
• Как пользователь сможет определить текущую температуру духового шкафа?
• Можно ли вводить температуру приготовления, время начала и время оконча-
ния работы духового шкафа в произвольном порядке?
• Что означает “ручной” и “автоматический” режим?
Схемы тестов
65
Модификации итерации схемы № 2.
• Добавить структурный нуль для верных данных для каждого элемента, описы-
вающего возможные значения данных, которые в этом примере должны быть
различными ссылками на температуру приготовления, время начала и время
окончания работы духового шкафа.
Категория тестов Неверные данные
Как указано в требованиях, неверные данные для температуры приготовления
включают следующие значения.
• Числа меньше 200.
• Числа больше 500.
• Числа в диапазоне от 200 до 500 не кратные 5.
На данный момент неизвестно, верны ли значения 200 и 500; неясно также, как
контроллер духового шкафа работает с другими типами значений, такими как отрица-
тельные числа, десятичные дроби и другие нечисловые символы.
Формат или диапазон значений времени начала и окончания работы пока тоже
неизвестен. Со временем связаны некоторые неотъемлемые свойства. Очевидно, что
в автоматическом режиме текущее время должно предшествовать времени начала ра-
боты духового шкафа и что, в свою очередь, время начала должно предшествовать
времени окончания. Такие зависимости образуют плодородную почву для создания
новых тестовых примеров.
Вопросы, задаваемые авторитетному лицу проекта:
• Каковы формат и диапазон времени начала и окончания работы духового шкафа?
• Что случится, если текущее время будет больше времени начала работы?
• Может ли текущее время быть до полуночи, а время начала работы после полу-
ночи, так что время начала наступит на следующий день?
• Что случится, если время начала работы духового шкафа будет больше времени
окончания?
• Может ли время начала работы быть до полуночи, а время окончания работы —
после полуночи, так, что время окончания наступит на следующий день?
Модификации итерации схемы № 2.
• Добавить структурный нуль для неверных данных под каждым элементом, опи-
сывающим возможные значения данных, которые в этом примере должны
быть различными ссылками на температуру приготовления, время начала и
время окончания работы духового шкафа.
• Для автоматического режима добавить компоненты, которые будут проверять
взаимоотношения между текущим временем и временем начала работы, а также
между текущим временем и временем окончания работы.
66
Глава 2
• Для автоматического режима добавить компоненты, которые будут отвечать за
то, чтобы время окончания работы вводилось после времени начала работы.
Категория тестов Сброс
Неизвестно, как пользователь будет запускать команды и как система поведет себя
при запуске команды “сброс” (может оказаться, что такой команды вообще не сущест-
вует).
Вопросы, задаваемые авторитетному лицу проекта:
• Как пользователь взаимодействует с духовым шкафом?
• Существует ли процедура “аварийного отключения”?
Модификации итерации схемы № 2.
• Структурный нуль нужно добавить для ввода сброса в обоих режимах, ручном и
автоматическом. Когда на перечисленные выше вопросы будут получены отве-
ты, можно модифицировать следующую версию схемы, отразив в ней новое
понимание того, как пользователь взаимодействует с контроллером духового
шкафа.
Категория тестов Потери мощности
В настоящих требованиях не указано, что случится, если в контроллере духового
шкафа произойдет падение напряжения. В данном примере можно рассмотреть три
состояния:
• падение напряжения в неактивном состоянии;
• падение напряжения в момент введения значений пользователем;
• падение напряжения в процессе нагрева духового шкафа.
Вопросы, задаваемые авторитетному лицу проекта:
• Что случится, если напряжение начнет падать, когда духовой шкаф не работает?
• Что случится, если падение напряжения произойдет в ходе инициализации?
• Что случится, если падение напряжения произойдет тогда, когда пользователь
вводит данные?
• Что случится, если произойдет падение напряжения перед моментом начала
работы, установленным в автоматическом режиме?
• Что произойдет, если падение напряжения произойдет тогда, когда духовой
шкаф будет находиться в режиме нагрева?
• Что произойдет, когда напряжение выровняется? ‘
• Какие шаги, если они вообще существуют, должен предпринять пользователь,
когда напряжение выровняется?
Схемы тестов
67
Модификации итерации схемы № 2.
• Структурный нуль нужно добавить для каждого из двух режимов (ручного и ав-
томатического), а также для элемента потери мощности. Когда на перечислен-
ные выше вопросы будут получены ответы, можно модифицировать схему, от-
разив в ней новое понимание того, как обращаться с напряжением в системе.
Категория тестов Создание напряжений
Контроллер духового шкафа управляет только операциями духового шкафа, тре-
буя наличия некоторых вычислительных ресурсов. Если этот контроллер на правах
совместного использования будет работать и в других приложениях, то понадобят-
ся тесты, которые будут генерировать дополнительный поток данных через шину
санных.
Вопросы, задаваемые авторитетному лицу проекта:
• Будут ли эти операции однопотоковыми?
• Какие еще процессы могут происходить одновременно?
• Может ли пользователь очень быстро ввести данные?
• Какой возможен тип прерываний?
• Каковы ресурсы совместного использования?
• Какие параметры будут подходящими и каковы их предельные значения?
• Каков размер доступной памяти и можно ли его ограничить?
Модификации итерации схемы № 2.
• В качестве структурного нуля для каждого из двух режимов, ручного и автома-
тического, нужно добавить элемент “создание напряжений”. Когда на перечис-
ленные выше вопросы будут получены ответы, можно модифицировать схему,
отразив в ней новое понимание системной архитектуры.
Категория Тестирование характеристик
В случае с контроллером духового шкафа такой аспект, как характеристики, влияет
на время, за которое духовой шкаф отвечает на ввод данных пользователем и указа-
яия относительно нагрева. Здесь нет других функций, для которых можно было бы
использовать измерение времени выполнения.
Вопросы, задаваемые авторитетному лицу проекта:
• Как долго длится обработка введенных пользователем данных?
• Как долго нагревается духовой шкаф и за какой промежуток времени он дости-
гает заданной температуры?
• Есть ли что-нибудь еще, что можно было бы измерить?
• С каким типом ввода может справиться система?
68
Глава 2
Модификации итерации схемы № 2.
• Никакие изменения в схему вноситься не будут. Время ответа — это часть любо-
го тестового примера, так что тестовый пример, вызывающий нагрев духового
шкафа, будет точно определять в виде ожидаемого результата, что духовой
шкаф достиг “х" градусов за время “у”.
2 [Т-3] Автоматический режим
2.1 [Т-4] Температура приготовления
2.1.1 [Т-1] Граничные значения 200-500'Ф
2.1.2 [Т-1]Шаг5'Ф
2.1.3 [Т-5] По умолчанию 350' Ф
21.5 Верше давние
2.2 [Т-6] Время начала работы
2 2.1 Нетдаюыу'псумолчеюта
2.2.2 Повторный юад
2.2.3 Верше данные
2.2.4 Неверные данше
2.2.5 Отооситвлыю текущего времени
2.2.5.1 текущее время < время начала работы
2-2.52 текущее время • время начата работы
, 2J.5.3 текущее > время мчала реботы
2 2.6 Относительно иедениого времена окончания
2 2,6.1 Время начала работы'эпрвделено
госта времени окончания работы
2.2.62 Определяется время мчала работы,
время скончания работы, а затем
нова время начата работы
2.2 [Т-6] Время окончания работы
Рис. 2.9. Часть итерации схемы №3
Цель этой длинной дискуссии заключалась в привлечении внимания к пот енци-
альным проблемам тестирования. Применение этих категорий тестов значительно
увеличивает размеры схемы. На рис. 2.9 показана часть новой схемы, а в приложении
АЗ представлена полная схема. В затемненной части показаны изменения, внесенные
Схемы тестов
69
з предыдущей итерации. На данном этапе имеется множество оставшихся без ответа
зопросов, поэтому тестеры еще не готовы к определению тестов. Опытные тестеры,
вероятнее всего, повторно вернутся к проблеме аналогично тому, как это делается на
третьей итерации в рамках одного совещания по редактированию. Тестеры выбира-
ют степень взаимодействия с разработчиками и то, будут ли проводиться пересмотры
тосле каждой новой итерации схемы.
Вопросы, поставленные тестерами, со всей очевидностью показывают, что отсут-
твует определение пользовательского интерфейса. Авторитетному лицу проекта те-
терь следует обеспечить тестеров спецификацией пользовательского интерфейса.
Имея на руках новые пользовательские требования, тестеры обрабатывают инфор-
. 'ацию, а также определяют новые проблемные места, чтобы указать на них команде
разработчиков.
Дополнительная информация о продукте
Авторитетное лицо проекта отвечает на большинство вопросов, выпуская специ-
фикацию пользовательского интерфейса, которая описывает то, как пользователь
ззаимодействует с контроллером духового шкафа. Эта новая спецификация описыва-
ет то, как духовой шкаф получает входные данные пользователя, и характеризует об-
: атную связь с пользователем.
Панель клавиш контроллера духового шкафа
Пользователь вводит команды через панель, содержащую 15 клавиш, как показано
на рис. 2.10. Десять клавиш — это цифры от 0 до 9. Остальные пять таковы:
1. Клавиша ВВОД отправляет команду на обработку видимых на дисплее данных.
2- Клавиша ВРЕМЯ НАЧАЛА РАБОТЫ сигнализирует о вводе времени начала ра-
боты.
3. Клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ сигнализирует о вводе времени
окончания работы.
4. Клавиша СТАРТ сигнализирует о начале приготовления в ручном или автома-
тическом режиме.
5. Клавиша ОТМЕНА сбрасывает текущую функцию, очищает дисплей от сооб-
щений об ошибке и останавливает работу нагревательного элемента.
Дисплей вывода
Дисплей вывода позволяет вывести 18 буквенно-цифровых знаков. Назовем сле-
дующие форматы вывода данных.
1. Когда пользователь вводит входные данные, прежде чем нажать клавишу
ВВОД, дисплей будет отображать нажатые пользователем клавиши. Время бу-
дет отображаться как “ЧЧ:ММ”, а температура как “NNN”. Температура отсчи-
тывается по шкале Фаренгейта.
2. Если отсчитывающий время таймер активен, то время будет отображаться как
“ЧЧ:ММ:СС”.
70
Глава 2
3. Если отсчитывающий время таймер неактивен, то, когда духовой шкаф будет
находиться в режиме нагрева, на дисплее отобразится слово “ПЕЧЕТСЯ”,
противном случае, когда духовой шкаф .достигнет желаемой температуры, дис-
плей будет пуст.
4. Сообщение об ошибке должно содержать максимум 18 символов. Сообщения
могут быть следующими.
• “ОШИБКА ВРЕМЕНИ” — когда было введено ошибочное значение времени.
• “ОШИБКА ТЕМПЕРАТУРЫ” — когда было введено ошибочное значение
температуры.
Чтобы очистить дисплей от сообщения об ошибке, пользователь должен нажать
Рис. 2.10. Панель клавиш пользовательского интерфейса
Последовательность нажатия клавиш при вводе
Чтобы выбрать температуру приготовления, пользователь должен выполнить сле-
дующую последовательность действий.
1. Ввести значение температуры. Три цифры NNN представляют собой задавае-
мую температуру приготовления, где NNN находится в пределах 200...500
(включительно) и кратно 5. В температуре первой цифрой не может быть ноль.
2- Затем следует нажать кнопку ВВОД. В противном случае ввод будет считаться
неверным.
3. Если значение не введено, то температура по умолчанию будет равна 350° Ф.
Схемы тестов
71
4. Если введено неверное значение, система отобразит на дисплее сообщение об
ошибке - “ОШИБКА ТЕМПЕРАТУРЫ”.
Примечание. Пользователь может задавать температуру только по шкале Фа-
ренгейта. Существующий на данный момент контроллер духового шкафа не
может обрабатывать значения температуры в градусах Цельсия.
Чтобы выбрать время начала работы духового шкафа, пользователь должен вы-
полнить следующую последовательность действий.
1. Нажать клавишу ВРЕМЯ НАЧАЛА РАБОТЫ.
2. Ввести значение времени начала работы в виде четырех цифр, представляю-
щих ЧЧ:ММ, где ЧЧ находится в интервале 00...23, а ММ — в интервале 00...59.
3. Затем нужно нажать клавишу ВВОД. В противном случае ввод будет считаться
неверным.
4. Если введено верное значение, система будет функционировать в автоматиче-
ском режиме.
5. Если значение не было введено, система будет функционировать в ручном ре-
жиме.
Если было введено неверное значение, система отобразит сообщение
“ОШИБКА ВРЕМЕНИ”.
Чтобы выбрать время окончания работы духового шкафа, пользователь должен
выполнить такую последовательность действий.
1. Нажать клавишу ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ.
2. Ввести значение времени окончания работы в виде четырех цифр, представ-
ляющих ЧЧ:ММ, где ЧЧ находится в интервале 00...23, а ММ— в интервале
00...59.
3. Затем следует нажать клавишу ВВОД. В противном случае ввод будет считаться
неверным.
4. Если введено верное значение, система будет функционировать в автоматиче-
ском режиме.
5. Если значение не было введено, система будет функционировать в ручном ре-
жиме.
Если было введено неверное значение, система отобразит сообщение
“ОШИБКА ВРЕМЕНИ”.
Отношение между значениями времени.
1. Оба задаваемые значения времени должны относиться к одному дню. Таким
образом,
текущее время < время начала работы < время окончания работы.
72
Глава 2
2. 00:00 означает полночь, начало дня. Это значение будет верным для текущего
времени, времени начала и неверным для времени окончания.
Условия предварительного нагрева
Духовой шкаф достигает заданной температуры в течение следующих промежут-
ков времени.
200-299° Ф за 4 минуты
300-399° Ф за 5 минут
400-500° Ф за 6 минут
Хотя предоставленная авторитетным лицом проекта информация дает ответы на
многие вопросы тестеров, описание пользовательского интерфейса по-прежнему ос-
тается неполным. Нигде не упоминается о настройке внутренних часов духового
шкафа. Предположим, что внутренние часы в ходе данного цикла тестирования уже
были настроены на реальное время. Эти новые требования вводят также новые функ-
ции. Дисплей вывода предполагает, что таймер отсчета времени отображает время в
формате “ЧЧ:ММ:СС”. Это первое упоминание о таймере отсчета времени, так что
данный вопрос нужно обсудить с авторитетным лицом проекта.
Также остаются неясными концепции ручного и аюпашипичгского режимов. В табл. 2.1
показано, как последовательность ввода задает ручной и автоматический режимы.
Таблица включает следующие три раздела.
• В первом столбце номер строки содержит символ “ф”, обеспечивающий уни-
кальный идентификатор, на который будут делаться ссылки в будущих тесто-
вых примерах.
• Во втором разделе показан ввод пользователя — все восемь возможных комби-
наций значений, которые могут быть введены пользователем. В этой таблице
подчеркивается, какие входные значения будут задаваться тестом; тут нет под-
робного описания последовательности клавиш, которые нужно нажать, чтобы
ввести данные. Например, в строке фЗ представлено состояние, в котором
пользователь задает время окончания, но не задает время начала работы или
температуру приготовления.
• В третьем разделе контроллер духового шкафа, обрабатывая данные, докумен-
тирует ожидаемое поведение духового шкафа. Снова взглянем на строку фЗ:
начало работы происходит в ручном режиме и нагрев духового шкафа начина-
ется, как только пользователь нажимает клавишу ВВОД. Духовой шкаф отклю-
чается автоматически в заданный момент времени. Температура духового шка-
фа задается по умолчанию. На дисплее производится отсчет прошедшего вре-
мени, которое является разницей между значением времени окончания работы
духового шкафа и значением времени, когда пользователь ввел команды. В дру-
гих обстоятельствах, например в строке ф5, если пользователь пропускает вре-
мя начала работы, духовой шкаф будет продолжать нагреваться до тех пор, по-
ка пользователь не нажмет клавишу' ОТМЕНА.
Таблица 2.1. Описание ручного/автоматического режима
ВВОД ПОЛЬЗОВАТЕЛЯ ОБРАБОТКА ДАННЫХ КОНТРОЛЛЕРОМ ДУХОВОГО ШКАФА
Номер строки Время начала работы Время окончания работы Темпе- ратура приготов ления Режим начала Время начала на- грева духо- вого шкафа Режим ОКОН-" W ча ния Время выключения духового шкафа Температура приготовления Сообщение на дисплее
ф1 нет данных нет данных нет данных ручной начать сейчас ручной кнопка ОТМЕНА по умолчанию 350° Ф "ПЕЧЕТСЯ"
ф2 нет данных нет данных верное значение ручной начать сейчас ручной кнопка ОТМЕНА заданное значение "ПЕЧЕТСЯ"
фЗ нет данных верное значение нет данных ручной начать сейчас автомати- ческий значение времени окончания по умолчанию 350° Ф таймер отсчета времени
ф4 нет данных верное значение верное значение ручной начать сейчас автомати ческий значение времени окончания заданное значение таймер отсчета времени
ф5 верное значение нет данных нет данных автомати- ческий значение времени на- чала ручной кнопка ОТМЕНА по умолчанию 350° Ф "ПЕЧЕТСЯ"
фб верное значение нет данных верное значение автомати- ческий значение времени на- чала ручной кнопка ОТМЕНА заданное значение "ПЕЧЕТСЯ"
ф7 верное значение верное значение нет данных автомати- ческий значение времени на- чала автомати- ческий значение времени окончания по умолчанию 350° Ф таймер отсчета времени
ф8 верное значение верное значение верное значение автомати- ческий значение времени на- чала автомати- ческий значение времени окончания заданное значение таймер отсчета времени
74 Глава 2
Из табл. 2.1 видно, что задание времени начала работы создает условия автомати-
ческого начала, тогда как задание времени окончания работы инициирует режим ав-
томатического окончания работы. Автоматический и ручной режимы применяются
не только в данном случае, но и при любых других условиях начала и конца работы
духового шкафа.
Как утверждалось выше, не существует идеальных требований и проекту' пользова-
тельского интерфейса недостает завершенности. Тестеры, проектирующие тесты пе-
ред началом разработки программного обеспечения, поддерживают важную для ко-
манды разработчиков обратную связь. Именно поэтому тесное сотрудничество тесте-
ров с разработчиками в самом начале проекта улучшает определение самого продукта.
Однако когда требования и пользовательский интерфейс находятся в плохом состоя-
нии, тестеры должны быть готовы к тому, что обнаружится много проблем.
Последняя итерация
Спецификация пользовательского интерфейса и описание ручного/автоматичес-
кого режима в табл. 2.1 дает ответы на многие вопросы тестеров. Теперь можно за-
полнить брешь в категориях тестов, связанных с контроллером духового шкафа, и
перейти к схеме. Чтобы скорее завершить этот пример, предположим, что с помощью
авторитетного лица проекта тестеры разобрались с неясными требованиями, получив,
перечисленные ниже сведения. При работе над реальными проектами нужно связать-
ся с авторитетным лицом проекта и обсудить любые требования, которые были со-
чтены неадекватными или недопустимыми.
Категория тестов Нет данных
• Если пользователь пропустил при вводе время начала или время окончания ра-
боты, то вступает в силу протокол ручного режима. Духовой шкаф начинает на-
греваться, как только пользователь введет верные входные данные. Духовой
шкаф прекратит нагреваться после нажатия кнопки ОТМЕНА
Категория тестов Повторное выполнение
• Если духовой шкаф не работает, любые элементы данных, введенные дважды,
переписывают предыдущее значение.
• Если духовой шкаф находится в режиме нагрева:
• введение другого значения температуры приготовления заменяет ее
текущее значение и духовой шкаф перестраивается соответствующим
образом. Контроллер духового шкафа игнорирует неверную температуру;
• клавиша ОТМЕНА выключает духовой шкаф и возвращает его в неактивное
состояние;
• все остальные команды игнорируются.
Категория тестов Верные данные
• Граничные значения темпера туры 200° Ф и 500° Ф являются верными.
Схемы тестов
75
• Верные значения температуры задаются по часам с 24-х часовой шкалой.
• Минуты меньше 10 должны начинаться с нуля.
• Текущее значение и время начала работы могут принимать значение 00:00, ко-
торое соответствует полуночи.
• В этом примере нет способа задавать дату.
• Духовой шкаф, ожидая начала нагрева в автоматическом режиме, остается в
неактивном состоянии, пока не наступит заданное пользователем время начала
работы. Затем духовой шкаф будет включен и, соответственно, начнется на-
грев.
• Хотя духовой шкаф не отображает текущей температуры, он показывает слово
“ПЕЧЕТСЯ”, чтобы указать, что духовой шкаф находится в режиме нагрева.
Тестерам нужно предоставить вспомогательный термометр, чтобы проследить
за температурой духового шкафа. Даже если бы духовой шкаф выдавал текущую
температуру, специалистам по тестированию все же нужно было бы убедиться в
точности отображаемой информации.
I
Категория тестов Неверные данные
• Неверными данными для времени начала и времени окончания работы будут:
• деление часов больше чем на 24;
• час, задаваемый одной цифрой, введенный без предшествующего нуля;
• поминутное деление больше чем на 59;
• Время 00:00 — это неверное время окончания работы.
• В автоматическом режиме значение времени должно удовлетворять следующе-
му соотношению:
• текущее время < время начала работы < время окончания работы.
В противном случае духовой шкаф не станет ни нагреваться, ни отправля ть со-
общение об ошибке.
• Числа, после которых не следует нажатие клавиши ВВОД, считаются неверными.
• Исходя из текущего пользовательского интерфейса невозможно ввести отри-
цательные значения или нечисловые символы.
Категория тестов Сброс
• Пользователь отменяет выполнение задачи, нажав клавишу ОТМЕНА.
• В ходе введения данных нажатие клавиши ОТМЕНА приведет к тому, что кон-
троллер вернется в неактивное состояние.
• В ходе нагревания нажатие клавиши ОТМЕНА выключит нагревательный эле-
мент и вернет контроллер в неактивное состояние.
76 Глава 2
Категория тестов Потери мощности
• Если в духовом шкафу произойдет падение напряжения, нагревательный эле
мент прекратит нагрев. Когда напряжение восстановится, духовой шкаф вер-
нется в неактивное состояние.
Категория тестов Создание напряжений
• В этой системе имеется один процессор, управляющий одним приложением,
так что предполагается, что нет никаких дополнительных операций с данными
или дополнительного потока данных в шине.
• Предполагается, что система не использует распределения памяти, внутренних
прерываний, системных параметров или других задач, влияющих на характе-
ристики.
• Предполагается, что пользователь относительно редко при вводе нажимает
клавиши и, следовательно, не может обеспечивать слишком высокую скорость
ввода данных.
• Предполагается, что чрезмерно частое использование духового шкафа или экс-
тремальные значения температуры — это механические проблемы, которые не
контролируются программным обеспечением духового шкафа. Если возникнет
необходимость проверить нагревательные элементы в течение длительного
периода, то для этого будет определен специальный тест.
Категория Тестирование характеристик
• Время предварительного нагрева задается в пользовательской спецификации
В каждом тестовом примере, в котором предписывается включение нагрева-
тельного элемента, будет устанавливаться приемлемое время предварительного
нагрева.
Информация о пользовательском интерфейсе и поведении системы приводит в
результате к дополнительным изменениям в схеме. В самой схеме также перемещают-
ся некоторые элементы, средство автоматизации составления схемы автоматически
перенумеровывает элементы в списке. В приложении А4 содержится схема на итера-
ции № 4, часть которой показана рис. 2.11 - Затененная часть показывает внесенные в
схему изменения. Основные изменения описаны ниже.
1. Скомбинированы элементы [Т-1] Граничные значения 200~500°Ф и [Т-1] Шаг
5° Ф. Поскольку прирост температуры равен 5° Ф, рассматриваемыми гранич-
ными значениями min ± 1, max ± 1 будут min ± 5 и max ±5.
2. После элемента верные данные было добавлено несколько примеров верных
температур.
3. После элемента повторный ввод и для других командных клавиш было введено
разграничение между такими режимами духового шкафа, как неактивный ре-
жим и режим нагрева, поскольку правила обработки повторно введенных дан-
- ных могут отличаться в зависимости от состояния духового шкафа.
Схемы тестов
77
2
[Т-3] Автоматический режим
2.1 [Т-4] Температура приготовления
2.1.2 [Т-5] По умолчанию 350’ Ф
2.1.3 Повторный ввод
2.1.4 Верные данные
2.1.5 Неверные данные
Рис. 2.11. Часть итерации схемы №4
78
Глава 2
По словам авторитетного лица проекта, духовой шкаф, ожидающий ввод
пользователя, и духовой шкаф, ожидающий автоматического включения, в дей-
ствительности находятся в неактивном режиме, поэтому был введен элемент
“неактивный духовой шкаф”. Однако в действительности это указывает на це-
лую новую категорию условий теста. Как система будет отвечать на другие ко-
манды, когда духовой шкаф будет в режиме “ожидание начала нагрева”? На по-
верхность всплывает еще один набор непонятных требований. Могла бы рест-
руктуризация схемы совершенно иным способом проиллюстрировать функ-
циональные возможности приложения (подробнее об этом см. раздел 2.4)?
На данный момент приходится продолжать работать с уже существующей схе-
мой, отметив, что требования отражены неточно.
4. Под элементом неверные данные было дано определение нескольким неверным
значениям. Сюда входят ноль, отрицательные значения, буквенные символы и
другие неверные варианты.
Поскольку уже известно, что обычной клавиатуры не будет, то не будет и воз-
можности ввести отрицательные значения или буквенные символы, поэтому'
тестеры могут попытаться исключить эти элементы из схемы. Однако рекомен-
дуется все же сохранить их, на случай, если в будущем выпуске продукт под-
вергнется значительным изменениям в пользовательском интерфейсе, в ре-
зультате чего пользователь сможет вводить отрицательные значения. Нужно
помнить, что будущие усовершенствования могут сделать возможной ситуацию,
“неосуществимую” в данный момент. Именно поэтому следует оставлять внепи
не избыточные тестовые примеры. Для полноты документации необходимо
добавить отметку о дате и записать утверждение о том, что результирующие
данные неизвестны или что этот тест на данный момент неприменим.
5. Под элементом нет данных/no умолчанию для времени начала и времени окон-
чания работы духового шкафа введено различие между состояниями (когда
число не было задано или было задано неверное значение).
Из описания пользовательского интерфейса известно, что введение времени
начала работы требует нажатия функциональной клавиши времени начала ра-
боты с последующим вводом набора цифр и нажатием клавиши ВВОД. Таким
образом, в элементе схемы под номером 2.2.1 рассматривается, что случится,
когда в этой последовательности будет отсутствовать гакой элемент, как число.
Существует две категории тестов. Элемент схемы под номером 2.2.1.1 вызывает
те, в которых используется нажатие клавиши ВРЕМЯ НАЧАЛА РАБОТЫ, после
чего следует нажатие нечисловой клавиши. Данная последовательность нажа-
тия клавиш пропускает такой элемент, как время начала работы, воспринимая
это как условие, заданное по умолчанию. Элемент схемы под номером 2.2.1.2 в
первую очередь вызывается для чисел, за которыми следует нажатие клавиши,
отличной от клавиши ВВОД, что приводит к неверному вводу времени. Анало-
гичные изменения встречаются в элементе 2.3.1. Вставка пояснений в схему
проясняет ситуацию и документирует цели тестов.
6. Здесь не будут задаваться тесты из категорий сброса, потери мощности и созда-
ния напряжений, чтобы сосредоточиться на нажатии клавиш пользователем.
Схемы Тестов
79
Кнопка ОТМЕНА, которая используется для сброса пользователем последова-
тельности команд, в схеме все же появляется и, следовательно, уже переадре-
сована как условие теста. Поэтому эти неиспользуемые метки будут удалены из
схемы, чтобы избежать неразберихи. Некоторые тестеры захотят сохранить их
в качестве структурного нуля для будущих ссылок.
*
Поскольку исходные требования критичны, то большинство элементов, добавлен-
ных в список, основываются на категориях тестов и интуиции тестеров. Если бы были
предоставлены полные требования, то для каждого элемента в схеме можно было бы
выяснить то специфическое требование, результатом которого он стал. В этой ситуа-
ции можно пометить каждый элемент в схеме идентификатором требований. Неко-
торые промышленные стандарты требуют наличия возможности связать определение
продукта с тем, что тестировалось. В главе 10 рассматриваются проблемы согласова-’
ния с такими стандартами.
По желанию тестеры могут также показать ожидаемые результаты как часть схе-
мы. На рис. 2.12 отображены возможные варианты модификации схемы, позволяю-
щие документировать ожидаемые результаты для тестирования граничных значений
"температуры.
1 [Т-3] Ручной режим
1.1 [Т-4] Температура приготовления
1.1.1 [Т-1] граничные значения 200-500' Ф/Шаг 5' Ф
1.1.1.1 ошибкапри195'
1.1.1.2 ошибка при 199'
1.1.1.3 нагрев при 200*
1.1.1.4 ошибка при 201'
1.1.1.5 нагрев при 205'
Рис. 2.12. Формулировка ожидаемых результатов
Оценка схемы
Многим читателям схема для контроллера духового шкафа может показаться неор-
~анизованной, чего и можно было ожидать в ситуации, когда информация о продукте
поступает постепенно. Плохие требования порождают плохой проект, а схема это от-
ражает. Возможно, схема выглядела бы лучше, если бы в начале проекта имелось
больше информации о продукте. При сравнении этой схемы с той, которая рассмат-
ривается в главе 6, кажется, что последней следовать легче, поскольку возможности
П зльзователя более ограничены и лучше определены.
Значение имеют любые методы, которые помогут тестерам понять приложение и
задать разумные вопросы. Реальная работа по созданию схемы очень важна благодаря
"ем знаниям, которые приобретаются в ходе этого процесса. Когда схема становится
80
Глава 2
слишком беспорядочной или когда расширение схемы с целью включения дополни-
тельных требований становится слишком сложным, можно принять несколько вари-
антов поведения.
Вариант 1: новая схема
Нужно воспользоваться тем, что уже известно о приложении и реструктуризиро-
вать схему соответствующим образом. В примере с контроллером духового шкафа в
новой схеме были бы свои преимущества, если бы высокоуровневые элементы схемы
ориентировались на следующие четыре функции:
• нерабочее состояние (ручной режим) — ожидание ввода пользователем;
• нерабочее состояние (автоматический режим) — ожидание автоматического
старта духового шкафа, когда наступит выбранное время начала работы;
• нагрев (ручной режим) — нагрев продолжается до тех пор, пока пользователь
не вызовет отмену;
• нагрев (автоматический режим) — нагрев продолжается до тех пор, пока духо-
вой шкаф не выключится в момент наступления выбранного времени оконча-
ния работы.
Исходные требования не определяют должным образом ручной и автоматический
режимы. Хотя авторитетное лицо проекта и утверждает, что два названных нерабо-
чих состояния одинаковы, в плане обработки введенных пользователем данных они
отличаются достаточно сильно, чтобы возникла необходимость в отдельных тестах.
Вариант 2: отдельные схемы
Для больших проектов использование отдельных схем для каждой функции может
помочь сгруппировать взаимосвязанную информацию. Иначе число уровней, воз-
никших в результате последующих дополнений, легко доведет до отчаяния тех, кто
попытается понять схему.
Вариант 3: таблица
В таблицах часто содержится та же информация, что и в схемах, но представляет-
ся она в ином формате. Когда отдельные блоки информации неоднократно появля-
ются в схеме, что типично для управляемых в режиме меню приложений, использо-
вание таблиц поможет улучшить организацию тестов. В главах 4 и 5 представлено
множество примеров таблиц.
Вариант 4; прецеденты
Прецеденты позволяют классифицировать информацию, касающуюся действий
пользователя от начала до конца. Возможный пример для контроллера духового шка-
фа: повару необходимо запрограммировать духовой шкаф на определенный способ
выпечки торта. Тестер перечисляет необходимые шаги и может затем указать вариан-
ты неудачных действий. Примером таких действий может служить введение непра-
вильного времени или неверной температуры. В главе 6 представлены примеры пре-
цедентов.
Схемы тестов
81
Вариант 5: та же схема в ее текущем виде
На последней итерации схема все таки содержит информацию, которая задает хо-
рэшие, хотя и неполные, условия для тестов. Опытные тестеры знают, что по ходу
тестирования будет возникать необходимость в дополнительных тестах. Таким обра-
э М, неполная схема — это не помеха. Иногда тестеры могут не знать, какой информа-
ции о продукте не хватает. В главе 3 для создания тестовых примеров используется
последняя итерация схемы.
За исключением случаев моделирования очень простых приложений, схемы редко
с щсывают всеохватывающий список условий для тестов. Даже при использовании
других методов проектирования тестов, у тестеров редко бывают все тестовые при-
меры, определяющие приоритеты в выполнении тестов. По мере того как тестер уз-
нает больше о приложении, он часто определяет новые тесты, основываясь на ин-
формации, полученной из последних тестов. Идея такого рода, как “а если я попро-
бую ввести это...” служит основой для исследовательского тестирования (введенного в
главе 1). Когда дополнительные тесты становятся очевидностью, тестер может со-
хранить таблицу контрольных проверок этих новых условий тестов, или же добавить
жх непосредственно в набор тестовых примеров. Чаще всего нет необходимости в по-
вторной корректировке схемы, содержащей новое условие теста, если только это ус-
' >вие не является исключительным способом создания соответствий между требова-
ниями и тестовыми примерами. Однако тесты, созданные на лету, обычно используют
'~эебования, которые плохо документированы.
Оценка календарного плана
Теперь сделаем короткую передышку в создании схемы и обратимся к проблеме,
касающейся менеджмента: сколько времени нужно отвести на тестирование. Еще до
того, как будут созданы тестовые примеры, можно сделать соответствующие оценки
хтя числа потенциальных тестовых примеров.
В качестве грубого правила можно принять то, что каждый лист в схеме преобра-
зуется, по крайней мере, в один тестовый пример. Некоторые листья могут привести
и нескольким тестовым примерам. Следовательно, один из вариантов оценки состоит
_ пересчете числа листьев или полного числа строк в схеме. В последней итерации
схемы в приложении А4 содержится 135 строк, 44 из которых являются точками ветв-
ления, а оставшаяся 91 строка — листьями. Таким образом, исходная оценка в 91 или
135 тестовый пример — это довольно существенное предположение. Поскольку неко-
торые из листьев приводят в результате к нескольким тестовым примерам, 91 — это
шнимальное число тестовых примеров, которого можно было бы ожидать. В кален-
дарном плане часто бывают недооценки и новые тестовые примеры создаются уже в
ходе тестирования. Следовательно, 135 — это неплохая оценка числа тестовых при-
зеров.
В дополнение к оценке числа тестовых примеров календарный план должен также
И редусматривать другие задачи, связанные с работой над тестами, например:
• настройка и конфигурирование системы для проведения тестов;
• создание и установка специальных средств тестирования;
82
Глава 2
• обучение использованию средств тестирования;
• заказ средств тестирования;
• программирование тестовых примеров в виде сценариев или в виде файлов с
данными;
• выполнение отдельных тестовых примеров;
• повторный запуск неудачных тестовых примеров;
• создание отчетов о тестировании и других документов.
Даже если в организации существует лишь совершенно пустая среда тестирования,
тестер должен уделить время настройке механизма тестирования. Тестовый пример
требует определенного количества времени для установки и выполнения. Поскольку
тестовые примеры в случае с духовым шкафом оказывались достаточно ограничен-
ными в плане содержания, можно сказать, что рассчитывать нужно на пятнадцать ми-
нут для каждого тестового примера. Это означает настройку и выполнение четырех
тестовых примеров в час. Таким образом, для выполнения 135 тестовых примеров
понадобится приблизительно 34 часа.
Как это часто бывает, некоторые тесты проваливаются. Разработчики устраняют
ошибки и выпускают новые, обновленные версии программного обеспечения. Тесте
ры должны повторно выполнить неудавшиеся тесты, чтобы подтвердить, что ошибки
были устранены. В идеале, повторно нужно выполнять даже тесты, которые изна-
чально были пройдены, чтобы убедиться, что модифицированное программное обес-
печение не изменило тех функций, которые раньше работали. Если в этом деле нет
предварительного опыта, можно отбросить цифры и сказать, что на повторное про-
ведение неудачных тестов уйдет дополнительно 50% выделенного на первоначальное
прохождение тестов времени. Таким образом, если на выполнение тестовых приме-
ров первый раз выделено 34 часа, то можно предположить, что приблизительно 17
часов уйдет на проверку устраненных ошибок.
В табл. 2.2 показан пример элемента календарного плана для работы над тестами.
Приведенные величины — исходная оценка; они будуг уточняться по мере осуществ-
ления проекта.
Один из аспектов планирования проекта заключается в том, что наверняка неиз-
вестно, насколько точно оценено тестирование до тех пор, пока задачи не будут за-
вершены. В конце проекта, сравнивая реальную и предполагаемую работу над задача-
ми, можно получить информацию, которая будет использоваться в последующих про-
ектах. Например, если исходные оценки были ниже реальных на 35%, то в следующем
проекте нужно добавить 35% к общей оценке в надежде на то, что будет создан более
точный календарный план. Только собрав такую информацию в течение нескольких
проектов, можно будет составлять более точные календарные планы.
В приложении А5, которое объясняется в главе 3, содержится 81 тестовый при-
мер, управляемый схемой. Это значительно меньше, чем исходная оценка в 135 тес-
товых примеров. Однако не каждый элемент схемы дал в результате тестовый при-
мер, в то время как несколько других элементов схемы указывали на один и тот же
тестовый пример. В ходе выполнения теста тестер, вероятнее всего, составит допол-
нительные тесты, в особенности тогда, когда в схеме обнаруживается отсутствие
Схемы тестов
83
какой-либо информации, касающейся приложения. Поэтому можно предположить,
-то по завершению тестирования суммарное количество тестовых примеров будет
ближе к оценочному значению 135, или даже превысит его.
аблица 2.2. Оценка календарного плана для задачи тестирования
где1 Описание /Приблизительное время работы
Спроектировать и создать тестовую программу, связанную с контроллером духового шкафа 40 часов
Сконфигурировать тестовую систему 10 часов
з Составить и выполнить каждый тестовый пример (135 тестовых примеров, приблизительно по 15 минут на каждый тестовый пример) 34 часа
а Проверить исправленные ошибки для провалившихся тестовых примеров (50% времени от указанного в задаче №3) 17 часов
- Написать резюмирующий отчет о тестировании 4 часа
Предполагаемое общее время 105 часов
Перед созданием тестовых примеров можно приблизительно рассчитать только
ззможное их число. Таким образом, из исходных оценок можно узнать лишь при-
' тизительный размер схемы.
Резюме
Несмотря на неполноту требований, начать разработку тестов все-таки можно.
Первый этап заключается в перечислении каждого требования в отдельности, а затем
с тределении того, какие из этих требований являются описаниями входных данных,
«кидаемыми результатами и проектными ограничениями.
Схематичный подход к тестированию предоставляет средства, с помощью кото-
рых можно организовать требования. Это важный инструмент для обсуждения требо-
ваний к приложению с авторитетным лицом проекта. По мере разработки схемы об-
аруживаются недостающие или неоднозначные требования. Создание следующих
туаций помогает определить условия для дополнительных тестов.
• Отсутствуют данные и не обеспечено тестирование по умолчанию.
• Повторное введение данных.
• Верные и неверные данные.
• Сброс или потери мощности в ходе обработки данных.
• Создание напряжений в системе.
• Проблемы с характеристиками.
84 Глава 2
С помощью схемы создается набор условий теста, которые очевидно станут осно-
вой тестового примера.
Число элементов в схеме указывает на число тестовых примеров, которые можно
будет составить. Эта информация полезна при оценке календарного плана проведе-
ния тестирования.
ГЛАВА
3
От схемы тестов
к тестовым примерам
Введение
В главе 2 во время изучения информации о контроллере духового шкафа была раз-
~ аботана схема тестов. По мере накопления данных о приложении возникало множе-
тво различных вопросов. Теперь нужно преобразовать схему тестов в тестовые при-
еры, которые потом можно будет выполнить.
Тестовый пример состоит из идентификатора тестового примера (ID), описания
годных данных и определения ожидаемых результатов. Кроме того, в тестовом при-
ере имеется указатель на соответствующий источник информации, чтобы можно
' яло сохранить связь между документами тестов. В ходе выполнения тестового при-
ера тестеры записывают такую информацию, как реальные результаты, факт прохо-
ждения теста и номер версии программного или аппаратного обеспечения, исполь-
емого для тестирования. Но прежде всего, начнем с определения тестовых примеров.
Создание тестовых примеров
Последняя версия схемы (см. приложение А4) помогает сформулировать тестовые
примеры. Каждый путь в схеме (от корня к листьям) определяет входную комбина-
цию, которая образует основу для тестового примера, и тогда можно решить, стоит ли
задавать тест, используя эту конкретную комбинацию. Когда уже решено, какие пути
схеме станут тестовыми примерами, следующим этапом будет определение четко
_сраженных входных состояний и связанных с ними ожидаемых результатов. Пол-
ный набор тестов состоит из одного или нескольких тестовых примеров для каждого
иста в схеме. Таблица тестовых примеров, как показано в приложении А5, содержит
.^формацию об этих примерах. Для краткости в табл. 3.1 показано несколько таких
"естовых примеров. В таблице содержится следующая информация.
86
Глава 3
ID тестового примера Уникальный идентификационный номер тестового при- мера. Чтобы не усложнять описание, была выбрана схема маркировки Т-номер.
Элемент схемы тестов Элемент в схеме тестов, на основе которого был сделан тестовый пример.
Предыдущее состояние Здесь указывается, должен ли духовой шкаф иметь опреде- ленную конфигурацию для выполнения теста. Такими предварительными условиями могут быть: • неактивное состояние; • успешное прохождение другого теста; • определенные требования к часам системы (текущее время); • специфическое аппаратное обеспечение, используемое для тестирования.
Входные данные Последовательность входных данных, которая вводится тестером. Каждое числовое значение, нажатие клавиш или действия, выполняемые вручную, перечисляются в отдель- ных строках.
Ожидаемые результаты Реальные результаты Поведение системы, которое тестер ожидает увидеть. Место, куда тестер будет записывать неожиданные резуль- таты, или где он будет делать отметку о том, что тест был пройден.
Таблица 3.1. Определенный набор тестовых примеров,
полученных на основе схемы тестов (полный перечень показан в приложении А5)
ID тестового примера Схема теста Предыдущее состояние Входные данные Ожидаемые результаты Реальные результаты
Т-1 1 1.1.1 (неактивное 199 Дисплей ОШИБКА
состояние) клавиша ТЕМПЕРАТУРЫ
ВВОД
Т-2 1.1.1.1 (неактивное 200 Духовой шкаф включа-
состояние) клавиша ВВОД ется и нагревается до 200° за 4 минуты.
клавиша СТАРТ Температура держится в диапазоне 198°-202°.
Во время нагрева на
дисплее ПЕЧЕТСЯ
От схемы тестов к тестовым примерам 87
П одолжение табл. 3.1
□ -естового примера Схема теста Предыдущее состояние . Входные : данные Ожидаемые • ^результаты Реальные результаты
’-3 1.1.1.2 (неактивное состояние) 201 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
"-11 1.1.2 (неактивное клавиша Духовой шкаф включа-
1.2.1.1 2.4.1.1 состояние) СТАРТ ется и нагревается до температуры 350° за 5 минут.
Температура держится
в диапазоне 348-352°.
При нагреве
на дисплее: ПЕЧЕТСЯ
7-22 1.3.1.2 запуск Т-2 20 секунд Духовой шкаф после начала перестает нагреваться нагрева в Т-2 и выключается. нажать Дисплей: спусгс» клавишу ОТМЕНА
"35 2.1,2 (неактивное состояние) текущее время должно быть не раньше 14:05 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1405 Когда наступает время 14:05, духовой шкаф включается и нагрева- ется до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
клавиша
ВВОД клавиша
СТАРТ
88
Глава 3
Окончание табл. 3.1
ю тестового примера Схема теста Предыдущее состояние Входные данные Ожидаемые результаты Реальные результаты
Т-36 2.13.1. 2.2.5.1 (неактивное состояние) текущее время -11:20 310 клавиша ВВОД клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1130 клавиша ВВОД 455 клавиша ВВОД клавиша СТАРТ Когда наступает время 11:30, духовой шкаф включается и нагрева- ется до 455° за 6 минут. Температура держится в диапазоне 453°-457°. Во время нагрева на дисплее' ПЕЧЕТСЯ
Каждый тестовый пример независим и начинается с исходного состояния, в кото-
ром духовой шкаф неактивен. Следовательно, эти тесты нельзя запускать последова-
тельно без предварительного возврата к исходному состоянию. Тесты, которые за-
висят от успешного выполнения других тестов, помечаются специальным образом.
На данный момент основная цель заключается в определении тестовых примеров, так
что теперь каждый тестовый пример будет начинаться с исходного состояния.
Первый тестовый пример в табл. 8.1 и в приложении А5 помечен Т-1. Этот тесто-
вый пример получен из строки 1.1.1.1 в схеме тестов, он также соответствует части
схемы, показанной ниже.
1 [R-3] Ручной режим
1.1 [R-4]
1.1.1
Температура приготовления
[R-1] Граничные значения
200-500° Ф. Шаг 5° Ф
1.1.1.1 199/200/201
В этом тестовом примере указывается, что нужно установить такую температуру
приготовления в ручном режиме, чтобы выполнялось условие на нижней границе.
От схемы тестов к тестовым примерам 89
стоящее из значения нижней границы температуры, температуры на один градус
гше и на один градус ниже. В этом первом тестовом примере входное значение
-емпературы равно 199° Ф, что является ошибкой, которую можно было ожидать по
^скольким причинам. Во-первых, верны лишь те значения, которые кратны 5, а
лачсние 199°Ф не удовлетворяет такому критерию. Во-вторых, наименьшее верное
1 тачение температурного диапазона равно 200° Ф, и снова значение 199° Ф не удов-
ггворяет этому критерию. Данный тест не зависит от какого-либо предыдущего со-
тояния и поэтому исходная среда тестирования духового шкафа должна соответст-
>вать его неактивному состоянию.
В следующем тестовом примере, Т-2, также используется путь 1.1.1.1. Теперь в тес-
~е предполагается использование официального нижнего граничного значения, рав-
зого 200° Ф. Это также одно из значений, заданных в элементе схемы 1.1.1.2. Ожи-
даемые результаты состоят из трех пунктов.
1. Духовой шкаф нагревается до желаемой температуры за определенный проме-
жуток времени, который, согласно документации духового шкафа, равен четы-
рем минутам.
2. В исходных требованиях указано, что контроллер духового шкафа поддержива-
ет заданную температуру в диапазоне ±2° Ф.
3. В спецификации пользовательского интерфейса говорится, что слово
ПЕЧЕТСЯ в поле дисплея отображается только тогда, когда включен нагрева-
тельный элемент. В противном случае дисплей пуст.
Тестовый пример Т-3 получается аналогично примеру Т-1 за исключением того,
что входное значение для теста будет “min +1”, что равно 201° Ф.
Другой тестовый пример, Т-11, создает интересную ситуацию, так как в трех путях
_хемы тестов отражен именно данный тестовый пример. Этот путь показывает эле-
1ент схемы, обозначенный как 1.1.2.
[R-3] Ручной режим
1.1 [R-4] Температура приготовления
1.1.1 [R-1] Граничные значения
200-500° Ф/Шаг 5° Ф
По умолчанию 350* Ф
Интерпретация этого фрагмента схемы указывает на то, что температура приго-
г звления задается в ручном режиме; однако не было введено никаких чисел, поэтому
появился элемент по умолчанию. Поскольку это верная входная последовательность,
луковой шкаф нагревается до температуры 350° Ф. Сообразительные читатели отме-
тли тот факт, что если пользователь не установил необходимую температуру, задается
90
Глава 3
температура по умолчанию, равная 350° Ф; если же задаются значения температуры,
выходящие за допустимые пределы, в результате отображается сообщение об ошибке
Это как раз тот пример, когда уточнение схемы порождает выяснение требований.
Элемент схемы 1.2.1.1 — это второй путь, приводящий к тестовому примеру Т-11, и
этот путь имеет следующий вид.
1 [R-3] 1.1 Ручной режим [R-4] Температура приготовления
1.2 [R-8] Команда СТАРТ
1.2.1 Нет данных /по умолчанию
Нагрев в ручном режиме попадает и в эту часть схемы. Пользовательский интер-
фейс требует, чтобы клавиша СТАРТ следовала за элементом температура приготовле-
ния^ в элементе строки 1.2.1 утверждается, что для клавиши СТАРТ не было введено
никаких значений, а элемент строки 1.2.1.1 указывает, что духовой шкаф не работает.
В требованиях к духовому шкафу утверждается, что если не введена температура при-
готовления (это происходит, когда с нажатием клавиши СТАРТ не связано какое-либо
значение), то устанавливается температура по умолчанию, равная 350° Ф.
Элемент схемы 2.4.1.1 — третий путь, приводящий к тем же условиям теста в при-
мере Т-11. Этот путь вызывает запуск команды начала работы без заданных данных,
когда духовой шкаф находится в неактивном состоянии. Даже если в автоматическом
режиме нагрева имеется такой путь, именно эта комбинация встречается только в
ручном режиме. Таким образом, данный тест указывает на избыточность двух допоет
нительных путей, приводящих к примеру Т-11.
Действительно ли проблема в схеме? Необязательно. В данном случае приходится
иметь дело с неполными требованиями, поэтому в спецификации тестов могут быть
свои собственные несоответствия. Причина данной проблемы отчасти заключается в
том, что схема создавалась по частям, исходя из ответов, предоставленных автори-
тетным лицом проекта. В первой итерации схемы использовалась общая информация
о духовом шкафе. В более позднюю версию была включена информация о пользова-
тельском интерфейсе и таким образом были внесены дополнения к схеме. С помощью
этих дополнений будут разработаны тесты, использующие клавишу СТАРТ так же, как
и другие клавиши, доступные пользователю. Контроллер духового шкафа интерпре-
тирует нажатие клавиши СТАРТ, когда с ней не связаны никакие числовые значения,
так же как и ввод числовых данных. Если давать определение пользовательскому ин-
терфейсу отдельно, то эти три пути не обязательно в результате приведут к одному и
тому же тестовому примеру.
Если необходимо наличие однозначного соответствия между схемой тестов и тес-
товыми примерами, придется давать определение трем отдельным тестовым приме-
рам, даже если их входные данные и описание ожидаемых результатов идентичны.
От схемы тестов к тестовым примерам
91
I эжно также сделать ссылку в одном из тестовых примеров на его клоны. Например,
"ест, полученный из элемента схемы 1.2.1.1, может содержать инструкцию “см. тесто-
ый пример Т-П”, предполагая, что пример Т-11 документирует результаты теста из
семента схемы 1.1.2.
2 [R-3] Автоматический
режим
2.4 [R-7]
2.4.1
2.4.2
Команда СТАРТ
Нет данных/
по молчанию
<• 11 • „ I ; I * *- ® ' * й,,
1
2 4.1.2 Духовой шкаф нагревается
Повторный ввод
Теперь более-менее очевидно то, как схема тестов из приложения А4 преобразует-
ся в тестовые примеры, показанные в приложении А5. Создание тестовых примеров
томительное, трудоемкое занятие и автор не станет донимать читателя пространны-
ми комментариями к каждому тестовому примеру, однако несколько тестовых приме-
j> >в имеют основания для дополнительных объяснений.
Элемент схемы 1.3.1.2, в котором определяется использование клавиши ОТМЕНА,
когда духовой шкаф находится в состоянии нагрева, служит источником для тестово-
го примера Т-22. Вместо того чтобы указывать этапы нагрева духового шкафа, в Т-22
~эосто предполагается запуск другого тестового примера, Т-2, чтобы перевести духо-
июй шкаф в известное состояние нагрева.
Оба тестовых примера, Т-35 и Т-36, зависят от текущего времени. Хотя духовой
*каф находится в нерабочем состоянии в момент начала каждого из тестов, Т-35 тре-
гЧ’ет, чтобы текущее время было до 14:05, в то время как для Т-36 необходимо, чтобы
:кущим временем был момент 11:20. Это налагает некоторые ограничения на вы-
^лнение тестов, однако задача тестеров— определить тест. Тестеры будут сталки-
аться с такими проблемами всякий раз, когда элементом приложения будет время.
Реальная входная последовательность, написанная прописью в столбце “Входные
пнные” в табл.3.1, зависит от имеющегося на данный момент пользовательского ин-
> :рфейса. Любые последующие изменения в пользовательском интерфейсе потребу-
т соответствующей модификации в спецификации входных данных тестовых при-
грев. Отделение значений данных от критериев интерфейса, как показано в
габл. 3.2, позволяет допустить общее описание входных данных. Эта новая таблица
содержит отдельный столбец для каждого значения входных данных без уточнения
реальной последовательности нажатия клавиш. Такой формат подходит для прило-
ений, в которых порядок ввода или подробности нажатия клавиш не важны. Тестер
92
Глава 3
должен сам решить, какой формат для записи необходимой информации подходит
наилучшим образом.
[R-3] 1.1 1.2 Ручной режим [R-4] [R-8] Температура приготовления Команда начала работы
1.3 [R-10] Команда окончания работы (клавиша ОТМЕНА) 4’
1.3.1 Нетданных/по умолчанию 1.3.1.1 духовой шкаф неактивен
1.3.1.1 духовой шкаф нагребается
В дополнение к схеме тестов, которая является ценным средством для определе-
ния тестовых примеров, дополнительную информацию о контроллере духового шка-
фа дает пользовательская документацияв главе 2. Это описание автоматического и
ручного режима служит основанием для дальнейшего тестирования. Для создания
теста, который поможет убедиться в правильности работы духового шкафа, будет ис-
пользоваться табл. 2.1. Конечно, тесты, созданные на основе этого источника, могут
дублировать тесты, созданные на основе схемы. В табл. 8.8 содержится несколько та-
ких новых тестов, которые позволяют убедиться, что пропуск или задание температу-
ры приготовления, времени начала и времени окончания работы приводят в резуль-
тате к соответствующему поведению духового шкафа. Тестовые примеры, заданные в
табл. 3.3, начинаются с Т-100, чтобы можно было отличить их от других тестовых
примеров, заданных в этой главе.
Первый тест, Т-100, был получен из первой строки в табл. 2.1. Этот тест предпола-
гает, что не было задано время начала работы, время окончания работы или темпера-
тура приготовления. Когда пользователь включает духовой шкаф, используя команду
СТАРТ, шкаф нагревается до температуры, задаваемой по умолчанию, равной 350° Ф,
и остается в таком состоянии до тех пор, пока пользователь не нажмет клавишу
ОТМЕНА. Тестовый пример Т-101 дает возможность убедиться, что духовой шкаф от-
ключается нужным образом.
Тестовый пример Т-102 является результатом строки с элементом ф2 в табл. 2.1.
В данном тесте тестеры задают температуру приготовления, равную 275° Ф. Этот тест
предусматривает в духовом шкафу ручной режим. Переходя к тесту Т-103, который
является продолжением Т-102, духовой шкаф отключается, когда пользователь нажи-
мает клавишу ОТМЕНА.
Таблица 3.2. Тестовый пример с перечисленными по отдельности значениями входных данных
ID теста Входные данные Результаты теста
ID тестового примера Схема тестов Предыдущее состояние » Температура приготовления Время начала работы Время окончания работы Ожидаемые результаты Реальные результаты
Т-1 1.1.1.1 (неактивен) 199 (отсутствует) (отсутствует) Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-2 1.1.1.1 1.1.1.2 (неактивен) 200 (отсутствует) (отсутствует) Духовой шкаф включается и нагревается до температуры 200° Ф за 4 минуты. Температура поддерживается в диапазоне 198- 202° Ф. При нагреве на дисплее: ПЕЧЕТСЯ
Т-3 1.1.1.1 (неактивен) 201 (отсутствует) (отсутствует) Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Таблица 3.3. Тестовые примеры, полученные из описания ручного/автоматического режима
ID тестового примера Источник теста (из та€л.2.1) Предыдущее состояние Входные данные Ожидаемые результаты Реальные результаты
Т-100 ф1 (неактивен) клавиша СТАРТ Духовой шкаф включается и нагревается до 350° Ф за 5 минут Температура поддерживается в диапазоне 348°-352°Ф. При нагреве на дисплее: ПЕЧЕТСЯ
Т-101 ф1 запуск Т-100 клавиша ОТМЕНА Духовой шкаф перестает нагреваться и выключается. Дисплей: <пусто>
Т-102 ф2 (неактивен) 275 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 275°Ф за 4 минуты. Температура поддерживается в диапазоне 273°-277° Ф. При нагреве на дисплее: ПЕЧЕТСЯ
Т-103 ф2 запуск Т-102 клавиша ОТМЕНА Духовой шкаф перестает нагреваться и выключается. Дисплей: <пусто>
Т-104 фЗ (неактивен) текущее время 13:10 клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1410 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350° Ф за 5 минут. Температура поддерживается в диапазоне 348°-352° Ф. Дисплей: таймер, начинающий отсчет с 01:00:00. Духовой шкаф выключается в 14:10 (когда таймер покажет 00:00:00) и подает звуковой сигнал.
Дисплей: <пусто>
ID тестового примера Источник теста (из табл.2.1) Предыдущее состояние Входные данные Ожидаемые результаты .АйллйАЯ -Та Реальные результаты
Т-105 фЗ запуск Т-104 25 секунд после начала нагрева в Т-104 нажать клавишу ОТМЕНА Духовой шкаф перестает нагреваться и выключается. Дисплей: <пусто>
Т-106 ф4 (неактивен) текущее время 5:34 45 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1534 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 455° ф за 6 минут. Температура поддерживается в диапазоне 453°-457°Ф. Дисплей: таймер, начинающий отсчет с 10:00:00. Духовой шкаф выключается в 15:34 (когда таймер покажет 00:00:00) и подает звуковой сигнал. Дисплей: спустс»
96
Глава 3
Остальные тестовые примеры выполняются аналогичным образом. Каждый тес-
товый пример начинается с неактивного состояния, если не указано иного. Будет ли в
тестовом примере задаваться время начала или время окончания зависит от режима
работы духового шкафа — ручного или автоматического.
Эти таблицы предоставляют необходимую документацию для тестовых приме-
ров до тех пор, пока не будут как следует определены входные данные и ожидае-
мые результаты. Следующий этап для тестеров — подготовка среды тестирования
(см. главу 9).
Упрощенный формат документации
Создание схемы и тестовых примеров для примера с контроллером духового шка-
фа порождает массу документации. Иногда можно воспользоваться упрощенным
форматом документации, чтобы ускорить создание тестовых примеров. У такого ме-
тода есть свои недостатки: упрощенные документы могут оказаться неадекватными
для удовлетворения строгих требований к документации, в особенности, когда они
неточно описывают входные данные и ожидаемые результаты. Однако в несформи-
ровавшихся организациях сведенная к минимуму документация может серьезно об-
легчить предварительную работу, в особенности, когда фактор времени очень важен.
Сокращения при составлении документации оправдывают себя только тогда, когда
специалисты, хорошо изучившие проект, могут отследить пропущенные этапы; одна-
ко любая информация, которая не была документирована, будет утрачена и забыта.
Принятие упрощенного формата документации зависит от степени риска, которую
организация сочтет приемлемой. Причины, вынуждающие избегать данного метода,
следующие:
• нужно составить исчерпывающую тестовую документацию;
• для повышения скорости работы к тестированию подключаются новые сотруд-
ники;
• нужно получить и сохранить аккредитацию от сторонних организаций по стан-
дартизации (сторонние аудиторы при аккредитации будут рассматривать уп-
рощенную документацию как недостаток).
К упрощению документации относится использование собственных схем с целью
выбора тестов и отслеживания их результатов. Некоторые тестеры могут ограни-
читься регистрацией всех выполненных тестов, сделав отметки на твердых копиях
схемы. Однако копии после этого очень быстро пачкаются. По возможности лучше
хранить информацию в виде компьютерных файлов, используя электронные таблицы
или тестовые средства специализированного программного обеспечения. Снабжен-
ная комментариями схема обеспечивает таблицу контрольных проверок типов запу-
щенных тестов.
Далее метод упрощенного документирования тестов будет продемонстрирован на
примере нескольких электронных таблиц. В принципе, наилучшего формата не суще-
ствует; тестер сам должен решать, в каком формате представить необходимую ин-
формацию. Хотя в табл. 3.4-3.7 и в приложении А6 отображается одна и та же
От схемы тестов к тестовым примерам
97
информация, она имеет разный формат. Ниже показано только несколько первых
трок электронной таблицы, тогда как в приложении А6 содержится полный вариант
прощенного документа.
'аблица 3.4. Таблица контрольных проверок
остового примера с расстановкой приоритетов на основе цветового кодирования
Схема тестового примера Данные Результат
[Т-3] Ручной
режим
1.1 [Т-4] Температура
приготовления
1.1.1 [Т-1] Граничные значения
2ОО°-5ОО° Ф/Шаг5°Ф
1.1.1.1 199/200/201
1.1.1.2 195/200/205 195 У
1.1.1.3 499/500/501 499 X
1.1.1.4 495/500/505
1.1.2 [Т-5] По умолчанию 350° Ф S
1.1.3 Повторный ввод См. под- V
список
1.1.3.1 Духовой шкаф не работает 250,405 V
1.1.4.2 Духовой шкаф нагревается 205, 450
1.1.4 Верные данные 345
1.1.4.1 410
98
Глава 3
Таблица 3.5. Таблица контрольных проверок
тестового примера с расстановкой приоритетов в отдельном столбце
Схем а ’естового пр/* “фа " 5 >." ые Результат
1 [т-з; Ручной режим
1.1 [Т-4] Температура приготов-
ления
1.1.1 [Т-1] Граничные
значения
2ОО°-5ОО° Ф/ Шаг 5° Ф
1.1.1.1 199/200/201
2 1.1.1.2 195/200/205 195
2 1.1.1.3 499/500/501 499 X
1.1.1.4 495/500/505
1 1.1.2 [Т-5] По умолчанию 350° Ф у/
2 1.1.3 Повторный См. под-
ввод список
1.1.3.1 Духовой шкаф не работает 250,405
1.1.3.2 Духовой шкаф нагревается 205, 450
1 1.1.4 Верные данные 345
1 1.1.4.1 410 ✓
Таблица 3.6. Таблица контрольных проверок тестового примера, отсортированная по приоритетам
Приоритеты Схема тестового примера Данные Результат
1 1.1.2 [Т-5] По умолчанию 350° Ф Z
1 1.1.4 Верные данные 345 Z
1 1.1.4.1 410 Z
1 1.1.5.1 ООО X
1 2.1.1.2 195/200/205 195,205 Z
1 2.1.2 [Т-5] По умолчанию 350° Ф Z
1 2.2.2.1 Духовой шкаф не работа- 0725,0720 Z
ет
1 2.2.5.1 Текущее время < время Текущее время = 23:58. Z
начала работы Начало работы = 23:59.
1 2.2.5.2 Текущее время = время Текущее время =19:30. Z
начала работы Начало работы = 19:30.
1 2.3.2.2 Духовой шкаф нагревает- Z
ся
1 2.3.3.2 2359 (верхняя граница) X
1 2.3.5.2 Время начала работы = Начало работы = 16:47. Z
время окончания работы Окончание работы =
16:47.
1 2.5.1.1 Задано время начала ра- Z
боты
2 1.1.1.2 195/200/205 195 Z
2 1.1.1.3 499/500/501 499 ✓
2 1.1.3 Повторный См. подсписок X
ввод
2 1.1.5.5 Отрицательные значения Невозможно выполнить Z
Окончание табл. 3.6
Приоритеты 'СхемаТ|йтового примера; - • Данные Результат
2 2.1.5.6 Буквенные символы Невозможно выполнить н/п
2 2.2.1.1.1 Нажать кла- вишу ВВОД н/п
2 2.2.1.1.2 Нажать кла- вишу ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ ✓
2 2.2.1,13 Нажать кла- вишу СТАРТ X
2 2.2.5.3 Текущее время > время начала работы Текущее время = 10:57. Начало работы = 10:56.
2 2.3.5.1 Время начала работы < время окончания работы Текущее время = 19:30. Начало работы = 23:59.
2 2.3.5.3 Время начала работы > время окончания работы Начало работы = 16:48. Окончание работы = 16:47. 7
1 [Т-3] Ручной
режим
1.1 [Т-4] Температура
приготовления
1.1.1 [Т-1] Г раничные значения
2ОО°-5ОО° Ф/Шаг5°Ф
1.1.1.1 199/200/201
1.1.1.4 495/500/505
Таблица 3.7. Таблица контрольных проверок тестового примера с идентификаторами тестовых примеров и приоритетами
Приоритеты Схема тестового примера * Резу пьтаты
501 1 [Т-3] Ручной режим
1.1 [Т-4] Температура приготовления
1.1.1 [Т-1] Граничные значения
200°-500° Ф/Шаг5°Ф
502 1.1.1.1 199/200/201
2 503 1.1.1.2 195/200/205 J
2 504 1.1.1.3 499/500/501 *
505 1.1.1.4 495/500/505
1 506 1.1.2 [Т-5] По умолчанию 350° Ф z
2 507 1.1.3 Повторный ввод
507-а 1.1.3.1 Духовой шкаф не работает J
507-6 1.1.3.2 Духовой шкаф нагревается J
1 508 1.1.4 Верные данные
1 509 1.1.4.1 410 J
102 Глава 3
Упрощение документации можно представить в виде последовательности этапов.
Этап 1
Один столбец в электронной таблице содержит исходную схему тестов.
Каждый лист схемы характеризует входные данные для тестового примера. Неко-
торые элементы схемы, не являющиеся листьями, также могут породить тестовые
примеры.
Этап 2
Тестер или руководитель проекта устанавливает приоритеты для тестов, выбирая
тесты, которые будут запускаться.
Для определения того, какие тесты будут запускаться, существует два метода. Пер-
вый — это использование разноцветных маркеров при цветовом кодировании листьев
схемы, когда разными цветами отмечаются различные уровни приоритетов. Другой
подход, который заключается в выделении отдельного столбца для расстановки при-
оритетов, имеет свои преимущества:
• не нужно использовать различные цвета, в особенности если распечатки черно-
белые;
• ввести числа в электронную таблицу проще, чем делать пометки маркером;
• порядок строк в таблице можно менять, основываясь на приоритетах.
Тестер или руководитель проекта определяет значение цвета или кода приорите-
та. Например, приоритет 1-го уровня может указывать на то, что тест нужно запустить
перед поставкой системы, тест с приоритетом 2-го уровня резервируется для после-
дующей улучшенной версии продукта. Различными цветами можно отмечать приори-
теты тестов, конфигурацию используемой системы или даже информацию о том, кто
проводил тест. В рассматриваемом примере более светлый и более темный цвета (см.
табл. 3.4) указывают на приоритеты уровня 1 и 2 соответственно.
Этап 3
В ходе выполнения теста тестер записывает данные, которые использовались для
запуска каждого теста.
Если на листьях схемы не заданы реальные входные значения, то тестер будет за-
писывать значения данных, которые использовались при выполнении теста.
Этап 4
Тестер записывает результаты теста в отдельный столбец.
Часто тестеры записывают лишь факт прохождения теста или его провала вместо
реально полученных выходных данных. В нашем примере тестер ставит контрольную
метку чтобы отметить успешные тесты, и метку * для обозначения тестов, которые
провалились. Конечно, корректность выполнения остается на совести тестера. При
обнаружении неожиданных результатов тестер решает, ведет ли себя система прием-
лемо при определенных входных данных.
От схемы тестов к тестовым примерам
103
Обозначение “н/п” означает “не применимо”, оно встречается, когда выбранный
_ест в существующих на данный момент условиях невыполним.
Этап 5
Организации, которые отслеживают тесты при помощи идентификатора, могут
. . Завить информацию о нем в таблицу.
Электронная таблица содержит столбец для вставки идентификатора тестового
~имера. Возле узлов схемы, которые не были преобразованы в тестовый пример,
вместо идентификатора тестового примера стоит прочерк
В таблицах представлены различные форматы записи, используемые для упро-
щенной документации тестов. Все примеры таблиц содержат столбец для записи
входных данных и результатов тестов. В табл. 3.4 показан пример использования цве-
вого кодирования, а также тесты, полученные из узлов, а не из листьев. Тестеры
’ .-стируют элемент схемы 1.1.3, выполняя элементы 1.1.3.1 и 1.1.3.2, находящиеся под
аги. Для элемента схемы 1.1.4 тестеры проводят тестирование верного значения 345,
-то показано в столбце с данными. Кроме того, тестер вводит верное значение 410,
торое задается элементом схемы 1.1.4.1, но ему не нужно записывать значение “410”
з столбец с данными, поскольку это значение данных уже указано элементом схемы.
Вместо использования цветового кодщювания в табл. 3.5 показано использование
дельного столбца для расстановки приоритетов среди тестовых примеров. В этой
таблице содержится та же информация, что и в табл. 3.4.
В табл. 3.6 показаны те же элементы таблицы, что и раньше, но со строками, от-
ртированными по приоритетам. Тестовые примеры без отметки о приоритете по-
лещены в конец списка. Недостаток этого метода заключается в том, что каждый эле-
мент схемы оказывается вырванным из контекста, следовательно, теряются иерархи-
ческие связи схемы, а также информация о путях. Несмотря на это, отсортированный
; приоритетам список все-таки может служить таблицей контрольных проверок для
' острого тестирования.
В табл. 3.7 содержатся как идентификаторы тестовых примеров, так и коды при-
эитетов, размещенные в отдельном столбце. В соответствующих тестовых примерах
еречисляются детали каждого теста, включая входные данные. Не каждая строка в
гхеме содержит идентификатор теста. Недостаток этого метода заключается в том,
~о для специфических тестов может существовать множество входных условий; од-
- -ко в данном случае необходимо документировать тип теста, который будет выпол-
_гться. Поскольку элемент схемы 1.1.3 — это приоритетный тест, то связанный с ним
теговый пример № 507 содержит все возможности для выполнения условий, указан-
ных в элементах 1.1.2.1 и 1.1.3.2.
Методы составления краткой документации позволяют упростить регистрацию
го, что уже было протестировано. Следует напомнить, что ведение такой докумен-
тции означает неполноту журнала тестирования. В главе 10 обсуждается возмож-
эсть преобразования кратких записей в журнале тестирования в более подробные
кументы, облегчающие отслеживание проведения тестов и соответствие получае-
мых результатов.
104
Глава 3
Резюме
Как было показано в главе 2, схемы тестов помогают организовать информацию и
выделить комбинации входных данных в приложении. Эта информация полезна при
разработке тестовых примеров. Каждый путь в схеме преобразуется в тестовый при-
мер. Используя таблицу для записи информации о тестовых примерах, тестер пере-
числяет комбинации входных данных, затем присваивает тестовым примерам иден-
тификаторы и определяет ожидаемое поведение приложения. Иногда ожидаемый
исход становится известен не сразу, поэтому тестер должен сам отыскивать эту ин-
формацию.
Тестер может и не создавать таблицы тестовых примеров, делая заметки непо-
средственно на схеме. При сокращении документации тестер должен знать, как функ-
ционирует приложение, поскольку при таком подходе полное описание входных дан-
ных и ожидаемых результатов отсутствует. Тестер может расставить приоритеты ли-
бо используя цветовое кодирование, либо присваивая знаки приоритета, он регист-
рирует используемые входные данные, результаты выполнения теста и факт прохож-
дения теста. Хотя сокращения в документации неадекватны в плане удовлетворения
общепринятым инструкциям по созданию документации по тестированию и могут
повредить аккредитации, полученной от сторонних структур, отвечающих за стан-
дартизацию, они позволяют тестерам строить планы на будущее, а также снизить
риск в сложных ситуациях.
ГЛАВА
Использование электронных
и обычных таблиц
г-ведение
Для систем с большим количеством точек входа или для приложен!^ с большим
> ' транством входов таблицы являются эффективным средством при определении
~овых примеров. Таблица, или ее интерактивный эквивалент— электронная таб-
в которой строки и столбцы отражают входные комбинации, — один из наибо-
распространенных инструментов тестирования ПО. Под термином электронная
» часто подразумевается таблица, которую обрабатывают при помощи компью-
чых средств управления, поэтому далее будет использоваться более общий термин
гД ииа.
Таблицы имеют множество форматов — универсального общепринятого формата
» :Vi чествует. Объемы информации, содержащейся в таблицах, меняются. Наряду с
ганием тестовых примеров в некоторых таблицах содержится дополнительная
Формация, имеющая отношение к проведению тестов. Если тестеры регистрируют
~голицах достаточно существенную информацию, то программисты могут восполь-
л $аться такими таблицами для точного воспроизведения провалившегося теста.
Демонстрацией использования таблиц при определении и документировании тес-
з может послужить пример простого диалога. С помощью сегодняшних инструмен-
- ьных средств невозможно воспользоваться простым диалогом на данном уровне,
гнако этот простой пример проиллюстрирует идеи создания тестовой таблицы.
.1'есь количество возможных входных комбинаций значительно меньше, чем в более
z иных или сложных системах, значит, пример требует несколько меньшей тестовой
пщы. В примере также будет представлено несколько сокращений для документи-
зания тестов, каждое из которых влияет на количество получаемой информации.
106
Глава 4
Глава 5 посвящена использованию таблиц в других приложениях, таких как диа-
граммы переходов, обработка изображений аналогично прочим аспектам тестирова-
ния ПО, включая тестирование элементов, слежение за тестом и планирование тес-
тирования.
Таблицы склонны к увеличению, и многочисленные инструментальные средства
направлены на автоматизацию некоторых задач тестирования. Независимо от ис-
пользования программных средств, таблицы играют очень важную роль в тестирова-
нии ПО. Цели этой главы состоят в следующем.
• Объяснить, каким образом тестеры используют таблицы.
• Объяснить, как разработчики могут интерпретировать табличные данные.
• Помочь менеджерам по разработке и руководителям проектов понять значение
задачи тестирования.
• Послужить руководством для тестеров, вынужденных работать в ситуации со
сжатыми сроками или в ситуации, когда инструментальные средства стоят до-
роже, чем само тестирование.
• Проиллюстрировать способы, которые помогают избежать утомительных и
повторяющихся задач.
• Помочь в ручном создании таблиц, когда инструментальные средства недос-
тупны.
Пример приложения
Приложения с графическим пользовательским интерфейсом (Graphical User Inter-
face — GUI) имеют много возможностей, с помощью которых пользователь может за-
полнить поле ввода. Это сразу приводит к огромному количеству тестовых примеров.
Благодаря современным технологиям многие инструменты позволяют автоматизиро-
вать тестирование GUI путем виртуальной генерации всех возможных нажатий кла-
виш и управлением всеми возможными агрибутами. Молодые тестеры, однако, могут
не располагать такими “предметами роскоши”, как комплексные инструментальные
средства, или же могут не понимать идеи, которая лежит в основе интерфейса тести-
рования. Проанализируем один из аспектов GUI—диалоговое окно.
Внешний вид рассматриваемого простого диалогового окна представлен на
рис. 4.1. Пользователь заполняет поля username и password, а затем нажимает либо
кнопку ОК для подтверждения ввода, либо кнопку Cancel, чтобы прервать диалог.
Этот пример довольно прост по двум причинам. Во-первых, здесь имеется лишь два
поля ввода и две кнопки, и, во-вторых, игнорируются атрибуты, связанные с каждым
полем ввода GUI.
Задача этого примера состоит в иллюстрации методов определения тестов, в том
числе и тестов ввода данных пользователем, а также определения слежения за свя-
занной с этим информацией. Данный пример с самого начала демонстрирует, как бы-
стро растет количество тестов и как затем вводятся методы для координации стреми-
тельного увеличения объемов тестирования.
Использование электронных и обычных таблиц
107
Рис. 4.1. Пример диалогового окна
Фокус (текущая позиция курсора) может находиться в четырех местах, каждое из
которых должно правильно отвечать на любое нажатие клавиши исходя из своего
контекста. Например, нажатие на буквенно-цифровые клавиши в результате будет
приводить к появлению в поле username новых символов, в то время как нажатие той
же последовательности клавиш тогда, как фокус находится на кнопке ОК, приводит к
тому, что приложение игнорирует нажатие клавиш.
Пользователь располагает широким выбором среди возможных нажатий клавиш
(как верных, так и ошибочных) для каждой точки входа. Количество возможных на-
жатий клавиш меняется в соответствии с типом используемой клавиатуры. Рассмот-
рим обычную клавиатуру с 88 различными клавишами. Такое количество клавиш дает
более 600 различных комбинаций нажатий клавиш для каждого поля ввода GUI. Эта
величина образуется с помощью следующих комбинаций:
• 88 разных клавиш — дают 26 символов нижнего регистра, 10 цифр, 12 символов
пунктуации, 12 функциональных клавиш и 28 прочих клавиш (таких как
<ENTER>, <INSERT>, <НОМЕ>, <PAGE UP>, <UP ARROW>, <SHIFT>,
<CONTROL>);
• 87 комбинаций с клавишей <SHIFT> — нажатие клавиши <SHIFT> можно соче-
тать с нажатием одной из остальных 87 клавиш, некоторые из них дают симво-
лы верхнего регистра и другие знаки пунктуации;
• 87 комбинаций с клавишей <CONTROL>— нажатие клавиши <CONTROL>
, можно сочетать с нажатием одной из 87 оставшихся клавиш;
• 87 комбинаций с клавишей <ALT> — клавишу <ALT> можно использовать со-
вместно с одной из 87 оставшихся клавиш;
• 86 комбинаций <CONTROL> + <SHIFT> — существует 86 возможных трехкла-
вишных комбинаций, в которых задействуются одновременно <CONTROL>,
<SHIFT> и любая третья клавиша;
• 86 комбинаций <ALT> + <SHIFT> — еще одна распространенная комбинация
нажатия трех клавиш, <ALT> + <SHIFT> + <любая третья клавиша>;
• 86 комбинаций <CONTROL> + <ALT> — комбинация включает в себя одновре-
менное нажатие клавиш <CONTROL>, <ALT> и любой третьей клавиши.
108
Глава 4
Таблица 4.1. Перечень возможных клавишных комбинаций для диалогового окна
Геюлц. ПОЗИЦ' курсора со -О ы о SH1FT + а? Ш SHIFT + b SHIFT + z SHIFT+ 0 SHIFT + 9 vONTROL + a - ; CONTROL+
попе Username
поле Password
кнопка ОК
кнопка CANCEL
Некоторые комбинации дают различный эффект в зависимости от основного со-
стояния системы. В качестве примера можно привести символ пробела, который иг-
норируется, если он следует после другого пробела, но важен, если следует за другим
символом. Часто поведение многих многоклавишных комбинаций определяется опе-
рационной системой; например, после нажатия клавиш <CONTROL> + <s> следует
запись текущей информации в файл. В этот пример не включены ни другие двух- и
трехклавишные комбинации, ни контекст, в котором они используются. Чтобы этот
пример более-менее соответствовал действительности, возможности будут ограниче-
ны лишь наиболее распространенными двух- и трехклавишными комбинациями, а
операционная система не будет приниматься к рассмотрению. Естественно, что в ре-
альной ситуации при тестировании решение принимается исходя из типа тестируе-
мых нажатий клавиш. Даже не прибегая к скрупулезному изучению полного набора
клавишных комбинаций, становится ясно, что все возможности по нажатию клавиш
выливаются в огромное количество тестовых примеров.
Таблица свободно отражает поля ввода на список возможных клавишных комби-
наций. Часть такой таблицы показана в табл. 4.1. Ограничивая расчеты лишь наибо-
лее распространенными двух- и трехклавишными комбинациями, полная таблица бу-
дет содержать более 600 столбцов. Хотя двухклавишные комбинации типа
<SHIFT> + <а> эквивалентны символу “А” верхнего регистра, в заголовке таблицы эта
комбинация считается действительной.
Перечень всех возможных комбинаций дает в итоге огромную таблицу. Несмотря
на это, данный подход имеет свои преимущества.
1. Упражнение по созданию большой таблицы помогает начинающим тестерам
понять важность тестирования.
2. Большая таблица откроет глаза тем наивным менеджерам, которые не предос-
тавили тестерам достаточно времени на тестирование и недооценили этот
важный этап создания качественного продукта.
Использование электронных и обычных таблиц
109
3. Если тестеры в замешательстве и не знают с чего начать, сведение подробного
перечня всех возможных комбинаций ввода в таблицу вызывает к жизни идеи,
которые затем служат основой для поиска более продуктивных путей тестиро-
вания.
4. Тестеры явственнее ощущают преимущества, предоставляемые инструмен-
тальными средствами.
Существует несколько методов, позволяющих уменьшить размер таблицы. Один из
- пектов работы тестера состоит в разумном сокращении числа тестовых примеров.
В следующем разделе рассматривается схема вычисления избыточности в тестовой
“аблице. В главе 8 представлены еще некоторые методы снижения количества тестов.
Основное предназначение данной книги — облегчить начальные этапы тестирования,
поэтому сначала будут рассмотрены некоторые методы документирования тестов с
помощью таблиц.
Документирование тестовых примеров
В простейшем случае таблица представляет из себя матрицу, где в крайнем левом
столбце собраны все возможные варианты начальных условий, а в самой верхней
проке перечисляются действия, которые необходимо выполнить. Каждая из ячеек
матрицы, образуемая пересечением строк и столбцов, обозначает отдельный тесто-
вый пример.
На рис. 4.2 показан общий вид таблицы тестовых примеров, формат которой сов-
падает с форматом таблицы состояний (описание таблицы состояний дается в главе 5).
Различные строки с<ютветстг.уют различным полям, куда пользователь может вводить
свои данные, а столбцы представляют различные варианты ввода. Таким образом,
каждая ячейка таблицы показывает поле с введенной последовательностью данных.
Например, выделенный тестовый пример № 34 требует, чтобы тестируемое прило-
жение привели в состояние, соответствующее полю ввода 3, а затем выполнили дей-
-гвия, определяемые вводом 4. Чтобы описание тестового примера считалось пол-
ным, тестер должен указать ожидаемые результаты. Количество сведений существенно
по
Глава 4
меняется для разных ячеек. Оставшаяся часть этой главы посвящена методам доку-
ментирования тестовых примеров. После выполнения тестового примера и оценки
поведения системы тестер может составить свое собственное мнение о действительг
ном исходе теста.
Действие Начальное состояние Ввод данных 1 Ввод данных 2 Ввод данных 3 Ввод данных 4 Ввод данных 5 — Ввод данных 6
Приглашение 1 тестовый пример 11 тестовый пример 12 тестовый пример 13 тестовый пример 14 тестовый пример 15 тестоны» пример 16
Приглашение 2 - . пример 21 тестовый пример 22 тестовый пример 23 тестовый пример 24 тестовый пример 25 тестовый пример 2fi
Приглашение 3 тестовый пример 31 тестовой пример 32 тестовый пример 33 тестовьй триер Зч тестовый пример 35 тестовый пример 36
Приглашение 4 тестовый пример 41 тестовый пример 42 тестовый пример 43 тестовый пример 44 тестовый пример 45 тестовый пример
Приглашение 5 тестовый пример 51 тестовый пример 52 тестовый пример 53 тестовый пример 54 тестжй пример 55 тестовый пример 56
Приглашение 6 тестовый пример 61 тестовый пример 62 тестовый пример 63 тестовый пример 64 тестовый пример 65 тасгай пример 66
Рис. 4.2. Таблица тестовых примеров
Разные типы информации (например, ожидаемые результаты, реальные результа-
ты, прохождение или провал теста и даже название системы отчетности) можно за-
фиксировать, как будет показано в следующем разделе. Каждый из методов удовле-
творяет конкретному критерию и применим в различных ситуациях.
Способы составления документации
Как уже говорилось ранее, таблица ставит в соответствие различные начальные
условия разным вариантам ввода. В примере диалогового окна в крайнем левом
столбце тестовой таблицы собраны начальные условия, которые в данном примере
состоят из двух полей ввода и двух кнопок. Столбцы соответствуют различным после-
довательностям возможных нажатий клавиш. В зависимости от формата таблицы
ячейки могут представлять собой или отдельный тестовый пример, или группу свя-
занных тестовых примеров. Полное описание тестовых примеров будет включать в
себя ожидаемые результаты и свободное место для записи результатов теста, а также
вердикта о его прохождении. Существует несколько способов регистрации этих дан-
ных. Все таблицы этого раздела можно использовать независимо; форматы примерно
равноценны — у каждого из них есть как преимущества, так и недостатки.
Представленные далее варианты таблиц иллюстрируют различные методы доку-
ментирования информации при тестировании диалогового окна. Напомним, что
табл. 4.1 содержит более 600 столбцов, поэтому для краткости рассматриваемая таб-
лица будет содержать несколько столбцов, необходимых для изложения различных
методов регистрации данных тестового примера.
Использование электронных и обычных таблиц
111
Каждый из форматов таблиц акцентируется на каком-либо из уровней информа-
ции. Форматы таблиц № 2 и № 4 отражают понятия, касающиеся собственно тестиро-
вания ПО.
Формат таблицы № 1 Формат таблицы № 2 Дает очень короткое описание ожидаемых результатов. Использует анализ граничных значений для описания различных условий ввода.
формат таблицы № 3 Полное описание теста собирается в отдельный документ, а контрольные данные — в тестовой таблице.
Формат таблицы № 4 Используется деление на классы эквивалентности для группировки вариантов ввода, дающих одинаковые результаты.
Формат таблицы № 5 Начальные условия, входные данные и ожидаемые результаты определяются в отдельных строках тестовой таблицы.
Какому же типу таблиц отдать предпочтение? Единого правильного ответа не су-
ществует. Выбор формата таблицы зависит от того, какая компоновка более очевидна
для тестера, а также от объемов имеющейся информации. Некоторые форматы таб-
лиц хранят достаточно сведений, чтобы программисты или тестеры могли воспроиз-
вести неудачный тест. Программные тестовые примеры разрабатываются специально
для тех приложений, которые тестируются, поэтому схема тестирования неизбежно
должна отражать специфические свойства приложения. Другими словами, следует
использовать любой удобный формат документов, чтобы сохранить нужную инфор-
мацию как для последователей, так и для общения с командой разработчиков.
Хотя формат таблицы прост и компактен, иногда может потребоваться сократить
количество регистрируемой информации. Как и в случае с описанием теста, при ис-
пользовании тестовых таблиц существует несколько методов усечения формата таб-
лицы. Тип используемого усечения зависит от того, должен ли тестер прослеживать
ввод, ожидаемый исход, действительный результат или прохождение теста. Эти ме-
тоды усечения описываются в разделе Сокращения в тестовой документации, но сна-
чала рассмотрим различные методы применения тестовых таблиц.
Формат тестовых таблиц № 1
Метод: дается краткое описание ожидаемых результатов.
Первый метод документирования тестовых примеров заключается в заполнении
всех ячеек таблицы ожидаемыми результатами, как это показано в табл. 4.2. Чаще все-
го характер записей зависит от типа тестируемого приложения.
Таблица 4.2. Формат тестовой таблицы №1: фиксация краткого описания
Поле <t» <Shtft> <Shift> • + <Ь> - <#> : <ENTEK> йЖЖжв <ТАВ> «BACKSPACE? «DELETE?
Поле плюс плюс плюс плюс плюс ошибка. ввести переход стирание стирание переход переход
User- name 'а' Ь' 'А' 'В' 'V невер- ный символ имя пользо- вателя/ пароль в поле Password символа слева символа справа в начало поля Username на один символ влево
Поле плюс плюс плюс плюс плюс ошибка ввести переход стирание стирание переход переход
Pass- word невер- ный символ имя пользо- вателя/ пароль на кноп- ку ОК символа слева символа справа в начало поля Password на один символ вправо
Кнопка без без без без без без ввести переход без без из- без из- без из-
ОК изме- нений изме- нений изме- нений изме- нений изме- нений изме- нений имя пользо- вателя/ пароль на кноп- ку Cancel изменений менений менений менений
Кнопка без без без без без без ввести переход без без из- без из- без из-
Cancel изме- нений изме- нений изме- нений изме- нений изме- нений изме- нений имя пользо- на поле Username изменений менений менений менений
вателя/
пароль
Использование электронных и обычных таблиц
ИЗ
Чтобы описание таблицы было полным, необходимо сделать предположения об
ожидаемом поведении пользовательского интерфейса, которые затем нужно согласо-
вать с разработчиками. Записи в ячейках могут выглядеть следующим образом.
• Краткая запись “плюс а” означает, что тестер вводит символ “а” в обозначенное
поле как крайний правый символ существующей вводимой последовательности.
• Если в поле ввода пароля добавляется правильный символ, система отвечает
появлением символа “ * ” вместо вводимого символа.
• Запись “без изменений” в ячейке означает, что никаких изменений не происхо-
дит (ни изменений внутри системы, ни изменений, видимых для пользователя).
• “Ошибка” означает, что от системы ожидается появление сообщения об ошибке.
По возможности фиксируется краткое описание других реакций. Например,
• введение неверного символа “ # ” в поле Username или в поле Password вызыва-
ет ошибку;
• нажатие клавиши <ENTER> вызывает разную реакцию в зависимости от пози-
ции активной формы ввода;
• нажатие клавиши <ТАВ> вызывает переход курсора в другую область диалого-
вого окна;
• при вводе в поле Username или поле Password нажатие клавиши <BACKSPACE>
приводит к стиранию предыдущего символа.
Последний тест не является четко определенным, так как символ стирается в зави-
симости от текущего положения курсора, и не дается никакой информации о том, что
делать при пустом поле ввода.
Преимущества. В итоге получается контрольная таблица для всех возможных ва-
риантов ввода. Каждой ячейке соответствует отдельный тестовый пример.
Недостатки. Не определены специальные начальные условия, поэтому отсутству-
ет критерий однозначности вводимых данных. В большинстве ситуаций ожидаемый
результат зависит от основного состояния GUI. Рассмотрим тест, в котором говорит-
ся: “Введите символ к”. В данном случае не ясно, будет ли символ “к” первым симво-
лом в пустом поле ввода или он прибавляется к уже введенным символам? Как отреа-
гирует система, если тестер при вводе превысит максимальное количество символов?
Пренебрегая описанием информации, где дается характеристика начальной конфи-
гурации, разные тестеры, скорее всего, будут вводить в поля ввода разные сочетания
клавиш. Пока тестер не обозначит, какое состояние является активным при вводе,
тест будет неэффективным.
Формат тестовой таблицы № 2
Метод: используется анализ граничных значений для описания различных усло-
вий ввода.
114
Глава 4
Чтобы учесть некоторые ограничения, выявленные при рассмотрении формата
тестовых таблиц № 1, формат таблиц модифицируется так, чтобы включить входные
условия, для которых нужно принимать во внимание различные исходные состояния
полей. В общей тактике тестирования используется концепция, известная как анализ
граничных значений, в которой особое внимание уделяется значениям вблизи границ.
Анализ граничных значений широко используется при тестировании числовых диа-
пазонов, математических вычислений, размеров буфера и любых других функций,
влияющих на какой-либо тип пределов. Типичные тесты, заданные на границе, обыч-
но содержат следующие три условия:
• граничное значение;
• граничное значение -1;
• граничное значение+1.
Применение анализа граничных значений к ограниченным диапазонам (которые
имеют как нижнюю, так и верхнюю границы) дает в результате следующие условия
теста:
• min;
• min-1;
• min+1;
• max;
• max-1;
• max+1.
Тестеры часто добавляют еще один тестовый пример:
• “промежуточное” или “типичное" значение для улучшения общей оценки.
Этот последний тест избыточен, если принимать во внимание разбиение на клас-
сы эквивалентности (как описано в формате тестовой таблицы № 4). В примере с ин-
терфейсом GUI приложение ведет себя одинаково независимо от того, будет ли в по-
ле Username 1, 2, 8 или больше символов вплоть до значения max-1. Однако некото-
рые программисты и менеджеры, не имеющие опыта в тестировании, требуют, чтобы
в тестовом примере обязательно использовалось “типичное” значение. Часто гораздо
легче создать новый тестовый пример, который удовлетворил бы посторонних, чем
тратить время на аргументацию того, что тест избыточен. В работах [Капег99],
[Myers 76] и [Myers 79] имеются дополнительные сведения относительно анализа
граничных значений, а в работе [Kit 95] представлены подробные примеры.
Еще в одном методе анализа утверждается, что некоторые из семи условий тестов,
перечисленных выше, избыточны и что для проверки корректности границ доста-
точно лишь трех-четырех тестов. Читатели, которые интересуются подобным анали-
зом, могут дополнительно изучить тестирование области определения по работам
[Beizer 90], [Beizer 95] и [Binder 00]. Теперь важно получить общее представление о
Использование электронных и обычных таблиц 115
подходах к различным тестам, так как дальше будет использоваться анализ граничных
значений.
В примере с диалоговым окном поля Username и Password содержат минимальное
и максимальное число допустимых знаков. В табл. 4.8 показано, как в этом случае
применяется анализ граничных значений.
Таблица 4.3. Применение анализа
граничных значений в примере с диалоговым окном
Условие для граничного значения Исходное состояние полей Ожидаемые результаты Username или Password после ввода дополнительного символа
min min-1 0 символов, "пустое поле" 1 символ в поле нельзя задать размер поля в -1 невозможно символ
min+1 в поле 1 символ 2 символа в поле
max "максимальное число символов". Приложение игнорирует даже если неизвестно, каким лишние символы. Сообщение должно быть это значение об ошибке не появляется. Примечание: в этой ситуации в действительности тестируется условие "max -1"
max-1 "число символов, равное max -1" максимальное число символов в поле
max +1 В примере с диалоговым окном невозможно нет возможности ввести такое число символов, которое ревышает максимальное значение
"ипичное значение Это число символов в диапазоне Приложение принимает новый "min +2..max -2". Если неизвестно, символ какое значение будет "типичным", то в тесте задается такое значение числа символов, которое не было задействовано в предыдущих примерах
В зависимости от приложения не все условия для граничных значений могут пре-
образовываться в реально выполнимый тестовый пример. В тестах, показанных в
табл. 4.8, задается пять тестовых условий, при которых проверяются нижняя и верх-
няя границы размера поля. В результате применения анализа граничных значений
размер таблицы увеличился. В формате таблицы № 4 представлен метод дальнейшего
Уменьшения числа тестовых примеров.
Таблица 4.4. Формат тестовой таблицы Ns 2: дополнительные специфические входные условия
<а> <€> <Shlft> + <а> «Shift» + <б> <1> <№> <£NTER> <ТАВ> «BACK- SPACE» <ОЕ1_ЕТЕ> <НОМЕ> «LEFT ARROW»
Текущее вход- ное состояние
поле пустое добав- добав- добав- добав добав- ошибка: ошибка переход без изме- без изме- без без изме-
User- поле пате ляется 'а' ляется 'б' ляется 'А' ляется 'Б' ляется '1' неверный символ отсутствует имя поль- зователя в поле Password нений нений измене- ний нений
в поле добав- добав- добав- добав добав- ошибка обработка переход вытира- вытира- переход переход
один символ ляется 'а' ляется 'б' ляется 'А' ляется 'Б' ляется’Г неверный символ имени пользова- теля/ пароля в поле Password ется сим- вол слева ется символ справа в нача- ло поля User- name на один символ влево
от 2 до добав- добав- добав- добав- добав- ошибка обработка переход вытира- вытира- переход переход
max-2 ляется 'а' ляется 'б' ляется 'А' ляется 'Б' ляется '1' неверный символ имени пользова- теля/ пароля в поле Password ется сим- вол слева ется символ справа в нача- ло поля User- name на один символ влево
в поле добав- добав- добав- добав- добав- ошибка: обработка переход вытира- вытира- переход переход
max -1 символ ляется 'а' ляется 'б' ляется 'А' ляется 'Б' ляется '1' неверный символ имени пользова- теля/ пароля в поле Password ется сим- вол слева ется символ справа в нача- ло поля User- name на один символ влево
в поле символ символ символ символ СИМВОЛ ошибка: обработка переход вытира- вытира- переход переход
максима- игнори- игнори- игнори- игнори- игнори- неверный имени в поле ется сим- ется в нача- на один
льное число символов руется: без изме- нений руется: без изме- нений руется: без изме- нений руется: без изме- нений руется: без изме- нений символ пользова- теля/ пароля Password вол слева символ справа ло поля User- name символ влево
поле пустое добав- добав- добав добав- добавля- ошибка. ошибка: переход без изме- без изме- без без изме-
Pass- поле word ляется »*• ляется ляется »★» ляется ется неверный символ отсутствует пароль к кнопке ОК нений нений измене- ний нений
Продолжение idUJi. 4.4
<а> <б> <Shrft> <Shlft> <1> + <а> +<б> <№> <ENTER> <ТАВ> <ВАСК- <DELETE> <НОМЕ> <LEFT ... •>
Текущеевход-; ' • . ' ; ' 'J
ное состояние
в поле добав- добав- добав- добав- добавля- ошибка: обработка переход вытира- вытира- переход переход
один символ ляется »♦» ляется ляется »★» ляется »★* ется '*' неверный символ имени пользова- теля/ пароля к кнопке ОК ется символ слева ется символ справа в нача- ло поля Pass- word на один символ влево
от 2 до добав- добав- добав- добав- добавля- ошибка: обработка переход вытира- вытира- переход переход
max - 2 ляется »♦» ляется »♦» ляется »•» ляется »★» ется неверный символ имени пользова- теля/ пароля к кнопке ОК ется символ слева ется символ справа в нача- ло поля Pass- word на один символ влево
в поле добав- добав- добав- добав- добавля- ошибка: обработка переход вытира- вытира- переход переход
max -1 символ ляется <★» ляется ляется »★» ляется ется неверный символ имени пользова- теля/ пароля к кнопке ОК ется символ слева ется символ справа в нача- ло поля Pass- word на один символ влево
в поле символ символ символ символ символ ошибка: обработка переход вытира- вытира- переход переход
максима* игнори- игнори- игнори- игнори- игнори- неверный имени к кнопке ется ется в нача- на один
льное число символов руется: без измене- ний руется: без измене- ний руется: без измене- ний руется: без измене- ний руется: без изме- нений символ пользова- теля/ пароля ОК символ слева символ справа ло поля Pass- word символ влево
кнопка поле без без без без без изме- без изме- ошибка: переход без изме- без изме- без без изме-
OK Username пустое измене- ний измене- ний измене- ний измене- ний нений нений отсутствует имя поль- зователя к кнопке Cancel нений нений измене- ний нений
поле без без без без без изме- без изме- ошибка: переход без изме- без изме- без без изме-
Password пустое измене- ний измене- ний измене- ний измене- ний нений нений отсутствует пароль к кнопке Cancel нений нений измене- ний нений
Окончание табл. 4.4
?б> «Shift «Shift» «> + <а> +<б> «№> «ENTER» тлв> «BACK- SPACE» «DELETF . <НО*ЛЬ «LEFT ARROW»
Тёк^ёСвхб^||
неверное без без без без без изме- без изме- ошибка: переход без изме- без изме- без без изме-
имя пользо- вателя/ пароль измене- ний измене- ний измене- измене- нений НИЙ НИЙ нений неверное имя поль- зователя/ пароль к кнопке Cancel нений нений измене- нений ний
верное без без без без без изме- без изме- обработка переход без изме- без изме- без без изме-
имя пользо- вателя/ пароль измене- ний измене- ний измене- измене- нений НИЙ НИЙ нений имени пользова- теля/ пароля к кнопке Cancel нений нений измене- нений ний
кнопка поле без без без без без изме- без изме- выход переход без изме- без изме- без без изме-
Cancel Username пустое измене- ний измене- ний измене- измене- нений НИЙ НИЙ нений из окна в поле Username нений нений измене- нений ний
поле без без без без без изме- без изме- выход переход без изме- без изме- без без изме-
Password пустое измене- ний измене- ний измене- измене- нений НИЙ НИЙ нений из окна в поле Username нений нений измене- нений ний
неверное без без без без без изме- без изме- выход переход без изме- без изме- без без изме-
имя пользо- вателя/ пароль измене- ний измене- ний измене- измене- нений НИЙ ний нений из окна в поле Username нений нений измене- нений ний
верное без без без без без изме- без изме- выход переход без изме- без изме- без без изме-
имя пользо- вателя/ пароль измене- ний измене- ний измене- измене- нений ний ний нений из окна в поле Username нений нений измене- нений ний
Использование электронных и обычных таблиц
119
Хотя в таблице теперь заданы условия для тестирования поведения приложения с
пустым, частично заполненным полем ввода и с максимальным значением размера
поля ввода, она все же нуждается в полном описании исходной конфигурации вход-
ных полей. Например, какие именно заданы символы, когда поле Username имеет
максимальный размер? При нажатии некоторых клавиш, таких как <BACKSPACE>
или <DELETE>, результаты получаются разными в зависимости от положения курсора
относительно непустого поля. Для тестов, в которых вызываются ошибки, ожидае-
мые результаты неясны. Как возникает ошибка? Издает ли приложение слышимый
жук, открывается ли диалоговое окно по исправлению ошибок, отправляется ли со-
общение об ошибке или же неверное нажатие клавиш игнорируется?
Эти тесты акцентированы больше на форматах ввода имени пользователя и паро-
ля. Хотя это и не имеет отношения к анализу граничных значений, дальше бцдут вве-
дены дополнительные тесты, чтобы учесть обоснованность пары значений имя пользо-
вателя и пароль при создании четырех новых категорий под кнопками ОК и Cancel:
• пустое поле Username;
• пустое поле Password;
• неверная пара значений имя пользователя и пароль (не указывается, какая имен-
но компонента ошибочна);
• верная пара значений имя пользователя и пароль.
Преимущества. Существуют отдельные условия для задания пустого, частично и
полностью заполненного поля, а также верной и неверной пары значений имя пользо-
вателя и пароль. Эта таблица удобна для контрольных проверок различных тестов.
Недостатки. Большинство тестов допускают двоякое толкование и, следователь-
но, не могут быть воспроизведены вследствие неполноты описания ожидаемых и ре-
альных результатов. Например, если в поле Username уже есть один символ, неиз-
вестно каким был предыдущий. Неизвестно также, какая пара значений имя пользова-
теля и пароль обрабатывается. При нажатии клавиш <BACKSPACE>, <DELETE> или
клавиш со стрелками неизвестно точное положение курсора в непустом поле.
В большей части таблиц, показанных на данный момент, содержалась информация
о входных и выходных данных общего характера. Полный тестовый пример, по оп-
ределению, включает недвусмысленную спецификацию входных данных и описание
ожидаемого поведения. Хотя в предыдущих примерах наблюдалась некоторая не-
брежность в плане описания входных данных, здесь дается таблица контрольных
проверок для записи типов выполняемых тестовых примеров. В последующих трех
форматах тестовых таблиц дано более полное описание тестовых примеров.
Формат тестовых таблиц № 3
Метод: в отдельном документе фиксируется исчерпывающее описание теста, а в
тестовой таблице на это описание делается ссылка.
Ожидаемые результаты могут быть точными только тогда, когда заданы недву-
смысленные входные условия. В табл. 4.5 показан другой подход, где в каждой ячейке
120 Глава 4
сделана ссылка на исчерпывающее описание тестового примера, которое документи-
ровано где-то в другом месте. У этого метода есть еще одно преимущество — можно
использовать указатели на отдельные документы тестовых примеров. Как известно,
документы с описанием тестовых примеров обычно очень велики, следовательно, на-
личие удобных ссылок, помогающих быстро определить, где помещен каждый тесто-
вый пример в большой схеме, имеет огромное значение для других читателей. Каж-
дый из идентификаторов тестовых примеров, показанных в табл. 4.5, содержит пре-
фикс, помогающий сгруппировать вместе аналогичные тесты.
Объем информации, содержащейся в тестовом примере, может широко варьиро-
ваться. Рассмотрим различные варианты для теста тп-402, в котором согласно той
информации, что включена в табл. 4.5, в поле Username (уже содержащее символ “г")
добавляется символ “а”. На рис. 4.3 показано одно из возможных описаний этого тес-
та, в котором указывается содержимое диалогового окна, предшествующее впечаты-
ванию символа “а”, и описываются ожидаемые результаты. Пустая часть тестового
примера будет заполнена после проведения теста. Данный тест не обязательно плох,
хотя в нем и не указывается, где вставляется второй символ “а”. Это означает неопре-
деленность и дает почву для интерпретаций: два разных человека, проводя по от-
дельности этот тестовый пример, могут достичь различных результатов. Результатом
одного теста будет появление в поле Username последовательности “га”, в то время
как другой тест даст “аг”. В исправленном тестовом примере на рис. 4.4 не только ука-
зывается положение курсора, а также тестируется возможность вставки символа, при
этом сочетается два метода выполнения теста.
Идентификация ID тестового примера: тп-402 Подсистема: тесты для поля Username Версия программы: Операционная система:
Тестер: Дата проведения теста:
Начальные установки
1. Вызвать диалоговое окно входа в систему
2. В поле Username ввести символ "г"
3. Убедиться, что все остальные области ввода пустые
Ввод данных
1. Поместить курсор в поле Username
2. Ввести символ "а"
Ожидаемые результаты
В поле Username появляются символы "га"
Действительные результаты □ Пройден О Провален
Рис. 4.3. Образец тестового примера
Использование электронных и обычных таблиц
121
Идентификация ID тестового гримера: тп-402 Версия программы:
Подсистема: тесты для поля Username Операционная система:
Тестео: Лата пооведения теста:
Начальные установки 1. Вызвать диалоговое окно входа в систему 2. В поле Username ввести символ У 3. Убедиться, что все остальные области ввода пустые
Ввод данных Часть А 1. Поместить курсор в поле Username после "г" 2. Ввести символ "а"
Часть Б 1. Возврат к начальной установке 2 Поместить курсор в поле Username перед "г"
Ожидаемые результаты Часть А В поле Username появляются символы ’га'
Часть Б В поле Username появляются символы "аг"
Действительные результаты □ Пройден ЕН Провален
Рис. 4.4. Образец тестового примера, состоящего из нескольких частей
До сих пор не задавалось количество деталей, содержащихся в тестовом примере.
Некоторые тестеры-поборники традиций могут поспорить, что один тестовый при-
мер должен описывать один уникальный сценарий тестирования и, следовательно, их
возмущают тестовые примеры, состоящие из нескольких частей. На данном этапе ос-
новная задача заключается в получении тестов, задающих и образующих своего рода
“сборник рецептов” для запуска тестов. Если дается указание, что именно нужно тес-
тировать, это само по себе уже большое достижение при условии, что удовлетворен
критерий задания недвусмысленных входных данных и ожидаемых результатов. То,
как упакована информация, — личное дело каждого. Если это весьма важно для данной
организации, нужно установить, нет ли в компании каких-либо особых указаний отно-
сительно деталей документации тестовых примеров.
Таблица 4.5. Формат тестовой таблицы № 3: ссылки на тестовые примеры
Следующая кла- виша <а> <Ь> <Shift> + <а> <b> <Ъ <М> <ENTER> <ТАВ> «BACK- SPACE <DELETE> <НОМЕ> <tEFT ARROW>
Текущее входное состояние Л
поле пустое поле тп-401 тп-419 тп-501 тп-519 ц-601 ном-1 тп-200 тп-218 нз-32 ш-82 ш-90 стр-1
User- name
в поле один символ тп-402 тп-420 тп-502 тп-520 ц-602 ном-2 тп-201 тп-219 нз-33 ш-83 ш-91 стр-2
от 2 до max-2 тп-403 тп-421 ТП-503 ТП-521 ц 603 ном-3 тп-202 тп-220 нз-34 ш-84 ш-92 стр-3
в поле max-1 символ ТП-404 тп-422 ТП-504 тп-522 ц-604 ном-4 тп-203 ТП-221 нз-35 ш-86 ш-93 стр-4
в поле мак- симальное число сим- волов ТП-405 тп-423 ТП-505 ТП-523 ц-605 ном-5 тп-204 тп-222 нз-36 ш-86 ш-94 стр-5
поле пустое поле тп-406 тп-424 тп-506 ТП-524 ц-606 ном-6 тп-205 тп-223 нз-37 ш-87- ш-95 стр-6
Pass- word
в поле один символ тп-407 тп-425 тп-507 ТП-525 ц-607 ном-7 тп-206 ТП-224 нз-38 ш-88 ш-96 стр-7
от 2 до max-2 тп-408 тп-426 ТП-508 ТП-526 ц-608 ном-8 тп-207 тп-225 нз-39 ш-89 ш-97 стр-8
в поле max-1 символ тп-409 ТП-427 ТП-509 ТП-527 ц-609 ном-9 тп-208 тп-226 нз-40 ш-72 ш-98 стр-9
в поле мак- симальное числосим- волов тп-410 ТП-428 тп-510 тп-528 ц 610 ном- 10 тп-209 тп-227 нз-41 ш-73 ш-99 стр-10
Окончание iaon 4.Ь
Следующая кла- виша <□> <Ь> <Shtft> + <а> «Shift»+ «Ь> <т> <№» «ENTER» <ТАВ» BACK- SPACE» «DELETE» — <Н©МЕ> «LEFT ARROW»
Текущее входное состояние
кнопка поле OK Username пустое тп-411 тп-429 тп-511 тп-529 ц-611 НОМ- 11 тп-210 тп-228 нз-42 ш-74 ш-100 стр-11
поле Password пустое тп-412 тп-430 тп-512 тп-530 ц-612 ном- 12 тп-211 тп-229 нз-43 ш-75 ш-101 стр-12
неверное имя поль- зователя/ пароль тп-413 тп-431 тп-513 тп-531 ц-613 ном- 13 тп-212 тп-230 нз-44 ш-76 ш-102 стр-13
верное имя поль- зователя/ пароль тп-414 тп-432 тп-514 тп-532 ц-614 ном- 14 тп-213 тп-231 нз-45 ш-77 ш-103 стр-14
кнопка поле Cancel Username пустое тп-415 тп-433 тп-515 тп-533 ц-615 ном- 15 тп-214 тп-232 нз-46 ш-78 ш-104 стр-15
поле Password пустое тп-416 . тп-434 тп-516 тп-534 ц-616 ном- 16 тп-215 тп-233 нз-47 ш-79 ш-105 стр-16
неверное имя поль- зователя/ пароль тп-417 тп-435 тп-517 тп-535 ц-617 ном- 17 тп-216 тп-234 нз-48 ш-80 ш-106 стр-17
верное имя поль- зователя/ пароль тп-418 тп-436 тп-518 тп-536 ц-618 ном- 18 тп-217 тп-235 нз-49 ш-81 ш-107 стр-18
124
Глава 4
Преимущества. В этом формате тестовых таблиц дается указатель на отдельные
документы тестовых примеров. Такой интуитивно понятный указатель помогает пе-
редать то, как размещены все тестовые примеры, на которые были сделаны ссылки, в
общей схеме тестирования.
Недостатки. Нет гарантии завершенности тестового примера. То, будут ли тесто-
вые примеры, на которые сделаны ссылки, недвусмысленными и повторяемыми, за-
висит от способности тестера задавать полные тестовые примеры.
Формат тестовой таблицы № 4
Метод: для сочетания входных данных, дающих аналогичный результат, использу-
ется разбиение на классы эквивалентности.
В примере с диалоговым окном читателя, возможно, удивило то, что для каждого
нажатия буквенной/цифровой клавиши был составлен отдельный тестовый пример,
хотя очевидно, что поведение будет одним и тем же. Например, если поле Username
пустое, то разве имеет значение, какой символ будет введен первым: “а”, “б” или “ю”?
Поведение приложения будет одинаковым. Более того, аналогичное поведение мож-
но ожидать и при попытке ввести дополнительные символы в поле, которое уже пол-
ностью заполнено. Эта концепция, в которой различные входные значения приводят
к аналогичным результатам, известна как разбиение на классы эквивалентности.
В табл. 4.6 были введены классы эквивалентности путем объединения столбцов и
строк, в которых проверяются аналогичные условия; в результате размер таблицы
уменьшился и число тестовых примеров снизилось. В этом конкретном примере ис-
пользуется три различных типа классов эквивалентности:
• аналогичное нажатие клавиш;
• текущее состояние полей Username и Password;
• функция Cancel.
В перовом типе разбиения комбинируется нажатие клавиш, приводящее к анало-
гичным результатам. В одном классе эквивалентности содержатся все буквы нижнего
регистра, в то время как в другом — все буквы верхнего регистра. Можно возразить,
что входные данные для образца приложения диалогового окна нечувствительны к
изменению условий, следовательно, достаточно и одного класса эквивалентности, в
который будут входить буквы как верхнего, так и нижнего регистра. Можно также
возразить, что все входные данные в виде буквенно-числовых символов ведут себя
аналогично и есть возможность объединить буквы двух регистров и числа в одну
большую категорию. Решение о том, будут ли буквенно-числовые входные данные
разбиты на один, два или три класса эквивалентност и, принимается исходя из специ-
фических функциональных возможностей приложения.
Таблица 4.6. Использование классов эквивалентности для комбинирования аналогичных столбцов и строк
Следующая клавиша Клавиши верхнего регистра Числ а ^ Верные|| .'Л?' СИМВОЛЫ ные f хй-даЖЖЖ ... <ТАВ> «SACK- <DH£TE> <Н0№» cLEFT SPACE> ARROW»
Текущее входное
состояние
поле пустое поле
Username
от одного до max -1
символов
максимальное число
символов в поле
поле пустое поле
Password
от одного до max -1
символов
максимальное число
символов в поле
кнопка отсутствует имя
ОК пользователя или
пароль
неверное имя
пользователя/
пароль
верное имя
пользователя/
пароль
Кнопка Cancel
126
Глава 4
В различных операционных системах реализация связи клавиш и кнопок может
оказаться различной. В типичных приложениях, написанных для ОС Windows, на-
пример, нажатие символа “с” или “С”, когда активна кнопка Cancel, привело бы в ре-
зультате к тому, что приложение закрыло бы окно. Аналогично, нажатие клавиши “о”
или “О”, когда активна кнопка ОК, вызывает обработку имени пользователя и пароля
приложением. В такой ситуации тестер может либо задать отдельные классы эквива-
лентности для “с” и “С”, а также для “о” и “О”, либо объединить все буквенно-числовые
символы вместе, но отметить, что эти конкретные символы ведут себя так же, как кла-
виши <ENTER> и <SPACE>, когда активны кнопки Cancel или ОК соответственно. По-
скольку автор в этой главе стремится проиллюстрировать различные форматы таб-
лиц, все буквенно-числовые символы рассматриваются как один класс эквивалентности.
Всевозможные знаки, включая знаки пунктуации, группируются в две категории:
верные и неверные, поэтому теперь нужно задать содержимое каждой из этих катего-
рий. В примере с диалоговым окном в требованиях должно быть указано, что верное
имя пользователя может содержать символы !, & и -, откуда следует, что невер-
ными будут следующие символы: @, #, %, *, Л, “, (, ), [, ], {, }, /, ?, <, >, а также любые
другие символы, имеющиеся на клавиатуре. Верные символы для пароля могут отли-
чаться от тех, которые заданы для имени пользователя. Набор верных и неверных
символов должен быть задан в требованиях к приложению.
В некоторых классах эквивалентности содержится только один вариант нажатия
клавиш, например клавиша <ТАВ>, нажатие которой приводит к тому, что фокус пе-
репрыгивает с одного поля на другое, и клавиша <BACKSPACE>, с помощью которой
можно вытереть символ, введенный перед этим в поле Username или Password.
Тестеру может быть также полезно создать вспомогательный список нажатия кла-
виш нулевого оператора, которые попадают в их собственный класс эквивалентности.
Сюда входят клавиши, нажатие которых не вызывает изменений и, следовательно,
игнорируется или пропускается системой. Этот список может отличаться для различ-
ных входных условий, так что клавиши нулевого оператора для поля Username могут
отличатся от клавиш для кнопки Cancel.
При втором типе разбиения на классы эквивалентности обнаруживается, что для
примера с диалоговым окном слияние некоторых строк в таблице дополнительно со-
кращает пространство входов. При добавлении новых буквенно-числовых знаков в поле
Username приложение диалогового окна ведет себя одинаково и тогда, когда в по-
ле один, два или три символа. Поведение изменяется, когда превышается макси-
мальное число разрешенных символов. Это приводит к созданию трех классов экви-
валентности: одного — для пустого поля, другого — для максимального числа симво-
лов, а третьего — для любого другого числа символов, которое лежит между двумя
этими предельными значениями. Для категории кнопки ОК строки, соответствующие
пустому полю имени пользователя или пароля, объединяются в один класс эквива-
лентности под названием отсутствует имя пользователя или пароли Этот класс отлича-
ется от класса неверное имя пользователя/пароль тогда, когда и имя пользователя, и па-
роль содержат какой-то набор символов, но либо имя пользователя, либо пароль не-
верны.
Третье, и последнее разбиение на классы эквивалентности влияет на кнопку
Cancel. В связанных с этим разбиением тестах больше не учитывается содержимое
Использование электронных и обычных таблиц
127
золей Username и Password, поскольку здесь рассматривается выход из диалогового
окна. При задании команды Cancel тестер должен Цедиться, что значения имени
пользователя и пароля не обновлялись или не использовались каким-либо способом.
Заполнение остальной части таблицы осуществляется тем же способом, что и в
предыдущих форматах тестовых таблиц. В табл. 4.7 все буквенно-числовые символы
объединены в один класс эквивалентности, а также отражены различные методы за-
писи теста, что выражается в создании общего описания ожидаемых результатов
для некоторых тестов и в создании ссылок на полное описание тестовых примеров
для тех тестов, которые заданы где-то в другом месте. Еще один способ использования
этой таблицы заключается в регистрации информации, полученной в ходе выполне-
ния тестового примера и имеющей к нему отношение.
Вместо того чтобы использовать матричный подход, в котором условия тестов за-
даются строками и столбцами, можно так видоизменить формат тестового примера,
чтобы каждый отдельный столбец описывал свой входной параметр и был связан с
.оответствующими результатами. В табл. 4. задано начальное состояние для каждого
тестового примера. Задано как содержимое полей Username и Password, так и поло-
жение курсора. Тестер должен будет нажать клавиши, указанные в столбце “Входные
данные”, а затем записать реальные результаты в последний столбец.
Преимущества. Предоставляя более детальную информацию о содержимом полей
ввода диалогового окна, описание становится более полным и такие тесты можно бу-
дет точно воспроизвести.
Недостатки. При одностроковом подходе сложнее определить, какие условия
тестов отсутствуют. Создание таблицы такого формата не гарантирует, что тесты бу-
дут заданы хорошо. Для сравнения, матричный формат дает возможность быстро ус-
тановить тип тестируемых условий. Тестер отвечает за предоставление адекватной
информации для создания всестороннего описания тестового примера.
Сокращения в тестовой документации
В большей части представленных на данный момент тестовых таблиц перечисля-
лись варианты входных данных. Для некоторых приложений этой информации
вполне достаточно, чтобы начать выполнение тестов. Аналогично схеме тестового
примера, можно получить общее представление о том, что будет тестироваться без
дополнительной информации.
Тестовая таблица помогает отслеживать очень важную информацию, включая тес-
товые входные данные, ожидаемые результаты и статус тестов. Использование со-
кращений в документации дает возможность включить в структуру таблицы важную
информацию. Сокращения позволяют уменьшить количество информации, записы-
ваемой для каждого тестового примера, но не дают возможности уменьшить число
выполняемых тестовых примеров.
Таблица 4.7. Формат тестовой таблицы № 4: задание
предполагаемого поведения теста при использовании классов эквивалентности
Букпенно- числовыс клавиши Верные символы Неверные символы <EMTER> <ТАВ> «BACKSPACE» <сеше> <НОМЕ> Клавиши ... стрелок
Текущее входное состояние
поле пустое поле User- name добавля- ется символ добавля- ется символ ошибка: неверный символ тп-1100 переход в поле Password без измене ний у-37 без изме- нений тп-567
от одного до max-1 символов добавля ется символ добавля- ется символ ошибка: неверный символ тп 1101 переход в поле Password удаляется символ слева у-36 переход в начало поля Username тп-568
максимальное число символов в поле символ игнориру- ется: без изменений символ игнориру- ется: без изменений ошибка: неверный символ тп-1102 переход в поле Password удаляется символ слева у-35 переход в начало поля Username тп-569
поле пустое поле Pass- word добавля- ется символ добавля- ется символ ошибка: неверный символ тп-1103 переход к кнопке ОК без измене- ний у-34 без изме- нений тп-570
от одного до max -1 символов добавля- ется символ добавля- ется символ ошибка: неверный символ тп-1104 переход к кнопке ОК удаляется символ слева у-33 переход в начало поля Password тп-571
максимальное число символов в поле символ игнориру- ется: без изменений символ игнориру- ется: без изменений ошибка: неверный символ тп-1105 переход к кнопке ОК удаляется символ слева у-32 переход в начало поля Password тп-572
Окончание таол.4./
Букиенно- ч меловые клавиши Верные символы Неверные СИМВОЛЫ <ENTER> <ТАВ> «BACKSPACE» «DELETE» «НОМЕ» Клавиши — стрелок
Текущее входное состояние
кнопка отсутствует без изме- без изме- без изме- ошибка: переход без измене- без без изме- без из-
ОК имя пользователя или пароль нений нений нений отсутст- вует имя пользо- вателя или пароль к кнопке Cancel ний измене- ний нений менений
неверное имя без изме- без изме- без изме- ошибка: переход без измене- без без изме- без из-
пользователя/ пароль нений нений нений неверное имя пользо- вателя/ пароль к кнопке Cancel ний измене- ний нений менений
верное имя без изме- без изме- без изме- тп-1107 переход без измене- без без изме- без из-
пользователя/ пароль нений нений нений к кнопке Cancel ний измене- ний нений менений
Кнопка Cancel без изме- без изме- без изме- выход переход без измене- без без изме- без из-
нений нений нений из окна в поле Username ний измене- ний нений менений
130
Глава 4
Таблица 4.8. Формат таблицы № 5: каждый тестовый пример в отдельной строке
Начальное состояние* '
Pass word Место сложение курсора- Входные 5данные ^Ъжидаемые'^^ Реальные результаты результаты т
тп-401 (пусто) (пусто) курсор находится в поле Username а в поле Username появляется "а"
тп-402 м (пусто) курсор находится за *м’ в поле Username б в поле Username появляется "мб"
тп-403 жасмин (пусто) курсор находится за 'ж' в поле Username а в поле Username появляется "жаасмин"
тп-404 джолуис (пусто) курсор находится в конце поля Username 2 нажатие клави- ши игнорируется (превышено максимальное
число симво- лов): без изменений
тп-405 Фрэд xyz88 курсор находится за 'д’ в поле Username № ошибка: система подает один зву- ковой сигнал
и отправление
в строку состоя-
ния "неверный
символ"
Чтобы проиллюстрировать различные подходы к документации, к тестам, пока-
занным в табл. 4.8 (которая может включать до 90 тестовых примеров), будут приме-
нены все описанные сокращения. Для каждого сокращения результаты тестов будут
записываться единообразно, так что один и тот же тестовый пример в каждом методе
сокращений будет иметь один и тот же статус. Таким образом, из 90 тестовых приме-
ров четыре имеют статус “провалился”, 12 не были проведены, а остальные тестовые
примеры были успешными. При использовании сокращений описание тестовых
входных данных расплывчато и ожидаемые результаты отсутствуют. Важно, чтобы
тестер достаточно хорошо понимал поведение системы и мог решить, пройден тест
или провален. Выбор сокращения зависит от того, какой тип и объем информации
записывается в каждую ячейку таблицы.
Таблица 4.9. Результаты тестовых примеров, используемые при сокращении документации
Буквснно- Верные Неверны*. <ENTER> <ТАВ> •гВАСК- <D€LETE> <НОМЕ> Клавиши
числовые символы СИМВОЛЫ > J: * •* SPACE» стрелок
клавиши • к а -А * Г*
Текущее входное состояние -У-; к-г у е
поле пустое поле Username прошел прошел прошел прошел прошел прошел не выполнялся прошел прошел
от одного до max-1 символов прошел прошел прошел прошел прошел прошел не выполнялся прошел прошел
максимальное прошел прошел прошел прошел прошел прошел не выполнялся прошел прошел
число символов
в поле
поле пустое поле прошел прошел прошел прошел прова- прошел не выполнялся прошел прошел
Password лился
от одного до max -1 символов прошел прошел прошел прошел прошел прошел не выполнялся прошел прошел
максимальное число символов в поле прошел прошел прошел прошел прошел прошел не выполнялся прошел прошел
кнопка отсутствует имя ОК пользователя прошел прошел прошел прошел прошел прошел не выполнялся прошел прошел
или пароль неверное имя не выпол - прошел не выпол- прошел прова- прова- не выполнялся прошел прошел
пользователя/ пароль нялся нялся лился лился
верное имя прошел не выпол- прошел прошел прошел прошел прошел прошел прошел
пользователя/ пароль нялся
Кнопка Cancel прошел прошел прошел прошел прошел прова- не выполнялся прошел прошел
ЛИЛСЯ
132 Глава 4
Сокращения — это не обязательно плохо, принимая во внимание, что все преды-
дущие действия, касающиеся тестирования, могли быть бессистемными, хаотичными,
недокументированными и невоспроизводимыми. Основная философия этой книги
заключается в том, что лучше располагать хоть какой-то документацией, чем вообще
ее не иметь. Благодаря документации обеспечивается подходящий фундамент для на-
чала работ по тестированию, что в конечном счете улучшит процесс тестирования.
При каждом сокращении делается акцент на различные уровни детализации.
Сокращение № 1
Сокращение № 2
Сокращение № 3
Сокращение № 4
Сокращение № 5
Проверяется каждый блок, чтобы определить, пройден тест или
провален.
Записываются клавиатурные комбинации, используемые для
запуска тестов.
Записываются реальные результаты.
Отмечаются тесты, которые были пройдены, а для тестов,
которые провалились, записываются номера отчетов
о проблемах.
Сочетаются и объединяются методы записи-сохранения
из предыдущих сокращений путем записи любой информации,
которая считается важной.
Сокращение № 1
Метод: проверяется каждый блок, чтобы определить, пройден тест или провален.
В табл. 4.10 каждый пройденный тест помечается J. Провалившиеся тесты поме-
чены символом *, а пустые ячейки соответствуют тестам, которые не выполнялись.
Конечно, вместо контрольной метки и креста можно использовать слова “пройден” и
“провален”. Это дает возможность сразу увидеть, какие тесты запускались.
Если тест выполняется повторно, то тестер может записать результаты последую-
щих тестов поверх предыдущих записей или цветовых пометок.
Преимущества. Есть запись о том, какие реализовывались ситуации и условия.
Можно легко увидеть, какие тесты были пройдены, а какие провалились.
Недостатки. Нет записи об используемых реальных входных значениях или об
ожидаемых и наблюдаемых результатах. Нельзя воспроизвести тест, поскольку не за-
писывается начальное состояние и клавиши, используемые для ввода. Нет четкого
определения ожидаемых результатов и, следовательно, о прохождении теста прини-
мает решение тестер.
Сокращение № 2
Метод: записываются клавиатурные комбинации, используемые для запуска тестов.
В табл. 4.11 для каждого выполняемого теста отслеживается информация о на-
жатии клавиш. Некоторые из входных условий теста (например, нажатие буквенно-
числовых клави п) также записываются более подробно. Для верных и неверных кла-
виш будет использоваться тот список, который был представлен в формате тестовой
таблицы № 4. Пустые ячейки указывают на тесты, которые не выполнялись. Информация
Использование электронных и обычных таблиц
133
о провалившихся тестах может записываться в журнале ошибок или регистрировать-
ся в системе отчетов о проблемах.
Преимущества. Есть запись о нажимаемых клавишах, которые используются для
реализации каждого условия. Если записано достаточное количество информации, в
особенности о предыдущем состоянии полей ввода, то тестовый пример можно будет
воспроизвести.
Недостатки. В этой таблице не регистрируется прохождение каждого теста. Для
многих тестов не указывается предыдущее содержимое полей. Не записываются на-
блюдаемые результаты. Некоторые тесты нельзя воспроизвести из-за недостатка ин-
формации. Для столбцов, в которых задается нажатие только одной клавиши
(например, <ENTER> и <BACKSPACE>), отображение нажатых клавиш не дает какой-
либо полезной информации, кроме утверждения, что тест был выполнен. Нет четко-
го определения ожидаемых результатов и, следовательно, факт прохождения теста
устанавливается по усмотрению тестера.
Сокращение № 3
Метод: записываются реальные результаты.
В табл. 4.12 тестер записывает результаты с различной степенью детализации. Ка-
ждый элемент под неверным символом констатирует, что при введении определенно-
го символа произошла ошибка. Для тестов, в которых ожидается наличие сообщения
об ошибке, в результатах воспроизводится сообщение об ошибке, отправленное при-
ложением. Когда ответ приложения не согласуется с ожидаемым, вместе с реальным
результатом ставится пометка ПРОВАЛИЛСЯ. В этой ситуации ожидаемое сообще-
ние об ошибке должно отличаться от реальных ошибок приложения.
Преимущества. Записываются реальные результаты.
Недостатки. Нет записи об используемых входных данных, даже если эта инфор-
мация иногда может быть получена из записанных результатов. Некоторые тесты
нельзя воспроизвести из-за недостатка информации, в особенности когда не было за-
дано предыдущее состояние. Например, нажатие левой или правой стрелки приведет
к различным результатам в зависимости от текущего положения курсора. Аналогично,
клавиша <DELETE> удалит символ, только если курсор находится слева от сущест-
вующего символа; символы не будут вытираться, если курсор находится в правом кон-
це поля ввода. Провалившиеся тесты не указываются, поэтому неизвестно, согласуют-
ся ли реальные результаты с ожидаемыми.
Сокращение № 4
Метод: отмечаются тесты, которые были пройдены, а для тестов, которые прова-
лились, записываются номера отчетов о неполадках.
В табл. 4.13 каждый тест, который был пройден, помечен контрольной меткой.
Провалившиеся тесты регистрируются в системе отслеживания неполадок, а в тесто-
вой таблице записывается ссылка на соответствующий отчет Пустые ячейки означа-
ют, что тест не выполнялся. Это дает возможность с первого взгляда определить об-
щее состояние выполнения тестов.
Таблица 4.10. Сокращение № 1: регистрация прохождения теста
1 Неверные .<ENTER> <TAB> «BACK- <DELETE> <HOME> Клавиши .
-ЖЖ. » “ : ! Числовые (ы клавиши символы ц SPACE> : : в4 •”хтреЙр<Ж
ЖЯК ?. ;
поле пустое поле Z z z ✓ z ✓
Username
от одного до max -1 Z ✓ ✓ z z z ✓ ✓
символов
максимальное число Z Z z ✓ ✓ ✓ z ✓
символов в поле
поле пустое поле ✓ ✓ z ✓ X ✓ z ✓
Password
от одного до max -1 ✓ ✓ ✓ z ✓ ✓ ✓ ✓
символов J
максимальное число Z Z z z z / z ✓
символов в поле
кнопка отсутствует имя Z Z z ✓ z J ✓ ✓
ОК пользователя
или пароль
неверное имя ✓ ✓ X X z ✓
пользователя/пароль
верное имя ✓ z ✓ z ✓ ✓ z Z
пользователя/пароль
Кнопка Cancel Z Z ✓ z z X z z
Таблица 4.11. Сокращение № 2: запись клавиш, используемых для ввода
Буквенно- Верные Невернью <ENTER> <ТАВ> <ВЛСК- <DELETE> <НОМЕ> Клавиши *" Ли» я . •'* МВОГп! ГНГ1В _я iPACt , ьлок s " клавиши , ' ' ‘ ‘ &*
, ’ 8 В к , » ♦ . .ч 114 ^-‘-Г .»1 » Теку1 .. '' ное с nie к " л,’_* s" ' ” ж ч я ® ® ’ я
поле Username пустое поле <а> <$> <@> <ENTER> <TAB> <BACK- SPACE> <HOME> вправо
от одного до max -1 символов <Б> <-> <?> <ENTER> <TAB> <BACK- SPACE> <HOME> вверх
максимальное число символов в поле <2> <_> <%> <ENTER> <TAB> <BACK- SPACE> <HOME> вправо
поле Password пустое поле <Ф> <&> <л> <ENTER> <TAB> <BACK- SPACE> <HOME> вверх
от одного до max -1 символов <3> <!> <(> <ENTER> <TAB> <BACK- SPACE> <HOME> вниз
максимальное число символов в поле <и> <-> <@> <ENTER> <TAB> <BACK- SPACE> <HOME> влево
кнопка ОК отсутствует имя пользователя или пароль неверное имя пользователя/пароль <н> <$> <-> <[> <ENTER> <ENTER> <TAB> <TAB> <BACK- SPACE> <BACK- SPACE> <HOME> <HOME> вверх вниз
верное имя пользователя/пароль <Ж> </> <ENTER> <TAB> <BACK- SPACE> <HOME> вправо
Кнопка Cancel <й> <&> <?> <ENTER> <TAB> <BACK- SPACE> <HOME> вниз
Таблица 4.12. Сокращение № 3: запись реальных результатов
Верные С ЙЙ MbH <1 ЙТЕЛ> « 3-» <ВАСК- жАСЕь » <DELETE> <НОМЕ>
Текущее входное
состояние
поле пустое добавля- добав- ошибка ошибка: переход без изме- без изме- без изме-
Username поле ется 'а' ляется '<§>' отсутствует в поле нений нений нений:
имя Password вправо
пользователя
от одного добавля- добав- ошибка'?' обработка переход удаляется переход без изме-
до max -1 ется 'Б' ляется имени поль- в поле предыду- в начало нений:
символов 1 1 зователя/ Password щий сим- поля вверх
пароля вол
максима- добавля- добав- ошибка обработка переход удаляется переход без изме-
льное ется '2' ляется '%' имени поль- в поле предыду- в начало нений:
число 1 г зователя/ Password щий сим- поля вправо
символов пароля вол
в поле
поле пустое добавля- добав- ошибка ,л' ошибка: ПРОВАЛИЛ- без изме- без изме- без изме-
Password поле ется 'Ф' ляется отсутствует ся: переход нений нений нений:
пароль к кнопке Cancel вверх
от одного добавля- добав- ошибка'(' обработка переход удаляется переход без изме-
до max -1 ется '3' ляется'!' имени поль- к кнопке ОК предыду- в начало нений:
символов зователя/ щая поля вниз
пароля
максима- добавля- добав- ошибка обработка переход удаляется переход переме-
льное ется 'и' ляется '<§>' имени поль- к кнопке ОК предыду- в начало щение
число - зователя/ щая поля влево
символов пароля
в поле
Окончание lauii ‘1.12
Буквенно- Верные Неверные <ENTER> <ТАВ> «BACK- «DELETE» <НОМЕ> Клавиши
числовые СИМВОЛЫ СИМ*0ЛЬ. SPACE» стрелок
клавиши
Текущее входное
состояние
кнопка отсутст- без изме- без без изме- ошибка: без изме- без изме- без измене-
ОК вуетимя нений 'н' измене- нении:'[' отсутствует нений нений ний вверх
пользова- ний: имя
теля или пользователя
пароль неверное без ошибка: ПРОВА- ПРОВА- без изме- без измене-
ИМЯ ПОЛЬ- измене- неверный ЛИЛСЯ ЛИЛО, нений ний вниз
зователя/ ний: пароль фокус не получено
пароль изменился сообщение "неверный символ"
верное без изме- без изме- принимается переход без изме- без из- без изме- без измене-
имя поль- нений: 'Ж' нений:'/' пользо- к кнопке нений менений нений ний: вправо
зователя/ вателя/ Cancel
пароль пароль
Кнопка Cancel без изме- без без изме- выход переход ПРОВА- без изме- без измене-
нений: 'й' измене- нений:'?' из окна в поле ЛИЛСЯ: нений ний: вниз
ний: '&' Username выход из окна
Таблица 4.13. Сокращение № 4:
отмечаются пройденные тесты, а для провалившихся тестов показываются отчеты о проблемах
- Буквенно- Верные ’ числовь1е символы клавиши •> ЖЙЙФ СИМВОЛЫ <ENTER> <ТАВ> сВАСК- SPAC&» <ОЫЕТЕ> <НОМЕ> Клавиши ^сгрелок§^
Текущее входное состояние
поле пустое поле ✓ ✓ ✓ ✓ ✓ ✓
Username
от одного до max-1 ✓ ✓ ✓ ✓ ✓ ✓ / /
символов -
максимальное число ✓ ✓ ✓ ✓ ✓ /
символов в поле
поле пустое поле ✓ / ✓ ✓ он ✓ •/
Password № 221
от одного до max -1 ✓ ✓ ✓ ✓ ✓ ✓ /
символов
максимальное число ✓ ✓ ✓ ✓ ✓ / /
символов в поле
кнопка отсутствует имя поль ✓ ✓ ✓ ✓ ✓ ✓ </ /
ОК зователя или пароль
неверное имя пользе ✓ ✓ ОН ОН № 65 /
вателя/пароль №103
верное имя пользе- ✓ ✓ ✓ ✓ ✓ ✓
вателя/пароль
Кнопка Cancel ✓ / / ОН № 47 /
Использование электронных и обычных таблиц
139
Преимущества. Есть запись о том, какие ситуации и условия были реализованы.
Фиксируются наблюдаемые результаты для каждого провалившегося теста. Можно
'егко увидеть тесты, которые не выполнялись.
Недостатки. Сама по себе таблица тестовых примеров не описывает входных
данных или наблюдаемых результатов. Тесты, которые были пройдены, нельзя вое-
дроизвести, поскольку не отслеживалась информация относительно начального со-
гояния и клавиш, нажимаемых для ввода. Однако информация о провалившихся тес-
тах документирована в соответствующих отчетах и есть запись, связанная с описани-
ем входных данных (предполагается, что описание отчета о неполадках полное). Нет
четкого определения ожидаемых результатов и, следовательно, факт прохождения
станавливается по усмотрению тестера.
Сокращение № 5
Метод: сочетаются и объединяются методы записи\сохранения из предыдущих
сокращений путем записи любой информации, которая считается важной.
Полученная информация записывается в различных форматах, которые могут
включать в себя следующие данные.
1. Тест не был выполнен:
• ячейка пустая.
2- Тест был пройден:
• отметка 'ф
• запись используемых клавиш;
• указание предыдущего состояния;
• запись реальных результатов.
3. Тест провалился:
• отметка *;
• запись только реальных результатов;
• запись ожидаемых и реальных результатов;
• ссылка на номер отчета о неполадках.
Уровни информации, показанные в табл. 4.14, несогласованны. Для пройденных
тестов тестер поставил метку J, в то время как для других были записаны реальные
результаты. Если нет никаких указаний со стороны руководства, тестер не будет запи-
сывать информацию согласованно.
Таблица 4.14. Сокращение № 5: запись важной информации
и -Ху \ v Буквенно- числовые клавиши Верные , Неверные „СИМВОЛЫ^!; символы ... <ENTER> fem 23g/ . у> fe:. <ВАСК- SPACE> <DELE- ТЕ> <НОМЕ> Клавиши ... стрелок
Текущее входное состояние у » "asJF " у ".... 7 .....3.2 . 3 -23 'УУ<“ .
поле Username пустое поле от одного до max -1 символов добавляется 'а' предыдущее ИМЯ = Джордж, курсор после 'р', печатает- ся 'Б' добавляется добавляется 1 _ 1 ошибка ошибка'?’ ошибка: от- сутствует имя пользователя имя пользо- вателя = В пароль = тест2 ✓ ✓ ✓ первый символ = "У <ВАСК- SPACE> удаляет 'У' без изме- нений переход в начало поля без изме- нений: вправо без изме- нений: вверх
максималь- ное число символов в поле курсор после первого символа, пе- чатается '2' добавляется < < ошибка '%' имя пользо- вателя = тест1234, кур- сор находит- ся между символами 'ст' ✓ курсор пе- ред первым символом, ничего не удаляется переход в начало поля без изме- нений: вправо
поле Password пустое поле добавляется -ф’ добавляется ошибка ошибка: от- сутствует па - роль ПРОВАЛИЛСЯ: активная об- ласть пере- местилась к имени пользо- вателя вместо кнопки ОК ✓ без изме- нений без изме- нений: вверх
от одного до max -1 символов xyz+3 добавляется ошибка 'С обработка имени поль- зователя/ пароля ✓ первый символ = 'У' <ВАСК- SPACE> переход в начало поля без изме- нений: вниз
удаляет
( 'A < HI 1,1111 lr /. II ,11 III
Буквенно- числовые клавиши Верные символы Неверные <£NTER> <ТАВ> символы <ВАСК- SPACfc» •сен- <номе> ТЕ> Клавиши стрелок -
Текущее входное состояние —
максималь- СэмСпейд + добавляется ошибка обработка ✓ удаляется переход переме-
ное число И имени поль- предыдущая в начало щение
символов зователя/ поля влево
в поле пароля
кнопка отсутствует без измене без измене- без изме- ошибка: от- ✓ ✓ без изме- без изме-
ОК имя пользе- ний: н ний: нений:'[' сутствует имя нений нений:
вателя или пользователя вверх
пароль
неверное имя без измене- ошибка: X X без изме- без изме-
пользователя/ ний: неверный нений нений:
пароль пароль вниз
верное имя без измене- без изме- принимается / ✓ ✓ без изме- без изме-
пользователя/ ний: 'Ж' нений:'/' имя пользе- нений нений:
пароль вателя/ вправо
пароль
Кнопка Cancel без измене- без измене- без изме- ВЫХОД ✓ X без изме- без изме-
ний: 'й' ний нений:'?' из окна нений нений:
вниз
142
Глава 4
Одним из способов указания предыдущего состояния является использование за-
писи типа “абв + г”, которая означает, что был добавлен символ “г”.
Преимущества. В зависимости от усердия тестера можно получить исчерпываю-
щую тестовую документацию. Есть возможность записать достаточное количество
информации так, чтобы воспроизвести тесты. Можно быстро определить, какие тес-
ты были выполнены.
Недостатки. Сокращение количества записываемой информации может привести
к тому, что тесты нельзя будет воспроизвести. Несогласованный способ записи ин-
формации усложняет оценку статуса тестов.
До настоящего момента таблицы тестов помогали обнаружить большую часть, но
не все входные комбинации. Во-Первых, физически невозможно перечислить все тес-
товые примеры, в особенности когда комбинаторный анализ обнаруживает астроно-
мическое число потенциальных тестов. Во-вторых, если в таблице были пропущены
важные категории, то связанные с ними тесты не будут рассматриваться. Наконец,
тестер должен знать, что невозможно запустить все тесты либо из-за объема тестов,
либо из-за ограниченности доступного времени. Действительность такова, что тестер
никогда не запустит абсолютно все тестовые примеры. Осознание этой суровой реаль-
ности делает еще более важным написание четко заданных и целевых тестовых при-
меров. Одна из тактик заключается в предоставлении более подробных тестовых
примеров, так, чтобы были хорошо заданы входные данные.
Подробные описания тестов
Использование показанных ранее таблиц для документирования и записи о вы-
полнении тестов позволяет обойти надлежащее описание тестовых примеров, по-
скольку в них содержатся неоднозначные входные условия. При этом возникает риск
невозможности воспроизвести тест одним и тем же способом. В хорошем тестовом
примере для тестируемого элемента должны быть заданы входные условия теста, ус-
ловия выполнения и предполагаемые результаты [IEEE 610.12], а также предыдущее и
последующее состояние всех данных, будь то буфера, содержимое памяти, пакеты
данных, дампы экрана или другие объекты, содержащие данные. В среде GUI в пол-
ном определении тестового примера описывается текущее состояние, включая со-
держимое всех полей и любые другие заданные состояния и переменные. Рассмотрим
все возможные вопросы, сопутствующие введению буквы “а” в поле Username.
• Было ли это поле пустым перед введением символа “а”?
• Нужно ли очищать это поле, чтобы испытать следующие тестовые входные
данные?
• Есть ли пространство впереди?
• Зависит ли этот тест от данных, которые были введены в других диалоговых
окнах?
В хорошем тестовом примере содержится достаточно подробностей, чтобы мож-
но было избежать всех неожиданностей. Тестовые таблицы, созданные ранее в этой
главе, составляют основу для разработки более полных тестов путем создания таблиц
Использование электронных и обычных таблиц 143
контрольных проверок входных условий, которые должны быть реализованы.
В табл. 4.15 перечислены требования к тестированию, на основе которых будут созда-
ваться тестовые примеры для тестирования примера с диалоговым окном. Поскольку
теперь каждая ячейка задает специфические тестируемые условия, то они будут рас-
сматриваться как набор требований к тестированию, а каждая ячейка будет помечена
"ТТ-№”, где “ТТ” — это аббревиатура требования к тестированию. Пока этот идентифи-
катор уникален, неважно, какими будут префикс и значение, и следуют ли они в ка-
ком-либо определенном порядке.
Такой тип таблиц помогает прослеживать преобразование требований к тестам
в тестовые примеры и наоборот. Например, из таблицы становится известно, что в
требовании ТГ-200 реализуется событие, которое заключается в нажатии клавиши
«BACKSPACES в пустом поле Username. Любые тестовые примеры, которые ссылают-
ся на ТТ-34, означают, что в тесте в непустом поле Password, где, однако, не содер-
жится максимальное число символов, помещается неверный знак. Ссылки на требо-
вания к тестам становятся составляющей документации тестового примера и именно
тестер отвечает за подтверждение того, что эти ссылки корректны.
Следующая задача заключается в задании подробных тестов, содержащих много
этапов, каждый из которых охватывает отдельное условие теста. Эти всесторонние
описания тестов, или тестовые процедуры, содержат ряд небольших тестовых при-
меров, которые должны быть успешно выполнены в заранее установленном порядке.
Тестовая процедура, как было определено институтом IEEE, “задает этапы выпол-
нения набора тестовых примеров или, в более общем смысле, этапы, используемые
для анализа элемента программного обеспечения для того, чтобы оценить набор
функций” [IEEE 829]. Это можно выразить иначе: наличие подробного сценария тес-
та с несколькими этапами и промежуточными результатами. Для перехода к следую-
щему внутреннему этапу большого сценария теста необходимо, чтобы предыдущий
этап был пройден успешно. Таким образом, тестовый пример — это комбинация спе-
цифических входных данных и ожидаемых результатов, в то время как тестовая про-
цедура представляет собой перечень большого числа этапов со своими входными
данными, каждый из которых имеет свои промежуточные ожидаемые результаты.
В современной промышленности использование терминов тестовый пример и тес-
товая процедура весьма противоречиво, иногда эти термины используют попеременно.
Если разница между данными терминами кажется абсурдной, нужно сконцентриро-
ваться на основной задаче: обеспечить ясное описание входных данных и ожидаемых
результатов. Если тестер и организация согласовали терминологию, то не имеет зна-
чения, какие термины используются. Когда же подходы к тестам и форматы докумен-
тации у организаций отличаются, то должен быть локальный словарь. В идеале, было
бы неплохо, если бы все тестеры в индустрии производства программного обеспече-
ния могли ссылаться на общие определения. Чтобы не обидеть кого-нибудь из сто
ронников пуризма, здесь будет использоваться слово тест, определение которого дал
институт IEEE:
набор, состоящий из одной или нескольких тестовых процедур;
набор, состоящий из одного или нескольких тестовых примеров и процедур
[IEEE 829].
144
Глава4
Таблица 4.15. Таблица требований к тестам
Ду ''; Z' If Буквенно- числовые клавиши Верные Неверные символы «ENTER» <ТАВ> '' '' '1
Текущее входное’" ”:: У" * состояние
поле Username пустое поле П-1 П-11 П-30 П-45 П-100
от одного до max -1 символов П-2 П-12 П-31 П-46 П-101
максимальное число символов в поле тт-з П-13 П-32 П-47 П-102
поле Password пустое поле П-4 П-14 П-33 П-48 П-103
от одного до max -1 символов П-5 П-15 П-34 П-49 П-104
максимальное число символов в поле ТТ-6 П-16 П-35 П-50 П-105
кнопка ОК отсутствует имя пользователя или пароль П-7 П-17 П-36 П-51 П-106
неверное имя поль- зователя/пароль П-8 П-18 П-37 П-52 П-107
верное имя пользо- вателя/пароль П-9 П-19 П-38 П-53 П-108
Кнопка Cancel П-10 П-20 П-39 П-54 П-109
Следующий пример применятся к образцу диалогового окна. Здесь показана сте-
пень детализации, которую могут использовать тестеры при задании тестов. Для бо-
лее сложных систем такого рода подход может помочь выбрать и документировать
соответствующий вариант тестирования. Независимо от типа или сложности прило-
жения, основные концепции задания входных данных и промежуточных результатов
остаются теми же.
Использование электронных и обычных таблиц
145
-ВАСК-| АСЕ> «DELETE- <5РАСЕ> <F1> <ALT> + <a> Клавйши нулевого W оператора <НОМЕ> 1 Клавиши — стрелок
а ж ж «
Т200 П-210 тт-зоо ТТ-310 П-320 тт-ззо П-400 П-500
Т-201 П-211' ТТ-301 П-311 ГТ-321 П-331 П-401 П-5001
Т-202 П-212 П-302 П-312 П-322 П-332 П-402 П-502
Т-203 П-213 тт-зоз ТТ-313 П-323 П-333 П-403 П-503
Т-204 П-214 П-304 П-314 П-324 П-334 П-404 П-504
Т-205 П-215 П-305 П-315 П-325 П-335 П-405 П-505
~-206 П-216 ТТ-306 ТТ-316 П-326 П-336 П-406 П-504
~-207 П-217 П-307 П-317 П-327 П-337 П-407 П-507
”208 П-218 П-308 П-318 П-328 П-338 П-408 П 508
~-209 П-219 П-309 П-319 П-329 П-339 П-409 П-509
В табл. 4.16-4.18 заданы подробные тесты труктура этих тестов следующая. t для примера с диалоговым окном.
естовая процедура
Это уникальный идентификатор. Префикс ГТ (сокращение
от “тест графического интерфейса”) выбран произвольно
для отождествления этой процедуры с тестом
для диалогового окна.
Начальная конфигурация диалогового окна задается либо
путем описания содержимого диалогового окна, либо
тестеры запускают специальный сценарий, который
заполнит диалоговое окно так, чтобы оно находилось
в известном состоянии.
Начальные настройки
Этап
Помечается каждая отдельная часть тестовой процедуры.
146
Глава 4
Требования к тесту Для прослеживаемости между тестовой таблицей и тестовой процедурой задается определенное требование к тестам, которое будет реализовано на данном этапе.
Входные данные Ожидаемые промежуточные результаты Реальные результаты Описываются клавиши, которые будет нажимать тестер. Описываются ожидаемые результаты, которые должны быть получены после ввода соответствующих входных данных. Выполнение данного этапа указывает на то, был ли тест запущен успешно. Фиксируются наблюдаемые неожиданности в поведении приложения.
Таблица 4.16. Тестовая процедура на основе тестовых примеров для диалогового окна
а
установки: и
'• я „ & “ Реальные результаты' . > .
1 ТТ-1 Набрать: 'с' в поле Username появляется 'с'
2 ТТ-2 Набрать: 'ам' в поле Username появляется 'сам'
3 ТТ-ЗО1 Набрать: знак пробела в поле Username появляется 'сам'
4 ТТ-1О1 Нажать клавишу <ТАВ> курсор перемещается в поле Password
5 ТТ-4 Набрать: 'х' в поле Password появляется '*'
6 ТТ-5 Набрать: '5у' в поле Password появляется '***'
7 ТТ-334 Нажать <CTRL>-<A> без изменений
8 ТТ-49 Нажать клавишу <ENTER> принимается пара значений имя
пользователя/пароль
Использование электронных и обычных таблиц
147
Таблица 4.17. Еще одна тестовая процедура
на основе тестовых примеров для диалогового окна
Тестовая . процедура: ГТ-4Й' '
Начальные Запустить установочный сценарий lnlt_user_iist.sci .. 'г" а
Этап Входные данные Ожидаемые промежуточные Реальные результаты результаты
1 тт-зоо Набрать: символ’ пробела Курсор перемещается в поле Username на один промежуток вправо
2 ТТ-2 Набрать: 'Д' В поле Username появляется 'Д'
3 ТТ-2 Набрать: 'жонк' В поле Username появляется 'Джон к'
4 ТТ-311 Нажать клавишу <F1> Курсор перемещается в конец поля Username
5 — Выйти из окна справки Курсор находится в конце поля Username
6 ТТ-501 Нажать левую стрелку Курсор перемещается на один промежуток влево
7 ТТ-211 Нажать клавишу <DELETE> В поле Username появляется 'Джон'
8 ТТ-2 Набрать: 'смит' В поле Username появляется 'Джонсмит'
9 ТТ-3 Набрать: 'у' Символ игнорируется: нельзя превысить максимальное число символов
10 ТТ-47 Нажать клавишу <ENTER> Сообщение об ошибке: отсутствует пароль
11 ТТ-322 Нажать <ALT>- <а> Курсор перемещается в поле Password
12 ТТ-4 ТТ-5 Набрать: 'клавиш13' В поле Password появляется «********'
13 ТТ-6 Набрать: 'з' Символ игнорируется: нельзя превысить максимальное число символов
14 ТТ-105 Нажать клавишу <ТАВ> Фокус перемещается на кнопку ОК
15 ТТ-52 Нажать клавишу <ENTER> Сообщение об ошибке: неверный пароль
148 Глава4
Таблица 4.18. Третья тестовая процедура
на основе тестовых примеров для диалогового окна
Тестовая процедура: ГТ-412
Начальные установки: В11пслнитъ тестовую процедуру ГТ-307
Этап Требования к тесту Входные данные Ожидаемые промежуточные результаты Реальные результаты
1 ТТ-1 Набрать: '6' “В поле Username появляется '6'
2 ТТ-2 Набрать: '8' В поле Username появляется '8'
3 ТТ-401 Нажать клавишу <НОМЕ> Курсор перемещается в начало поля Username
4 ТТ-2 Набрать: 'Л' В поле Username появляется 'Л68'
5 ТТ-101 Нажать клавишу <ТАВ> Курсор перемещается в поле Password
6 ТТ-103 Нажать клавишу <ТАВ> Фокус перемещается на кнопку ОК
7 ТТ-106 Нажать клавишу <ТАВ> Фокус перемещается на кнопку Cancel
8 ТТ-109 Нажать клавишу <ТАВ> Курсор перемещается в конец поля Username
9 ТТ-2 ТТ-3 Набрать: 'МИЛЛЕР' В поле Username появляется 'Л68МИЛЛЕ'; нельзя превысить максимальное число символов
10 ТТ-322 Нажать <ALT>-<a> Курсор перемещается в поле Password
11 ТТ-323 Нажать <ALT>-<a> Без изменений
12 ТТ-4 Набрать: 'ГТ В поле Password появляется '*'
13 ТТ-5 Набрать: 'Р' В поле Password появляется '**'
14 ТТ-104 Нажать клавишу <ТАВ> Фокус перемещается на кнопку ОК
15 ТТ-37 Набрать: '@' Без изменений <
16 ТТ-18 Набрать: '$' Без изменений
17 ТТ-52 Нажать клавишу <ENTER> Сообщение об ошибке: неверный пароль
Использование электронных и обычных таблиц
149
Эти три тестовые процедуры отличаются своими начальными настройками.
В табл. 4.16 указывается, что нужно начать с пустого диалогового окна. Пользователь
должен поместить курсор в намеченное поле. В табл. 4.17 необходимо запустить файл
сценария, чтобы привести приложение в известное состояние. Основой для табл. 4.18
является успешное завершение другой тестовой процедуры. Чтобы задать тесты, в
примере с диалоговым окном будут сделаны следующие предположения.
• Максимальное число символов в поле равно 8.
• Пара значений имя пользователя/пароль должна быть верна для тестовой проце-
дуры ГТ-410 и неверна для ГТ-411 и ГТ-412.
• Для отображения символов пароля приложение использует символ (*), звез-
дочку.
• <АГТ>-<а>— это комбинация клавиш, которая перемещает фокус в поле
Password.
Все предположения относительно системы должны документироваться и согласо-
вываться с остальной частью команды разработчиков.
В процедуре ГТ-411 файл init_user_list.scr является сценарием, который вставляет
информацию об имени пользователя и пароле. Тестер должен выполнить этот сцена-
рий перед выполнением тестовой процедуры.
Чтобы запустить тестовую процедуру ГТ-412, с помощью начальных установок из-
меняют пароль пользователя на требуемое значение. Тестер должен выполнить тес-
товую процедуру ГТ-307 перед выполнением ГТ-412.
Для тестовых процедур не существует стандартного формата. Тестер можег ис-
пользовать любой подходящий формат, который обеспечит получение необходимой
информации.
В больших комплектах тестовой документации размер спецификаций тестов бы-
стро возрастает, поэтому важно уметь легко определить тесты, а также условия, кото-
рые эти тесты реализуют. Этого можно достичь с помощью матрицы прослеживаемо-
сти. Отображая требования к тестам на тесты, которые реализуют эти специфические
условия, можно быстро определить, какие тесты должны выполняться, какие нужно
изменить требования, чтобы модифицировать данный тест, и с какими условиями
тесты не связаны. В табл. 4.19 отображены условия тестов, заданные для примера с
диалоговым окном для трех существующих тестовых процедур. Дополнительные
примеры матрицы отображения требований можно найти в работе [Hetzetl 88].
Используя тестовые таблицы, можно много достичь: от классификации типов
входных данных до объединения подобных элементов в классы эквивалентности,
фиксирования выполненных тестов и результатов прохождения теста и даже созда-
ния в условиях теста перекрестных ссылок на реальные тесты. Теперь есть все основ-
ные возможности, дающие неплохой старт для документирования деятельности, свя-
занной с тестированием. Хотя тесты помогают определить верное и неверное нажа-
тие клавиш в тестируемом диалоговом окне, этот подход не ориентирован на полное
тестирование, его синтаксиса и атрибутов.
150 Глава 4
Таблица 4.19. Матрица прослеживаемости
для отображения требований к тестам на тестовые процедуры
Тестезая процедура
Требования к тестам ГТ-410 - ' ГТ-411 ГТ-412
ТТ-1
ТТ-2
ТТ-3
ТТ-4
ТТ-5
ТТ-7
ТТ-8
В зависимости от первоначального подхода к заданию тестов для примера с диало-
говым окном будут получены различные типы тестов. Кто-то будет изучать пользова-
тельские входные данные, тестируя принятие разрешенных символов, другие же бу-
дут проверять функциональные возможности диалогового окна, как, например, пере-
мещение между полем Password и кнопкой ОК. В примере не затронуто тестирование
синтаксиса, которое ориентировано на разрешенное содержимое каждой области
ввода. Истинное тестирование синтаксиса может быть проведено только тогда, когда
синтаксис системы точно задан в строгой системе обозначений, такой, например, как
регулярное выражение. За информацией о тестировании синтаксиса можно обра-
титься к работам [Beizer 90] и [Marick 95]. Задача этой главы заключается в том, что-
бы обеспечить тестера-новичка точкой отсчета путем задания тестов, которые дают
возможность определить, нажатие каких клавиш будет верным, а каких — ошибочным.
Рассмотрение строгости тестирования синтаксиса приведет к возникновению новых
тестов в изначальном наборе тестов. Каждый метод проектирования тестов порожда-
ет набор тестовых примеров. Некоторые из примеров уникальны для этого метода,
тогда как другие дублируют тесты, созданные другим способом. Таким образом, ни
одним из методов нельзя получить все возможные тесты.
Автоматическое создание тестовых примеров
Большинство групп, занимающихся тестированием, чтобы облегчить и автомати-
зировать трудоемкие задачи по программированию тестовых примеров, использует
инструменты автоматизации тестирования. Понимание исходных предпосылок тес-
тирования программного обеспечения может помочь более эффективно использо-
вать эти инструменты. Большая часть коммерческих инструментов тестирования ге-
нерирует входные данные, посылает их тестируемому приложению и автоматизирует
выполнение тестов. Даже несмотря на то, что многие из этих инструментов часто
хранят информацию о тестах внутри, не создавая при этом таблиц, как показано в
этой главе, можно быть уверенным, что аналогичная информация используется для
создания наборов тестовых примеров. Использование обычных и электронных таб-
лиц — это очень эффективный способ записи большого числа тестовых примеров.
Использование электронных и обычных таблиц
151
Хотя более подробная информация об инструментах тестирования и автоматиза-
ции представлена в главе 9, здесь будет сказано несколько слов о специфике инстру-
ментов тестирования GUI. Многие из доступных коммерческих инструментов тести-
рования могут автоматизировать тестирование GUI путем виртуальной генерации
нажатия всех клавиш и проверки состояний соответствующих результатов. Инстру-
менты тестирования могут сказать о том, что что-то произошло в ответ на нажатие
клавиши, но они не могут определить, верно ли произошедшее. Тестер часто прове-
ряет журнал результатов, сгенерированный инструментом тестирования, чтобы убе-
диться, что получены ожидаемые результаты. Поскольку эти инструменты выполняют
тесты быстро, то, возможно, не понадобится тратить время на сокращение большого
набора тестов. Эти тесты обычно запускаются на ночь и создают отчетный доклад, в
котором записаны результаты тестов. Когда у тестера есть доступ к инструментам ав-
томатизации тестирования, нужно сохранять равновесие между выбором поддающе-
гося управлению числа тестов, которые позволяют как следует понять поведение сис-
темы, и выполнением всех возможных тестов.
Резюме
Таблицы, или их электронный эквивалент, — чрезвычайно важный инструмент
тестирования программного обеспечения. К информации о тестах, записываемой в
таблицы, могут относиться комбинации входных данных, ожидаемые исходы, реаль-
ные исходы и статус тестов. Факт прохождения тестов выясняется после сравнения
реальных результатов с ожидаемыми.
Тестовые таблицы и матрицы, представленные в этой главе, используют большое
количество информации. Аналогично схемам тестов, тестовые таблицы указывают на
предназначение данного теста, не давая при этом всей той информации, которая не-
обходима для создания полного тестового примера. Тестеры, так же как и команда
разработчиков, могут получить неплохое представление о том, какие тесты рассмат-
риваются.
Не существует единообразного формата таблиц, так как в каждой организации
информация записывается по-своему. Основным критерием тут является возмож-
ность записывать информацию, необходимую для качественного тестирования и до-
кументирования того, что было сделано.
Реализовать таблицы просто. Использование электронных таблиц— это простой
способ создания и изменения тестовых таблиц. Фактически, электронные таблицы —
это один из наилучших инструментов документирования тестовых примеров, резуль-
татов тестов и их статуса. Таблицы могут служить различным целям в зависимости от
того, как они используются.
В таблицах акцент делается на входных комбинациях. В матрице перечисляется
большая часть тестовых примеров, а иногда и все возможные входные комбинации.
В таблицу записываются тесты, которые нужно задать, создать и выполнить. Потом
тестер может выбрать порядок создания тестовых примеров, который может зави-
сеть от многих факторов, в том числе:
152
Глава 4
• приоритета тестов;
• порядка, в котором функции поступают к тестеру;
• доступной информации о продукте, которая необходима для дальнейшего за-
дания тестов;
• личных удобств: тестер задает тесты для тех функций, которые он лучше всего
знает;
• выбора различных функций: тестер выбирает несколько тестов для каждой
функции;
• если нет возможности охватить все тесты, следует выбрать произвольную часть
тестовой таблицы (как, например, тесты в одном столбце или одной строке),
или поочередно выбрать ячейки в таблице.
То, все ли тесты будут выполнятся, — своего рода приговор. Одна из задач тести-
рования программного обеспечения состоит в уменьшении максимального числа тес-
товых примеров до такого количества, которым будет проще управлять. В тестовых
таблицах также может быть представлен показатель объема тестовой документации,
имеющей отношение к делу, что достигается путем создания ссылок на подробное
описание тестов. Разносторонность таблиц и простота, с которой они передают ин-
формацию, делает их неотъемлемой частью тестирования.
ГЛАВА
5
Другие типы таблиц
Введение
Таблицы предоставляют обширные возможности для документирования различ-
ных типов информации, касающейся проектирования тестовых примеров, а также их
выполнения. В дополнение к таблицам, описанным в главе 4 для приложений с ин-
терфейсом GUI, в этой главе таблицы рассматриваются как вспомогательное средство
для документирования тестовых примеров в следующих ситуациях:
• приложения, описанные при помощи диаграмм переходов и таблиц состояний;
• приложения, требующие введения множества входных комбинаций;
• приложения, описанные при помощи таблиц решений.
Далее читатель узнает, как с помощью таблиц отслеживается связанная с тестами
информация:
• планирование теста;
• матрица прослеживаемости;
• матрица перекрестных ссылок;
• выполнение теста;
»
• факт прохождения теста.
Помимо изучения таблиц, при помощи анализа покрытия будет оценена эффек-
тивность тестовых примеров, для того чтобы оценить, адекватно ли тестовый пример
взаимодействует со всеми важными элемен тами приложения.
Конечный автомат
Конечный автомат — это поведенческая модель, состояние которой зависит как от
предыдущих, так и от текущих входных данных. Диаграмма переходов — это графиче-
ское представление конечного автомата. Ее задача — отобразить состояние, которое
154
Глава 5
может принять система или компонент. Диаграмма переходов также показывает со-
бытия или обстоятельства, результатом которых стал переход системы компонент из
одного состояния в другое [IEEE 610.12].
На некоторых диаграммах перехода могут быть показаны трансформация поведе-
ния сложных функций системы, взаимодействие между объектами, поток логики в
пределах модуля и многие другие ситуации. Диаграмма переходов полезна также при
моделировании входных данных, которые должны быть введены в различном поряд-
ке (например, программа синтаксического анализа, где каждое успешное нажатие
клавиш проходит через ряд состояний и каждое состояние может совпадать с преды-
дущим, быть новым состоянием в последовательности или же быть ошибочным со-
стоянием). При получении каждого нового элемента входных данных может также
происходить внутренняя обработка данных.
Диаграмма переходов и сопутствующая ей таблица — таблица переходов (или таб-
лица состояний) содержат информацию, которая без труда преобразуется в тестовый
пример. Рассматриваемый подход заключается в преобразовании диаграммы перехо-
дов в таблицу состояний, анализа таблицы состояний для полноты оценки и после-
дующего создания тестового примера. Чтобы продемонстрировать использование
диаграмм переходов в качестве входных данных для тестирования, будет разработан
тест для секундомера. Секундомер может быть как целостным приложением, так и
элементом большой системы. Он будет считаться самодостаточной функцией.
Диаграмма перехода для секундомера состоит из трех состояний, а интерфейс со-
держит три типа входных данных и один — выходных. Каждый из трех типов входных
данных представляет собой событие, влияющее на систему. Интерфейс имеет сле-
дующее описание.
Вход
НАЧАЛО истекшее время продолжает увеличиваться, начиная с текущего
отображаемого значения времени. Значение времени увеличивается
каждую секунду
КОНЕЦ увеличение значения истекшего времени прекращается
и отображается последнее значение времени
СБРОС текущее время сбрасывается на нулевое значение
Выход
Время текущее значение времени
На диаграмме перехода (рис. 5.1) показано поведение секундомера и взаимосвязь
между входными данными и состояниями. Овалами обозначены состояния секундо-
мера, а стрелками — переходы из одного состояния в другое. Каждая стрелка предос-
тавляет информацию, состоящую из двух частей. Первое значение указывает на собы-
тие, вызвавшее переход. Второе выражение, которое начинается с пометки “//”, оп-
ределяет действия, произошедшие в результате. В этом случае некоторые события
влияют на значение времени.
Другие типы таблиц
155
Рис. 5.1. Диаграмма переходов, иллюстрирующая поведение секундомера
Проиллюстрируем переход на примере. Когда секундомер находится в неактивном
состоянии и пользователь вводит команду НАЧАЛО, секундомер переходит в состоя-
ние выполнения и временная переменная возрастает, отображая истекшее время. Се-
кундомер остается в состоянии выполнения до тех пор, пока пользователь не вызовет
другое событие, которое приведет к изменениям.
В таблице состояний (табл. 5.1) показано другое представление той же информа-
ции, что содержится на рис. 5.1. В первом столбце перечислены все возможные собы-
тия, заголовки остальных столбцов содержат перечень всех возможных состояний.
В ячейках содержится информация о том, как каждое событие влияет на состояние.
Номера в нижнем правом углу каждой ячейки — это метки для идентификации ячейки.
На эти номера в последующих таблицах будут сделаны ссылки, чтобы можно было
отобразить источник тестового примера.
Если все переходы на диаграмме определены, то никакой путаницы не возникнет.
Это предполагает, что каждое состояние и комбинация событий имеют определен-
ный результат. При преобразовании диаграммы переходов в эквивалентную ей таб-
лицу состояний становится видимой информация, отсутствующая на диаграмме пере-
ходов. На рис. 5.1 не дано определения четырем событиям, таким образом на рисунке
отсутствуют дуги. Часто предполагают, что отсутствующие дуги в действительности
являются петлями, отображающими отс)»гствие изменений в состоянии. Следова-
тельно, если секундомер в текущий момент находится в состоянии выполнения, ис-
пользование команды НАЧАЛО не вызовет изменений и секундомер останется в этом
состоянии с постоянным значением времени. Аналогично, если секундомер находит-
ся в неактивном состоянии, то нажатие кнопки КОНЕЦ не вызовет никаких измене-
ний. Некоторые проектировщики опускают петли, чтобы предотвратить нагромож-
дение слишком сложных диаграмм. В таких обстоятельствах оправдывает себя ис-
пользование комментариев, указывающих на то, что отсутствующие события не вы-
зывают изменений. Однако из опыта известно, что такого рода предположения часто
156
Глава 5
скрывают потенциальные проблемы, так что для большей уверенности тестер должен
задать тесты, которые будут реализовывать все события для каждого состояния. Луч-
ше всего обсудить эту тему с разработчиками в ходе пересмотра проекта.
Таблица 5.1. Таблица состояний, описывающая диаграмму переходов
Событие кш. - ; Нерабочее состояние Состояние выполнения Состояние паузы
НАЧАЛО Выполнение Выполнение
//Время = возрастающее ? //Время = возрастающее
значение значение
ячейка 1 ячейка 4 ячейка 7
КОНЕЦ Пауза
? //Время = последнее 7
значение
ячейка 2 ячейка 5 ячейка 8 ,
СБРОС Неактивен Неактивен
? //Время = 0 //Время = 0
ячейка 3 ячейка 6 ячейка 9
Чтобы определить отсутствующие потоки на диаграмме секундомера, для перехода
в неактивное состояние имеет смысл прибегнуть к кнопке СБРОС без учета предыду-
щего состояния. Аналогично кнопка НАЧАЛО будет переводить секундомер в со-
стояние выполнения. Эти моменты отражены в ячейках 3 и 4 в табл. 5.2. Кнопка
КОНЕЦ будет переводить все состояния в состояние паузы, что записано в ячейке 8.
Эти дополнительные переходы содержатся в таблице состояний в табл. 5.2 и в обнов-
ленной диаграмме переходов на рис. 5.2.
Такое приложение, как секундомер описывает простую ситуацию и завершенная
таблица состояний строится на основе рациональных умозаключений. Оба варианта
поведения системы при нажатии команды КОНЕЦ в неактивном состоянии кажутся
логичными. Чтобы завершить таблицу состояний, принимаются решения, помогаю-
щие избежать дополнительной неясности. Завершение таблицы состояний для более
сложных систем может оказаться не таким очевидным. Если команда разработчиков и
рецензенты потерпели неудачу при установлении такой несообразности, именно тес-
теры находят неполадки уже после написания кода.
После анализа обнаруживается отсутствие некоторых операций в диаграмме пере-
ходов. При тестировании конечного автомата тесты, которые провалились, можно
обозначить с помощью любого из этих условий:
• состояние, показанное на диаграмме переходов, отсутствует в коде;
• опг . .ция, показанная на диаграмме переходов, отсутствует в коде;
• операция приводит к неверному состоянию;
• состояние выполняет неверные функции.
Другие типы таблиц
157
Таблица 5.2. Таблица состояний, в которой заданы все переходы
Нерабочее состояние
-Состояние выполнения . Состояние паузы‘;.ЖДт-
НАЧАЛО Выполнение Выполнение Выполнение
//Время = возрастающее //Время = возрастающее //Время = возрастающее
значение значение значение
ячейка 1 ячейка 4 ячейка 7
КОНЕЦ. Неактивен Пауза Пауза
//Время = 0 //Время = последнее значение //Время = последнее значение
ячейка 2 ячейка 5 ячейка 8
СБРОС Неактивен Неактивен Неактивен
//Время = 0 //Время = 0 //Время = 0
ячейка 3 ячейка 6 ячейка 9
Конец _ Начало Начало
Гбпос Время = возрастающее значение
...Конец
Рис. 5.2. Диаграмма переходов, содержащая все переходы
Еще одна проблема встречается там, где код содержит дополнительные состояния
или операции, не показанные на диаграмме переходов. Отлавливание ошибок такого
типа требует наличия инструментов для анализа, чтобы можно было точно указать на
любой код, который не выполняется. За дополнительной информацией о конечных
автоматах читатель может обратиться к работам [Beizer 95], [BinderOO] и [Marick95].
158
Глава 5
Создание тестовых примеров на основе таблицы состояний
Информация, содержащаяся в таблице состояний, легко преобразуется в тестовые
примеры благодаря табличной форме записи. Табл. 5.3 включает список тестовых
примеров, полученный на основе информации из табл. 5.2. Эта таблица тестовых
примеров состоит из шести столбцов.
ID тестового примера
Источник теста
Текущее состояние
Событие
Время на выходе
Следующее состояние
уникальный идентификатор для каждого тестового примера,
указывает на соответствующую ячейку в таблице состояний,
начальные условия, необходимые для запуска теста.
ввод, выполненный пользователем.
текущее значение времени, возвращаемое секундомером.
новое состояние секундомера.
Тестовый пример Т-200, информация для которого была получена из ячейки 1 в
табл. 5.2, указывает на то, что секундомер должен начинать с неактивного состояния
и ожидать события НАЧАЛО. Это переводит секундомер в состояние выполнения и
таким образом значение времени возрастает с каждой секундой.
Таблица 5.3. Описание тестового примера
Входные данные Ожидаемые результаты
Id тестового Примера Источник 'тест^|(||!^ Текущее состояние Событие Время навь1ход0,^^^^® состояние
Т-200 ячейка 1 Нерабочее НАЧАЛО Время = возрастающее значение Выполнение
Т-201 ячейка 2 Нерабочее КОНЕЦ Время = 0 Нерабочее
Т-202 ячейка 3 Нерабочее СБРОС Время = 0 Нерабочее *
Т-203 ячейка 4 Выполнение НАЧАЛО Время = возрастающее значение Выполнение
Т-204 ячейка 5 Выполнение КОНЕЦ Время = последнее значение Пауза
Т 205 ячейка 6 Выполнение СБРОС Время = 0 Нерабочее
Т-206 ячейка 7 Пауза НАЧАЛО Время = возрастающее значение Выполнение
Т-207 ячейка 8 Пауза КОНЕЦ Время = последнее значение ' Пауза
Т-208 ячейка 9 Пауза СБРОС Время = 0 Нерабочее
Другие типы таблиц
159
Уровень информации, представленной в табл. 5.3, достаточен, чтобы убедиться в
том, что изменения состояний корректно реализованы в коде. В некоторых случаях
ввод необходимо проверить более тщательно, поскольку он влияет на результирую-
щее время на выходе. В табл. 5.4 дано определение дополнительным тестовым при-
мерам, которые обеспечивают более доскональные входные условия, задавая фикси-
рованный интервал для входной последовательности. В этой обновленной таблице
содержится один столбец с входными данными, который помечен как “входная по-
следовательность” и описывает последовательность вводимых команд. В этом приме-
ре предполагается, что на первую команду уходит одна секунда, а затем наступает пе-
риод ожидания. Таким образом, для тестового примера Т-211 тестер запускает коман-
ду НАЧАЛО, а затем ждет пять секунд, прежде чем запустить команду КОНЕЦ, тогда
суммарное истекшее время будет равно шести секундам. Верна или неверна такая эв-
ристика, определяется при обсуждении этого вопроса остальными членами команды
разработчиков.
Таблица 5.4. Описание тестового примера с более подробными входными условиями
Входные данные Ожидаемые результаты
10 Источник Входная Время на выходе Следующее
тестового примера теста последовательность состояние
Т-210 ячейка 1 Нерабочее Событие НАЧАЛО Время = 0,1,2, 3,... Выполнение
Т-211 ячейка 1 ячейка 5 Нерабочее Событие НАЧАЛО Ожидание 5 секунд Событие КОНЕЦ Время = 0,1,2, 3,4, 5 Пауза
Т-212 ячейка 7 ячейка 5 Запуск теста Т-211 Событие НАЧАЛО Ожидание 3 секунды Событие КОНЕЦ Время = 6,7, 8, 9 Пауза
Т-213 ячейка 9 Запуск теста Т-212 Время = 0 Нерабочее
Событие СБРОС
На основе информации, содержащейся в диаграмме переходов и таблице состоя-
ний, был создан тестовый пример. Хотя это и важный этап в тестировании про-
граммного обеспечения, еще очень много нужно сделать. Создание среды, в которой
будут проходить тесты, отнимает массу усилий.
160
Глава 5
Проведение теста и уровни тестирования
На проведение теста влияет множество факторов. Они вводятся здесь для того,
чтобы указать на большой объем работы, которую нужно выполнить перед запуском
теста. Прежде всего необходимо создать механизмы для управления тестами: тесто-
вые драйвера, активирующие тестируемое приложение, а также способы, с помощью
которых тестер может вводить входные данные в приложение и переводить секундо-
мер в повое состояние. Также потребуются средства для фиксирования текущего вре-
мени и определения текущего состояния секундомера. Для некоторых приложений
эти задачи решаются благодаря распечатке изменений состояния, которая подтвер-
ждает текущее состояние системы. В примере с секундомером индикатором состоя-
ния секундомера может служить отображаемое время, а именно:
• значение времени равно нулю в нерабочем состоянии;
• значение времени увеличивается в состоянии выполнения;
• значение времени остается неизменным в состоянии паузы.
Последний случай неоднозначен, поскольку состояние секундомера можно изме-
нять достаточно быстро, так что в положении паузы секундомер покажет ноль. Таким
образом, неясно, какое в действительности состояние отображает нулевое значение:
паузу или нерабочее, поэтому тестер должен иметь возможность проверить текущее
состояние секундомера, чтобы можно было определить, корректен ли исход теста.
Еще одна компонента выполнения теста — это регистрация реальных результатов.
Можно расширить таблицу тестовых примеров, создав столбец, в котором тестер бу-
дет отмечать результаты прохождения теста (табл. 5.5). Для тестов, которые провали-
лись, документирование наблюдаемого поведения секундомера предоставляет ценную
информацию для отслеживания неполадок.
В тестовом примере из табл. 5.5 кроме корректности внутренних состояний про-
веряется точность временной функции. Осуществление такого теста требует внешних
средств подтверждения точности истекшего времени, как, например, использование
вспомогательного таймера для сравнения ожидаемого и реального значений истек-
шего времени. Это оказывается проблемой при тестировании системы, поскольку
приходится проверять точность таймера, если результирующий продукт, в который
будет встроен таймер, является частью системы, находящейся в условиях большой на-
грузки (включая многозадачность, прерывания, совместное использование ресурсов и
другие функции, которые могут приостановить использование секундомера). Тести-
рование характеристик, несмотря на свою важность, начинает цениться только тогда,
когда собран весь продукт в целом.
Другие типы таблиц
161
Таблица 5.5. Более совершенная таблица тестового примера
- Входные данные Ожидаемые результаты Реальные 'результаты
ID Текущее Событие Время Следующее прошел/
тестового примера теста состояние на выходе состояние , ...
Т-200 ячейка 1 Нерабочее НАЧАЛО Время= возраста- ющее зна- чение Выполнение
Т-201 ячейка 2 Нерабочее КОНЕЦ Время = 0 Нерабочее
Т-202 ячейка 3 Нерабочее СБРОС Время = 0 Нерабочее
Т-203 ячейка 4 Выполнение НАЧАЛО Время = возраста- ющее зна- чение Выполнение
Т-204 ячейка 5 Выполнение КОНЕЦ Время = по- следнее значение Пауза
Т-205 ячейка 6 Выполнение СБРОС Время = 0 Нерабочее
Т-206 ячейка 7 Пауза НАЧАЛО Время = возраста- ющее зна- чение Выполнение
Т-207 ячейка 8 Пауза КОНЕЦ Время = по- следнее значение Пауза
Т-208 ячейка 9 Пауза СБРОС Время = 0 Нерабочее
Остается ответить еще на один вопрос: как будет проводиться тестирование се-
кундомера — на уровне системы или на уровне элементов? До настоящего времени эта
разница была несущественной. Разработка тестовых примеров требует подробного
описания тестируемого приложения, невзирая на уровень тестирования. Таблицы
тестов и схем одинаково используются на всех уровнях тестирования. Основные раз-
личия заключатся в рамках и взаимодействиях, требуемых для выполнения тестов.
1. Поэлементное тестирование затрагивает наименьшие единицы компиляции
какого-либо приложения. Цель такого тестирования заключается в демонстра-
ции того, что каждый отдельный элемент функционирует так, как было задума-
но, перед интеграцией его с другими элементами. Тестеры, как правило, запус-
кают элемент и с помощью тестового драйвера, который передает информа-
цию о выполнении теста тестируемому элементу, вводят данные.
162
Глава 5
2. Тестирование уровня интеграции заключается в комбинировании отдельных
элементов и подтверждении того, что они функционируют корректно. Для
проведения тестирования интеграции существует несколько подходов, кото-
рые перечислены дальше. Эти подходы хорошо описаны также в работах
[Beizer 90] и [Pressman 01],
3. Тестирование уровней системы применяется для целостных приложений. Это
чаще всего касается ведения системы пользователем. Тестеры обычно взаимо-
действуют с приложением, вводя данные тем же способом, который использует
конечный пользователь.
Если таймер реализуется как самодостаточная единица компиляции, тестирование
можно проводить на уровне элементов. В этом примере более крупное приложение
структурируется таким образом, чтобы таймер был его модулем. Следует отметить,
что здесь нет дополнительного описания, касающегося реализации: неизвестно, будет
ли элемент процедурной функцией, набором подпрограмм или классом. Образец тес-
тового примера, созданный на основе анализа описания секундомера, — это не код,
используемый для его реализации. Тестовые примеры, разрабатываемые на основе
реального кода, подвергают риску выполнение кода, так как невозможно узнать, дей-
ствительно ли код корректен. В главе 9 разъясняется отличие между созданием тестов
на основе описания поведения и на основе структуры кода, а также предоставлена до-
полнительная информация об элементах, интеграции и тестировании уровней системы.
Таблица тестовых примеров
с несколькими входными данными
Для приложений, в которых содержится много входных значений, использование
таблиц для отслеживания всех входных данных, чтобы протестировать одну ситуа-
цию, может оказаться самым простым способом задания и документирования тесто-
вого примера. Такая таблица впервые была использована в этой главе; каждая строка
таблицы соответствовала отдельному тестовому примеру, а каждый столбец задавал
входное значение и ожидаемые результаты.
Чтобы проиллюстрировать этот подход, будет рассмотрено приложение для рас-
чета погашения ссуды, которое вычисляет месячные взносы исходя из постоянной
оплаты и постоянного процента по ссуде. В этом приложении есть три входных зна-
чения:
• процент по ссуде — годовой процент по ссуде;
• длительность погашения ссуды — суммарное число месяцев или лет, на которое
была выдана ссуда;
• величина ссуды — общая сумма займа.
Приложение возвращает три выходных значения:
ежемесячная оплата — величина каждого ежемесячного взноса;
Другие типы таблиц
163
• суммарная оплата — сумма, выплаченная за все время погашения ссуды;
• суммарная прибыль — суммарная прибыль, полученная за все время погашения
ссуды.
Варианты оплаты, а такж< другие изменения в жизненном цикле ссуды рассматри-
ваться не будут, чтобы не усложнять описание приложения.
В табл, э.6 показан набор тестовых примеров для этого приложения. Целая строка
данной таблицы представляет собой один отдельный тестовый пример. В первом
столбце задан уникальный идентификатор тестового примера. В следующем наборе
столбцов перечислены входные значения, после которых идут ожидаемые результаты.
Создание начальной таблицы заключается в перечислении типов входных данных
в виде заголовков столбцов. Существует несколько различных подходов к определе-
нию входных данных. Один из подходов к определению тестового примера — выбор
случайных значений, однако здесь следует обратить внимание на возможность про-
пуска каких-либо важных входных, комбинаций. Другой подход состоит в том, что ко-
манда разработчиков должна составить список контрольных проверок для критич-
ных входных комбинаций что поможет определить критичные тесты. Прохождение
через несколько итераций при составлении таблицы тестовых примеров, как это опи-
сано в главе 4, может помочь выделить для тестирования наиболее важные комбина-
ции данных. Анализ степени риска, описанный в главе 8, также помогает установить
подходящие тесты. Использование того или иного подхода зависит от типа тестируе-
мого приложения, знания тестером системы и от объема времени, выделенного на
тестирование.
Значения входных данных в табл. 5.6 выбраны исходя из обоснованных предпо-
ложений. В требованиях должно указываться, как управлять ожидаемыми результата-
ми. В примере со ссудой тестер должен получить математические уравнения, исполь-
зующиеся для создания реализованного программным путем алгоритма. Другим вари-
антом будет использование калькулятора для расчета погашения ссуды, имеющегося в
продаже или доступного в сети. Использование последнего варианта может привести
к результатам, которые будут слабо отличаться от реальных. Авторитетное лицо про-
екта устанавливает приемлемую пороговую величину. Если метод предназначен для
определения ожидаемых результатов, необходимо использовать подходящие методи-
ки тестирования (они включают вычисление ожидаемых результатов при помощи
средств, которые отличаются от кода, реализованного в тестируемом приложении).
Тестер должен быть уверен, что ожидаемые результаты определены корректно.
Структура этой таблицы позволяет добавить столбцы для отслеживания результа-
тов теста, статуса теста и другой относящейся к делу информации. В табл. 5.7 имеются
дополнительные столбцы для записи информацш полученной при проведении теста.
Не существует никаких стандартных промышленных фсрматов или названий для
таблиц, в которых задаются и отслеживаются тестовые примеры. Единственный кри-
терий заключается в том, что спецификации тестов должны предоставлять иденти-
фикаторы, ясное описание входных данных и ожидаемых результатов. Таким обра-
зом, табл. 5.7 также можно назвать таблицей тестовых примеров, проверочной мат-
рицей или любым другим подходящим названием, которое имеет смысл в данной ор-
ганизации.
Таблица 5.6. Таблица тестового примера приложения для расчета погашения ссуды
ID тестового примера .Входные данные Ожидаемые результаты
Процент по ссуде, (%) Длительность погашения ссуды Ветчина ссуды. ($) Ежемесячная оплата, ($) Суммарная оплата, ($) Суммарная прибыль, ($)
а-222 8 ЗОлет 80 000 587,01 211 324,20 131 324,20
а-223 8,50 ЗОлет 80 000 615,13 221 447,08 141 447,08
а-224 8,50 15 лет 80 000 787,79 141 802,50 61 802,50
а-225 8 15 лет 80 000 764,52 137 613,90 57 613,90
Таблица 5.7. Отслеживание статуса тестов
ID тестового примера Входные данные Ожидаемые результаты Реальные результаты Статистика тестов
Процент Длитель- Величина Ежеме- Суммарная Суммарная Ежеме- Сумма- Сумма- Прошел/ Дата Имя
по ссу- ность ссуды, ($) де, (%) погаше- ния долга . ссуды сяччая оплате, ($> прибыль, ($) оплата, ($) сячная рная рная оплата, оплата, прибыль. ($) (S) (S) провали-* гусям; тестера лея деиия теста
а-222 8 ЗОлет 80 000 587,01 211324,20 131324,20
а-223 8,50 ЗОлет 80 000 615,13 221447,08 141447,08
а-224 8,50 15 лет 80 000 787,79 141802,50 61802,50
а-225 8 15 лет 80 000 764,52 137613,90 57613,90
Другие типы таблиц
165
Таблицы решений
Таблицы решений — это еще один полезный метод управления тестовыми приме-
рами. В этом разделе будут обсуждаться способы использования таблиц решений и
анализа покрытия для оценки эффективности теста.
Таблица решений предоставляет возможность отслеживать сложные комбинации
условий и результирующих действий, которые имеют место при таких условиях, в яс-
ном для понимания формате. Преимущество таблиц решения — в логических выра-
жениях, которые содержат унарную операцию NOT и бинарные операции AND, OR и
XOR (исключающее ИЛИ). Каждый операнд, или переменная, в логическом выраже-
нии принимает значение TRUE или FALSE.
Ддя начала рассмотрим образец таблицы решений. Даже не имея серьезных зна-
ний о приложении и только бегло взглянув на таблицу решений, можно получить об-
щее представление о его функциональных возможностях. В табл. 5.8 рассматривается
система расчета по кредитной карточке. В таблице показаны различные условия или
состояния, которым должен удовлетворять счет клиента, и результирующие дейст-
вия, выполняемые приложением. Существует правило, согласно которому определя-
ется, какие Комбинации условий приводят к результирующим действиям. Каждое из
условий принимает одно из трех значений: Т (для TRUE), F (для FALSE) или I (для
“безразлично”). Состояние условия “безразлично” не влияет на результирующие дей-
ствия. Знак X указывает на то, выполнялись ли результирующие действия.
Например, правило № 2 звучит следующим образом:
ЕСЛИ все перечисленные ниже условия имеют значение TRUE
• счет показывает ненулевой баланс;
• клиент пропустил оплату за последние 12 месяцев;
• последняя оплата была сделана вовремя;
• не имеет значения, подписан ли клиент на дополнительные скидки,
ТО происходят следующие действия:
• вычисляется стоимость кредита при высоком проценте И следующие действия
НЕ происходят;
• вычисляется стоимость кредита при нормальном проценте;
• оценивается сбор за запоздавшую оплату;
• вычисляется процент по наличности.
Управление тестовыми примерами с помощью таблицы решений — занятие до-
вольно простое. Каждое из семи правил преобразуется в отдельный тестовый пример.
Входные данные для каждого теста состоят из отобранных данных, которые удовле-
творяют соответствующим условиям для каждого правила. Результат состоит из дей-
ствий, которые, как ожидается, должны произойти.
166
Глава 5
В таблице решений можно использовать другие обозначения, например, значения
ДА и НЕТ вместо TRUE и FALSE. Действия можно также помечать ДА и НЕТ, чтобы
не оставалось пустого места. В этом конкретном примере два действия являются
взаимоисключающими: стоимость кредита вычисляется либо при нормальном про-
центе, либо при высоком. Чтобы подчеркнуть эту связь, действие по вычислению
стоимости кредита может иметь три состояния: НОРМАЛЬНЫЙ, ВЫСОКИЙ и
ОТСУТСТВУЕТ. Последнее состояние применяется к правилу № 1. Такой подход по-
казан в табл. 5.9. Не принимая во внимание используемые обозначения, содержание
таблицы абсолютно то же. Принцип управления — обеспечить очевидную связь.
За дополнительными примерами и разъяснениями можно обратиться к работам
[Binder 00], [Myers 76], [PfleegerOl] и [Pressman 01].
Уменьшение размеров таблицы решений
Цель тестирования — снизить число тестовых примеров, сохраняя при этом воз-
можность находить неполадки.
Можно объединить правила, результирующие действия которых идентичны, и та-
ким образом упростить логические выражения. Теория, лежащая в основе этого уп-
рощения, пришла из проектирования аппаратной логики, в котором для управления
и оценки логических выражений используется алгебра логики. Если логическое вы-
ражение можно переписать в эквивалентной форме с помощью меньшего числа пе-
ременных, то соответствующая аппаратная схема будет проще. Методы упрощения
логических выражений обсуждаются во многих работах по электротехнике, например
в [Beizer90].
Пример в табл. 5.7 уже упрощен. При наличии четырех условий, каждое из кото-
рых может принимать значение TRUE или FALSE, можно получить 24 или 16 различ-
ных комбинаций. В таблице показано семь правил, поскольку в некоторых из них не
учитывается состояние одного или нескольких условий.
Расширение таблицы решений
Утверждение о том, что таблица решений (табл. 5.8) уже была уменьшена, подра-
зумевает, что интересными будут лишь несколько тестовых примеров. Но хорошо ли
это? Рассмотрим коротко этот вопрос. Таблица была уменьшена потому, что в неко-
торых правилах использовалось условие “безразлично”. Иногда расширение таблицы
решений, чтобы разъяснить условие “безразлично”, может обнаружить скрытые про-
блемы.
Таблица 5.8. Таблица решений
’ Г/ ’ • 'Ч . ' - >' Правило 1 Правило 2 Правило 3 Правило 4 Правило 5 Правило 6 Правы по 7
Условие счет показывает кредит или нулевой баланс Т F F F F F F
клиент пропустил оплату за последние 12 месяцев 1 Т Т F F F F
предыдущая оплата была сделана 1 F Т F F Т Т
с опозданием клиент подписан на дополнительные скидки 1 Т т F Т F Т
Действие вычисляется стоимость кредита при нормальном проценте вычисляется стоимость кредита при высоком проценте X X X X X X
вычисляется сбор за запоздавшую оплату X t X X
вычисляется процент по наличности X X
Таблица 5.9. Действия таблицы решений, имеющие три состояния
Пранило1 Правило 2 Правиле 3 Правиле 4 Правило 5 Правило € Правило 7
Условие счет показывает кредит или нулевой баланс т F F F F F F
клиент пропустил оплату за последние 12 месяцев 1 Т Т F F F F
предыдущая оплата была сделана с опозданием 1 F Т F F Т Т
клиент подписан на дополнительные скидки 1 Т Т F Т F т
Действие вычисляется стоимость кредита отсутствует высокий высокий нормаль- ный нормаль- ный нормаль- ный нормаль- ный
вычисляется сбор за запоздавшую оплату да да да
вычисляется процент да да
по наличности
Другие типы таблиц
169
В табл. 5.10 представлен расширенный вариант табл. 5.8. Правило 1 в табл. 5.8, ко-
торое содержит три условия “безразлично”, в табл. 5.10 разбито на восемь правил
(называемых “правило 1-п”). Каждое условие “безразлично” теперь принимает значе-
ние TRUE/FALSE. Эти две таблицы логически эквивалентны. Таким образом, комби-
нации условий дают в результате тесты, которые реализуют одинаковые обстоятель-
ства. Чтобы облегчить рассмотрение таблицы, семь тестов, полученные из табл. 5.8,
будут называться сокращенным, набором тестов, а шестнадцать тестовых примеров из
табл. 5.10 — расширенным набором тестов. В идеальном случае, расширенный набор тес-
тов — это избыточный исходный набор. Однако этого нельзя сказать по отношению к
исходному коду. Без инспекции реального кода тестер не может определить, следует
ли сокращенный набор тестов тем же путям в коде, что и расширенный набор тестов.
Без реального запуска теста нельзя быть уверенным в том, что тесты, полученные из
правил 1.2 и 1.3 в расширенном наборе, дадут те же результаты, что и правило 1 в со-
кращенном наборе.
Дальше анализируется система расчетов с помбщью кредитной карты. Если это за-
ново разрабатываемое приложение, может оказаться, что достаточно выполнить со-
кращенный набор тестов. Когда же камнем преткновения становится время, отведен-
ное для тестов, запуск сокращенного набора тестовых примеров покажет, что тесте-
ры, по крайней мере, разобрались с основными функциональными возможностями.
Если же это приложение является преемником другого приложения, которое было
модифицировано так, чтобы соответствовать новой банковской политике, то разум-
нее будет выполнить расширенный набор тестовых примеров. Тестер не может пред-
сказать, верна ли внутренняя логика. Не имея дополнительной информации, тестер
точно не знает, какой набор тестов следует выполнять.
Возникает вопрос: сколько тестовых примеров необходимо выполнить и что нуж-
но обнаружить? Перечислим несколько факторов:
• спешка;
• знания о проекте;
• анализ покрытия.
Многие проекты становятся жертвами сжатых сроков, так как времени для адек-
ватного тестирования приложения просто не хватает. Реализация тестовых примеров
в сокращенной таблице решений может обеспечить базис для осуществления ключе-
вых функций. Если остается время, тестеры могут перейти к выполнению дополни-
тельных тестов.
170
Глава 5
Таблица 5.10. Расширенная таблица решений
Условие счет показывает ТТТТ ТТТТ
кредит или
нулевой баланс
клиент пропус- FF FF ТТТТ
кал оплату
за последние
12 месяцев
предыдущая FFTT FFTT
оплата была
отправлена
с опозданием
клиент подписан FT FT F T FT
на план
дополнительных
скидок
Действие вычисляется
финансовый
расход
при нормальном
проценте
вычисляется
финансовый
расход при вы-
соком проценте
вычисляется
сбор за запо-
здавшую оплату
вычисляется
сумма налично-
сти, поддержи-
вающая скидку
Другие типы таблиц
171
Прави/ ' Правило 3 Правило 4 Правило 5 Правило б
йрЙий’Ш Прмило гЛ4Цмиввк£&Йх ^1равило7 ।
ЗЛ--
F F F F F F F F
Т Т Т Т F F F F
F F Т Т F F Т Т
F Т F Т F Т F Т
X X X X
X X X X
X X X X
X
X
172 Глава 5
Внутреннее знание о проекте помогает пролить свет на то, какая часть продукта
больше всего нуждается в тестировании. Часто при выборе теста тестеры полагаются
на интуицию, когда же возникает проблема, какой набор тестовых примеров выпол-
нять: сокращенный или расширенный, оптимальным решением может стать обсуж-
дение этого спорного момента с осведомленными разработчиками или менеджером
по выпуску новой продукции. Разработчики должны хорошо понимать структуру кода:
насколько код отражает таблицу решений или то, проводилась ли модификация кода,
чтобы он мог удовлетворять новым правилам в таблице решений. Определение наи-
более рискованной части приложения помогает направить усилия по тестированию в
ту область, которая больше всего в этом нуждается. Если в таблице решений докумен-
тировано рискованное поведение, то выполнение расширенного набора тестов мо-
жет повысигь уверенность в качестве продукта. В главе 8 обсуждается оценка степени
риска и введены дополнительные подходы к выбору наиболее важных тестов.
Анализ покрытия
Анализ покрытия дает возможность оценить эффективность теста. Данный метод
заключается в использовании специализированных инструментов тестирования для
наблюдения за путями выполняемого кода. На существующем рынке многие постав-
щики предлагают коммерческие инструменты для анализа покрытия. Кратко опишем,
в чем состоит анализ покрытия.
Создание тестового примера.
Установка специализированного инструмента анализа покрытия для наблюдения.
Выбор типа покрытия для наблюдения.
REPEAT
- Провести больше тестов.
UNTIL (покрытие = 100%)
Если выполнение сокращенного набора тестов удовлетворяет задаче покрытия, то
нет необходимости выполнять дополнительные тесты. Для иллюстрации различных
типов покрытий ниже представлен следующий фрагмент кода:
IF (A or В)
• THEN do_something
END IF
Далее будут рассмс трены три типа покрытия, для каждого из которых требуется
различное число тестовых примеров.
Другие типы таблиц
173
Покрытие утверждений
требуется один тестовый пример:
• утверждение IF должно принимать значение TRUE (в этом примере).
Покрытие ветвей
требуется два тестовых примера:
• утверждение IF принимает значение TRUE;
• утверждение IF принимает значение FALSE.
Покрытие условий
требуется четыре тестовых примера:
• A—TRUE и В —TRUE;
• A—TRUE, а В —FALSE;
• A-FALSE, а В-TRUE;
• A-FALSEhB-FALSE.
Покрытие утверждений
Здесь нужно следить за тем, выполнялась ли каждая строка кода по крайней мере,
один раз. Чтобы достичь 100%-го покрытия утверждений, понадобится выполнить
утверждение IF, причем оно должно принять значение TRUE для выполнения соот-
ветствующего требования THEN.
Покрытие ветвей
Здесь нужно следить за тем, была ли взята каждая ветвь или точка принятия реше-
ния при всех возможных исходах. Чтобы порытие было 100%-м, требуется два прохо-
да через условие IF, когда при одном проходе оно принимает значение TRUE, а при
другом — FALSE. Каждый цикл DO-WHILE и REPEAT-UNTIL также должен быть вы-
полнен при условиях TRUE и FALSE. Для утверждений CASE или SWITCH требуются
тестовые примеры, которые будут брать все возможные ветки, включая заданные по
умолчанию пути.
Покрытие условий
Оно известно также как покрытие предикатов и следит за тем, принимает ли каж-
дый операнд в комплексных логических выражениях значения FALSE/TRUE. Ком-
плексные логические выражения содержат операторы AND, OR и XOR. Поскольку
условие IF в этом Примере имеет логическое выражение с двумя компонентами, то
существует всего 22 (или 4) возможные комбинации значений TRUE/FALSE.
Каждый их этих типов покрытия содержит в себе более низкие уровни. Достиже-
ние 100%то покрытия ветвей означает 100%-ное покрытие утверждений. Аналогично
достижение 100%-го покрытия условий автоматтгчески приводит к удовлетворению
100%-го покрытия ветвей.
174
Глава 5
Спонсоры ответственны также за выбор меры покрытия, используемой для на-
блюдения. Цель всегда заключается в достижении 100%-го покрытия выбранной ме-
ры. Наблюдение за покрытием помогает определить, нужны ли дополнительные тес-
ты. Если поставленная цель — достичь 100%-го покрытия ветвей — может быть дос-
тигнута при выполнении сокращенного набора тестов, то на этом тестирование мож-
но прекратить, так как очевидно, что в данном приложении были реализованы все
важные пути. При покрытии ветвей меньше чем на 100% требуется выполнить до-
полнительные тесты, чтобы в конечном счете, достичь полного покрытия.
Невозможность достижения 100%-го покрытия объясняется рядом факторов.
1. Имеется недоступный код. Тестеры могут в разговоре с разработчиками под-
нять вопрос об удалении этого недоступного кода.
2. Исходный код имеет дополнительные функции, не документированные в ис-
ходной спецификации. Тестеры должны проконсультироваться с авторитет-
ным лицом проекта и определить, результат это неполной или неточной доку-
ментации и нужно ли ее подкорректировать.
3. На покрытие условий может также влиять компилятор, игнорируя части логи-
ческих выражений, которые не влияют на исход. Например, когда оценивается
логическое выражение XAND Y, если для Хуже задано значение FALSE, то пол-
ному выражению будет присвоено значение FALSE, не принимая во внимание
значение Y. Хотя такая функция “сокращения схемы” экономит время выпол-
нения, в невыполненных частях выражений могут быть скрыты ошибки. Тес-
терам следует прибегнуть к помощи разработчиков — выдвинуть на рассмотре-
ние все эти проблемы и оценить таким образом серьезность ситуации.
Хотя существует значительно большее число типов покрытия, три типа, которые
описаны в этом разделе, обеспечивают обширную обратную связь для оценки эффек-
тивности тестов, полученных из таблицы решений. При выборе между сокращенным
и расширенным набором тестов адекватным критерием может служить достижение
100%-го покрытия ветвей. Такая метрика покрытия позволяет определить, все ли
строки кода и все ли ветви использовались в тестовом примере. Для многих приложе-
ний 100%-ное покрытие ветвей — подходящая задача. Критичные прикладные систе-
мы безопасности, однако, требуют минимум 100%-го покрытия условий. Дополни-
тельную информацию о покрытии, включая другие, не рассматриваемые здесь типы,
можно почерпнуть из работ [Beizer 90], [Hamlet 01] и [Marick95]. Кроме того, в пуб-
ликации [Kit 95] предоставлены подробные примеры использования анализа покрытий.
Приложения со сложными данными
Для предыдущих примеров определить входные данные было относительно про-
сто. Клавиши на клавиатуре образовывали сходный список в примере с диалоговым
окном. Манипулирование диаграммой переходов для секундомера привело к созда-
нию набора тестов. Математический критерий дал начало созданию входных дан-
ных для тестирования приложения погашения долга ссуды. Для других систем раз-
мещение критической информации о тестах может оказаться не таким уж простым.
Другие типы таблиц
175
Следовательно, знания о системе становятся весьма существенными при разработке
эффективных тестов. В схематичном подходе, рассматриваемом в главе 2, представ-
лен один из методов извлечения существенной для тестирования информации. При
тестировании более сложных систем помощь также могут оказать таблицы.
Отображение обработки данных — это одна из областей, в которой используются
сложные данные. Прежде всего, это размер изображения, который меняется, скажем,
от 1 х 1 до 4096 х 4096 пикселей со всеми промежуточными неквадратичными раз-
мерностями, дающими в результате 224 четких размеров изображения. Изображение
может также варьироваться по разрядности атрибутов пикселей, например, у каждого
пикселя может быт 8 или 24 бита данных. Естественно, что тестируемая система
должна задавать разрядность атрибутов пикселей, а также максимальный и мини-
мальный размеры изображения, в противном случае такая система будет еще одним
примером плохих системных требований. В этом примере не только имеется огром-
ное число входных данных, учитывая, что простое изображение 256 х 256 содержит
2'6 пикселей, но существуют еще и специальные требования, касающиеся содержимо-
го изображения, размещения изображаемого объекта, значений пикселей и множест-
ва других специфических ограничений, налагаемых на изображение. Результаты мо-
гут принимать множество различных форм, например:
• другое изображение, имеющее свойства, совершенно отличные от свойств
входного;
• значение или набор значений, полученные на основе каких-либо вычислений,
выполненных по данным изображения;
• набор координат, связанных с важными зонами в исходном изображении.
В качестве примера будет рассмотрено изображение, состоящее из синего круга на
красном фоне. Один из алгоритмов мог бы преобразовать изображение в серой шка-
ле, дав в результате черный круг на темном фоне, тогда как другой алгоритм вычислит
координаты центра круга. Другой алгоритм мог бы сместить круг в другое положение
на изображении. Елю один алгоритм мог бы изменить исходный круг, сгенерировав
совершенно иной образ. Многие приложения, которые обрабатывают изображения,
генерируют совершенно новые изображения, изменяя значение каждого пикселя ис-
ходя из значений соседних пикселей. Возможности изменений тут бесконечны.
Даже без уточнения приложения, работающего с изображениями, это краткое
описание может дать обширные представления о некоторых проблемах, влияющих
на сложные системы. В данном примере тестируемая система берется при различных
типах изображений и запускается широкий диапазон алгоритмов, обрабатывающих
изображения и генерирующих различные типы результатов. К сожалению, невоз-
можно запустить все алгоритмы для всех возможных изображений, поскольку число
изображений бесконечно. Роль тестера заключается в выборе подходящего числа
изображений и тестов, которые дадут основания для уверенности в приложении, об-
рабатывающем изображения.
Исходная настройка теста заключается в определении типов изображений, кото-
рые будут использоваться в качестве входных данных. Сама по себе она приводит к
огромному набору изображений. В примере обработки изображений в табл. 5.11
176
Глава 5
перечислен тестовый набор, состоящий из шести операций по обработке изображе-
ний, которые запускаются на восьми различных изображениях. Входные условия
включают описания изображения и тех операций по обработке изображений, кото-
рые будут вызываться. В результате может получиться либо трансформированное
изображение, либо числовые значения. Тестер должен продумать подходящий список
входных изображений, иногда с помощью разработчиков. Поскольку для таких тестов
требуется указывать значительное количество деталей, в табл. 5.11 содержатся ссылки
на более полные описания тестового примера.
Детальное описание тестового примера должно содержать специфическую ин-
формацию о входных изображениях, которая либо задает специфический файл изо-
бражений, либо содержит инструкции относительно того, как создавать изображе-
ния. На рис. 5.3 показаны типичные тестовые примеры, в которых документируется
эта информация.
В этих тестах должно также быть определено то, как будут оцениваться их резуль-
таты. Если на выходе получается другое изображение, то тестер должен иметь воз-
можность определить, верное ли было сгенерировано изображение путем проведе-
ния побитового сравнения реального и ожидаемого изображений. Получить копию
ожидаемого изображения составляет трудность, поэтому некоторые тестеры могут
действительно создать файл изображения либо программируя значение каждого пик-
селя, либо используя программное обеспечение для редактирования изображений.
После того как изображение исследовано на предмет корректности, оно становит-
ся основой для сравнения в будущих тестах.
Еще один возможный формат— это перечисление ссылок на описание входных
данных и ожидаемых результатов. Такой формат аналогичен формату таблиц № 5,
показанному в табл. 4.8 в главе 4. В примере с обработкой изображения (табл. 5.) ис-
точник изображения задается в специальном файле, а входные данные заданы как
операции, которые должны быть выполнены. Ожидаемые результаты— это либо
файл, если генерируется другое изображение, либо одно или несколько числовых
значений, полученных в результате вычислений. Если результатом операции является
другое изображение, тест проще оценивать, проводя побитовое сравнение реального
и ожидаемого изображения. Этот детерминистический метод не оставляет места для
интерпретаций, однако в некоторых случаях описание ожидаемых результатов, по
которым тестер должен будет определять приемлемость реальных результатов, может
оказаться поверхностным.
В последнем подходе есть место для интерпретаций, но иногда это единственная
информация, доступная для тестера. При использовании недетерминистических
входных данных (например, получение прямого изображения) точное определение
ожидаемых результатов оказывается сложным, если такое определение вообще воз-
можно. Например, если взять два последовательные прямые изображения с теми же
предметами, можно обнаружить, что одно изображение смещено на один пиксель по
сравнению со вторым. Даже если описание ожидаемых результатов непонятное и не-
точное, команда проекта должна договориться относительно приемлемой степени
строгости результатов теста.
Таблица 5.11. Список тестовых примеров для приложения, обрабатывающего изображения
Тип изображения Размер изображения Инвертиро- вание Вращение 60 Вращение 90 Красный в синий Рассчитлтъзону Определитьцентр
горизонтальный скат 1024x1024 ин-10 B60-20 В90-1 ИЗ-100 рз-33 рст-10
горизонтальное изменение 480x480 ин-11 В60-21 В90-2 ИЗ-103 рз-34 рст-20
горизонтальное изменение 40x40 ин-12 В60-22 в90-3 из-24 рз-35 рст-30
голубая машина на дороге 1024x1024 ин-13 вбО-23 В90-4 из-31 рз-36 рст-40
черные и белые квадраты 480x768 ин-14 вбО-24 В90-5 из-402 рз-37 рст-50
черные и белые квадраты 480x480 ин-15 вбО-25 В90-6 из-102 рз-38 рст-60
черные и белые квадраты 1024x768 ин-16 вбО-26 В90-7 из-44 рз-39 рст-70
подсветки углов 2048 х 2048 ин-17 вбО-27 В90-8 из-45 рз-40 рст-80
178
Глава 5
Идентификация
ID тестового примера: из-563-а
Подсистема: цвета
Тестируемая система
Выпуск: 02.13_________________
Версия операционной системы- 4.1
Платформа '’С fanfrun__________
Проверка аппаратных средств изображения: АВ-03-х
Начальные установки
Сконфигурировать систему получения изображений для обработки изображений в разрешении 256 х 1024
Ввод данных
1. Загрузить и отобразить на экране изображение FlipRedGreen_256_1024.bmp
2. Ввести команду красное_на_синее
3. Ввести команду зеленое_на_красное
4. Ввести команду синее_на_зеленое
Ожидаемые результаты
1. На экрана видно изображение FlipRedGreen_256_1024.bmp
2. Все красные пикселы теперь заменены не синие
3. Все зеленые пикселы теперь заменены на красные
4. Все синие пикселы теперь заменены на зеленые
5. Результирующее ожидаемое изображение сохранено в OutputFlipRedGreen_256_1024.bmp
Действительные результаты
Записи теста
Дата проведения теста: Результаты: □Пройден □Провален
Тестер- Отчет о неполадках заполнен: □ Да □ Нет
Машина для тестирования: Номер отчета о неполадках:
Рис 5.3. Образец тестового примера по обработке изображений
Таблица 5.12. Результаты теста, обрабатывающего изображения
ID тестового примера Источник изображения Операции с изображением7 > Ожидаемые результаты Реальные результаты Статус у5<хлрошел/припалилсй
245 img_245.bmp Вычислить_площадь площадь = 1024 ✓ прошел
246 img_245.bmp Найти_среднюю_точку координаты = (200,768) ✓ прошел
247 img_907.bmp Инвертировать img_907_inv.bmp см. примечание в Iog_test247.txt провалился
248 img_33.bmp Повернуть_60 img_33_r60.bmp ✓ прошел
249 img_33.bmp Повернуть_90 img_33_r90.bmp ✓ прошел
250 img_33.bmp Инвертировать img_33_inv. Bmp см. Результаты в failed_test250.bmp провалился
251 img_33.bmp Вычислить_площадь площадь = 4042 площадь = 4000 провалился
252 img_906.bmp Инвертировать перевернутое изображе- ние лица человека J результаты сохранены в img_906_out bmp прошел
253 img_905.bmp Красное_на_синее красный блок заменен на синий в верхнем левом углу появилось несколько красных пикселов провалился
180
Глава 5
В ходе выполнения теста тестер заполняет последние два столбца, отведенные для
записи реальных результатов и результатов прохождения теста. Столбец “Реальные
результаты” может оказаться недостаточно большим для записи результатов прова-
лившихся тестов. Тестер может в каком-либо файле напечатать примечания или со-
хранить плохие изображения в отдельном файле.
В табл. 5. информация представлена очень кратко. Это сокращение— дополни-
тельная таблица контрольных проверок для отслеживания выполнения тестов записи
их результатов, а то, насколько детально описаны данные тесты, зависит от нужд ор-
ганизации. Тестер должен найти разумный компромисс между таблицей контрольных
проверок, чтобы быстро узнать, какие тесты запускались, и собрать достаточное ко-
личество информации, описывающей каждый тест в деталях.
Итак, мы обсудили предварительные этапы задания тестовых примеров, которые
будут работать со сложными входными данными. Для тестирования специфических
алгоритмов обработки изображений может понадобиться большое количество изо-
бражений. Каждое из этих изображений имеет определенные характеристики, чтобы
можно было реализовать различные функции в рамках одного алгоритма. Иногда
единственно точным описанием ожидаемых результатов является сам тест, а это оз-
начает, что тестеру может понадобиться мнение авторитетного лица. Таблицы, пока-
занные выше, — это всего лишь руководство по определению функций, для которых
требуется проводить тестирование. Основная задача заключается в выборе тех типов
тестов, которые будут запускаться, а не в случайном отборе изображений и определе-
нии того, на что похожи результаты.
Управление тестами
В некоторых таблицах, показанных ранее, помимо входных данных и ожидаемых
результатов содержится дополнительная информация. Например, тестер может за-
фиксировать факт прохождения теста, а также информацию о неполадках. Существу-
ют, конечно, и другие типы информации, которые неплохо сочетаются с использова-
нием таблиц тестов, например, размещение ресурсов как для оборудования, так и для
штата.
Планирование тестов
Планирование тестов — очень многогранная деятельность. Эта тема детально об-
суждается в главе 9, а здесь представлены лишь некоторые концепции. Даже когда
понимание всех типов деятельности весьма ограничено, таблицы предоставляют ин-
формацию, способствующую определению:
• предполагаемого календарного плана;
• кадровых ресурсов;
• необходимого оборудования.
В таблицах тестов иллюстрируется объем работ по тестированию. Таким образом,
таблицы играют роль средств коррекции календарных планов, однако это не зна-
чит, что руководство обязательно продлит календарный план (об этом можно только
Другие типы таблиц
181
мечтать!). Значительно более эффективным будет подтверждение аргументов факта-
ми. Утверждение: “Я не смогу провести 12064 теста за две недели”, которое сопрово-
ждается размахиванием огромной таблицей тестов, значительно более эффективно,
чем горестные стенания: “У меня не хватит времени, чтобы протестировать это!”
Приблизительные значения, как и в случае с числом потенциальных тестовых
примеров, можно получить, вычисляя число ячеек в таблице. Не все создаваемые тес-
товые примеры эквивалентны. Некоторые тесты, полученные из таблицы тестов
GUI, совершенно тривиальны, в то время как тесты, полученные из сценариев обра-
ботки изображения, значительно сложнее (они требуют массу времени только на то,
чтобы собрать данные). На некоторые тесты понадобится потратить время разработ-
чиков. Определение приемлемого количества времени, которое можно будет потра-
тить на настройку и выполнение тестов, — это чрезвычайно важная составляющая
планирования тестов. В главе 2 представлен образец предполагаемого календарного
плана.
Еще один аспект планирования тестов — кадровое обеспечение. Руководство мо-
жет воспользоваться таблицей тестов для распределения задач, внося имя тестера,
ответственного за реализацию и выполнение тестового примера, как показано в
табл. 5.13.
Определение оборудования заключается в перечислении аппаратного и программного
обеспечения, периферийных и других устройств, необходимых при проведении тес-
тов. Несмотря на то, что в таблице непосредственно не указывается необходимое
оборудование, тестер должен быть в состоянии просмотреть различные специфика-
ции тестов и получить предварительный список необходимого при тестировании.
Матрица тестовых примеров
В этой главе уже рассматривалось много примеров матриц. Термин “матрица” в
общем случае принято употреблять применительно к таблицам, в которых взаимо-
действие между столбцами и строками задает содержимое тестового примера. Кроме
того, сообществом людей, занимающихся программным обеспечением, было выделе-
но три типа матриц: таблица состояний, матрица прослеживаемости и матрица пере-
крестных ссылок.
Таблица состояний
Таблица состояний, которая была описана в разделе Конечный автомат, отображает
события на обработку состояний, а также несет в себе информацию из диаграммы пе-
рехода. Такое графическое представление с легкостью передает описание поведения
системы.
Таблица 5.13. Штатный план, показывающий распределение работы
Тип изображения Размер Инвертирование Вращение.СО Вращение_90 Кржный_е_синий Рассчитатъ_зону Определить,
изображения среднюю
точку
горизонтальный скат 1024x1024
горизонтальное изменение 480x480 Сэм Ли Трейси
горизонтальное изменение голубая машина на дороге черные и белые квадраты черные и белые квадраты черные и белые квадраты подсветка углов 40x40 1024x1024 Лу 480x768 480x480 Крис 1024x768 2048x2048
Другие типы таблиц 183
Матрица прослеживаемости
Матрица прослеживаемости отображает тестовые требования на тестовые примеры
и методики теста, которые его реализуют, как показано в табл. 4.19. Достоинство мат-
рицы прослеживаемости состоит в возможности определить тестовые примеры, ко-
торые были получены на основе специфического набора требований, так что тестер
может легко определить, на какой тест повлияют изменения в требованиях. В случае
неудачного выполнения теста для установления того, был ли тестовый пример задан
корректно, также может понадобиться отследить требование, являющееся источни-
ком для тестового примера.
Матрица перекрестных ссылок
Третий тип матриц — это матрица перекрестных ссылок. При общем подходе к зада-
нию тестовых примеров используются таблицы, содержащие перечисление возмож-
ных входных данных и действий, которые будут к ним применены. Каждая из таких
пар (входные данные/действия) составляет основу для тестового примера или мето-
дики теста, если для полного определения теста требуется дополнительная информа-
ция. В табл. 5.14 показана матрица перекрестных ссылок, а в ее ячейках сделаны
ссылки на тесты, которые документированы где-то в другом месте. Некоторые из этих
тестов являются тестовыми примерами, помеченными как тп №, другие представля-
ют собой методики теста, помеченные как мт №, остальные тесты помечены префик-
сом а и ст. Схема наименований для тестовых примеров меняется от проекта к проек-
ту. При использовании схемы наименований тесты в матрице тестовых примеров
сортируют по соответствующим группам. Дополнительную информацию можно по-
лучить, используя примечания. Звездочка указывает на то, что идентификатор теста в
таблице появляется несколько раз. Для отдельных тестовых примеров или методик
тестов весьма уместно будет реализовать несколько функций, перечисленных в таб-
лице. Чтобы установить приоритеты, распределение тестов, факт прохождения теста
или другую уместную информацию, можно использовать выделение. Затемненные
ячейки в табл. 5.14 указывают на тесты с высоким приоритетом.
Преимущество матрицы перекрестных ссылок заключается в том, что она играет
роль краткого справочника по широкому ряду тестовых наборов, указывая на резуль-
таты проведения определенных тестов. Такая таблица служит также индексом в набо-
ре описаний тестовых примеров, детали которых записаны где-то в другом месте в
виде страницы в массе документов тестового примера или в виде отдельного файла на
диске. В некоторых больших наборах тестов этот тип матриц можно использовать
вместо оглавлений, функционирующих как указатель в интерактивном режиме на
файл с тестовым примером, где каждый тестовый пример сохранен в виде отдельного
файла в сети.
Разница между матрицей прослеживаемости и матрицей перекрестных ссылок ед-
ва уловима. Основное отличие заключается в том, что в матрице прослеживемости
каждому тестируемому требованию присваивается уникальный идентификатор. В за-
висимости от терминологии, используемой в каждой организации, или если в специ-
фикации продукта каждое требование уже помечено уникальным идентификатором,
184
Глава 5
эти два типа матриц можно считать идентичными. Задача тут состоит в структуриза-
ции таблиц таким образом, чтобы максимизировать распределение информации.
Таблица 5.14. Матрица перекрестных ссылок
входные данные НгЗ — входные — данные
входные данные №1 входные данные №2 входные данные №4 входные данные №5
исходное состояние 1 тп101 мт 21 тпЮ ст 55
исходное состояние 2 тп 102 мт 22 ст 65*
исходное состояние 3 тп 103 мт 23 а-899 тп 35 ст 65* мт 432
исходное состояние 4 тп 104 мт 24 а-8988 тп 351 ст 72
исходное состояние 5 тп 105 мт 25 а-897 ст65* мт 442
исходное состояние 6 тп 107 мт 25 а 896 ТП 4779
исходное состояние 7 тп 108 мт 27 а-895
" *" означает, что тестовый пример в таблице встречается несколько раз.
иные ячейки указывают на высокий приоритет тестов.
Отслеживание проведения теста
Таблицы можно приспособить под отслеживание информации, касающейся вы-
полнения теста и его результатов. Тестеры могут отчитываться о ходе дел и прохож-
дении тестов, записывая в каждую ячейку нужные сведения. Таким образом, можно
быстро составить отчет о том, какие тесты были пройдены успешно, какие провали-
лись или еще не были выполнены. В главе 4содержится несколько примеров записи
результатов теста в таблицы.
Таблицы можно также использовать для отслеживания информации, связанной с
выполнением теста. В табл. 5.15 отслеживается следующая информация.
• Версии аппаратного и программного обеспечения.
• Машина, используемая для выполнения теста (предполагая, что существует од-
на машина для тестирования).
• Дата выполнения теста.
Другие типы таблиц
185
• Имя тестера.
• Информация из отчета о неполадках для провалившихся тестов.
• Отметка о том, выполнялся ли тест повторно.
Дополнительные примеры использования таблиц для отслеживания тестового
примера можно найти в работе [Black 99].
Резюме
Многие тестеры программного обеспечения широко используют таблицы. Табли-
цы применяются на протяжении всего процесса тестирования, начиная с поэлемент-
ного тестирования и заканчивая тестированием на уровне системы, они используют-
ся не только для преобразования в табличную форму документов реальных тестовых
примеров, но и для записи информации о выполнении тестов, их прохождении и
управлении тестами. Использование таблиц в ходе выполнения тестового примера
заключается в регистрации такой информации, как реальные результаты, факт про-
хождения теста, версия приложения, дата и имя тестера.
Описание приложения при помощи диаграммы переходов несложно преобразо-
вать в эквивалентную таблицу состояний, из которой потом легко выводятся тестовые
примеры.
Для приложений, где используется большое количество комбинаций сложных
данных, в таблицах тестов могут быть сделаны ссылки на файлы, которые содержат
реальное описание входных данных и исходных результатов.
С помощью таблиц решений можно отслеживать сложные комбинации условий и
связанные с ними результирующие действия. Уменьшение таблицы решений состоит
в объединении логически эквивалентных правил и, следовательно, создании меньше-
го числа правил, которые затем преобразуются в меньшее число тестовых примеров.
При выполнении тестов оценку эффективности тестовых примеров можно произ-
вести при помощи анализа покрытия, наблюдая за тем, какая часть кода выполняется.
Существует множество типов мер покрытия, наиболее распространенные — покры-
тия утверждений и ветвей.
Таблицы предоставляют возможность управлять задачами тестирования. Для со-
ставления предполагаемого календарного плана можно использовать такой размер
таблицы, с помощью которого можно оценить приблизительное число тестовых
примеров. Установка приоритетов для каждого тестового примера помогает опреде-
лить наиболее важные тесты. Дополнительное расширение таблиц позволяет регист-
рировать информацию о штате и размещении ресурсов. Отмечая тесты, которые уже
были выполнены, и связанные с ними результаты прохождения теста, руководство
может легко оценить текущее состояние процесса тестирования.
Еще один тип таблиц— это матрицы прослеживаемости, которые отображают
требования на соответствующие тестовые примеры. Матрицы прослеживаемости по-
могают определить, какие тестовые примеры выполнялись для обоснования требова-
ний и какие требования нужны для тестовых примеров.
Таблица 5.15. Отслеживание информации о выполнении теста
Среда тестирования Прохождение теста Отслеживание неполадок
ID Версия'; при- ложения Версия аппарат-. ного обес- печения Машина ДЛЯ Тестиро- вания Прошел/ прова- лился г*-; v , Дата про- ведения теста Имя тестера Номер отчета о про- блемах Решен- ные проб- лемы Повтор- ный тест: версия приложе- ния Повтор- ный тесл дата вы- полнения Повторный тест: имя тестера Статус повтор- ного теста
тестового примера
dIOOl d1002 d1003 03.04a 03.04a 03.04b 1-2.d 1-2.d 1-2.d №3 №3 №3 Прошел Прошел Прова- 12 марта 12 марта 12 марта Фрэд Фрэд Джо №2563 да 03.05 17 марта Фрэд Прошел
d1004 d1005 03.04b 03.04a 1-2.d 1-2.d №3 №3 лился Прошел Прова- 12 марта 12 марта Джо Фрэд №2569 да 03.05 17 марта Фрэд Прова-
d1006 03.05 1-2.g №2 лился Прова- лился 12 марта Фрэд №2571 нет лился
ГЛАВА
Тестирование
объектно-ориентированного ПО
Введение
При тестировании приложений, созданных с использованием объектно-ориенти-
рованного проектирования, применяются многие из тех методов, которые были опи-
саны в предыдущих главах.
В этой главе будут рассмотрены следующие примеры, в которых проиллюстриро-
вано тестирование объектно-ориентированного ПО.
• Проектирование тестов на уровне системы с помощью схемы.
• Проектирование тестов на уровне системы с помощью прецедентов.
• Проектирование поэлементных тестов для совокупности классов.
• Проектирование поэлементных тестов для иерархии классов.
Задача заключается в составлении каких-либо парадигм проектирования тестов,
чтобы можно было начать тестирование объектно-ориентированного ПО. Ограни-
ченные знания об объектно-ориентированном ПО никоим образом не повлияют на
работу тестера-профессионала. Эту главу, конечно, нельзя назвать ни учебным посо-
бием по объектно-ориентированному проектированию, ни всеохватывающим руко-
водством по объектно-ориентированному тестированию, однако здесь все же дается
определение наиболее важным концепциям объектно-ориентированного програм-
мирования. Более детальная информация об объектно-ориентированном тестирова-
нии содержится в работах [Binder 00], [Marick95] и [McGregor 01].
188
Глава 6
Сравнение объектно-ориентированного
и процедурного программирования
В ходе объектно-ориентированного программирования создаются функции, кото-
рых нет в процедурном программном обеспечении. Объектно-ориентированное ПО
использует классы (как основной элемент), а также наследование и инкапсуляцию,
которые действуют на классах. При процедурном программировании контролируют-
ся потоки между функциями программного обеспечения. Тестирование таких объ-
ектно-ориентированных функций требует новых стратегий.
Объектно-ориентированная терминология
Класс— это план, согласно которому задаются данные и поведение (лсетоды), общие
для всех классов определенного типа. Объект — это представитель отдельного класса.
Можно провести общую аналогию, представив себе форму для печенья. Класс — это
форма для печенья, которая задает то, как это печенье будет выглядеть. Объекты —
это печенье, созданное с помощью какой-то одной формы.
Наследование дает возможность получать новые классы из уже существующих. До-
черний класс {производный класс) наследует все данные и поведение (методы) корен-
ного класса {базового класса). К нему также можно добавить новые функции или пере-
определить уже существующие.
Инкапсуляция обеспечивает программистов четко заданным интерфейсом для
функций объекта таким образом, чтобы предотвратить возможность непосредствен-
ного доступа программиста к внутреннему коду объекта.
В объектно-ориентированном программировании также имеется возможность or
раничить доступ к членам класса (данным и методам). Объект всегда может получить
доступ к членам, заданным в рамках его собственного класса. Члены класса, отмечен-
ные как открытые, становятся внешне видимыми, позволяя объектам различных
классов получать доступ к этим открытым членам. Закрытые члены, напротив, дос-
тупны только объектам данного класса, — даже производный класс не может получить
доступ к частной информации родительского. Эти правила доступа проиллюстриро-
ваны в разделе “Тестирование наследования”.
Тестирование ПО
Во многих случаях объектно-ориентированное ПО можно рассматривать как при-
ложение, разработанное на основе определенного проектного подхода. Моделирова-
ние— это очень важная часть объектно-ориентированной разработки. Проектный
подход включает объектно-ориентированную декомпозицию и специализированные
диаграммы, которые описывают логические и физические модели разрабатываемой
системы. Хорошо продуманный объектно-ориентированный проект позволяет легко
проследить соответствие между требованиями и проектированием кода. <
Как было показано в предыдущих главах (без оглядки на методологию проектиро-
вания), при тестировании всегда задействуются несколько уровней, включая тестиро-
вание системы и поэлементное тестирование. Теперь в рамках этих двух категорий
Тестирование объектно-ориентированного ПО
189
будут рассматриваться приложения, созданные согласно объектно-ориентированным
концепциям.
Тестирование системы не зависит от процессов, используемых для создания како-
го-либо приложения. Тестер оценивает приложение с точки зрения пользователя.
Внутренние детали проектирования не важны и не влияют на определение тестов.
Разработка тестовых примеров выполняется, исходя из поведения приложения,
представленного в виде прецедента или в какой-либо другой форме требований. Та-
ким образом, для задания тестовых примеров на уровне системы знания об объектно-
ориентированном программном обеспечении вовсе не обязательны.
При поэлементном тестировании любого программного приложения требуется
знание о программировании и доступ к деталям реализации. Когда приходится иметь
дело с объектно-ориентированным кодом, смысл слова элемент несколько изменяется.
Класс — это наименьший элемент, который можно компилировать. Главное отличие
между двумя методологиями проектирования состоит в том, что при поэлементном
тестировании процедурного программного обеспечения имеется непосредственный
доступ к элементам (процедурам или функциям), в то время как доступ к данным и ме-
тодам класса может быть более ограниченным. Исчерпывающее поэлементное тести-
рование заключается в подтверждении того, что все методы в рамках класса и его ин-
терфейс функционируют так, как было задумано. Проектирование тестовых приме-
ров для наследования класса требует дополнительного рассмотрения (см. раздел “Тес-
тирование наследования”). Важно отметить, что некоторые объектно-ориентирован-
ные языки могут реализовываться процедурным способом, требуя, таким образом,
процедурной стратегии тестирования.
Большинство методов задания тестовых примеров одинаково применимы как для
процедурно разрабатываемых приложений, так и для приложений, разрабатываемых
с помощью объектно-ориентированного проектирования. Основное отличие, однако,
состоит в выполнении тестовых примеров. Поэлементное тестирование реализованно-
го с помощью объектно-ориентированного проектирования ПО требует таких усло-
вий выполнения, при которых можно будет работать с инкапсуляцией, как показано в
разделе “ Сложности проведения тестов ”.
Пример тестирования системы
В системе “Путеводитель” для местного торгового центра есть несколько торговых --
точек, которые относятся к следующим категориям.
• Женская одежда (3 торговые точки).
• Мужская одежда (2 торговые точки).
• Детская одежда (4 торговые точки).
• Женская обувь (2 торговые точки).
• Мужская обувь (2 торговые точки).
• Цветы (1 торговая точка).
• Подарки (5 торговых точек).
• Рестораны (5 торговых точек).
190 Глава 6
Путеводитель по пассажу взаимодействует с двумя типами действующих лиц. Тер-
мин действующее лицо применим к любой личности, аппаратному устройству или дру-
гой системе, которая взаимодействует с приложением. В этом примере действующи-
ми лицами будут:
• покупатели, которые разыскивают нужную торговую точку в пассаже;
• администраторы, которые обновляют названия торговых точек и их размещение.
Этот пример показан на рис. 6.1-6.5. Входные данные пользователя описаны на
рис. 6.1. На экране главного меню (рис. 6.2) у пользователя запрашивается тип торго-
вой точки.
Команды покупателя: главное меню
1. Покупатель прикасается к клавише названия одной из категорий торговых точек
в списке и получает список торговых точек, из которых можно выбирать.
2. Покупатель прикасается к клавише карты и на экране появляется карта пассажа.
3. Покупатель прикасается к клавише справки и получает экран справки.
Команды покупателя: список торговых точек
4. Покупатель прикасается к клавише названия конкретной торговой точки и на экране
появляется карта, на которой высвечивается положение этой торговой точки.
5. Покупатель прикасается к клавише главного меню и возвращается обратно
к главному меню.
6. Покупатель прикасается к клавише справки и получает экран справки.
Команды покупателя: карты
7. Покупатель прикасается к кнопке печати и получает распечатку нужной карты.
8. Покупатель прикасается к клавише ВЕРНУТЬСЯ НАЗАД и получает отображение
предыдущего экрана.
9. Покупатель прикасается к клавише главного меню и возвращается к главному меню.
10. Покупатель прикасается к клавише справки и переходит к справочному меню.
Команды покупателя: справка
11. Покупатель нажимает клавишу ВЕРНУТЬСЯ НАЗАД и получает отображение пре-
дыдущего экрана.
12. Покупатель прикасается к клавише главного меню и возвращается к главному меню.
Команды администратора
13. Администратор добавляет название новой торговой точки.
14. Администратор удаляет название торговой точки.
15. Администратор видоизменяет карту пассажа.
Рис. 6.1. Варианты входных данных для путеводителя по пассажу
Тестирование объектно-ориентированного ПО
191
На рис. 6.3 представлено меню со списком торговых точек. Экран с главным меню
и экран со списком торговых точек позволяют покупателю сделать запрос на печат-
ную карту пассажа (рис. 6.4). На всех экранах у пользователя имеется возможность
выбрать функцию справки (рис. 6.5). Текущие требования не предусматривают каких-
либо подробностей в отношении командного интерфейса администратора.
Путеводитель по пассажу
Главное меню
Выбрать тип торговой точки:
Детская одежда
Цветы
Подарки
Мужская одежда
Мужская обувь
Рестораны
Женская одежда
Женская обувь
Рис. 6.2. Сенсорный экран главного меню
Путеводитель по пассажу
Список торговых точек
Выбрать тип торговой точки
Список торговых точек
в данной категории:
торговая точка №1
торговая точка №2
торговая точка Ns3
Рис. 6.3. Сенсорный экран списка торговых точек
192
Глава 6
Путеводитель по пассажу
Карты
Карг пассажа или
специальная карта,
на которой показано
расположение
торпхой точки
Рис. 6.4. Сенсорный экран карты
Путеводитель по пассажу
Справка
Справочная информация
главного меню,
списка торговых точек
микарт
Рис. 6.5. Сенсорный экран справки
Входная пользовательская информация, представленная в этом разделе, играет
роль требований к “Путеводителю”. Как следует из предыдущих глав, неполные тре-
бования сильно обременяют тестера в смысле необходимости доопределения отсут-
ствующей информации и согласования этих вопросов с авторитетным лицом проекта.
Для разработки тестовых примеров на уровне системы существуют различные
стратегии. В этой главе рассматриваются два подхода. В первом примере будет ис-
пользоваться схематичный метод. Схема служит полезным инструментом для группи-
ровки взаимосвязанной информации. Во второй стратегии используются прецеденты,
которые ориентированы на сценарии действующих лиц. Эти независимые примеры
Тестирование объектно-ориентированного ПО
193
приводят в результате к похожим, хотя и неидентичным тестовым примерам. На вы-
бор тестером определенного подхода влияет несколько факторов, например:
• опыт и личные предпочтения тестера;
• формат, в котором представлены системные требования;
• наличие инструментов, которые могут помочь в разработке тестовых примеров.
Иногда тестер может начать с одной стратегии, а затем переключиться на другую,
если с использованием исходного метода возникают трудности.
Тестовые примеры на основе схемы
Поскольку описание входных данных имеет вид списка, организация этой инфор-
мации в схему является вполне обоснованным подходом. Для других приложений бо-
лее подходящим методом может оказаться структурирование информации с помощью
таблиц (см. главу 4). В этом примере, чтобы не усложнять описание тестовых приме-
ров, интерфейсы покупателя и администратора будут обрабатываться отдельно.
Команды пользователя
Схему можно создать, проводя реорганизацию вариантов входных данных в по-
следовательность, которую обычно задает пользователь. Список категорий торговых
точек также становится частью схемы. На рис. 6.6 показана результирующая схема.
В квадратных скобках содержится ссылка на исходное требование. Скобки с числами
указывают на описание вариантов входных данных, показанное на рис. 6.1, в то время
как элементы, помеченные знаком [Д], ссылаются на текущую конфигурацию пассажа.
Чтобы задать различные сценарии для покупателя, функции карты и справки по-
являются по несколько раз под различными элементами. Таким образом освещаются
различные контексты, в которых вызываются эти функции. Например, результирую-
щие данные вызова функции справки из главного меню отличаются от полученных
при вызове с сенсорного экрана справки. Аналогично, после нажатия кнопки
ВЕРНУТЬСЯ НАЗАД на сенсорном экране будут отображаться различные меню в за-
висимости от предыдущего состояния.
В этой конкретной схеме экран главного меню и список торговых точек разделе-
ны. Используя второй подход, можно вставить копию раздела со списком торговых
точек под каждую категорию торговых точек, копируя, таким образом, все точки под
номером 2в1.1.1.1,1.1.2.1и т.д. При этом размер схемы сильно увеличится и придет-
ся задавать тестовые примеры для каждой возможной комбинации входных данных
покупателя. Чтобы упростить тестирование и уменьшить число тестов, используем
одну категорию торговых точек и одно связанное с ней название торговой точки,
чтобы можно было выполнить сценарий под элементом № 2. Теперь нужно обсудить
компромиссы и доказать, что этот подход укладывается в рамки допустимой степени
риска.
Представленная схема — лишь одна из возможных интерпретаций описания поль-
зовательского интерфейса. Разные тестеры создают различные схемы, но суть остает-
ся той же. Основная задача заключается в перечислении действий пользователя, что-
бы можно было создать тесты, охватывающие все наиболее важные сценарии.
194
Глава 6
1 Главное меню
1.1 [1] Покупатель прикасается к кнопке одной из категорий торговых точек в списке и получает
список торговых точек, из которых можно выбирать
1.1.1 [Д] женская одежда (3 торговые точки)
1.1.2 [Д] мужская одежда (2 торговые точки)
1.1.3 [Д] детская одежда (4 торговые точки)
1.1.4 [Д] женская обувь (2 торговые точки)
1.1.5 [Д] мужская обувь (2 торговые точки)
1.1.6 [Д] цветы (1 торговая точка)
1.1Л [Д] подарки (5 торговых точек)
1.1.8 [Д] рестораны (5 торговых точек)
1.2 [2] Покупатель прикасается к клавише карты и на экране появляется карта пассажа
1.2.1 [7] Покупатель прикасается к кнопке печати и получает распечатку карты
1.2.2 [8] Покупатель прикасается к клавише ВЕРНУТЬСЯ НАЗАД и получает отображение
•редыдущег. з экрана
1.2.3 [9] Покупатель прикасается к клавише главного меню и возвращается к главному меню
1.2.4 [10] Покупатель прикасается к клавише главного меню и возвращается к главному меню
1.2.4.1 [11]Покупательнажимаетнаклавишу ВЕРНУТЬСЯ НАЗАД 1
и получает отображение предыдущего экрана
1.2.4.2 [ 12] Покупатель прикасается к клавише главного меню и возвращается к главному меню
1.3 [3] Покупатель прикасается к клавише справки и получает экран справки
1.3.1(11] Покупатель нажимает на клавишу ВЕРНУТЬСЯ НАЗАД и получает отображение
предыдущего экрана
1.3.2(12] Покупатель прикасается к клавише главного меню и возвращается к главному меню
2 Список торговых точек
2.1 [4] Покупатель прикасается к названию конкретной торговой точки и на экране появляется карта,
на которой высвечивается ее положение
2.1.1 [7] Покупатель прикасается к кнопке печати и получает распечатку карты
2.1.2 [8] Покупатель прикасается к клавише ВЕРНУТЬСЯ НАЗАД и получает отображение
предыдущего экрана
2.1.3 [9] Покупатель прикасается к клавише главного меню и возвращается к главному меню
2.1.4 [10] Покупатель прикасается к клавише главного меню и возвращается к главному меню
2 1.4.1 [11] Покупатель нажимает на клавишу ВЕРНУТЬСЯ НАЗАД
и получает отображение предыдущего экрана
2.1.4.2 (12] Покупатель прикасается к клавише главного меню и возвращается к главному меню
2.2 [5] Покупатель прикасается к клавише главного меню и возвращается к главному меню
2.3 [6] Покупатель прикасается к клавише справки и получает экран справки
2.3.1 [11] Покупатель нажимает на клавишу ВЕРНУТЬСЯ НАЗАД и получает отображение
предыдущего экрана
2.3.2 [12] Покупатель прикасается к клавише главного меню и возвращается к главному меню
Рис. 6.6. Схема для входной последовательности покупателя
Схема состоит из 23 листьев, каждый из которых дает в результате тестовый при-
мер. В приложении В1 содержится полная таблица из 23 тестовых примеров, некото-
рые из них показаны в табл. 6.1. В столбце “Источник теста” сделана ссылка на эле-
мент в схеме, в котором, в свою очередь, сделано указание на исходное требование к
пользовательскому интерфейсу.
Тестирование объектно-ориентированного ПО
195
Таблица 6.1. Выбор тестовых примеров на уровне системы для интерфейса покупателя
(полный список содержится в приложении 1)
ПП-1
1.1.1
Из главного меню:
выбрать "Женская
одежда"
Появляется экран со списком
торговых точек и перечисля-
ются 3 торговые точки с жен-
ской одеждой
ПП-5 1.1.5 Из главного меню: Появляется экран со списком
выбрать "Мужская торговых точек и перечисля-
обувь" ется 2 торговые точки с муж-
ской обувью
ПП-11 1.2.3
Из главного меню:
а) нажать кнопку
КАРТА
б) нажать кнопку
ГЛАВНОЕ МЕНЮ
а) Выдается карта пассажа,
размещенная на экране
б) Возврат к главному меню
ПП-17 2.1.2
Из главного меню:
а) выбрать
"Мужская одежда"
б) выбрать назва-
ние второй торго-
вой точки из спи-
ска
а) Список торговых точек и
список из 2 торговых точек
мужской одежды
6) Выдается карта пассажа,
размещенная на экране
в) Возврат к экрану со спи-
ском торговых точек, на кото-
в) нажать кнопку
ВЕРНУТЬСЯ НАЗАД
ром перечислены две торго-
вые точки мужской одежды
196
Глава 6
Команды администратора
Для создания тестов необходимо понять, как администратор взаимодействует с
системой. Схема на рис. 6.7 поможет тестеру организовать информацию так, чтобы
можно было установить отсутствующие требования. Большая часть добавленных эле-
ментов была получена на основе разумных предположений, которые охватывают
множество возможных ситуаций (например, вопросы, связанные с наличием катего-
рии или вводом данных). Объединение различных условий приводит к всесторонно-
сти тестовых примеров. '
1 Команды администратора
1.1 (13] Администратор добавляет название новой торговой точки
1.1.1 Категория существует
1.1.1.1 Верное название торговой точки
1.1.1.2 У названия торговой точки неверный формат
1.1.1.3 Такое название торговой точки в этой категории уже существует
1.1.2 Категории не существует
1.1.2.1 Верное название торговой точки
1.1.2.2 У названия торговой точки неверный формат
1.1.2.3 Такое название торговой точки в этой категории уже существует
1.2 [14] Администратор удаляет название торговой точки
1.2.1В обновленной категории ноль торговых точек
1.2.2 В обновленной категории одна или несколько торговых точек
1.3 [15] Администратор видоизменяет карту пассажа
Рис. 6.7. Исходная схема для интерфейса администратора
Когда в требованиях отсутствует нужная информация, тестеру лучше всего обра-
титься с этой проблемой к авторитетному лицу проекта. Ниже перечислена инфор-
мация, которой не хватает в рассматриваемом примере.
1. Как администратор выбирает категории, чтобы добавить торговую точку в су-
ществующую категорию?
2. Как администратор создает новую категорию? Что если название категории
уже существует?
3. Каков формат названий категорий?
4. Можно ли присвоить одно название нескольким категориям?
5. Когда администратор выбирает название перемещаемой торговой точки, дол-
жен ли он также задавать категорию?
6. Что произойдет при перемещении названия торговой точки, если во время об-
новления категория окажется пустой?
7. Как администратор задает название торговой точки, которое нужно перемес-
тить (указывает и щелкает на изображении карты; выбирает название торговой
точки из списка; набирает название торговой точки)?
8. Как администратор задает название торговой точки, которую нужно добавить?
Тестирование объектно-ориентированного ПО
197
9. Каким образом администратор задает новое расположение торговой точки?
Набирает номер, соответствующий расположению на карте?
10. Может ли администратор изменить расположение существующей торговой
точки, щелкая и перетягивая изображение на карте пассажа?
После того как авторитетное лицо проекта доопределит требования, тестеры за-
капчивают составление схемы, а затем переходят к заданию тестовых примеров. Если
проект находится в критическом состоянии, тестеры могут сами взяться за совершен-
ствование требований, часто восполняя отсутствующую информацию обоснованны-
ми предположениями. Это может оказать огромную помощь авторитетному лицу7 про-
екта, утверждающему лишь более совершенное описание вместо того, чтобы выде-
лять средства на завершение определения продукта, экономя, таким образом, время и
силы.
Тестовые примеры на основе прецедентов
Прецеденты — это эффективный механизм документирования требований. Они
описывают поведение приложения с точки зрения пользователя. Правильно сконст-
руированный прецедент можно легко преобразовать в тестовый пример. Полный на-
бор прецедентов редко описывает полный набор системных требований, так как в
наборе прецедентов пропущена информация, относящаяся к тестам характеристик
под нагрузкой.
В рассматриваемом примере прецеденты состоят из четырех разделов.
1. Основной заголовок. В этом разделе содержится уникальный идентификатор и
краткое описание прецедента.
2. Гарантии успеха. В этом разделе описывается конечное состояние, возникаю-
щее при успешном завершении теста,
3. Основной успешный сценарий. В разделе описывается простейший сценарий,
в котором каждый этап завершается нормально и нет необходимости в восста-
новлении системы.
4. Расширение. Здесь перечисляются альтернативные возможности, которые от-
ветвляются от этапов в основном успешном сценарии. В зависимости от ре-
зультирующих действий расширения могут возвращаться к основному сцена-
рию или достигать своего собственного завершения (например, генерируя не-
удачу или совершенно отличный результат).
В прецедентах содержится дополнительная информация (например, предусловия,
основные действующие лица, неудачные конечные условия, триггеры). Более деталь-
но прецеденты рассматриваются в работе [Cockburn 01].
В предыдущем примере, даже когда информация была неполной, создавать тесты
помогала схема. Здесь же роль связующего звена для преобразования описания вход-
ных данных пользователя в тестовые примеры играют прецеденты. Три таких преце-
дента показаны на рис. 6.8-6.10. В прецеденте № 3 (рис. 6.10) можно предположить,
что интерфейс администратора существует, и обдумать общую командную последова-
тельность.
198
Глава 6
Прецедент № 1. Покупатель ищет в пассаже определенную торговую точку.
Г арантии успеха
Покупатель получает распечатку карты для желаемой торговой точки.
Основной сценарий успеха
1. Покупатель выбирает категорию торговых точек.
2. Покупатель выбирает название торговой точки.
3. Покупатель выбирает функцию печати.
Дополнения
1а . Покупатель хочет получить справку при выборе категории торговой точки.
1б. Нет подходящей категории торговых точек
2а. Покупатель хочет получить справку при выборе названия торговой точки.
26. Желаемой торговой точки не существует.
Рис. 6.8. Прецедент №1
Прецедент № 2. Покупатель ищет все торговые точки
с подарками и хочет получить карту с кратчайшим путем к каждой из них.
Гарантии успеха
Покупатель получает распечатку карты для каждой торговой точки с подарками
Основной сценарий успеха
1. Покупатель выбирает категорию торговой точки,
2. Покупатель выбирает название первой торговой точки
3. Покупатель выбирает функцию печати.
4. Покупатель возвращается к списку торговых точек.
5. Покупатель выбирает второе название торговой точки.
6. Покупатель выбирает функцию печати.
Дополнения
(нет)
Рис. 6.9. Прецедент №2
Тестирование объектно-ориентированного ПО
199
_______________________________________________________________
Прецедент № 3. Администратор
добавляет в "Путеводитель" новую торговую точку.
Гарантии успеха
В списке торговых точек появляется новое название.
На карте пассажа появляется новое положение.
Основной сценарий успеха
. 1. Администратор выбирает категорию торговой точки.
2 Администратор добавляет название торговой точки.
3 . Администратор обновляет карту.
Дополнения
1а. Нет подходящей категории.
2а Название торговой точки уже существует.
За. Выбранное положение уже выделено под другую торговую точку.
Рис. 6.10. Прецедент №3
Каждый прецедент позволяет сгенерировать несколько тестовых примеров. В ос-
новном успешном сценарии, который является самым простым и наиболее общим
описанием прецедента, находится информация для первого прецедента. Данный
Сценарий также служит основой для последующих тестов. Чтобы убедиться, что сис-
тема правильно оперирует этим событием, для каждого расширения должен сущест-
вовать, по крайней мере, один тестовый пример. В табл. 6.2 перечислены тестовые
примеры, полученные на основе прецедента № 1. В приложении В2 содержатся тес-
товые примеры, полученные из каждого прецедента. Нумерация тестовых примеров
основывается на соответствующих прецедентах. Для наглядности в таблицу записано
расширение, которое согласуется с тестовым примером.
Этот набор тестовых примеров явно отличается от полученного в разделе 6.3.1 — в
данном примере прецеденты описывают намерения действующих лиц, тогда как в схеме
перечисляются комбинации входных данных. Здесь нет требований, в которых указы-
валось бы, что произойдет, если покупателю не удастся найти желаемую торговую
точку в пассаже, как в тестовом примере п1-3.
Разные тестеры могут предлагать различные тестовые примеры, которые являют-
ся производными одного и того же прецедента. Возникает вопрос: будет ли этот но-
вый набор тестовых примеров реализовывать все варианты входных пользователь-
ских данных? В матрице перекрестных ссылок в табл. 6.3 отслеживается, какие из ва-
риантов входных данных (из списка на рис. 6.1) соответствуют тестовому примеру.
Матрица не может адекватно отображать команды администратора вследствие не-
полноты требований. Даже если в матрице показано, что в четырех тестовых приме-
рах используется вариант входных данных № 13 (добавить название новой торговой
точки), не существует различия между успешным добавлением, отсутствием катего-
рии торговых точек или неверным названием торговой точки, хотя все они являются
200 Глава 6
отдельными ситуациями, которые относятся к разным прецедентам. Несмотря на эти
недостатки, матрица помогает обнаружить необходимость в дополнительных тесто-
вых примерах.
Не только в ПО, создаваемом путем объектно-ориентированного проектирования,
но и во многих приложениях прецеденты используются для полного документирова-
ния системных требований. Прецеденты помогают преобразовывать описание поль-
зовательского интерфейса в тестовые примеры (что и было показано в этом примере).
Поэлементное тестирование классов
Классы являются характерной особенностью объектно-ориентированного про-
граммирования, однако подходы к заданию тестовых примеров часто остаются теми
же, что и для процедурных приложений. В отдельную категорию входят классы, реа-
лизующие конечные автоматы. Диаграммы переходов и таблицы состояний, как опи-
сывалось в главе 5, без труда приводят к тестовым примерам. Использование другого
метода проектирования тестов, называемого тестированием ортогонального массива,
эффективно, когда перестановка небольшой части входных данных генерирует ог-
ромное число тестовых примеров.
Далее будут рассмотрены две специфические области в объектно-ориентирован-
ном программировании: наследование и среда выполнения тестов. Создание среды
для поэлементного тестирования классов требует специального рассмотрения благо-
даря эффекту инкапсуляции, скрывающему сложность системы.
Тестирование с использованием ортогональных массивов
У некоторых приложений число входных значений невелико и ограничено, но
перечисление всех возможных перестановок значений порождает множество тестов.
Одна из возможностей снизить количество тестовых примеров— это применение
комбинаторных методов, известных как тестирование ортогональных массивов. Дан-
ный метод подходит для тестирования всех программных продуктов, включая ПО,
созданное с помощью объектно-ориентированных методов.
Тестирование ортогональных массивов основывается на статистических методах,
заимствованных из промышленности. Для применения этого метода необходимо,
чтобы у программы были независимые наборы состояний. Задача состоит в спарива-
нии каждого состояния из одного набора со всеми состояниями из другого набора, по
крайней мере, один раз. Применение комбинаторных методов для снижения количе-
ства тестов заключается в определении уникальных пар состояний, как будет показа-
но на примере.
Приложение для книжного магазина обрабатывает информацию, представленную
на рис. 6.11. Программное обеспечение, созданное с помощью объектно-ориентиро-
ванных методов, состоит из трех классов: книга, закупка и доставка, которые имеют
ограниченное число возможных состояний. В процедурных приложениях три проце-
дуры— заказатъкнигу, купитъ_книгу и доставитъ_книгу— обладают аргументами с ко-
нечным набором значений. Чтобы упростить рассмотрение приложения, будуг ис-
пользоваться термины класс и состояние.
Таблица 6.2. Тестовые примеры для прецедента № 1
ID тестового примере Источник Ч тестового примера Исходное состояний системы Входные данные О ж идаемые результаты Реальные результаты
П1-1 прецедент № 1 Начать тест с главного меню а) выбрать "Мужская одежда" б) выбрать название первой торговой точки в) нажать кнопку печати а) Появляется список экранов с торговыми точками и перечисляется две торговые точки мужской одежды б) Выдается карта с этой торговой точкой, размещенная на экране (в) Выдается печатная копия карты
п1-2 прецедент № 1 расширение 1а Начать тест с главного меню а) нажать кнопку СПРАВКА б) нажать кнопку ВЕРНУТЬСЯ НАЗАД а) Появляется экран со справкой, предоставляющий информацию относительно главного меню б) Возврат к главному меню
п1-3 прецедент № 1 расширение 1б Начать тест с главногоменю [Нет входных данных: Покупатель ищет книжную торговую точку] В главном меню отсутствует категория книжных торговых точек
п1-4 прецедент № 1 Начать тест а) Выбрать пункт а) Появляется экран со списком
— расширение 2а с главного меню "Рестораны" б) нажать кнопку СПРАВКА торговых точек, на котором перечислено 5 ресторанов б) Выдается экран со справкой относительно меню торговых точек
п!-5 прецедент № 1 расширение 26 "Обувь Лорны" - это неверное название торговой точки Выбрать пункт "Женская обувь" Появляется экран со списком торговых точек, на котором перечисляются две торговые точки
женской обуви, где нет магазина
"Обувь Лорны"
Начать тест
с главного меню
202
Глава 6
Таблица 6.3. Отображение входных данных пользователя на тестовые примеры
Вариант^ BxoAHbik? ^анных?^ „1-Г М-2 М Гл дау - -3 П1-4 Л1-5 П2-1 пЗ- 1 пЗ-2 пЗ-З пЗ-4 - . : ~ ’’ ЧИЦ • ‘ ЗЙР * ‘ ’
1 Z Z Z Z Z Z
2
3 Z
4 Z Z Z Z
5
6 ✓
7 Z Z Z
8 \ У
9
10
11 Z
12
13 ✓ Z Z Z
14
15 Z Z Z
Книга Закупка Доставка
,в_наличии_на_складе специальный_заказ распродана наличные срочная чек экономная долговое обязательство по месту задержка
Рис. 6.11. Классы и состояния в примере с книжным магазином
У каждого из двух классов есть три состояния, а у одного класса их четыре, так что
тестирование каждой комбинации потребует З2 х 4', или 36 тестовых примеров. Если
выбрать состояние из двух классов (известное как двухточечная комбинация), то по-
требуется только 12 тестовых примеров, показанных в табл. 6.4, и, следовательно,
число необходимых тестовых примеров будет ниже.
Тестирование объектно-ориентированного ПО
203
Таблица 6.4. Применение ортогональных массивов
Тестовый пример Книга Закупка Доставка
1 в _наличии_на_складе наличные срочная
2 в наличии на складе чек экономная
3 в_наличии_на_складе долговое обязательство по месту
4 в_наличии_на_складе наличные задержка
5 специальный_заказ чек срочная
6 специальный_заказ долговое обязательство экономная
7 специаль ный_заказ наличные по месту
8 специальный_заказ чек задержка
9 распродана долговое обязательство срочная
10 распродана наличные экономная
11 распродана чек по месту
12 распродана долговое обязательство задержка
Рассматривая в таблице только столбцы “Книги” и “Доставка” (игнорируя столбец
“Закупка”), можно увидеть все возможные комбинации этих двух классов. Аналогич-
но, игнорируя класс книга, прослеживаются все возможные комбинации состояний
закупки и доставки. У класса доставка больше состояний, чем у остальных двух клас-
сов, поэтому инспектирование спариваний столбцов “Книга” и “Закупка” указывает на
то, что все возможные комбинации дублируются. Один из случаев дублирования
представлен тестовыми примерами 1 и 4, где классы книга и закупка обладают соот-
ветственно состояниями в__наличии_на_складе и наличные. Эти два теста по-прежнему
остаются уникальными по причине различных состояний доставки.
Для других приложений, где у всех классов одинаковое число состояний, в массиве
нет повторений. Например, для трех классов (каждый из них имеет три состояния)
будет получен массив, задающий девять тестовых примеров, для которых пары значе-
ний в массиве будут появляться не более одного раза.
В тестовом примере 1 в табл. 6.4 говорится о том, что нужно тестировать комби-
нацию, в которой сделаны следующие установки: для книг — в_наличии_на складе, для
закупок — наличные, для доставки — срочная. Способ реализации этого тестового при-
мера зависит от среды разработки. При объектно-ориентированном программирова-
нии задача данного теста заключается в том, чтобы объект класса книга в состоянии
в_паличии_Ш1_складе отправил сообщение, которое проходит объект класса закупка в
состоянии наличные к объекту класса доставка в состоянии срочная. В процедурном
языке этот тест заключается в передаче параме тров в_наличии_на_складе, наличные и
срочная соответственно процедурам заказать_книгу, купить книгу и дос7павить_книгу.
Некоторые комбинации могут казаться немыслимыми. Например, может ли в дей-
ствительности пользователь купить книгу, которая была распродана? Тестер будет
рассматривать это условие как нереальную комбинацию и удалит ее из набора тесто-
вых примеров. С другой стороны, выполнение такого рода тестов гарантирует, что
204
Глава 6
приложение будет отлавливать нереальные условия и возвращать соответствующее
сообщение об ошибке.
При уменьшении числа тестовых примеров всегда существует возможность утра-
тить критичные комбинации. Анализ степени риска (см. главу 8) помогает определить
подходящие тесты. Если в сокращенном наборе тестовых примеров пропущена очень
важная комбинация, то, возможно, будет проще создать дополнительный тестовый
пример, а не модифицировать комбинаторную схему для включения требуемых тес-
товых условий.
Тестирование ортогонального массива — это мощный метод, который использует-
ся всякий раз, когда у системы прослеживается небольшая область входных данных и
большое число перестановок. Дополнительные примеры реализации этого метода
представлены в работах [McGregor 01], [Nguyen 01], и [Pressman 01]. В более строгом
описании [Cohen 97] рассматривается теория поддержки тестирования ортогональ-
ных массивов, представлены подробные примеры и анализ на основе наглядных ил-
люстраций, а также объясняется использование других комбинаций (таких как три-
плеты и п арные комбинации).
Тестирование наследования
При наследовании создаются новые классы, которые повторно используют и рас-
ширяют классы, созданные ранее. При этом допускается расширение функций суще-
ствующего кода без реальной модификации исходного кода. Эта мощная концепция
программирования вызывает некоторые проблемы при тестировании ПО- Произ-
водный класс, или потомок родительского класса, наследует те же возможности, ко-
торые есть и у исходного родительского класса, хотя при этом также добавляются его
собственные возможности. Основная идея заключается в том, что после написания и
отлаживания родительского класса никто не захочет менять код из опасения внести
новые ошибки. Еще одна причина использования наследования — возможное отсутст-
вие доступа к исходному коду (это происходит, когда код распространяется в виде
части библиотеки классов). Разработчик может также сделать наследование классов
частью исходного проектирования. Точное определение момента, когда следует ис-
пользовать наследование, является одним из' аспектов хорошего объектно-
ориентированного проектирования. Неуместное использование наследования, как и
любой другой техники написания кода, может усложнить тестирование и отладку.
Рассмотрим характерный пример. На рис. 6.12 показана структура наследования
для трех классов.
• Класс А.
• Класс Б, потомок класса А.
• Класс В, потомок класса Б и класса А.
Тестирование объектно-ориентированного ПО
205
• обозначает новый метод, который подменяет предыдущий метод
Рис. 6.12. Пример наслединания
Даже если предыдущее тестирование подтвердило, что родительский класс сам по
себе работает корректно, остается вопрос, будут ли работать методы, заданные в ро-
дительском классе, если их вызовет дочерний. В каждом классе могут быть заданы
специфические методы и в зависимости от языка программирования наследование
позволяет дочернему классу переопределять (подменять) некоторые из них. Кроме
того, от метода (общего или частного) зависит его доступность для дочернего класса.
Общие методы видны для всех производных классов, чего нельзя сказать о частных.
Относительно наследования можно предположить, что методы класса А будут рабо-
тать и тогда, когда они будут вызваны объектом класса Б. Таким образом, тестировать
нужно взаимодействия класса А в контексте класса Б. Аналогично нужно тестировать
взаимодействия класса А в контексте класса В и взаимодействия Б в контексте В.
Ошибки, как правило, возникают во взаимодействиях по мере перемещения вверх и
вниз в иерархии уровней классов.
Проектирование с неглубокой структурой наследования проще тестирования.
При выравнивании класса создается диаграмма, которая выделяет все унаследован-
ные функции. В диаграмме, показанной на рис. 6.13, перечислены все методы как в
206
Глава 6
родительском, так и в производном классе, а также задано то, какие методы видны
для каждого класса.
Задача заключается в том, чтобы протестировать каждый метод в контексте всех
классов, которые могут получить к ним доступ. Использование диаграммы на рис. 6.13
помогает определить условия тестов, показанные в табл. 6.5. Обозначение “класс
метод” принято для того, чтобы связать метод с классом, в котором он задается
В первом условии теста сказано, что нужно протестировать метод м1 (заданный в
классе А) в контексте классов А, Б и В.
Таблица 6.5. Условия тестирования методов
Метод пасса
А.м1 класс А, Б, В
А.м2 класс А
А. м3 класс А
Б.м4 класс Б, В
А.м4 класс А
Б.м4 класс Б
В.м4 класс В
Б.м5 класс Б, В
Б.мб класс Б
В.мб класс В
Б.м7 класс Б
В .м8 класс В
Описанная выше стратегия позволяет тестеру установить, какие методы видимы
для производных классов. За дополнительной информацией и примерами по насле-
дованию можно обратиться к [Binder 00], [Marick95] и [McGregor 01]. Следующий
этап заключается в создании среды, в которой эти тесты будут выполняться.
Сложности проведения тестов
Следующий этап задания тестовых примеров — разработка среды, в которой будут
проводиться тесты. Для этого требуется специальное тестовое ПО (драйвер), которое
будет активизировать тестируемое ПО. Типичный драйвер выполняет такие функции:
упаковки входных и других данных;
активизации тестируемого ПО;
регистрации исходных результатов.
Класс*
КлассВ
Классе
метод, заданный в классе
с»жзлм- метода приводит к л,.«т. ,к»иу классу
метод, подмененный проипымм классом
метод, к которому ловко ;»*» класс не может полнить доступ
Рис. 6.13. Выравнивание иерархии классов
208
Глава 6
Создание драйвера для тестирования класса требует дополнительного обсуждения.
В объектно-ориентированном проектировании для сокрытия сложности использует-
ся инкапсуляция, и таким образом ограничивается видимость данных и методов вне
класса. Следовательно, другие классы не смогут активизировать эти данные и методы
без реализации какого-либо специального доступа. Драйвер должен обходить инкап-
суляцию, чтобы иметь возможность контролировать и наблюдать за внутренними
данными и методами класса. Существует несколько способов, которыми можно этого
достичь, а именно:
• для каждого класса предусматривается метод тестового примера;
• создаются параллельные, идентичные исходным классы, которые отличаются
наличием дополнительного кода, необходимого для тестирования;
• создаются дочерние классы, которые наследуют тестируемые методы.
Все эти подходы видоизменяют классы и, следовательно, модифицируют реальное
приложение. Таким образом, тес тируемая реализация может оказаться неидентичной
выпускаемому коду. Важно, чтобы среда тестирования была как можно ближе к среде
разработки, в противном случае нельзя будет полностью протестировать конечный
продукт.
Иногда программист создает специальный интерфейс, скрытый от других пользо-
вателей, которым тестер может воспользоваться для доступа к внутренним функциям.
Такая лазейка иногда остается и в коде конечного продукта. Это весьма опасно, по-
скольку злоумышленники без труда могут нанести вред системе.
Драйверы доя тестирования классов принимают множество форм, поэтому преж-
де чем выбрать схему драйвера, тестер должен проанализировать различные вариан-
ты. Создание эффективного драйвера, пригодного для повторного использования,
требует серьезного планирования и значительных усилий, даже если При тестирова-
нии используются коммерческие инструменты. За дополнительной информацией и
примерами драйверов для тестирования ПО, созданного с привлечением методов
объектно-ориентированной разработки, можно обратиться к работам [Binder 00] и
[McGregor 01].
Резюме
В процессе задания тестовых примеров для ПО, разрабатываемого с помощью
объектно-ориентированных методов, можно с легкостью применить многие из пере-
ходов, описанных в предыдущих главах. Это в особенности справедливо для уровня
тестирования системы, на котором задание тестовых примеров не зависит от того,
как спроектировано ПО. Схематичный подход помогает организовать требования.
Эффективной методикой документирования являются прецеденты, которые легко
преобразуются в тестовые примеры.
Классы представляют собой уникальную компоненту ПО, разрабатываемого с по-
мощью объектно-ориентированных методов, однако при задании тестовых примеров
используются подходы, которые применяются для ПО, реализуемого в соответствии с
принципами процедурного программирования.
Тестирование объектно-ориентированного ПО 209
Наследование как составная часть объектно-ориентированного программирова-
ния задает иерархию классов. При выравнивании классов перечисляются все унасле-
дованные функции и задаются видимые для дочерних классов методы.
Для некоторых областей входных данных получается слишком большой для все-
стороннего тестирования набор перестановок. Тестирование ортогонального масси-
ва — это мощный метод, позволяющий уменьшить число тестовых примеров и гаран-
тирующий наличие тестовых примеров для всех двухточечных комбинаций.
Создание среды проведения тестов, в которой тестируется ПО, разрабатываемое с
помощью объектно-ориентированных методов, требует дополнительного обсужде-
ния. Инкапсуляция ограничивает доступ классов к методам и внутренним состояниям.
Следовательно, драйверы должны иметь возможность доступа, контроля и наблюде-
ния за внутренними данными и методами.
ГЛАВА
Тестирование Web-приложений
Введение
Приложения, основанные на технологиях WWW, несут в себе новые проблемы как
для разработчиков, так и для тестеров. К этим проблемам можно отнести:
• короткие циклы выпусков;
• постоянно изменяющиеся технологии;
• большое число пользователей при начальном запуске Web-узла;
• невозможность контроля пользовательской среды запуска;
• доступность Web-узла в течение 24-х часов.
Качество Web-узла должно с самого начала быть безупречным. Любые трудности,
будь то время ответа, точность информации или практичность будут вынуждать поль-
зователя перейти на узел конкурента. Такие проблемы приводят к потере пользовате-
лей, снижению уровня продаж и ухудшают имидж компании. Различие приоритетов
тестирования основывается на типе тестируемого Web-узла. Для информационных
узлов основным качеством является доступность, в то время как для интерактивных
узлов важна скорость и надежность взаимодействия.
Использование методов проектирования тестов, представленных в предыдущих
главах, помогает задать тесты на основе функциональных возможностей, но это все
же только поднабор того, что требуется для тестирования Web-приложений. Перво-
источником многих стратегий, которые используются для тестирования систем, ос-
нованных на технологиях WWW, являются приложения, базирующиеся на техноло-
гии клиент-сервер (например, частные локальные сети компаний). Эта глава охваты-
вает подходы, необходимые для тестирования приложений, основанных на технологи-
ях WWW (аналогично приложениям, для которых важны практичность, безопасность,
212
Глава 7
базы данных и другие задачи тестирования). Здесь также представлены тестовые
примеры для образца приложения. Для более подробного ознакомления с Web-
приложениями можно обратиться к работам [Nguyen 01] и [Splaine 01].
Образец приложения
Наиболее распространенное Web-приложение — электронный магазин. Характер-
ными страницами, которые создает компания, можно назвать презентации продук-
тов, данные о компании (история, расположение, контактная информация и т.д.) и
политика компании (форма оплаты и пр.). В приложении могут также задействовать-
ся основные принципы и достижения компании, поощрительные призы или банне-
ры, которые обычно помогают привлекать инвестиционные средства для бизнеса.
Эти общие методы предназначены для поддержки пользователей, которые случайно
натолкнулись на Web-узел или держат его среди закладок. Такая несоразмерность
пользователей (не только в плане опыта, но и в плане цели посещения Web-узла) вы-
двигает серьезные требования к проектированию тестовых примеров.
Данное приложение представляет пример электронного книжного магазина.
Для каждой книги демонстрируется заголовок, имя автора, жанр, цена и аннотация.
На экране также может отображаться сама книга. Покупатель просматривает книги
аналогично тому, как он это делает в библиотеке исходя из названия, автора, жанра,
цены или ключевых слов, найденных в описании.
Покупатель выбирает различные товары, размещая их в тележке для покупок. Ко-
гда покупатель готов к покупке товаров, он может отобразить на экране выбранные
товары, прежде чем действительно сделать покупку — таким образом покупатель при-
обретает реальные книги.
Ассортимент и ориентация магазина меняются в зависимости от сезона и продаж,
поэтому внтрина магазина (т.е. страница, на которой представлены книги) должна
быстро и легко изменяться, не оказывая влияния на безопасность или целостность уз-
ла. Чтобы достичь этого, GUI в большинстве случаев хранится отдельно от коммерче-
ской компоненты приложения.
Среда, в которой запускается Web-приложение, содержит множество компонент.
Реальную конфигурацию определяет администратор сети. Для задания некоторых
тестов тестеру может понадобиться проанализировать отдельные настройки сети.
На рис. 7.1 показана простая конфигурация, состоящая из следующих компонент.
1. Пользователь просматривает Web-узел с помощью браузера, подключенного к
сети Internet.
2- Программное обеспечение Web-узла может выполняться на браузере пользова-
теля, сервере сети, подсоединенном в каком-то другом месте сети Internet, или
на сервере приложений — в зависимости от того, как разработчики спроекти-
ровали систему.
3. Брандмауэр, который представляет собой комбинацию аппаратного и про-
граммного обеспечения, существует для того, чтобы ограждать сети от зло-
умышленников. Пользователь также может установить брандмауэр, чтобы за-
щитить компьютер от внешних атак.
Тестирование Web-приложений
213
4. Прокси-сервер — это программное обеспечение, цель которого заключается в
том, что он является единственным соединением частной сети и Internet.
Прокси-сервер выполняет множество функций (например, предотвращает
проникновение некоторых файлов или покидание ими сети, улучшает характе-
ристики системы путем кэширования и т.д.).
5. Многие Web-приложения используют базы данных для хранения информации,
необходимой для запуска Web-узла.
Рис. 7.1. Пример Web-среды
Например, конфигурация клиент-сервер состоит из одного или нескольких ком-
пьютеров пользователя, подсоединенных к серверу посредством локальной (Local
Area Network — LAN) или глобальной (Wide Area Network — WAN) сети.
Размещение магазина в Web приводит к тому, что у узла возникают те же пробле-
мы, что и у обычного магазина, за исключением того, что он посещается с компьюте-
ра клиента. К этим проблемам относятся:
• обработка потока покупателей;
• количество заказчиков;
• оплата за продукт;
214
Глава 7
• выпуск продукта;
• безопасность информации о покупателях;
• обслуживание покупателя во время визита;
• сохранность базы клиентов.
Покупатель ожидает от узла простой и интуитивно понятной навигации, неболь-
шого времени ответа, круглосуточной доступности узла, надежности, отсутствия ава-
рийных ситуаций или сильного запаздывания, а также индикации выполнения при
использовании узла. Несоответствие Web-узла перечисленным выше критериям ведет
к быстрому разочарованию пользователя, таким образом узел может потерять своих
клиентов, что, естественно, вызовет убытки.
Сложности с функциональными
возможностями и практичностью
Первые тесты для Web-узла должны быть ориентированы на предполагаемое по-
ведение узла. Необходимо оценивать следующие проблемные моменты:
• функциональные возможности;
• практичность;
• навигацию;
• форму;
• содержимое страницы.
Проведение этих тестов в изолированной и контролируемой среде тестирования
помогает, прежде чем оценивать узел посредством Internet, убедиться в том, что ос-
новные функции Web-узла работают корректно. После проведения тестов в контро-
лируемой среде любые новые проблемы, вероятнее всего, будут вызваны взаимодей-
ствием с живой средой.
Тестирование функциональных возможностей
Тестирование функциональных возможностей заключается в подтверждении то-
го, что функции, которые больше всего влияют на взаимодействие с пользователем,
работают соответствующим образом. Сюда относятся:
• формы;
• поиск;
• временные рабочие окна;
• тележки для покупок;
• оплата в интерактивном режиме.
Тестирование Web-приложений
215
При задании тестовых примеров для тестирования функциональных возможно-
стей используются различные методы (включая таблицы и схемы, описанные в пре-
дыдущих главах). Вернемся к примеру с книжным магазином. В табл. 7.1 представлено
несколько образцов тестовых примеров. В данном случае отсутствует преимущество
схемы — указание на происхождение. Поскольку тележка для покупок — это сущест-
венная часть взаимодействия с покупателем, тесты комбинируют доступ к тележке для
покупок, продолжая взаимодействовать с Web-узлом.
Таблица 7.1. Образец тестовых примеров для функциональных возможностей
ID тестово- го при- мера Описание входных данных* - Входные данные Ожидаемые результаты Реаль- ные 1 резуль- таты
W-1 1. 2. 3. Пойти на страницу с перечнем каких-либо книг Выбрать и добавить книгу (книги) в тележку для покупок Просмотреть содержимое тележки для покупок Web- страница = добавленные книги = В тележке для по- купок перечисля- ются выбранные книги
W-2 1. 2. Добавить книгу (книги) в тележку для покупок, пройдя по различным страницам или при помощи поиска Просмотреть содержимое те- лежки для покупок добавленные книги = Web-страница (страницы) = критерий поиска = В тележке для по- купок перечисля- ются все выбран- ные книги даже после проведения поиска или изме- нения страницы (страниц)
W-3 1. 2. Выбрать, но не добавлять книги в тележку для покупок Просмотреть содержимое те- лежки для покупок выбранные книги = В тележке для по- купок не перечис- ляются выбранные ранее книги
W-4 1. 2. 3. Выбрать несколько книг и до- бавить их в тележку для покупок Не просматривать содержи- мое тележки для покупок Перейти к контролю Добавленные книги = Книги, размещен- ные в тележке для покупок, перечис- ляются на контроле
W-5 1. 2. Выбрать несколько книг и доба- вить их в тележку для покупок Удалить книгу из тележки для покупок добавленные книги = < удаленная книга = Содержимое те- лежки для покупок обновляется, чтобы отобразить книгу, которая была удалена
216
Глава 7
Формат таблицы тестовых примеров несколько отличается от тех форматов, что
использовались в предыдущих главах, хотя в них задается один и тот же тип инфор-
мации. Входные данные задаются в двух столбцах. Столбец “Описание входных дан-
ных” содержит общее описание теста, в то время как реальные данные, записываемые
тестером, получаются для входных данных из столбца “Входные данные”. Таким об-
разом, тестер использует одни и те же тестовые примеры с различными входными
данными, а также задает тесты, прежде чем узнает о реальной информации, разме-
щаемой на Web-узле.
Тестирование функциональных возможностей позволяет также оценить содержи-
мое динамически генерируемых страниц. Эти страницы задаются по мере того как их
запрашивает пользователь, часто выдавая информацию, которая является результа-
том поиска в базе данных. В разделе “Тестирование содержимого страницы” динами-
ческий код описан более детально, а в разделе “Тестирование баз данных” анализи-
руются проблемы, связанные с тестированием баз данных.
Еще один аспект тестирования функциональных возможностей заключается в
проверке множества закулисных функций, которые неохотно показываются пользо-
вателю: соединение с существующими системами, с базами данных, соединение со
сторонними приложениями (e-commerce, лицензионными серверами, блоками шиф-
рования и Т.Д.).
Тестирование практичности
Многие пользователи сразу отвергают продукт, который сложен в использовании
или не работает, поэтому первое впечатление пользователя от узла очень важно, не-
смотря на это многие Web-узлы становятся все более запутанными по мере увеличе-
ния числа функций. Если Web-узел относится к категории общего пользования, разо-
чарованный пользователь может легко переключиться на узел конкурента. Если же
это узел подписки, нетерпеливому пользователю придется ожидать обновлений, ко-
торые решат проблемы существующего узла. Неудачное же решение таких проблем
приведет в результате к потере подписчиков. Чтобы разобраться с этими недостатка-
ми, необходимо провести тестирование практичности, которое даст возможность
оценить исправность, а также удобство обращения путем сбора информации о взаи-
модействии пользователей с узлом. Основная идея — создать для команды, занимаю-
щейся продуктом, обратную связь с пользователем по “впечатлениям и ощущениям”,
структуре, навигации и функциям, поскольку у различных групп пользователей раз-
личные подходы к усвоению и управлению информацией.
Ключом к тестированию практичности является изучение реальных действий
пользователя. Наблюдатель фиксирует действия пользователя и его реакцию, чтобы
определить, с каким типом трудностей сталкивается пользователь и как он их преодо-
левает. Основные этапы тестирования практичности следующие:
• определение задач Web-узла;
• определение группы пользователей, для которых предназначен Webyaea;
• задание тестов и проведение тестирования практичности;
• анализ полученной информации.
Тестирование Web-приложений
217
Успешное тестирование практичности показывает не только позитивные сторо-
ны, но выявляет и слабые места проекта. Эти слабые места могут быть так же нераз-
личимы, как и время, которое тратит пользователь на выполнение желаемого дейст-
вия, или так же основательны, как и состояние пользователя, полностью потерявше-
гося в парадигме, используемой для создания страницы. Возможность разобраться с
этими слабыми местами на ранней стадии процесса разработки позволяет создать бо-
лее эффективный продукт, исключая, таким образом, переделки или хотя бы снижая
их число.
Определение задач Web-узла
Дизайнеры должны понимать, почему люди посещают определенный Web-узел и
какой тип задач пользователи решают с помощью этого узла. В зависимости от при-
ложения пользователь может:
• получать информацию о продукте;
• покупать продукт;
• получать информацию о путешествиях (например, сведения о рейсах) и бро-
нировать билеты;
• получать специфическую информацию (например, относительно банковского
счета);
• играть в игры;
• слушать музыку.
С помощью этой информации дизайнерам легче сохранить простоту и ориента-
цию Web-узла. Понимание задач Web-узла помогает установить основные запросы
пользователей и разработать типичные сценарии для проведения тщательной про-
верки узла.
Определение пользователей, для которых предназначен Web-узел
Что такое обычный пользователь? Чтобы ответить на этот вопрос, нужно устано-
вить профиль типичного пользователя, задавая такие категории, как пол, возраст,
уровень образования, опыт, навыки и демографические данные. Какой тип клиентов
привлекает узел? (Возьмем, к примеру, узел путешествий: предназначен ли он для де-
ловых людей, туристов или же для агентов бюро путешествий?) Помимо этого, уста-
новление ключевых слов на домашней страничке узла помогает находить этот узел
большему числу пользователей. Ключевые слова определяют пользователей, для ко-
торых предназначен узел.
Профиль пользователя важен при разработке проекта теста и при выборе образца
объекта. Следующий этап заключается в приглашении участников, выступающих в
роли пользователей, для которых предназначен узел (часто роль участников теста иг-
рают служащие компании, а работа выполняется согласно списку задач).
218
Глава 7
Задание тестов и проведение тестирования практичности
Данный этап состоит в подготовке и реализации тестирования практичности. Тес-
товые примеры по практичности являются четко заданным и несложным набором за-
дач, которому должны следовать участники. При задании тестовых примеров нужно
принимать во внимание знания участников. В примере с книжным магазином инст-
рукция должна включать поиск книги на заданную тему с последующей подачей заказа.
Выполнение тестовых примеров по практичности состоит в наблюдении за реак-
циями и эмоциями участников во время выполнения заданных задач. Со стороны на-
блюдателя не должно поступать никакой информации и не должна предоставляться
начальная помощь. Участники, в свою очередь, отмечают, что им понравилось или не
понравилось в узле, а также что их разочаровало в ходе использования узла. Наблюда-
тель фиксирует следующую информацию:
• успешно ли пользователь выполнил задачу;
• сколько времени понадобилось пользователю на выполнение задачи;
• число страниц, к которым нужен был доступ для завершения каждой задачи;
• в каких местах пользователь сталкивался с трудностями или где он делал ошибки;
• как пользователь искал помощи в случае неудач;
• предоставляет ли интерактивная справка достаточное количество информации;
• что пользователи говорили вслух и в каких местах задачи они это делали;
• невербальные сигналы (жесты и выражение лица);
• щелкал ли пользователь по страницам или использовал возможность поиска;
• как пользователь реагировал на время загрузки отдельных страниц;
• место, в котором пользователи запутывались или даже были не в состоянии
выполнить задачу;
• количество щелчков между задачами, время между щелчками, а также число
просмотренных страниц и то, какие именно страницы просматривались.
При тестировании практичности можно применять и другие методы сбора дан-
ных, такие как видеозапись и регистрация нажатия клавиш. Тесты практичности
можно встретить на узлах разработки или в специализированных лабораториях, ко-
торые занимаются практичностью. Такая лаборатория обеспечивает контролируемую
среду с полным набором возможностей по наблюдению, фиксированию и составле-
нию отчетов. Нужно признать, что такой подход дорогостоящ как в плане оборудова-
ния, так и в плане персонала, однако он позволяет получить более исчерпывающую
информацию о пользователях.
Другая задача тестирования практичности заключается в составлении анкет для
изучения мнений участников об узле или его прототипе. Это дает возможность полу-
чить качественную и количественную информацию. На один вопрос пользователи от-
вечают по рейтинговой шкале, другие вопросы окончательно открыты. В анкете ана-
лизируются следующие вопросы:
Тестирование Web-приложений
219
• удобно ли чувствовал себя пользователь при использовании узла;
• ответная реакция пользователя на навигацию и другие функции узла;
• порекомендовал ли бы пользователь этот продукт друзьям;
• понял ли пользователь терминологию;
• идеи относительно усовершенствований;
• что понравилось и что не понравилось пользователю в Web-узле и почему.
Какой бы ни был выбран подход для тестирования практичности, все результаты
должны быть документированы. Документация — это ключ к успешному завершению
данного этапа.
Анализ полученной информации
Отчет о тестах практичности содержит резюме полученных результатов, перечень
проблем, связанных со сложностью использования узла, указание на какие-либо тен-
денции, анализ видеопленок, некоторые высказывания участников относительно ра-
боты узла и статистический анализ анкеты. Заключения и рекомендации обычно
сконцентрированы на простоте использования и предложениях, касающихся специ-
фического переконструирования компонент приложения. Задача тут заключается в
совершенствовании Web-узла на основе оценки практичности.
За дополнительной информацией относительно тестирования практичности
можно обратиться ко многим публикациям, например, к [Dumas 99] и [Rubin 94].
Тестирование навигации
Хорошая навигация — важная часть Web-узла, в особенности это касается сложных
узлов, которые предоставляют большое количество информации. Оценка навигации
является наиболее значимой частью тестирования практичности. Большинство поль-
зователей ожидают:
• простого и быстрого доступа к информации, которую они хотят получить;
• логичной иерархии страниц
• подтверждения того, где они находятся в любой точке;
• возможность вернуться в предыдущее состояние или на домашнюю страницу;
• непротиворечивый вид и размещение каждой страницы;
• отсутствие неразберихи среди страниц.
Охарактеризуем основные проблемы при тестировании навигации;
• переход на страницу и с нее;
• прокрутка страниц;
• щелканье на развернутых и свернутых изображениях, чтобы убедиться, что они
работают;
220 Глава
• тестирование всех ссылок (как внутри, так и снаружи Web-узла), чтобы под-
твердить их обоснованность и корректность;
• подтверждение того, что нет разорванных ссылок;
• просмотр таблиц и форм, чтобы убедиться в правильности их расположения
(для разных броузеров размещение таблиц и форм может быть различным);
• подтверждение того, что окна с большим количеством блоков обрабатываются
так, как если бы каждый из них содержал только один блок;
• измерение времени загрузки каждой страницы;
• подтверждение совместимости и согласованного использования клавиш, быст-
рых сочетаний клавиш и действий мыши.
В табл. 7.2 показаны образцы тестовых примеров по навигации, которые относят-
ся к примеру с книжным магазином.
Таблица 7.2. Образцы тестовых примеров по навигации
ID тестового примера Описание входных данных, , Входные данные Ожидаемые результаты Реаль- . ные ре- зультаты
W-6 1. Найти запрос, который сгенерирует, по меньшей мере, 3 страницы с выходными данными 2. Прокрутить вниз на одну страницу запрос= 1. Найти результаты на 3 или больше страницах с выходными данными 2. Описание самой верхней книги прокручивается от верхней части экрана, в нижней части экрана появляется содержимое следующей страницы, за исключением момента, когда достигнут конец списка
W-7 1. Найти запрос, который сгенерирует, по меньшей мере, 3 страницы с выходны- ми данными 2. Прокрутить вниз на од- ну страницу далее запрос= 1. Найти результаты на 3 или больше страницах с выходными данными 2. Текущее содержимое экрана прокручивается и появляется следующая страница, за исключени- ем случая, когда достиг- нут верх или низ списка
Тестирование Web-приложений
221
Тестирование ссылок
В ходе тестирования навигации тестер должен убедиться в том, что все ссылки ра-
ботают так, как предполагалось, а именно:
• проследовать по любой из ссылок, представленных на Web-узле, включая тек-
стовые и графические гиперссылки, или сценарии JavaScript с поддержкой
средств управления (код, написанный на JavaScript, который загружается брау-
зером пользователя для выполнения);
• подтверждение того, что извлекаемые страницы — именно те, которые предпо-
лагалось увидеть;
• подтверждение того, что все ошибки дружелюбны к пользователю (например,
подтверждение того, что нет ошибок типа “404 — не найдено”).
Тестирование ссылок вручную отнимает много времени и оставляет лазейки для
субъективных ошибок, если ссылка отсутствует. Рекомендуется выполнять эту задачу
при помощи автоматизированных инструментов проверки ссылок (так называемых
“пауков”), прослеживающих ссылки в Web-узле. Обычно в распоряжении тестера име-
ется несколько таких “пауков”, которые проверяют ссылки на постраничной основе
или динамические ссылки, т.е. следуют по ссылкам на указываемые ими страницы.
Возможности тестирования ссылок меняются от инструмента к инструменту. Узловые
“пауки” могут значительно снизить время тестирования, однако недостатком автома-
тизации тестирования является то, что содержимое, возвращаемое по ссылке, не
проверяется на истинность в обязательном порядке.
Другая распространенная функция Web-узла — текст “над курсором мыши”. Он по-
является на экране, когда курсор находится возле объекта. Вследствие того, что со-
держимое может часто меняться, самым простым вариантом для тестеров будет под-
готовка таблицы контрольных проверок свойств текста “над курсором мыши”, чтобы
она была под рукой в ходе выполнения тестов по функциональным возможностям или
содержимому страницы. Затем тестеры тестируют эти функции по мере того как они
встречаются и соответственно записывают результаты. Тестирование функций помо-
гает также убедиться в том, что разработчики не пропустили заголовка “над курсором
мыши".
Тестирование форм
Web-узлы, использующие формы, нуждаются в тестах, ко торые позволяют прове-
рить работу каждого поля и помогают проконтролировать формы, отсылающие все
данные так, как это было запланировано дизайнерами. Тестирование форм состоит
из следующих действий:
• использование клавиши табулятора для проверки того, что форма проходит по
полям в положенном порядке как вперед, так и назад;
• тестирование граничных значений;
• проверка корректного отлавливания формами неверных данных, в особенно-
сти форматов даты и числовых форматов;
• проверка правильного обновления формами информации.
222
Глава 7
В примере с книжным магазином пользователь вводит данные в форму, чтобы оп-
латить покупку. На рис. 7.2 показана Web-страница, а в табл. 7.3 представлено не-
сколько образцов тестовых примеров. Использование схемы или таблицы, как уже го-
ворилось в предыдущих разделах, приводит к созданию более полного набора тесто-
вых примеров. Разбиение на классы эквивалентности и анализ граничных значений —
это методы, помогающие задать тесты для проверки работы большинства полей.
За примерами по применению этих методов следует обратиться к главе 4.
Рис. 7.2. Образец формы для книжного магазина
Тестирование Web-приложений
223
Таблица 7.3. Образцы тестовых примеров для тестирования форм
W-8 Переход табулятора от поля начальное поле = Переход из поля в поле
к полю осуществляется в нужном порядке
W-9 Ввести максимальное число символов, которое можно ввести в поле название поля = набранные символы = Введенные в поле данные принимаются
W-10 Превысить максимальное число символов, которое можно ввести в поле название поля = набранные символы = Введенные в поле энные отклоняются
W-11 Пропустить информацию в необязательном поле название поля = Приложение принимает форму(при условии, что пользователь корректно заполнил остальную часть формы)
W-12 Пропустить информацию в обязательном поле название поля = Форма требует, чтобы пользователь представил информа- цию в обязательном поле
Тестирование содержимого страницы
Для каждой Web-страницы нужно провести тесты, подтверждающие корректность
ее содержимого с точки зрения пользователя. Эти тесты делятся на две категории:
подтверждение адекватного функционирования каждой компоненты и подтвержде-
ние того, что содержимое каждой из них корректное. Задача первой категории тес-
тов — проверить, что:
• все изображения и графики правильно отображаются в различных браузерах;
• все содержимое представлено согласно требованиям;
• структура страниц остается постоянной в различных браузерах;
• критические страницы сохраняют содержимое от версии к версии;
• представлены все части таблицы или формы, а их расположение правильное;
• ссылки на важное содержимое внутри и снаружи узла точные;
• объекты с текстом всплывающей подсказки корректны;
• Web-страницы внешне выглядят привлекательно.
224
Глава 7
Чтобы убедиться в корректности содержимого, необходимо проверить содержи-
мое на точность, оценить правильность орфографии, грамматики и терминологии.
Динамические страницы создаются автоматически по мере того как их запрашива-
ет пользователь; полностью такие страницы не размещаются ни на одном сервере.
Например, осуществляя поиск отдельного предмета, базы данных могут обновляться,
перечисляя, таким образом, совершенно разные результаты каждый раз, когда будет
проводиться один и тот же поиск. Для Web-страниц нужны подходящие сообщения,
отображаемые при отсутствии данных или при условии, что количество представлен-
ных данных больше, чем заданный размер страницы.
Обычно динамически генерируемые HTML-страницы используются для представ-
ления результатов поиска. Что касается примера с книжным магазином, покупатель
может искать книги, относящиеся к какой-либо категории (например, тестирование
программного обеспечения), ссылаясь на имя автора или на заголовок. В разде-
ле “Тестирование баз данных” представлен образец тестов для просмотра различных
результатов поиска.
Поскольку большинство Web-узлов предполагают непрерывное изменение их со-
держимого, тестеры должны убедиться, что эти изменения не оказывают вредного
влияния на узел в целом. Регрессионное тестирование заключается в запуске сущест-
вующих тестов, чтобы убедиться, что узел по-прежнему работает, как и предполага-
лось. Задача таких тестов состоит в следующем:
• определить, загружает ли новая страница то же, что и предыдущая;
• проверить идентичность новой страницы с предыдущей версией;
• проверить, остается ли важная информация той же или же она отличается;
• проверить корректность ссылок.
В табл. 7.4 показано несколько образцов тестовых примеров для книжного магази-
на. Эти конкретные тесты изложены в свободной форме и выполняют функции ско-
рее общей таблицы контрольных проверок для тестирования содержимого страницы.
Тестер может задавать тесты, которые включают определенные изображения, табли-
цы или другие объекты тестирования.
Тестирование конфигурации
и совместимости
Основная задача тестирования Web-приложений состоит в подтверждении того,
что пользователь видит Web-страницу такой, какой она была задумана дизайнером.
Пользователь может выбирать в качестве браузера разное программное обеспечение
и различные его настройки, использовать разное сетевое программное обеспечение и
интерактивные услуги, а также запускать одновременно другие приложения. Web-
приложение может содержать серверы, базы данных и различные устройства для ус-
тановления соединения.
Тестирование Web-приложений
225
Таблица 7.4. Образцы тестовых примеров для тестирования содержимого страницы
Ютесто- вого примера Описание ;”'ЪЛ ’'данных : Входные данньг Ожидаемыёрезультаты ;;Р^альные ~ резуль- таты '
W-13 Просмотреть изображения и графики просматриваемая страница = браузеры = Изображения и графики корректно отображаются в выбранном браузере
W-14 Просмотреть таблицу просматриваемая таблица = браузеры = Таблица корректно отображается в выбранном браузере
W-15 Поместить курсор возле каждого объекта тестируемые объекты = Над каждым объектом появляется соответствующий текст
W-16 Выполнить поиск по категории (например, "тестирование программного обеспечения") категория поиска = В результатах поиска перечисляются все книги в этой категории
Как для пользователя, так и для Web-прпложепия установки аппаратного обеспе-
чения и конфигурация также влияют на среду. Сюда входят типы ЦП, ОЗУ, графиче-
ские адаптеры, платы захвата видеоизображения, мониторы, сетевые карты и типы
соединений (например, Tl, DSL, модемное). Все они могут влиять на появление Web-
страницы. В то время как обычно окружение Web-приложения остается неизменным,
можно ожидать, что пользовательское окружение будет разноплановым с нескольки-
ми вариациями в зависимости от конкретного пользователя. Таким образом, задача
тестирования конфигурации и совместимости состоит в том, чтобы убедиться, что
приложение функционирует корректно в Internet.
При написании тестовых примеров для тестирования конфигурации на впечатле-
ние пользователя могут влиять проблемы с различным окружением и конфигураци-
онными установками. В хороших требованиях даются ответы на перечисленные ниже
вопросы (тестеры могут использовать эту информацию для разработки подходящих
тестовых примеров).
1. Находится ли пользователь за брандмауэром или прокси-сервером?
2. Подсоединяется ли пользователь посредством сервера распределения нагрузки
(т.е. машины, которая остается одинаково загруженной на всех доступных Web-
серверах, см. раздел “Надежность и доступность”)?
226
Глава 7
3. Принимает ли браузер маркеры cookie? (Маркер cookie — это пакет данных, от-
правленный Web-сервером, а затем сохраненный на жестком диске пользорате-
ля. Он хранит информацию о пользователе и его предпочтениях.)
4. Есть ли возможности построить надежную защиту?
5. Какие технологии используют разработчики Web-страницы? Например, если
для Web-страницы используются управляющие элементы ActiveX или создание
сценариев Java, тестер должен знать, какие версии браузера поддерживают эти
реализации.
6. Используются ли обеспечивающие защиту инструментальные средства сервера
(блокировочные механизмы)?
Тестирование совместимости помогает убедиться в функциональных возможно-
стях и надежности продукта в поддерживаемых браузерах и платформах пользова-
тельского компьютера Рост числа браузеров и их версий (каждая из которых запуска-
ется в различных операционных системах и на различных платформах, а также имеет
отличные от других графические возможности и plug-in) привел к возникновению
сотен различных пользовательских окружений. Пользовательский браузер подсоеди-
няется к серверу и другим коммуникационным средствам, которые для выполнения
Web-приложения должны корректно взаимодействовать.
Поскольку в цикле тестирования может не оказаться времени на тестирование
всех разновидностей среды, установить приоритетные тесты могут помочь следую-
щие руководящие принципы.
1. Необходимо спросить у разработчиков об отдельных уязвимых конфигурациях
или несовместимых сценариях и нацелиться на эти сложные области.
2. Сконцентрироваться на наиболее распространенных на рынке версиях браузе-
ров. В идеале тестер должен знать о распространенности данного браузера
3. Тестер должен сосредоточить свое внимание на тех платформах, которые ве-
роятнее всего используются клиентами.
4. Необходимо сконцентрироваться на основных версиях программных продук-
тов, включая функции и ключевые изменения.
Табл. 7.5 может служить руководством по тестированию Web-приложений. Здесь
перечислены платформы и окружения браузеров, на которых проводится тестирова-
ние. Цель заключается в выполнении одних и тех же тестовых примеров на различ-
ных комбинациях платформ и браузеров, с отметкой подходящих ячеек после выпол-
нения тестовых примеров.
Тестирование Web-приложений 227
Таблица 7.5. Таблица совместимости браузеров
7 , Common
4.5
Windows 95
Windows 98
Windows NT
Windows 2000
Windows ME
Mac OS X
,Mac
Macintosh 8.1
Linux
не применим не применим
В идеале, конечно, нужно выполнять каждый тестовый набор для каждой комби-
нации браузер/платформа. В действительности такие ресурсы, как время и люди, ог-
раничивают число тестов, которые можно выполнить. Разделение тестирования ком-
бинаций браузер/платформа среди команды по тестированию может помочь уско-
рить выполнение тестов. Каждый член команды отвечает за тестирование специфи-
ческого набора тестовых примеров в определенном окружении браузер/платформа.
Чтобы определить, какие тесты нужно выполнять обязательно для всех комбинаций
браузер/платформа, а какие— только в особой среде, можно использовать анализ
степени риска, который гарантирует полное покрытие приоритетных платформ.
Кроме тестирования минимальных функциональных возможностей Web-узла в ка-
ждой комбинации браузер/платформа, тестовые примеры из табл. 7.6 могут исполь-
зоваться во время выполнения тестирования на совместимость. Тестеры должны по-
вторять эти тесты для каждой комбинации браузер/ платформа.
Надежность и доступность
Ключевое требование к Web-узлу состоит в том, что он должен быть доступен
пользователю в любой момент времени на протяжении 24-х часов в сутки. Число
пользователей, одновременно получающих доступ к Web-узлу, также может влиять на
его доступность. Чтобы оценить доступность, тестеры должны создать тесты вокруг
ожидаемых пиков использования узла, к числу которых можно отнести следующие:
для приложений-магазинов: стимулирующие кампании и продажи;
для деловых циклов: даты окончания месяца и квартала;
для банковских приложений: даты прямого зачисления на депозит;
228
Глава 7
• в течение обслуживания: обязательные потери времени на резервирование,
обновление и другие операции.
Таблица 7.6. Образцы тестовых примеров по совместимости
примера Описание входных Входные ;• . •: '.Версий данные браузера иплат- форма ‘' Реалы- ные резуль-- тэты
W-17 Добавить Web-узел к списку избранного и попытаться повторно установить сеанс связи, который уже был завершен Web- страница = Web-узел должен появиться и функцио- нировать должным образом
W-18 Создать сокращенную Web-страницу и попытаться полу- чить доступ к сокра- щенному варианту после завершения сеанса связи Web- страница = Web-узел должен появиться и функцио- нировать должным образом
W-19 Использовать кнопку НАЗАД после под- тверждения инфор- мации о кредитной карточке или регист- рации события Web- страница, отображае- мая перед ИСПОЛЬЗОВЭ; нием кноп- ки НАЗАД = Информация о кре- дитной карточке не должна появляться, а пользователю должна быть представлена страница, задаваемая по умолчанию или главная страница
W-20 Установить несколько сеансов связи с Web- узлом Доступная Web- страница = Можно пользоваться всеми сеансами связи
W-21 Провести с набором маркеров cookie и без него Web- страница = Функциональные возможности Web- узла реализованы так, как было заложено в проекте
W-22 Использовать возможность печати в браузере Web- страница = Распечатанные результаты являются образцом страницы, на которой была запрошена печать
Тестирование Web-приложений 229
Тестеры должны также выполнить проверку на предмет проблем с ресурсами
(таких как утечка памяти и ограничения баз данных), которые могут ухудшить харак-
теристики или даже остановить работу приложения, что приведет в результате к бу-
дущим потерям в бизнесе. Утечка памяти происходит тогда, когда память, которая
больше не используется, не возвращается в пул свободной памяти. Утечка памяти мо-
жет происходить медленно и ее сложно установить. В конечном счете, невозмож-
ность обнаружения утечки памяти приводит к остановке компьютерной системы. Ог-
раничения баз данных включают в себя хранение баз данных, запускаемых рацио-
нально (гарантирующих, что входные данные согласуются с заданной переменной),
тех, для которых выполняется регулярное резервное копирование и тех, которые га-
рантируют, что запись не использует все оставшееся дисковое пространство.
Важно, чтобы тестеры понимали архитектуру системы для того, чтобы про-
вести адекватное тестирование доступности и надежности. Например, если в сис-
теме содержится два Web-сервера для выравнивания нагрузки, то тестеры должны
быть в состоянии описать характеристики системы с одним Web-сервером. При вы-
равнивании нагрузки поддерживается одинаковая загруженность всех доступных
Web-серверов. Если по каким-либо причинам один из Web-серверов будет удален из
продукта (например, для обслуживания), то Web-сайт должен продолжать функцио-
нировать на более низком, но все же приемлемом уровне.
Много вопросов возникает относительно систем с круглосуточным доступом. Ко-
гда в такой системе выполнять тестирование под нагрузкой? Нужно ли для системы с
круглосуточным доступом создавать дубликат, чтобы провести тестирование системы
в загруженном режиме? Ниже перечислены ключевые области для исследования:
• тестирование продукта при использовании не в часы пик;
• необходимость в аналогичном или дублирующем тесте/промышленных аппа-
ратных средствах;
• масштабирование характеристик;
• аутентификация пользователя.
В табл. 7.7 представлено несколько образцов тестовых примеров для тестирования
надежности и доступности в примере с витриной магазина.
Характеристики
Тестирование характеристик (т.е. оценка характеристик системы при нормальном
и интенсивном использовании) критично для успеха любого Web-приложения. Сис-
тема, у которой на ответ уходит слишком много времени, может разочаровать пользо-
вателя — в результате он переходит на узел конкурента. В конечном счете каждая за-
прашиваемая страница будет выдана, однако это может не удовлетворять нужды поль-
зователя. Тогда возникает вопрос: что значит “слишком медленно”? При тестирова-
нии характеристик необходимо убедиться, что сервер Web-узла отвечает на запросы
браузера в рамках определенных параметров.
230
Глава 7
Таблица 7.7. Образцы тестовых примеров для надежности и доступности
ID тесто- вого примера Описание входных данных ' Входные данные Ожидаемые результаты Реаль- ные резуль- таты
W-23 Четыре пользова- теля вошли в сис- тему и одновре- менно купили одну и ту же книгу пользователь 1= Все четыре пользователя могут одновременно добавить в свои пользователь 2= г корзины для покупок одну и ту пользователь 3= же книгу пользователь 4= книга =
W-24 Повторить тест W-23 во время модернизации баз данных Модернизация баз данных про- шла успешно и пользователи могут покупать книги; в системе не отмечено какого-либо ухуд- шения характеристик
W-25 Во время распе- чатки отчета в кон- це месяца вос- пользоваться Web-узлом для покупки книги книга = Отчет предоставляется в конце месяца; книги успешно покупа- ются; в системе не отмечено ка- кого-либо ухудшения характе- ристик
W-26 Создать и выпол- нить сценарий автоматического теста, чтобы мож- но было покупать книги каждые 3 минуты книга 1= Все книги успешно покупаются; книга 2= в системе не отмечено какого- книга 3= либо ухудшения характеристик книга п=
W-27 Провести тест на объем, в котором каждые 20 минут инициируется 10 новых пользовате- лей. Запустить этот тест на один час Все пользователи могут полу- чить доступ к системе и работать с различными функциями Web- узла; в системе не отмечено какого-либо ухудшения характеристик
W-28 Повторить тест W-27 с меньшим количеством ре- сурсов, т е. число Web-серверов должно быть на единицу меньше устраненные ре- Все пользователи могут полу- сурсы = чить доступ к системе и работать с различными функциями Web-узла; в системе не отмече- но какого-либо ухудшения характеристик
Тестирование Web-приложений
231
Для WWW очень естественным кажется тот факт, что различные пользователи по-
разному взаимодействуют с приложением, сильно влияя на характеристики. К числу
аспектов, которые могут повлиять на характеристики, относятся:
• высокая активность и объемы пользователей во время запуска;
• время суток;
• пики активности из-за маркетингового стимулирования;
• нехватка ресурсов из-за множества пользователей в сети;
• время загрузки;
• модель пользования;
• время обдумывания;
• инте! гсивность входного потока пользователей;
• платформы клиентов;
• скорость доступа к Internet;
• скорость выходного потока.
Тестирование, проведенное в локальных системах, хорошо зарекомендовало себя
при проверке качества, но не дает возможности измерить время ответа, связанное с
запаздыванием в Internet. Тестирование, проведенное в географически отдаленных
районах, позволяет оценить вклад всех относительных запаздываний. Размер каждой
страницы и количество изображений, используемых на Web-узле, также может по-
влиять на характеристики приложения. Реализация браузера, кэширующего сценарии
тестов, чтобы подтвердить адекватность времени ответа, является ключевой обла-
стью для наблюдений в ходе тестирования характеристик.
Тестирование характеристик должно проводиться на ранней стадии цикла тести-
рования. Во многих организациях тестирование характеристик планируется на по-
следний крут тестирования. Такой метод планирования может оказаться не слишком
эффективным, в особенности если по результатам тестирования характеристик опре-
деляются основные дыры в проекте. Тестирование характеристик нужно проводить
тогда, когда команда по тестированию установила, что функциональные возможности
приложения стабильны.
В табл. 7.8 представлены образцы тестовых примеров, рассматриваемых в ходе
тестирования характеристик. Согласование времени, основной предмет беспокойст-
ва, должно задаваться в требованиях.
Таблица 7.8. Пример тестирования характеристик
ID тестового примера Описание входных данных Входные данные ' ' J ' ’-s :• Реальные результаты
W-29 1 Найти книгу 2. Зафиксировать время ответа на запрос 3. Повторить этот тест до 4 раз запрос= Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям
W-30 1. Выбрать страницу СЛЕДУЮЩАЯ из набора возможностей просмотра 2 Зафиксировать время ответа, потраченное на отображение следующей страницы 3. Повторить этот тест до 4 раз текущая страница = следующая страница = Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям f •*
W-31 1. Передать заполненную форму покупателя 2 Зафиксировать время ответа, за которое было получено подтверждение покупки 3. Повторить этот тест до 4 раз купленная книга (книги)= Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям
W-32 1 Включить в браузере возможность кэширования 2. Заполнить форму 3. Передать форму 4. Зафиксировать время ответа, измеренное как время ответа между конечными точками (т.е. браузер-WWW-Web-узел - WWW-браузер) 5. Повторить этот тест до 4 раз переданная форма = Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям
Окончание табл. 7.8
ID тестового примера Описание входных данных Входные данные Ожидаемые результаты Реальные J результаты
W-33 1. 2. 3. 4 5. Отключить возможность кэширования в браузере Заполнить форму Передать форму Зафиксировать время ответа, измеренное как время ответа между конечными точками (т е. 6pay3ep-WWW-Web-y3en- W WW-браузер) Повторить этот тест до 4 раз переданная форма = Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям
W-34 1. 2. 3. 4. 5. Войти в систему из отдаленного места или использовать автоматическое соединение, чтобы получить доступ к Web-узлу Заполнить форму Передать форму Зафиксировать время ответа, измеренное как время ответа между конечными точками Повторить этот тест до 4 раз отдаленное расположение = переданная форма = Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям
W-35 1. 2. 3. Инициировать запрос браузера Зафиксировать время ответа сервера Web-узла Повторить этот тест до 4 раз переданный запрос = Зафиксировать минимальное, максимальное и среднее время ответа и убедиться, что они удовлетворяют требованиям
234
Глава 7
Тестирование масштабируемости
Понятие масштабируемости касается возможности Web-узла оперировать объема-
ми и типами видов деятельности, которые встречаются после запуска. Организации
нужно убедиться в том, что выпускаемая система, у которой во многих ситуациях ха-
рактеристики остаются приемлемыми, может поддерживать уровни транзакции после
запуска узла. На масштабируемость влияют следующие типы сценариев:
• насколько близко среда тестирования совпадает с производственной средой;
• миллионы пользователей получают доступ к узлу во время запуска;
• пики активности, связанные с маркетинговым стимулированием.
Чтобы убедиться в масштабируемости системы, необходимо решить следующие
ключевые задачи:
• определить, какой тип сценария ожидается;
• установить деловые циклы;
• спланировать производительность, моделируя пользователей, которые пред-
положительно будут получать доступ к Web-узлу;
• установить уровни и типы деятельности, которые могут ухудшить характери-
стики;
• задать меру для характеристик (например, запросы в секунду и транзакции в се-
кунду).
Еще один аспект тестирования масштабируемости заключается в определении
различных типов посетителей и ожидаемого взаимодействия с ними. Случайные
пользователи любопытны и будут осматриваться на Web-узле. Другие пользователи
стремятся вести дела, запрашивая информацию или банковские транзакции и покупая
продукты у розничного торговца. Эти тесты отражают различные действия пользова-
телей, а именно:
• простую навигацию rto узлу;
• базовые операции с узлом;
• углубленные операции ключевых функций.
Следующий этап состоит в оценке числа посетителей каждого типа в различное
время
Более детальное изложение проблем, связанных с масштабируемостью, а также
примеры сценариев тестирования масштабируемости можно найти в публикации
[Segue 00].
Тестирование загруженности
Цель тестирования загруженности — смоделировать ощущение реального мира
путем генерации множества пользователей, получивших доступ к Web-узлу. Автоматизация
Тестирование Web-приложений
235
увеличивает способность проводить эффективные тесты по загруженности, посколь-
ку появляется возможность эмулировать тысячи пользователей, отправляя одновре-
менные запросы в приложение или на сервер. Для создания адекватных сценариев за-
груженности тестеры используют информацию, полученную из журнала ежедневной
регистрации коэффициента загрузки, чтобы воспроизвести реалистичную загрузку
пользователей. В некоторых случаях к журналу регистрации коэффициента загру-
женности сложно получить доступ, и работы по тестированию зависят от специфика-
ций требований, так как тестерам нужно понять требования к характеристикам сис-
темы.
Поскольку для многих организаций нереально воспроизвести среду тестирования,
сравнимую с производственной средой, тестеры должны предоставить надежные ре-
зультаты теста команде проекта, чтобы иметь возможность экстраполировать изме-
рения, сделанные в среде тестирования. Это непростая задача, поскольку при срав-
нении может не оказаться взаимно однозначного отношения. В этом случае команде
проекта важно правильно понять окончательные результаты и достичь согласия в их
отношении.
Подготовка к тестированию загруженности
Тестирование загруженности для успешного выполнения тестов по загруженности
с самого начала должно быть тщательно спланировано, что сократит время тестиро-
вания. Однако даже при оптимальном планировании тестирование загруженности
иногда необходимо повторить, по крайней мере, один раз и, следовательно, потра-
тить больше времени, чем предполагалось вначале (так как придется настраивать тес-
ты по загруженности).
В следующем руководстве представлено несколько важных моментов в подготовке
тестов по загруженности для успешного их завершения.
1. Понять требования системы к загруженности. Изучить общее и текущее число
пользователей, которое может понадобиться для поддержки Web-узла. У при-
ложений, выпущенных впервые, нет исторической статистики. Команда по
тестированию может оказаться зависимой от спецификации требований, так
как необходимо будет собрать такие специфические данные:
• число пользователей в виде любого уникального числа посещений за день,
за неделю или за месяц;
• текущее суммарное количество пользователей: наихудший вариант сцена-
рия в часы пик;
• максимальное значение скорости запросов: число с траниц, обслуживаемых
за секунду.
2- Установить, какие инструменты (например, инструменты для тестирования и
мониторинга) будут использоваться при проведении тестов по загруженности.
3. Сгенерировать достаточное число пользователей и транзакций, чтобы оценить
возможности и характеристики, которые будут поддерживаться в живом окру-
жении.
236
Глава?
4. Создать базис: сценарии для имитации одного пользователя с одним браузером.
5. Создать сценарии тестов для имитации нескольких сеансов связи, установлен-
ных на нескольких браузерах.
6. Определить все остальные приложения, запускаемые на сервере приложений,
чтобы фиксировать корректную деятельность системы. (Многие приложения,
запускаемые одновременно в одной системе, могут повлиять на характеристики.)
7. Вьыюлнить тест (тесты) несколько раз.
8. Определить участников, которые будут контролировать системные характери-
стики в ходе выполнения теста.
9. Провести формальные инспекции на сценариях тестов.
10. Подготовить результаты тестов, в которых будет фиксироваться минимальное,
максимальное и среднее время ответа системы.
Выполнение тестов по загруженности
На выполнение тестов по загруженности нужно потратить время, особое внима-
ние следует обратить на настройку реальных тестов. За информацией относительно
планирования и проведения тестов по загруженности в производственной среде
можно обратиться к разделу “Тестирование после реализации”.
Тестирование давления
При тестировании давления система подвергается переменным и максимальным
нагрузкам для оценки результирующих характеристик. Существуют автоматизирован-
ные инструменты тестирования, которые имитируют загруженность на любом Web-
узле и непрерывно выполняют тес гы на протяжении нескольких часов или дней.. Эти
инструменты могут предост авлять информацию следующих типов:
• число запросов, транзакций и килобит в секунду,
• время на передач}' и подтверждение приема (время, которое прошло с момен-
та, когда пользователь сделал запрос, до момента, когда он получил результи-
рующую информацию);
• текущее число соединений;
• ухудшение характеристик;
• типы посетителей узла;
• число посетителей каждого типа в течение какого-либо периода времени;
• коэффициент загрузки ЦП и памяти серверов приложений.
Еще один тип тестирования давления заключается в подтверждении надежной ра-
боты приложения в момент, когда доступная память или ресурсы процессоров близки
к предельным значениям. Например, если система может оперировать одновременно
с 50 пользователями, нужно создать сценарий теста, который будет выполняться не-
сколько часов, поддерживая 50 пользователей. Использование инструментов для мо-
ниторинга в ходе этого теста может помочь установить потенциальные критические
Тестирование Web-приложений
237
места в системе. Располагая такой информацией, разработчик может заранее опреде-
лить дополнительное аппаратное обеспечение или изменения в проекте, необходи-
мые для того, чтобы обеспечить будущее увеличение числа пользователей, получаю-
щих доступ. Однако в процессе работы с этим типом тестирования требуется высокая
степень случайности при реализации каждого имитируемого пользователя. В против-
ном случае можно увидеть пики и впадины в характеристиках, которые будут регу-
лярными и совершенно искусственными. Один из способов смягчения этой проблемы
заключается во внесении элемента случайности в момент времени между двумя после-
довательными действиями для каждого пользователя, а также в изменении интервала
времени между окончанием одного теста и началом следующего.
Тестирование давления не ограничивается осмотром Web-приложений пользова-
телем. Вычислительная машина баз данных также должна подвергаться тестированию
давления, помогая установить потенциальные критические места. Тестеры должны
решить, каким образом выполнять такие тесты: в изолированном окружении или в
среде WWW. Специфические сценарии тестов перечислены ниже.
1. Предположим, что база данных может обработать перечень из 100 000 книг,
сравнить время, которое было затрачено на введение 100 записей в базу данных
со временем, потраченным на введение 99 999 записей.
2- Выполнить тесты со 100 пользователями, получившими доступ к одной и той
же записи в базе данных, наряду со сравнением bj измени ответа, когда один
пользователь запросил запись.
На подготовку и выполнение тестов по давлению может повлиять несколько фак-
торов.
1, Сопоставима ли с^эсда тестирования с производственной средой по памяти и
процессорам? Если это не так, то может понадобиться запустить тесты в произ-
водственной среде. За дополнительными сведениями по проведению тестов в
производственной среде можно обратиться к разделу “Тестирование после реа-
лизации”.
2. Свободна ли среда тестирования от других информационных потоков, которые
не изменяют результатов тестов по давлению?
3. Каким будет наихудший сценарий? Создать тестовый пример, который будет
удовлетворять таким условиям.
После того как тестирование давления завершено, команда проекта должна ре-
шить, приемлемы ли отмеченные ухудшения относительно применяемых условий
давления. Ухудшения могут встречаться в любом из отмеченных выше сценариев.
Предполагается, что характеристики медленно ухудшаются, когда экстремальное ко-
личество пользователей одновременно обращается к узлу. Оценить ухудшение харак-
теристик поможет управление при допущении риска, которое обсуждается в главе 8.
238
Глава 7
Тестирование безопасности
Безопасность вызывает особый интерес при деловом общении и ведении дел
(в особенности в случае конфиденциальных сообщений и критичных для бизнеса
транзакций) через Internet. Пользователь должен быть уверен, что его личная и фи-
нансовая информация будет в безопасности. Очень важно обнаружить уязвимые мес-
та в приложении, которые могли бы позволить несанкционированный доступ поль-
зователя к системе.
Не принимая во внимание требование приложения относительно ввода пользова-
телем кодового слова, чтобы получить доступ к Web-узлу, тестер должен провести
проверку известных на данный момент угроз в сети Internet. В определении дополни-
тельных тестов, связанных с безопасностью, могут помочь ответы на следующие во-
просы.
1. Какие существуют меры предосторожности для предотвращения или ограни-
чения атак со стороны хакеров?
2- Настраиваются ли в браузере установки, гарантирующие максимально безопас-
ную защиту?
3. Как Web-узел оперирует правами доступа?
4. Есть ли в приложении программа обнаружения вирусов для пользователей, во-
шедших в систему посредством сетевого теледоступа или стороннего внутрисе-
тевого провайдера?
5. Оперирует ли приложение тайными действиями транзакций, т.е. изменением
первоначального адреса отправки?
6. Предоставляют ли поставщики e-commerce механизм предотвращения мошен-
ничества с кредитными карточками?
7. На месте ли системный журнал, как часто он проверяется, автоматически оп-
ределяя подозрительное поведение?
8. Как Web-узел шифрует данные?
9. Каким образом Web-узел аутентифицирует пользователей?
10. Дает ли возможность просмотр исходного кода выявить наиболее важную ин-
формацию?
11. Можно ли получить доступ к системе и нанести ей ущерб путем прямого вызова
баз данных по коммутируемым линиям связи посредством модема?
12. Как защищены кредитные карточки или информация пользователя? Какая за-
щищенность считается достаточной?
13. Допускает ли приложение файлы, обозначенные цифрами? (Туг используется
технология шифрования с открытым ключом, гарантирующая, что стороннее
лицо не нанесет вред файлу.)
Программное и аппаратное обеспечение, содержащее брандмауэры, является
ключевой компонентой в поддержке защищенности сети от злоумышленников. Задача
Тестирование Web-приложений
239
тестирования брандмауэра заключается в уничтожении и блокировке механизмов
безопасности для того, чтобы определить их эффективность. Регистрация и рассмот-
рение сетевого информационного потока (как входящего, так и исходящего) — это
основной вид деятельности при тестировании брандмауэров. Еще один аспект заклю-
чается в выполнении тестов на проникновение, в которых авторизованная личность
пытается вмешаться в работу сети. Тестирование брандмауэра подтверждает, что:
• фильтрация пакетов работает так, как было заложено в проекте;
• брандмауэр корректно реализует политику безопасности компании (например,
если в политике утверждается, что брандмауэр должен пересылать весь почто-
вый поток данных на почтовый сервер, то тестер должен в этом убедиться);
• брандмауэр при необходимости подает аварийный сигнал;
• в периметре, созданном брандмауэром, не должно быть никакой утечки (утечка
происходит, когда процедура доступа к сети отличается от доступа через суще-
ствующие защищенные ворота, позволяя таким образом злоумышленнику
обойти защиту брандмауэра, чтобы попасть в сеть);
• брандмауэр скрывает информацию и адреса из внутренней сети, которую он
защищает;
• адекватная регистрация событий помогает отыскивать злоумышленников и на-
ходить дыры в системе безопасности, вызванные каким-либо происшествием.
Полная проверка безопасности Web-узла требует наличия специальных знаний в
области информационных технологий. Часто специалисты по системам безопасности
из внешних организаций дают оценку по вопросам безопасности, относящихся к на-
стройкам браузера, протоколам системы безопасности, брандмауэрам, шифрованию,
а также злонамеренному использованию cookies, вирусам и управляющим элементам
ActiveX. Среднему тестеру иногда не хватает компетентности в этих областях, однако
он может эффективно оценить такие ситуации, как вход в систему и интерактивная
оплата.
Тестирование безопасности требует особой осторожности. Небрежные процеду-
ры тестирования могут привести к непреднамеренным повреждениям или разруше-
ниям из-за перегрузки сети запросами на обслуживание и скручивания портов на
главных машинах. Кроме того, организация должна оберегать результаты тестов,
чтобы не дать возможности неавторизированным личностям узнать что-либо об уяз-
вимых местах системы.
Тестирование сквозных транзакций
Сквозные транзакции придерживаются последовательности выполняемых клиен-
том действий начиная с момента посещения и заканчивая моментом ухода с узла.
Здесь тестируются отдельные компоненты, которые выполняют отдельные транзак-
ции и к которым могут относиться Web-браузеры, Web-серверы, серверы приложе-
ний, базы данных и промежуточное программное обеспечение. Ведение дел таким
образом базируется на e-commerce. Тестовые примеры для тестирования сквозных
240
Глава?
транзакций служат дополнением к тестированию практичности, следуя логике после-
довательности выполняемых действий и сочетая множество видов деятельности в ре-
альные тесты. В примере с витриной магазина последовательность выполняемых
действий следующая.
1. Клиент посещает узел.
2- Клиент просматривает книги.
3. Клиент выбирает книги и помещает их в тележку для покупок.
4. Клиент указывает адрес доставки.
5. Клиент платит за покупку.
6. Магазин отсылает квитанцию пользователю по электронной почте.
К сквозным транзакциям относится также обработка любых неблагоприятных ус-
ловий, которые возникли в результате запросов клиентов, например:
1. Выбранной книги нет в наличии.
2. Книги нужно специально заказывать.
3. Клиент хочет удалить из корзины для покупок одну или несколько выбранных
книг.
4. Клиент хочет отменить заказ (до или после покупки).
5. Клиент хочет вернуть деньги.
6. Кредитная карточка, используемая для покупки, оказалась непригодной (т.е. не-
действительной) .
Вследствие использования различных комбинаций действий пользователя необ-
ходимо, чтобы в своей основе тестовый пример походил на поток через Webyaea.
Однако нет необходимости в излишне детализированных тестовых примерах. На-
пример, тестер решает, каким образом выполнять действия: с помощью мыши, кла-
виатуры или комбинируя и то и другое. Указание таких деталей относится к тестиро-
ванию функциональных возможностей. В данном случае цель выполнения теста —
проанализировать комбинации действий. В табл. 7.9 перечислены образцы тестовых
примеров для тестирования сквозных транзакций.
Тестирование баз данных
Тестирование баз данных часто является очень важной частью тестирования
WWW, поскольку многие Web-узлы предоставляют какой-либо тип возможности поис-
ка. Продукты или информация на Web-узлах обычно хранится в базах данных, облег-
чающих и ускоряющих поиск выбранного элемента. В некоторых приложениях есть
данные, вводимые пользователем, которые затем становятся частью баз данных.
При тестировании баз данных требуются всесторонние знания тестируемого при-
ложения. Необходим также дополнительно оговоренный план подхода к тестирова-
нию данных. Как минимум, тестер должен иметь возможность запросить базу данных
в определенных точках последовательности выполняемых действий. Тестеру важно
Тестирование Web-приложений
241
понимать концепции проекта базы данных и правила реализации. К ключевым про-
блемам, возникающим при тестировании баз данных, относятся:
• целостность данных;
• достоверность данных (подходящая форма при вводе в базы данных);
• манипуляции с данными и обновления (обновления значения количества про-
данных книг, доступных КНИГИ Т.Д.).
Целостность данных — это основное условие успешной реализации Web-узла. Ор-
ганизация должна установить средства для контроля искажения данных. Искажение
данных часто обнаруживается только на поздних стадиях, поскольку искажения про-
исходят в подходе “создание блоков”. Все начинается с малого, но со временем (или с
увеличением числа транзакций) проблема усугубляется. Установка подходящих точек
проверки может помочь ослабить искажение данных. Например, если осуществлять
ежедневный пересмотр журнала транзакций, то тем самым можно облегчить отсле-
живание изменений в базах данных.
При тестировании баз данных также нужно учитывать достоверность данных.
Достоверность данных гарантирует предоставление клиентам точной информации и
возврат этой информации в базу данных. Как правило, доля дефектов в данных зна-
чительно больше, чем в самом приложении. В таком случае необходимо изучить по-
следовательность выполняемых действий и проверить базу данных в точках измене-
ний. Этот подход заключается в изоляции действий, которые модифицируют базы
данных, а также в инспектировании измененного содержимого на предмет коррект-
ности. Важно, чтобы тестер осознавал области риска и правильно расставлял при-
оритеты при тестировании. Проведение оценки степени риска, как описано в главе 8,
даст возможность установить тестовые примеры с более высоким приоритетом и по-
может уменьшить риск.
Тестирование баз данных выполняется на двух уровнях: административных и
пользовательских функций. Администратор баз данных может выполнить ограничен-
ные действия, недоступные для клиентов Web-узла. В примере с книжным магазином
к наиболее распространенным административным действиям относятся:
• добавление новых книг в перечень товаров;
• удаление существующих книг из перечня товаров;
• обновление специфических полей, таких как изменения в ценообразовании.
Следующий контрольный список поможет сформулировать множество дополни-
тельных административных тестовых примеров.
1. Понять проект базы данных.
2. Установить основные риски.
3. Понять средства управления безопасностью проекта; разобраться, какими
должны быть ID пользователя, чтобы ему разрешался доступ записи/чтения к
средствам управления базой данных.
4. Понять процедуры o6i ювления и усовершенствова! гия обслужива! 1ия баз данных.
242
Глава 7
5. Убедиться, что требования были удовлетворены.
6. Убедиться в работоспособности и производительности, когда несколько поль-
зователей одновременно выполняют одну и ту же задачу или делают запрос
(а также включить максимальное число совместно или одновременно дейст-
вующих пользователей согласно спецификации).
7. Убедиться, что процедуры резервного копирования и восстановления работа-
ют так, как было спроектировано, и не влияют на требования доступности.
8. Убедиться, что база данных допускает максимальное число соединений, кото-
рые система согласно проекту должна обрабатывать.
9. Убедиться, что при выполнении операций базы данных имеется достаточно
места и памяти для определенного количества данных. Расширить возможно-
сти системы, если эти физические пределы пространства и памяти превыша-
ются.
В примере с книжным магазином Web-приложение и Web-интерфейс пользователя
со временем остаются неизменными. Изменения происходят только при добавлении
книг и отслеживании списка клиентов (если приложение действительно отслеживает
привычки клиента, чтобы иметь возможность в будущем стимулировать продажи).
Доступ пользования к этой базе данных состоит преимущественно в поиске инфор-
мации. Для других Web-узлов, в которых базы данных изменяются непрерывно, опти-
мизация и скорость получения результатов поиска и ввода остаются критичными.
В табл. 7.10 представлено несколько общих образцов тестовых примеров для тести-
рования приложения “Книжный магазин”. Информация в столбце “Ожидаемые ре-
зультаты” будет изменяться в зависимости от требований к базам данных. Например,
задание имени несуществующего автора может дать в результате один или несколько
возможных исходов. Приложение может послать сообщение об ошибке, предложить
альтернативное написание или предоставит!, список книг, написанных авторами с
аналогичными именами.
Тестирование после реализации
Основная причина проведения тестирования после реализации заключается в
проверке поведения приложения в производственной среде. В большинстве случаев
невозможно дублировать тестовую среду таким образом, чтобы она сравнялась с про-
изводственной, поэтому команда по продукту должна запланировать результирующий
тест в производственной среде. При этом организация получит ценное подтвержде-
ние того, что Web-узел можно найти с помощью средств поиска, узловых пауков и ме-
татегов.
Поскольку большинство организаций, работающих на основе технологий WWW,
стараются находиться в сети круглосуточно, тестирование после реализации обычно
происходит в “окне сопровождения продукции”. Наиболее вероятным временем, вы-
деленным для такого окна, будет время, когда активность пользователей низка
(скажем, в 1:00 в Воскресенье), за исключением тех случаев, когда это время совпадает
с пиковой активностью на других узлах в мире.
Таблица 7.9. Образцы тестовых примеров для сквозных транзакций
ID тестового примера Описание входных данных Входные данные Ожидаемые результаты Реальные результаты
W-36 1. Просмотреть узел и добавить несколько добавленные книги = В корзине для покупок
книг (одну книгу) в корзину для покупок 2. Оценить содержимое корзины для покупок 3 Удалить книгу из корзины для покупок удаленная книга = перечисляются книги (книга) за исключением той, которая была удалена
W-37 1. Просмотреть узел и добавить несколько добавленные книги = Выход из меню покупок
книг (одну книгу) в корзину для покупок и возврат к странице
2. Купить книги 3. Перед введением номера кредитной кар- корзины для покупок
точки отменить заказ
W-38 1 Просмотреть узел и добавить несколько добавленные книги = Обрабатывается транзакция
книг (одну книгу) в корзину для покупок, информация, и отправляется
включая несколько специально заказываемых наименований товара предоставленная при покупке = подтверждающее почтовое сообщение
2. Купить книги 3. Передать форму
W-39 1. Просмотреть узел и добавить несколько выбранные книги = 1. Обрабатывается
книг в корзину для покупок транзакция и отправля-
2. Купить книги с помощью кредитной карточки ется подтверждающее почтовое сообщение
3. Передать транзакцию 4. Попросить вернуть деньги 2. Посылается отдельное почтовое сообщение для подтверждения отмены
заказа
Окончание табл. 7.9
ID тестового примера Описание входных данных Входные данные Ожидаемые результаты Реальные результаты
W 40 1. Просмотреть узел и добавить несколько книг в корзину для покупок 2. Купить книги добавленные книги = кредитная карточка = Покупка отменяется и поль- зователь отсылается назад на другую страницу
3. Представить недействительную кредитную
карточку
W-41 1. Просмотреть узел и добавить несколько добавленные книги = Выдается сообщение об
2. книг в корзину для покупок Купить книги, но заполнить не все обяза- пропущенные поля = ошибке, указывающее на отсутствие информации
тельные поля
3. Передать форму
Таблица 7.10. Образцы тестовых примеров для баз данных
ID тестового примера Описание входных данных Входные данные Ожидаемые результаты Реальные результаты
W 42 Выполнить поиск книги, задав верное имя автора автор = Отправляется список книг, написанных этим автором
W-43 Выполнить поиск книги, задав верное, но не уникальное имя автора автор = Отправляется список книг, написанных всеми авторами с такими именами
W-44 Выполнить поиск книги, задав сочетание автор = Отправляется информация
•* верного имени автора и названия книги название= об этой книге
W 45 Выполнить поиск книги, задав несуществующее имя автора автор = Имя автора не найдено. Отправляется предложение альтернативных написаний
Окончание таЬл. Ю
ID тестового примера Описание входных данных Входные данные Ожидаемые результаты — Реальные результаты
W-46 Выполнить поиск книги, задав верное имя автора, но несуществующее название автора название = Название не найдено. Перечисляются книги, написанные этим автором
W-47 1. Выполнить поиск верной книги по названию 2. Администратор изменяет цену на книгу 3. Выполнить поиск той же книги по названию название= новая цена = 1. Отправляется информация о книге 2. Обновляется база данных 3. Отправляется информация о книге с перечислением новых цен
W-48 Выполнить одновременно следующие шаги • Администратор добавляет новую книгу • Клиент ищет эту книгу автор = название= В результате поиска может быть отправлена неполная информация, например, пустые поля
W-49 Несколько пользователей должны одновременно сделать один и тот же запрос* критерий поиска = число пользователей = Всем пользователям предоставляются точные результаты с приемлемым временем ответа
Каждый запрос выполняется на отдельном компьютере при настройках LAN/lnternet с использованием подходящего браузера.
246
Глава 7
Стратегия сопровождения
Создание гармоничного набора задач, предшествующих реальным тестам или окну
сопровождения, увеличивает уверенность в качестве выпусков программного обеспе-
чения. Выполнение этих тестов перед выпуском продукта предоставляет тестерам
больше шансов обнаружить проблемы, которые были незаметными в ходе цикла тес-
тирования, и, следовательно, оценить реальные характеристики новой системы в
производственной среде.
Для проведения тестов после реализации требуется следующая информация:
• временная шкала событий;
• определение команды сопровождения;
• таблица контрольных проверок для тестов по загруженности с доступными
сценариями загруженности;
• план отката в случае неудачи.
Тщательная подготовка является ключевым фактором успешной и эффективной
стратегии. Чем раньше выполняется планирование, тем больше в конечном счете
экономится времени.
Временная шкала
Во временной шкале перечисляются важные события, которые должны произой-
ти. В эту временную шкалу, приведенную в табл. 7.11, входит время, задачи и люди,
отвечающие за каждую из этих задач.
Понятие теста “на дым” описывает исходный набор тестов, который определяет,
достаточно ли хорошо функционирует новая версия приложения для дальнейшего
тестирования. После того как приложение прошло через эту контрольную точку, тес-
теры выполняют тесты, позволяющие определить, можно ли выпускать приложение.
Такие тесты нуждаются в одобрении со стороны пользователей, которые подтвер-
ждают, что система удовлетворяет требованиям пользователя и готова к эксплуата-
ции. В иных ситуациях это могут быть регрессионные тесты (с несколькими новыми
тестами для проверки новых функций), которые оценивают пригодность приложе-
ния для выпуска. В этом контексте термин тест на одобрение относится к тестам, кото-
рые выбираются тестерами одновременно с менеджером по продукту и определяют
готовность продукта. Решено (не решено) продолжать тестирование — это точка, в
которой менеджер по продукту определяет, выпускать ли новый продукт в имеющей-
ся на да; 1ный момент форме. у
Команда сопровождения
В таблице членов команды, включенных в окно сопровождения после реализации
(табл. 7.12), перечисляются основные участники, которым нужно быть на месте
или находиться на связи во время тестирования. Эту' таблицу можно модифици-
ровать согласно специфическим званиям, ролям, именам, контактной информации и
числу сотрудников в каждой организации.
Тестирование Web-приложений
247
Таблица 7.11. Временная шкала событий
Зада1 a -z' » » Специалист Завершение задачи (пройдена/ провалена)
1:00 Скачать новые компоненты: Разработчик
перечислить компоненты и число версий, заданные в "Примечаниях к выпуску"
1:45 Установить интерактивный режим для системы и запустить тест "на дым" Разработчик
2:00 Тест на одобрение начат Тестер № 1
2:45 Тест на загруженность начат Тестер № 2
3:30 Тест на загруженность закончен Тестер № 2
4:00 Тест на одобрение закончен Тестер Ns 1
4:15 Решено/не решено продолжить Менеджер по продукту
4:15 Перейти к плану отката, если необходимо Все
Таблица 7.12. Команда после реализации
•<М1Ь ^Функция ' Специалк т На « e/Ra связи Контактная информация 1
Ведущий разработчик Поддержка на месте на месте
Тестер №1 Тест на одобрение — комплект 1 на месте
Тестер Ns 2 Тест на одобрение - комплект 2 на месте
Тестер Ns п Тест на одобрение - комплект п на месте
Тестер Ns m Тест на загруженность на месте
Разработчик Наблюдение за системой продукции на месте
Менеджер по продукту Полномочие решать продолжать или нет на связи
Таблица контрольных проверок теста на одобрение
В табл. 7.13 представлена таблица контрольных проверок, которую тестеры могут
использовать в окне сопровождения для выполнения теста на одобрение.
248 Глава 7
Таблица 7.13. Таблица контрольных проверок теста на одобрение
Ответственный тестер Тест компонент Завершение теста (прошел/провалился)
Тестер № 1 Указать используемые браузер/платформу. Сквозная транзакция. Проверка выписывания счета. Проверка системного журнала на сервере ’ ит.д.
Тестер № 2 Указать используемые браузер/платформу. Сквозная транзакция. Файл справки. Удалить книгу из корзины для покупок. Убедиться, что приоритетные проблемы, найденные в ходе тестирования приоритетов, были должным образом устранены
Тестер №п Указать используемые браузер/платформу. И т.д.
Таблица контрольных проверок теста на загруженность
Табл. 7.14 помогает тестерам отслеживать этапы проведения тестов на загружен-
ность. Поскольку время для сопровождения ограничено, сценарии тестов на загру-
женность должны быть готовы до начала тестирования после реализации.
Таблица 7.14. Таблица контрольных проверок теста на загруженность
Ответственный тестер Тест компонент Завершение теста (прошел/провалился)
Тестер №1 Выполнить сценарий теста на загруженность. Поработать с системотехникой, чтобы понаблюдать за характеристиками системы. Повторно выполнить сценарий теста на загруженность. Представить результаты менеджеру
План отката
В случае, когда для выпуска следует выполнять откат, нужна ситуационная стра-
тегия, охватывающая в общих чертах весь план отката. Этот план гармонично соче-
тается с процедурой очистки для возврата производственной среды в исходное со-
стояние, согласно которой тест на признание повторяется, чтобы подтвердить, что
Тестирование Web-приложений
249
восстановленное состояние функционально. В табл. 7.15 показана возможная вре-
менная шкала для отката продукта.
Таблица 7.15. Временная шкала плана отката
Время — Задача Специалист Завершение задачи (прошла/про валилась)
4:30 Выполнить откат для новой компоненты. Перечислить компоненты и номер версии (этот список должен быть принят до начала реального тестирования) Разработчик
5:30 Установить интерактивный режим для системы и запустить тест "на дым" Разработчик
5:45 Тест на одобрение начат Тестер № 1
6:00 Тест на загруженность начат Тестер № 2
7:00 Тест на загруженность закончен Тестер № 2
7:30 Тест на одобрение закончен Тестер № 1
Резюме
При тестировании Web-приложений возникают новые проблемы, поскольку тех-
нологии непрерывно изменяются, число браузеров увеличивается, контролировать
пользовательское окружение невозможно, а число пользователей и круглосуточная
доступность узла непредсказуемы.
В этой главе обсуждались некоторые аспекты и соответствующие подходы к под-
готовке тестов, их выполнению и документированию результатов.
Тестирование функциональных возможностей подтверждает, что основные функ-
ции работают корректно, здесь оценивается только один аспект Web-приложений.
В других типах тестирования специфика проблем переносится в среду WWW. Многие
из этих типов тестирования также эффективны и для окружения клиент-сервер.
При тестировании практичности с помощью наблюдения за пользователями во
время их взаимодействия с узлом оценивается дружелюбие узла к пользователям.
При тестировании навигации путем проверки доступа к узлу, изображениям, ссыл-
кам и другим компонентам узла подтверждается, что пользователь может выполнить
желаемую задачу.
При тестировании форм подтверждается, что каждое поле работает так, как нужно.
При тестировании содержимого страницы подтверждается, что информация,
предоставляемая узлом, корректна.
При тестировании конфигурации и совместимости подтверждается, что прило-
жение функционирует корректно в различных аппаратных и программных средах.
При тестировании надежности и доступности оценивается доступность Web-узла в
любое время по запросу пользователя. Такая оценка достигается путем тестирования
приложения в пиковое время использования (в периоды маркетинговой стимуляции
и циклов высокой активности).
250 Глава 7
способность Web-узла удовлетворять требованиям к загруженности. Во время тести-
рования загруженности оценивается функционирование системы при одновремен-
ной обработке большого количества запросов от множества пользователей. При тес-
тировании давления система подвергается переменным нагрузкам.
Во время тестирования сквозных транзакций выполняются тесты для всех компо-
нентов, которые осуществляют отдельные транзакции, придерживаясь последова-
тельности действий, выполняемой клиентом с момента входа до момента выхода с
узла.
При тестировании баз данных проверяется целостность хранимых данных, а так-
же информация о продукте, которая используется Web-узлом.
При тестировании после реализации проверяется поведение приложения в про-
изводственной среде. Сюда входит создание плана оката, если необходимо выполнить
откат выпуска и постепенно восстановить окружение продукта до исходного со-
стояния.
ГЛАВА
Сокращение числа тестовых
примеров
Введение
В методах проектирования тестовых примеров прослеживается тенденция к росту
числа тестовых примеров. В большинстве проектов почти невозможно провести все
тесты, так как график работы многих проектов из-за сильных временных ограниче-
ний очень плотный. Есть и другие причины, по которым необходимо уменьшать чис-
ло тестовых примеров, а именно:
• приближение даты выпуска;
• нереально большое число тестовых примеров;
• ограниченные кадровые ресурсы;
• ограниченный доступ к тестовому оборудованию.
В этой главе представлено несколько методов, позволяющих снизить количество
используемых тестовых примеров. Хотя ни один из методов не позволяет определить
наилучшие тестовые примеры, их задача заключается в разделении тестов на катего-
рии по шкале от наиболее важных к менее важным. Описанные здесь методы помога-
ют установить ключевые для тестирования области и распределить между ними при-
оритеты. Таким образом, тестер будет выполнять в первую очередь наиболее критич-
ные тестовые примеры, а оставшееся время можно потратить на выполнение сле-
дующего набора тестов.
Выбор значимого поднабора тестовых примеров, который наилучшим образом бу-
дет охватывать проблемы, снижая тем самым общее количество тестов и сохраняя
уверенность тестеров в работоспособности продукта, является настоящим искусством
тестирования. Отсутствие оценки потенциальных сложностей в приложении часто
приводит к тестированию наименее критичных функций. Без ах тветствующей оценки
254 Глава 8
Присвоение кода приоритета — это просто запись чисел рядом с каждым описани-
ем теста. Когда коды приоритетов распределены, тестеры оценивают количество
времени, необходимое для выполнения выбранных в каждой категории приоритетов
тестов. Если оценка времени попадает в рамки графика, то задача по разбиению за-
вершена и тесты, которые будут проводиться, определены. В противном случае нужно
будет провести дальнейшее разбиение.
Во втором раунде разбиения можно либо повторно использовать ту же шкалу, либо
привлечь новую схему приоритетов. В этом примере используется новая (пятиуровне-
вая) шкала для дополнительной детализации тестов.
Приоритет 1а Этот тест должен быть пройден, иначе выпуск окажется под угрозой срыва.
Приоритет 2а Этот тест должен быть выполнен до выпуска.
Приоритет За Этот тест выполняется, если позволяет время.
Приоритет 4а С этим тестом можно подождать до следующего выпуска или же провести его вскоре после выпуска.
Приоритет 5а Вероятнее всего, этот тест никогда не будет выполнен.
В строке “Приоритет 1а” внимание уделено наиболее критичным функциям при-
ложения: тест не просто должен быть проведен, он должен быть выполнен успешно.
Тесты, которые в оригинале находились в строке “Приоритет 3”, переместились в
строку “Приоритет 5а”. Тесты из строки “Приоритет 2” теперь разделились между
строками “Приоритет За”, “Приоритет 4а” и “Приоритет 5а”, в то время как тесты из
строки “Приоритет 1” теперь разбиты по новой пятиуровневой шкале. Есть вероят-
ность, что ни один из тестов с приоритетом 1 и 2 не будет помечен приоритетом 5а,
но все же стоит попытаться оценить обоснованность тестов и определить, нельзя ли
какие-либо тесты перевести в более низкую категорию классификации.
Тестеры продолжают расстановку приоритетов для каждого теста, присваивая код
до тех пор, пока число тестов с приоритетами 1а и 2а не даст в результате подходящую
оценку для сроков тестирования. Если оценка продолжительности тестирования пре-
вышает запланированное время, авторитетному лицу проекта следует пересмотреть
выбранные тесты и попы таться перевести некоторые из них в категорию с более низ-
ким приоритетом. Если после нескольких раундов оценка продолжительности тести-
рования в категории с более высоким приоритетом будет по-прежнему превышать за-
планированные сроки, авторитетному лицу придется принять несколько сложных
решений. Для большинства проектов, в особенности для заказываемых определен-
ным клиентом, есть возможность наращиваемого выпуска. В этом случае наиболее
важные, интересующие клиента функции тестируются в первую очередь и выдаются
заказчик}', после чего вскоре следует другой выпуск с протестированными остальны-
ми функциям. Большинство заказчиков могут подождать новых функций в течение
нескольких недель при условии, что их непосредственные нужды будут удовлетворе-
ны. С другой стороны, у организаций, создающих приложения массово-коммерчес-
кого типа, есть лишь узкое окно на рынке и нет возможности наращиваемого выпуска.
В таких обстоятельствах авторитетному лицу проекта следует пересмотреть масштабы
Сокращение числа тестовых примеров
255
"роекта, проанализировать найм дополнительных тестеров и вышеупомянутое адек-
з зтное тестирование или принять иные решения.
Классификация приоритетов, проиллюстрированная выше, является образцом
схемы разбиения. Приоритеты можно задавать по-разному исходя из потребностей
рганизации. Например, возможны следующие категории приоритетов:
• требуется клиенту;
• необходимо для увеличения доли рынка;
• использует новые технологии.
Анализ степени риска
Все проекты по разработке ПО только выигрывают от проведения анализа степе-
ни риска. Нормы критичных к безопасности приложений требуют, чтобы анализ сте-
сени риска был частью планирования и разработки ПО. Приложения критичны к
безопасности, если сбои в их работе приводят к таким катастрофическим результа-
там, как финансовый крах или потеря человеческой жизни.
Даже для некритичного программного обеспечения использование анализа степе-
ни риска в самом начале проекта дает возможность выделить потенциальные про-
' темные области, сбои в которых могут привести к более серьезным неблагоприят-
ным последствиям. Таким образом, при проектировании приложения разработчики и
'енеджеры должны уделить особое внимание этим областям и, следовательно, сни-
зить степень риска. Тестеры используют результаты анализа степени риска для выбо-
ра наиболее критичных тестов.
Компоненты риска
Анализ степени риска — это строго определенный процесс, в ходе которого моду-
1ям для тестирования назначаются приоритеты. Риск состоит из следующих компо-
нентов.
1. Вероятность события (или правдоподобие ошибки) — вероятность того, что
возникнет ошибка.
2. Серьезность влияния (или влияние ошибки) — влияние, которое оказала бы эта
неполадка в случае своего появления.
При анализе степени риска сначала перечисляются потенциальные проблемы, а
затем каждой установленной неполадке присваиваются значения вероятности и серы
езности. Классифицируя результаты, тестер может установить потенциальные про-
блемы, которые больше всего нуждаются в непосредственном внимании, и выбрать
юответствующие тестовые примеры.
256
Глаза 8
В табл. 8.1 представлены результаты анализа степени риска для рассматриваемой
системы. Таблица имеет следующую структуру.
ID проблемы—уникальный идентификатор, облегчающий создание
ссылок на фактор риска.
Потенциальная проблема — краткое описание проблемы.
Вероятность появления — вероятность появления неполадки по шкале
от 1 (низкая) до 10 (высокая).
Серьезность влияния — значение серьезности по шкале от 1 (низкая)
до 10 (высокая).
Риск — произведение вероятности появления и серьезности влияния.
Таблица 8.1. Таблица анализа степени риска
ID Э ' проблемы Потенциальная проблема ' Вероятность появления Серьезность влияния Риск J
А Потеря мощности 1 10 10
В Искаженный заголовок файла 2 1 2
С Неавторизованный пользователь получил доступ 6 8 48
D Базы данных не синхронизированы 3 5 15
Е Неясная пользовательская документация 9 1 9
F Снижение продаж 1 8 8
G Низкая пропускная способность 5 3 15
Значения вероятности и серьезности в табл. 8.1 находятся в диапазоне от 1 до 10.
В некоторых организациях предпочтение может быть отдано 3-х балльной шкале:
низкий, высокий, средний. Кроме того, можно использовать шкалу с диапазоном от 1
до 100, или дробные значения от 0 до 1. Использоваться может любая шкала при усло-
вии, что в ходе анализа поддерживается единообразие.
В некоторых проектах отслеживается история, которая позволяет тестерам мате-
матически вычислить значения вероятности и присвоить значения степени серьез-
ности на основе заслуживающих доверия данных. Если у организации нет никаких
предпочтений (или опыта) в выборе этих значений, самым простым способом будет
выбор проблем, которые соответствуют самому высокому и самому низкому значе-
нию, с последующей оценкой остальных проблем относительно этих экстремальных.
Сокращение числа тестовых примеров
257
Результаты могут быть не слишком внушительными, но они определенным образом
упорядочивают проблемы и, следовательно, указывают на важные тесты.
Произведение значений вероятности и серьезности события дает риск. Данный
результат помогает оценить риск по его порядку: чем выше значение риска, тем важ-
нее протестировать это состояние. Согласно данным табл. 8.1, потенциальные про-
блемы по степени риска располагаются следующим образом: С, D, G, А, Е, F и В. Хотя
у сбоев D и G риск один и тот же, у них разные значения вероятности и серьезности
сбоев.
Для некоторых организаций информации, которую дает анализ степени риска,
достаточно, чтобы определить тесты с высоким приоритетом. Следовательно, если в
качестве критерия выбран риск, то работать нужно с серьезностью и вероятностью
сбоев. Можно также провести дальнейший анализ компонентов риска, рассчитав от-
дельно весовые коэффициенты для значений вероятности и серьезности сбоев. Та-
кой анализ описан в следующем разделе.
Матрица риска
Матрица риска позволяет тестеру оценить и упорядочить потенциальные пробле-
мы, задав, если необходимо, дополнительные весовые коэффициенты для значений
вероятности или серьезности сбоев. Матрица риска не оперирует собственно риском.
Тестеры используют матрицу риска для того, чтобы определить пороговые значения,
которые классифицируют потенциальные проблемы в категориях приоритетов.
Обычно матрица риска имеет четыре квадранта, как показано на рис. 8.1. Каждый
из квадрантов представляет класс приоритетов, которые заданы следующим образом.
Приоритет 1 высокая серьезность и высокая вероятность.
Приоритет 2 высокая серьезность и низкая вероятность.
Приоритет 3 низкая серьезность и высокая вероятность.
Приоритет 4 низкая серьезность и низкая вероятность.
В этом конкретном примере рискованные сбои с высокой серьезностью считаются
более важными, чем сбои с высокой вероятностью. Таким образом, все рискованные
сбои, отображенные в верхнем левом квадранте, попадают в категорию приоритетов 2.
Для другого приложения можно изменить определения приоритетов 2 и 3, как пока-
зано на рис. 8.2. Организации, предпочитающие вариант, представленный на рис. 8.2,
стремятся минимизировать общее число дефектов, ориентируясь на сбои с высокой
вероятностью появления.
Разделение матрицы риска на квадранты— наиболее распространенный метод,
однако тестеры могут определять пороговые значения при помощи других типов гра-
ниц исходя из специфических нужд приложения. Наилучшие пороговые значения
обращены на нужды пользователя.
Если намечается тенденция, при которой весовые коэффициенты серьезности и
вероятности сбоев совпадают, то может подойти схема диагональных полос расста-
новки приоритетов, как показано на рис. 8.3. Данная структура пороговых значений
258
Глава 8
является компромиссом для тех, у кого возникают проблемы с выбором между при-
оритетом 2 и приоритетом 3 в схеме квадрантов.
£
А
F
С
Приоритету
Приоритет 1
Д
L Приоритет 4
Прi эоитп1’2 j
D
В
Е
10
Вероятность
Рис. 8.1. Пороговые значения, разбитые по
квадрантам
А
F
С
Приоритет 3
ПриоритетД
£
ё
X
го
S
жД
t Приоритет 4
Приоритет 2
D
1
В
Е
10
Вероятность
Рис. 8.2. Альтернативные пороговые зна-
чения, разбитые по квадрантам
Сокращение числа тестовых примеров
259
Рис. 8.3. Пороговые значения с разбиением
по диагональным полосам
Иногда менеджеры опасаются, что игнорирование некоторых сбоев с высокой
серьезностью независимо от вероятности может привести к небрежности в отноше-
нии к организации труда. Схема расстановки приоритетов (рис. 8.4) решает этот во-
прос, определяя более высокий приоритет всем серьезным сбоям. Оставшаяся часть
матрицы риска разбивается на несколько областей с более низким приоритетом либо
в виде квадрантов (как показано на рисунке), либо в виде диагональных полос.
Э
О
о
3
m
. Приоритет 1.,,
' Приоритет 3 Приоритет 2
•: Приоритет 5 Приоритет 4
Низкая
Вероятность Высокая
Рис. 8.4. Пороговые значения с разбиением
на основе высокой серьезности сбоев
260
Глава 8
Если все пороговые границы в матрице риска горизонтальны, то расстановка при-
оритетов основывается исключительно на серьезности сбоев без учета их вероятно-
сти. Это аналог схемы разбиения на категории приоритетов, описанной в разде-
ле “Схема приоритетных категорий”.
Анализ степени риска в реальном мире
Среда разработки только выигрывает от проведения анализа степени риска. Кри-
тичные к безопасности программные продукты, разрабатываемые в рамках сформи-
ровавшегося процесса разработки программного обеспечения, обладают четко за-
данными пороговыми значениями риска, полученными на основе исторических дан-
ных, статистической информации и являются объектом индустриальных стандартов
и государственного регулирования. В случае менее структурированной среды тестер
может проанализировать прошлые проекты и посмотреть, какие были обнаружены
серьезные сбои, а затем соответствующим образом уточнить имеющиеся пороговые
значения. Организации, у которых еще нет опыта работы с анализом степени риска
или мало данных о прошлых проектах, могут воспользоваться “линией на песке”
(даже если это пороговое значение совершенно случайно). Точность порогового зна-
чения станет известна только со временем — в виде реакции на выпуск, и тогда поя-
вится информация для отчета о неполадках.
Исчерпывающее изложение анализа степени риска, а также других методов, ка-
сающихся потребностей требовательных к безопасности приложений, можно найти в
работе [Leveson 95].
Во многих публикациях по разработке программного обеспечения описывается
полный процесс анализа степени риска. Кроме определения оценки риска и расстанов-
ки приоритетов по степени риска формальный процесс анализа степени риска включа-
ет управление, изменение и мониторинг степени риска. Дополнительную информацию
по управлению рисками можно найти в работах [Pressman 01] и [McConnell 98].
Определение проблемных
областей в ходе опроса
Предыдущие разделы были ориентированы на анализ степени риска, однако на
качество продукта также в большой степени влияют проблемы, связанные с людьми.
Чтобы разумно выбрать набор тестов, иногда гораздо важнее знать все о людях, от
которых будет зависеть проект, чем просто хорошо разбираться в функциях прило-
жения. Тестер, который присоединился к проекту позже, не только столкнется с
трудностями обучения, но и ощутит недостаток необычайно важных кулуарных зна-
ний, которые имеются в любом проекге. Тестеру будет недоставать также внутренних
знаний, касающихся проектных решений, неудачных экспериментов и навыков раз-
работчика, — всей той существенной информации, которая помогает изолировать
проблемные области.
Один из способов, с помощью которых можно получить такую информацию, — это
изучить людей, непосредственно работающих с проектом. Многие опытные разра-
ботчики получают удовольствие от хорошей работы и интуитивно понимают разницу
Сокращение числа тестовых примеров 261
между обязательными и необязательными тестовыми примерами. Очень часто от-
личным индикатором проблемных областей могут послужить интуиция и инстинк-
тивная реакция — это корректный способ заявить о невозможности прямого расчета
гыи измерения некоторых критериев. Естественные знания о продукте дают важное
интуитивное понимание еще не раскрытых проблем.
На результаты опроса могут повлиять политика компании и групповая динамика.
Встреча большой группы участников стимулирует умственную активность и приводит
к бурному обсуждению приложения. С другой стороны, некоторые люди могут не по-
желать давать искренние и честные ответы перед аудиторией, нуждаясь, таким обра-
зом, в обсуждениях один на один. Число собраний сохраняется, а число опрашивае-
мых людей изменяется в зависимости от числа участников или сложности проекта.
В этом разделе содержится список вопросов, которые позволяют изучить детали
внутренней структуры организации. Задача такой процедуры заключается в сле-
дующем.
• Выяснить, что волнует каждого члена команды.
• Установить потенциальные проблемы.
• Сконцентрировать усилия по тестированию на тех областях, которые вероят-
нее всего окажутся нестабильными.
Масштабы и терминология в проектах отличаются. Некоторые вопросы больше
подходят для проектов, заказанных для специфического конечного пользователя, в
то время как другие могут использоваться для программного обеспечения, выпускае-
мого серийно. Поскольку основная цель заключается в определении компонентов
приложения, которые сильнее всего нуждаются в тестировании, в вопросах использу-
ется общий термин модули. В зависимости от приложения модули могут относиться к
компоненту, функции, объекту, классу, подсистеме гиги другом}' типу элементов. Что-
бы точно отразить специфику данной организации, нужно просто модифицировать
вопросы.
В большинстве случаев один гиги несколько модулей могут служить общггми отве-
тами на многие вопросы. Нужно подсчитать число раз, когда функция была ответом.
Когда потенциально проблемные функции определены, тестер должен расставить в
этих областях приоритеты тестирования исходя из того, какие функции необходимо
оценить первыми. Такой подход помогает при сильных ограничениях во времени.
Если даже тестеру не хватит времени для проверки всех функций, то по крайней ме-
ре, наиболее трудные области будут протестированы прежде всего.
Сложности разработки
Часто оценку потенциально проблемных компонентов продукта наилучшим обра-
зом могут осуществить сами разработчики. Следует собрать членов команды разра-
ботчиков и задать им перечисленные ниже вопросы. (Несмотря на то, что этот под-
ход не гарантирует, что при тестировании будут найдены все проблемы, члены ко-
манды обычно соглашаются, чтобы наиболее вероятные проблемные области оцени-
вались за счет менее проблемных функций.)
262 Глава 8
Р-1 Имеется ли опыт использования новой технологии? Сочетались ли различ-
ные технологии? Если да, то в каких областях?
Использование любых новых технологий требует обучения. Новейшие
технологии иногда могут быть непроверенными или ошибочными.
Р-2 Вносились ли изменения в код, который уже был ошибочным? Если да, то в
какие модули?
У ошибок есть тенденция к накоплению. Изменения, вносимые в ошибоч-
ный код, вероятнее всего создадут новые проблемы или усугубят уже суще-
ствующие.
Р-3 Модифицировался ли код, изменявшийся ранее? Если да, то в каких моду-
лях?
Модифицируя код, написанный другим программистом, разработчик мо-
жет не до конца понимать нюансы, предусмотренные автором. Иногда воз-
никают побочные эффекты, о которых не все известно. Новый разработ-
чик может сделать неверные предположения по отношению к старому коду.
Р-4 Где раньше возникали сбои?
Тестер должен убедиться в том, что прошлые сбои были исправлены и что
они не проявятся иным путем.
Р-5 Какие модули обладают высокой сложностью?
Если код модуля выглядит свернутым, это, возможно, скрытая ошибка. Чем
больше ветвлений в блоке (подразумевается число условий IF и циклов
WHILE), тем больше потребуется тестов, чтобы проверить каждое условие
или ветвь. Мерой числа таких ветвей служит цикломатическая сложности
Многие инструменты тестирования позволяют оценить цикломатическую
сложность каждого модуля. В некоторых организациях степень сложности
функции ограничивается, поскольку функции с высокой сложностью имеют
тенденцию к возникновению неполадок Более детально о цикломатической
сложности можно узнать из работ [Beizer 90], [McCabe 82], [PressmanOl].
Р-6 Для каких функций требования были неполными или отсутствовали?
Как разработчик может сделать вывод, что модуль ведет себя нужным обра-
зом, если не вполне понятны основные функциональные возможности мо-
дуля? Это дает обширные возможности для интерпретаций и непредусмот-
ренных эффектов.
Р-7 Что было действительно сложно спроектировать и реализовать?
Иногда разработчику приходится потрудиться. В некоторых тестах данной
области нужно уделить внимание, поскольку у разработчика явно имеются
“мертвые зоны” и пропущенные функции. Разработчик мог сделать какие-
либо ошибочные предположения.
Кроме того, разработчику много помогали, так что любые существующие
проблемы, вероятнее всего, сложно будет обнаружить.
Сокращение числа тестовых примеров
263
Р-8 11 11 >1 Что быЛо просто спроектировать и реализовать? Разработчики могут считать некоторые задачи настолько очевидными и интуитивными, что избавляются от этой работы, не проводя адекватного проектирования и тестирования. Тестер не должен забывать об области только потому, что ее легко реализовать.
Р-9 Какие компоненты использовались повторно? Не все компоненты годятся для любых ситуаций. Повторно используемые компоненты в новой среде могут не дать всех необходимых функциональ- ных возможностей. Следует убедиться, что повторно используемые компо- ненты не вызывают нежелательных побочных эффектов.
Р-10 Изменялась ли архитектура? Если да, то какие модули были затронуты? Любые изменения при высокоуровневом проектировании могут повлиять на области действия низкоуровневых модулей.
Р-11 Есть ли “кандидаты” на “утечку памяти”? Многие приложения закрываются по причине истощения запасов памяти. Следует установить, есть ли такие модули, которые нужно проверить на предмет “съедания” памяти.
Р-12 Существуют ли неадекватные ресурсы, как, например, неадекватная ско- рость или память? Серьезным фактором может быть пропускная способность. Нужно устано- вить, какие типы временных тестов и тестов на размер данных подойдут.
Р-13 Изменялись ли аппаратные средства разработки? Некоторые платформы разработки диктуют такие требования, как специ- альные форматы данных, специальные адреса, интерфейс устройств, упа- ковку файлов. Если устройства SCSI перечислены в другом порядке, это может привести к проблемам с существующими функциями.
Р-14 Изменялась ли среда разработки? Использование различных операционных систем может повлиять на вызо- вы из библиотеки. Для компоновки программ понадобятся различные вер- сии файлов.
Р-15 Какие области влияют на целостность данных? Например, усовершенствование баз данных может привести к несоответст- вию данных или к потере всех данных.
Р-16 Есть ли такие тесты, которые, как чувствует разработчик, нужно будет вы- полнить? Разработчику необходимо задать вопрос, допускающий различные толко- вания, в таком виде, чтобы его основной смысл нельзя было свести к пре- дыдущему вопросу.
264
Глава 8
Сложности с заказчиком
Для многих компаний основную угрозу представляют неудовлетворенный клиент
и снижение продаж. То, что важно для клиента, не всегда оказывается в центре вни-
мания команды проектировщиков. Многие разработчики охотнее концентрируют
свою энергию на самых современных технологиях и захватывающих проблемах, иг-
норируя запросы клиента. Приоритеты тестирования должны быть ориентированы
на проблемы, которые наиболее неблагоприятно повлияют на конечного пользовате-
ля. Их можно установить, взяв входные данные у сотрудников из отделов продаж,
маркетинга, справки и отдела технической поддержки. Нужно определить, что ожи-
дал пользователь, когда впервые использовал продукт.
К1 На что жаловался клиент?
Даже если некоторые жалобы выглядят косметическими или тривиальны-
ми, они важны для конечного пользователя. Из-за мелких неприятностей
пользователь может скептически отнестись и ко всему продукту. В этой си-
туации восприятие пользователя оказывается очень весомым фактором.
К-2 Какие функции важны для клиента?
Нужно убедиться, что наиболее желательные для клиента функции рабо-
тают так, как было задумано.
К-3 Каковы приоритеты клиента?
Следует понять, как клиент планирует использовать приложение. Специ-
альные требования могут базироваться на таких проблемных для клиента
моментах, как перенос на специфические платформы, сопряжение с опре-
деленными приложениями, производительность или обработка специфи-
ческих форматов данных.
К-4 Какие возникли “накладки”? Приведет ли неудача с какими-либо функция-
ми к аннулированию сделки или задержке отгрузки?
Если продажи падают, компания потенциально может отойти от дел (тогда
вообще не будет продукта для тестирования, но ведь не в этом суть!). Пре-
жде всего следует обратиться к критичным для бизнеса проблемам, чтобы
убедиться, что соответствующие функции работают так, как ожидалось.
К-5 Что обещали отделы маркетинга и продаж клиенту?
Могут существовать недокументированные функции, которые были обе-
щаны клиенту'. Если приходится сталкиваться с какими-либо сильными из-
менениями в целях проекта, следует обсудить эту проблему с авторитетным
лицом проекта.
Сокращение числа тестовых примеров
265
Сложности управления
Менеджеры по тестированию пытаются обеспечить членов команды хорошими
требованиями, которые нужно удовлетворить в разумные сроки. Перечисленные ни-
же вопросы дают возможность исследовать влияние на проект проблем управления.
У-1 Где в календарном плане ощущалось особое напряжение?
Сжатые сроки и сверхурочные часы хорошо известны для тех, кто любит
“срезать углы”. Очевидные причины спешки в работе — плохое проектиро-
вание, недостаток пересмотров и неадекватное тестирование. Кроме того,
разработчик, работающий сверхурочно, из-за переутомления может при-
нять какие-либо неправильные решения. Нужно обратить внимание на та-
кие напряженные моменты в разработке.
У-2 Наблюдались ли какие-либо разногласия с высшим руководством? Если да,
то в чем?
Получали ли разработчики противоречащие сведения? Тестер должен про-
консультироваться с авторитетным лицом проекта и разобраться, какие ре-
альные цели стоят перед проектом.
У-3 Переориентировался ли проект? Для каких функций часто менялись требо-
вания?
Изменения в требованиях могут привести к серьезным изменениям в архи-
тектуре, пользовательском интерфейсе и других конструктивных элемен-
тах. Не всегда есть время на то, чтобы отбросить уже сделанную работу и
начать все заново. Модули, которые были модифицированы для реализа-
ции изменений, могут некорректно выполнять то, что нужно согласно но-
вым требованиям.
У-4 Для каких функций требования были непонятны?
Если неизвестно, какое поведение будет корректным, невозможно спроек-
тировать и модуль, который будет работать корректно. Разработчик может
сделать неверное предположение о поведении модуля.
Сложности с персоналом
Мастерство и профессиональный уровень сотрудников играют важную роль в соз-
дании качественного продукта. Большинство разработчиков стараются выполнять
незаурядную работу, но иногда бывают случаи, когда некоторые участки проекта ста-
новятся предметом огромного числа переделок. Вопросы к разработчикам могут по-
мочь вскрыть подобные проблемы. Некоторые их этих вопросов довольно деликат-
ные, так что важно создать подходящую обстановку для того, чтобы люди ответили на
них честно. Возможно, потребуется индивидуальный или даже письменный опрос,
чтобы обеспечить анонимность.
266 Глава 8
П-1 На каком этапе тестирования менялся персонал? Принимал ли разработчик
работу у другого разрабо тчика?
Некоторая жизненно важная информация содержится в голове у разработ-
чика, поскольку не все данные по проектированию документируются. Если
разработчик принимает чьи-то задачи (в результате штатных изменений
или из-за неожиданных проблем со здоровьем), разработчик, поставлен-
ный на замену, может не знать изначальных целей определенного подхода
и принятых решений. Следует выяснить, получил ли новый разработчик
достаточный объем информации и указания по уже выполненной работе.
П-2 Есть ли в проекте новые разработчики?
Даже если весьма уважаемый разработчик подключается к проекту, ему по-
надобится время, чтобы освоиться со специфической для приложения ин-
формацией. Если разработчик подключился в практической фазе проекта, у
него очень мало времени на то, чтобы ускорить темп своей работы до нуж-
ного уровня. Существует опасность, что разработчик сделает какие-либо
некорректные предположения о приложении.
С другой стороны, некоторые разработчики необычайно прилежны и
упорны в попытке понять все аспекты проекта. Такие сотрудники со всей
тщательностью проверят функционирование кода.
Данный вопрос не всегда может указывать на проблемную область.
П-8 Есть ли разработчики, чья работа была несовершенной, или наоборот, раз-
работчики высокого класса? На какие модули повлияла деятельность упо-
мянутых разработчиков?
Некоторые разработчики приобрели репутацию таких, кто не очень каче-
ственно делает свою работу; у других нет опыта работы с новыми техноло-
гическими задачами — как бы то ни было, их работа требует особого внима-
ния. Следует выяснить, тщательно ли были пересмотрены модули. Потен-
циальные проблемы анализирует и решает рецензент. Иногда для модулей
могут понадобиться дополнительные средства безопасности.
П4 Есть ли разработчики, которые отрицательно относятся к успеху продукта?
На какие модули повлияет деятельность таких разработчиков?
Время от времени в организации появляются сотрудники, которые по ка-
ким-либо причинам ничуть не заинтересованы в успехе проекта — они в ос-
новном лишь делают вид, что работают, перекладывают свою работу на
других, а иногда и открыто пренебрегают выполнением своих обязанно-
стей. Таких людей нужно отстранять от проекта прежде, чем они успеют
нанести серьезный вред. Излишне говорить, что это серьезный проектный
риск.
Сокращение числа тестовых примеров
267
П-5 Какая часть системы осталась непонятной для большинства членов коман-
ды?
Этот вопрос может показаться избыточным в свете вопроса П-4. Задавая
такой вопрос, можно либо получить подтверждение предыдущих ответов,
либо обнаружить новые проблемы, требующие внимания.
П-6 । Кто из разработчиков способствует успеху проекта?
Хотя этот вопрос не дает возможности установить проблемную область, он
никогда не помешает, так как позволяет обсудить позитивные моменты.
При опросе группы специалистов ведущим сотрудникам предоставляется
возможность получить одобрение со стороны равных себе. Опрос помогает
также установить специалистов, которые лучше других знакомы с проектом
и которые могут поделиться с тестерами дополнительной информацией.
Комбинированные схемы
Перечисление всех комбинаций входных данных в результате приводит к огром-
ному числу тестов. Например, тестирование графического приложения может заклю-
чаться в задании всех возможных графических образов со всеми доступными цвета-
ми, с примечаниями, сделанными всеми возможными шрифтами, запускаемого из
всех возможных состояний со всеми возможными... Этот бесконечный список пре-
вращается в задачу по вычислению всех возможных комбинаций. С позиции тестиро-
вания, тестирование каждого отдельного элемента в сочетании со всеми остальными
вариантами не всегда повышает доверие к продукту. Когда время сильно ограничено,
нельзя реализовать все перестановки. Следовательно, где-то тестер должен остано-
виться.
Для истинно модульных систем, в которых функции реализуются как независимые
элементы, тестирование значений, являющихся представителями каждого набора,
часто обеспечивает соответствующее доверие к продукту' в целом. В идеале, каждая
область тестируется изолированно, так как нужно убедиться, что работа в ней проис-
ходит должным образом. Следующий этап заключается в постепенном комбинирова-
нии отдельных частей и подтверждении того, что вместе они работают, как было за-
думано. Данная концепция не нова: это основа поэлементного тестирования, а также
тестирования взаимодействия и функционирования компонентов системы, описан-
ных в главе 9.
При оценке всего приложения для упрощения набора тестов можно воспользо-
ваться следующими вопросами.
1. Что оставить неизменным?
2. Какие комбинации маловероятны?
3. Какие комбинации наиболее вероятны?
4. Нужно ли тестировать каждую ситуацию в каждом режиме?
5. Можно ли тестировать какие-лз i6o функции, используя только одну конфигурацию?
268
Глава8
Выдвижение тестером предположений относительно приложения — эффективное
упражнение в анализе с целью найти компромиссное решение: какой аспект нужно
тестировать за счет того, что не будет протестировано.
Таблицы контрольных проверок или инвентарные перечни, введенные в главе 1,
помогают отслеживать протестированные функции приложения. Отслеживание за-
ключается в перечислении всех типов состояний с последующим подтверждением то-
го, что в ходе выполнения теста все события были реализованы по крайней мере
один раз. Если тестирование всех элементов в таблице контрольных проверок невоз-
можно, необходимо провести анализ степени риска или опросы, чтобы убедиться,
что тестируются критические функции.
Каждому выдвинутому предположению должно быть дано разумное обоснование.
Важнее всего объяснить, какие условия не будут тестироваться и документировать обос-
нования. Для этого необходимо, во-первых, известить авторитетное лицо и команду
разработчиков о том, какие функции не будут тестироваться и, во-вторых, составить
письменное доказательство на случай, если будут выдвинугы обвинения в пренебре-
жении специфическими функциями. Независимо от того, какие функции будут про-
пускаться при выполнении тестов, нужно получить на это согласие со стороны авто-
ритетного лица проекта.
Далее представлен пример схемы упрощения тестов вместе с ее оправданием для
воображаемого приложения обработки изображений (пример с образцом, обрабаты-
вающим изображения, описан в главе 5). Авторитетное лицо проекта задает возмож-
ности системы; на рис. 8.5 представлено краткое изложение этих требований.
В этом простом примере имеется потенциал для создания огромного количества
тестовых примеров. Можно рассмотреть следующие комбинации.
• Всего приложение поддерживает 14 753 281 различных размеров изображения,
т.е. (4096 - 256+I)2.
• Чтобы испробовать каждый из 8 алгоритмов изображения, для каждого разме-
ра потребуется (8 х 14 753 281) или 118 026 248 тестов.
Естественно, применение разбиения на классы эквивалентности или других оце-
нок на основе риска поможет уменьшить число выполняемых тестов. В этом случае
нужно проконсультироваться с авторитетным лицом проекта и установить, какие
функции клиент вероятнее всего будет использовать. Реальная проблема состоит в
том, чтобы выяснить, какие функции требуются для системы, а какие — для пользова-
теля. Может оказаться, что отдельные нужды пользователя в действительности огра-
ничивают поднабор возможностей системы в целом. В любом случае авторитетному
лицу проекта следует каким-то образом охарактеризовать типичного пользователя.
Предположим, что на рис. 8.6 описываются основные действия пользователя.
Анализ работы для одного типичного клиента дает возможность уменьшить число
размеров изображений с 14 753 281 до 3. Хотя по-прежнему нужно проверить все ал-
горитмы обработки изображений, число тестов радикально снижается Выходное
разрешение монитора 1280 х 1024 также ограничивает размер изображения, которое
можно отобразить.
Сокращение числа тестовых примеров 269
Требования к приложению по обработке изображений Размер обрабатываемых изображений: [256..4096]х[256 .4096] 256x256 — это минимальный размер изображения. Меньший размер изо бражения не позволяет реализовать ключевые функции. 4096x4096 - максимальный размер изображения. Все изображения неквадратного размера, которые находятся в рамках этого диапазона, также обрабатываются. Режимы ввода изображений: Захват изображений камерой: возможность захвата с помощью моделей камер ACME-12, FotoXP и PictureThis. Чтение из памяти: возможность загрузки изображений в память и передачи изображения приложению. Алгоритмы обработки приложений, реализуемые в этой версии: Алгоритмы генерации выходного изображения: Инвертирование Поворот на 60° Поворот на 90° Отражение по горизонтали Отражение по вертикали Замена красного цвета на синий Алгоритмы генерации числовых данных: Расчет области Нахождение центра Режимы вывода изображений: для алгоритмов, формирующих выходное изображение Передача на дисплей: изображение показывается на мониторе с разрешением 1280x1024. Сохранение в памяти: данные изображения сохраняются в памяти для записи в файл изображения. Режим выдачи данных: для алгоритмов, генерирующих числовые данные Входные данные появляются во всплывающем окне и одновременно записываются в журнал.
Рис. 8.5. Краткое изложение требований для примера приложения по обработке изображений
270
Глава 8
Основные действия пользователя
Даже если приложение разрабатывается для работы со всеми изображениями
между 256x256 и 4096x4096, тестирование будет сосредоточено на трех фор-
матах видеоинформации и использовании камеры FotoXP. Таким образом, для
получения, обработки и вывода изображений будут протестированы изображе-
ния размером 640x480, 800x600,1024x768.
К другим причинам, по которым размер изображений ограничивается, относятся:
1. Переконфигурирование системы для работы с разными размерами
изображений требует много времени. Тестер должен отредактировать
конфигурационный файл и заново инициализировать систему.
2. В течение двух лет, когда заказчик работал с данной системой,
пользователь использовал только три из перечисленных выше размера
изображений.
Следующая версия приложения должна также учитывать нового заказчика, чье
оборудование требует поддержки изображений размером 256x512 и 512x512.
Получение, обработка и вывод изображений такого размера должны быть про-
тестированы к дате, которая будет известна позднее.
Рис. 8.6. Схема упрощения стратегии тестирования
Цель данного подхода — подтвердить, что система работает с типичным пользова-
тельским сценарием, а не проводить далекие тесты, в которых предпринимается по-
пытка вскрыть недостатки в системе. Как и в случае со всеми схемами упрощения,
описанными в этой главе, выбранный набор тестов утверждает авторитетное лицо
проекта.
Отслеживание выбранных тестовых
примеров
Существует множество форматов отслеживания тестовых примеров. Некоторые
методы могут быть настолько неформальными, что соответствующий им список тес-
тов снабжается комментариями, в то время как в других методах отслеживания тестов
применяются электронные таблицы. Независимо от используемого метода тестер
должен быть в состоянии определить, какие тесты выполняются, а также установить
их результаты.
Матрица прослеживаемости требований
В схеме выяснения приоритетов, представленной в этой главе, часто перечисля-
ются тестируемые функции, а не тестовые примеры. Тестер должен установить, какие
тестовые примеры соответствуют заданным функциям. Этой цели можно достичь с
помощью матрицы прослеживаемости требований, в которой отображаются требо-
вания к тестовым примерам и которая решает следующие вопросы:
Сокращение числа тестовых примеров
271
• какие тестовые примеры выполняют специфические функции;
• какие требования не соответствуют тестовым примерам;
• какие функции по-прежнему нужно тестировать;
• на какие тестовые примеры влияют изменения в требованиях.
В табл. 8.2 показана часть матрицы прослеживаемости (функции приложения пе-
речисляются в заглавной строке, а тестовые примеры — в заглавном столбце). Для ка-
ждой тестируемой функции должна быть по крайней мере одна контрольная метка,
соответствующая тестовому примеру. Это подразумевает, что для реализации данных
условий существует как минимум один тест. В этом примере две выделенные строки
указывают, что функции 3 и 8 имеют более высокий приоритет. Согласно матрице
прослеживаемости, представленной ниже, при запуске тестового примера ТП8 будет
тестироваться функция 3. Однако для выполнения функции 8 не существует тестовых
примеров, так что понадобится создать новый тестовый пример.
Таблица 8.2. Матрица прослеживаемости
ТП1 рТ12| \ ¥ТПЗ^ ;йгп4., .^П5Г ТП6 ТП7 ТП8 ТП9
функция 1
функция 2
функция 3
функция 4
функция 5
функция 6
функция 7
функция 8
функция 9
функция 10
Матрица риска и тестовых примеров
Модификация матрицы риска путем включения в нее столбца с идентификаторами
тестовых примеров помогает отобразить связь каждого установленного риска с тес-
товым примером. Табл. 8.3 представляет собой расширение табл. 8.1. Дополнитель-
ный столбец содержит ссылки на тестовые примеры, которые должен выполнить
тестер.
272 Глава 8
Таблица 8.3. Карта рисков и тестовых примеров
Псбс П<^генциальная‘*«Я^ •' проблема Вероятность появления . ^Серьезнбстъ влияния, ьРискУ Тестовый ' пример
А Потеря мощности 1 10 10 ТП-77
В Искаженный заголовок файла 2 1 2 ТП-81 ТП-83
С Неавторизованный пользователь получил доступ 6 8 48 ТП-102 ТП-119
D Базы данных не синхронизированы 3 5 15 ТП-30
Е Неясная пользовательская документация 9 1 9 ТЛ-31
F Снижение продаж 1 8 8 ТП-41
G Низкая пропускная способность 5 3 15 ТП-110
Другой способ отображения риска на тестовые примеры заключается в использо-
вании таблицы прослеживаемости, аналогичной табл. 8.2, за исключением того, что
список функций заменяется на список рисков.
Сокращенное документирование тестов
Многие сокращения в документации позволяют отслеживать выполняемые тесто-
вые примеры. Самый простой метод — снабжение комментариями существующих до-
кументов по тестированию (будь то схема, матрица, таблица тестов или таблица со-
держимого теста) с помощью разноцветных ручек или кода приоритетов. В главе 6
содержится пример, где в схеме устанавливаются тесты с высоким приоритетом. Еще
один способ сокращения документации заключается в том, что в существующие таб-
лицы тестов добавляются столбцы для ввода приоритет ов тестов и результатов их
выполнения.
Резюме
Кроме всего прочего, тестеры отвечают за сокращение большого набора тестовых
примеров и выбор тестов, выполнение которых наиболее важно. В первую очередь
тестер ограничивает число тестовых примеров, применяя разбиение на классы экви-
валентности или тестирование ортогональных массивов, чтобы определит ь тесты, в
которых задействуются одни и те же функции. После того как тестовые примеры бы-
ли заданы и даже созданы, ограничить число выполняемых тестов помогает схема
расстановки приоритетов. Критерий выбора изменяется в соответствии с проектом,
хотя большинство из них могут основываться на таких факторах, как:
Сокращение числа тестовых примеров
273
• нужды клиента;
• серьезность сбоя;
• вероятность сбоя;
• среда разработки;
• сложности управления.
Присвоение кодов приоритета для каждого теста разбивает тесты на категории
высокого, среднего и низкого приоритетов. Это помогает отделить более срочные
~есты от тех, которые можно отложить.
При анализе степени риска (формальном подходе для систем программного обес-
печения, критичных к безопасности) распределение проблем выполняется на основе
статистических данных. Однако концепции анализа степени риска без труда приме-
нялся к новым проектам путем привлечения понятий серьезности и вероятности
'боев. По значениям этих величин можно определить степень риска, который харак-
теризует наиболее серьезные сбои. Значения вероятности и серьезности сбоя также
_тужат данными, которые используются в матрице риска. Разбиение этой матрицы
распределяет проблемы по классам приоритетности.
Опрос разных членов команды проекта помогает выделить модули, в которых мо-
•vr содержаться недостатки. Критерий оценки опирается на среду разработки, при-
-ритеты клиентов, сложности управления и трудности с персоналом.
Тестеры часто должны делать предположения относительно того, какие конфи-
гурации или комбинации данных вероятнее всего будут использоваться, и выпол-
нять тесты для наиболее распространенных сценариев, избегая менее вероятных
итуаций.
Очевидно, что перечисленные в этой главе подходы могут привести к различным
эезультатам, однако перекрытие, наборы тестовых примеров, основные цели — все
это служит для поддержки взаимодействия между членами команды проекта и помо-
гает находить компромиссы при откладывании каких-либо тестов.
ГЛАВА
Создание качественного ПО
Введение
В книге сделан акцент на задании тестовых примеров, однако это лишь один из ас-
ектов тестирования ПО. В данной главе вкратце будут рассмотрены другие задачи
“естирования ПО и вопросы разработки ПО, которые способствуют повышению ка-
чества продукта. Разработка ПО имеет множество аспектов, каждый из которых пред-
тавляет собой отдельную дисциплину и требует рассмотрения отдельных процессов.
В работах [PfleegerOl] и [Pressman 01] всестороннее обсуждаются концепции разра-
ботки ПО.
Инфраструктура среды разработки
Дисциплины разработки ПО, представленные в этом разделе, — чрезвычайно су-
щественные компоненты успешной разработки и тестирования ПО, поскольку они
хватывают весь проект в целом. Данный раздел раскрывает важность каждой их этих
дисциплин для эффективного тестирования ПО.
Требования
Хорошие требования укрепляют общее взаимопонимание между клиентом (пред-
гтавителем клиента) и разработчиками ПО. В требованиях описываются возможно-
сти системы с позиции пользователя. Они также служат основой для проектирования,
з котором описывается способ удовлетворения данных требований системой. Сис-
-емные требования касаются внутреннего интерфейса, проектных ограничений
масштабов проекта) и вопросов технических характеристик, таких как точность и
гыбор времени.
Успешным проектом считается тот, который удовлетворяет требованиям. Хоро-
шие требования проверяемы и недвусмысленны, — это подразумевает, что для каждо-
~о требования можно записать один или несколько тестовых примеров.
276
Глава 9
Существенные моменты в тестировании ПО
Требования — это основа, по отношению к которой оценивается конечный про-
дукт. При тестировании ПО требования необходимы, чтобы убедиться в том, что был
создан правильный продукт. Требования используются для задания тестовых приме-
ров путем определения входных и выходных условий и создания сценариев типа “что
если...?”. На ранней стадии проекта пересмотр требований помогает установить, яв-
ляются ли они адекватным и корректным отображением того, что нужно клиенту. Ко-
гда требования недостаточны или отсутствуют, на тестера ложится бремя по сбору
достаточного количества информации о приложении, чтобы можно было создать
тестовые примеры.
Дополнительные сведения
В стандартах IEEE [IEEE 830] и [IEEE 1233] описывается то, как составлять тре-
бования и приводить примеры. Есть и другие работы, в которых анализируются
требования: [Gause 89], [Hamlet 01], [Wiegers99]; в работе [Robertson 99] обсуж-
даются методы тестирования требований.
Проектный менеджмент
Проектный менеджмент — это дисциплина, которая изучает управление календар-
ными планами и ресурсами. Для успеха проектов нужна соответствующая организа-
ция деятельности и возможность постоянно оценивать и сообщать о состоянии дел.
Проектный менеджмент разработки ПО состоит из двух областей: планирования и
отслеживания проекта.
В ходе планирования проекта по разработке ПО составляется разумный план осу-
ществления разработки ПО и управления проектом ПО. Чтобы составить эффектив-
ный план проекта, необходимо:
• задать цель проекта;
• задать стратегию разработки;
• указать выполняемую работу;
• указать риски и планы их уменьшения;
• указать необходимые ресурсы;
• назначить ресурсы;
• указать компоненты продукта;
• разбить проект на небольшие, поддающиеся определению задачи;
• задать календарный план;
• установить критичные пути;
• указать, каких стандартов нужно придерживаться.
При отслеживании проекта по разработке ПО обеспечивается адекватное отраже-
ние реального состояния дел, таким образом руководство может принимать активное
Создание качественного ПО
277
участие в ситуациях, когда характеристики проекта значительно отклоняются от за-
планированных показателей. К основным видам деятельности по отслеживанию про-
екта относятся:
• • использование основных и второстепенных контрольных точек для отслежи-
вания хода работ;
• обнаружение потенциальных проблем;
• реализация плана восстановления (как избавиться от проблемы, когда что-то
идет не так).
По завершении проекта сравнение реальной продолжительности задачи с запла-
нированной помогает установить точность оценок. Изучение истории предыдущих
планов и учебных курсов повышает возможности планирования в будущем.
Существенные моменты в тестировании ПО
Тестирование ПО состоит из многих фаз и осуществляется параллельно с другими
задачами разработки ПО. В хорошем плане проекта учитывается множество задач
тестирования ПО, а также объем работы (включая планирование, проектирование
тестов, создание среды тестирования, выполнение тестов и другие задачи тестирова-
ния), который может составить половину календарного плана. Во многих насыщен-
ных проектах сроки выполнения тестов очень сжаты из-за сокращения графика раз-
работки. Хороший проектный менеджмент учитывает такие узкие места и календар-
ный план соответственно изменяется.
Дополнительные сведения
Дополнительную информацию о проектном менеджменте можно найти в работах
[IEEE1058], [Humphrey 89], [McConnell98] и [Boehm 81], где представлены приме-
ры схем планирования проектов.
Конфигурационный менеджмент в разработке ПО
Конфигурационный менеджмент разработки ПО (Software Configuration Manage-
ment — SCM) позволяет контролировать сложную среду разработки ПО и сохранять
целостность компонентов по мере того, как они изменяются в течение жизненного
цикла разработки. SCM позволяет отслеживать исходный код, документы, содержа-
щие требования, проектную документацию, тестовые примеры, руководства пользо-
вателей и многие другие артефакты, которые составляют часть проекта.
Виды деятельности SCM поддерживаются многими коммерческими инструмента-
ми. К ним относятся:
• координирование работы множества людей;
• предоставление средств для выяснения состояния продукта;
• поддержка множественных и параллельных потоков разработки;
• получение контрольного следа изменений.
278
Глава 9
SCM предполагает следующие виды деятельности.
Управление версиями позволяет сохранять историю каждой компоненты по мере то-
го как она изменяется со временем, таким образом всегда можно получить доступ к
предыдущему состоянию компоненты. Основной механизм заключается в контроле
регистрации и проверке каждой компоненты.
Управление конфигурацией состоит в отслеживании всех компонентов, необходимых
для конструирования отдельной версии системы, включая документы и специфика-
цию тестов. Эта часть SCM позволяет также отслеживать зависимости между файлами
с исходным кодом. В некоторых организациях необходимо также отслеживать все ин-
струменты (компиляторы, редакторы связей, инструмёнты для групповых операций и
другие бинарные файлы), которые необходимы для создания каждой версии системы.
Управление внесением изменений— это процесс, в ходе которого инициируется, ут-
верждается и наблюдается ход изменений, будь то усовершенствования или устране-
ние дефектов.
Управление выпусками— заключительный этап работы приложения. Это автомати-
зированный процесс выпуска (например, создание утилит), в котором точно извест-
но, что на каком уровне системы содержится. Чтобы уменьшить время выпуска, при
эффективном построении перестраиваются только те компоненты, которые нужда-
ются в перестройке. Процесс управления выпуском дает, во-первых, результирующее
выполняемое приложение и, во-вторых, ассоциированный список материалов. В спи-
ске материалов перечисляются все компоненты и соответствующие версии, исполь-
зуемые для создания выполняемого приложения.
Менеджмент процессов позволяет оценить виды деятельности по разработке ПО пу-
тем отслеживания развития компонентов по фазам жизненного цикла разработки.
Например, процесс может потребовать, чтобы компонент прошел тестирование пе-
ред выпуском. Менеджмент процессов также позволяет убедиться перед модифика-
цией кода, проекта и других документов, что имеются подходящие запросы на внесе-
ние изменений (и что они одобрены).
Существенные моменты в тестировании ПО
Помещая каждый артефакт под управление конфигурацией, тестер может легко
создать среду для любой версии продукта. Возникает множество проблем, когда по
неосмотрительности используются неверные версии объектов. Чаще всего это про-
исходит тогда, когда конфигурационный менеджмент осуществляется вручную или
когда специалисты, которые администрируют систему, неадекватно подготовлены.
Для эффективной работы тестеру необходимо знать правильную конфигурацию тес-
тируемой системы. Конфигурационный менеджмент также позволяет тестеру отсле-
живать множество сценариев и других файлов, относящихся к тестированию.
Проблемы, найденные при тестировании, обычно требуют внесения изменений в
код, что в результате приводит к новой версии продукта. Отслеживание версий тесто-
вых примеров и версий продукта как части описания проблем позволяет избежать
неразберихи.
Отсутствие управления конфигурациями обычно приводит к тому, что:
Создание качественного ПО
279
• проблемы, устраненные ранее, внезапно появляются снова в новых версиях
продукта;
• изменения, внесенные в предыдущие версии, не сохраняются;
• специальные функции или файлы отсутствуют при выпуске продукта.
Дополнительные сведения
Детально конфигурационный менеджмент описывается в работах [Buckley 96],
[Humphrey 89], [Leon 00], [Mikkelson 97] и [Pressman 01]. В [IEEE 828] собраны стан-
дарты IEEE, касающиеся конфигурационного менеджмента ПО.
Обеспечение качества ПО
Обеспечение качества ПО (Software Quality Assurance — SQA) осуществляет на-
глядное управление процессами, которые используются в проектах по разработке
ПО и создаваемых продуктах [Paulk 93]. Обеспечение качества включает виды дея-
тельности, спроектированные для оценки процессов, продукты которых разраба-
тываются или производятся [IEEE 610.12]. Цель SQA — создать высококачественное
ПО, т.е. подтвердить, что при разработке продуктов используются правильные инст-
рументы, процедуры и методы, а также предотвратить дефекты или обнаружить и
устранить их на ранней стадии, что позволит избежать повторных переделок.
В течение всего цикла разработки используются такие виды деятельности SQA:
• задание плана качества;
• проведение пересмотра ПО;
• подтверждение того, что существуют методы внесения контролируемых изме-
нений в документы и исходный код;
• аудит программных продуктов на предмет соответствия стандартам;
• сбор метрик качества ПО;
• оценка методов разработки и тестирования ПО.
Одна из функций SQA— проведение аудитов. Аудит — это независимая оценка ар-
тефактов проекта, первоочередная задача которой состоит в проверке соответствия
разработки продукта угвержденным стандартам и нормам. Аудиты могут быть внут-
ренними (аудиторы компании) и внешними (аудиторы из организаций по стандартам,
от которых компания получает аккредитацию, или сами клиенты в случае, если разра-
батываемое ПО — компонента собственного продукта клиента).
Существенные моменты в тестировании ПО
Некоторые компании ошибочно приравнивают SQA к тестированию ПО. В SQA
оценивается качество процесса, причем основное внимание уделяется предотвраще-
нию дефектов, что противоположно задаче тестирования ПО, в котором оценивается
качество продукта и основное внимание уделяется обнаружению ошибок. В SQA ве-
дется наблюдение за эффективностью тестирования путем пересмотра результатов
280
Глава 9
тестов и сбора метрик качества ПО. Аудит документов по тестированию ПО дает воз-
можность удостовериться, что процесс тестирования соответствует установленным
стандартам и нормам.
Дополнительные сведения
Виды деятельности SQA детально рассматриваются в публикациях [Humphrey 89]
и [Pressman 01]. В работе [IEEE730] описано содержание плана обеспечения качест-
ва ПО, а в [IEEE 1028] изложены процедуры для проведения аудитов.
Пересмотры и аудиты
Пересмотры — один из наиболее эффективных путей уменьшения числа ошибок и
повышения качества продукта. Задача пересмотров заключается в том, чтобы осоз-
нать и устранить дефекты на ранней стадии разработки, т.е. перед написанием кода,
пересматривая все артефакты по мере их создания. Сюда входят требования, проек-
ты, код, тестовые примеры и любые другие документы, имеющие отношение к проекту.
Пересмотр и. аудит рабочих продуктов, созданных на каждом этапе разработки,
помогают установить дефекты как можно раньше и, следовательно, предотвратить их
распространение на другие этапы разработки. Согласно [Boehm 81], наибольшей
окупаемостью обладает проверка требований и документов проектирования, по-
скольку стоимость устранения дефектов значительно возрастает, если они обнаруже-
ны позже. Существуют различные типы пересмотров. К ним относятся:
Технические пересмотры, которые являются типичными обсуждениями в однород-
ной группе; их цель — прокомментировать или утвердить рабочий продукт.
Ознакомления часто проводятся при содействии конструктора, который помогает
остальным специалистам разобраться с документацией или написанным кодом. Озна-
комление играет роль тренировочного инструмента, с помощью которого можно изу-
чить конкретный продукт.
Аудиты ПО— это наиболее строгий тип пересмотра. Они следуют формально
структурированным процессам, к которым относятся:
• использование таблицы контрольных проверок для повышения эффективно-
сти пересмотров;
• назначение специфических ролей участникам;
• сравнение рассматриваемых элементов со стандартами;
• проведение дополнительных аудитов;
• составление отчета по аудитам;
• хранение записей для описания слабых мест (как в самом продукте, так и в про-
цессе разработки);
• составление статистики для измерения эффективности процесса аудита.
Создание качественного ПО
281
Существенные моменты в тестировании ПО
Аудиты — это метод тест ирования документов, будь то требование, проект или дру-
гой тип документации. Эти документы становятся источником для задания тестовых
примеров. Документы по тестированию не застрахованы от ошибок, так что они так-
же получают пользу от аудитов.
При пересмотре проблемы обнаруживаются раньше, чем при тестировании кода,
поскольку документы составляются еще до того, как разрабатывается исходный код.
Важно обнаружить дефекты при пересмотре, поскольку дефекты, найденные при тес-
тировании, не несут информации о своем местоположении в исходном коде, который
требует модификации. При тестировании обнаруживаются дефекты, которые либо
были внесены после аудита, либо были пропущены в ходе самого аудита.
Дополнительные сведения
Формальные аудиты основываются на работе Майкла Фэгена (Michael Fagan),
[Fagan 86]. В [IEEE 1028] заданы процедуры проведения пересмотров. В работе
[Gilb 93] представлено детальное описание процесса аудита и содержатся примеры,
взятые из реальных проектов. В публикациях [Humphrey 89] и [Kit. 95] представлена
таблица контрольных проверок для аудита. В работу [Freedman 90] включена таблица
контрольных проверок для пересмотра тестовых примеров. В работе [Marick 95] со-
держится таблица контрольных проверок для аудитов кода.
Среда тестирования ПО
Создание среды тестирования ПО — задача нетривиальная. Даже некоторые тес-
ты, выполняемые вручную, требуют наличия специальных интерфейсов для обмена
информацией с приложением. Драйвер — это программная утилита, которая отправ-
ляет входные данные тестируемому приложению. Тот же драйвер или другая утилита
может затем собрать результирующие выходные данные. Для автоматизированных
тестов требуется, чтобы тестер запрограммировал тестовые примеры в приемлемой
для машины форме в виде сценария. Автоматическая среда тест ирования отправляет
сценарии тестируемому приложению, а затем собирает и оценивает исходы.
Дополнительными факторами, которые рассматриваются при настройке среды
тестирования, выступают аппаратное обеспечение, операционная система и сторон-
ние утилиты (последние представляют собой ПО поставщиков, которое используется
тестируемым приложением, но не упаковано или не установлено вместе с приложе-
нием).
Каждой фазе разработки ПО сопутствует параллельный процесс тестирования,
как показано на рис. 9.1. Тестер создает тестовые примеры на основе документов, по-
лученных на каждом этапе разработки.
282
Глава 9
• Документы, содержащие требования, обеспечивают входные данные, чтобы
задать тестовые примеры для системы, а также для управления фазой проекти-
рования.
• Фаза проектирования заключается в постепенной детализации проекта. Каж-
дый уровень проекта задает часть системы и, следовательно, требует комплекс-
ного тестирования, чтобы тестер мог убедиться, что каждый компонент рабо-
тает как наращиваемый элемент.
• В фазе элементов задаются спецификации и, в конечном счете, код для каждого
элемента. Спецификации элементов используются для задания поэлементных
тестов.
Рис. 9.1. Взаимосвязь между фазами разработки и уровнями тестирования ПО
Когда становится доступным необходимое ПО, проводятся тесты. Каждый из этих
различных уровней тестирования требует наличия соответствующей среды, в кото-
рой будут выполняться тесты. Это может быть как одна и та же, так и совершенно
различные среды в зависимости от определения тестером стратегии тестирования.
Создание качественного ПО
283
Поэлементное тестирование
Элемент — это наименьший компонент, который можно скомпилировать. Поэле-
ментное тестирование заключается в изолированной проверке каждого отдельного
элемента путем запуска тестов в искусственной среде. Для этого необходимо исполь-
зовать драйверы и заглушки. Драйверы — это модули тестов, которые запускают тес-
тируемый элемент. Заглушки заменяют недостающие компоненты, которые вызыва-
ются элементом и выполняют следующие действия:
• возвращаются к элементу, не выполняя никаких других действий;
• отображают трассировочное сообщение и иногда предлагают тестеру продол-
жить тестирование;
• возвращают постоянное значение или предлагают тестеру самому ввести воз-
вращаемое значение;
• осуществляют упрощенную реализацию недостающей компоненты;
• имитируют исключительные или аварийные условия.
Многие специалисты разделяют поэлементное тестирование на два типа:
“прозрачного” и “черного ящика”. Тестер использует внутреннюю структуру кода и
управляющую логику для конструирования тестов методом “прозрачного ящика”. Тес-
ты, созданные методом “черного ящика”, получаются из требований и других специ-
фикаций, причем тестеру необязательно знать внутреннюю структуру приложения и
управляющих элементов. Таким образом, “прозрачный ящик” базируется на структуре
кода, в то время как основа “черного ящика” — функциональные возможности и пове-
денческая модель. “Черный” и “прозрачный ящики” — это методы проектирования
тестовых примеров; каждый из них позволяет сгенерировать набор входных и вы-
ходных условий.
Несмотря на то, что метод “прозрачного ящика” все-таки позволяет находить де-
фекты (основываясь на внутренней структуре), существует опасность, что код будет
проверяться так, как он написан, а это не гарантирует корректности логики. С помо-
щью метода “черного ящика” приложение тестируется исходя из требований, при
этом подтверждается тот факт, что специфические входные данные приводят к ожи-
даемому корректному исходу. Борис Бейзер (Boris Beizer, World of Testing) на 5-дневном
семинаре в 1995 году одним из эффективных подходов к поэлементному тестирова-
нию назвал разработку тестов при помощи описания поведения элементов и анализа
покрытия (для подтверждения того, что тесты удовлетворяют желаемому критерию
покрытия, будь то 100%-ное покрытие ветвей, 100%-ное покрытие условий или по-
крытие любого другого типа).
Предыдущие главы были ориентированы на конструирование тестовых примеров
на основе задуманного поведения приложения. Следовательно, эти тесты относятся к
тестовым методам “черного ящика”. Например, в главе 5 для оценки эффективности
тестов используется исходный код, но он НЕ используется для конструирования тес-
товых примеров.
284 Глава 9
Существенные моменты, касающиеся качества ПО
Поэлементное тестирование — это первейшая возможность реализовать исходный
код. Оценивая каждый элемент изолированно и подтверждая корректность его рабо-
ты, точно установить проблему значительно проще, чем если бы элемент был частью
большой системы.
Дополнительные сведения
Работа [IEEE 1008] — это стандарт IEEE для поэлементного тестирования ПО. Стра-
тегии разработки тестов (как для метода “прозрачного”, так и для метода “черного ящи-
ка”), представлены в работах [Beizer84], [Beizer95], [Kaner99], [Myers76], и [Myers 79].
В британском стандарте BS7925-2 описаны методы “прозрачного” и “черного ящика” для
покомпонентного (поэлементного) тестирования.
Тестирование сборки
Стратегия сборки ПО задает порядок, в котором объединяются отдельные эле-
менты. Сборка — это процесс, который начинается с индивидуального тестирования в
изолированных условиях каждого элемента набора и заканчивается тогда, когда соз-
дается все приложение в целом. При тестировании сборки проверятеся корректность
функционирования скомбинированных вместе элементов. Это может упростить об-
наружение ошибок, которые встречаются в интерфейсе или при передаче данных
между отдельными элементами. В таком случае корень проблемы найти гораздо про-
ще, поскольку (по крайней мере, теоретически) заново добавленный компонент сразу
становится подозреваемым.
Существует четыре стратегии сборки, каждая со своими преимуществами и недос-
татками. Термины верхний и нижний относятся к расположению элементов в схеме
вызываемых функций приложения или структурной схеме.
Снизу вверх. Тесты и элементы объединяются снизу вверх. Следует сначала выпол-
нить поэлементное тестирование для компонентов, находящихся на более низком
уровне, а затем перейти к высокоуровневым компонентам. Для такого метода необхо-
димо использовать драйверы, чтобы вызывать тестируемые элементы.
Сверху вниз. Высокоуровневые подпрограммы становятся драйверами для осталь-
ных элементов. В этом методе используются заглушки, имитирующие поведение низ-
коуровневых элементов.
Сэндвич. Здесь комбинируются методы сверху вниз и снизу вверх, чтобы в конечном
счете прийти к полностью интегрируемой системе.
Большой взрыв. Объединяются все элементы. Хотя для этого метода не требуются
ни заглушки, ни драйверы, с его помощью значительно сложнее установить ошибки в
интерфейсе.
Создание качественного ПО
285
Существенные моменты, касающиеся качества ПО
Компоновка ПО и ее тестирование обычно связаны между собой. По мере добав-
ления новых компонентов к наращиваемой системе тестер проверяет, чтобы проме-
жуточные конфигурации работали так, как предполагалось.
Дополнительные сведения
Дополнительное обсуждение стратегий сборки можно найти в работах [Beizer 84],
[Beizer 90]. [Binder 00], [Hetzel 88] и [Myers 76].
Тестирование системы
При тестировании системы проверяется продукт в целом. После того как все про-
граммные и аппаратные компоненты собраны, подтверждается соответствие продук-
та исходным требованиям проекта. При наличии полностью скомпонованной систе-
мы тестер может оценить многие атрибуты, которые нельзя оценить на более низких
уровнях тестирования. К основным категориям тестирования системы относятся:
Тестирование на совместимость. Оценивается то, насколько хорошо ПО функцио-
нирует в определенной среде, задаваемой специфическими версиями аппаратного
обеспечения, ПО, операционной системы, сети и т.д.
Конфигурационное тестирование. Используются различные программные и аппарат-
ные конфигурации (например, разнообразные периферийные устройства, если они
нужны), которые должна поддерживать система.
Тестирование функциональных возможностей. Проверяется, чтобы каждая функция
отвечала требованиям.
Тестирование установки. Проверяется, чтобы полная, частичная или обновляемая
процедура установки работала согласно документации; тестируется также процесс де-
монтажа.
Тестирование загрузки. Система за короткий период времени подвергается типич-
ному воздействию со стороны пользователя; задача заключается в моделировании ре-
альных действий. Другое определение — это тестирование приложения в диапазоне
его задач для того, чтобы узнать, в какой точке время ответа системы ухудшится или
произойдет сбой.
Тестирование характеристик. Для того чтобы убедиться, что система дает ответ в
заданных рамках, тестер измеряет время выполнения каждой задачи в пиковых и
нормальных условиях.
Тестирование восстановления. Тестер проверяет способность системы к восстанов-
лению до пригодного для эксплуатации состояния после того, как возникла аварийная
ситуация, произошел сбой в аппаратном обеспечении или были обнаружены анало-
гичные проблемы, связанные с повреждением.
Тестирование надежности. Проверяется работа системы при установленных услови-
ях для заданного временного периода.
Тестирование на безопасность. Проверяется, чтобы доступ к разрешенным функциям
могли иметь только авторизованные пользователи.
Тестирование удобства обслуживания. Подтверждается, что любая информация по
внутреннему техническому обслуживанию (например, трассировочные и диагности-
ческие сообщения) соответствует документации.
Тестирование под нагрузкой. Систему вынуждают работать в неразумных условиях за-
груженности, отказываясь от ресурсов, необходимых для таких задач [Борис Бейзер,
World of Testing]. Задача заключается в том, чтобы вывести систему за пределы, задан-
ные в требованиях, для выявления потенциальных вредных ошибок.
Тестирование практичности. Оценивается “дружелюбие к пользователю” приложе-
ния и устанавливаются те операции, которые могут оказаться сложными для пользо-
вателей. Сюда входит проверка руководств и других публикаций, предназначенных
для пользователя.
Существенные моменты, касающиеся качества ПО
Оценивая полностью скомпонованную систему в сравнении с исходными требова-
ниями, тестер определяет, функционирует ли окончательный продукт соответствую-
щим образом, а затем решает, готова ли конечная система к выпуску. При тестирова-
нии на уровне системы среда тестирования должна быть как можно ближе к среде
развертывания. В противном случае тестер не будет оценивать конечный продукт.
Дополнительные сведения
Категории тестирования системы обсуждаются в работах [Beizer 84], [Kaner 99] и
[Myers 76].
Регрессионное тестирование
Регрессионное тестирование заключается в повторном использовании поднабора
тестов (которые до этого уже выполнялись) в новой версии приложения, чтобы убе-
диться, что функции, которые работали в предыдущей версии системы, по-прежнему
работают так, как ожидается. Устранение ошибок или добавление новых функций
может разрушить что-то, что раньше работало.
Добавление новых функций может сделать недействительными старые регресси-
онные тесты. Таким образом, тестеру может понадобиться удалить или обновить су-
ществующие тесты, чтобы учесть функции нового продукта.
Существенные моменты, касающиеся качества ПО
После того как разработчики устранили дефекты, регрессионные тесты заново за-
пускаются для проверки целостности модифицированного приложения. В идеальной
среде тестирования ч естер выполняет тест заново каждый раз, когда в приложение
вносятся изменения. Нельзя считать, что приложение свободно от дефектов только
потому, что набор регрессионных тестов был пройден. В новых тестах требуется про-
верять заново добавленные функции.
Создание качественного ПО
287
Дополнительные сведения
Обсуждение регрессионного тестирования представлено в работах [BeizerQO] и
[Капег99].
Тестирование одобрения
При тестировании одобрения подтверждается, что система удовлетворяет требо-
ваниям пользователя и приложение готово к немедленному использованию. Эта фаза
тестирования наступает после завершения тестирования системы. Тесты на одобре-
ние состоят из типичных пользовательских сценариев, сосредоточенных на основ-
ных требованиях к функциональным возможностям. Эти тесты являются типичным
поднабором тестовых примеров системы, которые запускаются в реальном пользова-
тельском окружении. Окончательные тесты на одобрение часто выполняются с уча-
стием клиента.
Существенные моменты, касающиеся качества ПО
Тестирование одобрения— это последняя контрольная точка перед выпуском.
Тесты на одобрение часто являются выбранным поднабором тестовых примеров, ко-
торые запускаются в реальном окружении; их может выполнять и конечный пользо-
ватель. Пункт о проведении тестов на одобрение в присутствии заказчика часто пре-
дусматривается в контракте, чтобы можно было продемонстрировать, что продукт
удовлетворяет нуждам клиента.
Дополнительные сведения
Дополнительную информацию о тестировании одобрения читатель найдет в ра-
ботах [Myers 76] и [Hetzel 88].
Задачи тестирования ПО
Тестирование ПО требует большего, чем просто создания и проведения тестов.
Прежде чем начать тестирование тестер должен продумать общую стратегию тести-
рования, включая способ описания ошибок, найденных в ходе тестирования. Автома-
тизация представляет очень важную часть тестирования, она должна быть как следует
выполнена, чтобы можно было добиться существенных результатов. В конце проекта
результаты тестирования ПО вносятся в заключительный отчет.
Планирование тестирования
В идеале тестер составляет план тестов на каждом уровне тестирования, от тести-
рования на уровне системы до поэлементного тестирования. Во многих организациях
план тестирования применяется к процессу в целом.
В плане тестирования системы описываются требования, ресурсы, стратегии и ка-
лендарный план для тестирования приложения. В хорошем плане тестирования зада-
ется:
288
Глава 9
• обзор графика процессов тестирования, который используется менеджерами
проекта для составления календарного плана проекта;
• подход к тестированию, включая использование инструментов тестирования;
• инструменты тестирования, включая то, как и где они будут получены;
• процессы, с помощью которых проводятся тесты и составляется отчет о ре-
зультатах;
• критерии входа и выхода из системы;
• персонал, который будет проектировать, разрабатывать и выполнять тесты;
• оборудование (необходимые машины и испытательные стенды);
• цель покрытия тестов (где это приемлемо);
• специальные конфигурации программного и аппаратного обеспечения, необ-
ходимые для тестов;
• стратегии тестирования приложения;
• функции, которые будут и которые не будут тестироваться;
• планы рисков и чрезвычайные планы.
Планы тестирования сборки и поэлементного тестирования содержат много ин-
формации, которая перечисляется в плане тестирования системы, кроме того, в них
установлены рамки для процессов тестирования сборки и поэлементного тестирова-
ния, соответственно.
Существенные моменты, касающиеся качества ПО
Информация, содержащаяся в плане тестирования, помогает тестеру приобрести
необходимые ресурсы для создания среды тестирования и определить подход для
создания тестов. После утверждения менеджерами план становится календарным
планом проведения процессов тестирования, а также укрепляет осознание тестером
масштабов своей ответственности.
Дополнительные сведения
Содержимое плана тестирования перечисляется в двух стандартах: [IEEE 829] и
[IEEE12207], Дополнительно о планах тестирования можно узнать из работ
[Beizer 84], [Капег99], и [Kit 95]. Таблица контрольных проверок для пересмотра
плана тестирования представлена в [Humphrey],
Автоматизация тестов
Часть процесса тестирования, касающаяся автоматизации, может дать такие дол-
говременные преимущества:
<
• сокращение времени на выполнение набора тестов;
• снижение вовлеченности тестера в тестирование;
• упрощение регрессионных тестов;
Создание качественного ПО
289
• возможность имитации тысяч пользователей;
• возможность избежать человеческих ошибок при наличии инструментов, ко-
торые контролируют повторяющиеся и трудоемкие задачи.
Автоматизация тестирования относится к двум ключевым процессам тестирова-
ния: проведению тестов и оценке выходных данных. Многие коммерческие инстру-
менты поддерживают такие процессы тестирования. Ниже перечислены наиболее
распространенные инструменты тестирования.
Инструменты записи-воспроизведения регистрируют события (в том числе нажатия
клавиш, действия мышкой и отображение результатов) в процессе запуска тестером
приложения и размещают информацию в сценарии. Теоретически, инструмент мо-
жет затем воспроизвести сценарий, чтобы выполнить приложение, однако на прак-
тике записанные тесты ограничены в использовании, но хорошо структурированные
сценарии реализации дают значительные преимущества.
Компараторы находят отличия между двумя наборами данных и затем определяют
результат теста. Тестер часто может задавать данные, которые должны игнориро-
ваться. Например, при игнорировании различия в полях даты/времени тест по-
прежнему будет считаться пройденным, если остальные данные верны.
Инструменты проведения тестов создают среду, которая инициализирует приложе-
ние, отправляет ему данные, регистрирует выходные данные, отправляет выходные
данные на компаратор для оценки и регистрирует полученные результаты.
Однако при автоматизации тестов требуется приложить значительные усилия,
чтобы получить отдачу. Приобретение инструмента тестирования— это еще не ус-
пешная автоматизация процесса тестирования, которая строится только на основе
хороших процессов тестирования. Следовательно, если среда хаотична, то сущест-
вующий хаос просто будет автоматизирован. Создание удобной автоматизированной
среды тестирования отнимает много времени и выгоду можно получить только после
нескольких итераций запуска тестов. Для успешной автоматизации тестирования
важны следующие моменты.
1. Автоматизированные инструменты тестирования не задают или не создают
сценариев тестов. Для программирования тестов потребуется немало времени.
2. Сами по себе сценарии являются языками программирования, следовательно,
для автоматического выполнения тестов требуется опыт программирования.
3. Инструменты тестирования не выбирают правильных тестов автоматически.
4. Тестерам нужно потренироваться в использовании инструментов.
5. Для отслеживания большого числа файлов и связанных с тестами артефактов
необходим конфигурационный менеджмент.
6. Любые автоматизированные тесты, которые потерпели неудачу при обнаруже-
нии ошибок, не дают гарантии, что нет других дефектов.
7. Поддержка наборов тестов может отнять много времени и сил.
290
Глава 9
8. Со временем тесты устаревают, поэтому необходимо постоянно разрабатывать
новые.
9. Инструменты тестирования являются программами, в них есть свои дефекты.
Автоматизацию тестов нельзя использовать, если:
• тесты зависят от взаимодействий, осуществляемых вручную (например, загруз-
ки диска);
• тесты планируется запускать только один раз или же очень редко;
• согласно оценкам, тест прост для человека и сложен для программы (напри-
мер, определяется удобочитаемость и доступность формата выходных данных).
Существенные моменты, касающиеся качества ПО
Автоматизация тестов облегчает регрессионные тесты, повторяя предыдущие тес-
ты так часто, как это необходимо, и выполняет их за более короткий срок, чем это
сделал бы человек. Автоматизированные тесты позволяют избежать ошибок, к кото-
рым приводит ручное тестирование, поскольку даже самые усердные специалисты
при наборе делают ошибки (к примеру, уставший тестер может неверно интерпрети-
ровать сгенерированные выходные данные). Для хорошей автоматизации тестирова-
ния требуются навыки опытного тестера, чтобы задать и выбрать нужные тестовые
примеры.
Дополнительные сведения
Автоматизации тестирования посвящены работы [Dustin 99] и [Fewster99]. В по-
следней описаны истории из реальной жизни для действующих проектов (как пози-
тивные, так и негативные). При просмотре Web-узлов поставщиков инструментов
можно обнаружить дополнительную информацию в виде демонстраций и учебных
пособий по использованию этих инструментов.
Система составления отчета о неполадках
Составление отчетов о неполадках— это процесс, инициирующий устранение
ошибок, усовершенствования, приемку и позволяющий отслеживать ход изменений.
В нем представлены методы управления внесением изменений и минимизации влия-
ния переделок, что весьма существенно для контроля качества. В зависимости от сре-
ды разработки система составления отчетов о проблемах может сочетаться или быть
независимой от конфигурационного менеджмента.
Существует три вида деятельности, помогающие контролировать изменения:
• установка очередности, в которой вносятся изменения;
• анализ влияния изменений в требованиях на уже завершенную работу;
• назначение ответственного специалиста за внесение изменений.
Создание качественного ПО
291
На современном рынке имеется множество коммерческих инструментов для со-
ставления отчета о неполадках. Эти инструменты задают метрики и предоставляют
отчеты, чтобы установить недостатки и проследить статус тестов.
Существенные моменты, касающиеся качества ПО
Системы составления отчетов являются основным средством обмена информаци-
ей между тестерами и разработчиками. Тестеры записывают все найденные неполад-
ки и предоставляют детальную информацию для их воспроизведения, хотя некото-
рые неполадки воспроизвести не так просто. Когда разработчики устранили пробле-
му и для тестирования доступна новая версия, тестер повторно выполняет связанный
с ней тестовый пример, чтобы убедиться, что проблема действительно была устранена.
Менеджеры оценивают работу по тестированию, создавая метрики с помощью
системы составления отчетов о неполадках. Сравнение количества найденных новых
неполадок с числом тех, которые были закрыты, помогает установить, готово ли при-
ложение к выпуску. Статистика ошибок также помогает определить области, которые
вызывают больше всего проблем.
Дополнительные сведения
Многие книги по конфигурационному менеджменту ПО также касаются составле-
ния отчетов о неполадках, так что можно обратиться к работам, перечисленным в
разделе “Конфигурационный менеджмент в разработке ПО”. Среди других книг, в ко-
торых обсуждается составление отчетов о неполадках и управление внесением изме-
нений, можно назвать работы [Капег 99] и [Wiegers 96].
Составление отчета о тестировании
Хотя отчеты о тестах могут принимать различные формы, их основная задача за-
ключается в описании событий, которые произошли во время процесса тестирова-
ния. Организация и заказчики должны определить наиболее приемлемый тип отчета.
В типичном отчете о тестировании указываются используемые конфигурации и среда
тестирования, а затем перечисляются выполненные тесты и их результаты. Деталь-
ный отчет о тестах включает журнал тестов (в котором перечисляются все тестовые
примеры с их результатами), а иногда и список всех отчетов о неполадках, связанных
с провалившимися тестами. С другой стороны, в финальном отчете о тестах анализи-
руются результаты тестов, т.е. указывается число выполненных тестов, тестов, кото-
рые были пройдены и которые провалились, количество повторно выполненных тес-
тов, а также перечисляются типы обнаруженных неполадок.
Существенные моменты, касающиеся качества ПО
Эти документы отображают действия тестера в ходе тестирования приложения.
Метрики, полученные из статистики тестов, помогают определить степень готовно-
сти приложения к использованию.
292
Глава 9
Дополнительные сведения
Работы [IEEE 829] и [Humphrey 89] описывают сложности, связанные с составле-
нием отчета о неполадках.
Резюме
Для создания качественных программных продуктов и эффективного тестирова-
ния чрезвычайно важны следующие ключевые моменты проектирования ПО.
1. Четкое задание требований упрощает процессы разработки и тестирования.
2. Руководство проекта устанавливает ресурсы и календарные планы для проекта,
а также отслеживает фактические проектные работы.
3. Конфигурационный менеджмент ПО позволяет отслеживать изменения на
протяжении жизненного цикла разработки.
4. Обеспечение качества ПО подтверждает, что продукт разработан согласно ус-
тановленным нормам.
5. Пересмотры, в общем, — это процесс, с помощью которого люди оценивают
часть работы. Другие члены проекта могут узнать о продукте во время ознаком-
ления. Аудиты ПО представляют собой специфический тип пересмотра и сле-
дуют более строгим правилам.
Чтобы эффективно провести тест, нужно тщательно настраивать среду тестиро-
вания. Тесты применяются на всех уровнях разработки ПО (от поэлементного тести-
рования до тестирования продукта в целом). Регрессионное тестирование заключает-
ся в повторении существующих тестов для подтверждения корректной работы преж-
них функций. Тестирование одобрения — это финальная контрольная точка оценки
требований конечного пользователя (часто это делает сам клиент).
Создание и проведение тестов — это только часть полной картины тестирования.
В фазе планирования тестов задается общая стратегия тестирования. Инструменты
тестирования помогают автоматизировать многие задачи тестирования. Система со-
ставления отчетов о неполадках позволяет отслеживать информацию о провалив-
шихся тестах. Окончательный отчет, построенный на заключениях о процессах тес-
тирования, резюмирует работы по тестированию и их статистику.
ГЛАВА
10
Программные стандарты
в тестовой документации
Введение
В предыдущих главах этой книги были представлены методы организации сведе-
ний о продукте для написания тестовых примеров. Некоторые из описаний результи-
рующих тестов довольно исчерпывающие, в то время как другие отнюдь неполны.
Для многих организаций сам только факт написания тестовых примеров, пусть даже
несовершенных, является значительным достижением. Хотя хорошо продуманная
документация лучше, чем бессистемно составленные тесты, этого не достаточно для
организаций, которые стремятся соответствовать промышленным стандартам.
Во многих организациях в качестве схем сертификации используются программ-
ные стандарты, в то время как в других в качестве основы для усовершенствования
применяются модели оценки. Если не учитывать поставленные задачи, то и стандар-
ты, и модели дают проверенные методы создания хорошего ПО. В работе [Moore 98]
сделан краткий обзор всевозможных стандартов разработки ПО, доступных на дан-
ный момент. Чтобы не усложнять объяснение материала, далее будет использоваться
общий термин стандарт, относящийся к стандартам, моделям и схемам сертификации.
Хотя немногие стандарты непосредственно касаются проблем тестирования ПО,
можно задать процедуры тестирования ПО, которые будут соответствовать опреде-
ленным стандартам. Наличие таких процессов в результате даст единообразные ме-
тоды тестирования. Естественно, что по мере выявления особенностей аспектов
происходит модификация процесса тестирования. Усовершенствование процессов
ПО выходит за рамки этой книги. ___
В главе представлены рекомендации по составлению тестоврйГдокументации, ко-
торая согласовывается с установленными промышленными методами. Данную книгу
294
Глава 10
нельзя назвать учебником по стандартам для начинающих; это скорее краткое описа-
ние того, как каждый из стандартов влияет на документацию тестовых примеров. Да-
лее будут рассмотрены следующие общеупотребительные в сообществе разработчи-
ков ПО модели и схемы сертификации.
• Стандарт ISO 9001.
• Стандарты ISO/IEC12207 и IEEE/EIA12207.
• Стандарты разработки ПО IF.F.F.
• Модель развития функциональных возможностей для ПО (Capability Maturity
Model® for Software — SW-CMM®. Модель SW-CMM и модель развития функ-
циональных возможностей (СММ) зарегистрированы в Бюро патентов и тор-
говых знаков США).
В стандартах прослеживается четкое различие между тем, что требуется, и тем,
что рекомендуется. Рекомендуемые этапы становятся пригодными к проверке только
тогда, когда организация в своих внутренних процессах посчитает эти этапы обяза-
тельными. Поскольку данные стандарты касаются вопросов перекрытия, можно соз-
дать документы для тестовых примеров, которые полностью согласуются с несколь-
кими или даже со всеми стандартами. В конце этой главы представлен шаблон тесто-
вого примера, в котором определяются обязательные и рекомендованные разделы.
Общие элементы
Большинство стандартов, влияющих на разработку ПО, касаются одних и тех же
основных элементов. Для каждой качественной системы требуется конфигурацион-
ный менеджмент и пересмотры, в то время как для остальных рекомендуются различ-
ные степени трассировки. Общий обзор таких концепций представлен в главе 9.
В следующих разделах предлагается несколько способов применения этих концепций
к тестовым примерам, чтобы удовлетворить стандартам.
Конфигурационный менеджмент
С позиции тестера, конфигурационный менеджмент касается нескольких областей:
• версии документации по тестированию;
• версии тестируемого приложения;
• управления средой тестирования.
В документации по тестированию номер версии можно задействовать к отдельно-
му тестовому примеру, к таблице тестовых примеров или к документам, содержащим
набор тестовых примеров. Независимо от того, как упакованы тестовые примеры,
тестер должен быть в состоянии быстро определить версию теста. Хотя гес геры мо-
гут вносить номер версии в описание тестового примера вручную, использование
коммерческих средств автоматической реализации конфигурационного менеджмента
для отслеживания тестовых примеров или версий документов менее подвержено
Программные стандарты в тестовой документации
295
ошибкам. Использование таких средств более надежно, поскольку они не зависят от
памяти человека и его аккуратности.
Новый номер версии присваивается каждой новой конструкции программного
приложения. Тестер ссылается на этот номер версии при выполнении тестов и со-
ставлении отчетов о неполадках. Использование инструментов конфигурационного
менеджмента создания ПО является наиболее эффективным способом контроля мно-
гих компонентов приложения.
Среда тестирования должна адекватно воспроизводить производственную среду,
чтобы можно было соответствующим образом протестировать выпускаемое прило-
жение. Конфигурационный менеджмент помогает контролировать создание среды
тестирования, включая версии операционной системы и конфигурации системы. Это
позволяет тестеру создать отчет о точных и полных результатах тестов.
Пересмотры
Во многих стандартах требуется, чтобы тестовые примеры и документация по
тестированию подвергались пересмотру, а исход пересмотра был документирован.
В различных стандартах на пересмотре делается различный акцент, поэтому здесь бу-
дут выделены моменты, которые нужны для нахождения неполадок, несоответствий,
обнаружения доку ментов и рекомендованных усовершенствований.
Важно фиксировать:
• найденные неполадки;
• приоритет каждой неполадки;
• Дату пересмотра;
• имена аудиторов;
• резолюцию.
Поскольку тестеры часто создают один документ, содержащий набор тестовых
примеров, можно воспользоваться одной страницей для резолюции, на которой за-
писывается информация, связанная с пересмотром, и ставится подпись под подтвер-
ждением. Существует несколько методов записи, которые позволяют фиксировать
исходы пересмотров, поэтому организация должна решить, какой из процессов при-
менить на практике. Методы записи информации, касающейся пересмотра, включают
следующие моменты.
1. Каждый аудитор должен ознакомиться с документом, содержащим набор тесто-
вых примеров, и датировать его.
2. Каждый аудитор должен ознакомиться со всеми тестовыми примерами или пе-
ресматриваемыми таблицами и да тировать их.
3. Для регистрации дат, пересматриваемых элементов, приоритетов неполадок и
имен аудиторов используется таблица в журнале регистраций пересмотра. Вся
эта информация отправляется по электронной почте команде разработки про-
дукта и архивируется для будущих ссылок.
296
Глава 10
После того как индивидуальные пересмотры завершены, тестеры должны внести в
документацию тестовых примеров необходимые изменения, сообщить об изменениях
каждому аудитору и поместить копию нового документа в систему конфигурационно-
го менеджмента.
Прослеживаемость требований
В некоторых стандартах затрагивается вопрос возможности прослеживания связи
между требованиями и тестовыми примерами. Одним из примеров можно назвать
матрицу прослеживаемости, показанную в табл. 4.19, в которой каждое требование
отображается на один или несколько связанных с ним тестовых примеров. Использо-
вание матрицы прослеживаемости — это один из самых простых способов, с помощью
которого можно добиться прослеживаемости требований. Еще один подход заключа-
ется в хранении соответствующей информации в рамках тестового примера и в дру-
гих проектных документах.
В некоторых предыдущих примерах иллюстрируются случаи обратной прослеживае-
мости. В тестовых примерах (табл. 4.19), полученных из схемы тестов, сделана ссылка
на соответствующий элемент схемы, который порождает каждый тестовый пример.
Этим обеспечивается обратная прослеживаемость между тестовым примером и схемой.
Аналогично, в тестовых примерах, полученных из таблицы состояний (табл. 3.1), дана
ссылка на событие, связанное с данным тестом. В этих двух примерах обеспечивается
прослеживаемость от тестового примера назад к проектным документам, в которых
задается тест; в них НЕ обеспечивается обратная прослеживаемость от тестового
примера к исходным требованиям, как утверждается в некоторых стандартах. Пере-
числение требований, подтвержденных тестовыми примерами на реальных формах
тестовых примеров, — это еще один способ, с помощью которого можно добиться об-
ратной прослеживаемости.
В табл. 5.3 показано использование прямой прослеживаемости. В каждом элементе
схемы сделана ссылка на тестовый пример, в котором реализуются заданные условия.
Если в схему вносятся какие-либо изменения, тестер может быстро определить, на ка-
кой тестовый пример эти изменения повлияют. Прямая прослеживаемость в этом
примере позволяет связать проект теста с результирующим тестовым примером (но
не исходные требования с соответствующим тестовым примером).
Промышленные стандарты
Дальше будут рассмотрены некоторые из наиболее распространенных стандартов,
влияющих на тестирование ПО. Многие тестовые примеры из предыдущих глав сле-
дует изменить для того, чтобы удовлетворить специфическим требованиям и реко-
мендациям.
Стандарт ISO 9001
ISO 9001 — это стандарт, основанный на принципах контроля качества. Изна-
чально принятый производителями, сейчас ISO 9001 используется во многих от-
раслях промышленности. Стандарт ISO 9001 также применим и к разработке ПО —
Программные стандарты в тестовой документации
297
он охватывает проектирование продукта, его разработку, создание, установку и об-
служивание.
В стандарте ISO 9001 акцент сделан на документации, контроле, прослеживаемо-
сти, замерах и идентифицируемости. Ключевыми темами также являются введение
поправок и выполнение. Важно не только регистрировать проблемы и отчитываться
о них, должны существовать процедуры, позволяющие убедиться в том, что проблема
решена и спорные вопросы улажены.
В стандарте ISO 9001 указывается, что нужно делать, чтобы получить качественное
окружение; однако в стандарте не говорится, как это сделать. Определение реальных
процедур — это уже дело отдельных организаций, цель которых состоит в удовлетво-
рении нужд заказчика. По существу, в стандарте задаются ключевые функциональные
требования, для каждого из которых нужно сказать, что делается, как сделать то, что
сказано, и иметь возможность показать, что было сделано. Реализация может отличать-
ся для разных организаций. В рекомендациях ISO 9000-3 и британском руководстве
TickIT даются указания по применению стандарта ISO 90001 в среде разработки ПО.
Влияние на тестирование ПО
Поскольку каждая организация, которая стремится придерживаться стандарта
ISO 9001, разрабатывает свои собственные процедуры тестирования, уровень строго-
сти может варьироваться. Аудитор, знакомый с принципами тестирования ПО, будет
опираться:
• на тестовую документацию, которая соответствует заданным компанией стан-
дартам;
• на наличие плана тестирования;
• на обоснование проектирования;
• па заданные процедуры аудита и выхода для результирующих процедур тести-
рования;
• на признаки того, что неполадки регистрируются и отслеживаются с целью их
решения;
• на ведение протоколов, отражающих качество системы;
• на проведение внутреннего аудита качества системы.
Организация может реализовать идентифицируемость и прослеживаемость путем
задания следующих процедур:
• помещения тестовых примеров под управление конфигурациями;
• документирования или иного способа задания прослеживаемости между требо-
ваниями и тестовыми примерами;
• пересмотра тестовых примеров;
• регистрации тех, кто выполнял пересмотр и кто утверждал тестовые примеры;
• архивирования тестовых примеров;
298
Глава 10
• документирования провалившихся тестовых примеров таким образом, чтобы
сбой можно было воспроизвести;
• фиксации и решения проблем.
Изменения к предыдущим примерам
Тестовые примеры из предыдущих глав сами по себе согласуются со стандартом
ISO 9001 при условии, что это соответствует документированным процедурам органи-
зации.
Предлагаемые ссылки
Самая последняя версия международного стандарта [180 9001:2000] заменяет пре-
дыдущую— [180 9001:1994]. Стандарт [ISO 9000-3] — это руководство по применению
стандарта ISO 9001 к среде разработки ПО.
К публикациям, касающимся реализации стандарта ISO 9001 в среде ПО, относят-
ся [Bamford 97], [Kehoe 96] и [Schmauch 94]. Сравнение стандарта ISO 9001 с Capabil-
ity Maturity Model® для ПО можно найти в работах [Bamford 93], [Bamford 98] и
[Paulk 94].
Информацию по TickIT можно получить на Web-узле www.tickit.org.
Стандарты ISO/IEC 12207 и IEEE/EIA 12207
ISO/IEC 12207 — это международный стандарт, разработанный совместными уси-
лиями Международной организации по стандартизации (International Organization for
Standardization — ISO) и Международной электротехнической комиссией (Internatio-
nal Electromechanical Commission — IEC). Стандарт описывает структуру процессов
жизненного цикла ПО от концепции до изъятия из обращения. Этот стандарт совмес-
тим с методом систем качества, контролем качества и поддержкой качества ISO 9001.
Стандарт IEEE/EIA12207 - адаптация ISO/IEC 12207 для США.
Стандарт ISO/IEC 12207 описывает следующие процессы жизненного цикла:
• Первичные процессы: Приобретение, поставка, разработка, функционирование и поддержка.
• Вспомогательные Документация, конфигурационный
процессы: менеджмент, гарантия качества, проверка, обоснование, совместный пересмотр, аудит и решение проблем.
• Организационные Управление, инфраструктура,
процессы: усовершенствование и обучение.
В стандарте ISO/IEC 12207 не указываются конкретные модели жизненного цикла
или методы разработки ПО, в нем также не задаются детали процесса разработки
или формат и содержимое документации. Следовательно, организации, стремящие-
ся применить ISO/IEC 12207, могут для определения видов деятельности, которые
Программные стандарты в тестовой документации
299
охватывают процесс разработки, использовать дополнительные стандарты (напри-
мер, один из стандартов разработки ПО IEEE).
Стандарты ISO/IEC 12207 и IEEE/EIA12207 предусматривают несколько уровней
тестирования ПО, к которым относятся:
• написание кода и тестирование ПО: разработать и документировать тестовые
процедуры и данные для тестирования каждого элемента ПО;
• интеграция и тестирование ПО: разработать план интеграции, согласно кото-
рому будут интегрироваться и тестироваться элементы ПО по мере разработки;
• тестирование ПО на соответствие техническим условиям: убедиться перед ин-
теграцией, что каждый элемент ПО удовлетворяет требованиям;
• тестирование системы на соответствие техническим условиям: убедиться, что
продукт готов к выпуску.
Кроме того, стандарты предусматривают поддержку таких видов деятельности:
• конфигурационного менеджмента;
• гарантии качества;
• обоснования и проверки;
• пересмотров;
• аудитов;
• процесса'разрешения проблем.
Влияние на тестирование ПО
Чтобы соответствовать стандарту ISO/IEC 12207 или IEEE/EIA12207, требуется
определенная документация. В стандартах задается также содержимое каждого из
этих документов:
• план обеспечения качества ПО;
• план тестирования;
• процедура тестирования;
• отчет о результатах теста.
Согласно стандартам ISO/IEC 12207 и IEEE/EIA 12207 процедуры тестирования
должны включать следующие сведения:
• об авторе;
• о конфигурации теста;
• задачи и основания;
• данные о подготовке теста, включая аппаратное и программное обеспечение;
• идентификатор теста;
300
Глава 10
• относящиеся к делу требования и прослеживаемость требований;
• предварительные условия;
• критерий перекрытия теста или другой метод подтверждения обоснованности
тестирования;
• тестовые входные данные;
• процедуры и данные для тестирования каждого элемента ПО и баз данных;
• ожидаемые результаты теста;
• критерий оценки результатов;
• инструкции по выполнению процедур.
Чтобы удовлетворять либо ISO/IEC 12207, либо IEEE/EIA12207, организации
должны ввести конфигурационный менеджмент и пересмотры документации тестов.
Они также должны обеспечить процесс решения проблем.
Изменения к предыдущим примерам
Тестовые примеры в предыдущих главах содержали многие, но не все компонен-
ты, требуемые стандартами ISO/IEC 12207 и IEEE/EIA 12207. Если к тестовым при-
мерам добавить следующие сведения, то они будут удовлетворять данным стандартам.
• Имя и фамилию автора тестового примера.
• Конфигурацию теста.
• Относящиеся к делу требования (за исключением случая, когда делается ссылка
на матрицу требований).
• Критерий оценки результатов.
• Введение к реализации процедур.
Предлагаемые ссылки
[ISO 12207] — это международный стандарт, a [IEEE 12207] — его эквивалент в
США, состоящий из трех частей:
• стандарт IEEE/EIA 12207.0— это стандарт ISO 12207 с введением для США и
шестью дополнительными приложениями. Данный документ охватывает мате-
риалы для США во всем тексте стандарта ISO/IEC 12207;
• стандарт IEEE/EIA 12207.1 — резюме содержимого каждого документа;
• стандарт IEEE/EIA 12207.2— руководство с дополнениями, альтернативами и
методами реализации для многих видов деятельности и задач ISO 12207.
В работе [Shoemaker 99] описывается способ использования стандарта ISO/IEC 12207.
Программные стандарты в тестовой документации
301
Стандарты разработки ПО IEEE
Институт инженеров по электротехнике и электронике (Institute of Electrical and
Electronics Engineers — IEEE) выпускает наборы стандартов, которые относятся к раз-
работке ПО. Каждый индивидуальный стандарт описывает отдельный аспект разра-
ботки ПО и дает специфические указания в отношении выполнения этой задачи.
Из всех стандартов, представленных в данной главе, стандарты разработки ПО IEEE
самым непосредственным образом описывают то, как реализовывать процесс тести-
рования ПО.
В стандартах разработки ПО IEEE акцент во многом сделан на те же ключевые ин-
фраструктурные принципы, что и в других стандартах:
• четко заданные требования;
• конфигурационный менеджмент;
• пересмотры и аудиты;
• прослеживаемость требований.
Влияние на тестирование ПО
Здесь будут рассмотрены три стандарта IEEE, которые самым непосредственным
образом касаются тестирования ПО:
• ANSI /IEEE Std 829-1998 — стандарт IEEE для документации тестирования ПО.
• ANSI/IEEE Std 100-1987 (R1993) — стандарт IEEE для поэлементного тестиро-
вания ПО.
• ANSI/IEEE Std 730-1998 — стандарт IEEE для планов гарантии качества ПО.
В [IEEE 829] задается формат и указывается содержимое следующих типов доку-
ментов.
1. План тестирования: затронуть такие проблемы планирования, как рамки рабо-
ты, разработка графика, кадровое обеспечение и то, какие функции будут тес-
тироваться.
2. Спецификация проекта тестирования: указать подход, который будет исполь-
зоваться для тестирования приложения.
3. Спецификация тестового примера: задать тестовый пример, установленный
проектом тестирования.
4. Спецификация процедуры тестирования: установить этапы, необходимые для
выполнения набора тестов.
5. Отчет о передаче тестируемого элемента: определить тестируемый элемент,
указав локализацию элемента, среду развертывания, а также имя специалиста,
ответственного за тестирование этого элемента.
302
Глава 10
6. Журнал тестирования: записать важные детали, касающиеся выполнения теста.
Во многих таблицах, показанных в предыдущих главах, содержатся сведения о
выполнении теста.
7. Отчет о происшествиях, возникших в ходе тестирования: документировать об-
наруженные во время тестирования события, которые требуют дополнитель-
ного изучения. Система составления отчетов о неполадках — это один из спосо-
бов регистрации сведений.
8. Резюмирующий отчет о тесте: дать общую оценку работе по тестированию.
В этой книге представлено много принципов спецификаций проекта тестирова-
ния, тестовых примеров и процедур тестирования. В описании тестов из предыдущих
глав содержатся многие необходимые элементы [IEEE 829]:
• идентификатор теста;
• специальные требования, необходимые для запуска теста;
• описание входных данных;
• описание выходных данных;
• зависимость от других тестов;
• определение статуса теста.
В [IEEE 1008] перечисляются различные задачи, необходимые для проведения по-
элементного тестирования. Наиболее важными для документации тестовых примеров
задачами являются:
• определение рискованных областей, к которым тестеры обращаются при тес-
тировании;
• определение необходимых для тестирования ресурсов;
• выбор тестируемых функций;
• проектирование тестов;
• определение характеристик входных и выходных данных;
• пересмотр и утверждение всех тестовых примеров;
• использование конфигурационного менеджмента для всех тестовых примеров
и документов по тестированию;
• использование инструментов перекрытия кода для наблюдения за эффектив-
ностью тестов.
Стандарт [IEEE 730] требует от тестеров уделить особое внимание тем видам дея-
тельности, которые влияют на документы по тестовым примерам:
• следовать процессу, заданному для управления конфигурациями;
• проводить пересмотры и аудиты;
Программные стандарты в тестовой документации
303
• следовать процессу, заданному для составления отчетов о неполадках, отсле-
живанию неполадок и их устранению.
Кроме заданной тестовой документации и процедур поэлементного тестирования,
существуют отдельные стандарты IEEE для конфигурационного менеджмента, пере-
смотров, аудитов и спецификаций требований.
Изменения к предыдущим примерам
В образце тестового примера содержится много компонент, предусматриваемых в
[IEEE 829]. Чтобы тестовый пример соответствовал этому стандарту, тестеры должны
предоставить дополнительную информацию:
• перечень функций, которые будут и которые «сбудут тестироваться;
• определение критерия, с помощью которого можно установить, пройден тест
или провален;
• информация, необходимая для настройки и выполнения тестов;
• точно сформулированное описание тестовых входных данных;
• точно сформулированное описание ожидаемых выходных данных;
• проваленным тестам присваивается номер, связанный с отчетом о неполадках.
Схемы тестов и таблицы тестов, представленные в предыдущих главах, являются
необычайно важным дополнением к тестовой документации, поскольку они помогают
установить функции для тестирования. В зависимости от того, как используется эта
информация, тестер может включить схемы и таблицы либо в план тестирования, ли-
бо в проектные документы по тестированию. Схема или таблица, помогающая опре-
делить задачи по тестированию, может использоваться в качестве раздела “Список за-
дач тестирования” в плане тестирования. Таблица тестов, в которой указываются тес-
товые примеры, может быть частью документов проекта тестирования. Безусловно,
когда используются методы сокращения документооборота и нет никакой другой ин-
формации, схема и таблицы одновременно играют роль документов проекта тестиро-
вания и документов для тестовых примеров. Оптимальный вариант — включить схему
и таблицы во все документы по тестированию, в которых эта информация использу-
ется в качестве входных данных.
Предлагаемые ссылки
В работе [Kit 95] представлено краткое описание различных стандартов разработ-
ки ПО IEEE. В работе [Schmidt 00] содержатся общие сведения о том, как пользовать-
ся стандартами разработки ПО IEEE.
Модель Capability Maturity Model® для ПО
В модели SW-CMM®, разработанной Институтом программотехники (США), ос-
новное внимание уделяется проблемам управления. Согласно этой модели оценива-
ются функциональные возможности системы и организации-производителю при-
сваивается уровень развития от 1 до 5. К основным принципам SW-CMM® относятся:
304 Глава 10
• четко заданные этапы выполнения каждой задачи;
• соответствующее обучение специалистов;
• поддержка руководства при выполнении всех работ;
• оценка всех выполненных этапов.
Ниже перечислены пять уровней модели SW-CMM®..
Уровень 1 Уровень 2 Уровень 3 Исходный: процесс неформален и узкоспециален. Повторяемый: методы управления проектом официально утверждены. Заданный: технологические процессы интегрированы с методами управления и официально утверждены.
Уровень 4 Уровень 5 Управляемый: продукт и процесс контролируются количественно. Оптимизированный: усовершенствование процесса утверждено официально.
Более высокий уровень развития указывает на то, что организация следует более
строгим процессам. По мере того как уровень развития компании повышается, воз-
растают продуктивность и качество, и, соответственно, уменьшается риск провала
проекта и снижения доходов.
В SW-CMM® представлено не так уж и много указаний относительно тестирования
ПО, однако на уровне 3 в этой модели затрагиваются некоторые проблемы, связан-
ные с тестированием. Чтобы попасть на уровень 3, организация должна сначала дос-
тичь уровня 2, продемонстрировав свой опыт в области:
• управления требованиями;
• конфигурационного менеджмента ПО;
• гарантии качества ПО;
• управления субподрядчиками ПО;
• планирования проекта ПО;
• отслеживания и контроля проекта ПО.
Влияние на тестирование ПО
Соответствие модели SW-CMM® должно оказывать большее влияние на среду тес-
тирования и разработки, чем на реальные документы тестовых примеров. Реализация
связанных с тестированием задач в сфере основных процессов разработки про-
граммных продуктов затрагивает:
заданные процессы для выполнения тестирования ПО;
экспертную оценку планов тестирования, процедур тестирования и тестовых
примеров;
Программные стандарты в тестовой документации
305
• конфигурационный менеджмент для планов тестирования, процедур тестиро-
вания и тестовых примеров;
• процессы тестирования, которые четко указаны в планах проекта и календар-
ных планах;
• прослеживаемость требований к продукту между требованиями к ПО, проек-
том, кодом и тестовыми примерами;
• адекватные ресурсы и создание фондов для выполнения задач по тестирова-
нию ПО;
• использование и наличие инструментов;
• адекватное обучение тестеров ПО для выполнения поставленных задач;
• критерий готовности теста, установленный для поэлементного тестирования,
тестирования сборки, тестирования системы и тестирования на одобрение;
• использование перекрытия тестов для определения адекватности тестирования;
• процедуры отслеживания неполадок.
Изменения к предыдущим примерам
Образцы тестовых примеров могут соответствовать модели SW-CMM® при усло-
вии, что они разрабатываются согласно процессам, заданным организацией. Если в
Процессе указывается, что тестовый пример должен предоставлять подробные сведе-
ния о входных данных и другую информацию, то тестеру следует соответствующим
образом изменить документы тестовых примеров. В идеале, процесс организации
должен требовать, чтобы для тестовых примеров проводились пересмотры и чтобы
они попадали под управление версиями.
Предлагаемые ссылки
О модели SW-CMM® упоминается в [Paulk 93]. В работе [Humphrey 89] стандарт
SW-CMM® описан более детально. В работах [Bamford 93], [Bamford 98] и [Paulk 94]
SWCMM® сравнивается с ISO 9001.
Институт программотехники создал и другие модели, которые базируются на ана-
логичных концепциях. К ним относятся модель развития функциональных возмож-
ностей системного проектирования (Systems Engineering Capability Maturity Model®)
и интеграция моделей развития функциональных возможностей (Capability Maturity
Model Integration®). Все документы, созданные Институтом программотехники, дос-
тупны на Web-узле www.sei.cmu.edu
Соответствие стандартам
Можно задать один формат тестовых примеров, который будет удовлетворять не-
скольким стандартам. В табл. 10.1 перечислено возможное содержание тестовых
примеров. Обязательные или рекомендуемые поля изменяются согласно каждому
стандарту. Эта таблица имеет следующую структуру.
306
Глава 10
• В столбце 1 перечисляются названия полей тестового примера.
• В столбце 2 дано краткое описание содержимого полей.
• В столбцах 3-6 указывается, какие поля для соответствия стандарту обязатель-
ны (отметка ✓), а какие рекомендуемы (отметка *).
• Последний, 7-й столбец, содержит информацию, которую можно хранить от-
дельно от реального тестового примера. Подробнее об этом позже.
Каждая организация задает свой собственный внутренний процесс и выбирает
формат тестовых примеров, а также решает, какая рекомендуемая информация (если
она есть), будет входить в документацию тестового примера. В табл. 10.1 поля отме-
чены как рекомендуемые (обозначены *), ееди в стандарте эта информация затраги-
вается либо непосредственно, либо в ссылках. Способ применения рекомендуемых по-
лей зависит от того, как организация интерпретирует и использует каждый стандарт.
В ISO 9001 не указано четко, какая информация должна записываться в тестовых
документах. В табл. 10.1 перечислены рекомендуемые поля исходя из того, какому
стандарту уделено особое внимание. В плане тестирования (стандарт ISO 9001) кон-
статируется необходимость подтверждения, таким образом, можно предположить,
что тестовые примеры должны содержать базовые компоненты, т.е. описания вход-
ных и выходных данных. В ISO 9001 также затрагивается конфигурационный ме-
неджмент и отслеживание неполадок; однако в стандарте не указывается, как эти за-
дачи решаются. Следовательно, кажется вполне разумным фиксировать информацию
о версиях компонентов и ассоциировать провалившиеся тесты с соответствующими
номерами отчетов о неполадках.
В ISO/IEC 12207 перечисляется специфическая информация, которая должна до-
кументироваться в тестовом примере. В стандарте требуется наличие системы управ-
ления версиями и аудита, следовательно, связанные с ними поля также могут быть ча-
стью тестовой документации. Необходимо составить список неполадок, возникших в
ходе тестирования. Таким образом, тестер может либо создать перекрестную ссылку
на эту информацию, включив номер отчета о неполадках в тестовый пример, либо,
имея в наличии автоматический инструмент для составления отчета о неполадках, со-
слаться на провалившийся тест.
В IEEE 829 задается содержание спецификаций плана тестирования, тестового при-
мера и процедуры тестирования (вся эта документация представлена как обязательные
поля в табл. 10.1). Для строгой реализации IEEE 829 требуется создать документы тесто-
вых примеров так, как это задано. Тестеры, следующие свободной интерпретации этого
стандарта, могут предоставить ту же информацию, но необязательно в установленных
тестовых документах. Если организация решила реализовать стандарт IEEE на пере-
смотрах ПО и конфигурационном менеджменте, то должна быть также зафиксирована
соответствующая информация (отмеченная в табл. 10.1 как рекомендуемая).
В SW-CMM® не указывается содержание тестовых примеров, хотя предполагается,
что тестовые примеры должны быть хорошо структурированы. Организация, работаю-
щая на уровне 3, должна, по определению, достичь успехов на уровне 2. На уровне 2 за-
трагиваются такие проблемы, как конфигурационный менеджмент и прослеживае-
мость, в то время как на уровне 3 организация работает с пересмотрами. Это означает,
что связанная со всем этим информация может быть частью тестовых документов.
Таблица 10.1. Содержимое тестовых примеров
Поле тестового примера Описание ISO 9001 ISO/IEC SW- 12207 СММй IEEE 829 Внешние ссылки
Описание теста
Идентификатор теста Прослеживаемость требований Задача/элементы теста Взаимозависимости тестового примера уникальный идентификатор тестового примера указать тестируемые требования краткое описание тестируемых функций перечень других тестовых примеров, которые необходимо запустить перед этим тестом; задаются предварительные условия * * ✓ * ✓ ✓ ✓ ✓ * ✓ ✓ матрица требований
Конфигурация системы
Версия приложения Версия операционной системы Версия аппаратного обеспечения Версия инструмента тестирования версия выпуска ПО или приложения версия операционной системы, используемой для запуска тестируемого приложения версия аппаратного обеспечения, на котором запускается приложение версия инструмента тестирования, используемого для выполнения теста (если предполагается использование инструмента тестирования) ♦ * ♦ ♦ * * * * * * * ♦ * * * инструмент конфигу- рационного менедж- мента инструмент конфигу- рационного менедж- мента инструмент конфигу- рационного менедж- мента инструмент конфигу- рационного менедж- мента
Продолжение табл. 10.1
Поле тестового примера эгЦсание isc Ю01 ISO/IEC 12207 SV- CMM® IEEE 82'1 is' : Внешние ссылки а i
Описание теста г
Среда тестирования It
и входящая
информация 1
Климатические нужды перечень необходимого программного и аппаратного обеспечения, данных, файлов и т.д. ♦ z * z план тестирования
Исходная настройка перечень этапов, через которые должен пройти тестер, прежде чем выполнить * z * z
этот тест
Специальные описание любого специального ♦ z * z
процедурные вмешательства со стороны оператора,
требования процедуры определения исходов или другие необходимые процедуры
Спецификация перечень входной последовательности ♦ z ♦ z
входных данных данных, которую должен ввести тестер
Результирующая информация 1
Ожидаемые задать все выходные данные, включая ♦ z * z
результаты (если нужно) время ответа и допустимое отклонение от ожидаемых значений
Критерий оценки критерий, используемый для определения прохождения теста z z план тестирования
Реальные результаты после выполнения теста, нужно записать то, как отреагировало приложение * z ♦ z журнал тестирования
Продолжение табл. Ю. 1
Поле тестового Описание ISO 9001 ISO/IEC SW- IEEE 829 Внешние ссылки
примера 12207- смм®
Описание теста
Записи ‘ 4
п выполнении! ест* . м ч »•’?'W'-л,"*'.-.
Дата теста дата, когда этот тест был выполнен Z Z журнал тестирования
Имя тестера имя или инициалы специалиста, выполнявшего этот тест Z журнал тестирования
Результат: Пройден Провален Номер отчета о неполадках: указать, был этот тест выполнен успешно или нет если тест провалился, здесь нужно ввести номер отчета о неполадках ♦ ♦ ♦ * ♦ Z журнал тестирования журнал тестирования или система составления отчета о неполадках
История тес зого „ • *““** * » 4 ’ - |римср |/ | , | | • . «
Версия тестового примера номер версии этого тестового примера ♦ ♦ * * инструмент конфигу- рационного менедж- мента
Дата создания тестового примера дата создания этого тестового примера * * * ♦ инструмент конфигу- рационного менедж- мента
Автор теста имя специалиста, написавшего тестовый пример * * * * инструмент конфигу- рационного менедж-
мента
Окончание табл. Ю. 1
Попе тестовою примера ../Опй^нйе .' 1509001 ISO/IEC. >SW~ ' IEEE 829 Внешние ссылки
12207 СММ® /
Описание теста с
История'т^г^вого примера» "'У’’*.' ... ' ' . и . - - ..• ... X' '
Пересмотрен имя (имена) специалиста (специалистов), * * * * журнал пересмотра пересматривавших этот тест
Дата пересмотра Утвержден дата пересмотра этого теста * . * * журнал пересмотра имя специалиста, подписавшегося под * журнал пересмотра этим тестовым примером
Программные стандарты в тестовой документации
311
Настройка процесса тестирования ПО происходит следующим образом. Сначала
определяется информация, которая будет отслеживаться, а затем принимается реше-
ние о том, как эта информация будет регистрироваться. В идеале, инструментальные
средства облегчают отслеживание больших объемов информации. Независимо от то-
го, какая информация фиксируется, основным принципом работы с ней является то,
что она должна быть доступна по требованию.
Формат тестовых примеров
Формат реальных тестовых примеров задается тестером, за исключением случая,
когда он диктуется уже существующими в компании процедурами. Сами форматы
варьируются от организации к организации. В некоторых организациях тестовые
примеры документируются в виде обычных или электронных таблиц, в других созда-
ются детализированные тестовые примеры, аналогичные показанным на рис. 4.4 и на
рис. 5.3, иногда тестовые примеры зависят от инструментов тестирования, фикси-
рующих и хранящих информацию, связанную с тестовыми примерами.
В основном влияние на формат тестовой документации зависит от того, выполня-
ются ли тестовые примеры вручную или автоматически. Тестовые примеры, выпол-
няемые вручную, требуют вмешательства со стороны человека. В соответствующей
документации детально перечисляются этапы, которым должен следовать тестер,
чтобы тест был выполнен корректно. Тестер записывает результаты либо в форм}'
тестового примера, либо в специальный системный журнал.
Автоматизированные тесты требуют гораздо меньшего вмешательства со стороны
человека. Тестер должен задать, отладить и в некоторых случаях инициировать тест
под управлением автоматизированного инструмента тестирования. По завершении
тестирования тестер проверяет результирующий системный журнал, чтобы увидеть,
какие тесты были пройдены, а какие — провалены. Автоматизированные инструмен-
ты тестирования хранят информацию, касающуюся тестовых примеров, в специаль-
ных файлах, которые тестер может просмотреть. Хороший инструмент предоставля-
ет эту информацию и при необходимости создает печатные копии тестовых приме-
ров. Существует несколько особых случаев, в которых требуется печатная копия со-
держания тестовых примеров:
• обязательства по договору с заказчиком могут требовать, чтобы тестовые при-
меры были опубликованы и отданы заказчику;
• печатные копии тестовых примеров облегчают пересмотр реальных тестов;
• печатные копии тестовых примеров упрощают отладку. (Да, тестер должен от-
лаживать тесты!)
Когда формат тестового примера задан, тестер должен взвесить количество обяза-
тельной информации. Для тестового примера, содержащего слишком большое число
полей, существует риск, что такой пример будет недозаполненным и некорректным.
Если нет соответствующей методики подтверждения полноты описания тестового
примера, в условиях сжатых сроков выполнения тестер может оставить некоторые
поля пустыми или же предоставить неверную информацию. Иногда информацию
предоставляет сам инструмент.
312 Глава 10
Внешняя информация
Чтобы размер тестового примера оставался контролируемым, некоторые виды
информации можно хранить отдельно от реального документа тестового примера
при условии, что эта информация будет доступна независимо от ее расположения.
Тип информации, которую можно хранить где-то в другом месте, связан с историей
тестового примера, конфигурационным менеджментом, прослеживаемостью требо-
ваний, пересмотрами, результатами теста или составлением отчета о неполадках.
В столбце, помеченном как “внешние ссылки” в табл. 10.1, предлагаются следующие
альтернативные поля для записи информации.
Инструмент конфигурационного менеджмента Система составления отчетов о неполадках Матрица требований Используется инструмент конфигурационного менеджмента для отслеживания версий всех компонентов. Записывается информация о провалившихся тестах в систему составления отчета о неполадках. Используется матрица, которая отображает прослеживаемость между требованиями и тестовыми примерами.
Журнал пересмотров Важная информация процесса пересмотра записывается в журнал пересмотра.
Журнал тестирования Для отслеживания информации о выполнении и результатах тестов используется журнал тестирования.
План тестирования В плане тестирования задается информация, которая имеет отношение к набору тестовых примеров.
Некоторые из этих видов информации могут применяться к полном}' набору тес-
тов. Один из подходов к документированию заключается в использовании таблиц
тестовых примеров, в которых общая информация отделена от информации, спе-
цифической для тестов. В табл. 10.2 отдельно от конкретных тестовых примеров пе-
речислены виды сведений, относящихся к конфигурации и пересмотрам. Следует от-
метить, что в эту таблицу входят не все поля, перечисленные в табл. 10.1.
Таблица 10.2. Запись общей информации отдельно от тестовых примеров
Версия приложения Требуемое оборудование
Версия инструмента тестирования Тестовые примеры, которые пересматривались
Версия операционной системы Дата пересмотра
Версия аппаратного обеспечения Тестовый пример утвержден
ID Имеющие тестового отношения примера требования Входные Ожидэ- Релль- Статус Машина Номер Дата Автор Дата Имя данные емые ныере- теста для тести- отчета создания тестового выполнения тестера резуль- зультаты рования о непо- теста примера теста тэты ладках
314 Глава 10
Резюме
Хотя большинство тестовых примеров, составленных в рамках этой книги, адек-
ватны, многие из них для соответствия стандартам нуждаются в дополнительных све-
дениях, которые подтверждают то, что среда тестирования, конфигурации, входные
условия, результаты и апостериорная информация хорошо документированы.
В стандартах указывается, какие данные должны содержаться в тестовых приме-
рах, а также рекомендуется другая информация, которую организация может регист-
рировать. В стандартах также затрагиваются различные уровни конфигурационного
менеджмента, пересмотров и прослеживаемости требований. Организации сами за-
дают свои внутренние процессы и определяют типы информации, которые должны
отслеживаться как часть тестового примера. Тестовый пример может быть структу-
рирован таким образом, чтобы удовлетворять требованиям сразу нескольких стан-
дартов. Инструментальные средства тестирования могут создавать и отслеживать
большую часть полей тестового примера. Некоторые виды информации можно хра-
нить отдельно от документа реального теста при условии, что важная информация
будет легкодоступной.
ПРИЛОЖЕНИЕ
В этом приложении содержатся схемы, на которые сделаны ссылки в главе 2.
Затемненные области на каждой схеме указывают на то, что добавленный элемент
относится к предыдущей итерации.
Приложение А1 Приложение А2 Приложение АЗ Приложение А4 первая итерация схемы теста, вторая итерация схемы теста, третья итерация схемы теста, четвертая итерация схемы теста.
В главе 3 автор ссылается на следующую информацию о тестовом примере.
Приложение А5 тестовый пример, полученный из схемы.
Приложение А6 сокращение, в котором схема используется в качестве таблицы контрольных проверок.
Приложение А1
Итерация схемы 1
1 Температура духового шкафа
1.1 [R-1 ] Граничные значения 200-500° Ф
1.2 [R-1] Шаг5°Ф
1.3 [R-5] Значение по умолчанию 350° Ф
2 [R-3] Ручной режим
2.1 [R-4] Температура приготовления
2.2 [R-8] Команда начала работы
2.3 [R-10] Команда окончания работы
316 Приложение А
3 [R-3] Автоматический режим
3.1 [R-4] Температура приготовления
3.2 [R-6] Время начала работы
3.3 [R-6] Время окончания работы
3.4 [R-7] Команда начала работы
3.5 [R-11] Закончить приготовление
3.5.1 [R-11 ] Истекшее время
3.5.2 [R-11 ] Команда окончания работы
Приложение А2
Итерация схемы 2
1 [К-3] 1 1.1 Ручной режим [R-4] Температура приготовления
1.1.1 1.1.1 1.1.1 [ R-1 ] Граничные значения 200-500° Ф [К-1] Шаг5°Ф [R-5] Значение по умолчанию 350° Ф
1.2 [R-8] Команда начала работы
1.3 [R-10] Команда окончания работы
2 [R-3] Автоматический режим
2.1 [R4] Темпе ратура п । >иготовления
2.11 [R-1] Граничные значения 200-500° Ф
21.2 [R-1] Шаг 5° Ф
2.1.3 . [R-5] Значение по умсьттанию 350° Ф
2.2 [R-6] Время начала работы
2.3 [R-6] Время окончания работы
2.4 [R-7] Команда начала работы
2.5 [R-11] Закончить приготовление
2.5.1 [R-11 ] Истекшее время
2.5.2 [R-11] Команда окончания работы
Приложение АЗ
Итерация схемы 3
1 [R-3] Ручной режим
1.1 [R4] Температура приготовления
Приложение A 317
1.1.1 [R-l]
1.1.2 [R-l]
Граничные значения 200-500° Ф
Шаг5°Ф
2 [R-3]
2.1
Автоматический режим
[R4] 2.1.1 2.1.2 2.1.3 Температура приготовления [R-1] Граничные значения 200-500° Ф [R-1] Шаг5°Ф [R-5] Значение по умолчанию 350° Ф
2.1.4 Повторный ввод
2.15 Верные данные
2.1.6 данные ВИИННМИНННМВНВОодВНЯчЭ
2.2
[R-6] Время начала работы
2.2.1 Her данных/щ. умолчанию
2.2.2 Повторный ввод
2.2.3 Верные данные
2.2.4 Неверные данные
2.25 Относительно текущего времени
2 2.5.1 текущее время < время начала работы
2.2.5.2 текущее время = время начала работы
2.25.3 текущее время >время начала работы
2.2.6 I Угносительно введешь >го времени окончания работы
2.2.6.1 В|>емя начала работы определено после времени
окончания работд^ННН^НК^ВнйЯЮя
318
Приложение А
2.4
2.3
| R-7 Команда начала ; -аботы
2.4.1 Нетданных/поумолчашио
2.4.2 Повторный ввод
2.5 [R-11] Закончить приготовление
2.5.1 [R-11] Истекшее время
2.5.2 |R-11] Команда окончания работы
25.2.1 Нет даннык/по умолчанию
Ь-5.2.2 . Повторный вво^' ^5^3
2-6 .*oi ери модности "'В
2.7 Явление йаЪтстему
Приложение А4
Итерация схемы 4
1 [R-3] Ручной режим
1.1 [R-4] Температура приготовления
|,.-1.1 [R-1] Грав^иш1ез1шчейия200-500“^£>^'Шаг5оФ^
1.1В 199Ж/201
1.1.1.2 195/200/205 •
1.1.L3 . 499/500/501 '
Приложение А
319
1.1.2 1.1.3 [R-5] Значение по умолчанию 350° Ф Повторный ввод i.1.3.1 ' . л 1.1,3.2 ^;}духо^йЕ1хаф>валревастса •' . < /
1.1.4 Верные данные пниннннмвннвнншв
1.1.5 Неверные данные 1 1 ' ] 0 1.1.5.4 • не кратные 5 .. • • 4^1 1.1.5.5' ^хйрхщательныё значения, ‘ Л / W-/-АА -I (Примечание. В этом проекте нельзя ввести отрицательные значения) . . , j 1.1.5.6 буквенные символы ' '• 1 г С(Ж. - (Примечание. В этом проекте нельзя ввести • *.z^ * буквенные символы) - . 1.1.5.7 'другие клавиши г~. .. • ’ (Примечание! В этом проекте нет других клавиш) . *
1.2 [R-8] 1.2.1 Команда начала Нет данных/по умолчанию .2.1.1 духовой шкаф не раб тает 12 Духовой ЩК гея
1.2.2 Повторный ввод 199-2 Аловой шкаф нагревается
1.3 [R-10] 1.3.1 Команда окончания (Клавиша ОТМЕНА) Нет данных/по умолчанию •- , ... . • - - • 13.1.1 духовой шкаф не рабстает ховой шкаф нагревается
1.3.2 Повторный ввод 1.3.2.1 духовой шкаф не работает 1.3.2.2 духовой шкаф нагревается
320
Приложение А
[R-3]
2.1
Автоматический режим
2.2
2.1.5 Неверные данные
2.1.5.1 О
21.5.2 00€
2.1.5.3 035
2.1.5.4 не кратные 5
2.1.5.5 < ггрицателъные значения
(Примечание. В этом проекте нельзя ввести
отрицательные значения)
2.1.5.6 буквенные символы
(Примечание. В этом проекте нельзя ввести
буквенные символы)
21.5.7 другие клавиши
(Примечание. В этим проекте нет других
клавиш)
[R-6] Время начала работы
2.2.1 Нет данных/по умолчанию_________________________________
2.2.1.1 Не задано число (за клавишей ВРЕМЯ НАЧАЛА
РАБОТЫ последовала одна из перечисленных
ниже клавиш)
22.1.1.1 Нажать клавишу ВВОД
2.2.1.1.2 Нажать клавишу ВРЕМЯ ОКОНЧАНИЯ
РАБОТЫ
2.2.1.1.3 Нажать клавишу СТАРТ
2.2.1.1.4 Нажать клавишу ОТМЕНА
Приложение A 321
2.2.1.2 После набора чисел нс гккледовало нажатие
' . клавиши ВВОД (Клавиша ВРЕМЯ НАЧАЛА + число +
. одна из клавиш, перечисленных ниже. Таким
. образом команда ВРЕМЯ НАЧАЛА РАБОТЫ
>. ; ‘ сб[*асызается. за исключением случая, когда
нажимается клавиша ВВОД)
2 .2.1.2.1 Нажать клавишу ВРЕМЯ ОКОНЧАНИЯ
РАБОТЫ
2.2.1.2.2 Нажать клавишу СТАРТ
2.2.1.2.3 Нажать клавишу ОТМЕНА
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.3.2 2359 (верхняя граница)
Неверные данные
2.2.4.1 410
2.2.4.2 отрицателшые значения
(Примечание. В этом проекте нельзя ввести
отрицательные значения)
2.2.4.3 буквенные символы
(Примечание. В этом проекте нслыы ввести
буквенные символы)
2.2.4.4 другие клавиши
(Примечание. В этом проекте нет других
Относительно текущего времени
2.2.5.1 текущее время < время начала работы
2.2.5.2 текущее время = время начала работы
2.2.5.3 текущее время > время начала работы
Относительно введенного времени окончания работы
2.2.6.1 Время начала работы определено после
времени окончания работы
2.2.6.2 Определяется время начала работы, время
окончания, а затем снова время начала работы
2.3
R-6' Время окончания работы
1.8.1 Нет данных/по умолчанию)
322
Приложение А
о число (За клавишей ВРЕМЯ
•IГЧАНИЯ РАБОТЫ последовала одна
2.3.1.1.1 Нажать клавишу ВВОД
2.3.1.1.2 Нажать клавишу' ВРЕМЯ НАЧАЛА
РАБОТЫ
2.8.1.1.3 Нажать клавишу СТАРТ
2.3.1.1.4 . Нажать клавишу ОТМЕНА
2.3.1.2 » После набора чисел не последовало нажатие
клавиши ВВОД (Клавиша ВРЕМЯ НАЧАЛА
ВРЕМЯ
ОТМЕНА
•ный ввод
Верные данные
2.3.2
2.3.3
2.3.4
2J.3.1 (НМЛ (нижняя гуанина)
2.3.3.2 2359 (верхняя граница)
Неверные данные
Я* zzZ ' \/' /// ' ' zj*t*’v**z ** ' /7 »'»**•*'*»' ,, •'«i
\ . • •• ' - " ' : . . - ' .
2.3.4.2 930
2 3.4.3 отрицательные значения
^Примечание. В эт<ш проекте нельзя ввести
е^грицателйЯые значения) А «
буквенные символы
(Примечание. В этом проекте нельзя ввести
буквенные символы)
другие клавиши
^Примечание.1^^м проек& нет других '
клавиш)
Приложение А 323
2.5
2.3.5
2.3.6
[R-7]
2.4.1
2.4.2
[R-11]
2.5.1
2.5.2
Относительно времени начала работы
2.3.5.1 время начала работы < время окончания
2.3.5.2 время начала работы = время окончания
2.3.5.3 время начала работы > время окончания
Относительно текущего времени
2.3.6.1 текущее время < время окончания работы
2.3.6.2 текущее время = время окончания работы
2.3.6.3 текущее время > время окончания работы
2.4
Команда начала работы
Закончить приготовление
[R-11]
2.5.2.1
2.5.2.2
Команда окончания работы (клавиша
ОТМЕНА)
Повторный ввод _____
2.5.2.2.1 /духовой шка^эне*работает (духовой шкаф
немджетоднов!ременнобыгьв.
нерабочем и автоматическом режимах)
2.5.2.2.2 ’ -‘духовой шкаф нагревается . • Ч .
324 Приложение А
Приложение А5
Тестовые примеры, полученные из схемы теста
е примера Схема Предыдущее Входные данные Ожидаемые результаты .•Реалы-"-':' ные Ж резуль- таты
Т-1 1.11.1 (нерабочее состояние) 199 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-2 1.1.1.1 1.1.1.2 (нерабочее состояние) 200 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 200° за 4 минуты. Температура держится в диапазоне 198-202°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-3 1.1.1.1 (нерабочее состояние) 201 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-4 1.1.1.2 (нерабочее состояние) 195 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-5 1.1.1.2 (нерабочее состояние) 205 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 205° за 4 минуты. Температура держится в диапазоне 203°-207°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-6 1.1.1.3 1.1.5.4 (нерабочее состояние) 499 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-7 , 1.1.1.3 1.1.1.4 (нерабочее состояние) 500 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 500° за 6 минут. Температура держится в диапазоне 498°-502°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-8 1.1.1.3 (нерабочее состояние) 501 клавиша ВВОД клавиша СТАРТ Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Приложение А
325
Ю тестового примера Схема теста Предыдущее состояние Входные данные Ожидаемые результаты Реаль- ные резуль- таты
Т-9 1.11.4 (нерабочее состояние) 495 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 495° за 6 минут. Температура держится в диапазоне 493°-497°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-10 1.1.1.4 (нерабочее состояние) 505 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-11 1.1.2 1.2.1.1 2.4.1.1 (нерабочее состояние) клавиша СТАРТ Духовой шкаф включается и нагревается до температуры 350° за 5 минут. Температура держится в диапазоне 348°-352°. При нагреве на дисплее: ПЕЧЕТСЯ
Т-12 1.1.3.1 • (нерабочее состояние) 250 клавиша ВВОД 450 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 405° за 6 минут. Температура держится в диапазоне 403°-407°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-13 1.1.3.2 запущен Т-5 через 2 минуты после начала нагрева в Т-5 нажать 450 клавиша ВВОД клавиша СТАРТ Духовой шкаф нагревается до 450° меньше чем за 6 минут. Новая температура держится в диапазоне 448°-452°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-14 1.1.4.1 (нерабочее состояние) 410 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 410° за 6 минут. Температура держится в диапазоне 408°-412°. Во время нагрева на дисплее: ПЕЧЕТСЯ
326
Приложение А
ID тестового Схема Предыдущее состояние Входные данные Ожидаемые результаты Р«аль- t4b.Ua резуль- таты
теста
Т-15 1.1.5.1 (нерабочее состояние) 0 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-16 1.1.5.2 (нерабочее состояние) ООО клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-17 1.1.5.3 (нерабочее состояние) 0401 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-18 1.2.1.2 запущен Т-9 через одну минуту после начала нагрева в Т-9 нажать клавишу СТАРТ Поведение духового шкафа никак не изменяется. Т-9 продолжает функционировать, как и ожидалось.
Т-19 1.2.2.1 (нерабочее состояние) клавиша СТАРТ клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-20 1.2.2.2 запущен Т-11 через одну минуту после начала нагрева в Т-11 нажать клавишу СТАРТ клавиша СТАРТ Поведение духового шкафа никак не изменяется. Т-11 продолжает функционировать, как и ожидалось.
Т-21 1.3.1.1 (нерабочее состояние) клавиша ОТМЕНА Никаких действий. Духовой шкаф остается в нерабочем состоянии Дисплей: <пусто>
Т-22 1.3.1.2 запущен Т-2 20 секунд после начала нагрева в Т-2 нажать клавишу ОТМЕНА Духовой шкаф перестает нагреваться и выключается. Дисплей: <пусто>
Т-23 1.3.2.1 (нерабочее состояние) клавиша ОТМЕНА клавиша ОТМЕНА Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: <пусто>
Приложение А
327
Т-24 1.3.2 2 запущен Т-5 20 секунд после начала нагрева Духовой шкаф перестает нагреваться
Т-25 2.1.1.1 (нерабочее в Т-5 нажать клавишу ОТМЕНА клавиша ОТМЕНА клавиша ВРЕМЯ и выключается. Дисплей: спустс» Дисплей: ОШИБКА
Т-26 2.1.1.1 состояние) текущее время должно быть меньше 14:30 (нерабочее НАЧАЛА РАБОТЫ 1430 клавиша ВВОД 199 клавиша ВВОД клавиша ВРЕМЯ ТЕМПЕРАТУРЫ В 14:32 духовой шкаф
Т-27 2.1.1.2 2.1.1.1 1 состояние) текущее время должно быть меньше 14:23 (нерабочее НАЧАЛА РАБОТЫ 1432 клавиша ВВОД 200 клавиша ВВОД клавиша СТАРТ клавиша ВРЕМЯ включается и нагревается до 200° за 4 минуты. Температура держится в диапазоне 198°-202°. Во время нагрева на дисплее' ПЕЧЕТСЯ Дисплей: ОШИБКА
Т-28 2.1.1.2 состояние) текущее время должно быть меньше 13:30 (нерабочее НАЧАЛА РАБОТЫ 1330 клавиша ВВОД 201 клавиша ВВОД клавиша ВРЕМЯ ТЕМПЕРАТУРЫ Дисплей. ОШИБКА
Т-29 2.1.1.2 состояние) текущее время должно быть меньше 14:30 (нерабочее НАЧАЛА РАБОТЫ 1430 клавиша ВВОД 195 клавиша ВВОД клавиша ВРЕМЯ ТЕМПЕРАТУРЫ В 15:06 духовой шкаф
состояние) текущее время должно быть меньше 15:06 НАЧАЛА РАБОТЫ 1506 клавиша ВВОД 205 клавиша ВВОД клавиша СТАРТ включается и нагревается до 205° за 4 минуты. Температура держится в диапазоне 203°-207°. Во время нагрева на дисплее: ПЕЧЕТСЯ
328
Приложение А
примера rd Схема теста Предыдущее состояние Входные данные Ожидаемые результаты Рваль- реэутж- таты
Т-30 2.1.1.3 2.1.5.4 (нерабочее состояние) текущее время должно быть меньше 04:30 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0430 клавиша ВВОД 499 клавиша ВВОД клавиша СТАРТ Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-31 2.1.1.3 2.1.1.4 (нерабочее состояние) текущее время должно быть меньше 09:30 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0930 клавиша ВВОД 500 клавиша ВВОД клавиша СТАРТ В 09:30 духовой шкаф включается и нагревается до 500° за 6 минут. Температура держится в диапазоне 498°-502°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-32 2.1.1.3 (нерабочее состояние) текущее время должно быть меньше 14:30 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1430 клавиша ВВОД 501 клавиша ВВОД Дисплей: ОШИБКА ВРЕМЕНИ
Т-33 2.1.1.4 (нерабочее состояние) текущее время должно быть меньше 20:10 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 2010 клавиша ВВОД 495 клавиша ВВОД клавиша СТАРТ В 20:10 духовой шкаф включается и нагревается до 495° за 6 минут. Температура держится в диапазоне 495°-497°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-34 2.1.1.4 (нерабочее состояние) текущее время должно быть меньше 16:00 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1600 клавиша ВВОД 505 клавиша ВВОД Дисплей ОШИБКА ВРЕМЕНИ
Т-35 2.1.2 (нерабочее состояние) текущее время должно быть меньше 14:05 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1405 клавиша ВВОД клавиша СТАРТ В 14:05 духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°.
Во время нагрева
на дисплее: ПЕЧЕТСЯ
Приложение А
329
примера > Схема теста Предыдущее состояние Входные данные Ожидаемые результаты. Реаль Sr
Т-36 2.1.З.1. 2.2.5.1 (нерабочее состояние) текущее время -11:20 310 клавиша ВВОД клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1130 клавиша ВВОД 455 клавиша ВВОД клавиша СТАРТ В 11:30 духовой шкаф включается и нагревается до 455° за 6 минут. Температура держится в диапазоне 453°—457°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-37 2.1.3.2 запущен Т-35 В 14:15, когда температура духового шкафа достигла 350°, набрать 325 клавиша ВВОД клавиша СТАРТ Духовой шкаф охлаждается до 325°. Во время охлаждения на дисплее: спустс». Температура держится в диапазоне 323°-327°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-38 2.1.4 1 2.5.1.5 (нерабочее состояние) текущее время - 09:07 350 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1215 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Дисплей: отсчет времени начиная с 03:08:00. Духовой шкаф выключается в 12:15 (когда на таймере 00:00:00) и подает звуковой сигнал. Дисплей: спустс»
Т-39 2.1.5.1 (нерабочее состояние) текущее время должно быть меньше 05:00 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0500 клавиша ВВОД 0 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
330
Приложение А
ID тестового примера- Схема теста Предыдущее состояние Входные данные Ожидаемы* результаты резуль- таты
Т 40 2.1.5.2 (нерабочее состояние) текущее время должно быть меньше 02:41 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0241 клавиша ВВОД 000 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-41 2.1.5.3 (нерабочее состояние) текущее время должно быть меньше 15:00' клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1500 клавиша ВВОД 035 клавиша ВВОД Дисплей: ОШИБКА ТЕМПЕРАТУРЫ
Т-42 2.2.1.1.1 (нерабочее состояние) клавиша ВРЕМЯ НАЧАЛА РАБОТЫ клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-43 2.2.1.1.2 (нерабочее состояние) клавиша ВРЕМЯ НАЧАЛА РАБОТЫ клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-44 2.2.1.1.3 (нерабочее состояние) клавиша ВРЕМЯ начала РАБОТЫ клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-45 2.2.1.1.4 (нерабочее состояние) клавиша ВРЕМЯ НАЧАЛА РАБОТЫ клавиша ОТМЕНА Никаких действий. Духовой шкаф остается в нерабочем состоянии.
Дисплей: <пусто>.
Приложение А 331
ID тестового Схема тестя Предыдущее состояние Входные данные Ожидаемые результаты ные тэты*"
Т-46 2.2.1.2.1 (нерабочее состояние) клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1122 клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ Дисплей: ОШИБКА ВРЕМЕНИ
Т-47 2.2.1.2.2 (нерабочее состояние) клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0805 клавиша СТАРТ Дисплей: ОШИБКА ВРЕМЕНИ
Т-48 2.2.1.2.3 (нерабочее состояние) клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 400 клавиша ОТМЕНА Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: спуск»
Т-49 2.2.2.1 (нерабочее состояние) текущее время — 07:00 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0725 клавиша ВВОД клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0720 клавиша ВВОД клавиша СТАРТ В 07:20 духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-50 22.2.2 запущен Т-49 через 30 секунд после начала нагрева вТ-49 нажать клавишу ВРЕМЯ НАЧАЛА РАБОТЫ 0840 клавиша ВВОД клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1200 клавиша ВВОД Поведение духового шкафа не изменяется. Т-49 продолжает функционировать, как и ожидалось
Т-51 2.23.1 22.5.2 (нерабочее состояние) текущее время — 00:00 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 0000 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
332
Приложение А
ID тестового Примера Йсема.|; теста Предыдущее состояние Входные данные Ожидаемые результаты Реаль- ные резуль- Матй^И
Т-52 2.2.3.2 2.2.5.1 (нерабочее состояние) текущее время — 23:58 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 2359 клавиша ВВОД клавиша СТАРТ В 23:59 духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-53 22.4.1 (нерабочее состояние) текущее время должно быть меньше 04:10 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 410 клавиша ВВОД клавиша СТАРТ Дисплей: ОШИБКА ВРЕМЕНИ
Т-54 2.2.52 (нерабочее состояние) текущее время —19:30 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1930 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Во время нагрева на дисплее: ПЕЧЕТСЯ
Т-55 2.25.2 2.3.3.2 2.3.5.1 2.5.1.1 (нерабочее состояние) текущее время -19:30 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1930 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 2359 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348-352°. Дисплей: отсчет времени начиная с 04:29:00. Духовой шкаф выключается в 23:59 (когда на таймере 00:00:00) и подает звуковой сигнал. Дисплей: спустс»
Т-56 22.5.3 (нерабочее состояние) текущее время —10:57 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ 1056 клавиша ВВОД клавиша СТАРТ Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: спустс»
Приложение А
333
Т-57 2.2.6.1 (нерабочее клавиша ВРЕМЯ В 17:30 духовой шкаф
состояние) ОКОНЧАНИЯ включается и нагревается
текущее РАБОТЫ до 350° за 5 минут.
время —16:40 1740 клавиша ВВОД Температура держится
клавиша ВРЕМЯ в диапазоне 348°-352°.
НАЧАЛА РАБОТЫ Дисплей: отсчет времени
1730 начиная с 00:01:00.
клавиша ВВОД клавиша СТАРТ Духовой шкаф выключается в 17:40
(когда на таймере 00:00:00) и подает
звуковой сигнал. / Дисплеи: спустс»
Т-58 2.2.62 (нерабочее клавиша ВРЕМЯ В 18:58 духовой шкаф
состояние) НАЧАЛА РАБОТЫ включается и нагревается
текущее 1825 до 350° за 5 минут.
время -16:40 клавиша ВВОД Дисплей: отсчет времени
клавиша ВРЕМЯ начиная с 00:02:00.
ОКОНЧАНИЯ РАБОТЫ Духовой шкаф
1900 выключается в 19:00
клавиша ВВОД (когда на таймере
клавиша ВРЕМЯ 00:00:00) и подает
НАЧАЛА РАБОТЫ звуковой сигнал.
1858 клавиша ВВОД клавиша СТАРТ Дисплей: спустс»
Т-59 2.3.1.1.1. (нерабочее клавиша ВРЕМЯ Духовой шкаф
состояние) ОКОНЧАНИЯ включается и нагревается
РАБОТЫ до 350° за 5 минут.
клавиша ВВОД клавиша СТАРТ Температура держится в диапазоне 348-352°.
Во время нагрева
на дисплее: ПЕЧЕТСЯ
334
Приложение А
Т-60 2.3.1.1.2 (нерабочее
состояние)
клавиша ВРЕМЯ Духовой шкаф
ОКОНЧАНИЯ включается и нагревается
РАБОТЫ до 350° за 5 минут.
клавиша ВРЕМЯ
НАЧАЛА РАБОТЫ Температура держится
клавиша СТАРТ в диапазоне 348°-352°.
Во время нагрева
на дисплее: ПЕЧЕТСЯ
Т-62 2.2.1.1.4 (нерабочее состояние)
Т-63 2.3.1.2.1 (нерабочее состояние)
Т-64 2.3.1.2.2 (нерабочее
состояние)
Т-65 2.3.1.2.3 (нерабочее
2.3.1.1.3 (нерабочее
состояние)
состояние)
клавиша ВРЕМЯ Духовой шкаф
ОКОНЧАНИЯ РАБОТЫ клавиша СТАРТ включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°.
Во время нагрева на дисплее: ПЕЧЕТСЯ
клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ клавиша ОТМЕНА Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: спустс»
клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 2010 клавиша ВРЕМЯ НАЧАЛА РАБОТЫ Дисплей: ОШИБКА ВРЕМЕНИ
клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1745 клавиша СТАРТ Дисплей: ОШИБКА ВРЕМЕНИ
клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 400 клавиша ОТМЕНА Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: спустс»
Приложение A 'I 335
Т-66 2.3.2.1 (нерабочее клавиша ВРЕМЯ Духовой шкаф
состояние) текущее время -16:00 ОКОНЧАНИЯ РАБОТЫ 1605 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1705 клавиша ВВОД клавиша СТАРТ включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Дисплей: отсчет времени начиная с 01:05:00. Духовой шкаф выключается в 17:05 (когда на таймере 00:00:00) и подает звуковой сигнал. Дисплей: спустс»
Т-67 2.3 2.2 запущен Т-31 В 9:31 (после начала нагрева) нажать клавишу ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1010 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ Поведение духового шкафа не изменяется. Т-31 продолжает функционировать, как и ожидалось.
Т-68 2.3.3.1 (нерабочее состояние) текущее время — 00:00 клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 00001 клавиша ВВОД клавиша СТАРТ Духовой шкаф включается и нагревается до 350°. Дисплей: отсчет времени начиная с 00:01:00. Духовой шкаф выключается в 00:01 (когда на таймере 00:00:00) и подает звуковой сигнал. Дисплей: <пусто>
Т-69 2.3.4.1 (нерабочее состояние) клавиша ВРЕМЯ ОКОНЧАНИЯ Дисплей: ОШИБКА ВРЕМЕНИ
РАБОТЫ
0000
клавиша ВВОД
336
Приложение А
ID тестового Примера Схема **входные данные/ Ожидаемые результаты Реаль- j ные - -'ТЙТЫ
Т-70 2.3.4.2 (нерабочее клавиша ВРЕМЯ Дисплей: ОШИБКА
состояние) ОКОНЧАНИЯ РАБОТЫ 930 клавиша ВВОД ВРЕМЕНИ
Т-71 2.3.5.2 (нерабочее клавиша ВРЕМЯ Никаких действий.
состояние) НАЧАЛА РАБОТЫ Духовой шкаф остается
текущее 1647 в нерабочем состоянии. i
время -14:00 клавиша ВВОД 375 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1647 клавиша ВВОД клавиша СТАРТ Дисплей: спустс»
Т-72 2.3.5.3 (нерабочее клавиша ВРЕМЯ Никаких действий.
состояние) НАЧАЛА РАБОТЫ Духовой шкаф остается
текущее 1648 в нерабочем состоянии.
время -14:00 клавиша ВВОД клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1647 клавиша ВВОД клавиша СТАРТ Дисплей: спустс»
Т-73 2.3.6.1 (нерабочее клавиша ВРЕМЯ Духовой шкаф
состояние) ОКОНЧАНИЯ включается и нагревается
текущее РАБОТЫ до 350°.
время -14:00 1401 клавиша ВВОД Дисплей: отсчет времени
клавиша СТАРТ начиная с 00:01:00.
Духовой шкаф
выключается в 14:01
(когда на таймере
00:00:00) и подает
звуковой сигнал.
Дисплей: спустс»
Приложение А
337
Т-74 2.3.6.2 (нерабочее состояние) текущее время -14:00 клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1400 клавиша ВВОД клавиша СТАРТ Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: <пусто>
Т-75 2.3.3.6 (нерабочее состояние) текущее время —14:01 клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 1400 клавиша ВВОД клавиша СТАРТ Никаких действий. Духовой шкаф остается в нерабочем состоянии. Дисплей: спустс»
Т-76 2.4.1.2 запущен Т-55 через 20 секунд после начала нагрева вТ-55 нажать клавишу СТАРТ Поведение духового шкафа не изменяется. Т-55 продолжает функционировать, как и ожидалось.
Т-77 2.4.21 (нерабочее состояние) текущее время —12:00 клавиша ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 13:00 клавиша ВВОД клавиша СТАРТ клавиша СТАРТ Духовой шкаф включается и нагревается до 350° за 5 минут. Температура держится в диапазоне 348°-352°. Дисплей: отсчет времени начиная с 01:00:00. Духовой шкаф выключается в 13:00 (когда на таймере 00:00:00) и подает звуковой сигнал. Дисплей: спустс»
Т-78 2.4.22 запущен Т-38 через 20 секунд после начала нагрева в Т-38 нажать клавишу СТАРТ Поведение духового шкафа не изменяется. Т-38 продолжает функционировать, как и ожидалось
клавиша СТАРТ
338 Приложение А
Т-79 2.5.1.3 (нерабочее клавиша ВРЕМЯ Поведение духового
состояние) НАЧАЛА РАБОТЫ шкафа не изменяется.
текущее 1400 Духовой шкаф
время -13:00 клавиша ВВОД продолжает оставаться
клавиша СТАРТ в нерабочем состоянии
Подождать 10 даже после того, как
минут, затем наступило время начала
нажать клавишу нагрева (14:00).
ОТМЕНА Дисплей: <пусто>
Т-80 2.5.2.1.2 запущен Т-38 через 2 минуты Духовой шкаф перестает
после начала нагреваться
нагрева вТ-38 и выключается.
нажать Дисплей: спустс»
клавишу ОТМЕНА
Т-81 2.52.2.2 запущен Т-55 через 1 минуту Духовой шкаф перестает
после начала нагреваться
нагрева в Т-55 и выключается,
нажать
клавишу Дисплей: <пусто>
ОТМЕНА
клавиша
ОТМЕНА
Приложение А6
Таблица контрольных проверок для тестовых примеров
с отдельными столбцами для кодов приоритета, входных данных
и результатов теста
Приоритеты Схема тестового примера Данные Результат
1 [R-3] Ручной режим
1.1 [R-4] Температура приготовления
1.1.1 [R-1] Граничные значения
200-500° Ф/Шаг 5° Ф
1.1.1.1 199/200/201
2 1.1.1.2 195/200/205 195
2 1.1.1.3 499/500/501 499 X
1.1.1.4 495/500/505
Приложение А
339
, и у . { '
1 1.1.2 [R-5] По умолчанию 350° Ф ✓
2 1.1.3 Повторный ввод См. ✓
подсписок
1.1.3.1 духовой шкаф не работает 250,405 ✓
1.1.3.2 духовой шкаф нагревается 205, 450 ✓
1 1.1.4 Верные данные 345 ✓
1 1.1.4.1 410 ✓
1.1.5 Неверные данные
1.1.5.1 0
1 1.1.5.2 000 *
1.1.5.3 0410
1.1.5.4 не кратные 5
2 1.1.5.5 отрицательные значения нельзя н/п
выполнить
1.1.5.6 буквенные символы
1.1.5.7 другие клавиши
1.2 [R-8] Команда начала работы
1.2.1 Нет данных/по умолчанию
1.2.1.1 духовой шкаф не работает
1.2.1.2 духовой шкаф нагревается
1.2.2 Повторный ввод
1.2.2.1 духовой шкаф не работает
1.2.2.2 духовой шкаф нагревается
1.3 [R-10] Команда окончания работы
(Клавиша ОТМЕНА)
1.3.1 Нет данных/по умолчанию
1.3.1.1 духовой шкаф не работает
1.3.1.2 духовой шкаф нагревается
1.3.2 Повторный ввод
1.3.2.1 духовой шкаф не работает
1.3.2.2 духовой шкаф нагревается
2 [R-3] Автоматический режим
2.1 [R-4] Температура приготовления
2.1.1 [R-1] Граничные значения
200-500° Ф/ Шаг 5° Ф
2.1.1.1 199/200/201
1 2.1.1.2 195/200/205
195,205 ✓
340 Приложение А
Схема! тестового примера Данные Результат
• 2.1.1,3 499/500/501 2.1.1.4 495/500/505
1 2.1.2 [R-5] Значение по умолчанию 350° Ф 2.1.3 Повторный ввод 2.1.3.1 духовой шкаф не работает 2.1.3.2 духовой шкаф нагревается 2.1.4 Верные данные 2.1.4.1 350 2.1.5 Неверные данные 2.1.5.1 0 2.1.5.2 000 2.1.5.3 035 2.1.5.4 не кратные 5 2.1.5.5 отрицательные значения
2 2.1.5.6 буквенные символы нельзя н/п выполнить 2.1.5.7 другие клавиши 2.2 [R-6] Время начала работы 2.2.1 Нет данных/по умолчанию 2.2.1.1 Не задано число
2 2 2.2.1.1.1 Нажать клавишу ВВОД ✓ 2.2.1.1.2 Нажать клавишу ВРЕМЯ * ОКОНЧАНИЯ РАБОТЫ
2 2.2.1.1.3 Нажать клавишу СТАРТ ✓ 2.2.1.1.4 Нажать клавишу ОТМЕНА 2.2.1.2 После набора чисел не последовало нажатие клавиши ВВОД 2.2.1.2.1 Нажать клавишу ВРЕМЯ ОКОНЧАНИЯ РАБОТЫ 2.2.1.2.2 Нажать клавишу СТАРТ 2.2.1.2.3 Нажать клавишу ОТМЕНА 2.2.2 Повторный ввод
1 2.2.2.1 духовой шкаф не работает 0725,0720 J 2.2.2.2 духовой шкаф нагревается
Приложение А
341
Приоритеты Схема тестового примера Данные Результат
1 1 2 2.2.3 Верныеданные 2.2.3.1 0000 (нижняя граница) 2.2.3.2 2359 (верхняя граница) 2.2.4 Неверные данные 2.2.4.1 410 2.2.4.2 отрицательные значения 2.2.4.3 буквенные символы 2.2.4.4 другие клавиши 2.2.5 Относительно текущего времени 2.2.5.1 текущее время < время начала работы 2.2.5.2 текущее время = время начала работы 2 2.5.3 текущее время > время начала работы 2.2 6 Относительно введенного времени окончания 2.2.6.1 Время начала работы определено после времени окончания 2.2.6.2 Определяется время начала работы, время окончания работы, а затем снова время начала работы 2.3 [R-6] Время окончания работы 2.31 Нет данных/по умолчанию 2.3.1.1 Не задано число 2.3.1.1.1 Нажать клавишу ВВОД 2.3.1.1.2 Нажать клавишу ВРЕМЯ НАЧАЛА РАБОТЫ 2.3.1.1.3 Нажать клавишу СТАРТ 2.3.1.1.4 Нажать клавишу ОТМЕНА текущее = 23:58 начало = 23:59 текущее = 19:30 начало = 19:30 текущее =1 0:57 начало = 10:56 ✓
342
Приложение А
еты Схема тестового примера < Результат
2.3.1.2 После набора чисел не последовало нажатие клавиши ВВОД 2.3.1.2.1 Нажать клавишу ВРЕМЯ НАЧАЛА РАБОТЫ 2.3.1.2.2 Нажать клавишу СТАРТ 2.3.1.2.3 Нажать клавишу ОТМЕНА 2.3.2 Повторный ввод 2.3.2.1 духовой шкаф не работает -
1 2.3.2.2 духовой шкаф нагревается 2.3.3 Верныеданные 2.3.3.1 0001 (нижняя граница)
1 2.3.3.2 2359 (верхняя граница) 2.3.4 Неверные данные 2.3.4.1 0000 2.3.4.2 930 2.3.4.3 отрицательные значения 2.3.4.4 буквенные символы 2.3.4.5 другие клавиши 2.3.5 Относительно времени начала
2 2.3.5.1 время начала работы < время начало = окончания работы 19:30 окончание = 23:59
1 2.3.5.2 время начала работы = время начало = окончания работы 16:47 окончание= 16:47
2 2.3.5.3 время начала работы > время начало = окончания работы 16:48 окончание = 16:47 2.3.6 Относительно текущего времени 2.3.6.1 текущее время < время окончания работы 2.3.6.2 текущее время = время окончания работы
Приложение А
343
1
Приоритеты Схема тестового примера
2.3.6.3 текущее время > время
окончания работы
2.4 [R-7] Команда начала
2.4.1 Нет данных/по умолчанию
2.4.1.1 духовой шкаф не работает
2.4.1.2 духовой шкаф нагревается
2.4.2 Повторный ввод
2.4.2.1 духовой шкаф не работает
2.4.2.2 духовой шкаф нагревается
2.5 [R-11] Закончить приготовление
2.5.1 [R-11] Истекшее время
2.5.1.1 время начала работы задано
2.5.1.2 время начала работы не задано
2.5.1.3 отменить автоматический
режим до того, как начнется
нагрев
2.5.2 [R-11] Команда окончания
(Клавиша ОТМЕНА)
2.5.2.1 Нет данных/по умолчанию
2.5.2.1.1 духовой шкаф
не работает
2.5.2.1.2 духовой шкаф
нагревается
2.5.2.2 Повторный ввод
2.5.2.2.1 духовой шкаф
не работает
2.5.22.2 духовой шкаф
нагревается
ПРИЛОЖЕНИЕ
Приложение Б1
Тестовые примеры, полученные из схемы команд покупателя
ID тестового примера Источник теста Входные данные Ожидаемые результаты Ь’* . Ч ‘ ''Mt-',-' **.-'* Реальные ретуль- таты
ПП-1 1.1.1 Из главного меню: выбрать "Женская одежда" Появляется экран со списком магазинов и перечисляется 3 магазина с женской одеждой
ПП-2 1.1.2 Из главного меню: выбрать "Мужская одежда" Появляется экран со списком магазинов и перечисляется 2 магазина мужской одежды
ПП-3 1.1.3 Из главного меню: выбрать "Детская одежда" Появляется экран со списком магазинов и перечисляется 4 магазина детской одежды
ПП-4 1.1.4 Из главного меню: выбрать "Женская обувь" Появляется экран со списком магазинов и перечисляется 2 магазина с женской обувью
ПП-5 1.1.5 Из главного меню выбрать "Мужская обувь" Появляется экран со списком торговых точек и перечисляется 2 магазина с мужской обувью
ПП-6 ,1.1.6 Из главного меню: выбрать "Цветы" Появляется экран со списком торговых точек и предлагается 1 магазин с цветами
ПП-7 1.1.7 Из главного меню: выбрать "Подарки" Появляется экран со списком магазинов и перечисляется 2 магазина с подарками
346
Приложение Б
ПП-8 1.1.8 Из главного меню: выбрать "Рестораны" Появляется экран со списком магазинов и перечисляется 5 ресторанов
ПП-9 1.2.1 Из главного меню: нажать на кнопку КАРТА нажать на кнопку ПЕЧАТЬ Выдается карта пассажа, размещенная на экране. Выдается печатная копия карты
ПП-1О 1.2.2 Из главного меню: нажать на кнопку КАРТА нажать на кнопку ВЕРНУТЬСЯ НА ПРЕДЫДУЩИЙ ЭКРАН Выдается карта пассажа, размещенная на экране. Возврат к главному меню
ПП-11 12.3 Из главного меню: а) нажать на кнопку КАРТА б) нажать на кнопку ГЛАВНОЕ МЕНЮ а) Выдается карта пассажа, размещенная на экране б) Возврат к главному меню
ПП-12 1 2 4.1 Из главного меню: а) нажать на кнопку КАРТА б) нажать на кнопку СПРАВКА в) нажать на кнопку ВЕРНУТЬСЯ НА ПРЕДЫДУЩИЙ ЭКРАН Выдается карта пассажа, размещенная на экране. Выдается экран справки, предоставляющий информацию о главном меню Возврат к главному меню
ПП-13 1.2.4.2 Из главного меню: а) нажать на кнопку КАРТА б) нажать на кнопку СПРАВКА в) нажать на кнопку ГЛАВНОЕ МЕНЮ Выдается карта пассажа, размещенная на экране. Выдается экран справки, предоставляющий информацию о главном меню. Возврат к главному меню
Приложение Б
347
ПП-14 1.3.1 Из главного меню:
а) нажать на кнопку
СПРАВКА
б) нажать на кнопку
ВЕРНУТЬСЯ НА
ПРЕДЫДУЩИЙ ЭКРАН
ПП-15 1.3.2 Из главного меню:
а) нажать на кнопку
СПРАВКА
б) нажать на кнопку
ГЛАВНОЕ МЕНЮ
ПП-16 2.1.1 Из главного меню:
а) выбрать "Женская
одежда"
б) выбрать в списке
название первого
магазина
в) нажать на кнопку
ПЕЧАТЬ
ПП-17 2.1.2 Из главного меню:
а) выбрать "Мужская
одежда"
б) выбрать название
второго магазина из
списка
в) нажать кнопку
ВЕРНУТЬСЯ НА
ПРЕДЫДУЩИЙ ЭКРАН
Выдается экран справки,
предоставляющий
информацию о главном меню.
Возврат к главному меню
Выдается экран справки,
предоставля ющий
информацию о главном меню.
Возврат к главному меню
Появляется экран со списком
магазинов и перечисляется 3
магазина с женской одеждой.
Выдается карта этого
магазина, размещенная
на экране.
Выдается печатная копия
карты
Появляется экран со списком
магазинов и перечисляется
2 магазина мужской одежды.
Выдается карта этого
магазина, размещенная
на экране.
Возврат к экрану, на котором
перечисляются 2 магазина
мужской одежды
348
Приложение Б
10 Источник тестового теста примера Входные данные Ожидаемые результаты Реальные резуль- таты
ПП-19 2.14.1 Из главного меню: а) выбрать "Женская обувь" Появляется экран со списком магазинов и перечисляется 2 магазина с женской обувью.
6) выбрать в списке первое название магазина в) нажать на кнопку СПРАВКА г) нажать на кнопку ВЕРНУТЬСЯ НА ПРЕДЫДУЩИЙ ЭКРАН Выдается экран справки, предоставляющий информацию относительно меню карты. Возврат к экрану с картой магазина
ПП-20 2.14.2 Из главного меню: а) выбрать "Мужская обувь" б) выбрать в списке второе название магазина в) нажать на кнопку СПРАВКА г) нажать на кнопку ГЛАВНОЕ МЕНЮ Появляется экран со списком торговых точек и перечисляется 2 торговые точки с мужской обувью Выдается карта этого магазина, размещенная на экране. Выдается экран справки, предоста вля ющи й информацию относительно меню карты.
Возврат к главному меню
ПП-21 2.2 Из главного меню: а) выбрать “Цветы" б) нажать на кнопку ГЛАВНОЕ МЕНЮ Появляется экран со списком торговых точек, где представлена 1 торговая точка с цветами. Возврат к главному меню
ПП-22 2.3.1 Из главного меню: а) выбрать "Подарки" б) нажать на кнопку СПРАВКА в) нажать на кнопку ВЕРНУТЬСЯ НА ПРЕДЫДУЩИЙ ЭКРАН Появляется экран со списком магазинов и перечисляется 2 магазина с подарками Выдается экран справки, предоставляющий информацию относительно меню списка магазинов. Возврат к экрану, на котором перечисляется два магазина с подарками
Приложение Б
349
Ю Источник Входные данные примера <,«. . резуль- ; -ч. ' ' 7»™ ? л
ПП-23 2.3.2 Из главного меню: а) выбрать "Рестораны" 6) нажать на кнопку СПРАВКА в) нажать на кнопку ГЛАВНОЕ МЕНЮ Появляется экран со списком магазинов и перечисляется 5 ресторанов. Выдается экран справки, предоставляющий информацию относительно меню списка магазинов. Возврат к главному меню
Приложение Б 2
Тестовые примеры, полученные из прецедентов
Исходное состояние системы Входные данные Ожидаемые результаты — Реаль- ные радуль- таты
го тостового примера Источник тестового примера
П1-1 прецедент №1 Начать тест с главного меню а) выбрать "Мужская одежда" б) выбрать название первого магазина в) нажать кнопку ПЕЧАТЬ а) Появляется список экранов с магазинами и перечисляется два магазина мужской одежды. 6) Выдается карта с этим магазином, размещенная на экране в) Выдается печатная копия карты
п1-2 прецедент №1 расширен ие1а Начать тест с главного меню а) нажать кнопку СПРАВКА б) нажать кнопку ВЕРНУТЬСЯ НА ПРЕДЫДУЩИЙ ЭКРАН а) Выдается экран со справкой, предоставляющий информацию относительно главного меню. б) Возврат к главному меню
п1-3 прецедент №1 расшире- ние 1б Начать тест с главного меню (Нет входных данных: Покупатель хочет найти книжный магазин] В главном меню отсутствует категория торговых точек книги
350 Приложение Б
п1-4 прецедент №1 расшире- ние 2а Начать тест с главного меню а) выбрать "Рестораны" б) нажать кнопку СПРАВКА а) появляется экран со списком торговых точек, на котором перечислено 5 ресторанов. б) выдается экран со справкой относите- льно меню магазина
п1-5 прецедент "Обувь Выбрать "Женская Появляется экран
№1 Лорны" - обувь" со списком торговых
расшире- это точек, на котором
ние 26 неверное перечисляется два
название магазина женской
магазина. обуви, где отсутствует
Начать тест с главного меню магазин "Обувь Лорны"
п2-1 прецедент Перечисле- 1. Выбрать 1. Появляется экран
№2 ны "Подарки" с перечнем магази-
следующие 2. Выбрать нов, на котором
магазины "Сувениры" перечисляются
подарков: 2 магазина
"Сувениры" и "Дом подарков". Начать тест с главного 3. Нажать на кнопку ПЕЧАТЬ с подарками.
4. Нажать на кнопку ВЕРНУТЬСЯ К ПРЕДЫДУЩЕМУ ЭКРАНУ 2. Выдается карта, показывающая размещение магазина "Сувениры".
меню 5. Выбрать "Дом 3. Выдается печатная копия карты.
подарков"
6. Нажать на кнопку 4. Возврат к экрану со
ПЕЧАТЬ списком магазинов, в котором перечис- ляются 2 магазина
с подарками.
5. Выдается карта,
показывающая
размещение магазина
"Дом подарков".
6. Выдается печатная
копия этой карты
Приложение Б 351
пЗ-1 прецедент Начать тест 1. Выбрать "Мужская 1. Появляется список,
№3 сменю админист- ратора одежда" 2. Вписать "Пещера" 3. Ввести размеще- ние магазина на карте 4. Запустить тест № п1-1, чтобы убедиться, что новая торговая точка была добавлена содержащий назва- ние 2 магазинов. 2. Система принимает название магазина. 3. Обновляется карта. 4. Выдается перечень из 3 магазинов, вклю- чая новое название; выдается карта, пока- зывающая расположение нового магазина.
пЗ-2 прецедент Начать тест 1. Создать новую 1. Создается новая
№3 с меню категорию категория.
расши- админист- магазинов "Книги" 2. Система принимает
рение 1а ратора 2. Добавить новую торговую точку "Читальный зал" в категорию "Книги" 3. Ввести размеще- ние магазина на карте 4. Использовать интерфейс поку- пателя, чтобы убе- диться, что новая торговая точка была добавлена название магазина. 3. Обновляется карта. 4. Новая категория "Книги"содержит название нового магазина; выдается карта, показывающая расположение нового магазина
352
Приложение Б
Ю Источник тестового тестового Примера примера ———— —— Исходное Входные данные Ожидаемые результаты Реаль- состояние . ные | та™ :
пЗ-З прецедент Перечне- 1. Выбрать 1. Появляется список.
№3 лены категорию содержащий
расшире- следующие "Подарки" 2 названия
ние 2а магазины 2. Впечатать магазинов.
подарков: "Сувениры" 2. Выдается сообщение
"Сувениры" об ошибке: название
и "Дом подарков". Начать тест с меню админист- ратора уже существует.
пЗ-4 прецедент Одним из 1. Выбрать "Цветы" 1. Появляется список.
№3 перечисле- 2. Впечатать содержащий
расшире- иных . "Цветочный 1 название магазина
ние За магазинов магазин" 2. Система принимает
является "Красная роза". 3. Задать место, которое в данный название магазина. 3. Выдается сообщение
момент занимает об ошибке, место уже
Начать тест торговая точка занято
с меню админист- ратора "Красная роза"
Рекомендуемая литература
[Bach] Bach J. What is Exploratory Testing? And How it Differs from Scripted Testing.
http: //www.statisfice.com/articles /what_is_et.htm
[Bamford 93] Bamford R., Deibler W.J. Comparing. Contrasting ISO 9001 andSIE Capability
Maturity Model COMPUTER, IEEE Computer Society, Vol 26, No 10, October, 1993.
[Bamford 97] Bamford R., Deibler W.J. The Application of ISO 9001 to Software Development.
The ISO 9000 Handbook (third edition) (R. W. Peach, ed.), McGraw-Hill, 1997.
[Bamford 98] Bamford R., Deibler W.J. Hybrid MultiModel Assessment - When the CMM Meets
ISO 9001. CROSSTALK —The Journal of Defense Software Engineering, Vol. 11,
No. 9, September, 1998.
[Beizer 84] Beizer B. Software System Testing and Quality Assurance, Van Nostrand Rienhold
Company, 1984.
[Beizer 90] Beizer B. Software Testing Techniques (second edition), Van Nostrand Rienhold
Company, 1990.
[Beizer 95] Beizer B. Black Box Testing, John Wiley.
[Binder 00] Binder R.V. Testing Object-Oriented Systems: Models, Patterns, andTools,
Addison-Wesley, 2000.
[Black 99] Black R. Managing the Testing Process, Microsoft Press, 1999.
[Boehm 81] Boehm B. Software Engineering Economics, Prentice-Hall, 1981.
[Buckley 96] Buckley FJ. Implementing Configuration Management: Hardware, Software,
and Firmware {second edition), IEEE Computer Society Press, 1996.
[Cockbum 01] Cockburn A. Writing Effective Use Cases, Addison-Wesley, 2001.
[Cohen 97] Cohen D.M., Dalal S.R., Fredman M.L., Patton G.C. TheAETGSystem:
An Approach to Testing Based on Combinatorial Design, IEEE Transactions on Software
Engineering, Vol. 23, No. 7, July, 1997.
[Dumas 99] Dumas J.S., Redish J. A Practical Guide to Usability Testing (revised edition),
Ablex, 1999.
[Dustin 99] Dustin E.R., RashkaJ., Paul J. Automated Software Testing: Introduction,
Management, and Performance, Addison-Wesley, 1999.
[Fagan 86] Fagan M.E. Advances in Software Inspections, IEEE Transactions on Software
Engineering, Vol. SE-12, No. 7, July, 1986.
[Fewster 99] Fewster M., Graham D. Software Test Automation: Effective Use of Test Execution
Tools, Addison-Wesley, 1999.
354
Рекомендуемая литература
[Freedman 90] Freedman D.P., Weinberg G.M. Handbook of Walkthroughs, Inspections,
and Technical Reviews, EvaluatingPrograms, Projects, and Products (third edition),
Dorset House Publishing, 1990.
[Gause 89] Gause D., Weinberg G. Exploring Requirements, Quality Before Design,
Dorset House Publishing, 1989.
[Gilb 93] GilbT., Graham D. Software Inspection, Addison-Wesley, 1993.
[Hamlet 01] Hamlet D., Maybee J. The Engineering ofSoftware, Addison-Wesley, 2001.
[Hetzel 88] Hetzel B. The Complete Guide to Software Testing (second edition),
John Wiley, 1988.
[Humphrey 89] Humphrey W.S. Managing the Software Process, Addison-Wesley.
[IEEE 610.12] ANSI/IEEEStd 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology, IEEE Computer Society Press, 1990.
[IEEE 730] ANSI/IEEE Std 730-1998 IEEE Standard for Software Quality Assurance Plans,
IEEE Computer Society Press, 1998.
[IEEE 828] ANSI/IEEE Std 828-1998 IEEE Standard for Software Configuration Management
Plans, IEEE Computer Society Press, 1998.
[IEEE 829] ANSI/IEEE Std 829-1998 IEEE Standard for Software Test Documentation,
EEE Computer Society Press, 1998,
[IEEE 830] ANSI/IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications, IEEE Computer Society Press, 1998
[IEEE 1008] ANSI/IEEE Std 1008-1987 IEEE Standard for Software Unit Testing,
IEEE Computer Society Press, R1993.
[IEEE 1028] ANSI/IEEEStd 1028-1997 IEEE Standardfor Software Reviews’,
IEEE Computer Society Press, 1997
[IEEE 1058] ANSI/IEEEStd 1058-1998 IEEE Standard for Software Project Management Plans,
IEEE Computer Society Press, 1998.
[IEEE 1233] ANSI/IEEE Std 1233-1998 IEEE Guidefor Developing of System Requirements
Specifications, IEEE Computer Society Press, 1998.
[IEEE 12207] ANSI/EIA12207 Industry Implementation on International Standard ISO/IEC
12207:1995 (ISO/IEC) Standardfor Informational Technology
[ISO 9000-3] ISO 9000-3 Quality management and quality assurance standards - Part3: Guidelines
for the application of ISO 9001 to the development, supply and maintenance of software.
International Organization for Standardization (ISO), 1991.
[ISO 9001:1994] ISO 9001 Quality system - Model for quality assurance in design, development,
production, installation and servicing (second edition), International Organization
for Standardization (ISO), 1994.
Рекомендуемая литература
355
[ISO 9001:2000] ISO 9001 Quality management systems-Requirements, International
Organization for Standardization (ISO), 2000.
[ISO 12207] International Organization for Standardization & International
Electromechanical Commission Informational Technology: Software Life Cycle Processes
(ISO 12207), International Organization for Standardization (ISO)/ International
Electromechanical Commission, 1995.
[Kaner 99] Kaner C., Falk J., Nguyen H.Q. Testing Computer Software (second edition),
John Wiley, 1999.
[Kehoe 96] Kehoe R., Jarvis A. 750 9000-3: A Toolfor Software Product and Process Improvement,
Springer, 1996.
[Kit 95] Kit E. Software Testing in the Real World: Improving the Process, Addison-Wesley, 1995.
[Leon 00] Leon A. A Guide to Software Configuration Management, Artech House, 2000.
[Leveson 95] Leveson N.G. Safeware: System Safety and Computers, Addison-Wesley, 1995.
[Marick 95] Marick B. The Craft of Software Testing: Subsystems Testing Including Object-Based
and Object-Oriented Testing, Prentice-Hall, 1995.
[McCabe 82] McCabe TJ. Structured Testing: A Software Testing Methodology Usingthe Cydomatic
Complexity Metric, National Bureau of Standards Special Publication 500-99,1982.
[McConnell 98] McConnell S. Software Project Survival Guide, Microsoft Press, 1998.
[McGregor 01] McGregor J.D., Sykes D.A Practical Guide to Testing Object-Oriented Software,
Addison-Wesley, 2001.
[Mikkelson 97] Mikkelson T., Pherigo S. Practical Software Configuration Management,
Prentice-Hall, 1997.
[Moore 98] Moore J. W. Software Engineering Standards: A User's Road Map,
IEEE Computer Society, 1998.
[Myers 76] Myers GJ. Software Reliability, Principles and Practices, John Whiley, 1976.
[Myers 79] Myers GJ. The Art of Software Testing,John Wiley, 1979.
[Nguyen 01] Nguyen H.Q. Testing Applications on the Web: Test Planning for Internet-Based
Systems, John Wiley, 2001.
[Paulk 93] Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Modelfor
Software, Version 1.1, (CMU/SEI-93-TR-24), Carnegie Mellon University, 1993.
[Paulk 94] Paulk M.C. A Comparison of ISO 9001 and the Capability Maturity Modelfor Software,
(CMU/SEI-93-TR-24), Carnegie Mellon University, 1994.
[Pfleeger 01] Pfleeger S.L. Software EngineeringTheory and Practice (second edition),
Prentice-Hall, 2001.
[Pressman 01] Pressman R.S. Software Engineering: A Practitioner's Approach (fifth edition),
McGraw-Hill, 2001.
[Robertson 99] Robertson S., RobertonJ. Mastering the Requirements Process, Addison-Wesley.
356
Рекомендуемая литература
[Rothman 99] Rothman J., Lawrence В. Testing in the Dark, Software Testing and Quality
Engineering, March/April, 1999;
http: / / www j rothman.com/Papers/Pragmaticstrategies.html
[Rubin 94] Rubin J. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective
Tests, John Wiley, 1994.
[Schmauch 94] Schmauch C.H. ISO 9000for Software Developers, ASQC Press, 1994.
[Schmidt 00] Schmidt M.E.C. Implementing the IEEE Software Engineering Standards,
SAMS, 2000.
[Segue 00] Segue Software Gain Confidence: The e-Business Reliability Survival Guide,
Segue Software, 2000.
[Shoemaker 99] Shoemaker D., Jovanovic V. Engineering a Better Software Organization,
Quest Publishing House, 1999.
[Splaine 01] Splaine S., Jaskiel S.P., Savoia A. The Web Testing Handbook, Software Quality
Engineering, 2001.
[Wiegers 96] Wiegers K.E. Creating A Software Engineering Culture,
Dorset House Publishing, 1996.
Предметный указатель
А
анализ
граничных значений, 115
компоненты риска, 255
покрытие ветвей, 173
покрытие условий, 173
покрытие утверждений, 173
покрытия, 172
степени риска, 255
д
действующее лицо, 190
диаграмма
контекста, 48
переходов, 153
К
категории тестов, 56
верные данные, 56; 58
неверные данные, 56; 58
нет данных, 56,57
повторное выполнение, 56; 57
потери мощности, 56; 60
применение, 62
сброс, 56; 59
создание напряжений, 56; 61
тестирование характеристик, 56, 62
класс, 18S
дочерний,188
инкапсуляция, 188
коренной, 188
наследование, 188
открытые члены, 188
классы эквивалентности, 124
компараторы, 289
конечный автомат, 153
конфигурационный менеджмент, 45; 277
м
матрица
перекрестных ссылок, 183
прослеживаемости, 183; 270
риска, 257
тестовых примеров, 181
метод
схем, 48; 52
теории графов, 45
тестирование ортогонального
массива, 204
методы сокращенного
документирования, 132
н
наращиваемый подход, 23
О
обеспечение качества, 279
аудит, 279
ознакомления, 280
пересмотр, 280
среда тестирования, 281
цикл разработки ПО, 279
объект, 188
ожидаемый результат, 51
отчет о неполадках, 45
оценка
календарного плана, 81
схемы, 79
п
планирование тестов, 180
прецеденты, 197
приоритеты тестов, 102
проведение теста, 160
проектные ограничения, 51
358
Предметный указатель
проектный менеджмент, 276
Р
расстановка приоритетов, 253
расширенный набор тестов, 169
регрессионный тест, 246
С
сложные данные, 174
сокращенный набор тестов, 169
составление документации, 110
среда выполнения тестов, 200, 206
стадии тестирования, 23
анализ тенденций, 23; 28
базовый тест, 23; 26
граничные оценки, 24; 35
изучение, 23; 25
инвентаризация, 23; 30
комбинирование элементов, 24; 34
ошибочные данные, 24; 43
создание напряжений, 24; 44
стандарты, 294
ANSI/IEEEStd 100-1987 (R1993), 301
ANSI/IEEE Std 730-1998, 301
ANSI/IEEEStd 829-1998,301
IEEE/EIA 12207, 295
ISO 9001, 296
ISO/IEC 12207, 298
модель SW-CMM®, 303
T
таблицы
использование, 105
описание тестов, 142
переходов, 154
решений, 165
состояний, 154;181
тестовая документация, 109
формат № 1, 111
формат №2, 113
формат №3, 119
формат №4, 124
тестирование
автоматизация, 288
безопасность, 286
восстановления, 285
загрузки, 285
конфигурационное, 285
на совместимость, 285
надежности, 285
наследования, 204
одобрения, 287
отчет, 291
планирование, 287
под нагрузкой, 286
поэлементное, 283
практичности, 286
сборки, 284
системы, 285
удобство обслуживания, 256
установки, 285
функциональных возможностей, 285
характеристик, 255
тестирование Web-ориентированных
приложений
анализ информации, 219
базы данных, 240
безопасность, 238
надежность и доступность, 227
определение задач Web-узла, 217
план отката, 248
сквозные транзакции, 239
тестирование загруженности, 234
тестирование
масштабируемости, 234
тестирование навигации, 219
тестирование практичности, 216
тестирование совместимости, 224
тестирование ссылок, 221
тестирование форм, 221
тестирование характеристик, 229
типы посетителей, 234
функциональные возможности и
практичность, 214
тестирование объектно-
ориентированного ПО, 187
определение тестовых
примеров, 189
поэлементное тестирование, 200
прецеденты, 197
сравнение с процедурным ПО, 188
терминология, 188
тестирование ортогональных
массивов, 200
тестовый драйвер, 206
тестовый пример, 143
ID тестового примера, 86
автоматизация, 150
входные данные, 86
определение IEEE, 143
предыдущее состояние, 86
создание, 85
элемент схемы, 86
требования, 275
выделение, 49
прослеживаемость, 296
типы, 50
Прелметный указатель 359
У
управление
версиями, 278
внесением изменений, 45; 278
выпусками, 278
конфигурацией, 278
процессами, 278
тестами, 180
упрощенный формат документации, 96
уровни тестирования, 161
Ф
факторы покрытия, 174
Научно-популярное издание
Луиза Тамре
Введение в тестирование программного
обеспечения
Литературный редактор
Верстка
Художественный редактор
Корректоры
П.Н. Мачуга
М.А. Смолина
Е.П. Дынник
З.В. Александрова, Л.А. Гордиенко
О.В. Мишутина
Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д. 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.
Подписано в печать 06.01.2003. Формат 70x100/16.
Гарнитура NewBaskerville. Печать офсетная.
Усл. печ. л. 29,67. Уч.-изд. л. 17,01.
Тираж 3500 экз. Заказ № 2184.
Отпечатано с диапозитивов в ФГУП “Печатный двор”
Министерства РФ по делам печати,
телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.
Разработка программного обеспечения/тестирование
Введение в тестирование программного обеспечения
Луиза Тамре
Тестирование играет жизненно важную роль в разработке качественного программного
обеспечения. Тем не менее, во многих компаниях, занимающихся разработкой ПО,
процессы тестирования недостаточно организованы, поэтому исполнители вынуждены
трудным путем, пытаясь добиться желаемых результатов. Эта книга написана для того,
чтобы помочь опытным специалистам по тестированию сделать разумный выбор и
повысить эффективность тестирования даже в тех случаях, когда им приходится
сталкиваться с неполными или противоречивыми требованиями.
В этой книге:
Последовательность вхождения в процесс тестирования с акцентом на ключевых
функциях
Определение недостающих сведений и проведение адекватного тестирования при
недостаточно четких требованиях
• Изучение различных форматов документации для регистрации тестовых примеров
• Выработка стратегии проектирования тестов на различных уровнях тестируемой системы
• Применение методов тестирования в объектно-ориентированных и Web-ориентирован-
ных приложениях
Воспользовавшись анализом рисков или какой-либо иной схемой расстановки приорите-
тов, разработчики и специалисты по тестированию смогут подобрать наиболее эффектив-
ный набор тестов. На основе рассматриваемых идей и примеров можно значительно
упростить процесс преобразования сведений о продукте в тестовые примеры, что в итоге
приведет к повышению качества создаваемого ПО.
Об авторе:
Луиза Тамре — специалист по вопросам качества программного обеспечения из г. Энн-Арбор (штат Мичит».
США). С 1983 года она работает в области тестирования программного обеспечения, в частности для Мичлс-
терства обороны США и компании General Motors. Л. Тамре — дипломированный специалист в обеспечении
качества ПО (CSQE), она также входит в комиссию Международной конференции по тестированию компью-
терного программного обеспечения.
ВИЛЬЯМС
Издательский дом "Вильямс’
www.wilhamspublishing.com
ADDISON-WESLEY
A Pearson Education book WWW.aW.COrn/CSGnC]