"1C: Scenārija pārbaude. Testēšanas rīki tiem, kam nepatīk tērēt laiku rutīnai Kā tas izskatās

Rakstā ir apskatīts jauns automatizētās testēšanas mehānisms, kas pirmo reizi parādījās platformā 8.3 versijā. Izpētot rakstu, jūs uzzināsit:

• Kas ir automatizētā testēšana platformā?
• Kā un kad to lietot?
• Kas un kur ir jākonfigurē, lai to palaistu?
• Kā uzrakstīt automatizētu testa skriptu?

Piemērojamība

Rakstā ir apskatīta 1C: Enterprise platformas versija 8.3.4.465. Pašreizējā platformas versijā automātiskās testēšanas mehānisma iespējas ir ievērojami paplašinātas, taču tas neietekmēja raksta atbilstību. Tas joprojām ir aktuāls.

Automatizētā testēšana 1C:Enterprise 8.3

1C:Enterprise 8.3 platformai ir jauns mehānisms, kas paredzēts sistēmas lietotāju interaktīvo darbību simulēšanai - automatizēta testēšana.

Automatizētā testēšana neatbalsta darbu ar parastu saskarni, bet tikai ar pārvaldītu.

Testējot tiek izmantotas divu veidu klientu aplikācijas – testa pārvaldnieks un testa klients. Testa vadītājs sazinās ar testa klientu un izpilda testa skriptu.

Testa skripts ir kods iegultā valodā, kas apraksta veicamo interaktīvo darbību secību.

Šim nolūkam iebūvētajai valodai ir pievienoti jauni objekti, kas abstraktā līmenī apraksta lietojumprogrammas saskarni (loga, formas, vadīklu utt. izteiksmē), kā arī apraksta lietotāja darbības (navigācija pa konfigurāciju). , datu ievade utt.) .

Testa vadītājs var būt biezs vai plāns klients. Testēšanas klients – biezais, plāns klients vai tīmekļa klients.

Testa pārvaldnieku var savienot ar vairākiem testa klientiem, bet testa klientu var savienot tikai ar vienu pārvaldnieku.

Lai pārvaldītu klientu, pārvaldnieks izveido ar to TCP savienojumu. Ir svarīgi, lai automatizētā testēšana neprasa izmaiņas konfigurācijas struktūrā.

Būtībā klients un testa pārvaldnieks ir konfigurācijas, kas tiek darbinātas ar noteiktiem komandrindas parametriem, un pārvaldnieks pārvalda klientus, “liekot” logiem un vadīklām darboties tā, it kā lietotājs ar tiem mijiedarbotos.

Automātiskajai testēšanai ir savi ierobežojumi. Piemēram, darbs ar parasto saskarni netiek atbalstīts, bet tikai ar pārvaldītu.

Lai veiktu automatizētu testēšanu, ir jādarbojas testa pārvaldniekam un testa klientam.

Pārvaldnieku var palaist no komandrindas ar taustiņu /TESTMANAGER:

“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” UZŅĒMUMS /F “X:\test” /N Administrators /TESTMANAGER

Varat arī palaist testēšanas pārvaldnieku no konfiguratora.

Lai to izdarītu, izvēlnē Rīki — opcijas atveriet dialoglodziņu “Opcijas”, kurā cilnē Launch 1C:Enterprise — Advanced atlasiet vienumu “Palaist kā testēšanas pārvaldnieku”:

Vēl viens veids, kā palaist testa pārvaldnieku, ir no iebūvētās valodas, izmantojot StartSystem() metodi, kurā jānorāda komandrinda:

RunSystem (“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” UZŅĒMUMS /F X:\test /N Administrators /TESTMANAGER)

Testēšanas klientu var palaist arī no komandrindas. Lai to izdarītu, izmantojiet komandrindas opciju slēdzi /TESTCLIENT.

Izmantojot parametru TPort, jūs norādāt porta numuru, caur kuru sadarbosies pārvaldnieks un testēšanas klients. Ja šis parametrs komandrindā nav norādīts, tiks izmantots ports 1538.

“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” UZŅĒMUMS /F “X:\Platform8Demo” /N Administrators /TESTCLIENT -TPort 1539

Testēšanas klientu var palaist no konfiguratora. Lai to izdarītu, izvēlnē Rīki — Opcijas atveriet dialoglodziņu “Opcijas”, kurā cilnē Launch 1C:Enterprise — Advanced atzīmējiet vienumu “Palaist kā pārbaudes klientam”. Šajā gadījumā jums būs jānorāda izmantotā porta numurs.

Lūdzu, ņemiet vērā, ka, lai izveidotu savienojumu ar testēšanas klientu, jums jāzina divi parametri: tā datora IP adrese (vai nosaukums), kurā darbojas testēšanas klients, un TCP porta numurs, caur kuru tiks veikta mijiedarbība.

Abas dažādas informācijas bāzes var izmantot kā testēšanas pārvaldnieku un testēšanas klientu (testēšanas pārvaldnieka datu bāzes konfigurācija var nesakrist ar testēšanas klienta konfigurāciju), vai vienu un to pašu informācijas bāzi.

Lai veiktu automātisko testēšanu, jums jāveic šādas darbības:

1. Izstrādāt testēšanas skriptu – uzrakstiet ārēju vai iebūvētu apstrādi, kurā secīgi tiks aprakstītas veicamās darbības.
2. Palaidiet Test Manager.
3. Palaidiet testēšanas klientu (vienu vai vairākus).
4. Testēšanas pārvaldniekā palaidiet izveidoto apstrādi un pārliecinieties, vai klientam tiek veiktas ieprogrammētās darbības.

Pārbaudāmā lietojumprogramma ir aprakstīta ar iebūvētu valodas objektu kopu, kas tiek izmantota skripta rakstīšanai:

