Methods, devices, and electronic equipment for generating test scripts

Abstract

This application discloses a method, apparatus, and electronic device for generating test scripts. The method includes: determining a target branch from multiple code branches, wherein each code branch is the code to be tested within all the code corresponding to the application, and the target branch is any one of the multiple code branches; obtaining multiple platform identifiers corresponding to the target branch, wherein each platform identifier corresponds to a platform on which the target branch is run; generating a common script and multiple function libraries based on the target branch and platform identifiers, wherein the common script is a common test script run on multiple platforms when testing the target branch, each function library corresponds to a platform identifier, and each function library contains multiple functions; the common script controls the platform to execute test operations by calling functions in the function libraries. This application solves the technical problem in the prior art where the number of test scripts corresponding to different platforms is too large, resulting in high test script maintenance costs.

Description

Technical Field

[0001] This application relates to the field of testing technology and other related technical fields. Specifically, it relates to a method, apparatus, and electronic device for generating test scripts. Background Technology

[0002] With the development of information technology, more and more users are choosing customized applications or customized devices that run those applications based on their own needs. To quickly respond to user customization requests, developers typically extract multiple code branches from the entire application's codebase; for example, each code branch might correspond to a specific function within the application. Furthermore, depending on the user's customization requirements, there are also multiple platform options available for the customized devices.

[0003] For each code branch, when compiling and generating the installation image, it is necessary to set markers to distinguish them and package images for different platforms for installation on devices of different platforms. When modifying or adding a code branch, it is usually necessary to use test scripts to test the modified or added code branch to ensure that the functionality works properly.

[0004] However, existing technologies maintain test scripts separately for each branch across multiple platforms. This results in a large number of duplicate test scripts being generated across different platforms, even within a single branch, leading to an excessive number of test scripts and consequently, high maintenance costs. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for generating test scripts, which at least solves the technical problem in the prior art of high test script maintenance costs caused by an excessive number of test scripts across different platforms.

[0006] According to one aspect of the embodiments of this application, a method for generating test scripts is provided, comprising: determining a target branch from multiple code branches, wherein the code branches are the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches; obtaining multiple platform identifiers corresponding to the target branch, wherein the platform identifiers correspond to the platforms on which the target branch is run; generating a common script and multiple function libraries based on the target branch and the platform identifiers, wherein the common script is a common test script run when testing the target branch on multiple platforms, each function library corresponds to a platform identifier, the function library contains multiple functions, and the common script controls the platform to perform test operations by calling the functions in the function library.

[0007] Furthermore, the method for generating test scripts also includes: detecting whether a target platform exists among multiple platforms, wherein the test process of the target platform differs from the test processes of other platforms, and the other platforms are platforms other than the target platform among the multiple platforms; if a target platform exists among multiple platforms, determining the differences between a first test process and a second test process, wherein the first test process is the test process of the target platform, and the second test process is the test process of other platforms; generating at least one difference script based on the difference content; generating a first identifier and a second identifier based on the difference script, wherein the first identifier is used to characterize the generation time of the difference script, and the second identifier is the platform identifier of the target platform.

[0008] Furthermore, the method for generating the test script also includes: after generating the first identifier and the second identifier based on the difference script, executing the common script on each platform and generating a first execution result, wherein the execution result is used to characterize whether the common script was executed successfully on each platform; executing the difference script on the target platform and generating a second execution result, wherein the second execution result is used to characterize whether the difference script was executed successfully on the target platform.

[0009] Furthermore, the method for generating test scripts also includes: after generating a common script and multiple function libraries based on the target branch and platform identifier, obtaining the target platform identifier of the device under test, wherein at least one target branch is running on the device under test, and the target platform identifier represents the platform installed on the device under test; determining the target function library corresponding to the device under test from multiple function libraries based on the target platform identifier, and determining the target script corresponding to the device under test from the common script and the differential script; testing the device under test based on the target script and the target function library, and generating test results.

[0010] Furthermore, the test script generation method also includes: after generating a common script and multiple function libraries based on the target branch and platform identifier, detecting whether there is a new test process in the current platform's test process; when a new test process is detected in the current platform's test process, detecting whether there is a new test process in the test processes of other test platforms, wherein other test platforms are platforms other than the current platform among multiple platforms; when a new test process is detected in the test processes of other test platforms, generating a new common script based on the new test process.

[0011] Furthermore, the test script generation method also includes: after generating a common script and multiple function libraries based on the target branch and platform identifier, detecting whether there is any updated content in the test process of the current platform; when updated content is detected in the test process of the current platform, detecting whether there is any updated content in the test processes of other test platforms; when updated content is detected in the test processes of other test platforms, updating the common script according to the updated content.

[0012] Furthermore, the test script generation method also includes: after generating a common script and multiple function libraries based on the target branch and platform identifier, detecting whether there are updates to the operation instructions in the current platform, wherein the operation instructions are the instructions generated when the current platform executes test operations, and the operation instructions correspond to functions in the function library of the current platform; when there are updates to the operation instructions of the current platform, determining the target function corresponding to the updated operation instructions; and updating the function library corresponding to the current platform based on the target function.

[0013] According to another aspect of the embodiments of this application, a test script generation apparatus is also provided, comprising: a determining module, configured to determine a target branch from multiple code branches, wherein the code branch is the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches; an obtaining module, configured to obtain multiple platform identifiers corresponding to the target branch, wherein the platform identifier corresponds to the platform on which the target branch is run; and a generating module, configured to generate a common script and multiple function libraries based on the target branch and the platform identifiers, wherein the common script is a common test script run when testing the target branch on multiple platforms, each function library corresponds to a platform identifier, the function library contains multiple functions, and the common script controls the platform to perform test operations by calling the functions in the function library.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program is configured to execute the above-described test script generation method at runtime.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, the electronic device including one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are configured to run the test script generation method described above.

[0016] In this application, a common script and multiple function libraries are generated based on the target branch and platform identifier. First, the target branch is determined from multiple code branches. Here, the code branch is the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches. Then, multiple platform identifiers corresponding to the target branch are obtained. Here, the platform identifier corresponds to the platform on which the target branch is run. Finally, a common script and multiple function libraries are generated based on the target branch and platform identifier. Here, the common script is a common test script that is run when testing the target branch on multiple platforms. Each function library corresponds to a platform identifier and contains multiple functions. The common script controls the platform to perform test operations by calling the functions in the function library.

