测试人员的囚徒困境要说测试人员职业生涯当中最在意也是最

.bizsvr_0 {line-height: 1.75em;} .bizsvr_2 {color: rgb(0, 128, 255);} .bizsvr_7 {text-align: center;}

　　要说测试人员职业生涯当中最在意也是最绕不开的一个终极话题就是如何和开发人员相处。

相信很多测试人员在面试的时候也遇到过这个问题：

　　你是如何和开发人员相（si）处（bi）的呢？

　　要说起测试人员和开发人员的博弈，就不得不提到一个著名的思维测试－囚徒困境。

　　在这场著名的思维试验中，两个罪犯即两个同案犯被逮捕了，他们被分别关到两个牢房里接受审讯。他们都被告知："如果你保持沉默，你会被判处一年徒刑；如果你出卖同伴，你会获得自由；但如果你的同伴出卖了你，你就会蹲两年大狱。"出于竞争性的私利"两个囚徒实际上都有动力去出卖对方。然而，就如同下图所显示的，如果两个囚徒互相出卖，则他们获得的结果是一起蹲两年大狱，如果把这两个囚徒视为一个整体，则这个结局对整体来说是最糟糕的；但如果他们是一条心，则他们获得的结局是都坐一年牢，如果把这两个囚徒视为一个整体，则这个结局对整体来说是最好的。"

　　看完上面的试验过程，有没有觉得测试人员和开发人员的相爱相杀关系很像上图中的囚徒困境。

　　为了早日交付可用的功能，测试和开发团队是需要携手共进的。但是在很多的组织里面，特别是在泰勒主义深入骨髓的瀑布式开发模式中，测试人员仅仅是在接收了开发人员提交的代码后不断的输出他们的检查结果。注意，在这里，我使用的是 **检查**而不是测试，因为CC先生认为这个时候的测试人员所做的事情就是把预测结果和实际开发出来的功能做着一一对比的工作而不是去做的真正的测试行为。

　　所以，此时的测试人员仅仅把开发人员简单地看作测试人员能够要到一些什么东西，并且要输出一些什么东西的对象。随着敏捷测试的推进，此现象在逐步改善和演化，开始将开发和测试之间的关系看作一张网络内各个部分之间的关系，而不是一台机器中的一个零件，你输入初始条件，它就要反馈出结果。

　　要打破测试和开发之间的囚徒困境，我们需要也希望能够培育出来这样的关系，当发生紧急需求时，一方能够对另一方说："这次相信我。"然后就把功能给交付了。

　　当然，这里面也许需要动用到一些必要的科技手段来帮助，比如代码评审，单元测试，自动化测试等等，最重要的是，测试人员和开发人员不能再是互相割裂的两个组织或者部门，什么样的行为能够让整体获利，这才是我们在市场需求不确定的情况下能快速做出反应的关键所在。