Data processing method and system

Abstract

The present disclosure provides a data processing method and system, the method comprising: extracting software test data from a plurality of received test case files; generating a plurality of structured files corresponding to the plurality of test case files according to the software test data, and constructing a shared workspace for a client and an agent according to the plurality of structured files; in a case where a first data adjustment request sent by the client is received, determining a first structured file corresponding to the first data adjustment request from the shared workspace, and performing data adjustment on the first structured file to obtain an adjusted first structured file; and in a case where a second data adjustment request generated by the agent is obtained, determining a second structured file corresponding to the second data adjustment request from the shared workspace, and performing data adjustment on the second structured file to obtain an adjusted second structured file. The embodiments of the present disclosure can flexibly process software test data.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a data processing method and system. Background Technology

[0002] With the continuous development of computer technology, software test cases, as important data in the software quality assurance process, often require management tasks such as data updates, data maintenance, and data import / export.

[0003] Currently, the management of software test cases can be achieved through a combination of manual management and automated maintenance by intelligent agents. However, there are significant differences in the data format between manually managed and agent-managed software test cases. Therefore, how to ensure that software test cases maintain a visual and manually editable data format while also providing automated maintenance by intelligent agents has become a pressing technical problem that needs to be solved. Summary of the Invention

[0004] This disclosure provides a data processing method and system, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] In a first aspect, this disclosure provides a data processing method, which includes: extracting software test data from multiple received test case files; wherein the test case files are files generated during software testing; generating structured files corresponding to the multiple test case files based on the software test data, and constructing a shared workspace for a client and an agent based on the multiple structured files; upon receiving a first data adjustment request sent by the client, determining a first structured file corresponding to the first data adjustment request from the shared workspace, and adjusting the data in the first structured file to obtain an adjusted first structured file; upon receiving a second data adjustment request generated by the agent, determining a second structured file corresponding to the second data adjustment request from the shared workspace, and adjusting the data in the second structured file to obtain an adjusted second structured file.

[0006] Secondly, this disclosure provides a data processing system, which includes: an intelligent agent, a data extraction module, a file generation module, a data adjustment module, and an intelligent agent harness module.

[0007] The data extraction module is used to extract software test data from multiple received test case files; wherein, the test case files are files generated during the software testing process.

[0008] The file generation module is used to generate structured files corresponding to the multiple test case files based on the software test data, and to build a shared workspace for the client and the agent based on the multiple structured files.

[0009] The data adjustment module is used to, upon receiving a first data adjustment request sent by the client, determine the first structured file corresponding to the first data adjustment request from the shared workspace, and perform data adjustment on the first structured file to obtain the adjusted first structured file.

[0010] The intelligent agent harness module is used to determine the second structured file corresponding to the second data adjustment request from the shared workspace when a second data adjustment request is received from the intelligent agent, and to adjust the data of the second structured file to obtain the adjusted second structured file, wherein the first structured file and the second structured file are the same structured file or different structured files.

[0011] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the data processing method described above.

[0012] 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 data processing method.

[0013] 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 data processing method described above.

[0014] The data processing method provided in this disclosure can extract software test data from multiple received test case files, generate structured files corresponding to the multiple test case files based on the software test data, and construct a shared workspace for the client and the agent based on the multiple structured files, thereby enabling the client and the agent to jointly process the structured files in the shared workspace. Upon receiving a first data adjustment request sent by the client, the method determines the first structured file corresponding to the first data adjustment request from the shared workspace, adjusts the data in the first structured file, and obtains an adjusted first structured file. Similarly, upon receiving a second data adjustment request generated by the agent, the method determines the second structured file corresponding to the second data adjustment request from the shared workspace, adjusts the data in the second structured file, and obtains an adjusted second structured file. This allows the test case files to maintain a visual and manually editable data format while also providing automated maintenance for the agent, achieving flexible processing of software test data.

[0015] 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

[0016] 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 detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 This is a flowchart of a data processing method provided in an embodiment of the present disclosure.

[0018] Figure 2 This is a flowchart illustrating the establishment of a shared workspace in a data processing method provided in an embodiment of this disclosure.

[0019] Figure 3 This is a schematic diagram illustrating the sharing of the same fact source between manual editing and intelligent agent maintenance in a data processing method provided in an embodiment of this disclosure.

[0020] Figure 4 This is a block diagram of a data processing system provided in an embodiment of the present disclosure.

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

[0022] 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.

[0023] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0024] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0025] 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.

[0026] 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.

[0027] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations. For example, appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identification is eliminated when using personal information to avoid precisely targeting specific individuals.

[0028] The technical terms used in the embodiments of this disclosure are explained below.

[0029] Test case files, also known as test case assets, are structured data collections containing information such as test case titles, preconditions, test steps, expected results, test data, test results, priorities, and descriptions.

[0030] Local structured file workspace: This refers to the workspace on the user's local file system where test case assets are stored in the form of directories and structured files. These structured files can be JSON files, YAML, XML, or other machine-parseable structured files.

[0031] Intelligent agent: refers to an automated software processing unit that can read context, invoke tools, modify files, generate differences, run verification, and continue to correct based on feedback.

[0032] Agent harness: refers to an engineered working system, outside of model weights, used to enable agents to work reliably in specific tasks. It includes five components: instructions, tools, environment, state, and feedback. The environment may include a local structured file workspace accessible to the agent, and the feedback may include structure verification results, tool execution results, user review comments, and repair suggestions.

[0033] Fact source: refers to the data source that is jointly accessed by the user editing channel and the agent maintenance channel and used to generate derived states; in embodiments with controlled write capabilities, the two can jointly read and write the data source under permission and work area boundary constraints.

[0034] Current changes: refers to the addition, modification, renaming, or deletion of test case assets in the current workspace relative to the activity baseline.

[0035] Snapshot: refers to the version record formed in the test case asset workspace at a certain point in time, including content hash, file path, commit file list, baseline relationship, and version facts used to restore or switch to a specified historical snapshot.

[0036] Difference fragments: These are structured data used to express the differences between old and new content, and include old files, new files, and one or more difference blocks organized by location.

[0037] External test management platform: refers to an enterprise's existing test management system, R&D collaboration system, or other external systems used to store, synchronize, execute, or review test cases.

[0038] With the continuous development of computer technology, software test cases, as crucial data in the software quality assurance process, often require management tasks such as data updates, maintenance, and import / export. Currently, the management of software test cases can be achieved through a combination of manual management and automated maintenance by intelligent agents; however, there are significant differences between the data formats of manually managed software test cases and those managed by intelligent agents.

[0039] Specifically, software test cases are crucial data in the software quality assurance process. Existing test cases are typically stored in the form of Excel spreadsheets, test management platform databases, external test management platform records, or semi-structured documents. While these storage methods are suitable for manual viewing, centralized management, import / export, and workflow approval, they are not conducive to automated maintenance, especially automated maintenance performed by intelligent agents.

[0040] In Excel-based test case management, test cases are typically expressed in rows and columns. Fields such as test steps, expected results, preconditions, priorities, execution status, and test data may be split into multiple cells and may be affected by merged cells, line breaks, or formatting information. Humans can understand the semantics of these tables, but intelligent agents struggle to reliably perform batch modifications, reviews, or rollbacks based on directory structure, paths, local context, and file differences.

[0041] In test management platforms or R&D collaboration platforms, test cases are typically stored in a server-side database, and users maintain them through forms, lists, tree directories, or synchronized tasks. This approach facilitates centralized access control and workflow management, but agents cannot directly utilize mature software engineering toolchains such as file reading, full-text search, structured search, difference calculation, command-line verification, version review, and local snapshots. If agents are required to participate in maintenance, users often need to copy and paste context, temporarily export files, or call additional interfaces, resulting in incomplete context, unclear scope of modifications, and broken verification chains.

[0042] In recent years, test case generation solutions based on large language models or intelligent agents have gradually emerged. These solutions primarily focus on generating test scenarios, test steps, or automated scripts from requirements documents, code, page images, user behavior, or natural language descriptions. For example, some solutions input requirements information into an intelligent agent to generate planned paths and test scripts; others generate test cases using large language models and refine them based on coverage, simulation results, or similarity; still others provide a dialog interface, allowing users to describe software functions in natural language and generate test cases. While these solutions improve the efficiency of generating test cases in a single step, they do not fully address the long-term maintenance issues of existing test case assets.

[0043] Furthermore, in real-world enterprise scenarios, test case libraries are not necessarily generated only once. More common tasks include batch adjusting steps based on business changes, fixing expected failures in existing test cases, filling in missing scenarios, reviewing duplicate or conflicting test cases, updating status based on test results, bidirectional synchronization with external platforms, and creating a traceable and rollbackable chain of evidence after modifications. If the agent directly operates on the database or platform interface, problems such as out-of-bounds modifications, inability to review, inability to verify, loss of context, and premature declaration of completion by the agent can easily occur.

