SlideShare a Scribd company logo

More Related Content

Viewers also liked (11)

Tester.pl - Numer 10
Tester.pl - Numer 10Tester.pl - Numer 10
Tester.pl - Numer 10
 
JMeter – narzędzie testera
JMeter – narzędzie testeraJMeter – narzędzie testera
JMeter – narzędzie testera
 
Certyfikacja ISTQB - fakty i mity
Certyfikacja ISTQB - fakty i mityCertyfikacja ISTQB - fakty i mity
Certyfikacja ISTQB - fakty i mity
 
Ile zarabia tester oprogramowania w 2014?
Ile zarabia tester oprogramowania w 2014?Ile zarabia tester oprogramowania w 2014?
Ile zarabia tester oprogramowania w 2014?
 
60 minut testowania - czyli co tester może osiągnąć w jedną godzinę przy pomo...
60 minut testowania - czyli co tester może osiągnąć w jedną godzinę przy pomo...60 minut testowania - czyli co tester może osiągnąć w jedną godzinę przy pomo...
60 minut testowania - czyli co tester może osiągnąć w jedną godzinę przy pomo...
 
JMeter - narzędzie testera - notatki
JMeter - narzędzie testera - notatkiJMeter - narzędzie testera - notatki
JMeter - narzędzie testera - notatki
 
Testowanie. Wprowadzenie do testowania oprogramowania.
Testowanie. Wprowadzenie do testowania oprogramowania. Testowanie. Wprowadzenie do testowania oprogramowania.
Testowanie. Wprowadzenie do testowania oprogramowania.
 
Agile fakty i mity
Agile fakty i mityAgile fakty i mity
Agile fakty i mity
 
Testy eksploracyjne - podstawy i przykłady
Testy eksploracyjne - podstawy i przykładyTesty eksploracyjne - podstawy i przykłady
Testy eksploracyjne - podstawy i przykłady
 
Testy Jednostokowe
Testy  JednostokoweTesty  Jednostokowe
Testy Jednostokowe
 
Blunders in Test Automation
Blunders in Test AutomationBlunders in Test Automation
Blunders in Test Automation
 

Similar to Tester.pl - Numer 5

testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015
testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015
testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015Radoslaw Smilgin
 
Strefa PMI nr 18, wrzesień 2017
Strefa PMI nr 18, wrzesień 2017Strefa PMI nr 18, wrzesień 2017
Strefa PMI nr 18, wrzesień 2017Strefa PMI
 
Raport User Experience i Product Design w Polsce 2018
Raport User Experience i Product Design w Polsce 2018Raport User Experience i Product Design w Polsce 2018
Raport User Experience i Product Design w Polsce 2018Tomasz Skórski
 
OTC Track Kantar TNS. Oferta na rok 2017
OTC Track Kantar TNS. Oferta na rok 2017OTC Track Kantar TNS. Oferta na rok 2017
OTC Track Kantar TNS. Oferta na rok 2017Kantar TNS S.A.
 
Strefa PMI nr 20, marzec 2018
Strefa PMI nr 20, marzec 2018Strefa PMI nr 20, marzec 2018
Strefa PMI nr 20, marzec 2018Strefa PMI
 
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...Mikolaj Leszczuk
 
Strefa PMI, nr 44, marzec 2024
Strefa PMI, nr 44, marzec 2024Strefa PMI, nr 44, marzec 2024
Strefa PMI, nr 44, marzec 2024Strefa PMI
 
Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5
Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5
Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5krakspot
 
J2EE. Podstawy programowania aplikacji korporacyjnych
J2EE. Podstawy programowania aplikacji korporacyjnychJ2EE. Podstawy programowania aplikacji korporacyjnych
J2EE. Podstawy programowania aplikacji korporacyjnychWydawnictwo Helion
 
Wsparcie, rozwój oraz popularyzacja oprogramowania Open Source
Wsparcie, rozwój oraz popularyzacja oprogramowania Open SourceWsparcie, rozwój oraz popularyzacja oprogramowania Open Source
Wsparcie, rozwój oraz popularyzacja oprogramowania Open Sourcebartekel
 
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) plBiz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) plKATHLEENBULTEEL
 
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) plBiz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) plKATHLEENBULTEEL
 
