Smoking test method and device, electronic equipment, storage medium and program product

By acquiring image files and analyzing resource requirements, combining the main process, single module and scene testing, the problem of insufficient coverage of traditional smoke tests is solved, and the coverage and accuracy of the test is significantly improved.

CN119690827APending Publication Date: 2025-03-25CHINA UNITED NETWORK COMM GRP CO LTD +2
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411745197.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-29
Publication Date
2025-03-25

AI Technical Summary

Technical Problem

Traditional smoke tests have low test coverage and fail to fully verify the functionality and stability of the software.

Method used

By obtaining the mirror file corresponding to the smoke test script, analyzing the resource requirements information of the software to be tested, and ensuring that the test environment has sufficient resources to support testing. Based on the association relationship between the image file and the functional module, combined testing is carried out, including main process testing, single-module testing and scenario testing.

Benefits of technology

The test coverage is significantly improved, the test results obtained are more representative and accurate, and can better evaluate the basic stability of the software.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119690827A_ABST
    Figure CN119690827A_ABST
Patent Text Reader

Abstract

The invention provides a smoking test method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of software testing. The method comprises the following steps: firstly, acquiring a test requirement of to-be-tested software and a mirror image file corresponding to a smoking test script; analyzing resource demand information of the to-be-tested software on the environment resources according to the test demand; determining whether the monitored environment resource information meets resource requirements or not; if the monitored environment resource information meets the resource requirement, based on the mirror image file, according to the incidence relation between the function modules corresponding to the to-be-tested software, combined testing is conducted on the to-be-tested software, and a testing result is obtained. According to the invention, the test coverage can be improved, and the stability of the test environment is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of software testing technology, and in particular to a smoke testing method, device, electronic device, storage medium and program product. Background Art

[0002] Smoke testing is a software testing method used to conduct a preliminary check on the basic functions of the software to determine whether it can be tested more deeply. In software development, smoke testing is usually performed after a new version or build is completed. Its main purpose is to verify whether the core functions of the software are working properly and ensure the basic stability and testability of the software.

[0003] Smoke testing is usually performed on new software builds. Based on the main functions of the software and common usage scenarios of users, a set of representative test cases are selected and executed to verify whether the basic functions of the software work as expected, thereby evaluating the basic stability of the software based on the test results. If all core functions work properly, the software passes the smoke test and can undergo more in-depth functional testing.

[0004] However, traditional smoke testing has low test coverage. Summary of the invention

[0005] The present application provides a smoke test method, device, electronic device, storage medium and program product to solve the technical problem of low test coverage of traditional smoke tests.

[0006] In a first aspect, the present application provides a smoke test method, comprising:

[0007] Obtain the image files corresponding to the test requirements and smoke test scripts of the software to be tested;

[0008] Analyze the resource requirements of the software to be tested for environmental resources according to the test requirements;

[0009] Determine whether the monitored environmental resource information meets resource requirements;

[0010] If the monitored environmental resource information meets the resource requirements, based on the image file and according to the association between the functional modules corresponding to the software to be tested, a combination test is performed on the software to be tested to obtain the test results. The combination test includes main process test, single module test and scenario test.

[0011] Optionally, determining whether the monitored environmental resource information meets resource requirements includes:

[0012] Determine resource matching parameters based on resource demand information and environmental resource information;

[0013] Determine whether the resource matching parameter meets a preset resource matching parameter threshold;

[0014] If the resource matching parameter meets the resource matching parameter threshold, then the environmental resource information meets the resource requirement.

[0015] Optionally, determining resource matching parameters according to resource demand information and environmental resource information includes:

[0016] Determine resource index scores and resource index weights based on resource demand information and environmental resource information. The resource index scores represent the degree of difference between the required resource index in the resource demand information and the actual resource index in the environmental resource information.

[0017] The resource indicator score and the resource indicator weight are weighted and summed to obtain the resource matching parameter.

[0018] Optionally, after determining whether the resource matching parameter meets a preset resource matching parameter threshold, the method further includes:

[0019] If the resource matching parameter does not meet the resource matching parameter threshold, determine the resource indicators that do not meet the resource requirements and the degree of influence of the resource indicators on the test results based on the resource matching parameters;

[0020] Generate the first prompt information based on resource indicators and impact level.

[0021] Optionally, based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the software to be tested is subjected to a combination test to obtain a test result, including:

[0022] Based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the container corresponding to the image file is started in the test environment to perform the main process test on the software to be tested;

[0023] If the main process test passes, perform single module test and scenario test on the functional modules to obtain the test results.

[0024] Optionally, the method further comprises:

[0025] Based on the image file, a single-mode test is performed on the functional module to obtain the test results. The single-mode test includes any one of the main process test, single module test, and scenario test.

