CN114385475A

CN114385475A - Test method and related device

Info

Publication number: CN114385475A
Application number: CN202011109103.3A
Authority: CN
Inventors: 余自强
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-10-16
Filing date: 2020-10-16
Publication date: 2022-04-22

Abstract

The embodiment of the application discloses a testing method and a related device, when testing software to be tested, the software to be tested is not tested according to interfaces required by the software to be tested one by one, but is tested according to service functions of the software to be tested one by one, and even tests of a plurality of service functions can be processed in batches. When the target service function is tested, a plurality of states related to the target service function of the software to be tested are obtained, and a state jump path of the software to be tested for realizing the target service function can be determined according to the state jump sequence of the states. Interface test cases required for realizing adjacent state jumping on the state jumping path are added into the case set, the interface test cases are called from the corresponding case set in sequence according to the jumping sequence of the state jumping path during testing, the output of the previous interface test case is the input of the next interface test case, the realization process of the target service function is simulated, the testing process is simplified, and the testing efficiency is improved.

Description

Test method and related device

Technical Field

The present application relates to the field of data processing, and in particular, to a test method and related apparatus.

Background

Currently, a mode of separating a front end from a back end is generally adopted when software is developed. And after the back-end developer completes the development of the system interface, the back-end developer sends the system interface to the front-end tester. And the front-end tester performs interface test to verify the correctness and the usability of the interface.

The interface test is to verify whether the data exchange of the interface between the system components from one state to another state is correct by using an interface test case, and when the actual output data is consistent with the expected output data, the interface passes the test. When testing software to be tested, a plurality of interfaces are called, front-end testers need to create different interface test cases one by one according to required interfaces for testing, input data of each interface test case are simulated, and the like, so that the testing process is complicated, and the testing efficiency is low.

Disclosure of Invention

In order to solve the technical problem, the application provides a data testing method and a related device, which are used for simplifying a testing process and improving testing efficiency.

The embodiment of the application discloses the following technical scheme:

in one aspect, the present application provides a testing method, the method comprising:

aiming at a target business function of software to be tested, acquiring a plurality of states related to the target business function of the software to be tested;

determining a state jump path of the software to be tested for realizing the target service function according to the plurality of states;

determining an interface test case for realizing adjacent state hopping in the state hopping path, and adding the interface test case into a case set for realizing the target service function;

and calling interface test cases from the case set in sequence according to the jump sequence of the state jump path, and carrying out interface test on the target service function of the software to be tested.

In another aspect, the present application provides a test apparatus, the apparatus comprising: the system comprises an acquisition unit, a first processing unit, a second processing unit and a calling unit;

the acquiring unit is used for acquiring a plurality of states related to the target business function of the software to be tested aiming at the target business function of the software to be tested;

the first processing unit is used for determining a state jump path of the software to be tested for realizing the target service function according to the plurality of states;

the second processing unit is configured to determine an interface test case for implementing adjacent state hopping in the state hopping path, and add the interface test case to a case set for implementing the target service function;

the calling unit is used for calling interface test cases from the case set in sequence according to the jump sequence of the state jump path and carrying out interface test of the target service function on the software to be tested.

In another aspect, an embodiment of the present application provides an apparatus for testing, where the apparatus includes a processor and a memory:

the memory is used for storing program codes and transmitting the program codes to the processor;

the processor is configured to perform the method of the above aspect according to instructions in the program code.

In another aspect, the present application provides a computer-readable storage medium for storing a computer program for executing the method of the above aspect.

In another aspect, embodiments of the present application provide a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method of the above aspect.

According to the technical scheme, when the software to be tested is tested, the software to be tested is not tested one by one according to the interfaces required by the software to be tested, but is tested one by one according to the service functions of the software to be tested. The method comprises the steps of firstly obtaining a plurality of states related to the target service function of the software to be tested, and determining a state jump path of the software to be tested for realizing the target service function according to the state jump sequence of the states. If the software to be tested has a plurality of service functions, each service function has a corresponding state jump path, and interface test cases required for realizing adjacent state jumps on the same state jump path are added into the same case set. When the interface test of the target service function is carried out on the software to be tested, according to the jump sequence of the state jump path corresponding to the realization of the target service function, the interface test cases are called from the case set corresponding to the state jump path in sequence, the output of the previous interface test case is the input of the next interface test case, so that the realization process of the target service function is simulated, front-end testers do not need to simulate the input data of each interface test case one by one, the test process is simplified, and the test efficiency is improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic view of an application scenario of a testing method according to an embodiment of the present application;

