CN117743176A

CN117743176A - Demand testing method and device, storage medium and computer equipment

Info

Publication number: CN117743176A
Application number: CN202311786899.XA
Authority: CN
Inventors: 赵博强; 甘维
Original assignee: Guangzhou Pinwei Software Co Ltd
Current assignee: Guangzhou Pinwei Software Co Ltd
Priority date: 2023-12-22
Filing date: 2023-12-22
Publication date: 2024-03-22

Abstract

The application provides a demand test method, a device, a storage medium and computer equipment, wherein the method comprises the following steps: when a demand test instruction is received, the demand to be tested and the corresponding case information thereof are determined based on the demand test instruction, and then the latest case library is determined, wherein the types of the cases in the case library comprise document types and script types, namely the case library comprises manual cases and automatic cases, and a test case set is determined in the case library according to the case information so as to test each test stage of the demand to be tested. Therefore, when the to-be-tested requirement exists and not only needs manual use cases but also needs automatic use cases, different platforms do not need to be switched to finish the test of the to-be-tested requirement, and further the efficiency of the requirement test is improved.

Description

Demand testing method and device, storage medium and computer equipment

Technical Field

The present disclosure relates to the field of software testing technologies, and in particular, to a demand testing method, a device, a storage medium, and a computer device.

Background

In the process of software development, in order to ensure the quality and stability of software, sufficient testing work must be performed. The test case is one of the core contents of the test work, and the main purpose of the test case is to check whether the system meets the requirements of expected functions, performance, safety and the like. Test cases typically include information such as input data, expected output results, execution steps, etc., which may be used to guide a tester or an automated test tool through test operations.

In general, the manual use case and the automatic use case required by the requirement test are respectively stored on different platforms, so that when the same requirement is tested, if the requirement needs to be used for the manual use case and the automatic use case, the requirement needs to be executed on different platforms in the test process, and the efficiency of the requirement test is lower.

Disclosure of Invention

The present application aims to solve at least one of the above technical drawbacks, and particularly to a technical drawback of the prior art that when testing the same requirement, if the requirement needs to be used for a manual use case and an automatic use case, the requirement needs to be executed by different platforms during the testing process, resulting in lower efficiency of the requirement test.

In a first aspect, the present application provides a demand testing method, the method comprising:

responding to a demand test instruction, and determining a demand to be tested and corresponding use case information thereof according to the demand test instruction;

determining a use case library;

according to the case information, determining a test case set in the case library; the types of the use cases in the use case library comprise document types and script types;

and according to the test case set and the execution sequence of each test stage in the to-be-tested requirement, testing each test stage in the to-be-tested requirement in sequence so as to finish the test of the to-be-tested requirement.

In one embodiment, the method further comprises:

when a use case update instruction is received, acquiring an update type and update information in the use case update instruction; wherein the update type comprises adding, deleting and editing;

and updating the use case library according to the update type and the update information.

In one embodiment, the updating the use case library according to the update type and the update information includes:

if the update type is newly added, acquiring a target address, a use case name, a use case label and use case content in the update information;

creating a test case corresponding to the case name, the case label and the case content under a target address in the case library so as to finish updating the case library;

if the update type is deleted, acquiring a target address and a use case name in the update information;

deleting the test case corresponding to the case name under the target address in the case library so as to finish updating the case library;

if the update type is editing, acquiring a target address, a use case name and modification information in the update information;

and modifying the test case corresponding to the case name under the target address in the case library according to the modification information so as to complete updating of the case library.

In one embodiment, determining a test case set in the case library includes:

acquiring each use case identifier in the use case information;

searching a test case corresponding to each case identifier in the case information in the case library;

and generating a test case set according to the test cases corresponding to each case identifier in the case information in the case library.

In one embodiment, the sequentially testing each testing stage in the requirement to be tested includes:

determining a target test phase to be executed currently;

determining a target test case matched with the target test stage by the case label in the test case set;

and testing the target test stage according to each target test case, judging whether each test stage in the requirements to be tested is tested when the test of the target test stage is completed, and if not, determining the next target test stage to be executed.

In one embodiment, the testing the target test stage includes:

determining the use sequence of each target test case so as to determine the target cases in each target test case;

if the type of the target use case is the document type, the target use case is sent to a client;

when response information of the client is received, returning to the step of determining the target cases to continue execution until all the target test cases are used;

if the type of the target use case is script type, loading and executing the target use case, and returning to the step of determining the target use case to continue execution until all the target test use cases are used.

In one embodiment, the method further comprises:

when a use case rendering instruction is received, the use case structure data and all use cases in the use case library are sent to a client, so that the client carries out multi-mode display on the use case structure data and all use cases in the use case library; wherein the multi-modal presentation includes a brain map presentation and a tabular presentation.

In a second aspect, the present application provides a demand test apparatus, the apparatus comprising:

the instruction response module is used for responding to the demand test instruction and determining the demand to be tested and the corresponding application information according to the demand test instruction;

the use case library determining module is used for determining a use case library;

the case set determining module is used for determining a test case set in the case library according to the case information; the types of the use cases in the use case library comprise document types and script types;

and the demand test module is used for sequentially testing each test stage in the to-be-tested demand according to the test case set and the execution sequence of each test stage in the to-be-tested demand so as to complete the test of the to-be-tested demand.

In a third aspect, the present application provides a storage medium having stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the demand test method as described in any one of the embodiments above.

In a fourth aspect, the present application provides a computer device comprising: one or more processors, and memory;

the memory has stored therein computer readable instructions which, when executed by the one or more processors, perform the steps of the demand test method as described in any of the embodiments above.

From the above technical solutions, the embodiments of the present application have the following advantages:

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive faculty for a person skilled in the art.

FIG. 1 is a flow chart of a method for testing demand according to an embodiment of the present disclosure;

FIG. 2 is a flowchart illustrating steps for updating a use case library according to an embodiment of the present disclosure;

FIG. 3 is a schematic flowchart of determining a test case set in a case library according to an embodiment of the present application;

FIG. 4 is a schematic flow chart of testing each testing stage in the requirements to be tested in sequence according to the embodiment of the present application;

FIG. 5 is a schematic flow chart of testing a target test stage according to an embodiment of the present application;

FIG. 6 is a schematic structural diagram of a demand test device according to an embodiment of the present disclosure;

fig. 7 is an internal structure diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

In one embodiment, the present application provides a demand test method, and the following embodiment describes the application of the method to a server. It is to be understood that the method for performing the demand test may be a single server or may be a server cluster composed of a plurality of servers, which is not particularly limited in this application.

As shown in fig. 1, the present application provides a demand test method, which includes:

step S101: responding to the demand test instruction, and determining the demand to be tested and the corresponding use case information according to the demand test instruction.

Wherein the use case signal comprises at least one use case identifier.

In this step, when a certain requirement needs to be tested, a tester can input a requirement number and a use case identifier (use case information) for testing through the client, and the client generates a corresponding requirement test instruction according to the requirement number and the use case information and sends the requirement test instruction to the server. When the server receives the demand test instruction, acquiring a demand number and use case information in the demand test instruction, searching a demand corresponding to the demand number in a preset demand record table according to the demand number, and determining the demand as a demand to be tested.

Step S102: a use case library is determined.

The use case library is a database for storing manual use cases and automatic use cases, and comprises a plurality of use cases and use case identifications corresponding to each use case. It should be understood that a manual case refers to a test case written by a person according to software requirements and design, and generally includes information such as test input, expected output, test steps, and the like. The tester needs to manually execute the test cases and record the test results. The manual use case has the advantages of higher flexibility and maintainability, but the test efficiency and coverage are relatively lower. The automation case refers to a test case realized by programming automation, and a large number of renaturation tests can be rapidly executed. Automated test scripts may be implemented through the writing of a scripting language or the use of automated test tools.

