Глава 6 - ОПРЕДЕЛЕНИЯ ТЕСТИРУЕМОЙ СИСТЕМЫ, ДРАЙВЕРА И ПЕРЕДАЧИ ИНФОРМАЦИИ   

Содержание:

6.1 Модели целевой системы

6.2 Конфигурация теста

6.3 Определение тестируемой системы (ТС)

6.4 Определение драйвера

6.5 Определения Интерфейсов связи

6.6 Дальнейшие требования к ТС и Системе драйверов



6.1 Модели целевой системы

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

Example - Пример
Remote Terminal Emulator (RTE) – Эмулятор Удаленного Терминала (ЭУТ)
Terminal (T) – Терминал (Т)
Network - Сеть
System Under Test (SUT) – тестируемая система (ТС)
Server System(s) – Серверная Система(ы)
Server – Сервер
Response Time Measured Here – время отклика , измеренное здесь
Client System(s) – Клиентская система(ы)
Client - Клиент
Legend – Условные обозначения
Keyboard / Display (K/D) – Клавиатура / Монитор (К/М)
Workstation (WC) – Рабочая станция
Optional- для заметок

6.2 Конфигурация теста

Конфигурация теста состоит из следующих компонентов:

  • Тестируемая система
  • Система(ы) Драйвера(ов)
  • Драйвер(а)/интерфейс(ы) связи ТС

Если одна из сетей является глобальной сетью (WAN), то тестируемой конфигурации не нужно включать в себя линий дальней связи WAN.

6.3 Определение тестируемой системы (ТС)

6.3.1 ТС состоит из:

  • Одной или более единиц (например, хост (компьютер), интерфейс пользователя, рабочие станции и т.п.), выполняющие сочетание транзакций, описанных в пункте 5.2.3, их общая производительность (общая МКПС) описывается величиной tpmC .

  • Любой системы предварительной обработки данных, рассматриваемой как часть ТС. Примерами такой системы являются процессоры связи, групповые контроллеры, клиенты базы данных (как в модели клиент/сервер) и рабочие станции.

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

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

  • Носителя для хранения информации, способного удовлетворить требования масштабируемости (пункт 4.2) и свойства ACID (пункт 3).

6.3.2 Один результат теста может использоваться для различных ТС, если соблюдаются следующие условия:

  • Каждая тестируемая система должна иметь одинаковую конфигурацию, архитектуру «железа» и программного обеспечения.

  • Исключение возможно для элементов, которые не принимают участие в вычислительном процессе ТС (например, число слотов (разъемов) для подключения периферийных устройств, источник питания, корпус, вентиляторы).

  • Каждая ТС должна соответствовать ценовому диапазону.

6.4 Определение драйвера

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

6.4.2 ЭУТ выполняет следующие функции:

  • Эмулирует пользователя, который генерирует и отправляет транзакционные сообщения ТС, вводит данные на экран ввода/вывода эмулируемого терминала;

  • Эмулирует терминал, отображающий на экране ввода/вывода ответные сообщения ТС;

  • Записывает Времена отклика;

  • Выполняет конверсию и/или мультиплексирование в протокол связи, используемый интерфейсом связи между драйвером и ТС ;

  • Выполняет статистические вычисления (например, 90-й процентиль измерения Времени отклика, подсчет пропускной способности и пр.), которые считаются функцией ЭУТ.

6.4.3 Обычно, система драйверов должна выполнять только функции ЭУТ. Работу, выполненную Системой драйверов в дополнение к ЭУТ, как описывается в пункте 6.4.2, необходимо тщательно проверять, как сказано в пункте 6.6.3.

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

6.4.5 Аппаратное и программное обеспечение, которое поддерживается Драйвером, не являющимся ЭУТ, необходимо считать частью ТС. Например, в модели "клиент/сервер" программное обеспечение клиента может управляться или моделироваться Системой Драйверов (см.пункт 6.6.3).

6.5 Определения Интерфейсов связи

6.5.1 Каналы связи ввода/вывода

6.5.1.1 Все используемые протоколы должны быть общедоступными. Комментарий: Основная идея данного определения состоит в исключении нестандартных каналов связи ввода/вывода. Ниже приведены примеры доступных каналов связи:

  • Конфигурация или архитектура, в которых терминалы или контроллеры терминалов соединены с каналом ввода/вывода процессора.

  • Процессор(ы) в ТС подключены к местной коммуникационной сети посредством программного процессора, который рассматривается как часть ТС.

6.5.2 Интерфейсы связи Драйвер/ТС

6.5.2.1 Интерфейс связи между Системой драйверов и ТС должны быть соединены, посредством их система будет связываться с терминалом (см. пункт 2.1.8) для предлагаемой конфигурации.

6.6 Дальнейшие требования к ТС и Системе драйверов

6.6.1 Ограничения для Системы драйверов

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

Комментарий: Синхронизация между ЭУТ и ТС запрещена.

6.6.2 Индивидуальные среды для моделируемых терминалов

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

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

Цель данного параграфа - предостеречь специалиста, проводящего тестирование, от увеличения количества сообщений, содержащих несколько строк, очень большого количества эмулируемых терминалов. Также необходимо показать, что тестируемая система поддерживает определенное количество пользователей, независимо от поддерживаемого количества реальных терминалов. Терминал может терять связь с ТС во время интервала измерения, но он должен восстановить ее за 90 секунд. Потеря и новый ввод пользователя должны быть запротоколированы, в отчете должно быть указано общее число таких потерь.

6.6.3 Система драйверов, выполняющая другие функции кроме ЭУТ

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

6.6.3.1 Необходимо показать, что архитектура предложенного решения подразумевает, что проведение тестирования без работы драйвера – экономически невыгодно (например, в работе базы данных «клиент/сервер», где клиентское программное обеспечение работает на большом количестве рабочих станций).

6.6.3.2 Запрещено нарушать правило 6.6.1.

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

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

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

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

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

6.6.3.5 Индивидуальные среды должны и далее поддерживаться от ЭУТ до ТС.

6.6.3.6 Необходимо показать полную функциональную диаграмму тестовой конфигурации и конфигурации предложенной системы. Необходимо также предоставить детальную информацию о функциональности всех программ и аппаратных средств, представленных в Системе драйверов, а также его интерфейс к ТС.

6.6.3.7 При моделировании устройств конечного пользователя, например, веб-браузера, разработка должна включать в себя задержку Времени отклика, равную 0.1 секунды, для того, чтобы компенсировать задержку отклика, обусловленную использованием этого веб-браузера.
Комментарий: Использование этой измеренной задержки на данном неучтенном в цене компоненте запрещено.

6.6.4 Обзор конфигурации сети и моделируемых распределений

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

6.6.5 Ограничение концентрации

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

Комментарий: Цель – разрешить выполнение только первого уровня концентрации на ЭУТ, но при этом не препятствовать ее дополнительным уровням.

6.6.6 Ограничение на вмешательство оператора

Системы должны работать без вмешательства оператора хотя бы в течение 8-ми часов.

6.6.7 Ограничение на Оптимизацию профиля программного обеспечения

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

  1. Использование ОППО или подобных процедур должно быть подробно изложено специалистом, проводящим тест.

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

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

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

  5. Такой же набор исполняемых файлов СУБД должен применяться для всех этапов тестирования.