Bandymo įrankiai tiems, kurie gailisi gaišti savo laiką rutinai. Testavimo įrankiai tiems, kurie gailisi gaišti savo laiką įprastiniam automatiniam testavimui 1s

Scenarijų testavimo tema jau seniai buvo atskleista, ir beveik kiekviena įmonė žino, kad tam tikru mastu reikia naudoti TDD ir BDD. Mūsų nedidelė 1C kūrėjų grupė nebuvo išimtis. Tačiau nuo poreikio supratimo iki realaus technologijų panaudojimo praeina laikas, o pakeliui trapūs protai, tokie kaip šio straipsnio autorius, pradeda galvoti apie viso šios veiklos efektyvumą. Jei jus domina, kaip grupė protingų vaikinų savo darbe pristatė kažką panašaus į scenarijų testavimą, sveiki atvykę.

fone

Rinkoje yra labai galingų ir pažangių vartotojo sąsajos testavimo įrankių. Yra specialios skriptų kalbos, daug dokumentacijos ir metodikų. Kitaip tariant: „Turite problemų? Yra sprendimas!".

Kita vertus, energija, išeikvojama problemai spręsti, turi kažkaip atitikti energiją, kurią gamina visas kolektyvas. Tačiau praktikoje, jei didelės įmonės gali sau leisti išlaikyti atskirus kokybės užtikrinimo specialistus (-us) ir testuotojus su maksimaliu procesų diegimu, tai maži biurai ne visada gali tai padaryti, kai kurias funkcijas tenka priskirti sau, o paties proceso filosofija šiek tiek iškreipta .

Taigi, atsižvelgiant į: geografiškai paskirstyta 1C kūrėjų grupė iki 10 žmonių, vidutiniškai iki 5 aktyvių projektų, daugiausia individualių sprendimų kūrimas nenaudojant tipiškų 1C produktų.

Tikslas: kuo efektyviau įgyvendinti plėtros testavimo procesus, įskaitant sąsajos veikimo ir verslo logikos testavimą. Efektyvumas reiškia pusiausvyrą, kai bandymams praleistas laikas vis dar yra prasmingas galutiniam rezultatui. Pripažįstu, kad ši eilutė yra labai subjektyvi ir galbūt visiškai pateisina posakį „bandymas palyginti šiltą su minkštu“. Kokie yra scenarijų testavimo tikslai, manau, skaitytojas žino net geriau nei autorius.

Išstudijavus daugybę Vakarų gamintojų instrumentinių sistemų, taip pat scenarijų testavimą iš 1C versijos 3.0 ir xUnitFor1C, atrodė, kad mes dar nesame protiškai subrendę diegti šias technologijas. Laikas praėjo, o mes vis dar negalime užaugti. Tuo pačiu viduje viskas reikalavo ir reikalavo bent kažkokio sprendimo.

Išrinkus senus įrašus, dar kartą buvo sudarytas potencialaus programinės įrangos produkto reikalavimų sąrašas:

  • Tirpalas turi būti debesyje
  • Visų pokyčių bandymų bazė turėtų būti vienoda
  • Turėtų būti prieigos prie programų kontrolė (kiekvienas programuotojas turi savo kūrimo baseiną)
  • Testo kūrimas ir vykdymas turi būti toje pačioje IDE
  • Scenarijai turi būti užprogramuoti, o ne parašyti vartotojo veiksmais
  • Pageidautina, kad bandomoji programavimo kalba būtų panaši į 1C kalbą
  • Testai turi būti paleisti vienu mygtuku, be išankstinių manipuliacijų, kompiliacijų, surinkimų, įkėlimų, atsisiuntimų ir pan.
  • Rašant testą, turėtų būti įmanoma išanalizuoti langų struktūrą ir bandomos programos atributus pagal 1C valdomos sąsajos modelį, ir tai turėtų būti programoje, kurioje yra sukurtas pats testas. Testuojamos programos laukų ypatybes turėtų būti įmanoma gauti, einant per kontrolinių duomenų medį testavimo bazėje – bandoma programa turi reaguoti ir parodyti, kur yra šis valdiklis.
  • Verslo logikai tikrinti neturėtų būti naudojama atskaitos bazė
  • Norint atlikti testą, neturėtų būti specialiai paruoštos bazės, visi testai turi veikti ir sukurti viską, ko jums reikia.
Žinoma, sąrašas toli gražu nėra baigtas ir tam tikru mastu jis yra kituose programinės įrangos produktuose. Gali atrodyti, kad tai jaunatviškas maksimalizmas, tačiau tik tada, kai visos šios sąlygos buvo įvykdytos viename gaminyje, pamatėme, kad mūsų situacijoje galima įgyvendinti scenarijų testavimą. Kolegos gal ir nesutiks su manimi, bet aš laikausi nuomonės, kad viena iš esminių problemų, susijusių su testų kokybe ir kiekybe, yra tai, kaip greitai ir patogiai galima atlikti šiuos testus nuolatinio programų kūrimo režimu.

Turbūt praėjo dar šeši mėnesiai, ir galiausiai nusprendžiau pradėti kurti kitą bandomąjį dviratį (toliau – testeris) vangiu pasirenkamu režimu ir štai kas iš to išėjo.

Kaip tai atrodo

Dėl to gimė 1C pagrindu sukurta programa, kurioje rašomi ir vykdomi scenarijų testai sprendimams, pagrįstiems 1C. Kasdienis naudojimas yra maždaug toks: testeris dirba visą dieną prie programuotojo antrame monitoriuje. Projekto duomenų bazėje vadovas nurodo reikiamą testų rinkinį, kurį turi apimti projektas.

Taip pat yra keletas standartinių, privalomų testų, kuriuos programuotojas turi atlikti atliekant kiekvieną užduotį. Pavyzdžiui, jei dokumentas įvedamas remiantis, turėtų būti įėjimo testas, pagrįstas. Kitaip tariant, programuotojas žino, kurie testai turi būti sukurti.

Kada rašomi testai?

Praktiškai testų rašymas puse atvejų vyksta kūrimo procese (labai patogu įprastiniam automatizavimui, kai kiekvieną kartą paleidus programą reikia kartoti tuos pačius veiksmus). Kitoje pusėje – po. Kaip turėjo pastebėti įmantrus skaitytojas, šią situaciją vargu ar galima pavadinti klasikiniu BDD.

Bandymo pavyzdys

