The article considers new mechanism automated testing, which first appeared in the platform in edition 8.3. After studying the material of the article, you will learn:

• What is automated testing in the platform?
• How and when to use it?
• What and where should be configured to run it?
• How to write an automated test script?

Applicability

The article discusses the 1C:Enterprise platform version 8.3.4.465. In the current version of the platform, the capabilities of the automatic testing mechanism have been significantly expanded, but this did not affect the relevance of the article material. It is still relevant.

Automated testing in 1C:Enterprise 8.3

The 1C:Enterprise 8.3 platform has a new mechanism designed to simulate the interactive actions of system users - automated testing.

Automated testing does not support working with a regular interface, but only with a managed one.

When testing, two types of client applications are used - the test manager and the test client. The test manager establishes a connection with the test client and executes the test script.

A test script is a code in a built-in language that describes a sequence of interactive actions to be performed.

To do this, new objects have been added to the built-in language that describe the application interface at an abstract level (in terms of a window, form, controls, etc.), and also describe user actions (configuration navigation, data entry, etc.) .

The test manager can be a thick or thin client. Test client - thick client, thin client or web client.

A test manager can be connected to multiple test clients, and a test client can only be connected to one manager.

To manage the client, the manager establishes a TCP connection with it. It is important that automated testing does not require changes to the configuration structure.

Essentially, the test client and manager are configurations run with certain command-line options, with the manager managing the clients by “making” the windows and controls behave as if the user is interacting with them.

Automated testing has its limitations. So, for example, work with the usual interface is not supported, but only with the managed one.

To perform automated testing, both the test manager and the test client must be running.

The manager can be launched from the command line with the /TESTMANAGER key:

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

Also, the test manager can be launched from the configurator.

To do this, through the menu Tools - Options, open the "Options" dialog, in which on the tab Launch 1C: Enterprise - Advanced, check the item "Run as test manager":

Another way to launch the test manager is from the built-in language, using the StartSystem() method, in which you must specify the command line:

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

The test client can also be launched from the command line. To do this, use the /TESTCLIENT command line switch.

The TPort parameter specifies the port number through which the manager and testing client will interact. If this option is not specified on the command line, port 1538 will be used.

“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\Platform8Demo” /N Administrator /TESTCLIENT -TPort 1539

The test client can be launched from the configurator. To do this, through the menu Tools - Options, open the "Options" dialog, in which, on the tab Launch 1C: Enterprise - Advanced, check the item "Run as a test client". In this case, you will need to specify the port number used.

Note that in order to connect to the test client, you need to know two parameters: the IP address (or name) of the computer running the test client, and the TCP port number through which the interaction will be performed.

