В чём разница между Core DDL скриптов от Core TML?

Различие между Core DDL и Core TML: контекст тестирования OTM

Прежде всего, важно прояснить, что вопрос касается специализированной области тестирования приложений для управления транспортировкой (Transportation Management Systems, TMS), а именно Oracle Transportation Management (OTM) или аналогичных систем. В этом контексте Core DDL (Data Definition Language) и Core TML (Transportation Management Language) представляют собой фундаментально разные уровни работы с системой, и понимание этой разницы критически для планирования тестирования, анализа воздействия изменений и валидации данных.

Core DDL: Уровень определения и структуры данных

Core DDL относится к набору базовых скриптов на языке SQL, которые определяют структуру базы данных OTM. Это "скелет" системы. Их основная функция — создание, модификация или удаление объектов базы данных: таблиц, индексов, ограничений (constraints), последовательностей (sequences), триггеров.

• Назначение: Первоначальная установка (installation), обновление версии (upgrade), применение исправлений (patches). DDL-скрипты изменяют саму схему данных.
• Влияние: Выполнение DQL-скриптов — операция высокого риска. Неправильный скрипт может привести к потере данных, нарушению целостности или простою системы.
• Контекст тестирования для QA:

    *   **Тестирование обновлений (Upgrade Testing):** Обязательная проверка того, что новые DDL-скрипты из патча или новой версии применяются корректно, не конфликтуют с существующими кастомизациями и не ломают функциональность.
    *   **Валидация схемы (Schema Validation):** Проверка соответствия структуры БД после применения скриптов эталонной или ожидаемой схеме.
    *   **Откат (Rollback Testing):** Проверка, что скрипты отката (rollback scripts) работают корректно и возвращают БД в стабильное состояние.

Пример Core DDL-скрипта (создание таблицы):

CREATE TABLE shipment (
    shipment_gid VARCHAR2(50) NOT NULL,
    status VARCHAR2(30),
    source_location_gid VARCHAR2(50),
    dest_location_gid VARCHAR2(50),
    total_weight NUMBER,
    CONSTRAINT pk_shipment PRIMARY KEY (shipment_gid),
    CONSTRAINT fk_src_loc FOREIGN KEY (source_location_gid) REFERENCES location(location_gid)
);

Core TML: Уровень бизнес-данных и конфигурации

Core TML (или Core Data TML) — это набор XML-файлов, содержащих базовые бизнес-данные и эталонные конфигурации системы. Это "стартовый набор" или "эталонные данные" для работы OTM. TML (Transportation Management Language) — это сериализованное XML-представление внутренних объектов OTM.

• Назначение: Инициализация системы стандартными справочниками, настройками, базовыми бизнес-объектами. Например: стандартные единицы измерения, типы услуг, базовые роли пользователей, конфигурации профилей.
• Влияние: Загрузка TML импортирует или обновляет данные в системе, а не её структуру. Конфликты могут возникать при слиянии с существующими кастомизированными данными.
• Контекст тестирования для QA:

    *   **Тестирование целостности данных (Data Integrity Testing):** Проверка, что после загрузки Core TML все системные справочники заполнены корректно и связи между объектами работают.
    *   **Регрессионное тестирование (Regression Testing):** Убедиться, что новые версии Core Data не сломали существующую, уже настроенную под клиента, функциональность.
    *   **Тестирование миграции данных (Data Migration Testing):** Если Core TML обновляется, необходимо проверить корректность преобразования (трансформации) существующих пользовательских данных под новую эталонную структуру.

Пример Core TML-объекта (фрагмент описания единицы измерения):

<TransMeasUnit xmlns="http://www.tmxml.com/">
    <TransMeasUnitGid>
        <Gid xmlns="http://www.tmxml.com/">
            <DomainName>PUBLIC</DomainName>
            <Xid>KGM</Xid>
        </Gid>
    </TransMeasUnitGid>
    <BaseMeasUnitGid>
        <Gid xmlns="http://www.tmxml.com/">
            <DomainName>PUBLIC</DomainName>
            <Xid>KGM</Xid>
        </Gid>
    </BaseMeasUnitGid>
    <Description>Килограмм</Description>
    <IsBaseUnit>true</IsBaseUnit>
    <Factor>1.0</Factor>
</TransMeasUnit>

Ключевые различия в сводной таблице

Стратегия тестирования для QA-инженера

Для всестороннего тестирования изменений, затрагивающих Core DDL или Core TML, я бы реализовал следующий план:

1. Изоляционное тестирование (Sandbox Testing): Первичный прогон всех скриптов и файлов в изолированном окружении, идентичном продовольственному.
2. Сравнение схем (Schema Diff): Использование инструментов (например, Redgate, Liquibase) для автоматического сравнения схемы БД до и после применения DDL.
3. Сквозные тесты (End-to-End): Выполнение ключевых бизнес-сценариев (создание отгрузки, планирование, финансовые расчеты) после обновления, чтобы убедиться, что взаимодействие между новыми структурами (DDL) и новыми данными (TML) работает корректно.
4. Проверка целостности ссылок (Referential Integrity): После загрузки TML обязательная проверка, что все внешние ключи (GID ссылки) разрешаются в существующие объекты.

Вывод: Core DSL и Core TML — это два взаимосвязанных, но принципиально разных строительных блока системы управления транспортировкой. DDL формирует инфраструктуру, а TML — её базовое наполнение. Эффективный QA-инженер в домене OTM должен чётко разграничивать риски и подходы к тестированию для каждого из них, фокусируясь на стабильности схемы данных для DDL и на консистентности и бизнес-корректности для TML.