Què són les dades de prova? Proveu tècniques de preparació de dades amb exemple

what is test data test data preparation techniques with example

Obteniu informació sobre què són les dades de prova i com es preparen les dades de prova per provar-les:

En l'època actual del creixement revolucionari de la informació i la tecnologia, els provadors solen experimentar un gran consum de dades de proves en el cicle de vida de les proves de programari.

Els provadors no només recopilen / mantenen dades de les fonts existents, sinó que també generen grans volums de dades de proves per garantir la seva contribució en auge de qualitat en el lliurament del producte per al seu ús real.

Per tant, com a provadors hem d’explorar, aprendre i aplicar contínuament els enfocaments més eficients per a la recopilació, generació, manteniment, automatització i gestió de dades completa de dades per a qualsevol tipus de prova funcional i no funcional.

En aquest tutorial, us proporcionaré consells sobre com preparar les dades de la prova de manera que no es perdi cap cas de prova important si es produeixen dades incorrectes i una configuració incompleta de l'entorn de prova.

Què aprendreu:

• Què són les dades de prova i per què és important
  • Provar reptes de proveïment de dades
  • Estratègies per a la preparació de dades de proves
  • Dades de proves corruptes
  • Dades de prova per al cas de prova de rendiment
  • Com es preparen les dades que garanteixin la màxima cobertura de les proves?
  • Dades per a proves de Black Box
  • Exemple de dades de prova per a EMR AUT obert
  • Creació de dades manuals per provar l'aplicació Open EMR
• Propietats d'una bona prova de dades
  • Propietats de les dades de prova
  • Provar tècniques de preparació de dades
  • Enfocaments de generació de dades de prova:
  • Conclusió
  • Lectura recomanada

Què són les dades de prova i per què és important

En referència a un estudi realitzat per IBM el 2016, la cerca, gestió, manteniment i generació de dades de proves abasta un 30% a un 60% del temps dels verificadors. És una evidència innegable que la preparació de dades és una fase de proves de programari que requereix molt de temps.

Figura 1: Temps mitjà comprovat pels provadors a TDM

No obstant això, és cert en moltes disciplines que la majoria de científics de dades dediquen un 50% a un 80% del temps de desenvolupament del seu model a l’organització de les dades. I ara, tenint en compte la legislació i la informació d’identificació personal (PII), fa que els comprovadors es comprometin d’una manera immensa en el procés de proves.

Avui en dia, la credibilitat i la fiabilitat de les dades de prova es consideren un element sense compromís per als propietaris d’empreses. Els propietaris de productes veuen les còpies fantasma de les dades de proves com el repte més gran, cosa que redueix la fiabilitat de qualsevol aplicació en aquest moment únic de la demanda / requisits dels clients per a la garantia de qualitat.

Tenint en compte la importància de les dades de prova, la majoria dels propietaris de programari no accepten les aplicacions provades amb dades falses o menys en mesures de seguretat.

En aquest moment, per què no recordem què són les dades de prova? Quan comencem a escriure els nostres casos de prova per verificar i validar les funcions donades i els escenaris desenvolupats de l’aplicació sota la prova, necessitem informació que s’utilitzi com a entrada per realitzar les proves per identificar i localitzar els defectes.

preguntes sobre l'entrevista de desenvolupadors de salesforce per a usuaris experimentats

I sabem que aquesta informació ha de ser precisa i completa per esbrinar els errors. És el que anomenem dades de prova. Per fer-la exacta, poden ser noms, països, etc ... que no siguin sensibles, on les dades relatives a la informació de contacte, SSN, historial mèdic i informació de la targeta de crèdit són sensibles.

Les dades poden ser de qualsevol forma com:

• Dades de proves del sistema
• Dades de prova SQL
• Dades de proves de rendiment
• Dades de prova XML

Si escriviu casos de prova, necessitareu dades d’entrada per a qualsevol tipus de prova. El verificador pot proporcionar aquestes dades d’entrada en el moment d’executar els casos de prova o l’aplicació pot triar les dades d’entrada necessàries a les ubicacions de dades predefinides.

