02-服务端测试的一些经验和心得

----------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------- 

1.服务端测试内容

服务端测试通常有2个方面、2个层次的划分。

一种是基于业务的web或app后端服务的测试

通常是接口测试，可以借助postman，jemeter等工具进行手工测试，

后续利用testng, pytest等测试框架写成自动化测试用例，以供线下准入测试和线上回归测试。这种接口测试一般更

贴近上层业务的功能，比如购物下订单，支付等业务的功能层面。也有特殊的后端服务不提供对外接口调用，需要

测试自己实现客户端请求后端服务。这个层面对测试人员的要求重点在于精通业务，功能细节，逻辑细节，设计出

详尽的测试用例。

一种是对后端服务所依赖的数据库，缓存(redis)，中间件，文件系统等所做的测试

这些一般是基础服务，是后端服务都需要依赖的。测试这些服务更接近底层，更关注的是整个系统之间的模块关系

以及系统整体的质量。我们也对基础服务做一些接口测试，自动化测试。在这个层面，对测试人员的是重点要了解

系统整体架构图的，数据流，调用关系，依赖的模块、组件的技术方案和实现原理（笔者自己很喜欢画系统架构图，

帮助自己理清测试思路），才能针对底层服务设计较好的测试用例进行测试。

从测试切入的角度来看，服务端测试还包含异常测试----一种反向测试的手段

不仅设计异常功能用例，还需要构造系统内

的故障情况（如数据库宕机，缓存失效，硬件故障，网络异常等）来测试系统的容灾设计方案是否生效，服务是否按预期降

级，兜底方案能否兜住，保证主要业务正常运行。

当然，不得不提的是性能测试

后台服务接口对请求的响应速度，业务qps最大扛量，底层数据库，缓存等服务是否被击穿，

服务器计算资源，存储文件系统是否满足大量请求，高并发请求的要求。可以通过jmeter, loadrunner工具或者自己编写脚本

压测后端接口，以及整个服务链路。

对于业务来说，还有负载测试，压力测试，7x24小时的稳定性测试等。

2.服务端测试用例设计

服务端测试做得好不好，收益如何，较大程度上取决于服务端测试用例的设计。

此处先声明，不仅是服务端测试，一个优秀的qa，不论负责哪个方向的测试工作，设计全面详尽的测试用例，都是必备的技能和素养。

下面谈一下服务端测试用例设计的一些心得，都是来源于日常的工作以及周围同事、同行分享的案例。

首先，服务端测试用例设计，一般从接口出发去考率，因为通常我们做服务端测试，最直接接触到的就是开发提供给我们的服务端的接口。

但是必须明确的是，做服务端测试绝不等同于单一的接口测试。

这里讲一个笔者刚入行时，将服务端测试简单当成 "接口测试" 的幼稚做法案例。应届毕业刚从事第一份测试工作时，

负责云计算产品的一个模块“dns解析”的测试。开发给提供了创建一个dns解析记录，删除和修改一个dns解析记录等接口。

笔者那时刚学着了解http协议，状态码等十分兴奋，很快地使用testng+httpclient框架编写出了接口测试用例，彼时只认为

http接口返回200就是成功，返回400、500等就是失败。

后来经过有经验的同事的指导，才知道接口测试绝不能仅仅关注接口的返回状态码，而应该着重关住最终的功能是否实现。

如上案例中，创建dns解析记录后，应该依次检查接口返回值，数据库是否按预期插入数据，新建的dns解析记录是否按时生效，

能通过dig+域名，解析出预期的ip地址，才是真正对服务端功能做了完整测试。即这个接口所有产生影响和改变的点都应该一一校验。

尤其对于一些异步的接口，异步接口通常提交一个任务，提交成功绝不意味这任务最终能成功，可能因为资源不足，用户授权失败，

网络中断等等各种原因导致最终任务是失败的。所以一定要校验到最终结果。这种案例在交易支付系统十分常见，扣款异步任务失败，

中奖提现最终失败等。

一个必备的基本技能：对接口的输入参数做各种组合测试

通常拿到接口的第一步，就是测试接口的鲁棒性。比如接口支持2个入参，就要对这2个入参的数据类型，取值范围，入参数量做多

种组合设计测试用例（等价类划分，边界值，异常值）。如果对各种参数组合的测试都不能满足，第一步接口层面就诸多问题，还

走不到测试后续更多更深层的场景。这一步是必不可少的。将这些用例自动化后，是很好的回归工具。

反向用例/异常用例安排上

