软件测试如何进行需求分析

乐哈哈yoyo

需求的分类

  业务需求：反应了客户对系统，产品的高层次的目标要求，在项目视图和范围文档中予以说明。

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

  用户需求：文档描述了用户使用产品必须要完成的任务，在用户说明书明确体现。

  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.其他异常或者不符合规定的操作

海海豚

但是现在我们的需求基本上都是按照客户的全部需求来做，感觉失去了自己独立分析需求的能力