Version test management and control method and system based on test submission process

Abstract

The invention provides a version test management and control method and system based on a test submitting process. The method comprises the following steps: standardizing a test process into seven stages: test demand receiving, test plan generation, version test submitting application, test plan execution, version promotion application, version promotion approval and test plan closed loop. A version ID is automatically verified through a deployment assembly line, deployment information is synchronized, and strict matching between a test environment and a research and development version is achieved; version data are automatically associated in the execution process, and test traceability is ensured; and promotion auditing is carried out based on the deployment records passing verification, and version pollution is completely eradicated. According to the method, a complete closed loop from demand to online is formed by constructing the version test management and control flow, so that the problems of inaccurate version management and control and inconsistent test deployment are effectively solved, and the software test quality and the online safety are remarkably improved.

Description

Technical Field

[0001] This application relates to the fields of project management and test management technology, specifically to a version test control method and system based on the test submission process. Background Technology

[0002] Software version test management is a process of managing testing activities to ensure that software applications are tested to a high standard. This approach includes organizing, controlling, and ensuring the traceability and visibility of the testing process to deliver high-quality software applications.

[0003] A test plan can be defined as a document describing the scope, methods, resources, and schedule of testing activities. Without a complete test plan, a project may fail. Test plans are particularly important in the development of large software systems. In software testing, a test plan provides detailed testing information about the upcoming testing work, including testing strategies, testing objectives, exit / pause criteria, resource planning, and test deliverables. The final test deliverable is the most crucial part of the entire testing domain. After testing is completed, the development team typically confirms the version package to be promoted, usually using the last deployed package from the test environment as the deployment package. An offline version comparison is used to confirm and verify the version. However, the verification process is conducted in separate workflows for the testing and development teams. On the one hand, because the testing team's control over version deployment is not specific enough, situations often arise after testing is completed, where additional deployments are needed for other requirements due to the lack of independence in the test environment, leading to the risk of version contamination. On the other hand, when the development team confirms the version, the testing team often cannot verify whether the compared version is the core version being tested.

[0004] Therefore, it often happens that the final version is not thoroughly tested or adequately regressed, while intermediate versions are not missed in testing but the final version is, thus causing production problems. In summary, the problem is that the version management and test management processes are not linked, and there is a gray area that neither the development team nor the testing team pays attention to. Summary of the Invention

[0005] This application provides a version test management method and system based on the test submission process, which can solve the technical problems in the prior art that lead to inaccurate version management and inconsistency between test and deployment versions due to the separation of testing and development processes.

[0006] Firstly, this application provides a version testing management method based on the testing process, including the following steps: The standardized software version testing process consists of 7 testing phases, including test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure. During the test requirement reception phase, test requirement data for the software version is received. During the test plan generation phase, the requirements are automatically broken down according to the associated systems to generate corresponding test plans. During the version testing application stage, the deployment pipeline automatically verifies the legality of the version ID and synchronizes key information such as the deployment package address, code branch, and timestamp to the associated test plan in real time, generating a version testing report that includes the testing results and the latest deployment records; Based on the version baseline provided in the version test report, the test plan execution phase automatically associates the test case execution and defect submission with the complete deployment data of the current version, and obtains the final deployment record after the test verification. During the version upgrade application phase, an upgrade application is initiated based on the final deployment record that has passed testing; During the version upgrade approval stage, the approved versions undergo version review, and the upgraded versions that pass the review generate online access materials to complete the testing loop.

[0007] Furthermore, the test requirement data includes requirement name, requirement number, list of related systems, total workload of requirement, list of workload of subsystems of requirement, person in charge of requirement, and requirement status.

[0008] Furthermore, the version testing application stage also includes: Generate a unique version identifier through the version management module; Verify the validity of the version identifier when the deployment pipeline is executed; After deployment is complete, the deployment package metadata will be automatically sent back to the test management platform.

[0009] Furthermore, based on the version benchmark provided in the version testing report, the system automatically associates test case execution and defect submissions with the complete deployment data of the current version during the test plan execution phase. After verification through testing, the final deployment record is obtained, specifically including the following steps: Review the smoke test records for test plans with associated version identifiers and obtain the smoke test records; Based on the smoke test logs, different case execution and defect management strategies are implemented to obtain the final deployment logs after the tests pass.

[0010] Furthermore, based on the smoke test records, different case execution and defect management strategies are implemented to obtain the final deployment record after the test passes. This specifically includes the following steps: If the test submission is approved, the test case execution and defect management module will be enabled, the test plan status will be changed to "in testing", test case defect tests will be executed, and the final deployment record of the test will be obtained. If the test submission fails the review, keep the case execution and defect module closed. You will need to readjust the version or fix the problem before submitting it for review again.

[0011] Furthermore, if the test submission is approved, the test case execution and defect management module is opened, the test plan status is changed to "in testing," test case defect testing is executed, and the final deployment record of the test passing is obtained. This specifically includes the following steps: After the test submission is approved, the currently active deployment version information will be automatically captured when the test cases are executed; When a defect is submitted, a mapping relationship between the defect and the deployment version is automatically established. Establish a two-way traceability link between test results and deployment records to obtain the final deployment record of the test passed.

[0012] Furthermore, a two-way traceability link is established between test results and deployment records to obtain the final deployment record when the test passes, specifically including: Automatically capture complete metadata of the currently active deployment version when executing test cases, including code branch, last merge time, and deployment package hash. When a defect is submitted, the mapping relationship between the defect and the deployment version is automatically associated, and a snapshot of the deployment environment when the defect is discovered is recorded. Construct a three-dimensional correlation matrix of version, test, and defect to obtain the final deployment record after the test passed; Furthermore, the version upgrade application stage also includes: An upgrade application should be initiated based on the last successful deployment record. The application materials for the upgrade application must include the deployment package hash value, test coverage report, and defect fix list.

[0013] Furthermore, the version upgrade stage implements a multi-level verification mechanism, including: Deployment package integrity verification: Compare the hash value of the upgrade package with the hash value of the last deployment package in the test environment; Test coverage verification: Verify whether the test case execution coverage reaches the preset threshold; Defect closed-loop verification: Confirm that all critical level defects have been repaired and verified; Version consistency check: Ensure that the code of the upgrade package is completely consistent with the branch commit records of the tested version.

[0014] Secondly, this application provides a system applied to the version test management method based on the test submission process described above, comprising: The testing phase is divided into modules to standardize the software version testing process into 7 testing phases, including test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure. The test plan generation module is communicatively connected to the test phase splitting module. It is used to receive test requirement data of the software version during the test requirement receiving phase, and to automatically split the requirements according to the associated system to generate the corresponding test plan during the test plan generation phase. The testing module is connected to the test plan generation module and is used to automatically verify the legality of the version ID through the deployment pipeline and synchronize key information such as deployment package address, code branch and timestamp to the associated test plan in real time during the version testing application stage, and generate a version testing report containing the testing results and the latest deployment record. The testing module, which communicates with the testing module, is used to automatically associate the test case execution and defect submission with the complete deployment data of the current version during the test plan execution phase, based on the version baseline provided by the version testing report, and obtain the final deployment record after passing the test verification. The upgrade application module communicates with the test module and is used to initiate an upgrade application based on the final deployment record of the test passing during the version upgrade application stage. The upgrade review and launch access module communicates with the upgrade application module and is used to review the approved version during the version upgrade approval stage, generate launch access materials for the upgraded version that has passed the review, and complete the test closed loop.

[0015] The beneficial effects of the technical solutions provided in this application include at least the following: By establishing an automated linkage mechanism between version and testing processes, precise control over the entire process from requirement reception to version deployment is achieved. During the testing phase, version legitimacy is automatically verified and deployment information is synchronized in real time, ensuring strict consistency between the testing environment and the development version. During test execution, version deployment data is automatically bound, achieving traceability of the testing process. In the upgrade phase, audits are conducted based on verified deployment records, eliminating the risk of version contamination. This method breaks down data barriers between development and testing, forming a complete closed loop of version-deployment-testing-deployment. It effectively solves the problems of inaccurate version control and inconsistencies between test and deployment versions in traditional models, significantly improving the testing quality and deployment security of software versions. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the version testing control method based on the testing process in this application. Figure 2 This is a functional module block diagram of the version testing management system based on the testing process in this application. Detailed Implementation

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

[0018] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0019] In the description of the embodiments in this application, terms such as "exemplary," "for example," or "for instance" are used as examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0020] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0021] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0023] Firstly, such as Figure 1 As shown, this application provides a version testing management method based on the testing process, including the following steps: Step S1: The standardized software version testing process consists of 7 testing phases, including test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure. Step S2: In the test requirement reception phase, receive the test requirement data for the software version; in the test plan generation phase, automatically decompose the requirements according to the associated systems to generate the corresponding test plan. Step S3: During the version testing application stage, the deployment pipeline automatically verifies the legality of the version ID and synchronizes key information such as the deployment package address, code branch, and timestamp to the associated test plan in real time, generating a version testing report that includes the testing results and the latest deployment records, thereby achieving accurate matching between the development version and the test environment and an automated testing process; Step S4: Based on the version baseline provided in the version test report, automatically associate the test case execution and defect submission with the complete deployment data of the current version during the test plan execution phase, and obtain the final deployment record after verification through testing; Step S5: During the version upgrade application phase, initiate an upgrade application based on the final deployment record that has passed testing; Step S6: During the version upgrade approval stage, the approved versions undergo version review, and the upgrade versions that pass the review generate the online access materials to complete the testing loop.

[0024] The version testing control method based on the testing process provided in this application replaces the manual testing process of R&D, connects version data with the test process data flow, and monitors the deployment version flow throughout the process; during test execution, deployment version data is automatically recorded when executing cases and registering defects, supporting process data traceability; after the test is completed, the original deployment records are directly used in the version upgrade process without manual data intervention, supporting the original state of the online version, and the original deployment records, test records, and approval records of the upgrade package can be accessed, ensuring high security and high reliability of version content.

[0025] In one embodiment, the seven testing phases in step S1 are specifically as follows: Test Phase 1: Test Requirement Reception. The upstream OA system or requirement management system provides the test requirement data source, and the test management platform synchronously receives the requirement data. Phase 2 of testing: Test plan generation. Based on the system data of the requirements received in Stage 1, a test plan is generated for each system, and a test manager is automatically assigned according to the system. Test Phase 3: Version Submission for Testing. The version administrator initiates a version submission, associates one or more test plans, generates a version ID, and during deployment, the pipeline verifies the version ID and synchronizes the deployment results to the version submission. If there are deployment results under the version, the status of the corresponding test plan is changed from not started to submission for testing. Test Phase 4: Test Plan Execution. The test manager of the test plan in Stage 2 processes the submitted test plans, completes the case execution and defect submission. During execution, the execution record will obtain the deployment information of the current version in real time to achieve the target, and supports execution version backtracking. Test Phase 5: Version Upgrade Application. After Stage 4 is completed, the test manager will notify the version administrator to apply for a version upgrade, submitting the production package address link and deployment information to be upgraded for a second review. Test Phase 6: Version Upgrade Approval and Deployment Window. On the deployment window day, the version manager will organize a meeting to confirm the versions submitted for Stage 5 and conduct an online review of the confirmed versions. Once approved, the production package address link of the version will be pushed to production in real time for operations and maintenance to download. After the meeting, a version confirmation report will be issued and distributed to each project team for deployment approval. Phase 7 of the test: The test plan is closed. After the requirement goes live, the test plan is synchronized to the test management platform and the test manager closes the test plan, thus completing the closed loop of the entire test process.

[0026] This application standardizes the software version testing process into seven stages (test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure), constructing a complete closed-loop management process from requirements to deployment. This standardized process clarifies and normalizes the division of testing stages, ensuring that each testing step has clear input and output standards. This effectively solves the version control chaos caused by ambiguous stage divisions in traditional testing processes, significantly improving the controllability and traceability of the testing process.

[0027] In one embodiment, in step S2, the test management platform provides a data synchronization mechanism between the test management platform and the requirement management platform to build test requirement data. The two platforms communicate and interact through a backend interface. The test management platform provides a requirement synchronization interface, which mainly receives the following data: requirement name, requirement number, list of related systems for the requirement, total workload of the requirement, list of workload of subsystems for the requirement, person in charge of the requirement, and requirement status.

[0028] In one embodiment, step S2 is specifically implemented as follows: Step S21: After receiving the test requirement data, the test platform splits the data by system. If there are N data items in the list of systems associated with the requirement, they will be split into N test plans. Step S22: Based on the system-test manager association table in the test platform, assign test managers to the N test plans in sequence according to the system name.

[0029] In this embodiment, during the test requirement reception phase, test requirement data (including key information such as requirement name, number, and a list of associated systems) is received in a structured manner. During the test plan generation phase, requirements are automatically decomposed based on the associated systems to generate corresponding test plans, achieving intelligent conversion from requirements to test plans. This technical solution effectively solves the problems of low efficiency and error-proneness in manual requirement decomposition in the traditional model. Through automated requirement allocation and test plan generation, it significantly improves the accuracy and efficiency of the test preparation phase, while ensuring a high degree of consistency between the test plan and the original requirements, laying a standardized foundation for subsequent test execution.

[0030] In one embodiment, the version testing application stage in step S3 further includes: Generate a unique version identifier through the version management module; Verify the validity of the version identifier when the deployment pipeline is executed; After deployment is complete, the deployment package metadata will be automatically sent back to the test management platform.

[0031] After the workload approval process is completed on the requirement management platform, the above-mentioned requirement synchronization interface is called to push the data to the test management platform; if the requirement approval process is suspended, the requirement synchronization interface is also used to complete the status synchronization.

[0032] In one embodiment, step S3 specifically includes the following steps: Step 31: Build a version management module on the testing platform, responsible for functions such as version submission for testing, version deployment, version upgrade application, and version upgrade review; the testing management platform provides: This test submission interface provides the following elements: test plan list, version number, system, applicant, creation time. After successful interface call, it returns the version ID. The version verification interface provides the following elements: system, version ID, used to verify the legality of version deployment; and, The deployment data synchronization interface provides the following elements: system, code branch, module, last merge time, deployment package address, submitter, deployer, deployment time, and version ID, which are used to synchronize detailed deployment data to the test management platform. Step 32: Version submission for testing. This mainly involves binding version information with the test plan. During regular testing, there may be multiple requirements for the same version within a system. When the version administrator receives a deployment request offline, they register the version information on the test management platform, call the version submission interface in Step 31, and generate a valid version ID. Step 33: Version deployment process. The automated deployment process is completed with the help of the pipeline. When deploying, the version ID is filled in. When executing, the version verification interface in step 31 is called. When the verification is passed, the automated deployment process is executed. After the automated test admission on the pipeline is passed, the deployment data synchronization interface in step 31 is called to synchronize the deployment information. Step 34: When the test platform receives the deployment data synchronization for the first time, it sets the test plan status in the deployment information to "under testing" according to the version information in Step 32, and the test execution team begins to intervene in the test.

[0033] In this embodiment, during the version submission application stage, the deployment pipeline automatically verifies the legitimacy of the version ID and synchronizes key information such as the deployment package address, code branch, and deployment timestamp in real time, achieving precise matching between the development version and the testing environment. This technical solution replaces traditional manual submission operations with automated processes, effectively solving problems such as inconsistent version identification and outdated deployment information, ensuring that the testing environment is always based on a legitimate and up-to-date development version. Simultaneously, the automatically generated version submission report fully records the submission results and deployment records, providing a traceable version baseline for subsequent test execution and significantly reducing the risk of invalid tests due to version inconsistencies.

[0034] In one embodiment, step S4: Based on the version baseline provided in the version testing report, automatically associate the test case execution and defect submission with the complete deployment data of the current version during the test plan execution phase, and obtain the final deployment record after test verification. This specifically includes the following steps: Step S41: Review the smoke test records of the test plans associated with the version identifiers and obtain the smoke test records; quickly verify the basic usability of the core functions of the software through smoke testing, screen out versions with fatal defects, avoid wasting subsequent testing resources, and ensure that only basically stable versions enter the detailed testing phase; Step S42: Based on the smoke test records, execute different case execution and defect management strategies to obtain the final deployment records of the test passed.

[0035] This embodiment establishes a version baseline through version testing reports and automatically links test case execution, defect submission, and deployment data during the test plan execution phase, ensuring close collaboration between the testing process and version building. Based on the review results of smoke test records, testing strategies are dynamically adjusted, such as automated test tiered execution and defect closed-loop management, ultimately generating a complete deployment record including deployment packages, test coverage, and defect convergence status. This method reduces manual intervention, improves testing efficiency and resource utilization, while reducing the risk of missed defects and ensuring the accuracy and traceability of version deployment data.

[0036] In one embodiment, step S42: Based on the smoke test record, execute different case execution and defect management strategies to obtain the final deployment record of the test passed, specifically including the following steps: Step S42A: If the test submission is approved, the case execution and defect management module will be opened, the test plan status will be changed to "in testing", the case defect test will be executed, and the final deployment record of the test will be obtained. Step S42B: If the test submission fails, keep the case execution and defect module closed. You need to readjust the version or fix the problem before submitting the test submission again.

[0037] In one embodiment, step S42A: If the test submission is approved, the case execution and defect management module is opened, the test plan status is changed to "under testing", the case defect test is executed, and the final deployment record of the test is obtained. This specifically includes the following steps: After the test submission is approved, the currently active deployment version information will be automatically captured when the test cases are executed; When a defect is submitted, a mapping relationship between the defect and the deployment version is automatically established. Establish a two-way traceability link between test results and deployment records to obtain the final deployment record of the test passed.

[0038] In one embodiment, a bidirectional traceability link is established between test results and deployment records to obtain the final deployment record when the test passes, specifically including: Automatically capture complete metadata of the currently active deployment version when executing test cases, including code branch, last merge time, and deployment package hash. When a defect is submitted, the mapping relationship between the defect and the deployment version is automatically associated, and a snapshot of the deployment environment when the defect is discovered is recorded. Construct a three-dimensional correlation matrix of version, test, and defect to obtain the final deployment record after the test passed; In one embodiment, step S4 is specifically implemented as follows: The testing platform develops a testing module for the test plan in the testing process, and testers register smoke test records. The test lead reviews the test submission. If the review is approved, the test platform's test case execution and defect management modules are opened, and the actual test start time of the test plan is recorded. If the review is not approved, the test case execution and defect management modules remain closed. After the test submission is approved, when executing the test case, the latest deployment record version data of the current version will be automatically obtained and stored in the test case execution record; After the test submission is approved, when submitting a defect, the latest deployment record version data of the current version is automatically obtained and stored in the defect submission record.

[0039] This embodiment constructs a three-dimensional traceability system of version-test-defect by automatically associating test case execution records and defect reports with the complete deployment data of the current version (including metadata such as code branches and deployment package hash values) during the test plan execution phase. This technical solution achieves a strong correlation between the testing process and version deployment, ensuring that each test result and defect can be accurately located to its corresponding code version, effectively solving the problem of inaccurate defect location caused by difficulties in version tracing in traditional testing. By automatically obtaining the final deployment record of passed tests, a fully verified and reliable benchmark is provided for version upgrades, significantly improving the credibility of test data and the controllability of version quality.

[0040] In one embodiment, step S5: the version upgrade application stage further includes: An upgrade application should be initiated based on the last successful deployment record. The application materials for the upgrade application should include the deployment package hash value, test coverage report and defect fix list; specifically, it should include: system, code branch, module, last code merge time, deployment package address, person submitting the test, person deploying, deployment time, version ID and review status.

[0041] In one embodiment, the version upgrade stage implements a multi-level verification mechanism, including: Deployment package integrity verification: Compare the hash value of the upgrade package with the hash value of the last deployment package in the test environment; Test coverage verification: Verify whether the test case execution coverage reaches the preset threshold; Defect closed-loop verification: Confirm that all critical level defects have been repaired and verified; Version consistency check: Ensure that the code of the upgrade package is completely consistent with the branch commit records of the tested version.

[0042] In one embodiment, step S6 specifically includes the following steps: Step S61: On the launch window day, the version manager will organize a version confirmation review meeting. The review content is all the records to be reviewed summarized in step 5.1. The development team will conduct a second review of the version information. After the review is completed, the version manager will upgrade the deployment data to production and synchronize the deployment package address to the production environment for the operations team to obtain according to the launch process. Step S62: After the meeting approval is completed, the version manager shall issue a full version meeting minutes of the release window day and provide it to each project team as the release process access material. Step S63: After the deployment is completed, the operations team will adjust the requirement status to "deployed" and synchronize the status to the test management platform. The test management platform will then change the status of the corresponding system test plans to "deployed," and the test manager will determine whether to close the system.

[0043] This embodiment employs a multi-level verification mechanism (including deployment package integrity verification, test coverage verification, defect closure-loop verification, and version consistency verification) to rigorously review upgraded versions during the version upgrade approval stage. This ensures that only versions meeting quality standards can generate deployment access materials. By establishing a standardized version review process and automated verification mechanism, this technical solution effectively addresses the issue of lax version quality control caused by human factors in traditional approval processes. Simultaneously, the system automatically generates deployment access materials containing complete test verification records, achieving closed-loop management of the entire process from requirement reception to version deployment. This significantly improves the quality controllability and deployment security of software releases, providing complete and traceable version release documentation for operation and maintenance deployment.

[0044] Secondly, such as Figure 2 As described above, this application provides a system applied to the version test management method based on the test submission process, including a test phase splitting module 100, a test plan generation module 200, a test submission module 300, a test module 400, an upgrade application module 500, and an upgrade review and launch access module 600. The testing phase breakdown module 100 is used to standardize the software version testing process into 7 testing phases, including test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure. The test plan generation module 200 is communicatively connected to the test phase splitting module 100, and is used to receive test requirement data of the software version in the test requirement receiving phase, and automatically split the requirements according to the associated system to generate the corresponding test plan in the test plan generation phase. The test submission module 300 is communicatively connected to the test plan generation module 200. During the version test submission application stage, it automatically verifies the legality of the version ID through the deployment pipeline and synchronizes key information such as deployment package address, code branch and timestamp to the associated test plan in real time, and generates a version test submission report containing test submission results and the latest deployment record. The test module 400 is communicatively connected to the test submission module 300 and is used to automatically associate the case execution and defect submission with the complete deployment data of the current version during the test plan execution phase based on the version baseline provided by the version test submission report, and obtain the final deployment record after passing the test verification. The upgrade application module 500 is communicatively connected to the test module 400 and is used to initiate an upgrade application based on the final deployment record that has passed the test during the version upgrade application stage. The upgrade review and launch access module 600 is communicatively connected to the upgrade application module 500. It is used to review the approved version during the version upgrade approval stage, generate launch access materials for the upgraded version that has passed the review, and complete the test closed loop.

[0045] The functions of each module in the aforementioned version test management system based on the test submission process correspond to the steps in the aforementioned version test management method embodiment based on the test submission process. Their functions and implementation processes will not be described in detail here.

[0046] Thirdly, embodiments of this application provide a version testing management device based on the testing process. The version testing management device based on the testing process can be a personal computer (PC), a laptop, a server, or other device with data processing capabilities.

[0047] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the version testing and management equipment based on the testing process, as well as interfaces used for interconnecting the version testing and management equipment based on the testing process with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0048] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0049] The processor can be a general-purpose processor, which can call a version test management program based on the test submission process stored in memory and execute the version test management method based on the test submission process provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the version test management program based on the test submission process is called can be referred to in the various embodiments of the version test management method based on the test submission process of this application, and will not be repeated here.

[0050] Fourthly, embodiments of this application also provide a readable storage medium.

[0051] The present application stores a version test management program based on the test submission process on a readable storage medium, wherein when the version test management program based on the test submission process is executed by a processor, it implements the steps of the version test management method based on the test submission process as described above.

[0052] The method implemented when the version test management program based on the test submission process is executed can be referred to in the various embodiments of the version test management method based on the test submission process of this application, and will not be repeated here.

[0053] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0054] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0055] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A version testing management method based on the testing process, characterized in that, Includes the following steps: The standardized software version testing process consists of 7 testing phases, including test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure. During the test requirement reception phase, test requirement data for the software version is received. During the test plan generation phase, the requirements are automatically broken down according to the associated systems to generate corresponding test plans. During the version testing application stage, the deployment pipeline automatically verifies the legality of the version ID and synchronizes key information such as the deployment package address, code branch, and timestamp to the associated test plan in real time, generating a version testing report that includes the testing results and the latest deployment records; Based on the version baseline provided in the version test report, the test plan execution phase automatically associates the test case execution and defect submission with the complete deployment data of the current version, and obtains the final deployment record after the test verification. During the version upgrade application phase, an upgrade application is initiated based on the final deployment record that has passed testing; During the version upgrade approval stage, the approved versions undergo version review, and the upgraded versions that pass the review generate online access materials to complete the testing loop.

2. The version testing control method based on the testing process as described in claim 1, characterized in that, The test requirement data includes requirement name, requirement number, list of related systems, total workload of requirement, list of workload of subsystems of requirement, person in charge of requirement, and requirement status.

3. The version testing control method based on the testing process as described in claim 1, characterized in that, The version testing application stage also includes: Generate a unique version identifier through the version management module; Verify the validity of the version identifier when the deployment pipeline is executed; After deployment is complete, the deployment package metadata will be automatically sent back to the test management platform.

4. The version testing control method based on the testing process as described in claim 1, characterized in that, Based on the version baseline provided in the version testing report, the system automatically associates test case execution and defect submissions with the complete deployment data of the current version during the test plan execution phase. After verification through testing, the final deployment record is obtained, which specifically includes the following steps: Review the smoke test records for test plans with associated version identifiers and obtain the smoke test records; Based on the smoke test logs, different case execution and defect management strategies are implemented to obtain the final deployment logs after the tests pass.

5. The version testing control method based on the testing process as described in claim 4, characterized in that, Based on the smoke test records, different test case execution and defect management strategies are implemented to obtain the final deployment record after the test passes. This specifically includes the following steps: If the test submission is approved, the test case execution and defect management module will be enabled, the test plan status will be changed to "in testing", test case defect tests will be executed, and the final deployment record of the test will be obtained. If the test submission fails the review, keep the case execution and defect module closed. You will need to readjust the version or fix the problem before submitting it for review again.

6. The version testing control method based on the testing process as described in claim 5, characterized in that, If the test submission is approved, the test case execution and defect management module will be enabled, the test plan status will be changed to "in testing," test case defect tests will be executed, and the final deployment record of the successful test will be obtained. The specific steps include: After the test submission is approved, the currently active deployment version information will be automatically captured when the test cases are executed; When a defect is submitted, a mapping relationship between the defect and the deployment version is automatically established. Establish a two-way traceability link between test results and deployment records to obtain the final deployment record of the test passed.

7. The version testing control method based on the testing process as described in claim 5, characterized in that, Establish a two-way traceability link between test results and deployment records to obtain the final deployment record after the test passes, specifically including: Automatically capture complete metadata of the currently active deployment version when executing test cases, including code branch, last merge time, and deployment package hash. When a defect is submitted, the mapping relationship between the defect and the deployment version is automatically associated, and a snapshot of the deployment environment when the defect is discovered is recorded. Build a three-dimensional correlation matrix of version, test, and defect to obtain the final deployment record of the tested version.

8. The version testing control method based on the testing process as described in claim 1, characterized in that, The version upgrade application stage also includes: An upgrade application should be initiated based on the last successful deployment record. The application materials for the upgrade application must include the deployment package hash value, test coverage report, and defect fix list.

9. The version testing control method based on the testing process as described in claim 1, characterized in that, The version upgrade phase implements a multi-level verification mechanism, including: Compare the hash values ​​of the upgrade package with those of the last deployment package in the test environment; Verify whether the test case execution coverage reaches the preset threshold; Confirm that all critical level defects have been repaired and verified; Verify that the code of the upgrade package is consistent with the branch commit records of the tested and passed version.

10. A system applied to the version test management method based on the test submission process as described in any one of claims 1-9, characterized in that, include: The testing phase is divided into modules to standardize the software version testing process into 7 testing phases, including test requirement reception, test plan generation, version submission for testing, test plan execution, version upgrade application, version upgrade approval, and test plan closure. The test plan generation module is communicatively connected to the test phase splitting module. It is used to receive test requirement data of the software version during the test requirement receiving phase, and to automatically split the requirements according to the associated system to generate the corresponding test plan during the test plan generation phase. The testing module is connected to the test plan generation module and is used to automatically verify the legality of the version ID through the deployment pipeline and synchronize key information such as deployment package address, code branch and timestamp to the associated test plan in real time during the version testing application stage, and generate a version testing report containing the testing results and the latest deployment record. The testing module, which communicates with the testing module, is used to automatically associate the test case execution and defect submission with the complete deployment data of the current version during the test plan execution phase, based on the version baseline provided by the version testing report, and obtain the final deployment record after passing the test verification. The upgrade application module communicates with the test module and is used to initiate an upgrade application based on the final deployment record of the test passing during the version upgrade application stage. The upgrade review and launch access module communicates with the upgrade application module and is used to review the approved version during the version upgrade approval stage, generate launch access materials for the upgraded version that has passed the review, and complete the test closed loop.

Images