Chip test management method, device, equipment, storage medium and program product

Abstract

The application relates to a chip test management method, device, equipment, storage medium and program product. The method comprises the following steps: in response to a document generation request for a target chip, acquiring a first requirement document of the target chip; based on the first requirement document and a reference test management document, generating a target test management document corresponding to the target chip; wherein the reference test management document is a test management document of a related product of the target chip; the target test management document comprises a test coverage strategy of each to-be-tested requirement point of the target chip, and the target test management document is used for guiding generation of a test case of the target chip. The method can improve the accuracy of the test case.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a chip testing management method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of internet technology and software development technology, software products are becoming increasingly complex and their iteration pace is accelerating, making the software testing phase increasingly important in the entire product development process.

[0003] Currently, in order to improve the efficiency of testing, artificial intelligence and large language model technology are being introduced to try to automatically parse and generate test cases from requirements documents.

[0004] However, the above approach skips the overall design and strategic planning of the testing work, directly generating single or batch test cases from scattered requirement descriptions. It lacks a unified constraint of the top-level test coverage strategy, resulting in low accuracy of the generated test cases. Summary of the Invention

[0005] Therefore, it is necessary to provide a chip test management method, device, equipment, storage medium, and program product that can improve the accuracy of test cases in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a chip test management method, including:

[0007] In response to a document generation request for the target chip, a first requirements document for the target chip is obtained;

[0008] Based on the first requirement document and the reference test management document, a target test management document corresponding to the target chip is generated; wherein, the reference test management document is the test management document of the relevant products of the target chip; the target test management document includes the test coverage strategy for each test requirement point of the target chip, and the target test management document is used to guide the generation of test cases for the target chip.

[0009] In one embodiment, generating the target test management document corresponding to the target chip based on the first requirements document and the reference test management document includes:

[0010] Extract the requirement points from the first requirement document to obtain each test requirement point of the target chip.

[0011] The reference test management document is parsed to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product; wherein, the test coverage strategy for each reference requirement point includes the test type of the corresponding reference requirement point;

[0012] Based on the test coverage strategy for each of the aforementioned test requirements, the chapter structure data, and each of the aforementioned reference requirements, a target test management document corresponding to the target chip is generated.

[0013] In one embodiment, based on the test coverage strategy for each of the test requirements, the chapter structure data, and each of the reference requirements, a target test management document corresponding to the target chip is generated, including:

[0014] Based on the test coverage strategy for each of the reference requirement points, determine the test coverage strategy for each of the requirement points to be tested.

[0015] Based on the chapter structure data, each of the test requirements and the corresponding test coverage strategy, a target test management document corresponding to the target chip is generated.

[0016] In one embodiment, the step of extracting requirement points from the first requirement document to obtain each test requirement point of the target chip includes:

[0017] Based on the first prompt template and the first requirement document, a first prompt text is constructed; the first prompt template includes extraction rules and output format;

[0018] The first prompt text is input into the extraction model to extract the demand points, thus obtaining each demand point to be tested.

[0019] In one embodiment, the method further includes:

[0020] For each requirement to be tested, the test case set is retrieved based on the test coverage strategy of the requirement to be tested, and the retrieval results are obtained.

[0021] Based on the search results, test cases are determined for the requirement points to be tested.

[0022] In one embodiment, determining the test cases for the requirement point to be tested based on the search results includes:

[0023] If the search results indicate that a target test case has been found, the target test case shall be used as the test case for the requirement point to be tested; wherein, the target test case is the test case required to test the requirement point to be tested.

[0024] In one embodiment, determining the test cases for the requirement point to be tested based on the search results includes:

[0025] If the search results indicate that the target test case was not found, test cases for the requirement point to be tested are determined based on the requirement content of the requirement point to be tested.

[0026] In one embodiment, determining the test cases for the requirement point to be tested based on its requirement content includes:

[0027] Based on the requirements of the requirement points to be tested, generate test cases for the requirement points to be tested; or...

[0028] Based on the requirements of the requirement point to be tested, the test cases in the test case set that are similar to the target test case are modified to obtain the test cases for the requirement point to be tested.

[0029] In one embodiment, the method further includes:

[0030] If an update to the requirements document for the target chip is detected, obtain the latest version of the second requirements document;

[0031] The first requirement document and the second requirement document are semantically compared to obtain the change requirement points included in the second requirement document.

[0032] Based on the aforementioned change requirements, the target test management document is updated to obtain the latest version of the test management document.

[0033] In one embodiment, the target test management document includes acceptance information for each test requirement of the target chip; the method further includes:

[0034] If the target chip's functionality meets the pre-acceptance conditions, then based on the functional design document, extract each candidate acceptance point for that function.

[0035] Based on the acceptance information of the test requirement points corresponding to the function, a target acceptance point is selected from each candidate acceptance point; wherein, the target acceptance point is used to accept the function.

[0036] In one embodiment, obtaining a first requirement document for the target chip in response to a document generation request for the target chip includes:

[0037] In response to a document generation request for the target chip, an initial requirements document for the target chip is obtained;

[0038] Based on the second prompt template and the initial requirements document, a second prompt text is constructed; the second prompt template includes multiple document evaluation items;

[0039] The second prompt text is input into the evaluation model to perform document evaluation, and the evaluation result is obtained.

[0040] The initial requirements document is adjusted based on the evaluation results to obtain the first requirements document.

[0041] Secondly, this application also provides a chip test management device, comprising:

[0042] The acquisition module is used to acquire a first requirement document for the target chip in response to a document generation request for the target chip.

[0043] The generation module is used to generate a target test management document corresponding to the target chip based on the first requirement document and the reference test management document; wherein, the reference test management document is the test management document of the relevant products of the target chip; the target test management document includes the test coverage strategy for each test requirement point of the target chip, and the target test management document is used to guide the generation of test cases for the target chip.

[0044] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the various method embodiments provided in the first aspect above.

[0045] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the various method embodiments provided in the first aspect above.

[0046] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the various method embodiments provided in the first aspect above.

[0047] The aforementioned chip test management method, apparatus, device, storage medium, and program product, in response to a document generation request for a target chip, obtains a first requirement document for the target chip, and generates a target test management document corresponding to the target chip based on the first requirement document and a reference test management document. Since the reference test management document is the test management document for related products of the target chip, generating the target test management document based on the reference test management document ensures the accuracy of the target test management document and improves document generation efficiency. Furthermore, since the target test management document includes the test coverage strategy for each test requirement point of the target chip, when using the target test management document to guide test case generation, the coverage of test cases can be effectively constrained, improving the accuracy of test cases. Therefore, testing based on test cases improves the accuracy of test results. Attached Figure Description

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

[0049] Figure 1 This is an internal structural diagram of a computer device in one embodiment;

[0050] Figure 2 This is a flowchart illustrating a chip test management method in one embodiment;

[0051] Figure 3 This is a schematic diagram illustrating how the target test management document is generated in one embodiment;

[0052] Figure 4 This is a schematic diagram of a document update method in one embodiment;

[0053] Figure 5 This is a schematic diagram of a demand deferral method in one embodiment;

[0054] Figure 6 This is a schematic diagram of the structure of six nodes in one embodiment;

[0055] Figure 7 This is a schematic diagram of the structure of a document generation system in one embodiment;

[0056] Figure 8 This is a flowchart illustrating the chip test management method in another embodiment;

[0057] Figure 9 This is a structural block diagram of a chip test management device in one embodiment. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0059] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0060] With the rapid development of internet technology and software development technology, software products are becoming increasingly complex and their iteration pace is accelerating, making the software testing phase increasingly important in the entire product development process.

[0061] Currently, in order to improve the efficiency of testing, artificial intelligence and large language model technology are being introduced to try to automatically parse and generate test cases from requirements documents.

[0062] However, the above approach skips the overall design and strategic planning of the testing work, directly generating single or batch test cases from scattered requirement descriptions. It lacks a unified constraint of the top-level test coverage strategy, resulting in low accuracy of the generated test cases.

[0063] Based on this, this application proposes a chip test management method, apparatus, device, storage medium, and program product. In response to a document generation request for a target chip, it obtains a first requirement document for the target chip and generates a target test management document corresponding to the target chip based on the first requirement document and a reference test management document. Since the reference test management document is the test management document for related products of the target chip, generating the target test management document based on the reference test management document ensures the accuracy of the target test management document and improves document generation efficiency. Furthermore, since the target test management document includes the test coverage strategy for each test requirement point of the target chip, when guiding test case generation through the target test management document, the coverage of test cases can be effectively constrained, improving the accuracy of test cases. Therefore, testing based on the test cases improves the accuracy of the test results.

[0064] The chip test management method provided in this application can be applied to computer equipment, which can be a terminal or a server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0065] Optionally, the chip test management method provided in this application embodiment can be applied to a computer device or an application for software testing, or the chip test management method provided in this application embodiment can be applied to a controller on a chip test management device; the application or controller responds to a document generation request for a target chip, obtains a first requirement document for the target chip; and generates a target test management document corresponding to the target chip based on the first requirement document and a reference test management document.

[0066] In an exemplary embodiment, taking the application of this chip test management method to a server as an example, its internal structure diagram can be as follows: Figure 1 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores documents. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a chip test management method.

[0067] Those skilled in the art will understand that Figure 1The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0068] In one exemplary embodiment, such as Figure 2 As shown, a chip test management method is provided. Taking the application of this method to a server as an example, it includes:

[0069] S201, in response to a document generation request for the target chip, obtain the first requirement document for the target chip.

[0070] The document generation request is used to request the server to generate test management documents for the target chip. Optionally, the document generation request can be sent from the terminal to the server; for example, the terminal generates a document generation request in response to a user's trigger operation and sends it to the server. The requirements document refers to the document used during product development to record the product design basis, such as product functions, performance, and interfaces. The first requirements document refers to the requirements document for the target chip. For example, the first requirements document could be the requirements document for version 14.0 of the target chip.

[0071] S202, based on the first requirements document and the reference test management document, generate the target test management document corresponding to the target chip.

[0072] The reference test management document refers to the test management document for related products of the target chip. These related products can have the same or similar functions as the target chip. In one embodiment, the target chip and related products belong to different product lines of the same product. The inference graphics processing unit (GPU) supports three product forms: desktop workstations, laptops, and embedded modules. These three product forms share the same GPU driver and operating system foundation, but differ in power management, thermal design, and interface form. The target chip can be an inference graphics processor for the desktop workstation product form, and the related products can be inference graphics processors for the laptop product form. It is understood that the reference test management document is used to guide the generation of test cases for related products. Therefore, to generate the target test management document, the reference test management document can be used as a reference to reduce repetitive work. The driving mechanism of the reference test management document allows the test management document structure and coverage strategy of related product lines to be mutually referenced. In multi-product-line parallel scenarios, the document generation time for subsequent product lines can be further shortened.

[0073] The target test management document includes a test coverage strategy for each requirement point under test of the target chip. The test coverage strategy describes the types of tests required to be performed on each requirement point under test, including functional testing, performance testing, regression testing, stability testing, and compatibility testing. It is understood that during the update and iteration process of the target chip, there are usually multiple versions. Each version of the target chip needs to be tested before delivery. For a requirement point under test, the types of tests required may differ across versions. The target test management document guides the generation of test cases for the target chip. Each version of the target chip corresponds to a specific target test management document, which can be generated using the chip test management method described in this application. Clearly defining the types of tests required to be performed on the target chip through the test coverage strategy improves the accuracy of subsequent test case generation.

[0074] Optionally, the target test management documentation includes one or more of the following:

[0075] (1) Sign-off form, used to record the review and approval status of work nodes by relevant responsible persons in the development and testing work;

[0076] (2) Test Scope includes a list of product models, a list of reference documents, and a list of peripherals (used to clearly distinguish between within and outside the test scope);

[0077] (3) The core chapter (Test Strategy) includes the Requirements Acceptance matrix (the module / priority / requirement description / test coverage / status / requirement test report / remarks corresponding to each requirement to be tested); test coverage tags; admission and exit conditions; test case change list (a list of test cases added / adjusted in this version);

[0078] Optionally, test coverage tags are divided into four hierarchical levels, L0-L3, to indicate at which test level the requirement to be tested is verified. Specifically, L0 level test coverage tags ensure the availability of the core path, with test cases covering functional tests, executed daily, and triggered immediately after code submission; L1 level test coverage tags cover major functionalities, with test cases covering both functional and installation tests, executed before release, and triggered after L0 level tests pass; L2 level test coverage tags are used for comprehensive verification, with test cases covering all test cases, executed at milestone nodes, and triggered after L1 level tests pass; L3 level test coverage tags ensure stability and performance, with test cases covering stability and performance tests, executed before release, and triggered after L2 level tests pass. By mapping each requirement to a test coverage strategy, combined with a function × test level coverage matrix, the scope of test coverage becomes clearer.

[0079] (4) The milestone schedule includes the phase name, target date, activity description, and eligibility criteria;

[0080] (5) Manpower estimation table, differentiated by test type and hardware and software environment requirements;

[0081] (6) The risk assessment form includes the risk category (equipment / process / upgrade / human resources), impact level, probability, and mitigation measures;

[0082] (7) Test report, report framework for each test round (initially blank, to be filled in for each subsequent round).

[0083] By generating a complete test management document that includes a sign-off sheet, requirement acceptance matrix, coverage strategy, scheduling, and risk assessment, it can be directly used as a work guide for the test team without the need for additional manual compilation.

[0084] In the above method, in response to a document generation request for the target chip, a first requirement document for the target chip is obtained, and a target test management document corresponding to the target chip is generated based on the first requirement document and a reference test management document. Since the reference test management document is the test management document for related products of the target chip, generating the target test management document based on the reference test management document ensures the accuracy of the target test management document and improves document generation efficiency. Furthermore, since the target test management document includes the test coverage strategy for each test requirement point of the target chip, the coverage of test cases can be effectively constrained when test case generation is guided by the target test management document, improving the accuracy of test cases. Therefore, testing based on test cases improves the accuracy of test results.

[0085] In one embodiment, the step of obtaining the first requirements document for the target chip in S201 is further defined, including:

[0086] S301, in response to a document generation request for the target chip, obtains the initial requirements document for the target chip.

[0087] The initial requirements document refers to the unfinalized version of the requirements document, such as a draft requirements document. By improving and updating the initial requirements document, the first requirements document can be obtained.

[0088] S302, Based on the second prompt template and the initial requirements document, construct the second prompt text.

[0089] The second prompt template includes multiple document evaluation items, each used to evaluate different aspects of the initial requirements document. For example, the second prompt template may include four document evaluation items: structural integrity evaluation, requirement testability evaluation, cross-version consistency evaluation, and text quality evaluation. The structural integrity evaluation item assesses the continuity of requirement identifiers, the responsible party's information, the identification of associated development tasks, the clarity of priorities, and the completeness of version numbers. The requirement testability evaluation item assesses whether each requirement point to be tested can have pass / fail conditions, unambiguous descriptions, and quantifiable baselines for performance requirements. The cross-version consistency evaluation item assesses whether the document version number matches the item version number and whether delayed requirements have target versions and supporting documents. The text quality evaluation item assesses typos and redundant information.

[0090] S303, input the second prompt text into the evaluation model to perform document evaluation and obtain the evaluation result.

[0091] The evaluation model is used to evaluate the input requirement document according to the aforementioned document evaluation items. The evaluation model can be a deep learning-based neural network model or a large language model; no specific limitation is made here. Optionally, the evaluation model can also indicate whether each document evaluation item passes or fails, and identify specific problems.

[0092] S304, based on the evaluation results, adjust the initial requirements document to obtain the first requirements document for the target chip.

[0093] Optionally, the initial requirements document can be adjusted based on the issues identified in the evaluation results to obtain a first requirements document. This first requirements document can then be used as the basis for approval and review.

[0094] In the above embodiments, the initial requirement document is evaluated and adjusted by the evaluation model to obtain the first requirement document, which can improve the generation efficiency and accuracy of the first requirement document.

[0095] In an exemplary embodiment, step S202, which generates the target test management document corresponding to the target chip, can be implemented as follows:

[0096] S401, extract the requirement points from the first requirement document to obtain each test requirement point of the target chip.

[0097] The requirements to be tested are independent, verifiable functional or non-functional requirements in the first requirements document. Optionally, the first requirements document can be parsed to obtain multiple requirements to be tested, so that each requirement can be comprehensively tested during the testing process.

[0098] S402, parse the reference test management document to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product.

[0099] The chapter structure data from the reference test management document can be used to construct the chapter structure of the target test management document. The test coverage strategy includes the test types corresponding to the reference requirement points, such as the trigger conditions and coverage depth for each test type. It is understandable that, since the target chip's functionality is related to that of related products, the functions corresponding to the reference requirement points and the requirement points under test are usually also related. Therefore, the test coverage strategy for the reference requirement points can provide a reference for the test coverage strategy for the requirement points under test. Additionally, the scheduling milestone format from the reference test management document can be extracted for test phase division, etc.

[0100] S403 generates the target test management document corresponding to the target chip based on the test coverage strategy for each test requirement, chapter structure data, and each reference requirement.

[0101] Optionally, prompt text is constructed based on the test coverage strategy for each test requirement, chapter structure data, and each reference requirement. This prompt text is then input into a large language model for document generation, outputting the target test management document. The prompt template embeds priority determination rules, team standard structure requirements, and test case writing format specifications to ensure consistent document format across different test engineers.

[0102] In the above embodiments, the generated target test management document contains the test requirements points in the first requirement document, providing comprehensive coverage of the target chip's requirements points. It can generate test cases that comprehensively cover the target chip's requirements points based on the target test management document, thus improving the comprehensiveness of test cases. By generating the target test management document based on the chapter structure data and test coverage strategy of the reference test management document, the repetitive workload can be reduced, the document generation efficiency can be improved, and the document generation can be constrained based on the reference test management document, thereby improving the accuracy of document generation.

[0103] In an exemplary embodiment, step S401, which involves extracting the requirement points to be tested, can be implemented as follows:

[0104] Based on the first prompt template and the first requirement document, the first prompt text is constructed; the first prompt text is input into the extraction model to extract the requirement points, and each test requirement point of the target chip is obtained.

[0105] The first prompt template includes extraction rules and an output format. Extraction rules can include functional requirements (visible functionalities for each user), interface requirements (interface name, command-line parameters, configuration items), constraints (performance metrics, compatibility requirements, platform support), exception scenarios (error handling, degradation strategies), and implicit requirements (not explicitly stated in the requirements document but implied in the context, marked as "implicit"). The output format can be a list of requirements grouped by feature / module, with each item including a requirement identifier, description, type (functionality / performance / compatibility / security), priority (P1 / P2 / P3), and the section from which the requirements document originated. Optionally, the first prompt template also includes product difference annotations, indicating whether each test requirement is unique to the target chip or shared with related products. The extraction model can be a deep learning-based neural network model or a large language model; no specific limitations are made here. Optionally, the first prompt template also includes a role definition, such as "You are a test engineer, skilled at extracting testable requirements from requirements documents." This role definition instructs the extraction model on the tasks to be performed, thereby improving the accuracy of requirement extraction.

[0106] In the above embodiments, requirement points are extracted based on the extraction model, and role definitions, extraction rules, and output format constraints are performed in the first prompt template to avoid model illusion and improve the accuracy of requirement point extraction.

[0107] In an exemplary embodiment, the step of S403 generating the target test management document corresponding to the target chip can be implemented as follows:

[0108] Based on the test coverage strategy for each reference requirement point, determine the test coverage strategy for each requirement point to be tested; based on the chapter structure data, each requirement point to be tested and the corresponding test coverage strategy, generate the target test management document corresponding to the target chip.

[0109] Optionally, for each requirement point to be tested, based on the correlation between the requirement description of the requirement point to be tested and the requirement descriptions of different reference requirement points, the reference requirement point corresponding to the requirement point to be tested is determined, and based on the test coverage strategy of the corresponding reference requirement point, the test coverage strategy of the requirement point to be tested is determined.

[0110] Among them, the reference requirement point corresponding to the requirement point to be tested can be the reference requirement point with the highest relevance to the requirement point to be tested. For example, the requirement description of the requirement point to be tested and the requirement description of the reference requirement point are mapped to the same semantic space to obtain the vector to be tested and the reference vector, and the cosine similarity between the vector to be tested and the reference vector is determined. The reference requirement point with the highest cosine similarity is then matched with the reference requirement point with the highest relevance to the requirement point to be tested.

[0111] Optionally, if the relevance of the reference requirement point with the highest relevance is greater than the relevance threshold, the test coverage strategy of the reference requirement point is used as the test coverage strategy for the requirement point under test. If the relevance of the reference requirement point with the highest relevance is not greater than the relevance threshold, the test coverage strategy of the reference requirement point is adjusted based on the requirement description of the requirement point under test to generate the test coverage strategy for the requirement point under test. The relevance threshold can be set based on experience, multiple trials, and actual needs.

[0112] In addition, regarding the coverage strategy for the requirements to be tested, the test coverage strategy can be shown to the test engineers for confirmation. After confirmation, the target test management document can be generated. The content shown to the test engineers for confirmation may include: whether this version includes stability testing, whether there is a quantified baseline for performance testing, the operating system / hardware matrix coverage of compatibility testing, and how to handle requirements that exceed the current resource scope (downgrade priority / not cover and mark the risk).

[0113] In the above embodiments, determining the test coverage strategy for the requirement points to be tested based on the test coverage strategy of the reference requirement points can improve the accuracy of the test coverage strategy, reduce repetitive workload, and thus improve the generation efficiency and accuracy of the target test management document.

[0114] like Figure 3 The diagram illustrates how the target test management document is generated. Inputting a first requirement document and a reference test management document, multiple test requirements are extracted from the first requirement document. The reference test management document is parsed to obtain chapter structure data and test coverage strategies for the test requirements. After the test engineer confirms the determined test coverage strategy, the target test management document is generated based on the multiple test requirements, chapter structure data, and test coverage strategies.

[0115] In one embodiment, the generated target test management document is saved to the local cache, and the Confluence interface is called to push the document to the specified Confluence page.

[0116] In an optional embodiment, for each requirement to be tested, the test case set is retrieved based on the test coverage strategy of the requirement to be tested to obtain the retrieval results; and the test cases for the requirement to be tested are determined based on the retrieval results.

[0117] The test case set includes a large number of generated test cases. Each test case in the set includes fields such as test case number, module path, title, priority, and type. The test case retrieval process primarily involves checking if there are available test cases for the requirement to be tested. Based on the test coverage strategy for the requirement to be tested, the test content for that requirement can be determined, and then available test cases can be retrieved from the test case set. If available test cases are found, they are directly used as test cases for the requirement to be tested; otherwise, test cases for the requirement to be tested need to be regenerated. Optionally, in addition to retrieving test cases based on the test coverage strategy for the requirement to be tested, the retrieval can also be performed by combining the requirement content and the test coverage strategy for the requirement to be tested, thereby improving the accuracy of the retrieval results.

[0118] In the above embodiments, by retrieving available test cases for the requirements to be tested from the test case set, the repetitive workload of generating test cases can be reduced and the efficiency of test case generation can be improved.

[0119] In an optional embodiment, the step of determining test cases for the requirement points to be tested based on different search results can be implemented in the following two ways:

[0120] (1) If the search results indicate that the target test case has been found, the target test case shall be used as the test case for the requirement point to be tested.

[0121] In this context, target test cases are the test cases required to test the requirements to be tested. It's important to note that target test cases are not predetermined. Based on the requirements to be tested, the content and characteristics of the target test cases can be clearly defined. This allows us to determine whether the retrieved test cases are indeed target test cases. By retrieving the test case set and directly using target test cases as the test cases for the requirements to be tested, the efficiency of test case generation is significantly improved.

[0122] (2) If the search results indicate that no target test case was found, the test case for the requirement point to be tested is determined based on the requirement content of the requirement point to be tested.

[0123] Understandably, if no target test case is found, it indicates that there are no directly usable existing test cases in the test case set. In this case, test cases need to be generated based on the requirements of the requirement to be tested. For example, new test cases can be generated directly based on the requirements; alternatively, existing test cases in the test case set can be modified based on the requirements. It should be noted that the above method of determining test cases for the requirement to be tested based on the requirements is only an example. The specific method can be set according to actual needs, and no specific limitation is made here.

[0124] In one embodiment, test cases for the requirement to be tested are generated based on the requirement content of the requirement to be tested, or test cases similar to the target test cases in the test case set are modified based on the requirement content of the requirement to be tested to obtain test cases for the requirement to be tested.

[0125] For example, based on the requirements of the point to be tested, a prompt text is generated and input into a large language model, which then generates test cases for the point to be tested. As another example, based on the requirements of the point to be tested and test cases similar to the target test cases, a modification prompt text is generated, and prompt words are added to the modification prompt text to instruct the large language model to modify the test cases similar to the target test cases according to the requirements, thereby generating test cases.

[0126] Optionally, based on the requirements and test coverage strategies of the requirements to be tested, a test case set can be retrieved. The results can be categorized into three cases: ① All test cases required for the requirements to be tested are retrieved; ② Similar test cases need to be modified; ③ Test cases need to be regenerated. For case ③, a test case outline can be provided through a large language model: module / title / priority / coverage points, thereby improving the efficiency of test case generation.

[0127] In the above embodiments, different methods of determining test cases for the requirements to be tested are determined based on different retrieval results of the test case set, which can make full use of existing test cases and improve the efficiency of test case generation.

[0128] In an optional embodiment, if a version update is detected in the requirements document of the target chip, the latest version of the second requirements document is obtained; the first requirements document and the second requirements document are semantically compared to obtain the changed requirements points included in the second requirements document; based on the changed requirements points, the target test management document is updated to obtain the test management document corresponding to the latest version.

[0129] Understandably, during the iteration process of the target chip, the requirements document will also be updated. Based on these updated requirements document versions, the target test management document also needs to be updated. Therefore, a semantic comparison can be performed between the first and second requirements documents to identify changed requirements, and the target test management document can be updated accordingly.

[0130] Optionally, firstly, extract the target fields for each requirement point from both the first and second requirement documents, using them as indexes for the requirement points. Then, compare the indexes of the requirement points in both versions line by line to identify semantic changes, designating them as changed requirement points. For these changed requirement points, use a large language model to assess their impact on the target test management document, outputting an impact assessment matrix. Present the changed requirement points and the impact assessment matrix to the test engineers. Mark the changed requirement points as required, await confirmation, and then perform an incremental update on the existing target test management document. Finally, overwrite the locally cached first requirement document with the second requirement document, using it as the baseline version for the next change detection.

[0131] The target fields may include a requirement identifier, a requirement version number field (indicating which product version the requirement belongs to), a requirement priority field, a requirement description text, and a responsible person (PIC) field.

[0132] The semantic changes that need to be identified can include the following five categories: (1) New requirements: Requirements that exist in the second requirement document but not in the first requirement document; (2) Requirement removal: Requirements that exist in the first requirement document but not in the second requirement document. This type of change is further distinguished as follows: If the version number field of the requirement in the second requirement document points to a higher version number, the semantic is "delayed to the target version"; if the requirement completely disappears in the second requirement document and there is no version field associated with it, the semantic is "requirement cancellation", marked as pending confirmation, and the change nature is output for the test engineer to confirm; (3) Requirement content modification: The requirement exists in two versions, but the requirement description text changes. Evaluate whether the modification affects the test coverage strategy; (4) Priority change: The priority field of the requirement changes from one value to another. Evaluate whether the test resource allocation needs to be adjusted; (5) Version number change: The version number field of the requirement changes from the target version to blank, or from blank to the target version.

[0133] By using semantic-level change detection based on requirement identifiers, the time for recognizing requirement document version changes is reduced to minutes for automatic analysis. It can also accurately distinguish different semantic types such as requirement delays, requirement cancellations, and content modifications, thus avoiding misjudgments.

[0134] The impact assessment matrix can include change identifier, change type, affected section, impact level, and recommended actions. When performing incremental updates to the target test management document based on the confirmed change list: for new requirements: add an entry to the requirement acceptance matrix; for delayed requirements: mark "Moved to target version, not overwritten in this version" in the current version; for cancelled requirements: delete the corresponding entry in the requirement acceptance matrix and record the reason; for content modifications: update the corresponding test scope and status fields; for priority changes: adjust the corresponding priority fields and reassess test resource allocation.

[0135] like Figure 4 The diagram illustrates the document update method. It involves obtaining a first requirement document and a second requirement document, semantically comparing the second requirement point in the second requirement document with the corresponding first requirement point to determine whether the second requirement point is a change requirement point, and updating the target test management document according to the change type of the change requirement point to obtain the latest version of the test management document.

[0136] When a requirement is delayed, a cross-version workflow mechanism is triggered. It checks if a draft requirement document for the target version exists locally. If not, a draft framework file is created, and the delayed requirement entry is added to the requirement acceptance matrix within the draft framework file, indicating its source. Once the target version's requirement document is officially released, it checks whether the draft entry has been overwritten by the official requirement document, achieving closed-loop tracking. This cross-version workflow mechanism establishes a two-way traceability link, preventing requirements from being lost between versions.

[0137] like Figure 5 The diagram illustrates the requirement deferral method. If requirement 2 in the first requirement document is deferred, requirement 2 is added to the draft of the second requirement document. During the development process, new requirements are continuously added to the draft of the second requirement document, eventually resulting in the second requirement document.

[0138] In the above embodiments, when there are version updates to the requirements document, by performing semantic comparison on different versions of the requirements document, identifying the changed requirements, and incrementally updating the target test management document, the document update efficiency can be improved.

[0139] In one embodiment, if the function of the target chip is detected to meet the pre-acceptance conditions, each candidate acceptance point of the function is extracted based on the function's design document; and the target acceptance point is selected from each candidate acceptance point based on the acceptance information of the test requirement points corresponding to the function.

[0140] The target acceptance points are used to accept the functionality. Acceptance preconditions can be set according to actual conditions; for example, a precondition could be that the functionality passes self-testing on the main branch. The design document records the technical means broken down by the development engineers to implement the functionality. Candidate acceptance points can include functional points, quantifiable indicators, boundary conditions, etc. The target test management document includes acceptance information for each test requirement of the target chip. The acceptance information for each requirement includes information that enables acceptance of the requirement, such as the corresponding module and requirement description. It is understandable that, since the design document is generated from a development perspective, its content may differ from the corresponding requirement document. All extracted candidate acceptance points may not be acceptable in the current version of the target chip. Therefore, it is necessary to select target acceptance points that can be accepted in the current version from the candidate acceptance points based on the acceptance information of the test requirement.

[0141] Optionally, if the development engineer notifies that the function has passed self-testing on the main branch, extract the acceptance criteria (function points, quantitative indicators, boundary conditions) from the function's design document and generate an acceptance list that can be checked item by item (pass / fail format).

[0142] For feature design documents, after a development engineer submits a feature design document, it can be evaluated using a large language model based on: testability (whether the feature description can be transformed into verifiable conditions), boundary conditions (whether reverse and abnormal scenarios beyond the positive ones are covered), dependencies (interaction points with other features), and acceptance criteria (whether quantitative indicators are included). Evaluation opinions are then output, including the pass / fail / risk status of each item and a description of specific issues. These can be directly published as a collection of comments, which have already improved the design document.

[0143] In the above embodiments, determining the target acceptance point based on the acceptance information in the functional design document and the target test management document can improve the acceptance efficiency of the target chip.

[0144] like Figure 6 The diagram shows the structure of a six-node processor, which includes six nodes. During chip test management, node 1 is used to evaluate and improve the design document, node 2 is used to evaluate and improve the initial requirements document to generate the first requirements document, node 3 is used to generate the target test management document based on the first requirements document, node 4 is used to generate the acceptance list, node 5 is used to update the target test management document to obtain the latest version of the test management document, and node 6 is used to generate test cases based on the target test management document.

[0145] like Figure 7 The diagram shown is a structural schematic of a document generation system, including:

[0146] Document retrieval module: Supports pulling document content from collaboration platforms such as Confluence, converting it into a unified lightweight markup language (Markdown) format, and establishing a local version cache.

[0147] Inference Engine: Drives the large language model to perform various analysis and generation tasks using structured prompt templates, assigns roles such as test engineer and test manager to the large language model, and activates domain-related inference.

[0148] Six-node processor: implementation Figure 6 The processing logic of the six key nodes is as follows: each node corresponds to a type of triggering condition and output.

[0149] Generator: Generates a target test management document that conforms to the team's standard structure based on the first requirements document and the reference test management document.

[0150] Use case recommendation engine: Provides use case-level change suggestions based on pattern samples from test case sets.

[0151] Document Push Module: Pushes the generated target test management documents to collaboration platforms such as Confluence.

[0152] In one embodiment, the above-described chip test management method can be applied to the generation and updating of test management documents for chip 1. The operator executes instruction 1, the document generation system calls the document acquisition module, pulls the initial requirements document for chip 1 (version 1.4.0) through the Confluence interface, constructs a second prompt text, and calls a large language model to check each item in the initial requirements document. The system finds the following typical problems: requirement "007" is skipped (no 006); requirement "031" is described as "may need to be implemented," but its priority is marked as P1 (testability contradiction); the version number field for requirement "035" is blank (suspected delay). A structure evaluation report is output and shown to the operator, who then provides feedback to the document generator for correction.

[0153] The operator executes instruction 2. The document generation system retrieves the reference test management document for chip 2 (version 1.4.0) as a reference, extracts the chapter structure and coverage strategy, and finds that the reference test management document for chip 2 (version 1.4.0) already includes five test strategies: functionality, performance, stability, installation, and compatibility. The L0-L3 hierarchical structure is defined, and the requirement acceptance matrix contains seven fields. The document generation system then performs requirement point extraction on the first requirement document for chip 1 (version 1.4.0), extracting a total of 37 requirement points. Of these, 28 are marked as common across product lines, and 9 are marked as unique.

[0154] The document generation system displays the pending coverage strategy item to the operator: whether power consumption testing (unique) should be included in this version's testing; the operator confirms: included, with a baseline target of full-load power consumption ≤250 watts. The document generation system generates the target test management document for chip 1, version 1.4.0, with a requirement acceptance matrix of 37 rows, including mappings of all requirement points; the scheduling section includes four milestone nodes from L0 to L3; and the risk assessment section lists 6 risks. The document generation system saves the target test management document locally and (after operator confirmation) pushes it to the designated page in Confluence.

[0155] Two weeks later, Chip 1 released version 2. The operator executed command 3, and the document generation system retrieved the new requirements document. Compared with the locally cached first requirements document, the following four semantic changes were identified: the version number field of requirement "035" changed from blank to 1.4.0 (originally suspected to be delayed, now confirmed to be included in this version); requirement "041" is a new requirement; the description of requirement "022" changed from "supporting audio interface 2.0" to "supporting audio interface 2.1" (affecting the compatibility test matrix); the priority of requirement "029" decreased from P2 to P3 (test resources can be reallocated). The change impact assessment matrix was output and shown to the operator for confirmation. After the operator's confirmation, an incremental update was performed on the target test management document: the requirements acceptance matrix added the requirement "041" entry; the status of the requirement "035" entry changed from "never covered" to "pending scheduling"; the test scope of the requirement "022" entry was updated to "audio interface 2.1 verification, compatibility matrix needs to be updated"; the priority field of the requirement "029" entry was updated to P3. The updated version was saved and pushed to Confluence, and the local cache was overwritten with the new requirements document.

[0156] The operator executes instruction 4. The document generation system reads the coverage strategy from the management system and loads the test case set. It matches test cases for each requirement point, identifies requirement "041" as having no matching test cases, and outputs 3 new test case outlines. Requirement "022" requires modification of existing test cases. All other requirement points have matching test cases, and the test case numbers are listed. A test case change suggestion report is output, which the operator uses to organize a test case review meeting.

[0157] Based on the above embodiments, in an exemplary embodiment, such as Figure 8 As shown, the chip test management method in this application embodiment may include the following steps:

[0158] S801, in response to a document generation request for the target chip, obtains the initial requirements document for the target chip.

[0159] S802, based on the second prompt template and the initial requirements document, construct the second prompt text, input the second prompt text into the evaluation model for document evaluation, and obtain the evaluation result.

[0160] The second prompt template includes multiple document evaluation items.

[0161] S803 adjusts the initial requirements document based on the evaluation results to obtain the first requirements document for the target chip.

[0162] S804 constructs a first prompt text based on the first prompt template and the first requirement document; the first prompt text is input into the extraction model to extract the requirement points, thereby obtaining each test requirement point of the target chip.

[0163] The first prompt template includes role definition, extraction rules, and output format;

[0164] S805 parses the reference test management document to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product.

[0165] The test coverage strategy for each reference requirement point includes the test type for that reference requirement point.

[0166] S806 determines the test coverage strategy for each requirement point under test based on the test coverage strategy for each reference requirement point; and generates the target test management document corresponding to the target chip based on the chapter structure data, each requirement point under test and the corresponding test coverage strategy.

[0167] S807, for each requirement to be tested, retrieves the test case set based on the requirement content and test coverage strategy of the requirement to be tested, and obtains the retrieval results.

[0168] S808: If the search results indicate that the target test case has been found, the target test case shall be used as the test case for the requirement point to be tested; if the search results indicate that the target test case has not been found, test cases for the requirement point to be tested shall be generated based on the requirement content of the requirement point to be tested, or test cases similar to the target test case in the test case set shall be modified based on the requirement content of the requirement point to be tested to obtain test cases for the requirement point to be tested.

[0169] Among them, the target test cases are the test cases required to test the requirements to be tested.

[0170] S809: If a version update is detected in the requirements document of the target chip, obtain the latest version of the second requirements document; perform a semantic comparison between the first requirements document and the second requirements document to obtain the change requirements points included in the second requirements document; based on the change requirements points, update the target test management document to obtain the test management document corresponding to the latest version.

[0171] S810, when the target chip's function is detected to meet the pre-acceptance conditions, extracts each candidate acceptance point of the function based on the function's design document; and selects the target acceptance point from each candidate acceptance point based on the acceptance information of the corresponding test requirement points of the function.

[0172] Among them, the target acceptance point is used to accept the function.

[0173] The specific implementation methods of S801-S810 are the same as those in the above method embodiments, and will not be repeated here.

[0174] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0175] Based on the same inventive concept, this application also provides a chip test management device for implementing the chip test management method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more chip test management device embodiments provided below can be found in the limitations of the chip test management method described above, and will not be repeated here.

[0176] In one exemplary embodiment, such as Figure 9 As shown, a chip test management device is provided, including: an acquisition module 901 and a generation module 902, wherein:

[0177] The acquisition module 901 is used to acquire the first requirement document for the target chip in response to a document generation request for the target chip.

[0178] The generation module 902 is used to generate a target test management document corresponding to the target chip based on the first requirement document and the reference test management document; wherein, the reference test management document is the test management document of the relevant products of the target chip; the target test management document includes the test coverage strategy for each requirement point to be tested of the target chip, and the target test management document is used to guide the generation of test cases for the target chip.

[0179] In one embodiment, the generation module 902 includes:

[0180] The extraction unit is used to extract requirement points from the first requirement document to obtain each test requirement point of the target chip.

[0181] The parsing unit is used to parse the reference test management document to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product; wherein, the test coverage strategy for each reference requirement point includes the test type of the corresponding reference requirement point;

[0182] The generation unit is used to generate the target test management document corresponding to the target chip based on the test coverage strategy for each test requirement, chapter structure data, and each reference requirement.

[0183] In one embodiment, the generating unit is specifically used for:

[0184] Based on the test coverage strategy for each reference requirement point, determine the test coverage strategy for each requirement point to be tested.

[0185] Based on the chapter structure data, each test requirement and the corresponding test coverage strategy, a target test management document for the target chip is generated.

[0186] In one embodiment, the extraction unit is specifically used for:

[0187] Based on the first prompt template and the first requirements document, construct the first prompt text; the first prompt template includes extraction rules and output format.

[0188] The first prompt text is input into the extraction model to extract the requirement points, thus obtaining each test requirement point of the target chip.

[0189] In one embodiment, the apparatus further includes a retrieval module for:

[0190] For each requirement to be tested, the test case set is retrieved based on the test coverage strategy for the requirement to be tested, and the retrieval results are obtained.

[0191] Based on the search results, determine the test cases for the requirements to be tested.

[0192] In one embodiment, the retrieval module is specifically used for:

[0193] If the search results indicate that the target test case has been found, the target test case will be used as the test case for the requirement to be tested; where the target test case is the test case required to test the requirement to be tested.

[0194] In one embodiment, the retrieval module is specifically used for:

[0195] If the search results indicate that no target test case was found, test cases for the requirement to be tested are determined based on the requirement content of the requirement to be tested.

[0196] In one embodiment, the retrieval module is specifically used for:

[0197] Based on the requirements of the requirement to be tested, generate test cases for the requirement to be tested; or...

[0198] Based on the requirements of the requirement to be tested, test cases that are similar to the target test cases in the test case set are modified to obtain test cases for the requirement to be tested.

[0199] In one embodiment, the apparatus further includes an update module for:

[0200] If an update to the requirements document for the target chip is detected, obtain the latest version of the second requirements document;

[0201] The first requirement document and the second requirement document are semantically compared to obtain the change requirement points included in the second requirement document.

[0202] Based on the changed requirements, the target test management document is updated to obtain the latest version of the test management document.

[0203] In one embodiment, the target test management document includes acceptance information for each test requirement of the target chip; the apparatus further includes an acceptance module for:

[0204] If the target chip's functionality meets the pre-acceptance conditions, then based on the functional design document, extract each candidate acceptance point for the function.

[0205] Based on the acceptance information of the test requirements corresponding to the function, a target acceptance point is selected from each candidate acceptance point; the target acceptance point is used to accept the function.

[0206] In one embodiment, the acquisition module 901 is specifically used for:

[0207] In response to a document generation request for the target chip, obtain the initial requirements document for the target chip;

[0208] Based on the second prompt template and the initial requirements document, construct the second prompt text; the second prompt template includes multiple document evaluation items;

[0209] The second prompt text is input into the evaluation model to perform document evaluation, and the evaluation results are obtained.

[0210] Based on the evaluation results, the initial requirements document was adjusted to obtain the first requirements document for the target chip.

[0211] Each module in the aforementioned chip test management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0212] In one exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to: in response to a document generation request for a target chip, obtain a first requirement document for the target chip; and generate a target test management document corresponding to the target chip based on the first requirement document and a reference test management document. The reference test management document is a test management document for related products of the target chip. The target test management document includes a test coverage strategy for each test requirement of the target chip, and is used to guide the generation of test cases for the target chip.

[0213] In one embodiment, a target test management document corresponding to the target chip is generated based on a first requirement document and a reference test management document. This includes: extracting requirement points from the first requirement document to obtain each test requirement point of the target chip; parsing the reference test management document to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product; wherein the test coverage strategy for each reference requirement point includes the test type of the corresponding reference requirement point; and generating the target test management document corresponding to the target chip based on each test requirement point, the chapter structure data, and the test coverage strategy for each reference requirement point.

[0214] In one embodiment, a target test management document corresponding to the target chip is generated based on each test requirement, chapter structure data, and test coverage strategy for each reference requirement. This includes: determining the test coverage strategy for each test requirement based on the test coverage strategy for each reference requirement; and generating the target test management document corresponding to the target chip based on the chapter structure data, each test requirement, and the corresponding test coverage strategy.

[0215] In one embodiment, requirement points are extracted from the first requirement document to obtain each test requirement point of the target chip, including: constructing a first prompt text based on a first prompt template and the first requirement document; the first prompt template includes extraction rules and an output format; the first prompt text is input into the extraction model to extract requirement points to obtain each test requirement point of the target chip.

[0216] In one embodiment, the method further includes: for each requirement point to be tested, retrieving the test case set based on the test coverage strategy of the requirement point to be tested, and obtaining the retrieval results; and determining the test cases for the requirement point to be tested based on the retrieval results.

[0217] In one embodiment, determining test cases for the requirement to be tested based on the search results includes: if the search results indicate that a target test case has been found, using the target test case as the test case for the requirement to be tested; wherein the target test case is the test case required to test the requirement to be tested.

[0218] In one embodiment, test cases for the requirement to be tested are determined based on the search results, including:

[0219] If the search results indicate that no target test case was found, test cases for the requirement to be tested are determined based on the requirement content of the requirement to be tested.

[0220] In one embodiment, the test cases for the requirement point to be tested are determined based on the requirement content of the requirement point to be tested, including: generating test cases for the requirement point to be tested based on the requirement content of the requirement point to be tested; or, modifying test cases in the test case set that are similar to the target test cases based on the requirement content of the requirement point to be tested to obtain test cases for the requirement point to be tested.

[0221] In one embodiment, the method further includes: when a version update is detected in the requirements document of the target chip, obtaining the latest version of the second requirements document; performing a semantic comparison between the first requirements document and the second requirements document to obtain the changed requirements points included in the second requirements document; and updating the target test management document based on the changed requirements points to obtain the test management document corresponding to the latest version.

[0222] In one embodiment, the target test management document includes acceptance information for each test requirement of the target chip; the method further includes: when the function of the target chip is detected to meet the preconditions for acceptance, extracting each candidate acceptance point of the function based on the function's design document; selecting a target acceptance point from each candidate acceptance point based on the acceptance information of the test requirement corresponding to the function; wherein the target acceptance point is used to accept the function.

[0223] In one embodiment, in response to a document generation request for a target chip, obtaining a first requirement document for the target chip includes: in response to a document generation request for the target chip, obtaining an initial requirement document for the target chip; constructing a second prompt text based on a second prompt template and the initial requirement document; the second prompt template including multiple document evaluation items; inputting the second prompt text into an evaluation model for document evaluation to obtain an evaluation result; and adjusting the initial requirement document based on the evaluation result to obtain the first requirement document for the target chip.

[0224] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon. When executed by a processor, the computer program performs the following: in response to a document generation request for a target chip, obtaining a first requirement document for the target chip; and generating a target test management document corresponding to the target chip based on the first requirement document and a reference test management document; wherein the reference test management document is a test management document for related products of the target chip; and the target test management document includes a test coverage strategy for each test requirement of the target chip, and is used to guide the generation of test cases for the target chip.

[0225] In one embodiment, a target test management document corresponding to the target chip is generated based on a first requirement document and a reference test management document. This includes: extracting requirement points from the first requirement document to obtain each test requirement point of the target chip; parsing the reference test management document to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product; wherein the test coverage strategy for each reference requirement point includes the test type of the corresponding reference requirement point; and generating the target test management document corresponding to the target chip based on each test requirement point, the chapter structure data, and the test coverage strategy for each reference requirement point.

[0226] In one embodiment, a target test management document corresponding to the target chip is generated based on each test requirement, chapter structure data, and test coverage strategy for each reference requirement. This includes: determining the test coverage strategy for each test requirement based on the test coverage strategy for each reference requirement; and generating the target test management document corresponding to the target chip based on the chapter structure data, each test requirement, and the corresponding test coverage strategy.

[0227] In one embodiment, requirement points are extracted from the first requirement document to obtain each test requirement point of the target chip, including: constructing a first prompt text based on a first prompt template and the first requirement document; the first prompt template includes extraction rules and an output format; the first prompt text is input into the extraction model to extract requirement points to obtain each test requirement point of the target chip.

[0228] In one embodiment, the method further includes: for each requirement point to be tested, retrieving the test case set based on the test coverage strategy of the requirement point to be tested, and obtaining the retrieval results; and determining the test cases for the requirement point to be tested based on the retrieval results.

[0229] In one embodiment, determining test cases for the requirement to be tested based on the search results includes: if the search results indicate that a target test case has been found, using the target test case as the test case for the requirement to be tested; wherein the target test case is the test case required to test the requirement to be tested.

[0230] In one embodiment, test cases for the requirement to be tested are determined based on the search results, including:

[0231] If the search results indicate that no target test case was found, test cases for the requirement to be tested are determined based on the requirement content of the requirement to be tested.

[0232] In one embodiment, the test cases for the requirement point to be tested are determined based on the requirement content of the requirement point to be tested, including: generating test cases for the requirement point to be tested based on the requirement content of the requirement point to be tested; or, modifying test cases in the test case set that are similar to the target test cases based on the requirement content of the requirement point to be tested to obtain test cases for the requirement point to be tested.

[0233] In one embodiment, the method further includes: when a version update is detected in the requirements document of the target chip, obtaining the latest version of the second requirements document; performing a semantic comparison between the first requirements document and the second requirements document to obtain the changed requirements points included in the second requirements document; and updating the target test management document based on the changed requirements points to obtain the test management document corresponding to the latest version.

[0234] In one embodiment, the target test management document includes acceptance information for each test requirement of the target chip; the method further includes: when the function of the target chip is detected to meet the preconditions for acceptance, extracting each candidate acceptance point of the function based on the function's design document; selecting a target acceptance point from each candidate acceptance point based on the acceptance information of the test requirement corresponding to the function; wherein the target acceptance point is used to accept the function.

[0235] In one embodiment, in response to a document generation request for a target chip, obtaining a first requirement document for the target chip includes: in response to a document generation request for the target chip, obtaining an initial requirement document for the target chip; constructing a second prompt text based on a second prompt template and the initial requirement document; the second prompt template including multiple document evaluation items; inputting the second prompt text into an evaluation model for document evaluation to obtain an evaluation result; and adjusting the initial requirement document based on the evaluation result to obtain the first requirement document for the target chip.

[0236] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements: in response to a document generation request for a target chip, obtaining a first requirement document for the target chip; and generating a target test management document corresponding to the target chip based on the first requirement document and a reference test management document; wherein the reference test management document is a test management document for related products of the target chip; and the target test management document includes a test coverage strategy for each test requirement point of the target chip, and is used to guide the generation of test cases for the target chip.

[0237] In one embodiment, a target test management document corresponding to the target chip is generated based on a first requirement document and a reference test management document. This includes: extracting requirement points from the first requirement document to obtain each test requirement point of the target chip; parsing the reference test management document to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product; wherein the test coverage strategy for each reference requirement point includes the test type of the corresponding reference requirement point; and generating the target test management document corresponding to the target chip based on each test requirement point, the chapter structure data, and the test coverage strategy for each reference requirement point.

