Ola Habr!
Chámome Maxim Ponomarenko e son programador en Sportmaster. Teño 10 anos de experiencia no campo das TIC. Comezou a súa carreira en probas manuais, despois pasou ao desenvolvemento de bases de datos. Durante os últimos 4 anos, acumulando os coñecementos adquiridos en probas e desenvolvemento, fun automatizando as probas a nivel de DBMS.
Levo algo máis dun ano no equipo Sportmaster e estou a desenvolver probas automatizadas nun dos grandes proxectos. En abril, os mozos de Sportmaster Lab e eu falamos nunha conferencia en Krasnodar, o meu informe chamábase "Probas unitarias nun DBMS" e agora quero compartilo contigo. Haberá moito texto, polo que decidín dividir o informe en dúas publicacións. Na primeira, falaremos de autotests e probas en xeral, e na segunda, deterémonos máis en detalle sobre o noso sistema de probas unitarias e os resultados da súa aplicación.
En primeiro lugar, unha teoría un pouco aburrida. Que son as probas automatizadas? Trátase de probas realizadas por software, e na TI moderna úsase cada vez máis no desenvolvemento de software. Isto débese a que as empresas están crecendo, os seus sistemas de información e, en consecuencia, a cantidade de funcionalidades que hai que probar é cada vez maior. Realizar probas manuais é cada vez máis caro.
Traballei para unha gran empresa cuxos lanzamentos saen cada dous meses. Ao mesmo tempo, pasou un mes enteiro en facer que unha ducia de probadores revisen manualmente a funcionalidade. Grazas á implementación da automatización por parte dun pequeno equipo de desenvolvedores, puidemos reducir o tempo de proba a dúas semanas en ano e medio. Non só aumentamos a velocidade das probas, senón que tamén melloramos a súa calidade. As probas automatizadas lánzanse regularmente e sempre realizan todo o curso das comprobacións incluídas nelas, é dicir, excluímos o factor humano.
A TI moderna caracterízase polo feito de que un desenvolvedor pode ser obrigado non só a escribir o código do produto, senón tamén a escribir probas unitarias que comproben este código.
Pero e se o seu sistema baséase principalmente na lóxica do servidor? Non hai solución universal nin boas prácticas no mercado. Como regra xeral, as empresas resolven este problema creando o seu propio sistema de probas autoescritos. Este é o noso propio sistema de probas automatizadas que se creou no noso proxecto e falarei sobre iso no meu informe.
Proba a fidelidade
En primeiro lugar, imos falar do proxecto onde implantamos un sistema de probas automatizadas. O noso proxecto é o sistema de fidelización Sportmaster (por certo, xa escribimos sobre el en ).
Se a túa empresa é o suficientemente grande, entón o teu sistema de fidelización terá tres propiedades estándar:
- O teu sistema estará moi cargado
- O seu sistema conterá procesos informáticos complexos
- O teu sistema mellorarase activamente.
Imos en orde... En total, se temos en conta todas as marcas Sportmaster, temos máis de 1000 tendas en Rusia, Ucraína, China, Casaquistán e Bielorrusia. Nestas tendas realízanse unhas 300 compras cada día. É dicir, cada segundo entran 000-3 comprobacións no noso sistema. Por suposto, o noso sistema de fidelización está moi cargado. E xa que se usa activamente, debemos proporcionar os máis altos estándares da súa calidade, porque calquera erro no software significa grandes perdas monetarias, reputacionais e doutro tipo.
Ao mesmo tempo, Sportmaster realiza máis de cen promocións diferentes. Hai unha variedade de promocións: hai promocións de produtos, hai as dedicadas ao día da semana, hai as vinculadas a unha tenda concreta, hai promocións polo importe do recibo, as hai polo número de mercadorías. En xeral, non está mal. Os clientes teñen bonos e códigos promocionais que se utilizan ao facer compras. Todo isto leva ao feito de que calcular calquera orde é unha tarefa moi non trivial.
O algoritmo que implementa o procesamento de pedidos é realmente terrible e complicado. E calquera cambio neste algoritmo é bastante arriscado. Parecía que os cambios aparentemente insignificantes podían levar a efectos bastante imprevisibles. Pero son precisamente procesos informáticos tan complexos, especialmente aqueles que implementan funcionalidades críticas, os mellores candidatos para a automatización. Comprobar manualmente ducias de casos similares leva moito tempo. E dado que o punto de entrada no proceso non se modifica, describilo unha vez, pode crear rapidamente probas automáticas e estar seguro de que a funcionalidade funcionará.
Dado que o noso sistema se usa activamente, a empresa quererá algo novo de ti, vivirá cos tempos que corren e estará orientada ao cliente. No noso sistema de fidelización, os lanzamentos saen cada dous meses. Isto significa que cada dous meses temos que realizar unha regresión completa de todo o sistema. Ao mesmo tempo, naturalmente, como en calquera TI moderna, o desenvolvemento non pasa inmediatamente do desenvolvedor á produción. Orixínase no circuíto do programador, despois pasa sucesivamente polo banco de probas, libera, acepta e só despois acaba na produción. Como mínimo, nos circuítos de proba e liberación, necesitamos realizar unha regresión completa de todo o sistema.
As propiedades descritas son estándar para case calquera sistema de fidelización. Imos falar das características do noso proxecto.
Tecnoloxicamente, o 90% da lóxica do noso sistema de fidelización está baseado en servidor e está implementado en Oracle. Hai un cliente exposto en Delphi, que realiza a función de administrador automatizado do lugar de traballo. Hai servizos web expostos para aplicacións externas (por exemplo, un sitio web). Polo tanto, é moi lóxico que se despregamos un sistema de probas automatizadas, o fagamos en Oracle.
O sistema de fidelización en Sportmaster existe desde hai máis de 7 anos e foi creado por desenvolvedores únicos... O número medio de desenvolvedores no noso proxecto durante estes 7 anos foi de 3-4 persoas. Pero durante o último ano, o noso equipo creceu significativamente, e agora hai 10 persoas traballando no proxecto. É dicir, chegan ao proxecto persoas que non están familiarizadas coas tarefas, procesos e arquitectura típicos. E hai un maior risco de que perdamos erros.
O proxecto caracterízase pola ausencia de probadores dedicados como unidades de persoal. Existen, por suposto, probas, pero as probas son realizadas por analistas, ademais das súas outras principais responsabilidades: comunicarse cos clientes empresariais, usuarios, desenvolver os requisitos do sistema, etc. etc... A pesar de que as probas se realizan de moi alta calidade (isto é especialmente apropiado mencionalo, xa que algúns dos analistas poden chamar a atención deste informe), a eficacia da especialización e concentración nunha cousa non foi cancelada. .
Tendo en conta todo o anterior, para mellorar a calidade do produto entregado e reducir o tempo de desenvolvemento, a idea de automatizar as probas nun proxecto parece moi lóxica. E en diferentes etapas da existencia do sistema de fidelización, os desenvolvedores individuais fixeron esforzos para cubrir o seu código con probas unitarias. En xeral, foi un proceso bastante desarticulado, con cada un usando a súa propia arquitectura e métodos. Os resultados finais eran comúns ás probas unitarias: desenvolvéronse probas, empregáronse durante algún tempo, gardáronse nun almacenamento de ficheiros versionados, pero nalgún momento deixaron de executarse e esquecéronse. En primeiro lugar, isto debeuse a que as probas estaban máis ligadas a un intérprete concreto, e non ao proxecto.
utPLSQL vén ao rescate
Sabes algo de Stephen Feuerstein?
Este é un tipo intelixente que dedicou unha longa parte da súa carreira a traballar con Oracle e PL/SQL, e escribiu un gran número de traballos sobre este tema. Un dos seus famosos libros chámase: "Oracle PL/SQL. Para profesionais". Foi Stephen quen desenvolveu a solución utPLSQL ou, como significa, o marco de probas unitarias para Oracle PL/SQL. A solución utPLSQL creouse en 2016, pero segue traballando activamente e lánzanse novas versións. No momento do informe, a última versión remóntase ao 24 de marzo de 2019.
Que é. Este é un proxecto de código aberto independente. Pesa un par de megabytes, incluíndo exemplos e documentación. Fisicamente, é un esquema separado na base de datos ORACLE cun conxunto de paquetes e táboas para organizar as probas unitarias. A instalación leva uns segundos. Unha característica distintiva de utPLSQL é a súa facilidade de uso.
Globalmente, utPLSQL é un mecanismo para executar probas unitarias, onde unha proba unitaria se entende como procedementos por lotes de Oracle ordinarios, cuxa organización segue determinadas regras. Ademais do lanzamento, utPLSQL almacena un rexistro de todas as súas execucións de proba e tamén ten un sistema de informes interno.
Vexamos un exemplo de como é o código de proba unitaria, implementado mediante esta técnica.
Así, a pantalla mostra o código dunha especificación típica do paquete con probas unitarias. Cales son os requisitos obrigatorios? O paquete debe levar o prefixo "utp_". Todos os procedementos con probas deben ter exactamente o mesmo prefixo. O paquete debe conter dous procedementos estándar: "utp_setup" e "utp_teardown". O primeiro procedemento chámase reiniciando cada proba unitaria, o segundo despois do lanzamento.
"utp_setup", como regra xeral, prepara o noso sistema para executar unha proba unitaria, por exemplo, creando datos de proba. "utp_teardown" - pola contra, todo volve á configuración orixinal e restablece os resultados do lanzamento.
Aquí tes un exemplo da proba unitaria máis sinxela que verifica a normalización do número de teléfono do cliente introducido ao formulario estándar para o noso sistema de fidelización. Non hai estándares obrigatorios sobre como escribir procedementos con probas unitarias. Como regra xeral, faise unha chamada a un método do sistema en proba e o resultado devolto por este método compárase co de referencia. É importante que a comparación do resultado de referencia e do obtido se produza mediante métodos estándar utPLSQL.
Unha proba unitaria pode ter calquera número de comprobacións. Como se pode ver no exemplo, facemos catro chamadas consecutivas ao método probado para normalizar o número de teléfono e avaliar o resultado despois de cada chamada. Ao desenvolver unha proba unitaria, debes ter en conta que hai comprobacións que non afectan de ningún xeito ao sistema e, despois de algunhas, hai que volver ao estado orixinal do sistema.
Por exemplo, na proba unitaria presentada simplemente formateamos o número de teléfono introducido, o que non afecta de ningún xeito ao sistema de fidelización.
E se escribimos probas unitarias usando o método de creación dun novo cliente, despois de cada proba crearase un novo cliente no sistema, o que pode afectar o lanzamento posterior da proba.
Así se executan as probas unitarias. Hai dúas opcións de lanzamento posibles: executar todas as probas unitarias desde un paquete específico ou executar unha proba unitaria específica nun paquete específico.
Así se ve un exemplo de sistema de informes internos. Baseándose nos resultados da proba unitaria, utPLSQL constrúe un pequeno informe. Nel vemos o resultado de cada verificación específica e o resultado global da proba unitaria.
6 regras de autotest
Antes de comezar a crear un novo sistema de probas automatizadas do sistema de fidelización, xunto coa xestión, determinamos os principios que deberían cumprir as nosas futuras probas automatizadas.
- As probas automáticas deben ser eficaces e deben ser útiles. Temos desenvolvedores marabillosos, que definitivamente hai que mencionar, porque algúns deles probablemente verán este informe e escriben un código marabilloso. Pero mesmo o seu marabilloso código non é perfecto e ten, ten e seguirá conter erros. Requírense probas automáticas para atopar estes erros. Se non é así, ou estamos escribindo autotests malos, ou chegamos a unha zona morta que, en principio, non se está a desenvolver. En ambos os casos, estamos facendo algo mal e o noso enfoque simplemente non ten sentido.
- Deben utilizarse autotests. Non ten sentido gastar moito tempo e esforzo en escribir un produto de software, poñelo nun repositorio e esquecelo. As probas deben realizarse e realizarse o máis regularmente posible.
- As probas automáticas deberían funcionar de forma estable. Independentemente da hora do día, do soporte de lanzamento e doutras configuracións do sistema, as probas deberían dar o mesmo resultado. Como regra xeral, isto está garantido polo feito de que as probas automáticas funcionan con datos de proba especiais con configuracións do sistema fixas.
- As probas automáticas deberían funcionar a unha velocidade aceptable para o teu proxecto. Este tempo determínase individualmente para cada sistema. Algunhas persoas poden permitirse o luxo de traballar todo o día, mentres que outras consideran fundamental facelo en segundos. Vouvos contar un pouco máis adiante que estándares de velocidade conseguimos no noso proxecto.
- O desenvolvemento da autotest debe ser flexible. Non é recomendable rexeitar probar ningunha funcionalidade simplemente porque non o fixemos antes ou por algún outro motivo. utPLSQL non impón ningunha restrición ao desenvolvemento e Oracle, en principio, permítelle implementar unha variedade de cousas. A maioría dos problemas teñen solución, só é cuestión de tempo e esforzo.
- Desplegabilidade. Temos varios postos onde necesitamos facer probas. En cada stand pódese actualizar un volcado de datos en calquera momento. É necesario levar a cabo un proxecto con probas automáticas de forma que poida realizar sen dor a súa instalación total ou parcial.
E no segundo post dentro dun par de días contarei que fixemos e que resultados conseguimos.
Fonte: www.habr.com