CTFL2011 Testowanie w cyklu życia oprogramowania
Z AmberPlace
|
| K2 115min |
Cele nauczania dla testowania w cyklu życia oprogramowania.
Te cele określają co będziesz potrafił po zakończeniu modułu.
2.1 Modele wytwarzania oprogramowania K2
- LO-2.1.1 Kandydat potrafi wyjaśnić powiązania pomiędzy rozwojem oprogramowania, czynnościami testowymi oraz produktami w cyklu życia oprogramowania i podać przykłady na podstawie cech projektu i produktu oraz kontekstu. (K2)
- LO-2.1.2 Kandydat akceptuje fakt, że modele wytwarzania oprogramowania muszą zostać zaadaptowane według cech projektu i produktu. (K1)
- LO-2.1.3 Kandydat pamięta atrybuty dobrego testowania mające zastosowanie w każdym z modeli rozwoju oprogramowania. (K1)
- LO-2.2.1 Kandydat potrafi porównać różne poziomy testów: główne cele, typowe przedmioty testów, typowe cele testowania (np. strukturalne lub funkcjonalne) i związane z nimi produkty, testerów, typy usterek i awarii do znalezienia. (K2)
- LO-2.3.1 Kandydat potrafi porównać podając przykłady cztery typy testów (funkcjonalne, niefunkcjonalne, strukturalne oraz związane ze zmianami). (K2)
- LO-2.3.2 Kandydat uznaje, że testy funkcjonalne i strukturalne występują na każdym poziomie testów. (K1)
- LO-2.3.3 Kandydat potrafi wymienić i opisać różne typy testów niefunkcjonalnych bazujących na wymaganiach niefunkcjonalnych. (K2)
- LO-2.3.4 Kandydat potrafi wymienić i opisać typy testów bazujące na analizie struktury lub architektury systemu. (K2)
- LO-2.3.5 Kandydat potrafi opisać cel wykonywania testów potwierdzających i regresywnych. (K2)
2.4 Testowanie pielęgnacyjne K2
- LO-2.4.1 Kandydat potrafi porównać testy pielęgnacyjne (testowanie istniejącego systemu) do testowania nowej aplikacji uwzględniając typy testów, powody rozpoczęcia[1] testowania oraz ilość testów. (K2)
- LO-2.4.2 Kandydat potrafi wymienić powody wykonywania testów pielęgnacyjnych (zmiany, migracja i wycofanie systemu). (K1)
- LO-2.4.3 Kandydat potrafi opisać rolę testów regresywnych i analizy wpływu w utrzymaniu. (K4)
2.1 Modele wytwarzania oprogramowania
| K2 20min |
| Pojęcia |
|---|
| komercyjne oprogramowanie z półki (COTS), iteracyjny-przyrostowy model wytrwarzania, walidacja, weryfikacja, model V |
Wstęp
Testowanie nie dzieje się w izolacji. Czynności testowania powiązane są z działaniami związanymi z rozwojem oprogramowania. Różne modele rozwoju oprogramowania wymagają różnego podejścia do testowania.
2.1.1 Model V (model sekwencyjny)
| K2 |
Najczęściej spotykany model V posiada cztery poziomy testowania odpowiadające czterem poziomom rozwoju oprogramowania. Istnieją też inne warianty tego modelu.
Cztery poziomy testowania używane w tym sylabusie to:
W praktyce model V może posiadać więcej, mniej lub w ogóle inne poziomy testowania i rozwoju oprogramowania zależnie od konkretnego projektu i wytwarzanego oprogramowania. Na przykład po testach modułowych może następować testowanie integracji modułów, a po testach systemowych - testy integracji systemów.
Produkty związane z wytwarzaniem oprogramowania (takie jak scenariusze biznesowe lub przypadki użycia, wymagania, projekt i kod źródłowy) są często podstawą do testowania na jednym lub wielu poziomach. Odniesienia do ogólnych produktów znajdują się w Capability Maturity Model Integration (CMMI) oraz "Software life cycle processes" (IEEE/IEC 12207). Podczas wytwarzania tych produktów można już wykonywać ich weryfikację i walidację (oraz wstępne projektowanie testów).
2.1.2 Modele iteracyjno-przyrostowe
| K2 |
Iteracyjno-przyrostowe wytwarzanie oprogramowania to proces zbierania wymagań, projektowania, budowania oraz testowania systemu zorganizowany w krótsze cykle rozwojowe. Na przykład: prototypowanie, RAD, Rational Unified Process (RUP) oraz metodyki zwinne. System wyprodukowany według takiego modelu może być przetestowany na kilku poziomach w każdej iteracji. Przyrost, dodany do innych wytworzonych wcześniej, staje się rosnącym systemem częściowym, który również powinien być przetestowany. Testowanie regresywne jest bardzo ważne w każdej iteracji oprócz pierwszej. Każdy przyrost może podlegać zarówno weryfikacji jak i walidacji.
2.1.3 Testowanie w cyklu życia oprogramowania
| K2 |
W każdym modelu rozwoju oprogramowania dobre testowanie posiada kilka niezmiennych cech:
- dla każdej czynności związanej z wytworzeniem oprogramowania istnieją odpowiadające jej czynności związane z testowaniem
- każdy poziom testowania ma zdefiniowane cele
- analiza i projektowanie testów dla danego poziomu powinny rozpoczynać się już podczas odpowiadającej im fazy wytwarzania
- testerzy powinni uczestniczyć w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania
Poziomy testowania mogą być łączone lub organizowane na różne sposoby w zależności od natury projektu lub architektury systemu. Na przykład przy integracji oprogramowania z półki w jeden system nabywca może przeprowadzić testy integracyjne na poziomie systemowym (np. integracja z infrastrukturą i innymi systemami lub wdrożenie systemu) oraz testy akceptacyjne (funkcjonalne i niefunkcjonalne oraz testy akceptacyjne użytkownika i testy produkcyjne).
2.2 Poziomy testowania
| K2 40min |
Wstęp
Dla każdego poziomu testowania można zdefiniować: ogólne cele, produkty, na podstawie których tworzy się przypadki testowe (podstawę testów), przedmiot testów (to co jest testowane), typowe defekty i awarie do wykrycia, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe, specyficzne podejście, odpowiedzialność.
Podczas planowania testów powinno zostać uwzględnione również testowanie danych konfiguracyjnych.
2.2.1 Testy modułowe
| K2 |
Podstawa testów:
- wymagania na moduły
- projekt szczegółowy
- kod
Typowe obiekty testów:
- moduły
- programy
- programy do konwersji lub migracji danych
- moduły bazodanowe
Testy modułowe polegają na wyszukiwaniu błędów i weryfikacji funkcjonalności oprogramowania (np. modułów, programów, obiektów, klas), które można testować oddzielnie. Może być wykonywane w izolacji od reszty systemu, w zależności od kontekstu cyklu rozwoju oprogramowania i od samego systemu. Można podczas nich użyć zaślepek, sterowników testowych oraz symulatorów.
Testy modułowe mogą zawierać testy funkcjonalności oraz niektórych atrybutów niefunkcjonalnych, takich jak użycia zasobów (np. wycieków pamięci) lub odporności, jak również testy strukturalne (np. pokrycia decyzji). Przypadki testowe są projektowane na podstawie takich produktów jak specyfikacja modułu, projekt oprogramowania lub model danych.
Testy modułowe zwykle wykonuje się mając dostęp do kodu źródłowego i przy wsparciu środowiska rozwojowego (np. bibliotek do unit testów, narzędzi do debagowania) oraz, w praktyce, zwykle angażują też programistę, który jest autorem kodu. Usterki są usuwane jak tylko zostaną wykryte, bez formalnego zarządzania nimi.
Jednym z podejść do testów modułowych jest przygotowanie i zautomatyzowanie przypadków testowych przed kodowaniem. Podejście to nazywane jest "najpierw testuj" lub wytwarzaniem sterowanym testowaniem. Jest to podejście wysoce iteracyjne i opiera się na cyklach tworzenia przypadków testowych, a następnie budowaniu i integracji niewielkich fragmentów kodu, wykonywaniu testów modułowych, poprawianiu usterek i powtarzaniu tego procesu aż testy zostaną zaliczone.
2.2.2 Testy integracyjne
| K2 |
Podstawa testów:
- projekt oprogramowania i systemu
- architektura
- przepływy procesów
- przypadki użycia
Typowe obiekty testów:
- implementacja baz danych podsystemów
- infrastruktura
- interfejsy
- konfiguracja systemu i dane konfiguracyjne
Testy integracyjne sprawdzają interfejsy pomiędzy modułami, interakcje z innymi częściami systemu (takimi jak system operacyjny, system plików i sprzęt) oraz interfejsy pomiędzy systemami.
Testy integracyjne mogą zostać zorganizowane w więcej niż jeden poziom i mogą być wykonywane dla przedmiotów testów o różnej wielkości:
- testowanie integracji modułów sprawdza interakcje pomiędzy modułami oprogramowania i jest wykonywane po testach modułowych
- testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem a oprogramowaniem i może być wykonywane po testach systemowych
- W takim przypadku organizacja rozwijająca system może kontrolować tylko jedną stronę interfejsu. Może to zostać uznane za ryzyko. Procesy biznesowe zaimplementowane jako przepływ pracy[2] mogą angażować wiele systemów. W takim przypadku istotne mogą okazać się różnice między platformami, na których zaimplementowane są poszczególne systemy.
Im większy jest zakres integracji, tym trudniejsze może być określenie, który moduł lub system zawiera defekt, co powoduje zwiększone ryzyko i dłuższy czas rozwiązywania problemów.
Systematyczne strategie integracji mogą bazować na architekturze systemu (np. strategie wstępująca i zstępująca), zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji albo na innym aspekcie systemu lub modułu. Żeby ułatwić namierzanie usterek oraz ich wczesne wykrywanie, w normalnych warunkach integracja powinna być raczej prowadzona metodą inkrementalną niż metodą "wielkiego wybuchu".
Podczas testów integracyjnych można wykonać testy niektórych atrybutów niefunkcjonalnych (np. wydajności) na równi z testami funkcjonalnymi.
Na każdym etapie integracji, testerzy koncentrują się wyłącznie na samej integracji. Na przykład, gdy integrują moduł A z modułem B, interesują się tylko testowaniem komunikacji pomiędzy modułami, a nie funkcjonalnością poszczególnych modułów, gdyż ta była sprawdzona wcześniej w testach modułowych. Można tu wykorzystać zarówno podejście funkcjonalne jak i strukturalne.
W idealnym przypadku tester powinien rozumieć architekturę i mieć wpływ na planowanie integracji. Jeżeli testy integracyjne planowane są zanim moduły lub systemy zostały wyprodukowane, można ich rozwój ustawić w kolejności pozwalającej na najbardziej efektywne testowanie.
2.2.3 Testy systemowe
| K2 |
Podstawa testów:
- wymagania na system i oprogramowanie
- przypadki użycia
- specyfikacja funkcjonalna
- raporty z analizy ryzyka
Typowe obiekty testów:
- podręczniki systemowe, użytkownika i operacyjne
- konfiguracje systemu i dane konfiguracyjne
Testy systemowe zajmują się zachowaniem systemu/produktu. Zakres testów powinien być jasno określony w głównym planie testów oraz w planach testów poszczególnych poziomów.
Środowisko testowe, podczas testów systemowych, powinno być zgodne ze środowiskiem docelowym /produkcyjnym w jak najwyższym możliwym stopniu, żeby zminimalizować ryzyko wystąpienia awarii spowodowanych przez środowisko, które nie zostałyby wykryte podczas testów.
Testy systemowe mogą zawierać testy oparte na ryzyku lub wymaganiach, procesie biznesowym, przypadkach użycia lub jeszcze innych wysokopoziomowych opisach słownych lub modelach zachowania systemu, interakcji z systemem operacyjnym i zasobami systemowymi.
Testy systemowe powinny sprawdzać funkcjonalne jak i niefunkcjonalne wymagania na system oraz jakość danych. Wymagania mogą być wyrażone w formie tekstu lub modeli. Testerzy muszą umieć sobie poradzić z wymaganiami niekompletnymi lub nieudokumentowanymi. Testowanie systemowe wymagań funkcjonalnych rozpoczyna się przez użycie najbardziej odpowiednich technik opartych na specyfikacji (czarnoskrzynkowych) dla testowanego aspektu systemu. Na przykład można utworzyć tablicę decyzyjną zawierającą kombinacje skutków opisane w regułach biznesowych. Następnie można użyć technik opartych na strukturze (białoskrzynkowych) do oceny dokładności testowania w odniesieniu do elementów struktury, takich jak menu lub nawigacja po stronach webowych. (Patrz rozdział 4)
Testy systemowe są często wykonywane przez niezależny zespół testowy.
2.2.4 Testy akceptacyjne
| K2 |
Podstawa testów:
- wymagania użytkownika
- wymagania systemowe
- przypadki użycia
- procesy biznesowe
- raporty z analizy ryzyka
Typowe obiekty testów:
- proces biznesowy w systemie w pełni zintegrowanym
- procesy utrzymania i obsługi
- procedury pracy użytkowników
- formularze
- raporty
- dane konfiguracyjne
Odpowiedzialność za testy akceptacyjne leży często po stronie klientów lub użytkowników systemu. Mogą w nie być zaangażowani również inni interesariusze.
Celem testów akceptacyjnych jest nabranie zaufania do systemu, jego części lub pewnych atrybutów niefunkcjonalnych. Wyszukiwanie usterek nie jest tym, na czym skupiają się testy systemowe. Mogą one oceniać gotowość systemu do wdrożenia i użycia, chociaż nie muszą być ostatnim poziomem testowania. Na przykład może po nich następować testowanie integracji systemów w większej skali.
Testy akceptacyjne mogą pojawić się w wielu momentach cyklu życia oprogramowania. Na przykład:
- oprogramowanie z półki może podlegać testom akceptacyjnym, gdy jest instalowane lub integrowane
- testy akceptacyjne użyteczności modułu mogą być wykonane w czasie testów modułowych
- testy akceptacyjne nowej funkcjonalności mogą być przeprowadzone przed testami systemowymi
Typowymi formami testów akceptacyjnych są:
Testowanie akceptacyjne przez użytkownika
Zwykle sprawdza przydatność[3] systemu dla użytkowników.
(Akceptacyjne) testy produkcyjne
Akceptacja systemu przez administratorów:
- testowanie wykonywania i odtwarzania kopii zapasowych
- uruchamianie systemu po awarii[4]
- zarządzanie użytkownikami
- zadania związane z utrzymaniem systemu
- ładowanie danych i inne zadania związane z migracją
- okresowe sprawdzenie słabych punktów zabezpieczeń
Testy akceptacyjne zgodności z umową i testy zgodności legislacyjnej
Testy zgodności z umową są wykonywane przez sprawdzenie spełnienia kryteriów akceptacji zapisanych w kontrakcie na wykonanie oprogramowania na zamówienie. Te kryteria akceptacji powinny być zdefiniowane w momencie negocjacji umowy. Testy zgodności legislacyjnej wykonuje się sprawdzając, czy oprogramowanie jest zgodne z wszystkimi przepisami prawnymi, z którymi musi być zgodne, takimi jak rozporządzenia rządowe, inne akty prawne lub przepisy dotyczące bezpieczeństwa.
Testy alfa i beta (lub polowe)
Producenci oprogramowania na szeroki rynek (oprogramowania z półki) często chcą uzyskać opinię potencjalnych lub obecnych klientów, zanim oprogramowanie zostanie wypuszczone do sprzedaży. Testy alfa są wykonywane u producenta, ale nie przez zespół projektowy. Testy beta, lub testy polowe, wykonywane są przez klientów lub potencjalnych klientów w ich własnych lokalizacjach.
W różnych organizacjach mogą być w użyciu inne nazwy, takie jak fabryczne testy akceptacyjne lub docelowe testy akceptacyjne[5] w sytuacji, gdy system jest testowany przed i po zainstalowaniu u klienta.
2.3 Typy testów
| K2 40min |
Wstęp
Grupa czynności testowych może być nakierowana na weryfikację systemu (lub części systemu) bazując na konkretnym powodzie lub celu testów.
Testy określonego typu skupiają się na konkretnym celu testu, którym może być którekolwiek z poniższych
- przetestowanie jakiejś funkcji wykonywanej przez oprogramowanie
- przetestowanie jakiegoś niefunkcjonalnego atrybutu jakościowego (takiego jak niezawodność lub użyteczność),
- przetestowanie struktury lub architektury systemu
- testy związane ze zmianami, to jest potwierdzaniem, że usterki zostały naprawione (testowanie potwierdzające) i szukaniem niezamierzonych zmian (testowanie regresywne).
Można opracować model oprogramowania i użyć go w testach strukturalnych (np. model przepływu sterowania, model struktury menu), testach niefunkcjonalnych (np. model wydajności, model użyteczności, model zagrożeń zabezpieczeń) lub funkcjonalnych (np. model przepływu procesu, model przejść między stanami lub specyfikacja w języku naturalnym).
2.3.1 Testowanie funkcji (testowanie funkcjonalne)
| K2 |
Funkcje, jakie ma pełnić system, podsystem lub moduł, mogą być opisane w produktach takich jak specyfikacja wymagań, przypadki użycia lub specyfikacja funkcjonalna. Mogą też być nieudokumentowane. Funkcje są tym "co" system robi.
Testy funkcjonalne dotyczą funkcji lub innych cech[6] (opisanych w dokumentach lub domniemanych przez testerów) oraz ich współdziałania z innymi systemami. Można je wykonywać na wszystkich poziomach (np. testy modułowe mogą bazować na specyfikacji modułów).
Do tworzenia warunków testowych oraz przypadków testowych z funkcjonalności systemu mogą zostać użyte techniki oparte na specyfikacji (Patrz rozdział 4). Testy funkcjonalne zajmują się zewnętrznym zachowaniem oprogramowania (testy czarnoskrzynkowe).
Jeden z typów testów funkcjonalnych - testowanie zabezpieczeń - sprawdza funkcje (np. zapory) pozwalające na wykrycie zagrożeń, takich jak wirusy, pochodzących od złośliwych obcych. Inny typ testów funkcjonalnych: testowanie współdziałania, ocenia zdolność oprogramowania do współpracy z jednym lub większą liczbą wskazanych modułów lub systemów.
2.3.2 Testowanie atrybutów niefunkcjonalnych (testowanie niefunkcjonalne)
| K2 |
Testowanie niefunkcjonalne obejmuje następujące (ale nie tylko te) typy testów: testowanie wydajnościowe, testowanie obciążeniowe, testowanie przeciążeniowe, testowanie użyteczności, testowanie pielęgnowalności, testowanie niezawodności oraz testowanie przenaszalności. Testowanie niefunkcjonalne polega na sprawdzeniu "jak" system działa.
Testowanie niefunkcjonalne może być wykonywane na wszystkich poziomach testów. Termin testy niefunkcjonalne oznacza testy wymagane do zmierzenia właściwości systemów i oprogramowania, które mogą zostać określone ilościowo na zmiennej skali, takich jak czasy odpowiedzi w testach wydajnościowych. Testy te mogą zostać odniesione do modelu jakości oprogramowania np. "Software Engineering – Software Product Quality" (ISO 9126). Testy niefunkcjonalne zajmują się zewnętrznym zachowaniem oprogramowania i w większości wypadków wykorzystują techniki czarnoskrzynkowe.
2.3.3 Testowanie struktury/architektury oprogramowania (testowanie strukturalne)
| K2 |
Testy strukturalne (białoskrzynkowe) można wykonywać na każdym poziomie testowania. Technik strukturalnych najlepiej użyć po technikach opartych na specyfikacji, po to by zmierzyć dokładność testowania przez ocenę stopnia pokrycia wybranego typu struktury.
Pokrycie, to stopień w jakim struktura została przetestowana przez zestaw testów wyrażony jako odsetek pokrytych elementów. Jeżeli pokrycie jest niższe niż 100%, można zaprojektować więcej testów, żeby przetestować te elementy, które zostały pominięte, i w ten sposób zwiększyć pokrycie. Techniki oparte na pokryciu opisane są w rozdziale 4.
Do pomiaru pokrycia (na przykład decyzji lub instrukcji) na wszystkich poziomach, ale szczególnie na poziomie testów modułowych i poziomie testów integracji modułów, mogą zostać użyte narzędzia. Testowanie strukturalne może zostać oparte na architekturze systemu, na przykład hierarchii wywołań.
Podejście strukturalne może mieć zastosowanie również w testach systemowych, testach integracji systemów oraz testach akceptacyjnych (np. do modeli biznesowych lub struktur menu).
2.3.4 Testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne
| K2 |
Po wykryciu i naprawieniu defektu, powinien zostać wykonany retest, żeby potwierdzić usunięcie usterki. Takie testy nazywane są testami potwierdzjącymi. Debagowanie (lokalizacja oraz poprawianie usterek) jest czynnością programistyczną, a nie testową.
Testowanie regresywne, to powtórzenie testów na już przetestowanym programie wykonywane po modyfikacjach żeby wykryć nowe usterki lub usterki odsłonięte na skutek wykonanych zmian. Usterki te mogą występować w testowanym oprogramowaniu, jak również w innych powiązanych lub niepowiązanych modułach. Testy regresywne wykonuje się po zmianach w oprogramowaniu lub w jego środowisku. Zakres testów regresywnych wynika z ryzyka nieznalezienia usterek w oprogramowaniu, które poprzednio działało poprawnie.
Testy, które mają być stosowane w testowaniu potwierdzającym i regresywnym muszą być powtarzalne.
Testy regresywne można wykonywać na wszystkich poziomach testów i dla wszystkich typów testów: funkcjonalnych, niefunkcjonalnych i strukturalnych. Zestawy testów regresywnych są wykonywane wiele razy i są stosunkowo niezmienne, wobec czego są dobrymi kandydatami do automatyzacji.
2.4 Testowanie pielęgnacyjne
| K2 15min |
| Pojęcia |
|---|
| analiza wpływu, testowanie pielęgnacyjne |
Wdrożony system często musi działać przez lata lub dekady. W tym czasie system, jego dane konfiguracyjne i jego środowisko są często poprawianie, zmieniane i rozszerzane. Dla dobrego testowania pielęgnacyjnego krytyczne jest planowanie wydań z wyprzedzeniem. Konieczne jest rozróżnianie pomiędzy planowanymi wydaniami i szybkimi poprawkami[7]. Testowanie pielęgnacyjne wykonuje się na działającym systemie na skutek modyfikacji, migracji lub złomowania oprogramowania lub systemu.
Modyfikacjami mogą być planowane ulepszenia (np. według planowych wydań), poprawki lub naprawy awaryjne oraz zmiany środowiska, takie jak planowane podniesienia wersji systemu operacyjnego, bazy danych lub oprogramowania z półki albo łaty zabezpieczeń systemu operacyjnego.
Testy pielęgnacyjne migracji oprogramowania (np. z jednej platformy na inną) powinny, oprócz testów zmian w oprogramowaniu, uwzględniać również testy produkcyjne nowego środowiska. Testy migracji (testowanie konwersji) są również potrzebne, gdy dane z innej aplikacji są migrowane do utrzymywanego systemu.
Testy pielęgnacyjne związane z wycofywaniem oprogramowania mogą zawierać testy migracji lub archiwizacji danych, jeżeli wymagany jest długi okres ich przechowywania.
Testy pielęgnacyjne, oprócz przetestowania tego co zostało zmienione, zawierają testy regresywne, tych części systemu, które się nie zmieniły. Zakres testów pielęgnacyjnych zależy od ryzyka zmian, wielkości istniejącego systemu oraz zakresu zmian. W zależności od zmian, testowanie pielęgnacyjne może być wykonane na niektórych lub wszystkich poziomach testowania oraz dla wybranych lub wszystkich typów testów.
Analizą wpływu nazywamy określenie jaki wpływ na istniejący system mogą mieć zmiany. Stosuje się ją, aby ustalić zakres testów regresywnych. Analiza wpływu może zostać użyta do określenia zestawu testów regresyjnych.
Testowanie pielęgnacyjne może być trudne do wykonania, jeżeli specyfikacja oprogramowania jest przestarzała lub gdy jej brak, lub gdy nie są dostępni testerzy posiadający wiedzę dziedzinową.
Literatura
| 2.1.3 | CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207 |
| 2.2 | Hetzel, 1998 |
| 2.2.4 | Copeland, 2004, Myers, 1979 |
| 2.3.1 | Beizer, 1990, Black, 2001, Copeland, 2004 |
| 2.3.2 | Black, 2001, ISO 9126 |
| 2.3.3 | Beizer, 1990, Copeland, 2004, Hetzel, 1998 |
| 2.3.4 | Hetzel, 1998, IEEE 829 |
| 2.4 | Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829 |
