Глава 9 - Полный отчет о выполнении   

Содержание:

9.1 Требования к Полному отчету о выполнении
9.2. Итоговое исполнительное постановление
9.3. Требования к выполнению отчета
9.4. Дополнительные файлы











9.1 Требования к Полному отчету о выполнении

По окончании Выполнения теста необходимо сформировать полный отчет о выполнении (FDR). Этот раздел задает требования к формированию FDR.

FDR это .zip файл, содержащий следующее:
  •  Отчёт в формате Adobe Acrobat PDF,
  •  Итоговое исполнительное постановление в формате Adobe Acrobat PDF,
  •  документ XML («ES.xml») с примерно той же информацией, что и в Итоговом исполнительном постановлении,
  •  Файлы обеспечения, состоящие из различных файлов исходных кодов, сценариев и списков. Требования к структуре файла FDR описаны ниже:
Примечание: Назначением FDR является описание того, при помощи какой реализации и исполнения был достигнут Результат контрольного тестирования, для того чтобы Результат мог быть воспроизведен с соответствующим оборудованием и программным обеспечением.

9.1.1 Основные пункты

9.1.1.1 Порядок и заголовки разделов в Отчете и Дополнительных файлах должны соответствовать порядку и заголовкам разделов из Спецификации Стандарта TPC-E (т.е. этого документа). Это необходимо для облегчения, насколько это возможно, сравнения и отличия читающими данных из разных Отчетов.

9.1.1.2 FDR должен следовать всем правилам отчетности, заданным в актуальной версии Спецификации оценки стоимости TPC, доступной на интернет-ресурсе www.tpc.org. Для ясности и читаемости требования Спецификации оценки стоимости TPC могут быть описаны повторно в Спецификации TPC-E.

9.1.1.3 В структуре директорий FDR содержатся три папки:
  •  ExecutiveSummaryStatement – содержит Итоговое исполнительное постановление и ES.xml
  •  Report – содержит Отчет,
  •  SupportingFiles – содержит Дополнительные файлы.
9.1.1.4 Требования к отчету, приведенные в пункте 9, задают необходимость приведения описаний, сценариев и и пошаговых инструкций по работе с GUI, которые необходимы для воспроизводства Результата контрольного тестирования. Организатор Теста может предоставлять описания, сценарии и инструкции к GUI только к измеряемой SUT, поскольку в момент публикации результатов нет никаких сведений о будущих изменениях в оборудовании и программном обеспечении. Для соблюдения требований воспроизводимости из пункта 9.1 Организатор теста должен предоставить по запросу все описания, сценарии и пошаговые инструкции к GUI, необходимые для воспроизведения Результатов контрольного теста.

9.2 Итоговое исполнительное постановление

Итоговое исполнительное постановление ТРС должно быть приведено в начальной части Отчета. Пример Итогового исполнительного постановления представлен в Приложении В. Последняя версия требуемого формата доступна у Администратора TPC.

9.2.1 Первая страница Итогового исполнительного постановления

9.2.1.1 Первая страница Итогового исполнительного постановления должна включать в себя следующее:
  •  Название Организатора
  •  Название тестируемого сервера
  •  Версию Спецификации TPC-E, по которой проводится контрольное тестирование и публикуются результаты
  •  Версию Спецификации оценки стоимости TPC, по которой публикуются результаты контрольного тестирования
  •  Дату отчета и/или Дату редактирования
  •  Отчетную производительность в tpsE (см. Пункт 6.7.1)
  •  Величину отношения Стоимость/Производительность(см. Спецификацию оценки стоимости TPC).
  •  Дату доступности(см. Спецификацию оценки стоимости TPC)
  •  Суммарную стоимость системы (см. Спецификацию оценки стоимости TPC)
  •  Название и версию Операционной сиcтемы, работающей на Сервере баз данных
  •  Название и версию СУБД
  •  Количество процессоров/ядер/потоков Сервера баз данных, которое было задействовано для контрольного тестирования (см. Политики ТРС по адресу www.tpc.org)
  •  Объем памяти, в гигабайтах, установленной на Сервере баз данных
  •  Диаграмму (см. пункт 9.3.1.2), описывающую компоненты Оцениваемой конфигурации (см. Спецификацию оценки стоимости TPC)
  •  Начальный размер базы данных в гигабайтах
  •  Уровень избыточности и детали реализации Уровня избыточности
  •  Оцененное количество Постоянный носителей (дисков) для хранения базы данных
