Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Rafał Hryniów. Tło historyczne  W roku 1947 komputery były wielkimi maszynami zajmującymi cały pokój, pracującymi na mechanicznych przekaźnikach i żarzących.

Podobne prezentacje


Prezentacja na temat: "Rafał Hryniów. Tło historyczne  W roku 1947 komputery były wielkimi maszynami zajmującymi cały pokój, pracującymi na mechanicznych przekaźnikach i żarzących."— Zapis prezentacji:

1 Rafał Hryniów

2 Tło historyczne  W roku 1947 komputery były wielkimi maszynami zajmującymi cały pokój, pracującymi na mechanicznych przekaźnikach i żarzących się lampach elektronowych. Szczytem techniki był wówczas komputer Mark II, olbrzym budowany na Uniwersytecie Harwardzkim. Technicy właśnie go uruchamiali po raz pierwszy, gdy nagle się zatrzymał. Rzucono się szukać przyczyny i znaleziono ćmę wciśniętą między dwa przekaźniki głęboko we wnętrzu komputera. Najwyraźniej zwabiona światłem i ciepłem wleciała do urządzenia i została zabita przez prąd, kiedy wylądowała na przekaźniku.  Tak narodził się komputerowy BUG!!! 2

3 Co to jest błąd ? Trzeba rozróżnić dwa poniższe pojęcia:  Błąd (ang. fault, error) jest niepoprawną konstrukcją znajdującą się w programie, mogącą prowadzić do niewłaściwego działania.  Błędne wykonanie (ang. failure) to niepoprawne działanie systemu w trakcie jego pracy. Błąd może prowadzić do wielu różnych błędnych wykonań. W wielu sytuacjach może jednak nie objawiać się błędnym wykonaniem. Takie same błędne wykonania mogą być spowodowane różnymi błędami. 3

4 Błąd – formalna definicja Błąd oprogramowania występuje, kiedy spełniony jest przynajmniej jeden z następujących warunków:  Oprogramowanie nie wykonuje czegoś, co według specyfikacji powinno wykonywać.  Oprogramowanie wykonuje coś, czego według specyfikacji nie powinno robić.  Oprogramowanie robi coś, o czym specyfikacja w ogóle nie wspomina.  Oprogramowanie nie wykonuje czegoś, o czym specyfikacja wprawdzie nie wspominna, ale nie powinna.  Oprogramowanie jest trudne do zrozumienia, trudne do użycia, powolne albo – zdaniem testera – będzie w oczach użytkownika po prostu nieprawidłowe. 4

5 Skąd się biorą błędy ? Przeprowadzono wiele badań przedsięwzięć, małych do bardzo dużych i uzyskane wyniki są zawsze takie same. Główną przyczyną powstawania błędów jest specyfikacja. 5

6 Przyczyny powstawania błędów  Specyfikacja – w wielu przypadkach nie została ona po prostu napisana, kiedy indziej nie była dostatecznie dokładna, albo nieustannie się zmieniała, albo nie była wystarczająco znana wszystkim osobom należącym do zespołu.  Projekt produktu – tworzony zbyt pośpiesznie, niedbale, często zmieniający się lub jego treść jest nieprecyzyjnie przekazana innym.  Błędy kodowania – duża złożoność programu, kiepska dokumentacja, stosowanie potencjalnie niebezpiecznych technik 6

7 Aksjomaty testowania  Programu nie da się przetestować całkowicie.  Testowanie oprogramowania jest ryzykowne.  Test nie udowodni braku błędów.  Im więcej błędów się znalazło, tym więcej błędów pozostaje.  Paradoks pestycydów.  Nie wszystkie błędy zostaną naprawione.  Specyfikacje produktu nigdy nie są gotowe.  Testerzy nie są najbardziej lubiani w zespole. 7

8 Testy w modelu V 8

9 Weryfikacja i Walidacja Powyższe nazwy często stosowane są zamiennie, ale mają naprawdę odmienne znaczenia. Ta różnica jest ważna w testowaniu oprogramowania.  Weryfikacja (ang. verification) to potwierdzenie, że coś – oprogramowanie – spełnia wymogi swojej specyfikacji (czyli zdefiniowanymi w fazie określania wymagań).  Walidacja, inaczej atestowanie (ang. validation) to potwierdzenie, że oprogramowanie spełnia rzeczywiste potrzeby użytkowników. 9

10 Metody „czarnej skrzynki” i „szklanej skrzynki”  Stosując metody czarnej skrzynki, tester wie jedynie, co oprogramowanie ma robić – nie zagląda do „wnętrza skrzynki”, żeby zobaczyć jak to działa. Kiedy wprowadzi się pewne dane wejściowe, otrzyma się pewne dane wyjściowe.  Stosując techniki szklanej skrzynki, tester ma dostęp do kodu programu i analizuje go w poszukiwaniu wskazówek, które pomogą w testowaniu. Może wytypować potencjalne niebezpieczeństwa i dostosować do nich swoje testy. 10