Les dades poden ser qualsevol tipus d’entrada a l’aplicació, qualsevol tipus de fitxer carregat per l’aplicació o entrades llegides de les taules de la base de dades.

Preparar les dades d’entrada adequades forma part de la configuració de la prova. En general, els provadors en diuen a preparació del banc de proves . Al banc de proves, tots els requisits de programari i maquinari s’estableixen mitjançant els valors de dades predefinits.

Si no teniu l’enfocament sistemàtic per crear dades mentre escriure i executar casos de proves llavors hi ha probabilitats de perdre alguns casos de prova importants. Els verificadors poden crear les seves pròpies dades segons les necessitats de proves.

No confieu en les dades creades per altres provadors ni en les dades de producció estàndard. Creeu sempre un conjunt de dades nou segons els vostres requisits.

De vegades, no és possible crear un conjunt de dades completament nou per a cada compilació. En aquests casos, podeu utilitzar dades de producció estàndard. Però recordeu afegir / inserir els vostres propis conjunts de dades en aquesta base de dades existent. Una de les millors maneres de crear dades és fer servir les dades de mostra o el banc de proves existents i afegir les dades de casos nous de prova cada vegada que obtingueu el mateix mòdul per provar-les. D'aquesta manera, podeu crear un conjunt de dades complet durant el període.

Provar reptes de proveïment de dades

Una de les àrees en la generació de dades de proves, considerades pels verificadors, és el requisit d’obtenció de dades per al subconjunt. Per exemple, teniu més d’un milió de clients i en necessiteu mil per provar-los. I aquestes dades de mostra haurien de ser consistents i representar estadísticament la distribució adequada del grup objectiu. En altres paraules, se suposa que hem de trobar la persona adequada per provar, que és un dels mètodes més útils per provar els casos d’ús.

I aquestes dades de mostra haurien de ser consistents i representar estadísticament la distribució adequada del grup objectiu. En altres paraules, se suposa que hem de trobar la persona adequada per provar, que és un dels mètodes més útils per provar els casos d’ús.

A més, hi ha algunes restriccions ambientals en el procés. Un d’ells és el mapatge de polítiques d’IPE. Com que la privadesa és un obstacle important, els provadors han de classificar les dades PII.

Les eines de gestió de dades de prova estan dissenyats per abordar el problema esmentat. Aquestes eines suggereixen polítiques basades en els estàndards / catàleg que tenen. Tot i això, no és un exercici molt segur. Encara ofereix l'oportunitat d'auditar sobre allò que es fa.

Per estar al dia amb l’abordatge dels reptes actuals i fins i tot futurs, sempre hauríem de fer preguntes com Quan / on hauríem d’iniciar la conducta de TDM? Què s’ha d’automatitzar? Quina inversió haurien d’assignar les empreses per provar-les en àrees de desenvolupament continu de competències en recursos humans i en l’ús de noves eines TDM? Hem de començar a fer proves amb proves funcionals o no funcionals? I preguntes molt més probables com aquestes.

A continuació s’esmenten alguns dels reptes més habituals de l’aprovisionament de dades de proves:

• És possible que els equips no tinguin coneixements i habilitats adequades per generar dades de proves
• La cobertura de dades de proves sovint és incompleta
• Menys claredat en els requisits de dades que cobreixen les especificacions de volum durant la fase de recollida
• Els equips de proves no tenen accés a les fonts de dades
• Retard en donar accés a les dades de producció als provadors per part dels desenvolupadors
• És possible que les dades de l'entorn de producció no es puguin utilitzar del tot per fer proves basades en els escenaris empresarials desenvolupats
• Pot ser que necessitin grans volums de dades en un curt període de temps
• Combinacions i dependències de dades per provar alguns dels escenaris empresarials
• Els provadors passen més temps del necessari per comunicar-se amb arquitectes, administradors de bases de dades i autoritzacions per obtenir dades
• La majoria de les dades es creen o es preparen durant l'execució de la prova
• Múltiples aplicacions i versions de dades
• Cicles d'alliberament continu en diverses aplicacions
• Legislació per vetllar per la informació d'identificació personal (PII)