9.2.2 Дополнительные страницы Итогового исполнительного постановления

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

Категории электронной таблицы стоимостей:

Основные категории, на которые разделена электронная таблица стоимостей, это::
  •  Серверное оборудование
  •  Серверное хранилище
  •  Серверное оборудование
  •  Клиентское оборудование
  •  Клиентское хранилище
  •  Инфраструктура (сетевое оборудование, ИБП, консоли, прочие компоненты, которые не подходят под вышеизложенные категории)9.2.2.2 Название Аудитора, который сертифицировал результаты, должно быть приведено после электронной таблицы стоимостей.9.2.2.3 Численные величины, перечисленные ниже, должны быть включены в Итоговое исполнительное постановление после электронной таблицы стоимостей:
  •  Отчетная производительность в tpsE (см. Пункт 6.7.1)
  •  Сконфигурированные клиенты (см. Пункт 2.6)
  •  Интервал измерения, в чч:мм:сс (часы, минуты, секунды) (см. Пункт 0),
  •  Время Нарастания в чч:мм:сс (см. Пункт 0),
  •  Время восстановления бизнеса в чч:мм:сс (см. Пункт 7.5.7.3),
  •  Количество Транзакций в Сочетании Транзакций, завершенных в пределах Интервала измерения (приведите в отчете общую сумму и количество по каждому типу Транзакций) (см. Пункт 6.3.1)
  •  Количество Транзакций каждого типа (включая Data-Maintenance), завершенных за Интервал Измерения
  •  Процентное соотношение по каждому типу Транзакций в Сочетании Транзакций, завершенном за Интервал измерения (см. пункт 6.3.1).
  •  Девяностый процентиль, минимум, максимум и среднее значение Времен отклика должно быть приведено в отчете по всем Транзакциям из Сочетания Транзакций, завершенных за Интервал Измерения (см. Пункт 6.5.1).
  •  Максимум, минимум и среднее значение Времен отклика по Транзакции Data-Maintenance также должно быть приведено в отчете.
Примечание: Приложение B содержит пример Итогового исполнительного постановления. Его задачей является создание удобного и легкого доступа к данным в знакомой форме и стиле. Не обязательно досконально повторять форму, показанную в Приложении B.

9.2.3 Требования ES.xml

9.2.3.1 Схема документа ES.xml описывается при помощи документа XML схемы tpce-es.xsd (доступного на сайте www.tpc.org). Файл ES.xml должен соответствовать tpce-es.xsd (составлен по соответствующей XML схеме).

Примечание: Организатор обязан проверить, что файл ES.xml, предоставляемый им в FDR соответствует XML схеме TPC-E. На сайте ТРС предоставляется утилита для осуществления этой проверки.

9.2.3.2 Приложение C описывает структуру XML схемы, определяет отдельные аттрибуты и элементы и объясняет, как использовать эту схему.

9.3 Требования к выполнению отчета

9.3.1 Введение в Отчет

9.3.1.1 В отчете должно присутствовать описание, указывающее Организатора(ов) контрольного теста и прочие компании, принимавших участие в нем.

9.3.1.2 В отчете должны быть представлены диаграммы тестируемой и оцениваемой конфигураций, сопровождаемые описанием различий. Сюда входят, но не ограничиываются ими:
  •  Количество и типы процессоров, количество ядер и количество потоков.
  •  Размер выделенной памяти и любые особые способы разметки/разделения памяти, характерные для этого теста.
  •  Количество и типы дисковых устройств (и контроллеров, в случае необходимости).
  •  Количество каналов или подключений шины к дисковым устройствам, включая их тип протокола.
  •  Количество соединений по локальной сети, включая маршрутизаторы, рабочие станции и т.п., , которые были использованы в тесте или включены в оцениваему структуру.
  •  Тип и расположение выполняемых компонент программного обеспечения (например, СУБД, клиент, процессы, мониторы транзакций, программные драйверы и т.д.).
