2. TESTER.PL
Outsourcing - modne słowo, chociaż może się wydawać że jego blask chwilowo
„przyblakł”. Outsourcing bowiem oznacza bardzo ścisły związek pomiędzy usługodawcą
a usługobiorcą. Oznacza niemalże 100 % zaufanie pomiędzy partnerami w biznesie. Czy
powoli ta „moda” przenosi się do też testowania, niezwykle odpowiedzialnego i można
powiedzieć strategicznego elementu procesu produkcji oprogramowania Czy
menedżerowie IT są dzisiaj zdecydowani na zlecanie takich usług? Z drugiej strony czy
firmy oferujące takie usługi są wystarczająco kompetentne w tej materii? I w końcu
chyba najważniejsze pytanie – czy to się opłaca?
Tak naprawdę od kryterium opłacalności trzeba zacząć. Dzisiaj testy to nie jest
prosta „klikologia”. Czasy, kiedy zespół testowy tworzyła grupa studentów,
a kierownikiem tego „temu” był programista z półrocznym doświadczeniem skończyły
się – chyba na zawsze.
Dzisiejszy tester to wysokiej klasy inżynier znający Javę, języki pochodne od C
(C++ C#), języki skryptowe, bazy danych, serwery aplikacji, serwery www, itp., itd.
Ponadto taka osoba „czuje” testy, ma pewne predyspozycje i cechy charakteru typowe
dla testera (ci, którzy są testerami wiedzą o czym piszę ☺). Oczywiście wiedza
merytoryczna z tej bardzo specyficznej dziedziny jest niezbędna. Kierownik testów zaś to
doświadczony project manager. Siłą rzeczy utrzymywanie takiego bardzo
profesjonalnego zespołu testerskiego może być w konsekwencji dużo droższe od kosztów
zespołu developerskiego. Jeżeli do tego dodamy zakup i utrzymanie profesjonalnych
narzędzi to sprawa wydaje się oczywista. Trzeba komuś zlecić to zadanie.
Dlatego wiele przedsiębiorstw na zachodzie Europy i w USA zdecydowało się na
ścisłą współpracę z profesjonalnymi firmami realizującymi usługi testowania „na
zewnątrz”.
Kwestia outsourcingu testowania rozległych i skomplikowanych rozwiązań IT
wydaje się ekonomicznie uzasadniona.
Zapewne ta „moda”, a tak naprawdę konieczność wynikająca z rachunku
ekonomicznego zawita wkrótce powszechnie do Polski.
Pozdrawiam,
Wojciech Jaszcz
Strona 2 z 42
3. TESTER.PL
Od redaktora
Pora na skromny jubileusz – to już piąty numer kwartalnika TESTER.PL!!!
W tym numerze dwa artykuły, oba bardzo interesujące:
1. Łukasza Żebrowskiego „Automatyzacja testów aplikacji internetowych
z wykorzystaniem narzędzia JMeter” – o jednym z najlepszych
i najpopularniejszych automatów testowych,
2. Hansa Schaefera „What a Tester Should Know, even After Midnight” o podstawowych zasadach pracy testera, jego obowiązkach i prawach
Pierwszy z nich to kolejny artykuł z serii o bezpłatnych narzędziach
wspomagających testowanie. W serii ukazały się już artykuły Roberta Rzeszotka o Pure
Test (w numerze pierwszym kwartalnika) i o BadBoy’u (w numerze trzecim).
Jeśli zechcecie podzielić się informacjami o innych automatach testowych,
których używacie - zapraszamy do publikacji na łamach naszego pisma.
We września tego roku, na naszym cyklicznym spotkaniu gościliśmy norweskiego
specjalistę testowania Hansa Schaefera Drugi artykuł - w języku angielskim podsumowuje informacje przedstawione już przez Hansa Schaefera na spotkaniu.
Polecam także tym, którzy uczestniczyli w spotkaniu.
Nasze kontakty na arenie europejskiej ulegają stałemu zacieśnieniu; w numerze
przedstawiamy sprawozdanie z III Światowego Kongresu Jakości Oprogramowania
w Monachium
Zamieszczamy też dwie informacje o nadchodzących konferencjach, obie
polecamy uwadze czytelników:
•
pierwsza to zaproszenie do Krakowa, na kolejna konferencję z serii Software
Quality Assurance Management SQAM, tym razem w Krakowie, 7 – 9
listopada 2005; wśród prelegentów kilku członków naszego Stowarzyszenia,
•
w numerze znajdziecie też informację o przyszłorocznej wrześniowej
konferencji CONQUEST 2006, w Berlinie. To właśnie ta konferencja od lat
gromadzi teoretyków i praktyków testowania z całego świata.
Osoby zainteresowane zapraszamy też na kolejną już edycję kursu Certyfikowany
Test Manager, organizowanego przez IIR w kwietniu 2006.
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.
Interesującej lektury!
Strona 3 z 42
5. TESTER.PL
III Światowy Kongres Jakości Oprogramowania.
Wojciech Jaszcz
Prezes SJSI
W dniach 26-30 września 2005 w Niemczech odbył się już trzeci światowy
kongres poświęcony jakość oprogramowania – 3rd World Congress for Software
Quality. W wydarzeniu udział wzięło prawie 1000 osób, które zjechały do
Monachium z czterech kontynentów.
W dniach 26–30 września, w Monachium, odbył się III Światowy Kongres
Jakości Oprogramowania (właściwa nazwa to: 3rd World Congress for Software Quality).
W wydarzeniu wzięło udział prawie 1000 osób, reprezentujących ponad 130 firm, z
czterech kontynentów. Powyższe liczby przemawiają do wyobraźni i jednoznacznie
pokazują, że w stolicy Bawarii reprezentowany był cały „świat QA”.
Pierwszy
dzień
Kongresu
wypełniły w całości seminaria.
Było ich łącznie czternaście, a
prowadzącymi byli eksperci z
Japonii, USA, Indii, Niemiec,
Norwegii, i Wielkiej Brytanii.
Reprezentowali
oni
zarówno
środowisko akademickie, jak i
„komercyjne”.
Tematyka
seminariów
była
bardzo
zróżnicowana, więc każdy mógł
znaleźć coś interesującego dla
siebie.
Rysunek 1 Politechnika Monachijska - miejsce
organizacji Kongresu
Kongres oficjalnie rozpoczął się we wtorek. Otworzył go ciekawym
wystąpieniem Hans Spitzner - Sekretarz Stanu Rządu Bawarii, Minister Ekonomii,
Infrastruktury, Transportu i Technologii. Kolejne wykłady prowadzone były w kilku
sesjach, z których najciekawsze to: Zarządzanie projektem, Integracja i testowanie,
Techniki przeglądu i audyty. Drugi dzień Kongresu podsumowany został wystąpieniem
Clausa E. Heinrich’a – Członka Zarządu SAP AG. Pan Heinrich podzielił się swoimi
ciekawymi „jakościowymi” doświadczeniami z wdrożeń systemów informatycznych
w przemyśle.
Środa to kolejny dzień bardzo interesujących prezentacji. Tylko wyjątkowy
malkontent nie wyszukałby jakiegoś ciekawego wykładu dla siebie. Tego dnia mieliśmy
również dwa znaczące polskie akcenty na Kongresie: przedpołudniową sesję „Testing I”
Strona 5 z 42
6. TESTER.PL
poprowadziła Joanna Nowakowska, natomiast ze swoją prezentacją pod tytułem
„Development and Validation of a HAZOP-based Inspection of UML Models”
wystąpił Aleksander Jarzębowicz z Politechniki Gdańskiej.
Rysunek 2 Audytorium podczas jednego z wykładów
Co więcej, tego dnia prawie wszyscy uczestnicy Kongresu bawili się na
organizowanym w tym samym czasie Oktoberfest. Królowały znakomite pieczone
kurczaki oraz doskonałe piwo z podalpejskich browarów.
Rysunek 3 Wejście na Oktoberfest
Rysunek 4 Zabawa na Oktoberfest
W związku z tym kongresowy czwartek rozpoczął się „bawarskim” śniadaniem, czyli
białą gotowaną kiełbasą podawaną z wyśmienitym piwem. Po takiej przekąsce, wszyscy
już w pełni sił mogli uczestniczyć w wykładach. Jedną z popołudniowych sesji „Agile
Methods” poprowadził Wojciech Jaszcz. Hellmuth Broda z SUN Microsystems zakończył
część merytoryczną Kongresu wykładem o środowiskach „Open”.
Profesor Berndt Hindel wygłaszając mowę końcową zakończył to czterodniowe
międzynarodowe spotkanie. Warto wspomnieć, że nagroda za najlepszy artykuł
powędrowała do Jon’a Whittle’a z QSS Group Inc.. Natomiast za najlepszą została
Strona 6 z 42
7. TESTER.PL
prezentację uznana została ta prowadzona przez panią Noriko Izumi z Hitachi HighTechnologies Corporation.
Rysunek 5 Wręczenie nagrody za najlepszy artykuł
Rysunek 6 Hellmuth Broda
„Na
deser”,
w
piątek,
zainteresowani mogli odwiedzić
jedną z trzech fabryk: BMW, Audi
lub Siemens. Taka okazja nie
zdarza się co dzień.
Rysunek 7 Fabryka BMW
Z pewnością warto było uczestniczyć w tym Kongresie. Wiele ciekawych
tematów, sporo wystawców rozwiązań, a przede wszystkim bardzo interesujący ludzie z
niemal wszystkich kontynentów, sprawiły, że o tej imprezie można mówić praktycznie
tylko w samych superlatywach. Szkoda, że wykłady standardowo trwały jedynie pół
godziny, a 5 min przeznaczone na dyskusję po każdym wykładzie szybko okazało się za
krótkie.
Warto przypomnieć, że SJSI było Patronem Medialnym tego Kongresu.
Kolejna, czwarta edycja Kongresu odbędzie się w 2008 roku w Waszyngtonie. Wcześniej
jednak, bo już w przyszłym roku w Berlinie będziemy mogli uczestniczyć w cieszącej się
dużym prestiżem konferencji CONQUEST 2006.
Strona 7 z 42
9. TESTER.PL
Automatyzacja testów aplikacji internetowych
z wykorzystaniem narzędzia JMeter
Łukasz Żebrowski
Łukasz Żebrowski jest absolwentem Szkoły
Głównej Handlowej w Warszawie na kierunku
Metody Ilościowe i Systemy Informacyjne. W
2005r. obronił pracę magisterską na temat „Plan
ratunkowy jako narzędzie ochrony systemów
informatycznych”.
Karierę
rozpoczął
w
Departamencie Ryzyka Rynkowego w Banku
Przemysłowo Handlowym PBK S.A., tworząc jeden
z modułów aplikacji wspierającej procesy
zarządzania ryzykiem operacyjnym. Od ponad dwóch lat pracuje w firmie Rodan
Systems S.A., obecnie na stanowisku Specjalisty ds. Zapewnienia Jakości, gdzie
odpowiada m.in. za testy systemowe i akceptacyjne aplikacji wykorzystujących
rozwiązania OfficeObjects®Workflow.
Żonaty. Jego hobby to fotografia i podróże. Posiada licencję pilota wycieczek.
Strona 9 z 42
10. TESTER.PL
Automatyzacja testów aplikacji internetowych
z wykorzystaniem narzędzia JMeter
Łukasz Żebrowski
Rodan Systems S.A.
Praca testera aplikacji internetowych nie jest łatwa. Rozwój technologii
internetowych, coraz bogatsze funkcjonalności aplikacji webowych np. autoryzacja
użytkowników, różnicowanie zakresów i poziomów ich uprawnień, implementacje
rozwiązań sterujących procesami pracy, mnogość funkcji użytkowych, a z drugiej strony
przyrostowy model tworzenia oprogramowania i napięte terminy wdrożeń sprawiają, że
konieczne stają się częste testy regresywne. Narzędziem, które z powodzeniem można
zastosować w tego typu testach, ale nie tylko jest wywodząca się z projektu Jakarta
aplikacja Apache JMeter (http://jakarta.apache.org/jmeter/) napisana w Javie i
dystrybuowana na licencji open source. JMeter będąc narzędziem typu Capture &
Raplay umożliwia funkcjonalne generowanie obciążenia aplikacji webowych oraz
mierzenie ich wydajności. Dodatkowo dzięki bogatej ofercie elementów, z których
tworzone są skrypty testowe JMeter umożliwia dostosowanie ich do indywidualnych,
często bardzo różnorodnych potrzeb testerów. Niniejszy artykuł zapozna czytelników z
obsługą JMeter’a, zaprezentuje jego możliwości i przedstawi jego praktyczne
zastosowanie w testach funkcjonalnych i wydajnościowych.
1. Budowa aplikacji
JMeter nie wymaga instalacji i jest gotowy do uruchomienia zaraz po
rozpakowaniu binariów, oczywiście pod warunkiem, że mamy zainstalowaną Javę.
Interfejs aplikacji przedstawiony jest na rys. 1. Główne okno zawiera menu i podzielone
jest na dwie części: po lewej stronie znajduje się drzewo elementów, z których stworzony
jest skrypt JMeter’a; w oknie po prawej stronie znajduje się obszar, w którym
wyświetlane i edytowane są szczegóły poszczególnych elementów. Kolejne elementy
skryptu dostawia się za pomocą podręcznego menu, wywoływanego prawym kliknięciem
myszki na odpowiedni element skryptu. Ostatnim elementem interfejsu jest kwadrat w
prawym górnym rogu(wskazany strzałką) informujący o stanie aplikacji (kolor szary
oznacza stan spoczynku, kolor zielony informuje, że skrypt jest w danym momencie
odtwarzany). W katalogu bin znajduje się jeszcze jeden plik, o którym będzie mowa w
dalszej części artykułu, mianowicie jmeter.properties, w którym użytkownik może pewne
elementy funkcjonowania aplikacji dostosować do swoich potrzeb.
Strona 10 z 42
11. TESTER.PL
Rys. 1. Interfejs JMeter’a
Jak wspomniałem na początku, JMeter jest narzędziem rejestrująco - odtwarzającym
(Capture&Replay Tool), a więc służącym do nagrywania sekwencji czynności
wykonywanych podczas testu ręcznego w przeglądarce internetowej, a następnie do
odtwarzania tych czynności w sposób automatyczny1. Jako przykład wykorzystałem
internetowy klient pocztowy, za pomocą którego wysyłać będę wiadomość e-mail,
następnie sprawdzę, czy wiadomość została wysłana, a na koniec wiadomość zostanie
usunięta z katalogu „wysłane”. Dane o odbiorcach oraz treści maili pobrane zostaną z
pliku. Wybrałem przykład prosty i być może mało ciekawy2, pozwala on jednak na
przetestowanie pewnej funkcjonalności testowanej aplikacji, a przy okazji daje doskonałą
okazję do zaprezentowania różnorodnych opcji narzędzia JMeter.
2. Nagrywanie skryptu
Po uruchomieniu JMeter’a skrypt składa się z dwóch elementów Test Plan
i WorkBench (widać to na rys. 1). Aby rozpocząć nagrywanie scenariusza, należy skrypt
wyposażyć w odpowiednie elementy a następnie je sparametryzować. Elementy
zaprezentowane na rys. 2 stanowią szkielet praktycznie każdego skryptu.
1
http://www.sjsi.org/bin/doc/slownik_v10.html
Użytkownika, który wysłał wiadomość e-mail zapewne najbardziej interesuje fakt, czy wiadomość dotarła
do adresata, jednakże taki przykład niepotrzebnie komplikowałby szkoleniowy scenariusz.
2
Strona 11 z 42
12. TESTER.PL
Rys. 2. Główne elementy skryptu JMeter
W skrócie przedstawię każdy z nich3:
Test Plan jest nadrzędnym elementem całego skryptu i stanowi miejsce, w którym można
zdefiniować stałe wykorzystywane podczas całego testu.
HTTP Cookie Manager obsługuje cookies, przechowuje informacje o sesji i jest
elementem niezbędnym przy rejestrowaniu akcji.
Thread Group grupuje elementy należące do jednego wątku. Jeden scenariusz może
zawierać kilka takich elementów.
Recording Controller jest elementem grupującym wszystkie rejestrowane zapytania.
WorkBench stanowi podręczne miejsce, w którym można przechowywać chwilowo
niewykorzystywane elementy, jego zawartość nie jest zapisywana podczas zapisywania
skryptu, stanowi miejsce, w którym umieszczany jest HTTP Proxy Server.
HTTP Proxy Server jest elementem sterującym serwerem proxy, wykorzystywanym
podczas nagrywania skryptu.
Po tym teoretycznym wstępie czas na rozpoczęcie budowy naszego skryptu.
JMeter’a uruchamiamy poprzez wykonanie pliku jmeter.bat znajdującego się w katalogu
bin. W otwartym oknie klikamy prawym przyciskiem myszy na element Test Plan
i wybieramy z menu podręcznego Add > Config Element > HTTP Cookie Manager.
Ponownie klikamy prawym przyciskiem na element Test Plan i wybieramy Add >
Thread Group. Następnie klikamy na element Thread Group i wybieramy Add > Logic
Controller > Recording Controller. Na koniec klikamy na WorkBench i wybieramy Add
> Non-Test Elements > HTTP Proxy Server. Wybierane elementy utworzą drzewo jak na
rys. 2.
Kolejnym krokiem jest parametryzacja komponentu HTTP Proxy Server – rys. 3.
Klikamy lewym przyciskiem myszki na ten element, wówczas w prawej części okna
wyświetli się formularz z atrybutami tego elementu. Ustawiamy port, na którym
uruchomiony zostanie serwer proxy np. 8001, a w polu Target Controller wybieramy Use
Recording Controller. Po kliknięciu przycisku Start JMeter jest gotowy do rejestrowania
żądań4 wysyłanych do serwera proxy.
3
Po szczegółowe informacje dotyczące tych i wszystkich innych elementów zapraszam na stronę
http://jakarta.apache.org/jmeter/usermanual/component_reference.html
4
W dalszej części artykułu stosował będę zamiennie określenia ‘żądanie’ i ‘zapytanie’ jako polski
odpowiednik słowa ‘request’.
Strona 12 z 42
13. TESTER.PL
Rys. 3. Element HTTP Proxy Server
Przed przystąpieniem do nagrywania naszych działań w przeglądarce, warto
wspomnieć o dwóch rzeczach. Komponent HTTP Proxy Server pozwala na
zdefiniowanie żądań, które mają być rejestrowane, a które pomijane. Służą do tego
odpowiednio pola „Patterns to Include” oraz „Patterns to Exclude”. Po kliknięciu
odpowiedniego przycisku Add pojawia się pole tekstowe, w które można wstawić
wyrażenie regularne5 definiujące wzór żądania (adresu URL). W naszym przykładzie
nagramy tylko strony php, wobec tego w polu „Patterns to Include” wstawiamy
wyrażenie regularne .*.php Kolejną rzeczą, o której warto zawczasu pamiętać to adres
serwera, na którym nagrywamy skrypty. Często zdarza się, że skrypty nagrywamy na
jednym serwerze, natomiast odtwarzane są one później na różnych serwerach testowych,
szkoleniowych, czasem produkcyjnych. W takiej sytuacji warto, aby adres serwera, port,
katalog, w którym zainstalowana jest aplikacja nagrane zostały w postaci parametrów.
W tym celu w elemencie Test Plan w sekcji User Defined Variables klikamy przycisk
Add i podajemy nazwę zmiennej oraz wartość, którą JMeter ma zastąpić wskazaną
zmienną6. Rys. 4 prezentuje wymyślone przeze mnie zmienne IP i katalog z
odpowiadającymi im wartościami.
5
Więcej o wyrażeniach regularnych można znaleźć m. in. na stronie http://wiki.apache.org/jakartajmeter/RegularExpressions
6
Jest to zmienna, gdyż JMeter nie zabrania późniejszej modyfikacji tego parametru.
Strona 13 z 42
14. TESTER.PL
Rys. 4. Parametry w sekcji User Defined Variables
Tak przygotowany skrypt na wszelki wypadek zapisujemy wybierając w menu
File > Save Test Plan as i możemy przystąpić do nagrywania skryptu. Uruchamiamy
przeglądarkę internetową, zmieniamy ustawienia przeglądarki, aby łączyła się przez
serwer proxy7, w elemencie HTTP Proxy Server uruchamiamy serwer proxy przyciskiem
Start i od tej chwili JMeter rozpoczyna rejestrowanie wszystkich żądań wykonanych
w przeglądarce.
Po zakończeniu nagrywania scenariusza zatrzymujemy serwer proxy przyciskiem
Stop, aby nie nagrały się dodatkowe żądania. Na rys. 5 przedstawiono scenariusz
z nagranymi zapytaniami, które jak widać umieszczone zostały poniżej elementu
Recording Controller. W przypadku dużych skryptów, np. gdy rejestrowana jest grafika,
istnieje mozliwość pogrupowania żądań, służy do tego element Simple Controller (Add >
Logic Controller > Simple Controller)8.
7
W IE wchodzimy w Narzędzia > Opcje internetowe, przechodzimy do zakładki Połączenia, klikamy
Ustawienia sieci LAN i w sekcji Serwer proxy zaznaczamy opcję „Użyj serwera proxy dla sieci LAN”, w
polu adres wpisujemy localhost, a w polu port wartość podaną w elemencie HTTP Proxy Server. Aby
ułatwić sobie włączanie i wyłączanie ustawień proxy, warto skorzystać z pluginu do przeglądarki, np.: dla
IE http://www.snapfiles.com/get/proxypal.html , lub dla Mozilli http://jgillick.nettripper.com/switchproxy/
8
Istnieje również możliwość zdefiniowania sposobu grupowania zapytań w polu Grouping elementu HTTP
Proxy Server.
Strona 14 z 42
15. TESTER.PL
Rys. 5. Budowa elementu HTTP Request
Prześledźmy teraz budowę przykładowego nagranego żądania. Każde żądanie
zapisane zostało w postaci elementu HTTP Request (rys. 5). Jak widzimy w polach Name
i Path, JMeter zastąpił wyrażenie ‘poczta’ odwołaniem do parametru ‘katalog’ w postaci
${katalog}9, podobna podmiana została wykonana w polu Server Name or IP. Pole Path
zawiera nagrany adres URL, pole Name ma tą samą zawartość, lecz wykorzystywane jest
ono jedynie jako etykieta. Poniżej w sekcji Send Parameters with Request zawarte są
wszystkie parametry, z którymi dane zapytanie zostało wykonane.
3. Parametry w JMeterze
Nagrany scenariusz teoretycznie jest gotowy do odtworzenia i przy odrobinie
szczęścia może wykonać się poprawnie. Jednakże zazwyczaj uruchomienie takiego
skryptu zwróci nam różnego rodzaju błędy np. „Obiekt o podanym id nie może zostać
utworzony, gdyż istnieje już obiekt o podanym id”, lub „Nie odnaleziono strony
o podanym adresie” w scenariuszu, w którym nagrywana była akcja usuwania jakiegoś
obiektu z bazy danych, a w adresie podany został identyfikator usuniętego wówczas
obiektu. Nawet jeśli wszystko wykonało się poprawnie nie mamy gwarancji, że np. za
9
Stosowanie parametrów zostało opisane w dalszej części artykułu.
Strona 15 z 42
16. TESTER.PL
tydzień, gdy zmieni się środowisko testowe ten skrypt uda się poprawnie wykonać.
Kolejnym krokiem, najważniejszym podczas automatyzacji testów jest odpowiednia
parametryzacja testów. Od tego etapu zależy skuteczność skryptów testowych, oraz ich
elastyczność względem środowiska testowego. Czas poświęcony na dokładną
parametryzację zwróci się z nawiązką w przyszłości, jeśli starannie przeprowadzona
parametryzacja pozwoli nam uniknąć modyfikacji wszystkich skryptów w związku ze
zmianami w środowisku testowym.
W JMeterze możemy wyróżnić następujące źródła wartości parametrów:
- parametry zaszyte w skrypt,
- generowane za pomocą funkcji,
- pobierane z pliku,
- pobierane z bazy danych,
- dynamicznie pobieranie poprzez wyrażenia regularne.
Parametry zaszyte w skrypt. Rys. 6 prezentuje część parametrów, z którymi nagrane
zostało żądanie wysłania wiadomości e-mail. Widać na nim, że adres odbiorcy(to),
temat(subject), treść(body) zapisane są na stałe. Taki skrypt będzie zawsze wysyłał emaila o tej samej treści na ten sam adres. Nie pozwoli nam to na przetestowanie, np. jak
będzie się zachowywała aplikacja, jeśli w polu temat użyjemy polskich znaków lub
pozostawimy to pole puste. Parametrami zaszytymi w skrypt są również wspomniane
wcześniej parametry katalog i IP, ponieważ ich wartości zostały zdefiniowane w
elemencie Test Plan. Oczywiście parametr zaszyty w skrypt nie zawsze oznacza coś
złego. Na rys. 6 widoczny jest parametr priority. Jeśli nasz scenariusz skupiał się będzie
na funkcjonalności wysyłania wiadomości, a priorytet e-maila nie będzie istotny, można
pozostawić go z obecną wartością. Podobnie może być z parametrami katalog i IP. Jeśli
nie przewidujemy dużej liczby skryptów, definicje wartości tych parametrów mogą
pozostać w skrypcie. Unikniemy pracy związanej z budową obsługi pobierania danych
np. z pliku, a wystarczającym ułatwieniem dla nas będzie fakt, że nie musimy ręcznie
modyfikować wszystkich zapytań, a jedynie definicję parametru.
Rys. 6. Parametry zaszyte w skrypt
Parametry generowane za pomocą funkcji. Jak już wcześniej wspomniałem odwołanie
do parametru ma postać ${nazwa_parametru} i wstawiane jest w polu wartość(value) dla
odpowiedniego atrybutu. Dozwolone jest przy tym łączenie ciągów znakowych np.
wyrażenie mail${licznik}przy założeniu, że licznik=5 zwróci ciąg znakowy mail5.
W podobny sposób następuje odwołanie do funkcji ${__functionName(var1,var2,var3)},
gdzie __functionName odpowiada nazwie funkcji. Przed nazwą funkcji jest podwójny
Strona 16 z 42
17. TESTER.PL
znak podkreślenia, jednakże zależy to od nazwy funkcji, również wielkość liter w nazwie
funkcji ma znaczenie10.
JMeter posiada kilkanaście wbudowanych funkcji, można również samemu
definiować własne funkcje11. W naszym przykładzie wykorzystam następujące funkcje:
__CSVRead, _StringFromFile, __split, __counter, a sposób ich wykorzystanie opisany
został w dalszej części.
Parametry pobierane z pliku. Do pobierania danych z pliku służą wcześniej
wymienione funkcje __CSVRead oraz _StringFromFile. Pierwsza z nich służy do
pobierania danych z pliku CSV(Comma Separated Value)12. Ponieważ funkcja ta jest
łatwa w użyciu, ale skutkuje wczytaniem do pamięci całego pliku, co może mieć wpływ
na wydajność, stosowana powinna być do raczej niewielkich plików, np. pliku
zawierającego parametry, z jakimi mają być wykonane wszystkie nasze skrypty.
Natomiast jeśli do testów chcemy wykorzystać plik zawierający dane wyciągnięte z bazy
danych zawierającej 8 milionów rekordów lepszym rozwiązaniem jest funkcja
_StringFromFile, która przy każdym wywołaniu wczytuje kolejną linię z pliku.
Parametry pobierane z bazy danych. Czasami jedynym źródłem, z którego możemy
zasięgnąć potrzebne informacje jest baza danych, np. dynamicznie generowany
identyfikator instancji czynności dla konkretnego użytkownika w aplikacji stosującej
rozwiązania klasy workflow. W tym celu można wykorzystać element JDBC Request13
(Add > Sampler > JDBC Request) - szczegóły elementu przedstawia rys. 7. Oczywiście
jako wartości poszczególnych atrybutów można użyć parametrów lub funkcji, również
w samym zapytaniu SQL.
Rys. 7. Element JDBC Request
10
Dokładny opis i zastosowanie funkcji można znaleźć na stronie
http://jakarta.apache.org/jmeter/usermanual/functions.html
11
Prawdopodobnie z wykorzystaniem skryptów BeanShell. Autor dotychczas nie korzystał z tej opcji.
12
Pomimo nazwy, JMeter umożliwia w pliku jmeter.properties zdefiniowanie własnego separatora wartości
poprzez wpis np. csvread.delimiter=;
13
Do prawidłowego działania potrzebne są odpowiednie sterowniki JDBC.
Strona 17 z 42
18. TESTER.PL
Wyrażenia regularne. Ostatnim źródłem danych dla naszego skryptu są odpowiedzi
zapytań, wykonanych wcześniej w danym scenariuszu, np. po wprowadzeniu dokumentu
do systemu wyświetlona zostaje strona z komunikatem „Dokument został dodany” wraz
z linkiem do szczegółów owego dokumentu. Za pomocą odpowiedniego wyrażenia
regularnego można uzyskać id dodanego dokumentu znajdującego się w kodzie strony.
Wyrażenie regularne definiuje się w elemencie Regular Expression Extractor (Add >
Post Processors > Regular Expression Extractor), który umieszcza się jako element
podrzędny względem filtrowanego żądania. Wyrażeniem regularnym posługujemy się
również w celu uzyskania odpowiedzi z JDBC Request.
4. Parametryzacja skryptu
Automatyzacja testów zazwyczaj opłacalna jest wówczas, gdy skrypty testów
automatycznych wykorzystywane będą wielokrotnie. Często kolejne iteracje testów
odtwarzane są w różny sposób w zależności od rodzaju testów np. kładąc nacisk na
powtarzalność lub na obciążenie. Wobec tego parametryzację rozpoczniemy od elementu
Thread Group i jego atrybutów sterujących sposobem odtwarzania wątków w skrypcie
testowym: liczbą wątków (Number of Threads), okresem rozruchu (Ramp-up Period)
oraz ilością powtórzeń (Loop Count). Dane te przechowywać będziemy w pliku test.csv
zawierającym tylko jedną linię tekstu np.”5;10;15”12, gdzie kolejne liczby stanowić będą
wartości odpowiednich parametrów. Ich interpretacja jest następująca: test będzie
symulował 5 równocześnie działających użytkowników, startujących co 2 sekundy14,
wykonujących ten sam test 15 razy. Dane z pliku pobierzemy za pomocą funkcji
__CSVRead z dwoma parametrami, pierwszy wskazuje odwołanie do pliku15, drugi
Number of
Threads podamy
wskazuje kolumnę danych16, np. dla
${__CSVRead(test.csv,0)}. Sparametryzowany element przedstawia rys. 8.
Rys. 8. Sparametryzowany element Thread Group
Kolejnym krokiem, który wykonamy na potrzeby naszego przykładu będzie
wydzielenie żądań związanych z logowaniem od reszty scenariusza, tak aby użytkownik
logował się tylko raz do klienta poczty, natomiast wielokrotnie (w zależności od Loop
Count) wykonywał czynności związane z wysyłaniem maili itd. W tym celu posłużymy
14
Ramp-up Period oznacza okres pomiędzy uruchomieniem pierwszego i ostatniego wątku, kolejne wątki
uruchamiane są w równych odstępach Ramp-up Period/Number of Threads.
15
Odwołanie do pliku jest case sensitive, może być zaszyte na stałe lub zawierać odwołanie do innego
parametru np. ${scenariusze}test.csv. Jeśli nie podamy ścieżki do pliku, wówczas plik będzie poszukiwany
w katalogu bin (jest to domyślne ustawienie, które można zmodyfikować w pliku jmeter.properties - wpis
user.dir). Można również podawać ścieżki względne np. ..scenariusze lub bezwzględne c:scenariusze
16
Pierwsza kolumna ma numer 0, druga numer 1 itd.
Strona 18 z 42
19. TESTER.PL
się bezparametrowym elementem Once Only Controller (Add > Logic Controller > Once
Only Controller), który umieścimy poniżej elementu Thread Group. Następnie
przeniesiemy do niego kolejno dwa pierwsze żądania(wejście na stronę główną,
logowanie się). Elementy przenosimy w następujący sposób: klikamy na wybrany
element lewym przyciskiem, przeciągamy go na element Once Only Controller,
puszczamy przycisk i z podręcznego menu wybieramy Add as Child. W podobny sposób
postępujemy z kolejnymi elementami, lub korzystamy w odpowiedni sposób z opcji
w menu podręcznym Insert Before, Insert After. W grupie Logic Controller (Add > Logic
Controller) znajdziemy wiele przydatnych elementów m. in. ForEach Controller, While
Controller, If Controller, Loop Controller itd.
W następnym kroku zajmiemy się parametryzacją poszczególnych żądań. Jak
pamiętamy częściowo zostały one już sparametryzowane (parametry IP i katalog). Teraz
zajmiemy się wartościami parametrów wysyłanych wraz z żądaniami. Najpierw do
zapytania, w którym przesyłane są login i hasło podstawimy wartości odczytane z pliku
test.csv, gdzie dostawimy kolejne kolumny oddzielone średnikami zawierające login
i hasło, a więc zawartość będzie wyglądała np. tak: „5;10;15;jmeter@os.pl;pwd123”17.
Do odczytu danych posłużą nam element Java Request i wyrażenia regularne. Java
Request (Add > Sampler > Java Reuqest18) ma wiele zastosowań, m. in. może służyć
jako miejsce wykonywania funkcji. W naszym scenariuszu element ten będzie nam
zwracał tekst zawierający login i hasło. W tym celu w polu ResultData wstawimy tekst
(rys. 9):
X0_${__CSVRead(test.csv,3)}_X1_${__CSVRead(test.csv,4)}_X2
Rys. 9. Element Java Request
Po odczytaniu odpowiednich wartości z pliku, element Java Request zwróci tekst:
X0_jmeter@os.pl_X1_pwd123_X2 (rys. 10).
17
Przedstawiona tu konstrukcje pobierania danych to przerost formy nad treścią, ponadto wymusza na
wszystkich symulowanych użytkownikach korzystanie z tego samego konta i w prawdziwych testach
raczej nie powinna mieć miejsca, jednakże zastosowałem ją tutaj dla potrzeb szkoleniowych.
18
Java Request można wykorzystać np. do wywołania funkcji __CSVRead z opcją next() np.
__CSVRead(test,csv,next()) co powoduje zmianę odwołania w pliku do kolejnego wiersza.
Strona 19 z 42
20. TESTER.PL
Rys. 10. Otrzymany wynik elementu Java Request
Do wyodrębnienia loginu i hasła wykorzystamy wspomniany już wcześniej
element Regular Expression Extractor (Add > Post Processors > Regular Expression
Extractor), który umieszczamy jako element podrzędny do Java Request, czyli elementu
generującego dane do filtrowania. Rys. 11 prezentuje poprawną konfigurację elementu
Regular Expression Extractor. Pole Reference Name definiuje nazwę zmiennej, do której
przypisana zostanie wyodrębniona wartość. Pole Regular Expression definiuje wyrażenie
regularne, według którego wyszukiwany jest tekst. Co ma zostać zwrócone definiowane
jest w nawiasie, w tym przypadku (.*) oznacza wszystko co znajduje się pomiędzy X0_
oraz _X1. Pole Match No. definiuje, które wystąpienie poszukiwanego wyrażenia ma
zostać zwrócone. Zastosowanie pola Template wyjaśnię na przykładzie. Na rys.11.
zdefiniowana jest jedna grupa $1$, co oznacza, że zwrócona zostanie jedna wartość,
przypisana do zmiennej login_g1 lub po prostu login. Na rys.12. w definicji wyrażenia
regularnego podane są dwa wyrażenia znajdujące się w nawiasie, a w polu Template
zdefiniowane zostały dwie grupy $2$, co oznacza, ze zwrócone zostaną dwie wartości:
login_g1=jmeter@os.pl oraz login_g2=pwd12319.
Rys. 11. Przykładowa konfiguracja elementu Regular Expression Extractor
Rys. 12. Przykładowa konfiguracja elementu Regular Expression Extractor z dwoma grupami
Regular Expression Extractor może być również stosowany z HTTP Request
pozwalając czerpać dane z kodu stron zwracanych w wyniku zapytania, przez co stanowi
potężne źródło inspiracji dla testera (np. różnego typu testy rekurencyjne) i świadczy
o potędze tego narzędzia w rękach doświadczonego użytkownika.
Zmienne login_g1 i login_g2 z wynikami wyrażenia regularnego wstawiamy
w odpowiednie pola zapytania wywołującego autoryzację użytkownika i przechodzimy
do parametryzacji dalszej części skryptu. Pozostało nam sparametryzowanie żądania
19
Po dokładniejszy opis odsyłam do dokumentacji
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Regular_Expression_Extractor
Strona 20 z 42
21. TESTER.PL
wysyłającego wiadomość e-mail, a konkretnie pól adresat, temat i treść. Pola adresat
i treść wypełnimy danymi odczytanymi z pliku, ale przy pomocy funkcji
_StringFromFile. Funkcja ta przy każdym wywołaniu wczytuje kolejną linię z pliku.
Dane wczytywane będą z pliku maile.txt zawierającego np. taką treść:
jmeter@gazeta.pl|Witam, Serdeczne pozdrowienia z Warszawy przesyła JMeter.
jmeter@onet.pl|Witam, Pozdrowienia z Krakowa przesyła JMeter.
Ponieważ _StringFromFile czyta całą linię, a my potrzebujemy wyodrębnić z niej dwa
parametry oddzielone separatorem „|” wykorzystamy funkcję__split (tekst_do_podziału,
nazwa_zmiennej, separator). Dodajemy nowy element Java Request i w polu Response
Data20 wstawiamy: ${__split(${_StringFromFile(maile.txt)},VAR,|)}. Wyodrębnione
parametry przypisane są do zmiennych VAR_1 i VAR_2, więc odwołania do tych
zmiennych wstawiamy w odpowiednie pola. Pozostało nam jeszcze sparametryzować
temat maila. Ponieważ nie chcemy duplikować nazw wiadomości, każda kolejna
wiadomość wysyłana przez poszczególnych użytkowników powinna różnić się tytułem.
Użyjemy do tego celu elementu Counter (Add > Pre Processors > Counter) - rys. 13.
Element ten wprowadza nam zmienną o nazwie wprowadzonej w pole Reference Name,
której wartość zwiększa się z każdym wywołaniem tego elementu. Mając zdefiniowany
licznik, możemy tytułowi każdego maila przydzielić wartość: Temat maila ${counter}.
Sparametryzowane zapytanie wysyłające e-mail prezentuje rys. 14. Tak przygotowany
skrypt jest gotowy do uruchomienia.
Rys. 13. Element Counter
Rys. 14. Parametry zapytania wysyłającego wiadomość e-mail.
20
Ponieważ nie interesuje nas wynik tego Java Request, lecz jedynie wywołanie funkcji, funkcję tą
możemy umieścić również w innych polach tego elementu.
Strona 21 z 42
22. TESTER.PL
Funkcją, której nie wykorzystałem w tym przykładowym skrypcie, a o której
warto wspomnieć jest funkcja __javaScript wykonująca fragment kodu JavaScript
i zwracająca wartość, np.:
${__javaScript(var d = new Date(); var date = d.getDate(); $DATE = d.getFullYear()+
"/" + d.getMonth() + "/" + date + "_" + d.getHours() + ":"+ d.getMinutes() + ":"+
d.getSeconds());,DATE)}
5. Odtwarzanie skryptu i zbieranie wyników
W celu odtworzenia skryptu w menu Run wybieramy opcję Start. Odtwarzanie
skryptu można przerwać przed końcem wybierając opcję Stop. O tym, czy skrypt
w danym momencie jest odtwarzany informuje zielony kolor kwadratu w prawym
górnym rogu. JMeter umożliwia również zdalne wykonywanie skryptów z innych
komputerów. Opcja ta szczególnie przydaje się do symulacji dużej ilości użytkowników,
z czym pojedyncza maszyna może mieć problemy. Przed zdalnym uruchomieniem
skryptów, w pliku jmeter.properties należy uzupełnić wpis remote_hosts o IP
komputerów, które posłużą jako serwery generujące zapytania. Numery IP wpisujemy
oddzielając je przecinkiem. Po uruchomieniu JMeter’a na komputerze
klienckim(sterujący serwerami) w menu Run > Remote Start ujrzymy odwołania do
poszczególnych serwerów. Testy na nich można uruchamiać osobno lub wszystkie naraz
(Run >Remote Start All). W sposób analogiczny działa opcja Remote Stop. Aby
komputer mógł pracować jako serwer musi mieć uruchomioną usługę rmiregistry21, oraz
aplikację JMeter w trybie serwer (jmeter.bat –s). Znajdujący się w katalogu bin plik
jmeter-server.bat uruchamia oba programy.
Przed przystąpieniem do odtwarzania należy wyposażyć skrypt w elementy
odpowiedzialne za zbieranie i wizualizację wyników. Najczęściej stosuje się View
Results Tree (Add > Listener > View Results Tree) umieszczany podrzędnie do Thread
Group. View Results Tree (rys. 15) składa się z 2 okien: w lewym w postaci drzewa
prezentowane są wszystkie kolejno wykonywane zapytania, w prawym w 3 zakładkach
prezentowane są informacje o wykonaniu zapytania.
21
Plik rmiregistry.exe znajduje się w katalogu JAVA_HOMEbin
Strona 22 z 42
23. TESTER.PL
Rys. 15. Element View Results Tree
a)
b)
Rys. 16. Informacje o zapytaniu w View Results Tree
Zakładka Sampler result (rys.16a) zawiera informacje o przebiegu wykonania
zapytania. Zakładka Request (rys. 16b) zawiera informacje o wykonanym zapytaniu.
Natomiast w zakładce Response przedstawiona jest odpowiedź uzyskana w wyniku
zapytania. Odpowiedź można wyświetlić jako tekst (opcja Show Text) lub jako strona
HTML (opcja Render HTML) – rys.15.
Pozostałe elementy z grupy Listener (Add > Listener) oferują inne sposoby
wizualizacji wyników np. Aggregate Report prezentuje m. in. zestawienie minimalnych,
Strona 23 z 42
24. TESTER.PL
średnich i maksymalnych czasów odtwarzanych zapytań, a Graph Results przedstawia
przebieg testów na wykresie. Część elementów z tej grupy umożliwia również zapisanie
wyników testu do pliku. Na przykład na rys. 15 w górnej części okna widoczne jest pole
Filename. Można w nim wskazać nazwę pliku, do którego dane będą zapisywane22.
JMeter umożliwia również odtwarzanie skryptów z linii poleceń, zgodnie ze
składnią:
jmeter -n -t <nazwa pliku scenarusza> -l <nazwa pliku z wynikami>.
Nazwa pliku z wynikami wskazuje plik, do którego zostaną zapisane dane z testów i jest
on tożsamy z plikiem definiowanym np. w View Results Tree. Wyniki testów domyślnie
zapisane są w formacie XML23 i zawierają m.in. informacje o czasie wykonania testu,
nazwie zapytania, czasie odpowiedzi, rodzaju odpowiedzi, poprawnym wykonaniu testu
itd. Wyniki mogą być również zapisane jako plik csv24. Po zakończeniu testów pliki
wynikowe można wczytać do odpowiedniego elementu z grupy Listener aby uzyskać
odpowiednią wizualizację graficzną; dokonać transformacji(XML) z wykorzystaniem
arkuszy styli XSL; lub przetworzyć innym narzędziem, np. w Excelu. W katalogu extras
znajdują się przykładowe arkusze styli XSL.
Innym przydatnym elementem jest Save Responses to a file (Add > Post
Processors > Save Responses to a file), który zapisuje do pliku odpowiedź na zapytanie,
a więc np. stronę HTML. Element ten umieszczony jako podrzędny do Recording
Controller zapisywał będzie odpowiedzi wszystkich zapytań znajdujących się
w Recording Controller. Zapisane pliki mają nazwę składającą się z wartości podanej
w polu Filename prefix oraz kolejnego numeru zapytania generowanego automatycznie
przez JMeter.
6. Asercje
Automatyzacja testów nie byłaby do końca skuteczny, gdyby nie wykorzystywała
automatycznej weryfikacji danych wyjściowych czyli gdyby nie stosowała asercji.
JMeter oferuje kilka rodzajów asercji m.in. Duration Assertion, Size Assertion, HTML
Assertion, MD5HEX Assertion. W naszym przykładzie użyjemy najprostszej asercji
Response Assertion (Add > Assertions > Response Assertion). Element ten umożliwia
zdefiniowanie wzorów ciągów tekstowych, których obecność w odpowiedzi na zapytanie
jest weryfikowana zgodnie z ustawieniami. Stwórzmy asercję badającą obecność tekstu
„Wiadomość została wysłana”25, na stronie wyświetlonej po wysłaniu wiadomości
e-mail. Wstawiamy element Response Assertion podrzędnie do testowanego żądania
22
Każdy element Listener zapisuje do pliku te same dane w ten sam sposób. Jeśli nie chcemy obciążać
komputera przetwarzaniem wizualizacji danych, a zależy nam tylko na zapisie danych do pliku to służy do
tego element Simple Data Writer.
23
Np. <sampleResult timeStamp="1128273174906" dataType="text" threadName="Thread Group 1-1"
label="/poczta/newmsg.php" time="360" responseMessage="OK" responseCode="200" success="true"/>
24
Np. 1128273306421,343,/poczta/msglist.php,200,OK,Thread Group 1-1,text,true. Format zapisu
definiuje wpis jmeter.save.saveservice.output_format w pliku jmeter.properties. Można tam również
określić rodzaj separatora jmeter.save.saveservice.default_delimiter, oraz, które dane mają być
rejestrowane. Zapis w formacie csv pozwala wzbogacić plik wynikowy o własne dane, np. wprowadzając
do pola z nazwą zapytania odpowiednie informacje oddzielone separatorem.
25
Można tu stosować również wyrażenia regularne np. „Wiadomo(.*) zosta(.*)a wys(.*)ana” będzie
ignorować potencjalne błędy wynikające z polskich znaków.
Strona 24 z 42
25. TESTER.PL
i odpowiednio konfigurujemy. Najpierw w polu Patterns to Test wstawiamy
poszukiwane wyrażenie. Następnie w polu Response Field to Test definiujemy gdzie
fraza będzie wyszukiwana. Na koniec w Pattern Matching Rules decydujemy czy
pożądane wyrażenie ma być zawarte w odpowiedzi (Contains) czy być równe
odpowiedzi (Match). Jeśli poprawny test nie powinien zawierać podanej frazy wówczas
zaznaczamy pole Not. Rys. 17 prezentuje przykładową konfigurację elementu Response
Assertion.
Rys.17. Element Response Assertion
Przed odtworzeniem skryptu należy dodać jeszcze element Assertion Results
z grupy Listener, w którym prezentowane są wyniki asercji. Rys. 18. prezentuje
przykładowy komunikat informujący, że asercja zwróciła błąd. Jeśli asercja zwróci błąd,
informacje o tym znaleźć można również w View Results Tree, gdzie odpowiednie
żądanie zostaje opisane kolorem czerwonym - rys. 1926.
Rys.18. Przykładowy komunikat o błędzie wyświetlony w Response Assertion
26
Nazwa zapytania w kolorze czerwonym jest standardowym oznaczeniem błędu, nie tylko podczas
wykonywania asercji, ale również jeśli odpowiedź informuje o błędzie np. http 404 lub http 500.
Strona 25 z 42
26. TESTER.PL
Rys. 19. Przykładowy komunikat o błędzie wyświetlony w View Results Tree
Budowę końcową naszego przykładowego skryptu prezentuje rys. 20.
Rys. 20. Budowa gotowego skryptu przykładowego.
Przedstawiony powyżej przykład prezentuje pewien wąski wycinek
funkcjonalności oferowanych przez JMeter’a. JMeter’em można testować również
żądania FTP, SOAP, TCP. Można korzystać z elementów sterujących wykonywaniem
zapytań w czasie np. definiując stałe odstępy czasu, losowe zgodnie z rozkładem Gaussa,
Strona 26 z 42
27. TESTER.PL
lub określając ilość zapytań na minutę. Można również korzystać z wielu innych
sposobów definiowania, pobierania i generowania danych dla użytkowników, zapytań
itd. Ponadto JMeter obsługuje język skryptowy BeanShell, który pozwala użytkownikowi
w jeszcze większym stopniu dostosować aplikację do swoich potrzeb. A jeśli i to komuś
nie wystarcza, to zawsze można dorobić jakąś funkcjonalność samemu. Przecież to open
source.
7. Podsumowanie
Zaprezentowałem Państwu narzędzie, które moim zdaniem każdy tester powinien
znać. Jest to narzędzie stosunkowo łatwe w obsłudze, łatwe do nauczenia przynamniej
w jego podstawowym zakresie, z drugiej strony dające ogromne możliwości zarówno pod
względem testowanych elementów np. HTTP, JDBC, jak i pod względem źródeł,
z których można czerpać dane(z plików, z bazy danych, generowane przez funkcje oraz
z samego siebie dzięki wyrażeniom regularnym). Dzięki tej różnorodności podstawową
barierą jest wyłącznie kreatywność samego testera. Ponadto zapewnia stosunkowo dużą
elastyczność skryptów względem środowiska testowego, oraz szerokie zastosowanie ze
względu na rodzaj testów: od funkcjonalnych po wydajnościowe.
Lista zalet jest długa, jednakże nie jest to narzędzie pozbawione wad. JMeter
posiada różne błędy utrudniające czasem pracę, lecz twórcy aplikacji starają się je
w miarę wolnego czasu na bieżąco poprawiać. Brakuje mu porządnego modułu
raportującego na podstawie danych wynikowych, lecz niedawno ruszyły prace nad
budową takiego modułu. Ponieważ jest narzędziem typu Capture & Replay zmiany
aplikacji mogą powodować dezaktualizację skryptów, lecz jest to ogólna przypadłość
narzędzi tego typu. Ponadto nie testuje interfejsu GUI testowanej aplikacji. Nie
umożliwia również nagrywania zapytań https, ale potrafi odtwarzać żądania https.
Ponieważ jest napisane w Javie, potrafi mocno obciążyć komputer podczas odtwarzania
skryptów, zwłaszcza, gdy symulowana jest duża ilość użytkowników. I ma problemy
z polskimi znakami27.
Niezależnie od wad, uważam, że zalety tego narzędzia są nieocenione. Jeżeli
dorzucimy do tego sprawną pomoc, którą można uzyskać poprzez listę dyskusyjną28 nie
pozostaje nam nic innego jak tylko zaprzyjaźnić się z JMeter’em. A jeśli, ktoś z Państwa
zdążył się już wcześniej zaprzyjaźnić z Badboy’em, którego w 3 numerze Testera.pl
prezentował Robert Rzeszotek, nic nie stoi na przeszkodzie, aby wyeksportować
scenariusze BadBoy’a do formatu JMeter’a29. Na koniec życzę owocnych testów
z wykorzystaniem JMeter’a i proszę pamiętać, że najtrudniejsze mają Państwo za sobą:
negocjacje z przełożonymi w sprawie pieniędzy na zakup kolejnego narzędzia do testów.
27
Stronę kodową definiuje się w pliku jmeter.properties wpisem sampleresult.default.encoding. Błąd na
rys. 18 i 19 nie wynikał z błędnego działania aplikacji, lecz z błędu JMeter’a. Zastosowanie frazy
ignorującej polskie znaki zlikwidowała występowanie błędu.
28
http://jakarta.apache.org/site/mail2.html#JMeter
29
Eksport w Badboy’u do formatu JMeter’a wykonuje się poprzez wybór z menu File > Export to JMeter
Strona 27 z 42
28. TESTER.PL
an informa business
Institute for International Research Sp. z o.o. jest polskim przedstawicielstwem
największej międzynarodowej firmy organizującej prestiżowe konferencje i
seminaria dla najwyższej kadry zarządzającej sektora prywatnego i publicznego. IIR
na świecie działa od ponad 30 lat a w Polsce od 1997 roku.
Wszystkie budowane przez nas programy przygotowywane są w oparciu o
szczegółowe badania rynku i analizowane pod kątem ich praktycznej przydatności
w bieżącym zarządzaniu firmą jak i w tworzeniu planów strategicznych. Prelegenci,
których zapraszamy wywodzą się przede wszystkim ze środowisk biznesowych, nie
brakuje wśród nich również prawników, wykładowców akademickich jak i
przedstawicieli rządu.
Od czerwca 2005 r. IIR Global ma nowego właściciela. Jest nim wiodący
międzynarodowy dostawca specjalistycznej informacji i usług dla środowisk
akademickich, profesjonalnych i biznesowych – Informa plc.
Nasi nowi właściciele postanowili pozostawić na rynku markę IIR jako symbol
organizatora konferencji i seminariów, podczas których wiedzę poszerzają eksperci.
Więcej informacji znajdą Państwo w Internecie pod adresem: http://www.iir.pl
Podsumowania
naszych
konferencji
znajdą
Państwo
na
stronie
http://www.iir.pl/konf/archiwum.html
Strona 28 z 42
29. TESTER.PL
an informa business
Certyfikowany Test Manager
kwiecień 2006 r., Warszawa
Trzydniowe interaktywne warsztaty dla osób odpowiedzialnych za testowanie
Szanowni Państwo,
serdecznie zapraszam Państwa do udziału w IV edycji kursu pt. Certyfikowany Test
Manager, który odbędzie się w kwietniu 2006 r. w Warszawie. To trzydniowe
seminarium da Państwu wiedzę na temat technicznych i organizacyjnych aspektów
procesu testowania. Udział w spotkaniu umożliwi Państwu efektywne
wykorzystanie angażowanych w testowanie zasobów.
W trakcie kursu poznają Państwo zasady testowania systemów informatycznych
oraz inne działania mające ogromny wpływ na ich jakość. W programie nie zabrakło
tak ważnego tematu jakim jest miejsce testów w procesie budowy systemu
informatycznego z uwzględnieniem najczęstszych przyczyn problemów w
projektach tego typu oraz stosowanej metodyki realizacji projektów
informatycznych. Dzięki udziałowi w tym kursie poznają Państwo jaka jest formalna
rola i zadania szefa zespołu testowego, będzie to również świetna okazja do
zdobycia miękkich umiejętności wymaganych przy kierowaniu takim zespołem.
Ostatni dzień spotkania poświęcony będzie normom i standardom odnoszącym się
do wytwarzania systemów informatycznych.
W trakcie kursu będzie miało miejsce sprawdzenie nabytych przez Państwa
umiejętności na podstawie praktycznych testów. Zdobyta wiedza potwierdzona
zostanie wspólnym certyfikatem wystawionym przez Stowarzyszenie Jakości
Systemów Informatycznych oraz IIR. Certyfikat będzie udokumentowaniem
Państwa fachowej wiedzy.
W razie pytań związanych z programem kursu proszę o kontakt telefoniczny: (022)
420 55 21 bądź za pośrednictwem poczty elektronicznej: erekosz@iir.pl
Z poważaniem
Edyta Rekosz
kierownik projektu
Institute for International Research Sp. z o.o.
Wojciech Jaszcz
Prezes
Stowarzyszenie Jakości Systemów Informatycznych
Strona 29 z 42
30. TESTER.PL
What a Tester Should Know, even After Midnight
Hans Schaefer
Software Test Consulting
hans.schaefer@ieee.org
Hans Schaefer to jeden z najbardziej znanych na świecie specjalistów w
dziedzinie testowania oprogramowania komputerowego oraz znakomity
prelegent i wykładowca. Przewodniczący Norwegian Software Testing
Qualifications Board
http://home.c2i.net/schaefer/testing.html
Strona 30 z 42
31. TESTER.PL
What a Tester Should Know, even After Midnight
Hans Schaefer
Software Test Consulting
A tester can do testing «just as a job». This could be good enough. Alternatively, a tester
can invest «the little extra», i.e. do a better job. In this paper, I try to define what this
«little extra» means.
Testing The Normal Way is Not Enough.
Systematic testing of software or systems can be learned, just like any engineering
discipline. There are tester knowledge certification schemes (ISTQB, ISEB, GTB), there
are books (Myers 79, Beizer 95, Kaner 99, Copeland 2004,) and there are standards
(ISTQB Glossary, BS 7925, IEEE 829, 1008, 1012,). At least the books and most of the
standards have been around for a long time, and many techniques are widely accepted.
This means testing can actually be studied and then executed in some systematic way.
This does not mean the typical testing methods described in this material are widely
practiced (Schaefer 2004). But it is at least possible to do testing «by following the
book».
For a tester, or test engineer, there are two major activities: Designing test cases, and
executing test cases and observing and analyzing results. If the results are not like
expected, deviations must be reported and followed up. Additionally, modern methods,
like exploratory testing (Bach website), include tasks like automation, and management
of testing time in the tester’s task list.
The normal way of doing this job is to learn some techniques, follow these techniques,
execute the test, and conclude the work with a test report. The typical task description
tells people to «test the system», not defining any more detail. Some books define the
task as «getting information about the quality», or «measuring quality» (Hetzel). As test
execution is one of the last activities in a project, it is very often run under severe and
budget time pressure. This means that the testers have a hidden or open motivation to
compromise on the thoroughness of their job. For example, as detecting defects always
delays both testing and the delivery or acceptance of the product, there is a hidden
pressure not to find any defects, or at least not serious ones. Testing is just «done». This
job is then not very motivating, investment in learning is scarce, people try to find a
different job, and testing does not improve over time.
Strona 31 z 42
32. TESTER.PL
Can we do Testing in a Better Way?
Glenford Myers, in 1979, defined testing differently: The aim of Testing to find defects.
He used this definition because it motivates people. Having a negative focus, trying to
break the product, leads to finding more and more serious defects than just checking if
the product «works».
Most people do as they are told. If they are told to find as many defects as possible, they
will try to do so. If told to get the job done (and explicitly or inherently passing the
message that defects delay the progress), people will try not to find defects, or they will
overlook many.
Thus the first rule is to clearly define the purpose of testing, and make the purpose
perfectly clear to people. This will be discussed in chapter 3.
There is one more problem with any job, not only testing: The world is developing,
especially in software. New techniques, methods and tools become available or are used
in design. Software products are more and more integrated with each other and growing
more and more complex. The focus of the requirements is changing, for example
emphasizing more security, interoperability and usability. This leads to changes in the
requirements to the testing job. Thus, a tester should continuously try to learn more. This
will be discussed in chapter 4.
The next problem is the mindset of people. Some people very much accept information
they see or rules that are given. Some people are critical and investigate and ask. As one
of the purposes of testing is finding problems and defects, a mindset that does not accept
everything without asking, checking more details, getting more information or thinking
would lead to better testing. This will be discussed in chapter 5.
Part of the tester’s task is to report incidents. This is not easy. Most literature read by
testers just describes issue and defect management, i.e. the life cycle of reporting,
prioritizing and handling these. But this is just «the ordinary job». Actually, there is more
to it. It can be compared to the task a frustrated user has when calling the supplier help
desk: Describing the problem in such a way that the other side accepts it as important
enough to do something about it. It means collecting more information about the trouble,
but also to think about how to «sell» the bug report to the responsible person. This is the
topic of chapter 6.
Finally, a tester has some rights. We should not just test anything thrown to us over the
wall. If information we need is not available, or if the product under test is far too bad,
testing it anyway means wasted resources. There should be some entry criteria to testing,
some «Tester’s Bill of Rights» (Gilb 2005). This is the topic of chapter 7.
All of this has to do with the philosophy of testing. But there are some tools, some very
basic rules for doing the work. There is a lot of controversy about what the basis is, but I
Strona 32 z 42
33. TESTER.PL
dare to include a few from a conference speech (Schaefer 2004). This is the topic of
chapter 8.
There is definitely more to it. A tester should always be on the outlook for more
challenges in field of testing. This paper is only the beginning of what you may look for.
The Purpose of Testing
There are a lot of possible goals for testing. One main, but possibly boring, purpose is to
measure the quality of a product. Testing is then considered just a usual measuring
device. Just usual measuring is not much fun, but a necessary job, which must be done
well. However there are questions a tester should ask, in order to measure optimally. The
main question is which quality characteristics are most important to know, and how
precisely the measurement must be done.
Another definition of testing is trying to create confidence in the product. Confidence,
however, is best built by trying to destroy it (and not succeeding in doing so). It is like
scientific work: Someone proposes a new theory, and all the educated specialists in the
area try all they can to show that it is wrong. After trying this for some time,
unsuccessfully, the new theory is slowly adopted. This view supports Myers’ definition
of software testing: Find defects! The approach is a pessimist approach. The pessimist
believes «this probably does not work» and tries to show it. Every defect found is then a
success.
People are functioning by motivation. The definition of testing as actively searching for
bugs is motivating, and people find more bugs this way. It works in two ways: One is by
designing more destructive or just more test cases. The other one is by having a closer
look at the results, analyzing details a not motivated tester would overlook. In the latter
case this may mean to analyze results that are not directly visible at the screen, but are
deep inside some files, databases, buffers or at other places in the network.
A tester should try to find defects!
Defects may be at places where you do not see them easily, i.e. not on screen output!
But it is more than this! Defects are like social creatures: they tend to clump together. It is
like mosquitoes: If you see and kill one, do you think this is the last one in the area? Thus
we may have a deeper look in areas where we find defects. Testers should have an idea
where to look more. They should study quality indicators, and reports about them.
Indicators may be the actual defect distribution, lack of internal project communication,
complexity, changes, new technology, new tools, new programming languages, new or
changed people in the project, people conflicts etc. The trouble is that all these indicators
may sometimes point into the wrong direction. The defects found may have been detected
at nearly clean places, just because the distribution of test cases tested these areas
especially well. Project communication may look awful; some people who should
communicate may be far from each other. But such people might communicate well
Strona 33 z 42
34. TESTER.PL
anyway, in informal or unknown ways, or the interface between the parts they are
responsible for may have been defined especially well, nearly “idiot proof”. Complex
areas may be full of errors. There is a lot of research showing that different complexity
indicators may predict defect distribution. However, there are nearly always anomalies.
For example, the most experienced people may work with the most complex parts.
Changes introduce defects or may be a symptom of areas, which have not been well
analyzed and understood. But changes may also have been especially well thought out
and inspected. In some projects, there are «dead dogs» in central areas who nobody wants
to awake. These central areas are then badly specified, badly understood and may be
completely rotten. But as nobody wants to «awake the dog» there are no change requests.
New technology is a risk, partly because technology itself may lead to new threats, partly
because using it is new to the people. People do not know what are the challenges with it.
The same is true about the testers. Little may be known about the boundaries of
technology and tools. However, it may work the opposite way: New technology may
relieve us of a lot of possible defects, simply making them impossible.
Finally we may look at the people. It is the people who introduce the defects. Research
has shown that «good» and «bad» programmers have widely differing productivities and
defect rates. However, defects do not only result from programming. It is more difficult
to map people to design and specification trouble. But at least one factor nearly always
has a negative impact: Turnover. If people take over other people’s job, they very often
do not get the whole picture, because tacit knowledge is not transferred. This is especially
true if there was no overlap between people.
Thus, there are lots of indicators that may lead us to more defects, but we have to use
them with care.
Defects clump together: they are social!
Defects often have a common cause!
Try to find common causes, and then follow them!
Where you find defects, dig deeper!
One more definition of testing is «measuring risk». This plainly means that testing is a
kind of risk mitigation, part of risk management. Testers should have an idea about
product risk, as well as risk management. In the worst case, testers should ask questions
about product risk, especially if nobody else asks these questions.
A very basic method for this is looking at the usage profile, and at possible damage. A
tester should ask which kind of user would do what how often. How will different users
use the system? How will this vary over time? And very important is not to forget about
wrong input and misuse. People have finger trouble, and interfacing systems have bugs.
Thus there is not only use with correct inputs, but probably also a lot of use with wrong
inputs.
The other risk factor is possible damage. This may be difficult to analyze. A start is at
least to ask oneself “what is the worst thing that can happen if this function, feature or
request fails?”
Strona 34 z 42
35. TESTER.PL
Testing is risk mitigation.
What determines risk?
What happens if some input is wrong?
As a summary, it is best if the tester is a pessimist. (A pessimist is an optimist with
experience). If something does not work, it is good News, because nobody will have the
defect later. The positive effect will be felt in the long run. Better test forces developers
to do better work, it informs management about risks, and it leads to lower cost (for
repair). Testers bring bad News, but that is their job. Nobody loves speed checks on the
motorway! But speed checks make our roads safer, and we all benefit.
A pessimist is a better tester!
Continuous Learning
Continuous learning is required in nearly any job. But for testers it is absolutely essential.
In most cases, testing is done somehow systematically, using some black box approach.
In addition, test design may follow heuristics. Any black box approach may leave
important areas un-covered. Any heuristic is incomplete, as it is dependent on personal
experience (or on learnt experience from others. And white box testing does not uncover
errors of omission. It all comes down to: If there is some aspect the tester doesn’t know,
it is not tested. Thus the tester should know as much as possible. But how?
A tester needs programming experience. There are lots of programming bugs, even after
unit testing by programmers. (Unit testing is often not done well anyway). The tester
should have an idea of what is difficult with the programming language. As an example,
loops and their counters are difficult in most cases, resulting in off-by-one errors. If the
tester has no idea about these, s/he will not check loops with zero, one, maximum and
more than maximum iterations, or will not check which individual object is selected.
Then off-by-one errors will only be found by chance.
The tester needs design experience. Much design is about contracts and communication:
which module within which constraints and with which reactions should do which tasks?
And where are these modules? How do they communicate and solve conflicts? If the
tester has no idea about architectures and their inherent problems, s/he will have trouble
planning (integration) tests.
The tester needs domain experience. System testing is about implementing the right
solution, doing what the domain requires. Can you test a railway interlocking system?
(Eh, what does interlocking mean, by the way...?). At least SOME domain experience
should be there, and/or communication with different stakeholders.
Strona 35 z 42
36. TESTER.PL
The trouble is: This is not enough. Much about testing is getting the right information
from the right people. Interview techniques are an interesting topic to learn. You get more
information when knowing how to interview people!
New systems are interfacing with other systems in more and more intricate ways. And
there are more and more unexpected interfaces. As an example, someone may integrate
YOUR web service into HIS web site, together with other web services. Or your service
works in a vastly different way than someone else’s, and is thus not attractive any more
(or much more attractive than expected). This means: Testing for today’s stakeholders
may definitely be not enough. There are totally new ways your system may be used or
interfaced, totally new ways it may be viewed at, and you should try to anticipate at least
part of this!
A tester should always try to find new ways to look at the object under test, new
approaches, and new viewpoints.
And finally: We want testers to use the newest approaches and technology. You have to
learn them. Read testing books, look for and learn tools, study journals, participate in
discussion groups, special interest groups, discuss with your colleagues, and go to testing
conferences!
Learn more, about everything!
Programming, architecture, new domains, users, tools, anything!
«I am using three things to pull my equipment: dogs, dogs and dogs.» (Roald
Amundsen)
For a tester, the three things are: Learning, learning and learning.
A Critical Mindset
Don’t believe anything! A colleague of mine said: «believing, that is the activity we do
on Sunday morning in the church. Everything else we should check.»
The trouble is: Believing is easier. It does not take work. We just believe, because
something is like expected, or because something is easier. Think about what is written in
your Newspaper. Is it really true? Where were the weapons of mass destruction? Was it
really the Jews who were responsible for all this bad stuff? Is watching TV really
dangerous for your kids? Is a certain soda really good for you?
The answer is: It is easiest not to ask. And if you question everything, you never get
anywhere. Thus in our daily lives, we are accustomed not to ask, to take a lot of things
for granted. To believe, or to assume, and NOT TO ASK QUESTIONS!
Strona 36 z 42
37. TESTER.PL
As a tester, don’t assume anything. It may be wrong! Designer, specifiers, and
programmers assume a lot. It may be difficult to ask because you may look stupid asking.
The other part that could answer may be far away or not easily available. You don’t even
think there may be another interpretation. Or the other part doesn’t know, or you get
some sarcastic answer...
Using the pessimist view, you may as well assume that any assumption is probably
wrong.
Don’t assume! Ask!
There are ways to overcome the trouble that you may seem stupid. Learn how to deal
with people, learn how to interview, learn how to be self-confident. (Learning, see the
section before). Ask someone else. Read, review, sleep over it, and try to find different
interpretations. You may need a lawyer’s mindset.
If you don’t get an answer, have it on your issues list. But don’t just assume something!
Don’t take things for granted! And especially: Don’t believe «the system is probably
right». There has been at least one banking system paying wrong interest. Difficult to
check, after all... There was a geographical information system sending you around half
the world instead of the direct way. There are airline reservation systems not telling you
all available flights. Many more examples exist.
If nobody else asks the right question, you might do so!
Think about new possibilities, unknown problems, and the stuff you learn.
Think «out of the box»!
Defects
Nobody loves the messenger with bad News!
As a tester, most of what you report is bad News. (In a few cases there may be no bad
News to bring, because everything seems to work, but that is a very different story).
The bad News is the bugs, or «issues» to call them in a neutral way. Textbooks handle
this area well. There is issue reporting, registration, handling, removal, retesting,
regression testing. We know all this. But there is something extra to it, and that is not
much in the books:
1 - An issue is only interesting for a tester if it is accepted as a defect and repaired.
2 - There are defects, which are the result of running many test cases in a row in some
very special order.
The first problem is one of salesmanship and discipline. As a tester, one has a sales job.
Nobody is interested in spending any money on repairing defects. They will only be
repaired if they are important enough. Thus, as a tester you have to report an issue in such
Strona 37 z 42
38. TESTER.PL
a way that the developer understands that it must be repaired. The damage must look big,
the probability of it occurring must look big, and the issue must be easy to repeat.
Thus the tester should not just write an issue on the issues list. The tester should think:
Are there any nearby scenarios, which would make this problem worse? Are there any
more stakeholders interested in this? Is this really the whole problem or is there more in
it? It is again «thinking out of the box». But it may also mean to invent and run some
more test cases. Cem Kaner has presented some excellent material on this cause (Kaner
bugadvoc)
Finally, there are the human issues, about diplomacy, politeness etc. A tester should make
sure not to hurt anyone personally when reporting an issue. Someone said, “Diplomacy is
the art of asking someone to go to hell in such a way that he will enjoy commencing the
journey”.
For every issue (or bug), research more about it!
Make sure you report it as a risk, and as the whole risk!
Defect reporting is a sales job!
Be diplomatic when reporting issues!
The second problem is worse: Sometimes we experience failures, and we cannot recreate
them. I.e. the first time the problem occurs, and the next time it is not there. These issues
are called »intermittent bugs». They are especially difficult if they introduce system
crashes. Upon restarting the system, any corrupted data in the memory may be deleted,
destroying the evidence. In many cases, intermittent bugs are the result of long-term
corruption of some resource or memory. An example is memory leaks. Some function in
the program does not return unused memory when finishing. But because there is a lot of
available memory, this can go on for a long time, until the memory is depleted. It is even
worse if this does not happen every time, but only in very special situations. But also
other resources may be depleted. As an example, the Mars Explorer ceased working after
18 days due to too many files accumulated. (Luckily NASA could download new
software). In many real time embedded systems, the tasks are restarted at certain
intervals, in order to cancel out possible corruption of resources.
The trouble is that ANY shared resource can be corrupted. It comes down to checking the
not very easily visible outputs like the screen: Files, memory pointers, buffers, databases,
messages to remote systems, registry, anything. It could be anything. It could even be the
result of a race condition, which depends on the exact timing of some parallel tasks. It is
easy to see the screen output; everything else requires tools or extra actions from the
tester. This may be too much work to do all the time. And intermittent bugs normally
require a whole sequence of test cases, not just one input and output. Finally, it may be
somewhere in the operating system, in the libraries, in something that is not your fault.
However, if intermittent bugs occur, it is a good idea to be able to rerun the same
sequence of test cases, maybe even with the same timing, and do more checking than
before. James Bach (Bach 2005) has a good guide to investigating such problems:
Strona 38 z 42
39. TESTER.PL
Analyze even intermittent problems!
Log everything you do in testing!
Log everything you see, and look at more remote details!
Make it possible to rerun your tests, with more logging and analysis tools switched
on!
The Tester Has Some Rights
As a tester you have some rights.
Testing is often misused by others to clean up the mess. Instead of thinking beforehand,
the defects are built into the system and the testers have to find them. This is a waste of
both time and effort. A defect found by testers costs many times the effort, which would
have prevented it, if it had been prevented. It also leads to extended time to deliver.
Testers should not be used to clean up, but to measure quality and report risk. It is plainly
the wrong job.
A tester is NOT a vacuum cleaner!
The answer to the problem is using entry criteria. This means forcing the party before to
do the job reasonably well. There are at least two sources where a tester’s Bill of Rights
has been published: Lisa Crispin talks about testers in Extreme Programming Projects.
The most important tester rights are these three:
*
You have the right to make and update your own estimates (…).
*
You have the right to the tools you need to do your job (…).
*
You have the right to expect your project team, not just yourself, to be responsible
for quality.
Tom Gilb (Gilb 2003) developed this list of testers rights (cited with the consent of the
author):
Testers Bill of Rights:
1.
Testers have the right to sample their process inputs, and reject poor quality work
(no entry).
2.
Testers have the right to unambiguous and clear requirements.
3.
Testers have the right to test evolutionarily early as the system increments.
4.
Testers have the right to integrate their test specifications into the other technical
specifications.
5.
Testers have the right to be a party to setting the quality levels they will test to.
6.
Testers have the right to adequate resources to do their job professionally.
7.
Testers have the right to an even workload, and to have a life.
Strona 39 z 42
40. TESTER.PL
8.
Testers have the right to specify the consequences of products that they have not
been allowed to test properly.
9.
Testers have the right to review any specifications that might impact their work.
10.
Testers have the right to focus on testing of agreed quality products, and to send
poor work back to the source.
The last one is the real clue:
Testers should send bad work back to the source!
The Late Night Tester's Toolbox
How should a tester work? What should a tester always keep in mind when working?
One main trouble is to test “everything”. This is far too much. It can never be achieved.
But the tester should have some ideas about what is tested and what not, or what is tested
more or less. That means test coverage.
Very shortly, there are three very basic concepts of coverage, and they can be applied to
any notation, which is a diagram. For example a control flow diagram, a data flow
diagram, a state transition diagram, a call graph, system architecture or a use case.
Basic coverage is executing every box.
The next level is testing every connection.
This should be the minimum when testing. If there is more time, the next level is
combining things, for example pairs of connections.
A tester should be able to state what coverage a test has achieved!
Next, a test should follow the usage profile. This is difficult, especially in module and
subsystem testing. But as a tester, one should at least try to get some idea about how the
object under test will be used. If nothing can be said, the test should be directed at any
use, testing robustness. This means especially test cases for wrong inputs are interesting.
Follow the usage profile if possible!
If not possible, test for robustness against wrong input.
One technique is the basis of most black box testing: Equivalence partitioning. It helps to
save test effort, and it can be applied to derive other test techniques. As a tester, you
should know it, but also be aware that it has caveats: Black box testing may leave out
important aspects. You should also be aware that combination testing is interesting. Lee
Copeland (Copeland 2004) has published a good introduction.
Equivalence partitioning is a good basic technique!
Remember combination testing!
Strona 40 z 42
41. TESTER.PL
Finally, there is all the test material. A worst-case scenario is if the tester has to admit
that the test cannot be done or has been wrong. A big problem is test environment. It
should be prepared and tested early. Waiting for the test environment to work can kill any
testing effort (and everybody else will point fingers!). After that, a defect may not be in
the object under test, but in the test data or the output analysis. Be self-critical!
Test the test environment!
Check you test data!
And finally, there is test automation. A software product should be soft, i.e. easy to
change. But change is a risk. This means there is a need to test after any change.
Retesting and regression testing may help. Running tests by using robots helps regression
testing. But test automation is more than that: Tools may read specifications and
automatically generate test cases. Tools may automatically create environments. Tools
may be used to manage the testing effort and the test material.
Automate testing tasks!
Be aware that there is more automation than using test robots!
Selected References
1. Bach 2005: James Bach. A blog note about possible causes of intermittent bugs:
http://blackbox.cs.fit.edu/blog/james/
2. Beizer 95: Boris Beizer, Black Box Testing, John Wiley, 1995
3. Better Software Magazine, www.bettersoftware.com. www.stickyminds.com
Very practical!
4. BS7925: British Standard: www.testingstandards.co.uk/bs_7925-1.htm
5. Copeland 2004: Lee Copeland, A Practitioner’s Guide to Software Test Design,
Artech House, 2004.
6. Crispin: Lisa Crispin, Tip House, Testing Extreme Programming, AddisonWesley, 2002, also http://home.att.net/~lisa.crispin/XPTesterBOR.htm
7. Gilb 2003: "Testers Rights: What Test should demand from others, and why?".,
Keynote at EuroSTAR 2003
8. GTB: German Testing Board: www.german-testing-board.info The German
Testing Board developed an earlier version of the nowadays-existing ISTQB
certification.
9. IEEE Standards: See www.ieee.org
10. ISEB: Information Systems Examinations Board of British Computer Society.
http://www.bcs.org/BCS/Products/Qualifications/ISEB/ has run a certification
scheme for software testers since 1999.
11. ISTQB: www.istqb.org International Software Testing Qualifications Board.
Develops and runs an international software tester certification scheme.
12. ISTQB Glossary: www.istqb.org/fileadmin/media/glossary-current.pdf
Strona 41 z 42
42. TESTER.PL
13. Kaner 99: C. Kaner, J. Falk, H. Q. Nguyen, “Testing Computer Software (3rd
ed.), John Wiley, 1999.
14. Kaner bugadvoc: A presentation about how a tester should report issues.
http://www.kaner.com/pdfs/BugAdvocacy.pdf
15. Myers 79: Glenford Myers: The Art of Software Testing, John Wiley, 1979.
16. Schaefer 2004; Hans Schaefer, “What Software People should have known about
Software Testing 10 years ago - What they definitely should know today. Why
they still don't know it and don't use it”, EuroSTAR 2004
For Poland, the following books are available in Polish:
1. Glenford Myers "Sztuka testowania oprogramowania" (translated to Polish 2005
and pubished by Helion publ. house)
2. Ron Patton "Testowanie oprogramowania", translated to Polish in 2002,
published by MIKOM.
3. Bogdan Wiszniewski and Bogdan Bereza "Praktyka i teoria testowania
programów", will be published by MIKOM autumn 2005.
Strona 42 z 42