• Pārbaudīta lietojumprogramma;
• ClientApplicationWindow tiek testēts;
• TestedWindowCommandInterface;
• TestGroupCommandInterface;
• TestCommandInterfaceButton;
• Testa veidlapa;
• TestFormField;
• TestFormGroup;
• TestFormButton;
• TestFormTable;
• TestedDecorationForm.

Mēs izmantosim “Pārvaldītās lietojumprogrammas” demonstrācijas konfigurāciju kā pārbaudāmo konfigurāciju.

Izveidosim ārējo apstrādi, pievienosim jaunu formu, kurā definēsim apdarinātāju jaunajai komandai “RunTesting”.

Pārbaudē veicam sekojošas darbības: izveidojam jaunu direktorijas elementu “Noliktavas”, laukā Nosaukums ierakstam rindiņu “Noliktavas tests”, pēc tam spiežam pogu “Ierakstīt un aizvērt”.

Šī testa kods izskatīsies šādi:

&OnClient
Procedūra RunTesting(Komanda)
// Izveidojiet savienojumu ar testējamo lietojumprogrammu
Pieteikums testā= Jauns Pieteikums testā(“localhost”);
// Mēs cenšamies izveidot savienojumu ne ilgāk kā vienu minūti
Beigu laiks, gaidīšana= PašreizējaisDatums () + 60 ;
Savienots = False ;
Vēl nav CurrentDate() >= Beigu laiks, gaidīšana Cikla mēģinājums
Pieteikums tiek testēts.EstablishConnection();
Savienots = True ;
Pārtraukt ;
Izņēmums
EndAttempt ; EndCycle ; Ja nav izveidots savienojums, tad
// Pabeidziet testu
Pieteikums testā= Nedefinēts ;
Ziņot ( "Savienojums neizdevās!");
Atgriezties ;
EndIf ;
// Atrodiet galveno logu
MainWindowTested
= (Tips());
MainWindowTested.Activate();
// Izpildiet komandu, lai izveidotu produktu direktorijas vienumu
Testa subjekta galvenais logs. Izpildīt komandu(“e1cib/command/Directory.Warehouses.Create”);
Pieteikums sadaļā Test.ExpectDisplayObject(Ierakstiet ( "Pārbaudes forma"), "Krājumi*");
Testa veidlapa= Pieteikums sadaļā Test.FindObject(Ierakstiet ( "Pārbaudes forma"),
"Krājumi*");
TestForm.Activate();
// Iestatiet jaunā produkta nosaukumu
FormElement = TestForm.FindObject(Ierakstiet ( “FormField tiek pārbaudīts”),
"Vārds");
Veidlapas elements. Aktivizēt();
Form Element.EnterText(“Noliktavas pārbaude”);
// Uzrakstiet elementu
FormElement = TestForm.FindObject(Ierakstiet ( “FormButton tiek pārbaudīts”),
“Ierakstīt un aizvērt”);
Veidlapas elements. Noklikšķiniet();
Procedūras beigas

Palaišanas opciju dialoglodziņā vispirms tika atlasīta vērtība “Palaist kā testa pārvaldnieku”, un lietotāja sesija tika palaista, izmantojot taustiņu kombināciju Ctrl+F5.

Pēc tam dialoglodziņā tika atlasīta vērtība “Run as testing client”, izmantojot taustiņu kombināciju Ctrl+F5, tika palaista otrā lietotāja sesija.

Tādā veidā mēs izvairījāmies no nepieciešamības manuāli norādīt nepieciešamos komandrindas parametrus.

Iepriekš minētais kods veic diezgan vienkāršu darbu, taču, scenārijam kļūstot sarežģītākam, koda lielums palielināsies, jo ir jāapraksta katra lietotāja mijiedarbība.

Šeit talkā nāk vēl viena platformas jauna iespēja – lietotāja darbību žurnāla ierakstīšana.

Lai to izdarītu, lietojumprogramma jāpalaiž īpašā režīmā:

Lai palielinātu, noklikšķiniet uz attēla.

Programmas galvenē parādās vairākas pogas:

Pogas ir paredzētas:

• sākt/pauzēt ierakstīšanu;
• ierakstīšanas pārtraukšana;
• ieraksta pabeigšana.

Kad ierakstīšana ir pabeigta, ekrānā tiek atvērts teksta dokuments, kas ir lietotāja darbību secība, kas saglabāta XML failā.

Lai palielinātu, noklikšķiniet uz attēla.

Ierakstīto žurnālu var pārvērst programmas kodā, ko pēc tam var izmantot testa skriptā.

Šim nolūkam ir paredzēta “User Action Log Conversion” (UILogToScript.epf) apstrāde, kuru var iegūt ITS vietnē.

Lai palielinātu, noklikšķiniet uz attēla.

Apstrādes darba rezultātā mēs saņemam ģenerētu kodu iebūvētajā valodā. Šis kods ir jāielīmē testa apstrādes veidlapas modulī.

Ņemiet vērā, ka ģenerētajā kodā skaitļi, kas ir lielāki par 999 vai mazāki par -999, tiks izvadīti, kā grupas atdalītāju izmantojot nepārkāpjošu atstarpi (piemēram, "1234", nevis "1234").

Šī rakstzīme no saņemtā koda ir jānoņem manuāli.

Apstrādājot automātiski tika ģenerēta koda sadaļa ar savienojumu ar klientu.

Mūsu piemērā mēs saņēmām šādu kodu:

&OnClient
Procedūra RunTesting(Komanda)
Testa scenārijs_23_03_2014();
Procedūras beigas &Klientā
Procedūra Testa scenārijs_23_03_2014() Testa lietojumprogramma= Jauns Pieteikums testā();
Beigu laiks, gaidīšana= PašreizējaisDatums () + 60 ;
Savienots = False ;
AprakstsErrorsConnections= “” ;
Vēl nav CurrentDate() >= Beigu laiks, gaidīšana Cikls
Mēģinājums
Test Application.SetConnection();
Savienots = True ;
Pārtraukt ;
Izņēmums
AprakstsErrorsConnections= ErrorDescription();
EndAttempt ;
EndCycle ;
Ja nav izveidots savienojums, tad
Testa lietojumprogramma= Nedefinēts ;
Ziņojums (+ Symbols.PS + AprakstsErrorsConnections);
Atgriezties ;
EndIf ; ( Testa lietojumprogramma);
(Testa lietojumprogramma); Procedūras beigas &Klientā
Procedūra WindowApplicationsDarbpusesButtonIzveidotNospiediet(Testa lietojumprogramma)
WindowApplicationsDarbpuses= (Veids (
“Klienta lietojumprogrammas logs tiek pārbaudīts”), “Darījumu partneri” , , 30 );
WindowApplicationsContractorsFormContractors= Logu lietojumprogrammu darbuzņēmēji. Atrodiet objektu(Ierakstiet (
"Pārbaudes forma"), “Darījumu partneri”);
PogaIzveidot = Logu lietojumprogrammas Contractors For Contractors. Find Object(Ierakstiet (
“FormButton tiek pārbaudīts”), "Izveidot");
PogaIzveidot. Noklikšķiniet(); Procedūras beigas &Klientā
Procedūra WindowApplicationsDarījuma puseIzveidotButtonIerakstītUnAizvērtNospiediet(Testa lietojumprogramma) WindowApplicationsDarbpuses izveide= TestApplication.FindObject(Ierakstiet (
“Klienta lietojumprogrammas logs tiek pārbaudīts”), “Darījuma partneris (izveide)”, , 30 );
WindowApplicationsAccountCreationFormAccountCreation=
Logu lietojumprogrammas CounterpartyCreation.FindObject(Ierakstiet ( "Pārbaudes forma"),
“Darījuma partneris (izveide)”);
Lauka nosaukums=
(Ierakstiet (
“FormField tiek pārbaudīts”), "Vārds");
FieldName.EnterText("Jauns"); FieldViewPrice = WindowApplicationsAccountCreationFormAccountCreation.FindObject(Ierakstiet (
“FormField tiek pārbaudīts”), “Cenu veids”);
FieldTypePrice.Activate(); FieldTypePrice.Select(); FieldTypePrice.ExpectFormationDropdownList(); FieldTypePrice.ExecuteSelectionFromSelectionList(“Pirkšana”); PogaIerakstītAizvērt=
WindowApplicationsAccountCreationFormAccountCreation.FindObject(Ierakstiet (
“FormButton tiek pārbaudīts”), “Ierakstīt un aizvērt”);
PogaIerakstīt.Nospiediet(); Procedūras beigas

Iegūtajā skriptā tiek izveidots savienojums ar testēšanas klientu, laukā tiek nospiesta poga, lai izveidotu jaunu direktorijas vienumu “Darījumu partneri”. Vārds Ievadiet tekstu “Jauns” un nolaižamajā sarakstā “Cenas veids” atlasiet vērtību “Pirkšana”, pēc tam noklikšķiniet uz pogas “Ierakstīt un aizvērt”.

Ja scenārijs prasa izmantot vairākus testēšanas klientus, tad pieslēgšana katram no tiem un veiktās darbības jāapraksta atsevišķi.

Tiks izmantots viens testa pārvaldnieks, un tam tiks pievienoti divi klienti dažādos portos.

Tā kā testa skripts ir apstrāde, kuras koda rindas tiek izpildītas secīgi, izstrādātājam ir jāapraksta darbību secība katram klientam.

Sīkāk apskatīsim, kā kods izskatīsies, izmantojot divus testēšanas klientus:

Procedūra Testa scenārijs_23_03_2014_Divi klienti() //pirmais klients
Testa pieteikums1= Jauns Pieteikums testā();
Beigu laiks, gaidīšana= PašreizējaisDatums () + 60 ;
Savienots = False ;
AprakstsErrorsConnections= “” ;
Vēl nav CurrentDate() >= Beigu laiks, gaidīšana Cikls
Mēģinājums
Testa lietojumprogramma 1. Izveidojiet savienojumu();
Savienots = True ;
Pārtraukt ;
Izņēmums
AprakstsErrorsConnections= ErrorDescription();
EndAttempt ;
EndCycle ; //otrais klients
Testa pieteikums2= Jauns Pieteikums testā();
Beigu laiks, gaidīšana= PašreizējaisDatums () + 60 ;
AprakstsErrorsConnections= “” ;
Vēl nav CurrentDate() >= Beigu laiks, gaidīšana Cikls
Mēģinājums
Testa lietojumprogramma 2. Izveidojiet savienojumu();
Savienots = True ;
Pārtraukt ;
Izņēmums
AprakstsErrorsConnections= ErrorDescription();
EndAttempt ;
EndCycle ;
Ja nav izveidots savienojums, tad
Testa pieteikums1= Nedefinēts ;
Testa pieteikums2= Nedefinēts ;
Ziņot ( "Mēs nevarējām izveidot savienojumu!"+ Simboli.PS + AprakstsErrorsConnections);
Atgriezties ;
EndIf ; //atsevišķas procedūras katram testēšanas klientam
WindowApplicationsDarbpusesButtonCreatePress1(Testa pieteikums1);
WindowApplicationsDarbpusesButtonCreatePress2(Testa pieteikums2);
WindowApplicationsDarījuma puseIzveidotButtonIerakstītUnAizvērtNospiediet1(Testa pieteikums1);
WindowApplicationsDarījuma puseIzveidotButtonIerakstītUnAizvērtNospiediet2(Testa pieteikums2); Procedūras beigas

