1c ssenari testi 8. Vaxtını gündəlik işlərə sərf etdiyinə görə peşman olanlar üçün sınaq alətləri

1C Test Mərkəzi 8, sistemin işini qiymətləndirməyə və informasiya sisteminin darboğazlarını öyrənməyə imkan verən 1C-dən ixtisaslaşmış proqram məhsuludur.

Əvvəllər biz xüsusi konfiqurasiyaya baxmışdıq. İndi biz istifadəçilər tərəfindən çox istifadəçi konfiqurasiya testi üçün ssenarilər yaratmağı və testin özünü necə həyata keçirməyi öyrənəcəyik.

1C Test Mərkəzində sınaq skripti xüsusi yaradılmış emal daxilində yazılır. Bu şablon konfiqurasiya daxilində yerləşir, onun “TCTestProcessingTemplate” adı var. Öz test skriptinizi yaratmaq üçün bu şablonu kopyalamalı və onun əsasında öz yeni şablonunuzu yaratmalısınız, gəlin buna “Malların yenidən göndərilməsi qəbzi” deyək:

Gəlin emala yeni bir atribut əlavə edək və onu formada göstərək - “DocumentForCopying”, bu, kopyalayacağımız sənəddir.

Forma moduluna daha yaxından nəzər salaq. Orada üç prosedurdan istifadə edə bilərsiniz - TCIinitialize (), TTSExecute (), Delete ().

TCIinitialize - ilkin olaraq infobase parametrlərini doldurmaq üçün istifadə olunur, məsələn, uçot siyasətinin doldurulması.
TCExecute test skriptinin birbaşa yazıldığı əsas moduldur.
TCUDeleteData test prosesi zamanı yaradılmış obyektlərin silinməsini təsvir edən moduldur.

Ən sadə kodu TCExecute() proseduruna yazaq, o, seçilmiş sənədi ard-arda 5 dəfə kopyalayacaq və hər bir sənədin surətinin çıxarılmasını və yerləşdirilməsini ölçəcək:

th=1-dən 5-ə qədər Dövr üçün

Alətlər = KipExternalComponent.GetTools();
StartTime = KipExternalComponent.TimerValue(Alətlər);

1C-də 267 video dərsi pulsuz əldə edin:

Sənədlər yarat();

EndTime = KipExternalComponent.TimerValue(Alətlər);
İcra müddəti = (Bitmə vaxtı - Başlama vaxtı) / 1000;

TCWriteIndicator("İcra müddəti", İcra müddəti);

EndCycle;

TCExecutionResultSuccessfully qaytarın();

CreateDocuments() proseduru serverdə yerinə yetiriləcək:

Sənədlərin yaradılması proseduru()

NewDocument = TCObject.DocumentForCopying.Copy();
NewDocument.Date = CurrentDate();
NewDocument.Write(DocumentWriteMode.Post);

EndProcedure

İndi skriptin hazırlanması başa çatıb, yük testini aparmaq üçün Test Mərkəzinə keçək.

1C Test Mərkəzinin qurulması 8.3

Testi yazdıqdan sonra biz Test Mərkəzinin özünü qurmağa başlayacağıq. Konfiqurasiya etmək üçün bir sıra istinad kitablarını doldurmalısınız:

Müalicələr— sınaqla əlaqəli proseslərin siyahısını ehtiva edən kataloq. Emal həm daxili, həm də xarici ola bilər.
Rollar— emal-emal parametrləri keçidinin saxlanması üçün kataloq. Parametrlər hər bir test üçün fərdi olan məlumatlardır (iterasiyaların sayı, kopyalanan sənəd və s.).
İstifadəçilər— istifadəçilərin siyahısı və onların parolları.
Kompüterlər— testin aparılacağı kompüterlərin siyahısı.
Müştərilər - yük testinin harada, kimdən və hansı rejimdə başlanacağının qurulması.

Test Ssenariləri

Bütün parametrləri birləşdirən əsas istinad kitabı: neçə dəfə, hansı istifadəçi tərəfindən, hansı adla yüklənmə testi aparılacaq.

Həmçinin "Parametrlər" sekmesinde texniki sınaq ssenarisini konfiqurasiya edə bilərsiniz:

Skripti qurduqdan sonra onu işə salmaq qalır.

1C-də sınaqların başlaması: Test Mərkəzi

Hər şey hazır olduqda, test işinə başlamaq qalır.

Bunu etmək üçün proqramın ən azı iki seansını işə salmalısınız: birincisi - sözdə rolunda. “agent”, ikincisi isə skriptin işə salınmasının təşəbbüskarı kimi.

Agentin işə salınması:

Skriptin icrası:

Çalıştırmaq üçün sadəcə siyahıdan istədiyiniz skripti seçin və Run düyməsini sıxın.

1C "Ssenari Testi" tətbiq həllinin sınaq versiyasını buraxdı (bax: http://www.1c.ru/news/info.jsp?id=8893)

Əslində, bu, 8.1 platformasında konfiqurasiyalar üçün funksional sınaq sistemidir.

O, iki xarici prosesdən ibarətdir “RecordTests.epf” və “RunTests.epf”.

Testlər xml faylları kimi saxlanılır.

Xüsusiyyətlər "1C: Ssenari Testi 8"

Əsas Xüsusiyyətlər

“1C: Ssenari Testi 8” istifadə edərək, “1C: Müəssisə 8” sisteminin istənilən konfiqurasiyasının funksionallığını yoxlamaq üçün testlər yaza və işlədə bilərsiniz. Alət iki xarici müalicədən ibarətdir. Bir emal testi qeyd etmək üçün, ikinci emal isə testi həyata keçirmək üçün nəzərdə tutulub. Qeydə alınmış test ya əllə, həm də avtomatik olaraq həyata keçirilə bilər.
Bu alətdən istifadə edərək testlər hazırlamaq üçün istifadəçi səviyyəsində sınaqdan keçirilən konfiqurasiyanın işləməsi haqqında biliklər kifayət qədər proqramlaşdırma bacarıqları tələb olunmur;
Test istifadəçinin proqramda yerinə yetirməli olduğu hərəkətlər toplusudur. Bunlar, məsələn, kataloqların, sənədlərin yeni elementlərinin yaradılması, formada məlumatların doldurulması və ya düymələrin basılması kimi hərəkətlər ola bilər. Belə bir test avtomatik olaraq həyata keçirildikdə, istifadəçinin məlumat daxil etmə işi simulyasiya edilir. Obyektlərin interaktiv yaradılması və formaların doldurulması üçün test əmrlərinin icrasının 1C: Enterprise 8 platforması tərəfindən istifadəçinin bu məlumatları klaviaturadan daxil etdiyi kimi emal edilməsi vacibdir.
Bənzər sınaq prinsipi digər proqramlarda da mövcuddur, lakin onlardan fərqli olaraq, bu alət 1C: Enterprise 8 konfiqurasiyalarının sınaqdan keçirilməsinin xüsusiyyətlərini əks etdirən test inkişaf imkanlarını həyata keçirir. Belə imkanlara aşağıdakılar daxildir:

müxtəlif konfiqurasiya obyektləri üçün formaların doldurulması üçün şablonların yaradılması (onlar fərdiləşdirilə və eyni konfiqurasiyanın müxtəlif testləri üçün istifadə edilə bilər);

istinad konfiqurasiya bazasında hansı obyektlərin hansı test addımları ilə əlaqəli olduğunun təhlili;

qeydə alınmış testin yerinə yetirilməsindən əvvəl düzgünlüyünün təhlili;

avtomatlaşdırılmış test keçirərkən səhvi əl ilə atmaq və testi avtomatik rejimdə davam etdirmək imkanı;

sənədin hərəkətinin istinad verilənlər bazası məlumatları ilə avtomatik müqayisəsi;

testin yaratdığı obyektlərin istinad məlumat bazasının məlumatları ilə zəruri müqayisəsi;

testi qeyd edərkən addımları aradan qaldırmaq imkanı;

konfiqurasiya obyektlərinin sınaq əhatə dairəsinin təhlili.

Testi həyata keçirmək üçün sınaqdan keçirilən konfiqurasiyanın xüsusi hazırlanması tələb olunmur.

1C-dən istifadə: Ssenari testi 8

Eyni testdə siz müxtəlif biznes əməliyyatlarını yoxlamaq üçün addımlar yarada bilərsiniz. Test məntiqi istifadəçi sənədlərinə uyğun olaraq proqramda iş əməliyyatlarının əks etdirilməsi qaydaları ilə təsvir olunur. Beləliklə, alət ssenari və ya konfiqurasiyaların funksional testi üçün istifadə edilə bilər.
Bu cür sınaqlara ehtiyac, konfiqurasiya funksionallığını dəyişdirərkən və ya səhvləri düzəldərkən, dəyişməz qalan konfiqurasiya funksionallığının işlək qaldığından əmin olmaq lazım olduqda yaranır. Bu, yeni konfiqurasiya buraxılışlarının inkişafı, onların sınaqdan keçirilməsi və buraxılması iterativ olduğu təşkilatlarda daha çox tələb olunur. Bu halda, testlərin yazılması və onların daha da avtomatlaşdırılması xərcləri hər bir yeni konfiqurasiya buraxılışının əl ilə reqressiya sınağı ilə müqayisədə daha az olacaq.
Bir qayda olaraq, bu cür testlər istifadəçilər tərəfindən tətbiq həlli ilə işləmək üçün ən çox istifadə edilən ssenarilər üçün yazılır, onlar dəyişdirilmiş konfiqurasiyanın və ya platformanın hər bir yeni versiyasında icra olunur; Tətbiq həllinin müəyyən bir funksionallığında səhvlərin kritikliyindən və təşkilatın sınaqlara sərf etməyə hazır olduğu vaxtdan asılı olaraq testlər daha mürəkkəb və ya daha az mürəkkəb edilə bilər.
"1C: Ssenari Testi 8" aşağıdakılar tərəfindən istifadə edilə bilər:

Tərəfdaşlar – dövriyyə həlləri hazırlayanlar;

İşçi verilənlər bazasını yeniləməzdən əvvəl konfiqurasiyanı yoxlamaq vəzifəsi olan tərəfdaşlar və ya istifadəçilər.

al

2010.01.05-ci il tarixli 1C qiymət siyahısından xətt

Məhsulun tərkibi və satış proseduru
Proqram məhsulu 2900000998513 "1C: Ssenari testi 8 NFR" daxildir:

testlərin hazırlanması və icrası üçün emal;

"1C: Enterprise 8" tipik konfiqurasiyaları üçün testlər toplusu;

qeydiyyat kartı;

sənədləşdirmə kitabı "1C: Ssenari Testi 8. İstifadəçi Təlimatı".

Məhsul 2900000998513 "1C: Ssenari testi 8 NFR" platforma və ya hər hansı tətbiq həlli üçün "1C: Müəssisə 8" üçün ən azı bir mütəxəssisi olan françayzi tərəfdaşlarına hər təşkilat üçün bir dəst olan NFR məhsullarının alınması ərizələrində satılır. ". Məhsulun işləməsi üçün tərəfdaşın 1C: Enterprise 8 platforması və təhlükəsizlik açarı daxil olmaqla istənilən NFR çatdırılması olmalıdır.
Məhsul 4601546061393 "1C: Ssenari Testi 8" platforma və ya hər hansı "1C: Enterprise 8" tətbiq həlli üçün ən azı bir mütəxəssisi olan françayzinq tərəfdaşları vasitəsilə "1C: Enterprise 8" PROF versiyası proqram məhsullarının istifadəçilərinə satılır.
Məhsulların təyinatı və istifadə şərtləri
Məhsul 2900000998513 "1C: Ssenari testi 8 NFR" tərəfdaşlar tərəfindən təklif olunan alətlərin imkanlarını öyrənmək, tərəfdaşın daxili inkişaflarında qeyri-məhdud istifadə etmək, həmçinin tərəfdaşın ərazisində müştəri üçün həyata keçirilən icra işləri üçün nəzərdə tutulub. Lisenziya NFR məhsulunu sınaq üçün istifadə etməyə imkan verir:

satış üçün hazırlanmış öz məhsulları;

standart konfiqurasiyalara dəyişikliklər;

müştərilərə məhsulların təqdim edilməsi işinin bir hissəsi kimi, əgər bu iş tərəfdaşın yerli şəbəkəsində aparılırsa.

Lisenziya məhsulun konfiqurasiyanı birbaşa müştərinin ərazisində sınaqdan keçirmək və ya müştəri və ya başqa təşkilat tərəfindən hazırlanmış və təkrarlanan konfiqurasiyanı sınaqdan keçirmək üçün istifadə edilməsinə icazə vermir. Belə işi həyata keçirmək üçün müştəri üçün 4601546061393 "1C: Ssenari Testi 8" məhsulunu almaq lazımdır.
Tətbiqin həyata keçirildiyi təşkilat tərəfindən satın alınan 4601546061393 "1C: Ssenari Testi 8" məhsulu həyata keçirən tərəfdaşın təşkilatında konfiqurasiyanı sınaqdan keçirmək üçün istifadə edilə bilməz. Belə işi yerinə yetirmək üçün tərəfdaş 2900000998513 "1C: Ssenari testi 8 NFR" məhsulunu almalıdır.

ST-də skriptin işlənib hazırlanması və sazlanması üçün xüsusi emal var. İdarəetmə bölməsindəki əmrdən istifadə edərək emal ST-dən endirilə bilər - "Emalı faylda saxla".

Yeni skript hazırlamaq üçün “Sınaq altında olan proqrama qoşulun və yeni skript yaradın” seçimini etməlisiniz.

Skriptləri qeyd etmək və sazlamaq üçün iki verilənlər bazası sessiyasını işə salmalısınız: “Test Meneceri” (bundan sonra MT) və “Test Müştərisi” (bundan sonra CT).

MT CT-yə nəzarət edir, istifadəçi hərəkətlərini qeyd edir və skripti dəyişdirməyə imkan verir. CT ssenarinin özünü təkrar etmək və istifadəçi hərəkətlərini yerinə yetirmək üçün lazımdır.

CT-ni işə salarkən işəsalma parametrlərini (1C bağlantısının növü, istifadəçi və s.) təyin etməlisiniz:

KT işə salındıqdan sonra siz istifadəçi hərəkətlərini qeyd etməyə başlaya bilərsiniz. Bunun üçün biz MT emalında rekord daxil edirik.

CT-də hərəkətləri təkrarlaya bilərsiniz.

CT-də hərəkətləri tamamladıqdan sonra MT-də qeydi dayandırın düyməsini basın:

"Qeyd et və bağla" əmrindən istifadə edərək qeydə alınan hərəkətlər skriptə köçürülür:

Nəticə: Düzgün və bacarıqlı yanaşma ilə “Ssenari Testi 3.0” konfiqurasiyası sizə istifadəçinin interaktiv hərəkətlərini tez və effektiv şəkildə qeyd etməyə və sadəcə olaraq skriptləri dəyişdirməyə və debug etməyə imkan verir. İnteraktiv skript addımlarını inkişaf etdirmək üçün ixtisaslı proqramçı olmaq lazım deyil. Hazır bir həllin necə istifadə ediləcəyini bilmək və anlamaq kifayətdir.

P.S.: “Taksi” interfeysi altında skriptləri işə salmamaq daha yaxşıdır, çünki skript düzgün işləməyə bilər.

Ssenari testi mövzusu çoxdan əhatə olunub və demək olar ki, hər bir şirkət TDD və BDD-dən bu və ya digər dərəcədə istifadə etmək zərurətindən xəbərdardır. 1C tərtibatçılarından ibarət kiçik qrupumuz da istisna deyildi. Bununla belə, ehtiyacın dərk edildiyi andan texnologiyanın real istifadəsinə qədər vaxt keçir və bu yolda, məsələn, bu məqalənin müəllifi kimi kövrək beyinlər bütün bu ideyanın effektivliyi haqqında düşünməyə başlayırlar. Bir qrup ağıllı oğlanın işlərində ssenari testinə bənzər bir şeyi necə təqdim etdikləri ilə maraqlanırsınızsa, xoş gəlmisiniz.

Fon

Bazarda çox güclü və yetkin UI test alətləri var. Skriptləri təsvir etmək üçün xüsusi dillər, bir çox sənədləşdirmə və metodologiya var. Başqa sözlə, “Bir problem varmı? Bir həll yolu var!"

Digər tərəfdən, problemin həllinə sərf olunan enerji, bütövlükdə komandanın istehsal etdiyi enerji ilə bir növ uyğun olmalıdır. Amma praktikada, əgər iri şirkətlər proseslərin tam inkişaf etdirilməsi ilə fərdi QA mütəxəssis(lər)ini və testçilərini heyətdə saxlamaq imkanına malik olsalar, kiçik ofislər həmişə bunu edə bilmirlər, bəzi funksiyalar onlara həvalə edilməlidir. özləri və prosesin özünün fəlsəfəsi bir qədər təhrif edilmişdir.

Beləliklə, verilmişdir: 10 nəfərə qədər coğrafi olaraq paylanmış 1C tərtibatçıları qrupu, orta hesabla 5-ə qədər aktiv layihə, əsasən standart 1C məhsullarından istifadə etmədən xüsusi həllərin inkişafı.

Məqsəd: interfeysin və iş məntiqinin işini yoxlamaq daxil olmaqla, inkişaf testi proseslərini mümkün qədər səmərəli şəkildə həyata keçirmək. Effektivlik, sınaqlara sərf olunan vaxtın son nəticə baxımından hələ də məna kəsb etdiyi zaman balansa aiddir. Etiraf edirəm ki, bu xətt çox subyektivdir və bəlkə də "isti ilə yumşaq müqayisə cəhdi" ifadəsini tamamilə əsaslandırır. Düşünürəm ki, oxucu ssenari testinin hansı məqsədlərə xidmət etdiyini müəllifdən daha yaxşı bilir.

Qərb istehsalçılarının bir sıra alət sistemlərini, həmçinin 1C versiyası 3.0 və xUnitFor1C-dən ssenari testlərini öyrəndikdən sonra belə görünürdü ki, biz hələ bu texnologiyaların tətbiqi üçün kifayət qədər zehni olaraq yetişməmişik. Zaman keçdi, amma biz hələ də böyüyə bilmirik. Eyni zamanda, bağırsaqlarım heç olmasa bir növ həll yolu tələb edir və tələb edirdi.

Köhnə qeydləri götürdükdən sonra potensial proqram məhsulu üçün tələblərin siyahısı bir daha tərtib edildi:

Həll bulud əsaslı olmalıdır
Bütün inkişaflar üçün test bazası vahid olmalıdır
Tətbiqlərə giriş nəzarəti olmalıdır (hər bir proqramçının öz inkişaf hovuzu var)
Testin inkişafı və icrası bir IDE-də olmalıdır
Skriptlər istifadəçi hərəkətləri ilə deyil, proqramlaşdırılmalıdır
Test proqramlaşdırma dilinin 1C dilinə oxşar olması arzu edilir
Testlər ilkin manipulyasiyalar, kompilyasiyalar, montajlar, yükləmələr, yükləmələr və s. olmadan bir düymə ilə başlamalıdır.
Testin yazılması prosesində 1C idarə olunan interfeys modeli baxımından sınaqdan keçirilən proqramın pəncərələrinin strukturunu və detallarını təhlil etmək mümkün olmalıdır və bu, testin özünün işlənib hazırlandığı proqramda olmalıdır. Sınaq bazasında nəzarət elementləri ağacından keçərkən sınaqdan keçirilən tətbiqin sahələrinin xassələrini əldə etmək mümkün olmalıdır - sınaqdan keçirilən proqram cavab verməli və bu nəzarətin harada olduğunu göstərməlidir.
İş məntiqini yoxlamaq üçün istinad bazasından istifadə edilməməlidir
Testi inkişaf etdirmək üçün xüsusi hazırlanmış bir baza olmamalıdır, bütün testlər özləri işləməli və lazım olan hər şeyi yaratmalıdırlar

Təbii ki, siyahı tam deyil və bu və ya digər dərəcədə digər proqram məhsullarında mövcuddur. Bu, gənclik maksimalizmi kimi görünə bilər, ancaq bütün bu şərtlər bir məhsulda yerinə yetirildiyi təqdirdə vəziyyətimizdə ssenari testini tətbiq etmək mümkün olduğunu gördük. Həmkarlar mənimlə razılaşmaya bilər, lakin mən hesab edirəm ki, testlərin keyfiyyət və kəmiyyətində əsas məsələlərdən biri tətbiqin davamlı inkişafı zamanı bu testlərin nə qədər tez və rahat şəkildə həyata keçirilə bilməsidir.

Yəqin ki, daha altı ay keçdi və nəhayət, mən növbəti sınaq velosipedini (bundan sonra tester adlandırılacaq) ləng, isteğe bağlı rejimdə hazırlamağa qərar verdim və bundan belə çıxdı.

Nə kimi görünür

Nəticədə, 1C əsaslı həllər üçün ssenari testlərinin yazıldığı və icra edildiyi 1C əsaslı bir tətbiq yarandı. Gündəlik istifadə belə bir şeydir: proqramçı bütün günü ikinci monitorunda test cihazını açıq saxlayır. Layihə mühasibat bazasında menecer layihəni əhatə etməli olan məcburi testlər toplusunu təyin edir.

Hər bir tapşırıq üçün proqramçı tərəfindən yerinə yetirilməli olan bir sıra standart, məcburi testlər də var. Məsələn, sənəd əsaslı şəkildə daxil edilirsə, giriş əsasında test olmalıdır. Başqa sözlə, proqramçı hansı testlərin yaradılması lazım olduğunu bilir.

Testlər nə vaxt yazılır?

Təcrübədə, işlərin yarısında testlərin yazılması inkişaf prosesi zamanı baş verir (tətbiq hər dəfə yenidən işə salındıqda eyni hərəkətləri təkrarlamaq lazım olduqda, rutinlərin avtomatlaşdırılması üçün çox əlverişlidir). Digər yarıda - sonra. Təcrübəli oxucunun yəqin ki, fərqinə vardığı kimi, bu vəziyyəti çətin ki, klassik BDD adlandırmaq olar.

Test nümunəsi

Deyək ki, “Sənəd hazırlayın, komplektin yığılması” layihəsi var. Bu sənəd anbar filtri olan siyahı formasını tələb edir. Baxılan həlldə siyahıların necə işləməsi ilə bağlı ümumi konsepsiya aşağıdakı kimi qəbul edilir: əgər filtr quraşdırılıbsa, sənədləri filtr dəyərinə görə seçməklə yanaşı, buradan yeni sənəd daxil edərkən seçim dəyərinin standart dəyər kimi xidmət etməsi tələb olunur. bu forma. Beləliklə, anbar quraşdırılıbsa, yeni sənəd daxil edildikdə avtomatik olaraq quraşdırılmalıdır.

Yalnız ilk baxışdan belə bir ssenari üçün testə ehtiyac olmadığı görünür, lakin sənədləri daxil etmək üçün müxtəlif variantları nəzərə alaraq, Anbar sahəsi fərqli dəyərləri qəbul edə bilər. Axı, sənəd kopyalana bilər və ya istifadəçinin standart parametrlərdə göstərilən başqa bir şirkəti var və filtrdə seçilmiş anbar onun təşkilati vahidi deyil. Bu və ya digər şəkildə, test belə görünəcək (komandamızda əcnəbilər var, buna görə test cihazının özü ingilis dilində yazılmışdır və sözügedən tətbiq həlli Amerika müştəriləri üçün nəzərdə tutulmuşdur):

Yuxarıda inkişaf etdirilən proqram, aşağıda tester, nazik müştəri rejimində, buludda test verilənlər bazası var. Gördüyünüz kod 1C dilində yazılmışdır. Skript kodu sınaqdan keçirilən 1C tətbiqinin metod sarğıları vasitəsilə işləyən müştəri proqramı ilə qarşılıqlı əlaqədə olur, məsələn, Seç (...) metodu belə görünür;

Test cihazında demək olar ki, bütün interfeys əməliyyatlarını həyata keçirməyə çalışdım, lakin konkret bir şeyə ehtiyacınız olsa belə, siz həmişə sınaqdan keçirilən sahənin obyektini əldə edə və onun üzərində sınaqdan keçirilən tətbiqin modelində həyata keçirilən istənilən metodları icra edə bilərsiniz.

Gəlin daha maraqlı ssenarilərə keçək.

Test əlaqəsi

Əvvəlki nümunədə olduğu kimi, montaj sənədini yaratmaq və yerləşdirmək üçün bir ssenari hazırlamaq üçün çoxlu əlavə məlumatlara sahib olmalıyıq: kataloqların lazımi tərkibi, anbarda qalan materiallar, ən azı bəzi sənədlərin olması deməkdir. anbara gəliş növü. Daha əvvəl dediyim kimi, biz özümüz qərara gəldik ki, testlər heç bir istinad bazası olmayan şəraitdə aparılmalıdır, tətbiqin yalnız ilkin görüntüsü var, burada inzibati hüquqlara, tamamlanmış təsnifatçılara və standart dəyərlərə malik ən azı bir istifadəçi var. rahat ilk iş istifadəçisi üçün.

Bununla birlikdə, hər dəfə "yol boyu" bütün lazımi məlumatları yaradacaq tam bir skript yazmaq səmərəsiz olacaqdır. Mən yalnız bir şeyi necə edəcəyini bilən deyil, həm də parametrləri qəbul edən parametrləşdirilmiş bir test hazırlamaq istərdim. Məsələn, verilənlər bazasında qəbz yaratmaq üçün onu yaradacaq test olmalıdır. Və heç bir şey bizə bu testi parametrləşdirməyə və bütün lazımi məlumatları ona ötürməyə mane olmur, məsələn, gəlişi hansı tarixə təyin etməliyik, hansı anbara getməliyik və hansı materialları/xidmətləri almalıyıq. Öz növbəsində, qəbz yaratmaq üçün test anbar yaratmaq üçün testlərdən, qablaşdırma növü, növü, çevrilmə amilləri və s. parametrlərdə gözlənilən materiallardan istifadə edəcəkdir.

Tətbiqimiz bulud əsaslı olduğundan və test bazası vahid olduğundan, hər bir proqramçı müəyyən bir test hazırlayarkən, birbaşa bir şey üçün test yazmaq prosesində onu parametrləşdirə və digər proqramçılar tərəfindən geniş istifadə üçün aça bilər.

Assembling yaradılması testinin qəbul üçün necə hazırlandığına dair bir nümunə:

(məsələn, triad və fraksiya ayırıcısının fərqli ola biləcəyi fərqli bir yerdə işlədilibsə, testin yanlış pozitivləri ilə bağlı problemlərin qarşısını almaq üçün qiymətlər, məbləğlər və kəmiyyətlər sətirlər kimi göstərilmişdir)

Bu testin icrası zamanı bir sıra digər sınaqlar aparılacaq ki, bu da Assembling-i belə sınaqdan keçirmək üçün lazım olan hər şeyi yaradacaq. Nəticənin verilənlər bazasında olacağı təxminən budur:

Biznes məntiqinin sınaqdan keçirilməsi

Bütün düymələrin sıxılması və sahələrin seçilməsi bir yana, əgər mən sənədlərin işlənməsi mexanizmlərinin nəticələrini sınaqdan keçirməsəydim və verilənlər bazasında mövcud uçot vəziyyətini qiymətləndirməsəydim, sınaq hadisəsi ürəyimdə dərin iz buraxacaqdı.

Etiraf etməliyəm ki, mən uzun müddət beynimi bir istinad bazası olmadan asan və sadə bir şəkildə necə həyata keçirmək barədə düşünmüşəm. Hesabat testi ilə birlikdə sənəd hərəkətlərini yoxlamaqdan daha yaxşı bir şey tapmadım.

Test edilən tətbiqdə sənəd hərəkətləri haqqında hesabat nümunəsi:

Tester bu hərəkətləri necə yoxlayacaq:

Qırmızı sahələr yoxlamaq üçün vacibdir. Sahələrə əlavə olaraq, tester şablondan istifadə edərək yoxlanılacaq sahələri təyin edə bilər.

Standart yoxlamalar

Çox vaxt eyni tipli obyektləri yoxlamaq vəzifəsi yaranır. Məsələn, işlərin yarısında sənəd formalarının cədvəl hissəsi olur və sətirləri köçürərkən, birinci sətri silərkən və ya birinci/sonrakı sətirləri daxil etmək və daxil etməkdən imtina edərkən proqram xətalarına tez-tez yol verilir. Bu məqsədlə müstəqil skripti olmayan, ancaq yerli zənglər üçün istifadə edilən test metodunu hazırlamaq mümkündür. Bu, çox rahatdır, çünki zaman keçdikcə bu cür testlər digər sınaq elementləri əlavə etməklə genişləndirilə bilər ki, bu da belə testlərin geniş tətbiqi hesabına tətbiqin əhatə dairəsinin avtomatik genişlənməsinə səbəb olur.

Xəta Nəzarəti

Nəzarət etmək istədiyimiz ən azı üç növ səhv var. Birinci növ kodlaşdırma xətalarıdır, məsələn, sıfıra bölmə, mövcud olmayan xassə və ya metoda giriş. İkinci növ səhvlər məntiqdəki səhvlərdir, məsələn, düyməni basdıqda forma bağlanmalıdır, lakin bu baş vermir və ya qutuyu yoxlayanda formanın bir hissəsi əlçatmaz və ya görünməz hala gəlməlidir. Üçüncü növ səhvlər, biznes məntiqi səhvləri, məsələn, anbardan material yazarkən, məlumat bazasında mövcudluğunu müəyyən etmək mümkün deyildi. Hər üç növ səhv test cihazında işlənə bilər. Tetiklendiğinde, tester istisnanı qeyd edir, onu jurnala yazır və zəng yığınını göstərə bilər, məsələn:

Biznes məntiqi səhvlərini idarə etmək üçün bir sıra üsullar da tətbiq edilmişdir. Məsələn, testiniz bilərəkdən daha çox material yazmaq istəyir və siz mesajın düzgün formalaşıb-qalılmayacağını, yoxsa ümumiyyətlə formalaşıb-olmadığını yoxlamaq istəyirsiniz.

Testlərdən birində belə bir yoxlamanın həyata keçirilməsinə bir nümunə:

Element ağacının təhlili

Tester test edilən tətbiqin vizual obyektlərini oxuya bilər. Bu, skript yazmaq üçün rahatdır və bəzən sadəcə zəruridir, xüsusən də çoxdilli həllər üçün, burada düymələrin adları istifadəçinin dilindən asılıdır və interfeysi inkişaf etdirmək üçün daxili identifikatordan istifadə etməlisiniz (əlbəttə ki, tapşırıq yoxdursa). düymələrdəki etiketlərin sintaksisini yoxlamaqdır). Test cihazının oxunan məlumatları necə təqdim etdiyinə dair bir nümunə:

Nəticə

Ümumiyyətlə, 1C proqramçısına kömək etmək üçün kiçik bir velosiped olduğu ortaya çıxdı. Proqramın müsbət keyfiyyətləri kimi aşağıdakıları qeyd etmək olar:

Test cihazı quraşdırmaq və konfiqurasiya etmək asandır
Əvvəlcə çox istifadəçidir (istifadəçilər həm də test cihazında, idarəetmə alt sistemində yaradılır)
Testləri yazmaq üçün xüsusi biliyə ehtiyac yoxdur
Sizə mürəkkəb iş məntiqi ssenarilərini həyata keçirməyə imkan verir
Müxtəlif layihələr üçün minlərlə testi bir verilənlər bazasında saxlamağa və onlardan "yenidən istifadə etməyə" imkan verir. Məsələn, bütün layihələr üçün ümumi olan siyahıda bir sənədin axtarışı üçün test yarada bilərsiniz. Və ya müştəri bazası artıq sınaqlar olan bəzi standart həll əsasında həyata keçirilirsə, bütün ana testləri, üstəlik müştəri üçün xüsusi hazırlanmış testləri çağıraraq müştəri bazasını yoxlaya bilərsiniz.

Və əlbəttə ki, hələ çox şey həyata keçirilməyib:

Test proqramı yoxdur
Təkmil təhlil sistemi, qrafiklər və sınaq nəticələrinə dair hesabatlar yoxdur
Nəyin pozulduğu, kim tərəfindən və niyə sındırıldığı barədə avtomatik göndərişlər və ya bildirişlər yoxdur
Repozitoriyalar və testlərin versiyalaşdırılması ilə heç bir əlaqə yoxdur

Test cihazı açıq və pulsuzdur, onu 8.3.8-dən başlayaraq işə salmaq məsləhətdir, lakin uyğunluq rejimini aktivləşdirsəniz, 8.3.7-də də işləyəcək. İçərisində kiçik köməklik var (internetdən yüklənib), metod sarğılar da rus dilindədir, dt-kitabı buradan yükləmək olar. Korporativ uçot 3.0 üçün bir neçə nümunə var.

Testlərinizdə uğurlar, dostlar və diqqətinizə görə təşəkkür edirik!

Teqlər:

BDD
ssenari testi

Teqlər əlavə edin

Bir çox mütəxəssis və sadəcə olaraq 1C Enterprise 8-ə əsaslanan məhsulların istifadəçiləri artıq hər hansı (rəsmi açıqlamalara görə) konfiqurasiyaları sınaqdan keçirmək üçün yeni proqram məhsulunun buraxılması haqqında eşitməli idilər və onun adı 1C Ssenari Testi 8-dir. Dərhal aydınlaşdırım ki, bu alət üçüncü tərəf fəalları deyil, birbaşa 1C şirkəti tərəfindən hazırlanmışdır. Bu məhsul haqqında məlumat tapa bilmədim (1C veb saytından sonsuz təkrar nəşrlərdən başqa), ondan belə nəticəyə gələ bilərəm ki, sadəcə mövcud deyil. Və nəzərdən keçirilən məhsulun özünü tapmaq asan deyil, ən azı lisenziya üçün 30k ödəmək istəməyənlər və ya alətlərin təchizatı ilə birlikdə ona sahib olmayanlar üçün8. Bu və ya digər şəkildə, bəzi sınaqlardan sonra bu alətə əl atmağı bacardım. Və bu andan daha ətraflı başlayacağam.

Quraşdırma.

Hazırda bu aləti əldə etməyin aşağıdakı rəsmi yollarını bilirəm:

a) "1C: Korporativ Alət Paketi 8" çatdırılmasına daxildir.
b) 1C istifadəçi dəstəyi saytından endirilə bilər.
c) ITS diskində erkən versiya mövcud idi, deyəsən oktyabr ayından.

Tətbiqin özü təxminən 2 MB ağırlığındadır, lakin sevinmək üçün hələ tezdir - onu quraşdırmaq üçün şablonları olan qovluğa gedən yolu göstərməlisiniz. Anladığım kimi, bu kataloq əsas konfiqurasiyalarda və ya proqrama daxil olan test konfiqurasiyasında mövcuddur. Əvvəlcə (~90MB) quraşdırılmalıdır, sonra yardım proqramı təhlükəsiz şəkildə quraşdırırıq və daha lazımsız konfiqurasiyanı silirik.

Bu sadə manipulyasiyalardan sonra biz maraqlandığımız alətlə bir kataloq alacağıq. Proqramın özü iki xarici *.epf emalından ibarətdir, əlavə olaraq qısa təsvir və sildiyimiz göstərici konfiqurasiya üçün demo testi əlavə olunur.

Nə ilə işləməli olduğumu aydınlaşdırım. Mən 1.2.2.1 versiyasını aldım, açıq-aydın əsas deyil. Test konfiqurasiyası olaraq 1C Enterprise 8.1-ə əsaslanan konfiqurasiyadan istifadə etdim.

Debrifinq.

Beləliklə, artıq qeyd etdiyim kimi, 1C Ssenari testi iki xarici emaldan ibarətdir: RecordTests və RunTests.

Əksər məlumatı daxili yardımda tapmaq olar. Bununla belə, mən buna böyük ümid bəsləməzdim, o, “açıq olanı açaq, başqa heç nə” prinsipi ilə yazılmışdı. Ancaq buna baxmayaraq, ümumi inkişaf üçün oxuya bilərsiniz.

Başlamaq üçün bu alətin əsas funksionallığını öz sözlərimlə təsvir edəcəyəm və sonra fərdi funksiyaların həyata keçirilməsini araşdırmağa çalışacağam.

1C Ssenari Testindən istifadə edərək, əvvəlcədən yazılmış skriptə uyğun olaraq asanlıqla avtomatik olaraq sənədlər, qovluqlar, registrlər yarada, onları həm vizual rejimdə, həm də sınaqçının gözündən gizlədilmiş istinad obyektləri ilə müqayisə edə və s. Tipik bir ssenarinin nümunəsini ilk ekran görüntüsündə görmək olar.

Skriptdəki hər bir nöqtə bir addım adlanır. Ümumiyyətlə, hər şey ilk baxışdan aydın və sadədir və təəssüf ki, müəyyən dərəcədə aldadıcıdır. Bununla belə, biz növbəti hissədə tələlərdən danışacağıq, lakin hələlik əsas imkanlara diqqət yetirəcəyik.

düyü. 1 Qeyd Testləri Emal olunur.

Bu alətin ideologiyası istinad bazasındakı obyektlərin sınaqdan keçirilmiş verilənlər bazasındakı obyektlərlə müqayisəsinə əsaslanır. Bu, RecordTestlərin işlənməsi üçün əsas pəncərədə aydın görünür, sol tərəfdə istinad verilənlər bazasından məlumatlar, sağda sol tərəfdəki məlumatlara əsaslanan testlər var. İstinad verilənlər bazası testin yaradıldığı verilənlər bazasıdır.

Yuxarıda təsvir olunan alətin əsas funksiyasına əlavə olaraq, daha ibtidai, lakin bəzən daha az faydalı olmayan bir sıra başqaları var. Məsələn, alət yalnız formaları avtomatik doldurmaq, düymələri sıxmaq, cədvəl hissələrini doldurmaq üçün istifadə edilə bilər və bu addımlar istifadəçinin interaktiv rejimdə işini simulyasiya edir; İstifadəçinin rolunu tester oynadığından, avtomatik rejimdə bir növ ad hoc testi olduğu ortaya çıxır.

Sınaq edilən obyektdən asılı olaraq avtomatik olaraq yaradılan tipik addımların nümunəsi var. Tipik bir nümunə: sol tərəfdə müəyyən bir sənəd (kataloq və s.) seçin və onu sağ tərəfə sürükləyin, bundan sonra avtomatik olaraq tipik addımların şablonu yaradılır. Sonra onları istədiyiniz kimi redaktə edə bilərsiniz.

Hər bir addım F12 düyməsini basaraq bu emalda birbaşa yerinə yetirilə bilər. Bu funksionallıq RunTest-in ikinci işlənməsi ehtiyacını şübhə altına alır, məncə, gələcəkdə onları birləşdirmək məntiqli olardı;

düyü. 2 RunTestlərin işlənməsi.

Hazır test xml sənədinə yazılır, biz onu RunTest emal vasitəsilə sınaqdan keçirilən verilənlər bazasında açırıq və hər şeyin bizim üçün necə yaxşı işlədiyini müşahidə edirik.

İkinci emalın funksionallığı fərqli deyil, nəzərə alsaq ki, qaçış birinci emal ilə də həyata keçirilə bilər. Bəzi faydalı xüsusiyyətlərə icra qeydinin aparılması və tamamlanmış addımların qeyd edilməsi daxildir.

İrəliyə baxaraq, bir daha bu emala qayıtmamaq üçün deyəcəm ki, yerindəcə heyran qaldım. Bütün zəruri və o qədər də zəruri olmayan seçimlərlə, səhvlərə məhəl qoymayan bir sınaq rejimi üçün yer yox idi. Bu, mənfi testlər və ümumiyyətlə testlər aparmağı son dərəcə xoşagəlməz edir. Ən kiçik uyğunsuzluq görünəndə "avtomatik" emalımız stupor vəziyyətinə düşür.

İndi isə bu sistemin sahədə istifadəsinin müsbət və mənfi tərəflərinə baxaq.

İstifadə xüsusiyyətləri.

Rəsmi açıqlamalara görə, 1C Ssenari testi müxtəlif konfiqurasiyalara uyğunluq baxımından universal bir vasitə olmalıdır. Düşünürəm ki, mənim konfiqurasiyam bu ifadə üçün əla sınaq yatağıdır.

Dərhal deyim ki, bu alətlə işləmə prosesini sadə və sakit adlandırmaq olmaz. Demək olar ki, hər addımda (hər mənada) zahirən aşkar şeylərlə sınaqdan keçirməlisən.

Budur, öhdəsindən gəlməli olduğum bəzi şeylər:

Nədənsə, test addımları üçün bütün müxtəlif variantlarla işlənmiş obyekti silmək üçün heç bir addım yoxdur. Əvvəlcə “Proses” addımından istifadə etməli və obyektləri silmək üçün əl ilə kod yazmalı oldum. Sonda indilik onsuz etmək və mövcud məlumatlarla işləmək qərarına gəldim.
Ən faydalılarından biri, məncə, “Hərəkəti standartla müqayisə et” addımıdır. Bu çatışmayan şeydi. İndi planlaşdırılmamış əməliyyatlardakı bütün dəyişiklikləri izləmək mümkündür.
Bu addım çox incə tənzimləmə tələb edir. Məsələn, biz dörd registr üzrə sənədin hərəkətini izləməliyik və onların hər birinin öz sahələri və analitikası var. Obyekt dəyişdikdə dəyişəcək dəyərlər var və bu xəta olmayacaq. Məsələn, sənədin işləndiyi vaxtı və ya avtomatik olaraq təyin edildiyi təqdirdə sənəd nömrəsini qeyd edən TimeStamp kimi bir sahə. Bütün belə anlar testi həyata keçirərkən xətaya səbəb olacaq. Tərtibatçıların bunu nəzərə almaları və qeyri-sabit bir sahə üçün yoxlamanı söndürməyə imkan vermələri yaxşıdır. Bizə ancaq belə sahələri tapmaq qalır.
Bununla belə, burada da bəzi tələlər var. Məsələn, mənim addım quraşdırma formamda nədənsə, birdən çox registr göstərilirsə, o zaman onlar üçün hərəkətlər göstərilmir, mən əlavələri söndürməli və hər bir registri ayrı-ayrılıqda konfiqurasiya etməliyəm.
Və ümumiyyətlə bəyənmədiyim şey. Başa düşdüyüm kimi, yalnız standartda olan hərəkətlər registrlərlə yoxlanılır. Məsələn, əgər standartda bir əməliyyat, sınaqdan keçirilmiş verilənlər bazasında isə üç əməliyyat varsa, o zaman müqayisə zamanı NO XƏT OLMAYACAQ. Çünki Bütün reyestrdə istinad parametrləri olan qeydlər axtarılır, əgər hər şey qaydasındadırsa, reyestrdə eyni obyektlə əlaqəli digərlərinin olması izlənmir.
Skript əsasında formaların avtomatik doldurulması addımları həmişə düzgün işləmir. Səhvlər tez-tez istinad sahələrində və tarixlərdə baş verir. Bu, çox güman ki, bir alət səhvi deyil, sahələrin bir xüsusiyyətidir, lakin buna baxmayaraq onların parametrləri ilə məşğul olmalı olacaqsınız.
Mümkün addım seçimləri xüsusi konfiqurasiya obyektləri ilə əlaqələndirilir. Kataloqlar üçün mövcud olanlar registrlər üçün olmaya bilər və s. Bağlanmanın daha çox obyektlərə deyil, onların xüsusiyyətlərinə aid olduğunu söyləmək daha düzgün olardı, məsələn, reyestrdə forma yoxdursa, onu doldurmaq üçün bir addım olmayacaq.
Ancaq səhvlər də var, məsələn, "Bir düyməni basın" addımı mənim üçün çox vaxt əlçatmazdır, daha doğrusu, seçim özü edilə bilər, amma heç nə olmayacaq.
Bəzi xüsusilə mürəkkəb hallarda testin avtomatlaşdırılması ilə bağlı çoxlu suallar qalır. Bu, xüsusilə qalıqlarla işləyən sənədlər üçün doğrudur, burada demək olar ki, bütün aspektlər mühüm rol oynayır, bəziləri alətin cari tətbiqində həyata keçirmək çox problemlidir. Eyni tarixdə, eyni nömrə ilə və s. sənədlərin yaradılması üçün konfiqurasiyada bir sıra məhdudiyyətlər var. İndiyə qədər mən yeni obyektlər yaratmadan mövcud obyektlərdən istifadə etməyi qərara almışam.

Bu siyahını uzatmaq olar, lakin bu məhsulu sınaqdan keçirənlərə icazə verin. Başa düşdüyüm və çatdırmağa çalışdığım əsas odur ki, “pulsuzluq olmayacaq”. Baş rolda bu məhsulla sınaq avtomatlaşdırmasını həyata keçirmək üçün bir gündən çox çox çalışmalı olacaqsınız. Təbii ki, mənim təhlilim sırf subyektivdir və məhsuldan və konfiqurasiya xüsusiyyətlərindən istifadə təcrübəsinin olmaması da buna təsir edə bilər, lakin, necə deyərlər, bizdə olanlar var və bundan qaçmaq mümkün deyil.

Tətbiq seçimləri.

Hazırda sözügedən aləti sınaq prosesinə daxil etmək üçün aşağıdakı konsepsiyanı seçmişəm.

Mövcud əməliyyat təcrübəsinə əsaslanaraq, mən əminəm ki, istinad bazası və test bazası məlumat baxımından eyni olmalıdır. Təbii ki, söhbət mövcud obyektləri dəyişdirmədən istifadə edən və yenisini yaratmayan skriptlərdən gedirsə. Birincisi, bu, bizə hər iki bazada vahid balanslar verəcək və bu, dövriyyəni yoxlamaq üçün çox vacibdir. İkincisi, bu, müəyyən bir etibarlılıq və lazımsız səhvlərdən bir qədər qorunma təmin edəcəkdir, çünki Mən hələ də istinad məlumatları ilə verilənlər bazaları, müxtəlif keçidlər və s. qarışmamış.

Beləliklə, bütün hallar üçün ssenarilər yaratdığımız bir istinad bazamız var. İnkişaf konfiqurasiyasındakı bəzi sənədlərdə sınaqdan keçirilməli olan düzəlişlər edilmişdir. Bir qayda olaraq - əl ilə. Bundan sonra dəyişikliklərlə konfiqurasiya test verilənlər bazasına yüklənir və sənəddəki dəyişikliyin digər obyektlərə təsir edib-etmədiyini öyrənmək üçün bütün və ya yalnız bitişik obyektlər üçün skriptlər işə salınır. Bundan sonra konfiqurasiya etibarlı hesab olunur və işləyən verilənlər bazasında quraşdırılır. Bundan sonra dəyişdirilmiş sənəd üçün sınaq skripti işçi verilənlər bazasından yeni standarta dəyişdirilir.

Başqa sözlə, biz bu ssenarilərlə reqressiya testi həyata keçiririk. Və bu, 1C Enterprise-də ən vacib və əl ilə həyata keçirilməsi çətin sınaq növlərindən biridir. Axı, çox tez-tez təkcə sənəd deyil, məsələn, sistemin bütün sənədlərinə qoşulan sənəd yerləşdirmə funksiyası da dəyişir və burada bizim skriptlərimiz uğursuz olan bütün sənədlərin daxil olduğu bir şəbəkə rolunu oynayacaq. düşəcək.

Başqa bir yaxşı istifadə iş verilənlər bazasını təsadüfi səhvlər üçün yoxlamaq ola bilər. Bunun üçün ondan ehtiyat nüsxə götürülür, bəzi test verilənlər bazasına yüklənir və testlərin tam dövrü aparılır. Bu proseduru avtomatik həyata keçirmək yaxşı olardı, lakin 1C Ssenari Testi ən azı hələ ki, cədvəl üzrə testlərin aparılmasını təmin etmir.

Təbii ki, bu alətin tətbiq dairəsi bununla bitmir;

Nəticə.

Bu alətin, şübhəsiz ki, gələcəyi var. Mənə elə gəlir ki, onun potensialının böyük hissəsi hələ sonrakı versiyalarda aşkar edilməmişdir və şübhəsiz ki, məhsul öz istifadəçisini tapacaq, mənim fikrimcə, istehsalçının fikri ilə üst-üstə düşməyən, çox güman ki, İT sahəsində xüsusi biliyi olmayan adi istifadəçi olmayın və şəxs inkişaf şöbəsindəndir. Çünki Bu alətdən səmərəli istifadə, xüsusən də mürəkkəb konfiqurasiyalarda ən asan məsələ deyil.