тест план. План тестирования
 Скачать 0.68 Mb.
|
|
<Название компании> <Имя проекта> План тестирования Версия <1.0> [Примечание: Следующий шаблон предоставляется для использования с Rational Unified Process-. Текст, заключенный в квадратные скобки и выделенный синим курсивом (style=InfoBlue), включен в качестве руководства для автора и должен быть удален перед публикацией документа. Абзац, введенный в этом стиле, будет автоматически установлен в обычный (стиль=основной текст).] [Чтобы настроить автоматические поля в Microsoft Word (которые отображают серый фон при выборе), выберите «Файл»> «Свойства» и замените поля «Заголовок», «Тема» и «Компания» соответствующей информацией для этого документа. После закрытия диалогового окна автоматические поля можно обновить по всему документу, выбрав «Правка»> «Выбрать все» (или Ctrl-A) и нажав F9, или просто щелкните поле и нажмите F9. Это должно быть сделано отдельно для верхних и нижних колонтитулов. Alt-F9 будет переключаться между отображением имен полей и их содержимого. Дополнительные сведения о работе с полями см. в справке Word.] Перевод: английский - русский - www.onlinedoctranslator.com <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> лист регистраций изменений Свидание Версия Описание Автор <дд/ммм/гг> <хх> <детали> <имя> Конфиденциально -<Название компании>, 2015 г. Страница 2 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> Оглавление 1. Введение 4 1.1 Цель 1.2 Предыстория 1.3 Область применения 1.4 Идентификация проекта 4 4 4 5 2. Требования к тесту 5 3. Стратегия тестирования 5 3.1 Типы тестирования 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.2 Инструменты 5 5 6 7 8 9 10 11 12 13 14 16 17 18 4. Ресурсы 19 4.1 Роли 4.2 Система 19 20 5. Вехи проекта 21 6. Результаты 21 6.1 Тестовая модель 6.2 Протоколы испытаний 6.3 Отчеты о дефектах 21 21 21 Приложение Задачи проекта 22 Конфиденциально -<Название компании>, 2015 г. Страница 3 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> План тестирования 1. Введение 1.1 Цель Этот документ плана тестирования для поддерживает следующие цели: • [Определить существующую информацию о проекте и компоненты программного обеспечения, которые необходимо протестировать. • Перечислите рекомендуемые требования к тесту (высокий уровень). • Рекомендовать и описывать используемые стратегии тестирования. • Определите необходимые ресурсы и оцените усилия по тестированию. • Перечислите готовые элементы тестового проекта.] 1.2 Предыстория [Введите краткое описание объекта тестирования (компоненты, приложение, система и т. д.) и его целей. Включите такую информацию, как основные функции и возможности, его архитектуру и краткую историю проекта. Этот раздел должен состоять всего из трех-пяти абзацев.] 1.3 Область применения [Опишите этапы тестирования — например, модульное, интеграционное или системное — и типы тестирования, которые будут рассмотрены в этом плане, такие как функциональное или производительное. Предоставьте краткий список характеристик и функций объекта тестирования, которые будут или не будут тестироваться. Перечислите любые предположения, сделанные во время разработки этого документа, которые могут повлиять на дизайн, разработку или реализацию тестирования. Перечислите любые риски или непредвиденные обстоятельства, которые могут повлиять на проектирование, разработку или внедрение тестирования. Перечислите любые ограничения, которые могут повлиять на дизайн, разработку или реализацию тестирования] Конфиденциально -<Название компании>, 2015 г. Страница 4 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 1,4 Идентификация проекта В таблице ниже указаны документация и доступность, использованная для разработки план испытаний: [Примечание: удалите или добавьте элементы по мере необходимости.] Документ (и версия/дата) Создано или Доступный Получено или Рассмотрено Автор или Ресурс Заметки Технические требования -Да нет -Да нет Функциональная спецификация -Да нет -Да нет Отчеты о вариантах использования -Да нет -Да нет План проэкта -Да нет -Да нет Спецификации дизайна -Да нет -Да нет Прототип -Да нет -Да нет Руководства пользователя -Да нет -Да нет Бизнес-модель или поток -Да нет -Да нет Модель данных или поток -Да нет -Да нет Бизнес-функции и правила -Да нет -Да нет Проект или оценка бизнес-рисков -Да нет -Да нет 2. Требования к тесту В приведенном ниже списке указаны те элементы — варианты использования, функциональные требования и нефункциональные требования, — которые были определены в качестве целей для тестирования. Этот список представляет то, что будет тестироваться. [Введите общий список основных требований к тесту.] 3. Стратегия тестирования [Стратегия тестирования представляет рекомендуемый подход к тестированию объекта тестирования. В предыдущем разделе «Требования к тестированию» описывалось, что будет тестироваться, а в этом — как будет тестироваться цель тестирования. Для каждого типа теста предоставьте описание теста и почему он внедряется и выполняется. Если тип теста не будет реализован и выполнен, укажите это в предложении, в котором говорится, что тест не будет реализован или выполнен, и с указанием обоснования, например «Этот тест не будет реализован или выполнен. Этот тест не подходит». Основными соображениями для стратегии тестирования являются методы, которые будут использоваться, и критерий, по которому можно узнать, когда тестирование завершено. В дополнение к соображениям, представленным для каждого теста ниже, тестирование должно выполняться только с использованием известных контролируемых баз данных в защищенных средах. ] 3.1 Типы тестирования 3.1.1 Проверка целостности данных и базы данных [Базы данных и процессы базы данных должны тестироваться как подсистема в Имя>. Эти подсистемы следует тестировать без пользовательского интерфейса объекта тестирования в качестве интерфейса для данных. Дополнительный Конфиденциально -<Название компании>, 2015 г. Страница 5 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> необходимо провести исследование системы управления базами данных (СУБД), чтобы определить инструменты и методы, которые могут существовать для поддержки тестирования, указанного ниже.] Цель теста: [Убедитесь, что методы и процессы доступа к базе данных работают правильно и без повреждения данных.] Техника: - [Вызовите каждый метод доступа к базе данных и процесс, заполняя каждый действительными и недействительными данными или запросами данных. - Проверьте базу данных, чтобы убедиться, что данные были заполнены должным образом, все события базы данных произошли правильно, или просмотрите возвращенные данные, чтобы убедиться, что правильные данные были получены по правильным причинам] Критерии завершения: [Все методы и процессы доступа к базе данных функционируют в соответствии с проектом и без повреждения данных.] Особые соображения: - [Для тестирования может потребоваться среда разработки СУБД или драйверы для ввода или изменения данных непосредственно в базах данных. - - Процессы должны запускаться вручную. Следует использовать небольшие базы данных или базы данных минимального размера (ограниченное количество записей), чтобы увеличить видимость любых неприемлемых событий.] 3.1.2 Функциональное тестирование [Функциональное тестирование цели тестирования должно быть сосредоточено на любых требованиях к тестированию, которые можно напрямую проследить до вариантов использования или бизнес-функций и бизнес-правил. Целью этих тестов является проверка надлежащего приема, обработки и извлечения данных, а также надлежащей реализации бизнес-правил. Этот тип тестирования основан на методах черного ящика; это проверка приложения и его внутренних процессов путем взаимодействия с приложением через графический интерфейс пользователя (GUI) и анализа выходных данных или результатов. Ниже приводится схема тестирования, рекомендуемого для каждого приложения:] Цель теста: [Обеспечить надлежащую функциональность цели тестирования, включая навигацию, ввод данных, обработку и поиск.] Техника: [Выполните каждый вариант использования, поток варианта использования или функцию, используя действительные и недопустимые данные, чтобы проверить следующее: - - Ожидаемые результаты получаются при использовании достоверных данных. При использовании неверных данных отображаются соответствующие сообщения об ошибках или предупреждения. - Каждое бизнес-правило применяется должным образом.] Критерии завершения: - - [Все запланированные тесты выполнены. Все выявленные дефекты устранены.] Особые соображения: [Определите или опишите те элементы или проблемы (внутренние или внешние), которые влияют на реализацию и выполнение функционального теста] Конфиденциально -<Название компании>, 2015 г. Страница 6 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.3 Тестирование бизнес-цикла [Тестирование бизнес-цикла должно эмулировать действия, выполняемые в <Имя проекта> с течением времени. Должен быть определен период, например, один год, и должны быть выполнены транзакции и действия, которые будут происходить в течение года. Сюда входят все ежедневные, еженедельные и месячные циклы, а также события, зависящие от даты, такие как щекотка.] Цель теста [Обеспечить правильное функционирование целевых и фоновых процессов в соответствии с требуемыми бизнес-моделями и графиками.] Техника: [Тестирование будет моделировать несколько бизнес-циклов, выполняя следующие действия: - Тесты, используемые для тестирования функций целевого объекта тестирования, будут изменены или расширены, чтобы увеличить количество раз, когда каждая функция выполняется для имитации нескольких разных пользователей в течение определенного периода. - Все функции, зависящие от времени или даты, будут выполняться с использованием допустимых и недопустимых дат или периодов времени. - Все функции, которые происходят по периодическому расписанию, будут выполняться или запускаться в соответствующее время. - Тестирование будет включать использование действительных и недействительных данных для проверки следующего: - - Ожидаемые результаты получаются при использовании достоверных данных. При использовании неверных данных отображаются соответствующие сообщения об ошибках или предупреждения. - Каждое бизнес-правило применяется должным образом. Критерии завершения: - - [Все запланированные тесты выполнены. Все выявленные дефекты устранены.} Особые соображения: - - [Системные даты и события могут потребовать специальной поддержки Бизнес-модель необходима для определения соответствующих требований и процедур тестирования.] Конфиденциально -<Название компании>, 2015 г. Страница 7 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.4 Тестирование пользовательского интерфейса [Тестирование пользовательского интерфейса (UI) проверяет взаимодействие пользователя с программным обеспечением. Цель тестирования пользовательского интерфейса — убедиться, что пользовательский интерфейс предоставляет пользователю соответствующий доступ и навигацию по функциям объекта тестирования. Кроме того, тестирование пользовательского интерфейса гарантирует, что объекты в пользовательском интерфейсе функционируют должным образом и соответствуют корпоративным или отраслевым стандартам.] Цель теста: [Проверьте следующее: - Навигация по целевому объекту тестирования правильно отражает бизнес- функции и требования, в том числе от окна к окну, от поля к полю и использование методов доступа (клавиши табуляции, движения мыши, клавиши-ускорители). - Оконные объекты и характеристики, такие как меню, размер, положение, состояние и фокус, соответствуют стандартам.] Техника: [Создайте или измените тесты для каждого окна, чтобы проверить правильную навигацию и состояния объектов для каждого окна приложения и объектов.] Критерии завершения: [Каждое окно успешно проверено, чтобы оставаться в соответствии с эталонной версией или в пределах приемлемого стандарта] Особые соображения: [Не все свойства пользовательских и сторонних объектов доступны.] Конфиденциально -<Название компании>, 2015 г. Страница 8 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.5 Профилирование производительности [Профилирование производительности — это тест производительности, в ходе которого измеряются и оцениваются время отклика, скорость транзакций и другие чувствительные ко времени требования. Целью профилирования производительности является проверка выполнения требований к производительности. Профилирование производительности реализуется и выполняется для профилирования и настройки характеристик производительности объекта тестирования в зависимости от таких условий, как рабочая нагрузка или конфигурация оборудования. Примечание. Операции ниже относятся к «логическим бизнес-операциям». Эти транзакции определяются как конкретные варианты использования, которые субъект системы должен выполнять с использованием цели тестирования, например, добавлять или изменять данный контракт.] Цель теста: [Проверить поведение производительности для определенных транзакций или бизнес-функций при следующих условиях: - - нормальная предполагаемая рабочая нагрузка ожидаемая рабочая нагрузка в худшем случае] Техника: - [Используйте процедуры тестирования, разработанные для тестирования функций или бизнес-циклов. - Измените файлы данных, чтобы увеличить количество транзакций, или сценарии, чтобы увеличить количество итераций каждой транзакции. - Сценарии следует запускать на одном компьютере (в лучшем случае для сравнительного анализа одного пользователя, одной транзакции) и повторять с несколькими клиентами (виртуальными или реальными, см. раздел «Особые соображения» ниже).] Критерии завершения: - [Одна транзакция или один пользователь: успешное выполнение тестовых сценариев без каких-либо сбоев и в пределах ожидаемого или необходимого времени, выделенного на транзакцию.] - [Несколько транзакций или несколько пользователей: успешное выполнение тестовых сценариев без каких-либо сбоев и в пределах приемлемого распределения времени.] Особые соображения: [Комплексное тестирование производительности включает фоновую нагрузку на сервер. Для этого можно использовать несколько методов, в том числе: - «Направляйте транзакции» непосредственно на сервер, обычно в форме вызовов языка структурированных запросов (SQL). - Создайте «виртуальную» пользовательскую нагрузку для имитации множества клиентов, обычно нескольких сотен. Для выполнения этой задачи используются инструменты эмуляции удаленного терминала. Этот метод также можно использовать для загрузки сети «трафиком». - Используйте несколько физических клиентов, каждый из которых запускает тестовые сценарии для загрузки системы. Тестирование производительности должно выполняться на выделенной машине или в определенное время. Это обеспечивает полный контроль и точное измерение. Базы данных, используемые для тестирования производительности, должны иметь либо фактический размер, либо одинаково масштабироваться.] Конфиденциально -<Название компании>, 2015 г. Страница 9 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.6 Нагрузочное тестирование [Нагрузочное тестирование — это тест производительности, который подвергает объект тестирования различным рабочим нагрузкам для измерения и оценки характеристик производительности и способности объекта тестирования продолжать нормально функционировать при этих различных рабочих нагрузках. Целью нагрузочного тестирования является определение и обеспечение правильной работы системы за пределами ожидаемой максимальной рабочей нагрузки. Кроме того, при нагрузочном тестировании оцениваются характеристики производительности, такие как время отклика, скорость транзакций и другие вопросы, чувствительные ко времени).] [Примечание: приведенные ниже транзакции относятся к «логическим бизнес-транзакциям». Эти транзакции определяются как определенные функции, которые конечный пользователь системы должен выполнять с помощью приложения, например, добавлять или изменять данный контракт.] Цель теста: [Проверьте время поведения производительности для определенных транзакций или бизнес-кейсов в различных условиях рабочей нагрузки.] Техника: - - [Используйте тесты, разработанные для тестирования функций или бизнес-циклов. Измените файлы данных, чтобы увеличить количество транзакций, или тесты, чтобы увеличить количество транзакций.] Критерии завершения: [Несколько транзакций или несколько пользователей: успешное завершение тестов без каких-либо сбоев и в пределах приемлемого распределения времени.] Особые соображения: - [Нагрузочное тестирование должно выполняться на выделенной машине или в определенное время. Это обеспечивает полный контроль и точное измерение. - Базы данных, используемые для нагрузочного тестирования, должны иметь либо фактический размер, либо одинаково масштабироваться.] Конфиденциально -<Название компании>, 2015 г. Страница 10 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.7 Стресс-тестирование [Стресс-тестирование — это тип теста производительности, который реализуется и выполняется для поиска ошибок из-за нехватки ресурсов или конкуренции за ресурсы. Недостаток памяти или места на диске может выявить дефекты объекта тестирования, которые не проявляются в нормальных условиях. Другие дефекты могут возникнуть в результате конкуренции за общие ресурсы, такие как блокировки базы данных или пропускная способность сети. Стресс- тестирование также можно использовать для определения пиковой рабочей нагрузки, с которой может справиться targetof-test.] [Примечание. Ссылки на транзакции ниже относятся к логическим бизнес-транзакциям.] Цель теста: [Убедитесь, что объект тестирования работает должным образом и без ошибок в следующих стрессовых условиях: - - мало или совсем нет доступной памяти на сервере (RAM и DASD) максимальное фактическое или физически возможное количество клиентов, подключенных или смоделированных - несколько пользователей, выполняющих одни и те же транзакции с одними и теми же данными или учетными записями - объем или сочетание транзакций в худшем случае (см. Тестирование производительности выше). Заметки: Цель стресс-тестирования также может быть сформулирована как выявление и документирование условий, при которых система НЕ работает должным образом. Стресс-тестирование клиента описано в разделе 3.1.11, Тестирование конфигурации.] Техника: - - [Используйте тесты, разработанные для профилирования производительности или нагрузочного тестирования. Чтобы протестировать ограниченные ресурсы, тесты должны выполняться на одной машине, а объем оперативной памяти и DASD на сервере должен быть уменьшен или ограничен. - Для оставшихся стресс-тестов следует использовать несколько клиентов, выполняющих либо одни и те же тесты, либо дополнительные тесты для получения наихудшего объема транзакций или сочетания. Критерии завершения: [Все запланированные тесты выполняются, и указанные ограничения системы достигаются или превышаются без сбоя программного обеспечения или условий, при которых происходит сбой системы, за пределами указанных условий.] Особые соображения: - [Нагрузка на сеть может потребовать сетевых инструментов для загрузки сети сообщениями или пакетами. - DASD, используемый для системы, следует временно уменьшить, чтобы ограничить доступное пространство для роста базы данных. - Синхронизация одновременного доступа клиентов к одним и тем же записям или учетным записям данных.] Конфиденциально -<Название компании>, 2015 г. Страница 11 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.8 Объемное тестирование [Объемное тестирование подвергает объект тестирования воздействию больших объемов данных, чтобы определить, достигнуты ли пределы, приводящие к сбою программного обеспечения. Volume Testing также определяет непрерывную максимальную нагрузку или объем, который может обрабатывать target-oftest в течение заданного периода. Например, если цель тестирования обрабатывает набор записей базы данных для создания отчета, объемный тест будет использовать большую тестовую базу данных и проверять, что программное обеспечение ведет себя нормально и создает правильный отчет.] Цель теста: [Убедитесь, что объект тестирования успешно работает в следующих сценариях с большим объемом: - Максимальное (фактическое или физически пригодное) количество подключенных или смоделированных клиентов, выполняющих одну и ту же бизнес-функцию в наихудшем случае (производительность) в течение длительного периода. - Достигнут максимальный размер базы данных (фактический или масштабированный), и одновременно выполняются несколько запросов или транзакций отчетов.] Техника: - - [Используйте тесты, разработанные для профилирования производительности или нагрузочного тестирования. Следует использовать несколько клиентов, запуская одни и те же тесты или дополнительные тесты для получения наихудшего объема транзакций или сочетания (см. Стресс-тестирование выше) в течение длительного периода. - Создается максимальный размер базы данных (фактический, масштабированный или заполненный репрезентативными данными), и несколько клиентов используются для одновременного выполнения запросов и отчетов о транзакциях в течение длительных периодов времени.] Критерии завершения: - [Все запланированные тесты выполнены, и заданные пределы системы достигнуты или превышены без сбоев программного обеспечения или программного обеспечения.] Особые соображения: [Какой период времени будет считаться приемлемым для условий большого объема, как указано выше?] Конфиденциально -<Название компании>, 2015 г. Страница 12 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.9 Проверка безопасности и контроля доступа [Тестирование безопасности и контроля доступа сосредоточено на двух ключевых областях безопасности: - - Безопасность на уровне приложений, включая доступ к данным или бизнес-функциям Безопасность на уровне системы, включая вход в систему или удаленный доступ к системе. Безопасность на уровне приложений гарантирует, что в зависимости от желаемой безопасности субъекты ограничены определенными функциями или вариантами использования или ограничены в данных, которые им доступны. Например, всем может быть разрешено вводить данные и создавать новые учетные записи, но удалять их могут только менеджеры. При наличии безопасности на уровне данных тестирование гарантирует, что «пользователь первого типа» может видеть всю информацию о клиенте, включая финансовые данные, однако «пользователь номер два» видит только демографические данные того же клиента. Безопасность на уровне системы гарантирует, что только те пользователи, которым предоставлен доступ к системе, могут получить доступ к приложениям и только через соответствующие шлюзы.] Цель теста: - Безопасность на уровне приложений: [ Убедитесь, что субъект может получить доступ только к тем функциям или данным, для которых предоставлены разрешения для его типа пользователя.] - Безопасность на уровне системы: Убедитесь, что доступ к ним разрешен только тем участникам, которые имеют доступ к системе и приложениям. .] Техника: - Безопасность на уровне приложений: [ Определите и перечислите каждый тип пользователя и функции или данные, для которых каждый тип имеет разрешения.] - по [Создайте тесты для каждого типа пользователя и проверьте каждое разрешение, создавая транзакции, характерные для каждого типа пользователя.] - В этом случае убедитесь, что эти дополнительные функции или данные корректно доступны или запрещены. Измените тип пользователя и повторно запустите тесты для тех же пользователей. В каждом - Доступ на уровне системы: [См. Особые соображения ниже] Критерии завершения: [Для каждого известного типа субъекта доступны соответствующие функции или данные, и все транзакции функционируют, как и ожидалось, и выполняются в предыдущих тестах функций приложения.] Особые соображения: [Доступ к системе должен быть рассмотрен или обсужден с соответствующим сетевым или системным администратором. Это тестирование может не потребоваться, поскольку оно может быть функцией сетевого или системного администрирования.] Конфиденциально -<Название компании>, 2015 г. Страница 13 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.10 Проверка отказоустойчивости и восстановления [Тестирование аварийного переключения и восстановления гарантирует, что объект тестирования сможет успешно выполнить аварийное переключение и восстановиться после различных аппаратных, программных или сетевых сбоев с неоправданной потерей или целостностью данных. Тестирование отказоустойчивости гарантирует, что для тех систем, которые необходимо поддерживать в рабочем состоянии, при возникновении условия аварийного переключения альтернативные или резервные системы должным образом «вступают во владение» отказавшей системой без потери данных или транзакций. Тестирование восстановления — это антагонистический процесс тестирования, в котором приложение или система подвергается воздействию экстремальных или смоделированных условий, вызывающих сбой, например сбой ввода-вывода (I/O) устройства или недопустимые указатели и ключи базы данных. Запускаются процессы восстановления, и приложение или система отслеживаются и проверяются, чтобы убедиться, что правильное приложение или система и восстановление данных были достигнуты.] Цель теста: [Убедитесь, что процессы восстановления (ручные или автоматические) правильно восстанавливают базу данных, приложения и систему до желаемого известного состояния. В испытания должны быть включены следующие типы условий: - - - - отключение питания клиента сбой питания сервера прерывание связи через сетевые серверы прерывание связи или потеря питания DASD и/или контроллеров DASD - незавершенные циклы (прерваны процессы фильтрации данных, прерваны процессы синхронизации данных). - - неверный указатель базы данных или ключи неверный или поврежденный элемент данных в базе данных] Конфиденциально -<Название компании>, 2015 г. Страница 14 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> Техника: [Тесты, созданные для тестирования функций и бизнес-циклов, следует использовать для создания серии транзакций. После достижения желаемой начальной контрольной точки необходимо выполнить или смоделировать следующие действия по отдельности: - - Прерывание питания клиента: выключите компьютер. Прерывание питания сервера: смоделируйте или инициируйте процедуры отключения питания сервера. - Прерывание через сетевые серверы: смоделируйте или инициируйте потерю связи с сетью (физически отключите провода связи или отключите сетевые серверы или маршрутизаторы). - Прерывание связи или потеря питания DASD и контроллеров DASD: имитируйте или физически отключите связь с одним или несколькими контроллерами или устройствами DASD. Как только вышеуказанные условия или смоделированные условия достигнуты, должны быть выполнены дополнительные транзакции, и по достижении этого состояния второй контрольной точки должны быть вызваны процедуры восстановления. Тестирование незавершенных циклов использует тот же метод, что и описанный выше, за исключением того, что сами процессы базы данных должны быть прерваны или преждевременно завершены. Для проверки следующих условий требуется, чтобы было достигнуто известное состояние базы данных. Некоторые поля базы данных, указатели и ключи должны быть повреждены вручную и непосредственно в базе данных (с помощью инструментов базы данных). Дополнительные транзакции должны выполняться с использованием тестов из Application Function and Business Cycle Testing и полных циклов.] Критерии завершения: [Во всех вышеперечисленных случаях приложение, база данных и система после завершения процедур восстановления должны вернуться в известное желаемое состояние. Это состояние включает в себя повреждение данных, ограниченное известными поврежденными полями, указателями или ключами, а также отчеты, указывающие на процессы или транзакции, которые не были завершены из-за прерываний.] Особые соображения: - [Тестирование восстановления очень навязчиво. Процедуры отключения кабеля (имитация потери питания или связи) могут быть нежелательными или невыполнимыми. Могут потребоваться альтернативные методы, такие как диагностические программные средства. - Требуются ресурсы из групп «Системы» (или «Операции с компьютером»), «База данных» и «Сеть». - Эти тесты следует запускать в нерабочее время или на изолированной машине.] Конфиденциально -<Название компании>, 2015 г. Страница 15 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.11 Тестирование конфигурации [Тестирование конфигурации проверяет работу объекта тестирования на различных конфигурациях программного и аппаратного обеспечения. В большинстве производственных сред конкретные аппаратные характеристики клиентских рабочих станций, сетевых подключений и серверов баз данных различаются. На клиентских рабочих станциях может быть загружено различное программное обеспечение, например приложения, драйверы и т. д., и в любой момент времени может быть активным множество различных комбинаций, использующих разные ресурсы.] Цель теста: [Убедитесь, что объект тестирования правильно работает на требуемых аппаратных и программных конфигурациях.] Техника: - - [Используйте сценарии функционального тестирования. Открывайте и закрывайте различное программное обеспечение, не связанное с целью тестирования, такое как приложения Microsoft, Excel и Word, либо как часть теста, либо до его начала. - Выполните выбранные транзакции, чтобы имитировать взаимодействие актера с целевым и нецелевым программным обеспечением. - Повторите вышеуказанный процесс, минимизировав доступную обычную память на клиентской рабочей станции.] Критерии завершения: [Для каждой комбинации целевого и нецелевого программного обеспечения все транзакции успешно завершаются без сбоев.] Особые соображения: - [Какое программное обеспечение, не предназначенное для тестирования, необходимо, доступно и доступно на настольном компьютере? - - Какие приложения обычно используются? С какими данными работают приложения; например, большая электронная таблица, открытая в Excel, или 100-страничный документ в Word? - Все системы, сетевое ПО, сетевые серверы, базы данных и т. д. также должны быть задокументированы как часть этого теста.] Конфиденциально -<Название компании>, 2015 г. Страница 16 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.1.12 Тестирование установки [Установочное тестирование преследует две цели. Во-первых, обеспечить возможность установки программного обеспечения в различных условиях, таких как новая установка, обновление, полная или выборочная установка, в нормальных и нештатных условиях. К ненормальным условиям относятся нехватка места на диске, отсутствие прав на создание каталогов и т. д. Вторая цель — убедиться, что после установки программное обеспечение работает правильно. Обычно это означает выполнение ряда тестов, разработанных для функционального тестирования.] Цель теста: Убедитесь, что объект тестирования правильно устанавливается на каждую требуемую конфигурацию оборудования при следующих условиях: - новая установка, новая машина, никогда ранее не устанавливавшаяся с <имя проекта> - обновление, ранее установленный компьютер <Имя проекта>, та же версия - обновление, ранее установленный компьютер <имя проекта>, более старая версия Техника: - [Вручную или разработать автоматизированные сценарии для проверки состояния целевой машины — новой — <имя проекта> никогда не устанавливалось; <имя проекта> уже установлена та же версия или более ранняя версия). - - Запустите или выполните установку. Используя предопределенный подмножество сценариев функционального тестирования, запустите транзакции.] Критерии завершения: Транзакции успешно выполняются без сбоев. Особые соображения: [Какие транзакции должны быть выбраны для проверки уверенности в том, что приложение было успешно установлено и отсутствуют какие-либо основные программные компоненты?] Конфиденциально -<Название компании>, 2015 г. Страница 17 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 3.2 Инструменты Для этого проекта будут использованы следующие инструменты: [Примечание: удалите или добавьте элементы по мере необходимости.] Инструмент Поставщик/внутренний Версия Управление тестированием Отслеживание дефектов Инструмент ASQ для функционального тестирования Инструмент ASQ для тестирования производительности Монитор тестового покрытия или профайлер Управление проектом Инструменты СУБД Конфиденциально -<Название компании>, 2015 г. Страница 18 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 4. Ресурсы [В этом разделе представлены рекомендуемые ресурсы для проекта <Имя проекта>, их основные обязанности, а также их знания или набор навыков.] 4.1 Роли В этой таблице показаны кадровые предположения для проекта. [ПРИМЕЧАНИЕ. Удалите или добавьте элементы по мере необходимости.] Человеческие ресурсы Рабочий Минимум ресурсов рекомендуемые Конкретные обязанности или комментарии (количество выделенных штатных ролей) Менеджер по тестированию, Руководитель тестового проекта Обеспечивает управленческий контроль. Обязанности: - - - обеспечить техническое руководство приобрести соответствующие ресурсы предоставлять управленческую отчетность Дизайнер тестов Определяет, расставляет приоритеты и реализует тестовые примеры. Обязанности: - - - создать план тестирования создать тестовую модель оценить эффективность усилий по тестированию Тестер Выполняет тесты. Обязанности: - - - - выполнять тесты журнал результатов восстановиться после ошибок запросы на изменение документа Администратор тестовой системы Обеспечивает управление и обслуживание тестовой среды и ресурсов. Обязанности: - - администрировать систему управления тестированием устанавливать и управлять доступом к тестовым системам Конфиденциально -<Название компании>, 2015 г. Страница 19 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> Администратор базы данных, Менеджер базы данных Обеспечивает управление и обслуживание среды тестовых данных (базы данных) и активов. Обязанности: - администрирование тестовых данных (база данных) Дизайнер Идентифицирует и определяет операции, атрибуты и ассоциации тестовых классов. Обязанности: - - идентифицирует и определяет тестовые классы идентифицирует и определяет тестовые пакеты Исполнитель Реализует и модульно тестирует тестовые классы и тестовые пакеты. Обязанности: - создает тестовые классы и пакеты, реализованные в тестовой модели 4.2 Система В следующей таблице указаны системные ресурсы для проекта тестирования. [Конкретные элементы тестовой системы в настоящее время полностью не известны. Рекомендуется, чтобы система имитировала производственную среду, уменьшая доступ и размеры базы данных, если и где это уместно.] [Примечание: удалите или добавьте элементы по мере необходимости.] Системные ресурсы Ресурс Имя / Тип Сервер базы данных — Сеть или подсеть — Имя сервера — Имя базы данных подлежит уточнению подлежит уточнению подлежит уточнению Клиентские тестовые ПК — Включить специальные требования к конфигурации подлежит уточнению Тестовый репозиторий — Сеть или подсеть — Имя сервера подлежит уточнению подлежит уточнению ПК для разработки тестов подлежит уточнению Конфиденциально -<Название компании>, 2015 г. Страница 20 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> 5. Вехи проекта [Тестирование <Имя проекта> должно включать в себя действия по тестированию для каждой из усилий по тестированию, указанных в предыдущих разделах. Следует определить отдельные вехи проекта, чтобы сообщать о достижениях в статусе проекта.] Контрольная задача Усилие Дата начала Дата окончания Тест плана Тест дизайна Реализовать тест Выполнить тест Оценить тест 6. Результаты [В этом разделе перечислите различные документы, инструменты и отчеты, которые будут созданы, кем, кому и когда будут доставлены.] 6.1 Тестовая модель [В этом разделе указаны отчеты, которые будут создаваться и распространяться на основе тестовой модели. Эти артефакты в тестовой модели необходимо создать или указать в инструментах ASQ.] 6.2 Протоколы испытаний [Опишите метод и инструменты, используемые для записи и отчета о результатах тестирования и статусе тестирования.] 6.3 Отчеты о дефектах [В этом разделе укажите метод и инструменты, используемые для записи, отслеживания и составления отчетов об инцидентах тестирования и их статусе.] Конфиденциально -<Название компании>, 2015 г. Страница 21 <Имя проекта> Версия: <1.0> План тестирования Дата: <дд/ммм/гг> <идентификатор документа> Приложение Задачи проекта Ниже приведены задачи, связанные с тестом: - Тест плана - определить требования к тесту - оценить риск - разработать стратегию тестирования - определить тестовые ресурсы - создать расписание - создать план тестирования Тест дизайна - подготовить анализ загруженности - определять и описывать тест-кейсы - определить и структурировать процедуры тестирования - просматривать и оценивать тестовое покрытие Реализовать тест - записывать или программировать тестовые сценарии - определить специфичные для теста функциональные возможности в модели проектирования и реализации - установить внешние наборы данных Выполнить тест - выполнить тестовые процедуры - оценить выполнение теста - восстановиться после остановленного теста - проверить результаты - исследовать неожиданные результаты - дефекты журналов Оценить тест - оценить покрытие тест-кейсов - оценить покрытие кода - анализ дефектов - определить, были ли достигнуты Критерии завершения теста и Критерии успеха - - - - Конфиденциально -<Название компании>, 2015 г. Страница 22 |