Chip system test demand analysis method and device and medium

Abstract

The invention discloses a chip system test demand analysis method, a chip system test demand analysis device and a medium, relates to the technical field of chip system testing, and provides the chip system test demand analysis method aiming at the problem that analysis is not comprehensive when chip system test demand analysis is carried out at present. A visual tool is utilized to assist testers in completing the test analysis process in a four-layer step-by-step decomposition test analysis mode, level and experience differences of different testers are isolated, and the test analysis quality is improved. In addition, the method can also guide a tester to input corresponding description information during demand analysis of each layer, so that all necessary elements required by the demand document in a test analysis process are obtained, and omission is avoided. And the test case description is automatically generated based on the obtained description information and is output as the demand document of the test item, so that the problems of omission and the like caused by manually outputting the demand analysis document can be effectively avoided.

Description

Technical Field

[0001] The present invention relates to the field of chip system testing, and in particular to a chip system testing requirement analysis method, device and medium. Background Art

[0002] Currently, the chip system test analysis process includes four stages: test requirements analysis, test case writing, test execution, and test reporting. Test requirements analysis requires testers to start from R&D requirements and produce a test requirements analysis document to guide the writing of test cases in the next stage.

[0003] However, because current test requirements analysis relies solely on manual testing by testers, and the process from R&D requirements directly to the test requirements analysis document that guides test case development involves extensive and complex analysis, it's easy for test analysis elements (such as missing test scenarios or test factors) to be missed. Furthermore, due to differences in background experience and technical skills among testers, test analysis may focus solely on normal functional testing, leading to weak analysis of abnormal reliability, or only functional testing without stress-related testing, resulting in omissions in test type analysis. Furthermore, even if the requirements analysis document is templated to guide testers in test requirements analysis, the lack of tools for formatting prevents this template tool from being fully implemented.

[0004] Therefore, technical personnel in this field are in urgent need of a chip system test requirements analysis method to solve the problem of incomplete analysis caused by missing test analysis elements and test types when conducting chip system test requirements analysis. Summary of the Invention

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

[0006] To solve the above technical problems, the present invention provides a chip system test requirements analysis method, comprising: If project information is received, a list of test scenarios is displayed.

[0007] 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.

[0008] Whenever the scenario description information corresponding to one of the test scenarios is received, a list of test factors is displayed.

[0009] According to 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 the factor value information of the current test factor, and the test result input template is used to guide the input of the expected result information after the execution of the test case corresponding to the current test scenario and the current test factor.

[0010] Test case description information is generated according to the received scenario description information, the factor value information and the expected result information.

[0011] In an optional embodiment, generating the test case description information according to the received scenario description information, the factor value information, and the expected result information includes: Determine the test case description elements according to the triple mapping rules; wherein the triple elements of the triple mapping rules include: test scenario, test factor, expected result; the test case description elements include: 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.

[0012] For each group of the test case description elements, the test case description information corresponding to the test case is generated.

[0013] In an optional embodiment, the method further includes: If there is a preset separator in the received scene description information / the factor value information, the received scene description information / the factor value information is decomposed into multiple scene description information / the factor value information corresponding to different test scenes / the test factors according to the preset separator.

[0014] In an optional embodiment, displaying the test scenario list includes: Display a test analysis model list; wherein the test analysis model list includes multiple test analysis models with different test scenario types, and each of the test analysis models stores one or more different test scenarios.

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

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

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

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

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

[0020] Among them, the attribute table of the test analysis model includes the quality level corresponding to each of the test scenarios; the quality levels include, from low to high, basic level, intermediate level and advanced level; the attribute table of the test factor list includes the value classification corresponding to each of the test factors.

[0021] In an optional embodiment, before displaying each of the test scenarios output by the selected test analysis model in the form of the test scenario list, the method further includes: Displays a list of quality levels.

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

[0023] Wherein, after receiving the quality level input, the test analysis model matches and outputs the test scenario whose quality level is less than or equal to the input from the test scenario set stored in the test analysis model.

[0024] In an optional embodiment, the test analysis model includes: a functional test analysis model, a configuration test analysis model, a drive 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.

[0025] The test factor model includes: a valid boundary value factor extraction model, an invalid 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.

[0026] In an optional embodiment, 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-term stability 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.

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

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

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

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

[0031] The test scenarios corresponding to the link reliability test analysis model include: link anomaly detection and service fault tolerance, link anomaly recovery detection, link flash disconnection processing, link flash disconnection under service pressure, special test equipment, and observable test interface.

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

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

[0034] In an optional embodiment, the attribute table corresponding to the functional test analysis model includes: the quality level of normal function test is the basic level; the quality level of the test for interaction with other functions is the intermediate level; the quality level of abnormal environment test is the intermediate level; the quality level of overload test is the advanced level; the quality level of long-term stability test within load is the advanced level; the quality level of abnormal environment stress test is the advanced level; the quality level of normal and abnormal random stress test is the advanced level; the quality level of specification capacity test is the advanced level; the quality level of performance index test is the advanced level; the quality level of special test equipment is the advanced level; the quality level of special test environment; the quality level of testable interface is the basic level; the quality level of observable interface is the basic level.

[0035] The attribute table corresponding to the configuration 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; the quality level of interface usability is advanced level.

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

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

[0038] 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.

[0039] The attribute table corresponding to the link reliability test analysis model includes: the quality level of link anomaly detection and service fault tolerance is the basic level; the quality level of link anomaly recovery detection is the basic level; the quality level of link flash disconnection processing is the intermediate level; the quality level of link flash disconnection under service pressure is the advanced level; the quality level of special test equipment is the basic level; the quality level of observable test interface is the basic level.

[0040] 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; the quality level of observable test interface is the basic level.

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

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

[0043] The value classification corresponding to the invalid boundary value factor extraction model includes: minimum value, typical value, and maximum value.

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

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

[0046] The value classification corresponding to the data set factor extraction model includes: valid data set and invalid data set.

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

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

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

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

[0051] In an optional embodiment, after receiving the project information, the method further includes: A project model is created, and the project information is stored in the project model.

[0052] After determining the selected test analysis model, the method further includes: The project number of the current project model is saved 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.

[0053] The R&D requirement information in the project information is stored as initial test requirement information in the selected test analysis model.

[0054] After determining the selected test factor model, the method further includes: The analysis model number of the current test analysis model is saved in the test factor model, and an association relationship between the test analysis model and the test factor model is established based on the same analysis model number.

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

[0056] After receiving the factor value information, the method further includes: A test allocation model is created, the factor model number of the current test factor model is saved in the test allocation model, and an association relationship between the test factor model and the test allocation model is established based on the same factor model number.

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

[0058] After receiving the expected result information, the method further includes: A test case model is created, the allocation model number of the current test allocation model is saved in the test case model, and an association relationship between the test allocation model and the test case model is established based on the same allocation model number.

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

[0060] In an optional embodiment, generating the test case description information according to the received scenario description information, the factor value information, and the expected result information includes: According to the association relationship 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 case corresponds one-to-one to the test case model.

[0061] For each of the test cases, the test case description information is generated according to the corresponding scenario description information, the factor value information and the expected result information.

[0062] In an optional embodiment, after determining the selected test factor model, the method further includes: 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.

[0063] After receiving the factor value information, the method further includes: Acquire 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.