有时测试系统的功能很复杂，测试人员往往容易陷入对系统内部细节的正向场景组合测试，力图做到全面细致，会容易忽略了反向or

异常的场景，而这一点，也通常是研发同学自己在写代码时也容易忽略的。因此，这类bug很容易被带到线上，由于异常场景才能触

发，所以潜伏周期长，对线上业务来说，是隐藏的定时炸弹一颗。

案例一：笔者曾经测试过一个关闭sesion的接口，关闭session的方式有多种，笔者沉迷于测试每种关闭方法是否生效，对正向功能

和组合用例做了详尽的测试，却漏掉了2个场景。

一个是场景：这个session不存在时，接口也返回了200，预期应该返回404，并携带message类似"session not found"来提示用户。

----这个bug影响相对较小

另一个场景：session传参正确，另一个参数传参与该session不匹配，系统内部没有校验，直接返回关闭成功，实际上不可能关闭成

功。----这个bug影响就很大，会让用户误以为操作成功，实际后台没有成功。

还有一种反向用例的经典场景是鉴权接口。

传参使用在数据库已配置的正确鉴权key去鉴权，返回成功，放行。但有时候粗心的qa常常忘记了测试传参使用错误的鉴权key去鉴权

是否返回失败，禁止放行。

这中鉴权接口如果没有测试反向用例，是存在很大的系统安全隐患的。加入研发代码也没考虑周全或者有bug， 就会导致错误的key也

可以通过鉴权，系统可能被攻击，盗取数据等，损失惨重，危害极大。

场景用例是接口用例的补充增强剂

接口只实现单个功能，将接口实现的功能串联起来，才是真正的业务场景。比如最常见的增删改查接口串联场景用例。

单个接口给功能正常不代表系统对用户场景整体运行正常。

比如直播时推流--拉流--拉转码流--内容审核平台接口杀流--观看直播流录制产物鉴定内容是否违规这个场景就是单做接口测试无法保证的。

最关键的一点是场景用例中可能有模块间调用，一种极端情况是a和b两个模块网络不通了，但是测试单独测试a的接口和b的接口都可以成功。

而且组合场景测试通常顺带清理了测试环境（因为一般都会带有删除操作），是一种很清爽的测试用例

小量并发作为功能测试用例--或许能发现一些隐藏问题

直播的拉流测试，当验证用例-推一路流并拉一路流-时，测试能通过，但是写了一个推3路流，并拉3路流时，用例没有通过，

因此发现了一个拉流的bug。程序对于处理单个和多个的情形时可能存在不同，有时候需要小量的并发请求作为功能测试用例

关注生效时间

上一个步骤或者场景的生效时间可能影响下游服务的成功率和稳定性，比如直播录制ts切片--上传tos--写入数据库tos信息记录这个过程，

如果生效很慢，可能影响后续m3u8的生成，因为生成m3u8时首先读取数据库中ts信息再去拼接，若读不到就报录制m3u8失败。自动化

测试用例没有中没有加等待时间，对于以前的老架构，生效时间不影响录制m3u8，对于新架构，生效时间影响录制m3u8，自动化用例

因为没有加等待时间，意外发现了新架构的问题。另外一点，是否需要等待时间，也需要结合实际业务的场景设计用例，才能发现更多

问题，qa应多思考

用例执行的时机/频率

对于一些隐藏较深的bug，触发的几率很小。用例执行一次通常会表现为通过。这种bug通常在压测或者线上全量的时候暴露。

一个思路是把用例自动化，并调整期执行的时机/频率，多跑跑，或许能够触发。

曾经遇到一个bug， 自动化脚本7x24小时不停运行，才能偶然碰到bug触发的时机，且这种bug一旦在线上触发，可能是比较大的灾难。

找到了以前的复盘case_study文档，贴下这个case的前因后果，也由衷感激当时让我写case_study的领导。

现象：某个私有云线上监控运行一段时间偶现报警“dns删除域名失败，删除后仍能解析到对应域名”

原因：DNS提供域名解析的是coreDNS。调用DNS接口操作Etcd数据后会及时推送到coreDNS，并且coreDNS会定时一小时从Etcd

数据全量缓存数据。当全量缓存数据已取出并在网络中传输，此时调用了delete接口修改了Etcd数据，并推送到coreDNS之后，全量

缓存数据才到达coreDNS，此时全量缓存的数据中没有删除域名，因此coreDNS还存在这个记录，所以即使删除接口返回了200，

仍然能解析到域名。最新数据与历史数据乱序。出现的概率很低，通过长期稳定性测试才能发现。

解决：开发修改对应代码逻辑。因推送的数据具有最新时效性，如果刚好在进行全量缓存，就先关闭推送。等全量缓存结束后，再推送。

总结：这个bug由于出现的概率非常小，是一种很“巧合”的情况下出现的bug，测试很难测到，所以部署7x24小时的业务监控脚本很有必要。

长链路的单步验证--最终表现的成功不代表执行链路上的每一步都正常

对于一些链路较长的测试场景，通常为了省事会直接验证最后一步的结果，将最后一步成功等同于整个链路成功，大部分场景这种假

设没有问题，不排除一些特殊场景，最后一步的校验虽然成功了，前置步骤的操作可能是不成功的或者是成功的时效不符合业务要求。

因此测试时，采取单步验证，是比较稳妥的办法

设计分层的测试用例--黑盒表面运行正常不代表黑盒内部每个零件都正常工作

对于直播推流，拉流测试，需要进行分层用例设计，具体讲，测试推流时，可以使用基于服务器内网ip的推流url, 基于服务器自身

公网ip的推流url, 基于公司ttgw网关vip（负载均衡）的推流地址，基于业务接入层的推流域名的推流url, 分成多层测试，一是可以

准确定位到具体失败的位置，二是能够精准测试，精确到某个具体的服务器推流链路是否畅通

锱铢必较的校验大魔王

测试的工作核心就是校验。同样的测试用例，不同的人用自动化实现，带来的测试收益可能差别很大，这取决于校验点的设计。

笔者的一个经验是，不妨做回”锱铢必较的校验大魔王“。

这里有2个案例分享。

一是笔者在测试直播流借助AI实时生成翻译字幕的功能时，为了便于失败后查问题，调用了录制接口将测试的直播流录制下来。

本来笔者测试的重心是字幕生成，笔者也对字幕生成的结果做了详细的校验。录制不在本用例测试范围。但由于笔者的“强迫症

心态”，还是顺带对录制的结果也进行了详细的校验，结果发现了录制功能返回的回调url地址错误，网页打不开的问题，间接发

现了录制模块的一个较大的bug, 也算个意外收获。

二是笔者在设计直播流后处理审核链路的线上巡检自动化用例时，对音频切片每10s切一片这个功能，不嫌繁琐的获取每一片并

计算其时长，十分严格按预期进行数学上的校验，产生了很好的效果。一次软件版本，导致线上音频切片变成非10s一片，有1s的，

14s的，19s的等，研发同学的线上有很多种维度的报警和监控都没有报出这个问题，但是笔者的qa巡检任务立刻报出来这个问题

并及时提醒研发同学回滚了软件版本，避免了线上的事故，这个是一个让笔者很开心的收益。也坚定了笔者从事测试岗位坚持

”锱铢必较的校验“这个观点。

分页的样例--来自同事

分页接口：卡片的列表，比较简单，实际有用的参数只有一个cardtype

上行参数：

pageNum int

pageSize int

cardType enumerate 0:所有， 1: 动漫，2： 音乐

下行参数

{

[

"id": 1233,

"cardType": 2,

"name": "alpha"

],

[

"id": 1234,

"cardType": 1,

"name": "beta"

]

}

一般的用例：

pageNum不传，负数、字符串

size同理

cardType为0，1，2，不在范围里的

组合的情况

返回的参数对不对

问题：

1. 太focus在参数组合的情况，没去想参数对用例的影响
2. 侧重入参，但返回参数校验不够：比如字段有没缺失、类型对不对
3. 和功能不耦合，多去考虑情况，如果给的场景不清晰，要质疑
4. 异常的校验过度关注在参数层面，而非功能层面，一般复杂的接口可能涉及到不同的模块，功能层面的异常情况才

        是更容易出现，比如订单状态已退款，再去走结算的逻辑会怎么样

补充举例：

分页的默认值，（非法值、或空值默认第一页，20条？没有的话找产品确认）

cardType 由于是枚举，不传比较特殊：是都需要返回所有类型的卡片；

每一种枚举值

组合枚举值允许么

不在枚举值范围内的如何处理

下行参数要校验：列表项每一个字段是都如要求返回、类型是否正确，值对不对（比如卡片类型搞串了）；

id是不是唯一，名字为空的话是null还是""、有无截断；

分页逻辑可以校验下: 比如确认有70条数据，可以查下最后一页，是不是返回

更新的逻辑，有缓存否，多久更新，更新策略（结合压测可以扯一扯）