用戶接受測試需求

用戶接受測試需求    軟件測試

一、怎樣確定用戶接受測試的測試需求

一般情況下，用戶接受測試的測試需求包含四大類：

（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.kjueaiud.com