A software high-level requirement data coupling coverage analysis method and device

Abstract

The application discloses a software high-layer demand data coupling coverage analysis method and device, solves a data coupling analysis correctness source problem throughout a whole life cycle (including high-layer demand, architecture design, low-layer demand, source code, etc.) of airborne software development, provides input and basis for evaluating data coupling correctness of downstream design output results (including architecture design, low-layer demand, source code, etc.), and its technical scheme is as follows: the application constructs a software high-layer demand data coupling analysis process based on external interface definition and internal control flow for entry-based software high-layer demand, and solves a source problem of correctness judgment of data coupling analysis results of downstream design output results (including architecture design, low-layer demand, source code, etc.) of software life cycle.

Description

Technical Field

[0001] This invention relates to the field of software testing and verification, and more specifically to a method and apparatus for software data coupling coverage analysis based on high-level requirements. Background Technology

[0002] In DO-178C, "Software Considerations in the Conformity Assessment of Airborne Systems and Equipment," high-level requirements are the starting point of the software lifecycle, the source for defining software architecture and low-level requirements, and the benchmark and direct basis for judging the correctness of software implementation during the software verification process.

[0003] According to DO-178C, "Validation" is a system lifecycle process activity used to determine the correctness and completeness of requirements. During system requirement validation, it's necessary to assess the conformity between the high-level software requirements and the system requirements. Once validated, the high-level software requirements and system requirements are considered consistent. However, in the software lifecycle, only "Verification" is defined: software verification is a technical evaluation of the outputs of the software planning, development, and verification processes. It assesses the correctness and conformity of the process results based on the process inputs and relevant technical standards (including requirement standards, design standards, model standards, coding standards, etc.).

[0004] High-level requirements review and analysis is a software verification activity used to assess the consistency of internal interfaces, logic, and data coupling relationships within high-level requirements. According to Section 6.3.1.b of DO-178B / C, "Accuracy and Consistency," which requires ensuring that "each high-level requirement is accurate, unambiguous, and sufficiently detailed, with no conflicts between requirements," verifying requirement consistency necessitates assessing for conflicts between requirement items. The focus in evaluating whether requirements conflict includes not only the behaviors described by different requirement items but also the internal interfaces between requirements—that is, whether the data flow and data coupling relationships between requirements are normal. Based on this verification objective, high-level requirements data coupling analysis activities should be incorporated into the high-level requirements review and analysis process.

[0005] Furthermore, the objective of Schedule A-7.8 of DO-178C, "Complete test coverage of the software architecture (data coupling and control coupling)," indirectly places requirements on high-level requirement data coupling analysis. This objective primarily focuses on the adequacy assessment of integration testing to ensure the correctness of interactions and dependencies between integrated components. To verify the correctness of interactions and dependencies between integrated components, it is necessary to further determine the conformity of data coupling relationships between software components and high-level software requirements, based on the assessment results of the correctness of data coupling relationships between high-level software requirement items. If abnormal defects in high-level requirement data coupling relationships can be identified early in the software lifecycle, it will effectively prevent the propagation of these defects to later stages of the software lifecycle, significantly reducing the cost of defect remediation.

[0006] The existing airworthiness standard supporting document DO-248C, in FAQ#67 "What is Data Coupling and Control Coupling Analysis?", proposes a comprehensive verification objective combining software architecture review, source code review, requirements-based software (hardware) integration testing, and structural coverage analysis, but fails to explicitly mention conducting relevant data coupling analysis activities for high-level requirements. This results in a lack of criteria for judging the correctness of data coupling analysis in software architecture and source code. Therefore, in software airworthiness verification engineering practice, high-level requirement data coupling analysis should be supplemented to ensure the correctness of data coupling relationships between high-level requirement items, and this should serve as the source of criteria for judging the correctness of data coupling in subsequent software lifecycle process results (including architecture design, low-level requirements, source code, etc.).

[0007] Currently, the industry lacks technical solutions that meet the above requirements. Summary of the Invention

[0008] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form to prepare for the more detailed descriptions that follow.

[0009] The purpose of this invention is to solve the above-mentioned problems and provide a method and apparatus for high-level software requirement data coupling coverage analysis. This method and apparatus solves the problem of the correctness of data coupling analysis throughout the entire life cycle of airborne software development (including high-level requirements, architecture design, low-level requirements, source code, etc.), and provides input and basis for evaluating the correctness of data coupling in downstream design outputs (including architecture design, low-level requirements, source code, etc.).

[0010] The technical solution of this invention is as follows: This invention discloses a method for high-level software requirement data coupling and coverage analysis, the method comprising:

[0011] Step 1: Organize the external input interfaces and external output interfaces of the software high-level requirements, and form a table of external input interfaces and a table of external output interfaces of the software high-level requirements.

[0012] Step 2: Taking each high-level software requirement item as the object, analyze and extract the input interface data and output interface data of the high-level software requirement item to form an input and output information table of the high-level software requirement.

[0013] Step 3: Decompose the input and output information tables of the software high-level requirements, extract the output information of the software high-level requirements to generate the internal data definition table of the software high-level requirements, and extract the input information of the software high-level requirements to generate the internal data usage table of the software high-level requirements.

[0014] Step 4: Merge the internal data definition table of the software high-level requirements and the external input interface table of the software high-level requirements to obtain their union, and generate the data definition table of the software high-level requirements. Merge the internal data usage table of the software high-level requirements and the external output interface table of the software high-level requirements to obtain their union, and generate the data usage table of the software high-level requirements.

[0015] Step 5: Check whether the usage data of the software's high-level requirements has a source and whether the output data of the software's high-level requirements has a destination;

[0016] Step 6: Exhaustively cross-pair each input data with the corresponding output data to form "definition-use" pairs of data with the same name;

