PyUseCase

PyUseCase is een GUI testen van software voor PyGTK.
Onderhoudbaar GUI testen met een Use Case Recorder
Het opnemen van de opzet in plaats van de mechanica
De meest natuurlijke manier om tests te maken via een gebruikersinterface is om gewoon het uitvoeren van de acties die u wilt uitvoeren en hebben een tool die hen kan opnemen en dan later te reproduceren hen. Dit is een eenvoudige en snelle manier om GUI tests te maken en er uiteenlopende instrumenten die dit doen.
Meest gereedschappen paar tests vast aan de GUI
De problemen beginnen wanneer je een paar testen en uw GUI veranderingen. De opname kan een geweldige manier om tests te maken, maar het is een vreselijke manier om grote aantallen van hen te houden. Het is foutgevoelig, frustrerend en zeer tijdrovend als je eenmaal een paar tests. De eerste generatie van gereedschappen opgenomen pixel posities en brak zodra u uw schermresolutie veranderd. Gereedschap deal van vandaag op het gebied van de GUI mechanica: een tafel met een bepaalde naam en klik in de derde kolom van de vierde rij. Ze kunnen het scherm verandert en kleine re-regelingen van de GUI overleven, maar niet veel anders. De opgenomen scripts zijn dicht en het doel van de test niet overbrengen, en zijn een gesloten boek voor alle niet-technische mensen (en soms aan iedereen behalve de auteur van het gereedschap).
Het probleem is in wezen een koppeling. De tests en de GUI zijn nauw met elkaar gekoppeld en kunnen niet gemakkelijk variëren onafhankelijk van elkaar. Dit punt wordt goed gemaakt door Robert C. Martin in zijn blog hier en zijn conclusie is dat de GUI testen is inherent bros en je moet zo weinig van doen wat je weg kunnen komen.
Dit lijkt nogal defaitistische wel. Er is grote waarde kunnen aantonen wat uw tests aan een gebruiker van het systeem. Als de tests te omzeilen de gebruikersinterface dan dat proces vraagt ​​om een ​​eerlijk bedrag van de technische vaardigheid en veel vertrouwen van de kant van uw gebruiker. En toch, software-ontwikkelaars te lossen koppeling problemen de hele tijd. Het antwoord is, zoals gebruikelijk, op een ander niveau van indirectheid introduceren.
Het doorbreken van de koppeling met een UI kaart
Mensen uit het bedrijfsleven en de gebruikers over het algemeen werken in use cases. Deze zijn van hoog niveau beschrijvingen van een opeenvolging van handelingen in een taal die zij begrijpen: dat wil zeggen dat van het domein. Het idee van een "Use Case Recorder" is dus een instrument dat kan opnemen en afspelen dergelijke sequenties en daarmee de bedoeling van de gebruiker vast te leggen. Dit zal dan mogelijk verhoogd begrip, minder afhankelijkheid van de exacte vorm van de GUI en gemakkelijker aanpassing van de bestaande tests zonder toevlucht te klikken alle knoppen opnieuw.
Het basismechanisme is dat we handhaven van een mapping tussen de acties die thans kunnen worden uitgevoerd met onze GUI en verklaringen in deze domeintaal. GUI veranderingen dan betekenen dat deze single mapping moet worden bijgewerkt, maar de tests kunnen onaangetast blijven, blijven beschrijven wat te worden gedaan op het conceptuele niveau nodig. Deze mapping heeft de vorm van een extern bestand in PyUseCase 3.0 en de komende JUseCase 3,0, terwijl in oudere versies het de vorm van instrumenten in de applicatie code.
Controle van het gedrag via logs en TextTest
Dus onze use-case recorder kan opnemen en afspelen Usecases voor ons. Maar hoe kunnen we controleren dat wat we zien op het scherm juist is? De meeste GUI gereedschap dit doen doordat de test script "beweringen", die opzoeken enkele widget en controleer of andere eigenschap van het is gelijk aan een hardcoded waarde bevatten. Dit creëert nog meer afhankelijk van de huidige grafische layout en kan niet worden "geregistreerd" op een natuurlijke wijze, maar moet worden geprogrammeerd achteraf. Nee "Antwoordcode" zou bevatten van nature deze informatie: als het deed het zou veranderen in een test script.
Deze discussie is niet op de TextTest site voor niets. Als we alleen kunnen krijgen onze applicatie om een ​​logboek bij van wat de GUI lijkt erop dat we kunnen controleren wat het doet door het toezicht op de inhoud van die log gebruik TextTest produceren. PyUseCase 3.0 doet dit voor u: het genereert een ASCII-art soort logboek van de huidige GUI verschijning en bewaakt veranderingen aan. De applicatie kan aanvullen met eigen logging als het wil. Met andere use-case recorders moet de toepassing op zijn eigen log te bouwen voor dit doel nu.
synchroniseren testen door code instrumentatie
Bijna alle GUI testen inspanningen worden geplaagd door problemen met het maken van zorgen dat het script lang genoeg wacht alvorens verder te gaan als er iets gebeurt op de achtergrond. De oplossingen variëren van geheimzinnige manieren om te wachten voor een aantal widget om een ​​bepaald uiterlijk (nog meer afhankelijkheden GUI-mechanica) moeten "slaap" verklaringen vrijelijk rond verspreid. Die niet wanneer het systeem wordt geladen, waardoor de proeven veel trager dan anders het geval zou zijn. Iedereen zonder grondige kennis van de code is slecht uitgerust om dergelijke problemen op te lossen, maar te doen is een essentieel onderdeel van het schrijven van tests.
Use-case Recorders introduceren het concept van een "Application Event". Dit is in principe een aantal instrumenten in de code die aangeeft in de gebruikslaag case recorder die iets is gebeurd dat moet worden gewacht, zodat de recorder opnemen en afspelen wacht en klikken. Deze worden in meer detail here.
Opname macro's, evenals testen
Op hoog niveau, gemakkelijk te manipuleren "Usecases" zijn nuttig voor andere dingen dan het testen. Ze zijn ook zeer nuttig voor de gebruikers van het systeem die hun eigen macro's kunnen creëren voor sequenties van acties die zij vaak uit te voeren.
Deze staan ​​bekend als "GUI snelkoppelingen" hier. Een use-case recorder zal doorgaans toestaan ​​dat een toepassing om te vragen een "toolbar" van het welke controles voor het opnemen en afspelen van hen, die naar wens kunnen worden ingevoegd in de applicatie GUI bevat. Naast zodat gebruikers macro's, kunnen ze ook worden gebruikt om nog hoger niveau abstracties scheppen voor de "test language" hierboven beschreven, helpen testers uitvoeren herhaalde maatregelen om een ​​bepaald scherm bereiken voor testen. Deze worden in meer detail here.
Meer informatie is te vinden op de project homepage

Wat is nieuw in deze release:.

• Zeer basisondersteuning voor wxPython was toegevoegd.
• Er zijn ook een aantal verbeteringen en bugfixes voor PyGTK. Met name wordt gtk.Dialog.run nu ondersteund zonder dat de broncode verandert.
• Python 2.6 en PyGTK 2.12 of hoger zijn nu verplicht.
• De legacy-instrumenten gebaseerde interface is verwijderd.

Eisen

• Python
• PyGTK
• TextTest