Полный ответ на этот вопрос будет очень долгим. Я постараюсь упомянуть основные моменты.
Чтобы разделить проблемы, вы можете посмотреть на тесты, чтобы:
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) - база данных не выполнит эту попытку и сообщит, что вы допустили ошибку. Вам не нужно проверять это самостоятельно, вставляя данные, а затем извлекая их.
Вы хотите иметь правила проверки / фильтрации данных перед их отправкой в базу данных.
Эти правила проверки / фильтрации должны работать с данными в вашем реальном приложении. Затем вы можете настроить тесты, чтобы убедиться, что они правильные, предоставив им правильные и неправильные данные, чтобы убедиться, что они проходят или не проходят валидацию соответственно.
Что касается проектирования базы данных, вы не можете проверить это с помощью тестов - поскольку многие проекты будут работать, даже если они не идеальны (и определение идеальных изменений между разными людьми). Правильный дизайн базы данных приходит с опытом и знаниями, а не с автоматизированными тестами.
источник