Mjete testimi për ata të cilëve u vjen keq të humbin kohën e tyre në një rutinë. Mjetet e testimit për ata që ndjejnë keqardhje për humbjen e kohës në testimin rutinë të automatizuar 1c
Tema e testimit të skenarit është zbuluar prej kohësh, dhe pothuajse çdo kompani e kupton nevojën për të përdorur TDD dhe BDD në një shkallë ose në një tjetër. Grupi ynë i vogël i zhvilluesve 1C nuk ishte përjashtim. Sidoqoftë, nga momenti i të kuptuarit të nevojës, deri në përdorimin aktual të teknologjisë, koha kalon, dhe gjatë rrugës, mendjet e papjekura, siç është autori i këtij artikulli, fillojnë të mendojnë për efektivitetin e gjithë kësaj sipërmarrjeje. Nëse po pyesni sesi një grup djemsh të zgjuar kanë zbatuar diçka të ngjashme me testimin e skenarit në punën e tyre, jeni të mirëpritur.
Sfondi
Ekzistojnë mjete shumë të fuqishme dhe të përparuara të testimit të UI në treg. Ka gjuhë të veçanta të shkrimit, shumë dokumentacion dhe metodologji. Me fjalë të tjera, "Keni një problem? Ka një zgjidhje! ".Nga ana tjetër, energjia e shpenzuar për zgjidhjen e problemit duhet të korrespondojë disi me energjinë e prodhuar nga kolektivi në tërësi. Dhe në praktikë, nëse ndërmarrjet e mëdha mund të lejojnë stafin e specialistëve dhe testuesve individualë të QA me vendosjen e proceseve në maksimum, atëherë zyrat e vogla nuk janë gjithmonë në gjendje ta bëjnë këtë, disa nga funksionet duhet t'i besohen vetë, dhe filozofia e vetë procesit është pak e përkulur ...
Pra, duke pasur parasysh: një grup zhvilluesish të shpërndarë gjeografikisht për 1C deri në 10 persona, mesatarisht, deri në 5 projekte aktive, kryesisht zhvillimin e zgjidhjeve me porosi pa përdorur produkte standarde 1C.
Objektivi: Zbatimi i proceseve të testimit të zhvillimit në mënyrë sa më efikase, duke përfshirë testimin e ndërfaqes dhe logjikës së biznesit. Efikasiteti kuptohet si ekuilibri kur koha e shpenzuar për testim ka ende kuptim për sa i përket rezultatit përfundimtar. Unë e pranoj që kjo linjë është shumë subjektive, dhe ndoshta justifikon plotësisht shprehjen "një përpjekje për të krahasuar të ngrohtën me të butën". Çfarë qëllimi testimi i skenarit shërben si i tillë, mendoj se lexuesi e di edhe më mirë se autori.
Pas hulumtimit të një numri sistemesh instrumentale nga shitësit perëndimorë, si dhe testimit të skenarëve nga versioni 1C 3.0, dhe xUnitFor1C, u duk se ne ende nuk ishim pjekur mendërisht për të zbatuar këto teknologji. Koha kaloi, por ne ende nuk mund të rritemi. Në të njëjtën kohë, gjithçka nga brenda kërkonte dhe kërkonte të paktën një lloj zgjidhjeje.
Duke marrë shënimet e vjetra, një listë e kërkesave për një produkt të mundshëm softuer u përpilua edhe një herë:
- Zgjidhja duhet të jetë e bazuar në re
- Baza e provës për të gjitha zhvillimet duhet të jetë uniforme
- Duhet të ketë kontroll të qasjes në aplikacione (secili programues ka grupin e tij të zhvillimit)
- Zhvillimi dhe ekzekutimi i testit duhet të jetë në një IDE
- Skriptet duhet të programohen, jo të regjistrohen nga veprimet e përdoruesit
- Desirableshtë e dëshirueshme që gjuha programuese e testit të jetë e ngjashme me gjuhën 1C
- Testet duhet të lëshohen një buton në të njëjtën kohë, pa manipulime paraprake, përpilime, asamble, shkarkime, shkarkime dhe gjëra të tjera.
- Në procesin e shkrimit të një testi, duhet të jetë e mundur të analizohet struktura e dritareve dhe detajet e aplikacionit në test në drejtim të modelit të ndërfaqes së menaxhuar 1C, dhe kjo duhet të jetë në programin ku testi vetë po zhvillohet. Duhet të jetë e mundur të merren vetitë e fushave të aplikacionit nën provë, kur ecni nëpër pemën e kontrolleve në bazën e testimit - aplikacioni nën test duhet të kujtojë dhe të tregojë se ku është ky kontroll.
- Asnjë bazë referimi nuk duhet të përdoret për të testuar logjikën e biznesit
- Për të praktikuar testin, nuk duhet të ketë një bazë të përgatitur posaçërisht, të gjitha testet duhet të jenë në gjendje të punojnë dhe të krijojnë gjithçka që ju nevojitet vetë
Ndoshta kaluan edhe gjashtë muaj të tjerë, dhe më në fund mora vendimin për të filluar në një mënyrë ngadalë opsionale zhvillimin e një testuesi tjetër biçikletash (më tej - një testues), dhe kjo është ajo që doli.
Si duket
Si rezultat, lindi një aplikacion i bazuar në 1C, në të cilin testet e skenarit shkruhen dhe ekzekutohen për zgjidhje të bazuara në 1C. Përdorimi i përditshëm është diçka si kjo: testuesi është i hapur për programuesin në monitorin e dytë gjatë gjithë ditës së punës. Në bazën e të dhënave të kontabilitetit të projektit, menaxheri tregon një grup të detyrueshëm testesh që duhet të mbulojnë projektin.Ekzistojnë gjithashtu një numër testesh standarde, të detyrueshme që duhet të kryhen nga programuesi për secilën detyrë. Për shembull, nëse dokumenti futet në bazë, duhet të ketë një test të hyrjes në bazë. Me fjalë të tjera, programuesi e di se cilat teste duhet të krijohen.
Kur shkruhen testet
Në praktikë, në gjysmën e rasteve, testet shkruhen gjatë procesit të zhvillimit (është shumë i përshtatshëm për automatizimin e një rutine kur keni nevojë të përsërisni të njëjtat veprime sa herë që aplikacioni të rifillojë). Në gjysmën tjetër - pas. Siç duhet ta ketë vënë re lexuesi i sofistikuar, kjo situatë vështirë se mund të quhet një BDD klasike.Shembull testi
Le të themi se ekziston një projekt i quajtur "Zhvilloni Kompletin e Ndërtimit të Dokumenteve". Ky dokument kërkon një formë liste me një filtër sipas magazinave. Koncepti i përgjithshëm i punës së listave në zgjidhjen e konsideruar është si më poshtë: nëse është instaluar një filtër, përveç filtrimit të dokumenteve sipas vlerës së filtrit, kërkohet që vlera e filtrit të shërbejë si vlerë e paracaktuar kur futni një dokument të ri nga këtë formë. Kështu, nëse magazina është e instaluar, ajo duhet të instalohet automatikisht kur futni një dokument të ri.Vetëm në shikim të parë duket se një test nuk është i nevojshëm për një skenar të tillë, megjithatë, duke pasur parasysh shumëllojshmërinë e opsioneve për futjen e dokumenteve, fusha Magazina mund të marrë vlera të ndryshme. Në fund të fundit, dokumenti mund të kopjohet, ose përdoruesi ka një kompani tjetër të specifikuar në cilësimet e paracaktuara, dhe magazina e zgjedhur në filtër nuk është njësia e saj organizative. Në një mënyrë apo tjetër, kështu do të duket testi (ne kemi të huaj në ekipin tonë, kështu që vetë testuesi është i shkruar në anglisht, dhe zgjidhja e aplikuar në vetvete është menduar për punën e klientëve amerikanë):
Mbi të është aplikacioni që po zhvillohet, më poshtë është testuesi, në modalitetin e klientit të hollë, baza e provës në re. Kodi që shihni është shkruar në gjuhën 1C. Kodi i skenarit ndërvepron me aplikacionin e klientit që funksionon përmes mbështjellësve të metodave të aplikacionit 1C në provë, për shembull, kështu duket metoda Choose (...);
Unë u përpoqa të zbatoja pothuajse të gjitha operacionet e ndërfaqes në testues, por edhe nëse keni nevojë për diçka specifike, gjithmonë mund të merrni një objekt të fushës nën provë dhe të ekzekutoni çdo metodë mbi të që zbatohet në modelin e aplikacionit në provë.
Do të kaloj në skenarë më interesantë.
Ndërlidhja e testeve
Për të zhvilluar një skenar për krijimin dhe postimin e një dokumenti të Asamblesë, si në shembullin e mëparshëm, duhet të kemi shumë të dhëna shtesë: përbërja e kërkuar e drejtorive, mbetjet e materialeve në magazinë, që të paktën nënkupton praninë e një lloj mbërritjeje në magazinë. Siç thashë më herët, ne vendosëm vetë që testet duhet të kryhen në kushtet kur baza e referencës nuk ekziston, ekziston vetëm një imazh fillestar i aplikacionit, ku ka të paktën një përdorues me të drejta administrative, klasifikues të mbushur dhe vlerat e paracaktuara për përdoruesit e rehatshëm të punës fillestare.Sidoqoftë, do të jetë joefikase të shkruani një skenar të plotë çdo herë që do të krijojë të gjitha të dhënat e nevojshme "gjatë rrugës". Unë do të doja të zhvilloja një test të parametruar që jo vetëm që di të bëjë diçka, por gjithashtu pranon parametra. Për shembull, për të krijuar një faturë në bazën e të dhënave, duhet të ketë një test që do ta krijojë atë. Dhe asgjë nuk na pengon që ta bëjmë këtë test të parametërizuar, dhe të transferojmë të gjitha të dhënat e nevojshme në të, për shembull, në cilën datë të bëjmë mbërritjen, në cilën magazinë dhe cilat materiale / shërbime të mbërrijmë. Nga ana tjetër, testi për krijimin e një dëftese do të përdorë teste për krijimin e një depoje, materiale që do të priten në parametrat e llojit të paketimit, llojit, faktorëve të konvertimit, etj.
Meqenëse aplikacioni ynë është i turbullt dhe baza e testit është e unifikuar, secili programues, duke zhvilluar një test, mund, në procesin e shkrimit të një testi drejtpërdrejt në diçka, ta parametrojë atë, duke e hapur atë për përdorim të gjerë nga programuesit e tjerë.
Këtu është një shembull se si testi i Asamblesë përgatitet për pranim:
(çmimet, shumat dhe sasitë vendosen si vargje për të shmangur problemet e pozitivëve të rremë të kontrollit të testit nëse ai kryhet në një lokalitet tjetër, ku ndarësi i treshave dhe pjesëve të pjesshme, për shembull, mund të ndryshojë)
Në procesin e ekzekutimit të këtij testi, do të ekzekutohen një numër testesh të tjera, të cilat do të krijojnë gjithçka të nevojshme për të qenë në gjendje të testoni Asamblenë si të tillë. Ky është afërsisht cili do të jetë rezultati në bazën e të dhënave:
Testimi i logjikës së biznesit
Përveç faktit që të gjithë butonat "klikoheshin" dhe fushat "zgjidheshin", ngjarja e testimit do të kishte lënë një plagë të thellë në zemër nëse nuk do të kisha testuar rezultatet e mekanizmave të ekzekutimit të dokumentit dhe nuk do të kisha vlerësuar kontabilitetin aktual situata në bazën e të dhënave.Unë rrëfej se kam grumbulluar trurin tim për një kohë të gjatë, si është më mirë ta zbatosh atë në mënyrë që pa një bazë referimi, dhe në mënyrë që të jetë e lehtë dhe e thjeshtë. Nuk mund të mendoja për ndonjë gjë më të mirë sesa të kontrolloja me lehtësi lëvizjet e dokumenteve në lidhje me testimin e raportimit.
Këtu është një shembull i një raporti mbi lëvizjet e dokumenteve në aplikacionin në provë:
Kjo është mënyra se si testuesi do të kontrollojë këto lëvizje:
Zonat e kuqe janë të rëndësishme për verifikim. Përveç zonave, testuesi mund të përdoret për të kontrolluar fushat sipas shabllonit.
Kontrolle tipike
Problemi i kontrollimit të objekteve të të njëjtit lloj shpesh lind. Për shembull, në gjysmën e rasteve, format e dokumenteve kanë një seksion tabelor, dhe gabimet e programit shpesh bëhen kur kopjoni rreshta, fshini rreshtin e parë, ose futni dhe refuzoni të futni rreshtat e parë / pasues. Për këtë qëllim, është e mundur të zhvillohet një metodë testimi që nuk ka një skenar të pavarur, por që përdoret vetëm për thirrjet lokale. Kjo është shumë e përshtatshme, sepse me kalimin e kohës, teste të tilla mund të rriten duke shtuar elementë të tjerë testimi atje, gjë që kërkon një zgjerim automatik të mbulimit të aplikacionit për shkak të përdorimit të gjerë të testeve të tilla.Kontrolli i gabimit
Ekzistojnë të paktën tre lloje të gabimeve që dëshironi të kontrolloni. Lloji i parë janë gabimet e kodimit të tilla si pjesëtimi me zero, qasja në një pronë ose metodë që nuk ekziston. Lloji i dytë i gabimeve janë gabimet në logjikë, për shembull, kur klikoni në një buton, formulari duhet të mbyllet, por kjo nuk ndodh, ose kur kontrolloni kutinë, një pjesë e formularit duhet të bëhet e paarritshme ose e padukshme. Dhe lloji i tretë i gabimeve, gabimet e logjikës së biznesit, për shembull, kur fshini materialin nga një depo, nuk ishte e mundur të përcaktohej prania e tij nga baza e të dhënave. Të tre llojet e gabimeve mund të përpunohen në testues. Kur aktivizohet, testuesi regjistron një përjashtim, e shkruan atë në regjistër dhe mund të tregojë pirgun e thirrjes, për shembull, si kjo:
Një numër metodash për trajtimin e gabimeve të logjikës së biznesit janë zbatuar gjithashtu. Për shembull, testi juaj qëllimisht dëshiron të fshijë më shumë materiale dhe ju doni të kontrolloni nëse mesazhi do të formohet në mënyrë korrekte dhe nëse do të gjenerohet fare.
Këtu është një shembull i zbatimit të një kontrolli të tillë në një nga testet:
Analiza e pemës së elementeve
Testuesi mund të lexojë objekte vizuale të aplikacionit në provë. Kjo është e përshtatshme, dhe nganjëherë thjesht e nevojshme për të shkruar një skenar, veçanërisht për zgjidhjet shumëgjuhëshe, ku emrat e butonave varen nga gjuha e përdoruesit, dhe ju duhet të përdorni një identifikues të brendshëm për të përpunuar ndërfaqen (përveç nëse, natyrisht, detyra është të kontrolloni sintaksën e etiketave në butona). Këtu është një shembull se si testuesi paraqet të dhënat e lexuara:
Përfundim
Në përgjithësi, doli të ishte një biçikletë e vogël për të ndihmuar programuesin 1C. Si cilësi pozitive programet, mund të vërehen sa vijon:- Testuesi është i lehtë për t'u instaluar dhe konfiguruar
- Fillimisht është shumë përdorues (përdoruesit krijohen gjithashtu në testues, në nënsistemin e administrimit)
- Nuk kërkon ndonjë njohuri të veçantë për të shkruar teste
- Ju lejon të zbatoni skenarë kompleksë të logjikës së biznesit
- Ju lejon të mbani mijëra teste për projekte të ndryshme në një bazë të dhënash dhe t'i "ripërdorni" ato. Për shembull, mund të krijoni një test, të përbashkët për të gjitha projektet, për të gjetur një dokument në një listë sipas numrit. Ose nëse baza e klientit zbatohet në bazë të një zgjidhjeje tipike për të cilën tashmë ka teste, ju mund të kontrolloni bazën e klientit duke thirrur të gjitha testet e prindërve, plus teste të krijuara posaçërisht për klientin
- Asnjë orar i ekzekutimit të provës
- Nuk ka një sistem të avancuar të analizave, tabelave dhe raporteve mbi rezultatet e testit
- Asnjë postë automatike dhe njoftime për atë që u prish, kush u prish dhe pse nuk zbatohen
- Nuk ka lidhje me depot, dhe versionet testuese
Teste të mbara, miq, dhe faleminderit për vëmendjen tuaj!
Etiketat:
- BDD
- testimi i skenarit
Artikulli diskuton një mekanizëm të ri të automatizuar të testimit që u shfaq për herë të parë në platformë në versionin 8.3. Pasi të keni studiuar materialin e artikullit, do të zbuloni:
- Çfarë është testimi i automatizuar në platformë?
- Si dhe kur ta përdorni?
- Çfarë dhe ku duhet të konfiguroni për ta ekzekutuar?
- Si mund të shkruaj një skript testi të automatizuar?
Zbatueshmëria
Artikulli diskuton platformën "1C: Ndërmarrja" botimi 8.3.4.465. Në versionin aktual të platformës, aftësitë e mekanizmit të testimit automatik janë zgjeruar ndjeshëm, por kjo nuk ndikoi në rëndësinë e materialit të artikullit. Stillshtë ende e rëndësishme.
Testimi i automatizuar në "1C: Ndërmarrja 8.3"
Platforma 1C: Enterprise 8.3 ka një mekanizëm të ri të krijuar për të simuluar veprimet ndërvepruese të përdoruesve të sistemit - testimi i automatizuar.
Testimi i automatizuar nuk mbështet punën me një ndërfaqe të rregullt, vetëm një të menaxhuar.
Gjatë testimit, përdoren dy lloje të aplikacioneve të klientit - menaxheri i testit dhe klienti i testit. Menaxheri i testit kontakton klientin e testit dhe drejton skriptin e testimit.
Një skript testi është i përfshirë në kodin gjuhësor që përshkruan një sekuencë veprimesh ndërvepruese që duhen kryer.
Për ta bërë këtë, objektet e reja janë shtuar në gjuhën e ngulitur, të cilat në nivel abstrakt përshkruajnë ndërfaqen e aplikacionit (në aspektin e dritareve, formave, kontrolleve, etj.), Dhe gjithashtu përshkruajnë veprimet e përdoruesit (lundrimi përmes konfigurimit, futja e të dhënave, etj) ...
Menaxheri i testit mund të jetë një klient i trashë ose i hollë. Test klient - klient i trashë, klient i hollë ose klient në internet.
Një menaxher test mund të lidhet me klientë të shumtë testues, dhe një klient test mund të lidhet vetëm me një menaxher.
Për të menaxhuar klientin, menaxheri krijon një lidhje TCP me të. Importantshtë e rëndësishme që testimi i automatizuar të mos kërkojë ndryshime në strukturën e konfigurimit.
Në thelb, klienti dhe menaxheri i testimit janë konfigurime që ekzekutohen me parametra specifikë të vijës së komandës, ku menaxheri menaxhon klientët duke "detyruar" dritaret dhe kontrollet të sillen sikur përdoruesi të ndërveprojë me ta.
Testimi i automatizuar ka kufizimet e tij. Kështu, për shembull, puna me një ndërfaqe të rregullt nuk mbështetet, por vetëm me një të menaxhuar.
Menaxheri i testimit dhe klienti duhet të konkurrojnë për të kryer testime të automatizuara.
Menaxheri mund të nisë nga rreshti i komandës me ndërprerësin / TESTMANAGER:
“C: \ Program Files (x86) \ 1cv8 \ 8.3.4.437 \ bin \ 1cv8c.exe” NDTERRMARRJE / F “X: \ test” / N Administrator / TESTMANAGER
Ju gjithashtu mund të ekzekutoni menaxherin e testit nga konfiguruesi.
Për ta bërë këtë, përmes menusë Shërbimi - Parametrat, hapni dialogun "Parametrat", në të cilin në skedën Start 1C: Enterprise - Additional, zgjidhni artikullin "Run as test manager":
Një mënyrë tjetër për të filluar menaxherin e testit është nga gjuha e ngulitur, duke përdorur metodën RunSystem (), në të cilën duhet të specifikoni rreshtin e komandës:
Drejtoni sistemin ("c: \ Program Files (x86) \ 1cv8 \ 8.3.4.437 \ bin \ 1cv8c.exe" NDTERRMARRJE / F X: \ test / N Administrator / TESTMANAGER ")
Klienti i testimit gjithashtu mund të nisë nga rreshti i komandës. Për ta bërë këtë, përdorni ndërprerësin e parametrave të linjës së komandës / TESTCLIENT.
Parametri TPort specifikon numrin e portit përmes të cilit do të kryhet ndërveprimi midis menaxherit dhe klientit të testimit. Nëse ky parametër nuk është specifikuar në rreshtin e komandës, do të përdoret porta 1538.
"C: \ Program Files (x86) \ 1cv8 \ 8.3.4.437 \ bin \ 1cv8c.exe" NDTERRMARRJE / F "X: \ Platform8Demo" / N Administrator / TESTCLIENT -Port 1539
Klienti i testit mund të nisë nga konfiguruesi. Për ta bërë këtë, përmes menysë Shërbimi - Opsionet, hapni dialogun "Opsionet", në të cilën në skedën Start 1C: Enterprise - Additional, zgjidhni artikullin "Run as testing client". Në këtë rast, do t'ju duhet të specifikoni numrin e portit të përdorur.
Vini re se për t'u lidhur me klientin test, duhet të dini dy parametra: adresën IP (ose emrin) e kompjuterit në të cilin po funksionon klienti testues dhe numrin e portës TCP që do të përdoret për komunikim.
Të dyja infobazat e ndryshme (konfigurimi i bazës së menaxherit të testimit mund të mos përkojë me konfigurimin e klientit të testimit) dhe e njëjta infobaza mund të përdoret si menaxher testimi dhe klient.
Për të kryer testime të automatizuara, ndiqni këto hapa:
- Zhvilloni një skenar testimi - shkruani përpunim të jashtëm ose të integruar në konfigurim, i cili do të përshkruajë rradhazi hapat që duhen kryer.
- Filloni menaxherin e testimit.
- Nisni një klient testimi (një ose më shumë).
- Drejtoni përpunimin e krijuar në menaxherin e testit, sigurohuni që veprimet e programuara të kryhen në klient.
Aplikacioni nën test përshkruhet nga një grup objektesh gjuhësore të përfshira që përdoren për të shkruar një skenar:
- Aplikimi i Testit;
- Testuar Dritarja e Aplikimit të Klientit;
- Testuar Ndërfaqja e Dritares së Komandës;
- TestedCommandInterface Group;
- TestedCommandInterfaceButton;
- Forma e testueshme;
- TestedFormField;
- TestGroupForms;
- TestFormButton;
- TestedFormTable;
- TestuarDekorimiFormat.
Ne do të përdorim konfigurimin demo "Aplikacioni i Menaxhuar" si konfigurimin e testuar.
Le të krijojmë një përpunim të jashtëm, të shtojmë një formë të re, në të cilën do të përcaktojmë një mbajtës për komandën e re "Run Test".
Në test, ne kryejmë veprimet e mëposhtme: krijoni një element të ri të drejtorisë "Magazina", futni rreshtin "Test magazina" në fushën Emri, pastaj shtypni butonin "Ruaj dhe mbyll".
Kodi i programit për këtë test do të duket kështu:
& Klienti
Procedura Drejtoni Testimin(Ekipi)
// Lidhu me aplikacionin nën provë
Aplikimi i testuar= E re Aplikimi i testuar("Localhost");
// Ne përpiqemi të lidhemi jo më shumë se një minutë
Koha Përfundim duke pritur= Data aktuale () + 60;
I lidhur = E gabuar;
Deri në CurrentDate ()> = = Koha Përfundim duke pritur Përpjekja e ciklit
Aplikimi nën test. InstallConnection();
I lidhur = E vërtetë;
Aborto;
Nje perjashtim
Fundi i Përpjekjeve; Fundi i ciklit; Nëse nuk është i lidhur atëherë
// Përfundoni testin
Aplikimi i testuar= E pacaktuar;
Për të raportuar ( "Krijimi i lidhjes dështoi!");
Kthim;
FundIf;
// Gjeni dritaren kryesore
Dritarja kryesore e testuar
= (Lloji ());
Dritarja kryesore e testuar. Aktivizo();
// Ekzekutoni komandën për të krijuar një artikull të katalogut të produktit
Dritarja kryesore e testuar. Ekzekuto komandën("E1cib / command / Directory. Magazina. Krijo");
Aplikimi i testuar.WaitDisplayObject(Një lloj ( "Forma e testueshme"), "Magazina*");
E testueshmeFormë=
TestedApplication.FindObject(Një lloj ( "Forma e testueshme"),
"Magazina*");
Formulari në test. Aktivizo();
// Vendosni një emër për produktin e ri
Elementi i Formës = TestableForm.FindObject(Një lloj ( "TestedFormField"),
"Emri");
Elementi i Formës.();
Elementi i Formës. HyrjaTeksti("Testi i magazinave");
// Shkruani artikullin
Elementi i Formës = TestableForm.FindObject(Një lloj ( "TestFormButton"),
"Regjistro dhe mbylle");
Elementi i Formës.();
Fundi i Procedurës
Në dialogun e parametrave të nisjes, së pari u zgjodh vlera "Run as test manager", duke përdorur shkurtoren e tastierës Ctrl + F5 u nis një sesion përdoruesi.
Pastaj vlera "Run si klient testues" u zgjodh në dialog dhe seanca e dytë e përdoruesit u nis duke përdorur shkurtoren e tastierës Ctrl + F5.
Kjo shmang nevojën për të specifikuar manualisht parametrat e kërkuar të vijës komanduese.
Kodi i mësipërm bën mjaft veprime të thjeshta, por ndërsa skenari bëhet më kompleks, sasia e kodit gjithashtu do të rritet, pasi është e nevojshme të përshkruhet çdo veprim ndërveprues i përdoruesit.
Këtu një tjetër vjen në shpëtim mundësi e re Platformat - regjistroni regjistrin e veprimeve të përdoruesit.
Për ta bërë këtë, duhet të ekzekutoni aplikacionin në një mënyrë të veçantë:
Klikoni mbi imazhin për ta zmadhuar.
Disa butona shfaqen në kokën e programit:
Butonat janë të destinuar për:
- filloni / ndaloni regjistrimin;
- ndaloni regjistrimin;
- fundi i regjistrimit.
Pas përfundimit të regjistrimit, një dokument teksti hapet në ekran, i cili është një sekuencë e veprimeve të përdoruesit të ruajtura në një skedar XML.
Klikoni mbi imazhin për ta zmadhuar.
Regjistri i regjistruar mund të konvertohet në kodin e programit, i cili më pas mund të përdoret në një skript testues.
Për këtë, synohet përpunimi "Transformimi i regjistrit të veprimeve të përdoruesit" (UILogToScript.epf), i cili mund të merret nga faqja e internetit e ITS.
Klikoni mbi imazhin për ta zmadhuar.
Si rezultat i punës së përpunimit, marrim kodin e gjeneruar në gjuhën e ngulitur. Ky kod duhet të futet në modulin e formularit të përpunimit të testit.
Vini re se në kodin e gjeneruar, numrat më të mëdhenj se 999 ose më pak se –999 do të dalin duke përdorur një hapësirë që nuk thyhet si ndarës i grupit (për shembull, "1 234" në vend të "1234").
Ky simbol duhet të hiqet manualisht nga kodi i marrë.
Seksioni i kodit me lidhjen me klientin u krijua automatikisht nga përpunimi.
Në shembullin tonë, ne morëm kodin e mëposhtëm:
& Klienti
Procedura Drejtoni Testimin(Ekipi)
Skenari i Testit_23_03_2014();
EndProcedure & OnClient
Procedura Skenari i Testit_23_03_2014()
Aplikimi i Testit= E re Aplikimi i testuar();
Koha Përfundim duke pritur= Data aktuale () + 60;
I lidhur = E gabuar;
PërshkrimiErrorsConnections=
“”
;
Deri në CurrentDate ()> = = Koha Përfundim duke pritur Cikli
Përpjekje
TestApplication.InstallConnection();
I lidhur = E vërtetë;
Aborto;
Nje perjashtim
PërshkrimiErrorsConnections= PërshkrimiErrors ();
Fundi i Përpjekjeve;
Fundi i ciklit;
Nëse nuk është i lidhur atëherë
Aplikimi i Testit= E pacaktuar;
Raport ( + Simbolet. PS + PërshkrimiErrorsConnections);
Kthim;
FundIf; ( Aplikimi i Testit);
(Aplikimi i Testit); EndProcedure & OnClient
Procedura WindowApplicationsContractorsButtonCreateClick(Aplikimi i Testit)
WindowApplicationsContractors= (Lloji (
"Dritarja e Aplikimit TestedClient"), "Palët e tjera", 30);
WindowApplicationsContractorsFormContractors=
WindowApplicationsContractors.FindObject(Një lloj (
"Forma e testueshme"), "Palët e kundërta");
Butoni i ri = WindowApplicationsContractorsFormContractors.FindObject(Një lloj (
"TestFormButton"), "Krijo");
Butoni Krijo. Shtyp(); EndProcedure & OnClient
Procedura WindowApplicationsContractorCreateButtonWrite dhe ClosePress(Aplikimi i Testit)
WindowApplicationsContractorCreate=
TestApplication.FindObject(Një lloj (
"Dritarja e Aplikimit TestedClient"),
"Kundërpartia (krijimi)",
,
30
);
WindowApplicationsContractorCreateFormContractorCreate=
WindowApplicationsContractorCreate.FindObject(Një lloj ( "Forma e testueshme"),
"Kundërpartia (krijimi)");
Emri i fushes=
(Një lloj (
"TestedFormField"),
"Emri");
Emri i Fushës.EnterText("I ri" ); Fusha e Shikimit të Çmimeve = WindowApplicationsContractorCreateFormContractorCreate.FindObject(Një lloj (
"TestedFormField"), "Lloji i çmimeve");
FieldViewPrice. Aktivizo();
FieldViewPrice.Zgjidhni();
FieldViewPrice.WaitFormingListList();
FieldPriceViewRunChoiceFromListChoice("Prokurimi"); Regjistro butonin dhe mbylle=
WindowApplicationsContractorCreateFormContractorCreate.FindObject(Një lloj (
"TestFormButton"),
"Regjistro dhe mbylle");
Butoni Regjistro dhe Mbyll.(); Fundi i Procedurës
Në skenarin që rezulton, krijohet një lidhje me klientin e testimit, butoni për krijimin e një artikulli të ri në drejtorinë "Kontraktorët" shtypet, në fushë Emri futet teksti "E re", dhe në listën zbritëse "Lloji i çmimeve" zgjedhim vlerën "Blerje", pastaj shtypet butoni "Regjistro dhe mbyll".
Nëse një skenar duhet të përdorë disa klientë testues, atëherë lidhja me secilin prej tyre dhe veprimet e kryera duhet të përshkruhen veçmas.
Një menaxher testi do të përdoret dhe dy klientë do të lidhen me të në porte të ndryshme.
Meqenëse një skenar testi po përpunohet, linjat e kodit të të cilit ekzekutohen në mënyrë sekuenciale, zhvilluesi duhet të përshkruajë sekuencën e veprimeve për secilin klient.
Le të hedhim një vështrim më të afërt se si do të duket kodi kur përdorni dy klientë testues:
Procedura TestScenario_23_03_2014_TwoClient()
// klienti i parë
Aplikimi i Testit 1= E re Aplikimi i testuar();
Koha Përfundim duke pritur= Data aktuale () + 60;
I lidhur = E gabuar;
PërshkrimiErrorsConnections=
“”
;
Deri në CurrentDate ()> = = Koha Përfundim duke pritur Cikli
Përpjekje
Test Aplikimi 1. InstallConnection();
I lidhur = E vërtetë;
Aborto;
Nje perjashtim
PërshkrimiErrorsConnections= PërshkrimiErrors ();
Fundi i Përpjekjeve;
Fundi i ciklit; // klienti i dytë
Aplikimi i testit2= E re Aplikimi i testuar();
Koha Përfundim duke pritur= Data aktuale () + 60;
PërshkrimiErrorsConnections=
“”
;
Deri në CurrentDate ()> = = Koha Përfundim duke pritur Cikli
Përpjekje
TestApplication2.InstallConnection();
I lidhur = E vërtetë;
Aborto;
Nje perjashtim
PërshkrimiErrorsConnections= PërshkrimiErrors ();
Fundi i Përpjekjeve;
Fundi i ciklit;
Nëse nuk është i lidhur atëherë
Aplikimi i Testit 1= E pacaktuar;
Aplikimi i testit2= E pacaktuar;
Për të raportuar ( "Nuk mund të krijoj një lidhje!"+ Simbolet. PS + PërshkrimiErrorsConnections);
Kthim;
FundIf; // procedurat janë të ndara për secilin klient testimi
WindowApplicationsContractorsButtonCreatePress1(Aplikimi i Testit 1);
WindowApplicationsContractorsButtonCreatePress2(Aplikimi i testit2);
WindowApplicationsContractorCreateButtonWrite and Close Press1(Aplikimi i Testit 1);
WindowApplicationsContractorCreateButton Shkruaj dhe Mbyll Shtypin2(Aplikimi i testit2); Fundi i Procedurës
Pushimet midis veprimeve të kryera gjithashtu duhet të programohen veçmas. Skenari për një numër të madh klientësh bëhet i vështirë për t’u lexuar.
Për më tepër, testimi i automatizuar është i disponueshëm vetëm për format e menaxhuara.
Sidoqoftë, përparësia e testimit të automatizuar është thjeshtësia dhe qartësia e zhvillimit të testit. Meqenëse testi funksionon vetëm me veprime ndërvepruese të përdoruesit, zhvilluesi nuk ka nevojë të njohë strukturat e konfigurimit në nivelin e atributeve të objektit.
Nëse ndryshoni, për shembull, kodin e konfigurimit, nuk ka nevojë të rishkruani testin sepse klienti i testit do të kryejë akoma të njëjtat veprime me të njëjtat kontrolle.
Një mekanizëm i automatizuar i testimit mund të përdoret nga testuesit për të regjistruar sekuencën e veprimeve që çojnë në një gabim. Të dhënat e regjistruara mund t'u dërgohen zhvilluesve për të korrigjuar gabimin e zbuluar.
Testimi i automatizuar mund të përdoret gjithashtu për të identifikuar bllokimet dhe bllokimet e tepërta në konfigurim.
Për ta bërë këtë, duhet të zbatoni një skenar që riprodhon problemin dhe të filloni të gjeni dhe eliminoni shkakun.
Shumë specialistë dhe thjesht përdorues të produkteve të bazuar në 1C Enterprise 8 duhet të kenë dëgjuar tashmë për lëshimin e një produkti të ri softuerik për të testuar çdo konfigurim (sipas deklaratave zyrtare), dhe emri i tij është Testimi i Skenarit 1C 8. Do ta sqaroj menjëherë se ky mjetështë zhvilluar drejtpërdrejt nga 1C, dhe jo nga aktivistë të palëve të treta. Unë nuk mund të gjeja informacion mbi këtë produkt (përveç ribotimeve të pafundme nga faqja 1C), nga të cilat mund të konkludoj se thjesht nuk ekziston. Dhe produkti i rishikimit në vetvete nuk është i lehtë për tu gjetur, të paktën për ata që nuk duan të paguajnë 30k për një licencë ose nuk e kanë tashmë atë, së bashku me furnizimin e KIP8. Në një mënyrë ose në një tjetër, por pas disa sprovave, unë ende arrita të marr duart në këtë instrument. Dhe nga ky moment do të filloj më në detaje.
Instalimi.
Për momentin, unë jam në dijeni për mënyrat e mëposhtme zyrtare për të marrë këtë mjet:
a) Përfshihet në shpërndarjen "1C: Paketa e mjeteve të korporatës 8".
b) Mund ta shkarkoni në faqen e internetit të mbështetjes së përdoruesit 1C.
c) Versioni i hershëm ishte i pranishëm në diskun ITS, duket për tetorin.
Vetë aplikacioni peshon rreth 2 MB, por është shumë herët për t'u gëzuar - për ta instaluar atë, duhet të specifikoni rrugën drejt dosjes me shabllone. Siç e kuptoj, ky drejtori është në konfigurimet bazë, ose në atë testuese, e cila i bashkëngjitet programit. Duhet të instalohet para së gjithash (~ 90Mb), atëherë ne do të instalojmë me siguri programin dhe do të heqim konfigurimin e panevojshëm.
Pas këtyre manipulimeve të thjeshta, ne do të marrim një katalog me instrumentin që na intereson. Vetë programi përbëhet nga dy përpunime të jashtme * .epf, përveç kësaj, bashkëngjitet një përshkrim i shkurtër dhe një test demo për konfigurimin shembullor që kemi hequr.
Unë do të sqaroj me çfarë duhej të punoja. Mora versionin 1.2.2.1, padyshim që nuk është ai kryesor. Si një konfigurim test, unë kam përdorur një konfigurim të bazuar në 1C Enterprise 8.1.
Debrifing.
Pra, siç e përmenda tashmë, testimi i skenarit 1C përbëhet nga dy procese të jashtme: WritingTests dhe RunningTests.
Shumica e informacionit mund të gjendet në ndihmën online. Sidoqoftë, nuk do të kisha lidhur shpresa të mëdha, është shkruar sipas parimit "ne do të përtypim të dukshmen, dhe asgjë tjetër". Por, megjithatë, mund të lexoni për zhvillim të përgjithshëm.
Për të filluar, unë do të përshkruaj me fjalët e mia funksionalitetin kryesor të këtij mjeti, dhe pastaj do të përpiqem të thellohem më thellë në zbatimin e funksioneve individuale.
Me ndihmën e testimit të Skenarit 1C, ju lehtë mund të krijoni dokumente, libra referimi, regjistra sipas një skenari të para-shkruar në mënyrë automatike, t'i krahasoni ato me objektet e referencës, etj., Si në mënyrë vizuale ashtu edhe të fshehura nga sytë e testues Një shembull i një skenari tipik mund të shihet në pamjen e parë të ekranit.
Çdo pikë në skenar quhet hap. Në përgjithësi, gjithçka është e qartë dhe e thjeshtë në shikim të parë, dhe, mjerisht, deri diku mashtruese. Sidoqoftë, ne do të flasim për kurthet në pjesën tjetër, por tani për tani le të ndalemi në veçoritë themelore.
Oriz. 1 Përpunimi i Testeve të Regjistrimit.
Ideologjia e këtij mjeti bazohet në krahasimin e objekteve të bazës së referencës me objektet në bazën e testuar. Kjo mund të shihet qartë në dritaren kryesore për përpunimin e Regjistrimeve të Testit, në anën e majtë janë të dhëna nga baza e të dhënave referuese, në të djathtë janë teste të bazuara në të dhënat nga ana e majtë. Baza e referencës është baza në të cilën krijohet testi.
Përveç funksionit kryesor të mjetit, të përshkruar më sipër, ka një numër të tjerëve, më primitivë, por ndonjëherë jo më pak të dobishëm. Për shembull, mjeti mund të përdoret vetëm për plotësimin automatik të formave, butonat e klikimit, plotësimin e seksioneve tabelare, dhe kështu me radhë, këto hapa simulojnë ndërveprimin e përdoruesit në mënyrë interaktive. Dhe meqenëse roli i përdoruesit luhet nga testuesi, rezulton një lloj testimi ad hoc në modalitetin automatik.
Ekziston një model i hapave tipikë që gjenerohen automatikisht në varësi të objektit nën provë. Këtu është një shembull tipik: në anën e majtë, zgjidhni një dokument specifik (libër reference, etj.) Dhe tërhiqeni atë në anën e djathtë, pas së cilës ne krijojmë automatikisht një model të hapave tipikë. Pas kësaj, ju mund t'i ndryshoni ato sipas dëshirës tuaj.
Çdo hap mund të kryhet drejtpërdrejt në këtë përpunim duke shtypur F12. Ky funksionalitet hedh dyshime mbi nevojën për përpunimin e dytë të RunTests, mendoj se në të ardhmen do të ishte logjike kombinimi i tyre.
Oriz. 2 Përpunimi i Testeve Run.
Testi i përfunduar shkruhet në një dokument xml, të cilin e hapim në bazën e të dhënave të testuar përmes përpunimit të RunTests dhe vëzhgojmë sesi gjithçka është kryer në mënyrë perfekte për ne.
Funksionaliteti i trajtimit të dytë nuk është i ndryshëm, duke pasur parasysh që vrapimi mund të bëhet edhe me trajtimin e parë. Nga karakteristikat e dobishme, është e mundur të theksohet mirëmbajtja e një protokolli të ekzekutimit dhe shënimi i hapave të kryer.
Duke parë përpara, në mënyrë që të mos kthehem në këtë trajtim, do të them që u hodha në erë në vend. Me gjithë larminë e opsioneve të nevojshme dhe jo aq shumë, nuk kishte vend për modalitetin e testimit me injorimin e gabimeve. Kjo e bën jashtëzakonisht të pakëndshme kryerjen e testeve negative, dhe testimeve në përgjithësi. Në mospërputhjen më të vogël, përpunimi ynë "automatik" futet në një marrëzi.
Tani le të shohim të mirat dhe të këqijat e përdorimit të këtij sistemi kushtet e terrenit.
Karakteristikat e përdorimit.
Sipas deklaratave zyrtare, testimi i skenarit 1C duhet të jetë një mjet universal për sa i përket përputhshmërisë me konfigurime të ndryshme. Unë mendoj se konfigurimi im është një pikë referimi e shkëlqyeshme për të testuar këtë deklaratë.
Unë do të them menjëherë se procesi i punës me këtë mjet nuk mund të quhet i thjeshtë dhe i qetë. Pothuajse në çdo hap (në çdo kuptim) duhet të eksperimentosh me gjëra në dukje të dukshme.
Këtu janë disa nga gjërat me të cilat duhej të përballesha:
- Për disa arsye, me gjithë larminë e opsioneve për hapat e testimit, nuk ka asnjë hap për të fshirë objektin e përpunuar. Në ditët e para, ju duhej të përdorni hapin Procesi dhe të shkruani manualisht kodin për të fshirë objektet. Në fund, vendosa të bëj pa të tani për tani dhe të punoj me të dhënat ekzistuese.
- Një nga më të dobishmit, sipas mendimit tim, është hapi "Krahasimi i lëvizjes me një referencë". Kjo është ajo që mungonte. Tani është e mundur të gjurmoni të gjitha ndryshimet në transaksionet që nuk ishin planifikuar.
Ky hap ka nevojë për rregullim shumë të mirë. Për shembull, ne duhet të ndjekim lëvizjen e një dokumenti në katër regjistra, dhe secili prej tyre ka grupin dhe dimensionet e veta. Ka vlera që do të ndryshojnë kur objekti ndryshon, dhe ky nuk do të jetë një gabim. Për shembull, një fushë si TimeStamp, e cila regjistron kohën e dokumentit, ose numrin e dokumentit, nëse caktohet automatikisht. Të gjitha momentet e tilla do të shkaktojnë një gabim gjatë ekzekutimit të testit. Goodshtë mirë që zhvilluesit e kanë parashikuar këtë dhe kanë bërë të mundur çaktivizimin e kontrollit për një fushë jo konstante. Ne vetëm duhet të gjejmë fusha të tilla.
Sidoqoftë, edhe këtu kishte disa kurthe. Për shembull, për ndonjë arsye, në formën e vendosjes së një hapi, nëse shfaqen më shumë se një regjistër, atëherë lëvizjet përgjatë tyre nuk shfaqen, ju duhet të fikni ato të panevojshme dhe të konfiguroni secilin regjistër personalisht.
Dhe se me të vërtetë nuk më pëlqeu fare. Siç arrita të kuptoj, vetëm ato lëvizje që janë në standard kontrollohen nga regjistrat. Për shembull, nëse ka një postim në standard, dhe në bazën e testuar janë tre, atëherë NUK do të ketë gabime në krahasim. Sepse i gjithë regjistri kërkohet për një postim me parametrat e referencës, nëse gjithçka është në rregull, atëherë prania në regjistrin e të tjerëve që lidhen me të njëjtin objekt nuk gjurmohet. - Hapat e mbushjes automatike të bazuar në skenarë nuk funksionojnë gjithmonë si duhet. Gabimet shpesh ndodhin në fushat dhe datat referuese. Me shumë mundësi, ky nuk është një gabim i mjetit, por një veçori e fushave, por megjithatë ju duhet të ngatërroni cilësimet e tyre.
- Hapat e mundshëm shoqërohen me objekte specifike të konfigurimit. Ajo që është në dispozicion për drejtoritë mund të mos jetë e disponueshme për regjistrat, etj. Do të ishte më e saktë të thuhet se lidhja ka më shumë të ngjarë jo për objektet, por për veçoritë e tyre, për shembull, nëse regjistri nuk ka një formë, atëherë nuk do të ketë asnjë hap për ta plotësuar atë.
Por ka edhe defekte, për shembull, hapi "Shtyp butonin" është shpesh i padisponueshëm për mua, më saktësisht, zgjedhja mund të bëhet, vetëm asgjë nuk do të ndodhë. - Mbeten vetëm shumë pyetje në lidhje me automatizimin e testit në disa raste veçanërisht konfuze. Kjo është veçanërisht e vërtetë për dokumentet që kanë të bëjnë me mbetjet, ku pothuajse të gjitha aspektet luajnë një rol të rëndësishëm, disa prej të cilave janë shumë problematike për tu mposhtur në zbatimin aktual të mjetit. Ekzistojnë një numër kufizimesh në konfigurim për krijimin e dokumenteve në një datë, me një numër, etj. deri më tani jam vendosur të përdor objekte ekzistuese pa krijuar objekte të reja.
Lista vazhdon dhe vazhdon, por le ta bëjnë testuesit e këtij produkti. Gjëja kryesore që kuptova dhe po përpiqem të përcjell është se "nuk do të ketë pagesë falas". Për të zbatuar automatizimin e testit me këtë produkt në rolin kryesor, do t'ju duhet të djersiteni për më shumë se një ditë. Sigurisht, analiza ime është thjesht subjektive, mungesa e përvojës në përdorimin e produktit dhe veçoritë e konfigurimit gjithashtu mund të ndikojnë, por, siç thonë ata, ne kemi atë që kemi, dhe nuk ka largim prej saj.
Opsionet e aplikimit.
Për veten time, për momentin, unë kam zgjedhur konceptin e mëposhtëm për futjen e mjetit në fjalë në procesin e testimit.
Bazuar në përvojën aktuale të funksionimit, jam i bindur se baza e referencës dhe baza e provës duhet të jenë identike për sa i përket të dhënave. Natyrisht, kur po flasim për skenarë që përdorin objekte ekzistuese pa i ndryshuar ato, në vend që të krijojnë të reja. Së pari, do të na japë të njëjtat balanca në të dy bazat, dhe kjo është shumë e rëndësishme për testimin e qarkullimeve. Së dyti, do të japë një shkallë të caktuar besueshmërie dhe një lloj mbrojtjeje kundër gabimeve të panevojshme. Ende nuk e kuptoj plotësisht lidhjen e të dhënave të referencës me bazat e të dhënave, lidhjet e ndryshme, etj., Më mundojnë dyshimet e paqarta se mund të ketë një lloj lidhjeje që një ditë do të kthehet në një ngatërresë lidhjesh të vdekura që nuk mund të jenë zbërthyer
Pra, ne kemi një bazë referimi, sipas së cilës ne kemi bërë vetë skripte për të gjitha rastet. Një dokument në konfigurimin e zhvillimit përmban rregullime që duhet të testohen. Si rregull - me dorë. Pas kësaj, konfigurimi me ndryshimet ngarkohet në bazën e të dhënave të testit dhe skriptet ekzekutohen për të gjitha ose vetëm objektet ngjitur, në mënyrë që të zbulohet nëse ndryshimi në dokument kishte ndikim në pjesën tjetër të objekteve. Pas kësaj, konfigurimi konsiderohet i zbatueshëm dhe i instaluar në bazën e prodhimit. Pas kësaj, skenari për testimin e dokumentit të modifikuar ndryshohet në një standard të ri nga baza e punës.
Me fjalë të tjera, me këto skenarë ne po kryejmë testimin e regresionit. Dhe kjo është një nga llojet më të rëndësishme dhe më të vështira për t'u zbatuar me dorë të testimit në 1C Enterprise. Në fund të fundit, shumë shpesh jo vetëm që dokumenti ndryshon, por, të themi, funksioni i postimit të dokumentit, i cili shoqërohet me të gjitha dokumentet në sistem, këtu skriptet tona do të luajnë rolin e një rrjeti në të cilin të gjitha dokumentet që kanë e dështuar do të bjerë.
Një përdorim tjetër i mirë është kontrollimi i bazës së të dhënave të prodhimit për defekte të rastësishme. Për ta bërë këtë, një kopje rezervë hiqet prej tij, ngarkohet në një bazë të dhënash testimi dhe kryhet një cikël i plotë i testeve. Do të ishte mirë ta kryeni këtë procedurë në mënyrë automatike, por testimi i Skenarit 1C nuk parashikon kryerjen e testeve në një orar, të paktën jo akoma.
Kjo, natyrisht, nuk përfundon fushën e aplikimit të këtij mjeti, opsionet e mundshme shumë, solla vetëm të parën që më erdhi në mendje.
Përfundim.
Ky instrument padyshim që ka të ardhme. Më duket se shumica e potencialit të tij ende nuk është zbuluar në versionet e mëvonshme, dhe, pa dyshim, produkti do të gjejë përdoruesin e tij, i cili, për mendimin tim, i cili, me sa duket, nuk përkon me mendimin e prodhuesit, do përkundrazi mos u bëni një përdorues i zakonshëm pa njohuri specifike në fushën e IT, dhe një person nga departamenti i zhvillimit. Sepse përdorimi i këtij mjeti në mënyrë efektive nuk është një detyrë e lehtë, veçanërisht në konfigurime komplekse.
Ekziston një përpunim i veçantë për zhvillimin dhe korrigjimin e një skripti në ST. Përpunimi mund të shkarkohet nga CT me komandën në seksionin Administrata - "Ruaj përpunimin në skedar".
Për të zhvilluar një skenar të ri, zgjidhni "Lidhu me aplikacionin nën provë dhe krijo një skenar të ri".
Për të regjistruar dhe korrigjuar skriptet, duhet të drejtoni dy sesione të bazës: "Test Manager" (në tekstin e mëtejmë MT) dhe "Test Client" (në tekstin e mëtejmë CT).
MT kontrollon CT, regjistron veprimet e përdoruesit dhe ju lejon të modifikoni skriptin. CT është e nevojshme për të riprodhuar vetë skriptin dhe për të ekzekutuar veprimet e përdoruesit.
Kur filloni CT, duhet të specifikoni parametrat e nisjes (lloji i lidhjes 1C, përdoruesi, etj.):
Pasi të ketë filluar CT, mund të filloni të regjistroni veprimet e përdoruesit. Për ta bërë këtë, ndizni regjistrimin në MT në përpunim.
Ju mund të riprodhoni veprimet në CT.
Pas përfundimit të veprimeve në CT, ne shtypim regjistrimin e ndaluar në MT:
Me komandën "Regjistro dhe Mbyll" veprimet e regjistruara transferohen në skenar:
Përfundimi: Konfigurimi "Testimi i skenarit 3.0", me qasjen e saktë dhe të aftë, ju lejon të regjistroni shpejt dhe me efikasitet veprimet ndërvepruese të përdoruesit, është mjaft e thjeshtë të modifikoni dhe korrigjoni skriptet. Zhvillimi i hapave të shkrimit interaktiv nuk kërkon kualifikimet e një programuesi. Mjafton të dini dhe të kuptoni se si të përdorni një zgjidhje të gatshme.
P.S .: bettershtë më mirë të mos ekzekutosh skriptet nën ndërfaqen "Taxi", pasi ndonjëherë skenari nuk funksionon si duhet.
