测试开发工作者日记：2020.6.10-6.11
这俩天还是在忙安卓自动化平台和交接，性能稳定，用例也磨合的差不多了，还增加了预发布单独设备，还有很多方便快捷的小功能。
方方面面吧，都不错，测开要想混的好，良心匠心不能少~(一条能服务的人传人现象)。
而其余时间，都在维护测试工具平台，这种数据构造平台后期维护量一般都非常非常巨大。逻辑复杂，稳定性差，风险高，且认同度低。比如说构造测试用订单，同样的东西，发现了bug，开发一听，你这是脚本造的，都第一时间觉得是脚本问题而抵赖掉。
而且测试人员要开发这种平台的前期是异常艰苦的地狱难度，文档基本借鉴不到，接口文档更是可笑。
所有需求，都是自己去想办法解决，逻辑都是抓包一点点一点摸索，你能指望的人就是领导，给你背后撑腰。
拿这个订单来说，它的计算方式是写在app客户端，然后把最终结果加密后和后台服务器去对比验证。也就是说，我想做一个测试用订单出来(相当于做一个微型测试生成订单专用客户端)，最终的价格，是没办法通过接口/抓包 来查询到的。只能通过自己一点一点猜，一点一点验证，一次一次的试出来客户端的计算方式，什么单价，会员，折扣，发票，入住天数，单价，优惠卷，押金，增费，节假日特殊费用等等一大堆的计算。
有的同学说，那你问开发啊，但是我想说：你实际去问就明白了。你根本找不到对的人，即便找到了人家也没时间给你讲，拖你几天常有的事，有时间也不一定配合你。讲了也可能很粗糙你完全听不懂，可能时间长他自己都忘了。当时的开发者产品 离职了等等等等 一系列因素。让测试平台的开发难度指数形式上升，何况一般手底下技术高的都是腼腆内向的，比如我很难去拉下面子去求爷爷告奶奶的问。何况遇到严谨的同事，还会怀疑你的动机，不给你泄漏这些机密算法和逻辑，当时我不知道我低声下气的叫了多少声：大佬，问个问题。
而这只是 成百的功能中的一个，毫不夸张的说，大部分测开面对这种情况基本就会找借口推脱掉了，不可能去做这种费力还要装孙子的事。而这后续的维护成本，才是真的要命。当你安稳的度过了几个月之后，这块复杂的逻辑早都忘的一干二净，唯一记得的就是当时那恐怖的回忆。而这时候突然需求产品逻辑变更，你的测试平台这个功能也随机失效，只能同步去改。那时候命运会再次给你拉回到那痛苦的经历中，一边无情的鞭挞你，一边还要让你明白，这种折磨是永无止境的无限循环，你永远别想逃离。
还好我眼光足够远并且足够胆子大，所以一开始就想到了这些问题，早早的做好了后续维护的优化。
·比如页面维护脚本的各种请求/sql/shell 设置，让配置变得极度灵活可控可视，而之后不需要去研究代码：
·比如开发各个自己维护常用的小算法工具
·比如各种环境/数据库等配置都放在页面维护
当然也少不了帮助文档，别人看不看无所谓，反正是给健忘的未来自己看的：
在线抓包mock来测试调试出新改动的app数据(接口文档根本指不上，全靠自己抓包)
总之做了很多工作，算是未雨绸缪，磨刀不误砍柴工。先打好了地基，未来你随便建设摩天大楼。
能有这份思想 全靠iso9126国际软件质量体系中的六大特性27子特性，作为一个匠心独运的测开，自己开发的东西必须要跟着iso9126走，最终收益的是自己。(具体该体系可参考我的文章，自己去翻翻，我写的理解比较通俗易懂)
而最后的结果是我维护起来，时间和精力起码减少到一半以下。
但是我还是发现我天真了。因为一个功能虽然如此省时，但是我做了足足七八十个功能。这些功能对应着公司大部分开发的业务，每天都有变更和需要维护的。即使我再怎么优化维护成本，这总消耗成本依然是天文数字，这长线持续的维护依然会扯碎我的时间精力。
当然我现在佛系了很多，本平台专用的智能维护助手机器人(名字没想好)也在研发中了。到时候进一步缩小自己的维护成本，我也会再度省出时间去做别的。