Querying test record method and device and related equipment

Abstract

This application discloses a method, apparatus, and related equipment for querying test records, relating to the field of data query technology. The method involves obtaining query information, including an entry identifier and a version identifier. The entry identifier identifies the target test entry among multiple test entries, and the version identifier identifies the target version among at least one version included in the target test entry. Each version includes at least one test record. A database structurally stores the identifiers of each test entry, the identifiers of each version under each entry, and the test records contained under each version. Based on the entry identifier and version identifier, the test records contained under the target version can be directly retrieved from the database. Thus, by using the entry identifier and version identifier, test records of a specific entry and version can be directly located from a database that structurally stores entry identifiers, version identifiers, and test records, improving query efficiency.

Description

Technical Field

[0001] This application relates to the field of data query technology, and in particular to a method, apparatus and related equipment for querying test records. Background Technology

[0002] The digital instrumentation and control system of a nuclear power plant is the "nerve center" of the plant, undertaking the core functions of reactor monitoring, control, and protection. Its reliability and accuracy are directly related to the safe and stable operation of the nuclear power unit. Before leaving the factory, the digital instrumentation and control system equipment needs to undergo comprehensive functional testing and verification within the manufacturing plant to ensure that the equipment can perform its safety functions normally after installation at the nuclear power plant site.

[0003] Currently, during the functional verification, performance testing, and system commissioning of digital instrumentation and control systems in nuclear power plants, multiple test items are typically designed to meet different testing requirements. Tests are then executed based on these test items to generate different test records. These test records are generally used to document the testing process and results, serving as a basis for subsequent test verification, problem analysis, and traceability of the verification process. Currently, test records are usually stored in the form of test documents or test files, and are identified using document-related information.

[0004] However, when there are a large number of test records, such as tens of thousands, the time required to retrieve the required test records from a large number of test records increases and the query efficiency decreases. Summary of the Invention

[0005] This application provides a method for querying test records to improve the efficiency of test record retrieval. Furthermore, this application also provides a corresponding apparatus for querying test records, a computer device, a computer-readable storage medium, and a computer program product.

[0006] Firstly, this application provides a method for querying test records, which can be applied to a computer device. During the querying process, the computer device can obtain query information, including an entry identifier and a version identifier. The entry identifier identifies the target test entry among multiple test entries, and the version identifier identifies the target version among at least one version included in the target test entry. Each of the at least one version includes at least one test record. For example, the computer device can obtain query information input by a user, which specifies the specific test entry and version. Then, based on the obtained entry identifier and version identifier, the computer device queries a database for the target test record, which is the test record included in the target version. The database includes a structured storage of identifiers for multiple test entries, identifiers for at least one version included in each test entry, and test records included in each version.

[0007] Because the query information carries both the item identifier and the version identifier during the test record query process, and the database stores the test item identifier, version identifier, and test record in a structured manner, it is possible to directly locate the test record corresponding to the target test item under the target version from the database based on the item identifier and version identifier, rather than searching by matching each item one by one or by manual comparison when the structured association between the version identifier and the test record is missing. This allows the query results to quickly hit the test record of the specific test item under the specific version, improving query efficiency.

[0008] In one possible implementation, when querying a target test record from the database based on an entry identifier and a version identifier, the specific steps could be as follows: First, based on the entry identifier, query the target test entry among multiple test entries stored in the database; then, based on the version identifier, query the target version among at least one version corresponding to the target test entry stored in the database. Thus, based on the target version, the target test record can be determined, which is the test record included in the target version. In this way, through a step-by-step locating method, the test entry is first located, then the version under that entry is located, and finally the test record under that version is obtained. This ensures a clear query path and accurately retrieves the target test record required by the user.

[0009] In one possible implementation, the query information may further include a change identifier, which indicates whether a version change has occurred. When determining the target test record based on the target version, specifically, the change identifier can be used to query versions within the target version that match the change identifier, and the test records included in those matching versions can be identified as the target test records. For example, in practical applications, a user may only want to query test records for versions where the test content has changed. By inputting a specific change identifier, the computer device can further filter out test records for versions that meet the change criteria. Thus, by introducing a change identifier, test records corresponding to versions that have changed or have not changed can be further filtered within the target version, satisfying the user's query needs for test records with specific change states and avoiding interference from irrelevant records.

[0010] In one possible implementation, after retrieving the target test record from the database based on the entry identifier and version identifier, a test document can be automatically generated according to the target test entry, target version, and target test record, following a preset test document template. This allows for the automatic integration of relevant test entry information, version information, and specific test records after the required target test record is retrieved, generating a uniformly formatted test document. This reduces the need for manual test record organization and improves data recording and processing efficiency.

[0011] In one possible implementation, the version identifier is generated when the test content of a test entry is updated. Thus, associating the version identifier with updates to the test content allows each change to the test content to be traced and distinguished through the version identifier, facilitating fine-grained version management of the subsequent testing process.

[0012] In one possible implementation, the process of storing data in a database is included before obtaining the query information. Specifically, test data generated during the execution of tests on each of the multiple test items is obtained, and test records corresponding to each of the multiple test items are generated based on the test data. These test records are then stored in the database via append-only operations. This append-only storage of test records preserves the historical traces of test record generation, facilitating the tracking of the testing process's evolution, and also provides a data foundation for the aforementioned efficient structured query.

