how effectively prepare test bed
Desafiaments i pràctiques recomanades per a la configuració del banc de proves / entorn de proves:
En diverses ocasions, els provadors troben els seus defectes rebutjats per qüestions mediambientals o es repliquen constantment per defectes similars. Tot i que obrir el màxim nombre de defectes ha de ser sens dubte un dels punts de referència personals per a tots els provadors, la majoria dels provadors també han de destacar en tenir el major nombre de defectes vàlids.
Com s’aconsegueix això?
A part dels altres aspectes com ara planificar diversos escenaris de prova i entendre bé la línia de comanda, a cal invertir una bona quantitat de temps a configurar el banc de proves o l'entorn de proves . En segon lloc, tot i tenir una quantitat estimada per a la planificació de casos de proves, també ho han de fer els verificadors centrar les seves energies en creant dades de prova efectives .
Personalment, en formar part del procés d’auditoria, he observat que el major nombre de defectes vàlids es troben quan s’inverteix una bona quantitat d’esforços en la creació correcta del banc de proves o de l’entorn de prova i quan el comprovador té comprensió del tipus d’entorn necessari.
A més, el tipus de dades de prova subministrades a l’entorn de prova pot exposar alguns defectes molt greus en el codi / funció que s’està provant i que poden afectar greument la qualitat del producte.
En aquest article es parla de què implica exactament el banc de proves: es tracta d’un procés en dos passos de configuració de l’entorn de prova i configuració de dades de prova:
Part 1) A la part anterior de l 'article es parlarà de procés general de configuració de l'entorn de prova , els problemes d’instal·lació més freqüents als quals s’enfronten les proves i els consells que cal tenir en compte en crear un banc de proves en lloc d’aquests desafiaments.
Part 2) Després d 'haver dit tantes coses respecte al banc de proves en aquest article, valia la pena llançar una mica de llum sobre el Manteniment de l'entorn de prova aspectes també. L’última part de l’article tracta de la segona part de la configuració del banc de proves, que inclou les dades de la prova, l’enfocament per configurar-la i alguns efectius. Prova tècniques de gestió de dades .
Amb un 'big bang' constant en el desenvolupament i les proves de programari, es fa cada vegada més gran l'adopció de diverses metodologies per fer que el procés global d'assegurament de la qualitat sigui transparent, eficient i adequat.
Es realitzen diverses auditories de qualitat entre les organitzacions per assegurar que el rendiment de l'equip de proves es pugui avaluar adequadament i que tingui resultats mesurables amb les mètriques identificades en la inicialització del cicle de proves. Aquests resultats permeten identificar on es troba un equip concret en termes d’assegurar una qualitat òptima per al programari que proven.
Aquests informes també ajuden l'equip a entendre les oportunitats de millora basades en les observacions realitzades durant l'auditoria.
No cal esmentar que una mètrica molt òbvia per a qualsevol equip de prova seria respecte al nombre total de defectes oberts en comparació amb el nombre de defectes vàlids . Per tant, una de les preguntes que apareix òbviament és: Quina és la base d’intentar descobrir algun defecte? Dit d'una altra manera, quina és la base sobre la qual es pot trobar un defecte?
La resposta és unànime: configuració del banc de proves i / o entorn de prova. Hi ha paràmetres de qualitat establerts dins dels equips reduir els defectes rebutjats com a error de configuració de prova / error d’usuari, configuracions no vàlides o, en alguns casos, els defectes que es produeixen quan s’escapa d’un equip concret a causa de configuracions no disponibles, configuracions no provades.
amb què obrir fitxers XML
Comencem donant una ullada més detallada a la definició del que és un banc de proves o un entorn de prova.
Què aprendreu:
Què és un banc de proves i un entorn de prova?
En un sentit molt genèric, un banc de proves es podria definir com un tipus d’entorn de desenvolupament pel qual els implementadors de codi o mòduls tenen la llibertat de provar els seus mòduls sense cap molèstia per part de l’equip de proves, en un confinament absolut.
Tot i això, un banc de proves no només és específic per a un equip de desenvolupament. Des de la perspectiva d'un equip de proves o d'un provador, atès que el banc de proves no és res més que una plataforma identificada per a la prova de programari / producte, també es denomina indistintament entorn de prova.
Qualsevol banc de proves o entorn de prova hauria de configurar-se d'acord amb l'objectiu de prova identificat per a l'aplicació / producte / programari que es prova. En determinades situacions, un banc de proves seria la classificació de l'entorn de prova i de les dades de prova amb què opera.
Components d'un entorn de prova
Qualsevol prova tindria els seus requisits específics d’entorn de prova, però en un sentit molt ampli, qualsevol banc de prova / entorn de prova inclourà el maquinari, el programari i les peces de xarxa per donar suport a la configuració necessària com a mínim per conduir i realitzar la prova particular. .
És ben sabut que els problemes ambientals consumeixen una quantitat raonable del temps d’un comprovador, que al seu torn afecten la productivitat i els horaris de proves. Tot i que el tipus de desafiament varia per a tots i cadascun dels equips de prova, alguns poden ser comuns.
Alguns dels principals reptes que s’enfronten habitualment són:
# 1) Entorn remot
Els recursos o entorns de prova es situen majoritàriament geogràficament en llocs remots per als equips. Aquest és un dels reptes més freqüents per als equips de prova, ja que en cas de problemes relacionats amb el maquinari, el firmware, el programari, la xarxa, etc.
Els equips que consumeixin els recursos haurien de confiar en gran mesura en els equips de suport de la ubicació on es trobin els actius.
En les mateixes línies, si algun recurs necessita una actualització de firmware o una actualització de compilació, de nou l’equip de prova pot necessitar el suport dels equips de suport propietaris de l’entorn obrint tiquets de suport. Això també pot agafar un temps considerable de proves i endarrerir els horaris, especialment en casos de diferències de zona horària.
# 2) Ús combinat entre equips
La majoria de les vegades, els equips de desenvolupament i de prova utilitzen els mateixos recursos ambientals. Tot i que la norma general defineix que els entorns de desenvolupament, prova i producció han de ser separats, en realitat aquest escenari ideal molt rarament s’aconsegueix. Es fa extremadament desagradable per a les organitzacions adquirir recursos separats per a cada equip.
Per tant, la majoria d’organitzacions obliguen l’ús comú de l’entorn entre el desenvolupament i la prova. A més, si els recursos de desenvolupament i proves es disputen l’ús dels mateixos recursos al mateix temps, es produeix un caos i desacords entre els membres.
# 3) Planificació ineficaç per a l'ús de recursos per a la integració
En alguns casos per a escenaris que necessiten un fitxer proves de punta a punta per la qual cosa hi ha una integració de dos o més components per funcionar junts, de nou pot haver-hi el requisit de tenir un ús comú dels recursos entre els equips de prova. La planificació ineficaç pel que fa a l’ús contribueix de manera important al fet que l’entorn es torna inestable, a més del conflicte entre equips.
L'efecte més evident d'això és que un problema que es nota per a una determinada una o dues vegades pot produir un comportament completament diferent en les següents proves per al mateix escenari. Si ja hi ha un defecte obert, hi ha moltes possibilitats que el desenvolupament no l'accepti com a candidat vàlid per a una solució.
# 4) Configuració de proves complexes
La configuració del banc de proves o de l'entorn de prova de vegades és massa complexa. Això suposarà diversos reptes, ja que l'equip de prova necessitarà les habilitats necessàries per entendre les configuracions necessàries. De vegades hi ha una manca de base de coneixement disponible perquè el provador pugui arribar a la configuració necessària.
En aquests casos, els verificadors poden induir ells mateixos un error al banc de proves configurant-lo incorrectament. Això afectaria molt el cas de prova i els resultats que produeix.
# 5) Temps de configuració elaborat
En altres ocasions, per a cada cas de prova, la configuració de la prova pot ser massa elaborada en cada cas de prova identificat. Això es podria deure a una àmplia varietat de tecnologies coexistents que necessiten ser acoblades o components múltiples per treballar junts en casos de proves d’integració.
En aquests casos, cadascun dels components ha de funcionar perfectament per garantir resultats consistents, ja que un component pot formar una entrada al següent.
Bones pràctiques per configurar un entorn de prova
Hem donat una ullada a l’esquema general dels desafiaments als quals s’enfronta un provador abans o mentre comença l’execució de la prova. La majoria de nosaltres ens hem enfrontat a un o més d’aquests problemes en algun moment de les fites del nostre projecte. Aquests reptes han existit i possiblement continuaran existint en diversos graus perquè no existeix una situació idealista.
Tenint en compte que els reptes de configuració formen part integrant de la feina del verificador i són inevitables, a continuació, es presenten alguns suggeriments sobre com preparar la configuració de manera efectiva per a les proves. Això podria ajudar a minimitzar els defectes que poden originar-se per problemes de configuració.
preguntes d’entrevistes sobre sabó i descans
Consell 1) Enteneu el Comproveu els requisits a fons i educar-se
Comenceu sempre pels conceptes bàsics i pels més evidents. Quan l’equip de desenvolupament desplega un document d’especificacions o un document de casos d’ús, el pas invariable per a l’equip de prova consisteix a entendre els requisits de la línia de comanda i, a continuació, preparar un document de casos de prova que detalli els casos de prova.
Mentre es duu a terme la planificació de les proves, sí el millor pràctica per incloure també la informació detallada de l'entorn de prova al document del cas de prova. No s’endevina que el comprovador passarà una estona analitzant quin entorn de prova pot ser necessari i, en conseqüència, les configuracions necessàries.
Això es pot aconseguir parlant amb l'equip de desenvolupament / arquitectes per tal de construir una bona base de coneixement. Això no només estalviaria una mica de temps en el cicle d’execució, sinó que també ajudarà un provador a assignar el seu temps d’execució de manera eficaç entre proves senzilles i complexes.
Personalment, un bon resultat d’això és que molts de nosaltres vam descobrir problemes d’instal·lació (que impedirien intrínsecament l’execució coherent de les proves) al començament del cicle, cosa que ens va donar el temps de canalitzar i adquirir l’ajuda necessària per solucionar aquests problemes. no ampliar el cicle de prova més enllà de períodes inacceptables.
Un altre impacte positiu que això tindria és que això milloraria molt els coneixements de l’equip de proves i evitaria defectes innecessaris. Tot i que aquesta pràctica resumeix gairebé totes les pràctiques necessàries per fer front als reptes de configuració de proves esmentats anteriorment, encara val la pena fer una menció sobre els altres consells.
Consell núm. 2) Comprovació de la connectivitat
Un altre punt de control més important és assegurar-se que es pugui accedir als recursos o actius que es pretén utilitzar per fer proves. En cas que el sistema s’hagi d’executar integrat amb altres màquines, comproveu-ne la connectivitat utilitzant ping o telnet.
A més, si els sistemes han d’interactuar entre ells i estan darrere dels tallafocs, assegureu-vos que es puguin autenticar mitjançant aquests tallafocs mitjançant les opcions bàsiques de seguretat (BSO) i comproveu també si hi ha cap servidor intermediari. En cas que noteu que algunes màquines no són accessibles o necessiten autenticació BSO, es poden presentar sol·licituds de servei adequades per satisfer el requisit a l'equip d'assistència.
Això és particularment útil quan l’entorn es troba en llocs remots i també evitarà escalades respecte a les màquines i els sistemes. En cas que l'equip de prova requereixi l'accés a qualsevol recurs o repositori, això ajudaria a determinar-ne de forma activa.
Consell núm. 3)Comprovació de la xarxa i / o emmagatzematge
Això és gairebé una extensió a la punta anterior i necessitaria una altra comprovació més amb major profunditat tècnica. Assegureu-vos que les proves que necessiteu tinguin l’amplada de banda necessària i si les proves necessiten connexió a Internet. A més, assegureu-vos de trobar una manera de verificar que la topologia de xarxa entre sistemes i recursos sigui correcta.
En segon lloc, si el vostre objectiu de prova implica la necessitat d’emmagatzematge, assegureu-vos que hi hagi emmagatzematge i connectivitat de xarxa. Majoritàriament, és responsabilitat de l’administrador tenir-ho al seu lloc, però, també és un gran valor afegit tenir uns coneixements funcionals i funcionals del mateix.
Consell núm. 4) Comproveu si hi ha maquinari i programari, llicències necessàries
Moltes vegades passa que els provadors comencen a executar-se als sistemes sense comprovar el maquinari i el programari necessaris que poden ser necessaris. Com a resultat d'això moltes vegades, un provador s'adona gairebé durant el cicle de proves que certes funcionalitats només estan disponibles en un nivell superior de maquinari o programari / firmware.
En aquest moment, el provador marcarà un bloquejador en el seu esforç de prova, que es consumeix un temps de prova considerable. Per tant, és una pràctica inestimable tenir un punt de control per prendre nota del maquinari i el programari que es necessiten prèviament.
Moltes vegades pot haver-hi temps d'inactivitat relacionats amb l'actualització del maquinari / programari, que es redueixen Consell 1 on un provador ha de participar en una planificació proactiva pel que fa al maquinari. Alguns programes poden requerir llicències que poden requerir aprovacions i accions de l'equip legal. En tractar-se d’una acció impulsada per processos, pot trigar de nou a complir-se uns quants dies, que cal planificar.
Consell núm. 5)Navegadors i versions
Les proves que feu s'han de reflectir què farà un usuari final . Podria provar en un navegador concret les darreres versions de tots els navegadors. Per tant, és obligatori identificar els diferents tipus de navegadors que s’utilitzaran per provar i instal·lar-los a la vostra configuració de prova local.
En segon lloc, també identifiqueu quines versions de navegadors cal utilitzar per provar-les. Una bona pràctica seria començar amb un navegador de la versió inferior, garantint així la compatibilitat amb versions posteriors i després actualitzar a la versió més recent.
Consell núm. 6)Planificar l'ús de l'entorn de prova.
Tenint en compte que l’equip de proves mai no tindrà la possibilitat de tenir els seus propis recursos, sistemes i recursos de prova, és una de les fites principals de la planificació de la prova que es faci un ús efectiu dels recursos de prova.
preguntes i respostes d’entrevistes de codi Java
Això es requereix particularment quan més d’un equip ha d’accedir al mateix conjunt de recursos, ja sigui per un escenari extrem a extrem que consta de dos o més components que treballen junts o per una situació en què la configuració de la prova és massa elaborada o complexa per reproduir-se. molt fàcilment i hi pot haver diversos membres d’un mateix equip que tinguin els seus propis objectius de prova amb la mateixa configuració.
Una bona pràctica seria elaborar un enfocament de temps compartit mitjançant el qual un determinat equip o persona l’utilitzi per a la meitat anterior i la resta de persones per a la segona meitat. Hi pot haver algun moment intermedi que sigui comú en què cadascun d’ells pugui realitzar proves independents que no dificultin l’altre.
Fer això no només reduirà el caos i els conflictes dins dels membres, sinó que també garantirà l’estabilitat conductual de l’entorn durant més temps.
Consell núm. 7)Eines d'automatització i les seves configuracions
Com sabem, cada línia de comanda de les proves tindrà algunes proves repetitives que formaran part del cicle de regressió que s’hauran d’automatitzar. L’equip de proves ha d’identificar quin tipus d’automatització voldria fer i les eines necessàries per fer-ho.
Tot i que aquest necessari no ha de formar part de la preparació de l’entorn, seguiria enumerant-ho com una pràctica recomanada per tenir les eines d’automatització identificades i configurades en conseqüència. Això dependrà completament de la discreció del verificador quan vulgui realitzar aquesta activitat, ja que no és un factor obligatori per garantir la preparació de la prova.
Conclusió
Aquests consells i trucs poden ser un bon criteri i una petjada per garantir la preparació de l'entorn de prova per a les proves. Sens dubte, cada equip s'enfronta al seu propi conjunt de reptes i els consells anteriors es poden adaptar i personalitzar per adaptar-se a les seves pròpies necessitats.
De fet, la font per esborrar tot aquest esquelet de consells prové d’una de les meves tasques en què em vaig enfrontar a problemes de configuració molt complexos i em vaig trigar gairebé un any a començar a provar.
Tot i que les limitacions de l’entorn de la prova estaven fora del meu control, sentia que molts d’aquests problemes s’haurien pogut informar abans si hagués aplicat aquests consells. Des de llavors, l’he aplicat per a totes les tasques que em venen i aquest esquelet m’ha ajudat molt a trobar proactivament problemes de configuració i canalitzar els meus esforços per resoldre’ls.
Sobre l'autor: Aquest article està escrit per Sneha Nadig. Treballa com a responsable de proves amb més de 7 anys d’experiència en projectes de proves manuals i d’automatització.
A la part 2 d’aquest article, veurem el procés de configuració i manteniment de l’entorn de prova i els consells de preparació i gestió de dades de proves. Mentrestant, no dubteu a publicar les vostres consultes de preparació del llit de proves als comentaris.
Lectura recomanada
- Com realitzar proves de post-llançament eficaçment i minimitzar l’impacte de la versió per als clients en directe
- Com decidiu quins defectes són acceptables perquè el programari es publiqui?
- Com preparar i lliurar una presentació de proves de control de qualitat excepcional a l’equip
- Procés de gestió de defectes: com gestionar eficaçment un defecte
- 9 millors idees perquè els provadors utilitzin el seu temps de banca de manera efectiva
- Lideratge en proves: responsabilitats del líder de proves i com gestionar l’equip de prova de manera eficaç
- Com planificar i gestionar eficaçment els projectes de proves (consells)
- Procés de triatge de defectes i maneres de gestionar la reunió de triatge de defectes