A method, device, equipment and medium for building a use case library service framework

Abstract

The application discloses a use case library service framework building method and device, equipment and medium, and relates to the technical field of computer, which comprises the following steps: constructing a general use case template; the general use case template comprises a function for preparing a use case, a function for determining whether the use case is executable, a function for executing the use case, and a function for cleaning up the use case; an interface list is defined in advance, and each interface in the interface list is encapsulated to obtain an encapsulated interface; the interface comprises a first interface for determining whether the use case is executable, an interface for executing the use case, an interface for obtaining a single use case result, and an interface for obtaining an all-use case execution condition summary; a use case library service framework is built based on the general use case template and all encapsulated interfaces, and the use case library service framework is packaged and integrated into a target product to deploy the use case library service framework in the target product. The application provides a use case library service framework which can integrate an automatic tool into any product, and the use case library service framework is encapsulated as a service to be dispatched by the product, thereby reducing the test cost.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for building a use case library service framework. Background Technology

[0002] The automated process of software testing involves running a system or application under preset conditions and evaluating the results. These preset conditions should include both normal and abnormal conditions. Automated testing is a process that transforms human-driven testing behaviors into machine execution. Commonly used Python automated testing frameworks include Robot Framework (a keyword-driven automated testing framework), Pytest (a Python testing framework), UnitTest / PyUnit (Python's built-in unit testing framework), Behave (a behavior-driven Python testing framework), and Lettuce (a distributed cache-driven framework). For users, how their tools can be integrated into the product, and how to easily call these tools and generate test reports in a production environment, are issues that require further research.

[0003] In summary, how to provide a method to integrate existing automation tools and encapsulate them as services to be scheduled by products is a problem that needs to be solved. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for building a use case library service framework, which can provide a method to integrate existing automation tools and encapsulate them as services to be scheduled by products. The specific solution is as follows:

[0005] Firstly, this application discloses a method for building a use case library service framework, including:

[0006] Construct a general use case template; the general use case template includes a first function for preparing use cases, a second function for determining whether use cases are executable, a third function for executing use cases, and a fourth function for cleaning up use cases;

[0007] A predefined list of interfaces is determined, and each interface in the list is encapsulated to obtain the corresponding encapsulated interface. The interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases.

[0008] A use case library service framework is built based on the general use case template and all the encapsulated interfaces, and the use case library service framework is packaged and integrated into the target product to deploy the use case library service framework in the target product.

[0009] Optionally, the interface logic corresponding to the first interface is as follows:

[0010] Based on the current parameters, obtain the target test case corresponding to the global variable, and call and execute the first function corresponding to the target test case;

[0011] If the first function fails to execute, a first result indicating that the target test case is not executable is returned; if the first function succeeds, the second function is called.

[0012] If the second function executes successfully, it returns a second result indicating that the target test case is executable; if the second function fails, it returns a first result indicating that the target test case is not executable.

[0013] Optionally, the interface logic corresponding to the second interface is as follows:

[0014] Obtain the target test case corresponding to the global variable based on the current parameters, and add the target test case to the producer queue;

[0015] If the target test case is successfully added to the producer queue, the running parameters of the target test case are stored in the running variable of the global variable, and the consumer is triggered to run the target test case; otherwise, a message indicating that the running status of the target test case is empty is returned.

[0016] Set the preparation status of the target test case to running, and execute the first function corresponding to the target test case;

[0017] If the first function fails to execute, the preparation status of the target test case is set to failure, and the running status of the target test case is set to skipped.

[0018] If the first function executes successfully, the preparation status of the target test case is set to successful, and the third function corresponding to the target test case is executed.

[0019] If the third function fails to execute, the running status of the target test case is set to failure; if the test case execution function executes successfully, the running status of the target test case is set to success, and the fourth function corresponding to the target test case is executed.

[0020] If the fourth function fails to execute, the cleanup status of the target test case is set to failure; if the fourth function executes successfully, the cleanup status of the target test case is set to success.

[0021] Optionally, after storing the running parameters of the target test case into the running variables of the global variable, the method further includes:

[0022] Determine whether the running parameters have been successfully stored in the running variables;

[0023] If storage is successful, the corresponding runtime identifier is returned; if storage fails, a message indicating that the runtime status of the target test case is empty is returned.

[0024] Optionally, the interface logic corresponding to the third interface is as follows:

[0025] Retrieve the target test case corresponding to the global variable based on the current parameters.

[0026] Optionally, the interface logic corresponding to the fourth interface is as follows:

[0027] Obtain all test case information of global variables, and summarize and statistically analyze the test case information according to preset summarization rules to obtain summary results; wherein, the preset summarization rules include counting the number of first test cases with non-empty test case running status and counting the number of second test cases with successful test case running status, and determining the success rate based on the number of first test cases and the data of second test cases;

[0028] Accordingly, after deploying the use case library service framework in the target product, the method further includes:

[0029] Execute all test cases and retrieve the summary results from the fourth interface;

[0030] Based on the summarized results, the running status of all test cases is determined. If each running status is skipped, successful, or failed, the test case is determined to have been executed successfully; otherwise, the test case is determined to have failed.

[0031] Optionally, the method for building the use case library service framework further includes:

[0032] Based on the resource addition command, a preset resource addition function is introduced into the general use case template to establish a binding relationship between the newly added resource and the run identifier.

[0033] Based on the resource removal command, a preset resource removal function is introduced into the general use case template to remove the binding relationship between the resource to be removed and the run identifier.

[0034] Based on the resource acquisition command, a preset resource acquisition function is introduced into the general use case template to obtain the resource information corresponding to the run identifier based on the preset resource acquisition function.

[0035] Secondly, this application discloses a device for building a use case library service framework, comprising:

[0036] The test case template building module is used to build a general test case template; the general test case template includes a first function for preparing test cases, a second function for determining whether a test case is executable, a third function for executing test cases, and a fourth function for cleaning up test cases;

[0037] An interface encapsulation module is used to determine a predefined list of interfaces and encapsulate each interface in the list to obtain a corresponding encapsulated interface. The interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases.

[0038] The framework deployment module is used to build a use case library service framework based on the general use case template and all the encapsulated interfaces, and to package and integrate the use case library service framework into the target product to deploy the use case library service framework in the target product.

[0039] Thirdly, this application discloses an electronic device, including:

[0040] Memory, used to store computer programs;

[0041] A processor is used to execute the computer program to implement the steps of the aforementioned disclosed method for building a use case library service framework.

[0042] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed method for building a use case library service framework.

[0043] As can be seen, this application constructs a general use case template; the general use case template includes a pre-set first function for preparing use cases, a second function for determining whether a use case is executable, a third function for executing use cases, and a fourth function for cleaning up use cases; it determines a pre-defined interface list and encapsulates each interface in the interface list to obtain the corresponding encapsulated interface; the interface in the interface list includes a first interface for determining whether a use case is executable, a second interface for executing use cases, a third interface for obtaining the result of a single use case, and a fourth interface for obtaining a summary of the execution status of all use cases; based on the general use case template and all the encapsulated interfaces, a use case library service framework is built, and the use case library service framework is packaged and integrated into the target product to deploy the use case library service framework in the target product. Therefore, the construction process of the test case library service framework in this application includes two parts: first, building a general test case template, which needs to include a first function for preparing test cases, a second function for determining whether a test case is executable, a third function for executing test cases, and a fourth function for cleaning up test cases; second, encapsulating interfaces, specifically by first determining a predefined list of interfaces, including a first interface for determining whether a test case is executable, a second interface for executing test cases, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases. Each interface in the interface list is then encapsulated to obtain the corresponding encapsulated interface. Finally, based on the general test case template and all encapsulated interfaces, the test case library service framework is built and packaged and integrated into the target product for deployment. The above solution provides a test case library service framework that enables automation tools to be integrated into any product. The framework has strong independence and portability, is not strongly coupled with the product, is applicable to any product, and is encapsulated as a service for product scheduling, reducing the self-testing costs of testing and development. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0045] Figure 1 This application discloses a flowchart of a method for building a use case library service framework.