Al costat del quadre blanc de la prova de dades, els desenvolupadors preparen les dades de producció. És aquí on la necessitat de QA de treballar de manera tàctil amb els desenvolupadors per afavorir la cobertura de les proves d’AUT. Un dels majors reptes és incorporar tots els escenaris possibles (100% cas de prova) amb tots els casos negatius possibles.

En aquesta secció, hem parlat dels desafiaments de les dades de proves. Podeu afegir més reptes a mesura que els hàgiu resolt en conseqüència. Posteriorment, explorem diferents enfocaments per gestionar el disseny i la gestió de dades de proves.

Estratègies per a la preparació de dades de proves

Sabem per la pràctica quotidiana que els actors de la indústria de les proves experimenten contínuament diferents maneres de millorar els esforços de proves i, sobretot, la seva eficiència en termes de costos. En el curt curs de l’evolució de la informació i la tecnologia, hem vist quan les eines s’incorporen als entorns de producció / proves, el nivell de producció augmenta substancialment.

Quan parlem de la exhaustivitat i la cobertura completa de les proves, depèn principalment de la qualitat de les dades. Com que les proves són l’eix vertebrador per assolir la qualitat del programari, les dades de prova són l’element bàsic del procés de prova.

Figura 2: Estratègies per a la gestió de dades de proves (TDM)

Creació de fitxers plans basats en les regles de mapatge. Sempre és pràctic crear un subconjunt de dades que necessiteu des de l’entorn de producció on els desenvolupadors van dissenyar i codificar l’aplicació. De fet, aquest enfocament redueix els esforços dels provadors en la preparació de dades i maximitza l’ús dels recursos existents per evitar despeses addicionals.

Normalment, hem de crear les dades o almenys identificar-les en funció del tipus de requisits que cada projecte té al principi.

Podem aplicar les estratègies següents per gestionar el procés de TDM:

1. Dades de l’entorn de producció
2. Recuperació de consultes SQL que extreuen dades de les bases de dades existents del client
3. Eines automatitzades de generació de dades

Els verificadors hauran de fer una còpia de seguretat de les proves amb dades completes tenint en compte els elements que es mostren a la figura 3 aquí. Els restants en equips de desenvolupament àgils generen les dades necessàries per executar els seus casos de prova. Quan parlem de casos de prova, ens referim a casos de diversos tipus de proves, com ara el quadre blanc, el quadre negre, el rendiment i la seguretat.

En aquest punt, sabem que les dades per a les proves de rendiment haurien de poder determinar la rapidesa amb què el sistema respon sota una determinada càrrega de treball per estar molt a prop d’un gran volum de dades reals o en viu amb una cobertura significativa.

Per fer proves de caixa blanca, els desenvolupadors preparen les dades necessàries per cobrir el màxim nombre de branques possibles, tots els camins del codi font del programa i la interfície d'aplicació (API) negativa.

Figura 3: Activitats de generació de dades de prova

Finalment, podem dir que tothom que treballa en el cicle de vida del desenvolupament de programari ( SDLC ), com ara els BA, els desenvolupadors i els propietaris de productes haurien d’estar ben implicats en el procés de preparació de dades de prova. Pot ser un esforç conjunt. I ara us deixem a la qüestió de les dades de prova danyades.

Dades de proves corruptes

Abans d'executar qualsevol cas de prova sobre les nostres dades existents, hem d'assegurar-nos que les dades no estiguin corrompudes / obsoletes i que l'aplicació de la prova pugui llegir la font de dades. Normalment, quan hi ha més d'un provador que treballa en diferents mòduls d'un AUT a l'entorn de proves alhora, les possibilitats que les dades es corrompin són tan altes.

En el mateix entorn, els verificadors modifiquen les dades existents segons les seves necessitats / requisits dels casos de prova. Sobretot, quan els provadors acaben amb les dades, deixen les dades tal com són. Tan bon punt el següent comprovador recull les dades modificades i realitza una altra execució de la prova, hi ha la possibilitat que es produeixi un error de prova concret que no sigui l'error o el defecte del codi.

