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
Related
I have recorded the JMeter script from blazemeter. It is working fine in website. When i run the jmx file Its throwing an error below..
"alert("Something went wrong. Please try again");window.history.back();"
This is the issue with JMeter script or application. I am getting response from server 200.
Most probably your script lacks correlation of the dynamic parameters (or it's not working properly)
In the majority of cases you won't be able to just replay recorded script, modern web applications heavily rely on dynamic parameters for establishing user session, tracking client side state, security reasons and so on.
So you need to identify all the parameters, extract them using suitable Post-Processors and replace recorded hard-coded values with the JMeter Variables originating from the Post-Processors.
And don't forget to add HTTP Cookie Manager to your test plan if it's not there yet.
I am using Server side GTM, but I am facing adblocking issues when calling the below request when I want to retrieve the gtm?js file:
https://example.gtmdomain.com/gtm.js?id=GTM-MY_GTM_ID
The request works fine when I don't use adblockers.
Is there a way to rename the endpoint to something else, such as https://example.gtmdomain.com/secret_file_name.js?id=GTM-MY_GTM_ID in order to not be blocked by adblockers?
So. Server-side gtm is exactly what it says. It's executed on the server. It listens for network requests. It doesn't have any exposure to what happens on the front-end. And the front-end has no clue about there being a server-side GTM. Well, unless there are explicit calls to its endpoint, which you can proxy with your backend mirrors when needed.
What you experience is adblockers blocking your front-end GTM container. Even though it's theoretically possible to track all you need, including front-end events with server-side GTM, it's considered to be the best practice to use both GTMs and stream front-end events to back-end GTM through front-end GTM.
This, of course, makes you dependant on adblockers since they will block your front-end GTM. A way to avoid it is... Well, not to use the front-end GTM and have all your tracking implemented either in a tag manager that is not blocked (I doubt there is one) or just have your own custom javascript library doing all the front-end tracking and sending it to the backend GTM to be properly processed and distributed.
Generally, it's too expensive to implement tracking with no TMS, since now you really have to know your JS, so only the cool kids can afford to do this. A good example would be Amazon.
Basically, it would cost about two to five times more (depending on particulars) to implement tracking with no TMS, but adblockers typically cut only about 10% of traffic. 10% is not vital for reporting, measuring effectiveness of funnels and what not. All the critically important data is not being reported on by analytics anyway. Backend is the real source of critical data.
You can easily do this if you use sGTM hosting from https://stape.io
There is a feature called Custom Loader. With it, you can download Web GTM from different paths and all other related scripts will be also downloaded from different URLs, for example, gtag.js for GA4.
More info https://stape.io/blog/avoiding-google-tag-manager-blocking-by-adblockers
You can also create your custom loader client for Web GTM. However, there will be problems with related scripts. UA/GA4 still will be blocked then, but GTM itself not.
So, I finally implemented a great solution using GTM client templates. It works like a charm.
To summarize, the steps are:
Create a client template from your server container. You can import this template from https://raw.githubusercontent.com/gtm-templates-simo-ahava/gtm-loader/main/template.tpl
Create a new client from this client template
name your path as you want
This article explains perfectly the required steps: https://www.simoahava.com/analytics/custom-gtm-loader-server-side-tagging/
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 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.
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.