fig. 2 is a flowchart of a testing method provided in an embodiment of the present application;

fig. 3 is a schematic diagram of a state jump path according to an embodiment of the present application;

fig. 4 is a schematic diagram of a use case set according to an embodiment of the present application;

FIG. 5 is a schematic diagram of configuration interface test case input data according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of a state machine provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of a multi-test provided by an embodiment of the present application;

fig. 8 is a schematic diagram of a state jump path according to an embodiment of the present application;

fig. 9 is a flowchart of a method for determining a state jump path according to an embodiment of the present application;

FIG. 10 is a schematic illustration of a test result provided by an embodiment of the present application;

FIG. 11 is a schematic diagram of a testing apparatus according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a server according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application are described below with reference to the accompanying drawings.

Each interface will have different test results due to the difference of the previous state. In order to ensure that each interface can be successfully called in different states, a front-end tester writes various different input data and expected output data when testing the interface so as to test the calling condition of the interface in different states. When the software to be tested is tested, the software to be tested has multiple functions, at least one interface is required to be called for realizing each function, and each interface simulates different states according to different input data required by different states. Therefore, when the test of the software to be tested is completed, a front-end tester needs to fill in a large amount of input data, so that the test process is complicated, and the test efficiency is low.

In order to simplify the testing process and improve the testing efficiency, the application provides a testing method and a related device.

The testing method provided by the embodiment of the application can be applied to processing equipment with testing capability, for example, terminal equipment or a server with testing function. The method can be independently executed through the terminal equipment or the server, can also be applied to a network scene of communication between the terminal equipment and the server, and is executed through the cooperation of the terminal equipment and the server. The terminal device may be a smart phone, a notebook computer, a desktop computer, a Personal Digital Assistant (PDA for short), a tablet computer, or the like. The server may be understood as an application server, or may also be a Web server, and in actual deployment, the server may be an independent physical server, or a server cluster or distributed system formed by a plurality of physical servers, or a cloud server providing cloud computing services. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

In addition, the technical scheme provided by the application also relates to the technical field of cloud, such as the field of cloud computing and the like.

Cloud computing (cloud computing) refers to a delivery and use mode of an IT infrastructure, and refers to obtaining required resources in an on-demand and easily-extensible manner through a network; the generalized cloud computing refers to a delivery and use mode of a service, and refers to obtaining a required service in an on-demand and easily-extensible manner through a network. Such services may be IT and software, internet related, or other services. Cloud Computing is a product of development and fusion of traditional computers and Network Technologies, such as Grid Computing (Grid Computing), distributed Computing (distributed Computing), Parallel Computing (Parallel Computing), Utility Computing (Utility Computing), Network Storage (Network Storage Technologies), Virtualization (Virtualization), Load balancing (Load Balance), and the like.

With the development of diversification of internet, real-time data stream and connecting equipment and the promotion of demands of search service, social network, mobile commerce, open collaboration and the like, cloud computing is rapidly developed. Different from the prior parallel distributed computing, the generation of cloud computing can promote the revolutionary change of the whole internet mode and the enterprise management mode in concept.

In the embodiment of the application, the interface test of the target service function of the to-be-tested soft is realized through the cloud computing technology.

In order to facilitate understanding of the technical solution of the present application, the following describes a test method provided in the embodiment of the present application with reference to an actual application scenario.

Referring to fig. 1, the figure is a schematic view of an application scenario of a testing method provided in the embodiment of the present application. As shown in fig. 1, the terminal device 100 and the server 200 are included, where the terminal device 100 has software to be tested, and the server 200 tests the software to be tested APP in the terminal device 100. The APP has n service functions, and a description will be given below with one of the service functions "doing tasks" as a target service function.

The server 200 obtains three states related to the realization of the task-making business function by the APP, which are respectively: and the task state is not obtained, the task is not submitted, and the task state is completed. When a user does a task, firstly, the task is not picked up, and the task is picked up and then becomes a picked-up task but is not submitted; and the state of the picked task and the uncommitted task becomes a finished state after the task is picked and submitted according to the task condition. The three states can form a state jump path for realizing the task-making business function of the software to be tested: uncollected → picked, uncommitted → completed tasks.

The jumping between different states requires different interface test cases, for example, interface test case x is needed from a task-not-taken state to a task-taken state and a task-not-submitted state, and interface test case y is needed from a task-taken state, a task-not-submitted state to a task-completed state. The server 200 may determine the interface test cases x and y required for implementing the jump path corresponding to the "do task" service function, and add the interface test case x and the interface test case y to the case set 201 for implementing the "do task" service function.

