Home

Оригинальная публикация
Автор: Сергей Терентьев

Пролог

Проекты бывают разные, простые и сложные, с хорошей и плохой документацией, стартапы и проекты с солидным (часто не очевидным) легаси, и тд. При этом для каждого проекта можно подобрать свой набор QA процессов и инструментов, который даст возможность достичь требуемого качества.

О статье и общая проблематика

В этой статье я расскажу о виде тестирования, который мне ранее не встречался в стандартных QA источниках, при этом нечто очень похожее используется в направлении Data Engineering. Этот вид тестирования показал свою эффективность в тех случаях, когда у вашего проекта есть следующие особенности:

• это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сосмнения), что их воспоминания о фактическом поведении “серой логики” верны 

• на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”

• сам проект уже в production

• при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)

Согласитесь, не так, чтобы эти условия были какой-то редкостью).

Погружаемся глубже в вопрос - “Зачем”?

Перед тем как ответить на вопрос “что же нам с этим делать?”, давайте поглубже копнем в сам вопрос - “Зачем нам вообще что-то с этим делать?”.

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

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

Предположим, что при наличии разных поставщиков данных нет полной уверенности (а когда она была в нашей-то профессии:-)) в том, что обработка данных от одного из них не приведет к резкому увеличению затрат ресурсов

В сухом остатке мы имеем кейсы, которые на проекте с вышеупомянутыми (в прошлом разделе) особенностями, вполне вероятно не будут выявлены тестированием перед релизом нового функционала. Конечно, есть вероятность, что на проекте есть prod like окружение с постоянно обновляющимися данными из production (после их предварительного обезличивания) - но как правило это очень дорого, а значит редко встречается на практике.

Как справиться с подобными кейсами на проекте?

Единственное место, где мы можем проверить: “а действительно ли такое когда либо было, а если было, то когда и как часто”, - это БД на production окружении. В связи с этим речь пойдет именно о валидации уже имеющихся на production данных с целью (нашей извечной) найти отклонения между ожиданием и реальностью.

Что нам необходимо понимать прежде чем работать с БД на production окружении? 

1. наши действия не должны вызывать изменения существующих сущностей. Только чтение, никакой записи.

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

3. наши действия не должны заафектить производительность БД

Рекомендую, перед применением каких-либо скриптов в production окружении, уточнить безопасность применения этих скриптов у Database administrator (с учетом вышеописанных критериев).

Подсвечу, что в Data Engineering похожие проверки используются для определения качества данных на этапе сбора дата сетов. Например для обучения ИИ моделей или для анализа какой-либо статистики. Но в этих случаях полученные данные намерено подвергаются изменению (удаляются поля, усредняются выбросы и т.д.), а в наших кейсах нам важно зафиксировать сам факт наличия отклонений (и возможно приступить к локализации причин). Все используемые в Data Engineering проверки перенимать не имеет смысла, многие из них в наших случаях часто избыточны, так как рестрикции на уровне БД не дадут нарушить определенные условия. Примеры излишних проверок:

• Тесты ссылочной целостности (Referential Integrity)

• Тесты уникальности (Uniqueness tests)

• Струнные узоры (String patterns)

Что же нам стоит взять на вооружение? Из своего опыта, могу выделить те проверки, которые хорошо вписываются в наши задачи (Software QA), но сначала опишем "легенду" БД на вымышленном проекте, чтобы изучая примеры можно было проще погрузиться в тот или иной случай.

Легенда

Описание таблиц будет без погружения в ограничения и форматы, оно служит только для получения общего представления о гипотетической ситуации. Для “легенды” представим, что в нашей БД с помощью нескольких таблиц отражены взаимосвязанные сущности поставок продуктов на фестиваль:

Таблица unified_fest (фестивали на которые будут поставляться продукты питания) с колонками:

id- первичный ключ

name- имя фестиваля 

start_date- дата начала фестиваля

end_date- дата конца фестиваля

Таблица technical_supply (технические поставки продуктов на фестивали) с колонками:

id - первичный ключ

unified_fest_id - внешний ключ принадлежности поставки к фестивалю (таблица unified_fest)

is_active_state - активность технической поставки

contractor - поставщик

start_date - дата начала поставки

end_date - дата конца поставки

