Главная страница
Навигация по странице:

  • Дата Версия Автор Описание изменений

  • Документ Создан Просмот рен

  • Инструмент Производитель/ Торговая фирма Версия

  • Системные ресурсы Ресурс

  • Этапы Достижения Дата начала Дата окончания

  • Методические указания к выполнению лабораторной работы

    		•

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


    Скачать 60.14 Kb.
    НазваниеЛабораторная работа 1 составление тестплана в соответствии с методологией rup ц ель лабораторной работы
    АнкорВерификация и тестирование
    Дата24.10.2020
    Размер60.14 Kb.
    Формат файлаdocx
    Имя файлаВериф и тестир лаб1.docx
    ТипЛабораторная работа
    #145326

    ЛАБОРАТОРНАЯ РАБОТА №1

    «СОСТАВЛЕНИЕ ТЕСТ-ПЛАНА В СООТВЕТСТВИИ С

    МЕТОДОЛОГИЕЙ RUP»


    ЦЕЛЬ ЛАБОРАТОРНОЙ РАБОТЫ




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

    Тест-план




    История изменений

    Дата

    Версия

    Автор

    Описание изменений





    <имя>

    <описание>
























    1. ВВЕДЕНИЕ

    1.1 НАЗНАЧЕНИЕ


    Данный тест-план «Название Тест-плана» содержит следующие задачи:

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

    • Перечень тест-требований (высокий уровень).

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

    • Определение необходимых ресурсов и обеспечение оценки тестов.

    • Перечень элементов тестового проекта.

    1.2 ПРЕДМЕТНАЯ ОБЛАСТЬ


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

    1.3 СФЕРА ПРИМЕНЕНИЯ


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

    1.4 ИДЕНТИФИКАЦИЯ ПРОЕКТА


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

    Примечание. Удалите или добавьте элементы по мере необходимости.



    Документ

    Создан

    Просмот рен

    Автор или ресурс

    Заметки




    Технические требования

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Функциональные требования

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Отчеты о случаях использования

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    План проекта

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Технические характеристики

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Прототипы

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Инструкция пользователя

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Бизнес-модель

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    Модель данных

     Да 

    Нет

     Да 

    Нет

    <ФИО/на звание ресурса>

    <Описание>

    Бизнес функции и правила

     Да 

    Нет

     Да 

    Нет

    <ФИО/на звание ресурса>

    <Описание>

    Оценка проекта и бизнес рисков

     Да 

    Нет

     Да 

    Нет

    <ФИО/на

    звание ресурса>

    <Описание>

    2. ТРЕБОВАНИЯ К ТЕСТИРОВАНИЮ


    Функциональные и не функциональные требования, которые приведены в списке ниже, были определены как целевые для тестирования. Этот список показывает то, что будет проверено.

    (Вставьте списокосновных требований к тестированию.)

    3. СТРАТЕГИЯ ТЕСТИРОВАНИЯ


    Стратегия тестирования представляет собой рекомендуемый подход к тестированию целей теста. Для каждого теста необходимо предоставить описание того, как он должен быть реализован и выполняться. Если тест не будет выполнен, его следует отметить как «Данный тест не реализован или не выполнен».

    3.1 ТИПЫ ТЕСТИРОВАНИЯ

    3.1.1 ТЕСТИРОВАНИЕ ДАННЫХ И ЦЕЛОСТНОСТИ БАЗЫ ДАННЫХ


    Базы данных и процессы базы данных должны быть протестированы как подсистема разрабатываемого проекта. Данные подсистемы должны быть протестированы только используя интерфейс доступа к данным без пользовательского интерфейса. В дополнение, необходимо провести исследование системы управления базами данных (СУБД), для идентификации инструментов и методов, которые могут быть применены для поддержки тестирования.

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

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

    Методы тестирования:

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

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

    Критерии тестирования:

    Все методы доступа к базе данных и ее процессам функционируют, без повреждения данных.

    Замечания:

    Тестирование СУБД может требовать разрешение на изменение данных в БД.

    Процессы должны быть вызваны вручную.

    Маленькие или минимальные размеры БД (ограничение на число записей) должны учитываться для исключения неприемлемых событий.

    3.1.2 ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ


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



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

    Гарантировать надлежащую функциональность навигации, ввода данных, обработки и поиска в цели теста.

    Методы тестирования:

    Выполнить все описанные случаи использования, включая:

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

    Проверка корректного отображения ошибки при вводе неправильных данных.

    Проверка применения каждого из бизнес правил.

    Критерии тестирования:

    Все запланированные тесты были выполнены.

    Все выявленные дефекты были зафиксироны.




    Замечания:

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


    3.1.3 ТЕСТИРОВАНИЕ БИЗНЕС-ЦИКЛА


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

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

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

    Методы тестирования:

    Тестирование моделирует несколько деловых циклов, включая следующие условия:

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

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

    Все функции, выполняющиеся по периодическому, графику будут выполнены и начаты в подходящие время.

    Тестирование будет включать в себя использование действительных и недействительных данных для проверки:

    Результатов, при вводе действительных данных.

    Отображения корректной ошибки или предупреждающего сообщения, при вводе недействительных данных.

    Выполнения всех бизнес-правил.

    Критерии тестирования:

    Были выполнены все запланированные тесты.

     Были исправленны все выявленные дефекты.

    Замечания:

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

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


    3.1.4 ТЕСТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА


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



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

    Проверить следующее:

    Навигацию между окнами, полями (Клавиша Tab) и окнами приложения.

    Объекты окна и особенности пользовательского интерфейса, расположение элементов в со стандартами.

    Методы тестирования:

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

    Критерии тестирования:

    Были выполнены все тесты, связанные с пользовательским интерфейсом.

    Замечания:

    Не ко всем элементам можно получить доступ.


    3.1.5 ТЕСТ ПРОИЗВОДИТЕЛЬНОСТИ


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



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

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

    Нормальная ожидаемая нагрузка;

    Нагрузка в режиме повышенной нагрузки и стрес-тестов.




    Методы тестирования:

    Использовать процедуры проверки

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

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

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

    Критерии тестирования:

    При использовании одной транзакции или одного пользователя: Успешное завершение всех сценариев тестирования без отказов и выполнении условий по времени.

    При использовании нескольких транзакций или нескольких пользователей: Успешное завершение сценариев тестирования без отказов и выполнение всех ограничений по времени.



    Замечания:

    Всестороннее тестирование производительности включает в себя наличие фоновой рабочей нагрузки на сервере.

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

    Передача транзакций непосредственно на сервер, используя язык структурированных запросов(SQL).

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

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

    Тестирование производительности должно быть выполнено на одной и той же машине. Это позволяет получить более точные измерения производительности.

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

    3.1.6 ТЕСТИРОВАНИЕ НАГРУЗКИ


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

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



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

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

    Методы тестирования:

    Используйте тесты, разработанные для тестирования функций или бизнес цикла.

    Добавьте больше данных для увеличения количества транзакций и тестов.

    Критерии тестирования:

    Успешное прохождение тестов с использованием различных пользователей и транзакций.

    Замечания:

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

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


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


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

    Примечание: Транзакции, приведенные ниже, относятся к логическим бизнес транзакциям.


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

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

    Низкий уровень памяти или отсуствие доступа к ней на сервере (RAM and DASD);

    Максимальное или доступное количество подключенных или имиируемых клиентов;

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

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

    Стресс тестирование клиента описано в секции

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

    Методы тестирования:

    Использовать тесты, разработанные для тестирования производительности и нагрузки.

    Использовать тесты на одном и том же компьютере с ограниченным количеством RAM и DASD.

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

    Критерии тестирования:

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

    Замечания:

    Для нагрузки сети необходимо будет загрузить сеть различными сообщениями и пакетами.

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

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


    3.1.8 ТЕСТИРОВАНИЕ ОБЪЕМА


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



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

    Для проведения тестирования объема, система должна соблюдать следующие требования:

    Правильно обрабатывать максимальное количество подключенных клиентов.

    При достижении максимального объема базы данных правильно обрабатывать поступающие запросы и транзакции.

    Методы тестирования:

    Использовать тесты, разработанные для тестирования производительности или нагрузки.

    Тестирование при помощи проведения транзакций большим количеством пользователей за ограниченный период.

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

    Критерии тестирования:

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

    Замечания:

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


    3.1.9 ТЕСТИРОВАНИЕ «БЕЗОПАСНОСТИ» И «УДАЛЕННОГО

    КОНТРОЛЯ»


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

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

    • Уровень безопасности системы, включая вход или удаленное получение доступа к системе.

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

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



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

    • Уровень безопасности приложения:

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

    • Уровень безопасности системы: Убедиться, что каждый пользователь может получить доступ к системе и приложениям только определенным им.

    Методы тестирования:

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

    • Создать тесты для каждого типа пользователя для проверки разрешений на создание различных транзакций специфичных для данного типа.

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

    • Уровень безопасности системы: (Смотрите раздел замечания)

    Критерии тестирования:

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

    Замечания:

    Права доступа должны быть распределены системным администратором.

    3.1.10 ТЕСТИРОВАНИЕ НА ОТКАЗОУСТОЙЧИВОСТЬ И

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


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

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

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


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

    Убедиться, что процесс восстановления правильно восстанавливает все данные, соблюдая следующие условия:

    • проверка прерывания питания клиента

    • проверка прерывания питания сервера

    • проверка прерывания работы сети

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

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

    • проверка неверного указателя или ключа базы данных

    • проверка поврежденных или неверных данных в базе проекта




    Методы тестирования:

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

    • Прервать питание на клиенте: выключить компьютер.

    • Прервать питание на сервере: инициировать процедуру выключения сервера.

    • Прервать питание сети: имитировать или инициировать потери связи в сети (физически отключить провода или отключить сетевой сервер или маршрутизатор).

    • Прервать связь или потерять мощность: имитировать разрыв связи между диском и компьютером.

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

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

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



    Критерии тестирования:

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

    Замечания:

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

    • Требуется использование таких ресурсов как базы данных и компьютерные сети.

    • Данные тесты следует запускать в определенные часы или на изолированной машине.

    3.1.11 ТЕСТИРОВАНИЕ КОНФИГУРАЦИИ


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



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

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

    Методы тестирования:

    Запустить скрипт тестирования

    Открывать и закрывать программное обеспечение не связанное с тестированием, например, такое как программы компании Microsoft.

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

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

    Критерии тестирования:

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

    Замечания:

    Какое программное обеспечение не участвующее в тестировании доступно на целевой машине?

    Какие приложения обычно используются?

    Какие данные выполняло приложение?

    Например: Excel открыл таблицу.

    Все системы и их конфигурации, использованные в данном тесте, должны быть задокументированы.


    3.1.12 ТЕСТИРОВАНИЕ УСТАНОВКИ


    Тестирование установки имеет две цели. Первое - это убедиться, что программное обеспечение может быть установлено в разных условиях: установка с нуля, обновление, полная и выборочная установка. Также установка может проходить в аномальных условиях, таких как недостаток места на диске, отсутствия прав на создания папок и другие. Вторая цель – убедиться, что после установки программное обеспечение правильно функционирует. Обычно это проверяется проведением тестов для функционального тестирования.


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

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

    Новая установка, на новой целевой машине, с ранее не установленным тестируемым проектом.

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

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



    Методы тестирования:

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

    • Запустит или выполнить установку.

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

    Критерии тестирования:

    Транзакции тестируемого проекта выполняются без сбоев.

    Замечания:

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

    3.2 ИНСТРУМЕНТЫ


    Для этого проекта будут использованы следующие инструменты:

    Примечание: Удалите или добавьте элементы при необходимости.



    Инструмент

    Производитель/ Торговая фирма

    Версия

    IBM Rational Quality

    Manager







    ASQ инструменты для функционального тестирования





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





    Монитор покрытия теста или профилировщик





    СУБД инструменты







    Примечание: ASQ (сокр. От Automated Software Quality) – инструментальные средства создания качественного ПО.

    4. РЕСУРСЫ


    В этом разделе отражены рекомендуемые ресурсы для проекта «Название проекта» и их основные назначения.

    4.1 РОЛИ

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

    Примечание: Удалите или добавьте элементы по мере необходимости.

    Отдел кадров

    Работник

    Рекомендуемые минимальные ресурсы

    (количество ролей, назначенных на

    полный рабочий день)

    Конкретные обязанности или комментарии

    Тест-менеджер,

    Менеджер тестпроектов



    Обеспечивает управленческий контроль.

    Обязанности:

    • Обеспечение технического руководства

    • Приобретение соответствующих ресурсов

    • Предоставлять управленческую отчетность

    Проектировщик тестов





    Идентифицирует, определяет приоритеты и реализует тестовые примеры.

    Обязанности:

    • Создание плана тестирования

    • Создание тестовой модели

    • Оценка эффективности качества тестирования

    Тестировщик



    Выполняет тесты.

    Обязанности:

    • Выполнение тестов

    • Ведение журнала результатов

    • Восстановление при ошибках

    • Создание запросов на изменение документа

    Администратор тестовой системы



    Обеспечивает управление и обслуживание тестовой среды и тех. поддержку.

    Обязанности:

    • Администрирование системы управления тестированием

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

    Администратор базы данных,

    Менеджер базы данных



    Обеспечивает управление и поддержку тестовых данных (базы данных)

    Обязанности:

     Администрировать тестовые данные (базу данных)

    Проектировщик



    Определяет и дает характеристику операциям, атрибутам и ассоциациям тестовых классов.

    Обязанности:

    • Идентифицирует и дает характеристику тестовым классам

    • Идентифицирует и дает характеристику тестовым пакетам

    Исполнитель



    Реализует и тестирует тестовые

    классы и пакеты Обязанности:

     Создает тестовые классы и пакеты, указанные в тестовой модели



    4.2 СИСТЕМА

    В следующей таблице представлены системные ресурсы для проекта тестирования.

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

    Примечание: Удалите или добавьте элементы по мере необходимости.



    Системные ресурсы

    Ресурс

    Название/Тип

    Сервер баз данных

    —Сеть или подсеть

    —Название сервера

    —Название базы данных



    TBD

    TBD

    TBD

    Тест клиентского ПК

    —Включение специальных требований к конфигурации



    TBD

    Тестовый репозиторий

    —Сеть или подсеть

    —Название сервера



    TBD

    TBD

    Тестирование ПК для разработки

    TBD



    Примечание: TBD (to be determined) - «будет определено».

    5. ОСНОВНЫЕ ЭТАПЫ ПРОЕКТА


    Тестирование «Название проекта» должно включать основные этапы каждого тестирования определенного вышеперечисленного раздела. Следует разделить проект на отдельные этапы для достоверной передачи информации о статусе проекта.



    Этапы

    Достижения

    Дата начала

    Дата окончания

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

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





    Оценка риска





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





    Определение тестовых ресурсов





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





    Создание тестплана





    Проектирование теста

    Подготовка анализа рабочей нагрузки





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





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





    Обзор и оценка тестового покрытия








    Реализация теста

    Запись или тестовые скрипты программы





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





    Установка внешних наборов данных





    Выполнение теста

    Оценка выполнения теста





    Восстановление после остановки теста





    Проверка результатов





    Исследование неожиданных результатов





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





    Выполнение процедуры тестированя





    Оценивание теста

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





    Оценка степени покрытия кода





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








    Определение достижения критериев завершения тестирования и критериев успеха






    6. РЕЗУЛЬТАТЫ


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

    6.1 ИСПЫТАНИЯ

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

    6.2 ЖУРНАЛ ИСПЫТАНИЙ

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

    6.3 ОТЧЕТЫ ОБ ОШИБКАХ

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



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

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

    1. Изучить теоретическую часть по приведенным выше данным и дополнительной литературе;

    2. Просмотреть демонстрационный пример;

    3. Выбрать объект тестирования (информационную систему) и утвердить его у преподавателя;

    4. Определить тест-требования на основе анализа требований к информационной системе;

    5. Составить тест-план в соответствии со стандартом методологии RUP;

    6. Оформить результаты лабораторной работы в виде отчета. Теоретический материал в отчете не приветствуется.

    ТРЕБОВАНИЯ К ОТЧЕТУ:

    Отчет должен быть представлен в печатном и электронном виде содержать:

    1. титульный лист;

    2. цель работы;

    3. описание задачи; 4) решение задачи; 5) вывод.


    написать администратору сайта