11 Testowanie statyczne i dynamiczne  Testowanie statyczne dotyczy czegoś, co nie jest wykonywane – np. kodu lub specyfikacji weryfikowanych za pomocą analizy lub inspekcji.  Testowanie dynamiczne polega na wykonaniu i używaniu (fragmentu) programu i porównywaniu uzyskanych wyników z poprawnymi. 11

12 Testowanie specyfikacji (TS) Znalezienie błędów w tak wczesnej fazie projektu może zaoszczędzić bardzo dużo czasu i pieniędzy. Testowanie specyfikacji jest statycznym testowaniem metodą czarnej skrzynki. Specyfikacja to dokument, nie program do wykonania, więc uważa się ją za statyczną. Jest zbudowana na podstawie danych z wielu różnych źródeł: badań nad użytecznością, badań preferencji klientów, marketingu. Nie trzeba dokładnie wiedzieć, w jaki sposób dane zostały zgromadzone – wystarczy, że zostały spisane w postaci specyfikacji wymagań. 12

13 (TS) Ogólny przegląd 1. Walidacja specyfikacji wymagań Zbadanie kim jest klient/użytkownik Zorientowanie się w dziedzinie działania 2. Zbadanie zgodności standardów i reguł Terminologia i konwencje danego przedsiębiorstwa Wymagania branżowe Standardy państwowe Graficzny interfejs użytkownika (GUI) Standardy sprzętowe i sieciowe 3. Przegląd i zbadanie podobnego oprogramowania 13

14 (TS) Techniki szczegółowe  Kontrolna lista atrybutów specyfikacji Kompletna Dokładna Precyzyjna, jednoznaczna, przejrzysta Spójna Istotna Wykonalna Wolna od szczegółów realizacji Dająca się przetestować  Kontrolna lista terminologii Zawsze, każdy, wszystkie, żaden, nigdy Niewątpliwie, dlatego, jasne, oczywiste, niewątpliwe Niektóre, czasami, często, zwykle, normalnie, najczęściej, większość, głównie. Itd., i tak dalej, i temu podobne, takie jak Dobry, szybki, tani, wydajny, stabilny Opracować, przetworzyć, odrzucić, pominąć, wyeliminować „Jeśli...to” (z pominięciem „w przeciwnym razie”) 14

15 Test pozytywny, test negatywny  Testy pozytywne – kontrolują jedynie, czy oprogramowanie funkcjonuje poprawnie na swego rodzaju minimalnym poziomie. Nie testuje się zbyt daleko, nie szuka się sposobów wywołania awarii za wszelką cenę.  Testy negatywne – projektowanie i wykonywanie zadań testowych, których głównym zadaniem jest złamanie programu – wymuszenie awarii, mają one zmusić nawet dobrze ukryte błędy do ujawnienia się. 15

16 Metoda klas równoważności  Klasa równoważności – zbiór zadań testowych, które testują to samo albo ujawniają ten sam błąd Identyfikując klasy równoważności, warto rozważyć, jak pogrupować podobne dane wejściowe, podobne dane wyjściowe i podobne działania programu. Te grupy mogą być stosownymi klasami równoważności 16

17 Zastosowanie klas równoważności  Warunki graniczne  Puste zbiory danych  Niedozwolone dane 17

18 Analiza kodu (AK)  Badanie projektu konstrukcji i kodu  Formalne przeglądy  Standardy i reguły programowania  Lista kontrolna do przeglądów kodu 18

19 (AK) Formalne przeglądy  Elementy: Identyfikacja problemów – celem przeglądu jest znalezienie błędów i braków Postępowanie według zasad – muszą być określone ścisłe procedury działania Przygotowanie – każdy uczestnik ma inną rolę i musi być do niej przygotowany Pisanie raportu – musi być sporządzony i rozpowszechniony raport o wynikach przeglądu 19

20 (AK) Standardy i reguły programowania  Skąd wziąć standardy ??? American National Standard Institute (ANSI) – International Engineering Consortium (IEC) – International Organisation for Standardisation (ISO) – National Committee for Information Technology Standards (NCITS) – Association for Computing Machinery (ACM) – Institute of Electrical and Electronics Engineers, Inc (IEEE) – 20

21 (AK) Lista kontrolna przeglądu kodu  Błędy w odwołaniach do zmiennych  Błędy w deklarowaniu zmiennych  Błędy obliczeniowe  Błędy w porównaniach  Błędy przepływu sterowania  Błędy w parametrach procedur  Błędy wejścia/wyjścia 21

22 Testowanie interfejsu użytkownika Cechy dobrego interfejsu użytkownika:  Zgodność ze standardami  Intuicyjność  Spójność  Elastyczność  Wygoda  Poprawność  Użyteczność 22

