1) 在软件测试过程中,从需求分析开始到集成测试阶段引入测试手段,能发现所有缺陷的80%;系统测试阶段引入测试手段,能发现剩余缺陷中80%的缺陷;在运行维护阶段经过长时间、大量运行软件后,能够发现最后剩余的20%的缺陷。

1) IEE软件工程标准词汇表( 1997年)中定义需求为:
(1)用户解决问题或达到目标所需的条件或权能( Capability )
(2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面( 1 )或( 2 )所描述的条件或权能的文档说明。
2) 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性,是在开发过程中对系统的约束软件需求的层次
1) 用户需求( user requirement )文档描述了用户使用产品必须要完成的任务,这在使用实例(use case )文档或方案脚本( scenario )说明中予以说明
2) 业务需求( business requirement )反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明
3) 功能需求( functional requirement )定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求


用户不多导致产品无法被接受
用户需求的增加带来过度的耗费和降低产品的质量
模棱两可的需求说明可能导致时间的浪费和返工
用户增加一些不必要的特性和开发人员画蛇添足( gold. plating)
过分简略的需求说明以致遗漏某些关键需求
忽略某类用户的需求将导致众多客户的不满
不完善的需求说明使得项目计划和跟踪无法准确进行
1) 完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息,用TBD( "待确定” ) 作为标准标识来标明这项缺漏。在开始开发之前,必须解决需求中所有的TBD项。
2) 一致性
一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。在开发前必须解决所有需求间的不一 致部分。只有进行一番调查研究 ,才能知道某项需求是否确实正确。
3) 可修改性
在必要时或为维护每一需求变更历史记录时,应该修订SRS.这就要求每项需求要独立标出,并与别的需求区别开来,从而无二义性。每项需求只应在SRS中出现- -次。 这样更改时易于保持一致性。 另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
4) 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以-种结构化的,粒度好( fine -grained )的方式编写并单独标明,而不是大段大段的叙述。
对软件测试要解决的问题进行详细的分析,弄清楚参与软件测试活动的相关人员对软件测试活动和交付物的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么等。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!
