测试与研发总是在互相吐槽的同时又保持着亲密的合作。
导读：
很多行业，譬如软件研发、机械制造、餐饮等等，都是有自己行业相关的测试标准以及配套的研发、测试部门的。研发负责一个产品从无到有的设计生产，测试则把控着产品质量的生命线。而对于程序员来说，测试与研发之间经常会有互黑吐槽与亲密合作，一个合格的产品总是在这个过程中诞生的。
测试的职责
对于测试人员来说，他们的目的就是为了让产品的bug在生产者层面就能够暴露无遗，最好是全部一把揪出来，然后返还给研发进行bug修复。一款产品要尽可能少的让bug流向下游的客户手中，因为少一个bug，就多一分竞争力，就多一分赚钱的能力。
其次，测试并不仅仅是测试bug，有时候还会提出产品使用方面的优化建议，比如这样操作太繁琐了，能不能进行改善。或者这样的界面太丑了，能不能美化点，这样那样的（当然这些可能更多取决于产品经理与客户，但是测试也是会有这样的建议的）。
为什么要有专门的测试
为什么要专门的测试人员，而不是让研发自己兼任测试，毕竟研发自己搞出来的东西，自己就是很了解的，测试岂不是有更大的优势，我觉得有以下几个方面可以解释：
- 大部分情况下，我们对与自己做的东西总是有一种倾向性，会觉得自己做的东西很不错，bug不多，而在自行测试（我说的不是代码层面的测试，而是用户交互层面的）的时候会有意无意的规避可能产生bug的操作。比如一个产品，它有这么一个bug：先点击模式1，然后切换模式2，在模式2中选择功能项1，然后返回模式1，此时在模式1与2之间再次进行极为频繁、快速的切换的时候就会导致死机。如果是自己测试的话就可能会潜意识下减缓模式切换的速度与频次，这样一来这个bug就被隐藏了，其它也是类似的。
- 测试与研发不是完全的一个领域，计算机三级考试还有专门的软件测试科目呢。测试经过多年的发展，逐渐的跟研发形成相互交错，但又不是完全重合的专业领域。研发整体上来讲是没有测试更加专业的（对测试这个行业来讲）。但是研发也会在“模块自测”等测试步骤中发挥做作用。
- 时间、精力限制。如果研发人员既做测试又做研发的话，那么整个产品周期会变得很长，更不用说上面两条会极大地影响产品质量。
测试的定位
我们说的测试并不是类似网络上面那种测评啊啥的那种测试。测试是极富专业性与必要性的行业，有句话不是说嘛：“对测试的重视与投入程度一定程度上决定了整个公司产品的好坏”。
像软件研发来说，测试的工作会包括测试架构搭建、测试用例编写、测试过程把控等。测试流程包括模块自测、集成测试、性能测试、功能测试、系统测试等等。测试方法有经典的白盒测试、黑盒测试等。
总之，测试是产品生产环节中不可缺少的一部分，测试的投入决定了流入下游客户手中的产品bug数量，测试决定了整个产品的质量好坏。
为什么bug总是修不完
我经常会有一种感叹：为什么bug总是修不完。而事实也是如此，我就从来没有见过毫无bug的软件产品，无论它是由谁开发的，无论那个开发的人有多么牛逼。工作当中也是经常处于这个bug修完了，终于可以修下一个bug的状态。
开发者无法控制用户的使用行为，这就会导致很多的bug产生，想起一个段子，引用如下：
一个测试工程师走进一家酒吧，要了一杯啤酒
一个测试工程师走进一家酒吧，要了一杯咖啡
一个测试工程师走进一家酒吧，要了0.7杯啤酒
一个测试工程师走进一家酒吧，要了-1杯啤酒
一个测试工程师走进一家酒吧，要了2^32杯啤酒
一个测试工程师走进一家酒吧，要了一杯洗脚水
一个测试工程师走进一家酒吧，要了一杯蜥蜴
一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@
一个测试工程师走进一家酒吧，什么也没要
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷
一个测试工程师走进一家酒吧，要了NaN杯Null
1T测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶
1T测试工程师把酒吧拆了
一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱
一万个测试工程师在酒吧门外呼啸而过来源见知乎：计算机领域有哪些经典的典故或笑话？ - 胡飒的回答
上面的测试工程师可以自行替换为用户，因为上面的测试本身就是为了模拟用户产生的操作引入的bug，以及试图规避用户可能会产生的操作引入的bug。
有些bug由于年代久远，不得不保留，比如古时候微软的一个excel的bug（关于日期设置的），有兴趣可以搜下，这里就不再说了。这些被保留的bug往往是由于某个产品发布之后已经被广泛应用了，修改bug会异常困难，此时就只能暂时选择保留，想办法在用户层面去规避这个bug。
bug可以减少，可以暂时隐藏不被用户看到与触发，但是永远存在，并有着出现的可能与风险。
互黑
（以下皆为瞎扯淡）话说我们公司经常会有这样的吐槽：
- 为什么我这里怎么玩都玩不出这个bug，一到测试手里就出事（手动笑哭，这个时候就不得不佩服测试强大的揪bug能力了）。
- 还可以这样玩儿？还有这种操作方式？这不死才有问题了，但是该修还是得滚回去修，该规避还是要规避。
- 我怎么没看出来这是个bug，这不是挺正常的吗？你说的那个现象在哪呢？（这时测试的小伙伴会指着某个地方：你看，就是这里！）话说这个是我同事遇到的，自己很难看到bug在哪里，不过最后总能证明，测试是对的（再次跪拜）。
（以下纯脑补）不知道测试的小伙伴会怎么吐槽研发的，是不是会有类似下面的吐槽呢：
- 这功能做的跟坨屎一样，这么难用，这怎么测试，太难玩儿了吧！
- 怎么又发版本了，不是刚发过一版，刚测试过嘛！
- 什么？昨天发的版本不行，今天打了个补丁，用这个测试！ %csdf，那我这白测了半天，能不能一次搞定！？这么改来改去。
- 怎么净找周六周末发版本测试，双休日还让不让休息了。
- 我说这是个bug，你（研发）说这不是个bug，我说这就是个bug，你说它就不是个bug（自行脑补让子弹飞的情节）。明明需求规格上写着，你这没实现，它怎么就不算是个bug，然后研发会从代码设计、算法设计上解释半天，说这就不是个bug。
- 我测了半天你告诉我不能这么测，但之前就是这么测的啊！你又说针对这个功能，它就不能这么测，心好累。
程序员都喜欢自黑以及互相吐槽，工作嘛，总是要找点乐趣，排解排解心情，bug解不完，还不得吐槽下，放松下心情，当然，最后该解的bug一个都少不了。
协作
互相吐槽是有的，但是合作共同开发产品才是重点，产品在开发阶段的bug是处于发散趋势的，随着新功能的添加，虽然旧的bug同时在修复，但是总体的bug数量是在增加的。此时就需要不断地把功能交付给测试部门，然后测试部门不断地反馈bug回来，研发再去修复bug，直到新功能开发完毕，bug才会呈现收敛趋势，就在这个不断迭代循环的步骤中，一款产品才能逐渐变得合格可用。
只有双方都彼此负起责任，测试认真对待每一个功能点进行详细的测试，研发对于测试反馈的每一个问题点都进行详细分析排查，定性这到底是不是个bug，是的话怎么去复现，对于难以复现的问题往往需要测试与研发通力合作，共同找到问题点。
