For one of my Requests in jmeter, I am getting Response code as 200 OK but Response body is NULL.
Due to this "Response Assertion" is failing since we are expecting Response to generate.
Here i am unable to get as to why the status code is 200 even though Response body is null.
Sampler result showing Response status as 200
Response Data SS
Response assertion
If you're expecting HTTP Status Code to be 200 and not interested in the body - amend your Response Assertion configuration as follows:
Fields to Test: Response Code
Pattern Matching Rules: Equals
Patterns to Test: 200
This way your assertion will pass.
Check out Response Assertions in JMeter 3.2 - New and Improved article for more information on using Response Assertion to conditionally mark Samplers as passed or failed
If you expect the request to return some body data - then assertion failure is correct and I can think of the following options:
You're sending a malformed request hence not getting a response, cross check the request with the API contract or with the other API testing tools like SoapUI or Postman
There is a bug in your application. Status code 200 doesn't necessarily mean success and vice versa
If the situation happens only under the load it might be the case you found the bottleneck
Related
I'm new using JMeter and I have this case:
Test Plan
Test Group1
Http Request 1
Json Extractor1
BeanShell Assertion1
Http Request 2
Http Request 3
And I want to use the response of HTTP req 1(extracted in JSON extractor) in both HTTP request 2 and 3. For request 2 is working fine I just use ${response} and works fine but when I try to user the same variable in request 3 is like is empty is not showing anything.
So I tried to put the BeanShell Assertion and do a var.set or even a set property, but is still not working. It is like the var or property is being set, and I can see them in HTTP req 2 but in HTTP req 3 they are empty.
Is there another way to set the variable or the response of the request 1 to be use in any other requests of the same thread?
Thanks
You need to amend your test design and make the JSON Extractor a child of the Http Request 1
Test Plan
Test Group1
HTTP Request 1
JSON Extractor
HTTP Request 2
HTTP Request 3
If you have JSON Extractor at the same level as HTTP Requests 1-3 it's being executed after every of them so it tries to extract the value from HTTP Request 2 response, doesn't find it and the variable gets empty or default value.
The same applies to the Beanshell Assertion.
More information: JMeter Scoping Rules
With regards to using Beanshell in general it's not very recommended, since JMeter 3.1 you should be using JSR223 Test Elements and Groovy language
I've done a fair bit of research, but I can't find anything conclusive on what HTTP response to send in the case that there are no results to be returned.
Ie. The request was correctly formed, no errors occurred, we took a trip to the database and came back empty handed...there just isn't any data to return.
Should I return a 200 and an empty result set?
The only HTTP response that seems close is 204, but it doesn't allow for a Message body. None of the error codes (400 or 500 level) seem accurate to the situation.
I have some validations in my Rest API that will return 400 bad request. I have added test cases in JMeter for these, however the Listeners (e.g. Tree view) show these as unsuccessful (Error Icon) because JMeter did not receive a 200 response. Is there a way to indicate for a given HTTP request that 400 is the expected result. I can add an assert but the tree view display still shows the red error icon.
You verify the Response Code, 400 and the Response Message,bad request with Response Assertions.
Add two Response Assertions to the HTTP Request where you need to verify the error.
Let's say you want to verify the response code first. Select Field to Test as Response Code in the first Response Assertion. Select the Ignore Status field. Set the Pattern Matching Rules as Equal. Click Add button and type the response code to verify, 400.
Please ensure the Ignore Status is selected only in the first assertion.
In the second Response Assertion we shall verify the response message. Select the Field to Test as Response Message, Pattern Matching Rules as Contains, click the Add button and the add the regular expression to check.
You're getting the error because JMeter automatically treats responses with HTTP Status Codes above 399 as failures.
If you expect HTTP Status Code 400 and would like to mark the request(s) as passed - add a Response Assertion and configure it to check that response code equals to 400 and additionally tick "Ignore Status" box:
Why validation response code and unathuntication status code is 200(ok) instead of 422 and 401 ?
how can i find request is failed to show error to users when all response codes are 200?
Have a look at this thread for an explanation why it's 200 always: https://github.com/nuwave/lighthouse/issues/279
I have to write an application which serves HTTP request.
For these requests application has to send the response content with status**.
Status is integer which represents status code.( 1 : Session Expired, 2: Invalid Request Data. etc,.)
There are 2 options.
One is to send the status code with content itself:
Ex : {status : 56, content: [{name:'pinto', id: 90}]}
Another one is specifying the status code in header itself, so that once I receive the header from client if status states the there is an error I can abort the request so that I don't have to receive the response body and process it.
I think second option will be better than first one, because
No need to get for the response content which is very much helpful in case of content is large.
Is this is recommended solution or any other suggestions ?
You should be using HTTP status codes for this kind of thing.
Session Expired: 401 Unauthorized - authentication is possible but has failed
Invalid Request Data:
400 Bad Request - request cannot be fulfilled due to bad syntax
405 Method Not Allowed - request method not supported by that resource
409 Conflict - request could not be processed because of conflict
413 Request Entity Too Large - request is larger than the server is willing or able to process
422 Unprocessable Entity - request unable to be followed due to semantic errors