需求分析阶段软件测试,关于需求分析和测试分析阶段的一些想法

项目终于结束了，这次经历的项目规模应该是来这里之后的最大型的项目。又经历了一次项目之后的感想，下面针对需求分析阶段(RPD)和测试分析阶段来分别进行总结：

项目类型：大型重构型项目。大部分是老大业务规则，小部分的新业务需求(这部分内容是少不了的)

PRD阶段：

先说说本次prd的缺点在于：新老逻辑区分不清晰，需求描述跳跃性很大，需求没有完整的描述，没有做好后续的跟踪，没有更新。我希望的prd文档：

1、prd的结构要清晰。(文档的目录结构中提现)

曾经看过一篇文章中有说到，系统功能是将人工操作过程搬到软件系统来实现，那么任何的人工操作肯定都会有一条主流。那prd文档里需要体现这条主流，让人家一看就很清晰

2、prd仅包含本次需要实现的内容

我们这个项目是改造型项目，很多老的规则不变。有些老的规则会有所变动，也会有新增加的功能。只要本次系统需要实现的都需要罗列出来，而本次系统要改造掉的东西那么只需要说本次需要改造成什么样子即可，而无需将老的逻辑再描述一遍，会给看的人产生误导和干扰，如果真的要去了解原来老的逻辑，到时候可以自己再去老系统里面去看。

3、prd要有业务流图和实际业务说明

这个点，本次的prd里是有做到的。业务流图可以主流，也可以是主流上某个节点的细化流程图。并且配合文字说明，将流程图和实际业务背景结合在一起做个说明。

4、PRD的粒度问题

测试用例有粒度的问题，prd同样应该有粒度问题。我觉得我们以前的prd文档肯定是粗粒度的，所以我们才有了测试分析这么一个角色，去分解这些粗粒度的需求。但是实际上prd应该是细粒度的。但是越细pd花费的时间越多，那针对有些项目，前期时间比较短，那么需要明确prd的一个粒度问题。prd要细到什么样的程度，也是作为prd评审的依据之一

5、prd的迭代问题

开发过程有迭代，prd同样需要迭代的过程。prd文档并不是prd评审通过之后就没事了的，我们不能要求prd文档覆盖的需求点是100%的，我们也允许后面的需求增删改，但是每一次的变动，都需要实时更新prd文档，并且及时通知到整个项目组。开发过程中，有的时候是业务方有需求要增加，有的时候因为开发设计的问题也会影响到需求变更，所有的这些pd都要及时做好跟踪。

测试分析阶段

1、测分的介入时间：

测分的介入时间应该和系分是一样的。越早越好，越早介入对于需求分析和理解都是很好的保住，对于比较复杂的需求在前期就可以使得PA，测分和系分的理解保持一致。

2、测分到底做什么事情？

理想中的测试分析阶段应该是制定测试计划和测试用例编写阶段了。但是目前现状，我们的测试分析需要做的事情是需求分析的一个补充。把所有的点都分析到位。不要去看系分是如何实现的，测分阶段就是要把所有需要实现的测试需求点罗列出来。

3、测试计划的制定

假设主体业务流程分以下几级1->2->3->4  ，那么在每一级估算的计划执行时间应该是数据准备时间+用例执行时间+buffer时间。

1)数据准备时间：1级1小时，2级2小时，3级3小时，4级4小时(举例类推)。用例个数×每一级的数据准备时间。

2)用例执行时间：用例估算个数×平均用例执行时间。

3)buffer时间：这个时间是无法提前预计到的一切情况而预留的时间。比如bug修复时间，沟通的时间，会议时间等等。

注：大型项目在测分阶段无法完成所有的用例，所以在这个阶段制定测试计划不可能是精确的。我们只能尽量准确的去估算。

测试计划分：项目测试计划(大型项目，这个计划是细化到某个阶段的)；第一轮测试执行计划(在阶段内每个人细化到天的)；第二轮测试执行计划；集成测试计划。每个阶段都要有相应的测试计划，而且随着需求的变更，设计的变更，测试计划也要及时跟着调整。

本文出自shaofei19820625的51Testing软件测试博客：http://www.51testing.com/?74714版权声明：原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。