引言
又到周末了，思前想后不知道写点什么，那就从以前经历的一个线上缺陷说起，聊一下软件质量保障的巡检技术。
我认为质量保障的手段有主动发现与被动发现之分。通常，大家所听到的测试左移，例如测试参与的code review、每日运行的接口自动化用例以及软件测试异常注入等，可以划分为主动发现缺陷的手段，可以理解为对缺陷发起主动“进攻”。而项目上线后，主动缺陷发现手段则不便在生产环境继续使用，当然根据测试右移的思想，我们可以通过生产环境服务监控、错误日志发现等被动方式监测到线上的抛错问题，可以将此手段归类为被动发现手段。主动和被动手段没有哪种更好之分，都是质量保障的一部分，二者结合方可提升业务测试质量。
大家都知道，软件测试是无法穷举测试的，即测试只能证明软件存在缺陷,不能证明软件没有缺陷。主动手段不能保障产品发布后就不会有缺陷产生，因而可以使用被动手段弥补，监控风险较高的功能or服务。
此外，做过接口自动化的小伙伴都知道，自动化用例是否有效，可以将发现的缺陷数作为一个衡量指标，这样测试人就必须尽可能丰富用例的断言内容，例如接口断言、DB断言等。纵然如此，断言在某些场景下仍然存在不足。因为有时候即便不合理的业务输入也可能存在正确的输出结果。今天介绍的案例就是这样的一个case。
案例
业务场景是这样的，存在一个服务A，可以根据输入内容，将内容中存在的MP3信息解析出来，然后转存到我们自己的服务器上，生成一个MP3的链接地址，并在前端页面（用户端）渲染出来（允许用户点击播放MP3内容）。
起初测试同学测试这个服务的时候，没有考虑MP3本身的可播放性，只是通过页面展示的MP3图标作为预期结果（当然测试在真实测试过程也会主动去点击播放，但是问题是mp3太多，所以不能全部都点击播放一遍）。接口测试也是只对接口返回的MP3标签内容进行check，没有对其可用性进行断言。
代码语言：javascript复制<audio src="mp3 url" id="yourid" controls="controls" loop="loop"> </audio>突然有天就接到了来自业务方的反馈，说C端用户投诉APP端展示的MP3内容无法播放，影响了用户体验。我们这边开发通过排查发现，确实在转存服务器的过程有些MP3文件本身损坏，导致无法播放。开发意识到服务器上仍然存在损坏的mp3文件，需要对服务器上的Mp3文件进行一次全量的扫描。因为数量之大，肯定不可能考虑人工check，只能使用自动化手段，而我通过研究MP3自身属性发现，损坏的MP3属性相比可播放的Mp3是不完整的，可以通过自动化的手段在线扫描MP3自身属性，如果发现MP3某属性缺失可判定为文件损坏。
TIP 通过FFMpeg可以查看MP3属性，具体操作详见 https://ffmpeg.org/ffmpeg.html
有效的MP3会有Metadata，而无效的MP3则无，可以肯定的是损坏的MP3属性是不完整的。
代码语言：javascript复制 Metadata:
comment : 5023415_499131
genre : 5023415_499131
encoder : Lavf56.4.101
disc :
track :
artist : Dan Gibson
title : The Canon Stirs
album : Pachelbel: Forever by the Sea
Duration: :04:25.95, start: 0.025056, bitrate: kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 320 kb/s
Stream #0:1: Video: png, rgba(pc), 500x500, 90k tbr, 90k tbn (attached pic)
Metadata:
comment : Other
解决方案
为了解决这个问题，针对存量MP3，我们通过脚本进行一次全量扫描，发现损坏MP3即下架；针对增量MP3，将脚本部署到服务器作为巡检脚本，通过Jenkins调度此任务，每日定时对当天产生的MP3文件进行扫描，发现损坏MP3，告知相关同学进行重传或下架。
第一时间想到的使用Python的eyeD3库进行MP3属性信息获取，可以使用如下代码查看MP3标签信息。
代码语言：javascript复制import eyed3
audiofile = eyed3.load('Valid-TheCanonStirs.mp3')
# audiofile = eyed3.load('invalid-test.mp3')
print(audiofile.tag.title)
print(audiofile.tag.artist)
print(audiofile.tag.album)
print(audiofile.tag.track_num)
如果有效MP3，则输出，否则则会报错。
所以有时候自动化并不一定需要多高深的技术来实现，简简单单代码就能实现自动化（当然上述代码不是用来巡检的脚本，因为量比较大，需要多进程并行检测）。改进后通过巡检技术方案检测损坏MP3的流程图如下：
因为是离线巡检问题数据，这个方案仍然存在一定的延时性，但是我们当时的业务对实效性要求不高，只要当天能把入库的MP3巡检完毕即可，这样也可以解决问题了。
思考
巡检技术其实不是什么高深的技术，可以理解为接口自动化的补充，去做一些直接通过断言无法做（抑或断言成本高）的事情。对于实效性要求不高的业务，可以借助异步手段实现数据准确性校验。对于实效性高的业务，建议让开发对服务多打日志，通过检测错误日志（当然错误日志也是有等级的，这个可以根据基于业务自身定义，级别较高的需要立刻响应）实现第一时间发现问题并报警。
此外，为何借助于Jenkins实现任务调度，难道使用Linux服务器自身的Crontab实现定时任务不行吗？答案是可以的，但是Jenkins更易于巡检任务的管理，特别是当巡检任务比较多的时候，可以将Jenkins理解为一个简单的巡检任务管理平台，在Jenkins服务器上部署巡检脚本、报警等配置，算是一整套的解决方案（部署->调度->报警）。当然了，Jenkins管理巡检任务也有缺陷，例如巡检发现的问题统计，如果想做的更好建议开发简单的巡检平台，考虑从 脚本开发->部署->调度->报警->数据统计 全流程覆盖。实现也简单，工作量更多在于前端管理系统开发，调度/部署层 可以基于Jenkins Open API实现（以后有机会详细介绍Jenkins），直接调用接口即可。其他的可以额外开发接口即可。
好了，就到这了，最后给大家抛一个问题：评判接口自动化用例是否有效的指标有哪些？