[0046] Figure 2 This application discloses a flowchart illustrating a specific method for building a use case library service framework.

[0047] Figure 3This is an interface logic flowchart of a first interface disclosed in this application;

[0048] Figure 4 This is an interface logic flowchart of a second interface disclosed in this application;

[0049] Figure 5 This is an interface logic flowchart of a third interface disclosed in this application;

[0050] Figure 6 This is an interface logic flowchart of a fourth interface disclosed in this application;

[0051] Figure 7 This is a schematic diagram of the structure of a device for building a use case library service framework disclosed in this application;

[0052] Figure 8 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this 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 invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0054] The automated process of software testing involves running a system or application under preset conditions and evaluating the results. These preset conditions should include both normal and abnormal conditions. Automated testing is a process that transforms human-driven testing behaviors into machine execution. However, for users, how their tools can be integrated into the product, and how these tools can be easily invoked and test reports generated in a production environment, are issues that require further research. To address this, this application discloses a method, apparatus, device, and medium for building a use case library service framework, which provides a method to integrate existing automated tools and encapsulate them as services for product scheduling.

[0055] See Figure 1 As shown in the figure, this application discloses a method for building a use case library service framework, the method including:

[0056] Step S11: Construct a general use case template; the general use case template includes a first function for preparing use cases, a second function for determining whether a use case is executable, a third function for executing use cases, and a fourth function for cleaning up use cases.