[0013] In one possible implementation, test data includes at least one of test design, test execution results, or test verification information. Thus, test records can cover key data throughout the entire lifecycle of testing activities, enabling the retrieved target test records to comprehensively reflect the design, execution, and verification of the tests.

[0014] Secondly, this application provides a device for querying test records. The device includes: an acquisition module for acquiring query information, the query information including an entry identifier and a version identifier, the entry identifier being used to identify the target test entry to be queried among a plurality of test entries, the version identifier being used to identify the target version to be queried among at least one version included in the target test entry, each of the at least one version including at least one test record; and a query module for querying the target test record from a database based on the entry identifier and the version identifier, the target test record being the test record included in the target version, the database including the identifiers of a plurality of test entries stored in a structured manner, the identifier of at least one version included in each of the plurality of test entries, and the test record included in each of the at least one version included in each test entry.

[0015] In one possible implementation, the query module is configured to: query a target test entry among multiple test entries stored in the database based on an entry identifier; query a target version among at least one version corresponding to the target test entry stored in the database based on a version identifier; and determine a target test record based on the target version, wherein the target test record is the test record included in the target version.

[0016] In one possible implementation, the query information further includes a change identifier, which is used to identify whether the version has changed; the query module is used to: query the target version that matches the change identifier based on the change identifier; and determine the target test records included in the version that matches the change identifier.

[0017] In one possible implementation, the device further includes a generation module, configured to generate test documents according to a preset test document template based on the target test items, the target version, and the target test records.

[0018] In one possible implementation, the version identifier is generated when the test content of the test entry is updated.

[0019] In one possible implementation, the device further includes: a storage module for acquiring test data generated during the execution of tests on each of the multiple test items; generating test records corresponding to each of the multiple test items based on the test data; and storing the test records in a database by appending them.

[0020] In one possible implementation, the test data includes at least one of test design, test execution results, or test verification information.

[0021] Since the query test record device provided in the second aspect corresponds to the query test record method provided in the first aspect, the technical effects of the second aspect and its various embodiments can be found in the corresponding first aspect and its various embodiments, and will not be repeated here.

[0022] Thirdly, this application provides a computer device including a processor and a memory. The processor and the memory communicate with each other. The processor executes instructions stored in the memory to cause the computer device to perform a query test record method as described in the first aspect or any implementation thereof. It should be noted that the memory may be integrated into the processor or may be independent of the processor. The computer device may also include a bus. The processor is connected to the memory via the bus. The memory may include readable storage memory and random access memory.

[0023] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer device, cause the computer device to perform the operation steps of the query test record method in the first aspect or any implementation thereof.

[0024] Fifthly, this application provides a computer program product, which includes instructions that, when executed on a computer device, cause the computer device to perform the operation steps of the query test record method in the first aspect or any implementation thereof.

[0025] Furthermore, the technical effects of any of the implementation methods in the third to fifth aspects can be found in the technical effects of different implementation methods in the first aspect, and will not be repeated here.

[0026] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0028] Figure 1 This application provides a schematic diagram of the architecture of a test record query system. Figure 2 A flowchart illustrating a method for querying test records provided in an embodiment of this application; Figure 3 A flowchart illustrating a test record generation and storage method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a query test record device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are some, but not all, embodiments of this application. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application.

[0030] See Figure 1 This is a schematic diagram of the architecture of a test record query system provided in an embodiment of this application. Figure 1 As shown, the test record query system 10 includes a client 110, a query device 120, and a database 130.

[0031] Client 110 is used to interact with user 200, such as obtaining query information input by user 200 or presenting queried documents or files to user 200. Exemplarily, client 110 can be an application running on user 200's terminal device, such as a desktop application or mobile application, or it can be a web browser provided by test record query system 10, or it can be a front-end page with a graphical user interface; this application does not limit this. Client 110 and user 200 communicate through a human-computer interaction interface.

[0032] The query device 120 is configured to respond to a query operation triggered by user 200 through client 110, retrieve documents or files from database 130 based on the query information input by user 200, and present the retrieved documents or files to user 200 through client 110. Exemplarily, the query device 120 can be implemented in software or hardware. Further, when the query device 120 is implemented in software, it can be a service or process running on a computing device; when the query device 120 is implemented in hardware, it can be implemented using a processor or at least one computing device including a processor. The query device 120 communicates with client 110 via a network. Exemplarily, the query device 120 and client 110 can communicate via a wired or wireless network, which can be a local area network, a wide area network, the Internet, or any other form of network. The query device 120 and client 110 can communicate using Hypertext Transfer Protocol, Hypertext Transfer Secure Protocol, Remote Procedure Call Protocol, or WebSocket protocol, etc., and this application does not limit this.

[0033] Database 130 is used to store structured data, including identifiers of multiple test items, identifiers of at least one version included in each test item, and test records included in each version. Further, the structured data stored in database 130 may also include change identifiers, which can be used to identify whether the versions included in the test items have changed. Exemplarily, database 130 can be a relational database, such as MySQL, Oracle, PostgreSQL, or SQL Server, or a non-relational database, such as MongoDB, Redis, or Cassandra; this application does not limit this. Database 130 communicates with query device 120 through a database connection driver. Exemplarily, query device 120 can establish a communication connection with database 130 through Java Database Connectivity, Open Database Connectivity, or a database native application programming interface, and send query instructions to database 130 using a structured query language. After executing the query, database 130 returns the query result set to query device 120.

