Testowanie CRUD

CRUD to czarnoskrzynkowa technika projektowania testów związana z przetwarzaniem danych. Polega na tworzeniu przypadków testowych na podstawie śledzenia cyklu życia danych w systemie. W artykule opisana została podstawowa wersja metody, a także jej rozszerzenia, ponieważ w rzeczywistych projektach najprostsze podejście CRUD może okazać się niewystarczające. Zapraszamy do lektury rozdziału z książki „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia”, która trafi do Państwa rąk już w maju.

Opis metody

Akronim CRUD pochodzi od czterech angielskich słów: create, read, update oraz delete, czyli: stwórz, czytaj, uaktualnij, skasuj. Technika testowania CRUD dotyczy danych. Jest szczególnie pomocna w systemach bazodanowych oraz w aplikacjach, których istotną funkcjonalnością jest przetwarzanie danych. Operacje CRUD spotkać można prawie we wszystkich systemach. Na portalu społecznościowym możemy stworzyć swoje konto, dodać inną osobę do znajomych, usunąć ją z kontaktów, odczytać listę znajomych, zmodyfikować swoje dane itp. W każdej bazie danych podstawowe operacje to CREATE/INSERT, SELECT, UPDATE, DELETE.

Metoda CRUD polega na śledzeniu cyklu życia jakiejś danej, od momentu jej stworzenia do usunięcia. Jest to w pewnym sensie czarnoskrzynkowy odpowiednik białoskrzynkowej metody testowania przepływu danych. W metodologii TMap [117] technika ta nazywa się testowaniem cyklu danych (ang. data cycle test).

Systematyczne podejście CRUD wymaga stworzenia tzw. macierzy CRUD (ang. CRUD matrix), a następnie wyprowadzenia na jej podstawie przypadków testowych. Macierz CRUD może być elementem projektu systemu (i wtedy nie musimy jej sami tworzyć) lub może być wyprowadzona na podstawie specyfikacji funkcjonalnej. Określa ona, w których miejscach systemu jakie operacje na danych są możliwe do wykonania. W wierszach macierzy występują dane (np. poszczególne zmienne, obiekty itd.), natomiast cztery kolumny odpowiadają czterem podstawowym operacjom: C, R, U i D. W poszczególnych polach macierzy umieszcza się elementy systemu (np. ekrany), w których można wykonać określoną operację na określonej danej. Przykład macierzy CRUD jest pokazany na rys.

macierzC

Rysunek 1. Macierz CRUD

Zmienna id może być stworzona w miejscu E1. Miejscem może być np. ekran tworzenia nowego użytkownika. Zmienna id może być odczytana w dwóch miejscach: E2 oraz E3 i skasowana w E1. Zmiennej id nie da się aktualizować (bo np. jest unikalnym, niemodyfikowalnym kluczem). Zarówno imię, jak i nazwisko mogą być stworzone w E2 oraz odczytane i aktualizowane w E4. Zmienna wiek może być stworzona w E3 i aktualizowana w E4. Zmiennych nazwisko, imię i wiek nie można skasować (bo np. podlegają archiwizacji). 

Mając stworzoną macierz CRUD, możemy przystąpić do tworzenia przypadków testowych. W najprostszej formie są one po prostu przekształconą macierzą CRUD, w której z każdym miejscem w systemie związany jest jeden przypadek testowy. Przypadki dla macierzy z rys.1. zostały pokazane w tabeli Tabela 8.1.

Tabela 8.1. Przypadki testowe wyprowadzone z macierzy CRUD

 

PT1

PT2

PT3

PT4

Warunek wstępny

E1

E2

E3

E4

Akcja 1

Stwórz id

Stwórz nazwisko

Stwórz wiek

Odczytaj nazwisko

Akcja 2

Usuń id

Stwórz imię

Odczytaj id

Odczytaj imię

Akcja 3

 

Odczytaj id

 

Aktualizuj nazwisko

Akcja 4

 

 

 