En la majoria dels casos, és així com les dades es corrompen i / o queden obsoletes, cosa que provoca un fracàs. Per evitar i minimitzar les possibilitats de discrepància de les dades, podem aplicar les solucions de la manera següent. I, per descomptat, podeu afegir més solucions al final d’aquest tutorial a la secció de comentaris.

1. Tenir la còpia de seguretat de les vostres dades
2. Torneu les dades modificades al seu estat original
3. Divisió de dades entre els provadors
4. Mantingueu l’administrador del magatzem de dades actualitzat per a qualsevol canvi o modificació de dades

Com mantenir intactes les dades en qualsevol entorn de prova?

La majoria de les vegades, molts provadors són els responsables de provar la mateixa versió. En aquest cas, més d’un provador tindrà accés a dades comunes i intentarà manipular el conjunt de dades comuns segons les seves necessitats.

Si heu preparat dades per a alguns mòduls específics, la millor manera de mantenir intacte el vostre conjunt de dades és conservar-ne còpies de seguretat.

Dades de prova per al cas de prova de rendiment

Les proves de rendiment requereixen un conjunt de dades molt gran. De vegades, la creació de dades manualment no detectarà alguns subtils errors que només poden ser capturats per les dades reals creades per l'aplicació sotmesa a prova. Si voleu dades en temps real, que és impossible crear manualment, demaneu al vostre responsable o responsable que les faci disponibles des de l’entorn actiu.

Aquestes dades seran útils per garantir el bon funcionament de l'aplicació per a totes les entrades vàlides.

Quines són les dades de prova ideals?

Es pot dir que les dades són ideals si s’identifiquen tots els errors de l’aplicació per establir la mida mínima de dades. Proveu de preparar dades que incorporin totes les funcionalitats de l'aplicació, però que no superin la restricció de temps i costos per preparar dades i executar proves.

Com es preparen les dades que garanteixin la màxima cobertura de les proves?

Dissenyeu les vostres dades tenint en compte les categories següents:

1) Sense dades: Executeu els casos de prova amb dades en blanc o predeterminades. Consulteu si es generen missatges d’error adequats.

2) Conjunt de dades vàlid: Creeu-lo per comprovar si l'aplicació funciona segons els requisits i si les dades d'entrada vàlides es guarden correctament a la base de dades o als fitxers.

3) Conjunt de dades no vàlid: Prepareu un conjunt de dades no vàlids per comprovar el comportament de l'aplicació per si hi ha valors negatius, entrades de cadenes alfanumèriques.

4) Format de dades il·legals: Feu un conjunt de dades en format de dades il·legals. El sistema no ha d’acceptar dades en un format no vàlid o il·legal. A més, comproveu que es generin missatges d’error adequats.

5) Conjunt de dades de condició límit: Conjunt de dades que conté dades fora del rang. Identifiqueu els casos de límit de l'aplicació i prepareu un conjunt de dades que cobreixi les condicions de límit inferior i superior.

6) El conjunt de dades per a proves de rendiment, càrrega i esforç: Aquest conjunt de dades hauria de tenir un volum gran.

D’aquesta manera, la creació de conjunts de dades separats per a cada condició de prova assegurarà una cobertura completa de la prova.

Dades per a proves de Black Box

Els verificadors de garantia de qualitat realitzen proves d’integració, proves de sistema i proves d’acceptació, que es coneix com a prova de caixa negra. En aquest mètode de prova, els provadors no tenen cap treball en l’estructura interna, el disseny i el codi de l’aplicació sota la prova.

L’objectiu principal dels verificadors és identificar i localitzar els errors. En fer-ho, apliquem proves funcionals o no funcionals mitjançant diferents tècniques de proves de caixa negra.

Figura 4: Mètodes de disseny de dades de Black Box

En aquest moment, els provadors necessiten les dades de la prova com a entrada per executar i implementar les tècniques de prova de la caixa negra. I els verificadors haurien de preparar les dades que examinaran totes les funcionalitats de l'aplicació sense excedir el cost i el temps indicats.

