I'm running on Windows 10 with the latest version, 7.21.1. I imported the example collection featured in their documentation - https://learning.postman.com/docs/postman/collection-runs/building-workflows/. I run Request 1 in the collection through the Runner and Request 4 does not trigger as it seems it should. It is setup in Tests and seems correct based on their documentation. I have my own collection I was trying this with, but when it was not working I then tried this sample and realized there was something else amiss.
Any assistance would be helpful! I can provide more information if needed.
This is what the example collection has in Request 1 under Tests: postman.setNextRequest('Request 4');
Thanks!
I figured this out. I didn't understand the flow of how the operation worked or the flow of runner. All requests that could be called next need to be selected in runner. And this operation works like a goto where all requests after the request that is run next all run. Closing this out.
Related
I did NOT see below request in my webtest, however it is being executed and failing.
I know this is a coding issue and it has to be fixed by development team , however I want to skip running this request for now and make my test pass. Please help me.
GTE https://www.corteva.com/etc/designs/default.css
Webtest:
Results:
You can set Parse Dependant Requests to false for corresponding request (e.g. https://www.corteva.com).
Ignore unimportant errors in web test
I've been evaluating moving our Mapping and Routing apps to use HERE's Rest API. I've been testing some scenarios to proof it out and one I can't seem to get working correctly is the Batch Geocoding.
The submission of the data to Geocode works fine and I do get a valid RequestID back but when I poll for the status of the Batch Job the status always says "accepted" but never seems to change.
I am using a developer account that has a 90 day trial. Could there be a limitation due to the type of account?
Looks like it's a queue issue, except mine has been going on for nearly a week.
HERE API never runs batch job, always returns accepted status
I am trying to load test Nginx installed on an EC2 instance via Jmeter, Everytime I try to load test, only 50% request are successful,
For Eg:
If I try with 10 users, only 5 response are OK
If I try with 100 users, only 50 response are OK
If I try with 500, only 250 response are OK
Any Idea, regarding this strange behavior?
This sounds weird. I would recommend the following troubleshooting techniques:
First of all always check jmeter.log file, it should contain enough information to get to the bottom of your test failure(s).
If JMeter log file doesn't contain any suspicious entries next step would be checking response messages using i.e. View Results In Table and/or View Results Tree listener. This should provide you some high-level information and trends, i.e. you will be able to see if some particular sampler(s) is(are) always failing.
If above steps don't give enough clue to resolve your issue you can temporary enable saving of request and response data to see what is wrong with the failing sampler(s). Add the next lines to user.properties file (located in JMeter's "bin" folder)
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data=true
jmeter.save.saveservice.samplerData=true
jmeter.save.saveservice.requestHeaders=true
jmeter.save.saveservice.responseHeaders=true
jmeter.save.saveservice.url=true
and next time your run JMeter test the .jtl results file will contain all the relevant data which can be analyzed using aforementioned View Results Tree listener. Don't forget to revert the change once you fix the script as JMeter listeners are very resource intensive per se and above settings greatly increase disk IO and it may ruin your test.
If none of above helps - check logs on the application under test side, most probably you will get something from them.
I am using Postman to run a Runner on some specific requests. Is it possible to create a schedule to execute (meaning every day on specific hour)?
You can set up a Postman Monitor on your collection, and schedule it to execute the request each minute/hour/weekly basis.
This article can get you started on creating your monitor. Postman allows 1000 monitoring requests for free per month.
PS: Postman gives you details about the responses as in No. of successful requests, response codes, response size etc. I wanted the actual response for my test. So I just printed the response body as shown below. Hope it helps someone out there :)
Well, if there is no other possibility, you can actually try doing this:
- launch postman runner
- configure the highest possible number of iterations
- configure the delay (in milliseconds) to fit your scheduling requirement
It is absolutely awful, but if the delay variable can be set high enough, it might work.
It implies that postman is continuousely running.
You may do this using a scheduling tool that can launch command lines and use Newman ...
I don't think Postman can do it on its own
Alexandre
EDIT:
You may do this using a scheduling tool that can launch command lines and use Newman ... I don't think Postman can do it on its own
check this postman feature : https://www.getpostman.com/docs/postman/monitors/intro_monitors
from postman v10.2.1 onwards you can schedule your collections to run directly (without using monitors) on the specified times
check out here - https://learning.postman.com/docs/running-collections/scheduling-collection-runs/
I'm running into an unusual situation that I can't get to the bottom of.
We have a rails 4.1 application running on jRuby 1.7.12 inside Torquebox 3.1.0. One of the API endpoints retrieves a list of objects.
Currently the database has just under 7000 records in. When an API request is made, these are queried and rendered in JSON using the ActiveModel::Serializersgem. This all works as we'd expect, and doing this in a rails console, it works perfectly.
The problem lies when making an actual API request. It seems to work as expected, and looking at the rails log, there is the output
Completed 200 OK in 6354ms (Views: 5479.0ms | ActiveRecord: 867.0ms)
At this point, I expect to see the data returned from the server, however it takes a good 2.7 minutes to actually see a response from the server. I've tried making the request from Chrome, Safari and even in curl just to make sure it's not a weird browser issue but not having any luck.
I've implemented some caching within the serialisers as described here. I'm pretty sure this isn't the issue however as it works as expected in a console, so I'm really confused.
What else could be going on that is causing the 2+ minute delay. During this time I'm seeing around a 100% CPU usage for Java, so something is definitely going on.
Well it turns out it was the bullet gem taking up all the time. It seems that with that many records, detecting whether there is an N+1 query is quite time consuming. Simply disabling bullet reduces the time to exactly what the rails console says it is.