PyUseCase

PyUseCase er en GUI test software til PyGTK.
Vedligeholdelse under GUI test med en Use Case Recorder
Optagelse hensigten snarere end mekanik
Den mest naturlige måde at skabe test via en brugergrænseflade er simpelthen at udføre de handlinger, du ønsker at udføre og få et værktøj, der kan optage dem og derefter gengive dem senere. Dette er en enkel og hurtig måde at oprette GUI test, og der findes mange værktøjer, der gør dette.
De fleste værktøjer par testene tæt til GUI
Problemerne starter, når du har et par tests og dine GUI ændringer. Optagelse kan være en fantastisk måde at skabe test, men det er en forfærdelig måde at opretholde et stort antal dem. Det er fejlbehæftet, frustrerende og meget tidskrævende, når du har et par tests. Den første generation af værktøjer indspillet pixelpositioner og brækkede så snart du ændret din skærmopløsning. Dagens værktøjer deal med hensyn til GUI mekanik: finde en tabel med et bestemt navn, og klik i tredje kolonne i fjerde række. De kan overleve screen ændringer og mindre re-arrangementer af GUI, men ikke meget andet. De optagede scripts er tætte og ikke formidle formålet med testen, og er en lukket bog for alle ikke-tekniske folk (og nogle gange til alle undtagen forfatteren af ​​værktøj).
Problemet er i det væsentlige en af ​​kobling. De prøver og GUI er tæt koblet til hinanden og ikke bekvemt kan variere uafhængigt af hinanden. Dette punkt er lavet godt af Robert C. Martin i sin blog her, og hans konklusion er, at GUI test er i sagens natur sprødt, og du bør gøre så lidt af det, som du kan slippe af sted med.
Dette synes temmelig defaitistisk selv. Der er enorm værdi i at kunne vise, hvad din test gøre til en bruger af systemet. Hvis testene omgå brugergrænsefladen så denne proces kræver en rimelig mængde af tekniske færdigheder og en masse tillid fra den del af din bruger. Og alligevel, softwareudviklere løse kobling problemer hele tiden. Svaret er, som sædvanlig, at indføre et andet niveau af indirection.
Breaking koblingen med en UI kort
Erhvervsfolk og brugere generelt arbejder i use cases. Disse er højt niveau beskrivelser af en række af handlinger på et sprog, de forstår: nemlig at af domænet. Ideen om en "Use Case Recorder" er derfor et værktøj, der kan optage og afspille sådanne sekvenser og derved fange hensigten med brugeren. Dette vil så give øget forståelse, mindre afhængighed af den nøjagtige form af GUI og lettere justering af eksisterende tests uden at ty til at klikke alle knapperne igen.
Den grundlæggende mekanisme er, at vi fastholder en mapping mellem de handlinger, der kan i øjeblikket udføres med vores GUI og erklæringer på dette område sprog. GUI ændringer så betyde, at denne enkelte kortlægning skal opdateres, men testene kan forblive uberørt, fortsætter med at beskrive, hvad der skal gøres på det begrebsmæssige plan. Denne kortlægning har form af en ekstern fil i PyUseCase 3.0 og den kommende JUseCase 3,0, mens i ældre versioner det tager form af instrumentering i ansøgningen kode.
Kontrol af adfærd via logfiler og TextTest
Så vores brug-sag optager kan optage og afspille usecases for os. Men hvordan kan vi kontrollere, at det, vi ser på skærmen, er korrekt? De fleste GUI værktøjer gør dette ved at tillade test script til at indeholde "påstande", som ser nogle widget og check, at nogle tilhører det er lig med en hardcodede værdi. Dette skaber endnu mere afhængighed af det aktuelle GUI layout og kan ikke "optaget" på nogen naturlig måde, men har skal programmeres i efter den kendsgerning. Nej "brugertilfælde" ville naturligvis indeholde disse oplysninger: hvis det gjorde det ville blive til en test script.
Denne diskussion er ikke på TextTest stedet for ingenting. Hvis vi kun kan få vores ansøgning til at producere en log over, hvad GUI ser ud som vi kan kontrollere, hvad det gør ved at overvåge indholdet af denne log hjælp TextTest. PyUseCase 3.0 gør dette for dig: det genererer en ASCII-art typen log over den aktuelle GUI udseende og overvåger ændringer. Applikationen kan supplere den med sin egen logning som den ønsker. Med andre use-case-optagere ansøgningen skal bygge sin egen log til dette formål i øjeblikket.
Synkronisering tests ved kode instrumentering
Næsten alle GUI test indsats er plaget af problemer med at sikre manuskriptet venter længe nok, før du fortsætter, når der sker noget i baggrunden. Løsningerne spænder fra mystiske måder at vente nogle widget at have en vis udseende (endnu flere afhængigheder på GUI-mekanik) til "sleep" udsagn gavmildt spredt rundt. Som ikke når systemet er fyldt og forårsage testene til at køre meget langsommere end de ellers ville. Nogen uden indgående kendskab til koden er dårligt rustet til at løse sådanne problemer, men at gøre det er en vital del af skrive tests.
Brug-case-optagere indføre begrebet en "Application Event". Dette er dybest set en vis instrumentering i den kode, der angiver til brugen sag optager, at noget er sket, der skal ventede, således at optageren til at optage og replay venter samt klik. Disse beskrives mere detaljeret her.
Optagelse af makroer samt test
Højt niveau, let manipulerede "usecases" er nyttige for andre ting end test. De er også yderst nyttig for brugere af systemet, som kan oprette deres egne makroer for sekvenser af handlinger, de udfører ofte.
Disse er kendt som "GUI genveje" her. A Brug-tilfælde optager vil typisk give et program til at anmode om et "værktøjslinjen" fra det, som indeholder knapper til optagelse og afspilning dem som kan indsættes i ansøgningen GUI som ønsket. Udover at tillade brugere at oprette makroer, kan de også bruges til at skabe endnu højere abstraktioner niveau for "test sproget" er beskrevet ovenfor, medvirken testere i at udføre gentagne aktioner for at nå et bestemt skærm til test. Disse beskrives mere detaljeret her.
Mere information kan findes på projektets hjemmeside

Hvad er nyt i denne udgivelse:.

• Meget grundlæggende støtte til wxPython var tilføjet.
• Der er også en række forbedringer og fejlrettelser til PyGTK. Især er gtk.Dialog.run understøttes nu uden at kræve kildekode ændringer.
• Python 2.6 og PyGTK 2.12 eller nyere kræves nu.
• Arven instrumentering-baseret interface er blevet fjernet.

Krav :

• Python
• PyGTK
• TextTest