[0064] In an optional embodiment, the method further includes: If a description query request is received, the scenario description information, the factor value information, the expected result information or the test case description information specified by the description query request is retrieved from the corresponding model and returned.

[0065] In an optional embodiment, if the description query request specifies the test case description information, after returning the test case description information, the method further includes: If new test case description information is received, the previously stored test case description information is replaced.

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

[0067] The method further comprises: 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.

[0068] 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.

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

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

[0071] To solve the above technical problems, the present invention further provides a chip system test demand analysis device, comprising: The scenario selection module is used to display a list of test scenarios if project information is received.

[0072] The scenario description module is used to return a corresponding analysis scenario input template according to 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.

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

[0074] A 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 execution of the test case corresponding to the current test scenario and the current test factor.

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

[0076] In order to solve the above technical problems, the present invention also provides a computer program product, including a computer program / instruction, which implements the steps of the chip system test requirement analysis method described above when executed by a processor.

[0077] To solve the above technical problems, the present invention further provides a chip system test demand analysis device, comprising: Memory for storing computer programs.

[0078] A processor is used to implement the steps of the chip system test requirement analysis method as described above when executing the computer program.

[0079] To solve the above technical problems, the present invention also provides a non-volatile storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the chip system test requirement analysis method as described above are implemented.

[0080] The present invention provides a chip system test requirement analysis method, which displays all preset test scenarios in a list form for testers to select when receiving project information for chip system testing this time; each time the tester selects a test scenario, all preset test factors are displayed for the tester to further select; after the test factor selection is completed, the corresponding factor value input template and expected test result input template are returned to guide the tester to input the factor value of the test factor, and to execute the expected test result of the corresponding test case under the current test scenario, current test factor and current test factor value.

[0081] Based on the above, this method breaks down the complete test analysis process into four progressively more detailed requirements analysis layers: Test Initial Requirements (TIR) ​​- Test System Requirements (TSR) - Test Allocation Requirements (TAR) - Test Cases (TC). TIR corresponds to the requirements analysis phase for determining test scenarios based on R&D requirements in project information; TSR corresponds to the requirements analysis phase for determining test factors based on test scenarios; TAR corresponds to the requirements analysis phase for determining test factor values ​​based on R&D requirements and test factors; and TC corresponds to the requirements analysis phase for determining the corresponding test cases after the test scenarios, test factors, and test factor values ​​are determined, and the expected results after executing these test cases are determined. Based on this, this method also utilizes a visual tool to assist testers in completing the entire test analysis process during test case development using a four-layer, step-by-step test analysis approach. Testers are guided to enter the corresponding descriptive information at each level of requirements analysis, thereby capturing all the necessary elements for the requirements document during the test analysis process. Therefore, this method can automatically generate test case descriptions based on these captured elements, which serve as the output requirements document for the test project. This four-layer model unifies and refines the test analysis process, isolates differences in the skill and experience of different testers, and improves the quality of test analysis. Secondly, this method guides testers to complete the input of descriptive information for each level of requirement analysis, automatically generates and outputs requirement analysis documents, and can effectively avoid problems such as omissions in requirement analysis documents.

[0082] The chip system test requirement analysis device and non-volatile storage medium provided by the present invention correspond to the above method and have the same effect as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0083] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0084] Figure 1 A flowchart of a chip system test requirement analysis method provided by an embodiment of the present invention.

[0085] Figure 2 A database structure diagram of a test analysis model provided by an embodiment of the present invention.

[0086] Figure 3 A database structure diagram of a test factor model provided by an embodiment of the present invention.

[0087] Figure 4 A diagram of the project test requirement database structure provided by an embodiment of the present invention.

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

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

[0090] Figure 7 This is a structural diagram of a chip system test requirement analysis system provided by an embodiment of the present invention.

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

[0092] Figure 9 A flowchart of a TSR analysis test factor and test case description pre-generation provided by an embodiment of the present invention.

[0093] Figure 10 This is a structural diagram of a chip system test requirement analysis device provided by an embodiment of the present invention.

[0094] Figure 11 This is a structural diagram of another chip system test requirement analysis device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0095] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0096] The core of the present invention is to provide a chip system test demand analysis method, device and medium.

[0097] In order 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 implementation methods.

[0098] In related technologies, the common chip system test analysis process includes: importing the R&D requirements for this test analysis after the system architecture outputs the R&D requirements; testers conduct test requirements analysis based on the R&D requirements and output test requirements analysis documents to guide the writing of test cases; write test cases based on the test requirements analysis documents; screen test cases, execute test cases and annotate test results according to the version plan; and output test reports from dimensions such as test achievement, risks and issues, and next steps.

[0099] In the above process, the steps of conducting test analysis based on the project's R&D requirements and producing test requirements documentation directly impact the quality of subsequent test case development, and therefore the effectiveness of the test itself. Currently, the analysis of chip system test requirements and the writing of test requirements analysis documents are entirely manual. This inevitably leads to the following problems: Test requirements analysis documents developed directly by testers based on R&D requirements analysis may contain only test scenarios but no test factors, or only test factors but no test scenarios. Test scenarios alone cannot provide detailed guidance for test case development, while test factors alone cannot guarantee a comprehensive test scenario analysis. Therefore, both scenarios present the problem of incomplete test requirements analysis. Furthermore, because directly generating a corresponding test requirements analysis document based on R&D requirements requires a high level of expertise, and the professional expertise and experience of different testers vary, comprehensiveness of the test analysis cannot be guaranteed. This can result in test analysis focusing solely on normal functionality while weakening abnormal reliability analysis, or focusing solely on functional testing without stress-related testing, leading to omissions in test type analysis. Furthermore, even if the requirements analysis document is templated to guide testers in test requirements analysis, the lack of tools to verify the format makes this template tool impractical.

[0100] To solve the above problems, the present invention provides a chip system test demand analysis method, such as Figure 1 Shown, including: S11: If project information is received, a test scenario list is displayed.

[0101] S12: According to the test scenario selected in the test scenario list, the corresponding analysis scenario input template is returned.

[0102] Among them, the analysis scenario input template is used to guide the input of scenario description information.

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

[0104] S14: According to the test factor selected in the test factor list, the corresponding factor value input template and the expected test result input template are returned.

[0105] Among them, 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 case corresponding to the current test scenario and the current test factor.

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

[0107] As can be seen from the above, this method uses visualization to assist testers in chip system test requirements analysis and automatically outputs test requirements analysis documents. Therefore, this method should be applied to devices with processing power, display, and human-computer interaction capabilities (hereinafter referred to as "this device"), such as computers and workstations.

[0108] In step S11, the project information includes the test items required for this chip system, including R&D requirements (i.e., system requirements, SR) to represent the fundamental needs of this test analysis. The test scenario list displayed in step S11 includes all possible test scenarios configured for chip system testing on this device, providing a more comprehensive test scenario for testers to analyze and select, avoiding omissions.

[0109] Furthermore, the aforementioned test scenarios can be configured based on the actual chip system testing needs in real-world scenarios. For example, the aforementioned test scenarios can be configured according to ISO standards (standards specified by the International Organization for Standardization) or IEC standards (standards developed by the International Electrotechnical Commission), making the method compatible with currently used international standards such as ISO / IEC.

[0110] In another optional implementation, if a correlation between some of the project information and a specific test scenario is previously discovered, the project information matching that test scenario can be configured when the test scenario is configured for the device. When this information appears in the project information, only the relevant test scenario can be displayed, providing more intelligent test scenario-assisted analysis.