[0044] In other words, existing test case editing or management platforms typically use databases or internal platform models as their primary source of facts. Users maintain test cases through the platform interface, and the system supports directory management, import / export, cloud editing, reuse, and report output. However, this implementation makes it difficult for agents to directly understand and maintain test case assets through file systems, search, diffs, and command-line verification. Even if the platform provides an API, agents need to additionally adapt to the interface and request protocol, and cannot naturally read directories, locate files, generate patches, and review diffs as they would when maintaining a code repository.

[0045] While existing Excel or tabular management methods facilitate manual batch data entry, their row-column model is unsuitable for representing the stable asset boundaries required for long-term maintenance. Because test case steps, expected results, preconditions, priorities, and test data may be stored in a mixed format (text blocks or formatted data), agents struggle to reliably determine which fields belong to the same test case, which changes should be included in the review process, and which should remain unchanged when making partial modifications. Therefore, tabular methods increase the cost for agents to understand and maintain test case assets.

[0046] Existing test case generation solutions based on large language models are mostly centered on "generating test cases after inputting requirements or context." Their technical path typically includes requirement parsing, scenario generation, test case generation, script generation, coverage evaluation, or result correction. This type of solution addresses the problem of generating test cases from scratch, but it doesn't necessarily provide a mechanism for transforming an existing test case library into a local structured asset, continuously maintained by an agent, and reviewed and rolled back by users. Simply writing the generated results back to the platform or documentation still lacks the version evidence and verification loop required for long-term maintenance.

[0047] Existing agent-based testing solutions also include techniques that involve agents planning test paths, identifying page interaction elements, and generating test steps or scripts. These solutions tend to automatically explore the system under test and generate test artifacts, rather than performing file-level, incremental, and constrained maintenance on an existing set of test case assets. Even if the generation process includes execution feedback, it may not solve the problem of manual editing and agent modifications sharing the same source of facts.

[0048] While existing general AI programming tools or AI integrated development environments can read and write code files, generate discrepancies, and run verifications, their default processing object is the code file. If test case assets remain confined to Excel, databases, or remote platforms, AI programming tools cannot directly leverage their mature software engineering capabilities. Converting non-code test case assets into a local, structured file workspace that can be maintained by the intelligent agent, and maintaining consistent convergence within the application for manual editing, current changes, snapshots, discrepancy reviews, and external synchronization, is a problem that existing solutions have not fully addressed.

[0049] Based on the above, it can be seen that the existing technology has at least the following defects: First, test case assets lack local structured fact sources that agents can directly explore and maintain; second, manual editing and agent maintenance often operate on different state sources, which can easily lead to conflicts or synchronization inconsistencies; third, the agent maintenance process lacks rules, states, tools, verification, feedback, and observability constraints; fourth, agent modifications lack an evidence chain that combines with activity baselines, current changes, snapshots, and discrepancy reviews; and fifth, after synchronization with external platforms, it is difficult to retain local maintainable assets as the foundation for the long-term operation of agents.

[0050] Based on this, the present disclosure provides a data processing method and system, an electronic device, and a computer-readable storage medium, as detailed in the following embodiments.

[0051] The data processing method according to embodiments of this disclosure can be executed by electronic devices such as terminal devices or servers. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. The server can be a standalone physical server, a server cluster consisting of multiple physical servers, or a cloud server capable of cloud computing. This method can be implemented by a processor calling computer-readable program instructions stored in memory.

[0052] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0053] Figure 1 A flowchart illustrating a data processing method provided in an embodiment of this disclosure. (Refer to...) Figure 1 The method includes:

[0054] Step S11: Extract software test data from the received multiple test case files; wherein, the test case files are files generated during the software testing process.

[0055] The software test data can be understood as the data generated during the software testing process. This software test data includes, but is not limited to, information such as test case titles, preconditions, test steps, expected results, test data, test results, priority, and descriptions.

[0056] In some embodiments, extracting software test data from the received plurality of test case files includes:

[0057] Upon receiving multiple test case files from multiple test data storage systems, the test case files are parsed according to a preset mapping rule to obtain software test data corresponding to the preset mapping rule.

[0058] The test data storage system can be understood as a system used to store the test case file. The test data storage system includes, but is not limited to: Excel file system, database, external test management platform or existing local workspace, etc.

[0059] Preset mapping rules can be understood as rules used to extract software test data from test case files; these preset mapping rules can be set according to actual application scenarios; for example, these preset mapping rules include keyword matching, regular expressions, etc.

[0060] Taking the application of the data processing method provided in this disclosure in a test case scenario as an example, this data processing method will be explained. This disclosure provides a way to file test case assets. Specifically, the data processing system of this disclosure can receive test case assets from an Excel file system, a database, an external test management platform, or an existing local workspace. The system parses software test data such as the directory level, test case identifier, title, preconditions, test steps, expected results, test data, priority, execution status, and description of the test cases according to preset mapping rules.

[0061] As can be seen from the above embodiments, this disclosure can accurately parse test case assets and transform them into standard structured data containing core elements such as directory hierarchy, test case identifier, preconditions, and expected results, ensuring the standardization and consistency of test assets, and also providing a guarantee for the subsequent construction of a unified shared workspace and improving the convenience of data processing.

[0062] In some embodiments, this disclosure can also, upon receiving multiple test case files from multiple test data storage systems, input the multiple test case files into a file processing model for parsing to obtain corresponding software test data. This file processing model includes, but is not limited to, large models, large language models, and convolutional neural network models. By introducing a file processing model, this disclosure can automatically parse the complex file of test case assets based on natural language understanding and visual feature extraction capabilities, thereby achieving fully automated and intelligent extraction of software test data, effectively adapting to the daily iteration and rapid release pace of R&D.

[0063] Step S12: Based on the software test data, generate structured files corresponding to the multiple test case files, and build a shared workspace for the client and the agent based on the multiple structured files.

[0064] In this context, a shared workspace can be understood as a workspace that can be used and managed by both the client and the agent. For example, the shared workspace could be a local structured file workspace.

[0065] In some embodiments, generating structured files corresponding to the plurality of test case files based on the software test data, and constructing a shared workspace for the client and the agent based on the plurality of structured files, includes:

[0066] The software test data of the target test case file is converted into a structured file corresponding to the target test case file, wherein the target test case file is any one of the plurality of test case files;

[0067] Based on the file attribute information of the multiple structured files, construct corresponding file indexes for the multiple structured files;

[0068] Based on the multiple structured files and the file index, the shared workspace is constructed so that the client and the agent can jointly adjust the data of the structured files in the shared workspace.

[0069] Each software test case in this disclosure can correspond to a structured file. Taking the current implementation of the data processing system as an example, this structured file mainly stores the test case identifier, structure version, test case title, priority, preconditions, step array, expected result, test result, test data, and description. The directory to which the test case belongs is not stored as an internal field of the test case file, but is expressed by the relative path of the test case file (i.e., the test case file) in the local workspace, the directory identifier file, and the workspace index. The external platform number or binding relationship is not a necessary field in the core test case file, but can be maintained as optional synchronization information in external synchronization modules, indexes, or mapping records.

[0070] File attribute information can be understood as the attribute information inherent in the structured file itself. This file attribute information includes, but is not limited to: use case identifier, relative path, existence status, normalized complete content hash, structure version, structure status, and structure errors.

[0071] Following the example above, Figure 2 This is a flowchart illustrating the establishment of a shared workspace in a data processing method provided in this embodiment of the disclosure, based on... Figure 2 It can be seen that this specifically includes steps 201 to 208.

[0072] Step 201: Obtain test case data.

[0073] The data processing system disclosed herein can receive test case assets from Excel file systems, databases, external test management platforms, or existing local workspaces.

[0074] Step 202: Parse the directory and fields.

[0075] The system disclosed herein parses software test data such as directory level, test case identifier, title, preconditions, test steps, expected results, test data, priority, execution status, and description of test cases according to preset mapping rules.

[0076] Step 203: Generate the local directory structure.

[0077] Step 204: Generate structured use case files.

[0078] For each test case (i.e., test case file), a corresponding structured file is generated.

[0079] Step 205: Generate directory metadata.

[0080] The system (i.e., the data processing system) can also generate directory metadata files for directory nodes to store use case set identifiers, display names, or sorting information.

[0081] Step 206: Calculate the content hash.

[0082] Step 207: Create a workspace index.

[0083] Step 208: Output the local structured file workspace.

[0084] Specifically, in the process of documenting test case assets, this disclosure requires generating a corresponding structured file for each test case (i.e., test case file). This structured file can be a JSON file and contains a stable test case identifier, structure version, and business fields. The workspace relative path, content hash, existence status, and structure verification status are stored by the workspace index. The system (i.e., the data processing system) can also generate directory metadata files for directory nodes to store test case set identifiers, display names, or sorting information.

