Test method, device and related equipment of a graphics processor

Abstract

This disclosure provides a testing method, apparatus, and related equipment for a graphics processing unit (GPU). The method includes: detecting a trigger event corresponding to the GPU and determining the event type of the trigger event; obtaining the quality assurance status of the instantiated object corresponding to the trigger event; selecting a target node from multiple quality assurance activity nodes based on the combination relationship between the event type and the quality assurance status; generating a test task corresponding to the trigger event through the target node; and executing the test task to test the GPU. This method can automatically detect trigger events through event awareness, eliminating the need for manual monitoring; furthermore, it can automatically select the target node based on the combination relationship between the event type and the current quality assurance status, eliminating the need for manual judgment and thus simplifying the testing process.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a testing method, apparatus and related equipment for a graphics processor. Background Technology

[0002] In the development of a graphics processing unit (GPU), in order to ensure product quality, a large number of functional and regression tests need to be performed on the driver and related hardware and software.

[0003] In related technologies, GPU testing activities typically rely on manual triggering: testers need to continuously monitor various events during the development process, such as updates to the Product Requirements Document (PRD), submissions of design specifications, code merge requests, or code freeze notifications. Once these events occur, testers need to rely on their personal experience to manually determine which testing process should be initiated (such as reviewing requirements, updating test plans, or executing test cases), and generate and execute test tasks accordingly.

[0004] However, this manually-driven test triggering mechanism is cumbersome to operate and has obvious lag. Furthermore, due to its over-reliance on personal experience, different testers may use different testing methods for the same event. Summary of the Invention

[0005] This disclosure provides a testing method, apparatus, and related equipment for graphics processors.

[0006] In a first aspect, this disclosure provides a method for testing a graphics processing unit (GPU), the method comprising: detecting a triggering event corresponding to the GPU and determining the event type of the triggering event; obtaining the quality assurance status of an instantiated object corresponding to the triggering event; selecting a target node from multiple quality assurance activity nodes based on the combination relationship between the event type and the quality assurance status; generating a test task corresponding to the triggering event through the target node and executing the test task to test the GPU.

[0007] Secondly, this disclosure provides a testing apparatus for a graphics processing unit (GPU). The apparatus includes: a detection module, adapted to detect a trigger event corresponding to the GPU and determine the event type of the trigger event; an acquisition module, adapted to acquire the quality assurance status of an instantiated object corresponding to the trigger event; a selection module, adapted to select a target node from multiple quality assurance activity nodes based on the combination relationship between the event type and the quality assurance status; and a testing module, adapted to generate a test task corresponding to the trigger event through the target node and execute the test task to test the GPU.

[0008] Thirdly, this disclosure provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the processor is configured to perform the above-described method.

[0009] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described method.

[0010] Fifthly, this disclosure provides a computer program product comprising computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the method described above.

[0011] In the embodiments provided in this disclosure, triggering events can be automatically detected through event awareness, eliminating the need for manual monitoring. Furthermore, target nodes can be automatically selected based on the combination of event type and current quality assurance status, eliminating the need for manual judgment and simplifying the testing process. Specifically, the decision-making mechanism combining event type and quality assurance status allows the same triggering event to trigger different quality assurance activity nodes under different states, thereby avoiding issues such as repeated reviews or missed change detections and improving the execution efficiency of quality assurance activities. Moreover, this approach can be automated, without relying on human experience, facilitating the assurance of uniformity and consistency in the testing process.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the description of detailed exemplary embodiments with reference to the accompanying drawings.

[0014] Figure 1 A flowchart illustrating a testing method for a graphics processor provided in an embodiment of this disclosure.

[0015] Figure 2 A schematic diagram of the architecture of a six-node workflow processor is shown.

[0016] Figure 3 This is a structural diagram of a testing apparatus for a graphics processor provided in an embodiment of this disclosure.

[0017] Figure 4 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0019] Unless otherwise specified, the various embodiments and features of this disclosure may be combined with each other. As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries.

[0020] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0022] Figure 1A flowchart of a testing method for a graphics processor provided in this disclosure embodiment is shown below. Figure 1 The method includes the following steps: Step S110, detecting the trigger event corresponding to the graphics processor and determining the event type of the trigger event.

[0023] In this context, a triggering event refers to a signal or notification generated during the development of GPU software or hardware that can prompt a response from quality assurance activities. Event types can be identifiers used to categorize triggering events, such as file entry, content modification, or node status change.

[0024] Step S120: Obtain the quality assurance status of the instantiated object corresponding to the triggering event.

[0025] An instantiated object is an abstract representation of a GPU product in a specific dimension. For example, an instantiated object can correspond to a product line, a version, a hardware configuration, or a combination of terminal types. Each instantiated object has an associated quality assurance status. The quality assurance status describes the instantiated object's position in the quality assurance process and the work it has completed, such as which nodes have been completed and whether it has cached data.

[0026] Step S130: Select the target node from multiple quality assurance activity nodes based on the combination relationship between event type and quality assurance status.

[0027] The composition relationship is used to characterize the matching logic between event types and the current quality assurance status. Typically, different composition relationships correspond to different processing paths. Multiple quality assurance activity nodes can be different processing stages or task units in the quality assurance process, such as document review nodes, test plan generation nodes, and functional acceptance nodes. This disclosure does not limit the number of quality assurance activity nodes or the method of node division. The target node is one or more nodes to be executed selected from multiple quality assurance activity nodes based on the composition relationship. Different processing stages can include: node task initialization stage, node task execution stage, node task verification stage, and node task completion stage.

[0028] Step S140: Generate a test task corresponding to the trigger event through the target node, and execute the test task to test the graphics processor.

[0029] In this context, a test task refers to the specific work content defined by the target node. The content of the test task varies depending on the target node. For example, the test task for a review node might be generating document review comments, the test task for a test plan generation node might be building a test plan document, and the test task for a functional acceptance node might be generating an acceptance checklist.

[0030] Therefore, the triggering methods for quality assurance activities in related technologies are relatively singular, failing to differentiate responses based on the specific type of R&D event and the current project status, resulting in a low degree of alignment between quality assurance activities and the R&D process. This disclosure improves the targeting and efficiency of quality assurance activities by combining event type and quality assurance status in the decision-making process, making the triggering timing and content of quality assurance activities more precise. This method can automatically select the corresponding quality assurance activity node based on the R&D event type and the current quality assurance status, reducing manual judgment and repetitive processing, and improving the execution efficiency, consistency, and traceability of the GPU testing quality assurance process.

[0031] Furthermore, those skilled in the art can make various modifications and variations to the above embodiments: In one optional implementation, the instantiated object can be used to characterize the version information, hardware parameter information, and / or terminal type information of the graphics processor; and, when the graphics processor has multiple instantiated objects, before obtaining the quality assurance status of the instantiated object corresponding to the triggering event, the following operations are further performed: extracting the object identifier contained in the triggering event, and selecting the instantiated object corresponding to the triggering event from among the multiple instantiated objects based on the object identifier. Specifically, for scenarios with multiple instantiated objects, the accurate association between the triggering event and the instantiated object can be achieved by extracting the object identifier from the triggering event and locating the instantiated object corresponding to the current triggering event from among the multiple instantiated objects based on the identifier.

[0032] The representational information of the instantiated object can be a description of the GPU product across multiple dimensions. Version information may include software version number, driver version number, or firmware version number. Hardware parameter information may include parameters such as the GPU's architecture codename, number of cores, memory capacity, and operating frequency. Terminal type information may include product form factors such as desktop computer, laptop, server, and embedded device. The instantiated object can contain multiple types of the above information simultaneously, for example, "an instance of the desktop GPU driver version N with 4GB of video memory."

[0033] Therefore, when multiple instantiated objects exist, it is necessary to accurately assign triggering events to the corresponding instantiated objects. For example, when a "Product A Version N Design Specification Document Submission Event" is detected, the event message can contain the object identifier "ProductA_VersionN". Accordingly, this object identifier is extracted from the event message, and then the matching instantiated object is searched in a pre-maintained set of multiple instantiated objects. The method for extracting the object identifier can differ depending on the type of triggering event. For example, for events pushed via Webhook, the object identifier can be extracted from a specific field in the JSON message body. For events obtained through polling, the object identifier can be extracted from the document's metadata or directory structure. For manually entered events, the object identifier can be obtained through command-line parameters or interactive interface options. Using object identifiers enables precise matching between triggering events and instantiated objects, facilitating parallel management of quality assurance activities in scenarios with multiple product lines and versions, and avoiding state confusion between different instantiated objects.

[0034] In one alternative implementation, to improve the efficiency of test task generation, when generating test tasks corresponding to trigger events through the target node, the following method can be used: through the target node, select shared requirement information corresponding to the business function to be tested from the test requirement data stored in the shared resource pool; generate test tasks corresponding to trigger events according to the test coverage strategy corresponding to the shared requirement information; and after executing the test tasks, further store the test requirement data corresponding to the test tasks in the shared resource pool.

[0035] The shared resource pool can be a public storage area for storing test-related data, accessible to multiple instantiated objects. Test requirement data refers to data describing the function, feature, or requirement to be tested, and may include function descriptions, acceptance criteria, priority information, version attribution information, etc. Test requirement data is associated with specific business functions; for example, a function description may include: video decoding function, multi-monitor output function, etc. The business function to be tested refers to the specific functional characteristic targeted by the current test task, which can be extracted from documents associated with triggering events, such as functional points identified from design specification documents or product requirement documents. Shared requirement information refers to data items selected from the test requirement data in the shared resource pool that match the business function to be tested. A test coverage strategy can be a description of the test methods and scope used to verify whether a requirement or function meets expectations. For example, a test coverage strategy may include test types (e.g., functional testing, performance testing, compatibility testing), test environment requirements, test data preparation methods, pass / fail criteria, etc.

[0036] For example, when the target node is the test plan generation node, it can query the shared resource pool to see if there is test requirement data related to the current GPU video decoding function. If so (e.g., video decoding function test requirements from other product lines), it retrieves the shared requirement information and its associated test coverage strategy (e.g., "verify decoding smoothness at 4K resolution"). Accordingly, it generates the corresponding entries in the test plan for the current instantiated object based on this coverage strategy. After the test plan is generated, the test requirement data for the current instantiated object is stored in the shared resource pool for use by other instantiated objects in subsequent processes. The shared resource pool enables the reuse of test requirement data and test coverage strategies across instantiated objects, thereby reducing repetitive test design work and improving test efficiency.

[0037] The test requirement data stored in the shared resource pool can include multiple test requirement lists corresponding to multiple instantiated objects. Accordingly, shared requirement information corresponding to the business function under test can be selected from the test requirement data stored in the shared resource pool in the following way: Based on the graphics processor component that the business function under test depends on, a reference instantiated object is selected from multiple instantiated objects; wherein the reference instantiated object shares the graphics processor component that the business function depends on with the instantiated object corresponding to the triggering event; and shared requirement information corresponding to the business function under test is selected from the test requirement list of the reference instantiated object. The shared resource pool stores multiple test requirement lists corresponding to multiple instantiated objects. When selecting shared requirement information, firstly, based on the GPU component that the business function under test depends on, a reference instantiated object shared with that component is selected from the multiple instantiated objects; then, the corresponding shared requirement information is selected from the test requirement list of that reference instantiated object. The test requirement list can be a structured data collection used to organize the various test requirements corresponding to the instantiated objects. Each test requirement list can contain multiple records, each corresponding to a business function or requirement item. The record can include fields such as requirement identifier, requirement description, priority, acceptance criteria, and associated test coverage strategy.

[0038] In this context, a graphics processing unit (GPU) component refers to a functional module or subsystem within a GPU. Different business functions may depend on different GPU components. For example, "video decoding" might rely on the video decoder hardware module and corresponding driver interface within the GPU; "multi-GPU parallel computing" might depend on the interconnect interfaces between GPUs and the cluster management module in the driver; and "multi-monitor output" might depend on the GPU's display controller and corresponding output port driver. A reference instantiated object is one or more instantiated objects selected from multiple instantiated objects that share the same GPU component as the instantiated object corresponding to the currently triggered event. When selecting a reference instantiated object, an index or mapping table can be built based on component sharing relationships for quick lookup. This GPU component-based reference instantiated object filtering mechanism improves the accuracy and relevance of shared requirement information selection, avoiding the erroneous reuse of test assets from product lines with different hardware dependencies.

[0039] Furthermore, during parallel development of multiple instantiated objects, the lack of a unified cross-product line requirement coordination mechanism may lead to inconsistent requirement descriptions, resulting in inconsistent testing standards. To address this issue, each test requirement list can be used to store the correspondence between the requirement description information of the corresponding instantiated object and the test coverage strategy. Accordingly, for multiple associated instantiated objects sharing the same graphics processor component, multiple requirement descriptions of these associated instantiated objects are extracted. If inconsistencies are detected in the descriptions of the same business function across multiple requirement descriptions, a consistency warning message is generated. Inconsistencies in the descriptions of the same business function include: inconsistent priority definitions, inconsistent acceptance criteria, and / or inconsistent version attribution.

[0040] The requirement description information refers to the textual description of a specific business function or product requirement. Requirement description information can be in natural language, such as "GPU drivers should support silent installation mode during installation." There is a correspondence between test coverage strategies and requirement description information; that is, each requirement description can be associated with one or more test coverage strategies used to verify that requirement. Consistency alert information refers to the alert message generated when the system detects differences between the requirement descriptions of different instantiated objects. This alert message can include the specific content of the difference, the identifier of the involved instantiated object, the type of difference, and other fields. The alert message can be output in the user interface, sent via email, logged to a log file, or pushed via instant messaging tools.

[0041] Inconsistent priority definitions refer to situations where the same business function is assigned different priority levels in the product requirement documents of different instantiated objects. For example, Product A defines "HDR video playback support" as P0 (highest priority), while Product B defines the same function as P2 (lower priority). Upon detecting this difference, testers can be prompted to confirm the true priority of the function. Inconsistent acceptance criteria refer to situations where the same business function has different pass / fail conditions in the requirement descriptions of different instantiated objects. For example, Product A's acceptance criterion requires "video decoding latency not exceeding 5 milliseconds," while Product B's requires "video decoding latency not exceeding 10 milliseconds." In this case, a prompt message can be generated to remind relevant personnel to align their standards. Inconsistent version attribution refers to situations where the same business function is assigned different version numbers in the requirement descriptions of different instantiated objects. For example, Product A marks a function as the current version (version N), while Product B marks the same function as a future version (version N+1). In this case, a prompt can be generated to confirm the consistency of version planning. In practical implementation, different expressions of priority levels can be identified through keyword matching, differences in quantitative indicators in acceptance criteria can be identified through numerical comparison, and differences in version attribution can be identified through version number string comparison. Automated consistency checks across instantiated objects can promptly identify discrepancies in requirement descriptions between different product lines, providing a basis for unifying testing standards and coordinating resource allocation, and reducing testing risks caused by inconsistent requirements.

[0042] Furthermore, in parallel scenarios with multiple instantiated objects, to avoid state misalignment or schedule conflicts in quality assurance, multiple instantiated objects can correspond to multiple state machine instances. Each state machine instance records the quality assurance state of its corresponding instantiated object. Different instantiated objects may be at different quality assurance activity nodes at the same time; or, different instantiated objects may be at different processing stages within the same node at the same time. By introducing the concept of state machine instances, the quality assurance state of each instantiated object can be recorded separately. Multiple instantiated objects correspond to multiple independent state machine instances. Under the management of multiple state machine instances, different instantiated objects can be at different quality assurance activity nodes at the same time, or at different processing stages within the same node, thereby achieving parallel execution of quality assurance activities.

[0043] In this context, a state machine instance can be a data model instance used to describe the transition logic between different states of a given instantiated object. Each state machine instance independently maintains the quality assurance state of its corresponding instantiated object. Information that a state machine instance can record includes: the current node (e.g., review node, test plan generation node), the completion time and deliverable identifiers of completed nodes, a list of pending nodes, and contextual data passed between nodes (e.g., the list of test concerns generated by the previous node). By maintaining an independent state machine instance for each instantiated object, fine-grained management and parallel execution support for quality assurance states are achieved, avoiding state interference between different instantiated objects.

[0044] In one optional implementation, the quality assurance status includes: completed node records and / or test cache data; and the event types that trigger events include: file entry type, content change type, and node status type; multiple quality assurance activity nodes include: review node, test plan generation node, functional acceptance node, change node, and test case judgment node.

[0045] In the quality assurance status, completed node records can be a list or collection, used to record the quality assurance activity nodes that the instantiated object has completed. Node records can include information such as node identifier, completion time, and deliverable pointers. Test cache data refers to intermediate data generated and stored in previous quality assurance activities, which can be used by subsequent nodes. Test cache data can include retrieved document content, generated requirement lists, compiled coverage strategy templates, etc. For example, when the test plan generation node is executed, the product requirement document content cached in the review node can be directly read without re-retrieving it.

[0046] The document entry type in the event types refers to events related to the creation, submission, and publication of documents or files. For example, the initial submission of a design specification document or the publication of a draft product requirements document. The content change type refers to events related to modifications to the content of existing documents or data. For example, updating a product requirements document or merging code defect fixes. The node status type refers to events related to changes in the status of the quality assurance activity node itself. For example, the completion event of a node, the functional acceptance request event, or the code freeze notification event.

[0047] The quality assurance activity nodes are divided into several parts: the review node, which is used to review and evaluate documents or requirements; the test plan generation node, which generates structured test plan documents based on the reviewed requirements; the functional acceptance node, which generates acceptance checklists for individual functional features; the change node, which detects document or code changes and evaluates their impact on the test plan; and the use case evaluation node, which evaluates the coverage of existing test cases with requirements and generates supplementary use case suggestions. These nodes can have logical dependencies. For example, the review node typically occurs before the test plan generation node, the change node can occur after the test plan generation node, and the use case evaluation node typically occurs after the test plan has been largely stabilized.

[0048] Among them, when selecting a target node from multiple quality assurance activity nodes based on the combination relationship between event type and quality assurance status, it can be achieved in the following way: (1) In response to the triggering event being of the file entry type and the test cache data being empty, the review node is selected as the target node.

[0049] Among these, document entry events can include design specification document submission events or product requirement document draft release events. An empty test cache indicates that the instantiated object has not yet cached the relevant document content, meaning it is currently in the early stages of the quality assurance process. In this case, because a baseline has not yet been established, change detection cannot be performed directly; therefore, the review node is selected as the target node to conduct an initial review of the submitted documents.

[0050] (2) If the triggering event is of the content change type and the test cache data is not empty, then the change node is selected as the target node.

[0051] Events involving content changes can include product requirement document updates, defect fix code merging, or temporary feature merging. A non-empty test cache indicates that the instantiated object has completed at least one round of document review or test plan generation, and a baseline version exists for comparison. In this case, the system selects the change node as the target node and performs change detection. The change node can compare the latest document with the cached version, identify newly added, modified, deleted, or postponed requirement items, and assess the impact of these changes on existing test plans.

[0052] (3) If the response to the triggering event is a node state type and the completed node record contains a completed preset preceding node, then the functional acceptance node is selected as the target node.

[0053] Among these, events of node status type can include functional acceptance request events. Completed preset prerequisite nodes can include design specification review nodes. That is, when a functional acceptance request event is triggered, it checks whether the completed node records contain the corresponding design specification review node. If it does, it means that the function has passed the document review during the design phase and meets the conditions for functional acceptance. Therefore, the functional acceptance node is selected as the target node, and an acceptance checklist is generated.

[0054] The routing rules described above are merely illustrative. Depending on the product type, team size, or quality assurance strategy, these rules can be extended or adjusted in various ways. For example, in one alternative approach, a code freeze notification event can simultaneously trigger both the review node and the use case decision node (multi-node triggering), and a release scope confirmation event can trigger the use case decision node, etc. Those skilled in the art can configure more rule entries according to actual business needs.

[0055] Optionally, after executing a test task, the execution result can be obtained, and the quality assurance status of the instantiated object can be updated based on the result. The execution result of a test task refers to the output or conclusion generated after the test task defined in the target node is completed. Different nodes produce different forms of execution results. For example, the execution result of a review node could be a review report and a conclusion on whether the review passed. The execution result of a test plan generation node could be a test plan document. The execution result of a functional acceptance node could be an acceptance checklist and an acceptance conclusion. The execution result of a change detection node could be a change list and a judgment on whether the test plan needs to be updated. The execution result of a use case judgment node could be a use case change suggestion report.

[0056] Specifically, when updating the quality assurance status of instantiated objects, the current node can be marked as completed, and the completion time and storage location of the deliverables can be recorded. Data from the execution results can also be written to the test cache for use by subsequent nodes. Furthermore, the conditions for automatically triggering subsequent nodes can be determined based on the conclusions in the execution results (e.g., acceptance failure or document review failure). (For example, the next stage can only proceed after acceptance is passed). Updating the quality assurance status through execution result feedback enables closed-loop management of the quality assurance process, ensuring the real-time nature and accuracy of status information, and providing a reliable status foundation for the correct triggering and decision-making of subsequent nodes.

[0057] To facilitate understanding, an example is provided below to illustrate the specific implementation details of the graphics processor testing method provided in this application. This example offers a method and system for automatically orchestrating multi-stage quality assurance workflows for GPU software testing, relating to the field of software quality assurance (QA) technology, specifically GPU software testing, automated orchestration of quality assurance workflows, and software engineering automation. This example is applicable to the systematic, event-driven automatic orchestration and management of multi-stage QA activities during the development of GPU driver software and related products (such as GPU accelerated computing cards, AI inference accelerator cards, and graphics workstation graphics cards).

[0058] In the first approach, testing can be implemented through manual tracking. For example, in traditional GPU software development teams, the tracking and orchestration of quality assurance activities primarily rely on manual methods. Specifically, QA engineers perceive development progress through daily communication, which can include meetings or instant messaging tools. Based on the perceived development progress, QA engineers manually determine when to initiate test preparation. QA management users can maintain an internal process document. This process document can be in wiki format or word processing software (such as Word) format. This process document specifies the QA input and output requirements for each stage. However, there is no automatic correlation mechanism between this process document and the actual execution process. When requirements change, such as updates to the Product Requirements Document (PRD) or feature delays, the impact assessment of the changes relies entirely on the personal experience of QA engineers, lacking a systematic impact analysis process. In scenarios involving parallel development of multiple product lines, the coordination of QA activities is accomplished through manual alignment meetings, lacking a unified orchestration view. Furthermore, knowledge such as test coverage strategies and risk assessment is implicitly embedded in engineers' personal experience and passed down through oral instruction. When personnel leave, there is a risk of knowledge gaps.

[0059] In the second related approach, continuous integration and continuous delivery (CI / CD) tools can be used for testing. CI / CD tools are used in GPU software development to automate build and deployment processes, and their typical practices include the following steps.

[0060] Step 1: After the development engineer submits the code, the CI system automatically triggers a build task. The build task may include operations such as compiling the driver and generating the installation package.

[0061] Step 2: Upon successful build, the pre-set test scripts will be automatically triggered. These test scripts may include a graphical API compliance test suite, which can generate a test report upon completion of the test script execution.

[0062] Step 3: After the test is passed, the CD process will automatically push the software package to the test environment or release repository.

[0063] Step 4: The test results are communicated to relevant personnel via email or instant messaging.

[0064] In the above approach, the core focus of CI / CD tools is the automation of the code build and test execution layers. This approach can reduce the human cost of repetitive builds and regression tests.

[0065] The third approach can be implemented using test management tools. Professional test management tools can provide test case library management and test execution tracing capabilities. A typical implementation includes the following steps.

[0066] Step 1: QA engineers create test cases in the test management tool, classify and manage them according to modules or priorities, and form a test case library.

[0067] Step 2: For each test version, you can create a test plan in the test management tool, select test cases from the test case library, and assign the test cases to test engineers for execution.

[0068] Step 3: The test engineer executes the test cases according to the test plan, records the pass or fail status, and generates a test report.

[0069] Step 4: Integrate the test management tool with the defect management tool (such as Jira) to form a defect lifecycle management system.

[0070] In the above approach, the core focus of the test management tool is on test case management and progress tracking during the test execution phase. It lacks the ability to perceive and respond to upstream development activities, such as requirements review activities or design review activities.

[0071] The fourth approach involves using a document management collaboration platform. Some teams use such platforms to store PRDs, design documents, and test plans, and manually maintain cross-references between documents. The technical approach involves establishing connections between documents through page links on the collaboration platform, relying on manual checks for document updates, and manually synchronizing the content of associated documents. This solution addresses document storage and retrieval issues but lacks the ability to proactively detect document changes and trigger downstream responses.

[0072] It can be seen that the above-mentioned related methods have at least the following defects: (1) Quality assurance activities rely on manual judgment and the response is delayed.

[0073] In the relevant technical solutions, there is no automatic correlation mechanism between R&D events such as PRD releases, design specification document submissions, and code merges, and the initiation of QA activities. QA engineers rely on manual information acquisition methods to perceive R&D progress. These methods may include reviewing meeting minutes or receiving instant messaging notifications. This approach leads to unstable timing of QA activity initiation and response delays. These delays can range from several hours to several days. In GPU software teams with short version iteration cycles (e.g., 2 to 4 weeks for a small version), such delays compress the testing window.

[0074] (2) The impact of requirement changes on the test scope cannot be automatically assessed.

[0075] In the GPU software development cycle, the Product Requirements Document (PRD) is frequently updated during version development. Update types can include requirement additions / deletions, priority adjustments, and cross-version postponements. Each update should theoretically trigger an impact assessment on the test plan and an incremental update of the test plan. However, existing technical solutions lack semantic-level awareness of changes to the requirement document. For example, these solutions cannot automatically identify the semantic difference between "requirement postponement" (the version number field changes from the current version to blank) and "requirement deletion" (the entire entry is removed), nor can they automatically map the impact of changes to specific sections of the test plan.

[0076] (3) The continuous integration and continuous delivery pipeline does not cover the quality assurance business decision-making level.