[0111] As for step S12, as can be seen from the above, step S11 is the step of visually displaying all test scenarios to the tester to assist the tester in analyzing the test scenarios corresponding to the current test. After the tester has determined the test scenarios required for R&D needs, they can select some of the visually displayed test scenarios by clicking a mouse, etc. The aforementioned mouse clicking, etc., is a common human-computer interaction method implemented using a mouse input device. Other human-computer interaction methods can also be used to select test scenarios, and this embodiment does not limit this. Once a test scenario is selected, step S12 outputs an analysis scenario input template corresponding to the selected test scenario. The analysis scenario input template is a template that guides the tester in entering scenario description information. For example, the analysis scenario input template may include the necessary keywords and formatting for the scenario description information of the currently selected test scenario, guiding the tester in entering the scenario description information according to unified standards. 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 template corresponding to each scenario type should be completed accordingly when configuring the scenario type.

[0112] In addition, another main purpose of providing the analysis scenario input template in step S12 is to remind the tester to input the scenario description information related to the selected test scenario, so as to be used for the subsequent generation of test case description information, and to avoid omitting the test scenario element when outputting the test requirement analysis document. It should also be noted that when multiple test scenarios are selected, the corresponding analysis scenario input templates can be returned one by one in sequence, or the analysis scenario input templates of all selected test scenarios can be returned at the same time. However, it should be noted that when the latter implementation scheme is adopted, the visual interface needs to distinguish the templates of different test scenarios and determine which test scenario the information entered by the tester is specifically the scenario description information of (this can be achieved through different windows or input boxes marked with scenario type / analysis scenario input template).

[0113] Next, we move on to step S13. Similar to step S11, step S13 also displays the necessary elements for test analysis, but the difference is that it displays test factors. However, it should be noted that step S13 triggers the display of test factors after the tester enters the scenario description information. Its purpose is to avoid omission of scenario description information. That is, only after completing the description input of the previous level test requirement analysis stage (test scenario) will the next level test requirement analysis stage (test factor) be entered.

[0114] In addition, since there may be multiple test scenarios selected in step S12, and the scenario description information corresponds to each test scenario one by one, and the trigger condition of step S13 is the tester inputting a certain scenario description information. Therefore, when executing step S13 of this method, step S13 corresponding to each selected test scenario should be executed in sequence according to the order in which the tester inputs the scenario description information. However, since there are two possible solutions when displaying the analysis scenario input template as described above: First, different test scenarios are executed sequentially. Only after the scenario description information of the previous test scenario is inputted will the analysis scenario input template of the next test scenario be displayed to guide the tester to input the scenario description information.

[0115] In this case, combined with the subsequent steps S13 and S14, it can be seen that the entire process is that after the tester selects a test scenario from the test scenario list, steps S12 to S14 are executed for the test scenario. Only after steps S12 to S14 of this test scenario are executed, the tester is allowed to select the next test scenario from the test scenario list and execute steps S12 to S14 corresponding to this test scenario. Repeat the above process until the tester believes that all test scenarios required for this test have been selected and steps S12 to S14 have been executed to generate the corresponding test case description information. Only then is the test requirement analysis of a test project considered complete.

[0116] Secondly, different test scenarios are executed in parallel and can be distinguished by multiple windows, interfaces or text boxes. At this time, although steps S12 to S14 are still processes that need to be executed separately for each test scenario, the tester can jump arbitrarily between the 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 test factor selection, you can pause and switch to the input of scene description information for test scenario 3 (for example, switching the currently active window, etc.). This implementation scheme is more flexible than the above scheme, but it is also more likely to cause the problem of missing some test scenario processes and not being fully executed. Therefore, in actual applications, different implementation schemes can be selected according to different needs, and this embodiment does not limit this.

[0117] In addition, to better illustrate the various elements of test requirements analysis mentioned above, the following examples are used to illustrate: Taking the testing of Redundant Array of Independent Disks (RAID) in a chip system as an example, let's assume the R&D requirement is "RAID5 supports 3-32 drive counts." Analysis reveals that this requirement primarily addresses testing the RAID5 drive count specifications. Appropriate scenarios include "normal configuration function testing," "interaction with other functions testing," and "abnormal configuration input testing," specifically three specific test scenarios for RAID5 drive count specifications. Furthermore, scenario descriptions provide additional information for these three scenarios. For example, the scenario description for "normal configuration function testing" is "RAID5 valid drive count creation test"; the scenario description for "interaction with other functions testing" is "RAID5 maximum drive count add-on scenario"; and the scenario description for "abnormal configuration input testing" is "RAID5 invalid drive count creation test."

[0118] Furthermore, each test scenario may correspond to a different test factor type. Taking the above-mentioned "normal configuration function test" as an example, the factor value of the "Raid5 valid disk number creation test" has obvious boundary characteristics, so the test factor "valid boundary value" can be used. And there are three specific factor values ​​(i.e. factor value information) of "minimum value", "typical value" and "maximum value". Similarly, taking the "abnormal configuration input test" as an example, the factor value of the "Raid5 invalid disk number creation test" has obvious boundary characteristics, so the test factor "invalid boundary value" can be used. And there are two specific factor values ​​(i.e. factor value information) of "minimum value" and "maximum value".

[0119] Finally, once the aforementioned test scenarios, test factors, and other elements are in place, you can use them to guide the development of test cases. However, completing a complete test requirements analysis also requires analyzing the expected results of executing the written test cases, such as success or failure, which is the expected result information mentioned above.

[0120] From this brief overview of the examples above, we can see that a test scenario is the specific test functionality of the test case to be written, and test factors are the specific parameters required by the test case to implement the corresponding test functionality. The scenario description information provides a descriptive supplement to the test scenario, and the factor value information is the specific values ​​of each parameter in the test factor. The expected result information is the expected execution result of the test case written based on these elements, usually a success or failure.

[0121] In summary, the chip system test requirements analysis method provided by the present invention breaks down all elements of the entire test requirements analysis process into analysis of five nodes: "R&D requirements → test scenarios → test factors → factor values ​​→ test cases." This results in a four-layer test requirements analysis model: "Test initial requirements → test system requirements → test allocation requirements → test cases" (i.e., TIR → TSR → TAR → TC). This guides testers in test requirements analysis using a unified, standardized process. This method can isolate differences in background and experience among testers, improving the quality of test analysis. Furthermore, because this method visually presents all aspects of the test requirements analysis to testers and lists pre-configured test scenarios and test factors (all or relevant) for analysis steps such as test scenarios and test factors, it effectively avoids omissions that testers may make when analyzing requirements, improving the comprehensiveness of the analysis. Furthermore, after obtaining scenario description information, factor value information, and expected result information, this method obtains all the elements necessary to generate a complete test case description, enabling testers to generate test case descriptions on their behalf. This means that testers no longer need to write test case descriptions; instead, corresponding requirements analysis documents can be output to guide subsequent test case writing. This further reduces the risk of omissions or writing errors caused by human factors, and better ensures the comprehensiveness and reliability of test requirements analysis.

[0122] On the other hand, the above embodiment illustrates that this method can generate test case description information based on scenario description information, factor value information, and expected result information, but does not limit the specific implementation method. In an optional implementation, the three fields corresponding to the scenario description information, factor value information, and expected result information can be concatenated end to end in any order to generate a single field, thereby generating the test case description information.