[0026] Optionally, after performing a combination test on the software to be tested based on the image file and according to the association relationship between the functional modules corresponding to the software to be tested and obtaining the test result, the method further includes:

[0027] Determine test data based on test results. Test data includes test case execution rate, test case pass rate, defect density, and defect severity.

[0028] Based on the test data, the risk level of the software to be tested is calculated and the risk assessment parameters are determined;

[0029] If the risk assessment parameter does not meet the preset risk assessment parameter threshold, a second prompt message is generated based on the test data.

[0030] In a second aspect, the present application provides a smoke test device, comprising:

[0031] The acquisition module is used to obtain the test requirements of the software to be tested and the image file corresponding to the smoke test script;

[0032] The analysis module is used to analyze the resource demand information of the software to be tested for environmental resources according to the test requirements;

[0033] A determination module is used to determine whether the monitored environmental resource information meets the resource requirements;

[0034] The test module is used to perform a combination test on the software to be tested based on the image file and the relationship between the functional modules corresponding to the software to be tested if the monitored environmental resource information meets the resource requirements, and obtain the test results. The combination test includes main process test, single module test and scenario test.

[0035] Optionally, a module is determined, specifically for:

[0036] Determine resource matching parameters based on resource demand information and environmental resource information;

[0037] Determine whether the resource matching parameter meets a preset resource matching parameter threshold;

[0038] If the resource matching parameter meets the resource matching parameter threshold, then the environmental resource information meets the resource requirement.

[0039] Optionally, the determination module is further configured to:

[0040] Determine resource index scores and resource index weights based on resource demand information and environmental resource information. The resource index scores represent the degree of difference between the required resource index in the resource demand information and the actual resource index in the environmental resource information.

[0041] The resource indicator score and the resource indicator weight are weighted and summed to obtain the resource matching parameter.

[0042] Optionally, the smoke test device further comprises: a generation module;

[0043] A generating module, for determining whether the resource matching parameter satisfies a preset resource matching parameter threshold, and if the resource matching parameter does not satisfy the resource matching parameter threshold, determining the resource indicator that does not satisfy the resource requirement and the degree of influence of the resource indicator on the test result according to the resource matching parameter;

[0044] Generate the first prompt information based on resource indicators and impact level.

[0045] Optionally, a test module is specifically used to:

[0046] Based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the container corresponding to the image file is started in the test environment to perform the main process test on the software to be tested;

[0047] If the main process test passes, perform single module test and scenario test on the functional modules to obtain the test results.

[0048] Optionally, the test module is also used to:

[0049] Based on the image file, a single-mode test is performed on the functional module to obtain the test results. The single-mode test includes any one of the main process test, single module test, and scenario test.

[0050] Optionally, the build module is also used to:

[0051] Based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the software to be tested is combined and tested. After the test results are obtained, the test data is determined according to the test results. The test data includes the test case execution rate, the test case pass rate, the defect density and the defect severity;

[0052] Based on the test data, the risk level of the software to be tested is calculated and the risk assessment parameters are determined;

[0053] If the risk assessment parameter does not meet the preset risk assessment parameter threshold, a second prompt message is generated based on the test data.

[0054] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0055] Memory stores computer-executable instructions;

[0056] The processor executes the computer-executable instructions stored in the memory to implement the method as described in the first aspect and various possible implementations of the first aspect.

[0057] In a fourth aspect, the present application provides a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the method as described in the first aspect and various possible implementation methods of the first aspect.

[0058] In a fifth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the method as described in the first aspect and various possible implementation methods of the first aspect.

[0059] The smoke test method, device, electronic device, storage medium and program product provided by the present application obtain the image file corresponding to the smoke test script, and analyze the resource requirement information of the software to be tested according to the test requirements, so as to ensure that the test environment has sufficient resources to support the test, and then combine the main process test, single module test and scenario test into the smoke test to verify the performance of the software under complex conditions. In this way, more functions and scenarios are covered, and the obtained test results are more representative and accurate, which can significantly improve the test coverage and thus better evaluate the basic stability of the software. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0061] Figure 1 Schematic diagram of the smoke test method provided in the embodiment of the present application Figure 1 ;

[0062] Figure 2 Schematic diagram of the smoke test method provided in the embodiment of the present application Figure 2 ;

[0063] Figure 3 Schematic diagram of the smoke test method provided in the embodiment of the present application Figure 3 ;

[0064] Figure 4 A schematic diagram of the main process test process provided in the embodiment of the present application;

[0065] Figure 5 A schematic diagram of a scenario test process provided in an embodiment of the present application;

[0066] Figure 6 A schematic diagram of a single-mode test process provided in an embodiment of the present application;

[0067] Figure 7 A schematic diagram of the structure of a smoke test device provided in an embodiment of the present application;