Примечание: Детализированные диаграммы конфигураций систем и различных архитектур могут значительным образом варьироваться, и не представляется возможным привести точные рекомендации, подходящие всем реализация. Таким образом, необходимо описать системные компоненты и связи со степенью детализации достаточной для осуществления независимого воспроизведения среды тестирования.

9.3.1.3 Нижеследующий пример диаграммы иллюстрирует тестовую серверную конфигурацию, использующую 32-разрядный сервер. Сервер использует 3 SCSI Контроллер, каждый из которых подключен к четырем дисковым устройствам с 72GB памяти и скоростью вращения шпинделя 15Krpm. Для подключения машины Драйвера к машинам среднего ранга и машин среднего ранга к серверу используется стандарт локальной сети Gigabit Ethernet. Необходимо заметить, что эта диаграмма не иллюстрирует или обозначает какую либо оптимальную конфигурацию для тестирования TPC-E.


                   Figure 9.a - Пример тестовой конфигурации

9.3.1.4 В отчете должно быть приведено описание шагов, предпринятых для конфигурирования всего оборудования. Все сценарии конфигурации или пошаговые инструкции по работе с GUI приводятся в Дополнительных Файлах (см. пункт 9.4.1.1). Описание, сценарии и инструкции к GUI должны быть достаточно полны для того, чтобы читатель, знакомый с компьютерными системами и TPC-E спецификацией мог воссоздать среду оборудования. Это включает в себя, но не ограничивается:
  •  Описание любых обновлений прошивок или патчей оборудования.
  •  Описание любых конфигураций GUI, использовавшихся для настройки оборудования системы.
  •  Описание того, как именно оборудование сочетается для создания полной системы. К примеру, если в описании SUT указаны базовая система с одним процессором, пакет дополнения процессора, состоящий из 3 процессоров, контроллер сетевых карт, 3 дисковых контроллера, в отчете должно быть представлено описание того, где и как размещаются процессоры, контроллеры NIC и дисковые контроллеры внутри корпуса.
  • Описание того, как соединяются компоненты оборудования. Описание можно выполнить, предполагая, что читающий его имеет представление о компьютерных системах и спецификации TPC-E. К примеру, необходимо описание только того, что Контроллер 1 в слоте А подключен к Дисковой Башне 5. Предполагается, что читатель достаточно осведомлен, чтобы определить, какой типа кабеля необходим, опираясь на описание компонент, и как вставлять кабель в компоненты.
9.3.1.5 В Отчете должно быть представлено писание всех шагов, предпринятых для конфигурирования всего программного обеспечения.

Все сценарии конфигурации и пошаговые инструкции GUI приводятся в Дополнительных файлах (см. Пункт 9.4.1.2). Описание, сценарии и инструкции GUI должны быть достаточны для того, чтобы читатель, имеющий представление о компьютерных системах и спецификации TPC-E, мог воссоздать программную среду. Это включает в себя, но не ограничивается:
  •  Описание любых обновлений или патчей программного обеспечения.
  •  Описание любых изменений в программном обеспечении.
  •  Описание любых конфигураций GUI, используемых для настройки программного обеспечения.
9.3.2 Пункт 2 Проектирование, масштабирование и наполнение базы данных

В отчете должно быть представлено описание шагов, предпринятых для создания базы данных, обеспечивающей Отчетный уровень производительности. Все сценарии или инструкции GUI приводятся в Дополнительных файлах (см. Пункт 9.4.2). Описание, сценарии и инструкции GUI должны быть выполнены таким образом, чтобы читатель, имеющий представлении о программной среде баз данных и спецификации TPC-E мог воссоздать базу данных. Это включает в себя, но не ограничивается ими, требования, изложенные в нижеследующих подпунктах 9.3.2.

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

9.3.2.2 Хотя на горизонтальное или вертикальное разделение таблиц и рядов в тестировании ТРС-Е накладывается очень немного ограничений (см. Пункт 2.3.3), любое подобное разделение должно быть представлено в Отчете. Используя таблицу CUSTOMER в качестве примера, подобное разделение может быть обозначено так:

C_part_1                             C_ID
                                            C_TAX_ID
                                            C_ST_ID
                                            C_L_NAME
                                            C_F_NAME
                                            C_M_NAME
                                            C_GNDR
                                            C_TIER
                                            C_DOB
                                            C_AD_ID

------------ Горизонтальное разделение-----------

C_part_2                             C_CTRY_1
                                            C_AREA_1
                                            C_LOCAL_1
                                            C_EXT_1
                                            C_CTRY_2
                                            C_AREA_2
                                            C_LOCAL_2
                                            C_EXT_2
                                            C_CTRY_3
                                            C_AREA_3
                                            C_LOCAL_3
                                            C_EXT_3
                                            C_EMAIL_1
                                            C_EMAIL_2

Как только разделенные элементы базы данных были обозначены таким образом, к ним можно обращаться при помощи, например, их записи, T_part_N, во время описания физического выделения файлов базы данных (см. Пункт 9.3.2.6), в которой Т обозначает название таблицы и N обозначает номер сегмента раздела.

9.3.2.3 В Отчете должна быть описана Репликация таблиц в случае ее использования (см. Пункт 2.3.3.3).

9.3.2.4 Дополнительные и/или повторяющиеся колонки в любой таблице должны быть представлены в Отчете вмесе с описанием влияния на производительность (см. Пункт 0).

9.3.2.5 Размерность (например, количество рядов) в каждой таблице, в том виде, в котором она существовала после загрузки базы данных (см. Пункт 2.6), должна быть представлена в Отчете.

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

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



9.3.2.7 В Отчет должно быть добавлено предложение, которое описывает:
  • Интерфейс базы данных (например, встроенный, интерфейс уровня вызовов) и язык доступа (например, чтение/запись с помощью SQL, COBOL), используемый для реализации Транзакций TPC-E. Если для реализации ТРС-Е используется более одного интерфейса/языка доступа, то должен быть описан каждый из интерфейсов/языков доступа и должен быть предоставлен список того, какой интерфейс/язык доступа используется в сочетании с каким типом Транзакций.
  • Модель данных, реализованная в СУБД (например, реляционная, сетевая, иерархическая).
9.3.2.8 The methodology used to load the database must be reported in the Report.

9.3.3 Пункт 3 Информация, относящаяся к Транзакциям

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

9.3.3.2 В Отчете должно быть приведено предложение, говорящее о том, что требования ко слепку базы данных (как описано в Пункте 3.3.) были соблюдены.

9.3.4 Пункт 4 Информация, относящаяся к SUT, Драйверу и Сети

9.3.4.1 Сетевая конфигурация и тестируемой и Оцениваемой конфигураций должна быть описана и представлена в Отчете. Это включает в себя обязательную Сеть между Драйвером и Уровнем А (см. пункт 4.2.2) и любые опциональные интерфейсные сети Сервера баз данных (см. Пункт 4.1.3.14).

9.3.5 Пункт 5 Информация, относящаяся к EGen

9.3.5.1 В Отчете должна быть указана версия EGen, использовавшегося в контрольном тестировании (см. Пункт 5.3.1).

9.3.5.2 В Отчет должно быть включено предложение, говорящее о том, что в тестировании был использован весь необходимый код EGen, предоставляемый TPC.

9.3.5.3 Если Организатор теста модифицировал EGen, то утверждение о том, что EGen был модифицирован, должно быть включено в Отчет. В Отчет также должны быть включены все официальные формуляры от ТРС, документирующие допустимые изменения EGen (см. Пункт 5.3.7.1). Если какое либо из внесенных в EGen изменений не подкреплено официальным формуляром, это также должно быть включено в Отчет.

9.3.5.4 Если Организатор Теста расширил функционал EGenLoader (как описано в Приложении A.6), в Отчете должно быть описано использование расширенного EGenLoader и проверка расширяющего кода Аудитором (см. Пункт 5.7.4).

9.3.5.5 Файлы make/project используемые для компиляции/связи EGenLoader и EGenValidate должны быть включены в Дополнительные файлы. В Дополнительные файлы также должны быть внесены опции компилятора/редактора связей и флаги, используемые для компиляции/связывания Объектов EGen для SUT.

