Message generation request body method and device, computer device and storage medium

By defining interface templates and custom scripts in Metersphere and JMeter, the details are automatically expanded based on the number of items in the interface response to generate a complete message request body. This solves the problem of limited scenarios in interface automation test cases and achieves more comprehensive automation test coverage.

CN119311587BActive Publication Date: 2026-02-03SHENZHEN LANYOU TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411372062.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-09-29
Publication Date
2026-02-03
Estimated Expiration
2044-09-29

AI Technical Summary

Technical Problem

When using Metersphere and Jmeter for API automation testing, the test cases are limited to a single scenario, making it difficult to flexibly automate testing for more business scenarios based on different business data.

Method used

Define the keys and values ​​of the interface to be tested, obtain the fields that need to be parameterized for the items in multiple detail rows, obtain the interface query results through the beashell script syntax of Meterstphere, convert them into a message request body using JsonItemExpander, and set it into the Meterstphere parameters.

Benefits of technology

It achieves flexibility in interface automation test cases, and can automatically match and generate complete message request bodies based on different business data, covering more test scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119311587B_ABST
    Figure CN119311587B_ABST
Patent Text Reader

Abstract

The present application belongs to the field of software testing, and relates to a message request body generation method and device, computer equipment and a storage medium. The method comprises the following steps: defining the keys and values of the interfaces that need to request the interfaces, and the strings of the fields that need to be parameterized; acquiring the strings of the fields that need to be expanded and parameterized in all items; adding the strings of the fields that need to be expanded and parameterized in the items into a Map; acquiring the number of items to be expanded from a response result, and passing the acquired parameters to an encapsulation class JsonItemExpander; calling the encapsulation class JsonItemExpander through an imported ly.mp.ms.common.jar; outputting the message after the items are expanded; and setting the output message character into an MS parameter. The interface automation case is more flexible, does not depend on fixed design data, and can be directly run normally by automatically matching different data.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a method and device for generating a message request body, a computer device and a storage medium. BACKGROUND

[0002] MeterSphere is a comprehensive test management platform, and its interface automation testing function allows testers to automatically verify the function, performance and stability of software interfaces by writing test scripts. Through MeterSphere, testers can more conveniently manage test resources, execute test tasks, and quickly locate problems, thereby improving overall test efficiency and software quality.

[0003] JMeter is an open-source performance testing tool, and its interface automation testing function is also powerful. JMeter simulates the behavior of a large number of concurrent users to perform stress testing on software interfaces to evaluate the performance of the interface under high load. The interface automation testing function of JMeter can not only help testers find potential performance bottlenecks, but also verify the stability of the interface under various complex scenarios.

[0004] Currently, when Metersphere and Jmeter perform interface automation testing, the number of item detail data in the response result of each request of the previous interface request is not fixed, which causes the next interface request to also be unknown about how many items of message bodies need to be written to request.

[0005] In the prior art, when Metersphere and Jmeter perform interface automation testing, only fixed use case data can be designed in advance, and after the basic use case data is determined, there will be a fixed number of items, and subsequent requests can parameterize variables and form message body requests according to the fixed number. This way, the use case scenario is single and cannot automatically test more business scenarios according to different business data. SUMMARY

[0006] The purpose of the embodiments of the present application is to provide a method and device for generating a message request body, a computer device and a storage medium to solve the problem of single use case scenario in the prior art when Metersphere and Jmeter perform interface automation testing, which cannot automatically test more business scenarios according to different business data.

[0007] To solve the above technical problems, the present application provides a method for generating a message request body, which adopts the following technical solution, comprising:

[0008] S1, define the keys and values of the interface to be tested, and the fields that need to be parameterized;

[0009] S2, acquire the field in the item of one main single corresponding to multiple detail lines which needs parameterization;

[0010] S3, add the string of the field in the item which needs to be extended parameterization to the data structure Map for storing key-value pairs;