In this step, the current latest use case library is determined as the use case library used in the current demand test. It can be understood that the manual use cases uploaded by the testers or the manual use cases stored during testing can be stored in the use case library, and meanwhile, the automatic use cases written by the testers or the automatic use cases stored during testing can also be stored in the use case library, and unique identifiers are allocated to each use case stored in the use case library.

Step S103: and according to the case information, determining a test case set in a case library.

The types of the use cases in the use case library comprise document types and script types. It will be appreciated that when the type of use case is a document type, then the use case is indicated as an artificial use case. When the type of the use case is script type, the use case is indicated as automation use case.

In this step, a set of test cases required for testing the requirement to be tested is determined in the determined case library based on the obtained case information.

Step S104: and testing each testing stage in the requirements to be tested in sequence according to the test case set and the execution sequence of each testing stage in the requirements to be tested so as to finish the testing of the requirements to be tested.

It will be appreciated that the order of execution of the various test phases in the demand under test is determined based on the execution logic of the demand under test. The requirement to be tested at least comprises a testing stage, and the testing stage at least needs one testing case.

Specifically, based on the execution sequence of each test stage in the requirements to be tested, each test stage in the requirements to be tested is tested by using the test case set in turn, and when the test of the last test stage in the requirements to be tested is completed, the test of the requirements to be tested is indicated to be completed.

As shown in fig. 2, in one embodiment, the demand test method further includes:

step S201: when the use case update instruction is received, the update type and the update information in the use case update instruction are obtained.

Wherein, the update type comprises adding, deleting and editing. It will be appreciated that when the update types are different, the information types contained in the update information are also different.

In this step, when the tester needs to add a use case, delete a use case, or edit a use case, the update type may be selected at the client and update information corresponding to the selected update type may be input or uploaded. The client generates a use case update instruction according to the use case update instruction, and sends the use case update instruction to the server. When the server receives the use case update instruction, the update type and the corresponding update information in the use case update instruction are obtained.

Specifically, the manner in which the tester inputs or selects information at the client includes brain pattern and form pattern.

Step S202: and updating the use case library according to the update type and the update information.

In the step, according to the acquired update type and update information, updating the use case library in match with the update type.

It can be understood that the use case library is updated, the same database is used for storing both the manual use case and the automatic use case, and when the to-be-tested requirement exists, the manual use case and the automatic use case are required, different platforms are not required to be switched to complete the test of the to-be-tested requirement, so that the efficiency of the requirement test is improved.

In one embodiment, updating the use case library according to the update type and the update information includes:

creating a test case corresponding to the case name, the case label and the case content under the target address in the case library so as to finish updating the case library;

if the update type is deletion, acquiring a target address and a use case name in the update information;

deleting the test case corresponding to the case name under the target address in the case library to finish updating the case library;

and modifying the test case corresponding to the case name under the target address in the case library according to the modification information so as to complete the updating of the case library.

The target address refers to a path of a use case to be updated or added. The use case content refers to a use case document or a use case script.

In this embodiment, since the update types are different, the corresponding update information is also different, data in the update information is acquired according to the update type, and based on the acquired data, an update operation corresponding to the update type is performed on the use case library.

As shown in FIG. 3, in one embodiment, determining a test case set in a case library includes:

step S301: and obtaining the respective case identifications in the case information.

Step S302: and searching the test case corresponding to each case identifier in the case information in the case library.

Step S303: and generating a test case set according to the test cases corresponding to each case identifier in the case information in the case library.

In this embodiment, each case identifier in the case information is obtained, and the obtained case identifier is used to match with a test case in the case library, so that a set of successfully matched test cases is determined as a set of test cases. It can be appreciated that since the manual use cases and the automated use cases in the use case library share a set of identification rules, there is no duplication of identification of the manual use cases and the automated use cases in the use case library. At this time, at least one of a manual case and an automated case exists in the obtained test case set.

