Test method and device for researching and testing sticking points in life cycle

Abstract

The invention relates to the technical field of computers, and discloses a test method and device for studying and testing sticking points in a life cycle. The method comprises the following steps: determining at least one sticking point corresponding to each stage according to each stage of a research and test life cycle; wherein each stage comprises a research and development stage, a test stage, a pre-sending stage, a gray stage and a formal stage which are executed in sequence; verifying the target sticking point corresponding to the target stage, and when the verification result of the target sticking point corresponding to the target stage indicates that the target sticking point corresponding to the target stage does not pass the verification, skipping the target sticking point corresponding to the target stage in response to the approval passing result of the user for the target sticking point corresponding to the target stage. The next sticking point of the target sticking point continues to be executed, the target sticking point is any one of the sticking points of the target stage, and the target sticking point is any one of the sticking points of the target stage.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and particularly to a test method and device for key points in the research and testing life cycle. Background Art

[0002] In the field of software research and development, ensuring software quality and performance has always been a core concern. With the continuous increase in software complexity and the growing diversification of user requirements, traditional test methods have gradually revealed their limitations. The traditional test process mainly relies on manual execution, which not only requires a large amount of manpower and time, but also the stability and accuracy of test results are often affected by the experience, skill level and subjective judgment of testers, resulting in inaccuracy.

[0003] Therefore, how to conduct efficient and accurate testing in the research and testing life cycle has become an urgent problem to be solved in the field of software research and development. Summary of the Invention

[0004] In view of this, the present invention provides a test method and device for key points in the research and testing life cycle.

[0005] In a first aspect, the present invention provides a test method for key points in the research and testing life cycle, the method comprising: determining at least one key point corresponding to each stage according to each stage of the research and testing life cycle; wherein each stage includes a research and development stage, a testing stage, a pre-release stage, a gray-scale stage and an official stage that are executed in sequence; verifying the target key point corresponding to the target stage, and in the case that the verification result of the target key point corresponding to the target stage indicates that the target key point corresponding to the target stage fails to pass the verification, in response to the approval result of the user for the target key point corresponding to the target stage, skipping the target key point corresponding to the target stage and continuing to execute the next key point of the target key point, wherein the target stage is any one of each stage, and the target key point is any one of the key points of the target stage.

[0006] The test method for key points in the research and testing life cycle provided in this embodiment divides the research and testing life cycle into a research and development stage, a testing stage, a pre-release stage, a gray-scale stage and an official stage, each stage has a clear key point, and automatically detects key points in each stage of the research and testing life cycle, reducing the dependence on manual execution and improving the efficiency and accuracy of testing. At the same time, in the case that the target key point fails to pass the verification, the user is allowed to approve and skip the key point and continue to execute the next key point, which can avoid blocking the entire test process due to problems with a certain key point.

[0007] In a possible implementation, the bottlenecks in the testing phase include: unit testing, static code scanning test, automated testing, incremental line coverage test, incremental interface coverage test, execution statement efficiency test, and test plan case pass rate test; the bottlenecks in the R & D phase include unit testing and static code scanning test; the bottlenecks in the pre-release phase include: automated testing, incremental line coverage test, incremental interface coverage test, and test plan case pass rate test; the bottlenecks in the gray-scale phase include: incremental line coverage test, incremental interface coverage test, and test plan case pass rate test; the bottlenecks in the official phase include: test plan case pass rate test.

[0008] The testing method for the bottlenecks in the R & D and testing life cycle provided in this embodiment, by setting different bottlenecks for each phase and conducting tests, can effectively improve the efficiency and accuracy of testing. Among them, through unit testing, it can be ensured that each code unit works as expected, improving the reliability and stability of the code. Conducting static code scanning in the testing phase helps to comprehensively check the code quality and improve the software security. Through automated testing, the testing efficiency can be improved, human errors can be reduced, and the consistency and repeatability of testing can be ensured. Through the incremental line coverage test, the degree to which the newly added code is tested can be measured to ensure that the newly added functions are fully tested. Through the incremental interface coverage test, the degree to which the newly added interfaces are tested can be measured to ensure the functionality and stability of the newly added interfaces. Through the execution statement efficiency test, the execution efficiency of the code can be evaluated to ensure that the software meets the user requirements in terms of performance. By measuring the pass rate of the test plan cases, the execution effect of the test plan can be ensured.

[0009] In a possible implementation, when the target bottleneck is unit testing, verifying the target bottleneck corresponding to the target phase includes: detecting whether the smallest testable unit in the software is running normally; where the smallest testable unit includes at least one of functions, methods, and classes.

[0010] The testing method for the bottlenecks in the R & D and testing life cycle provided in this embodiment, unit testing targets the smallest testable units in the software, such as functions, methods, or classes. This fine-grained testing method can accurately locate specific problems in the code, thus avoiding discovering problems only during later integration testing or system testing, which may lead to an increase in the cost of problem location and repair.

[0011] In a possible implementation, when the target bottleneck is static code scanning test, verifying the target bottleneck corresponding to the target phase includes: detecting whether the syntax of the code in the software follows the syntax rules of the programming language; detecting whether the code style in the software is consistent with the target style; detecting whether the code complies with the coding specifications.

[0012] The testing method for the key points in the research and testing life cycle provided in this embodiment. Static code scanning can automatically detect syntax errors in the code, ensuring that the code follows the syntax rules of the programming language. This helps to reduce compilation failures or runtime errors caused by syntax errors, and improve the reliability and stability of the code.

[0013] In addition, by detecting whether the code style is consistent with the target style, static code scanning can ensure that the code conforms to the specifications of the team or project in terms of format, naming, comments, etc. This helps to improve the readability and maintainability of the code, and reduce the communication cost of team collaboration.

[0014] Furthermore, detecting whether the code complies with the coding standards helps to discover potential logical errors, security vulnerabilities and other issues. By following the coding standards, the security, portability and scalability of the code can be improved.

[0015] In a possible implementation, when the target key point is automated testing, verifying the target key point corresponding to the target stage includes: detecting whether the automated test success rate of the single interface and the preset combined scenarios is not less than the first success rate threshold.

[0016] The testing method for the key points in the research and testing life cycle provided in this embodiment. Automated testing can quickly execute a large number of test cases through preset test scripts and tools, thus significantly shortening the testing cycle. Compared with manual testing, automated testing can discover and report problems faster, and significantly improve the testing efficiency.

[0017] In a possible implementation, when the target key point is the pass rate test of the test plan cases, verifying the target key point corresponding to the target stage includes: obtaining the number of test plan cases; determining the number of target test plan cases from multiple test plan cases; where the target test plan cases are used to indicate the test plan cases with a pass rate of not less than the pass rate threshold; detecting whether the ratio of the number of target test plan cases to the number of test plan cases is not less than the ratio threshold.

[0018] The testing method for the key points in the research and testing life cycle provided in this embodiment. By setting the pass rate threshold and the ratio threshold, the execution effect and quality of the test plan can be quantitatively evaluated. This helps to objectively and accurately measure the effectiveness of the testing work and avoid the deviation of subjective judgment.

[0019] Moreover, the pass rate test of the test plan cases requires the test plan to cover as many scenarios and function points as possible. By verifying the ratio of the number of target test plan cases to the total number of test plan cases, the comprehensiveness and in-depthness of the testing work can be ensured, and the risk of missing potential problems can be reduced.

[0020] Second aspect, the present invention provides a test device for researching and measuring bottlenecks in the research and measurement life cycle. The device includes: a determination module for determining at least one bottleneck corresponding to each stage according to each stage of the research and measurement life cycle; wherein each stage includes a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and an official stage that are executed in sequence; a verification and processing module for verifying the target bottleneck corresponding to the target stage, and in the case where the verification result of the target bottleneck corresponding to the target stage indicates that the target bottleneck corresponding to the target stage fails the verification, in response to the approval result of the user for the target bottleneck corresponding to the target stage, skipping the target bottleneck corresponding to the target stage and continuing to execute the next bottleneck of the target bottleneck, where the target stage is any one of each stage, and the target bottleneck is any one of the bottlenecks of the target stage.

[0021] Third aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the test method for researching and measuring bottlenecks in the research and measurement life cycle according to the first aspect or any corresponding embodiment thereof.

[0022] Fourth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored. The computer instructions are used to cause a computer to execute the test method for researching and measuring bottlenecks in the research and measurement life cycle according to the first aspect or any corresponding embodiment thereof.

[0023] Fifth aspect, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the test method for researching and measuring bottlenecks in the research and measurement life cycle according to the first aspect or any corresponding embodiment thereof. Description of the Drawings

[0024] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0025] Figure 1 is a flowchart of the test method for researching and measuring bottlenecks in the research and measurement life cycle according to an embodiment of the present invention;

[0026] Figure 2 is a schematic diagram of the test method for researching and measuring bottlenecks in the research and measurement life cycle according to an embodiment of the present invention;

[0027] Figure 3 is a structural block diagram of the test device for researching and measuring bottlenecks in the research and measurement life cycle according to an embodiment of the present invention;

[0028] Figure 4 It is a schematic diagram of the hardware structure of the computer device according to an embodiment of the present invention. Detailed implementation manners

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0030] In the related art, in the field of software R & D, ensuring software quality and performance has always been the core concern. With the continuous increase in software complexity and the increasing diversification of user requirements, traditional testing methods have gradually revealed their limitations. The traditional testing process mainly relies on manual execution, which not only requires a large amount of manpower and time, but also the stability and accuracy of the test results are often affected by the experience, skill level, and subjective judgment of the testers, resulting in inaccuracies.

[0031] Based on this, the present invention provides a testing method for key points in the research and testing life cycle. The research and testing life cycle is divided into a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage. Each stage has clear key points, and key points are automatically detected at each stage of the research and testing life cycle, reducing the dependence on manual execution and improving the efficiency and accuracy of testing. At the same time, when the target key point fails the verification, the user is allowed to approve and skip the key point and continue to execute the next key point, which can avoid blocking the entire testing process due to problems with a certain key point.

[0032] According to an embodiment of the present invention, an embodiment of a testing method for key points in the research and testing life cycle is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0033] In this embodiment, a testing method for key points in the research and testing life cycle is provided, which can be used in computer devices such as computers and servers. Figure 1 It is a schematic flowchart of the testing method for key points in the research and testing life cycle according to an embodiment of the present invention, as Figure 1 shown. The process includes the following steps:

[0034] Step S101: Determine at least one bottleneck point corresponding to each stage according to each stage of the research and testing life cycle. Each stage includes a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage that are executed in sequence.

[0035] The research and testing life cycle can represent the entire process of software or product from the start of research and development to formal launch and continuous monitoring, including a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage that are executed in sequence. A bottleneck point can represent a key checkpoint set in each stage of the research and testing life cycle to ensure that the work in this stage meets the predetermined quality standards or completes specific tasks. The bottleneck point can be functional testing, performance testing, security testing, code review, etc., which are not specifically limited here.

[0036] In specific implementation, according to the definition of the research and testing life cycle, the whole process is divided into a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage. For each stage, determine at least one key bottleneck point, which can be functional testing, performance testing, security testing, code review, document integrity check, etc. The number and type of bottleneck points in each stage are determined according to the actual situation and requirements of the project.

[0037] Step S102: Verify the target bottleneck point corresponding to the target stage, and in the case where the verification result of the target bottleneck point corresponding to the target stage indicates that the target bottleneck point corresponding to the target stage fails the verification, in response to the approval result of the user for the target bottleneck point corresponding to the target stage, skip the target bottleneck point corresponding to the target stage and continue to execute the next bottleneck point after the target bottleneck point, where the target stage is any one of each stage, and the target bottleneck point is any one of the bottleneck points of the target stage.

[0038] The target stage is any one of each stage, and the target bottleneck point is any one of the bottleneck points of the target stage. The approval result can represent the formal approval given when the user decides to continue to promote the project despite the fact that the target bottleneck point fails the verification due to certain reasons (such as urgent release requirements, known problems but with controllable risks, etc.).

[0039] In specific implementation, select the current target stage and target bottleneck point for verification. If the target bottleneck point passes the verification, continue to execute the next bottleneck point or enter the next stage. If the target bottleneck point fails the verification, the system prompts the user that the bottleneck point fails and asks whether to approve. The user decides whether to approve the failed bottleneck point according to the actual situation and requirements of the project. If the user decides to approve, skip the failed bottleneck point and continue to execute the next bottleneck point or enter the next stage. If the user decides not to approve, it may be necessary to roll back to the previous stage or re-execute the bottleneck point.

[0040] As an example, a software project is in the testing phase of the research and testing lifecycle, and one of the bottlenecks is "functional testing". During the testing phase, "functional testing" is identified as a key bottleneck in this phase. When the "functional testing" bottleneck is executed, a defect is found in a certain functional module. The system prompts the user that this bottleneck fails the verification. The user evaluates the severity of the defect and the repair cost and decides that although there are defects, they do not affect the overall release plan, so the user decides to approve and pass this bottleneck. The system skips the "functional testing" bottleneck and continues to execute the next bottleneck, such as "performance testing".

[0041] The testing method for the bottlenecks in the research and testing lifecycle provided by this embodiment divides the research and testing lifecycle into a research and development phase, a testing phase, a pre-release phase, a gray-scale phase, and a formal phase. Each phase has clear bottlenecks, and the bottlenecks are automatically detected in each phase of the research and testing lifecycle, reducing the dependence on manual execution and improving the efficiency and accuracy of testing. At the same time, when the target bottleneck fails the verification, the user is allowed to approve and pass this bottleneck and continue to execute the next bottleneck, which can avoid blocking the entire testing process due to problems with a certain bottleneck.

[0042] In a possible implementation, the bottlenecks in the testing phase include: unit testing, static code scanning test, automated testing, incremental line coverage test, incremental interface coverage test, execution statement efficiency test, test plan case pass rate test; the bottlenecks in the research and development phase include unit testing, static code scanning test; the bottlenecks in the pre-release phase include: automated testing, incremental line coverage test, incremental interface coverage test, test plan case pass rate test; the bottlenecks in the gray-scale phase include: incremental line coverage test, incremental interface coverage test, test plan case pass rate test; the bottlenecks in the formal phase include: test plan case pass rate test.

[0043] Unit testing: During the development process, whenever a function or module is completed, developers write corresponding unit tests to ensure its correct functionality. Static code scanning test: Before the code is submitted, a scanning tool is used to perform static analysis on the code to discover potential code quality problems. Automated testing: During the testing phase, automated test scripts are written and executed to comprehensively test the software. Incremental line coverage test: After each code update, it is checked whether the newly added or modified code lines are covered by tests. Incremental interface coverage test: After each interface update, it is checked whether the newly added or modified interfaces are covered by tests. Execution statement efficiency test: During the performance testing phase, performance testing is performed on the key execution statements in the software. Test plan case pass rate test: At the end of the testing phase, the pass rate of test cases is counted to evaluate the execution effect of the test plan.

[0044] Among them, R&D stage: unit testing and static code scanning testing: During the R&D process, developers will perform unit testing and static code scanning to ensure the quality of the code and the correctness of its functions.

[0045] Pre-release stage: Before pre-release, automated testing, incremental line coverage testing, incremental interface coverage testing, and test plan case pass rate testing will be performed to ensure that the software meets the predetermined quality and stability requirements before the official release.

[0046] Grayscale stage: During the grayscale release stage, incremental line coverage testing, incremental interface coverage testing, and test plan use case pass rate testing will be performed to monitor the performance of the software in the real environment and to promptly identify and fix potential problems.

[0047] Formal stage: After the official release, a test plan use case pass rate test will be conducted to ensure that the software maintains high quality and stability after the official release.

[0048] As an example, during the testing phase, 100 test cases were executed using the Selenium automated testing tool at an automated testing checkpoint. Of these, 95 passed and 5 failed. Based on the test results, the tester analyzed and fixed the failed cases.

[0049] For example, during the R&D phase, during a static code scanning test, the scanning tool discovered a memory leak in the code. Based on the scan results, the developer fixed the code and re-ran the unit tests.

[0050] Please refer to Figure 2 , Figure 2 2 is a schematic diagram of a testing method for detecting lifecycle checkpoints provided according to an embodiment of the present invention.

[0051] Unit testing and static scanning blocker items are controlled during testnet entry and exit. Automated test pass rates are controlled for test and staging environments. Incremental code line coverage and incremental interface coverage are controlled for test, staging, and grayscale environments, respectively. Slow SQL detection primarily targets server-side applications and controls testnet exit. Test plan checkpoints verify the pass rates of testnet, staging, grayscale, and production environments based on the execution of use cases in each environment associated with the requirements.

[0052] The test method for the key points in the research and testing life cycle provided in this embodiment, by setting different key points for each stage and conducting tests, can effectively improve the efficiency and accuracy of testing. Among them, through unit testing, it can be ensured that each code unit works as expected, improving the reliability and stability of the code. Conducting static code scanning during the testing stage helps to comprehensively check the code quality and improve the security of the software. Through automated testing, the testing efficiency can be improved, human errors can be reduced, and the consistency and repeatability of testing can be ensured. Through incremental line coverage testing, the degree to which the newly added code is tested can be measured, ensuring that the newly added functions are fully tested. Through incremental interface coverage testing, the degree to which the newly added interfaces are tested can be measured, ensuring the functionality and stability of the newly added interfaces. Through execution statement efficiency testing, the execution efficiency of the code can be evaluated, ensuring that the software meets the user requirements in terms of performance. Measuring the passing rate of test plan test cases can ensure the execution effect of the test plan.

[0053] In a possible implementation manner, when the target key point is unit testing, verifying the target key point corresponding to the target stage in step S102 includes: detecting whether the smallest testable unit in the software is running normally; where the smallest testable unit includes at least one of functions, methods, and classes.

[0054] Unit testing can be used to verify whether the behavior of the smallest testable units (such as functions, methods, classes, etc.) in the software meets the expectations. The smallest testable units can represent the smallest code units independently tested in software engineering. Specifically, they can include functions, methods, or classes, which encapsulate specific functions or behaviors.

[0055] Specifically, when the target key point is unit testing, the specific content of verifying the target key point corresponding to the target stage in step S102 includes: setting up the necessary test environment, including configuring test data, building a test framework, etc., to ensure that unit testing can be carried out in an independent and controllable environment. For each smallest testable unit (such as functions, methods, classes, etc.), write corresponding test cases. The test cases should cover various possible inputs and expected outputs of the unit to ensure the comprehensiveness of the test. Use a test framework (such as JUnit, pytest, etc.) to execute the written test cases. The test framework will automatically run the test cases and collect the test results. Analyze the test results to check whether each test case passes. If a test case fails, the reason for the failure needs to be located and repaired. Record the test results and generate a test report. The test report should include the passing rate of the test cases, the detailed information of the failed test cases, and repair suggestions, etc.

[0056] For example: The software project is in the unit testing phase, and the goal is to conduct unit tests on a class named Calculator. Set up a test framework (such as JUnit) and configure the necessary test data. For each method in the Calculator class (such as addition, subtraction, multiplication, division, etc.), write corresponding test cases. For example, for the addition method, a test case can be written to verify whether 2 + 3 equals 5. Use JUnit to execute the written test cases. JUnit will automatically run these test cases and collect the test results. Analyze the test results and find that the test case for the addition method passes, but the division method fails when the divisor is 0. Locate the cause of the failure, which is that the exception situation where the divisor is 0 is not handled. Record the test results and generate a test report. The test report indicates that there is a problem with the division method and suggests adding exception handling logic to fix the problem.

[0057] The test method for the research and testing life cycle bottleneck points provided in this embodiment. Unit testing targets the smallest testable units in the software, such as functions, methods, or classes. This fine-grained testing method can accurately locate specific problems in the code, thus avoiding discovering problems only during later integration testing or system testing, which would increase the cost of problem location and repair.

[0058] In a possible implementation, when the target bottleneck point is static code scanning testing, the verification of the target bottleneck point corresponding to the target phase in step S102 includes:

[0059] Step a1, detect whether the syntax of the code in the software follows the syntax rules of the programming language.

[0060] Step a2, detect whether the code style in the software is consistent with the target style.

[0061] Step a3, detect whether the code complies with the coding specifications.

[0062] The syntax rules of the programming language are used to represent how to write code correctly. For example, Java has strict type checking and class definition rules, while Python pays more attention to indentation and dynamic typing. The code style can represent the specific format and conventions adopted when writing code, including indentation, spaces, comments, naming conventions, etc. The coding specifications can represent the guidelines and principles for writing high-quality code, which can specifically cover multiple aspects such as code structure, naming rules, comment requirements, and error handling.

[0063] During specific implementation, check whether the syntax of the code in the detection software follows the syntax rules of the programming language. Static code analysis tools (such as ESLint, Checkstyle, SonarQube, etc.) can be used to perform syntax checks on the source code. The analysis tool will report any syntax errors or warnings, which need to be fixed or confirmed. Check whether the code style in the detection software is consistent with the target style. The static code analysis tool can be configured to match the code style requirements of the project (such as indentation, spaces, naming conventions, etc.). Run the analysis tool to check whether the code style is consistent with the target style and report any inconsistencies. The static code analysis tool can be configured according to the coding specifications of the project (such as the internal coding guidelines of the team, industry best practices, etc.). Run the analysis tool to check whether the code complies with the coding specifications and report any issues that do not meet the specifications.

[0064] For the test method of the research and test lifecycle bottleneck point provided in this embodiment, static code scanning can automatically detect syntax errors in the code to ensure that the code follows the syntax rules of the programming language. This helps reduce compilation failures or runtime errors caused by syntax errors and improve the reliability and stability of the code.

[0065] In addition, by detecting whether the code style is consistent with the target style, static code scanning can ensure that the code complies with the specifications of the team or project in terms of format, naming, comments, etc. This helps improve the readability and maintainability of the code and reduces the communication cost of team collaboration.

[0066] In addition, detecting whether the code complies with the coding specifications helps discover potential logical errors, security vulnerabilities and other issues. By following the coding specifications, the security, portability and scalability of the code can be improved.

[0067] In a possible implementation, when the target bottleneck point is automated testing, the verification of the target bottleneck point corresponding to the target stage in step S102 above includes: detecting whether the automation test success rates of single interfaces and preset combined scenarios are not less than the first success rate threshold.

[0068] Automated testing of single interfaces can represent automated test scripts for testing and validating the functions of individual interfaces. Preset combined scenarios can be test scenarios in automated testing that are predefined for the integration and interaction of multiple interfaces according to real business requirements and user scenarios. These scenarios simulate various situations that users may encounter in actual use.

[0069] In specific implementation, for each interface in the software, automated test scripts are written and executed to verify the function, performance, and stability of the interface. The success rate of each interface test is recorded. According to the preset combined scenarios, automated test scripts are written and executed to simulate various situations that users may encounter in actual use, and verify whether the integration and interaction of multiple interfaces meet the expectations. The success rate of each scenario test is recorded. The automated test success rates of single interfaces and preset combined scenarios are compared with the set first success rate threshold. If the actual success rate is not lower than the threshold, the test is considered passed; otherwise, the reasons for the test failure need to be further checked and analyzed. A detailed test report is generated based on the test results, including the test success rate, detailed information of failed test cases, test environment configuration, etc., for subsequent analysis and improvement.

[0070] For the test method of the research and test life cycle bottleneck provided in this embodiment, through the preset test scripts and tools, the automated test can quickly execute a large number of test cases, thus significantly shortening the test cycle. Compared with manual testing, the automated test can discover and report problems faster, significantly improving the test efficiency.

[0071] In a possible implementation manner, when the target bottleneck is the test plan case pass rate test, the verification of the target bottleneck corresponding to the target stage in step S102 includes:

[0072] Step b1, obtain the number of test plan cases.

[0073] Step b2, determine the number of target test plan cases from multiple test plan cases; where the target test plan cases are used to indicate the test plan cases with a test plan case pass rate not less than the pass rate threshold.

[0074] Step b3, detect whether the ratio of the number of target test plan cases to the number of test plan cases is not less than the ratio threshold.

[0075] Test plan cases can represent the test cases defined in the test plan for verifying aspects such as software function, performance, and security. Each test case contains information such as test steps, expected results, and actual results. The pass rate threshold can represent a pass rate standard set in the test plan case pass rate test. If the actual pass rate is not lower than this threshold, the test case is considered passed; otherwise, the reasons for the test failure need to be further checked and analyzed.

[0076] When implementing specifically, count the total number of all test cases in the current test plan. Specifically, this can be achieved through a test management tool (such as TestRail, Jira, etc.) or database query. Traverse all test plan cases and filter out the test cases that meet the requirements according to the passing rate threshold. These test cases that meet the requirements are the target test plan cases. The target test plan cases can be automatically filtered by writing a script or using the functions of the test management tool. Calculate the ratio of the number of target test plan cases to the total number of test plan cases, and compare this ratio with the set ratio threshold. If the ratio is not less than the ratio threshold, it is considered that the overall passing rate of the test plan cases has reached the expected requirements; otherwise, it is necessary to further check and analyze the reasons for test failures and take corresponding improvement measures.

[0077] The test method for the research and testing life cycle checkpoint provided in this embodiment can quantitatively evaluate the execution effect and quality of the test plan by setting the passing rate threshold and the ratio threshold. This helps to objectively and accurately measure the effectiveness of the test work and avoid the deviation of subjective judgment.

[0078] Moreover, the passing rate test of the test plan cases requires that the test plan covers as many scenarios and function points as possible. By verifying the ratio of the number of target test plan cases to the total number of test plan cases, the comprehensiveness and in-depthness of the test work can be ensured, and the risk of missing potential problems can be reduced.

[0079] In this embodiment, a test device for the research and testing life cycle checkpoint is also provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0080] This embodiment provides a test device for the research and testing life cycle checkpoint, as Figure 3 shown, including: a determination module 301, configured to determine at least one checkpoint corresponding to each stage according to each stage of the research and testing life cycle; wherein each stage includes a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage that are sequentially executed; a verification processing module 302, configured to verify the target checkpoint corresponding to the target stage, and in the case where the verification result of the target checkpoint corresponding to the target stage indicates that the target checkpoint corresponding to the target stage fails the verification, in response to the approval result of the user for the target checkpoint corresponding to the target stage, skip the target checkpoint corresponding to the target stage and continue to execute the next checkpoint of the target checkpoint, where the target stage is any one of each stage, and the target checkpoint is any one of the checkpoints of the target stage.

[0081] In some possible implementation manners, the bottlenecks in the testing phase include: unit testing, static code scanning test, automated testing, incremental line coverage test, incremental interface coverage test, execution statement efficiency test, and test plan case passing rate test; the bottlenecks in the R & D phase include unit testing and static code scanning test; the bottlenecks in the pre-release phase include: automated testing, incremental line coverage test, incremental interface coverage test, and test plan case passing rate test; the bottlenecks in the gray-scale phase include: incremental line coverage test, incremental interface coverage test, and test plan case passing rate test; the bottleneck in the official phase is the test plan case passing rate test.

[0082] In some possible implementation manners, when the target bottleneck is unit testing, the above-mentioned verification processing module 302 is used to detect whether the smallest testable unit in the software is operating normally; among them, the smallest testable unit includes at least one of functions, methods, and classes.

[0083] In some possible implementation manners, when the target bottleneck is static code scanning test, the above-mentioned verification processing module 302 is used to detect whether the syntax of the code in the software follows the syntax rules of the programming language; detect whether the code style in the software is consistent with the target style; detect whether the code complies with the coding specifications.

[0084] In some possible implementation manners, when the target bottleneck is automated testing, the above-mentioned verification processing module 302 is used to detect whether the success rate of the automated testing of single interfaces and preset combined scenarios is not less than the first success rate threshold.

[0085] In some possible implementation manners, when the target bottleneck is the test plan case passing rate test, the above-mentioned verification processing module 302 is used to obtain the number of test plan cases; determine the number of target test plan cases from multiple test plan cases; among them, the target test plan cases are used to indicate the test plan cases with a passing rate of not less than the passing rate threshold; detect whether the ratio of the number of target test plan cases to the number of test plan cases is not less than the ratio threshold.

[0086] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding embodiments above, and will not be repeated here.

[0087] The testing device for the bottlenecks in the R & D and testing life cycle in this embodiment is presented in the form of functional units. Here, the functional units refer to ASIC (Application Specific Integrated Circuit) circuits, processors and memories that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0088] An embodiment of the present invention further provides a computer device having the above-mentioned Figure 3 test device for the key points of the research and testing life cycle shown.

[0089] Please refer to Figure 4 , Figure 4 which is a schematic structural diagram of a computer device provided by an alternative embodiment of the present invention. As Figure 4 shown, the computer device includes: one or more processors 10, a memory 20, and an interface for connecting each component, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 4 In

[0090] FIG., a single processor 10 is taken as an example.

[0091] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above-mentioned hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above-mentioned programmable logic device can be a complex programmable logic device, a field programmable gate array, a general array logic, or any combination thereof.

[0091] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0092] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device, etc. In addition, the memory 20 can include a high-speed random access memory and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0093] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, a hard disk, or a solid state drive; the memory 20 may further include a combination of the above types of memory.