[0011] S4, acquire the number of the item to be extended from the response result returned by the interface of the previous query class, extract parameters by matching multiple data through Metesphere, take the data result returned by the interface of the previous query class as parameters, and pass the acquired parameters to the encapsulation class JsonItemExpander, call the encapsulation class JsonItemExpander through the imported ly.mp.ms.common.jar, and convert into a message request body;

[0012] S5, run the interface test case to be tested, and output the message request body after the item is extended;

[0013] S6, set the output message request body into the Meterstphere parameter.

[0014] Preferably, the step of S1, defining the key and value of the interface to be tested, and the field needing parameterization, specifically comprises:

[0015] S11, define the overall structure identifier of the request message body;

[0016] S12, create two HashMap key-value pair data structures of head and items respectively, and add the message fields needing to be generated into the key-value pair.

[0017] Preferably, the step of S2, acquiring the field in the item of one main single corresponding to multiple detail lines which needs parameterization, specifically comprises:

[0018] S21, acquire the writing of multiple detail data of the interface query result in the previous step through the beashell script syntax of Meterstphere;

[0019] S22, pass the parameter value acquired in the previous step to the character variable through the declaration of the character variable.

[0020] Preferably, the step of S3, adding the string of the field in the item which needs to be extended parameterization to the data structure Map for storing key-value pairs, specifically comprises:

[0021] S31, create the HashMap key-value pair data structure of the field needing to be extended parameterization;

[0022] S32, add the field needing to be parameterized for expansion into the key-value pair.

[0023] Preferably, the S4 obtains the number of items to be expanded from the response result returned from the interface of the previous query class, matches multiple data extraction parameters through Metesphere, takes the obtained data result returned from the interface of the previous query class as a parameter, and transmits the obtained parameter to the encapsulation class JsonItemExpander, calls the encapsulation class JsonItemExpander through the imported ly.mp.ms.common.jar, and converts into a message request body.

[0024] S41, obtains the number of items to be expanded from the response result returned from the interface of the previous query class, takes the number of fields needing to be expanded in the response result obtained through the interface query in the previous step as the number of items to be expanded;

[0025] S42, declares an integer parameter, and assigns the result of the previous step to the integer parameter;

[0026] S43, takes the data result returned from the interface of the previous query class as a parameter and transmits the parameter to the getJSONStr method in the encapsulation class JsonItemExpander, and converts into a message request body.

[0027] Preferably, the S5 runs the interface test case to be tested, and the step of outputting the message request body after expanding the item includes:

[0028] S51, converts the message request body into a string recognizable by Meterstphere;

[0029] S52, runs the interface test case to be tested, and outputs the message request body after expanding the item.

[0030] Preferably, the S6 sets the output message request body into the Meterstphere parameter, and the step includes:

[0031] S61, extracts a message string variable req_array from the message request body;

[0032] S62, sets the message string variable req_array to the parameter jsonReqArray recognizable by Meterstphere.

[0033] In order to solve the above technical problems, the application also provides a message request body generation device, which adopts the technical scheme as follows:

[0034] A definition module is configured to define keys and values of an interface to be tested and fields to be parameterized;

[0035] An acquisition module is configured to acquire the fields to be parameterized in an item corresponding to a plurality of detail lines of a main single;

[0036] An addition module is configured to add a string of the fields to be expanded and parameterized in the item to a data structure Map for storing key-value pairs;

[0037] A calling module is configured to acquire a number of the item to be expanded from a response result returned by an interface from a previous query class, extract parameters by matching a plurality of data through Metesphere, take the data result returned by the interface from the previous query class as parameters, and pass the acquired parameters to an encapsulation class JsonItemExpander, call the encapsulation class JsonItemExpander through ly.mp.ms.common.jar imported, and convert into a message request body;

[0038] An output module is configured to run an interface case to be tested and output the message request body after the item is expanded;

[0039] A setting module is configured to set the output message request body into a Meterstphere parameter.

[0040] To solve the above technical problems, the present application also provides a computer device, which adopts the technical scheme as follows: a memory and a processor, the memory stores computer readable instructions, and the processor executes the computer readable instructions to realize the steps of the above-mentioned message request body generation method.