Arī pauzes starp veiktajām darbībām ir jāieprogrammē atsevišķi. Skripts lielam skaitam klientu kļūst grūti lasāms.

Turklāt automatizētā testēšana ir pieejama tikai pārvaldītajām veidlapām.

Tomēr automatizētās testēšanas priekšrocība ir testa izstrādes vienkāršība un skaidrība. Tā kā tests darbojas tikai ar interaktīvām lietotāja darbībām, izstrādātājam nav jāzina konfigurācijas struktūras objekta detaļu līmenī.

Ja maināt, piemēram, konfigurācijas kodu, tests nav jāatkārto, jo testa klientā joprojām tiks veiktas tās pašas darbības ar tām pašām vadīklām.

Testētāji var izmantot automatizētu testēšanas mehānismu, lai reģistrētu darbību secību, kas izraisa kļūdu. Ierakstītos datus var nosūtīt izstrādātājiem, lai tie labotu konstatēto kļūdu.

Automātisko testēšanu var izmantot arī, lai konfigurācijā identificētu liekas slēdzenes un strupceļus.

Lai to izdarītu, jums ir jāievieš skripts, kas atkārto problēmu, un jāsāk atrast un novērst cēloni.

Daudziem speciālistiem un vienkārši uz 1C Enterprise 8 balstītu produktu lietotājiem jau vajadzētu dzirdēt par jauna programmatūras produkta izlaišanu jebkuras (saskaņā ar oficiālajiem paziņojumiem) konfigurāciju testēšanai, un tā nosaukums ir 1C Scenario Testing 8. Ļaujiet man nekavējoties precizēt, ka šis rīku izstrādā tieši uzņēmums 1C, nevis trešo pušu aktīvisti. Es nevarēju atrast informāciju par šo produktu (ja neskaita nebeidzamos atkārtotos izdrukas no 1C vietnes), no kuras es varu secināt, ka tas vienkārši neeksistē. Un pats apskates produkts nav viegli atrodams, vismaz tiem, kas nevēlas maksāt 30k par licenci vai arī viņiem vēl nav kopā ar instrumentu piegādi8. Tā vai citādi, pēc dažiem pārbaudījumiem man izdevās dabūt šo instrumentu rokās. Un no šī brīža es sākšu sīkāk.

Uzstādīšana.

Šobrīd es zinu šādus oficiālus veidus, kā iegūt šo rīku:

a) Tas ir iekļauts "1C: Corporate Toolkit 8" piegādē.

b) Var lejupielādēt no 1C lietotāju atbalsta vietnes.

c) ITS diskā bija agrīna versija, šķiet, no oktobra.

Pati lietojumprogramma sver aptuveni 2 MB, taču vēl ir pāragri priecāties - lai to instalētu, jums ir jānorāda ceļš uz mapi ar veidnēm. Kā es saprotu, šis direktorijs ir pieejams pamata konfigurācijās vai testa konfigurācijā, kas ir iekļauta programmā. Vispirms jāinstalē (~90MB), tad droši instalējam utilītu un izdzēšam nevajadzīgāko konfigurāciju.

Pēc šīm vienkāršajām manipulācijām mēs saņemsim katalogu ar mūs interesējošo rīku. Pati programma sastāv no divām ārējām *.epf apstrādes, papildus ir pievienots īss apraksts un demonstrācijas tests indikatīvai konfigurācijai, kuru mēs noņēmām.

Ļaujiet man precizēt, ar ko man bija jāstrādā. Es ieguvu versiju 1.2.2.1, acīmredzot ne primāro. Kā testa konfigurāciju es izmantoju konfigurāciju, kuras pamatā ir 1C Enterprise 8.1.

Apspriešana.

Tātad, kā jau minēju, 1C Scenario testēšana sastāv no divām ārējām apstrādēm: RecordTests un RunTests.

Lielāko daļu informācijas var atrast iebūvētajā palīdzībā. Tomēr es uz to neliktu lielas cerības, tas tika uzrakstīts pēc principa "izpakosim acīmredzamo un neko citu". Bet, neskatoties uz to, jūs varat to izlasīt vispārējai attīstībai.

Sākumā es saviem vārdiem aprakstīšu šī rīka galveno funkcionalitāti, un tad mēģināšu iedziļināties atsevišķu funkciju īstenošanā.

Izmantojot 1C Scenario Testing, jūs varat viegli automātiski izveidot dokumentus, direktorijus, reģistrus pēc iepriekš uzrakstīta skripta, salīdzināt tos ar atsauces objektiem utt., gan vizuālā režīmā, gan paslēptu no testētāja acīm. Tipiska scenārija piemēru var redzēt pirmajā ekrānuzņēmumā.

Katrs skripta punkts tiek saukts par soli. Kopumā no pirmā acu uzmetiena viss ir acīmredzams un vienkāršs un, diemžēl, zināmā mērā mānīgs. Taču par slazdiem runāsim nākamajā sadaļā, bet pagaidām koncentrēsimies uz pamata iespējām.

Rīsi. 1 Ierakstu testu apstrāde.

Šī rīka ideoloģija ir balstīta uz objektu salīdzināšanu atsauces datubāzē ar objektiem pārbaudītajā datu bāzē. Tas ir skaidri redzams galvenajā RecordTests apstrādes logā, kreisajā pusē ir dati no atsauces datu bāzes, labajā pusē ir testi, kuru pamatā ir dati no kreisās puses. Atsauces datu bāze ir tā, kurā tika izveidots tests.

