1/52 Testowanie oprogramowania Adam Roman Instytut Informatyki UJ Wykład 8 testowanie niefunkcjonalne (testowanie charakterystyk jakościowych) testowanie z użyciem narzędzi
ISO 9126 (1) Norma dotycząca zagadnień jakości oprogramowania Rozróżnienie na testy funkcjonalne i niefunkcjonalne Część normy Opis 9126-1 model jakości opisujący 6 kategorii jakości 9126-2 9126-3 9126-4 metryki dla zewnętrznych (dynamicznych) pomiarów charakterystyk jakości metryki dla wewnętrznych (statycznych) pomiarów charakterystyk jakości metryki dla quality-in-use (pomiary dla gotowego produktu będącego w użyciu) 2/52
ISO 9126 (2) kategorie i podkategorie jakości FUNKCJONALNOŚĆ (FUNCTIONALITY) dopasowanie (suitability) współdziałanie (interoperability) bezpieczeństwo (security) dokładność (accuracy) zgodność (compliance) NIEZAWODNOŚĆ (RELIABILITY) UŻYTECZNOŚĆ (USABILITY) EFEKTYWNOŚĆ (EFFICIENCY) PIELĘGNOWALNOŚĆ (MAINTAINABILITY) odporność na błędy (fault tolerance) odtwarzalność (recoverability) dojrzałość (maturity) zrozumiałość (understandability) łatwość nauki (learnability) łatwość obsługi (operability) efektywność czasowa (time behaviour) zużycie zasobów (resource behaviour) analizowalność (analyzability) testowalność (testability) modyfikowalność (changeability) stabilność (stability) PRZENASZALNOŚĆ (PORTABILITY) adaptowalność (adaptability) instalowalność (installability) zgodność (conformance) zastępowalność (replaceability) 3/52
4/52 Testowanie niefunkcjonalne Testowanie funkcjonalne co system robi Testowanie niefunkcjonalne jak (jak dobrze) system to robi Główne techniki testowania niefunkcjonalnego to techniki czarnoskrzynkowe Testowanie niefunkcjonalne może zależeć od wymagań, ale często zależy od nich niejawnie!
5/52 Testowanie atrybutów jakościowych ATRYBUTY JAKOŚCIOWE TESTOWANIE DZIEDZINOWE (domain testing) TESTOWANIE TECHNICZNE (technical testing) dokładność (accuracy) dopasowanie (suitability) współdziałanie (interoperability) użyteczność (usability) dostępność (accessibility) funkcjonalne bezpieczeństwo (functional security) bezpieczeństwo (security) niezawodność (reliability) efektywność (efficiency) pielęgnowalność (maintainability) przenaszalność (portability)
Testowanie dziedzinowe 6/52
7/52 Dokładność (accuracy) (1) Dokładność zdolność systemu do dostarczania rezultatów jego działania na odpowiednim poziomie precyzji Przypadek idelany: dokładność wynika ze specyfikacji Wykorzystywane techniki: analiza wartości brzegowych tablice decyzyjne (gdy wartość wynika z wielu wejść) Synonim: poprawność (correctness)
8/52 Dokładność (accuracy) (2) dokładność a poziomy testowania sprawdzenie poprawności danych przechowywanych w pamięci sprawdzenie, czy precyzja nie jest tracona przy transferze danych pomiędzy modułami sprawdzenie dokładności na poziomie systemowym (zwykle dostępna specyfikacja) klient powinien być zadowolony z rezultatów scenariuszy, raportów i zapytań
Dopasowanie (suitability) (1) Dopasowanie zdolność systemu do dostarczania odpowiedniego zbioru funkcji dla określonych zadań i celów użytkownika Inaczej: czy system potrafi rozwiązać zadany problem? Konieczna u testera wiedza dziedzinowa Typ testów posiadający charakter walidacyjny Wykorzystywane techniki: use case y wywiady scenariusze testowe testy eksploracyjne 9/52
10/52 Dopasowanie (suitability) (2) przykład Zakup w sklepie e-commerce: normalny proces 1. Klient umieszcza jeden lub więcej produktów w korzyku 2. Klient wybiera checkout 3. System pobiera od Klienta adres, formę płatności i formę dostawy 4. System wyświetla w/w informacje dla potwierdzenia przez Klienta 5. Klient potwierdza Systemowi zamówienie Wyjątki: Klient próbuje zrobić checkout z pustym koszykiem system zwraca odpowiedni komunikat o błędzie Klient wpisuje błędny adres, formę płatności lub formę dostawy system zwraca odpowiedni komunikat o błędzie Klient przerywa transakcję przed lub w trakcie checkoutu; System wylogowuje Klienta po 10 minutach nieaktywności
11/52 Dopasowanie (suitability) (3) przykład c.d.: testowanie typowego procesu # Krok testowy Oczekiwany wynik 1 Włóż 1 produkt do koszyka Produkt w koszyku 2 Kliknij checkout Ekran checkoutu 3 4 Wpisz poprawny adres, formę płatności (AmEx) i formę dostawy Weryfikuj informację o zamówieniu Ekrany wyświetlone prawidłowo i wejścia zaakceptowane Wyświetlone jak podano 5 Potwierdź zamówienie Zamówienie w systemie 6 7 Powtórz 1-5, ale z 2 produktami, kartą Visa i zam. międzynarodowe Powtórz 1-5, ale z max liczbą produktów i kartą MasterCard Tak jak w 1-5 Tak jak w 1-5 8 Powtórz 1-5, ale płać Discoverem Tak jak w 1-5
Dopasowanie (suitability) (4) przykład c.d.: testowanie dopasowania przy wyjątkowych warunkach # Krok testowy Oczekiwany wynik 1 0 produktów w koszyku Koszyk pusty 2 Kliknij checkout Komunikat o błędzie 3 Włóż produkt, kliknij checkout, wpisz zły adres, potem złą formę płatności, potem złą inf. o dostawie Komunikaty o błędach; nie da się przejść do następnego eranu dopóki dane nie są poprawne 4 Zweryfikuj info o zamówieniu Wyświetlone jak podano 5 Potwierdź zamówienie Zamówienie w sytemie 6 7 8 Powtórz 1-3, ale zatrzymaj i przerwij po włożeniu produktu Powtórz 1-3, ale zatrzymaj i przerwij po każdym ekranie Powtórz 1-4, nie potwierdzaj zamówienia Użytkownik wylogowany po 10 minutach nieaktywności Jak w 6 Jak w 6 12/52
13/52 Współdziałanie (interoperability) (1) Współdziałanie zdolność systemu do interakcji z jednym lub wieloma komponentami systemu Testowanie poprawności funkcjonalności we wszystkich zamierzonych środowiskach (hardware, software, middleware, infrastruktura sieciowa, systemy bazodanowe, systemy operacyjne) Dotyczy też komponentów dla których współdziałanie jest niebezpośrednie
Współdziałanie (interoperability) (2) Silny nacisk na element testowania konfiguracji Ważny typ testów w przypadku tworzenia lub integracji oprogramowania z półki (COTS) oraz systemów systemów (systems of systems) Ważny typ w fazie testów integracyjnych Stosowane techniki: use-case y, scenariusze testowe podział na klasy równoważności pair-wise, techniki kombinacyjne drzewa klasyfikacji 14/52
15/52 Współdziałanie (interoperability) (3) przykład (kontynuacja przykładu ze sklepem internetowym) połączenie techniki use-case ów z techniką pair-wise 4 typy testów: A. AmEx, 1 produkt, zamówienie do Polski B. Visa, 2 produkty, zamówienie zagraniczne C. MasterCard, max produktów, do Polski D. Discover, 1 produkt, do Polski
Współdziałanie (interoperability) (4) przykład c.d. Środowisko Prz. Test Prędkość System operacyjny Bezpieczeństwo Przeglądarka test. 1 DU XP Symantec Firefox A 2 DU Vista Trend IE B 3 DU Mac McAfee Opera C 4 DU Linux OS ~ D 5 BB XP Trend Opera D 6 BB Vista Symantec ~ C 7 BB Mac OS Firefox B 8 BB Linux McAfee IE A 9 ~ XP McAfee ~ B 10 ~ Vista OS OS A 11 ~ Mac Symantec IE D 12 ~ Linux Trend Firefox C 13 ~ XP OS IE C 14 ~ Vista McAfee Firefox D 15 ~ Mac Trend ~ A 16 ~ Linux Symantec Opera B 16/52
17/52 Użyteczność (usability) (1) Użyteczność zdolność systemu do bycia zrozumiałym, łatwym do nauczenia, użycia i atrakcyjnym dla użytkownika Testowanie skupiające się na użytkownikach Często wymaga wiedzy psychologicznej, socjologicznej oraz wiedzy z zakresu ergonomii; również narodowych/lokalnych standardów dot. dostępności Chcemy obserwować efekty testowania na prawdziwych, końcowych użytkownikach (a nie testerach)
Użyteczność (usability) (2) podcharakterystyki użyteczności Zrozumiałość (jak łatwo zrozumieć co program robi i dlaczego mielibyśmy go używać?) Łatwość nauki (łatwość zrozumienia jak program działa) Łatwość obsługi (czy obsługa programu jest intuicyjna?) Atrakcyjność (czy użytkownik chętnie używa programu?) 18/52
19/52 Użyteczność (usability) (3) techniki testowania użyteczności 1. inspekcja (ewaluacja, przegląd) efektywne w wykrywaniu błędów wcześnie można wykorzystać końcowych użytkowników 2. walidacja aktualnej implementacji może zawierać uruchamianie scenariuszy testów użyteczności 3. ankieta/kwestionariusz/obserwacja obserwowanie użytkowników podczas użytkowania oprogramowania standardowe ankiety typu SUMI, WAMMI
20/52 Użyteczność (usability) (4) usability room źródło: scholar.lib.vt.edu
21/52 Dostępność (accessibility) Dostępność zdolność systemu do bycia używalnym przez użytkowników z różnymi formami inwalidztwa Wymagania często wynikają z jakichś standardów lub wymogów prawnych Standardy narzucają wykorzystanie technologii asystujących (np. text-to-speech, lupa, zmiana kontrastu itp.)
Testowanie techniczne 22/52
23/52 Bezpieczeństwo (security) (1) Bezpieczeństwo atrybuty oprogramowania umożliwiające ochronę przed nieautoryzowanym dostępem do programu i danych Często zagrożenia związane z bezpieczeństwem są ukryte, niejawne i niewidoczne Błędy bezpieczeństwa często nie mają widocznych symptomów (nawet po włamaniu)
24/52 Bezpieczeństwo (security) (2) przykłady obszarów związanych z bezpieczeństwem Piractwo (nieautoryzowany dostęp do danych) SQL injection, hasła, pliki tymczasowe, fizyczna lokalizacja serwera Przepełnienie bufora DoS (denial of service) Przechwycenie transferu danych Łamanie zabezpieczeń (kryptologia) Bomby logiczne/wirusy/robaki Przypadki testowe to zwykle ataki na oprogramowanie
25/52 Bezpieczeństwo (security) (3) przykłady ataków współpracująca aplikacja interfejs użytkownika współpracująca aplikacja współpracująca aplikacja TESTOWANY PROGRAM baza danych system plików system operacyjny kernel aplikacja współdzieląca zasoby
Bezpieczeństwo (security) (4) przykłady ataków c.d. Ataki dot. zależności blokada dostępu do bibliotek manipulacja rejestrem użycie uszkodzonych plików edycja/zmiana danych konfiguracji wymuszenie małych zasobów Ataki na interfejs użytkownika input overflow wykorzystanie różnych konfiguracji inny charset, znaki specjalne, SQL injection Ataki na projekt typowe loginy i hasła atak na niechronione API ataki poprzez porty tworzenie pętli (np. w skryptach) nietypowe przepływy procesów wymuszenie restartu aplikacji Ataki na implementację manipulacja czasem (sync) duplikacja plików o wysokich prawach dostępu wymuszenie komentarzy błędów przeszukanie plików tymczasowych 26/52
Niezawodność (reliability) (1) Niezawodność zdolność oprogramowania do bezbłędnego działania przez określony czas lub przez określoną liczbę operacji Zawsze ważna, ale kluczowa w systemach krytycznych Testy niezawodności wykorzystują profile operacyjne 3 cechy niezawodności: dojrzałość (zdolność do bezawaryjnego działania przy występowaniu usterek) tolerancja na błędy (wyjątki i ich obsługa) odtwarzalność (zdolność działania po awarii) 27/52
Niezawodność (reliability) (2) niezawodność hardware u a software u niezawodność burn-in useful-life end-of-life HARDWARE czas niezawodność SOFTWARE SDLC useful-life obsolescence upgrade 1 upgrade 2 czas 28/52
Niezawodność (reliability) (3) Metryki wykorzystywane do pomiaru niezawodności: MTTF (mean time to failure) MTTR (mean time to repair) MTBF (mean time between failures) gęstość defektów / KLOC złożoność cyklomatyczna liczba modułów liczba określonych konstrukcji programistycznych wartości metryk porównuje się z odpowiednim modelem do monitorowania można użyć tzw. modeli wzrostu niezawodności 29/52
30/52 Efektywność (efficiency) (1) Efektywność zdolność oprogramowania do zapewnienia odpowiedniej wydajności, relatywnie do ilości zużytych zasobów Systemy czasu krytycznego muszą dostarczać swoje funkcje w ściśle określonym czasie Dla systemów czasu rzeczywistego (i innych) ważne jest zużycie zasobów
Efektywność (efficiency) (2) Błędy efektywności powodują: wolny czas odpowiedzi nieadekwatną przepustowość problemy z niezawodnością (obciążenie) nadmierne wymagania co do zasobów Najczęstsza przyczyna: błędy projektowe (a więc są trudne do usunięcia w późniejszych fazach testów) Dlatego t. efektywności winno być przeprowadzane na każdym poziomie testów, zwłaszcza na etapie projektu i kodowania (przeglądy, inspekcje) 31/52
32/52 Efektywność (efficiency) (3) mity o testowaniu wydajności Mit 1. Testowanie wydajności musi polegać na obciążaniu systemu setkami wirtualnych użytkowników i zwiększać tę liczbę aż system się zepsuje Mit 2. Testowanie wydajności można wykonywać tylko pod koniec testów systemowych Mit 3. Wystarczy, by tester obciążeń znał narzędzie do testowania wydajności, a całe testowanie pójdzie sprawnie i gładko
33/52 Efektywność (efficiency) (4) rodzaje testów efektywności testowanie obciążenia (load testing) testowanie warunków skrajnych (stress testing) testowanie skalowalności (scalability testing) testowanie wykorzystania zasobów (resource utilization t.) testowanie wytrzymałościowe (endurance testing) testowanie skokowe (spike testing) testowanie niezawodności (reliability testing) testowanie z aktywnym tłem (background testing) testowanie punktu krytycznego (tip-over testing) i wiele innych!
34/52 Efektywność (efficiency) (5) co należy wiedzieć przed rozpoczęciem testów efektywności? jak wielu użytkowników będzie używać systemu w jednym czasie? jaki jest zakres testów? które podsystemy testujemy? czy testujemy end-to-end czy konkretne akcje użytkowników? jakie konfiguracje podlegają testom? jak bardzo realistyczne będzie testowanie? jakie zadania będą wykonywali użytkownicy? jaki workload-mix będzie występował? jak wiele workload-mixów będzie używanych (współbieżność)? czy użyjemuy wirtualizacji? czy serwery będą dzielone z innymi procesami? jakie back-endowe procesy będą działać podczas testów? procesy wsadowe? procesy typu dating/month processes?
35/52 Efektywność (efficiency) (6) przykład spójnej metodologii dla testowania efektywności Microsoft Developer Network Performance Testing Guidance for Web Applications 1. zidentyfikuj środowisko testowe oraz produkcyjne 2. zidentyfikuj kryteria akceptacji wydajnościowej 3. zaplanuj i zaprojektuj testy 4. skonfiguruj środowisko testowe 5. zaimplementuj testy 6. wykonaj testy 7. przeanalizuj wyniki, dostrój, zretestuj
36/52 Efektywność (efficiency) (7) przykładowe metryki dla wydajności % wykorzystania procesora w kluczowym czasie dostępna pamięć (RAM, wirtualna) top N aktywnych procesów liczba przełączeń kontekstów na sekundę długość kolejek (procesor, dysk) w danym czasie zużycie i wysycenie pamięci dyskowej błędy sieci czas podróży pakietu czas prezentacji danych klientowi
czas przetwarzania transakcji (s) Efektywność (efficiency) (8) przykłady błędów wydajności nieakceptowalna efektywność przy jakimkolwiek obciążeniu nieakceptowalna efektywność przy obciążeniu > 500 trans./h akceptowalna efektywność wysycenie zasobów 500 degradacja efektywności w czasie czas odpowiedzi polepsza się wraz z odmową przetwarzania transakcji ponad ustalony limit akceptowalna efektywność częstotliwość transakcji (1/h) poprawny czas odpowiedzi ale zła obsługa błędów 37/52
38/52 Pielęgnowalność (maintainability) (1) Pielęgnowalność ławtość modyfikowania oprogramowania w celu naprawy defektów, dostosowania do nowych wymagań, ułatwienia przyszłego utrzymywania lub dostosowania do zmian zachodzących w jego środowisku Oprogramowanie się nie zużywa, ale staje się przestarzałe Zatem będą pojawiać się nowe funkcjonalności, patche, update y, nowe środowiska itp.
39/52 Pielęgnowalność (maintainability) (2) Testowanie pielęgnowalności raczej nie polega na pisaniu skryptów testowych; większość defektów jest niewidoczna dla testowania dynamicznego Defekty pielęgnowalności powodowane są m.in.: trudnym do zrozumienia kodem zależnościami środowiskowymi ukrytymi informacjami i stanami zbytnią złożonością Stosowane techniki: testowanie statyczne
40/52 Pielęgnowalność (maintainability) (3) subcharakterystyki pielęgnowalności oraz problemy z nimi związane Analizowalność (łatwość diagnozowania problemów) przyczyny: spaghetti code brak dobrej dokumentacji brak lub złe standardy/zalecenia abstrakcja kodu Stabilność (zdolność do unikania niespodziewanych efektów na skutek zmian) efekt uboczny modyfikowalności przyczyny: związanie kohezja jakość wymagań Modyfikowalność (zdolność do wprowadzania zmian) przyczyny: związanie (coupling) kohezja zły styl kodowania kiepska dokumentacja Testowalność (zdolność do bycia zwalidowanym po wprowadzonej zmianie) przyczyny: brak lub zła dokumentacja brak komentarzy w kodzie zła konwencja nazewnictwa brak instrumentacji kodu
Przenaszalność (portability) (1) Przenaszalność łatwość, z jaką oprogramowanie może być przeniesione z jednego środowiska do innego Najczęstsze przyczyny problemów z przenaszalnością: zależności środowiskowe zajmowanie zasobów niestandardowe interakcje systemu operacyjnego np. klasyczne dla Windows: zmiana w dzielonym rejestrze podczas instalacji lub usunięcie dzielonych plików przy deinstalacji 41/52
koegzystencja (zdolność do współistnienia z innym, niezależnym oprogramowaniem dzielącym środowisko) 42/52 Przenaszalność (portability) (2) subcharakterystyki przenaszalności adaptowalność (zdolność do adaptacji w innym środowisku bez podejmowania akcji innych niż przewidziane w tym celu) nie zawsze dobre! nie zawsze tanie i proste (Java) zastępowalność (możliwość bycia zastąpionym przez inny produkt do tego samego celu w tym samym środowisku) DLL, COM, DCOM, COTS instalowalność (możliwość bycia zainstalowanym w danym środowisku) zależności, błędy, niemożność przerwania
Testowanie z użyciem narzędzi 43/52
44/52 Business case dla automatyzacji (1) koszty ryzyko zyski
Business case dla automatyzacji (2) koszty początkowe: ocena i wybór właściwego narzędzia zakup narzędzia (lub adaptacja open-source owego) nauka narzędzia integracja narzędzia z istniejącymi narzędziami i procesami koszty powracające: utrzymanie narzędzia licencje wsparcie szkolenia (np. dla nowych pracowników) 45/52
46/52 Business case dla automatyzacji (3) ryzyka: nierealistyczne oczekiwania wobec narzędzia niedoszacowanie czasu i zasobów na automatyzację przeszacowanie możliwości narzędzia zbytnia zależność od jednego narzędzia ryzyka związane z dostawcą, wsparciem, adaptowalnością
47/52 Business case dla automatyzacji (4) zyski: długookresowa inwestycja oszczędza czas, wysiłek i pieniądze ostrożny wybór tego, co automatyzować daje dobrze napisane i zaprojektowane, efektywne testy automatyczne (lepsze pokrycie = niższe ryzyko!) lepsza przewidywalność czasu wykonania testów Zysk z inwestycji może się zwrócić dopiero po wielu miesiącach!
48/52 Rodzaje narzędzi narzędzia do zarządzania testowaniem narzędzia do wykonywania testów (capture/replay) narzędzia do debugowania narzędzia do zasiewania błędów narzędzia do fault injection narzędzia do analizy statycznej i dynamicznej narzędzia do testów wydajnościowych narzędzia do monitorowania narzędzia do testowania stron www symulatory i emulatory
Testowanie przy użyciu słów kluczowych (1) (ang. Keyword-Driven Testing) Narzędzia capture/replay nie sprawdzają się jako rozwiązania długookresowe Przykład (Mercury-Interactive): 1. workstationset_window( FREDAPP,11); 2. edit_set( edt_mrnumber, MRE5418 ); 3. obj_type( edt_mrnumber, <ktab> ); 4. password_edit_set( edt_password, kzisnyixmynxfy ); 5. edit_set( Edit_2, VN00417 ); 6. obj_type( Edit_2,,<kReturn> ); 7. set_window( FREDAPP, 7); 8. button_press( No ); 9. set_window( FREDAPP, 5); 10. set_window( edt_mrnumber, BC3456 ); 11. obj_type( edt_mrnumber, <ktab> ); 12. password_edit_set( edt_password, dztcmzgtdzbs ); 13. obj_type( edt_password, <kreturn> ); 14. set_window( FREDAPP97 Msg, 5); 15. button_press( Yes ); 49/52
50/52 Testowanie przy użyciu słów kluczowych (2) (ang. Keyword-Driven Testing) skrypt jest niezbyt czytelny skrypt dosłownie opisuje czynności techniczne; jest zupełnie złym sposobem modelowania zachowania człowieka-testera! tester jest tu małpą, która bezmyślnie robi to, co ręczny testcase każe mu zrobić: kliknij tu, wpisz to ale tester ręczny wykorzystuje też kontekst oraz rozsądek! (wracając do skryptu): co by się stało, gdyby kolejność tabowania się zmieniła? zmiana zabija automatyzację!
51/52 Testowanie przy użyciu słów kluczowych (3) (ang. Keyword-Driven Testing) testowanie przy użyciu słów kluczowych meta-język pozwalający testerowi na bezpośrednią automatyzację testów bez konieczności programowania Przykład: Zadanie Użyte dane Oczekiwany wynik Uruchom SUT C:\...\SUT.exe Uruchamia się poprawnie Login User ID / hasło Loginuje się poprawnie Stwórz nowy rekord Edytuj rekord Wskaźnik do wiersza danych w arkuszu Klucz rekordu: wskaźnik do wiersza danych Info o stworzeniu nowego rekordu Oczekuj info o zmianie rekordu
KONIEC 52/52