Podem dissenyar les dades per als nostres casos de prova tenint en compte categories de conjunts de dades com ara cap dada, dades vàlides, dades no vàlides, format de dades il·legals, dades de condició límit, partició d’equivalència, taula de dades de decisió, dades de transició d’estat i dades de casos d’ús. Abans d’entrar en les categories de conjunts de dades, els verificadors inicien la recopilació de dades i l’anàlisi dels recursos existents de l’aplicació sota el verificador (AUT).

Segons els punts anteriors esmentats sobre el manteniment del magatzem de dades sempre actualitzat, heu de documentar els requisits de dades a nivell de cas de prova i marcar-los com a utilitzables o no reutilitzables quan escriviu els casos de prova. Us ajuda a que les dades necessàries per a les proves estiguin ben esborrades i documentades des del principi que podríeu fer referència per al vostre ús posterior.

Exemple de dades de prova per a EMR AUT obert

Per al nostre tutorial actual, tenim l’EMR obert com a aplicació sota prova (AUT).

=> Si us plau, busqueu el enllaç per a l’aplicació Open EMR aquí per a la vostra consulta / pràctica.

La taula següent il·lustra pràcticament una mostra de la recopilació de requisits de dades que pot formar part de la documentació dels casos de prova i s’actualitza quan escriviu els casos de prova per als vostres escenaris de prova.

( NOTA : Feu clic a en qualsevol imatge per a una vista ampliada)

Creació de dades manuals per provar l'aplicació Open EMR

Fem un pas endavant cap a la creació de dades manuals per provar l'aplicació Open EMR per a les categories de conjunts de dades donades.

1) Sense dades: El comprovador valida l'URL de l'aplicació EMR oberta i les funcions 'Cerca o afegeix pacient' sense donar dades.

2) Dades vàlides: El comprovador valida l'URL de l'aplicació EMR oberta i la funció 'Cerca o afegeix pacient' amb dades vàlides.

3) Dades no vàlides: El comprovador valida l'URL de l'aplicació EMR oberta i la funció 'Cerca o afegeix pacient' amb dades no vàlides.

4) Format de dades il·legals: El comprovador valida l'URL de l'aplicació EMR oberta i la funció 'Cerca o afegeix pacient' amb dades no vàlides.

Dades de prova per a 1 a 4 categories de conjunts de dades:

5) Conjunt de dades de condició límit: Es tracta de determinar els valors d’entrada dels límits que es troben dins o fora dels valors donats com a dades.

6) Conjunt de dades de particions d'equivalència: És la tècnica de prova que divideix les dades d’entrada en valors d’entrada vàlids i no vàlids.

Dades de prova per a 5^thi 6^thcategories de conjunts de dades, que són per al nom d’usuari i contrasenya Open EMR:

7) Conjunt de dades de la taula de decisions: És la tècnica per qualificar les vostres dades amb una combinació d’entrades per produir diversos resultats. Aquest mètode de prova de caixa negra us ajuda a reduir els esforços de prova en verificar totes i cadascuna de les combinacions de dades de prova. A més, aquesta tècnica us pot garantir la cobertura completa de la prova.

Vegeu a continuació el conjunt de dades de la taula de decisions per al nom d’usuari i la contrasenya de l’aplicació Open EMR.

El càlcul de les combinacions realitzades a la taula anterior es descriu per obtenir informació detallada a continuació. És possible que el necessiteu quan feu més de quatre combinacions.

Preguntes i respostes de l'entrevista sql per als provadors

• Nombre de combinació = Nombre de condicions 1 Valors * Nombre de condicions 2 Valors
• Nombre de combinacions = 2 ^ Nombre de condicions vertaderes / falses
• Exemple: nombre de combinacions: 2 ^ 2 = 4

8) Conjunt de dades de proves de transició d'estat: És la tècnica de prova que us ajuda a validar la transició d'estat de l'aplicació sota prova (AUT) proporcionant al sistema les condicions d'entrada.

Per exemple, iniciem la sessió a l’aplicació Open EMR proporcionant el nom d’usuari i la contrasenya correctes al primer intent. El sistema ens dóna accés, però si introduïm les dades d’inici de sessió incorrectes, el sistema denega l’accés. La prova de transició d'estat valida quants intents d'inici de sessió podeu fer abans de tancar Open EMR.