When the server 200 performs the interface test of the task service function test on the APP, the jump sequence of the state jump path for realizing the task service function can be as follows: the task of not picking up → picking up task, task of not submitting → task of completing, take out the interface test case x that the first state transform needs from the set of cases 201 to test at first, take out the interface test case y that the second state transform needs from the set of cases 201 to test again.

When testing software to be tested, the testing is not carried out according to interfaces required by the software to be tested one by one, but is carried out according to business functions of the software to be tested one by one, each business function has a corresponding state jump path, and interface test cases required by realizing adjacent state jumps on the same state jump path are added into the same case set. When interface test is carried out on a certain service function, interface test cases are called from a corresponding case set in sequence according to the jump sequence of a state jump path corresponding to the service function, so that the output of the previous interface test case is the input of the next interface test case, the realization process of the target service function is simulated, front-end testers do not need to simulate the input data of each interface test case one by one, the test process is simplified, and the test efficiency is improved.

The following describes a test method provided by the embodiment of the present application with reference to an application scenario shown in fig. 1. Referring to fig. 2, the figure is a flowchart of a testing method provided in the embodiment of the present application. In the method shown in fig. 2, the following steps are included:

s201: aiming at a target business function of software to be tested, acquiring a plurality of states related to the target business function realized by the software to be tested.

When the software to be tested is tested according to the interfaces, each interface has different test results due to the difference of the previous state. For example, the background for implementing the data synchronization service function of the client calls three interfaces, which are respectively: logging in to obtain a user ID interface, reporting a local data interface and reporting a local conflict interface. The data synchronization process comprises the following steps: the client sends the Identity (ID) of the user and the user login information to the background; the background returns the user ID and the user login information; the client reports the local data to the background; generating an increment diff and a newly added version number by the background, and returning the increment data and the version number; the client reports the local conflict to the background; and after the background finishes processing the conflict, returning synchronization finishing information to the client. The user ID interface is required to be called and logged in not only in the data synchronization process, but also in the information sending process. In order to enable the interface to pass the test under any condition, the interface needs to be called under any condition according to the consideration of front-end testers, test cases are created, and input data are filled one by one, so that the test process is complicated, and the test efficiency is low.

In order to simplify the testing process and improve the testing efficiency, the testing is not performed one by one according to the interfaces, but performed one by one according to the service functions. A business function is performed by a series of actions according to a designated sequence, and the software to be tested is converted from one state to another state by calling an interface according to the action sequence and executing the corresponding action. Therefore, the implementation process of the corresponding service function can be determined according to the state conversion.

One software to be tested generally has a plurality of business functions, and when the software to be tested is subjected to function testing one by one according to the business functions, taking the target business function as an example, a plurality of states related to the realization of the target business function by the software to be tested are obtained.

S202: and determining a state jump path of the software to be tested for realizing the target service function according to the plurality of states.

The process of realizing the business function by the software to be tested is a process of changing one state into another state, and the continuous transformation of a plurality of states can be represented as a bar-shaped jump path to represent the realization process of the corresponding target business function.

Referring to fig. 3, the figure is a schematic diagram of a state jump path according to an embodiment of the present application. Fig. 3 shows a state jump path corresponding to an advertisement on-line service function, where the advertisement on-line service function relates to six states, which are respectively: initialization, Audit Plan to be Configured (CAP), content main order taking, payment waiting, online waiting and finished.

Aiming at the advertisement on-line service function, after entering the software to be tested, the software enters an initialization state; after the order is submitted, the initialization state is changed into a state to be checked by CAP; after the platform confirms the order, the state of waiting CAP examination is changed into the state of waiting for the content owner to receive the order; after the content owner receives the order, the state of the content owner receiving the order is changed into a state to be paid; after the payment is finished, the state of the payment to be made is changed into the state of going on line; after the content is on line, the on-line state is changed into a finished state. Therefore, the six states can determine a state jump path for realizing the online service function of the advertisement.

S203: and determining an interface test case for realizing adjacent state hopping in the state hopping path, and adding the interface test case into a case set for realizing the target service function.

Whether the state is changed into another state from one state is expected or not can be verified through the interface test case, namely, a jump process between adjacent states corresponds to one interface test case. The interface test cases required on the state jump path for realizing the target service function are added into the same case set, so that the interface test cases are called from the case set corresponding to the target service test function when the target service function is tested subsequently, and the test efficiency is improved.

Referring to fig. 4, the figure is a schematic diagram of a use case set provided in the embodiment of the present application. Each state path corresponds to a use case set for realizing the service function. A large set of use cases can be managed through interface testing tools, such as postman, meter, poster, etc., as shown in FIG. 4 for managing the set of use cases for the corresponding state path of FIG. 3 through postman: and after initialization is completed, five interfaces are called in the case set to realize the online service function of the advertisement.

In order to enable postman to manage the use case set, the interface test use case can adopt a json format, the name of the state transformation is used as the name of the interface test use case, and the starting state and the ending state on the state jump path are used as the names of the use case set. Whether the interface test case name or the case set name can be changed into other names through modification.

The interface test case can take the previous state as input data and the expected result of the next state as expected output data, and the process executed by the jump relation from the previous state to the next state can be represented by a test function, so that when the actual output data of the interface test case is consistent with the expected output data, the adjacent state jumps to pass the test, and the interface called in the interface test case also passes the test; when the actual output data of the interface test case is not in accordance with the expected output data, the adjacent state jump fails to pass the test, and the interface called in the adjacent state jump also fails to pass the test.

S204: and calling interface test cases from the case set in sequence according to the jump sequence of the state jump path, and carrying out interface test on the target service function of the software to be tested.

When the interface test of the target service function is carried out on the software to be tested, interface test cases can be sequentially called from the case set corresponding to the state jump path according to the jump sequence of the state jump path. According to the jump sequence of the state jump path, the interface test cases in the use case set have corresponding sequences, the output of the previous interface test case can be used as the input of the next interface test case, and the realization process of the target function of the software to be tested is simulated.

Even if a plurality of interface test cases are called in the target service function, the front-end tester does not need to fill input data into the test cases one by one, but only fills the input data into the first interface test case in the case set. Referring to fig. 5, this figure is a schematic diagram of a configuration interface test case input parameter provided in the embodiment of the present application. The interface of the input data required to be filled in of the initialized-completed interface test case not only can be written with the required input parameters, but also can be configured with different test environments. The subsequent interface test cases can be called according to the jump sequence of the state jump path, the output of the previous interface test case is used as the input of the next interface test case, and the test of the target function of the software to be tested is automatically completed through the state conversion process of testing a service function through the continuity of the interface test cases, so that the test process is simplified, and the test efficiency is improved.

The test principle of the interface test case is very similar to the structure of a finite state machine (hereinafter referred to as a state machine), and the constituent elements of the state machine are input, output and state, and describe the state sequence of an object in a life cycle and how to respond to various events from the outside. Therefore, the corresponding interface test case can be generated through the state machine configuration file. The state machine configuration file comprises a present state, a next state, a condition and an attribute. The current state is a first state in the jumping direction of the adjacent state, and the secondary state is a second state in the jumping direction of the adjacent state, namely the current state can be changed into the secondary state after the condition is met. The condition includes not only input data but also execution logic that changes from the present state to the next state, i.e., a function under test. The attributes include desired output data.

Referring to fig. 6, a schematic diagram of a state machine provided in an embodiment of the present application is shown. In the figure, the present state is a to-be-paid state, and the next state is a to-be-on-line state, provided that whether the balance is sufficient is checked, that is, when the balance is sufficient, the to-be-paid state may become the to-be-on-line state. The state machine configuration files corresponding to this figure are as follows:

the input data in the state machine configuration file corresponds to the input data of the interface test case, the tested function of the state machine configuration file corresponds to the test function of the interface test case, and the expected output data in the state machine configuration file corresponds to the expected output data of the interface test case, so that the state machine configuration file can determine the corresponding interface test case.

When the more the interfaces are called in different business functions, the more the changed states are, and the test conditions of the interfaces are easy to be missed when the test cases are created one by one, so that the test on the interfaces is incomplete, and the test on the software to be tested is incomplete. With the increase of service functions of software to be tested, such as order state circulation software, financial approval software and the like, the test mode of interface-by-interface is easier to omit, the state machine configuration file can simplify the complex logic into a limited stable state, can simplify the complex interface calling process into a state conversion process, can cover all conditions by defining the state change, and improves the coverage rate of the test conditions.

Meanwhile, a back-end developer usually develops the software by using a state machine configuration file, so that when the interface test is carried out, the state machine configuration file which is defined by the back-end developer can be directly used, the state machine configuration file which is required in a state jump path corresponding to the target service function of the software to be tested is read, and a corresponding interface test case is generated according to the state machine configuration file, so that the workload of a front-end tester is reduced, and the convenience of the test work is improved.

