• Articles
• admin

efterfrågan på att testa Flash/Flex applikationer har blivit mycket mer betydande under de senaste åren. Detta indikerar en ökad användning av denna teknik, vilket i sin tur illustrerar ett behov av automatiserad testning av dessa applikationer. Detta behov väcker dock några frågor och problem, av vilka några kommer att diskuteras i följande artikel.

specifikt är den första frågan som måste besvaras om att automatisera en Flash/Flex-applikation: vilken är rätt Automatiseringsteknik? Det finns två olika sätt att gå:

inbyggd mus & tangentbordsintegration – bra för situationer där det krävs minimal Flashinteraktion.

API-nivå integration – bra för situationer där det finns en hel del Flash interaktion krävs.

inbyggd mus & tangentbordsintegration – det är här en musrörelse, musklick eller tangentbordsåtgärd simuleras på operativsystemnivå. Den återger den mest realistiska användarsimulering genom att spela in GUI – baserade åtgärder, få oss mycket nära ”verkliga livet” användning av vår ansökan. Att använda denna metod har dock vissa problem. Till exempel kräver testning av en Flash-applikation att applikationen och testmiljön förbereds på ett speciellt sätt. Det finns olika sätt att göra din Flash-applikation testbar, beroende på vilket testverktyg som används och utvecklingsmiljö. Vissa verktyg som TestComplete, Rational Robot och QTP kräver att ett dedikerat bibliotek (vanligtvis levereras av verktygets leverantör) bäddas in i Flash-applikationen under kompilering eller vid körning. Detaljerna i denna process kan vanligtvis hittas i dokumentationen av dessa verktyg.

att fånga objekten i en Flex/Flash-applikation är problematisk på egen hand. För att lösa detta finns det två huvudmetoder:

1. fånga skärmen från enheten och anställa bildigenkänning för att lokalisera önskade element på skärmen, automatisera programmet i en svart låda sätt. Aubergine är ett bra exempel på ett verktyg som använder detta tillvägagångssätt. Det är också hur SilkPerformer fungerar i en Citrix-miljö.
2. tolka objekten som används i egenskaper och använd dessa egenskaper för att lokalisera objektet. Detta är samma tillvägagångssätt som används i QTP: s objektförråd. Typiska Blixtobjektegenskaper som tillstånd, namn och text används både för att hitta objekt och verifiera att vissa åtgärder har ägt rum. Rational Robot är ett bra exempel på detta tillvägagångssätt; den använder 11 olika Verifieringspunkter för att verifiera att en viss åtgärd har ägt rum eller verifiera ett objekts tillstånd. Detta tillvägagångssätt är perfekt för dem som vill simulera relativt enkla GUI-interaktioner, som att klicka på en Films ”play” – knapp eller interagera med en bekräftelsedialog, eftersom det i en mer komplicerad applikation tenderar att misslyckas.

API-nivå integration – för applikationer som har mycket mer komplexa Flash/Flex användargränssnitt eller applikationer som är 100% Flash-baserade, det är svårt att använda GUI fånga som presenteras eftersom det kan vara sprött och svårt att bekräfta att den önskade funktionaliteten fungerade. För detta kan man använda API-nivåintegrationen. För att göra denna typ av automatisering måste man kunna kompilera om/ändra de underliggande Flash-objekten.

hur du fortsätter härifrån beror på om du använder Flash eller Flex, eftersom Flex exponerar vissa automations-API: er som annars måste reproduceras om du använder pure Flash. För att göra detta kan man: