Menu

Test af webapplikation komplet guide (Sådan testes et websted)

  • Vigtigste
  • Webtest
  • Test af webapplikation komplet guide (Sådan testes et websted)

web application testing complete guide

Prøv Vores Instrument Til At Fjerne Problemer

En komplet testvejledning til webapplikationer: Sådan testes et websted

Vi er alle enige om, at internettet i dagens stadigt skiftende og konkurrencedygtige verden er blevet en integreret del af vores liv.

De fleste af os træffer vores beslutninger ved at søge på oplysningerne på internettet i disse dage, og det er derfor ikke længere valgfrit, men obligatorisk for alle slags virksomheder at være vært for et websted. Det er det første skridt i at blive og forblive relevant på markedet.

Bare det at have et websted er ikke nok. En organisation er nødvendig for at udvikle et websted, der er informativt, tilgængeligt og brugervenligt. For at opretholde alle disse kvaliteter skal webstedet testes godt, og denne proces med at teste et websted er kendt som webtest.

Test af webapplikationer

Hvad du lærer:

Hvad er webtestning?

Webtest er en softwaretestpraksis for at teste websteder eller webapplikationer for potentielle fejl. Det er en komplet test af webbaserede applikationer, før de bliver live.

Et webbaseret system skal kontrolleres fuldstændigt fra ende til slut, før det går live for slutbrugere.

Ved at udføre websitetest kan en organisation sørge for, at det webbaserede system fungerer korrekt og kan accepteres af brugere i realtid.

UI-designet og funktionaliteten er kaptajnerne for test af websteder.

Webtest tjeklister

1) Funktionstest
2) Brugervenlighedstest
3) Interface test
4) Kompatibilitetstest
5) Test af ydeevne
6) Sikkerhedstest

Anbefalede værktøjer til at praktisere webtestkoncepter nævnt på denne side:

# 1) LoadNinja

LoadNinja giver dig mulighed for at indlæse test din webapplikation med ægte browsere i målestok ved hjælp af testskripter, der kan afspilles igen umiddelbart efter optagelsen, og der produceres handlingerbare browserbaserede ydeevnedata for at isolere problemer og fejle fejl i realtid.

LoadNinja - Banner

=> Besøg LoadNinja-webstedet

# 2) LambdaTest

LambdaTest er en skalerbar cloudbaseret testplatform på tværs af browsere designet til at tilbyde alle websteder og webapptest, der er nødvendige for skyinfrastruktur.

LambdaTest

LambdaTest-platformen hjælper med at sikre, at dine webapp-elementer (såsom JavaScript, CSS, HTLM5, Video ... osv.) Gengives problemfrit på alle stationære og mobile webbrowsere med understøttelse af manuel, visuel og automatiseret test. Med LambdaTest kan du få adgang til op til 2000+ kombinationer af desktop- og mobilbrowsere i skyen.

=> Besøg LambdaTest-webstedet

# 1) Funktionstest

Test for - alle links i websider, databaseforbindelse, formularer, der bruges til at indsende eller få oplysninger fra brugeren på websiderne, test af cookies osv.

Tjek alle linkene:

  • Test de udgående links fra alle sider til det specifikke domæne, der testes.
  • Test alle interne links.
  • Testlinks hopper på den samme side.
  • Testlink bruges til at sende e-mails til admin eller andre brugere fra websider.
  • Test for at se, om der er forældreløse sider.
  • Endelig inkluderer linkkontrol, kontroller for ødelagte links i alle de ovennævnte links.

Testformularer på alle sider:
Formularer er en integreret del af ethvert websted. Formularer bruges til at modtage information fra brugere og til at interagere med dem. Så hvad skal kontrolleres i disse formularer?

  • Kontroller først alle valideringer på hvert felt.
  • Kontroller for standardværdier i felterne.
  • Forkerte input i formularerne til felterne i formularerne.
  • Muligheder for at oprette formularer, hvis der er nogen, formularer sletning, visning eller ændring af formularerne.

Lad os tage et eksempel på det søgemaskiprojekt, som jeg arbejder med i øjeblikket. I dette projekt har vi tilmeldingstrin for annoncører og tilknyttede virksomheder. Hvert tilmeldingstrin er forskelligt, men det afhænger af de andre trin.

Så tilmeldingsflowet skal udføres korrekt. Der er forskellige feltvalideringer som e-mail-id'er, validering af brugerfinansielle oplysninger osv. Alle disse valideringer skal kontrolleres i manuel eller automatiseret webtest.

Test af cookies:

Cookies er små filer, der er gemt på brugerens maskine. Disse bruges dybest set til at opretholde sessionen - hovedsageligt login-sessionerne. Test applikationen ved at aktivere eller deaktivere cookies i dine browserindstillinger.

Test, om cookies er krypteret, før du skriver til brugermaskinen. Hvis du tester sessioncookies (dvs. cookies, der udløber, efter at sessionen slutter), skal du kontrollere for login-sessioner og brugerstatistik, efter at sessionen er afsluttet. Kontroller effekten på applikationssikkerheden ved at slette cookies. (Jeg vil også snart skrive en separat artikel om test af cookies)

Valider din HTML / CSS:

Hvis du optimerer dit websted til søgemaskiner, er HTML / CSS-validering den vigtigste. Valider hovedsageligt webstedet for HTML-syntaksfejl. Kontroller, om webstedet kan crawles til forskellige søgemaskiner.

Databasetestning:

Datakonsistens er også meget vigtigt i en webapplikation. Kontroller for dataintegritet og fejl, mens du redigerer, sletter, ændrer formularerne eller udfører DB-relateret funktionalitet.

Kontroller, om alle databaseforespørgsler er udført korrekt, data hentes og også opdateres korrekt. Mere om databasetest kan være en belastning på DB, vi behandler dette i webbelastning eller præstationstest nedenfor.

Ved test af funktionaliteten på webstederne skal følgende testes:

Links
jeg. Interne links
ii. Eksterne links
iii. Mail Links
iv. Brudte links

Formularer
jeg. Validering af felt
ii. Fejlmeddelelse for forkert indtastning
iii. Valgfri og obligatorisk felt

Database
Test udføres på databaseintegritet.

# 2) Test af brugervenlighed

Brugervenlighedstest er den proces, hvorved et systems interaktionsegenskaber mellem menneske og computer måles, og svagheder identificeres til korrektion.

• Let læring
• Navigation
• Subjektiv brugertilfredshed
• Generelle udseende

Test for navigation:

Navigation betyder, hvordan en bruger surfer på websiderne, forskellige kontroller som knapper, felter, eller hvordan brugeren bruger linkene på siderne til at surfe på forskellige sider.

Usability Testing inkluderer følgende:

  • Hjemmesiden skal være let at bruge.
  • Instruktionerne skal være meget klare.
  • Kontroller, om de leverede instruktioner er perfekte til at opfylde dets formål.
  • Hovedmenuen skal findes på hver side.
  • Det skal være konsistent nok.

Indholdskontrol:

Indholdet skal være logisk og let at forstå. Kontroller for stavefejl. Brugen af ​​mørke farver irriterer brugerne og bør ikke bruges i webstedets tema.

hvordan man vender et array i java

Du kan følge nogle standardfarver, der bruges til websider og indholdsopbygning. Dette er de almindeligt accepterede standarder som det, jeg nævnte ovenfor om irriterende farver, skrifttyper, rammer osv.

Indholdet skal være meningsfuldt. Alle ankertekstlinks skal fungere korrekt. Billederne skal placeres korrekt med de rigtige størrelser.

Dette er nogle af de grundlæggende vigtige standarder, der skal følges i webudvikling. Din opgave er at validere alt til UI-test.

Andre brugeroplysninger til brugerhjælp:

Ligesom søgemuligheden hjælper sitemap også med filer osv. Sitemapet skal være tilgængeligt med alle links på websteder med et korrekt træbillede af navigation. Se efter alle links på sitemap.

Indstillingen 'Søg på stedet' hjælper brugerne med at finde indholdssider, som de leder efter nemt og hurtigt. Disse er alle valgfri emner, og hvis de er til stede, skal de valideres.

# 3) Interface-test

Ved webtestning skal interface på serversiden testes. Dette kan gøres ved at kontrollere, at kommunikationen foregår korrekt. Serverens kompatibilitet med software, hardware, netværk og databasen skal testes.

De vigtigste grænseflader er:

  • Webserver og applikationsservergrænseflade
  • Applikationsserver og databaseservergrænseflade.

Kontroller, om alle interaktioner mellem disse servere udføres, og fejl håndteres korrekt. Hvis databasen eller webserveren returnerer en fejlmeddelelse for enhver forespørgsel fra applikationsserveren, skal applikationsserveren fange og vise disse fejlmeddelelser passende for brugerne.

Tjek hvad der sker, hvis brugeren afbryder en transaktion derimellem? Tjek hvad der sker, hvis forbindelsen til webserveren nulstilles imellem?

# 4) Test af kompatibilitet

Kompatibiliteten af ​​dit websted er et meget vigtigt testaspekt. Se hvilken kompatibilitetstest der skal udføres:

  • Browser kompatibilitet
  • Operativsystemkompatibilitet
  • Mobil browsing
  • Udskrivningsmuligheder

Browser Kompatibilitet:

I min webtestekarriere har jeg oplevet dette som den mest indflydelsesrige del af websitetest.
Nogle applikationer er meget afhængige af browsere. Forskellige browsere har forskellige konfigurationer og indstillinger, som din webside skal være kompatibel med.

Din websteds kodning skal være en cross-browser platform kompatibel. Hvis du bruger java-scripts eller AJAX opfordrer til UI-funktionalitet, udfører sikkerhedskontrol eller validering, giver derefter mere stress på browserkompatibilitetstest af din webapplikation.

Test webapplikationer på forskellige browsere som Internet Explorer, Firefox, Netscape Navigator, AOL, Safari, Opera-browsere med forskellige versioner.

OS-kompatibilitet:

Nogle funktioner i din webapplikation er, at den muligvis ikke er kompatibel med alle operativsystemer. Alle nye teknologier, der bruges i webudvikling, såsom grafisk design og interface-opkald som forskellige API'er, er muligvis ikke tilgængelige i alle operativsystemer.

Test derfor din webapplikation på forskellige operativsystemer som Windows, Unix, MAC, Linux, Solaris med forskellige OS-smag.

Mobilbrowsing:

Vi er i den nye teknologialder. Så i fremtiden vil mobil browsing rocke. Test dine websider i mobile browsere. Kompatibilitetsproblemer kan også være der på mobile enheder.

Udskrivningsindstillinger:

Hvis du giver sideudskrivningsmuligheder, skal du sørge for, at skrifttyper, sidejustering, sidegrafik osv. Bliver udskrevet korrekt. Sider skal passe til papirstørrelsen eller i henhold til den størrelse, der er nævnt i udskrivningsmuligheden.

# 5) Performance Testing

Webapplikationen skal bære en tung belastning. Webpræstationstest skal omfatte:

  • Test af webbelastning
  • Webstresstest

Test applikationsydelse ved forskellige internetforbindelseshastigheder.

Test af webbelastning : Du skal teste, om mange brugere har adgang til eller anmoder om den samme side. Kan systemet opretholde spidsbelastningstid? Webstedet skal håndtere mange samtidige brugeranmodninger, store inputdata fra brugere, samtidig forbindelse til DB, tung belastning på bestemte sider osv.

Webstresstest: Generelt betyder stress at strække systemet ud over de angivne grænser. Webstresstest udføres for at bryde stedet ved at give stress, og det kontrolleres, hvordan systemet reagerer på stress, og hvordan det genopretter efter nedbrud. Der gives generelt stress på inputfelter, login- og tilmeldingsområder.

I webydelse kontrolleres test af webstedsfunktionalitet på forskellige operativsystemer og forskellige hardwareplatforme for fejl i software og hardwarehukommelse.

Ydelsestest kan anvendes til at forstå webstedets skalerbarhed eller til at sammenligne ydelsen i miljøet af tredjepartsprodukter såsom servere og middleware til potentielt køb.

Forbindelseshastighed
Testet på forskellige netværk som Dial-Up, ISDN osv.

belastning
jeg. Hvad er nej. af brugere pr. gang?
ii. Kontroller for spidsbelastninger, og hvordan systemet fungerer
iii. En stor mængde data, som brugeren har adgang til

Stress
jeg. Kontinuerlig belastning
ii. Ydelse af hukommelse, CPU, filhåndtering osv.

# 6) Sikkerhedstest

Følgende er nogle af testsagerne til websikkerhedstest:

  • Test ved at indsætte den interne URL direkte i browserens adresselinje uden login. Interne sider bør ikke åbnes.
  • Hvis du er logget ind ved hjælp af brugernavn og adgangskode og gennemsøger interne sider, så prøv at ændre URL-indstillinger direkte. Dvs. Hvis du tjekker nogle udgiversite-statistikker med udgiverwebsite-id = 123. Prøv at ændre URL-websted-id-parameteren direkte til et andet websteds-id, som ikke er relateret til den indloggede bruger. Denne bruger skal nægtes adgang til at se andres statistikker.
  • Prøv nogle ugyldige input i inputfelter som login-brugernavn, adgangskode, input-tekstfelter osv. Kontroller systemets reaktion på alle ugyldige input.
  • Webmapper og filer skal ikke være tilgængelige direkte, medmindre de får downloadmuligheden.
  • Test CAPTCHA for at automatisere scriptlogins.
  • Test om SSL bruges til sikkerhedsforanstaltninger. Hvis den bruges, vises den korrekte meddelelse, når brugerne skifter fra ikke-sikre HTTP: // sider til sikre HTTPS: // sider og omvendt.
  • Alle transaktioner, fejlmeddelelser og forsøg på sikkerhedsbrud skal logges i logfiler et eller andet sted på webserveren.

Den primære årsag til at teste sikkerheden på et web er at identificere potentielle sårbarheder og derefter reparere dem.

  • Netværksscanning
  • Sårbarhedsscanning
  • Adgangskodebrydning
  • Log gennemgang
  • Integritetskontrol
  • Virusdetektion

Typer af webtest

Et websted er klassificeret i mange typer, ca. 20 typer. Alle disse krymper under statisk og dynamisk type. Blandt dem skal vi diskutere 4 typer og deres testmetoder på en detaljeret måde. Før det vil jeg bare kugle disse typer.

  • Enkel statisk websitetest
  • Dynamisk test af webapplikationer
  • Test af e-handelswebsite
  • Test af mobilwebsite

# 1) Simpelt statisk websted

Et simpelt statisk websted viser det samme indhold for alle besøgende, der besøger webstedet på forskellige tidspunkter. Det er også kendt som et informativt websted. På et statisk websted er det kun udviklere, der kun kan foretage ændringer i kode. Denne type websted har ingen større funktioner, og det afhænger udelukkende af UI-design.

At teste et simpelt statisk websted er meget let, du skal kun overveje et par ting, mens du tester. Nogle af dem er nævnt nedenfor:

Punkter at huske:

# 1) Test af GUI-designet er et must, fordi et statisk websted rent afhænger af det. Du skal sammenligne de godkendte PSD-filer med den udviklede webside. Kontroller, at alle elementerne i designet skal præsenteres på den udviklede side.

#to) Den anden del af GUI-designet er at kontrollere skriftstørrelse, skrifttypestil, afstand og farve alt er blevet gengivet.

(Dette billede forklarer problemet med afstandsjustering i desktop-visningen på et websted.)

# 3) For det andet skal du kontrollere linkene (sidelinks) for at se, om det fungerer korrekt eller ej. Find også ud af, om der er et brudt link?

# 4) Kontroller stavningen og indholdet på alle websider ved at sammenligne det indhold, klienten giver.

# 5) I nogle tilfælde vises billedet ikke korrekt, det kan gå i stykker, eller nogle gange bliver billedet duplikeret, og der vises muligvis forkerte billeder. Det skal kontrolleres nøje. Fordi for et statisk websted er det kun indhold og billeder, der giver liv.

# 6) Tjek rullebjælken omhyggeligt, og efter min erfaring har jeg haft problemer med rullebjælken. Det problem, du står overfor, er uønsket rulning, der vises, eller ruller bliver skjult (det kan skjule indholdet). Ovenstående spørgsmål gælder både vandrette og lodrette ruller.

# 7) Hvis der er en kontaktformular, skal du kontrollere, at den fungerer korrekt ved at sende nogle dummy-meddelelser.

Ting at kontrollere på kontaktformularen er:

  • Sendes meddelelsen korrekt, og der vises en vellykket besked?
  • Kontroller, om e-mailen modtaget til den pågældende person i det korrekte format som designet?
  • Kontroller, at e-mail ikke skal lande i spam som junk mail?
  • Hvis der er en svar-e-mail-trigger er aktiveret, skal du kontrollere, om afsenderen har modtaget e-mailen?

# 8) Kontroller, om det er en fejlfri webside, og valider den med W3 validator eller anden relateret software.

# 9) Nogle konstante ting, der skal kontrolleres på et statisk websted,

  • Kontroller, at favicon findes på fanelinjen
  • URL skal indeholde den korrekte sidetitel
  • Hvis copyrightoplysninger er der, skal de vises
  • Hvis der er en kontaktformular, er Captcha et must. (Det forhindrer uønsket e-mail)
  • Tjek webstedets indlæsningshastighed. (Et statisk websted bør ikke tage meget tid at indlæse). Hvis et gif-billede bruges under indlæsning, skal du spore dets funktionalitet

Bortset fra disse er der enorme ting, der skal testes i backend på hvert websted, der er systemtest , sikkerhedstest, interface-test, kompatibilitetstest og performance-test osv. Til dette skal du have teknisk viden. På et simpelt statisk websted finder du ikke flere funktioner, hvis du også har brug for at udføre funktionstest.

# 2) Dynamisk webapplikation (CMS-websted)

Det er den type, hvor brugeren regelmæssigt kan opdatere og ændre deres webstedsindhold. Herfra vil jeg bruge ordet 'webapplikationstest' i stedet for dynamisk websitetest. Webapplikationen er en kombination af front-end og back-end programmering .

Frontend'en vil være HTML og CSS, mens back-end bruger programmeringssprog som PHP, Javascript og ASP osv. Med denne backend kan bruger / klient tilføje eller ændre indholdet på hjemmesiden.

Test af en webapplikation er ikke let end at teste et statisk websted, men ikke meget vanskeligt end at teste et e-handelswebsted. Funktionstest er den vigtigste ting, der skal udføres under test af en webapplikation. Webapplikationen kan indeholde meget kompliceret funktionalitet, så testeren skal være meget forsigtig under testningen.

Der er to forskellige typer webapplikationer er der, den ene er ingen handling, der udføres af brugeren i frontend (dvs. kun backend-ændringer vil afspejle sig i frontend), den anden er slutbruger, der arbejder foran -end sig selv ( for eksempel login, tilmelding, abonnement på nyhedsbrev og andre lignende handlinger). Så testning skal udføres i henhold til det.

Punkter at huske:

De punkter, som jeg nævnte i test for statisk websted, skal også medtages, mens du tester en webapplikation. Derudover skal følgende ting bemærkes.

# 1) I GUI sektionen, værktøjstip er obligatorisk for alle felter og knapper skal feltjustering (afstand) udføres ordentligt, deaktiveret felt / knapper skal være nedtonet, felter / knapper skal være i standardformat som i SRS, fejlmeddelelse skal vises, hvis noget går galt, pop op meddelelse skal kun vises i midten af ​​websiden, rullemenuen skal ikke afkortes.

Fanen genvejstast skal fungere i alle felter og mere.

#to) I funktionssektionen skal du kontrollere, hvis din webapplikation har login- eller tilmeldingsfunktionalitet obligatorisk validering af marken , formvalidering (dvs. nummerfelter skal kun acceptere tal, ikke alfabeter), tegnbegrænsning på felter (dvs. kun så mange tegn kan indtastes).

Særlige tegn og negative talbegrænsninger på felter, test af e-mail-funktionalitet, test af dokumentupload (dvs. kun specificeret dokumenttype kan uploades ), timeout-funktionalitet, sorteringsfunktionalitet, javascript arbejder på kompatible browsere osv. skal testes.

# 3) Når du kommer til back-end-funktionalitetsafsnittet, testes upload af billeder til ødelagte billeder, tekst, der indtastes i felterne, fungerer eller ej. Back-end opdatering skal reflektere over frontend , databasetest (dvs. om du kan tilføje nye felter eller slette uønskede felter) skal alle disse ting udføres.

Ydeevne er ikke meget nødvendigt for en webapplikation (dynamisk websted), da den har meget mindre indhold. Hvis du har brug for det, kan du gøre med de værktøjer, du er fortrolig med. Pick-up nogle standard online ydeevne værktøj, hvis du ønsker at udføre enkel præstation test.

pl sql interview spørgsmål og svar

# 3) E-handelswebsted

Et e-handelswebsted er noget kompliceret sammenlignet med ovenstående to. Testeren skal være meget forsigtig, når man tester et e-handelswebsted. Der er enorme ting, der skal kontrolleres på e-handelswebsteder ud af dem. Jeg dækker bare nogle af mine erfarne problemer med test af e-handelswebsteder.

I GUI-sektionen skal du kontrollere alle funktionerne som i SRS og det samme med funktionaliteten. Funktionaliteten vil være næsten den samme for alle kommercielle websteder.

Funktionelt set skal du kontrollere alle sider, såsom hovedsiden (inkluderer fremhævede produkter, specialtilbud, log ind detaljer, søgefunktionalitet) produktdetaljer, kategoriside, bestilling, betalingsportal alt skal testes.

Punkter at huske:

# 1) Kontroller, om indkøbskurven bliver opdateret, når du køber eller øger mængden. Kontroller denne funktionalitet på alle sider og omstændigheder.

#to) Kontroller, om specielle kuponer og tilbud anvendes på korrekte ordrer og du ser den nedsatte pris vises eller ej.

(Dette billede forklarer om gratis forsendelse, og hvordan det anvendes i betalingsafsnittet)

# 3) Under opdatering af et enkelt produkt bliver det undertiden ganget ved at overveje antallet af variationer i produktet. Så kontroller, om det enkelte produkt vises, og dets variationer vises korrekt. (Jeg stod over for dette problem)

# 4) Kontroller, om filterindstillingen fungerer nøjagtigt. Hvis der er foretaget filtrering, baseret på den valgte kategori og prisfastsættelse?

# 5) Under tilmelding skal supervalidering udføres. Kun den nye bruger kan tilmelde sig.

# 6) Hvis en eksisterende bruger tilføjede et produkt til indkøbskurven, skulle sektionen om ønskeliste under deres forrige login også gemmes og vises under det næste login.

# 7) Sammenlign produkter skal fungere ved at sammenligne produkterne baseret på nogle specifikationer, der er tildelt i back-end.

# 8) Kontroller, om valutakonverteren fungerer fint. Baseret på det valgte land skal valutaomregneren vise de relevante priser og afgiftssatser.

(Ved valg af sprog Valuta konverteres, her er USD ment som standard)

# 9) Generelt bruges mange plug-ins i en e-handelswebside (WordPress & lignende), du skal være meget forsigtig. Plugin-installationen kan komme i konflikt eller påvirke andre vigtige funktioner. Så følg op med installationen af ​​plug-ins og dens anvendelse.

# 10) Kontroller, om den sociale delingsindstilling fungerer på det enkelte produkt eller ej.

#elleve) Forsendelsesomkostninger skal genereres baseret på den valgte region. Og kontroller også skatteprocentgenerering. (Det kan forårsage nogle juridiske problemer under slutbrugernes køb).

skatteprocent

(På dette billede Forsendelse og skatteprocent beregnes for Frankrigs region)

# 12) Betalingsgateway skal kun fungere, hvis gyldige kortoplysninger gives. Validering skal gælde for kortnummer og CCV-kodenummer. (Det er bedre at beholde validering i selve kortnummerfeltet).

# 13) Generering af e-mail på hver eneste proces under køb skal ske (tilmelding, produktbestilling, betaling vellykket, ordre annulleret, ordre modtaget og andre e-mail-udløsere, hvis nogen).

# 14) Tjek live chat med nogle dumpy e-mails.

Bemærk: Generelt udvikles e-handelswebsite ikke til mobilkompatibilitet, og når der kommer til mobilversionen, genereres der en app. I nogle tilfælde opretter de ikke en app i stedet for at der oprettes et mobilkompatibelt websted. I sådanne tilfælde skal du nøje kontrollere, om der mangler funktionalitet og UI-afvigelse.

Dette er nogle af de problemer, som jeg stod over for og bemærkede, da jeg testede et e-handelswebsted. Bortset fra dette skal du kontrollere alle de generelle ting, der er relateret til et e-handelswebsted.

# 4) Mobilwebsted

Lad os først og fremmest være klar over et mobilwebsite. Generelt synes folk, at både en mobilwebsite og en mobilapplikation er den samme, men i virkeligheden er en mobilwebsite udviklet med HTML-sider og kan kun ses med en internetforbindelse.

Men mobilappen er intet andet end en applikation, der kan downloades og bruges senere uden en internetforbindelse. Her bliver mange af os forvirrede og rejser et spørgsmål Hvad er forskellen mellem mobilwebsted og responsivt websted?

Et responsivt websted betyder, at indholdet passer ind i størrelsen på mobilenheden i stedet for at oprette en version, mens et mobilwebsted opretter en ny version, der ikke er en refleksions desktopversion. På mobilwebstedet har du kun begrænsede sider, og uønskede funktioner fjernes her.

Test af et mobilwebsted er noget kedeligt snarere end andre typer websteder. Det har separate designs, og du skal være forsigtig, når du tester funktionaliteterne.

Punkter at huske:

Vigtige punkter at overveje, når du tester et mobilwebsted:

  • Normalt bruger vi en emulator til at teste et mobilwebsted, og vi kan få ideelle resultater, men jeg foretrækker altid, at du tester på rigtige enheder. Jeg har stået over for mange problemer, da jeg testede i rigtige enheder (Især apple-enheder). Specifikke enhedsspecifikationer kan være i konflikt med de udviklede websider.

(Dette billede forklarer simuleringstest og backline-problemet, der vises i det.)

  • GUI og brugervenlighedstest er vigtigere, da det ikke afspejler desktopversionen.
  • Ydeevne er en anden vigtig faktor, der skal overvejes ved test af mobilwebsites. Ydelsesrelaterede problemer kan spores, når du tester i de rigtige enheder.
  • Kontroller, om browsing på normale weblinks fra mobil bliver udløst af et mobillink.
  • Tjek siderulling, sidenavigation, tekstafkortning osv. På mobilwebstedet.

Bedste webtestværktøjer

Der er en bred vifte af testværktøjer, der er tilgængelige til webapptest.

virtual reality-headset kompatibelt med ps4

=> Tjek denne omfattende liste af de mest populære værktøjer til test af webapplikationer.

Point, der skal overvejes, når du tester et websted

Webstederne er i det væsentlige klient / server applikationer - med webservere og 'browser' klienter.

Interaktioner mellem bør overvejes HTML-sider, TCP / IP-kommunikation, internetforbindelser, firewalls, applikationer, der kører på websider (såsom applets, javascript, plug-in-applikationer) og applikationer, der kører på serversiden (såsom CGI-scripts, databasegrænseflader, logningsprogrammer, dynamiske sidegeneratorer, asp osv.).

Derudover er der en lang række servere og browsere med forskellige versioner af hver. De inkluderer små men undertiden signifikante forskelle mellem dem med hensyn til variationer i forbindelseshastigheder, hurtigt skiftende teknologier og flere standarder og protokoller. Slutresultatet, hvor testning af websteder kan blive en større igangværende indsats.

Eksempel på testscenarier til test af en webapplikation

Få andre overvejelser, der skal medtages under test af et websted, er angivet nedenfor .

  • Hvad er den forventede belastning på serveren (f.eks. Antal hits pr. Tidsenhed)?
  • Hvilken form for ydeevne kræves under hver indlæsningsbetingelse (såsom svartid på webserver, responstid for databaseforespørgsel)?
  • Hvilken slags værktøj kræves der til præstationstest (såsom værktøjer til test af webbelastning, andre værktøjer, der allerede er interne, der kan tilpasses, værktøjer til download af webroboter osv.)?
  • Hvem er målgruppen? Hvilken slags browsere bruger de? Hvilken type forbindelseshastigheder vil de bruge? Er de intraorganisationer (således sandsynligvis med høje forbindelseshastigheder og lignende browsere) eller internettet (således med en lang række forbindelseshastigheder og browsertyper)?
  • Hvilken form for ydeevne forventes fra klientsiden (f.eks. Hvor hurtigt skal sider vises, hvor hurtigt skal animationer, applets osv. Indlæses og køre)?
  • Vil nedetid for server- og indholdsvedligeholdelse / opgraderinger være tilladt? Hvis ja, hvor meget?
  • Hvilken slags sikkerhed (firewalls, kryptering, adgangskoder osv.) Kræves, og hvad forventes det at gøre? Hvordan kan det testes?
  • Hvor pålidelig kræves det, at webstedets internetforbindelser er? Og hvordan påvirker det backupsystemet eller overflødige forbindelseskrav og test?
  • Hvilken proces kræves for at administrere opdateringer til webstedets indhold?
  • Hvad er kravene til vedligeholdelse, sporing og styring af sideindhold, grafik, links osv.?
  • Hvilken HTML-specifikation overholdes? Hvor strengt? Hvilke variationer er der tilladt for målrettede browsere?
  • Vil der være nogen standardkrav til sideudseende og / eller grafik på et websted eller dele af et websted?
  • Hvordan valideres og opdateres interne og eksterne links? Og hvor ofte? vil det ske?
  • Kan test udføres på produktionssystemet, eller kræves der et separat testsystem?
  • Hvordan skal der tages højde for browserens caching, variationer i browserindstillingsindstillinger, opkaldsforbindelsesvariabilitet og internet-trafikproblemer i den virkelige verden?
  • Hvor omfattende eller tilpasset er kravene til serverlogning og rapportering; betragtes de som en integreret del af systemet, og kræver de test?
  • Hvordan skal CGI-programmer, applets, javascript, ActiveX-komponenter osv. Vedligeholdes, spores, kontrolleres og testes?
  • Siderne skal maksimalt være 3-5 skærme, medmindre indholdet er stærkt fokuseret på et enkelt emne. Hvis det er større, skal du angive interne links på siden.
  • Sidelayouterne og designelementerne skal være ensartede på hele et websted, så det er klart for brugeren, at de stadig er på et websted.
  • Sider skal være så browseruafhængige som muligt, eller sider skal leveres eller genereres baseret på browsertypen.
  • Alle sider skal have links uden for siden; der skal ikke være blindgange.
  • Sideejeren, revisionsdato og et link til en kontaktperson eller organisation skal medtages på hver side.

Ofte stillede spørgsmål om webtest

Nedenfor bør de forskellige spørgsmål komme op til en testers sind, når man tænker på et websted, der allerede er udviklet og kan blive udsat for offentligheden:

  • Fungerer hjemmesiden som forventet?
  • Vil slutbrugeren finde hjemmesiden let at gennemse?
  • Er webstedet tilgængeligt på forskellige enheder, som slutbrugerne besidder?
  • Er webstedet sikret nok?
  • Er webstedets ydeevne op til mærket?
  • Opbevares dataene på et websted nøjagtigt og varer på tværs af sessioner?
  • Er hjemmesiden integreret godt med andre grænseflader i arbejdsgangen?
  • Vil webstedet fungere som forventet, selv efter at være gået live?

For at besvare disse spørgsmål er der identificeret forskellige testteknikker, der kan bruges til at teste en webapplikation.

Lad os tage et eksempel på et e-handelswebsted, der for nylig er blevet frigivet til QA-teamet til test.

Vi gennemgår hvert af de ovennævnte spørgsmål i detaljer for at forstå testens omfang og se, hvordan test af websteder kan udføres.

test af websteder

Fungerer hjemmesiden som forventet?

for at bekræfte, at webstedet fungerer godt, skal QA udføre funktionstest. I løbet af funktionstest , skal forskellige funktioner i en applikation valideres i forhold til kravene nævnt i det funktionelle specifikationsdokument.

Nedenfor er et par generiske scenarier, en QA forventes at dække under udførelse af funktionstest af ethvert websted, selvom de ikke er nævnt i funktionelle specifikationer:

  • Brugernavigation til forskellige sider på hjemmesiden og færdiggørelse af end-to-end workflow
  • Hvis brugeren kan markere / fravælge afkrydsningsfelter
  • Hvis brugeren kan vælge værdier fra rullemenuer
  • Hvis brugeren kan vælge / fravælge radioknapper
  • Forskellige navigeringsknapper som Submit, Next, Upload osv. Fungerer godt
  • Kalendere indlæses korrekt og giver brugeren mulighed for at vælge en dato
  • Beregninger sker som implementeret
  • Søgefunktionalitet fungerer, hvis nogen
  • Korrekt informationsvisning
  • Forskellige interne og eksterne links til andre sider
  • Korrekt fanerækkefølge for felterne på websider
  • Obligatoriske og valgfrie felter skal verificeres for de positive og negative input
  • Standardværdier for hvert webfelt skal verificeres
  • E-mail-funktionalitet er implementeret for nogle handlinger på hjemmesiden

Det er vigtigt for websteder at være kompatible med søgemaskiner. Derfor bør vi gennemse websteder for HTML-syntaks korrekthed, format og overholdelsesstandarder som WS-I, ISO og ECMA.

