Block chain-based information processing method and device, equipment, medium and product

Abstract

The invention provides an information processing method and device based on a block chain, equipment, a medium and a product, which can be applied to the fields of an information processing technology, a testing technology, a block chain technology and finance. The information processing method based on the block chain comprises the steps that a monitored trigger event is responded, target to-be-tested data corresponding to the trigger event and obtained from the block chain is tested according to an intelligent contract used for the trigger event, a test result is obtained, the block chain pre-stores multiple pieces of pre-processed candidate to-be-tested data, and the candidate to-be-tested data are stored in the intelligent contract; each candidate to-be-tested data has a timestamp and a data type; and in response to the test result passing multi-party cooperative verification, storing the test result to the block chain in a chain structure according to the time information corresponding to the test result.

Description

Technical Field

[0001] This application relates to information processing technology, testing technology, blockchain technology and the financial field, and more specifically, to a blockchain-based information processing method, apparatus, equipment, medium and product. Background Technology

[0002] With the development of computer technology, various software development and testing techniques have emerged. In the software development and testing process, test data is the core basis for verifying software quality.

[0003] In one example, the method for storing test data may include at least one of the following: a centralized database-based storage method, a trusted timestamp service-based storage method, and a distributed file system-based storage method. A centralized database-based storage method involves using a relational database or document database to store test results and implementing basic version management through transaction logs. However, this method carries the risk of privilege abuse or attacks, leading to a high risk of test result tampering. A trusted timestamp service-based storage method involves submitting the hash value of the test data to a third-party institution such as the National Time Service Center to obtain a timestamp certificate. However, this method has high service costs and cannot cover the entire test lifecycle. A distributed file system-based storage method involves using a distributed storage system to store test logs and ensuring data integrity through content addressing. However, this method cannot prevent multiple nodes from jointly deleting or modifying data.

[0004] In the process of realizing the concept of this application, the inventors found that the related technologies have at least the following problems: due to the high risk of tampering, low traceability efficiency and high compliance costs of the above-mentioned methods for storing test data, it is difficult to achieve effective storage of test data. Summary of the Invention

[0005] In view of this, this application provides a blockchain-based information processing method, apparatus, device, medium, and product.

[0006] According to one aspect of this application, a blockchain-based information processing method is provided, comprising: in response to detecting a triggering event, testing target test data corresponding to the triggering event obtained from the blockchain according to a smart contract for the triggering event, and obtaining a test result, wherein the blockchain pre-stores a plurality of pre-processed candidate test data, each of the candidate test data having a timestamp and a data type; and in response to the test result being verified by multi-party collaborative verification, storing the test result in a chain structure on the blockchain according to the time information corresponding to the test result.

[0007] According to another aspect of this application, a blockchain-based information processing device is provided, comprising: a testing module, configured to, in response to a triggered event, test target test data corresponding to the triggered event obtained from the blockchain according to a smart contract for the triggered event, and obtain test results, wherein the blockchain pre-stores a plurality of pre-processed candidate test data, each of the candidate test data having a timestamp and a data type; and a first storage module, configured to, in response to the test results being verified by multi-party collaboration, store the test results in a chain structure on the blockchain according to the time information corresponding to the test results.

[0008] According to another aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more instructions, wherein, when the one or more instructions are executed by the one or more processors, the one or more processors cause the one or more processors to perform the method as described above.

[0009] According to another aspect of this application, a computer-readable storage medium is provided having executable instructions stored thereon, which, when executed by a processor, cause the processor to implement the method described above.

[0010] According to another aspect of this application, a computer program product is provided, the computer program product including computer-executable instructions, which, when executed, are used to implement the method described above.

[0011] According to embodiments of this application, by listening to trigger events and using smart contracts to automatically test the target test data, the automation and efficiency of the testing process are improved, and manual intervention and errors are reduced. Simultaneously, by storing the test results in a chain structure on the blockchain after multi-party collaborative verification, the authenticity and immutability of the test results are ensured. This at least partially overcomes the technical problem that the various methods of test data storage have high tampering risks, low traceability efficiency, and high compliance costs, making it difficult to effectively store test data. This enhances the credibility and security of the data, enabling automated and reliable processing and storage of test data, thereby achieving reliable management of the entire lifecycle of test data. Attached Figure Description

[0012] The above and other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0013] Figure 1 This illustration schematically shows a system architecture to which information processing methods can be applied according to embodiments of this application;

[0014] Figure 2 A flowchart illustrating a blockchain-based information processing method according to an embodiment of this application is shown schematically.

[0015] Figure 3 This illustration schematically shows an example of a process for obtaining candidate test data according to an embodiment of this application;

[0016] Figure 4 The illustration shows an example diagram of the process for obtaining and verifying test results according to an embodiment of this application;

[0017] Figure 5 This illustration shows an example diagram of a blockchain-based information processing procedure according to an embodiment of the present application;

[0018] Figure 6 This illustration shows an example diagram of a blockchain-based information processing procedure according to another embodiment of this application;

[0019] Figure 7 A block diagram of a blockchain-based information processing apparatus according to an embodiment of this application is schematically shown; and

[0020] Figure 8 A block diagram of an electronic device suitable for implementing a blockchain-based information processing method according to an embodiment of this application is illustrated schematically. Detailed Implementation

[0021] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0023] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0024] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0025] In the technical solution of this invention, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0026] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this invention offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0027] Centralized database-based storage methods involve using relational or document databases to store test results and implementing basic version management through transaction logs. However, this approach carries the risk of privilege abuse or attacks, leading to a high risk of test result tampering.

[0028] The storage method based on trusted timestamp services involves submitting the hash value of the test data to a third-party organization such as the National Time Service Center to obtain a timestamp certificate. However, this method has a high service cost and cannot cover the entire test lifecycle.

[0029] The storage method based on a distributed file system refers to using a distributed storage system to store test logs and ensuring data integrity through content addressing. However, this method cannot prevent multiple nodes from jointly deleting or modifying data.

[0030] In summary, due to the high risk of tampering, low traceability efficiency, and high compliance costs of the above-mentioned methods for storing test data, it is difficult to achieve effective storage of test data.

[0031] To at least partially address the technical problems existing in related technologies, this application provides a blockchain-based information processing method, apparatus, device, medium, and product, which can be applied to blockchain-based information processing methods, apparatuses, devices, media, and products. The blockchain-based information processing method includes: in response to detecting a trigger event, testing target test data corresponding to the trigger event obtained from the blockchain according to a smart contract used to trigger the event, and obtaining test results, wherein the blockchain pre-stores multiple pre-processed candidate test data, each candidate test data having its own timestamp and data type; and in response to the test results being verified through multi-party collaborative verification, storing the test results in a chain structure on the blockchain according to the time information corresponding to the test results.

