RU2611961C2 - Method and system of regression testing of web page functionality, machine-readable data storage media - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: present invention relates to processing web pages and, in particular, to processing web pages to simplify testing of web page functionality. Technical result is achieved by emulating the code execution of a functional unit at the first point of time, capturing formed images for each of the first and second operating conditions, establishing connection between the captured formed images of the functional unit, preserving the captured images in the initial data array, emulating the code execution of a functional unit at the second point of time and capturing the formed images for each of the first and second functional conditions for testing to create test data array.

EFFECT: technical result: testing fragments of a specific test page in several browsers or multiple versions of one page in one browser.

16 cl, 6 dwg

Description

FIELD OF THE INVENTION

The present solution provides a method for processing web pages and, in particular, a method for processing web pages to simplify testing the functionality of web pages.

State of the art

Web page testing is well known in the art for a number of reasons. For example, there is a known procedure for checking the compatibility of a particular web page with various browsers. There is also a known procedure for testing the effect of updating the base code, which is used to render the created web page when viewing it in a browser. Testing examples include regression testing, which is a well-known form of software testing. Software testing is used to find bugs (errors) or other software shortcomings that can cause certain characteristics to stop functioning after making changes to the underlying software or as a result of using a different type of browser to render the graphical browser interface (GUI) for this specific program code.

In US patent 6898764 B2 it is determined that the testing cycle is an essential part of the development cycle of any software. Testing is a mandatory procedure to verify that the program is working correctly. For many programs, part of the testing cycle includes testing a graphical user interface (GUI) of an object, and the present patent describes that testing a GUI of an object is usually performed using testing tools such as GUI capture and playback tools. To simplify the automation of GUI tests, testing tools typically create various kinds of GUI mapping files that are used to describe the contents of a GUI program at an object level. In general, a GUI mapping file includes a line of text for each GUI object, and each line describes a specific GUI object.

US 2008/0310736 A1 provides a visual comparison of a system in which two images can be compared analytically. The two images may be screen shots of the user interface or any other pair of images that need to be compared. As described, two images can be compared using both graphical and control information and metadata. The control information may extend known image information beyond simple graphical information. The elements presented in the image, such as buttons, lists, text boxes, lists, radio buttons and the like, can be more likely determined by their functions than by their appearance. Using the control data, the elements can be compared for differences, which can then be presented to the tester for easy identification and work with them.

Disclosure of invention

The first object of this solution is a method of regression testing the appearance of a web page or web pages. To this end, a method is presented that allows testing fragments of a specific test page in several browsers or several versions of one page in one browser.

The presented method can be used to test a web page for compatibility with a browser or to make changes to the base code that was used to render one web page in one browser.

In accordance with the present decision, a web page or a plurality of web pages that form a website are divided into several functional blocks. Each functional block has at least a first functional state and a second functional state, each of which is associated with a specific generated image, which are created as a result of the execution of the code corresponding to the functional block. When emulating, at the first moment of time, the execution of the code that was determined by the function block can capture, for this emulation procedure, a generated graphic image for each of the first functional state and the second functional state. These captured generated images can then be associated with the function block and stored as the original data array. At the second point in time, it is possible to perform the function block emulation and capture procedure for the given emulation, test generated graphic images for each of the first and second functional states to create a test data array. A comparison of the pixel values of the images from the original data array and the test data array allows you to identify changes between them. These changes can be used to gain access to the result of the changes on the web page or to the compatibility of the web page with specific browsers.

The generated graphic image that was created during the execution of this code is captured by one or more screenshots. These screenshots are referenced or otherwise linked to the source code. By isolating the individual parts of the functional code and linking them to individual screenshots, it becomes possible to see this part of the code at a much higher level of detail than is achieved, for example, through drop-down menus. When performing analysis at this level of detail, you can also see how exactly a particular piece of code will affect the appearance of the web page as a whole. In accordance with this decision, you can check the visual effects that are caused by the test part of the code, in relation to the adjacent formed parts of the web page, which relate to unchanged parts of the code. It is also possible to sequentially determine which parts of the source code were actually tested, unlike the rest of the page.