[0057] In this embodiment, a general test case template needs to be constructed. This general test case template needs to include a first function for preparing test cases (i.e., the prepare function), a second function for determining whether a test case is executable (i.e., the is_executable function), a third function for executing test cases (i.e., the execute function), and a fourth function for cleaning up test cases (i.e., the destroy function).

[0058] A specific example of a general use case template is as follows:

[0059] Class Test:

[0060] def prepare(self): / / Test case preparation section

[0061] def is_executable(self): / / Whether the test case is executable

[0062] def execute(self): / / Execute test cases

[0063] def destroy(self): / / Test case cleanup

[0064] It should be noted that each of the above functions can embed the user's previous tool code into the template according to its function. Furthermore, if resource sharing between multiple use cases is required, resources can be added, removed, or retrieved at any point in the above four functions.

[0065] Specifically, this includes: introducing a preset resource addition function into the general use case template based on the resource addition command, to establish a binding relationship between the newly added resource and the run identifier based on the preset resource addition function; introducing a preset resource removal function into the general use case template based on the resource removal command, to release the binding relationship between the resource to be removed and the run identifier based on the preset resource removal function; and introducing a preset resource acquisition function into the general use case template based on the resource acquisition command, to acquire the resource information corresponding to the run identifier based on the preset resource acquisition function. That is, for the resource addition method, a custom preset resource addition function `addkey` can be introduced to save the resource information created for this use case, binding the newly added resource to the `runId` (i.e., the run identifier). For example, when creating a virtual machine, the virtual machine ID (identifier) ​​can be saved to the `runId`; for the resource removal method, a custom preset resource removal function `removekey` can be introduced to release the binding between the resource to be removed and the `runId`; and for the resource acquisition method, a custom preset resource acquisition function `getkey` can be introduced to acquire the resource information within the same `runId`.

[0066] Understandably, the use case layer can customize resource sharing as needed. Resources that need to be used externally can be stored in global variable use cases so that other use cases can call resources, thereby reducing the overall execution time of use cases.

[0067] Step S12: Determine a predefined list of interfaces and encapsulate each interface in the list to obtain the corresponding encapsulated interface; the interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases.

[0068] In this embodiment, a predefined list of interfaces is determined. The interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases. Each interface in the list is then encapsulated to obtain the corresponding encapsulated interface. This embodiment of the application provides a general test case template and interfaces to achieve the goal of making test cases executable and their results queryable.

[0069] Step S13: Build a use case library service framework based on the general use case template and all the encapsulated interfaces, and package and integrate the use case library service framework into the target product to deploy the use case library service framework in the target product.

[0070] In this embodiment, a use case library service framework is built based on a general use case template and all encapsulated interfaces. This framework is then packaged and integrated into the target product for deployment. The above solution provides a use case library service framework that enables automation tools to be integrated into any product. The framework is highly independent and portable, with no strong coupling between the framework and the product. It is applicable to any product and is encapsulated as a service for product scheduling, reducing the self-testing costs of testing and development.