Papildus iepriekš aprakstītajai rīka galvenajai funkcijai ir vairākas citas, primitīvākas, bet dažreiz ne mazāk noderīgas. Piemēram, rīku var izmantot tikai, lai automātiski aizpildītu veidlapas, noklikšķinātu uz pogām, aizpildītu tabulas daļas un tamlīdzīgi; šīs darbības simulē lietotāja darbu interaktīvā režīmā. Un tā kā lietotāja lomu pilda testētājs, tā izrādās sava veida ad hoc testēšana automātiskajā režīmā.

Pastāv tipisku darbību shēma, kas tiek ģenerēta automātiski atkarībā no pārbaudāmā objekta. Šeit ir tipisks piemērs: kreisajā pusē atlasiet konkrētu dokumentu (direktoriju utt.) un velciet to uz labo pusi, pēc tam automātiski tiek izveidota tipisku darbību veidne. Pēc tam varat tos rediģēt, kā vēlaties.

Katru darbību var veikt tieši šajā apstrādē, nospiežot taustiņu F12. Šī funkcionalitāte liek apšaubīt nepieciešamību pēc otrās RunTests apstrādes; es domāju, ka būtu loģiski nākotnē tos apvienot.

Rīsi. 2 RunTestu apstrāde.

Gatavs tests tiek ierakstīts xml dokumentā, kuru mēs atveram testējamajā datu bāzē, izmantojot RunTest apstrādi, un novērojam, kā viss mums darbojas lieliski.

Otrās apstrādes funkcionalitāte neatšķiras, ņemot vērā, ka palaišanu var veikt arī ar pirmo apstrādi. Dažas noderīgas funkcijas ietver izpildes žurnāla saglabāšanu un pabeigto darbību atzīmēšanu.

Skatoties uz priekšu, lai vairs neatgrieztos pie šīs apstrādes, teikšu, ka uz vietas biju pārsteigts. Izmantojot visas nepieciešamās un ne tik nepieciešamās iespējas, nebija vietas testa darbības režīmam, kas ignorēja kļūdas. Tas padara ārkārtīgi nepatīkamu negatīvu testu veikšanu un testēšanu kopumā. Kad parādās mazākā neatbilstība, mūsu “automātiskā” apstrāde nonāk stuporā.

Tagad apskatīsim šīs sistēmas izmantošanas priekšrocības un trūkumus šajā jomā.

Lietošanas iezīmes.

Saskaņā ar oficiālajiem paziņojumiem, 1C Scenario testēšanai vajadzētu būt universālam rīkam saderības ar dažādām konfigurācijām ziņā. Es domāju, ka mana konfigurācija ir lieliska šī apgalvojuma pārbaudes vieta.

Uzreiz teikšu, ka darbu ar šo rīku nevar saukt par vienkāršu un mierīgu. Gandrīz katrā solī (visās nozīmēs) ir jāeksperimentē ar šķietami pašsaprotamām lietām.

Šeit ir daži no tiem, ar kuriem man bija jātiek galā:

1. Kādu iemeslu dēļ ar visām testa darbību opcijām nav neviena soļa apstrādātā objekta dzēšanai. Sākumā man bija jāizmanto darbība “Apstrāde” un manuāli jāraksta kods, lai izdzēstu objektus. Beigās nolēmu pagaidām iztikt bez tā un strādāt ar esošajiem datiem.
2. Viens no visnoderīgākajiem, manuprāt, ir solis “Salīdzināt kustību ar standartu”. Tas ir tas, kas pietrūka. Tagad ir iespējams izsekot visām izmaiņām darījumos, kas netika plānoti.
   Šis solis prasa ļoti precīzu regulēšanu. Piemēram, mums ir jāseko dokumenta kustībai četros reģistros, un katram no tiem ir savs lauku un analītikas kopums. Ir vērtības, kas mainīsies, mainoties objektam, un tā nebūs kļūda. Piemēram, lauks TimeStamp, kurā tiek ierakstīts dokumenta apstrādes laiks vai dokumenta numurs, ja tas tiek piešķirts automātiski. Visi šādi brīži, izpildot testu, radīs kļūdu. Labi, ka izstrādātāji to ņēma vērā un ļāva atspējot nekonstanta lauka pārbaudi. Mums tikai jāatrod tādi lauki.
   Tomēr pat šeit ir dažas nepilnības. Piemēram, manā soļu iestatīšanas formā nez kāpēc, ja ir parādīts vairāk nekā viens reģistrs, tad kustības tiem netiek rādītas, man ir jāizslēdz papildu un jākonfigurē katrs reģistrs atsevišķi.
   Un kas man vispār nepatika. Kā varēju saprast, tad ar reģistriem pārbauda tikai tās kustības, kas ir standartā. Piemēram, ja standartā ir viena transakcija, bet pārbaudītajā datu bāzē - trīs, tad salīdzināšanas laikā kļūdu nebūs. Jo Visā reģistrā tiek meklēti ieraksti ar atsauces parametriem, ja viss ir kārtībā, tad netiek izsekota citu ar to pašu objektu saistīto personu klātbūtne reģistrā.
3. Darbības, lai automātiski aizpildītu veidlapas, pamatojoties uz skriptu, ne vienmēr darbojas pareizi. Kļūdas bieži rodas atsauces laukos un datumos. Visticamāk, tā nav rīka kļūda, bet gan lauku iezīme, taču jums tomēr būs jāpielāgojas to iestatījumi.
4. Iespējamās soļu opcijas ir saistītas ar konkrētiem konfigurācijas objektiem. Tas, kas ir pieejams direktorijiem, var nebūt pieejams reģistriem utt. Precīzāk būtu teikt, ka iesiešana drīzāk ir nevis objektiem, bet to pazīmēm, teiksim, ja reģistram nav veidlapas, tad nebūs soli to aizpildīt.
   Bet ir arī kļūdas, piemēram, solis “Nospiediet pogu” man bieži nav pieejams, pareizāk sakot, pašu izvēli var izdarīt, bet nekas nenotiks.
