反方论点：反方辩手太禅、宝妮、七修、王蕾从以下几个方面论证了在webx层做接口测试不合适：
1. 它无法取代功能测试。基于Webx的接口测试跟实际用户使用的页面还有很大的差距，它无法进行用户界面测试，比如界面是否友好和合理，界面的美观和协调；也无法进行易用性测试，比如键盘快捷键和鼠标拖拽；它无法保证最终页面确实满足了客户的需求，也无法保证最终用户看到的页面没有展现方面的问题。因此，不能说我们做了Webx接口测试，就不用做页面的功能测试了。
2. 它不能取代底层接口测试。底层接口测试可以非常容易地做代码覆盖，像某些边界测试，空指针等特殊值的测试是Webx接口测试无法模拟的。同时，调用底层接口时参数简单，不必去准备session， cookie和request里的参数，这也是一种效率的提升。另外，Webx接口测试要新搭建测试环境，这是个苦差事，显然底层接口的测试环境搭起来要容易许多。
3. 它不能取代页面自动化测试。页面自动化最直观的模拟了用户的操作，有效地减少回归的成本。相比Webx接口测试，页面自动化可以检测js操作和ajax请求对页面产生的影响，可以进行不同浏览器的兼容性测试，可以进行流程复杂的跨应用测试。这些都是Webx接口测试做不到的。同时，页面自动化上手相对容易，它不必关心到底这个操作对应是的哪个action，入参要填什么key-value pair，只要把手动操作的步骤用自动化的语言写出来就可以了。
综合以上三点，Webx接口测试即不能取代页面自动化测试，也无法取代底层接口测试，更无法取代功能测试。这时，Webx接口测试的地位就很尴尬了，自动化测试讲究的是投入产出比。那么我们在做好以上三项无可替代的测试的基础上，再增加Webx接口测试，它能给我们带来多少收益呢？还是我们有时间就做一下，没时间就不做了呢？
此外，Webx层的接口测试还有一些硬伤：
● 它要求开发把接口名，参数文档化。那么测试代码，环境数据，参数数据的可信赖性都是建立在文档上的，或者就是第一次写脚本时通过工具抓取出来的，都不可靠。
● Webx测试代码的测试数据以xml的形式存在，无论读还是写的门槛都很高。配置文件也很复杂，一不小心写错了排错也不容易，这无疑也增加了我们的成本。而淘宝作为互联网公司，项目测试的时间都很短（注意这里不是回归），时间这么短我们真的要有Webx测试么？
综上所述，反方认为基于Webx的接口测试因其固有的局限性，不符合我们淘宝测试的实情，不应成为我们测试发展的方向。
嘉宾点评：
郭芙：项目效率，沟通协调比较多，执行测试时间比较少，我们需要降低沟通协调成本，需求变更对测试人员很痛苦，不经测试人员测试出现问题测试人员仍然需要承担，对于测试人员很苦恼，希望有平台能够使这些变更不需要人工通知就能知道。
雷卷：测试的敬业等等很多是个人习惯，webx是一个方向性问题，可能现在不会做，但不代表以后不做，webx基于某个framework，耦合性比较高，在这方面页面自动化测试优势很多，代码质量开发人员有很大责任，对开发而言基于webx会页面自动化更方便，可能达到的覆盖面更广。
文朗：很多观点和雷卷一致，webx是否要取代页面自动化或者功能测试，是相辅相成的关系，测试设计就是用来做选择，希望能够提供一定得技术手段来供选择，代码是调用关系，我们需要从上面一层去覆盖，从webx做跟业务关系更紧。
行烈：反方关注到了一些额外成本的投入，代码的积累是否是最合适的方式，目前人工的力量更多，期望更多的能交给机器。
宝驹：感谢8位选手，测试的手段很多，确实是一门艺术，webx并不是来取代某种测试，web层测试能够提高多少效率。
推荐阅读：
