Jakość danych w testach regresji relacyjnych baz danych

Pracowałem nad aplikacją internetową do zarządzania kolekcjami muzealnymi typu open source, która ma być używana do śledzenia artefaktów, które muzeum przystąpiło, podarowało, pożyczyło lub w inny sposób nabyło.

Obejmowało to zaprojektowanie i utworzenie dość dużej bazy danych (w odniesieniu do moich wcześniejszych doświadczeń), która przechowuje wszelkiego rodzaju różnorodne informacje (informacje o artefaktach, zmiany informacji o lokalizacji, osobiste dane kontaktowe, zdjęcia itp.), Które muszą być elastyczne i łatwo rozszerzalne .

Właśnie kończę studia wyższe i nie jestem profesjonalistą, jeśli chodzi o projektowanie baz danych, dlatego naprawdę chcę stworzyć dokładny pakiet testów, aby upewnić się, że to, co mam, „działa”.

Przeczytałem o testowaniu baz danych i natknąłem się na kilka artykułów, które wspominają o testowaniu regresji w odniesieniu do baz danych, ale nie do końca rozumiem, co to wszystko dotyczy. Po przeczytaniu tego artykułu w Dr.Dobbs rozumiem, że jednym z rodzajów testów, które muszę wykonać, jest sprawdzenie, czy logika w bazie danych jest poprawna. Stworzyłem więc testy, które wstawiałyby określone dane do bazy danych, a następnie śledziłem je za pomocą zapytania, aby upewnić się, że odzyskam prawidłowe dane z bazy danych (upewniając się, że działają wszystkie odpowiednie wyzwalacze lub widoki).

Pomyłka pojawia się w związku z testowaniem „jakości danych”. W powyższym artykule autor wspomina, że ​​chcesz sprawdzić następujące testy:

• Reguły wartości domeny w kolumnie
• Reguły wartości domyślnej kolumny
• Zasady istnienia wartości
• Reguły wartości wiersza
• Zasady wielkości

Jakiego rodzaju testy to obejmowałoby i w jaki sposób byłyby realizowane? Również po raz pierwszy piszę zestaw testowy dla bazy danych. Czy są jakieś dobre wskazówki na temat tego, jak / od czego zacząć, lub jakie procesy mogę wykonać, aby poprowadzić mój rozwój testów?

Pełna odpowiedź na to pytanie byłaby bardzo długa. Spróbuję wymienić główne punkty.

Aby rozdzielić obawy, możesz patrzeć na testy, aby:

A - Sprawdź poprawność projektu bazy danych.

B - Sprawdź, czy program (i) poprawnie współpracują z bazą danych.

Sprawdzanie poprawności projektu bazy danych powinno być wykonane przez osobę (osoby), która zaprojektowała bazę danych. Deweloperzy (podczas testów jednostkowych) powinni bardziej zajmować się częścią (B). Główną różnicą, którą widzę między dwoma typami testów, są używane narzędzia. W przypadku (A) użyjesz środowiska niezależnego od kodu projektu, natomiast w (B) oczywiście użyjesz kodu projektu. W poniższym tekście zmieszam oba.

Aby odpowiedzieć na konkretne pytania:

Reguły wartości domeny w kolumnie

Każda kolumna ma powiązany typ danych. Każda kolumna musi zostać zweryfikowana pod kątem reguł biznesowych, aby udowodnić, że reprezentuje poprawny typ danych. Problemy mogą pojawić się, jeśli typ danych kolumny nie jest zgodny z wymaganiami biznesowymi lub jeśli kod wykorzystuje typ danych inny niż sposób, w jaki jest on zdefiniowany w bazie danych.

Na przykład:

• Jeśli kolumna jest zdefiniowana jako mała int, nie powinno być możliwości przechowywania w niej tekstu. Jest to ważny test, zwłaszcza gdy kolumny są opcjonalne, ponieważ może pozostać niezauważony, dopóki ktoś nie wprowadzi do niego niektórych danych.

• Czy możesz zapisać wartość ujemną w kolumnie, w której firma tego wymaga?

Reguły wartości domyślnej kolumny

Niektóre kolumny są powiązane z domyślną specyfikacją wartości w DDL (Data Def. Language), gdzie jeśli podczas wstawiania wstawka nie podaje wartości, baza danych przyjmie wartość domyślną. Można to przetestować, nie przekazując wartości i obserwując wartość wynikową przechowywaną w bazie danych. Ten test może również obejmować sprawdzenie kolumn Nullable. Rzadko wymaga to testu, ponieważ można go zweryfikować z DDL, chyba że na kolumnie zostanie zbudowany unikalny indeks.

Zasady istnienia wartości

Jak rozumiem, weryfikujesz, czy wstawione lub zaktualizowane dane pokazują się zgodnie z oczekiwaniami w bazie danych.

Reguły wartości wiersza

