Samouczek testowania baz danych (danych).

Członkowie zespołu testowego i programistycznego zwykle kładą największy nacisk na GUI, ponieważ graficzny interfejs użytkownika jest najbardziej widoczną częścią aplikacji. Jednak ważna jest także walidacja informacji będących sercem aplikacji, czyli BAZY DANYCH.

Rozważmy aplikację bankową, w której użytkownik dokonuje transakcji. Teraz z punktu widzenia Testowania Baz Danych lub Testowania DB, ważne są następujące rzeczy:

1. Aplikacja przechowuje informacje o transakcjach w bazie danych aplikacji i poprawnie wyświetla je użytkownikowi.
2. W trakcie tego procesu nie są tracone żadne informacje.
3. Aplikacja nie zapisuje informacji o operacjach częściowo wykonanych lub przerwanych.
4. Żadna nieupoważniona osoba nie może uzyskać dostępu do informacji użytkownika.

Aby zapewnić wszystkie powyższe cele, musimy zastosować walidację danych lub testowanie danych.

Różnice między testowaniem interfejsu użytkownika a testowaniem danych

Testowanie interfejsu użytkownika	Testowanie bazy danych lub danych
Ten typ testów jest również znany jako testowanie graficznego interfejsu użytkownika lub testowanie front-endu.	Ten typ testów jest również znany jako testowanie backendu lub testowanie danych.
Ten typ testowania dotyczy głównie wszystkich testowalnych elementów, które są otwarte dla użytkownika do oglądania i interakcji, takich jak formularze, prezentacje, wykresy, menu i raporty itp. (utworzone za pomocą VB, VB.net, VC++, Delphi – narzędzia front-end)	Ten typ testów dotyczy głównie wszystkich testowalnych elementów, które zazwyczaj są ukryte przed użytkownikiem w celu oglądania. Należą do nich procesy wewnętrzne i przechowywanie, takie jak Assembly, Podobnie jak DBMS Oracle, SQL Server, MYSQL itp.
Ten typ testów obejmuje walidację pola tekstowe wybierz menu rozwijane kalendarze i przyciski Nawigacja strony wyświetlanie obrazów Wygląd i działanie całej aplikacji	Ten typ testów obejmuje walidację: schemat tabele bazy danych kolumny klucze i indeksy wyzwalacze procedur składowanych walidacja serwera bazy danych sprawdzanie duplikacji danych
Tester musi posiadać dogłębną wiedzę na temat wymagań biznesowych, a także stosowania narzędzi programistycznych oraz stosowania frameworków i narzędzi automatyzacji.	Aby móc przeprowadzać testy zaplecza, tester musi mieć solidną wiedzę na temat serwerów baz danych oraz koncepcji języka zapytań strukturalnych (ang. Structured Query Language).

Rodzaje testowania baz danych

Istnieją 3 rodzaje testowania baz danych

1. Testy strukturalne
2. Testy funkcjonalne
3. Testy niefunkcjonalne

W tym samouczku dotyczącym testowania baz danych przyjrzymy się po kolei każdemu typowi i jego podtypom.

Co to jest testowanie schematu?

Testowanie schematu w testowaniu baz danych sprawdza różne formaty schematów powiązanych z bazą danych i sprawdza, czy formaty mapowania tabel/widoków/kolumn są kompatybilne z formatami mapowania interfejsu użytkownika. Głównym celem testowania schematu jest upewnienie się, że mapowanie schematu pomiędzy front-endem i backendem jest podobne. Dlatego też nazywa się to testowaniem mapowania.

Omówmy najważniejsze punkty kontrolne podczas testowania schematu.

1. Walidacja różnych formatów schematów powiązanych z bazami danych. W wielu przypadkach format mapowania tabeli może nie być zgodny z formatem mapowania obecnym na poziomie interfejsu użytkownika aplikacji.
2. W przypadku niezamapowanych tabel/widoków/kolumn konieczna jest weryfikacja.
3. Należy również sprawdzić, czy heterogeniczne bazy danych w środowisku są spójne z ogólnym mapowaniem aplikacji.

Przyjrzyjmy się także niektórym interesującym narzędziom do testowania baz danych, służącym do sprawdzania poprawności schematów baz danych.

• DBUnit zintegrowany z Antem jest bardzo odpowiedni do testowania mapowania.
• SQL Server umożliwia testerom sprawdzanie schematu bazy danych i wysyłanie zapytań do schematu bazy danych poprzez pisanie prostych zapytań, a nie poprzez kod.

Na przykład, jeśli programiści chcą zmienić strukturę tabeli lub ją usunąć, tester powinien upewnić się, że wszystkie procedury składowane i widoki korzystające z tej tabeli są zgodne z konkretną zmianą. Innym przykładem może być to, że jeśli testerzy chcą sprawdzić zmiany schematu między 2 bazami danych, mogą to zrobić za pomocą prostych zapytań.