[0085] Then, the system builds a file index for each structured file in the local workspace. This index includes workspace facts such as use case identifier, relative path, existence status, normalized complete content hash, structure version, structure status, and structure errors. The directory ownership of structured files is expressed by relative path, directory identifier file, or directory index. External platform number or binding relationship is not a necessary field for core use case files or core workspace indexes; it can be maintained as optional synchronization information in external synchronization modules or mapping records. The system uses this index as the source of workspace facts when subsequently judging current changes, snapshot differences, synchronization scope, and agent review scope.

[0086] In an exemplary implementation, the structured file corresponding to the test case file can use the ".casey.json" suffix, and directory nodes can be represented by directory identifier files. Each structured file includes at least two types of data: system fields and business fields. System fields are used to maintain asset identity and version, such as "$version" and "$id"; business fields are used to express the semantics of the test cases, such as "name", "rank", "preconditions", "steps", "expectedResult", "testResult", "testData", and "desc".

[0087] Among them, "rank" can be enumerated using priorities such as "P0", "P1", "P2", "P3", "P4", "N", etc., "testResult" can be enumerated using states such as "pending", "passed", "failed", etc., and "steps" is an array of steps.

[0088] Test steps can include action steps and conditional steps. Action steps must at least include a step type and a step description, and may optionally include the expected result of that step. Conditional steps, in addition to a step type and step description, may also include a condition object; the condition object may include a condition description and multiple branches, each branch including a branch label, a branch condition, and an array of steps under that branch. Through this structure, the system can express linear steps, nested steps, and conditional branching steps.

[0089] An example test case file is as follows:

[0090] { "$version": 1,

[0091] "$id": "case_11111111-1111-4111-8111-111111111111",

[0092] "name": "Unified Identity Authentication Login Successful",

[0093] "rank": "P1",

[0094] "preconditions": "User account has been registered and is available for login".

[0095] "steps": [

[0096] {

[0097] "type": "action",

[0098] "description": "Enter your username and password",

[0099] "expectedResult": "The input component receives the username and password."

[0100] },

[0101] {

[0102] "type": "action",

[0103] "description": "Submitted a unified identity authentication login request",

[0104] "expectedResult": "System successfully logged in"

[0105] }

[0106] ],

[0107] "expectedResult": "User enters the target business workspace",

[0108] "testResult": "pending",

[0109] "testData": "Username, Password, Tenant ID",

[0110] "desc": "Verify the main login process using unified identity authentication"

[0111] }

[0112] It should be noted that the above test case file is only an example. In actual implementation, the field names, enumeration values, and extended fields can be adjusted according to project rules.

[0113] For example, after importing the current table (i.e., the test case file), fields such as "Test Case Title," "Test Case Hierarchy," "Preconditions," and "Remarks" in the table can be mapped to the corresponding fields in the local structured test case file. The steps and expected results are imported according to the step table structure. If an external platform provides a test case number or directory number, the system can save the external identifier in the synchronization module or mapping record, but it will not use it as a necessary field in the core test case file, nor will it directly replace the local test case identifier or local directory identifier.

[0114] The workspace index can record at least the following fields: use case identifier, relative path, absolute path, existence status, content hash, file size, modification time, indexing time, parsing status, parsing errors, structure version, structure status, and structure errors. The directory index can record at least the directory identifier, relative path, absolute path, existence status, existence of the directory identifier file, and indexing time. These index fields are used to support agent retrieval scope control, current change determination, snapshot comparison, and review view generation.

[0115] As can be seen from the above embodiments, this disclosure converts test case assets, originally located in Excel, databases, or external test management platforms, into a collection of local structured files. These files form a workspace that is explorable, maintainable, and auditable by the agent, using directories, indexes, content hashes, and metadata. This facilitates subsequent manual editing and agent maintenance by sharing the same source of facts. Because this disclosure converts test case assets into a local structured file workspace, the test case assets possess characteristics similar to code repositories, including readability, searchability, comparability, snapshot recording, and rollback capabilities. The agent can reuse the file system exploration, text retrieval, structured analysis, patch generation, and structure verification, field integrity verification, or business rule verification capabilities of mature software engineering tools, without relying entirely on closed platform interfaces or manually pasting context.

[0116] It should be noted that the local structured file workspace is not a temporary exported file, but rather a source of facts jointly operated by the application system and the intelligent agent. User edits within the application are ultimately written to this structured file collection; in embodiments with open write capabilities, modifications by the intelligent agent also affect this structured file collection; in read-only review embodiments, the intelligent agent interprets, reviews, or generates modification suggestions based on the workspace facts provided by the system; the application system re-presents the file state to the user through indexing, monitoring, content hashing, structure verification, snapshots, and projection mechanisms.

[0117] In some embodiments, the structured file can be replaced by a file in another format. For example, the above embodiments use JSON files to store test case assets, but YAML, XML, Protocol Buffers, SQLite exported files, or other machine-parseable structured formats can also be used. The purpose of this disclosure is achieved as long as the format can express test case fields, directory relationships, metadata, and content hashes, and can be reliably read and modified by the agent; in embodiments involving external platform synchronization, the format or related mapping records can also express external binding relationships.

[0118] Step S13: Upon receiving the first data adjustment request sent by the client, determine the first structured file corresponding to the first data adjustment request from the shared workspace, and adjust the data of the first structured file to obtain the adjusted first structured file.

[0119] The client can be a client corresponding to a user, through which the user can adjust the structured files in the shared workspace.

[0120] A data adjustment request can be understood as a request to adjust a structured file in a shared workspace. This adjustment includes, but is not limited to, operations such as directory management, import / export, deletion, editing, reuse, and report output. A first data adjustment request can be understood as a data adjustment request sent by the client, and the first structured file can be understood as the structured file corresponding to the first data adjustment request.

[0121] In some embodiments, before determining the first structured file corresponding to the first data adjustment request from the shared workspace upon receiving the first data adjustment request sent by the client, the method further includes:

[0122] Upon receiving a file provision request for a first structured file from the client, the first structured file is determined from the shared workspace and sent to the client, so that the client can display the first structured file to the user through a display page;

[0123] The client receives the first data adjustment request for the first structured file, wherein the first data adjustment request is a request generated by the client based on the user's data adjustment operation for the first structured file.

[0124] The file provision request can be understood as a request from the client to retrieve a first structured file from the shared workspace. The display page can be a page that displays the first structured file, and this display page includes, but is not limited to, web pages, application interfaces, etc.

[0125] Following the previous example, this disclosure provides a direct user editing channel. Specifically, the system provides a structured test case editing interface (i.e., a display page) that can show the user structured files in the local structured file workspace. Users can view and modify fields such as test case title, priority, preconditions, steps, expected results, test results, test data, and description within the application system. When a user edits, a data adjustment request (i.e., the first data adjustment request) is generated. Based on this request, the system writes the edited results to the corresponding structured file and refreshes the workspace index and content hash.

[0126] It should be noted that direct user editing does not create a second set of fact sources independent of the file workspace. If a user modifies a use case field, the system, through file writing, index updates, and derived state refreshes, makes that modification a file-level fact that is readable, searchable, and comparable to the agent.

[0127] In some embodiments, after sending the first structured file to the client so that the client can display the first structured file to the user through a display page, the method further includes: receiving a first file generation request generated by the client based on the first structured file;

[0128] Upon receiving a first file generation request from the client, a first newly added structured file corresponding to the first file generation request is generated in the shared workspace.

[0129] Step S14: Upon receiving the second data adjustment request generated by the agent, determine the second structured file corresponding to the second data adjustment request from the shared workspace, and adjust the data of the second structured file to obtain the adjusted second structured file.

[0130] The intelligent agent can be understood as an intelligent agent that maintains structured files, and it can be implemented based on large models, large language models, or deep learning models.

[0131] The second data adjustment request can be understood as a data adjustment request generated by the intelligent agent, and the second structured file can be understood as the structured file corresponding to the second data adjustment request. This second data adjustment request allows adjustments to the second structured file in the shared workspace, including but not limited to: modifying, reusing, importing, and exporting the structured file.

[0132] Following the previous example, this disclosure provides an agent maintenance channel. Specifically, the system provides the agent with a local test case asset workspace. The agent can perform actions such as reading the directory structure, retrieving file content, analyzing structured fields, generating modifications, viewing current differences, and continuing to correct based on verification feedback for the second structured file. Maintenance tasks that the agent can perform include: batch modification steps based on business changes; correcting expected results based on manual input, external platform synchronization, or the "test result" marker in the structured test case file, combined with user-provided problem descriptions; supplementing missing test paths; merging duplicate test cases; reviewing the consistency of existing test cases; and partially adjusting a group of test cases based on user feedback.

[0133] In one implementation, the system provides the agent with file system access to its local workspace, enabling it to read, search, and modify existing files. In another implementation, the system exposes read-only review tools or restricted write tools to the agent through a controlled tool interface. The system can initially expose read-only tools such as current change review, snapshot list, snapshot submission review, and snapshot comparison to the agent; when the agent needs to directly generate maintenance results (i.e., a second data adjustment request), after the user confirms the maintenance results, the agent uses a field-level modification tool to perform field-level writing to obtain the maintained structured file (i.e., the adjusted second structured file).

