Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
308 Определение требований ТМТ TMT-RD-10 3.1.31. Экспорт результатов прогона тестов Эта опция предоставляет возможность экспортировать выбранные результаты прогона тестов в файлы ASCII-формата с разделителями-запятыми. Опция активизируется после выбора элемента "Export/Test Results" ("Экспорт/Результаты прогона тестов") из меню "Utilities" ("Утилиты"). После этого отображается список всех доступных результатов прогона тестов. Для выполнения экспорта пользователю достаточно просто дважды щелкнуть на имени требуемого результата прогона тестов. Далее выдается запрос на указание целевого местоположения и имени выходного файла. Пользова тель должен иметь возможность отправлять данные экспорта на принтер. 3.1.32. Справка Для каждого элемента меню должен существовать экран с соответствующей справочной информа цией по возможностям, реализуемым тем или иным элементом меню. Содержимое справочного эк рана всецело зависит от меню, из которого он вызывается. 3.1.33. Многопользовательские функциональные возможности Данный программный продукт должен функционировать в коммерческой, сетевой среде и обеспечи вать множеству пользователей возможность одновременного тестирования нескольких проектов. Следует убедиться, что продукт поддерживает приемлемые показатели производительности при работе с ним нескольких тестировщиков. Проведенные маркетинговые исследования дают возмож ность заключить, что одновременная работа до пяти тестировщиков должна будет приветствоваться сообществом пользователей. 3.2. Требования к внешнему интерфейсу Какие-либо требования к аппаратным или программным внешним интерфейсам отсутствуют. 3.3. Требований к производительности В этом разделе описывается требования к производительности программного продукта ТМТ. 3.3.1. Возможность поддержки нескольких пользователей Продукт ТМТ предназначен для функционирования в многопользовательском режиме. Поскольку продукт разрабатывается впервые и ориентируется на внутреннее применение, он не рассчитан на перегрузки, характерные для коммерческих Web-приложений. Тем не менее, важно удостовериться в возможности поддержки пяти клиентских сеансов без существенного снижения производительности. Во время тестирования должна оцениваться производительность для случаев работы от одного до пяти пользователей, которые одновременно выполняют как аналогичные, так и различные виды работ. 3.4. Ограничения проекта В начальной версии продукта ТМТ используется приложение базы данных Oracle. Проектирование и реализация программного продукта должны быть совместимы с Oracle. 3.5. Структура данных Проект структуры данных для тестового случая показан в таблице 3.1, а активные индексы — в таблице 3.2. 3.6. Атрибуты Какие-либо требования к сопровождению и переносимости отсутствуют. 3.7. Прочие требования Прочие требования в настоящий момент отсутствуют. 309 Определение требований ТМТ TMT-RD-10 Таблица 3.1. Структура данных для представления тестового случая Описание поля Project Name (Имя проекта) Requirement Satisfied (Удовлетворенное требование) Requirement Name (Имя требования) Test Identifier (Идентификатор теста) Test Name (Имя теста) Expected Result (Ожидаемый результат) Hardware Required (Требуемое оборудование) Test Setup (Настройка теста) Configuration Name (Имя конфигурации) Test 1 Name (Имя теста 1) Test 1 Steps (Шаги теста 1) Test 2 Name (Имя теста 2) Test 2 Steps (Шаги теста 2) Test 3 Name (Имя теста 3) Test 3 Steps (Шаги теста 3) Test 4 Name (Имя теста 4) Test 4 Steps (Шаги теста 4) Test 5 Name (Имя теста 5) Test 5 Steps (Шаги теста 5) User ID (Идентификатор пользователя) Date (Дата) Time Start (Время начала) Time Stop (Время окончания) Time Needed (Требуемое время) Pass(Пройден) Fail (Отказ) Fail Detail (Детали отказа) Blocked (Заблокирован) Blocked Detail (Детали блокировки) Post Test Cleanup (Очистка по завершении теста) Метка поля PRJNAM REQSAT REQNAM TSTID TSTNAM XRSLT HWREQ TSTSUP CFGNUM TST1NUM TST1STP TST2NUM TST2STP TST3NUM TST3STP TST4NUM TST4STP TST5NUM TST5STP UID DATRUN START STOP TIMREQ PASS FAIL FLDTL BLCKD BLKDTL CLNUP Тип поля Character (Символьный) Numeric (Числовой) Character Character Character Character Character Character Character Character Character Character Character Character Character Character Character Character Character Character Date (Дата) Time (Время) Time Numeric Logical (Логический) Logical Character Logical Character Character Размер поля 20 8 20 20 20 50 256 256 20 20 256 20 256 20 256 20 256 20 256 20 8 4 4 4 T/F (истина/ ложь) T/F 256 T/F 256 50 310 Определение требований ТМТ TMT-RD-10 Таблица 3.2. Индексы в базе данных тестовых случаев Описание индекса Requirement Satisfied (Удовлетворенное требование) Test Identifier (Идентификатор теста) User ID (Идентификатор пользователя) Pass (Пройден) Fail (Отказ) Blocked (Заблокирован) Имя индекса REQSAT.IDX TSTID.IDX UID.IDX PASS.IDX FAIL.IDX BLCKD.IDX Ссылки Ссылки отсутствуют Приложение 1 —Список аббревиатур API—Application Programming Interface (Интерфейс программирования приложений) ASCII — American Standard Code for Information Interchange (Американский стандартный код обмена информацией) CDR — Compact Disc Recordable (Записываемый компакт-диск) HTML — Hypertext Markup Language (Язык гипертекстовой разметки) ISO — International Organization for Standardization (Международная организация по стандартизации) РРС — Power PC (Процессор Power PC) RISC — Reduced Instruction Set Computing (Сокращенный набор вычислительных инструкций) SQL-—Structured Query Language (Язык структурированных запросов) SPARC — Scalable Processor Architecture (Масштабируемая процессорная архитектура) TCL — Tool Command Language (Инструментальный командный язык) ТМТ — Test Management Toolkit (Набор инструментальных средств управления тестированием) Х86 — Процессоры серии Intel Приложение 2 — Определение терминов Отсутствует Приложение 3 — Адреса электронной почты утверждающих лиц От: ЧакД. Клуш (Chuck D. Klout) [cdklout@tmtco] Отправлено: Среда 9/7/01 14:23 Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco Копия: marketing@tmtco; customersupport@tmtco Тема: Определения требований к приложению ТМТ, версия 1.0 Уважаемые члены команды, Я просмотрел определения требований для первой версии приложения ТМТ и пришел к выводу, что этот документ весьма точно соответствует требованиям, выдвинутым нашими заказчиками. Я одоб ряю определения требований к приложению ТМТ (код TMT-RD-10) в том виде, в котором они были составлены. Я должен собираюсь встретиться со своими заказчиками на будущей неделе с целью уточнения списка обязательного оборудования. Я также хочу получить своевременный ответ, чтобы выполнить пересмотр плана тестирования. Заранее благодарен, Чак 311 Определение требований ТМТ TMT-RD-10 Чак Д. Клут Директор отдела маркетинга ТМТСО cdklout@tmtco.com От: Сьюзи Перл (Suzie Perl [spent@tmtco.com] Отправлено: Четверг 9/9/2001 09:30 Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco Копия: marketing@tmtco; customersupport@tmtco Тема: Определение требований ТМТ 1.0 Привет всем, Хорошая работа! Я просмотрела определение требований к приложению TMT-RD-10 (версия 8) и одобрила его использование в процессе разработки в том виде, в каком оно было записано. С наилучшими пожеланиями, Сьюзи Сюзанна Перл Менеджер, отдел программирования ТМТСО От: Брит Гейтер (Bret Gater) [bgater@tmtco.com] Отправлено: Четверг 9/9/2001 Кому: Крис Браун [cbrown@tmtco]; test@tmtco; development@tmtco Копия: marketing@tmtco; costumersupport@tmtco Тема: Определение требований ТМТ 1.0 Уважаемые члены команды, Я просмотрел определение требований TMT-RD-10 (версия 8) и одобрил его использование коман дой тестирования в том виде, в котором он написан. С наилучшими пожеланиями, Брит Брит Гейтер Менеджер, отдел программирования 312 Пример плана тестирования В главе 3 отмечалось, что эффективное планирование тестирования является ключе вым фактором успеха проекта, оцениваемого в терминах соответствия графику и бюджету. Для удобства на рис. 14.1 повторно приводится диаграмма из главы 3, кото рая отражает действия, выполняемые во время составления планов тестирования. Исходными данными для процесса планирования являются документы описания требований, которые были подробно описаны в главе 2. В главе 13 приводится доста точно реальный пример документа определения требований. Результатом выполне ния действий, связанных с планированием, является план тестирования. Этот план представляет собой документ или набор документов, которые должны периодически просматриваться командами тестировщиков, разработчиков и менеджерами про граммных продуктов. В плане тестирования идентифицируются ресурсы, которые необходимо привлечь для тестирования программного продукта, определяются цели тестирования, методика его проведения, а также указывается, какие результаты и промежуточные продукты должны подвергаться тестированию. Содержимое и фор мат плана тестирования обсуждаются в главе 3, а пример план тестирования предла гается в данной главе. Полезные рекомендации по разработке плана тестирования содержатся в доку менте IEEE Standard 829, IEEE Standard for Software Test Documentation (дополнительные сведения вопросу можно найти в главе 3). Конечно, можно воспользоваться и аль тернативным форматом, но п р и этом не следует забывать относительно включения всех необходимых документов, диктуемых стандартом IEEE. В этой главе в качестве основы для примера плана тестирования был выбран стандарт IEEE Standard 829. Структура плана тестирования, определяемая стандартом, включает в себя 16 компонент: 1. Идентификатор плана проведения испытаний 2. Введение 3. Компоненты, которые должны тестироваться 4. Характеристики и свойства, которые должны тестироваться 5. Характеристики и свойства, которые не должны тестироваться 6. Подход 7. Критерий успешных и неудачных испытаний 8. Критерий приостановки испытаний и требования возобновления испытаний 9. Выходные результаты тестов 10. Задачи тестирования 314 Часть III. Процесс быстрого тестирования 11. Требования окружающей среды 12. Распределение ответственности 13. Подбор кадров и подготовка персонала 14. График работ 15. Риски и непредвиденные обстоятельства 16. Утверждение плана проведения испытаний. -> На этап проектирования и реализация тестов Рис. 14.1. Действия, выполняемые при составлении планов тестирования. При внимательном изучении приведенного выше списка можно заметить, чем tie является стандартный план тестирования. Он не суть детализованная спецификация, описывающая методику выполнения тестов, а также не место фиксации результатов тестирования. В некоторых организациях, занимающихся тестированием, с содер жимым плана комбинируются один и большее количество указанных выше пунктов. В результате появляется возможность собрать и сохранить всю документацию в одном месте. Подобный подход вполне оправдан. Тем не менее, в этой книге рассматрива ется модульный набор документов, который в дальнейшем подпадает под стандарт. В оставшейся части главы предлагается пример плана тестирования, подготов ленный для вымышленного набора инструментальных средств управления тестиро ванием (Test Management Toolkit, ТМТ). В качестве исходных данных для плана тес тирования служит документ определения требований к продукту ТМТ, который был рассмотрен в главе 13. План тестирования программного продукта ТМТ ТМТ-ТР-10 Идентификатор документа: ТМТ-ТР-10 Версия: 0.8 Авторы: Крис Браун (Chris Brown) Джеймс Варне (James Barnes) Набор инструментальных средств управления тестированием Версия 1.0 План тестирования Хронология версий Версия Дата Автор Описание 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 09/02/2001 09/03/2001 09/03/2001 09/05/2001 09/06/2001 09/07/2001 09/09/2001 09/10/2001 Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Крис Браун Джеймс Варне Эскиз плана тестирования для документа определения требований: TMT-RS-05 Доводка и синхронизация с: TMT-TS-05 Начато построение детализованных тестовых случаев Построение тестовых случаев завершено. Окончательная доводка Основная доводка и очистка, дополнительные тестовые случаи, заключительный формат Заключительная синхронизация с TMT-RS-07, добавлены тесты многопользовательского режима В раздел 2 добавлены тестовые случаи для многопользовательского режима Конфигурации тестов, оценка трудозатрат и календарный график Отдел Утверждено Дата утверждения Маркетинга Программирования Тестирования Чак Д. Клут (Chuck D. Klout), директор отдела маркетинга Сюзанна Перл (Suzanna Perl), менеджер отдела программирования Брит Гейтер (Bret Gater), менеджер отдела тестирования 09/11/2001 09/12/2001 09/12/2001 315 План тестирования программного продукта ТМТ ТМТ-ТР-10 Содержание 1. Введение 316 2. Тестируемые элементы 317 3. Свойства, которые должны тестироваться 317 4. Свойства, которые не должны тестироваться 318 5. Применяемый подход 318 5.1. Тестирование свойств 318 5.2. Регрессионное тестирование 318 5.3. Установка продукта 319 5.4. Резервное копирование и восстановление 319 5.5. Тестирование графического интерфейса пользователя 319 6. Критерий успешных и неудачных испытаний 319 7. Критерий приостановки испытаний и требования возобновления испытаний 319 8. Выходные результаты тестов 320 9. Задачи тестирования 320 10. Конфигурации тестов 323 11. Распределение ответственности 323 12. Подбор кадров и подготовка персонала 324 13. Календарный график 324 14. Риски и непредвиденные обстоятельства 325 Ссылки 325 Приложение 1 —Список аббревиатур 326 Приложение 2 — Определение терминов 326 Приложение 3 — Сообщения электронной почты от утверждающих лиц 326 От: Чак Д. Клут (Chuck D. Klout) [cdklout@tmtco] 326 От: Сьюзи Перл (Suzie Perl [spent@tmtco.com] 327 От: Брит Гейтер (Bret Gater) [bgater@tmtco.com] 327 1. Введение Назначение этого документа состоит в детализации процедур тестирования, которые должны атте стовать функциональные возможности программного продукта ТМТ. Свойства, на которые произво дятся ссылки в этом документе, находятся в документе определения требований, именуемого "На бор инструментальных средств управления тестированием, Определение требований". Документ, определяющий требования, имеет идентификатор TMT-RD-10 и находится под управлением систе мы контроля документов на Web-сайте: http//www .tmtcointernal.com/usr/www/docstores/desiqn/reauirements/TMT-RD-10.doc 316 План тестирования программного продукта ТМТ ТМТ-ТР-10 2. Тестируемые элементы Ниже приводится перечень высокоуровневый список компонентов продукта, на которые имеются ссылки в этом план тестирования: • Тестируемая версия — Этот элемент связан с функциональными возможностями программного продукта ТМТ версии 1.0. • Исправление ошибок — Это первая версия профаммного продукта, поэтому в ней отсутствуют исправления ошибок, которые найдены в предыдущих версиях, требующих тестирования. Все найденные и исправленные в ходе тестирования ошибки должны быть верифицированы. • Носитель, на котором распространяется продукт— Начальная версия профаммного продукта может выгружаться из Web-сайта разработчиков. Заказчики, заинтересованные в приобретении этого продукта, могут получать его на CD-ROM. Тестированию должны подвергаться оба типа рас пространения. • Документы для конечного пользователя — Предполагается, что клиент и сервер находятся в различных местах, поэтому требуются два отдельных модуля, для каждого из которых должна предусматриваться собственная программа установки. Документы для конечного пользователя, такие как руководство пользователя, руководство по установке и примечания к версиям, могут вы гружаться отдельно, чтобы заказчик мог иметь возможность просматривать системные требования и процедуры установки. Для достижения приемлемого уровня точности должно выполняться тес тирование процессов установки и создания пакетов, а также просматриваться соответствующая документация. 3. Свойства, которые должны тестироваться Для того чтобы удостовериться в том, что программный продукт ТМТ удовлетворяет требованиям, указанным в спецификации требований ТМТ, необходимо протестировать следующие требования: • Требование 3.1.1. Пользовательский интерфейс • Требование 3.1.2. Навигация • Требование 3.1.3. Аутентификация пользователей — клиент • Требование 3.1.4. Аутентификация пользователей — администратор • Требование 3.1.5. Текущие проекты • Требование 3.1.6. Завершенные проекты • Требование 3.1.7. Создание нового проекта • Требование 3.1.8. Изменение проекта • Требование 3.1.9. Удаление проекта • Требование 3.1.10. Создание тестового случая или набора • Требование 3.1.11. Изменение тестового случая или набора • Требование 3.1.12. Удаление тестового случая или набора • Требование 3.1.13. Отображение теста • Требование 3.1.14. Отображение тестового набора • Требование 3.1.15. Прогон одиночного теста • Требование 3.1.16. Прогон тестового набора • Требование 3.1.17. Создание списка прогона • Требование 3.1.18. Выполнение списка прогона • Требование 3.1.19. Сводный отчет по ошибкам • Требование 3.1.20. Результаты тестирования — одиночный тест • Требование 3.1.21. Результаты тестирования — тестовый набор или список прогона 317 План тестирования программного продукта Т М Т ТМТ-ТР-10 Требование 3.1.22. Создание матрицы прослеживаемости Требование 3.1.23. Резервное копирование тестовых случаев Требование 3.1.24. Резервное копирование тестовых наборов Требование 3.1.25. Резервное копирование результатов прогона тестов Требование 3.1.26. Восстановление тестовых случаев Требование 3.1.27. Восстановление тестовых наборов Требование 3.1.28. Восстановление результатов прогона тестов Требование 3.1.29. Экспорт тестовых случаев Требование 3.1.30. Экспорт тестовых наборов Требование 3.1.31. Экспорт результатов прогона тестов Требование 3.1.32. Получение справки Требование 3.1.33. Многопользовательские функциональные возможности 4. Свойства, которые не должны тестироваться Ниже приводится список функциональных свойств и/или конфигураций системы, которые не должны тестироваться. • В план тестирования не включается описание функциональных возможностей и процесса установ ки реляционной базы данных. Предполагается, что база данных установлена и функционирует. Также предполагается, что структура данных точно определена и содержит обязательные поля с типами и размерностью, которые определены в спецификации требований. Эти требования под робно излагаются в руководствах по подготовке и установке. • В плане не предусматривается непосредственное тестирование Web-сервера (Apache или IIS). • План тестирования не предполагает интенсивного расширенного тестирования архитектуры кли ент/сервер. Функциональные возможности, обеспечивающие работу в многопользовательском ре жиме, тестируются через работу пяти реальных пользователей, что определено минимальной многопользовательской конфигурацией. 5. Применяемый подход Подход, предполагающий всеобъемлющее тестирование, включает тестирование свойств, регресси онное тестирование, тестирование процесса установки продукта, резервного копирования и восста новления, а также тестирование графического интерфейса пользователя. В этом разделе подробно описывается каждый упомянутый вид тестирования. 5.1. Тестирование свойств Все свойства, описанные в определении требований TMT-RD-10 должны тестироваться на выбран ных комбинациях конфигураций клиент/сервер, описанных в разделе 10. Тестирование свойств предполагает функциональное и отрицательное тестирование (попытка выполнения операций и ввода данных, не предусмотренных разработчиками). 5.2. Регрессионное тестирование Поскольку это первая версия программного продукта, отсутствует потребность в верификации на предмет проявления ошибок, устраненных в предыдущих версиях. Данная версия программы отли чается тем, что ошибки, исправленные на этапе системного тестирования, не разрушают ранее ра ботоспособные функциональные возможности. Для регрессионного тестирования первой версии программного продукта предлагается следую щий подход: 318 План тестирования программного продукта ТМТ ТМТ-ТР-10 • Исправление ошибок должно осуществляться по мере их обнаружения. Для каждой программной сборки, переданной в команду тестировщиков, должны прогоняться тесты, что обеспечивает га рантию того, что устраненные ошибки не проявятся снова. Другими словами, в сборке должно проверяться каждое исправление ошибки. • Если программный продукт функционирует устойчиво, а тестовые случаи прошли успешно, перед выполнением просмотром готовности должен быть выполнен последний проход регрессионного тестирования. 5.3. Установка продукта Каждая программная сборка, переданная команде тестировщиков, устанавливается в соответствии с процедурой установки, которую будет использовать заказчик. Однако для каждой сборки модули клиента и сервера устанавливаются только на подмножестве всех возможных комбинаций платформ и операционных систем, которые указаны в спецификации требований. Предполагается, что успеш ная установка на одной платформе UNIX создает прецедент для успешной установки для всех ос тальных UNIX-подобных платформ. То же справедливо и для платформ Windows. Этот подход ут вержден у заказчика (см. сообщение электронной почты утверждающего лица из отдела маркетинга). 5.4. Резервное копирование и восстановление Функционирование резервного копирования и восстановления тестируется для проектов, тестовых случаев, тестовых наборов и результатов прогона тестов. При этом должны использоваться как фи зические, так и логические устройства, которые являются автономными либо сетевыми. Сетевое резервное копирование является наиболее предпочтительным сценарием для заказчика, поэтому ему будет уделяться повышенное внимание. 5.5. Тестирование графического интерфейса пользователя При тестировании графического интерфейса продукта ТМТ используется следующий подход: • Графический интерфейс пользователя тестируется в браузерах Netscape Navigator и Microsoft Internet Explorer. При этом должен быть просмотрен полный состав интерфейса, а также протести рованы возможности навигации в обоих браузерах. • Все действия по тестированию выполняются в ручном режиме. • Все дефекты отслеживаются и устраняются с помощью корпоративной системы отслеживания дефектов. Такой подход предполагает нахождение недоработок в графическом интерфейсе поль зователя в ходе проведения различных оценок после завершения работы над проектом. 6. Критерий успешных и неудачных испытаний Критерий успешных и неудачных испытаний для каждого тестового случая описывается через ожи даемые результаты. Если после прогона тестового случая получен ожидаемый результат, значит, тест пройден успешно. Если же после прогона теста ожидаемый результат не получен, считается, что тест потерпел неудачу. Если же тест не может быть прогнан вследствие блокирующей ошибки в сборке, результат тестирования именуется "заблокированным". Для того чтобы продукт ТМТ смог успешно пройти фазу системного тестирования, 100% тестов из данного плана тестирования должны выполниться, по крайней мере, на одной программной сбор ке. 100% всех прогнанных тестов должны завершиться успешно, а по завершении тестирования не должна остаться неустраненной ни одна серьезная ошибка. 7. Критерий приостановки испытаний и требования возобновления испытаний Если хотя бы одна фундаментальная функциональная возможность оказывается неработоспособ ной, например, установка и запуск программы, тестирование должно быть приостановлено до тех пор, пока соответствующая функциональность не станет доступной. Поиск катастрофических ошибок 319 План тестирования программного продукта ТМТ ТМТ-ТР-10 должен продолжаться, если только обнаруженные ошибки не столь серьезны и не заблокировано 50% и более тестовых случаев. Если тестирование оказывается приостановленным, команды разра ботчиков и тестеров должны ежедневно встречаться с целью достижения прогресса в возобновлении испытаний. Встречи продолжаются до тех пор, пока не будет достигнуто согласие возобновить про цесс тестирования. 8. Выходные результаты тестов Перечисленные ниже элементы представляют собой рабочие продукты, которые появляются в ре зультате выполнения тестирования: • Данный план тестирования. • Матрица прослеживаемое™ требований. • Документ со спецификациями тестов. • Отчеты по результатам прогона тестов. • Ежедневные обновления состояния тестирования, направляемые менеджерам по тестированию и разработке. • Отчеты о дефектах (ошибках). За примечания по версии несут ответственность разработчики; однако, примечания по версии долж ны просматриваться и одобряться командой тестирования до пересмотра готовности продукта. 9. Задачи тестирования Ниже перечислены задачи, которые должны выполняться во время тестировании продукта ТМТ: • Выполнение тестирования процесса установки продукта. • Прогон тестов для свойств и построение отчета об ошибках. • Верификация фактов устранения ошибок. • Выполнение тестов резервного копирования и восстановления. • Выполнение тестирования графического интерфейса пользователя. • Ведение обзоров по ошибкам. • Подготовка отчетов о состоянии тестов. • Написание отчета по результатам тестирования. В этом разделе оцениваются временные затраты (в человеко-часах), которые потребуются для вы полнения перечисленных выше задач. Эти оценки трудозатрат основаны на прошедшем 09.01.2001 сеансе Wideband Delphi. Фактором, оказывающим наибольшее влияние на объем времени и ресур сов, которые необходимы для тестирования продукта ТМТ, является количество клиентских и сер верных операционных систем, оговоренное в документе определения требований. Сводку по опера ционным системам можно найти в таблице 9.1. 320 План тестирования программного продукта ТМТ ТМТ-ТР-10 Таблица 9.1. Клиентские и серверные операционные системы Клиентская операционная система Microsoft Windows - Windows 85 - Windows 98 - Windows ME - Windows XP - Windows NT 3.51 и выше - Windows 2000 Apple - MAC OS 9.x и выше Серверная операционная система Microsoft Windows - Windows NT 3.51 и выше UNIX - Sun Solaris 2.6 и выше - HPUX 10.x и выше - Open BSD - AIX 2.4.1. и выше - SCO Open Desktop - Linux Red Hat 6.x и выше Как показано в таблице 9.1, имеется семь клиентских и семь серверных операционных систем, упо мянутых в определении списка требований. При этом необходимо, чтобы использовалась только одна операционная система из списка, куда входят Windows NT, Solaris 2.6, OS9.X и Linux 6.x. Следо вательно, существует 49 возможных комбинаций клиентских и серверных операционных систем. Установка каждой комбинации системы клиент/сервер требует в среднем 5 часов. Общее время, необходимое для тестирования процесса установки продукта, составляет 5 х 49 = 245 часов, или около 30 рабочих дней. Обратите внимание, что процесс предполагает установку операционной сис темы, приложения реляционной базы данных и приложения ТМТ для клиента и сервера, а также установку клиентского браузера. Если запланировать тестирование свойств и резервного копирова ния для всех 49 комбинаций, объемы времени, необходимого для тестирования ТМТ, возрастут до немыслимых размеров. Вследствие больших временных затрат на тестирование всех возможных комбинаций, во время выполнения тестирования процесса установки продукта используют лишь подмножество комбинаций клиент/сервер, которое показано в таблице 9.2. Таблица 9.2. Выбранные комбинации операционных систем, применяемые при тестировании установки продукта Комбинация 1 2 3 4 5 6 7 Клиентская операционная система - Windows 95 - Windows 98 - Windows ME - Windows XP - Windows NT 3.51 - Windows 2000 - MAC OS 9.0 Серверная операционная система - Windows NT 3.51 - Sun Solaris 2.6 -HPUX 10.1 - Open BSD - AIX 2.4.1 и выше - Linux 6.5 - SCO Open Desktop Сокращение количества комбинаций должно приводить к экономии ресурсов, затрачиваемых на тес тирование продукта. В данном случае на тестирование уходит 35 человеко-часов, что значительно меньше 245 часов, необходимых для проверки всех комбинаций. И все же, количество комбинаций, приведенных в таблице 9.2, остается довольно-таки большим применительно к тестированию свойств и резервного копирования/восстановления. Для тестирования свойств и резервного копиро- 321 План тестирования программного продукта ТМТ ТМТ-ТР-10 вания/восстановления количество комбинаций клиент/сервер может быть сокращено до двух конфи гураций (см. таблицу 9.3). Таблица 9.3. Выбранные комбинации операционных систем, применяемые при тестировании свойств и резервного копирования/восстановления Комбинация 1 2 Клиентская операционная система - Windows 98 - Windows 2000 Серверная операционная система - Sun Solaris 2.6 - Linux 6.5 Предполагая что использование выделенных комбинаций операционных систем, которые показаны в таблицах 9.2 и 9.3, в таблице 9.4 приводятся оценки трудозатрат для каждого цикла тестирования приложения ТМТ. Обратите внимание, что одиночный цикл тестирования включает выполнение все го набора запланированных тестов на кандидате на программную сборку. Для тестирования прило жения ТМТ необходимо воспользоваться тремя циклами тестирования, поэтому общие трудозатраты сводятся к утроенному объему трудозатрат, перечисленных в таблице 9.4. Таблица 9.4. Оценки трудозатрат для каждого цикла тестирования Задача Тестирование процесса установки продукта Прогон тестов свойств и построение отчетов по ошибкам Верификация исправлений ошибок Тесты резервного копирования и восстановления Тестирование графического интерфейса пользователя Отчет о состоянии тестирования Ведение обзоров по ошибкам Итого Время (часы) 35 16 24 24 16 16 8 139 322 План тестирования программного продукта ТМТ ТМТ-ТР-10 10. Конфигурации тестов Диаграмма для тестовой конфигурации #1, показанная на рис. 10.1, будет использоваться во время тестирования свойств, резервного копирования/восстановления и графического интерфейса пользо вателя. В этой тестовой конфигурации присутствуют два сервера и пять клиентов, причем серверы и клиенты подключены к общей сети. Тестовая конфигурация #1 основывается на выделенных комби нациях операционных систем клиент/сервер, которые приведены в таблице 9.3. Предполагается, что тес товая конфигурация #1 будет первичной конфигурацией, используемой во время верификации ошибок. Несмотря на то что на рис. 10.1 это явно не показано, все серверы и клиенты выполняют приложение баз данных Oracle как систему реляционных баз данных, которая задействована в продукте ТМТ. Это ограничение тестовой конфигурации должно быть включено в примечания по версии. Предполагается, что при будущем тестировании будут использоваться другие системы управления базами данных. Также на рисунке явно не указано, что в качестве приложения браузера для клиентов 1, 3 и 5 выбран Internet Explorer, а для клиентов 2 и 4 - Netscape Navigator. На рис. 10.2 показана диаграмма для тестовой конфигурации #2. Эта конфигурация предназначена для тестирования процесса уста новки продукта, но при необходимости может использоваться и для другого тестирования. Обратите внимание, что тестовая конфигурация #2 является единственной, которая поддерживает тестирова ние на платформе Apple Macintosh. 11. Распределение ответственности В этом разделе обсуждается ответственность за тестирование на организационном уровне; здесь не рассматриваются роли и ответственность отдельных инженеров по тестированию, поскольку это служит материалом следующего раздела. Ответственность команды разработки • Объединение тестируемых свойств на этапе их создания. • Выполнение комплексных испытаний на свойствах перед их упаковкой в форме сборки для коман ды тестирования. • Подготовка программных сборок для команды тестирования в сроки, устанавливаемые на ежене дельных собраниях команд разработки и тестирования. • Помощь тестировщикам в обосновании результатов тестирования и, при необходимости, в харак- теризации ошибок, чтобы в систему отслеживания дефектов вводились точные отчеты. • Устранение ошибок, информация о которые введена в систему отслеживания дефектов. 323 План тестирования программного продукта ТМТ ТМТ-ТР-10 • Подготовка примечаний по версии для тех ошибок, которые не устранены в версии, поставленной заказчику. • Реализация обходного пути "малого влияния на заказчика" для тех ошибок, которые не были уст ранены, но упоминаются в примечании по версии. Ответственность команды тестирования • Прогон запланированных тестов и ввод сообщений об ошибках в систему отслеживания дефектов в случае получения аномальных результатов. • Помощь разработчикам в воспроизведении ошибок. • Ведение регулярных обзоров ошибок на этапе системных испытаний. Обзоры должны составлять ся еженедельно, если только команды тестирования и разработки не придут к выводу, что отчеты необходимо составлять чаще. • Проверка успешности устранения ошибок, которая позволяет удостовериться в том, что исправ ленное программное обеспечение демонстрирует ожидаемое поведение (удовлетворяет опреде ленным требованиям). • Подготовка еженедельных отчетов о состоянии процесса тестирования и обнаружении ошибок. • Подготовка отчета по результатам прогона тестов в конце этапа системных испытаний. Резюме этого отчета будет присутствовать в обзоре степени готовности продукта. Резюме должно вклю чать в себя определение, достигнут ли критерий завершения тестирования, обозначенный в разделе 6. 12. Подбор кадров и подготовка персонала Роли и ответственности персонала во время тестирования приложения ТМТ показаны в таблице 12.1. Д. Нгуен (D. Nguyen) должен обучиться администрированию баз данных Oracle, а К. Тейлор (С. Taylor), новичок в компании, должна пройти внутренние курсы обучения по тестированию программ ного обеспечения "Software Testing 101", руководимые Дж. Барнсом (J.Barnes). Все обучение должно завершиться до передачи разработчиками первой программной сборки в команду тестирования. Таблица 12.1. Персонал тестеров Сотрудник Дж. Варне Д. Нгуен С. Скефиди К. Тейлор Б. Вилер Должность Руководитель отдела тестирования Тестировщик Тестировщик Тестировщик Разработчик Ответственность Координация тестирования, построение отчетов и тестирование свойств Установка продукта и платформы тестирования Тесты резервного копирования/восстановления Тесты графического интерфейса пользователя Тестирование модулей комплексные испытания, исправление ошибок Доступность 100 % 100% 50% 50% 100 % 13. Календарный график Календарный график системного тестирования продукта ТМТ показан в таблице 13.1. Испытание герметичности, показанное на графике, выполняется во время предварительного знакомства с про граммным обеспечением. В течение этого испытания обеспечивается обнаружение в приложении основных блокирующих ошибок, а также дефектов в конфигурациях тестов и тестовых случаях. Ис пытание герметичности должно состоять из подмножества тестовых случаев установки и свойств. 324 План тестирования программного продукта ТМТ ТМТ-ТР-10 Таблица 13.1. Календарный график тестирования продукта ТМТ Задача Установка и отладка тестовых конфигураций #1 и #2 Испытание герметичности на предварительной сборке Цикл тестирования #1 Цикл тестирования #2 Цикл тестирования #3 Пересмотр степени готовности Дата начала 10/1 10/15 10/22 22/5 11/19 12/3 Дата завершения 10/12 10/19 11/2 11/16 11/30 12/3 Предполагается, что тестирование модулей и комплексные испытания были реализованы до уста новки тестовой конфигурации #1 и все катастрофические ошибки, обнаруженные в ходе этого тести рования, устранены до начала стадии системного тестирования. 14. Риски и непредвиденные обстоятельства В таблице 14.1 перечислены риски, связанные с процессом тестирования продукта ТМТ, вместе с оценочными значениями вероятностей их возникновения, влиянием и кратким описанием плана смягчения этого влияния. Таблица 14.1. Идентификация рисков и меры по смягчению их воздействия Риск Написание тестовых случаев для процесса резервного копирования скорее всего задержится, поскольку разработка подсистемы резервного копирования еще не завершена, а созданный прототип выявил серьезные проблемы. К. Тейлор может отсутствовать на работе в течение всего ноября по семейным обстоятельствам. Ее отсутствие привело бы к смещению графика на 2 дня в каждом тестовом цикле. Контракт на обслуживание сети завершился, а его возобновление находится на стадии переговоров. Если контракт не будет возобновлен до начала тестирования, то календарный график может не выполняться из-за возможных проблем с сетью. Вероятность 75% 50% 20% Влияние Основное Незначи тельное Незначи тельное Смягчение влияния Руководитель команды тестирования должен постоянно принимать участие во встречах разработчиков и по мере получения новой информации пересматривать тестовые случаи. Один из разработчиков графического интерфейса, Р. Карини (R. Carini), согласился выполнить его тестирование, а С. Скефиди должен подготовить обзор результатов прогона тестов, если Тейлор будет отсутствовать. Необходимо отслеживать состояние контракта на обслуживание и обратить внимание руководства на возможный риск, если соглашение не будет достигнуто до начала испытаний герметичности. 325 План тестирования программного продукта ТМТ ТМТ-ТР-10 Ссылки Chris Brown, Test Management Toolkit, Requirements Definition (Набор инструментальных средств управления тестированием, Определение требований). Документ TMT-RD-10, который размещает ся под управлением системы контроля документов по адресу: http://www.tmtcointemal.corn/usr/www/docstores/desian/reauirements/TMT-RD-10.doc Приложение 1 — Список аббревиатур API — Application Programming Interface (Интерфейс программирования приложений) ASCII — American Standard Code for Information Interchange (Американский стандартный код обмена информацией) CDR — Compact Disc Recordable (Записываемый компакт-диск) HTML — Hypertext Markup Language (Язык гипертекстовой разметки) ISO — International Organization for Standardization (Международная организация по стандартизации) PPC — Power PC (Процессор Power PC) RISC — Reduced Instruction Set Computing (Сокращенный набор вычислительных инструкций) SQL — Structured Query Language (Язык структурированных запросов) SPARC — Scalable Processor Architecture (Масштабируемая процессорная архитектура) TCL — Tool Command Language (Инструментальный командный язык) ТМТ — Test Management Toolkit (Набор инструментальных средств управления тестированием) Х86 — Процессоры серии Intel Приложение 2 — Определение терминов Отсутствует Приложение 3 — Сообщения электронной почты от утверждающих лиц От: ЧакД. Клуш (Chuck D. Klout) [cdklout@tmtco] Отправлено: Среда 9/11/01 16:40 Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco Копия: marketing@tmtco; customersupport@tmtco Тема: План тестирования ТМТ, версия 1.0 Уважаемые члены команды, Во-первых, я хочу выразить благодарность команде за напряженную работу по написанию требова ний и плана тестирования для данной версии программного продукта. Я утверждаю план тестирова ния ТМТ-ТР-10, версия 8, в том виде, в котором он написан. Я встречался с нашими заказчиками для определения обязательного перечня сертифицированного оборудования для данной версии программного продукта. Утверждения, проведенные в плане тес тирования в связи с предполагаемой совместимостью с ограниченным числом комбинаций операци онных систем, имеют смысл. В связи с этим мы можем продолжать работы с сокращенным списком оборудования и операционных систем, на который имеются ссылки в разделах 9 и 10 при рассмот рении конфигураций тестов. Такая комбинация аппаратного и программного обеспечения покрывает и те конфигурации, которые заказчики используют в настоящее время, так и те, которые планируется установить в будущем. Спасибо, Чак 326 План тестирования программного продукта ТМТ ТМТ-ТР-10 Чак Д. Клут Директор отдела маркетинга ТМТСО cdklout@tmtco.com От: Сьюзи Перл (Suzie Perl [spent@tmtco.com] Отправлено: четверг 9/12/2001 09:30 Кому: Крис Браун (Chris Brown) [cbrown@tmtco]; development@tmtco Копия: marketing@tmtco; customersupport@tmtco Тема: План тестирования ТМТ 1.0 Привет всем, Хорошая работа! Я просмотрела план тестирования ТМТ-ТР-10, версия 8, для первой версии ТМТ и утверждаю его в том виде, в котором он написан. С наилучшими пожеланиями, Сьюзи Сюзанна Перл Менеджер, отдел программирования ТМТСО От: Брит Гвйтер (Bret Gater) [bgater@tmtco.com] Отправлено: четверг 9/12/2001 7:30 Кому: Крис Браун [cbrown@tmtco]; test@tmtco; development@tmtco Копия: marketing@tmtco; costumersupport@tmtco Тема: План тестирования ТМТ 1.0 Уважаемые члены команды, Я просмотрел план тестирования ТМТ-ТР-10, версия 8, и утверждаю его использование командой тестирования в том виде, в котором он написан. С наилучшими пожеланиями, Брит Брит Гейтер Менеджер, отдел программирования 327 В главе 4 упоминалось, что процесс создания сценариев э ф ф е к т и в н ы х тестовых слу чаев состоит из двух частей. Исходя из предположения, что непротиворечивые оп ределения требований готовы, а план тестирования в соответствие с требованиями составлен, разработка тестовых случаев сводится к выполнению следующих этапов: • Проектирование тестов • Разработка детализованных тестовых процедур • Верификация и отладка тестовых процедур. Этот общий подход можно применять для тестов, выполняемых как в ручном, так и в автоматическом режимах; реально получается так, что сначала лучше разработать и отладить процедуры вручную, а затем добавить возможности автоматизации. На рис. 15.1 показана диаграмма, отображающая действия по проектированию и разработке тестов. Первичными входными данными для процесса разработки явля ется набор документов, описывающие план тестирования, который обсуждался в гла ве 3. В плане тестирования предлагается подход, а также определяется круг задач, которые должны быть решены в ходе тестирования. Потребуется определить архи тектуру тестов, что означает определение, по меньшей мере, тестовых наборов. Кро ме того, необходимо будет определить набор тестовых конфигураций, на которые будут ориентироваться создаваемые тесты. Пример плана тестирования был пред ставлен в предыдущей главе. Результатом действий по проектированию и разработке тестов является набор просмотренных и отлаженных тестовых случаев, готовых для использования в сис темных и приемочных испытаниях. Тестовые случаи должны отображаться на требо вания, сформулированные заказчиком. О н и должны обеспечивать хорошее покры тие за счет тестирования, по меньшей мере, всех высокоприоритетных требований, а в идеале — абсолютно всего перечня требований. Тестовые случаи также должны осуществлять хорошее покрытие кода путем прохода большинства, если не всех, ло гических ветвей кода. Если в распоряжение специалиста по тестированию поступают спецификация требований и план тестирования, он может приступить к проектированию тестов. Этот процесс связан с подготовкой следующих действий: • Определение целей тестирования • Определение входных данных, необходимых для прогона каждого теста Примеры проектирования и разработки тестов |