responsive web design testing
I dagens tid har bruken av mobile enheter for å få tilgang til internett vokst og blitt ganske populær. Nesten alle Internett-brukere ønsker en mobilversjon av nettstedet.
Imidlertid er de fleste nettsteder ikke så optimaliserte som de burde være for mobile enheter. Testerne bør utføre en mobil responsiv test på responsive design.
Tradisjonelle programvareprodukter gjengir stort sett det samme på alle enheter.
Microsoft Office, for eksempel , ser likt ut på alle personlige datamaskiner. Tenk deg å ta Microsoft Word nøyaktig slik det kjører på skrivebordet, og se det på en iPhone4. Enten vil menyene og knappene virke små, ellers ser du bare et hjørne av skjermen og trenger å bruke omfattende rullefelt. Uansett blir applikasjonen i det vesentlige ubrukelig.
Denne frustrerende opplevelsen er nøyaktig hva hver designer går gjennom når de prøver å designe for nettet.
Løsningen på problemet er noe som kalles “responsiv design”, en teknikk for å få websider til å spørre nettleseren om hva oppløsningen er, og deretter omforme brukerens opplevelse på en elegant måte basert på den tilgjengelige skjermen. Plutselig er det umulig å vite nøyaktig hvordan programvaren din vil se ut i produksjonen.
Det betyr en teststrategi (og en automatiseringsstrategi) som må være i stand til å eksperimentere og lære hva som 'ser riktig ut', og hva som ikke gjør det, i forskjellige oppløsninger.
Hva du vil lære:
- Nybegynnerguide for å teste responsive nettstedsdesign
- Hva er Responsive Web Design?
- Fordeler med responsiv design:
- Hovedkomponenter i responsivt nettsteddesign:
- Responsive webdesigneksempler
- Hvordan teste et responsivt nettsted
- Eksempel på testscenarier for responsiv nettstedstesting:
- Verktøy for å teste et responsivt nettsted
- Utfordringene ved å teste responsivt design og mulige løsninger
- Tips for responsiv nettesting
- Konklusjon
Nybegynnerguide for å teste responsive nettstedsdesign
Når vi prøver å åpne et nettsted, leser serveren “ m.sub-domener ”For å identifisere hva slags mobilenhet forespørselen stammer fra. Basert på det, omdirigerer det brukeren til tilsvarende mobilversjon.
For å gjøre dette 100% effektivt, bør hver enhet ha sin egen utforming av nettstedet spesielt utviklet for det; feller eksempel,et annet spesifikt design for Blackberry, iPhone, iPad, etc. med tanke på skjermstørrelse og oppløsninger.
Ulike nettversjoner for hver oppløsning og enhet er imidlertid ikke praktisk. De Ethan Marcotte kom opp med en ny tilnærming - Responsive Web Design ( RWD ) - som løser dette problemet.
Vår anbefaling
# 1) LT-nettleser
LT-nettleser hjelper brukere med å teste og feilsøke nettstedet deres på 45+ enhetsvisningsport. Test nettstedet ditt på forskjellige forhåndsinstallerte porter for mobile og stasjonære enheter med LT Browser, en utviklingsvennlig nettleser for feilsøking med mobilvisning.
Bare skriv inn nettadressen til nettstedet ditt, velg enheten du vil teste nettstedet ditt på. Du kan samtidig velge to enheter for sammenligning side om side.
Ikke bare testing, men brukere kan også feilsøke nettstedet sitt på farten ved hjelp av innebygde DevTools som tilbys av LT Browser.
Det beste er at brukere kan lage en tilpasset enhet på grunnlag av deres krav som gjør LT Browser til vårt førstevalg for responsiv testing.
=> Besøk LT BrowserHva er Responsive Web Design?
RWDmål for nettsteder å reagere på enheten, oppløsningen og være i stand til å gjengi og tilpasse seg riktig. For eksempel, hvis brukeren bytter fra stasjonær / bærbar PC til iPad, bør nettstedet automatisk tilpasse oppløsningsendringene som bildestørrelse etc. i henhold til de respektive enhetsegenskapene.
Kort oppsummert,Responsiv utforminger “Ett nettsted for hver skjerm” .
Skjermbildet nedenfor er eteksempelav RWD:
Merk: Sanntideksempelav et responsivt nettsted er www.fpl.com
I RWD er et nettsted designet for å gi en overlegen brukeropplevelse gjennom enkel navigering, klart og enkelt brukergrensesnitt, etc. Responsive nettsteder tilpasser seg enkelt og fungerer i alle oppløsninger, nettlesere, skjermstørrelser, maskinvare og operativsystemer.
- Responsive nettsteder er kodet i PHP, .Net, Java, CQ5 (Adobe Experience Manager - AEM) og mange nye rammer som er veldig nyttige for å utvikle responsive design.
- CSS og HTML-funksjoner er utnyttet for å gjøre skjermoppløsninger og bilder blir endret automatisk.
- RW-design bruker breakpoints for å identifisere utformingen av et nettsted. Hver design brukes på forskjellige brytpunkter. Ett design brukes over et brytpunkt, mens et annet design brukes under brytpunktet. Disse brytpunktene er vanligvis basert på bredden på nettleserne.
- Mens de designer et responsivt nettsted, vurderer utviklerne innholdet, designet og ytelsen til nettstedet på alle enheter sikre brukervennlighet .
Diagrammet er en nøyaktig likhet med hvordan innholdet tilpasser seg miljøet og oppførselen til enheten.
Merk : Bortsett fra RWD er det en annen tilnærming som kalles Adaptivt nettdesign ( AWD ) . I AWD-tilnærmingen vil det være en spesifikk design for hver enhet. Imidlertid er AWD kanskje ikke egnet hele tiden. Dessuten tar design av AWD-nettsteder mer tid og penger i forhold til RWD-nettstedene.
Fordeler med responsiv design:
#1) Brukererfaring: Basert på enheten som vi får tilgang til en RW fra, skjuler den de uvanlige elementene og hjelper brukerne med å oppnå sine mål raskere.For eksempel:hvis vi åpner en RW fra mobil, skjuler det de viktige elementene og fremskynder innlastingen av websider.
#to) Deling eller lenking: For en RW brukes bare én URL for forskjellige enheter. Siden bare en enkelt nettadresse samler alle data og informasjon fra forskjellige enheter, gir det en bedre UX for brukere.
# 3) Lite eller minimum vedlikehold kreves for en RW.
# 4) RW-oppsett er flytende.
Forskjeller mellom responsivt nettdesign og adaptivt nettdesign:
RWD og AWD er nært knyttet til hverandre.
- RWD reagerer raskt og positivt på endringene mens AWD lett kan modifiseres for et nytt formål.
- RWD har flere væskegitteroppsett og AWD har flere faste breddeoppsett.
- Bilder i RWD kalles som kontekstbevisste.
Hovedkomponenter i responsivt nettsteddesign:
Responsivt nettdesign har tre hovedkomponenter:
#1) Fleksible oppsett: Å bygge et nettsted med et fleksibelt rutenett som enkelt kan endres dynamisk til hvilken som helst bredde.
#to) Mediespørsmål: Gi forskjellige stiler for nettlesere og enheter basert på konteksten, for eksempel retningen på enheten, visningsport osv.
# 3)Fleksibel medium: Når størrelsen på visningsportene endres, må media (bilder, videoer osv.) Også endre størrelse eller oppløsning i henhold til kravet.
Merk : “Viewport” er området i nettleseren der det faktiske innholdet på nettstedet vises. Viewport inkluderer ikke verktøylinjer, faner osv.
Responsive webdesigneksempler
Eksempel 1)
Åpne lenken www.fpl.com fra forskjellige enheter og følg URL-en. URL-en til et responsivt nettsted forblir den samme for alle enheter.
til) Visning av RW fra en stasjonær eller bærbar datamaskin (stor skjermstørrelse)
b) Visning av RW fra et nettbrett (middels skjermstørrelse)
c) Visning av RW fra en mobil (liten skjermstørrelse)
Eksempel 2)
Åpne siden www.yepme.com fra en bærbar datamaskin og også fra en mobil og sammenlign URL-ene. Dette yepme.com link er ikke en responsiv link.
til) Visning av et nettsted som ikke reagerer fra en stasjonær eller bærbar datamaskin
databasetesting intervju spørsmål og svar
b) Visning av et ikke-responsivt nettsted fra en mobil
Hvordan teste et responsivt nettsted
Responsiv designtest betyr teste nettstedet eller URL fra forskjellige enheter. Det er praktisk talt ikke mulig å teste det responsive nettstedet helt, for å gjøre det må vi sette opp forskjellige systemer for forskjellige skjermstørrelser.
En mulig måte for responsiv test er å endre størrelsen på nettleservinduet i henhold til testscenariet.
Noen nettlesere, som IE og Safari, vil gi plugin-moduler eller nettleserutvidelser som hjelper deg å vise visningsområdet i piksler. Dette gjør testingen enkel ved å få ønsket skjermstørrelse ved å endre pikslene.
Andre nettlesere som Chrome tilbyr programvare eller kalt program “Emulator” som vil bidra til å endre skjermfunksjonene og miljøet i henhold til ønsket enhet som trengs for testing.
Merk: “Emulator” er programvare eller program som tilbys i nettleseren som får vertssystemet (nåværende nettleser) til å oppføre seg som gjestesystemet (nettleseren til ønsket enhet som skal testes for ønsket skjermstørrelse).
Selv om emulatorene ikke kan gi deg det nøyaktige miljøet som trengs for testing, er de en kostnadseffektiv løsning for å teste en RW på høyt nivå.
Eksempel på testscenarier for responsiv nettstedstesting:
Den responsive webdesigntesteren skal sørge for at responsiv design tilfredsstiller alle de nevnte test scenarier for å sikre at det er et feilfritt responsivt design.
#1) Responsiv nettstedslink eller URL bør være den samme for alle nettlesere i hver enhet, uavhengig av skjermoppløsningen.
Anta www.abc.com er et responsivt nettsted. Hvis vi åpner den på en bærbar datamaskin og på en mobiltelefon, bør URL-en være den samme på begge enhetene. Nettstedet som åpnes i mobilnettleseren, skal ikke starte med www.mabc.com eller www.mobile.abc.com
Eksempel: Åpne nettstedet www.kotak.com fra en bærbar datamaskin og også åpne det samme fra mobilen også og observere URL-en i begge enhetene. URL-en er ikke den samme for begge enhetene.
Nedenfor viser øyeblikksbildet hvordan URL-adressen endres for en ikke-responsivt nettsted på forskjellige enheter som bærbar PC og mobil.
Åpne nettstedet www.w3schools.com fra en bærbar datamaskin og fra mobil og sjekk URL-ene. Det skal være det samme for begge enhetene.
Nedenfor øyeblikksbildet viser URL-en forblir den samme for et responsivt nettsted på forskjellige enheter:
#to) Visningsplasseringen til innholdet (bilder, underkoblinger, menyer osv.) På et responsivt nettsted bør endres dynamisk i henhold til endringen i skjermoppløsningen. Det vil si at hvis vi endrer skjermoppløsningen fra størrelsen på den bærbare datamaskinen til en mobil, bør visningen av menyalternativer endres dynamisk.
Eksempel: Åpne lenken www.fpl.com fra en bærbar datamaskin og klikk på menyen i høyre øvre hjørne av vinduet. Menyalternativene vises som vist nedenfor:
hvor er apk-filer lagret på android
Åpen www.fpl.com fra mobil og klikk på menyen i øverste høyre hjørne av vinduet. Menyalternativene er som nedenfor:
Merk: Dette scenariet kan også testes ved hjelp av nettleseremulatorer (Tidligere:krom).
Åpne nettstedet www.fpl.com gjennom et skrivebord og observer hvordan menyalternativene vises. Se øyeblikksbildet nedenfor:
Endre størrelsen på nettleservinduet til det med skjermstørrelse på mobil, og sjekk deretter visningen av menyalternativene. Se øyeblikksbildet nedenfor:
# 3) URLer til et responsivt nettsted bør også være oppløsningsspesifikke.
Forutsetning for å teste dette scenariet: Be utvikleren om å sette inn en hvilken som helst underkobling til nettstedet Responsive testing der sub-linken ikke er responsiv.
For eksempel, kan utvikleren sette inn lenke www.snapdeal.com til testnettstedet vårt.
Nå åpner du det responsive testnettstedet fra en mobil og klikker på underlenken som er nevnt i forutsetningen. Da skal URL-en til underlenken endres til https://m.snapdeal.com .
# 4) Det samme scenariet kan også testes fra en bærbar datamaskin. Åpne RW fra en stasjonær eller bærbar datamaskin og klikk på underkoblingen (nevnt i forutsetningen for testscenario tre) som ikke er responsiv. URL-en til underlenken skal ikke endres (ettersom vi tester dette scenariet fra den bærbare datamaskinen, bør URL-en forbli den samme).
# 5) Forutsetning for å teste dette scenariet: Be utvikleren om å sette inn en hvilken som helst underlenke,for eksempel, www.paytm.com inn på teststedet. Den mobile enheten der du skal utføre dette scenariet, bør ha den respektive applikasjonen av Paytm installert i mobilen.
Åpne nå vårt testresponsive nettsted fra en mobil og klikk på 'paytm' -underkoblingen. Deretter skal Paytm-applikasjonen som er installert i mobilen åpnes. (Brukeren skal ikke omdirigeres til nettstedet i nettleseren eller et annet vindu; bare appen skal være åpen.)
# 6) Bildene på det responsive nettstedet er oppløsningsspesifikke. Det betyr at oppløsningen til bildet som er satt inn i koden til responsivt nettsted designet for mobilkompatibilitet, er forskjellig fra en stasjonær eller nettbrett. Hver skjermstørrelse skal ha sitt spesifikke bilde i designet.
Forutsetning for å teste dette scenariet: Å teste og kontrollere oppløsningen på bildene kan være en tøff oppgave. Be utvikleren om å sette inn tre forskjellige bilder på det responsive nettstedet separat for mobil, nettbrett og stasjonær PC.
Åpne det testresponsive designnettstedet fra skrivebord, nettbrett og mobil. Bildene på den responsive websiden skal være forskjellige for alle de tre enhetene.
(ELLER)
Åpne test-RW fra et skrivebord og sjekk bildet på websiden. Endre størrelsen på vinduet til det på et nettbrett og sjekk bildet. Dette skal være forskjellig fra det som vises på skjermstørrelsen på skrivebordet. Nå kan du endre størrelsen på vinduet til mobilskjermstørrelse og sjekke bildet. Dette bildet skal også være forskjellig fra de to ovennevnte bildene.
Eksempel: Åpne det responsive nettstedet www.fpl.com fra et skrivebord; høyreklikk på bildet på startside -> velg “Inspiser” fra menyen. Kontroller bildeoppløsningen (sjekk filtypen .jpg) fra koden. Se skjermbildet nedenfor:
Endre størrelsen på det samme vinduet til skjermstørrelsen på nettbrettet, og se etter bildeoppløsningen. (Navnet på utvidelsen er medium.jpg)
Til slutt endrer du størrelsen på vinduet til størrelsen på en mobil skjermstørrelse og sjekker bildet. (Navnet på utvidelsen er small.jpg)
# 7) Klikk tilfeldig hvor som helst på websiden og sjekk om data eller tekst som ikke er hyperkoblet blir startet og omdirigert til annen side eller innhold. Dette tester om noe ord eller tekst er merket som hyperkoblingen i baksiden .
Merk : I noen få prosjekter snakker kravene om pikselstørrelse og oppløsning på skjermen for bestemte enheter. (For eksempel, en nettbrettvisning for deres RW bør være på 15:15 piksler og for en mobil, den skal være på 10:10 osv.)
Å teste for de dynamiske endringene som skal skje for RW-skjermen når vi endrer pikselstørrelsen er hovedscenariet.
# 8) Åpne vår test-RW i en nettleser og se innholdet og visningen av hovedbildene. Endre størrelsen på vinduet til brytpunktet for nettbrettstørrelsen, og kontroller endringene som skal skje med bildeoppløsningen og annet innhold. Ved brytepunktene bør endringene skje dynamisk (noen ganger vil ikke endringene skje ved brytepunktene og kan endres i en annen pikselstørrelse som er en feil.)
Verktøy for å teste et responsivt nettsted
Det er få verktøy (nettsteder) som lar deg forhåndsvise nettsidene til vårt responsive nettsted.
For eksempel,Vi kan teste det responsive nettstedet vårt med forskjellige forhåndsdefinerte skjermoppløsninger (smarttelefoner, nettbrett, etc.) og også tilpasse til ønsket oppløsning. Disse verktøyene gjør testaktiviteter enklere og raskere. Slike verktøy i nettleseren kan betegnes som Responsinator .
Noen verktøy tilbyr også en viktig funksjon for å fange det responsive skjermbildet som kan hjelpe oss med å teste nettstedsdesign, HTML, layout, CSS, etc. på det responsive nettstedet.
Disse verktøyene er gode alternativer når de faktiske enhetene ikke er tilgjengelige eller klare.
Her er en rask verktøyliste:
Skriv inn URL-adressen til det responsive nettstedet som må testes, i feltet 'Skriv inn URL-en din her' ovenfor og klikk 'GO'. Du kan til og med velge enheten og oppløsningen der du vil se det responsive nettstedet.
Gå inn www.fpl.com i feltet, velg oppsettet “Nexus 7 PORTRAIT” og klikk GO. Nettstedet blir vist i oppløsningen til det valgte formatet.
#to) Screenfly
Gå inn på teststedet www.fpl.com og klikk på GO.
Endre oppsettet til skrivebord, nettbrett, mobil osv., Og test nettstedet. Med dette verktøyet kan du til og med tilpasse oppløsningen.
For eksempel, still skjermoppløsningen til 512 x 256 og test nettstedet.
Merk : Med dette verktøyet kan du til og med teste scenario 6 enkelt ved å endre oppløsningen og verifisere navngivningen av bildet.
# 3) Designmodo
Skriv inn hvilken som helst URL, www.makemytrip.com og klikk Enter.
På høyre side av nettleseren har du muligheten til å endre nettstedsoppsettet til en bestemt mobilmodell eller enhet etc.
Merk : Dette verktøyet har en annen funksjon som å dra skjermen og endre oppløsningen til ønsket oppløsning.
# 4) svarer
Skriv inn test-URL, www.fpl.com i feltet og klikk på “Test” -knappen.
Merk: Dette verktøyet har bare noen få faste layoutalternativer som nettstedet vårt kan testes på.
# 5) Mattkersley
Hvis du vil ha en visning av RW-en på flere skjermstørrelser om gangen, er dette verktøyet mattkersley er det du trenger.
Skriv inn test-URL-en din i adressefeltet, og klikk på Enter. Du kan se RW på flere skjermstørrelser om gangen.
# 6) Som standard, krom har få Dev-verktøy som vi kan simulere enhetsmodus og deres evner gjennom.
For å bruke denne funksjonen i krom, åpne et hvilket som helst testresponsivt designnettsted som www.fpl.com i krom og høyreklikk på websiden og velg 'Inspiser' fra menyen eller trykk Ctrl + Shift + I. Vinduet nedenfor åpnes nederst på websiden.
Klikk nå på ikonet som vist på skjermbildet nedenfor.
Mobilmodus på websiden blir åpnet. Fra det kan du endre oppløsningen til en hvilken som helst spesifikk piksel og til hvilken som helst forhåndsdefinert mobilmodell som vises i rullegardinmenyen. Se øyeblikksbildet nedenfor for å få en klar ide:
Merk: Vi kan også endre nettsiden til stående eller liggende.
Andre gode verktøy for å teste responsiv design:
7) Responsiv utforming
8) BrowserStack
9) Troy
10) AmIResponsiveDesign
elleve) Responsinator
12) Studiopress
1. 3) ResponsiveTest
14) For MAC-maskiner har vi en egen applikasjon kalt “ PASSE ”For å teste en RW. Denne applikasjonen lar deg sette opp forskjellige brytpunkter på forskjellige enheter for testing. APTUS er ikke et gratis program, og vi må kjøpe det fra Mac App Store.
Utfordringene ved å teste responsivt design og mulige løsninger
Dynamisk teststrategi
Å flytte fra 320 × 480 (oppløsningen til iPhone4) til 2048 × 2048 (en stor skjerm) gir mer enn 4 millioner mulige nettleserstørrelser. De fleste testgrupper vil begrense listen over testenheter til en håndfull. Selv da er det manuelle testproblemet vanskelig eller umulig å nærme seg.
gratis anime streaming nettsteder engelsk kalt
Utviklere kan umulig forutse alle plattformproblemene, og testere kan ikke fange dem før de slippes. På grunn av dette finner vi sporadisk et brukergrensesnittproblem i produksjonen.
Kanskje noen har redusert størrelsen på nettleseren sin, og viktige tekstfelt dekkes av en sidetikett. Kanskje noen koder designet for å håndtere dynamisk sidestørrelse, bryter modale datovelgere og blir aldri lagt merke til av en normal test bygget på WebDriver. Det er for mange visningsalternativer for å lage tester for og for lite tid.
La oss ta en titt på enrealistisk eksempelfor å illustrere problemet.
Dynamiske sider, ting som reklamebrytere, og innhold som streames inn fra brukere i forskjellige sidestørrelser, er en stift for mange programvareprodukter. Legg til det faktum at vi ikke kan forutsi hvordan siden vil vises, og mange automatiseringsarbeid starter med feil.
Jeg ser to populære løsninger for dette problemet - ved hjelp av et standardisert, eller baseline, datasett og forfriskende som hver gang testpakken kjøres, og tar ting ett miljø eller en plattform om gangen.
Standarddata sikrer at sideinnholdet vil se likt ut hver gang vi laster inn testmiljøet. Denne strategien kombinert med noe som Sauce Labs som gir folk tilgang til mange plattformer, og du kommer ganske langt.
Denne tilnærmingen tar tid og ressurser. Du trenger tid fra noen med databasetilgang, vanligvis en DBA, for å opprette og oppdatere databaseeksport. Og noen må lage skriptoppsett og nedrivningsskript for å opprettholde testmiljøet. Etter all denne innsatsen kan du ende opp med den typen sanerte miljøfeil som elsker å gjemme seg i.
Alternativt kan du bruke Visual Testing-teknologi for å automatisere tester på websider som varierer i layout og innhold. Ved hjelp av dette verktøyet kan du lage tester uten endringer i testmiljøet ditt, og uten å kreve noen ferdighetssett fra personer utenfor testgruppen din.
La oss se på et eksempel.
Vurder Twitter-mobilappen.
Dette produktet er en kombinasjon av kontinuerlig skiftende brukerinnhold og annonsering. Det er også noen få kjerndeler i brukergrensesnittet, som nyhetsfeed og varsler, i overskriften.
Ved å bruke et visuelt testverktøy kan du starte med å utføre en skjermopptak av hele siden som kan rulles, ikke bare det synlige området. Du kan velge et sammenligningsalternativ som ignorerer tekstinnhold, men fokuserer på elementene på siden.
For eksempel, Du kunne se at feltene for tweets eksisterer, at hver tweet har et navnelement og et dato / klokkeslett, uten å bekymre deg for hva som er i elementene.
Å søke etter elementer på tvers av hele sider avlaster også vedlikeholds- og kompleksitetsbelastningen vi ser i mange automatiserte tester. I stedet for å manipulere data på en side, lagre, bla og deretter bekrefte, får du alt i ett skudd. Dette betyr mindre kode å skrive, mindre kode å vedlikeholde og færre falske positive i testkjøringene om natten.
Responsiv testing for responsiv design:
Responsiv design har lagt det kombinatoriske problemet til alle tilgjengelige plattformer. Spørsmålet er; ut av alle disse mulige plattformene og skjermstørrelsene, hvilke velger vi for best testdekning.
Å redusere antall miljøer vi dekker til bare de mest populære, gjør den tekniske oppgaven enklere og ignorerer også dekningsproblemet.
Å øke antall miljøer med et automatiseringsrammeverk alene skaper et vedlikeholds-mareritt og potensielt tilfører et uløselig testproblem.
Kombinasjonen av gode visuelle testverktøy med et fleksibelt rammeverk for automatisering av brukergrensesnittet, for eksempel webdriver, kan gjøre de tekniske aspektene av dette problemet ikke bare lettere å håndtere, men også løselige.
Målet er god dekning av brukergrensesnittet med en rimelig vedlikeholdsbyrde. Visuell testing er det eneste robuste og skalerbare alternativet.
Tips for responsiv nettesting
#1) Når du tester en RW, bør du være oppmerksom på designkonsistensen, slik som justering av bilder, tekster, polstring rundt kantene osv. Over alle nettlesere og operativsystemer.
#to) Under testingen av en RW bør testeren være klar over hva du skal teste og hvordan du tester på flere enheter ved forskjellige brytpunkter. Ellers kan det være ganske uttømmende og desorienterende.
# 3) For grundig testing av et responsivt nettsted, er testeren og utviklerkoordinasjonen et must. Utvikleren skal hjelpe testere med å lage de forholdene som er nevnt i forutsetningene for testsakene.
# 4) Sjekk om websidene er lesbare i alle oppløsninger, dvs. innholdet skal være lesbart, selv om vi endrer størrelsen på nettleseren til mobilskjermstørrelse.
# 5) Det viktige innholdet i RW skal være synlig for alle brytpunkter, dvs. hvis vi endrer nettleserstørrelsen fra skrivebordet til mobilskjermen, så bør hovedbildene, hovedteksten, menyen osv. Være de samme.
# 6) Hvis nettleseren er endret for å teste, bør ethvert klikkområde (som knapper, menyer, underkoblinger osv.) Av RW være egnet for å klikke.
# 7) Endring av størrelse på nettleseren og testing av det responsive nettstedet kan bare identifisere noen få hovedproblemer, mens det kan være noen få andre problemer relatert til finger-swipes, tapping osv. På mobile enheter. Å teste disse spesifikke funksjonene på de faktiske enhetene kan føre til bedre feilsøking og fjerning.
Konklusjon
Når vi tester, vil responsiv design ha mange utfordringer. Du bør tenke på en effektiv måte for å overvinne utfordringene.
Å teste et responsivt nettsted er veldig viktig for en vellykket fremtid for mange mobile applikasjoner. Mobilbrukere kommer bare til å øke, og forventningene deres er veldig varierte fra desktop-brukere. Implementering og grundig testing av RWD er en fin måte å sette nettstedet ditt opp til å møte forventningene.
Implementering og grundig testing av RWD er en fin måte å sette nettstedet ditt opp til å møte forventningene.
Vi håper informasjonen, tipsene og testscenariene som er diskutert i denne artikkelen, vil helt sikkert hjelpe dine responsive nettstedsbehov.
Om forfatteren: Dette er et gjestepost av Laxmi. Hun har 7+ års erfaring med programvaretesting og jobber for tiden som senior programvaretestingeniør.
Prøv alle eksemplene i denne artikkelen, og gi oss beskjed hvis du har spørsmål / kommentarer om det samme.
Anbefalt lesing
- Alpha Testing og Beta Testing (En komplett guide)
- Build Verification Testing (BVT Testing) Komplett guide
- Funksjonstesting mot ikke-funksjonell testing
- Typer programvaretesting: Ulike testtyper med detaljer
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
- Veiledning for testing av webapplikasjoner
- Beste QA Software Testing Services fra SoftwareTestingHelp