让我们思考几个常见的问题：
软件测试的目的是什么？
开发人员能否构建出没有Bug的完美软件？
测人人员和开发人员是什么关系？
软件测试能否保证软件质量？
先闭目冥想五分钟吧，然后可以尝试着回答上面的问题。
计算机先驱 Maurice Wikes 回忆起 1949 年他在英国剑桥工作的情形，在拖着打孔纸带上楼给雏形计算机 EDASC 装载程序时，他看到了自己的未来：
我强烈的意识到，生命中剩下的好日子，都将耗费在给自己的程序找错误上头。
Maurice Wikes告诉我们，没有完美的软件。
我在我的微信订阅号“程序视界”里发布过一篇荐书文，推荐了温伯格技术思想三部曲中的《颠覆完美软件：:软件测试必须知道的几件事》。在这本书里，温伯格也告诉我们，没有完美的软件。所有的开发和测试人员都应该读读那本书。
温伯格在《颠覆完美软件》中几乎讨论所有常见的与软件测试相关的概念、问题和指导思想，所以，在这篇文章里，我只能来吐槽啦，我将从以下几方面列一些常见的现象，希望能引起大家的思考。
测试和开发的关系
流程与标准
资源
态度
测试和开发的关系
测试和开发是对立的吗？
从处理Bug的角度看，似乎可以这么说。开发人员既生产代码，也生产Bug。因为开发人员不可避免地会生产Bug，所以测试人员必须存在，以便在软件交付之前尽可能多地检出Bug，保证交付给客户的软件质量更好一些。一个产Bug，一个挑Bug，看起来似乎是对立的。
在现实中，很多测试团队和开发团队也正是因为这一点而搞得关系不和，甚至真的对立起来。请回想一下你周围发生的与开发和测试相关的事儿，看看有没有遇到过下面的情景：
开发说，测试净找麻烦，客户跟本不可能像他们那样使用软件
测试说，问题总是会在看似极端的条件下产生，用户总是会不经意触碰到看似极端的不可能出现的条件
开发说，测试花在异常情况下的精力比测试主流程还多，不知道轻重缓急
测试说，开发从来不考虑测试的感受，连测都不测就扔给我们
开发说，我都测了，还要测试人员干什么
测试说，这么明显的问题你们都不测一下，把我们测试当垃圾桶啊
……
许许多多类似的问题，让开发和测试的关系从扑朔迷离、相爱相杀走向对立。我见过开发和测试搞冷战某人遇见某人侧脸而过，也见过测试经理和开发经理打架，还见过高层领导故意让测试团队和开发团队关系紧张以为这样可以提高测试效率也能给开发压力最终会产出更高质量的软件……
实际上，测试和开发拥有同一个目的：让软件更完美。测试和开发的关系，是一个问题的两面，应该是相辅相成和平共处的。测试不是为了挑刺儿，他提出的问题也不针对生产软件的开发人员，而仅仅是在努力想让开发人员的产出物看起来更好用。只要开发不将测试提Bug这个行为看成针对个人的行为，一切就有了美好的前提。
否定软件，并不是否定开发软件的人。这是开发和测试都需要明确的一个原则和前提。
还有的人认为开发和测试之关系类似皮与毛，皮之不存毛将焉附？所以有的开发也会因此而有优越感：没我们写软件，你们测试早下岗了！可是，开发不写软件，开发也下岗了耶！
感谢开发的不完美，让测试可以有事可做并练就慧眼。
感谢测试的认真细致和耐心体贴，让开发可以发现自己的不完美并有机会提升自己——那些说我软件不好的，都是为了我好。
资源
别动我们测试的服务器，你们自己搭一个！
我们没环境，不用你们的用谁的？
谁把我们的测试手机拿走了？你们申请一个嘛，老来占我们设备。
谁在用我们的账号？招呼都不打！我要用，赶紧退出来！
有时开发和测试之间也会有资源上的冲突，要有努力的有创造性的解决（我可以负责任地说，装黑苹果不是好办法），不要让大家伙的工作卡在环境上，这是管理者要解决的基本问题。我见过很多非常棒的一线经理，在现实制约下，主动把自己的手机、iPad都贡献出来当做测试设备。这也是解决资源问题的一种办法哦。
流程与标准
你身边的人员会这么抱怨吗：
开发根本不看我们的测试用例，评审邮件从来就不回复
我们一报Bug，开发就说用户根本不可能这么用，还说不知道我们怎么会这么测
送测单里根本不写测试范围或者寥寥几句跟没写一样
开发调整设计从来也不告诉我们
为什么产品经理和UI只和开发讨论需求变更？
为什么发布计划里不给测试预留测试时间？
为什么开发写完代码测都不测就扔给我们？
为什么客户那里发现了问题老问是谁测的、为什么没测出来？
测试老是一声不吭就把Bug优先级设置为Major
测试总是把大量时间花在用户根本不可能用到的功能上
测试分不清哪些什么是重点，你给他说他还老是一堆道理这了那了
测试提的Bug，现象描述也不准确，重现步骤也没有，有的根本就知道是不是误操作
测试老来打断我，一会儿叫一下一会儿叫一下，根本没办法专注开发
jira上的Bug重复率太高，一个问题提N遍，难道就不能合并一下？
测试发现Bug，一声招呼都不打就直接告诉老板了，搞得我很被动
测试就是专门挑刺儿的，有劲不往正地儿使，你倒是测测用户常用的功能啊
那么简单的Bug都能流出到用户那里，真不知道测试怎么测的
开发老嫌测试报告数据不漂亮，逼着我们调整
Ok，如果你身边的开发和测试从来没有过类似的问题，那很好，恭喜你，看来你们的团队人nice协作也很顺畅，棒棒哒。
假如你身边充斥着这样嘈杂的抱怨，那说明什么呢？开发、测试、发布这一套流程有问题？还是团队缺乏明确的指向来引导大家向积极、有效的行为靠近？
流程和标准总是有待解释的，再好的规则，歪嘴和尚也能把它念斜……
我们随便挑一个问题吧：为什么开发写完代码测都不测就扔给我们？这个问题普遍存在，它反映出的是程序员和测试人员的工作边界难以界定的矛盾。
程序员会说，我都测一遍，还要你们测试做什么？
测试会说，你测都不测，冒烟都过不了，有没有责任心？
程序员说，要我写测试用例，搭各种环境，遍历各种正常、异常逻辑，我还有没有时间写代码了？
测试会说，我们测试是垃圾桶吗，什么烂玩意儿都直接扔给我们，我们的时间就那么不值钱？
开发会说，测试本来就是干这个的，你不测谁测？
……
像这样的问题，能制定一个标准，说明什么样的逻辑开发要自测覆盖什么样的逻辑可以交给测试来测？能画一条三八线吗？
不能。所以，这个时候，靠谱的一线管理者就显得很重要。如何创造性的发现适合团队的方法来让大家顺畅地协同工作，比标准、制度更重要，这往往依赖于技术管理者的能力和团队成员的意识。没有普适的方法，只有适合这个组织的、此时此地的策略，加油吧，在战斗中摸索出最适合当下的道路。
那什么是靠谱的一线管理者呢？
温伯格《成为技术领导者》一书中对领导职责的定义如下：
领导的职责就是创造这样一个环境，每个人都能在其中发挥出更多的能力。
如果一个技术领导带领的团队，大部分人都能专心做与其能力适配的事情而不用整天泡在与本节前面所列类似的问题里，那他基本上就算是比较靠谱了。
至于像给测试预留多长的测试周期、调整设计要不要通知测试、需求调整要不要测试参与等问题，合理的流程和标准可以起到很大的辅助作用，技术领导者只要依据合理的制度，引导大家有效参与，就可以化解。
态度
场景一：
测试MM对阿猿说发现了一个Bug。 阿猿矢口否认：不可能，绝对不可能！ MM：真的有Bug，你过来看一下！ 阿猿：我都不用看，在我这儿好好儿的。 MM：你来看一下嘛…… 阿猿：看什么看，肯定你环境问题，动什么东西了吗？重启了吗？
场景二：
测试MM想在jira上提个Bug，先在QQ上对阿猿说：有个Bug，你过来看下？ 阿猿：忙着呢，焦头烂额的。 MM：一分钟都用不了，你来看下吧。 阿猿：思路一打断就不好恢复了，等会儿！ MM：你不看我提到jira上了啊。 阿猿：随便，你不就是爱提Bug嘛。
场景三：
测试MM呼叫阿猿：阿猿阿猿，程序又崩溃了，快来看看！ 阿猿慢腾腾地起身过来，鼠标点几下：看不出来什么问题，你怎么操作的？ MM：这样点一下，那样，这样，……回车……。 阿猿：重现不了啊，你想办法重现，重现了再叫我，我忙着呢。 MM：……
我曾经画过一张暴漫，以“她发现了一个Bug”为题发布在微信订阅号“程序视界”里，再现类似的场景，感兴趣的可以在订阅号内回复10019查看。
开发和测试的日常工作中，上面的情景不断上演，这其中有一部分原因来自态度。我们有时还能听到类似下面的话：
你Bug里的现象描述根本没用
你根本就没理解这个逻辑，给你说不清楚
测试什么都不懂……
你听我的，我让你怎么测你就怎么测
你这种测法儿，再好的软件都经不起你折腾
用户根本不可能这样用，你们整来整去净瞎耽误工夫
一轮都没测完，你们就给老板说可以按期交付没问题？
你们安排计划时根本不考虑测试，三天，三天怎么可能测得完！
……
有时，有一些开发人员会用技术优势藐视测试，认为测试工作技术含量低，内心认为测试是附属没地位，说话就不太客气……测试会感觉到，反过来也会对开发有意见……就这么，从相敬如宾开始走向嫌怨丛生……
有个朋友的QQ签名档是：没有自我，只有大道。我琢磨，放在软件项目里，也挺适用的。
其实，开发和测试拥有共同的目的：生产高质量软件。具体说，每一个产品、项目、版本都有明确的目标，这些目标是属于开发和测试的，是大家的。我们把共同的目标牢记在心，摆在首位，我们还要想着别人所做的一切，都是针对软件本身，都是在为目标而努力，这样就心平气和多了，就容易从当下的泥沼中超脱出来，求同存异共同前进。
随时随地看视频
