A chip system test requirement analysis method, device and medium

Abstract

The application discloses a chip system test requirement analysis method, device and medium, relates to the chip system test technical field, and aims at the problem of incomplete analysis in the chip system test requirement analysis at present, and provides a chip system test requirement analysis method. The test analysis process is completed by a test personnel with the aid of a visual tool in a four-layer step-by-step test analysis mode, the level and experience difference of different test personnel are isolated, and the quality of test analysis is improved. In addition, the method can also guide the test personnel to input corresponding description information during requirement analysis at each layer, so that all necessary elements required by a requirement document in a test analysis process are acquired, and omission is avoided. Furthermore, test case description is automatically generated based on the acquired description information, and is output as a requirement document of the test project, so that the problems of omission and the like caused by manual output of the requirement analysis document can be effectively avoided.

Description

Technical Field

[0001] This invention relates to the field of chip system testing, and in particular to a chip system testing requirements analysis method, apparatus and medium. Background Technology

[0002] Currently, the test analysis process for chip systems includes four stages: test requirements analysis, test case writing, test execution, and test reporting. Among these, test requirements analysis requires testers to start with the development requirements and output a test requirements analysis document to guide the writing of test cases in the next stage.

[0003] However, current test requirements analysis relies entirely on manual work by testers. The process from development requirements to the output of test requirements analysis documents guiding test case writing involves numerous and complex analytical activities, making it highly susceptible to overlooking test analysis elements (such as missing test scenarios or test factors). Furthermore, differences in background experience and technical skill levels among testers can lead to analyses that only cover normal functional tests, resulting in weak reliability analysis or only functional tests without stress-related tests, leading to omissions in test type analysis. Even when requirements analysis documents are templated to guide testers, the lack of tools for format checking prevents their effective implementation.

[0004] Therefore, those skilled in the art urgently need a chip system test requirements analysis method to solve the problem of incomplete analysis caused by the omission of test analysis elements and test types when conducting chip system test requirements analysis. Summary of the Invention

[0005] The purpose of this invention is to provide a chip system test requirements analysis method, apparatus, and medium to improve the comprehensiveness of chip system test requirements analysis.

[0006] To address the aforementioned technical problems, this invention provides a chip system test requirements analysis method, comprising:

[0007] If project information is received, a list of test scenarios will be displayed.

[0008] Based on the test scenario selected in the test scenario list, the corresponding analysis scenario input template is returned; wherein, the analysis scenario input template is used to guide the input of scenario description information.

[0009] Whenever a scenario description information corresponding to a test scenario is received, a list of test factors is displayed.

[0010] Based on the test factor selected in the test factor list, the corresponding factor value input template and expected test result input template are returned; wherein, the factor value input template is used to guide the input of factor value information of the current test factor, and the test result input template is used to guide the input of expected result information after the execution of the test cases corresponding to the current test scenario and the current test factor.

[0011] Based on the received scenario description information, factor value information, and expected result information, test case description information is generated.

[0012] In one optional embodiment, generating test case description information based on the received scenario description information, factor value information, and expected result information includes:

[0013] Test case description elements are determined according to triple mapping rules; wherein, the triple elements of the triple mapping rules include: test scenario, test factor, and expected result; the test case description elements include: scenario description information corresponding to the current test scenario, factor value information corresponding to the current test factor, and expected result information.

[0014] For each group of test case description elements, generate the corresponding test case description information for the test case.

[0015] In an optional embodiment, it further includes:

[0016] If a preset separator exists in the received scenario description information / factor value information, then the received scenario description information / factor value information is decomposed into multiple scenario description information / factor value information corresponding to different test scenarios / test factors according to the preset separator.

[0017] In one optional embodiment, the list of test scenarios includes:

[0018] Display a list of test analysis models; wherein the list of test analysis models includes multiple test analysis models with different test scenario types, and each test analysis model stores one or more different test scenarios.

[0019] The test scenarios output by the selected test analysis model are displayed in the form of a test scenario list.

[0020] The list of test factors includes:

[0021] Display a list of test factor models; wherein the list of test factor models includes multiple test factor models of different test factor types, and each test factor model stores one or more different test factors.

[0022] The test factors output by the selected test factor model are displayed in the form of a test factor list.

[0023] In an optional embodiment, each of the test analysis models and each of the test factor models further includes an attribute table.

[0024] After selecting the test analysis model or the test factor model, the method further includes: displaying the corresponding attribute table.

[0025] The attribute table of the test analysis model includes quality levels corresponding to each test scenario; the quality levels, from low to high, include: basic level, intermediate level, and advanced level; the attribute table of the test factor list includes value categories corresponding to each test factor.

[0026] In an optional embodiment, before displaying the test scenarios output by the selected test analysis model in the form of a test scenario list, the method further includes:

[0027] Display a list of quality levels.

[0028] The selected quality level is input into the selected test analysis model.

[0029] The test analysis model, upon receiving the quality level input, matches and outputs test scenarios whose quality level is less than or equal to the input from its stored set of test scenarios.

[0030] In one optional embodiment, the test analysis model includes: a functional test analysis model, a configuration test analysis model, a driver test analysis model, a performance test analysis model, a compatibility test analysis model, a link reliability test analysis model, a reliability test analysis model, and an extension test analysis model.

[0031] The test factor models include: effective boundary value factor extraction model, invalid boundary value factor extraction model, state factor extraction model, ordered operation factor extraction model, dataset factor extraction model, testable interface factor extraction model, observable interface factor extraction model, testable device factor extraction model, and extended analysis factor extraction model.

[0032] In one optional embodiment, the test scenarios corresponding to the functional test analysis model include: normal function test, interaction test with other functions, abnormal environment test, overload test, long-term stability test under load, abnormal environment stress test, normal and abnormal random stress test, specification capacity test, performance index test, special test equipment, special test environment, testable interface, and observable interface.

[0033] The test scenarios corresponding to the configuration-based test analysis model include: normal configuration function testing, interaction with other functions testing, abnormal configuration input testing, specification capacity testing, and interface usability testing.

[0034] The test scenarios corresponding to the driver test analysis model include: normal driver function, installation and uninstallation test, repeated installation and uninstallation stress test, and coexistence test with other drivers.

[0035] The test scenarios corresponding to the performance-based test analysis model include: performance index testing and special test equipment.

[0036] The test scenarios corresponding to the compatibility test analysis model include: uplink compatibility, downlink compatibility, and special test equipment.

[0037] The test scenarios corresponding to the link reliability test analysis model include: link anomaly detection and service fault tolerance capability, link anomaly recovery detection, link intermittent disconnection handling, link intermittent disconnection under service pressure, special test equipment, and observable test interfaces.

[0038] The test scenarios corresponding to the reliability test analysis model include: business fault tolerance capability, business recovery capability, fault tolerance capability under business pressure, fault injection test equipment, fault injection test interface, and observable test interface.

[0039] The test scenarios corresponding to the extended test analysis model include: basic testing, intermediate testing, and advanced testing.

[0040] In one optional embodiment, the attribute table corresponding to the functional test analysis model includes: a basic quality level for normal functional testing; an intermediate quality level for testing interaction with other functions; an intermediate quality level for abnormal environment testing; a high quality level for overload testing; a high quality level for long-term stability testing under load; a high quality level for abnormal environment stress testing; a high quality level for normal and abnormal random stress testing; a high quality level for specification capacity testing; a high quality level for performance index testing; a high quality level for special testing equipment; a basic quality level for special testing environments; a basic quality level for testable interfaces; and a basic quality level for observable interfaces.

[0041] The attribute table corresponding to the configuration-based test analysis model includes: the quality level of normal configuration function testing is basic; the quality level of interaction with other functions testing is intermediate; the quality level of abnormal configuration input testing is intermediate; the quality level of specification capacity testing is advanced; and the quality level of interface usability is advanced.

[0042] The attribute table corresponding to the driver test analysis model includes: the quality level of normal driver function is the basic level; the quality level of installation and uninstallation test is the basic level; the quality level of repeated installation and uninstallation stress test is the intermediate level; and the quality level of coexistence test with other drivers is the intermediate level.

[0043] The attribute table corresponding to the performance-based test analysis model includes: the quality level of the performance index test as the basic level; and the quality level of the special test equipment as the basic level.

[0044] The attribute table corresponding to the compatibility test analysis model includes: the quality level for uplink compatibility as the base level; the quality level for downlink compatibility as the base level; and the quality level for special test equipment as the base level.

[0045] The attribute table corresponding to the link reliability test analysis model includes: the quality level of link anomaly detection and service fault tolerance capability is the basic level; the quality level of link anomaly recovery detection is the basic level; the quality level of link intermittent interruption handling is the intermediate level; the quality level of link intermittent interruption under service pressure is the advanced level; the quality level of special test equipment is the basic level; and the quality level of observable test interfaces is the basic level.

[0046] The attribute table corresponding to the reliability test analysis model includes: the quality level of service fault tolerance capability is the basic level; the quality level of service recovery capability is the basic level; the quality level of fault tolerance capability under service pressure is the intermediate level; the quality level of fault injection test equipment is the basic level; the quality level of fault injection test interface is the basic level; and the quality level of observable test interface is the basic level.

[0047] The attribute table corresponding to the extended test analysis model includes: the quality level of the basic test is the basic level; the quality level of the intermediate test is the intermediate level; and the quality level of the advanced test is the advanced level.

[0048] In one optional embodiment, the value classification corresponding to the effective boundary value factor extraction model includes: minimum value, typical value, and maximum value.

[0049] The value classifications corresponding to the invalid boundary value factor extraction model include: minimum value, typical value, and maximum value.

[0050] The value classification corresponding to the state factor extraction model includes: all state values ​​and state transition values.

[0051] The value classification corresponding to the ordered operation factor extraction model includes: valid order and invalid order.

