如何在合适的时机引入接口测试V0.3

Posted 2021-04-24 51Testing软件测试网

　　一、背景介绍

　　首先要简单说下推荐系统，这是一个采用thrift协议为其他服务提供相关推荐数据的后台服务系统，该服务主要包含q2u（为用户推荐感兴趣问题），u2u（为用户推荐感兴趣的用户）等多个子服务，要求针对每个子服务做负载测试，寻求系统最大所能承受压力。作为小白的我思考之后很快制定了测试方案：

　　有过重大专项测试经验的朋友一定会有这样的体会：'功能测试初期发现的缺陷（Bug）比预期的多，多到了让人怀疑程序是否通过了前置的单元测试'。虽然这样的情况屡见不鲜，但事实并非如此，以至于开发人员来说，大量的缺陷'提交-修复－再提交'的恶性循环，使得整个项目进度受到了影响。

　　经过分析，我们发现这样的场景往往发生在多模块松耦合架构下系统间交互接口的通信或相互调用上。尤其是涉及到多系统间接口差异大、报文流转复杂、业务场景多样化的时候。虽然开发人员通过了程序模块的单元测试，甚至通过了一些基本的集成测试，但是业务场景覆盖性方面难以保证。如果直接进行'关注度在交易级的'功能测试，而忽略'接口级'的覆盖，测试初期的缺陷（Bug）逃逸率也必然相对较高，如果不及时处理，越靠近实施后期，修复这些缺陷的成本和风险就越大。

　　不过也不用担心，这些问题是有规律的：

　　1. 被触发的条件简单

　　虽然利用简单的测试方法和正常的业务流程就可以使一部分缺陷暴露出来，但并不能使问题暴露达到预期的最大化。

　　2. 缺陷集中趋势表现成模块化发展

　　程序的缺陷往往在某一个或某几个模块中表现非常突出，正所谓"缺陷的区域性"特点。

　　3. 缺陷主/子流程节点叠加

　　前一缺陷修复后，往往会暴露更深层次的问题。一些主流程节点的缺陷被修复后，子流程节点和报文流转的下游往往出现更多或更深层次的问题。

　　4. 接口不规范、需求理解差异化导致存在缺陷

　　对于需求不明确、接口定义模糊的情况会造成测试侧重点偏离的情况，使一些问题不能及时发现。

　　 

　　在哪个时间引入"接口测试"最"划算"呢？单元测试之后和功能测试之前。因为：

　　1） 可以扫清低级接口问题，使得缺陷在早期暴露；

　　2） 可以提升代码质量，变向缩短功能测试、专题测试、整体测试周期；

　　3） 可以通过接口分析，能分析出不易想到的业务场景；

　　4） 接口级问题修复/测试，高速迭代时间成本更低，程序修复速度更快，投入产出较高；

　　5） 更贴近灰盒测试，有助于测试人员将测试从抽象到具象，让业务、技术能力同步提高。

　　而且，接口测试和功能测试的关注点有所不同。

　　接口测试相比功能测试颗粒度更细，且覆盖的偏重点在于交易的报文层面，它并不是黑盒测试那样在功能界面上通过交易按钮触发程序流程，覆盖测试案例。接口测试一般安排在功能测试的前期，相比功能测试，有着案例覆盖简单、接口级的粒度覆盖更细、底层问题暴露几率较大的优点。多系统交互的项目测试活动中，在功能测试前期引入接口测试，能较大的降低缺陷逃逸率，减少后期底层代码的修改而造成的项目风险。同时，也能避免逃逸的缺陷影响到其他交易模块，被其他模块接口适配，造成潜在的风险。

　　所以，在涉及多系统交互的重大专项功能测试前期，我们要引入接口测试。

......

本文出自《51测试天地》原创测试文章系列（四十二）

读者互动环节

你认为在哪个时间引入"接口测试"最"划算"呢？

欢迎留言发表不同的评论~~

点击左下角“阅读原文”查看全文内容！