9.3.6 Пункт 6 Информация, относящаяся к Оценка производительности и Времени отклика

9.3.6.1 В Отчет должно быть включено количество экземпляров EGenDriverMEE и EGenDriverCEиспользовавшихся в контрольном тестировании (см. Пункт 6.2.5).

9.3.6.2 В Отчете должна быть приведена Измеренная производительность (см. Пункт 6.7.1.2).

9.3.6.3 В Отчете должен быть представлен График Выполнения теста, отображающий зависимость производительности от прошедшего времени по Транзакции Trade-Result (см. Пункт 6.7.2).

9.3.6.4 В Отчете должен быть указан метод, использовавшийся для определения того, что SUT достигла Стабильного состояния перед тем, как начинать Интервал измерения.

9.3.6.5 В Отчете должно быть приведено описание того, как операции, обычно совершаемые во время Выполнения теста, осуществлялись фактически во время Интервала измерения (к примеру, создание контрольных точек, создание записей Журнала Отмены/Возврата и т.п.).
9.3.6.6 В Отчете должны быть приведены зафиксированные средние значения входных параметров заданных в пункте 6.4.1 по каждой Транзакции за время Интервала измерения.

9.3.7 Пункт 7 Информация, относящаяся ко свойствам Транзакций и Системы

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

9.3.7.2 Организатор теста должен указать в Отчете Уровень избыточности (см. Пункт 7.5.7.1) и описать тесты Доступности данных, использовавшиеся для ее демонстрации.

9.3.7.3 В Отчете должен быть представлен График Доступности данных по каждому выполнению теста, демонстрирующий Уровень избыточности (см. пункт 7.5.7.2)

9.3.7.4 Организатор Теста должен описать в Отчете тест(ы), использовавшиеся для демонстрации Восстановления Бизнеса.

9.3.7.5 Время восстановления бизнеса должно быть указано в Итоговом исполнительном постановлении и в Отчете. Если сбои, описанны в Пунктах 7.5.2.2, 7.5.2.3 и 7.5.2.4 не были объединены в один тест Устойчивости (обычно отключая питание Сервера базы данных во время выполнения), то тогда Время восстановления бизнеса после сбоя, описанного для внезапного мгновенного перебоя – это то Время восстановления бизнеса, которое должно быть внесено в Итоговое исполнительное постановление. Все значения Времени восстановления бизнеса по каждому тесту, нуждающемуся в Восстановлении бизнеса, должны быть приведены в Отчете.

9.3.7.6 В Отчете должен быть представлен График Времени восстановлени бизнеса (см. пункт 7.5.7.4) по всем тестам Восстановления бизнеса.

9.3.8 Пункт 8 Информация, относящаяся к оценке стоимости

9.3.8.1 В Отчете должны быть представлены детали расчетов 60-дневного Объема (см. Пункт 8.2.2) вместе с доказательством того, что база данных сконфигурирована таким образом, чтобы обеспечивать потребности в росте данных в течение Рабочего дня (см. Пункт 6.6.6.1).

9.3.8.2 Отчет должен содержать Аттестационное письмо Аудитора, которое обозначает соответствие тестированию.

9.3.9 Таблица индексов Дополнительных файлов

В Отчете должен быть представлен индекс для всех файлов, требования о которых описаны в пункте 9.4. Индекс Дополнительных файлов представлен в табличном формате, в котором колонки обозначают следующее:
  •  Первая колонка обозначает пункт в Спецификации TPC
  •  Вторая колонка предоставляет короткое описание содержимого файла
  •  Третья колонка содержит путь к файлу, начиная с директории SupportingFiles
Если никаких Дополнительных Файлов не предоставляется, то в колонке описания должно быть указано, что дополнительных файлов не существует, и колонка пути должна быть оставлена пустой.

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

9.3.9.1 Нижеследующая таблица являетсяпримером Таблицы индексов Дополнительных файлов, которая должна быть внесена в Отчет.




9.4 Дополнительные файлы