Tarkime, yra projektas „Develop Document Build Kit“. Šiam dokumentui reikalinga sąrašo forma su sandėlio filtru. Bendroji sąrašų veikimo koncepcija šiame sprendime perimama taip: jei nustatytas filtras, be dokumentų atrankos pagal filtro reikšmę, reikia, kad pasirinkimo reikšmė būtų numatytoji vertė įvedant naują dokumentą iš šio forma. Taigi, jei sandėlis yra įrengtas, jis turėtų būti automatiškai įdiegtas įvedus naują dokumentą.

Tik iš pirmo žvilgsnio atrodo, kad tokiam scenarijui testo nereikia, tačiau atsižvelgiant į įvairias dokumentų įvedimo galimybes, Sandėlio laukas gali užtrukti skirtingos reikšmės. Juk dokumentą galima nukopijuoti arba vartotojas turi kitą įmonę, nurodytą numatytuosiuose nustatymuose, o filtre pasirinktas sandėlis nėra jo organizacinis vienetas. Vienaip ar kitaip testas atrodys taip (savo komandoje turime užsieniečių, tad pats testeris parašytas angliškai, o pats pritaikytas sprendimas skirtas Amerikos klientams):

Viršuje - kuriama programa, žemiau - testeris, plonojo kliento režimu, bandomoji duomenų bazė debesyje. Kodas, kurį matote, parašytas 1C kalba. Scenarijaus kodas sąveikauja su veikiančia kliento programa per bandomosios 1C programos metodų įvynioklius, pavyzdžiui, taip atrodo Pasirinkti (...) metodas;


Beveik visas sąsajos operacijas bandžiau diegti testeryje, bet net ir prireikus kažko konkretaus, visada galima gauti testuojamo lauko objektą ir jame vykdyti bet kokius metodus, kurie yra įdiegti testuojamos programos modelyje.

Pereikime prie įdomesnių scenarijų.

Bandomasis ryšys

Norėdami sukurti Surinkimo dokumento kūrimo ir vykdymo scenarijų, kaip ir ankstesniame pavyzdyje, turime turėti daug papildomų duomenų: reikiamą katalogų sudėtį, medžiagų likutį sandėlyje, o tai bent jau reiškia, kad yra kažkoks atvykimas į sandėlį. Kaip jau sakiau anksčiau, patys nusprendėme, kad bandymai turi būti atliekami tokiomis sąlygomis, kai atskaitos bazė neegzistuoja, yra tik pradinis programos vaizdas, kur yra bent vienas vartotojas, turintis administravimo teises, užpildyti klasifikatoriai, ir numatytosios vertės patogiam pradiniam darbui.

Tačiau kiekvieną kartą parašyti visą scenarijų, kuris sukurs visus reikiamus duomenis „pakeliui“, bus neefektyvu. Norėčiau sukurti parametrizuotą testą, kuris ne tik žino, kaip kažką daryti, bet ir priima parametrus. Pavyzdžiui, norint sukurti kvitą duomenų bazėje, turi būti testas, kuris jį sukurs. Ir niekas netrukdo mums atlikti šio testo parametrų ir perduoti į jį visus reikiamus duomenis, pavyzdžiui, kokia data atlikti kvitą, į kurį sandėlį ir kokias medžiagas / paslaugas gauti. Savo ruožtu kvito sudarymo teste bus naudojami sandėlio kūrimo testai, medžiagos, kurių bus tikimasi parametruose pakuotės tipas, tipas, konversijos koeficientai ir pan.

Kadangi mūsų programa yra miglota, o testų bazė yra vieninga, kiekvienas programuotojas, kurdamas tam tikrą testą, gali jį parametruoti į kažką tiesiogiai rašydamas testą, atverdamas jį plačiam naudojimui kitiems programuotojams.

Štai pavyzdys, kaip surinkimo kūrimo testas ruošiasi priėmimui:


(kainos, sumos ir kiekiai nurodomi kaip eilutės, kad būtų išvengta klaidingai teigiamo testo patvirtinimo problemų, jei jis vykdomas kitoje vietoje, kur, pavyzdžiui, triadų ir trupmeninių dalių skyriklis gali skirtis)

Vykdant šį testą bus atlikta daugybė kitų testų, kurie sukurs viską, ko reikia, kad būtų galima išbandyti surinkimą kaip tokį. Štai koks rezultatas bus duomenų bazėje:


Verslo logikos testavimas

Be to, kad buvo „paspausti“ visi mygtukai ir „pasirinkti“ laukai, testavimo įvykis būtų palikęs gilų randą širdyje, jei nebūčiau patikrinęs dokumentų registravimo mechanizmų rezultatų ir įvertinęs einamąją apskaitą. padėtis duomenų bazėje.

Prisipažinsiu, ilgai mąsčiau, kaip geriau tai įgyvendinti taip, kad be atskaitos pagrindo, ir kad tai būtų lengva ir paprasta. Nieko geresnio nesugalvojau, kaip lengva patikrinti dokumentų judėjimą kartu su ataskaitų tikrinimu.

Čia yra dokumento judėjimo ataskaitos pavyzdys bandomoje programoje:

Štai kaip testeris patikrins šiuos judesius:

Svarbu patikrinti raudonas sritis. Be sričių, testeryje galite nustatyti lauko patvirtinimą pagal šabloną.

Patikrinimų pavyzdžiai

Dažnai kyla problemų tikrinant to paties tipo objektus. Pavyzdžiui, puse atvejų dokumentų formose yra lentelės dalis, o programavimo klaidos dažnai daromos kopijuojant eilutes, ištrinant pirmą eilutę arba įvedant ir atsisakant įvesti pirmąją/paskesnes eilutes. Šiuo tikslu galima sukurti testavimo metodą, kuris neturi savarankiško scenarijaus, bet yra naudojamas tik skambučiui vietoje. Tai labai patogu, nes laikui bėgant tokių testų skaičius gali būti padidintas pridedant kitus testavimo elementus, o tai reiškia, kad dėl plačiai paplitusio tokių testų taikymo automatiškai išplečiama taikymo sritis.

Klaidų valdymas