[0017] As described above, the common script generated in this application is a shared test script that runs when testing target branches on multiple platforms. In other words, this application retains only one copy of the duplicate test scripts involved on multiple platforms, namely the common test script. This not only avoids the problem of test script duplication but also reduces the number of test scripts, thereby lowering the maintenance cost of the test scripts. Furthermore, by generating function libraries one-to-one with platform identifiers, this application ensures that the function libraries are maintained independently based on each platform. Therefore, when test scripts are needed to test target branches on a specific platform, it can be ensured that the test scripts accurately call the corresponding function libraries for that platform, thus improving the stability of the test scripts.

[0018] Therefore, the technical solution of this application achieves the goal of reducing the number of test scripts, thereby improving the maintenance efficiency of test scripts and solving the technical problem of high test script maintenance costs caused by the excessive number of test scripts across different platforms in the prior art. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a diagram illustrating a code branch based on existing technology;

[0021] Figure 2 This is a schematic diagram of a method for generating test scripts and function libraries based on existing technology;

[0022] Figure 3 This is a flowchart of an optional test script generation method according to an embodiment of this application;

[0023] Figure 4This is a schematic diagram illustrating a method of sharing a single set of test scripts in each code branch, according to an embodiment of this application.

[0024] Figure 5 This is a schematic diagram of an optional test script generation method according to an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of an optional file storage scheme according to an embodiment of this application;

[0026] Figure 7 This is a schematic diagram illustrating the creation of a test script based on a script management system according to an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of a script list in a script management system according to an embodiment of this application;

[0028] Figure 9 This is a schematic diagram of an optional test script generation apparatus according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] With the development of information technology, more and more users are choosing customized applications and customized devices to run those applications based on their own needs. To quickly respond to users' customized requirements, developers often extract multiple code branches from the entire application's codebase; for example, each code branch corresponds to a specific function within the application.

[0033] in, Figure 1 This is a diagram illustrating a code branch based on existing technology. For example... Figure 1 As shown, on a main branch, you can first extract major version branches according to your needs, for example... Figure 1 The R1 and R2 branches in the code. After obtaining each major version branch, a fix branch can be extracted from the major version branch to fix version issues, for example, Figure 1 The P1 branch in the code. Additionally, temporary development branches for user-added requirements can be extracted from major version branches to develop these temporary requirements, for example, Figure 1 The F1 branch in the code. For some advanced users, there are customized requirements that also need to be developed using a separate branch, for example, Figure 1 The M1 branch is then used. Finally, all major version branches will be merged into the main branch as needed. Among them, the R1, R2, P1, F1, and M1 branches mentioned above are all code branches.

[0034] Furthermore, depending on the user's customization needs, there will be multiple options for the platform on which the customized equipment is installed. For example, taking network communication equipment as an example, in order to meet the needs of different customer groups, network communication equipment can use different architecture chips (such as x86, NP, multi-core, etc.), design different processor routing methods, support different board types, and tailor different specifications, thereby manufacturing equipment with multiple platform types.

[0035] It should be noted that, based on Figure 1 When compiling and generating installation images from various code branches, it is necessary to distinguish them by setting tags and package them into images for different platforms, allowing installation on devices on different platforms. Therefore, it is evident that when there are numerous branches and platforms, the combinations of branches and platforms will increase exponentially. As shown in Table 1 below, with m platforms and n branches, there can be m*n combinations of branches and platforms.

[0036] Table 1

[0037] Branch 1 Image1 Image2 Image3 Image4 Image5 Image… Branch 2 Branch 3 Branch 4 … Branch n Image m*n

[0038] When modifying or adding a code branch, test scripts are typically used to test the modified or added branch to ensure proper functionality. Automated testing, as an effective means of quickly performing regression testing, must cover all combinations of these tests. The number of test scripts and libraries that automated testing relies on is directly related to the number of branches and platforms. Therefore, with frequent branch pulls and merges and an increasing number of platforms, the sheer number and complexity of test scripts and their dependent libraries become considerable.

[0039] Figure 2 This is a schematic diagram illustrating a method for generating test scripts and function libraries based on existing technology. For example... Figure 2 As shown, for each code branch, existing technologies first identify the multiple platforms corresponding to that branch, and then maintain a separate set of test scripts and function libraries for each platform. However, even across different platforms within a single code branch, there are often many identical test procedures. For example, for Platform 1 and Platform 2, both platforms are equipped with board A, so the test procedures for board A are the same for both platforms. However, in this case, because existing technologies maintain test scripts separately for each platform, they generate one test script for board A for Platform 1 and another for board A for Platform 2. Therefore, even within a single branch, existing technologies generate a large number of duplicate test scripts across different platforms. When there are many code branches and platform combinations, the number of duplicate scripts generated by existing technologies increases exponentially, leading to excessively high maintenance costs. Furthermore, when a change occurs on all platforms, the test scripts for each platform need to be modified repeatedly; in other words, existing technologies cannot achieve effective code reuse.

[0040] To address the aforementioned problems, this application provides a method embodiment for generating test scripts. It should be noted that the steps shown in the flowcharts can be executed in a computer system, such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order. A script management system can serve as the execution entity for the test script generation method in this application embodiment.

[0041] Figure 3 This is a flowchart of an optional test script generation method according to an embodiment of this application, such as... Figure 3 As shown, the method includes the following steps:

[0042] Step S301: Determine the target branch from multiple code branches.

[0043] In step S301, the code branch is the code to be tested within all the code corresponding to the application, and the target branch is any one of the multiple code branches. Specifically, taking... Figure 1 Taking the R1, R2, P1, F1, and M1 branches as examples, these code branches need to be tested on different platforms after they are extracted. For instance, since the P1 branch is the code branch that fixes version issues, it can only be determined whether the version issues can be fixed by using the P1 branch after testing the P1 branch.

[0044] Furthermore, the target branch mentioned above can be any one of multiple code branches. Since multiple code branches are relatively independent, it's rare to merge the same function into multiple branches simultaneously. Also, over time, older code branches are usually no longer maintained, so the actual number of maintained code branches is relatively fixed, avoiding the problem of an ever-expanding number of code branches. Therefore, this application chooses to maintain the test scripts and function libraries of each code branch independently to improve the stability of the test scripts under each code branch.