The attribute of the state machine configuration file can also be provided with an interface address which is used for identifying the address of an interface test case request generated according to the state machine configuration file, so that an interface is automatically bound through the interface address, a corresponding test case is automatically operated, and the test efficiency of the software to be tested is improved.

The input data in the condition of the state machine configuration file is an interface parameter, and the interface parameter can be modified, so that the corresponding interface is tested for multiple times through the modified interface parameter. The state machine configuration file has a modifiable data structure, and the interface test case generated by using the modified state machine configuration file can be tested for the corresponding interface, so that when the interface is subjected to targeted test, the service function of the interface does not need to be comprehensively tested, and the test pertinence is improved. When a specific test is performed on an interface, the same interface may also be tested multiple times by using an interface test case, see fig. 7, which is a schematic diagram of multiple tests provided in the embodiment of the present application. In the figure, an interface test case is adopted to carry out two tests on the initialized-to-be-CAP auditing interface, and each test can obtain a corresponding test result according to different test aspects.

When the target service function is realized, the states related to the target service function are many, the conversion among the states is very complex, all the states related to the target service function can be traversed through a traversal method, and the state jump path of the software to be tested for realizing the target service function is determined, so that the accuracy of obtaining the state jump path is improved. The traversal method is not specifically limited in the embodiments of the present application, and for example, a depth-first traversal method may be adopted, and a breadth-first traversal method may also be adopted.

The process of realizing the target service function by the software to be tested may be complex, for example, two adjacent states are continuously transformed with each other, so that the state jump path is difficult to be determined, and the testing efficiency is reduced. Referring to fig. 8, the figure is a schematic diagram of a state jump path according to an embodiment of the present application. Because the submitted order may not conform to the CAP audit, the order is rejected, the state of the CAP audit waiting is changed into the state of the modification waiting to be rejected, the order is submitted again after the modification is finished, the state of the modification waiting to be rejected is changed into the state of waiting for the CAP audit, the above processes are repeated continuously until the CAP audit is passed, and the state of the CAP audit waiting is changed into the state of receiving the order of the content owner after the platform determines the order.

In order to improve the test efficiency, a method for determining a state jump path is described below. Referring to fig. 9, this figure is a flowchart of a method for determining a state jump path according to an embodiment of the present application. The method comprises the following steps:

s901: and starting from the condition that i is 1, acquiring a secondary state corresponding to the ith current state.

S902: and traversing each secondary state in turn in the secondary state corresponding to the ith current state.

S903: judging whether the state jump path of each secondary state and the ith current state is repeated with a historical path, if so, executing S704; if not, go to S705.

S904: if yes, deleting the repeated state jump path.

S905: if not, taking the secondary state corresponding to the unrepeated state jump path as the (i + 1) th current state.

S906: and continuing to search the secondary state corresponding to the (i + 1) th current state until the plurality of states related to the target service function are searched.

The front-end tester can test the service function corresponding to a certain case set through the case set, and can test all the case sets at one time. Generally, one piece of software to be tested has a plurality of service functions, and in order to further improve the testing efficiency, the plurality of service functions can be tested in batches. Specifically, the software to be tested is obtained in batch to realize a plurality of use case sets corresponding to a plurality of service functions, for example, the interface test tool is used to obtain the plurality of use case sets in batch, and a large number of interface test use cases can also be managed and run through the test tool. The interface test of a plurality of business functions is carried out on the software to be tested, so that under a complex scene, such as order state circulation, financial examination and approval and the like, a front-end tester does not need to simulate different state transformation processes one by one according to the use flow of the software to be tested, the business function test of the software to be tested is rapidly completed through batch operation of a case set, and the test efficiency is improved.

Next, a test method provided in the embodiment of the present application will be described with reference to a specific scenario, where the advertisement on-line service function is used as a target service function to perform a test.

Referring to fig. 8, seven states related to the implementation of the advertisement on-line service function by the software to be tested are obtained: initializing, checking to CAP, refuting and modifying, receiving a bill by a content owner, paying, uploading and finishing, determining a state jump path corresponding to the function of realizing the advertisement online service by adopting a depth-first traversal method, and obtaining the state jump path after deleting the repeated state jump path: initialization → pending CAP review → pending refute modification → pending content master order → pending payment → pending online → completed. And reading the state machine configuration files required by the adjacent states in the state jump path, generating corresponding interface test cases according to the state machine configuration files, and adding the interface test cases required in the state jump path into a case set for realizing the online service function of the advertisement. When the interface test of the advertisement on-line service function is carried out on the software to be tested, according to the skipping sequence of the skipping path for realizing the advertisement on-line service function: initialization → pending CAP examination → pending rejectional modification → pending content master order → pending payment → pending online → completed, and calling interface test cases from the set of cases in turn.