[0071] As can be seen, this application constructs a general use case template; the general use case template includes a pre-set first function for preparing use cases, a second function for determining whether a use case is executable, a third function for executing use cases, and a fourth function for cleaning up use cases; it determines a pre-defined interface list and encapsulates each interface in the interface list to obtain the corresponding encapsulated interface; the interface in the interface list includes a first interface for determining whether a use case is executable, a second interface for executing use cases, a third interface for obtaining the result of a single use case, and a fourth interface for obtaining a summary of the execution status of all use cases; based on the general use case template and all the encapsulated interfaces, a use case library service framework is built, and the use case library service framework is packaged and integrated into the target product to deploy the use case library service framework in the target product. Therefore, the construction process of the test case library service framework in this application includes two parts: first, building a general test case template, which needs to include a first function for preparing test cases, a second function for determining whether a test case is executable, a third function for executing test cases, and a fourth function for cleaning up test cases; second, encapsulating interfaces, specifically by first determining a predefined list of interfaces, including a first interface for determining whether a test case is executable, a second interface for executing test cases, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases. Each interface in the interface list is then encapsulated to obtain the corresponding encapsulated interface. Finally, based on the general test case template and all encapsulated interfaces, the test case library service framework is built and packaged and integrated into the target product for deployment. The above solution provides a test case library service framework that enables automation tools to be integrated into any product. The framework has strong independence and portability, is not strongly coupled with the product, is applicable to any product, and is encapsulated as a service for product scheduling, reducing the self-testing costs of testing and development.

[0072] See Figure 2 As shown in the figure, this application embodiment discloses a specific method for building a use case library service framework. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution.

[0073] Specifically, it includes:

[0074] Step S21: Construct a general use case template; the general use case template includes a first function for preparing use cases, a second function for determining whether use cases are executable, a third function for executing use cases, and a fourth function for cleaning up use cases.

[0075] Step S22: Determine a predefined list of interfaces and encapsulate each interface in the list to obtain the corresponding encapsulated interface; the interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases.

[0076] In this embodiment, the interface logic corresponding to the first interface is as follows: obtain the target test case corresponding to the global variable according to the current parameters, call and execute the first function corresponding to the target test case; if the first function fails to execute, return a first result indicating that the target test case is not executable; if the first function executes successfully, call the second function; if the second function executes successfully, return a second result indicating that the target test case is executable; if the second function fails to execute, return a first result indicating that the target test case is not executable.

[0077] It should also be noted that this embodiment uses the Python language to provide a general method for writing test case library services.

[0078] The parameters and return value of the first interface are as follows:

[0079]

[0080] like Figure 3 As shown, the interface logic corresponding to the first interface is as follows:

[0081] Based on the current parameters runId (run identifier) ​​and testcaseid (test case identifier), obtain the target test case information corresponding to testcaseId in the global variable GlobalConfig: determine the specific test case test1 to be called;

[0082] Call the first function corresponding to the test1 test case, namely the prepare function;

[0083] If the prepare function fails, it will return the first result False, indicating that the test case is not executable.

[0084] If the prepare function executes successfully, the second function, is_executable, will be called.

[0085] If the is_executable function executes successfully, it returns the second result True, indicating that the test case is executable;

[0086] If the is_executable function fails to execute, it returns the first result False, indicating that the test case is not executable.

[0087] In this embodiment, the interface logic corresponding to the second interface is as follows: Obtain the target test case corresponding to the global variable based on the current parameters, and add the target test case to the producer queue; if the target test case is successfully added to the producer queue, store the running parameters of the target test case in the running variable of the global variable, and trigger the consumer to run the target test case; otherwise, return a message indicating that the running status of the target test case is empty; set the preparation status of the target test case to running, and execute the first function corresponding to the target test case; if the first function fails to execute, set the preparation status of the target test case to failed. The execution status of the target test case is set to skipped. If the first function executes successfully, the preparation status of the target test case is set to successful, and the third function corresponding to the target test case is executed. If the third function fails, the execution status of the target test case is set to failed. If the test case execution function executes successfully, the execution status of the target test case is set to successful, and the fourth function corresponding to the target test case is executed. If the fourth function fails, the cleanup status of the target test case is set to failed. If the fourth function executes successfully, the cleanup status of the target test case is set to successful.

