Rapid iteration test method based on PLM system

Abstract

A rapid iteration test method based on a PLM system comprises the steps that firstly, the system is divided into a functional module and a non-functional module according to the core service process of the PLM system to be tested, functional domain decoupling is conducted on the functional module, and a plurality of independent test modules are obtained; 2, respectively making test plans for the independent test modules and the non-functional modules, and distributing test resources for the independent test modules; 3, compiling a test case according to the test plan; 4, compiling a test script according to the test case, and constructing a continuous automatic test chain; 5, deploying a test environment, continuously and automatically testing the test case in the script by the test chain, and generating a structured test report; and 6, analyzing the test report, and ending the test when the passing rate of the test case meets the acceptance standard. Therefore, execution of the test case and feedback of the test result are automatically executed through the automatic test script, and the overall test efficiency is high.

Description

Technical Field

[0001] The present invention relates to a testing method for a PLM system, belongs to the field of software testing, and in particular to a rapid iterative testing method based on a PLM system. Background Art

[0002] A PLM system is an information system used to manage the entire product lifecycle, from conception and design to delisting. It spans multiple departments and functional areas, involving product, design, manufacturing, tasks, quality control, and other aspects. Therefore, PLM systems are highly complex and place stringent demands on stability and scalability. Due to the rapid pace of market demand, the requirements for PLM systems also change frequently. To ensure the system's continuity, stability, and rapid response to market demands, testing the PLM system is particularly important. Currently, testing methods for PLM systems often involve multiple manual steps. Due to frequent changes in requirements, traditional testing processes are cumbersome, the workload is excessive, and testing takes a long time, resulting in low testing efficiency.

[0003] The Chinese patent application with application number 202410701790.X and application date May 31, 2024, discloses a method, device, and electronic device for testing an application system. The method includes: receiving an application test request, wherein the application test request is used to request testing of a specified application system, and the specified application system is one of a group of application systems; responding to the application test request, when the application test request matches the target business scenario of the specified application system, querying the sample data pool for sample data corresponding to the target business scenario; when the first sample data is queried, generating a set of first test data based on the first sample data; using the set of first test data to test the specified application system, and obtaining a first test result for the specified application system. Although this patent is more efficient in the test data generation link, it still has the following defects: The execution of test cases and feedback of test results in this design rely on manual operations, resulting in low overall testing efficiency.

[0004] The information disclosed in this background technology section is only intended to increase the understanding of the overall background of this patent application, and should not be regarded as an admission or any form of suggestion that the information constitutes the prior art already known to a person skilled in the art. Summary of the Invention

[0005] The purpose of the present invention is to overcome the defects and problems in the prior art that the execution of test cases and the feedback of test results rely on manual operations, resulting in low overall testing efficiency, and to provide a rapid iterative testing method based on a PLM system in which the execution of test cases and the feedback of test results are automatically performed through automated test scripts, thereby increasing the overall testing efficiency.

[0006] To achieve the above objectives, the technical solution of the present invention is: a rapid iterative testing method based on a PLM system, the rapid iterative testing method comprising the following steps: Step 1: First, divide the system into non-functional modules and functional modules based on the core business processes of the PLM system to be tested. Then, decouple the functional modules by functional domain to form several independent test modules. Step 2: Develop test plans for the independent test modules and non-functional modules, including test type, test scope, and acceptance criteria. At the same time, a dynamic resource allocation algorithm is used to calculate the test weight of each independent test module, and test resources are allocated to the independent test modules based on the test weight. Step 3: According to the above test plan, write test cases for the above independent test modules and non-functional modules to obtain several test cases; Step 4: First, write a test script based on the above test cases, and then build a continuous automated test chain based on the test script; Step 5: First, start the standardized image deployment test environment. In this test environment, the above-mentioned continuous automated test chain automatically pulls the PLM system code and executes the test cases in the above-mentioned test scripts. After the test cases are executed, a structured test report is automatically generated. The structured test report includes the test case pass rate; Step 6: If the pass rate of the test cases meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases does not meet the above acceptance criteria, a defect report is generated, and the PLM system code is repaired according to the defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated; if the pass rate of the test cases in the new structured test report meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases in the new structured test report does not meet the above acceptance criteria, the following process is repeated to generate a new defect report, and the PLM system code is repaired again according to the new defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated until the pass rate of the test cases meets the above acceptance criteria and the rapid iterative test is completed.

[0007] In the first step, the core business process of the PLM system to be tested refers to: first, dynamically collecting, screening, sorting, responding to and executing customer needs through a demand response funnel mechanism to obtain a priority demand list; then, based on the priority demand list and combined with the business logic of the PLM system, analyzing customer needs and identifying the core business process of the PLM system to be tested.

[0008] In the first step, decoupling the functional modules from their functional domains to form several independent test modules involves first confirming the PLM business logic based on customer requirements, then decoupling the functional modules from their functional domains based on the PLM business logic to obtain several independent test modules, where each independent test module corresponds to a business functional domain and has independent testing and verification capabilities. The PLM business logic includes material management, BOM changes, file management, document management, design tool collaboration, process management, and project management.

[0009] In the second step, the use of a dynamic resource allocation algorithm to calculate the test weight of each independent test module and allocate test resources to the independent test modules according to the test weight refers to: using a Critical Path Weighting algorithm, based on the critical path, business complexity, risk and customer weight of each independent test module, a comprehensive score is calculated through a quantitative model, and the weight of each independent test module is dynamically adjusted to allocate test resources.

[0010] In the fourth step, writing a test script according to the test case refers to writing a test script according to the operation steps and expected results of the test case; In the fourth step, building a continuous automated test chain based on the test script means integrating an automated test framework, an end-to-end test tool, and a continuous integration engine through the test script to form a continuous automated test chain.

[0011] In the fifth step, the continuous automated testing chain automatically pulls the PLM system code and executes the test cases in the above test script, which means that: the continuous integration engine in the continuous automated testing chain automatically pulls the PLM system code and triggers the test process, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases of the PLM system interaction scenario.

[0012] In the fifth step, automatically generating a structured test report after the test case is executed means: connecting the Allure reporting system with the continuous automated testing chain, and automatically generating a structured report through the Allure reporting system after the test case is executed.

[0013] In the sixth step, generating a defect report includes: connecting the Jira ticket system with the continuous automated testing chain and the Git repository, and automatically generating a Jira ticket for the test case that failed to be executed through the Jira ticket system; the Jira ticket describes the specific problem of the test failure, and the test case that failed to be executed refers to the test case whose actual test result does not match the expected result of the test case; In the sixth step, repairing the PLM system code according to the defect report and then submitting the repaired PLM system code means that after the developer locates the problem according to the Jira work order, he repairs the PLM system code and then submits the repaired PLM system code to the Git repository; In the sixth step, the continuous automated testing chain automatically pulls the repaired PLM system code and executes the test cases in the above test script, which means that after the repaired PLM system code is submitted to the Git repository, the continuous integration engine in the continuous automated testing chain automatically pulls the repaired PLM system code and triggers regression testing, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases for PLM system interaction scenarios.

[0014] The automated testing framework adopts the pytest framework, the end-to-end testing tool adopts the Playwright engine, and the continuous integration engine adopts Jenkins or GitLab CI.

[0015] In the fifth step, starting the standardized image to deploy the test environment means: building a test environment based on the PLM system to be tested, then using containerization technology to encapsulate the test environment into a standardized image, and starting the standardized image to automatically deploy the test environment during testing.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. A rapid iterative testing method based on a PLM system of the present invention comprises the following steps: writing test cases for non-functional modules and independent test modules according to a test plan; writing test scripts according to the test cases; building a continuous automated test chain based on the test scripts; starting a standardized mirror deployment test environment; in the test environment, the continuous automated test chain automatically pulls PLM system code and executes the test cases in the test scripts; when applied, first, according to the core business process of the PLM system to be tested, the system is divided into functional modules and non-functional modules, and the functional modules are decoupled from their functional domains to obtain a number of independent test modules; then, test plans are formulated for the non-functional modules and independent test modules respectively, and a dynamic resource allocation algorithm is used to allocate test resources to the independent test modules; then, test cases are written according to the test plan, and test scripts are written using an automated test framework according to the operating steps and expected results of the test cases; a continuous automated test chain is built based on the script, and the continuous automated test chain integrates the automated test framework and end-to-end testing Tools and continuous integration engines start standardized mirror deployment test environment, the continuous automated test chain automatically pulls the PLM system code and executes the test cases in the test script, and when all test cases are executed, a structured report is generated to feedback the test results. Finally, after modifying the PLM system code according to the test results, the code is pulled again and the test cases are executed until the acceptance criteria in the test plan are met. The modular processing of module division and functional domain decoupling of the PLM system makes the test more targeted and flexible. The integrated continuous automated test chain can automatically pull the PLM system code and execute test cases, reducing manual intervention and improving the speed and accuracy of test execution. The closed-loop feedback mechanism of the structured report can quickly feedback the test results and solve the problem by quickly locating the problem, which greatly shortens the test time. Compared with the traditional test method, the test cycle of the present invention is shortened by more than 30%, while improving the accuracy and stability of the test. This method has passed ISO / IEC 25010 standard compliance certification is suitable for industries with frequently changing requirements and high business complexity. It can provide highly efficient and accurate testing, effectively shortening the PLM system delivery cycle, accurately meeting customer needs, and ensuring long-term stable operation of the system after launch. It is particularly suitable for high-tech fields such as robotics manufacturing and aerospace. Therefore, this invention not only enables rapid iterative testing of PLM systems, but also improves overall testing efficiency.

[0017] 2. In a rapid iterative testing method based on a PLM system, the present invention adopts a Critical Path Weighting algorithm. According to the critical path, business complexity, risk and customer weight of each independent test module, the score is comprehensively calculated by a quantitative model, and the weight of each independent test module is dynamically adjusted to allocate test resources. When applied, the Critical Path Weighting algorithm is used to dynamically calculate the weight of the test module, give priority to the core business modules with high weight, cover multiple parameter combinations, ensure the comprehensive verification of the critical path, and optimize the resource allocation strategy for low-weight modules, only cover the main process, simplify the parameter combination and automatically regress through the script, reduce manual intervention, thereby optimizing resource allocation, improving test efficiency, and increasing the coverage of the core business module by 20%-30%, reducing the waste of resources on non-critical paths. Therefore, the present invention not only has a high overall test efficiency, but also reduces resource waste.

[0018] 3. In a rapid iterative testing method based on a PLM system of the present invention, a test environment is built based on the PLM system to be tested, and then the test environment is packaged into a standardized image using containerization technology. During testing, the standardized image is started to automatically deploy the test environment. During application, a test environment for the PLM system to be tested is first built based on the PLM system version requirements. Then, the dependencies required for the test environment of the PLM system are packaged and packaged using Docker technology to generate a standardized Docker image with a version binding mechanism. The environment dependencies include specific versions of databases, middleware, and browsers. Before testing, the standardized image is directly started and test data is loaded. Containerization makes the test environment setup more standardized, eliminating the need for testers to manually configure each environment, reducing the complexity of environment configuration and avoiding common errors and configuration inconsistencies in traditional manual configuration processes. At the same time, the containerized environment can be quickly reused and migrated, further improving testing efficiency. Docker containerization is integrated with the CI / CD pipeline to improve environment consistency, increasing test environment build efficiency by 50%, supporting rapid rollback and multi-version parallel testing, ensuring consistency between the test environment and the production environment, and avoiding test failures due to environmental differences. Therefore, the present invention not only reduces resource waste, but also improves the efficiency and consistency of test environment deployment.

[0019] 4. In a rapid iterative testing method based on a PLM system, the Allure reporting system is docked with a continuous automated test chain. After the test case is executed, a structured report is automatically generated by the Allure reporting system. When applied, after the automated test is completed, the Allure reporting system can generate a structured report. The structured report includes a test case pass rate, a defect distribution heat map, and a historical trend analysis, which comprehensively presents the overall results of the test case execution. The defect distribution heat map can accurately locate the problem and quickly identify high-frequency defect modules through an intuitive visualization method, thereby increasing the repair priority decision speed by 60%. This closed-loop feedback mechanism helps to quickly identify and solve key problems, avoid the lack of stability caused by the lengthy test-repair chain in traditional PLM, and ensure the long-term stable operation of the system after going online. Therefore, the present invention not only improves the efficiency and consistency of test environment deployment, but also improves the efficiency of defect repair. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flow chart of the present invention.

[0021] Figure 2 This is a test diagram of the business scope of the PLM system.

[0022] Figure 3 It is a flow chart of the rapid iterative test in the present invention.

[0023] Figure 4 This is a schematic diagram of adding the Playwright automated testing framework in the present invention to the PLM system. DETAILED DESCRIPTION

[0024] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] See also Figure 1 — Figure 4 A rapid iterative testing method based on a PLM system, the rapid iterative testing method comprising the following steps: Step 1: First, divide the system into non-functional modules and functional modules based on the core business processes of the PLM system to be tested. Then, decouple the functional modules by functional domain to form several independent test modules. Step 2: Develop test plans for the independent test modules and non-functional modules, including test type, test scope, and acceptance criteria. At the same time, a dynamic resource allocation algorithm is used to calculate the test weight of each independent test module, and test resources are allocated to the independent test modules based on the test weight. Step 3: According to the above test plan, write test cases for the above independent test modules and non-functional modules to obtain several test cases; Step 4: First, write a test script based on the above test cases, and then build a continuous automated test chain based on the test script; Step 5: First, start the standardized image deployment test environment. In this test environment, the above-mentioned continuous automated test chain automatically pulls the PLM system code and executes the test cases in the above-mentioned test scripts. After the test cases are executed, a structured test report is automatically generated. The structured test report includes the test case pass rate; Step 6: If the pass rate of the test cases meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases does not meet the above acceptance criteria, a defect report is generated, and the PLM system code is repaired according to the defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated; if the pass rate of the test cases in the new structured test report meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases in the new structured test report does not meet the above acceptance criteria, the following process is repeated to generate a new defect report, and the PLM system code is repaired again according to the new defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated until the pass rate of the test cases meets the above acceptance criteria and the rapid iterative test is completed.

[0026] In the first step, the core business process of the PLM system to be tested refers to: first, dynamically collecting, screening, sorting, responding to and executing customer needs through a demand response funnel mechanism to obtain a priority demand list; then, based on the priority demand list and combined with the business logic of the PLM system, analyzing customer needs and identifying the core business process of the PLM system to be tested.

[0027] In the first step, decoupling the functional modules from their functional domains to form several independent test modules involves first confirming the PLM business logic based on customer requirements, then decoupling the functional modules from their functional domains based on the PLM business logic to obtain several independent test modules, where each independent test module corresponds to a business functional domain and has independent testing and verification capabilities. The PLM business logic includes material management, BOM changes, file management, document management, design tool collaboration, process management, and project management.

[0028] In the second step, the use of a dynamic resource allocation algorithm to calculate the test weight of each independent test module and allocate test resources to the independent test modules according to the test weight refers to: using a Critical Path Weighting algorithm, based on the critical path, business complexity, risk and customer weight of each independent test module, a comprehensive score is calculated through a quantitative model, and the weight of each independent test module is dynamically adjusted to allocate test resources.

[0029] In the fourth step, writing a test script according to the test case refers to writing a test script according to the operation steps and expected results of the test case; In the fourth step, building a continuous automated test chain based on the test script means integrating an automated test framework, an end-to-end test tool, and a continuous integration engine through the test script to form a continuous automated test chain.

[0030] In the fifth step, the continuous automated testing chain automatically pulls the PLM system code and executes the test cases in the above test script, which means that: the continuous integration engine in the continuous automated testing chain automatically pulls the PLM system code and triggers the test process, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases of the PLM system interaction scenario.

[0031] In the fifth step, automatically generating a structured test report after the test case is executed means: connecting the Allure reporting system with the continuous automated testing chain, and automatically generating a structured report through the Allure reporting system after the test case is executed.

[0032] In the sixth step, generating a defect report includes: connecting the Jira ticket system with the continuous automated testing chain and the Git repository, and automatically generating a Jira ticket for the test case that failed to be executed through the Jira ticket system; the Jira ticket describes the specific problem of the test failure, and the test case that failed to be executed refers to the test case whose actual test result does not match the expected result of the test case; In the sixth step, repairing the PLM system code according to the defect report and then submitting the repaired PLM system code means that after the developer locates the problem according to the Jira work order, he repairs the PLM system code and then submits the repaired PLM system code to the Git repository; In the sixth step, the continuous automated testing chain automatically pulls the repaired PLM system code and executes the test cases in the above test script, which means that after the repaired PLM system code is submitted to the Git repository, the continuous integration engine in the continuous automated testing chain automatically pulls the repaired PLM system code and triggers regression testing, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases for PLM system interaction scenarios.

[0033] The automated testing framework adopts the pytest framework, the end-to-end testing tool adopts the Playwright engine, and the continuous integration engine adopts Jenkins or GitLab CI.

[0034] In the fifth step, starting the standardized image to deploy the test environment means: building a test environment based on the PLM system to be tested, then using containerization technology to encapsulate the test environment into a standardized image, and starting the standardized image to automatically deploy the test environment during testing.

[0035] The supplementary description of the present invention is as follows: The present invention preferably adopts a rapid iterative testing method based on an agile testing model, aligning the testing cycle with the development iteration to achieve real-time response and verification closed loop of requirement changes.

[0036] The reason why the present invention preferably adopts a rapid iterative testing method based on an agile testing model is that: since the testing cycle of the rapid iterative testing method is relatively short, usually in days or even hours, this short cycle enables the development team to quickly obtain feedback, adjust the development direction in a timely manner, and ensure that the project progresses as planned. Secondly, as the development progresses, the software system will continue to update its version. Rapid iterative testing needs to be able to adapt to these changes in a timely manner to ensure that each new version can be effectively tested to avoid introducing new problems. Thirdly, rapid iterative testing is closely integrated with continuous integration and continuous testing to ensure that each code submission can pass automated testing, timely discover and fix problems, and ensure code quality. Finally, through continuous testing and optimization, it is ensured that the system can run efficiently and stably in rapid iterations to meet user needs. When applied, the agile testing model is used to align the test cycle with the development iteration to achieve real-time response and verification closed loop of demand changes, shorten the feedback cycle, improve the efficiency of test resource utilization, and support rapid iteration and optimization of core business processes.

[0037] The functional modules preferably include a material management module (responsible for the creation, editing, deletion and query of materials), a BOM change module (managing the creation, modification and approval of BOM structures), a file management module (supporting file upload, download and version control), a document management module (handling document creation, editing, approval and release), and a design tool collaboration module (realizing the integration of design tools, data synchronization and collaborative editing).

[0038] The non-functional modules preferably include a performance module (ensuring the response time and resource utilization of the system under high concurrency and high load), a security module (responsible for the system's access control, data encryption and vulnerability protection), a compatibility module (ensuring the compatibility of the system on different operating systems, browsers and devices), and a reliability module (ensuring the stability of the system during long-term operation and after fault recovery).

[0039] Example 1: See also Figure 1 — Figure 4 A rapid iterative testing method based on a PLM system, the rapid iterative testing method comprising the following steps: Step 1: First, divide the system into non-functional modules and functional modules based on the core business processes of the PLM system to be tested. Then, decouple the functional modules by functional domain to form several independent test modules. Step 2: Develop test plans for the independent test modules and non-functional modules, including test type, test scope, and acceptance criteria. At the same time, a dynamic resource allocation algorithm is used to calculate the test weight of each independent test module, and test resources are allocated to the independent test modules based on the test weight. Step 3: According to the above test plan, write test cases for the above independent test modules and non-functional modules to obtain several test cases; Step 4: First, write a test script based on the above test cases, and then build a continuous automated test chain based on the test script; Step 5: First, start the standardized image deployment test environment. In this test environment, the above-mentioned continuous automated test chain automatically pulls the PLM system code and executes the test cases in the above-mentioned test scripts. After the test cases are executed, a structured test report is automatically generated. The structured test report includes the test case pass rate; Step 6: If the pass rate of the test cases meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases does not meet the above acceptance criteria, a defect report is generated, and the PLM system code is repaired according to the defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated; if the pass rate of the test cases in the new structured test report meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases in the new structured test report does not meet the above acceptance criteria, the following process is repeated to generate a new defect report, and the PLM system code is repaired again according to the new defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated until the pass rate of the test cases meets the above acceptance criteria and the rapid iterative test is completed.

[0040] Example 2: The basic content is the same as Example 1, except that: in the first step, the core business process of the PLM system to be tested refers to: first, dynamically collecting, screening, sorting, responding to and executing customer needs through a demand response funnel mechanism to obtain a priority demand list; then, based on the priority demand list and combined with the business logic of the PLM system, analyzing customer needs to identify the core business process of the PLM system to be tested.

[0041] When applying, first collect customer needs in real time and dynamically through multiple channels (such as user feedback system, market research data, etc.), use rule engine or manual review to perform preliminary screening, remove invalid and duplicate needs, and screen out high-value needs related to the core functions of the PLM system to be tested. Then, based on dimensions such as business value and technical complexity, generate a priority demand list through weighted sorting algorithm, and assign high-priority needs to the development team for execution. During the demand execution process, continuously collect customer and team feedback, optimize the demand processing mechanism, and form a dynamic closed-loop management; through the demand response funnel mechanism, you can quickly focus on key needs, improve the efficiency of customer demand conversion, and ensure that testing activities are closely centered around customers Actual business needs are developed; in the process of identifying the core business processes of the PLM system to be tested, the functional correlation and priority of each business link of the PLM system to be tested (such as material management, BOM changes, document management, etc.) are first clarified. Then, combined with the priority demand list, the core processes that have the greatest impact on system stability and business efficiency (such as BOM change control and design tool collaboration) are identified to ensure their efficient operation to support product design, production quality and customer satisfaction. By accurately matching customer needs with core business processes, the problem of insufficient stability of traditional PLM systems due to the wide range of business is solved, rapid iteration and efficient delivery are supported, ensuring the efficient and stable operation of the PLM system and accurately matching customer needs.

[0042] Example 3: The basic content is the same as Example 1, except that: in the first step, the functional domain decoupling of the functional modules to form several independent test modules means: first, confirming the PLM business logic according to customer needs, and then decoupling the functional domains of the functional modules according to the PLM business logic to obtain several independent test modules, wherein each independent test module corresponds to a business functional domain and has independent testing and verification capabilities; the PLM business logic includes material management, BOM changes, file management, document management, design tool collaboration, process management, and project management.

[0043] When applying, the system is divided into functional modules and non-functional modules according to the core business processes of the PLM system to be tested. Among them, the functional modules are directly involved in the business processes and realize specific business functions. The test plan covers functional testing, performance testing, integration testing and regression testing, etc.; although the non-functional modules do not directly perform business functions, they are crucial to the operation and performance of the system, and are usually related to compatibility, performance and security. The test plan includes performance testing, security testing, compatibility testing and reliability testing, etc.; combined with the business characteristics and technical requirements of the PLM system, the test covers functional modules and non-functional modules, and a targeted test plan is formulated to improve the test accuracy; based on customer needs and the business logic of the PLM to be tested (including material management, BOM changes, file management, etc.), the user stories are split into atomic functional units, and merged into independent functional domains based on functional similarity, such as materials Management, BOM changes, file management, document management, design tool collaboration, etc. Then, define clear input / output interfaces for each functional domain to ensure that the interactions between each functional domain are clear and controllable. Then, use the dependency injection framework to manage the dependencies between functional domains to avoid functional domains directly creating dependencies, thereby improving the maintainability and testability of the system. Finally, encapsulate the data access logic independently to avoid the business logic module directly operating the database. Through the above functional domain decoupling strategy, the coupling degree between functional domain modules can be effectively reduced, ensuring that the functional modules of the PLM system to be tested are reasonably divided into independent functional domains, and creating a test module with independent test verification capabilities for each functional domain, thereby improving the maintainability and scalability of the system, supporting rapid iteration and efficient testing, and solving the problems of maintenance difficulties and low test coverage caused by complex module dependencies in traditional architecture.

[0044] Example 4: The basic content is the same as Example 1, except that: in the second step, the use of a dynamic resource allocation algorithm to calculate the test weight of each independent test module and allocate test resources to the independent test module according to the test weight refers to: using a Critical Path Weighting algorithm, according to the critical path, business complexity, risk and customer weight of each independent test module, a quantitative model is used to comprehensively calculate the score, and the weight of each independent test module is dynamically adjusted to allocate test resources.

[0045] When applied, the Critical Path Weighting algorithm is used to dynamically calculate the test weight of each independent test module, giving priority to high-weight core business modules, covering multi-parameter combinations, and ensuring comprehensive verification of critical paths. For low-weight modules, the resource allocation strategy is optimized to cover only the main process, simplify parameter combinations, and automatically regress through scripts to reduce manual intervention, thereby optimizing resource allocation and improving testing efficiency. The coverage of core business modules is increased by 20%-30%, and resource waste on non-critical paths is reduced; the specific calculation method is: Critical path: Count the number of times a module is dependent (direct / indirect), formula: Critical path score = number of direct dependencies × 0.6 + number of indirect dependencies × 0.4; Business complexity: code circle complexity (SonarQube) + number of business rules Formula: Complexity score = cyclomatic complexity × 0.5 + number of rules × 0.5; Risk: historical defect density (number of defects / lines of code) + fault impact level (level 1-5), formula: Risk score = defect density × 0.4 + impact level × 0.6; Customer weight: customer score (1-10) + business value coefficient (such as VIP × 2), formula: Customer score = customer score × 0.7 + business coefficient × 0.3; Comprehensive score = critical path × 0.4 + complexity × 0.2 + risk × 0.3 + customer × 0.1; Resource allocation based on the comprehensive score: High: exclusive test resources are used for execution 3-5 times, comprehensive score ≥ 0.8; Medium: double the time + parallel execution, comprehensive score = 0.5; Low: execution after other tasks are completed, comprehensive score < 0.5.

[0046] Example 5: The basic content is the same as Example 1, except that: in the third step, the writing of test cases for the above-mentioned independent test modules and non-functional modules refers to: using the pytest framework to write test cases for the above-mentioned independent test modules; using the pytest framework or using performance testing tools, compatibility testing tools, and security testing tools respectively to write test cases for non-functional modules.

[0047] When applying, write test cases for independent test modules and use the functions of the pytest framework, such as parameterized testing and dynamic test generation, to improve test efficiency and accuracy; for non-functional modules, choose the pytest framework or other appropriate tools to write test cases according to specific needs; for performance testing modules, use performance testing tools such as JMeter, and for compatibility testing, use compatibility testing tools such as BrowserStack, and for security testing, use security testing tools such as Nessus.

[0048] Example 6: The basic content is the same as Example 1, except that: in the fourth step, writing a test script according to the above test case means: writing a test script according to the operation steps and expected results of the above test case; in the fourth step, building a continuous automated test chain based on the test script means: integrating the automated test framework, end-to-end testing tools, and continuous integration engine through the test script to form a continuous automated test chain.

[0049] When applied, the test script is based on the modular design principle, converting the operation steps of the test case into reusable code units, verifying the expected results through the assertion mechanism, and using parameterized data-driven technology to decouple the test data from the script logic; in terms of continuous automated test chain integration, first use the pytest framework to write parameterized test scripts based on Python, use the fixture dependency injection mechanism to manage test resources, and implement batch verification of multi-scenario business processes. Then integrate the Playwright engine as an end-to-end testing tool to form a pytest combined with Playwright automated testing module. The Playwright engine performs cross-browser testing in headless mode, such as CAD file upload and approval flow triggering, covering PLM core interaction scenarios, ensuring the stability and consistency of the system in different browser environments, and supporting network request monitoring and UI element intelligent waiting; finally, combine pytest with Playwright's automated testing module with Jenkins or GitLab The CI continuous integration engine tool is connected to form a continuous automated testing chain. The continuous integration engine automatically triggers testing every time the code is updated to ensure that code changes do not destroy the original functions of the system, and promptly feeds back test results to the development team, forming a close collaboration between testing and development; the rapid iterative testing process reduces the complexity and error probability of manual operations through the execution of automated scripts, and improves the accuracy and speed of testing.

[0050] Example 7: The basic content is the same as Example 1, except that: in the fifth step, the continuous automated test chain automatically pulls the PLM system code and executes the test cases in the above-mentioned test script, which means that the continuous integration engine in the continuous automated test chain automatically pulls the PLM system code and triggers the test process, and the automated test framework in the continuous automated test chain calls the test script and automatically executes the test cases in the test script. During this process, the automated test framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases for the PLM system interaction scenario.

[0051] When applied, the continuous automated testing chain is connected to the Git repository. After the developer submits the PLM system code to the Git repository, the Jenkins or GitLab CI continuous integration engine tool automatically pulls the latest version of the PLM system code from the Git repository, triggers the test process, calls the test script through the pytest framework, and automatically executes the test cases in the test script. The automated testing framework calls the Playwright engine to perform end-to-end testing, simulates user cross-browser operations, and verifies the integrity and consistency of the PLM system interaction scenarios; pytest combines Playwright's automated testing module with Jenkins or GitLab CI to form a continuous automated testing chain, which can realize various automated tests such as functional testing, performance testing, security testing, compatibility testing and regression testing. After the continuous integration engine tool pulls the code, it automatically triggers the test, monitors the execution status and provides real-time feedback on the results; this automated testing method significantly improves testing efficiency, avoids human errors in manual testing, and ensures the reliability of test results.

[0052] Example 8: The basic content is the same as Example 1, except that: in the fifth step, after the test case is executed, automatically generating a structured test report means: connecting the Allure reporting system with the continuous automated testing chain, and after the test case is executed, automatically generating a structured report through the Allure reporting system.

[0053] When used, the Allure reporting system integrates with the continuous automated testing chain. After all test cases are executed, the Allure reporting system generates a structured report, including test case pass rate, defect distribution heat map, and historical trend analysis. The test case pass rate clearly displays the test pass status of each module. If the test case pass rate meets the acceptance criteria, the test is considered complete. The defect distribution heat map visually displays the distribution of defects across modules, facilitating the prioritization of remediation in high-risk areas. Historical trend analysis tracks the changing trends of test results, helping teams assess the impact of iterations on system quality. The Allure reporting plug-in generates intuitive test reports. After the CI task executes the test, it calls Allure to generate the report and publish it to the server. This report provides real-time feedback on quality status, accelerating problem identification. The report displays key information such as test case pass rate and failure reasons, ensuring detailed analysis of test results for core business processes and improving the efficiency of problem discovery and resolution. In practical applications, such as in the automotive manufacturing or aerospace sectors, this automated testing and reporting mechanism helps teams quickly respond to changing requirements within complex PLM systems and ensure high-quality system delivery across different iterations. Through Allure reporting, teams can quickly identify and resolve key issues, ensuring long-term stable operation of the system after launch.

[0054] Example 9: The basic content is the same as Example 1, except that: in the sixth step, generating a defect report means: connecting the Jira work order system with the continuous automated testing chain and the Git repository, and automatically generating a Jira work order for the test case that was not executed through the Jira work order system; the Jira work order describes the specific problem of the test failure, and the test case that was not executed refers to the test case whose actual test result does not match the expected result of the test case; in the sixth step, repairing the PLM system code according to the defect report and then submitting the repaired PLM system code means: after the developer locates the problem according to the Jira work order, he repairs the PLM system code Repair, and then submit the repaired PLM system code to the Git repository; in the sixth step, the continuous automated testing chain automatically pulls the repaired PLM system code and executes the test cases in the above test script, which means that after the repaired PLM system code is submitted to the Git repository, the continuous integration engine in the continuous automated testing chain automatically pulls the repaired PLM system code and triggers regression testing, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases for the PLM system interaction scenario.

[0055] When applying, first connect the Jira ticket system with the continuous automated testing chain and Git repository. After all test cases have been executed, the test cases whose actual test results do not match the expected results of the test cases are considered to have failed to be executed. For these test cases, the Jira ticket system will automatically create a Jira ticket, assign a responsible person, and associate the Git commit record of the repair code to achieve problem traceability. The Jira ticket describes in detail the specific problem of the test case failure and notifies the developer. The developer can quickly locate the problem and fix it based on the detailed information in the Jira ticket; the repaired code is submitted back to the Git repository, and the Jenkins or GitLab in the continuous integration tool chain is used. The CI continuous integration engine tool automatically detects new submissions and triggers regression testing. Regression testing ensures that the repaired code does not introduce new problems and verifies the overall stability of the system. The regression test must meet the following conditions to pass: all core functional use cases are executed successfully, all serious and above defects are repaired and verified, the test coverage of the scope of impact of the code change meets the requirements (coverage ≥ 80%), and the test results are reviewed by the team to confirm that there are no residual risks. This automated defect management and regression testing mechanism significantly improves the efficiency of defect management, ensuring that problems can be quickly discovered and resolved. At the same time, the automated regression testing of the continuous integration tool chain ensures the quality of code repairs and the stability of the system. In practical applications, such as in the automotive manufacturing or aerospace fields, this automated defect management and regression testing mechanism can help teams quickly respond to demand changes in complex PLM systems, quickly repair defects and verify system stability, ensuring that customer needs are efficiently responded to.

[0056] Example 10: The basic content is the same as Example 1, except that: the automated testing framework adopts the pytest framework, the end-to-end testing tool adopts the Playwright engine, and the continuous integration engine adopts Jenkins or GitLab CI.

[0057] When applied, the pytest framework provides the functions of writing, collecting and running test cases. It is responsible for loading, organizing and dynamically scheduling test cases (such as prioritizing the execution of core module cases based on the Critical Path Weighting algorithm), and generating test reports. The Playwright engine, as a browser automation tool, supports cross-browser testing, including Chromium, Firefox and WebKit. The Playwright engine is called by pytest to perform end-to-end testing, simulate user cross-browser operations (such as PLM system interaction processes), and verify UI consistency and functional integrity. The continuous integration engine (such as Jenkins / GitLab CI) monitors code changes, pulls the latest code from the repository, automatically builds the environment and triggers pytest to execute test tasks (including unit tests, interface tests and Playwright scripts), and finally summarizes the test results and provides feedback.

[0058] Example 11: The basic content is the same as Example 1, except that: in the fifth step, starting the standardized image to deploy the test environment means: building a test environment based on the PLM system to be tested, and then using containerization technology to encapsulate the test environment into a standardized image. During testing, starting the standardized image to automatically deploy the test environment.

[0059] During application, first, based on the requirements of the PLM system version to be tested, a test environment is established, and the dependencies required for testing are clarified (such as Python version, browser driver, database). A Dockerfile is written based on the official base image, and system tools (such as Chrome, chromedriver), Python libraries (through requirements.txt), and test code are installed layer by layer. Subsequently, the image is built and the functional integrity is verified (such as running test cases). The volume is optimized through multi-stage building or Alpine image, and finally pushed to the private repository, thus achieving one-click deployment and cross-environment reuse, ensuring the consistency, isolation, and rapid expansion ability of the test environment. When using it, start the standardized Docker image, which automatically loads the dependencies required for the PLM system test environment. Before each test, just start the standardized Docker image to automatically deploy the test environment and load the required dependencies, without the need to repeatedly configure the test environment, significantly improving the test efficiency and reducing the complexity of environment setup. At the same time, it ensures that the test environment is configured the same as the production environment, avoiding test failures caused by environmental differences. In this invention, according to the specific requirements and business logic of the PLM system, the containerized image is deeply customized to ensure that the image can accurately match the test requirements of the PLM system. The customized image contains components such as PLM test instances, Playwright runtime, and browser drivers, supporting the stable operation of Playwright in specific browser versions and operating systems. During the test process, the resource allocation and expansion ability of the containerized test environment are dynamically adjusted according to actual needs. The containerized image is bound to a specific version of the PLM system, and the PLM system version is specified through environment variables or configuration files, supporting parallel testing of multiple versions, facilitating the rapid verification of different versions of the PLM system. In addition, through different configurations of the Docker image (such as Windows / Linux base images, different browser versions), cross-platform and cross-browser testing are achieved, ensuring the compatibility and stability of the PLM system in various environments. The containerized encapsulation of the PLM system test environment not only improves the test efficiency and environmental consistency but also provides strong technical support for rapid iterative development.

[0060] Example 12: The basic content is the same as that of Example 1, except that in the fifth step, if the test case is interrupted and not completed, the test environment, network, and test script are checked and repaired. After repair, the test case is re-executed until all test cases are completed and a structured report is generated.

[0061] When applying, the interruption and incomplete execution of test cases are usually caused by abnormalities in the test environment, script or network. In terms of the test environment, insufficient hardware resources or incorrect environment configuration may cause the system to fail to start or the script to run. The test script may not be able to execute the test case smoothly due to writing defects, compatibility issues or abnormal test data. Network abnormalities may also cause test interruptions. At this time, it is necessary to check the test environment, test scripts, and network environment, and repair them after finding the abnormalities. After repair, re-execute the test until the test case is fully executed.

[0062] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by ordinary technicians in this field based on the contents disclosed in the present invention should be included in the protection scope recorded in the claims.

Claims

1. A rapid iterative testing method based on a PLM system, characterized by: The rapid iterative testing method comprises the following steps: Step 1: First, divide the system into non-functional modules and functional modules based on the core business processes of the PLM system to be tested. Then, decouple the functional modules by functional domain to form several independent test modules. Step 2: Develop test plans for the independent test modules and non-functional modules, including test type, test scope, and acceptance criteria. At the same time, a dynamic resource allocation algorithm is used to calculate the test weight of each independent test module, and test resources are allocated to the independent test modules based on the test weight. Step 3: According to the above test plan, write test cases for the above independent test modules and non-functional modules to obtain several test cases; Step 4: First, write a test script based on the above test cases, and then build a continuous automated test chain based on the test script; Step 5: First, start the standardized image deployment test environment. In this test environment, the above-mentioned continuous automated test chain automatically pulls the PLM system code and executes the test cases in the above-mentioned test scripts. After the test cases are executed, a structured test report is automatically generated. The structured test report includes the test case pass rate; Step 6: If the pass rate of the test cases meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases does not meet the above acceptance criteria, a defect report is generated, and the PLM system code is repaired according to the defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated; if the pass rate of the test cases in the new structured test report meets the above acceptance criteria, the rapid iterative test is completed; if the pass rate of the test cases in the new structured test report does not meet the above acceptance criteria, the following process is repeated to generate a new defect report, and the PLM system code is repaired again according to the new defect report, and the repaired PLM system code is submitted. The continuous automated test chain automatically pulls the repaired PLM system code and executes the test cases in the above test script. After the test cases are executed, a new structured test report is automatically generated until the pass rate of the test cases meets the above acceptance criteria and the rapid iterative test is completed.

2. The rapid iterative testing method based on a PLM system according to claim 1, characterized in that: In the first step, the core business process of the PLM system to be tested refers to: first, dynamically collecting, screening, sorting, responding to and executing customer needs through a demand response funnel mechanism to obtain a priority demand list; then, based on the priority demand list and combined with the business logic of the PLM system, analyzing customer needs and identifying the core business process of the PLM system to be tested.

3. The rapid iterative testing method based on a PLM system according to claim 1, characterized in that: In the first step, decoupling the functional modules from their functional domains to form several independent test modules involves first confirming the PLM business logic based on customer requirements, then decoupling the functional modules from their functional domains based on the PLM business logic to obtain several independent test modules, where each independent test module corresponds to a business functional domain and has independent testing and verification capabilities. The PLM business logic includes material management, BOM changes, file management, document management, design tool collaboration, process management, and project management.

4. The rapid iterative testing method based on a PLM system according to claim 1, characterized in that: In the second step, the use of a dynamic resource allocation algorithm to calculate the test weight of each independent test module and allocate test resources to the independent test modules according to the test weight refers to: using a Critical Path Weighting algorithm, based on the critical path, business complexity, risk and customer weight of each independent test module, a comprehensive score is calculated through a quantitative model, and the weight of each independent test module is dynamically adjusted to allocate test resources.

5. The rapid iterative testing method based on a PLM system according to claim 1, characterized in that: In the fourth step, writing a test script according to the test case refers to writing a test script according to the operation steps and expected results of the test case; In the fourth step, building a continuous automated test chain based on the test script means integrating an automated test framework, an end-to-end test tool, and a continuous integration engine through the test script to form a continuous automated test chain.

6. The rapid iterative testing method based on a PLM system according to claim 5, characterized in that: In the fifth step, the continuous automated testing chain automatically pulls the PLM system code and executes the test cases in the above test script, which means that: the continuous integration engine in the continuous automated testing chain automatically pulls the PLM system code and triggers the test process, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases of the PLM system interaction scenario.

7. The rapid iterative testing method based on a PLM system according to claim 5, characterized in that: In the fifth step, automatically generating a structured test report after the test case is executed means: connecting the Allure reporting system with the continuous automated testing chain, and automatically generating a structured report through the Allure reporting system after the test case is executed.

8. The rapid iterative testing method based on a PLM system according to claim 5, characterized in that: In the sixth step, generating a defect report includes: connecting the Jira ticket system with the continuous automated testing chain and the Git repository, and automatically generating a Jira ticket for the test case that failed to be executed through the Jira ticket system; the Jira ticket describes the specific problem of the test failure, and the test case that failed to be executed refers to the test case whose actual test result does not match the expected result of the test case; In the sixth step, repairing the PLM system code according to the defect report and then submitting the repaired PLM system code means that after the developer locates the problem according to the Jira work order, he repairs the PLM system code and then submits the repaired PLM system code to the Git repository; In the sixth step, the continuous automated testing chain automatically pulls the repaired PLM system code and executes the test cases in the above test script, which means that after the repaired PLM system code is submitted to the Git repository, the continuous integration engine in the continuous automated testing chain automatically pulls the repaired PLM system code and triggers regression testing, and the automated testing framework in the continuous automated testing chain calls the test script and automatically executes the test cases in the test script. During this process, the automated testing framework calls the end-to-end testing tool, simulates user cross-browser operations, and executes test cases for PLM system interaction scenarios.

9. A rapid iterative testing method based on a PLM system according to any one of claims 5 to 8, characterized in that: The automated testing framework adopts the pytest framework, the end-to-end testing tool adopts the Playwright engine, and the continuous integration engine adopts Jenkins or GitLab CI.

10. The rapid iterative testing method based on a PLM system according to claim 1, characterized in that: In the fifth step, starting the standardized image to deploy the test environment means: building a test environment based on the PLM system to be tested, then using containerization technology to encapsulate the test environment into a standardized image, and starting the standardized image to automatically deploy the test environment during testing.

Images