Analiza FMEA procesu / Zbigniew Huber
Analiza FMEA procesu / Zbigniew HuberAnaliza FMEA procesu / Zbigniew Huber
Analiza FMEA procesu / Zbigniew HuberDarmowe Ebooki
 
Sprzedaj swój program. Droga do udanych projektów programistycznych
Sprzedaj swój program. Droga do udanych projektów programistycznychSprzedaj swój program. Droga do udanych projektów programistycznych
Sprzedaj swój program. Droga do udanych projektów programistycznychWydawnictwo Helion
 
Jakość i wiarygodność OSS
Jakość i wiarygodność OSSJakość i wiarygodność OSS
Jakość i wiarygodność OSSbartekel
 
Strefa PMI nr 17, czerwiec 2017
Strefa PMI nr 17, czerwiec 2017Strefa PMI nr 17, czerwiec 2017
Strefa PMI nr 17, czerwiec 2017Strefa PMI
 
Strefa PMI, nr 40, marzec 2023
Strefa PMI, nr 40, marzec 2023Strefa PMI, nr 40, marzec 2023
Strefa PMI, nr 40, marzec 2023Strefa PMI
 
MediaMon na Microsoft Technology Summit 2011
MediaMon na Microsoft Technology Summit 2011MediaMon na Microsoft Technology Summit 2011
MediaMon na Microsoft Technology Summit 2011MediaMon.pl
 

Similar to Tester.pl - Numer 5 (20)

testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015
testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015
testerzy.pl katalog szkoleń praktycznych dla testerów oprogramowania 2015
 
Strefa PMI nr 18, wrzesień 2017
Strefa PMI nr 18, wrzesień 2017Strefa PMI nr 18, wrzesień 2017
Strefa PMI nr 18, wrzesień 2017
 
Raport User Experience i Product Design w Polsce 2018
Raport User Experience i Product Design w Polsce 2018Raport User Experience i Product Design w Polsce 2018
Raport User Experience i Product Design w Polsce 2018
 
OTC Track Kantar TNS. Oferta na rok 2017
OTC Track Kantar TNS. Oferta na rok 2017OTC Track Kantar TNS. Oferta na rok 2017
OTC Track Kantar TNS. Oferta na rok 2017
 
Strefa PMI nr 20, marzec 2018
Strefa PMI nr 20, marzec 2018Strefa PMI nr 20, marzec 2018
Strefa PMI nr 20, marzec 2018
 
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...
 
Strefa PMI, nr 44, marzec 2024
Strefa PMI, nr 44, marzec 2024Strefa PMI, nr 44, marzec 2024
Strefa PMI, nr 44, marzec 2024
 
Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5
Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5
Open Source - czy aby napewno zło?” - Piotr Pyciński, KrakSpot#5
 
J2EE. Podstawy programowania aplikacji korporacyjnych
J2EE. Podstawy programowania aplikacji korporacyjnychJ2EE. Podstawy programowania aplikacji korporacyjnych
J2EE. Podstawy programowania aplikacji korporacyjnych
 
Wsparcie, rozwój oraz popularyzacja oprogramowania Open Source
Wsparcie, rozwój oraz popularyzacja oprogramowania Open SourceWsparcie, rozwój oraz popularyzacja oprogramowania Open Source
Wsparcie, rozwój oraz popularyzacja oprogramowania Open Source
 
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) plBiz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
 
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) plBiz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
Biz miz o1 m5_u5.2_r7_k(ppt-sdl) pl
 
Lakiernik 714[03] l2.03_u
Lakiernik 714[03] l2.03_uLakiernik 714[03] l2.03_u
Lakiernik 714[03] l2.03_u
 
Analiza FMEA procesu / Zbigniew Huber
Analiza FMEA procesu / Zbigniew HuberAnaliza FMEA procesu / Zbigniew Huber
Analiza FMEA procesu / Zbigniew Huber
 
Jak bardzo techniczny musi być tester?
Jak bardzo techniczny musi być tester?Jak bardzo techniczny musi być tester?
Jak bardzo techniczny musi być tester?
 
