A software quality inspection method and apparatus

Abstract

A software quality inspection method and device, the method splits a specification rule with a coarse granularity into a plurality of atomic use cases with a fine granularity, then judges whether the split atomic use cases can perform automatic inspection, and develops automatic inspection measures for the atomic use cases that can perform automatic inspection, thereby reducing the difficulty of developing automatic inspection measures and improving the coverage of automatic inspection. Meanwhile, when the specification rule is updated, only the updated specification rule can be processed, which can reduce the probability that the automatic inspection measures are not applicable due to the change of the specification rule, and reduce the workload of adjusting the automatic inspection measures.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a software quality inspection method and apparatus. Background Technology

[0002] As software functions become increasingly complex, the amount of code also increases. In software engineering, to improve software quality, a series of software design safety specifications and development safety specifications are formulated. The aim is to constrain the software development process through these specifications, thereby improving the stability, security, and reliability of the final software.

[0003] However, with the diversity and complexity of business scenarios, programming languages, frameworks, libraries, etc., security specifications also need to be constantly revised and updated. This makes it impossible to automate the inspection of many specifications, requiring a lot of manpower to perform manual inspections. Summary of the Invention

[0004] This application provides a software quality inspection method and apparatus to improve the accuracy of software quality inspection and increase the coverage of automated inspection.

[0005] In a first aspect, this application provides a software quality inspection method, the method comprising: obtaining a first set, the first set including a first atomic use case with identification information corresponding to a first specification detail, the first atomic use case including at least one, the identification information being used to identify the first atomic use case as an atomic use case capable of performing automated inspection or an atomic use case requiring manual inspection, the first specification detail being any one of multiple software specification details used for inspecting software quality; if the identification information of the first atomic use case is a first identification information, then using the automated execution measures corresponding to the first atomic use case to perform automated inspection on the first specification detail, the first identification information being used to identify the first atomic use case as an atomic use case capable of performing automated inspection.

[0006] The above technical solution can be used to perform quality checks on atomic test cases corresponding to the specification details. Since the granularity of atomic test cases is finer than that of the specification details, it can reduce the difficulty of developing automated development tools and improve the coverage of automated checks.

[0007] In one possible design, the method further includes: if the identification information of the first atomic use case is the second identification information, then displaying a prompt message, the prompt message being used to prompt the user that the first specification details need to be manually reviewed, and the second identification information being used to identify the first atomic use case as an atomic use case that needs to be manually reviewed.

[0008] Since some atomic use cases can be automatically checked while others require manual inspection, the above technical solution allows for the execution of appropriate inspection measures based on the identification information of each atomic use case, thereby improving inspection efficiency.

[0009] In one possible design, obtaining the first set includes: obtaining a first version of the first specification details; splitting the first version of the first specification details to obtain a first atomic use case corresponding to the first specification details; obtaining the identification information configured by the user for the first atomic use case, and using the first atomic use case configured with the identification information as the first set.

[0010] The above technical solution can be used to decompose the specification details into atomic use cases, which means decomposing the coarse-grained specification details into fine-grained atomic use cases, thereby improving the coverage of automated inspection.

[0011] In one possible design, obtaining the first set includes: obtaining a first version of the first specification details and a second version of the first specification details, wherein the second version is higher than the first version; if it is determined that the content of the first version of the first specification details and the second version of the first specification details is the same, then the first atomic use case with identification information corresponding to the first version of the first specification details is taken as the first set.

[0012] In other words, if the new version of the specification details has not changed from the old version, the atomic use case corresponding to that specification detail can be used directly without needing to re-atomic the specification details when they are updated.

[0013] In one possible design, the method further includes: if it is determined that the first specification details of the first version and the first specification details of the second version are different, then the first specification details of the second version are split to obtain a second atomic use case corresponding to the first specification details of the second version, the second atomic use case including at least one; comparing the second atomic use case with the first atomic use case to determine a third atomic use case and a fourth atomic use case, the third atomic use case being an atomic use case that is different from the second atomic use case and the first atomic use case, and the third atomic use case being an atomic use case within the second atomic use case, the fourth atomic use case being an atomic use case that is the same as the second atomic use case and the first atomic use case; obtaining the identification information of the fourth atomic use case from the first atomic use case with identification information to obtain a fourth atomic use case configured with identification information; obtaining the identification information configured by the user for the third atomic use case, and forming a first set of the third atomic use case configured with identification information and the fourth atomic use case configured with identification information.

[0014] With the above technical solution, when the specification details change, it is only necessary to re-atomize the updated specification details and process the newly added atomic use cases. This can reduce the probability that the automated inspection measures will not be applicable due to the change of specification details, and reduce the workload of adjusting the automated inspection measures.

[0015] Secondly, this application provides a software quality inspection apparatus, comprising: an acquisition unit, configured to acquire a first set, the first set including first atomic use cases with identification information corresponding to a first specification detail, the first atomic use case including at least one, the identification information being used to identify the first atomic use case as an atomic use case capable of performing automated inspection or an atomic use case requiring manual inspection, the first specification detail being any one of multiple software specification details used for inspecting software quality; and an inspection unit, configured to perform automated inspection on the first specification detail using automated execution measures corresponding to the first atomic use case when the identification information of the first atomic use case is a first identification information, the first identification information being used to identify the first atomic use case as an atomic use case capable of performing automated inspection.

[0016] In one possible design, the inspection unit is further configured to: display a prompt message when the identification information of the first atomic use case is the second identification information, the prompt message being used to prompt the user that the first specification details need to be manually checked, and the second identification information being used to identify the first atomic use case as an atomic use case that needs to be manually checked.

[0017] In one possible design, the acquisition unit is specifically used to acquire the first set in the following manner:

[0018] Obtain the first specification details of the first version; break down the first specification details of the first version to obtain the first atomic use case corresponding to the first specification details; obtain the identification information configured by the user for the first atomic use case, and take the first atomic use case with the configured identification information as the first set.

[0019] In one possible design, the acquisition unit is specifically used to acquire the first set in the following manner:

[0020] Obtain the first specification details of the first version and the first specification details of the second version, where the second version is higher than the first version; if it is determined that the content of the first specification details of the first version and the first specification details of the second version is the same, then take the first atomic use case with identification information corresponding to the first specification details of the first version as the first set.

[0021] In one possible design, the apparatus further includes a splitting unit, which is configured to split the first specification detail of the second version when it is determined that the contents of the first specification detail of the first version and the first specification detail of the second version are different, to obtain a second atomic use case corresponding to the first specification detail of the second version, wherein the second atomic use case includes at least one.

[0022] The apparatus further includes: a determining unit, configured to compare the second atomic use case with the first atomic use case to determine a third atomic use case and a fourth atomic use case, wherein the third atomic use case is an atomic use case that is different from the second atomic use case and the first atomic use case, and the third atomic use case is an atomic use case in the second atomic use case, and the fourth atomic use case is an atomic use case that is the same as the second atomic use case and the first atomic use case.

[0023] The acquisition unit is further configured to: acquire the identification information of the fourth atomic use case from the first atomic use case with identification information, thereby obtaining the fourth atomic use case configured with identification information; and acquire the identification information configured by the user for the third atomic use case, and combine the third atomic use case configured with identification information and the fourth atomic use case configured with identification information into a first set.

[0024] Thirdly, this application provides a software quality inspection device, which has the function of implementing the software quality inspection method in the first aspect or any possible implementation of the first aspect. The function can be implemented by hardware or by hardware executing corresponding software.

[0025] The software quality inspection device includes: a memory and a processor; the memory is used to store computer instructions; the processor is used to execute the computer instructions stored in the memory to cause the software quality inspection device to perform the method described in the first aspect or any possible implementation thereof.

[0026] Fourthly, this application also provides a computer-readable storage medium storing computer instructions that, when executed by a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

[0027] Fifthly, this application also provides a computer program product, the computer program product including computer instructions, which, when executed by a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

[0028] Regarding the technical effects of the various implementation methods of the second to fifth aspects, please refer to the introduction of the technical effects of the first aspect or the various implementation methods of the first aspect, which will not be elaborated here. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0030] Figure 2 A system structure block diagram provided for an embodiment of this application;

[0031] Figure 3 A flowchart of a software quality inspection method provided in this application embodiment;

[0032] Figure 4 A flowchart illustrating a method for obtaining an atomic use case library provided in this application embodiment;

[0033] Figure 5 A comparative diagram showing the processing methods before and after the update of the specification details, provided for an embodiment of this application;

[0034] Figure 6 A flowchart illustrating another method for obtaining an atomic use case library provided in an embodiment of this application;

[0035] Figure 7 This is a schematic diagram of the structure of a software quality inspection device provided in an embodiment of this application;

[0036] Figure 8 This is a schematic diagram of the structure of a software quality inspection device provided in an embodiment of this application. Detailed Implementation

[0037] The implementation of this embodiment will now be described in detail with reference to the accompanying drawings.

[0038] The following section will first explain some of the terms used in the embodiments of this application so that those skilled in the art can understand them.

[0039] 1) Rule: An entry in a specification that describes a rule or requirement.

[0040] 2) Atomic Cases (AC): The content of a detail in the specification is broken down into multiple atomic cases according to a certain method. Each atomic case corresponds to a specific, clear, and indivisible technical requirement.

[0041] The "multiple" mentioned in the embodiments of this application refers to two or more. It should be noted that in the description of the embodiments of this application, terms such as "first" and "second" are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0042] This application provides a software quality inspection method that can be applied to any scenario requiring software quality inspection, such as software security specification inspection, software design specification inspection, software coding specification inspection, and hardware development specification inspection. Furthermore, this method can be applied to software quality inspection platforms and systems. In other words, the solution of this application can be applied to the fields of software security and software / hardware development.

[0043] The following uses software security specifications as an example to introduce the methods of this application and the scenarios in which these methods are applied.

[0044] like Figure 1 The diagram shown is an application scenario illustration provided by an embodiment of this application. (See attached image.) Figure 1 As shown, the scenario includes: user 10, terminal device 11, user 20, terminal device 21, and server 30. User 10 can use terminal device 11 to write the "Software Security Specification." Simultaneously, user 10 can write atomic use cases (or "sub-rules") for each specification in the "Software Security Specification." It should be understood that the number of atomic use cases for different specifications can be the same or different; this application does not limit this. For example, see Table 1 below.

[0045] Table 1

[0046]

[0047] It should be understood that the terms "specification", "safety specification details", and "specification details" in the embodiments of this application have the same meaning.

[0048] Suppose that one of the specifications has P atomic use cases, where M is a positive integer greater than or equal to 1. User 10 can send the written "Software Security Specification" to User 20 via a communication network. Correspondingly, after receiving the "Software Security Specification" written by User 10, User 20 can determine which atomic use cases among the P atomic use cases can be automatically checked and which atomic use cases require manual checking. Based on the determination result, it assigns corresponding identification information to the N atomic use cases, whereby the identification information indicates whether the atomic use case check is automated or manual.

[0049] For example, suppose there are a total of 5 atomic use cases (i.e., P=5), of which 3 atomic use cases can be automated and 2 atomic use cases require manual inspection. For instance, the identification information of the atomic use cases can be found in Table 2 below.

[0050] Table 2

[0051]

[0052]

[0053] It should be understood that Table 2 is only an illustrative example, and the form of the identification information of atomic use cases is not specifically limited in the embodiments of this application.

[0054] The above process can be understood as classifying atomic use cases into those that can be automatically checked and those that require manual checking. Then, user 20 can use terminal device 21 to convert the atomic use cases that can be automatically checked into corresponding code for performing automated checks (i.e., developing automated checking measures for the atomic use cases that can be automatically checked), so that automated checks can be performed subsequently based on the code. Meanwhile, for atomic use cases that require manual checking, the steps for manual checking are specified.

[0055] Next, user 20 can upload atomic test cases, the code corresponding to atomic test cases that can be automated, and the manual inspection steps corresponding to atomic test cases that require manual inspection to server 30. Server 30 will then perform automated or manual inspections based on the identification information of the atomic test cases. It should be understood that each atomic test case that can be automated can correspond to a set of automated inspection code.

[0056] exist Figure 1 In the schematic diagram shown, terminal device 11 and terminal device 21 can establish a connection through a communication network, and terminal device 21 and server 30 can establish a communication connection through a communication network. Terminal device 21 can upload the code corresponding to the atomic use case to server 30, which will check it, obtain the check result, and then send the check result to terminal device 21.

[0057] It should be understood that user 10 here can be the company's management personnel, user 20 refers to the developers, and server 14 can be understood as the software quality inspection platform.

[0058] It should be noted that the communication network can be a local area network (LAN) or a wide area network (WAN) relayed through a relay device. Terminal devices 11 and 21 can be mobile phones, tablets, laptops, personal computers, etc., and server 30 can be any server device capable of supporting the corresponding inspection services.

[0059] When the communication network is a local area network (LAN), for example, it can be a Wi-Fi hotspot network, a Bluetooth (BT) network, or a near-field communication (NFC) network. When the communication network is a wide area network (WAN), for example, it can be a 3G network, a 4G network, a 5G network, a future public land mobile network (PLMN), or the Internet.

[0060] like Figure 2 The diagram shown is a system structure block diagram provided in an embodiment of this application. (See also...) Figure 2 As shown, it may specifically include a security specification management service module 21 and an atomic use case management service module 22.

[0061] The security specification management service module 21 may include a specification version management module 211, a specification details management module 212, and a specification version difference management module 213. The specification version management module 211 manages basic information such as the basic information and version information of the security specifications; the details management module 212 manages the details of each version of the specification; and the specification version difference management module 213 compares the details of different versions of the security specifications to identify the similarities and differences.

[0062] The atomic use case management service module 22 may include an atomic decomposition management module 221, a rules and atomic use case relationship management module 222, an atomic use case analysis and inheritance management module 223, an atomic use case automated inspection scheme management module 224, and an inspection result confirmation management module 225. The atomic decomposition management module 221 is used to atomically decompose the security specification rules to obtain atomic use cases; the rules and atomic use case relationship management module 222 is used to manage the correspondence between each atomic use case and the rules in different versions; the atomic use case analysis and inheritance management module 223, when the security specification version is updated, automatically inherits the atomic use cases of the unmodified rules based on the analysis results of the version difference management module, and submits the newly added and updated rules to the atomic decomposition management module for re-decomposition; the atomic use case automated inspection scheme management module 224 is used to maintain the technical solution, implementation steps, and deployment information of the automated inspection measures for each atomic use case; drive the operation of atomic use cases and inspection tools and record the inspection results; the inspection result confirmation management module 225 provides manual confirmation functionality for automated inspection results, automated inspection failures, and atomic use cases that have not implemented automated inspections.

[0063] The software quality inspection method provided in this application is described in detail below.

[0064] like Figure 3 The diagram shown is a flowchart of a software quality inspection method provided in an embodiment of this application. (See attached diagram.) Figure 3 As shown, the method may include the following steps:

[0065] S301: The server retrieves the first set.

[0066] The first set may include atomic use cases with the same and / or different identification information, which identifies whether the atomic use case is manually checked or not manually checked. For example, the first set may include L atomic use cases that can be automatically checked and / or M atomic use cases that require manual checking. It should be understood that the first set may also be referred to as the "atomic use case library".

[0067] Assuming the total number of atomic test cases is N, then when the first set includes L atomic test cases that can be automatically checked, N = L; when the first set includes M atomic test cases that require manual checking, N = M; when the first set includes L atomic test cases that can be automatically checked and M atomic test cases that require manual checking, N = L + M.

[0068] S302: The server determines whether automated checks can be performed based on the identification information of the atomic use case. If automated checks can be performed, proceed to S303; otherwise, proceed to S304.

[0069] After obtaining the first set, the server can determine whether an atomic use case is eligible for automatic checks based on its identification information. If the atomic use case identification information indicates that it is eligible for automatic checks, the server can utilize automated checks, i.e., code execution for automatic checks. If the atomic use case identification information indicates that it is eligible for manual checks, the server displays a notification message to inform the user to perform manual checks and provides the corresponding check steps for the user to perform manual checks.

[0070] S303: The server performs automated checks based on the automated check measures corresponding to the atomic use cases that can perform automated checks, and obtains the first check result.

[0071] S304: The server provides the check steps corresponding to the atomic use cases that require manual inspection, so that users can perform manual inspections and obtain a second inspection result.

[0072] Users can perform manual inspections according to the provided inspection steps. After the inspection is completed, a corresponding inspection result input box is provided, allowing users to edit the inspection results.

[0073] S305: The server summarizes and confirms the first and second check results, and outputs the check results.

[0074] The above technical solution breaks down specification details into atomic use cases, addressing the problem in existing technologies where coarse-grained specification details prevent automated checking. Atomic decomposition reduces the amount of content in each requirement, making the description more specific and clear. This significantly reduces the difficulty of developing automated checking tools and improves the accuracy of automated checks.

[0075] The following details the process of obtaining the atomic use case library in S301.

[0076] Taking a software security specification of the current version or an earlier version as an example, such as a security specification detail in "Software Security Specification 1.0", the following implementation method can be used for other security specification details. The atomic use case library of "Software Security Specification 1.0" can be understood as a collection of atomic use case libraries corresponding to each security specification detail. For example, see [link to implementation details]. Figure 4 As shown, the atomic use case library can be obtained through the following steps:

[0077] S401: The server obtains the first version of the first security specification details.

[0078] For ease of description, the current version will be referred to as "Version 1", the version updated after the current version will be referred to as "Version 2", and any security specification detail in the current version will be referred to as "Second Security Specification Detail".

[0079] S402: The server atomically decomposes the first security specification details of the first version to generate the first atomic use case.

[0080] Users can import the "Software Security Specification 1.0" into the software quality inspection system (i.e., the server). The server can then obtain the detailed security specifications from "Software Security Specification 1.0" and break them down into atomic use cases. For ease of description, the atomic use case resulting from the breakdown of the first security specification detail will be denoted as the "first atomic use case".

[0081] The following explanation uses a specific example of the detailed specifications to illustrate this process. Assume that the "Software Security Specification 1.0" contains the following detailed specification:

[0082] The use of encryption algorithms known to be insecure in the industry is prohibited; strong encryption algorithms are recommended.

[0083] Because this specification is quite broad and coarse-grained, it is difficult to automate the checks. Therefore, this embodiment breaks it down into finer-grained, more specific atomic use cases. For example, the atomization decomposition management module can break down the above specification into the following 7 atomic use cases:

[0084] 1. Data encryption using weak encryption algorithms such as blowfish and RC4 is prohibited.

[0085] 2. It is forbidden to use weak encryption algorithms such as DES and 2TDEA (i.e., 2Key 3DES) to encrypt data.

[0086] 3. SHA-1 is prohibited as the hash algorithm for digital signatures, and SHA-1 is prohibited from being used in hash-only scenarios.

[0087] 4. MD5 is prohibited from being used for the following cryptographic security purposes: digital signatures, authentication credential storage, integrity protection, HMAC, key derivation, generating hash values ​​in challenge-response authentication, and random number generation.

[0088] 5. The key length for RSA and DSA algorithms should be at least 2048 bits (2048 bits can be used until 2021), and 3072 bits is recommended.

[0089] 6. The use of DH / DHE algorithms with a key length of less than 2048 bits (such as DH512 and DH1024) and ECDH / ECDHE algorithms with a key length of less than 224 bits is prohibited.

[0090] 7. It is recommended to use the DH / DHE algorithm with a key length of 3072 bits or more and the ECDH / ECDHE algorithm with a key length of 256 bits or more.

[0091] This allows the abstract specifications to be broken down into specific, clear, single-content, and technically feasible atomic use cases. Then, automated inspection tools can be developed to check these atomic use cases. This approach makes it easy to check whether the code meets the specific requirements, thereby reducing the complexity of developing automated inspection tools and increasing the automation rate.

[0092] S403: The server retrieves the first atomic use case marked and obtains the atomic use case library corresponding to the first security specification details.

[0093] In this step, the user can determine whether an atomic use case is eligible for automated checks. If the atomic use case can be represented by code, it is considered eligible for automated checks. The atomic use case can then be marked as eligible for automated checks, and automated check measures can be developed for it.

[0094] If an atomic use case cannot be described through code, it is considered unsuitable for automated checks. This atomic use case can then be marked as requiring manual checks, and the manual check steps can be labeled accordingly. In this way, the set of atomic use cases from both parts can be denoted as an atomic use case library.

[0095] Following the above method, the atomic test case library corresponding to each security specification detail in "Software Security Specification 1.0" can be obtained sequentially. Due to changes in the security landscape caused by technological iterations and new security incidents, the specification also needs to be revised and updated synchronously. Many details of the specification will be adjusted, therefore, the automated inspection logic needs to be adjusted accordingly, making automated measures unstable and resulting in a significant workload for adjustments. In this embodiment, after the specification details are revised and updated, atomic test cases with the same details can be directly inherited from the previous version of the specification, i.e., no further atomic decomposition is required. For newly added or changed details, atomic decomposition is performed again. Atomic test cases identical to those in the previous version can be directly used. For newly added atomic test cases, it is only necessary to determine whether automated checks can be performed. This allows for the rapid generation of atomic test cases for the new version and minimizes the impact of specification changes on automated inspection measures.

[0096] In other words, when the specifications are updated, the atomization decomposition method can minimize the impact on the parts that can be automated, so that the newly added specifications can be quickly automated, thereby improving the automation coverage of security rule checks.

[0097] like Figure 5The diagram illustrates a comparison of processing methods before and after an update of the specification details provided in this application. For example, the current version is "Software Security Specification 1.0," and the updated version is "Software Security Specification 2.0." For "Software Security Specification 1.0," the specification details can first be broken down to obtain atomic use cases 1.0. Then, automated inspection measures can be developed for some atomic use cases in atomic use cases 1.0, for example, denoted as Automated Inspection 1.0.

[0098] After updating to the "Software Security Specification 2.0", the detailed specifications in "Software Security Specification 2.0" can be broken down to obtain Atomic Use Case 2.0. Atomic Use Case 2.0 can include some Atomic Use Case 1.0, deleted Atomic Use Cases, and newly added / updated Atomic Use Cases. For some Atomic Use Case 1.0 in Atomic Use Case 2.0, automated checks 1.0 can be automatically inherited. For newly added / updated Atomic Use Cases, new automated check measures can be developed. This yields the automated check measures corresponding to some Atomic Use Case 2.0 in "Software Security Specification 2.0", which can be denoted as Automated Check 2.0.

[0099] The following flowchart illustrates the update process described above. Figure 6 The diagram shown is a flowchart of another method for obtaining an atomic use case library provided in an embodiment of this application. (See attached diagram.) Figure 6 As shown, the method may include the following steps:

[0100] S601: The server obtains the first security specification details of the second version.

[0101] S602: The server compares the first security specification details of the first version with the first security specification details of the second version, and generates a comparison analysis result of the details.

[0102] It should be understood that after the security specifications of Software Security Specification 1.0 are imported into the server, the server can save the security specifications of Software Security Specification 1.0 for comparison between the old and new versions in the future.

[0103] S603: The server determines whether the first security specification details of the first version and the second version are the same. If they are the same, proceed to S604; if they are different, proceed to S605.

[0104] S604: The server retrieves the first atomic use case corresponding to the first security specification details.

[0105] For a specific security specification detail, the server needs to determine if that detail is identical in both versions. If it is identical, the server directly inherits the atomic use cases from the previous version. In other words, there is no need to atomically decompose that specific security specification detail.

[0106] For all security specification details in Software Security Specification 1.0 and Software Security Specification 2.0, the server needs to compare each security specification detail sequentially to see if they are the same. Therefore, among all the security specification details, some may remain unchanged, while others may have changed.

[0107] S605: The server atomically decomposes the first security specification details of the second version to obtain the second atomic use case.

[0108] If the first security specification details of the second version differ from those of the first version, then the first security specification details of the second version are split into atomic use cases. For ease of description, the atomic use case corresponding to the first security specification details of the second version can be denoted as the "second atomic use case".

[0109] Let's continue with the example of the detailed rule in the aforementioned "Software Security Specification 1.0," which states, "The use of encryption algorithms known to be insecure in the industry is prohibited; strong cryptographic algorithms are recommended." Suppose that this detailed rule has been updated in "Software Security Specification 2.0," for example, as follows:

[0110] Prioritize the use of secure, strong cryptographic algorithms. Cryptographic algorithms that can be omitted can be reused in new versions. Insecure cryptographic algorithms are prohibited.

[0111] After obtaining the updated specification details, these details can be atomically decomposed, resulting in 8 atomic test cases. The first 7 atomic test cases are identical to the 7 test cases in Software Security Specification 1.0, and the following atomic test case has been added:

[0112] 8. Newly installed versions disable insecure password algorithms by default. After upgrading, you need to generate corresponding alerts or user prompts for the insecure password algorithms enabled in the new version.

[0113] It should be understood that the preceding 7 atomic use cases plus the newly added 8th atomic use case can be interpreted as the "second atomic use case".

[0114] S606: The server determines whether the second atomic use case is different from the first atomic use case. If different atomic use cases exist, then execute S607. If no different atomic use cases exist, i.e., the atomic use cases are completely identical, then no action is taken.

[0115] S607: Third atomic use case for server to retrieve tags.

[0116] When the specification details are updated, the updated specification details need to be atomically decomposed. This may result in the second atomic use case being partially the same as or completely different from the previous atomic use case. In this embodiment, only the newly added atomic use cases need to be processed. That is, the atomic use cases that differ between the two versions need to be processed. For ease of description, the atomic use case that differs from the atomic use case in the previous version can be referred to as the "third atomic use case".

[0117] If the second atomic use case is completely different from the atomic use cases of the first atomic use case, then the second atomic use case is included in the atomic use case library corresponding to the first security specification details of the second version. If the second atomic use case is partially the same as the first atomic use case, then the set consisting of the third and fourth atomic use cases is included in the atomic use case library corresponding to the first security specification details of the second version. The fourth atomic use case refers to the atomic use case that is the same in the second and first atomic use cases. For example, assuming the first atomic use cases corresponding to the first specification details of the first version include 1, 2, and 3, and the second atomic use cases corresponding to the first specification details of the second version include 4, 5, and 6, then 4, 5, and 6 constitute the atomic use case library corresponding to the first specification details of the second version. Similarly, assuming the first atomic use cases corresponding to the first specification details of the first version include 1, 2, and 3, and the second atomic use cases corresponding to the first specification details of the second version include 1, 2, 3, 4, and 5, then 1, 2, and 3 are the aforementioned fourth atomic use cases, and 4 and 5 are the third atomic use cases.

[0118] For example, a user can determine whether a third atomic use case can perform automated checks. If it can, the user marks the atomic use cases in the third atomic use case that can perform automated checks and develops automated check measures for the atomic use cases that can perform automated checks. If it cannot perform automated checks, i.e., it requires manual checks, the user marks the atomic use cases in the third atomic use case that require manual checks and explains the manual check steps.

[0119] Continuing with the previous specification details as an example, the newly added atomic use case #8 can be understood as the "third atomic use case". Users can determine whether the atomic use case "8. New installations disable insecure password algorithms by default; after upgrading, corresponding alerts or user prompts need to be generated for the insecure password algorithms enabled in the version" can be automatically checked. Since this atomic use case cannot be described by code, i.e., it requires manual checking, it is marked as an atomic use case requiring manual checking. Since the previous 7 atomic use cases can be described by code, they are marked as atomic use cases that can be automatically checked.

[0120] This will give you the new atomic use case (the third atomic use case) and the atomic use case that inherits from the previous version (the fourth atomic use case). Finally, combining the above atomic use cases together will give you the updated atomic use case library for the security specification.

[0121] Furthermore, in item 5 of the aforementioned atomic use case, "RSA and DSA algorithm key length is at least 2048 bits (2048 bits can be used until 2021), 3072 bits is recommended," it can be seen that the specific description of this atomic use case involves the issue of usage period. In this case, in this embodiment of the application, after the expiration of the period, the atomic use case can be directly modified, for example, modified as follows:

[0122] 5. The key length for RSA and DSA algorithms must be at least 3072 bits.

[0123] The above modifications allow for rapid adaptation to specification changes with minimal alterations. Of course, after updating this atomic test case, the automated checks for that test case also need to be updated.

[0124] In this embodiment, fine-grained atomic use cases are more adaptable to updates to security specifications. Furthermore, when specification details are updated or expire, the updated specification details can be re-atomicd and decomposed. Since some of the decomposed atomic use cases are identical to existing ones, new automated check measures only need to be developed for the newly added atomic use cases (e.g., atomic use cases capable of performing automated checks). This reduces the probability of automated check measures becoming unusable due to specification changes and also reduces the workload of adjusting automated measures.

[0125] Furthermore, since source code can only cover a limited number of security and quality issues—meaning it cannot perform comprehensive analysis and inspection—it cannot detect issues such as whether software logs leak sensitive information, whether the operating system environment in which the software runs is secure, whether the middleware configuration is secure, or whether secure compilation options are enabled. Therefore, in this embodiment, the method described above for performing automated checks using atomic test cases can also be used to check software runtime logs, runtime environment, compilation and build environment, software information tree, etc.

[0126] For example, software runtime logs can be checked and analyzed to see if they leak sensitive information; the operating system environment can be analyzed to determine if the operating system version, configuration, and patches meet security requirements; the middleware version can be analyzed to determine if it has known vulnerabilities; middleware configuration parameters can be analyzed to determine if they meet security requirements; the software information tree can be analyzed to determine if the third-party components it references are secure and if their versions have vulnerabilities; and software compilation environment parameters can be analyzed to determine if secure compilation options are enabled.

[0127] The above-described inspection method can solve the problem of limited inspection scope when security inspection is based solely on source code in the prior art. The solution of this application embodiment can make the software inspection coverage wider and the inspection results of higher quality, that is, the inspection results are more reliable.

[0128] Based on the above embodiments, this application also provides a software quality inspection device, which may be a device or equipment in the aforementioned server. See also... Figure 7 As shown, the device 700 may include: an acquisition unit 701 and an inspection unit 702.

[0129] The acquisition unit 701 is used to acquire a first set, which includes a first atomic use case with identification information corresponding to the first specification details. The first atomic use case includes at least one, and the identification information is used to identify whether the first atomic use case is an atomic use case that can perform automated checks or an atomic use case that requires manual checks. The inspection unit 702 is used to perform automated checks on the first specification details using the automated execution measures corresponding to the first atomic use case when the identification information of the first atomic use case is the first identification information. The first identification information is used to identify whether the first atomic use case is an atomic use case that can perform automated checks.

[0130] In one possible implementation, the inspection unit 702 is further configured to: display a prompt message when the identification information of the first atomic use case is the second identification information, the prompt message being used to prompt the user that the first specification details need to be manually checked, and the second identification information being used to identify the first atomic use case as an atomic use case that needs to be manually checked.

[0131] In one possible implementation, the acquisition unit 701 is specifically used to create a first set in the following manner:

[0132] Obtain the first specification details of the first version; break down the first specification details of the first version to obtain the first atomic use case corresponding to the first specification details; obtain the identification information configured by the user for the first atomic use case, and take the first atomic use case with the configured identification information as the first set.

[0133] In one possible implementation, the acquisition unit 701 is specifically used to create a first set in the following manner:

[0134] Obtain the first specification details of the first version and the first specification details of the second version, where the second version is higher than the first version; if it is determined that the content of the first specification details of the first version and the first specification details of the second version is the same, then take the first atomic use case with identification information corresponding to the first specification details of the first version as the first set.

[0135] In one possible implementation, the apparatus further includes a splitting unit 703, which is configured to split the first specification details of the second version when it is determined that the contents of the first specification details of the first version and the first specification details of the second version are different, to obtain a second atomic use case corresponding to the first specification details of the second version, wherein the second atomic use case includes at least one.

[0136] The apparatus further includes a determining unit 704, configured to compare the second atomic use case with the first atomic use case to determine a third atomic use case and a fourth atomic use case, wherein the third atomic use case is an atomic use case that is different from the second atomic use case and the first atomic use case, and the third atomic use case is an atomic use case in the second atomic use case, and the fourth atomic use case is an atomic use case that is the same as the second atomic use case and the first atomic use case.

[0137] The acquisition unit 701 is further configured to: acquire the identification information of the fourth atomic use case from the first atomic use case with identification information, thereby obtaining the fourth atomic use case configured with identification information; and acquire the identification information configured by the user for the third atomic use case, and combine the third atomic use case configured with identification information and the fourth atomic use case configured with identification information into a first set.

[0138] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0139] The module division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in each embodiment of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0140] like Figure 8 The illustration shows a software quality inspection device 800 provided in an embodiment of this application. This device can be a server or one or more devices within a server. The device 800 includes at least one processor 802, used to implement or support the device 800 in implementing the software quality inspection device provided in this embodiment. Figure 7 The function of the inspection unit shown is illustrated. For example, when the identification information of the first atomic use case is the first identification information, the processor 802 performs automated inspection on the first specification details using the automated execution measures corresponding to the first atomic use case. The first identification information is used to identify the first atomic use case as an atomic use case capable of performing automated inspection, etc. For details, please refer to the detailed description in the method example, which will not be repeated here.

[0141] Device 800 may further include at least one memory 801 for storing program instructions. Memory 801 and processor 802 are coupled. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. Processor 802 may operate in conjunction with memory 801. Processor 802 may execute program instructions and / or data stored in memory 801. At least one of the at least one memory may be included in the processor.

[0142] The device 800 may also include a communication interface 803 for communicating with other devices via a transmission medium. The processor 802 can use the communication interface 803 to send and receive data.

[0143] This application does not limit the specific connection medium between the communication interface 803, the processor 802, and the memory 801 described above. Embodiments of this application... Figure 8 The memory 801, processor 802, and communication interface 803 are connected via a bus 804. Figure 8 The bus is represented by thick lines. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0144] In the embodiments of this application, the processor 802 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application may be directly executed by the hardware processor, or executed by a combination of hardware and software modules in the processor.

[0145] In this embodiment, the memory 801 can be non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as RAM. Memory is any medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in this embodiment can also be a circuit or any other device capable of implementing storage functions for storing program instructions.

[0146] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0147] This application also provides a computer-readable storage medium including instructions that, when run on a computer, cause the computer to perform the methods of the above embodiments.

[0148] This application also provides a computer program product, including instructions that, when run on a computer, cause the computer to perform the methods described above.

