Inżynieria programowania:

Jest to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji.

Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany ponieważ jest to najskuteczniejszy sposób tworzenia programowania wysokiej jakości.

Gospodarki wszystkich rozwiniętych krajów zależą od oprogramowania

Coraz więcej i więcej systemów wymaga niezawodnego oprogramowania

Inżynieria oprogramowania zajmuje się teorią, metodami i narzędziami związanymi z wytwarzaniem programowania

Obecnie wytwarzanie oprogramowania jest poważną gałęzią gospodarki narodowej rozwiniętego kraju.

Koszty oprogramowania

Koszty oprogramowania są często do minującym składnikiem kosztów całego systemu. Zdarza się, że koszt programowania znacznie przekracza samą wartość sprzętu komputerowego np. komputera osobistego.

Koszt utrzymania i konserwacji oprogramowania jest większy niż koszt jego wytworzenia. Wieloletnia konserwacja oprogramowania może kosztować wielokrotnie więcej niż jego zakup.

Inżynieria oprogramowania zajmuje się efektywnymi metodami wytwarzania i implementowania oprogramowania.

Proces tworzenia oprogramowania

-Zbiór czynności i związanych z nimi wyników, które zmierzają do opracowania produktu programowego.

-Zasadnicze czynności wspólne dla wszystkich procesów

a. Specyfikacja oprogramowania

b. Tworzenie oprogramowania

c. Zatwierdzenie oprogramowania

d. Ewolucja oprogramowania

Najbardziej popularne modele cyklu życia oprogramowania

1. Model kaskadowy

2. Model ewolucyjny

3. Model przyrostowy

4. Model spiralny

Lekceważenie metodyki Inżynierii oprogramowania

Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program to jest ‘drobiazg’. Często po awarii pojawia się komunikat typu ID 02. ID to skrót od Idiotyczny drobiazg, a następująca po nim liczba

wskazuje, przez ile miesięcy produkt informatyczny powinien być testowany.”

- Guy Kawasaki, ‘The Macintosh Way’

Przykłady awaryjności systemów:

Therac-25 AECL (Atomic Energy Canada Limited) Naświetlanie rentgenowskie – leczenie raka

1983-87

Zatoka Perska – 1988 r.

Dhahran – 1991 r.

Gujana Francuska - 1996

Mars Climate Orbiter

Mars Polar Lander

Blackout – 2003 r.

Airbus A380 – 2005 r.

BNP PARIBAS – 2009 r.

Ile kosztuje błąd ? niekiedy ludzkie życie

Czym są testy oprogramowania?

Testowanie oprogramowania jest to proces związany z wytwarzaniem

oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Testowanie ma dwa główne cele:

1. weryfikację oprogramowania

2. walidację oprogramowania

Weryfikacja oprogramowania ma na celu sprawdzenie, czy wytwarzane oprogramowanie jest zgodne ze specyfikacją.

Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika.

55% specyfikacja tracimy na wstępie czyli do czego program ma służyć, wymagania klienta, 25% błędy projektantów, 15% ktoś nie sprawdził kodu z innymi modułami, 5% błędy np. na obszarze dokumentacji API.

Po co testować?

1. testowania umożliwia wykrycie błędów we wczesnych stadiach rozwoju oprogramowania, co pozwala zmniejszyć koszty usuwania tego błędu.

2. Warto przeprowadzać testy na kaŜdym etapie tworzenia oprogramowania.

3. Testować należy jak najwcześniej, ponieważ podstawowymi źródłami bledów są specyfikacja i projekt.

4. Im później wykryty zostanie błąd tym większy jest koszt jego usunięcia.

Standardy testów

Podstawowym standardem dla testowania oprogramowania jest IEEE 829 – 1998 (829 Standard for Software Test Documentation). Jest to standard określający formę zbioru 8 dokumentów potrzebnych w każdej z faz testowania oprogramowania. W efekcie każdej z tych faz tworzony jest 1 dokument wynikowy. Standard ten określa dokładnie format dokumentów, jednak nie wymaga aby wszystkie były wykonane. Nie zawiera także informacji o tym co dokładnie mają zawierać.

Elementy składowe:

