敏捷中的极限编程有个广受争议的实践叫结对编程，相信大家即时没试过也会有所耳闻。的确，结对编程并非适合所有人，但是不可否认的是，结对编程的确对代码质量有着不同一定程度的提高。最近突发奇想，既然有结对编程，那么测试是否也可以结对呢？查了一些资料后发现不少团队都有过不同程度的结对测试的实践，其中很多测试的质量甚至效率都有所提高。
结对编程，顾名思义是两个测试者坐在一起对软件的同一模块进行测试，两个人处于平等地位，并且在测试过程中不断进行讨论和交换思想，以尽可能消除单一测试者的知识缺陷、思维盲点和测试中的错误，提升整个测试活动的质量和效率。
其实结对测试对测试质量的提升应该不用我多说，有了两个人充分交换思想并且相互监督，测试中的思维盲点和所犯的错误都会大幅降低。但是测试效率的提升可能并不那么显而易见，似乎由于结对的关系，测试工作的效率反而会降低，甚至折半。其实这个问题可以参考结对编程，如果单纯从编程这一活动中去看，结对的效率可能不会提升，但是从整个项目流程看，结对编程减少了开发人员研究相关知识和业务的时间，并且由于提升了代码质量而减少了后期返工的时间，整体效率其实是提升的。同理，结对测试对于整个项目来说也是可以提升效率的（根据测试阶段发现的bug不如开发阶段发现的bug易于解决，所以可能整体提升的效率不如结对编程那么明显），而且由于两人共同工作的关系，个人的集中力也会提升，这也会对效率的提升有所帮助。
除此以外，结对测试也会对个人能力产生不错的提升，你可以从结对的人身上学到不同的思考问题的方式，对软件质量和测试方法的理解以及测试和操作工具的一些小诀窍。这些都对我们以后的测试活动有所帮助，所以即使从项目来讲测试效率提升不明显，但从长远来讲，个人和公司都会因此而受益。
那么怎么结对才能使产生最大化的收益呢，我总结了下面几点：
-
结对测试采用自愿原则，对于一些对结对工作有强烈抵触情绪的人或者进行了相关尝试之后发现自己确实不适合结对工作的人，一定不要强制要求其结对，否则测试的质量和效率可能不升反降。
-
结对测试时最好选择性格合得来的人，否则一有分歧就陷入争吵或冷战，对测试也是没有好处的。话说回来，想找个合得来的不一定会那么容易，所以这就要求我们在结对的时候多站在他人的角度思考问题，慢慢磨合，这样才会慢慢适应结对工作。
-
结对测试中原则上两人是平等的，但是也要有所分工，比如一人主导测试，另一人辅助，给主导测试的人以建议和监督，好似驾驶员和领航员一样互相配合。测试过程中角色要不断轮换，这样才能既平衡工作量，又增加两人的共同责任意识。
-
结对测试的两人要充分交换思想，这样才能将思维盲点和错误降到最低。比如一个测试人员发现了一个bug，另一个测试人员在充分理解其思想后可能会由这个bug联想到另外一种可能出现bug的情景。尽量避免主导测试的人独干、辅助人员浑水摸或辅助者施发命令、主导者沦为操作员的情况发生。
-
结对测试的两人水平最好接近，或者相差不是太大，这样才可以做到齐头并进，充分交换思想。如果两个人水平相差太大，水平高的人可能会抱怨水平低的人拉自己后退，导致效率变低。水平低的人又往往会很难理解水平高的人的一些思想，产生焦急，或自卑的情绪，这都是不利于结对测试的开展。
-
比较适合结对测试的测试阶段有单元测试，集成/系统测试的测试用例分析设计阶段，探索性测试和自动化测试的开发阶段。对于一般的集成/系统测试的测试执行阶段，结对并不会对效率产生什么帮助，对质量的提升也是微乎其微的。但对核心模块或质量要求非常高的测试来说，最好全程采用结对，包括测试执行，因为在这里漏掉一个bug的代价可是非常高的。
-
单元测试和自动化测试的开发阶段，如果没有适合结对的测试人员，可以适当选择测试和开发结对的策略，由于思维和技能的差异，可以会产生更大的覆盖面。当然测试人员需要一定的编码能力，开发人员也要有一些测试思想，以避免能力相差太大带来的负面影响。
-
结对测试的时间不宜过长，一定要留下充分的独立思考的时间。因为结对毕竟会收对方的影响，使得在某些问题上不能完全坚持自己的主张，或否定自己的思想，可能会导致对一些问题的思考不够充分，并产生漏掉bug的可能。
看了以上几点，相信大家对结对测试也有了自己的理解，希望大家能留下自己的想法，也欢迎有过结对测试经历的同学能够分享自己的经验。
参考：
http://www.kohl.ca/articles/pairtesting.html
http://www.kaner.com/pdfs/exptest.pdf
http://www.stickyminds.com/article/software-testing-twos?page=0%2C0
还有一些长得都差不多的中文文章，请原谅我实在分不清原作者是谁，这里就不写了。。。
