Standard development test method for operator interface

Abstract

The invention discloses a standard development test method for an operator interface, and relates to the technical field of operator development, the method comprises the following steps: in the development stage of the operator interface, constructing a universal development code, and generating an operator interface code of a target operator based on the universal development code, the construction process of the universal development code following a prefabricated code standard; in the test stage of the operator interface, a general test code is constructed, an interface test code of a target operator is generated based on the general test code, and the construction process of the general test code follows a prefabricated code specification; code specification detection is carried out on the target code based on the prefabricated code specification, wherein the target code comprises an operator interface code and an interface test code of a target operator; and under the condition that the code specification detection is passed, storing the target code. According to the method, the standardability of the operator interface code and the interface test code can be ensured, and the development test efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of operator development technology, and in particular to a standardized development and testing method for an operator interface. Background Art

[0002] The development and design of operator interface specifications based on the chip field has been constantly evolving and improving, aiming to improve the development efficiency, development quality, computing performance and versatility of operators, and promote the widespread application of operators on different chips and hardware accelerators. In the field of artificial intelligence and machine learning, in order to achieve efficient execution and interoperability of operators, it is usually necessary to define operator interface specifications.

[0003] However, there is still a lack of unified operator interface specifications. Different deep learning frameworks and hardware accelerators use different operator interface specifications, which affects the interoperability of operators on different platforms. There is also a lack of code specifications for operator development and testing: different developers and testers have different code writing and submission habits, which affects the efficiency of operator development and testing and limits the readability and flexibility of the code. Summary of the invention

[0004] In response to the above problems and technical requirements, the applicant has proposed a standardized development and testing method for operator interfaces. The technical solution of this application is as follows:

[0005] On the one hand, a standardized development and testing method for an operator interface is provided, comprising the following steps:

[0006] During the development phase of the operator interface, a general development code is constructed, and the operator interface code of the target operator is generated based on the prefabricated code specification of the general development code, wherein the prefabricated code specification is followed during the construction of the general development code, and the prefabricated code specification includes at least one of a code format specification, a code style specification, and a parameter usage specification, and the general development code includes codes corresponding to general processes in the process of implementing different operator functions;

[0007] During the test phase of the operator interface, a general test code is constructed, and an interface test code of the target operator is generated based on the general test code, wherein the general test code construction process follows the prefabricated code specification, and the general test code includes codes corresponding to general processes in the test process of operators with different functions;

[0008] Performing code specification detection on a target code based on the prefabricated code specification, the target code including the operator interface code and the interface test code of the target operator;

[0009] When the code specification detection is passed, the target code is stored.

[0010] Among them, the further solutions are:

[0011] The generating the operator interface code of the target operator based on the general development code comprises:

[0012] Based on the operator function of the target operator, modify the operator function code block in the general development code to generate the operator interface code of the target operator, wherein the code in the operator function code block is used to implement the operator function;

[0013] The step of generating the interface test code of the target operator based on the general test code includes:

[0014] Based on the operator function of the target operator, the test function code block in the general test code is modified to generate the interface test code of the target operator, and the test function code block is used to test the operator function.

[0015] The performing code specification detection on the target code based on the prefabricated code specification includes:

[0016] In the process of passing the parameter into the target code, the passed parameter is detected based on the parameter usage specification, wherein the parameter usage specification includes a usage specification of parameter type, parameter dimension, and parameter value range;

[0017] In the process of submitting the target code, the target code is formatted based on the code format specification and / or the code style specification. The code format specification includes interface naming specifications and parameter naming specifications, and the code style specification includes code structure specifications and code comment specifications.

[0018] The performing code specification detection on the target code based on the prefabricated code specification includes:

[0019] Performing code specification detection on the target code locally based on the prefabricated code specification;

[0020] When the code specification detection passes, storing the target code includes:

[0021] When the code specification detection is passed locally, the target code is submitted to the remote repository, wherein remote code detection is triggered when the target code is submitted to the remote repository, and the remote code detection includes code quality detection and code logic detection;

[0022] When the target code passes the remote code detection, the target code is stored in the remote repository.

[0023] The locally performing code specification detection on the target code based on the prefabricated code specification includes:

[0024] The target code is locally subjected to code specification detection based on a custom detection script, wherein the custom detection script is generated according to the prefabricated code specification.

[0025] When the local code standard detection passes, submitting the target code to the remote repository includes:

[0026] If the local code standard detection is passed, the code submission information is subjected to submission standard detection, wherein the submission standard detection includes information format detection and information content detection;

[0027] In the case of the submission specification detection, the target code carrying the code submission information is submitted to the remote warehouse.

[0028] The submitting specification detection of the code submission information includes:

[0029] Based on the format type indicated in the information format specification, performing the information format detection on the code submission information;

[0030] The information content detection is performed on the code submission information based on the content requirements indicated in the information content specification.

[0031] Optionally, during the remote code detection process, code quality detection is performed on the target code through a detection platform;

[0032] And forwarding the target code to an integrator's device, wherein the integrator's device is used to display the target code to the integrator so that the integrator can perform code logic detection on the target code.

[0033] The method further comprises:

[0034] In the operator interface testing phase, a test case corresponding to the target operator is generated based on a general test case, wherein the general test utilizes a test case specification, and the test case specification includes a file format specification and a test condition specification.

[0035] The generating a test case corresponding to the target operator based on the general test case includes:

[0036] Based on the functional requirements of the target operator, the test parameters in the general test case are adjusted to obtain a specific test case for the target operator, wherein operators with different functions may use different parameters.

[0037] The beneficial technical effects of this application are:

[0038] In the embodiment of the present application, the prefabricated code specification is used to implement the constraints on the operator interface development and testing process, and after obtaining the operator interface code and the interface test code, the code is tested again based on the prefabricated code specification. Only when the test passes, the operator interface code and the interface test code are retained to ensure the standardization of the operator interface code and the interface test code. Through the unified prefabricated code specification, developers can use the unified operator interface development and testing specification to develop and design the operator interface. The standardized operator interface is easier to understand, which helps to improve the efficiency of assisted development. And through the development and testing constraints of each operator interface, it is beneficial to the portability of the operator on different platforms, which can reduce the overhead caused by data conversion and replication, and improve the performance and efficiency of the operator interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is a flow chart of an operator interface specification development and testing method provided by an exemplary embodiment of the present application;

[0040] Figure 2 It is a code quality detection result feedback diagram provided by an exemplary embodiment of the present application;

[0041] Figure 3 is a code logic detection result feedback diagram provided by an exemplary embodiment of the present application;

[0042] Figure 4 is a diagram of a code remote detection structure provided by an exemplary embodiment of the present application;

[0043] Figure 5 It is a schematic diagram of API document generation provided by an exemplary embodiment of the present application;

[0044] Figure 6 Another exemplary embodiment of the present application provides a schematic diagram of API document generation. DETAILED DESCRIPTION

[0045] The specific implementation of the present application is further described below in conjunction with the accompanying drawings.

[0046] Please refer to Figure 1 , which shows a flow chart of an operator interface specification development and testing method provided by an exemplary embodiment of the present application. The method comprises the following steps:

[0047] Step 101 , in the development phase of the operator interface, a general development code is constructed and a code specification is prefabricated based on the general development code to generate the operator interface code of the target operator.

[0048] The general development code follows the prefabricated code specification during construction, and the prefabricated code specification includes code format specification, code style specification and parameter usage specification, and the general development code includes the code corresponding to the general process in realizing different operator functions.

[0049] In the embodiment of the present application, code specifications that need to be uniformly followed during the development and testing process, namely prefabricated code specifications, are pre-formulated, so that the development code and the test code are constrained by the prefabricated code specifications to meet unified specifications.

[0050] The prefabricated code specifications include code format specifications, code style specifications, and parameter usage specifications. Among them, the code format specification refers to the specification of a unified format during the operator interface development and testing process, including the naming format, input and output format, and other specifications of each interface parameter. The code style specification is the specification of a unified style during the operator interface development and testing process, including the specifications of the writing indentation method, writing structure, and code comments. The parameter usage specification refers to the restriction specifications on the use of parameters during the development process.

[0051] In the development phase of the operator interface, the operator interface code is developed based on the prefabricated code specification to obtain the operator interface code of the target operator. In this process, the operator interface code of the target operator can be generated based on the general development code. Among them, the general development code is also a code template generated based on the prefabricated code specification. In the development process of different operator interfaces, the general development code can be modified according to the characteristics of each operator to obtain a specific operator interface code. This process can reduce repetitive development processes and improve R&D efficiency.

[0052] Step 102: In the operator interface testing phase, a general test code is constructed and based on the general test code, an interface test code of a target operator is generated.

[0053] The general test code construction process follows the prefabricated code specifications, and the general test code contains codes corresponding to the general process in the operator testing process of different functions.

[0054] In the embodiment of the present application, in the test process of the operator interface, the same prefabricated code specification as in the development process is followed. According to the prefabricated code specification, the interface test code of the target operator is generated, which is used for the interface test process of the target operator, realizing unified standard management of the development and testing process.

[0055] In the testing phase, the interface test code of the target operator is generated based on the test code. In the testing process of different operator interfaces, the general test code can be modified according to the characteristics of each operator to obtain a specific interface test code.

[0056] Step 103: Perform code specification detection on the target code based on the prefabricated code specification, where the target code includes operator interface code and interface test code.

[0057] In the above process, the process of generating the operator interface code and interface test code of the target operator follows the prefabricated code specification, but there may be some human modification processes in the generation process. In order to ensure the standardization of the operator interface code and the interface test code. In a possible implementation, the operator interface code and the interface test code are also tested according to the prefabricated code specification to determine whether the two comply with the prefabricated code specification.

[0058] During the detection process, one by one detection is performed according to the prefabricated code specifications. Optionally, when the prefabricated code specifications include code format specifications, code style specifications and parameter usage specifications, it is respectively detected whether the code format of the target code complies with the code format specifications, whether the code style complies with the code style specifications and whether the parameters used comply with the parameter usage specifications.

[0059] Step 104: if the code standard detection is passed, the target code is stored.

[0060] When the target code meets all specifications included in the prefabricated code specification, it is determined that the code specification detection passes. In this case, the target code related to the target operator can be stored for subsequent calls by developers and testers.

[0061] When part of the target code does not meet the prefabricated code specifications, it is determined that the code specification detection fails, and the reason why the code does not meet the specifications can be fed back to the developer so that the developer and tester can make modifications.

[0062] In the embodiment of the present application, the prefabricated code specification is used to implement the constraints on the operator interface development and testing process, and after obtaining the operator interface code and the interface test code, the code is tested again based on the prefabricated code specification. Only when the test passes, the operator interface code and the interface test code are retained to ensure the standardization of the operator interface code and the interface test code. Through the unified prefabricated code specification, developers can use the unified operator interface development and testing specification to develop and design the operator interface. The standardized operator interface is easier to understand, which helps to improve the efficiency of assisted development. And through the development and testing constraints of each operator interface, it is beneficial to the portability of the operator on different platforms, which can reduce the overhead caused by data conversion and replication, and improve the performance and efficiency of the operator interface.

[0063] Optionally, during the development phase of the operator interface, a general development code and an operator function based on the target operator are constructed, the operator function code block in the general development code is modified, and the operator interface code of the target operator is generated.

[0064] In the development phase, first build the general development code, which contains the code corresponding to the general computing process that implements different operator functions. Schematically, the general development code contains the following code:

[0065]

[0066]

[0067] The general development code contains the operator function code block, and the code in the operator function code block is used to implement the operator function. During the development of the target operator interface, the operator function code block in the general development code can be modified according to the functional requirements of the target operator to obtain the operator interface code corresponding to the target operator.

[0068] Indicatively, in combination with the above example, according to the operator function of the target operator, the code block related to "Base Op" in the above code is modified to obtain the operator function code block corresponding to the target operator.

[0069] In the process of code development, error information needs to be printed. When a code error or abnormal situation is found, error information that conforms to the error information specification will be automatically printed so that developers can quickly locate the problem. And a log mechanism needs to be used to record error information so that troubleshooting can be performed during code debugging.

[0070] Indicatively, when creating the descriptor of the activation function, if the activation function descriptor is empty, the error message "activationDesc is NULL" is printed in time, as shown below:

[0071]

[0072] Optionally, during the test phase of the operator interface, a general test code and an operator function based on the target operator are constructed, and the test function code block in the general test code is modified to generate an interface test code for the target operator.

[0073] Among them, the test function code block is used to test the operator function.

[0074] In the test phase of the operator interface, first build the general test code. The general test code contains the code corresponding to the general process in the test process of different operators, and the general test code contains the test function code block, which can be adjusted according to the operator functions of different operators. Schematically, the general test code contains the following code:

[0075]

[0076]

[0077] Combined with the above example, the fd.write() code block can be modified according to the operator function of the target operator to obtain the specific test code corresponding to the target operator.

[0078] The general test code also includes general code for calling test cases to use the test cases of the target operator.

[0079] Test cases for target operators can also be generated based on general test cases.

[0080] Optionally, based on a general test case, a test case corresponding to the target operator is generated, wherein the general test utilizes a test case specification, and the test case specification includes a file format specification and a test condition specification.

[0081] In the process of generating the test case corresponding to the target operator, the test parameters in the general test case are adjusted based on the functional requirements of the target operator to obtain the specific test case of the target operator, wherein operators with different functions may use different parameters.

[0082] General test cases are test cases generated according to the file format specification, which contain general test conditions, such as boundary conditions and common scenario conditions, where the general test conditions meet the test condition specifications, that is, the boundary conditions meet the boundary setting specifications, and the common scenario conditions also meet the scenario setting specifications. In principle, for a tensor that can open up a maximum memory of 2G, the boundary conditions involve test cases that open up a maximum memory of 2G and test cases that open up a minimum memory of 1, which is the memory boundary condition of the extreme test operator; and for the setting of common scenarios, the operator value is usually taken as -5 to 5, or -100 to 100, and the memory is opened from 1 to 200M. The general scenario test design will be carried out.

[0083] It can also generate general test cases for different parameter tests, set different parameter value ranges, step sizes, boundary values, etc., and use a random number generator or specify a specific parameter combination to set different parameterized test scenarios. Schematically, as shown below:

[0084]

[0085]

[0086] Among them, N, C, H, and W are common parameters of different operators. By randomizing N, C, H, and W, different common test cases are generated for common testing of various operators.

[0087] And because different operators can use different parameters, specific test cases can be added. For example, different operators support different data types, dimension information, and non-numeric processing, etc., to generate specific test cases. Specific test cases and general test cases constitute the test cases of operators. It should be noted that specific test cases are obtained by adjusting the test parameters in general test cases based on the functional requirements of operators.

[0088] Schematically, a common test case is as follows:

[0089]

[0090]

[0091] According to the parameter requirements of different operators, the parameters of the above general test cases are filled to obtain specific test cases of operators.

[0092] In this embodiment, by automating the generation of development code, test code and test cases, the workload of manual writing can be reduced and the development and testing efficiency can be improved. In addition, specific specifications are followed during the development and testing process, and the unified development and testing process specifications help improve the efficiency of assisted development.

[0093] In the above process, the process of generating development code and test code is introduced. The following will introduce the code standard detection process.

[0094] Optionally, in the process of passing parameters into the target code, the passed parameters are checked based on parameter usage specifications, where the parameter usage specifications include usage specifications of parameter types, parameter dimensions, and parameter value ranges.

[0095] Different operators use different types of parameters. Before an operator uses an input parameter, it is necessary to check the validity of the input parameter to ensure that the parameter meets the operator's requirements.

[0096] During the parameter validity check, the check is performed according to the parameter usage specifications, where the parameter usage specifications include specifications for parameter type, parameter dimension, and parameter value range. Therefore, the parameter validity check includes the check of parameter type, parameter dimension, and parameter value range. During this process, it is necessary to check whether the pointer of the input parameter is empty, whether the data type and dimension of the parameter meet the requirements, and whether the parameter value range is reasonable.

[0097] In one possible implementation, parameter requirements for different operators are preset. During the parameter validity detection process, the parameters of the input operator can be detected according to the parameter type, parameter dimension, and parameter value range required by the preset target operator. The input parameters are used if the detection passes.

[0098] Indicatively, for the activationForwardCheckArgs() function, it is necessary to check whether the TecoDNN handle, descriptor (activationDesc, xDesc, yDesc), and data (x, y, alpha, and beta) pointers are empty, and at the same time, the data types of x and y are checked for consistency. If they do not match, "TECODNN_STATUS_BAD_PARAM" is returned, and the program cannot run normally. As shown below:

[0099]

[0100] If the parameter validity check is passed, the target code is determined to meet the parameter usage specifications. If any of the parameter type, parameter dimension, and parameter value range does not meet the specifications, the target code is determined to have failed the parameter validity check, for example, the input parameter pointer is null, the input parameter type is inconsistent, the input parameter dimension is inconsistent, etc.

[0101] In the process of submitting the target code, specification checking can be performed based on either the code format specification or the code style specification, or based on both.

[0102] Optionally, based on the code format specification, the target code is checked for format specification, where the code format specification includes interface naming specifications and parameter naming specifications.

[0103] The prefabricated code specifications include code format specifications. Optionally, the code format specifications include interface naming specifications and parameter naming specifications. For operator interfaces, their names should accurately describe their functions and effects, and use the form of verbs plus nouns to express the operation and purpose of the interface. Among them, the naming method of interfaces usually uses camel case naming, that is, the first letter of each word is capitalized, and spaces or underscores are removed. Taking the TecoDNN operator library as an example, "tecodnn" or "TECODNN" is usually required as a naming prefix to identify the library to which the interface belongs, and the specific operation or attribute of the interface is used as the naming suffix. Schematically, general operators include structure types, enumeration types, computing interfaces, and non-computing interfaces.

[0104] The structure type is used to represent and configure different objects and parameters. It is usually prefixed with the operator library name, followed by the name of the specific object or parameter. For example, with the prefix tecodnn, tecodnnActivationDescriptor_t, it represents the descriptor of the activation function, which is usually used with operators, such as tecodnnCreateActivationDescriptor() (create the descriptor), tecodnnSetActivationDescriptor() (initialize the descriptor), tecodnnGetActivationDescriptor() (get the descriptor), tecodnnDestroyActivationDescriptor() (destroy the descriptor), etc.

[0105] Enumeration types are used to represent different options and configuration parameters. They are named with the operator library name as the prefix and the specific type name as the suffix.

[0106] Non-computing interfaces are often used to configure and manage other aspects of the operator library, providing control and settings for the underlying functions of the operator library, such as descriptor creation, initialization, acquisition, and destruction. The naming convention is to use the operator library name as a prefix and the specific operation type name as a suffix, such as tecodnnCreate, tecodnnSet, tecodnnGet, and tecodnnDestory.

[0107] The computing class interface is used to perform specific computing operations, such as activation, convolution, pooling, and normalization. It provides functions for computing and configures and controls the computing process through input and output descriptors and algorithm selection. Its naming convention is also prefixed with the operator library name and the specific operation type as the suffix, such as tecodnnActivationForward, which is used to perform forward activation calculations on tensors.

[0108] As for parameters, their names should be descriptive and easy to read, which helps developers understand the meaning and function of the parameters. For example, for enumeration constants and macro definitions, uppercase characters and underscores can be used for naming, which indicates the meaning and function of the parameters. Schematically, tecodnnActivationMode_t represents the data type. The names of the parameters are shown in Table 1:

[0109] Table 1

[0110] tecodnnActivationMode_t mode TECODNN_ACTIVATION_SIGMOID Sigmoid calculation TECODNN_ACTIVATION_RELU ReLU calculation TECODNN_ACTIVATION_TANH Tanh calculation TECODNN_ACTIVATION_CLIPPED_RELU Clipped relu calculation TECODNN_ACTIVATION_ELU elu calculation TECODNN_ACTIVATION_IDENTITY identity calculation TECODNN_ACTIVATION_SIGMOID_TAB Calculate the sigmoid function by looking up a table TECODNN_ACTIVATION_ELU_TAB Calculate the elu function by looking up the table TECODNN_ACTIVATION_TANH_TAB Calculate the tanh function by looking up a table TECODNN_ACTIVATION_GELU GELU calculation TECODNN_ACTIVATION_LEAKYRELU Leaky ReLU calculation TECODNN_ACTIVATION_SELU selu calculation TECODNN_ACTIVATION_RELU6 relu6 calculation TECODNN_ACTIVATION_SILU silu calculation TECODNN_ACTIVATION_GELU_APPROXIMATE Approximate calculation of gelu

[0111] For example, the naming of interface parameters can use camel case naming, with the first letter in lowercase, the first letter of each subsequent word in uppercase, and no underscores to separate them.

[0112] In the process of code standard detection, it is necessary to detect whether the interface naming and parameter naming conform to the unified specifications, that is, to perform standard detection of the interface naming specifications and parameter naming specifications.

[0113] If both the interface naming specification and the parameter naming specification meet the requirements, it is determined that the code specification detection has passed.

[0114] Optionally, based on the code style specification, the target code is checked for style specifications, where the code style specification includes code structure specifications and code comment specifications.

[0115] In order to make the code structure clear and visible, code structure specifications can be formulated in advance. In a possible implementation, the code structure specifications include code block structure alignment specifications and code indentation specifications. Among them, the code block structure alignment specifications require that the corresponding code lines in block-level structures such as functions, classes, and conditional statements must be aligned; the code indentation specifications require the use of a consistent indentation method, such as using spaces or tabs for indentation.

[0116] In order to make developers clearly understand the code functions and algorithm logic, comments can be added to the code for explanation. In one possible implementation, a code comment specification is set for the code comment method, including the specification of the comment method and the comment content. Optionally, the comment content must include file header comments and function comments. Among them, the file header comments include R&D personnel, R&D time, and R&D purpose. Schematically, the file header comments can be as follows:

[0117] #encoding:utf-8

[0118] Created on 2023-02-21

[0119] @author:xxx

[0120] Describe:Realize the function of matrix multiplication.

[0121] This includes the development time Create on 2023-02-21, the developer author, and the development purpose Describe.

[0122] Functional comments contain the functional description of each function or method. In terms of commenting, for larger code blocks, block comments can be used, and the functional description of the code block must be annotated before the first line of the code block, usually using " / / " to indicate the comment field.

[0123] Schematically, for the tecodnnActivationForward function whose function is forward activation calculation, the function is explained before the function is implemented, as shown below:

[0124] / *Function to perform forward activation* /

[0125] tecodnnStatus_t TECODNNWINAPI

