i'm trying to make an Jmeter request to create administrator from admin user. I get 200 answer back, but actually there is no administrator that was created.
Can you help me with that?
This "HTTP 200" indication of success is a false positive accepted by many performance testers. Think back to testing 101, for each step there is a positive and expected result for the step. If you do not receive that expected result then you should branch your test code and discontinue the execution of your business process.
Take a look at the content within pages being returned for each step. Do not simply accept an HTTP 200 as an indicator of success, because the content on the page may be inappropriate for the condition you expect.
This answer is tool independent as the problem of not checking content crosses users of all performance testing tools and cross protocols.
Related
I have a Parse app and I want to find out which users/installations account for requests. There is a spike in API request activity in my app, and I'm suspicious of some users/devices that may be sending too many requests (either intentionally or due to a bug). How do I find that out? Here is a spike in usage:
There are two ways I know of that you might be able to see what's going on, and what might be causing that massive spike you're seeing.
Head to the Analytics section for your app (that the screenshot you provided was generated from). In the left pane, under Performance, you should see Requests and Queries submenu items. If you click on Queries, and then set the date range to 19th April (when your spike was experienced), you should be able to see the Classes and Queries that generated the traffic. There is a handy count field, so this should give you a clue as to the requests on the server. However, this doesn't tell you who was requesting - just what the requests were - but this information might be useful in tracking down any bugs.
If you want to see what Installations have been generating the most requests, click on "Explorer" in the left pane (this is quite new functionality). From here, you can see specific information about users and requests. There is a handy Saved Query that you can use to see which users have been generating traffic. Click on "Top Installations Yesterday", then change the date range to be the date of your traffic spike, and change "Group By" to be "Parse User ID". Click "Run Query" and you should see the User ID of the user who has been generating the bulk of the traffic at the top.
If the user causing the hassle is anonymous, then I think the User ID will be empty. And if that's what you're seeing, you could have a malicious user on your hands :-(
Hope that helps!
As a team we're currently investigating a strange occurrence. It doesn't seem to apply to all orders by any means, but it is affecting a large number of customers based on the logging we've added to the noItems.phtml page.
Please note: I'm not really expecting an answer as I assume this is a problem we have to solve ourselves based on addons, and our server configuration (three servers for loading balancing). However, I am looking for possible ideas and/or whether this is something somebody has come across previously.
What we've done so far, and what we know:
User enters their card details in the SagePay iFrame;
User purchases an item via SagePay -- order is successful;
Some users are sent back to the success page;
Some users don't see the success page (phoned to confirm a handful) but instead return back to the empty basket;
We're still investigating, but we find it ever so strange how a user would return to the empty basket page. We've added logging to the noItems.phtml and we can see that some users are getting assigned another session ID after a successful transaction. This seems to be the problem, but why the user is being assigned another session ID after a SagePay payment isn't easy to comprehend.
Has anybody else experienced a similar issue with SagePay/Magento? And if so, what steps did you take to solve?
Our Sage Pay Support team would be happy to look at the transaction logs (within 72 hours of the transation being submitted) and help you determine the reason for the failed transactions on 0845 111 4455 24/7.
You reply to the Notification URL when you acknowledge receipt of our response. You have 20 seconds to response. You need to send the Status (OK, Error or Invalid), Status Detail and Redirect URL. We then send the shopper back to your Redirect URL.
A few suggestions would be:
If we can't reach your Notification URL, check you have ports 443 and 80 open. Check you don't have a DNS issue.
If you are receiving the notification from Sage Pay to confirm the status of the transaction via the Notification URL. Check the information you are sending is in the correct casing, that it is not empty data and that your website is not spooling and check whether the success/failure URL is a valid landing page.
All our system needs is the Status Deatil, 'Status = ' and 'RedirectURL =' fields with the appropriate values assigned, separated with Carriage-Return and Line-Feeds (as specified in the protocol) . Nothing else is required. The response you send should also be text/plain message, not text/html or any other MIME type.
If the customer is being sent back to an empty basket, check whether your website is doing a job in the background such as writing to a databse, preparing confirmation emails to the back office before sending the customer to the payment page. Test whether your server can handle the amount of transactions coming through from Sage Pay. Or are you truncating the NEXT URL?
Regarding a session ID, each transaction is assigned a unique Sage Pay ID called a VPSTxID which is used to identify the transaction. We can take a look at the transactions you are referring to if you are getting several session IDs to discuss further if you would like.
Sage Pay Support.
Check the action that pushes the user to the success page on successful purchase. Maybe its something like target _parent. Maybe its something where its trying to load the success page in the iframe. Or maybe its timing out on sagepay when trying to redirect.
For example, when we have new message on http://facebook.com or http://gmail.com, site gives us signal about this, and this happened without refresh page. how it works? I Imagine this so:
some Jhon is registered user on site.
There is javascript code, which every 10 seconds sends AJAX request to messages table, for check: in table, has or not unread messages for john (architecture, how marking ready / unread messages, here not important), if Yes, site give signal to Jhon "You have several new messages".
Tell please, I am closer to the truth or not? If yes, I have also one questions please.
In modern sites we use websockets which enable the server to push information to the browser with less overhead and no delay. That's what's used on SO.
But as some browsers still don't support them, we must sometimes fall back to a pull-loop as the one you describe.
On the server it may be handled with a queue instead of database queries at each browser request. But there are probably many different implementations on this point.
I'm testing an app which accepts payments through Sagepay.
It all seems to be working OK but I would like to test various types of non-successful responses in the Sagepay sandbox.
For example, each test I have done so far has returned a status of OK. It is also possible to receive statuses like REJECTED, NOTAUTHED, INVALID etc
Is it possible to simulate these responses in some way?
Entering incorrect details repeatedly just returns me to the failure URL I specify in the API settings.
If you login to your simulator account on Sagepay via https://test.sagepay.com/simulator/ you can tell it which responses to return. You can instruct it to return random responses, or MALFORMED, INVALID, ERROR, NOTAUTHED, REJECTED, 3DAUTH.
Unfortunately you have to change these through the admin panel and then they apply for each transaction rather than using different details to trigger different responses.
In addition to Steve's answer, if you use the SERVER integration you can click different buttons to SIMUALATE (on the SIMULATOR server) a reply from SagePay gateway.
I'm not typically a web developer, but I'm a decent enough coder that I felt comfortable accepting a proposal from a friend to develop his brother's small business website. I'm nearly finished and I've been using CodeIgniter, which has been a huge help and was easy to jump into.
They have a handful of products they'd like available for purchase via the site, their preference was Auth.net (which I have no previous experience with), and their host does not support SSL (nearlyfreespeech.net), so I decided that Auth.net's SIM was appropriate. If I test SIM outside of the CI application with a relay response page which simply spits out the available transaction details, everything goes as expected. If I try it with the relay response page set to a CI controller/method which simply echoes a string, Auth.net displays the following 'error':
An error occurred while trying to
report this transaction to the
merchant. An e-mail has been sent to
the merchant informing them of the
error. The following is the result of
the attempt to charge your credit
card.
This transaction has been approved.
It is advisable for you to contact the
merchant to verify that you will
receive the product or service.
My initial thought was that perhaps the rewrite rule I set up to circumvent having to include the index.php front controller was the issue, so I tried including it in the relay response URL with no change. I should also note that the controller in question implements a _remap() method, but the relay response method shouldn't be affected by it as it doesn't match it's regex.
Any insight(s) would be greatly appreciated.
This error occurs when your script doesn't respond within a specified amount of time. It also is displayed if anything other then a 200 success message is returned. So basically there is an error in your relay response URL.
You need to test this first by pulling up the page directly to see if it works and returns the proper header response. Then you can test it by sending a simulated POST response to it and see if it also responds properly. If those work make sure the script isn't taking too long to respond. If it is there probably are ways to optimize the slow page to give the response in the appropriate amount.