软件项目交付后，bug太多？测试：这锅我不背！

--“ 兄弟，又开始写bug啦？”

--“ 兄弟，感谢你养活了我们整个组。”

最近在搜索测试工程师的时候，翠花在知乎上看到这么一个段子：

一万个测试工程师在酒吧门外呼啸而过

一个测试工程师走进一家酒吧，什么也没要

一个测试工程师走进一家酒吧，要了一杯啤酒

一个测试工程师走进一家酒吧，要了一杯咖啡

一个测试工程师走进一家酒吧，要了0.7杯啤酒

一个测试工程师走进一家酒吧，要了NaN杯Null

一个测试工程师走进一家酒吧，要了2^32杯啤酒

一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷

一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@

一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱

1T测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶

一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来

一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿

测试工程师们满意地离开了酒吧。

然后一名顾客点了一份炒饭，酒吧炸了。。。

如果把酒吧理解成一个数据库……

上面那个段子就是说在测试的时候请求各种合法的不合法的数据都正常运行了，然后投入使用分分钟被没考虑到的请求搞崩了

软件测试工程师真这么苦逼吗？

若是如此，那在外包或众包软件下的测试工程师岂不是更惨？

翠花为了弄清楚这个问题，果断找了客栈平台上的优质测试forkey问了问～

forkey来自福建漳州，已经30的他，和大多数人一样正值芳华，与妻子恩爱，事业顺利。从事软件测试5年多。

找到他后，翠花就想到自己不懂测试呀！摔！！不管了，既然足够优秀，那就直接请教吧～就这样，开启了小白翠花对测试工程师无下限询问的旅程：

原来测试是分好多种的，在forkey的描述中，测试有功能测试、自动化测试、安全测试、性能测试等。

其中常用的测试就会包括测试用例的编写，然后找bug ，提交bug ，回归bug后产品上线啥的。也就是他们常说的手动测试吧～

远程兼职做项目，一把做好的产品提交给客户，就会出现类似于开头那个段子出现的酒吧爆炸的情况，这是为什么呢？

辛辛苦苦做了这么多，最后出现问题都是测试的锅吗？

forkey告诉翠花，这种情况会是由于很多原因的。

比如产品原型不清楚，有歧义。导致产品经理跟客户之间是有歧义的，导致后期交付到项目方手里，被当作了bug。

还比如是在项目开发方面，开发人员开发完后并没有先自测，测试在测试回归阶段会因为一些隐秘的东西，测不全。

或者是后期更改需求了，开发者加进去了，但是测试并不知道，远程可能这点不太好，有变化，应该及时反馈，做到团队悉知。

那如何才能有效的避免？

在远程兼职做项目中，测试在客户验收的出现“很多客户反馈，测试都是他们自己测的，测试人员很多只走一下流程，没有按照交付去测试”的这种吃力不讨好的现象呢？

forkey说，在产品原型之后应该马上让测试人员介入，和产品经理一起再次梳理原型，这样对于一些漏洞，能够提早的说出来，进行改进，加固需求完善性，减少后面开发按照错误的原型进行开发。

当然在他看来编写测试用例是非常必要的。这是基于和产品经理一起梳理需求之后的一个自然而然的步骤。当然评审也很重要“测试用例评审的话，bug肯定会好的。”对于一些潦草，功能点没展开的测试用例，评审的话项目经理会帮助改进一下。

做测试呢，一般都是比较较真的。

比如你检查出这个是bug，让开发去更改，但是这时候可能需求是正确的，但是开发与测试理解的是两种含义。当然这时候也可能包括客户的描述不清楚，那么这时候就不是bug而是模凌两可了。

解决办法不是没有，对于容易产生歧义的地方，产品经理应该会给出注释。除非本身他们自己也没想到，这个都是没办法的，身而为人，翠花觉得bug这事确实缘由太多了，若是单纯在交付后出现bug去形成一种测试并没有做好的工作的看法，就是一种偏见了

因为在翠花的公司：

如果有一天，我老无所依

请把我留在bug堆里吧！！！

—— 董开发