ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.02.2024
Просмотров: 127
Скачиваний: 4
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
1.2.Используемые термины и сокращения
2.1.План обучения внутренних пользователей
2.2.План обучения внешних пользователей
3.1.План функционального тестирования
3.2.План нагрузочного тестирования
7.План развертывания приложений
7.1.Приложения, подлежащие миграции/развертыванию
7.5.Развертывание нового портала BIG DATA
14.2.Последовательность действий при откате
15.1.Требования к миграции данных BIG DATA в Axapta
23.1.План миграции данных BIG DATA в Axapta
29.1.Контроль миграции BIG DATA в Axapta
29.2.Контроль миграции источника данных плазменных панелей
3.2.План нагрузочного тестирования
План нагрузочного тестирования описывает порядок проведения этапа «нагрузочное тестирование», необходимого для выявления узких мест разрабатываемой системы и аппаратного обеспечения.
Данный план содержит:
-
перечень ресурсов, которые будут привлечены на этапе нагрузочного тестирования; -
цели; -
инструменты для измерения результата достижения целей, и т.д.
План нагрузочного тестирования несет рекомендательный характер и может быть изменен вследствие новых открывшихся обстоятельств при осуществлении работ по нагрузочному тестированию.
Основной средой проведения нагрузочного тестирования является тестовое приложение разработанной системы (BIG DATA).
Во время проведения нагрузочного тестирования не допускается наличие явных ошибок, по которым не закрыты задачи по исправлению в GPT.
Если такие задачи существуют, по каждой их них принимается отдельное решение о влиянии на функционал приложения и возможном влиянии на результаты проведения интеграционного тестирования.
3.2.1.Компонентное нагрузочное тестирование
Этап компонентного тестирования заключается в нагрузочном тестировании нескольких основных крупных модификаций с целью выявления узких мест в модификациях и оптимизации разработанного кода.
К основным модификациям можно отнести следующие:
-
DIN01 web-форма «Журнал дилера»; -
DIN03 web-форма «Виртуальные контракты»; -
DIN05 web-форма «Операции».
Нагрузочное тестирование каждой модификации будет происходить после завершения этапа внутреннего функционального тестирования и перед ее передачей эксперту Заказчика на функциональное тестирование.
3.2.2.Комплексное нагрузочное тестирование
Комплексное нагрузочное тестирование заключается в тестировании разработанного портала в полнофункциональном режиме, когда все модификации будут полностью протестированы и скомпилированы в одно приложение.
Этап комплексного нагрузочного тестирования проходит после общей компиляции разработанного приложения перед этапом тестирования Заказчиком проекта.
Повторное проведение этапа нагрузочного тестирования будет проведено после тестирования Заказчиком проекта и перед подписанием документа «Акт приемки».
Все этапы нагрузочного тестирования выполняются ответственным сотрудником Исполнителя в соответствии с правилами процедуры тестирования.
Время на проведение каждого этапа тестирования будет обговариваться сторонами перед началом каждого отдельного теста и указываться в «Протоколе тестирования» по окончании теста.
3.2.3.Процедура тестирования
3.2.3.1.Компонентное тестирование
Перед началом этапа тестирования сотрудник Исполнителя составляет сценарий тестирования для каждой из основных модификаций и согласует его с экспертом Заказчика.
Тестирование будет проводиться в разработанной программной среде. Программной средой может быть приложение с разработанной модификацией, которая будет тестироваться, а также данные, на которых будет проводиться тестирование.
Во время тестирования ответственный сотрудник Исполнителя собирает полученные данные с помощью соответствующих инструментов, после чего готовит «Протокол тестирования» по итогам тестирования.
3.2.3.2.Комплексное тестирование
Для проведения данного этапа также требуется составление сценария для тестирования полного функционала разработанной системы модификаций. Сценарий тестирования согласуется с экспертом Заказчика.
Средой тестирования должно выступать полностью разработанное приложение, в котором на момент проведения тестирования не выявлено критических ошибок, влияющих на функционал. Также средой тестирования могут быть реальные данные, импортированные в тестовую систему.
Оборудование для проведения комплексного тестирования должно соответствовать описанному в документе «Технический дизайн на среду для опытного тестирования».
Во время тестирования ответственный сотрудник со стороны Исполнителя собирает полученные результаты и готовит «Протокол тестирования» по итогам тестирования. На основе протокола обеими сторонами принимается решение о готовности разработанного приложения.
3.2.4.Обработка результатов тестирования
При рассмотрении протокола тестирования на каждом из этапов обеими сторонам совместно принимается решение о готовности отдельных компонентов или функционала в целом.
Могут быть получены следующие результаты:
-
Результат проведенного тестирования удовлетворяет обе стороны, и работа продолжается. -
Результат проведенного тестирования не полностью удовлетворяет обе стороны. На этом основании сотрудник Исполнителя фиксирует список требований, которые должны быть выполнены для перехода к следующему этапу проекта или тестирования. Принимается совместное решение о возможности продолжения работ до исправления выявленных ошибок и замечаний. Замечания должны быть внесены в GPT соответствующим образом.
3.2.5.Используемые инструменты и другое обеспечение
Для проведения нагрузочного тестирования будет использована программа Microsoft Application Center Test из пакета Visual Studio 2003. С помощью этого инструмента будут подготавливаться сценарии тестирования, запускаться созданные сценарии и собираться данные по их работе.
Эта программа ранее была использована при нагрузочном тестировании пилотного проекта BIG DATA.
Для отслеживания нагрузки на аппаратное обеспечение будет использоваться программа Microsoft System Performance Monitor, входящая в стандартный пакет ОС Windows. Для выявления каких-либо проблем, связанных со временем загрузки или производительностью базы данных Oracle, будет использоваться Automatic Workload Repository (опция Oracle 10g Release 2).
Требования к использованию аппаратного обеспечения описаны в документе «Технический дизайн на среду для опытного тестирования».
3.2.6.Цели и показатели
Основным критерием оценки быстродействия портала будем считать время, требуемое на загрузку web-страницы на стороне клиента, которое не должно превышать 5 секунд при скорости канала 100 Мбит/с.
При этом необходимо, чтобы нагрузка на аппаратное обеспечение не превышала следующих показателей:
4.средняя нагрузка процессорной мощности сервера БД – не более 60 %;
5.среднее потребление памяти Business Connector – не более 50 MБ на 1 пользователя.
Для каждого из этапов (компонентного, комплексного) необходимо провести несколько итераций с разными параметрами.
Необходимо рассмотреть подключение в условиях ограниченного канала (56 кбит/с, размер загружаемой страницы не более 55 кБ, время на загрузку не более 10 с), инструментальное тестирование (например, 15 пользователей; сеть 100 Мбит/c), экстремальное тестирование для определения предела производительности (не менее 250 пользователей) надо провести для комплексного тестирования.
6.План поддержки
Данный раздел описывает различные этапы технического сопровождения, которое будет предоставлено Заказчику после запуска системы.
Ниже приведено описание того, как будет происходить сопровождение и распределение обязанностей по сопровождению.
6.1.Начальная поддержка
Осуществляется в первый месяц после запуска системы в эксплуатацию.
Поддержка на данном этапе является частью проекта ИИ, и все работы по поддержке ведутся в рамках проекта.
В случае возникновения инцидента пользователь системы сообщает эксперту со стороны Заказчика. Они совместно выявляют причину возникновения проблемы и устанавливают, является ли это ошибкой системы.
Если этот инцидент действительно является ошибкой системы, то эксперт сообщает об этом ответственному сотруднику со стороны Исполнителя, который, в свою очередь, фиксирует в GPT запрос об инциденте, где описывает возникшую ошибку.
Также при необходимости ответственный сотрудник Заказчика может и сам сформировать запрос в GPT.
Степень критичности инцидента устанавливается совместно представителем Заказчика и Исполнителя. Она может быть высокой, средней и низкой. В соответствии со степенью критичности осуществляется исправление данного инцидента.
Дальнейшая работа по устранению проблем ведется в соответствии с устоявшейся процедурой обработки замечаний, принятой в MR.
По итогам этапа начальной поддержки формируется документ «Акт приемки», который определяет готовность к переводу системы полностью в промышленную эксплуатацию.
После подписания акта обеими сторонами считается, что проект ИИ переводится на этап «Основной поддержки» и будет относиться к проекту Big Data.
6.2.Основная поддержка
Начинается с момента подписания акта приемки.
Ведение всех запросов относится к проекту BIG DATA, в рамках которого также ведется поддержка основной функциональности, разработанной для MR.
Первоначально обращения всех пользователей системы проходят через ответственных сотрудников MR.
В том случае, когда ответственный сотрудник MR не может сам установить причину возникновения проблемы, он обращается за помощью к ответственному сотруднику Исполнителя, который, в свою очередь, действуя согласно документу «Процедура обработки замечаний», фиксирует данное замечание/инцидент в GPT.