[0238] In one embodiment, a target test management document corresponding to the target chip is generated based on each test requirement, chapter structure data, and test coverage strategy for each reference requirement. This includes: determining the test coverage strategy for each test requirement based on the test coverage strategy for each reference requirement; and generating the target test management document corresponding to the target chip based on the chapter structure data, each test requirement, and the corresponding test coverage strategy.

[0239] In one embodiment, requirement points are extracted from the first requirement document to obtain each test requirement point of the target chip, including: constructing a first prompt text based on a first prompt template and the first requirement document; the first prompt template includes extraction rules and an output format; the first prompt text is input into the extraction model to extract requirement points to obtain each test requirement point of the target chip.

[0240] In one embodiment, the method further includes: for each requirement point to be tested, retrieving the test case set based on the test coverage strategy of the requirement point to be tested, and obtaining the retrieval results; and determining the test cases for the requirement point to be tested based on the retrieval results.

[0241] In one embodiment, determining test cases for the requirement to be tested based on the search results includes: if the search results indicate that a target test case has been found, using the target test case as the test case for the requirement to be tested; wherein the target test case is the test case required to test the requirement to be tested.

[0242] In one embodiment, test cases for the requirement to be tested are determined based on the search results, including:

[0243] If the search results indicate that no target test case was found, test cases for the requirement to be tested are determined based on the requirement content of the requirement to be tested.

[0244] In one embodiment, the test cases for the requirement point to be tested are determined based on the requirement content of the requirement point to be tested, including: generating test cases for the requirement point to be tested based on the requirement content of the requirement point to be tested; or, modifying test cases in the test case set that are similar to the target test cases based on the requirement content of the requirement point to be tested to obtain test cases for the requirement point to be tested.

[0245] In one embodiment, the method further includes: when a version update is detected in the requirements document of the target chip, obtaining the latest version of the second requirements document; performing a semantic comparison between the first requirements document and the second requirements document to obtain the changed requirements points included in the second requirements document; and updating the target test management document based on the changed requirements points to obtain the test management document corresponding to the latest version.

[0246] In one embodiment, the target test management document includes acceptance information for each test requirement of the target chip; the method further includes: when the function of the target chip is detected to meet the preconditions for acceptance, extracting each candidate acceptance point of the function based on the function's design document; selecting a target acceptance point from each candidate acceptance point based on the acceptance information of the test requirement corresponding to the function; wherein the target acceptance point is used to accept the function.

[0247] In one embodiment, in response to a document generation request for a target chip, obtaining a first requirement document for the target chip includes: in response to a document generation request for the target chip, obtaining an initial requirement document for the target chip; constructing a second prompt text based on a second prompt template and the initial requirement document; the second prompt template including multiple document evaluation items; inputting the second prompt text into an evaluation model for document evaluation to obtain an evaluation result; and adjusting the initial requirement document based on the evaluation result to obtain the first requirement document for the target chip.

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

[0249] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0250] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0251] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A chip test management method, characterized in that, The method includes: In response to a document generation request for the target chip, a first requirements document for the target chip is obtained; Based on the first requirement document and the reference test management document, a target test management document corresponding to the target chip is generated; wherein, the reference test management document is the test management document of the relevant products of the target chip; the target test management document includes the test coverage strategy for each test requirement point of the target chip, and the target test management document is used to guide the generation of test cases for the target chip.

2. The method according to claim 1, characterized in that, The step of generating the target test management document corresponding to the target chip based on the first requirement document and the reference test management document includes: Extract the requirement points from the first requirement document to obtain each test requirement point of the target chip. The reference test management document is parsed to obtain the chapter structure data of the reference test management document and the test coverage strategy for each reference requirement point of the relevant product; wherein, the test coverage strategy for each reference requirement point includes the test type of the corresponding reference requirement point; Based on the test coverage strategy for each of the aforementioned test requirements, the chapter structure data, and each of the aforementioned reference requirements, a target test management document corresponding to the target chip is generated.

3. The method according to claim 2, characterized in that, The test coverage strategy based on each of the test requirements, the chapter structure data, and each of the reference requirements generates a target test management document corresponding to the target chip, including: Based on the test coverage strategy for each of the reference requirement points, determine the test coverage strategy for each of the requirement points to be tested. Based on the chapter structure data, each of the test requirements and the corresponding test coverage strategy, a target test management document corresponding to the target chip is generated.

4. The method according to claim 2, characterized in that, The step of extracting requirement points from the first requirement document to obtain each test requirement point of the target chip includes: Based on the first prompt template and the first requirement document, a first prompt text is constructed; the first prompt template includes extraction rules and output format; The first prompt text is input into the extraction model to extract the demand points, thus obtaining each of the demand points to be tested.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: For each requirement to be tested, the test case set is retrieved based on the test coverage strategy of the requirement to be tested, and the retrieval results are obtained. Based on the search results, test cases are determined for the requirement points to be tested.

6. The method according to claim 5, characterized in that, The step of determining test cases for the requirement point to be tested based on the search results includes: If the search results indicate that a target test case has been found, the target test case shall be used as the test case for the requirement point to be tested; wherein, the target test case is the test case required to test the requirement point to be tested.

7. The method according to claim 5, characterized in that, The step of determining test cases for the requirement point to be tested based on the search results includes: If the search results indicate that no target test case was found, test cases for the requirement point to be tested are determined based on the requirement content of the requirement point to be tested; wherein, the target test case is the test case required to test the requirement point to be tested.

8. The method according to claim 7, characterized in that, The process of determining test cases for the requirement point under test based on its requirement content includes: Based on the requirements of the requirement points to be tested, generate test cases for the requirement points to be tested; or... Based on the requirements of the requirement point to be tested, the test cases in the test case set that are similar to the target test case are modified to obtain the test cases for the requirement point to be tested.

9. The method according to any one of claims 1-4, characterized in that, The method further includes: If an update to the requirements document for the target chip is detected, obtain the latest version of the second requirements document; The first requirement document and the second requirement document are semantically compared to obtain the change requirement points included in the second requirement document. Based on the aforementioned change requirements, the target test management document is updated to obtain the latest version of the test management document.

10. The method according to any one of claims 1-4, characterized in that, The target test management document includes acceptance information for each test requirement of the target chip; the method further includes: If the target chip's functionality meets the pre-acceptance conditions, then based on the functional design document, extract each candidate acceptance point for that function. Based on the acceptance information of the test requirement points corresponding to the function, a target acceptance point is selected from each candidate acceptance point; wherein, the target acceptance point is used to accept the function.

11. The method according to any one of claims 1-4, characterized in that, The step of obtaining a first requirement document for the target chip in response to a document generation request for the target chip includes: In response to a document generation request for the target chip, an initial requirements document for the target chip is obtained; Based on the second prompt template and the initial requirements document, a second prompt text is constructed; the second prompt template includes multiple document evaluation items; The second prompt text is input into the evaluation model to perform document evaluation, and the evaluation result is obtained. The initial requirements document is adjusted based on the evaluation results to obtain the first requirements document.

12. A chip test management device, characterized in that, The device includes: The acquisition module is used to acquire a first requirement document for the target chip in response to a document generation request for the target chip. The generation module is used to generate a target test management document corresponding to the target chip based on the first requirement document and the reference test management document; wherein, the reference test management document is the test management document of the relevant products of the target chip; the target test management document includes the test coverage strategy for each test requirement point of the target chip, and the target test management document is used to guide the generation of test cases for the target chip.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

Images