Test Plan, Test Design Specification, Test Case, Specification, Test Procedure Specification, Test Item, Transmittal Report, Test Log, Test Incident Report, Test Summary Report

Do innych standardów związanych z testowaniem oprogramowania należą: IEEE 1008, IEEE 1012, BS 7925-1, BS 7925-2.

Rodzaje testów oprogramowania

Testowanie oprogramowania dzieli się na dwa główne nurty, które zależą od przyjętego punktu widzenia testera:

1. Pierwszy sposób to testy testy funkcjonalne. Polegają one na tym, że wcielamy się w rolę użytkownika, traktując oprogramowanie jak „czarną skrzynkę”, która wykonuje określone zadania. Nie wnikamy w ogóle w techniczne

szczegóły działania programu. Testy te często są nazywane testami czarnej skrzynki (black box testing).

1. Drugi sposób postępowania to testy strukturalne. Tym razem tester ma dostęp do kodu źródłowego oprogramowania, może obserwować jak zachowują się różne części aplikacji, jakie moduły i biblioteki są wykorzystywane w trakcie testu. Te testy czasami są nazywane testami białej skrzynki (white box testing).

Podział testów oprogramowania

Testy możemy także podzielić ze względu na:

1. Sposób przeprowadzania

2. Zakres aplikacji jaki obejmują testy

3. Przeznaczenie

4. Testy wydajnościowe i obciążeniowe

Podział ze względu na sposób przeprowadzania testów

Oprócz przedstawionej wcześniej klasyfikacji, testy oprogramowania mogą być wykonywane manualnie, bądź automatycznie. Testy mogą być wykonywane ręcznie przez testera, który przechodzi przez interfejs użytkownika zgodnie z określoną sekwencją kroków lub automatyczne, których wykonanie nie wymaga udziału testera.

Zazwyczaj zautomatyzowane jest przeprowadzanie testów jednostkowych. Zrobienie tego jest dość proste, gdyż istnieją takie narzędzia jak Jakarta Ant, które mają wbudowaną funkcjonalność uruchamiania testów jednostkowych.

Znacznie bardziej skomplikowaną sprawą jest automatyzacja testów w schemacie czarnej skrzynki. Potrzebne do tego jest specjalistyczne oprogramowanie, które pozwala uruchamiać uprzednio napisane lub nagrane przez testera skrypty.

Podział ze względu na zakres aplikacji jaki obejmują testy

1. Testy jednostkowe testują oprogramowanie na najbardziej podstawowym poziomie podstawowym – na poziomie działania pojedynczych funkcji (metod).

b.Testy integracyjne pozwalają sprawdzić jak współpracują ze sobą różne komponenty oprogramowania, obecnie rzadko mamy do czynienia z monolitycznymi aplikacjami, raczej są one tworzone modułowo, więc trzeba sprawdzić czy wszystko razem działa poprawnie, nie ma niezgodności interfejsów itp.

c. Testy systemowe dotyczą działania aplikacji jako całości, zazwyczaj na tym poziomie testujemy różnego rodzaju wymagania niefunkcjonalne: szybkość działania, bezpieczeństwo, niezawodność, dobrą współpracę z innymi aplikacjami i sprzętem.

Podział ze względu na przeznaczenie

1. Testy akceptacyjne – testy wykonywane w celu sprawdzenia na ile oprogramowanie działa zgodnie z wymaganiami klienta

2. Testy funkcjonalne – testy sprawdzające działanie oprogramowania zgodnie ze specyfikacją, oczywiście testy akceptacyjne są siłą rzeczy rodzajem testów funkcjonalnych.

Aczkolwiek zdarza się, że klient wymaga do akceptacji produktu także wyników testów jednostkowych. Dlatego też odróżniamy kategorię testów funkcjonalnych i akceptacyjnych.

Podział ze względu na przeznaczenie

Testy regresyjne – jest to bardzo ważny rodzaj testów, pełniących zasadniczą rolę jeśli traktujemy poważnie kwestię jakości oprogramowania. Celem testów regresyjnych jest sprawdzenie, czy dodając nową funkcjonalność, poprawiając błędy nie naruszyliśmy niespodziewanie innej funkcjonalności oprogramowania. Testy regresyjne powinny być wykonywanie zarówno na poziomie kodu aplikacji (jeśli to możliwe) – zazwyczaj są to testy jednostkowe – jak i na wyższym poziomie, działania całej aplikacji. Aplikacja jest testowana w ten sposób, że przechodzimy przez wybrane ścieżki

