跨多个浏览器进行硒测试的自动化测试套件软件包结构的建议

Question

So, I could use a recommendation or two on what makes the most sense on how to structure my automated test package (it's java based using Selenium 2.4.5).

I've thought of two main options:

root test dir -> browser dir -> test dir -> test class in java

or

root test dir -> test dir -> browser dir -> test class in java

I just haven't really experimented enough to know if it's more useful to be able to run the tests based off browser or the kind of tests. For example I could see the benefit of running all IE tests to verify something, but I can also see the validity of running all of the 'login' or 'sign up' based tests so I was hoping someone who has actually implemented and uses this more could give me an idea on what works for them.

Ultimate Goal: Have build variants setup to run against several different environments (dev, integration, staging, and production) and with several different browser options (chrome, firefox, ie, opera, safari, or all) when a commit is pushed and Jenkins job finishes deployment.

Answer 1

We have implemented the PageObject Model successfully. PageObject pattern is probably the most popular way of handling responsibility and separation of concern out there. In short, you create separate object for each pages and tests so there are clear separation of concern. As all of us know, controlling the UI in early development is a challenge for UI testing while this pattern provides a way to handle the whole framework by only modifying the page object instead of changing everything.

Also, the multi browser capabilities can easily be controlled with the Testing framework such as TestNG. I have a public Github repo here

Answer 2

Tests should be developed universally, so that when written for one browser - will work for all browsers and on all environments. This way it will require you only to handle your properties/data for different browsers/environments in resources/CLI, and the issue with package presentation will solve itself.

Also you will organize your tests in suites, and this is where you can create tons of them for every setup you need.

Thus, package structure has little to do with multibrowser testing, it is only for your convenience.