[0077] CI / CD tools cover the build and test execution layers, but not the QA business decision-making layer. The QA business decision-making layer here refers to the following decision-making activities: determining when to review PRD quality (rather than simply reviewing existing PRD content); determining when to evaluate test coverage for new features from a test strategy perspective; determining when to update the test plan's coverage matrix; and determining when to initiate cross-version requirement flow processes. These decisions require business semantic understanding, a capability that current CI / CD tools lack. Therefore, this layer of decision-making still relies entirely on manual execution.

[0078] (4) The quality assurance activities of multiple product lines lack unified planning, resulting in duplication of work.

[0079] GPU software products are typically delivered in parallel across multiple product forms. These forms can include desktop, server, and SoC versions. These product lines share core GPU and operating system drivers. Many QA activities, such as test strategy design and test case writing, have high reusability. However, the lack of a cross-product-line QA activity orchestration view in the relevant technical solutions leads to QA teams across different product lines performing the same analysis work repeatedly. The cross-product-line reuse of existing test assets (such as test cases and coverage strategies) relies on manual identification, resulting in low reuse efficiency.

[0080] (5) Quality assurance knowledge cannot be systematically accumulated.

[0081] QA knowledge, such as test coverage strategies, defect risk assessment, and PRD review experience, exists in the form of tacit knowledge within engineers' individual understanding, lacking a structured knowledge base and automatic recall mechanism. New members need a considerable amount of time to learn and master the skills. QA knowledge cannot be systematically recalled and accumulated during the execution of testing activities.

[0082] Accordingly, this example aims to address the following technical issues: (1) How to achieve automatic mapping of R&D process events to QA activities to eliminate response delays caused by manual tracking. (2) How to perform semantic-level change detection on requirement documents to automatically assess the impact of changes on the test plan. (3) How to build an automatic orchestration mechanism covering the QA business decision-making layer to extend the automation capabilities of CI / CD to the test strategy layer. (4) How to achieve unified orchestration of QA activities across multiple product lines and automated reuse of test assets. (5) How to structure and precipitate QA knowledge into a rule base that can be called by the system so that the knowledge automatically takes effect during execution.

[0083] In short, the technical problem in this example is: how to design an automated system in the multi-product line GPU software development process that can sense development lifecycle events, automatically orchestrate corresponding quality assurance activities, support semantic-level change detection of requirements documents and incremental test plan updates, and achieve unified coordination of quality assurance activities across multiple product lines.

[0084] The system proposed in this example can be composed of five layers. This five-layer structure forms a complete data flow chain from event perception to execution, as follows: I. First layer: Event perception layer.

[0085] The event awareness layer is responsible for listening to various triggering events generated during the GPU software development process, structuring these events into standard event messages, and pushing them to the decision engine layer.

[0086] The event types supported by the event awareness layer can include the following:

[0087] (1) Design Specification Document Submission Event (DESIGN_SPEC_SUBMITTED): This event is triggered when a development engineer submits a design specification document. The data fields of this event may include the document's Uniform Resource Locator (URL), Feature ID, submitter, and timestamp.

[0088] (2) Product Requirements Document Draft Release Event (PRD_DRAFT_PUBLISHED): This event is triggered when the product manager releases a PRD draft. The data fields for this event may include the document URL, version number, product line identifier, and publisher.

[0089] (3) Product Requirements Document Update Event (PRD_UPDATED): This event is triggered when the PRD content is updated. The data fields of this event may include the document URL, version number, update description, and change summary.

[0090] (4) Product Requirements Document Approval Event (PRD_SIGNED_OFF): This event is triggered when the PRD is approved. The data fields of this event may include the document URL, version number, list of approvers, and approval time.

[0091] (5) Functional Acceptance Request Event (FEATURE_ACCEPTANCE_REQUEST): This event is triggered when a development engineer submits a functional feature acceptance request. The data fields of this event may include the functional feature identifier, the URL of the design specification document, and the submitter.

[0092] (6) Bug Fix Merge Event (BUG_FIX_MERGED): This event is triggered when a bug fix is ​​merged into the release branch. The data fields for this event may include the bug ID, affected module, merge time, and Jira ID.

[0093] (7) Temporary Feature Merge Event (TEMP_FEATURE_MERGED): This event is triggered when a temporary feature is merged into a release branch. The data fields of this event may include the feature identifier, the affected module, and the merge time.

[0094] (8) Code Freeze Notification Event (CODE_FREEZE_NOTIFIED): This event is triggered when the code freeze milestone is reached. The data fields of this event may include the version number, freeze time, and target release date.

[0095] (9) Release Scope Confirmation Event (RELEASE_SCOPE_CONFIRMED): This event is triggered when the release scope is confirmed. The data fields of this event may include version number, product line list, and feature list.

[0096] The event awareness layer can acquire the aforementioned events in various ways. Three exemplary acquisition methods are described below: (1) Push mode: The system integrates with the webhook of the R&D management system (e.g., Jira or Confluence). When an event occurs in the R&D management system, the event is pushed to the entry point of this system in real time. (2) Pull mode: The system periodically polls the document management platform to detect document version changes and extracts change events from the document management platform. (3) Active input mode: Quality assurance engineers can manually trigger events through the command-line interface or web entry point. This mode is suitable for scenarios where automated awareness has not yet been integrated. Specifically, the event awareness layer can perform the following processing steps.

[0097] Step 1: The event awareness layer receives raw event signals. These raw event signals can be Webhook callback signals or results from timed polling.

[0098] Step 2: Analyze the event signal and extract key fields such as event type, associated document identifier, product line identifier, and timestamp.

[0099] Step 3: Construct a standard event message. This message can be a JSON data structure. Write the message to the event queue.

[0100] Step 4: Push the event message to the decision engine layer and wait for the processing result.

[0101] Second layer: Decision engine layer.

[0102] The decision engine layer is the core processing unit in this example. It is responsible for automatically determining the quality assurance activity nodes to be triggered based on the event type and the current test status. The decision engine layer can use a trigger routing rule table for decision-making. This rule table is described below.

[0103] (1) When the input event is a design specification document submission event (such as the DESIGN_SPEC_SUBMITTED event) and the precondition is unconstrained, the triggering node is the design specification review node (called N1), and the priority is high.

[0104] (2) When the input event is a PRD draft release event (such as the PRD_DRAFT_PUBLISHED event) and the preceding state condition is unconstrained, the triggering node is the PRD review node (called N2), and the priority is high.

[0105] (3) When the input event is a PRD update event (such as the PRD_UPDATED event) and the prerequisite state condition is that there is an existing test plan cache, the triggering node is the change detection and incremental update node (called N5), and the priority is high.

[0106] (4) When the input event is a PRD update event and the prerequisite state condition is no test plan cache, the triggering node is the PRD review node (N2) with high priority.

[0107] (5) When the input event is a PRD approval event (such as the PRD_SIGNED_OFF event) and the prerequisite state condition is that N2 has been completed, the triggering node is the test plan generation node (called N3), and the priority is high.

[0108] (6) When the input event is a functional acceptance request event (such as the FEATURE_ACCEPTANCE_REQUEST event) and the prerequisite state condition is the existence of a corresponding design specification document, the trigger node is the functional acceptance node (called N4) with high priority.

[0109] (7) When the input event is a defect repair code merging event (such as the BUG_FIX_MERGED event) and the prerequisite state condition is an existing test plan, the triggering node is the change detection node (N5) and the priority is medium.

[0110] (8) When the input event is a temporary feature merging event (such as the TEMP_FEATURE_MERGED event) and the prerequisite state condition is an existing test plan, the triggering node is the change detection node (N5) and the priority is medium.

[0111] (9) When the input event is a code freeze notification event (such as the CODE_FREEZE_NOTIFIED event) and the prerequisite state condition is an existing test plan, the triggering node includes the test case judgment node (called N6), and the priority is high.

[0112] (10) When the input event is a release scope confirmation event (such as the RELEASE_SCOPE_CONFIRMED event) and the prerequisite state condition is that the test plan has been generated, the triggering node is the test case judgment node (N6), and the priority is medium. The test case judgment node can also be called the test case confirmation node.

[0113] The trigger nodes in the rule table above are a specific implementation of the quality assurance activity nodes mentioned above. Among them, the design specification review node and the PRD review node are specific forms of the review nodes mentioned above.

[0114] Specifically, the decision engine layer can execute the following decision steps.

[0115] Step 1: Receive event messages and extract the event type and product line identifier.

[0116] Step 2: Query the current quality assurance status of this product line. The quality assurance status can include completed nodes, pending items, and a list of cached documents.

[0117] Step 3: Determine the set of nodes to be triggered based on the event types and preceding states matched in the trigger routing rule table.

[0118] Step 4: Classify the set of nodes to be triggered obtained in Step 3: (1) Single node triggering scenario: If the node set contains only one node, such as the code freeze notification event triggering node N6 during the freeze phase, then add the node directly to the task queue; (2) Multi-node triggering scenario: If the node set contains multiple nodes, such as the PRD update event triggering nodes N2 and N5 simultaneously during the review phase, then sort them according to the preset node priority rules to generate an ordered task queue.

[0119] Step 5: Push the task queue to the execution layer and update the quality assurance status record for this product line.

[0120] Table 1 shows an optional schematic form of the trigger routing rule table.

[0121] Table 1

[0122]

[0123] Table 1 systematically displays, in matrix form, the execution nodes or status markers triggered by the seven event types under the four quality assurance phases. Each row in the matrix corresponds to an event type, and each column corresponds to a phase. The cell content is the node number (N1~N6) or status marker that should be triggered under that phase. The specific mapping relationships are as follows: Design specification document submission event: Triggers N1 (design specification review) in the draft stage, triggers N1 in the review stage, is "ignored" in the testing stage, and is "ignored" in the freeze stage; PRD draft release event: Triggers N2 (PRD review) in the draft stage, triggers N2 in the review stage, is "ignored" in the testing stage, and is "ignored" in the freeze stage; PRD update event: Triggers N2 in the draft stage, triggers both N2 and N5 in the review stage, triggers N5 (change detection) in the testing stage, and is "requires manual confirmation" in the freeze stage; Functional acceptance request event: "ignored" in the draft stage, "ignored" in the review stage, triggers N4 (functional acceptance) in the testing stage, and is "requires manual confirmation" in the freeze stage; Code freeze notification event: "ignored" in the draft stage, "ignored" in the review stage, triggers N6 (use case judgment) in the testing stage, and triggers N6 (use case judgment) in the freeze stage; Defect fix introduction event: "ignored" in the draft stage, "ignored" in the review stage, triggers N5 (change detection) in the testing stage, and triggers both N5 and N6 (use case judgment) in the freeze stage.

[0124] It should be noted that Table 1 is only an example, and those skilled in the art can make various adjustments to the contents of Table 1.

[0125] In practice, when a graphics processor has multiple instantiated objects, a separate state machine instance is maintained for each instantiated object. For example, an instantiated object can correspond to a product line, and correspondingly, each product line maintains a separate quality assurance state machine instance for each version. This state machine instance is used to record the quality assurance status of the corresponding instantiated object.

[0126] Third layer: Execution layer.

[0127] The execution layer implements the specific processing logic for the six quality assurance activity nodes, with each node corresponding to an independent workflow processor module. The trigger nodes determined by the decision engine layer above serve as the entry points for each processor module described below. Figure 2 The diagram below shows the architecture of a six-node workflow processor. Figure 2 The implementation methods of each node are explained in detail.

[0128] 1. Node N1: Review the processor according to design specifications.

[0129] Triggering condition: When the input event is a design specification document submission event (such as the DESIGN_SPEC_SUBMITTED event) and the precondition is unconstrained, the triggering node is the design specification review node (referred to as N1).

[0130] Input: Design specification document (which can be obtained through the Uniform Resource Locator (URL) or Local Markup Language (NMR) format file of the collaborative document platform).

[0131] The specific processing steps are as follows: Step 1: Retrieve the design specification document content through the document retrieval interface and convert it into a structured markup language format.

[0132] Step 2: Extract the functional description paragraphs, acceptance criteria paragraphs, and dependency declarations from the document to construct a list of functional points.

[0133] Step 3: Perform a four-dimensional review on each function point: (1) Testability review: check whether the function description can be transformed into verifiable pass or fail conditions; if the description contains vague words such as "may" or "suggestion", mark it as a review opinion.

[0134] (2) Boundary condition review: In addition to the positive function description, check whether the reverse scenario (such as invalid input), abnormal scenario (such as interruption or timeout), and boundary value (maximum value, minimum value or null value) are covered; generate supplementary suggestions for missing items.

[0135] (3) Dependency review: Extract the explicitly declared dependency modules in the document, cross-compare them with the list of known functional features, and identify potential cross-functional feature interaction risks.

[0136] (4) Review of acceptance criteria: Check whether the acceptance criteria are quantified (e.g., “delay less than or equal to 5 milliseconds” instead of “low delay”), and generate inquiry opinions for unquantified indicators.

[0137] Step 4: Summarize the review results and generate a structured review report by dimension (each comment includes: location, problem description and suggestions).

[0138] Step 5: Output the review report (which can be directly pasted into the collaborative document platform's comment section), update the status of node N1 to "completed," and add it to the test concern list for node N3 to use.

[0139] Output: Quality Assurance Review Comments Report (markup language format) and Test Concern List (JavaScript object notation format).

[0140] 2. Node N2: Product Requirements Document Review Processor.

[0141] Triggering conditions: When the input event is a PRD draft release event (such as the PRD_DRAFT_PUBLISHED event) or a code freeze notification event (such as the CODE_FREEZE_NOTIFIED event) and the preceding state condition is unconstrained, the triggering node is the PRD review node (referred to as N2).

[0142] Input: Product requirements document (Uniform Resource Locator for collaborative document platform).

[0143] The processing steps include: Step 1: Retrieve the product requirements document content, parse the requirements table (including identifier column, priority column, version number column, responsible person column, and project management tool identifier column), and build a structured list of requirements items.

[0144] Step Two: Read the entire text to establish semantic understanding (this step is a prerequisite and cannot be combined with Step Three - that is, understand the entire text first, and then perform item-by-item checks).

[0145] Step 3: Perform the product requirement document review checklist according to the following four dimensions: (1) Dimension A (structural integrity): Check whether the requirement identifiers are consecutive without skipping numbers; whether the person in charge and project management tool identifier are filled in for each requirement; whether the priority field has an undetermined status such as "to be confirmed"; whether the version number field is blank.

[0146] (2) Dimension B (Requirement Measurability): For each highest priority (P0) or second highest priority (P1) requirement, check whether there are quantitative indicators or clear verification methods; check whether there is a contradiction between "may be needed" and high priority labeling; check whether the scope has been locked (no open description).

[0147] (3) Dimension C (Cross-version consistency): Compare the version number in the title of the product requirement document with the version number field of all entries to identify entries mixed in with future version requirements; check whether there is a destination declaration for requirements of deleted or changed versions.

[0148] (4) Dimension D (text quality): detect typos in the text (based on the rule base); identify content that appears repeatedly inside and outside the product requirement document (repetition inside and outside the table); check whether the semantics of the status markers in the signature confirmation form are defined.

[0149] Step 4: Generate a review report, with each issue labeled with: dimension attribution, specific location, issue description, recommendations, and severity (not approved, risky, or approved).

[0150] Step 5: Write the product requirements document to the cache (for subsequent node N5 change detection), and update the node N2 status to complete.

[0151] Outputs: Product requirements document review report (four-dimensional structured, which can be directly submitted to the product requirements document manager as a signed confirmation feedback) and requirements coverage matrix (JavaScript object notation format, for use by node N3).

[0152] 3. Node N3: Test plan generation processor.

[0153] Triggering condition: When the input event is a PRD approval event (such as the PRD_SIGNED_OFF event) and the prerequisite state condition is that N2 has been completed, the triggering node is the test plan generation node (referred to as N3).

[0154] Input: Product requirements document (cached), reference test plan (from sibling product lines of the same version).

[0155] The processing steps include: Step 1: Read the product requirement document cache (which has been pulled in the N2 stage), extract all requirement items, and sort them by component or priority.

[0156] Step 2: Pull the reference test plan (sibling product lines, for example, product A references the same version of product B's test plan), and extract the chapter structure, the coverage strategy sample of the requirement acceptance form, and the risk item sample.

[0157] Step 3: Requirement Difference Analysis - Compare the current product line's product requirement document with the reference product line's product requirement document, and identify the following information based on the comparison results: (1) Common requirements (shared across product lines): marked as coverage strategies that can be directly reused from the reference test plan; (2) Unique requirements (specific to this product line): marked as coverage strategies that need to be designed from scratch; (3) Differential requirements (similar but different): marked as differentiated adjustments that need to be made based on the reference strategy.

[0158] Step 4: Generate a test plan skeleton, which includes seven chapters of the team's standard structure: signature confirmation, test scope (including software development kits, documents and peripherals), test strategy (including requirement acceptance form and strategies for each test type, admission and exit criteria and test case list), schedule, test resources, risks and test reports.

[0159] Step 5: Fill in the requirement acceptance form - For each requirement item, fill in the component, priority, description, test coverage (initial coverage strategy suggestion) and status (initially not started).

[0160] Step Six: Generate a Risk List – Match applicable entries (equipment, process, upgrade, or human resources) from the risk rule base, and combine them with risk points specific to this version (extracted from the node N1 test focus list and node N2 review comments).

[0161] Step 7: Save the test plan to the local cache directory, and optionally push it to the collaborative document platform (through the push sub-process).

[0162] Output: Structured test plan (in team standard format, markup language and collaborative document platform hypertext markup language).

[0163] 4. Node N4: Functional characteristic acceptance processor.

[0164] Triggering condition: When the input event is a functional acceptance request event (such as the FEATURE_ACCEPTANCE_REQUEST event) and the prerequisite state condition is the existence of a corresponding design specification document, the triggering node is the functional acceptance node (referred to as N4).

[0165] Input: Uniform Resource Locator (URL) for the design specification document (linked to the design document for the corresponding functional feature).

[0166] The processing steps include: Step 1: Retrieve the design specifications, extract the list of functional points and acceptance criteria.

[0167] Step 2: Perform cross-checks on the test concern list generated for node N1 (if it exists) to supplement any acceptance criteria that were missed in the node N1 phase.

[0168] Step 3: Generate an acceptance checklist. Each checklist item includes: a description of the function, a verification method (operation steps), a quantitative pass / fail standard, and a pass / fail judgment box.

[0169] Step 4: Sort the checklist by priority (highest priority acceptance criteria take precedence), and output an acceptance document that can be executed directly.

[0170] Output: Functional feature acceptance checklist (format and markup language can be selected by checking boxes).

[0171] 5. Node N5: Change Detection and Incremental Update Processor.

[0172] Triggering conditions: When the input event is a PRD update event (such as the PRD_UPDATED event), a defect fix code merging event (such as the BUG_FIX_MERGED event), or a temporary feature merging event (such as the TEMP_FEATURE_MERGED event) and the prerequisite state condition is that there is an existing test plan cache, the triggering node is the change detection and incremental update node (referred to as N5).

[0173] Input: The latest product requirements document (Uniform Resource Locator) and cached version (local cache); or change description (defect identifier or feature identifier and description of affected modules).

[0174] In the scenario of updating product requirement documents, the processing steps may include: Step 1: Retrieve the latest product requirement document and perform a semantic-level comparison (non-text-level difference comparison) with the cached version.

[0175] Step 2: Perform semantic comparison for each requirement identifier and determine the change type for each change item: (1) New requirement: There is no corresponding identifier in the cached version; (2) Requirement removal: The identifier disappears in the current version - further determine it as "delayed" (the version number field is changed to a future version) or "cut" (no destination declaration); (3) Content modification: The identifier exists but the description, priority or version number field changes - assess the impact on test coverage; (4) Priority change: The priority field changes - the highest priority needs to be increased to supplement the second highest priority test, and the highest priority can be reduced to reduce the coverage density; (5) Version number field change: such as the current version number disappearing or becoming blank - determine it as delayed.

[0176] Step 3: Generate a change list and classify it by impact level (high impact: changes in coverage; medium impact: adjustments to test priority; low impact: text quality issues).

[0177] Step 4: Assess which sections of the test plan need to be updated (requirements acceptance form, coverage strategy, scheduling, or risks).

[0178] Step 5: For each impact assessment, generate specific incremental modification suggestions for the test plan (down to the table row level).

[0179] Step 6: Execute incremental update of test plan, generate updated version, and mark the source of change (date and triggering event).

[0180] Step 7: Delayed requirements trigger cross-version flow rotation process - The current version test plan retains the entry and marks it "Move to XY0, this version will not overwrite"; the target version draft file adds the corresponding entry, indicating the source version and original identifier.

[0181] Step 8: Overwrite the local cache with the new version of the product requirements document and update the document version history.

[0182] In the scenario of defect repair merging or temporary feature merging, the following processing steps may be included: Step 1: Receive change description (defect identifier or feature identifier and description of affected modules).

[0183] Step 2: Locate the affected requirement items in the requirement acceptance table of the test plan.

[0184] Step 3: Assess the impact of the changes on the coverage strategy (whether new regression test cases are needed, and whether the expected results of existing test cases will be affected).

[0185] Step 4: Generate incremental update suggestions and output the updated version of the test plan.

[0186] Outputs: Change list (by impact level), post-update test plan, and draft target version (if there are delays).

[0187] For example, in a specific example, when node N5 handles a product requirement document update scenario, its internal data flow and branching logic are as follows: Node N5's data comes from two branches: the latest PRD (Latest PRD, i.e., the current version document) and the cached PRD (Cached PRD, i.e., the previous version snapshot). Both are input into the requirement ID alignment module, which aligns the requirement identifier dimension through diff / merge operations. The aligned requirement entries enter the semantic type determination module, and the determination results are divided into four categories: addition, modification, postponement, and deletion. Among them, changes in the postponement type will trigger the postponement scenario branch, which then flows to the cross-version transfer module. This module executes the "suspend → append to next version" logic, and finally outputs to the v(n+1) test plan to append the postponed requirement entry, retaining the original ID and the original version. In addition, changes of the type of addition, modification, and deletion flow to the Impact Classification module, which classifies changes into three levels according to their impact: urgent, important, and general. Changes after classification flow to the Incremental Test Plan Update module, which performs differential collection input, version tracking processing, and finally outputs to the current version test plan.

[0188] 6. Node N6: Use case judgment processor.

[0189] Triggering conditions: When the input event is a code freeze notification event (such as the CODE_FREEZE_NOTIFIED event) or a release scope confirmation event (such as the RELEASE_SCOPE_CONFIRMED event) and the prerequisite state condition is that the test plan has been generated, the triggering node is the test case judgment node (referred to as N6).

[0190] Input: Test plan (including requirements acceptance form and coverage strategy) and test case pattern library (structured JavaScript object representation format).

[0191] The processing steps include: Step 1: Read the requirement acceptance table in the test plan and extract the coverage strategy declaration for each requirement.

[0192] Step 2: Read the use case pattern library (pattern samples extracted from the existing use case library, including use case titles, coverage points, and module affiliation).

[0193] Step 3: Perform test case matching for each requirement: (1) First case: There are test cases in the existing test case library that cover the requirement point, output a list of matching test case identifiers; (2) Second case: The existing test case coverage direction is correct, but the expected results or test conditions need to be adjusted, that is: the test case needs to be modified, then point out the specific modification points; (3) Third case: There are no existing test cases covering the requirement, generate a test case outline suggestion (module affiliation, test case title, priority, coverage points and suggested test methods), that is, new test cases need to be added.

[0194] Step 4: From the perspective of test layering strategies (e.g., smoke testing, basic function testing, full function testing, or extended function testing), evaluate the test layer to which each test case should belong.

[0195] Step 5: Generate a use case change suggestion report, which is summarized into three categories: "new, modified, or confirmed to continue". This report can be directly used as input for use case review.

[0196] Output: Test case change suggestion report (categorized and summarized in markup language format) and new test case outline (can be imported into test management tools).

[0197] Through the coordinated work of the above six nodes, the graphics processor software testing process can be automated and standardized.

[0198] Fourth layer: Knowledge base layer.

[0199] The knowledge base layer is used to store various structured knowledge required for system operation, which is called by the decision engine layer and the execution layer. The coverage strategies, risk assessment rules, historical quality data and other contents called by the above layers during the execution process are the specific forms of structured knowledge stored in the knowledge base layer. The knowledge base module consists of: (1) Coverage strategy template library: maintains templates according to test type (function, performance, stability, compatibility, installation) and product form, and is called when node N3 generates test plans. (2) Risk assessment rule library: maintains typical risk items for graphics processor software testing (hardware dependency risk, driver compatibility risk, multi-operating system version verification risk, test environment resource risk), and is called when node N3 generates risk chapters of test plans. (3) Historical quality database: stores the defect density distribution of historical versions (statistics by module or test type), and is used as a reference for high-risk areas when node N2 reviews product requirement documents. (4) Use case pattern library: pattern samples extracted from the existing use case library, including use case title patterns, coverage point keywords, and precondition templates, and is called when node N6 matches use cases. (5) Text quality rule base: List of common typos and redundant expression patterns, called when reviewing the text quality dimension at node N2. (6) Product line difference configuration: Maintains the differences in software configuration packages, unique function tags, and shared core component lists for each product line, called when performing difference analysis at node N3.

[0200] Fifth layer: Multi-product line coordination layer.

[0201] The multi-product-line coordination layer is used to manage the parallel execution of quality assurance activities and the reuse of test assets across multiple product lines. The mechanism described above, which maintains state machine instances for different instantiated objects and enables asset reuse, is the specific implementation of the multi-product-line coordination layer. Specifically, the coordination mechanism includes the following steps: Step 1: Parallel state maintenance. An independent quality assurance state machine instance is maintained for each product line and each version, supporting parallel processing of different nodes by three product lines of the same version. For example, product B has reached node N3, product A is still at node N2, and product C has just triggered node N1. This parallel mechanism is applicable to scenarios involving the same business function but different terminal types, such as scenarios where mobile phones, computers, laptops, and watches share graphics processor driver software, or scenarios where graphics processor hardware has subtle differences between layers. Each scenario corresponds to one instantiated object, and each instantiated object maintains one state machine instance.

[0202] Step Two: Shared Asset Trigger Mechanism. Once any product line completes the generation of the N3 test plan, the system automatically registers the product line's acceptance test plan and coverage strategy to the shared resource pool, allowing other product lines to use it as a reference test plan when executing N3. For example, if a graphics processor supports video playback, the mobile phone and computer product lines can reuse the generated test coverage strategy for this function.

[0203] Step 3: Cross-Product Line Consistency Check. When the node N2 review results for multiple product lines of the same version are all available, the system automatically performs a cross-product line product requirement document consistency check. This check aims to identify requirements with the same name that exist in product requirement documents across multiple product lines but have inconsistent descriptions, and generates consistency prompts. For example, the acceptance criteria for a certain feature in the product requirement document of product B may be inconsistent with those in the product requirement document of product A. This check mainly targets differences in the textual descriptions of business functions, including differences in the use of synonyms or near-synonyms. In practical implementation, a text recognition model can be introduced for judgment, and consistency checks between product lines can be achieved through semantic segmentation and recognition comparison.

[0204] Step 4: Shared Use Case Identification. When Node N6 performs use case judgment, the system scans for confirmed use cases from other product lines (by matching the use case pattern library), marks highly similar use cases as reusable candidates, and includes them in the product line's use case library after confirmation by the quality assurance engineer, thus avoiding duplicate writing.

[0205] Step 5: Coordination Layer Report Output. Regularly generate a multi-product line quality assurance activity progress overview (current stage of each product line, list of pending tasks, cross-product line risk alerts) to support overall progress management.

[0206] To more clearly illustrate the operational mechanism of the above five-layer architecture in actual work, this example uses a graphics processor driver testing team as an example to describe in detail the system workflow when three product lines, such as Product A (desktop version), Product B (server version), and Product C (System on Chip, SoC version), release a graphics processor driver version (hereinafter referred to as version N) in parallel.

[0207] The scenario is as follows: The team consists of approximately 10 quality assurance engineers, each responsible for one of three product lines. Products A, B, and C share the same graphics processor core drivers, such as the Direct Rendering Manager / Kernel Mode Setting (DRM / KMS) module and the Mesa graphics library. However, each has its own independent upper-level functionalities, such as multi-monitor output management for Product A, multi-GPU parallel computing configuration for Product B, and low-power edge inference mode for Product C. The development cycle for version N is approximately 3 months, and the Product Requirements Document (PRD) will undergo multiple updates during this period.

[0208] In practice, the implementation includes the following stages: Stage 1: Design period (1 to 2 weeks after the start of version N development).

[0209] Phase 1 specifically includes the following steps: Step 1: The development engineer submits the design specification (Design Spec) of the video decoding acceleration interface feature of Product B to the document collaboration platform, triggering the Design Specification Submitted (DESIGN_SPEC_SUBMITTED) event.

[0210] Step 2: The event awareness layer receives the event, extracts the document Uniform Resource Locator (URL), constructs the event message, and writes it to the event queue.

[0211] Step 3: The decision engine layer queries the quality assurance status of product B version N, for example, if it is currently idle (IDLE), matches the routing rules, and triggers the design specification review node (called N1).

[0212] Step 4: Design Specification Review. The processor (N1 processor) retrieves the design specification document and performs a four-dimensional review (testability, boundary conditions, dependencies, and acceptance criteria). Taking the video decoding acceleration interface as an example, the processor identifies that the description of supporting devices with 16 gigabytes (GB) of video random access memory (VRAM) or more lacks boundary conditions (whether the exact boundary case of 16 gigabytes is supported), and generates the review opinion "Suggested addition: processing strategy and corresponding testing method when the video memory is exactly 16 gigabytes".

[0213] Step 5: Output the review report, archive it locally, update the status of node N1 to complete, and write the test concern list (including 6 boundary condition reminders).

[0214] Step Six: In parallel, two design specifications are submitted for each of Product A and Product C. The multi-product line coordination layer creates independent node N1 task instances for each of the three product lines, executes them in parallel, and generates review comments for each.

[0215] Phase Two: Requirements Lock-in Period (3 to 4 weeks after development begins).

[0216] Phase Two specifically includes the following steps: Step One: The product manager publishes the draft of the product requirements document for version N (containing 35 requirements), triggering the "Product Requirements Document Draft Published" (PRD_DRAFT_PUBLISHED) event (each of the three product lines has its own independent product requirements document).

[0217] Step 2: The decision engine triggers the product requirement document review node (called N2) for each of the three product lines, and the multi-product line coordination layer schedules three N2 processor instances in parallel.

[0218] Step 3: Product Requirements Document Review Processor (N2 Processor) Perform a four-dimensional checklist for the product requirements document review. Taking the product requirements document for Product B as an example: Dimension A (Structural Integrity) found that the requirement identifier jumps from R001 to R003 (R002 is missing), the Person In Charge (PIC) column has 8 blank entries, and the project management tool identifier (Jira ID) only covers 18 / 35 entries; Dimension B (Requirement Testability) found that R015 (Optimize Graphics Processor Computing Performance) has no quantifiable baseline, and R022 is marked as the highest priority (P0) but the description includes the possibility of needing to be implemented; Dimension C (Cross-Version Consistency) found that the version number fields of R031 to R035 are empty (it is not clear which version they belong to); Dimension D (Text Quality) found that the description of R019 is "keep it consistent" (it should be "keep it consistent").

[0219] Step 4: After all three product line nodes N2 are completed, the multi-product line coordination layer performs a cross-product line consistency check, identifies that the priority of the graphics processor driver installation process is inconsistent in the product requirement documents of product A and product B (product A label, product B label), and generates a consistency prompt message.

[0220] Step 5: The Quality Assurance Manager aligns with the Product Manager based on the three Node N2 review reports, and the Product Requirements Document is revised and signed off (PRD_SIGNED_OFF).

[0221] Phase 3: Test plan generation period (2 to 3 days after approval).

[0222] Phase 3 specifically includes the following steps: Step 1: The signing and confirmation of the product requirements document triggers the test plan generation node (referred to as N3) for the three product lines.

[0223] Step 2: Taking Product B node N3 as an example, the processor completes the following first (assuming Product B's product requirement document was approved earliest): pulls Product B's product requirement document (already cached, read directly), parses 35 requirements; since there is no reference test plan for the same version of sibling product lines, the test plan of the previous version (version N-1) of Product B is called as a reference; generates the Product B version N test plan, containing 35 requirement acceptance table entries, and the risk section includes the dependency on test equipment with video memory greater than or equal to 16 gigabytes (from the test concern of node N1); the test plan is registered to the shared resource pool.

[0224] Step 3: When Product A node N3 starts, the multi-product line coordination layer prompts that the product B version N test plan can be used as a reference. The product A node N3 processor calls the reference to identify 23 common requirements (direct reuse of the coverage strategy) and 8 product A unique requirements (requiring a new design strategy), which significantly improves the generation efficiency.

[0225] Step 4: Once the test plans for the three product lines are generated, save them locally and push them to the collaborative document platform. The status of node N3 will be updated to "completed".

[0226] Phase 4: Development Iteration Period (lasting 6 to 8 weeks, with incremental updates to the test plan).

[0227] Phase four includes the following steps: Step one: Mid-development, the product manager updates the product requirements document (version N) for product B, triggering the Product Requirements Document Updated (PRD_UPDATED) event. The change detection and incremental update node (called N5) processor starts, and semantic comparison reveals that: the R031 version number changes from blank to version N+1 (delayed), the R022 priority is downgraded from the highest priority to the second highest priority (P1), and R036 (4K High Dynamic Range (HDR) video decoding support) is added.

[0228] Step 2: Node N5 generates a change list: R031 triggers the cross-version flow rotation process (marks the current test plan as moving to version N+1, creates a version N+1 draft file and adds entries), R022 adjusts test priority (updates the corresponding row in the requirement acceptance table), and R036 adds a coverage strategy design.

[0229] Step 3: Simultaneously, multiple functional features are developed and submitted for acceptance (Functional Acceptance Request (FEATURE_ACCEPTANCE_REQUEST)). The functional acceptance node (referred to as N4) concurrently processes the generation of 4 acceptance checklists, and the quality assurance engineer performs the acceptance one by one.

[0230] Phase 5: Release preparation period (1 week before code freeze).

[0231] Phase 5 includes the following steps: Step 1: Code freeze notification (CODE_FREEZE_NOTIFIED) event trigger: The final version node N2 of the three product lines reviews the product requirement documents (confirming that there are no missing requirements in the final product requirement documents); the use case judgment node (called N6) of the three product lines performs use case judgment (confirming the completeness of use case coverage).

[0232] Step 2: The test case judgment processor (N6 processor) performs test case matching on the 31 requirements of the product A test plan, and outputs: 21 existing test cases can be used, 7 need to be modified, and 3 need to be added. It generates a new test case outline (including priority and coverage suggestions). The quality assurance engineer then completes the test case review and puts it into the database in the test management tool.

[0233] Step 3: The system outputs a multi-product line quality assurance activity completion report, and the test manager confirms that all three product lines meet the release-ready criteria.

[0234] Additionally, this example can also implement cross-version requirement transfer operations: For example, a requirement in the version N test plan (such as REQ-031) is marked as "delayed / moved to version N+1" because its dependency is not ready (such as NPU hardware); this requirement is transferred to the version N+1 test plan draft through "cross-version batch" and included in the form of "migration" (retaining the original ID, source version, and migration date); finally, with the official release of version N+1 PRD, it triggers the subsequent N2 review, N3 test plan regeneration, and requirement closed-loop verification and test case execution. The above approach has at least the following advantages: (1) Continuity of requirements: The original information (ID, source, date) of delayed requirements is retained through the migration mechanism to avoid loss of requirements or duplicate design; (2) Version connection: The requirement flow path from version N to N+1 is clearly defined (test plan → draft → PRD release), supporting requirement management for multiple version iterations; (3) Automated triggering: After the version N+1 PRD is released, the N2 review and N3 test plan regeneration are automatically triggered to reduce manual intervention and improve process efficiency; (4) Closed-loop verification: After the requirement is migrated in, it is implemented through "closed-loop verification → test case execution guarantee", which can strengthen quality control.

[0235] This example, through the above process, achieves the following beneficial effects: First, the timeliness of quality assurance response is significantly improved. The event-driven mechanism transforms the triggering of quality assurance activities from manual perception (with delays ranging from hours to days) to automatic response (within minutes), effectively expanding the testing window in graphics processor software teams with iteration cycles of 2 to 4 weeks.

[0236] Second, the efficiency of requirement change processing is improved. Semantic change detection replaces manual comparison of each item, reducing the impact analysis of product requirement document changes from 2 to 4 hours of manual work to minutes of automatic output, and is not affected by differences in engineers' individual experience, resulting in higher coverage consistency.

[0237] Third, the cost of multi-product line collaboration is reduced. The cross-product line test plan reference reuse mechanism reduces the design cost of coverage strategies for common requirements by about 60% (based on an estimated 65% common requirement ratio across the three product lines), while automatically identifying cross-product line inconsistencies and reducing omissions.

[0238] Fourth, quality assurance knowledge is systematically accumulated. Covering strategy template libraries, risk assessment rule libraries, and use case pattern libraries transforms quality assurance knowledge from tacit experience into structured assets that can be called upon by the system. This improves the onboarding efficiency of new members, and knowledge transfer no longer depends on personnel stability.

[0239] Fifth, test plan quality standardization. The standardized six-node workflow and product requirements document review checklist eliminate differences in process execution caused by individual engineer differences, and quality assurance activities for each version are performed according to the same quality standards.

[0240] Sixth, the quality assurance decision-making layer is separated from the execution layer. The decision engine is responsible for business judgment (what to trigger and when to trigger), while the execution layer is responsible for standardized execution (how to execute). Quality assurance users do not need to participate in the execution details, thus improving management efficiency.

[0241] Figure 3 A schematic diagram of the structure of a testing apparatus for a graphics processor according to another embodiment of this disclosure is shown, as follows. Figure 3 As shown, the device includes: a detection module 31, adapted to detect a trigger event corresponding to the graphics processor and determine the event type of the trigger event; an acquisition module 32, adapted to acquire the quality assurance status of the instantiated object corresponding to the trigger event; a selection module 33, adapted to select a target node from multiple quality assurance activity nodes according to the combination relationship between the event type and the quality assurance status; and a testing module 34, adapted to generate a test task corresponding to the trigger event through the target node and execute the test task to test the graphics processor.

[0242] The specific working principles of each of the above modules can be found in the descriptions of the corresponding parts in the method embodiments, and will not be repeated here.

[0243] This disclosure also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the processor is configured as described above.

[0244] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0245] Figure 4 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0246] Reference Figure 4 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by at least one processor 701, and the one or more computer programs are executed by at least one processor 701 to enable at least one processor 701 to perform the above-described graphics processor testing method.

[0247] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the above-described method. The computer-readable storage medium may be volatile or non-volatile.

[0248] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0249] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0250] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0251] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0252] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0253] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0254] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0255] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0256] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0257] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0258] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A method for testing a graphics processing unit, characterized in that, include: Detect the trigger event corresponding to the graphics processor and determine the event type of the trigger event; Obtain the quality assurance status of the instantiated object corresponding to the triggering event; Based on the combination relationship between the event type and the quality assurance status, a target node is selected from multiple quality assurance activity nodes; The target node generates a test task corresponding to the triggering event, and the test task is executed to test the graphics processor.

2. The method according to claim 1, characterized in that, The instantiated object is used to represent the version information, hardware parameter information, and / or terminal type information of the graphics processor; Furthermore, when the graphics processor has multiple instantiated objects, before obtaining the quality assurance status of the instantiated object corresponding to the triggering event, the process further includes: Extract the object identifier contained in the triggering event; Based on the object identifier, select the instantiated object corresponding to the triggering event from among the plurality of instantiated objects.

3. The method according to claim 2, characterized in that, The step of generating the test task corresponding to the triggering event through the target node includes: Through the target node, select the shared requirement information corresponding to the business function to be tested from the test requirement data stored in the shared resource pool; Based on the test coverage strategy corresponding to the shared requirement information, a test task corresponding to the triggering event is generated; Furthermore, after executing the test task, the method further includes storing the test requirement data corresponding to the test task in the shared resource pool.

4. The method according to claim 3, characterized in that, The test requirement data stored in the shared resource pool includes: multiple test requirement lists corresponding to multiple instantiated objects; The step of selecting shared requirement information corresponding to the business function to be tested from the test requirement data stored in the shared resource pool includes: Based on the graphics processor component that the business function to be tested depends on, a reference instantiated object is selected from the plurality of instantiated objects; wherein, the reference instantiated object and the instantiated object corresponding to the triggering event share the graphics processor component that the business function depends on; Select the shared requirement information corresponding to the business function to be tested from the test requirement list of the reference instantiated object.

5. The method according to claim 4, characterized in that, Each test requirement list is used to store the correspondence between the requirement description information of the corresponding instantiated object and the test coverage strategy; The method further includes: For multiple associated instantiated objects that share the same graphics processor component, extract multiple requirement description information of the multiple associated instantiated objects; If inconsistencies are detected in the descriptions of the same business function among the multiple requirement descriptions, a consistency prompt message is generated. The inconsistencies in the description of the same business function include: inconsistent priority definitions, inconsistent acceptance criteria, and / or inconsistent version attribution for the same business function.

6. The method according to claim 4, characterized in that, The multiple instantiated objects correspond to multiple state machine instances, and each state machine instance is used to record the quality assurance status of the corresponding instantiated object; In this scenario, different instantiated objects may be at different quality assurance activity nodes at the same point in time; or, different instantiated objects may be at different processing stages within the same quality assurance activity node at the same point in time.

7. The method according to any one of claims 1-6, characterized in that, The quality assurance status includes: completed node records and / or test cache data; Furthermore, the event types that trigger the event include: file entry type, content change type, and node status type; The multiple quality assurance activity nodes include: review node, test plan generation node, functional acceptance node, change node, and test case judgment node.

8. The method according to claim 7, characterized in that, The step of selecting a target node from multiple quality assurance activity nodes based on the combination relationship between the event type and the quality assurance status includes: If the triggering event is of the file entry type and the test cache data is empty, then the review node is selected as the target node; If the triggering event is of the content change type and the test cache data is not empty, then the changed node is selected as the target node; If the triggering event is a node state type and the completed node record contains a completed preset preceding node, then the function acceptance node is selected as the target node.

9. The method according to any one of claims 1-6, characterized in that, After executing the test task, the process also includes: Obtain the execution result of the test task, and update the quality assurance status of the instantiated object based on the execution result.

10. A testing apparatus for a graphics processor, characterized in that, include: The detection module is adapted to detect trigger events corresponding to the graphics processor and determine the event type of the trigger event; The acquisition module is adapted to acquire the quality assurance status of the instantiated object corresponding to the triggering event; The selection module is adapted to select a target node from multiple quality assurance activity nodes based on the combination relationship between the event type and the quality assurance status; The testing module is adapted to generate a test task corresponding to the triggering event through the target node, and execute the test task to test the graphics processor.

11. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The processor is configured to perform the method of any one of claims 1-9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program, when executed by a processor, implements the method as described in any one of claims 1-9.

13. A computer program product comprising computer-readable code, characterized in that, When the computer-readable code is run in an electronic device, the processor in the electronic device performs the method of any one of claims 1-9.

Images