an excellent way data testing using xml technologies
I SDLC , hvis applikasjonen bruker fossemodell, er testaktiviteter planlagt til slutt. Dette utgjør en risiko for omarbeid med hensyn til krav, design, kode og testtilfeller hvis QA-teamet identifiserer feil. Det er bedre å unngå å vente til slutten for å identifisere manglene i en applikasjon.
Tester som ikke er basert på funksjonell utførelse av applikasjonen, kan finne feil uten å foreskrive frigjøring av alle komponentene i testmiljøet. Dette kan oppnås ved datatesting.
XML og relaterte teknologier som brukes til kommunikasjon mellom forskjellige nivåer i et program, gir en mulighet til å utføre testene som ikke trenger å vente til hele applikasjonen er lett tilgjengelig for testing.
Dette dokumentet skisserer en mulig måte å se på datatestealternativet tidlig i livssyklusen til en produktutgivelse.
Hva du vil lære:
Antagelse:
Dette dokumentet forutsetter at leseren er kjent med programvare testing konsepter og grunnleggende bruk av en database og XML-teknologier.
Fokusgruppe:
QA team (QA), data team (DT), developer (DEV)
Hensikt:
De eksempeldata identifisert for testing av et produkt definerer omfanget av utførte tester, gir tillit til testresultatene og kvaliteten på produktet. Å identifisere dataene for en test avhenger av kravene til testen som skal utføres.
Dette dokumentet fokuserer på å validere testdata før du ser dem i brukergrensesnittet.
Denne prosessen trenger testdataadministrasjon for å få effektive testresultater. Data som vi alle vet kan lagres i en database eller en flat fil. Men dataoverføringen fra / til en database kan håndteres ved hjelp av XML. Det eksisterer et veldig nært forhold mellom XML (1), XSD (2), XPATH (3) og XSLT (4). (Se alle definisjonene nedenfor).
(1) XML - er X strekkbar M arkup L anguage. Det er en anbefaling fra World Wide Web Consortium (W3C) å beskrive data. Med et sett med riktige syntaksregler, kan man sikre at et XML-dokument er “godt formet”
(to) XSD - Brukes til å betegne strukturen til et XML-dokument. Et 'godt utformet' XML-dokument kan valideres mot et XSD (XML-skjema) for å validere det
(3) XPATH - En 'gyldig' og 'godt utformet' XML bør navigeres gjennom for å plukke opp passende data fra XML. XPATH-uttrykk ser ut som en tradisjonell filbane i en katalog.
(4) XSLT - er X strekkbar S dekkark L anguage T ransformasjoner - Mens du representerer dataene fra en XML i et brukergrensesnitt (UI), kan hvilken som helst stil (skrift, farge, størrelse osv.) brukes med XSLT. XSLT bruker XPath for å finne informasjon fra XML.
Data presentert i XML er validert mot et skjema (XSD-fil). XML kan sendes ut i forskjellige formater med XSLT og XPATH.
hva er din tilnærming når du tester mobilapplikasjoner
For formålet med denne diskusjonen skal vi bruke følgende eksempel.
Eksempel - Et forlag har et nettsted som viser informasjon om bøkene det har gitt ut. En av websiden viser et sammendrag om hvert kapittel i en bok. Testing bør sikre at innholdet er passende på denne websiden. Forlaget har nå gitt ut millioner av bøker.
All informasjon relatert til de publiserte bøkene lagres i en database. Likevel trenger den aktuelle nettsiden en delmengde av dataene (om en ny bok og dens kapitler) som skal ekstraheres fra databasen til en XML.
XML gitt nedenfor representerer metadataene om boka.
XML-fil Book.xml
A book on test data Jim 2015 Technical English 120 10 Acknowledgement Introduction What is data List of references
XML Schema Book.xsd
Test livssyklus for datadministrasjon
I likhet med annen prosess, test datahåndtering har sine egne livssyklus (LC) stadier.
- Identifiser datakrav
- Planlegg datainnsamling
- Bygg dataene
- Test dataene
- Datavedlikehold (ikke detaljert i dette dokumentet fordi det ikke er relevant)
#1. Identifiser datakrav
I eksemplet ovenfor lagrer databasen millioner av poster. Hvis innholdet i alle bøkene blir hentet ut i en XML-fil, krever det detaljert validering. Når og når ny informasjon må sendes ut på websiden, kan XML og skjemaet gjennomgå endringer.
Endringene i XML, XSD, XPATH og XSLT krever riktig validering. Men denne testingen trenger ikke vente på presentasjon, mellomvare og datalagutgivelse. QA-team kan analysere XSD for å utarbeide datakravsplan.
Livssyklusstadium | Oppføringskriterier | Aktiviteter / Ansvar | Utgangskriterier |
---|---|---|---|
Identifiser krav til testdata | Følgende dokumenter er tilgjengelige Database design, UI design, kravspesifikasjon, teknisk arkitektur, dataflytdiagram, Use case diagrammer | Forstå datakravene som refererer til dokumentene fra oppføringskriterier (QA, DT, DEV) Testdatakrav (QA, DT, DEV) - Dokumenterer alle databehov for hver skjerm som viser en kartlegging mellom skjermvisningsnavn og tilsvarende XML-element | Gjennomgå kravene til testdata (QA, DEV, DT) |
Prosessen med å identifisere alle datakravene for et produkt bør adressere følgende:
a) Dekning og fullstendighet - Dekker de identifiserte kravene alle brukssaker?
Eksempel - Det er veldig viktig å teste datakombinasjonene for tittel, forfatter, kategori, språk i XML-eksemplet ovenfor; siden skjemaet mandater disse feltene.
Dette kan enkelt håndteres ved å se på XML-skjemaet som beskriver tilstedeværelsen av et element / attributt og deres rekkefølge i XML
b) Kvalitet - Er dataene samlet inn av best mulig kvalitet? Testdataene som brukes bestemmer kvaliteten på testingen som er utført på applikasjonen.
- Positivt og negative scenarier - Testing bør sjekke hvordan applikasjonen oppfører seg med gyldige / ugyldige inndata
De testdata krav dokument viser databehov på tvers av alle nivåer i applikasjonen. Data fra databasen kan brukes direkte i brukergrensesnittet og / eller manipuleres (beregninger, sammenkobling osv.). Derfor er det nødvendig å fange opp alle databehov.
Tabellen nedenfor representerer en eksempeldatatabell:
Feltnavn | Data-type | Testdata | Merknader | Prøve resultater |
---|---|---|---|---|
Forfatter | String | Tomt felt | Siden det er et obligatorisk felt. Testen skal mislykkes. | |
Forfatter | String | Forfatter + @ | Har spesialtegn | Denne testen skal mislykkes |
Forfatter | String | Forfatternavn | Inkluderer et mellomrom | Denne testen skal bestå |
Forfatter | String | 123 Forfatter | Starter med et nummer | Denne testen skal mislykkes |
Forfatter | String | @!Forfatter | Starter med spesialtegn | Denne testen skal mislykkes |
Forfatter | String | Forfatter | Prefiksert med mellomrom | Denne testen skal mislykkes |
I eksemplet ovenfor kan bruk av strengdatatype for forfatterfeltet unngås. I stedet kan et mønster håndheves.
F.eks. bare alfabeter, start med en stor bokstav, ingen spesialtegn osv. A mønster (begrense en elementverdi definert i XSD) kan defineres som .
Hvis dette er satt for forfatter elementet i eksemplet ovenfor betyr det forfatter elementet skal ha verdien med en kombinasjon av store, små bokstaver og positive heltall.
# 2. Planlegg datainnsamling
LC scene | Oppføringskriterier | Aktiviteter / Ansvar | Utgangskriterier |
---|---|---|---|
Planlegg datainnsamling | Godkjent dokument for testdata | Identifiser hyppigheten av databehov (DEV, QA) Liste testdata (QA) Definer XML-skjema (DEV) | Gjennomgå frekvensen av databehov og testdata (DT) |
# 3. Bygg dataene
LC scene | Oppføringskriterier | Aktiviteter / Ansvar | Utgangskriterier |
---|---|---|---|
Bygg data | Dataforespørsel fil | Bygg dataene i DB (DT) Pakk ut dataene fra DB til XML (DT) Valider XML mot skjema (DT) Del XML-filen med QA (DT) | XML-fil mottas av QA-teamet |
# 4. Test dataene
LC scene | Oppføringskriterier | Aktiviteter / Ansvar | Utgangskriterier |
---|---|---|---|
Test dataene | XML-fil for dataforespørsel | Valider XML mot skjema for fullstendighet og korrekthet (QA) Oppdater kartleggingsdokumentet med testresultater (QA) | Testresultater delt med DEV, DT-teamet |
Som oppført i tabellene ovenfor validerer QA XML mot skjemaet for å sjekke om dataene er tilgjengelige som forventet. Når skjemaet samsvarer, kan innholdet og strukturen bekreftes å være bra. Likevel bekrefter dette ikke at dataene blir plukket opp nøyaktig av systemet.
Som vi vet viser XML en trestruktur med p arent-barn-søsken-forfader-etterkommere forholdet mellom nodene.
Se på tabellen nedenfor for å forstå de enkleste XPATH-konvensjonene:
topp markedsundersøkelsesbedrifter i verden
For å representere feltene fra XML på en skjerm (som HTML for eksempel) brukes XSLT - XPATH kombinasjon.
Latest Book
Title Author Publication_Year Category Language Pages
I en nettleser blir endelig den resulterende XML representert som nedenfor. Siden dataene allerede er verifisert, kan testfokuset være mer på skjermen.
Konklusjon
- Datatesting utført tidlig i utviklings-testing livssyklus sparer penger ettersom kostnadene ved å fikse en feil under funksjonell testutførelse er mye mer enn å fikse den tidlig i livssyklusen
- Innsatsen som ble brukt først på å validere XML-filen, XPath og XSLT med XSD-dokumenter, hjelper med å unngå flere iterasjoner av utgivelsen
- QA-teamet kan jobbe tett med utviklingsteamet og tilby en verdiøkende tjeneste
- QA-team kan hjelpe til med å spotte forskjellige kombinasjoner av data for å sikre dekning og korrekthet
Jeg er sikker på at du vil finne denne teknikken nyttig. Kommenter gjerne hvis du har spørsmål.
Anbefalt lesing
- En enkel tilnærming for XML til databasetesting
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Viktige forskjeller mellom Black Box Testing og White Box Testing
- Topp 10 populære datavareverktøy og testteknologier
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
- Testing Primer eBook Download
- Hva er mutasjonstesting: opplæring med eksempler
- Hvordan utføre datadrevet testing ved hjelp av TestComplete Tool