自己所在的测试团队开展UAT测试业务。以前从事的测试项目几乎没有碰到这种情况，所以，在这个小组的最初的测试流程设计，测试执行监控，测试案例评审，测试状态报告等很多方面都碰到了问题。

　　经过几个月的不断总结和改进，终于摸索出了一套比较有效的管理流程和方案，总结如下：

　　第一阶段

　　交付产品特点：第三方产品开始按照版本方式交付，而且每次交付的版本功能改动比较大，问题级别高，影响广泛

　　测试组情况：此时测试组织仍然按照老的测试流程管理，把所有相关的问题交付给同时承担正常业务需求的人员进行测试，流程也按照正常每月上线流程进行。

　　造成的矛盾：测试人员承担双重的测试任务；正常需求的时间点与第三方软件版本上线时间点不一致，更加剧了测试人员的压力；针对第三方软件进行的UAT测试由于本身特点，正常按月上线的需求测试流程不适于新的测试。

　　出现的问题：

　　测试不能按时完成，测试质量不能保证，测试人员怨声载道。

　　改进措施：

　　1、成立新的小组，承担第三方软件的测试

　　2、根据新产品按版本交付的特点，建立新的测试流程。

　　第二阶段

　　交付产品特点：第三方产品的版本交付时间经常延迟，或者经常出现紧急交付，给UAT测试组造成很大冲击。

　　测试组情况：虽然成立了专门的UAT测试组，但是测试人员大部分是新入职人员，对系统的理解较差，造成测试案例质量不高，测试执行力不强，测试监控力度和强度比较弱，加之第三方公司紧急交付情况频繁发生。

　　造成的矛盾：测试新人压力很大，对上下游的抱怨增强

　　出现的问题：

　　测试不能按时完成，问题发现不及时，最后发现重大问题情况屡屡发生，这种现象更加剧了紧急交付的现象。对客户和第三方都造成了不良影响。

　　改进措施：

　　1、与第三方公司协商版本交付时间点，以及变化冻结时间点，确保版本稳定。

　　2、在测试内部加强测试人员系统知识培训和学习

　　3、完善测试流程，增加案例评审环节，增加每日测试进度报告等监控措施

　　第三阶段

　　交付产品特点：第三方产品交付的整体版本中包含的新功能太少，很多新的、紧急的功能改造在大版本交付后才陆续交付。

　　测试组情况：对于大版本交付后一般先做一个版本接受基本功能回归测试，以保证除新功能外的基本功能正常。

　　造成的矛盾：

　　在这种交付情况下，测试组在开始做的版本回归测试结果被后续不断的新改动功能破坏，造成回归测试通过，但部署了后续紧急新功能后造成失败。

　　出现的问题：

　　后续新增改动对旧功能的破坏无法被发现，上线后给客户造成很坏影响。

　　改进措施：

　　1、严格执行与第三方协商好的版本和新功能交付时间点，紧急的变化及时升级到高层经理

　　2、进一步完善测试流程，增加所有新功能交付测试通过后的一个回归测试环节，保证回归测试通过后的版本就是最终上线版本。

　　第四阶段：

　　Everything is OK now.

版权声明：本文出自 zhengxm_16 的51Testing软件测试博客：http://www.51testing.com/?80374

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。