Zalenium - multiple browser interaction - zalenium

I want to know if I Can open 2-3 browser in zalenium and switch between these browser to automate a flow where I enter data in 1 browser, I need to validate the data in the second browser and vice versa. Both browsers are chrome browsers. Can I use the driver.manage.window.switch (windowhanle) function.
Any examples will help.

This is not possible, each node started will Zalenium will only run one browser. This is done by design, so video and log collection is performed in a clean way.

Related

Cypress tests against devtools port only

We use some third party enterprise software ("Container App"), which has an embedded Chromium browser, in which our webapp runs.
We use Cypress to test our webapp in a stand-alone browser outside of this container, however we would like to be able to test it inside, as it interacts with the container in various ways through javascript.
The only thing the container exposes is a "remote devtools-url" to the target (our) browser, which can be pasted to a native browser outside of the container and then debugged in devtools. Like this:
The Container provides 2 different url's for above debugging purposes, and they both work and seemingly similarly. They are something like the following (not precise, unfortunately I am not at work atm):
devtools://...inspector.html?id=xxx
http://ip/...inspector.html?id=xxx
Is it possible to setup Cypress to test "as normal", only having access to this remote devtools-url/port?
The target browser inside the container cannot be started by Cypress, as only the container can start and close it. So the target browser will already be running (with a --remote-debugging-port). I can get the devtools-id dynamically through a call to /json/list.
If not possible, any other way to achieve the goal of testing the browser/app running inside the container?
It is not possible. Testing with Cypress a web page in embedded Chromium running in your application means Cypress needs to connect to already running browser. Cypress doesn't have that possibility.
The documentation states:
When you run tests in Cypress, we launch a browser for you. This enables us to:
Create a clean, pristine testing environment.
Access the privileged browser APIs for automation.
There is a request in Cypress issue tracker to add the option to connect to already running browser. But there is no response on it from Cypress developers.

What exactly happens when we disable history in Firefox?

I have a problem with live video streams in the system I am developing that happens only in Firefox and only in normal mode.
The player correctly loads the stream, but after a few seconds can't continue to load and just keeps trying and trying forever.
This doesn't happen in Chrome, nor if I load the page in Private Mode, nor with normal videos. Just with live streams, just in Firefox, just in normal mode.
This happens both in local development (home, remote connection) and in the corporative cloud.
It's an Angular 8/NodeJs system and the player I use is Clappr. I changed to Video.js and the problem continued.
The stream is coming from a load balancer with 6 children servers, each one with an apache server who have a proxy to an icecast server that originates the stream.
[load balancer] < [6 child servers with apache server proxy] > [icecast server]
I work for a very large company that has an IPS system installed. It was the first thing I thought. But the IPS team could not find any blocked traffic. Also if it was that, why would the traffic not be blocked in private mode?
So I thought about trying to pinpoint what the exact configuration is different in private mode that does the trick and I figured out that disabling all history (not only navigation and downloads or forms) makes it work too.
Does anyone knows what exactly happens when the navigation history is disabled? Besides not saving history, does it have an impact on something else? Some type of cache, network or something like that? Anyone has any idea about how to make stream work without disabling history? I can't ask my users to disable history just to use my system.
EDIT
One thing that may be relevant to the issue is that in Firefox it doesn't show LIVE label when the transmission starts. It shows a negative number. Maybe this could create some problem with the history.
I couldn't find the information on what exactly happens when we disable history in Firefox, but I could solve the problem of playing the stream in Firefox, so I won't accept this answer, but leave it here for future reference in case someone has a similar problem.
I solved it by adding ?nocache=<random integer of length 10> to the video url. Please notice that if you already have some parameter in your url, you can't have 2 ? characters in your url and have to mix parameters correctly.

How to track & trend end to end performance (the client experience)