[0041] To solve the above technical problems, the present application also provides a computer readable storage medium, which adopts the technical scheme as follows: the computer readable storage medium stores computer readable instructions, and the computer readable instructions are executed by the processor to realize the steps of the above-mentioned message request body generation method.

[0042] Compared with the prior art, the present application has the following beneficial effects: by adding a custom script in interface testing, defining an interface template, and automatically expanding item details and generating a complete message body request according to the number of items in the response of the previous step, the interface automation case is more flexible and does not depend on fixed design data, and different data can be automatically matched and directly run normally; according to different business data, more business scenarios are tested automatically, and the scenario coverage of the automation test case is more comprehensive. BRIEF DESCRIPTION OF DRAWINGS

[0043] In order to more clearly illustrate the solutions in the present application, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced as follows. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0044] Figure 1 is an exemplary system architecture diagram to which the present application can be applied;

[0045] Figure 2 is a flow chart of an embodiment of the method for generating a message request body of the present application;

[0046] Figure 3 is a structural schematic diagram of an embodiment of the device for generating a message request body of the present application;

[0047] Figure 4 is a structural schematic diagram of an embodiment of the computer device of the present application. DETAILED DESCRIPTION

[0048] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs; the terminology used in the description of the specification of the application only for the purpose of describing specific embodiments, and is not intended to limit the present application; the terms "include" and "have" and any variations thereof in the specification and claims of the present application and the above description of drawings are intended to cover the non-exclusive inclusion. The terms "first", "second" and the like in the specification and claims of the present application or the above description of drawings are used to distinguish different objects, not to describe a particular order.

[0049] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The appearance of the phrase in various places in the specification does not necessarily all refer to the same embodiment, nor is it necessarily mutually exclusive of other embodiments. It is explicitly and implicitly understood that the embodiments described herein can be combined with other embodiments.

[0050] In order to make the person skilled in the art better understand the solutions of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings.

[0051] The RequestBody plays a crucial role in the HTTP protocol, as it is used to transmit the data portion sent by the client to the server. As an optional component of the HTTP request, the RequestBody carries the required parameters, content, or data for the request, enabling the client to effectively exchange data with the server.

[0052] Specifically, the RequestBody mainly contains various types of data that the client wants to send to the server. These data can exist in multiple formats, including but not limited to form data (application / x-www-form-urlencoded), JSON data (application / json), files (multipart / form-data), etc. The specific format is usually specified by the Content-Type field in the request header, so that the server can correctly parse and process these data.

[0053] The RequestBody enables the client to pass complex, structured data to the server, supporting various network application scenarios such as user login, data submission, file upload, etc. For example, in the shopping cart settlement scenario of an e-commerce platform, the user's purchase information (such as product ID, quantity, etc.) can be sent to the server in JSON format through the RequestBody, thereby realizing the order generation and payment process.

[0054] As shown in Figure 1 The system architecture 100 can include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 can include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0055] Users can use the first terminal device 101, the second terminal device 102, or the third terminal device 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, or the third terminal device 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0056] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with a display screen and supporting web browsing, including but not limited to a smart phone, a tablet computer, an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, a desktop computer, and the like.

[0057] The server 105 can be a server providing various services, for example, a background server providing support for a page displayed on the first terminal device 101, the second terminal device 102, and the third terminal device 103.

[0058] It should be noted that the method for generating a message request body provided in the embodiments of the present application is generally executed by a server / terminal device, and accordingly, the device for generating a message request body is generally arranged in a server / terminal device.

[0059] It should be understood that Figure 1 The number of terminal devices, networks, and servers in

[0060] Example One

[0061] With reference to Figure 2 , a flow chart of one embodiment of the method for generating a message request body of the present application is shown. The method for generating a message request body includes the following steps:

[0062] In step S1, keys and values of a to-be-tested interface and fields that need to be parameterized are defined.