Tabela bazy danych, testowanie kolumn

Przyjrzyjmy się różnym kontrolom testowania baz danych i kolumn.

1. Czy mapowanie pól i kolumn bazy danych w backendie jest kompatybilne z tymi mapowaniami w front-endzie?
2. Walidacja długości i konwencji nazewnictwa pól i kolumn bazy danych zgodnie z wymaganiami.
3. Sprawdzanie obecności wszelkich nieużywanych/niezamapowanych tabel/kolumn bazy danych.
4. Weryfikacja kompatybilności

• typ danych
• długości pól

kolumn wewnętrznej bazy danych z kolumnami znajdującymi się w przedniej części aplikacji.

5. Czy pola bazy danych umożliwiają użytkownikowi wprowadzenie żądanych danych wejściowych zgodnie z wymaganiami dokumentów specyfikacji wymagań biznesowych.

Testowanie kluczy i indeksów

Ważne kontrole kluczy i indeksów –

1. Sprawdź, czy wymagane

• Główny klucz
• klucz obcy

na wymaganych tabelach utworzono ograniczenia.

2. Sprawdź, czy odniesienia do kluczy obcych są prawidłowe.
3. Sprawdź, czy typ danych klucza podstawowego i odpowiadających mu kluczy obcych jest taki sam w obu tabelach.
4. Sprawdź, czy dla wszystkich kluczy i indeksów zastosowano wymagane konwencje nazewnictwa.
5. Sprawdź rozmiar i długość wymaganych pól i indeksów.
6. Czy wymagane

• Clusterindeksy wyd
• Nie Clusterindeksy wyd

zostały utworzone w wymaganych tabelach, zgodnie z wymaganiami biznesowymi.

Testowanie procedur składowanych

Ważnymi testami sprawdzającymi procedury składowane są:

1. Czy zespół programistów przyjął wymagane, A) standardowe konwencje kodowania oraz B) wyjątki i obsługę błędów. Dla wszystkich procedur składowanych dla wszystkich modułów testowanej aplikacji.
2. Czy zespół programistów uwzględnił wszystkie warunki/pętle, stosując wymagane dane wejściowe do testowanej aplikacji?
3. Czy zespół programistów prawidłowo zastosował operację TRIM za każdym razem, gdy dane były pobierane z wymaganych tabel w bazie danych?
4. Czy ręczne wykonanie procedury składowanej zapewnia użytkownikowi końcowemu wymagany wynik?
5. Czy ręczne wykonanie procedury składowanej zapewnia aktualizację pól tabeli zgodnie z wymaganiami testowanej aplikacji?
6. Czy wykonanie procedur składowanych umożliwia niejawne wywoływanie wymaganych wyzwalaczy?
7. Walidacja obecności niewykorzystanych procedur składowanych.
8. Walidacja warunku Zezwalaj na wartość null, którą można wykonać na poziomie bazy danych.
9. Potwierdzenie faktu, że wszystkie procedury składowane i funkcje zostały pomyślnie wykonane, gdy testowana baza danych jest pusta.
10. Walidacja ogólnej integracji modułów procedur składowanych zgodnie z wymaganiami testowanej aplikacji.

Niektóre z przydatnych narzędzi do testowania baz danych do testowania procedur przechowywanych to LINQ, narzędzie testowe SP itp.

Testowanie wyzwalacza

1. Czy podczas fazy kodowania wyzwalaczy przestrzegano wymaganych konwencji kodowania?
2. Sprawdź, czy wyzwalacze wykonane dla odpowiednich transakcji DML spełniły wymagane warunki.
3. Czy wyzwalacz poprawnie aktualizuje dane po ich wykonaniu?
4. Walidacja wymaganej aktualizacji/wstawienia/usunięcia uruchamia funkcjonalność w obszarze testowanej aplikacji.

Walidacja serwera bazy danych

1. Sprawdź konfiguracje serwera bazy danych zgodnie z wymaganiami biznesowymi.
2. Sprawdź uprawnienia wymaganego użytkownika do wykonywania tylko tych poziomów akcji, które są wymagane przez aplikację.
3. Sprawdź, czy serwer bazy danych jest w stanie obsłużyć maksymalną dozwoloną liczbę transakcji użytkownika, określoną w specyfikacjach wymagań biznesowych.

Testowanie funkcjonalnej bazy danych

Testowanie funkcjonalnej bazy danych jest rodzajem testowania bazy danych, który jest używany do walidacji wymagań funkcjonalnych bazy danych z perspektywy użytkownika końcowego. Głównym celem testowania funkcjonalnego bazy danych jest sprawdzenie, czy transakcje i operacje wykonywane przez użytkowników końcowych, które są związane z bazą danych, działają zgodnie z oczekiwaniami, czy nie.