Furthermore, a plurality of case sets corresponding to a plurality of business functions realized by the software to be tested can be obtained, and the software to be tested is subjected to interface test of the plurality of business functions, wherein the software to be tested has 7 case sets. Referring to fig. 10, a schematic diagram of a test effect provided by the embodiment of the present application is shown. After 7 case sets are obtained, 7 case sets are run in batch by adopting the test method, 6 test case sets can be obtained to pass the test, 1 case set does not pass the test, and the case set which does not pass the test is the case set 6. Therefore, the front-end tester can correspond to the corresponding service function according to the case set 6 which does not pass the test, and can quickly find the interface which cannot pass the test.

Based on the testing method provided by the foregoing embodiment, a related apparatus provided by the embodiment of the present application is introduced.

The present embodiment provides a testing apparatus 1100, and referring to fig. 11, the apparatus 1100 includes an obtaining unit 1101, a first processing unit 1102, a second processing unit 1103, and a calling unit 1104:

the obtaining unit 1101 is configured to, for a target service function of software to be tested, obtain a plurality of states related to the target service function of the software to be tested;

the first processing unit 1102 is configured to determine, according to the multiple states, a state jump path where the software to be tested implements the target service function;

the second processing unit 1103 is configured to determine an interface test case for implementing adjacent state hopping in the state hopping path, and add the interface test case to a case set for implementing the target service function;

the calling unit 1104 is configured to sequentially call interface test cases from the case set according to the jump sequence of the state jump path, and perform an interface test of the target service function on the software to be tested.

As a possible implementation manner, the second processing unit 1103 is configured to read a state machine configuration file for implementing adjacent state jumps in the state jump path; the state machine configuration file at least comprises a present state, a secondary state, a condition and an attribute, wherein the present state is a first state in the jump direction of the adjacent state, the secondary state is a second state in the jump direction of the adjacent state, the condition comprises input data and a tested function, and the attribute comprises expected output data; and determining a corresponding interface test case according to the state machine configuration file.

As a possible implementation manner, the attribute further includes an interface address, and identifies an address of the corresponding interface test case request.

As a possible implementation, the state machine configuration file has a modifiable data structure.

As a possible implementation manner, the first processing unit 1102 is configured to traverse the plurality of states by a depth-first traversal method, and determine a state jump path of the software to be tested for implementing the target service function.

As a possible implementation manner, the apparatus further includes a deleting unit configured to delete a duplicate state jump path, where the state jump path has directionality.

As a possible implementation manner, the apparatus further includes a batch test unit, configured to obtain a plurality of case sets corresponding to a plurality of service functions implemented by the software to be tested; and performing interface test of the plurality of service functions on the software to be tested.

When testing software to be tested, the testing device provided by the embodiment of the application does not test the software to be tested according to interfaces required by the software to be tested one by one, but tests the software to be tested according to service functions of the software to be tested one by one. The method comprises the steps of firstly obtaining a plurality of states related to the target service function of the software to be tested, and determining a state jump path of the software to be tested for realizing the target service function according to the state jump sequence of the states. If the software to be tested has a plurality of service functions, each service function has a corresponding state jump path, and interface test cases required for realizing adjacent state jumps on the same state jump path are added into the same case set. When the interface test of the target service function is carried out on the software to be tested, according to the jump sequence of the state jump path corresponding to the realization of the target service function, the interface test cases are called from the case set corresponding to the state jump path in sequence, the output of the previous interface test case is the input of the next interface test case, so that the realization process of the target service function is simulated, front-end testers do not need to simulate the input data of each interface test case one by one, the test process is simplified, and the test efficiency is improved.

The embodiment of the present application further provides a device for testing, and the device for testing provided by the embodiment of the present application will be described below from the perspective of hardware materialization.

