总结篇之接口测试
如下内容是两年前初做接口测试时的一个阶段总结,分享出来大家仅供参考,有不足之处希望多多指正。
接口测试理论
理论方面我们从如上四个问题进行解读:
- 什么是接口测试?
这个网上有很多概念,简要解释如下:
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。按照定义很容易我们知道接口测试主要关注的点应该在数据的交换,传递与管理和接口之间相互依赖关系。按照不同组件之间的接口类型,接口测试有如下几种分类。
- 为什么做接口测试
2.1 接口测试越来越重要:因手机计算能力有限,另外移动应用必须省电,因此大量的计算,数据存储,业务处理等活动需要放到服务端由大型服务器来完成。在服务器端完成计算后,通过REST接口来获取到想要的计算接口,然后展示。所以说服务端的接口的测试就尤其重要。
2.2 测试前置:软件系统的开发不在遵循传统软件的开发模式,我们需要的是快速上线,快速发布。由于测试在整个软件开发流程的最后阶段,能不能快速上线,快速发布。测试能不能在保证一定质量的前提下快速完成就成为了很重要的一环。依赖树的结构开发接口,我们不等到客户端开发完成,提前测试服务端接口可大大加快进度。
2.3 节约测试成本:由于接口测试阶段更接近底层,发现底层的问题的直接性更高,难度相对UI测试要低很多。可能底层接口上的1个BUG,会导致UI测试功能上的8个BUG。
2.4 自动化持续集成:自动化集成就是我们完成了一个项目的用例后可以上传SVN或者git,归档之后可以定时在teamcat上跑接口,当后期开发改了某个接口可以快速的发现对其他接口有没有影响,帮助回归测试,每天设置时间定时运行,并且能及时发送结果邮件。谈起自动化集成方便回归测试,我觉得只有真正用起来的人才能深有体会。例子如下:
- 接口测试流程
我们来说说这些信息,对我们来说有什么用处。开发人员,项目开始结束时间这些信息从项目角度来说,是必须的。你需要知道在测试过程中和谁交互沟通,你需要根据项目开始结束时间来安排资源。测试环境,数据库信息这些是我们接口测试的基础。需求文档,API文档这是我们接口测试的依据。第一次提测时间,是我们开始投入资源测试的时间,接口提交频率决定了我们能否在开发完成的同时完成测试。(这里说的同时是指开发在提交最后一批接口时完成了前面所有接口的测试)。开发提交可测接口的频率过低,会导致测试介入过晚。从而不能完成测试。提测频率过高,有可能会影响开发的效率。 - 接口测试与app测试对比
如上图,针对基本业务功能进行测试,两部分有重合的地方,但关注侧重点有所不同。接口测试:更关注于服务器逻辑验证;app测试:更关注于页面展示逻辑及界面前端与服务器集成验证。在业务规则的边界来考虑,边界分析测试会有重合的地方。但app前端的输入输出很多时候范围有限。单接口测试上没有限制,覆盖的范围更广,出现问题的概率也更高。
结论:接口测试和app测试的活动有部分重复的内容,主要集中在业务功能测试方面。除此之外,针对各自特性的测试都不一样,需要分别进行有针对性的测试,才能确保整个产品的质量。
上文持续集成提到的Teamcat 部署方式支持docker一键部署,shell一键部署两种方式,可快速投入使用。详细步骤请见Github Readme文档。如果大家有问题以及改进建议,欢迎与我们多多沟通交流。
Teamcat详细介绍
Demo展示地址:http://www.teamcat.cn/
Github地址:https://github.com/TeamcatCorp/Teamcat
我们的联系方式:
扫码加入即可,欢迎多多交流~
注:如有转载,请注明出处。