[0149] This application also provides a chip, the logic in which is used to execute the methods of the above embodiments.

[0150] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by instructions. These instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0151] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0152] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0153] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A software quality inspection method, characterized in that, include: Obtain a first set, which includes first atomic use cases with identification information corresponding to a first specification detail. The first atomic use case includes at least one, and the identification information is used to identify whether the first atomic use case is an atomic use case capable of performing automated checks or an atomic use case requiring manual checks. The first specification detail is any one of multiple software specification details used for checking software quality. The first atomic use case is obtained by atomically decomposing the first specification detail. If the first atomic use case can be described by code, then the first atomic use case is an atomic use case capable of performing automated checks; if the first atomic use case cannot be described by code, then the first atomic use case is an atomic use case requiring manual checks. If the identification information of the first atomic use case is the first identification information, then the automated execution measures corresponding to the first atomic use case are used to perform automated checks on the first specification details. The first identification information is used to identify the first atomic use case as an atomic use case that can perform automated checks. If the identification information of the first atomic use case is the second identification information, then a prompt message is displayed. The prompt message is used to remind the user that the first specification details need to be manually checked, and the second identification information is used to identify the first atomic use case as an atomic use case that needs to be manually checked. The process of obtaining the first set includes: Obtain the first specification details of the first version and the first specification details of the second version, where the second version is higher than the first version; if it is determined that the content of the first specification details of the first version and the first specification details of the second version is the same, then take the first atomic use case with identification information corresponding to the first specification details of the first version as the first set. If it is determined that the content of the first specification details of the first version and the first specification details of the second version are different, then the first specification details of the second version are split to obtain the second atomic use case corresponding to the first specification details of the second version. The second atomic use case includes at least one. The second atomic use case is compared with the first atomic use case to determine the third atomic use case and the fourth atomic use case. The third atomic use case is an atomic use case that is different from the second atomic use case and the first atomic use case, and the third atomic use case is an atomic use case in the second atomic use case. The fourth atomic use case is an atomic use case that is the same as the second atomic use case and the first atomic use case. The identification information of the fourth atomic use case is obtained from the first atomic use case with identification information to obtain the fourth atomic use case configured with identification information. The identification information configured by the user for the third atomic use case is obtained, and the third atomic use case configured with identification information and the fourth atomic use case configured with identification information are combined into a first set.

2. A software quality inspection device, characterized in that, include: An acquisition unit is configured to acquire a first set, which includes first atomic use cases with identification information corresponding to a first specification detail. The first atomic use case includes at least one, and the identification information identifies whether the first atomic use case is an atomic use case capable of performing automated checks or an atomic use case requiring manual checks. The first specification detail is any one of multiple software specification details used for checking software quality. The first atomic use case is obtained by atomically decomposing the first specification detail. If the first atomic use case can be described by code, then the first atomic use case is an atomic use case capable of performing automated checks; if the first atomic use case cannot be described by code, then the first atomic use case is an atomic use case requiring manual checks. The inspection unit is used to perform automated inspection on the first specification details by utilizing the automated execution measures corresponding to the first atomic use case when the identification information of the first atomic use case is the first identification information. The first identification information is used to identify the first atomic use case as an atomic use case that can perform automated inspection. The inspection unit is further configured to: display a prompt message when the identification information of the first atomic use case is the second identification information, the prompt message being used to prompt the user that the first specification details need to be manually checked, and the second identification information being used to identify the first atomic use case as an atomic use case that needs to be manually checked; The acquisition unit is specifically used to acquire the first set in the following manner: Obtain the first specification details of the first version and the first specification details of the second version, where the second version is higher than the first version; if it is determined that the content of the first specification details of the first version and the first specification details of the second version is the same, then take the first atomic use case with identification information corresponding to the first specification details of the first version as the first set. The device further includes: a splitting unit, which is configured to split the first specification details of the second version when it is determined that the contents of the first specification details of the first version and the first specification details of the second version are different, to obtain a second atomic use case corresponding to the first specification details of the second version, wherein the second atomic use case includes at least one. The apparatus further includes: a determining unit, configured to compare the second atomic use case with the first atomic use case, and determine a third atomic use case and a fourth atomic use case, wherein the third atomic use case is an atomic use case that is different from the second atomic use case and the first atomic use case, and the third atomic use case is an atomic use case in the second atomic use case, and the fourth atomic use case is an atomic use case that is the same as the second atomic use case and the first atomic use case; The acquisition unit is further configured to: acquire the identification information of the fourth atomic use case from the first atomic use case with identification information, thereby obtaining the fourth atomic use case configured with identification information; and acquire the identification information configured by the user for the third atomic use case, and combine the third atomic use case configured with identification information and the fourth atomic use case configured with identification information into a first set.

3. A software quality inspection device, characterized in that, include: Memory and processor; The memory is used to store computer instructions; The processor is used to execute computer instructions stored in the memory to cause the software quality inspection device to perform the method as described in claim 1.

4. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions that, when executed by a computer, cause the computer to perform the method as described in claim 1.

5. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a computer, cause the computer to perform the method as described in claim 1.

Images