[0123] However, this approach presents a problem. In practice, testers typically generate text-based test requirements analysis documents based on R&D requirements. However, subsequent test case development often involves using spreadsheets. Because these two documents are separate deliverables, there's no guarantee of a one-to-one correspondence between test factors and test cases.

[0124] In response to the above problem, this embodiment also provides an optional implementation scheme. The above step S15 is specifically as follows: S151: Determine the test case description element according to the triple mapping rule.

[0125] The triplet elements of the triplet mapping rule include: test scenario, test factor, and expected result. (As mentioned above, the expected result is the expected test result 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).

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

[0127] In this embodiment, using triple mapping rules, a test requirements analysis document can be output in the form of a table document. This document contains three elements: scenario description information corresponding to the test scenario, factor value information corresponding to the test factor, and expected result information corresponding to the expected result (test case). This effectively unifies the document formats of the two different stages, facilitating a smooth transition and efficient communication between the requirements analysis stage and the test case writing stage.

[0128] It should also be noted that one test case description information corresponds to one test case, and multiple test cases may be obtained after analyzing the R&D needs in a project. Therefore, during the execution of the above method, a project may have multiple scenario description information, factor value information and expected result information. At this time, it is necessary to determine the association relationship between the scenario description information, factor value information and expected result information based on the correspondence between the above steps S12~S14. Specifically, in the above steps, a test scenario is selected and the scenario description information is input to trigger the selection of the test factor, and the test factor selected subsequently corresponds to this test scenario; then, based on the correspondence between the scenario description information and the test scenario, and the relationship between the factor value information and the expected result information and the test factor, the association relationship between the scenario description information, the factor value information and the expected result information can be obtained, and a set of test case description elements can be obtained.

[0129] On the other hand, in actual applications, there may be a situation where a scenario type (a scenario description information) corresponds to multiple scenario descriptions, and a test factor (a factor value information) corresponds to multiple specific factor values. For example, the scenario description information corresponding to the "interaction test with other functions" is the "adding disk scenario under the condition of Raid5 maximum disk", but further, there are two possible situations for adding disks: self-expansion and external disk migration, so the "adding disk scenario under the condition of Raid5 maximum disk" can be divided into "capacity expansion" (i.e. capacity expansion under the condition of Raid5 maximum disk) and "Raid0 migration to Raid5" (i.e. migration under the condition of Raid5 maximum disk). At this time, the tester input information may contain two scenario description information. Similarly, for the "valid boundary value", its possible value types include "minimum value", "typical value" and "maximum value", that is, the tester input information also contains multiple specific factor value information. In view of this, in order to distinguish this situation, this embodiment provides a corresponding implementation plan, and this method also includes: S2: If there is a preset separator in the received scene description information / factor value information, decompose the received scene description information / factor value information into multiple scene description information / factor value information corresponding to different test scenes / test factors according to the preset separator.

[0130] It should be noted that this embodiment does not limit the specific meaning of the preset delimiter. An appropriate symbol or symbol combination can be freely selected as the preset delimiter according to actual needs. However, it should be noted that the preset delimiter should be a symbol or symbol combination that the tester will not use when entering descriptive information such as scenario description information and factor value information, so as to avoid confusion with valid descriptive information. In an optional embodiment, the above-mentioned preset delimiter is "&&".

[0131] Taking the above-mentioned preset delimiter "&&" as an example, assuming that the tester needs to enter the scenario description information of "interaction test with other functions" (scenario of adding disks under the condition of maximum disk of Raid5), he can enter "expand capacity && migrate Raid0 to Raid5". At this time, based on the preset delimiter "&&", it can be identified that the tester has entered two different scenario description information corresponding to the current test scenario.

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

[0133] In view of this, this embodiment provides an optional display method. The display of the test scenario list in step S11 specifically includes: S111: Display the test analysis model list.

[0134] The test analysis model list includes a plurality of test analysis models with different test scenario types, and each test analysis model stores one or more different test scenarios.

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

[0136] Similarly, the test factor list displayed in step S13 specifically includes: S131: Display the test factor model list.

[0137] 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.

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

[0139] As can be seen from the 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 stored test scenarios and test factors when selected, it can meet the model requirements of this embodiment.

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

[0141] Correspondingly, after selecting the test analysis model or the test factor model, the method further includes: displaying a corresponding attribute table.

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

[0143] It should be noted that the three quality levels defined in this embodiment are merely an optional solution and are formulated based on currently commonly used ISO and IEC standards. In actual applications, other quality levels may be formulated based on other standards or for other needs, and this embodiment does not limit this.

[0144] In addition, it can serve as a further supplementary explanation for the value classification. As shown in the above example of the test factor "effective boundary value", it has three value types: "minimum value", "typical value" and "maximum value". That is, the attribute of value classification can be used to guide the tester to enter three specific values ​​corresponding to "minimum value", "typical value" and "maximum value" as factor value information when entering the factor value information corresponding to the "effective boundary value". At this time, the factor value input template of the test factor can be a template that guides the tester to enter the numerical format, such as binary, decimal, or single floating point, double floating point, integer and other format requirements for the test factor value.

[0145] Furthermore, the above-mentioned attribute table may be stored in the model in the form of a JSON (JavaScript Object Notation) table, which is not limited in this embodiment.

[0146] The attribute table provided in this embodiment can further help testers understand the attributes of each test scenario or test factor, thereby facilitating testers to analyze requirements and select appropriate test scenarios or test factors, thereby improving the reliability and comprehensiveness of test analysis.

[0147] In addition, based on the previous embodiment, this embodiment also provides a further implementation scheme for the display of the above test scenario. Before the above step S112, this method further includes: S113: Display the quality level list.

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

[0149] Among them, after the quality level is input, the test analysis model matches and outputs test scenarios with a quality level less than or equal to the input from the test scenario set stored in itself.

[0150] That is, in this embodiment, the test analysis model no longer outputs all stored test scenarios upon selection. Instead, based on the quality level selected by the tester (the quality level input into the test analysis model), it matches and outputs stored test scenarios of the corresponding quality level. In this case, the test scenarios acquired and displayed in step S112 are those that meet the tester's current quality level requirements.

[0151] It should be noted that the test analysis model in this embodiment matches quality levels with backward compatibility. That is, when matching for an intermediate quality level, the matched test scenarios include those at the basic and intermediate levels. Similarly, if the selected quality level is advanced, since advanced is the highest of the three quality levels, the test analysis model outputs all stored test scenarios according to the backward-compatible matching rules. It should also be noted that this backward-compatible matching rule is merely an optional implementation provided in this embodiment, adapted to meet the needs of current general standards. That is, the test scenario requirements for a higher quality level include all the requirements for test scenarios at a lower quality level. In other implementation scenarios, other matching rules may be adopted based on different needs, and this embodiment does not limit this. However, the solution provided in this embodiment, which matches corresponding test scenarios based on quality level for presentation to testers, can effectively reduce the number of test scenarios presented to testers. Furthermore, the presented test scenarios are more relevant to the test requirements, achieving a more flexible and convenient test scenario presentation solution.

[0152] Furthermore, the above embodiments do not limit specific test analysis models and test factor models. However, they do illustrate that test analysis models and test factor models can be pre-configured based on standards used in actual applications. In this embodiment, an optional implementation of a test analysis model and test factor model is provided, specifically for currently used ISO and IEC standards.