Aktualizuj imię

Akcja 5

 

 

 

Aktualizuj wiek

 

Przypadki testowe opisują czynności do wykonania w każdym z miejsc systemu. Na przykład PT3 polega na tym, że gdy znajdujemy się na ekranie E3, to najpierw tworzymy zmienną wiek, a następnie odczytujemy id

W tabeli nie opisaliśmy oczekiwanych wyników, gdyż w podejściu CRUD zwykle są one definiowane w naturalny sposób: jeśli akcja polega na stworzeniu obiektu, oczekiwanym wynikiem jest stworzenie tego obiektu itd.

Rozszerzenie metody

W poprzednim podrozdziale opisaliśmy bardzo prostą wersję metody CRUD. W rzeczywistych projektach takie podejście może nie wystarczać. Można rozważać następujące rozszerzenia CRUD:

  • uwzględnienie kolejności wykonywania operacji;
  • uwzględnienie związków ilościowych pomiędzy operacjami a danymi;
  • rozważenie tzw. pytań reporterskich w stosunku do operacji (kto, co, gdzie, kiedy, dlaczego, jak, jak dużo?).

Pierwsze rozszerzenie uwzględnia kolejność wykonywania operacji w ramach danego przypadku testowego. Na przykład dla przypadku PT2 z tabeli Tabela 8.1 możemy najpierw stworzyć imię, potem odczytać id, a na końcu stworzyć nazwisko. Każdy przypadek można zatem rozbić na kilka „podprzypadków” testowych, zawierających ten sam zbiór operacji, ale w różnej kolejności. Takie podejście może jednak spowodować eksplozję liczby testów[1].

W drugim rozszerzeniu każda operacja może być wykonana na kilka sposobów, z uwzględnieniem relacji ilościowych pomiędzy operacjami a obiektami. Sposoby te są opisane w tabeli Tabela 8.2.

Tabela 8.2. Różne realizacje możliwych operacji CRUD

Operacja

Możliwe realizacje

Create

  • Stwórz jedną, nową instancję danej
  • Stwórz instancję danej będącą duplikatem innej danej
  • Stwórz więcej niż jeden element naraz (jeśli to możliwe)

Read

  • Odczytaj jeden element
  • Odczytaj więcej niż jeden element
  • Odczytaj element, który nie istnieje
  • Odczytaj elementy w określonej ilości lub formacie (np. posortowane, przefiltrowane, pasujące do określonego wzorca, wszystkie, zadaną liczbę rekordów itp.)

Update

  • Aktualizuj jeden element
  • Aktualizuj więcej niż jeden element
  • Aktualizuj elementy pasujące do danego wzorca
  • Aktualizuj nieistniejący element

Delete

  • Usuń jeden istniejący element
  • Usuń więcej niż jeden element
  • Usuń elementy pasujące do danego wzorca
  • Usuń nieistniejący element

W podejściu trzecim poza samym faktem wykorzystywania operacji testujemy również warunki, w jakich to się odbywa. W szczególności:

  • Kto. Jaki użytkownik może wykonać daną operację? Jakie musi mieć uprawnienia?
  • Co. Jaki typ operacji jest możliwy? Czy oprócz operacji poprawnych jest dopuszczane wymuszenie operacji niepoprawnej? Co ze znakami specjalnymi, pustymi wartościami pól, długimi łańcuchami znaków itd.?
  • Kiedy. Kiedy dana operacja może zostać wykonana? Jaki jest skutek operacji żądanych w czasie niedostępności systemu?
  • Dlaczego. Jaki jest cel wykonania danej operacji? Czy można wykonać operację w złej wierze (np. kwestie bezpieczeństwa)?
  • Jak. W jaki sposób są wykonywane operacje? Czy przez polecenia z klawiatury, plik wsadowy, wybór operacji z graficznego interfejsu użytkownika?

[1] Dla przypadku zawierającego  akcji liczba możliwych ustawień tych operacji wynosi