Yra bent trijų tipų klaidos, kurias norėtume kontroliuoti. Pirmasis tipas yra kodavimo klaidos, pvz., padalijimas iš nulio, prieiga prie neegzistuojančios savybės ar metodo. Antro tipo klaidos – tai logikos klaidos, pavyzdžiui, paspaudus mygtuką forma turėtų užsidaryti, bet taip neatsitiks arba pažymėjus langelį dalis formos turėtų tapti nepasiekiama arba nematoma. Ir trečios rūšies klaidos, verslo logikos klaidos, pavyzdžiui, nurašant medžiagą iš sandėlio, nebuvo įmanoma nustatyti jos buvimo duomenų bazėje. Visų trijų tipų klaidas galima ištaisyti testeriu. Suaktyvinus testeris registruoja išimtį, įrašo ją į žurnalą ir gali parodyti skambučių krūvą, pavyzdžiui, taip:

Taip pat buvo įdiegta keletas verslo logikos klaidų tvarkymo metodų. Pavyzdžiui, jūsų testas tyčia nori nukopijuoti daugiau medžiagos ir norite patikrinti, ar pranešimas bus suformuotas teisingai, ar jis iš viso bus suformuotas.

Štai tokio patikrinimo vykdymo viename iš testų pavyzdys:


Elementų medžio analizė

Testuotojas gali nuskaityti vaizdinius testuojamos programos objektus. Tai patogu, o kartais tiesiog būtina rašant scenarijų, ypač daugiakalbiams sprendimams, kai mygtukų pavadinimai priklauso nuo vartotojo kalbos, o sąsajai sukurti reikia naudoti vidinį identifikatorių (nebent, žinoma, užduotis – patikrinti mygtukų etikečių sintaksę). Štai pavyzdys, kaip testeris pateikia nuskaitytus duomenis:

Išvada

Apskritai pasirodė, kad tai mažas dviratis, padedantis 1C programuotojui. Kaip teigiamų savybių programos apima šias:
  • Testerį lengva įdiegti ir konfigūruoti
  • Iš pradžių jis yra kelių vartotojų (vartotojai taip pat sukuriami testeryje, administravimo posistemyje)
  • Testams rašyti nereikia specialių žinių
  • Leidžia įgyvendinti sudėtingus verslo logikos scenarijus
  • Leidžia vienoje duomenų bazėje laikyti tūkstančius skirtingų projektų testų ir juos „naudoti dar kartą“. Pavyzdžiui, galite sukurti testą, kad rastumėte dokumentą sąraše pagal numerį, kuris yra bendras visiems projektams. Arba, jei klientų bazė yra įdiegta remiantis kokiu nors standartiniu sprendimu, kuriam jau yra testai, galite patikrinti klientų bazę iškviečia visus pirminius testus, taip pat specifinius kliento testus
Ir, žinoma, dar daug kas neįgyvendinta:
  • Nėra bandomojo paleidimo grafiko
  • Nėra pažangios analizės sistemos, grafikų ir ataskaitų apie bandymų rezultatus
  • Jokių automatinių laiškų ir pranešimų apie tai, kas sugedo, kas sugedo ir kodėl
  • Nėra ryšio su saugyklomis ir testų versijų kūrimas
Testeris yra atviras ir nemokamas, pageidautina paleisti nuo 8.3.8, bet veiks ir 8.3.7, jei įjungsite suderinamumo režimą. Viduje yra šiek tiek pagalbos (atsisiunčiama iš interneto), metodo įvyniojimai taip pat yra rusų kalba, dt-shnik galima atsisiųsti iš čia. Yra keletas apskaitos korporacijos 3.0 pavyzdžių.

Sėkmės jūsų draugams atliekant testus ir ačiū už dėmesį!

Žymos:

  • BDD
  • scenarijaus testavimas
Pridėti žymes

Straipsnyje aptariamas naujas automatinio testavimo mechanizmas, kuris pirmą kartą pasirodė platformoje 8.3 leidime. Išstudijavę straipsnio medžiagą, sužinosite:

  • Kas yra automatinis testavimas platformoje?
  • Kaip ir kada jį naudoti?
  • Ką ir kur reikia sukonfigūruoti, kad jis būtų paleistas?
  • Kaip parašyti automatinį testo scenarijų?

Pritaikomumas

Straipsnyje aptariama 1C:Enterprise platformos versija 8.3.4.465. Dabartinėje platformos versijoje automatinio testavimo mechanizmo galimybės gerokai išplėstos, tačiau tai neturėjo įtakos straipsnio medžiagos aktualumui. Tai vis dar aktualu.

Automatinis testavimas naudojant 1C:Enterprise 8.3

1C:Enterprise 8.3 platforma turi naują mechanizmą, skirtą interaktyviems sistemos vartotojų veiksmams imituoti – automatizuotą testavimą.

Automatinis testavimas nepalaiko darbo su įprasta sąsaja, o tik su valdoma sąsaja.

Testuojant naudojamos dviejų tipų kliento programos – testavimo tvarkyklė ir bandomasis klientas. Testavimo tvarkyklė užmezga ryšį su bandomuoju klientu ir vykdo bandomąjį scenarijų.

Bandomasis scenarijus yra įtaisytosios kalbos kodas, aprašantis interaktyvių veiksmų seką, kurią reikia atlikti.

Norėdami tai padaryti, į integruotą kalbą buvo įtraukti nauji objektai, kurie abstrakčiu lygmeniu apibūdina programos sąsają (lango, formos, valdiklių ir pan.), taip pat aprašo vartotojo veiksmus (konfigūracijos naršymą, duomenų įvedimą). ir kt.) .

Testo vadovas gali būti storas arba plonas klientas. Bandomasis klientas – storas klientas, plonas klientas arba žiniatinklio klientas.

Bandomasis tvarkytuvas gali būti prijungtas prie kelių bandomųjų klientų, o bandomasis klientas gali būti prijungtas tik prie vieno valdytojo.

Norėdamas valdyti klientą, valdytojas užmezga su juo TCP ryšį. Svarbu, kad atliekant automatinį testavimą nereikėtų keisti konfigūracijos struktūros.

Iš esmės bandomasis klientas ir tvarkyklė yra konfigūracijos, vykdomos naudojant tam tikras komandinės eilutės parinktis, o valdytojas valdo klientus „priversdamas“ langus ir valdiklius elgtis taip, lyg vartotojas su jais sąveikautų.

Automatinis testavimas turi savo apribojimų. Taigi, pavyzdžiui, darbas su įprasta sąsaja nepalaikomas, o tik su valdoma.

Norint atlikti automatinį testavimą, turi veikti ir testavimo tvarkyklė, ir bandomasis klientas.