[0153] The test analysis models specifically include: functional test analysis model, configuration test analysis model, drive test analysis model, performance test analysis model, compatibility test analysis model, link reliability test analysis model, reliability test analysis model and extended test analysis model.

[0154] The test factor model specifically includes: valid boundary value factor extraction model, invalid boundary value factor extraction model, state factor extraction model, ordered operation factor extraction model, data set factor extraction model, testable interface factor extraction model, observable interface factor extraction model, testable device factor extraction model and extended analysis factor extraction model.

[0155] Furthermore, based on the currently used ISO and IEC standards, specific test scenario solutions are provided for each test analysis model: 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.

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

[0157] 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.

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

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

[0160] 6. The test scenarios corresponding to the link reliability test analysis model include: link anomaly detection and service fault tolerance, link anomaly recovery detection, link disconnection processing, link disconnection under service pressure, special test equipment, and observable test interface.

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

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

[0163] Furthermore, based on the various test analysis models provided in the above embodiments, this embodiment also provides an optional implementation scheme of the quality table stored therein: 1. The attribute table corresponding to the functional test analysis model includes: the quality level of normal function test is the basic level; the quality level of interaction test with other functions is the intermediate level; the quality level of abnormal environment test is the intermediate level; the quality level of overload test is the advanced level; the quality level of long-term stability test under load is the advanced level; the quality level of abnormal environment stress test is the advanced level; the quality level of normal and abnormal random stress test is the advanced level; the quality level of specification capacity test is the advanced level; the quality level of performance index test is the advanced level; the quality level of special test equipment is the advanced level; the quality level of special test environment is the basic level; the quality level of testable interface is the basic level; the quality level of observable interface is the basic level.

[0164] 2. The attribute table corresponding to the configuration 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; the quality level of interface usability is advanced level.

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

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

[0167] 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; the quality level of special test equipment is the basic level.

[0168] 6. The attribute table corresponding to the link reliability test analysis model includes: the quality level of link anomaly detection and service fault tolerance is the basic level; the quality level of link anomaly recovery detection is the basic level; the quality level of link flash disconnection processing is the intermediate level; the quality level of link flash disconnection under service pressure is the advanced level; the quality level of special test equipment is the basic level; the quality level of observable test interface is the basic level.

[0169] 7. The attribute table corresponding to the reliability test analysis model includes: the quality level of business fault tolerance is the basic level; the quality level of business recovery capability is the basic level; the quality level of fault tolerance 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; the quality level of observable test interface is the basic level.

[0170] 8. 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; the quality level of the advanced test is the advanced level.

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

[0172] Table 1 Common test analysis models and their attribute values ​​json table

[0173] In addition, in combination with the test analysis model and test scenario provided in the above embodiment, a possible example is provided to illustrate the implementation of S111~S114 in the above embodiment: Assuming that the tester selects a functional test analysis model and the selected quality level is an intermediate level, based on the above Table 1, it can be seen that the analysis scenario input template displayed at this time can be as shown in Table 2 below.

[0174] Table 2 Functional test analysis model + visual input template for intermediate quality level

[0175] On the other hand, for the test factor model provided in the above embodiment, this embodiment also provides an optional implementation scheme of its attribute table based on the currently common ISO and IEC standards: 1. The value categories corresponding to the effective boundary value factor extraction model include: minimum value, typical value, and maximum value.

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

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

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

[0179] 5. The value classification corresponding to the data set factor extraction model includes: valid data set and invalid data set.

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

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

[0182] 8. The value categories corresponding to the testable device factor extraction model include: function enumeration.

[0183] 9. The value categories corresponding to the extended analysis factor extraction model include: factor set.

[0184] Based on the implementation plans provided by the above embodiments for the test factor model, the test factor model shown in Table 3 below is obtained.

[0185] Table 3 Test factor model and its attribute value json table

[0186] Similarly, in combination with the test factor model and value classification provided in the above embodiment, a possible example is also provided to illustrate the implementation of S131 and S132 in the above embodiment: Assuming that the tester selects the effective boundary value test factor model, based on the above Table 3, it can be seen that the factor value input template and expected result template displayed at this time can be shown in the following Table 4.

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

[0188] It is not difficult to see from the above that each test analysis model and test factor model can be implemented through a database structure. It stores information such as test scenarios, test factors, attribute value json tables, and can schedule all or part of the information for display when needed. The database structure can meet all the above requirements and is commonly used for data storage in various computing devices. It is simple and easy to implement. In addition, the database can distinguish different models (test analysis models, test factor models) by model number (ID). Figure 2 The test analysis model shown, and Figure 3 In the test factor model shown, each model's corresponding database structure stores information such as the model ID, name (model description), description (scenario description or factor value information), and attribute value JSON tables. The model ID serves as the primary key (PK) of this database, matching other tables or data with corresponding foreign keys (FKs). This establishes a relationship between the two databases through the PK and FK.

[0189] Furthermore, for example, the R&D requirement "Raid5 supports 3-32 disks" in the above embodiment is used as an example. As can be seen from the above description, the test analysis model selected for this R&D requirement is the configuration-based test analysis template. After the tester completes the TIR-level information input according to this method, the information shown in Table 5 below is obtained.

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

[0191] Next, we analyze the TSR. The factor values ​​for the "Raid5 effective disk number creation test" have obvious boundary characteristics. The "effective boundary value" model is used to analyze the minimum, typical, and maximum values. The "Raid5 invalid disk number creation test" has obvious boundary characteristics. The "invalid boundary value" model is used to analyze the minimum and maximum values. There is currently no direct and effective analysis model for the "adding disks to the Raid5 maximum disk situation scenario." We can use the "expansion analysis" model to analyze it. Through analysis, we know that "Raid5 expansion requires adding one disk. If Raid5 already has 32 disks, adding one more disk will result in 33 disks, which exceeds the maximum specification of 32 disks." At the same time, "Raid0 needs to add one disk when migrating to Raid5. If Raid0 also has 32 disks, and migrating to Raid5 requires adding one disk, then the resulting Raid5 will have 33 disks, which does not meet the maximum specification of 32 disks." Fill in the values ​​obtained according to the analysis instructions in the "Analysis Input Template" and fill in the test results for each category value. Because the "Adding a disk to a maximum RAID 5" scenario analysis test factors have two, they are expressed here using the "&&" delimiter. The "Model Analysis Result Save" module analyzes the input template content according to the delimiter to obtain two test factors. The "Pre-Generated Use Case" module analyzes the input template content according to the delimiter to obtain two test factors, and the test results of both factors share the same "failure." Two test case descriptions are output in the "TSR, Factor Value, Result" format: "Adding a disk to a maximum RAID 5 scenario, expansion, failure" and "Adding a disk to a maximum RAID 5 scenario, migration from RAID 0 to RAID 5, failure." The resulting TAR and use case description information are shown in Table 6 below.

[0192] Table 6 Schematic diagram of TAR and use case description obtained from TSR analysis

[0193] It's also worth noting that the factor value information for the "Adding a Drive to a Maximum RAID 5" scenario has two sub-information items: "Capacity Expansion" and "Raid0 to RAID 5 Migration." These two sub-information items correspond to two different test cases. However, because they both represent the factor values ​​of a test factor within the same test scenario (not necessarily in numerical form), they share the same test result.