Referring to fig. 12, fig. 12 is a schematic diagram of a server 1400 provided by an embodiment of the present application, which may have a relatively large difference due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 1422 (e.g., one or more processors) and a memory 1432, one or more storage media 1430 (e.g., one or more mass storage devices) for storing applications 1442 or data 1444. Memory 1432 and storage media 1430, among other things, may be transient or persistent storage. The program stored on storage medium 1430 may include one or more modules (not shown), each of which may include a sequence of instructions operating on a server. Still further, a central processor 1422 may be disposed in communication with storage medium 1430 for executing a series of instruction operations on storage medium 1430 on server 1400.

The server 1400 may also include one or more power supplies 1426, one or more wired or wireless network interfaces 1450, one or more input-output interfaces 1458, and/or one or more operating systems 1441, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

The steps performed by the server in the above embodiment may be based on the server structure shown in fig. 12.

The CPU 1422 is configured to perform the following steps:

Optionally, the CPU 1422 may further execute the method steps of any specific implementation of the test method in the embodiment of the present application.

For the above-described test method, the embodiment of the present application further provides a terminal device for testing, so that the above-described test method is implemented and applied in practice.

Referring to fig. 13, fig. 13 is a schematic structural diagram of a terminal device according to an embodiment of the present application. For convenience of explanation, only the parts related to the embodiments of the present application are shown, and details of the specific technology are not disclosed. The terminal device may be any terminal device including a mobile phone, a tablet computer, a Personal Digital Assistant (PDA for short), and the like, taking the terminal device as the mobile phone as an example:

fig. 13 is a block diagram illustrating a partial structure of a mobile phone related to a terminal device provided in an embodiment of the present application. Referring to fig. 13, the cellular phone includes: a Radio Frequency (RF) circuit 1510, a memory 1520, an input unit 1530, a display unit 1540, a sensor 1550, an audio circuit 1560, a wireless fidelity (WiFi) module 1570, a processor 1580, and a power supply 1590. Those skilled in the art will appreciate that the handset configuration shown in fig. 13 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

The following describes each component of the mobile phone in detail with reference to fig. 13:

the RF circuit 1510 may be configured to receive and transmit signals during information transmission and reception or during a call, and in particular, receive downlink information of a base station and then process the received downlink information to the processor 1580; in addition, the data for designing uplink is transmitted to the base station. In general, RF circuit 1510 includes, but is not limited to, an antenna, at least one Amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, RF circuit 1510 may also communicate with networks and other devices via wireless communication. The wireless communication may use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Message Service (SMS), and the like.

The memory 1520 may be used to store software programs and modules, and the processor 1580 implements various functional applications and data processing of the mobile phone by operating the software programs and modules stored in the memory 1520. The memory 1520 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 1520 may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device.

The input unit 1530 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the cellular phone. Specifically, the input unit 1530 may include a touch panel 1531 and other input devices 1532. The touch panel 1531, also referred to as a touch screen, can collect touch operations of a user (e.g., operations of the user on or near the touch panel 1531 using any suitable object or accessory such as a finger or a stylus) and drive corresponding connection devices according to a preset program. Alternatively, the touch panel 1531 may include two parts, a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, and sends the touch point coordinates to the processor 1580, and can receive and execute commands sent by the processor 1580. In addition, the touch panel 1531 may be implemented by various types such as a resistive type, a capacitive type, an infrared ray, and a surface acoustic wave. The input unit 1530 may include other input devices 1532 in addition to the touch panel 1531. In particular, other input devices 1532 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

The display unit 1540 may be used to display information input by the user or information provided to the user and various menus of the mobile phone. The Display unit 1540 may include a Display panel 1541, and optionally, the Display panel 1541 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 1531 may cover the display panel 1541, and when the touch panel 1531 detects a touch operation on or near the touch panel 1531, the touch operation is transmitted to the processor 1580 to determine the type of the touch event, and then the processor 1580 provides a corresponding visual output on the display panel 1541 according to the type of the touch event. Although in fig. 13, the touch panel 1531 and the display panel 1541 are two separate components to implement the input and output functions of the mobile phone, in some embodiments, the touch panel 1531 and the display panel 1541 may be integrated to implement the input and output functions of the mobile phone.

The handset can also include at least one sensor 1550, such as light sensors, motion sensors, and other sensors. Specifically, the light sensor may include an ambient light sensor that adjusts the brightness of the display panel 1541 according to the brightness of ambient light and a proximity sensor that turns off the display panel 1541 and/or the backlight when the mobile phone is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when stationary, and can be used for applications of recognizing the posture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.

