Kuopio. Raportti Rasitustestaus

Samankaltaiset tiedostot
Kuopio Testausraportti Kalenterimoduulin integraatio

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Tik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe LU. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T3

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen Kevät 2016

JHS 180 Paikkatiedon sisältöpalvelut Liite 4 INSPIRE-palvelujen laadun testaus

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU käyttöjärjestelmässä -projekti

T Testiraportti - järjestelmätestaus

TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL Virtuaaliyhteisöjen muodostaminen Versio 1.0

T Testiraportti - integraatiotestaus

Kuopio. Testitapausluettelo: Projektit-osakokonaisuus

Data Sailors - COTOOL dokumentaatio Riskiloki

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

Convergence of messaging

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Vakuutusyhtiöiden testausinfo

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

TESTIRAPORTTI - JÄRJESTELMÄ, ADMIN Virtuaaliyhteisöjen muodostaminen Versio 1.0

TESTIRAPORTTI - XMLREADER LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0

Lohtu-projekti. Testaussuunnitelma

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

@Tampereen Testauspäivät ( )

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

Testaussuunnitelma. Ohjelmistotuotantoprojekti Nero. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

TESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)

Enfo Oyj. Virtualisointi. Case: Eduskunta. Juha-Pekka Leskinen, EDUSKUNTA - Tietohallintotoimisto Markus Sjöman, Enfo Oyj - Zourcing

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

AJAX-konsepti AJAX. Asynkronisuus. Nykyisten web-ohjelmien ongelmia. Asynchronous JavaScript And XML

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS Ti Kandidaatintyö ja seminaari

PS-vaiheen edistymisraportti Kuopio

SOVELLUSALUEEN KUVAUS

Project group Tete Work-time Attendance Software

Määrittelydokumentti NJC2. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Matematiikan tukikurssi

Tehokkaiden strategioiden identifiointi vakuutusyhtiön taseesta

Lohtu-projekti. Testiraportti. Versiohistoria: syklin toteutuksen testit. 1. ajo Virve

FuturaPlan. Järjestelmävaatimukset

Tarkista vielä ennen analysoinnin aloittamista seuraavat seikat:

Projektisuunnitelma Viulu

LOPPURAPORTTI Paperikonekilta Versio 1.0

Menetelmäraportti Ohjelmakoodin tarkastaminen

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri

COTOOL dokumentaatio Testausdokumentit

Fysiikan laboratoriotyöt 1, työ nro: 3, Vastuksen ja diodin virta-jänniteominaiskäyrät

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Harjoitustyö Case - HelpDesk

Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä?

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

Suoritustavat: Laboratoriotöitä 2.-3.periodi. Luennot 2h, Laboratorityöt 4h, itsenäinen työskentely 124 h. Yhteensä 130 h.

Testaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Funktion suurin ja pienin arvo DERIVAATTA,

Valtioneuvoston kanslia VAIN VIRKAKÄYTTÖÖN Hallinto- ja palveluosasto/hallintoyksikkö Terja Ketola PTJ2008-työsuunnitelma 1 (5)

KRYSP-rajapintojen suorituskykytestaukset. Jari Torvinen

OpusCapitan Windows 7 - käyttöönotto. Kimmo Kouhi, varatoimitusjohtaja

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS

Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle

Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Järvitesti Ympäristöteknologia T571SA

Testaajan eettiset periaatteet

Tietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy.

KanTa-palvelut. Sähköisen lääkemääräyksen testauspalvelun suunnitelma. versio 1.0

Fysiikan laboratoriotyöt 1, työ nro: 2, Harmoninen värähtelijä

Matematiikan taito 9, RATKAISUT. , jolloin. . Vast. ]0,2] arvot.

Käyttöohje. Versiohistoria: versio Mari Kommenttien perusteella korjattu versio

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

Onnistunut Vaatimuspohjainen Testaus

ZigBee-ohjaus kuorma-autolle

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

Ohjelmiston toteutussuunnitelma

