JMeter Study -016-thought article--mountain heavy water complex steady

First of all, this article is a non-technical blog post, for the idea of class blog, please see, Welcome to discuss together!

Today in the writing of JMeter interface monitoring script, encountered a problem, in the resolution of the problem, the idea of a deviation, resulting in their own problems, around the bend, wasting some time. In other words, it was his thinking that solved the problem at that time, there is no time flexibility, dwarfish the ^_^. The specific problem scenario is as follows.

In the daily test development work, the test script corresponds to a lot of scenes, and the essential scene is the important status code verification. At this point, different status codes correspond to different page display, and subsequent different business logic processing operations, so the test script needs to respond to different requests corresponding to the different status code to determine the status code changes after the previous operation is correct, if correct can continue to perform subsequent related validation operations, Otherwise, the subsequent associated operation is terminated, and the notification is sent to the relevant members of the product group for timely processing. So how to obtain and judge the status code is correct or not? The following is an example of an order status code in the e-commerce website, which describes the idea of how I solved the problem at the time, with the following steps:

The first type: The verification code is directly judged by the assertion

How to: Get a list of orders and set up response assertions directly.

This way of judging is very simple, just set the assertion in the request response. However, this method of judgment has a very restrictive condition (all order statuses returned in the order list are not allowed to have the same status), otherwise this judgment cannot be determined to determine whether the order status is correct (to determine if the order's status is not the desired state, while the status of the other order has the desired state, then this method is wrong).

Second: The order list is obtained after the order status through the logical controller and so on to determine

How to: Get a list of orders, get the order status of the corresponding order through the regular expression extractor (get the status method through the regular extractor, see the previous blog post: Single parameter fetch, multi-parameter fetch, multi-parameter reference), and then through the Bean Shell assertion, BSF assertion and other ways to determine the status of the order, verify that it is in line with the expected, so that the logical controller control whether to perform subsequent operations.

This kind of judgment way is slightly complicated, and need certain script Foundation, suggest friends to study, raise oneself of script ability.

Third: The order status is determined by an assertion after it has been acquired in the orders list

How to do this: obtain order information through a regular extractor, such as a character that precedes the order's status from the order number, and then stitch the desired status to set the stitched string as an assertion. For example, the order data information is as follows:

{"errno": 0, "data": {"Single_coupon": "", "Cash_per_month": 0, "order_id": "34567890", "order_char_id": "1234567890", " Status ": -2," Receiver_tel ":" "," receiver_addr ":" Huaxia "," Receiver_mobile ":" 1234567890 "," Shipping_cost ": 0," shop_guide _cost ":" 0 "," Businessid ": 2," Dealtype ": 2," Buy_total ": 3," Order_cost ": 14700," Coupon_code ":" "," Coupon_amt ": 0," Porderid ":" 0101234567890 "," Subordernum ": 0," suborderids ": []}

The regular expression corresponding to the regular extractor is:

order_id ":" ${order_id} "," order_char_id ":" 12${order_id} "," Status ":

the template corresponding to the regular extractor is: $0$

The final order information obtained is: order_id ":" 34567890 "," order_char_id ":" 1234567890 "," status ":

The asserted information is (assuming the order status at this time is: 4): order_id ":" 34567890 "," order_char_id ":" 1234567890 "," Status ": 4

This method is similar to the second method, except that the extraction domain (the second one is a separate order state, the order information is taken here), the judging method (the second is judged by other means, the assertion is used directly here), this kind of simple, recommended.

Fourth: Judging by order detail data

How to do this: request the order details of the corresponding order, directly set the response assertion (ex: "Status": 4) to judge.

This kind of judgment, same concise, also only need to set the assertion in the request response, and guarantee the uniqueness of the order, there is no other order interference situation occurs, it is recommended to take this approach.

PS: In the process of solving the problem, but also tried other methods of verification, here is no longer one by one to repeat, the above is my own thought of more effective way to share to everyone. If there is a better way, welcome to inform, greatly appreciated!

At this point, JMeter Learning -016-thought article-Mountain heavy water complex steady smooth end, hope this article can give beginners JMeter you a reference.

Finally, very grateful to the pro-stop, I hope this article can be pro helpful. Warmly welcome the kiss to discuss together and progress together. Thank you so much! ^_^

JMeter Learning -016-thought article-Mountain heavy water complex steady