I betragtning af cookies, der bruges til at opretholde login-sessioner, skal webstedet testes ved at aktivere / deaktivere cookies eller ved at bruge det uoverensstemmende domæne. Test kan også udføres på tværs af sessioner ved at nulstille cookies for at bringe browsere tilbage til vaniljetilstand.

QA bør også validere, at webstedscookies altid opbevares lokalt i et krypteret format.

I betragtning af vores e-handelswebsted skal forskellige links som herremode, damemode, børnemode, hjemmetilbehør, elektroniske apparater, bøger, film og musik osv., Der er tilgængelige på en webside, klikkes på og verificeres, hvis brugeren navigerer til forventet side.

Tilsvarende skal forskellige funktioner som login, tilmelding, søgemulighed, filtre, sorteringsrækkefølge, indkøbskurv osv. Verificeres på forskellige websider som login-side, tilmeldingsside, produktdetaljer-side, indkøbskurv, ordreanmeldelse, betaling, osv. Hjemmesiden skal kontrolleres for session- / cookiehåndtering som sessionudløb og sessionlager osv.

Vil slutbrugeren finde hjemmesiden let at gennemse?

Brugervenlighedstest skal udføres for at måle webstedets brugervenlighed for en slutbruger i forbindelse med tilgængelighed, søgbarhed og anvendelighed osv.

Brugervenlighedstest

Nedenfor er der få af de testscenarier, der skal verificeres under udførelse af brugervenlighedstest for et websted:

  • Webstedsindhold skal være informativt, struktureret og linket logisk, så brugeren let kan forstå
  • Websidekontrol skal være let for brugerne at navigere
  • Hjemmesiden skal have uploadet hjælp- og instruktionsdokumenter
  • Webstedet skal have søgefunktionen for slutbrugerens bekvemmelighed
  • Adgang til / fra hovedmenuen til alle sider skal være der
  • Webstedsindhold skal verificeres for stavefejl
  • Webstedet skal følge definerede retningslinjer i baggrunden for baggrundsfarve, mønster, stil, skrifttyper, billedplaceringer, rammer, rammer osv.
  • Webstedet skal være vant til oversættelsesfunktionen i betragtning af det faktum, at det er tilgængeligt for brugere fra forskellige nationer med forskellige sprog, valutaer osv.

Få værktøjer, der kan bruges til at udføre brugervenlighedstest er Brugerzoom og Reflektor .

Et e-handelswebsted skal være kundevenligt, let at navigere og opmærksomhedsgribende. Alle websider skal verificeres for tilgængelighed, skrifttyper, styling, billeder, stavefejl og produktrelevant information. Et websted skal være udstyret med relevante hjælpedokumenter og kundesupportfaciliteter.

I betragtning af stigningen i berøringsskærmbaserede grænseflader er vi nødt til at validere tilgængeligheden af ​​både nøgleindgange og berøringsskærmindgange. Tilsvarende skal billeder og webstedsindhold valideres for brugervenlighed på forskellige skærmstørrelser (mobiltelefoner, bærbare computere og faner osv.).

Er webstedet tilgængeligt på forskellige enheder, som slutbrugerne besidder?

Forudsat at vores websted kan få adgang til en række brugere med et andet sæt enheder, er vi nødt til at sikre, at hjemmesiden kører godt på dem alle uden fejl.

For at sikre det samme skal der foretages kontrol af websteds kompatibilitet, som følger med Test af kompatibilitet . Under kompatibilitetstest af et websted sikres det, at webstedet kører godt på forskellige browsere, operativsystemer og enheder som bærbare computere, mobiltelefoner, tablets, printere osv.

Browsers kompatibilitet (Cross Browser Testing):

Webstedet skal fungere godt med forskellige browsere som Microsoft Internet Explorer, Microsoft Edge, Firefox, Google Chrome, Safari og Opera. Alle aktive versioner af disse browsere skal verificeres med forskellige browserfunktioner slået TIL / FRA.

Også under udførelsen test på tværs af browsere , QA bør også kontrollere den optimale webstedsydelse på tværs af browsere.

Operativsystemkompatibilitet (test på tværs af platforme):

For at identificere potentielle brugeroplevelsesproblemer skal et websted testes på forskellige platforme som Windows, Linux, Unix.MAC, Solaris osv. For at være sikker på OS-kompatibilitet.

Enhedskompatibilitet (test på tværs af enheder):

Et websted kan browses gennem forskellige enheder som bærbare computere, mobiltelefoner, tablets osv. Med forskellige tilgængelige operativsystemer som iOS, Android, Windows osv. Derfor skal test udføres på enhederne, der også dækker nedenstående scenarier.

  • Webstedsskærmstørrelse skal justeres i henhold til enheden
  • En enhed skal have skærmrotation
  • Webstedet bør ikke vise nogen indlæsningsproblemer på forskellige enheder med forskellige netværkshastigheder
  • Kontroller webstedsadfærden, når enheden er inden for / uden for netværksområdet
  • Bekræft webstedets opførsel på lav CPU og hukommelse for at understøtte forskellige formfaktorer

For et e-handelswebsted er kompatibilitetskontrollen en af ​​de vigtigste testtyper. Kundebasen vil være stor og vil få adgang til vores websted fra forskellige browsere, operativsystemer og enheder.

I betragtning af at mobile platforme bliver populære, bør vi sikre, at webstedsbelastning på lille formfaktor under acceptabel belastningstid. Det er også vigtigt at validere brugen af ​​forskellige netværkshastigheder for at sikre, at den er anvendelig for alle kunder.

Er webstedet sikret nok?

Sikkerhedstest udføres for at afdække sårbarheder i et system og sikre, at et websted er sikret.