[0032] It should be noted that the blockchain-based information processing method and apparatus provided in this application can be used in information processing technology, testing technology, and blockchain technology. The blockchain-based information processing method and apparatus provided in this application can also be used in any field other than information processing technology, testing technology, and blockchain technology, such as in the financial field. The application fields of the blockchain-based information processing method and apparatus provided in this application are not limited.

[0033] Figure 1 The illustration schematically depicts a system architecture to which the information processing method can be applied according to embodiments of this application. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this application, in order to help those skilled in the art understand the technical content of this application, but do not mean that the embodiments of this application cannot be used in other devices, systems, environments or scenarios.

[0034] like Figure 1 As shown, the system architecture 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a blockchain network 104, and a server 105.

[0035] Users can interact with server 105 through blockchain network 104 using at least one of the first terminal device 101, second terminal device 102, and third terminal device 103 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, second terminal device 102, and third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0036] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0037] Blockchain network 104 may include at least one chain. Each chain may have at least one block. Each block may be used to store information.

[0038] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0039] It should be noted that the information processing method provided in this application embodiment can generally be executed by server 105. Correspondingly, the information processing device provided in this application embodiment can generally be located in server 105. The information processing method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the information processing device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0040] Alternatively, the information processing method provided in the embodiments of this application can also be executed by the first terminal device 101, the second terminal device 102, or the third terminal device 103, or by other terminal devices different from the first terminal device 101, the second terminal device 102, or the third terminal device 103. Correspondingly, the information processing apparatus provided in the embodiments of this application can also be disposed in the first terminal device 101, the second terminal device 102, or the third terminal device 103, or in other terminal devices different from the first terminal device 101, the second terminal device 102, or the third terminal device 103.

[0041] It should be understood that Figure 1 The number of first terminal devices, second terminal devices, third terminal devices, blockchain networks, and servers shown in the diagram is merely illustrative. Depending on implementation needs, any number of first terminal devices, second terminal devices, third terminal devices, blockchain networks, and servers can be included.

[0042] It should be noted that the sequence numbers of the operations in the following methods are for descriptive purposes only and should not be considered as indicating the execution order of the operations. Unless explicitly stated otherwise, the method does not need to be executed in the exact order shown.

[0043] Figure 2 A flowchart illustrating a blockchain-based information processing method according to an embodiment of this application is shown.

[0044] like Figure 2 As shown, the blockchain-based information processing method 200 includes operations S210~S220.

[0045] In operation S210, in response to the detection of a trigger event, the target test data corresponding to the trigger event obtained from the blockchain is tested according to the smart contract used to trigger the event, and the test results are obtained. The blockchain pre-stores multiple pre-processed candidate test data, each of which has its own timestamp and data type.

[0046] When operating S220, in response to the test results being verified through multi-party collaboration, the test results are stored in a chain structure on the blockchain according to the time information corresponding to the test results.

[0047] A triggering event is an event that can initiate a specific testing process. For example, when the code repository receives a new version of code pushed by a developer, it can be considered a triggering event, meaning that a series of tests may need to be performed on the new version of code to verify its functionality and stability.

[0048] Smart contracts are code and rules deployed on a blockchain that are executed automatically when preset conditions are met. For example, when a trigger event is detected that a new version is pushed to the code repository, the corresponding smart contract will be activated and automatically call the testing service to test the test cases related to the new version of the code.

[0049] It should be noted that multiple smart contracts can be pre-configured, each for a specific trigger event. In this case, upon detecting a trigger event, the smart contract used for that event can be determined, allowing for the automatic execution of a test process based on that smart contract. Alternatively, a single smart contract can be configured, defining sub-contracts for different trigger events. In this case, upon detecting a trigger event, the test process for that event can be automatically executed based on the smart contract; this is not a limitation.

[0050] Blockchain is a distributed ledger technology characterized by immutability and traceability. In the embodiments of this application, the blockchain is used to store pre-processed candidate test data and test results. For example, pre-stored test cases, execution logs, and hash values ​​of defect reports are recorded on the blockchain to ensure the security and reliability of this data.

[0051] In embodiments of this application, user consent or authorization can be obtained before acquiring user information. For example, a request to acquire user information can be sent to the user before storing candidate test data. If the user consents or authorizes the acquisition of user information, the operation of storing candidate test data is performed.

[0052] In the embodiments of this application, the blockchain can monitor various preset trigger events in real time. Once a trigger event is detected, the target test data related to the trigger event can be obtained from the blockchain according to the rules and logic pre-written in the smart contract corresponding to the trigger event. Then, the target test data is tested according to the instructions in the smart contract to obtain the test results.

[0053] After a trigger event is detected, a smart contract can automatically retrieve the target test data for that trigger event from multiple candidate test data stored on the blockchain. The target test data refers to the data associated with the trigger event and that needs to be tested. For example, if the trigger event is the push of a new version of the code, the target test data might be the test cases corresponding to the modified or added features in the new version of the code, used to verify whether the functionality of the new version of the code meets the requirements.

[0054] The filtering method for target test data can be configured according to actual business needs and is not limited here. For example, multiple candidate test data can be filtered based on at least one of timestamp and data type to obtain the target test data used to trigger the event. A timestamp records the specific time an event occurs. Each candidate test data has its own corresponding timestamp. For example, if a test case is created and stored on the blockchain on January 1, 2025 at 14:23:05, then that time point is the timestamp of the test case, used for subsequent tracing and verification of the data's order and temporal relationship. Data type is used to distinguish different types of test-related data. Data type can include at least one of test cases, execution logs, and defect reports.

[0055] Test results refer to the output obtained after testing based on the target test data. For example, after executing a test case, the test result may be "pass," indicating that the tested function is normal; or it may be "fail," accompanied by specific error information, indicating that there is a problem with the tested function.

[0056] In another embodiment, a message queue mechanism can also be used. When a trigger event occurs, the event information is sent to the message queue. Then, a dedicated test consumer retrieves the event message from the queue and obtains the target test data from the blockchain according to the smart contract rules corresponding to the event for testing.

[0057] After obtaining the test results, multi-party collaborative verification can be performed. Multi-party collaborative verification refers to the process by which multiple nodes with different roles or in the blockchain jointly verify the test results. For example, after the tester submits the test results, at least three verification nodes can review the results separately. When at least three verification nodes agree on the authenticity of the test results, the test results can be considered to have passed multi-party collaborative verification. Verification nodes can be configured according to actual business needs and are not limited here. For example, verification nodes for development, verification nodes for testing, and verification nodes for operation and maintenance.