działania oprogramowania tak, jak by to robił jego użytkownik.

Testy wydajnościowe i obciążeniowe

1. Testy instalacyjne/testy konfiguracji – służą do tego, żeby sprawdzić, jak oprogramowanie zachowuje się na różnych platformach sprzętowych, systemach operacyjnych, różnych

wersjach tych systemów, przy różnym zestawie

oprogramowania, jakie może mieć odbiorca.

1. Testy wersji alfa i beta – testy te służą głównie zdobyciu informacji zwrotnej od użytkowników – wybranej grupie przekazujemy wstępne wersje produktu, następnie zbieramy ich

opinie i komentarze dotyczące działania produktu.

Testy wydajnościowe i obciążeniowe

1. Testy używalności – tzw. usability tests, służą temu by sprawdzić jak szybko potencjalni użytkownicy mogą opanować działanie aplikacji, na ile użyteczna i jasna jest dokumentacja, itp. B.

2. Testy post -awaryjne – testy służące sprawdzeniu, czy aplikacja zachowuje się poprawnie po wystąpieniu sytuacji awaryjnej. W pieniu sytuacji awaryjnej. W pewnych przypadkach jest to bardzo ważny rodzaj testów, np. producent bazy danych powinien sprawdzić na ile awaria wpłynie na integralność przechowywanych danych.

Oczekiwania

Łatwe uruchamianie pewnego zakresu testów

1. Porządek w testach

2. Raporty dotyczące wyników testu

Rozwiązanie: Framework

Testowanie to jeden z najbardziej istotnych i odpowiedzialnych etapów rozwoju oprogramowania. Tradycyjne podejście do testowania oprogramowania zakłada, iż aplikację testujemy empirycznie: uruchamiamy ją, wprowadzamy pewne dane wejściowe i oceniamy, czy otrzymane wyniki są prawidłowe. Proces usuwania błędów przy takim podejściu jest zazwyczaj bardzo żmudny, gdyż sporo czasu zajmuje samo zlokalizowanie przyczyny ich występowania. Często poprawienie jednego błędu powoduje wprowadzenie kilku innych. Okazuje się również, iż testowanie empiryczne jest powtarzalne i w efekcie sporo niezauważonych błędów może przedostać się do końcowego produktu. Dlatego też tak istotne staje się posiadanie możliwości zastosowania testów zautomatyzowanych. Testy zautomatyzowane dają nam pełną powtarzalność – zawsze wykonują się w ten sam sposób i w tym samym środowisku. Piszemy je w tym samym języku programowania co kod testowanej aplikacji. W każdej chwili możemy uruchomić dowolny podzbiór wszystkich testów i upewnić się, że dany fragment kodu działa zgodnie z naszymi oczekiwaniami. Testy wykonują się bez żadnej ingerencji z naszej strony, same też interpretują dane wyjściowe. Dobry zestaw testów daje nam komfort szybkiego wprowadzania zmian – otrzymujemy natychmiastową informację, czy wprowadzona przed chwilą modyfikacja spowodowała pojawienie się błędów w innych miejscach i w razie potrzeby możemy szybko je poprawić.

• assertEquals(a, b) – sprawdza, czy parametr a jest równy b (a i b mogą być tutaj typami prostymi oraz klasami, ale jeśli są typem dynamicznym, to muszą implementować metodę equals)

• assertFalse(a) – sprawdza, czy wyrażenie logiczne a zwraca wartość false

• assertNotNull(a) – sprawdza, czy a jest różne od null, przy czym a jest referencją do obiektu

• assertNotSame(a, b) – sprawdza, czy parametry a i b nie wskazują na ten sam obiekt

• assertNull(a) – sprawdza, czy referencja a ma wartość null

• assertSame(a, b) – sprawdza, czy parametry a i b wskazują na ten sam obiekt

• assertTrue(a) – sprawdza, czy wyrażenie logiczne a zwraca wartość true

info z wykładu np.RC 1.0 wersja oprogramowania niedopracowana

RTM – wersja dopracowana