[0034] User 200 refers to a user using the test record query system. User 200 can perform human-computer interaction operations on client 110, such as inputting information like entry identifiers and version identifiers to client 100 via keyboard, mouse, or touchscreen. The input information can be used by client 100 as query information, and this application does not limit this.

[0035] During the testing and verification of digital instrumentation and control systems in nuclear power plants, testers design multiple test items to meet different testing requirements and execute tests based on these items to generate corresponding test records. These test records document the testing process and results, serving as the basis for subsequent test verification, problem analysis, and traceability of the verification process. Test records are typically stored in the form of test documents or test files, identified using document-related information. In this approach, the test document or test file is identified and stored as a whole, and the test items contained within it are not individually identified.

[0036] When it is necessary to find a test record for a specific test item in a test document or file, user 200 inputs information such as the document name or number through client 110. The query device 120 locates the target test document or file in database 130 based on this information and returns it to user 200, who then searches for the required test record item by item within that document or file. As the number of test records increases, so does the number of test documents or files. After the query device 120 locates the target document or file, user 200 still needs to manually filter the target test records within the document or file. This process involves two steps: locating the document and then searching for the test records item by item. The time consumed increases with the number of test records.

[0037] Based on this, in the test record query system 10 provided in this application, the query device 120 can directly locate the test records included in the target version in the database 130 according to the entry identifier and version identifier input by the user 200 through the client 110. The database 130 stores the identifiers of multiple test entries, the identifiers of at least one version included in each test entry, and the test records included in each version. Each test record is associated with a corresponding entry identifier and version identifier.

[0038] In practice, client 110 responds to user 200's input by obtaining the query information input by user 200, which includes an item identifier and a version identifier. Client 110 generates a query request based on this query information and sends it to query device 120 via the network. After receiving the query request, query device 120 parses it to obtain the query information and generates a query instruction based on the item identifier and version identifier in the query information. This query instruction is then sent to database 130 via the database connection driver. After executing the query instruction, database 130 matches the stored test records with the corresponding item identifier and version identifier based on the query instruction. The matched test records are then returned to query device 120 as a query result set. After processing the query result set, query device 120 presents the target test record to user 200 through client 110.

[0039] Thus, compared to the query method of locating the target document by document name or number and then having the user 200 search item by item within the document, the query device 120 can directly locate the test records included in the target version based on the item identifier and version identifier. This shortens the query path from "first locate the document and then search item by item" to "directly locate the test record", thereby reducing query time and improving query efficiency.

[0040] Understandable Figure 1 The architecture of the test record query system 10 shown is merely an example of an architecture provided by this application embodiment. Other possible test record query systems may include a greater number of users 200, a greater number of clients 110, a greater number of query devices 120, or even a greater number of databases 130, etc., and this application does not limit them in this regard.

[0041] like Figure 2 The diagram shown is a flowchart illustrating a method for querying test records according to an embodiment of this application. This method can be applied to... Figure 1 The test record query system 10 shown can be applied to other applicable test record query systems. The following example demonstrates its application in... Figure 1 The test record query system 10 shown is used as an example for illustration. Figure 2 As shown, the method may specifically include the following steps.

[0042] S201: Query device 120 obtains query information, which includes entry identifier and version identifier.

[0043] The entry identifier is used to identify the target test entry to be queried among multiple test entries. A test entry is the smallest execution unit of a test task, corresponding to an independent test step or a test parameter. Each test entry is assigned a unique entry identifier in database 130 to distinguish different test entries. For example, the entry identifier can be a string, such as "TC-001-02", where "TC" represents a test case (TC), "001" represents the functional module number, and "02" represents the second test case under that module. The entry identifier can also be a pure numeric ID, hierarchical coding, functional abbreviation plus serial number, etc., and this application does not limit its application to these forms.

[0044] The version identifier is used to identify the target version to be queried among at least one version included in the target test entry. The same test entry may have multiple versions at different times due to upstream design changes, parameter adjustments, or test procedure modifications, and each version has a corresponding version identifier. For example, the version identifier can be a string, such as "V1.0", "V2.0", "V1.1", etc., where "V" represents the version (V) and the number represents the version number.

[0045] As an implementation example, the version identifier value can reflect the version evolution process of a test item. For instance, the version identifier can be encoded in the format "Vx.y", where "x" represents the major version number of the test item and "y" represents the minor version number. When a test item is first created, its version identifier can be set to "V1.0". When the test parameters of the test item are adjusted, for example, the allowable deviation range is adjusted from ±1% to ±1.5%, the minor version number of the version identifier increments; for example, the version identifier can be updated from "V1.0" to "V1.1". When the test steps or test content of the test item change, for example, adding a new test operation to the original test steps, such as adding verification of the valve's response time under a 50% opening command, the major version number of the version identifier increments; for example, the version identifier can be updated from "V1.1" to "V2.0". Through the above encoding method of the version identifier, different types of changes to the test item can be distinguished according to different values ​​of the version identifier, facilitating refined management of the version evolution process of the test item by testers.