[0058] A chain structure refers to a structure where each new data block is linked to the previous data block in a specific way, forming an irreversible chain. For example, in a blockchain, each block contains information such as the hash value of the previous block, thus forming a chain structure. When storing test results, the test results can be stored in a chain structure on the blockchain according to the time information corresponding to the test results, ensuring the orderliness and immutability of the data.

[0059] According to embodiments of this application, by listening to trigger events and using smart contracts to automatically test the target test data, the automation and efficiency of the testing process are improved, and manual intervention and errors are reduced. Simultaneously, by storing the test results in a chain structure on the blockchain after multi-party collaborative verification, the authenticity and immutability of the test results are ensured. This at least partially overcomes the technical problem that the various methods of test data storage have high tampering risks, low traceability efficiency, and high compliance costs, making it difficult to effectively store test data. This enhances the credibility and security of the data, enabling automated and reliable processing and storage of test data, thereby achieving reliable management of the entire lifecycle of test data.

[0060] According to an embodiment of this application, candidate test data can be obtained by: standardizing the original test data according to a preset format rule to obtain intermediate test data, wherein the preset format rule defines the data format for each data type; and performing hierarchical hash calculation on the intermediate test data to obtain candidate test data.

[0061] Raw test data refers to data that has not been processed in any way. For example, the initial draft of test cases for new features written by developers may contain information such as input parameters and expected outputs, but the format is arbitrary and does not follow a unified standard; or the raw execution logs generated during the testing process record test steps, actual outputs, screenshots, etc., but the format is inconsistent and lacks a standardized structure.

[0062] Predefined formatting rules refer to pre-defined standards and requirements for standardizing data formats. Data format refers to the organization and representation of data, specifying which specific fields the data should include, as well as the types and formats of these fields. For example, predefined formatting rules specify that test cases should include fields such as input parameters, expected output, and execution conditions, and specify the field type (e.g., string, integer, boolean value) and format (e.g., date format YYYYMMDD) for each field. Alternatively, predefined formatting rules specify that execution logs should record test steps, actual output, screenshots / videos, etc., with consistent recording formats for each step. Alternatively, predefined formatting rules specify that defect reports should include defect descriptions, severity levels, and repair status, with severity levels expressed in fixed formats such as high, medium, low, or 1, 2, 3.

[0063] For each original test data, the data type of the original test data can be determined, and the original test data can be standardized according to the data format defined in the preset format rules for that data type to obtain intermediate test data with complete structure and standardized fields.

[0064] After obtaining intermediate test data, hierarchical hashing can be performed on the intermediate test data to obtain candidate test data. Hierarchical hashing refers to a method of hashing data, that is, generating hash values ​​that can represent the characteristics of the data through multiple layers of hashing operations.

[0065] Taking the intermediate test data as a test case as an example, we can first calculate the hash value of the entire test case to obtain H1 (e.g., H1 = Hash(Test Case ID + Input Parameters)); then, according to the time window, we aggregate the hash values ​​of multiple test cases within the same time period to generate a new hash value H2 (e.g., H2 = Hash(H1 + H_prev + Log Content)); finally, using the hash tree structure, we perform multi-level combination calculations on all related hash values ​​to obtain the root hash value. This root hash value represents the characteristics of that part of the test cases in the candidate test data and becomes part of the candidate test data, which is stored on the blockchain along with information such as timestamps and data types.

[0066] According to embodiments of this application, by standardizing the original test data, the consistency and compatibility of the data format are ensured, which is beneficial for subsequent storage, management, and sharing. This avoids confusion and errors caused by inconsistent data formats and helps improve blockchain storage efficiency. By performing hierarchical hash calculations on the standardized intermediate test data, an integrity verification mechanism is provided, enabling rapid detection of data tampering, enhancing data credibility and non-repudiation, and effectively improving data standardization and security.

[0067] According to embodiments of this application, the data type includes at least one of the following: test cases, execution logs, and defect reports. When the original data to be tested is a test case, the data format includes input parameters, expected output, and execution conditions; when the original data to be tested is an execution log, the data format includes test steps, actual output, and images or videos; when the original data to be tested is a defect report, the data format includes defect description, severity level, and repair status.

[0068] A test case is a set of conditions used to verify whether software functionality meets expected inputs, operations, and results. In a typical test case, a test case might include input parameters, expected output, and execution conditions. Input parameters are the part of the test case used to input data into the software under test to verify how the software handles different inputs. For example, when testing the addition function of a calculator, the input parameters could be two integer values. Expected output refers to the result that the software is expected to produce, used to compare with the actual output to determine if the software function is working correctly. For example, for the calculator addition function mentioned above, the expected output is the correct sum of the two input integers. Execution conditions refer to the environmental and configuration requirements specified in the test case, ensuring that the test is performed under specific conditions.

[0069] An execution log records detailed information about the software testing process. In one example, an execution log might include test steps, actual output, and images or videos. Test steps refer to the specific operational procedures recorded in the execution log, detailing the actions performed by testers or automated testing tools during the test. For example, when testing a user registration function, the test steps include opening the registration page, entering the username, and entering the password. Actual output refers to the actual results produced by the software under test during execution, as recorded in the execution log. This output may or may not match the expected output. For example, after executing the user registration test steps mentioned above, the actual output might be a successful registration message or the display of some error message. Images or videos refer to screenshots or operation videos recorded in the execution log to more intuitively demonstrate the test process and results, especially when errors or anomalies occur, providing more direct evidence. For example, when an error occurs in the registration function, a screenshot can show the specific content and location of the error message.

[0070] A defect report is a detailed record of defects or problems existing in software. In one example, a defect report might include a defect description, severity level, and fix status. The defect description is a detailed textual description of the software defect, clearly explaining its manifestation and the scenarios in which it occurs. For example, "When multiple pop-ups are clicked simultaneously, the system crashes and displays a blank screen." The severity level is the assessment and classification of the defect's impact, typically categorized as high, medium, or low. For example, a high severity level indicates that the defect will cause serious consequences such as system crashes or data loss; a medium severity level indicates that it will affect the normal use of some functions; and a low severity level might be a minor flaw in the interface. The fix status is the status indicator recorded in the defect report, indicating the current fix status, such as not fixed, fixed but awaiting verification, or fixed.

[0071] According to embodiments of this application, by clearly defining different data types and their corresponding data formats, the integrity and standardization of various types of data to be tested can be ensured. Specifically, for test cases, by clearly defining their input parameters, expected outputs, and execution conditions, the accuracy and repeatability of the tests can be improved, enabling testers to clearly understand the test requirements and ensuring the correctness of test execution. For execution logs, by clearly defining that they include test steps, actual outputs, and information such as screenshots or videos, it is convenient to comprehensively record and trace the test process, which helps to analyze test results and locate problems. For defect reports, by specifying the format of defect description, severity level, and repair status, it is beneficial to convey defect information in a timely and accurate manner, making it easier for developers to quickly understand and handle defects, and improving software quality management and defect repair efficiency.