[0063] In the present embodiment, the electronic device (for example, the server / terminal device shown in Figure 1 The server / terminal device can receive the request for generating a message request body through a wired connection or a wireless connection. It should be noted that the wireless connection can include but is not limited to 3G / 4G / 5G connection, WiFi connection, Bluetooth connection, WiMAXX connection, Zigbee connection, UWB (ultra wideband) connection, and other now known or future developed wireless connection.

[0064] Here the custom script, for different interfaces to be tested, the request body field is different. In this embodiment, the format and field of the custom message request body is defined using the beanshell script syntax in Metersphere, which is compatible with the java syntax.

[0065] In this embodiment, step S1 can further include the following steps:

[0066] S11, define the overall structure identifier of the request message body.

[0067] Take the following interface request body as an example:

[0068]

[0069]

[0070] String headName = "head"; / / If not needed, fill in, considering that there may be some request body without such head wrapped header information, which can be empty.

[0071] String itemName = "items"; / / Mandatory. This method mainly deals with the expansion of multiple detail lines, so there must be an items identifier to wrap the details, so it is mandatory, and the items value can be freely defined, such as dataList, datas, etc.

[0072] S12, create two HashMap key-value pair data structures of head and items respectively, and add the fields of the message to be generated to the key-value pair.

[0073] For example, two HashMap key-value pair data structures can be named headMap and itemMap.

[0074] If the value needs to match multiple, the value should be written as xxxx_ALL according to the format rule, where xxxx is the corresponding key. If the value does not need to match multiple, it can be parameterized or written as a fixed value according to the MS syntax. For example, in the following example: XXXX represents containerNo and id.

[0075] For example, a value and multiple values can be defined in advance:

[0076] One value: key value is: "XXXX":"${XXXX}";

[0077] Multiple values: key value is: "XXXX":"XXXX_ALL".

[0078] HashMap headMap=new HashMap();

[0079] headMap.put("waybillNo","${waybillNo}");

[0080] headMap.put("driverName","Zhang San");

[0081] headMap.put("status","4");

[0082] HashMap itemMap=new HashMap();

[0083] itemMap.put("waybillNo","${waybillNo}");

[0084] itemMap.put("containerNo","containerNo_ALL");

[0085] itemMap.put("id","id_ALL");

[0086] itemMap.put("status","3");

[0087] itemMap.put("pickQuantity","pickQuantity_ALL");

[0088] itemMap.put("realityPickTime",

[0089] "${__timeShift(yyyy-MM-dd HH:mm:ss,,,,)}");

[0090] itemMap.put("deliverQuantity","");

[0091] itemMap.put("deliveryArrivalTime","");

[0092] Step S2: Obtain the fields that need to be parameterized from the item corresponding to multiple detail rows in a master order.

[0093] In this embodiment, step S2 may further include the following steps:

[0094] S21, get the writing method of the multiple detail data of the interface query result of the previous step through the beashell script syntax of Meterstphere.

[0095] For example, all the fields that need to obtain multiple detail data can be obtained by code vars.get("containerNo_ALL");

[0096] S22, pass the parameter value obtained in the previous step to the character variable by declaring the character variable.

[0097] For example, the code can be used:

[0098] String id_ALL=vars.get("id_ALL");

[0099] String containerNo_ALL=vars.get("containerNo_ALL");

[0100] String planQuantity_ALL=vars.get("planQuantity_ALL");

[0101] Step S3, add the string of the field that needs to be expanded and parameterized in the item to the data structure Map for storing key-value pairs.

[0102] Map is a data structure for storing key-value pairs in JAVA programming, which is used in the Beanshell script of Metersphere.

[0103] In the embodiment, step S3 can further include the following steps:

[0104] S31, create a HashMap key-value pair data structure of the field that needs to be expanded and parameterized.

[0105] S32, add the field that needs to be expanded and parameterized to the key-value pair.

[0106] For example, when adding the field that needs to be expanded and parameterized to the key-value pair, the name can be valueMap, the key is the content in the left quotation mark, which is consistent with XXXX_ALL defined in step S1, and the value is the string of the field that needs to be expanded and parameterized obtained in step S2.

[0107] For example, the code can be used to realize:

[0108] HashMap valueMap=new HashMap();

[0109] valueMap.put("id_ALL", id_ALL);

[0110] valueMap.put("containerNo_ALL", containerNo_ALL);

[0111] valueMap.put("pickQuantity_ALL", planQuantity_ALL);

[0112] Step S4, the number of items to be expanded is obtained from the response result returned from the interface of the previous query class, the parameters are extracted by matching multiple data through Metesphere, the data result returned from the interface of the previous query class is taken as the parameter, and the obtained parameter is transmitted to the encapsulation class JsonItemExpander, the encapsulation class JsonItemExpander is called through the imported ly.mp.ms.common.jar to convert into a message request body.

[0113] In the embodiment, step S4 can further include the following steps.

[0114] S41, the number of items to be expanded is obtained from the response result returned from the interface of the previous query class, and the number of fields to be expanded in the response result obtained by the interface query in the previous step is taken as the number of items to be expanded.

[0115] For example, it can be implemented by using the beanshell script syntax in Meterstphere: ${id_matchNr}.

[0116] S42, an integer parameter is declared, and the result of the previous step is assigned to the integer parameter.

[0117] For example, it can be implemented by using int num = ${id_matchNr}.

[0118] S43, the data result returned from the interface of the previous query class is taken as the parameter and transmitted to the getJSONStr method in the encapsulation class JsonItemExpander to convert into a message request body.

[0119] The headName, itemName, headMap, itemMap defined in step S1, the Map value valueMap generated in step S3, and the expansion number num obtained in step S4 are taken as the parameters and transmitted to the getJSONStr method in the encapsulation class JsonItemExpander to convert into a complete message request body.

[0120] For example, the code can be implemented as follows:

[0121] int num = ${id_matchNr};

[0122] String newStr = JsonItemExpander.getJSONStr(headMap,

[0123] itemMap, num, valueMap);

[0124] return newStr;

[0125] Step S5, run the interface test case to output the message request body after the item is expanded.

[0126] In this embodiment, step S5 can further include the following steps:

[0127] S51, convert the message request body into a string that can be recognized by Meterstphere.

[0128] MeterSphere supports data exchange formats such as JSON and XML. If the message is in JSON format, Java libraries such as Jackson or Gson can be used to parse and generate strings. These libraries can serialize Java objects into JSON strings or deserialize JSON strings into Java objects.

[0129] In Java or other supported programming languages, write logic to parse the message request body and convert it into a string. Ensure that all necessary fields are properly processed and converted.

[0130] Send the converted string to MeterSphere for testing to verify whether it can be correctly parsed and processed. If problems are encountered, debug and adjust according to the MeterSphere logs or error information.

[0131] S52, run the interface test case to output the message request body after the item is expanded.

[0132] Running the interface test case to be tested will automatically obtain the message after expansion. The output results have been stored in the background console and can be used in the next step to call the overall message request body xxx using ${xxx}.

[0133] Step S6, set the output message request body into the Meterstphere parameter.

[0134] In this embodiment, step S6 can further include the following steps:

[0135] S61, extract the message string variable req_array from the message request body.

[0136] The above steps S1 to S4 are all in the custom static method isVal() (code structure: public static String isVal() {S1, S2, S3, S4}), so the complete message generated by step S4 needs to be extracted and set into the string variable req_array.

[0137] This can be achieved by using the following syntax: String req_array = isVal().

[0138] S62, set the message string variable req_array to the parameter jsonReqArray recognized by Meterstsphere.

[0139] For example, the code can be used to achieve:

[0140] vars.put("jsonReqArray", req_array);

[0141] In some optional implementations of the embodiment, step S6 can further include the following steps:

[0142] S7, call the message request body.

[0143] The next interface request body can directly call the message request body by using ${jsonReqArray}.

[0144] For example, the complete usage sample code can be:

[0145] import java.util.*;

[0146] import com.ly.mp.ms.common.*;

[0147] public static String isVal(){

[0148] / / Step 1: define which keys and values of the message interface need to be parameterized. A value: key value is: "XXXX":"${XXXX}"; multiple values: key value is: "XXXX":"XXXX_ALL"

[0149] String headName = "head"; / / leave blank if not needed

[0150] String itemName = "items"; / / Required

[0151] HashMap headMap = new HashMap();

[0152] headMap.put("waybillNo", "${waybillNo}");

[0153] headMap.put("driverName", "Zhang San");

[0154] headMap.put("identityId", "34567");

[0155] headMap.put("contactInformation", "13622222222");

[0156] headMap.put("carPlate", "Guangdong A12345");

[0157] headMap.put("carTrailer", "Guangdong A12345");

[0158] headMap.put("carType", "TRUCK-B");

[0159] headMap.put("expectedArrivalDate", "2024-01-04 13:00:00");

[0160] headMap.put("status", "4");

[0161] HashMap itemMap = new HashMap();

[0162] itemMap.put("waybillNo", "${waybillNo}");

[0163] itemMap.put("containerNo", "containerNo_ALL");

[0164] itemMap.put("id", "id_ALL");

[0165] itemMap.put("status", "3");

[0166] itemMap.put("pickQuantity","pickQuantity_ALL");

[0167] itemMap.put("realityPickTime","${__timeShift(yyyy-MM-dd HH:mm:ss,,,,)}");

[0168] itemMap.put("deliverQuantity","");

[0169] itemMap.put("deliveryArrivalTime","");

[0170] / / Step 2: Retrieve the strings of the fields that need to be expanded and parameterized from all items.

[0171] String id_ALL=vars.get("id_ALL");

[0172] String containerNo_ALL=vars.get("containerNo_ALL");

[0173] String planQuantity_ALL=vars.get("planQuantity_ALL");

[0174] / / Step 3: Add the strings of the fields in the item that need to be extended and parameterized to the Map. Keep the strings in quotes consistent with the definition. Then, retrieve the multiple matching results from the previous step.

[0175] HashMap valueMap=new HashMap();

[0176] valueMap.put("id_ALL",id_ALL);

[0177] valueMap.put("containerNo_ALL",containerNo_ALL);

[0178] valueMap.put("pickQuantity_ALL",planQuantity_ALL);

[0179] / / Step 4: Obtain the number of items to be expanded from the response result, and pass the parameters obtained in the above 4 steps to the wrapper class.

[0180] int num = ${id_matchNr} ;

[0181] String newStr = new String(req_array) ;

[0182] JsonItemExpander.getJSONStr(headName, itemName, headMap, itemMap, num, valueMap) ;

[0183] return newStr ;

[0184] }

[0185] / / Fifth step: output the message after expanding the item

[0186] String req_array = isVal() ;

[0187] / / System.out.println("jsonString=" + req_array) ;

[0188] log.info("req_array===" + req_array) ;

[0189] / / Sixth step: set the output message character into the MS parameter

[0190] vars.put("jsonReqArray", req_array) ;

[0191] / / Seventh step: the next interface request body directly calls ${jsonReqArray} for use.

[0192] It should be emphasized that, in order to further ensure the privacy and security of the above generated message request body information, the above generated message request body information can also be stored in a blockchain node.

[0193] The blockchain referred to in the present application is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. Blockchain, in essence, is a decentralized database, which is a series of data blocks associated using cryptographic methods, each data block containing a batch of network transaction information for verifying the validity (anti-fake) of the information and generating the next block. The blockchain can include a blockchain underlying platform, a platform product service layer and an application service layer.

[0194] The embodiment is implemented, and beneficial effects are that: by adding a custom script in interface testing, defining an interface template, and automatically expanding item details and generating a complete message body request according to the number of items of the obtained interface response in the previous step, the interface automation case is more flexible, does not depend on fixed design data, and can be directly run normally by automatically matching different data; more business scenarios are automatically tested according to different business data, so that the scenario coverage of the automation test case is more comprehensive.

[0195] The application can be used in many general or specific computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The application can be described in the general context of computer-executable instructions executed by a computer, such as a program module. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The application can also be practiced in a distributed computing environment in which tasks are performed by remote processing devices connected by a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0196] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by computer-readable instructions instructing related hardware, and the computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above-mentioned embodiments of each method. Among them, the storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0197] It should be understood that although each step in the flowchart of the accompanying drawings is displayed in sequence according to the direction of the arrow, these steps are not necessarily executed in sequence according to the direction of the arrow. Unless otherwise stated herein, the execution of these steps is not strictly limited in sequence, and they can be executed in other orders. Moreover, at least part of the steps in the flowchart of the accompanying drawings can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence is not necessarily sequential, but can be alternately executed with other steps or sub-steps or stages of other steps.