This method has some advantages in terms of testing specific blocks of a web page and linking these blocks of code with the corresponding screenshots, which can then be used as reference.

The present technology offers a method that simplifies the creation of a library of reference image groups for specific blocks of code. This library of reference screenshots can be used later to check further iterations on this web page or on the same version of the web page in a different browser for another generated image. In accordance with one embodiment, a data file is created as a result of a testing process that determines the reference image, the current image, and the differences between them. All of this can be done for each state in each browser within a particular webpage being tested. In another embodiment, a data file was created as a result of a testing process that defines a reference image, a specific image and the differences between them for each unlimited period of time within a specific web page that is being tested in the same browser.

To determine the differences in the test and reference images, according to one of the options, the comparison is based on the colors of the pixels in each image. When comparing the actual colors of the pixels, in contrast to the machine code of each of the colors, the solution has the advantage of compensating for the different shades of colors that can be displayed during the rendering of the web page.

In another embodiment, the color of each pixel is treated as simplified, in the same way that the human eye processes color. With such handling of the color of the reference image and the test image, it becomes possible to reduce the possibility of false matches, i.e. incorrectly distinguishing between two images.

Another object of the solution is to parse an individual web page into individual functional blocks or elements. When testing individual elements, an even greater level of detail can be achieved by using active elements that can be static or active.

Another object of the present solution is a system for regression testing the functionality of a web page, the system includes a first data store containing an initial data array including generated graphic images of at least part of the web page in the first functional state, the generated graphic images are associated with code from a function block, which when emulated affects the rendering of generated graphic images. The system further includes a processor configured to influence the emulation of the function block to create a test data array that includes captured generated images of at least a portion of the web page in a first functional state and a second functional state at a second point in time. When comparing the pixel values of the images in each of the original data array and the test data array, it is possible to determine the changes in the generated graphic image between the original and test data arrays.

Another object is a computer-readable storage medium including executable instructions (computer-readable codes) that are stored on a computer-readable medium, and upon which the electronic device is configured to perform the above method.

Brief Description of the Drawings

Various exemplary embodiments will now be described with reference to the respective drawings, wherein:

In FIG. 1 schematically shows a system corresponding to a solution;

In FIG. 2 is a flowchart of a method that can be implemented;

In FIG. 3 is a flowchart of a method that can be implemented in accordance with this decision;

In FIG. 4 shows a sample fragment of a web page that can be tested in accordance with this decision;

In FIG. 5 is a sample screenshot of a generated web page in a first functional state;

In FIG. 6 is a screen shot of a generated web page in a second functional state.

The implementation of the invention

In FIG. 1 shows a system 100 including a server 110, which is used to test web pages, and a specific effect from the main code, which is used to render a web page displayed using a browser on the display of one or more devices 120. One of one or multiple devices 120 may be used by a system operator to gain access to the functionality of system 100. It is important to keep in mind that system 100 is only one embodiment. Thus, the entire following description is presented only as a description of an illustrative example. This description is not intended to determine the scope or scope of this technology. Some useful examples of system modifications may also be covered by the following description. It is worth noting that the purpose of this is also exclusively to help in understanding, and not to determine the scope and boundaries of this technology. These modifications are not an exhaustive list, and it will be understood by those skilled in the art that other modifications are possible. In addition, this should not be interpreted so that where it has not yet been done, i.e. where examples of modifications have not been set forth, no modifications are possible, and / or that which is described is the only embodiment of this element. As will be clear to a person skilled in the art, this is most likely not the case. In addition, it should be borne in mind that the system is, in some specific manifestations, a fairly simple embodiment, and in such a case is presented here in order to facilitate understanding. As is clear to a person skilled in the art, many embodiments will have much greater complexity.

In the context of the present description, unless specifically indicated otherwise, "electronic device" means a hardware device capable of working with software suitable for solving the corresponding problem. Examples of electronic devices, among others, are personal computers (desktop computers, laptops, etc.), smartphones and tablets, and satellite navigation devices. It should be borne in mind that a device behaving like an electronic device in the present context can behave like a server with respect to other electronic devices. The use of the expression “electronic device” does not exclude the possibility of using multiple electronic devices to receive / send, execute or initiate the execution of any task or request, or the consequences of any task or request, or the steps of any method described above.

A general embodiment of an electronic device 120 is known in the art, and therefore will not be described in detail here. Suffice it to say that the electronic device 120 comprises a user input interface (e.g., a keyboard, mouse, touch pad, touch screen, etc.) for receiving user input; the aforementioned screen (e.g., screen, touch screen, printer, etc.) for providing visual or audio output to the user; a network communication interface (for example, a modem, network card, etc.) for two-way communication over a data network; and a processor connected to an input user interface, an output user interface, and a network communication interface, which is configured to perform various procedures, including those described below. To this end, the processor may store or have access to machine-readable instructions (machine-readable codes), the execution of which initiates the processor to perform the various procedures described herein.

In the context of the present description, unless specifically indicated otherwise, “server” means a computer program running on appropriate equipment that is able to receive requests (for example, from electronic devices 120) over the network 130 and to fulfill these requests or initiate the execution of these requests. The equipment may be a single physical computer or a single physical computer system, but neither is required. In the context of this technology, the use of the expression “server” does not mean that each task (for example, received instructions or requests) or any specific task will be received, completed or initiated to be executed by the same server (that is, by the same software software and / or hardware); this means that any number of software elements or hardware devices can be involved in the reception / transmission, execution or initiation of any request or the consequences of any request associated with the client device, and all this software and hardware can be one server or several servers , both options are included in the expression “at least one server”.

In the context of the present description, unless specifically indicated otherwise, the term "database" means any structured data set that is independent of the specific structure, database management software, hardware of the computer on which data is stored, used, or otherwise are available for use. The database may reside on the same hardware that runs the process that stores or uses the information stored in the database, or it may reside on separate hardware, such as a dedicated server or multiple servers.

In the context of the present description, unless specifically indicated otherwise, the term “component” means software (corresponding to a particular hardware context) that is necessary and sufficient to perform the specific specified (s) function (s).

The system 100 implemented in accordance with FIG. 1 is configured to perform a regression testing method for the appearance of a web page or pages, and with reference to FIG. 2 describes an example of how exactly this system can be used. For this, the solution presents a method that allows you to test fragments of a specific test page in several browsers or several versions of one page in one browser. In order to provide testing, a web page or a plurality of web pages together forming a web site were distributed into a plurality of function blocks that were stored in the test environment database 140 within the system (step 200).

Part of the testing function of these individual blocks is the test creation module 150, which provides the definition of one or more test suites for each function block (step 210). Certain test suites can be performed with the ability to simplify testing of each of these function blocks within one or more of their functional states. For example, it should be noted that the search block may have two states, the first of which displays a visual representation of the page after the search block was initially loaded and before the search was performed, and in the second state, the data is returned and displayed in the search block. Other examples of functional states are presented in the drop-down menus shown in FIG. 5 and 6. In FIG. 5 is an example of a displayed web page 500, on which three drop-down menus 510, 520 and 530 are visible. Each of these menus shown in FIG. 5 are in a first functional state, which in this case is not activated. In FIG. 6 shows the same web page 600 with the same drop-down menus 510, 520 and 530, but the first drop-down menu 510 is in a second functional state, in which menu 610 is visible. In this example, it is seen that the visual representation formed when rendering the code on screen for user perception will depend on which of the two states is implemented.

Creating a specific set of tests uses pre-created test procedures or scripts (both options are included in the concept of "test procedures"), which are stored in the database 160 of the test library. These pre-created test procedures or actions can be related to each other and used to program a series of steps that will be performed in relation to a specific function block. A series of steps are made with the ability to simulate user interaction with a web page and automatically bring the functional block to the desired state. For each block of the website to be tested, there is a set of tests created by the module 150 create tests. Each set of tests provides testing of one or several states of functional blocks and confirms the correctness of their execution. To test each state, it is necessary to create a functioning workflow or sequence of actions that, when executed in relation to a functional block, affects the block in such a way that it leads to (or leads through) these states. Actions can be tied to each other and, preferably, performed with the ability to be performed sequentially so that the first action in the test suite is performed and completed before the second action is initiated. Examples of actions may include:

- click (element) - click on the center of the element.

- doubleClick (element) - double click on the center of the element.

- mouseDown (element, [button]) - click the mouse button in the center of the element. Possible button values are: 0 - left, 1 - middle, 2 - right. By default, the left mouse button is used.

- mouseUp (element) - the previously pressed mouse button is released.

- mouseMove (element, [offset]) - move the mouse to this element. The offset is specified for the upper left corner of the element. If not specified, the mouse will be moved to the center of the element.

- dragAndDrop (element, dragTo) - drag an element onto another dragTo element.

- executeJS (function (window)) - run a specific function in the browser. The argument to the function is the browser window object.

Any test suite created will also include a screen capture area, which will affect the capture and storage of a particular part of the webpage being executed. The screen capture function can also be performed with the ability to capture an array of different areas of a web page and this function can be linked in such a way that allows several captures within the same test suite procedure: examples of ordinary parts of the code that can be stored in the library database 160 tests, and which can be used to create a test suite for later storage in a library of 150 test suites, include:

setUrl (url) - indicates the address of the web page from which screenshots will be taken. The URL refers to the rootUrl configuration field.

setCaptureElements ('selector1', 'selector2', ...}) - indicates CSS selectors for the elements that will be used to determine the capture area of the web page.

It should be noted that in order to confirm the correct capture (formation, retrieval) of the generated web page, it is necessary that the capture area be defined by the minimum bounding area for all elements, including window shadows, if possible. During the capture procedure, which will be executed automatically as part of any set of tests, specific generated images created as a result of the execution of the code that was determined by the tested function block will be captured using one or more screenshots. These screenshots are referenced or otherwise linked to the source code. By isolating the individual parts of the functional code and associating them with individual screenshots, it becomes possible to see this part of the code at a much greater level of detail than is achieved, for example, through drop-down menus and the like.

After creating a test set for a specific functional block of code within the test mode, it is necessary to perform a set of tests with respect to a specific code in order to determine the properties of the data set for a specific part of the functional code (step 220). As mentioned earlier, each of the individual test suites is stored in a specific location in the library of 150 test suites. Server 110 may be configured to perform a specific test suite or a combination of test suites using commands, such as a merge command, that will initiate the execution of one or more test suites located in a particular section of the test suites library, as defined in a particular case. It should be noted that, since the test suites were individually personalized or associated with specific functional code blocks that were defined within the database of functional code blocks 160, the execution of the test suite initiates automatic code processing within a specific functional block, including graphical drawing of the actions being tested on web page. The resulting visual display resulting from the execution of the test suite will then be captured based on the parameters defined in the test suite. In accordance with the present technology, after capturing, the reference set of images is then stored or in some other way connected with the database of the functional code block (step 230) to determine the initial data array. The original data array stores data indicating the behavior of the function block at the first moment in time. This point in time may indicate how the web page generated by processing the code that determines the functionality of the web page, or the parts of the web page defined by the test function blocks, look in the first browser, or simply indicate how the website will be displayed and run on a specific day at a specific time.

A set of tests can be performed in the background, but the execution of test sets can also be performed with the ability to provide the user with a graphical overview of the executable code during the execution of individual test sets. This can be useful for a number of reasons, including the fact that it provides a real-time demonstration of what will be captured. As will be explained in more detail below, a similar graphical overview, which is simultaneously displayed during the execution of individual test sets, can also be used to demonstrate in real time the differences between the reference set of captured images and images captured during the subsequent execution of the test set relative to the fact same functional block.

It should be noted that the formation of a database 140 of data about the testing environment and the functional code that was used to render these images is only the first step in the regression testing method. The second step is to compare these reference images, which were defined in the original data array, with the second set of captured images, the test data array. In FIG. 3 provides an overview of an exemplary scheme that can be adopted as part of this comparison method.

