OOAD - Testowanie i zapewnienie jakości

Po napisaniu kodu programu należy go przetestować, aby wykryć, a następnie obsłużyć wszystkie błędy w nim zawarte. Do celów testowych wykorzystywanych jest kilka schematów.

Innym ważnym aspektem jest zgodność celu programu, który sprawdza, czy program służy celowi, do którego jest przeznaczony. Sprawność określa jakość oprogramowania.

Testowanie systemów obiektowych

Testowanie to ciągła czynność podczas tworzenia oprogramowania. W systemach zorientowanych obiektowo testowanie obejmuje trzy poziomy, a mianowicie testowanie jednostkowe, testowanie podsystemów i testowanie systemu.

Testów jednostkowych

W testach jednostkowych testowane są poszczególne klasy. Widać, czy atrybuty klas są zaimplementowane zgodnie z projektem i czy metody i interfejsy są wolne od błędów. Za testowanie jednostkowe odpowiedzialny jest inżynier aplikacji, który wdraża strukturę.

Testowanie podsystemów

Obejmuje to testowanie określonego modułu lub podsystemu i jest obowiązkiem lidera podsystemu. Obejmuje testowanie powiązań w ramach podsystemu, a także interakcji podsystemu z otoczeniem. Testy podsystemu mogą służyć jako testy regresji dla każdej nowo wydanej wersji podsystemu.

Testowanie systemu

Testowanie systemu obejmuje testowanie systemu jako całości i jest obowiązkiem zespołu zapewnienia jakości. Zespół często używa testów systemowych jako testów regresyjnych podczas tworzenia nowych wersji.

Techniki testowania zorientowane obiektowo

Testowanie szarej skrzynki

Różne typy przypadków testowych, które można zaprojektować do testowania programów zorientowanych obiektowo, nazywane są przypadkami testowymi szarej skrzynki. Niektóre z ważnych typów testów szarych skrzynek to:

State model based testing - Obejmuje to pokrycie stanu, pokrycie zmiany stanu i pokrycie ścieżki przejścia między stanami.
Use case based testing - Każdy scenariusz w każdym przypadku użycia jest testowany.
Class diagram based testing - Każda klasa, klasa pochodna, asocjacje i agregacje są testowane.
Sequence diagram based testing - Testowane są metody zawarte w komunikatach na diagramach sekwencji.

Techniki testowania podsystemów

Dwa główne podejścia do testowania podsystemów to:

Thread based testing - Wszystkie klasy potrzebne do realizacji pojedynczego przypadku użycia w podsystemie są zintegrowane i przetestowane.
Use based testing- Testowane są interfejsy i usługi modułów na każdym poziomie hierarchii. Testowanie zaczyna się od pojedynczych klas do małych modułów składających się z klas, stopniowo do większych modułów, a na końcu do wszystkich głównych podsystemów.

Kategorie testowania systemów

Alpha testing - Jest to wykonywane przez zespół testowy w organizacji, która rozwija oprogramowanie.
Beta testing - Jest to realizowane przez wyselekcjonowaną grupę współpracujących klientów.
Acceptance testing - Dokonuje tego klient przed przyjęciem przedmiotu dostawy.

Certyfikat Jakości Oprogramowania

Jakość oprogramowania

Schulmeyer i McManus zdefiniowali jakość oprogramowania jako „przydatność całego oprogramowania do użycia”. Dobrej jakości oprogramowanie robi dokładnie to, co powinno i jest interpretowane pod kątem spełnienia specyfikacji wymagań stawianych przez użytkownika.

Zapewnienie jakości

Zapewnianie jakości oprogramowania to metodologia określająca zakres, w jakim oprogramowanie nadaje się do użytku. Czynności uwzględnione w celu określenia jakości oprogramowania to:

Auditing
Opracowanie standardów i wytycznych
Tworzenie raportów
Przegląd systemu jakości

Czynniki jakości

Correctness - Poprawność określa, czy wymagania oprogramowania są odpowiednio spełnione.
Usability - Użyteczność określa, czy oprogramowanie może być używane przez różne kategorie użytkowników (początkujących, nietechnicznych i ekspertów).
Portability - Przenośność określa, czy oprogramowanie może działać na różnych platformach z różnymi urządzeniami sprzętowymi.
Maintainability - Łatwość konserwacji określa łatwość, z jaką błędy mogą być korygowane, a moduły mogą być aktualizowane.
Reusability - Możliwość ponownego użycia określa, czy moduły i klasy można ponownie wykorzystać do tworzenia innych produktów oprogramowania.

Metryki zorientowane obiektowo

Metryki można ogólnie podzielić na trzy kategorie: metryki projektu, metryki produktu i metryki procesu.

Metryki projektu

Metryki projektu umożliwiają kierownikowi projektu oprogramowania ocenę stanu i wydajności trwającego projektu. Następujące metryki są odpowiednie dla projektów oprogramowania zorientowanego obiektowo -

Liczba skryptów scenariuszy
Liczba klas kluczowych
Liczba klas wsparcia
Liczba podsystemów

Metryki produktu

Metryki produktu mierzą cechy oprogramowania, które zostało opracowane. Metryki produktu odpowiednie dla systemów zorientowanych obiektowo to -

Methods per Class- Określa złożoność klasy. Jeżeli zakłada się, że wszystkie metody klasy są równie złożone, wówczas klasa z większą liczbą metod jest bardziej złożona, a zatem bardziej podatna na błędy.
Inheritance Structure- Systemy z kilkoma małymi sieciami dziedziczenia mają lepszą strukturę niż systemy z pojedynczą dużą siatką dziedziczenia. Z reguły drzewo dziedziczenia nie powinno mieć więcej niż 7 (± 2) poziomów, a drzewo powinno być zrównoważone.
Coupling and Cohesion - Moduły o niskim sprzężeniu i dużej kohezji są uważane za lepiej zaprojektowane, ponieważ pozwalają na większe możliwości ponownego użycia i konserwacji.
Response for a Class - Mierzy efektywność metod wywoływanych przez instancje klasy.

Metryki procesu

Metryki procesu pomagają mierzyć, jak przebiega proces. Są gromadzone we wszystkich projektach przez długi czas. Są używane jako wskaźniki długoterminowych ulepszeń procesów tworzenia oprogramowania. Niektóre metryki procesu to -

Liczba KLOC (kilogramy linii kodu)
Skuteczność usuwania wad
Średnia liczba błędów wykrytych podczas testowania
Liczba wad ukrytych na KLOC