基本介紹
- 中文名：軟體測試生命周期
- 測試計畫：測試計畫經常是等到開
- 系統資源：安裝SQA Suite的硬體和軟體環境
- 確定資源：人力資源
生命周期,具體步驟,測試計畫,測試設計,測試開發,測試執行,測試評估,
生命周期
過程: 測試計畫 → 測試設計 → 測試開發 → 測試執行 → 測試評估
具體步驟
測試計畫
測試計畫的問題：
1、測試計畫經常是等到開發周期後期才開始實行，使得沒有時間有效的執行計畫；
2、測試計畫的組織者可能缺乏Client/Server測試經驗；
3、測試的量度和複雜性可能太大，沒有自動化工具，很難計畫和控制。
測試策略：
測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統測試）以及每個階段內在進行的測試種類（功能測試、性能測試、壓力測試等）。
測試策略包括
1、要使用的測試技術和工具；
2、測試完成標準；
3、影響資源分配的特殊考慮例如測試與外部接口或者模擬物理損壞、安全性威脅。
測試計畫最關鍵的一步就是將軟體分解成單元，寫成測試需求。
測試需求有很多分類方法，最普通的一種就是按照商業功能分類。把軟體分解成單元元件有幾個好處：
1、測試需求是測試設計和開發測試用例的基礎，分成單元可以更好地進行設計；
2、詳細的測試需求是用來衡量測試覆蓋率的重要指標；
3、測試需求包括各種測試實際和開發以及所需資源。
怎樣估計測試工作量：
1、效率假設：即測試隊伍的工作效率。對於功能測試，這主要依賴於套用的複雜度，視窗的個數，每個視窗中的動作數目。對容量測試，主要依賴於建立測試所需數據的工作量大小。
2、測試假設：為了驗證一個測試需求所需測試動作數目。
3、套用的維數：套用的複雜度指標。例如要加入一個記錄，測試需求的維數就是這個記錄中域的數目。
4、所處測試周期的階段：有些階段主要工作都在設計，有些階段主要是測試執行。
測試資源：
1、人力資源
測試經理
為測試項目提供總體方向。開發測試計畫、徵集並監督測試人員、申請系統資源、監視並匯報工作進程、測試評估、測試需求的分解。
測試工程師 ---- 設計和開發
設計：對被測軟體的詳細了解、分解測試需求的技能、選擇在C/S環境下用來驗證測試需求的技術。
開發：熟悉SQA、VB、和腳本語言。
測試工程師 ---- 執行
負責測試執行和記錄結果。需要能夠安裝系統，網路知識，初始化資料庫和其他初始條件。重要的是診斷能力。
測試系統管理者
每個測試項目必須指定一個專人負責管理SQA Suite。包括在伺服器上安裝存儲庫，安裝印表機連線，執行備份，以及其他維護工作。管理者必須高度熟悉SQA，網路工作經驗。
2、系統資源
安裝SQA Suite的硬體和軟體環境
資料庫伺服器
該伺服器必須專用於 測試工作，能夠重置某些初始值，包括系統日期和時間等。
寫測試計畫的步驟：
1、確定工程
收集下列信息
1、測試計畫經常是等到開發周期後期才開始實行，使得沒有時間有效的執行計畫；
2、測試計畫的組織者可能缺乏Client/Server測試經驗；
3、測試的量度和複雜性可能太大，沒有自動化工具，很難計畫和控制。
測試策略：
測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統測試）以及每個階段內在進行的測試種類（功能測試、性能測試、壓力測試等）。
測試策略包括
1、要使用的測試技術和工具；
2、測試完成標準；
3、影響資源分配的特殊考慮例如測試與外部接口或者模擬物理損壞、安全性威脅。
測試計畫最關鍵的一步就是將軟體分解成單元，寫成測試需求。
測試需求有很多分類方法，最普通的一種就是按照商業功能分類。把軟體分解成單元元件有幾個好處：
1、測試需求是測試設計和開發測試用例的基礎，分成單元可以更好地進行設計；
2、詳細的測試需求是用來衡量測試覆蓋率的重要指標；
3、測試需求包括各種測試實際和開發以及所需資源。
怎樣估計測試工作量：
1、效率假設：即測試隊伍的工作效率。對於功能測試，這主要依賴於套用的複雜度，視窗的個數，每個視窗中的動作數目。對容量測試，主要依賴於建立測試所需數據的工作量大小。
2、測試假設：為了驗證一個測試需求所需測試動作數目。
3、套用的維數：套用的複雜度指標。例如要加入一個記錄，測試需求的維數就是這個記錄中域的數目。
4、所處測試周期的階段：有些階段主要工作都在設計，有些階段主要是測試執行。
測試資源：
1、人力資源
測試經理
為測試項目提供總體方向。開發測試計畫、徵集並監督測試人員、申請系統資源、監視並匯報工作進程、測試評估、測試需求的分解。
測試工程師 ---- 設計和開發
設計：對被測軟體的詳細了解、分解測試需求的技能、選擇在C/S環境下用來驗證測試需求的技術。
開發：熟悉SQA、VB、和腳本語言。
測試工程師 ---- 執行
負責測試執行和記錄結果。需要能夠安裝系統，網路知識，初始化資料庫和其他初始條件。重要的是診斷能力。
測試系統管理者
每個測試項目必須指定一個專人負責管理SQA Suite。包括在伺服器上安裝存儲庫，安裝印表機連線，執行備份，以及其他維護工作。管理者必須高度熟悉SQA，網路工作經驗。
2、系統資源
安裝SQA Suite的硬體和軟體環境
資料庫伺服器
該伺服器必須專用於 測試工作，能夠重置某些初始值，包括系統日期和時間等。
寫測試計畫的步驟：
1、確定工程
收集下列信息
文檔 | 已創建（是/否） | 版本/日期 |
需求詳述 | ||
功能詳述 | ||
項目計畫 | ||
設計詳述 | ||
原型 | ||
用戶手冊 |
定義新的工程，Adminà New Project。
確定軟體的結構，用Assetsà Software Structure選項定義軟體結構。
2、定義測試策略
確定軟體的結構，用Assetsà Software Structure選項定義軟體結構。
2、定義測試策略
測試策略項 | 例子 |
測試階段 | 系統測試 |
測試類型 | 功能測試 |
測試技術 | 75%用SQA Suite自動測試，25%手工測試 |
完成標準 | 95%測試用例通過並且最高級缺陷全部解決 |
特殊考慮 | 測試必須在上午進行 |
3、分解軟體，寫測試需求
分析各種信息
反覆檢查並理解各種信息，和用戶交流，理解他們的要求。可以按照以下步驟執行：
1、確定軟體提供的主要商業任務
2、對每個商業任務，確定完成該任務所要進行的交易。
3、確定從資料庫信息引出的計算結果。
4、對於對時間有要求的交易，確定所要的時間和條件。這些條件包括資料庫大小、機器配置、交易量、以及網路擁擠情況。
5、確定會產生重大意外的壓力測試，包括：記憶體、硬碟空間、高的交易率
6、確定套用需要處理的數據量。
7、確定需要的軟體和硬體配置。通常情況下，不可能對所有可能的配置都測試到，因此要選擇最有可能產生問題的情況進行測試，包括：最低性能的硬體、幾個有兼容性問題的軟體並存、客戶端機器通過最慢的LAN/WANF連線訪問伺服器。
8、確定其他與套用軟體沒有直接關係的商業交易。包括：
管理功能，如啟動和推出程式
配置功能，如設定印表機
操作員的愛好，如字型、顏色
套用功能，如訪問email或者顯示時間和日期。
9、確定安裝過程，包括定置從哪安裝、定製安裝、升級安裝。
10、確定沒有隱含在功能測試中的戶界面要求。大多界面都在功能測試時被測試到。還有寫沒有測到，如：操作與顯示的一致性，如使用快捷鍵等；界面遵從合理標準，如按鈕大小，標籤等。
把需求組織成層次圖
4、估計測試工作量
∑(每個測試的時間*每個需求的測試的數目*測試需求的的數目)
（測試設計、開發、….）
5、確定資源
人力資源
分析各種信息
反覆檢查並理解各種信息，和用戶交流，理解他們的要求。可以按照以下步驟執行：
1、確定軟體提供的主要商業任務
2、對每個商業任務，確定完成該任務所要進行的交易。
3、確定從資料庫信息引出的計算結果。
4、對於對時間有要求的交易，確定所要的時間和條件。這些條件包括資料庫大小、機器配置、交易量、以及網路擁擠情況。
5、確定會產生重大意外的壓力測試，包括：記憶體、硬碟空間、高的交易率
6、確定套用需要處理的數據量。
7、確定需要的軟體和硬體配置。通常情況下，不可能對所有可能的配置都測試到，因此要選擇最有可能產生問題的情況進行測試，包括：最低性能的硬體、幾個有兼容性問題的軟體並存、客戶端機器通過最慢的LAN/WANF連線訪問伺服器。
8、確定其他與套用軟體沒有直接關係的商業交易。包括：
管理功能，如啟動和推出程式
配置功能，如設定印表機
操作員的愛好，如字型、顏色
套用功能，如訪問email或者顯示時間和日期。
9、確定安裝過程，包括定置從哪安裝、定製安裝、升級安裝。
10、確定沒有隱含在功能測試中的戶界面要求。大多界面都在功能測試時被測試到。還有寫沒有測到，如：操作與顯示的一致性，如使用快捷鍵等；界面遵從合理標準，如按鈕大小，標籤等。
把需求組織成層次圖
4、估計測試工作量
∑(每個測試的時間*每個需求的測試的數目*測試需求的的數目)
（測試設計、開發、….）
5、確定資源
人力資源
職位 | 姓名 | 特殊責任/說明 |
測試經理 | ||
測試工程師 設計/開發（可以多人） | ||
測試工程師 測試執行（可以多人） | ||
測試系統管理員 |
系統資源
系統 | 名稱/類型 | |
資料庫伺服器 網路/子網 伺服器名稱 資料庫名稱 | ||
SQA 測試存儲庫 網路/子網 伺服器名稱 | ||
客戶測試機 包括專門的配置需求 | 列表 | |
測試開發的PC機 | 列表 |
6、創建工程調度表
任務 | 相關工作量（天） |
整個SQA過程 | 38 |
測試計畫 | 12 |
確定項目 | 1 |
定義測試策略 | |
決定測試需求 | |
估計工作量 | |
確定資源 | |
調度測試活動 | |
生成測試計畫文檔 | |
測試設計 | |
分析測試需求 | |
指定測試過程 | |
指定測試用例 | |
查看測試需求的覆蓋率 | |
測試開發 | |
建立測試開發環境 | |
錄製和回放原型過程 | |
開發測試過程 | |
測試和調試測試過程 | |
修改測試過程 | |
建立外部數據集合 | |
重新測試並調試測試過程 | |
測試執行 | |
設定測試系統 | |
執行測試 | |
驗證測試結果 | |
調查突髮結果（unexpected result） | |
生成缺陷日記 | |
測試評估 | |
回顧測試日記 | |
評估測試需求的覆蓋率 | |
評估缺陷 | |
決定是否達到測試完成的標準 |
7、書寫測試計畫
1、介紹
目的
背景
測試範圍
項目檔案列表
2、測試需求
3、測試策略
測試類型
1、功能測試
2、用戶界面測試
3、性能測試
4、壓力測試
5、容量測試
6、配置測試
7、安裝測試
工具
4、資源
人力資源
系統資源
5、調度
6、文檔
軟體元件
測試特性（Assets）
測試日記
缺陷報告
1、介紹
目的
背景
測試範圍
項目檔案列表
2、測試需求
3、測試策略
測試類型
1、功能測試
2、用戶界面測試
3、性能測試
4、壓力測試
5、容量測試
6、配置測試
7、安裝測試
工具
4、資源
人力資源
系統資源
5、調度
6、文檔
軟體元件
測試特性（Assets）
測試日記
缺陷報告
測試設計
測試設計的問題
1、不做測試設計，測試過程也是胡亂建立的。
2、測試設計不詳細，不是基於可量度的測試策略，例如測試計畫覆蓋一個集合或者測試需求的一個子集。
3、測試過程沒有採用最好的技術來檢驗Windows C/S結構的測試需求
測試用例的選擇規則
1、選擇與測試需求的實質部分最相關的測試用例。
2、選擇的測試用例應該不容易應用程式的改變的影響。
下面是選擇測試用例的幾點具體規則：
1、商業函式
商業函式一般與資料庫有關，要測試資料庫的變化，有幾種方法：
1、如果資料庫的的改變會反映在一個列表框中，那么就要選擇驗證列表框內容的測試用例。
2、還可以檢查交易完成後的確認對話框。可以檢查對話框的標題。圖象比較也可以檢查確認對話框，但圖象比較容易受其他因素影響。
3、修改腳本，SQA Basic提供了強大的資料庫支持。
2、域的驗證
各種不同的域選擇相應的測試用例。
3、用戶界面測試
對象狀態測試用例
4、性能標準
等待狀態測試用例
5、壓力下的操作
6、訪問控制
Object state test case
7、配置測試
不能選擇圖象測試用例（也解析度有關）和檔案測試用例（與驅動器有關）
8、安裝選項和驗證
對象狀態用例和視窗存在用例，檔案存在用例。
書寫測試設計的步驟
生成測試需求報告
↓
指定測試過程
↓
指定測試用例（可選）
↓
回顧測試覆蓋率
1、不做測試設計，測試過程也是胡亂建立的。
2、測試設計不詳細，不是基於可量度的測試策略，例如測試計畫覆蓋一個集合或者測試需求的一個子集。
3、測試過程沒有採用最好的技術來檢驗Windows C/S結構的測試需求
測試用例的選擇規則
1、選擇與測試需求的實質部分最相關的測試用例。
2、選擇的測試用例應該不容易應用程式的改變的影響。
下面是選擇測試用例的幾點具體規則：
1、商業函式
商業函式一般與資料庫有關，要測試資料庫的變化，有幾種方法：
1、如果資料庫的的改變會反映在一個列表框中，那么就要選擇驗證列表框內容的測試用例。
2、還可以檢查交易完成後的確認對話框。可以檢查對話框的標題。圖象比較也可以檢查確認對話框，但圖象比較容易受其他因素影響。
3、修改腳本，SQA Basic提供了強大的資料庫支持。
2、域的驗證
各種不同的域選擇相應的測試用例。
3、用戶界面測試
對象狀態測試用例
4、性能標準
等待狀態測試用例
5、壓力下的操作
6、訪問控制
Object state test case
7、配置測試
不能選擇圖象測試用例（也解析度有關）和檔案測試用例（與驅動器有關）
8、安裝選項和驗證
對象狀態用例和視窗存在用例，檔案存在用例。
書寫測試設計的步驟
生成測試需求報告
↓
指定測試過程
↓
指定測試用例（可選）
↓
回顧測試覆蓋率
測試開發
輸入：被測軟體、基於測試需求的測試設計
輸出：測試過程和測試用例
目標：
1、創建可以重用的測試過程和測試用例
2、維護測試過程、測試用例與相關測試需求的一一對應。
測試開發的問題：
1、測試開發很亂，與測試需求或測試策略沒有對應性
2、測試過程不可重複或不可重用
3、測試過程被作為一個編程任務來執行，導致腳本太長，不能滿足軟體移植性的要求。
錯誤處理
當測試過程發生錯誤時，有幾種解決辦法：
1、跳轉到別的測試過程
2、調用一個能夠清除錯誤的過程
3、退出過程，啟動另一個
4、退出過程和應用程式，重新啟動啟動Windows，在失敗的地方重新開始測試
測試開發的步驟
1、設立開發環境
SQA Suite
連線到SQA存儲庫
啟動SQA Baisc或VB
被測軟體
等等
2、錄製和回放原型過程
原型過程指出所有未知視窗控制，使得他們都能象標準視窗那樣動作或者沒有特別的動作，把他們都劃歸為Generic類型。通過這個過程，SQA Robot就知道該怎樣處理套用中的特殊控制。
1、把recording option 中的Define Unknown Object as Type Generic選項設定為off
2、使用的過程標識符要可以被覆蓋，或者能被刪掉。因為這只是個原型，用來教SQA Robot 錄製的過程
3、錄製測試過程和測試用例
1、錄製模組測試過程和與測試需求最低層對應的測試用例；
2、錄製初始化過程；
3、錄製導航過程，把前面的過程串起來；
4、測試和調試測試過程
5、修改測試過程（可選）
6、建立外部數據集合
如果測試過程是用來循環一套輸入和輸出數據，就需要建立數據集合。
7、重複測試和調試測試過程，回到4
輸出：測試過程和測試用例
目標：
1、創建可以重用的測試過程和測試用例
2、維護測試過程、測試用例與相關測試需求的一一對應。
測試開發的問題：
1、測試開發很亂，與測試需求或測試策略沒有對應性
2、測試過程不可重複或不可重用
3、測試過程被作為一個編程任務來執行，導致腳本太長，不能滿足軟體移植性的要求。
錯誤處理
當測試過程發生錯誤時，有幾種解決辦法：
1、跳轉到別的測試過程
2、調用一個能夠清除錯誤的過程
3、退出過程，啟動另一個
4、退出過程和應用程式，重新啟動啟動Windows，在失敗的地方重新開始測試
測試開發的步驟
1、設立開發環境
SQA Suite
連線到SQA存儲庫
啟動SQA Baisc或VB
被測軟體
等等
2、錄製和回放原型過程
原型過程指出所有未知視窗控制，使得他們都能象標準視窗那樣動作或者沒有特別的動作，把他們都劃歸為Generic類型。通過這個過程，SQA Robot就知道該怎樣處理套用中的特殊控制。
1、把recording option 中的Define Unknown Object as Type Generic選項設定為off
2、使用的過程標識符要可以被覆蓋，或者能被刪掉。因為這只是個原型，用來教SQA Robot 錄製的過程
3、錄製測試過程和測試用例
1、錄製模組測試過程和與測試需求最低層對應的測試用例；
2、錄製初始化過程；
3、錄製導航過程，把前面的過程串起來；
4、測試和調試測試過程
5、修改測試過程（可選）
6、建立外部數據集合
如果測試過程是用來循環一套輸入和輸出數據，就需要建立數據集合。
7、重複測試和調試測試過程，回到4
測試執行
測試執行的問題
1、自動化測試沒有有效的利用，使得手工測試太多。
2、測試結果的捕獲沒有系統性，而且沒有查看或調查
3、缺陷報告必須用手工加入缺陷跟蹤系統
錯誤分類
1、測試用例失敗
正常錯誤
2、腳本命令失敗
當測試過程不能執行錄製過程中的某個功能時，回產生這種錯誤，如滑鼠單擊按鈕或選擇選單項等。它也能指示是缺陷還是測試過程的設計問題。
3、致命錯誤
導致測試停止，這種情況最好重起Windows。
具體步驟：
1、建立測試系統
2、準備測試過程
3、運行初始化過程
4、執行測試
5、從終止的測試恢復
6、驗證預期結果
7、調查突髮結果
8、記錄缺陷日記
1、自動化測試沒有有效的利用，使得手工測試太多。
2、測試結果的捕獲沒有系統性，而且沒有查看或調查
3、缺陷報告必須用手工加入缺陷跟蹤系統
錯誤分類
1、測試用例失敗
正常錯誤
2、腳本命令失敗
當測試過程不能執行錄製過程中的某個功能時，回產生這種錯誤，如滑鼠單擊按鈕或選擇選單項等。它也能指示是缺陷還是測試過程的設計問題。
3、致命錯誤
導致測試停止，這種情況最好重起Windows。
具體步驟：
1、建立測試系統
2、準備測試過程
3、運行初始化過程
4、執行測試
5、從終止的測試恢復
6、驗證預期結果
7、調查突髮結果
8、記錄缺陷日記
測試評估
測試評估的目標
1、量化測試進程
2、生成缺陷和測試覆蓋率的總結報告
測試評估的問題
1、沒有把測試覆蓋率作為報告測試進程的根據，使得不知測試是否結束；
2、沒有做缺陷評估，缺陷評估是量度軟體可行性的重要指標；
3、不使用專門的軟體工具進行數據輸入任務和相應的評估活動，使得這些任務變得繁重累人。
測試覆蓋率
評估測試完成多少的標準
缺陷評估
評估軟體質量的重要指標，通常評估模型假設缺陷的發現是呈泊松分布的；嚴格的缺陷評估要考察在測試過程中發現缺陷的間隔時間長短。評估要估計軟體當前的可靠性並預測隨著測試的繼續進行，軟體可靠性會怎樣提高。
SQA Suite 提供四種形式進行缺陷評估：
1、缺陷分布報告可以生成缺陷數量與缺陷屬性的函式。如測試需求和狀態。
2、缺陷趨勢報告可以看出缺陷增長和減少的趨勢；
3、缺陷年齡報告展示一個缺陷處於某種狀態的時間長短
4、測試結果進度報告展示測試過程在被測套用的幾個版本中的執行結果以及測試周期。
具體步驟
1、回顧測試日記
2、評估測試需求的覆蓋率
3、分析缺陷
4、決定是否達到完成測試的標準，沒有滿足標準時
1、再測試
2、降低標準
3、確定軟體的一個滿足標準的子集，看是否可以發布。
1、量化測試進程
2、生成缺陷和測試覆蓋率的總結報告
測試評估的問題
1、沒有把測試覆蓋率作為報告測試進程的根據，使得不知測試是否結束；
2、沒有做缺陷評估，缺陷評估是量度軟體可行性的重要指標；
3、不使用專門的軟體工具進行數據輸入任務和相應的評估活動，使得這些任務變得繁重累人。
測試覆蓋率
評估測試完成多少的標準
缺陷評估
評估軟體質量的重要指標，通常評估模型假設缺陷的發現是呈泊松分布的；嚴格的缺陷評估要考察在測試過程中發現缺陷的間隔時間長短。評估要估計軟體當前的可靠性並預測隨著測試的繼續進行，軟體可靠性會怎樣提高。
SQA Suite 提供四種形式進行缺陷評估：
1、缺陷分布報告可以生成缺陷數量與缺陷屬性的函式。如測試需求和狀態。
2、缺陷趨勢報告可以看出缺陷增長和減少的趨勢；
3、缺陷年齡報告展示一個缺陷處於某種狀態的時間長短
4、測試結果進度報告展示測試過程在被測套用的幾個版本中的執行結果以及測試周期。
具體步驟
1、回顧測試日記
2、評估測試需求的覆蓋率
3、分析缺陷
4、決定是否達到完成測試的標準，沒有滿足標準時
1、再測試
2、降低標準
3、確定軟體的一個滿足標準的子集，看是否可以發布。
