Software interface testing method and device, electronic equipment and medium

Abstract

The invention provides a software interface test method and device, electronic equipment and a medium. The method comprises the steps that test case parameters of a target interface are dynamically read from a predefined Excel file; constructing a test case based on the test case parameters; applying the test case to the target interface, and receiving response information returned by the target interface; and determining a test result of the target interface according to the response information. Through a parameter configuration interface of the Excel file, a user can easily add, modify or delete parameters without modifying source codes or configuration files. In addition, the test case can discover and process abnormal conditions in time through the functions of sending a network request and checking response information.

Description

Technical Field

[0001] The present disclosure relates to the technical field of software testing, and in particular to a method, device, electronic device and medium for testing a software interface. Background Art

[0002] In the field of software development, interface automation testing is one of the key steps to ensure software quality and stability. It aims to verify the functionality, performance, and stability of the software interface to ensure the reliability of the software under different environments and usage conditions. However, traditional interface testing methods have some limitations, especially in the dynamic parameter setting, which limits the comprehensiveness and effectiveness of the test.

[0003] Traditional interface testing methods are usually static, that is, the values ​​and ranges of parameters are fixed during the test case design phase. This method may be effective in some cases, but it often performs poorly when faced with variable actual application scenarios. Because it cannot fully consider the various boundary value situations and changes under different environments and usage conditions, the traditional static parameter setting method may lead to problems such as insufficient test coverage and missed tests. For example, consider a test scenario for an online payment interface. Traditional testing methods may only fix the payment amount and payment method in the test case, but in fact users may pay with various amounts and may choose different payment methods such as credit cards, Alipay, etc. In addition, factors such as the user's account balance, network environment, and server load will also affect the payment process. If the parameter settings in the test case are static, it is likely that all possible payment scenarios will not be covered, resulting in incompleteness and inaccuracy in the test. Summary of the invention

[0004] In view of the shortcomings of the prior art described above, the purpose of the present invention is to provide a software interface testing method, device, electronic device and medium, aiming to achieve comprehensive coverage of various test scenarios and boundary conditions and improve the efficiency and accuracy of the test.

[0005] A first aspect of the present disclosure provides a method for testing a software interface, which is applied to a client and includes: dynamically reading test case parameters of a target interface from a predefined Excel file; constructing a test case based on the test case parameters; applying the test case to the target interface and receiving response information returned by the target interface; and determining a test result of the target interface based on the response information.

[0006] In an embodiment of the first aspect, the dynamically reading test case parameters of the target interface from a predefined Excel file includes: creating an Excel file containing at least one worksheet; in response to user input, configuring the test case parameters of the target interface in the Excel file, and saving the test case parameters to a specified worksheet; generating a plurality of directly callable test case parameters in a dictionary structure from the Excel file.

[0007] In an embodiment of the first aspect, generating multiple test case parameters with a dictionary structure that can be directly called from the Excel file includes: locating and obtaining a target worksheet in the Excel file; extracting parameter names and corresponding parameter values ​​from the target worksheet, and integrating them into a preset parameter list; parsing the parameter list to generate multiple test case parameters with a dictionary structure that can be directly called.

[0008] In an embodiment of the first aspect, applying the test case to the target interface and receiving response information returned by the target interface includes: sending a network request containing test case parameters to the target interface; generating the network request based on the read test case parameter information and embedding the test case parameter information in a request body or a request header; and receiving response information returned by the target interface based on the network request.

[0009] In an embodiment of the first aspect, the response information includes a status code and response data of the test target interface, wherein the status code indicates a processing result of the network request, and the response data indicates the response content of the target interface to the network request or the reason why the target interface failed to execute the network request.

[0010] In an embodiment of the first aspect, determining the test result of the target interface based on the response information includes: checking the response information; if the response information includes an expected status code, determining that the target interface test is successful; if the response information includes an unexpected status code, determining that the target interface test has failed.

[0011] The second aspect of the present disclosure discloses a software interface testing method, which is applied to a target interface and includes: receiving a network request containing test case parameters sent by a client; executing the network request; and sending corresponding response information to the client based on the execution result.

[0012] In an embodiment of the second aspect, the corresponding response information is sent to the client based on the execution result, including: if the execution is successful, sending the expected status code and the response content of the network request to the client; if the execution fails, sending an unexpected status code to the client and causing the execution of the network request to fail.

[0013] The third aspect of the present disclosure discloses a testing device for a software interface, which is arranged on a client and includes: a reading module, used to dynamically read the test case parameters of the target interface from a predefined Excel file; a building module, used to build a test case based on the test case parameters; an application module, used to apply the test case to the target interface and receive response information returned by the target interface; and an analysis module, used to determine the test result of the target interface according to the response information.

[0014] The fourth aspect of the present disclosure discloses a testing device for a software interface, which is arranged at a target interface and includes: a receiving module for receiving a network request containing test case parameters sent by a client; an execution module for executing the network request; and a sending module for sending corresponding response information to the client based on the execution result.

[0015] A fifth aspect of the present disclosure discloses an electronic device, comprising: a processor and a memory; wherein the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory, so that the electronic device executes the software interface testing method as described in any one of the first aspect or the software interface testing method as described in any one of the second aspect.

[0016] A sixth aspect of the present disclosure discloses a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the software interface testing method described in any one of the first aspect or the software interface testing method described in any one of the second aspect.

[0017] As described above, the software interface testing method, device, electronic device and medium disclosed in the present invention have the following technical effects:

[0018] (1) Based on the parameter configuration interface of the Excel file, users can easily add, modify or delete parameters without modifying the source code or configuration files. This greatly improves the flexibility and configurability of the system and provides users with a more convenient configuration experience.

[0019] (2) The program dynamically reads the parameter information in the Excel file during runtime and applies it to the program in real time. This dynamic application enables the system to make corresponding adjustments based on configuration requirements, enhancing the intelligence and adaptability of the system.

[0020] (3) The function of sending network requests and checking status codes can detect and handle abnormal situations in a timely manner, enhance the stability and reliability of the system, and ensure the normal operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flowchart showing a method for testing a software interface in an embodiment of the present disclosure is shown.

[0022] Figure 2 A schematic diagram showing a process of dynamically reading test case parameters in an embodiment of the present disclosure.

[0023] Figure 3 A schematic diagram showing a flow chart of applying test case parameters in an embodiment of the present disclosure.

[0024] Figure 4 A flowchart showing a method for testing a software interface in another embodiment of the present disclosure is shown.

[0025] Figure 5 A module schematic diagram showing a testing device for a software interface in an embodiment of the present disclosure.

[0026] Figure 6 A module schematic diagram showing a testing device for a software interface in yet another embodiment of the present disclosure.

[0027] Figure 7 A schematic diagram of the circuit structure of an electronic device in an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0028] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0029] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0030] The technical solutions in the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0031] like Figure 1As shown, a flow chart of a method for testing a software interface in an embodiment of the first aspect of the present disclosure is shown, which is applied to a client and includes steps S11-S14.

[0032] Step S11: dynamically read the test case parameters of the target interface from a predefined Excel file.

[0033] In some embodiments, Figure 2 As shown, the step S11 includes steps S111 to S113, wherein:

[0034] Step S111: Create an Excel file containing at least one worksheet.

[0035] Specifically, first, create an Excel file, which will be used to store and manage test case parameters. This Excel file should contain at least one worksheet, each of which can contain test parameters for a specific interface or a group of related interfaces. For ease of management and distinction, test parameters for different interfaces can be stored in different worksheets.

[0036] Step S112: In response to user input, configure the test case parameters of the target interface in the Excel file, and save the test case parameters in a specified worksheet.

[0037] Specifically, the user performs input operations on the system interactive interface to configure the test case parameters of the target interface. These parameters may include URL, request header, request body, expected response code, etc. The user enters these parameter values ​​in the specified cells in the Excel file, and the system saves these parameters to the specified worksheet in a certain logical format. For example, you can enter the parameter name in the first column, the parameter value in the second column, and so on.

[0038] Step S113: Generate multiple test case parameters in a dictionary structure that can be directly called from the Excel file.

[0039] Exemplarily, the step S113 includes: locating and acquiring the target worksheet in the Excel file; extracting parameter names and corresponding parameter values ​​from the target worksheet, and integrating them into a preset parameter list; parsing the parameter list to generate multiple test case parameters in a dictionary structure that can be directly called.

[0040] In more detail, to locate and obtain the target worksheet in the Excel file, you need to use an appropriate programming language or library to operate the Excel file. Taking Python as an example, you can use the openpyxl library or the pandas library to process Excel files. First, open the Excel file using the functions provided by the library. This usually involves specifying the path and name of the file and creating an object representing the file. In the loaded Excel file, you need to locate the worksheet that contains the test case parameters. This can be achieved by the name or index of the worksheet. Once the target worksheet is found, it can be read and operated.

[0041] After locating the target worksheet, each parameter name and corresponding parameter value can be accessed by traversing each row (or column) of the target worksheet. This involves iterative traversal and processing a row of data in each iteration. During the traversal process, the parameter name and parameter value need to be extracted from each cell. This can be achieved by reading the value attribute of the cell. The extracted information can be cleaned or converted as needed, for example, converting string type parameter values ​​to the correct data type (such as integers, floating point numbers, or Boolean values). The extracted parameter information needs to be integrated into a preset parameter list. This list can be a Python list, where each element is a tuple or dictionary containing the parameter name and parameter value. In this way, these parameters can be easily accessed and managed.

[0042] Finally, the information integrated into the parameter list is parsed into a test case parameter in a dictionary structure that can be directly called. Specifically, each parameter element in the parameter list can be parsed into a dictionary structure, where the key is the parameter name and the value is the corresponding parameter value. The dictionary structure can be directly called for subsequent interface test operations.

[0043] Step S12: construct a test case based on the test case parameters.

[0044] Specifically, design the basic structure of the test case according to the test requirements. This usually includes the test case ID, test purpose, input data, execution conditions, expected results, etc. This step ensures the integrity and consistency of the test case. Use the dictionary structure obtained from the parameter list to fill in the input data part of the test case. For example, if the test case needs to verify a specific user login function, the dictionary structure will provide specific values ​​such as username and password. Set any necessary environmental conditions or prerequisites according to the dictionary structure. This involves configuring the state of the test environment, such as the initialization state of the database, the opening of a specific port, etc. Use the information in the dictionary structure to clearly define the expected results of each test case. This includes expected return values, error messages, system behaviors, etc., which are the criteria for subsequent verification of whether the test passes or fails. Combine all the above elements to form a complete test case. Ensure that each test case is independent, that is, it can be executed independently without relying on other test cases.

[0045] Step S13: Apply the test case to the target interface, and receive response information returned by the target interface.

[0046] In some embodiments, Figure 3 As shown, the step S13 specifically includes steps S131 to S132, wherein:

[0047] Step S131: Sending a network request containing test case parameters to the target interface. The network request is generated according to the read test case parameter information, and the test case parameter information is embedded in the request body or request header.

[0048] Specifically, as described in the previous steps, read the test case parameters from the predefined Excel file. Use the read parameters to build a network request object, which usually involves specifying the HTTP method (such as GET, POST, PUT, etc.), setting the request URL, and adding the necessary request headers and request bodies. The request header may include content type, authorization information, etc., while the request body may contain the actual data payload, such as a JSON object or form data.

[0049] Embed the read parameter information into the request body or request header according to the test requirements. For example, if the test is a POST request and specific user-submitted data needs to be verified, the user-submitted data obtained from the parameter list should be correctly serialized and embedded in the request body. If the test is related to authentication, the API key or access token should be added to the request header. Use appropriate software libraries or tools (such as Python's requests library, Postman, etc.) to send the constructed network request to the target interface. This operation may require setting timeouts, handling cookies and sessions, and considering asynchronous requests.

[0050] Step S132: Receive response information returned by the target interface based on the network request.

[0051] Specifically, after the network request is sent, the test system waits for the target interface to process the request and return a response. This process involves network latency, processing time, and data transmission time. Once the target interface completes the processing, it returns a response message to the test system.

[0052] Furthermore, the response information usually includes two main parts: a status code and the response data of the test target interface.

[0053] The status code is a three-digit code that indicates the processing result of the request according to the HTTP standard. For example, the 200 series status code indicates success, the 400 series indicates a client error, and the 500 series indicates a server error. The response data is the specific data returned by the target interface based on the request content. If the request is successfully processed, the response data may be the expected output of the request; if the processing fails, the response data may contain error information or the reason for the failure.

[0054] Step S14: Determine the test result of the target interface according to the response information.

[0055] In some implementations, the response information is checked using an assertion; if the response information includes an expected status code, the target interface test is determined to be successful; if the response information includes an unexpected status code, the target interface test is determined to be a failure.

[0056] Specifically, according to the design of the test case, the expected response result is predefined. This usually includes the expected status code, the data expected to be returned in the response body, and possible response header information. Assertions are implemented to verify the response information. Assertions are a checking mechanism in programming that is used to confirm whether certain conditions of the program are true. In the present disclosure, assertions will be used to confirm whether the response information meets the expected results and check whether the status code of the response matches the expected status code. For example, if the expected status code is 200 (OK) and the actual response status code is also 200, the assertion is successful. Verify whether the data in the response body contains the expected return value or message. For example, if the request is a query operation and the data of a specific database record is expected to be returned, it is necessary to confirm whether the data exists and is correct. For another example, if the request is to create a resource and the resource is expected to be successfully created, the status code should be 201 (created). If the status code does not match the expectation, it may mean that there is a configuration error, a server problem, or other abnormal situation.

[0057] If the status code is consistent with expectations, the test system will further analyze the response data to ensure that the data strictly corresponds to the expected results. Only when both the status code and the response data meet expectations can the behavior of the target interface under this test case be considered to meet the specified requirements, and the test is confirmed to have passed.

[0058] If any unexpected results are identified in the response information, whether due to incorrect status codes, missing response data, or inaccurate data, these will be considered assertion failures. Any such failure indicates that the target interface does not perform up to the established standards under this test case, and the test is considered unsuccessful.

[0059] In this way, the read test case parameters can be effectively used to construct and send network requests to the target interface, while ensuring the accuracy of the request and the reliability of the test process.

[0060] like Figure 4 As shown, a flow chart of a method for testing a software interface in an embodiment of the second aspect of the present disclosure is shown, which is applied to a target interface and includes steps S41-S43.

[0061] Step S41: receiving a network request including test case parameters sent by a client.

[0062] Specifically, the server or target interface is in a waiting state, ready to receive requests from the client. This usually involves starting the service on a specific port so that the client can find and communicate with it over the network. When the client initiates a network request, the server detects the request and prepares to process it. This process involves checking the integrity of the request, verifying the connection protocol, etc. After receiving the request, the server begins to parse the data in it. This includes extracting HTTP methods (such as GET, POST, etc.), URL paths, query parameters, request headers, and test case parameters in the request body. The parsed test case parameters are verified to ensure that they conform to the expected format and range. If the parameters do not meet the requirements, the server may return an error response, such as 400Bad Request. Once the verification is passed, the server is ready to execute the request. This may involve initializing database connections, preparing resources required for business logic processing, etc.

[0063] Step S42: Execute the network request.

[0064] Specifically, based on the parsed test case parameters and request type, the server executes the corresponding business logic, which includes operations such as querying the database, calculating data, and updating data status. If the network request involves data storage or retrieval, the server will interact with the database or other backend services. During the execution of the request, the server needs to handle various abnormal situations that may occur, such as database connection failures and business logic errors.

[0065] Step S43: Based on the execution result, corresponding response information is sent to the client.

[0066] In some implementations, the step S43 specifically includes: if the execution is successful, sending the expected status code and the response content of the network request to the client; if the execution fails, sending an unexpected status code to the client and causing the network request to fail.

[0067] Specifically, based on the result of executing the network request, determine whether the operation is successful, which involves checking whether the business logic is completed as expected, whether the database operation is successful, and whether other necessary conditions are met.

[0068] If the execution is successful, the server will prepare response data including status code and response content. For successful operations, a status code such as 200 is usually used to indicate that the request has been successfully processed. At the same time, the response content should contain the data or results required by the request. Using appropriate protocols and technologies (such as HTTP / HTTPS), the target interface sends the generated response data back to the client.

[0069] If the execution fails, the target interface also needs to send a response to the client. This response information should include an unexpected status code and the specific reason or error information that caused the failure. Among them, unexpected status codes are 4xx series error codes (such as 404 Not Found, 403 Forbidden) or 5xx series error codes (such as 500 Internal Server Error, 503 Service Unavailable), etc. These status codes indicate that the server encountered a problem and could not complete the request. The error message provides detailed information about the error to help users or developers understand what went wrong and guide them to take appropriate solutions.

[0070] This embodiment ensures that the client can accurately understand the processing result of the server by accurately sending the status code and response content corresponding to the request execution result. When successful, the expected status code (such as 200OK) and the required data are returned, and when failed, the specific error status code and reason are provided, which reduces unnecessary round-trip communication and improves the overall communication efficiency and reliability.

[0071] In order to better illustrate the principle of the above implementation method, a specific example is listed below, and the application scenario is a test scenario of an online payment interface.

[0072] The goal of this example is to test the functionality and performance of the interface under different amounts, payment methods, account balances, network environments, server loads, etc., to ensure that the payment interface can run stably in various situations and can handle various abnormal situations.

[0073] First, create an Excel file to store different test case parameters. Each test case may include different parameters such as payment amount, payment method, user account balance, etc. List all test case parameters in the Excel file as shown in the following table:

[0074] Test case number Payment amount (RMB) Payment Methods Account balance (yuan) Payment password 1 1 credit card 10 123456 2 10 Alipay 0 678901 3 100 WeChat Pay 100 246800 4 1000 credit card 100 321654

[0075] Run the test cases one by one according to the test case numbers in the table. For each test case, generate a corresponding HTTP request and embed the test case parameters in the request body or request header. Use an HTTP client library (such as Python's requests library) to send an HTTP request to the payment interface. The request may include parameters such as payment amount, payment method, account balance, payment password, etc.

[0076] After receiving the HTTP request, the target interface executes the HTTP request and sends a response message to the client according to the execution result. The client receives the response from the payment interface. It obtains the status code from the response and uses an assertion to check whether the response code is 200.

[0077] If the response code is 200, use assertions to verify whether the payment amount is deducted correctly, whether the payment method is selected correctly, whether the account balance is updated correctly, whether the network environment has an impact on the payment process, and whether the server load has an impact on the payment process. If all steps are successful, return payment result confirmation information, such as "Payment successful, amount is 1 yuan."

[0078] If the status code is not 200, capture AssertionError and return the response error information, indicating the reason for the request failure, such as "insufficient account balance", "internal server error", "unsupported payment method", "wrong password", etc.

[0079] It should be particularly noted that the process or method represented by the flowchart of the above embodiment of the present disclosure can be understood as representing a module, fragment or part of a code including one or more sets of executable instructions configured to implement the steps of a specific logical function or process. And the scope of the preferred embodiment of the present disclosure includes other implementations, in which the functions may not be performed in the order shown or discussed, including performing the functions in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0080] like Figure 5 As shown, a software interface testing device 50 of the third aspect of the present disclosure is provided at the client. It should be noted that the principle and technical implementation of the multi-software interface testing device can refer to the software interface testing method embodiment in the previous embodiment (for example Figure 1 ), so it will not be repeated in this embodiment.

[0081] Specifically, the software interface testing device 50 includes: a reading module 51, a construction module 52, an application module 53, and an analysis module 54, wherein:

[0082] The reading module 51 is used to dynamically read the test case parameters of the target interface from a predefined Excel file.

[0083] The construction module 52 is used to construct a test case based on the test case parameters.

[0084] The application module 53 is used to apply the test case to the target interface and receive response information returned by the target interface.

[0085] The analysis module 54 is used to determine the test result of the target interface according to the response information.

[0086] like Figure 6 As shown, the software interface testing device 60 of the fourth aspect of the present disclosure is set at the target interface. It should be noted that the principle and technical implementation of the testing device for multiple software interfaces can refer to the software interface testing method embodiment in the previous embodiment (for example Figure 3 ), so it will not be repeated in this embodiment.

[0087] Specifically, the software interface testing device 60 includes: a receiving module 61, an execution module 62, and a sending module 63, wherein:

[0088] The receiving module 61 is used to receive a network request containing test case parameters sent by a client;

[0089] The execution module 62 is used to execute the network request;

[0090] The sending module 63 is used to send corresponding response information to the client based on the execution result.

[0091] It should be noted that Figure 5 , Figure 6 Each functional module in the embodiment can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a program instruction product. The program instruction product includes one or a group of program instructions. When the program instruction is loaded and executed on a computer, the process or function according to the present disclosure is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The program instruction can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0092] and, Figure 5 , Figure 6 The device disclosed in the embodiment can be implemented by other module division methods. The device embodiments shown above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as a group of modules or modules can be combined or dynamically added to another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical or other forms.

[0093] in addition, Figure 5 , Figure 6 Each functional module and submodule in the embodiment can be dynamically in a processing component, or each module can exist physically separately, or two or more modules can be dynamically in one component. The above-mentioned dynamic components can be implemented in the form of hardware or in the form of software functional modules. If the above-mentioned dynamic components are implemented in the form of software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.

[0094] like Figure 7 As shown, a schematic diagram of the structure of an electronic device in an embodiment of the fifth aspect of the present disclosure is shown.

[0095] The electronic device can execute the following steps by running the computer program instructions: Figure 1 or Figure 4The test method of the interface described in any one of the items. Exemplarily, the electronic device can be a server group / server, a desktop computer, a laptop computer, etc., or a cloud server / server group, a distributed computing node system, etc. that remotely communicates with a local terminal.

[0096] The electronic device 70 includes a bus 71, a processor 72, and a memory 73. The processor 72 and the memory 73 can communicate with each other through the bus 71. The memory 73 can store program instructions. The processor 72 implements the method steps in the previous embodiment by running the program instructions in the memory 73, such as Figure 1 or Figure 4 A method for testing an interface as described in any one of the items.

[0097] The bus 71 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, although only one thick line is used in the figure, it does not mean that there is only one bus or one type of bus.

[0098] In some embodiments, the processor 72 may be implemented as a central processing unit (CPU), a microprocessing unit (MCU), a system on chip (System On Chip), or a field programmable logic array (FPGA). The memory 63 may include a volatile memory (Volatile Memory) for temporary storage of data when running a program, such as a random access memory (Random Access Memory, RAM).

[0099] The memory 73 may also include a non-volatile memory (non-volatile memory) for data storage, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid-state disk (SSD).

[0100] In some embodiments, the electronic device 70 may further include a communicator 74. The communicator 74 is used to communicate with the outside. In a specific example, the communicator 74 may include one or a group of wired and / or wireless communication circuit modules. For example, the communicator 74 may include one or more of a wired network card, a USB module, a serial interface module, etc. The wireless communication protocols followed by the wireless communication module include: for example, near field wireless communication (NFC) technology, infrared (IR) technology, global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time division code division multiple access (TD-SCDMA), long term evolution (LTE), Bluetooth (BT), global navigation satellite system (GNSS), etc. One or more of the above.

[0101] In the sixth aspect of the present disclosure, a computer-readable storage medium may be provided, wherein program instructions are stored, and the program instructions are executed by running, for example Figure 1 or Figure 4 A method for testing a component interface in an embodiment.

[0102] That is, the method steps in the above embodiments are implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or are implemented as computer code originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded via a network and to be stored in a local recording medium, so that the method represented herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA).

[0103] In summary, the test method, device, electronic device and medium of the software interface disclosed in the present invention can easily add, modify or delete parameters through the parameter configuration interface of the Excel file without modifying the source code or configuration file. This greatly improves the flexibility and configurability of the system and provides users with a more convenient configuration experience. The program dynamically reads the parameter information in the Excel file at runtime and applies it to the program in real time. This dynamic application enables the system to make corresponding adjustments according to the configuration requirements, enhancing the intelligence and adaptability of the system. By sending HTTP requests and checking the status code, abnormal situations can be discovered and handled in a timely manner.

[0104] The above embodiments are merely illustrative of the principles and effects of the present disclosure, and are not intended to limit the present disclosure. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present disclosure. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present disclosure shall still be covered by the claims of the present disclosure.

Claims

1. A software interface testing method, applied to a client, characterized in that: include: Dynamically read the test case parameters of the target interface from a pre-defined Excel file; Constructing a test case based on the test case parameters; Applying the test case to the target interface and receiving response information returned by the target interface; A test result of the target interface is determined according to the response information.

2. The software interface testing method according to claim 1, characterized in that: The method of dynamically reading the test case parameters of the target interface from the predefined Excel file includes: Create an Excel file containing at least one worksheet; In response to user input, configuring the test case parameters of the target interface in the Excel file, and saving the test case parameters to a specified worksheet; Generate multiple directly callable test case parameters in a dictionary structure from the Excel file.

3. The software interface testing method according to claim 2, characterized in that: The method of generating multiple directly callable test case parameters of a dictionary structure from the Excel file includes: Locate and obtain the target worksheet in the Excel file; Extract parameter names and corresponding parameter values ​​from the target worksheet and integrate them into a preset parameter list; The parameter list is parsed to generate multiple test case parameters in a dictionary structure that can be directly called.

4. The software interface testing method according to claim 1, characterized in that: The step of applying the test case to the target interface and receiving response information returned by the target interface includes: Sending a network request containing test case parameters to the target interface; the network request is generated according to the read test case parameter information, and the test case parameter information is embedded in the request body or request header; Receive response information returned by the target interface based on the network request.

5. The software interface testing method according to claim 4, characterized in that: The response information includes a status code and response data of the test target interface, wherein: The status code indicates a processing result of the network request, and the response data indicates the response content of the target interface to the network request or the reason why the target interface fails to execute the network request.

6. The software interface testing method according to claim 5, characterized in that: The step of determining the test result of the target interface according to the response information includes: checking the response information; If the response information includes the expected status code, it is determined that the target interface test is successful; If the response information includes an unexpected status code, it is determined that the target interface test has failed.

7. A software interface testing method, applied to a target interface, characterized in that: include: Receive the network request containing test case parameters sent by the client; Executing the network request; Based on the execution result, corresponding response information is sent to the client.

8. The software interface testing method according to claim 7, characterized in that: The sending corresponding response information to the client based on the execution result includes: If the execution is successful, the expected status code and the response content of the network request are sent to the client; If the execution fails, an unexpected status code is sent to the client and the network request execution fails.

9. A software interface testing device, arranged at a client, characterized in that: include: The reading module is used to dynamically read the test case parameters of the target interface from a predefined Excel file; A construction module, used for constructing a test case based on the test case parameters; An application module, used for applying the test case to the target interface and receiving response information returned by the target interface; An analysis module is used to determine a test result of the target interface according to the response information.

10. A software interface testing device, arranged at a target interface, characterized in that: include: A receiving module is used to receive a network request containing test case parameters sent by a client; An execution module, used for executing the network request; The sending module is used to send corresponding response information to the client based on the execution result.

11. An electronic device, characterized in that: The electronic device comprises: Processor and memory; Wherein, the memory is used to store computer programs; The processor is used to execute the computer program stored in the memory so that the electronic device executes the software interface testing method described in any one of claims 1 to 6 or the software interface testing method described in claim 7 or 8.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by an electronic device, it implements the software interface testing method described in any one of claims 1 to 6 or the software interface testing method described in claim 7 or 8.

Images