老总让做后台接口监控，我却开发了一个App

旧城等待， 2022-05-12 07:16 141阅读 0赞

最近投入到了一个新的项目中，是一个新的Android项目，项目涉及到智能聊天相关的功能，所以需要一个很好的接入层，总之肯定不能用通用的http协议来聊天。

手Q、微信等聊天软件，都会实现自己的一套协议用来发送消息，而这个协议一般都是私有协议，不会公开相应的技术细节，所以一般在没有官方支持的情况下，很难做出一套私有协议的模拟发送工具。

新的项目使用了哈雷协议作为接入层，也是一个私有协议。新项目因为项目的特点，需要对后台服务进行监控，技术上来说，必须模拟哈雷接入层的私有协议，然后才能进行相应的监控。与其他私有协议一样，哈雷协议的模拟难度是很大的，这时候该怎么做呢？

# 哈雷协议介绍 #

“哈雷深入移动互联网网络应用场景，向移动应用提供完善的最优网络接入托管、 实时消息推送、通用资源下载、App 增量自更新等服务。”

“哈雷 SDK 的网络接入服务主要针对业务前后端频繁、少量的数据收发场景，业务后台 支持ＨＴＴＰ(S)服务、TAF 服务或者支持 jce 格式调用的后台服务。”

哈雷协议主要是面向移动互联网的，官方只提供了Android以及iOS的SDK。App可以通过集成对应的SDK，完成对哈雷协议的使用。

# 传统的方案 #

传统的方案在PC上模拟请求，然后校验相应的返回结果。

## 适用范围： ##

1、对于公开协议一般比较方便，例如http、smtp等，有各种各样的模拟工具以及开源类库都可以用。

2、对于私有协议一般很困难，除非官方提供支持，否则很难做出PC上的模拟工具。例如我们的哈雷协议，只提供了Android以及iOS的SDK。

**优点：**

1、PC监控稳定性好；

2、PC性能强大，执行效率高；

3、PC监控扩展性好。

**缺点：**

1、无论是私有协议还是公有协议都会有一定的开发量；

2、和APP运行时的环境始终有些差异，不能完全代表真实环境；

3、PC上模拟代码以及参数和开发的项目代码以及参数相互隔离，不能及时同步。

# 思考新的方案 #

新项目的后台接口监控使用传统的PC上的监控的方案存在两大回避不了的问题：

首先是是开发量的问题：重新做一套PC上的哈雷模拟工具，开发量巨大，开发也不愿意承担这个任务。

第二个是后续维护的问题：后台功能的更改以及协议的升级，对应的PC上的模拟工具都需要再做调整。

所以要不断地思考，尝试寻找新的方案，自己给自己来了一次头脑风暴 。

**1、为什么要做后台接口监控？**

后台接口监控是针对后台接口做的测试，周期性触发，可以准实时地保证后台接口的功能正常性。服务出现问题后能够在10分钟内发现对应的问题。

**2、后台接口监控为什么不能用移动端的UI界面自动化测试来代替？**

客户端的UI自动化测试耗时较长，稳定性较差，同时覆盖范围有限，不能满足后台接口可用性的准实时测试。

**3、移动端只能做UI自动化测试吗？**

移动终端（包括Android和iOS）性能越来越强，扩展性也越来越强，可以说PC能做到的事，理论上在移动终端上都能做到 。

**4、后台接口监控不涉及到UI界面测试，只涉及到网络请求测试，移动端就不能做相应的测试吗？**

思前想后，确实找不到说不的理由。做一个不用关注界面，只在后台发网络请求的App就可以了 。

**5、在移动端做后台接口监控开发量大吗？**

哈雷本身就提供了对应的SDK，不用重新开发。而且开发一般采用了MVP架构，既然不要界面，只需要把开发的Model数据层和Presenter层源代码Copy过来就可以直接用了。

**6、在移动端做后台接口监控，结果怎么看呢，总不能拿着手机看吧？**

目前手机和PC传递数据的方法很多，而且很成熟，可以将移动端的测试结果传送到PC上或者其他平台上查看。

**7、在移动设备上运行后台接口监控的定期任务，设备稳定性如何呢？**

这个只能说还没人这样做过，不是很清楚。理论上问题不大，即使物理设备有问题，也可以尝试用虚拟机代替。

**8、在移动端做后台接口监控发现问题容易定位吗？**

这个理论上比PC模拟端更好定位，因为主要代码都是Copy开发同学的，出了问题，那真的是项目代码出的问题。

**9、在移动端做后台接口监控，后续功能升级维护麻烦吗？**

因为是Copy的开发的代码，功能升级后，再Copy一遍开发的代码就OK了。理论上难度很小。

经过脑暴后，做一个移动端的APP来实现后台接口监控有很多的挑战，但也存在很多优势，可以试着搞一下。

# 最终选择的方案 #

Copy开发的代码做一个在Android移动端运行的后台接口监控App，具体实现流程如下：

![JtoF0ef.png][]

## Android设备层 ##

**如何选取要Copy的代码**

基本上Android开发用的都是MVP架构，MVP架构也是谷歌官方推荐的。

![E4ROHaR.png][]

Model:：即数据层。它区别于MVC架构中的Model，在这里不仅仅只是数据模型。在MVP架构中Model它负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等。这一层的代码全部Copy。

View: 即视图层。在View层中只负责对数据的展示，提供友好的界面与用户进行交互。这一层的代码都用不到，不用Copy。

Presenter：是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。这一层的代码选择性地Copy。

要做的后台接口监控不涉及视图层，只涉及网络请求。所以最终选择Copy的代码：全部的Model层+部分Presenter层。

MVP只是一个整体的思想，具体的对应到的代码，还需要进一步划分：

![8qqNvZG.png][]

所以最终Copy的就是NetService模块的所有代码、Manager和Enging模块的部分代码。

## App的具体实现 ##

**1、Jce模块**：jce是腾讯内部通用协议，用来规定客户端和服务端RPC调用时具体的字段，该模块包含了对应的jce文件解析出来的java类、公用的组包方法、解包方法（具体可以参考腾讯相应的开源项目）。

例如发送消息的类的定义如下：

![7ell6uk.png][]

**2、Copy代码的组合**：哈雷SDK的初始化、组包、发包功能、验包功能。

初始化：静态初始化一次（Copy自NetService模块）。

![Ao0RiDF.png][]

组包发包：（通用的发送方法Copy自NetService模块，具体发送内容Copy自Engine模块）。

![8YLthfW.png][]

返回内容校验：（Copy自Manager模块）。

涉及到具体的字段含义、判断条件，较敏感，就不写示例代码。

**3、实现和adb的通信**：

Activity对外暴露（常规的APP，切勿随意暴露Activity，会有安全风险）：

![hQ4bROX.png][]

Activity接收adb的启动指令，满足条件，则启动线程，开始发送请求：

![tYEtZY7.png][]

对应的adb命令：使用adb发送intent信息，并填写相应的字段  
adb shell am start -n com.example.sheldonfan.helei\_test/.Main3Activity –es msg “start”

**4、结果输出日志**：

![LdzGQMY.png][]

## PC层 ##

比较简单，大约几十行左右的python实现：

1、任务触发：发送adb命令，触发对应的接口监控。

![rXIgK52.png][]

2、用adb命令捕获日志：  
![2vt93s5.png][]

**主要关注点：**

这里不要用多线程实现，要用多进程实现。日志捕获是一个阻塞式的，不停止的话会一直进行下去，所以一定需要一个终止的方法，而Python的多线程没有终止命令，只能用多进程了。

返回值中的Poplog、f，代表着打开的进程和文件，分别用来终止进程和关闭文件，调用terminate()以及close()方法即可。

3、日志分析：

（1）监控日志看是否完成测试：App执行完任务后，会输出“test\_is\_end”log。  
![7oekyg9.png][]

（2）校验结果：主要是分析log，做字段校验，较敏感不做具体字段的介绍。

4、报告以及告警

将步骤3校验结果的做成报告，如果有校验失败的情况，根据情况发送告警。

5、定期触发

目前的监控任务比较简单，暂时先采用了：while True +time.slepp。

![JwAsIsw.png][]

因为都是脚本实现的，后续可以根据需要无缝迁移到jenkins等CI平台。

# 任务执行效果 #

1、执行效率：每一个测试Case（一个Case都只发送一条请求），只涉及到网络请求发送 + 打log + 抓log + log分析，没有任何UI界面的操作，执行耗时都在秒级，满足了后台接口监控的准实时性要求。

2、稳定性：必须有一个手机节点来执行。

最初使用实体手机，出现USB连接不稳定、电池出问题等情况，一天内需要维护多次。所以切换到了虚拟机来运行。

经过实测，Android官方的7.0版本模拟器了，选择X86的，性能好，稳定也满足要求，可以做到一星期内稳定运行（宿主PC选取的是酷睿i5+8GB内存+开启VT），详细配置如下：

![FSiMkSt.png][]

目前的方案满足了需求，可以说这次新方案的尝试成功了！

# 后记 #

后续遇到类似的需要选择方案解决一个问题时，我们应该如何去分析选择，尤其是面临各种选择都存在风险的情况下，应该怎么做呢？

总结了一个简单的分析流程：

![yBp0iEr.png][]

**核心的关注点：**

1、首先要明确我们做一件事的目的是什么。

对于测试而言最终目的一定是落地到产品的质量保证维度上；而实现自动化、后台接口测试只是一个手段，这些手段对应的产品的质量维度才是目的，不能把手段当成最终的目的。

2、可行、不可行的方案都要列举。

不可行的方案未必真的是不可行，可行的方案也未必真的可行。

3、列举可行或者不可行原因，确认这些原因是否真的成立。

这个要结合最终目的来分析。有时候分析到最后，我们会发现可能有以下几种的情况。

（1）倒推因果：根本就找不到可行或者不可行的原因，可行只是因为有人这样做了，所以认为是可行的，成为了传统；不可行只是没人这样做过，所以不可行。此时要仔细和最终目的进行对比，仔细分析可行性

（2）技术革新以及时代变革，不可行的方案可能变成了可行的，可行的方案又变成不可行的了。

4、遇到问题多思考，必要时拉上一群人一起脑暴。

思考的过程一定要记录下来，方便后续回溯，否则会陷入胡思乱想的怪圈（记录方法不限）。

# 后后记 #

这次后台接口监控实现，主要的工作量全在了客户端源代码的学习以及理解以及自己写代码。类似于Copy了客户端的网络数据模块的源代码，针对这一个模块做了接口测试。Copy的代码也随着开发的代码进行更新，也和开发的代码一样，有了版本的概念。

后续和开发同学沟通，也可以这样说了：“开发大哥，没听懂吗？那我们直接看代码吧。”

**这一次的方案意外地有如下几个好处：**

（1）整体的效率提高了：Copy开发的代码比直接自己写代码，效率提升很多，而且质量也不差；

（2）对开发的整体代码架构有了深入的了解：为后续bug的定位以及测试方案的制定等，提供了重要的依据；

（3）顺便测试了客户端代码逻辑：本方案主要是为了做后台接口监控，最终也实现了后台接口监控，同时也对开发的Model层以及Presenter层的代码逻辑进行了校验。

**这个方案实施的前提：**

当然这个方案能够快速实施并有较好的效果，也是有一些前提条件的，大家想用这个方案也要先考虑一下这些前提是否成立。

（1）开发要遵从MVP架构：本次能够快速Copy开发代码完成测试App的开发，主要原因还是开发遵从了MVP架构，真的可以做到Copy过来就可用的地步，自己需要修改的很少。谷歌提出的MVP架构真的真的很强大。

如果开发没有遵从MVP架构，数据存储、视图展示、数据控制混在一起，根本找不到从哪里Copy，此时建议测试同学优先推动开发同学，优化一下开发的代码架构。

（2）测试也要能读得懂代码，会写代码。本方案实施至少需要做到以下三点：

A、获取项目的源代码，并正常编译运行；

B、能进行简单调试追踪，了解项目代码逻辑；

C、掌握Android的基本开发知识，进行简单的开发 。

总之测试了解开发的代码，并将开发的代码为我所有，好处多多。

[JtoF0ef.png]: http://i.imgur.com/JtoF0ef.png
[E4ROHaR.png]: http://i.imgur.com/E4ROHaR.png
[8qqNvZG.png]: http://i.imgur.com/8qqNvZG.png
[7ell6uk.png]: http://i.imgur.com/7ell6uk.png
[Ao0RiDF.png]: http://i.imgur.com/Ao0RiDF.png
[8YLthfW.png]: http://i.imgur.com/8YLthfW.png
[hQ4bROX.png]: http://i.imgur.com/hQ4bROX.png
[tYEtZY7.png]: http://i.imgur.com/tYEtZY7.png
[LdzGQMY.png]: http://i.imgur.com/LdzGQMY.png
[rXIgK52.png]: http://i.imgur.com/rXIgK52.png
[2vt93s5.png]: http://i.imgur.com/2vt93s5.png
[7oekyg9.png]: http://i.imgur.com/7oekyg9.png
[JwAsIsw.png]: http://i.imgur.com/JwAsIsw.png
[FSiMkSt.png]: http://i.imgur.com/FSiMkSt.png
[yBp0iEr.png]: http://i.imgur.com/yBp0iEr.png