Якість даних в реляційних тестах регресії бази даних

Я працюю над веб-додатком із відкритим кодом «Музейна колекція», яке слід використовувати для відстеження доступу до музею, дарування, позики чи придбаних предметів, що іншим чином.

Це стосувалося проектування та створення досить великої бази даних (стосовно мого попереднього досвіду), яка зберігає всіляку різну інформацію (інформацію про артефакти, зміну інформації про місцезнаходження, особисту контактну інформацію, фотографії тощо), яка повинна бути гнучкою та легко розширюваною .

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

Я читав про тестування баз даних і натрапив на кілька статей, де згадується регресійне тестування стосовно баз даних, але я не повністю розумію, що це стосується. Читаючи цю статтю в Dr.Dobbs, я розумію, що один із типів тестування, який мені потрібно буде зробити, - це перевірити правильність логіки в базі даних. Тож я б створив тести, які вставляють певні дані в базу даних, а потім слідкую за цим запитом, щоб переконатися, що я повертаю правильні дані з бази даних (забезпечуючи справність всіх відповідних тригерів чи поглядів).

Плутанина приходить із згадкою про тестування на "Якість даних". У статті над автором згадується, що ви хочете перевірити наступні тести:

• Правила значення домену стовпця
• Правила значення за замовчуванням у стовпці
• Ціннісні правила існування
• Правила значення рядків
• Правила розміру

Які типи тестів це передбачало б і як вони будуть реалізовані? Також я вперше пишу тестовий набір для бази даних, чи є якісь вказівки щодо того, як / з чого почати чи будь-які процеси, які я міг би дотримуватися, щоб керувати моєю розробкою тесту?

Повна відповідь на це питання була б дуже довгою. Спробую зазначити основні моменти.

Щоб відокремити проблеми, ви можете переглядати тести:

A - Підтвердити дизайн бази даних.

B - Перевірте, що програма (програми) взаємодіють правильно з базою даних.

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

Щоб відповісти на ваші конкретні запитання:

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

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

Наприклад:

• Якщо стовпець визначений як маленький int, ви не зможете зберігати в ньому текст. Це важливий тест, особливо коли стовпці необов’язкові, оскільки це може пройти непомітно, поки хтось фактично не введе в нього якісь дані.

• Чи можете ви зберегти негативне значення у стовпці, де бізнес вимагає, щоб це сталося?

Правила значення за замовчуванням у стовпці

Деякі стовпці пов'язані зі специфікацією значення за замовчуванням у DDL (Мова захисту даних), де, якщо під час вставки вставка не надає значення, база даних прийме значення за замовчуванням. Це можна перевірити, не передаючи значення та спостерігаючи за результатом значення, яке зберігає база даних. Цей тест може також включати перевірку наявності стовпців Nullable. Це рідко вимагає тесту, оскільки його можна перевірити за допомогою DDL, якщо на стовпці не побудовано унікальний індекс.

Ціннісні правила існування

Як я це розумію, ви перевіряєте, що вставлені або оновлені дані відображаються так, як очікувалося в базі даних.

Правила значення рядків

Мені не ясно, що саме це означає.

Правила розміру

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

вказівки щодо того, як / з чого почати

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

• Чи має бути стовпець визначеного типу (немає сенсу створювати ім'я як Int).

• Чи сумісний розмір з вимогами бізнесу?

• Чи всі стовпці вимог бізнесу містяться в базі даних?

• Чи нульові стовпці дійсно необов’язкові?

• тощо.

Далі ви можете розробити тестові випадки для тестування вищезазначеного. Ви можете використовувати GUI, щоб зробити більшість тестів.

Є й інші важливі тести бази даних, про які ви не згадали. Вони мають справу з:

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

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

3 - Тестування роботи обмежень зовнішніх ключів.

4 - Тестування того, що відбувається при видаленні рядків та його вплив на пов'язані рядки.

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

6 - Правильна нормалізація таблиці та нормалізовані стовпці містять правильні значення.

Наведене вище не є повним переліком, але воно повинно вас почати.

Я думаю, що ти підходиш до цього неправильно.

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

Що ви хочете мати, це правила перевірки / фільтрації даних перед тим, як вони надсилаються в базу даних.

• Переконайтесь, що дані відповідають загальноприйнятим типам та діапазону для кожного стовпця та фільтрують небажаний вміст
• Переконайтесь, що правильно уникнути цього, щоб уникнути помилок (та можливих ін'єкцій SQL, якщо у вас є загальнодоступний інтерфейс)

Ці правила перевірки / фільтрації повинні працювати на даних вашої фактичної програми. Потім ви можете налаштувати тести, щоб переконатися, що вони правильні, подаючи їх з правильними та неправильними даними, щоб переконатися, що вони пройшли або не виконали перевірку відповідно.

Що стосується дизайну баз даних, ви не можете реально перевірити її тестами, оскільки багато конструкцій працюватимуть, навіть якщо вони не ідеальні (і визначення ідеальних змін між різними людьми). Правильна розробка баз даних має досвід та знання, а не автоматизовані тести.