[0052] The value classification corresponding to the dataset factor extraction model includes: valid dataset and invalid dataset.

[0053] The value classification corresponding to the testable interface factor extraction model includes: function enumeration.

[0054] The value classification corresponding to the observable interface factor extraction model includes: function enumeration.

[0055] The value classification corresponding to the testable device factor extraction model includes: function enumeration.

[0056] The value classification corresponding to the extended analysis factor extraction model includes: factor set.

[0057] In an optional embodiment, after receiving the project information, the method further includes:

[0058] Create a project model and store the project information in the project model.

[0059] After determining the selected test analysis model, the process also includes:

[0060] The project number of the current project model is stored in the test analysis model, and an association relationship is established between the project model and the test analysis model based on the same project number.

[0061] The R&D requirements information in the project information is saved as initial test requirements information in the selected test analysis model.

[0062] After determining the selected test factor model, the process also includes:

[0063] The analysis model number of the current test analysis model is stored in the test factor model, and the association between the test analysis model and the test factor model is established based on the same analysis model number.

[0064] The scenario description information corresponding to the current test scenario is stored as test system requirement information in the selected test factor model.

[0065] After receiving the factor value information, the process also includes:

[0066] Create a test allocation model, store the factor model number of the current test factor model in the test allocation model, and establish the association between the test factor model and the test allocation model based on the same factor model number.

[0067] The factor value information corresponding to the current test factor is stored as test allocation requirement information in the currently created test allocation model.

[0068] After receiving the expected result information, the process also includes:

[0069] Create a test case model, store the allocation model number of the current test allocation model in the test case model, and establish an association between the test allocation model and the test case model based on the same allocation model number.

[0070] The expected result information corresponding to the current factor value information is stored as test case information in the currently created test case model.

[0071] In an optional embodiment, generating test case description information based on the received scenario description information, factor value information, and expected result information includes:

[0072] Based on the association chain formed by the project model, the test analysis model, the test factor model, the test allocation model, and the test case model, the scenario description information, the factor value information, and the expected result information corresponding to each test case are determined; the test cases correspond one-to-one with the test case models.

[0073] For each test case, the test case description information is generated based on the corresponding scenario description information, factor value information, and expected result information.

[0074] In an optional embodiment, after determining the selected test factor model, the method further includes:

[0075] Acquire test scenario analysis process information and record the test scenario analysis process information in a first association table; wherein, the first association table is associated with the selected test analysis model and the selected test factor model.

[0076] After receiving the factor value information, the process also includes:

[0077] Obtain test factor analysis process information and record the test factor analysis process information in a second association table; wherein, the second association table is associated with the selected test factor model and the currently created test allocation model.

[0078] In an optional embodiment, it further includes:

[0079] If a description query request is received, the scenario description information, factor value information, expected result information, or test case description information specified in the description query request will be retrieved and returned from the corresponding model.

[0080] In an optional embodiment, if the description query request specifies the test case description information, then after returning the test case description information, the method further includes:

[0081] If new test case description information is received, the existing stored test case description information will be replaced.

[0082] In an optional embodiment, the test analysis model and the test factor model are stored in a test model baseline library.

[0083] This method also includes:

[0084] If a model addition request is received, the test analysis model or the test factor model carried in the model addition request is added to the test model baseline library.

[0085] If a model deletion request is received, the test analysis model or the test factor model specified in the model deletion request will be deleted from the test model baseline library.

[0086] If a model change request is received, the test analysis model / test factor model carried in the model change request will overwrite the original test analysis model / test factor model in the test model baseline library.

[0087] If a model query request is received, the test analysis model / test factor model specified in the model query request is retrieved from the test model baseline library, and the corresponding test scenario / test factor and the corresponding attribute table are displayed.

[0088] To address the aforementioned technical problems, the present invention also provides a chip system test requirements analysis device, comprising:

[0089] The scenario selection module is used to display a list of test scenarios if project information is received.

[0090] The scenario description module is used to return the corresponding analysis scenario input template based on the test scenario selected in the test scenario list; wherein, the analysis scenario input template is used to guide the input of scenario description information.

[0091] The factor selection module is used to display a list of test factors whenever it receives scenario description information corresponding to a test scenario.

[0092] The factor description module is used to return the corresponding factor value input template and expected test result input template based on the test factor selected in the test factor list; wherein, the factor value input template is used to guide the input of factor value information of the current test factor, and the test result input template is used to guide the input of expected result information after the test cases corresponding to the current test scenario and the current test factor are executed.

[0093] The test case description module is used to generate test case description information based on the received scenario description information, factor value information, and expected result information.

[0094] To address the aforementioned technical problems, the present invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the chip system test requirements analysis method described above.

[0095] To address the aforementioned technical problems, the present invention also provides a chip system test requirements analysis device, comprising:

[0096] Memory is used to store computer programs.

[0097] A processor, used to execute the computer program, implements the steps of the chip system test requirements analysis method as described above.

[0098] To address the aforementioned technical problems, the present invention also provides a non-volatile storage medium storing a computer program, which, when executed by a processor, implements the steps of the chip system test requirements analysis method described above.

[0099] This invention provides a chip system test requirements analysis method. Upon receiving project information for chip system testing, it displays all preset test scenarios in a list for testers to select from. After each tester selects a test scenario, it displays all preset test factors for further selection. Once the test factors are selected, it returns the corresponding factor value input template and expected test result input template to guide testers in inputting the factor values ​​and, under the current test scenario, current test factor, and current test factor value, to execute the expected test results of the corresponding test cases.

[0100] Based on the above, this method breaks down the complete test analysis process into four progressively detailed requirement analysis levels: "Test Initial Requirements (TIR), Test System Requirements (TSR), Test Allocation Requirements (TAR), and Test Cases (TC)." Specifically, TIR corresponds to the requirement analysis stage of determining test scenarios based on R&D requirements in project information; TSR corresponds to the requirement analysis stage of determining test factors based on test scenarios; TAR corresponds to the requirement analysis stage of determining test factor values ​​based on R&D requirements and test factors; and TC corresponds to the requirement analysis stage of determining corresponding test cases after the test scenarios, test factors, and test factor values ​​are determined, and determining the expected results after the test cases are executed. Based on this, this method also utilizes visualization tools to assist testers in completing the entire test analysis process in writing test cases using a four-level progressively decomposed test analysis approach. It guides testers to input corresponding descriptive information at each level of requirement analysis, ensuring that all necessary elements for the requirement document are obtained during a test analysis process. Therefore, this method can automatically generate test case descriptions based on the obtained elements, serving as the output requirement document for this test project. This method unifies and refines the test analysis process through a four-level model, isolating differences in the skill levels and experience of different testers, and improving the quality of test analysis. Secondly, this method guides testers to complete the input of descriptive information for each level of requirements analysis, automatically generates and outputs requirements analysis documents, and can effectively avoid problems such as omissions in requirements analysis documents.

[0101] The chip system test requirement analysis device and non-volatile storage medium provided by this invention correspond to the above-mentioned method and have the same effect. Attached Figure Description

[0102] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0103] Figure 1 A flowchart illustrating a chip system test requirements analysis method provided in an embodiment of the present invention.

[0104] Figure 2 This is a database structure diagram of a test analysis model provided in an embodiment of the present invention.

[0105] Figure 3 This is a database structure diagram of a test factor model provided in an embodiment of the present invention.

[0106] Figure 4 This is a diagram illustrating the structure of a project testing requirements database, as provided in an embodiment of the present invention.

[0107] Figure 5 This is a structural diagram of a first association table provided in an embodiment of the present invention.

[0108] Figure 6 This is a structural diagram of a second association table provided in an embodiment of the present invention.

[0109] Figure 7 This is a structural diagram of a chip system test requirements analysis system provided in an embodiment of the present invention.

[0110] Figure 8 A flowchart of a TIR analysis test scenario provided in an embodiment of the present invention.

[0111] Figure 9 This is a flowchart for pre-generating TSR analysis test factors and test case descriptions, provided as an embodiment of the present invention.

[0112] Figure 10 This is a structural diagram of a chip system test requirements analysis device provided in an embodiment of the present invention.

[0113] Figure 11 A structural diagram of another chip system test requirement analysis device provided in an embodiment of the present invention. Detailed Implementation

[0114] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0115] The core of this invention is to provide a method, apparatus, and medium for analyzing chip system testing requirements.

[0116] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0117] In related technologies, a common chip system test analysis process includes: importing the R&D requirements for this test analysis after outputting the system architecture; testers conducting test requirement analysis based on the R&D requirements and outputting a test requirement analysis document to guide the writing of test cases; writing test cases based on the test requirement analysis document; selecting test cases, executing test cases, and labeling test results according to the version plan; and outputting a test report from the dimensions of test achievement, risks and problems, and next steps.

[0118] In the above process, the step of conducting test analysis based on the project's R&D needs and outputting a test requirements document directly affects the quality of subsequent test case writing, and thus directly impacts the effectiveness of the test. Currently, the analysis of chip system test requirements and the writing of test requirements analysis documents still rely entirely on manual processes. This inevitably leads to the following problems:

[0119] Test requirement analysis documents developed and generated directly by testers based on R&D requirements may contain only test scenarios without test factors, or only test factors without test scenarios. Having only test scenarios doesn't provide detailed guidance for test case writing, while having only test factors fails to guarantee the comprehensiveness of test scenario analysis. Therefore, both scenarios suffer from incomplete test requirement analysis. Furthermore, since generating test requirement analysis documents directly from R&D requirements requires a high level of expertise, and the varying levels of expertise and experience among testers can compromise the comprehensiveness of the test analysis. This may result in situations where only normal functionality is analyzed while reliability analysis is weak, or only functional testing is performed without stress testing, leading to omissions in test type analysis. Moreover, even if requirement analysis documents are templated to guide testers in test requirement analysis, the lack of tools for format checking prevents these template tools from being truly implemented.

