用户接受测试需求

用户接受测试需求    软件测试

一、怎样确定用户接受测试的测试需求

一般情况下，用户接受测试的测试需求包含四大类：

（1）业务功能类的用户测试需求
    简单解释：
            （a）以检查业务功能的正式业务要求是否被正确的实现了为目标
            （b）以检查业务功能的潜在业务要求是否被正确的实现了为目标
（2）业务流程类的用户测试需求
    简单解释：
            （a）以检查子系统间的业务联系性的业务要求是否被正确的实现了为目标
（3）业务集成类的用户测试需求
    简单解释：
            （a）以检查系统间的业务联系性的业务要求是否被正确的实现了为目标
（4）性能类的用户测试需求
    简单解释：
            （a）以检查系统的性能指标要求是否被正确的实现了为目标，包括响应时间、吞吐量/处理能力、资源利用率、交易成功率等
（5）其它非功能性的用户测试需求
    简单解释：
            （a）以检查系统的非功能性指标要求是否被正确的实现了为目标，包括安全性、可靠性、可维护性、可监控性、可扩展性等。

二、用户接受测试需求的基本属性

1）测试需求的名称
　　为了便于对测试需求进行规范管理，方便查询和统计分析，用来唯一标识一个测试需求。

（2）测试需求的编号
　　“需求编号”采用“REQ-A-B-C”四段编号，其中“REQ”代表需求，“A”代表系统名称，“B”代表模块名称，“C”代表三位的功能点顺序编号，从“001”编起。
如“REQ-CCI-外呼－001”，表示CCI系统“外呼”功能模块的第一个功能点。

（3）上级需求的编号
　　为了对某测试需求进行详细划分，请将该测试需求作层状显示。如下所示：
      需求1
          需求11
                    需求111
                ……
            需求12
                    需求121
              ……
        需求2
          需求21
                    需求211
                ……
            需求22
                    需求221
              ……
      “上级需求名称”，即为该需求的父需求名称。若为空，表示该需求为第一级需求。

（4）所属子系统名称
    例如：
 BIS：银行保险系统l
 CCBSS：证券系统l
 CCI：呼叫中心整合系统l
 CMIS：信贷管理信息系统l
 DCC：数据集中系统l
 EAIH：总行企业级应用整合平台l
 ECIF：企业级客户信息平台l
 ECTIP：企业级渠道交易整合平台l
 IPSS：综合产品服务系统l
 OCRM：操作型客户关系管理l
 UDI：数据交换池l
 SRF：Server Farm（基础实施项目组）l
 ICS：国际卡系统l

（5）评审状态
　　为了便于需求跟踪，需要设置该需求的评审状态。
      “评审状态”有“创建”、“变更”、“评审”三个状态。 [Page]

（6）重要性
　　测试需求的“重要性”用来度量该测试需求对应的“业务需求”在整个系统业务功能中的重要程度，其来源一般依据“软件需求”的重要性指标。
      “重要性”指标的取值有“核心”、“重要”、“一般”和“可选”四个值。

（7）优先级
　　测试需求的“优先级”指标用来表明测试需求实施的优先次序。
　　优先级的取值有“高”、“中”和“低”三个值。
　　优先级取值的设定由测试经理综合考虑测试需求的“重要性”、“稳定度”和“工作量”三个值来设定。

（8）稳定度
　　测试需求的“稳定度”指标用来表明该测试需求在测试实施过程中可能发生变更的可能性程度。
　　测试需求的“稳定度”指标有“高”“中”“低”三个取值。
　　影响测试需求稳定度的因素有业务需求的变更、业务需求的不正确理解等原因。
　　需求的稳定度由测试经理根据相应的业务需求的稳定度和其它因素进行设置。

（9）工作量
　　测试需求的“工作量”指标用来标明在后续的测试实施过程中，为完全覆盖该测试需求而需要的工作量。
　　该数值由测试经理根据该测试需求对应的业务需求的复杂程度及其业务流程的繁简程度进行设置。
　　该值是一个权重值，采用百分制。
　　工作量最大的为100，最小的为10，以10为增量进制。
　　需求的工作量由测试经理进行设置。
　　据此对测试人员的工作量进行量化考核。

（10）版本
　　需求版本用来记录该测试需求对应的测试版本号。

（11）创建人
        记录该测试需求的创建人。 

（12）创建日期
        记录该测试需求的创建日期。

（13）功能点描述
        “功能点描述”是对该测试需求对应的业务功能进行详细的描述。
          每个测试需求只对应一个功能点，这一点一定注意。

（14）业务规则描述
        “业务规则描述”指对与该测试需求相对应业务功能的逻辑约束的描述。
          业务规则一定要采用R1：到R9：进行编号。

三、用户接受测试的业务功能风险分析

A级
高级风险 
 B级
中级风险
 C级
低级风险 
 
功能类型 数据的计算/验证
例子：利息的计算
 数据的改变
例子：修改客户信息 
 数据的显示 
例子：显示客户信息
 
业务影响 合法性
例子：违反权限管理机制
 错误信息 
例子：普通错误
 无  
使用频度 非常频繁

例子：开户每天都有N次 经常 
例子：销户
 极少 
例子：挂失
 
受影响客户的数量 大量/非常重要
例子：取款/VIP客户
 组/群 
例子：网上缴电话费
 一些 
例子：营业员报表
 
        


×业务风险评估需要针对被测软件的所有业务功能!
×评估的标准应该在整个业务的范围内是唯一的，才能在企业范围内使不同的评估结果具有可比性!
×四个标准要应用于每一个业务功能！

使用下面的原则为每一个业务功能进行业务风险的评估：
×如果一个业务功能涉及到至少2个A或者1个A与至少两个B，那么这个业务功能的风险级别为A级（Risk Class A）
×如果一个业务功能涉及到至少两个B或者1个A与1个B，那么这个业务功能的风险级别为B级（Risk Class B）
×其他情况下，该业务功能的风险级别为C级（Risk Class C） 

原文转自：http://www.ltesting.net