Proves unitàries en un DBMS: com ho fem a Sportmaster, segona part

primera part - aquí.

Imagineu la situació. Esteu davant la tasca de desenvolupar noves funcionalitats. Teniu novetats respecte als vostres predecessors. Si suposem que no tens obligacions morals, què faries?

Molt sovint, tots els antics desenvolupaments s'obliden i tot comença de nou. A ningú li agrada aprofundir en el codi d'una altra persona, però si teniu temps, per què no comenceu a crear el vostre propi sistema? Aquest és un enfocament típic, i en gran part és correcte. Però en el nostre projecte ho vam fer malament. Vam basar el futur sistema de proves automàtiques en els desenvolupaments de les proves unitàries sobre utPLSQL dels nostres predecessors, i després vam començar a treballar en diverses direccions paral·leles.

1. Restauració de proves unitàries antigues. Recuperació significa adaptar les proves a l'estat existent del sistema de fidelització i adaptar les proves als estàndards utPLSQL.
2. Resoldre un problema amb una comprensió de què exactament, quins mètodes i processos es cobreixen amb autotests. Heu de mantenir aquesta informació al cap o treure conclusions basades directament en el codi de prova automàtica. Per això, vam decidir crear un catàleg. Vam assignar un codi mnemotècnic únic a cada prova automàtica, vam crear una descripció i vam registrar la configuració (per exemple, en quines condicions s'hauria de llançar o què hauria de passar si falla l'inici de la prova). Bàsicament, hem emplenat les metadades sobre les proves automàtiques i hem col·locat aquestes metadades en taules d'esquemes utPLSQL estàndard.
3. Definir l'estratègia d'expansió, és a dir. selecció de la funcionalitat que està subjecta a verificació mitjançant proves automatitzades. Vam decidir parar atenció a tres coses: millores del nou sistema, incidències de producció i processos clau del sistema. Així, estem desenvolupant paral·lelament al llançament, garantint la seva major qualitat, ampliant simultàniament l'abast de la regressió i garantint la fiabilitat del sistema en llocs crítics. El primer coll d'ampolla d'aquest tipus va ser el procés de distribució de descomptes i bonificacions en un xec.
4. Naturalment, vam començar a desenvolupar nous autotests. Una de les primeres tasques de llançament va ser avaluar el rendiment de mostres predefinides del sistema de fidelització. El nostre projecte té un bloc de consultes SQL rígidament fixades que seleccionen clients en funció de les condicions. Per exemple, obteniu una llista de tots els clients la darrera compra dels quals va ser en una ciutat concreta, o una llista de clients l'import mitjà de compra dels quals supera un valor determinat. Després d'haver escrit proves automàtiques, vam comprovar mostres predefinides, vam registrar paràmetres de rendiment de referència i, a més, vam fer proves de càrrega.
5. Treballar amb autotests hauria de ser convenient. Les dues accions més habituals són executar autotests i crear dades de prova. Així van aparèixer dos mòduls auxiliars al nostre sistema: un mòdul de llançament i un mòdul de generació de dades.

   El llançador es representa com un procediment universal amb un paràmetre d'entrada de text. Com a paràmetre, podeu passar el codi mnemotècnic de prova automàtica, el nom del paquet, el nom de la prova, la configuració de la prova automàtica o una paraula clau reservada. El procediment selecciona i executa totes les proves automàtiques que compleixen les condicions.

   El mòdul de generació de dades es presenta en forma de paquet en el qual per a cada objecte del sistema a prova (una taula a la base de dades) s'ha creat un procediment especial que hi insereix dades. En aquest procediment, els valors predeterminats s'omplen tant com sigui possible, cosa que garanteix la creació d'objectes literalment amb un clic d'un dit. I per facilitar-ne l'ús, es van crear plantilles per a les dades generades. Per exemple, creeu un client d'una determinada edat amb un telèfon de prova i una compra completada.

