Automatic browser compatibility testing method and related device

Abstract

The invention discloses an automatic browser compatibility testing method and a related device, and relates to the technical field of software, a to-be-executed target test task is obtained, and the target test task comprises a test case and a test environment; target execution machines matched with the test environments are determined in the execution machine cluster, main batch tasks and sub-batch tasks associated with the main batch tasks are generated, and the sub-batch tasks correspond to the test environments one to one; under the sub-batch tasks, executing the test case in the test environment through the target execution machine; and under the main batch task, counting execution conditions of the test cases under the sub-batch tasks. According to the browser compatibility testing method and device, distribution and execution of the compatibility testing tasks can be achieved, the testing cases are executed in the testing environment through the execution machine under the sub-batch tasks, the execution conditions of the testing cases of the sub-batch tasks are counted under the main batch tasks, automatic testing of browser compatibility can be achieved, and the testing efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of software technology, and in particular to an automated browser compatibility testing method and related devices. Background Art

[0002] With the rapid development of network applications, the increasing types and number of browsers, and the continuous updating of the same browser version, browser compatibility testing of network applications has become one of the difficulties in the testing field.

[0003] Current related testing technologies have problems such as reliance on manual testing, high labor costs, and low test coverage and efficiency. Summary of the invention

[0004] In view of the above problems, the present application provides an automated browser compatibility testing method and related devices to achieve the purpose of automated browser compatibility testing. The specific scheme is as follows:

[0005] The first aspect of the present application provides an automated browser compatibility testing method, the automated browser compatibility testing method comprising:

[0006] Obtaining a target test task to be executed, wherein the target test task includes a test case and a test environment;

[0007] Determine a target execution machine matching the test environment in the execution machine cluster, and generate a main batch task and sub-batch tasks associated with the main batch task, wherein the sub-batch tasks correspond to the test environment one by one;

[0008] Under the sub-batch task, executing the test case in the test environment by the target execution machine;

[0009] Under the main batch task, statistics are collected on the execution status of the test cases under the sub-batch tasks.

[0010] In a possible implementation, obtaining a target test task to be executed includes:

[0011] receiving a test task, wherein the test task has a priority;

[0012] A task with the highest priority among the test tasks is used as the target test task.

[0013] In a possible implementation, determining a target execution machine matching the test environment in the execution machine cluster includes:

[0014] Obtaining the running status of each executor in the executor cluster through a heartbeat connection;

[0015] An execution machine in the execution machine cluster that is in a working state and matches the test environment is used as the target execution machine.

[0016] In a possible implementation, executing the test case in the test environment by the target execution machine includes:

[0017] Determine a resource pool required for executing the test case in the test environment, and configuration data required for executing the test case in the resource pool;

[0018] The resource pool is subjected to data verification according to the type of the configuration data, and after the resource pool passes the data verification, the test case is executed in the test environment by the target execution machine; wherein, for the first configuration data of non-consumable type in the configuration data, if there is one of the first configuration data in the resource pool, it is determined that the resource pool passes the data verification; for the second configuration data of consumable type in the configuration data, if the number of the second configuration data in the resource pool meets the number of times the test case is used, it is determined that the resource pool passes the data verification.

[0019] In a possible implementation, the counting of execution status of the test cases under the sub-batch tasks includes:

[0020] By reading the case execution table maintained by the sub-task batch, the execution status of the test cases under the sub-batch task is counted.

[0021] In a possible implementation, the case execution table includes a checkpoint screenshot of the test case, and the automated browser compatibility testing method further includes:

[0022] Obtain benchmark images through automated interface testing;

[0023] By comparing the detection point reference image with the check point screenshot, abnormal points are marked in the check point screenshot.

[0024] A second aspect of the present application provides an automated browser compatibility testing device, the automated browser compatibility testing device comprising:

[0025] A task acquisition module is used to acquire a target test task to be executed, wherein the target test task includes a test case and a test environment;

[0026] A test execution module is used to determine a target execution machine that matches the test environment in an execution machine cluster, and generate a main batch task and a sub-batch task associated with the main batch task, wherein the sub-batch task corresponds to the test environment one by one; under the sub-batch task, the test case is executed under the test environment by the target execution machine; under the main batch task, the execution status of the test case under the sub-batch task is counted.

[0027] A third aspect of the present application provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements the automated browser compatibility testing method of the first aspect or any implementation of the first aspect.

[0028] A fourth aspect of the present application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0029] The memory is used to store computer programs;

[0030] The processor is used to execute the computer program so that the electronic device can implement the automated browser compatibility testing method of the above-mentioned first aspect or any implementation manner of the first aspect.

[0031] In a fifth aspect, the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement the automated browser compatibility testing method of the above-mentioned first aspect or any implementation method of the first aspect.

[0032] By means of the above technical scheme, the present application provides an automated browser compatibility testing method and related devices, which obtain the target test task to be executed, wherein the target test task includes a test case and a test environment; determine the target execution machine that matches the test environment in the execution machine cluster, and generate a main batch task and a sub-batch task associated with the main batch task, wherein the sub-batch task corresponds to the test environment one by one; under the sub-batch task, execute the test case under the test environment by the target execution machine; under the main batch task, count the execution status of the test case under the sub-batch task. The present application can realize the allocation and execution of compatibility test tasks, execute the test case under the test environment by the execution machine under the sub-batch task, and count the execution status of the test case of the sub-batch task under the main batch task, which can realize the automated testing of browser compatibility and improve the testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0034] Figure 1 A flowchart of an automated browser compatibility testing method provided in an embodiment of the present application;

[0035] Figure 2 A partial flow chart of an automated browser compatibility testing method provided in an embodiment of the present application;

[0036] Figure 3 A schematic diagram of another part of the flow chart of an automated browser compatibility testing method provided in an embodiment of the present application;

[0037] Figure 4 A schematic diagram of another part of the flow chart of an automated browser compatibility testing method provided in an embodiment of the present application;

[0038] Figure 5 An example diagram of the relationship between a resource pool, a test environment, and a test case provided in an embodiment of the present application;

[0039] Figure 6 A schematic diagram of the structure of an automated browser compatibility testing device provided in an embodiment of the present application;

[0040] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0042] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0043] The terms "first", "second" etc. in the specification of the application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable in appropriate circumstances, and this is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0044] To facilitate understanding of this application, the following first describes the relevant concepts involved in this application:

[0045] Interface automation: also known as UI (User Interface) automation. Traditional interface testing is to operate the user interface manually to discover program defects. Interface automation is to use code to replace manual operations to complete the test of the user interface.

[0046] Interface automation component based on control elements: It is a tool for testing network applications. The test runs directly in the browser, just like a real user is operating. It supports the mainstream browsers currently used by most users. The main functions of this tool include: testing compatibility with browsers - testing whether your application can work well on different browsers and operating systems, testing system functions - creating regression tests to verify software functions and user needs. It supports automatic recording of actions and automatic generation of test scripts in different programming languages.

[0047] Browser driver: directly controls the browser through native browser support or browser extensions.

[0048] Resource pool: Each resource pool on the server is a list that stores specific data and is mainly used to automatically allocate data to test cases.

[0049] Execution machine: A physical machine that automatically executes the interface automation cases and uploads the results to the server after execution.

[0050] As a medium connecting personal terminals with the Internet, the browser's working process is mainly divided into two parts: communication process and page rendering. The communication process refers to first establishing a connection between the local terminal and the designated remote server, and then communicating between the browser and the server, that is, sending an HTTP request. The browser's network communication module is responsible for completing the preliminary communication. The page rendering process refers to processing and organizing the received web page content, calculating the web page display mode, and then outputting it to the display device. The above work is completed by the browser's rendering engine. This process is the core function of the browser and also the feature of different browsers. The mainstream browsers on the market are similar in the communication department, but due to the different kernels and supported hypertext markup language standards, a variety of solutions are provided in the page rendering link, which leads to differences in the page display effect when the same code is parsed and rendered by different browsers, and even different versions of the same browser may have such differences. With the popularization of personal terminals, user experience has been valued, and developers have summarized the above differences as browser compatibility issues. The browser compatibility test of traditional network applications is mainly based on manual testing. Manually detecting incompatibility issues by visually checking the web pages presented by different browser types and versions requires high labor costs, is time-consuming, and has low testing efficiency.

