百度&ThoughtWorks的Web测试自动化资料分享

PPT Download:
–测试驱动开发(TDD)实战–ThoughtWorks
–Testing Automation 我们的尝试与实践–Baidu

 

介绍了常用的测试工具Selenium，以及做测试时需要重点考虑的一些地方：

• 要尽量避免UI测试：其原因是API和功能层级来说更加稳定，而且其自动化和维护的成本都比较低。在Google内部，测试就有一个721原则，即70%的测试工作集中在底层接口测试和单元测试，20%的测试工作为集成测试，其他10%的测试即为界面测试；
• 在测试Case时，不要试图自动化所有的Case，另外可以考虑使用Ipython等工具来半自动化自己的测试；
• 在处理业务变更时，利用ID/Name定位元素设定UI Map，向开发团队展示自动化成果和开发约定规则。

分享了百度在设计Case时常用的原则：

一般情况下，我们写Case的时候倾向于Case之间是没有关联的，但是这种情况很难做到，这是我们努力的一个方向。我们 希望一个Case在执行的时候， 它自己能够将初始化和结尾的工作先做好，A Case和B Case不应该有关系，B Case的成功与失败不应该依赖于A Case的成功与失败，一个好的Case应该这样设计。但是有时候A Case做完，我们需要先添加一个用户，然后再删除这个用户，这种情况下，如果没添加就去删除，则是失败的，两者之间存在一种依赖关系。在这种设计的情况 下，有一个解决的思路是支持Case间的依赖，你可以定义一个标签去说明某个Case依赖于其他的Case，这样就先执行被依赖的Case，然后再执行这 个Case，确保了执行的顺序。

Selenium本身设计上是比较适合做兼容性测试的，但实际上效果并不是那么好，可能会有各种各样的问题，比如对JavaScript的支持不 同，可能 会导致在Firefox上运行是OK的，在IE上运行可能就会失败。兼容性测试方面并没有一个比较好的方法，还是要用Selenium来做，虽然它对非 Firefox浏览器有时候支持的不好，但基本还是可以做的。如果你能提取几个主流的浏览器，比如Firefox和IE，其他的浏览器暂时不关注的话，就 可以针对性地设计一些Case。

至于百度的自动化测试率，各个开发小组的数据是不一样的，但估计不是很高。在2008年我们大批做的时候，这个数据达到过60%~70%，但是现在 这个数 据已经下来了，估计是30%这个级别。我们对这个数据本身已经没有太多的强制要求，有的组可能适合做自动化测试，数据可能高一些，有的组不适合，可能就低 一些。

Web的手动测试非常耗时，劳动强度高，并且很单调，而且还会引入一些人为的错误，因此测试自动化势在必行。通常自动化测试是通过一些测试自动化工 具开发和执行测试脚本，达到评估软件质量的目的。自动化测试不仅能够大大减轻测试人员的工作量，并减少了测试过程中人为出现的错误。

测试不仅仅能起到检验质量的作用，而且还能从根本上改善代码质量。测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原 理是 在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并 不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。

• WEB自动化测试只是给基本的业务流程提供一个安全网，主要目的不是发现bug的，覆盖率不高，有些人工更方便的使用人工测试好了。从提问的环节得到的信息，其实百度各个组对于WEB自动化测试的覆盖率没有硬性的要求，好一点的可能达到20-30%的样子；
• 尽管TDD强调在编写任何功能代码前都要先写测试，不过对于WEB测试来说由于运行一次的代价比较大，所以可以先在TestCase里列出场景，而不写任何测试代码，这样先让这个TestCase作为一个文档的作用存在；
• 通过测试和上层方法进行驱动开发。比如你写Action测试时发现需要跳转首页的方法，就驱动在Action建立toIndex（）方法。在Action发现你需要Service ，就建立Service对象，利用IDE的辅助提示功能，快速的进行驱动开发。