借用练瑜伽的关键要点——
“松而不懈，直而不僵”
作为组织用户验收测试的内心理念^_^
进行一些补充，侧重于具体实践的可行性，而非空谈。
一. 用户验收测试的痛点在哪里？
1. 用户没有时间做验收？
-----将验收划分成几个阶段，集中验收耗时太久。详见第三部分的第1点：选择合适的时间点。
2. 与系统测试是否有重复劳动的资源浪费嫌疑？
-----不要直接就把系统丢给用户去测，不同的时间点采取不同的方式和手段去进行用户验收测试。详见第三部分的第1点和第2点。
3. 用户验收总是草草收场？
-----有的时候真的很取决于用户的责任心和专业度。对于重大项目用户验收反而是好做的，因为大家都重视。所以根源还是态度问题，重视程度是怎样的。
对于小需求，有的时候觉得追着用户做验收既浪费自己时间也未必能收到好的效果或者是否真的有那么大的必要，自己都在怀疑。这是我自己的个性弱点。
所以，作为测试人员需要不断的去推敲去体会什么样的需求需要什么样的验收，既保持住自己的立场又不失灵活性。甚至对于我自己来说，由于个性的弱点，甚至需要做一些心里斗争，而这恰恰是我觉察自己的最好机会，看到了就释然了，能够更不偏不倚更客观的做事情。
4. 用户验收应该与系统测试建立哪些区别？用户应该究竟关注什么？
-----个人认为用户验收与系统测试都需要测试人员去规划，而不是截然分开，直接扔给用户去测做甩手掌柜。根据用户的特点和擅长去规划用户验收。在第三部分有一些思考。
5. 用户与IT在验收中的分工和界限以及配合度是怎样的？
-----IT擅长测试效率的提升，比如可以帮助用户划分等价类，但注意不要过多的干涉，否则就体现不出用户验收的价值了，除非你非常确定是一个等价类。对于用户验收效率提升方面，主要体现在测试环境和测试数据方面的规划和及时支持。
二. 目前我们是怎么做用户验收测试的？
1. 项目型
1） 确定用户验收测试的负责人及职责分工
2） 基于需求的用户验收测试案例
3） 用户验收测试案例的评审
4） 用户验收测试准备工作支持
比如：准备测试用户，测试数据，与系统测试的数据区分开来，便于统计用户验收测试的情况。
5） 用户验收测试过程的监督和控制
6） 用户验收测试报告
2. 常规型
对于项目型，通常用户方也很重视，会抽调专门的人力参与。
但是对于常规型的用户验收测试，通常是在最后上线前几天，用户根据时间多少来选择性的测试或者干脆不测。
三. 我们可以有哪些突破和创新？
用户验收测试的目的并非是让用户分担测试工作量，也不是让用户共担质量风险。
用户验收测试的目的是保证上线的产品是用户真正想要的产品。
背景：用户没有提供规范的需求文档，开发也没有专门的需求分析和系统分析的岗位，用户和开发沟通个大概，开发人员就开始编码，在编码过程中出现各种疑问和细节问题再跟用户沟通。
测试方如何推动和保证用户验收测试的效果？
1. 选择合适的时间点
1） 测试评审完成：
这个时间点通常开发设计已经完成，测试评审通常会发现更细节的问题或疑问，有可能是需求方面的有可能是设计方面的，用户在这个时间介入主要是针对细节层面的问题和疑问进行解决和反思，有助于开发测试用户三方进一步的对需求进行深入思考，并增加对需求定版的信心。
2） 测试遍历结束：
这个时间点通常主要功能和流程能够走通，用户在这时介入可以更清楚更直观的看到需求实现成什么样子，纸上谈兵时如果产生误解，这个时候能够被清晰和及时的纠正或评估风险。
这个阶段，可能系统还存在一些非严重级别的BUG，对于不那么专业或抓不住重点的用户来说，这时候介入参与用户验收，会对IT有抱怨，而且测试人员还需要花额外的时间解释和沟通，效果不是最好的。
所以，这个阶段的用户验收可以以测试人员演示和讲解为主，主动告知已经完成到什么地步，还存在什么样的问题。
3） 系统测试完成：
这个时间点通常IT测试已经通过，不存在已知的BUG。这个时候，测试人员需要引导用户按照生产场景和角色进入到测试系统进行验收，用户这个时候因为前两个阶段的基础对系统已经较为熟悉，可以尽快上手测试。但是也有可能用户因为前两个阶段对系统已经很有信心了，而不愿意过多投入用户验收测试。
所以，测试人员要非常强调，用户这个阶段的工作重点是什么，一方面是做最后模拟生产的验收；另一方面准备系统上线的宣导和培训，以及试运行的准备。
这些貌似与测试无关，但其实是系统能够顺利在生产上运行的关键一环，测试的最终目的是让真实用户能够很好的使用系统，寻找BUG只是保证达到目的的步骤之一，不要在最后一环功亏一篑。
2. 选择合适的方式
1） 文档为媒介：分析完需求后要以测试的方法提炼关键要素，抽取要点，尽量将需求结构化。
2） 系统为原型：对程序实现增加感性认识，测试方对关键功能和规则做演示。
3） 用户从实际用户的角度体验系统。
3. 如何有力的支持用户
1） 衡量用户的业务水平和IT水平，视情况协调资源和安排计划
2） 评估用户擅长什么？擅长市场洞察，产品策划还是系统操作？让用户发挥他的擅长点去做用户验收。
3） 支持用户有效率的去做验收，比如IT通过技术手段快速的准备测试数据
4） 引导用户贴近生产场景去测试，并尽量分析实际的异常业务场景
5） 引导用户站在业务的全局观和长远规划去思考现有需求的合理性
4. 简化验收标准
UAT测试是用户接受度测试，划定重要功能范围，选取关键检查点，用户能够接受即符合验收标准。
四. 举例-对于统计分析类的需求：
1. 影响涉众：不同岗位和角色使用数据的方式是否有不同
2. 不同系统的数据是否会自相矛盾：比如数据在不同系统以不同的展现方式能够查到，要保证不会给数据的使用者造成迷惑，即使在统计口径上有所不同，但不要给使用者造成自相矛盾的感觉。
3. 总数和明细是否能对上：比如A系统里能查到明细，B系统里能查到总数，要关注总数和明细相符，并分析如果用户发现不同会有什么影响
4. 对于验收的方法：最好能从前台生成数据或查看数据，从前台验证结果数据是否正确。
