转帖：产品之需求测试

樱花季节

产品之需求测试
buer 发表于：2010-10-19 浏览：390次 评论：1次 所属分类： 功能测试
在需求分析过程中，测试人员的职责是对需求分析中产生的各种文档进行评审，确定其质量达到要求（尽量减少错误），提出修改意见，为今后的跟踪和测试打下基础； 每次需求评审的时候，我们很多的时候都是在理解我们在做什么，而非系统的进行需求的评审；在前期，设计的时候，我们需要从哪些角度测试prd中的需求是否正确： 1、首先检查所有的文档，包括原型等相关资料是否齐全，一般来说，不全的前期资料会带来一定需求分析的偏差，即使某些模块，大家都很熟悉，缺失的内容可能会让我们测试在一定程度上忽略或者放低重视程度该模块的内容； 2、项目范围描述是否清楚： 很多时候，我们都直接无视背景资料之类的内容；却不知，背景资料之类的内容是我们最近距离的接近我们的用户，甚至对于我们测试同学来讲，可能是唯一的机会去接近我们的用户；作为生产链的最后一个环节，我们跟最前面的使用者，其实是脱节的；如何把握住这点，从有限的资料中挖掘出更多的用户信息，是很有必要的； 因此，作为一个项目的大方向，一个基准线，我们的PD也需要很好的关注这点内容，我们做的东西有没有用，比我们做的东西怎么实现其实跟加值得关注！ 3、关注需求的粒度 　　可能，我们讲解我们的系统的时候，两句话就能够讲完主流程，更多的时间我们都是在关注于我们的分支流程，我们的一些细节的小功能方面，我们在测试的时候首要关注的是项目的主流程。我们在需求评审的时侯，很容易，评着评着就纠结到某个细节里面出不来了。 是以，需求测试的时候，首先要关注的是主流程是否可行，再此大前提之下，我们可以去讨论其余的分支流程，细节问题； 4、可配置的粒度 　　我们以前有个PD，喜欢将所有的属性都设置成可配置的，甚至是查询条件都是可以随机配置的，导致我们大家对他的需求都非常痛恨；但是从另外一个角度来讲，如果什么都是不可配置的，什么都是写死在程序中的；那么，很显然，可重用性就会带来一定的影响，甚至很可能介入一个系统就要开发一个接口，一个可重用的，可配置的接口又是很必要的； 因此，把握住可配置的粒度，是PD、开发和测试共同的目标； 5、每个人都是PD 看完需求的背景之后，我们会对自己需要做的东西有一个初步的轮廓，把自己当成一个PD，如果你是PD，你将如何实现这部分的内容；然后再结合已经有的原型之类的去比较两者之间的差异，如果你看过了PRD和原型之后，你的思维会被定视在别人给你设定好的路上；换一个视角，把自己放在一个更高的起点上去观察你需要做的工作；很多后期的修改都是因为前期设计不够；

liulisuo

很好，学习了~