[0120] To address the above problems, this invention provides a chip system test requirements analysis method, such as... Figure 1 As shown, it includes:

[0121] S11: If project information is received, display a list of test scenarios.

[0122] S12: Based on the test scenario selected in the test scenario list, return the corresponding analysis scenario input template.

[0123] The scenario input template is used to guide the input of scenario description information.

[0124] S13: Whenever a scenario description information corresponding to a test scenario is received, the list of test factors is displayed.

[0125] S14: Based on the test factors selected in the test factor list, return the corresponding factor value input template and the expected test result input template.

[0126] The factor value input template guides the input of factor value information for the current test factor, while the test result input template guides the input of expected result information after the execution of the test cases corresponding to the current test scenario and the current test factor.

[0127] S15: Generate test case description information based on the received scenario description information, factor value information, and expected result information.

[0128] As described above, this method is a visualization-based approach to assist testers in analyzing chip system test requirements and to automatically generate test requirements analysis documents. Therefore, this method should be applied to devices with processing capabilities, display functions, and human-computer interaction capabilities (hereinafter referred to as "this device"), such as computers and workstations.

[0129] For step S11, the project information refers to the information on the test items that need to be performed on this chip system, including R&D requirements (i.e., system requirements, SR) to characterize the fundamental requirements of this test analysis. The test scenario list shown in step S11 can include all possible test scenarios configured in this device for chip system testing, providing a more comprehensive range of test scenarios for testers to analyze and select, avoiding omissions.

[0130] Furthermore, the test scenarios described above can be set up based on the actual needs of chip system testing in real-world scenarios. For example, the test scenarios can be set up according to ISO standards (standards specified by the International Organization for Standardization) or IEC standards (standards developed by the International Electrotechnical Commission) to ensure that this method is compatible with currently used international standards such as ISO / IEC.

[0131] Alternatively, in another optional implementation, if a correspondence is found in advance between some information in the project information and a specific test scenario, the project information matching the test scenario can also be configured when configuring the test scenario for this device. When this information appears in the project information, only the relevant part of the test scenario can be displayed, providing more intelligent test scenario auxiliary analysis.

[0132] Regarding step S12, as described above, step S11 involves visually displaying all test scenarios to the testers to assist them in analyzing the test scenarios corresponding to this test. After the testers have determined the test scenarios required by the R&D needs, they can select some of the visually displayed test scenarios by clicking the mouse. The aforementioned mouse clicking method is a common human-computer interaction method implemented using the mouse as an input device. In addition, other human-computer interaction methods can be used to select test scenarios, and this embodiment does not limit this. When a test scenario is selected, step S12 outputs the analysis scenario input template corresponding to the selected test scenario. The analysis scenario input template is a template that guides the testers to input scenario description information. For example, the analysis scenario input template may include the necessary keywords, formats, etc., for the scenario description information of the currently selected test scenario to guide the testers to input scenario description information according to a unified standard. It should also be noted that the analysis scenario input templates for different test scenarios may be different, and the configuration of the analysis scenario input templates corresponding to each scenario type should be completed accordingly when configuring the scenario type.

[0133] In addition, another main purpose of providing the analysis scenario input template in step S12 is to remind testers to input scenario description information related to the selected test scenario, which will be used for the generation of subsequent test case description information, thus avoiding the omission of the test scenario element when outputting the test requirements analysis document. It should also be noted that when multiple test scenarios are selected, the corresponding analysis scenario input templates can be returned sequentially one by one, or all selected test scenario input templates can be returned simultaneously. However, it should be noted that when using the latter implementation, the visual interface needs to distinguish between the templates of different test scenarios and determine which specific test scenario's scenario description information the tester inputs (this can be achieved through different windows or input boxes marked with scenario type / analysis scenario input template).

[0134] Next, regarding step S13, similar to step S11, step S13 also displays the necessary elements in the test analysis, the difference being that it displays test factors. However, it's important to note that step S13 triggers the display of test factors after the tester inputs scenario description information. This is to avoid omitting scenario description information; that is, the next level of test requirement analysis (test factors) will only proceed after the description input of the previous level test requirement analysis stage (test scenario) is completed.

[0135] Furthermore, since there may be multiple selected test scenarios in step S12, and the scenario description information corresponds one-to-one with each test scenario, and the trigger condition for step S13 is that the tester inputs a scenario description, when executing step S13 of this method, steps S13 corresponding to each selected test scenario should be executed sequentially according to the order in which the tester inputs the scenario description information. However, there are two possible solutions when displaying the analysis scenario input template:

[0136] First, different test scenarios are executed sequentially. The analysis scenario input template for the next test scenario will be displayed only after the scenario description information of the previous test scenario has been completed, in order to guide the testers in inputting the scenario description information.

[0137] In this situation, considering subsequent steps S13 and S14, the entire process is as follows: after the tester selects a test scenario from the test scenario list, steps S12-S14 are executed for that test scenario. Only after steps S12-S14 for the current test scenario are completed can the tester select the next test scenario from the list and execute steps S12-S14 for that scenario. This process is repeated until the tester believes that all necessary test scenarios have been selected and steps S12-S14 have been executed to generate the corresponding test case description information. Only then is the test requirements analysis for a test project considered complete.

[0138] Secondly, different test scenarios can be executed in parallel, distinguished by multiple windows, interfaces, or text boxes. Although steps S12-S14 still correspond to the separate processes required for each test scenario, testers can freely jump between processes corresponding to different test scenarios by operating different windows, interfaces, or text boxes. For example, for test scenario 1, when executing the step of selecting test factors, the process can be paused and the input of scenario description information for test scenario 3 can be initiated (e.g., switching the currently active window). This implementation scheme is more flexible than the above scheme, but it is also more prone to the problem of missing some test scenario processes and not executing them completely. Therefore, different implementation schemes can be selected according to different needs in practical applications, and this embodiment does not impose any restrictions on this.

[0139] Furthermore, to better illustrate the various elements of test requirements analysis mentioned above, the following examples will be provided:

[0140] Taking the testing of a Redundant Array of Independent Disks (RAID) in a chip system as an example, let's assume the development requirement is "RAID5 supports 3-32 disks." Analysis shows that this requirement mainly describes testing the RAID5 disk configuration specifications. The corresponding scenario types can be "Normal Configuration Function Test," "Interaction Test with Other Functions," and "Abnormal Configuration Input Test," which correspond to three specific tests for the RAID5 disk configuration specifications. Furthermore, the scenario description information is used to supplement the above three scenario types. For example, the scenario description information corresponding to "Normal Configuration Function Test" is "RAID5 Effective Disk Creation Test"; the scenario description information corresponding to "Interaction Test with Other Functions" is "Adding Disks under the Maximum RAID5 Disk Scenario"; and the scenario description information corresponding to "Abnormal Configuration Input Test" is "RAID5 Invalid Disk Creation Test."

[0141] Furthermore, each test scenario may correspond to different test factor types. Taking the "Normal Configuration Function Test" mentioned above as an example, the factor values ​​for the "RAID5 Valid Disk Creation Test" have obvious boundary characteristics, so the "Valid Boundary Value" test factor can be used. It also has three specific factor values ​​(i.e., factor value information): "Minimum," "Typical," and "Maximum." Similarly, taking the "Abnormal Configuration Input Test" as an example, the factor values ​​for the "RAID5 Invalid Disk Creation Test" have obvious boundary characteristics, so the "Invalid Boundary Value" test factor can be used. It also has two specific factor values ​​(i.e., factor value information): "Minimum" and "Maximum."

[0142] Finally, once the aforementioned test scenarios, test factors, and other elements are complete, test cases can be written accordingly. However, completing a full test requirements analysis also requires analyzing the expected results of executing the written test cases, such as success or failure, which is the aforementioned expected result information.

[0143] From the above examples, we can see that the test scenario is the specific test function of the test cases that need to be written, and the test factor is the specific parameter used by the test cases to implement the corresponding test function. The scenario description information is a descriptive supplement to the test scenario, and the factor value information is the specific value of each parameter in the test factor. The expected result information is the expected execution result after the test cases written based on the above elements are executed, which is mostly success or failure.

[0144] In summary, the chip system test requirements analysis method provided by this invention decomposes all elements of the entire test requirements analysis process into five nodes: "R&D Requirements → Test Scenarios → Test Factors → Factor Values ​​→ Test Cases," resulting in a four-layer test requirements analysis model: "Initial Test Requirements → Test System Requirements → Test Allocation Requirements → Test Cases" (TIR → TSR → TAR → TC). This provides a unified and standardized process to guide testers in test requirements analysis. It effectively isolates differences in the background and experience of different testers, improving the quality of test analysis. Furthermore, because this method presents all aspects of the test requirements analysis to testers in a visual manner, and in analysis stages such as test scenarios and test factors, it displays pre-configured test scenarios and test factors (all or related) in a list format, it effectively avoids potential omissions by testers when analyzing requirements, improving the comprehensiveness of the analysis. Moreover, after obtaining scenario description information, factor value information, and expected result information, this method obtains all the elements needed to generate a complete test case description, and can replace testers in generating test case descriptions. This means that testers don't need to write test case descriptions; the system can still generate corresponding requirements analysis documents to guide subsequent test case writing. This further reduces problems such as omissions or errors caused by human factors, and better ensures the comprehensiveness and reliability of test requirements analysis.

[0145] On the other hand, the above embodiments illustrate that this method can generate test case description information based on scenario description information, factor value information, and expected result information, but do not limit how it is specifically implemented. In an optional implementation, the three fields corresponding to the scenario description information, factor value information, and expected result information can be concatenated in any order to obtain a single field, thereby obtaining the test case description information.

[0146] However, this presents a problem: in practice, testers typically produce test requirement analysis documents based on development needs, usually in text format. However, test cases are often written in spreadsheet format. Since these two documents are two independent deliverables, it's impossible to guarantee a one-to-one correspondence between test factors and test cases.

[0147] To address the aforementioned problems, this embodiment also provides an optional implementation scheme, wherein step S15 specifically comprises:

[0148] S151: Determine the test case description elements according to the triplet mapping rules.

[0149] The triplet mapping rule includes the following triplet elements: test scenario, test factor, and expected result (as explained above, the expected result is the test result expected after the test case is executed, so the triplet elements can also be test scenario, test factor, and test case). The test case description element includes: scenario description information corresponding to the current test scenario, factor value information corresponding to the current test factor, and expected result information (or expected result information corresponding to the test case).

[0150] S152: For each group of test case description elements, generate the corresponding test case description information.

[0151] In this embodiment, the test requirements analysis document can be output in tabular form using the triplet mapping rule. This document contains three elements: scenario description information corresponding to the test scenario, factor value information corresponding to the test factors, and expected result information corresponding to the expected results (test cases). This effectively unifies the document format between the two different stages, facilitating a smooth transition and efficient communication between the requirements analysis and test case writing stages.

[0152] It should also be noted that one test case description corresponds to one test case. However, after analyzing development requirements in a project, multiple test cases may be obtained. Therefore, during the execution of the above method, a project may have multiple scenario descriptions, factor values, and expected results. In this case, it is necessary to determine the association between scenario descriptions, factor values, and expected results based on the correspondence between steps S12-S14. Specifically, after selecting a test scenario and inputting scenario description information in the above steps, the selection of test factors is triggered. The subsequently selected test factors correspond to this test scenario. Then, based on the correspondence between scenario description information and test scenarios, and the relationship between factor values ​​and expected results information and test factors, the association between scenario descriptions, factor values, and expected results can be obtained, resulting in a set of test case description elements.

[0153] On the other hand, in practical applications, there may be situations where one scenario type (one scenario description) corresponds to multiple scenario descriptions, and one test factor (one factor value) corresponds to multiple specific factor values. For example, the scenario description for "interaction test with other functions" is "adding a disk in the case of maximum RAID5 disk". However, adding a disk can involve two possibilities: self-expansion or migration of an external disk. Therefore, "adding a disk in the case of maximum RAID5 disk" can be further divided into "expansion" (i.e., expansion in the case of maximum RAID5 disk) and "migration from RAID0 to RAID5" (i.e., migration in the case of maximum RAID5 disk). In this case, the tester's input information may contain two scenario descriptions. Similarly, for "effective boundary value", its possible value types include "minimum value", "typical value", and "maximum value", meaning that the tester's input information also contains multiple specific factor value information. To address this, this embodiment provides a corresponding implementation scheme, and the method further includes:

[0154] S2: If the received scene description information / factor value information contains a preset separator, then the received scene description information / factor value information is decomposed into multiple scene description information / factor value information corresponding to different test scenarios / test factors according to the preset separator.

[0155] It should be noted that this embodiment does not limit the specific type of the preset separator; appropriate symbols or combinations of symbols can be freely selected as the preset separator according to actual needs. However, it should be noted that the preset separator should be a symbol or combination of symbols that the tester would not use when inputting scene description information, factor value information, or other descriptive information, to avoid confusion with valid descriptive information. In an optional implementation, the aforementioned preset separator is "&&".

[0156] Taking the preset separator "&&" as an example, if the tester needs to input the scenario description information of "interaction test with other functions" (adding disk in the case of Raid5 maximum disk), they can input "expansion && Raid0 migration to Raid5". At this time, based on the preset separator "&&", it can be identified that the tester inputs two different scenario description information corresponding to the current test scenario.

[0157] On the other hand, this method involves displaying test scenarios and test factors in steps S11 and S13. The above embodiments do not restrict how the display of test scenarios and test factors is implemented. To ensure comprehensiveness, all pre-configured test scenarios and test factors in this device can be displayed. However, this approach is not user-friendly. Furthermore, when there are too many test scenarios or test factors, displaying too much information to testers can easily lead to omissions.

[0158] To address this, this embodiment provides an optional display method. The display of the test scenario list in step S11 specifically includes:

[0159] S111: Displays a list of test analysis models.

[0160] The test analysis model list includes multiple test analysis models with different test scenario types, and each test analysis model stores one or more different test scenarios.

[0161] S112: Display the test scenarios output by the selected test analysis model in the form of a test scenario list.

[0162] Similarly, the test factor list displayed in step S13 above specifically includes:

[0163] S131: Display the list of test factor models.

[0164] The test factor model list includes multiple test factor models with different test factor types, and each test factor model stores one or more different test factors.

[0165] S132: Display the test factors output by the selected test factor model in the form of a test factor list.

[0166] As described above, in this embodiment, test scenarios and test factors are stored and differentiated in the form of "models". It should be noted that the "model" in this embodiment does not necessarily have to be a complex model such as a machine learning model or a mathematical model. At its simplest, as long as the model can output all the test scenarios and test factors it stores when selected, it meets the requirements for the model in this embodiment.

[0167] Furthermore, in addition to storing test scenarios and test factors, the aforementioned test analysis models and test factor models can also store other information that helps testers analyze requirements. For example, this embodiment provides an optional implementation: each test analysis model and each test factor model also includes an attribute table.

[0168] Correspondingly, after selecting the test analysis model or test factor model, this method also includes: displaying the corresponding attribute table.

[0169] The attribute table of the test analysis model includes quality levels corresponding to each test scenario; the quality levels, from low to high, include: basic level, intermediate level, and advanced level; the attribute table of the test factor list includes value categories corresponding to each test factor.

[0170] It should be noted that the three quality levels defined in this embodiment are only one option, based on currently common ISO and IEC standards. In practical applications, other quality levels can be defined based on other standards or other needs, and this embodiment does not impose any restrictions on this.

[0171] Furthermore, the value classification provides further clarification. As shown in the example of the "Effective Boundary Value" test factor above, it has three value types: "Minimum," "Typical," and "Maximum." That is, the value classification attribute can guide testers to input the three specific values ​​corresponding to "Minimum," "Typical," and "Maximum" when entering factor value information corresponding to "Effective Boundary Value." In this case, the factor value input template can be a template guiding testers on the input numerical format, such as binary, decimal, or single-point, double-point, or integer formats required for the test factor values.

[0172] Furthermore, the aforementioned attribute table can be stored in the model in the form of a JSON (JavaScript Object Notation) table, and this embodiment does not impose any restrictions on this.

[0173] Based on the attribute table provided in this embodiment, testers can further understand the attributes of each test scenario or test factor, which in turn helps testers analyze requirements and select appropriate test scenarios or test factors, thereby improving the reliability and comprehensiveness of test analysis.

[0174] Furthermore, based on the previous embodiment, this embodiment also provides a further implementation scheme for demonstrating the above-mentioned test scenario. Before step S112, this method further includes:

[0175] S113: Displays a list of quality grades.

[0176] S114: Input the selected quality level into the selected test analysis model.

[0177] The test analysis model, upon receiving a quality level input, matches and outputs test scenarios with a quality level less than or equal to the input from its stored set of test scenarios.

[0178] In this embodiment, the test analysis model no longer outputs all stored test scenarios upon selection. Instead, it matches the test scenarios with the corresponding quality level stored in the model based on the quality level selected by the tester (the quality level input to the test analysis model) and outputs them. Therefore, the test scenarios obtained and displayed in step S112 are those that meet the tester's current quality level requirements.

[0179] It should be noted that the quality level matching in this embodiment is backward compatible. That is, when matching for a quality level of intermediate, the matched test scenarios include both basic and intermediate level test scenarios. Similarly, if the selected quality level is advanced, since advanced is the highest of the three quality levels, according to the backward compatible matching rule, the test analysis model outputs all the test scenarios stored therein. It should also be noted that this backward compatible matching rule is only an optional implementation scheme provided in this embodiment, set to adapt to current general standards. That is, the requirements for test scenarios at higher quality levels include all the requirements for test scenarios at lower quality levels. Other matching rules can be used in other implementation scenarios based on different needs, and this embodiment does not impose any restrictions on this. However, the solution provided in this embodiment, which matches corresponding test scenarios based on quality levels to be displayed to testers, can effectively reduce the number of test scenarios displayed to testers. Furthermore, the displayed test scenarios are more relevant to the testing requirements, achieving a more flexible and convenient test scenario display solution.

[0180] Furthermore, the above embodiments do not impose limitations on specific test analysis models and test factor models. However, it does illustrate that test analysis models and test factor models can be pre-set based on the standards used in practical applications. In this embodiment, specifically for currently common ISO and IEC standards, an optional implementation scheme for a test analysis model and test factor model is provided.

[0181] The test analysis models specifically include: functional test analysis model, configuration test analysis model, driver test analysis model, performance test analysis model, compatibility test analysis model, link reliability test analysis model, reliability test analysis model, and extension test analysis model.

[0182] The test factor model specifically includes: effective boundary value factor extraction model, invalid boundary value factor extraction model, state factor extraction model, ordered operation factor extraction model, dataset factor extraction model, testable interface factor extraction model, observable interface factor extraction model, testable device factor extraction model, and extended analysis factor extraction model.

[0183] Furthermore, based on currently accepted ISO and IEC standards, specific test scenario solutions are provided for each test analysis model:

[0184] 1. The test scenarios corresponding to the functional test analysis model include: normal function test, interaction test with other functions, abnormal environment test, overload test, long-term stability test under load, abnormal environment stress test, normal and abnormal random stress test, specification capacity test, performance index test, special test equipment, special test environment, testable interface, and observable interface.

