S1项目-测试阶段

排主计划时，UAT一般只预留1-2周时间，且遇到赶进度需调整主计划时，压缩的往往是测试时间。一是侯世达定律作祟，大家想着万一UAT顺利呢，一周用户测试、一周改bug，时间足够了；二是从整个项目交付来看，测试显的“不重要”，开发完一个功能、接口，体现的是实际进度变化，无法缩减，否则系统少功能，是显性取舍。其实在制定计划，包括做计划调整时，凭经验大家都知道要给uat留够时间，或缓冲时间，但往往只有到了测试阶段时，才会提出。是个有意思的现象，因为给领导汇报时，也有底气，已经是长征终点前的最后几步了，从项目组角度是可以按期上线的了，但为了测试充分些，提高用户体验度，提升上线成功率，适当延长UAT阶段，这个一般是可以接受的。对于项目组也好交差，测试碰到的问题属于不可见风险，谁知道UAT碰到这些问题呢，只能客观面对，延期解决。

测试分为单元测试、系统测试、集成测试及验收测试，逐级漏斗形拦截缺陷。S1项目资源紧张，产品团队内部测试不充分，要由现场交付团队找bug，毕竟是交付团队在面对客户，不想问题在客户面前集中爆发，只能辛苦交付了。

测试资料包括测试计划、培训资料、测试脚本、测试问题清单及测试报告。

测试应广泛邀请业务参与，虽然实际只有小比例参与。收集测试人员、部门、测试模块，用以提前配置测试账户及权限。提前发出测试安排，注明每个模块的培训时间。

培训资料往往是通用功能幻灯片，结合系统演示讲解。需把控时间按照测试安排进行，否则易陷入指导业务操作或回答业务细节问题上。培训应录屏保存。测试阶段的关键干系人，是关键用户。顾问应兼具教练的角色，对关键用户进行个性化辅导，对业务关键用户培训，使其成为“内部讲师”。还有个说法，叫“涟漪型培训”，关键用户-种子用户-终端用户。

若是大型系统的培训，往往分模块、多轮进行，可包括项目管理培训、项目小组关键用户培训及最终用户培训。其中项目管理培训和项目小组专精培训将由顾问负责，最终用户培训用“Train-the-trainer”的培训方式，即由“内部讲师”负责。

测试脚本，包括测试数据（注明测试时要填写的数据，否则可能信息传输失败或校验报错）、测试脚本、测试通过报文或截图、测试失败报文或截图。测试脚本提供需测试的场景、功能路径、功能描述、测试步骤、操作描述、期望结果。 

问题清单，包括：模块、问题属性、等级、描述、提出人、提出日期、状态、处理方法、实现方式、实际完成时间、处理人。问题属性包括功能问题、需求问题、数据问题、操作问题、样式问题。

收集测试问题时，应按照部门或模块指定唯一负责人对接。既可以把控问题/需求提出的严谨性，确保业务是有认真思考后提出的。也可以平衡部门内部的分歧点，消除内部需求不一致性。

测试问题的关键，是对于优先级的定义。高优先级为影响业务流程，必须在上线前解决。中、低优先级则允许上线后迭代优化，只要承诺解决即可。而判定哪些为高优先级，则需要业务方、项目组及顾问共同讨论。有的高优先级问题，评估结果是目前无法实现，或需要变通方案，或需要一定时间解决，需达成一致。这也是Go/No-go meeting的决策依据。

需与业务、顾问提前确定某些假设条件，如以下情况，测试仍会被认为是成功的：应用程序功能完备，但个别使用者感到不习惯；测试中出现的问题不是业务蓝图的范围，而是业务蓝图签字确认后提出的对蓝图方案范围有实质变更的新建议或新要求。

根据问题解决情况，安排回归测试。

测试报告，包括测试安排、测试结果统计及结果分析，说明缺陷修复率、影响流程的高优先级问题解决情况及业务签字验收情况。给出结论，系统是否具备上线条件。

测试阶段需注意培训手册的编写。一般由业务用户输出，但质量较差，达不到要求。上线后，业务表示看不懂操作手册，碰到任何问题直接找IT，最后还得由系统管理员逐渐完善操作手册。因此测试阶段，要求由乙方提供通用版操作手册，业务审核通过后，在测试阶段开始补充，输出适合本公司业务现状的、按岗位区分的操作手册。

测试常碰到的问题，一是测试不够充分，业务用户参与意愿不强，测试进度慢，测试不深入，仅按照最短路径原则完成主干流程的操作。这属于正常现象，人对于测试有种天生的厌烦感，认为是不增值的苦差事，而不是觉得是为了减少上线实际使用的不便，仿佛现在测试的系统不是以后与他的日常工作紧密关联的工具。针对这个问题，需提前获得领导的支持（这个不难，都到测试阶段了，而且需要的资源不是很多），布置测试作业，交代要完成的测试任务及时间点。同时顾问与关键用户需现场配合指导；二是发现关键问题后就认为ok了，等待回归测试，或二次测试时再做后续测试。需在测试安排中说明清楚，测试截止日期。

1. UAT的重点在于：

   1. 测试和确认系统是否与业务方案相符；

   2. 以预设的测试场景案例测试系统问题；

   3. 以自己的实际应用场景测试系统功能；

   4. 测试端到端按角色的业务场景；

   5. 验证系统中集成点的数据准确性

2. 而要避免做成了：

   1. 与项目组沟通理解业务方案不明确的地方；

   2. 培训业务同事使用系统；

   3. 要求对现有业务方案的澄清；

   4. 提出对现有业务方案变更的新需求；

   5. 提出未有在业务方案的新功能要求