一、背景介绍
首先要简单说下推荐系统，这是一个采用thrift协议为其他服务提供相关推荐数据的后台服务系统，该服务主要包含q2u（为用户推荐感兴趣问题），u2u（为用户推荐感兴趣的用户）等多个子服务，要求针对每个子服务做负载测试，寻求系统最大所能承受压力。作为小白的我思考之后很快制定了测试方案：
有过重大专项测试经验的朋友一定会有这样的体会：'功能测试初期发现的缺陷（Bug）比预期的多，多到了让人怀疑程序是否通过了前置的单元测试'。虽然这样的情况屡见不鲜，但事实并非如此，以至于开发人员来说，大量的缺陷'提交-修复－再提交'的恶性循环，使得整个项目进度受到了影响。
经过分析，我们发现这样的场景往往发生在多模块松耦合架构下系统间交互接口的通信或相互调用上。尤其是涉及到多系统间接口差异大、报文流转复杂、业务场景多样化的时候。虽然开发人员通过了程序模块的单元测试，甚至通过了一些基本的集成测试，但是业务场景覆盖性方面难以保证。如果直接进行'关注度在交易级的'功能测试，而忽略'接口级'的覆盖，测试初期的缺陷（Bug）逃逸率也必然相对较高，如果不及时处理，越靠近实施后期，修复这些缺陷的成本和风险就越大。
不过也不用担心，这些问题是有规律的：
1.被触发的条件简单
虽然利用简单的测试方法和正常的业务流程就可以使一部分缺陷暴露出来，但并不能使问题暴露达到预期的最大化。
2.缺陷集中趋势表现成模块化发展
程序的缺陷往往在某一个或某几个模块中表现非常突出，正所谓"缺陷的区域性"特点。
3.缺陷主/子流程节点叠加
前一缺陷修复后，往往会暴露更深层次的问题。一些主流程节点的缺陷被修复后，子流程节点和报文流转的下游往往出现更多或更深层次的问题。
4.接口不规范、需求理解差异化导致存在缺陷
对于需求不明确、接口定义模糊的情况会造成测试侧重点偏离的情况，使一些问题不能及时发现。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/09/n-3710809.html
二、那么如何进行接口测试？
1.接口测试前期的准备工作
·业务需求说明书
·接口规范标准文档
·数据字典
·常用日志查询工具（SecureCRT/Xshell/flashfxp工具……）
2.设计接口测试案例：
接口规范文档定义程序接口规则，报文按照接口规定的格式要求来流转。测试人员依据接口规范来文档、数据字典、业务需求说明书等文档来设计测试案例。案例设计的原则"重报文流转，轻业务场景"，案例执行通过报文日志查询结合前端交易结果来验证测试结果。
案例编写需要在报文层面与业务场景相结合往来账，充分考虑正常异常场景：
·边界值验证：报文所允许的边界值，使用在最小值、略高于最小值、正常值、略低于最大值、最大值和超大值处取输入变量值，记为：min、min+、nom、max-、max、max+
·有效值、无效值验证：有效值略。无效值验证输入无效的数值类型（空格、符号）
·最大长度输入：根据报文标准，输入报文标准中要求域的最大长度。如地址、附言、金额域等等
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/09/n-3710809.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
