I am using Selenium to perform client-sided testing of a specific browser on an AngularJS web application. I want perform a load test by sending many request from concurrent users. For example, 1k request in a second from x amount of users, 2k request, etc.
There is no formal documentation on this topic. Has anyone done this before? Is there an (expected) maximum amount of request Selenium can perform, I know it would be dependant on hardware. I also know there exist tools such as Jmeter, but those do not run client-side JavaScript.
JMeter doesn't run client-side JavaScript but in order to simulate 2k concurrent users you simply don't need to run it. If JavaScript is generating some network traffic - your will be able to mimic it using normal JMeter's HTTP Request samplers. Client-side performance, i.e. script(s) execution timeline should be tested separately using JavaScript Profilers and/or tools like YSlow
Also be aware that Selenium can be integrated with JMeter via WebDriver Sampler plugin.
Alternatively you can consider LoadRunner TruClient, however both approaches which kick off real browsers (no mater full or headless) will be very resources intensive.
Related
I am using selenium to test an application, I am starting my browser normally but at some point, I need to switch to offline mode, so far I saw several posts saying that is not possible using selenium unless you start the driver in offline mode ( which is not my case ).
I am using C# and Selenium, and I have planned to integrate my project to run it remotely.
Do you know if there is a way to switch the browser to offline mode using Javascript? or any other method?
You could integrate a Service Worker into your application and coordinate with it to either pass through requests as usual, or, if you flag it to do so, drop all requests and simulate failures.
Service Workers essentially act as a proxy for all requests and you can choose how to handle them (e.g. cache them, refresh data from the server, or simply deny the requests).
I'm working on a project in which I have to develop a simple PHP based web module from where the user (admins) can send SMS messages (Followup) to students, as for the sake of advertisement and other needs.
The SMS API is very simple and I just need to send a GET request to a Cross Origin Domain along with the phone number and message.
I tested it with the file_get_contents("sms_api_url?credentials"); and it works fine.
What worries me is that the SMS will be sent to TONS of numbers and so I have to send the request multiple times using a loop, which will take a lot of time and I think will be too much resource consuming.
Also the max execution time for PHP is set to 30 seconds which I don't want to change.
I thought to use the Client side JavaScript for sending cross origin request in a loop so that it wont affect my server but that wouldn't be secure as it would reveal the API credentials.
What Technology should I use to accomplish my goals? and send tons of get request efficiently?
You've told us nothing about the the actual volume you need to handle, the metrics for the processing/connection time nor what constraints there are on the implementation.
As it stands this is way too broad to answer. But some approaches you might consider are:
1) Running concurrent requests - but note that just like domain sharding, this can undermine your bandwidth if over used
2) You can have PHP scripts running indefinitely outside the webserver (using the CLI SAPI) and these can be launched from a web session.
I thought to use the Client side JavaScript for sending cross origin request in a loop so that it wont affect my server but that wouldn't be secure as it would reveal the API credentials.
If you send directly to the endpoint, then yes, you'd need the credentials in the browser. But if you implement a proxy script which injects the credentials on your webserver then you can use your own credentials from the browser.
Using cron has certian advantages - but you really don't want to be spawning a task from crond to send one SMS message - it needs to run in batches, and you need to manage the concurrency.
You might want to consider switching to a different aggregator whom can offer bulk processing.
Regardless of the aproach you will need a way to store the messages/phone numbers and a locking mechanism around retrieval processing.
Personally, I'd be tempted to look at using an MTA for this or perhaps even Kannel - but that's more an approach for handling volumes in excess of 300,000 per day.
To send as many network requests as needed in less than 30 seconds are two requirements that kind of contradict themselves. Also, raw "efficiency" can just mean squeeze every single resource in the server, which not may be desirable.
Said that, I think the key points are:
I may be wrong but, as far as I know, there're only two ways to prevent a non-authorised party from consuming a web service: private credentials and IP filtering. None are possible in browser-based JavaScript.
Don't make a human being stare in front of the computer until a task of this kind completes. There's absolutely no need to and it can even cause the task to abort.
If you need to send the same text to different recipients, find out whether the SMS provider has an API that allows to do it in a single API request. Large batch deliveries get one or two orders of magnitude harder when this feature is not available.
In short you need:
A command line script
A task scheduler (e.g. cron)
Prefer server stability to maximum efficiency (you may even want to throttle your requests)
Send the requests from the server, but don't do it in the PHP script that generates the page.
Instead, store information about the desired messages in a database.
Write another program which, periodically, checks the database for unsent messages and makes the call to the API. You could run it using cron.
I am trying to checkout using PayPal in sandbox environment in my script in JMeter.
It throws an error in the response tree as were sorry, but to checkout using PayPal, you need to turn on javascript and enable cookies in your web browsers settings.
Load testing PayPal is not the best idea, I would recommend leaving it to PayPal QA engineers and focus solely on your application. Even if you figure out that PayPal operations are slow - I don't think you will be able to do anything with it.
In regards to your question itself: well-behaved JMeter test must represent a real user using real browser as close as possible with all related stuff (cookies, headers, cache, think times, etc.). So first of all add HTTP Cookie Manager to your Test Plan.
Also be aware that according to JMeter main page:
JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does
So if the application you're testing is built using AJAX technology don't expect JMeter to create and send JavaScript-driven requests, you will need to add HTTP Request samplers to mimic them.
Check out How to make JMeter behave more like a real browser article for more tips and tricks
Is there a way to send data packets from an active Python script to a webpage currently running JavaScript?
The specific usage I'm looking for is to give the ability for the webpage, using JavaScript, to tell the Python script information about the current state of the webpage, then for the Python script to interpret that data and then send data back to the webpage, which the JavaScript then uses to decide which function to execute.
This is for a video game bot (legally), so it would need to happen in real time. I'm fairly proficient in Python and web requests, but I'm just getting into JavaScript, so hopefully a solution for this wouldn't be too complex in terms of Javascript.
EDIT: One way I was thinking to accomplish this would be to have Javascript write to a file that the Python script could also read and write to, but a quick google search says that JavaScript is very limited in terms of file I/O. Would there be a way to accomplish this?
For security reasons, javascript in a browser is usually restricted to only communicate with the site it was loaded from.
Given that, that's an AJAX call, a very standard thing to do.
You can make HTTP requests using the XMLHttpRequest API, which Jquery abstracts with $.ajax and $.get. You can also use the lower level Websockets network API:
https://developer.mozilla.org/en-US/docs/WebSockets
Note that the XMLHttpRequest API will only allow requests to the same server, OR requests that return an appropriate Access-Control-Allow-Origin header.
It sounds like the Javascript is only going to send information, not receive any. In that case, you're in luck. I'm guessing you are also running the Javascript and the Python on the same machine.
Run a Python webserver on the machine the browser is running on. Here's a simple example:
http://webpy.org/install
Once visiting http://127.0.0.1:8080/ in your browser gives the message Hello World!, you can start adding more addresses to your website, for example http://127.0.0.1:8080/report_data, http://127.0.0.1:8080/report_event etc.
Your Javascript can then make AJAX requests using jQuery.ajax or XMLHTTPRequest, to the address http://127.0.0.1:8080/report_data, and pass the information as GET parameters.
While I was developing some web apps, to me it became optimal to use a web service to interact with the server, and the rest I was enjoying to do with client side (JQuery). but when I was testing my code, I encountered a huuge hole in it, and i don't know how to prevent it.
The problem is that I can easily inject javascript and run any functions including webmethods from firefox's firebug tool.Is it a something known, and what should be done to prevent it.
THank you
This is not a hole at all. The client can only run JavaScript code on the page that they have downloaded from you on their own computer. It has no affect on your site at all.
As for the ability for them to make requests via JavaScript -- well, they can make requests via the browser too. What's the difference? Just make sure that your server properly validates all requests -- it should treat any request as if it were as malicious as possible.