1. TESTER.PL
Rynek rośnie! To widać. I nie chodzi tu o wzrost eksportu, czy PKB, ale o rynek
związany z testowaniem.
Od początku tego roku mamy „wysyp” konferencji i warsztatów związanych z
testowaniem. Nie bez przyczyny – jest na to popyt!
W lutym Stowarzyszenie wspólnie z IIR zorganizowało drugie z kolei warsztaty
„Certyfikowany Test Manager”. Software – Konferencje w tym roku zrealizowało
i zamierza zrealizować jeszcze kilka kursów związanych z testowaniem. W maju
mieliśmy zakończoną dużym sukcesem II Konferencję SJSI, za kilka dni odbędzie się
w Warszawie duża impreza –II Krajowa Konferencja Jakości Systemów
Informatycznych. W sierpniu odbędzie się w Krakowie Software Quality Assurance
Management – impreza, która w zeszłym roku przyciągnęła nie tylko znane „testerskie”
postacie z Polski, ale także kilka osobistości z zagranicy.
Wszystko wskazuje na to, że na przełomie września i października będziemy
mieli gotową „polską” wersję egzaminu International Software Testing Qualification
Board. Aktualnie trwają prace nad słownikiem oraz tłumaczeniem pytań.
To wszystko się dzieje, bo jest na to zapotrzebowanie, bo firmy zauważają
korzyści z inwestowania w jakość, w tym - w testy.
Podobne nastroje zauważyć można u przedstawicieli firm sprzedających
narzędzia, a także wśród konsultantów zajmujących się optymalizacją testów. Według
różnych szacunków roczny wzrost sprzedaży narzędzi sięgnąć może nawet 14%.
Polski rynek usług testowych szacuje się na 33-49 mln USD rocznie. To nie jest
mało, a kryje się tutaj jeszcze spory potencjał. Niektóre z zagranicznych firm przenoszą
swoje działy testowania właśnie do Polski – tak się dzieje np. w Krakowie. Poważne i
uznane polskie firmy same zaczynają inwestować w tworzenie kompleksowych
kompetencji związanych z testowaniem. Pod koniec ubiegłego roku tak postąpił Polsoft,
wyodrębniając w swojej strukturze profesjonalne Centrum Testowania.
Co to oznacza w konsekwencji dla nas testerów? Z pewnością powinniśmy
patrzeć w przyszłość z dużym optymizmem. Tester z dużym doświadczeniem, a
zwłaszcza inżynier testowy, czy analityk testowy nie powinni w najbliższej przyszłości
narzekać na brak zajęcia. Jedno jednak nie ulega wątpliwości – aby być konkurencyjnym
na rynku należy być dobrym w tym co się robi. I pewnie stąd popyt na konferencje i
szkolenia.
Z pozdrowieniami
Wojciech Jaszcz
Prezes SJSI
Strona 1 z 50
2. TESTER.PL
Od redaktora
Z pewnym drobnym poślizgiem – koniec czerwca - oddajemy Wam, drodzy
Czytelnicy, kolejny, czwarty numer kwartalnika TESTER.PL.
W tym numerze trzy pozycje:
1. Piotr Kałuski o dokumentowaniu wyników testów,
2. Joanna Nowakowska i Lucjan Stapp o zaletach stosowania metodologii Test
Driven Development i używanych narzędziach,
3. Mark Curphey o tworzeniu bezpiecznego oprogramowania.
Numer otwiera sprawozdanie Wojciecha Jaszcza z II Konferencji Stowarzyszenia
Jakości Systemów Informatycznych, która odbyła się w Serocku, w dniach 19-20 maja
2005. Jako uczestnik zarówno tej jak i I Konferencji SJSI, pozwolę sobie stwierdzić, że
była to impreza ze wszech miar udana, i – o ile jest to możliwe – chyba nawet lepsza niż
poprzednia.
Chciałbym także zwrócić uwagę na informację o konferencji (z warsztatami)
Certyfikowany Test Manager, które nasze Stowarzyszenie przeprowadza wspólnie z IIR.
Szkolenie odbędzie się w Warszawie, w pierwszej połowie września.
Równocześnie po raz kolejny chciałbym gorąco zachęcić wszystkich Czytelników
tego periodyku do aktywnej współpracy. Cały czas czekamy na Państwa uwagi, artykuły,
felietony – wszystko, co Was interesuje, co chcielibyście przeczytać, czego się
dowiedzieć. Jeżeli tylko będziemy mogli, postaramy się zrealizować Państwa postulaty.
Lato – okres mniej wzmożonej pracy zawodowej – to świetny moment do napisania do
nas o tym, co Was interesuje i czego chcielibyście dowiedzieć się od nas.
Strona 2 z 50
3. TESTER.PL
II Konferencja
Stowarzyszenia Jakości Systemów Informatycznych
W dniach 19 – 20 maja 2005 już po raz drugi odbyła się konferencja
Stowarzyszenia Jakości Systemów Informatycznych. W tym roku mieliśmy przyjemność
podejmować Państwa w Instytucie Rozwoju Biznesu w Serocku.
Dwudniowa impreza zgromadziła około 70 uczestników z różnych branż gospodarki.
Gościliśmy m.in. przedstawicieli sektora Telco, IT, bankowości i ubezpieczeń, sektora
publicznego, naukowców. Spotkanie otworzył krótkim powitaniem Wojciech Jaszcz,
prezes Stowarzyszenia.
Zasadnicza część konferencji rozpoczęła się bardzo interesującym panelem
„Jakość usług w organizacji”, który zainicjował i poprowadził p. Borys Stokalski, Prezes
Infovide. W gronie panelistów znaleźli się Grzegorz Kulisz (ComputerLand S.A.), Piotr
Wasikowski (Sollers Consulting Sp. z o.o.) i Bogdan Bereza-Jarociński ( bbjTest).
Wywiązała się burzliwa dyskusja o „jakości usług”, która w konsekwencji przeszła w
dysputy o SLA w organizacji. Dużym zainteresowaniem cieszyły się prezentacje
Bogdana Berezy – Jarocińskiego „Twórcze myślenie w testowaniu oprogramowania –
mit czy konieczność? Przegląd zagadnień”, oraz „Przegląd modeli oceny dojrzałości
procesu testowania”. Podobnie jak wspomniana wyżej prezentacja, kilka prelekcji
poświęcone było zagadnieniom z pogranicza zarządzania testami i zarządzania
projektami. Były to prezentacje „Szacowanie testów metodą TPA” (Wojciech Jaszcz,
Michał Mazur z ComputerLand S.A.) oraz „Organizacja i zarządzanie zespołem
testerów” (Paweł Brodziński, Comarch S.A.).
Lucjan Stapp i Joanna Nowakowska przedstawili w swoim wystąpieniu ciekawe
podejście do związania testów i developmentu w modelu TDD – Test Driven
Development. W naszych realiach to bardzo nowatorski pomysł i warto dłużej się nad
nim zastanowić. Kolejne, niezwykle ciekawe wykłady dotyczyły miar oprogramowania
(prelegent: dr Andrzej Kobyliński, Szkoła Główna Handlowa) oraz procesu testowania w
Strona 3 z 50
4. TESTER.PL
kontekście CMMI oraz wytycznych SEI (Maciej Bodych, Piotr Ślęzak, Premium
Technology sp. z o.o.).
Sporo miejsca zajęła również część „narzędziowa”, w której uzasadnionym
zainteresowaniem cieszyły się prezentacje firmy Mercury głównego sponsora naszej
konferencji. Były to w szczególności: „Quality Center with Business Process
Testing”(prelegent: Lubomir Stojek), oraz „Tuning and LoadTesting on J2EE
environment” (prelegent: Darek Malinowski). O opensourcowym narzędziu JMeter i
testach regresywnych z jego wykorzystaniem opowiedział Łukasz Żebrowski z Rodan
Systems S.A.
Nie zabrakło też wieczornego spotkania przy grillu. Ciekawe dyskusje przy piwie,
a czasami przy czymś mocniejszym, trwały prawie do godzin porannych
.
Wszystkim uczestnikom, prelegentom, a w szczególności sponsorom, bez których
zorganizowanie tej konferencji byłoby niemożliwe, chcielibyśmy bardzo podziękować.
Liczymy na Waszą obecność i wsparcie kolejnych inicjatyw Stowarzyszenia Jakości
Systemów Informatycznych! Do zobaczenia na następnej edycji Konferencji!!!
W imieniu organizatorów
Wojciech Jaszcz
Prezes Zarządu
Strona 4 z 50
6. TESTER.PL
Prelegenci:
Bereza-Jarociński Bogdan, bbjTest
Bodych Maciej, Premium Technology Sp. z o.o.
Brodziński Paweł, Comarch S.A.
Jaszcz Wojciech, ComputerLand S.A.
Kobyliński Andrzej, Szkoła Główna Handlowa
Kulisz Grzegorz, ComputerLand S.A.
Malinowski Dariusz, Merkury
Mazur Michał, ComputerLand S.A.
Nowakowska Joanna, Rodan Systems S.A.
Stapp Lucjan, Politechnika Warszawska
Stojek Lubomir, Mercury
Stokalski Borys, Infovide S.A.
Ślęzak Piotr, Premium Technology Sp. z o.o.
Wąsikowski Piotr, Sollers Consulting Sp. z o.o.
Żebrowski Łukasz, Rodan Systems S.A.
Podziękowania
Chciałbym
serdecznie
podziękować
wszystkim
osobom
zaangażowanym
w przygotowanie konferencji, a zwłaszcza:
Joannie Nowakowskiej, Wojciechowi Jaszczowi, Lucjanowi Stappowi, Liliannie
Wierzchoń, Janowi Sabakowi i Piotrowi Wąsikowskiemu, bez których zaangażowania,
poświęcenia swojego czasu, profesjonalnego podejścia, i niezwykłej umiejętności
radzenia sobie w sytuacjach kryzysowych, ta konferencja nie doszłaby do skutku.
Beacie Pogorzelskiej i Joannie Wiśniewskiej, oraz wszystkim życzliwym tu
niewymienionym za pomoc w organizacji konferencji.
Centrum Szkoleniowemu za pomoc w skutecznym rozwiązaniu problemów.
Strona 6 z 50
7. TESTER.PL
Kontakt:
Regina Koenig, (22) 528 66 37
Mercury
rkoenig@mercury.com
Beata Pogorzelska, (22) 810 10 50
ITBC Communication
Beata_Pogorzelska@itbc.pl
MERCURY DLA PLATFORMY MICROSOFT VISUAL STUDIO 2005
Mercury optymalizuje współpracę między zespołami programistów i kontrolerów jakości.
Warszawa, 15 czerwca 2005 r. - Firma Mercury Interactive Corporation
(NASDAQ: MERQ) poinformowała, że oferowane przez nią rozwiązania będą
obsługiwać platformę Microsoft Visual Studio 2005 Team System. Celem jest
zapewnienie jak najwyższej jakości aplikacji przez cały cykl ich istnienia - od
projektowania i prac programistycznych, po ich dostarczenie i zarządzanie.
Microsoft Visual Studio 2005 to elastyczna platforma, obejmująca narzędzia do
zarządzania całym cyklem życia aplikacji, ułatwiająca współpracę między
zespołami programistów w celu uproszczenia procesu dostarczania aplikacji w
architekturze usługowej SOA (Service Oriented Architecture).
Zintegrowane produkty do testowania aplikacji firmy Mercury oraz platformy
Microsoft Visual Studio 2005 umożliwiają klientom:
pełne wykorzystanie zasobów testowych - obejmujących testy modułowe, funkcjonalne i
obciążeniowe - w środowiskach programowania i kontroli jakości, dzięki integracji z
pakietami oprogramowania Mercury Quality Center™ i Mercury Performance Center™;
Strona 7 z 50
8. TESTER.PL
współpracę w zakresie diagnozowania i korygowania błędów w aplikacjach, wąskich
gardeł w zakresie wydajności oraz problemów ze skalowalnością przez cały cykl
istnienia aplikacji za pomocą narzędzia Mercury Diagnostics™;
dostarczenie pełnego obrazu procesu testowania aplikacji za pomocą narzędzia
Mercury Application Delivery Dashboard™.
„Współpraca z firmą Microsoft wypełnia lukę, dzielącą procesy tworzenia aplikacji i kontroli
jakości w taki sposób, aby zagwarantować klientom wysoką jakość aplikacji niestandardowych i
aplikacji w architekturze SOA, tworzonych w oparciu o platformę .NET Framework” – powiedział
Rajesh Radhakrishnan, wiceprezes działu produktów do dostarczania aplikacji w firmie Mercury.
„Mercury umożliwia klientom optymalizację jakości aplikacji na każdym etapie – od prac
programistycznych po eksploatację.”
Obecnie klienci, korzystający z rozwiązań Mercury Quality Center i Mercury Performance
Center mogą testować jakość i wydajność aplikacji oraz usług WWW tworzonych w oparciu
o platformę Microsoft .NET Framework. Ponadto, oferowany w ramach pakietu Mercury
Performance Center, program Mercury LoadRunner® pozwala symulować rzeczywiste
obciążenie aplikacji i usług WWW w celu dostosowania ich do potrzeb przedsiębiorstwa jeszcze
przed wdrożeniem. Użytkownicy mają do dyspozycji moduły dodatkowe, które umożliwiają
sprawdzanie
często
zmieniających
się
wymagań
funkcjonalnych
aplikacji
przed
ich
uruchomieniem. Klienci korporacyjni, tworzący aplikacje w oparciu o platformę firmy Microsoft,
korzystają także z oprogramowania Mercury Diagnostics, które pozwala zarządzać ich
dostępnością i wydajnością przez 24 godziny na dobę, 7 dni w tygodniu. Dzięki takiemu
rozwiązaniu problemy są wykrywane i lokalizowane, a ich przyczyny definiowane zanim będą
miały wpływ na jakość pracy klientów. Proces trwa przez cały cykl istnienia aplikacji.
Zgodnie z opublikowanym przez firmę Gartner raportem „2005 Magic
Quadrant for Application Quality Ecosystem”, Mercury jest liderem rynku kontroli
jakości aplikacji. Badania przeprowadzone przez IDC wskazują, że firma
kontroluje ponad 55 procent rynku, czyli dwukrotnie więcej niż najbliższy z
konkurentów. Szczegółowe informacje na temat produktów i usług firmy Mercury
w
zakresie
dostarczania
aplikacji
można
uzyskać
pod
adresem
http://www.mercury.com/us/business-technology-optimization/applicationdelivery/
Strona 8 z 50
9. TESTER.PL
INFORMACJE O FIRMIE MERCURY
Mercury Interactive Corporation (NASDAQ: MERQ), lider w zakresie optymalizacji technologii
biznesowych (BTO), pomaga klientom w optymalizacji wartości technologii informatycznych.
Założona w 1989 roku firma jest jednym z najszybciej rozwijających się producentów
oprogramowania dla przedsiębiorstw. Mercury oferuje oprogramowanie i usługi ułatwiające
zarządzanie priorytetami, pracownikami i pracą działów informatycznych; dostarcza aplikacje i
zarządza nimi oraz integruje i realizuje strategie informatyczne. Klienci na całym świecie
korzystają z produktów firmy Mercury w celu podwyższenia jakości i wydajności aplikacji oraz
zarządzania kosztami, ryzykiem i zgodnością systemów informatycznych. Więcej informacji o
firmie można znaleźć na stronie internetowej: www.mercury.com/pl
Strona 9 z 50
10. TESTER.PL
Dokumentowanie wyników testów
Piotr Kałuski
CGI
Piotr Kałuski jest absolwentem Wydziału Elektroniki i Technik
Informacyjnych Politechniki Warszawskiej, kierunek informatyka.
Od 1995 uczestniczył w wielu projektach informatycznych jako
programista, analityk, projektant i kierownik zespołu. Obecnie jest
pracownikiem firmy CGI i jako konsultant jest członkiem zespołu
System Test w firmie Polkomtel. Dziedzina jego zainteresowań to
sposoby usprawnienia procesu testowania i wykorzystanie narzędzi
Open Source w procesie wytwarzania i testowania
oprogramowania. Szczegóły można znaleźć pod adresem
www.piotrkaluski.com.
Strona 10 z 50
11. TESTER.PL
Dokumentowanie wyników testów
Piotr Kałuski
CGI
Streszczenie
W poniższym artykule będę się chciał podzielić swoimi doświadczeniami
dotyczącymi tworzenia dokumentacji wyników testów i korzystania z niej. Przedstawię
różne konteksty, w jakich ta dokumentacja jest użyta i co jest od niej wymagane w
zależności od kontekstu.
Uwaga: Należy tu wyraźnie odróżnić pojęcia „dokumentacja testów” od
„dokumentacji wyników testów”. Dokumentacja wyników testów opisuje rezultaty
testów, jest zapisem zachowania się aplikacji w trakcie testów. Dokumentacja testów
zawiera w sobie dokumentację wyników testów oraz inne dokumenty używane i
tworzone w trakcie testów, z planem testów na czele.
Po co tworzymy dokumentację wyników testów i kiedy z niej
korzystamy
Dokumentowanie wyników testów ma dwa podstawowe cele (uporządkowane
według ważności)
1. Odnotowanie faktu, że dany test został wykonany i że przeszedł lub nie
2. Zapisanie jak zachowywała się dana wersja oprogramowania
W zależności od kontekstu, w jakim pracuje dany wytwórca oprogramowania,
waga punktu 2 może się różnić. Za to w każdym wypadku punkt 1 jest najważniejszym
celem dokumentowania wyników testów. Musimy wiedzieć, co zostało przetestowane i z
jakim skutkiem. Jeżeli nie przechowujemy nawet tej podstawowej informacji oznacza to,
że nie mamy żadnej kontroli nad procesem testowania.
Warto sobie uświadomić, kiedy najczęściej korzystamy ze stworzonej wcześniej
dokumentacji wyników testów. Otóż robimy to wtedy, gdy:
1. W systemie został wykryty błąd (w testach bądź po wdrożeniu)
2. Chcemy dowiedzieć się jak działały poprzednie wersje systemu.
W sytuacji z punktu pierwszego, dokumentacja wyników testów staje się
materiałem dowodowym w śledztwie „dlaczego błąd nie został wykryty w trakcie
testów?”
W sytuacji z punktu drugiego, dokumentacja pełni rolę bazy wiedzy. Sięgamy do
niej, aby porównać działanie wersji oprogramowania bądź też dowiedzieć się jak system
działa.
Strona 11 z 50
12. TESTER.PL
Przeanalizuję obydwa zastosowania i postaram się zwrócić uwagę, jakie cechy
powinna posiadać dokumentacja wyników testów, aby w obydwu przypadkach była jak
najbardziej pomocna.
Wykryto błąd na produkcji
Załóżmy, że mamy do czynienia z systemem bankowym, załóżmy też, dla
uproszczenia, że w banku faza testów jest jednoetapowa. Nowe pakiety idą od
programistów do testerów a od testerów na produkcję.
Jak wiadomo w systemach bankowych nie ma żartów i błędy na produkcji mogą
bank kosztować wiele nerwów i pieniędzy. Przeanalizujmy, co się dzieje, jeżeli na
produkcji pojawia się poważny błąd.
Rozpoczyna się analiza skutków błędu oraz przyczyn, dla których błąd nie został
wykryty w trakcie testów. Zadaje się, więc, działowi testów kolejne pytania:
1. Czy dana funkcjonalności została w ogóle przetestowana?
Najgorsza odpowiedź, jakiej może udzielić tester na takie pytanie brzmi “nie
wiem”. Jeżeli odpowiedź brzmi “Nie” to oczywiście następnym pytaniem jest:
2. Dlaczego nie przetestowano danej funkcjonalności/scenariusza biznesowego?
Jest wiele sytuacji, w których świadoma rezygnacja z testowania danej
funkcjonalności jest uzasadniona. Może się na przykład okazać, że przeprowadzenie
danego scenariusza testowego nie jest możliwe w środowisku testowym, ze względu na
różnicę między środowiskiem testowym a produkcyjnym. Pojawienie się groźnego błędu
na produkcji może skłonić kierownictwo do zainwestowania w stworzenie testerom
warunków lepiej odwzorowujących te produkcyjne.
Jeżeli odpowiedź na pytanie 1 brzmi “Tak i w trakcie testów wystąpił ten sam
błąd i został on zaraportowany z numerem xxxx” to śledztwo przenosi się do działu
programistów i konfiguracji.
Jeżeli odpowiedź na pytanie 1 brzmi “Tak i wszystko działało jak należy”
zaczyna się analiza czy rzeczywiście w trakcie testów działało jak należy. Szuka się więc
odpowiedzi na pytanie:
3. Czy tester prawidłowo zinterpretował wyniki testów?
Jeżeli dokumentacja zawiera tylko informację “test przeszedł/nie przeszedł” to
niewiele pomoże przy szukaniu odpowiedzi na ostatnie pytanie. W takiej sytuacji będzie
trzeba uwierzyć testerowi na słowo bądź spróbować ponownie przeprowadzić test w
środowisku testowym (o ile takie jeszcze istnieje dla danej wersji oprogramowania).
Dlatego też na tym etapie, jest pomocne, jeżeli dokumentacja zawiera bardziej
szczegółowe informacje o przebiegu testów. Można je przejrzeć ponownie i sprawdzić
czy system rzeczywiście działał w środowisku testowym, czy też tester przegapił błąd.
Oczywiście im dokładniejsze informacje tym analiza jest łatwiejsza i bardziej owocna.
Strona 12 z 50
13. TESTER.PL
Wyniki tej analizy pozwalają się zastanowić jak można ulepszyć proces wytwarzania
oprogramowania, aby zmniejszyć szansę wystąpienia sytuacji, w których system działa w
środowisku testowym a nie działa na produkcji. Albo jak pomóc testerom, aby nie
przegapiali błędów w trakcie testów.
Podsumowanie
Przy analizie błędów występujących na produkcji, dokumentacja wyników testów
jest materiałem dowodowym. Najważniejszą informacją jest czy funkcjonalność była
testowana czy nie. Im więcej informacji dodatkowych, tym większa szansa wyciągnięcia
rzeczowych wniosków na przyszłość.
Korzystanie z dokumentacji wyników testów w trakcie testów
Zapisywanie informacji o tym, co zostało przetestowane a co nie, nie tylko
pomaga testerowi wybronić się w sytuacji, kiedy błąd został wykryty na produkcji.
Pozwala mu też samemu kontrolować postęp prac. Jeżeli każda kolejna wersja
oprogramowania wymaga od jednej osoby wykonania 100 scenariuszy testowych, to
zapisywanie wyników staje się koniecznością.
Po drugie, dokumentacja wyników testów jest cennym źródłem informacji o tym
jak zachowuje się/powinien się zachowywać testowany system. Jeżeli mamy do
czynienia z komercyjnym produktem renomowanej firmy (np. serwerem bazy danych,
edytorem tekstu), to jest do niego dołączona dokumentacja, gdzie wszystko jest w miarę
przystępnym językiem wytłumaczone i zilustrowane przykładami.
Tester bardzo często ma do czynienia z oprogramowaniem tworzonym na
potrzeby firmy, dla której pracuje. Często jedyną tworzoną dokumentacją jest
specyfikacja wymagań oraz projekt i specyfikacja techniczna (detailed design).
Jakkolwiek często są to dokumenty rzetelne i wyczerpujące, nie są one łatwą lekturą dla
początkujących. Po drugie, po kilku latach trwania projektu, poszczególne dokumenty
skupiają się na wąskim aspekcie nowych zmian funkcjonalnych, zakładając, że ogólne
zasady działania systemu są znane. Czytelne, dobrze udokumentowane testy mogą być
niezastąpionym źródłem informacji o tym jak system naprawdę działa.
Dokumentowanie w praktyce
Jak już wyżej napisałem, najważniejszą informacją, jaką powinniśmy zawrzeć w
dokumentacji wyników testów jest informacja o tym, jakie testy wykonaliśmy i jakie
były ich rezultaty. W najprostszej wersji będzie to lista scenariuszy z informacją
przeszedł/nie przeszedł. Może to na przykład wyglądać tak:
1. Aktywacja klienta – Sukces
2. Dezaktywacja klienta – Sukces
3. Reaktywacja – Błąd
Strona 13 z 50
14. TESTER.PL
Jeżeli testujemy scenariusze z wieloma parametrami, ułatwieniem może być
zebranie wyników w tabeli.
Bardziej szczegółowe dokumentowanie rezultatów testów może mieć różne
formy, w zależności od tego jak bardzo chcemy być szczegółowi. Zacznijmy od końca.
Poniżej przedstawiam przykład dokumentacji, jaka mogłaby być stworzona przez
prymusa kursu “Testowania Oprogramowania”
Test Case 3.24
Aktywuj klienta z segmentu klientów indywidualnych
Opis:
Należy przetestować zachowanie się aplikacji w trakcie aktywacji nowego klienta
indywidualnego. Operacja ta polega na wybraniu odpowiedniej pozycji z menu, następnie
wypełnienia szeregu pól tekstowych i zatwierdzeniu danych przez naciśnięcie przycisku
“OK”.
Po wybraniu odpowiedniej pozycji z menu:
Pojawia się okienko dialogowe do wprowadzania danych:
Strona 14 z 50
15. TESTER.PL
Należy wprowadzić następujące dane:
• Imię i nazwisko
• Adres zamieszkania
• Telefon kontaktowy
• NIP
• PESEL
• Nazwisko panieńskie matki
• Imię matki
• Imię ojca
Do pól zostają wprowadzone następujące wartości:
Pole
Imię
Nazwisko
Ulica
Miasto
NIP
PESEL
Wartość
Jan
Kowalski
Jeziorna 5
01-230 Warszawa
111-222-33-44
01030478954
Strona 15 z 50
16. TESTER.PL
Nazwisko panieńskie matki
Imię matki
Imię ojca
Telefon
Nowak
Anna
Tomasz
22 44 55 667
Następnie kliknięty zostaje przycisk “OK”. Pojawia się komunikat, że konto zostało
utworzone:
Strona 16 z 50
17. TESTER.PL
Zatwierdzenie danych powoduje utworzenie następujących wierszy w bazie danych:
W tabeli CUSTOMERS powstaje wiersz z ID wygenerowanym przez serwer jako
unikalny identyfikator wiersza. Pole ACCOUNT_NUMBER ma wartość wyświetloną w
powyższym okienku dialogowym:
Select CUSTOMER_ID, ACCOUNT_NUMBER, FIRST_NAME, LAST_NAME,
CREATION_DATE from CUSTOMERS where ACCOUNT_NUMBER =
23454985
CUSTOMER_ID ACCOUNT_ FIRST_NAME
NUMBER
326473246
23454985
Jan
LAST_NAM
E
Kowalski
CREATION_
DATE
02-04-2005
W tabeli SERVICES pojawiają się nowe wiersze dla domyślnych serwisów tworzonych
w trakcie aktywacji. Dla kont indywidualnych takie serwisy to:
• Telefoniczny dostęp do konta – Klient może przeprowadzać operacje na koncie
dzwoniąc na odpowiedni numer telefonu
• Internetowy dostęp do konta – Klient może przeprowadzać operacje na koncie
korzystając z przeglądarki internetowej
• Karta Visa – Klient otrzymuje kartę kredytową
• SMSy z informacją o zmianie salda – klient dostaje SMSa przy każdej zmianie
salda jego konta.
Select CUSTOMER_ID, SERVICE_NUMBER, SERVICE_TYPE,
ACTIVATION_DATE from SERVICES where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
SERVICE_NUMB
ER
1
SERVICE_TYPE
TEL_ACC
Strona 17 z 50
ACTIVATION_D
ATE
02-04-2005
18. TESTER.PL
326473246
326473246
326473246
2
3
4
INT_ACC
VISA
SMS_NOTIF
02-04-2005
02-04-2005
02-04-2005
W tabeli PRICING_SCHEME_ASGN tworzone są cenniki usług dla klienta:
Select CUSTOMER_ID, SERVICE_NUMBER, PRICING_SCHEME_ID from
PRICING_SCHEME_ASGN where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
326473246
326473246
SERVICE_NUMBER
1
2
3
4
PRICING_SCHEME_ID
IND_TEL_ACC
IND_INT_ACC
GEN_VISA
GEN_SMS
W tabeli BILLING_EVENTS pojawiają się 2 wiersze – 1 wiersz opłaty aktywacyjnej a
drugi jako opłata za pierwszy miesiąc. Tabela BILLING_EVENTS zawiera informacje o
zdarzeniach, za które klient powinien zapłacić, a które nie są bezpośrednio związane z
serwisami.
Select CUSTOMER_ID, EVENT_TYPE, EVENT_DATE, AMOUNT from
BILLING_EVENTS where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
EVENT_TYPE
ACTIV
MON_FEE
EVENT_DATE
02-04-2005
02-04-2005
AMOUNT
20.00
15.00
W tabeli ADDITIONAL_ADDRESSES nie jest tworzony żaden nowy wiersz, ponieważ
nie został utworzony żaden adres dodatkowy.
System zachowuje się zgodnie z oczekiwaniami. To oznacza, że test przeszedł
pomyślnie.
SUKCES.
Piękne, prawda? Jest to przykład idealnie nadający się do książki na temat
testowania. Gdybym spotkał się kiedyś z projektem, w którym cała dokumentacja testów
tak by właśnie wyglądała to moje odczucia byłyby następujące:
1. Byłbym pełen szczerego podziwu, że ktoś tak się przyłożył
2. Potem pomyślałbym sobie “Ludzie pracujący przy tym projekcie chyba nie mają
co robić z czasem albo mają jakieś super narzędzie”
Strona 18 z 50
19. TESTER.PL
Takie ładne, potoczystym językiem spisane wyniki świetnie i szybko się czyta,
ale mało który projekt (a może żaden) ma czas i budżet, aby tego typu dokumenty
wykonywać dla wszystkich testów. Głównym zadaniem testerów jest testować. Przy za
wysoko postawionej poprzeczce większość czasu będą oni spędzali na tworzeniu
dokumentacji wyników. W efekcie, pakiety idące na produkcje - zamiast w 70% - będą
przetestowane w 20% (ale za to jak udokumentowane!). Jedyna sytuacja, w której taka
szczegółowość byłaby uzasadniona to taka, kiedy testujemy po raz pierwszy nową
funkcjonalność. Jeżeli jednak testujemy coś po raz n-ty (a scenariusz aktywacji do takich
należy), powinniśmy pomijać rzeczy oczywiste, które prawie zawsze są takie same.
Bardziej realny przykład wygląda tak:
Test Case 3.24
Aktywuj klienta z segmentu klientów indywidualnych
Strona 19 z 50
20. TESTER.PL
Stan bazy danych:
Select CUSTOMER_ID, ACCOUNT_NUMBER, FIRST_NAME, LAST_NAME,
CREATION_DATE from CUSTOMERS where ACCOUNT_NUMBER =
23454985
CUSTOMER_ID ACCOUNT_NUMBER
CREATION_DATE
326473246
23454985
Jan
FIRST_NAME LAST_NAME
Kowalski
02-04-2005
Select CUSTOMER_ID, SERVICE_NUMBER, SERVICE_TYPE,
ACTIVATION_DATE from SERVICES where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
326473246
326473246
SERVICE_NUMBER SERVICE_TYPE
ACTIVATION_DATE
1
TEL_ACC
2
INT_ACC
3
VISA
4
SMS_NOTIF
02-04-2005
02-04-2005
02-04-2005
02-04-2005
Select CUSTOMER_ID, SERVICE_NUMBER, PRICING_SCHEME_ID from
PRICING_SCHEME_ASGN where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
326473246
326473246
SERVICE_NUMBER
1
2
3
4
Strona 20 z 50
PRICING_SCHEME_ID
IND_TEL_ACC
IND_INT_ACC
GEN_VISA
GEN_SMS
21. TESTER.PL
Select CUSTOMER_ID, EVENT_TYPE, EVENT_DATE, AMOUNT from
BILLING_EVENTS where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
EVENT_TYPE
ACTIV
MON_FEE
EVENT_DATE
02-04-2005
02-04-2005
AMOUNT
20.00
15.00
SUKCES.
Zwróćmy uwagę, na czym polegały skróty. Po pierwsze, usunąłem sekcję na
temat wyboru pozycji z menu. Aktywacja jest funkcjonalnością tak podstawową, że
każdy wie, gdzie ją znaleźć. I zawsze to będzie w tym samym miejscu, więc nie warto o
tym pisać w dokumentacji każdego scenariusza (chyba, że struktura menu się zmieniła).
Po drugie usunąłem większość wyjaśnień. Nadają one dokumentowi
potoczystość, ale pisanie ich zajmuje zbyt dużo czasu. Poza tym, są one tak naprawdę
powieleniem informacji, która powinna się znajdować w scenariuszu testu (specyfikacji
zadania testowego). Czytelnikiem tego dokumentu najczęściej będzie ktoś, kto ma
przynajmniej ogólne pojęcie o systemie, więc domyśli się tego, co nie jest napisane
wprost. A jeżeli się nie domyśli, to sprawdzi sobie oczekiwane rezultaty w odpowiednim
scenariuszu z planu testów. (Muszę jednak uczciwie zauważyć, że to co napisałem
powyżej, też nie zawsze wytrzymuje konfrontacji z rzeczywistością. Niejednokrotnie
oczekiwania co do wyników testów, nie są zbyt szczegółowo określone przed
wykonaniem testu. Szczególnie dla scenariuszy, które powodują złożone zmiany w
systemie, oczekiwania są sformułowane pobieżnie i krystalizują i uszczegóławiają się
dopiero w trakcie wykonywania testu.)
Coś takiego można zrobić szybko. Jedyna wada to selektywność informacji. A co
będzie, jeżeli informacje zawarte w dokumencie okażą się nie wystarczające w trakcie
jakiejś analizy w przyszłości?
Można temu zaradzić. Spójrzmy na trzecią wersję:
Test Case 3.24
Aktywuj klienta z segmentu klientów indywidualnych
Strona 21 z 50
23. TESTER.PL
CUSTOMER_ID
ACCOUNT_NUMBER
LAST_NAME FIRST_NAME
NIP TAX REGION
EMPLOYER LAST_KNOWN_SALARY
PHONE
ADDRESS_STREET ADDRESS_CITY
PREFFERED_TIME_TO_CONTACT
PROFESSION
CREDIT_CARD_NUMBER FATHERS_NAME MOTHERS_NAME
MOTHERS_MAIDEN_NAME
MAIDEN_NAME
DATE_OF_BIRTH
CUSTOMER_SEGMENT VIP BAD_DEBTS IN_COLLECTION
LAST_NOTE DATE_OF_CREATION
NUMBER_OF_SERVICES
DISCOUNT_PLAN STATUS
EDUCATION RESPONSIBLE_PERSON
ELIGIBLE_FOR_PROMOTIONS REASON_OF_DEACTIVATION
DEACTIVATION_DATE COMMENTS
326473246 23454985
Kowalski
Jan
111-222-33-44VAT22
Warsaw
Kaluski&Kaluski
10000 22 44 55 667 Jeziorna 5
01-230
Warszawa
Afternoon
Programmer 2562-2389-2376-2321Tomasz
Anna
Nowak
14/07/1984 INDIVIDUAL N
N
N
02/04/2005 4
HJ-KDISC
AC
MSC Jan Tkaczuk Y
Moved to our company from competitors
Select * from SERVICES where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
326473246
326473246
SERVICE_NUMBER SERVICE_TYPE
ACTIVATION_DATE
STATUS
COMMENTS
ADDRESS_STREET ADDRESS_CITY
DEACTIVATION_REASON
DEACTIVATION_DATE
ON_HOLD
LAST_COMPLAINT LEVEL_OF_SATISFACTION
DISCOUNT
1
TEL_ACC
02/04/2005 AC
Added on initial activation
N
7
30
2
INT_ACC
02/04/2005 AC
Added on initial activation
N
7
0
3
VISA
02/04/2005 AC
Added on initial activation
N
7
30
4
SMS_NOTIF
02/04/2005 AC
Added on initial activation
N
7
0
Select * from PRICING_SCHEME_ASGN where CUSTOMER_ID =
326473246
CUSTOMER_ID
SERVICE_NUMBER
EFFECTIVE_DATE
Strona 23 z 50
PRICING_SCHEME_ID
DISCOUNTING_MODE
24. TESTER.PL
326473246
326473246
326473246
326473246
CHARGE_MODE
1
02/04/2005
2
02/04/2005
3
VISA
4
STD
IND_TEL_ACC
STD IND
IND_INT_ACC
STD IND
GEN_VISA 02/04/2005
VISA
GEN_SMS 02/04/2005
IND
Select * from BILLING_EVENTS where CUSTOMER_ID = 326473246
CUSTOMER_ID
326473246
326473246
EVENT_TYPE
AMOUNT
VAT_RATE
ACTIV
TBB
OTC
MON_FEE
TBB
RCM
SERVICE_NUMBER EVENT_DATE
STATUS
TAX_RATE
GL_CAT
RATING_MODE
02/04/2005 20
0
22
INDGL
0
02/04/2005 15
7
INDGL
SUKCES.
Tu danych jest więcej, zamieszczone są wartości wszystkich kolumn. Wygląd jest
mało czytelny, ale tak to wygląda w trakcie szybkich copy-paste z narzędzi typu OraTool
czy Rapid Sql. Poza tym sam fakt wielości danych powoduje, że dokument jest
nieczytelny.
Jednak, pomimo, iż dokumentu nie czyta się jednym tchem, ma on komplet
danych potrzebnych do analizy. W dokumencie są one nieczytelne, ale można je
skopiować do arkusza kalkulacyjnego i tam odpowiednio przetworzyć i zbadać.
Możemy też wspomóc proces dokumentowania takimi narzędziami jak LReport
(http://lreport.sourceforge.net), o którym pisałem w poprzednim numerze TESTERa.
Ale czasami i na to nie ma czasu. I tu już nie ma reguły. Musimy się kierować
zdrowym rozsądkiem oraz doświadczeniem i decydować, co jest najważniejsze.
Ostatecznie możemy zredukować dokumentację do zrzutu ekranu pokazującego, że
rezultaty są zgodne oczekiwaniami.
Osobnym tematem jest, co powinno być zapisem zachowania się aplikacji –
zawartość tablic, logi etc. Moim zdaniem odpowiedź brzmi “zależy od konkretnego
przypadku”. Jeżeli aplikacja operuje na obiektach bazodanowych, które w sposób dość
bezpośredni odzwierciedlają obiekty biznesowe, wtedy zawartość tablic jest pomocna.
Jeżeli aplikacja używa dość abstrakcyjnych pojęć na poziomie bazy danych, ale za to ma
bardzo bogaty i dopracowany mechanizm logowania, to może się okazać, że lepiej jest w
dokumencie zamieszczać logi. Albo i to, i to.
Strona 24 z 50
25. TESTER.PL
Podsumowanie
Najważniejszą informacją, jaką musimy zawrzeć w dokumentacji wyników
testów jest informacja o tym, jakie testy wykonaliśmy i jakie były ich rezultaty.
Przy dokumentowaniu bardziej szczegółowym powinniśmy się kierować
zdrowym rozsądkiem. Zawsze musimy pamiętać, nawet biorąc pod uwagę wszystkie
zalety starannej dokumentacji, że głównym zadaniem testera jest testować.
Warto zastanowić się nad użyciem narzędzi do wspomagania procesu
dokumentowania, szczególnie dla obszarów, które są testowane często i operują na tych
samych zestawach tabel.
Strona 25 z 50
27. TESTER.PL
Test Driven Development
kolejna miękka metodologia tworzenia modułów
czy
sposób na zwiększenie zainteresowania programistów
testami modułowymi
Joanna Nowakowska,
Pion Zarządzania Jakością
Rodan Systems S.A.
Lucjan Stapp,
Wydział MiNI,
Politechnika Warszawska
Joanna Nowakowska jest konsultantem ds. Zapewnienia Jakości w firmie Rodan
Systems S.A.. Jest absolwentką Szkoły Głównej Handlowej w Warszawie na kierunku
Metody Ilościowe i Systemy Informacyjne oraz ścieżce studiów
Zarządzanie Jakością. Od 2002 roku pracuje w Zespole Zapewnienia
Jakości w firmie Rodan Systems S.A., gdzie jest odpowiedzialna za
dokumentację systemu zarządzania jakością, organizację prac
zespołu testowego, przeprowadzanie szkoleń dla pracowników oraz
klientów firmy oraz modułowe, systemowe i akceptacyjne testy
aplikacji. W marcu 2005 uzyskała tytuły ISTQB Certified Tester,
Advanced Level, Functional Tester, ISTQB Certified Tester,
Advanced Level, Technical Tester oraz ISTQB Certified Tester,
Advanced Level, Test Manager nadawane przez International Software Testing
Qualifications Board (ISTQB) i International Software Quality Institute (iSQI), tym
samym stając się pierwszą osobą w Polsce posiadającą tytuł ISTQB Certified Tester, Full
Advanced Level. Współzałożyciel Stowarzyszenia Jakości Systemu Informatycznych,
członek Review Board w German Testing Board.
Lucjan Stapp jest wieloletnim pracownikiem naukowym
Politechniki Warszawskiej. Doktor nauk matematycznych, (bo
gdy robił doktorat nie było jeszcze doktoratów z informatyki).
Wielokrotnie pracował też jako kierownik zespołów
projektowych i zespołów zapewnienie jakości w dużych i małych
projektach.
Zwolennik lekkich metodyk, także w testowaniu.
Członek założyciel SJSI, przewodniczący Komisji Rewizyjnej
SJSI.
Strona 27 z 50
28. TESTER.PL
Test Driven Development
kolejna miękka metodologia tworzenia modułów
czy
sposób na zwiększenie zainteresowania programistów
testami modułowymi
Joanna Nowakowska,
Pion Zarządzania Jakością
Rodan Systems S.A.
Lucjan Stapp,
Wydział MiNI,
Politechnika Warszawska
Wstęp
Kiedy spojrzymy na klasyczny model procesu testowania – model V (rys.1), to
zauważamy, że pierwszym etapem testów dynamicznych są testy modułowe (ang.
unit/component tests).
specyfikacja
wymagań
Testy
akceptacyjne
specyfikacja
systemu
Testy
systemowe
specyfikacja
funkcjonalna
Testy
Integracyjne ”małe”
implementacja
Testy modułowe
Rysunek 1. Model V
Głównym celem przeprowadzenia testów modułowych jest dynamiczna,
niskopoziomowa weryfikacja testowanego systemu (dalej: System Under Tests, SUT), we
wczesnej fazie realizacji projektu. Po wyodrębnieniu składowych elementów SUT, takich
Strona 28 z 50
29. TESTER.PL
jak: moduły, klasy i ich metody można – i trzeba - dokonać weryfikacji sposobu działania
tych elementów niezależnie (w odosobnieniu) od reszty aplikacji.
Co dają nam testy modułowe:
•
umożliwiają jednoznaczne określenie miejsca wystąpienia błędu, a także
wskazanie nieefektywnych linijek kodu programu na poziomie
poszczególnych modułów,
• uniemożliwiają „przykrycie” błędów w jednym komponencie przez działanie
innego komponentu,
• umożliwiają uzyskanie istotnych informacji o jakości testów i pokryciu
testowym najniższym kosztem ze wszystkich typów testów, dzięki
bezpośredniemu działaniu na kodzie systemu.
Z przeprowadzonych badań wiadomo, że około 80 % wszystkich błędów
popełnianych przy bezpośrednim1 tworzeniu oprogramowania to błędy w kodzie
poszczególnych modułów. Tym samym ich wykrycie i usunięcie powinno zdecydowanie
wpłynąć na jakość tworzonego systemu. Z drugiej strony usunięcie błędów znalezionych
na poziomie testów modułowych kosztuje relatywnie mało – usunięcie tego samego
błędu znalezionego podczas testów modułowych może kosztować od kilku do kilkuset
razy mniej, niż znalezienie i usunięcie go już po przekazaniu oprogramowania do użytku
przez klienta [2].
Bardzo często okazuje się, że w organizacji pojawia się konflikt pomiędzy
zespołem wytwórczym a zespołem testowym o to, kto powinien odpowiadać za
przygotowanie i przeprowadzenie testów modułowych. Z jednej strony istnieją
argumenty za tym, by testy modułowe wykonywał programista, ponieważ:
•
•
•
najlepiej zna kod danego elementu systemu,
posiada „białą” znajomość SUT,
zmiany w kodzie mogą pociągnąć za sobą efekty uboczne, łatwe do
zauważenia przez twórcę kodu, dużo trudniej przez osobę zewnętrzną (a więc
nie znającą kodu).
Z drugiej strony programiści nie chcą testować swojego kodu, gdyż uważają, że:
• nie mają czasu na testy,
• testy są nudne i bezcelowe,
• programiści „nie robią” błędów,
• SUT i tak będzie testowany przez zespół testowy,
Co więcej programistom często brak kompetencji w zakresie testowania.
W niniejszym artykule chcemy przedstawić metodologię, która ułatwia
rozwiązanie konfliktu między zespołem wytwórczym a testowym, a następnie
zaprezentować przykładowy zestaw narzędzi umożliwiających wykonanie testów
modułowych tą metodą.
1
Najwięcej błędów powstaje zawsze z niejasności specyfikacji, autorom chodzi tu o błędy popełniane
bezpośrednio w tworzeniu SUT.
Strona 29 z 50
30. TESTER.PL
Test Driven Development
Test Driven Development (TDD) to podejście, którego nazwa pochodzi od tytułu
książki Kent Beck’a Test Driven Development by Example [1] z 2002 roku. Przedstawia
ona zmodyfikowaną ideę pochodzącą od eXtreme Programming (XP), zwaną w XP testfirst programming lub test-first development, a polega na idei:
NAJPIERW NAPISZ TESTY, A NASTĘPNIE TWÓRZ KOD!
Osiąga się w ten sposób dwa cele:
•
•
wymusza się przemyślenie problemu przed stworzeniem kodu (bardziej na
poziomie specyfikacji niż walidacji),
zwiększa się poprawność tworzonego kodu.
Schemat działania przy stosowaniu metody TDD można opisać w 4 prostych
krokach [2]:
Krok pierwszy:
1. Przemyśl problem
2. Przemyśl jak to testować
3. Napisz prosty test z dobrym interfejsem
Krok drugi:
1. Napisz tylko tyle kodu, by uruchomić test
2. Obserwuj, dlaczego test nie „przeszedł” – stąd pobierz wiedzę, co naprawdę
masz zaprogramować
Krok trzeci:
1. Napisz tylko tyle kodu, by test „przeszedł”
2. Uruchom ponownie test, sprawdź czy napisany moduł „przechodzi” test (a także
wszystkie poprzednio napisane testy)
Krok czwarty:
1. Usuń wszelkie powtórzenia, zwiększ czytelność kodu
2. Ponownie wykonaj testy
3. Jak wszystko OK, to zapisz wykonywany moduł
Strona 30 z 50
31. TESTER.PL
Rysunek 2. Schemat działania w TDD
To nie jest – niestety - takie proste jak wygląda na pierwszy rzut oka i wymaga
większej uwagi przy pracy, żeby dobrze przygotować testy. Tym niemniej nie jest to
bardzo uciążliwe, a przy pewnej praktyce robi się to sprawnie i dość szybko. Co więcej,
istnieje wiele shareware’owych narzędzi wspomagających tworzenie oprogramowania
metodą TDD.
Najbardziej znanym z nich jest JUnit2 - narzędzie z grupy XUnit3 przeznaczone
do testów modułowych (oraz jego rozszerzenie – JUnitPerf4 – przeznaczone do
modułowych testów wydajnościowych). Testy modułowe napisane z wykorzystaniem
biblioteki JUnit mogą zostać uzupełnione o statyczną analizę kodu (na zgodność kodu ze
standardami programowania) – tutaj wykonaną za pomocą narzędzia Hammurapi5, oraz
testy pokrycia, których przeprowadzenie umożliwi nam m.in. Emma 6. Wszystkie
2
http://www.junit.org
XUnit – rodzina narzędzi przeznaczonych do testów modułowych (w zależności od języka
programowania: Java – JUnit, Visual Basic – VBUnit (http://www.vbunit.org), C++ - CPPUnit
(http://cppunit.sourceforge.net), C# - NUnit (http://nunit.nunit.org).
4
http://www.clarkware.com/software/JUnitPerf.html
5
http://www.hammurapi.org
6
http://emma.sourceforge.net
3
Strona 31 z 50
32. TESTER.PL
wymienione tutaj narzędzia zostały opisane dokładniej w ostatnim paragrafie, gdzie
przedstawiono pełniejszy opis środowiska narzędziowego.
Chcąc określić, jakie są koszty i narzuty wynikające z zastosowania takich
narzędzi, w ramach zajęć stworzono 2 porównywalne grupy studentów tworzące tą samą
prostą aplikację (około 6 godzin pracy 3-osobowego zespołu):
• grupa testowa - metodologią TDD,
• grupa kontrolna - tradycyjnie, bez projektowania testów jednostkowych.
Oba zespoły pracowały w tym samym środowisku:
•
Eclipse SDK 3.0.2
• wbudowany JUnit
• wbudowany Hammurapi
• Emma
Na rysunku 3 przedstawiono czasy, jakie zespoły zużyły na wykonanie zadania.
Jak widać, w okresie początkowym zespół pracujący zgodnie z metodyką TDD
potrzebował zdecydowanie więcej (o ponad 1/3) czasu – głównie na nauczenie się
poprawnego posługiwania się wykorzystywanymi narzędziami (JUnit’em i
Hammurapi’m – Emma służyła głownie do osiągnięcia ustalonego z góry poziomu
pokrycia testami). Po nabraniu wprawy (zadanie 4 i 5) ta różnica czasu nie była już tak
znacząca, zespół pracujący w metodyce TDD potrzebował około 7 % czasu więcej.
Czas wykonania zadania
8
7
6
5
4
3
2
1
0
zadanie 1
zadanie 2
zadanie 3
grupa TDD
zadanie 4
zadanie 5
grupa kontrolna
Rysunek 3 Czas wykonania zadania
A jak metodologia TDD wpływa na ilość popełnionych błędów, więc także na
jakość produktu? Możemy to zobaczyć na rys. 4.
Strona 32 z 50
33. TESTER.PL
W okresie początkowym lepsze wyniki uzyskała grupa kontrolna; wynika to –
naszym zdaniem – z dodatkowego stresu, jakiemu poddana została grupa pracująca w
metodyce TDD. Widać jednak, że już od 3 zadania proporcje zmieniają się zdecydowanie
na rzecz pracujących zgodnie z TDD, uzyskali oni o 50% lepsze rezultaty.
Ilość popełnionych błędów
14
12
10
8
6
4
2
0
zadanie 1
zadanie 2
zadanie 3
grupa TDD
zadanie 4
zadanie 5
grupa kontrolna
Rysunek 4. Ilość błędów popełnionych w kodzie
Kolejny rysunek przedstawia jak poprawiła się jakość tworzonego kodu – jak
wynika z rys. 5 zdecydowanie bardziej zgodny ze standardami kod wyprodukował zespół
pracujący zgodnie z metodyką TDD.
Jakość kodu (wg Hammurapi)
18
16
14
12
10
8
6
4
2
0
zadanie 1
zadanie 2
zadanie 3
grupa TDD
zadanie 4
grupa kontrolna
Rysunek 5 Jakość kodu (wg Hammurapi)
Strona 33 z 50
zadanie 5
34. TESTER.PL
Podsumowując to proste doświadczenie, możemy stwierdzić, że stosowanie
metodyki TDD przy tworzeniu modułów to:
•
nieduży koszt dodatkowy – po nauczeniu się metodyki zwiększenie czasu na
wykonanie kodu jest nieduże (mniej niż 10 %),
• nastąpiło istotne zwiększenie poprawności kodu (50 % mniej błędów w
TDD).
Tworzony metodyką TDD kod jest podatny na refactoring, dzięki analizie
wyników z Hammurapi’ego następuje też odkrywanie wzorców poprawnego
programowania.
Pomimo wielu zalet metodyki TDD dostrzegamy również jej wady, tu
chcielibyśmy zwrócić uwagę na podstawowe:
•
przy stosowaniu metodyki TDD obowiązuje zasada wszystko albo nic – jeżeli
przerwiemy przed końcem (bo np. skończył się czas) – nie otrzymamy
gotowego modułu;
• nie zastępuje testów jednostkowych w 100% i gdy w kontrakcie jest wymóg
przeprowadzenia testów jednostkowych musimy je przeprowadzić;
• jest to miękka metodyka, co powoduje, że wiele organizacji odrzuci ją jako
nie nadającą się do stosowania.
O ile ostatni zarzut jest co najmniej dyskusyjny, to dwa pierwsze mogą
spowodować jej zdecydowane ograniczenie. Wydaje się nam jednak, że zyski (ponad 50
% poprawy jakości modułów przy mniej niż 10 % nakładzie czasu)) jest argumentem
zdecydowanie przemawiającym za jej stosowaniem.
Opis wykorzystanego środowiska narzędziowego
(dla aplikacji napisanych w języku Java)
Poniżej chcielibyśmy zaprezentować zintegrowane środowisko testowe dla
aplikacji napisanych w Java, działające w oparciu o narzędzie Eclipse i wbudowaną
bibliotekę Ant wspierającą uruchamianie testów. Wymienione tutaj narzędzia są
darmowe, także dla użytku komercyjnego. Konfiguracja wszystkich narzędzi znajduje się
w pliku build.xml, co umożliwia nam uruchomienie pełnych testów (z wykorzystaniem
wszystkich opisanych tutaj narzędzi) za pomocą jednego przycisku!
Biblioteka JUnit
JUnit to narzędzie z grupy XUnit przeznaczone do testów modułowych
oprogramowania tworzonego w Javie..
Podstawowymi elementami biblioteki są:
Strona 34 z 50
35. TESTER.PL
•
•
•
•
abstrakcyjna klasa TestCase, z wykorzystaniem której tworzony jest
przypadek testowy (klasa zawiera metody setUp() i tearDown() – co
umożliwia ładowanie danych wejściowych potrzebnych do wykonania
przypadku oraz czyszczenie po wykonaniu testu);
klasa Assert, zawierająca zestaw asercji porównujących wyniki oczekiwane z
rzeczywistymi;
klasy TestRunner (junit.textui.TestRunner i junit.swingui.TestRunner)
umożliwiające wykonanie przypadku testowego;
klasa TestSuite, umożliwiająca grupowanie większej ilości przypadków
testowych.
Standardowo wyniki wykonania testu wyrzucane są na konsoli, jednak
uruchamiając testy jako zadanie w Ant możemy wygenerować raport z wykonania
przypadków testowych w formacie XML/HTML. Przykładowy raport zaprezentowany
został na rysunku 6.
Rysunek 6. Raport z narzędzia JUnit
Z założenia narzędzie JUnit nie wspiera testów wydajnościowych. Chcąc
wykonać takie testy powinniśmy zaopatrzyć się w narzędzie JUnitPerf – bibliotekę
umożliwiającą uruchamianie testów JUnit z parametrami wydajnościowymi.
Hammurapi
Hammurapi to narzędzie do kontroli zgodności kodu ze standardami
programowania.
W skład aplikacji wchodzą między innymi:
•
Hammurapi – narzędzie do automatycznego przeglądu kodu Java. Ładuje
cały kod do repozytorium i generuje szczegółowy raport. Przeznaczony
głównie dla architektów.
Strona 35 z 50
36. TESTER.PL
•
Quickrapi – szybka wersja Hammurapi. Przeglądu dokonuje w pamięci.
Generuje uproszczone raporty. Przeznaczony głównie dla deweloperów
• Archiver
Hammurapi zawiera listę 120 inspektorów - reguł sprawdzających poprawność
języka. Można samemu dodawać nowe reguły, można też je dezaktywować, a także
grupować w zestawy (i pojedyncze zestawy używać np. odnośnie konkretnych typów
testów czy technologii). Pełna lista inspektorów (wraz z opisem i kodami) dostępna jest
pod adresem: http://www.hammurapi.org/content/inspectors.html
Na chwilę obecną Output Listener Hammurabiego umożliwia generowanie
raportów w formacie XML/HTML, umieszczonym tam nieprawidłowościom nadaje
priorytety, przekazując równocześnie informację o miarach (np. NCSS, class complexity
itd.).
Przykładowe okno raportu przedstawiono na rys. 7.
Rysunek 7. Przykładowe okno raportu z aplikacji Hammurapi
Emma
Przy tworzeniu testów modułowych bardzo istotną informacją może się okazać ta
o pokryciu testowym – takich informacji dostarczy nam kolejne narzędzie – Emma.
Emma to narzędzie napisane w Javie, niezależne od zewnętrznych bibliotek, które
może działać samodzielnie (z linii poleceń), bądź jako zadanie w Ant. Emma mierzy
pokrycie testami klas, metod, bloków (ang. basic blocks – nie mylić z pokryciem
instrukcji – statements) oraz linii kodu, w oparciu o pliki o rozszerzeniu *.class lub *.jar
(inaczej niż najbardziej popularny, komercyjny program Clover mierzący pokrycie w
Strona 36 z 50
37. TESTER.PL
oparciu o pliki *.java). Narzędzie udostępnia 2 sposoby instrumentalizacji: tryb on-the-fly
dla małych aplikacji oraz tryb offline przeznaczony dla bardziej złożonych systemów
(J2EE, klient-serwer, itd.). Generowane w formacie XML/HTML/TXT statystyki
agregowane są na kilku poziomach (np. pakietów, klas itd.), a pokryte linie kodu
zaznaczone kolorami. Dodatkowo Emma umożliwia filtrowanie danych trafiających do
raportu (np. pokrycie tylko konkretnych pakietów).
Należy zdawać sobie sprawę, że raporty z Emmy nie są w 100 % zgodne z
typową zalecaną techniką programistyczną (głównie chodzi o obsługę wyjątków), tym
niemniej jest to naprawdę bardzo użyteczne narzędzie. Przykład raportu z aplikacji
Emma przedstawiono na rys. 8
Rysunek 8. Raport z aplikacji Emma
Bibliografia
[1].
[2].
[3].
[4].
Beck, K, Test Driven Development by example, Addison-Wesley, 2002
Gilb T., Graham D., Software Inspection, Addison-Wesley 1993,
Newkirk, James W,. Vorontsov, Alexei A, Test Driven Development in
Microsoft .NET, Microsoft Professional, 2005
Hunt, Andy, Thomas, Dave, Pragmatic Unit Testing in C# with NUnit,
Pragmatic Programmers, 2005
Strona 37 z 50
38. TESTER.PL
Certyfikowany Test Manager
7- 9 września 2005 r., hotel Bristol, Warszawa
Program seminarium
Dzień pierwszy
Wprowadzenie
Ogólne zasady budowy systemu informatycznego
Przykładowe metodyki stosowane przy realizacji projektów informatycznych
Klasyczna metodyka "kaskadowa"
Metoda "spirali"
Lekkie metodyki na przykładzie XP
Zasady i praktyka budżetowania projektów informatycznych - Jak powstaje budżet projektu
Zarządzanie wymaganiami
Współpraca niezbędnym czynnikiem sukcesu
Zarządzanie ryzykiem
Testowanie w różnych metodykach wytwarzania oprogramowania
Związek testów z etapami realizacji projektu: modele V i W
Test Driven Development
Zakres, przygotowanie oraz metody prowadzenia podstawowych poziomów testów
Testy modułów
Testy integracyjne "małe"
Testy systemowe
Testy integracyjne "duże"
Testy akceptacyjne
Testy pielęgnacyjne
Zakres, przygotowanie oraz metody testów właściwości
Testy wydajnościowe
Testy architektury i koncepcji
Testy użyteczności
Testy bezpieczeństwa
Inne
Testy regresji i ich rola w procesie testowania
Przeglądy
Przegląd wybranych norm związanych z jakością i testowaniem
Strona 38 z 50
39. TESTER.PL
Dzień drugi
Zarządzanie procesem testowym
Planowanie prac
Szacowanie pracochłonności
Struktura dokumentacji testowej
Przeprowadzenie testów
Rejestrowanie wyników testów
Kontrola postępu prac
Zarządzanie zgłoszeniami problemów i zmian
•
•
•
Zarządzanie wersjami oprogramowania i danych
Definicja testware ("testaliów")
Zarządzanie wersjami
Metody opisu i przechowywania przypadków i scenariuszy testowych
Dzień trzeci
Zarządzanie procesem testowym - cd
Zarządzanie środowiskami o Struktura środowiska testowego o Testy w projekcie rozproszonym
Testowanie a zmiany wymagań
Jakość procesu testowego
Kryteria oceny jakości systemu informatycznego
Narzędzia
Egzamin
Kierowanie zespołem testów
Budowanie zespołu
Role w zespole
Cechy dobrego testera
Zadania szefa zespołu
Przywództwo
Zarządzanie konfliktem
Sztuka kompromisu
Podsumowanie
Wręczenie certyfikatów
Strona 39 z 50
40. TESTER.PL
Testowanie bezpieczeństwa oprogramowania:
Wróćmy do podstaw
Mark Curphey
Tłumaczenie: Tomasz Zemelka
Mark Curphey jest dyrektorem w Software Security Consulting at Foundstone (firma
jest własnością McAfee (www.foundstone.com/s3i)). Uzyskał stopień magistra ze
specjalnością Ochrona Informacji na Royal Holloway, University of London, gdzie
specjalizował się w zaawansowanej kryptografii
Adres mailowy: mark@curphey.com.
Strona 40 z 50
41. TESTER.PL
Testowanie bezpieczeństwa oprogramowania:
Wróćmy do podstaw
Mark Curphey
Tłumaczenie: Tomasz Zemelka7
Wersja angielska tego artykułu ukazała się w Software Magazine w listopadzie
2004 pt. „Software Security Testing: Let's Get Back to Basics“ i można ją znaleźć na
internetowej stronie magazynu: www.Softwaremag.com.
Lepsza droga testowania bezpieczeństwa oprogramowania
sieciowego oparta na zmodyfikowanym procesie powstawania
programów
„Oprogramowanie to paliwo wykorzystywane przez nowoczesny biznes, paliwo,
dzięki któremu rządy rządzą, a społeczeństwo staje się lepiej połączone. Programy
komputerowe pomogły stworzyć, udostępnić i ukazać informację we wcześniej nieznanej
formie. W skali globalnej zapierające dech w piersi tempo rozwoju oprogramowania
pomaga udźwignąć światową ekonomię. W życiu codziennym urządzenia bazujące na
oprogramowaniu pomagają leczyć choroby, są w stanie dać głos niemym, sprawić, że
upośledzeni ruchowo mają możliwość odzyskania sprawności. Mając na uwadze
wszystkie te względy można powiedzieć, że oprogramowanie jest nieodzownym
elementem naszego nowoczesnego świata”.
Rośnie zaawansowanie technologii, ale wygląda na to, że zabezpieczenia
oprogramowania nie dotrzymują kroku postępowi. Mimo nowych technicznych
standardów,
takich
jak
WS-Security2
czy
nowoczesnych
zamienników, jak choćby AES dla
starzejącego
się
już
algorytmu
kryptograficznego
DES,
problem
bezpieczeństwa staje się coraz większy
zamiast maleć. Na domiar złego, zgodnie
z badaniami prowadzonymi przez
National Institute of Standards (NIST),
brak bezpieczeństwa spowodowany jest
w 92% brakiem bezpieczeństwa aplikacji,
a nie sieci. (Rys.1)
Dlaczego tak wielu ludzi niewłaściwie odbiera kwestię bezpieczeństwa
oprogramowania i co należy zrobić zanim sprawy się pogorszą? Jak w każdej dobrej
7
Redakcja niniejszym dziękuje Tomaszowi Zemelce nie tylko za przetłumaczenie artykułu, ale także za
uzyskanie zgody autora i wydawcy na niniejszą publikację.
Strona 41 z 50
42. TESTER.PL
analizie, najpierw należy poszukać ‘korzenia’ (źródła) problemu, zanim zaproponujemy
nowe lepsze rozwiązania. W szczególności przedstawimy lepszą drogę testowania
bezpieczeństwa oprogramowania sieciowego zaproponowanego przez OWASP – The
Open Web Application Security Project (www.owasp.org)
Przez ostatnią dekadę, wprost z wczesnego środowiska hackerskiego, wyłonił się
ogromny przemysł zabezpieczeń oprogramowania. Wczesne, dominujące społeczeństwo
akademickie, mające dostęp do pochodnych Unixa i chcące poszerzyć granice nowej
technologii, tworzyło rozszerzenia i ‘hackowało’ kod źródłowy na własne potrzeby.
Powstająca sieć komputerowa bazująca na systemach telefonicznych była miejscem
sprawdzania tej nowej technologii w praktyce, robiący to entuzjaści zaczęli dzielić się
‘sztuczkami’, które ich zdaniem były po prostu ‘cool’. Te garażowe spotkania
i podziemna kultura spowodowała, że hakerzy zaczęli używać poradników typu ‘Captain
Crunch’ i ‘Condor’ oraz wytworzyła się subkultura wykorzystująca następstwa tego
dzielenia wiedzy. Dominujący trend przemysłu zajmującego się bezpieczeństwem
podążał za masową technologią przyjmując ścieżkę od sieci internetowych poprzez
główny nurt powstawania komercyjnych systemów operacyjnych stosując wiele sztuczek
właśnie z tamtego okresu.
Podczas gdy umiejętności administratora zarządzającego systemem relatywnie
dobrze wykorzystane są w bezpieczeństwie sieci i systemu operacyjnego, gdzie
funkcjonalność jest zdefiniowana z góry albo przynajmniej została ograniczona,
ewoluując do rozwiązywania nowych generacji problemów bezpieczeństwa,
potrzebujemy nowego podejścia i innego zestawu umiejętności.
Generalnie musimy zaakceptować fakt, iż jeśli istnieje problem bezpieczeństwa
oprogramowania, to rozwiązanie leży w stworzeniu programu zabezpieczającego.
Wiedza potrzebna do budowania takiego oprogramowania znacznie różni się od wiedzy
na temat bezpiecznego konfigurowania firewalla. Zabezpieczenie musi zostać
wbudowane w program tak, by nie mogło być później konfigurowane. Ułatwieniem może
być myślenie o rozwoju bezpieczeństwa oprogramowania jak o kombinacji ludzi,
procesów i technologii. Jeżeli są to czynniki ‘tworzące’ oprogramowanie, logiczne jest,
że czynniki te również muszą zostać przetestowane.
Dzisiaj, większość ludzi testuje tylko technologię albo samo oprogramowanie.
W rzeczywistości większość nie testuje oprogramowania dopóki nie zostało stworzone i
nie znajduje się w fazie życia tzn. kod nie został stworzony i zaimplementowany w
działającej aplikacji sieciowej. W zamian stosują techniki testów penetracyjnych po tym
jak aplikacja została umieszczona w internecie. Generalnie jest to bardzo nieefektywna i
kosztowna praktyka. Grady Booch, autor oprogramowania modelującego i współtwórca
Unified Modeling Language (UML), opisał to podejście jako leczenie objawów, a nie
przyczyny. Znakomicie opisuje to bezpieczeństwo oprogramowania. Przemysł
zabezpieczeń musi się przystosować i nauczyć srogiej lekcji jaką dostał od społeczeństwa
w minionej dekadzie. Tak jak inżynierowie oprogramowania muszą nauczyć się, że
tworzenie oprogramowania to nie to samo co budowanie wieżowców, tak przemysł
zabezpieczeń musi się przystosować, jeśli chce przetrwać.
Efektywne testowanie programu powinno składać się z następujących
składników:
Strona 42 z 50
43. TESTER.PL
Ludzi – aby zagwarantować wystarczające wykształcenie, świadomość i umiejętności
Proces – aby mieć pewność, że zespół posiada właściwą politykę i każdy wie jak się w
niej odnaleźć, wie również jakie są najefektywniejsze techniki i procesy
Technologia – by upewnić się, że proces został efektywnie zaimplementowany i
przekłada się na właściwe bezpieczeństwo w procesie tworzenia języków i struktur.
Chyba, że wykorzystywane jest podejście całościowe, gdyż testowanie wyłącznie
technicznej implementacji aplikacji nie odsłania sterujących czy operacyjnych braków w
zabezpieczeniach, które mogły się pojawić. Ludzie muszą testować w poszukiwaniu
przyczyny, a nie symptomów, a kiedy znajdą przyczynę, muszą przepisać lek zarówno
krótko jak i długoterminowy, by sobie z tym poradzić. Poprzez testowanie ludzkie i tym
bardziej procesowe jesteśmy w stanie zlokalizować zagadnienie, które pojawi się później
w fazie testów technologicznych i w ten sposób wyplenić błędy wcześniej oraz
zidentyfikować główną przyczynę ich powstania.
Ludzie zwykle testują tylko część technicznych problemów, które mogą wystąpić
w systemie. Wynikiem tego jest niekompletna i nieodpowiednia ocena wyrażająca
bezpieczeństwo.
Denis Verdon, Szef Korporacji Information Security Group At Fidelity National
Financial, zaprezentował znakomitą analogię dla tego niezrozumienia na konferencji
OWASP AppSec w Nowym Jorku:
„Gdyby samochody testowano tak jak aplikacje…testy bezpieczeństwa
przyjmowałyby tylko zderzenia frontalne. Samochody nie byłyby testowane na wypadek
bocznych zderzeń albo na wypadek zachowania stabilności w trakcie nagłych manewrów
w sytuacjach wyjątkowych, nietestowana byłaby również skuteczność hamulców czy
zabezpieczenia antywłamaniowe.”
Wiele organizacji zaczęło stosować skanery aplikacji sieciowych. Te skanery,
zachowujące się jak czarne skrzynki, usiłują ‘pełznąć’ po sieci w poszukiwaniu luk w
zabezpieczeniach jak automatyczny haker. Mogłyby mieć zastosowanie w testowaniu
oprogramowania, ale nie wierzymy, by automatyczna czarna skrzynka była albo
kiedykolwiek mogła być efektywna. Skaner sieciowy powinien być ostatnim etapem w
procesie testowania, nie pierwszym. Nie zmniejszamy jednak jego roli, raczej staramy się
pokazać, że należy zrozumieć jakie ma ograniczenia i że struktura testów powinna być
właściwie zaplanowana.
Przykład
Recenzowaliśmy stronę sieciową, gdzie projektanci stworzyli tylne drzwi dla
celów administracyjnych. Kiedy klikało się link albo wysyłało formularz ze strony, był
on przesyłany w postaci parametrów (przykładem zastosowania takiej funkcji może być
serwis www.weather.com, gdzie, podając jako parametr kod miejsca zamieszkania,
otrzymuje się prognozę pogody dla swojego regionu) W tej aplikacji developerzy tak
skonstruowali przesyłanie parametrów, że pozornie dowolny ciąg parametrów długości
40 znaków powodował automatyczne zalogowanie na stronie jako administrator. Jedyna
możliwość, aby skaner sieciowy wykrył tego rodzaju błąd, to moment kiedy skaner
Strona 43 z 50
44. TESTER.PL
użyłby dokładnego kodu z biliona możliwości, co jest niewykonalne. W tym przypadku
zajęłoby to setki lat.
Natomiast, nawet dla laika patrzącego w kod źródłowy, błąd ten był oczywisty.
If input from browser = „the special 40 characters” then log user in as administrator
Wystarczyłoby by jeden złośliwy użytkownik wysłał link do setek albo tysięcy
ludzi z publicznej listy mailingowej, aby wszyscy mieli całkowitą kontrolę nad stroną i
kontami klientów biznesowych.
Testowanie pokazało, że obecny zbiór skanerów do aplikacji sieciowych
wykrywa mniej niż 20% błędów w powszechnie używanych stronach internetowych. To
pozostawia 80% różnych dziur w kodzie programu, które mogą znaleźć i wykorzystać
potencjalni hakerzy.
Gary McGraw, autor „Building Secure Software”, ujął to w ten sposób:
„Jeżeli test penetracyjny nie powiedzie się, to masz świadomość tego, że problem
istnieje, jeżeli test penetracyjny zakończy się powodzeniem, to nie masz pojęcia czy błąd
istnieje”
OWASP przyciągnął wielu specjalistów zorientowanych prorozwojowo oraz
uzyskał wsparcie wielkich firm zajmujących się zabezpieczeniami w IT, takich jak
Fidelity. Powoli kształtuje dominujący trend postrzegania jak kierować bezpieczeństwem
oprogramowania.
Verdon z Fidelity National powiedział:
„Środowisko ludzi zajmujących się zabezpieczeniami w dalszym ciągu nie daje
rady wymaganiom jakie stawiają przed nimi ci, którzy zajmują się aplikacjami i
developmentem. Szczerze mówiąc wielu z nich nadal nie wie jakie pytania zadać. Z
pewnością architekci znają struktury J2EE i .Net’s security, ale nikt do tej pory nie dał
im wskazówek jak z nimi pracować. Członkowie OWASP uświadomili to sobie i zaczęli
zapełniać tę lukę. Pomagają tworzyć powszechny język, który potrzebny jest do
właściwego modelowania problemów zabezpieczeń i ich rozwiązywania.”
OWASP Testing Project
OWASP Testing Project jest to projekt składający się z dwóch części mający na
celu utorować drogę do stworzenia spójnego zbioru dokumentacji oraz oprogramowania
wspomagającego. Pierwsza część projektu ma za zadanie przedstawienie zorientowanej
zadaniowo struktury bezpieczeństwa, aby pomóc organizacjom przy tworzeniu ich
własnych procesów. Druga wspomaga strukturę szczegółowymi opisami technicznymi
tego, w jaki sposób zaimplementować procesy wysokiego poziomu, włączając
egzaminowanie kodu specyficznych problemów. Tak jak wszystkie projekty OWASP,
dokumentacje i oprogramowanie jest darmowe i dostępne dla wszystkich.
Na testową strukturę zorientowaną zadaniowo powinny składać się działania
umiejscowione w następujących etapach procesu tworzenia:
Strona 44 z 50
45. TESTER.PL
• Zanim rozpocznie się proces tworzenia
• W trakcie fazy definiowania i projektów
• W trakcie procesu tworzenia
• Podczas etapu wdrażania
Zanim zacznie się proces tworzenia, zgodnie ze strukturą powinno się
przetestować czy powstał odpowiedni proces cyklu życia programu i czy zawiera
niezbędne zabezpieczenia. Zaleca się przetestowanie czy zespół tworzący
oprogramowanie jest zaopatrzony we właściwe standardy i zna właściwy sposób
postępowania oraz czy twórcy stworzyli metryczne i wzorcowe kryteria. Ta koncepcja
nie powinna być niczym nowym dla zespołów, które stosują najlepsze techniki, takie jak
Rational Unified Software stworzony przez Rational Software (od 2003 przejęty przez
IBM).
Następnie, aby mieć pewność, że bezpieczeństwo jest integralną częścią
powstawania oprogramowania w jego cyklu życia, koniecznie należy sprawdzić czy
właściwa polityka, standardy i dokumentacja są na miejscu. Dokumentacja jest bardzo
ważna, ponieważ daje twórcom wytyczne i wprowadza politykę, według której mogą
pracować: ludzie tylko wtedy robią właściwe rzeczy, kiedy wiedzą jakie rzeczy są
właściwe. Jeśli aplikacja ma powstać w Javie, niezbędny staje się standard zabezpieczeń
dla Javy. Jeżeli aplikacja ma korzystać z kryptografii, dostępny musi być standard
kryptograficzny. Poprzez dokumentowanie powszechnych i najczęściej spotykanych
problemów zmniejszy się liczba decyzji, które należy podjąć w trakcie procesu
tworzenia, a ryzyko związane z bezpieczeństwem implementacji zostanie zmniejszone.
Testing Requirements is Essential
Testowanie zaczyna się na poważnie podczas fazy definiowania i projektowania.
Wymogi bezpieczeństwa określają jak aplikacja pracuje z punktu widzenia zabezpieczeń.
Niezbędne jest przetestowanie wymogów bezpieczeństwa. W tym przypadku w pierwszej
kolejności należy przetestować to, czy odpowiednie wymogi istnieją i czy nie zawierają
luk. Np. jeżeli bezpieczeństwo wymaga, aby użytkownik, który chce dostać się do
zasobów uprzednio zalogował się na stronie, należy sprawdzić czy to oznacza, że musi
być zarejestrowany w systemie i posiadać przypisaną rolę?
W trakcie szukania luk w wymaganiach rozważmy takie mechanizmy
bezpieczeństwa jak:
• User Management
• Authentication
• Authorization
• Session Management
• Transport Security
• Data Protection
• Data Validation
Aplikacje powinny mieć udokumentowany projekt i architekturę. Przez
udokumentowanie mamy na myśli modele, dokumenty tekstowe i inne podobne
Strona 45 z 50
46. TESTER.PL
elementy. Elementy te koniecznie muszą zostać przetestowane, należy zwrócić uwagę
czy wymuszają właściwy poziom bezpieczeństwa, zgodny z wymaganiami.
Identyfikacja wad zabezpieczeń w fazie projektu nie tylko jest najmniej
kosztownym etapem do lokalizacji błędów, ale również najefektywniejszym do
wprowadzania zmian. Na przykład jeżeli stwierdzimy, że projekt przewiduje wezwanie
do autoryzacji w kilku miejscach, może należałoby rozważyć komponent będący
centralną autoryzacją. Jeżeli aplikacja przewiduje kontrolę danych w kilku miejscach,
może powinno się stworzyć centralną strukturę walidacyjną (co byłoby wydajniejsze i
tańsze). Projektowe wzorce bezpieczeństwa stają się coraz popularniejsze i użyteczne na
tym etapie. Jeśli jakiś słaby punkt zostaje odkryty, powinien od razu trafić do architekta
systemu, by ten zastosował alternatywne rozwiązanie.
Bardzo użyteczne dla bezpieczeństwa są modele UML opisujące sposób pracy
aplikacji. W niektórych przypadkach mogą istnieć gotowe modele. Używając tych modeli
należy wraz z projektantami systemu określić dokładne działanie aplikacji. Jeżeli zostaną
odkryte jakieś słabe punkty, należy je przekazać do architektów systemu w celu
zastosowania alternatywnych rozwiązań. Istnieje specjalny dialekt UML dla modeli
bezpieczeństwa tzw. SecureUML.
‘Uzbrojeni’ w projekt i opinie architektów oraz model UML dokładnie opisujący
działanie systemu możemy rozpocząć wykonywanie prób modelu-zagrożeń. Model
zagrożeń stał się bardzo popularną techniką polegającą na szukaniu ‘dziur’, które mógłby
wykorzystać przeciwnik i sprawdzaniu czy zostały wprowadzone odpowiednie środki
zapobiegawcze. Tworzy się realistyczne scenariusze ‘ataku’. Analizując projekt i
architekturę pod kątem tych scenariuszy sprawdza się czy aplikacja jest odpowiednio
zabezpieczona. Jeżeli wystąpią jakieś zagrożenia, należy ponownie wrócić do
projektantów i architektów, aby ci odpowiednio zmodyfikowali projekt.
Teoretycznie, wdrażanie jest implementowaniem projektu. Jednakże w
rzeczywistości wiele decyzji dotyczących projektu podejmowanych jest właśnie na etapie
tworzenia kodu. Są to zwykle pomniejsze zmiany, które dotyczą zbyt szczegółowych
zagadnień by być opisanymi na etapie projektu czy analizy wymagań lub nie objęte
żadnymi standardami. Jeżeli projekt i architektura były niewystarczające, wówczas
developer będzie zmuszony do podejmowania wielu takich decyzji. Jeżeli
niewystarczająca była polityka lub standardy, konstruktor będzie miał jeszcze więcej
decyzji do podjęcia.
Zespół do spraw bezpieczeństwa powinien ‘przejść’ kod wraz z developerem, a w
niektórych przypadkach również z architektami systemu. Takie ‘przejście’ kodu jest
dokładnym przejrzeniem kodu, gdzie developerzy czy architekci mogą wyjaśnić logikę i
przebieg działania programu. Zespołowi daje to możliwość ogólnego zrozumienia kodu,
a developerom pozwala na wyjaśnienie, dlaczego pewne rzeczy zostały napisane w ten
sposób, a nie inny. Celem nie jest sprawdzenie kodu tylko zrozumienie, na wysokim
poziomie, w jaki sposób funkcjonuje aplikacja.
Znając kod i wiedząc jak zostały rozwiązane niektóre istotne zagadnienia, tester
może przetestować kod w poszukiwaniu luk w zabezpieczeniach.
Strona 46 z 50
47. TESTER.PL
Jeżeli zostaną sprawdzone wymagania, przeanalizowany projekt, powstaną
modele zagrożeniowe i zostaną przeprowadzone testy kodu, można by założyć, że
wszystkie usterki zostały wykryte. Jednakże ostatnim krokiem jest test wdrożonej
aplikacji mający na celu sprawdzenie czy nic nie zostało pominięte. Test penetracyjny
powinien sprawdzać sposób w jaki cała infrastruktura została wdrożona i zabezpieczona.
Podczas gdy aplikacja wydaje się być właściwie zabezpieczona, może okazać się, że jakiś
niewielki błąd dający się wykorzystać do złamania zabezpieczeń tkwi w konfiguracji
zarządzania w procesie instalacji. To właśnie jest miejsce, gdzie najbardziej efektywne
stają się czarnoskrzynkowe skanery szukające dziur w konfiguracji zarządzania.
Pamiętajmy, że koszty naprawy znalezionego na tym etapie błędu w zabezpieczeniach są
ogromne i mogą wymagać wielkich zmian w projekcie.
Dobry program testujący angażuje zespół
odpowiedzialny za zabezpieczenia złożony
przeważnie z tych samych osób, które
tworzyły oprogramowanie. Dobre zespoły
kładą większy nacisk na testowanie
definicji i fazy projektowej cyklu życia
oprogramowania niż na testowanie
wdrażania. W sprzedaży pojawiają się tzw.
„złote środki” do testowania, ale takie
programy po prostu nie istnieją. Rys.2
Zespoły testujące powinny spodziewać się
tego, że ponad połowę czasu zajmuje
testowanie projektów i procesów. Pozostały
czas powinien być przeznaczony na
sprawdzenie tego, jak te projekty i polityka
tworzenie została wykorzystana w kodzie.
Rys.3
Podsumowanie
Tworzenie bezpiecznego oprogramowania oznacza tworzenie lepszego
oprogramowania. Testowanie bezpieczeństwa oznacza testowanie całego cyklu życia
oprogramowania, które kolejno testuje ludzi, procesy i technologie.
Strona 47 z 50
48. TESTER.PL
Kontakt:
Regina Koenig, (22) 528 66 37
Mercury
rkoenig@mercury.com
Beata Pogorzelska, (22) 810 10 50
ITBC Communication
Beata_Pogorzelska@itbc.pl
MERCURY MANAGED SERVICES DLA PLATFORMY SAP NETWEAVER™
Warszawa, 7 czerwca 2005 r. - Mercury Interactive Corporation (NASDAQ:
MERQ), lider w zakresie optymalizacji technologii biznesowych (BTO),
poinformował o udostępnieniu rozwiązań Mercury Managed Services dla SAP
NetWeaver,
umożliwiających
krytycznych
aplikacji,
bez
zarządzanie
wydajnością
konieczności
inwestowania
i
dostępnością
w
dodatkową
infrastrukturę.
Rozwiązanie Mercury Managed Services zapewnia wysoką jakość obsługi
użytkowników,
nawet
w ramach
dużych
wdrożeń
obejmujących
tysiące
stanowisk. Oferowane usługi pozwalają korzystającym z oprogramowania SAP
na:
•
całościową weryfikację wydajności i skalowalności zautomatyzowanych
procesów gospodarczych;
•
identyfikowanie, diagnozowanie i rozwiązywanie problemów w zakresie
wydajności, wynikających między innymi z dostosowywania rozwiązań do
niestandardowych potrzeb, integracji z systemami innych firm oraz zmian
w infrastrukturze;
Strona 48 z 50
49. TESTER.PL
•
prewencyjne zarządzanie poziomem usług.
Dzięki zastosowaniu pakietu Mercury Performance Center możliwie jest
wykonywanie testów obciążeniowych, dostrajanie wydajności, planowanie mocy
obliczeniowej
oraz
diagnostykę
wdrożeń
SAP
NetWeaver
przed
ich
uruchomieniem. Ponadto użytkownicy mogą skorzystać z rozwiązania Mercury
Business Availability Center, które umożliwia zarządzanie poziomem usług i
konfiguracją, odwzorowywanie powiązań między aplikacjami, diagnostykę
aplikacji oraz zarządzanie dostępnością systemów. W ramach programu Mercury
Managed Services klienci korzystający z produktów firmy SAP współpracują ze
specjalistami firmy Mercury w zakresie zarządzania rozwiązaniem SAP
NetWeaver przez cały okres jego eksploatacji. Rozwiązanie jest już dostępne na
rynku.
USŁUGI MERCURY MANAGED SERVICES
Program Mercury Managed Services polega na udostępnianiu rozwiązań
przez Internet, w modelu hostingu. Firma Mercury wyznacza zespół specjalistów,
który udziela użytkownikom pomocy w zdalnym zarządzaniu wydajnością i
dostępnością krytycznych aplikacji do zarządzania przedsiębiorstwem (ERP) i
obsługą klienta (CRM) oraz innych aplikacji niestandardowych. W większości
przypadków rozwiązanie Mercury Managed Services umożliwia efektywne
wprowadzanie w życie rozwiązań informatycznych w ciągu kilku tygodni, a nawet
kilku dni. Z Mercury Managed Services korzysta obecnie ponad 500 klientów ze
Stanów Zjednoczonych, Europy i Dalekiego Wschodu.
MERCURY I SAP
Mercury i SAP współpracują od połowy lat dziewięćdziesiątych. Jako partner
SAP w dziedzinie oprogramowania, firma Mercury opracowała szereg rozwiązań
przeznaczonych do optymalizacji jakości, wydajności i skalowania rozwiązań
firmy SAP. Produkty Mercury, takie jak Mercury WinRunner®, Mercury QuickTest
Professional™ i Mercury LoadRunner®, uzyskały certyfikaty w zakresie integracji
z oprogramowaniem SAP. Dzięki tym certyfikatom użytkownicy mają
zagwarantowane niezawodne współdziałanie interfejsów pomiędzy produktami
Strona 49 z 50
50. TESTER.PL
obu firm. W lutym 2005 r. zostało zawarte długoterminowe porozumienie, dzięki
któremu w ramach usługi SAP Go Live Check Service przeznaczonej dla
użytkowników platformy SAP NetWeaver™ oferowane jest rozwiązanie Mercury
LoadRunner.
Strona 50 z 50
