被一个问题卡了近两天，下班后我哭了。。。

写在前面

好像很久没有更文了，感觉有很多想写的，但却又不知道该写些什么了。。。

近阶段，整个人的状态都好，本计划这月想给自己充电，做一些自己想做的事，结果真的就是事与愿违吧。

好像每个人都一样，都是为了生活而疲于奔命，依然忙碌于各种事情之间。

整个过程

没经过深思熟虑的计划制定

两周前，组内同事想让我帮忙做冒烟测试脚本，原因是因为每次发版测试的时间耗时特别长，所以在结束批量测试工具的开发工作后，我便主动和领导请缨做冒烟测试脚本的开发工作。

和领导说，脚本开发需要5天，整个冒烟测试每次需要大约5分钟！

领导听完很吃惊，我自己说应该差不多吧。

迷之自信？

可能很多同学也会和我的领导一样吃惊，为什么？

系统发版后的回归测试，就测试场景和流程来看，工作量肯定不小，姑且不说技术问题，就业务流程的梳理就很费时间了。

而我却说整个过程只需要五天，可见我是多想证明自己了

其实不然，我自己还是有一些考量的，才说出五天，原因有两个：

• 因为信任，所以备受期待，同事信任我，真的感觉自己被需要，并且想为团队贡献出一份自己的力量；
• 因为之前做过测试环境的性能测试脚本，以为很多接口可以直接拿来就用（我天真了，因为改了不少，需要重做）。

理性永远在给感性收拾烂摊子

整个系统总共6个测试流程，也就是说我每天要完成1.2个流程的脚本开发。

我特别喜欢现在团队的氛围，第一天到下班点时，差一个模块就完成了一个流程。

所以在责任心的驱使下，心想加个班吧，今天能赶出来这个模块，明天其他的流程就能复用了。

一切看似很好，也正是这个模块把我彻底卡住了，我遇到了一个让我很抓狂的问题：

打个类比，比如发起申请接口，申请成功了，到领导审批，点击同意的时候报错，而发起申请这个接口却不报错，你在页面同样的操作，领导同意却是正常好用的。

被问题卡住，心态开始崩盘

这个问题，我反复查了近两天......

这期间我积极的找开发同事帮忙排查问题，并确认是否是我的入参不对导致节点数据不正确。

由于开发同事比较忙，能帮我排查问题的时间有限，所以只有在开发稍微有点时间，才能帮忙排查联调。

也正因为开发同事的尽心尽力帮忙，几次下来，让我感觉离问题根源好像又进了一步。

也知道为什么不能审批了，因为虽然请求成功了，但是没走业务逻辑，导致部分数据还是默认值，所以审批报错。

关于入参的排查，暂时告一段落了，因为数据状态不对，无法进行审批，意味着还是没有解决问题。

到这已经是第三天了，一个流程都没整完，感觉整个人都不好了，心态有点崩了......

于是向领导说明原因，领导了解后，并说先把耗时最长的做完，虽然没那么大压力，但是心里还是有些深深地自责。

我还是没忍住，终于哭了出来......

距离周五晚上发版测试还有两天，这个问题不解决，怎么也说不过去，心里一直憋着这个劲特别难受。

当时的想法，真的是谁能帮帮我，帮帮我行么？

但是我也不知道该找谁帮忙，谁又能帮助我？

为什么？说是业务问题吧？还不算？技术问题吧，入参还查不出来啥问题？真的就是进退两难！

因为开发太忙，实在没时间，暂时也没想到什么好的解决办法，我就先下班回了家。

把车停好后，习惯性地给女友打了电话，那天还是我的生日，再加上那阶段烦心事特别多，说着说着我哭了出来，突然感觉好无助而且很没用，最后彻底哭了出来，为什么就那么难？

我以为我很颓废，今天我才知道，原来我早废了。

因为烦心事特别多，导致整个人都不好了，哭出来后，感觉真的很舒服，而且整个人平和了许多。

没人能教你，只有自己能拯救自己

回到家后，搭建好环境，改用工具进行测试，使用jmeter+fiddler抓包开始，重新调接口来模拟测试，结果居然成功了，真的很意外，难道是我代码写的有问题？

第二天上班，我把自己代码接口调用及入参与昨天做好的jmeter脚本一一对照，发现入参一模一样，这让我产生了怀疑，是我封装的工具类有问题？

我代码走的HTTP协议，而jmeter脚本是HTTPS协议才成功的。

这让我想到，可能我的httpclient需要走HTTPS协议请求会让接口调用后，数据应该会正常显示吧。

有了思路，就开始找httpclient如何进行HTTPS请求的相关文章。

经过一番搜索，找到的重点都是围绕使用ssl和根证书的使用的代码片段，我又对httpclient底层封装进行改造，改造完再次使用封装工具类调用接口，结果还是数据状态不对，我真的彻底绝望了。

于是，我又去找到了强哥（我北京的同事），强哥说你干嘛自己封装，用hutool呀。

我照着强哥的思路，又去照着hutool中的工具类，开始写demo，逐一调用接口，结果竟然成功了，这让我欣喜若狂，真的好用。

于是，我对写好的demo，再次进行封装，也就是hutool中的工具类封装，封装好后，再次使用封装好的工具类调用，结果数据状态又不对了。

我真的服了，这是玩我吗？分开就好使，封装就不行。

有的同学说了，应该是你封装的有问题，那为什么其他模块都好用，就这个模块不行？

后来，我灵机一动，那就都对分开可用这部分代码进行简单封装，保证流程跑通就行，算是退而求其次的解决方法，虽然，它很low，但是能用。

也正因为这个临时解决方案，助力我在周五发版前成功的让同事用上了，一个流程的冒烟测试，跑完这一个流程仅需113秒，比手动回归快了近10倍的时间。

写在最后

整个过程让我记忆深刻，在此特别记录一下，真的是头一次被问题卡的这么难受，那种既生气，又干不掉难题的感觉，太难受了!

你有被难题阻塞，一直无法继续下去的情况吗？欢迎文末给我留言哦！

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!