Vejledning til spiltestning: Sådan tester du mobil-/desktopapps

⚡ Smart opsummering

Spiltestning er den kvalitetskontrolproces, der anvendes i videospil, og som har til formål at finde defekter i gameplay, grafik, lyd og netværk, så den version, der leveres til spillerne, forbliver stabil, kompatibel og underholdende.

  • 🔘 Tre livscyklusfaser: Præproduktion, produktion samt test og implementering har hver deres egne verifikationsaktiviteter.
  • ☑️ Ni kernetyper: Funktionalitet, kompatibilitet, ydeevne, overholdelse, lokalisering, soak, recovery, sikkerhed og multiplayer-tjek udgør standardpakken.
  • Gentagende af natur: Enhver nybyggeri kan introducere defekter igen, så testdokumenter gennemgås igen med hver prototype.
  • 🧪 Hvidboksdækning: Code inspektion, fokustest, dataanalyse, sti- og flowtest, algoritme- og AI-analyse, der ser ind i motoren.
  • Hjælpespil: Adaptiv teknologi erstatter visuelle stimuli med lydsignaler for spillere med syns-, høre-, kognitive eller motoriske handicap.
  • 📊 Målinger er vigtige: DAU/MAU, sessionsantal, downloadrang, fastholdelseskohorter og billedhastighed kvantificerer, om udgivelsen rent faktisk fungerer.

Spiltestproces for mobil- og desktopapplikationer, der dækker funktions-, ydeevne- og compliance-tjek

Hvad er spiltestning?

Spiltestning er en softwaretestproces til test af videospil med henblik på kvalitetskontrol. Hovedformålet med spiltestning er at identificere og opdage defekter og fejl i et videospil og at forbedre dets stabilitet og ydeevne. Spiltestning er en del af spiludvikling, der hjælper med at sikre, at det videospil, der implementeres, er fri for fejl.

Før de enkelte teknikker giver mening, er det nyttigt at se, hvor testning er placeret i den bredere udviklingscyklus.

Spiludviklings livscyklus

Førproduktion: I denne fase udarbejdes spilidé, storyboard, funktioner, kravanalyse og dokumentation. Denne fase omfatter det tekniske designdokument og funktionsspecifikationer, spilarkitektur, frame overlay og animation. Følgende punkter tages i betragtning:

  • Musik, kamera (zoom ind og ud, afspilning, filmisk visning), spiller- og handlingsattributter
  • Spillets flowlogik, regler og betingelser for at nå det næste niveau
  • Objekt- og begivenhedsudløsere, scorer, spillerbevægelse og -positionering, spillerstatistik
  • Ikke-interaktive sekvenser, specialeffekter, titelskærme, handlinger med flere knapper
  • Gamepad, filmklip, stød-/vibrationseffekter, juridiske tekster, brug af knapfunktioner, brug af analog og digital tilstand

De tre faser og aktiviteterne i hver af dem er vist nedenfor.

Diagram over spiludviklingslivscyklus, der viser præproduktion, produktion, test og implementering
Spiludviklings livscyklus

Produktion: I denne fase udføres selve kodningen. Denne fase omfatter kodning og integration af de forskellige moduler.

Test og implementering: I denne fase udføres funktionelle tests, regressionstest og Alpha-, Beta- og Gold-milepælene. Test af dækning og flows, dataintegritet, algoritmespecifik test, stitest og inkrementel testning udføres også ved hjælp af testværktøjer til mobile spil.

Hvordan spiltestning adskiller sig fra anden softwaretestning

Test af spil er en gentagende proces – alle nye builds kan indeholde fejl og skal testes grundigt.

Al spiltestning følger en grundlæggende struktur uanset spillets størrelse og den tid, det tager at producere det.

Kvalitetssikringsmedarbejderen skal studere spillets regler og krav og forstå den overordnede arkitektur for spillets komponenter, filarkitekturen, flowet, filstrukturerne og de afhængigheder, der er forbundet med spillet. Med hver ny prototype af spillet skal testdokumenterne gennemgås for at afspejle eventuelle ændringer i specifikationerne, nye testcases til spiltestning og ny konfigurationsunderstøttelse. En videospiltester bør også sikre, at der ikke er introduceret nye problemer.

Jobs med spiltestere omfatter:

  • Klassificer kravene ud fra det tilsigtede formål og målgruppen.
  • Identificer bruger- og systemkravene og klassificer dem i funktionelle, ikke-funktionelle og domænekrav.
  • Identificer testbare elementer, ikke-testbare elementer, mål og målinger for funktionelle og ikke-funktionelle krav.
  • Kontroller, om de funktionelle krav er fuldstændige, ensartede og forståelige.
  • Identificer brugerdefinerede krav og modstridende krav.
  • Identificer indbyrdes afhængige krav, hvilket er et af de centrale opgaver inden for spiltestning.
  • Prioritér kravene baseret på unikhed, kompleksitet og kritiskhed.
  • Identificer spillets tema, karakterer, animation, AI, filmsekvenser, kameraperspektiv og gameplay.