[0194] On the other hand, this embodiment also provides another optional implementation scheme. After receiving the project information in step S11, the method further includes: S31: Create a project model and store project information in the project model.

[0195] After determining the selected test analysis model, it also includes: S32: Save the project number of the current project model in the test analysis model, and establish an association relationship between the project model and the test analysis model based on the same project number.

[0196] S33: The R&D requirement information in the project information is saved as initial test requirement information in the selected test analysis model.

[0197] After determining the selected test factor model, it also includes: S34: 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 based on the same analysis model number.

[0198] S35: The scenario description information corresponding to the current test scenario is saved in the selected test factor model as the test system requirement information.

[0199] After receiving the factor value information, it also includes: S36: Create a test allocation model, save the factor model number of the current test factor model in the test allocation model, and establish an association relationship between the test factor model and the test allocation model based on the same factor model number.

[0200] S37: The factor value information corresponding to the current test factor is saved as the test allocation requirement information in the currently created test allocation model.

[0201] After receiving the expected result information, it also includes: S38: Create a test case model, save the allocation model number of the current test allocation model in the test case model, and establish an association relationship between the test allocation model and the test case model based on the same allocation model number.

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

[0203] like Figure 4 As shown, this embodiment also establishes Figure 4 The project test requirement database structure is shown in Figure 1. The project test requirement database structure consists of five different levels of model databases, including project model, test analysis model (i.e. Figure 5 TIR model in ), test factor model (i.e. Figure 5 TSR model in ), test allocation model (i.e. Figure 5 TAR model in ) and test case model (i.e. Figure 5TC model in). Model databases at each level are associated with each other through PK and FK. The PK of the upper-level model database can be matched to the FK of the corresponding database in the lower-level model database.

[0204] It is easy to understand that the establishment of the association relationship in this embodiment is based on the generation of the selection instructions of the tester. Specifically, as described in the above steps S31 to S39, 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 this project. Afterwards, according to step S11, a list of scenarios will be displayed to the tester. At this time, the test scenario selected by the tester is the test scenario that the tester believes is relevant to the current project. At this time, the association relationship between the corresponding test analysis model and the project model is established, and the associated project number table item can be added as the FK in the database of the corresponding test analysis model. After the association relationship is established, relevant information can be written under this database table item, such as the TIR number, TIR name, TIR description, TIR priority, and other information that characterizes the test scenario. Among them, the TIR description is the information based on which the tester selects the current test analysis model, which can be the R&D requirement SR in the project information. Similarly, once a test scenario is selected and the scenario description is entered, the test factor list is displayed and a test factor is selected. The selected test factor is the test factor associated with the previously selected test scenario. The associated TIR number (that is, the TIR number stored in the test analysis model database corresponding to the associated test scenario) can be added as a FK in the database of the corresponding test factor model to establish a relationship between the model databases. Similarly, the TAR model corresponding to the factor value information and the TC model corresponding to the test case also store relevant information and establish a relationship with the previous model data in the same way.

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

[0206] In the above embodiments, Figure 4Based on the project test requirement database structure diagram shown, we can get the association chain corresponding to all test requirements under a project. An association chain is composed of the databases of "project model - TIR model - TSR model - TAR model - TC model", and each database records the test requirement analysis information of the corresponding level. However, it should be noted that a model database does not necessarily record only the information of an association chain. For example, for a certain TIR model database, it may record the numbers of multiple associated projects to which it is associated. That is, this model is used in multiple test projects, and the same applies to subsequent levels.

[0207] However, in general, the test requirements analysis document is output per R&D requirement (i.e., a test project). Based on the corresponding project model number, all associated TIR model database entries in the TIR model hierarchy are traversed (i.e., including the associated project number as the TK). Next, using the TIR number of each associated TIR model database entry, all associated TAR model database entries in the next level, the TSR model database, are found. This process continues until all associated database entries in the final level, the TC model, are identified. This results in a tree-like relationship network starting from a project number. Each tail node (i.e., the TC model hierarchy) of this relationship network, traversing back to the head node (i.e., the project model hierarchy), yields a relationship chain. Each relationship chain identifies the test case description information corresponding to a test instance (i.e., corresponding to a TC model). After generating all the test case descriptions for a project, the project's test requirements analysis document can be integrated and output.

[0208] In addition, in addition to the information described above, each model database can also add the entry of other information items based on actual needs, such as the specific factor value (TAR value) recorded by the TAR model, the use case number of the TC model, the use case description (test case description information generated in step S14), the use case preconditions, the test steps, the test expectations (i.e., the expected result information mentioned above), etc.

[0209] Furthermore, the above embodiment only requires the tester to input the scenario description information, factor value information, expected result information, and other descriptive information required to generate the test case description information. Among them, the scenario description information can better reflect the process of how the tester obtains the corresponding test scenario based on the R&D demand analysis. However, for the conversion of test scenarios to test factors, and from test factors to specific test factor values, there is currently no descriptive information to reflect the tester's demand analysis process (i.e., the analysis process from TIR to TSR, and the analysis process from TSR to TAR), which cannot provide better demand analysis guidance for subsequent testers. Based on this, this embodiment also provides a further implementation plan.

[0210] After determining the selected test factor model, the above method further includes: S41: Acquire test scenario analysis process information, and record the test scenario analysis process information in a first association table.

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

[0212] After receiving the factor value information, it also includes: S42: Acquire test factor analysis process information, and record the test factor analysis process information in the second association table.

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

[0214] Specifically, the first association table is the data table associated with the TIR model and TSR model, which describes the analysis information of the tester in the process from the TIR model to the TSR model in the relationship chain. Therefore, a test scenario analysis process information in the first association table is associated with the TIR model database and TSR model database on the same relationship chain. Figure 5 As shown, an entry in the first association table should include the associated TIR number and TSR number as foreign keys to achieve the association with the corresponding TIR model database and the TIR model database. Figure 5 As shown, the first association table can also record other information that is helpful for test requirement analysis, such as the associated test analysis model number (i.e., the test analysis model based on which the test scenario is determined) and the model attribute value used when generating TSR (i.e., the quality level input into the test analysis model when obtaining the test scenario), etc.

[0215] The same is true for the second association table, such as Figure 6 As shown, an entry in the second association table should include the associated TSR number and TAR number as foreign keys to establish a connection 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., the test factor model based on which the test factor is determined) and the model attribute value used when generating the TAR (i.e., the value classification of the test factor model used when obtaining factor value information).

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

[0217] On the other hand, the information stored in the above databases and associated tables also supports querying, and testers can query the information stored in the specified data table items based on the corresponding numbers. That is, this embodiment provides an optional implementation scheme, and the above method also includes: S51: If a description query request is received, the scenario description information, factor value information, expected result information or test case description information specified by the description query request is retrieved from the corresponding model and returned.

[0218] It is not difficult to understand that the scenario description information, factor value information, expected result information or test case description information illustrated in this embodiment is only a basic description information. In the above embodiment, a solution for recording other description information is also provided. Under the premise of implementing the corresponding solution, this embodiment can also query this part of the description information.

[0219] Furthermore, it can be seen from the above embodiment that 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 "adding a disk scenario in the case of the largest disk in Raid5, migrating Raid0 to Raid5, failed". However, the above automatically generated test case description information may not conform to the general language habits of testers, so this embodiment also provides a further implementation plan. When the description information to be queried is specified as test case description information in the above step S191, then after step S191, this method further includes: S52: If new test case description information is received, the previously stored test case description information is replaced.