[0198] Example Two

[0199] Further reference Figure 3 As a response to the above Figure 2 The present invention provides an embodiment of a device for generating a message request body, which is similar to the method shown. Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0200] like Figure 3 As shown, the message request body generation device 70 described in this embodiment includes: a definition module 71, an acquisition module 72, an addition module 73, a calling module 74, an output module 75, and a setting module 76.

[0201] in:

[0202] Define module 71, which is used to define the keys and values ​​of the interface to be tested, as well as the fields that need to be parameterized;

[0203] Module 72 is used to retrieve the parameterized fields in an item that corresponds to multiple detail rows in a main order;

[0204] Add module 73, which is used to add the strings of the fields that need to be extended and parameterized in the item to the data structure Map used to store key-value pairs;

[0205] Module 74 is called to obtain the number of items to be expanded from the response result returned by the interface of the previous query class. It extracts parameters by matching multiple data through Metesphere, takes the data result returned by the interface of the previous query class as the parameter, and passes the obtained parameter to the encapsulation class JsonItemExpander. It calls the encapsulation class JsonItemExpander through the imported ly.mp.ms.common.jar to convert it into a message request body.

[0206] Output module 75 is used to run test cases of the interface to be tested and output the message request body after expanding the item;

[0207] The setting module 76 is used to set the output message request body into the Meterstphere parameter.