Poniżej przedstawiono podstawowe warunki, które muszą być spełnione podczas walidacji baz danych.

• Czy pole jest obowiązkowe, a jednocześnie dozwolone są w nim wartości NULL?
• Czy długość każdego pola jest wystarczająca?
• Czy wszystkie podobne pola mają takie same nazwy w tabelach?
• Czy w bazie danych znajdują się pola obliczeniowe?

Ten konkretny proces to walidacja mapowań pól z punktu widzenia użytkownika końcowego. W tym konkretnym scenariuszu tester wykonałby operację na poziomie bazy danych, a następnie przeszedłby do odpowiedniego elementu interfejsu użytkownika, aby zaobserwować i sprawdzić, czy przeprowadzono właściwe walidacje pól.

Należy również zastosować odwrotną sytuację, w której pierwsza operacja jest wykonywana przez testera w interfejsie użytkownika, a następnie jest ona weryfikowana z poziomu zaplecza.

Sprawdzanie integralności i spójności danych

Ważne są następujące kontrole

1. Czy dane są dobrze zorganizowane logicznie?
2. Czy dane zapisane w tabelach są prawidłowe i zgodne z wymaganiami biznesowymi?
3. Czy w testowanej aplikacji znajdują się niepotrzebne dane?
4. Czy dane zostały zapisane zgodnie z wymogami dotyczącymi danych, które zostały zaktualizowane z poziomu interfejsu użytkownika?
5. Czy operacje TRIM zostały wykonane na danych przed wstawieniem ich do testowanej bazy danych?
6. Czy transakcje zostały przeprowadzone zgodnie ze specyfikacjami wymagań biznesowych i czy wyniki są prawidłowe, czy nie?
7. Czy dane zostały prawidłowo przekazane, jeżeli transakcja przebiegła pomyślnie?
8. Czy dane zostały pomyślnie wycofane, jeśli transakcja nie została pomyślnie wykonana przez użytkownika końcowego?
9. Czy dane zostały wycofane, jeśli transakcja nie została wykonana pomyślnie, a w danej transakcji brało udział wiele heterogenicznych baz danych?
10. Czy wszystkie transakcje zostały zrealizowane przy zastosowaniu wymaganych procedur projektowych określonych w wymaganiach biznesowych systemu?

Bezpieczeństwo logowania i użytkownika

Podczas weryfikacji danych logowania i zabezpieczeń użytkownika należy brać pod uwagę następujące kwestie.

1. Czy aplikacja uniemożliwia użytkownikowi dalsze korzystanie z aplikacji w przypadku:

• nieprawidłowa nazwa użytkownika, ale prawidłowe hasło
• prawidłowa nazwa użytkownika, ale nieprawidłowe hasło.
• nieprawidłowa nazwa użytkownika i nieprawidłowe hasło.

2. Czy użytkownik ma prawo wykonywać tylko te konkretne operacje, które są określone w wymaganiach biznesowych?
3. Czy dane są zabezpieczone przed nieuprawnionym dostępem?
4. Czy istnieją różne role użytkowników utworzone z różnymi uprawnieniami?
5. Czy wszyscy użytkownicy mają wymagany poziom dostępu do określonej bazy danych zgodnie ze specyfikacjami biznesowymi?
6. Sprawdź, czy poufne dane, takie jak hasła, numery kart kredytowych, są szyfrowane i nie są przechowywane jako zwykły tekst w bazie danych. Dobrą praktyką jest upewnienie się, że wszystkie konta mają hasła, które są złożone i trudne do odgadnięcia.

Testy niefunkcjonalne

Testy niefunkcjonalne w kontekście testowania baz danych można podzielić na różne kategorie, zgodnie z wymaganiami biznesowymi. Mogą to być testy obciążeniowe, testy obciążeniowe, Testowanie bezpieczeństwa, Test użyteczności, Testowanie kompatybilności, i tak dalej. Testowanie obciążenia, a także testy warunków skrajnych, które można pogrupować w gamę testów wydajnościowych, służą dwóm konkretnym celom, jeśli chodzi o rolę testów niefunkcjonalnych.

Kwantyfikacja ryzyka– Kwantyfikacja ryzyka pomaga zainteresowanym stronom ustalić różne wymagania dotyczące czasu reakcji systemu przy wymaganych poziomach obciążenia. To jest pierwotna intencja każdego najwyższą jakość zadanie. Należy zauważyć, że testowanie obciążenia nie łagodzi bezpośrednio ryzyka, ale poprzez procesy identyfikacji i kwantyfikacji ryzyka stwarza możliwości naprawcze i impuls do działań zaradczych, które łagodzą ryzyko.

