С точки зрения Тестера, под бизнес логикой понимается влияние, оказываемое действиями пользователя на состав и корректность данных информационной системы.
Например, при вводе документа Заказ поставщику , все движения, сформированные этим документом попадают под понятие бизнес логика.
Проверка бизнес логики в Тестере может быть осуществлена двумя способами:
- Можно сформировать отчет о движениях документа и сверить эти движения с эталоном.
- Можно сформировать отчет или группу отчетов для анализа последствий изменения данных.
Оба способа основаны по проверке данных отчетов/печатных форм тестируемого приложения с эталонными данными, хранящимися в самом тесте.
Ниже, будет рассмотрен пример проверки бизнес логики на основании отчета о движениях документа. Проверка логики отчетами, может быть осуществлена похожим образом.
Процессы ниже будут рассмотрены на примере тестирования конфигурации ERP2.
Подготовка эталона¶
Итак, мы проверяем бизнес логику через отчет о движениях документа.
Понятие информационной системы ИС, классификация ИС | Информатика 10-11 класс #22 | Инфоурок
Для этого нам необходимо иметь в Тестере сохраненный табличный документ с макетом сформированных движений, которые мы считаем правильными.
За получением макета мы должны идти в тестируемое приложение. Там, необходимо сформировать отчет о движениях тестируемого документа, скопировать результат в буфер обмена ( Ctrl+A , Ctrl+C ), затем, переключиться в Тестер и вставить скопированное в разрабатываемый тест, на вкладку Шаблон .
Результат таких действий показан на картинке ниже (фактически, на картинке показан уже модифицированный вариант шаблона, детали ниже):
Области проверки¶
Тестер позволяет производить сравнение табличных документов полностью или по выделенным областям.
В целях ускорения прохождения теста, и исключения ложного срабатывания на проверке незначимых, с точки зрения бизнес логики, данных, рекомендуется явно задать проверяемые области макета.
Задание областей осуществляется по правому клику в поле табличного документа, на картинке ниже, красной штрих линией выделена проверяемая область:
Автоподстановки¶
Кроме задания областей, тестируемые данные могут быть модифицированы для того, чтобы проводить тестирование во времени, в условиях меняющихся значений данных.
Например, движения документа могут содержать такие данные как: дата записи, номер и дата документа. Так как документы могут проводиться в разное время, часть этих данных в тестируемом приложении может постоянно меняться.
Стратегии тестирования могут быть разными, но если имеют место случаи, когда часть данных изменчива, и не требует жесткой проверки на соответствие, разработчик теста может в шаблоне использовать автоподстановочные символы:
Они работают следующим образом:
Бизнес-логика программных систем. Раздел 1: Введение.
- . Означает, что в поле должно быть значение, начинающееся с текста “Заказ поставщику”, а дальше не важно
- . Тот же смысл, что и в п.1
- . Означает, что в данном поле должно быть хоть какое-то значение. Если значения при проверке не окажется – будет вызвано исключение.
Проверка строк не чувствительна к регистру
Для задания автоподстановок, можно использовать специальный помощник, вызываемый правым кликом на поле таблицы:
Кроме описанных возможностей, также доступна программная подготовка шаблона для проверки. Подробнее читайте Как параметризировать шаблон сценария?
Источник: test1c.com
Создание бизнес логики
База данных состоит из таблиц, хранящих информацию о следующих объектах – клиенты, заказы, инженеры, детали, виды расчета.
Созданная база данных представляет собой структурированную информацию о работе инженера по сервисному обслуживанию (эта информация хранится в пяти связанных таблицах) и предоставляет возможность работы с ней с помощью соответствующего программного продукта.
Первая таблица «Клиенты» содержит следующую информацию: номер клиента, ФИО клиента, адрес клиента, телефон клиента.
Во второй таблице «Заказы» хранится информация о номере заказа, Дате приема оборудования, номере клиента, номере инженера, номере детали, номере вида расчета, дате выдачи оборудования и стоимости ремонта.
Третья таблица «Детали» содержит сведения о номере детали, о наименовании детали, о технических характеристиках, о производителе.
В четвертой таблице «Инженеры» хранится информация о номере инженера, ФИО инженера, содержит телефон и адрес.
Для полей таблиц нужны различные типы данных. Задаем их согласно предполагаемым записям (см. таблицу 1, таблицу 2).
Таблица №1 – Создание доменов
| Имя домена | Тип | Длина | Not Null | Ограничения |
| D_INDEX | smallint | + | >0 | |
| D_NAME | varchar | 50 | ||
| D_STOIM | varchar | 10 | ||
| D_DATE | DATE | |||
| D_ADRES | varchar | 50 | ||
| D_TELEPHONE | varchar | 15 |
Таблица 2 – Создание таблиц и определение их типов полей
Создали таблицы с помощью запроса SQL. Это можно увидеть по рисунку 4, рисунку 5, рисунку 6, рисунку 7, рисунку 8.
Рисунок 4 — Создание таблицы “Клиенты”
Рисунок 5 — Создание таблицы “Детали ”
Рисунок 6 — Создание таблицы “Инженер”
Рисунок 7 — Создание таблицы “Расчеты”
Рис. 8 – Создание таблицы «Заказы»
Далее были созданы генераторы и триггеры. Генератор представляет собой механизм, создающий уникальную последовательность чисел и автоматически заполняющий заданное поле при вставке или обновлении записей. Генераторы, как правило, используются в хранимых процедурах для автоматического заполнения поля (полей), входящих в первичный ключ.
Триггер является функцией, выполняющейся при вставке, изменении или удалении записи. Триггеры могут определяться как для таблиц, так и для обновляемых представлений.
Рис. 9. Список генераторов
В результате было создано по 5 триггеров и генераторов:
Рис. 10. Генераторы и триггеры базы данных
Представление «Список клиентов» (CLIENT_INFO)
Рисунок 11 — Создание просмотра CLIENT_INFO
Рисунок 12 — Результат просмотра CLIENT_INFO
Аналогичным образом были созданы представления остальных таблиц.
Примеры создания хранимых процедур:
Процедура «Добавить клиента» (ADD_CLIENT)
Рисунок 13 — Создание хранимой процедуры ADD_ CLIENT
Процедура «Удалить заказ» (DEL_ZAK)
Рисунок 14 — Создание хранимой процедуры DEL_ZAK
Рисунок 15 — Список созданных хранимых процедур
Было создано исключение. Исключения представляют собой именованное сообщение об ошибке.
Рисунок 16 — Список созданных исключений
Исключение KEY_EX внедряется следующим образом:
Рисунок 17 — Исключение KEY_EX в хранимой процедуре. На примере процедуры ADD_ZAK.
2.3 Реализация программного средства «Автоматизированное рабочее место инженера по сервисному обслуживанию компьютерной техники»
C++Builder предоставляет разработчикам следующие компоненты для разроботки приложений:
· Компоненты управления данными Data Control, обеспечивающие отображение и редактирования записей на форме приложения.
· Компоненты вкладки Standart (Button, Label, Edit, RadioButton, CheckBox, RadioGroup, Panel)
· Компоненты доступа к данным Data Access — адресуют фактические данные, хранящиеся в файле базы данных.
· Компоненты вкладки QReport (QuickRep, QRSubDetail, QRLabel, QRDBText, QRBand, QRSysData), создание отчетов
· Компоненты Interbase (IBDatabase, IBTransaction, IBTable, IBStoredProc)
Наличие на форме большого количества невидимых компонентов в ряде случаев затрудняет проектирование пользовательского интерфейса. Кроме того, нередко бывает удобно отделить компоненты, отвечающие за доступ к данным и бизнес-логику информационной системы, от интерфейсных элементов, например, для обегчения ее дальнейшей модернизации. Для этой цели в C++ Builder имеется специальный тип, называемый модулем данных — TDataModule. На рис.18 представлен модуль данных разрабатываемого клиентского приложения.
Рисунок 18 — Компонент DataModule2
Рисунок 19 — Результат заполнения таблицы “Клиенты ”
Рисунок 20 — Результат заполнения таблицы “Заказы”
Рисунок 21 — Результат заполнения таблицы “Детали”
Рисунок 22 — Результат заполнения таблицы “Инженеры”
Рисунок 23 — Результат заполнения таблицы “Виды расчета”
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Сервер бизнес-логики. (трехуровневая архитектура)
Промежуточный сервер
Пользовательский
Бизнес-логика интерфейс
второго уровня
 |
 |
Сервер БД
Пользовательский
Модель с физически выделенным в отдельное приложение блоком BL, таким образом получаем трехуровневую архитектуру “клиент-сервер”. На сервере БД может функционировать “универсальная” часть бизнес-логики (правила на уровне предприятия или группы связанных приложений). Такая схема позволяет поддерживать тонких клиентов на пользовательских компьютерах и в то же время разгрузить сервер БД от чрезмерной загрузки при сохранении гибкой системы работы с бизнес-правилами. В качестве промежуточного сервера может использоваться второй SQL-сервер, но чаще рациональней задействовать персональную СУБД, которая менее требовательна к аппаратным ресурсам и может обеспечить удобные средства построения и поддержки бизнес-логики.
3. Программные средства разработки 3.1. Универсальные средства
Для разработки клиентских приложений существует громадное число универсальных пакетов программ, которые позволяют выполнить соединение с сервером и разработать для пользователя удобный графический интерфейс, позволяющий эффективно работать с данными. Некоторые из этих средств для разработки приложений в архитектуре “клиент-сервер” перечислены в таблице.
Источник: kazedu.com