[0126] tecodnnActivationForward(tecodnnHandle_t handle, tecodnnActivationDescriptor_t activationDesc, const void*alpha, consttecodnnTensorDescriptor_t xDesc, const void*x, const void*beta, consttecodnnTensorDescriptor_t yDesc, void*y){

[0127] …

[0128] Add the comment field / *Function to perform forward activation* / before the code block to indicate that the function is the forward activation calculation.

[0129] After receiving the submitted target code, the code standard is checked according to the above code structure standard and code comment standard. If the code structure does not conform to the unified code structure standard, the target code is determined to be non-compliant; or if the code comment does not conform to the unified code comment standard, the target code is determined to be non-compliant. If the code structure standard and code comment standard are both passed, the target code is determined to be compliant with the code style standard.

[0130] The above-mentioned code format detection, code style detection and parameter validity detection can be performed locally, that is, code specification detection is performed on the target code locally based on the pre-made code specification.

[0131] During the local detection process, if the format specification detection, style specification detection and parameter validity detection are passed, the target code can be submitted to the remote warehouse for storage. If any of the format specification detection, style specification detection and parameter validity detection fails, an error message can be displayed and submission of code to the remote warehouse is prohibited. Optionally, the target code is locally tested for code specifications based on a custom detection script, which is generated according to the prefabricated code specifications so as to be detected by the custom script.

[0132] In a possible implementation, a custom script can be built according to the pre-made code specification, and then the cpplint tool can be adjusted based on the custom script to implement code specification detection. Schematically, a custom script is generated for the specification requirements before the test code is submitted:

[0133] set noparent

[0134] filter=-build / c++11

[0135] filter=-build / namespace

[0136] #filter=-build / include subdir

[0137] #filter=-build / header_guard

[0138] filter=-legal / copyright

[0139] filter=-readability / alt tokens

[0140] filter=-readability / casting

[0141] filter=-readability / check

[0142] filter=-readability / nolint

[0143] filter=-runtime / int

[0144] filter=-runtime / threadsafe

[0145] filter=-whitespace / bracesfilter=-whitespace / empty_loop

[0146] bodyfilter=-whitespace / semicolon

[0147] linelength=100

[0148] These requirements include adding a copyright notice (legal / copyright) at the beginning of the code, setting a maximum of 100 characters per line of code (linelength=100), and leaving whitespace (whitespace / semicolon) after the ";" in the for loop. Custom scripts are used to implement detection based on pre-set specifications.

[0149] Optionally, when the code standard detection is passed locally, a submission standard detection is performed on the code submission information, and the submission standard detection includes information format detection and information content detection.

[0150] During the code submission process, code-related information will also be submitted to explain the code. In a possible implementation, a code information submission specification is also pre-set, and during the submission process, the code submission information is subjected to submission specification detection. The code information submission specification includes an information format specification and an information content specification, wherein the information format specification indicates the format type requirements of the submitted information, and the information content specification indicates the information content that the submitted information needs to contain. Optionally, the information content includes at least one of the submitted code type, the submitted code change range, and the submitted code change description.

[0151] During the submission specification detection process, the code submission information is subjected to the information format detection based on the format type indicated in the information format specification. In this process, the format type in the submission information can be compared with the preset format type. If they are the same, the detection passes. Schematically, the information format specification requires information submission in the format of "type(scope): subject".

[0152] Based on the content requirements indicated in the information content specification, the code submission information is tested for the information content. In this process, the information content contained in the submission information can be extracted and compared with the content contained in the preset requirements. If all the required content is contained, the test is passed.

[0153] The specific information content requirements are shown in Table 2:

[0154] Table 2

[0155]

[0156] Optionally, information format detection is performed based on the information format specification and information content detection is performed based on the information content specification. If both the information format detection and the information content detection are passed, it is determined that the submission specification detection is passed, and if the information format detection fails or the information content detection fails, it is determined that the submission specification detection fails. Schematically, in combination with the above example, in the submission specification detection, it is first detected whether the submitted information is in the "type(scope): subject" format. If the format does not match, the submission specification detection fails.

[0157] And it is also necessary to detect the information content. The detection script is as follows:

[0158]

[0159]

[0160] The detection script will detect the contents corresponding to type and scope. Type must be one of feat, fix, perf, refactor, ci, tool, docs, and test; scope must be one of blas, dnn, rand, ual, common, and op.

[0161] In the case of submission specification detection, the target code carrying the code submission information is submitted to the remote repository.

[0162] That is, when the local code specification check passes, the target code is submitted to the remote warehouse. When the target code is submitted to the remote warehouse, remote code detection is triggered, and the remote code detection includes code quality detection and code logic detection.

[0163] In a possible implementation, code submission is allowed only when the code standard detection is passed, and then the submission standard detection is performed. That is, if the local code standard detection is passed, the submission standard detection is performed on the code submission information, and the submission standard detection includes information format detection and information content detection; in the case of submission standard detection, the target code carrying the code submission information is submitted to the remote warehouse.

[0164] And to ensure the compliance of the code, after the target code is submitted to the remote warehouse, the remote server will be triggered to perform remote code detection. The detection content of the remote code detection includes code quality detection and code logic detection. Among them, the code quality detection mainly includes code specification detection, submission specification detection, code compilation unit test and code operation unit test. Among them, the code specification detection and submission specification detection are the same as the specifications adopted during local detection, that is, the specification detection is performed again remotely to ensure the compliance of the code. And in the detection process, code compilation unit test and code operation unit test are also required. If the code compilation is successful, it is determined that the code compilation unit test has passed. If the code runs successfully, it is determined that the code runs the unit test. In a possible implementation method, if the code specification detection, submission specification detection, code compilation unit test and code run unit test pass, it is determined that the code quality detection has passed.

[0165] Optionally, the target code can be tested for code quality through the testing platform, that is, the testing platform can be used to perform automated testing. In an illustrative example, the Jenkins tool can be used for code quality testing. If the code quality test passes, a normal sign will be displayed to indicate that the code quality test passes; if the code quality test fails, an abnormal sign will be displayed to indicate that the code quality test fails, and the abnormal sign can also indicate specific abnormal items, so that developers can quickly locate and troubleshoot. In an illustrative example, Figure 2 As shown, when the commit check passes, a normal mark 201 is displayed, and when the compile test fails, an abnormal mark 202 is displayed.

[0166] In addition to the above-mentioned code quality detection, it also includes code logic detection, which is used to detect whether there are logical errors and grammatical problems in the code. Optionally, code logic detection is performed by manual detection. After the target code is submitted to the remote warehouse, the remote server can forward the target code to the integrator's device, and the integrator's device is used to display the target code to the integrator so that the integrator can perform code logic detection (i.e. Code-Review) on the target code. The integrator can view the target code submitted to the remote warehouse through the integrator's device and perform code logic detection on the target code. If the detection passes, a successful detection notification can be fed back, and the distributor (code submitter) can view the notification. If the detection fails, a failure notification can be fed back, and modification suggestions can also be fed back. The distributor can modify the code according to the modification suggestions. Optionally, the success notification and the failure pass can be fed back through the score, such as "1" can be fed back in case of success, and "-1" can be fed back in case of failure.

[0167] Indicatively, Figure 3As shown, the code logic check fails, a score of "-1" 301 is displayed, and the feedback interface includes modification suggestions 302 so that the developer can make modifications.

[0168] Optionally, if the target code passes the remote code detection, the target code is stored in a remote repository.

[0169] In a possible implementation, after the target code is submitted, the target code may be temporarily stored in a remote repository. If the above-mentioned code quality test and the above-mentioned code logic test are passed, the target code is retained in the remote repository for storage.

[0170] Schematically, the process of remote code detection can be as follows Figure 4 As shown, the distributor submits the code and submits the target code to the remote repository Gerrit. The remote server forwards the code submitted to Gerrit to the detection platform Jenkins and the integrator. The integrator performs code logic detection on the target code and feeds the detection results back to Gerrit. The detection platform Jenkins performs code quality detection and feeds the detection results back to Gerrit. When the code logic detection and code quality detection are passed, the target code is uploaded to the gitlab server for storage.

[0171] In this embodiment, by formulating prefabricated code specifications, the development team can unify the design and use of interfaces, reduce cognitive differences between developers, and reduce unnecessary communication and coordination costs. Developers can understand and use operator interfaces faster, speed up development progress, reduce errors and debugging time, and improve development efficiency. And the standardized operator interface design allows better integration and reuse between different modules, encouraging modularization and abstraction of operators. By splitting operators into independent functional units and defining clear interface constraints, the operator library is easier to expand and maintain. This modular design also promotes code reuse and teamwork. Developers can more easily understand and use interfaces written by others, reduce learning costs, and promote the sharing of operator interfaces, improving the efficiency of collaboration and code sharing between teams.

[0172] During the development process, development documents need to be generated to introduce the development process. Optionally, the development documents mainly include requirement analysis documents, solution design documents, and test design documents, where the requirement analysis document is used to indicate the functional requirement analysis of the operator, the solution design document is used to indicate the development process based on the operator function, and the test design document is used to indicate the testing process based on the operator function. In order to generate development documents that meet the specifications, in one possible implementation, a template can be pre-set and the document can be generated based on the template, thereby achieving the unification of document specifications.

[0173] Optionally, a development document of the target operator is generated based on a development document template, wherein the development document template includes at least one of a requirement analysis template, a solution design template, and a test design template.

[0174] When generating documents, you can select templates based on your needs. That is, when generating a requirements analysis document, you can select a requirements analysis template; when generating a solution design document, you can select a solution design template; when generating a test design document, you can select a test design template. By generating unified and standardized documents, it is convenient for team members to review and provide feedback, ensuring the traceability and standardization of the documents.

[0175] After the development is completed, an application programming interface (API) document needs to be generated to describe the operator interface, including interface description, parameter description, and examples of the operator interface usage, so as to better understand and use the operator interface and promote code collaboration and sharing.

[0176] Among them, standardized API documentation is mainly achieved through Doxygen and Sphinx tools. First, Doxygen is used to capture the comment information in the code and generate xml structured content; then Doxyrest is used to convert the xml format into the rst format natively supported by Sphinx, and the myst_parser plug-in is used to add support for Markdown syntax. The Sphinx framework can be used to generate the html web version and pdf offline version of the API documentation. Due to the unified code comment specifications, it is conducive to the capture of code comment information, thereby generating standardized API documentation.

[0177] Indicatively, Figure 5 As shown, code file comments 501 (including function functions and function parameter comments) are captured by Doxygen, and API documents 502 can be generated according to the code file comments 501 to introduce the function functions and parameters.

[0178] For complex functional interfaces, graphic documents can be generated in combination with diagrams to introduce specific calculation principles and steps for easier understanding.

[0179] like Figure 6 As shown, it shows an API document that introduces matrix multiplication operations, and explains them through a combination of pictures and texts, making it easier for readers to understand the interface functions and principles.

[0180] In this embodiment, by generating a standardized API document, the functions and principles of the developed operator interface can be clearly introduced, which facilitates the use of the operator interface.

[0181] The above is only a preferred embodiment of the present application, and the present application is not limited to the above embodiments. It is understood that other improvements and changes directly derived or associated by those skilled in the art without departing from the spirit and concept of the present application should be considered to be included in the protection scope of the present application.

Claims

1. A standard development and testing method for an operator interface, characterized in that: The method comprises: In the development stage of the operator interface, a general development code is constructed, and the operator interface code of the target operator is generated based on the general development code. The general development code construction process follows the prefabricated code specification, which includes code format specifications, code style specifications, and parameter usage specifications. The general development code includes codes corresponding to the general process in the process of implementing different operator functions. In the test phase of the operator interface, a general test code is constructed, and an interface test code of the target operator is generated based on the general test code. The general test code construction process follows the prefabricated code specification, and the general test code contains codes corresponding to the general process in the test process of operators with different functions; Performing code specification detection on a target code based on the prefabricated code specification, the target code including the operator interface code and the interface test code of the target operator; When the code specification detection is passed, the target code is stored.

2. The method according to claim 1, characterized in that The generating the operator interface code of the target operator based on the general development code comprises: Based on the operator function of the target operator, modify the operator function code block in the general development code to generate the operator interface code of the target operator, wherein the code in the operator function code block is used to implement the operator function; The generating the interface test code of the target operator based on the general test code comprises: Based on the operator function of the target operator, the test function code block in the general test code is modified to generate the interface test code of the target operator, and the test function code block is used to test the operator function.

3. The method according to claim 1, characterized in that The performing code specification detection on the target code based on the prefabricated code specification includes: In the process of passing the parameter into the target code, the passed parameter is detected based on the parameter usage specification, wherein the parameter usage specification includes a usage specification of parameter type, parameter dimension, and parameter value range; In the process of submitting the target code, the target code is checked for compliance based on the code format specification and / or the code style specification, wherein the code format specification includes interface naming specifications and parameter naming specifications, and the code style specification includes code structure specifications and code comment specifications.

4. The method according to any one of claims 1 to 3, characterized in that: The performing code specification detection on the target code based on the prefabricated code specification includes: Performing code specification detection on the target code locally based on the prefabricated code specification; When the code specification detection passes, storing the target code includes: When the code specification detection is passed locally, the target code is submitted to the remote repository, wherein the remote code detection is triggered when the target code is submitted to the remote repository, and the remote code detection includes code quality detection and code logic detection; When the target code passes the remote code detection, the target code is stored in the remote repository.

5. The method according to claim 4, characterized in that The locally performing code specification detection on the target code based on the prefabricated code specification includes: The target code is locally subjected to code specification detection based on a custom detection script, wherein the custom detection script is generated according to the prefabricated code specification.

6. The method according to claim 4, characterized in that When the local code standard detection passes, submitting the target code to the remote repository includes: If the local code standard detection is passed, the submission standard detection is performed on the code submission information, and the submission standard detection includes information format detection and information content detection; In the case of the submission specification detection, the target code carrying the code submission information is submitted to the remote warehouse.

7. The method according to claim 6, characterized in that The submitting specification detection of the code submission information includes: Based on the format type indicated in the information format specification, performing the information format detection on the code submission information; The information content detection is performed on the code submission information based on the content requirements indicated in the information content specification.

8. The method according to claim 4, characterized in that During the remote code detection process, the target code is subjected to code quality detection through a detection platform; And forwarding the target code to an integrator's device, wherein the integrator's device is used to display the target code to the integrator so that the integrator can perform code logic detection on the target code.

9. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: In the operator interface testing phase, a test case corresponding to the target operator is generated based on a general test case, wherein the general test utilizes a test case specification, and the test case specification includes a file format specification and a test condition specification.

10. The method according to claim 9, characterized in that The generating a test case corresponding to the target operator based on the general test case includes: Based on the functional requirements of the target operator, the test parameters in the general test case are adjusted to obtain a specific test case for the target operator, wherein operators with different functions may use different parameters.

Images