[0046] In one possible implementation, client 110 can obtain the entry identifier of the target test entry and the version identifier of the target version to be queried, which are entered by user 200 through their input interface. For ease of distinction and description, the identifier of the target test entry will be referred to as the entry identifier, and the identifier of the target version will be referred to as the version identifier. For example, client 110 can obtain the above input information in response to user 200 entering "TC-001" in the entry identifier input box and "V2.0" in the version identifier input box and clicking the query button. Client 110 encapsulates the above information entered by user 200 into a query request and sends it to query device 120 via the network. After receiving the query request, query device 120 can parse the query request to obtain the entry identifier "TC-001" and the version identifier "V2.0" carried in the query request, that is, obtain the query information.

[0047] S202: The query device 120 queries the target test record from the database 130 based on the entry identifier and version identifier.

[0048] Database 130 pre-stores structured data. Specifically, database 130 stores: identifiers of multiple test items, identifiers of at least one version included in each test item, test records included in each version, and change status associated with each version. The change status indicates whether a version has been changed and the type of change. That is, in database 130, each test item is associated with at least one version, each version is associated with at least one test record, and each level has a corresponding identifier field. For example, the test record table in database 130 may include the following fields: item identifier, version identifier, change identifier, test record, etc. Each test record establishes an association with the corresponding test item and version through the item identifier, version identifier, and change identifier.

[0049] After obtaining the query information, the query device 120 executes the query in the database 130. The matching method of the query device 120 may also have several variations; two possible implementation methods are provided below as examples.

[0050] In a first possible implementation, the query device 120 can obtain the target test record based on the entry identifier and the version identifier. Specifically, the query device 120, based on the entry identifier obtained in S201, queries among multiple test entries stored in the database 130 for a test entry that matches the entry identifier. For ease of distinction and description, in this embodiment, the test entry that matches the entry identifier is referred to as the target test entry. Then, the query device 120, based on the version identifier obtained in S201, queries among at least one version corresponding to the target test entry for a version that matches the version identifier, thereby obtaining the target version. Finally, the query device 120 obtains the test records included in the target version from the database 130, thus obtaining the target test record.

[0051] In a second possible implementation, the query information also includes a change identifier, and the query device 120 obtains the target test record based on the entry identifier, version identifier, and change identifier. Specifically, S202 may include the following sub-steps.

[0052] S2021: Query device 120 determines the target version based on the entry identifier and version identifier.

[0053] The query device 120, based on the entry identifier obtained in S201, queries among multiple test entries stored in the database 130 for a test entry that matches the entry identifier, thereby obtaining the target test entry. The query device 120, based on the version identifier obtained in S201, queries among at least one version corresponding to the target test entry for a version that matches the version identifier, thereby obtaining the target version.

[0054] S2022: Query device 120 queries the target version for a version that matches the change identifier based on the change identifier.

[0055] Based on the change identifier obtained in S201, the query device 120 matches the change status with the change identifier in at least one version corresponding to the target test item.

[0056] In this embodiment, the change identifier may have multiple values, and correspondingly, the matching method of the query device 120 may also have multiple scenarios. Two possible implementation examples are provided below.

[0057] In the first implementation example, the change flag is a Boolean value, which can be either "yes" or "no". When the change flag is "yes", it indicates that a version that has undergone a change needs to be queried. The query device 120 queries for versions with a change status of "yes" among at least one version corresponding to the target test item, i.e., queries for versions that have undergone a change. When the change flag is "no", it indicates that a version that has not undergone a change needs to be queried. The query device 120 queries for versions with a change status of "no" among at least one version corresponding to the target test item, i.e., queries for versions that have not undergone a change.

[0058] As a second implementation example, the change identifier serves as a category label to indicate the specific change type. For example, the change identifier can be set to "Added Step," indicating that user 200 wants to query versions changed due to the addition of a test step; the change identifier can also be set to "Deleted Step," indicating that user 200 wants to query versions changed due to the deletion of a test step. When the change identifier is set to "Added Step," the query device 120 queries at least one version corresponding to the target test item for versions with the change type "Added Step," i.e., versions changed due to the addition of a test step. When the change identifier is set to "Deleted Step," the query device 120 queries at least one version corresponding to the target test item for versions with the change type "Deleted Step," i.e., versions changed due to the deletion of a test step.

[0059] The query device 120 identifies the successfully matched version as the version that matches the change identifier. If no version matching the change identifier is found, the query device 120 determines that the match has failed and returns a prompt message to the client 110, such as "No version matching the change identifier was found," to inform the user that there are no matching results under the current query conditions.

[0060] It should be noted that the two ways of taking the value of the change identifier and the corresponding matching process described above are only illustrative examples and are not intended to limit the scope of protection of this application. In other embodiments, the change identifier may also take other values, such as "modify parameters" or "adjust order", and accordingly, the query device 120 may use a similar method to perform the matching query, which is not limited in this application.

[0061] S2023: Query device 120 to determine the target test records included in the version that matches the change identifier.

[0062] The query device 120 retrieves the test records included in the version matching the change identifier in S2022 from the database 130, thus obtaining the target test record.

[0063] It should be noted that the two implementation methods described above are merely illustrative examples and are not intended to limit the scope of protection of this application. In other embodiments, the query device 120 may also use other methods to obtain the target test records, and this application does not limit this approach.

[0064] Furthermore, the query device 120 can also send the retrieved target test records back to the client 110, so that the client 110 can present the target test records to the user 200. The client 110 can present the retrieved target test records in a list format.

[0065] To facilitate understanding, the process of querying target test records by device 120 will be described below with specific examples, using two possible matching methods as examples.

