UAT测试

UAT

UAT（User Acceptance Test），用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

1.测试目的：

本阶段测试是为了测试开发出来的产品是否能够满足用户的需求，因为只有用户实际使用了产品，根据实际体验才能知道产品是否能满足要求。同时也是为了找出在实际环境中可能出现的一些Bug，并及时修复。

2.测试参与人员：

UAT测试顾名思义可以知道测试的主体应该是实际客户，本阶段的测试需要客户直接参与，因为研发、测试甚至PM都不能准备的了解客户实际环境下如何使用产品，所有本阶段的测试参与者主要是实际客户。

3.测试用例：

UAT的用例原则上来讲应该是用户自行按照实际使用来设计，但考虑到客户对新系统的不熟悉，可以采用测试人员设计用例，邀请实际客户参与评审的方式来设计用例。

4.测试范围：

测试应该包含安装、环境部署、各个子模块的基本功能等系统一个完成过程中的所有部分（也包含用户手册），同时应该根据用户实际使用环境着重测试客户使用频率高的模块，尽可能将用户常用模块中可能隐藏着的问题发现出来并修改。

5.UAT测试的前提：

UAT需要满足一定的条件才能开始，进行UAT的产品理论上来说，必须已经全部开发、测试完毕，代码状态处于冻结状态，所有测试出来的bug都已经被妥善处理，重大的bug 都被解决，并验证通过。对于一些低级别bug ，要么决定被写入发布公告中，要么被设置为不需要修改的问题。在实际项目操作过程中，由于计划进度原因达不到理论状态前提，UAT的效果也达不到应有的效果。

6.UAT测试策略：

UAT测试理论上是用户按照使用手册进行操作，或者安排组织客户培训后让用户操作。测试过程应该有用户独立完成各个步骤，根据用户要求可以安排研发或测试的人员陪同测试，既能在过程中起到指导帮助作用，也能在测试发现Bug的时候做第一时间的调查分析。

7.UAT 测试通过条件：

●成功地执行了测试计划中规定的测试用例；

●修正了所发现的功能性错误；

●用户肯定测试结果，并通过了专门小组的评审，评审人员应该包含客户、产品经理、

项目经理、研发负责人、测试负责人等。

最后用户在确认书上签字认可测试结果，确认产品能够满足客户需求。

UAT测试的难点和建议：

难点：

1.用例设计无法有限覆盖实际环境：

很多时候UAT测试用例仍然是由测试人员甚至是开发人员设计，他们并不能真正的了解真实客户更多的需求，也无法完全知道用户的真实使用环境，所以设计出来的UAT 用例很多时候仍然是系统测试级的用例。

2.客户对系统不熟悉：

客户在实际测试的时候或多或少还是存在着对系统不熟悉的情况，测试效率不高，进度比较慢；再者很多时候客户不愿意安排人员来进行UAT测试，UAT测试实际上仍然是测试人员完成，由于使用习惯和思维惯性，使得潜在的问题不易发现，造成问题遗漏。

3.认为UAT可有可无：

因为进入到此阶段本身就意味着开发和测试进入到后期，已经完成了系统测试，认为已经完成了系统测试，系统就没有大的问题，UAT可以不开展了，这样节约系统上线时间，早日带来价值。

建议：

1.尝试在开发的过程中邀请客户参与，尤其是当重要功能集成好后，应该立即邀

请客户参与到测试中来，即可让用户尽早熟悉系统，对产品有一个初步的认识，

又可以在用户体验后及时了解用户的需求更新（如易用性），并落实更改。

2.坚持UAT测试，因为用户在使用系统的时候是为了完成真实任务和工作，是最

真实的使用环境和真实的数据，真实环境的真实数据得到的测试结果最真实可

靠；同时也能有效的避免研发和测试人员在前期形成的定式思维。从而能更有

效的发现潜在问题。

3.UAT测试一般来讲是上线前最后一次需求确认的机会，一旦系统推广上线后再

发现某些需求不满足或者实现出现了偏差，修改和维护的成本大幅提高，造成

时间和费用的双重消耗。