........................
在webx层做接口测试是否合适？
上一篇 /
下一篇 2013-07-04 11:21:59
/ 个人分类：webx
从以下几个方面论证了在webx层做接口测试合适： 1. 提前发现bug的时间，缩短单个项目研发周期 2. 执行速度快，用例维护量小， 可以持续回归，减少手工回归成本， 减小测试开发比 – 底层代码修改，action层接口未改，用例就不用改； – 和开发代码耦合度低，不需要频繁改动； 3. 业务和代码覆盖面广，可以模拟页面的请求 – 某项目发现296个bug,样式和js类有54个，环境类bug42个，接口测试可以覆盖70%容易出现bug的地方 - 用例业务覆盖面达到一定程度后，可以加强开发重构server端代码的信心，提高整体代码质量 4. 定位bug比手工测试和ruby自动化测试都容易 5. 可以覆盖以前手工或者ruby自动化不容易测试的功能点 - 后台扫描程序 - notify消息重复发送，代码处理能力 - 异常情况下接口/请求的重复调用，如支付宝 - 容灾控制 - 读写分离（接口测试更精确） 6. 可以更好的规范文档的产出，方便后人学习 7. 写好的用例可以用来给开发做自测，提高冒烟质量，还加强团队合作，从整个研发部门来看，节省了很大一部分成本 8. 基于WebX3.0的接口测试更简单，高效，优势更明显 9. 成本低。以前接口测试底层一个应用一个接口测试人员，相对于数个底层应用，如果能从上层覆盖，从长远考虑，投入产出比更高 10. WebX接口测试让测试人员更好的了解开发代码，提高整体测试人员的技术水平和定位bug的能力。让回归更有目的，测试不需要开发，也可定位需要回归哪些业务点。 反方论点：反方辩手太禅、宝妮、七修、王蕾从以下几个方面论证了在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的接口测试因其固有的局限性，不符合我们淘宝测试的实情，不应成为我们测试发展的方向。 嘉宾点评： A：项目效率，沟通协调比较多，执行测试时间比较少，我们需要降低沟通协调成本，需求变更对测试人员很痛苦，不经测试人员测试出现问题测试人员仍然需要承担，对于测试人员很苦恼，希望有平台能够使这些变更不需要人工通知就能知道。 B：测试的敬业等等很多是个人习惯，webx是一个方向性问题，可能现在不会做，但不代表以后不做，webx基于某个framework,耦合性比较高，在这方面页面自动化测试优势很多，代码质量开发人员有很大责任，对开发而言基于webx会页面自动化更方便，可能达到的覆盖面更广。 C：很多观点和雷卷一致，webx是否要取代页面自动化或者功能测试，是相辅相成的关系，测试设计就是用来做选择，希望能够提供一定得技术手段来供选择，代码是调用关系，我们需要从上面一层去覆盖，从webx做跟业务关系更紧。 D：反方关注到了一些额外成本的投入，代码的积累是否是最合适的方式，目前人工的力量更多，期望更多的能交给机器。 E：感谢8位选手，测试的手段很多，确实是一门艺术，webx并不是来取代某种测试，web层测试能够提高多少效率。
收藏
举报
TAG:
