Software deliverable quality examination method and system

Abstract

The invention relates to the technical field of software testing, and provides a software deliverable quality examination method and system. The method comprises the following steps: performing format analysis on the content of the software deliverable according to the organization structure of the software deliverable, and constructing the context of an examination tool; setting an examination rule configuration attribute; the review rule configuration attributes comprise a unique identifier of the review rule, a classification to which the review rule belongs, a Boolean flag bit for identifying starting and stopping of the review rule, a rule brief description of the review rule and an implementation class name of the specific review rule; and based on the context of the review tool and the interface for inputting the unified rule, according to the review rule configuration attribute, combining the configuration file of the report to be generated and the check failure item, and according to the report template, generating the review report. The inspection efficiency and the automation degree of the deliverable can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular, to a method and system for quality review of software deliverables. Background Art

[0002] The statements in this part merely provide background technical information related to the present invention and do not necessarily constitute prior art.

[0003] With the development of the software industry and the deepening of digital transformation, large-scale software (such as ERP systems) still faces huge challenges when dealing with increasing customer requirements and fast-response delivery requirements. First, large-scale management software itself is huge in scale and complex in business logic. Its deliverables are not limited to core front-end and back-end codes, but also include various resources, data files, configuration files, etc., and the test workload is huge. At the same time, customer requirements now mostly adopt an agile iterative release strategy, so the high-frequency release rhythm also puts higher requirements on the test efficiency of deliverables. Facing such a huge test workload and test efficiency requirements, how to ensure the submission quality of deliverables is particularly important. If only relying on manual review of deliverables, not only is the efficiency slow but also unreliable. And the technical implementations of software systems of different manufacturers vary greatly, and there is no general review tool that can fully meet the quality review requirements of specific software deliverables in all aspects. Summary of the Invention

[0004] In order to solve the technical problems existing in the above background art, the present invention provides a method and system for quality review of software deliverables, which provides a comprehensive standard for the quality review of software deliverables, can customize review rules according to the development specifications, deliverable specifications formulated by the enterprise, and the specific form of deliverables, and quickly generates a review report after batch execution for developers and testers to identify and modify problems, greatly improving the review efficiency and automation degree of deliverables.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions:

[0006] The first aspect of the present invention provides a method for quality review of software deliverables.

[0007] A method for quality review of software deliverables includes:

[0008] Parsing the format of the content of the software deliverable according to the organizational structure of the software deliverable to construct a review tool context;

[0009] Setting review rule configuration attributes; the review rule configuration attributes include the unique identifier of the review rule, the category to which the review rule belongs, a boolean flag bit indicating the enablement and disablement of the review rule, a brief description of the review rule, and the class name of the implementation of the specific review rule;

[0010] Based on the context of the review tool, an interface for inputting unified rules configures attributes according to the review rules, combines with the configuration file of the report to be generated, checks the non - passing items, and generates a review report according to the report template; the configuration file of the report to be generated includes: the unique identifier of the review rule, the unique number of the review rule, the semantic brief description of the review rule, the problem category that the problems detected by the review rule will lead to, the severity level of the problems detected by the review rule, the modification deadline of the problems detected by the review rule, and the repair suggestions for the problems detected by the review rule.

[0011] Further, the report template includes: rule number, patch file name, rule semantic brief description, list of existing problems, repair suggestions for the problems, problem category, problem level, and problem modification time limit.

[0012] Further, the non - passing items for inspection include: the unique identifier of the review rule, the file name of the software deliverable, the problem phenomenon, and the specific software deliverable.

[0013] Further, the review rules include: (1) The name of the software deliverable does not contain: space, select, delete, from, and xss; (2) The name of the jar file in the software deliverable cannot contain snapshot and version number; (3) The js file in the software deliverable cannot contain debugger statements; (4) The software deliverable cannot contain files that cause user configuration information to be overwritten; (5) Check whether the data files carried by the software deliverable are legal according to the module to which the software deliverable belongs; (6) Conduct a security vulnerability check on third - party jar files; (7) The data files in the software deliverable do not contain operation sql for system tables; (8) The data protection columns of the data files in the software deliverable should be correctly set; (9) Check whether the fields of the backend data structure are consistent with the fields of the database table structure and whether the field types are consistent.

[0014] Further, the organizational structure of the software deliverable is a patch with its own format, and the patch includes a file list and a specific file set; the file list includes: basic information of the patch, files included in the patch, and the deployment path, operation method, and operation steps of the files. The basic information of the patch includes: the module to which it belongs, patch type, patch number, and patch name; the specific file set includes: files with standard formats and files with the software system's own format. The files with standard formats include: backend files, frontend files, data files, and data structure files. The files with the software system's own format include: system - defined database table structure description files, data files with the software system's own format, and metadata files.

[0015] Further, the review tool context includes: a list set of parsed patch information, and the list set of patch information includes: the physical storage path of the patch file, the physical decompression path of the patch file, the entity class object generated by deserializing the manifest file in the patch, and various types of file lists.

[0016] The second aspect of the present invention provides a software deliverable quality review system.

[0017] A software deliverable quality review system includes:

[0018] A parsing and construction module, which is configured to: parse the format of the content of the software deliverable according to the organizational structure of the software deliverable, and construct a review tool context;

[0019] An attribute setting module, which is configured to: set review rule configuration attributes; the review rule configuration attributes include the unique identifier of the review rule, the classification to which the review rule belongs, a boolean flag bit indicating the enabling and disabling of the review rule, a brief description of the review rule, and the implementation class name of the specific review rule.

[0020] A report generation module, which is configured to: based on the review tool context, input an interface with unified rules, according to the review rule configuration attributes, in combination with the configuration file of the report to be generated, check the non-compliant items, and generate a review report according to the report template; the configuration file of the report to be generated includes: the unique identifier of the review rule, the unique number of the review rule, a semantic brief description of the review rule, the problem category that the problems detected by the review rule will cause, the severity level of the problems detected by the review rule, the modification deadline of the problems detected by the review rule, and the repair suggestions for the problems detected by the review rule.

[0021] The third aspect of the present invention provides a computer device, which includes:

[0022] A processor, adapted to execute a computer program;

[0023] A computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by the processor, the steps in the software deliverable quality review method described in the first aspect above are implemented.

[0024] The fourth aspect of the present invention provides a computer-readable storage medium, which stores a computer program, and the computer program is adapted to be loaded and executed by a processor to implement the steps in the software deliverable quality review method described in the first aspect above.

[0025] The fifth aspect of the present invention provides a computer program product or a computer program.

[0026] The present invention provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in the software delivery quality review method described in the first aspect above.

[0027] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0028] The present invention provides a software delivery quality review method and system, which performs format parsing on the content of a software delivery according to the organizational structure of the software delivery to construct a review tool context; sets review rule configuration attributes; based on the review tool context, inputs an interface with unified rules, and according to the review rule configuration attributes, combines a configuration file of a report to be generated to check non-conforming items, and generates a review report according to a report template; the present invention can refer to development specifications and delivery specifications formulated by an enterprise, etc., and customize review rules that meet actual review requirements for specific delivery forms. After the tool configures these review rules, it can perform batch reviews on the deliveries, automatically collect non-conforming items and generate a review report, helping relevant personnel to troubleshoot problems and improving the review efficiency and automation degree of the deliveries. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The accompanying drawings forming a part of the present invention are used to provide a further understanding of the present invention. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention.

[0030] Figure 1 is a flowchart of the software delivery quality review method shown in an embodiment of the present invention;

[0031] Figure 2 is a framework diagram of the software delivery quality review method shown in an embodiment of the present invention;

[0032] Figure 3 is a structural diagram of the software delivery quality review system shown in an embodiment of the present invention;

[0033] Figure 4 is a structural diagram of the computer device shown in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0035] It should be noted that the following detailed description is illustrative and is intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs.

[0036] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular forms are also intended to include the plural forms. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they specify the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0037] Figure 1 is a flowchart of a method for reviewing the quality of software deliverables shown in an embodiment of the present invention. As Figure 1 shown, it includes:

[0038] Parse the format of the content of the software deliverable according to the organizational structure of the software deliverable, and construct the context of the review tool.

[0039] Set the review rule configuration attributes.

