本篇的目的是简明的完成一份接口测试用例设计的撰写,维护的文档,需要大家共同努力,不断完善,存在的不足以及日后在实际使用中暴露出来的问题,希望大家及时出,以便更新文档。
罗马不是一天建成的,用例不是一次完成的;书写测试用例本身和完善代码一样,也是一个循序渐进的过程。
首先,必须熟读需求说明书和接口设计文档,了解每个接口具体的使用场景,明白软件的性能指标。
其次,设计接口测试用例:开始在编码阶段,测试人员根据需求说明书和接口设计文档设计接口测试用例。
然后,codereview:开发完成编码后,在时间充裕的条件下,要进行?codereview,一方面是检查开发的代码功能逻辑是否正确,另一方面通过review开发的代码来补充接口测试用例。
最后,完成用例后,随着对系统了解的增多,不断提高用例精度,对测试用例需要进行定期review,一旦测试需求发生变化,测试用例必须重新维护。
阶段一:开发在编码,测试拿到需求文档和接口设计文档:
1、基本功能测试(业务测试):
根据需求文档和接口设计文档的转译,需要清楚业务流程规则和每个接口的使用场景方式,设计符合业务逻辑和接口使用场景的用例。
2、边界分析测试:
在基本功能的基础上,开始考虑接口输入输出参数的影响。主要采用等价类划分、边界值分析方法等。
覆盖所有的必选参数
组合可选参数
参数有无、或为null
参数的顺序、个数、类型
参数类型数值大小、输入的数值的范围
参数字串长短,Null-max-max+1
参数包含特殊字符
3、参数组合测试:
在边界分析的基础上,考虑输入条件的各种组合、输入条件之间的相互制约关系。主要使用因果图法进行用例设计。
4、异常情况测试:
接口实现是否对异常情况都进行了处理,接口输入参数虽然合法,但是在接口实现中,也会出现异常,因为内部的异常不一定是输入的数据造成的,而有可能是其他逻辑造成的,程序需要对任何异常都进行处理,比如:某个接口需要先登录获取?sesssion,如果直接调用该接口应该给出相应提示。
5、幂等级测试:
简单说就时针对连续重复提交的情况的进行测试,特别是涉及到交易金额的场景,需要验证软件是如何处理的。
6、并发测试:
两个以上用户同时操作使用同一场景时,可能引导争夺资源,死锁等现象。
7、事务性测试:
一个业务流程包含多个操作步骤,如果某个操作失败,那么整个操作需要回滚。或者调用前一个步骤的逆向接口进行操作取消。
8、大数据量时测试
数据库里数据量较大时(百万级),测试对DB进行增删改查操作的效率。
9、环境异常测试
关联系统出现宕机、超时或者无响应的状态时,接口返回提示正确,业务逻辑正确,不可存在事务性不一致的情况
阶段二:开发完成编码,测试时间充裕的条件下,需要对开发的代码进行codereview
1、review开发的代码实际业务逻辑是否正确
2、隐含条件测试:
进行codereview,检查代码中是否有隐含的默认条件。例如:F项目中的getRecommendArticleList接口,代码中默认查询返回4条记录(如下图),但在接口文档中并未提到,如果不reviewcode而开发也不告诉我们的话,这种情况肯定会漏测。
3、SQL测试:
针对需要进行数据库操作的接口,查看相关sql,对sql的正确性进行验证。如下图,一般sql的过滤条件都会比开发告诉我们的要多,所以查看sql进行验证是最保险的方式,特别需要设计组合条件的场景进行验证:
1、接口返回数据
返回json数据的层次关系是否与文档一致;
数值类型数据:?特别是金额,负数、小数转为json输出是否正确;
接口返回数据与接口文档一致;
接口返回数据和数据库一致;
接口返回数据符合业务逻辑(比如转账功能,从一个账户扣款,另一个要增加相应金额);
对于列表,应该根据请求参数,也应该验证列表的长度是否与期望值一致;
负面测试用例,应验证ERRORINFO是否与实际相匹配。
2、数据库
接口传入数据与插入DB的数据一致性;
前端某个操作涉及后台DB多张表时,每张表都要检验数据正确性。
3、安全层面:
后端接口返回给前端的数据包含敏感信息(如:姓名、身份证号、卡号、手机号、加密后的密码等)时,不能明文传输,需要加密。
后台打日志要求对于敏感信息不能打出,或者进行加星号脱敏后打出,具体有:
身份证号,用户密码(含加密后),用户手机号码,用户姓名,银行卡号
身份证号码脱敏字段为生日时,生日在日志中不能打出
4、性能层面:
接口响应时间:接口处理数据的时间也是测试需要关注的一个点。牵扯到内部就是算法与代码的优化
接口数据包大小:接口传递的数据包大小也需要关注,特别是返回给前端的接口,要把不同接口数据包大小需要做限制。
并发承载能力:多用户并发时接口可以承载合同中的并发量。
文章来源:百度文库