CTFL2011 Statyczne techniki testowania

Z AmberPlace

Spis treści 1 3.1 Techniki statyczne a proces testowania 2 3.2 Proces przeglądu 3 3.3 Analiza statyczna przy pomocy narzędzi 4 Literatura 5 Referencje

K2 60min

Cele nauczania dla technik statycznych.

Te cele określają co będziesz potrafił po zakończeniu modułu.

3.1 Techniki statyczne a proces testowania (K2)

LO-3.1.1 Kandydat potrafi rozpoznać produkty, które mogą zostać sprawdzone przez różne techniki testowania statycznego. (K1)

LO-3.1.2 Kandydat potrafi opisać znaczenie i wartość statystycznych technik testowania w ocenie produktów procesu rozwoju oprogramowania. (K2)

LO-3.1.3 Kandydat potrafi wyjaśnić różnice pomiędzy testami statycznymi i dynamicznymi. (K2)

3.2 Proces przeglądu (K2)

LO-3.2.1 Kandydat pamięta kroki, role i odpowiedzialności związane z typowym przeglądem formalnym. (K2)

LO-3.2.2 Kandydat potrafi wyjaśnić różnice pomiędzy różnymi typami przeglądów: przeglądem nieformalnym, przeglądem technicznym, przejrzeniem i inspekcją. (K2)

LO-3.2.3 Kandydat potrafi wskazać czynniki wpływające na skuteczne przeprowadzanie przeglądów. (K2)

3.3 Analiza statyczna przy pomocy narzędzi (K2)

LO-3.3.1 Kandydat pamięta typowe błędy wykrywane przez analizę statyczną i umie porównać je z przeglądami i testami dynamicznymi. (K1)

LO-3.3.2 Kandydat potrafi opisać używając przykładów typowe korzyści z analizy statycznej. (K1)

LO-3.3.3 Kandydat potrafi wymienić typowe defekty kodu i projektu, które mogą zostać wykryte przez narzędzia do analizy statycznej. (K1)

3.1 Techniki statyczne a proces testowania

K2 15min

Pojęcia
testowanie dynamiczne, testowanie statyczne

W przeciwieństwie do technik dynamicznych, które wymagają uruchomienia oprogramowania, techniki statyczne polegają na sprawdzeniu ręcznym (przeglądach) lub analizie automatycznej (analiza statyczna) kodu lub innych dokumentów projektowych bez uruchamiania kodu.

Przeglądy są jednym ze sposobów na testowanie produktów procesu wytwarzania oprogramowania (łącznie z kodem). Przeglądy można wykonywać na długo przed wykonaniem testów dynamicznych. Usterki znalezione podczas przeglądów we wczesnych fazach produkcji oprogramowania (np. defekty znalezione w wymaganiach) często okazują się dużo tańsze do usunięcia niż te wykryte podczas wykonywania testów dynamicznych.

Przeglądy można wykonywać całkowicie ręcznie, ale istnieje dla nich również wsparcie narzędziowe. Główną czynnością wykonywaną manualnie jest sprawdzenie produktu i zanotowanie uwag. Przeglądom mogą podlegać wszystkie produkty procesu wytwarzania oprogramowania: specyfikacja wymagań, projekt, kod, plany testów, specyfikacja testów, przypadki testowe, skrypty testowe, podręcznik użytkownika oraz strony webowe.

Główne korzyści z wykonywania przeglądów to: wczesne wykrycie i naprawa usterek, zwiększenie produktywności produkcji oprogramowania, redukcja czasu produkcji oprogramowania, zmniejszenie kosztów i czasu testowania, ogólne zmniejszenie kosztu wytwarzania i użytkowania oprogramowania, zmniejszenie liczby usterek oraz usprawnienie komunikacji. Przeglądy mogą wykrywać braki (na przykład w wymaganiach), które trudno jest wykryć w testach dynamicznych.

Przeglądy, analiza statyczna oraz testy dynamiczne mają ten sam cel – znajdowanie defektów. Te trzy techniki uzupełniają się wzajemnie, mogą skutecznie i efektywnie znajdować różne typy błędów. Techniki statyczne, w odróżnieniu od testów dynamicznych, znajdują raczej przyczyny awarii (usterki), a nie same awarie.