Tvarkyklę galima paleisti iš komandinės eilutės naudojant /TESTMANAGER klavišą:

„c:\Programų failai (x86)\1cv8\8.3.4.437\bin\1cv8c.exe“ ĮMONĖ /F „X:\testas“ /N Administratorius /TESTMANAGER

Be to, testavimo tvarkyklę galima paleisti iš konfigūratoriaus.

Norėdami tai padaryti, meniu Įrankiai - Parinktys atidarykite dialogo langą "Parinktys", kuriame skirtuke Paleiskite 1C: Įmonė - Išplėstinė, pažymėkite elementą "Vykdyti kaip bandymo tvarkyklę":

Kitas būdas paleisti bandymų tvarkyklę yra iš integruotos kalbos, naudojant StartSystem() metodą, kuriame turite nurodyti komandinę eilutę:

StartSystem („c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe“ ENTERPRISE /F X:\test /N Administratorius /TESTMANAGER)

Bandomąjį klientą taip pat galima paleisti iš komandinės eilutės. Norėdami tai padaryti, naudokite komandų eilutės jungiklį /TESTCLIENT.

Parametras TPort nurodo prievado numerį, per kurį vadybininkas ir bandomasis klientas sąveikaus. Jei ši parinktis nenurodyta komandinėje eilutėje, bus naudojamas 1538 prievadas.

"c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ĮMONĖ /F "X:\Platform8Demo" /N Administratorius /TESTCLIENT -TPort 1539

Bandomąjį klientą galima paleisti iš konfigūratoriaus. Norėdami tai padaryti, meniu Įrankiai - Parinktys atidarykite dialogo langą "Parametrai", kuriame skirtuke Paleisti 1C: Įmonė - Išplėstinė pažymėkite elementą "Vykdyti kaip bandomąjį klientą". Tokiu atveju turėsite nurodyti naudojamo prievado numerį.

Atkreipkite dėmesį, kad norint prisijungti prie bandomojo kliento, reikia žinoti du parametrus: kompiuterio, kuriame veikia bandomasis klientas, IP adresą (arba pavadinimą) ir TCP prievado numerį, kuriuo bus palaikomas ryšys.

Abi skirtingos informacijos bazės gali būti naudojamos kaip tvarkyklė ir testavimo klientas (testavimo tvarkyklės duomenų bazės konfigūracija gali neatitikti testuojančio kliento konfigūracijos) arba ta pati informacinė bazė.

Norėdami atlikti automatinį testavimą, turite atlikti šiuos veiksmus:

  1. Sukurkite bandomąjį scenarijų – konfigūracijoje parašykite išorinį arba įmontuotą apdorojimą, kuris nuosekliai aprašys veiksmus, kuriuos reikia atlikti.
  2. Paleisti bandymo tvarkyklę.
  3. Paleiskite bandomąjį klientą (vieną ar daugiau).
  4. Testavimo tvarkyklėje paleiskite sukurtą apdorojimą vykdyti, įsitikinkite, kad klientui atlikti suprogramuoti veiksmai.

Bandomą programą apibūdina 1C:Enterprise kalbos objektų rinkinys, kuris naudojamas scenarijui rašyti:

  • Išbandyta programa;
  • TestedWindowClientApplication;
  • TestedCommandInterfaceWindow;
  • TestedCommandInterfaceGroup;
  • TestedButtonCommandInterface;
  • TestedForm;
  • TestedFormField;
  • TestedFormGroup;
  • TestedFormButton;
  • TestedFormTable;
  • Išbandyta dekoravimo forma.

Kaip bandomąją konfigūraciją naudosime „Valdomos programos“ demonstracinę konfigūraciją.

Sukurkime išorinį apdorojimą, pridėkime naują formą, kurioje nustatysime tvarkyklę naujai „RunTesting“ komandai.

Teste atliekame šiuos veiksmus: sukuriame naują katalogo „Sandėliai“ elementą, lauke Name įveskite eilutę „Sandėlio testas“, tada spaudžiame mygtuką „Išsaugoti ir uždaryti“.

Šio testo kodas atrodys taip:

&AtClient
Procedūra Vykdymo testavimas(Komanda)
// Prisijunkite prie bandomos programos
Išbandyta programa= Nauja Išbandyta programa(„localhost“);
// Bandoma prisijungti ne ilgiau kaip vieną minutę
Pabaigos laikas Laukimas= DabartinisData() + 60 ;
Prisijungta = klaidinga ;
Nors ne dabartinė data() >= Pabaigos laikas Laukimas Ciklo bandymas
TestedApplication.SetConnection();
Prisijungta = tiesa ;
nutraukti;
Išimtis
EndTry ; EndCycle ; Jei neprisijungęs, tada
// Baigti testą
Išbandyta programa= neapibrėžta ;
Pranešti apie ( "Nepavyko prisijungti!");
Grįžti ;
EndIf ;
// Raskite pagrindinį langą
MainWindowTested
=(Tipas());
MainWindowTested.Activate();
// Vykdykite komandą, kad sukurtumėte produkto katalogo elementą
Pagrindinis Tested.RunCommand langas(„e1cib/command/Catalog.Warehouses.Create“);
TestedApplication.ExpectObjectDisplay(A tipas ( „Išbandyta forma“), „Sandėlis*“ );
Išbandyta forma= TestedApplication.FindObject(A tipas ( „Išbandyta forma“),
„Sandėlis*“ );
TestedForm.Activate();
// Nustatykite naujo produkto pavadinimą
FormItem = TestedForm.FindObject(A tipas ( „TestedFormField“),
"Vardas");
FormElement.Activate();
FormElement.EnterText(„Sandėlio testas“);
// Rašymo elementas
FormItem = TestedForm.FindObject(A tipas ( „FormButton Tested“),
„Įrašyti ir uždaryti“);
FormaElement.Paspauskite();
Procedūros pabaiga

Paleidimo parinkčių dialogo lange pirmiausia buvo pasirinkta reikšmė „Vykdyti kaip testavimo tvarkyklę“, naudojant Ctrl + F5 klavišų kombinaciją, buvo paleista vartotojo sesija.

Tada dialogo lange buvo pasirinkta reikšmė „Vykdyti kaip testavimo klientą“, naudojant Ctrl + F5 klavišų kombinaciją, buvo paleista antroji vartotojo sesija.

Taip išvengėme būtinybės rankiniu būdu nurodyti reikiamas komandų eilutės parinktis.