[0068] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0069] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0070] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0071] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0072] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0073] During the software development process, it is usually necessary to manually configure the test environment, including installing the software, configuring dependencies, and setting environment variables. Then, a set of representative test cases are selected from the test case library. These test cases are usually based on the main functions of the software. The selected test cases are executed manually or through automated tools to verify whether the basic functions of the software work as expected. Finally, the basic stability of the software is evaluated based on the test results. If all core functions work properly, the software passes the smoke test and can undergo more in-depth functional testing. It can be seen that the test coverage of traditional smoke tests is low, that is, it usually only covers the core functions of the software, and may ignore some edge cases and complex scenarios, resulting in potential problems not being discovered.

[0074] Based on this, the present application proposes a smoke test method, device, electronic device, storage medium and program product. The method is based on the consideration that the software needs to be combined with software, modules and scenarios in actual applications, and introduces combination testing, including main process testing, single module testing and scenario testing. Specifically, the main process test verifies the core functions of the software, the single module test checks the independent functions of the module, and the scenario test simulates the real usage scenario, thereby improving the test coverage and more comprehensively evaluating the basic functions and stability of the software. On this basis, since the environmental resources required for the combination test may be different from those of the traditional test, if the resource demand information of the software to be tested is analyzed, it is possible to prevent waste or shortage of resources, ensure that the test environment has sufficient resources to support the test, and make the test process stable. In addition, considering that the combination test may cause the configuration process in the test to be cumbersome and affect the test efficiency, the image file corresponding to the smoke test script can be obtained, so as to quickly deploy the test environment and improve the test efficiency.

[0075] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0076] Figure 1 Schematic diagram of the smoke test method provided in the embodiment of the present application Figure 1 .like Figure 1 As shown, the method may include:

[0077] S101, obtaining the image file corresponding to the test requirements of the software to be tested and the smoke test script.

[0078] The execution subject of the embodiment of the present application is an electronic device, which may be a terminal device, such as a laptop computer, a desktop computer, a tablet computer, etc., or a server. This embodiment does not specifically limit this.

[0079] Among them, test requirements can refer to the functional and performance requirements of the software to be tested defined according to actual needs. These requirements determine the scope and objectives of the test.

[0080] The smoke test script is a set of automated test scripts used to quickly verify whether the basic functions of the software are working properly. The script usually covers the core functions of the software. In this embodiment, the smoke test script can be written in python, and the resulting .py file package includes scripts such as file parsing, use case generation, resource monitoring, data analysis, and test report generation.

[0081] The image file corresponding to the smoke test script contains the executable package of the software application to be tested and its operating environment. In containerization technology, the image file is used to create a container instance to ensure the consistency of the environment. In this embodiment, a Dockerfile can be used to create an image file, including initContainer, python operating environment, running script dependency package installation, etc. A container refers to an independent operating environment created from an image file, which contains an application and all its dependencies, ensuring the consistency and isolation of the test.

[0082] It is understandable that using image files can ensure that each test is run in the same environment, reducing environment configuration errors and improving the reliability of test results.

[0083] S102: Analyze the resource demand information of the software to be tested for environmental resources according to the test requirements.

[0084] The resource requirement information may refer to the hardware and software resources required by the software to be tested during operation, including the CPU usage, memory usage, storage space (such as disk input / output data volume), network bandwidth, etc.

[0085] It can be understood that by analyzing resource requirements and environmental resource information, the reasonable allocation of test environment resources can be ensured to avoid resource waste or shortage. At the same time, it can ensure that the test environment can support the entire test process and enhance test stability.

[0086] S103: Determine whether the monitored environmental resource information meets resource requirements.

[0087] The environmental resource information may refer to the resource information available in the current test environment, which is used to evaluate whether the resource requirements of the software can be met.

[0088] It should be understood that if the environment resource information is insufficient, it may be necessary to adjust the environment configuration or allocate more resources.

[0089] S104: If the monitored environmental resource information meets the resource requirements, based on the image file and according to the association relationship between the functional modules corresponding to the software to be tested, a combination test is performed on the software to be tested to obtain a test result.

[0090] Among them, combined testing includes main process testing, single module testing, and scenario testing to comprehensively evaluate the functions and performance of the software. Main process testing refers to verifying whether the core functions and main business processes of the software are working properly. Single module testing refers to testing a single module in the software to be tested to ensure that the module can correctly perform its functions when running independently. Scenario testing refers to simulating the user's operations in a specific situation to verify the performance of the software in complex usage scenarios. Specifically, a single module use case refers to a use case for a functional module, which only focuses on a specific part of the software to be tested and describes the input, processing, and output of the functional module in detail. According to the association relationship between the functional modules corresponding to the software to be tested, scenario-based use cases can be obtained. Scenario-based use cases are use cases based on user scenarios or business processes, which describe how users interact with the software to be tested through a series of steps to complete specific tasks.

[0091] The association relationship between the functional modules corresponding to the software to be tested may refer to the interaction and dependency relationship between different functional modules in the software to be tested, and these relationships affect the execution order and data flow of each module.

[0092] It should be noted that in the combined test, for each functional module, its main process is verified first. If the main process test fails, further scenario testing of the module is stopped, so as to discover key problems of the functional module at an early stage and avoid wasting time and resources in subsequent testing.

[0093] It can be understood that by verifying the core functions of the software to be tested through main process testing, checking the independent functions of the functional modules through single module testing, and simulating the usage of the software to be tested in real usage scenarios through scenario testing, the test coverage can be improved and the deficiencies in the prior art can be effectively solved. At the same time, this embodiment shortens the test preparation time and improves the overall test efficiency through automated test processes and rapid environment deployment.

[0094] The smoke test method provided in the embodiment of the present application obtains the test requirements and corresponding image files of the software to be tested, analyzes the resource requirement information of the software to be tested, and then determines whether the resource information of the current environment meets the resource requirements of the software. If the environmental resources meet the requirements, a combined test is performed based on the association between the image file and the functional module. Through main process testing, single module testing and scenario testing, the functions and performance of the software are comprehensively evaluated, and test results are obtained, thereby covering the core functions, independent modules and complex usage scenarios of the software, and significantly improving the coverage of the test.

[0095] Figure 2 Schematic diagram of the smoke test method provided in the embodiment of the present application Figure 2 .like Figure 2 As shown, this embodiment is Figure 1Based on the embodiment, the process of S103 is described in detail, which specifically includes the following steps:

[0096] S201. Determine resource matching parameters according to resource demand information and environmental resource information.

[0097] Among them, resource matching parameters are used to quantify and compare the indicators of resource demand information and environmental resource information. By quantifying the resource demand information, the performance of the software under different loads and usage scenarios can be analyzed. According to the characteristics and requirements of the software, the reasonable range and minimum threshold of each resource indicator in the resource information can be determined, and then the quantified resource demand can be compared with the environmental resource information to define the resource matching parameters.

[0098] For example, in high-load or concurrent access scenarios, higher CPU and memory configurations may be required. By simulating the above scenarios, the upper and lower limits of resource requirements can be determined. Resource matching parameters can be defined through simple numerical comparisons (such as whether the number of CPU cores in the environment is greater than or equal to the required number of cores) or more complex calculations (such as whether the network delay is within an acceptable range).

[0099] Furthermore, in actual testing, it is also necessary to verify in advance whether the resource matching parameters accurately reflect the resource requirements of the software to be tested. If a mismatch or performance problem is found, the resource matching parameters or thresholds may need to be adjusted.

[0100] S202: Determine whether the resource matching parameter meets a preset resource matching parameter threshold.

[0101] The resource matching parameter threshold may refer to a standard or limit preset according to actual conditions and testing experience, and is used to determine whether the resource matching parameter is high enough to meet the resource requirements of the software to be tested.

[0102] In this embodiment, the requirements for environmental resources are analyzed according to the characteristics and requirements of the software to be tested. Through in-depth research on the software requirements document and technical specifications, accurate resource requirement information such as the minimum configuration required for software operation, network performance requirements, and specific versions that the software depends on can be determined. Furthermore, it is necessary to consider the resource requirements of the software to be tested in special scenarios such as high load and concurrent access, and determine the reasonable range and corresponding threshold of each resource through simulation and analysis of different scenarios.

[0103] S203: If the resource matching parameter meets the resource matching parameter threshold, the environmental resource information meets the resource requirement.

[0104] In this embodiment, if the resource matching parameter meets the resource matching parameter threshold, it is considered that the environment resource information meets the resource requirement, that is, the test environment has sufficient resources to support the operation of the software to be tested.

[0105] In one achievable manner, S201 may be specifically implemented through the following steps:

[0106] Firstly, the resource indicator score and resource indicator weight are determined according to the resource demand information and the environmental resource information. Then, the resource indicator score and resource indicator weight are weighted and summed to obtain the resource matching parameters.

[0107] Among them, the resource indicator score represents the difference between the demand resource indicators in the resource demand information and the actual resource indicators in the environmental resource information. It reflects the matching degree of each resource indicator (such as CPU, memory, storage, etc.), and can calculate the matching degree between the resource demand information and the environmental resource information in a quantitative way.

[0108] Resource indicator weight may refer to the importance of each resource indicator in the overall resource matching. Different resource indicators may have different effects on the operation of the software, so different weights need to be assigned.

[0109] Specifically, by setting a corresponding resource indicator weight for each resource indicator, scoring is performed according to the degree of difference between the actual monitoring value and the required value. For indicators that exceed the requirements, certain points are deducted, and correspondingly, for indicators that meet the requirements, certain points are added to obtain the resource indicator score, and then the resource matching parameters are obtained by weighted summation.

[0110] Specifically, in the calculation resource matching parameters, i is the resource index, D i is the resource demand indicator, P i is the actual resource indicator, Pr i is the resource indicator score, Wr i is the resource indicator weight, and Pr is the resource matching parameter.

[0111] (1) When the actual resource index meets the required resource index (P i ≤D i ), the resource indicator score can be expressed as:

[0112] Pr i =100

[0113] The full score can be set according to actual conditions. In this embodiment, 100 points is the full score.

[0114] (2) When the actual resource index exceeds the required resource index (P i >D i ), the resource indicator score can be expressed as:

[0115]

[0116] (3) According to the resource index score calculated by the above formula and the preset resource index weight, the resource matching parameters can be obtained:

[0117]

[0118] As an example, for the resource indicator of CPU usage, if the actual usage rate in the real-time monitored environmental resource information is 90%, and the upper limit specified in the resource demand information is 60%, then the current actual usage rate exceeds the specified upper limit value, and corresponding points are deducted according to the degree of difference. If the full score is 100 points and the difference is 30%, then the resource indicator score obtained according to the formula in (2) above is 50 points. If the preset resource indicator weight of CPU usage is 0.3, then the resource matching parameter is 50×0.3=15. If the resource matching parameter threshold of CPU usage is 30, then the matching degree is low and the environmental resource information does not meet the resource demand.

[0119] In this embodiment, the total resource matching parameter of the software to be tested may be obtained by summing up the resource matching parameters of the various resource indicators, so as to perform unified quantitative management.

[0120] It can be understood that by weighted summation of resource indicator scores and weights, a method for quantifying resource matching parameters is provided to evaluate the matching degree between environmental resources and demand resources, which improves the accuracy of the evaluation, helps identify deficiencies or surpluses in resource allocation, and supports more optimized resource allocation and distribution.

[0121] Accordingly, after the above step S202, if the resource matching parameter does not meet the resource matching parameter threshold, the specific processing steps may be:

[0122] Firstly, according to the resource matching parameters, the resource indicators that do not meet the resource requirements and the degree of influence of the resource indicators on the test results are determined; then, according to the resource indicators and the degree of influence, the first prompt information is generated.

[0123] It should be understood that the smaller the resource matching parameter is, the lower the environmental resource matching degree is, which means that the resource indicator may affect the testing process. Therefore, the first prompt information needs to be conveyed to the testers and relevant managers in a timely manner.

[0124] The degree of influence of resource indicators on test results indicates the impact that insufficient resources may have on test accuracy, stability or performance.

[0125] The first prompt information includes notifications or suggestions generated based on resource matching analysis, which prompt the user which resources are insufficient, the possible impact on the test results, possible solutions or precautions, etc. The first prompt information can be an email notification, a text message reminder, etc.

[0126] As an example, the first prompt information details that the CPU utilization rate in the monitored environmental resource information is 90%, the upper limit specified in the resource demand information is 60%, the resource indicator score is 50 points, the resource indicator weight is 0.3, the resource matching parameter is 15, and the resource matching parameter threshold is 30. The CPU utilization rate is too high, which may increase the system response time, affect the execution time of the test case, and cause the test environment to be unstable, increase the risk of system crashes, and cause the test process to be interrupted. It is necessary to optimize the test environment and adjust the test load.

[0127] It can be understood that by analyzing the resource matching parameters in detail, it is possible to quickly identify and locate deficiencies in resource configuration, improve the accuracy and efficiency of problem identification, and the generated first prompt information provides users with specific guidance and suggestions, helping users take appropriate measures to optimize resource configuration and ensure the applicability of the test environment.

[0128] The smoke test method provided in the embodiment of the present application ensures the reasonable allocation of test environment resources by accurately calculating resource matching parameters, avoids resource waste or shortage, improves resource utilization efficiency, and reduces the risk of test failure or inaccuracy due to insufficient resources by ensuring that environmental resources meet demand, thereby enhancing the stability of the test environment.

[0129] Figure 3 Schematic diagram of the smoke test method provided in the embodiment of the present application Figure 3 .like Figure 3 As shown, this embodiment is Figure 1 Based on the embodiment, the process of S104 is described in detail, which specifically includes the following steps:

[0130] S301. Based on the image file and according to the association relationship between the functional modules corresponding to the software to be tested, start the container corresponding to the image file in the test environment to perform a main process test on the software to be tested.

[0131] S302: If the main process test passes, perform single module test and scenario test on the functional modules to obtain test results.

[0132] like Figure 4 As shown, Figure 4The schematic flow chart of the main flow test provided for the embodiment of the present application, when performing the smoke test, the test is carried out in sequence according to the single module, that is, module 1, module 2, ..., module N are tested respectively, so as to quickly find obvious problems in the single functional module, and lay the foundation for subsequent in-depth testing. For each module, the main flow test of the module is first carried out. If the main flow verification fails, the test of the single module is stopped, and the main flow test result is directly output, which helps to find the key problems of the module at an early stage and avoid wasting time and resources in subsequent tests. When the main flow verification passes, the single module test is carried out again, and the single module test result is output.

[0133] like Figure 5 As shown, Figure 5 The flowchart of the scenario test provided in the embodiment of the present application is that the scenario test is used to simulate the use of different users in different scenarios. The test is performed according to a single scenario, that is, the test is performed in scenario 1, scenario 2, ..., scenario N respectively. The main process test associated with the functional module determines whether the scenario test is executed. If the associated main process test fails in a certain scenario, the scenario use case execution fails and the scenario test needs to be performed again. Correspondingly, when the associated main process tests are all passed, the scenario use case is executed (scenario test is performed) and the scenario test results are output.

[0134] Correspondingly, after the above step S302, the test data can also be determined based on the test results, and then the risk level of the software to be tested can be calculated based on the test data to determine the risk assessment parameters. If the risk assessment parameters do not meet the preset risk assessment parameter thresholds, a second prompt information is generated based on the test data.

[0135] Among them, test data includes test case execution rate, test case pass rate, defect density and defect severity, which are a series of indicators used to evaluate test results and software quality. The test case execution rate refers to the ratio of the number of executed test cases to the total number of test cases, reflecting the coverage of the test. The test case pass rate refers to the ratio of the number of passed test cases to the number of executed test cases, reflecting the correctness of the software function. Defect density refers to the number of defects per unit code volume (such as per thousand lines of code), that is, the ratio of the number of defects to the size of the software, reflecting the quality level of the software to be tested. Defect severity refers to the degree of impact of the defect on the software function or performance, and is usually divided into different levels (such as low, medium, high, and fatal).

[0136] Risk assessment parameters are indicators that quantify the software risk level. They are calculated based on test data and are used to assess the risk of the software in its current state. Risk assessment parameter thresholds can refer to the preset standards or limits of risk assessment parameters, which are used to determine whether the risk assessment parameters are within an acceptable range.

[0137] The second prompt information may refer to a notification or suggestion generated based on the risk assessment analysis, which is used to prompt the user of the risk level of the software to be tested and possible improvement measures, etc.

[0138] Specifically, the collected test results are analyzed in depth, and the test data can be calculated by the following formula:

[0139] (1) Test case execution rate:

[0140]

[0141] Among them, P exe is the test case execution rate; Exenum is the number of executed test cases, and CaseNum is the total number of test cases.

[0142] (2) Test case pass rate:

[0143]

[0144] Among them, P pass is the test case pass rate; Passnum is the number of test cases passed, and Exenum is the number of executed test cases.

[0145] (3) Defect density:

[0146]

[0147] Among them, P d is the defect density; Bugnum is the total number of defects; Codenum is the number of product codes.

[0148] (4) Defect severity:

[0149]

[0150] Among them, P s is the severity of the defect; i is the type of severity level; bugnum is the corresponding defect number; bugLev is the corresponding severity level coefficient. The defect severity level coefficient is generally defined as 1, 2, 3, and 4. The larger the number, the more severe the defect.

[0151] Then, based on the test data, the risk level of the software to be tested is comprehensively evaluated. In this embodiment, a risk assessment model can be established, and the test case execution rate, test case pass rate, defect density and defect severity are used as input variables. By presetting weight values ​​for risk features and then performing weighted summation, the risk assessment parameters can be calculated:

[0152]

[0153] Among them, R is the risk assessment parameter; j is the indicator type in the test data; P j is the above test data, i.e., the risk characteristic value; W j is the weight of each risk characteristic value.

[0154] Then, a risk assessment parameter threshold is set. When the risk assessment parameter R exceeds the preset threshold, a risk warning is triggered. The risk level can adopt a grading system, such as low risk, medium risk and high risk, to generate a second prompt information. Similar to the first prompt information, the second prompt information can include the source of risk, possible improvement measures, and suggestions for software release.

[0155] It is understandable that through risk assessment, the development team can better control software quality, reduce the number and severity of defects, and improve software stability and reliability. Risk assessment and prompt information, that is, the second prompt information, provides data support and direction guidance for the continuous improvement of the software, which helps to optimize processes and strategies in future development and testing.

[0156] The smoke test method provided in the embodiment of the present application, through the main process test, prioritizes the verification of the core functions of the software, ensures the reliability and stability of key business processes, and then combines single module testing and scenario testing to comprehensively cover various functional modules and usage scenarios of the software, thereby improving the coverage and depth of the test. At the same time, container technology is used to ensure that each test runs in the same environment, thereby reducing environmental configuration errors and improving the reliability of test results.

[0157] Figure 6 The following is a flow chart of a single-mode test provided in an embodiment of the present application. Figure 6 As shown, this embodiment is based on the above embodiment to illustrate the single-mode test process, and the method includes:

[0158] Based on the image file, a single-mode test is performed on the functional module to obtain the test results. The single-mode test includes any one of the main process test, single module test, and scenario test.

[0159] In this embodiment, the single mode, that is, the main process test, single module test, and scenario test are performed on a single functional module separately, and the main process test results, single module test results, and scenario test results are output respectively. The specific selection depends on the user's test goals and needs. Unlike the combination test, in the single mode test, the scenario test does not depend on whether the associated main process passes the test, but can directly execute the scenario test. This test mode is suitable for in-depth and independent testing of specific modules, and can more focusedly discover hidden problems.

[0160] The smoke test method provided in the embodiment of the present application, through a single-mode test method, allows the most appropriate test strategy to be selected according to specific needs, provides flexibility and targeting of the test, reduces unnecessary test steps and resource consumption through selective testing, improves the overall test efficiency, and can more quickly identify and locate problems by testing a single functional module, supporting modular development and testing strategies.

[0161] Figure 7 This is a schematic diagram of the structure of the smoke test device provided in the embodiment of the present application. Figure 7 As shown, the smoke test device 70 includes:

[0162] The acquisition module 701 is used to obtain the image file corresponding to the test requirements of the software to be tested and the smoke test script;

[0163] The analysis module 702 is used to analyze the resource demand information of the software to be tested for the environmental resources according to the test requirements;

[0164] Determination module 703, used to determine whether the monitored environmental resource information meets the resource requirements;

[0165] Test module 704 is used to perform combined testing on the software to be tested based on the image file and the relationship between the functional modules corresponding to the software to be tested if the monitored environmental resource information meets the resource requirements, and obtain the test results. The combined testing includes main process testing, single module testing, and scenario testing.

[0166] Optionally, the determination module 703 is specifically configured to:

[0167] Determine resource matching parameters based on resource demand information and environmental resource information;

[0168] Determine whether the resource matching parameter meets a preset resource matching parameter threshold;

[0169] If the resource matching parameter meets the resource matching parameter threshold, then the environmental resource information meets the resource requirement.

[0170] Optionally, the determination module 703 is further configured to:

[0171] Determine resource index scores and resource index weights based on resource demand information and environmental resource information. The resource index scores represent the degree of difference between the required resource index in the resource demand information and the actual resource index in the environmental resource information.

[0172] The resource indicator score and the resource indicator weight are weighted and summed to obtain the resource matching parameter.

[0173] Optionally, the smoke test device further comprises: a generation module;

[0174] A generating module, for determining whether the resource matching parameter satisfies a preset resource matching parameter threshold, and if the resource matching parameter does not satisfy the resource matching parameter threshold, determining the resource indicator that does not satisfy the resource requirement and the degree of influence of the resource indicator on the test result according to the resource matching parameter;

[0175] Generate the first prompt information based on resource indicators and impact level.

[0176] Optionally, the testing module 704 is specifically configured to:

[0177] Based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the container corresponding to the image file is started in the test environment to perform the main process test on the software to be tested;

[0178] If the main process test passes, perform single module test and scenario test on the functional modules to obtain the test results.

[0179] Optionally, the testing module 704 is further configured to:

[0180] Based on the image file, a single-mode test is performed on the functional module to obtain the test results. The single-mode test includes any one of the main process test, single module test, and scenario test.

[0181] Optionally, the build module is also used to:

[0182] Based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the software to be tested is combined and tested. After the test results are obtained, the test data is determined according to the test results. The test data includes the test case execution rate, the test case pass rate, the defect density and the defect severity;

[0183] Based on the test data, the risk level of the software to be tested is calculated and the risk assessment parameters are determined;

[0184] If the risk assessment parameter does not meet the preset risk assessment parameter threshold, a second prompt message is generated based on the test data.

[0185] The smoke test device provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be described in detail here.

[0186] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 As shown, the electronic device 80 provided in the embodiment of the present application includes: at least one processor 801 and a memory 802. The electronic device 80 also includes a communication component 803. The processor 801, the memory 802 and the communication component 803 are connected via a bus 804.

[0187] In a specific implementation process, at least one processor 801 executes the computer execution instructions stored in the memory 802, so that at least one processor 801 executes the above-mentioned character string cutting method.

[0188] The specific implementation process of the processor 801 can be found in the above-mentioned method embodiment, and its implementation principle and technical effect are similar, so the embodiments of this application will not be repeated here.

