TESTER.PL

Strona 1 z 50

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

TESTER.PL

Strona 2 z 50

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.

TESTER.PL

Strona 3 z 50

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

TESTER.PL

Strona 4 z 50

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

TESTER.PL

Strona 5 z 50

Sponsorzy:

- Sponsor Główny

- Sponsor

- Partner medialny

TESTER.PL

Strona 6 z 50

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.

TESTER.PL

Strona 7 z 50

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™;

TESTER.PL

Strona 8 z 50

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/application-

delivery/

TESTER.PL

Strona 9 z 50

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

TESTER.PL

Strona 10 z 50

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.

TESTER.PL

Strona 11 z 50

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.

TESTER.PL

Strona 12 z 50

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.

TESTER.PL

Strona 13 z 50

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

TESTER.PL

Strona 14 z 50

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:

TESTER.PL

Strona 15 z 50

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 Wartość Imię Jan Nazwisko Kowalski Ulica Jeziorna 5 Miasto 01-230 Warszawa NIP 111-222-33-44 PESEL 01030478954

TESTER.PL

Strona 16 z 50

Nazwisko panieńskie matki Nowak Imię matki Anna Imię ojca Tomasz Telefon 22 44 55 667

Następnie kliknięty zostaje przycisk “OK”. Pojawia się komunikat, że konto zostało utworzone:

TESTER.PL

Strona 17 z 50

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_

NUMBER FIRST_NAME LAST_NAM

E CREATION_DATE

326473246 23454985 Jan Kowalski 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 SERVICE_NUMB

ER SERVICE_TYPE ACTIVATION_D

ATE 326473246 1 TEL_ACC 02-04-2005

TESTER.PL

Strona 18 z 50

326473246 2 INT_ACC 02-04-2005 326473246 3 VISA 02-04-2005 326473246 4 SMS_NOTIF 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 SERVICE_NUMBER PRICING_SCHEME_ID 326473246 1 IND_TEL_ACC 326473246 2 IND_INT_ACC 326473246 3 GEN_VISA 326473246 4 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 EVENT_TYPE EVENT_DATE AMOUNT 326473246 ACTIV 02-04-2005 20.00 326473246 MON_FEE 02-04-2005 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”

TESTER.PL

Strona 19 z 50

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

TESTER.PL

Strona 20 z 50

Stan bazy danych: Select CUSTOMER_ID, ACCOUNT_NUMBER, FIRST_NAME, LAST_NAME, CREATION_DATE from CUSTOMERS where ACCOUNT_NUMBER = 23454985 CUSTOMER_ID ACCOUNT_NUMBER FIRST_NAME LAST_NAME CREATION_DATE 326473246 23454985 Jan Kowalski 02-04-2005

Select CUSTOMER_ID, SERVICE_NUMBER, SERVICE_TYPE, ACTIVATION_DATE from SERVICES where CUSTOMER_ID = 326473246 CUSTOMER_ID SERVICE_NUMBER SERVICE_TYPE ACTIVATION_DATE 326473246 1 TEL_ACC 02-04-2005 326473246 2 INT_ACC 02-04-2005 326473246 3 VISA 02-04-2005 326473246 4 SMS_NOTIF 02-04-2005

Select CUSTOMER_ID, SERVICE_NUMBER, PRICING_SCHEME_ID from PRICING_SCHEME_ASGN where CUSTOMER_ID = 326473246 CUSTOMER_ID SERVICE_NUMBER PRICING_SCHEME_ID 326473246 1 IND_TEL_ACC 326473246 2 IND_INT_ACC 326473246 3 GEN_VISA 326473246 4 GEN_SMS

TESTER.PL

Strona 21 z 50

Select CUSTOMER_ID, EVENT_TYPE, EVENT_DATE, AMOUNT from BILLING_EVENTS where CUSTOMER_ID = 326473246 CUSTOMER_ID EVENT_TYPE EVENT_DATE AMOUNT 326473246 ACTIV 02-04-2005 20.00 326473246 MON_FEE 02-04-2005 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

TESTER.PL

Strona 22 z 50

Stan bazy danych: Select * from CUSTOMERS where ACCOUNT_NUMBER = 23454985

TESTER.PL