Nedenfor er tjeklisten, der kan verificeres under udførelse af sikkerhedstest:

  • Webstedet skal kun være tilgængeligt for godkendte brugere
  • Webstedsbrugere skal kun kunne udføre de opgaver, som de er godkendt til
  • Webstedet skal verificeres for CAPTCHA-felter til brugeridentifikation
  • Browsers sikkerhedsindstillinger skal verificeres, mens de går fra sikre til usikre sider
  • Webserverbeskyttelse skal være der for utilgængelige webmapper eller filer
  • Sørg for, at begrænsede filer ikke skal downloades uden passende adgang
  • Sessioner, der blev inaktive, burde automatisk dræbes efter en bestemt periode
  • Alle ugyldige og uautoriserede forsøg fra slutbrugere eller intermitterende systemfejl / -fejl skal logges til analyseformål

Værktøjer som Sårbarhedsstyring , Veracode og SQL-kort kan bruges til at udføre sikkerhedstest af dit websted.

Som en del af sikkerhedstestning skal et e-handelswebsted valideres til

  1. Webstedsadgangskontrol.
  2. Enhver lækage af brugerens personlige oplysninger.
  3. Sikrede betalingsmetoder.

Er webstedets ydeevne op til mærket?

For at kontrollere ydeevnen på et websted kan præstationstest udføres. Det vil evaluere en applikations opførsel under forskellige arbejdsbelastningsforhold, som kan være et realistisk scenario. Hvis systemet går i drift uden at udføre præstationstest, kan det ende med problemer som et langsomt kørende system eller dårlig brugervenlighed, som sandsynligvis vil påvirke brandimaget såvel som markedssalg.

Et websted kan testes mod belastning og stress.

Nedenfor er tjeklisten til test af webpræstationer:

  • Webstedsadfærd skal overholdes under normale belastninger og spidsbelastningsforhold
  • Websteds ydeevne skal undersøges ved at måle responstid, hastighed, skalerbarhed og ressourceudnyttelse
  • Korrekt RCA (rodårsagsanalyse) skal udføres med en løsning, hvis et system går i stykker eller bliver ustabilt på et hvilket som helst tidspunkt
  • Netværksforsinkelsesproblemer bør identificeres, hvis der er nogen

Et e-handelswebsted skal testes grundigt ved hjælp af et sæt simulerede brugere under normale såvel som peakbelastningsforhold, der kan være under 'Salgsæsonen'.

Under salget vil brugere, der får adgang til hjemmesiden, formere sig. Desuden bør webstedsadfærd undersøges, mens flere samtidige brugere har adgang til de samme varer eller udfører de samme handlinger (som transaktioner eller afgivelse af ordrer) på hjemmesiden.

Der findes forskellige værktøjer på markedet til præstationstest. Få af dem er det LoadRunner, WinRunner, Silk Performer, JMeter osv.

Opbevares dataene på et websted nøjagtigt og varer på tværs af sessioner?

Databasen er en af ​​de kritiske komponenter i en webapplikation, der indeholder de komplette oplysninger, der er indtastet via et websted. Derfor skal der udføres kontrol for at sikre, at korrekte brugerdata gemmes i databasetabeller uden manipulationer og for at opretholde dataintegriteten.

  • Kontroller datakonsistens på tværs af brugergrænsefladen, dvs. webstedsgrænsefladen og databasen
  • Kontroller, at DB-tabeller opdateres korrekt, hver gang indsæt / opdater / slet-handlinger udføres af et webstedsapplikation
  • Kontroller svartiden for tekniske forespørgsler, og finjuster dem, hvis det er nødvendigt
  • Kontroller for DB-forbindelse og adgangstilladelser

Som et QA-teammedlem, der tester e-handelswebsitet, kan du udføre nedenstående aktiviteter og validere ændringerne hver gang i de tilsvarende databasetabeller. Dette vil sikre, at webstedsgrænsefladen og DB begge er konsistente.

1) Bestilling af et produkt.

2) Annullerer produkt.

3) Vælg at udveksle produkt.

4) Vælg at returnere produkt.

Er hjemmesiden integreret godt med andre grænseflader i arbejdsgangen?

Testing af grænsefladeniveau udføres for at kontrollere den glatte interaktion mellem hjemmesiden og forskellige grænseflader som webserver og databaseserver.

Under interface-test skal testeren sikre sig, om applikationsanmodningerne sendes korrekt til databasen, og at korrekte oplysninger vises til klienten som output. En webserver bør ikke kaste nogen undtagelsesundtagelser på noget tidspunkt, og databasen skal altid være synkroniseret med applikationen.

Vil webstedet fungere som forventet, selv efter at være gået live?

Når et produkt er gået ind i et produktionsmiljø, skal den regelmæssige inspektion udføres for at kontrollere kvalitetskontrol.

Nedenstående scenarier kan overvejes, når produktet kontrolleres i produktionen:

  • Webapplikationstest skal udføres med jævne mellemrum, og testlogfiler skal gemmes som bevis på, at Service Level Agreement (SLA) er kompatibel
  • Automatisk skaleringssystemer og belastningsafbalancere bør kontrolleres, hvis de er på plads og fungerer
  • Hold øje med slutbrugerens oplevelser og prøv at afdække mangler eller ondsindede angreb, som typisk går ubemærket hen under QA-test
  • Overvåg produktets responstid under spidsbelastninger
  • Udfør kantniveau test tilfælde i realtid for at identificere netværksfejl, forbindelsesfejl eller afbrydelse ved et uventet opkald

Konklusion

Jeg har udarbejdet denne detaljerede tutorial med mine års erfaring med at teste de forskellige hjemmesider.

Håber, at denne artikel hjælper dig med at forstå de forskellige aspekter af test af webapplikationer. Næste gang du sidder og skriver en testplan for dit websted, skal du huske at validere forskellige aspekter ud over webstedets funktionalitet.

Håber denne artikel ville have været en informativ for dig!

Anbefalet læsning

^