[0072] According to embodiments of this application, performing hierarchical hash calculation on intermediate test data to obtain candidate test data may include the following operations: dividing the hash values ​​of multiple intermediate test data according to time windows to obtain a set of hash values ​​corresponding to each time window; aggregating the hash values ​​within each time window for each hash value set to obtain an aggregated hash corresponding to each time window; and obtaining candidate test data based on multiple hash values ​​and multiple aggregated hashes.

[0073] A time window refers to an interval in which data is divided according to a set time range. For each intermediate test data point, the hash values ​​of multiple intermediate test data points can be divided according to the time window, resulting in a hash value set corresponding to each time window. The hash value set refers to the collection of hash values ​​of multiple intermediate test data points within a specific time window. For example, within the time window of 08:00:00 to 08:10:00, if three intermediate test data points have hash values ​​H1, H2, and H3 respectively, then these three hash values ​​constitute the hash value set for this time window.

[0074] In one embodiment, the time window can be of fixed length. For example, if the time window is set to 10 minutes, then 08:00:00 to 08:10:00 is one time window, and 08:10:01 to 08:20:00 is another time window. In another embodiment, the time window can be sliding. For example, if the window length is set to 10 minutes and the window slides every 5 minutes, this will create time windows with some overlap. For example, starting from 08:00:00, the first window is 08:00:00-08:10:00, the second window is 08:05:00-08:15:00, and so on. This method is suitable for scenarios with more granular time analysis.

[0075] For each set of hash values, multiple hash values ​​within a time window can be aggregated to obtain a specific aggregate hash corresponding to each time window. An aggregate hash is a single hash value obtained by aggregating multiple hash values ​​within the same time window according to certain rules, used to represent the comprehensive characteristics of multiple data points within that time window. For example, combining and hashing H1, H2, and H3 within the aforementioned time window to obtain H_agg is the aggregate hash for that time window.

[0076] The method for generating aggregated hashes can be configured according to actual business needs and is not limited here. For example, hash values ​​within a time window can be concatenated sequentially and then used for overall hash calculation to obtain an aggregated hash. Alternatively, a weighted hash aggregation method can be used, assigning a weight to each hash value based on the importance of the data corresponding to each hash value or other attributes, and then combining the weighted hash values ​​to obtain the aggregated hash.

[0077] After obtaining the aggregated hashes for each time window, candidate test data can be derived based on multiple hash values ​​and aggregated hashes. For example, multiple hash values ​​and aggregated hashes can be integrated into a predefined data structure, with necessary information such as timestamps and data types appended to form candidate test data. Alternatively, a combination of data structures such as binary trees or hash trees can be constructed to form candidate test data.

[0078] According to embodiments of this application, by dividing the hash values ​​of multiple intermediate test data according to time windows, the data can be managed in an orderly manner according to time sequence, facilitating batch processing and analysis of data from different time periods. By aggregating the hash values ​​within the time window, the amount of data that needs to be stored and transmitted is reduced, while retaining the ability to verify the integrity of the original data. This effectively organizes and processes large amounts of intermediate test data, improving data storage efficiency and security. Furthermore, by integrating multi-dimensional information based on multiple hash values ​​and multiple aggregated hashes to obtain candidate test data, this provides an efficient and reliable data foundation for subsequent testing processes and blockchain trusted storage, contributing to improved efficiency and credibility of test data management.

[0079] Figure 3 The illustration shows an example diagram of the process for obtaining candidate test data according to an embodiment of this application.

[0080] like Figure 3 As shown in 300, after obtaining the original test data 310, it can be standardized according to the preset format rule 320 to obtain intermediate test data 330. The preset format rule 320 defines the data format for each data type.

[0081] For example, if the original test data 310 is a test case, the data format 321 includes input parameters, expected output, and execution conditions. Alternatively, if the original test data 310 is an execution log, the data format 322 includes test steps, actual output, and images or videos. Alternatively, if the original test data 310 is a defect report, the data format 323 includes defect description, severity level, and repair status.

[0082] After obtaining the intermediate test data 330, the hash values ​​of the multiple intermediate test data 330 can be divided according to the time window to obtain a hash value set corresponding to each time window. For each hash value set, the hash values ​​within the time window are aggregated to obtain the aggregate hash 340 corresponding to each time window. For example, multiple aggregate hashes 340 may include aggregate hash 341 corresponding to time window 1, aggregate hash 342 corresponding to time window 2, ..., aggregate hash 34M corresponding to time window M, where M is a positive integer.

[0083] After obtaining multiple aggregate hashes 340, candidate test data 350 can be obtained based on multiple hash values ​​and multiple aggregate hashes 340.

[0084] According to an embodiment of this application, operation S210 may include the following operations: in response to the detection of a triggering event that the code repository version has changed, automatically calling a test service through a smart contract to obtain target test data; or in response to the detection of a triggering event that the defect status has changed, automatically calling a test service through a smart contract to generate target test data; and using test nodes in the blockchain to test the target test data and obtain test results.

[0085] A code repository version change occurs when a developer pushes new code commits to the repository, which can be considered a triggering event. For example, a developer might commit an update to the code repository, modifying the implementation of certain features. When the triggering event is a code repository version change, test cases corresponding to the modified or added features in the new version can be used as target test data. A smart contract for handling code repository version changes can then be used to automatically invoke a test service to test the new code version.

[0086] A change in defect status refers to a change in the status of a defect report from "not fixed" to "fixed," which can also be considered a triggering event. For example, a developer fixes a defect and updates the status to "fixed." When the triggering event is a change in defect status, defect-related test cases can be used as target test data, and regression tests can be automatically triggered using smart contracts for defect status changes to verify whether the defect has truly been fixed.

[0087] A test node is a node in a blockchain network used to execute test tasks. It is responsible for running test services and generating test results. For example, test node A can be responsible for performing functional tests to verify whether the new code's functionality meets expectations; test node B can be responsible for performing performance tests to verify performance under high load. It should be noted that test nodes used for different test tasks can be the same or different; this is not a limitation.

[0088] According to embodiments of this application, by automatically responding to changes in code repository versions and defect statuses through smart contracts, the testing process can be automated and intelligent, significantly improving testing efficiency and reducing manual intervention. Furthermore, by utilizing test nodes in the blockchain to execute testing tasks, the credibility and immutability of test results are ensured, thereby achieving efficient and reliable test data management, which helps improve software quality and development efficiency.

