Глава 2 - ТРАНЗАКЦИИ и ПРОФИЛИ ТЕРМИНАЛА |
Содержание: 2.1 Описание терминов
2.1.1. Термин "выбрать", используемый в данной инструкции, означает выбор (например., привязка, указание на что-либо) ряда (или рядов) в базе данных, не требуя при этом возвращения содержимого выбранного ряда (-ов). 2.1.2. Термин "вернуть", используемый в данной инструкции, относится к вызову (т.е. загрузке) значения определенного свойства из базы данных и его передаче прикладной программе. Примечание: Поля, относящиеся к свойствам базы данных, используют верхний регистр. Другие поля, как, например, SUT или RTE, используемые для вычислений или связи с терминалом, но не хранящиеся в базе данных, используют нижний регистр. 2.1.3. Термин "транзакция базы данных", используемый в данной инструкции, относится к элементарной операции над этой базой данных со всеми свойствами СУБД, описанными в Главе 3. Понятие "деловая транзакция" включает в себя одну или несколько транзакций базы данных. При использовании термина "транзакция", подразумевается именно "деловая транзакция". 2.1.4. Термин [x .. y] представляет собой определенный диапазон значений, начиная с х, и заканчивая у. 2.1.5. Понятие "случайно выбранный из [x .. y]" означает, что значения выбраны независимо и случайно, равномерно распределены в пределах от х до у включительно. Их среднее значение равно (х+у)/2, а его десятичная точность такая же, как и у х и у. Например, диапазон [0.01 .. 100.00] имеет 10 тыс. уникальных значений, в то время, как в диапазоне [1 .. 100] их только 100. 2.1.6. Понятие "неравномерное случайное" используется только для генерации номера заказчика, фамилии заказчика, и номера товара, и означает, что значение выбрано случайно и независимо, и неравномерно распределено в диапазоне [x .. y]. Это число должно генерироваться функцией NURand, которая дает случайное значения в пределах [x .. y]. Результаты этой функции могут быть преобразованы в имена или числа, допустимые в приложении. NURand(A, x, y) = (((random(0, A) | random(x, y)) + C) % (y - x + 1)) + x где: exp-1 | exp-2 - дает результат побитовой логической операции OR для exp-1 и exp-2 exp-1 % exp-2 - дает остаток от целочисленного деления exp-1 на exp-2 random(x, y) дает значение, случайно выбранное в диапазоне [x .. y] А – это константа, выбранная согласно размеру диапазона [x .. y] для C_LAST, диапазон - [0 .. 999], А = 255 для C_ID, диапазон - [1 .. 3000], А = 1023 для OL_I_ID , диапазон - [1 .. 100000], А = 8191 С – это динамическая константа, случайно выбранная в пределах [0 .. A], которая может варьироваться без изменения производительности. Одно и то же значение С для полей (C_LAST, C_ID, and OL_I_ID) должно использоваться всеми терминалами. 2.1.6.1. Чтобы значение С, используемое для C_LAST, не влияло на производительность, необходимо, чтобы было учтено нижеследующее: Допустим, при заполнении базы данных для генерации C_LAST значение С будет равным C-Load. C-Load – это значение в пределах [0..255], включая 0 и 255. Чтобы сгенерировать C_LAST для запуска измерений, допустим, что значение С будет равно C-Run. Допустим, C-Delta – это абсолютное значение разницы между C-Load и C-Run. Значение C-Delta должно лежать в пределах диапазона [65..119], включая числа 65 и 119, но исключая числа 96 и 112. 2.1.7 Термин "прикладная программа" относится к коду, который не является частью доступных компонентов системы, а создан специально для реализации профилей транзакций данного контрольного измерения (см. пункты 2.4.2, 2.5.2, 2.6.2, 2.7.4 и 2.8.2). Например, процедуры сохранения, триггеры и условия целостности на уровне ссылок считаются частью прикладной программы, если они используются для реализации любой части профилей транзакций. Но в случае их использования исключительно для выполнения правила непрерывности (см. параграф 1.5) или требования прозрачности (см. параграф 1.6), независимо от профиля транзакции, программами они уже не считаются. 2.1.8 Термин "терминал", используемый здесь, относится к устройству, позволяющему пользователю вводить символы и отображать их на экране, имеющем минимальное разрешение 24х80. Терминал определяется как компонент, позволяющий вводить и отображать данные на экране (см. Главу 2). Терминал может ничего не знать о программе, за исключением формата полей, их типа и местонахождения. 2.2 ОСНОВНЫЕ ТРЕБОВАНИЯ для ТЕРМИНАЛА ВВОДА/ВЫВОДА 2.2.1. Описание экрана ввода/вывода. 2.2.1.1. Специалист, выполняющий тестирование, должен настроить формат экрана ввода/вывода, как это сказано в пунктах 2.4.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1 и 2.8.3.1, максимально близко к свойствам и ограничением системы, на которой это тестирование выполняется. Любые отклонения от этих параметров должны быть подробно изложены в отчете. 2.2.1.2. Экраны ввода/вывода могут быть перенастроены таким образом, чтобы обойти ограничения программы, но производительность останется без изменений. Тем не менее, все же следует придерживаться следующих правил:
2.2.1.3. Поля "количество" и "стоимость", определенные в Главе 2, выражаются форматом валюты США. Эти форматы можно менять на любую другую региональную валюту (например, воспользуйтесь знаком другой валюты, переместите десятичный знак хотя бы на одну позицию вправо). 2.2.1.4. Если в таблице есть неиспользуемые поля (или группа полей), то не обязательно их вводить или отображать на экране. Например, если заказ имеет менее 15 товаров и какая-то группа полей, ожидающая ввода, не используется, то нет никакой необходимости их отображать. Таким образом, если выбрать заказчика по полю, в котором введена его фамилия, то поле "номер заказчика" не используется и не требует его отображения. 2.2.1.5. Значения всех полей, предназначенных для ввода и вывода данных, должны быть очищены в начале каждой транзакции, даже если данным терминалом постоянно используется один и тот же тип транзакции. Поля должны быть очищены таким образом, чтобы в них отображались пробелы или нули. Комментарий: В пунктах 2.2.1.4 и 2.2.1.5, в случае, если пользователь, проводящий тестирование, для очистки полей не поддерживает пробелы либо нули, он может использовать другие символы очистки. 2.2.1.6. Для выбора типа транзакции используется Меню. Оно содержит одно или несколько подменю, и должно располагаться либо в самом верху экрана, или в его самом низу. Если для выбора меню требуется поле ввода, то оно должно располагаться на линии (линиях), зарезервированных для меню. Комментарий: Меню – это дополнение к форматам экрана, определенным в главе Терминал ввода/вывода, для каждого типа транзакции. 2.2.1.7. Меню должно отображать недвусмысленный текст (т.е., оно должно содержать полное название каждой транзакции и действие, которое последует при выборе пользователем этой транзакции). В меню должно отображаться как минимум 60 символов, исключая пробелы. 2.2.1.8. Любые дополнительные поля ввода или вывода, отличные от упомянутых в пунктах 2.3.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1 и 2.8.3.1, должны быть подробно описаны, а цель их использования должна быть подробно изложена. 2.2.2. Поля для ввода и отображения 2.2.2.1. Как только терминал передает тестируемой системе, ТС, (SUT – system under test) все входящие в состав данных символы, говорят, что это поле заполнено. 2.2.2.2. Как только ТС передает терминалу для вывода на экран все передает терминалу все входящие в состав данных символы, то говорят, что это поле выведено на экран. 2.2.2.3. Передача входных или выходных данных не требует передачи определенного числа байтов. При этом допускается любой из методов оптимизации данных, например, сжатие или кэширование. 2.2.2.4. Пользователю должно быть предоставлено следующее: 1. Символы при вводе должны отображаться на экране. Это можно осуществить при визуальном контроле при полной загрузке, когда не заметно никаких задержек. Иначе, необходимо, чтобы отображение символа проверялось во время выполнения измерений. Это можно сделать при помощи, например, анализатора протокола, аппаратурой проверки приемника (RTE – receiver test equipment), и т.д., и таким образом показать, что время задержки между вводом символа с клавиатуры и его отображением на экране - менее 1 секунды. Если используется устройство локальной проверки задержки и устройство с блочным режимом, то такие проверки не требуются. Комментарий: Для программы, представленной в виде веб-браузера, терминала, или компьютера, эмулирующего терминал с режимом локальной проверки, либо с блочным режимом, есть требование о длительности задержки между моментом ввода символа при помощи клавиатуры и моментом его отображения на экране. Эта задержка не должна превышать 1 секунду. Поэтому никаких дополнительных проверок не требуется. 2. Ввод разрешен только в поля ввода (т.е., поля для вывода, метки или пустые места на экране ввода/вывода защищены от ввода в них данных). 3. Поля, в которые допускается ввод, отмечены особым образом, их можно легко отличить (например, имеют подсветку, подчеркивания, негативное изображение, разделители столбцов, и т.д.). 4. В поля должны вводиться только определенные символы. Для буквенно-цифровых полей недопустимые символы должны быть преобразованы либо в пробелы, либо в нули. Для числовых полей вводимые значения с числом цифр, меньшим допустимого максимума, должны быть представлены в соответствующем виде. 5. Требуется, чтобы перед запуском тестирования транзакции RT, поля, значения в которых необходимы приложению для завершения расчетов, были заполнены, или же сама программа должна содержать функции, отлавливающие исключения, и сообщающие пользователю, что эти поля требуют ввода. 6. В поля можно вводить значения в любом порядке. Так же в любом порядке разрешается изменять эти значения. В частности:
7. Поля для ввода числовых значений должны быть защищены от ввода других символов. При вводе одного или нескольких нечисловых символов пользователь должен быть предупрежден сообщением об ошибке.
Комментарий: Проверка ввода может осуществляться либо терминалом, либо приложением, или их комбинацией. Проверка Позиций 5 и 7 должна проводиться еще до запуска транзакции базы данных. В частности, ввод неправильного значения может не привести к откату транзакции. 2.2.2.5. Все поля, значения в которых обновляются в результате выполнения деловой транзакции, должны отмечаться меткой "новый" (т.е., обновленный). 2.3 Общие требования к профилям транзакций Каждая транзакция должна выполняться в точном соответствии с ее профилем. При этом: 2.3.1 Порядок обработки данных в пределах транзакции несущественен (если это не оговорено отдельно, см. пункт 2.4.2.3) и остается на усмотрение лица, проводящего тестирование. Это связано с тем, что выполняемые транзакции функционально равнозначны тем, которые описаны в профилях транзакции. 2.3.2 Профили транзакции точно определяют минимальный выбор данных и условия их обновления при выполнении транзакций. Дополнительные навигационные шаги или операции по обработке записей базы данных, должны быть подробно описаны, а их цель должна быть подробна изложена. 2.3.3 Каждое свойство должно быть взято из соответствующей таблицы в профиле транзакции. Комментарий: Целью данной главы является предупреждение уменьшения числа логических операций с базой данных, необходимых для выполнения каждой транзакции. 2.3.4 Перед передачей данных в ТС, либо после передачи выходных данных от ТС к терминалу, больше никакие операции по обработке данных из профилей транзакций не должны выполняться. Комментарий: Цель данной главы – удостовериться, что до того, как зафиксирован момент начала транзакции RT, или после того, как зафиксирован момент ее окончания, никаких операций по обработке данных из профиля транзакций для данной деловой транзакции не проводилось (см. пункт 5.3). Например, в транзакции Новый Заказ, перед передачей входных данных в ТС, этой системе запрещено из таблицы ЗАКАЗЧИК извлекать какой-либо ряд, даже если этот ряд позже все же будет извлечен во время выполнения этой самой транзакции. 2.3.5 Если транзакции проходят или организованы в рамках ТС, то необходимы специальные мониторы отображения процесса транзакций или другое равноценное доступное программное обеспечение (далее именуемое ТМ) со следующими характеристиками/функциональностью: Операция – ТМ должен предусматривать:
Безопасность – ТМ должен предусматривать:
Администрирование/обслуживание – ТМ должен иметь заранее определенную способность выполнять централизованную, непрограммную (т.е., должно осуществляться стандартной программой, и не требовать дополнительного программирования) и динамическую настройку управления ресурсами ТМ, включая "железо", сеть, службы (одну или несколько), правила установки приоритетов организации очереди и т.д. Восстановление - ТМ должна иметь способность:
Четкость приложения – содержание сообщений, которыми обмениваются клиентские и серверные приложения, должно составляться исключительно ТМ. Клиентские и серверные программы не должны ничего знать о содержании этих сообщений или механизмах, лежащих в основе их формирования. Комментарий 1: Далее следуют примеры реализаций приложений, которые не соответствуют требованию прозрачности.
Комментарий 2: Цель данной главы состоит в поощрении использования универсальных, доступных мониторов транзакций, и в избегании использования программного обеспечения, разработанного исключительно для проведения контрольных измерений или другого ограниченного использования. Комментарий 3: Если СУБД или равнозначная ей программа строит индивидуальные сообщение для каждого пользователя, то не требуется никакой особой функциональности. Комментарий 1: Ниже приведены некоторые примеры типов ошибок, которые могут появиться в неправильной транзакции:
Комментарий 2: Точная информация, выводимая в отчете при появлении ошибки, является особенностью программы и не определяется требованием о сообщении ошибки. Деловая транзакция "Новый заказ" включает в себя ввод полной информации о заказе через единую транзакцию базы данных. Она представляет собой транзакцию "чтение-запись" средней сложности. Ее довольно часто используют, и она для удовлетворения потребностей пользователя имеет особые ограничения на время выполнения. Данная транзакция является основой рабочей нагрузки системы. Она разработана таким образом, чтобы для отражения он-лайн активности базы данных осуществлять переменную нагрузку системы. Это типично для прикладных сред. 2.4.1 Генерация входных данных 2.4.1.1 Для любого заданного терминала, номер главного склада (W_ID) постоянен для всего интервала измерений (Глава 5.5). 2.4.1.2 Номер точки продажи (D_ID) домашнего склада выбирается случайно в диапазоне от 1 до 10 (D_W_ID = W_ID). При помощи функции NURand(1023, 1, 30000) случайным образом выбирается номер заказчика (C_ID) данной точки продажи (C_D_ID = D_ID) данного домашнего склада (C_W_ID = W_ID). 2.4.1.3 Число позиций в заказе (ol_cnt) выбирается случайно в пределах от 5 до 15 (в среднем около 10). Это поле не заполняется, т.к. ее содержимое генерируется терминалом при определения размера заказа. Позже ТС рассчитывает значение O_OL_CNT, и отображает его на экране. 2.4.1.4 Для определения ошибок, допускаемых пользователем при вводе данных, и тестировании отката транзакции, случайным образом отбирается 1% транзакций "Новый заказ". Это делается путем генерации случайного значения rbk в диапазоне [1 .. 100]. Комментарий: Все транзакции "Новый заказ" должны иметь независимо сгенерированные входные данные. Данные, полученные при откате транзакции, не могут использоваться в последующих транзакциях. 2.4.1.5 В заказе для каждой из ol_cnt позиции: 1. При помощи функции NURand(8191,1,100000) случайным образом выбирается номер позиции (OL_I_ID). Если это последняя позиция в заказе, и при этом rbk = 1 (см. Пункт 2.4.1.4), то номеру позиции присваивают неиспользуемое значение. Комментарий: Неиспользуемым значением для номера позиции является число, не найденное в базе данных, и таким образом в прикладной программе возникнет событие "не найден". 2. Номер снабжающего склада (OL_SUPPLY_W_ID) в 99% случаев выбирается как номер домашнего склада, и в 1% случаев – как номер удаленного склада. Этого можно достичь генерацией случайного числа х в пределах от 1 до 100. Комментарий 1: В 90% случаев всего лишь около десяти разных товаров, указанных в заказе, можно поставить с домашнего склада. Комментарий 2: Если система настроена на использование одного склада, то все товары поставляются с этого склада. 3. Количество (OL_QUANTITY) выбирается случайно из [1 .. 10]. 2.4.1.6 Дата поступления заказа (O_ENTRY_D) генерируется ТС, используя текущие системные дату и время. 2.4.1.7 Если товар поставляется с домашнего склада (т.е., когда OL_SUPPLY_W_ID равно O_W_ID), то строку заказа называют "домашней". 2.4.1.8 Если товар поставляется с удаленного склада (т.е., когда OL_SUPPLY_W_ID не равно O_W_ID), то ее называют "удаленной". 2.4.2 Профиль транзакции 2.4.2.1 Ввод данных в новый заказ выполняется в одну транзакцию базы данных в следующем порядке: 1. Создайте заголовок заказа. Этот шаг включает в себя: Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакций, приведенном ниже. 2.4.2.2 Для заданных значений номера склада (W_ID), номера точки продаж (D_W_ID , D_ID), номера заказчика (C_W_ID , C_D_ID , C_ ID), количества товаров в заказе (ol_cnt, не переданных SUT) и для заданного числа товаров, поставляемых со складов (OL_SUPPLY_W_ID) в количестве (OL_QUANTITY):
2.4.2.3 Отмененная транзакция, может быть все же выполнена при соблюдении следующих этапов:
В данном случае выполнение транзакции отменяется. Комментарий 1: Цель этой главы состоит в том, чтобы удостовериться, что, в пределах транзакции Новый Заказ, в первую очередь будут обработаны все действующие, а не используемые в заказе номера товаров. Если известно, что какой-то номер товара не используется, то можно пропустить выполнение данной транзакции. Это не приведет к какой-либо оптимизации (т.е. изменению хода выполнения других действий, использованию транзакций других типов и т.д). Комментарий 2: Этот параграф является исключением к параграфу 2.3.1. Порядок обработки данных до появления сообщения "не найден" – не важен. 2.4.3 Терминал ввода/вывода. 2.4.3.1 Перед началом каждой транзакции терминал должен отображать экран ввода/вывода, приведенный ниже. В нем все поля, за исключением поля Склад, значение в котором не меняется и должно быть равным W_ID, должны быть заполнены либо пробелами, либо нулями. New Order – Новый Заказ. 2.4.3.2 В соответствующие поля пользователь должен ввести необходимые входные данные, которые разделены на 2 группы и устроены следующим образом:
Комментарий: Значение ol_cnt не может быть введено, т.к. оно должно рассчитываться программой во время обработки входных данных.
Комментарий: Для совпадения количества введенных символов, поле "поддерживающий склад" должно заполняться для каждого товара, даже если этот склад – "домашний". 2.4.3.3 Терминал должен отображать на экране все входные и выходные данные, получаемые в результате выполнения транзакции. Отображаемые на экране поля делятся на две группы, согласно следующему:
2.4.3.4 Для отмененных в результате неиспользуемого номера товара транзакций (1% от общего числа транзакций "Новый заказ"), терминал должен отображать следующие значения в соответствующих полях: W_ID, D_ID, C_ID, C_LAST, C_CREDIT, O_ID и в статусе выполнения транзакции должно отображаться сообщение "Номер товара неверен". Комментарий: Для подтверждения выполнения части транзакции, номер отмененного заказа, O_ID, должен отображаться на экране. 2.4.3.5 Следующая таблица подводит итог требований к терминалу ввода/вывода для транзакции "Новый заказ": 2.4.3.6. Главные требования терминала ввода/вывода см. в Главе 2.2. Транзакция "Оплата" обновляет баланс заказчика и отражает состояние оплаты в статистике склада и точки продажи. Она представляет собой упрощенную транзакцию чтения-записи, которая часто используется и имеет определенные требования ко времени выполнения. Кроме того, данная транзакция включает в себя ключ доступа к таблице ЗАКАЗЧИК, отличный от первичного. 2.5.1 Генерация входных данных 2.5.1.1 Для заданного терминала номер домашнего склада (W_ID) – постоянен на протяжении всего интервала измерений. 2.5.1.2 Номер точки продаж (D_ID) главного склада выбирается случайно в диапазоне от 1 до 10 из домашнего склада (D_W_ID = W_ID). Номер заказчика в 60% случаев выбирается по фамилии (C_W_ID , C_D_ID, C_LAST), и в 40% случаев – по его номеру (C_W_ID , C_D_ID , C_ID). Независимо от метода выбора, в 85% случаев постоянно обслуживающий заказчика склад – это домашний склад, а в остальных случаях – это удаленный склад. Это условие можно реализовать путем генерации 2х случайных чисел х и у в пределах [1 .. 100];
Комментарий: Этот случай показывает ситуацию, где заказчик не использует свой уникальный номер при оплате.
Комментарий: Если система настроена на один склад, то все заказчики выбираются из данного домашнего склада. 2.5.1.3 Сумма оплаты (H_AMOUNT) выбирается случайно из [1.00 .. 5,000.00]. 2.5.1.4 Дата оплаты (H_DATE) генерируется в ТС, использующей текущую дату и время. 2.5.1.5 Транзакция “Оплата” считается домашней, при условии, что “Оплата” производится через склад, к которому принадлежит Заказчик (при C_W_ID = W_ID). 2.5.1.6 Транзакция “Оплата” считается удаленной, если “Оплата” заказа производится через другой склад, к которому он не относится (при C_W_ID не равном W_ID). 2.5.2 Профиль транзакции 2.5.2.1 Транзакция “Оплата” вводит данные об оплате за одну транзакцию, и это включает в себя: Случай 1 – заказчик выбирается по номеру: выбор 3 рядов со считыванием и обновлением данных, вставку 1 ряда Случай 2 – заказчик выбирается по фамилии: выбор 2 рядов со считыванием данных, выбор 3 рядов со считыванием и обновлением данных, вставка 1 ряда. Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакции, приведенном ниже. 2.5.2.2 Для заданных значений номера склада (W_ID), номера точки продаж (D_W_ID , D_ID), номера заказчика (C_W_ID , C_D_ID , C_ ID) или его фамилии (C_W_ID , C_D_ID , C_LAST) и суммы платежа (H_AMOUNT):
Комментарий: Отображение формата на экране, используемого для хранения истории должно иметь четкий вид. (т.е. часть W_ID значения C_DATA должна иметь тот же формат для отображения на экране, что и поле W_ID).
2.5.3 Терминал ввода/вывода 2.5.3.1 Перед началом тестирования терминал должен отображать следующий экран вводы/вывода. На этом экране все поля должны быть очищены (либо заполнены нулями или пробелами). Для каждой транзакции в самом начале терминал должен отображать на экране приведенное ниже изображение, в котором все поля должны быть заполнены либо пробелами, либо нулями, за исключением поля Склад, которое не меняется и должно содержать фиксированное значение W_ID, связанное с этим терминалом. Кроме того, поля, отображающие данные об адресе склада (т.е., W_STREET_1, W_STREET_2, W_CITY, W_STATE, и W_ZIP), так же могут содержать фиксированные значения, если они были найдены в предыдущей транзакции. Payment – ««Оплата»» 2.5.3.2 В соответствующих местах экрана ввода/вывода пользователь должен ввести необходимые входные данные, которые организованы как отдельные поля: D_ID, C_ID или C_LAST, C_D_ID, C_W_ID, и H_AMOUNT. Комментарий: Для того чтобы количество введенных символов совпадало, поле "поддерживающий склад" должно заполняться для каждого товара, даже если этот склад – "домашний". 2.5.3.3 В соответствующих полях экрана ввода/вывода терминал должен отображать все входные и выходные данные, получаемые в результате выполнения транзакции. При этом отображаются следующие поля: W_ID, D_ID, C_ID, C_D_ID, C_W_ID, W_STREET_1, W_STREET_2, W_CITY, W_STATE, W_ZIP, D_STREET_1, D_STREET_2, D_CITY, D_STATE, D_ZIP, C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, C_BALANCE, первые 200 символов C_DATA (только если C_CREDIT = "BC"), H_AMOUNT, и H_DATE. 2.5.3.4 Следующая таблица подводит итог требований терминала ввода/вывода к транзакции "Оплата": 2.5.3.5. Основные требования терминала ввода/вывода приведены в параграфе 2.2. 2.6 Транзакция "Статус заказа" Транзакция "Статус заказа" запрашивает статус последнего заказа клиента. Она представляет собой средней сложности транзакцию чтения-записи, которая часто используется, и имеет определенные требования ко времени выполнения. Кроме того, данная транзакция включает в себя вторичный доступ к таблице ЗАКАЗЧИК. 2.6.1 Генерация входных данных 2.6.1.1 На протяжении всего временного интервала измерений для данного терминала номер домашнего склада (W_ID) не изменяется. 2.6.1.2 Для домашнего склада случайным образом из диапазона [1 ..10] выбирается номер точки продажи (D_ID). Для выбранной точки продажи (C_D_ID = D_ID) и домашнего склада (C_W_ID = W_ID) в 60% случаев заказчик выбирается по фамилии (C_W_ID, C_D_ID, C_LAST), и в 40% случаев – по номеру (C_W_ID, C_D_ID, C_ID). Это можно осуществить путем генерации случайного числа у из диапазона [1 .. 100].
Комментарий: Это событие описывает ситуацию, когда заказчик не пользуется своим уникальным номером.
2.6.2 Профиль транзакции 2.6.2.1 Запрос статуса заказа выполняется в одну транзакцию базы данных следующими этапами: 1. Требуется найти заказчика и его последний заказ. Этот этап включает в себя следующее: Случай 1 – заказчик выбирается по номерувыбора 2 рядов со считыванием данных Случай 2 – заказчик выбирается по фамилии: выбор 4 (в среднем) рядов со считыванием данных. 2. Проверить статус (дата доставки) каждого товара в заказе (в среднем 10 товаров на каждый заказ). Этот шаг включает в себя: выбор (1 * число товаров на заказ) рядов со считыванием данных.Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакции, приведенном ниже. 2.6.2.2 Для данного номера заказчика (C_W_ID , C_D_ID , C_ ID):
Случай 2 – заказчик выбирается по фамилии: в таблице ЗАКАЗЧИК выбираются все ряды с соответствующими значениями C_W_ID, C_D_ID и C_LAST и сортируются функцией C_FIRST по возрастанию. После сортировки выбирается ряд, находящийся на позиции n/2, округленной до целого (где n – число выбранных рядов), и в этом ряду находятся значения C_BALANCE, C_FIRST, C_MIDDLE, and C_LAST.
Комментарий: нет необходимости передавать данные, пока не обеспечены все условия атомарности, непротиворечивости, изолированности, долговечности (ACID) (см. главу 3).
2.6.3 Терминал ввода/вывода 2.6.3.1 Вначале тестирования терминал должен отображать следующий экран ввода/вывода. На этом экране все поля ввода и вывода должны быть очищены. Исключение составляет поле Склад, информация в котором не меняется и должна содержать значение W_ID, связанное с данным терминалом. Order-Status – статус заказа 2.6.3.2 Пользователь должен ввести все необходимые входные данные в соответствующие поля экрана ввода/вывода, которые определены как отдельные поля: D_ID и либо C_ID, или C_LAST. 2.6.3.3 На экране ввода/вывода терминал должен отображать все входные и выходные данные, полученные в результате выполнения транзакции. Отображаемые на экране поля делятся на две группы:
Комментарий 1: Порядок позиций в заказе, показанный на экране ввода/вывода "Статус Заказа", не обязательно должен соответствовать порядку, в котором они были введены в экран "Новый Заказ". Комментарий 2: При OL_DELIVERY_D равному нулю (т.е., заказ не был выполнен), терминал должен отображать особое нулевое представление даты (т.е., пробелы, 99-99-9999, и т.д.). Выбранная нулевая форма представления даты не должна меняться во время теста. 2.6.3.4 Следующая таблица подводит итог требований терминала к транзакции Статус Заказа: 2.6.3.5 Основные требования терминала ввода/вывода описаны в параграфе. Транзакция ”Доставка” включает в себя обработку пакета, состоящего из 10 заказов (еще не обработанных). Каждый заказ обрабатывается в полном объеме в рамках транзакции базы данных чтение/запись. Число обрабатываемых заказов в группе в пределах базы данных является особенностью реализации. Транзакция, состоящая из 1 или более (до 10) транзакций базы данных, выполняется редко, и должна обрабатываться в пределах заданного времени. Транзакция Доставка предназначена для выполнения в отложенном, т.е., через постановку в очередь, а не в интерактивном режиме. При этом терминал должен отображать сообщение о завершении транзакции. Результат обработки записывается в файл результатов. 2.7.1 Генерация входных данных 2.7.1.1 Для заданного терминала во время всех измерений номер домашнего склада (W_ID) не изменяется. 2.7.1.1 Номер перевозчика (O_CARRIER_ID) выбирается случайно в пределах [1 .. 10]. 2.7.1.3 Дата доставки (OL_DELIVERY_D) генерируется в ТС, основываясь на системной дате и времени. 2.7.2 Отложенное выполнение 2.7.2.1 В отличие от других транзакций данного контрольного тестирования, транзакция Доставка должна выполняться в отложенном режиме. Этот режим главным образом характеризуется постановкой ее в очередь, возвращением контроля исходному терминалу, не зависимо от завершения транзакции, и записью информации о выполнении транзакции в файл результатов. 2.7.2.2 Отложенное выполнение транзакции Доставка должно придерживаться следующих правил:
2.7.2.3 Файл результатов отложенной деловой транзакции Доставка предназначен исключительно для записи в него информации и не имеет никакого отношения к коммерческой деятельности. Файл результатов должен составляться согласно следующим правилам:
2.7.3 Терминал ввода/вывода 2.7.3.1 В начале тестирования терминал должен отображать следующий экран ввода/вывода. На этом экране все поля ввода и вывода должны быть очищены. Исключение составляет поле Склад, информация в котором не меняется и должна содержать значение W_ID, связанное с данным терминалом. Delivery - Доставка 2.7.3.2 В соответствующие поля экрана ввода/вывода пользователь должен ввести необходимую информацию, которая представляется одним полем точки продажи: O_CARRIER_ID. 2.7.3.3 В соответствующих полях экрана ввода/вывода терминал должен отображать все входные и выходные данные, поступающие в результате постановки транзакции в очередь. На экране отображаются следующие поля: W_ID, O_CARRIER_ID, а также статус-сообщение "Доставка поставлена в очередь". 2.7.3.4 Таблица, приведенная ниже, подводит итог требованиям терминала ввода/вывода к транзакции Доставка: 2.7.3.5 Основные требования терминала ввода/вывода описаны в параграфе 2.2. 2.7.4 Профиль транзакции 2.7.4.1 Отложенная транзакция Доставка, используя одну или более (до 10) транзакций базы данных, рассылает невыполненные заказы (со средним числом товаров на заказ, равным 10) по каждой из 10 точек продаж выбранного склада. Доставка каждого заказа выполняется в следующем порядке: 1. Заказ обрабатывается и включает в себя: 2. Обновляется баланс заказчика, содержащий: 3. Заказ удаляется из списка новых заказов и включает в себя: Комментарий: Данная деловая транзакция может быть выполнена либо одной транзакцией базы данных, или разбита на несколько частей (до 10 транзакций), что позволит пользователю, осуществляющему данное тестирование, выполнить ее наиболее эффективным количеством транзакций базы данных. Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакций, приведенном ниже. 2.7.4.2 Для данного номера склада (W_ID), для каждой из 10 точек продажи (D_W_ID , D_ID) данного склада, и для каждого номера перевозчика (O_CARRIER_ID):
2.8 Транзакция Уровень Запасов Деловая транзакция Уровень Запасов определяет число недавно проданных товаров, уровень запаса которых ниже определенного порогового значения. Эта транзакция представляет собой сложную транзакцию "только для чтения", которая редко выполняется, имеет низкий уровень требований ко времени выполнения и непротиворечивости. 2.8.1 Генерация входных данных 2.8.1.1 Каждый терминал должен использовать уникальное значение (W_ID, D_ID), которое не меняется на протяжении всего измерения, т.е., значения D_ID не могут повторно использоваться в пределах данного склада. 2.8.1.2 Минимальное количество запасов (порог) выбирается случайным образом в диапазоне [10 .. 20]. 2.8.2 Профиль транзакции 2.8.2.1 Проверка уровня запасов товаров из последних 20 заказов производится посредством выполнения одной транзакции базы данных в следующем порядке: 1. Проверяется следующий доступный номер заказа, который включает в себя: выбор 1 ряда со считыванием данных. 2. Проверяются все товары из последних 20 заказов (среднее число товаров в заказе равно 10). Этот этап включает в себя: выбор (20 * число товаров в заказе) рядов со считыванием данных. 3. Для каждого отдельного товара на домашнем складе проверяется, не является ли уровень запасов ниже определенного порогового значения. Это действие включает в себя:
Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакций, приведенном ниже. 2.8.2.2 Для заданных значений номера склада (W_ID), номера точки продаж (D_W_ID , D_ID) и порогового значения уровня запасов:
Комментарий: Запасы должны рассчитываться только для отдельных товаров. Таким образом, товары, встречающиеся более одного раза в 20 избранных заказах, должны быть собраны в одно итоговое значение для данного товара.
Комментарий: Не нужно выполнять транзакцию, пока не удовлетворены все требуемые ACID свойства (см. пункт 2.8.2.3).
2.8.2.3 Для деловой транзакции Уровень Запасов не требуется проводить полного упорядочивания и многократного считывания данных. Еще до запуска транзакции все считывания должны быть выполнены не позже, чем самые последние данные были обработаны. Все остальные ACID свойства должны быть учтены. Комментарий: Данный параграф позволяет разбивать транзакцию на несколько частей. 2.8.3 Терминал ввода/вывода 2.8.3.1 В начале тестирования терминал должен отображать следующий экран ввода/вывода. На этом экране все поля ввода и вывода должны быть очищены. Исключение составляют поля Склад и Точка Продаж, информация в которых не меняется и должна содержать значения W_ID и D_ID, связанные с данным терминалом. Stock-Level – Уровень Запасов 2.8.3.2 Пользователь должен ввести необходимую информацию в соответствующее поле (threshold) экрана ввода/вывода. 2.8.3.3 Терминал должен отобразить в соответствующем поле экрана ввода/вывода всю входную и выходную информацию, полученную в результате выполнения транзакции. Должны отображаться следующие поля: W_ID, D_ID, threshold и low_stock. 2.8.3.4 Следующая таблица подводит итог требований терминала ввода/вывода к транзакции Уровень Запасов. 2.8.3.5 Основные требования терминала ввода/вывода описаны в параграфе. |
Статья: Глава 2 - ТРАНЗАКЦИИ и ПРОФИЛИ ТЕРМИНАЛА |
Перейти на главную страницу компании "Софтпоинт" |