[0208] The beneficial effects of implementing this embodiment are as follows: by adding a custom script to the interface test, defining the interface template, and automatically expanding the item details based on the number of items obtained from the previous interface response, a complete message body request is generated; this makes the interface automation test cases more flexible, does not rely on fixed design data, and can automatically match different data to run normally; and it automates the testing of more business scenarios based on different business data, making the automation test cases cover more comprehensive scenarios.

[0209] Example Three

[0210] To address the aforementioned technical problems, embodiments of the present invention also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0211] The aforementioned computer device 8 includes a memory 81, a processor 82, and a network interface 83 that are interconnected via a system bus. It should be noted that only the computer device 8 with components 81, 82, and 83 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0212] The aforementioned computer devices can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. These devices can facilitate human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0213] The aforementioned memory 81 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the aforementioned memory 81 may be an internal storage unit of the aforementioned computer device 8, such as the hard disk or memory of the computer device 8. In other embodiments, the aforementioned memory 81 may also be an external storage device of the aforementioned computer device 8, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 8. Of course, the aforementioned memory 81 may also include both the internal storage unit and its external storage device of the aforementioned computer device 8. In this embodiment, the aforementioned memory 81 is typically used to store the operating system and various application software installed on the aforementioned computer device 8, such as computer-readable instructions for generating message request bodies. In addition, the aforementioned memory 81 can also be used to temporarily store various types of data that have been output or will be output.

[0214] In some embodiments, the processor 82 described above may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 82 is typically used to control the overall operation of the computer device 8. In this embodiment, the processor 82 is used to execute computer-readable instructions stored in the memory 81 or to process data, for example, to execute computer-readable instructions for the method of generating a message request body.

[0215] The network interface 83 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 8 and other electronic devices.

[0216] The beneficial effects of implementing this embodiment are as follows: by adding a custom script to the interface test, defining the interface template, and automatically expanding the item details based on the number of items obtained from the previous interface response, a complete message body request is generated; this makes the interface automation test cases more flexible, does not rely on fixed design data, and can automatically match different data to run normally; and it automates the testing of more business scenarios based on different business data, making the automation test cases cover more comprehensive scenarios.

[0217] Example Four

[0218] The present invention also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the method for generating a message request body as described above.

[0219] The beneficial effects of implementing this embodiment are as follows: by adding a custom script to the interface test, defining the interface template, and automatically expanding the item details based on the number of items obtained from the previous interface response, a complete message body request is generated; this makes the interface automation test cases more flexible, does not rely on fixed design data, and can automatically match different data to run normally; and it automates the testing of more business scenarios based on different business data, making the automation test cases cover more comprehensive scenarios.

[0220] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0221] Obviously, the embodiments described above are merely some embodiments of the present invention, not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the patent scope of the present invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the patent protection scope of this invention.