Strona 23 z 50

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 SERVICE_NUMBER SERVICE_TYPE ACTIVATION_DATE STATUS COMMENTS ADDRESS_STREET ADDRESS_CITY DEACTIVATION_REASON DEACTIVATION_DATE ON_HOLD LAST_COMPLAINT LEVEL_OF_SATISFACTION DISCOUNT 326473246 1 TEL_ACC 02/04/2005 AC Added on initial activation N 7 30 326473246 2 INT_ACC 02/04/2005 AC Added on initial activation N 7 0 326473246 3 VISA 02/04/2005 AC Added on initial activation N 7 30 326473246 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 PRICING_SCHEME_ID EFFECTIVE_DATE DISCOUNTING_MODE

TESTER.PL

Strona 24 z 50

CHARGE_MODE 326473246 1 IND_TEL_ACC 02/04/2005 STD IND 326473246 2 IND_INT_ACC 02/04/2005 STD IND 326473246 3 GEN_VISA 02/04/2005 VISA VISA 326473246 4 GEN_SMS 02/04/2005 STD IND Select * from BILLING_EVENTS where CUSTOMER_ID = 326473246 CUSTOMER_ID EVENT_TYPE SERVICE_NUMBER EVENT_DATE AMOUNT STATUS TAX_RATE VAT_RATE GL_CAT RATING_MODE 326473246 ACTIV 02/04/2005 20 TBB 0 22 INDGL OTC 326473246 MON_FEE 02/04/2005 15 TBB 0 7 INDGL RCM

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.

TESTER.PL

Strona 25 z 50

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.

TESTER.PL

Strona 26 z 50

TESTER.PL

Strona 27 z 50

Test Driven Development

kolejna miękka metodologia tworzenia modułów

czy

sposób na zwiększenie zainteresowania programistów

testami modułowymi

Joanna Nowakowska, Lucjan Stapp, Pion Zarządzania Jakością Wydział MiNI,

Rodan Systems S.A. 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.

TESTER.PL

Strona 28 z 50

Test Driven Development

kolejna miękka metodologia tworzenia modułów

czy

sposób na zwiększenie zainteresowania programistów

testami modułowymi

Joanna Nowakowska, Lucjan Stapp, Pion Zarządzania Jakością Wydział MiNI,

Rodan Systems S.A. 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).

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

specyfikacja funkcjonalna

implementacja

Testy akceptacyjne

Testy systemowe

Testy Integracyjne ”małe”

Testy modułowe

specyfikacja wymagań

specyfikacja systemu

TESTER.PL

Strona 29 z 50

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.

TESTER.PL

Strona 30 z 50

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 test-first 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ł

TESTER.PL

Strona 31 z 50

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. Emma6. Wszystkie

2 http://www.junit.org 3 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

TESTER.PL

Strona 32 z 50

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

0

1

2

3

4

5

6

7

8

zadanie 1 zadanie 2 zadanie 3 zadanie 4 zadanie 5

grupa TDD 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.

TESTER.PL

Strona 33 z 50

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

0

2

4

6

8

10

12

14

zadanie 1 zadanie 2 zadanie 3 zadanie 4 zadanie 5

grupa TDD 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)

0

2

4

6

8

10

12

14

16

18

zadanie 1 zadanie 2 zadanie 3 zadanie 4 zadanie 5

grupa TDD grupa kontrolna

Rysunek 5 Jakość kodu (wg Hammurapi)

TESTER.PL

Strona 34 z 50

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ą:

TESTER.PL

Strona 35 z 50

• 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.

TESTER.PL

Strona 36 z 50

• 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

TESTER.PL

Strona 37 z 50

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]. Beck, K, Test Driven Development by example, Addison-Wesley, 2002 [2]. Gilb T., Graham D., Software Inspection, Addison-Wesley 1993, [3]. Newkirk, James W,. Vorontsov, Alexei A, Test Driven Development in

Microsoft .NET, Microsoft Professional, 2005 [4]. Hunt, Andy, Thomas, Dave, Pragmatic Unit Testing in C# with NUnit,

Pragmatic Programmers, 2005

TESTER.PL

Strona 38 z 50

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

TESTER.PL

Strona 39 z 50

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

TESTER.PL

Strona 40 z 50

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.

TESTER.PL

Strona 41 z 50

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ę.

TESTER.PL

Strona 42 z 50

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:

TESTER.PL

Strona 43 z 50

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

TESTER.PL

Strona 44 z 50

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:

TESTER.PL

Strona 45 z 50

• 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

TESTER.PL

Strona 46 z 50

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.

TESTER.PL

Strona 47 z 50

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.

TESTER.PL

Strona 48 z 50

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 zarządzanie wydajnością i dostępnością

krytycznych aplikacji, bez konieczności inwestowania 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;

TESTER.PL

Strona 49 z 50

• 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

TESTER.PL

Strona 50 z 50

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.