Test af mobilapps: Eksempel på testscenarier og testscenarier

Et ofte stillet spørgsmål fra vores elever er, hvordan man tester mobilapps. Nedenfor er eksempler testscenarier og testcases til en mobilapplikation.

Du kan udføre nogle eller alle disse testcases baseret på dine mobil test krav. Casene er organiseret efter mobil testtype.

Funktionstest af mobilapplikation

Funktionstest af en mobilapplikation er processen med at teste appens funktionalitet, herunder brugerinteraktioner og de transaktioner, en bruger måtte udføre. Formålet er at sikre kvalitet, opfylde de specificerede forventninger, reducere risikoen for fejl og holde kunderne tilfredse.

De forskellige faktorer, der er relevante i funktionel testning, er:

1. Applikationstype baseret på brugen af ​​forretningsfunktionalitet (bank, spil, social eller forretning)
2. Target målgruppetype (forbruger, virksomhed, uddannelse)
3. Distributionskanal, der bruges til at sprede applikationen (f.eks. Apple App Store, Google Spil, direkte distribution)

Disse faktorer bestemmer, hvor dybt hvert område nedenfor går, som diagrammet viser.

De mest grundlæggende testscenarier i funktionel testning kan betragtes som:

1. For at validere, om alle de obligatoriske obligatoriske felter fungerer som påkrævet.
2. For at validere, at de obligatoriske felter vises på skærmen på en måde, der adskiller sig fra de ikke-obligatoriske felter.
3. At validere, om applikationen fungerer som kravet, hver gang den starter eller stopper.
4. For at validere, om applikationen går i minimeret tilstand, når der er et indgående telefonopkald. For at validere dette skal du bruge en anden telefon til at ringe til enheden. Dette er kernen i afbrydelsestest.
5. For at validere om telefonen kan gemme, behandle og modtage SMS'er, når appen kører. For at validere dette skal du bruge en anden telefon til at sende en SMS til den enhed, der testes, og som den testede applikation i øjeblikket kører på.
6. For at validere, at enheden er i stand til at udføre den nødvendige multitasking, når det er nødvendigt.
7. For at validere, at applikationen tillader nødvendige sociale netværksfunktioner såsom deling, opslag og navigation.
8. For at validere, at applikationen understøtter enhver betalingsgateway-transaktion såsom Visa, Mastercard eller PayPal, som krævet af applikationen.
9. For at validere, at scenarierne for sidevisning er aktiveret i applikationen efter behov.
10. At validere, at navigationen mellem relevante moduler i applikationen er i overensstemmelse med kravene.
11. For at validere, at afkortningsfejl holdes på en overkommelig grænse.
12. For at bekræfte, at brugeren modtager en passende fejlmeddelelse, f.eks. "Netværksfejl. Prøv igen senere", når der er en netværksfejl.
13. At validere, at den installerede applikation gør det muligt for andre applikationer at fungere tilfredsstillende, og at den ikke bruger hukommelsen i de andre applikationer.
14. For at validere, at applikationen genoptages ved sidste operation i tilfælde af en hård genstart eller systemnedbrud.
15. At validere, om installationen af ​​applikationen kan udføres problemfrit, forudsat at brugeren har de nødvendige ressourcer, og at det ikke fører til væsentlige fejl.
16. For at validere, at applikationen udfører automatisk start i henhold til kravene.
17. At validere, om applikationen fungerer i henhold til kravene på alle generationer af mobilnetværk, det vil sige 3G, 4G og 5G.
18. At optræde Regressionstest at afdække nye softwarefejl i eksisterende områder af et system, efter at der er foretaget ændringer i dem. Genudfør også tidligere udførte tests for at fastslå, at programmets adfærd ikke har ændret sig på grund af ændringerne.
19. For at validere, om applikationen tilbyder en brugervejledning til dem, der ikke er bekendt med appen.

Testcases til præstationstest

Når funktionerne opfører sig korrekt, er spørgsmålet, om de holder under belastning.

Det grundlæggende mål med denne type testning er at sikre, at applikationen fungerer acceptabelt under bestemte ydeevnekrav, såsom adgang for et stort antal brugere eller fjernelse af en central infrastrukturdel som en databaseserver.

De generelle testscenarier for test af ydeevne i en mobilapplikation er:

1. For at bestemme, om applikationen fungerer i henhold til kravet under forskellige belastningsforhold.
2. For at afgøre, om den aktuelle netværksdækning er i stand til at understøtte applikationen på spids-, gennemsnits- og minimumsbrugerniveauer.
3. For at afgøre, om den eksisterende klient-server-konfiguration giver det nødvendige optimale ydeevneniveau.
4. At identificere de forskellige flaskehalse i applikationer og infrastruktur, der forhindrer applikationen i at fungere på de krævede acceptniveauer.
5. For at validere om applikationens svartid lever op til kravene.
6. At evaluere produkt og/eller hardware for at afgøre, om det kan håndtere forventede belastningsmængder.
7. At vurdere, om batteriets levetid kan understøtte applikationen under forventede belastningsvolumener.
8. At validere applikationens ydeevne, når netværket ændres til Wi-Fi fra 4G/5G eller omvendt.
9. For at validere, at hver af de nødvendige CPU-cyklusser er optimeret.
10. For at validere, at batteriforbrug, hukommelseslækager og ressourcer som GPS og kameraets ydeevne ligger inden for de krævede retningslinjer.
11. For at validere applikationens levetid, når brugerbelastningen er streng.
12. For at validere netværkets ydeevne, mens du bevæger dig rundt med enheden.
13. At validere applikationens ydeevne, når kun intermitterende faser af forbindelse er tilgængelige.

Sikkerhedstests testcases

Ydeevne og sikkerhed overlapper hinanden: den lokale lagring, der øger hastigheden på en app, er det, en angriber læser først.

Det grundlæggende formål med sikkerhedstest er at sikre, at applikationens data- og netværkssikkerhedskrav er opfyldt i henhold til retningslinjerne.

Følgende er de mest afgørende områder for kontrol af sikkerheden af ​​mobilapplikationer.

1. At validere, at applikationen er i stand til at modstå ethvert brute-force-angreb, som er en automatiseret proces med trial and error, der bruges til at gætte en persons brugernavn, adgangskode eller kreditkortnummer.
2. At validere, at applikationen ikke tillader en angriber at få adgang til følsomt indhold eller funktioner uden korrekt godkendelse.
3. At validere, at applikationen har et stærkt adgangskodebeskyttelsessystem, og at det ikke tillader en angriber at indhente, ændre eller gendanne en anden brugers adgangskode.
4. For at bekræfte, at applikationen ikke lider af utilstrækkelig sessionsudløb.
5. At identificere de dynamiske afhængigheder og træffe foranstaltninger for at forhindre angribere i at få adgang til disse sårbarheder.
6. At forhindre SQL injektionsrelaterede angreb.
7. At identificere og gendanne fra eventuelle uadministrerede kodescenarier.
8. For at sikre, at certifikaterne er validerede, og for at kontrollere, om applikationen implementerer certifikatfastgørelse.
9. For at beskytte applikationen og netværket mod denial of service-angreb.
10. At analysere kravene til datalagring og datavalidering.
11. For at aktivere sessionsstyring for at forhindre uautoriserede brugere i at få adgang til uopfordrede oplysninger.
12. For at kontrollere, om en kryptografisk kode er brudt, og sikre, at den er repareret.
13. At validere, at implementeringen af ​​forretningslogik er sikret og ikke sårbar over for angreb udefra.
14. For at analysere filsysteminteraktioner skal du bestemme enhver sårbarhed og rette disse problemer.
15. At validere protokolhåndteringerne, for eksempel ved at forsøge at omkonfigurere standardlandingssiden for applikationen ved hjælp af en ondsindet iframe.
16. For at beskytte mod ondsindede injektioner på klientsiden.
17. For at beskytte mod ondsindede runtime-injektioner.
18. For at undersøge filcache og forhindre eventuelle ondsindede muligheder fra det samme.
19. For at forhindre usikker datalagring i programmernes tastaturcache.
20. At undersøge cookies og forhindre ondsindede handlinger fra cookies.
21. At levere regelmæssige revisioner til databeskyttelsesanalyse.
22. At undersøge brugerdefinerede filer og forhindre ondsindede handlinger fra de brugerdefinerede filer.
23. For at forhindre bufferoverløb og tilfælde af hukommelseskorruption.
24. At analysere forskellige datastrømme og forebygge eventuelle sårbarheder fra disse.

Usability Testing Test Cases

En sikker app, som ingen kan betjene, fejler stadig, så brugervenligheden står på sidelinjen ved siden af ​​de tekniske kontroller.

Brugbarhedstestprocessen for en mobilapplikation udføres for at producere en hurtig og nem applikation med færre funktioner i stedet for en langsom og vanskelig applikation med mange funktioner. Hovedformålet er at ende med en brugervenlig og intuitiv brugerflade, der ligner de brancheaccepterede brugerflader, der er bredt anvendte.

