软件测试如何进行需求分析
需求的分类业务需求：反应了客户对系统，产品的高层次的目标要求，在项目视图和范围文档中予以说明。功能需求：定义了开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足了业务需求。用户需求：文档描述了用户使用产品必须要完成的任务，在用户说明书明确体现。eg： 业务需求：企业内部要有自己的通讯簿，简单好用 功能需求：部门管理，联系人管理，添加，修改，删除，导入导出等等功能 用户需求：要能导入导出通讯薄；按部门结构显示企业内人员，有个人名片；可以拨出电话，发送短信，搜索联系人
进行测试需求分析的目的： 把用户需求转化为功能需求 1.对测试范围进行度量 2.对处理分支进行度量 3.对需求的业务场景进行度量 4.明确其功能点对应的输入，处理和输出 5.把隐式需求转为明确
测试活动五要素： 测试需求（what） 决定怎么测（how） 测试时间（when） 测试需求人员（who） 测试环境（where）：测试中需要的技能，工具以及相应的背景知识，测试中可能遇到的风险等等 测试需求力求详细明确，以避免测试遗漏和误解
获取需求的途径： 相关的业务培训，评审 其他相关人员沟通 与软件相关的文档 其他（如旧系统为原型）
测试需求分析 确认功能： 1.业务功能：与用户实际业务直接相关的功能或细节 2.辅助功能：辅助完成业务功能的一些功能或者是细节，eg：设置过滤条件 3.数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等 4.易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，eg：快捷键就是典型的易用性需求 5.编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，eg：只能输入数字 6.参数需求：功能的细节，在功能执行时，需要根据参数设置不同，进行不同处理的细节。 7.权限需求：功能的细节，指在功能的执行过程，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限 8.性能约束：功能的细节，执行功能时必须满足的性能需求
分析场景： 1.考虑场景的调用者：考虑每一个场景提供的服务是供哪些外部模块或者系统调用，找出所有的调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程（一般和外部有交互的业务出错概率比较大，需要重点关注） 2.考虑系统内部各个场景之间的：形成内部业务流程图，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图挖掘隐性需求：？？？
测试员经验积累： 1.常用的或规定的业务流程 2.各业务流程分支的遍历 3.明确规定不可使用的业务流程 4.没有明确规定但是应该不可以执行的业务流程 5.其他异常或者不符合规定的操作
但是现在我们的需求基本上都是按照客户的全部需求来做，感觉失去了自己独立分析需求的能力
页:
[1]
