IT岗位中最“和谐”的两个工种：开发、测试趣谈

lsekfe

开发和测试是互联网公司最常见的两个工种，他们相互依赖，或者说单方面依赖，但至少不像开发和产品那样关系恶劣，动不动就武力解决(开玩笑)。
　　网上关于开发、产品关系的段子很多，但关于开发和测试的却不多。因为工作关系，对开发、测试都比较熟悉，所以今天我们来聊一聊开发和测试之间的那些事儿。
　　角色定位
　　开发：就像是建筑师一样，按照图纸的要求，打地基盖房子，尽可能100%还原设计师的要求。
　　开发自测的思路也一般以完成功能为主，想的是正常人应该的操作（但用户是正常人吗？)
　　测试：对测试过程充满了期待，他们像一群拆迁队一样，疯狂的在项目上做着破坏，寻找bug。
　　比如，一个住人的房子，测试是这么测的：
　　这房子能住1个人吗?
　　这房子能住0.6个人吗？
　　这房子能住-1个人吗？
　　这房子能住100亿个人吗？
　　这房子能住NULL个人吗？
　　这房子能住1头猪吗？
　　这房子能住一个asdfQwer@24dg!&*(@吗？
　　这房子能住一个烫烫烫的锟斤拷吗？
　　这房子拆了天花板能住人吗？
　　这房子剩一半能住人吗？
　　这房子只剩个天花板能住人吗？
　　把这房子挪到别的地方能住人吗？
　　这房子有一万个人一起涌进来，然后又走了，之后还能住人吗？
　　开发：用户不会像你这么操作的
　　他们以发现bug的数量和质量为荣，他们给开发报bug的时候，多半是很开心的（是不是挺变态的）。
　　但是，bug数太多
　　测试：这个开发，这次又有100多bug，也不害臊
　　开发：呵呵...
　　当找bug变成一种似乎永无止境的任务时，找bug的快感就完全消失了。
　　提测
　　情景
　　开发：排期定好了，到提测时间了，可我代码还没写完呢，怎么办？先把主流程写通吧，小细节，测试同学测的时候我继续开发，提bug就提bug吧。
　　测试：提测了，那应该是都写好了，流程是可以跑通的。
　　提测申请
　　情景
　　开发：哎呀，为什么这个模板里有这么多内容，我要写那么多干嘛，就写个标题吧，嘿嘿
　　测试：你不写全了，我哪知道需要测试啥？你的代码你是最清楚啊
　　相关prd、接口、log文档呢
　　哪个地方应该重点测试
　　哪个地方的逻辑有些复杂
　　是否有权限要求，在哪申请
　　是否修改了prd上没有的功能
　　测试服地址，app哪些模块需要连接测试服
　　bug
　　情景1
　　测试：发现了一个bug，跟开发说：这里运行不了，是不是有bug？
　　开发：呵呵，你的环境没搭好吧？
　　情景2
　　资深测试：发现一个bug，跟开发说：亲，我这里运行不了，能不能帮忙看看是不是我环境没搭好？
　　开发：卧槽，是不是出bug了？
　　测试写的bug描述
　　情景1
　　测试：我费劲巴拉的在jira写了半天
　　开发：我就看个标题
　　情景2
　　开发：复现步骤呢，bug环境呢，链接呢，机型呢？有截图吗？
　　测试：...
　　有经验的测试，不会一发现问题，就给开发提bug。而是进行反复的确认，在测试报告里会写出详细的复现步骤，贴出效果图，确认bug的产品环境(比如，是任何机器都会触发，还是某台特定机器特定浏览器的问题)。
　　再资深一点的测试，会主动追查bug产生的原因，会去代码的相关片段进行debug，给出开发同学合适的建议。
　　debug
　　开发：debug的心态，则是一个变化的过程。
　　不可能，我代码写的那么好，怎么会有bug
　　哎，我电脑上是好好的啊
　　真是奇怪，刚刚还好好的
　　肯定是数据问题
　　清下缓存试试
　　重启电脑试试
　　我去，居然忘加判断了，真傻x
　　不对，不是我的问题，这是之前那个傻x写的
　　哦，这个地方就得是之前的写法，是我傻x了
　　哎呀，找到问题了，跟我没关系，是锅，又背锅了
　　不是自己写的bug
　　情景
　　开发同学：不是我的锅，是第三方包/后端/客户端/之前那个傻x的问题
　　测试同学：我不管，是你的项目的问题，就是你的bug。
　　《程序员修炼之道》说：bug是你的过错还是别人的过错，并不是真的很有关系。它仍然是你要解决的问题。
　　重复提的bug
　　情景
　　开发：两位测试大大，你俩能不能同步一下再报bug，我的bug数破100了
　　测试：...
　　开发：这几个bug都是一个问题引起的，唉，怪我自己。。。
　　debug过程中出现的bug
　　情景
　　开发：哎呀，这个地方的逻辑写的不对，趁测试没发现，偷偷改了。
　　改完之后，一看jira，呵呵，那个bug刚刚提交出来。
　　测试：没有我发现不了的bug??
　　需求变动
　　情景1
　　测试：这个地方怎么跟prd不符？
　　开发：产品需求改了啊，怎么没改prd
　　两人一起怒视pm
　　情景2
　　测试：这个地方怎么跟prd不符？
　　开发：emmmm，我觉着这么做更符合用户使用习惯（其实是实现起来麻烦，换了一种方式）
　　改完bug
　　情景
　　开发：默默改完了
　　测试：改完了吗？在吗？人肉访问中。。。
　　测试：改完了吗？你改一下jira状态啊？
　　测试：改完了？自测了吗？还是有问题啊？
　　开发：WTF...
　　复现步骤太麻烦了，就在脑子里过了一遍逻辑，感觉没问题
　　没切回原来的环境
　　没删断点log
　　测试：改完了，能告知一下错误原因吗？
　　要封包了，还要改需求的pm
　　开发、测试双双拿起来桌子上的板砖
　　上线
　　情景
　　开发：我就改了一点点，不影响其他功能，不用测了，直接上吧
　　测试：上线了？什么时候上的？上的什么功能，我不知道怎么能上线，出问题不要甩锅给我啊！！！
　　不要偷偷上线，有时间尽量安排测试。实在不行，也要跟测试同学同步一下信息。
　　线上故障
　　情景
　　开发：你们测试怎么回事，怎么没测出来？
　　测试：你没跟我说这个需求啊，我哪知道？
　　总结
　　世上没有无bug的代码，开发尽量不写带明显bug的代码；
　　测试要写测试用例，要维护核心case。
　　开发测试是一个团队，大家都是为了一个目标，所以要相亲相爱，要peace！