该文原创为新潮质量保障技术团队中的 “上进的中年软件测试从业者”，用于技术交流分享

又到了周五的晚上，下班的时候看到了了企业微信推送的一条很尬的消息。

不自觉的第一时间就想到了天下无贼的一句台词 - 你 TM 才没脑子呢，纯属戏言。

又要开启愉快的周末生活了，虽然已经差不多都安排满了事情，但是没有工作日那种压迫感，还是不错的。这也是为什么加班最好在公司的主要原因，身心会不自觉就投入其中。

浑浑噩噩的过了两周，感觉没什么可值得写的，幸好今天解决了一个测试平台架构上面的问题，可以拿出来给大家唠叨唠叨。

## 开篇

昨天有同事发来一个问题，想要在测试平台架构提供的 RF Remote 服务返回的 http 请求以 Response 对象的形式呈现，然后通过预先检查 status_code 来避免因为开发乱写返回而导致漏测 (这逻辑真的很值得学习，自愧不如)。后面想了想，其实从自动化业务用例的场景来说，即使这个地方断言有误而导致本应失败的用例判定承担，后续的业务也同样会失败。举个例子来说：创建用户失败，后端返回 500 的 code 和{"msg": "创建用户成功"}的误导消息，但是后续的查看用户列表业务场景，同样会因为用户创建失败而导致查询失败。

当然，这也比较考验自动化用例设计者的严谨性。对于合理的用户需求，我们通常都是尽可能的去满足，至少我会要求以这种态度来处理测试平台在推广过程中任何反馈。

## 背景

接到这个需求之后，就去同事那里查看具体的情况，然后看到了如下的信息：

初步分析得到的结论是反序列化过程后的问题，熟悉我们平台的同学都知道我们有公共工具服务以 RPC 的形式呈现，传输过程中更多的时候我们会把数据序列化。附上简单的服务调用图，方便后续问题解决过程中理解。

## 调研

然后没有多想就把 reuqests 请求后的 Response 对象没有经过序列化过程直接返回给了 RF Remote Server, 然后 Remote Server 再透传给用户。然后同事那边又反馈了新的问题（这就是过度自信，不自测的下场）：

这个问题在通过 google，尝试各种关键字排列组合，都没有找到合适的。今天早上到了办公室继续调研这个问题（再次强烈建议早上宝贵的时间一定要给最棘手的事情），突然灵光乍现想到了原理就是为什么 Python 的对象无法通过 RF Remote Server 传给用户，然后就在本地打了断点，开始探究根源：

熟悉的身影再次出现，至此问题的根源找到。（具体的原因就不说了，前面已经介绍很多次了）

## 解决过程

找到了问题的根源就很好办了。先尝试用在 RF Remote Server 用直接用 requests 来生成 Response 对象返回

然后发现了一个奇怪的现象：

Response 对象被在调用过程中，返回给客户端的是被解析的 byte 集合。然后在官网上找到了正解：

也就是说 Python 对象在传输过程中会自动转换为 string， 具体到测试平台这边现有的架构，是没有办法来满足同事的需求。

但是，只要思想不滑坡，办法总比困难多。和同事商量后，决定在 RF Remote Server 这边对需要 status_code 的需求，把 status_code 强制加到 response 的 content 里面。当然，这是一种变通的方式，不是最优的解决方案。也请有解决方案的同学不吝赐教。

## 思考

后面的一次尝试，发现了一个惊喜。当调用一次 RF Remote Server 自己通过 requests 生成的 Response，再次调用工具服务拿到 Response 后，通过 RF Remote Server 透传后，居然不会报错！！！大胆猜测一下如果 RPC 客户端引入服务端传送过来的对象对应的包，也就是说如果工具服务返回了 requests 的 Response 对象，并且 RF Remote Server 端引入了 requests 包，远程调用将不是真正意义的远程调用。当然，这本身也不符合 RPC 服务的宗旨。

大胆推测，小心求证。这里就不去求证了，感兴趣的小伙伴可以去试一下。

## 结语

之前一直听开发同学说 websocket， 前段时间有幸接触到了一个新项目有这样的接口形式，有种拨开云天的感觉。后续争取能够引入到测试平台里面，让平台的的服务形式更丰富。感谢大家的耐心阅读，我们两周后见！另外感谢在 tester home 指正 MD5 的那位小伙伴。