[0189] The electronic device provided in the embodiment of the present application can be implemented as Figure 1 The string cutting device is used to execute the string cutting method provided by any of the above method embodiments, and its implementation principle and technical effect are similar, which will not be repeated here.

[0190] In the above Figure 8 In the illustrated embodiment, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present application may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0191] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0192] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0193] The present application also provides a computer program product, including a computer program, which implements the above-mentioned character string cutting method when executed by a processor.

[0194] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above-mentioned string cutting method is implemented.

[0195] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0196] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0197] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0198] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0199] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0200] If the function is implemented in the form of 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 the present application can essentially or in other words, the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0201] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0202] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0203] It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0204] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application may be integrated into one unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of a software program module.

[0205] If the integrated unit / module is implemented in the form of hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. If not specifically stated, the processor may be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. If not specifically stated, the storage unit may be any appropriate magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory RRAM (Resistive Random Access Memory), a dynamic random access memory DRAM (Dynamic Random Access Memory), a static random access memory SRAM (Static Random-Access Memory), an enhanced dynamic random access memory EDRAM (Enhanced Dynamic Random Access Memory), a high-bandwidth memory HBM (High-Bandwidth Memory), a hybrid memory cube HMC (Hybrid Memory Cube), etc.

[0206] If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, 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, which is stored in a memory and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned memory includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0207] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0208] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0209] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A smoke test method, characterized in that: include: Obtain the image files corresponding to the test requirements and smoke test scripts of the software to be tested; Analyzing the resource demand information of the software to be tested for environmental resources according to the test requirements; Determine whether the monitored environmental resource information meets resource requirements; If the monitored environmental resource information meets the resource requirements, based on the image file and according to the association relationship between the functional modules corresponding to the software to be tested, the software to be tested is subjected to a combination test to obtain a test result. The combination test includes main process test, single module test and scenario test.

2. The method according to claim 1, characterized in that The step of determining whether the monitored environmental resource information meets the resource requirements includes: Determining resource matching parameters according to the resource demand information and the environmental resource information; Determining whether the resource matching parameter meets a preset resource matching parameter threshold; If the resource matching parameter satisfies the resource matching parameter threshold, then the environmental resource information satisfies the resource requirement.

3. The method according to claim 2, characterized in that The determining of resource matching parameters according to the resource demand information and the environmental resource information includes: Determine a resource indicator score and a resource indicator weight according to the resource demand information and the environmental resource information, wherein the resource indicator score represents the degree of difference between the required resource indicator in the resource demand information and the actual resource indicator in the environmental resource information; The resource indicator score and the resource indicator weight are weighted and summed to obtain the resource matching parameter.

4. The method according to claim 3, characterized in that After determining whether the resource matching parameter satisfies a preset resource matching parameter threshold, the method further includes: If the resource matching parameter does not meet the resource matching parameter threshold, determine the resource indicator that does not meet the resource requirement and the degree of influence of the resource indicator on the test result according to the resource matching parameter; First prompt information is generated according to the resource indicator and the impact degree.

5. The method according to any one of claims 1 to 4, characterized in that The method of performing a combined test on the software to be tested based on the image file and according to the association relationship between the functional modules corresponding to the software to be tested to obtain a test result includes: Based on the image file, according to the association relationship between the functional modules corresponding to the software to be tested, the container corresponding to the image file is started in the test environment to perform the main process test on the software to be tested; If the main process test passes, the single module test and the scenario test are performed on the functional modules respectively to obtain the test results.

6. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Based on the image file, a single-mode test is performed on the functional module to obtain the test result, wherein the single-mode test includes any one of the main process test, the single module test, and the scenario test.

7. The method according to any one of claims 1 to 4, characterized in that After performing a combined test on the software to be tested based on the image file and according to the association relationship between the functional modules corresponding to the software to be tested to obtain the test result, the method further includes: Determine test data according to the test results, wherein the test data includes test case execution rate, test case pass rate, defect density and defect severity; Calculating the risk level of the software to be tested based on the test data to determine risk assessment parameters; If the risk assessment parameter does not meet a preset risk assessment parameter threshold, a second prompt message is generated according to the test data.

8. A smoke test device, characterized in that: include: The acquisition module is used to obtain the test requirements of the software to be tested and the image file corresponding to the smoke test script; An analysis module, used to analyze the resource demand information of the software to be tested for environmental resources according to the test requirements; A determination module is used to determine whether the monitored environmental resource information meets the resource requirements; The test module is used to perform a combination test on the software to be tested based on the image file and the association relationship between the functional modules corresponding to the software to be tested if the monitored environmental resource information meets the resource requirements, and obtain the test results. The combination test includes main process test, single module test and scenario test.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

11. A computer program product, characterized in that The invention comprises a computer program, which is used to implement the method according to any one of claims 1 to 7 when being executed by a processor.