集成测试用例设计的一些感悟
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
集成测试用例设计的一些感悟
最近在搞接口测试,自己对接口测试的一点初见;
集成测试又等于接口测试(个人认为),是在单元测试中的一个,可以认为是单元测试,又可认为是接口测试。
集成用例设计基于业务场景,其实说白了集成测试是按照详细设计来写的,但其输入的数据来源则是来于uc,设计思想如下;
先进行数据准备,数据准备的思想来源于uc,分析出uc的业务场景,通过各个业务场景来产生各个类型输入数据;
又叫数据准备;
数据准备好了,分析接口参数,从数据库字段的限制分析,输入的参数合法不合法,长度如何,是否可为空;
这个又叫假定接口参数的不正确性;
结果期待输出值的各种情况;
可以把接口想象一个盒子我们输入预期的数据,给我们返回预期的结果;
但这有个问题就是无法知道盒子内部的逻辑是否正确?
内部的逻辑严格讲应为单元测试,单元测试应保持内部逻辑的正确性,可单元测试和接口测试界限并不是那么清楚,所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常;
由于内部的异常不一定是输入的数据造成的,但却有可能是其他逻辑造成的数据丢失的情况;
例如:有个删除功能将数据表中的一条记录删掉,而提供给外部的接口是要查询到这个数据才能返回成功;
这样内部的异常还是有可能存在的;
总结:
1、数据准备;来源于uc的业务场景分析;
2、接口;参数分析;错误和正确;
3、内部逻辑分析。