La taula següent indica com responen els intents d’inici de sessió correctes o incorrectes

9) Data de la prova de casos d’ús: És el mètode de prova que identifica els nostres casos de prova que capturen les proves d’extrem a extrem d’una característica concreta.

Exemple, obriu l'inici de sessió EMR:

Llegiu també => Tècniques de gestió de dades de dades

Propietats d'una bona prova de dades

Com a provador, heu de provar el mòdul 'Resultats de l'examen' del lloc web d'una universitat. Tingueu en compte que tota l’aplicació s’ha integrat i que es troba a l’estat ‘A punt per provar’. El 'mòdul d'examen' està vinculat amb els mòduls 'Registre', 'Cursos' i 'Finances'.

Suposem que teniu informació adequada sobre l’aplicació i que heu creat una llista completa d’escenaris de prova. Ara heu de dissenyar, documentar i executar aquests casos de prova. A la secció 'Accions / passos' o 'Entrades de prova' dels casos de prova, haureu d'esmentar les dades acceptables com a entrada per a la prova.

Les dades esmentades en casos de prova s’han de seleccionar correctament. La precisió de la columna 'Resultats reals' del document de casos de prova depèn principalment de les dades de la prova. Per tant, el pas per preparar les dades de la prova d’entrada és importantíssim. Per tant, aquí teniu el meu resum sobre 'Proves de DB: estratègies de preparació de dades de prova'.

Propietats de les dades de prova

Les dades de la prova s’han de seleccionar amb precisió i han de contenir les quatre qualitats següents:

1) Realista:

En realitat, significa que les dades han de ser exactes en el context d’escenaris de la vida real. Per exemple, per provar el camp 'Edat', tots els valors han de ser positius i majors de 18 anys. És ben obvi que els candidats a l’admissió a la universitat solen tenir 18 anys (això es pot definir de manera diferent en termes de requisits empresarials).

Si la prova es fa utilitzant les dades de prova realistes, l’aplicació es farà més robusta, ja que la majoria dels errors possibles es poden capturar mitjançant dades realistes. Un altre avantatge de les dades realistes és la seva reutilització que ens estalvia temps i esforç per crear noves dades una vegada i una altra.

Quan parlem de dades realistes, m’agradaria presentar-vos el concepte del conjunt de dades daurat. Un conjunt de dades daurat és el que cobreix gairebé tots els escenaris possibles que es produeixen en el projecte real. Mitjançant l’ús de GDS, podem proporcionar la màxima cobertura de proves. Utilitzo el GDS per fer proves de regressió a la meva organització i això m’ajuda a provar tots els escenaris possibles que es poden produir si el codi entra a la caixa de producció.

Hi ha un munt d’eines generadores de dades de proves disponibles al mercat que analitzen les característiques de les columnes i les definicions d’usuari de la base de dades i, a partir d’aquestes, us generen dades de proves realistes. Pocs dels bons exemples de les eines que generen dades per provar les bases de dades són Generador de dades DTM , Generador de dades SQL i Mockaroo .

2. Pràcticament vàlid:

Això és similar al realista, però no és el mateix. Aquesta propietat està més relacionada amb la lògica comercial d’AUT, per exemple. el valor 60 és realista en el camp de l’edat, però pràcticament no és vàlid per a un candidat a graduació o fins i tot a programes de màster. En aquest cas, un interval vàlid seria de 18 a 25 anys (això es podria definir als requisits).

3. Versàtil per cobrir escenaris:

Preguntes i respostes d’entrevistes d’oracle pl / sql

Pot haver-hi diverses condicions posteriors en un únic escenari, de manera que trieu les dades amb astúcia per cobrir el màxim d'aspectes d'un únic escenari amb el conjunt mínim de dades, per exemple. mentre creeu dades de prova per al mòdul de resultats, no només tingueu en compte el cas dels estudiants habituals que completen el seu programa sense problemes. Presteu atenció als estudiants que repeteixen el mateix curs i pertanyen a semestres diferents o fins i tot a programes diferents. El conjunt de dades pot tenir aquest aspecte:

Pot haver-hi diverses altres sub-condicions interessants i complicades. Per exemple. la limitació d’anys per completar un programa de grau, superant un curs previ per inscriure un curs, màxim núm. de cursos que un estudiant pot matricular-se en un sol semestre, etc. etc. Assegureu-vos de cobrir tots aquests escenaris amb saviesa amb el conjunt finit de dades.

4. Dades excepcionals (si escau / es requereix):

Pot haver-hi certs escenaris excepcionals que es produeixen amb menys freqüència però que exigeixen una gran atenció quan es produeixen, per exemple problemes relacionats amb estudiants discapacitats.

A la imatge següent es mostra una altra bona explicació i exemple del conjunt de dades excepcionals:

Emportar:

Les dades de prova es coneixen com a bones dades de prova si són realistes, vàlides i versàtils. És un avantatge addicional si les dades també proporcionen cobertura per a escenaris excepcionals.

Provar tècniques de preparació de dades

Hem debatut breument sobre les propietats importants de les dades de proves i també hem explicat com és important la selecció de dades de prova mentre realitzem les proves de base de dades. Ara anem a discutir el ' tècniques per preparar dades de proves ' .

Només hi ha dues maneres de preparar les dades de la prova:

Mètode 1) Inseriu dades noves

Obteniu un DB net i inseriu totes les dades tal com s’especifica als casos de prova. Un cop hàgiu introduït totes les dades necessàries i desitjades, comenceu a executar els casos de prova i empleneu les columnes 'Passar / Fallar' comparant 'Sortida real' amb 'Sortida esperada'. Sembla simple, oi? Però espereu, no és tan senzill.

Poques preocupacions essencials i crítiques són les següents:

• És possible que no hi hagi una instància buida de la base de dades
• Les dades de prova inserides poden ser insuficients per provar alguns casos, com ara el rendiment i les proves de càrrega.
• Inserir les dades de prova necessàries en una base de dades en blanc no és una tasca fàcil a causa de les dependències de la taula de base de dades. A causa d'aquesta inevitable restricció, la inserció de dades pot convertir-se en una tasca difícil per al comprovador.
• La inserció de dades de prova limitades (segons les necessitats del cas de prova) pot amagar alguns problemes que només es podrien trobar amb el gran conjunt de dades.
• Per a la inserció de dades, poden ser necessàries consultes complexes i / o procediments, i per a això seria necessària l'ajuda o ajuda dels desenvolupadors de la base de dades.

Esmentats cinc temes són els inconvenients més crítics i els més evidents d’aquesta tècnica per a la preparació de dades de proves. Però també hi ha alguns avantatges:

• L’execució dels TC es fa més eficient ja que la base de dades només té les dades necessàries.
• L'aïllament d'errors no requereix temps, ja que a la base de dades només hi ha les dades especificades en casos de prova.
• Menys temps necessari per fer proves i comparar resultats.
• Procés de prova lliure de desordre

Mètode 2) Trieu un subconjunt de dades de mostra entre les dades de base de dades reals

Aquesta és una tècnica més factible i més pràctica per a la preparació de dades de proves. No obstant això, requereix coneixements tècnics sòlids i requereix coneixements detallats de DB Schema i SQL. En aquest mètode, heu de copiar i utilitzar les dades de producció substituint alguns valors de camp per valors ficticis. Aquest és el millor subconjunt de dades per a les proves, ja que representa les dades de producció. Però pot ser que això no sigui factible tot el temps a causa de problemes de seguretat i privadesa de les dades.

Emportar:

A la secció anterior, hem comentat anteriorment les tècniques de preparació de dades de proves. En resum, hi ha dues tècniques: crear dades noves o seleccionar un subconjunt de dades ja existents. Tots dos s’han de fer de manera que les dades seleccionades proporcionin cobertura a diversos escenaris de prova, principalment vàlids i no vàlids, proves de rendiment i proves nul·les.

A l'última secció, també fem un recorregut ràpid pels enfocaments de generació de dades. Aquests enfocaments són útils quan hem de generar noves dades.

