从 0 开始做后台测试

作者：赵燕

团队：腾讯移动品质中心TMQ

从用户反馈说起

“我备份的照片怎么不见了”；

“出现服务器错误-1001”；

“下载的照片无法显示”。

用户反馈，测试过程中经常遇到各种与后台相关的非必现问题，对于一个重后台功能的产品，包括很多业务逻辑和用户的数据都与后台强相关，若只是通过客户端来测试后台功能的话，在遇到上述问题时，分析和重现问题对于测试人员来说非常困难。

除此以外，在日常的测试中，后台相关的测试还面临以下几类问题：

1、后台测试的充分性和完整性的保证；

2、不与客户端直接交互的功能，无法通过客户端的用例来直接覆盖到所有功能点；

3、面对一些偶现问题，无法定位问题，不知从何下手；

4、后台的一些服务改动和发布，回归测试非常耗时。

为了解决后台测试面临的问题，于是开启了产品后台测试的探索之路，按照以下思路进行：分析产品的后台架构>客户端交互的后台接口测试>TAF后台接口测试>后台服务性能测试。

分析产品的后台架构

下图是产品后台的部分架构，由分片上传服务，业务处理服务，用户数据服务，照片压缩和照片加密服务组成。

业务处理模块：该服务主要实现业务逻辑功能，包括图片上传、图片下载、创建相册和图片分类，如下图所示。该服务中的接口都是与客户端直接交互的。可以通过模拟客户端的请求来测试业务处理模块中的接口。

用户数据服务：用户文件存储的是用户图片相关的信息，例如图片的SHA，URL等，用户数据存储的是联系人信息和短信信息。

图片压缩服务：压缩图片成为各种合适尺寸的图片缩略图；

加密服务：加密服务包括加密数据接口和加密密钥接口；

用户数据服务，图片压缩服务和加密服务，这三个服务的接口是不直接与客户端进行交互的，无法通过客户端模拟请求来测试，因此针对这三种服务的接口通过访问TAF接口的方式来进行测试的。

图存平台和TFS等属于外部公共接口，暂时不在测试范围内。

与客户端的后台接口测试

框架接入和问题解决

通过客户端测试后台因为其他产品已有现成的框架，新产品的接入只需要分析现有框架是否适用或是否需要做二次开发。

1、分析框架是否适用，产品前后台接口通信协议都是使用的shark协议，评估并测试后确认可以使用现有的框架来开发用例；

2、分析产品的接口，我们产品的接口功能都依赖于登录态，大部分接口都需要校验登录态loginkey，因此需要搞定登录态的问题；

（1）参考手Q快速登录提供的WTLoginSDKDemo，修改其中的参数appid为对应产品相册的appid，并且把该SDK集成到后台测试框架中；

（2）启动测试后，根据输入的QQ帐号密码拿到即通返回的A2票据，存入到SD卡中，A2票据的有效期为1个月；

（3）QQ帐号及A2作为登录接口的WTLogin的请求参数，解析接口的返回结果拿到登录态Loginkey；

（4）Loginkey是作为后台登录态的唯一校验。

3、产品接口请求参数photoInfos中的SHA是需要校验的，需要获取真实照片的photoInfos。

（1）单独出一个公共类PhotoInfoUtil构造phtoInfos中的请求参数字段；

（2）编写获取照片SHA的函数;

（3）接口测试用例中的请求参数SHA直接调用PhotoInfoUtil.create(path).sha赋值。

后台接口应用案例

1、需求描述

新功能照片地图的照片标签功能，客户端通过上传本地照片的经纬度信息到后台，后台通过调用腾讯地图的API返回城市信息给客户端，客户端显示在照片地图上显示城市信息

2、测试分析

（1）苹果系统使用的是高德地图的API，而我们的产品后台使用的是腾讯地图的API，需要测试城市信息是否显示一致；

（2）选择城市的测试样本，一是参考产品用户照片地点的分布，二是参考蚂蜂窝热门旅游城市，最后综合考虑选择了蚂蜂窝的270个热门旅游城市作为测试样本；

通过客户端手工测试，需要人工准备270个热门城市的照片，测试结果也需要人工判断，预计耗时需要5天；

（3）分析后台接口，请求参数中填写照片经纬度信息，批量构造270个热门城市的经纬度信息存入数组中，通过请求接口CSBatchGetAddrByCoord返回270个热门城市的城市信息，预计耗时1.5天；

（4）照片地图照片标签功能，客户端只是上传照片的信息到服务器和显示城市信息结果，无复杂业务逻辑和交互操作，照片标签功能适合用后台接口测试来完成。

3、测试效果

一共发现了六类城市信息显示问题，已经通过映射的关系解决部分重点问题，测试效率提升了70%，特别在后续的回归测试中5分钟即可以完成一次测试。

后台TAF接口测试

用户数据服务的接口不与客户端交互，是后台TAF接口，通过直接访问TAF接口来进行测试。

TAF知识准备篇

JCE文件：JCE文件是TAF框架中客户端和服务端的通信协议，是一种类C++语言的标识符，用于生成具体的服务接口文件，了解JCE的语法规则，关键字，基本类型，复杂类型，名字空间和接口是做TAF接口测试的基础。详细知识可参阅《TAF-使用指南和规范》。

Makefile：TAF框架提供了一个makefile.taf的基础Makefile，使用TAF实现的服务，需要遵从Makefile规范：（1）原则上一个目录是一个Server或者程序，即Makefile只能有一个Target，（2）需要包含其他库时，根据依赖关系倒序include在Makefile文件底部。

TAF框架使用：做TAF接口测试仅需要了解C++客户端的使用，客户端对服务端完成收发包操作是通过通信器(communicator)来实现的，通信器可以使用配置文件初始化通信器，也可以直接使用属性初始化，通信器不需要自己创建，直接采用服务框架中的通信器即可。

单个接口测试

（1）连接服务器, 定义初始化服务器变量taf::CommunicatorPtr _comm; 服务器init函数。

Locator:registry服务的地址，必须有ip port的，如果不需要registry来定位服务，则不需要配置。

Property：属性上报地址，如果没有配置，则上报的数据直接丢弃。

（2）请求TAF接口，选择转换DataInteface.jce文件成 c++语言，在生成的DataInteface.h中找到服务的接口操作类typedef taf::TC_AutoPtr DataInterfacePrx;定义变量QQPIM::DataInterfacePrx client;

以上是接口long getDataList(long UIN, string dbdir, out vectorreslist)请求服务操作，getDataList是接口名，UIN和”cont”是请求参数，relist是服务器响应结果。 （3）编译运行，写好的接口测试代码放到linux服务器上运行，可以通过跳板机登录，编译通过的可执行文件，发送到服务器上运行。

Makefile文件包括编译需要的JCE文件外，还需要有编译依赖的工具类库文件，值得注意的是不同的服务Makefile文件可能不一样。

举例：加密服务和用户数据服务的Makefile文件所包含的库文件就有区别：

多个接口测试

分析接口之间的关系，其中多个接口间存在依赖关系的（即前一个接口的输出结果是后一个接口的输入参数），则可以通过在一个测试类中实现多个接口测试函数来实现。

TAF接口每日监控运行

1、是由一个shell脚本qqpimtest.sh运行所有接口的可执行文件，并把运行结果重定向到文件qqpimtest.txt中； 2、解析接口测试生成的报告文档，将文档报告数据进行HTML编码； 3、通过服务器上的邮件系统，将邮件定时发送出去，邮件模版如下图所示。

未来测试计划

本篇文章介绍的是在项目中如何从0开始做后台测试，主要侧重的是项目后台架构的分析，测试后台接口功能，能解决后台功能测试的问题。涉及到接口稳定性和高负载情况下服务器处理超时问题是部分偶现问题出现的源头，因此下一步会重点研究后台性能测试。

获取更多测试干货，请搜索微信公众号：腾讯移动品质中心TMQ！