软件测试需求分析_软件测试需求分析方法，2024年最新真的太香了

1） IEE软件工程标准词汇表( 1997年)中定义需求为:

(1)用户解决问题或达到目标所需的条件或权能( Capability )

(2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

(3)一种反映上面( 1 )或( 2 )所描述的条件或权能的文档说明。

2)      需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束软件需求的层次

1.2.2  软件需求的层次

1)      用户需求( user requirement )文档描述了用户使用产品必须要完成的任务，这在使用实例(use case )文档或方案脚本( scenario )说明中予以说明

2)       业务需求( business requirement )反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明

3)       功能需求( functional requirement )定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求

1.2.3  软件需求主要包括两个方面：需求开发和需求管理

1.2.4  需求开发可进一步分为四个阶段

1. 需求获取阶段
2. 需求分析阶段
3. 编写需求规格阶段
4. 需求验证阶段

1.2.5  不适当的需求过程可能引发风险

1. 用户不多导致产品无法被接受
2. 用户需求的增加带来过度的耗费和降低产品的质量
3. 模棱两可的需求说明可能导致时间的浪费和返工
4. 用户增加一些不必要的特性和开发人员画蛇添足( gold. plating)
5. 过分简略的需求说明以致遗漏某些关键需求
6. 忽略某类用户的需求将导致众多客户的不满
7. 不完善的需求说明使得项目计划和跟踪无法准确进行

1.3   软件需求规格说明书

1.3.1  软件需求规格说明的特点

**1)**完整性

不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD( "待确定” ) 作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项。

**2)**一致性

一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。在开发前必须解决所有需求间的不一 致部分。只有进行一番调查研究 ，才能知道某项需求是否确实正确。

**3)**可修改性

在必要时或为维护每一需求变更历史记录时,应该修订SRS.这就要求每项需求要独立标出,并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现- -次。 这样更改时易于保持一致性。 另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。

**4)**可跟踪性

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以-种结构化的，粒度好( fine -grained )的方式编写并单独标明，而不是大段大段的叙述。

1.4   软件测试需求跟踪矩阵

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数软件测试工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上软件测试开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

3083992857)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！