QualitySpy moduł reports

Transkrypt

1 QualitySpy moduł reports Testy akceptacyjne dla przypadku użycia: Pobranie metryk produktu w wybranym formacie dla wybranch wersji przez interfejs REST Nazwa pliku: /QualitySpy/modules/qualityspyreports/src/test/java/pl/wroc/pwr/qualityspy/reports /MetricsAcceptanceTest.java Autor: Marcin Wojciechowski Ostatnia modyfikacja: Liczba testów akceptacyjnych w tym pliku 3

2 AT1: Sprawdzenie czy podano właściwy link URL Data powstania: Autor: Marcin Wojciechowski : Sprawdzenie czy przy próbie pobrania niewłaściwego URL serwer zwraca kod Czy po próbie przejścia pod niewłaściwy adres URL, serwer zgłosi błąd HTTP Należy dokonać próby podania niewłaściwego linku URL. 2. Należy sprawdzić, czy serwer zwrócił kod 404 i komentarz słowny. Oczekiwane rezultaty: Przypadek testowy nr 1: Dane wejściowe: Uzyskany wynik: Testujący: Po dokonaniu próby podania niewłaściwego linku URL serwer zwrócił kod 404 wraz z komentarzem słownym. Przemysław Fudali Data wykonania testu:

3 AT2: Sprawdzenie czy podany projekt istnieje. Data powstania: Autor: Piotr Dziwiński : Sprawdzenie czy przy próbie podania nieistniejącego projektu funkcja zgłosi błąd HTTP 404 z komentarzem błędu. 1 Czy po próbie podania nieistniejącego projektu, funkcja zgłosi błąd HTTP 404 z komentarzem słownym Należy wejść na adres: podając parametry zapytania GET: projectname nieistniejący w bazie projekt i versionname przykładowa wersja. 2. Należy sprawdzić, czy funkcja zwróci kod 404 i komentarz słowny: Nie znaleziono projektu projekt w wersji wersja. Oczekiwane rezultaty: Przypadek testowy nr 1: Dane wejściowe: Uzyskany wynik: Testujący: Po dokonaniu próby pobrania nieistniejącego projektu foo i wersji 1.0, funkcja zwróciła kod 404 z komunikatem: Nie znaleziono projektu foo w wersji 1.0. Piotr Dziwiński Data wykonania testu:

4 AT3: Pobranie metryki produktu w wybranym formacie dla wybranych wersji przez interfejs REST Data powstania: Autor: Marcin Wojciechowski : Sprawdzenie poprawności pobrania metryk produktu znajdujących się w bazie danych dla wybranych projektów w dwóch wariantach: formacie XML i CSV. Test musi być wykonany na pustej bazie danych, do której będą wstawione przykładowe dane. 1 Czy udało się dodać przykładowe dane do bazy danych? 2 Czy udało się pobrać metryki produktu dodanych przykładowych projektów? 3 Czy zwrócone dane są w poprawnym formacie i zgadzają się z wprowadzonymi wcześniej danymi do bazy danych Należy przygotować odpowiednie projekty i metryki oraz ustalić ich atrybuty. 2. Należy umieścić w bazie testowe obiekty korzystając z modułu persistence. 3. Należy pobrać przez interfejs REST obiekty testowe w formacie XML i CSV podając jako argumenty zapytania nazwę i wersję wprowadzonego projektu. 4. Należy sprawdzić, czy wygenerowany dokument XML jest prawidłowy zgodnie ze schematem.xsd. 5. Należy sprawdzić czy zwrócony dokument XML zawiera poprawne dane wszystkich dodanych przykładowych projektów. 6. Należy sprawdzić, czy zwrócony plik CSV zawiera poprawny nagłówek. 7. Należy sprawdzić czy zwrócony plik CSV zawiera w kolejnych wierszach poprawne dane. Oczekiwane rezultaty:

5 Przypadek testowy nr 1: Dane wejściowe: Uzyskany wynik: Projekty o nazwie MetricsTest1 oraz MetricsTest2 z uzupełnionymi wszystkimi wartościami Udało się umieścić przykładowe metryki w bazie danych. Funkcja poprawnie wygenerowała pliki. Format pliku XML zgadza się ze schematem.xsd i zawiera wszystkie poprawne dane. Plik CSV zawiera poprawny nagłówek i poprawne dane metryk. Testujący: Przemysław Fudali Data wykonania testu: Tabela z danymi i przebiegiem testu znajduje się w osobnym załączniku

6 QualitySpy moduł reports Testy akceptacyjne dla przypadku użycia: Pobranie historii projektu i metryk CKJM przez interfejs REST Nazwa pliku: /QualitySpy/modules/qualityspyreports/src/test/java/pl/wroc/pwr/qualityspy/reports /ProjectsHistoryAcceptanceTest.java Autor: Marcin Wojciechowski Ostatnia modyfikacja: Liczba testów akceptacyjnych w tym pliku 3

7 AT1: Sprawdzenie czy podano właściwy link URL Data powstania: Autor: Marcin Wojciechowski : Sprawdzenie czy przy próbie pobrania niewłaściwego URL serwer zwraca kod Czy po próbie przejścia pod niewłaściwy adres URL, serwer zgłosi błąd HTTP Należy dokonać próby podania niewłaściwego linku URL. 2. Należy sprawdzić, czy serwer zwrócił kod 404 i komentarz słowny. Oczekiwane rezultaty: Przypadek testowy nr 1: Dane wejściowe: Uzyskany wynik: Testujący: Po dokonaniu próby podania niewłaściwego linku URL serwer zwrócił kod 404 wraz z komentarzem słownym. Przemysław Fudali Data wykonania testu:

8 AT2: Sprawdzenie czy podany projekt istnieje. Data powstania: Autor: Piotr Dziwiński : Sprawdzenie czy przy próbie podania nieistniejącego projektu funkcja zgłosi błąd HTTP 404 z komentarzem błędu. 1 Czy po próbie podania nieistniejącego projektu, funkcja zgłosi błąd HTTP 404 z komentarzem słownym Należy wejść na adres: podając parametry zapytania GET: projectname nieistniejący w bazie projekt, ckjmversion i repoversion przykładowe nr wersji. 2. Należy sprawdzić, czy funkcja zwróci kod 404 i komentarz słowny: Nie znaleziono projektu projekt w wersji wersja. Oczekiwane rezultaty: Przypadek testowy nr 1: Dane wejściowe: Uzyskany wynik: Testujący: Po dokonaniu próby pobrania nieistniejącego projektu foo i wersji 1.0, funkcja zwróciła kod 404 z komunikatem: Nie znaleziono projektu foo w wersji 1.0. Piotr Dziwiński Data wykonania testu:

9 AT3: Pobranie historii projektu i metryk CKJM przez interfejs REST Data powstania: Autor: Marcin Wojciechowski, Piotr Dziwiński : Sprawdzenie poprawności pobrania metryk CKJM projektu i dla historii o wybranej wersji, zakresu wersji lub zakresu dat, w dwóch wariantach: formacie XML i CSV. Test musi być wykonany na pustej bazie danych, do której będą wstawione przykładowe dane. 1 Czy udało się dodać przykładowe dane do bazy danych? 2 Czy udało się pobrać historię projektu o danej nazwie i wersji? 3 Czy udało się pobrać historię projektu o danej nazwie i przedziale wersji? 4 Czy udało się pobrać historię projektu o danej nazwie i przedziale dat? 1 1. Należy przygotować odpowiednie obiekty: projektu, metryk, historii projektu i rewizji oraz ustalić ich atrybuty. W bazie powinno znaleźć się kilka obiektów danego typu, aby zwracane dane różniły się w zależności od podawanych kryteriów. 2. Należy umieścić w bazie testowe obiekty korzystając z modułu persistence. 3. Należy pobrać przez interfejs REST obiekty testowe w formacie XML i CSV, uwzględniając wszystkie trzy warianty pobierania danych (wersja, zakres wersji, zakres dat). Należy też sprawdzić różne kombinacje podawanych kryteriów. 5. Należy sprawdzić, czy wygenerowany dokument XML jest prawidłowy zgodnie ze schematem.xsd. 6. Należy sprawdzić, czy zwrócony dokument XML zawiera dane zgodne z danymi wejściowymi oraz czy statystyki NR i NDC zostały prawidłowo wyznaczone. 7. Należy sprawdzić, czy wygenerowany plik CSV zawiera poprawny nagłówek. 8. Należy sprawdzić czy zwrócony plik CSV zawiera w kolejnych wierszach poprawne dane zgodne z danymi wejściowymi oraz czy statystyki NR i NDC zostały prawidłowo wyznaczone.