Do typowych defektów, które łatwiej wykryć w testach statycznych niż dynamicznych należą: odchylenia od standardów, usterki w wymaganiach, usterki w projekcie, niedostateczna pielęgnowalność oraz nieprawidłowe specyfikacje interfejsów.

3.2 Proces przeglądu

K2 25min

Pojęcia
kryteria wejścia, przegląd formalny, przegląd nieformalny, inspekcja, metryka, moderator, przegląd koleżeński, przeglądający, protokólant, przegląd techniczny, przejrzenie

Wstęp

Istnieją różne typy przeglądów, od nieformalnych, cechujących się brakiem spisanych instrukcji dla przeglądających, do systematycznych, uwzględniających przygotowanie zespołu, zapisanie wyników przeglądu oraz udokumentowane procedury wykonania przeglądu. Stopień sformalizowania przeglądu zależy od takich czynników jak dojrzałość procesu produkcyjnego, czy wymagań wynikających z prawa lub konieczności udokumentowania przebiegu przeglądu.

Proces przeprowadzenia przeglądu zależy od jego celów (np. znajdowania usterek, zrozumienia produktu lub zadania, przekazania wiedzy testerom i nowym członkom zespołu lub przedyskutowania i podjęcia uzgodnionej decyzji).

3.2.1 Kroki przeglądu formalnego

K1

Przegląd formalny zwykle składa się z następujących faz:

1. planowanie

• definiowanie kryteriów przeglądu
• wybór uczestników przeglądu
• przydział ról
• ustalenie kryteriów wejścia i zakończenia dla bardziej formalnych typów przeglądów (np. dla inspekcji)
• wybór fragmentów dokumentu do przejrzenia

2. rozpoczęcie

• rozesłanie dokumentów
• opisanie celów przeglądu, procesu i dokumentów uczestnikom przeglądu
• sprawdzenie kryteriów wejścia (dla bardziej formalnych typów przeglądów)

3. przygotowanie indywidualne

• przygotowanie przed spotkaniem przeglądowym przez przejrzenie dokumentów
• zapisywanie potencjalnych defektów, pytań i komentarzy

4. sprawdzenie/ocena/zapisanie wyników (spotkanie przeglądowe)

• dyskusja lub spisywanie, z udokumentowaniem wyników i sporządzeniem protokołu (dla bardziej formalnych typów przeglądów)
• zapisywanie defektów i rekomendacji dotyczących ich poprawiania, podejmowanie decyzji co do defektów

5. poprawki

• naprawianie znalezionych defektów, zwykle wykonywane przez autora
• uaktualnianie statusów defektów (w przeglądach formalnych)

6. sprawdzenie

• sprawdzenie, że usterki zostały obsłużone
• zbieranie metryk
• sprawdzanie kryteriów zakończenia (dla bardziej formalnych typów przeglądów)

3.2.2 Role i odpowiedzialność

K1

Uczestnicy przeglądów formalnych mogą pełnić następujące role:

kierownik

Decyduje o wykonaniu przeglądów, przydziela czas w harmonogramie projektu i sprawdza, czy zostały zrealizowane cele przeglądu

moderator

Osoba, która prowadzi przegląd dokumentu lub zbioru dokumentów, włączając w to planowanie przeglądu, prowadzenie spotkań i sprawdzenie czy ustalenia ze spotkania zostały wypełnione. Jeżeli jest to konieczne, moderator może mediować pomiędzy różnymi punktami widzenia i często jest osobą, od której zależy sukces przeglądu.

autor

Osoba która napisała lub nadzorowała powstanie dokumentu podlegającego przeglądowi.

przeglądający

Osoby, z odpowiednim przygotowaniem biznesowym lub technicznym (również nazywani kontrolerami lub inspektorami), którzy po niezbędnym przygotowaniu, znajdują i spisują uwagi (np. usterki) do przeglądanego produktu. Przeglądający powinni zastać tak dobrani, żeby reprezentowali różne spojrzenia i różne role w procesie przeglądu. Przeglądający powinni brać udział w każdym spotkaniu przeglądowym.