[0066] In a first possible implementation, assuming that the query information obtained by client 110 has an entry identifier of "TC-001", a version identifier of "V2.0", and a change identifier of "Yes", query device 120 determines the target version as "V2.0" based on the entry identifier "TC-001" and the version identifier "V2.0" in step S2021. In step S2022, query device 120 queries at least one version corresponding to the target test entry for versions with a change status of "Yes" based on the change identifier "Yes", and determines that the version matching the change identifier is V2.0, which has changed due to the test parameter being adjusted from ±1% to ±1.5%. In step S2023, query device 120 retrieves test records REC-002 and REC-003 under version V2.0 from database 130 as the target test records. Client 110 presents two target test records to user 200 on the display interface. Specific information includes: "Operator sends a 50% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1.5%", actual test results "valve opening 50.3%" and "valve opening 49.8%", and execution result "passed". Database 130 stores three test records: REC-001, REC-002, and REC-003. REC-001 is identified as "TC-001" and has a version identifier of "V1.0". This is the initial version, and the test record content is: "Operator sends a 50% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1%; actual valve opening 48.2%, deviation -1.8%", and execution result "failed". REC-002 is labeled "TC-001" and version "V2.0". The test parameters have been adjusted in this version. The test record states: "Operator sends a 50% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1.5%; Actual valve opening is 50.3%, with a deviation of +0.3%", and the result is "Pass". REC-003 is also labeled "TC-001" and version "V2.0". The test record states: "Operator sends a 50% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1.5%; Actual valve opening is 49.8%, with a deviation of -0.2%", and the result is "Pass".

[0067] In a second possible implementation, the query information obtained by client 110 has an entry identifier of "TC-001", a version identifier of "V2.0", and a change identifier of "No". In step S2021, query device 120 determines the target version as "V2.0". In step S2022, query device 120 queries versions with a change status of "No" based on the change identifier "No", and the matched version is V1.0, which is the initial version and has not undergone any changes. In step S2023, query device 120 identifies test record REC-001 under version V1.0 as the target test record and presents it to user 200 through client 110.

[0068] If the query device 120 does not find a target version that matches the entry identifier and version identifier in step S2021, or does not find a version that matches the change identifier in step S2022, the query device 120 can return a prompt message to the client 110, such as "No matching test record found", to inform the user that there is no matching result under the current query conditions.

[0069] It should be noted that the two query methods described above are merely illustrative examples and are not intended to limit the scope of protection of this application. In other embodiments, the query device 120 may also use other methods to query the target test records, and this application does not limit these methods.

[0070] In further possible implementations, this embodiment may also include the following steps.

[0071] S203: Query device 120 to generate test documents.

[0072] After step S202, the query device 120 can also generate a test document according to the target test item, target version and target test record, based on a preset test document template.

[0073] The preset test document templates can include various types of document templates such as test reports or completion reports. The query device 120 fills in the relevant information from the target test items, target version, and target test records into the corresponding positions in the template, and generates a complete test document according to the preset format and structure of the template.

[0074] For example, suppose user 200 inputs an entry identifier of "TC-001" and a version identifier of "V2.0" in step S201, and query device 120 obtains two target test records, REC-002 and REC-003. Query device 120 automatically generates a test document based on the target test entry "TC-001", the target version "V2.0", and the two target test records, according to a preset test document template. This test document may include: an entry description of the target test entry, "The operator sends a 50% opening command to verify whether the valve response meets the expected requirements", version information "V2.0", a list of test records, and test conclusions. The test record list is arranged in chronological order of execution time, namely REC-002 and REC-003. Each test record contains test design information, "The valve is expected to reach the target opening within 5 seconds, with a deviation not exceeding ±1.5%", and test execution information, "Actual valve opening 50.3%" or "Actual valve opening 49.8%", with the execution result being "Pass". The test result was "passed".

[0075] The query device 120 will present the generated test document to the user 200 through the client 110, or store it in the database 130 for later review.

[0076] Through the above steps, user 200 can quickly and accurately retrieve the target test record from database 130 by inputting the entry identifier and version identifier. When the query information also includes a change identifier, user 200 can further filter the test records according to the change type to meet the query needs of different scenarios. At the same time, the query device 120 can automatically generate test documents based on the query results, realizing an end-to-end automated process from query to document output, thus improving the efficiency of test document generation.

[0077] Understandable Figure 2 The flowchart of the method for querying test records shown is merely an example of a method provided in this application embodiment. In other possible implementations, step S203, i.e., generating test documents, is an optional step, and user 200 can choose whether to generate test documents according to actual needs. This application does not limit this.

[0078] See Figure 3 This is a flowchart illustrating a test record generation and storage method provided in an embodiment of this application. For ease of understanding and explanation, Figure 3 This method is applied in China Figure 1 The test record query system 10 shown is illustrated using the query device 120 executing the method flow as an example. In other possible embodiments, the method flow may also be executed by other devices, and there is no limitation on this.

[0079] like Figure 3As shown, the method may specifically include the following steps.

[0080] S301: Query device 120 initiates testing on multiple test items.

[0081] The query device 120 sends test commands to the device under test (DUT) via the client 110. After executing the test, the DUT returns test data. The DUT can be a hardware device or component requiring functional verification, such as a valve controller, temperature sensor, or pump controller. Taking a valve controller as an example, the query device 120 sends an opening command to the valve controller via the client 110. Upon receiving the command, the valve controller executes the corresponding valve opening action and returns the actual opening value as test data. Test execution can be manually triggered by a tester or controlled by the query device 120 using automated testing tools; this application does not impose any limitations on this.

