一、背景
在敏捷项目中，用户验收测试（UAT）作为最后一项测试，担负着两个使命。其一是确保软件符合用户需求，即满足实际业务需求，使终端用户认可系统逻辑。其二是保证软件可以在实际环境或接近实际环境中运行。然而，随着业务复杂度和系统规模的不断提升，UAT验收的风险也随之增加。因此，需要采取更完备的应对计划和风险控制措施，以确保项目的成功实施。
二、UAT验收测试的基础
产品的成功与否取决于是否能够满足最终用户的需求。然而，产品设计视角和最终用户视角存在矛盾。产品设计是从全局角度考虑问题，而最终用户则是从自己的视角考虑问题，这就会产生很大的矛盾。对于大型的系统来说，最终用户的人员非常庞杂，如何管理业务用户的期望，引导他们理解整体产品的设计方案，从更高的维度来看待产品是UAT验收测试面临的主要挑战。
在UAT验收测试中，我们经常会遇到各种问题。例如，用户第一次接触产品时感觉与自己的预期不符，导致他们对产品不满意，甚至不想继续进行验收；使用过程中发现产品与线下习惯不一致，要求改变，但可能会影响其他功能；或者验证过程中，用户提出了新的需求和改进意见。
为了避免或减少这些问题的发生，我们可以从需求早期开始与关键客户进行沟通交流，通过关键场景、产品原型、Showcase、试用等方式加深他们对产品的理解，引导他们理解整体产品设计方案，为最终的UAT验收测试打好基础。这不仅可以帮助我们更好地满足最终用户的需求，还可以提高产品的成功率。
关键场景确认
关键场景是指产品中最重要、最核心的功能场景。在产品设计和开发过程中，需要通过和关键用户的沟通和交流，确定产品的关键场景，并对这些场景进行深入了解和分析，以确保产品的设计和开发能够满足用户的需求。同时要和关键用户确定关键场景的验收标准，以便在后期验收中达成一致。
产品原型
产品原型是在设计前期开发出来的，以草图或模型的形式呈现产品的大致轮廓和功能。产品原型更直观地展示出产品，给用户更多视觉上的感受。基于产品原型与关键用户沟通和交流，能够在早期形成对产品的直观印象，激发他们对产品需求的思考，避免后期的发散。
Showcase
Showcase是和业务的最早连接真实连接。每个迭代阶段要求关键的用户来观看关键场景的Showcase，以确保每阶段的主干核心场景是符合业务诉求的。在此时获得关键用户的反馈和新诉求，还可以在下一阶段迭代中及时修正和调整，避免到UAT验收阶段才发现大量的不一致看法。
关键用户试用
所有的观看都不如真正的上手试一试。 在真正的UAT测试之前，我们还安排了一个关键用户试用的环节。在SIT产品内集成测试完成之后，邀请关键用户来进行一个简单的试用。
说是试用也并不是无目的上来乱用。最重要的原则依然是管理用户的期望，进行合理的引导。 首先要做一个简单的关键场景的培训，带着用户把关键场景过一遍，了解整个的过程。并在特定环境上试用特定数据允许他们上手试一试，收集他们对系统初体验的感受和想法，并对一些疑问进行解答。
最后，基于关键用户的反馈，形成一个常见Q&A（避坑宝典），以避免后续大规模UAT验收时面对庞大的业务团队，无力应对众多的问题。关键用户也可以作为种子选手，在真正UAT验收测试中帮助为其他的业务人员介绍线下业务流程如何在系统中进行操作，避免由于对系统不熟悉产生的问题，提高UAT效率。
总之，通过关键场景，产品原型、Showcase、关键用户试用等方式来与关键用户沟通和交流，可以让用户更好地了解产品功能和设计，更早的获得用户反馈，从而减少UAT测试中出现的问题，提高产品的质量和用户满意度。
正式的UAT验收测试
在进行大规模的复杂产品的UAT验收测试时，由于涉及的三方系统比较繁多，统一UAT时间可能会导致时间的空白期，所以我们利用这段时间提前进行一轮UAT产品内验收测试。产品内验收测试主要聚焦在产品内的一些关键用户场景，对于外围产品的依赖用Mock来实现。UAT产品间验收测试是多个产品共同验收端到端的场景，涉及到的人员和场景更为复杂。
UAT验收测试的准备
通常情况下，我们的产品终端用户都是“兼职”参加UAT测试，因此通常没有足够的时间参与UAT的全流程测试。为了能够合理安排业务验收测试，节约业务人员的时间和精力，在开始正式的UAT验收测试之前，我们需要做好充分的准备工作。特别是对于端到端拉通验收测试，涉及的人员众多，场景复杂，需要更为详细的计划准备工作。
主要的准备工作包括正式的产品培训、业务验收人员的安排、测试用例准备、测试账号准备、测试数据准备、测试环境准备、技术支持准备、问题解决机制、缺陷验证、回归测试以及重新发布规则等。
产品培训
在测试开始之前，需要对所有参与的业务人员进行产品培训。现场进行产品功能的讲解和演示，并进行答疑，让大家对系统的使用有基本的了解，避免由于不理解系统功能产生的不合理缺陷。
测试用例准备
测试用例的准备是非常关键的一个环节。通常是在UAT之前，IT产品和测试人员共同协助关键用户基于关键场景生成验收测试用例。基于前期讨论的验收标准，结合关键场景，并利用一定的测试设计技巧，产出符合用户验收测试的测试用例。
在测试用例准备中，我们遇到很多困难。由于用户场景中的参数非常多，用例数量庞大，无法在规定时间内完成测试。因此，我们结合业务代码和测试设计的方法（例如Twopairs和正交法），剔除其中重复覆盖代码的用例，将用例数量控制在合理的范围。
通过与用户和产品经理充分沟通，从用户场景重要性、产品重要性和复杂度风险等多个维度确定测试用例的优先级，并制定合理的测试计划。
测试的业务人员安排
由于业务人员众多，不同的业务人员分管不同的业务场景，有些由于业务繁忙也无法到达现场。我们根据业务人员的负责的功能模块和场景不同以及实际的条件，把人员分成三个大组，两个梯队。第一梯队的人必须到现场进行验收测试，第二梯队的人可以远程进行。 每个组指定1个负责人，负责测试人员的到场情况，测试进度，以及测试中遇到的关键问题等的处理和协调。
测试账号准备
由于这是一个面向企业的产品，所有用户都需要提前设置账号和权限。在测试开始之前，我们会根据事先收集到的业务人员信息，为每个人员创建账号，并收集不同角色需要的权限，以便进行账号权限的配置，保证业务人员能够第一时间沉浸式地开展验收工作。
测试数据准备
制作UAT测试数据是非常费时、费力的过程。我们需要根据业务场景制定相应的测试数据，以确保测试的充分性和准确性。因此，在SIT阶段，我们会尽量使用贴近真实的业务数据进行测试。在UAT阶段，系统中的基础数据直接来源于脱敏处理后的生产数据。我们通过对终端用户进行访谈，尽量模拟真实数据和数据量的业务数据。为了验证基础数据的有效性，我们在SIT阶段进行了多轮数据集成测试，以确保基础数据能够在上下游系统中流通。
为了方便业务用户的使用，每个模块还准备了自己的可使用数据集合，共享给各个用户在验收测试中使用。
测试环境准备
UAT测试环境需要尽可能与生产环境保持一致，但实际情况很难达到与生产环境完全一致的资源。因此，我们需要尽量保留生产环境的一些特征，例如每个服务至少有两个instances，打开负载均衡等，各种规格和配置达到相当或者同比例减小，操作系统、网络配置、数据库等都尽量与生产环境保持一致。同时，还要确保服务版本匹配，端到端拉通时要保证整个环境的版本相匹配。
在测试环境准备中，测试人员需要提前对关键场景、关键数据甚至一些破坏性场景进行验证，以确保测试环境的可用性。
问题响应机制
为了在UAT中及时响应业务发现的各种问题，我们建立了多层次的问题响应机制：
现场专人支持：由不同模块的QA和BA/IT 产品构成现场支持团队，针对用户发现的问题，及时响应，提高用户的满意度。
建立分层筛查多角色配合的问题处理流程和标准：
QA初步判断问题是否是环境，配置或者使用的问题，是则当场解答或者推荐参考Q&A。
如果是针对方案设计的疑问，BA/产品经理将进行进一步的解释和回答，消除用户的疑问。
如果是新的需求或者优化建议，将问题登记到相应系统，标记为新需求和优化建议。之后BA和产品经理一起进行专题讨论处理。
如果确定是Bug，QA初步分析定位，进行缺陷登记后，走正常的缺陷处理流程。
如果是针对需求理解有争议，或者产品之间的接口有争议，则登记到待讨论问题列表，在每日碰头会上进行拉通讨论。如果无法决策，则升级到更高一级进行讨论。
每日问题拉通。每日结束前对今天的问题进行总结拉通，未解决的问题通过邮件、电话、即时通讯工具或者专题讨论等方式来收集问题反馈，并及时安排专人负责处理和响应。
根据问题的重要性和紧急程度，制定相应的问题处理计划。对于重要性高、紧急程度高的问题，限定24小时内处理和解决；对于重要性低、紧急程度低的问题，可以安排在后续的版本中进行修复。
建立问题库的各种记录标准，比如发现问题类型，阶段，问题流转状态，处理过程以及最终决策，以便后续的追溯和分析。
通过以上的问题响应机制，可以及时响应和解决UAT中发现的问题，提高产品的质量和用户满意度。
缺陷验证以及重新发布规则
正是的，您对UAT阶段发现的缺陷的处理方式的描述是正确的。当发现的缺陷影响到上下游其他系统的业务流程时，会被定义为紧急缺陷，这种缺陷会被优先处理和修复。修复后，需要在SIT环境进行验证，并提出发布申请，申请通过后才能发布到UAT环境。对于不影响业务流程的修复，也需要在验证后进行版本发布，通常在非工作时间进行统一的版本发布以避免对UAT测试进度产生影响。
UAT产品内测试
UAT产品内验收测试是UAT的第一阶段，主要聚焦于产品内的一些关键用户场景。对于外围产品的依赖，我们使用Mock来实现。在UAT产品内测试中，我们尽可能地完成所有场景测试，并记录所有问题，包括缺陷、性能瓶颈、易用性问题等。这有助于为后续的端到端验收打下坚实的基础。
同时，我们还需要保持测试的节奏。如果存在一些关键场景的阻塞问题或遗漏，我们将触发紧急处理机制，快速修复升级，以保证测试的顺畅进行。
在测试结束后，我们及时地对测试结果进行总结和分析。针对一些发现的问题进行专题讨论，例如UI优化专题，邀请UX和产品专家及时修正设计原则和方向，进行统一修改，以为UAT测试的下一阶段验证做好准备。
总之，在UAT产品内测试中，我们需要保证测试的质量和效率，尽可能地发现和解决问题，以保证UAT的顺利进行。
UAT拉通验收测试(E2E UAT)
E2E UAT 拉通验收测试是UAT 的最终阶段。它涉及验证整个端到端业务流程。这是为了确保系统能够正确处理用户的所有业务需求，并满足所有验收标准。
和SIT拉通测试一样，我们也准备了详细的场景计划，每天有哪些场景启动，哪些场景结束，以及中间的流转过程都详细规划，确保多个团队可以步调一致，通力合作。
在 E2E UAT 期间，将测试整个业务流程，从开始到结束。系统能够处理的所有类型的数据和场景，包括错误处理和数据验证都将被验证。最重要的还是多个系统间的接口能够正常通信，协调一致保证整个业务流程的进行。
在 E2E UAT 期间发现的问题，大多数是多个系统接口的问题，这些问题将被记录在一个共享看板上，每天结束前将由各系统一起拉通问题的定位和解决方案，一旦确定了修改系统，将把问题复制到相应系统的看板上进行处理。相应的场景将会被标记重测，问题修复后进行重测验证。
总之，E2E UAT是 UAT 过程中至关重要的一步，确保了所有系统已准备好进行生产使用，并满足所有用户的业务需求。
总结
随着用户验收篇的完成，大规模敏捷测试怎么做系列也接近尾声了。在这个系列中，我们介绍了大规模敏捷测试的三部曲：迭代内测试，SIT系统集成测试和UAT用户验收测试。每个阶段都有其独特的特点和目标，下面我们再来回顾一下：
迭代内测试
迭代内测试是大规模敏捷开发过程中的第一阶段，也是开发流程中最重要的测试环节之一。它是整个质量保证的基础。 在迭代内测试期间，团队会执行各种类型的质量保证活动，包括开卡，验卡，单元测试，模块内集成测试，用户故事功能测试，性能测试等，以验证软件是否符合需求和验收标准。
迭代内质量保证的特点包括：
测试左移：迭代内BA，开发和测试要紧密协作，测试尽早的参与到需求澄清，验收标准制定，通过不断的提问确保需求的描述质量。 同时在开卡，验卡过程中，从测试角度不断拉通对齐和BA，开发对需求的认知，保障需求传递的质量。 从而尽早的发现问题和解决问题。
高度自动化快速反馈：迭代一般周期非常短，通常2周一个迭代。迭代内测试是一个持续测试的过程，为了确保测试过程的效率和准确性，迭代内测试通常要求更高的自动化测试。比如单元测试覆盖率一般达到60%-80%的范围，而单接口的测试尽量可以达到100%。对于验收标准也可以采用BDD等方式来进行自动化。
探索式测试与Bugbash：基于每个用户故事的验收标准以及整个用户故事地图进行探索式测试是对自动化测试的有效补充。同时探索式测试也帮助发现更深层次的问题。 每1-2迭代组织不同角色进行一个短时间的Bugbash，有助于激发团队质量意识，从不同视角发现更广泛的问题。
SIT系统集成测试
SIT测试是大规模敏捷开发过程中的第二阶段，也称为系统集成测试。在SIT测试期间，会测试整个系统的集成和交互，确保系统不仅符合需求和规范，还可以与其他系统和组件互操作。
SIT系统集成测试的特点包括：
测试环境复杂：SIT测试通常需要在一个复杂的测试环境中进行，这包括多个硬件、软件和网络组件，和其他系统之间的连接等。为了更好地测试系统集成和交互，SIT测试需要在尽可能接近真实环境的测试环境中进行，并确保测试环境的稳定和可靠性。
需要跨团队合作：SIT测试需要跨团队合作，不仅测试人员，还有开发人员、运维人员等都要和不同部门，不同系统的团队合作。测试人员将作为主要的协调引擎，确保测试过程的顺利进行。
需要测试集成和交互：SIT测试的主要目标是测试系统的集成和交互，确保系统能够与其他系统和组件无缝协作。在SIT测试期间，测试计划需要更加详细和全面，包括测试场景、测试用例、测试数据等。测试计划应该考虑到各种可能的系统交互和集成情况，包括问题响应机制，多个团队之间接口处理规则等等都是需要提前考虑的问题。
UAT用户验收测试
UAT测试是大规模敏捷开发过程中的最后一个测试阶段，也称为用户验收测试。在UAT测试期间，最终用户将测试系统的功能、性能和用户体验等方面，以确保系统符合业务需求和用户期望。
UAT测试的特点包括：
管理用户期望：UAT测试需要最终用户参与，他们将测试系统的各个方面，以确保系统满足他们的需求和期望。但是用户更习惯于线下的使用，需要管理他们对于产品系统的期望，引导他们逐步熟悉产品系统，理解设计理念，并及时反馈。
强调用户体验：UAT测试的重点是用户体验，需要重点关注用户的反馈和建议，以确保系统符合用户期望。
高效及时的支持：为了让最终用户更好地理解和使用系统，除了提供详细的文档和培训材料外，还需要高效及时的响应支持。及时解答用户的疑问，消除使用的误解，提高用户满意度。
总体而言，大规模敏捷测试的三部曲——迭代内测试、SIT测试和UAT测试，可以逐步解决大规模系统的质量保证问题。在每个阶段中，测试团队需要根据测试目标和特点，制定相应的测试计划和测试策略，引入适当的测试工具和方法，以提高测试效率和质量。同时，测试团队还需要与其他团队协作，以确保系统的稳定性、可靠性和用户体验。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 350394277@qq.com