[0017] Step 7: Based on the control flow logic formed by the order of arrangement among the software high-level requirement items, further divide the data "definition-use" pairs among the software high-level requirement items into two categories: normal and invalid.

[0018] Step 8: For the "definition-use" pairs of data between high-level software requirements that are accessible by control flow, sort out the source of input data and the destination of output data for each high-level software requirement, and generate data flow information between high-level software requirement items;

[0019] Step 9: Based on the valid "definition-use" pairs of data between high-level software requirements, regroup the data, and group the data with identical "definition" and "use" columns together to form a data flow between two high-level software requirement items / external interface devices, thus obtaining the high-level software requirement data flow dictionary and the corresponding data flow diagram.

[0020] Step 10: Based on the software high-level requirement data flow field, with the external input interface device as the starting point of the data flow, connect all the external input interface devices that are accessible through the data flow and are associated with the high-level requirement items, the software high-level requirement items, and the external output interface devices into a three-in-one system, forming all possible software test sequences. Then, select the software test sequences in which the processing logic and control flow relationship of the software high-level requirements are valid, forming scenario-based software test inputs, which also serve as the basis for designing test procedures based on software high-level requirements.

[0021] Step 11: Check if there is empty data in the input source and output destination of the software high-level requirement data coupling relationship table. If so, it can be determined that the data flow is abnormal. Submit the defect handling process to improve the software high-level requirements and then re-analyze. Otherwise, end the software high-level requirement data coupling analysis.

[0022] According to one embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, the analysis object in step 2 is a software high-level requirement item described in textual or tabular form.

[0023] According to an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, in the process of merging tables in step 4, duplicate data in the two tables are merged into one data item. The software high-level requirement data definition table includes the definition of internal interface data and the definition of external interface data, and the software high-level requirement data usage table includes the usage of internal interface data and the usage of external interface data.

[0024] According to an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, step 5 further includes:

[0025] For all usage data in the data usage table of the software high-level requirements, iteratively search the data definition table of the software high-level requirements to see if there is any definition data with the same name. For all definition data in the data definition table of the software high-level requirements, iteratively search the data usage table of the software high-level requirements to see if there is any usage / external output interface data with the same name. If no duplicate name is found in either iterative search, it can be determined as a data flow anomaly, and the defect handling process is submitted. After the software high-level requirements are improved, return to step 1 and repeat the coupling coverage analysis process. If the same name is found in both iterative searches, continue to step 6 to continue the coupling coverage analysis process.

[0026] According to an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, step 6 further includes:

[0027] Based on the data definition table and data usage table of high-level software requirements, all definitions and all uses of each high-level software requirement data are cross-paired to form multiple sets of possible "definition-use" pairs for high-level software requirement data. From these, "definition-use" pairs where the definition and use are limited to a single software requirement item are automatically deleted, forming "definition-use" pairs for data between high-level software requirements.

[0028] According to an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, step 7 further includes:

[0029] Based on the control flow relationship between software high-level requirement items, analyze the validity of the "definition-use" pairs in the "definition-use" pair table of software high-level requirement data item by item. Move the "definition-use" pairs that are not reachable in the control flow to the invalid "definition-use" pair table of software high-level requirement data, and move the "definition-use" pairs that are reachable in the control flow to the valid "definition-use" pair table of software high-level requirement data.

[0030] According to an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, step 8 further includes:

[0031] Based on the "definition-use" pairing table of valid high-level software requirements data, and referring to the external input interface table and external output interface table of high-level software requirements, the input and output information tables of high-level software requirements are expanded to supplement the input sources and output destinations. The data coupling relationship analysis between related high-level software requirement items is completed, forming a coupling relationship table of high-level software requirement data. This table serves as the basis for judging the correctness of software architecture and low-level requirement data coupling, as well as as the injection interface for requirement-based software integration test cases and as the basis for assisting in calculating the expected test output.

[0032] According to one embodiment of the software high-level requirement data coupling coverage analysis method of the present invention, the possible software test sequences concatenated in step 10 are performed according to the depth-first principle.

[0033] This invention also discloses a software high-level requirement data coupling coverage analysis device, which includes a data coupling relationship mining module and a software test sequence construction module.

[0034] The data coupling relationship mining module is used to mine the data coupling relationships between high-level software requirements, including:

[0035] The sorting unit is configured to sort out the external input interfaces and external output interfaces of the software high-level requirements, forming a table of external input interfaces and a table of external output interfaces of the software high-level requirements.

[0036] The analysis unit is configured to analyze and extract the input interface data and output interface data of each high-level software requirement item, and form an input and output information table of the high-level software requirement.

[0037] The unit is configured to split the input and output information tables of the software high-level requirements, extract the output information of the software high-level requirements to generate the internal data definition table of the software high-level requirements, and extract the input information of the software high-level requirements to generate the internal data usage table of the software high-level requirements.

[0038] The merging unit is configured to merge the internal data definition table of the software high-level requirements and the external input interface table of the software high-level requirements to obtain the union of the two, thereby generating the data definition table of the software high-level requirements; and to merge the internal data usage table of the software high-level requirements and the external output interface table of the software high-level requirements to obtain the union of the two, thereby generating the data usage table of the software high-level requirements.

[0039] The inspection unit is configured to check whether the usage data of the software's high-level requirements has a source and whether the output data of the software's high-level requirements has a destination.

[0040] The pairing unit is configured to exhaustively cross-pair each input data with the same-name output data to form a "definition-use" pair of data with the same name;

[0041] The classification unit is configured to further divide the data "definition-use" pairs between software high-level requirement items into two categories: normal and invalid, based on the control flow logic formed by the order of arrangement between the software high-level requirement items.

[0042] The data flow generation unit is configured to identify the source of input data and the destination of output data for each high-level software requirement that is accessible through control flow, and generate data flow information between high-level software requirement items.

[0043] The software test sequence construction module is used to leverage the data coupling relationships between high-level software requirements to assist in forming software test sequences, including:

[0044] The data flow dictionary and data flow diagram generation unit is configured to regroup the data based on the valid "definition-use" pairs between software high-level requirements, grouping data with identical "definition" and "use" columns into one group to form the data flow between two software high-level requirement items / external interface devices, thus obtaining the software high-level requirement data flow dictionary and the corresponding data flow diagram.

[0045] The software test sequence filtering unit is configured to use the external input interface device as the starting point of the data flow based on the software high-level requirement data flow field. It integrates the external input interface device that is accessible through the data flow and is associated with the high-level requirement item, the software high-level requirement item, and the external output interface device into a three-in-one system, and then filters out the software test sequences in which the processing logic and control flow relationship of the software high-level requirement are valid, forming a scenario-based software test input, and at the same time serving as the basis for designing test procedures based on the software high-level requirement.

[0046] The data flow anomaly checking unit is configured to check whether there is empty data in the input source and output destination of the software high-level requirement data coupling relationship table. If so, it can be determined as a data flow anomaly, and the defect handling process is submitted to improve the software high-level requirements and then re-analyze. Otherwise, the software high-level requirement data coupling analysis is terminated.

[0047] According to one embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention, the software high-level requirement entries in the analysis unit are described in textual or tabular form.

[0048] According to an embodiment of the software high-level requirement data coupling coverage analysis device of the present invention, the merging unit merges duplicate data in two tables into one data item during the merging process. The software high-level requirement data definition table includes the definition of the internal interface data output by the requirement item and the definition of the external device input interface data. The software high-level requirement data usage table includes the usage of the internal interface data input by the requirement item and the usage of the external device output interface data.

[0049] According to an embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention, the inspection unit is further configured as follows:

[0050] For all usage data in the data usage table of the software high-level requirements, iteratively search the data definition table of the software high-level requirements to see if there is any definition data with the same name. For all definition data in the data definition table of the software high-level requirements, iteratively search the data usage table of the software high-level requirements to see if there is any usage / external output interface data with the same name. If no duplicate name is found in either iterative search, it can be determined as a data flow anomaly, and the defect handling process is submitted. After the software high-level requirements are improved, return to the sorting unit to re-perform the coupling coverage analysis process. If the same name is found in both iterative searches, continue to execute the pairing unit to continue the coupling coverage analysis process.

[0051] According to an embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention, the pairing unit is further configured as follows:

[0052] Based on the data definition table and data usage table of high-level software requirements, all definitions and all uses of each high-level software requirement data are cross-paired to form multiple sets of possible "definition-use" pairs for high-level software requirement data. From these, "definition-use" pairs where the definition and use are limited to a single software requirement item are automatically deleted, forming "definition-use" pairs for data between high-level software requirements.

[0053] According to an embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention, the classification unit is further configured as follows:

[0054] Based on the control flow relationship between software high-level requirement items, analyze the validity of the "definition-use" pairs in the "definition-use" pair table of software high-level requirement data item by item. Move the "definition-use" pairs that are not reachable in the control flow to the invalid "definition-use" pair table of software high-level requirement data, and move the "definition-use" pairs that are reachable in the control flow to the valid "definition-use" pair table of software high-level requirement data.

[0055] According to an embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention, the data flow generation unit is further configured as follows:

[0056] Based on the "definition-use" pairing table of valid high-level software requirements data, and referring to the external input interface table and external output interface table of high-level software requirements, the input and output information tables of high-level software requirements are expanded to supplement the input sources and output destinations. The data coupling relationship analysis between related high-level software requirement items is completed, forming a coupling relationship table of high-level software requirement data. This table serves as the basis for judging the correctness of software architecture and low-level requirement data coupling, as well as as the injection interface for requirement-based software integration test cases and as the basis for assisting in calculating the expected test output.

[0057] According to one embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention, the possible software test sequences in the software test sequence screening unit are connected in accordance with the depth-first principle.

[0058] The present invention also discloses a computer device including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the steps of the method described above.

[0059] The present invention also discloses a computer-readable medium having stored thereon computer program instructions that, when executed by a processor, implement the steps of the method described above.

[0060] The present invention also discloses a computer program product comprising computer program instructions that, when executed by a processor, implement the steps of the method described above.

[0061] Compared with existing technologies, this invention has the following advantages: Firstly, by extracting the directly defined input (use) and output (definition) information from each high-level requirement, and pairing output information with corresponding input information, combined with the sequence of control flow, this invention analyzes the source (definition) of input information and the destination (use) of output information, forming data "definition-use" pairs between high-level requirement items. This yields the data coupling relationship between different requirement items and categorizes them into normal, invalid, and abnormal data flow information. The normal and invalid data flow information can serve as a basis for evaluating the correctness of data coupling in downstream design output results, while abnormal data flow information is treated as a software defect and submitted for correction.

[0062] On the other hand, this invention generates a data flow (including a data flow dictionary and data flow graph) based on the judgment results of the definition-use pairs between high-level requirement items, and then generates a software test sequence based on high-level requirements, providing a basis for writing test procedures based on high-level requirements. This solution is a high-level requirement data flow relationship consistency analysis carried out under the constraints of external interface definitions and internal control flow. While discovering defects in the high-level requirement data coupling relationship, it establishes the correctness criteria for the data coupling relationship of downstream design outputs such as architecture design, low-level requirements, and source code.

[0063] In summary, this invention addresses the issue of itemized high-level requirements by constructing a data coupling analysis process for high-level software requirements based on external interface definitions and internal control flows. This process can solve the fundamental problem of determining the correctness of data coupling analysis results for downstream design outputs (including architecture design, low-level requirements, source code, etc.) in the software lifecycle. Attached Figure Description

[0064] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related characteristics or features may have the same or similar reference numerals.

[0065] Figure 1 A flowchart of an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention is shown.

[0066] Figure 2 A schematic diagram of the high-level demand data flow of the present invention is shown.

[0067] Figure 3 A schematic diagram of an embodiment of the software high-level requirement data coupling coverage analysis device of the present invention is shown. Detailed Implementation

[0068] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that the aspects described below with reference to the accompanying drawings and specific embodiments are merely exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0069] In the airborne software development lifecycle, high-level requirements are the starting point and input for the software development process. According to DO-178C, high-level requirements refer to software requirements developed through analysis of system requirements, safety-related requirements, and system architecture. Based on the general attributes of requirements, a complete requirement entry should at least include three components: input, processing, and output; that is, by processing and manipulating input data, output data is generated.

[0070] The software high-level requirement data coupling analysis method serves as the starting point for determining the correctness of data coupling relationships throughout the software lifecycle. It primarily checks the consistency of data coupling relationships within software high-level requirements, meaning that each high-level requirement's input should have a source and its output should have a destination (both sources and destinations include two main categories: external interfaces and internal interfaces).

[0071] For ease of description, this invention divides high-level requirement data flows into three categories, as detailed below:

[0072] a. Normal information of high-level demand data flow: A "definition-use" pair is formed between input and output that is reachable in the control flow, including both unconditional accessibility and conditional accessibility.

[0073] b. Invalid information in high-level requirement data flow: The "definition-use" pair formed between input and output is unreachable in the control flow. This type of information is a disturbance item in high-level requirement data coupling analysis and does not need to be saved or further processed.

[0074] c. High-level requirement data flow anomaly information: For input data with no source (if for input data of a certain high-level requirement, there is no output data with the same name in all other high-level requirement entries, nor is it in the external input interface list, then the data lacks a source), or output data with no destination (if for output data of a certain high-level requirement, there is no input data with the same name in all other high-level requirement entries, nor is it in the external output interface list, then the data lacks a destination), since a "definition-use" pair cannot be formed, it can be determined as a data flow anomaly, and it is necessary to submit the software defect handling process for correction.

[0075] Figure 1 The flowchart illustrates an embodiment of the software high-level requirement data coupling coverage analysis method of the present invention. Please refer to [link to flowchart illustration]. Figure 1 The following is a detailed description of the implementation steps of the software high-level requirement data coupling coverage analysis method in this embodiment.

[0076] Step 1: Organize the external (input and output) interfaces of the software's high-level requirements, forming Table 1-0-0 of the external input interfaces (definition data) of the software's high-level requirements and Table 1-0-1 of the external output interfaces (usage data) of the software's high-level requirements.

[0077] Table 1 External Input Interfaces for High-Level Software Requirements (Table 1-0-0)

[0078]

[0079] Table 2 External Output Interfaces for High-Level Software Requirements (Table 1-0-1)

[0080]

[0081] Step 2: Taking each software high-level requirement item described in text or table form as the object, analyze and extract the input (use) interface data and output (definition) interface data of the software high-level requirement item (for input interface data, the software high-level requirement is where the input data is used; for output interface data, the software high-level requirement is where the output data is defined), and form the input and output information table 1-1 of the software high-level requirement.

[0082] Table 3 Input and Output Information for High-Level Software Requirements (Table 1-1)

[0083]

[0084] Step 3: Decompose the input and output information table 1-1 of the software high-level requirements, extract the output information of the software high-level requirements, generate the internal data definition table 1-2-1 of the software high-level requirements, extract the input information of the software high-level requirements, and generate the internal data usage table 1-3-1 of the software high-level requirements.

[0085] Table 4 Internal Data Definitions for High-Level Software Requirements (Table 1-2-1)

[0086]

[0087] Table 5 uses internal data from Table 1-3-1 to define software high-level requirements.

[0088]

[0089] Step 4: Check if there is duplicate data in the internal data definition table 1-2-1 and the external input interface table 1-0-0 of the software high-level requirements. If duplicate data is found, first determine if the duplicate data is valid, then merge the two tables to obtain their union. During the merging process, duplicate data in the two tables are merged into a single data item. Finally, generate the data definition table 1-2 for the software high-level requirements, which includes the definitions of internal and external interface data. Also, check if there is duplicate data in the internal data usage table 1-3-1 and the external output interface table 1-0-1 of the software high-level requirements. If duplicate data is found, first determine if the duplicate data is valid, then merge the two tables to obtain their union. During the merging process, duplicate data in the two tables are merged into a single data item. Finally, generate the data usage table 1-3 for the software high-level requirements, which includes the usage of internal and external interface data.

[0090] Table 6 Data Definitions for High-Level Software Requirements (Table 1-2)

[0091]

[0092]

[0093] Table 7 uses data from Tables 1-3 to represent the software high-level requirements.

[0094]

[0095] Step 5: Check if the usage data of the software high-level requirements has a source and if the output data of the software high-level requirements has a destination: For all usage data in Tables 1-3 of the software high-level requirements data usage, iteratively search Tables 1-2 of the software high-level requirements data definition to see if there is any data with the same name. Similarly, for all definition data in Tables 1-2 of the software high-level requirements data definition, iteratively search Tables 1-3 of the software high-level requirements data usage to see if there is any data with the same name (data with the same name refers to data usage that includes both internal and external interface data). If no data with the same name is found in either iterative search, it can be determined that the data flow is abnormal. Submit the defect handling process, improve the software high-level requirements, and return to Step 1 to repeat the analysis process of this invention. If the same name is found in both iterative searches, proceed to Step 6 to continue the analysis process of this invention.

[0096] Step 6: Exhaustively cross-pair each input data with the same-named output data (data with the same name is considered the same data) to form "definition-use" pairs of data with the same name: Based on the data definition table 1-2 and the data usage table 1-3 of the software high-level requirements, cross-pair all definitions (e.g., at m) and all uses (e.g., at n) of each software high-level requirement data to form (m*n groups) of possible "definition-use" pairs of software high-level requirement data in Table 1-4-0; automatically delete "definition-use" pairs whose definition and use are limited to one requirement item (within) (e.g., for recursive definition requirements) to form "definition-use" pairs of data between software high-level requirements in Table 1-4-1.

[0097] Step 7: Based on the control flow logic formed by the order of arrangement among the software high-level requirement items, further divide the data "definition-use" pairs between the software high-level requirement items into two categories: normal (valid) and invalid. According to the control flow relationship between the software high-level requirement items, analyze the validity of the "definition-use" pairs in Table 1-4-1 one by one. Move the "definition-use" pairs that are unreachable (invalid) in the control flow to the invalid software high-level requirement data "definition-use" pairs Table 1-4-2, and move the "definition-use" pairs that are reachable (valid) in the control flow to the valid software high-level requirement data "definition-use" pairs Table 1-4.

[0098] Table 8 shows the "Definition-Use" of high-level software requirement data in relation to Table 1-4-0, the "Definition-Use" of high-level software requirement data in relation to Table 1-4-1, the "Definition-Use" of invalid high-level software requirement data in relation to Table 1-4-2, and the "Definition-Use" of valid high-level software requirement data in relation to Table 1-4-0.

[0099]

[0100] Step 8: For the "definition-use" pairs of data between high-level software requirements accessible by control flow, analyze the source (definition) of the input data (use) and the destination (use) of the output data (definition) for each high-level software requirement, generating data flow information between high-level software requirement items: Based on the valid "definition-use" pairs of data between high-level software requirements in Table 1-4, and referring to the external input interface table 1-0-0 and the external output interface table 1-0-1 of high-level software requirements, expand the input and output information table 1-1 of high-level software requirements, supplementing the "input source" and "output destination," completing the data coupling relationship analysis between related high-level software requirement items, forming the coupling relationship table 1-5 of high-level software requirement data, which serves as the basis for judging the correctness of software architecture and low-level requirement data coupling; as the interface for injecting software integration test cases based on requirements, and as the basis for assisting in calculating the expected test output.

[0101] Table 9. Software High-Level Requirements Data Coupling Relationships (Table 1-5)

[0102]

[0103]

[0104] Steps 1 to 8 above are used to uncover the data coupling relationships between high-level software requirements.

[0105] Step 9: Based on the valid software high-level requirement data "definition-use" in Table 1-4, regroup the data, and group the data with identical "definition" and "use" columns together to form a data flow between two software high-level requirement items / external interface devices, thus obtaining the software high-level requirement data flow dictionary 1-6 and the corresponding data flow diagram.

[0106] Table 10 Software High-Level Requirements Data Flow Dictionary 1-6

[0107]

[0108] Step 10: Based on the software high-level requirement data flow fields 1-6 and the external input interface device (which can be identified as EIDin) as the starting point of the data flow, following the depth-first principle, connect all the external input interface devices (which can be identified as EIDin), software high-level requirement items (which can be identified as UIDx, where x is an Arabic numeral representing the sequence number), and external output interface devices (which can be identified as EIDout) that are accessible through the data flow and are associated with the high-level requirement items, into a possible software test sequence. Then, select the software test sequences whose processing logic and control flow relationships of the software high-level requirements are valid to form scenario-based software test inputs, which also serve as the basis for designing test procedures based on software high-level requirements. For example, if there is a unidirectional data flow (denoted by DF0) between the external input interface device EIDin and the high-level requirement item UID1, a unidirectional data flow (denoted by DF1) between the high-level requirement items UID1 and UID2, a unidirectional data flow (denoted by DF2) between the high-level requirement items UID2 and UID3, a unidirectional data flow (denoted by DF3) between the high-level requirement items UID1 and UID3, and a unidirectional data flow (denoted by DF4) between the high-level requirement item UID3 and the external input interface device EIDin, then there are two software test sequences: EIDin——UID1——UID3——EIDout and EIDin——UID1——UID2——UID3——EIDout.

[0109] Step 11: Check if there is any empty data in the "Input Source" and "Output Destination" fields of Table 1-5, which represents the software high-level requirements data coupling relationship. If so, it indicates a data flow anomaly. Submit the defect handling process, improve the software high-level requirements, and re-analyze. Otherwise, end the software high-level requirements data coupling analysis.

[0110] Steps 9 to 11 above utilize the data coupling relationships between high-level software requirements discovered in steps 1 to 8 to assist in forming a software test sequence.

[0111] Figure 3 The principle of one embodiment of the software high-level requirement data coupling coverage analysis apparatus of the present invention is illustrated. Please refer to [link to previous text]. Figure 3 The apparatus in this embodiment includes a data coupling relationship mining module and a software test sequence construction module. The data coupling relationship mining module is used to mine the data coupling relationships between high-level software requirement items. The software test sequence construction module is used to utilize the mined data coupling relationships between high-level software requirements to assist in forming a software test sequence.

[0112] The data coupling relationship mining module includes: sorting unit, analysis unit, splitting unit, merging unit, checking unit, pairing unit, classification unit, and data stream generation unit.

[0113] The sorting unit is configured as follows: sort out the external input interfaces and external output interfaces of the software high-level requirements, and form a table of external input interfaces and a table of external output interfaces of the software high-level requirements.

[0114] The analysis unit is configured to: take each software high-level requirement item as the object, analyze and extract the input interface data and output interface data of the software high-level requirement item, and form the input and output information table of the software high-level requirement.

[0115] The analysis objects in the analysis unit are high-level software requirement items described in textual or tabular form.

[0116] The splitting unit is configured as follows: split the input and output information tables of the software high-level requirements, extract the output information of the software high-level requirements to generate the internal data definition table of the software high-level requirements, and extract the input information of the software high-level requirements to generate the internal data usage table of the software high-level requirements.

[0117] The merging unit is configured as follows: merge the internal data definition table of the software high-level requirements and the external input interface table of the software high-level requirements to obtain their union, and generate the data definition table of the software high-level requirements; merge the internal data usage table of the software high-level requirements and the external output interface table of the software high-level requirements to obtain their union, and generate the data usage table of the software high-level requirements.

[0118] During the merging process, the merging unit combines duplicate data from two tables into a single data item. The data definition table for high-level software requirements includes the definition of internal interface data for requirement items and the definition of input interface data for external devices. The data usage table for high-level software requirements includes the usage of internal interface data for requirement items and the usage of output interface data for external devices.

[0119] The inspection unit is configured to check whether the usage data of the software's high-level requirements has a source and whether the output data of the software's high-level requirements has a destination.

[0120] The inspection unit is further configured as follows: for all usage data in the data usage table of the software high-level requirements, it iteratively searches the data definition table of the software high-level requirements to see if there is any definition data with the same name. For all definition data in the data definition table of the software high-level requirements, it iteratively searches the data usage table of the software high-level requirements to see if there is any usage / external output interface data with the same name. If no matching name is found in either iterative search, it can be determined as a data flow anomaly, and the defect handling process is submitted. After the software high-level requirements are improved, it returns to the sorting unit to re-perform the coupling coverage analysis process. If the same name is found in both iterative searches, the pairing unit is executed to continue the coupling coverage analysis process.

[0121] The pairing unit is configured to exhaustively cross-pair each input data with the same-name output data to form a "definition-use" pair of data with the same name.

[0122] The pairing unit is further configured as follows: based on the data definition table and the data usage table of the software high-level requirements, all definitions and all uses of each software high-level requirement data are cross-paired to form multiple sets of possible "definition-use" pairs of software high-level requirement data; from these pairs, "definition-use" pairs where the definition and use are limited to a single software requirement item are automatically deleted to form "definition-use" pairs of data between software high-level requirements.

[0123] The classification unit is configured as follows: based on the control flow logic formed by the order of arrangement among the software high-level requirement items, the data "definition-use" pairs among the software high-level requirement items are further divided into two categories: normal and invalid.

[0124] The classification unit is further configured as follows: based on the control flow relationship between software high-level requirement items, analyze the validity of the "definition-use" pairs in the "definition-use" pair table of software high-level requirement data item by item, move the "definition-use" pairs that are not reachable in the control flow to the invalid "definition-use" pair table of software high-level requirement data, and move the "definition-use" pairs that are reachable in the control flow to the valid "definition-use" pair table of software high-level requirement data.

[0125] The data flow generation unit is configured to define and use data between high-level software requirements that are accessible through control flow. It sorts out the source of input data and the destination of output data for each high-level software requirement, and generates data flow information between high-level software requirement items.

[0126] The data flow generation unit is further configured to: expand the input and output information tables of software high-level requirements based on the "definition-use" pair table of valid software high-level requirements data, and refer to the external input interface table and external output interface table of software high-level requirements, supplement the input sources and output destinations, complete the data coupling relationship analysis between related software high-level requirement items, and form a coupling relationship table of software high-level requirement data. This table serves as the basis for judging the correctness of software architecture and low-level requirement data coupling, as well as as the interface for injecting requirement-based software integration test cases and as the basis for assisting in calculating the expected test output.

[0127] The software test sequence construction module includes: a data flow dictionary and data flow graph generation unit, a software test sequence filtering unit, and a data flow anomaly checking unit.

[0128] The data flow dictionary and data flow diagram generation unit is configured as follows: based on the valid "definition-use" pairs of data between high-level software requirements, the data is regrouped, and data with identical "definition" and "use" columns are grouped together to form a data flow between two high-level software requirement items / external interface devices, thus obtaining the high-level software requirement data flow dictionary and the corresponding data flow diagram.

[0129] The software test sequence filtering unit is configured as follows: based on the software high-level requirement data flow field, with the external input interface device as the starting point of the data flow, the external input interface devices that are connected through the high-level requirement items and reachable by the data flow, the software high-level requirement items, and the external output interface devices are all linked together to form possible software test sequences. Then, the software test sequences with valid processing logic and control flow relationships of the software high-level requirements are filtered to form scenario-based software test inputs, which also serve as the basis for designing test procedures based on software high-level requirements.

[0130] The possible software test sequences are concatenated in the software test sequence selection unit according to the depth-first principle.

[0131] The data flow anomaly checking unit is configured to check whether there is empty data in the input source and output destination of the software high-level requirement data coupling relationship table. If so, it can be determined as a data flow anomaly, and the defect handling process is submitted to improve the software high-level requirements and then re-analyze. Otherwise, the software high-level requirement data coupling analysis is terminated.

[0132] Furthermore, this invention discloses a computer device including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform, for example... Figure 1 The steps of the method are shown. Since the steps of the method have been described in detail in the foregoing embodiments, they will not be repeated here.

[0133] Furthermore, this invention discloses a computer-readable medium storing computer program instructions that, when executed by a processor, implement as follows: Figure 1 The steps of the method are shown. Since the steps of the method have been described in detail in the foregoing embodiments, they will not be repeated here.

[0134] Furthermore, this invention discloses a computer program product, including computer program instructions, characterized in that, when executed by a processor, the computer program instructions implement as follows: Figure 1 The steps of the method are shown. Since the steps of the method have been described in detail in the foregoing embodiments, they will not be repeated here.

[0135] Although the methods described above are illustrated and depicted as a series of actions for the sake of simplicity, it should be understood and appreciated that these methods are not limited by the order of the actions, as some actions may occur in a different order and / or concurrently with other actions from the illustrations and descriptions herein or not illustrated and described herein but which may be understood by those skilled in the art, according to one or more embodiments.

[0136] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0137] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0138] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

[0139] In one or more exemplary embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functionality may be stored or transmitted as one or more instructions or code on or through a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible to a computer. Any connection is also legitimately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. As used in this article, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0140] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for high-level software requirement data coupling and coverage analysis, characterized in that, The methods include: Step 1: Organize the external input interfaces and external output interfaces of the software high-level requirements, and form a table of external input interfaces and a table of external output interfaces of the software high-level requirements. Step 2: Taking each high-level software requirement item as the object, analyze and extract the input interface data and output interface data of the high-level software requirement item to form an input and output information table of the high-level software requirement. Step 3: Decompose the input and output information tables of the software high-level requirements, extract the output information of the software high-level requirements to generate the internal data definition table of the software high-level requirements, and extract the input information of the software high-level requirements to generate the internal data usage table of the software high-level requirements. Step 4: Merge the internal data definition table of the software high-level requirements and the external input interface table of the software high-level requirements to obtain their union, and generate the data definition table of the software high-level requirements. Merge the internal data usage table of the software high-level requirements and the external output interface table of the software high-level requirements to obtain their union, and generate the data usage table of the software high-level requirements. Step 5: Check whether the usage data of the software's high-level requirements has a source and whether the output data of the software's high-level requirements has a destination; Step 6: Exhaustively cross-pair each input data with the corresponding output data to form "definition-use" pairs of data with the same name; Step 7: Based on the control flow logic formed by the order of arrangement among the software high-level requirement items, further divide the data "definition-use" pairs among the software high-level requirement items into two categories: normal and invalid. Step 8: For the "definition-use" pairs of data between high-level software requirements that are accessible by control flow, sort out the source of input data and the destination of output data for each high-level software requirement, and generate data flow information between high-level software requirement items; Step 9: Based on the valid "definition-use" data pairs between high-level software requirements, regroup the data, grouping data with identical "definition" and "use" columns together to form a data flow between two high-level software requirement items / external interface devices, thus obtaining the high-level software requirement data flow dictionary and the corresponding data flow diagram. Step 10: Based on the software high-level requirement data flow field, with the external input interface device as the starting point of the data flow, connect all the external input interface devices that are accessible through the data flow and are associated with the high-level requirement items, the software high-level requirement items, and the external output interface devices into a three-in-one system, forming all possible software test sequences. Then, select the software test sequences in which the processing logic and control flow relationship of the software high-level requirements are valid, forming scenario-based software test inputs, which also serve as the basis for designing test procedures based on software high-level requirements. Step 11: Check if there is empty data in the input source and output destination of the software high-level requirement data coupling relationship table. If so, it can be determined that the data flow is abnormal. Submit the defect handling process to improve the software high-level requirements and then re-analyze. Otherwise, end the software high-level requirement data coupling analysis.

2. The software high-level requirement data coupling and coverage analysis method according to claim 1, characterized in that, The analysis objects in step 2 are high-level software requirements items described in textual or tabular form.

3. The software high-level requirement data coupling and coverage analysis method according to claim 1, characterized in that, In the process of merging tables in step 4, duplicate data in the two tables are merged into one data item. The data definition table of software high-level requirements contains the definition of the internal interface data output of the requirement item and the definition of the external device input interface data. The data usage table of software high-level requirements contains the usage of the internal interface data input of the requirement item and the usage of the external device output interface data.

4. The software high-level requirement data coupling and coverage analysis method according to claim 1, characterized in that, Step 5 further includes: For all usage data in the data usage table of the software high-level requirements, iteratively search the data definition table of the software high-level requirements to see if there is any definition data with the same name. For all definition data in the data definition table of the software high-level requirements, iteratively search the data usage table of the software high-level requirements to see if there is any usage / external output interface data with the same name. If no duplicate name is found in either iterative search, it can be determined as a data flow anomaly, and the defect handling process is submitted. After the software high-level requirements are improved, return to step 1 and repeat the coupling coverage analysis process. If the same name is found in both iterative searches, continue to step 6 to continue the coupling coverage analysis process.

5. The software high-level requirement data coupling and coverage analysis method according to claim 1, characterized in that, Step 6 further includes: Based on the data definition table and data usage table of high-level software requirements, all definitions and all uses of each high-level software requirement data are cross-paired to form multiple sets of possible "definition-use" pairs for high-level software requirement data. From these, "definition-use" pairs where the definition and use are limited to a single software requirement item are automatically deleted, forming "definition-use" pairs for data between high-level software requirements.

6. The software high-level requirement data coupling and coverage analysis method according to claim 5, characterized in that, Step 7 further includes: Based on the control flow relationship between software high-level requirement items, analyze the validity of the "definition-use" pairs in the "definition-use" pair table of software high-level requirement data item by item. Move the "definition-use" pairs that are not reachable in the control flow to the invalid "definition-use" pair table of software high-level requirement data, and move the "definition-use" pairs that are reachable in the control flow to the valid "definition-use" pair table of software high-level requirement data.

7. The software high-level requirement data coupling and coverage analysis method according to claim 6, characterized in that, Step 8 further includes: Based on the "definition-use" pairing table of valid high-level software requirements data, and referring to the external input interface table and external output interface table of high-level software requirements, the input and output information tables of high-level software requirements are expanded to supplement the input sources and output destinations. The data coupling relationship analysis between related high-level software requirement items is completed, forming a coupling relationship table of high-level software requirement data. This table serves as the basis for judging the correctness of software architecture and low-level requirement data coupling, as well as as the injection interface for requirement-based software integration test cases and as the basis for assisting in calculating the expected test output.

8. The software high-level requirement data coupling and coverage analysis method according to claim 1, characterized in that, The possible software test sequences are concatenated in step 10 according to the depth-first principle.

9. A software high-level requirement data coupling coverage analysis device, characterized in that, The device includes a data coupling relationship mining module and a software test sequence construction module. The data coupling relationship mining module is used to mine the data coupling relationships between high-level software requirements, including: The sorting unit is configured to sort out the external input interfaces and external output interfaces of the software high-level requirements, forming a table of external input interfaces and a table of external output interfaces of the software high-level requirements. The analysis unit is configured to analyze and extract the input interface data and output interface data of each high-level software requirement item, and form an input and output information table of the high-level software requirement. The unit is configured to split the input and output information tables of the software high-level requirements, extract the output information of the software high-level requirements to generate the internal data definition table of the software high-level requirements, and extract the input information of the software high-level requirements to generate the internal data usage table of the software high-level requirements. The merging unit is configured to merge the internal data definition table of the software high-level requirements and the external input interface table of the software high-level requirements to obtain the union of the two, thereby generating the data definition table of the software high-level requirements; and to merge the internal data usage table of the software high-level requirements and the external output interface table of the software high-level requirements to obtain the union of the two, thereby generating the data usage table of the software high-level requirements. The inspection unit is configured to check whether the usage data of the software's high-level requirements has a source and whether the output data of the software's high-level requirements has a destination. The pairing unit is configured to exhaustively cross-pair each input data with the same-name output data to form "definition-use" pairs of data with the same name; The classification unit is configured to further divide the data "definition-use" pairs between software high-level requirement items into two categories: normal and invalid, based on the control flow logic formed by the order of arrangement between the software high-level requirement items. The data flow generation unit is configured to identify the source of input data and the destination of output data for each high-level software requirement that is reachable from the control flow, and generate data flow information between the high-level software requirement items. The software test sequence construction module is used to leverage the data coupling relationships between high-level software requirements to assist in forming software test sequences, including: The data flow dictionary and data flow diagram generation unit is configured to regroup the data based on the valid "definition-use" pairs between software high-level requirements, grouping data with identical "definition" and "use" columns into one group to form a data flow between two software high-level requirement items / external interface devices, thus obtaining the software high-level requirement data flow dictionary and the corresponding data flow diagram. The software test sequence filtering unit is configured to use the external input interface device as the starting point of the data flow based on the software high-level requirement data flow field. It integrates the external input interface device that is accessible through the data flow and is associated with the high-level requirement item, the software high-level requirement item, and the external output interface device into a three-in-one system, and then filters out the software test sequences in which the processing logic and control flow relationship of the software high-level requirement are valid, forming a scenario-based software test input, and at the same time serving as the basis for designing test procedures based on the software high-level requirement. The data flow anomaly checking unit is configured to check whether there is empty data in the input source and output destination of the software high-level requirement data coupling relationship table. If so, it can be determined as a data flow anomaly, and the defect handling process is submitted to improve the software high-level requirements and then re-analyze. Otherwise, the software high-level requirement data coupling analysis is terminated.

10. The software high-level requirement data coupling and coverage analysis device according to claim 9, characterized in that, The analysis objects in the analysis unit are high-level software requirement items described in textual or tabular form.

11. The software high-level requirement data coupling and coverage analysis device according to claim 9, characterized in that, During the merging process, the merging unit combines duplicate data from two tables into a single data item. The data definition table for high-level software requirements includes the definition of internal interface data for requirement items and the definition of input interface data for external devices. The data usage table for high-level software requirements includes the usage of internal interface data for requirement items and the usage of output interface data for external devices.

12. The software high-level requirement data coupling and coverage analysis device according to claim 9, characterized in that, The inspection unit is further configured as follows: For all usage data in the data usage table of the software high-level requirements, iteratively search the data definition table of the software high-level requirements to see if there is any definition data with the same name. For all definition data in the data definition table of the software high-level requirements, iteratively search the data usage table of the software high-level requirements to see if there is any usage / external output interface data with the same name. If no duplicate name is found in either iterative search, it can be determined as a data flow anomaly, and the defect handling process is submitted. After the software high-level requirements are improved, return to the sorting unit to re-perform the coupling coverage analysis process. If the same name is found in both iterative searches, continue to execute the pairing unit to continue the coupling coverage analysis process.

13. The software high-level requirement data coupling and coverage analysis device according to claim 9, characterized in that, The pairing unit is further configured as follows: Based on the data definition table and data usage table of high-level software requirements, all definitions and all uses of each high-level software requirement data are cross-paired to form multiple sets of possible "definition-use" pairs for high-level software requirement data. From these, "definition-use" pairs where the definition and use are limited to a single software requirement item are automatically deleted, forming "definition-use" pairs for data between high-level software requirements.

14. The software high-level requirement data coupling and coverage analysis device according to claim 13, characterized in that, The classification unit is further configured as follows: Based on the control flow relationship between software high-level requirement items, analyze the validity of the "definition-use" pairs in the "definition-use" pair table of software high-level requirement data item by item. Move the "definition-use" pairs that are not reachable in the control flow to the invalid "definition-use" pair table of software high-level requirement data, and move the "definition-use" pairs that are reachable in the control flow to the valid "definition-use" pair table of software high-level requirement data.

15. The software high-level requirement data coupling and coverage analysis device according to claim 14, characterized in that, The data stream generation unit is further configured as follows: Based on the "definition-use" pairing table of valid high-level software requirements data, and referring to the external input interface table and external output interface table of high-level software requirements, the input and output information tables of high-level software requirements are expanded to supplement the input sources and output destinations. The data coupling relationship analysis between related high-level software requirement items is completed, forming a coupling relationship table of high-level software requirement data. This table serves as the basis for judging the correctness of software architecture and low-level requirement data coupling, as well as as the injection interface for requirement-based software integration test cases and as the basis for assisting in calculating the expected test output.

16. The software high-level requirement data coupling and coverage analysis device according to claim 9, characterized in that, The possible software test sequences are concatenated in the software test sequence selection unit according to the depth-first principle.

17. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method of claim 1.

18. A computer-readable medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the method of claim 1.

19. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the method of claim 1.

Images