Nie wiem dokładnie, co to dokładnie oznacza.

Zasady wielkości

Każda kolumna ma rozmiar w bazie danych na podstawie tego, jak jest zdefiniowany w DDL. chcesz się upewnić, że każda wartość, która pasuje do wymagań (wprowadzona z GUI lub wynikowa jako wynik obliczeń) zostanie poprawnie zapisana w kolumnie. Na przykład typ danych Small Integer nie pozwala przechowywać wartości 5 miliardów. Ponadto nazwa zdefiniowana jako VARCHAR2 (30) nie zmieści 40 znaków, więc reguły biznesowe muszą być tutaj bardzo jasne, szczególnie gdy kolumna jest używana do agregacji danych. Chcesz sprawdzić, co dzieje się w takich sytuacjach.

wytyczne jak / od czego zacząć

Jednym ze sposobów jest opracowanie planu testowania. Chcesz mieć pewność, że korzystasz z właściwej wersji specyfikacji (takich jak dokumenty wymagań i przypadki użycia) oraz oprogramowania. Musisz także skoordynować te testy z testami wykonanymi przez testowanie jednostkowe (jeśli takie istnieją). Możesz znaleźć duplikaty testów, których nie musisz wykonywać ponownie. Chcesz wykonać kopię bazy danych przed testowaniem, aby w razie potrzeby móc powtórzyć określony test. DBA może ci w tym pomóc. Musisz również sprawdzić ze swoim zespołem, w jaki sposób dokumentują testy tez i zweryfikować z nimi zakres testowania. Możesz podzielić bazę danych na części logiczne i rozpocząć testowanie każdej części logicznej osobno. Proces testowania można rozpocząć od przestudiowania DDL bazy danych i sprawdzenia, czy kolumny są poprawnie zdefiniowane zgodnie z wymaganiami firmy. Powinieneś używać oprogramowania aplikacji, a nie innych narzędzi do wykonywania większości testów. Na przykład pytanie:

• Czy kolumna ma być zdefiniowanego typu (nie ma sensu tworzyć Nazwy jako Int).

• Czy rozmiar jest zgodny z wymaganiami biznesowymi?

• Czy w bazie danych znajdują się wszystkie kolumny wymagań biznesowych?

• Czy kolumny zerowe są naprawdę opcjonalne?

• itp.

Następnie możesz zaprojektować przypadki testowe do przetestowania powyższego. Możesz użyć GUI do wykonania większości testów.

Istnieją inne ważne testy bazy danych, o których nie wspomniałeś. Dotyczą one:

1 - Testowanie, czy klucze podstawowe są naprawdę unikalne z perspektywy biznesowej.

2 - Testowanie, czy unikalne indeksy (inne niż PK) są naprawdę unikalne z perspektywy biznesowej.

3 - Testowanie ograniczeń klucza obcego działa.

4 - Testowanie, co dzieje się po usunięciu wierszy i jego wpływu na powiązane wiersze.

5 - Inne testy dotyczące specjalnych konstrukcji baz danych, takich jak CHEKC, wyzwalacze, jeśli istnieją.

6 - Prawidłowa normalizacja tabeli i że znormalizowane kolumny zawierają prawidłowe wartości.

Powyższa lista nie jest pełną listą, ale powinna zacząć.

Myślę, że podchodzisz do tego niewłaściwie.

Każda znana mi baza danych weryfikuje dane przed wstawieniem ich do tabel - weryfikuje je względem definicji każdej kolumny. Nie można wprowadzić 80-znakowego ciągu do kolumny SMALLINT (3) - baza danych zawiedzie przy tej próbie i poinformuje, że popełniłeś błąd. Nie musisz sam tego sprawdzać, wstawiając dane, a następnie je odzyskując.

To, co chcesz mieć, to reguły sprawdzania poprawności / filtrowania danych przed przesłaniem ich do bazy danych.

• Upewnij się, że dane pasują do akceptowanych typów i zakresów dla każdej kolumny, i filtruj niechciane treści
• Upewnij się, że odpowiednio go unikniesz, aby uniknąć błędów (i ewentualnych zastrzyków SQL, jeśli masz interfejs publiczny)

Te reguły sprawdzania poprawności / filtrowania powinny działać na danych w Twojej rzeczywistej aplikacji. Następnie możesz skonfigurować testy, aby upewnić się, że są poprawne, podając je poprawnymi i niepoprawnymi danymi, aby upewnić się, że pomyślnie przejdzie lub nie przejdzie walidacji.

Jeśli chodzi o projekt bazy danych, nie można tak naprawdę zweryfikować go za pomocą testów - ponieważ wiele projektów będzie działać, nawet jeśli nie będą one idealne (i definicja idealnych zmian między różnymi osobami). Właściwy projekt bazy danych zawiera doświadczenie i wiedzę, a nie zautomatyzowane testy.