[0134] Figure 3 This is a schematic diagram illustrating the sharing of the same fact source between manual editing and intelligent agent maintenance in a data processing method provided by an embodiment of this disclosure. Based on Figure 3 As can be seen, in this disclosure, the user can instruct the user editing module to process the structured files in the local structured file workspace by issuing user editing commands; while the intelligent agent can generate intelligent agent maintenance tasks and process the structured files in the local structured file workspace through the intelligent agent access module. After completing the processing of the structured files, the workspace index and content hash are refreshed, and the current change view, use case editing view, review and verification results are presented to the user through derived state projection.

[0135] As can be seen from the above embodiments, this disclosure enables users to directly edit and agents to maintain a shared source of facts. User edits in the application system and agent modifications to files ultimately affect the same batch of structured files, converging through indexing, hashing, current changes, and snapshot mechanisms. This mechanism reduces synchronization conflicts between the two sets of state sources and improves the consistency of modification results.

[0136] In some embodiments, before determining the second structured file corresponding to the second data adjustment request from the shared workspace upon obtaining the second data adjustment request generated by the agent, the method further includes steps one and two.

[0137] Step 1: Upon receiving a file provision request for the second structured file generated by the agent, determine the second structured file from the shared workspace, wherein the file provision request is a request generated by the agent based on user-input data adjustment information, or the file provision request is a request generated by the agent after determining that the second structured file meets the file maintenance conditions.

[0138] In this context, a file provision request can be understood as a request from an agent to obtain a second structured file from a shared workspace.

[0139] Data adjustment information can be understood as information input by the user to the intelligent agent to control the intelligent agent to perform specific operations. For example, the data adjustment information can be prompts, control instructions, etc.

[0140] File maintenance conditions can be set according to actual application scenarios. For example, the conditions for the second structured file to meet file maintenance can be: the second structured file meets the preset maintenance time period, or the file size of the second structured file is greater than the preset threshold.

[0141] In some embodiments, before determining the second structured file from the shared workspace upon receiving a file provision request for the second structured file generated by the agent, the method further includes:

[0142] The environmental submodule in the intelligent agent harness module is used to determine the work area environmental information of the shared work area;

[0143] The status submodule in the intelligent harness module is used to determine the status information of the shared work area;

[0144] The workspace environment information and the status information are input into the intelligent agent. The intelligent agent, based on the workspace environment information and the status information, determines that the second structured file meets the file maintenance conditions and generates a file provision request for the second structured file.

[0145] Determining the second structured file from the shared workspace includes:

[0146] The second structured file is determined from the shared workspace using the file processing submodule in the intelligent agent harness module.

[0147] It should be noted that the data processing system in some embodiments of this disclosure can be understood as a system corresponding to the data processing method, through which the steps or operations of the data processing method can be implemented. That is to say, this data processing system is an intelligent agent collaborative maintenance system for test case assets, and this system may include the following modules:

[0148] The conversion module is used to convert structured test case data from external test case sources such as Excel, databases, or external platforms into a local collection of structured files, which is stored in a local structured file workspace.

[0149] The workspace management module is used to maintain directory hierarchy, use case files, indexes, content hashes, existence status, and metadata.

[0150] The user editing module provides the ability to edit structured test cases and writes the edited results to a local collection of structured files.

[0151] The agent access module is used to provide agents with file system access capabilities or controlled tool access capabilities.

[0152] The intelligent agent harness control module consists of five subsystems (i.e., submodules): instructions, tools, environment, status, and feedback.

[0153] The change review module is used to generate the current change list, difference segments, review status, and verification results.

[0154] The snapshot and rollback module is used to create snapshots, record a list of committed files, compare snapshots, and perform recovery.

[0155] An optional external synchronization module is used to import, export, query tasks, and process synchronization results with an external test management platform when the system is configured to synchronize with external platforms.

[0156] The intelligent agent harness module can be understood as an intelligent agent harness control module, which is used to implement intelligent agent harnesses for intelligent agents. The intelligent agent harness module includes an environment submodule, a state submodule, a file processing submodule, a rule submodule, and a feedback submodule.

[0157] The file processing submodule can be a submodule that performs various file processing operations for the agent. For example, the file processing subsystem can provide the agent with various file processing tools to perform the corresponding file processing operations; correspondingly, the file processing submodule can be a tool subsystem.

[0158] A rules submodule can be understood as a module that defines the processing rules of an agent for a shared workspace. For example, the rules submodule can be the instruction subsystem in the agent harness control module.

[0159] Specifically, the system provides an agent harness control module for maintaining test case assets. This agent harness (i.e., the agent harness control module) is not a single prompt or test script, but an engineered working system comprised of instructions, tools, environment, status, and feedback. For the system's test case asset maintenance scenario, the instruction subsystem includes workspace rules, modification scope, prohibited modification fields, and acceptance criteria (i.e., file processing rules); the tool subsystem includes tools for file reading, searching, current change review, snapshot review, difference viewing, field-level modification, and structure verification; the environment subsystem includes a local structured file workspace, directory structure, dependencies, permissions, and repeatable execution conditions prepared for the test case maintenance agent (i.e., workspace environment information); the status subsystem can include the current workspace status, current changes, activity baseline, snapshot, review conclusions, and session handover information (i.e., status information), where the current task and agent-oriented review status can be extended later; the feedback subsystem can include structure verification results, tool execution results, user review comments, and repair suggestions (i.e., data adjustment feedback information).

[0160] Furthermore, each subsystem within the agent framework performs the following functions: The instruction subsystem defines the rules for the agent-readable workspace, test case formats, field naming conventions, modification scope, prohibited fields for deletion, external synchronization constraints, and acceptance criteria. The status subsystem records the current workspace status, current changes, activity baselines, snapshots, review conclusions, and session handover information; current tasks, agent-oriented review status, and failure history can be extended later. The tool subsystem provides the agent with file reading, searching, current change review, snapshot review, difference viewing, field-level modification, and structure verification capabilities. The environment subsystem provides a repeatable local structured file workspace, dependencies, commands, and data directories. The feedback subsystem returns structure verification results, tool execution results, user review comments, and remediation suggestions to the agent in a structured manner; in implementations that do not provide UI / functional automated test execution capabilities, test reports, execution logs, or reasons for automated execution failures are not used as existing feedback sources. The observability mechanism records key operations, tool calls, verification results, and reasons for stopping during agent maintenance.

[0161] Through this mechanism, the system ensures that the agent must complete a verifiable closed loop before the task is finished. If verification fails, the system returns specific files, fields, the reason for failure, and repair suggestions to the agent. The agent continues to modify based on the feedback until verification passes, the user confirms, or the stopping conditions are met.

[0162] For example, in some embodiments, the state submodule may be a task state machine, the file processing submodule may be a tool interface, the rule submodule may be a task rule file, and the feedback submodule may be verification feedback; in addition, the system also includes audit logs.

[0163] The task rules file can include task objectives, allowed directory ranges for modification, a list of allowed fields for modification, prohibited system fields for modification, required verification projects, completion conditions, and stop conditions. Prohibited fields for modification can include use case identifiers, architecture versions, and other fields prefixed with system names; allowed fields for modification can include business fields such as name, preconditions, steps, expected results, test data, description, and test results.

[0164] The tool interfaces that the intelligent agent can call are shown in Table 1 below.

[0165] Table 1

[0166]

[0167] The verification feedback and audit logs can use a structured format, including fields such as "file", "jsonPointer", "ruleId", "message", "hint", and "severity". An example would be: "file=auth / login.casey.json", "jsonPointer= / steps / 1 / condition", "ruleId=STEP_CONDITION_REQUIRED", "message=The conditional step is missing a condition object", "hint=Add a condition to this step or change the step type to action".

[0168] After receiving this feedback, the agent can only make corrections to the file and fields, and enter the review state after passing the verification again.

[0169] The task state machine can include: pending start, rules loaded, context read, modifications generated, verification failed, pending correction, verification passed, pending user review, snapshot created, completed, and stopped. State transitions are triggered by tool call results, verification results, and user review results.

[0170] The audit log can record task identifier, agent identifier, reading range, modified file, modified field, verification command, verification result, user review conclusion, snapshot identifier, and stop reason.

[0171] Based on the above, it can be seen that before determining the second structured file from the shared workspace, this disclosure can use the environment submodule in the agent harness module to determine the workspace environment information of the shared workspace for the agent, and use the state submodule in the agent harness module to determine the state information of the shared workspace for the agent.

