web application testing complete guide
En komplett testprogram for webapplikasjoner: Hvordan teste et nettsted
Vi må alle være enige om at internett i dagens stadig skiftende og konkurransedyktige verden har blitt en integrert del av våre liv.
De fleste av oss tar våre beslutninger ved å søke i informasjonen på internett i disse dager, og det er derfor ikke lenger valgfritt å være vert for et nettsted, men obligatorisk for alle slags virksomheter. Det er det første trinnet i å bli og forbli relevant i markedet.
Bare det å ha et nettsted er ikke nok. En organisasjon er nødvendig for å utvikle et nettsted som er informativt, tilgjengelig og brukervennlig. For å opprettholde alle disse egenskapene, bør nettstedet være godt testet, og denne prosessen med å teste et nettsted er kjent som nettesting.
Hva du vil lære:
- Hva er nettesting?
- Sjekklister for webtesting
- Typer av webtesting
- Poeng som skal vurderes når du tester et nettsted
- Eksempel på testscenarier for testing av en webapplikasjon
- Vanlige spørsmål om webtesting
- Konklusjon
- Anbefalt lesing
Hva er nettesting?
Nettprøving er en programvaretestpraksis for å teste nettsteder eller webapplikasjoner for potensielle feil. Det er en komplett testing av nettbaserte applikasjoner før du gjør live.
Et nettbasert system må kontrolleres helt fra ende til slutt før det går live for sluttbrukere.
Ved å utføre nettstedstesting kan en organisasjon sørge for at det nettbaserte systemet fungerer som det skal og kan aksepteres av sanntidsbrukere.
UI-design og funksjonalitet er kapteiner for testing av nettsteder.
Sjekklister for webtesting
1) Funksjonstesting
2) Brukervennlighetstesting
3) Grensesnitt testing
4) Kompatibilitetstesting
5) Ytelsestesting
6) Sikkerhetstesting
Anbefalte verktøy for å praktisere webtestkonsepter nevnt på denne siden:
# 1) LoadNinja
LoadNinja lar deg laste teste webapplikasjonen din med ekte nettlesere i målestokk, ved hjelp av testskript som kan spilles av umiddelbart etter opptak, og produserer handlingsbare nettleserbaserte ytelsesdata for å isolere problemer og feilsøke feil i sanntid.
=> Besøk LoadNinja-nettstedet
#2) LambdaTest
LambdaTest er en skalerbar skybasert testplattform på tvers av nettlesere designet for å tilby alle nettsteder og nettapptesting som trengs for skyinfrastruktur.
LambdaTest-plattformen bidrar til å sikre at webapp-elementene dine (som JavaScript, CSS, HTLM5, Video ... osv.) Gjengis sømløst i alle stasjonære og mobile nettlesere med støtte for manuell, visuell og automatisert testing. Med LambdaTest får du tilgang til opptil 2000+ kombinasjoner av stasjonære og mobile nettlesere i skyen.
=> Besøk LambdaTest-nettstedet# 1) Funksjonstesting
Test for - alle lenkene på websider, databasetilkobling, skjemaer som brukes til å sende inn eller få informasjon fra brukeren på websidene, test av informasjonskapsler, etc.
Sjekk ut alle lenkene:
- Test de utgående koblingene fra alle sidene til det spesifikke domenet som testes.
- Test alle interne lenker.
- Testlenker som hopper på samme side.
- Testlenker brukes til å sende e-post til admin eller andre brukere fra websider.
- Test for å se om det er foreldreløse sider.
- Til slutt inkluderer koblingskontroll, se etter ødelagte koblinger i alle de ovennevnte koblingene.
Testskjemaer på alle sider:
Skjemaer er en integrert del av ethvert nettsted. Skjemaer brukes til å motta informasjon fra brukere og til å samhandle med dem. Så hva skal sjekkes i disse skjemaene?
- Sjekk først alle valideringene i hvert felt.
- Se etter standardverdier i feltene.
- Feil inngang i skjemaene til feltene i skjemaene.
- Alternativer for å opprette skjemaer, hvis noen, skjemaet sletter, viser eller endrer skjemaene.
La oss ta et eksempel på søkemotorprosjektet jeg jobber med. I dette prosjektet har vi påmeldingstrinn for annonsører og tilknyttede selskaper. Hvert påmeldingstrinn er forskjellig, men det er avhengig av de andre trinnene.
Så registreringsstrømmen skal utføres riktig. Det finnes forskjellige feltvalideringer som e-post-ID, validering av brukerøkonomisk informasjon osv. Alle disse valideringene bør sjekkes i manuell eller automatisert nettesting.
Testing av informasjonskapsler:
Informasjonskapsler er små filer som er lagret på brukermaskinen. Disse brukes i utgangspunktet for å opprettholde økten - hovedsakelig påloggingsøktene. Test applikasjonen ved å aktivere eller deaktivere informasjonskapslene i nettleseralternativene.
Test om informasjonskapslene er kryptert før du skriver til brukermaskinen. Hvis du tester økt-informasjonskapsler (dvs. informasjonskapsler som utløper etter at økten er avsluttet), må du se etter påloggingsøkter og brukerstatistikk etter at økten er avsluttet. Sjekk effekten på applikasjonssikkerheten ved å slette informasjonskapslene. (Jeg vil snart skrive en egen artikkel om testing av informasjonskapsler også)
Valider HTML / CSS:
Hvis du optimaliserer nettstedet ditt for søkemotorer, er HTML / CSS-validering den viktigste. Valider hovedsakelig nettstedet for HTML-syntaksfeil. Sjekk om siden kan gjennomsøkes til forskjellige søkemotorer.
Databasetesting:
Datakonsistens er også veldig viktig i en webapplikasjon. Se etter dataintegritet og feil mens du redigerer, sletter, endrer skjemaene eller gjør DB-relatert funksjonalitet.
Sjekk om alle databasespørsmålene er utført riktig, data blir hentet og også oppdatert riktig. Mer om databasetesting kan være en belastning på DB, vi vil ta opp dette i nettbelastning eller ytelsestesting nedenfor.
Ved testing av funksjonaliteten til nettsteder bør følgende testes:
Lenker
Jeg. Interne lenker
ii. Eksterne linker
iii. Mail Links
iv. Broken Links
Skjemaer
Jeg. Feltvalidering
ii. Feilmelding for feil inntasting
iii. Valgfrie og obligatoriske felt
Database
Testing vil bli gjort på databasens integritet.
# 2) Testing av brukervennlighet
Brukervennlighetstesting er prosessen der et menneskes interaksjonsegenskaper mellom datamaskin måles og svakheter identifiseres for korreksjon.
• Enkel læring
• Navigering
• Subjektiv brukertilfredshet
• Generelt utseende
Test for navigering:
Navigering betyr hvordan en bruker surfer på websidene, forskjellige kontroller som knapper, ruter eller hvordan brukeren bruker lenkene på sidene til å surfe på forskjellige sider.
Brukervennlighetstesting inkluderer følgende:
- Nettstedet skal være enkelt å bruke.
- Instruksjonene som gis skal være veldig klare.
- Sjekk om instruksjonene som er gitt er perfekte for å oppfylle formålet.
- Hovedmenyen skal vises på hver side.
- Det skal være konsistent nok.
Innholdskontroll:
Innholdet skal være logisk og lett å forstå. Se etter stavefeil. Bruk av mørke farger irriterer brukerne og bør ikke brukes i nettstedstemaet.
bug livssyklus i programvaretesting
Du kan følge noen standardfarger som brukes til websider og innholdsbygging. Dette er de allment aksepterte standardene som det jeg nevnte ovenfor om irriterende farger, skrifttyper, rammer, etc.
Innholdet skal være meningsfylt. Alle ankertekstkoblingene skal fungere skikkelig. Bilder bør plasseres riktig med riktig størrelse.
Dette er noen av de grunnleggende viktige standardene som bør følges i nettutviklingen. Din oppgave er å validere alt for UI-testing.
Annen brukerinformasjon for brukerhjelp:
I likhet med søkealternativet hjelper nettstedskartet også med filer, etc. Sitemapet skal være tilgjengelig med alle lenkene på nettsteder med riktig trevisningsvisning. Se etter alle koblinger på områdekartet.
Alternativet 'Søk på nettstedet' vil hjelpe brukerne å finne innholdssider som de leter etter enkelt og raskt. Dette er alle valgfrie gjenstander, og hvis de er til stede, bør de valideres.
# 3) Grensesnitttesting
Ved nettesting bør servergrensesnittet testes. Dette kan gjøres ved å verifisere at kommunikasjonen er riktig utført. Serverens kompatibilitet med programvare, maskinvare, nettverk og databasen bør testes.
Hovedgrensesnittene er:
- Webserver og applikasjonsservergrensesnitt
- Applikasjonsserver og databaseservergrensesnitt.
Sjekk om alle interaksjoner mellom disse serverne blir utført og feil blir håndtert riktig. Hvis databasen eller webserveren returnerer en feilmelding for ethvert spørsmål fra applikasjonsserveren, bør applikasjonsserveren fange opp og vise disse feilmeldingene riktig for brukerne.
Sjekk hva som skjer hvis brukeren avbryter noen transaksjon i mellom? Sjekk hva som skjer hvis forbindelsen til webserveren tilbakestilles i mellom?
# 4) Testing av kompatibilitet
Kompatibiliteten til nettstedet ditt er et veldig viktig testaspekt. Se hvilken kompatibilitetstest som skal utføres:
- Nettleserkompatibilitet
- Operativsystemkompatibilitet
- Mobilsurfing
- Utskriftsalternativer
Nettleserkompatibilitet:
I min webtestekarriere har jeg opplevd dette som den mest påvirkende delen av nettstedstesting.
Noen applikasjoner er veldig avhengige av nettlesere. Ulike nettlesere har forskjellige konfigurasjoner og innstillinger som websiden din skal være kompatibel med.
Din koding av nettstedet ditt skal være en kompatibel nettleserplattform. Hvis du bruker java-skript eller AJAX krever UI-funksjonalitet, utfører sikkerhetskontroller eller valideringer, og gir mer stress på nettleserkompatibilitetstesting av webapplikasjonen.
Test nettapplikasjoner på forskjellige nettlesere som Internet Explorer, Firefox, Netscape Navigator, AOL, Safari, Opera nettlesere med forskjellige versjoner.
OS-kompatibilitet:
Noe funksjonalitet i webapplikasjonen din er at den kanskje ikke er kompatibel med alle operativsystemer. All ny teknologi som brukes i nettutvikling, som grafisk design og grensesnittanrop som forskjellige API-er, er kanskje ikke tilgjengelig i alle operativsystemer.
Test derfor webapplikasjonen din på forskjellige operativsystemer som Windows, Unix, MAC, Linux, Solaris med forskjellige OS-smaker.
Mobilsurfing:
Vi er i den nye teknologitiden. Så i fremtiden vil mobilsurfing rocke. Test nettsidene dine i mobile nettlesere. Kompatibilitetsproblemer kan også være der på mobile enheter.
Utskriftsalternativer:
Hvis du gir sideutskriftsalternativer, må du sørge for at skrifter, sidejustering, sidegrafikk osv. Blir skrevet ut riktig. Sidene skal passe til papirstørrelsen eller i henhold til størrelsen som er nevnt i utskriftsalternativet.
# 5) Ytelsestesting
Nettapplikasjonen skal bære tung belastning. Nettprestasjonstesting bør omfatte:
- Test av nettbelastning
- Nettstresstesting
Test applikasjonsytelsen med forskjellige internettforbindelseshastigheter.
Test av nettbelastning : Du må teste om mange brukere har tilgang til eller ber om samme side. Kan systemet opprettholde toppbelastningstid? Nettstedet skal håndtere mange samtidige brukerforespørsler, store inndata fra brukere, samtidig tilkobling til DB, tung belastning på bestemte sider osv.
Nettstresstesting: Generelt betyr stress å strekke systemet utover de spesifiserte grensene. Nettstresstesting utføres for å bryte nettstedet ved å gi stress, og det kontrolleres hvordan systemet reagerer på stress og hvordan det gjenoppretter etter krasj. Stress blir vanligvis gitt på inndatafelt, påloggings- og påmeldingsområder.
I nettytelse blir testing av nettstedsfunksjonalitet på forskjellige operativsystemer og forskjellige maskinvareplattformer sjekket for feil på programvare og maskinvarelekkasje.
Ytelsestesting kan brukes for å forstå nettstedets skalerbarhet eller for å måle ytelsen i miljøet til tredjepartsprodukter som servere og mellomvare for potensielt kjøp.
Tilkoblingshastighet
Testet på forskjellige nettverk som Dial-Up, ISDN, etc.
Laste
Jeg. Hva er nei. av brukere per gang?
ii. Se etter toppbelastning og hvordan systemet oppfører seg
iii. En stor mengde data som brukeren har tilgang til
Understreke
Jeg. Kontinuerlig belastning
ii. Ytelse på minne, CPU, filhåndtering osv.
# 6) Sikkerhetstesting
Følgende er noen av testtilfellene for testing av websikkerhet:
- Test ved å lime den interne URL-en direkte inn i nettleserens adressefelt uten pålogging. Interne sider skal ikke åpnes.
- Hvis du er logget på med brukernavn og passord og blar gjennom interne sider, kan du prøve å endre URL-alternativene direkte. Dvs. Hvis du sjekker noen statistikk for publisistnettsteder med publisist-ID = 123. Prøv å endre URL-ID-parameteren til en annen side-ID som ikke er relatert til den påloggede brukeren. Denne brukeren skal nekte tilgang til å se andres statistikk.
- Prøv noen ugyldige innganger i inndatafelt som påloggingsbrukernavn, passord, inntastingsbokser osv. Sjekk systemets reaksjon på alle ugyldige innganger.
- Nettkataloger og filer skal ikke være tilgjengelige direkte med mindre de får nedlastingsalternativet.
- Test CAPTCHA for å automatisere skriptinnlogginger.
- Test om SSL brukes til sikkerhetstiltak. Hvis den brukes, skal den riktige meldingen vises når brukere bytter fra usikre HTTP: // sider til sikre HTTPS: // sider og omvendt.
- Alle transaksjoner, feilmeldinger og sikkerhetsbruddforsøk skal logges på loggfiler et sted på webserveren.
Den primære årsaken til å teste sikkerheten til et web er å identifisere potensielle sårbarheter og deretter reparere dem.
- Nettverksskanning
- Sårbarhetsskanning
- Passordsprekker
- Logg gjennomgang
- Integritetskontroll
- Virusdeteksjon
Typer av webtesting
Et nettsted er klassifisert i mange typer, omtrent 20 typer. Alle disse krymper under statisk og dynamisk type. Blant dem kan vi diskutere fire typer og deres testmetoder på en detaljert måte. Før det vil jeg bare kule disse typene.
- Enkel statisk testing av nettsteder
- Dynamisk testing av webapplikasjoner
- Testing av netthandelsnettsteder
- Testing av mobilnettsteder
# 1) Enkelt statisk nettsted
Et enkelt statisk nettsted vil vise det samme innholdet for alle besøkende som besøker nettstedet til forskjellige tidspunkter. Det er også kjent som et informasjonsnettsted. På et statisk nettsted kan bare utviklere gjøre endringer som bare i kode. Denne typen nettsteder vil ikke ha noen vesentlige funksjoner, og det avhenger rent av UI-design.
Å teste et enkelt statisk nettsted er veldig enkelt, du må bare vurdere noen få ting mens du tester. Noen av dem er nevnt nedenfor:
Poeng å huske:
#1) Å teste GUI-design er et must fordi et statisk nettsted bare avhenger av det. Du må sammenligne de godkjente PSD-filene med den utviklede nettsiden. Sjekk at alle elementene i designet skal presenteres på den utviklede siden.
#to) Den andre delen av GUI-design er å sjekke skriftstørrelse, skriftstil, avstand og farge alt er gjengitt.
(Dette bildet forklarer avstandsjusteringsproblemet i skrivebordsvisningen til et nettsted.)
# 3) For det andre må du sjekke lenkene (sidekoblinger) for å se om den fungerer som den skal eller ikke. Finn også ut om det er en ødelagt lenke?
# 4) Bekreft stavemåten og innholdet på alle websider ved å sammenligne innholdet gitt av klienten.
# 5) I noen tilfeller vises ikke bildet ordentlig, det kan gå i stykker, eller noen ganger blir bildet duplisert, feil bilder kan vises. Det må kontrolleres nøye. For for et statisk nettsted, vil bare innhold og bilder gi liv.
# 6) Sjekk rullefeltet nøye, og etter min erfaring har jeg møtt problemer med rullefeltet. Problemet du vil møte er at uønsket rulling vises eller ruller blir skjult (det kan skjule innholdet). Ovennevnte saker gjelder både horisontale og vertikale ruller.
# 7) Hvis det er et kontaktskjema, sjekk at det fungerer som det skal ved å sende noen dummy-meldinger.
Ting å sjekke på kontaktskjemaet er:
- Sendes meldingen riktig, og vises en vellykket melding?
- Sjekk om e-posten mottatt til den berørte personen i riktig format som designet?
- Sjekk at e-post ikke skal lande i spam som søppelpost?
- Hvis det er en svar-e-postutløser er aktivert, sjekk om avsenderen mottok e-posten?
# 8) Sjekk om det er en feilfri webside, og valider den med W3 validator eller annen relatert programvare.
# 9) Noen konstante ting som skal sjekkes på et statisk nettsted,
- Kontroller at favicon er tilstede på fanelinjen
- URL bør inneholde riktig sidetittel
- Hvis copyrightinformasjon er der, bør den vises
- Hvis det er et kontaktskjema, er Captcha et must. (Det forhindrer søppelpost)
- Sjekk lastehastigheten til nettstedet. (Et statisk nettsted bør ikke ta mye tid å laste inn). Hvis et gif-bilde brukes under innlasting, kan du spore funksjonaliteten
Bortsett fra disse, er det store ting som må testes på baksiden av hvert nettsted som er systemtesting , sikkerhetstesting, grensesnitttesting, kompatibilitetstesting og ytelsestesting osv. For dette må du ha teknisk kunnskap. På et enkelt statisk nettsted, vil du ikke finne flere funksjoner hvis du også trenger å gjøre funksjonstesting.
# 2) Dynamisk webapplikasjon (CMS-nettsted)
Det er typen brukeren kan oppdatere og endre innholdet på nettstedet regelmessig. Herfra skal jeg bruke ordet 'testing av webapplikasjoner' i stedet for dynamisk testing av nettsteder. Nettapplikasjonen er en kombinasjon av front-end og back-end programmering .
Front-enden vil være HTML og CSS, mens back-end bruker programmeringsspråk som PHP, Javascript og ASP etc. Med denne backend kan bruker / klient legge til eller endre innholdet på nettstedet.
Det er ikke lett å teste en webapplikasjon enn å teste et statisk nettsted, men ikke så vanskelig enn å teste et e-handelsnettsted. Funksjonstesting er det viktigste som skal utføres mens du tester en webapplikasjon. Nettapplikasjonen kan inneholde mye komplisert funksjonalitet, så testeren må være veldig forsiktig når du tester.
Det er to forskjellige typer webapplikasjoner er det, den ene er ingen handling vil utføres av brukeren i front-end (dvs. bare endringer i back-end vil gjenspeile seg i front-end) den andre er sluttbrukeren vil jobbe foran -end seg selv ( for eksempel pålogging, påmelding, abonnement på nyhetsbrev og andre lignende handlinger). Så testing bør gjøres i henhold til det.
Poeng å huske:
Poengene som jeg nevnte under statisk testing av nettsteder, skal inkluderes mens jeg tester en webapplikasjon. I tillegg til det skal følgende ting bemerkes.
#1) I GUI-delen, verktøytips er obligatorisk for alle felt og knapper, bør feltjustering (avstand) gjøres riktig, deaktivert felt / knapper skal være nedtonet, felt / knapper skal være i standardformat som i SRS, feilmelding skal vises hvis noe går galt, popup meldingen skal bare vises midt på websiden. rullegardinmenyen skal ikke avkortes.
Hurtigtasten på fanen skal fungere i alle felt og mer.
#to) I funksjonalitetsdelen, hvis webapplikasjonen din har påloggings- eller påmeldingsfunksjonalitet, sjekk deretter obligatorisk feltvalidering , skjemavalidering (dvs. tallfelt skal bare akseptere tall, ikke alfabet), tegnbegrensning på felt (dvs. bare så mange tegn kan angis).
Spesialtegn og negative tallbegrensninger på felt, testing av e-postfunksjonalitet, testing av dokumentopplasting (dvs. bare spesifisert dokumenttype kan lastes opp ), tidsavbruddsfunksjonalitet, sorteringsfunksjonalitet, javascript fungerer på kompatible nettlesere osv. bør testes.
# 3) Når du kommer til back-end-funksjonalitetsseksjonen, fungerer testopplasting for ødelagte bilder, tekst som skrives inn i feltene eller ikke. Back-end oppdatering bør reflektere over frontend , databasetesting (dvs. om du kan legge til nye felt eller slette uønskede felt) alle disse tingene skal utføres.
Ytelse er ikke mye nødvendig for en webapplikasjon (dynamisk nettsted) siden den har veldig mindre innhold. Hvis du trenger det, kan du gjøre med verktøyene du er kjent med. Plukk opp noe standard online ytelsesverktøy hvis du vil gjøre enkel ytelsestesting.
hvordan man skriver junit test tilfeller
# 3) Netthandelsnettsted
Et netthandelsnettsted er noe komplisert sammenlignet med de to ovennevnte. Testeren må være veldig forsiktig når du tester et e-handelssted. Det er store ting å sjekke ut på e-handelsnettsteder. Jeg dekker bare noen av mine erfarne problemer med testing av netthandelsnettsteder.
I GUI-delen må du sjekke alle funksjonene som i SRS og det samme med funksjonaliteten. Funksjonaliteten vil være nesten den samme for alle kommersielle nettsteder.
Funksjonsmessig må du sjekke alle sider, for eksempel hovedsiden (inkluderer utvalgte produkter, spesialtilbud, påloggingsdetaljer, søkefunksjonalitet) produktdetaljer, kategoriside, bestilling, betalingsportal, alt må testes.
Poeng å huske:
#1) Sjekk om handlekurven blir oppdatert når du kjøper eller øker mengden. Sjekk denne funksjonaliteten på alle sider og omstendigheter.
#to) Sjekk om spesielle kuponger og tilbud blir brukt på riktige bestillinger og du ser at den nedsatte prisen vises eller ikke.
(Dette bildet forklarer om gratis frakt og hvordan det brukes i betalingsdelen)
# 3) Noen ganger blir det multiplisert ved oppdatering av et enkelt produkt ved å vurdere antall varianter i produktet. Så sjekk om enkeltproduktet vises og variasjonene vises riktig. (Jeg møtte dette problemet)
# 4) Sjekk om filteralternativet fungerer nøyaktig. Hvis filtrering er utført, basert på valgt kategori og pris?
# 5) Mens du registrerer deg, bør supervalidering gjøres. Bare den nye brukeren kan registrere seg.
# 6) Hvis en eksisterende bruker la til et produkt i handlekurven, bør ønskelisten under forrige pålogging også lagres og vises under neste pålogging.
# 7) Sammenlign produkter bør fungere ved å sammenligne produktene basert på noen spesifikasjoner som er tildelt i back-end.
# 8) Sjekk om valutakalkulatoren fungerer bra. Basert på det valgte landet, skal valutaomformeren vise de aktuelle prisene og avgiftssatsene.
(Når du velger språk Valuta skal konverteres, her er USD ment som standard)
# 9) Vanligvis brukes mange plugin-moduler i et nettsted for e-handel (WordPress og lignende). Du må være veldig forsiktig. Plugin-installasjonen kan komme i konflikt eller påvirke andre viktige funksjoner. Så følg opp med plugin-installasjonen og bruken av den.
# 10) Sjekk om alternativet for sosial deling fungerer på det enkelte produkt eller ikke.
#elleve) Fraktkostnadene skal genereres basert på valgt region. Og sjekk også avgiftssatsen. (Det kan føre til noen juridiske problemer under kjøpet av sluttbrukerne).
(I dette bildet Frakt og skattesatsen beregnes for Frankrike-regionen)
# 12) Betalingsgatewayen skal bare fungere hvis gyldige kortopplysninger er gitt. Validering bør gjelde kortnummer og CCV-kodenummer. (Det er bedre å beholde validering på selve kortnummerfeltet).
# 1. 3) E-postgenerering på hver eneste prosess under kjøpet skal skje (påmelding, produktbestilling, betaling vellykket, bestilling kansellert, mottatt bestilling og andre e-postutløsere hvis noen).
# 14) Sjekk livechatten med noen dumpe e-poster.
Merk: Vanligvis vil ikke e-handelsnettsteder bli utviklet for mobilkompatibilitet, og når det kommer til mobilversjonen, blir det generert en app. I noen tilfeller vil de ikke opprette en app i stedet for et mobilkompatibelt nettsted. I slike tilfeller må du sjekke nøye for å vite om det mangler funksjonalitet og UI-avvik.
Dette er noen av problemene jeg møtte og bemerket da jeg testet et netthandelsnettsted. Bortsett fra dette, må du sjekke alle generelle ting relatert til et e-handelsnettsted.
# 4) Mobilnettsted
Først av alt, la oss være tydelige om et mobilnettsted. Generelt tror folk at både et mobilnettsted og en mobilapplikasjon er de samme, men i virkeligheten er et mobilnettsted utviklet med HTML-sider og kan bare vises med en internettforbindelse.
Men mobilappen er ikke annet enn et program som kan lastes ned og brukes senere uten internettforbindelse. Her blir mange av oss forvirrede og reiser et spørsmål Hva er forskjellen mellom mobilnettsted og responsivt nettsted?
Et responsivt nettsted betyr at innholdet passer inn i størrelsen på mobilenheten i stedet for å lage en versjon, mens et mobilnettsted lager en ny versjon som ikke er en reflekterende desktopversjon. På mobilnettstedet vil du bare ha begrensede sider, og uønskede funksjoner fjernes her.
Å teste et mobilnettsted er litt kjedelig i stedet for andre typer nettsteder. Den har separate design, og du må være forsiktig når du tester funksjonalitetene.
Poeng å huske:
Viktige punkter du bør vurdere når du tester et mobilnettsted:
- Vanligvis vil vi bruke en emulator for å teste et mobilnettsted, og vi kan få ideelle resultater, men jeg foretrekker alltid at du tester på ekte enheter. Jeg har møtt mange problemer da jeg testet i ekte enheter (Spesielt apple-enheter). Ekte enhetsspesifikasjoner kan komme i konflikt med nettsidene som er utviklet.
(Dette bildet forklarer om simulatortesting og problemstillingen bakfra som vises i den.)
- GUI og brukervennlighetstesting er viktigere, siden det ikke reflekterer desktopversjonen.
- Ytelse er en annen viktig faktor som skal vurderes for testing av mobile nettsteder. Ytelsesrelaterte problemer kan spores når du tester i ekte enheter.
- Sjekk om du surfer på vanlige nettlenker fra mobil, blir utløst av en mobillink.
- Sjekk siderulling, sidenavigering, tekstavkorting osv. På mobilnettstedet.
Beste webtestverktøy
Det er et bredt utvalg av testverktøy som er tilgjengelige for testing av webapper.
intervju spørsmål om såpe og hvile
=> Sjekk denne omfattende listen av de mest populære verktøyene for testing av webapplikasjoner.
Poeng som skal vurderes når du tester et nettsted
Nettstedene er i det vesentlige klient / server applikasjoner - med webservere og ‘nettleserklienter’.
Det bør tas hensyn til samspillet mellom HTML-sider, TCP / IP-kommunikasjon, Internett-tilkoblinger, brannmurer, applikasjoner som kjører på websider (for eksempel applets, javascript, plugin-applikasjoner) og applikasjoner som kjører på serversiden (for eksempel CGI-skript, databasegrensesnitt, loggeapplikasjoner, dynamiske sidegeneratorer, asp, etc.).
I tillegg finnes det et bredt utvalg av servere og nettlesere med forskjellige versjoner av hver. De inkluderer små, men noen ganger signifikante forskjeller mellom dem når det gjelder variasjoner i tilkoblingshastigheter, raskt skiftende teknologier og flere standarder og protokoller. Sluttresultatet som testing av nettsteder kan bli en stor kontinuerlig innsats.
Eksempel på testscenarier for testing av en webapplikasjon
Få andre hensyn som skal inkluderes når du tester et nettsted, er gitt nedenfor .
- Hva er forventet belastning på serveren (f.eks. Antall treff per tidsenhet)?
- Hva slags ytelse kreves under hver belastningstilstand (for eksempel svartid på webserver, responstid på databasespørsmål)?
- Hva slags verktøy vil det være nødvendig for ytelsestesting (for eksempel verktøy for nettbelastningstesting, andre verktøy som allerede er interne som kan tilpasses, verktøy for nedlasting av nettroboter osv.)?
- Hvem er målgruppen? Hva slags nettlesere vil de bruke? Hva slags tilkoblingshastigheter vil de bruke? Er de internorganisasjoner (dermed sannsynlig med høye tilkoblingshastigheter og lignende nettlesere) eller Internett-omfattende (dermed med et bredt utvalg av tilkoblingshastigheter og nettlesertyper)?
- Hva slags ytelse forventes fra klientsiden (f.eks. Hvor raskt skal sidene vises, hvor raskt skal animasjoner, applets osv. Lastes og kjøres)?
- Vil nedetid for server- og innholdsvedlikehold / oppgraderinger være tillatt? I så fall hvor mye?
- Hva slags sikkerhet (brannmurer, kryptering, passord osv.) Kreves og hva forventes det å gjøre? Hvordan kan det testes?
- Hvor pålitelig er nettstedets internettforbindelser påkrevd? Og hvordan påvirker det backup-systemet eller overflødige tilkoblingskrav og testing?
- Hvilken prosess kreves for å administrere oppdateringer til innholdet på nettstedet?
- Hva er kravene for å vedlikeholde, spore og kontrollere sideinnhold, grafikk, lenker, etc.?
- Hvilken HTML-spesifikasjon vil bli fulgt? Hvor strengt? Hvilke varianter vil være tillatt for målrettede nettlesere?
- Vil det være noen standardkrav for sideutseende og / eller grafikk på et nettsted eller deler av et nettsted?
- Hvordan vil interne og eksterne lenker bli validert og oppdatert? Og hvor ofte? vil det skje?
- Kan det utføres testing på produksjonssystemet, eller vil det være nødvendig med et eget testsystem?
- Hvordan skal man teste taushet om nettbuffering, variasjoner i innstillinger for nettleseralternativer, variabilitet for oppringt tilkobling og virkelige internettproblemer?
- Hvor omfattende eller tilpasset er kravene til serverlogging og rapportering; betraktes de som en integrert del av systemet, og trenger de testing?
- Hvordan skal CGI-programmer, applets, javascript, ActiveX-komponenter osv. Vedlikeholdes, spores, kontrolleres og testes?
- Sidene skal være maksimalt 3-5 skjermer, med mindre innholdet er sterkt fokusert på et enkelt emne. Hvis større, oppgi interne lenker på siden.
- Sidelayoutene og designelementene skal være konsistente på et nettsted, slik at det er klart for brukeren at de fortsatt er på et nettsted.
- Sider skal være så nettleseruavhengige som mulig, eller sider bør leveres eller genereres basert på nettlesertypen.
- Alle sider skal ha lenker utenfor siden; det skal ikke være noen blindveisider.
- Sidenes eier, revisjonsdato og en lenke til en kontaktperson eller organisasjon bør inkluderes på hver side.
Vanlige spørsmål om webtesting
Nedenfor skal de forskjellige spørsmålene komme til en testers sinn når de tenker på et nettsted som allerede er utviklet og kan eksponeres for publikum:
- Fungerer nettstedet som forventet?
- Vil sluttbrukeren finne nettstedet lett å bla gjennom?
- Er nettstedet tilgjengelig på forskjellige enheter som sluttbrukerne eier?
- Er nettstedet sikret nok?
- Er nettstedets ytelse opp til merket?
- Lagres dataene på et nettsted nøyaktig og vedvarer på tvers av økter?
- Er nettstedet integrert godt med andre grensesnitt i arbeidsflyten?
- Vil nettstedet fungere som forventet selv etter live?
For å svare på disse spørsmålene er det identifisert forskjellige testteknikker som kan brukes til å teste en webapplikasjon.
La oss ta et eksempel på et netthandelsnettsted som nylig ble utgitt til QA-teamet for testing.
Vi vil gå gjennom hvert av de ovennevnte spørsmålene i detalj for å forstå omfanget av testen og se hvordan nettstedstesting kan utføres.
Fungerer nettstedet som forventet?
for å bekrefte at nettstedet fungerer bra, må QA utføre funksjonstesting. I løpet av funksjonstesting , må forskjellige funksjoner i en applikasjon valideres opp mot kravene nevnt i dokumentet om funksjonell spesifikasjon.
Nedenfor er noen generiske scenarier, en QA forventes å dekke mens du utfører funksjonstesting av et hvilket som helst nettsted, selv om de ikke er nevnt i funksjonelle spesifikasjoner:
- Brukernavigering til forskjellige sider på nettstedet og fullføring av end-to-end arbeidsflyten
- Hvis brukeren kan velge / fjerne merket for avmerkingsboksene
- Hvis brukeren kan velge verdier fra rullegardinfelt
- Hvis brukeren kan velge / fravelge alternativknapper
- Ulike navigasjonsknapper som Send, Neste, Last opp osv. -Knapper fungerer bra
- Kalendere lastes ordentlig inn og lar brukeren velge en dato
- Beregninger skjer som implementert
- Søkefunksjonalitet fungerer hvis noen
- Riktig informasjonsvisning
- Ulike interne og eksterne lenker til andre sider
- Riktig fanerekkefølge for feltene på websider
- Obligatoriske og valgfrie felt bør verifiseres for positive og negative innganger
- Standardverdier for hvert nettfelt bør bekreftes
- E-postfunksjonalitet er implementert for noen handlinger på nettstedet
Det er viktig for nettsteder å være kompatible med søkemotorer. Derfor bør vi gjennomgå nettsteder for HTML-syntaks korrekthet, format og samsvarstandarder som WS-I, ISO og ECMA.
Med tanke på informasjonskapsler, som brukes til å opprettholde påloggingsøkter, bør nettstedet testes ved å aktivere / deaktivere informasjonskapsler eller ved å bruke domene som ikke samsvarer. Testing kan også utføres på tvers av økter ved å tilbakestille informasjonskapsler for å bringe nettlesere tilbake til vaniljetilstanden.
QA bør også validere at nettstedets informasjonskapsler alltid lagres lokalt i et kryptert format.
Tatt i betraktning vårt e-handelsnettsted, bør forskjellige lenker som herremote, damemote, barnemote, hjemmetilbehør, elektroniske apparater, bøker, filmer og musikk, etc. tilgjengelig på en webside klikkes på og verifiseres hvis brukeren navigerer til forventet side.
På samme måte bør forskjellige funksjoner som pålogging, registrering, søkealternativ, filtre, sorteringsrekkefølge, Legg i handlekurv, etc. verifiseres på forskjellige nettsider som påloggingsside, registreringsside, produktinformasjonsside, handlekurv, bestillingsanmeldelse, betaling, etc. Nettstedet bør sjekkes for økt- / informasjonskapseladministrasjon som økt utløp og øktlagring etc.
Vil sluttbrukeren finne nettstedet lett å bla gjennom?
Brukervennlighetstesting må utføres for å måle nettstedets brukervennlighet for en sluttbruker i sammenheng med tilgjengelighet, søkbarhet og nytte osv.
Nedenfor er det få av testscenariene som bør verifiseres når du utfører brukervennlighetstesting for et nettsted:
- Nettstedsinnhold skal være informativt, strukturert og koblet logisk slik at brukeren lett kan forstå
- Websidekontroller skal være enkle for brukere å navigere
- Nettstedet skal ha lastet opp hjelp- og instruksjonsdokumenter
- Nettstedet skal ha søkefunksjonen for å gjøre det enklere for sluttbrukerne
- Tilgang til / fra hovedmenyen til alle sider skal være der
- Nettstedsinnhold bør verifiseres for stavefeil
- Nettstedet skal følge definerte retningslinjer i sammenheng med bakgrunnsfarge, mønster, stil, skrifttyper, bildeplasseringer, rammer, rammer osv.
- Nettstedet bør være vant til oversettelsesfunksjonen med tanke på at det er tilgjengelig for brukere fra forskjellige nasjoner med forskjellige språk, valutaer etc.
Få verktøy som kan brukes til å utføre brukervennlighetstesting er Brukerzoom og Reflektor .
Et e-handelsnettsted skal være kundevennlig, lett å navigere og oppsiktsvekkende. Alle websider bør verifiseres for tilgjengelighet, skrifttyper, styling, bilder, stavefeil og produktrelevant informasjon. Et nettsted skal være utstyrt med relevante hjelpedokumenter og kundestøttefasiliteter.
Tatt i betraktning økningen i berøringsskjermbaserte grensesnitt, må vi validere tilgjengeligheten til både nøkkelinnganger og berøringsskjerminnganger. På samme måte bør bilder og nettstedsinnhold valideres for brukervennlighet på forskjellige skjermstørrelser (mobiltelefoner, bærbare datamaskiner og faner osv.).
Er nettstedet tilgjengelig på forskjellige enheter som sluttbrukerne eier?
Forutsatt at en rekke brukere med et annet sett med enheter har tilgang til nettstedet vårt, må vi sørge for at nettstedet fungerer bra på alle uten feil.
For å sikre det samme, bør det gjøres kontroller av nettstedskompatibilitet som følger med Kompatibilitetstesting . Under kompatibilitetstesting av et nettsted, er det sikret at nettstedet kjører godt på forskjellige nettlesere, operativsystemer og enheter som bærbare datamaskiner, mobiltelefoner, nettbrett, skrivere, etc.
Nettleserkompatibilitet (testing av tvers av nettlesere):
Nettstedet skal fungere bra med forskjellige nettlesere som Microsoft Internet Explorer, Microsoft Edge, Firefox, Google Chrome, Safari og Opera. Alle aktive versjoner av disse nettleserne bør verifiseres med forskjellige nettleserfunksjoner slått PÅ / AV.
Også mens du opptrer tester i flere nettlesere , QA bør også sjekke for optimal ytelse på nettstedet på tvers av nettlesere.
Operativsystemkompatibilitet (testing på tvers av plattformer):
For å identifisere potensielle problemer med brukeropplevelsen, bør et nettsted testes på forskjellige plattformer som Windows, Linux, Unix.MAC, Solaris, etc. for å være sikker på operativsystemkompatibiliteten.
Enhetskompatibilitet (testing av flere enheter):
Et nettsted kan bli bladd gjennom forskjellige enheter som bærbare datamaskiner, mobiler, nettbrett, etc. med forskjellige operativsystemer som iOS, Android, Windows osv. Derfor bør testing utføres på enhetene som også dekker nedenstående scenarier.
- Nettstedsskjermstørrelse bør justeres i henhold til enheten
- En enhet skal være skjermrotasjon
- Nettstedet bør ikke vise noen lasteproblemer på forskjellige enheter med forskjellige nettverkshastigheter
- Bekreft nettstedets oppførsel når enheten er innenfor / utenfor nettverksområdet
- Bekreft nettstedets oppførsel på lav CPU og minne for å støtte forskjellige formfaktorer
For et e-handelsnettsted er kompatibilitetskontrollen en av de viktigste testtypene. Kundebasen vil være stor og vil få tilgang til nettstedet vårt fra forskjellige nettlesere, operativsystemer og enheter.
Med tanke på at mobile plattformer blir populære, bør vi sikre nettstedsbelastning på liten formfaktor under akseptabel ladetid. Det er også viktig å validere bruken av forskjellig nettverkshastighet for å sikre at den er brukbar for alle kunder.
Er nettstedet sikret nok?
Sikkerhetstesting utføres for å avdekke sårbarheter i et system og sikre at et nettsted er sikret.
Nedenfor er sjekklisten som kan verifiseres når du utfører sikkerhetstesting:
- Nettstedet skal være tilgjengelig for bare godkjente brukere
- Nettstedsbrukere skal kunne utføre bare de oppgavene de er autorisert for
- Nettstedet bør verifiseres for CAPTCHA-felt for brukeridentifikasjon
- Innstillinger for nettlesersikkerhet bør verifiseres når du går fra sikre til usikre sider
- Webserverbeskyttelse bør være der for utilgjengelige webkataloger eller filer
- Forsikre deg om at begrensede filer ikke skal lastes ned uten passende tilgang
- Økter som ble inaktive, burde automatisk drepes etter en viss periode
- Alle ugyldige og uautoriserte forsøk fra sluttbrukere eller periodiske systemfeil / svikt bør logges for analyseformål
Verktøy som Sårbarhetsstyring , Veracode, og SQL-kart kan brukes til å utføre sikkerhetstesting av nettstedet ditt.
Som en del av sikkerhetstesting, bør et netthandelsnettsted valideres for
- Nettstedsadgangskontroller.
- Eventuell lekkasje av brukerens personlige informasjon.
- Sikrede betalingsmåter.
Er nettstedets ytelse opp til merket?
For å kontrollere ytelsen til et nettsted, kan ytelsestesting utføres. Den vil evaluere oppførselen til en applikasjon under en rekke arbeidsbelastningsforhold som kan være et realistisk scenario. Hvis systemet går live uten å utføre ytelsestester, kan det ende opp med problemer som et langsomt kjørende system eller dårlig brukervennlighet, noe som sannsynligvis vil påvirke merkevaren samt salg på markedet.
Et nettsted kan testes mot belastning og stress.
Nedenfor er sjekklisten for testing av ytelse på nettet:
- Nettstedsadferd bør følges under normale belastninger og toppbelastning
- Nettstedets ytelse bør undersøkes ved å måle responstid, hastighet, skalerbarhet og ressursutnyttelse
- Riktig RCA (rotårsaksanalyse) bør gjøres med en løsning hvis et system går i stykker eller blir ustabilt når som helst
- Nettverksforsinkelsesproblemer bør identifiseres hvis noen
Et netthandelsnettsted bør testes grundig ved hjelp av et sett med simulerte brukere under normale så vel som toppbelastningsforhold som kan være i løpet av 'Salgssesongen'.
Under salget vil brukere som får tilgang til nettstedet formere seg. Nettstedsadferd bør også undersøkes mens flere samtidige brukere får tilgang til de samme elementene eller utfører de samme handlingene (som transaksjoner eller bestillinger) på nettstedet.
Det er forskjellige verktøy tilgjengelig i markedet for ytelsestesting. Få av dem er det LoadRunner, WinRunner, Silk Performer, JMeter, etc.
Lagres dataene på et nettsted nøyaktig og vedvarer på tvers av økter?
Databasen er en av de kritiske komponentene i et webapplikasjon som inneholder den fullstendige informasjonen som er angitt via et nettsted. Derfor, for å sikre at riktige brukerdata blir lagret i databasetabeller uten noen manipulasjoner, og for å opprettholde dataintegriteten, bør verifikasjoner utføres.
- Bekreft datakonsistens på tvers av brukergrensesnittet, dvs. nettstedsgrensesnitt og database
- Kontroller at DB-tabeller oppdateres riktig når innsettings- / oppdaterings- / slettingshandlinger utføres av et nettstedsprogram
- Bekreft responstiden for tekniske spørsmål og finjuster dem om nødvendig
- Se etter DB-tilkobling og tilgangstillatelser
Som et QA-teammedlem som tester e-handelsnettsted, kan du utføre aktivitetene nedenfor og validere endringene hver gang i de tilsvarende databasetabellene. Dette vil sikre at nettstedsgrensesnittet og DB, begge er konsistente.
1) Bestille et produkt.
2) Avbryter produktet.
3) Velg å bytte produkt.
4) Velg å returnere produktet.
Er nettstedet integrert godt med andre grensesnitt i arbeidsflyten?
Grensesnittnivåtesting utføres for å kontrollere jevn interaksjon på nettstedet med forskjellige grensesnitt som webserver og databaseserver.
Under grensesnitttesting må testeren sørge for om applikasjonsforespørslene blir sendt riktig til databasen, og riktig informasjon vises til klienten som utdata. En webserver skal ikke kaste noen unntak unntak når som helst, og databasen skal alltid være synkronisert med applikasjonen.
Vil nettstedet fungere som forventet selv etter live?
Når et produkt går over i et produksjonsmiljø, bør den regelmessige inspeksjonen gjøres for å kontrollere kvalitetskontrollen.
Nedenfor kan du vurdere når du verifiserer produktet i produksjonen:
- Nettapplikasjonstester bør utføres med jevne mellomrom, og testlogger skal lagres som bevis på at Service Level Agreement (SLA) er i samsvar
- Automatisk skaleringssystemer og lastbalansere bør kontrolleres hvis de er på plass og fungerer
- Hold øye med sluttbrukeropplevelsene og prøv å avdekke mangler eller ondsinnede angrep som vanligvis ikke blir lagt merke til under QA-testing
- Overvåk responstiden for produktet under toppbelastning
- Utfør kantnivå testtilfeller i sanntid for å identifisere nettverksfeil, tilkoblingsfeil eller avbrudd ved en uventet samtale
Konklusjon
Jeg har utarbeidet denne detaljerte opplæringen med mange års erfaring med å teste de forskjellige nettstedene.
Håper denne artikkelen hjelper deg med å forstå de forskjellige fasettene ved testing av webapplikasjoner. Neste gang du sitter for å skrive en testplan for nettstedet ditt, husk å validere forskjellige aspekter utover funksjonaliteten til nettstedet.
Håper denne artikkelen ville ha vært en informativ for deg!
Anbefalt lesing
- Veiledning for testing av webapplikasjoner
- Alpha Testing og Beta Testing (En komplett guide)
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Build Verification Testing (BVT Testing) Komplett guide
- Funksjonstesting mot ikke-funksjonell testing
- Typer programvaretesting: Ulike testtyper med detaljer
- Nybegynnerveiledning for testing av webapplikasjon
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)