一个致命的bug--自负

王豆豆现在怀着无比复杂的心情写下此文，谨以此文献给广大越挫越勇的软件测试人员们。

此刻为什么王豆豆的心情无比复杂呢？

原因有三：

1.在临近年关的时候，好多小伙伴都放假了，王豆豆却还在加班上项目

2.上项目也就罢了，竟然还被开发在眼皮底下写了一个bug上去

3.写了一个bug也就罢了，竟然没有被发现消灭在摇篮中，竟然在线上去招摇了一圈。

简单总结起来就是一句话：项目上线后发现了一个bug

为什么项目上线了才发现bug呢？说到原因王豆豆要先去哭哭再回来。

哭完回来了分割线

说起原因先追溯下项目本身需求：

本次项目的需求很简单，就是A公司向我们借款，借钱肯定是大事情嘛，不都得打个欠条什么的（借款合同），然后我们向B公司请求在签约平台上签了好欠条（借款合同），签好之后推给我们，欠条嘛不都得双方都保存的么？所以我们也存表并将欠条（借款合同）回调给A公司。

是不是一个很简单的逻辑，很清楚明了的一个需求？

就是这样一个简单的需求，大名鼎鼎的王豆豆竟然栽上面了，与其说是被栽上面上，不如说是被开发给谋害了（此处伤心过头，开始推卸责任了），伤心啊，枉我一世英名啊。。。

BIG BUG诞生的原因：

这个项目从上周四提测之后，苍天不负有心人王豆豆花了一天多时间将分析出来的所有测试范围测试完毕，然后就开始与B公司联测（A公司还在开发），与B公司联测完毕后，就等A公司了，这里差点连黄花菜都等出来了。

好不容易星期一开始与A公司联测，不管与谁联测，联测从来没有顺利过，至到昨天终于与A公司联测完毕，所有测试流程都通过，我们发给他的欠条也能正常收到。

话说今天就准备开始上线了，原本计划上午上线，但是开发说优化了一下代码，要先回归一下，回归就回归嘛，好简单的事情嘛。

今天下午开始回归，测试过程很顺利，唯独就是给A公司调回调接口发欠条的时，总是返回“连接超时”，最后确定是对方环境的问题，也就没管了，然后就开始上线了。

我滴个神，BUG诞生分割线

项目上线后，前面流程很顺利，但后来一个华丽丽的BUG就这样诞生了。

我们调A公司生产合同接口时发欠条（测试环境和生产环境不同，回调接口也不一致），给我们返回“保存信息失败”，这是什么情况？

当时王豆豆想的是这一定不是我们的问题，一定是对方存数据出错了，因为在测试时对方就报了这样一个bug。

现实和想象总是那么滴不同，不仅不同，而且还这么反转，难道你以为这是在拍电影么？话说电影就是来源于生活，也不是没有道理。

最终检查数据发现，结论：就是我们的BUG，给对方的request_data未按要求写，少了一部分内容。

戏剧啊，太戏剧了，当时王豆豆真不敢相信她的眼睛，不是已经联测过了，为什么联测的时候通过了？

继续查询分割线

最后发现，就是从今天下午四点后向对方请求的报文都少了内容，请求体与前面的不同，原来是开发人员优化代码是将报文对象引用成别的对象导致的。

事情的经过就是这样，开发在我眼皮底下写了一个bug，而我竟然没有发现，而且还让其上线了，真是好伤心，简直是给我幼小的心灵重重一击。

总结：

按理这么明显的一个bug，为什么会没有发现呢？

主要原因是以下几点：

1.对方测试环境不通，一直返回连接超时，而将保存信息失败的bug隐藏起来了，导致我这边无法获取到最真实的结果-----直接原因

2.明知对方环境不通，我也只是在微信群上发了几次，在对方并没有完全解决好问题的情况下，就不在追踪了-----间接原因

3.为什么不追踪？如果是我们一直联调测试也没有成功，我肯定会一直跟踪下去，但是我没有，最直接的原因是因为自己的自负，相信昨天的结果-----深层次原因

细分析下来出现这样的bug，也是必然的，因为我犯了软件测试人员最忌讳的一点：过于自信，未精益求精，所以出现bug，责任全在于我，并不在开发。

因为我一般都不相信开发人员，开发人员说没改，那一定是改了，只不过改的范围小了一点，可能就是一个变量名，也可能就是代码换了一下位置，就像今天开发人员就是说自己没改，而我最相信的是自己，相信自己的测试结果，那个requst_data在前面测试时特意检查过，反而今天就不怎么在意了。

4.还犯了一个错误，以前在调对方接口返回错误信息时，我都会将请求体和返回信息一并发给对方，但今天只将返回信息发出来了，可能我认为就是对方环境的问题，与我们请求报文无关，如果一并发出来，也许群里的某个小伙伴就能发现。

软件测试这个工作来不得半点假，一定要用实事求是和精益求精的态度对待每一次测试，对于测试结果不要相信开发，不要相信自己，哪怕有一丁点儿不对，也要拿出死磕的决心来，对战到底，只有这样才不会放过每一个潜在的bug。

最后愿每出现的一个bug都会成为我们勋功章上的一抹亮丽的色彩。