10 Oczekiwane rezultaty: Przypadek testowy nr 1: Dane wejściowe: Uzyskany wynik: Projekt o nazwie ProjectHistoryTest, metryki, historię projektu oraz rewizji z uzupełnionymi wszystkimi wartościami Udało się umieścić przykładowe dane w bazie danych. Funkcja poprawnie wygenerowała dokument we wszystkich trzech wariantach. Format pliku XML zgadza się ze schematem.xsd i zawiera wszystkie oczekiwane dane. Statystyki NR i NDC są zgodne z oczekiwaniem. Plik CSV posiada poprawny nagłówek i zawiera wszystkie oczekiwane dane. Statystyki NR i NDC są zgodne z oczekiwaniem. Testujący: Piotr Dziwiński Data wykonania testu: Tabela z danymi i przebiegiem testu znajduje się w osobnym załączniku

11 QualitySpy moduł reports Testy akceptacyjne dla przypadku użycia: Pobranie wszystkich projektów przez interfejs REST Nazwa pliku: /QualitySpy/modules/qualityspyreports/src/test/java/pl/wroc/pwr/qualityspy/reports /ProjectsAcceptanceTest.java Autor: Mateusz Bilski Ostatnia modyfikacja: Liczba testów akceptacyjnych w tym pliku 1

12 AT1 Pobieranie nazw wszystkich projektów przez interfejs REST Data powstania: Autor: Marcin Wojciechowski, Piotr Dziwiński : Sprawdzenie poprawności pobrania nazw oraz numerów aktualnych wersji wszystkich projektów znajdujących się w bazie danych. Test musi być wykonany na pustej bazie danych. L. p. 1 Czy połączenie z bazą danych zostało otwarte? 2 Czy baza danych w stanie początkowym jest pusta? 3 Czy udało się dodać przykładowe projekty do bazy danych? 4 Czy udało się pobrać nazwy oraz numery wersji dodanych przykładowych projektów? L. p Należy sprawdzić, czy połączenie z bazą danych zostało otwarte. 2. Należy pobrać listę projektów z bazy danych i sprawdzić, że jest ona pusta. 3. Należy umieścić w bazie danych testowe projekty. 4. Należy pobrać przez interfejs REST dokument XML lub CSV z nazwami oraz wersjami projektów w bazie danych. 5. Należy sprawdzić, czy wygenerowany dokument jest prawidłowy. 5. Należy sprawdzić, czy dokument XML lub CSV zawiera poprawne dane wszystkich dodanych przykładowych projektów. Oczekiwane rezultaty: L. p. Przypadek testowy nr 1: Dane wejściowe Dwa projekty nazwane Test1 i Test2 z wersjami odpowiednio 1.0 i 2.0 Uzyskany wynik Połączenie z bazą danych zostało otwarte. Baza danych była pusta (zwrócona lista projektów była pusta). Udało się umieścić przykładowe projekty w bazie danych Udało się pobrać dokument z nazwami i wersjami projektów. Dokumenty XML i CSV zostały poprawnie wygenerowane (spełniały warunki specyfikacji). Dokumenty zawierały poprawne dane dokładnie 2 projekty z podanym wcześniej danymi. Testujący Piotr Dziwiński Data wykonania testu