如今，市面上的浏览器种类越来越多（尤其是在平板和移动设备上），这意味着你所测试的站点需要在这些你声称支持浏览器上都能很好的工作。
同时，主流浏览器（IE，Firefox，Chrome，Opera，Safari）版本更新更加频繁，终端用户甚至不会感知这些浏览器版本的升级。
这两点导致了对于日益增多的浏览器做兼容性测试显示十分必要，但也使得这种兼容性测试变得十分耗时。
通过全覆盖的测试，你可以明确的知道你的站点支持哪些浏览器，哪些有兼容性问题。一个简单的减少浏览器兼容性测试的办法，是停止对老版本浏览器的支持。这个策略对一些公司是适用的，但并不适用所用的公司。
停止对老版本浏览器的支持，并不意味这你的产品在这些老版本上没有bug， 这仅仅是你可以忽略那些老版本上的潜在问题，把精力放在那些当前支持的浏览器版本上。
分散风险
一个途径是在多浏览器环境中执行日常的测试工作。
举个例子来讲，你要测试这样一个web应用：用户登入，生成报表，发送报表，退出系统。这个应用还包含一个管理功能，管理员或经理登入后可查看哪些人做了哪些改动。
为了覆盖更多的浏览器，你可以用一种浏览器来测试登入功能，在另一个浏览器中测试“发送报表”的功能，用第三种浏览器测试“审计变动”的功能。
这是一个有效的方法，在日常的功能测试的过程中，同时覆盖多浏览器兼容性测试。上面这个例子还是存在一些问题的，比如讲，如果“审计变动”这个功能在第一种，或第二种浏览器里是有问题，那么会发现不了。这种方法节省下来的时间，可以让你在做兼容性测试策略时，更有侧重。
让其他人来帮你做测试
对于一些明显的页面兼容性问题，有一些在线工具可以帮着你检查，例如Browser Shots，它可以将你的页面载入到它所支持的浏览器中(它支持浏览器种类和版本很丰富)，然后截屏，你可以查看在这些浏览器下的载入情况了.
这是一个很棒的工具，但那些需要登入验证的应用，或则你的应用中包含的页面太多 ，这个工具显得有点力不从心了.
和标准进行比对
你可以对你的站点进行HTML语法标准检查，如果通过了，在多浏览器兼容性上，你可以更有自信一点了，但即使通过了，还是总有一些浏览器（比如万恶的360）渲染你的页面是会有兼容性问题。
自动化
Web UI的测试可以通过webdriver这个工具来实现自动化，可以使用selenium Grid来将自动化脚本在多浏览器上运行。如果不会写代码的话可以使用TestWriter，完全零编码进行测试。
前提是你得有Web UI自动化的投入。Web UI自动化可以发现一些功能上的问题，但对于多浏览器页面布局方面的差异，通过它是很难发现的。
Fight Layout Bugs
你可以写一些自动化脚本来检查页面在不同浏览器下渲染效果。Fighting Layout bugs是一个开源的工具，可以用来检查页面布局方面的bug
手工测试
你可以手工测试所有的浏览器版本，为了避免混淆，你可以将不同的浏览器安装在不同的虚拟机上（uedde的确这这样做的），当有其他人需要用是，可以直接克隆这些虚拟机，或则直接访问这些虚拟机。但这太耗时，费力了，但还是有必要做一次这样的多浏览器手工测试的。
分类
你可以依据内核来划分浏览器。
chrome & safari使用的是webkit内核，Firefox则是Gecko， IE系列的是Trident内核，Opera使用Presto内核。新的Opera好像也开始使用webkit内核了。
这样你可以认为，如果在chrome上没有问题，那么“理应”在safari也应该没问题。
模拟
市面上有一些工具可以模拟不同的浏览器，有一些浏览器也附带了工具来兼容老版本。但使用这些工具是要谨慎，这样的模拟并不一定准确。慎重。
outsource selenium
如果你没有条件搭建selenium grid测试环境，你可以尝试着使用Sauce Labs 和 testingbot 这样的服务。
多浏览器的支持我们心中永远的痛，特别是如今浏览器更新如此频繁的状况下。哎~ 你可以选择上面的适合你的方法。
PS：有些浏览器有兼容模式，可以通过兼容模式来模拟老版本。有些浏览器，如chrome，提供了开发者工具可以帮着定位问题。