5. Par testa automatizāciju dažos īpaši sarežģītos gadījumos vienkārši paliek daudz jautājumu. Tas jo īpaši attiecas uz dokumentiem, kas strādā ar atliekām, kur gandrīz visiem aspektiem ir svarīga loma, no kuriem dažus ir ļoti problemātiski ieviest pašreizējā rīka ieviešanā. Konfigurācijā ir vairāki ierobežojumi, lai izveidotu dokumentus vienā datumā, ar vienu un to pašu numuru utt. Līdz šim esmu apņēmies izmantot esošos objektus, neveidojot jaunus.

Šo sarakstu var turpināt un turpināt, taču ļaujiet to darīt šī produkta testētājiem. Galvenais, ko es sapratu un mēģinu pateikt, ir tas, ka "bezmaksas nebūs." Lai ieviestu testēšanas automatizāciju ar šo produktu galvenajā lomā, jums būs smagi jāstrādā vairāk nekā vienu dienu. Protams, mana analīze ir tīri subjektīva, un arī pieredzes trūkums produkta un konfigurācijas funkciju lietošanā to var ietekmēt, taču, kā saka, mums ir tas, kas mums ir, un no tā nevar izbēgt.

Lietojumprogrammas iespējas.

Pašlaik esmu izvēlējies šādu koncepciju attiecīgā rīka ieviešanai testēšanas procesā.

Pamatojoties uz pašreizējo darbības pieredzi, esmu pārliecināts, ka atsauces bāzei un testu bāzei datu ziņā jābūt identiskām. Protams, ja mēs runājam par skriptiem, kas izmanto esošos objektus, tos nemainot, un nerada jaunus. Pirmkārt, tas dos mums vienādus atlikumus abās bāzēs, un tas ir ļoti svarīgi, lai pārbaudītu apgrozījumu. Otrkārt, tas nodrošinās zināmu uzticamību un zināmu aizsardzību pret nevajadzīgām kļūdām, jo Joprojām līdz galam neizprotu saikni starp atsauces datiem un datu bāzēm, dažādām saitēm u.t.t.. Mani moka neskaidras aizdomas, ka varētu būt kaut kādas saites, kas reiz pārvērtīsies par mirušu saišu mudžekli, kas vairs nevar būt atšķetināts.

Tātad, mums ir atsauces bāze, uz kuras pamata esam izveidojuši scenārijus visiem gadījumiem. Kādā izstrādes konfigurācijas dokumentā ir veikti labojumi, kas ir jāpārbauda. Kā likums - manuāli. Pēc tam konfigurācija ar izmaiņām tiek ielādēta testa datu bāzē, un skripti tiek palaisti visiem vai tikai blakus esošajiem objektiem, lai noskaidrotu, vai izmaiņas dokumentā ir ietekmējušas citus objektus. Pēc tam konfigurācija tiek uzskatīta par dzīvotspējīgu un instalēta darba datu bāzē. Pēc tam modificētā dokumenta testēšanas skripts no darba datu bāzes tiek mainīts uz jaunu standartu.

Citiem vārdiem sakot, mēs veicam regresijas testēšanu ar šiem scenārijiem. Un tas ir viens no vissvarīgākajiem un grūtāk manuāli īstenojamajiem testēšanas veidiem 1C Enterprise. Galu galā ļoti bieži mainās ne tikai dokuments, bet, teiksim, dokumentu grāmatošanas funkcija, kas ir saistīta ar visiem sistēmas dokumentiem, un šeit mūsu skripti spēlēs tīkla lomu, kurā visi dokumenti, kas neizdodas. kritīs.

Vēl viens labs pielietojums varētu būt darba datubāzes pārbaude, lai atrastu nejaušas kļūdas. Lai to izdarītu, no tā tiek paņemts dublējums, ielādēts kādā testa datu bāzē un tiek palaists pilns testu cikls. Būtu labi šo procedūru veikt automātiski, taču 1C Scenario Testing vismaz pagaidām neparedz testu veikšanu pēc grafika.

Protams, šī rīka piemērošanas joma ar to nebeidzas, ir daudz iespējamo variantu; es esmu norādījis tikai pirmos, kas ienāca prātā.

Secinājums.

Šim rīkam neapšaubāmi ir nākotne. Man šķiet, ka lielākā daļa no tā potenciāla vēl ir jāatklāj vēlākās versijās, un, bez šaubām, produkts atradīs savu lietotāju, kurš, manuprāt, kas acīmredzot nesakrīt ar ražotāja viedokli, visticamāk nedrīkst būt parasts lietotājs bez specifiskām zināšanām IT jomā, un cilvēks ir no attīstības nodaļas. Jo Efektīva šī rīka izmantošana nav vieglākais uzdevums, it īpaši sarežģītās konfigurācijās.

Sveiki draugi!

Es vēršu jūsu uzmanību uz nelielu konfigurāciju scenāriju testēšanai risinājumiem, kuru pamatā ir 1C:Enterprise 8.3, pārvaldītās formas.

Konfigurāciju sauc par testeri. Testeris ir vide scenāriju testu izstrādei un izpildei. Testeris nav tīrs BDD produkts, un tas nav paredzēts, lai aprakstītu sistēmas darbību, pirms tā ir izstrādāta.

Testera galvenie mērķi:

1. Organizējiet kolektīvu darbu ar testiem vienā vidē ar atbalstu versiju veidošanai, uztveršanai rediģēšanai un citām pazīstamām funkcijām darbam ar kodu
2. Nodrošiniet lietotājam vienkāršu veidu, kā saprātīgā laikā izveidot, atbalstīt un paplašināt reālu scenāriju testus, ar minimālu slieksni, lai iekļūtu procesā, un uzticamu infrastruktūru.

Izmantojot testeri, varat paļauties uz šādu problēmu atrisināšanu:

1. Augsta funkcionālā pārklājuma pakāpe. Testeris ir labi orientēts uz testa izstrādes procesu, kas pozitīvi ietekmē izveidoto testu kvantitāti un kvalitāti
2. Testi ir rakstīti 1C programmēšanas valodā, kas ir ne tikai pazīstams rīks, bet arī ļauj testēšanā izmantot visu platformas funkciju komplektu un, pats galvenais, ļauj kontrolēt testēšanas gaitu programmatiski, nepaļaujoties uz iebūvēts modelis testēšanas rīkā
3. Varat izveidot bibliotēkas no testiem, piemēram, varat izveidot testus, kas, pamatojoties uz nodotajiem parametriem, atver meklēšanas logu dinamiskā sarakstā vai ģenerē atskaiti. Ja testa veikšanai nepieciešams atlikums noliktavā, varat ieviest bibliotēkas testu, kurā pārskaitāt vajadzīgā bilances sastāvu, un šis atlikums tiks kapitalizēts
4. Vienkārša biznesa loģikas pārbaude, bez salīdzināšanas ar datiem no citām datu bāzēm, bez tiešiem pieprasījumiem testējamajai lietojumprogrammai, bez izkārtojumiem ar datiem, kas serializēti “citur”. Visu informāciju var saglabāt pašā testā, izkārtojumā un, ja nepieciešams, modificēt.
5. Papildus tam, ka visi testi tiek glabāti datu bāzē un jebkurš Testera lietotājs var izmantot cita programmētāja rakstītu testu, Testerim ir iespēja pakāpeniski augšupielādēt/lejupielādēt testus failu sistēmā. Tas var būt noderīgi turpmākai testu sinhronizēšanai ar versiju kontroles sistēmām, piemēram, Git.

Demobāzē ir izveidota neliela savstarpēji saistītu testu infrastruktūra, ko var izmantot, izstrādājot savus testus. Tāpat datu bāzē ir piemērs, kā izveidot pasūtījumu piegādātāja dokumentam ERP2 (demo).

ERP2 konfigurācijai (demonstrācijai) tika izveidota repozitorija https://github.com/grumagargler/ERP2
Es tur augšupielādēju demonstrācijas testus. Ceru, ka šī iniciatīva nepaliks nepamanīta entuziastiem, un tiks pievienoti vēl citi pārbaudījumi.

Visplašāko informāciju par Testeri atradīsit palīdzībā, tā būs uz darbvirsmas, kad sistēma startēs. Palīdzībā ir sadaļa Quick Start, iesaku ar to iepazīties.

Testeris ir bezmaksas. Izstrādāts un atbalstīts mūsu pašu vajadzībām, bez jebkāda komerciāla motīva.

Paldies par interesi par sistēmu un veiksmi testos, draugi!

Atjauninājums 1.3.2.7

Pievienota procedūra LogError, ko izmanto, lai programmatiski pievienotu ziņojumus kļūdu žurnālam no skripta koda, neapturot skripta izpildi

Visas funkcijas darbam ar laukiem tagad var pārvietoties pa tabulas daļu, piemēram, šādi var pārbaudīt uzkrājuma summu piektajā rindā: Pārbaudīt ("#Accruals / Result [ 5 ]", 1000);

Funkcija Pārbaudīt mēģina pārbaudīt skaitliskās vērtības, neņemot vērā triādes atdalītāju un decimāldaļu

Pievienots palaišanas žurnāls, kurā tiek reģistrēti skripta izpildes notikumi

Pievienota pāreja no skripta uz starta žurnālu un kļūdu žurnālu

Lauku atlases kokam pievienots palīgs

Asistentam ir pievienota tiešsaistes palīdzība par iebūvētajām testēšanas metodēm.

Pievienotas lietojumprogrammu versijas. Versijas var iestatīt gan lietojumprogrammai kopumā, gan katram lietotājam atsevišķi

Pievienotie pārskati: Protokols, Kopsavilkums (pārskati darbosies tikai jaunizveidotajiem skriptiem šajā laidienā). Ir iespējams konfigurēt grafiku atskaišu nosūtīšanai pa pastu (veidojot pārskatus, tiek ņemts vērā lietotāju RLS)

Pārskati tiek ieviesti kā atsevišķas tiesības; lai tos pievienotu lietotājiem, kas nav administratori, jums ir jāveic atbilstoši iestatījumi viņu profilos.

Optimizēta skriptu augšupielāde failos. Augšupielādētie faili tiek ģenerēti bsl formātā

Pārejas secība:

Pēc konfigurācijas atjaunināšanas, pirms skriptu palaišanas, ieteicams norādīt to versijas saviem risinājumiem. Tas tiek darīts lietojumprogrammu direktorijā.

Uzmanību! Konfigurācijas pamatā ir versija 8.3.10, taču tiek atbalstītas arī vecākas versijas. Lai to izdarītu, ir jāiestata saderības režīms, kas nepieciešams konfigurācijai saskaņā ar versiju 8.3.10, jāsaglabā konfigurācija failā un jāizmanto kā atjauninājums.

Risinājuma kartīte 1C: 8. scenārija pārbaude

Tas ir rīku komplekts jebkuras sistēmas 1C:Enterprise 8 konfigurācijas funkcionalitātes pārbaudei. Produkts ļauj sagatavot nepieciešamos testus un veikt tos manuāli vai automātiski. Lai izstrādātu testus, izmantojot "1C: Scenario Testing 8", pietiek ar izpratni par pārbaudāmās konfigurācijas darbību lietotāja līmenī; programmēšanas prasmes nav nepieciešamas.