After applying a set of tests (s) to one or more functional blocks within a particular web page, this technology provides a second application of the same set of tests to a functional block, and it is assumed that it will essentially be performed in the same way as in the case of a tested reference function block (step 300). Examples of such sequential testing may include testing the same function block in different browser environments, or testing a modified version of the function block in the same browser environment that was used in the reference case, or a combination of the two.

Similar to that described with reference to FIG. 2, a similar application of the test suite affects the created set of captured images that are related to the functionality of the tested functional blocks. Like storing reference data for any function block, these captured images can be stored in a test database 170 (step 310) and define a test data set. It should be noted that the captured images may not be stored permanently, it is enough that they will be cached in memory, and this will allow to process these captured images in relation to the corresponding reference images (step 320).

From the foregoing, it will be understood that the present technology offers a method that simplifies the creation of an initial data array including a series of reference images for specific blocks of code. This library of reference screenshots can be used later to check further iterations on this web page or on the same version of the web page in a different browser for another generated image. In accordance with one embodiment, a data file is created as a result of a testing process that determines the appropriate images in each of the original data array and the data array under test and compares them with each other. The comparison is carried out using pixel values, such as pixel color and pixel intensity, and helps to determine the differences between the images in the two data sets. The data file may be stored in the test database 170 (step 330). All of this can be done for each state in each browser within a particular webpage being tested. In another embodiment, the data file was created as a result of a testing process that determines the reference image in the original data array, the specific image in the test data array and the differences between them for each unlimited time within a specific web page that is being tested in the same browser

By conducting analysis at this level of detail, you can also see how a particular piece of code will affect the overall appearance of a web page. For example, in accordance with this decision, it is possible to check the visual effects that are caused by the test part of the code, in relation to the adjacent formed parts of the web page, which relate to unchanged parts of the code. It is also possible to sequentially determine which parts of the source code were actually tested, unlike the rest of the page. This method has some advantages in terms of testing specific blocks of a web page and linking these blocks of code with the corresponding screenshots, which can then be used as reference.

In part of the comparison step 320, the system and method corresponding to the present technology determines the differences in the images that form the test data array and the original data array. In some embodiments of the present technology, the determination of differences can be made by pixel-by-pixel comparison of two sets of images. In one embodiment, this comparison is based on the color of the pixels in each image. When comparing the actual colors of the pixels, in contrast to the machine code of each of the colors, it mainly compensates for the different shades of colors that can be displayed during the rendering of the web page. After comparing the two captured images, it becomes possible to automatically create a report in one of various formats, including HTML.

In another embodiment, which does not affect the actual colors of the pixels in each image, the color of each pixel is considered simplified in the form in which the color is recognized by the human eye. With this treatment of the colors of the reference image and the test image, it becomes possible to reduce the possibility of false matches, i.e. incorrectly distinguishing between two images. In some embodiments, a simplified color code has been derived from more complex machine-defined colors. For example, methods are known for identifying machine-defined colors within primary colors and sub-colors (or shades). These sub-colors may not be captured by the human eye. In some embodiments of the present technology, system 100 supports a matching feature (not shown) that associates one or more complex colors, elusive to the human eye, with one simplified color that the human eye is able to perceive. For example, this mapping can associate three colors: <red>, <bright red> and <dark red> (or corresponding machine codes such as #ABCD) with the color <red>.

By analyzing captured images based on comparison, it is also possible to compensate for rendering noise, erroneous text or characters. For example, an image processing method, which is one of the methods that can be used in accordance with the present technology, can be performed with the ability to ignore the cursor in the screen capture procedure, both in the case of the reference image and in the case of the test image.

Since all test suites were created using the test library database 160, which contains predefined test procedures or scripts, and the test suites are created for a user-defined part of the code, it is possible that any test suites will span multiple function blocks on one web page . In this case, it is possible to create a screen capture that will illustrate the effect of processing one part of the code on another part of the web page. In FIG. Figure 4 presents an example of a fragment of a web page that was created as a result of processing two separate parts of a functional code, block A 400 and block B 410. Since the system and method allow the use of several capture regions (areas) for any one functional block, it is possible to identify a sequence of several blocks in relation to element code. Each piece of code can be associated with a corresponding visual representation of the code in the layout of the web page. In addition, since the test suite allows the user to determine the capture area, it is possible to define and mark the boundaries between the blocks within the captured screenshot, and gives a definition that the view is one of:

a) one block in the zero state (for example, a button in the drop-down menu, the button is not selected;

b) two (several) blocks in the zero state;

c) one block with activated functions (pressed button in the drop-down menu);

d) two buttons and, for example, a drop-down menu overlaps the second button.

Part of the regression testing method is, as emphasized above, testing the same functional code in different browser environments or testing different versions of the same code in the same browser environment. To provide this function, the system 100 may interact with a third party providing automation tools 180 (see FIG. 1), for example, those that can be used to automate the execution of a web application within a browser environment or to simulate the execution of the same web pages in various browsers. Examples of such tools can be Selenium - a set of different software tools, each of which has different approaches to testing automation, which can simplify testing in different browser environments or PhantomJS, which is a console version of the webkit browser, and can be executed with the ability to process a function block and Modified versions of this function block as part of what is defined as the same browser environment. Although these automation tools are shown as being outside the system 100, some embodiments of these tools can be installed inside the system 100 or accessed through the network 130. It should be noted that any of these types of tools can be selected as part of creating specific test suites.

It should also be noted that the functionality described here was presented with reference to testing specific specific functional blocks of code within a particular web page or groups of web pages forming a website. As mentioned earlier, a user-defined definition of a functional block of code, for example, CSS code, on a particular web page can be tested, and created or formed web pages that are associated with this particular page can be saved and used in test mode. By dividing the web page into composite functional blocks and further testing these blocks, this technology makes it possible to evaluate these blocks in great detail in the context of the overall appearance of the web page. When determining the capture area of a function block, it is possible to determine how exactly various blocks can affect the overall display, including parts of the web page that are the results of the process of rendering another function block.

System 100 allows a user to break a web page into composite functional blocks, which can be done to subsequently report which parts of the web page have been tested. As described previously, after creating a test suite for a function block and storing it in a library of 150 test suites, this particular test suite can be used independently or simultaneously with other test suites. If multiple test suites are applied to the same web page, the system can be configured to determine which parts of the code on the original web page have been tested. This can be expressed using, for example, a color sequence, while those parts that were completely captured in at least one test can be marked in the first color, partially in the second color, and were not captured at all in the third color. By color coding using a sequence of type "traffic light" (red, orange, green) can be created quite a clear picture.

It should be noted that only an example embodiment of a system and method for simplifying website regression testing has been described. Such a system and method have many advantages, such as:

- Compatible with various browsers;

- The ability to separately test parts of a web page;

- The position and size of the captured element can be determined regardless of part of their base code and can be calculated in a huge number of different ways, including, for example, window shadows and outline properties;

- Through image-based analysis, it is possible to provide selective testing so that some specific differences between images (processing noise, inserted text, and so on) are ignored;

- Creating a report on testing the web page as a whole and, accordingly, the scope of this testing.

In the context of the present description, unless specifically indicated otherwise, the term “computer-supported computer information medium” means a medium of absolutely any type and nature, including RAM, ROM, disks (CDs, DVDs, diskettes, hard drives, etc.). e.), USB flash drives, solid state drives, tape drives, etc.

In the context of the present description, unless specifically indicated otherwise, the words "first", "second", "third", etc. used in the form of adjectives solely to distinguish the nouns to which they relate from each other, and not for the purpose of describing any specific relationship between these nouns. So, for example, it should be borne in mind that the use of the terms “first server” and “third server” does not imply any ordering, chronology, hierarchy or ranking (for example) of servers / between servers, as well as their use (in itself) does not imply that a certain "second server" must exist in a given situation. Hereinafter, as indicated here in other contexts, reference to the “first” element and the “second” element does not exclude the possibility that it is one and the same actual real element. So, for example, in some cases, the “first” server and the “second” server can be the same software and / or hardware, and in other cases they can be different software and / or hardware.