[0172] Then, the workspace environment information and status information are input into the agent for analysis. When the agent determines that the second structured file meets the file maintenance conditions based on the workspace environment information and status information, it generates a file provision request for the second structured file. After receiving the file provision request output by the agent, the file processing submodule in the agent's tool module is used to determine the second structured file from the shared workspace and input the second structured file into the agent for analysis.

[0173] As can be seen from the above embodiments, this disclosure constrains the agent maintenance process through agent restraints, making the agent's behavior controlled by commands, tools, environment, state, and feedback mechanisms. This mechanism can reduce the risks of agents modifying beyond their boundaries, accidentally deleting key fields, ignoring failure results, being unable to reproduce the modification process, or prematurely declaring completion.

[0174] Step 2: Input the second structured file into the intelligent agent, and use the intelligent agent to generate the second data adjustment request based on the second structured file, wherein the first structured file and the second structured file are the same structured file or different structured files.

[0175] In some embodiments, inputting the second structured file to the agent and using the agent to generate the second data adjustment request based on the second structured file includes:

[0176] The rules submodule in the intelligent agent harness module is used to determine the file processing rules for the intelligent agent;

[0177] The file processing rules and the second structured file are input into the intelligent agent, and the intelligent agent generates the second data adjustment request based on the file processing rules and the second structured file.

[0178] The method further includes:

[0179] When the data of the second structured file is adjusted to obtain the adjusted second structured file, the feedback submodule in the intelligent agent harness module is used to generate data adjustment feedback information for the intelligent agent and input the data adjustment feedback information into the intelligent agent;

[0180] Using the intelligent agent, a third adjustment data request for the second structured file is generated based on the data adjustment feedback information;

[0181] Using the file processing submodule in the intelligent body harness module, the second structured file is adjusted according to the third adjustment data request to obtain the adjusted second structured file.

[0182] The third data adjustment request is a request to further adjust the data in the second structured file. In some embodiments, this disclosure can utilize an agent to perform multiple rounds of data adjustment on the second structured file. The second data adjustment request can be understood as a data adjustment request during any round of data adjustment; the third data adjustment request can be understood as a data adjustment request corresponding to the next round of data adjustment after any round of data adjustment. That is, after performing one round of data adjustment on the second structured file using the second data adjustment request, the data adjustment feedback information can be input into the agent for analysis to obtain the third data adjustment request corresponding to the next round of data adjustment, and then the next round of data adjustment can be executed.

[0183] Specifically, after determining the second structured file using the file processing submodule, the rule submodule in the agent tool module can be used to determine the file processing rules for the agent; then the file processing rules and the second structured file are input into the agent for analysis, and the agent generates a second data adjustment request for the second structured file based on the file processing rules and the second structured file.

[0184] After obtaining the second data adjustment request, the second structured file is adjusted using the second data adjustment request. In the case of obtaining the adjusted second structured file, the feedback submodule in the agent's harness module generates data adjustment feedback information corresponding to the adjusted second structured file for the agent, and inputs the data adjustment feedback information into the agent.

[0185] Then, the agent generates a third adjustment data request for the second structured file based on the data adjustment feedback information, and uses the file processing submodule in the agent's tool module to adjust the data of the second structured file again based on the third adjustment data request to obtain the adjusted second structured file.

[0186] In some embodiments, the specific methods for the agent operation constraint and verification closed loop in this disclosure include: providing loading task rules and reading the workspace context; using the agent to generate and write modifications according to the task rules and workspace context, thereby adjusting the data of the structured file in the workspace; after completing the modification, performing structure and business verification; if the verification fails, returning structure failure information to the user; if the verification passes, providing the modification to the user for review; if the user approves the review, creating a snapshot and recording the trajectory; if the user requests correction, continuing to correct the structured file according to the modification opinions provided by the user.

[0187] As can be seen from the above embodiments, this disclosure constrains the agent maintenance process through agent restraints, making the agent's behavior controlled by commands, tools, environment, state, and feedback mechanisms. This mechanism can reduce the risks of agents modifying beyond their boundaries, accidentally deleting key fields, ignoring failure results, being unable to reproduce the modification process, or prematurely declaring completion.

[0188] In some embodiments, after sending the second structured file to the agent, the method further includes: receiving a second file generation request generated by the agent based on the second structured file; and, upon receiving the second file generation request from the agent, generating a second newly added structured file corresponding to the second file generation request in the shared workspace. That is, the agent of this disclosure possesses the ability to reason, make decisions, and proactively create assets. Specifically, the agent of this disclosure can autonomously generate a second file generation request and create a corresponding second newly added structured file after understanding and analyzing an existing second structured file, thereby improving the level of intelligence in the automated operation and maintenance of the workspace.

[0189] In some embodiments, after adjusting the data of the first structured file to obtain the adjusted first structured file, the method further includes:

[0190] Generate a first adjustment operation record for the first structured file, and store the first adjustment operation record in a first record file corresponding to the first structured file;

[0191] The process of adjusting the data in the second structured file to obtain the adjusted second structured file further includes:

[0192] A second adjustment operation record is generated for the second structured file, and the second adjustment operation record is stored in the second record file corresponding to the second structured file.

[0193] The first adjustment operation record can be understood as information used to record data adjustment operations performed on the first structured file; the second adjustment operation record can be understood as information used to record data adjustment operations performed on the second structured file; the first adjustment operation record and the second adjustment operation record can be log information or snapshots.

[0194] The first log file can be understood as a file used to record the first adjustment operation, such as a log file; the second log file can be understood as a file used to record the second adjustment operation, such as a log file; the first log file and the second log file can be the same file or different files.

[0195] In some embodiments, the method further includes: upon receiving a record file read request from the client, sending the first record file or the second record file to the client, so that the client displays the first record file or the second record file to the user through a display page.

[0196] Following the previous example, this disclosure can also record current changes, difference reviews, and snapshots (i.e., the first adjustment operation record and the second adjustment operation record). Specifically, this disclosure's system uses the active baseline as a reference to determine current changes, identify the addition, modification, renaming, and deletion of test case assets in the current workspace, determine the list of changed files when content changes are determined, compare single-file difference segments, and create a full or partial snapshot based on the user-selected commit scope. Then, the system reads the persistent commit file facts at the time of snapshot creation to facilitate subsequent historical commit reviews. Furthermore, after creating a full or partial snapshot, the active baseline is updated, and based on the active baseline, the system performs operations to restore selected test cases (i.e., rollback) or switch to a specified historical snapshot for the current workspace.

[0197] Specifically, the system uses the activity baseline as a reference to determine the addition, modification, renaming, and deletion of test case assets in the current workspace (i.e., data adjustment operations performed on the first and second structured files). When determining content changes, the system uses a normalized full content hash, such as a SHA-256 hash, instead of truncated hashes or unstable text comparison results.

[0198] In an exemplary implementation, the system compares snapshot entries in the active baseline with the current workspace index: if a use case exists in the current workspace but not in the active baseline, it is determined to be an addition; if a use case exists in the active baseline but not in the current workspace or is marked as missing, it is determined to be a deletion; if both exist but have different relative paths and the same content hash, it is determined to be a renaming; if both have content hashes and the paths are the same but the hashes are different, it is determined to be a modification; if the hash is missing, the system adopts a conservative processing strategy in the corresponding process, such as recalculating the hash, writing it, and then reading it; if the relative paths are different and the content hashes are different, it is determined to be a renaming and the content has been modified, and the content change flag is set to true in the change records (i.e., the first adjustment operation record and the second adjustment operation record). Each change record includes at least an entity identifier, entity type, change type, old path, new path, old content hash, new content hash, and a content change flag.

[0199] The system disclosed herein provides a diff review entry point for each current change. The diff results include old files, new files, and diff fragments. Diff fragments are generated by the backend or main processing unit based on the active baseline and the current workspace content. The rendering or presentation layer directly consumes this diff contract without needing to generate the diff itself.

[0200] This disclosed system supports snapshot creation. Snapshots can be full snapshots or partial snapshots based on an active baseline. When a snapshot is created, the system records a list of commit files, including the type of additions, modifications, renamings, or deletions, the old path, the new path, the old content hash, the new content hash, and whether the content has changed. When a user subsequently views the commit files of a snapshot (i.e., the first record file, the second record file), the system reads the commit files persisted at the time of snapshot creation, rather than inferring them temporarily based on the current workspace, the current active baseline, or snapshots with adjacent times.

[0201] Snapshot commit records can include at least: snapshot identifier, use case identifier, entity type, change type, old relative path, new relative path, old content hash, new content hash, whether the content has changed, and creation time. These records enable the system to read "what was committed when this snapshot was created" during history review, rather than mistaking the current workspace state for historical commits.

[0202] In some embodiments, the system disclosed herein supports users in restoring selected test cases based on an active baseline, and also supports users in selecting a specified historical snapshot to switch the workspace state. Before performing operations that may overwrite the current file content, the system performs pre-checks and creates hidden checkpoints, generating a difference-aware execution plan. After execution, the system publishes the converged local test case structure tree, file existence status, and derived state results to the presentation layer.

