• Articles
• admin

efterspørgslen efter test af Flash/Fleksprogrammer er blevet meget mere markant i løbet af de sidste par år. Dette indikerer en udvidelse af brugen af denne teknologi, hvilket igen illustrerer et behov for automatiseret test af disse applikationer. Dette behov rejser imidlertid et par spørgsmål og problemer, hvoraf nogle vil blive diskuteret i den følgende artikel.

specifikt er det første spørgsmål, der skal besvares om automatisering af en Flash/Fleksapplikation: hvilken er den rigtige automatiseringsteknik? Der er to forskellige måder at gå:

indbygget mus & tastaturintegration – god til situationer, hvor der kræves minimal Flashinteraktion.

API-niveau integration – god til situationer, hvor der kræves meget Flashinteraktion.

indbygget mus & tastaturintegration – det er her en musebevægelse, museklik eller tastaturhandling simuleres på operativsystemniveau. Det gengiver den mest realistiske brugersimulering ved at optage GUI-baserede handlinger og få os meget tæt på “det virkelige liv” brug af vores applikation. Brug af denne metode har dog nogle problemer. For eksempel kræver test af en Flash-applikation, at applikationen og testmiljøet forberedes på en særlig måde. Der er forskellige måder at gøre din Flash-applikation testbar, afhængigt af det anvendte testværktøj og udviklingsmiljø. Nogle værktøjer såsom TestComplete, rationel Robot og ktp kræver, at et dedikeret bibliotek (normalt leveret af værktøjets leverandør) integreres i Flash-applikationen under kompilering eller på kørselstid. Detaljerne i denne proces kan typisk findes i dokumentationen af disse værktøjer.

optagelse af objekterne i en fleks/Flash-applikation er problematisk alene. For at løse dette er der to hovedmetoder:

1. Optag skærmen fra enheden og brug billedgenkendelse til at finde de ønskede elementer på skærmen og automatisere applikationen på en sort boks måde. Aubergine er et godt eksempel på et værktøj, der bruger denne tilgang. Det er også, hvordan SilkPerformer fungerer i et Citriks miljø.
2. Parse de objekter, der bruges i egenskaber og bruge disse egenskaber til at lokalisere objektet. Dette er den samme tilgang, der bruges i ktp ‘ s objektlagre. Typiske Flashobjektegenskaber som tilstand, navn og tekst bruges både til at lokalisere objekter og kontrollere, at visse handlinger har fundet sted. Rationel Robot er et godt eksempel på denne tilgang; den bruger 11 forskellige Verifikationspunkter til at verificere, at en bestemt handling har fundet sted, eller verificere et objekts tilstand. Denne tilgang er perfekt til dem, der ønsker at simulere relativt enkle GUI-interaktioner, såsom at klikke på en films “play” – knap eller interagere med en bekræftelsesdialog, som på en mere kompliceret applikation har denne tilgang en tendens til at mislykkes.

API-niveau integration – for applikationer, der har meget mere komplekse Flash/Fleksbaserede brugergrænseflader eller applikationer, der er 100% flashbaserede, er det svært at bruge GUI-optagelse som præsenteret, da det kan være skørt og vanskeligt at bekræfte, at den ønskede funktionalitet fungerede. Til dette kan man bruge API-niveauintegrationen. For at udføre denne type automatisering skal man være i stand til at kompilere/ændre det / de underliggende Flashobjekt(er).

hvordan du fortsætter herfra afhænger af, om du bruger Flash eller fleks, da fleks udsætter nogle automatiserings-API ‘ er, der ellers skal gengives, hvis du bruger ren Flash. For at gøre dette kan man: