CN113282517A - Quality evaluation system of intelligent contract code - Google Patents
Quality evaluation system of intelligent contract code Download PDFInfo
- Publication number
- CN113282517A CN113282517A CN202110826875.7A CN202110826875A CN113282517A CN 113282517 A CN113282517 A CN 113282517A CN 202110826875 A CN202110826875 A CN 202110826875A CN 113282517 A CN113282517 A CN 113282517A
- Authority
- CN
- China
- Prior art keywords
- code
- intelligent contract
- test
- quality evaluation
- subtasks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
A system for quality assessment of intelligent contract codes, the system comprising: the production line management subsystem is used for starting a production line task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions; and further for distributing the intelligent contract code to evaluation subsystems corresponding to the plurality of subtasks, respectively; and the plurality of evaluation subsystems are used for receiving the intelligent contract codes distributed by the pipeline management subsystem and executing corresponding subtasks in the carried execution environment.
Description
Technical Field
The present description relates to the field of computer applications, and more particularly, to a quality evaluation system for intelligent contract codes.
Background
The block chain technology, also called as distributed account book technology, is a new technology which is formed by a plurality of computing devices participating in 'accounting' together and maintaining a complete distributed database together, and has the characteristics of decentralization, openness and transparency and difficulty in tampering; the intelligent contract refers to a digital contract which is defined by the form of code and can be triggered to execute by transaction on a block chain. Quality control of intelligent contract codes is very important because a large number of on-chain services need to be completed by means of intelligent contracts.
In the related art, the written intelligent contract code can be executed and tested, and the quality of the written intelligent contract code is evaluated according to whether the expected service can be completed or not; however, as the business is expanded, the intelligent contract codes to be evaluated become more and more complex, and therefore the existing code evaluation mechanism cannot fully evaluate the quality of the complex intelligent contract codes.
Disclosure of Invention
In view of the above, the present specification discloses a quality evaluation system for intelligent contract codes.
According to a first aspect of embodiments herein, there is disclosed a quality evaluation system for intelligent contract code, comprising:
the production line management subsystem is used for starting a production line task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions; and further for distributing the intelligent contract code to evaluation subsystems corresponding to the plurality of subtasks, respectively;
and the plurality of evaluation subsystems are used for receiving the intelligent contract codes distributed by the pipeline management subsystem and executing corresponding subtasks in the carried execution environment.
According to a second aspect of the embodiments of the present specification, there is disclosed a method for quality evaluation of an intelligent contract code, comprising:
starting a pipeline task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions;
distributing the intelligent contract code to execution environments corresponding to the plurality of subtasks respectively;
and executing the plurality of subtasks in the execution environments corresponding to the plurality of subtasks, respectively.
In the technical scheme, the pipeline task for performing quality evaluation on the intelligent contract to be evaluated comprises a plurality of subtasks respectively corresponding to different quality evaluation dimensions, so that the quality of the intelligent contract to be evaluated can be evaluated from different quality evaluation dimensions, and the comprehensiveness of the quality evaluation on the complex intelligent contract code can be remarkably improved.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this specification and together with the description, serve to explain the principles.
FIG. 1 is a diagram illustrating an exemplary configuration of a system for quality assessment of intelligent contract code as described herein;
FIG. 2 is a schematic diagram of the structure of a pipeline task described in this specification;
FIG. 3 is a closed-loop exemplary diagram of development and testing of intelligent contract code as described herein;
FIG. 4 is an exemplary diagram of a quality assessment chart as described herein;
FIG. 5 is a flowchart illustrating an example method of evaluating the quality of intelligent contract code as described herein;
FIG. 6 is a diagram illustrating an example of a computer device for performing a quality assessment of intelligent contract code as described herein.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in one or more embodiments of the present disclosure, the technical solutions in one or more embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in one or more embodiments of the present disclosure. It is to be understood that the described embodiments are only a few, and not all embodiments. All other embodiments that can be derived by one of ordinary skill in the art from one or more embodiments of the disclosure without making any creative effort shall fall within the scope of the disclosure.
When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of systems and methods consistent with certain aspects of the present description, as detailed in the appended claims.
The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.
In practical applications, the blockchain provides the functionality of a Smart contract (Smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.
Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.
Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.
In the related art, the written and compiled intelligent contract codes (such as the above byte codes) can be tested, and the quality of the written intelligent contract codes can be evaluated according to whether expected services can be completed or not; however, as the service based on the block chain is expanded, the intelligent contract code to be evaluated provided by the developer becomes more and more complex, and the traditional evaluation mechanism cannot fully evaluate the quality of the complex intelligent contract code.
Based on the above, the present specification proposes an intelligent contract code quality evaluation system, which starts a pipeline task including a plurality of subtasks for an intelligent contract code to be evaluated in quality, so as to evaluate the quality of the intelligent contract code from a plurality of different quality evaluation dimensions.
When the intelligent contract code quality evaluation system is implemented, the intelligent contract code quality evaluation system can be composed of a pipeline management subsystem and a plurality of evaluation subsystems; referring to FIG. 1, FIG. 1 is a diagram illustrating an exemplary structure of an intelligent contract code quality evaluation system; in this example, the pipeline management subsystem may interface with the plurality of evaluation subsystems to collectively form the intelligent contract code quality evaluation system.
The pipeline management subsystem can be responsible for starting a pipeline task for performing quality evaluation on the intelligent contract code, and the pipeline task comprises a plurality of subtasks respectively corresponding to the evaluation subsystems; the production line management subsystem can execute corresponding subtasks in the execution environment carried by each evaluation subsystem only by distributing the codes of the intelligent contract to the evaluation subsystems, so that the quality evaluation of the intelligent contract codes is completed from the quality evaluation dimension corresponding to each subtask.
In the above technical solution, on one hand, the pipeline management subsystem may start a pipeline task for performing quality evaluation on the intelligent contract to be evaluated, and the pipeline task includes a plurality of subtasks respectively corresponding to different quality evaluation dimensions; therefore, the multiple evaluation subsystems in the system can evaluate the quality of the intelligent contract to be evaluated from different quality evaluation dimensions, and the comprehensiveness of the quality evaluation of the complex intelligent contract codes can be remarkably improved;
on the other hand, because the plurality of subtasks corresponding to different quality assessment dimensions form a pipeline task together, under the condition that the number of intelligent contract codes to be subjected to quality assessment is large, the equipment utilization rate of each subsystem can be improved, and the idle equipment is reduced, so that the implementation efficiency of quality assessment is integrally improved.
The present specification is described below with reference to specific embodiments and specific application scenarios.
With continued reference to fig. 1, in the intelligent contract code quality evaluation system shown in fig. 1, two subsystems may be included:
the production line management subsystem is used for starting a production line task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions; and further for distributing the intelligent contract code to evaluation subsystems corresponding to the plurality of subtasks, respectively;
and the plurality of evaluation subsystems are used for receiving the intelligent contract codes distributed by the pipeline management subsystem and executing corresponding subtasks in the carried execution environment.
The intelligent contracts can comprise any kinds of intelligent contracts which are used for being deployed on any blockchain; the intelligent contract code may include uncompiled code written in a high-level language as described above, or compiled bytecode executable by a virtual machine on a block-node device.
The pipeline task may include a task that is composed of a plurality of subtasks (or called pipeline links) and requires the subtasks to be executed in a certain order; for example, in a case that quality evaluation needs to be performed on a certain uncompiled intelligent contract Code01 developed for an ethernet blockchain, a pipeline management subsystem in the above intelligent contract Code quality evaluation system may start a pipeline task for the intelligent contract Code01, where the pipeline task may include sub-tasks for evaluating dimensions respectively for syntax check before compilation, Code integrity evaluation during compilation, execution test after compilation, and the like, and an execution order of each sub-task may be set according to whether compilation is needed or not.
It is to be understood that the above example is only a feasible example, and a person skilled in the art may determine the execution timing relationship between the subtasks according to the specifically designed subtask content, and the description need not be further limited to this.
The execution environment may include any execution environment adapted to the subtask to be executed; for example, for the syntax checking subtask before compiling, assuming that the subtask is designed as an application program executed in the Linux environment, the execution environment may be a Linux virtual machine for executing the subtask; for another example, for a compiled execution test subtask, assuming that the subtask needs to test the execution condition of the compiled bytecode in the blockchain node device, the corresponding execution environment may be a test sandbox configured in a preset blockchain environment.
Of course, it can be understood that the execution environment may also be equipped with additional functional modules according to specific evaluation requirements; for example, for the above-mentioned sub-tasks related to the execution test, the corresponding execution environment may be configured with a memory monitoring module, so as to facilitate direct detection of memory changes during the code running process, and the like.
In one embodiment, the intelligent contract code to be evaluated may include an uncompiled first code or a compiled second code of the first code; the various evaluation subsystems included in the system may include any combination of a static analysis subsystem, an execution testing subsystem, a syntax checking subsystem, a fuzzy testing subsystem, and a compiling subsystem. As described above, various evaluation subsystems in the system may correspond to subtasks in the pipeline task, and therefore, a person skilled in the art may select combinations that meet requirements from the various subtasks according to actual business requirements, exclude combinations that do not meet requirements, and set up corresponding evaluation subsystems, thereby implementing customized evaluation and control on intelligent contract code quality.
Referring to fig. 2, fig. 2 is a schematic diagram of a pipeline task according to the present disclosure; in this example, the pipeline tasks may include several sub-tasks of syntax checking, static analysis, code compilation, execution testing, fuzz testing, and execution testing, which may be further subdivided into unit testing and integration testing.
The specific functions and implementations of the various subsystems described above will be described in detail with reference to examples.
The static analysis subsystem can be used for executing a safety evaluation subtask based on static analysis; program Static Analysis (Program Static Analysis) generally refers to a code Analysis technique that scans Program codes through lexical Analysis, syntactic Analysis, control flow, data flow Analysis and other techniques to verify whether the codes meet the indicators of normativity, safety, reliability, maintainability and the like in a mode of not running the codes; for example, by means of pattern matching, functions, data structures and the like known to have security vulnerabilities are searched in program source codes; usually, the static analysis inputs the source code of the program (i.e. the first code), but the executable code generated after compiling (i.e. the second code) may also be directly analyzed; when the static analysis subsystem is implemented, the static analysis subsystem may perform static analysis on the first code based on a preset code security rule, so as to generate a security evaluation result corresponding to the first code; for example, a static analysis tool such as drAna may be used to input the used code security rule and the first code to obtain a static analysis result, and a security evaluation result corresponding to the first code may be generated according to the result of the static analysis, such as the number of security holes, the threat level, and the like.
The execution test subsystem can be used for executing an execution test subtask based on a preset test case; executing a test generally refers to testing a computer program that has completed all or part of its functions and modules before formal use, using a test case composed of test data and expected results, to ensure that the program can operate correctly in a predetermined manner; generally, the execution test is directed to the executable code after compilation (i.e., the second code described above); therefore, when the execution test subsystem is implemented, the subsystem may perform an execution test on the second code based on a preset test case, and generate an execution evaluation result corresponding to the second code.
For example, for an executable program code whose functions are handled in different cases, the test case may select an input including various situations that the program can accept and a corresponding output, so as to verify the correctness of the executable program code. Specifically, when selecting a test case, a person skilled in the art can select a corresponding test case in a reverse-reasoning manner according to the requirement on the type of the result of the execution test; for example, if the robustness (also called robustness) of the executable program code needs to be verified, the input content that the program cannot accept can be selected, that is, the robustness of the executable program code is determined according to the reaction of the executable program code when unexpected input content is received.
In an embodiment, when the plurality of evaluation subsystems includes the execution test subsystem, the test cases may include the following two types of test cases: the system comprises a first type of test case used for carrying out unit test on the second code based on a ready-to-use or chain-throwing environment, and a second type of test case used for carrying out integration test on the second code based on a fixed chain environment. The instant drop chain environment may refer to a block chain environment which is temporarily built during a test period and can be discarded after the test is completed, and the fixed chain environment may refer to a block chain environment which is built in advance, continuously runs, and can be repeatedly used in a plurality of rounds of execution tests. Generally, unit testing, also called module testing, is small in scale and suitable for confirming the functions of units such as code blocks, functions and the like in large-scale program codes, and integration testing is large in scale and is generally used for confirming whether the units or modules can complete expected tasks after integration. Since the intelligent contract code is eventually required to be deployed on the blockchain, the environment used for unit testing or integration testing of the second code may be a blockchain environment. However, for the sake of testing efficiency, when performing different types of execution tests on the second code, the specific adopted blockchain environment may also be different;
for example, when the second code is subjected to the cell test, a chain throwing environment can be adopted, and the block chain environment can be destroyed after being used, so that the additional maintenance investment on the block chain environment for the test can be avoided; for another example, when performing the integration test on the second code, since the integration test needs to check the support degree of the entire second code for the service, and the sufficiently simulated blockchain environment is generally complex and is not suitable for being thrown at any time, a fixed chain environment may be used to reduce the investment for repeatedly constructing the sufficiently simulated blockchain environment.
In an illustrated embodiment, the first type of test case for unit testing and the second type of test case for integration testing may each include test cases based on different intelligent contract development frameworks; the different intelligent contract development frameworks can respectively adopt different development languages. Generally, in a larger-scale code quality evaluation process, the evaluated intelligent contract codes may come from different projects, and therefore, the adopted intelligent contract development frameworks may also be different; for example, in the early stage of operation, the blockchain service company AA uses an industry-sourced development framework frame01 in developing an intelligent contract, and uses a programming language lang 01. After a period of time, the proprietary development framework 02 is customized according to the business requirements of the second code, and the programming language lang02 is used, so if in a certain code quality evaluation process, the second code which needs to perform the execution test is developed by using the development framework 01, and the second code is developed by using the development framework 02, the two test cases are required to contain the test cases based on the different intelligent contract development frameworks, and the different development frameworks can also adopt different programming languages.
In one illustrated embodiment, the intelligent contract development framework may include a chainstack and a donut. Chainstack is a java-based intelligent contract development framework, and donut is a JavaScript-based intelligent contract development framework. Under the condition that the intelligent contract to be evaluated comprises both the content developed based on the chainstack framework and the content developed based on the donut framework, the test cases of the first type of test case and the second type of test case can be respectively developed based on the chainstack framework and the donut framework, so that the adaptability of the intelligent contract to be evaluated is ensured.
In an embodiment shown in the above, the execution evaluation result obtained by the execution test may include a case coverage rate and a case passing rate of the second code; during implementation, a log output instruction can be inserted into a code, so that the coverage condition of a code block is judged according to an output log to obtain the case coverage rate of the second code, and input parameters capable of triggering different option branches can be preset in a test case, so that the option branches in the second code can be covered as high as possible; and counting the proportion of the paired service input and output successfully realized by the second code in the test case to obtain the case success rate of the second code.
Generally, the coverage rate may include coverage of multiple layers, such as coverage of code blocks, coverage of logical branches, etc., which may be used to describe the proportion of the code that has undergone testing, while the use case passing rate is more biased to describe whether the code can perform business satisfactorily; the two indexes are combined, so that the accuracy of the execution evaluation result obtained by the execution test can be further improved.
The syntax checking subsystem can be used for carrying out syntax checking on the first code and generating a corresponding syntax evaluation result; when the grammar checking subsystem is realized, the grammar rule can be matched with the language grammar of the checked first code; for example, if the first code to be checked is written in the solid language, the syntax checking should be performed using the syntax standard of the solid language.
Generally, because a code with an abnormal grammar cannot be compiled correctly, the abnormal grammar part needs to be corrected to have the value of subsequent evaluation, and therefore, if a grammar checking subsystem is arranged in the system, a corresponding grammar checking subtask can be arranged at a position close to the front in an evaluation flow of the code before compiling; generally speaking, the syntax evaluation result may include information such as the number, location, severity level, and the like of the syntax errors in the first code, and this part of information may be referred by a manager, and may also be fed back to a developer as debugging information so as to correct the first code in time, so as to accelerate the code iteration speed and improve the production efficiency.
The fuzzy test subsystem can be used for carrying out fuzzy test on the second code and generating a corresponding stability evaluation result; FUZZ testing is generally considered to be an automatic or semi-automatic testing technique, often used to discover errors and security problems in the code of software/operating systems/networks, where the input of random and illegal data is referred to as "FUZZ"; thereafter, various exceptions, such as system crashes or built-in code failures, etc., occurring to the software/operating system/network, etc. being tested, are monitored and recorded as a result of the fuzz test. Unlike the execution tests described above, which tend to verify the known functionality of code, fuzz testing tends to use a large number of random inputs to discover unknown problems in the code.
The compiling subsystem may be configured to compile the first code to generate the second code. Also similar to the syntax checking subsystem, the compiling function included in the syntax checking subsystem should be adapted to the language used by the first code; for example, if the first code is an intelligent contract code written in bambooo language and needs to be finally deployed into the ethernet block chain, the compiling subsystem may include a compiler for compiling the program code written in bambooo language into byte codes executable by the ethernet virtual machine. It is also understood that the compiling subsystem may also output evaluation indicators related to code quality, such as code repetition rate, expected execution efficiency, instruction usage statistics, etc., so as to provide a richer data source for intelligent contract code quality evaluation. Those skilled in the art can customize the specific functions of the compiling subsystem according to specific requirements.
It can be understood that, since the code submitted to the intelligent contract code quality evaluation system may include only the first code or the corresponding compiled second code, the intelligent contract code quality evaluation system does not need to be responsible for compiling the first code into the second code, and the compiling subsystem may not be provided.
In an embodiment shown in the above, the system may further include a result display subsystem, and the system may be configured to obtain the execution results of the multiple subtasks from the multiple evaluation subsystems, generate a quality evaluation result corresponding to the intelligent contract code according to the execution results of the multiple subtasks, and finally output and display the quality evaluation result.
For example, if the system includes a syntax checking subsystem, a static analysis subsystem, an execution testing subsystem, and a fuzzy testing subsystem, the result presentation subsystem may obtain the execution results of the corresponding subtasks, i.e., a plurality of evaluation results of a plurality of quality evaluation dimensions, from the syntax checking subsystem, the static analysis subsystem, the execution testing subsystem, and the fuzzy testing subsystem, respectively, and then integrate the plurality of evaluation results to generate a quality evaluation result for the intelligent contract code, which includes information of the plurality of evaluation dimensions, and output and present the quality evaluation result.
Referring to fig. 3, fig. 3 is a closed-loop exemplary diagram illustrating development and testing of an intelligent contract code; in this example, the intelligent contract code quality evaluation system may interface with an intelligent contract code development client, so as to implement access of a code development and code quality evaluation pipeline; in this case, after the intelligent contract code quality evaluation pipeline gives a quality evaluation result for the submitted intelligent contract code, the development side can immediately perform version iteration of the code according to the quality evaluation result, and submit a new version of the intelligent contract code to the quality evaluation pipeline for evaluation. By adopting the scheme, the code development, evaluation and iteration form a service closed loop, so that the version iteration of the code can be accelerated, a developer can acquire and modify a test result quickly, and unnecessary test and evaluation of the intelligent contract code quality evaluation system on the overdue version of the code can be reduced.
For example, although the unit test in the test process may be performed independently by the execution test subsystem, the execution test subsystem may also push the task related to the unit test to a developer working environment (e.g., an integrated development environment developed for a block chain such as Remix and ChainIDE), and the developer may perform the unit test and further debugging directly in the developer working environment; therefore, the intelligent contract code quality evaluation production line can carry out subsequent evaluation on the intelligent contract codes after the versions of the developers are iterated, and therefore the service implementation speed is increased.
In practical application, besides the intelligent contract code quality evaluation system is connected with the intelligent contract code development system to form a development-evaluation-iteration business closed loop, the quality evaluation result of the intelligent contract code can be visually output, so that a manager can control the code quality of the intelligent contracts in batches.
In an embodiment shown in the above, in the process of outputting and displaying the quality evaluation result by the result displaying subsystem, the quality evaluation result may be firstly visualized to obtain a corresponding quality evaluation chart, and then the quality evaluation chart is output. Referring to fig. 4, fig. 4 is an exemplary diagram of a quality assessment chart described herein; in this example, assuming that the quality evaluation result includes a code branch coverage evaluation result for a plurality of intelligent contract codes, the result presentation subsystem may perform visualization processing on the evaluation result to obtain a statistical chart as shown in fig. 4, so that a manager can obtain a more intuitive experience on the quality of the plurality of intelligent contract codes.
Generally speaking, the execution mode of multiple tasks may be synchronous execution or asynchronous execution, where synchronous execution generally refers to an execution mode that is sequentially executed according to a preset sequence, a subsequent task needs to be started after a previous task is completed, and asynchronous execution generally refers to an execution mode that does not preset the sequence of multiple tasks, and tasks do not generally need to wait for other tasks to be completed during asynchronous execution. The reliability of the process can be improved by synchronously executing all the subtasks in sequence, but performance waste can be caused by waiting links; although asynchronous execution may reduce the reliability of the flow, the waiting time can be reduced, and the resource utilization rate of the system can be improved; thus, whether or not each subtask in the pipeline task executes asynchronously may be determined after evaluating the success or failure of asynchronous execution. For example, after asynchronous execution gain and loss evaluation is performed on a certain group of subtasks, if an asynchronous execution mode is used, the benefit brought by the utilization rate of system resources is improved and is greater than the loss caused by the reduction of the reliability of the process, the group of subtasks can be performed in an asynchronous execution mode.
In an embodiment shown, when the plurality of subsystems include the fuzz testing subsystem, a subtask corresponding to the fuzz testing subsystem may be an asynchronous task. Generally, the above-mentioned fuzz testing process requires a large amount of random and illegal data to perform a simulation attack, and thus may consume a large amount of system resources and time; and because the dependence relationship between the subtask corresponding to the fuzzy test subsystem and other subtasks is less, the subtask corresponding to the fuzzy test subsystem can be set as an asynchronous task, so that the phenomenon that other subtasks wait for the completion of a fuzzy test link for a long time is avoided, and the resource utilization rate of the system is improved. Of course, it is understood that the subtasks that can be set as asynchronous tasks are not limited to the corresponding subtasks of the fuzz test, and the description need not be further limited.
In an embodiment shown, the system may further be equipped with a code library for storing the intelligent contract codes to be evaluated submitted by the user; when the pipeline management subsystem starts a pipeline task for performing quality evaluation on the intelligent contract code to be evaluated, the intelligent contract code to be evaluated submitted by a user can be periodically acquired from the code base based on a preset timing task, and a corresponding quality evaluation pipeline task is started. For example, the intelligent contract code quality evaluation system may be equipped with a gillab code library, and the pipeline management subsystem periodically obtains an intelligent contract code to be evaluated, which is submitted by a user, from the gillab code library based on a preset timing task, and starts a corresponding quality evaluation pipeline task.
It is understood that the above-mentioned scheme of implementing high-instantaneity quality assessment on intelligent contract codes in a code library by timing tasks is only one feasible example; in addition, those skilled in the art may set the pipeline management subsystem to start up as instructed, or to start up driven by an event generated by newly uploading an intelligent contract code in the code library, etc., which need not be further limited in this specification.
The above are all embodiments of the quality evaluation system for intelligent contract codes in the present specification; the present specification also discloses a method for quality evaluation of intelligent contract codes, please refer to fig. 5, fig. 5 is a flow chart of the method for quality evaluation of intelligent contract codes shown in the present specification, and the method may include the following steps:
s501, starting a pipeline task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions;
s502, distributing the intelligent contract codes to execution environments respectively corresponding to the subtasks;
s503, executing the plurality of subtasks in the execution environments corresponding to the plurality of subtasks, respectively.
For the definition and examples of the block chain, the intelligent contract, the pipeline task, the execution environment, and other items in the method, reference is made to the above description of the quality evaluation system of the intelligent contract code, and details are not repeated in this specification. When the method is applied, assuming that the intelligent contract code to be evaluated is an intelligent contract code written based on the solid language and aiming at the ether house block chain, a pipeline task may be started for the intelligent contract code, and as an example, the pipeline task may include sub-tasks for evaluating dimensions, such as solid syntax check before compiling, code integration evaluation in the compiling process, execution test in the chain environment of the simulated ether house block chain after compiling, and the like, respectively, so as to obtain a multi-dimensional intelligent contract code quality evaluation result.
Therefore, by the method, the quality of the intelligent contract code can be evaluated from multiple quality evaluation dimensions in a pipeline task mode, and the comprehensiveness of the quality evaluation of the complex intelligent contract code can be improved; and due to the adoption of a pipeline task scheduling mode, under the condition that the number of intelligent contract codes to be subjected to quality evaluation is large, the equipment utilization rate of each subsystem can be improved, and the idle equipment is reduced, so that the implementation efficiency of quality evaluation is integrally improved.
In one embodiment, the method further comprises a result display process; specifically, after the plurality of subtasks are executed, the execution results of the plurality of subtasks may be obtained, and the quality evaluation result corresponding to the intelligent contract code may be generated according to the execution results of the plurality of subtasks; and outputting and displaying the quality evaluation result.
In one embodiment shown, the specific form of the output presentation described above may be further varied; for example, after the quality evaluation result is obtained, the quality evaluation result may be visualized to obtain a corresponding quality evaluation chart, and the quality evaluation chart may be output.
In one embodiment, the smart contract code to be evaluated may include an uncompiled first code or may further include a compiled second code of the first code. In this case, the executing of the plurality of subtasks may include executing any combination of the following subtasks:
a static analysis subtask which is used for carrying out static analysis on the first code based on a preset code security rule and generating a security evaluation result corresponding to the first code; for example, a static analysis tool such as drAna may be used to input the used code security rule and the first code to obtain a static analysis result, and a security evaluation result corresponding to the first code may be generated according to the static analysis result, such as the number of security holes, the threat level, and the like.
Executing a test subtask, including executing a test on the second code based on a preset test case, and generating an execution evaluation result corresponding to the second code; for example, for an executable program code whose functions are handled in different cases, the test case may select an input including various situations that the program can accept and a corresponding output, so as to verify the correctness of the executable program code.
A grammar checking subtask which comprises the step of carrying out grammar checking on the first code and generating a corresponding grammar evaluation result; when the method is implemented, the grammar rule can be matched with the language grammar of the checked first code; for example, if the first code to be checked is written in the solid language, the syntax checking should be performed using the syntax standard of the solid language.
Generally, because a code with an abnormal grammar cannot be compiled correctly, the abnormal grammar part needs to be corrected to have the value of subsequent evaluation, and therefore, a grammar checking subtask can be arranged at a position close to the front in an evaluation flow of the code before compiling; generally speaking, the syntax evaluation result may include information such as the number, location, severity level, and the like of the syntax errors in the first code, and this part of information may be referred by a manager, and may also be fed back to a developer as debugging information so as to correct the first code in time, so as to accelerate the code iteration speed and improve the production efficiency.
The fuzzy test subtask comprises a fuzzy test on the second code and a corresponding stability evaluation result; FUZZ testing is generally considered to be an automatic or semi-automatic testing technique, often used to discover errors and security problems in the code of software/operating systems/networks, where the input of random and illegal data is referred to as "FUZZ"; thereafter, various exceptions, such as system crashes or built-in code failures, etc., occurring to the software/operating system/network, etc. being tested, are monitored and recorded as a result of the fuzz test. Unlike the execution tests described above, which tend to verify the known functionality of code, fuzz testing tends to use a large number of random inputs to discover unknown problems in the code.
And compiling the subtask, which includes compiling the first code to generate the second code. For example, if the first code is an intelligent contract code written in bambooo language and needs to be finally deployed into the ethernet block chain, the compiling subsystem may include a compiler for compiling the program code written in bambooo language into byte codes executable by the ethernet virtual machine. It is also understood that the compiling subsystem may also output evaluation indicators related to code quality, such as code repetition rate, expected execution efficiency, instruction usage statistics, etc., so as to provide a richer data source for intelligent contract code quality evaluation. Those skilled in the art can customize the specific functions of the compiling subsystem according to specific requirements.
In an illustrative embodiment, in the case that the plurality of evaluation subtasks includes the execution test subtask, the test cases may include a first type of test case for performing unit testing on the second code based on a ready-to-use, i.e., drop-chain environment, and a second type of test case for performing integration testing on the second code based on a fixed-chain environment. The instant drop chain environment may refer to a block chain environment which is temporarily built during a test period and can be discarded after the test is completed, and the fixed chain environment may refer to a block chain environment which is built in advance, continuously runs, and can be repeatedly used in a plurality of rounds of execution tests. Since the intelligent contract code is eventually required to be deployed on the blockchain, the environment used for unit testing or integration testing of the second code may be a blockchain environment. However, for the sake of testing efficiency, when performing different types of execution tests on the second code, the specific adopted blockchain environment may also be different;
for example, when the second code is subjected to the cell test, a chain throwing environment can be adopted, and the block chain environment can be destroyed after being used, so that the additional maintenance investment on the block chain environment for the test can be avoided; for another example, when performing the integration test on the second code, since the integration test needs to check the support degree of the entire second code for the service, and the sufficiently simulated blockchain environment is generally complex and is not suitable for being thrown at any time, a fixed chain environment may be used to reduce the investment for repeatedly constructing the sufficiently simulated blockchain environment.
In an illustrated embodiment, the first type of test case and the second type of test case each include test cases based on different intelligent contract development frameworks; the different intelligent contract development frameworks respectively adopt different development languages. For example, in the early stage of operation, the blockchain service company AA uses the development framework frame01 that is open in the industry when developing the smart contract, uses the programming language lang01, and after a while, customizes the development framework frame02 that is private according to its business requirements, uses the programming language lang02, so that if, in a certain code quality evaluation process, some second code that needs to perform the execution test is developed by using the development framework frame01, and some is developed by using the development framework frame02, it is necessary that both of the two test cases contain test cases that use different programming languages based on the different smart contract development frameworks.
In one illustrated embodiment, the intelligent contract development framework may include a chainstack and a donut. Chainstack is a java-based intelligent contract development framework, and donut is a JavaScript-based intelligent contract development framework. Under the condition that the intelligent contract to be evaluated comprises both the content developed based on the chainstack framework and the content developed based on the donut framework, the test cases of the first type of test case and the second type of test case can be respectively developed based on the chainstack framework and the donut framework, so that the adaptability of the intelligent contract to be evaluated is ensured.
In an embodiment shown, in a case that the plurality of evaluation subtasks include the execution test subtask, the execution evaluation result corresponding to the second code may include a use case coverage rate and a use case passing rate of the second code. Generally, the coverage rate may include coverage of multiple layers, such as coverage of code blocks, coverage of logical branches, etc., which may be used to describe the proportion of the code that has undergone testing, while the use case passing rate is more biased to describe whether the code can perform business satisfactorily; the two indexes are combined, so that the accuracy of the execution evaluation result obtained by the execution test can be further improved.
In an embodiment shown, when the pipeline task for performing quality evaluation on the intelligent contract code to be evaluated is started, the intelligent contract code to be evaluated submitted by the user may be periodically acquired from the code library based on a preset timing task, and the corresponding quality evaluation pipeline task is started. For example, the intelligent contract code quality evaluation system may be equipped with a Gitlab code library, and may periodically obtain an intelligent contract code to be evaluated, which is submitted by a user, from the Gitlab code library based on a preset timing task, and start a corresponding quality evaluation pipeline task.
It is understood that the above-mentioned scheme of implementing high-instantaneity quality assessment on intelligent contract codes in a code library by timing tasks is only one feasible example; besides, those skilled in the art can set the pipeline task to be started as an instruction, or be started by an event generated by newly uploading intelligent contract code in the code base, and the like, which need not be further limited in this specification.
In an embodiment, in the case that the plurality of subtasks includes the fuzz testing subtask, the fuzz testing subtask is an asynchronous task. Generally, the above-mentioned fuzz testing process requires a large amount of random and illegal data to perform a simulation attack, and thus may consume a large amount of system resources and time; and because the dependence relationship between the subtask corresponding to the fuzzy test subsystem and other subtasks is less, the subtask corresponding to the fuzzy test subsystem can be set as an asynchronous task, so that the phenomenon that other subtasks wait for the completion of a fuzzy test link for a long time is avoided, and the resource utilization rate of the system is improved. Of course, it is understood that the subtasks that can be set as asynchronous tasks are not limited to the corresponding subtasks of the fuzz test, and the description need not be further limited.
The present specification further provides a computer device for carrying the quality evaluation system of the intelligent contract code, which at least includes a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the functions of the quality evaluation system of the intelligent contract code when executing the program.
Fig. 6 is a schematic diagram illustrating a more specific hardware structure of a computing device according to an embodiment of the present disclosure, where the computing device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present specification also provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the foregoing method for evaluating the quality of intelligent contract code.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.
Claims (21)
1. A quality assessment system for intelligent contract codes, comprising:
the production line management subsystem is used for starting a production line task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions; and further for distributing the intelligent contract code to evaluation subsystems corresponding to the plurality of subtasks, respectively;
and the plurality of evaluation subsystems are used for receiving the intelligent contract codes distributed by the pipeline management subsystem and executing corresponding subtasks in the carried execution environment.
2. The system of claim 1, further comprising:
and the result display subsystem is used for acquiring the execution results of the plurality of subtasks from the plurality of evaluation subsystems, generating the quality evaluation result corresponding to the intelligent contract code according to the execution results of the plurality of subtasks, and outputting and displaying the quality evaluation result.
3. The system of claim 2, wherein the output presentation of the quality assessment results comprises:
performing visualization processing on the quality evaluation result to obtain a corresponding quality evaluation chart;
and outputting the quality evaluation chart.
4. The system of claim 1, the smart contract code to be evaluated comprising uncompiled first code, and compiled second code of the first code;
the plurality of evaluation subsystems comprises a combination of any of the following subsystems:
the static analysis subsystem is used for carrying out static analysis on the first code based on a preset code safety rule to generate a safety evaluation result corresponding to the first code;
the execution test subsystem is used for executing a test on the second code based on a preset test case and generating an execution evaluation result corresponding to the second code;
the grammar checking subsystem is used for carrying out grammar checking on the first code and generating a corresponding grammar evaluation result;
the fuzzy test subsystem is used for carrying out fuzzy test on the second code and generating a corresponding stability evaluation result;
and the compiling subsystem is used for compiling the first code to generate the second code.
5. The system of claim 4, when the plurality of evaluation subsystems includes the execution testing subsystem, the test case comprising:
the first type of test case is used for carrying out unit test on the second code based on a ready-to-use and chain-throwing environment;
and the second type of test case is used for carrying out integration test on the second code based on a fixed chain environment.
6. The system of claim 5, wherein the first type of test case and the second type of test case each comprise test cases based on different intelligent contract development frameworks; the different intelligent contract development frameworks respectively adopt different development languages.
7. The system of claim 6, the smart contract development framework comprising a chainstack and a donut.
8. The system of claim 4, wherein when the plurality of evaluation subsystems includes the execution testing subsystem, the execution evaluation result corresponding to the second code comprises:
and the use case coverage rate and the use case passing rate of the second code.
9. The system of claim 1, the system having a code library hosted thereon; the code base is used for storing the intelligent contract codes to be evaluated, which are submitted by the user;
the starting of the pipeline task for performing quality evaluation on the intelligent contract code to be evaluated comprises the following steps:
and periodically acquiring the intelligent contract code to be evaluated submitted by the user from the code library based on a preset timing task, and starting a corresponding quality evaluation pipeline task.
10. The system of claim 4, wherein when the plurality of subsystems includes the fuzz testing subsystem, the corresponding subtask of the fuzz testing subsystem is an asynchronous task.
11. A quality evaluation method of intelligent contract codes comprises the following steps:
starting a pipeline task for performing quality evaluation on the intelligent contract code to be evaluated; the pipeline task comprises a plurality of subtasks which respectively correspond to different quality evaluation dimensions;
distributing the intelligent contract code to execution environments corresponding to the plurality of subtasks respectively;
and executing the plurality of subtasks in the execution environments corresponding to the plurality of subtasks, respectively.
12. The method of claim 11, further comprising:
acquiring the execution results of the plurality of subtasks, and generating a quality evaluation result corresponding to the intelligent contract code according to the execution results of the plurality of subtasks;
and outputting and displaying the quality evaluation result.
13. The method of claim 12, wherein the displaying the quality assessment output comprises:
performing visualization processing on the quality evaluation result to obtain a corresponding quality evaluation chart;
and outputting the quality evaluation chart.
14. The method of claim 11, the smart contract code to be evaluated comprising uncompiled first code, and compiled second code of the first code;
the executing the plurality of subtasks includes executing a combination of any of the following subtasks:
a static analysis subtask which is used for carrying out static analysis on the first code based on a preset code security rule and generating a security evaluation result corresponding to the first code;
executing a test subtask, including executing a test on the second code based on a preset test case, and generating an execution evaluation result corresponding to the second code;
the grammar checking subtask comprises the steps of carrying out grammar checking on the first code and generating a corresponding grammar evaluation result;
the fuzzy testing subtask comprises the steps of carrying out fuzzy testing on the second code and generating a corresponding stability evaluation result;
and compiling the subtask, which comprises compiling the first code to generate the second code.
15. The method of claim 14, when the plurality of evaluation subtasks includes the execution test subtask, the test case includes:
the first type of test case is used for carrying out unit test on the second code based on a ready-to-use and chain-throwing environment;
and the second type of test case is used for carrying out integration test on the second code based on a fixed chain environment.
16. The method of claim 15, wherein the first type of test case and the second type of test case each include test cases based on different intelligent contract development frameworks; the different intelligent contract development frameworks respectively adopt different development languages.
17. The method of claim 16, the smart contract development framework comprising a chainstack and a donut.
18. The method of claim 14, wherein when the plurality of evaluation subtasks includes the execution test subtask, the result of the execution evaluation corresponding to the second code comprises:
and the use case coverage rate and the use case passing rate of the second code.
19. The method of claim 11, wherein initiating pipeline tasks for quality evaluation of intelligent contract code to be evaluated comprises:
and periodically acquiring the intelligent contract code to be evaluated submitted by the user from the code library based on a preset timing task, and starting a corresponding quality evaluation pipeline task.
20. The method of claim 14, when the plurality of subtasks includes the fuzz testing subtask, the fuzz testing subtask is an asynchronous task.
21. A computer device comprising at least a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 11 to 20 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110826875.7A CN113282517A (en) | 2021-07-21 | 2021-07-21 | Quality evaluation system of intelligent contract code |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110826875.7A CN113282517A (en) | 2021-07-21 | 2021-07-21 | Quality evaluation system of intelligent contract code |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113282517A true CN113282517A (en) | 2021-08-20 |
Family
ID=77286877
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110826875.7A Pending CN113282517A (en) | 2021-07-21 | 2021-07-21 | Quality evaluation system of intelligent contract code |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113282517A (en) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109344080A (en) * | 2018-10-31 | 2019-02-15 | 江苏电力信息技术有限公司 | It is lasting to deliver and the integrated Software Quality Assurance method of automatic test |
| CN109542761A (en) * | 2018-10-11 | 2019-03-29 | 平安科技（深圳）有限公司 | Evaluation of Software Quality, device and storage medium |
| CN109684215A (en) * | 2018-12-25 | 2019-04-26 | 中国科学院电子学研究所苏州研究院 | A kind of automated software Quality System Review and iteratively faster method |
| CN109960643A (en) * | 2017-12-22 | 2019-07-02 | 网宿科技股份有限公司 | A kind of code test method and device |
| CN111444092A (en) * | 2020-03-24 | 2020-07-24 | 腾讯科技（深圳）有限公司 | Intelligent contract testing method and device, electronic equipment and storage medium |
| CN112035350A (en) * | 2020-08-27 | 2020-12-04 | 腾讯科技（深圳）有限公司 | Test method and device for block chain system and computer equipment |
| CN112527380A (en) * | 2020-12-04 | 2021-03-19 | 中国航空工业集团公司成都飞机设计研究所 | Continuous integration method oriented to embedded high-security software |
| US20210141718A1 (en) * | 2019-11-11 | 2021-05-13 | Adobe Inc. | Automated Code Testing For Code Deployment Pipeline Based On Risk Determination |
| CN112905447A (en) * | 2021-01-22 | 2021-06-04 | 支付宝(杭州)信息技术有限公司 | Test method and system for block chain virtual machine |
| CN112988594A (en) * | 2021-04-25 | 2021-06-18 | 郑州信大捷安信息技术股份有限公司 | Integrated detection method and system for code quality evaluation |
-
2021
- 2021-07-21 CN CN202110826875.7A patent/CN113282517A/en active Pending
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109960643A (en) * | 2017-12-22 | 2019-07-02 | 网宿科技股份有限公司 | A kind of code test method and device |
| CN109542761A (en) * | 2018-10-11 | 2019-03-29 | 平安科技（深圳）有限公司 | Evaluation of Software Quality, device and storage medium |
| CN109344080A (en) * | 2018-10-31 | 2019-02-15 | 江苏电力信息技术有限公司 | It is lasting to deliver and the integrated Software Quality Assurance method of automatic test |
| CN109684215A (en) * | 2018-12-25 | 2019-04-26 | 中国科学院电子学研究所苏州研究院 | A kind of automated software Quality System Review and iteratively faster method |
| US20210141718A1 (en) * | 2019-11-11 | 2021-05-13 | Adobe Inc. | Automated Code Testing For Code Deployment Pipeline Based On Risk Determination |
| CN111444092A (en) * | 2020-03-24 | 2020-07-24 | 腾讯科技（深圳）有限公司 | Intelligent contract testing method and device, electronic equipment and storage medium |
| CN112035350A (en) * | 2020-08-27 | 2020-12-04 | 腾讯科技（深圳）有限公司 | Test method and device for block chain system and computer equipment |
| CN112527380A (en) * | 2020-12-04 | 2021-03-19 | 中国航空工业集团公司成都飞机设计研究所 | Continuous integration method oriented to embedded high-security software |
| CN112905447A (en) * | 2021-01-22 | 2021-06-04 | 支付宝(杭州)信息技术有限公司 | Test method and system for block chain virtual machine |
| CN112988594A (en) * | 2021-04-25 | 2021-06-18 | 郑州信大捷安信息技术股份有限公司 | Integrated detection method and system for code quality evaluation |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109408373B (en) | Test method of intelligent contract, computer readable storage medium and test terminal | |
| CN111414172B (en) | Automatic deployment and release system and method for application software | |
| CN105389256B (en) | A kind of unit test method and system | |
| CN110007921B (en) | Code publishing method and device | |
| CN110674047B (en) | Software testing method and device and electronic equipment | |
| CN108111364B (en) | Service system testing method and device | |
| US20110016454A1 (en) | Method and system for testing an order management system | |
| CN111679984B (en) | Performance analysis method and device | |
| CN112732561A (en) | Project deployment method and device, computer equipment and storage medium | |
| CN113296787A (en) | Online development and code hosting system based on cloud platform and using method | |
| CN111767209A (en) | Code testing method, device, storage medium and terminal | |
| CN111679977A (en) | Jest-based React project unit testing method, equipment and storage medium | |
| CN112306857A (en) | Method and apparatus for testing applications | |
| Faiz et al. | Flutter framework code portability measurement on multiplatform applications with iso 9126 | |
| CN112527312B (en) | Test method and test device for embedded system | |
| CN113742215A (en) | Method and system for automatically configuring and calling test tool to perform test analysis | |
| CN112561690A (en) | Method, system, equipment and storage medium for testing credit card staging service interface | |
| US10579761B1 (en) | Method and system for reconstructing a graph presentation of a previously executed verification test | |
| CN110471828B (en) | Operating system testing method, device and equipment thereof | |
| CN113282517A (en) | Quality evaluation system of intelligent contract code | |
| CN115470141A (en) | Fault simulation method, device and related equipment | |
| CN115509913A (en) | Software automation test method, device, machine readable medium and equipment | |
| CN114817047A (en) | Compiler test method, case generation method and device and instruction storage structure | |
| CN113986263A (en) | Code automation test method, device, electronic equipment and storage medium | |
| Saini et al. | Software failures and chaos theory |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210820 |