TAPAHTUMIEN SEURANTA KEHITYSEHDOTUSTEN KIRJAUS POIKKEAMIEN HALLINTA

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen

Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen

Testaussuunnitelma Labra

χ = Mat Sovellettu todennäköisyyslasku 11. harjoitukset/ratkaisut

YKSITTÄISTEN HEITTOJEN HALLINTA/KAS-ELY ANTERO AROLA

Harjoitustyön testaus. Juha Taina

Testit laatueroasteikollisille muuttujille

Kannattaa opetella parametrimuuttujan käyttö muidenkin suureiden vaihtelemiseen.

Internetin hyödyt ja vaarat. Miten nettiä käytetään tehokkaasti hyväksi?

MATHCAD. Kokeilemalla voi tarkistaa tunnistaako MATHCAD halutun kerrannaisyksikön: Siis ei tunnistanut millinewtonia

Algoritmit 1. Luento 3 Ti Timo Männikkö

COTOOL dokumentaatio Riskiloki

RAPORTTI ISOVERIN ERISTEIDEN RADIOTAAJUISTEN SIGNAALIEN VAIMENNUKSISTA

Kiinnostuspohjainen topologian hallinta järjestämättömissä vertaisverkoissa

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Yhteenveto mittareiden ja laskureiden kehittämistyöstä

SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus

2 Yhtälöitä ja epäyhtälöitä

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

Ohjelmiston testaussuunnitelma

SEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant Versio: V0.9

Opponenttitestaus Kuopio

Health Intelligence - Parempaa informaatiota terveydenhuollon päätöksentekoon. Terveydenhuollon ATK päivät Sibelius Talo, Lahti

Transkriptio:

Kuopio Raportti Rasitustestaus

Kuopio, Rasitustestausraportti, 22.4.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 18.4.2002 Matti Peltomäki Ensimmäinen versio 0.9. 18.4.2002 Matti Peltomäki Sisäisen katselmoinnin korjaukset 1.0. 22.4.2002 Matti Peltomäki Asiakaskatselmoinnin korjaukset

1. JOHDANTO...4 2. MENETELMÄT JA TAVOITTEET...4 2.1. YLEISTÄ...4 2.2. SUUNNITTELUSTA...4 2.3. TURVALLISUUSNÄKÖKOHTIA...4 2.4. TIEDONSIIRTOAIKA YHTEYKSIEN FUNKTIONA...4 2.5. PYYNNÖN JONOTUSAIKA YHTEYKSIEN FUNKTIONA...5 2.6. PUUTTEITA...5 3. TOTEUTUKSEN KULKU...6 4. TULOSTEN ANALYSOINTIA...6 4.1. TIEDONSIIRTOAIKA YHTEYKSIEN FUNKTIONA...6 4.2. PYYNTÖJEN JONOSTUSAIKA YHTEYKSIEN FUNKTIONA...6 4.3. HAVAINTOJA...7 4.4. HÄIRIÖTEKIJÖISTÄ...8

1. Johdanto Tämä dokumentti raportoi Kuopio-projektissa suoritetun järjestelmän rasitustestauksen. Dokumentti on tarkoitettu ensisijaisesti projektiryhmälle ja asiakkaalle. Kurssin henkilökunta käyttää dokumenttia kurssiarvostelua varten. Tässä raportissa esitellään kertauksenomaisesti rasitustestauksessa käytetyt menetelmät ja tavoitteet T2-vaiheessa tehtyjen suunnitelmien pohjalta. Suunnitelmissa avoimeksi jätetyt detaljit päivitetään tässä vastaamaan todellisuutta. Lisäksi esitellään lyhyesti testauksen kulku, toteutunut aikataulu ja testausta vaikeuttaneet käytännön tekijät. Viimeisessä luvussa analysoidaan rasitustestauksen tulokset ja pohditaan niiden luotettavuutta. Lisäksi esitetään parannusehdotuksia liittyen edellisessä luvussa kuvattuihin testausta vaikuttaneisiin käytännön asioihin. 2. Menetelmät ja tavoitteet 2.1. Yleistä CenterTest.NET on Microsoftin integroidun kehitysympäristön Visual Studion.NETversion osa. CenterTest on suunniteltu erityisesti www-sivustojen testaukseen. Se on yhteensopiva virtuaalisesti minkä tahansa www-palvelinohjelmiston kanssa, mutta se on suunniteltu erityisesti ASP.NET sovelluksia silmälläpitäen. CenterTest on Kuopio-projektissa kokeiltu testauksen apumenetelmä. Ennen projektia se oli projektiryhmälle aidosti uusi, mutta projektin aikana kaksi ryhmän jäsentä tutustui siihen huolellisesti. Projektissa CenterTestin ominaisuuksista käytettiin mahdollisuutta sivustojen rasitustesteihin, joita CenterTestiin voi ohjelmoida httppyyntökohtaisesti. Muita CenterTestin ominaisuuksia ei resurssipuutteen vuoksi voida ohjelmatyöprojektissa kokeilla. 2.2. Suunnittelusta Testausvastaava tutustui T2-vaiheen aikana huolellisesti ja kattavasti CenterTestin mahdollisuuksiin ja ominaisuuksiin. CenterTestin käyttö suunniteltiin alustavasti myös vaiheessa T2, mutta suunniteltua tarkennettiin radikaalisti LU-vaiheessa. 2.3. Turvallisuusnäkökohtia CenterTestin rasitustestien tarkoituksena on aiheuttaa keinotekoisesti wwwpalvelimelle määrätyn suuruista kuormaa ja samalla tarkkailla yhdeltä tai usealta työasemalta käsin verkon ja palvelimen kuormitusta. Tällainen kuormitus rasittaa suuresti verkkoa, jossa testaus tapahtuu. Tämän vuoksi rasitustestit tehdään sellaiseen vuorokaudenaikaan, jolloin muu liikenne Innofactorin sisäisessä verkossa on pienimmillään. Näin pyritään varmistamaan, että rasitustestit eivät aiheuta huomattavaa haittaa muulle liiketoiminnan kannalta oleelliselle tietoliikenteelle. 2.4. Tiedonsiirtoaika yhteyksien funktiona LU-vaiheessa tarkennettujen suunnitelmien mukaan ensimmäinen rasituksesta tutkittava asia on tiedon siirtämiseen kuluva aika yhteyksien funktiona. Tässä