[0045] To better illustrate this, we will use a code branch, namely the target branch, as an example.

[0046] Step S302: Obtain multiple platform identifiers corresponding to the target branch.

[0047] In step S302, the platform identifier corresponds to the platform on which the target branch is running. Specifically, one platform identifier corresponds to one platform. For example, taking network communication products as an example, in order to meet the needs of different customer groups, different architecture chips (such as x86, NP, multi-core, etc.), different processor routing methods, different board types, and different specifications can be designed to produce multi-platform network communication products. Among them, network communication products can be network communication devices such as industrial control computers, desktop computers, laptop computers, firewall devices, and servers.

[0048] Step S303: Generate common scripts and multiple function libraries based on the target branch and platform identifier.

[0049] In step S303, the common script is a common test script that runs when testing target branches on multiple platforms. Each function library corresponds to a platform identifier, and the function library contains multiple functions. The common script controls the platform to perform test operations by calling the functions in the function library.

[0050] Specifically, existing technologies suffer from a large number of test scripts and high maintenance costs due to excessive duplication of test scripts across different platforms. Therefore, to address this issue, it is necessary to avoid generating duplicate test scripts. Among these, Figure 4 This diagram illustrates a scenario where a single set of test scripts is shared across all code branches. Figure 4 As shown, a common script and a function library are generated in each code branch. The common script can be used to represent the same test process to be executed by multiple platforms when testing the target branch. For example, there are three platforms: Platform 1, Platform 2, and Platform 3. Each platform is equipped with board A. Based on this, the test process for board A is the same for all three platforms. Therefore, only one common script needs to be generated for the test process of board A, thereby avoiding the generation of duplicate test scripts, reducing maintenance costs, and achieving code reusability.

[0051] in addition, Figure 4 The system also maintains functions for all platforms through a function library. Specifically, the library uses if / else statements to differentiate between different platforms. For example, in... Figure 4 In function library 1, if platform = 1, then the relevant function corresponding to platform 1 is executed; else if platform = 2, then the relevant function corresponding to platform 2 is executed.

[0052] It is important to note that Figure 4 A single set of common scripts may contain multiple common scripts, such as script 1 and script 2. This is because in practical applications, multiple platforms may have multiple identical test processes. For example, multiple platforms may simultaneously have board A, board B, and board C, each with a corresponding test process, thus generating three common scripts. Similarly, a single function library may also contain multiple function libraries.

[0053] In addition, it should be noted that although Figure 4 While using common scripts avoids the problem of duplicate test scripts, it uses if / else statements in its function library to differentiate between different platforms. This results in a large number of functions in the function library, and the presence of numerous conditional statements makes the code less readable, harder to maintain, and prone to errors, leading to instability when the test script calls related functions.

[0054] To address the aforementioned issues, this application, while generating common scripts, chooses to generate separate function libraries for each platform and maintain them independently. This avoids the instability of test scripts during testing caused by extensive use of if / else statements. Figure 5 As shown, under the target branch, the script management system generates a set of common scripts. These common scripts are shared test scripts that run when testing the target branch on multiple platforms. Specifically, the number of common scripts can be determined based on the number of identical test processes across multiple platforms, such as... Figure 5 The script management system includes two common scripts: Script 1 and Script 2. It also generates separate function libraries for each platform based on the platform identifier. For example, for platform 1, a separate function library 1 is generated, containing multiple functions; for platform 2, a separate function library 2 is generated, also containing multiple functions. In subsequent maintenance, the function libraries corresponding to each platform are maintained independently.

[0055] The above analysis shows that this application maximizes code reuse through common scripts, while avoiding the problem of duplicate test scripts between different platforms under a single code branch, thus reducing the number of test scripts. On the other hand, this application maintains function libraries for different platforms independently within the same branch, achieving platform differentiation and avoiding script stability issues caused by platform functional differences. For example, due to differences in hardware architecture, different platforms will have different command lines and different outputs after commands are issued when writing test scripts. Therefore, maintaining corresponding function libraries for each platform can effectively isolate tests for different platforms, thereby ensuring the stability of test scripts. For example, the output of the `show_module` function differs between devices with slots and devices without slots. This can be achieved by encapsulating different `show_module` functions, returning the same structure, for use by the same script.

[0056] Based on the content of steps S301 to S303 above, it can be seen that in this application, a common script and multiple function libraries are generated according to the target branch and platform identifier. First, the target branch is determined from multiple code branches, where the code branch is the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches. Then, multiple platform identifiers corresponding to the target branch are obtained, where the platform identifier corresponds to the platform on which the target branch is run. Finally, a common script and multiple function libraries are generated according to the target branch and platform identifier. The common script is a common test script that is run when testing the target branch on multiple platforms. Each function library corresponds to a platform identifier and contains multiple functions. The common script controls the platform to perform test operations by calling the functions in the function library.

[0057] As described above, the common script generated in this application is a shared test script that runs when testing target branches on multiple platforms. In other words, this application retains only one copy of the duplicate test scripts involved on multiple platforms, namely the common test script. This not only avoids the problem of test script duplication but also reduces the number of test scripts, thereby lowering the maintenance cost of the test scripts. Furthermore, by generating function libraries one-to-one with platform identifiers, this application ensures that the function libraries are maintained independently based on each platform. Therefore, when test scripts are needed to test target branches on a specific platform, it can be ensured that the test scripts accurately call the corresponding function libraries for that platform, thus improving the stability of the test scripts.

[0058] Therefore, the technical solution of this application achieves the goal of reducing the number of test scripts, thereby improving the maintenance efficiency of test scripts and solving the technical problem of high test script maintenance costs caused by the excessive number of test scripts across different platforms in the prior art.

[0059] In one optional embodiment, the script management system can detect whether a target platform exists among multiple platforms, wherein the testing process of the target platform differs from the testing processes of other platforms, which are platforms other than the target platform among the multiple platforms. If the target platform exists among the multiple platforms, the script management system determines the differences between a first testing process and a second testing process, wherein the first testing process is the testing process for the target platform, and the second testing process is the testing process for other platforms. Finally, the script management system generates at least one difference script based on the difference content; and generates a first identifier and a second identifier based on the difference script, wherein the first identifier represents the generation time of the difference script, and the second identifier is the platform identifier of the target platform.