1. For at sikre, at knapperne har den nødvendige størrelse og er egnede til store fingre.
2. For at sikre at knapperne er placeret i samme del af skærmen for at undgå at forvirre slutbrugerne.
3. For at sikre, at ikonerne er naturlige og i overensstemmelse med applikationen.
4. For at sikre at knapper, der har samme funktion, også har samme farve.
5. For at sikre, at valideringen for hanenping Zoom ind og zoom ud er aktiveret.
6. For at sikre, at tastaturindgangen kan minimeres på en passende måde.
7. For at sikre, at applikationen giver en metode til at gå tilbage eller fortryde en handling ved berøring af det forkerte element inden for en acceptabel varighed.
8. For at sikre at kontekstmenuerne ikke overbelastes, fordi de skal bruges hurtigt.
9. For at sikre at teksten holdes enkel og tydelig, så den er synlig for brugerne.
10. For at sikre at korte sætninger og afsnit er læselige for slutbrugerne.
11. For at sikre, at skriftstørrelsen er stor nok til at være læsbar og ikke for stor eller for lille.
12. For at validere, at applikationen spørger brugeren, hver gang brugeren begynder at downloade en stor mængde data, hvilket muligvis ikke er befordrende for applikationens ydeevne.
13. At validere, at lukningen af ​​applikationen udføres fra forskellige tilstande, og verificere, om den genåbnes i samme tilstand.
14. For at sikre, at alle strenge konverteres til de relevante sprog, når en sprogoversættelsesfunktion er tilgængelig.
15. For at sikre, at applikationselementerne altid er synkroniseret i henhold til brugerhandlingerne.
16. For at sikre, at slutbrugeren får en brugermanual, der hjælper slutbrugeren med at forstå og betjene applikationen, hvis de ikke er bekendt med, hvordan den fungerer.

Brugervenlighedstest udføres normalt af manuelle brugere, da kun mennesker kan forstå andre brugeres følsomhed og komfort.

Testtilfælde af kompatibilitetstest

Det samme build skal opføre sig identisk på hardware, som holdet måske aldrig har haft.

Kompatibilitetstest på mobile enheder udføres, fordi mobile enheder har forskellige størrelser, opløsninger, skærme, versioner og hardware, så applikationen bør testes på tværs af alle enheder for at sikre, at den fungerer som ønsket.

Følgende er de mest fremtrædende områder for kompatibilitetstestning.

1. At validere, at applikationens brugergrænseflade matcher enhedens skærmstørrelse, og at ingen tekst eller kontrolelementer er delvist usynlige eller utilgængelige.
2. For at sikre at teksten er læsbar for alle brugere af applikationen.
3. For at sikre, at opkalds- og alarmfunktionen er aktiveret, når applikationen kører. Applikationen minimeres eller suspenderes ved et opkald, og når opkaldet stopper, genoptages applikationen.

Testtilfælde af genanvendelighedstest

Gendannelsestest dækker gendannelse efter nedbrud og transaktionsafbrydelser – hvad applikationen gør, når enheden, batteriet eller forbindelsen afbrydes midt i en transaktion.

1. Validering af den effektive applikationsgendannelsessituation efter uventede afbrydelser eller nedbrudsscenarier.
2. Verifikation af, hvordan applikationen håndterer en transaktion under strømsvigt (dvs. hvis batteriet dør, eller enheden lukkes ned manuelt).
3. Valideringen af ​​processen, hvor forbindelsen er suspenderet, og systemet skal genetablere den for at gendanne de data, der er direkte påvirket af den suspenderede forbindelse. Brug af den rigtige mobile testværktøjer hjælper med at sikre en problemfri genopretningsproces.

Vigtig tjekliste til test af mobilapplikationer

En håndfuld tjek dækker alle ovenstående kategorier og er lette at glemme.

1. Installationstest (om applikationen kan installeres inden for en rimelig tid og med de nødvendige kriterier)
2. Afinstallationstest (om applikationen kan afinstalleres inden for en rimelig tidsperiode og med de nødvendige kriterier)
3. Netværkstesttilfælde (validering af, om netværket yder under den krævede belastning, og om netværket er i stand til at understøtte alle nødvendige applikationer under testprocedurerne)
4. Tjek ikke-tilknyttede nøgler
5. Tjek applikationens velkomstskærm
6. Fortsat tastaturindtastning under afbrydelser og på andre tidspunkter, f.eks. ved netværksproblemer
7. Metoder, der handler om at forlade applikationen
8. Opladereffekt, mens et program kører i baggrunden
9. Lavt batteri og høj ydeevne krav
10. Fjernelse af batteriet, mens en applikation kører
11. Batteriforbrug fra applikationen
12. Tjek bivirkningerne ved applikationen

Ofte Stillede Spørgsmål