转 https://www.cnblogs.com/syw20170419/p/8640609.html
案例 《挖掘管理价值：企业软件项目管理实战》一2.3 需求分析过程
1、什么是测试需求分析
一般可以从三个方面去考虑：
1、功能需求--产品应该完成哪些功能，即向用户提供的功能，一般来说这个都是比较硬性的标准；
2、非功能性需求--用户可能不能明确告诉你的一些需求，比如
这块的内容并不 是说用户需要，而是说不知道需要做成什么样的，我们不能不做，做了只会对自己受益。要不然等到后期用户使用感觉这慢，那不爽，那倒霉的还是是自己；
3、限制条件--在需求分析中需要考虑一些条件约束，规则等，比如客户的约束，行业的约束，法律的约束以及自己的约束等，用户典型的操作行为有哪些？常用的功能是什么，操作时长等。
2、定义流程：确定流程是什么样子的，来分析业务，检测出核心功能首要进行测试
3、二次沟通：与需求分析师/产品经理沟通
4、细化：软件流程、区分核心、非核心模块
5、依据流程生成场景模型
6、结合场景进行测试数据设计：依据的测试手段都是合理有效的。减少不必要的时间等浪费
测试人员在阅读需求文档或看demo时，要能回签如下问题：
1、系统要实现哪些功能，这些功能的输入，输出，操作步骤是什么。
2、系统中业务流程，业务规则描述是否清楚，是否按照流程图就可以正常的执行，有没有缺少的节点。
3、系统涉及的用户有哪些，用户都具备什么样的权限。
4、系统对于非功能性的需求有哪些？这些需求描述是否完整，有明确的指标。
5、系统的运行环境描述是否完整，按照这个环境是否能搭建出测试环境。
6、用户典型的操作行为有哪些？常用的功能是什么，操作时长等。
以上这些问题的答案如果在文档或demo中无法找到答案，就需要跟项目经理进行沟通来了解这些信息。
测试需求分析的步骤
1 、 熟悉需求背景及商业目标：
a) 了解清楚项目发起的原因，是为了解决用户的什么问题。
b) 当前的解决方案是不是最优的，为什么会这样做？
2 、业务模型法：
a) 考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。
b) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。
3 、业务场景法：
a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注）
b) 考虑系统内部各个用例之间的交互，形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。
4 、功能分解法
a). 业务功能：与用户实际业务直接相关的功能 或细节。
b). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。
c). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。
d). 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。
e). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。
f). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。
g). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。
举例说明如何进行测试需求分析
先看一段关于日志文件的需求描述如下：“软件要将所有的访问者都要记录下来，对每次访问要记录访问开始时间、访问结束时间、访问者的IP地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。
在这段需求描述中，我们首先要想象自己是日志模块的开发者，根据这段需求描述，是否能够开发出日志模块来呢？日志文件要记录的信息内容上面都提到了：访问开始时间、结束时间、IP地址。乍一看好像可以根据这个需求描述进行开发。
但仔细来分析一下这段需求的话，就会发现并不是想象的那样乐观。先找出需求中涉及的三个显性元素：
1、访问者
2、访问记录
3、日志文件
首先对访问者和访问记录这两个元素进行分析，先看访问者有那些属性，除了描述中提及的访问时间和IP地址外，访问者还有那些属性呢？显然访问者 的访问内容是最重要的属性，仅记录访问时间和访问者的IP地址是否足够呢，从日志能分析出什么有用的信息呢？从时间信息上最多只能看出那段时间访问的人数 较多，得到用户的时间分布规律，但很难对用户的行为有深入的分析，只有知道访问者在访问那些内容才能得到更有价值的信息。象Web服务器软件要记录下访问 的URL信息以便知道访问者访问的内容，所以访问记录中遗漏了关于访问内容的信息。
从访问记录这个元素来分析，访问记录主要属性是记录格式，每条记录是以什么格式来记录呢？没有描述出来。有经验的开发者就知道日志记录格式是一 个很重要的问题，因为日志记录的分析一般是需要使用专门的分析软件或者写专门的分析程序来分析的。如何设计合理的记录格式来利用已有的日志分析软件来进行 分析是首要考虑的问题。
再对日志文件这个元素进行分析，先看看日志文件有那些属性，首先日志文件具有文件名，还有存放位置，文件格式，文件内容、文件创建时间、文件大小、文件权限等属性。
需求描述中提到了每天要生成一个日志文件，从文件创建时间属性来看，每天有24小时，到底从什么时候开始创建文件，从0点开始还是从几点开始，没有描述出来。
---从文件名属性来看，如何命名日志文件，需求中也没有提及。从存放位置属性来看，日志文件存放在什么地方也没有说明。是不是所有的日志文件都存放在应用程序同一子目录下？
---从文件格式属性来看，首先日志文件是以文本方式存储还是以二进制格式存储？再者，文件的内容是以何种格式记录，每条访问记录间如何分隔，是以回车换行作为分隔还是以其他字符作为分隔？都没有描述。
---从文件内容属性来分析，除了存放上述描述的内容外，是否还可以保存其他内容，如果不能保存其他内容的话，需求描述中应该加上一句”日志文件中只能存储访问记录信息，不得储存其他记录信息“。
---从文件大小属性来分析，日志文件的大小有没有限制？如果某天处于访问高峰期，访问特别多，是否需要将日志文件分拆成多个是一个需要考虑的问题。
---从文件权限属性来分析，日志文件是否机器上的所有用户都可以访问还是只有特定的用户可以访问？文件是否需要设置权限是一个需要考虑的问题。
所以在对上述需求描述进行分析后，你会发现需求描述中有很多的问题没有描述清楚。也许有人会有疑问，如果将所有上面说到的问题都描述出来的话会 不会工作量太大了？仅从需求分析的角度来讲，需求规格描述得较细的话确实会增大很多工作量，但从整个开发过程来看，需求描述完整的话，后续阶段的开发产生 歧义和遗漏的可能性就很小，实际上后续阶段节约的时间会大大超过需求所多花的时间。
测试人员在需求阶段应做哪些工作
1)首先，对于需求文档的检查主要是两个方面：
---检查需求文档描述的正确性，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人 员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符合，那么是否要确认--这里存在一个隐患，用户可能会在开发的后 期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
---检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性--我的意思是说保证需求是可以完全为测试工作服务的。
2)那么在检查完了需求之后，就可以开始设计测试用例了，在这个阶段因为没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发，而应该从业务角度出发，从实际业务出发来设计测试用例。
当然，这个阶段所设计的测试用例是不够完善的，只能涵盖某些内容，但是我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。 。
3)当项目紧时，无法写出需求文档，我们的做法就是：从网上找跟该项目相似的一些资料进行整理，需要是帮助我们理解业务，然后项目经理组织会议讨论该系统做成什么样，要实现哪些功能，测试人员要充分参与交流，将自己理解的情况表达出来，不能只是被动地去听。