[0185] 2. The test scenarios corresponding to the configuration-based test analysis model include: normal configuration function testing, interaction with other functions testing, abnormal configuration input testing, specification capacity testing, and interface usability testing.

[0186] 3. The test scenarios corresponding to the driver test analysis model include: normal driver function, installation and uninstallation test, repeated installation and uninstallation stress test, and coexistence test with other drivers.

[0187] 4. The test scenarios corresponding to the performance-based test analysis model include: performance index testing and special test equipment.

[0188] 5. The test scenarios corresponding to the compatibility test analysis model include: uplink compatibility, downlink compatibility, and special test equipment.

[0189] 6. The test scenarios corresponding to the link reliability test analysis model include: link anomaly detection and service fault tolerance capability, link anomaly recovery detection, link intermittent interruption handling, link intermittent interruption under service pressure, special test equipment, and observable test interfaces.

[0190] 7. The test scenarios corresponding to the reliability test analysis model include: business fault tolerance capability, business recovery capability, fault tolerance capability under business pressure, fault injection test equipment, fault injection test interface, and observable test interface.

[0191] 8. The extended test analysis model includes test scenarios for: basic testing, intermediate testing, and advanced testing.

[0192] Furthermore, based on the various test and analysis models provided in the above embodiments, this embodiment also provides an optional implementation of the quality table stored therein:

[0193] 1. The attribute table corresponding to the functional test analysis model includes: the quality level of normal functional testing is basic; the quality level of interaction testing with other functions is intermediate; the quality level of abnormal environment testing is intermediate; the quality level of overload testing is advanced; the quality level of long-term stability testing under load is advanced; the quality level of abnormal environment stress testing is advanced; the quality level of normal and abnormal random stress testing is advanced; the quality level of specification capacity testing is advanced; the quality level of performance index testing is advanced; the quality level of special testing equipment is advanced; the quality level of special testing environment is basic; the quality level of testable interfaces is basic; and the quality level of observable interfaces is basic.

[0194] 2. The attribute table corresponding to the configuration-type test analysis model includes: the quality level of normal configuration function test is basic level; the quality level of interaction test with other functions is intermediate level; the quality level of abnormal configuration input test is intermediate level; the quality level of specification capacity test is advanced level; and the quality level of interface usability is advanced level.

[0195] 3. The attribute table corresponding to the driver test analysis model includes: the quality level of normal driver function is the basic level; the quality level of installation and uninstallation test is the basic level; the quality level of repeated installation and uninstallation stress test is the intermediate level; and the quality level of coexistence test with other drivers is the intermediate level.

[0196] 4. The attribute table corresponding to the performance-based test analysis model includes: the quality level of performance index testing is the basic level; the quality level of special testing equipment is the basic level.

[0197] 5. The attribute table corresponding to the compatibility test analysis model includes: the quality level of uplink compatibility is the basic level; the quality level of downlink compatibility is the basic level; and the quality level of special test equipment is the basic level.

[0198] 6. The attribute table corresponding to the link reliability test analysis model includes: the quality level of link anomaly detection and service fault tolerance capability is the basic level; the quality level of link anomaly recovery detection is the basic level; the quality level of link intermittent interruption handling is the intermediate level; the quality level of link intermittent interruption under service pressure is the advanced level; the quality level of special test equipment is the basic level; and the quality level of observable test interfaces is the basic level.

[0199] 7. The attribute table corresponding to the reliability test analysis model includes: the quality level of business fault tolerance capability is the basic level; the quality level of business recovery capability is the basic level; the quality level of fault tolerance capability under business pressure is the intermediate level; the quality level of fault injection test equipment is the basic level; the quality level of fault injection test interface is the basic level; and the quality level of observable test interface is the basic level.

[0200] 8. The attribute table corresponding to the extended test analysis model includes: the quality level of basic tests is the basic level; the quality level of intermediate tests is the intermediate level; and the quality level of advanced tests is the advanced level.

[0201] Based on the implementation schemes provided by the above embodiments for the test analysis model, the test analysis model shown in Table 1 below is obtained.

[0202] Table 1. Common test analysis models and their attribute values ​​(JSON table)

[0203]

[0204] In addition, based on the test analysis model and test scenario provided in the above embodiments, a possible example of the implementation of S111~S114 in the above embodiments is also provided for illustration: Assuming that the tester selects a functional test analysis model and the selected quality level is intermediate, then based on Table 1 above, the analysis scenario input template displayed at this time can be as shown in Table 2 below.

[0205] Table 2. Visual Input Template for Functional Test Analysis Model + Intermediate Quality Level

[0206]

[0207] On the other hand, regarding the test factor model provided in the above embodiments, this embodiment also provides an optional implementation scheme for its attribute table based on currently common ISO and IEC standards:

[0208] 1. The value categories corresponding to the effective boundary value factor extraction model include: minimum value, typical value, and maximum value.

[0209] 2. The value categories corresponding to the invalid boundary value factor extraction model include: minimum value, typical value, and maximum value.

[0210] 3. The value categories corresponding to the state factor extraction model include: all state values ​​and state transition values.

[0211] 4. The value classifications corresponding to the ordered operation factor extraction model include: valid order and invalid order.

[0212] 5. The value categories corresponding to the dataset factor extraction model include: valid dataset and invalid dataset.

[0213] 6. The value categories corresponding to the testable interface factor extraction model include: function enumeration.

[0214] 7. The value categories corresponding to the observable interface factor extraction model include: functional enumeration.

[0215] 8. The value categories corresponding to the testable equipment factor extraction model include: functional enumeration.

[0216] 9. The value classification corresponding to the extended analysis factor extraction model includes: factor set.

[0217] Based on the implementation schemes provided by the above embodiments for the test factor model, the test factor model is summarized as shown in Table 3 below.

[0218] Table 3 Test factor model and its attribute values ​​(JSON table)

[0219]

[0220] Similarly, in conjunction with the test factor model and value classification provided in the above embodiments, a possible example of the implementation of S131 and S132 in the above embodiments is also provided for illustration: Assuming that the tester selects the effective boundary value test factor model, then based on Table 3 above, the factor value input template and expected result template displayed at this time can be shown in Table 4 below.

[0221] Table 4 Visual input template for the effective boundary value test factor model

[0222]

[0223] As can be seen from the above, each test analysis model and test factor model can be implemented using a database structure. This structure stores information such as test scenarios, test factors, and attribute value JSON tables, and can schedule all or part of this information for display when needed. The database structure meets all the above requirements and is commonly used for data storage in various computing devices, making it simple and easy to implement. Furthermore, the database can distinguish different models (test analysis models, test factor models) using model IDs. Figure 2 The test analysis model shown, and Figure 3 The test factor models shown have database structures that store information such as model ID, name (model description), description (scenario description information or factor value information), and attribute value JSON tables. The model ID serves as the primary key (PK) of this database, used to match other data tables or data with corresponding foreign keys (FK). In other words, the relationship between the two databases is established through the PK and FK.

[0224] Furthermore, taking the "Raid5 supported disk count: 3-32" development requirement in the above embodiment as an example, this can be further illustrated. As can be seen from the above description, the test analysis model selected for this development requirement is a configuration-based test analysis template. After the testers complete the TIR level information input according to this method, they can obtain the information shown in Table 5 below.

[0225] Table 5. Schematic diagram of TSR obtained by TIR analysis

[0226]

[0227] Next, the TSR (Total Residual Ranking) was analyzed. The factor values ​​for "RAID 5 Effective Disk Creation Test" showed clear boundary characteristics, and the "Effective Boundary Value" model was used to analyze the minimum, typical, and maximum values. The "RAID 5 Invalid Disk Creation Test" also showed clear boundary characteristics, and the "Invalid Boundary Value" model was used to analyze the minimum and maximum values. For "RAID 5 Maximum Disk Addition Scenario," there is currently no directly effective analysis model, but the "Extended Analysis" model can be used. The analysis revealed that "RAID 5 expansion requires adding one disk. With an existing RAID 5 of 32 disks, adding one more disk results in 33 disks, exceeding the maximum specification of 32 disks." Furthermore, "migrating from RAID 0 to RAID 5 requires adding one disk. If RAID 0 also has 32 disks, and migrating to RAID 5 requires adding one more disk, then the resulting RAID 5 will have 33 disks, not meeting the maximum specification of 32 disks." The values ​​obtained from the analysis were entered into the "Analysis Input Template," along with the test results for each category. Since the scenario analysis for "Adding disks under the maximum RAID 5 disk configuration" has two test factors, they are expressed using the "&&" separator. The "Save Model Analysis Results" module divides the input template content according to the separator to obtain the two test factors. The "Pre-generate Test Cases" module also divides the input template content according to the separator to obtain the two test factors, and the test results for both factors share the same "failure" value. Two test case descriptions are output in the format "TSR, Factor Value, Result": "Adding disks under the maximum RAID 5 disk configuration, expansion, failure" and "Adding disks under the maximum RAID 5 disk configuration, RAID 0 migration to RAID 5, failure". The obtained TARs and test case descriptions are shown in Table 6 below.

[0228] Table 6. A schematic table illustrating the TAR and use case descriptions obtained from TSR analysis.

[0229]

[0230] It should also be noted that since the factor value information for the "Raid5 Maximum Disk Addition Scenario" has two sub-information items, "Expansion" and "Raid0 to Raid5 Migration", these two sub-information items correspond to two test cases. However, since they both belong to the factor values ​​of a test factor under the same test scenario (not necessarily in numerical form), they share the same test result.

[0231] On the other hand, this embodiment also provides another optional implementation scheme. After receiving the project information in step S11, the method further includes:

[0232] S31: Create a project model and store project information in the project model.

[0233] After determining the selected test analysis model, the following steps are also included:

[0234] S32: Save the project number of the current project model in the test analysis model, and establish the association between the project model and the test analysis model based on the same project number.

[0235] S33: Save the R&D requirements information in the project information as the initial test requirements information in the selected test analysis model.

[0236] After determining the selected test factor model, the following steps are also included:

[0237] S34: Save the analysis model number of the current test analysis model in the test factor model, and establish the association between the test analysis model and the test factor model based on the same analysis model number.

[0238] S35: Save the scenario description information corresponding to the current test scenario as test system requirement information in the selected test factor model.

[0239] After receiving the factor value information, it also includes:

[0240] S36: Create a test allocation model, save the factor model number of the current test factor model in the test allocation model, and establish the association between the test factor model and the test allocation model based on the same factor model number.

[0241] S37: Save the factor value information corresponding to the current test factor as test allocation requirement information in the currently created test allocation model.

[0242] After receiving the expected result information, it also includes:

[0243] S38: Create a test case model, save the allocation model number of the current test allocation model in the test case model, and establish the association between the test allocation model and the test case model based on the same allocation model number.

[0244] S39: Save the expected result information corresponding to the current factor value information as test case information in the currently created test case model.

[0245] like Figure 4 As shown, this embodiment establishes... Figure 4 The project test requirements database structure is shown below. This database consists of five different levels of model databases, including the project model, the test analysis model (i.e., ... Figure 5 The TIR model in the test factor model (i.e.) Figure 5 The TSR model in the test assignment model (i.e.) Figure 5 The TAR model and test case model (i.e.) Figure 5 (TC model in the model). The model databases at different levels are linked through PK and FK, and the PK of the upper-level model database can be matched with the corresponding FK of the lower-level model database.

[0246] It is easy to understand that the establishment of the association in this embodiment is based on the selection instructions of the tester. Specifically, as explained in steps S31 to S39 above, when a new project information is received, a new project model (database) is established, and a project number is generated as the PK of this model database. The database stores the project name to explain the project. Then, according to step S11, a list of scenarios will be displayed to the tester. The test scenario selected by the tester at this time is the test scenario that the tester believes is related to the current project. At this time, the association between the corresponding test analysis model and the project model is established, and the associated project number can be added as an entry as FK in the database of the corresponding test analysis model. After the association is established, relevant information can be written under this database entry, such as the TIR number, TIR name, TIR description, TIR priority, etc., which represent the test scenario. Among them, the TIR description is the information on which the tester selects the current test analysis model, which can be the R&D requirement SR in the project information. Similarly, after the test scenario is selected and the scenario description information is entered, the stage of displaying the test factor list and selecting a test factor begins. The selected test factor at this point is the one associated with the previously selected test scenario. An associated TIR number (i.e., the TIR number stored in the test analysis model database corresponding to the associated test scenario) can be added to the database of the corresponding test factor model as the FK, establishing the association between the model databases. Based on the same principle, the TAR model corresponding to factor value information and the TC model corresponding to the test cases also store relevant information and establish associations with the previous level model data in the same way.

[0247] Based on this, this embodiment also provides a specific implementation plan for the above step S15, which specifically includes: determining the scenario description information, factor value information, and expected result information corresponding to each test case based on the association chain composed of the project model, test analysis model, test factor model, test allocation model, and test case model; the test cases correspond one-to-one with the test case models; for each test case, generating test case description information based on the corresponding scenario description information, factor value information, and expected result information.

[0248] As provided in the above embodiments Figure 4Based on the project test requirement database structure diagram shown, a chain of relationships can be derived for all test requirements under a project. Each relationship chain consists of databases in the order of "Project Model—TIR Model—TSR Model—TAR Model—TC Model," with each database recording test requirement analysis information for its corresponding level. However, it's important to note that a model database may not only record information for one relationship chain. For example, a TIR model database might record the project numbers of multiple associated projects. This means the model is used in multiple test projects, and the same applies to subsequent levels.

[0249] However, test requirements analysis documents are typically output on a per-development-requirement basis (i.e., a test project). The process involves iterating through the TIR model hierarchy based on its corresponding project model number, identifying all associated TIR model database entries (i.e., those containing the associated project number as TK). Then, using the TIR number of each associated TIR model database entry, the next level (TSR model database) is used to find all associated TAR model database entries. This process continues until all associated database entries in the final TC model are identified. This results in a tree-like relationship network starting from a project number. Each tail node (TC model level) traversing back to the head node (project model level) yields a relationship chain, and each relationship chain identifies the test case description information corresponding to a test instance (i.e., a TC model). After generating all test case description information for this project, the test requirements analysis document for that project can be obtained and output.

[0250] In addition to the information described above, each model database can also add other information items based on actual needs, such as the specific factor values ​​(TAR values) recorded in the TAR model, and the test case number, test case description (test case description information generated in step S14), test case preconditions, test steps, test expectations (i.e., the aforementioned expected result information) in the TC model.

[0251] Furthermore, the above embodiments only require testers to input the scenario description information, factor value information, expected result information, and other descriptive information needed to generate test case description information. The scenario description information can effectively reflect how testers derive the corresponding test scenarios based on R&D requirements analysis. However, for the transition from test scenarios to test factors, and from test factors to specific test factor values, there is currently no descriptive information to reflect the testers' requirements analysis process (i.e., the TIR→TSR analysis process and the TSR→TAR analysis process), which cannot provide better guidance for subsequent requirements analysis by testers. Based on this, this embodiment also provides a further implementation scheme.

[0252] After determining the selected test factor model, the above method also includes:

[0253] S41: Obtain test scenario analysis process information and record the test scenario analysis process information in the first association table.

[0254] The first association table is associated with the selected test analysis model and the selected test factor model.

[0255] After receiving the factor value information, it also includes:

[0256] S42: Obtain the test factor analysis process information and record the test factor analysis process information in the second association table.

[0257] The second association table is associated with the selected test factor model and the currently created test assignment model.

[0258] Specifically, the first association table, which is the data table associated with the aforementioned TIR and TSR models, describes the tester's analysis information during the process from the TIR model to the TSR model in the relational chain. Therefore, a test scenario analysis process piece of information in the first association table is associated with both the TIR model database and the TSR model database on the same relational chain. Figure 5 As shown, a single entry in the first association table should include the associated TIR number and TSR number as foreign keys to establish a connection with the corresponding TIR model database and TIR model database. Furthermore, as also... Figure 5 As shown, the first association table can also record other information that helps with test requirement analysis, such as the associated test analysis model number (i.e., which test analysis model the test scenario is determined based on) and the model attribute values ​​used when generating TSR (i.e., the quality level input to the test analysis model when obtaining the test scenario).

[0259] The same principle applies to the second related table, such as... Figure 6 As shown, each entry in the second association table should include the associated TSR number and TAR number as foreign keys to establish an association with the corresponding TSR model database and TAR model database. It may also include information such as the associated test factor model number (i.e., which test factor model the test factor is based on) and the model attribute values ​​used when generating the TAR (i.e., the value classification of the test factor model used to obtain factor value information).

[0260] Based on the implementation scheme provided in this embodiment, the gap in the process description of the analysis requirements in the above embodiments is filled. By guiding testers to input and record the analysis process information of TIR→TSR and TSR→TAR, it can guide other testers to conduct subsequent test requirement analysis or facilitate the review and reproduction of test requirement analysis.

[0261] On the other hand, the information stored in the various databases and related tables also supports querying. Testers can query information stored in a specific data table item based on the corresponding number. That is, this embodiment provides an optional implementation scheme, and the above method further includes:

[0262] S51: If a description query request is received, retrieve and return the scenario description information, factor value information, expected result information, or test case description information specified in the description query request from the corresponding model.

[0263] It is easy to understand that the scenario description information, factor value information, expected result information, or test case description information exemplified in this embodiment are only basic description information. In the above embodiment, a scheme for recording other description information is also given. Under the premise of implementing the corresponding scheme, this embodiment can also query this part of the description information.

[0264] Furthermore, as can be seen from the above embodiments, this method can generate corresponding test case description information for each test case. For example, the test case description information obtained in the above example is "Raid5 maximum disk addition scenario, Raid0 migration to Raid5 fails." However, the automatically generated test case description information may not conform to the general language habits of testers. Therefore, this embodiment also provides a further implementation scheme. When the description information queried in step S191 is specified as test case description information, then after step S191, this method further includes:

[0265] S52: If new test case description information is received, replace the existing stored test case description information.

[0266] In other words, this embodiment supports modification of test case description information to address potential semantic inconsistencies that may arise when test case description information is automatically generated by this method. However, it should be noted that modification of description information is not limited to test case description information. While other description information is manually entered by testers and therefore does not present semantic inconsistencies, only test case description information is automatically generated by this method. Therefore, this embodiment uses test case description information as an example to provide a method for querying and modifying it.

[0267] On the other hand, besides the modifiable solutions provided in the above embodiments, this embodiment also provides a modification solution for the test analysis model and the test factor model:

[0268] The test analysis model and the test factor model are stored in the test model baseline library.

[0269] This method also includes:

[0270] S61: If a model addition request is received, the test analysis model or test factor model carried in the model addition request will be added to the test model baseline library.

[0271] S62: If a model deletion request is received, delete the test analysis model or test factor model specified in the model deletion request from the test model baseline library.

[0272] S63: If a model change request is received, the test analysis model / test factor model carried in the model change request will overwrite the original test analysis model / test factor model in the test model baseline library.

[0273] S64: If a model query request is received, retrieve the test analysis model / test factor model specified in the model query request from the test model baseline library, and display the corresponding test scenario / test factor and the corresponding attribute table.

[0274] In other words, this method supports adding, deleting, modifying, and querying test analysis models and test factor models. After the equipment is put into use for test analysis, the test analysis model and test factor model can be adjusted according to changes in actual applications to adapt to different needs.

[0275] Based on the above embodiments, it can be seen that the functions implemented by this method can be divided into the following three parts:

[0276] 1. Model processing section.

[0277] This includes the information display and input information saving sections corresponding to steps S11~S14, S2, S31~S39, and S41~S42 mentioned above.

[0278] 2. Model Management Section.

[0279] That is, the management function part that includes the modules and description information corresponding to the above steps S51~S52 and S61~S64 for adding, deleting, modifying and querying.

[0280] 3. Test case generation section.

[0281] This corresponds to the test case description information generation part implemented in step S15 above.

[0282] The model processing and test case generation sections mentioned above belong to the business logic, while the model management section belongs to the management logic. In practical applications, these three functional sections can be implemented through three different functional modules within the device, such as... Figure 7 As shown, a chip system test requirements analysis system 10 includes a model processing module 11, a model management module 12, and a test case generation module 13, which are used to complete the three major functional parts and their corresponding steps, respectively. The model management module 12 can be further divided into four sub-modules: add, modify, delete, and query. The model processing module 11 can be further divided into two sub-modules: model parameter parsing and display (i.e., for information display) and model analysis result saving (i.e., for saving information input by testers). The test case generation module 13 has a single function: generating test case descriptions, and does not have multiple sub-modules. However, it should be noted that since the above embodiment provides an implementation scheme where the test case description information generated by this method may have semantic inconsistencies and can be modified by testers after querying, the process of generating test case description information by the test case generation module can also be called "pre-generation of test case description information." Only after testers query and modify the information do they obtain the final determined test case description information.

[0283] On the other hand, the above embodiments all illustrate the implementation of this method from the device side. However, it is not difficult to see from the above embodiments that this method mainly provides assistance to testers when conducting test requirements analysis. It unifies and refines the breadth and depth of test analysis through a four-layer model, isolates differences in the background and experience of different testers, and improves the quality of test analysis. However, the quality of the analysis conducted by the testers still directly affects the quality of the test requirements analysis results. Based on this, this embodiment also provides an interaction process between the tester and the device applying this method (or the chip system test requirements analysis system provided in the above embodiments) from the perspective of the tester (human-machine interface).

[0284] For the TIR requirements analysis phase, the human-computer interaction process is as follows: Figure 8 As shown, it includes:

[0285] S71: Testers enter project information into the project database.

[0286] S72: Testers enter the R&D requirements as TIRs into the TIR database.

[0287] S73: Testers query the TIR list of a project.

[0288] S74: The tester selects the TIR to be analyzed from the TIR list and selects the appropriate analysis model from the test analysis model list and quality grade list displayed in the model processing module.

[0289] S75: Testers analyze the attribute values ​​of the test analysis model displayed by the model processing module and fill in the results in the input template related to the analysis attribute values.

[0290] S76: After the tester confirms the analysis results, the analysis results are saved. The model processing module sequentially traverses the input template after each analysis item, separates the values ​​in the input boxes according to the separators, and adds a TSR table item, as well as a TIR and TSR related table item.

[0291] For the TSR requirements analysis phase and the test case description information pre-generation phase, the human-computer interaction process is as follows: Figure 9 As shown, it includes:

[0292] S81: Testers query the TSR list in the project.

[0293] S82: The tester selects the TSR to be analyzed from the TSR list and selects the appropriate analysis model from the test factor model list displayed in the model processing module.

[0294] S83: Testers analyze the attribute values ​​of the test factor model displayed by the model processing module, fill in the results in the input template related to the analysis attribute values, and fill in the test results of this type of factor in the corresponding test result input template.

[0295] S84: After the tester confirms the analysis results, the analysis results are saved. The model processing module sequentially traverses the input template after each analysis item, separates the values ​​in the input boxes according to the separators, and adds a TAR table entry, as well as a TSR and TAR association table entry. The test case pre-generation module sequentially traverses the input template after each analysis item, separates the values ​​in the input boxes according to the separators, and outputs the test case description according to the format "TSR", "TAR", "Test Result", and adds a test case table entry.

[0296] In addition to the embodiments of the chip system test requirements analysis method provided in the above embodiments, the present invention also provides an embodiment corresponding to a computer program product. A computer program product includes a computer program / instructions, which, when executed by a processor, can implement the steps of the chip system test requirements analysis method as described in any of the above embodiments.

[0297] Since the embodiments of the computer program product portion correspond to the embodiments of the method portion, please refer to the description of the embodiments of the method portion for the embodiments of the computer program product portion, which will not be repeated here.

[0298] In the above embodiments, a method for analyzing chip system test requirements has been described in detail. This invention also provides an embodiment corresponding to a chip system test requirements analysis device. It should be noted that this invention describes the device embodiment from two perspectives: one based on functional modules, and the other based on hardware.

[0299] From the perspective of functional modules, such as Figure 10 As shown, this embodiment provides a chip system test requirements analysis device, including:

[0300] The scenario selection module 21 is used to display a list of test scenarios if project information is received.

[0301] The scenario description module 22 is used to return the corresponding analysis scenario input template based on the test scenario selected in the test scenario list; wherein, the analysis scenario input template is used to guide the input of scenario description information.

[0302] The factor selection module 23 is used to display a list of test factors whenever a scenario description information corresponding to a test scenario is received.

[0303] The factor description module 24 is used to return the corresponding factor value input template and expected test result input template based on the test factor selected in the test factor list. The factor value input template is used to guide the input of factor value information for the current test factor, and the test result input template is used to guide the input of expected result information after the test cases corresponding to the current test scenario and the current test factor are executed.

[0304] The test case description module 25 is used to generate test case description information based on the received scenario description information, factor value information, and expected result information.

[0305] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0306] Figure 11 A structural diagram of a chip system test requirements analysis device provided in another embodiment of the present invention is shown below. Figure 11 As shown, a chip system test requirements analysis device includes: a memory 30 for storing computer programs.

[0307] The processor 31 is used to implement the steps of a chip system test requirements analysis method as described in the above embodiment when executing a computer program.

[0308] The chip system test requirements analysis device provided in this embodiment may include, but is not limited to, mobile terminals, personal computers, workstations, etc.

[0309] The processor 31 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 31 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array. The processor 31 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 31 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 31 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0310] The memory 30 may include one or more computer-readable storage media, which may be non-transitory. The memory 30 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 30 is used to store at least the following computer program 301, which, after being loaded and executed by the processor 31, can implement the relevant steps of a chip system test requirements analysis method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 30 may also include an operating system 302 and data 303, and the storage method may be temporary or permanent storage. The operating system 302 may include Windows, Unix, Linux, etc. The data 303 may include, but is not limited to, a chip system test requirements analysis method.

[0311] In some embodiments, a chip system test requirements analysis device may further include a display screen 32, an input / output interface 33, a communication interface 34, a power supply 35, and a communication bus 36.

[0312] Those skilled in the art will understand that Figure 11 The structure shown does not constitute a limitation on a chip system test requirements analysis apparatus and may include more or fewer components than shown.

[0313] The present invention provides a chip system test requirements analysis device, including a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a chip system test requirements analysis method.

[0314] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. A computer program is stored on the non-volatile storage medium, and when executed by a processor, the computer program implements the steps described in the above method embodiments.

[0315] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0316] The foregoing has provided a detailed description of a chip system test requirements analysis method, apparatus, and medium provided by the present invention. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to the present invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the present invention.

[0317] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method of analyzing test requirements for a chip system, characterized by, The method comprises the following steps: If the project information is received, a test scenario list is displayed; According to the test scenario selected in the test scenario list, a corresponding analysis scenario input template is returned; wherein the analysis scenario input template is used to guide the input of scenario description information; Whenever the scenario description information corresponding to one of the test scenarios is received, a test factor list is displayed; According to the test factor selected in the test factor list, a corresponding factor value input template and an expected test result input template are returned; wherein the factor value input template is used to guide the input of factor value information of the current test factor, and the test result input template is used to guide the input of expected result information after the execution of a test case corresponding to the current test scenario and the current test factor; According to the received scenario description information, factor value information and expected result information, test case description information is generated.

2. The chip system test requirement analysis method according to claim 1, wherein According to the received scenario description information, factor value information and expected result information, test case description information is generated, which comprises the following steps: According to a triple mapping rule, a test case description element is determined; wherein the triple element of the triple mapping rule comprises a test scenario, a test factor and an expected result; and the test case description element comprises the scenario description information corresponding to the current test scenario, and the factor value information and the expected result information corresponding to the current test factor; For each group of test case description elements, the test case description information corresponding to the test case is generated.

3. The chip system test requirement analysis method according to claim 1, wherein The method further comprises the following steps: If the received scenario description information / factor value information contains a preset delimiter, the received scenario description information / factor value information is decomposed into multiple pieces of scenario description information / factor value information corresponding to different test scenarios / test factors according to the preset delimiter.

4. The chip system test requirement analysis method according to any one of claims 1 to 3, characterized by, The test scenario list is displayed, which comprises the following steps: A test analysis model list is displayed; wherein the test analysis model list comprises multiple test analysis models with different test scenario types, and each test analysis model stores one or more different test scenarios; Each test scenario output by the selected test analysis model is displayed in the form of the test scenario list; The test factor list is displayed, which comprises the following steps: A test factor model list is displayed; wherein the test factor model list comprises multiple test factor models with different test factor types, and each test factor model stores one or more different test factors; The test factors output by the selected test factor model are displayed in the form of the test factor list.

5. The chip system test requirement analysis method according to claim 4, wherein Each test analysis model and each test factor model further comprises an attribute table; After the test analysis model or the test factor model is selected, the corresponding attribute table is displayed. The attribute table of the test analysis model includes quality levels corresponding to each of the test scenarios; the quality levels include, from low to high, a basic level, an intermediate level, and a high level; and the attribute table of the test factor list includes value classifications corresponding to each of the test factors.