[0051] In order to solve the above-mentioned browser compatibility testing problem, the industry uses recorded interface automation scripts, and then executes these scripts in different environments, and uses the running results of the scripts to determine whether there are compatibility issues in a specific environment. To this end, the industry often needs to install a large number of virtual machines and establish long connections with the server, which puts a lot of performance pressure on the server and easily causes congestion. In addition, the recorded interface automation scripts do not have unified data management. When executed in a distributed manner, the same case is likely to have data conflicts when executed in multiple test environments, resulting in case execution failure and affecting test efficiency. In other words, the automated compatibility testing method currently used in the industry has the problem of putting a lot of performance pressure on the server and data conflicts between cases.

[0052] See also Figure 1 , Figure 1 A flowchart of an automated browser compatibility testing method provided in an embodiment of the present application. Figure 1 As shown, an automated browser compatibility testing method provided in an embodiment of the present application includes the following steps S10 to S40, which are described in detail below.

[0053] S10, obtaining a target test task to be executed, wherein the target test task includes a test case and a test environment.

[0054] In the embodiment of the present application, when the tester applies to perform compatibility testing, he selects the test environment to be executed and the interface automation case (i.e., test case) on the front-end page to generate the test task to be executed (i.e., target test task), and sends the target test task to the server. It should be noted that the test case recorded by the tester adopts the business language framework, which can be converted into the syntax of different frameworks when the case is executed, thereby supporting multiple interface automation frameworks and reducing the dependence on manual testing.

[0055] S20, determining a target execution machine matching the test environment in the execution machine cluster, and generating a main batch task and sub-batch tasks associated with the main batch task, wherein the sub-batch tasks correspond to the test environment one by one.

[0056] In the embodiment of the present application, the server records the configuration information of each execution machine in the execution machine cluster in the database, which is maintained and managed by the system support personnel. After obtaining the target test task, the server can determine the execution machine (i.e., the target execution machine) that matches the test environment in the execution machine cluster based on the configuration information in the database. The target execution machine can be one execution machine or multiple execution machines, which is not limited in the embodiment of the present application.

[0057] Furthermore, the server generates a main batch task and sub-batch tasks associated with the main batch task, and the sub-batch tasks can be one or more. Specifically, the server puts the main batch task and the sub-batch tasks into a table in the database, and the main batch task is associated with the sub-batch task in the table in the database, and the execution status of the sub-batch tasks is counted to generate the final compatibility test execution result report.

[0058] It should be noted that a sub-batch task corresponds to a test environment in the target test task, includes configuration information of the test environment, and is associated with scripts of all test cases that need to be executed.

[0059] In actual applications, if the matching fails, that is, there is no executor matching the test environment in the executor cluster, the server returns a matching failure message to the tester. The tester changes to a similar test environment based on the information or applies to the system support staff for an additional test environment. The system support staff will re-initiate the test task after updating the configuration of the executor.

[0060] S30, executing the test case in the test environment through the target execution machine under the sub-batch task.

[0061] In the embodiment of the present application, for ease of understanding, an example is given in which a target test task includes n test cases and m test environments. For each i test environments in the m test environments, the server determines an execution machine that matches the test environment in the execution machine cluster, assuming that there are a.

[0062] After the server generates a main batch task and m sub-batch tasks, for the i-th sub-batch task corresponding to each i test environment, n test cases are executed in the test environment by a executor. Specifically, in the process of executing n test cases in the test environment by a executor, if n is a small value, the first executor among the a executors to claim the task will claim and execute all n test cases, so that other executors will not receive the sub-batch task, but continue to poll to find other sub-batch tasks; if n is a large value, the a executors will each receive a part of the test cases to execute, and the rest will be received by other executors that meet the requirements, or the executors will receive them again after executing the previously received test cases.

[0063] After receiving the test case, the execution machine can download the case table or the script of the test case. After the download is complete, there is no need to maintain a connection with the server, which can effectively avoid the problem of excessive server load caused by multiple execution machines connecting to the server while executing.

[0064] After downloading, the execution machine needs to verify the test case. If the verification fails, the execution machine will upload the information of the test case verification failure to the server. If the verification passes, the execution machine will start the corresponding framework to execute the test case according to the execution method of the test case. When the test case is executed, it will convert the business language into the corresponding framework language for execution, or directly run the script of the test case.

[0065] S40, under the main batch task, counting the execution status of the test cases under the sub-batch tasks.

[0066] In the embodiment of the present application, after the execution of each sub-batch task is completed, the execution status of the test cases under the sub-batch task can be counted under the main batch task, such as the test cases executed by each execution and the execution results.

[0067] In a possible implementation, a sub-batch task can maintain a case execution table, in which the execution status of its test cases is recorded. In this regard, in the embodiment of the present application, step S40 "under the main batch task, counting the execution status of the test cases under the sub-batch task" can adopt the following steps:

[0068] By reading the case execution table maintained by the subtask batch, the execution status of the test cases under the subbatch task is counted.

[0069] After the tasks of the subtask batch are initialized, the case status of the subbatch task is not started and no executor is available to collect it. According to the matching results of the test environment, the subbatch task is bound to the successfully matched executor and saved in the database, waiting for the corresponding executor to be idle before collecting the test cases under the subbatch task.

[0070] In a possible implementation, in order to assist testers in finding abnormal points on the interface and improve test coverage, in the embodiment of the present application, the case execution table includes a checkpoint screenshot of the test case. In this regard, an automated browser compatibility testing method provided in the embodiment of the present application also includes the following steps:

[0071] Obtain the benchmark image through interface automated testing; by comparing the detection point benchmark image with the checkpoint screenshot, mark the abnormal points in the checkpoint screenshot.

[0072] In the embodiment of the present application, after the execution machine finishes executing the test case, the execution machine will determine whether the test case has passed or not according to whether all the checkpoints set in the case have passed, and then upload the execution result and checkpoint screenshots of the test case to the case execution table. After the execution machine completes the last test case received under the subtask batch, it will determine whether the sub-batch task has executed all the test cases. If so, it will update the final execution status of the subtask batch, and then update the execution status of the main task batch.

[0073] After the compatibility test task is completed, the tester can view the overall execution status on the result viewing page, including the overall pass rate, the pass rate of each test environment, and the pass rate of each test case in multiple test environments. The tester can view the execution details of the test case in a certain test environment and the screenshots of the checkpoints by clicking the test case and selecting the test environment.

[0074] In addition, the present application adds an image comparison function. Specifically, after the business language syntax for image comparison is added to the test case, the test case will automatically save the screenshot as the inspection reference image after the tester performs the normal interface automation test. During the compatibility test, the checkpoint screenshots in each test environment are used as the tested image for image comparison with the reference image, and the places where there are differences from the reference image are marked in the checkpoint screenshots as abnormal points. The image comparison algorithm performs multi-dimensional calculations based on the brightness, contrast and structure of the image, and can identify the visual differences of the transaction page in different environments. The result display page can simultaneously display screenshots of the test case in multiple test environments, and the checkpoint screenshots have been marked with abnormal points by the image comparison algorithm. Therefore, testers can quickly find abnormal points on the interface and effectively improve test efficiency.

[0075] In a possible implementation, there are priorities between test tasks. For example, test tasks can be divided into urgent and ordinary. Urgent test tasks have the highest execution priority, which can allow the executor to suspend the ordinary test tasks being executed and execute the urgent test tasks instead. When the executor completes the urgent test task, if the executor does not receive a new urgent test task, it will continue to complete the ordinary test tasks it has received before. Figure 2 , Figure 2 A partial flow chart of an automated browser compatibility testing method provided in an embodiment of the present application. Figure 2 As shown, an automated browser compatibility testing method is provided in an embodiment of the present application, wherein "obtaining a target test task to be executed" in step S10 may include the following steps S101 to S102, and these steps are described in detail below.

[0076] S101, receiving a test task, the test task has a priority.

[0077] S102: taking a task with the highest priority among the test tasks as a target test task.

[0078] In the embodiment of the present application, the server can process multiple test tasks at the same time, each test task has a corresponding priority. The task with the highest priority among the test tasks is used as the target test task. At this time, the execution machine suspends the test tasks with lower priority being executed and executes the target test task instead.

[0079] In one possible implementation, the executor can establish a heartbeat connection with the server, which allows the server to determine the running status of the executor and thus match the executor to the test environment. Figure 3 , Figure 3 Another partial flow chart of an automated browser compatibility testing method provided in an embodiment of the present application. Figure 3 As shown, an automated browser compatibility testing method is provided in an embodiment of the present application, wherein "determining a target execution machine that matches the test environment in the execution machine cluster" in step S20 may include the following steps S201 to S202, and these steps are described in detail below.

[0080] S201, obtaining the running status of each executor in the executor cluster through a heartbeat connection.

[0081] S202: An execution machine in the execution machine cluster that is in a working state and matches the test environment is used as a target execution machine.

[0082] In the embodiments of the present application, different operating systems, browser types and versions may be installed in each execution machine, and a client may be deployed to control the operation of the execution machine. After the client is started, it has the functions of maintaining the state of the execution machine and receiving and executing tasks. In actual applications, the maintenance of the execution machine state can be achieved through a state component, which periodically reads the configuration information of the execution machine from the server database to update the state of the execution machine. When the system support personnel modify the state of the execution machine on the server and set it to the working state, the execution machine starts running, and the state component starts the heartbeat component and the task component.

[0083] The heartbeat component periodically informs the server of the current status of the executor by updating its status in the configuration information. The server will assign tasks to the executor only when the executor is in working state. After the task component receives the test case of the executor, it uploads the execution result to the server.

[0084] When the executor is running, the task component will periodically poll to see if there are any test tasks that the executor can claim. The priority for claiming test tasks is urgent tasks > claimed but unfinished ordinary tasks > unclaimed ordinary tasks. The client will give priority to claiming test tasks marked as urgent. When the client finds that there are no urgent test tasks currently being executed, it will claim the urgent task regardless of whether it is executing an ordinary task. After claiming the urgent test task, the client will restart to interrupt the ordinary test tasks that may be executed. When a test task is found to be available, the client will update the execution status of the case in the test task and inform the server and other executors that the case in the test task has been claimed to avoid repeated claiming of tasks and data conflicts.

[0085] In a possible implementation, test data is distributed to test cases by automatically sampling data, which effectively avoids data conflicts and improves test efficiency. Figure 4 , Figure 4 Another partial flow chart of an automated browser compatibility testing method provided in an embodiment of the present application. Figure 4 As shown, an automated browser compatibility testing method is provided in an embodiment of the present application, wherein "executing the test case in the test environment by the target execution machine" in step S30 may include the following steps S301 to S302, and these steps are described in detail below.

[0086] S301, determining a resource pool required for executing a test case in a test environment, and configuration data required for executing the test case in the resource pool.

[0087] S302, perform data verification on the resource pool according to the type of configuration data, and after the resource pool passes the data verification, execute the test case in the test environment through the target execution machine; wherein, for the first configuration data of the non-consumable type in the configuration data, if there is a first configuration data in the resource pool, it is determined that the resource pool has passed the data verification; for the second configuration data of the consumable type in the configuration data, if the number of the second configuration data in the resource pool meets the number of times the test case is used, it is determined that the resource pool has passed the data verification.

[0088] There are often some unique parameters in the transaction process, such as the number generated after adding a new transaction. When performing compatibility testing, if concurrent execution is used, there will be a situation where test cases of the same transaction process are executed in different test environments. If these test cases all use the same configuration data, only one test case will pass, and the other test cases will fail because the process status has been transferred, or multiple execution machines use the same account to log in, and finally only one execution machine will succeed.

