Какие менял форматы данных

Мои практики работы с форматами данных в QA

В рамках тестирования веб- и мобильных приложений, API, ETL-процессов и систем интеграции я сталкивался с широким спектром форматов данных. Работа с ними — неотъемлемая часть валидации корректности обмена информацией между системами, клиентом и сервером, а также проверки бизнес-логики.

Основные категории форматов

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

• Текстовые структурированные форматы (для API и конфигураций):

    *   **JSON (JavaScript Object Notation):** Самый распространенный формат для REST API. Использую для создания тестовых данных, валидации ответов сервера, написания assertions в автотестах.

    ```json
    {
      "user": {
        "id": 12345,
        "name": "Иван Тестов",
        "email": "test@example.com",
        "subscription": "premium"
      }
    }
    ```

    *   **XML (eXtensible Markup Language):** Часто встречается в legacy-системах, SOAP API, конфигурациях и данных от внешних поставщиков (например, банковские выписки).

    ```xml
    <Order>
      <OrderID>1001</OrderID>
      <CustomerName>ООО "Ромашка"</CustomerName>
      <Items>
        <Item SKU="A123">Тестовый товар</Item>
      </Items>
    </Order>
    ```

    *   **YAML/ЯML (YAML Ain't Markup Language):** Используется для конфигурационных файлов (например, Docker Compose, CI/CD пайплайны в GitLab CI/GitHub Actions), где важна читаемость.

    ```yaml
    api_testing:
      base_url: "https://api.example.com"
      endpoints:
        login: "/auth/login"
        profile: "/user/profile"
      credentials:
        username: "qa_user"
    ```

• Форматы для передачи данных и сериализации:

    *   **Protocol Buffers (protobuf) от Google:** Бинарный формат, часто используемый в gRPC API. Для работы с ним необходимо предварительно компилировать `.proto`-файлы, описывающие структуру сообщений. Тестирование включает проверку корректности сгенерированных классов и передачи данных.
    *   **MessagePack, BSON:** Бинарные альтернативы JSON. Проверял их использование в высоконагруженных системах, где критичен размер передаваемых данных.

• Форматы данных в базах данных (для проверки persistence-слоя):

    *   **Реляционные (SQL):** Проверял корректность сохранения данных в таблицах MySQL, PostgreSQL. Писал сложные SQL-запросы для извлечения данных и сверки с ожидаемым состоянием системы.

    ```sql
    -- Пример запроса для проверки состояния заказа после выполнения бизнес-процесса
    SELECT status, updated_at FROM orders WHERE id = 1001;
    ```

    *   **Документоориентированные (NoSQL):** Работал с **MongoDB (BSON-документы)**, проверяя вложенные структуры и массивы.
    *   **Ключ-значение (Redis):** Тестировал корректность TTL (время жизни) ключей, сериализацию сложных объектов.

• Форматы файлов для импорта/экспорта и отчетности:

    *   **CSV/TSV (Comma/Tab-Separated Values):** Тестирование функциональности выгрузки отчетов и пакетной загрузки данных (например, загрузка прайс-листов). Критически важна проверка кодировки (UTF-8, Windows-1251), разделителей, экранирования кавычек.
    *   **Excel (XLSX/XLS):** Аналогично CSV, но с дополнительной сложностью — проверка формул, нескольких листов, форматирования.
    *   **PDF:** Проверка генерации счетов, договоров, актов. Использовал как визуальное сравнение (например, через Sikuli), так и извлечение текста библиотеками (например, `pdfplumber` в Python) для текстовой валидации содержимого.

    ```python
    # Пример фрагмента кода на Python для проверки текста в PDF
    import pdfplumber

    with pdfplumber.open("invoice.pdf") as pdf:
        first_page = pdf.pages[0]
        text = first_page.extract_text()
        assert "ИНН 1234567890" in text, "Реквизиты не найдены в документе"
    ```

• Специфические и промышленные форматы:

    *   **EDI (Electronic Data Interchange):** Стандарты типа **EDIFACT** или **X12** для обмена данными между компаниями (логистика, ритейл). Требовалась тщательная проверка структуры сегментов и тегов.
    *   **Логи и трассировки:** **Неструктурированный текст**, **JSON Lines**, формат **W3C**. Анализировал логи для поиска причин дефектов, проверял корректность записей аудита.

Ключевые аспекты тестирования форматов данных

В процессе работы я фокусировался не только на знании синтаксиса, но и на глубокой проверке:

1. Валидность и парсинг: Корректно ли данные разбираются парсером (валидный JSON/XML), нет ли ошибок кодировки.
2. Структура (Schema Validation): Соответствует ли данные ожидаемой схеме (JSON Schema, XSD для XML, .proto для gRPC). Это основа контрактного тестирования API.
3. Содержимое данных: Корректность бизнес-логики: значения полей, форматы дат, обязательность атрибутов, граничные значения.
4. Преобразования (Transformation): Корректность конвертации между форматами (например, XML -> JSON в промежуточном микросервисе, или объект БД -> ответ API).
5. Производительность: Насколько объемные файлы (большие XML, JSON) обрабатываются системой, не вызывая падение по памяти или времени.

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