[0220] In other words, this embodiment supports modification of test case description information to resolve semantic inconsistencies that may exist in test case description information automatically generated by this method. However, it should be noted that modification of description information is not limited to test case description information. However, since other description information is manually entered by the tester, semantic inconsistencies do not exist. Only the test case description information is automatically generated by this method. Therefore, this embodiment uses test case description information as an example to provide a query and modification method.

[0221] On the other hand, in addition to the solution of modifying the description information provided in the above embodiment, this embodiment provides a modification solution for the test analysis model and the test factor model: The test analysis model and test factor model are saved in the test model baseline library.

[0222] The method further comprises: S61: If a model addition request is received, the test analysis model or test factor model carried in the model addition request is added to the test model baseline library.

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

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

[0225] S64: If a model query request is received, the test analysis model / test factor model specified by 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.

[0226] That is, this method supports the "addition, deletion, modification and query" of the test analysis model and the test factor model. After the device is put into use for test analysis, the test analysis model and the test factor model can also be adjusted according to changes in actual applications to meet different needs.

[0227] Based on the above embodiments, it can be seen that the functions implemented by this method are divided into the following three parts: 1. Model processing part.

[0228] That is, it includes the information display and input information storage parts corresponding to the above steps S11~S14, S2, S31~S39, and S41~S42.

[0229] 2. Model management part.

[0230] That is, it includes the management function part of adding, deleting, modifying and checking the modules and description information corresponding to the above steps S51~S52, S61~S64.

[0231] 3. Use case generation part.

[0232] That is, it corresponds to the test case description information generation part implemented in the above step S15.

[0233] Among them, the model processing part and the use case generation part are both business-side functions, while the model management part belongs to the management-side function. In actual applications, the above three functional parts can be implemented through three different functional modules in 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 use case generation module 13, each of which is used to perform the three aforementioned functional components and their corresponding steps. Specifically, 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 displaying information) and model analysis result storage (i.e., for storing information entered by the tester); and the use case generation module 13 has a single function: generating test case descriptions, without multiple sub-modules. However, it should be noted that the above embodiment provides an implementation scheme in which the test case description information generated by this method may contain semantic inconsistencies and can be modified by the tester after querying. Therefore, the process of generating test case description information by the use case generation module can also be referred to as "pre-generation of test case description information." The final test case description information is only obtained after the tester queries and modifies it.

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

[0235] For the TIR demand analysis phase, the human-computer interaction process is as follows: Figure 8 Shown, including: S71: The tester enters the project information into the project database.

[0236] S72: The tester enters the R&D requirements as TIR into the TIR database.

[0237] S73: The tester queries the TIR list of the project.

[0238] S74: The tester selects a TIR to be analyzed from the TIR list, and selects a suitable analysis model from the test analysis model list and quality level list displayed by the model processing module.

[0239] S75: The tester analyzes the attribute values ​​of the test analysis model displayed by the model processing module, and fills the results in an input template related to the analysis attribute values.

[0240] S76: After the tester confirms the analysis result, the tester saves the analysis result. The model processing module sequentially traverses the input template after each analysis item, splits the value in the input box according to the delimiter, and adds a TSR table item and a TIR and TSR association table item.

[0241] For the TSR requirement analysis phase and the test case description information pre-generation phase, the human-computer interaction process is as follows: Figure 9 As shown, including: S81: The tester queries the TSR list in the project.

[0242] S82: The tester selects the TSR to be analyzed from the TSR list, and selects a suitable analysis model from the test factor model list displayed by the model processing module.

[0243] S83: The tester analyzes the attribute values ​​of the test factor model displayed by the model processing module, and fills the results in the input template related to the analysis attribute value, and fills in the test results of this type of factor in the corresponding test result input template.

[0244] S84: The tester confirms the analysis results and saves them. The model processing module sequentially traverses the input template after each analysis item, splits the values ​​in the input box according to the delimiter, and adds a TAR table entry and a TSR and TAR association table entry. The use case pre-generation module sequentially traverses the input template after each analysis item, splits the values ​​in the input box according to the delimiter, and outputs the test case description in the format of "TSR", "TAR", and "test result", and adds a use case table entry.

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

[0246] Since the embodiments of the computer program product part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the computer program product part, and will not be repeated here.

[0247] In the above embodiment, a chip system test requirements analysis method is described in detail. The present invention also provides a corresponding embodiment of a chip system test requirements analysis device. It should be noted that the present invention describes the device embodiment from two perspectives: one from the perspective of functional modules and the other from the perspective of hardware.

[0248] Based on the perspective of functional modules, such as Figure 10 As shown, this embodiment provides a chip system test requirement analysis device, including: The scenario selection module 21 is used to display a list of test scenarios upon receiving project information.

[0249] The scenario description module 22 is used to return a corresponding analysis scenario input template according to 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.

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

[0251] 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; wherein the factor value input template is used to guide the input of the factor value information of the current test factor, and the test result input template is used to guide the input of the expected result information after the execution of the test case corresponding to the current test scenario and the current test factor.

[0252] The use case description module 25 is used to generate test case description information according to the received scenario description information, factor value information and expected result information.

[0253] Since the embodiments of the apparatus part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the apparatus part, and they will not be repeated here.

[0254] Figure 11 A structural diagram of a chip system test requirement analysis device provided by another embodiment of the present invention is shown as follows: Figure 11 As shown, a chip system test requirement analysis device includes: a memory 30 for storing computer programs.

[0255] The processor 31 is configured to implement the steps of a chip system test requirement analysis method according to the above embodiment when executing a computer program.

[0256] The chip system test requirement analysis device provided in this embodiment may include but is not limited to a mobile terminal, a personal computer, a workstation, etc.

[0257] Among them, the processor 31 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 31 can be implemented in at least one hardware form of a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic array (PLA). The processor 31 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 31 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 31 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

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

[0259] In some embodiments, a chip system test requirement 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 .

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

[0261] An embodiment of the present invention provides a chip system test requirement analysis device, which includes 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 requirement analysis method.

[0262] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiment.

[0263] It is understood that if the methods in the above embodiments are implemented in the form of 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, or the portion 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 each embodiment of the present invention. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0264] The above is a detailed introduction to a chip system test requirement analysis method, device and medium provided by the present invention. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present invention, the present invention can also be improved and modified in several ways, and these improvements and modifications also fall within the scope of protection of the present invention.

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

Claims

1. A chip system test requirements analysis method, characterized in that: include: If project information is received, a list of test scenarios is displayed; Returning a corresponding analysis scenario input template according to 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; Whenever the scenario description information corresponding to one of the test scenarios is received, a list of test factors 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 the test case corresponding to the current test scenario and the current test factor; Test case description information is generated according to the received scenario description information, the factor value information and the expected result information.

2. The chip system test requirement analysis method according to claim 1, characterized in that: Generating test case description information according to the received scenario description information, the factor value information, and the expected result information includes: Determine a test case description element according to a triple mapping rule; wherein the triple element of the triple mapping rule includes: a test scenario, a test factor, and an expected result; the test case description element includes: 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 the 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, characterized in that: Also includes: If there is a preset separator in the received scene description information / the factor value information, the received scene description information / the factor value information is decomposed into multiple scene description information / the factor value information corresponding to different test scenes / the test factors according to the preset separator.