[0060] Optionally, the target platform mentioned above can be one or multiple. For example, multiple platforms could be Platform 1, Platform 2, and Platform 3. All three platforms carry board A. Therefore, for the testing process of board A, the script management system can generate a common script 1. However, Platform 1 also carries board B, while Platforms 2 and 3 do not. Therefore, for the testing process of board B, a differential script can be generated. Since this differential script is applicable to Platform 1, its second identifier is the platform identifier of Platform 1. Furthermore, based on the generation time of the differential script, a first identifier, such as a timestamp, can be generated, which can be used as the suffix of the differential script.

[0061] Optional, such as Figure 5 As shown, in Figure 5The document shows several difference scripts that support different platforms, namely difference script 1 and difference script 2.

[0062] It is important to note that a single difference script can support multiple platforms simultaneously. For example, if platform 2 subsequently also includes board B, the difference script generated for the test process of board B can also support platform 2. Therefore, both common and difference scripts possess uniqueness within the script management system through the combination of script, branch, and platform dimensions. In other words, because this application sets a platform identifier (i.e., a second identifier) ​​for the difference script, it solves the problem of writing a small number of test cases that cannot be shared across different platforms.

[0063] In one optional embodiment, after generating a first identifier and a second identifier based on the difference script, the script management system executes the common script on each platform and generates a first execution result, wherein the execution result is used to characterize whether the common script is executed successfully on each platform; the script management system also executes the difference script on the target platform and generates a second execution result, wherein the second execution result is used to characterize whether the difference script is executed successfully on the target platform.

[0064] Optionally, after generating the common script and the difference script, the script management system needs to verify them. Only after successful verification will the common script and the difference script be officially applied to the testing process of the target branch and the device under test running the target branch. Since a common script supports all platforms, while a difference script only supports one or a few platforms, the script management system will verify the common script and the difference script separately. The common script needs to be executed on each platform. If all executions are successful, it means the common script is applicable to all platforms; if it fails on any platform, it indicates an anomaly in the common script. The difference script only needs to be executed on the corresponding target platform. If it executes successfully, it means the difference script is in a normal state; if it fails, it indicates an anomaly in the difference script.

[0065] By validating the common scripts and differential scripts, we can ensure that they are compatible with the corresponding platforms, thereby improving test stability.

[0066] In one optional embodiment, after generating a common script and multiple function libraries based on the target branch and platform identifier, the script management system first obtains the target platform identifier of the device under test, wherein at least one target branch is running on the device under test, and the target platform identifier represents the platform on the device under test. Then, the script management system determines the target function library corresponding to the device under test from the multiple function libraries based on the target platform identifier, and determines the target script corresponding to the device under test from the common script and the differential scripts. Finally, the script management system tests the device under test based on the target script and the target function library, generating test results.

[0067] Optionally, the device under test can be a network communication device such as a firewall, industrial control computer, server, or edge computing device, or a computer such as a desktop computer or laptop computer. The device under test can be equipped with any of multiple platforms and can run any branch of the code, such as the target branch.

[0068] Typically, after releasing the target branch, it needs to be compiled and an installation image generated. Then, by setting tags to differentiate them, images for different platforms are packaged for installation and use by products on different platforms. The product can be the device under test mentioned above. The following explanation uses platform 1 running on the device under test as an example.

[0069] The script management system first identifies the platform (Platform 1) of the device under test by obtaining the target platform identifier. Then, it determines the target script corresponding to Platform 1 based on the platform identifiers of the common script and the differential script. For example, since the common script is applicable to all platforms, the target scripts corresponding to Platform 1 must contain the common script. Furthermore, the second identifier of each differential script indicates the platforms it supports. Therefore, by comparing the second identifier with the target platform identifier, it can be determined whether Platform 1 corresponds to a differential script, and if so, whether that differential script is also a target script.

[0070] Furthermore, since each platform's function library is generated and maintained independently, once the platform on the device under test is determined to be Platform 1, the script management system can directly determine the location of the target function library corresponding to Platform 1 and add it to the Python syspath system path. Subsequently, when the target script is invoked, it will automatically search for the target function library in this path to complete the testing of the device under test. During the testing process, the device under test will run the target branch according to the test flow of the target script to check whether the target branch can be executed accurately on the device under test. If the entire test flow of the target script is completed and the test results meet the expected requirements, it indicates that the target branch can be executed accurately on the device under test, and the script management system will mark the target script as having passed the test on Platform 1.

[0071] In one optional embodiment, after generating common scripts and multiple function libraries based on the target branch and platform identifier, the script management system further detects whether there are any new test processes in the current platform's test process. If a new test process is detected in the current platform's test process, the script management system checks whether there are any new test processes in the test processes of other test platforms, where other test platforms are platforms other than the current platform. If a new test process is found in the test processes of other test platforms, the script management system generates a new common script based on the new test process.

[0072] Optionally, when a new feature is added to all platforms, the corresponding test process for that feature also needs to be added to all platforms. In this case, since the new test process is the same for all platforms, the script management system only needs to generate a new common script based on the new test process and mark the new common script as supporting all platforms.

[0073] In one optional embodiment, after generating common scripts and multiple function libraries based on the target branch and platform identifier, the script management system further checks whether there are any updates in the current platform's test flow. If updates are detected in the current platform's test flow, the script management system checks whether there are any updates in the test flows of other test platforms. If updates are found in the test flows of other test platforms, the script management system updates the common scripts accordingly.

[0074] Optionally, when a function is modified across all platforms, if the test process is modified (i.e., there are updated contents in the test process), the script management system only needs to update the common scripts.

[0075] In one optional embodiment, after generating a common script and multiple function libraries based on the target branch and platform identifier, the script management system checks whether the operation instructions in the current platform have been updated. These operation instructions are those generated when the current platform performs test operations, and they correspond to functions in the current platform's function library. If the operation instructions in the current platform are updated, the script management system determines the target function corresponding to the updated operation instructions and updates the corresponding function library for the current platform based on the target function.

[0076] Optionally, the above operation instructions can be functions in the function library that issue command lines to the platform. When the command line on a certain platform is updated, the script management system will first determine the target function corresponding to the updated command line, and then update the function library corresponding to the platform according to the target function.