Таблица product_sets (категории продуктов, поставляемые в рамках технической поставки) с колонками:

id - первичный ключ

category_type_id - идентификатор категории продукта по внутреннему справочнику

Таблица products (продукты, поставляемые в рамках технической поставки) с колонками:

id - первичный ключ

product_set_id - внешний ключ к таблице product_sets 

product_type_id - тип продукта по внутреннему справочнику

trade_category_id - категория продукта по классификации регулятора (также по справочнику)

name - название продукта/товара 

price - цена продукта/товара 

technical_supply_id - внешний ключ к таблице technical_supply

Проверки данных

Ниже представлен список вероятных проверок, которые стоит рассмотреть для использования.

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

WITH valid_product_sets AS (
    SELECT p.product_set_id
    FROM products p
    JOIN technical_supply ts ON p.technical_supply_id = ts.id
    WHERE ts.is_active_state = TRUE
    GROUP BY p.product_set_id
    HAVING COUNT(DISTINCT p.technical_supply_id) > 1
)
SELECT DISTINCT ON (p.product_set_id, p.technical_supply_id) p.id, p.technical_supply_id, ts.contractor, ts.is_active_state, p.product_set_id
FROM products p
JOIN technical_supplies ts ON p.technical_supply_id = ts.id
JOIN valid_product_sets vps ON p.product_set_id = vps.product_set_id
WHERE ts.is_active_state = TRUE
ORDER BY p.product_set_id, p.technical_supply_id, p.id
LIMIT 1000;

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

3. наличие пустых (""/null) значения в ячейках, где это запрещено только бизнес логикой, и не запрещено ограничениями на уровне БД

SELECT *
FROM unified_fest
WHERE name IS NULL
   OR TRIM(name) = '';

4. аномальное количество записей для какой-нибудь объединяющей сущности в со-зависимой таблице

SELECT 
    uf.id,
    uf.name,
    ts.contractor,
    COUNT(ts.id) AS supply_count
FROM unified_fest uf
JOIN technical_supply ts 
      ON ts.unified_fest_id = uf.id
GROUP BY 
    uf.id,
    ts.contractor
HAVING 
    COUNT(ts.id) > 100;

5. наличие записей меньше нуля там, где это недопустимо

SELECT * FROM products WHERE price <= 0;

6. разсогласованность связанных дат

SELECT ts.*
FROM technical_supply ts
JOIN unified_fest uf 
    ON ts.unified_fest_id = uf.id
WHERE ts.start_date > uf.end_date;

7. несовпадение ожидаемого формата записи в полях, которые это позволяют

SELECT * FROM unified_fest
WHERE name ~* '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$';

SELECT * FROM unified_fest WHERE name ~ '^[0-9]+$';

Самое приятное то, что все эти проверки как правило очень экономны. Они не занимают много времени на написание скриптов и могут быть оптимизированы для быстрого выполнения в БД. Нам не обязательно выгружать все миллионы записей с найденными совпадениями по условиям. Нам достаточно первых N записей, чтобы подтвердить гипотезу и начать расследование причин. Более того запуск SQL скриптов при необходимости отлично автоматизируется и при желании может быть использован в пайплайнах.

Заключение

Подобные проверки можно проводить перед реализацией новой логики, которая опирается на сомнительные парадигмы поведения сущностей, подверженных влиянию “серой логики”. Также проверки можно включить в рамки пост релизных мероприятий, выполняемых после деплоя очередного инкремента в production (через какой-то временной период). Особенно полезно это на тех проекта, где идет активная работа с легаси логикой.

Подведем итог, мы имеем выделенный процесс тестирования со строго определенным набором атрибутов:

• исследуемые объекты - данные из БД

• окружение источника данных - production

• ограничения для операций - минимальное влияние на источник данных

• цель - поиск отклонений в поведении ранее реализованного функционала, при отсутствии уверенного понимания логики работы этого самого функционала

Хочу заметить, что я не смог однозначно отнести подобное тестирование к какому либо набору видов тестирования, описанных в ISTQB. Рискну предположить, что напрашивается выделение отдельного вида тестирования, отражающего валидацию ранее реализованной логики в условиях production окружения с обязательным ожиданием для накопления проверяемых данных в естественных условиях.

Обсудить в форуме