[0203] As can be seen from the above embodiments, this disclosure expresses the agent maintenance results as current changes, difference fragments, snapshot submission file list, verification results, and review status, enabling users to review agent modifications by file, by use case, or by snapshot, and to restore selected use cases based on the active baseline or switch to a specified historical snapshot when needed.

[0204] In some embodiments, this disclosure also provides an external platform synchronization mechanism, enabling bidirectional synchronization between the system and an external test management platform. When synchronizing from an external platform to the local workspace, the system obtains project, directory, and test case data from the external platform, converts it into a local structured file collection, and maintains external identifiers and binding relationships in the synchronization module or mapping record. When synchronizing from the local workspace to an external platform, the system generates synchronization data based on local file differences and the selected scope, and submits the changes to the external platform.

[0205] Furthermore, the system disclosed herein maintains a transport-neutral gateway abstraction at the synchronization boundary. This gateway abstraction is responsible for project discovery, directory tree loading, import / export task creation, task status querying, artifact downloading, upload handover, and structured error normalization. The application system does not confuse temporary directory numbers from external platforms with local directory identifiers, nor does it use external platforms as the source of facts maintained by agents. After external synchronization is completed, the local structured file workspace remains the primary source of facts for user editing and agent maintenance.

[0206] As can be seen from the above embodiments, this disclosure supports interoperability with external test management platforms, while not relying on external platform databases as the sole source of facts for long-term maintenance by the agent. After synchronization, the local structured file workspace remains the readable, maintainable, and auditable asset base for the agent.

[0207] As can be seen from the above embodiments, during the bidirectional synchronization process with the external test management platform, this disclosure can perform platform data acquisition on the external test management platform to import tasks and artifact downloads; use the conversion module to convert the acquired files into structured files and store them in the local structured file workspace; use an intelligent agent or manual maintenance of the workspace; when updating the structured files in the workspace, use the change review module to review them, and after the review, perform a synchronization data generation operation to obtain the review information that needs to be synchronized to the external test management platform. Then, synchronize the imported tasks and review information from the external platform to the external test management platform. At the same time, this disclosure will also generate platform verification results. The platform verification results can be used as feedback to return to the local maintenance process, so that the local structured file workspace remains the primary source of facts.

[0208] The data processing method provided in this disclosure can extract software test data from multiple received test case files, generate structured files corresponding to the multiple test case files based on the software test data, and construct a shared workspace for the client and the agent based on the multiple structured files, thereby enabling the client and the agent to jointly process the structured files in the shared workspace. Upon receiving a first data adjustment request sent by the client, the method determines the first structured file corresponding to the first data adjustment request from the shared workspace, adjusts the data in the first structured file, and obtains an adjusted first structured file. Similarly, upon receiving a second data adjustment request generated by the agent, the method determines the second structured file corresponding to the second data adjustment request from the shared workspace, adjusts the data in the second structured file, and obtains an adjusted second structured file. This allows the test case files to maintain a visual and manually editable data format while also providing automated maintenance for the agent, achieving flexible processing of software test data.

[0209] The technical solution provided in this disclosure focuses on the long-term maintenance of existing test case assets, rather than just the one-time generation of test cases. Therefore, this disclosure can cover high-frequency scenarios in the enterprise test case lifecycle, including batch maintenance, repair, review, verification, synchronization, and rollback. This improves the efficiency of batch maintenance of test case assets, enhances the completeness of test case fields, consistency of steps, and review quality, and reduces the risk of unreviewable and unrecoverable modifications. In specific engineering implementations, the above-mentioned beneficial effects can be demonstrated through the following verifiable phenomena: when an agent modifies multiple test cases in batches, the system can generate a list of change files and difference fragments according to the test case files, allowing users to review the scope of modifications without having to open the original platform records one by one; when an agent generates steps that do not conform to the structure verification rules, the system can locate the specific file and field path and return the reason for failure; when a user rejects a maintenance result, the system can restore the corresponding file based on the active baseline or snapshot; when an agent attempts to modify system fields or directories outside the scope, the agent's mechanism can prevent the modification from being accepted during the rule check or verification phase. The above effects can be verified through indicators such as batch modification time, verification failure location granularity, rollback success rate, and out-of-bounds modification interception records.

[0210] The following explanation illustrates the task processing method using specific embodiments in various application scenarios.

[0211] Example 1: Import from Excel test case library and maintain in batches by intelligent agents.

[0212] Users import an Excel file containing multi-level test case sets, test case titles, preconditions, execution steps, expected results, priorities, and test data into the system. The system reads the Excel file and parses the test cases corresponding to each row or group of rows according to preset field mapping rules. For multi-level test case set fields, the system generates a local directory structure; for each test case, the system generates a JSON file.

[0213] For example, a test case under the login module is converted into "login / normal login.casey.json". The file contains the test case identifier, structure version, title, priority, preconditions, step array, expected result, test result, test data, and description. The system calculates the complete content hash for this file and writes the path, test case identifier, directory relationship, and content hash into the workspace index.

[0214] The user then requested the agent to uniformly change all "account and password login" steps in a certain business process to "unified identity authentication login". The agent searched for relevant JSON files through the file system, read the step array, identified the target fields, and generated batch modifications. The system ran structured validation to confirm that the step array, expected results, test data, and description fields still conformed to the structure validation rules. After the validation passed, the system displayed the current change list and the difference fragments for each use case. After the user reviewed it, a snapshot was created, recording the list of submitted files and the content hashes of each file before and after the modification.

[0215] In this embodiment, instead of generatively rewriting temporary Excel text, the agent performs auditable, verifiable, and rollback-capable maintenance on local structured test case assets.

[0216] Example 2: User-direct editing and intelligent agent repair collaboration.

[0217] A user opens a test case in the application system and directly modifies the expected result of that test case. The system writes the modification to the corresponding JSON file, refreshes the content hash, and marks the file as currently changed. This modification immediately becomes a workspace fact readable by the agent.

[0218] Subsequently, based on issues reviewed manually, reported by external systems, or manually compiled, the user pointed out inconsistencies in the expected results of multiple use cases within the same module. The user requested the agent to check and fix similar issues. The agent read the user-provided issue description, workspace rules, and relevant JSON files, located multiple expected result fields, and generated localized modifications.

[0219] The system displays both user-made and agent-made changes in the current change view. Users can view the differences item by item or filter changes by directory, path, or use case field. For agent-made changes they do not wish to accept, users can revert to the active baseline; for accepted changes, users can create a snapshot. When a snapshot is created, the system records the type of addition, modification, deletion, or renaming for each committed file and saves the old content hash and the new content hash.

[0220] This example illustrates that direct user editing and agent maintenance are not two unrelated links, but rather share the same local structured file workspace and converge through current changes and snapshot mechanisms.

[0221] Example 3: Verification closed loop driven by intelligent body harness.

[0222] The system generates task rules for a single agent maintenance task. These rules include: the agent can only modify test cases under a specified test case set; it cannot modify system fields such as test case identifiers and structure versions; the step array must contain at least one step; each step must include an operation description and may include the corresponding expected result; after modification, a structured validation command must be run to generate structured validation results or a maintenance summary.

[0223] After reading the rules, the agent obtains the context through the workspace file and the review tool, and modifies the target JSON file. Once modified, the system performs structured validation. If validation fails, the system returns the field paths, the reason for failure, and suggested fixes in a structured format. For example, it might indicate that the use case "payment / refund.casey.json" has an invalid priority.

[0224] The agent continues to revise the corresponding files based on the feedback. The system runs the verification again. If the verification passes, the system generates the verification results, the current change list, and the difference snippets. After reviewing the review results, the user accepts the changes and creates a snapshot. The system records the agent's task trajectory, including the rules read, the tools called, the files modified, the reasons for the structured verification failure, the correction process, and the final result.

[0225] This embodiment demonstrates the role of the agent's restraint mechanism in constraining and verifying the agent's behavior, so that the agent maintenance process does not rely solely on natural language commitments, but rather on an engineered feedback loop.

[0226] Example 4: Supporting agents to understand the current workspace state through read-only review tools.

[0227] In another implementation, the system does not directly expose write capabilities to the agent. Instead, it first exposes the current changes and snapshot facts to the agent through read-only tools. The system starts a local controlled service and provides the agent with tools such as current change review, snapshot list, snapshot submission review, and snapshot comparison.

[0228] The system can provide agents with read-only review capabilities such as current change review, snapshot list, snapshot submission review, and snapshot comparison through local controlled tool services, enabling agents to interpret current change and snapshot information based on the workspace facts provided by the system. These tools are only used for reading and interpreting facts and do not perform file writing, snapshot creation or deletion, historical snapshot switching, file recovery, review status writing, or database operations; writing capabilities, snapshot operation capabilities, and agent-oriented review status can be implemented as subsequent extended implementation methods.