[0088] Furthermore, after storing the running parameters of the target test case into the running variable of the global variable, the method further includes: determining whether the running parameters are successfully stored into the running variable; if the storage is successful, returning the corresponding running identifier; if the storage fails, returning a message indicating that the running status of the target test case is empty.

[0089] The parameters and return value of the second interface are as follows:

[0090]

[0091] like Figure 4 As shown, the interface logic corresponding to the second interface is as follows:

[0092] Based on the current parameters runId and testcaseid, obtain the target test case information corresponding to testcaseId in the global variable GlobalConfig: determine the specific test case test1 to be called;

[0093] Add the information of the target test case test1 to the producer queue;

[0094] If the addition fails, return None, indicating that the running status is empty and the process will end directly;

[0095] If the addition is successful, the runtime parameters of the target test case test1 will be stored in the global variable GlobalConfig's runtime variable run_context;

[0096] If the storage fails, it returns None, indicating that the running status is empty and the process ends directly;

[0097] If the storage is successful, the run key (i.e., runId and testcaseId) will be returned.

[0098] Once the addition is successful, the consumer is triggered to run the target test case test1, and the result does not affect the subsequent storage steps.

[0099] The consumer consumes the target test case test1 information passed in by the producer and calls the specific instance test1.

[0100] Set the global variable GlobalConfig to the running status of test case test1;

[0101] Execute the prepare function of the target test case test1;

[0102] If the prepare function fails, the global variable GlobalConfig is set to the preparation status of test case test1 as failed, the running status of test1 is set to skipped, and the process ends directly.

[0103] If the prepare function executes successfully, the global variable GlobalConfig is set to the preparation status of test case test1 as successful;

[0104] Execute the execute function of the target test case test1;

[0105] If the execute function fails, the global variable GlobalConfig is set to the failure status of test case test1, and the process ends directly.

[0106] If the execute function executes successfully, the global variable GlobalConfig is set to the success status of test case test1;

[0107] Execute the destroy function of the target test case test1;

[0108] If the destroy function fails to execute, the global variable GlobalConfig is set to the failure status of test case test1, and the process ends.

[0109] If the destroy function executes successfully, the global variable GlobalConfig and the test case test1's cleanup status are set to successful.

[0110] It should be noted that the framework layer operates using the producer-consumer concept. Once the second interface is run, the producer writes the use case information into the producer queue. The consumer retrieves the parameter information stored in the producer queue every 0.5 seconds and executes the specific use case.

[0111] In this embodiment, the interface logic corresponding to the third interface is: to obtain the target test case corresponding to the global variable based on the current passed parameters.

[0112] The parameters and return values ​​of the third interface are as follows:

[0113]

[0114]

[0115] like Figure 5 As shown, the interface logic corresponding to the third interface is as follows:

[0116] Based on the current parameters runId and testcaseid, retrieve the information of the target test case test1 corresponding to the testcaseId in the global variable GlobalConfig.

[0117] In this embodiment, the interface logic corresponding to the fourth interface is as follows: obtain all test case information of the global variable, and summarize and statistically analyze the test case information according to the preset summary rules to obtain the summary result; wherein, the preset summary rules include counting the number of first test cases with non-empty test case running status and counting the number of second test cases with successful test case running status, and determining the success rate based on the number of first test cases and the data of the second test cases.

[0118] The parameters and return value of the fourth interface are as follows:

[0119]

[0120] like Figure 6 As shown, the interface logic corresponding to the fourth interface is as follows:

[0121] Retrieve all test case information from the global variable GlobalConfig, and aggregate the test case information according to preset aggregation rules to obtain the aggregated results:

[0122] total = the number of first test cases whose running status is not empty;

[0123] success = the number of second test cases whose execution status is successful;

[0124] Success rate success_percentage = success / total * 100%.

[0125] Step S23: Build a use case library service framework based on the general use case template and all the encapsulated interfaces, and package and integrate the use case library service framework into the target product to deploy the use case library service framework in the target product.