6. Les proves automàtiques haurien d'iniciar-se i executar-se en un temps acceptable per al vostre sistema. Per això, es va organitzar un llançament nocturn diari, a partir dels resultats de la qual es genera un informe de resultats que s'envia a tot l'equip de desenvolupament a través del correu corporatiu. Després de restaurar autotests antics i crear-ne de nous, el temps total de funcionament va ser de 30 minuts. Aquesta actuació agradava a tothom, ja que el llançament es va fer fora de l'horari laboral.

   Però vam haver de treballar per optimitzar la velocitat de treball. El sistema de fidelització en producció s'actualitza a la nit. Com a part d'un dels llançaments, vam haver de fer canvis urgents a la nit. Esperar durant mitja hora els resultats de les proves automàtiques a les tres de la matinada no va fer feliç a la persona responsable de l'alliberament (salutacions ardents a Alexey Vasyukov!), i l'endemà al matí es van dir moltes paraules amables cap al nostre sistema. Però com a resultat, es va establir un estàndard de 5 minuts per al treball.

   Per accelerar el rendiment, vam utilitzar dos mètodes: els autotests van començar a executar-se en tres fils paral·lels, afortunadament això és molt convenient a causa de l'arquitectura del nostre sistema de fidelització. I vam abandonar l'enfocament en què l'autotest no crea dades de prova per si mateix, sinó que intenta trobar alguna cosa adequada al sistema. Després de fer els canvis, el temps total de funcionament es va reduir a 3-4 minuts.