As shown in fig. 4, in one embodiment, testing each test stage in the requirements to be tested sequentially includes:

step S401: a target test phase to be currently performed is determined.

And determining the current test stage to be executed as a target test stage according to the execution sequence of each test stage in the requirement to be tested.

Step S402: and determining the target test cases of which the case labels are matched with the target test stages in the test case set.

It will be appreciated that each use case in the use case library includes a use case tag to indicate the stage of use of that use case in the tested requirements. In the step, a target test case corresponding to a target test stage is determined in the test case set through the case label.

Step S403: and testing the target testing stage according to each target testing case.

In this step, the target test stage is tested according to each target test case corresponding to the target test stage.

Step S404: when the test on the target test stage is completed, judging whether each test stage in the requirements to be tested is completed or not.

Step S405: if there is a test stage in the need to be tested that has not completed the test, then the next target test stage to be executed is determined.

It can be understood that when there are test phases of the incomplete test in the requirement to be tested, the target test phase to be executed currently is redetermined according to the execution sequence of each test phase in the requirement to be tested.

Step S406: if all the testing stages in the to-be-tested requirement are tested, testing of all the testing stages in the to-be-tested requirement is completed.

For example, assume that the requirement a to be tested has a test stage a and a test stage b, and the execution sequence is the test stage a and the test stage b. Based on the above, determining that the target test stage to be executed is the test stage a, determining the target test case d corresponding to the test stage a in the test case set, testing the test stage a based on the target test case d, judging whether each test stage in the test requirement a is tested when the test of the test stage a is completed, and determining that the test stage b is not tested at this time, so that the next target test stage to be executed is redetermined, determining the target test case e corresponding to the test stage b in the test case set, testing the test stage b based on the target test case e, judging whether each test stage in the test requirement a is tested when the test of the test stage b is completed, and determining that the test of each test stage in the test requirement a is completed when the test of the test stage b is completed.

It can be understood that in the process of testing the requirement to be tested, when the requirement to be tested needs not only the manual case but also the automatic case, the requirement to be tested can be uniformly obtained from the case library, and the test of the requirement to be tested is completed based on the obtained test case set. Therefore, when the to-be-tested requirement exists and not only needs manual use cases but also needs automatic use cases, different platforms do not need to be switched to finish the test of the to-be-tested requirement, and further the efficiency of the requirement test is improved.

As shown in fig. 5, in one embodiment, testing the target test phase includes:

step S501: the use sequence of each target test case is determined so as to determine the target cases in each target test case.

In this step, the basis for determining the use sequence of each target test case is the execution sequence of each interface in the target test stage, and when determining the use sequence of each target test case, the target case to be used currently is determined in each target test case.

Step S502: and judging the type of the target use case.

It will be appreciated that since the methods used by the manual use case and the automated use case are different, a determination of the type of the target use case is required.

Step S503: and if the type of the target use case is the document type, sending the target use case to the client.

Step S504: and when the response information of the client is received, returning to the step of determining the target use cases to continue execution until all the target test cases are used.

When the type of the target use case is the document type, the target use case is explained to be the artificial use case, and the target use case is sent to the client, so that a tester can perform test operation according to the target use case received by the client. After the tester completes the operation contained in the target use case, the client returns response information for representing the completion of the test to the server. When the server receives the response information sent by the client, the next target use case to be used can be redetermined, and the method is performed until each target test case is used.

Step S505: if the type of the target use case is script type, loading and executing the target use case, and returning to the step of determining the target use case to continue execution until all the target test use cases are used.

When the type of the target use case is the script type, the target use case is described as an automation use case, namely, the target use case is loaded and executed, namely, a script file corresponding to the target use case is loaded and executed, then the next target use case to be used is redetermined, the type of the redetermined target use case is judged, and the like until each target test use case is used.

In one embodiment, the demand test method further comprises:

when a use case rendering instruction is received, the use case structure data and all use cases in the use case library are sent to the client, so that the client carries out multi-mode display on the use case structure data and all use cases in the use case library; wherein the multi-modal presentation includes a brain map presentation and a tabular presentation.

It can be understood that when a tester wants to know the full view of all test cases, a case rendering instruction can be initiated, so that when the server receives the case rendering instruction, data in the case library is returned to the client, and the client performs multi-mode display on the data responded by the server. Therefore, the tester can flexibly switch different use case display forms, and can intuitively and visually know all the test cases. Thereby improving the efficiency of the test work.

In one embodiment, after each test stage in the demand under test has completed testing, the demand testing method further comprises:

synchronizing the execution state of each test case in the test case set to the client so that the client can visually display the execution state of each test case; the execution state comprises execution success, execution failure, execution blocking, execution neutralization and execution waiting.

In this embodiment, the execution state of each test case in the test case set is synchronized in real time, so that the client can perform real-time visual display on the execution state of each test case. Therefore, a tester can know the execution state of each test case in real time in the process of testing the requirement to be tested, and the intelligent level of the requirement testing method is improved.

It can be understood that the information of the total execution number, the executed number, the unexecuted number, the successful execution number, the execution failure number and the like of each test case in the test case set can be counted and sent to the client for visual display. And when the execution failure or the execution blockage occurs, a corresponding alarm instruction can be generated according to the case identification of the test case of the execution failure or the execution blockage, and the alarm instruction is sent to the client so as to prompt the test personnel.

In one embodiment, the review records of the use cases in the use case library are collected, and when a review instruction is received, the review records of the use cases in the use case library are sent to the client. To support the tester to view the review content of the use case.

It should be understood that, although the steps in the flowcharts related to the embodiments described above are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.

The following describes a demand testing device provided in the embodiments of the present application, and the demand testing device described below and the demand testing method described above may be referred to correspondingly.

As shown in fig. 6, the present application provides a demand test apparatus 600, the apparatus comprising:

the instruction response module 601 is configured to respond to a demand test instruction, and determine a demand to be tested and corresponding application information thereof according to the demand test instruction;

a use case library determining module 602, configured to determine a use case library;

the case set determining module 603 is configured to determine a test case set in a case library according to the case information; the types of the use cases in the use case library comprise document types and script types;

the requirement testing module 604 is configured to test each testing stage in the requirement to be tested in sequence according to the test case set and the execution sequence of each testing stage in the requirement to be tested, so as to complete the testing of the requirement to be tested.

In one embodiment, the demand test apparatus further includes:

the instruction receiving module is used for acquiring the update type and the update information in the use case update instruction when the use case update instruction is received; wherein, the update type comprises adding, deleting and editing;

and the use case library updating module is used for updating the use case library according to the updating type and the updating information.

In one embodiment, the use case library update module further includes:

the first judging sub-module is used for acquiring a target address, a use case name, a use case label and use case contents in the update information if the update type is newly added;

the first updating sub-module is used for creating a test case corresponding to the case name, the case label and the case content under the target address in the case library so as to complete updating of the case library;

the second judging sub-module is used for acquiring a target address and a use case name in the update information if the update type is deleted;

the second updating sub-module is used for deleting the test case corresponding to the case name under the target address in the case library so as to complete updating of the case library;

the third judging sub-module is used for acquiring a target address, a use case name and modification information in the update information if the update type is editing;

and the third updating sub-module is used for modifying the test case corresponding to the case name under the target address in the case library according to the modification information so as to complete the updating of the case library.

In one embodiment, the use case set determining module includes:

the mark acquisition sub-module is used for acquiring each use case mark in the use case information;

the test case searching sub-module is used for searching the test cases corresponding to each case identifier in the case information in the case library;

and the test case set generation sub-module is used for generating a test case set according to the test cases corresponding to each case identifier in the case information in the case library.