Hvis du gerne vil blive videospilstester, er her en gratis tutorial, der er værd at tjekke ud: Sådan bliver du videospiltester.

Typer af spiltestning

Nedenfor er de populære spiltestteknikker. Hver af dem er rettet mod en forskellig klasse af defekter, og en udgivelsesklar titel går normalt igennem dem alle i stedet for at vælge mellem dem.

1) Funktionstest

Funktionalitets-QA-testere leder efter generiske problemer i spillet eller dets brugergrænseflade og grafik, såsom problemer med spillets mekanik, stabilitetsproblemer og integriteten af ​​spillets aktiver. Brugergrænsefladetest sikrer spillets brugervenlighed. Dette er den samme disciplin som funktionstest i enhver anden applikation, anvendt på spilleregler i stedet for forretningsregler.

Eksempel: Kontrol af farver og baggrunde, menustruktur, skærmretning og skærmopløsning, skriftstørrelse, justeringsfejl, brugervenlighed, systemnavigation såsom indlæsningstid, timeout og visning, sortering, bekræftelsesmeddelelser, sekvenser, animation og lydelementer i spillet, instruktioner og dialogmeddelelser. Det dækker også brugerinteraktioner, brugergrænseflader, transaktionstest, kalibrering og nøjagtighedstest af mobiltelefonkameraer, skærmopløsninger, test af mobilresponsivt design og test af lydkvalitet.

2) Kompatibilitetstest

Kontrol af, om spillet er kompatibelt på tværs af forskellige enheder og på forskellige konfigurationer af hardware og software. Bred enhedsdækning er vigtigere for spil end for de fleste applikationer, fordi GPU-drivere og skærmens billedformat ændrer, hvordan titlen gengives. Se kompatibilitetstest for den generelle teknik.

Eksempel: Installer og afinstaller spillet på alle understøttede konsoller, stationære computere og mobiler.

3) Ydelsestest

Spillets samlede ydeevne kontrolleres. Ydeevnejustering udføres for at optimere spillets hastighed. Den bredere øvelse dækkes i test af ydeevne, og den mobilspecifikke vinkel i test af mobilapps ydeevne.

Vigtige parametre kontrolleret under ydeevnetest:

  • Svartid på klient og servere, transaktionsafslutningstider, spidsbelastningsydelse, levetid, netværksdækning, hukommelseslækage, lav hukommelse, lavt batteri, tid det tager at downloade applikationen, samtidig (flere brugere) adgang til applikationsserveren, hastighed, gennemløbshastighed, pålidelighed og skalerbarhed.
  • Batteriforbrug og grafikydeevne: Mål batteriforbruget i mobilspillet. Batteriforbruget skal være optimalt over lange timer, og spillets respons skal være tilfredsstillende under varierende tunge belastninger på tværs af forskellige enheder.
  • Processor- og hukommelsesbegrænsninger: Ydelsestællere bruges til at måle applikationens CPU- og hukommelsesforbrug.
  • Netværksforbindelse: Måler mobilspillets responstid på forskellige netværkstyper (Wi-Fi, 3G, 4G, 5G). Det giver et samlet indblik i, hvor godt spillet vil klare sig på upålidelige netværk, og kontrollerer også forbindelsen mellem mobile enheder, datacentre og skyen. Spidsbelastningstider, ustabile forbindelser, dataduplikering, pakketab og fragmentering af data overvåges alle.
  • Test af mobilspils ydeevne, især for MMO-titler.

4) Overholdelses-/overensstemmelsestestning

Dette dækker overholdelse af markedsretningslinjer (f.eks. Apple App Store-politikker) og overholdelse af virksomhedspolitikker (f.eks. forbudt indhold). Overholdelse kan også henvise til regulerende organer som PEGI og ESRB. Spillet er rettet mod en bestemt indholdsklassificering, og hvis der er stødende indhold, der er upassende til den ønskede klassificering, identificeres og rapporteres det. Selv en enkelt overtrædelse i en indsendelse til licensgodkendelse kan medføre, at spillet afvises, hvilket medfører yderligere omkostninger til yderligere test og genindsendelse.

Eksempel: Hvis spillet skal udgives i europæiske lande, skal det testes for PAL-konvertering; hvis spillet er produceret til Nordamerika, skal det testes for NTSC-konverteringer.

5) Lokaliseringstestning

