PyUseCase

PyUseCase er et GUI testing programvare for PyGTK.
vedlikeholds GUI testing med en Bruk sak opptaker
Opptak hensikten heller enn mekanikerne
Den mest naturlige måten å lage tester via et brukergrensesnitt er å bare utføre de handlingene du ønsker å utføre og ha et verktøy som kan ta dem og deretter gjenskape dem senere. Dette er en enkel og rask måte å lage GUI tester, og det finnes mange verktøy som gjør dette.
De fleste verktøy par testene tett til GUI
Problemene starter når du har et par tester og dine GUI endringer. Opptak kan være en fin måte å lage tester, men det er en forferdelig måte å opprettholde et stort antall dem. Det er utsatt for feil, frustrerende og tidkrevende når du har noen tester. Den første generasjonen av verktøy registrert pikselposisjoner og brøt så snart du har endret skjermoppløsningen. Dagens verktøy avtale i form av at de grafiske mekanikere: finne et bord med et bestemt navn, og klikk på den tredje kolonnen i fjerde rad. De kan overleve skjermen endres og mindre re-arrangementer av det grafiske brukergrensesnittet, men ikke mye annet. De registrerte skript er tett og ikke formidle formålet med testen, og er i en lukket bok for alle ikke-tekniske mennesker (og noen ganger til alle bortsett forfatteren av verktøyet).
Problemet er i det vesentlige en av koplingen. Testene og GUI er tett koblet til hverandre og kan ikke godt variere uavhengig av hverandre. Dette punktet er laget godt av Robert C. Martin i sin blogg her og hans konklusjon er at GUI testing er iboende sprø og du bør gjøre så lite av det som du kan komme unna med.
Dette synes heller defeatist skjønt. Det er stor verdi i å kunne vise hva testene gjør en bruker av systemet. Hvis testene omgå brukergrensesnittet da at prosessen krever en god del teknisk innsikt og stor tillit fra den delen av brukeren. Og uansett, programvareutviklere løse koblings problemer hele tiden. Svaret er, som vanlig, å innføre en annen indirekte nivå.
Bryte koblingen med en UI kart
Forretningsfolk og brukere generelt arbeide i bruk tilfeller. Dette er høyt nivå beskrivelser av en rekke handlinger på et språk de forstår: det vil si at av domenet. Ideen om en "Use case Recorder" er derfor et verktøy som kan ta opp og spille av slike sekvenser og dermed fange hensikten med brukeren. Dette vil da gi økt forståelse, mindre avhengighet av den eksakte formen av GUI og enklere justering av eksisterende tester uten å ty til å klikke alle knappene igjen.
Den grunnleggende mekanismen er at vi opprettholder en mapping mellom handlinger som kan i dag utføres med vår GUI og uttalelser i dette domenet språk. GUI endringer da bety at denne ene kartleggingen må oppdateres, men testene kan forbli urørt, fortsetter å beskrive hva som må gjøres på konseptnivå. Denne kartleggingen tar form av en ekstern fil i PyUseCase 3.0 og den kommende JUseCase 3,0, mens i eldre versjoner det tar form av instrumentering i applikasjonskoden.
Kontroll av atferd via logger og TextTest
Så vår bruk-case spilleren kan ta opp og spille Use Cases for oss. Men hvordan kan vi sjekke at det vi ser på skjermen er riktig? De fleste GUI-verktøy gjør dette ved å la testskriptet til å inneholde "påstander", som ser opp noen widget og sjekk at noen eiendom av det er lik en hardkodet verdi. Dette skaper enda mer avhengighet av dagens GUI layout og kan ikke "tatt opp" på noen naturlig måte, men må programmeres i ettertid. Ingen "usecase" ville naturligvis inneholde denne informasjonen: hvis det gjorde det ville bli en test script.
Denne diskusjonen er ikke på TextTest stedet for ingenting. Hvis vi bare kan få vår søknad til å produsere en logg over hva GUI ser ut som vi kan sjekke hva den gjør ved å overvåke innholdet som log hjelp TextTest. PyUseCase 3.0 gjør dette for deg: den genererer en ASCII-art måler av dagens GUI utseende og overvåker endringer i den. Søknaden kan supplere den med sin egen hogst som den ønsker. Med andre bruk-case-opptakere programmet trenger for å bygge sin egen logg for dette formålet i dag.
Synkronisere tester av kode instrumentering
Nesten alle GUI testing innsats er plaget av problemer med å sørge for manuset venter lenge nok før du fortsetter når noe skjer i bakgrunnen. Løsningene spenner fra uforståelige måter å vente på noen widget til å ha et visst utseende (enda flere avhengigheter på GUI-mekanikk) til "sleep" uttalelser liberalt spredt rundt. Som svikter når systemet er lastet og føre prøvene til å kjøre mye saktere enn de ellers ville. Noen uten inngående kjennskap til koden er dårlig rustet til å løse slike problemer, men å gjøre det er en viktig del av å skrive tester.
Use-case-opptakere introdusere begrepet en "Application hendelse". Dette er i utgangspunktet noe instrumentering i koden som indikerer til bruk-case-opptaker at noe har skjedd som må ventet på, og dermed gir opptakeren til å ta opp og replay venter samt klikk. Disse er beskrevet i større detalj her.
Opptaks makroer samt tester
Høyt nivå, lett manipulert "Use Cases" er nyttige for andre ting enn testing. De er også svært nyttig for brukere av systemet som kan lage sine egne makroer for sekvenser av handlinger de utfører ofte.
Disse er kjent som "GUI snarveier" her. En Use-case opptakeren vil vanligvis tillate et program å be om en "verktøylinje" fra det som inneholder kontroller for opptak og avspilling dem som kan settes inn i programmet GUI som ønsket. Dessuten tillater brukere å lage makroer, kan de også brukes til å lage enda høyere nivå abstractions for "test language" som er beskrevet ovenfor, hjelpe testere i å utføre gjentatte handlinger for å oppnå en viss skjerm for testing. Disse er beskrevet i større detalj her.
Mer informasjon finnes på prosjektets hjemmeside

Hva er nytt i denne utgaven.

• Svært grunnleggende støtte for wxPython var lagt til.
• Det finnes også en rekke forbedringer og feilrettinger for PyGTK. Spesielt er gtk.Dialog.run støttes nå uten å kreve kildekode endringer.
• Python 2.6 og PyGTK 2.12 eller senere er nå pålagt.
• Arven instrumentering basert grensesnitt er fjernet.

Krav

• Python
• PyGTK
• TextTest