[0094] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0095] An embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented by downloading through a network the original computer code stored in a remote storage medium or a non-transitory machine-readable storage medium and to be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid state drive, etc.; further, the storage medium may further include a combination of the above types of memory. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiment is implemented.

[0096] A part of the present invention can be applied as a computer program product, such as computer program instructions, which when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should be able to understand that the forms of existence of computer program instructions in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways for computer program instructions to be executed by a computer include, but are not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible by the computer.

[0097] Although the embodiments of the present invention are described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A test method for researching and measuring the key points in the life cycle, characterized in that, The method includes: Determining at least one bottleneck point corresponding to each stage according to each stage of the research and measurement life cycle; wherein, each stage includes a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage that are executed in sequence; Verifying the target bottleneck point corresponding to the target stage, and when the verification result of the target bottleneck point corresponding to the target stage indicates that the target bottleneck point corresponding to the target stage fails the verification, in response to the approval result of the user for the target bottleneck point corresponding to the target stage, skipping the target bottleneck point corresponding to the target stage and continuing to execute the next bottleneck point of the target bottleneck point, wherein, any one of each stage of the target stage, and the target bottleneck point is any one of the bottleneck points of the target stage.

2. The test method for the research and measurement life cycle key point according to claim 1, wherein, The bottleneck points of the testing stage include: unit testing, static code scanning test, automated testing, incremental line coverage test, incremental interface coverage test, execution statement efficiency test, test plan case pass rate test; the bottleneck points of the research and development stage include unit testing, static code scanning test; the bottleneck points of the pre-release stage include: automated testing, incremental line coverage test, incremental interface coverage test, test plan case pass rate test; the bottleneck points of the gray-scale stage include: incremental line coverage test, incremental interface coverage test, test plan case pass rate test; the bottleneck points of the formal stage include: test plan case pass rate test.

3. The test method for the key points in the research and measurement life cycle according to claim 2, wherein When the target bottleneck point is unit testing, verifying the target bottleneck point corresponding to the target stage includes: Detecting whether the smallest testable unit in the software is running normally; wherein, the smallest testable unit includes at least one of functions, methods, and classes.

4. The test method for the research and measurement life cycle bottleneck according to claim 2, wherein, When the target bottleneck point is the static code scanning test, verifying the target bottleneck point corresponding to the target stage includes: Detecting whether the syntax of the code in the software follows the syntax rules of the programming language; Detecting whether the code style in the software is consistent with the target style; Detecting whether the code complies with the coding specifications.

5. The testing method for the research and measurement life cycle key point according to claim 2, wherein When the target bottleneck point is automated testing, verifying the target bottleneck point corresponding to the target stage includes: Detecting whether the automated test success rate of the single interface and the preset combined scenario is not less than the first success rate threshold.

6. The test method for the research and measurement life cycle bottleneck point according to claim 2, wherein When the target bottleneck point is the test plan case pass rate test, verifying the target bottleneck point corresponding to the target stage includes: Obtaining the number of test plan cases; Determining the number of target test plan cases from multiple test plan cases; wherein, the target test plan cases are used to indicate the test plan cases with a test plan case pass rate not less than the pass rate threshold; Detecting whether the ratio of the number of target test plan cases to the number of test plan cases is not less than the ratio threshold.

7. A test device for researching and measuring the key points in the lifecycle, characterized in that, The device includes: A determination module, configured to determine at least one bottleneck point corresponding to each stage according to each stage of the research and measurement life cycle; wherein, each stage includes a research and development stage, a testing stage, a pre-release stage, a gray-scale stage, and a formal stage that are executed in sequence; A verification processing module, which is used to verify the target checkpoint corresponding to the target stage, and in the case that the verification result of the target checkpoint corresponding to the target stage indicates that the target checkpoint corresponding to the target stage fails the verification, in response to the approval result of the user for the target checkpoint corresponding to the target stage, skip the target checkpoint corresponding to the target stage, and continue to execute the next checkpoint after the target checkpoint, where the target stage is any one of each stage, and the target checkpoint is any one of the checkpoints of the target stage.

8. A computer device, characterized in that, It includes: A memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the test method of the research and testing life cycle checkpoint according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the test method of the research and testing life cycle checkpoint according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions, and the computer instructions are used to cause a computer to execute the test method of the research and testing life cycle checkpoint according to any one of claims 1 to 6.

Images