测试承接的版本测试任务中，无非就是如下的任务类型：

　　1、新增功能验证

　　2、合入故障单验证

　　3、测试文档的编写

　　4、测试支持（现场问题协查验证，技术问题答复等）

　　我们先来谈谈新增功能验证，如何叫可以发布了。

　　场景：测试人员负责一个新增功能XXX

　　本功能的测试安排建议：

　　1、测试跟踪阶段：

　　测试人员接受新增功能的测试设计任务；

　　测试人员参与产品需求的跟踪和评审，提交同行评审单，尤其是对于功能应用的场景，用户真正的需求（用户需求）深刻理解；

　　SE负责将用户需求转化为产品需求，测试人员作为用户，有责任追述到用户需求（因为对于SE也会犯错），测试人员代表用户来检查产品需求的正确性。

　　说明：测试人员一定要敢于质疑SE的产品需求和方案中的瑕疵和缺陷。

　　因为你是用户，你是用户的代表，你是代表用户来审视这个用户需求的转化物(产品需求）。

　　2、测试设计阶段：

　　测试方案的编写：关键是测试点的完整，保证测试场景的完毕。 我们有打分表来评价测试方案。

　　测试用例的编写：关键是确保测试点转化为可以执行的测试用例。 我们有打分表来评价测试用例。

　　什么样的用例是好的用例：无论何人，何时，何地执行此用例的结果是唯一的。 通过这个用例执行后的产品质量是恒定的。

　　什么样的用例是不好的用例：预置条件不清晰，可执行性差，不同的人执行结果不唯一。

　　说明：测试设计阶段，如果发现需求和方案的错误，需要提交CQ文档单。

　　版本到了测试部后，如果发现需求和方案导致的软件错误，需要提交代码单，拆出文档单。

　　3、测试执行阶段：

　　测试准备阶段：在版本到达测试部之前需要把自己的新增功能的测试计划做好，把需要准备的外部网元准备好。

　　强调一个概念，版本到达测试的时间，应该是测试开始时间，而不是测试准备时间，测试准备要提前做。

　　比如你计划去旅行，10月5号的车票；你肯定会在10月4号晚上之前把行囊准备好。

　　举例，如果你的功能需要配合网元的新版本配合，需要提前跟测试经理提出并准备好，在版本到达测试部前应该准备好配合网元的新版本。

　　而不是等测试开始后，才搭建所需的配合网元版本。

　　测试初期： 一般是第一轮测试的前七天。

　　测试目标是：尽可能的提前发现新增功能的重大故障。 所有要做的事情都是从最可能发现故障的角度入手。

　　比如：1）大容量的数据必须提前配置好，无论是后台网管的边界值测试还是业务的配合，都是最有可能发现故障的。

　　2）新增功能涉及到的性能影响，需要尽可能的安排在前面七天进行测试，这样发现故障后开发有更长的时间来修改。

　　3）常见业务场景的遍历。

　　推荐工作方法：测试初期以功能点检查为主，测试用例的选择应该是有侧重点的，先铺开面，而不是平铺直叙遍历测试用例（这个是测试中期来做）。

　　测试前应该看看开发过程，尤其是集成测试过程，会有很大的收获。

　　测试中期： 是测试用例的完整多轮覆盖的过程。 主要是第一轮的第七天开始直到临近版本发布。略。

　　测试末期： 一般是最后一轮测试末期。

　　功能发布前要询问自己如下的问题：

　　1）我该做的有没有做完，这个就是测试点的完整性。不管你受到了多大的影响（开发定位问题），你要时刻清醒的知道我该做的有没有做完。

　　2）我使用的测试环境和用户到时候真正使用的环境有何不同，我如何能够保证我的测试环境尽可能的和用户真正环境相同。

　　   比如，我的这个功能是印尼使用，那么我有没有交叉印尼常用的功能； 印尼的常见组网环境如何？

　　3）我确实没有能力做到的部分（场景，工具限制）对于版本发布的影响风险。并及时反馈给测试经理和测试总工。

　　4）我发现的故障单，有没有得到解决，剩余的遗留故障对于版本发布的影响承担，也要及时反馈给测试经理和测试总工。

　　   这个要强调一下，测试人员不是以提交故障单作为结束的。

　　   注意：不要提单就不管了，爱什么时候解决什么时候解决，爱什么版本解决什么版本解决，而是要跟踪到故障单的解决为结束的。

　　5 ）我的功能如果要商用开通，升级有什么影响，需要做什么操作，工程实施如何进行。反馈给升级团队。

　　总结：

　　提前介入需求和方案，质疑一切；

　　版本到达测试部前做好测试准备，以终为始；

　　测试目标是提前发现重大故障，越早越好；

　　测试完毕可以拍胸脯说这功能O了，信心百倍。

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

本文出自gracehjd的51Testing软件测试博客：http://www.51testing.com/?92844