Hola Habr!
Em dic Maxim Ponomarenko i sóc desenvolupador a Sportmaster. Tinc 10 anys d'experiència en l'àmbit informàtic. Va començar la seva carrera en proves manuals, després va passar al desenvolupament de bases de dades. Durant els últims 4 anys, acumulant els coneixements adquirits en proves i desenvolupament, he estat automatitzant les proves a nivell de DBMS.
Fa poc més d'un any que estic a l'equip Sportmaster i estic desenvolupant proves automatitzades en un dels grans projectes. A l'abril, els nois de Sportmaster Lab i jo vam parlar en una conferència a Krasnodar, el meu informe es deia "Proves d'unitat en un DBMS" i ara vull compartir-lo amb vosaltres. Hi haurà molt de text, així que vaig decidir dividir l'informe en dues publicacions. En el primer, parlarem d'autotests i proves en general, i en el segon, m'atendré amb més detall en el nostre sistema de proves unitàries i els resultats de la seva aplicació.
Primer, una mica de teoria avorrida. Què són les proves automatitzades? Es tracta de proves que es duen a terme amb programari, i a la informàtica moderna s'utilitza cada cop més en el desenvolupament de programari. Això es deu al fet que les empreses creixen, els seus sistemes d'informació creixen i, en conseqüència, creix la quantitat de funcionalitats que cal provar. Fer proves manuals és cada cop més car.
Vaig treballar per a una gran empresa els llançaments de la qual surten cada dos mesos. Al mateix temps, es va dedicar un mes sencer a fer que una dotzena de provadors comprovessin manualment la funcionalitat. Gràcies a la implementació de l'automatització per part d'un petit equip de desenvolupadors, vam poder reduir el temps de prova a 2 setmanes en un any i mig. No només hem augmentat la velocitat de les proves, sinó que també hem millorat la seva qualitat. Les proves automatitzades es posen en marxa periòdicament i sempre realitzen tot el curs de controls que s'hi inclouen, és a dir, excloem el factor humà.
La TI moderna es caracteritza pel fet que es pot requerir que un desenvolupador no només escrigui codi de producte, sinó també que escrigui proves unitàries que comprovin aquest codi.
Però, què passa si el vostre sistema es basa principalment en la lògica del servidor? No hi ha una solució universal o bones pràctiques al mercat. Com a regla general, les empreses resolen aquest problema creant el seu propi sistema de proves escrit per si mateix. Aquest és el nostre propi sistema de proves automatitzats escrit per nosaltres mateixos que es va crear en el nostre projecte i en parlaré al meu informe.
Prova de fidelitat
En primer lloc, parlem del projecte on vam desplegar un sistema de proves automatitzat. El nostre projecte és el sistema de fidelització Sportmaster (per cert, ja ho vam escriure a ).
Si la vostra empresa és prou gran, el vostre sistema de fidelització tindrà tres propietats estàndard:
- El vostre sistema estarà molt carregat
- El vostre sistema contindrà processos informàtics complexos
- El vostre sistema es millorarà activament.
Anem en ordre... En total, si tenim en compte totes les marques Sportmaster, tenim més de 1000 botigues a Rússia, Ucraïna, Xina, Kazakhstan i Bielorússia. En aquestes botigues es fan unes 300 compres cada dia. És a dir, cada segon entren 000-3 comprovacions al nostre sistema. Naturalment, el nostre sistema de fidelització està molt carregat. I com que s'utilitza activament, hem d'oferir els estàndards més alts de la seva qualitat, perquè qualsevol error en el programari suposa grans pèrdues monetàries, reputacionals i altres.
Paral·lelament, Sportmaster realitza més d'un centenar de promocions diferents. Hi ha diferents promocions: hi ha promocions de productes, n'hi ha de dedicades al dia de la setmana, n'hi ha lligades a una botiga concreta, hi ha promocions per l'import del rebut, n'hi ha pel nombre de mercaderies. En general, no està malament. Els clients tenen bonificacions i codis promocionals que s'utilitzen en fer compres. Tot això porta al fet que calcular qualsevol ordre és una tasca molt no trivial.
L'algorisme que implementa el processament de comandes és realment terrible i complicat. I qualsevol canvi a aquest algorisme és força arriscat. Semblava que els canvis més insignificants aparentment podrien portar a efectes força impredictibles. Però són precisament processos informàtics tan complexos, especialment aquells que implementen una funcionalitat crítica, els millors candidats per a l'automatització. Comprovar manualment desenes de casos similars requereix molt de temps. I com que el punt d'entrada al procés no canvia, després d'haver-lo descrit una vegada, podeu crear ràpidament proves automàtiques i estar segur que la funcionalitat funcionarà.
Com que el nostre sistema s'utilitza activament, l'empresa voldrà alguna cosa nova de tu, viure amb els temps i estar orientada al client. Al nostre sistema de fidelització, els llançaments surten cada dos mesos. Això vol dir que cada dos mesos hem de fer una regressió completa de tot el sistema. Al mateix temps, naturalment, com en qualsevol TI moderna, el desenvolupament no passa immediatament del desenvolupador a la producció. S'origina al circuit del desenvolupador, després passa successivament pel banc de proves, llança, accepta i només després acaba en producció. Com a mínim, en els circuits de prova i d'alliberament, hem de realitzar una regressió completa de tot el sistema.
Les propietats descrites són estàndard per a gairebé qualsevol sistema de fidelització. Parlem de les característiques del nostre projecte.
Tecnològicament, el 90% de la lògica del nostre sistema de fidelització es basa en servidor i s'implementa a Oracle. Hi ha un client exposat a Delphi, que fa la funció d'administrador automatitzat del lloc de treball. Hi ha serveis web exposats per a aplicacions externes (per exemple, un lloc web). Per tant, és molt lògic que si despleguem un sistema de proves automatitzat, ho farem a Oracle.
El sistema de fidelització a Sportmaster fa més de 7 anys que va ser creat per desenvolupadors únics... La mitjana de desenvolupadors del nostre projecte durant aquests 7 anys va ser de 3-4 persones. Però durant l'últim any, el nostre equip ha crescut considerablement, i ara hi ha 10 persones treballant en el projecte. És a dir, persones que no estan familiaritzades amb les tasques, els processos i l'arquitectura habituals vénen al projecte. I hi ha un major risc que ens perdem errors.
El projecte es caracteritza per l'absència de provadors dedicats com a unitats de personal. Hi ha, per descomptat, proves, però les proves les fan els analistes, a més de les seves altres responsabilitats principals: comunicar-se amb clients comercials, usuaris, desenvolupar els requisits del sistema, etc. etc... Malgrat que les proves es duen a terme amb una qualitat molt alta (això és especialment adequat esmentar-ho, ja que alguns dels analistes poden cridar l'atenció d'aquest informe), l'efectivitat de l'especialització i la concentració en una cosa no s'ha cancel·lat. .
Tenint en compte tot l'anterior, per millorar la qualitat del producte lliurat i reduir el temps de desenvolupament, la idea d'automatitzar les proves en un projecte sembla molt lògica. I en diferents etapes de l'existència del sistema de fidelització, els desenvolupadors individuals van fer esforços per cobrir el seu codi amb proves unitàries. En general, va ser un procés força desarticulat, amb cadascú utilitzant la seva pròpia arquitectura i mètodes. Els resultats finals eren comuns a les proves unitàries: es van desenvolupar proves, s'utilitzaven durant un temps, s'emmagatzemaven en un emmagatzematge de fitxers versionats, però en algun moment es van deixar d'executar i es van oblidar. En primer lloc, això es va deure al fet que les proves estaven més lligades a un intèrpret concret, i no al projecte.
utPLSQL ve al rescat
Saps alguna cosa sobre Stephen Feuerstein?
Aquest és un noi intel·ligent que va dedicar una llarga part de la seva carrera a treballar amb Oracle i PL/SQL, i ha escrit un gran nombre de treballs sobre aquest tema. Un dels seus famosos llibres es diu: "Oracle PL/SQL. Per a professionals". Va ser l'Stephen qui va desenvolupar la solució utPLSQL, o, com ho significa, el marc de prova d'unitat per a Oracle PL/SQL. La solució utPLSQL es va crear el 2016, però es continua treballant activament i es publiquen noves versions. En el moment de l'informe, l'última versió data del 24 de març de 2019.
Què es. Aquest és un projecte de codi obert independent. Pesa un parell de megabytes, incloent exemples i documentació. Físicament, és un esquema separat a la base de dades ORACLE amb un conjunt de paquets i taules per organitzar les proves unitàries. La instal·lació triga uns segons. Una característica distintiva d'utPLSQL és la seva facilitat d'ús.
Globalment, utPLSQL és un mecanisme per executar proves unitàries, on una prova unitària s'entén com a procediments per lots d'Oracle ordinaris, l'organització dels quals segueix determinades regles. A més de llançar-se, utPLSQL emmagatzema un registre de totes les vostres proves i també té un sistema d'informes intern.
Vegem un exemple de com és el codi de prova d'unitat, implementat amb aquesta tècnica.
Per tant, la pantalla mostra el codi d'una especificació de paquet típica amb proves unitàries. Quins són els requisits obligatoris? El paquet ha de tenir el prefix "utp_". Tots els procediments amb proves han de tenir exactament el mateix prefix. El paquet ha de contenir dos procediments estàndard: "utp_setup" i "utp_teardown". El primer procediment s'anomena reiniciant cada prova d'unitat, el segon després del llançament.
“utp_setup”, per regla general, prepara el nostre sistema per executar una prova d'unitat, per exemple, creant dades de prova. "utp_teardown": per contra, tot torna a la configuració original i restableix els resultats del llançament.
Aquí teniu un exemple de la prova d'unitat més senzilla que verifica la normalització del número de telèfon del client introduït al formulari estàndard per al nostre sistema de fidelització. No hi ha estàndards obligatoris sobre com escriure procediments amb proves unitàries. Per regla general, es fa una trucada a un mètode del sistema que s'està provant i el resultat retornat per aquest mètode es compara amb el de referència. És important que la comparació del resultat de referència i l'obtingut es faci mitjançant mètodes estàndard utPLSQL.
Una prova d'unitat pot tenir qualsevol nombre de comprovacions. Com es pot veure a l'exemple, fem quatre trucades consecutives al mètode provat per normalitzar el número de telèfon i avaluar el resultat després de cada trucada. A l'hora de desenvolupar una prova d'unitat, cal tenir en compte que hi ha comprovacions que no afecten de cap manera el sistema, i després d'alguna cosa cal tornar a l'estat original del sistema.
Per exemple, a la prova d'unitat presentada simplement formatem el número de telèfon d'entrada, cosa que no afecta de cap manera el sistema de fidelització.
I si escrivim proves unitàries mitjançant el mètode de creació d'un client nou, després de cada prova es crearà un client nou al sistema, cosa que pot afectar el llançament posterior de la prova.
Així s'executen les proves unitàries. Hi ha dues opcions de llançament possibles: executar totes les proves unitàries des d'un paquet específic o executar una prova unitària específica en un paquet específic.
Així és un exemple de sistema d'informes interns. A partir dels resultats de la prova unitària, utPLSQL crea un petit informe. Hi veiem el resultat de cada control concret i el resultat global de la prova unitària.
6 regles dels autotests
Abans de començar a crear un nou sistema de prova automatitzada del sistema de fidelització, juntament amb la direcció, vam determinar els principis que haurien de complir les nostres futures proves automatitzades.
- Els autotests han de ser efectius i han de ser útils. Tenim desenvolupadors meravellosos, que definitivament cal esmentar, perquè alguns d'ells probablement veuran aquest informe i escriuen un codi meravellós. Però fins i tot el seu meravellós codi no és perfecte i té, té i continuarà contenir errors. Es requereixen autotests per trobar aquests errors. Si no és així, o estem escrivint autotests dolents, o bé hem entrat en una zona morta que, en principi, no s'està desenvolupant. En ambdós casos, estem fent alguna cosa malament i el nostre enfocament simplement no té sentit.
- S'han d'utilitzar autotests. No té sentit dedicar molt de temps i esforços a escriure un producte de programari, posar-lo en un dipòsit i oblidar-lo. Les proves s'han de fer amb la màxima regularitat possible.
- Els autotests haurien de funcionar de manera estable. Independentment de l'hora del dia, el suport de llançament i altres configuracions del sistema, les proves haurien de donar lloc al mateix resultat. Com a regla general, això s'assegura pel fet que les proves automàtiques funcionen amb dades de prova especials amb una configuració fixa del sistema.
- Les proves automàtiques haurien de funcionar a una velocitat acceptable per al vostre projecte. Aquest temps es determina individualment per a cada sistema. Algunes persones poden permetre's el luxe de treballar tot el dia, mentre que d'altres consideren fonamental fer-ho en qüestió de segons. Us explicaré una mica més endavant quins estàndards de velocitat hem aconseguit en el nostre projecte.
- El desenvolupament d'autotest ha de ser flexible. No és aconsellable negar-se a provar cap funcionalitat simplement perquè no ho hem fet abans o per algun altre motiu. utPLSQL no imposa cap restricció al desenvolupament i Oracle, en principi, permet implementar una varietat de coses. La majoria dels problemes tenen solució, només és qüestió de temps i esforç.
- Desplegabilitat. Tenim diversos estands on hem de fer proves. A cada estand, es pot actualitzar un bolcat de dades en qualsevol moment. Cal realitzar un projecte amb proves automàtiques de manera que es pugui dur a terme sense dolor la seva instal·lació total o parcial.
I al segon post d'aquí a un parell de dies us explicaré què hem fet i quins resultats hem aconseguit.
Font: www.habr.com