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

Я работал над веб-приложением «Управление коллекциями музеев» с открытым исходным кодом, которое будет использоваться для отслеживания экспонатов музея, которые были приобретены, переданы в дар, взяты в аренду или иным образом приобретены.

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

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

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

Путаница приходит с упоминанием о тестировании «Качество данных». В статье выше автор упоминает, что вы хотите проверить следующие тесты:

• Столбец правила значения домена
• Правила значений по умолчанию для столбцов
• Правила существования стоимости
• Правила стоимости строк
• Правила размера

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

Полный ответ на этот вопрос будет очень долгим. Я постараюсь упомянуть основные моменты.

Чтобы разделить проблемы, вы можете посмотреть на тесты, чтобы:

A - Проверьте проект базы данных.

B - Проверьте, что программа (ы) правильно взаимодействует с базой данных.

Проверка проекта базы данных должна выполняться лицом (лицами), которые проектировали базу данных. Разработчики (во время модульного тестирования) должны больше заботиться о части (B). Основное различие, которое я вижу между двумя типами тестов, заключается в используемых инструментах. Для (A) вы будете использовать среду, независимую от кода проекта, тогда как для (B) вы, конечно, будете использовать код проекта. В следующем тексте я буду смешивать оба.

Чтобы ответить на ваши конкретные вопросы:

Столбец правила значения домена

Каждый столбец имеет связанный тип данных. Каждый столбец должен быть проверен на соответствие бизнес-правилам, чтобы доказать, что он представляет правильный тип данных. Могут возникнуть проблемы, если тип данных столбца несовместим с бизнес-требованиями или если код использует тип данных, отличный от того, как он определен в базе данных.

Например:

• Если столбец определен как small int, вы не сможете хранить в нем текст. Это важный тест, особенно когда столбцы являются необязательными, поскольку они могут остаться незамеченными, пока кто-то не введет в них некоторые данные.

• Не могли бы вы сохранить отрицательное значение в столбце, где бизнес требует, чтобы это произошло?

Правила значений по умолчанию для столбцов

Некоторые столбцы связаны со спецификацией значения по умолчанию в DDL (Data Def. Language), где, если во время вставки вставка не предоставляет значение, база данных примет значение по умолчанию. Это можно проверить, не передавая значение и наблюдая за значением результата, которое хранит база данных. Этот тест может также включать проверку столбцов Nullable. Для этого редко требуется тест, поскольку его можно проверить с помощью DDL, если в столбце не создан уникальный индекс.

Правила существования стоимости

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

Правила стоимости строк

Мне не ясно, что именно это означает.

Правила размера

Каждый столбец имеет размер в базе данных в зависимости от того, как он определен в DDL. Вы хотите убедиться, что любое значение, которое соответствует требованиям (введенное в графическом интерфейсе или полученное в результате вычисления), будет правильно храниться в столбце. Например, тип данных Small Integer не позволяет хранить значение 5 миллиардов. Кроме того, имя, определенное как VARCHAR2 (30), не будет содержать 40 символов, поэтому бизнес-правила должны быть здесь очень четкими, особенно когда столбец используется для агрегирования данных. Вы хотите проверить, что происходит в таких ситуациях.

руководство о том, как / с чего начать

Один из способов сделать это - разработать план тестирования. Вы хотите убедиться, что используете правильную версию спецификаций (таких как документы с требованиями и варианты использования) и программного обеспечения. Вам также необходимо согласовать эти тесты с тестами, выполненными модульным тестированием (если есть). Вы можете найти дубликаты тестов, которые вам не нужно выполнять снова. Вы хотите взять копию базы данных перед тестированием, чтобы при необходимости можно было повторить конкретный тест. Администратор базы данных может помочь вам в этом. Вы также должны уточнить у своей команды, как они документируют эти тесты, и проверить объем тестирования с ними. Вы можете разбить вашу базу данных на логические части и начать тестирование каждой логической части отдельно. Процесс тестирования может начаться с изучения DDL базы данных и проверки правильности определения столбцов в соответствии с требованиями бизнеса. Вы должны использовать программное обеспечение приложения, а не какой-либо другой инструмент для выполнения большинства тестов. Например, вопрос следующий:

• Предполагается, что столбец имеет определенный тип (нет смысла делать имя как Int).

• Совместим ли размер с требованиями бизнеса?

• Все ли столбцы в бизнес-требованиях найдены в базе данных?

• Пустые столбцы действительно необязательны?

• и т.п.

Затем вы можете разработать контрольные примеры для проверки вышеперечисленного. Вы можете использовать графический интерфейс для выполнения большинства тестов.

Есть и другие важные тесты базы данных, которые вы не упомянули. Те имеют дело с:

1 - Проверка того, что первичные ключи действительно уникальны с точки зрения бизнеса.

2 - Проверка того, что уникальные индексы (кроме PK) действительно уникальны с точки зрения бизнеса.

3 - Тестирование ограничений внешнего ключа.

4 - Тестирование того, что происходит, когда строки удаляются и его влияние на связанные строки.

5 - Другие тесты, касающиеся специальных конструкций базы данных, таких как CHEKC, Триггеры, если они существуют.

6 - правильная нормализация таблицы и то, что нормализованные столбцы содержат правильные значения.

Вышеприведенный список не является полным, но он должен помочь вам начать.

Я думаю, что вы подходите к этому неправильно.

Любая база данных, которую я знаю, проверяет данные перед вставкой в ​​таблицы - она ​​проверяет соответствие по определению каждого столбца. Вы не можете ввести 80-символьную строку в столбец SMALLINT (3) - база данных не выполнит эту попытку и сообщит, что вы допустили ошибку. Вам не нужно проверять это самостоятельно, вставляя данные, а затем извлекая их.

Вы хотите иметь правила проверки / фильтрации данных перед их отправкой в ​​базу данных.

• Убедиться, что данные соответствуют принятым типам и диапазону для каждого столбца, и отфильтровать нежелательный контент.
• Убедитесь, что вы избежали ошибок (и возможных SQL-инъекций, если у вас есть открытый интерфейс).

Эти правила проверки / фильтрации должны работать с данными в вашем реальном приложении. Затем вы можете настроить тесты, чтобы убедиться, что они правильные, предоставив им правильные и неправильные данные, чтобы убедиться, что они проходят или не проходят валидацию соответственно.

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