[0040] Based on the context of the review tool, input the interface of the unified rule, and according to the review rule configuration attributes, combined with the configuration file of the report to be generated, check the non-passing items, and generate a review report according to the report template.

[0041] The present invention can refer to the development specifications and deliverable specifications formulated by enterprises, etc., and customize the review rules that meet the actual review needs for specific deliverable forms. After the tool configures these review rules, it can conduct batch reviews on the deliverables, automatically collect the non-passing items of the review, and generate a review report to help relevant personnel troubleshoot problems and improve the review efficiency and automation degree of the deliverables.

[0042] Figure 2 is a framework diagram of the method for reviewing the quality of software deliverables shown in an embodiment of the present invention;

[0043] In some embodiments, the step of parsing the format of the content of the software deliverable according to the organizational structure of the software deliverable and constructing the context of the review tool; the specific method includes:

[0044] Parse the format of the content of the deliverable according to the organizational form of the specific deliverable, sort out various types of files in the deliverable, and construct the context required for the tool to review the deliverable.

[0045] When the deliverables of large-scale software are released externally, they are usually packaged into a patch in a proprietary format. It can be considered that the patch is the organizational structure of the software deliverables, and the patch usually contains a file list and a specific file set.

[0046] File list: It not only records the basic information of the patch itself (such as the module it belongs to, patch type, patch number, patch name, etc.), but also records the files included in the patch, as well as information such as the deployment path, operation method, operation steps of the files, and so on.

[0047] In one or more embodiments, the specific file set of the deliverables included in the patch includes not only files in standard formats, such as backend files (jar), frontend files (html, js, CSS), data files (DML), data structure files (DDL); but also a large part are files in the proprietary format of the software system, such as system-customized database table structure description files, system-proprietary data files, metadata files, etc. These files also need to undergo quality reviews.

[0048] The constructed tool context (PatchCheckContext) mainly contains a list collection (List) of the parsed patch information <patchinfo>), where the attributes included in the information (PatchInfo) of each patch are shown in Table 1:

[0049] Table 1 Attributes included in the information of each patch

[0050]

[0051]

[0052] In one or more embodiments, based on the review tool context, an interface for inputting unified rules is used to set review rule configuration attributes. The specific method includes:

[0053] Implement the logic of the review rules with reference to the specification. To achieve the above purpose, the review rules need to follow the unified rule interface standard ICheckRuleHandler, which includes two methods: handle and getCheckRule.

[0054] Among them, the handle method is the method for executing the rule check logic. The input parameter is the context object (PatchCheckContext) constructed when parsing the deliverable file, and the return value is the set of items that fail the check (List <checkfaileditem>)。The attributes included in the CheckFailedItem are shown in Table 2:

[0055] Table 2 Attributes included in the CheckFailedItem

[0056]

[0057]

[0058] In some embodiments, the getCheckRule method: obtains the configuration items of the review rule. This method has no parameters, and the return value is a rule configuration object (CheckRuleConfig).

[0059] Among them, when the specific review rule implements the rule handling method handle of the rule interface standard ICheckRuleHandler, by accessing the incoming context object PatchCheckContext, it can traverse the information (PatchInfo) of each patch file, and then perform logical implementation according to the requirements of the specific specification. During the process, the content that fails the check is constructed into an object of the CheckFailedItem and returned uniformly.

[0060] In a possible implementation manner, in order to ensure the quality of software products, enterprises will formulate unified development specifications, secure coding specifications, deliverable production specifications and other documents to guide the development of software and the production of deliverables. However, the specifications of these document formats cannot forcibly restrict the coding of developers and the production of product deliverables. Therefore, it is necessary to identify the important items in the specifications and implement them into executable review rules to perform mandatory checks on the deliverables. Currently, there are more than sixty review rules identified from the specifications for deliverables, as shown in Table 3 for example:

[0061] Table 3 Partial review rules for deliverables

[0062]

[0063]

[0064]

[0065] In addition, there are many other rules, such as:

[0066] (1) In the data files of the deliverables, there should be no operation SQL statements on system tables such as dba_tables, dba_all_tables, all_tables, all_all_tables, user_all_tables, all_indexes, and all_views, because these tables can expand the query results and may retrieve tables in other tablespaces, resulting in SQL logic errors.

[0067] (2) The data files in the deliverables should correctly set the protection columns for the data to protect the user's data columns and prevent the user data from being overwritten.

[0068] (3) Check whether the fields of the backend data structure are consistent with those of the database table structure, and whether the field types are consistent. Inconsistencies will cause functional errors.

[0069] In particular, the implementation logic of specific specifications can not only be implemented by self-coding. Some very professional inspection rules can also be assisted in completion by calling open-source tools. For example, for the review rule of "checking whether there are security vulnerabilities in the third-party components included in the patch", the tool first checks whether there is a jar file of the third-party component in the patch in the rule implementation logic. If there is, it will call the open-source tool for checking security vulnerabilities to scan these jar files, and the open-source tool will generate its own inspection result files. After the review tool obtains these inspection result files from the specified directory, it reads and parses these result files, extracts the security vulnerability information that appears in the result files, and then packages and converts it into the standard return value List of the handle method. <checkfaileditem>in the form of

[0070] In one or more embodiments, a review rule configuration attribute is set. The specific method includes:

[0071] After implementing the logic of the review rule, the review rule is configured in the tool. The tool holds a list file of review rule configuration items. Each review rule will have a corresponding configuration item (CheckRuleConfig) for implementing information configuration and enabling / disabling control of the review rule. Its main attributes are shown in Table 4:

[0072] Table 4 Main attributes of the configuration item

[0073]

[0074]

[0075] Specifically, when the tool executes, it first reads the review rule configuration list, filters all review rule configuration items in the enabled state according to the enable attribute, then reflects and loads the implementation class of the review rule according to the impl attribute, passes the constructed tool context PatchCheckContext into the handle method and executes the handle method, and then returns the return value List of the handle method <checkfaileditem>Collected together.

[0076] In one or more embodiments, based on the review tool context, an interface for inputting unified rules configures attributes according to review rules, combines with the configuration file of the report to be generated, checks the non-passing items, and generates a review report according to the report template. The specific method includes:

[0077] Generate a review report from the set of non-passing items summarized after the review rules are executed. To achieve the above purpose, first, the tool needs to read the configuration file of the report columns, which describes the column information that the review rules need to display in the report. The attributes of the nodes (ReportConfigItem) of the configuration file are shown in Table 5:

[0078] Table 5 Attributes of the nodes of the configuration file

[0079]

[0080]

[0081] After obtaining all the report column configuration items (ReportConfigItem) of the review rules, traverse the set of non-passing items summarized by the tool (List <checkfaileditem>) Each item that fails the check (CheckFailedItem) is converted into a report item (ReportItem) by matching the rule ID attribute and combining it with the report column configuration item (ReportConfigItem). The attributes of the report item are specifically shown in Table 6 as follows:

[0082] Table 6 Attributes of the Report Item

[0083]

[0084]

[0085] In some embodiments, the html template file of the review report preset in the reading tool is read. In this template file, the report content is presented in the form of an html table. The columns of the html table are "Rule Number", "Patch Name", "Rule Name", "Existing Problem", "Repair Suggestion", "Problem Category", "Problem Level", and "Modification Time Limit". The tool will use the report item set summarized in the previous step (List <reportitem>Traverse in sequence, read the attributes of each report item (ReportItem), then organize each column using <>, and then organize the rows of the html table using . Each report item corresponds to generating a row of the html table. Finally, splice the html fragment of the table into the html template of the review report and save it as an html file named "Deliverable Review Report".

[0086] A specific example of the implementation scenario is as follows: The backend of a software system is developed using Java. The file type of the deliverables submitted by the backend is a jar file. When the jar file is released externally, it cannot be a snapshot version and cannot carry a version number. Because if either of the above two situations occurs, when updating the patch, the file cannot be replaced due to inconsistent jar file names, resulting in the possibility that the latest jar file may not be loaded after the service starts. Therefore, we need to implement the rule "The jar file name should not contain the snapshot keyword and version number" to check for potential problems in the deliverables.

[0087] First, obtain the set of submitted patch files, decompress each patch file, obtain the file list and parse its content, and then sort out the set of files of each type included in each patch. In this embodiment, the deliverable files of the jar type will be the focus. In this embodiment, there is a patch file named "Improve Function A.zip", and the patch contains two jar files, namely module-service-api-0.1.0-SNAPSHOT.jar and module-service-core-0.3.0.jar.

[0088] Then, define the implementation class JarFileCheckHandler with reference to the meaning of the rule "The jar file name should not contain the snapshot keyword and version number". This class implements the review rule standard interface ICheckRuleHandler. In the handle method, the PatchCheckContext context object passed in through the method parameter can traverse the information of each patch to check whether the patch contains files of the jar type. If the patch contains files of the jar type, then read the file name of the jar file, and use keyword matching to determine whether the file name contains the SNAPSHOT keyword, and use regular expressions to determine whether it contains a version number. If it is found during the inspection that the file name of a jar file contains the SNAPSHOT keyword or contains a version number, then construct a CheckFailedItem for the failed inspection to describe the problem.

[0089] When the tool executes this rule through reflection of the implementation class, for the patch file "Improve Function A.zip", it checks the two jar files, module-service-api-0.1.0-SNAPSHOT.jar and module-service-core-0.3.0.jar, included in this patch. It is found that the file name of module-service-api-0.1.0-SNAPSHOT.jar contains the keyword SNAPSHOT and the version number, and the file name of module-service-core-0.3.0.jar contains the version number. Therefore, a check failure item (CheckFailedItem) is included in the returned set, and its attribute content is shown in Table 7:

[0090] Table 7 Attributes of the Failure Item

[0091]

[0092]

[0093] Meanwhile, the following configuration node should also be added to the configuration file of the report item column of the tool:

[0094] {

[0095] "ruleId":"PFR003",

[0096] "ruleCode":"Patch_File_Jar0001",

[0097] "ruleName":"The jar file name should not contain the snapshot keyword and the version number",

[0098] "problemCategory":"Development Specification",

[0099] "problemLevel":"Level Two",

[0100] "repairDeadline":"Modify in the current patch",

[0101] "repairSuggestion":"Snapshot is an informal version and should not be released as a deliverable"

[0102] }

[0103] The item that fails the check (CheckFailedItem) is uniquely identified by a rule named "PFR003". The above-mentioned newly added node can be matched in the report item column configuration file, and then this item that fails the check is converted into a report item (ReportItem), and its attribute content is as shown in Figure 8:

[0104] Table 8 Attributes of Report Items

[0105]

[0106]

[0107] Finally, this report item is converted into a table fragment using tags and combined with the html template of the review report to form an html file of the review report for display.

[0108] The above combination Figure 1 has introduced in detail the software deliverable quality review method provided by the embodiments of the present invention. Next, the software deliverable quality review system provided by the embodiments of the present invention will be introduced in combination with the accompanying drawings.

[0109] Figure 3 is a schematic structural diagram of the software deliverable quality review system shown in the embodiments of the present invention. Referring to Figure 3 , the system described in the present invention includes:

[0110] A parsing and construction module, which is configured to: parse the format of the content of the software deliverable according to the organizational structure of the software deliverable and construct a review tool context;

[0111] An attribute setting module, which is configured to: set review rule configuration attributes; the review rule configuration attributes include the unique identifier of the review rule, the classification to which the review rule belongs, a boolean flag bit indicating the enablement and disablement of the review rule, a brief description of the review rule, and the class name of the implementation of the specific review rule;

[0112] A report generation module, which is configured to: based on the review tool context, input an interface of a unified rule, and according to the review rule configuration attributes, in combination with the configuration file of the report to be generated and the items that fail the check, generate a review report according to the report template; the configuration file of the report to be generated includes: the unique identifier of the review rule, the unique number of the review rule, a semantic brief description of the review rule, the problem category that the problem detected by the review rule will cause, the severity level of the problem detected by the review rule, the modification deadline of the problem detected by the review rule, and the repair suggestion for the problem detected by the review rule.

[0113] In some embodiments, the report template includes: rule number, patch file name, brief description of rule semantics, list of existing problems, suggestions for fixing problems, problem category, problem level, and problem modification time limit.

[0114] In some embodiments, the non-compliant items include: the unique identifier of the review rule, the file name of the software deliverable, the problem phenomenon, and the specific software deliverable.

[0115] In some embodiments, the review rules include: (1) the name of the software deliverable does not contain: space, select, delete, from, and xss; (2) the jar file name in the software deliverable cannot contain snapshot and version number; (3) the js file in the software deliverable cannot contain debugger statements; (4) the software deliverable does not contain files that cause user configuration information to be overwritten; (5) check whether the data files carried by the software deliverable according to the module it belongs to are legal; (6) perform security vulnerability checks on third-party jar files; (7) the operation sql of the system table is not included in the data files of the software deliverable; (8) the protection columns of the data should be correctly set in the data files of the software deliverable; (9) check whether the fields of the backend data structure are consistent with the fields of the database table structure and whether the field types are consistent.

[0116] In some embodiments, the organizational structure of the software deliverable is a patch with its own format, and the patch includes a file list and a specific file set; the file list includes: basic information of the patch, files included in the patch, and the deployment path, operation method, and operation steps of the files. The basic information of the patch includes: the module it belongs to, patch type, patch number, and patch name; the specific file set includes: files with standard format and files with the own format of the software system. The files with standard format include: backend files, frontend files, data files, and data structure files. The files with the own format of the software system include: system-defined database table structure description files, data files with the own format of the system, and metadata files.

[0117] In some embodiments, the review tool context includes: a list set of parsed patch information. The list set of patch information includes: the physical storage path of the patch file, the physical decompression path of the patch file, the entity class object generated by deserializing the manifest file in the patch, and various types of file lists.

[0118] According to the embodiments of the present invention, the software deliverable quality review system can correspond to execute the methods described in the embodiments of the present invention, and the above and other operations and / or functions of each module of the software deliverable quality review system are respectively for the purpose of achieving Figure 1 The corresponding processes of the various methods in [it] are not described herein again for the sake of brevity.

[0119] See Figure 4 the structural diagram of the computer device shown in [it]. The computer device includes a processor, a communication interface, and a computer-readable storage medium. Among them, the processor, the communication interface, and the computer-readable storage medium can be connected through a bus or other means. Among them, the communication interface is used to receive and send data. The computer-readable storage medium can be stored in the memory of the computer device. The computer-readable storage medium is used to store a computer program, and the computer program includes program instructions. The processor is used to execute the program instructions stored in the computer-readable storage medium. The processor (or CPU (Central Processing Unit, central processing unit)) is the computing core and control core of the computer device, and it is suitable for implementing one or more instructions. Specifically, it is suitable for loading and executing one or more instructions to implement the corresponding steps in the embodiment of the software delivery item quality review method.

[0120] This embodiment provides a computer-readable storage medium (Memory). The computer-readable storage medium is a memory device in the computer device and is used to store programs and data. It can be understood that the computer-readable storage medium here can include both the built-in storage medium in the computer device and, of course, the extended storage medium supported by the computer device. The computer-readable storage medium provides a storage space, and this storage space stores the processing system of the computer device.

[0121] Moreover, one or more instructions suitable for being loaded and executed by the processor are also stored in this storage space. These instructions can be one or more computer programs (including program codes). It should be noted that the computer-readable storage medium here can be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory; optionally, it can also be at least one computer-readable storage medium located far from the aforementioned processor.

[0122] In one embodiment, one or more instructions are stored in the computer-readable storage medium; the processor loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the embodiment of the above software delivery item quality review method.

[0123] This embodiment provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the corresponding steps in the embodiment of the above software delivery quality review method.

[0124] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of an embodiment implemented by hardware, a software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) containing computer-usable program code.

[0125] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing devices to generate a machine, so that the instructions executed by the processors of the computer or other programmable data processing devices generate a device for implementing the functions specified in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0126] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements the functions specified in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0127] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0128] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0129] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.< / reportitem> < / checkfaileditem> < / checkfaileditem> < / checkfaileditem> < / checkfaileditem> < / patchinfo>

Claims

1. A software deliverable quality review method, characterized in that Including: Parsing the content of the software deliverables according to the organizational structure of the software deliverables to construct the review tool context; Setting the review rule configuration attributes; The review rule configuration attributes include the unique identifier of the review rule, the classification to which the review rule belongs, the boolean flag bit indicating the enablement and disablement of the review rule, the brief description of the review rule, and the name of the implementation class of the specific review rule; Based on the review tool context, inputting the interface of the unified rule, and according to the review rule configuration attributes, combining with the configuration file of the report to be generated, checking the non-conforming items, and generating a review report according to the report template; The configuration file of the report to be generated includes: the unique identifier of the review rule, the unique number of the review rule, the semantic brief description of the review rule, the problem category that the problems detected by the review rule will cause, the severity level of the problems detected by the review rule, the modification deadline of the problems detected by the review rule, and the repair suggestions for the problems detected by the review rule.

2. The software deliverable quality review method according to claim 1, characterized in that The report template includes: rule number, patch file name, rule semantic brief description, list of existing problems, repair suggestions for problems, problem category, problem level, and problem modification timeliness.

3. The software deliverable quality review method according to claim 1, wherein The non-conforming items checked include: the unique identifier of the review rule, the file name of the software deliverable, the problem phenomenon, and the specific software deliverable.

4. The software deliverable quality review method according to claim 3, characterized in that The review rules include: (1) The name of the software deliverable does not contain: space, select, delete, from, and xss; (2) The jar file name in the software deliverable cannot contain snapshot and version number; (3) The js file in the software deliverable cannot contain debugger statements; (4) The software deliverable cannot contain files that cause the user configuration information to be overwritten; (5) Check whether the data files carried by the software deliverable according to the module to which it belongs are legal; (6) Conduct security vulnerability checks on third-party jar files; (7) The operation sql of the system table is not included in the data files of the software deliverable; (8) The protection columns of the data in the data files of the software deliverable should be correctly set; (9) Check whether the fields of the backend data structure are consistent with the fields of the database table structure and whether the field types are consistent.

5. The software delivery quality review method according to claim 1, wherein The organizational structure of the software deliverable is a patch with its own format, and the patch includes a file list and a specific file set; the file list includes: the basic information of the patch, the files carried in the patch, and the deployment path, operation method, and operation steps of the files. The basic information of the patch includes: the module to which it belongs, the patch type, the patch number, and the patch name; the specific file set includes: files with standard formats and files with the self-defined format of the software system. The files with standard formats include: backend files, frontend files, data files, and data structure files. The files with the self-defined format of the software system include: system-defined database table structure description files, system self-defined data files, and metadata files.

6. The software deliverable quality review method according to claim 1, wherein The review tool context includes: a list set of parsed patch information, and the list set of patch information includes: the physical storage path of the patch file, the physical decompression path of the patch file, the entity class object generated by deserializing the manifest file in the patch, and various types of file lists.

7. A software deliverable quality review system, characterized in that, including: a parsing and construction module configured to: parse the content of the software delivery according to the organizational structure of the software delivery and construct the review tool context; an attribute setting module configured to: set the review rule configuration attributes; the review rule configuration attributes include the unique identifier of the review rule, the classification to which the review rule belongs, a boolean flag indicating the enabling and disabling of the review rule, a brief description of the review rule, and the name of the implementation class of the specific review rule; a report generation module configured to: based on the review tool context, input an interface with unified rules, check the non-compliant items according to the review rule configuration attributes in combination with the configuration file of the report to be generated, and generate a review report according to the report template; The configuration file of the report to be generated includes: the unique identifier of the review rule, the unique number of the review rule, the semantic brief description of the review rule, the problem category that the problems detected by the review rule will cause, the severity level of the problems detected by the review rule, the modification deadline of the problems detected by the review rule, and the repair suggestions for the problems detected by the review rule.

8. A computer device, characterized in that a processor adapted to execute a computer program; a computer-readable storage medium storing a computer program, and when the computer program is executed by the processor, the steps in the software delivery quality review method according to any one of claims 1-6 are implemented.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the computer program is adapted to be loaded and executed by the processor to perform the steps in the software delivery quality review method according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by the processor, the steps in the software delivery quality review method according to any one of claims 1-6 are implemented.

Images