Pērciet 1C: Scenārija testēšana 8

4601546061393

42 000

Licencēšana 1C: Scenārija pārbaude 8

Produkts "1C: Scenario Testing 8" ir paredzēts lietošanai ar klienta licences "1C:Enterprise 8", palielinot darbu skaitu.Preces piegādes komplektā ietilpst izplatīšanas komplekts, grāmata “1C: Scenario Testing 8. User Guide” un licences līgums.

Lai lietotu produktu, jums ir jābūt jebkurai sistēmas 1C:Enterprise 8 pamata piegādei (PROF versijai). Produkts nav paredzēts lietošanai ar 1C:Enterprise 8 pamata versijām. 1C:Scenario testing 8 var legāli izmantot darbstacijās organizācijas lokālajā tīklā, kas nodrošināta ar 1C klienta licenci: Enterprises 8. 1C: Scenārija testēšana 8 iekļauta piegādes komplektācijā 1C: korporatīvais rīku komplekts 8

Atbalsts un atjaunināšana 1C: Scenārija testēšana 8

Atbalsts un serviss reģistrētajiem lietotājiem tiek nodrošināts Informācijas tehnoloģiju atbalsta (1C:ITS) ietvaros - 1C:ITS Techno vai 1C:ITS Prof. Bezmaksas abonēšanas periods, iegādājoties programmu, ir 3 mēneši. Pēc bezmaksas abonementa termiņa beigām, lai saņemtu produktu atbalsta pakalpojumus, jums ir jāreģistrējas maksas abonementam jebkurai 1C:Enterprise 8 sistēmas pamata piegādei.

Reģistrētie lietotāji var lejupielādēt atjauninājumus no vietnes users.v8.1c.ru un no ITS diska.

1C funkcionalitāte: scenārija pārbaude 8

Tests ir darbību kopums, kas lietotājam jāveic programmā. Tās var būt darbības, piemēram, jaunu direktoriju elementu, dokumentu izveide, datu aizpildīšana veidlapā vai pogu nospiešana. Kad šāda pārbaude tiek veikta automātiski, lietotāja ievade tiek simulēta. Ir svarīgi, lai testa komandu izpilde interaktīvai objektu izveidei un veidlapu aizpildīšanai platformā 1C:Enterprise 8 tiktu apstrādāta tāpat kā tad, ja lietotājs šos datus ievadītu no tastatūras.

Līdzīgs testēšanas princips pastāv arī citās programmās, taču atšķirībā no tām 1C: Scenario Testing 8 ievieš testa izstrādes iespējas, kas atspoguļo testēšanas 1C: Enterprise 8 konfigurāciju specifiku. Šīs iespējas ietver:

• veidņu veidošana dažādu konfigurācijas objektu veidlapu aizpildīšanai (tās var pielāgot un izmantot vienas un tās pašas konfigurācijas dažādiem testiem);
• saiknes analīze starp atsauces konfigurācijas bāzes objektiem un testa soļiem;
• ierakstītā testa pareizības analīze pirms tā izpildes;
• iespēja manuāli apiet konstatēto kļūdu, veicot automatizētu testu, un turpināt testu automātiskajā režīmā;
• automātiska dokumentu kustību salīdzināšana ar atsauces datu bāzes datiem;
• testā izveidoto objektu nepieciešamais salīdzinājums ar uzziņu datu bāzes datiem;
• iespēja atkļūdot darbības, ierakstot testu;
• konfigurācijas objektu testa pārklājuma analīze.

Lai veiktu testu, nav nepieciešama īpaša pārbaudāmās konfigurācijas sagatavošana.

Tajā pašā testā varat izveidot darbības, lai pārbaudītu dažādus biznesa darījumus. Testa loģiku raksturo noteikumi biznesa darījumu atspoguļošanai programmā saskaņā ar lietotāja dokumentāciju. Tādējādi rīku var izmantot scenāriju vai konfigurāciju funkcionālai pārbaudei.

Nepieciešamība pēc šādas pārbaudes rodas, ja ir jāpārliecinās, ka, pārveidojot konfigurācijas funkcionalitāti vai labojot kļūdas, tiek saglabāta nemainīga konfigurācijas funkcionalitātes funkcionalitāte. Tas ir vairāk pieprasīts tajās organizācijās, kur jaunu konfigurācijas laidienu izstrāde, to testēšana un izlaišana ir iteratīva. Šajā gadījumā testu rakstīšanas un to turpmākās automatizētās izpildes izmaksas būs mazākas nekā ar katras jaunas konfigurācijas izlaiduma manuālo regresijas testēšanu.

Parasti testi tiek rakstīti visbiežāk izmantotajiem reāla darba scenārijiem ar lietojumprogrammas risinājumu un tiek izpildīti katrā jaunā modificētās konfigurācijas vai platformas versijā. Testus var padarīt vairāk vai mazāk sarežģītus atkarībā no kļūdu kritiskuma konkrētā lietojumprogrammas risinājuma funkcionalitātē un atkarībā no laika, ko organizācija ir gatava tērēt testēšanai.

Rīku komplekts 1C:Scenario testing 8 sastāv no divām ārējām apstrādēm (viena apstrāde paredzēta testa ierakstīšanai, otra tā izpildei), kā arī testu komplekta (faili xml formātā) tipiskām 1C:Enterprise 8 konfigurācijām.

Var izmantot:

• partneri - aprites risinājumu izstrādātāji,
• partneri vai lietotāji, kuru uzdevums ir pārbaudīt konfigurāciju pirms darba datu bāzes atjaunināšanas.