Minimalne wymagania dotyczące sprzętu systemowego– Minimalna konfiguracja systemu, która pozwoli systemowi spełnić formalnie określone oczekiwania dotyczące wydajności interesariuszy. Dzięki temu można zminimalizować zewnętrzny sprzęt, oprogramowanie i powiązane koszty posiadania. Ten konkretny wymóg można sklasyfikować jako ogólny wymóg optymalizacji biznesowej.

Testowanie obciążenia

Cel każdego testu obciążeniowego powinien być jasno zrozumiany i udokumentowany. Następujące typy konfiguracji są niezbędne dla testowanie obciążenia.

1. Najczęściej używane transakcje użytkownika mogą mieć wpływ na wydajność wszystkich pozostałych transakcji, jeśli nie będą one wydajne.
2. W końcowym zestawie testów należy uwzględnić co najmniej jedną transakcję użytkownika, która nie podlega edycji, dzięki czemu będzie można odróżnić wydajność takich transakcji od innych, bardziej złożonych transakcji.
3. Należy uwzględnić ważniejsze transakcje, które ułatwiają realizację podstawowych celów systemu, ponieważ awaria pod obciążeniem tymi transakcjami ma z definicji największy wpływ.
4. Należy uwzględnić co najmniej jedną edytowalną transakcję, aby jest gwarancją najlepszej jakości, które mogą dostarczyć Ci Twoje monitory, takich transakcji można odróżnić od innych transakcji.
5. Optymalny czas reakcji przy dużej liczbie wirtualnych użytkowników dla wszystkich potencjalnych wymagań.
6. Efektywne czasy pobierania różnych rekordów.

Ważnymi narzędziami do testowania obciążenia są LoadRunner Professional, wygraj biegacz i JMeter.

Ważnymi narzędziami do testowania warunków skrajnych są LoadRunner Professional i JMeter.

Najczęstsze problemy występujące podczas testowania baz danych

A significant amount of overhead could be involved to determine the state of the database transactions

Rozwiązanie: Ogólne planowanie i harmonogram procesu należy zorganizować w taki sposób, aby nie pojawiały się problemy związane z czasem i kosztami.

New test data have to be designed after cleaning up of the old test data.

Rozwiązanie: Powinieneś mieć pod ręką wcześniejszy plan i metodologię generowania danych testowych.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

Rozwiązanie: Utrzymanie zapytań SQL i ich ciągła aktualizacja to znacząca część całego procesu testowania, który powinien być częścią całości strategia testowania.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Rozwiązanie: Należy zachować odpowiednią równowagę pomiędzy jakością i ogólnym czasem trwania harmonogramu projektu.

Mity i nieporozumienia związane z testowaniem baz danych

Database Testing requires plenty of expertise and it is a very tedious job

Rzeczywistość: Skuteczne i wydajne testowanie baz danych w testowaniu oprogramowania zapewnia długoterminową stabilność funkcjonalną całej aplikacji, dlatego konieczne jest włożenie w to ciężkiej pracy.

Database testing adds extra work bottleneck

Rzeczywistość: Wręcz przeciwnie, testowanie baz danych zwiększa wartość całej pracy, odkrywając ukryte problemy i w ten sposób aktywnie pomagając ulepszyć całą aplikację.

Database testing slows down the overall development process

Rzeczywistość: Znaczna ilość testów baz danych pomaga w ogólnej poprawie jakości aplikacji bazodanowej.

Database testing could be excessively costly

Rzeczywistość: Wszelkie wydatki na testowanie baz danych są inwestycją długoterminową, która prowadzi do długoterminowej stabilności i odporności aplikacji. Zatem wydatki na testowanie baz danych lub SQL Testowanie jest konieczne.

Najlepsze praktyki

• Wszystkie dane, w tym metadane, a także dane funkcjonalne, muszą zostać zweryfikowane zgodnie z ich mapowaniem w dokumentach specyfikacji wymagań.
• Weryfikacja dane testowe który został stworzony przez/w porozumieniu z zespołem programistów, musi zostać zatwierdzony.
• Walidacja danych wyjściowych przy użyciu procedur ręcznych i automatycznych.
• Wdrożenie różnych technik, takich jak technika tworzenia wykresów przyczynowo-skutkowych, technika podziału równoważności i technika analizy wartości brzegowych w celu generowania wymaganych warunków danych testowych.
• Należy również zweryfikować zasady sprawdzania integralności referencyjnej dla wymaganych tabel bazy danych.
• Wybór domyślnych wartości tabeli do sprawdzenia spójności bazy danych jest bardzo ważną koncepcją. Czy zdarzenia dziennika zostały pomyślnie dodane do Bazy Danych dla wszystkich wymaganych zdarzeń logowania
• Czy zaplanowane zadania są realizowane terminowo?
• Wykonaj na czas kopię zapasową bazy danych.

Sprawdź również- Pytania i odpowiedzi dotyczące rozmów kwalifikacyjnych dotyczących testowania baz danych