从开发转测试的那一天起，从我抛弃C# ，IIS 和 sql server起。我就学习了那些测试理论知识，百度文库，51testing，爱问知识人，豆丁网。你可以找到几百本类似的测试知识的书籍。从学习时到工作后，一直都是这些测试理论。好像新闻联播里面那些每天必须播出的词段一样。但是真正的测试经验和知识，我想说：是从实际的工作经验中得到的。这些是最重要，最核心的。我们要善于从工作中积累，总结转换为自己的杀手锏。中医越老越专业。

　　分享知识，收获快乐。如果我知道的知识，正是别人困惑的问题。那我希望我的一些拙见对大家有点用处。有问题欢迎大家指出。谢谢。

　　因为我们的角色是测试人员。有的公司称为质量保证部。望文生义，我们是保证软件产品的质量的。除了ST之外，只要的一个环节是UAT。针对于UAT测试，我从我个人实际的工作中举些报表类系统的例子吧。我个人认为在UAT阶段有以下几个关注点和内容：

　　UAT阶段测试人员的准备工作：

　　1：界面展现层和业务服务层

　　（a）正常的测试环境（包括应用服务器和数据库都能够正常访问），知会业务验收测试时请再次确认环境的连通性；

　　（b）系统角色清单中对应的单一测试用户UM账号和万能测试用户备用户验收使用。

　　（c）系统当前数据内容知会：例如某类报表在当前环境的数据库中只有某一段时间的数据。或者这类报表中只允许回溯一月之内的数据。那么请将此时间节点通知用户。如果涉及关联系统如上下游系统又数据依赖关系。那么可以提早准备上游源数据以附件的形式发送给验收的用户，以减少沟通成本，提高用户的验收效率。

　　（d）用户体验建议：若一张报表中有多个查询条件，且有非空和可为空的组合条件等。实例：某张报表对于业务公司某个渠道的考核标准相当多，导致系统需要统计的字段相当多达到二十至三十多。在操作上我们会建议用户决定是否使用默认查询条件，以避免用户在系统操作过程中产生的时间耗费。加强系统的易操作性和人性化特点。使用户体验感觉更加良好。

　　（e）完整的业务流程测试。正常流程，异常流程以及组合流程。如果流程较少可以采用枚举或者说穷举法。如果流程较多，那我们就协助用户，用等价类划分来进行测试吧。

　　2：业务逻辑层（系统计算逻辑和业务计算逻辑的比对）

　　用户最关注的，最想看到的就是自己心中想象的系统界面和自己心中早已想象好的数据模样。每一个目录，菜单，每一张报表。更加重要的是：系统数据计算的正确性。这里的数据加工正确性并不仅仅是加减乘除的正确性（这个数据加工正确与否我们测试人员一般都能够正确判断）。还有业务逻辑的加工规则是否正确。例如两个不同架构的相同报表 A  B。都计算一个字段：客户转换率。A为部门级的报表，它的客户转换率不用除这个月的固定基数值。B为人员级的报表，它的客户转化率这个值必须除以其他指标加上固定基数的和作为除数。显然，两张表的其他字段的值可以是完全一样的。但是客户转换率这个字段的值一样。那么这张报表就是有问题的。因为B表的 客户转换率字段的分母显然比A表客户转换率的分母大。

　　其他小notice：

　　1：在冒烟测试完成后，ST测试开始不久就应该通知业务同事进行UAT测试。这种并行测试方法可以减少开发人员的移交次数，节约测试时间。因为业务和IT测试人员关注点完全不一样，不存在测试工作上的重复。本人曾经ST将近完成的时候才通知业务进行UAT结果导致用户验收时间不足。发现当初沟通需求时，因为需求未表述清晰导致开发和测试人员理解上的偏差，导致代码需要大面积的更改，只能够下一个版本进行修复和优化了。

　　2：对于业务提出的一些问题，请单独记录并分析，分类。例如：采用excel 进行记录。并标注解决状态（新建  已修复 验收通过）。分析完毕后的此文档可以作为自己的测试资产。为以后的UAT测试工作提供一些共性问题的参考资料。更快捷的定位并通知开发同事修复问题。逐渐的减少共性问题的发现。提高开发  测试 用户的工作效率。共同保证系统质量！

　　以上为自己的日常工作中总结的一点点拙见。希望大家指出问题并补充您的方法。谢谢！