Дополнительные файлы содержат читаемые людьми и исполняемые машиной (т.е, предназначенные для выполнения соответствующей программой без изменений) сценарии, которые необходимы для воссоздания Результата контрольного тестирования. Если присутствует выбор между использованием GUI или сценарием, то тогда в Дополнительных файлах должен быть представлен сценарий, выполняемый машиной. Если для GUI не существует соответствующего сценария, тогда в Дополнительных файлах должно содержаться детальное пошаговое описание того, как пользоваться GUI.

Иерархическая структура директории SupportingFiles должна соответствовать принципам нумерации пунктов в Спецификации Стандарта TPC-E (т.е. этом документе). Название директорий определяются подпунктами третьего уровня Пункта 9.4, непосредственно предшествующими четвертым уровням, содержащим требования об отчетности по Дополнительным файлам. Если существует более чем один экземпляр одного типа файлов, то для каждого экземпляра можно использовать вложенные папки. К примеру в случае, если в тестировании использовалось несколько машин Уровня А, то может быть создана папка для каждой машины Уровня А.

Имена файлов должны быть выбраны таким образом, чтобы ясно показать обычному пользователю, что содержится внутри файла. К примеру, если необходимо предоставить сценарии по всем предложениям определений таблиц и всем прочим предложениям, использовавшимся для организации базы данных, имена файлов 1, 2, 3, 4 или 5 являются неприемлемыми. Должны использоваться имена файлов, которые содержат слова «таблицы», «индексы», «фреймы» (или «tables», «index» или «frames») для того чтобы сообщить пользователю о том, что создается при помощи сценария.

9.4.1 Директория SupportingFiles/Introduction

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

9.4.1.2 Все сценарии, необходимые для конфигурирования программного обеспечения, должны быть приведены в Дополнительных файлах. Это включает в себя любые Настраиваемые Параметры и опции, которые были изменены со значений по умолчанию в коммерчески доступных продуктах, включая, но не ограничиваясь ими:
  •  опции настройки базы данных.
  •  опции восстановления/подтверждения.
  •  опции последовательности/блокировки.
  •  параметры конфигурирования Операционной системы и прикладного программного обеспечения.
  •  Опции компиляции и связи и оптимизации процесса выполнения, использовавшиеся для создания/установки приложений, Операционных систем и/или баз данных.
  •  Параметры, переключатели или флаги, которые могут быть изменены для корректировки поведения продукта.
Примечание: это требование может быть соблюдено посредством представления полного списка всех параметров и опций.

9.4.2 Директория SupportingFiles/Clause2

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

9.4.3 Директория SupportingFiles/Clause3

9.4.3.1 В Дополнительных файлах должна быть представлена Реализация Фрейма (как описано в пункте 4.2) каждой Транзакции. Сюда входит, но не ограничивается им, исходный код, реализующий двенадцать Транзакций (см. Пункт 3.3) данного тестирования.

9.4.4 Директория SupportingFiles/Clause4

9.4.4.1 Нет требований

9.4.5 Директория SupportingFiles/Clause5

9.4.5.1 Если Организатор теста модифицировал EGen, изменения должны быть описаны в Дополнительных файлах.

9.4.5.2 Если Организатор теста расширил EGenLoader (как описано в Приложении A.6), расширяющий код должен быть представлен в Дополнительных файлах.

9.4.5.3 В Дополнительных файлах должна быть приведена конфигурация EGenDriverCE, EGenDriverMEE и EGenDriverDM.

9.4.5.4 В Дополнительные файлы должны быть включены используемые параметры EGenLoader.

9.4.5.5 В Дополнительные файлы должен быть включен отчет о выходных данных EGenLogger по каждому объекту CCE, CMEE и CDM (см. Пункт 5.8.1).

9.4.6 Директория SupportingFiles/Clause6

9.4.6.1 В Дополнительные файлы должен быть включен отчет о выходных данных EGenValidate (см. Пункт 6.7.4).

9.4.7 Директория SupportingFiles/Clause7

9.4.7.1 В Дополнительные файлы должны быть включены сценарии ACID и выходные данные тестов ACID.

9.4.8 Директория SupportingFiles/Clause8

9.4.8.1 В Дополнительные файлы должна быть включена электронная таблица, детально описывающая расчеты 60-дневного объема.