23 Testowanie dokumentacji (1) Znaczenie testowania dokumentacji:  Poprawia użyteczność  Zwiększa niezawodność  Zmniejsza koszty serwisu 23

24 Testowanie dokumentacji (2) Lista kontrolna do testowania dokumentacji:  Odbiorcy  Terminologia  Treść i zawartość  Same fakty  Krok po kroku  Rysunki i ekrany  Próbki i przykłady  Pisownia i gramatyka 24

25 Uwagi (1)  Jeśli użytkownik zostanie wprowadzony w błąd mylnymi instrukcjami instalacyjnymi albo nieprawidłowymi komunikatami o błędach, będzie to dla niego równoznaczne z błędami oprogramowania, które powinni byli znaleźć testerzy.  Dla testera oprogramowania dokumentacja zasługuje na tyle samo uwagi i wysiłku co kod programu. Stanowią one dla użytkownika całość. 25

26 Uwagi (2)  Dokumentację najlepiej testować tak samo, jak będzie się nią posługiwał użytkownik, niezależnie od tego, na ile jest statycznym tekstem, a na ile kodem. Należy ją starannie przeczytać, wykonać każdą z opisanych czynności, sprawdzić każdy rysunek i wypróbować każdy przykład. W ten sposób znajdzie się błędy zarówno w programie, jak i w dokumentacji. 26

27 Testowanie witryn WWW (1)  Metoda czarnej skrzynki (tekst, łącza, grafika, formularze, obiekty i inne elementy złożone)  Metoda szarej skrzynki (częściowe zerkanie)  Metoda szklanej skrzynki 27

28 Testowanie witryn WWW (2)  Testowanie konfiguracji i kompatybilności  Wprowadzenie automatyzacji: 28

29 Testowanie automatyczne i narzędzia do testowania (1) Narzędzia do testowania:  Analizatory i monitory  Sterowniki  Namiastki  Narzędzia do testowania przeciążającego (Microsoft Stress) 29

30 Testowanie automatyczne i narzędzia do testowania (2) Automatyzacja testu oprogramowania:  Nagrywanie i odtwarzanie  Programowane makroprogramy  W pełni programowalne automatyczne narzędzia do testowania (Visual Test) 30

31 Testowanie automatyczne i narzędzia do testowania (3) Testowanie na chybił-trafił: małpy i goryle  Głupie małpy  Półgłupie małpy  Bystre małpy 31

32 Polowanie na błędy i testowanie beta  Podział testowania  Testowanie beta Uwaga! Jednym z największych zagrożeń w projekcie wytwarzania oprogramowania jest próba potraktowania testowania beta jako namiastki prawdziwych testów. Nie wolno tego robić!  Zlecanie testowania innej firmie 32

33 Planowanie testowania  Cele planowania testów (Standard ANSI/IEEE 829/1983) Określenie zakresu, metodyki, zasobów i harmonogramu testowania, zidentyfikowanie przedmiotów testowania, funkcji do przetestowania, czynności, które trzeba wykonać, osób odpowiedzialnych za każdą z nich oraz ryzyka związanego z planem. 33

34 Cele planowania zadań testowych  Organizacja  Powtarzalność  Zarządzanie  Dowód przeprowadzenia testów 34

35 Testowanie ad hoc Testowanie ad hoc polega na tym, że oprogramowanie testuje się bez planu, nie ma żadnych zadań testowych ani nawet planu testowania. Tester zasiada przed komputerem i zaczyna naciskać klawisze. Robi to zwykle wrażenie i może być cennym uzupełnieniem planowanych testów, np.. W czasie zmasowanego „ataku na błędy” ale nie jest zorganizowane, nie daje się powtórzyć, nie daje się tymi działaniami zarządzać, a po zakończeniu, nie ma żadnego dowodu, że tego typu testowanie rzeczywiście przeprowadzono. 35

36 Systemy śledzenia błędów (1) Raport o incydencie (Standard ANSI/IEEE 829)  Identyfikator  Streszczenie  Opis wydarzenia  Skutki 36

37 Systemy śledzenia błędów (2)  Ręczne raportowanie i śledzenie błędów (papierowe raporty)  Automatyczne raportowanie o błędach i śledzenie ich (bazodanowe aplikacje) 37

38 Testy jednostkowe Pozwalają na automatyzację testów Służą przede wszystkim testowaniu zachowania Mogą być uruchamiane cyklicznie bez konieczności ich ręcznego wyzwalania 38

39 Testy jednostkowe  Podstawowe elementy Testów jednostkowych TestCase TestSuite Metody testowe setUp tearDown 39

40 40


Pobierz ppt "Rafał Hryniów. Tło historyczne  W roku 1947 komputery były wielkimi maszynami zajmującymi cały pokój, pracującymi na mechanicznych przekaźnikach i żarzących."

Podobne prezentacje


Reklamy Google