[0229] When an agent needs to review a historical snapshot, it invokes the snapshot submission review tool. The system reads the persistent commit file records from when the snapshot was created and returns the facts of the files committed at that time, rather than making temporary inferences based on the current workspace or snapshots with adjacent times. In this way, the agent can explain historical changes to the user based on stable product facts.

[0230] This embodiment is suitable for scenarios with strict requirements on agent permissions. It can first provide read-only review capabilities, and then gradually open up restricted write capabilities according to business needs.

[0231] Example 5: Two-way synchronization with an external test management platform.

[0232] The system establishes a project binding with an external test management platform. Users can choose to synchronize test cases from the external platform to the current workspace. The system loads remote project, directory tree, and test case data through the external platform gateway, creates an asynchronous export task, downloads the task artifacts, and converts them into a local collection of structured files. The system can maintain external test case numbers and platform binding information in the synchronization module or mapping records, but it does not write these external identifiers as necessary fields in the core test case files, nor does it confuse the temporary directory numbers of the external platform with local directory identifiers.

[0233] After the agent maintains these test cases in its local workspace, the system generates synchronization data based on current changes and the user's selected scope. When the user chooses to synchronize to an external platform, the system creates an import task through the external platform gateway, uploads the data, and polls the task status. If the platform returns a structured validation error, the system normalizes the error into a stable error code and displayable information, which can be provided as feedback to the agent to continue repairing local assets.

[0234] After synchronization is complete, the system refreshes the local structured document workspace and updates the necessary external mapping information in the synchronization module. Regardless of whether the external platform exists as an enterprise process system, the local structured document workspace remains the primary source of facts for user editing and agent maintenance.

[0235] Based on the above embodiments, this disclosure provides a method, system, electronic device, and storage medium for collaborative maintenance of test case assets. The method converts structured test case data from Excel, databases, or external test management platforms into a set of structured files in the user's local file system, and establishes a test case asset workspace based on this file set. The system provides a direct user editing channel and an agent maintenance channel, enabling manual editing and agent modification to share the same source of fact; and constrains the rules, states, tools, environment, feedback, verification, and observability of agents through agent tools. To improve the efficiency of test case asset maintenance, enhance the completeness of test case fields and the quality of steps and expected results, and reduce agent maintenance risks, the system generates a list of current changes, difference fragments, snapshot submission files, structured verification results, and user review information based on the active baseline and the current workspace. This information supports user review, quality control, and recovery based on the active baseline or a specified snapshot; the system also supports synchronization with an external test management platform. This disclosure enables test case assets to have engineered maintenance capabilities that allow for searchability, differential review, verification, snapshot recording, and snapshot-based recovery. This improves the efficiency and quality of collaborative maintenance of test case assets by humans and intelligent agents, and reduces the risks of missing context, out-of-bounds modifications, synchronization inconsistencies, and inability to review and recover.

[0236] The task processing method disclosed herein enables manual editing and agent maintenance to share the same source of facts. Users edit test cases in a structured manner through the application system, while agents maintain test cases through a file system or controlled tools. Both operate uniformly on the same batch of local structured files and converge through indexing, hashing, current changes, and snapshot mechanisms.

[0237] The task processing method disclosed herein implements an intelligent agent tool for test case asset maintenance. The intelligent agent maintenance process is constrained by the tool, which consists of instructions, tools, environment, state, and feedback. Rules belong to the instruction subsystem, structured verification results and repair suggestions belong to the feedback subsystem, and an observability mechanism is used to record key operations and tool results, thereby making the intelligent agent maintenance process verifiable, traceable, auditable, and reversible.

[0238] The task processing method disclosed herein implements a collaborative maintenance evidence chain mechanism for review and rollback. The system generates current change, difference fragment, and snapshot commit file facts based on the active baseline and current workspace to support user review, risk control, and rollback recovery, thereby improving the efficiency and quality of agent-based collaborative maintenance of test case assets.

[0239] The task processing method disclosed herein implements read-only or controlled tool interfaces to support agent review workspaces. The system can expose tools such as current change review, snapshot list, snapshot submission review, and snapshot comparison to agents, enabling agents to review test case assets based on product semantics, rather than scanning documents or inferring differences on their own.

[0240] The task processing method disclosed herein separates external platform synchronization from local asset maintenance. The system supports synchronization with external test management platforms, but after synchronization, it still retains the local structured file workspace as the long-term maintenance fact source for the agent, thus balancing enterprise platform processes and agent engineering maintenance capabilities.

[0241] Based on the above, this disclosure provides a method for collaborative maintenance of test case assets by intelligent agents. Existing test case assets are organized into a local structured file workspace, and intelligent agents, through agent facilitation, perform constrained, verifiable, and auditable incremental maintenance on the same source of facts. This disclosure can acquire structured test case data; convert the structured test case data into a set of structured files in the user's local file system; establish a test case asset workspace based on the set of structured files; provide a direct editing channel for users in the application system; provide controlled workspace access capabilities to intelligent agents; constrain the intelligent agent maintenance process through agent facilitation consisting of instructions, tools, environment, state, and feedback; converge changes generated by user editing and intelligent agent maintenance to the same workspace state; and generate current changes, difference fragments, snapshot records, review information, verification results, and rollback information based on this workspace state.

[0242] In some embodiments, for agent access methods, this disclosure can directly expose the local file system to the agent, or provide workspace access capabilities through controlled tool interfaces, MCP services, local HTTP services, command-line tools, or plugin interfaces. In scenarios with high security requirements, read-only auditing tools can be exposed first, followed by restricted write tools.

[0243] In some embodiments, the verification methods in the intelligent agent tool of this disclosure can include structural verification, field integrity verification, business rule verification, pre-verification imported from external platforms, or manual review results. If UI / functional automated testing capabilities are not integrated, test execution reports, execution logs, or reasons for automated execution failures will not be used as existing feedback sources.

[0244] In some embodiments, for snapshot storage methods, the snapshots of this disclosure can be stored in a local database, content-addressed storage, version control system, compressed archive, or remote storage. The review and recovery purposes of this disclosure can be achieved as long as snapshot entries, content hashes, commit facts, and the content required for rollback can be recorded.

[0245] In some embodiments, the external synchronization platform is not limited to a specific R&D collaboration system, but can also be a test management system, defect management system, requirements management system, or an internal enterprise quality platform. The synchronization protocol can be REST, GraphQL, file upload / download, message queue, or other interface forms.

[0246] In some embodiments, the user-direct editing channel, for the user interface, can be implemented as a desktop application, web application, command-line interface, or integrated development environment plugin. As long as the user's editing results are ultimately written to a local structured file workspace and share the same source of fact with the agent's maintenance results, they fall within the scope of this disclosure.

[0247] In some embodiments, this refers to the directory hierarchy; the test case directory can be generated based on test case set fields, business modules, requirement numbers, external platform directories, or user-defined rules. The directory hierarchy can also be separated from the test case files and maintained by an index file or database records.

[0248] In some embodiments, the focus is on agent type; the agent can be a general software engineering agent, a test-specific agent, a rule-driven automation agent, or a multi-agent system. Multiple agents can be responsible for retrieval, modification, verification, and review respectively, but their maintenance results are still converged through a local structured file workspace and agent tethering.

[0249] The present disclosure provides a method for intelligent agent collaborative maintenance of test case assets, which can solve the problem that existing test case assets are difficult to maintain efficiently, stably, and verifiably under the collaboration of humans and intelligent agents, and that the maintenance results are difficult to continuously improve the quality of test cases.

[0250] It enables the conversion of structured test case assets into local structured file workspaces that agents can directly explore and maintain. It allows users to directly edit and share the same source of fact with agents' file-level maintenance within the same application system. At the same time, it uses agent tools to perform scope constraints, verification feedback, difference review, snapshot recording, and rollback control on the maintenance process.

[0251] It enables the mapping of test case fields from Excel, databases, or external test management platforms to local structured files, while preserving business semantics such as test case hierarchy, steps, expected results, preconditions, priorities, test data, and descriptions.

[0252] This enables intelligent agents to obtain test case library context through file system reading, searching, difference analysis, and file modification, instead of relying on manual pasting or a closed platform interface.

[0253] It enables users to directly edit and agents to maintain the same batch of test case assets within the same application, and brings both to a unified current workspace state.

[0254] It implements constraints on the maintenance behavior of intelligent agents, preventing them from modifying beyond their boundaries, deleting key fields, ignoring verification failures, prematurely declaring completion, or failing to explain the basis for modification.

[0255] This system improves batch maintenance efficiency, enhances the completeness of test case fields, and improves the quality of steps and expected results when intelligent agents collaboratively maintain test case assets. It also organizes the session context, tool execution results, structured validation results, current changes, difference fragments, snapshot commit file lists, and user review information in the maintenance task into a user-reviewable chain of maintenance evidence. Users can trigger recovery based on the active baseline or a specified snapshot within the system.