6. The chip system test requirement analysis method according to claim 5, wherein Before each of the test scenarios output by the selected test analysis model is displayed in the form of the test scenario list, the method further includes: displaying a quality level list; inputting the selected quality level into the selected test analysis model; After the quality level is input, the test analysis model matches and outputs the test scenario with the quality level less than or equal to the input from the test scenario set stored in the test analysis model.

7. The chip system test requirement analysis method according to Claim 5, characterized by, The test analysis model includes a functional test analysis model, a configuration test analysis model, a driver test analysis model, a performance test analysis model, a compatibility test analysis model, a link reliability test analysis model, a reliability test analysis model, and an extended test analysis model. The test factor model includes an effective boundary value factor extraction model, an ineffective boundary value factor extraction model, a state factor extraction model, an ordered operation factor extraction model, a data set factor extraction model, a testable interface factor extraction model, an observable interface factor extraction model, a testable device factor extraction model, and an extended analysis factor extraction model.

8. The chip system test requirement analysis method according to claim 7, wherein The test scenarios corresponding to the functional test analysis model include normal function testing, interaction testing with other functions, abnormal environment testing, overload testing, long-stable testing within load, abnormal environment stress testing, normal and abnormal random stress testing, specification capacity testing, performance index testing, special test equipment, special test environment, testable interface, and observable interface. The test scenarios corresponding to the configuration test analysis model include normal configuration function testing, interaction testing with other functions, abnormal configuration input testing, specification capacity testing, and interface usability. The test scenarios corresponding to the driver test analysis model include driver normal function, installation and uninstallation testing, repeated installation and uninstallation stress testing, and coexistence testing with other drivers. The test scenarios corresponding to the performance test analysis model include performance index testing and special test equipment. The test scenarios corresponding to the compatibility test analysis model include uplink compatibility, downlink compatibility, and special test equipment. The test scenarios corresponding to the link reliability test analysis model include link abnormality detection and business fault tolerance capability, link abnormality recovery detection, link flash detection processing, link flash under business stress, special test equipment, and observable test interface. The test scenarios corresponding to the reliability test analysis model include business fault tolerance capability, business recovery capability, fault tolerance capability under business stress, fault injection test equipment, fault injection test interface, and observable test interface. The test scenarios corresponding to the extended test analysis model include basic testing, intermediate testing, and high-level testing.

9. The chip system test requirement analysis method according to claim 8, wherein The attribute table corresponding to the functional test analysis model includes: the quality level of normal function test is a basic level; the quality level of interaction test with other functions is a middle level; the quality level of abnormal environment test is a middle level; the quality level of overload test is a high level; the quality level of long stable test within load is a high level; the quality level of abnormal environment stress test is a high level; the quality level of normal and abnormal random stress test is a high level; the quality level of specification capacity test is a high level; the quality level of performance index test is a high level; the quality level of special test equipment is a high level; the quality level of special test environment is a basic level; the quality level of testable interface is a basic level; and the quality level of observable interface is a basic level. The attribute table corresponding to the configuration test analysis model includes: the quality level of normal configuration function test is a basic level; the quality level of interaction test with other functions is a middle level; the quality level of abnormal configuration input test is a middle level; the quality level of specification capacity test is a high level; and the quality level of interface usability is a high level. The attribute table corresponding to the drive test analysis model includes: the quality level of drive normal function is a basic level; the quality level of installation and uninstallation test is a basic level; the quality level of repeated installation and uninstallation stress test is a middle level; and the quality level of coexistence test with other drives is a middle level. The attribute table corresponding to the performance test analysis model includes: the quality level of performance index test is a basic level; and the quality level of special test equipment is a basic level. The attribute table corresponding to the compatibility test analysis model includes: the quality level of uplink compatibility is a basic level; the quality level of downlink compatibility is a basic level; and the quality level of special test equipment is a basic level. The attribute table corresponding to the link reliability test analysis model includes: the quality level of link abnormality detection and service fault tolerance capability is a basic level; the quality level of link abnormality recovery detection is a basic level; the quality level of link flash interruption processing is a middle level; the quality level of link flash interruption under service stress is a high level; the quality level of special test equipment is a basic level; and the quality level of observable test interface is a basic level. The attribute table corresponding to the reliability test analysis model includes: the quality level of service fault tolerance capability is a basic level; the quality level of service recovery capability is a basic level; the quality level of fault tolerance capability under service stress is a middle level; the quality level of fault injection test equipment is a basic level; the quality level of fault injection test interface is a basic level; and the quality level of observable test interface is a basic level. The attribute table corresponding to the extended test analysis model comprises: the quality level of the basic test is a basic level; the quality level of the intermediate test is a middle level; and the quality level of the high-level test is a high level.

10. The chip system test requirement analysis method according to Claim 7, characterized by, The value classification corresponding to the effective boundary value factor extraction model comprises: minimum value, typical value, and maximum value. The value classification corresponding to the invalid boundary value factor extraction model comprises: minimum value, typical value, and maximum value. The value classification corresponding to the state factor extraction model comprises: all state values and state transition values. The value classification corresponding to the ordered operation factor extraction model comprises: effective order and invalid order. The value classification corresponding to the data set factor extraction model comprises: effective data set and invalid data set. The value classification corresponding to the testable interface factor extraction model comprises: function enumeration. The value classification corresponding to the observable interface factor extraction model comprises: function enumeration. The value classification corresponding to the testable device factor extraction model comprises: function enumeration. The value classification corresponding to the extended analysis factor extraction model comprises: factor set.

11. The chip system test requirement analysis method according to claim 4, wherein After receiving the project information, further comprising: creating a project model and storing the project information in the project model; After determining the selected test analysis model, further comprising: saving the project number of the current project model in the test analysis model, and establishing an association relationship between the project model and the test analysis model according to the same project number; saving the R&D requirement information in the project information as test initial requirement information in the selected test analysis model; After determining the selected test factor model, further comprising: saving the analysis model number of the current test analysis model in the test factor model, and establishing an association relationship between the test analysis model and the test factor model according to the same analysis model number; saving the scene description information corresponding to the current test scene as test system requirement information in the selected test factor model; After receiving the factor value information, further comprising: creating a test allocation model, saving the factor model number of the current test factor model in the test allocation model, and establishing an association relationship between the test factor model and the test allocation model according to the same factor model number; saving the factor value information corresponding to the current test factor as test allocation requirement information in the test allocation model created at present; After receiving the expected result information, further comprising: creating a test case model, saving the allocation model number of the current test allocation model in the test case model, and establishing an association relationship between the test allocation model and the test case model according to the same allocation model number; saving the expected result information corresponding to the current factor value information as test case information in the test case model created at present.

12. The chip system test requirement analysis method according to Claim 11, wherein The generating the test case description information according to the received scene description information, the factor value information and the expected result information comprises: determining the scene description information, the factor value information and the expected result information corresponding to each test case according to the association relationship chain composed of the project model, the test analysis model, the test factor model, the test allocation model and the test case model; the test case corresponds to the test case model one by one; for each test case, generating the test case description information according to the corresponding scene description information, the factor value information and the expected result information.

13. The chip system test requirement analysis method according to Claim 11, wherein After determining the selected test factor model, further comprising: obtaining test scene analysis process information and recording the test scene analysis process information in a first association table; wherein the first association table is associated with the selected test analysis model and the selected test factor model; after receiving the factor value information, further comprising: obtaining test factor analysis process information and recording the test factor analysis process information in a second association table; wherein the second association table is associated with the selected test factor model and the currently created test allocation model.

14. The chip system test requirement analysis method according to Claim 11, wherein Further comprising: if a description query request is received, the scene description information, the factor value information, the expected result information or the test case description information specified by the description query request are called from the corresponding model and returned.

15. The chip system test requirement analysis method according to Claim 14, characterized by, if the description query request specifies the test case description information, after returning the test case description information, further comprising: if the new test case description information is received, the original stored test case description information is replaced.

16. The chip system test requirement analysis method according to Claim 5, wherein The test analysis model and the test factor model are saved in a test model baseline library; The method further comprises: if a model increase request is received, the test analysis model or the test factor model carried in the model increase request is added to the test model baseline library; if a model deletion request is received, the test analysis model or the test factor model specified in the model deletion request is deleted from the test model baseline library; if a model change request is received, the test analysis model / test factor model carried in the model change request covers the original test analysis model / test factor model in the test model baseline library; if a model query request is received, the test analysis model / test factor model specified by the model query request is called from the test model baseline library, and the corresponding test scene / test factor and the corresponding attribute table are displayed.

17. A chip system test requirement analysis apparatus characterized by comprising: comprising: a scene selection module, configured to display a test scene list if project information is received; a scene description module, configured to return a corresponding analysis scene input template according to the selected test scene in the test scene list; wherein the analysis scene input template is used to guide the input of scene description information; a factor selection module, configured to display a test factor list when receiving the scenario description information corresponding to one of the test scenarios; a factor description module, configured to return a factor value input template and an expected test result input template according to a test factor selected from the test factor list; the factor value input template is used to guide input of factor value information of the current test factor, and the test result input template is used to guide input of expected result information after execution of a test case corresponding to the current test scenario and the current test factor; a test case description module, configured to generate test case description information according to the received scenario description information, the factor value information and the expected result information.

18. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instruction is executed by the processor to implement the steps of the chip system test requirement analysis method according to any one of claims 1 to 16.

19. A chip system test requirement analysis apparatus characterized by comprising: comprise: a memory, configured to store a computer program; a processor, configured to execute the computer program to implement the steps of the chip system test requirement analysis method according to any one of claims 1 to 16.

20. A non-volatile storage medium, comprising: The non-volatile storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the chip system test requirement analysis method according to any one of claims 1 to 16.

Images