yhteydessä tiedon siirtämisellä tarkoitetaan pyynnön lähettämisestä joko ensimmäisen tavun perille saapumiseen tarvittavaa aikaa (TTFB = Time To First Byte) tai vastaavaa aikaa laskettuna viimeiseen tavuun asti (TTLB = Time To Last Byte). Testaus suoritettiin useana peräkkäisenä CenterTestin testinä, jossa vaihdellaan yhtäaikaisten yhteyksien määrää esimerkiksi geometrisen jonon 1,2,4,8, mukaisesti. Tuloksista piirrettiin muutama graafi CenterTestin monipuolisten visualisointitoimintojen avulla. Graafit on esitetty luvussa 4. 2.5. Pyynnön jonotusaika yhteyksien funktiona Aiemmin todettiin, että suorituskykyä tarkkailevia apuohjelmia voidaan rasitustestauksen aikana ajaa useammalla samassa verkossa olevalla työasemalla. Tämän kohdan kuvaama menetelmä käyttää hyväkseen tätä seikkaa. Microsoftin Internet Information Services www-palvelinohjelmisto pitää sisällään mainiosti hyödylliseen testaukseen soveltuvia suorituskykyä tarkkailevia apuohjelmia. LU-vaiheessa tarkennettiin rasitustestauksen suunnitelmia, ja tutustuttiin huolellisesti näihin toimintoihin. Toimintojen valtavan kirjon vuoksi ei läheskään kaikkia hyödylliseksi perusteltavissa olevia rasitusmittareita voitu kokeilla, vaan niistä valittiin yksi, jota pyrittiin käyttämään hyväksi mahdollisimman tehokkaasti ja järkevästi. Järjestelmää ajavalle palvelimelle asetettiin suorituskyvyn tarkkailija, joka tutki aikaa, jonka jokainen yksittäinen http-pyyntö viettää palvelimen ylläpitämässä pyyntöjen jonossa ennen kuin se on toteutettu loppuun asti. Jos oletetaan verkkoviiveet ja käyttäjän työasemasta aiheutuvat viiveet mitättömiksi, saadaan tästä hyvä approksimaatio ajalle, joka kuluu käyttäjän lähettämästä pyynnöstä (esimerkiksi napin painamisesta) siihen, että uusi sivu on latautunut käyttäjälle. Juuri tämä aika on erittäin tärkeä käyttömukavuuden mittari. Testauksen periaate on samanlainen kuin edellisessäkin kohdassa. Yhtäaikaisten keinokäyttäjien määrää muutetaan, ja joka kerralla otetaan tilastollista dataa talteen. 2.6. Puutteita CenterTest tarjoaa mahdollisuuden testata sivustoja kuormituksen lisäksi toimivuuden suhteen. Tällainen testaus edellyttää kuitenkin testitapausten laadintaa Visual Basic.NET skriptikielellä. Arvioitu työmäärä on yli tunti testitapausta kohden, ja tulosten luotettavuuden varmistamiseksi vaaditaan lisäksi manuaalista testausta. Näistä syistä ja resurssien vähyyden vuoksi testausta CenterTestillä toiminnallisuuksien suhteen ei toteutettu ohjelmatyöprojektissa. CenterTest laskee testiaineistoista testiajokohtaisesti tilastollisia tunnuslukuja, kuten diskreetin aikakeskiarvon pyyntöjen määrästä aikayksikköä kohden. Saatavien erilaisten tunnuslukujen määrä on kuitenkin varsin rajoitettu. Esimerkiksi testiajokohtaista tai edes kaikkien testiajojen yli laskettua keskihajontaa diskreetin ajan suhteen CenterTest ei laske. Tämä asettaa rajoituksia virheanalyysille, jolla ainoa mahdollinen toteutusmenetelmä on toistokoe. Toistokokeiden toteutusmahdollisuudet ohjelmatyöprojektissa ovat kuitenkin varsin mitättömät, joten tästä syystä virheanalyysi jouduttiin jättämään varsin huonoon asemaan. Tätä on analysoitu lisää luvussa 4.

3. Toteutuksen kulku Rasitustestaus toteutettiin lauantaina 13.4.2002 aamupäivällä. Testaajina toimivat Mikko Lampi ja Matti Peltomäki. Lauantaiaamun valinnalla pyrittiin löytämään ajankohta, jolloin liikenne Innofactorin verkossa olisi tarpeeksi pieni. Kesken testauksen havaittiin, että valinta epäonnistui. Kun testausta oli suoritettu muutama tunti, huomattiin, että toiseen projektiin liittyviä C#-käännöksiä ajettiin fyysisesti samalla palvelimella, jota rasitustestauksessa rasitettiin. Tästä johtuen testauksen loppuosan tulokset eivät ole luotettavia ja niissä esiintyy anomalioita, joille ainoa löydetty järkevä selitys on edellä kuvattu. Testauksessa tutkittiin ensin tiedonsiirtoaikaa yhteyksien lukumäärän funktiona noin kaksi tuntia, sitten pyyntöjen jonotusaikaa hieman yli kaksi tuntia. Testaus aloitettiin 9:50 ja se oli ohi noin 14:10. 4. Tulosten analysointia 4.1. Tiedonsiirtoaika yhteyksien funktiona Ensimmäiseksi tutkittiin tiedonsiirtoaikaa yhteyksien funktiona. Seuraavassa kuvassa on esitetty sekä TTLB että TTFB. Kuvaajasta huomataan selkeä epälineaarinen muoto. Pystyakselin yksikkönä on millisekunti, vaaka-akselin yksikkönä yhtäaikaisten yhteyksien määrä. 4.2. Pyyntöjen jonostusaika yhteyksien funktiona Vastaavalla tavalla piirrettiin graafi pyyntöjen jonostusajasta yhteyksien funktiona. Tällä kertaa CenterTest ei tarjonnut mahdollisuutta piirtää dataa, mutta Microsoft Excelin toimintojen avulla tuloksista saatiin havainnollinen esitys. Kuvaaja on esitetty alla.

Request Wait Time versus Connections 25000 20000 15000 10000 Maximum Average 25 percent ile 50 percent ile 75 percent ile 5000 0 0 100 200 300 400 500 600 Simultaneous Browser Connections Kuvaajaan on piirretty keskiarvojen lisäksi maksimiarvo ja neljännespersentiilit. Hyödyksi on käytetty kaikki CenterTestin tarjoama numeerinen data. Puutteena tässä kohtaa voidaan pitää sitä, että persentiileistä saadaan irti vain neljännespersentiilit mielivaltaisten persentiilien asemesta. Pystyakselin yksikkönä on millisekunti, vaaka-akselin yksikkönä yhtäaikaisten yhteyksien määrä. Tässä kohdassa käytetiin huomattavasti suurempaa suurinta yhtäaikaisten yhteyksien määrää kuin edellisessä kohdassa, millä pyrittiin havaitsemaan mahdollinen epälineaarinen käytös suurilla yhteyksien lukumäärän arvoilla. 4.3. Havaintoja Luvussa 4.1. esitetyssä graafissa on selkeästi epälineaarinen muoto, mutta katsomalla tulosten skaalaa huomataan, että tiedonsiirtoajat pysyvät varsin pieninä pienillä (<100) yhtäaikaisten käyttäjien määrällä. Koska ohjelmiston suunniteltu käyttäjäkunta on PK-yritysten työntekijät, on varsin oletettavaa, että yhdellä resurssienhallintajärjestelmällä ei ole yli sataa yhtäaikaista käyttäjää. Edellinen tulos on luonnollisesti pätevä silloin, kun yhdellä fyysisellä palvelinkoneella ajetaan tasan yhtä resurssienhallintajärjestelmää. Mikäli tulee tapauksia, joissa sama palvelinkone jaetaan useamman järjestelmän kesken, tulee miettiä tulosten pätevyyttä edes lineaarisesti skaalattuna uudelleen. Lisäksi tulos on funktio palvelimen laitteistokonfiguraatiosta. Vastaavasti tilanne, jossa yhden resurssienhallintajärjestelmän kuorma on hajautettu usealle palvelimelle on mahdollinen. Tässä saadut tulokset kertovat lähinnä, että alle sadan yhtäaikaisen käyttäjän järjestelmässä tämä ei ole tarpeellista. Luvussa 4.2. esitettyjen tulosten tulkinta on kumuloituneiden häiriötekijöiden vuoksi huomattavasti hankalampaa. Saatua raakaa numeerista dataa ja sen visualisointia lukuunottamatta, mitään johtopäätöksiä ei liene mahdollista esittää.

4.4. Häiriötekijöistä Luvuissa 2 ja 3 todettiin, että projektin rasistustestausajot kärsivät häiriötekijöistä niiden ennaltaehkäisy-yrityksestä huolimatta. Tässä luvussa kyseiset häiriötekijät on kuvattu yksityiskohtaisesti. Testauksen aika pyrittiin valitsemaan siten, että liikenne verkossa ja palvelimen muu käyttö olisi mahdollisimman vähäistä. Tässä epäonnistuttiin. Testauksen aikana Innofactorissa oli fyysisesti töissä kolme ohjelmoijaa, joista kaikki käyttivät kohteena ollutta palvelinta jollain tavoin ja ainakin yksi ajoi raskaita käännösprosesseja. Häiriötekijöiden varma poistaminen olisi vaatinut tietoa siitä, milloin palvelimella on työkäyttöä ja milloin ei. Tällaista tietoa ei ollut saatavilla.