[0256] It achieves the goal of maintaining the local structured file workspace as the fact source for the agent while synchronizing with an external test management platform.

[0257] Therefore, the agent-based collaborative maintenance method for test case assets provided in this disclosure enables test case assets to remain structured, visualized, and manually editable, while also being exposed to agents in a local file system manner. Furthermore, the method allows agents to use agents to constrain context acquisition, modification scope, verification process, feedback correction, review, and rollback, thereby forming a verifiable, reviewable, and recoverable human-machine collaborative maintenance closed loop.

[0258] 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.

[0259] In addition, this disclosure also provides a data processing system, electronic device, and computer-readable storage medium, all of which can be used to implement any of the data processing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding section of the method and will not be repeated here.

[0260] Figure 4 This is a block diagram of a data processing system provided in an embodiment of the present disclosure.

[0261] Reference Figure 4 This disclosure provides a data processing system, which includes: an intelligent agent 401, a data extraction module 402, a file generation module 403, a data adjustment module 404, and an intelligent agent harness module 405.

[0262] The data extraction module 402 is used to extract software test data from multiple received test case files; wherein, the test case files are files generated during the software testing process.

[0263] The file generation module 403 is used to generate structured files corresponding to the multiple test case files based on the software test data, and to build a shared workspace for the client and the agent based on the multiple structured files.

[0264] The data adjustment module 404 is used to, upon receiving a first data adjustment request sent by the client, determine the first structured file corresponding to the first data adjustment request from the shared workspace, and perform data adjustment on the first structured file to obtain the adjusted first structured file;

[0265] The intelligent agent harness module 405 is used to determine the second structured file corresponding to the second data adjustment request from the shared workspace when a second data adjustment request is received from the intelligent agent 401, and to adjust the data of the second structured file to obtain the adjusted second structured file, wherein the first structured file and the second structured file are the same structured file or different structured files.

[0266] The data processing system provided in this disclosure can extract software test data from multiple received test case files, generate structured files corresponding to the multiple test case files based on the software test data, and construct a shared workspace for the client and the agent based on the multiple structured files, thereby enabling the client and the agent to jointly process the structured files in the shared workspace. Upon receiving a first data adjustment request sent by the client, the system determines the first structured file corresponding to the first data adjustment request from the shared workspace, adjusts the data in the first structured file, and obtains an adjusted first structured file. Similarly, upon receiving a second data adjustment request generated by the agent, the system determines the second structured file corresponding to the second data adjustment request from the shared workspace, adjusts the data in the second structured file, and obtains an adjusted second structured file. This allows the test case files to maintain a visual and manually editable data format while also providing automated maintenance for the agent, achieving flexible processing of software test data.

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

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

[0269] Reference Figure 5 This disclosure provides an electronic device, which includes: at least one processor 501; at least one memory 502; and one or more I / O interfaces 503 connected between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs that can be executed by the at least one processor 501, and the one or more computer programs are executed by the at least one processor 501 to enable the at least one processor 501 to perform the above-described data processing method.

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

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

[0272] This disclosure also provides a computer program product including computer-readable code, which, when run in a processor of an electronic device, enables the processor in the electronic device to perform the aforementioned data processing method.

[0273] 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).

[0274] 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.

[0275] 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.

[0276] 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.

[0277] 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.

[0278] 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.

[0279] 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 system to produce a machine such that, when executed by the processor of the computer or other programmable data processing system, 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 system, and / or other device to function in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing the aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

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

[0281] 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.

[0282] 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 data processing method, characterized in that, include: Extract software test data from multiple received test case files; wherein, the test case files are files generated during the software testing process. Based on the software test data, generate structured files corresponding to the multiple test case files, and build a shared workspace for the client and the agent based on the multiple structured files; Upon receiving a first data adjustment request sent by the client, the system determines the first structured file corresponding to the first data adjustment request from the shared workspace, and performs data adjustment on the first structured file to obtain the adjusted first structured file. Upon receiving a second data adjustment request generated by the agent, the second structured file corresponding to the second data adjustment request is determined from the shared workspace, and the data of the second structured file is adjusted to obtain the adjusted second structured file.

2. The method according to claim 1, characterized in that, Before determining the second structured file corresponding to the second data adjustment request from the shared workspace upon receiving the second data adjustment request generated by the agent, the method further includes: Upon receiving a file provision request for a second structured file generated by the agent, the second structured file is determined from the shared workspace, wherein the file provision request is a request generated by the agent based on user-input data adjustment information, or the file provision request is a request generated by the agent upon determining that the second structured file meets file maintenance conditions; The second structured file is input into the intelligent agent, which then generates the second data adjustment request based on the second structured file. The first structured file and the second structured file may be the same structured file or different structured files.

3. The method according to claim 2, characterized in that, The step of inputting the second structured file into the intelligent agent and using the intelligent agent to generate the second data adjustment request based on the second structured file includes: The rules submodule in the agent harness module is used to determine the file processing rules for the agent; The file processing rules and the second structured file are input into the intelligent agent, and the intelligent agent generates the second data adjustment request based on the file processing rules and the second structured file. The method further includes: When the data of the second structured file is adjusted to obtain the adjusted second structured file, the feedback submodule in the intelligent agent harness module is used to generate data adjustment feedback information for the intelligent agent and input the data adjustment feedback information into the intelligent agent; Using the intelligent agent, a third adjustment data request for the second structured file is generated based on the data adjustment feedback information; Using the file processing submodule in the intelligent body harness module, the second structured file is adjusted according to the third adjustment data request to obtain the adjusted second structured file.

4. The method according to claim 2, characterized in that, Before determining the second structured file from the shared workspace upon receiving a file provision request for the second structured file generated by the agent, the method further includes: The environmental submodule in the intelligent agent harness module is used to determine the work area environmental information of the shared work area; The status submodule in the intelligent harness module is used to determine the status information of the shared work area; The workspace environment information and the status information are input into the intelligent agent. The intelligent agent, based on the workspace environment information and the status information, determines that the second structured file meets the file maintenance conditions and generates a file provision request for the second structured file. Determining the second structured file from the shared workspace includes: The second structured file is determined from the shared workspace using the file processing submodule in the intelligent agent harness module.

5. The method according to claim 1, characterized in that, Before determining the first structured file corresponding to the first data adjustment request from the shared workspace upon receiving the first data adjustment request sent by the client, the method further includes: Upon receiving a file provision request for a first structured file from the client, the first structured file is determined from the shared workspace and sent to the client, so that the client can display the first structured file to the user through a display page; The client receives the first data adjustment request for the first structured file, wherein the first data adjustment request is a request generated by the client based on the user's data adjustment operation for the first structured file.

6. The method according to claim 1, characterized in that, The step of extracting software test data from multiple received test case files includes: Upon receiving multiple test case files from multiple test data storage systems, the test case files are parsed according to a preset mapping rule to obtain software test data corresponding to the preset mapping rule.

7. The method according to claim 1, characterized in that, The step of generating structured files corresponding to the multiple test case files based on the software test data, and constructing a shared workspace for the client and the agent based on the multiple structured files, includes: The software test data of the target test case file is converted into a structured file corresponding to the target test case file, wherein the target test case file is any one of the plurality of test case files; Based on the file attribute information of the multiple structured files, construct corresponding file indexes for the multiple structured files; Based on the multiple structured files and the file index, the shared workspace is constructed so that the client and the agent can jointly adjust the data of the structured files in the shared workspace.

8. The method according to claim 1, characterized in that, After adjusting the data in the first structured file to obtain the adjusted first structured file, the process further includes: Generate a first adjustment operation record for the first structured file, and store the first adjustment operation record in a first record file corresponding to the first structured file; The process of adjusting the data in the second structured file to obtain the adjusted second structured file further includes: A second adjustment operation record is generated for the second structured file, and the second adjustment operation record is stored in the second record file corresponding to the second structured file.

9. The method according to claim 8, characterized in that, The method further includes: Upon receiving a record file read request from the client, the first record file or the second record file is sent to the client, so that the client can display the first record file or the second record file to the user through a display page.

10. A data processing system, characterized in that, The system includes an intelligent agent, a data extraction module, a file generation module, a data adjustment module, and an intelligent agent harness module. The data extraction module is used to extract software test data from multiple received test case files; wherein, the test case files are files generated during the software testing process. The file generation module is used to generate structured files corresponding to the multiple test case files based on the software test data, and to build a shared workspace for the client and the agent based on the multiple structured files. The data adjustment module is used to, upon receiving a first data adjustment request sent by the client, determine the first structured file corresponding to the first data adjustment request from the shared workspace, and perform data adjustment on the first structured file to obtain the adjusted first structured file. The intelligent agent harness module is used to determine the second structured file corresponding to the second data adjustment request from the shared workspace when a second data adjustment request is received from the intelligent agent, and to adjust the data of the second structured file to obtain the adjusted second structured file, wherein the first structured file and the second structured file are the same structured file or different structured files.

Images