[0126] Step S24: Execute all use cases and retrieve the summary results of the fourth interface.

[0127] In this embodiment, the use case library service framework is packaged and integrated into the target product. Once the target product is successfully deployed, the environment information is dynamically obtained and the use case service is started to execute, and the summary results of the fourth interface are retrieved periodically.

[0128] Step S25: Determine the running status of all test cases based on the summarized results. If each running status is skipped, successful, or failed, the test case is determined to be completed; otherwise, the test case is determined to be failed.

[0129] In this embodiment, the running status of all test cases is determined based on the summary results. When the status of each test case is any one of SKIP, SUCCESS, or FAIL, the test case is determined to be completed and the result at this time is taken as the final result. Otherwise, the test case is determined to have failed and the result is sent back via email.

[0130] For more detailed processing procedures of steps S21 and S23, please refer to the corresponding content disclosed in the foregoing embodiments, which will not be repeated here.

[0131] As can be seen, this invention uses Python to provide a general method for writing test case library services, which can be applied to various products. This is equivalent to triggering automated testing with the product, which greatly ensures that the product output is testable and usable, and also reduces the self-testing costs of testing and development to another extent. The test case library service framework has strong independence and portability. Its framework is not strongly coupled with the product and can be applied to any product. One framework can be applied to multiple products.

[0132] See Figure 7 As shown in the figure, this application discloses an apparatus for building a use case library service framework, the apparatus comprising:

[0133] The test case template construction module 11 is used to construct a general test case template; the general test case template includes a first function for preparing test cases, a second function for determining whether a test case is executable, a third function for executing test cases, and a fourth function for cleaning up test cases;

[0134] The interface encapsulation module 12 is used to determine a predefined list of interfaces and encapsulate each interface in the list to obtain the corresponding encapsulated interface; the interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases;

[0135] The framework deployment module 13 is used to build a use case library service framework based on the general use case template and all the encapsulated interfaces, and to package and integrate the use case library service framework into the target product so as to deploy the use case library service framework in the target product.

[0136] As can be seen, this application constructs a general use case template; the general use case template includes a pre-set first function for preparing use cases, a second function for determining whether a use case is executable, a third function for executing use cases, and a fourth function for cleaning up use cases; it determines a pre-defined interface list and encapsulates each interface in the interface list to obtain the corresponding encapsulated interface; the interface in the interface list includes a first interface for determining whether a use case is executable, a second interface for executing use cases, a third interface for obtaining the result of a single use case, and a fourth interface for obtaining a summary of the execution status of all use cases; based on the general use case template and all the encapsulated interfaces, a use case library service framework is built, and the use case library service framework is packaged and integrated into the target product to deploy the use case library service framework in the target product. Therefore, the construction process of the test case library service framework in this application includes two parts: first, building a general test case template, which needs to include a first function for preparing test cases, a second function for determining whether a test case is executable, a third function for executing test cases, and a fourth function for cleaning up test cases; second, encapsulating interfaces, specifically by first determining a predefined list of interfaces, including a first interface for determining whether a test case is executable, a second interface for executing test cases, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases. Each interface in the interface list is then encapsulated to obtain the corresponding encapsulated interface. Finally, based on the general test case template and all encapsulated interfaces, the test case library service framework is built and packaged and integrated into the target product for deployment. The above solution provides a test case library service framework that enables automation tools to be integrated into any product. The framework has strong independence and portability, is not strongly coupled with the product, is applicable to any product, and is encapsulated as a service for product scheduling, reducing the self-testing costs of testing and development.

[0137] In some specific embodiments, the interface logic corresponding to the first interface in the device includes:

[0138] The first function call unit is used to obtain the target test case corresponding to the global variable based on the current parameters, and call and execute the first function corresponding to the target test case.

[0139] The first result acquisition unit is used to return a first result indicating that the target test case is not executable if the first function fails to execute; and to call the second function if the first function executes successfully.

[0140] The second result acquisition unit is used to return a second result indicating that the target test case is executable if the second function executes successfully; and to return a first result indicating that the target test case is not executable if the second function fails to execute.

[0141] In some specific embodiments, the interface logic corresponding to the second interface in the device is as follows:

[0142] The queue addition unit is used to obtain the target test case corresponding to the global variable based on the current parameters, and add the target test case to the producer queue;

[0143] The triggering unit is configured to, if the target test case is successfully added to the producer queue, store the running parameters of the target test case in the running variable of the global variable and trigger the consumer to run the target test case; otherwise, return a message that the running status of the target test case is empty.

[0144] The first function execution unit is used to set the preparation state of the target test case to running and execute the first function corresponding to the target test case;

[0145] The preparation state setting unit is used to set the preparation state of the target test case to failure and the running state of the target test case to skip if the first function fails to execute.

[0146] The third function execution unit is used to set the preparation status of the target test case to success and execute the third function corresponding to the target test case if the first function is executed successfully.

[0147] The running status setting unit is used to set the running status of the target test case to failure if the third function fails to execute; and to set the running status of the target test case to success if the test case execution function succeeds, and to execute the fourth function corresponding to the target test case.

[0148] The cleanup status setting unit is used to set the cleanup status of the target test case to failure if the fourth function fails to execute, and to set the cleanup status of the target test case to success if the fourth function executes successfully.

[0149] In some specific embodiments, the triggering unit is further configured to determine whether the running parameters are successfully stored in the running variables; if the storage is successful, the corresponding running identifier is returned; if the storage fails, a message indicating that the running status of the target test case is empty is returned.

[0150] In some specific embodiments, the interface logic corresponding to the third interface in the device is to obtain the target test case corresponding to the global variable based on the current passed parameters.

[0151] In some specific embodiments, the interface logic corresponding to the fourth interface in the device is as follows:

[0152] The information aggregation unit is used to obtain all test case information of global variables, and to aggregate and statistically analyze the test case information according to preset aggregation rules to obtain the aggregation result; wherein, the preset aggregation rules include counting the number of first test cases with non-empty test case running status and counting the number of second test cases with successful test case running status, and determining the success rate based on the number of first test cases and the data of second test cases;

[0153] Accordingly, after the framework deployment module 13, the system further includes:

[0154] The result retrieval unit is used to execute all test cases and retrieve the summary results of the fourth interface;

[0155] The result determination module is used to determine the running status of all test cases based on the summarized results. If each running status is skipped, successful, or failed, the test case is determined to be completed; otherwise, the test case is determined to be failed.

[0156] In some specific embodiments, the device further includes:

[0157] The first function reference unit is used to introduce a preset resource addition function into the general use case template based on the resource addition command, so as to establish a binding relationship between the new resource and the run identifier based on the preset resource addition function;

[0158] The second function reference unit is used to introduce a preset resource removal function into the general use case template based on the resource removal command, so as to remove the binding relationship between the resource to be removed and the running identifier based on the preset resource removal function;

[0159] The third function reference unit is used to introduce a preset resource acquisition function into the general use case template based on the resource acquisition command, so as to obtain the resource information corresponding to the run identifier based on the preset resource acquisition function.

[0160] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the method for building a use case library service framework executed by the electronic device disclosed in any of the foregoing embodiments.

[0161] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0162] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0163] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system 221, computer program 222 and data 223, etc., and the storage method can be temporary storage or permanent storage.

[0164] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of completing the method for building the use case library service framework executed by the electronic device 20 as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0165] Furthermore, this application also discloses a computer-readable storage medium storing a computer program. When the computer program is loaded and executed by a processor, it implements the method steps for building the use case library service framework disclosed in any of the foregoing embodiments.

[0166] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0167] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0168] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art.

[0169] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0170] The foregoing has provided a detailed description of the method, apparatus, device, and storage medium for building a use case library service framework provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for building a use case library service framework, characterized in that, include: Construct a general use case template; the general use case template includes a first function for preparing use cases, a second function for determining whether use cases are executable, a third function for executing use cases, and a fourth function for cleaning up use cases; A predefined list of interfaces is determined, and each interface in the list is encapsulated to obtain the corresponding encapsulated interface. The interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases. A use case library service framework is built based on the general use case template and all the encapsulated interfaces, and the use case library service framework is packaged and integrated into the target product to deploy the use case library service framework in the target product.