[0077] In one alternative embodiment, if changes to test scripts and function libraries are required under different code branches, manual operation or automated tools are needed to assist in batch coverage and other operations. Considering that the number of active code branches is limited and relatively fixed, this operation will not consume too much manpower.

[0078] As the above analysis shows, the technical solution of this application, by focusing only on the test process in the test scripts and encapsulating functions in the test function library, and having the test scripts call the test function library, represents the test processes that differ between platforms using differential scripts, while representing the same test processes using common scripts. This maximizes the use of common scripts and avoids the problem of the number of test scripts rapidly increasing as code branches and platform combinations expand. Furthermore, by adding platform tagging functionality to the differential scripts, the problem of writing a small number of test cases that cannot be shared across platforms is solved. Meanwhile, considering the significant differences between different code branches and the relatively fixed and limited number of active code branches, the test scripts and function libraries under each code branch are maintained independently. This avoids the problem of mutual interference between changes under different code branches and enhances the stability of the test scripts. Moreover, considering the differences in functionality between different platforms under a single code branch, maintaining the function libraries for each platform independently within a single code branch can also avoid the problem of poor test script stability caused by differences in functionality between different platforms.

[0079] In an optional embodiment, to better illustrate the technical solution of this application, the following describes an optional data table construction process for the script management system:

[0080] First, construct the script table. Specifically, within each branch, scripts for the same test case have the same name: e.g., script1. When storing, they are distinguished by adding a file extension. In a script table, the script name, file extension, and branch form a unique key. For example, Table 2 below shows one such script table.

[0081] Table 2

[0082]

[0083] Then, a script support platform table is constructed. Specifically, for common scripts, a script will support all platforms. For differential scripts, only one or a few platforms will be supported. The script support platform table can be configured to match the mapping between each test script and the platform, where "Tested Successfully" indicates whether the test script has been tested successfully on the supported platforms. For example, Table 3 below shows one such script support platform table.

[0084] Table 3

[0085]

[0086] Finally, a function library table is constructed, maintaining an independent function library for each code branch and platform. Specifically, Table 4 below shows one such function library table.

[0087] Table 4

[0088]

[0089] In one alternative embodiment, Figure 6 An optional file storage scheme according to an embodiment of this application is illustrated. For example... Figure 6 As shown, under code branch 1, a separate set of common scripts is stored. This set of common scripts can include multiple common scripts such as common script 1, common script 2, and common script 3. Simultaneously, under code branch 1, a separate set of difference scripts is also stored. This set of difference scripts can include multiple difference scripts such as difference script 1 and difference script 2. Finally, under each code branch, a corresponding function library is maintained separately for each platform. For example, the function library for platform 1 corresponds to platform 1, the function library for platform 2 corresponds to platform 2, and the function library for platform 3 corresponds to platform 3.

[0090] In an optional embodiment, in order to further illustrate the technical solution of this application, the following operation is described based on a script management system.

[0091] first, Figure 7 The diagram illustrates the creation of test scripts based on a script management system, such as... Figure 7As shown, for newly created scripts, you need to specify the code branch to which it belongs and indicate which platforms it supports (multiple selections are supported). When saving a test script, you need to ensure that the test script name + code branch + supported platform is a unique value.

[0092] Figure 8 This document illustrates a script list containing multiple list items used to filter code branches, filter supported platforms, display platforms supported by the test script, and display untested platforms. Furthermore, a single test script may support multiple platforms simultaneously. Figure 8 As shown, for script 1, the corresponding code branch is branch 1, and the supported platforms can be platform 1 and platform 2.

[0093] In addition, the script management system also provides code branch cloning functionality. Specifically, the script management system provides a branch cloning entry point, allowing operators to select which existing code branch the new code branch will be copied from, thus performing a full-platform cloning of the original code branch. The script management system also provides cloning logs for operators to view at any time.

[0094] As shown above, test scripts within a single code branch can be categorized into common scripts and differential scripts. Common scripts maximize code reuse. Furthermore, by independently maintaining function libraries for different platforms within a single branch, platform differentiation is achieved, avoiding script instability issues caused by platform feature differences. Finally, by independently maintaining test scripts across different code branches, both test isolation and stability are ensured, and the limited number of active code branches due to the continuous elimination of older branches prevents script overload.

[0095] Example 2

[0096] According to an embodiment of this application, an embodiment of a test script generation apparatus is also provided, wherein, Figure 9 This is a schematic diagram of an optional test script generation apparatus according to an embodiment of this application, such as... Figure 9 As shown, the device includes: a determining module 901, an acquiring module 902, and a generating module 903.

[0097] The determination module 901 is used to determine the target branch from multiple code branches. The code branches are the code to be tested within the entire codebase of the application, and the target branch is any one of the multiple code branches. Specifically, taking... Figure 1Taking the R1, R2, P1, F1, and M1 branches as examples, these code branches need to be tested on different platforms after they are extracted. For instance, since the P1 branch is the code branch that fixes version issues, it can only be determined whether the version issues can be fixed by using the P1 branch after testing the P1 branch.

[0098] Furthermore, the target branch mentioned above can be any one of multiple code branches. Since multiple code branches are relatively independent, it's rare to merge the same function into multiple branches simultaneously. Also, over time, older code branches are usually no longer maintained, so the actual number of maintained code branches is relatively fixed, avoiding the problem of an ever-expanding number of code branches. Therefore, this application chooses to maintain the test scripts and function libraries of each code branch independently to improve the stability of the test scripts under each code branch.

[0099] The acquisition module 902 is used to acquire multiple platform identifiers corresponding to the target branch, where each platform identifier corresponds to the platform on which the target branch is running. Specifically, one platform identifier corresponds to one platform. For example, taking network communication products as an example, in order to meet the needs of different customer groups, different architecture chips (such as x86, NP, multi-core, etc.), different processor routing methods, different board types, and different specifications can be designed to produce multi-platform network communication products. These network communication products can be industrial control computers, desktop computers, laptop computers, firewall devices, and servers, among other network communication equipment.

[0100] The generation module 903 is used to generate common scripts and multiple function libraries based on the target branch and platform identifier. The common scripts are common test scripts that are run when testing the target branch on multiple platforms. Each function library corresponds to a platform identifier and contains multiple functions. The common scripts control the platform to perform test operations by calling the functions in the function library.