Each embodiment includes at least one of the aforementioned objectives and / or objects. Additional and / or alternative characteristics, aspects, and advantages of the embodiments are apparent from the description, the accompanying drawings, and the accompanying technology claims.

Those skilled in the art will understand that in the present description, the expression “receiving data” from a user means receiving by the electronic device data from the user in the form of an electronic (or other) signal. In addition, those skilled in the art will understand that displaying data to a user via a graphical user interface (e.g., an electronic device screen and the like) may include transmitting a signal to the graphical user interface, this signal contains data that can be processed, and at least a portion of this data may be displayed to the user via a graphical user interface.

Some of these steps, as well as signal transmission-reception, are well known in the art and therefore have been omitted in specific parts of the description for simplicity. Signals can be transmitted-received using optical means (for example, optical connection), electronic means (for example, wired or wireless connection) and mechanical means (for example, based on pressure, temperature or other suitable parameter).

Modifications and improvements to the above described embodiments will be apparent to those skilled in the art. The preceding description is provided as an example only and is not subject to any restrictions. Thus, the scope of legal protection is limited only by the scope of the attached claims.

Claims (27)

1. A method of regression testing the functionality of a web page, including: determining at least one functional block of the web page, configured to receive at least the first and second functional state, each of which is associated with a particular generated image as a result of executing code corresponding to the functional block; emulation at the first instant of execution of the code of the functional block and capture of the generated images for each of the first and second functional states; establishing a connection between the captured generated images of the functional unit and storing the captured images in the original data array; emulation at the second time of execution of the code of the function block and capture for testing the generated images for each of the first and second functional states to create a test data array; comparing the pixel values of the images in each of the original data array and the test data array to determine the changes between the original and test data arrays. 2. The method according to p. 1, in which the emulation of the execution of at least part of the code of the functional block is carried out by initially defining a set of tests for this functional block, determined by accessing pre-created testing procedures stored in the database of the test library. 3. The method according to claim 2, in which the testing procedures are related to each other and form a series of stages, the implementation of which with respect to a specific functional block imitates the interaction of the user with the web page on which the functional block is located. 4. The method of claim 3, wherein the test suite is configured to test a functional unit in the first and second functional states and capture images with each of these two functional states. 5. The method according to claim 1, wherein creating a library of source data arrays containing images associated with a particular function block. 6. The method according to p. 1. in which each of the test data array and the original data array contains the generated image captured during the emulation of the functional code in one browser environment. 7. The method according to claim 1. in which each of the test data array and the original data array contains generated graphic images captured during emulation of the function block code in various browser environments to provide information about the compatibility of the web page with different browser environments. 8. The method according to claim 1, wherein creating a data file containing data indicating changes between the test data array and the original data array. 9. The method according to claim 8, in which the difference between the test data array and the original data array for each of the states created by emulating the function block code is determined. 10. The method of claim 1, wherein comparing the pixel values of the images by analyzing the pixels in each image in the test data array and the output data array. 11. The method according to p. 10, in which when comparing translate the colors of each pixel in a simplified version. 12. The method according to p. 1, which carry out semantic analysis of the code to determine the web page with the determination of which parts of the code are located in functional blocks. 13. The method according to p. 12, which determines which of the functional blocks was tested at the second point in time. 14. Machine-readable storage medium, including machine-readable codes made with the possibility of their execution by a computing device with the implementation of the method according to p. 1. 15. System regression testing the functionality of a web page, including: the first data store containing the initial data array with the generated image of at least part of the web page in the first and second functional states, the generated images being associated with a function block code, which when emulated affects the rendering of the generated image; a processor configured to: emulating at the first time the code of the function block is executed and capturing the generated images for each of the first and second functional states; establishing a connection between the captured generated images of the functional unit and storing the captured images in the original data array; emulating a function block to create a test data array containing captured generated images of at least a portion of the web page in the first and second functional states at the second time moment; comparing the pixel values of the images in each of the original data array and the test data array with determining the changes in the generated images between the original and test data arrays. 16. The system of claim 15, which includes a library of test suites containing predefined test procedures used in the test suites to evaluate the functionality of a functional unit.

Images