2. The method for building a use case library service framework according to claim 1, characterized in that, The interface logic corresponding to the first interface is as follows: Based on the current parameters, obtain the target test case corresponding to the global variable, and call and execute the first function corresponding to the target test case; If the first function fails to execute, a first result is returned to indicate that the target test case is not executable; If the first function executes successfully, then the second function is called; If the second function executes successfully, it returns a second result indicating that the target test case is executable; If the second function fails to execute, a first result is returned to characterize that the target test case is not executable.

3. The method for building a use case library service framework according to claim 1, characterized in that, The interface logic corresponding to the second interface is as follows: Obtain the target test case corresponding to the global variable based on the current parameters, and add the target test case to the producer queue; If the target test case is successfully added to the producer queue, the running parameters of the target test case are stored in the running variables of the global variables, and the consumer is triggered to run the target test case. Otherwise, return a message indicating that the target test case is running in an empty state; Set the preparation status of the target test case to running, and execute the first function corresponding to the target test case; If the first function fails to execute, the preparation status of the target test case is set to failure, and the running status of the target test case is set to skipped. If the first function executes successfully, the preparation status of the target test case is set to successful, and the third function corresponding to the target test case is executed. If the third function fails to execute, the running status of the target test case is set to failure; if the test case execution function executes successfully, the running status of the target test case is set to success, and the fourth function corresponding to the target test case is executed. If the fourth function fails to execute, the cleanup status of the target test case is set to failure. If the fourth function executes successfully, the cleanup status of the target test case is set to successful.

4. The method for building the use case library service framework according to claim 3, characterized in that, After storing the runtime parameters of the target test case into the runtime variables of the global variable, the method further includes: Determine whether the running parameters have been successfully stored in the running variables; If storage is successful, the corresponding runtime identifier is returned; if storage fails, a message indicating that the runtime status of the target test case is empty is returned.

5. The method for building a use case library service framework according to claim 1, characterized in that, The interface logic corresponding to the third interface is as follows: Retrieve the target test case corresponding to the global variable based on the current parameters.

6. The method for building a use case library service framework according to claim 1, characterized in that, The interface logic corresponding to the fourth interface is as follows: Obtain all test case information of global variables, and summarize and statistically analyze the test case information according to preset summarization rules to obtain summary results; wherein, the preset summarization rules include counting the number of first test cases with non-empty test case running status and counting the number of second test cases with successful test case running status, and determining the success rate based on the number of first test cases and the data of second test cases; Accordingly, after deploying the use case library service framework in the target product, the method further includes: Execute all test cases and retrieve the summary results from the fourth interface; Based on the summarized results, the running status of all test cases is determined. If each running status is skipped, successful, or failed, the test case is determined to have been executed successfully; otherwise, the test case is determined to have failed.

7. The method for constructing a use case library service framework according to any one of claims 1 to 6, characterized in that, Also includes: Based on the resource addition command, a preset resource addition function is introduced into the general use case template to establish a binding relationship between the newly added resource and the run identifier. Based on the resource removal command, a preset resource removal function is introduced into the general use case template to remove the binding relationship between the resource to be removed and the run identifier. Based on the resource acquisition command, a preset resource acquisition function is introduced into the general use case template to obtain the resource information corresponding to the run identifier based on the preset resource acquisition function.

8. A device for building a use case library service framework, characterized in that, include: The test case template building module is used to build a general test case template; the general test case template includes a first function for preparing test cases, a second function for determining whether a test case is executable, a third function for executing test cases, and a fourth function for cleaning up test cases; An interface encapsulation module is used to determine a predefined list of interfaces and encapsulate each interface in the list to obtain a corresponding encapsulated interface. The interfaces in the list include a first interface for determining whether a test case is executable, a second interface for executing the test case, a third interface for obtaining the result of a single test case, and a fourth interface for obtaining a summary of the execution status of all test cases. The framework deployment module is used to build a use case library service framework based on the general use case template and all the encapsulated interfaces, and to package and integrate the use case library service framework into the target product to deploy the use case library service framework in the target product.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method for building the use case library service framework as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the steps of the method for building a use case library service framework as described in any one of claims 1 to 7.

Images