We are using Demandware for our eCommerce site so they are giving sandboxes for development and testing.
I am automating the site for regression testing. But if I run automation scripts on Testing sandbox, sometimes it is taking longer time to load the page as a result test fails.
So what is the best way to do automation testing on Demandware related websites ?
Is it possible to deploy site to Cloud ?
Is is possible to increase the performance of testing related sandbox ? So tests will not fail?
Can you please suggest your thoughts?
Use development instance for these tests, as it is close to production in terms that it uses Akamai CDN, so the loading of pages will be relatively faster.
If sandboxes/development instances are performing slow, it may be good idea to look in Pipeline profiler in Demandware Business Manager to get insight as to where the performance bottleneck is lying.
Related
Our application is built on a microservice architecture. The test environment is sometimes down due to failures in some of the downstream services. What are some good practices to follow that would have a stable test environment.
Looking for ideas that are popular in the industry.
Thanks
You can make a dashboard that includes results from some tests that are checking which services are up and send notifications to responsible people when some services are down so that they can fix them.
What is the difference between
Using the performance testing tool directly(Jmeter ,..)
Integrate the performance testing tool with selenium using plugin(Jmeter ,..).
Whether I can achieve all the functionalities in both the ways.
If used as a plugin will there be any limitations?
Thanks.
Performance testing tool acts on HTTP protocol level, basically pretty much the same as browser does, however in particular JMeter:
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 (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever displayed at a time).
therefore you can only test backend performance using JMeter however you will not get client-side performance metrics
Protocol-based tests have much less footprint in terms of resources (CPU, RAM, etc.) so you can simulate thousands of virtual users from a mid-range modern laptop.
Selenium is a browser automation framework, it operates real browsers so:
you have client-side performance metrics (including ability to query Window.Performance metrics)
and you don't have HTTP-protocol related metrics (connect time, latency, concurrency, throughput, etc.)
Browser-based tests have huge footprint in terms of resources as browsers are very resource intensive, for example Firefox 74 requires 1 CPU core and 2 GB of RAM per browser instance so you can kick off only several browsers on a mid-range modern laptop
Depending on your requirements you might want to either test the backend using JMeter or the frontend using Selenium or create the main load using JMeter and use 1-2 real browsers to test client-side performance.
If you're looking for a way of integrating JMeter with Selenium take a look at WebDriver Sampler (it's a JMeter Plugin which can be installed using JMeter Plugins Manager)
we recently implemented on our websites local storage. I am curious if there is some way to automate testing of local storage. I don't mean unit test etc. I am looking for some tools from testers perspective for example - possibility to test it with Selenium or other test automation tool.
Thank you
everyone
do you think nodeJS suit for the web UI automate testing?
I　don't think so.
first, nodeJS base on V8 engine, so how to test the issue on IE6-8?also how about other
no web-kit based browser?
second, what's nodeJS suit for?
What are you talking about? NodeJS is designed for writing SERVERS, not clients. It has nothing to do with browsers.
Imho NodeJS is the best choice for writing high traffic web servers. Also together with websockets it is also very good choice. And it is the future of web designing since the unification of language used in client's side and server's side.
You can use nodeJS to connect to Selenium and do automated UI tests, Soda (https://github.com/testingbot/soda) supports this.
If you want to use a node.js based headless browser to automate UI tests, check out zombie.js. If you want to create a UI test suite that runs against different browsers, I'd highly recommend selenium.
Say you want to create a new environment for a team of developers to build a large website on a LAMP stack.
I am not interested in the knowledge needed for coding the website (php,js,html,css,etc.). This stuff I know.
I am interested in what you need to know to setup a good environment and workflow with test server, production sever, version control, backups, etc.
What would be a good learning path?
As someone who has lead this process at several companies, my recommendation is to gradually raise the "maturity" of your organisation as a software factory by incrementally consolidating a set of practices in an order that makes sense to your needs. The order I tend to follow (starting with things that I consider more basic, to the more advanced stuff):
Version control - control your sources. I used to work with SVN but I'm gradually migrating my team to Mercurial (I agree to meagar's recommendation for a distributed VCS). A great HG tutorial is in hginit
Establish a clear release process, label your releases in VCS, do clean builds in a controlled environment, test and release from these.
Defect tracking - be systematic about your bugs and feature requests. I tend to use Trac because it gives me a more or less complete solution for project management plus a wiki that I use as a knowledge base. But you have choices galore (Jira, Bugzilla, etc...)
Establish routine Testing practices. Unit tests e.g. by using one of the xUnit frameworks (make it a habit to at least write unit tests for new functions you write and old code you modify) and Integration / System tests (for webapps use some tool like Selenium).
Make your tests run frequently, as a part of an automated build process
Eventually, write your tests before you code (Test-Driven Development) and strive to increase coverage.
Go a step forward in your build/test/release cycle by setting up some continuous integration system (to make sure your build and tests are run regularly, at least nightly). I recently started using Hudson and it is great for our Java/Maven projects, but you can use it for any other build process as well
In terms of testing environments, I agree with meagar's recommendations. We have these layers:
Test at developers workstations (should contain a full setup to run your code)
Staging environment: clone your production environment as closely as possible and deploy and run your app there. We also use VMs.
Production preview: we deploy our app to the production servers with production data but in a different "preview" URL for our internal use only. We run part of our automated Integration tests against this server, and do some additional manual testing with internal users
Production - and keep fingers crossed ;)
In terms of backup, at least for your source code, distributed VCS give you the advantage that your full repos are replicated in many machines, thus minimising the risk of data loss (which is much more critical with centralised repos as is the case with SVN).
Before you do anything else, ask your developers what they want out of a test/production environment. You shouldn't be making this decision, they should. The answer to this depends entirely on what kind of workflow they're familiar with and what kind of software they'll be developing.
I'd personally recommend a distributed VCS like git or mercurial, local WAMP/LAMP stacks on each developer's workstation (shared "development" servers are silly) and a server running some testing VMs which are duplicates of your production environment. You can't ask for more specific advice than that without involving your developers.