Aukščiau pateiktas kodas veikia gana gerai paprasti žingsneliai, bet jei scenarijus tampa sudėtingesnis, kodo kiekis taip pat padidės, nes būtina aprašyti kiekvieną interaktyvų vartotojo veiksmą.

Čia į pagalbą ateina dar vienas. nauja galimybė Platformos – vartotojo veiksmų žurnalo įrašas.

Norėdami tai padaryti, turite paleisti programą specialiu režimu:

Spustelėkite paveikslėlį, kad jį padidintumėte.

Programos antraštėje rodomi keli mygtukai:

Mygtukai skirti:

  • pradėti/sustabdyti įrašymą;
  • sustabdyti įrašymą;
  • įrašo užbaigimas.

Baigus įrašymą, ekrane atsidaro tekstinis dokumentas, kuris yra vartotojo veiksmų seka, įrašyta XML faile.

Spustelėkite paveikslėlį, kad jį padidintumėte.

Įrašytą žurnalą galima konvertuoti į programos kodą, kuris vėliau gali būti naudojamas bandomajame scenarijuje.

Tam skirtas „Vartotojo veiksmų žurnalo konversijos“ apdorojimas (UILOgToScript.epf), kurį galima gauti ITS svetainėje.

Spustelėkite paveikslėlį, kad jį padidintumėte.

Apdorojimo metu gauname sugeneruotą kodą įtaisyta kalba. Šis kodas turėtų būti įklijuotas į bandymo apdorojimo formos modulį.

Atminkite, kad sugeneruotame kode skaičiai, didesni nei 999 arba mažesni nei -999, bus išvesti naudojant nepertraukiamą tarpą kaip grupės skyriklį (pavyzdžiui, "1234" vietoj "1234").

Šis simbolis turi būti pašalintas iš gauto kodo rankiniu būdu.

Apdorojant automatiškai sugeneruota kodo dalis su ryšiu su klientu.

Mūsų pavyzdyje gauname šį kodą:

&AtClient
Procedūra Vykdymo testavimas(Komanda)
Bandymo scenarijus_23_03_2014();
EndProcedure &AtClient
Procedūra Bandymo scenarijus_23_03_2014() TestApp= Nauja Išbandyta programa();
Pabaigos laikas Laukimas= DabartinisData() + 60 ;
Prisijungta = klaidinga ;
AprašymasErrorsConnections= “” ;
Nors ne dabartinė data() >= Pabaigos laikas Laukimas Ciklas
Bandymas
TestApplication.SetConnection();
Prisijungta = tiesa ;
nutraukti;
Išimtis
AprašymasErrorsConnections= DescriptionErrors();
EndTry ;
EndCycle ;
Jei neprisijungęs, tada
TestApp= neapibrėžta ;
Ataskaita (+ simboliai. PS + AprašymasErrorsConnections);
Grįžti ;
EndIf ; ( TestApp);
(TestApp); EndProcedure &AtClient
Procedūra WindowApplicationAccountsCreateButtonClick(TestApp)
WindowApplicationContractors= (Tipas (
„TestingClientApplicationWindow“), „Rangovai“ , , 30 );
WindowApplicationAccountsFormAccounts= WindowApplicationAccounts.FindObject(A tipas (
„Išbandyta forma“), „Rangovai“);
ButtonCreate = WindowApplicationAccountsFormAccounts.FindObject(A tipas (
„FormButton Tested“), „Sukurti“);
Mygtukas Sukurti. Paspauskite(); EndProcedure &AtClient
Procedūra WindowApplicationAccountCreateButtonSaveAndClosePaspauskite(TestApp) WindowApplicationContractorCreation= TestApplication.FindObject(A tipas (
„TestingClientApplicationWindow“), „Paskyra (sukūrimas)“, , 30 );
WindowApplicationAccountCreationFormAccountCreation=
WindowApplicationAccountCreate.FindObject(A tipas ( „Išbandyta forma“),
„Paskyra (sukūrimas)“);
Lauko pavadinimas=
(A tipas (
„TestedFormField“), "Vardas");
FieldName.EnterText(„Naujas“); Lauko tipasKaina = WindowApplicationAccountCreationFormAccountCreation.FindObject(A tipas (
„TestedFormField“), „Kainos tipas“);
FieldPriceType.Activate(); Lauko tipasKaina.Pasirinkite(); FieldPriceView.WaitFormationDropdownList(); FieldPriceType.PerformSelectionFromSelectionList(„Pirkimas“); MygtukasIšsaugoti&Uždaryti=
WindowApplicationAccountCreationFormAccountCreation.FindObject(A tipas (
„FormButton Tested“), „Įrašyti ir uždaryti“);
MygtukasIšsaugoti&Uždaryti.Paspauskite(); Procedūros pabaiga

Gautame scenarijuje užmezgamas ryšys su testuojančiu klientu, paspaudžiamas mygtukas, skirtas sukurti naują katalogo „Rangovės“ elementą, lauke vardasįvedamas tekstas „Naujas“, o išskleidžiamajame sąraše „Kainos tipas“ pasirinkite reikšmę „Pirkimas“, tada spaudžiamas mygtukas „Išsaugoti ir uždaryti“.

Jei scenarijuje reikia naudoti kelis bandomuosius klientus, tai prisijungimas prie kiekvieno iš jų ir atliekami veiksmai turi būti aprašyti atskirai.

Bandymų tvarkyklė bus naudojama atskirai, prie jos yra prijungti du klientai skirtinguose prievaduose.

Kadangi yra apdorojamas bandomasis scenarijus, kurio programos kodo eilutės vykdomos nuosekliai, kūrėjas turi aprašyti kiekvieno kliento veiksmų seką.

Pažiūrėkime atidžiau, kaip kodas atrodys naudojant du bandomuosius klientus:

Procedūra Bandomasis scenarijus_23_03_2014_TwoClients() //pirmas klientas
Bandomoji programa 1= Nauja Išbandyta programa();
Pabaigos laikas Laukimas= DabartinisData() + 60 ;
Prisijungta = klaidinga ;
AprašymasErrorsConnections= “” ;
Nors ne dabartinė data() >= Pabaigos laikas Laukimas Ciklas
Bandymas
TestApplication1.SetConnection();
Prisijungta = tiesa ;
nutraukti;
Išimtis
AprašymasErrorsConnections= DescriptionErrors();
EndTry ;
EndCycle ; //antras klientas
TestApp2= Nauja Išbandyta programa();
Pabaigos laikas Laukimas= DabartinisData() + 60 ;
AprašymasErrorsConnections= “” ;
Nors ne dabartinė data() >= Pabaigos laikas Laukimas Ciklas
Bandymas
TestApplication2.SetConnection();
Prisijungta = tiesa ;
nutraukti;
Išimtis
AprašymasErrorsConnections= DescriptionErrors();
EndTry ;
EndCycle ;
Jei neprisijungęs, tada
Bandomoji programa 1= neapibrėžta ;
TestApp2= neapibrėžta ;
Pranešti apie ( "Negalima prisijungti!"+ Simboliai.PS + AprašymasErrorsConnections);
Grįžti ;
EndIf ; //procedūros yra atskiros kiekvienam testuojančiam klientui
WindowApplicationAccountsCreateButtonPress1(Bandomoji programa 1);
WindowApplicationAccountsButtonCreateClick2(TestApp2);
WindowApplicationAccountCreateButtonSave&ClosePaspauskite1(Bandomoji programa 1);
WindowApplicationAccountCreateButtonSave&ClosePress2(TestApp2); Procedūros pabaiga

Pauzes tarp atliekamų veiksmų taip pat reikia užprogramuoti atskirai. Daugelio klientų scenarijus tampa sunkiai įskaitomas.

Be to, automatinis testavimas galimas tik valdomoms formoms.

Tačiau automatizuoto testavimo pranašumas yra testo kūrimo paprastumas ir matomumas. Kadangi testas veikia tik interaktyviais vartotojo veiksmais, kūrėjui nereikia žinoti konfigūracijos struktūrų objekto atributo lygiu.

Pakeitus, pavyzdžiui, konfigūracijos kodą, testo perdaryti nebereikės, nes bandomasis klientas vis tiek atliks tuos pačius veiksmus su tais pačiais valdikliais.

Automatinio testavimo mechanizmą testuotojai gali naudoti norėdami įrašyti veiksmų, sukeliančių klaidą, seką. Įrašytus duomenis galima siųsti kūrėjams, kad jie ištaisytų aptiktą klaidą.

Automatinis testavimas taip pat gali būti naudojamas norint nustatyti perteklinius užraktus ir aklavietes konfigūracijoje.

Norėdami tai padaryti, turite įdiegti scenarijų, kuris atkuria problemą, ir pradėti ieškoti bei pašalinti priežastį.

Daugelis specialistų ir tiesiog „1C Enterprise 8“ pagrindu pagamintų produktų vartotojų jau turėjo girdėti apie naujo išleidimą programinės įrangos produktas bet kokių (pagal oficialius pareiškimus) konfigūracijų testavimui, o jo pavadinimas yra 1C scenarijaus testavimas 8. Aš tuoj pat paaiškinsiu, kad šis įrankis Tai plėtra tiesiogiai 1C, o ne trečiųjų šalių aktyvistų. Neradau informacijos apie šį gaminį (neskaitant nesibaigiančių pakartotinių spaudinių iš 1C svetainės), iš kurios galėčiau daryti išvadą, kad jo tiesiog nėra. O patį apžvalginį produktą rasti nelengva, bent jau nenorintiems mokėti 30k už licenciją arba jos jau neturintiems kartu su KIP8 pasiūla. Vienaip ar kitaip, bet po tam tikrų išbandymų vis tiek pavyko gauti šį įrankį į savo rankas. O nuo šiol pradėsiu nuo smulkmenų.

Montavimas.

Šiuo metu žinau šiuos oficialius būdus, kaip gauti šį įrankį:

a) Jis įtrauktas į pristatymą „1C: įmonių įrankių paketas 8“.

b) Galima atsisiųsti iš 1C naudotojų palaikymo svetainės.

c) Ankstyvoji versija buvo ITS diske, manau, spalio mėn.

Pati aplikacija sveria apie 2MB, bet dar anksti džiaugtis – norint ją įdiegti, reikia nurodyti kelią iki aplanko su šablonais. Kiek suprantu, šis katalogas yra pagrindinėse konfigūracijose arba bandomajame, kuris pridedamas prie programos. Pirmiausia jį reikėtų įdiegti (~ 90Mb), tada saugiai įdiegsime programą ir ištrinsime nereikalingą konfigūraciją.

Po šių paprastų manipuliacijų gausime katalogą su mus dominančiu įrankiu. Pati programa susideda iš dviejų išorinių *.epf apdorojimų, papildomai pridedamas trumpas aprašymas ir pavyzdinės konfigūracijos demonstracinis testas, kurį pašalinome.

Leiskite man paaiškinti, su kuo man teko dirbti. Gavau 1.2.2.1 versiją, aišku, ne pirminę. Kaip bandomąją konfigūraciją naudojau konfigūraciją, pagrįstą 1C Enterprise 8.1.

Apklausa.

Taigi, kaip jau minėjau, 1C scenarijaus testavimas susideda iš dviejų išorinių apdorojimų: Testų įrašymo ir Testų vykdymo.

Didžiąją dalį informacijos galite rasti integruotame žinyne. Tačiau didelių vilčių į tai nedėjau, parašyta pagal principą „kramt tai, kas akivaizdu, ir nieko kito“. Tačiau, nepaisant to, galite perskaityti bendrą raidą.

Iš pradžių savais žodžiais aprašysiu pagrindinį šio įrankio funkcionalumą, o tada pabandysiu įsigilinti į atskirų funkcijų įgyvendinimą.

Naudodami 1C scenarijaus testavimą galite lengvai kurti dokumentus, katalogus, registrus automatiškai pagal iš anksto parašytą scenarijų, palyginti juos su atskaitos objektais ir pan., tiek vizualiniu režimu, tiek paslėpti nuo testuotojo akių. Įprasto scenarijaus pavyzdį galima pamatyti pirmoje ekrano kopijoje.

Kiekvienas scenarijaus elementas vadinamas žingsniu. Apskritai viskas iš pirmo žvilgsnio akivaizdu ir paprasta, ir, deja, tam tikru mastu apgaulinga. Tačiau apie spąstus kalbėsime kitame skyriuje, bet kol kas sutelkime dėmesį į pagrindines funkcijas.

Ryžiai. 1 Rašymo testų tvarkymas.

Šio įrankio ideologija pagrįsta atskaitos bazės objektų palyginimu su objektais bandomoje bazėje. Tai aiškiai matoma pagrindiniame Testų įrašų apdorojimo lange, kairėje pusėje yra duomenys iš referencinės duomenų bazės, dešinėje yra testai, pagrįsti duomenimis iš kairės. Nuorodų duomenų bazė yra duomenų bazė, kurioje buvo sukurtas testas.

Be pagrindinės aukščiau aprašytos įrankio funkcijos, yra ir nemažai kitų, primityvesnių, bet kartais ne mažiau naudingų. Pavyzdžiui, įrankis gali būti naudojamas tik automatiškai pildyti formas, spustelėti mygtukus, pildyti lentelės dalis ir pan., šie veiksmai imituoja vartotojo darbą interaktyviu režimu. Ir kadangi vartotojo vaidmenį atlieka testeris, tai pasirodo kaip ad hoc testavimas automatiniu režimu.

Priklausomai nuo testuojamo objekto, yra tam tikras tipiškų veiksmų šablonas, sukurtas automatiškai. Čia yra tipiškas pavyzdys: kairėje pusėje pasirinkite konkretų dokumentą (nuorodų knygą ir pan.) ir vilkite jį į dešinę pusę, po to automatiškai sukuriame tipinių žingsnių šabloną. Po to galėsite juos redaguoti kaip norite.

Kiekvieną veiksmą galima atlikti tiesiogiai šiame apdorojime, paspaudus F12. Šis funkcionalumas verčia abejoti, ar reikia antrojo RunTests apdorojimo, manau, būtų logiška ateityje juos sujungti.

Ryžiai. 2 Tvarkymas Bandomasis paleidimas.

Užbaigtas testas įrašomas į xml dokumentą, kurį atidarome bandomoje duomenų bazėje, apdorojant Test Run ir stebime, kaip viskas su mumis gerai.

Antrojo apdorojimo funkcionalumas nesiskiria, atsižvelgiant į tai, kad paleidimą galima atlikti naudojant pirmąjį apdorojimą. Iš naudingų savybių galima paminėti vykdymo protokolo priežiūrą ir atliktų veiksmų žymėjimą.

Žvelgdamas į ateitį, kad negrįžčiau prie šio apdorojimo, pasakysiu, kad buvau pritrenktas vietoje. Esant visoms reikalingoms ir nelabai galimybėms, nebuvo vietos bandomojo paleidimo režimui su klaidų ignoravimu. Dėl ko labai nemalonu atlikti neigiamus testus ir apskritai testavimą. Esant menkiausiam neatitikimui, mūsų „automatinis“ apdorojimas patenka į stuporą.

Dabar apsvarstykite šios sistemos naudojimo privalumus ir trūkumus lauko sąlygomis.

Naudojimo ypatybės.

Remiantis oficialiais pareiškimais, „1C Scenario Testing“ turėtų būti universalus įrankis, suderinamas su įvairiomis konfigūracijomis. Manau, kad mano konfigūracija yra puiki šio teiginio bandymo aikštelė.

Iš karto pasakysiu, kad darbo su šiuo įrankiu procesas negali būti vadinamas paprastu ir ramiu. Beveik kiekviename žingsnyje (visomis prasmėmis) tenka eksperimentuoti su iš pažiūros akivaizdžiais dalykais.

Štai keletas dalykų, su kuriais man teko susidurti:

  1. Dėl tam tikrų priežasčių, naudojant įvairias testavimo žingsnių parinktis, nėra jokio žingsnio apdorotam objektui ištrinti. Iš pradžių turėjau naudoti veiksmą „Apdoroti“ ir rankiniu būdu parašyti kodą, kad pašalinčiau objektus. Galiausiai nusprendžiau kol kas apsieiti be jo ir dirbti su esamais duomenimis.
  2. Vienas iš naudingiausių, mano nuomone, yra žingsnis „Judesio palyginimas su standartu“. Štai ko trūko. Dabar galima sekti visus neplanuotus operacijų pokyčius.
    Šį žingsnį reikia labai tiksliai sureguliuoti. Pavyzdžiui, turime sekti dokumento judėjimą keturiuose registruose, ir kiekvienas iš jų turi savo laukų ir analizės rinkinį. Yra verčių, kurios pasikeis, kai objektas pasikeis, ir tai nebus klaida. Pavyzdžiui, toks laukas kaip TimeStamp, kuriame įrašomas dokumento laikas arba dokumento numeris, jei jis priskiriamas automatiškai. Visi tokie momentai sukels klaidą atliekant testą. Gerai, kad kūrėjai tai numatė ir leido išjungti nepastovio lauko patikrą. Tiesiog turime rasti tokius laukus.
    Tačiau ir čia neapsieita be spąstų. Pavyzdžiui, kažkodėl mano žingsnių nustatymo formoje, jei rodomas daugiau nei vienas registras, tai judesiai ant jų nerodomi, turiu išjungti papildomus ir kiekvieną registrą konfigūruoti atskirai.
    O kas man visai nepatiko. Kaip pavyko suprasti, registrais tikrinami tik tie judesiai, kurie yra standarte. Pavyzdžiui, jei standarte yra vienas laidas, o išbandytoje duomenų bazėje - trys, tada lyginant klaidų nebus. Nes visame registre ieškoma operacijos su nuorodos parametrais, jei viskas gerai, tai likusių, susijusių su tuo pačiu objektu, buvimas registre nesekamas.
  3. Scenarijus pagrįsti automatinio užbaigimo veiksmai ne visada veikia tinkamai. Nuorodos laukuose ir datose dažnai pasitaiko klaidų. Labiau tikėtina, kad tai ne įrankio klaida, o laukų ypatybė, tačiau vis tiek turėsite keisti jų nustatymus.
  4. Galimi veiksmai yra susieti su konkrečiais konfigūracijos objektais. Tai, kas prieinama katalogams, gali būti neprieinama registrams ir pan. Tiksliau būtų sakyti, kad įrišimas yra veikiau ne prie daiktų, o su jų ypatybėmis, pavyzdžiui, jei registre nėra formos, tada jos pildyti nebus žingsnio.
    Tačiau yra ir klaidų, pvz., „Paspauskite mygtuką“ veiksmas man dažnai nepasiekiamas, tiksliau, galima pasirinkti patį pasirinkimą, bet nieko neatsitiks.
  5. Kai kuriais ypač painiais atvejais lieka tik daug klausimų apie testavimo automatizavimą. Tai ypač pasakytina apie dokumentus, kuriuose dirbama su likučiais, kur beveik visi momentai atlieka svarbų vaidmenį, kai kuriuos iš jų labai sunku įveikti dabartiniame įrankio diegime. Konfigūracijoje yra keletas apribojimų, leidžiančių kurti dokumentus tą pačią dieną, tuo pačiu numeriu ir pan. kol kas apsisprendžiau naudoti esamus objektus nekurdamas naujų.

Šį sąrašą galima tęsti ir tęsti, bet tegul tai daro šio gaminio bandytojai. Pagrindinis dalykas, kurį supratau ir bandau perteikti, yra tai, kad „nemokamų nebus“. Norėdami įdiegti testavimo automatizavimą, kai pagrindinis vaidmuo tenka šiam gaminiui, turėsite paprakaituoti ne vieną dieną. Žinoma, mano analizė yra grynai subjektyvi, gali turėti įtakos ir gaminio naudojimo patirties trūkumas bei konfigūracijos ypatybės, bet, kaip sakoma, turime tai, ką turime, ir nuo to nepabėgsi.

Taikymo parinktys.

Šiuo metu sau pasirinkau tokią koncepciją, kaip įvesti nagrinėjamą įrankį į testavimo procesą.

Remdamasis dabartine eksploatavimo patirtimi, esu įsitikinęs, kad etaloninė bazė ir bandymų bazė turi būti identiški duomenų atžvilgiu. Natūralu, kad jei kalbame apie scenarijus, kurie naudoja esamus objektus jų nekeisdami, o nekuria naujų. Pirma, tai suteiks mums tuos pačius likučius abiejose bazėse, o tai labai svarbu tikrinant apyvartas. Antra, tai suteiks tam tikrą patikimumą ir tam tikrą apsaugą nuo nereikalingų klaidų, nes. Vis dar iki galo nesupratau ryšio tarp informacinių duomenų ir duomenų bazių, įvairių nuorodų ir pan., mane kankina neaiškūs įtarimai, kad gali būti kažkokie ryšiai, kurie vieną gražią akimirką pavirs į negyvų nuorodų raizginį, tu negali išnarplioti.

Taigi, turime atskaitos bazę, pagal kurią kūrėme scenarijus visoms progoms. Kūrimo konfigūracijos dokumente yra pataisymų, kuriuos reikia išbandyti. Kaip taisyklė - rankiniu būdu. Po to konfigūracija su pakeitimais įkeliama į testavimo bazę, o scenarijai paleidžiami visiems arba tik gretimiems objektams, siekiant išsiaiškinti, ar dokumento pakeitimas turėjo įtakos kitiems objektams. Po to konfigūracija laikoma perspektyvia ir įdiegta darbo bazėje. Po to modifikuoto dokumento testavimo scenarijus iš darbinės duomenų bazės pakeičiamas į naują standartą.

Kitaip tariant, pagal šiuos scenarijus atliekame regresijos testavimą. Ir tai yra vienas iš svarbiausių ir sunkiausiai rankiniu būdu įgyvendinamų testavimo tipų „1C Enterprise“. Juk labai dažnai keičiasi ne tik dokumentas, bet, tarkime, dokumento talpinimo funkcija, kuri yra susieta su visais sistemos dokumentais, čia mūsų scenarijai atliks tinklo vaidmenį, į kurį visi dokumentai nepavyks nukris.

Kitas geras panaudojimas būtų patikrinti, ar darbinėje bazėje nėra atsitiktinių klaidų. Norėdami tai padaryti, iš jo paimama atsarginė kopija, įkeliama į kokią nors testų duomenų bazę ir vykdomas visas testų ciklas. Ši procedūra būtų malonu tai padaryti automatiniu režimu, tačiau 1C scenarijaus testavimas nenumato bandymų paleidimo pagal grafiką, bent jau kol kas.

Tai, žinoma, nesibaigia šio įrankio taikymo sfera, galimybės Jų yra daug, tik išvardijau pirmuosius, kurie atėjo į galvą.

Išvada.

Šis įrankis tikrai turi ateitį. Man atrodo, kad didžioji jo potencialo dalis dar turi būti atskleista vėlesnėse versijose ir, be jokios abejonės, produktas suras savo vartotoją, kurio, mano nuomone, matyt, nesutampančia su gamintojo nuomone, bus daugiau. greičiausiai ne paprastas vartotojas, neturintis specifinių IT srities žinių, o žmogus iš plėtros skyriaus. Nes efektyviai naudoti šį įrankį - ne labiausiai paprasta užduotis ypač sudėtingose ​​konfigūracijose.

Norint sukurti ir derinti scenarijų ST, yra specialus apdorojimas. Apdorojimą iš CT galima iškrauti komanda Administracija – „Išsaugoti apdorojimą faile“.

Norėdami sukurti naują scenarijų, pasirinkite Prisijunkite prie bandomos programos ir sukurkite naują scenarijų.

Norėdami įrašyti ir derinti scenarijus, turite paleisti dvi duomenų bazės sesijas: „Testing Manager“ (toliau MT) ir „Testing Client“ (toliau CT).

MT valdo CT, įrašo vartotojo veiksmus ir leidžia užbaigti scenarijų. KT reikalinga pačiam scenarijui atkurti ir vartotojo veiksmams atlikti.

Paleidžiant CT, turite nurodyti paleidimo parametrus (ryšio tipas 1C, vartotojas ir kt.):

Pradėjus KT, galite pradėti įrašyti vartotojo veiksmus. Norėdami tai padaryti, apdorojant MT įjungiame įrašą.

Galite atkurti veiksmus KT.

Atlikę veiksmus CT, paspauskite įrašymo sustabdymo mygtuką MT:

Komanda „Įrašyti ir uždaryti“ įrašyti veiksmai perkeliami į scenarijų:

Apatinė eilutė: „Scenario Testing 3.0“ konfigūracija, naudojant teisingą ir meistrišką požiūrį, leidžia greitai ir efektyviai įrašyti interaktyvius vartotojo veiksmus, užtenka tiesiog modifikuoti ir derinti scenarijus. Norint sukurti interaktyvius scenarijaus žingsnius, nebūtina būti programuotoju. Pakanka žinoti ir suprasti, kaip naudoti paruoštą sprendimą.

P.S.: Geriau neleisti scenarijų pagal Taxi sąsają, nes kartais scenarijus neveikia tinkamai.

Panašūs įrašai