Lokaliseringstest bliver afgørende, når et spil er målrettet globale markeder. Spiltitler, indhold og tekster skal oversættes og testes med enheder på flere sprog. Disse tests kan udføres hurtigt ved hjælp af cloudbaseret enhedsadgang og testautomatisering.

Eksempel: Lokaliseringsbehov specifikke for MENA-regionen (Mellemøsten/Nordafrika), arabisk lokalisering (understøttelse af tekst fra højre mod venstre, tovejsvisning), pseudolokaliseringstest, dobbeltbytetegn til østasiatiske sprog, lokal tid og dato, valuta, adresseformater og andre lokale krav.

6) Gennemvædningstest

Denne testteknik til spilautomatisering involverer at lade spillet køre i en længere periode i forskellige driftstilstande - for eksempel i tomgang, på pause eller ved titelskærmen. Soaking kan identificere hukommelseslækager eller afrundingsfejl.

Eksempel: Spillet er begyndt, og figuren er sat til at stå inaktiv i 24 timer. Denne teknik bruges til at opdage nedbrud forårsaget af hukommelseslækager og andre fejl i spilmotoren.

7) Genopretningstest

I software, gendannelsestest kontrollerer, hvor godt applikationen gendanner sig fra nedbrud, hardwarefejl og andre lignende fejl. Applikationen tvinges til at fejle, og det observeres derefter, hvordan den gendanner sig fra fejlforholdene og miljøet.

Eksempel: Genstart pludselig spillekonsollen, mens en spilapplikation kører, og valider dataintegriteten.

8) Sikkerhedstest

Sikkerhedstest udføres for at kontrollere, hvor sikkert softwaren fungerer, når den udsættes for eksterne trusler. Det dækker databeskyttelse mod eksterne trusler, ukontrollerede systemadgangsbegrænsninger, databrud, fejl i operativsystemer, fejl i kommunikationssystemer og svage krypteringsalgoritmer.

Eksempel: Ændring af en URL fra /login til /play på en spilleside bør ikke tillade direkte adgang til spillene.

9) Test af andre spil

Test af rigtige eller virtuelle karakterer. I multiplayer-videospil er forbindelse til serveren og synkronisering af spilstatus to kritiske områder, der skal testes.

Eksempel: Multiplayer 3D-racerspil.

Test af nye funktioner såsom opdateringer om spilstatus, venneinvitationer og deling af premiumgaver. Dette sikrer en rig spiloplevelse for brugeren.

Eksempel: Facebook, blogs.

Lydtest

Test af, om der er en fejl i indlæsningen af ​​filerne, lyt til lydfiler for fejl eller forvrængninger og brug af en CC-profiler til at analysere farvekommentaren.

Database og spilstatistik

Databaseverifikation ved hjælp af fejlfinding for at undersøge, om spillet bruger dataene korrekt. Sørg for, at dataene er indlæst det rigtige sted og viser de korrekte oplysninger.

White-box-testning

White-box-testning af spil fokuserer på de arkitektoniske, integrations- og systematiske aspekter af mobilspil.

  1. Code Inspektion: Kildekoden gennemgås, og programlogik, almindelige programmeringsfejl og overholdelse af kodningsstandarder analyseres.
  2. Fokus test: Kodestykker føres til de isolerede moduler, og outputtet analyseres.
  3. Dataanalyse: Dataanvendelse, fortolkning og manipulation analyseres og valideres for de forskellige moduler.
  4. Sti- og flowtest: Den korrekte rækkefølge af objekter udføres.
  5. Algoritmespecifik testning: Test af et bestemt spilscenarie eller en bestemt funktion ved at indstille datavariabler og dataværdier i koden og udføre den i runtime-miljøet.
  6. Kunstig intelligens Analyse: Løbestatistikker for AI-komponentens programmerbare bevægelser og spil genereres. Resultatet valideres for at kontrollere, om alle de programmerbare bevægelser bruges. Eksempel: et sidegreb på snowboardet og spil som f.eks. et kombineret slag eller spark i multidirektionel handling.

Assisterende spil ved hjælp af adaptiv teknologi

Hjælpespil er også kendt som tilgængelighedsspil. Funktioner er designet ved hjælp af adaptiv teknologi til personer med forskellige handicap såsom nedsat syn, sløret syn, blindhed, manglende evne til at skelne farver samt tale-, høre-, kognitive, motoriske og mobilitetshæmninger. Verifikationsmetoden følger de samme principper som tilgængelighedstest i mainstream-software.

Cardinal Direction (CD) og Tower of London (TOL) er to populære spil, der er blevet tilpasset til synshandicappede brugere. I disse spil erstattes visuelle stimuli med lydinput.