4. The chip system test requirement analysis method according to any one of claims 1 to 3, characterized in that: The list of test scenarios shown includes: Displaying a test analysis model list; wherein the test analysis model list includes multiple test analysis models with different test scenario types, and each of the test analysis models stores one or more different test scenarios; Displaying each of the test scenarios output by the selected test analysis model in the form of a test scenario list; The test factors list includes: Displaying a list of test factor models; wherein the list of test factor models includes a plurality of test factor models with different test factor types, and each of the test factor models 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, characterized in that: Each of the test analysis models and each of the test factor models further includes an attribute table; After selecting the test analysis model or the test factor model, the method further includes: displaying the corresponding attribute table; Among them, the attribute table of the test analysis model includes the quality level corresponding to each of the test scenarios; the quality levels include, from low to high, basic level, intermediate level and advanced level; the attribute table of the test factor list includes the value classification corresponding to each of the test factors.

6. The chip system test requirement analysis method according to claim 5, characterized in that: Before displaying the test scenarios output by the selected test analysis model in the form of the test scenario list, the method further includes: Display a list of quality levels; inputting the selected quality level into the selected test analysis model; Wherein, after receiving the quality level input, the test analysis model matches and outputs the test scenario whose quality level is 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 in that: The test analysis models include: functional test analysis model, configuration test analysis model, drive test analysis model, performance test analysis model, compatibility test analysis model, link reliability test analysis model, reliability test analysis model and extended test analysis model; The test factor model includes: a valid boundary value factor extraction model, an invalid 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, characterized in that: 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; The test scenarios corresponding to the configuration-based test analysis model include: normal configuration function test, interaction test with other functions, abnormal configuration input test, specification capacity test, and interface usability; The test scenarios corresponding to the driver test analysis model include: driving normal functions, 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 anomaly detection and service fault tolerance, link anomaly recovery detection, link flash disconnection processing, link flash disconnection under service pressure, special test equipment, and observable test interface; The test scenarios corresponding to the reliability test analysis model include: business fault tolerance, business recovery capability, fault tolerance under business pressure, 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 advanced testing.

9. The chip system test requirement analysis method according to claim 8, characterized in that: The attribute table corresponding to the functional test analysis model includes: the quality level of normal function test is basic level; the quality level of test for interaction with other functions is intermediate level; the quality level of abnormal environment test is intermediate level; the quality level of overload test is advanced level; the quality level of long-term stability test under load is advanced level; the quality level of abnormal environment stress test is advanced level; the quality level of normal and abnormal random stress test is advanced level; the quality level of specification capacity test is advanced level; the quality level of performance index test is advanced level; the quality level of special test equipment is advanced level; the quality level of special test environment is basic level; the quality level of testable interface is basic level; the quality level of observable interface is basic level; The attribute table corresponding to the configuration 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; the quality level of interface usability is advanced level; The attribute table corresponding to the driver test analysis model includes: the quality level of the driver's normal function is the basic level; the quality level of the installation and uninstallation test is the basic level; the quality level of the repeated installation and uninstallation stress test is the intermediate level; the quality level of the coexistence test with other drivers is the intermediate level; The attribute table corresponding to the performance test analysis model includes: the quality level of the performance index test is the basic level; the quality level of the special test equipment is the basic level; The attribute table corresponding to the compatibility test analysis model includes: the quality level of uplink compatibility as the basic level; the quality level of downlink compatibility as the basic level; the quality level of special test equipment as the basic level; The attribute table corresponding to the link reliability test analysis model includes: the quality level of link anomaly detection and service fault tolerance is the basic level; the quality level of link anomaly recovery detection is the basic level; the quality level of link flash disconnection processing is the intermediate level; the quality level of link flash disconnection under service pressure is the advanced level; the quality level of special test equipment is the basic level; the quality level of observable test interface is the basic level; The attribute table corresponding to the reliability test analysis model includes: the quality level of business fault tolerance is the basic level; the quality level of business recovery capability is the basic level; the quality level of fault tolerance 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; the quality level of observable test interface is the basic level; The attribute table corresponding to the extended test analysis model includes: the quality level of basic test is basic level; the quality level of intermediate test is intermediate level; and the quality level of advanced test is advanced level.

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

11. The chip system test requirement analysis method according to claim 4, characterized in that: After receiving the project information, the method further includes: Creating a project model and storing the project information in the project model; After determining the selected test analysis model, the method further includes: 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 based on the same project number; saving the R&D requirement information in the project information as initial test requirement information in the selected test analysis model; After determining the selected test factor model, the method further includes: 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 based on the same analysis model number; Saving the scenario description information corresponding to the current test scenario as test system requirement information in the selected test factor model; After receiving the factor value information, the method further includes: 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 based on the same factor model number; Saving the factor value information corresponding to the current test factor as test allocation requirement information in the currently created test allocation model; After receiving the expected result information, the method further includes: 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 based on the same allocation model number; The expected result information corresponding to the current factor value information is saved as test case information in the currently created test case model.

12. The chip system test requirement analysis method according to claim 11, characterized in that: Generating the test case description information according to the received scenario description information, the factor value information, and the expected result information includes: Determining the scenario description information, the factor value information, and the expected result information corresponding to each test case based on an association relationship chain formed by the project model, the test analysis model, the test factor model, the test allocation model, and the test case model; wherein the test cases correspond to the test case models in a one-to-one manner; For each of the test cases, the test case description information is generated according to the corresponding scenario description information, the factor value information and the expected result information.

13. The chip system test requirement analysis method according to claim 11, characterized in that: After determining the selected test factor model, the method further includes: 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; After receiving the factor value information, the method further includes: Acquire 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.

14. The chip system test requirement analysis method according to claim 11, characterized in that: Also includes: If a description query request is received, the scenario description information, the factor value information, the expected result information or the test case description information specified by the description query request is retrieved from the corresponding model and returned.

15. The chip system test requirement analysis method according to claim 14, characterized in that: If the description query request specifies the test case description information, after returning the test case description information, the method further includes: If new test case description information is received, the previously stored test case description information is replaced.

16. The chip system test requirement analysis method according to claim 5, characterized in that: The test analysis model and the test factor model are stored in a test model baseline library; The method further comprises: 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; If a model deletion request is received, deleting the test analysis model or the test factor model specified in the model deletion request from the test model baseline library; If a model change request is received, overwriting the original test analysis model / test factor model in the test model baseline library with the test analysis model / test factor model carried in the model change request; If a model query request is received, the test analysis model / the test factor model specified by the model query request is retrieved from the test model baseline library, and the corresponding test scenario / the test factor and the corresponding attribute table are displayed.

17. A chip system test demand analysis device, characterized in that: include: The scenario selection module is used to display the test scenario list if the project information is received; A scenario description module, configured to return a corresponding analysis scenario input template according to 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; a factor selection module, configured to display a list of test factors whenever receiving the scenario description information corresponding to a test scenario; A factor description module is used to return a corresponding factor value input template and an expected test result input template according to 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 execution of the test case corresponding to the current test scenario and the current test factor; The use case description module is used to generate test case description information based on the received scenario description information, the factor value information and the expected result information.

18. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the chip system test requirement analysis method according to any one of claims 1 to 16 are implemented.

19. A chip system test requirement analysis device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the chip system test requirement analysis method as described in any one of claims 1 to 16 when executing the computer program.

20. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps of the chip system test requirement analysis method according to any one of claims 1 to 16.

Images