7. Un projecte amb proves automàtiques s'hauria de poder desplegar en diferents estands. Al principi del nostre viatge, hi va haver intents d'escriure els nostres propis fitxers per lots, però va quedar clar que una instal·lació automatitzada autoescrita era un horror total i vam girar cap a solucions industrials. A causa del fet que el projecte conté molt de codi directe (en primer lloc, emmagatzemem el codi d'autotest) i molt poques dades (les dades principals són metadades sobre autotests), la implementació al projecte Liquibase va resultar molt senzilla.

   És una biblioteca de codi obert i independent de la base de dades per fer el seguiment, la gestió i l'aplicació dels canvis d'esquema de bases de dades. Gestionat mitjançant la línia d'ordres o marcs com Apache Maven. El principi de funcionament de Liquibase és bastant simple. Tenim un projecte organitzat d'una manera determinada, que consisteix en canvis o scripts que cal desplegar al servidor de destinació, i fitxers de control que determinen en quina seqüència i amb quins paràmetres s'han d'instal·lar aquests canvis.

   A nivell de DBMS, es crea una taula especial en la qual Liquibase emmagatzema el registre de transferència. Cada canvi té un hash calculat, que es compara cada vegada entre el projecte i l'estat de la base de dades. Gràcies a Liquibase, podem implementar fàcilment canvis al nostre sistema a qualsevol circuit. Els autotests es posen en marxa en circuits de prova i llançament, així com en contenidors (circuits personals dels desenvolupadors).

Així doncs, parlem dels resultats de l'ús del nostre sistema de proves unitàries.

1. Per descomptat, en primer lloc, estem convençuts que hem començat a desenvolupar un millor programari. Les proves automàtiques es llancen diàriament i es troben desenes d'errors a cada llançament. A més, alguns d'aquests errors només estan indirectament relacionats amb la funcionalitat que realment volíem canviar. Hi ha seriosos dubtes que aquests errors s'han trobat mitjançant proves manuals.
2. L'equip ara té confiança que una funcionalitat específica funciona correctament... En primer lloc, això es refereix als nostres processos crítics. Per exemple, durant els últims sis mesos no hem tingut cap problema amb la distribució de descomptes i bonificacions en rebuts, malgrat els canvis de llançament, tot i que en períodes anteriors es van produir errors amb certa freqüència.
3. Hem aconseguit reduir el nombre d'iteracions de prova. A causa del fet que les proves automàtiques s'escriuen per a noves funcionalitats, els analistes i els verificadors a temps parcial reben codi de major qualitat, perquè ja s'ha comprovat.
4. Alguns dels desenvolupaments en proves automatitzades són utilitzats pels desenvolupadors. Per exemple, les dades de prova dels contenidors es creen mitjançant el mòdul de generació d'objectes.
5. És important que hem desenvolupat una "acceptació" del sistema de proves automatitzat per part dels desenvolupadors. Hi ha una comprensió que això és important i útil. Però des de la meva pròpia experiència puc dir que això no és així. Cal escriure autotests, recolzar-los i desenvolupar-los, analitzar els resultats, i sovint aquests costos de temps simplement no valen la pena. És molt més fàcil anar a la producció i tractar-hi els problemes. Aquí, els desenvolupadors s'alineen i ens demanen que cobrim la seva funcionalitat amb autotests.

Què és el següent

Parlem dels plans de desenvolupament del projecte de proves automatitzades.

Per descomptat, mentre el sistema de lleialtat de Sportmaster sigui viu i continuï desenvolupant-se, també és possible desenvolupar autotests gairebé sense fi. Per tant, la principal direcció de desenvolupament és ampliar l'àrea de cobertura.

A mesura que augmenta el nombre d'autotests, el seu temps total de funcionament augmentarà de manera constant i haurem de tornar a la qüestió del rendiment. El més probable és que la solució sigui augmentar el nombre de fils paral·lels.

Però aquestes són maneres òbvies de desenvolupament. Si parlem d'alguna cosa més no trivial, destaquem el següent:

1. Actualment, la gestió d'autotest es realitza a nivell de SGBD, és a dir. Es requereix coneixements de PL/SQL per treballar amb èxit. Si cal, gestió del sistema (per exemple, llançament o creació de metadades), podeu crear algun tipus de tauler d'administració amb Jenkins o alguna cosa semblant.
2. A tothom li agraden els indicadors quantitatius i qualitatius. Per a les proves automatitzades, aquest indicador universal és Cobertura de codi o mètrica de cobertura de codi. Mitjançant aquest indicador, podem determinar quin percentatge del codi del nostre sistema en prova està cobert per autotests. A partir de la versió 12.2, Oracle ofereix la possibilitat de calcular aquesta mètrica i ofereix l'ús del paquet estàndard DBMS_PLSQL_CODE_COVERAGE.

   El nostre sistema de prova automàtica té poc més d'un any i potser ara és el moment d'avaluar la nostra cobertura. En el meu últim projecte (no un projecte Sportmaster) això és el que va passar. Un any després de treballar en autotests, la direcció es va encarregar d'avaluar quin percentatge del codi cobrim. Amb una cobertura superior a l'1%, la direcció estaria contenta. Nosaltres, els desenvolupadors, esperàvem un resultat d'aproximadament el 10%. Vam instal·lar la cobertura del codi, la vam mesurar i vam aconseguir un 20%. Per celebrar-ho hem anat a buscar el premi, però com hem anat a aconseguir-lo i on hem anat després és una història completament diferent.

3. Les proves automàtiques poden comprovar els serveis web exposats. Oracle ens permet fer-ho força bé i ja no ens trobarem amb una sèrie de problemes.
4. I, per descomptat, el nostre sistema de proves automatitzades es pot aplicar a un altre projecte. La solució que hem rebut és universal i només requereix l'ús d'Oracle. He sentit que altres projectes de Sportmaster estan interessats en les proves automàtiques i potser anirem a ells.

Troballes

Resumim. En el projecte del sistema de fidelització a Sportmaster, vam aconseguir implantar un sistema de proves automatitzat. Es basa en la solució utPLSQL de Stephen Feuerstein. Al voltant d'utPLSQL hi ha codi d'autotest i mòduls auxiliars escrits per si mateix: mòdul de llançament, mòdul de generació de dades i altres. Els autotests es llancen diàriament i, el més important, funcionen i són útils. Estem segurs que hem començat a llançar programari de major qualitat. Al mateix temps, la solució resultant és universal i es pot aplicar lliurement a qualsevol projecte on sigui necessari organitzar proves automatitzades al SGBD Oracle.

PD Aquest article no és gaire concret: hi ha molt text i pràcticament no hi ha exemples tècnics. Si el tema és generalment interessant, aleshores estem preparats per continuar-lo i tornar-hi amb una continuació, on us explicarem què ha canviat durant els últims sis mesos i us proporcionarem exemples de codi.

Escriu comentaris si hi ha punts que s'haurien de posar èmfasi en el futur o preguntes que requereixen divulgació.

Només els usuaris registrats poden participar en l'enquesta. Inicia sessiósi us plau.

Escrivim més sobre això?

• Si, es clar

• No gràcies

Han votat 12 usuaris. 4 usuaris es van abstenir.

Font: www.habr.com