UAT：它也是一种“群体测试”吗？

时间：2014-07-29 18:06:32 阅读：254 评论：0 收藏：0 [点我收藏+]

	Viktor Grebenyuk是一名质量保证专家和测试经理，在测试复杂的（主要是金融领域的）系统和应用程序方面有八年以上的经验。他丰富的经验让他可以：比较不同的测试工具和方法，突出它们的优缺点，并努力找到最适合每个特定案例的正确方法。
	Natalya Serdyuchenko自2004年以来就一直从事软件开发和测试。她曾与摩托罗拉，索尼爱立信，华为等客户合作，担任测试工程师，测试经理和首席分析师。她目前的工作与银行产业有关。Natalya对改善测试流程，特别是UAT流程有着浓厚的兴趣。

　　用户接受测试（UAT）看起来像“群体测试”主要是因为：执行此测试的人不是测试专家。这些人可能是他们自己业务领域的专业人士，但却对软件测试原理和技巧还不是很懂。你可能会争辩UAT的价值及其在SDLC里的地位，但是一旦你决定去做UAT，你就必须得解决如何让非测试人员（如：企业用户）有效负责此事。另外，你或许需要考虑一系列问题：该如何在你的组织里将UAT和现有测试程序结合起来；创建UAT测试用例的需要及这些测试用例应该看起来像什么；以及谁负责UAT管理。本文的目的是减少在一个项目上组织和管理UAT时你可能发现的关键问题。

　　如何让非测试人员（企业用户）有效地进行UAT
　　首先，如果你想强制非测试人员（我们称他们为UAT执行者）有效进行UAT，你必须教他们如何做到这一点。你可以使用任何相关的培训策略（在线培训，面对面会议等）提供为项目选择的UAT方法或在你的组织中被批准的一般UAT程序的概述，并在UAT中突出他们的职责。一旦有了这些信息，也有利于共享软件测试的基本知识，并为他们提供一个在UAT中将被使用的测试工具的示范。除此之外，或许有必要为他们展示端到端的业务流程的概述。因为事实上一些UAT执行者心中可能并没有完全掌握端到端的业务流程只是因为他们的日常工作往往局限于被测解决方案（ SUT ）的一个独立部分的使用。请记住，即使在已经通过了所有培训课程并学习了你项目开始时给他们提供的所有材料后，UAT中，人们仍然需要持续地咨询和支持。随时做好准备，并与UAT执行者保持联系，要记得，某些时候你或许需要对一些人重复初始培训。即使有些企业用户过去参加过UAT，有经验了，仍然需要为他们提供至少一个有限的培训课程，因为UAT过程的某些方面可能会因项目而异。在某些情况下，只分享UAT方法或测试技术并不足以使UAT执行者有效地进行UAT—— 最难的事情是激励人们。 UAT执行者应明确认识UAT的目的并了解他们的责任以及他们正在增加的价值。如你所知，有动力的人才能取得更大的成绩，所以，如果你想从你的UAT获得尽可能多的优势，你应该尽力让这些人不仅仅只是遵循正式程序，还要愿意参与到UAT中去。这样的话，你不仅会获得好处还能体会到乐趣——下一次与这些有动力的UAT执行者合作就更容易了。在任何情况下（即使你没有能力为这些人提供任何额外的动力），都请确保你以甚至只让人们遵循正式步骤就可以获益的方法去设置过程。
　　这种情况下几点建议将帮助你，如：
　　 ?给UAT执行者提供包含他们可能会在UAT中所需要的所有信息（关于测试环境，获得被测apps，如何使用测试工具的手册，联系人列表，等等信息）的详细说明;
　　 ?提出一个UAT执行者和UAT团队其他成员之间的明确沟通计划;
　　 ?制定一个清晰易懂的可以在UAT过程中使用的程序以解决UAT执行者的问题;
　　 ?确保UAT经理和UAT团队其他成员在解决UAT执行者的问题中的高参与度（他们应该在任何时候都可以感觉到有人可以帮助他们）。
　　拥有一个有固定测试时间的UAT执行者团队将是一个真正的优势（假定50％的时间用来测试，50％的用于线下活动）。建立合理的循环，就可以建立一个UAT专家团队，节省大量培训时间去做进一步的UATs。

　　如何在你的组织机构中将UAT与现有的测试程序结合起来
　　将UAT与组织中正在使用的其他测试程序及相关标准（这一点在UAT是项目中使用的唯一一种测试的情况中尤其重要）结合起来很重要。
特别是，你需要确保你生产成为UAT一部分的测试物，文献和报告与预计生产成为其他测试活动的一部分的是一致的。这也适用于测试管理工具和缺陷跟踪工具：建议所有测试结果以与被其他类测试管理一样的方式被获取和管理。
　　这将有助于为执行和执行结果计划的UAT测试用例（如果你有大量的UAT利益相关者，这一点尤其有效）获得更大的知名度。识别被发现为其他测试活动（如果有的话）一部分的缺陷的副本，并确保所有已识别的缺陷得到妥善处理。

　　你需要生产作为UAT一部分的测试用例吗？他们应该看起来像什么？
从一开始就必须注意，我们强烈建议为UAT编写测试用例（它们可以被称为测试用例，测试脚本，用例，用户故事，等等）。企业用户常常尽量避免这样做，理由是他们已经知道他们将要做什么及怎么做，因为它与他们的日常工作类似。捕捉提前为执行而计划的所有测试用例仍然很重要。
　　首先，这可以让你了解究竟要验证什么，为此要做些什么，预计会有什么结果。创建UAT测试用例不仅对在实际开始执行过程前规定验证范围很有必要（有时人们在或许真的可以给正被执行的测试增加价值的测试期间开始进行额外检查，但也可以毁掉整个UAT计划或为测试的其他部分准备的相关数据），同时也使得UAT的执行在资源和基础设施的使用计划（包括人力资源）方面更有效，增加了测试集的坚固性（例如，它有助于在平行多人创建UAT测试用例时避免重复检查，或帮助揭示覆盖缺口和错误假设），并让你能够在执行阶段更精确地追踪UAT进度。UAT的性质不同于开发人员或测试专家正在执行的测试类型—— UAT没有如验证被测系统是否正常工作这样的目标。这种类型的测试的主要目标是确保SUT响应客户的期望，并使企业的目标得以实现。正因为如此，UAT测试脚本看起来应该是什么样的并没有硬性规定——他们可能被创建为正式的测试用例，用户故事，甚至审核清单。UAT案例的细节的格式和水平可以根据下几个因素而有所不同：
　　 ?你用于开发和执行测试用例的时间。
　　 ?测试基础设施的制约。
　　 ?UAT执行者的经验（包括他们在企业领域的经验和软件测试原理和技术业务方面的经验）。
　　 ?UAT团队成员的可能循环（你可以在你项目的UAT过程中使用相同的企业用户，或有时你需要换用新人）。
　　不论UAT测试将被写入的方式，UAT测试中的与其他测试类型（例如前提，将被执行的一系列步骤，期待的结果或一名参赛者）使用的相同的强制测试用例属性要被包含在内。定义一个将实施这个测试用例的业务角色非常重要，因为同一个业务场景根据执行者可以有不同的流量（同时请考虑一下客户体验——让某个人扮演客户以确保过程与最终客户的角度一致是很有用的）。计划测试用例的开发时，你可能会把这些因素考虑在内，但你也应该记住，准备的测试用例很明确且它们很可能由企业用户运行都很重要，这取决于测试哪个业务过程。当你考虑UAT测试用例的覆盖范围时，除了对业务流程的特定bit的单独验证，你还应该考虑加上一个终端到终端的业务流程验证。最后，如果你想从UAT测试用例获得好处，你应该牢记你决定开发他们的理由。对这件事不要采取正式方法，而要以饱满的热情（这最后一条建议适用于UAT过程中的任何活动及其他）创建它们。请记住，UAT的执行有时可能会更新原来的业务需求，甚至创造新的需求，因为UAT的执行正成为企业用户（多数情况下的需求发起人）重新思考他们原先需求的正确性和详细水平，以及业务目标的完整性的另一原因，因为，在这一点上，他们已经开始使用新的解决方案，甚至第一次详细地看了新的解决方案。创建UAT测试用例较早地利用了业务需求识别问题，这样修复它们的成本可能会减少。

　　谁负责UAT管理？
　　 UAT的关键成功因素之一是选择合适的人来管理这项活动。 UAT往往被视为（相对于解决方案而执行的）测试类型之一，所以让一名测试经理或测试领导管理UAT或许看起来蛮合理的。此人在管理UAT时很可能有类似责任心且必须处理类似问题，如他或她管理系统集成测试（ SIT ）时面对的问题。另一方面，UAT经理将会需要处理一些其他类型的（在某些情况下需要额外的个人技能和/或关于被测系统的商业逻辑知识的）问题。例如，UAT管理和SIT管理之间的重要区别之一是，正在做UAT的人不直接向UAT经理汇报（这是UAT看起来像一种“群体测试”的另一个原因）。正在做UAT的人仍准备好了他们的生产线管理，这也需要这些人去做他们的主要（即非测试）工作。因此，在某些情况下，UAT经理必须找到UAT执行者线上活动和UAT相关活动之间的适当平衡点。在这种情况下，UAT经理应该有机会获得升级路径，因为测试者无法及时实施其UAT的一部分可能会危及整个UAT活动。值得一提的是，避免任何形式的利益冲突，特别是当一些人在项目团队中担任多个角色时，也很重要。

　　结论
　　 UAT是解决方案生产前的最后一站，这意味着UAT的组织和管理方式将（在大多数情况下）定义开发了的解决方案的企业用户期望，这意味着UAT的作用尤其重要。我们希望这篇文章将帮你避免常见的错误，在你的项目中提高UAT效率。一件需要铭记的事是，即使你已经创建了一个强大的UAT过程，如果你找到一种方法来激励人们，你总能从你的群体测试中获得更多。