[0089] According to an embodiment of this application, the blockchain-based information processing method 200 may further include the following operation: in response to the verification information from the verification node satisfying the preset verification conditions, determining that the test result has passed multi-party collaborative verification, wherein the preset verification conditions define at least one of the type of verification node and the number of verification information.

[0090] Verification nodes are nodes that participate in verifying the authenticity and accuracy of test results. There can be one or more nodes, and this is not limited. For example, verification nodes may include at least one of development nodes, testing nodes, and operations nodes. Development nodes are nodes operated by developers to verify code logic and functional implementation. Testing nodes are nodes operated by testers to execute test tasks and verify test results. Operations nodes are nodes operated by operations personnel to verify performance in a real-world operating environment.

[0091] Verification information refers to the feedback information provided by the verification node after verifying the test results. For example, verification information can be a digital signature obtained by the verification node signing the test results using its private key. Predefined verification conditions refer to predefined criteria used to determine whether the verification information meets the requirements. Predefined verification conditions define at least one of the following: the type of verification node and the quantity of verification information. For example, preset verification conditions define that the type of verification node must include development nodes, test nodes, and operation and maintenance nodes; alternatively, preset verification conditions define that verification information from three verification nodes is required.

[0092] According to the embodiments of this application, through a multi-party collaborative verification mechanism and by using the definition of preset verification conditions to flexibly adapt to different verification needs, this automated verification process reduces manual intervention, effectively prevents data tampering and single points of failure, improves the efficiency, reliability and security of the verification process, and ensures the authenticity and credibility of the test results.

[0093] Figure 4 The illustration shows an example diagram of the process for obtaining and verifying test results according to an embodiment of this application.

[0094] like Figure 4 As shown in 400, multiple test services 402 can be predefined for different trigger events 401.

[0095] In response to the detected event 401 indicating a change in the code repository version, the test service 402_1 can be automatically invoked via a smart contract to obtain the target test data 403. For the event 401 indicating a change in the code repository version, taking node 404 in blockchain 104 as an example, node 404 can be used to test the target test data 403, yielding a test result 405 regarding the change in the code repository version.

[0096] In response to the detection of trigger event 401 indicating a change in defect status, the test service 402_2 can be automatically invoked via a smart contract to obtain the target test data 406. For trigger event 401 indicating a change in defect status, taking node 407 in blockchain 104 as an example, node 407 can be used to test the target test data 406, obtaining the test result 408 for the change in defect status.

[0097] After obtaining at least one of the test results 405 (for changes in the code repository version) and 408 (for changes in defect status), operation S410 can be performed. In operation S410, it is determined whether at least one of the test results 405 and 408 meets the preset verification conditions. If yes, it can be determined that at least one of the test results 405 and 408 has passed multi-party collaborative verification 409; if no, it can be determined that at least one of the test results 405 and 408 has failed multi-party collaborative verification 410.

[0098] According to an embodiment of this application, the blockchain-based information processing method 200 may further include the following operations: in response to a change in a user's role type, executing an approval process using a smart contract; and in response to the approval process being passed, storing permission change information in the blockchain, wherein the permission change information includes the changed role type and an effective timestamp.

[0099] A user's role type refers to the level of permissions or scope of responsibilities assigned to the user. In one embodiment, the role type may include at least one of a test role, a development role, and an audit role.

[0100] For example, if a user's role type is "test," the user has the permission to submit test data but not the permission to modify historical data. That is, a user with a test role can submit new test data, but cannot modify historical data already stored in the system.

[0101] Alternatively, if the user's role type is developer, the user has the permission to query defect reports and, with the approval of the auditing role, to update the defect status. That is, a developer user can view defect reports, but requires the auditing role's authorization to update the defect status.

[0102] Alternatively, if the user's role type is audit, the user has permission to read all data and audit operation logs. That is, users with an audit role can view all data in the system and audit operation logs.

[0103] According to the embodiments of this application, by clearly defining role and permission allocation and auditing mechanisms, unauthorized access and operations are effectively prevented, security risks are reduced, security and data integrity are ensured, and the overall credibility and management efficiency of test data are improved.

[0104] When a user's role type changes, a smart contract can be used to automatically execute an approval process for the user's role change request. This approval process can involve multi-party signature approval, with the approval confirmed only when multiple nodes with approval authority jointly sign and confirm. It should be noted that the above approval process can be triggered automatically by the smart contract upon detecting a change in the user's role type, or it can be triggered manually by the user; this is not limited to either method.

[0105] Once the approval process is complete, permission change information can be stored on the blockchain. This information can be used to record detailed information about user role changes, such as the changed role type and effective timestamp. The changed role type refers to the user's new role; for example, if changing from "Testing" to "Development," the applied role type would be "Testing," and the changed role type would be "Development." The effective timestamp indicates the specific time when the role change took effect.

[0106] The specific method for storing permission change information on the blockchain can be configured according to actual business needs and is not limited here. For example, permission change information can be automatically written to the blockchain by a smart contract, manually submitted using a command-line tool, or implemented by calling the interface of a blockchain-as-a-service platform; there are no restrictions here.

[0107] According to embodiments of this application, by utilizing smart contracts to automate the approval process for permission changes, the efficiency and security of permission management are improved. Furthermore, by using blockchain to store permission change information, the transparency and immutability of change records are ensured, enhancing credibility and auditing capabilities, effectively preventing unauthorized permission changes, reducing security risks, simplifying the approval process, and improving user experience.

[0108] According to an embodiment of this application, the blockchain-based information processing method 200 may further include the following operations: performing at least one of integrity verification and operation traceability analysis on the data in the blockchain to obtain an audit result; and visualizing the audit result to obtain an audit result view, wherein the audit result view characterizes whether the audit result is abnormal through a preset display method, and the preset display method includes at least one of color and shape.

[0109] Integrity verification refers to the process of checking whether data has been tampered with or corrupted during storage and transmission. The implementation method of integrity verification can be configured according to actual business needs and is not limited here. For example, integrity verification can be implemented by comparing hash values; that is, the hash value of the data can be calculated and compared with the stored hash value to verify the integrity of the data. Alternatively, integrity verification can be implemented through digital signatures; that is, it can verify whether the data has been signed and whether the signature is valid to ensure that the data has not been tampered with. In one example, integrity verification can also be implemented using the database's checksum mechanism, periodically calculating the checksum of the data and comparing it with the stored checksum.

[0110] In a specific example, taking the hash value of the calculated data as H_local=0x9b2c and the hash value of the stored data as H_chain=0x9b2c as an example, since H_local=H_chain, it can be determined that the data in the blockchain has passed the integrity verification.

[0111] Operation attribution analysis refers to the process of tracing and analyzing the origin of various operations. The implementation method of operation attribution analysis can be configured according to actual business needs and is not limited here. For example, operation attribution analysis can be implemented by analyzing operation logs, that is, by analyzing operation logs, the specific steps a user takes on the blockchain can be traced. Alternatively, operation attribution analysis can be implemented by analyzing transaction records, that is, by analyzing transaction records on the blockchain, the history of data changes can be traced. In one example, operation attribution analysis can also be implemented by using log analysis tools to analyze operation logs.

[0112] According to embodiments of this application, performing at least one of integrity verification and operation tracing analysis on data in the blockchain to obtain an audit result may include the following operations: performing data integrity verification on the data to be verified based on the hash value to be verified and the test hash value in the test result to obtain an integrity verification result; and associating the operator identifier with the operation type based on the timestamp and transaction identifier to generate an operation trajectory in chronological order to obtain an operation tracing analysis result.

[0113] Audit results refer to the conclusions and reports derived from integrity verification and operational source tracing analysis. In one embodiment, audit results may include at least one of integrity verification results and operational source tracing analysis results.

[0114] Data to be verified refers to data that requires integrity verification. Examples include test cases, execution logs, and defect reports. The hash value to be verified is the hash value of the data to be verified, used for integrity verification. The test hash value is the hash value of the test result stored in the blockchain, used to compare with the hash value to be verified. Integrity verification results can be used to confirm whether the data is complete and whether it has been tampered with.

[0115] In one example, the database's checksum mechanism can be used to periodically calculate the checksum of the data and compare it with the stored checksum to obtain the integrity verification result. Alternatively, digital signature technology can be used to verify whether the data has been signed and whether the signature is valid, in order to obtain the integrity verification result.

[0116] A timestamp refers to the specific time an operation occurred. For example, the timestamp of a test case is the time the test case was created or updated; the timestamp of an execution log is the time the execution log was recorded. A transaction identifier is an ID that uniquely identifies a transaction in the blockchain. For example, the transaction identifier of a test case is the transaction ID when the test case data is stored on the blockchain; the transaction identifier of an execution log is the transaction ID when the execution log data is stored on the blockchain. An operator identifier is a unique identifier of the user who performs the operation. Operation types can include submission, query, update, etc. Operation tracing analysis results can be used to display the detailed steps, time, and executor of the operation.

[0117] In one example, log analysis tools can be used to analyze operation logs, correlate operators and operation types, to obtain operation source tracing analysis results. Alternatively, database query language can be used to correlate fields in the operation log table to obtain operation source tracing analysis results.

[0118] In a specific example, the operation trajectory can be represented in the following form:

[0119] 2025-01-01 14:23:05 —> Test user A submitted TC_001 (TxID: 0x3a7f...);

[0120] 2025-01-01 14:25:30 —> Smart contract triggers test execution (TxID: 0x5d8f...);

[0121] 2025-01-01 14:30:15 —> Developer B marked DF_001 as "fixed" (TxID: 0x9b2c...).

[0122] According to the embodiments of this application, integrity verification can quickly confirm whether data has been tampered with by comparing hash values; user operation traceability analysis uses timestamps and transaction identifiers to generate detailed operation trajectories, which facilitates auditing and supervision, and ensures the integrity of data and the traceability of operations.

[0123] After obtaining audit results from at least one of the following: integrity verification and operational traceability analysis of the data in the blockchain, the audit results can be visualized to obtain an audit result view. Visualization refers to presenting the audit results in a graphical or tabular format. The specific form of the audit result view can be configured according to actual business needs and is not limited here. For example, the audit result view can be in the form of a bar chart, line chart, etc., to display data integrity statistics. Alternatively, the audit result view can be in the form of a flowchart, etc., to display operation steps and time sequence.

[0124] The method for generating the audit results view can be configured according to actual business needs and is not limited here. For example, data visualization tools can be used to process the audit results to obtain the audit results view. Alternatively, a customized web application can be used to process the audit results to obtain the audit results view.

[0125] According to embodiments of this application, integrity verification and operational traceability analysis ensure the credibility of data and the compliance of operations within the blockchain. Furthermore, by visually displaying audit results, users can intuitively understand and analyze the integrity of data and the detailed process of operations, enhancing the transparency and credibility of information processing, facilitating auditing and supervision, improving audit efficiency, and reducing the complexity and error rate of manual analysis.

[0126] According to an embodiment of this application, the blockchain-based information processing method 200 may further include the following operation: in response to monitoring data on the blockchain meeting abnormal conditions, outputting early warning information.

[0127] Anomaly conditions define the rules under which the system will trigger an alert. In one embodiment, anomaly conditions may include at least one of the following: inconsistent test results for the same test case, unauthorized requests for access to sensitive data, or a test result timestamp earlier than the test case submission timestamp. An alert is a notification issued when data on the blockchain is detected to meet anomaly conditions.

[0128] In another embodiment, the built-in monitoring tools of the blockchain node can be used to periodically scan the blockchain data to detect whether the data on the blockchain meets any abnormal conditions. Alternatively, third-party monitoring software combined with custom scripts can be used to detect whether the data on the blockchain meets any abnormal conditions.

[0129] According to embodiments of this application, by defining various abnormal conditions, real-time monitoring of blockchain data and timely issuance of early warnings can quickly identify potential risks, enhance the security and reliability of the blockchain, help improve overall robustness, and ensure data integrity and operational compliance.

[0130] Figure 5 The illustration shows an example diagram of a blockchain-based information processing procedure according to an embodiment of this application.

[0131] like Figure 5 As shown in Figure 500, for data 510 in the blockchain, integrity verification can be performed on the data 510 in the blockchain to obtain integrity verification result 521; operation traceability analysis can be performed on the data 510 in the blockchain to obtain operation traceability analysis result 522; at least one of integrity verification result 521 and operation traceability analysis result 522 can be used as audit result 520. After obtaining integrity verification result 521 and operation traceability analysis result 522, audit result 520 can be visualized to obtain audit result view 530.

[0132] In addition, operation S540 can be performed on data 510 in the blockchain. In operation S540, it is determined whether data 510 on the blockchain meets the abnormal conditions. If so, an early warning message 550 can be output; if not, data 510 on the blockchain can be continuously monitored.

[0133] Figure 6 The illustration shows an example diagram of a blockchain-based information processing procedure according to another embodiment of this application.

[0134] like Figure 6 As shown, the information processing process based on blockchain can be implemented using an information processing system 600. In one embodiment, the information processing system 600 may include a data preprocessing layer 610, a blockchain evidence storage layer 620, a smart contract layer 630, and an audit analysis layer 640.

[0135] In the data preprocessing layer 610, the original test data 611 can be standardized according to preset format rules to obtain intermediate test data 612.

[0136] In the blockchain evidence storage layer 620, the hash values ​​of multiple intermediate test data 612 can be divided according to the time window to obtain a hash value set 621 corresponding to each time window; for each hash value set 621, the hash values ​​within the time window are aggregated to obtain the aggregate hash 622 corresponding to each time window; based on the multiple hash values ​​and multiple aggregate hashes 622, candidate test data 623 is obtained.

[0137] In the smart contract layer 630, in response to the detected trigger event 631, the target test data 632 can be obtained from multiple candidate test data 623 stored in the blockchain. Based on the smart contract used to trigger event 631, the target test data 623 is tested to obtain a test result 633. After obtaining the test result 633, it can be signed and notarized 634, and the test result 633, verified through multi-party collaboration, is stored in a chain structure on the blockchain.

[0138] In the audit analysis layer 640, at least one of integrity verification and operation traceability analysis can be performed on the data in the blockchain to obtain audit result 641. The audit result 641 is visualized to obtain audit result view 642, in which the audit result view 642 can be characterized by preset display methods to indicate whether the audit result is abnormal.

[0139] The above are merely exemplary embodiments, but are not limited thereto. Other blockchain-based information processing methods known in the art may also be included, as long as they can achieve automated, reliable processing and storage of test data, as well as reliable management of the entire lifecycle of test data.

[0140] Figure 7 A block diagram of a blockchain-based information processing apparatus according to an embodiment of this application is shown schematically.

[0141] like Figure 7 As shown, the blockchain-based information processing device 700 may include a test module 710 and a first storage module 720.

[0142] The testing module 710 is used to respond to a triggered event, and according to the smart contract used to trigger the event, to test the target test data corresponding to the triggered event obtained from the blockchain, and obtain the test result. The blockchain pre-stores multiple pre-processed candidate test data, each candidate test data having its own timestamp and data type. In one embodiment, the testing module 710 can be used to execute the operation S210 described above, which will not be repeated here.

[0143] The first storage module 720 is used to store the test results in a chain structure to the blockchain in response to the test results being verified by multi-party collaboration, according to the time information corresponding to the test results. In one embodiment, the storage module 720 can be used to perform the operation S220 described above, which will not be repeated here.

[0144] According to an embodiment of this application, candidate test data is obtained by: standardizing the original test data according to a preset format rule to obtain intermediate test data, wherein the preset format rule defines the data format for each data type; and performing hierarchical hash calculation on the intermediate test data to obtain candidate test data.

[0145] According to embodiments of this application, the data types include at least one of the following: test cases, execution logs, and defect reports; when the original data to be tested is a test case, the data format includes input parameters, expected output, and execution conditions; when the original data to be tested is an execution log, the data format includes test steps, actual output, and images or videos; when the original data to be tested is a defect report, the data format includes defect description, severity level, and repair status.

[0146] According to embodiments of this disclosure, performing hierarchical hash calculation on intermediate test data to obtain candidate test data includes: dividing the hash values ​​of multiple intermediate test data according to time windows to obtain a set of hash values ​​corresponding to each time window; aggregating the hash values ​​within each time window for each hash value set to obtain an aggregated hash corresponding to each time window; and obtaining candidate test data based on multiple hash values ​​and multiple aggregated hashes.

[0147] According to embodiments of this disclosure, the test module 710 may include a first calling unit, a second calling unit, and a test unit.

[0148] The first invocation unit is used to automatically invoke the test service via a smart contract to obtain the target test data in response to a trigger event indicating a change in the code repository version. Alternatively, the second invocation unit is used to automatically invoke the test service via a smart contract to generate the target test data in response to a trigger event indicating a change in the defect status.

[0149] The test unit is used to test the target test data using test nodes in the blockchain and obtain test results.

[0150] According to embodiments of this application, the blockchain-based information processing device 700 may further include a determining module.

[0151] The determination module is used to determine the test result through multi-party collaborative verification in response to the verification information from the verification node satisfying the preset verification conditions. The preset verification conditions define at least one of the types of verification nodes and the number of verification information.

[0152] According to an embodiment of this application, the blockchain-based information processing device 700 may further include an execution module and a second storage module.

[0153] The execution module is used to execute the approval process using smart contracts in response to changes in the user's role type.

[0154] The second storage module is used to store permission change information to the blockchain in response to the approval process. The permission change information includes the changed role type and the effective timestamp.

[0155] According to embodiments of this application, the role type includes at least one of the following: test role, development role, and review role; the test role has the permission to submit test data but does not have the permission to modify historical data; the development role has the permission to query defect reports and, with the authorization of the review role, the permission to update the defect status; the review role has the permission to read all data and the permission to review operation logs.

[0156] According to embodiments of this application, the blockchain-based information processing device 700 may further include an acquisition module and a visualization module.

[0157] The module is used to perform at least one of the following: integrity verification and operational traceability analysis on the data in the blockchain, to obtain the audit results.

[0158] The visualization module is used to visualize the review results and obtain the review result view. The review result view uses a preset display method to indicate whether the review result is abnormal. The preset display method includes at least one of color and shape.

[0159] According to an embodiment of this application, the audit result includes at least one of the integrity verification result and the operation traceability analysis result; the obtaining module may include a first obtaining unit and a second obtaining unit.

[0160] The first obtaining unit is used to perform data integrity verification on the data to be verified based on the hash value to be verified of the data to be verified and the test hash value in the test result, and obtain the integrity verification result.

[0161] The second acquisition unit is used to associate the operator identifier with the operation type based on the timestamp and transaction identifier, so as to generate the operation trajectory in chronological order and obtain the operation traceability analysis results.

[0162] According to embodiments of this application, the blockchain-based information processing device 700 may further include an output module.

[0163] The output module is used to output alert information in response to monitored data on the blockchain meeting abnormal conditions. Abnormal conditions include at least one of the following: inconsistent test results for the same test case, unauthorized role requests to operate on sensitive data, and the timestamp of the test result being earlier than the timestamp of the test case submission.

[0164] Any one or more of the modules, submodules, units, and subunits according to the embodiments of this application, or at least part of the functions of any one or more of them, can be implemented in one module. Any one or more of the modules, submodules, units, and subunits according to the embodiments of this application can be implemented by dividing them into multiple modules. Any one or more of the modules, submodules, units, and subunits according to the embodiments of this application can be at least partially implemented as hardware circuits, such as field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits (ASICs), or implemented by hardware or firmware in any other reasonable manner by integrating or packaging circuits, or implemented in any one of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, one or more of the modules, submodules, units, and subunits according to the embodiments of this application can be at least partially implemented as computer program modules, which, when run, can perform corresponding functions.

[0165] For example, any plurality of test modules 710 and the first storage module 720 can be combined into one module / unit / subunit, or any one of these modules / units / subunits can be split into multiple modules / units / subunits. Alternatively, at least part of the functionality of one or more of these modules / units / subunits can be combined with at least part of the functionality of other modules / units / subunits and implemented in one module / unit / subunit. According to embodiments of this application, at least one of test module 710 and the first storage module 720 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of test module 710 and the first storage module 720 can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0166] It should be noted that the information processing device part based on blockchain in the embodiments of this application corresponds to the information processing method part based on blockchain in the embodiments of this application. For a detailed description of the information processing device part based on blockchain, please refer to the information processing method part based on blockchain, which will not be repeated here.

[0167] Figure 8 A block diagram of an electronic device suitable for implementing a blockchain-based information processing method according to an embodiment of the present disclosure is shown schematically. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0168] like Figure 8 As shown, a computer electronic device 800 according to an embodiment of the present disclosure includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage portion 809 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0169] RAM 803 stores various programs and data required for the operation of electronic device 800. Processor 801, ROM 802, and RAM 803 are interconnected via bus 804.

[0170] According to embodiments of this disclosure, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the input / output (I / O) interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output (I / O) interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0171] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the blockchain-based information processing method according to the embodiments of this disclosure.

[0172] In this disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0173] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods provided in the embodiments of this disclosure. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the blockchain-based information processing method provided in the embodiments of this disclosure.

[0174] When the computer program is executed by the processor 801, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0175] According to embodiments of this disclosure, program code for executing computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages.

[0176] 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 this disclosure. It should also be noted that in some alternative implementations, the functions indicated in the boxes may occur in a different order than those shown in the drawings.

[0177] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A blockchain-based information processing method, comprising: In response to a detected trigger event, the target test data corresponding to the trigger event, obtained from the blockchain, is tested according to the smart contract for the trigger event to obtain test results. The blockchain pre-stores multiple pre-processed candidate test data sets, each with its own timestamp and data type. In response to the test results being verified through multi-party collaboration, the test results are stored in a chain structure on the blockchain according to the time information corresponding to the test results.

2. The method according to claim 1, wherein, The candidate test data was obtained in the following way: According to preset format rules, the original test data is standardized to obtain intermediate test data, wherein the preset format rules define the data format for each of the data types; and The intermediate test data is subjected to hierarchical hash calculation to obtain the candidate test data.

3. The method according to claim 2, wherein, The data types include at least one of the following: test cases, execution logs, and defect reports; When the original data to be tested belongs to a test case, the data format includes input parameters, expected output, and execution conditions; when the original data to be tested belongs to an execution log, the data format includes test steps, actual output, and images or videos; when the original data to be tested belongs to a defect report, the data format includes defect description, severity level, and repair status.

4. The method according to claim 2, wherein, The step of performing hierarchical hash calculation on the intermediate test data to obtain the candidate test data includes: Based on the time window, the hash values ​​of the multiple intermediate test data are divided to obtain a set of hash values ​​corresponding to each time window. For each set of hash values, the hash values ​​within the time window are aggregated to obtain the aggregated hash corresponding to each time window; and The candidate test data is obtained based on the multiple hash values ​​and the multiple aggregate hashes.

5. The method according to any one of claims 1 to 4, wherein, In response to a detected trigger event, the system performs tests on the target test data corresponding to the trigger event, obtained from the blockchain, based on the smart contract used for the trigger event, and obtains test results including: In response to the detection of a code repository version change as the triggering event, the smart contract automatically invokes a testing service to obtain the target test data; or in response to the detection of a defect status change as the triggering event, the smart contract automatically invokes a testing service to generate the target test data; and The target test data is tested using the test nodes in the blockchain to obtain the test results.

6. The method according to any one of claims 1 to 4, further comprising, after testing the target test data corresponding to the triggering event obtained from the blockchain according to the smart contract for the triggering event, and obtaining the test result: In response to the verification information from the verification node satisfying the preset verification conditions, it is determined that the test result has passed multi-party collaborative verification, wherein, The preset verification conditions define at least one of the type of the verification node and the quantity of the verification information.

7. The method according to any one of claims 1 to 4, further comprising: In response to changes in a user's role type, the approval process is executed using smart contracts; as well as In response to the approval process being completed, the permission change information is stored in the blockchain, wherein the permission change information includes the changed role type and the effective timestamp.

8. The method according to claim 7, wherein, The role types include at least one of the following: test role, development role, and review role; The test role has the permission to submit test data but does not have the permission to modify historical data. The development role has the authority to query defect reports and, with the authorization of the review role, to update the defect status. The auditing role has the permission to read all data and the permission to audit operation logs.

9. The method according to any one of claims 1 to 4, further comprising, after storing the test result to the blockchain according to the time information corresponding to the test result: Perform at least one of the following on the data in the blockchain: integrity verification and operational traceability analysis, to obtain the audit result; and The audit results are visualized to obtain an audit result view, wherein... The review result view uses a preset display method to indicate whether the review result is abnormal. The preset display method includes at least one of color and shape.

10. The method according to claim 9, wherein, The audit results include at least one of the integrity verification results and the operational traceability analysis results; The audit result obtained by performing at least one of the following on the data in the blockchain: integrity verification and operation tracing analysis: Based on the unverified hash value of the data to be verified and the test hash value in the test result, data integrity verification is performed on the data to be verified to obtain the integrity verification result; and Based on the timestamp and transaction identifier, the operator identifier and operation type are associated to generate an operation trajectory in chronological order, thereby obtaining the operation tracing analysis results.

11. The method according to any one of claims 1 to 4, further comprising, after storing the test result to the blockchain according to the time information corresponding to the test result: In response to the monitoring of data on the blockchain meeting abnormal conditions, an early warning message is output; in, The abnormal conditions include at least one of the following: inconsistent test results for the same test case, unauthorized role requesting operation on sensitive data, and the timestamp of the test result being earlier than the timestamp of the test case submission.

12. A blockchain-based information processing device, comprising: A testing module, in response to a detected trigger event, tests target test data corresponding to the trigger event, retrieved from the blockchain, according to a smart contract for the trigger event, to obtain test results. The blockchain pre-stores multiple pre-processed candidate test data sets, each with its own timestamp and data type. The first storage module is used to store the test results in a chain structure to the blockchain in response to the test results being verified by multiple parties, according to the time information corresponding to the test results.

13. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 11.

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

15. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 11.

Images