In one embodiment, the demand test module includes:

a test phase determination sub-module for determining a target test phase to be currently executed;

the label matching sub-module is used for determining a target test case matched with the case label and the target test stage in the test case set;

and the stage test sub-module is used for testing the target test stage according to each target test case, judging whether each test stage in the requirements to be tested is tested, and if not, determining the next target test stage to be executed.

In one embodiment, the phase test sub-module includes:

the target case determining unit is used for determining the use sequence of each target test case so as to determine the target case in each target test case;

the first judging unit is used for sending the target use case to the client if the type of the target use case is the document type;

the response information receiving unit is used for returning to the step of determining the target use cases to continue execution until all the target test use cases are used when receiving the response information of the client;

and the second judging unit is used for loading and executing the target use cases if the type of the target use cases is script type, and returning to the step of determining the target use cases to continue execution until all the target test use cases are used.

In one embodiment, the demand test apparatus further includes:

the multi-mode display module is used for sending the case structure data and all cases in the case library to the client when receiving the case rendering instruction, so that the client carries out multi-mode display on the case structure data and all cases in the case library; wherein the multi-modal presentation includes a brain map presentation and a tabular presentation.

The above-described division of the modules in the demand test apparatus is merely for illustration, and in other embodiments, the demand test apparatus may be divided into different modules as needed to perform all or part of the functions of the demand test apparatus. The various modules in the demand test apparatus described above may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, the present application also provides a storage medium having stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the demand test method as set forth in any one of the above embodiments.

In one embodiment, the present application also provides a computer device having stored therein computer readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the demand test method as set forth in any one of the above embodiments.

Schematically, as shown in fig. 7, fig. 7 is a schematic internal structure of a computer device according to an embodiment of the present application, and the computer device 700 may be provided as a server. Referring to FIG. 7, a computer device 700 includes a processing component 702 that further includes one or more processors and memory resources represented by memory 701 for storing instructions, such as applications, executable by the processing component 702. The application program stored in the memory 701 may include one or more modules each corresponding to a set of instructions. Further, the processing component 702 is configured to execute instructions to perform the need testing method of any of the embodiments described above.

The computer device 700 may also include a power supply component 703 configured to perform power management of the computer device 700, a wired or wireless network interface 704 configured to connect the computer device 700 to a network, and an input output (I/O) interface 705. The computer device 700 may operate based on an operating system stored in memory 701, such as Windows Server TM, mac OS XTM, unix TM, linux TM, free BSDTM, or the like.

It will be appreciated by those skilled in the art that the structure shown in fig. 7 is merely a block diagram of some of the structures associated with the present application and is not limiting of the computer device to which the present application may be applied, and that a particular computer device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.

Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises/comprising," "includes," and/or "having," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, components, or groups thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, and include any and all combinations of the listed items.

In the present specification, each embodiment is described in a progressive manner, and each embodiment focuses on the difference from other embodiments, and may be combined according to needs, and the same similar parts may be referred to each other.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of demand testing, the method comprising:

determining a use case library;

2. The demand test method according to claim 1, further comprising:

3. The demand test method according to claim 2, wherein updating the use case library according to the update type and the update information comprises:

4. The demand test method of claim 1, wherein determining a test case set in the case library comprises:

acquiring each use case identifier in the use case information;

5. The demand test method according to any one of claims 1 to 4, wherein the sequentially testing each test stage in the demand to be tested includes:

determining a target test phase to be executed currently;

6. The demand test method of claim 5, wherein the testing the target test phase comprises:

7. The demand test method according to claim 1, further comprising:

8. A demand testing apparatus, the apparatus comprising:

9. A storage medium, characterized by: the storage medium having stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the demand test method of any of claims 1 to 7.

10. A computer device, comprising: one or more processors, and memory;

stored in the memory are computer readable instructions which, when executed by the one or more processors, perform the steps of the demand test method of any one of claims 1 to 7.