1C: სცენარის ტესტირება. სატესტო ინსტრუმენტები მათთვის, ვინც ბოდიშს გიხდით დროის რუტინაზე დაკარგვის გამო, როგორ გამოიყურება ეს

სტატიაში განხილულია ახალი ავტომატური ტესტირების მექანიზმი, რომელიც პირველად გამოჩნდა პლატფორმაზე 8.3 გამოცემაში. სტატიის მასალის შესწავლის შემდეგ გაიგებთ:

• რა არის ავტომატური ტესტირება პლატფორმაზე?
• როგორ და როდის გამოვიყენოთ იგი?
• რა და სად უნდა იყოს კონფიგურირებული მისი გასაშვებად?
• როგორ დავწეროთ ავტომატური ტესტის სკრიპტი?

გამოყენებადობა

სტატიაში განხილულია 1C:Enterprise პლატფორმის ვერსია 8.3.4.465. პლატფორმის მიმდინარე ვერსიაში, ავტომატური ტესტირების მექანიზმის შესაძლებლობები მნიშვნელოვნად გაფართოვდა, მაგრამ ამან არ იმოქმედა სტატიის მასალის შესაბამისობაზე. ის კვლავ აქტუალურია.

ავტომატური ტესტირება 1C: Enterprise 8.3-ში

1C:Enterprise 8.3 პლატფორმას აქვს ახალი მექანიზმი, რომელიც შექმნილია სისტემის მომხმარებლების ინტერაქტიული მოქმედებების სიმულაციისთვის - ავტომატური ტესტირება.

ავტომატური ტესტირება არ უჭერს მხარს ჩვეულებრივ ინტერფეისით მუშაობას, მაგრამ მხოლოდ მართულ ინტერფეისს.

ტესტირებისას გამოიყენება კლიენტის აპლიკაციების ორი ტიპი - ტესტის მენეჯერი და ტესტის კლიენტი. ტესტის მენეჯერი ამყარებს კავშირს ტესტის კლიენტთან და ახორციელებს ტესტის სკრიპტს.

ტესტის სკრიპტი არის კოდი ჩაშენებულ ენაში, რომელიც აღწერს შესასრულებელი ინტერაქტიული მოქმედებების თანმიმდევრობას.

ამისათვის ჩაშენებულ ენას დაემატა ახალი ობიექტები, რომლებიც აღწერს აპლიკაციის ინტერფეისს აბსტრაქტულ დონეზე (ფანჯრის, ფორმის, კონტროლის და ა.შ.) და ასევე აღწერს მომხმარებლის ქმედებებს (კონფიგურაციის ნავიგაცია, მონაცემთა შეყვანა. და ა.შ.).

ტესტის მენეჯერი შეიძლება იყოს სქელი ან თხელი კლიენტი. სატესტო კლიენტი - სქელი კლიენტი, თხელი კლიენტი ან ვებ კლიენტი.

სატესტო მენეჯერი შეიძლება იყოს დაკავშირებული რამდენიმე სატესტო კლიენტთან, ხოლო ტესტის კლიენტი შეიძლება იყოს დაკავშირებული მხოლოდ ერთ მენეჯერთან.

კლიენტის სამართავად, მენეჯერი ამყარებს მასთან TCP კავშირს. მნიშვნელოვანია, რომ ავტომატური ტესტირება არ საჭიროებს ცვლილებებს კონფიგურაციის სტრუქტურაში.

არსებითად, სატესტო კლიენტი და მენეჯერი არის კონფიგურაციები, რომლებიც გაშვებულია ბრძანების ხაზის გარკვეული პარამეტრებით, მენეჯერი მართავს კლიენტებს ფანჯრებისა და კონტროლის ღილაკების მოქცევით ისე, თითქოს მომხმარებელი მათთან ურთიერთობს.

ავტომატურ ტესტირებას აქვს თავისი შეზღუდვები. ასე რომ, მაგალითად, ჩვეულებრივ ინტერფეისთან მუშაობა არ არის მხარდაჭერილი, მაგრამ მხოლოდ მართულთან.

ავტომატური ტესტირების ჩასატარებლად, უნდა მუშაობდეს როგორც ტესტის მენეჯერი, ასევე ტესტის კლიენტი.

მენეჯერის გაშვება შესაძლებელია ბრძანების ხაზიდან /TESTMANAGER კლავიშით:

"c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F "X:\test" /N ადმინისტრატორი /TESTMANAGER

ასევე, ტესტის მენეჯერის გაშვება შესაძლებელია კონფიგურატორიდან.

ამისათვის მენიუს საშუალებით Tools - Options გახსენით "Options" დიალოგი, რომელშიც გაშვება 1C: Enterprise - Advanced ჩანართზე შეამოწმეთ პუნქტი "Run as test manager":

ტესტის მენეჯერის დასაწყებად კიდევ ერთი გზა არის ჩაშენებული ენიდან StartSystem() მეთოდის გამოყენებით, რომელშიც უნდა მიუთითოთ ბრძანების ხაზი:

StartSystem ("c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F X:\test /N ადმინისტრატორი /TESTMANAGER")

ტესტის კლიენტი ასევე შეიძლება გაშვებული იყოს ბრძანების ხაზიდან. ამისათვის გამოიყენეთ /TESTCLIENT ბრძანების ხაზის შეცვლა.

TPort პარამეტრი განსაზღვრავს პორტის ნომერს, რომლის მეშვეობითაც მენეჯერი და ტესტირების კლიენტი ურთიერთქმედებენ. თუ ეს პარამეტრი არ არის მითითებული ბრძანების ხაზში, გამოყენებული იქნება პორტი 1538.

"c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F "X:\Platform8Demo" /N ადმინისტრატორი /TESTCLIENT -TPort 1539

სატესტო კლიენტის გაშვება შესაძლებელია კონფიგურატორიდან. ამისათვის მენიუს საშუალებით Tools - Options გახსენით "პარამეტრების" დიალოგი, რომელშიც ჩანართზე Launch 1C: Enterprise - Advanced შეამოწმეთ პუნქტი "Run as a test client". ამ შემთხვევაში, თქვენ უნდა მიუთითოთ გამოყენებული პორტის ნომერი.

გაითვალისწინეთ, რომ სატესტო კლიენტთან დასაკავშირებლად, თქვენ უნდა იცოდეთ ორი პარამეტრი: კომპიუტერის IP მისამართი (ან სახელი), რომელიც მუშაობს სატესტო კლიენტზე და TCP პორტის ნომერი, რომელზეც განხორციელდება კომუნიკაცია.

ორივე სხვადასხვა ინფობაზის გამოყენება შესაძლებელია როგორც მენეჯერად, ასევე სატესტო კლიენტად (ტესტის მენეჯერის მონაცემთა ბაზის კონფიგურაცია შეიძლება არ ემთხვეოდეს ტესტირების კლიენტის კონფიგურაციას) ან იგივე ინფო ბაზა.

ავტომატური ტესტირების ჩასატარებლად, თქვენ უნდა შეასრულოთ შემდეგი ნაბიჯები:

1. შექმენით სატესტო სკრიპტი - ჩაწერეთ გარე ან ჩაშენებული დამუშავება კონფიგურაციაში, რომელიც თანმიმდევრულად აღწერს შესასრულებელ ნაბიჯებს.
2. გაუშვით ტესტის მენეჯერი.
3. გაუშვით სატესტო კლიენტი (ერთი ან მეტი).
4. ტესტირების მენეჯერში გაუშვით შექმნილი დამუშავება შესასრულებლად, დარწმუნდით, რომ დაპროგრამებული მოქმედებები შესრულებულია კლიენტზე.

ტესტირებადი აპლიკაცია აღწერილია 1C: Enterprise ენის ობიექტების ნაკრებით, რომლებიც გამოიყენება სკრიპტის დასაწერად:

• ტესტირებული აპლიკაცია;
• TestedWindowClientApplication;
• TestedCommandInterfaceWindow;
• TestedCommandInterfaceGroup;
• TestedButtonCommandInterface;
• TestedForm;
• TestedFormField;
• TestedFormGroup;
• TestedFormButton;
• TestedFormTable;
• გამოცდილი დეკორაციის ფორმა.

როგორც სატესტო კონფიგურაცია, ჩვენ გამოვიყენებთ "მართული აპლიკაციის" დემო კონფიგურაციას.

შევქმნათ გარე დამუშავება, დავამატოთ ახალი ფორმა, რომელშიც განვსაზღვრავთ დამმუშავებელს ახალი "RunTesting" ბრძანებისთვის.

ტესტში ჩვენ ვასრულებთ შემდეგ მოქმედებებს: შევქმენით დირექტორია "საწყობების" ახალი ელემენტი, სახელის ველში შეიყვანეთ ხაზი "საწყობის ტესტი", შემდეგ დააჭირეთ ღილაკს "შენახვა და დახურვა".

ამ ტესტის კოდი ასე გამოიყურება:

&კლიენტი
Პროცედურა RunTesting(გუნდი)
// დაუკავშირდით სატესტო აპლიკაციას
შემოწმებული აპლიკაცია= ახალი შემოწმებული აპლიკაცია("localhost");
// დაკავშირების მცდელობა არა უმეტეს ერთი წუთის განმავლობაში
დასრულების დრო ლოდინი= CurrentDate() + 60 ;
დაკავშირებული = მცდარი;
ხოლო Not CurrentDate() >= დასრულების დრო ლოდინიციკლის მცდელობა
TestedApplication.SetConnection();
დაკავშირებული = ჭეშმარიტი;
გაუქმება ;
გამონაკლისი
ბოლო ცდა ; ბოლო ციკლი ; თუ არ არის დაკავშირებული მაშინ
// ტესტის დასრულება
შემოწმებული აპლიკაცია= განუსაზღვრელი;
მოხსენება ( "Ვერ ვუკავშირდები!");
Დაბრუნების ;
Დაასრულე თუ ;
// იპოვნეთ მთავარი ფანჯარა
MainWindowTested
=(ტიპი());
MainWindowTested.გააქტიურება();
// შეასრულეთ ბრძანება პროდუქტის დირექტორიაში ელემენტის შესაქმნელად
Tested.RunCommand-ის მთავარი ფანჯარა("e1cib/command/Catalog.Warehouses.Create");
TestedApplication.ExpectObjectDisplay(ტიპი ( "ტესტირებული ფორმა"), "სტოკი*" );
ტესტირებული ფორმა= TestedApplication.FindObject(ტიპი ( "ტესტირებული ფორმა"),
"სტოკი*");
TestedForm.გააქტიურება();
// დააყენეთ ახალი პროდუქტის სახელი
FormItem = TestedForm.FindObject(ტიპი ( "TestedFormField"),
"სახელი");
FormElement.გააქტიურება();
FormElement.EnterText(„საწყობის ტესტი“);
// ელემენტის ჩაწერა
FormItem = TestedForm.FindObject(ტიპი ( "FormButton ტესტირება"),
"ჩაწერა და დახურვა");
FormElement.Press();
დასრულების პროცედურა

გაშვების პარამეტრების დიალოგში პირველად შეირჩა მნიშვნელობა „გაშვება როგორც სატესტო მენეჯერი“, Ctrl + F5 კლავიშების კომბინაციის გამოყენებით, დაიწყო მომხმარებლის სესია.

შემდეგ, დიალოგში, შეირჩა მნიშვნელობა "გაშვება როგორც ტესტირების კლიენტი", Ctrl + F5 კლავიშების კომბინაციის გამოყენებით, დაიწყო მომხმარებლის მეორე სესია.

ამრიგად, ჩვენ თავიდან ავიცილეთ საჭირო ბრძანების ხაზის საჭირო პარამეტრების ხელით მითითების აუცილებლობა.

ზემოთ მოცემული კოდი ასრულებს საკმაოდ მარტივ მოქმედებებს, მაგრამ თუ სცენარი უფრო რთული გახდება, კოდის რაოდენობა გაიზრდება, რადგან აუცილებელია მომხმარებლის თითოეული ინტერაქტიული მოქმედების აღწერა.

აქ სამაშველოში მოდის პლატფორმის კიდევ ერთი ახალი ფუნქცია - მომხმარებლის ქმედებების ჟურნალის ჩაწერა.

ამისათვის თქვენ უნდა გაუშვათ აპლიკაცია სპეციალურ რეჟიმში:

დააწკაპუნეთ სურათზე გასადიდებლად.

პროგრამის სათაურში გამოჩნდება რამდენიმე ღილაკი:

ღილაკები განკუთვნილია:

• ჩაწერის დაწყება/შეწყვეტა;
• ჩაწერის შეწყვეტა;
• ჩაწერის დასრულება.

ჩაწერის დასრულების შემდეგ ეკრანზე იხსნება ტექსტური დოკუმენტი, რომელიც წარმოადგენს XML ფაილში შენახული მომხმარებლის ქმედებების თანმიმდევრობას.

დააწკაპუნეთ სურათზე გასადიდებლად.

ჩაწერილი ჟურნალი შეიძლება გარდაიქმნას პროგრამის კოდში, რომელიც შემდეგ შეიძლება გამოყენებულ იქნას სატესტო სკრიპტში.

ამისთვის განკუთვნილია “User Action Log Conversion” დამუშავება (UIlogToScript.epf), რომლის მიღებაც შესაძლებელია ITS ვებსაიტიდან.

დააწკაპუნეთ სურათზე გასადიდებლად.

დამუშავების შედეგად ვიღებთ გენერირებულ კოდს ჩაშენებულ ენაში. ეს კოდი უნდა იყოს ჩასმული ტესტის დამუშავების ფორმის მოდულში.

გაითვალისწინეთ, რომ გენერირებულ კოდში, 999-ზე მეტი ან -999-ზე ნაკლები რიცხვები გამოვა, როგორც ჯგუფის გამყოფი ადგილის გარეშე (მაგალითად, "1234" ნაცვლად "1234").

ეს სიმბოლო ხელით უნდა მოიხსნას მიღებული კოდიდან.

კოდის განყოფილება კლიენტთან კავშირთან ავტომატურად გენერირდება დამუშავებით.

ჩვენს მაგალითში ვიღებთ შემდეგ კოდს:

&კლიენტი
Პროცედურა RunTesting(გუნდი)
ტესტის სცენარი_23_03_2014წ();
დასრულების პროცედურა და კლიენტი
Პროცედურა ტესტის სცენარი_23_03_2014წ() TestApp= ახალი შემოწმებული აპლიკაცია();
დასრულების დრო ლოდინი= CurrentDate() + 60 ;
დაკავშირებული = მცდარი;
აღწერაErrorsConnections= “” ;
ხოლო Not CurrentDate() >= დასრულების დრო ლოდინიციკლი
მცდელობა
TestApplication.SetConnection();
დაკავშირებული = ჭეშმარიტი;
გაუქმება ;
გამონაკლისი
აღწერაErrorsConnections= DescriptionErrors();
ბოლო მცდელობა ;
ბოლო ციკლი ;
თუ არ არის დაკავშირებული მაშინ
TestApp= განუსაზღვრელი;
ანგარიში (+ სიმბოლოები. PS + აღწერაErrorsConnections);
Დაბრუნების ;
Დაასრულე თუ ; ( TestApp);
(TestApp); დასრულების პროცედურა და კლიენტი
Პროცედურა WindowApplicationAccountsCreateButtonდაწკაპუნეთ(TestApp)
WindowApplicationContractors= (ტიპი (
"TestingClientApplicationWindow"), „კონტრაგენტები“ , , 30 );
WindowApplicationAccountsFormAccounts= WindowApplicationAccounts.FindObject(ტიპი (
"ტესტირებული ფორმა"), "კონტრაქტორები");
ღილაკი შექმნა = WindowApplicationAccountsFormAccounts.FindObject(ტიპი (
"FormButton ტესტირება"), "Შექმნა" );
ButtonCreate. დააჭირეთ(); დასრულების პროცედურა და კლიენტი
Პროცედურა WindowApplicationAccountCreateButtonSaveAndClosePress(TestApp) WindowApplicationContractorCreation= TestApplication.FindObject(ტიპი (
"TestingClientApplicationWindow"), "ანგარიში (შექმნა)", , 30 );
WindowApplicationAccountCreationFormAccountCreation=
WindowApplicationAccountCreate.FindObject(ტიპი ( "ტესტირებული ფორმა"),
"ანგარიში (შექმნა)");
ველის სახელი=
(ტიპი (
"TestedFormField"), "სახელი");
FieldName.EnterText("ახალი"); FieldTypePrice = WindowApplicationAccountCreationFormAccountCreation.FindObject(ტიპი (
"TestedFormField"), „ფასის ტიპი“);
FieldPriceType.გააქტიურება(); FieldTypePrice.Select(); FieldViewPrice.WaitFormationDropdownList(); FieldPriceType.PerformSelectionFromSelectionList("ყიდვა"); ღილაკი შენახვა და დახურვა=
WindowApplicationAccountCreationFormAccountCreation.FindObject(ტიპი (
"FormButton ტესტირება"), "ჩაწერა და დახურვა");
ღილაკი Save&Close. დააჭირეთ(); დასრულების პროცედურა

შედეგად სცენარში მყარდება კავშირი ტესტირების კლიენტთან, ველში დაჭერილია ღილაკი "კონტრაქტორების" დირექტორიაში ახალი ელემენტის შესაქმნელად. სახელიშეიყვანება ტექსტი „ახალი“ და ჩამოსაშლელ სიაში „ფასის ტიპი“ აირჩიეთ მნიშვნელობა „ყიდვა“, შემდეგ დააჭირეთ ღილაკს „შენახვა და დახურვა“.

თუ თქვენ გჭირდებათ რამდენიმე სატესტო კლიენტის გამოყენება სცენარში, მაშინ თითოეულ მათგანთან კავშირი და შესრულებული მოქმედებები ცალკე უნდა იყოს აღწერილი.

ტესტის მენეჯერი გამოყენებული იქნება მარტო და ორი კლიენტი დაკავშირებულია მას სხვადასხვა პორტზე.

ვინაიდან სატესტო სკრიპტი მუშავდება, რომლის პროგრამის კოდის სტრიქონები შესრულებულია თანმიმდევრულად, დეველოპერმა უნდა აღწეროს მოქმედებების თანმიმდევრობა თითოეული კლიენტისთვის.

მოდით უფრო დეტალურად განვიხილოთ, თუ როგორ გამოიყურება კოდი ორი სატესტო კლიენტის გამოყენებისას:

Პროცედურა ტესტის სცენარი_23_03_2014_TwoClients() //პირველი კლიენტი
ტესტის აპლიკაცია 1= ახალი შემოწმებული აპლიკაცია();
დასრულების დრო ლოდინი= CurrentDate() + 60 ;
დაკავშირებული = მცდარი;
აღწერაErrorsConnections= “” ;
ხოლო Not CurrentDate() >= დასრულების დრო ლოდინიციკლი
მცდელობა
TestApplication1.SetConnection();
დაკავშირებული = ჭეშმარიტი;
გაუქმება ;
გამონაკლისი
აღწერაErrorsConnections= DescriptionErrors();
ბოლო მცდელობა ;
ბოლო ციკლი ; //მეორე კლიენტი
TestApp2= ახალი შემოწმებული აპლიკაცია();
დასრულების დრო ლოდინი= CurrentDate() + 60 ;
აღწერაErrorsConnections= “” ;
ხოლო Not CurrentDate() >= დასრულების დრო ლოდინიციკლი
მცდელობა
TestApplication2.SetConnection();
დაკავშირებული = ჭეშმარიტი;
გაუქმება ;
გამონაკლისი
აღწერაErrorsConnections= DescriptionErrors();
ბოლო მცდელობა ;
ბოლო ციკლი ;
თუ არ არის დაკავშირებული მაშინ
ტესტის აპლიკაცია 1= განუსაზღვრელი;
TestApp2= განუსაზღვრელი;
მოხსენება ( "Დაკავშირება ვერ ხერხდება!"+ სიმბოლოები.PS + აღწერაErrorsConnections);
Დაბრუნების ;
Დაასრულე თუ ; //პროცედურები ცალკეა თითოეული ტესტირების კლიენტისთვის
WindowApplicationAccountsCreateButtonPress1(ტესტის აპლიკაცია 1);
WindowApplicationAccountsButtonCreateClick2(TestApp2);
WindowApplicationAccountCreateButtonSave&ClosePress1(ტესტის აპლიკაცია 1);
WindowApplicationAccountCreateButtonSave&ClosePress2(TestApp2); დასრულების პროცედურა

შესრულებულ მოქმედებებს შორის პაუზებიც ცალკე უნდა დაპროგრამდეს. კლიენტების დიდი რაოდენობის სკრიპტი რთულდება.

ასევე, ავტომატური ტესტირება ხელმისაწვდომია მხოლოდ მართული ფორმებისთვის.

თუმცა, ავტომატური ტესტირების უპირატესობა არის ტესტის შემუშავების სიმარტივე და ხილვადობა. ვინაიდან ტესტი მუშაობს მხოლოდ მომხმარებლის ინტერაქტიულ ქმედებებზე, დეველოპერს არ სჭირდება კონფიგურაციის სტრუქტურების ცოდნა ობიექტის ატრიბუტის დონეზე.

თუ შეცვლით, მაგალითად, კონფიგურაციის კოდს, არ არის საჭირო ტესტის ხელახლა გამეორება, რადგან სატესტო კლიენტი კვლავ შეასრულებს იგივე მოქმედებებს იგივე კონტროლებით.

ავტომატური ტესტირების მექანიზმი შეიძლება გამოიყენონ ტესტერებმა შეცდომის გამომწვევი მოქმედებების თანმიმდევრობის ჩასაწერად. ჩაწერილი მონაცემები შეიძლება გაეგზავნოს დეველოპერებს აღმოჩენილი შეცდომის გამოსასწორებლად.

ავტომატური ტესტირება ასევე შეიძლება გამოყენებულ იქნას კონფიგურაციის ზედმეტი ჩამკეტებისა და ჩიხების დასადგენად.

ამისათვის თქვენ უნდა განახორციელოთ სკრიპტი, რომელიც ასახავს პრობლემას და დაიწყოთ მიზეზის პოვნა და გამოსწორება.

ბევრ სპეციალისტს და 1C Enterprise 8-ზე დაფუძნებული პროდუქტების მხოლოდ მომხმარებლებს უკვე უნდა სმენოდათ ახალი პროგრამული პროდუქტის გამოშვების შესახებ ნებისმიერი (ოფიციალური განცხადებების მიხედვით) კონფიგურაციის შესამოწმებლად და მისი სახელია 1C Scenario Testing 8. დაუყოვნებლივ განვმარტავ, რომ ეს ინსტრუმენტი შემუშავებულია უშუალოდ კომპანიის 1C-ის მიერ და არა მესამე მხარის აქტივისტების მიერ. მე ვერ ვიპოვე ინფორმაცია ამ პროდუქტის შესახებ (გარდა გაუთავებელი ბეჭდვისა 1C ვებსაიტიდან), საიდანაც შემიძლია დავასკვნათ, რომ ის უბრალოდ არ არსებობს. და თავად მიმოხილვის პროდუქტის პოვნა ადვილი არ არის, ყოველ შემთხვევაში მათთვის, ვისაც არ სურს ლიცენზიისთვის 30 ათასის გადახდა ან უკვე არ აქვს ის, KIP8-ის მიწოდებასთან ერთად. ასეა თუ ისე, მაგრამ გარკვეული განსაცდელების შემდეგ მაინც მოვახერხე ამ ხელსაწყოს ხელში ჩაგდება. და ამიერიდან დავიწყებ უფრო დეტალურად.

ინსტალაცია.

ამ დროისთვის მე ვიცი შემდეგი ოფიციალური გზები ამ ხელსაწყოს მისაღებად:

ა) ის შედის "1C: კორპორატიული ხელსაწყოების პაკეტი 8" მიწოდებაში.

ბ) ჩამოტვირთვა შესაძლებელია 1C მომხმარებლის მხარდაჭერის ვებსაიტიდან.

გ) ადრეული ვერსია იყო ITS დისკზე, ვფიქრობ ოქტომბრისთვის.

თავად აპლიკაცია იწონის დაახლოებით 2 მბ-ს, მაგრამ ჯერ ნაადრევია გახარება - მისი ინსტალაციისთვის, შაბლონებით უნდა მიუთითოთ საქაღალდისკენ მიმავალი გზა. რამდენადაც მე მესმის, ეს დირექტორია არის ძირითად კონფიგურაციებში, ან საცდელში, რომელიც თან ერთვის პროგრამას. ის პირველ რიგში უნდა იყოს დაინსტალირებული (~ 90 მბ), შემდეგ ჩვენ უსაფრთხოდ დავაინსტალირებთ კომუნალურ პროგრამას და წაშლით უფრო არასაჭირო კონფიგურაციას.

ამ მარტივი მანიპულაციების შემდეგ ჩვენ მივიღებთ კატალოგს ჩვენთვის საინტერესო ხელსაწყოთი. თავად პროგრამა შედგება ორი გარე *.epf დამუშავებისგან, დამატებით დართულია მოკლე აღწერა და დემო ტესტი იმ სამაგალითო კონფიგურაციისთვის, რომელიც ჩვენ წავშალეთ.

ნება მომეცით განვმარტო, რასთან მქონდა მუშაობა. მე მივიღე ვერსია 1.2.2.1, აშკარად არა პირველადი. როგორც სატესტო კონფიგურაცია, მე გამოვიყენე კონფიგურაცია, რომელიც დაფუძნებულია 1C Enterprise 8.1-ზე.

დებრიფინგი.

ასე რომ, როგორც უკვე აღვნიშნე, 1C სცენარის ტესტირება შედგება ორი გარე დამუშავებისგან: ჩაწერის ტესტები და გაშვებული ტესტები.

ინფორმაციის უმეტესი ნაწილი შეგიძლიათ იხილოთ ჩაშენებულ დახმარებაში. თუმცა დიდი იმედი არ მექნებოდა, წერია პრინციპით "დაღეჭე აშკარა და სხვა არაფერი". მაგრამ, მიუხედავად ამისა, შეგიძლიათ წაიკითხოთ ზოგადი განვითარებისთვის.

დასაწყისისთვის, მე ჩემი სიტყვებით აღვწერ ამ ხელსაწყოს მთავარ ფუნქციონირებას, შემდეგ კი შევეცდები ჩავუღრმავდე ინდივიდუალური ფუნქციების განხორციელებას.

1C სცენარის ტესტირების გამოყენებით, თქვენ შეგიძლიათ მარტივად შექმნათ დოკუმენტები, დირექტორიები, დარეგისტრირდეთ ავტომატურად წინასწარ დაწერილი სკრიპტის მიხედვით, შეადაროთ ისინი საცნობარო ობიექტებს და ა.შ., როგორც ვიზუალურ რეჟიმში, ასევე დამალული ტესტერის თვალში. ტიპიური სცენარის მაგალითი ჩანს პირველ სკრინშოტში.

სკრიპტის თითოეულ პუნქტს ეწოდება ნაბიჯი. ზოგადად, ყველაფერი ერთი შეხედვით აშკარა და მარტივია და, სამწუხაროდ, გარკვეულწილად მატყუარა. თუმცა, ჩვენ ვისაუბრებთ ხაფანგებზე შემდეგ ნაწილში, მაგრამ ახლა მოდით ყურადღება გავამახვილოთ ძირითად მახასიათებლებზე.

ბრინჯი. 1 ჩაწერის ტესტების მართვა.

ამ ხელსაწყოს იდეოლოგია ეფუძნება საცნობარო ბაზის ობიექტების შედარებას სატესტო ბაზის ობიექტებთან. ეს აშკარად ჩანს ტესტის ჩანაწერების დამუშავების მთავარ ფანჯარაში, მარცხენა მხარეს არის მონაცემები საცნობარო მონაცემთა ბაზიდან, მარჯვნივ არის ტესტები, რომლებიც დაფუძნებულია მარცხენა მხრიდან. საცნობარო მონაცემთა ბაზა არის მონაცემთა ბაზა, რომელშიც შეიქმნა ტესტი.

გარდა ზემოთ აღწერილი ხელსაწყოს ძირითადი ფუნქციისა, არის კიდევ მრავალი სხვა, უფრო პრიმიტიული, მაგრამ ზოგჯერ არანაკლებ სასარგებლო. მაგალითად, ინსტრუმენტის გამოყენება შესაძლებელია მხოლოდ ფორმების ავტომატური შევსებისთვის, ღილაკების დასაჭერად, ცხრილის განყოფილებების შესავსებად და ა.შ. ეს ნაბიჯები ახდენს მომხმარებლის მუშაობის სიმულაციას ინტერაქტიულ რეჟიმში. და რადგან მომხმარებლის როლს ასრულებს ტესტერი, გამოდის ერთგვარი ad hoc ტესტირება ავტომატურ რეჟიმში.

არსებობს ტიპიური ნაბიჯების გარკვეული ნიმუში, რომელიც ავტომატურად იქმნება ტესტირებადი ობიექტის მიხედვით. აი, ტიპიური მაგალითი: მარცხენა მხარეს აირჩიეთ კონკრეტული დოკუმენტი (საცნობარო წიგნი და ა.შ.) და გადაიტანეთ მარჯვენა მხარეს, რის შემდეგაც ავტომატურად იქმნება ჩვენთვის ტიპიური ნაბიჯების შაბლონი. ამის შემდეგ, თქვენ შეგიძლიათ შეცვალოთ ისინი, როგორც გსურთ.

თითოეული ნაბიჯი შეიძლება შესრულდეს უშუალოდ ამ დამუშავებისას F12 დაჭერით. ეს ფუნქცია ეჭვქვეშ აყენებს RunTests-ის მეორე დამუშავების აუცილებლობას, ვფიქრობ, ლოგიკური იქნება მათი გაერთიანება მომავალში.

ბრინჯი. 2 სატესტო გაშვება.

დასრულებული ტესტი იწერება xml დოკუმენტში, რომელსაც ჩვენ ვხსნით შესამოწმებელ მონაცემთა ბაზაში Test Run-ის დამუშავების გზით და ვაკვირდებით, როგორ არის ყველაფერი ჩვენთან.

მეორე დამუშავების ფუნქციონალობა არ განსხვავდება, იმის გათვალისწინებით, რომ გაშვება შეიძლება გაკეთდეს პირველი დამუშავებით. სასარგებლო თვისებებიდან შეიძლება აღინიშნოს შესრულების პროტოკოლის შენარჩუნება და გადადგმული ნაბიჯების მარკირება.

წინ ვიხედები, რომ ამ დამუშავებას არ დავუბრუნდე, ვიტყვი, რომ ადგილზე დამარტყა. საჭირო და არც თუ ისე ძალიან ვარიანტების მრავალფეროვნებით, არ იყო ადგილი სატესტო გაშვების რეჟიმისთვის, შეცდომების იგნორირება. რა ხდის უკიდურესად არასასიამოვნო უარყოფითი ტესტების ჩატარებას და ზოგადად ტესტირებას. ოდნავი შეუსაბამობის შემთხვევაში, ჩვენი "ავტომატური" დამუშავება სისულელეში გადადის.

ახლა განიხილეთ ამ სისტემის დარგში გამოყენების დადებითი და უარყოფითი მხარეები.

გამოყენების მახასიათებლები.

ოფიციალური განცხადებების თანახმად, 1C სცენარის ტესტირება უნდა იყოს უნივერსალური ინსტრუმენტი სხვადასხვა კონფიგურაციებთან თავსებადობის თვალსაზრისით. მე ვფიქრობ, რომ ჩემი კონფიგურაცია შესანიშნავი ტესტია ამ მტკიცებისთვის.

მაშინვე ვიტყვი, რომ ამ ინსტრუმენტთან მუშაობის პროცესს არ შეიძლება ეწოდოს მარტივი და მშვიდი. თითქმის ყოველ ნაბიჯზე (ყველა გაგებით) თქვენ უნდა აწარმოოთ ექსპერიმენტები ერთი შეხედვით აშკარა საგნებით.

აი, რასთან გამკლავება მომიწია:

1. რატომღაც, სატესტო ნაბიჯების მრავალფეროვნებით, არ არსებობს ნაბიჯი დამუშავებული ობიექტის წაშლისთვის. თავიდან მომიწია "პროცესის" ნაბიჯის გამოყენება და ხელით კოდის დაწერა ობიექტების მოსაშორებლად. საბოლოო ჯამში, გადავწყვიტე ამ დროისთვის მის გარეშე გამეკეთებინა და არსებული მონაცემებით მემუშავა.
2. ერთ-ერთი ყველაზე სასარგებლო, ჩემი აზრით, არის ნაბიჯი "მოძრაობის შედარება სტანდარტთან". ეს არის ის, რაც აკლდა. ახლა შესაძლებელია თვალყური ადევნოთ ყველა ცვლილებას ტრანზაქციებში, რომლებიც არ იყო დაგეგმილი.
   ამ საფეხურს ძალიან დახვეწილი რეგულირება სჭირდება. მაგალითად, ჩვენ უნდა დავაკვირდეთ დოკუმენტის მოძრაობას ოთხ რეესტრში და თითოეულ მათგანს აქვს საკუთარი ველები და ანალიტიკა. არის მნიშვნელობები, რომლებიც შეიცვლება ობიექტის შეცვლისას და ეს არ იქნება შეცდომა. მაგალითად, ველი, როგორიცაა TimeStamp, რომელიც იწერს დოკუმენტის დროს, ან დოკუმენტის ნომერს, თუ ის ავტომატურად არის მინიჭებული. ყველა ასეთი მომენტი გამოიწვევს შეცდომას ტესტის შესრულებისას. კარგია, რომ დეველოპერებმა უზრუნველყოს ეს და შესაძლებელი გახადეს არამუდმივი ველის შემოწმების გამორთვა. უბრალოდ ასეთი ველები უნდა მოვძებნოთ.
   თუმცა, აქაც არ იყო ხაფანგების გარეშე. მაგალითად, რატომღაც, ჩემი ნაბიჯის დაყენების ფორმაში, თუ ნაჩვენებია ერთზე მეტი რეგისტრი, მაშინ მათზე მოძრაობები არ არის ნაჩვენები, მე უნდა გამორთო ზედმეტი და თითოეული რეგისტრი ინდივიდუალურად დავაკონფიგურირო.
   და რაც საერთოდ არ მომეწონა. როგორც მივხვდი, რეგისტრებით მოწმდება მხოლოდ ის მოძრაობები, რომლებიც სტანდარტშია. მაგალითად, თუ სტანდარტში არის ერთი გაყვანილობა, ხოლო ტესტირებულ მონაცემთა ბაზაში სამი, მაშინ შედარებისას შეცდომები არ იქნება. იმიტომ რომ მთელ რეესტრში იძებნება ტრანზაქცია მითითების პარამეტრებით, თუ ყველაფერი წესრიგშია, მაშინ იმავე ობიექტთან დაკავშირებული დანარჩენების რეესტრში ყოფნა არ კონტროლდება.
3. სკრიპტზე დაფუძნებული ავტომატური დასრულების ნაბიჯები ყოველთვის არ მუშაობს სწორად. შეცდომები ხშირად გვხვდება საცნობარო ველებსა და თარიღებში. უფრო სავარაუდოა, რომ ეს არ არის ინსტრუმენტის შეცდომა, არამედ ველების მახასიათებელი, მაგრამ, მიუხედავად ამისა, თქვენ მოგიწევთ მათი პარამეტრების შეცვლა.
4. შესაძლო ნაბიჯები დაკავშირებულია კონკრეტულ კონფიგურაციის ობიექტებთან. ის, რაც ხელმისაწვდომია დირექტორიებისთვის, შეიძლება არ იყოს ხელმისაწვდომი რეგისტრებისთვის და ა.შ. უფრო ზუსტი იქნება იმის თქმა, რომ სავალდებულოა არა ობიექტებზე, არამედ მათ მახასიათებლებზე, მაგალითად, თუ რეესტრს არ აქვს ფორმა, მაშინ მისი შევსების ნაბიჯი არ იქნება.
   მაგრამ ასევე არის შეცდომები, მაგალითად, ნაბიჯი "დააჭირე ღილაკს" ხშირად ჩემთვის მიუწვდომელია, უფრო სწორად, თავად არჩევანის გაკეთება შესაძლებელია, მაგრამ არაფერი მოხდება.
5. რჩება მხოლოდ ბევრი კითხვა ტესტის ავტომატიზაციის შესახებ ზოგიერთ განსაკუთრებით დამაბნეველ შემთხვევებში. ეს განსაკუთრებით ეხება დოკუმენტებს, რომლებიც მუშაობენ ნარჩენებთან, სადაც თითქმის ყველა მომენტი თამაშობს მნიშვნელოვან როლს, რომელთაგან ზოგიერთი ძალიან პრობლემურია ინსტრუმენტის ამჟამინდელი განხორციელებისას. არსებობს მთელი რიგი შეზღუდვები კონფიგურაციაში დოკუმენტების შესაქმნელად იმავე თარიღზე, იგივე ნომრით და ა.შ. აქამდე მე გადავწყვიტე არსებული ობიექტების გამოყენება ახლის შექმნის გარეშე.

ეს სია შეიძლება გაგრძელდეს და გაგრძელდეს, მაგრამ ნება მიეცით ამ პროდუქტის ტესტერებს ამის გაკეთება. მთავარი, რისი გადმოცემასაც მე მივხვდი და ვცდილობ, არის ის, რომ „უფასო არ იქნება“. სატესტო ავტომატიზაციის განსახორციელებლად ამ პროდუქტით მთავარ როლში, მოგიწევთ ოფლი ერთ დღეზე მეტი ხნის განმავლობაში. რა თქმა უნდა, ჩემი ანალიზი წმინდა სუბიექტურია და პროდუქტის გამოყენებისა და კონფიგურაციის მახასიათებლების გამოცდილების ნაკლებობამ შეიძლება ასევე იმოქმედოს, მაგრამ, როგორც ამბობენ, ჩვენ გვაქვს ის, რაც გვაქვს და მისგან თავის დაღწევა არ არის.

განაცხადის პარამეტრები.

ჩემთვის, ამ დროისთვის მე ავირჩიე შემდეგი კონცეფცია ტესტირების პროცესში მოცემული ინსტრუმენტის შესატანად.

ამჟამინდელი ოპერაციული გამოცდილებიდან გამომდინარე, დარწმუნებული ვარ, რომ საცნობარო ბაზა და ტესტის ბაზა იდენტური უნდა იყოს მონაცემთა თვალსაზრისით. ბუნებრივია, თუ ვსაუბრობთ სკრიპტებზე, რომლებიც იყენებენ არსებულ ობიექტებს მათი შეცვლის გარეშე და არ ქმნიან ახალს. პირველ რიგში, ეს მოგვცემს ერთნაირ ნაშთებს ორივე ბაზაში და ეს ძალიან მნიშვნელოვანია ბრუნვის შესამოწმებლად. მეორეც, ეს მისცემს გარკვეულ საიმედოობას და გარკვეულ დაცვას არასაჭირო შეცდომებისგან, რადგან. ჯერ კიდევ ბოლომდე არ მესმოდა კავშირი საცნობარო მონაცემებსა და მონაცემთა ბაზებს შორის, სხვადასხვა ბმულებს შორის და ა.შ., მტანჯავს ბუნდოვანი ეჭვები, რომ შეიძლება არსებობდეს რაღაც სიმები, რომელიც ერთ მშვენიერ მომენტში გადაიქცევა მკვდარი ბმულების ჭურჭლად. თქვენ არ შეგიძლიათ ამოხსნა.

ასე რომ, ჩვენ გვაქვს საცნობარო ბაზა, რომლის მიხედვითაც ჩვენ თვითონ შევქმენით სცენარები ყველა შემთხვევისთვის. განვითარების კონფიგურაციის დოკუმენტში არის შესწორებები, რომლებიც უნდა შემოწმდეს. როგორც წესი - ხელით. ამის შემდეგ, ცვლილებებით კონფიგურაცია იტვირთება სატესტო ბაზაში და სკრიპტები გაშვებულია ყველა ან მხოლოდ მიმდებარე ობიექტებისთვის, რათა გაირკვეს, მოახდინა თუ არა გავლენა დოკუმენტის ცვლილებამ სხვა ობიექტებზე. ამის შემდეგ, კონფიგურაცია ითვლება სიცოცხლისუნარიანად და დამონტაჟებულია სამუშაო ბაზაში. ამის შემდეგ, შეცვლილი დოკუმენტის ტესტირების სკრიპტი იცვლება ახალ სტანდარტზე სამუშაო ბაზიდან.

სხვა სიტყვებით რომ ვთქვათ, ჩვენ ვაკეთებთ რეგრესიის ტესტირებას ამ სცენარებით. და ეს არის ერთ-ერთი ყველაზე მნიშვნელოვანი და რთული ტესტირების ტიპების ხელით განხორციელება 1C Enterprise-ში. ყოველივე ამის შემდეგ, ძალიან ხშირად იცვლება არა მხოლოდ დოკუმენტი, არამედ, ვთქვათ, დოკუმენტის განთავსების ფუნქცია, რომელიც ასოცირდება სისტემის ყველა დოკუმენტთან, აქ ჩვენი სკრიპტები ითამაშებენ ქსელის როლს, რომელშიც ყველა დოკუმენტი მარცხი დაეცემა.

კიდევ ერთი კარგი გამოყენება იქნება სამუშაო ბაზის შემოწმება შემთხვევითი შეცდომებისთვის. ამისათვის, მისგან იღებენ სარეზერვო ასლს, იტვირთება სატესტო მონაცემთა ბაზაში და ტარდება ტესტების სრული ციკლი. კარგი იქნებოდა ამ პროცედურის ჩატარება ავტომატურ რეჟიმში, მაგრამ 1C სცენარის ტესტირება არ ითვალისწინებს ტესტების გაშვებას გრაფიკით, ყოველ შემთხვევაში ჯერ არა.

ეს, რა თქმა უნდა, არ ამთავრებს ამ ხელსაწყოს ფარგლებს, ბევრი შესაძლო ვარიანტია, მე მხოლოდ პირველი მივაწოდე, რაც თავში მომივიდა.

დასკვნა.

ამ ხელსაწყოს რა თქმა უნდა აქვს მომავალი. მეჩვენება, რომ მისი პოტენციალის უმეტესი ნაწილი ჯერ კიდევ არ არის გამოვლენილი შემდგომ ვერსიებში და, უდავოდ, პროდუქტი იპოვის თავის მომხმარებელს, რაც, ჩემი აზრით, რომელიც აშკარად არ ემთხვევა მწარმოებლის აზრს, უფრო სავარაუდოა, რომ არა. ჩვეულებრივი მომხმარებელი IT სფეროში სპეციფიკური ცოდნის გარეშე, მაგრამ პირი განვითარების დეპარტამენტიდან. იმიტომ რომ ამ ხელსაწყოს ეფექტურად გამოყენება არ არის ადვილი ამოცანა, განსაკუთრებით რთულ კონფიგურაციებში.

გამარჯობა მეგობრებო!

თქვენს ყურადღებას ვაქცევ მცირე კონფიგურაციას 1C:Enterprise 8.3, მართული ფორმების საფუძველზე გადაწყვეტილებების სცენარის ტესტირებისთვის.

კონფიგურაციას ეწოდება ტესტერი. ტესტერი არის სკრიპტირებული ტესტების შემუშავებისა და გაშვების გარემო. ტესტერი არ არის სუფთა BDD პროდუქტი და არ არის გამიზნული სისტემის ქცევის აღსაწერად მის შემუშავებამდე.

ტესტერის ძირითადი მიზნები:

1. ტესტებთან გუნდური მუშაობის ორგანიზება ერთ გარემოში ვერსიების, რედაქტირების და სხვა ნაცნობი ფუნქციების მხარდაჭერით კოდთან მუშაობისთვის
2. მიეცით მომხმარებელს მარტივი გზა შექმნას, შეინარჩუნოს და გააფართოვოს რეალური სცენარის ტესტები, გონივრულ დროში, პროცესში შესვლის მინიმალური ზღვრით და საიმედო ინფრასტრუქტურით.

ტესტერის გამოყენებით, შეგიძლიათ დაეყრდნოთ შემდეგი ამოცანების გადაჭრას:

1. ფუნქციონალური დაფარვის მაღალი ხარისხი. ტესტერი კარგად არის ორიენტირებული ტესტის შემუშავების პროცესზე, რაც დადებითად მოქმედებს შექმნილი ტესტების რაოდენობასა და ხარისხზე.
2. ტესტები იწერება 1C პროგრამირების ენაზე, რომელიც არა მხოლოდ ნაცნობი ინსტრუმენტია, არამედ საშუალებას გაძლევთ გამოიყენოთ პლატფორმის ფუნქციების მთელი ნაკრები ტესტირებაში და რაც მთავარია, საშუალებას გაძლევთ აკონტროლოთ ტესტირების პროცესი პროგრამულად, ჩაშენებულზე დაყრდნობის გარეშე. მოდელი ტესტირების ხელსაწყოში
3. თქვენ შეგიძლიათ შექმნათ ბიბლიოთეკები ტესტებიდან, მაგალითად, შეგიძლიათ შექმნათ ტესტები, რომლებიც ხსნიან საძიებო ფანჯარას დინამიურ სიაში მიღებული პარამეტრების მიხედვით, ან გენერირება გარკვეული ანგარიში. თუ თქვენი ტესტისთვის გჭირდებათ ნაშთის ქონა, შეგიძლიათ განახორციელოთ ბიბლიოთეკის ტესტი, რომელშიც ჩააბარებთ საჭირო ბალანსის შემადგენლობას და ეს ნაშთი ჩაირიცხება
4. ბიზნეს ლოგიკის მარტივი შემოწმება, სხვა მონაცემთა ბაზების მონაცემებთან შედარების გარეშე, ტესტირებადი აპლიკაციისთვის პირდაპირი მოთხოვნის გარეშე, განლაგების გარეშე, სერიული მონაცემებით "სხვა ადგილას". ყველა ინფორმაცია შეიძლება შეინახოს თავად ტესტში, განლაგებაში, საჭიროების შემთხვევაში, შეიცვალოს.
5. გარდა იმისა, რომ ყველა ტესტი ინახება მონაცემთა ბაზაში და ტესტერის ნებისმიერ მომხმარებელს შეუძლია გამოიყენოს სხვა პროგრამისტის მიერ დაწერილი ტესტი, ტესტერს აქვს შესაძლებლობა ეტაპობრივად განტვირთოს/ჩატვირთოს ტესტები ფაილურ სისტემაში. ეს შეიძლება სასარგებლო იყოს ტესტების შემდგომი სინქრონიზაციისთვის ვერსიების კონტროლის სისტემებთან, როგორიცაა Git.

დემო ბაზამ შეიმუშავა ურთიერთდაკავშირებული ტესტების მცირე ინფრასტრუქტურა, რომელიც შეიძლება გამოყენებულ იქნას საკუთარი ტესტების შესაქმნელად. ასევე, მონაცემთა ბაზა შეიცავს ERP2-ისთვის (დემო) დოკუმენტის Order to Supplier-ის შექმნის მაგალითს.

ERP2 კონფიგურაციისთვის (დემო) შეიქმნა საცავი https://github.com/grumagargler/ERP2
იქ გადმოვტვირთე დემო ტესტები. ვიმედოვნებ, რომ ეს წამოწყება შეუმჩნეველი არ დარჩება ენთუზიასტებისთვის და ტესტები შეივსება.

თქვენ იპოვით ყველაზე ამომწურავ ინფორმაციას ტესტერის შესახებ დახმარებაში, ის იქნება სამუშაო მაგიდაზე, როდესაც სისტემა დაიწყება. დახმარებაში არის სწრაფი დაწყების განყოფილება, გირჩევთ გაეცნოთ მას.

ტესტერი უფასოა. შემუშავებული და შენახული ჩვენი საკუთარი საჭიროებისთვის, ყოველგვარი კომერციული ფონის გარეშე.

გმადლობთ სისტემით დაინტერესებისთვის და წარმატებებს გისურვებთ მეგობრებო!

განახლება 1.3.2.7

დამატებულია პროცედურა LogError (RecordError), გამოიყენება სკრიპტის კოდიდან შეცდომების ჟურნალში შეტყობინებების პროგრამულად დასამატებლად სკრიპტის შესრულების შეჩერების გარეშე

ველებთან მუშაობის ყველა ფუნქციას ახლა შეუძლია ტაბულური ნაწილის ნავიგაცია, მაგალითად, ამ გზით შეგიძლიათ შეამოწმოთ დარიცხვის ოდენობა მეხუთე სტრიქონში: შემოწმება ("#Accruals / Result [ 5 ]", 1000);

Check ფუნქცია ცდილობს შეამოწმოს რიცხვითი მნიშვნელობები ტრიადის გამყოფისა და წილადი ნაწილის გათვალისწინების გარეშე.

დამატებულია Run Log, სადაც აღირიცხება სკრიპტის შესრულების მოვლენები

დამატებულია სკრიპტიდან გადასვლა Run Log-ზე და Error Log-ზე

დაემატა დამხმარე ველის შერჩევის ხეს

დამხმარეს დაემატა ონლაინ დახმარება ჩაშენებული ტესტერის მეთოდებისთვის

დამატებულია აპლიკაციის ვერსიები. ვერსიების დაყენება შესაძლებელია როგორც მთლიანობაში, ასევე ცალ-ცალკე თითოეული მომხმარებლისთვის

დამატებულია მოხსენებები: პროტოკოლი, რეზიუმე (ანგარიშები იმუშავებს მხოლოდ ამ გამოშვების ახლად დაწყებულ სცენარებზე). შესაძლებელია ფოსტით მოხსენებების გაგზავნის განრიგის დაყენება (ანგარიშების გენერირებისას გათვალისწინებულია მომხმარებლების RLS)

ანგარიშები დანერგილია როგორც ცალკეული უფლებები, რომ დაამატოთ ისინი არაადმინისტრატორ მომხმარებლებში, თქვენ უნდა გააკეთოთ შესაბამისი პარამეტრები მათ პროფილებში

ოპტიმიზებულია სკრიპტების გადმოტვირთვა ფაილებში. ატვირთული ფაილები გენერირებულია bsl ფორმატში

გადასვლის ბრძანება:

კონფიგურაციის განახლების შემდეგ, სკრიპტების გაშვებამდე, რეკომენდებულია მათი ვერსიების დანიშვნა თქვენი გადაწყვეტილებებისთვის. ეს კეთდება განაცხადის დირექტორიაში.

ყურადღება! კონფიგურაცია ეფუძნება 8.3.10 ვერსიას, მაგრამ ადრინდელი ვერსიების მუშაობა ასევე მხარდაჭერილია. ამისათვის, 8.3.10 ვერსიით, თქვენ უნდა დააყენოთ საჭირო კონფიგურაციის თავსებადობის რეჟიმი, შეინახოთ კონფიგურაცია ფაილში და გამოიყენოთ იგი როგორც განახლება.

გადაწყვეტის ბარათი 1C: სცენარის ტესტირება 8

ეს არის ინსტრუმენტარიუმი 1C:Enterprise 8 სისტემის ნებისმიერი კონფიგურაციის მუშაობის შესამოწმებლად. პროდუქტი საშუალებას გაძლევთ მოამზადოთ საჭირო ტესტები და შეასრულოთ ისინი ხელით ან ავტომატურად. ტესტების შესამუშავებლად "1C: სცენარის ტესტირება 8"-ის გამოყენებით, საკმარისია გქონდეთ წარმოდგენა შემოწმებული კონფიგურაციის მუშაობის შესახებ მომხმარებლის დონეზე, პროგრამირების უნარები არ არის საჭირო.

შეიძინეთ 1C: სცენარის ტესტირება 8

4601546061393

42 000

ლიცენზირება 1C: სცენარის ტესტირება 8

პროდუქტი "1C: სცენარის ტესტირება 8" განკუთვნილია გამოსაყენებლად 1C: Enterprise 8 კლიენტის ლიცენზიარაც ზრდის სამუშაოების რაოდენობას პროდუქტის პაკეტში შედის სადისტრიბუციო ნაკრები, წიგნი „1C: სცენარის ტესტირება 8. მომხმარებლის სახელმძღვანელო“ და სალიცენზიო ხელშეკრულება.

პროდუქტის გამოსაყენებლად, თქვენ უნდა გქონდეთ 1C:Enterprise 8 სისტემის ნებისმიერი ძირითადი მიწოდება (PROF ვერსია). პროდუქტი არ არის განკუთვნილი 1C:Enterprise 8-ის ძირითად ვერსიებთან გამოსაყენებლად. 1C:Scenario Testing 8 ლეგალურია გამოსაყენებლად: ორგანიზაციის ლოკალური ქსელის სამუშაო ადგილები, უზრუნველყოფილი 1C კლიენტის ლიცენზიით: საწარმოები 8. 1C: სცენარის ტესტირება 8 შედის მიწოდებაში 1C: კორპორატიული ხელსაწყოების პაკეტი 8

მხარდაჭერა და განახლება 1C: სცენარის ტესტირება 8

რეგისტრირებული მომხმარებლების მხარდაჭერა და სერვისის შენარჩუნება ხორციელდება საინფორმაციო და ტექნოლოგიური მხარდაჭერის ფარგლებში (1C: ITS) - 1C: ITS Techno ან 1C: ITS Prof. პროგრამის შეძენისას უფასო გამოწერის ვადაა 3 თვე. უფასო გამოწერის პერიოდის გასვლის შემდეგ, პროდუქტის მხარდაჭერის სერვისების მისაღებად, თქვენ უნდა გამოიწეროთ 1C:Enterprise 8 სისტემის ნებისმიერი ძირითადი განაწილება.

დარეგისტრირებულ მომხმარებლებს შეუძლიათ ჩამოტვირთოთ განახლებები საიტიდან users.v8.1c.ru და ITS დისკიდან.

ფუნქციონალობა 1C: სცენარის ტესტირება 8

ტესტი არის მოქმედებების ერთობლიობა, რომელიც მომხმარებელმა უნდა შეასრულოს პროგრამაში. ეს შეიძლება იყოს მოქმედებები, მაგალითად, დირექტორიების, დოკუმენტების ახალი ელემენტების შექმნაზე, ფორმაზე მონაცემების შევსებაზე, ღილაკების დაჭერაზე. როდესაც ასეთი ტესტი ავტომატურად შესრულდება, მომხმარებლის შეყვანა სიმულირებულია. მნიშვნელოვანია, რომ სატესტო ბრძანებების შესრულება ობიექტების ინტერაქტიული შექმნისა და ფორმების შევსებისთვის დამუშავებული იყოს 1C:Enterprise 8 პლატფორმის მიერ ისე, როგორც მომხმარებელმა შეიყვანა ეს მონაცემები კლავიატურიდან.

მსგავსი ტესტირების პრინციპი არსებობს სხვა პროგრამებში, მაგრამ, მათგან განსხვავებით, 1C: Scenario Testing 8 ახორციელებს ტესტის განვითარების შესაძლებლობებს, რომლებიც ასახავს 1C: Enterprise 8 კონფიგურაციის ტესტირების სპეციფიკას. ეს შესაძლებლობები მოიცავს:

• სხვადასხვა კონფიგურაციის ობიექტების ფორმების შევსების შაბლონების შექმნა (მათი შეიძლება მორგებული იყოს და გამოიყენოთ ერთი და იგივე კონფიგურაციის სხვადასხვა ტესტებისთვის);
• კონფიგურაციის საცნობარო ბაზის ობიექტებსა და ტესტის საფეხურებს შორის კავშირის ანალიზი;
• ჩაწერილი ტესტის სისწორის ანალიზი მის შესრულებამდე;
• ავტომატური ტესტის შესრულებისას აღმოჩენილი შეცდომის ხელით გვერდის ავლით და ტესტის ავტომატურ რეჟიმში გაგრძელების შესაძლებლობა;
• დოკუმენტის მოძრაობის ავტომატური შედარება საცნობარო ბაზის მონაცემებთან;
• ტესტით შექმნილი ობიექტების სათითაოდ შედარება საცნობარო ბაზის მონაცემებთან;
• ტესტის ჩაწერისას გამართვის ნაბიჯების შესრულების შესაძლებლობა;
• კონფიგურაციის ობიექტების სატესტო დაფარვის ანალიზი.

ტესტის ჩასატარებლად არ არის საჭირო გამოცდილი კონფიგურაციის სპეციალური მომზადება.

იმავე ტესტში შეგიძლიათ შექმნათ ნაბიჯები სხვადასხვა ბიზნეს ტრანზაქციების შესამოწმებლად. ტესტის ლოგიკა აღწერილია პროგრამაში ბიზნეს ტრანზაქციების ასახვის წესებით მომხმარებლის დოკუმენტაციის მიხედვით. ამრიგად, ინსტრუმენტი შეიძლება გამოყენებულ იქნას კონფიგურაციების სკრიპტული ან ფუნქციური ტესტირებისთვის.

ასეთი ტესტირების აუცილებლობა ჩნდება მაშინ, როდესაც აუცილებელია დავრწმუნდეთ, რომ კონფიგურაციის ფუნქციის დასრულებისას ან შეცდომების გამოსწორებისას, შენარჩუნებულია კონფიგურაციის ფუნქციონალობის ფუნქციონირება, რომელიც უცვლელი რჩება. ეს უფრო მოთხოვნადია იმ ორგანიზაციებში, სადაც კონფიგურაციების ახალი გამოშვებების შემუშავება, მათი ტესტირება და გამოშვება განმეორებადი ხდება. ამ შემთხვევაში, ტესტების ჩაწერის ღირებულება და მათი შემდგომი ავტომატიზირებული შესრულება ნაკლები იქნება, ვიდრე კონფიგურაციის ყოველი ახალი გამოშვების ხელით რეგრესიის ტესტირება.

როგორც წესი, ტესტები იწერება რეალური მუშაობის ყველაზე ხშირად გამოყენებული სცენარებისთვის, გამოყენებითი გადაწყვეტით და შესრულებულია შეცვლილი კონფიგურაციის ან პლატფორმის ყოველ ახალ ვერსიაზე. ტესტები შეიძლება იყოს მეტ-ნაკლებად რთული, რაც დამოკიდებულია გამოყენებული გადაწყვეტის კონკრეტულ ფუნქციონალურ შეცდომებზე და იმ დროის მიხედვით, რომელიც ორგანიზაციას სურს დახარჯოს ტესტირებაზე.

1C:Scenario Testing 8 ინსტრუმენტარიუმის შედგება ორი გარე დამუშავებისგან (ერთი დამუშავება განკუთვნილია ტესტის დასაწერად, მეორე მისი შესასრულებლად), ასევე ტესტების ნაკრები (ფაილები xml ფორმატში) ტიპიური 1C:Enterprise 8 კონფიგურაციისთვის.

Შეგიძლია გამოიყენო:

• პარტნიორები - ცირკულაციის გადაწყვეტილებების შემქმნელები,
• პარტნიორები ან მომხმარებლები, რომლებსაც აქვთ დავალება, შეამოწმონ კონფიგურაცია საწარმოო ბაზის განახლებამდე.