Enfocaments de generació de dades de prova:

• Generació manual de dades de proves: En aquest enfocament, els verificadors introdueixen manualment les dades de la prova segons els requisits del cas de prova. És un moment que pren el procés i també propens a errors.
• Generació automàtica de dades de proves: Això es fa amb l'ajut d'eines de generació de dades. El principal avantatge d’aquest enfocament és la seva rapidesa i precisió. No obstant això, té un cost superior al de la generació manual de dades de proves.
• Injecció de dades de fons : Això es fa mitjançant consultes SQL. Aquest enfocament també pot actualitzar les dades existents a la base de dades. És ràpid i eficaç, però s’ha d’implementar amb molta cura perquè la base de dades existent no es corrompi.
• Ús d’eines de tercers : Hi ha eines disponibles al mercat que primer entenen els vostres escenaris de prova i, a continuació, generen o injecten dades en conseqüència per proporcionar una àmplia cobertura de les proves. Aquestes eines són precises ja que es personalitzen segons les necessitats del negoci. Però són força costosos.

Emportar:

Hi ha 4 enfocaments per provar la generació de dades:

1. manual,
2. automatització,
3. injecció de dades de fons,
4. i eines de tercers.

Cada enfocament té els seus pros i contres. Heu de seleccionar l'enfocament que satisfaci les vostres necessitats empresarials i de proves.

Conclusió

La creació de dades completes de proves de programari de conformitat amb els estàndards de la indústria, la legislació i els documents bàsics del projecte realitzat és una de les responsabilitats bàsiques dels verificadors. Com més eficaçment gestionem les dades de la prova, més podem desplegar productes raonablement lliures d’errors per a usuaris del món real.

La gestió de dades de prova (TDM) és el procés que es basa en l’anàlisi de reptes i la introducció a més d’aplicar les millors eines i mètodes per abordar bé els problemes identificats sense comprometre la fiabilitat i la cobertura completa de la sortida final (producte).

Sempre hem de plantejar-nos preguntes per buscar mètodes innovadors i més rendibles per analitzar i seleccionar els mètodes de prova, inclòs l’ús d’eines per generar les dades. Està àmpliament demostrat que les dades ben dissenyades ens permeten identificar defectes de l’aplicació sotmesa a la prova en totes les fases d’un SDLC multifàsic.

Hem de ser creatius i participar amb tots els membres dins i fora del nostre equip àgil. Compartiu els vostres comentaris, experiència, preguntes i comentaris, de manera que puguem continuar les nostres discussions tècniques per maximitzar el nostre impacte positiu sobre la gestió automàtica de dades.

Preparar les dades de prova adequades és una part bàsica de la 'configuració de l'entorn de prova del projecte'. No ens podem perdre simplement el cas de prova dient que les dades completes no estaven disponibles per provar-les. El comprovador ha de crear les seves pròpies dades de prova addicionals a les dades de producció estàndard existents. El vostre conjunt de dades hauria de ser ideal en termes de cost i temps.

Sigues creatiu, utilitza les teves habilitats i criteris per crear diferents conjunts de dades en lloc de confiar en dades de producció estàndard.

Part II - La segona part d 'aquest tutorial es troba a ' Prova de generació de dades amb l'eina en línia de GEDIS Studio '.

Us heu enfrontat al problema de les dades de proves incompletes per provar-les? Com ho vas gestionar? Comparteix els teus consells, experiència, comentaris i preguntes per enriquir encara més aquest tema de discussió.

Lectura recomanada

• Tutorial de proves de magatzem de dades de proves ETL (una guia completa)
• Què és la prova de mutació: tutorial amb exemples
• Com realitzar proves basades en dades mitjançant l'eina TestComplete
• Proves basades en dades o parametritzades amb Spock Framework
• Els 4 passos per provar Business Intelligence (BI): com provar dades de negoci
• Tutorial de proves de volum: exemples i eines de prova de volum
• Una manera excel·lent de provar dades mitjançant tecnologies XML (Llibre blanc)
• Top 10 eines de validació i prova de dades estructurades per a SEO