Our webapp is usually accessed using Google Chrome in a windows OS. Should we really need to have a windows OS for this or ubuntu with GUI is sufficient?
AFAIK, Chrome is sandbox from the OS. We are using teamcity and selenium, chrome driver for testing. Our plan is to use Ubuntu with GUI and register it as a teamcity agent, e.g. kubernetes pod if possible
From a generic perspective, web applications should be accessible through browsers irrespective of the underlying os. Albeit, Chrome relies heavily on sandboxing, keeping different processes and applications in separate partitions. This limits the interaction between applications and the OS kernel.
Chrome OS and Chrome security
Google's browser-based operating system i.e. Chrome OS stores data in the cloud implementing the idea ..."The browser is the operating system"... which relies on many of the same security features and concepts used by the Chrome browser.
Chrome achieves tighter security through Sandbox feature and should be functional irrespective of the underlying Operating System as Linux systems implements Sandboxing too.
References
You can find a couple of relevant detailed discussions in:
compile & execute Chromium failed due to SUID sandbox issue
NaCl helper process running without a sandbox error using Chrome through Selenium in Linux
NaCl helper process running without a sandbox! error when running npm tests
tl; dr
Sandboxing Chrome OS system services
Related
I'm helping set up web testing frameworks for a team that runs web tests on a project that already supports Firefox and Chrome. They want to extend it to be able to test Microsoft Edge.
So far we've been using Selenium grid with Docker and Jenkins but only for Firefox and Chrome.
Is there a way to extend a set up like this for Microsoft Edge? Or is there a way to dockerize Micrsoft Edge testing?
I know there is a webdriver for Edge compatible with selenium grid but I've seen nothing about how to dockerize it.
I want to use Docker because it keeps all the Jenkins slaves clean and allows for controlled versions of browsers, and we can control multiple containers with Docker-Compose.
You can try to use WebDriver with Windows Insider to test web projects with MS Edge.
WebDriver is an emerging standard through which Web developers can write tests to automate Web browsers for site testing. It provides a programmable remote control for developing complex user scenarios and running them in an automated fashion against your website in a browser.
Reference:
Bringing automated testing to Microsoft Edge through WebDriver
Other useful links:
Automated browser testing on Microsoft Edge, Firefox and Chrome for free.
Free Testing on Microsoft Edge
I am running an Azure Pipelines (DevOps) pipeline that builds my automation test solution into a dll, and loads that dll to get all of the integration automation tests.
I am using the default cloud "Host" agents to run the automation. However, the drivers throw tons of errors. I recognize the errors as the same ones that I encountered when I set up automation via Jenkins -- when I was running Jenkins as a service.
To fix the issue in Jenkins, I stopped running it as a Windows service, and started launching it as a java -jar Jenkins.war command in Powershell. That allowed the selenium drivers to launch browsers as normal on the VM's desktop, rather than running the browser instances and drivers completely in memory.
So, when it ran the browser windows and drivers completely in memory, I received the same driver errors as I am now encounting on the Host agents in Azure Pipelines. The problem is that I cannot find how to make the Agents run the tests on the VM desktop. I don't have any idea where to start on solving this problem, and can't seem to find any info online about this.
Edit: To be as clear as possible. The ONLY error occurring is "$ is not defined". This is because the DOM does not load properly because the browser executables and driver executables are running completely in memory, headless. I need to be able to run the executables in a rendered part of the host machines. So, what I mean is, if I were to remote desktop into this machine, I would actively see browser windows rendering, and automation running. Right now though, if I were to remote into this VM, I would see chrome.exe, and chromedriver.exe in TaskManager, but nothing would be visible on the desktop.
I found the answer.
https://learn.microsoft.com/en-us/azure/devops/pipelines/test/ui-testing-considerations?view=vsts&tabs=mstest#visible-ui-mode
You must manually configure the hosts to run Selenium non-headless. This will prevent everything from running as a service, which is purely in memory, with no UI components. This is the problem I mentioned that Jenkins encountered when running Jenkins as a service.
The fix for Jenkins running automation with a GUI is the same for the Hosted agents in Azure pipelines, ultimately. It's just a manual configuration. This is done via a plugin and build step in pipelines.
I am planning to write Selenium tests for my application and want them to run on a wide variety of browsers and versions. I am also planning to use a virtualisation service such as SauceLabs or TestingBot.
However, as far as I can tell there are a number of different Selenium components such as:
Selenium WebDriver itself
Chrome Driver
InternetExplorer Driver
Opera Driver
Safari Driver
etc
Furthermore, I read in articles like https://support.saucelabs.com/customer/portal/articles/2005317-default-selenium-version-for-each-firefox-browser-version that you might be best advised to change the versions of these to get better compatibility depending on the version of the browser you are targeting.
I am confused as to whether I need to have different versions of Selenium and other components installed locally OR should I just have the latest version of Selenium WebDriver installed locally, SauceLabs/TestingBot will have specific versions on their VMs and the two will magically work together?
Thanks for any advice!
If you're executing on the cloud, be it Sauce, TestingBot, BrowserStack, etc., you won't need to have the Selenium server or any of the browser drivers installed locally.
That being said, however, I would advise keeping the standalone server along with chrome-driver and the IE driver (and/or any other browser drivers you need) installed locally for debugging tests under development. It's much easier while you're coding to run a test on your own machine and get it to the point where it's working as expected prior to committing. You can then use Sauce or whatever cloud hosted grid solution for your official test runs.
I typically just have the most recent versions installed locally, but this could be different for you based on your requirements. At work, I develop automated tests for internal applications. All of our users are all on the same pre-configured Windows image with the same browsers/versions. As such, I only need to worry about the supported platforms in my tests. If you're working with a public-facing application, you might consider referring to the supported browser/versions for the application. Juggling different versions of the same browser on a local machine can get pretty tedious, so even then, if I were in that situation, I'd likely configure my machine to the most common platforms and execute locally while in development, then use something like Sauce for executing on specific platforms. In short, I like to keep my local environment as clean and simple as possible, and let Sauce do the heavy lifting of managing all the different browser/version/os combinations for me.
I'm looking to use Chromium OS for a specific business application, but I need access to local serial and USB ports. My reading of the Chromium docs says NPAPI plugins are not supported in Chrome OS, only PPAPI (Pepper). I'm a bit confused about PPAPI, as all docs talk about this in the context of Native Client, which as it's a sandboxed environment, cannot access local resources.
So my basic question is: Is it possible to write a PPAPI browser plugin that will work like a regular NPAPI browser plugin to access local resources?
Currently, no. NPAPI plugins are on the way out, Native Client is a sandboxed environment, and Pepper's interfaces are designed to mirror those available elsewhere on the web platform (e.g. Javascript). So a good place to look for future interfaces would be draft web standards and HTML5/JS addons, e.g. for gamepads (https://wiki.mozilla.org/GamepadAPI) or cameras (http://developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html )
What would be a good workflow on OS X for testing client-side code (HTML/JS/CSS) for browser compatibility and other issues across all major browsers?
I do my web development with Textmate (HTML and JavaScript), CSSEdit (CSS), and use Safari's Web Inspector, mainly for checking the JS console. I do have Parallels with Windows XP on it, but haven't tuned it for web development at all.
We develop on Macs too so what we usually do is testing and debugging in Firefox with the help of the Firebug plugin and the Web Developer toolbar. We then cross-check stuff in Chrome/Safari using Chrome's built-in Inspector in case of any discrepancies.
For testing on Windows we use a dedicated Windows machine that we can access through Remote Desktop which has some Virtual Machines running various versions of Internet Explorer (one VM for each would be nice, but we just use one for IE6, one for IE 7 and use the IE version that's installed on the remote machine as the third option).
A colleague of mine has a setup with VMWare and running IE right off his Macbook in a VirtualMachine.
As far as I can tell debugging in IE 6 is pretty hard, but some of the newer IE versions have a pretty decent Inspector similar to the ones in Safari and Chrome.