[0101] Specifically, existing technologies suffer from a large number of test scripts and high maintenance costs due to excessive duplication of test scripts across different platforms. Therefore, to address this issue, it is necessary to avoid generating duplicate test scripts. Among these, Figure 4 This diagram illustrates a scenario where a single set of test scripts is shared across all code branches. Figure 4As shown, a common script and a function library are generated in each code branch. The common script can be used to represent the same test process to be executed by multiple platforms when testing the target branch. For example, there are three platforms: Platform 1, Platform 2, and Platform 3. Each platform is equipped with board A. Based on this, the test process for board A is the same for all three platforms. Therefore, only one common script needs to be generated for the test process of board A, thereby avoiding the generation of duplicate test scripts, reducing maintenance costs, and achieving code reusability.

[0102] in addition, Figure 4 The system also maintains functions for all platforms through a function library. Specifically, the library uses if / else statements to differentiate between different platforms. For example, in... Figure 4 In function library 1, if platform = 1, then the relevant function corresponding to platform 1 is executed; else if platform = 2, then the relevant function corresponding to platform 2 is executed.

[0103] It is important to note that Figure 4 A single set of common scripts may contain multiple common scripts, such as script 1 and script 2. This is because in practical applications, multiple platforms may have multiple identical test processes. For example, multiple platforms may simultaneously have board A, board B, and board C, each with a corresponding test process, thus generating three common scripts. Similarly, a single function library may also contain multiple function libraries.

[0104] In addition, it should be noted that although Figure 4 While using common scripts avoids the problem of duplicate test scripts, it uses if / else statements in its function library to differentiate between different platforms. This results in a large number of functions in the function library, and the presence of numerous conditional statements makes the code less readable, harder to maintain, and prone to errors, leading to instability when the test script calls related functions.

[0105] To address the aforementioned issues, this application, while generating common scripts, chooses to generate separate function libraries for each platform and maintain them independently. This avoids the instability of test scripts during testing caused by extensive use of if / else statements. Figure 5 As shown, under the target branch, the test script generation device generates a set of common scripts. These common scripts are shared test scripts that run when testing the target branch on multiple platforms. Specifically, the number of common scripts can be determined based on the number of identical test procedures across multiple platforms, such as... Figure 5The test script generation device also generates a separate function library for each platform based on the platform identifier. For example, for platform 1, a separate function library 1 is generated, which contains multiple functions; for platform 2, a separate function library 2 is generated, which also contains multiple functions. In subsequent maintenance, the function library corresponding to each platform is also maintained independently.

[0106] The above analysis shows that this application maximizes code reuse through common scripts, while avoiding the problem of duplicate test scripts between different platforms under a single code branch, thus reducing the number of test scripts. On the other hand, this application maintains function libraries for different platforms independently within the same branch, achieving platform differentiation and avoiding script stability issues caused by platform functional differences. For example, due to differences in hardware architecture, different platforms will have different command lines and different outputs after commands are issued when writing test scripts. Therefore, maintaining corresponding function libraries for each platform can effectively isolate tests for different platforms, thereby ensuring the stability of test scripts. For example, the output of the `show_module` function differs between devices with slots and devices without slots. This can be achieved by encapsulating different `show_module` functions, returning the same structure, for use by the same script.

[0107] Based on the above analysis, this application adopts a method of generating common scripts and multiple function libraries according to the target branch and platform identifier. First, the target branch is determined from multiple code branches, where the code branch is the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches. Then, multiple platform identifiers corresponding to the target branch are obtained, where the platform identifier corresponds to the platform on which the target branch is run. Finally, common scripts and multiple function libraries are generated according to the target branch and platform identifier. The common script is a common test script that is run when testing the target branch on multiple platforms. Each function library corresponds to a platform identifier and contains multiple functions. The common script controls the platform to perform test operations by calling the functions in the function library.

[0108] As described above, the common script generated in this application is a shared test script that runs when testing target branches on multiple platforms. In other words, this application retains only one copy of the duplicate test scripts involved on multiple platforms, namely the common test script. This not only avoids the problem of test script duplication but also reduces the number of test scripts, thereby lowering the maintenance cost of the test scripts. Furthermore, by generating function libraries one-to-one with platform identifiers, this application ensures that the function libraries are maintained independently based on each platform. Therefore, when test scripts are needed to test target branches on a specific platform, it can be ensured that the test scripts accurately call the corresponding function libraries for that platform, thus improving the stability of the test scripts.

[0109] Therefore, the technical solution of this application achieves the goal of reducing the number of test scripts, thereby improving the maintenance efficiency of test scripts and solving the technical problem of high test script maintenance costs caused by the excessive number of test scripts across different platforms in the prior art.

[0110] Optionally, the test script generation device further includes: a detection module, a first determination module, a first generation module, and a second generation module. The detection module is used to detect whether a target platform exists among multiple platforms, wherein the test process of the target platform differs from the test processes of other platforms, which are platforms other than the target platform among the multiple platforms. The first determination module is used to determine the differences between the first test process and the second test process when the target platform exists among the multiple platforms, wherein the first test process is the test process of the target platform, and the second test process is the test process of other platforms. The first generation module is used to generate at least one difference script based on the difference content. The second generation module is used to generate a first identifier and a second identifier based on the difference script, wherein the first identifier represents the generation time of the difference script, and the second identifier is the platform identifier of the target platform.

[0111] Optionally, the target platform mentioned above can be one or more. For example, multiple platforms could be platform 1, platform 2, and platform 3. All three platforms carry board A. Therefore, for the testing process of board A, the test script generation device can generate a common script 1. However, platform 1 also carries board B, while platforms 2 and 3 do not. Therefore, for the testing process of board B, a differential script can be generated. Since this differential script is applicable to platform 1, its second identifier is the platform identifier of platform 1. Furthermore, based on the generation time of the differential script, a first identifier, such as a timestamp, can also be generated, where the timestamp can be used as a suffix for the differential script.

[0112] Optional, such as Figure 5 As shown, in Figure 5 The document shows several difference scripts that support different platforms, namely difference script 1 and difference script 2.

[0113] It should be noted that a single difference script can support multiple platforms simultaneously. For example, if platform 2 subsequently also includes board B, the difference script generated for the test process of board B can also support platform 2. Therefore, both common and difference scripts, through the combination of script, branch, and platform dimensions, possess uniqueness in the test script generation device. In other words, because this application sets a platform marker (i.e., a second identifier) ​​for the difference script, it solves the problem of writing a small number of test cases that cannot be shared across platforms. Optionally, the test script generation device further includes: a first execution module and a second execution module. The first execution module is used to execute the common script on each platform and generate a first execution result, wherein the execution result indicates whether the common script executes successfully on each platform; the second execution module is used to execute the difference script on the target platform and generate a second execution result, wherein the second execution result indicates whether the difference script executes successfully on the target platform. Optionally, after generating the common script and the difference script, they need to be verified. Only after successful verification will the common script and the difference script be formally applied to the target branch and the test device running the target branch. Since a common script supports all platforms, while a difference script only supports one or a few platforms, the common script needs to be executed on each platform. If all executions are successful, the common script is applicable to all platforms; if it fails on any platform, the common script has an error. The difference script only needs to be executed on the corresponding target platform. If it executes successfully, the difference script is functioning correctly; if it fails, the difference script has an error.

[0114] By validating the common scripts and differential scripts, we can ensure that they are compatible with the corresponding platforms, thereby improving test stability.

[0115] Optionally, the test script generation device further includes: a first acquisition module, a second determination module, and a test module. The first acquisition module is used to acquire the target platform identifier of the device under test, wherein the device under test runs at least one target branch, and the target platform identifier represents the platform on the device under test. The second determination module is used to determine the target function library corresponding to the device under test from multiple function libraries based on the target platform identifier, and to determine the target script corresponding to the device under test from common scripts and differential scripts. The test module is used to test the device under test based on the target script and the target function library, and generate test results.

[0116] Optionally, the device under test can be a network communication device such as a firewall, industrial control computer, server, or edge computing device, or a computer such as a desktop computer or laptop computer. The device under test can be equipped with any of multiple platforms and can run any branch of the code, such as the target branch.

[0117] Typically, after releasing the target branch, it needs to be compiled and an installation image generated. Then, by setting tags to differentiate them, images for different platforms are packaged for installation and use by products on different platforms. The product can be the device under test mentioned above. The following explanation uses platform 1 running on the device under test as an example.

[0118] First, by obtaining the target platform identifier, the platform on which the device under test is running is determined to be Platform 1. Then, based on the platform identifiers of the common script and the differential script, the target script corresponding to Platform 1 is determined. For example, since the common script is applicable to all platforms, the target script corresponding to Platform 1 must contain the common script. In addition, the second identifier of each differential script indicates the platforms supported by that differential script. Therefore, by comparing whether the second identifier is the same as the target platform identifier, it can be determined whether Platform 1 corresponds to a differential script, and if Platform 1 corresponds to a differential script, it can be determined that the differential script is also a target script.

[0119] Furthermore, since the function libraries for each platform are generated and maintained separately, once the platform on which the device under test is installed is determined to be Platform 1, the location of the target function library corresponding to Platform 1 can be directly determined and added to the Python syspath system path. Subsequently, when the target script is invoked, it will automatically search for the target function library in this path to complete the testing of the device under test. During the testing process, the device under test will run the target branch according to the test flow of the target script to check whether the target branch can be executed accurately on the device under test. If the entire test flow of the target script is completed and the test results meet the expected requirements, it indicates that the target branch can be executed accurately on the device under test. At the same time, the test script generation device will also mark that the target script has passed the test on Platform 1.

[0120] Optionally, the test script generation device further includes: a first detection module, a second detection module, and a third generation module. The first detection module is used to detect whether a new test process exists in the current platform's test process; the second detection module is used to detect whether a new test process exists in the test processes of other test platforms when a new test process is detected in the current platform's test process, wherein other test platforms are platforms other than the current platform among multiple platforms; the third detection module is used to generate a new common script based on the new test process when a new test process exists in the test processes of other test platforms.

[0121] Optionally, when a new feature is added to all platforms, the corresponding test process for that feature also needs to be added to all platforms. In this case, since the new test process is the same for all platforms, the test script generation device only needs to generate a new common script based on the new test process and mark the new common script as supporting all platforms.

[0122] Optionally, the test script generation device further includes: a third detection module, a fourth detection module, and an update module. The third detection module is used to detect whether there is updated content in the current platform's test process; the fourth detection module is used to detect whether there is updated content in the test processes of other test platforms when updated content is detected in the current platform's test process; and the update module is used to update the common script according to the updated content when updated content exists in the test processes of other test platforms.

[0123] Optionally, when a function is modified across all platforms, if the test process is modified (i.e., there are updated contents in the test process), the test script generation device only needs to update the common script.

[0124] Optionally, the test script generation device further includes: a fifth detection module, a third determination module, and a first update module. The fifth detection module is used to detect whether there are updates to the operation instructions in the current platform, wherein the operation instructions are instructions generated when the current platform executes test operations, and the operation instructions correspond to functions in the function library of the current platform; the third determination module is used to determine the target function corresponding to the updated operation instructions when there are updates to the operation instructions of the current platform; the first update module is used to update the function library corresponding to the current platform based on the target function.

[0125] Optionally, the above operation instructions can be functions in the function library that issue command lines to the platform. When the command line on a certain platform is updated, the test script generation device will first determine the target function corresponding to the updated command line, and then update the function library corresponding to the platform according to the target function.

[0126] In one alternative embodiment, if changes to test scripts and function libraries are required under different code branches, manual operation or automated tools are needed to assist in batch coverage and other operations. Considering that the number of active code branches is limited and relatively fixed, this operation will not consume too much manpower.

[0127] As the above analysis shows, the technical solution of this application, by focusing only on the test process in the test scripts and encapsulating functions in the test function library, and having the test scripts call the test function library, represents the test processes that differ between platforms using differential scripts, while representing the same test processes using common scripts. This maximizes the use of common scripts and avoids the problem of the number of test scripts rapidly increasing as code branches and platform combinations expand. Furthermore, by adding platform tagging functionality to the differential scripts, the problem of writing a small number of test cases that cannot be shared across platforms is solved. Meanwhile, considering the significant differences between different code branches and the relatively fixed and limited number of active code branches, the test scripts and function libraries under each code branch are maintained independently. This avoids the problem of mutual interference between changes under different code branches and enhances the stability of the test scripts. Moreover, considering the differences in functionality between different platforms under a single code branch, maintaining the function libraries for each platform independently within a single code branch can also avoid the problem of poor test script stability caused by differences in functionality between different platforms.

[0128] Example 3

[0129] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program is configured to execute the test script generation method in Embodiment 1 above when running.

[0130] Example 4

[0131] According to another aspect of the embodiments of this application, an electronic device is also provided, the electronic device including one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are configured to run the programs, wherein the programs are configured to execute the test script generation method in Embodiment 1 above during runtime.

[0132] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0133] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0137] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0138] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of generating a test script, characterized by, include: The target branch is determined from multiple code branches, wherein the code branches are the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches; Obtain multiple platform identifiers corresponding to the target branch, wherein the platform identifiers correspond to the platforms on which the target branch is run; A common script and multiple function libraries are generated based on the target branch and the platform identifier. The common script is a public test script that runs when multiple platforms test the target branch. Each function library corresponds to a platform identifier and contains multiple functions. The common script controls the platform to perform test operations by calling the functions in the function library. The common test script and the functions in the function library are generated based on a script management system that supports code branch cloning. The method further includes: detecting whether a target platform exists among the plurality of platforms, wherein the test process of the target platform differs from the test processes of other platforms, and the other platforms are platforms other than the target platform among the plurality of platforms; if the target platform exists among the plurality of platforms, determining the difference between a first test process and a second test process, wherein the first test process is the test process of the target platform, and the second test process is the test process of the other platforms; generating at least one difference script based on the difference content; generating a first identifier and a second identifier based on the difference script, wherein the first identifier is used to characterize the generation time of the difference script, and the second identifier is the platform identifier of the target platform; After generating a common script and multiple function libraries based on the target branch and the platform identifier, the method further includes: obtaining the target platform identifier of the device under test, wherein at least one target branch is running on the device under test, and the target platform identifier represents the platform mounted on the device under test; determining the target function library corresponding to the device under test from the multiple function libraries based on the target platform identifier, and determining the target script corresponding to the device under test from the common script and the differential script; testing the device under test based on the target script and the target function library, and generating test results; After generating a common script and multiple function libraries based on the target branch and the platform identifier, the method further includes: detecting whether a new test process exists in the test process of the current platform; when the new test process is detected in the test process of the current platform, detecting whether the new test process exists in the test processes of other test platforms, wherein the other test platforms are platforms other than the current platform among the multiple platforms; when the new test process exists in the test processes of other test platforms, generating a new common script based on the new test process.

2. The method of claim 1, wherein, After generating the first identifier and the second identifier based on the difference script, the method further includes: The common script is executed on each platform, and a first execution result is generated, wherein the first execution result is used to characterize whether the common script is executed successfully on each platform; The difference script is executed on the target platform, and a second execution result is generated, wherein the second execution result is used to characterize whether the difference script was successfully executed on the target platform.

3. The method according to any one of claims 1-2, characterized in that, After generating a common script and multiple function libraries based on the target branch and the platform identifier, the method further includes: Check if there are any updates in the current platform's testing process; When the updated content is detected in the test process of the current platform, the system checks whether the updated content is present in the test processes of other test platforms. When the updated content exists in the testing process of the other testing platforms, the common script is updated according to the updated content.

4. The method according to any one of claims 1-2, characterized in that, After generating a common script and multiple function libraries based on the target branch and the platform identifier, the method further includes: Detect whether there are updates to the operation instructions in the current platform, wherein the operation instructions are instructions generated by the current platform when performing test operations, and the operation instructions correspond to functions in the function library of the current platform; When the operation instructions of the current platform are updated, determine the objective function corresponding to the updated operation instructions; The function library corresponding to the current platform is updated based on the objective function.

5. An apparatus for generating a test script, characterized by, include: A determination module is used to determine a target branch from multiple code branches, wherein the code branches are the code to be tested in all the code corresponding to the application, and the target branch is any one of the multiple code branches; The acquisition module is used to acquire multiple platform identifiers corresponding to the target branch, wherein the platform identifiers correspond to the platform on which the target branch is run; A generation module is used to generate a common script and multiple function libraries based on the target branch and the platform identifier. The common script is a common test script that runs when multiple platforms test the target branch. Each function library corresponds to a platform identifier. Each function library contains multiple functions. The common script controls the platform to perform test operations by calling the functions in the function library. The common test script and the functions in the function library are generated based on a script management system. The script management system supports code branch cloning. The test script generation device further includes: a detection module for detecting whether a target platform exists among the plurality of platforms, wherein the test process of the target platform differs from the test processes of other platforms, and the other platforms are platforms other than the target platform among the plurality of platforms; a first determination module for determining the difference between a first test process and a second test process when the target platform exists among the plurality of platforms, wherein the first test process is the test process of the target platform and the second test process is the test process of the other platforms; a first generation module for generating at least one difference script based on the difference content; and a second generation module for generating a first identifier and a second identifier based on the difference script, wherein the first identifier is used to characterize the generation time of the difference script and the second identifier is the platform identifier of the target platform. The test script generation device further includes: a first acquisition module, used to acquire the target platform identifier of the device under test, wherein at least one target branch is running on the device under test, and the target platform identifier represents the platform mounted on the device under test; a second determination module, used to determine the target function library corresponding to the device under test from the plurality of function libraries according to the target platform identifier, and to determine the target script corresponding to the device under test from the common script and the differential script; and a testing module, used to test the device under test based on the target script and the target function library, and generate test results. The test script generation device further includes: a first detection module, used to detect whether there is a new test process in the test process of the current platform; a second detection module, used to detect whether there is a new test process in the test processes of other test platforms when the new test process is detected in the test process of the current platform, wherein the other test platforms are platforms other than the current platform among the plurality of platforms; and a third generation module, used to generate a new common script based on the new test process when the new test process exists in the test processes of other test platforms.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the method for generating the test script as described in any one of claims 1-4 when it is run.

7. An electronic device, comprising: The electronic device includes one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to perform a program execution, wherein the program is configured to execute the test script generation method of any one of claims 1-4 at runtime.

Images