Both different infobases can be used as a manager and a testing client (the configuration of the testing manager's database may not match the configuration of the testing client) or the same infobase.

To perform automated testing, you need to do the following steps:

1. Develop a test script - write an external or built-in processing in the configuration, which will sequentially describe the steps to be performed.
2. Launch test manager.
3. Launch a test client (one or more).
4. In the testing manager, launch the created processing for execution, make sure that the programmed actions are performed on the client.

The application under test is described by a set of 1C:Enterprise language objects that are used to write the script:

• TestedApplication;
• TestedWindowClientApplication;
• TestedCommandInterfaceWindow;
• TestedCommandInterfaceGroup;
• TestedButtonCommandInterface;
• TestedForm;
• TestedFormField;
• TestedFormGroup;
• TestedFormButton;
• TestedFormTable;
• TestedDecorationForm.

We will use the “Managed Application” demo configuration as a test configuration.

Let's create an external processing, add a new form, in which we will define a handler for the new "RunTesting" command.

In the test, we perform the following actions: create a new element of the directory “Warehouses”, in the Name field enter the line “Warehouse test”, then click the “Save and close” button.

The code for this test will look like this:

&AtClient
Procedure RunTesting(Team )
// Connect to the application under test
TestedApplication= New TestedApplication(“localhost” );
// Trying to connect for no more than one minute
End TimeWaiting= CurrentDate() + 60 ;
Connected = False ;
While Not CurrentDate() >= End TimeWaiting Cycle Attempt
TestedApplication.SetConnection();
Connected = true ;
abort ;
Exception
EndTry ; EndCycle ; If Not Connected Then
// End the test
TestedApplication= undefined ;
To report ( “Unable to connect!”);
Return ;
EndIf ;
// Find the main window
MainWindowTested
=(Type());
MainWindowTested.Activate();
// Execute the command to create an element of the product directory
MainWindow of the Tested.RunCommand(“e1cib/command/Catalog.Warehouses.Create”);
TestedApplication.ExpectObjectDisplay(Type ( “TestedForm”), "Stock*" );
TestedForm= TestedApplication.FindObject(Type ( “TestedForm”),
"Stock*" );
TestedForm.Activate();
// Set the name for the new product
FormItem = TestedForm.FindObject(Type ( “TestedFormField”),
"Name");
FormElement.Activate();
FormElement.EnterText(“Warehouse test”);
// Write element
FormItem = TestedForm.FindObject(Type ( “FormButton Tested”),
“Record and Close”);
FormElement.Press();
EndProcedure

In the launch options dialog, the “Run as test manager” value was first selected, using the Ctrl + F5 key combination, a user session was launched.

Then, in the dialog, the value “Run as a testing client” was selected, using the Ctrl + F5 key combination, the second user session was launched.

Thus, we avoided the need to manually specify the required command line options.

The code above performs fairly simple actions, but if the script becomes more complex, the amount of code will increase, since it is necessary to describe each interactive user action.

Here comes another one to the rescue. new opportunity Platforms – log entry of user actions.

To do this, you need to run the application in a special mode:

Click on the image to enlarge.

Several buttons appear in the program header:

The buttons are for:

• start/stop recording;
• stop recording;
• completion of the recording.

When the recording is completed, the screen will display Text Document, which is a sequence of user actions saved in an XML file.

Click on the image to enlarge.

The recorded log can be converted into program code, which can then be used in a test script.

For this, the “User Action Log Conversion” processing (UILogToScript.epf) is intended, which can be obtained from the ITS website.

Click on the image to enlarge.

As a result of the processing, we get the generated code in the built-in language. This code should be pasted into the test processing form module.

Note that in the generated code, numbers greater than 999 or less than -999 will be output using a non-breaking space as the group separator (for example, "1234" instead of "1234").

This symbol must be removed from the received code manually.

The section of code with the connection to the client was generated automatically by processing.

In our example, we get the following code:

&AtClient
Procedure RunTesting(Team )
Test Scenario_23_03_2014();
EndProcedure &AtClient
Procedure Test Scenario_23_03_2014() TestApp= New TestedApplication();
End TimeWaiting= CurrentDate() + 60 ;
Connected = False ;
DescriptionErrorsConnections= “” ;
While Not CurrentDate() >= End TimeWaiting Cycle
Attempt
TestApplication.SetConnection();
Connected = true ;
abort ;
Exception
DescriptionErrorsConnections= DescriptionErrors();
EndTry ;
EndCycle ;
If Not Connected Then
TestApp= undefined ;
Report (+ Symbols. PS + DescriptionErrorsConnections);
Return ;
EndIf ; ( TestApp);
(TestApp); EndProcedure &AtClient
Procedure WindowApplicationAccountsCreateButtonClick(TestApp)
WindowApplicationContractors= (Type (
“TestingClientApplicationWindow”), “Contractors” , , 30 );
WindowApplicationAccountsFormAccounts= WindowApplicationAccounts.FindObject(Type (
“TestedForm”), “Contractors” );
ButtonCreate = WindowApplicationAccountsFormAccounts.FindObject(Type (
“FormButton Tested”), "Create" );
ButtonCreate.Press(); EndProcedure &AtClient
Procedure WindowApplicationAccountCreateButtonSaveAndClosePress(TestApp) WindowApplicationContractorCreation= TestApplication.FindObject(Type (
“TestingClientApplicationWindow”), “Account (creation)”, , 30 );
WindowApplicationAccountCreationFormAccountCreation=
WindowApplicationAccountCreate.FindObject(Type ( “TestedForm”),
“Account (creation)”);
FieldName=
(Type (
“TestedFormField”), "Name");
FieldName.EnterText("New" ); FieldTypePrice = WindowApplicationAccountCreationFormAccountCreation.FindObject(Type (
“TestedFormField”), “Price type” );
FieldPriceType.Activate(); FieldTypePrice.Select(); FieldPriceView.WaitFormationDropdownList(); FieldPriceType.PerformSelectionFromSelectionList(“Purchasing”); ButtonSave&Close=
WindowApplicationAccountCreationFormAccountCreation.FindObject(Type (
“FormButton Tested”), “Record and Close”);
ButtonSave&Close.Press(); EndProcedure

In the resulting scenario, a connection to the testing client is established, the button for creating a new element of the "Contractors" directory is pressed, in the field Name the text “New” is entered, and in the drop-down list “Price type”, select the value “Purchase”, then the button “Save and close” is pressed.

If you need to use several test clients in a scenario, then the connection to each of them and the actions performed must be described separately.

The test manager will be used alone, and two clients are connected to it on different ports.

Since the test script is processing, the lines of the program code of which are executed sequentially, the developer needs to describe the sequence of actions for each client.

Let's take a closer look at how the code will look when using two test clients:

Procedure Test Scenario_23_03_2014_TwoClients() //first client
Test Application1= New TestedApplication();
End TimeWaiting= CurrentDate() + 60 ;
Connected = False ;
DescriptionErrorsConnections= “” ;
While Not CurrentDate() >= End TimeWaiting Cycle
Attempt
TestApplication1.SetConnection();
Connected = true ;
abort ;
Exception
DescriptionErrorsConnections= DescriptionErrors();
EndTry ;
EndCycle ; //second client
TestApp2= New TestedApplication();
End TimeWaiting= CurrentDate() + 60 ;
DescriptionErrorsConnections= “” ;
While Not CurrentDate() >= End TimeWaiting Cycle
Attempt
TestApplication2.SetConnection();
Connected = true ;
abort ;
Exception
DescriptionErrorsConnections= DescriptionErrors();
EndTry ;
EndCycle ;
If Not Connected Then
Test Application1= undefined ;
TestApp2= undefined ;
To report ( “Could not connect!”+ Symbols.PS + DescriptionErrorsConnections);
Return ;
EndIf ; //procedures are separate for each testing client
WindowApplicationAccountsCreateButtonPress1(Test Application1);
WindowApplicationAccountsButtonCreateClick2(TestApp2);
WindowApplicationAccountCreateButtonSave&ClosePress1(Test Application1);
WindowApplicationAccountCreateButtonSave&ClosePress2(TestApp2); EndProcedure

Pauses between the actions performed also need to be programmed separately. Scenario for a large number customers becomes hard to read.

Also, automated testing is only available for managed forms.

However, the advantage of automated testing is the simplicity and visibility of test development. Since the test operates only on interactive user actions, the developer does not need to know the configuration structures at the level of object attributes.

If you change, for example, the configuration code, there is no need to redo the test, because the test client will still perform the same actions with the same controls.

The automated testing mechanism can be used by testers to record the sequence of actions leading to an error. Recorded data can be sent to developers to fix the detected error.

Automated testing can also be used to identify redundant locks and deadlocks in a configuration.

To do this, you need to implement a script that reproduces the problem, and begin to find and fix the cause.

1C Test Center 8 is a specialized software product from 1C, which allows you to evaluate the performance of the system and study the bottlenecks of the information system.

Earlier we looked at arbitrary configuration. Now let's learn how to create scenarios for multi-user configuration testing by users and run the testing itself.

The test script in 1C Test Center is written inside a specially created processing. This template is located inside the configuration, it has the name "TTSTemplateTestProcessing". To create your own test scenario, you need to copy this template and, based on it, create your own, new one, let's call it "Reposting goods receipt":

Add to processing new props and display it on the form - "DocumentToCopy", this is the document that we will copy.

Let's take a closer look at the form module. It can use three procedures - TCIinitialize (), TTSExecute (), Delete ().

• TCIinitialize - used to initialize the settings information base, for example, filling out an accounting policy.
• TCRun - the main module in which the test script is written directly.
• TCDeleteData is a module that describes the deletion of objects created during testing.

Let's write the simplest code in the TCExecute() procedure, which will copy the selected document 5 times in a row and measure the copying and posting of each document:

For d=1 By 5 Loop

Tools = KipExternalComponent.GetTools();
StartTime = KipExternalComponent.TimerValue(Tools);

Get 267 1C video lessons for free:

CreateDocuments();

EndTime = KipExternalComponent.TimerValue(Tools);
Execution Duration = (EndTime - StartTime) / 1000;

TPWriteIndicator("Execution Time", Duration of Execution);

EndCycle;

Return TCExecutionResultSuccessful();

The CreateDocuments() procedure will be executed on the server:

Procedure CreateDocuments()

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

EndProcedure

This completes the preparation of the script, let's move on to the Test Center for load testing.

Setting up 1C Test Center 8.3

After writing the test, let's start setting up the Test Center itself. To set up, you need to fill out a number of directories:

• Processing— a directory containing a list of processing connected to testing. Processing can be both internal and external.
• Roles- a directory for storing a bunch of processing-processing settings. Settings are data that are individual for each test (the number of iterations, the document being copied, etc.).
• Users— list of users and their passwords.
• Computers— list of computers on which the test will be run.
• Clients - setting where, from whom and in what mode load testing will be launched.

Test Scenarios

The main directory that consolidates all the settings in itself: how many times, by which user, on what behalf the load testing will be performed.

Also on the "Parameters" tab there is the ability to configure a technical testing scenario:

After setting up the script, it remains only to run it.

Start testing in 1C: Test Center

When everything is ready, it remains only to start the testing work.

This requires the launch of at least two sessions of the program: the first - in the role of the so-called. "agent", and the second as the initiator of the script launch.

Agent start:

Running the script:

To start, just select from the list desired scenario and click the Run button.

Key Features

Using 1C:Script Testing 8, you can write and run tests to check the performance of any configuration of the 1C:Enterprise 8 system. The tool consists of two external processing. One processing is for recording the test, the second processing is for running the test. The recorded test can be performed either manually or automatically.

To develop tests using this tool, it is enough to have knowledge about the operation of the tested configuration at the user level, programming skills are not required.

A test is a set of actions that the user must perform in the program. These can be actions, for example, on creating new elements of directories, documents, filling in data on a form, pressing buttons. When such a test is automatically run, the user's work on entering information is simulated. It is important that the execution of test commands for interactive creation of objects and filling out forms is processed by the 1C:Enterprise 8 platform in the same way as if the user entered these data from the keyboard.

A similar testing principle exists in other programs, but, unlike them, this tool implements test development capabilities that reflect the specifics of testing 1C:Enterprise 8 configurations. These possibilities include:

• creating templates for filling out forms of different configuration objects (they can be customized and used for different tests of the same configuration);
• analysis of which objects in the reference configuration database are associated with which test steps;
• analysis of the correctness of the recorded test before its execution;
• the ability to manually bypass the error when running an automated test and continue the test in automatic mode;
• automatic comparison of document movements with the data of the reference base;
• one-by-one comparison of the objects created by the test with the data of the reference database;
• the ability to perform debugging steps when recording a test;
• analysis of test coverage of configuration objects.

Not required to complete the test special training tested configuration.

Using 1C: Scenario testing 8

In the same test, you can create steps to test different business transactions. The test logic is described by the rules for reflecting business transactions in the program, according to the user documentation. Thus, the tool can be used for scripted or functional testing of configurations.

The need for such testing arises when it is necessary to make sure that when finalizing the configuration functionality or fixing errors, the configuration functionality that has not been changed remains operational. This is more in demand in those organizations where the development of new configuration releases, their testing and release are iterative. In this case, the cost of writing tests and their further automated run will be less than with manual regression testing of each new release of the configuration.

As a rule, such tests are written for the most frequently used scenarios of working with an application solution by users; they are run on each new version changed configuration or platform. Tests can be made more complex or less complex, depending on the criticality of errors in a particular functionality of the applied solution and depending on the amount of time that the organization is willing to spend on testing.

"1C: Scenario Testing 8" can be used by:

• Partners - developers of circulation solutions;
• Partners or users who have the task of testing the configuration before updating the production base.

1C has released a trial version of the "Scenario Testing" application solution (see http://www.1c.ru/news/info.jsp?id=8893)

In fact, this is a functional testing system for configurations on the 8.1 platform.

Consists of two external processing "TestWrite.epf" and "TestRun.epf".

Tests are saved as xml files.

Feature "1C: Scenario testing 8"

Key Features

Using 1C:Script Testing 8, you can write and run tests to check the performance of any configuration of the 1C:Enterprise 8 system. The tool consists of two external processings. One processing is for recording the test, the second processing is for running the test. The recorded test can be performed either manually or automatically.

To develop tests using this tool, it is enough to have knowledge about the operation of the tested configuration at the user level, programming skills are not required.

A test is a set of actions that the user must perform in the program. These can be actions, for example, on creating new elements of directories, documents, filling in data on a form, pressing buttons. When such a test is automatically run, the user's work on entering information is simulated. It is important that the execution of test commands for interactive creation of objects and filling out forms is processed by the 1C:Enterprise 8 platform in the same way as if the user entered these data from the keyboard.

A similar testing principle exists in other programs, but, unlike them, this tool implements test development capabilities that reflect the specifics of testing 1C:Enterprise 8 configurations. These possibilities include:

• creating templates for filling out forms of different configuration objects (they can be customized and used for different tests of the same configuration);
• analysis of which objects in the reference configuration database are associated with which test steps;
• analysis of the correctness of the recorded test before its execution;
• the ability to manually bypass the error when running an automated test and continue the test in automatic mode;
• automatic comparison of document movements with the data of the reference base;
• one-by-one comparison of the objects created by the test with the data of the reference database;
• the ability to perform debugging steps when recording a test;
• analysis of test coverage of configuration objects.

To perform the test, no special preparation of the tested configuration is required.

Using 1C: Scenario testing 8

In the same test, you can create steps to test different business transactions. The test logic is described by the rules for reflecting business transactions in the program, according to the user documentation. Thus, the tool can be used for scripted or functional testing of configurations.

The need for such testing arises when it is necessary to make sure that when finalizing the configuration functionality or fixing errors, the configuration functionality that has not been changed remains operational. This is more in demand in those organizations where the development of new configuration releases, their testing and release are iterative. In this case, the cost of writing tests and their further automated run will be less than with manual regression testing of each new release of the configuration.

As a rule, such tests are written for the most frequently used application scenarios by users, they are run on each new version of the changed configuration or platform. Tests can be made more complex or less complex, depending on the criticality of errors in a particular functionality of the applied solution and depending on the amount of time that the organization is willing to spend on testing.

"1C: Scenario Testing 8" can be used by:

• Partners - developers of circulation solutions;
• Partners or users who have the task of testing the configuration before updating the production base.

Buy

line from the price list 1C dated 2010.01.05

Product composition and sales order

Software product 2900000998513 "1C: Scenario testing 8 NFR" includes:

• processing for the preparation and execution of tests;
• a set of tests for typical configurations "1C:Enterprise 8";
• registration card;
• documentation book "1C: Scenario Testing 8. User Guide".

Product 2900000998513 "1C: Scenario Testing 8 NFR" is sold according to applications for the purchase of NFR products, one set per organization, to franchisee partners who have at least one specialist in the platform or in any 1C: Enterprise 8 application solution. For the product to work, the partner must have any NFR delivery that includes the 1C:Enterprise 8 platform and a security key.

Product 4601546061393 "1C: Scenario testing 8" is sold to users software products"1C:Enterprise 8" PROF version through franchisee partners who have at least one specialist in the platform or in any "1C:Enterprise 8" application solution.

Purpose and conditions of use of products

Product 2900000998513 "1C: Scenario Testing 8 NFR" is designed to explore the capabilities of the proposed tools by partners, unlimited use in the partner's internal development, as well as for implementation work performed for the client on the partner's territory. The license allows you to use the NFR product for testing:

• own products developed for sale;
• modifications of typical configurations;
• as part of the work on the implementation of products with customers in the event that these works are carried out in local network partner.

The license does not allow the product to be used to test a configuration directly at a customer's premises, or to test a configuration developed and replicated by a customer or other organization. To carry out such work, it is necessary to purchase product 4601546061393 "1C: Scenario testing 8" for the client.

Product 4601546061393 "1C: Scenario Testing 8" purchased by the organization in which the implementation is being performed cannot be used to test the configuration in the organization of the partner implementing the implementation. To carry out such work, the partner needs to purchase the product 2900000998513 "1C: Scenario testing 8 NFR".