Claims

1. A method for generating a message request body, characterized in that, Includes the following steps: S1. Define the keys and values ​​of the interface to be tested, as well as the fields that need to be parameterized; S2. Retrieve the parameterized fields from an item that corresponds to multiple detail rows in a main order; S3. Add the strings of the fields that need to be extended and parameterized in the item to the Map data structure used to store key-value pairs; S4. Obtain the number of items to be expanded from the response result returned by the interface of the previous query class. Extract parameters by matching multiple data through Metersphere. Use the data result returned by the interface of the previous query class as the parameter and pass the obtained parameter to the encapsulation class JsonItemExpander. Call the encapsulation class JsonItemExpander through the imported ly.mp.ms.common.jar to convert it into a message request body. S5. Run the test case of the interface to be tested and output the message request body after expanding the item; S6. Set the output message request body into the Metersphere parameters; Step S1 further includes: S11. Define the overall structure identifier of the message request body; S12. Create two HashMap key-value pair data structures, head and items, respectively, and add the message fields to be generated into the key-value pairs; Step S2 further includes: S21. How to retrieve multiple detailed data entries from the previous step's interface query results using Metersphere's beanshell script syntax; S22. By declaring a character variable, the parameter value obtained in the previous step is passed to the character variable; Step S3 further includes: S31. Create a HashMap key-value data structure that requires the parameterized fields to be extended; S32. Add the fields that need to be extended with parameterization to the key-value pairs; Step S4 further includes: S41. Obtain the number of items that need to be expanded from the response result returned by the interface of the previous query class, and take the number of fields that need to be expanded in the response result of the previous query as the number of items that need to be expanded. S42. Declare an integer parameter and assign the result of the previous step to the integer parameter; S43. Pass the data result returned by the interface of the previous query class as a parameter to the getJSONStr method in the encapsulation class JsonItemExpander, and convert it into a message request body; Step S5 further includes: S51. Convert the message request body into a string that Metersphere can recognize; S52. Run the test case of the interface to be tested and output the message request body after expanding the item.

2. The method for generating a message request body according to claim 1, characterized in that, The step S6, setting the output message request body into the Metersphere parameters, specifically includes: S61. Extract the message string variable req_array from the message request body; S62. Set the message string variable req_array to the parameter jsonReqArray that Metersphere can recognize.

3. An apparatus for generating a message request body, implemented using the method for generating a message request body as described in claim 1, characterized in that, include: Define the module to define the keys and values ​​of the interface to be tested, as well as the fields that need to be parameterized; The retrieval module is used to retrieve the parameterized fields from an item that corresponds to multiple detail rows in a main order; The module is used to add the strings of the fields in the item that need to be extended and parameterized to the Map data structure used to store key-value pairs; The calling module is used to obtain the number of items to be expanded from the response result returned by the interface of the previous query class. It uses Metersphere to match multiple data to extract parameters, takes the data result returned by the interface of the previous query class as parameters, and passes the obtained parameters to the wrapper class JsonItemExpander. The wrapper class JsonItemExpander is called through the imported ly.mp.ms.common.jar to convert it into a message request body. The output module is used to run the test cases of the interface to be tested and output the message request body after expanding the item. The configuration module is used to set the output message request body into the Metersphere parameters.

4. A computer device comprising a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the method for generating a message request body as described in any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the method for generating a message request body as described in any one of claims 1 to 2.

Citation Information

Patent Citations

  • Test case generation method and device, storage medium and electronic device

    CN117687903A

  • Software development platform using method

    CN118035107A