Quality detection management method and system for digital currency system development

Abstract

The embodiment of the invention provides a quality detection management method and system for digital currency system development. The method comprises the following steps: receiving a quality detection request of to-be-detected software in a digital currency system development process, and determining an institution level to which the to-be-detected software belongs according to the quality detection request; determining a quality detection process required to be executed for the to-be-detected software according to the mechanism level to which the to-be-detected software belongs; according to the detection sequence of all the quality detection nodes of the quality detection process, corresponding quality detection operation is executed on the to-be-detected software, the quality detection process comprises a plurality of quality detection nodes, and all the quality detection nodes automatically trigger the to-be-detected software to execute the corresponding detection operation according to the detection sequence when the preset condition is met. The research and development requirements of a complex system architecture can be met, the quality detection nodes in the quality detection process can be automatically triggered and started, the automation degree is high, and therefore the research and development detection efficiency and quality are improved.

Description

Technical Field

[0001] Embodiments of this disclosure relate to a quality inspection and management method and system for the development of digital currency systems. Background Technology

[0002] In traditional application system development, quality is improved by performing quality checks and management on the software code. However, typical application system architectures are relatively simple, usually single-layered. For complex architectures like digital currency systems, traditional solutions are insufficient to meet the development needs of digital currency systems and cannot efficiently achieve quality control during the development process. Summary of the Invention

[0003] At least one embodiment of this disclosure provides a quality inspection management method for the development of a digital currency system. The method includes: receiving a quality inspection request for software under test during the development of the digital currency system; determining the organizational level to which the software under test belongs based on the quality inspection request; determining the quality inspection process to be executed for the software under test based on the organizational level to which the software under test belongs; and performing corresponding quality inspection operations on the software under test according to the inspection sequence of each quality inspection node in the quality inspection process. The quality inspection process includes multiple quality inspection nodes, and each quality inspection node automatically triggers to perform corresponding inspection operations on the software under test according to the inspection sequence under preset conditions.

[0004] For example, according to at least one embodiment of the quality inspection management method of this disclosure, the step of determining the quality inspection process to be performed for the software under test based on the organizational level to which the software under test belongs includes: in response to the organization to which the software under test belongs being a first-level organization, executing a first software quality inspection process, the first software quality inspection process including the following quality inspection nodes: static code scanning, unit testing, code security scanning, artifact scanning, and automated testing; in response to the organization to which the software under test belongs being a second-level organization, executing a second software quality inspection process, the second software quality inspection process including automated testing.

[0005] For example, according to at least one embodiment of the quality inspection management method of this disclosure, the method further includes: providing a unit test scheduling engine and a plurality of unit test execution modules scheduled by the engine, each unit test execution module being configured with a compilation environment supporting different development languages; further, the step of executing unit tests includes: starting the control unit test scheduling engine to determine the unit test task and compilation environment of the software under test according to the unit test request; the unit test scheduling engine dispatching the unit test task to the unit test execution module corresponding to the compilation environment to execute the unit test task.

[0006] For example, according to at least one embodiment of the quality inspection management method of this disclosure, the method further includes: when the unit test scheduling engine fails to find a unit test execution module corresponding to the development language of the software under test, adding a unit test execution module that supports the compilation environment of the development language and incorporating it into the scheduling management of the unit test scheduling engine.

[0007] For example, according to at least one embodiment of the quality inspection management method of this disclosure, the unit test scheduling engine adjusts the participation of each unit test execution module in the unit test task based on the unit test task and the processing capacity of each unit test execution module in its scheduling management.

[0008] For example, according to at least one embodiment of the quality inspection management method of this disclosure, the method further includes: during the execution of static code scanning and unit testing, monitoring the execution time and determining whether the execution time exceeds a set time; if it is determined that the execution time exceeds the set time, re-executing the static code scanning or unit testing.

[0009] For example, according to at least one embodiment of the quality inspection management method of this disclosure, the method further includes: formatting the scan result obtained from the most recent static code scanning and the execution result of the unit test; determining whether the formatting result meets the quality control threshold, and if the determination meets the threshold, triggering the next quality inspection node.

[0010] At least one embodiment of this disclosure provides a quality inspection and management system for the development of a digital currency system, comprising: an institutional level determination module configured to receive a quality inspection request for software under test during the development of the digital currency system, and determine the institutional level to which the software under test belongs based on the quality inspection request; and a inspection process management module configured to determine the quality inspection process to be executed for the software under test based on the institutional level to which the software under test belongs; and to perform corresponding quality inspection operations on the software under test according to the inspection sequence of each quality inspection node in the quality inspection process, wherein the quality inspection process includes multiple quality inspection nodes, and each quality inspection node automatically triggers to execute corresponding inspection operations on the software under test according to the inspection sequence under preset conditions.

[0011] For example, in a quality inspection management system according to at least one embodiment of the present disclosure, the inspection process management module is further configured to: execute a first software quality inspection process in response to the organization to which the software under test belongs being a first-level organization, the first software quality inspection process including the following quality inspection nodes: static code scanning, unit testing, code security scanning, artifact scanning and automated testing; and execute a second software quality inspection process in response to the organization to which the software under test belongs being a second-level organization, the second software quality inspection process including automated testing.

[0012] For example, according to at least one embodiment of the quality inspection management system of this disclosure, the system further includes: a unit test scheduling engine and a plurality of unit test execution modules scheduled by the engine, each unit test execution module being configured with a compilation environment supporting different development languages; a test process management module, which is further configured to control the start of the unit test scheduling engine; and a unit test scheduling engine, which is configured to determine the unit test task and compilation environment of the software under test according to the unit test request, and to distribute the unit test task to the unit test execution module corresponding to the compilation environment for execution of the unit test task.

[0013] For example, in a quality inspection management system according to at least one embodiment of the present disclosure, the unit test scheduling engine is further configured to add a unit test execution module that supports the compilation environment of the development language and include it in the scheduling management of the unit test scheduling engine if no unit test execution module corresponding to the development language of the software under test is found.

[0014] For example, in a quality inspection management system according to at least one embodiment of the present disclosure, the unit test scheduling engine is further configured to adjust the participation of each unit test execution module in the unit test task based on the unit test task and the processing capacity of each unit test execution module in its scheduling management.

[0015] For example, according to at least one embodiment of the quality inspection management system of this disclosure, the system further includes: a bypass anomaly detection module, configured to start during the execution of static code scanning and unit testing to monitor the execution time and determine whether the execution time exceeds a set time; if the execution time exceeds the set time, re-execute the static code scanning or unit testing.

[0016] At least one embodiment of this disclosure provides an electronic device, including: one or more processors; and a memory storing one or more computer program modules; wherein the one or more computer program modules are configured to be executed by the one or more processors to implement a method provided according to at least one embodiment of this disclosure.

[0017] At least one embodiment of this disclosure provides a computer-readable medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by one or more processors, implement a method according to at least one embodiment of this disclosure.

[0018] The quality inspection management scheme of this disclosure is designed for the characteristics of digital currency system development. It calls different quality inspection processes for different institutional levels, thereby meeting the R&D needs of complex system architecture. Moreover, each quality inspection node in the quality inspection process can be automatically triggered and started, with a high degree of automation, thus improving the efficiency and quality of R&D inspection. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Clearly, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit the scope of this disclosure.

[0020] Figure 1 A schematic diagram of an exemplary environment for a quality inspection and management system for the development of a digital currency system, according to at least one embodiment of the present disclosure, is shown.

[0021] Figure 2 A block diagram of a quality inspection management system according to at least one embodiment of the present disclosure is shown;

[0022] Figure 3 A flowchart illustrating a quality inspection and management method for developing a digital currency system according to at least one embodiment of the present disclosure is shown.

[0023] Figure 4 A schematic diagram of a quality inspection management method according to an embodiment of the present disclosure is shown;

[0024] Figure 5A , Figure 5B , Figure 5C , Figure 5D , Figure 5E The flowcharts of different quality inspection nodes in a quality inspection management process according to an example of an embodiment of the present disclosure are shown respectively.

[0025] Figure 6 A schematic diagram of an electronic device according to at least one embodiment of the present disclosure is shown;

[0026] Figure 7 A schematic diagram of a computer-readable medium according to at least one embodiment of the present disclosure is shown. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0028] Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms “first,” “second,” and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, terms such as “comprising” or “including” mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as “connected” or “linked” are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as “upper,” “lower,” “left,” and “right” are used only to indicate relative positional relationships, which may change accordingly when the absolute position of the described objects changes.

[0029] Note that the examples described below are merely specific examples and are not intended to limit the embodiments of this disclosure to the specific shapes, hardware, connections, operations, values, conditions, data, sequences, etc., shown and described. Those skilled in the art can utilize the concepts of this disclosure to construct further embodiments not mentioned herein by reading this specification.

[0030] The terminology used in this disclosure is that which is currently widely used in the art in consideration of the functionality of this disclosure; however, these terms may vary depending on the intent, precedent, or new technology of those skilled in the art. Furthermore, specific terms may be chosen by the applicant, and in such cases, their detailed meanings will be described in the detailed description of this disclosure. Therefore, the terminology used in this specification should not be construed as simple names, but rather based on the meaning of the terms and the overall description of this disclosure.

[0031] This disclosure uses flowcharts to illustrate the operations performed by a system according to embodiments of this disclosure. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously, as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0032] As described in the background section, traditional solutions are mainly designed for software testing and management of application systems with simple system architectures. They are not suitable for digital currency systems with complex system architectures. Moreover, during the software quality testing process, the testing methods are distributed across different tools or platforms, and the test results are also scattered across various tools or platforms. This requires developers to log into different systems to view the results, which significantly reduces work efficiency.

[0033] Based on the above, at least one embodiment of this disclosure provides a quality inspection and management scheme for digital currency system development. Compared with traditional schemes, this scheme achieves centralized inspection and management of software code under development for digital currency systems with diverse system architectures by conducting hierarchical testing of software code belonging to different institutional levels. This meets the quality management requirements under complex system architectures, thereby improving R&D efficiency and reducing management costs. Furthermore, by embedding quality inspection methods (nodes) into the R&D implementation process, it avoids frequent switching between multiple quality inspection and management systems by developers, achieving automatic quality inspection during the R&D process. This avoids oversights that may be caused by manual triggering of inspections, further improving R&D quality and efficiency.

[0034] Figure 1 A schematic diagram of an exemplary environment for a quality inspection and management system for the development of a digital currency system, according to at least one embodiment of the present disclosure, is shown. The digital currency system in this embodiment adopts a two-tier architecture, such as... Figure 1 As shown, the system architecture 10 of the digital currency system includes a first-tier institution 101 (e.g., a central bank) and multiple second-tier institutions (operating institutions designated by the central bank, such as commercial banks) 102A, 102B, 102C, etc. During the development of the digital currency system, these two layers of institutions develop different application systems, generating a large amount of software code, such as software code C1 generated by first-tier institution 101 and software code C2 generated by second-tier institution 102A. When performing quality checks on this code, traditional methods require developers to frequently switch between multiple quality check and management systems, and each quality check node requires manual triggering, leading to omissions of some quality check nodes and low detection efficiency. The quality check management system 100 of this embodiment can complete the corresponding quality check process according to the hierarchical institution to which the code under test belongs, meeting the quality management requirements under the two-tier architecture of the digital currency system and achieving automated detection. Furthermore, the system 100 can also achieve parallel processing of multiple software programs under test, improving detection efficiency.

[0035] Figure 1The quality inspection management system 100 shown can communicate operationally with the computer systems of the first-level organization 101 and the second-level organization 102 via any suitable communication channel or network. Suitable communication networks can be any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.), etc. System 100 receives quality inspection requests from different levels of organizations (systems) via the aforementioned communication network, performs quality inspection on the software under test according to the content of the quality inspection request, and displays the inspection results in various graphical forms (e.g., Figure 1 The results are shown in the diagram (table), which is provided for R&D personnel to refer to and process.

[0036] Figure 2 A block diagram of a quality inspection management system 100 according to at least one embodiment of the present disclosure is shown. Figure 2 As shown, the quality inspection and management system 100 includes a static code scanning module 110, a unit testing module 120, a code security scanning module 130, a product scanning module 140, an automated testing module 150, an organizational level judgment module 170, and an inspection process management module 180.

[0037] For example, in at least one embodiment of this disclosure, the organizational level determination module 170 is configured to receive a quality inspection request for the software under test during the development of the digital currency system, and determine the organizational level to which the software under test belongs based on the quality inspection request.

[0038] For example, the development process includes multiple phases, such as the coding phase, the test submission phase, the testing phase, and the production phase. For a complete software quality inspection process, quality inspection requests are typically received during the coding phase or the test submission phase. These quality inspection requests can include requests from different quality inspection nodes, such as code merging requests (in the coding phase) and unit test requests (in the test submission phase). The requests can include information about the requesting organization, code information, and the type of quality inspection. The organizational level is identified by parsing the request's organizational information, such as a single-level or two-level organization, and then the corresponding quality inspection process is controlled. Of course, quality inspection requests may also be received at other stages; this disclosure does not specifically limit the specific stages.

[0039] For example, the organization level determination module 170 can determine the organization level to which the software under test belongs based on the organization identifier or address identifier in the quality inspection request, and then transmit the determination result to the inspection process management module 180.

[0040] Here, "Organization Identifier" refers to the identifier of the organization to which the code under test belongs. For example, the organization identifier could be a unique identifier for the central bank or operating institution that submitted the code to system 100. In some examples, the organization identifier can indicate a specific node (computer system node) associated with the organization and may include alphanumeric characters, special characters, and any other suitable symbols. "Address Identifier" can also represent the identifier of the address of the organization to which the code under test belongs in the network. For example, the address identifier could represent an operating institution or central bank in the network. In some examples, the address identifier may include a string of characters, such as letters, numbers, etc. For example, the address identifier could be a string of 5, 10, 15, or any other suitable number of characters.

[0041] For example, the testing process management module 180 mainly controls the operation of different quality testing processes based on the judgment results of the organization level, and serves as the main body for controlling and managing other modules (mainly the related modules of each quality testing node).

[0042] For example, in at least one embodiment of this disclosure, the testing process management module 180 is configured to determine the quality testing process to be executed for the software under test based on the organizational level to which the software under test belongs (e.g., the identifier of the organizational level); and to perform corresponding quality testing operations on the software under test according to the testing order of each quality testing node in the quality testing process. The quality testing process includes multiple quality testing nodes, and each quality testing node automatically triggers the execution of corresponding testing operations on the software under test according to the testing order under preset conditions. Figure 2 As shown, the static code scanning module 110, unit testing module 120, code security scanning module 130, artifact scanning module 140, and automated testing module 150 respectively implement the functions of quality inspection nodes such as static code scanning, unit testing, code security scanning, artifact scanning, and automated testing. They are controlled and invoked by the inspection process management module 180, and their specific functions are described later. For example, preset conditions may include the completion of the previous quality inspection node, the execution result meeting the set standards, and the receipt of certain requests.

[0043] In traditional R&D processes, static code scanning and unit testing are typically performed using different tools / platforms, with scan results scattered across various tools, requiring developers to log into different systems to view them. This disclosure provides a centralized static code scanning and unit test management platform. Through system-level integration, scan / test results are recorded on a unified platform, providing developers with a centralized query and display page. This avoids the need for developers, quality managers, testers, and R&D managers to switch between different platforms. Furthermore, the centralized display of various scan / test results effectively improves work efficiency.

[0044] In the entire quality inspection and management process, upon receiving a code merging request, the inspection process management module 180 can (based on the code's hierarchical structure) trigger the static code scanning module 110 to start and execute static code scanning and record the scan results. Upon receiving a unit test request, the inspection process management module 180 can (based on the code's hierarchical structure) trigger the unit test module 120 to complete unit tests and record the results. After the unit tests are completed, it is determined whether the static code scanning results and unit test results meet the quality management requirements. If they meet the quality management requirements, the inspection process management module 180 triggers the code security scanning module. 130 initiates code security scanning; upon receiving notification of code security scan completion, the inspection process management module 180 triggers the product scanning module 140 to start, performing integration operations of the application system (composed of code) to form a product and perform product scanning; upon receiving notification of product scanning completion, the inspection process management module 180 deploys the application system, and after completing the deployment, triggers the automated testing module 150 to perform automated testing; upon receiving a production application, the inspection process management module 180 automatically obtains the test report and product scanning results to provide data support for production review personnel.

[0045] In at least one embodiment of this disclosure, the testing process management module 180 is further configured to execute a first software quality testing process in response to the organization to which the software under test belongs being a first-level organization, wherein the first software quality testing process includes the following quality testing nodes: static code scanning, unit testing, code security scanning, artifact scanning, and automated testing; and to execute a second software quality testing process in response to the organization to which the software under test belongs being a second-level organization, wherein the second software quality testing process includes automated testing, such as performing automated testing and manual testing.

[0046] Thus, in the embodiments of this disclosure, the organizational hierarchy is pre-determined by the organizational hierarchy judgment module 170, and then the detection process management module 180 controls the execution of different software quality detection processes, meeting the quality detection requirements for the diverse system architecture of the digital currency system. Moreover, different quality detection processes are executed for the code of different organizations, and the hierarchical detection helps to improve work efficiency.

[0047] Furthermore, unit test execution is closely related to the compilation environment. Different programming languages ​​require different compilation environment settings. When the application system architecture is complex (e.g., involving multiple programming languages), multiple unit test systems are needed to adapt to different programming languages. Thus, during unit testing, software code in various programming languages ​​needs to be distributed across different unit test systems for processing, and test results are also stored separately in each unit test system. For large-scale microservice architecture applications involving numerous microservices, the processing capacity requirements for unit tests become very high, easily leading to queuing and waiting issues. To solve the above problems, embodiments of this disclosure provide a new unit testing scheme that uses centralized scheduling and distributed execution to achieve unit testing of a digital currency system with diverse programming languages.

[0048] For example, in at least one embodiment of this disclosure, the unit test module 120 includes a unit test scheduling engine and multiple unit test execution modules (unit test execution containers in the figure) that it schedules. Each unit test execution module is configured with a compilation environment that supports different programming languages ​​to execute unit test tasks. For example, unit test execution containers that support compilation environments such as Java, C, C++, and C#. When configuring unit test execution modules, multiple unit test execution containers can be set for the same programming language. In one example, one Java unit test execution container and n C unit test execution containers can be set.

[0049] like Figure 2 As shown, the unit test module 120 includes a unit test scheduling engine 120A and multiple unit test execution containers 120B1...120Bn. The scheduling engine 120A is responsible for receiving, scheduling, and issuing unit test tasks and receiving unit test results from each execution container 120Bn. Multiple execution containers 120Bn can be deployed and different environment parameters can be set according to the needs of the application system. The execution containers 120Bn and the scheduling engine 120A receive and execute unit test tasks, and the execution results are sent to the scheduling engine 120A.

[0050] For example, the unit test scheduling engine 120A maintains a service scan plan table. This table includes information about multiple unit test execution containers, such as the compilation environment parameters configured for each container and its ID. Administrators can add, modify, and delete unit test execution containers within the project table to dynamically maintain software testing requirements for diverse programming languages.

[0051] Upon receiving a unit test request, the testing process management module 180 activates the unit test scheduling engine 120A. The unit test scheduling engine 120A determines the unit test tasks and compilation environment for the software under test based on the unit test request. The unit test scheduling engine 120A then distributes the unit test tasks to the unit test execution modules 120Bn corresponding to the compilation environment for execution. Specifically, the unit test request may include information such as the codebase and branches of the software under test. The unit test scheduling engine 120A queries the unit test tasks and compilation environment based on the codebase information, then finds the appropriate unit test execution container in the global scheduling project table and sends the unit test tasks to that execution container. After each unit test execution container completes its test task, the test results are stored in a unified database (not shown) for the system to retrieve and access.

[0052] Thus, the solution of this disclosure can adapt to the unit testing function of digital currency systems with diverse development languages, and centrally summarizes the test results into a unified database, thereby improving testing efficiency and convenience.

[0053] For example, in at least one embodiment of this disclosure, the unit test scheduling engine 120A adjusts the participation of each unit test execution module 120Bn in the unit test task based on the unit test task and the processing capacity of each unit test execution module 120Bn in its scheduling management. For example, the unit test scheduling engine 120A monitors the running status of each unit test execution module 120Bn in real time and records each running status in a project table. By analyzing the running status of each execution module, the unit test task is sent to an idle execution module for processing.

[0054] For example, if the unit test scheduling engine 120A determines that all execution modules for a certain type of programming language are running, and there are too many unit test tasks requiring queuing, the unit test scheduling engine 120A can horizontally scale up to increase the number of execution modules for that type of programming language. For instance, it can add a new execution module for that type of programming language, add configuration information to the service scan plan table maintained by the unit test scheduling engine 120A, and then the unit test scheduling engine 120A can schedule the newly added execution module to execute unit test jobs. Furthermore, if the unit test scheduling engine 120A monitors that an execution module has completed its assigned unit test tasks, it will release it to prevent resources from being occupied for a long time and update the running status of that execution module in the service scan plan table.

[0055] For example, in at least one embodiment of this disclosure, if the unit test scheduling engine 120A fails to find a unit test execution module corresponding to the development language of the software under test, it adds a unit test execution module that supports the compilation environment of that development language and incorporates it into the scheduling management of the unit test scheduling engine. Specifically, first, a unit test execution module corresponding to the compilation environment of that development language is added, and then the configuration information of the new unit test execution module is added to the aforementioned service scanning scheme table. Later, the unit test execution module is scheduled based on this configuration information.

[0056] The unit test scheduling engine can promptly add corresponding unit test execution modules when a new development language compilation environment is needed, without the need for repeated framework development. It can effectively support the unit test requirements of diverse development languages ​​and enable the configuration of compilation environment parameters.

[0057] For example, in at least one embodiment of this disclosure, such as Figure 2 As shown, the quality inspection management system 100 also provides a bypass anomaly detection module 160. The bypass anomaly detection module 160 is configured to monitor the execution time during static code scanning and unit testing, and determine whether the execution time exceeds a set time (set based on experience, such as 3 hours). If the execution time exceeds the set time, the inspection process management module 180 re-executes the static code scanning or unit testing. By setting the bypass anomaly detection module, the problem of scanning "freezing" can be effectively avoided, and "failed" quality inspection tasks can be re-initiated.

[0058] For example, in at least one embodiment of this disclosure, the scan results obtained from the most recent static code scanning and the execution results of the unit tests are formatted; it is then determined whether the formatted results meet the quality control thresholds. If they do, the next quality inspection node is triggered. By centralizing the processing of static code scanning results and unit test results at the system level, developers and quality management personnel avoid switching between different platforms. Furthermore, if, after the aforementioned comprehensive and centralized assessment, it is found that both the static code scanning results and the unit test execution results meet their respective quality control threshold requirements, the next quality inspection node can be triggered, proceeding to subsequent quality inspection stages, thus effectively improving work efficiency.

[0059] Figure 3 A flowchart illustrating a quality inspection management method 300 for digital currency system development according to at least one embodiment of the present disclosure is shown. Reference is made below. Figure 3 This will explain each step of the method.

[0060] In step S301, a quality inspection request for the software under test during the development of the digital currency system is received, and the organizational level to which the software under test belongs is determined based on the quality inspection request.

[0061] In step S303, the quality inspection process required for the software under test is determined based on the organizational level to which the software under test belongs;

[0062] In step S305, the corresponding quality inspection operations are performed on the software under test according to the inspection sequence of each quality inspection node in the quality inspection process. The quality inspection process includes multiple quality inspection nodes, and each quality inspection node automatically triggers the execution of the corresponding inspection operation on the software under test under preset conditions.

[0063] In step S303, the steps for determining the required quality inspection process based on the organizational level of the software under test include: in response to the software under test belonging to a first-level organization, executing a first software quality inspection process, which includes the following quality inspection nodes: static code scanning, unit testing, code security scanning, artifact scanning, and automated testing; in response to the software under test belonging to a second-level organization, executing a second software quality inspection process, which includes quality inspection nodes for automated testing, such as executing automated testing and manual testing.

[0064] For example, in some embodiments of this disclosure, it further includes: providing a unit test scheduling engine and a plurality of unit test execution modules scheduled by the engine, each unit test execution module being configured with a compilation environment that supports different development languages; further, the step of executing unit tests includes: starting the control unit test scheduling engine to determine the unit test tasks and compilation environment of the software under test; the unit test scheduling engine dispatching the unit test tasks to the unit test execution modules corresponding to the compilation environment to execute the unit test tasks.

[0065] For example, in some embodiments of this disclosure, the method further includes: if the unit test scheduling engine fails to find a unit test execution module corresponding to the development language of the software under test, it adds a unit test execution module that supports the compilation environment of the development language and incorporates it into the scheduling management of the unit test scheduling engine.

[0066] For example, in some embodiments of this disclosure, the unit test scheduling engine adjusts the participation of each unit test execution module in the unit test task based on the unit test task and the processing capacity of each unit test execution module in its scheduling management.

[0067] For example, in some embodiments of this disclosure, the method further includes: monitoring the execution time during the static code scanning and unit testing process, and determining whether the execution time exceeds a set time; if the execution time exceeds the set time, re-executing the static code scanning or unit testing.

[0068] For example, in some embodiments of this disclosure, the method further includes: formatting the scan results obtained from the most recent static code scan and the execution results of the unit test; determining whether the formatting result meets the quality control threshold, and if it does, triggering the next quality inspection node.

[0069] The additional aspects of the quality inspection and management method 300 for digital currency system development according to at least one embodiment of the present disclosure can correspond to the additional aspects of the quality inspection and management system 100 for digital currency system development according to at least one embodiment of the present disclosure. Therefore, the technical effects of the additional aspects of the method 300 according to at least one embodiment of the present disclosure can also be mapped to the additional aspects of the system 100 according to at least one embodiment of the present disclosure, which will not be repeated here.

[0070] Figure 4 A schematic diagram of an example quality inspection management method according to an embodiment of the present disclosure is shown. Figure 4 As shown, this quality inspection and management method is designed for the two-tier architecture of a digital currency system, involving a first software inspection process and a second software inspection process. Figure 5A , Figure 5B , Figure 5C , Figure 5D , Figure 5E The following are flowcharts illustrating different quality inspection nodes in an example of a quality inspection management process according to an embodiment of the present disclosure. These quality inspection nodes include: static code scanning (S410), unit testing (S420), quality inspection (S430), code security scanning (S440), artifact scanning (S450), and automated testing (S460). The testing steps for software code submitted by various levels of organizations are described in detail below.

[0071] When R&D personnel initiate a request to submit software for testing, System 100 initiates the corresponding quality inspection process based on the organization (first-tier or second-tier) to which the software code testing applicant belongs. Although... Figure 4 As shown, the organizational level of the organization to which the code belongs is determined after the static code scan is performed. However, the determination can also be performed before the static code scan is performed. This embodiment of the present disclosure does not limit this.

[0072] (I) First Software Quality Inspection Process

[0073] If the organization to which the software under test belongs is a first-level organization in a two-tier architecture, then the first software quality inspection process is executed. In this process, quality inspection nodes are embedded into the R&D process, including the coding stage, the submission for testing stage, the testing stage, and the production stage. Quality inspection scans or result checks are automatically triggered at the above key stages, and the R&D process is automatically determined based on the inspection results, the object being inspected, and the preset quality control thresholds to determine whether the R&D process can continue or whether it can be improved before continuing.

[0074] (Encoding phase)

[0075] Step S410: Automatically trigger static code scanning.

[0076] When developers submit a code merge request, the system automatically triggers a static code scanning task and completes the static code scan and records the results asynchronously.

[0077] (Submission for testing)

[0078] Step S420: Execute unit tests automatically.

[0079] For a single layer, the system automatically obtains the compilation environment required for the code and distributes the unit test tasks to the corresponding runtime environment (unit test execution module) for execution and records the unit test results.

[0080] Step S430: Perform quality checks automatically.

[0081] For a single layer of organization, the system automatically obtains the static code scan results and unit test results corresponding to the code submitted for testing, as well as the preset quality control threshold. When the scan results meet the threshold requirements, the system automatically triggers the next detection node (such as code security scan); otherwise, it prompts the applicant for the reason why it cannot continue.

[0082] Step S440: Perform a code security scan automatically.

[0083] Step S450: Automatically complete the integration of the application system and the scanning of the product.

[0084] (Testing phase)

[0085] Step S460: Perform automated testing.

[0086] System 100 automatically obtains automated test tasks and executes automated tests based on the submitted test content. When the test results meet the requirements, it enters the manual testing stage.

[0087] Step S470: Perform a manual test.

[0088] Step S480: Display the test report.

[0089] Researchers submit a change execution application (an example of an approval process), and the system automatically obtains the test report and product testing results and provides them to the change reviewer.

[0090] (Production Phase)

[0091] Step S490: Execute the production application.

[0092] (II) Second Software Quality Inspection Process

[0093] If the organization to which the software under test belongs is a secondary organization in a two-tier architecture system, then the second software quality inspection process will be executed.

[0094] like Figure 4 As shown, the second software quality testing process includes steps S460-S490. The specific content is similar to or the same as the aforementioned steps, and will not be repeated here.

[0095] As described above, in order to meet the quality inspection requirements of digital currency system R&D, this disclosure provides an automated embedded quality inspection management solution that integrates multiple quality inspection methods into the R&D process of digital currency system, realizes automatic quality inspection and management during the R&D process, and achieves the goals of improving R&D quality, improving R&D efficiency, and reducing R&D management costs.

[0096] Figure 5A A flowchart illustrating an exemplary static code scanning (S410) quality inspection node according to at least one embodiment of the present disclosure is shown, as follows: Figure 5A As shown, this process includes steps S4101 to S4106.

[0097] Step S4101: Initiate a code merge request.

[0098] Before performing static code scanning, a scanning plan needs to be pre-configured. Scanning plan information includes the scan plan name, the corresponding code repository, scanning rules, scan exclusion paths, and unit test exclusion paths. During configuration, rules can be retrieved from the built-in scan rule library as needed; multiple rules can be set. Additionally, multiple scan exclusion paths and unit test exclusion paths can also be set.

[0099] After completing a phase of coding, a code merge request can be initiated. The system will obtain the code repository information from the merge request information and query the corresponding scanning scheme for this code repository based on the code repository information. If a scanning scheme can be found, a static code scanning task will be created; otherwise, the static code scanning stage will be skipped by default.

[0100] Step S4102: Scan the execution engine to issue execution tasks.

[0101] To ensure operational efficiency, the system 100 sets up multiple scan execution containers 110Bn. The scan execution engine 110A reads the number of scan tasks to be executed in each scan execution container 110Bn and assigns newly created static code scan tasks to the currently idle scan execution container 110Bn.

[0102] Step S4103: Scan execution container 110Bn retrieves the scan plan and executes the scan.

[0103] The scan execution tasks are executed asynchronously, queued according to their creation order. The scan execution container 110Bn retrieves scan execution tasks from the queue, queries the corresponding scan plan based on the code repository information in the execution task, reads the scan rules in the scan plan in a loop, and calls the configuration table to scan and check the code in the corresponding code repository that is not excluded from the scan exclusion path.

[0104] Step S4104: Record and analyze the scan results.

[0105] The scan results are temporarily stored in memory. Once the scan is complete, the scan result parsing module 110C reads the scan results from memory and summarizes and stores them. The summarized information includes the total number of issues found in this scan, the number of issues at different scan levels, the corresponding code class name, and the line of code for each issue. Simultaneously, the bypass anomaly checking module 160 checks the execution time of the scan task. If the execution time is too long, exceeding the preset timeout, the bypass anomaly checking module 160 marks the scan task as "failed," thus preventing the scan from "freezing." "Failed" scan tasks can be re-initiated.

[0106] Step S4105: Send an instant message after the scan is completed. After the scan is completed, the system 100 will automatically send an instant message to the code merge initiator, reminding them to check the scan results. The instant message includes information such as the execution time of this scan and the corresponding code repository name.

[0107] Step S4106: View the scan results.

[0108] Relevant personnel can view the scan results and scan status. By entering the code repository name, they can quickly retrieve all scan records for a specific code repository. The scan results include the total number of issues found in this scan and the number of issues at different levels. Clicking on the total number of issues will take you to the issue details page, which displays the corresponding issue descriptions in a list format. Clicking on the issue description will automatically redirect you to the corresponding source code page, which displays the source code, the issue description, and suggested solutions.

[0109] Figure 5BA flowchart illustrating an exemplary unit test (S420) quality inspection node according to at least one embodiment of the present disclosure is shown. This process is embedded in the test submission phase and is an automated processing step in the test submission phase, including steps S4201 to S4204.

[0110] Step S4201: Initiate a unit test request.

[0111] After completing the coding, the R&D personnel initiate a test request and fill in the test content, including information such as the code library and branches involved. After the request is initiated, the system will retrieve the code library and branch information from the request information and query the unit test exclusion path corresponding to this code library based on the code library information. If it cannot be found, unit tests will be performed on all code in the code library by default.

[0112] Step S4202: The unit test scheduling engine 120A issues execution tasks.

[0113] To ensure operational efficiency while meeting the need for centralized unit test management across different programming languages, the deployment of the unit test execution container 120Bn adopts a "plug-in" deployment method. This allows the unit test execution container 120Bn to be deployed on different devices with different compilation environment parameters set, and the unit test scheduling engine 120A to centrally manage the unit test execution container 120Bn.

[0114] When a new programming language is added, the system 100 can deploy one or more corresponding unit test execution containers and incorporate them into the management of the unit test scheduling engine 120A, thereby achieving adaptation for unit tests of the new programming language. Similarly, when the unit test processing capacity is insufficient, the unit test execution containers can also be horizontally scaled.

[0115] After receiving a unit test task, the unit test scheduling engine 120A will query the number of tasks to be executed in the corresponding unit test execution container 120Bn based on the code library information (mainly the development language information), and allocate the newly created unit test execution task to the currently most idle unit test execution container 120Bn.

[0116] Step S4203: The unit test execution container executes unit tests.

[0117] Unit test execution tasks are executed asynchronously, queued according to their creation order. The unit test execution container 120Bn retrieves execution tasks from the queue, calls the code library interface to obtain the source code based on the code library information in the execution task, compiles the source code, then queries the unit test exclusion path corresponding to the code library, calls the unit test execution command to perform unit test checks on the source code outside the exclusion path, and temporarily records the scan results in memory.

[0118] Step S4204: Record and analyze the unit test results.

[0119] After all unit tests have been executed, the execution result parsing module 120C reads the execution results from memory and summarizes and stores the results. The summarized information includes the unit test coverage and unit test pass rate. After storing the information, the system 100 updates the test submission process status and enters the execution result checking step S430.

[0120] Meanwhile, the bypass anomaly check module 160 checks the execution time of the unit test task. When the execution time is too long and exceeds the preset timeout, the bypass anomaly check module 160 will mark the task as "failed". This mechanism avoids the scanning "freeze" problem. The "failed" task can be re-initiated for execution.

[0121] Figure 5C A flowchart illustrating an exemplary static code scanning and unit test result checking process (S430) according to at least one embodiment of the present disclosure is shown. This process is embedded in the test submission phase and is an automated processing step of the test submission phase, specifically including steps S4301 to S4303.

[0122] Step S4301: Obtain the test results of unit tests and static code scanning results.

[0123] After unit testing is completed, System 100 will automatically initiate the result checking function. First, System 100 will read the code repository information for this test submission, and then query the last static code scan result data and unit test data of the code repository based on the code repository information.

[0124] Step S4302: Obtain the quality control threshold.

[0125] System 100 retrieves the corresponding quality control threshold information for the code repository based on the code repository information, including the "bottom line" requirement for unit test coverage and the "bottom line" requirement for the number of static code scanning issues at each level. If no quality control threshold information is found, step S4303 is skipped.

[0126] Step S4303: Check the execution results.

[0127] The final static code scan results and unit test data of the code repository are compared with the quality control threshold information. If any data fails to meet the "bottom line" requirements, the test submission process is marked as "failed" and returned to the initiator.

[0128] Developers can then choose to fix code issues or add unit test cases based on the inspection results, and then resubmit the test. At this time, system 100 will repeat steps S4301-S4303. Alternatively, developers can initiate a "forced submission" process. In the "forced submission" process, the system will no longer run steps S4301-S4303, and a higher level of approval can be set.

[0129] Figure 5D A schematic flowchart of an exemplary code security scan quality inspection node according to at least one embodiment of the present disclosure is shown. This process is embedded in the submission test phase and includes steps S4401 to S4403 as an automated processing step in the submission test phase.

[0130] Step S4401: Invoke the security scan execution container (an example of code security scan module 130).

[0131] After passing the quality management check, the system first reads the code repository information submitted for testing, then calls the interface of the security scan execution container to send the code repository information to the interface of the security scan execution container and initiates a security scan task.

[0132] The security scan execution container uses a "plug-in" approach, for example, it can use the Fortify tool, which can be customized as needed.

[0133] Step S4402: Perform a code security scan.

[0134] After receiving a scan task, the security scan execution container executes the scan task and records the scan results to the database and files. The security scan adopts an asynchronous execution mode. After the task is initiated, there is no need to wait for the scan task to complete before proceeding with the subsequent steps of submitting for testing.

[0135] Step S4403: Display the code security scan results.

[0136] System 100 provides a security test result viewing page (function), which allows relevant personnel to view the security test scan results.

[0137] Figure 5E A schematic flowchart of an exemplary article scanning quality inspection node according to at least one embodiment of the present disclosure is shown. This process is embedded in the submission testing stage and is an automated processing step in the submission testing stage, including steps S4501 to S4503.

[0138] Step S4501: After passing the quality management inspection, System 100 will call the application system integration command to complete the integration of the application system and generate application artifacts. System 100 will then call the artifact library file upload interface to upload the artifacts to the specified directory.

[0139] Step S4502: The artifact repository (system) retrieves virus database information to scan artifacts and records the scan results. Developers can log in to the artifact repository to view the scan results.

[0140] Step S4503: To ensure scan quality, the quality administrator will periodically download the latest virus database from the Internet and then log in to the artifact database to update the virus database content.

[0141] Figure 5F A schematic diagram of an exemplary automated test process according to at least one embodiment of the present disclosure is shown. This process is embedded in the test submission phase and is an automated processing step in the test submission phase, including steps S4601 to S4605.

[0142] Step S4601: Application deployment and release.

[0143] Once the artifact is successfully uploaded to the artifact library, the system will automatically start the deployment process.

[0144] System 100 will execute different deployment processes based on different application types.

[0145] When the application system is a backend system, System 100 first calls the artifact library file download interface to download the artifact to the corresponding server, and then calls the deployment command to complete the deployment of the application system and start the application system.

[0146] When the application system is an App, System 100 first calls the artifact library file download interface to obtain the App, and then calls the automated testing platform App publishing interface to push the App to the automated testing platform. The automated testing platform will then publish the App to the test mobile phone.

[0147] Step S4602: Create an automated test task.

[0148] Once deployed, the system will automatically create automated test tasks, with task information including creation time and the name of the application to be tested.

[0149] Step S4603: Call the automated testing platform to execute the test.

[0150] System 100 invokes the automated testing platform to execute automated test cases. These automated test cases are maintained in advance by testers and will not be described in detail here.

[0151] Step S4604: Query the test results in round-robin mode and update them in the test submission process.

[0152] System 100 periodically polls the automated testing platform interface to query test results. Once the test is completed, System 100 writes the test results into the submitted test application form, including the total number of test cases executed, the number of test cases that passed, the test pass rate, and a link to the test result details page.

[0153] Step S4605: Confirm whether the test passed.

[0154] To meet the needs of different R&D, the system supports both automatic and manual automated testing and inspection methods.

[0155] When set to manual inspection, after the automated test is completed, the tester can log in to the system to view the test results in the submitted test application and decide whether to proceed to the next processing stage.

[0156] When set to automatic detection, after the automatic test is completed, the system will read the automatic test pass standard (the "bottom line" of the test pass rate). When the automatic test pass rate is higher than the "bottom line" threshold, the system will proceed to the next processing stage. Otherwise, it will send an instant message to the test request initiator and remain in the automatic test stage.

[0157] As mentioned above, quality management in traditional R&D processes is typically a sideline task, usually involving manual static code scanning, unit testing, automated testing, and manual review of results. This approach, due to manual intervention, makes it difficult to avoid oversights and prone to omissions. To address this issue, this embodiment embeds various quality management tasks into the R&D process, employing an automated system-triggered execution method. The system automatically reads and judges the execution results, determining whether to proceed to the next R&D stage. This embedded and automated control avoids oversights caused by manual execution and control, improving R&D quality and efficiency while reducing R&D costs.

[0158] It should be noted that the above application scenarios are merely exemplary in order to describe one or more aspects of this disclosure in specific scenarios. However, these aspects are not essential, and various modifications can be made to the application scenario. The embodiments of this disclosure are not limited.

[0159] At least some embodiments of this disclosure also provide an electronic device. Figure 6 A schematic diagram of an electronic device 600 according to at least one embodiment of the present disclosure is shown.

[0160] like Figure 6As shown, the electronic device 600 includes one or more processors 610 and a memory 620. The memory 620 includes one or more computer program modules 621. The one or more computer program modules 621 are stored in the memory 620 and configured to be executed by the processor 610. These computer program modules 621 include instructions for executing the quality inspection management method 300 for digital currency system development according to at least one embodiment of the present disclosure and its additional aspects. When executed by the processor 610, they can perform one or more steps of the quality inspection management method 300 for digital currency system development according to at least one embodiment of the present disclosure and its additional aspects. The memory 620 and the processor 610 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown). For example, the bus can be a Peripheral Component Interconnect Standard (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0161] For example, processor 610 may be a central processing unit (CPU), a digital signal processor (DSP), or other processing unit with data processing and / or program execution capabilities, such as a field-programmable gate array (FPGA). Processor 610 may be a general-purpose processor or a special-purpose processor, capable of controlling other components in electronic device 600 to perform desired functions.

[0162] Exemplarily, memory 620 may include any combination of one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc. One or more computer program modules 621 may be stored on the computer-readable storage medium, and processor 610 may run one or more computer program modules 621 to implement various functions of electronic device 600. The computer program modules include multiple computer-executable instructions. Various application programs and various data, as well as various data used and / or generated by the application programs, may also be stored in the computer-readable storage medium.

[0163] For example, electronic device 600 may also include input devices such as touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, and gyroscopes; output devices such as liquid crystal displays, speakers, and vibrators; storage devices such as magnetic tapes and hard disks (HDDs or SDDs); and communication devices such as network interface cards like LAN cards and modems. The communication devices allow electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data and perform communication processing via networks such as the Internet. A drive is connected to the I / O interface as needed. Removable storage media, such as disks, optical disks, magneto-optical disks, and semiconductor memories, are installed on the drive as needed so that computer programs read from them can be installed into the storage device as required.

[0164] For example, the electronic device 600 may further include a peripheral interface (not shown in the figure). This peripheral interface can be of various types, such as a USB interface, a Lightning interface, etc. The communication device can communicate wirelessly with networks and other devices, such as the Internet, intranets and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). Wireless communication can use any of a variety of communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., based on IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n standards), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email, instant messaging, and / or Short Message Service (SMS), or any other suitable communication protocol.

[0165] The electronic device 600 may be, for example, a system-on-a-chip (SOC) or a device including the SOC. For instance, it can be any device such as a mobile phone, tablet, laptop, e-reader, game console, television, digital photo frame, navigator, home appliance, communication base station, industrial controller, server, etc., or any combination of data processing devices and hardware. The embodiments of this disclosure do not limit this. The specific functions and technical effects of the electronic device 600 can be found in the foregoing description of the quality inspection and management method 300 for digital currency system development according to at least one embodiment of this disclosure and its additional aspects, and will not be repeated here.

[0166] Figure 7 A schematic diagram of a computer-readable medium 700 according to at least one embodiment of the present disclosure is shown.

[0167] like Figure 7 As shown, a computer-readable medium 700 stores computer instructions 710, which, when executed by a processor, perform one or more steps of the quality inspection management method 300 for the development of a digital currency system and its additional aspects as described above.

[0168] For example, when the program code is read by a computer, the computer can execute the program code stored in the computer storage medium to perform one or more steps of, for example, the quality inspection management method 300 for the development of a digital currency system according to at least one embodiment of the present disclosure and its additional aspects.

[0169] For example, the computer-readable medium may include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), flash memory, and other computer-readable media or any combination thereof.

[0170] At least some of the embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other.

[0171] It should be noted that, in this document, relational terms such as "first," "second," etc., are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0172] The following points should be noted regarding this disclosure:

[0173] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0174] (2) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0175] The above description is merely an exemplary embodiment of this disclosure and is not intended to limit the scope of protection of this disclosure, which is determined by the appended claims.

Claims

1. A quality inspection and management method for the development of a digital currency system, the method comprising: Receive quality inspection requests for software under test during the development of the digital currency system, and determine the organizational level to which the software under test belongs based on the quality inspection requests; Based on the organizational level to which the software under test belongs, determine the quality inspection process required for the software under test; According to the testing sequence of each quality testing node in the aforementioned quality testing process, the corresponding quality testing operations are performed on the software under test. The quality inspection process includes multiple quality inspection nodes, and each quality inspection node automatically triggers the corresponding inspection operation on the software under test according to the inspection sequence under preset conditions.

2. The method according to claim 1, wherein, Based on the organizational hierarchy to which the software under test belongs, determine the steps of the quality inspection process required for the software under test, including: In response to the fact that the organization to which the software under test belongs is a first-level organization, a first software quality inspection process is executed. The first software quality inspection process includes the following quality inspection nodes: static code scanning, unit testing, code security scanning, artifact scanning, and automated testing. In response to the fact that the organization to which the software under test belongs is a two-tier organization, a second software quality inspection process is executed, which includes the automated testing.

3. The method according to claim 2, wherein, The method further includes: A unit test scheduling engine and multiple unit test execution modules it schedules are provided in advance. Each unit test execution module is configured with a compilation environment that supports different programming languages. Furthermore, the step of performing the unit test includes: The unit test scheduling engine is started to determine the unit test tasks and compilation environment of the software under test based on the unit test request. The unit test scheduling engine distributes the unit test tasks to the unit test execution module corresponding to the compilation environment to execute the unit test tasks.

4. The method according to claim 3, wherein, The method further includes: If the unit test scheduling engine fails to find a unit test execution module corresponding to the development language of the software under test, it adds a unit test execution module that supports the compilation environment of the development language and incorporates it into the scheduling management of the unit test scheduling engine.

5. The method according to claim 3, wherein, The unit test scheduling engine adjusts the participation of each unit test execution module in the unit test task based on the unit test task and the processing capacity of each unit test execution module in its scheduling management.

6. The method according to claim 2 or 3, wherein, The method further includes: During the execution of the static code scan and the unit test, the execution time is monitored, and it is determined whether the execution time exceeds the set time. If the execution time exceeds the set time, the static code scan or the unit test will be re-executed.

7. The method according to claim 2, wherein, The method further includes: The results of the most recent static code scan and the results of the unit test are formatted. Determine whether the formatting result meets the quality control threshold. If it does, trigger the next quality inspection node.

8. A quality inspection and management system for the development of digital currency systems, comprising: The institutional hierarchy determination module is configured to receive quality inspection requests from the software under test during the development of the digital currency system, and determine the institutional hierarchy of the software under test based on the quality inspection requests. The testing process management module is configured to determine the required quality testing process for the software under test based on the organizational level to which the software under test belongs; and to perform corresponding quality testing operations on the software under test according to the testing sequence of each quality testing node in the quality testing process. The quality inspection process includes multiple quality inspection nodes, and each quality inspection node automatically triggers the corresponding inspection operation on the software under test according to the inspection sequence under preset conditions.

9. The system according to claim 8, wherein, The testing process management module is further configured to: in response to the organization to which the software under test belongs being a first-level organization, execute a first software quality testing process, the first software quality testing process including the following quality testing nodes: static code scanning, unit testing, code security scanning, artifact scanning, and automated testing; in response to the organization to which the software under test belongs being a second-level organization, execute a second software quality testing process, the second software quality testing process including the automated testing.

10. The system according to claim 9, wherein, The system also includes: a unit test scheduling engine and multiple unit test execution modules scheduled by the engine, each unit test execution module being configured with a compilation environment that supports different programming languages; The detection process management module is also configured to control the startup of the unit test scheduling engine; The unit test scheduling engine is configured to determine the unit test task and compilation environment of the software under test based on the unit test request, and to send the unit test task to the unit test execution module corresponding to the compilation environment to execute the unit test task.

11. The system according to claim 10, wherein, The unit test scheduling engine is further configured to, if it fails to find a unit test execution module corresponding to the development language of the software under test, add a unit test execution module that supports the compilation environment of the development language and include it in the scheduling management of the unit test scheduling engine.

12. The system according to claim 10, wherein, The unit test scheduling engine is further configured to adjust the participation of each unit test execution module in the unit test task based on the unit test task and the processing capacity of each unit test execution module in its scheduling management.

13. The system according to claim 9 or 10, wherein, The system also includes: The bypass anomaly detection module is configured to start during the execution of the static code scan and the unit test to monitor the execution time and determine whether the execution time exceeds a set time; if the execution time exceeds the set time, the static code scan or the unit test is re-executed.

14. An electronic device comprising: One or more processors; Memory, which stores one or more computer program modules. The one or more computer program modules are configured to be executed by the one or more processors to implement the method according to any one of claims 1-7.

15. A computer-readable medium storing computer-executable instructions, wherein, When computer-executable instructions are executed by one or more processors, they are used to implement the method according to any one of claims 1-7.

Images