Audio circuitry 1560, speaker 1561, and microphone 1562 may provide an audio interface between a user and a cell phone. The audio circuit 1560 may transmit the electrical signal converted from the received audio data to the speaker 1561, and convert the electrical signal into an audio signal by the speaker 1561 and output the audio signal; on the other hand, the microphone 1562 converts collected sound signals into electrical signals, which are received by the audio circuit 1560 and converted into audio data, which are processed by the audio data output processor 1580 and then passed through the RF circuit 1510 for transmission to, for example, another cellular phone, or for output to the memory 1520 for further processing.

WiFi belongs to short-distance wireless transmission technology, and the mobile phone can help a user to receive and send e-mails, browse webpages, access streaming media and the like through a WiFi module 1570, and provides wireless broadband internet access for the user. Although fig. 13 shows WiFi module 1570, it is understood that it does not belong to the essential constitution of the handset and can be omitted entirely as needed within the scope not changing the essence of the invention.

The processor 1580 is a control center of the mobile phone, connects various parts of the entire mobile phone by using various interfaces and lines, and performs various functions of the mobile phone and processes data by operating or executing software programs and/or modules stored in the memory 1520 and calling data stored in the memory 1520, thereby integrally monitoring the mobile phone. Optionally, the processor 1580 may include one or more processing units; preferably, the processor 1580 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, and the like, and a modem processor, which mainly handles wireless communications. It is to be appreciated that the modem processor may not be integrated into the processor 1580.

The handset also includes a power supply 1590 (e.g., a battery) for powering the various components, which may preferably be logically coupled to the processor 1580 via a power management system to manage charging, discharging, and power consumption management functions via the power management system.

Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which are not described herein.

In an embodiment of the present application, the handset includes a memory 1520 that can store program code and transmit the program code to the processor.

The processor 1580 included in the mobile phone may execute the test method provided in the foregoing embodiments according to the instructions in the program code.

The embodiment of the present application further provides a computer-readable storage medium for storing a computer program, where the computer program is used to execute the testing method provided by the foregoing embodiment.

Embodiments of the present application also provide a computer program product or computer program comprising computer instructions stored in a computer-readable storage medium. The computer instructions are read by a processor of the computer device from a computer-readable storage medium, and the computer instructions are executed by the processor to cause the computer device to perform the testing method provided in the various alternative implementations of the above aspects.

Those of ordinary skill in the art will understand that: all or part of the steps for realizing the method embodiments can be completed by hardware related to program instructions, the program can be stored in a computer readable storage medium, and the program executes the steps comprising the method embodiments when executed; and the aforementioned storage medium may be at least one of the following media: various media that can store program codes, such as read-only memory (ROM), RAM, magnetic disk, or optical disk.

It should be noted that, in the present specification, all the embodiments are described in a progressive manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus and system embodiments, since they are substantially similar to the method embodiments, they are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described embodiments of the apparatus and system are merely illustrative, and the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only one specific embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present application should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of testing, the method comprising:

2. The method of claim 1, wherein the determining the interface test case for implementing the adjacent state jump in the state jump path comprises:

reading a state machine configuration file for realizing adjacent state jumping in the state jumping path; the state machine configuration file at least comprises a present state, a secondary state, a condition and an attribute, wherein the present state is a first state in the jump direction of the adjacent state, the secondary state is a second state in the jump direction of the adjacent state, the condition comprises input data and a tested function, and the attribute comprises expected output data;

and determining a corresponding interface test case according to the state machine configuration file.

3. The method of claim 2, wherein the attributes further comprise an interface address identifying an address of the corresponding interface test case request.

4. The method of claim 2, wherein the state machine configuration file has a modifiable data structure.

5. The method of claim 2, wherein determining the state jump path of the software to be tested for implementing the target business function according to the plurality of states comprises:

and traversing the states by a depth-first traversal method, and determining a state jump path of the software to be tested for realizing the target service function.

6. The method of claim 5, wherein before determining the interface test case for implementing the adjacent state jump in the state jump path, further comprising:

duplicate state-hop paths are deleted, the state-hop paths having directionality.

7. The method according to any one of claims 1-6, further comprising:

acquiring a plurality of case sets corresponding to a plurality of business functions realized by the software to be tested;

and performing interface test of the plurality of service functions on the software to be tested.

8. A test apparatus, the apparatus comprising: the system comprises an acquisition unit, a first processing unit, a second processing unit and a calling unit;

9. An apparatus for testing, the apparatus comprising a processor and a memory:

the processor is configured to perform the method of any of claims 1-7 according to instructions in the program code.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium is used to store a computer program for performing the method of any one of claims 1-7.