百度技术沙龙第 4 期回顾：Web 测试自动化（含资料下载）

在 7 月 24 日 InfoQ 和百度联合举办的第 4 期百度技术沙龙活动上，来自百度的工程师孙景卫和 ThoughtWorks 的工程师张晓庆分别和与会者分享了测试相关的话题，包括百度研发团队在 Web 测试自动化方面的尝试和实践，以及测试驱动开发实战。本次活动还增设了促进交流的 OpenSpace 环节，让“每一个人都是讲师”！

在孙景卫的演讲中，他从 Web 测试自动化的目标谈起，认为让测试自动化并不是为了赢得老板的赞赏，或者认为这是一个很潮的技术，不用就会落后，而是为了网站的质量。随后他介绍了测试自动化的原理，包括感性的时间和空间，记录鼠标键盘的动作；利用如 Http 协议和 Web 服务协议进行测试；或者直接操纵页面控件，如利用 JavaScript 操纵 Dom 等。在分享百度研发团队在测试自动化方面的一些实践时，孙景卫重点介绍了常用的测试工具 Selenium，以及做测试时需要重点考虑的一些地方：

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

最后，孙景卫还介绍了如何设计一个好的模式或者框架来让测试自动化更加便捷，包括要对业务进行分层，关注数据存储和数据驱动，重视 DRY/WET 原则，以及要能够对结果进行验证等。在提问环节，有听众问如何设计 Case，以及当某个 Case 位置变更的时候，应该如何处理，孙景卫分享了百度在设计 Case 时常用的原则：

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

也有与会者提到如何使用 Selenium 来对不同的浏览器进行兼容性测试，以及百度的自动化测试率能达到多少，孙景卫的观点是：

Selenium 本身设计上是比较适合做兼容性测试的，但实际上效果并不是那么好，可能会有各种各样的问题，比如对 JavaScript 的支持不同，可能会导致在 Firefox 上运行是 OK 的，在 IE 上运行可能就会失败。兼容性测试方面并没有一个比较好的方法，还是要用 Selenium 来做，虽然它对非 Firefox 浏览器有时候支持的不好，但基本还是可以做的。如果你能提取几个主流的浏览器，比如 Firefox 和 IE，其他的浏览器暂时不关注的话，就可以针对性地设计一些 Case。 至于百度的自动化测试率，各个开发小组的数据是不一样的，但估计不是很高。在 2008 年我们大批做的时候，这个数据达到过 60%~70%，但是现在这个数据已经下来了，估计是 30% 这个级别。我们对这个数据本身已经没有太多的强制要求，有的组可能适合做自动化测试，数据可能高一些，有的组不适合，可能就低一些。

在 ThoughtWorks 工程师，也是 InfoQ 中文站敏捷社区编辑张晓庆的“测试驱动开发（TDD）实战”演讲中，他主要结合代码演示介绍了 TDD 的一些原则，包括：

• 自上而下的驱动
• Web 测试要先列出应用场景
• 要先写测试，哪怕是 Bug
• 测试即文档
• 与 QA 讨论测试场景
• TDD 与语言无关
• TDD 不是玩具

在会后部分参会者所写的博客中，详细记录了两位分享嘉宾演讲的一些要点，比如 YanHua 的“测试专题活动和奇遇咖啡的 rails 活动小记”以及 sunway00 的“参加 Web 测试自动化与 TDD 应用的沙龙心得笔记：

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

为了让参会者能够有更多的时间进行相互的交流，本次活动在最后的 1.5 小时中设置了 OpenSpace（开放空间）环节，将大家分成不同的小组，然后自己选择组长自己选择话题，然后和其他人员进行分享。从而让每个人都有发言的机会，“每一个人都是讲师”，并能在相同的单位时间内聆听到关于一个话题更多的观点，更靠近百度技术沙龙所强调的“交流”和“争鸣”目的。这一环节的效果，正如一位参会者会后在网易论坛中对这次活动的图片报道中写到，“真是很活跃丰富的沙龙活动，互动性很强，是我最喜爱的交流方式！希望百度延续这样的方式，给大家一个自由的交流平台。”关于 OpenSpace 环节的讨论，InfoQ 随后会有更深入的总结，本次活动的演讲资料下载链接为：百度技术沙龙第 4 期（7 月 24 日）演讲资料下载！