在了解具体如何做tars接口测试之前,我们先简单了解下这个测试的背景知识: Tars平台和Tars协议。
Tars是基于名字服务使用Tars协议的高性能RPC开发框架,同时配套一体化的服务治理平台,帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。
Tars是将腾讯内部使用的微服务架构TAF(Total Application Framework)多年的实践成果总结而成的开源项目。Tars这个名字来自星际穿越电影人机器人Tars, 电影中Tars有着非常友好的交互方式,任何初次接触它的人都可以轻松的和它进行交流,同时能在外太空、外星等复杂地形上,超预期的高效率的完成托付的所有任务。 拥有着类似设计理念的Tars也是一个兼顾易用性、高性能、服务治理的框架,目的是让开发更简单,聚焦业务逻辑,让运营更高效,一切尽在掌握。
目前该框架在腾讯内部,有100多个业务、1.6多万台服务器上运行使用。
Tars的最大优势在于对运营的帮助,Tars会展现整个系统的实时运行全貌,并对服务进行准实时监控和管理(具体到服务的进程级别),大大提高了运营效率,这使得开发更懂得运营,运营变得更加简单。
主要是解决在开发系统时,经常碰到的以下问题:
1、容错:任何一台服务down掉,都不影响业务的访问;
2、 高性能:在c1机器上框架3.0版本使用用O2编译,服务端提供最高达41w/s的吞吐量;
3、伸缩性:可以非常方便的对服务进行平行扩展;
4、易管理:能够在Web系统上,对Tars系统上的服务进行集中管理;
5、故障隔离:任何一个服务down掉、异常,都最大限度的不影响其它服务;
6、开发效率:提高开发效率,业务开发人员只需要关注业务本身的逻辑;
7、运维效率:提高运维效率,能够清晰的看到整个系统的运行情况,对服务进行立体化监控。
Tars的设计采用了分层的思想,各个层次之间相互解耦或者松耦合。运营只需要关注最上层的部署、发布、配置、监控、调度管理等。从开发者的角度出发,封装了大量日常开发过程中经常使用的公共库代码和远程过程调用,让开发使用更简单方便;从框架本身的角度出发,做到高稳定性、高可用性、高性能,这样才能让业务服务运营更加放心;从分布式平台的角度出发,解决服务运营过程中,遇到的容错、负载均衡、容量管理、就近接入、灰度发布等问题,让平台更加强大。
tars协议是一种二进制、可扩展、代码自动生成、支持多平台(c++/java/iphone/android/symbian/kjava/mtk)的协议,其底层设计类似于google的protocol buffer,但是不完全一样,同时其实现完全自主开发,对细节完全可控。
tars支持的类型分两种,基本类型和复杂类型。
基本类型包括:void、bool、byte、short、int、long、float、double、string、unsigned byte、unsigned short、unsigned int;
复杂类型包括:enum、const、struct、vector、map、struct、vector、map的嵌套。
tars协议主要应用在后台服务之间的网络传输协议,以及对象的序列化和反序列化等。
对于开发人员来说,Tars框架提供一套适合传输的、语言无关的通信协议,这就是tars协议。开发人员可以在tars协议文件中定义通信用的数据结构和服务提供的接口方法,为了提高开发效率并且减少错误,Tars框架还提供了工具来把协议转换成各种语言的数据结构,开发人员可以不必关注数据结构、服务基类和代理类的编写,把更多精力投入到业务逻辑的实现上。
通过接口测试可以保证后台服务对外提供的数据的正确性。接口可能是面向web、客户端或者其他一些后台服务。通过接口可以去测试一些通过客户端无法模拟的一些情况,如边界测试、各种异常数据的错误处理, 除此之外,很多测试用例通过接口来构造数据比从客户端模拟容易太多。
从我们这次任务系统重构来说,涉及到29个服务改造,以及运营配置系统的重建,逻辑复杂度很高。很多TestCase靠GUI测试不易覆盖。那么必须深入接口,对接口进行更有力的测试才能让系统更稳定。
其次,接口测试脚本可以接入到持续集成,以及进行线上质量监控。方便快速的回归以及发现问题。
新需求接口测试(功能、性能)——接口自动化脚本——接口接入持续集成——接口线上监控。
1、提测的新需求需要进行接口测试,根据接口的复杂度,会有5—30个左右的测试点。接口功能测试脚本调试通后,可以用来做压力测试;
2、创建可以多次回归,可以自动校验结果数据的接口自动化脚本的用例集合;
3、将脚本接入到持续集成系统中, 这样每天持续集成可以自动发现接口问题;
4、将接口测试部署到线上监控,可以及时发现线上质量问题。
接口测试的重点是要检查数据的交换、传递和控制管理过程,以及系统间的相互逻辑依赖关系等。接口测试可以关注于服务器逻辑验证,而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证。
怎么写接口测试用例呢? 据我经验总结,可以有如下方法:
1、看设计文档,了解基本业务逻辑,可以确认基本的接口测试点;
2、看代码,了解详细的判断逻辑处理,进一步补充接口测试点,适用于代码能力强点的同学;
3、跟开发沟通,了解里面细节逻辑处理,适用于代码能力不强的同学;
4、探索性测试,多思考边界情况、可能出现的异常点;
5、用测试建模的方法帮助分析。
工欲善其事必先利其器。可见选择一款好用的接口测试平台对接口测试的效率起着很关键的作用。
在选择工具时我试用了多个接口测试工具,包括Tars自带接口测试、客户端接口测试工具、web接口测试平台。综合对比下,选择了web接口测试平台。
我觉得一个好的平台需要有以下几点:
1、能够导入tars, 自动生成接口模板, 测试人员可以轻松编写用例;
2、用例管理,接口脚本可以通过测试集合管理起来,可以做脚本之间执行的前后关系设置;
3、充分的assert结果数据判断,方便做自动化接入;
4、可以用已经做好的接口测试脚本来做服务的压测;
5、完善的平台支持,有bug,或者需求可以尽快支撑。
这里,给下具体的举例,了解下整个执行的过程。
1、tars文件获取:
我举例的这个接口涉及到3个tars文件,在tars中定义了接口,接口的请求包体结果,返回的消息结构。
2、在Tars平台上获取提供接口服务的servant名称,并在平台上进行配置。
3、将tars文件导入到平台中,生成接口模板:
4、按照测试点来创建用例,构造接口测试数据:
5、assert设置:
在手工测试时是通过人工来校验结果数据。做自动化时,需要选择脚本,以及补充assert设置。
6、脚本执行,和结果数据查看。
(1)如果执行不通需要进行问题定位;
(2)结果返回与预期不同需要进行定位。
总结有如下定位方法:
1、看接口执行返回的错误码。Tars框架层错误,比如tars error -4, 是表示发送的servant找不到。tars error -1 表示解析包体错误。
2、如果是接口内部返回Ret=-1, 表示是后台服务判断不应该进行数据返回。这里的原因可能有多种。如传的数据不满足数据下发条件,传送的数据内容不合要求等。一般异常情况开发都会打后台日志。Tars平台查看下后台日志来确认下问题原因。
3、看日志也不清楚原因,可能性有3个:
(1)可能是测试对业务逻辑或测试点理解的不清楚;
(2)代码逻辑处理没有按业务要求来做;
(3)日志打印不充分,或者不好理解。
建议测试人员根据具体的业务需求来确定测试方法, 是覆盖客户端测试,还是需要深入到接口和性能测试。
这涉及到时间和人力投入。
后台测试不像前台(直接面向用户)有详细的需求文档。后台一般是有概要设计或者没有设计。如果想要保证测试质量,需要测分人员深入了解程序逻辑,来构造测试用例,否则测试的效果就跟单用客户端来验证接口的效果差不多了。
其次,做性能测试也需要考虑好是应该从web层来压测,还是直接压测具体服务。这根据具体改动情况来决定。
以上是我这次跟大家分享的内容。对tars的测试分析、bug定位方法,小伙伴们是否有一些更好的方法呢?
Tars开源地址:https://github.com/Tencent/Tars。
想知道更多测试相关干货,请关注我们的微信公众号——腾讯移动品质中心TMQ :