原文：https://www.stickyminds.com/article/who-what-when-and-how-pair-testing

概要： 结对测试可以帮助您加快测试任务并为测试结果提供更高质量。但谁(Who)可以进行结对测试，他们应该在什么时候(When)进行测试？什么样(What)的结对测试最适合你的情况？本文为您提供更多关于如何(How)进行结对测试以最大限度地发挥其优势的信息。

谁可以做结对测试

与开发人员或其他测试人员进行结对测试的情况经常发生，但请注意，这些不是唯一可以做到的规则。

文档编写人员可以联系测试人员以获取有关下一版应用程序内容的信息。然后测试人员将引导文档编写者完成新功能，并为下一个版本提供所需的文档。

客户可以想出一个需要调查的问题。与客户一起，测试人员将重现错误场景以查看正在发生的事情。

而业务分析师或解决方案设计人员只需访谈测试人员即走查该功能。在某个时刻进行检查时，他们可能会提出这样的问题：“如果你这样做会发生什么？”一些严重的探索性测试从这里开始，测试人员可能会发现一些错误。

我甚至听说过一位知名测试人员不得不带着他的儿子在国内另一个地方进行紧急任务。当他的儿子坐在他旁边时，他要求他的儿子接管键盘并帮助进行测试工作。孩子发现了一些很酷的错误。

我与我的Scrum团队的所有成员一起进行测试 - 与开发人员一起调查错误，解决方案设计人员检查功能的某些行为，业务分析师将展示新功能的工作方式以及视觉设计师了解用户界面与我们所期望的相关的外观。

几乎每个人都可以进行结对测试。一旦我与我的交付经理就应用程序中的问题讨论了一种情况。我也看到了这个问题，但我无法控制它。在评估情况并与交付经理进行一些结对测试时，我发现：在某些情况下，我正在处理的一个功能似乎会干扰该应用程序的这一部分。事实证明，这是一个不争的事实，需要立即修复后端系统来解决这个问题。我最终可能自己解决了这个问题，但结对帮助我们更快地找到了问题。

何时进行结对测试

我经常与我的Scrum团队的成员进行结对测试。这些发生在整个软件开发生命周期中，无论是在一个sprint还是几个sprints中。

您还可以使用结对测试作为学习机会，例如通过一起进行一些测试，让新的同事或初级测试人员加速应用程序的速度。

来自于其它角色的支持也可以通过一个结对测试来完成。您可以在设计过程中询问设计人员某些功能的工作原理，在您阅读某些文档之前，在您知道该功能之前，一起使用白板，讨论与该功能相关的各种场景。从另外一个角度来看，业务分析师可能会问你这个功能究竟是如何工作的，并且你最终会做结对测试，看看这个功能是否可以增强。

结对测试也可以在需要调查问题时完成。您可以去其他团队成员（测试人员或其他人）寻求建议，或者您可能会被客户代理要求查看客户问题。

这些对结对测试来说都是很好的机会，但是它也可能发生在你根本没注意到它的时候。

比如我会和我的业务分析师定期进行一些配对测试。我们一起测试一些功能标签以查看分析是否有效，并在业务分析师检查数据时执行测试。

如何做对测试

结对测试可以自发地发生，即使是偶然的，或者你可以采取预定义的方法。因此，我区分了两种类型的结对测试：主动结对测试和隐式结对测试。

在主动结对测试中，您可以预先准备好您要做的测试工作。您按照计划和执行测试想法为您争取时间。你会坐在一起商定一段时间，并做一些探索。一切都是预定义的，双方都在积极努力结对测试。

然后就会出现配对测试刚刚发生的情况。

在调查问题的同时，你会陷入困境并要求同事寻求帮助。当你在一起工作并想出新的东西来测试时，使用不同的测试数据，你会发现问题的原因。那是一些无计划的结对测试。

然后，您的同事来到您的办公桌，询问某个功能的新流程如何运作。当你向他解释这一点时，他开始提问。你可以回答大部分问题，但他会询问你没有发生的情况。咦？这是一个错误。感谢您与我一起进行一些测试。

当你准备出差或假期休假时，你去找一位同事解释已经完成了什么以及还有哪些工作要做。当你从这次旅行回来时，你会去找这位同事，她会告诉你什么被覆盖了，她发现了什么。这是也是结对。

看着这些情况，你可以看到结对测试刚刚发生了。你走到一个人或一个人走到你的办公桌前，在你知道它之前，你已经做了一些结对测试。我称这种情况为隐式结对测试。

如果你想积极开展一些结对测试，最好的做法是与一个你信任的同事合作。您们可以一起确定对测试会话的重点和范围。

为您的结对测试计划前期工作。建立一个可以一起测试的环境，而不会有任何问题 - 这意味着一个桌面，与应用程序一起工作的工具，以及一个可以一起工作的时间窗口。你可以通过经理批准来做到这一点，或者只是自己主动。评估结果并将其呈现给您的利益相关者。

结对测试与结对编程

如果一个开发人员要求查看某个功能并查看其是怎么工作的，那么最终可能会在此活动中重写某些代码，甚至创建新代码。在这种情况下，你是结对编程。结对编程的结果是新的或更改的代码，开发人员是主控人。

当您要求开发人员查看您在其代码中遇到的问题时，你们一起判断这只是一个测试失误还是真正的bug，在这种情况下，是结对测试。结对测试的结果对是关于问题是否是Bug，测试人员是主控人。

当你和一个开发人员在一起进行自动化时，有时你是结对测试，有时你是结对编程。有时你甚至可能没有注意到这种变化。

我定期与我的开发人员合作。我们一起编写代码来支持我们的测试，比如单元测试，UI测试，端到端和回归测试。我们都执行这些测试，看看它们是否工作。我为自动化创建的测试由开发人员进行代码审查，以查看是否需要改进，有时我们在进行结对活动时直接重构它们。

结对测试的结果

为了使结对测试取得成功，你必须提供一些有形的结果。可以有几个输出：

测试文档：在准备测试时，您将生成一些文档。将出现这两个主要文件是一个测试计划和一套测试想法来支持您的执行。

缺陷报告：在与开发人员或客户调查问题时，您可能会意识到这是一个导致真正问题的错误。您编写的缺陷报告将解决问题。

活动报告：当一对一执行测试时，一个正在测试，另一个正在做笔记。以这样一种方式写下这些笔记是一个好主意，以便信息可以转发给其他团队成员或利益相关者。

共享知识：虽然共享知识不被视为有形产出，但我认为将其作为结果提及是很重要的。结对意味着在测试中共同工作的专家有两名，所以您可以消除单点故障的情况，从而为您的测试提供更多信心。

面向利益相关者的信息：信息可以是您所写的测试计划，您根据测试想法所做的测试，或者会话报告中记录的所有内容。信息也可能是您发现，报告和重新测试的错误。所有这些信息对利益相关方都是有价值的，因为它建议他们如何进行。

测试是自动化的：与您的开发人员一起创建和自动化的测试将被添加到回归测试套件中。这些新测试将减轻您形成重复性回归测试工作的难度，并可以专注于实际问题。

在我的日常工作中，我会定期与我的Scrum团队的同事进行结对测试。有些活动时间短，只需几分钟到一个小时，有些活动时间更长，最多一天。有时候是有计划的，有时是自发的。

在有探索，思考和创造空间的环境中，结对测试效果最佳。您不需要预定义测试脚本。你不需要用户界面作为测试的起点。所有你需要的是两个批判性思考的人 - 一个有创造力的人和一个破坏性的人。毕竟，两个头比一个好。