Sprzedaj swój program. Droga do udanych projektów programistycznych
Sprzedaj swój program. Droga do udanych projektów programistycznychSprzedaj swój program. Droga do udanych projektów programistycznych
Sprzedaj swój program. Droga do udanych projektów programistycznych
 
Jakość i wiarygodność OSS
Jakość i wiarygodność OSSJakość i wiarygodność OSS
Jakość i wiarygodność OSS
 
Strefa PMI nr 17, czerwiec 2017
Strefa PMI nr 17, czerwiec 2017Strefa PMI nr 17, czerwiec 2017
Strefa PMI nr 17, czerwiec 2017
 
Strefa PMI, nr 40, marzec 2023
Strefa PMI, nr 40, marzec 2023Strefa PMI, nr 40, marzec 2023
Strefa PMI, nr 40, marzec 2023
 
MediaMon na Microsoft Technology Summit 2011
MediaMon na Microsoft Technology Summit 2011MediaMon na Microsoft Technology Summit 2011
MediaMon na Microsoft Technology Summit 2011
 

More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)

More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)

Star Trek: BDD Enterprise
Star Trek: BDD EnterpriseStar Trek: BDD Enterprise
Star Trek: BDD Enterprise
 
Model based testing as a BA tool
Model based testing as a BA toolModel based testing as a BA tool
Model based testing as a BA tool
 
Communication - Language of Leader
Communication - Language of LeaderCommunication - Language of Leader
Communication - Language of Leader
 
Miękkie umiejętności w pracy analityka biznesu
Miękkie umiejętności w pracy analityka biznesuMiękkie umiejętności w pracy analityka biznesu
Miękkie umiejętności w pracy analityka biznesu
 
Błędy w analizie z praktyki (nowe wydanie  )
Błędy w analizie z praktyki (nowe wydanie  )Błędy w analizie z praktyki (nowe wydanie  )
Błędy w analizie z praktyki (nowe wydanie  )
 
7 Skills for highly effective teams - workshop
7 Skills for highly effective teams - workshop7 Skills for highly effective teams - workshop
7 Skills for highly effective teams - workshop
 
Dancing with the devil - how to cooperate with a problematic customer
Dancing with the devil - how to cooperate with a problematic customerDancing with the devil - how to cooperate with a problematic customer
Dancing with the devil - how to cooperate with a problematic customer
 
Cosmic truths about software requirements
Cosmic truths about software requirementsCosmic truths about software requirements
Cosmic truths about software requirements
 
Zagraj w zaangażowanie
Zagraj w zaangażowanieZagraj w zaangażowanie
Zagraj w zaangażowanie
 
Analiza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projektyAnaliza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projekty
 
Internet of Things loves data - analysis of Industry 4.0
Internet of Things loves data - analysis of Industry 4.0Internet of Things loves data - analysis of Industry 4.0
Internet of Things loves data - analysis of Industry 4.0
 
Start with Accessibility: Why, How and What
Start with Accessibility: Why, How and WhatStart with Accessibility: Why, How and What
Start with Accessibility: Why, How and What
 
Agile business analyst
Agile business analystAgile business analyst
Agile business analyst
 
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesuAnalityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
 
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BAJak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
 
7 Skills for highly effective teams
7 Skills for highly effective teams7 Skills for highly effective teams
7 Skills for highly effective teams
 
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
 
[TestWarez 2017] Przychodzi tester na rozmowę...
[TestWarez 2017] Przychodzi tester na rozmowę...[TestWarez 2017] Przychodzi tester na rozmowę...
[TestWarez 2017] Przychodzi tester na rozmowę...
 
[TestWarez 2017] A proper gun makes testing fun
[TestWarez 2017] A proper gun makes testing fun[TestWarez 2017] A proper gun makes testing fun
[TestWarez 2017] A proper gun makes testing fun
 
[TestWarez 2017] Zen testów wydajnościowych
[TestWarez 2017] Zen testów wydajnościowych[TestWarez 2017] Zen testów wydajnościowych
[TestWarez 2017] Zen testów wydajnościowych
 

Tester.pl - Numer 5

  • 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