今天晚上回来后看到淘宝测试团队发出来的《
接口测试白皮书》，一口气将它读完，写的还是相当不错的，有非常多值得借鉴和学习的地方。
- 在工作的流程上，各个测试角色是可以互补的，接口测试的设计、用例可以跟功能和性能测试共享，从而构建出整个产品各个环节的测试案例覆盖程度。
这一点之前感触并不深，现在看来，同一产品的不同测试团队，像共享bug一样，将所有人的案例都组织在一起，一起共享是一件非常值得去做的事情。
- 我们的客户是调用接口的人，不是开发接口的人。
说的好！之前一直以为是为开发服务，看来是上面的话总结的比较好，为调用接口的人服务。
- 测试用例设计出来以后应该经过评审，并将评审结果以某种形式记录下来，作为测试实施的最终方案。评审最好由以下这些人员共同参与：需求方、设计人员、开发人员、功能测试人员、接口测试人员以及这些人员的直接主管。
我们这边的接口测试案例的设计评审还是空缺的，上周我还组织了一次功能测试人员和接口测试人员的接口测试案例评审，看来我要继续推动这件事了。
- 质量评估标准：
- 接口覆盖率是否达到要求。内部接口90%，外部接口95%。
说实话，挺高的。我们目前对自己的要求是至少70%，我们认为追求过高的代码覆盖率的意义并没有想象中的大。相反，过度要求高的代码覆盖率，可能会造成反面影响。 - 测试用例中对接口业务规则的验证是否完整。
关键词：业务规则，保证了业务规则，就保证了用户使用的大部分功能。
- 测试用例中是否覆盖接口之间的关联性测试。
- 遗留的 bug对系统的影响程度。
- 测试用例与测试代码是否一致。
我们主要通过CodeReview和自己的人品，并没有做太多严格的审核。
- 测试用例是否可持续回归。
- 经过测试的接口是否达到了调用方的标准，调用方能否使用该接口来开发出产品设计说明书所设计的应用。
可以看出，淘宝的接口测试评估标准还是挺全面的，做的确实不错！非常值得学习！
- 还可以继续提高的地方（都是我们想要做的，就不一一点评了）：
- 测试数据管理框架构建与统一
- 接口测试项目构建基础框架
- mock 框架化
- 高比例代码自动生成框架
- 接口测试工具集与三方库的本地化应用
- 测试未来遐想（想象力确实很丰富啊，同样也是我的梦想）：
- 测试虚拟化：提供接口测试虚拟机，构建测试虚拟化层。将被测系统运行在虚拟机中，与外部系统剥离，进行内部代码检测、内存检测、数据校验与逻辑检测。
- 测试智能化：智能分析系统代码，智能生成测试代码，智能 mock 外部系统，智能执行测试代码，智能分析测试结果，智能定位缺陷，智能修复缺陷。
- 测试框架及工具组合：JUnit+DbUnit+Spring TestContext Framework+Unitils+TestNG+CruiseControl+Clover
感叹一下Java相关的框架就是多啊，不像C++，难啊！我们的组合是：GTest + GMock + CCNET(MSBUILD+Svn) + 自己开发的C++代码覆盖率统计工具