[0082] For example, taking valve opening control testing as an example, this test is used to verify whether the valve's response under different opening commands meets the design requirements. The query device 120 stores three test entries: TC-001-01, TC-001-02, and TC-001-03. TC-001-01 verifies the valve's response under a 50% opening command, TC-001-02 verifies the valve's response under a 100% opening command, and TC-001-03 verifies the valve's response under a 0% opening command. The initial version of each test entry is identified as V1.0, and the corresponding test design information is as follows: "Operator sends a 50% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1%", "Operator sends a 100% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1%", and "Operator sends a 0% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1%". During the test execution, the query device 120 responds to the operation of the tester by sending test instructions to the device under test through the client 110, such as sending a 50% opening instruction to the valve, and receiving the actual opening feedback value returned by the device under test.

[0083] It should be noted that during test execution, the query device 120 can record and track the execution status of each test item in real time. Testers can view the execution progress of the current test task through the client 110 to see which test items have been completed, which are being executed, and which have not yet been executed.

[0084] S302: Query device 120 to obtain test data, which includes test design, test execution results, and test verification information.

[0085] The query device 120 acquires test data during test execution. This test data may include at least one of the following: test design, test execution results, or test verification information. Specifically, the test design may include information such as test steps, test parameters, and expected results; the test execution results may include actual results and pass / fail determinations; and the test verification information may include information such as the executor, execution time, and environmental conditions.

[0086] For example, taking test item TC-001-01 as an example, this test item is identified as "TC-001-01" and the version is identified as "V1.0", used to verify the valve's response under a 50% opening command. After the query device 120 sends a 50% opening command to the device under test, the obtained test data includes: test design information "Operator sends a 50% opening command, the valve is expected to reach the target opening within 5 seconds, with a deviation of no more than ±1%", test execution result information "Actual valve opening 48.2%, deviation -1.8%", and test verification information "Executor Zhang San, execution time 2025-01-15 10:20:00, ambient temperature 25℃, ambient humidity 45%". The query device 120 compares the measured result "actual valve opening 48.2%" with the expected result "device deviation no more than ±1%". The measured deviation of -1.8% exceeds the allowable range of ±1%, therefore the test conclusion is "failure".

[0087] Taking test item TC-001-02 as an example, this test item is identified as "TC-001-02" and the version is identified as "V1.0". It is used to verify the valve's response under a 100% opening command. After query device 120 sends a 100% opening command to the device under test, the obtained test data includes: test design information "Operator sends 100% opening command, expected valve to reach target opening within 5 seconds, deviation not exceeding ±1%", test execution result information "actual valve opening 98.2%, deviation -1.8%", test verification information "Executor Zhang San, execution time 2025-01-15 10:35:00, ambient temperature 25℃, ambient humidity 45%", and the test conclusion is "failure".

[0088] Taking test item TC-001-03 as an example, this test item is identified as "TC-001-03" and the version is identified as "V1.0". It is used to verify the valve's response under a 0% opening command. After query device 120 sends a 0% opening command to the device under test, the obtained test data includes: test design information "Operator sends 0% opening command, expected valve to reach target opening within 5 seconds, deviation not exceeding ±1%", test execution result information "Actual valve opening 0.5%, deviation +0.5%", test verification information "Executor Zhang San, execution time 2025-01-15 10:50:00, ambient temperature 25℃, ambient humidity 45%", and the test conclusion is "Pass".

[0089] Taking test item TC-001-01 under version "V1.1" as an example. Due to upstream design changes, the allowable deviation range in this version was adjusted from ±1% to ±1.5%. The test data obtained from equipment 120 includes: test design information "Operator sends a 50% opening command, expecting the valve to reach the target opening within 5 seconds, with a deviation not exceeding ±1.5%", test execution result information "Actual valve opening is 50.3%, deviation is +0.3%", test verification information "Executor: Li Si, Execution time: 2025-06-20 09:30:00, Ambient temperature: 26℃, Ambient humidity: 42%", and the test conclusion is "Pass".

[0090] In one possible implementation, the test record may contain more or fewer fields. For example, the test record may also include descriptions of test items, test environment information, test tool information, remarks, etc., and this application does not limit this.

[0091] It should be noted that this test record is structured data, meaning that each field in each test record has a clearly defined data type and format, facilitating subsequent storage and retrieval. For example, the "Execution Result" field can be a Boolean or enumeration type, and the "Execution Time" field can be a date and time type.

[0092] S303: Query device 120 to generate corresponding test records based on test data. Test data includes test design, test execution results, and test verification information.

[0093] Based on the test data obtained in step S302, the query device 120 generates a test record corresponding to each test item according to a preset test record format. Each test record is stored in the database 130 in a structured manner and is associated with a corresponding item identifier and version identifier, so that each test record can be associated with the corresponding test item and version through the item identifier and version identifier.

[0094] For example, based on the test data of test item TC-001-01 in version V1.0 in step S302, the device 120 generates the following test record: the record is identified as REC-001, the test content is "the operator sends a 50% opening command, and the valve is expected to reach the target opening within 5 seconds with a deviation of no more than ±1%; the actual valve opening is 48.2%, and the deviation is -1.8%", and the execution result is "failure". This test record is associated with the item identifier TC-001-01 and the version identifier V1.0.

[0095] Based on the test data of test item TC-001-02 in version V1.0, the following test record was generated by device 120: the record is identified as REC-002, the test content is "the operator sends a 100% opening command, the valve is expected to reach the target opening within 5 seconds, and the deviation is no more than ±1%; the actual valve opening is 98.2%, and the deviation is -1.8%", the execution result is "failed", and this test record is associated with the item identifier TC-001-02 and the version identifier V1.0.

[0096] Based on the test data of test item TC-001-03 in version V1.0, the following test record was generated by device 120: the record is identified as REC-003, the test content is "the operator sends a 0% opening command, the valve is expected to reach the target opening within 5 seconds, and the deviation is no more than ±1%; the actual valve opening is 0.5%, and the deviation is +0.5%", the execution result is "passed", and this test record is associated with the item identifier TC-001-03 and the version identifier V1.0.

[0097] Based on the test data of test item TC-001-01 in version V1.1, the following test record was generated by device 120: the record is identified as REC-004, the test content is "the operator sends a 50% opening command, the valve is expected to reach the target opening within 5 seconds, and the deviation is no more than ±1.5%; the actual valve opening is 50.3%, and the deviation is +0.3%", the execution result is "passed", and this test record is associated with the item identifier TC-001-01 and the version identifier V1.1.

[0098] S304: Query device 120 to store the test record by appending it.

[0099] The query device 120 stores the test record generated in step S303 into the database 130 by appending the record.

[0100] In this context, appending refers to adding each test record as an independent data record to the test record table in database 130. The new test record will not overwrite the existing test record. In other words, when the same test item is executed in multiple rounds of testing under different versions, the test records generated in each round of testing are stored in database 130 as independent records, and the records do not interfere with each other.

[0101] For example, after test entry TC-001-01 is tested under version V1.0, query device 120 stores REC-001 as a separate record in the test record table of database 130. This record is associated with the entry identifier TC-001-01 and the version identifier V1.0. When the version of the test entry is updated to V1.1, query device 120 appends REC-004 as another separate record to the same test record table. This record is associated with the entry identifier TC-001-01 and the version identifier V1.1. At this time, database 130 has two records, REC-001 and REC-004, existing simultaneously, and REC-001 will not be overwritten by REC-004.

[0102] Storing test records by appending them ensures that all historical test records are completely preserved, preventing them from being overwritten or lost by new test data, thus guaranteeing the integrity and traceability of the test data. When test record queries are needed later, the query device 120 can retrieve all test records for the target version from the database 130, including historical records and current records.

[0103] It should be noted that the database 130 may include identifiers for multiple test entries, identifiers for at least one version included in each test entry, and test records included in each version. In other words, the database 130 stores three levels: test entries, versions, and test records. Each test entry is associated with at least one version, and each version is associated with at least one test record. Each level has a corresponding identifier field for subsequent querying of entry identifiers and version identifiers.

[0104] Understandable Figure 3 The flowchart illustrating the test record generation and storage method is merely one example provided in this application. In other possible implementations, the generation of test data and the generation of test records can be combined into one step or broken down into more sub-steps; this application does not limit this approach.

[0105] See Figure 4 , Figure 4A schematic diagram of a test record query device according to an embodiment of this application is shown. This test record query device 400 can be applied to test record query scenarios or deployed in a computer device used for querying test records. The test record query device 400 may include an acquisition module 401 and a query module 402.

[0106] The acquisition module 401 is used to acquire query information. This query information includes an entry identifier and a version identifier. The entry identifier identifies the target test entry to be queried among multiple test entries, and the version identifier identifies the target version to be queried among at least one version included in the target test entry. Each of these at least one version includes at least one test record. The acquisition module 401 can acquire the query information input by the user 200 through the client 110.

[0107] The query module 402 is used to query the target test record from the database based on the entry identifier and version identifier obtained by the acquisition module 401. The target test record is the test record included in the target version. The database includes identifiers of multiple test entries stored in a structured manner, identifiers of at least one version included in each of the multiple test entries, and test records included in each of the at least one version included in each test entry.

[0108] In one possible implementation, the query module 402 is specifically configured to: query a target test entry among multiple test entries stored in the database based on an entry identifier; query a target version among at least one version corresponding to the target test entry stored in the database based on a version identifier; and determine a target test record based on the target version, wherein the target test record is the test record included in the target version.

[0109] In one possible implementation, the query information acquired by the acquisition module 401 further includes a change identifier, which is used to identify whether a version has changed. The query module 402 is specifically used to: query the target version for versions matching the change identifier based on the change identifier; and determine the target test records included in the versions matching the change identifier.

[0110] In one possible implementation, the test record query device 400 further includes a generation module. This generation module is used to generate a test document according to a preset test document template, based on the target test entry, the target version, and the target test record.

[0111] In one possible implementation, the test record query device 400 further includes a storage module. This storage module is used to: acquire test data generated during the execution of tests on each of a plurality of test items; generate a test record corresponding to each of the plurality of test items based on the test data; and store the test records in a database by appending them. The test data includes at least one of test design, test execution results, or test verification information.

[0112] In one possible implementation, the version identifier is generated when the test content of the test entry is updated.

[0113] The query test record device 400 provided in this embodiment corresponds to the aforementioned Figure 2 and Figure 3 The method for querying test records in the illustrated embodiment is described above. Therefore, the functions of each module in this embodiment and their technical effects can be found in the foregoing. Figure 2 and Figure 3 The relevant details in the illustrated embodiments are described herein and will not be repeated here.

[0114] Understandable Figure 4 The structure of the query test recording device 400 shown is merely one structural example provided by the embodiments of this application. In other possible implementations, the query test recording device 400 may include more or fewer modules, and this application does not limit this.

[0115] See Figure 5 This is a schematic diagram of the structure of a computer device 500 provided in an embodiment of this application. The computer device 500 can be applied to test record query scenarios, or it can be deployed in a computer device used for querying test records. Figure 5 As shown, the computer device 500 includes a processor 501 and a memory 502.

[0116] Processor 501 may include one or more processing units. For example, processor 501 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices. Processor 501 is the control center of computer device 500, performing various functions and processing data of computer device 500 by running or executing software programs stored in memory 502 and accessing data stored in memory 502.

[0117] Memory 502 may include read-only memory (ROM) and random access memory (RAM) for storing instructions and data. Memory 502 may also include non-volatile random access memory. Exemplarily, memory 502 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory.

[0118] In one possible implementation, the memory 502 stores a computer program, and the processor 501 executes the computer program to implement the aforementioned... Figure 2 and Figure 3 The steps of the method for querying test records executed by the query device 120 in the illustrated embodiment specifically include: obtaining query information, which includes an entry identifier and a version identifier; querying a target test record from the database based on the entry identifier and the version identifier; and determining the target test record. For the specific implementation of the method steps executed by the processor 501 when executing the computer program, please refer to the foregoing. Figure 2 and Figure 3 The relevant details in the illustrated embodiments are described herein and will not be repeated here.

[0119] Understandable Figure 5The structure of the computer device 500 shown is merely one structural example provided in the embodiments of this application. In other possible implementations, the computer device 500 may also include more or fewer components, such as a communication interface for data interaction with external devices, or a bus for connecting the various components inside the computer device 500. This application does not limit the scope of the application in this regard.

[0120] In addition, embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores instructions that, when executed on a computer device, cause the computer device to perform the query test record method provided in embodiments of this application.

[0121] In addition, this application also provides a computer program product. The computer program product includes a computer program or instructions that, when executed on a computer device, cause the computer device to perform the query test record method provided in this application.

[0122] Based on the above description of the embodiments, those skilled in the art will understand that all or part of the steps in the embodiments of this application can be implemented using software plus a general-purpose hardware platform, or can be implemented using dedicated hardware. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This software product can be stored in a computer-readable storage medium and may include several instructions to cause a computer device to execute the methods in the various embodiments of this application.

[0123] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for querying test records, characterized in that, The method includes: Obtain query information, which includes an entry identifier and a version identifier. The entry identifier is used to identify the target test entry to be queried among multiple test entries, and the version identifier is used to identify the target version to be queried among at least one version included in the target test entry. Each of the at least one version includes at least one test record. Based on the entry identifier and the version identifier, a target test record is queried from the database. The target test record is the test record included in the target version. The database includes the identifiers of the plurality of test entries stored in a structured manner, the identifier of at least one version included in each of the plurality of test entries, and the test record included in each of the at least one version included in each test entry.

2. The method according to claim 1, characterized in that, The step of querying the target test record from the database based on the entry identifier and the version identifier includes: Based on the entry identifier, the target test entry is queried from the plurality of test entries stored in the database; Based on the version identifier, query the target version in at least one version corresponding to the target test entry stored in the database; Based on the target version, the target test record is determined, wherein the target test record is the test record included in the target version.

3. The method according to claim 2, characterized in that, The query information also includes a change identifier, which is used to identify whether the version has changed; The step of determining the target test record based on the target version includes: Based on the change identifier, query the target version for a version that matches the change identifier; The version that matches the change identifier includes the target test record.

4. The method according to claim 2, characterized in that, After retrieving the target test record from the database based on the entry identifier and the version identifier, the process further includes: Based on the target test items, the target version, and the target test records, a test document is generated according to a preset test document template.

5. The method according to claim 1, characterized in that, The version identifier is generated when the test content of the test entry is updated.

6. The method according to claim 1, characterized in that, Before obtaining the query information, the method further includes: Acquire the test data generated during the execution of tests on each of the plurality of test items; Based on the test data, generate a test record corresponding to each of the plurality of test items; The test records are stored in the database by appending them.

7. The method according to claim 6, characterized in that, The test data includes at least one of test design, test execution results, or test verification information.

8. A device for querying test records, characterized in that, The device includes: The acquisition module is used to acquire query information, which includes an entry identifier and a version identifier. The entry identifier is used to identify the target test entry to be queried among multiple test entries, and the version identifier is used to identify the target version to be queried among at least one version included in the target test entry. Each of the at least one version includes at least one test record. The query module is used to query a target test record from the database based on the entry identifier and the version identifier. The target test record is the test record included in the target version. The database includes the identifiers of the plurality of test entries stored in a structured manner, the identifier of at least one version included in each of the plurality of test entries, and the test record included in each of the at least one version included in each test entry.

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

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

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the query test record method as described in any one of claims 1 to 7.

Images