I am trying to figure out how best to track & trend end to end performance between releases. By end to end I mean, what is the experience form the client visiting this app via a browser. This includes download time, dom rendering, javascript rendering, etc.
Currently I am running load tests using Jmeter, which is great to prove application and database capacity. Unfortunately, Jmeter will never allow me to show a full picture of the user experience. Jmeter is not a browser therefore will never simulate javascript and dom rendering impact. IE: if time to first byte is 100ms, but it takes the browser 10 seconds to download assets and render the dom, we have problems.
I need a tool to help me with this. My initial idea is to leverage Selenium. It could run a set of tests (login, view this, create that) and somehow record timings for each. We would need to run the same scenario multiple times and likely through a set of browsers. This would be done before every release and would allow me to identify changes in the experience to the user.
For example, this is what I would like to generate:
action | v1.5 | v1.6 | v1.7
----------------------------------------
login | 2.3s | 3.1s | 1.2s
create user | 2.9s | 2.7s | 1.5s
The problem with selenium is that 1. I am not sure if it is designed for this and 2. it appears that DOM ready or javascript rendering is realllly hard to detect.
Is this the right path? Does anyone have any pointers? Are there tools out there that I could leverage for this?
I think you have good goals, but I would split them:
Measuring DOM rendering, javascript rendering etc. are not really part of "experience from the client visiting this app via a browser", because your clients are usually unaware that you are "rendering dom" or "running javasript" - and they don't care. But they are something I'd want to address after every committed change, not just release to release, because it could be hard to trace degradation back to particular change if such test is not running all the time. So I would put it in continuous integration on build level. See a good discussion here
Then you probably would want to know if server side performance is the same or worsened (or is better). For that JMeter is ideal. Such testing could be done on some schedule (e.g. nightly or on each release) and can be automated using for example JMeter plug-in for Jenkins. If server side performance got worse, you don't really need end-to-end testing, since you already know what will happen.
But if server is doing well, then "end user experience" test using a real browser has a real value, so Selenium actually fits well to do this, and since it can be integrated with any of the testing frameworks (junit, nunit, etc), it also fits into automated process, and can generate some report, including duration (JUnit for instance has a TestWatcher which allows you to add consistent duration measurement to every test).
After all this automation, I would also do a "real end user experience" test, while JMeter performance test is running at the same time against the same server: get a real person to experience the app while it's under load. Because people, unlike automation, are unpredictable, which is good for finding bugs.
Regarding "JMeter is not a browser". It is really not a browser, but it may act like a browser given proper configuration, so make sure you:
add HTTP Cookie Manager to your Test Plan to represent browser cookies and deal with cookie-based authentication
add HTTP Header Manager to send the appropriate headers
configure HTTP Request samplers via HTTP Request Defaults to
Retrieve all embedded resources
Use thread pool of around 5 concurrent threads to do it
Add HTTP Cache Manager to represent browser cache (i.e. embedded resources retrieved only once per virtual user per iteration)
if your application is build on AJAX - you need to mimic AJAX requests with JMeter as well
Regarding "rendering", for example you detect that your application renders slowly on a certain browser and there is nothing you can do by tuning the application. What's next? You will be developing a patch or raising an issue to browser developers? I would recommend focus on areas you can control, and rendering DOM by a browser is not something you can.
If you still need these client-side metrics for any reason you can consider using WebDriver Sampler along with main JMeter load test so real browser metrics can also be added to the final report. You can even use Navigation API to collect the exact timings and add them to the load test report
See Using Selenium with JMeter's WebDriver Sampler to get started.
There are multiple options for tracking your application performance between builds (and JMeter tests executions), i.e.
JChav - JMeter Chart History And Visualisation - a standalone tool
Jenkins Performance Plugin - a Continuous Integration solution

JMeter fails to simulate browser response time

I'm trying to simulate a connection to a website. The goal of the simulation is to collect statistics on page loading time on browser side.
I configured JMeter Flagging the option Retrieve Embedded Resources in order to simulate the real time to load the whole page. The issue is that while from a real Browser i have a response time (let's assume for the page A the response time is 10 seconds) in JMeter I found i response time 20 times higher.
It seems JMeter takes a much longer time to gather embedded resources (e.g. js, images, ...)
Do you have any suggestion for this issue?
Kind Regards
Update 31/07
I discovered some resources are not completely downloaded. Using Firebug i see some components with 0 bytes downloaded that the browsere keep trying to download (but the user do not percieve since the page is loaded). Therefore i suspect JMeter keeps trying downloading it. Is there any chance to set a timeout to overcome this kind of situation?
Update_1 31/07
I figured out that the issue is related with nested iframes. setting httpsampler.max_frame_depth=0 i get the correct time. however i would like to understand the reason of this issue. Do I have to set other paramters?
Disable browser cache and re-run your test in browser.
Jmeter will not store cache, unless otherwise specified.
Hope this will help.
Add a HTTP Cache Manager to your test plan.
Real browsers retrieve images, scripts, styles, etc. but do it only once. In order to simulate browser behavior you need to configure JMeter appropriately.
See How to make JMeter behave more like a real browser guide for more test elements which can be used for this.

Headless automation of IE-browser, tracking site rendering times

I'm need to monitor my sites render times for common tasks (Login, Search etc.). I need something automated that can mimic a users actions on I.E. and be able time how long a page takes to render.
Example automated execution:
1) open headless IE browser
2) go to http://google.com
3) type "stackoverflow"
4) press submit button
5) start timer
6) wait for results page to fully
render
7) stop timer
8) Close IE
9) record results
I need this to run as a scheduled task while the server, without the user logged in.
I have been searching for something to help me do so. Anyone have any experience with this type of thing or know of anything that can accomplish this?
It depends on what you focus, functionality or performance.
Functionality
When monitoring functionality, you aim at automatically ensuring that a web application still works correctly. Usually, this is more part of the continous integration process - and less part of production monitoring. It can be well done with HtmlUnit, Selenium or WebDriver. HttpUnit is no longer recommended (API more low-level, JavaScript not so well supported, less widely adopted, fewer bug fixes and enhancements).
HtmlUnit simulates a browser. So you can never be sure, that your application behaves exactly identical in a real browser. This is especially important for sophisticated Ajax applications. This is comparable to all the small incompatibilities between FireFox and Internet Explorer. Pros: Headless, easy to understand. Cons: Risk of undetected incompatibilities.
Selenium remote controls a real browser. In our setup, we could not use it headlessly, especially with Internet Explorer. But if you embed it into a virtual machine, it runs headlessly. If your application is reachable through public internet, you might even use Selenium Grid and a preconfigured virtual machine from the Amazon Elastic Cloud EC2. Pros of Selenium: Real world compatibility, easy scripting. Cons: Headless only in virtual machine, performance overhead, more complex runtime setup, stress simulation of concurrent users only in the cloud.
Up to version 1.5, Selenium uses a JavaScript part called Selenium Core to control the browser. If your application has security restrictions for JavaScript, Selenium might not work correctly.
WebDriver uses for each browser the specific interface, e.g. for FireFox an extension and for internet explorer Automation Controls. Additionally it uses the operation system, e.g. for simulating keystrokes. This is more powerful, robust and reliable than Selenium Core. As of Selenium version 2.0, WebDriver is integrated into Selenium. But Selenium 2.0 is still beta.
Performance
You mention measuring with a timer and you mention rendering times. When monitoring performance of a web application, you want to be alerted when real world usage of a application is no longer possible due to overlong answering times.
In this scenario, you are normally not interested in exact results in milliseconds. You can still use one of the tools mentioned above. For example, a browser with Selenium Core is slower than a real world browser - but this is of little relevance for continuous monitoring.
If you absolutely need exact measurements, none of the above is suitable. You should differentiate between client-side duration and network plus server-side duration.
Client-side duration is needed for rendering the HTML and for executing the JavaScript. It does not depend on the number of concurrent users. You can measure it once, e.g. with Firebug. You do not need to monitor it permanently.
Network plus server-side duration is needed for transferring the request to the server, handling the request and generating the response and transferring the response to the client. They vary according to network usage and number of concurrent users. You can exactly measure and monitor them for example with JMeter. But in case of sophisticated Ajax functionality, the simulation of the right client requests in JMeter is a complex task. Pros of JMeter: Exact measurement, possibility to stress an application with many concurrent users. Cons: Limited for Ajax, much effort for request building.
Another option might be Selenium Remote Control (or Selenium in general).
One option for headless automation is to use HtmlUnit. Have a look at this link for more information: Using HtmlUnit on .NET for Headless Browser Automation
The following Headless IE port for PhantomJS is currently in Beta (v0.2):
http://triflejs.org/
Here is a quick intro:
The API is the same as PhantomJs so eventually you'll be able to do the following:
// 1. Create Page Object and navigate to Google
page = require("webpage").create();
page.open("http://www.google.com", function(status) {
if ( status === "success" ) {
// 2. Inject jQuery for DOM operations
page.includeJs("http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js", function() {
// 3. Start Timer
console.log('Start Timer: ' + (new Date()).getTime());
// 4. Type string and click search
page.evaluate(function() {
$(("input[type=text")[0]).val("stackoverflow");
$("button:contains('Google Search')).click();
});
// 5. Wait for loading and end timer.
page.onLoadFinished = function() {
console.log('Load Finished. End Timer:' + (new Date()).getTime());
phantom.exit();
};
});
}
});

Resources