protokólant

Dokumentuje wszystkie zagadnienia, problemy lub różnice zdań, które pojawiły się na spotkaniu przeglądowym.

Przeglądanie produktów programistycznych lub innych produktów z nimi związanych z różnych perspektyw oraz wykorzystywanie list kontrolnych może sprawić, że przeglądy będą skuteczniejsze i bardziej efektywne. Na przykład listy kontrolne uwzględniające różne spojrzenia takie jak perspektywa użytkownika, serwisanta, testera lub operatora, albo lista kontrolna typowych problemów z wymaganiami mogą pomóc w wykrywaniu nie znalezionych wcześniej defektów.

3.2.3 Typy przeglądów

K2

Pojedynczy produkt programistyczny lub inny powiązany z nim produkt może podlegać więcej niż jednemu przeglądowi. Jeżeli wykorzystywane jest kilka typów przeglądów, to mogą być wykonywane w różnym porządku. Na przykład przegląd nieformalny może być przeprowadzony przed przeglądem technicznym, albo inspekcja specyfikacji wymagań może poprzedzać przejrzenie ich z klientem.

Głównymi cechami, opcjami i celami powszechnie stosowanych typów przeglądów są:

Przegląd nieformalny

• brak formalnego procesu
• może przybrać formę programowania w parach oraz przegląd projektu lub kodu przez kierownika zespołu
• może być udokumentowany
• jego użyteczność może być różna w zależności od przeglądających
• główny cel: tani sposób na osiągnięcie niewielkich korzyści

Przejrzenie

• spotkanie jest prowadzone przez autora
• może przybrać formę scenariuszy, uruchamiania "na sucho", grupa kolegów
• sesje nie ograniczone czasowo
  • opcjonalnie przygotowanie przeglądających przed spotkaniem
  • opcjonalnie raport z przeglądu, lista uwag
• opcjonalnie protokólant (którym nie jest autor)
• w praktyce może być od całkiem nieformalnego do bardzo formalnego
• główne cele: uczenie się, zrozumienie, znajdowanie usterek

Przegląd techniczny

• posiada zdefiniowany proces wykrywania defektów m.in. przez kolegów i ekspertów technicznych z opcjonalnym udziałem kierownictwa
• może być organizowany jako przegląd koleżeński bez udziału kierownictwa
• w idealnej sytuacji prowadzony przez przeszkolonego moderatora (nie autora)
• przygotowanie przeglądających przed spotkaniem
• opcjonalnie z wykorzystaniem list kontrolnych
• przygotowanie raportu z przeglądu, który zawiera listę uwag, ocenę czy produkt programistyczny spełnia wymagania i, tam gdzie jest to potrzebne, rekomendacje związane z uwagami
• w praktyce może być wykonywany w sposób od całkiem nieformalnego do bardzo formalnego
• główne cele: przedyskutowanie, podjęcie decyzji, ocena alternatyw, wyszukanie usterek, rozwiązanie problemów technicznych oraz sprawdzenie zgodności ze specyfikacją i standardami

Inspekcja

• prowadzona przez przeszkolonego moderatora (nie autora)
• zwykle sprawdzenie przez kolegów
• posiada zdefiniowane role
• posiada metryki
• posiada formalny proces oparty na regułach i listach kontrolnych
• posiada zdefiniowane kryteria wejścia i zakończenia
• przygotowanie przed spotkaniem przeglądowym
• raport z inspekcji zawierający listę uwag
• formalny proces kontroli wykonania napraw
  • opcjonalnie elementy doskonalenia procesów
• opcjonalnie wykorzystanie czytającego
• główny cel: wyszukanie usterek

Przejrzenia, przeglądy techniczne oraz inspekcje można wykonywać w grupie osób równych rangą - kolegów z tego samego szczebla organizacji. Taki przegląd nazywa się przeglądem koleżeńskim.

3.2.4 Czynniki wpływające na powodzenie przeglądów

K2

Następujące czynniki wpływają na sukces przeglądów:

• każdy przegląd ma jasno zdefiniowany cel
• w przegląd zaangażowani są ludzie odpowiedni do jego celu
• testerzy są wartościowymi przeglądającymi, którzy przyczyniają się do sukcesu przeglądu oraz poznają produkt, co pozwala im przygotować testy wcześniej
• znalezione usterki są przyjmowane pozytywnie i wyrażane w sposób obiektywny
• rozwiązuje się problemy personalne i psychologiczne (np. jest to pozytywnym doświadczeniem dla autora)
• przegląd jest prowadzony w atmosferze zaufania; wyniki przeglądu nie zostają użyte do oceny uczestników przeglądu
• stosuje się techniki przeglądania adekwatne do celów przeglądu, do typu i poziomu produktu oraz przeglądających
• jeżeli jest to potrzebne, zostają użyte listy kontrolne lub role do podniesienia skuteczności znajdowania usterek
• organizuje się szkolenia, szczególnie z bardziej formalnych technik takich jak inspekcja
• kierownictwo wspiera dobry proces przeglądu (np. przez przeznaczenie odpowiedniej ilości czasu w harmonogramach na zadania związane z przeglądem)
• kładzie się nacisk na uczenie się oraz doskonalenie procesów

3.3 Analiza statyczna przy pomocy narzędzi

K2 20min

Pojęcia
kompilator, złożoność, przepływ sterowania, przepływ danych, analiza statyczna

Celem analizy statycznej jest wyszukanie usterek w kodzie programu lub w modelach bez uruchamiania oprogramowania, które jest sprawdzane przez narzędzie używane w tym procesie. Miejscem, w którym kod jest wykonywany, są testy dynamiczne. Analiza statyczna może znaleźć usterki, które są trudne do znalezienia podczas testowania dynamicznego. Tak jak to było w przypadku przeglądów, analiza statyczna znajduje usterki, a nie awarie. Narzędzia do analizy statycznej analizują kod oprogramowania (np. przepływ sterowania lub przepływ danych) jak również wygenerowane wyjście w postaci HTMLa lub XMLa.

O wartości analizy statycznej stanowią następujące jej cechy:

• wczesne wykrywanie usterek, jeszcze przed wykonaniem testów
• wczesne wykrywanie podejrzanych aspektów kodu lub projektu przez wyliczenie miar, takich jak wysoki stopień złożoności
• identyfikacja defektów trudnych do wykrycia przez testowanie
• wykrywanie zależności i niespójności w modelach oprogramowania
• zwiększenie pielęgnowalności kodu i projektu
• zapobieganie defektom, jeżeli zastosowane zostają wnioski z analizy procesu rozwoju oprogramowania

Analiza statyczna zwykle wykrywa następujące typy usterek:

• odwołanie do niezainicjalizowanej zmiennej
• niespójne interfejsy pomiędzy modułami
• niewykorzystywane lub niepoprawnie zadeklarowane zmienne
• martwy kod
• brakująca albo błędna logika (pętle potencjalnie nieskończone)
• zbyt skomplikowane konstrukcje
• naruszenie standardów kodowania
• słabe punkty zabezpieczeń
• naruszenie reguł składni kodu i modeli oprogramowania

Narzędzia do analizy statycznej używane są zwykle przez programistów (do sprawdzania zgodności ze zdefiniowanymi regułami lub standardami kodowania) przed lub w trakcie testów modułowych lub integracyjnych lub też podczas wkładanie kodu do narzędzi kontroli wersji (commit) . Mogą one też być wykorzystywane przez projektantów podczas modelowania oprogramowania. Narzędzia do analizy statycznej mogą zaraportować dużą liczbę ostrzeżeń, którymi trzeba dobrze zarządzać, żeby uzyskać jak największą skuteczność użycia narzędzia.

Kompilatory wykonują pewne elementy analizy statycznej, w tym obliczanie miar dotyczących kodu źródłowego.

Literatura

3.2	IEEE 1028
3.2.2	Gilb,1993, van Veenendaal, 2004
3.2.4	Gilb,1993, IEEE 1028
3.3	van Veenendaal, 2004

Referencje