[0089] In order to solve the above problems, this application designs a mechanism for extracting numbers from the resource pool - in addition to filling in fixed values ​​when executing test cases, the configuration data of the corresponding test environment can also be extracted from the resource pool. The configuration data in the resource pool is divided into consumable and non-consumable types. The non-consumable type is generally reusable data, while the consumable type is non-recyclable after each use, such as transaction numbers. The methods of data extraction include executing the database language to extract from the database of the test environment or manually filling in by testers. Multiple test cases can share a resource pool, and a test case can use multiple resource pools. Each resource pool also corresponds to multiple test environments. When a new test task generates multiple sub-batch tasks, first count which resource pools are used for each test case and the number of configuration data to be extracted from each resource pool. For non-consumable configuration data, in each test environment, the resource pool has one piece of data to pass the data verification; for consumable configuration data, the resource pool must contain configuration data with the number of uses in each test environment to pass the verification. Through the resource pool approach, you can modify the configuration data in the resource pool at any time to cover the corresponding test cases, without having to modify each test case separately, which reduces the cost of maintaining cases and avoids data conflicts during concurrent execution.

[0090] See also Figure 5 , Figure 5 This is an example diagram of the relationship between a resource pool, a test environment, and a test case provided in an embodiment of the present application. Figure 5As shown, the configuration data in the resource pool includes account information. The account information of test environment 1 in the resource pool includes account 1 to account X, and the account information of test environment 2 in the resource pool includes account X+1 to 2X. Test cases 1 to 3 are running in both test environment 1 and test environment 2.

[0091] Through the above description, an automated browser compatibility testing method provided by an embodiment of the present application completes automated compatibility testing through distributed execution of interface automation cases. It does not require the execution machine to maintain a connection with the server for a long time, and can effectively reduce the performance pressure on the server. At the same time, the execution machine can test the priority of the task to selectively execute interface automation cases, so that urgent tasks can be completed first. Using resource pool draws to allocate to cases reduces the cost of case maintenance and avoids data conflicts. In addition, image comparison is used to assist testers in quickly discovering differences and improving testing efficiency.

[0092] An automated browser compatibility testing method provided by an embodiment of the present application is introduced above. A device for executing the automated browser compatibility testing method will be introduced below.

[0093] See also Figure 6 , Figure 6 A schematic diagram of the structure of an automated browser compatibility testing device provided in an embodiment of the present application. Figure 6 As shown, an automated browser compatibility testing device provided by an embodiment of the present application includes:

[0094] The task acquisition module 10 is used to acquire the target test task to be executed, wherein the target test task includes a test case and a test environment;

[0095] The test execution module 20 is used to determine the target execution machine that matches the test environment in the execution machine cluster, and generate a main batch task and sub-batch tasks associated with the main batch task, and the sub-batch tasks correspond to the test environment one by one; under the sub-batch task, the test case is executed in the test environment by the target execution machine; under the main batch task, the execution status of the test case under the sub-batch task is counted.

[0096] In a possible implementation, the task acquisition module 10 for acquiring the target test task to be executed is specifically used to:

[0097] Receive test tasks, where the test tasks have priorities; and use a task with the highest priority among the test tasks as a target test task.

[0098] In a possible implementation, the test execution module 20 for determining a target execution machine matching the test environment in the execution machine cluster is specifically configured to:

[0099] The running status of each executor in the executor cluster is obtained through the heartbeat connection; the executor in the executor cluster that is in working status and matches the test environment is used as the target executor.

[0100] In a possible implementation, the test execution module 20 for executing the test case in the test environment by the target execution machine is specifically used to:

[0101] Determine the resource pool required for executing the test case in the test environment, and the configuration data required for execution in the resource pool; perform data verification on the resource pool according to the type of configuration data, and after the resource pool passes the data verification, execute the test case in the test environment through the target execution machine; wherein, for the first configuration data of the non-consumable type in the configuration data, if there is a first configuration data in the resource pool, it is determined that the resource pool passes the data verification; for the second configuration data of the consumable type in the configuration data, if the number of the second configuration data in the resource pool meets the number of times the test case is used, it is determined that the resource pool passes the data verification.

[0102] In a possible implementation, the test execution module 20 for counting the execution status of the test cases under the sub-batch tasks is specifically used to:

[0103] By reading the case execution table maintained by the subtask batch, the execution status of the test cases under the subbatch task is counted.

[0104] In a possible implementation, the case execution table includes a checkpoint screenshot of the test case, and the test execution module 20 is further used to:

[0105] Obtain the benchmark image through interface automated testing; by comparing the detection point benchmark image with the checkpoint screenshot, mark the abnormal points in the checkpoint screenshot.

[0106] It should be noted that the detailed functions of each module in the embodiment of the present application can be found in the corresponding public part of the above-mentioned automated browser compatibility testing method embodiment, and will not be repeated here.

[0107] The present application also provides an electronic device in an embodiment. Figure 7 , Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0108] like Figure 7As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 to a random access memory (RAM) 703. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 703. The processing device 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0109] Typically, the following devices may be connected to the I / O interface 705: an input device 706 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 707 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 708 including, for example, a memory card, a hard disk, etc.; and a communication device 709. The communication device 709 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Figure 7 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0110] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any one of the automated browser compatibility testing methods provided in the embodiments of the present application.

[0111] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any one of the automated browser compatibility testing methods provided in the embodiments of the present application.

[0112] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0113] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0114] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0115] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

Claims

1. An automated browser compatibility testing method, characterized in that: The automated browser compatibility testing method comprises: Obtaining a target test task to be executed, wherein the target test task includes a test case and a test environment; Determine a target execution machine matching the test environment in the execution machine cluster, and generate a main batch task and sub-batch tasks associated with the main batch task, wherein the sub-batch tasks correspond to the test environment one by one; Under the sub-batch task, executing the test case in the test environment by the target execution machine; Under the main batch task, statistics are collected on the execution status of the test cases under the sub-batch tasks.

2. The automated browser compatibility testing method according to claim 1, characterized in that: The obtaining of the target test task to be executed includes: receiving a test task, wherein the test task has a priority; A task with the highest priority among the test tasks is used as the target test task.

3. The automated browser compatibility testing method according to claim 1, characterized in that: The step of determining a target execution machine matching the test environment in the execution machine cluster includes: Obtaining the running status of each executor in the executor cluster through a heartbeat connection; An execution machine in the execution machine cluster that is in a working state and matches the test environment is used as the target execution machine.

4. The automated browser compatibility testing method according to claim 1, characterized in that: The executing the test case in the test environment by the target execution machine includes: Determine a resource pool required for executing the test case in the test environment, and configuration data required for executing the test case in the resource pool; The resource pool is subjected to data verification according to the type of the configuration data, and after the resource pool passes the data verification, the test case is executed in the test environment by the target execution machine; wherein, for the first configuration data of non-consumable type in the configuration data, if there is one of the first configuration data in the resource pool, it is determined that the resource pool passes the data verification; for the second configuration data of consumable type in the configuration data, if the number of the second configuration data in the resource pool meets the number of times the test case is used, it is determined that the resource pool passes the data verification.

5. The automated browser compatibility testing method according to claim 1, characterized in that: The counting of the execution status of the test cases under the sub-batch tasks includes: By reading the case execution table maintained by the sub-task batch, the execution status of the test cases under the sub-batch task is counted.

6. The automated browser compatibility testing method according to claim 5, characterized in that: The case execution table includes a checkpoint screenshot of the test case, and the automated browser compatibility testing method further includes: Obtain benchmark images through automated interface testing; By comparing the detection point reference image with the check point screenshot, abnormal points are marked in the check point screenshot.

7. An automated browser compatibility testing device, characterized in that: The automated browser compatibility testing device comprises: A task acquisition module is used to acquire a target test task to be executed, wherein the target test task includes a test case and a test environment; A test execution module is used to determine a target execution machine that matches the test environment in an execution machine cluster, and generate a main batch task and a sub-batch task associated with the main batch task, wherein the sub-batch task corresponds to the test environment one by one; under the sub-batch task, the test case is executed under the test environment by the target execution machine; under the main batch task, the execution status of the test case under the sub-batch task is counted.

8. A computer program product, characterized in that It comprises computer-readable instructions, and when the computer-readable instructions are executed on an electronic device, the electronic device implements the automated browser compatibility testing method as claimed in any one of claims 1 to 6.

9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the automated browser compatibility testing method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the automated browser compatibility testing method as described in any one of claims 1 to 6.

Images