En videospilstester bør være opmærksom på følgende, når han tester et sådant spil:

  1. Farverne skal blinke i et mønster, og toner skal spille for hver farve.
  2. Hver farve skal ledsages af en hørbar tone.
  3. Visuelle data skal beskrives med ord, så synshandicappede spillere ikke har problemer med at modtage dem via skærmlæsere.
  4. Spilleren skal høre lyde i spillet i tre dimensioner og skal være i stand til at navigere i verden ved hjælp af berøringsskærmen, 3D-lyd og spatialiseret lyd.

Spilmålinger som en tester bør kende

Testresultater alene fortæller ikke et studie, om en udgivelse lykkedes. Følgende målinger er de tal, en tester forventes at læse sammen med fejlrapporten.

DAU/MAU (dagligt aktive brugere / månedligt aktive brugere): Forholdet mellem aktive brugere, der spiller hver dag, og antallet af månedlige aktive brugere. Dette kaldes også almindeligvis for "stickiness factor".

Session: Hver gang en bruger åbner appen, tæller det som en session. Her er fokus på det gennemsnitlige antal sessioner pr. DAU.

Download rang: Rangeringen af ​​et spil i en bestemt appbutik (iOS, Android Spil) efter månedlige spildownloads.

Tilbageholdelse: En meget vigtig målestok for en Android spiltester på et gratis spil. For at beregne fastholdelsen skal du opdele brugerne i kohorter baseret på den dag, applikationen blev downloadet.

Ydelsesmålinger: Disse track ydeevnen af ​​online- eller vedvarende spil — den billedhastighed, hvormed et spil kører på en klienthardwareplatform, eller i tilfælde af en spilserver, dets stabilitet. Ydeevnemålinger kan bruges til at overvåge skiftende funktioner og opdateringer.

Nøglerisici i spiltestning

Risiciene nedenfor forvandler oftest et teknisk fungerende byggeri til et kommercielt skuffende et.

  1. Spillet skaber ikke en fængslende oplevelse for den målrettede målgruppe.
  2. Spillet har ikke et spillercentreret design.
  3. Sjovhedsfaktoren og det vanedannende gameplay mangler.
  4. Spillet er hverken unikt, konkurrencepræget eller hurtigt.
  5. Spillet fejler på grund af tekniske problemer, defekte funktioner, kritiske fejl, dårlig musik og lyd eller dårlig video.
  6. Udgifterne til spiludvikling overstiger budgettet.
  7. Det æstetiske design og gameplayet er ikke holdt simpelt.

Ofte Stillede Spørgsmål

Den kører tidligere beståede sager igen efter hver build for at bekræfte en rettelse eller en ny funktion, der ikke brød noget. Fordi spilbuilds ændres dagligt, fokuserer regressionspakker normalt på højrisikoområder såsom gemte filer, login, matchmaking og økonomien i spillet.

Maskinlæringsbots afspiller tusindvis af sessioner natten over for at finde bløde låse og uopnåelig geometri, gruppere duplikerede crashrapporter og markere visuelle fejl ved at sammenligne gengivne frames. Menneskelige testere har stadig den rette vurdering af sjovfaktoren, som ingen model i øjeblikket erstatter.

Ja, for det scriptede lag. Copilot fremskynder skrivningen af ​​​​testudstyr til motorer, datadrevne parametersæt og logparsere. Den kan ikke bedømme gameplay-balance eller sværhedskurver, så genererede tests kræver stadig en tester for at definere, hvad et korrekt resultat ser ud.

Testere spiller uden et manuskript og prøver bevidst mærkelige sekvenser og grænser for at afdække fejl, hvor der ikke forventes nogen skriftlig case. Det supplerer manuskriptbaserede løb og er især effektivt på nye niveauer, fysikinteraktioner og alt, der involverer spillerkreativitet.

En typisk stak parrer en defekt tracbruger et teststyringsværktøj, et motor-native automatiseringsframework, en GPU- eller CPU-profiler, netværksdelingping forsyningsselskaber og en cloud med rigtige enheder til at dække mobil test enhedsmatrix.

Alfa betyder, at funktionssættet er komplet, men groft. Beta betyder, at indholdet er låst, og fokus skifter til defekter og balance, ofte med eksterne aktører. Guld betyder, at buildet er godkendt til udgivelse og indsendt til platformcertificering.

Inkluder buildnummer, platform og enhed, nøjagtige reproduktionstrin, hyppighed, forventet versus faktisk adfærd og et videoklip med logfilen. Spil er visuelle, så en kort optagelse løser tvetydighed, som skriftlige trin alene sjældent afgør.

Spiltest jagter defekter i forhold til en specifikation. Spiltest indsamler designfeedback fra repræsentative spillere om sværhedsgrad, tempo og underholdning. Den ene beskytter korrekthed, den anden beskytter appel, og et studie har brug for begge dele før udgivelsen.

Opsummer dette indlæg med: