軟體測試的過程管理

一.軟體測試的各個過程（PDCA）

1.測試需求的分析和確定  2.測試計劃  3.測試設計  4.測試執行 5.測試記錄和缺陷跟蹤 6.迴歸測試 7.測試總結和報告

二.測試需求

1.需求規格說明書的檢查要點

      正確性：對照原始需求檢查需求規格說明書

      必要性：不能回溯到出處的需求項可能是多多餘的

      優先順序：恰當劃分並標識

      明確性：不使用含糊的詞彙

      可測性：每項需求都是必須可驗證的

      完整性：不能遺漏必要和必須的資訊

      一致性：與原始需求一致、內部前後一致

      可修改性：良好的組織結構使需求易於修改

三.需求文件的檢查步驟

    （1）獲取最新版本的軟體需求規格說明書，同時儘量取得使用者原始需求文件

    （2) 閱讀和嘗試理解需求規格說明書中描述的所有需求項

    （3）對照需求規格說明書檢查列表進行檢查並記錄

    （4）針對檢查結果進行討論、修訂需求規格說明書後回到第一步，直到檢查列表中的所有項通過

舉例：

1. 是否覆蓋了使用者提出的所有需求項

2.用詞是否清晰，語義是否存在有歧義的地方

3.  是否清晰地描述了軟體系統需要做描述及不做什麼

4.是否描述了軟體使用的目標環境，包括軟硬體環境

5.是否對需求項進行了合理的編號

6.需求項是否前後一致、彼此不衝突

7.是否清楚說明了系統的每個輸入、輸出的格式，以及輸入輸出之間的對應關係

8.是否清晰描述了軟體系統的效能要求

9.需求的優先順序是否合理分配

10.是否描述了各種約束條件

四、通過編寫測試用例來檢查需求

測試人員通過構建並嘗試回答設計的黑盒測試主要是為了測試需求的完備性，準確性，明確性以及簡明性等需求問題。

五、測試的計劃

  1.確定測試範圍 

  2.制定測試策略： （1）測試戰略：測試的先後次序，測試的優先順序，測試的覆蓋方法、迴歸測試的原則等。

                          （2)  測試戰術：採用的技術、架構、協議等。

   3.安排好測試資源：通過充分估計測試的難度，測試的時間、工作量等因素，決定測試資源的合理利用。

    4.安排好進度：測試的進度需要就結合專案的開發計劃。產品的整體計劃進行安排，還有考慮測試本身的各項活動進行安排。

     5.計劃風險：對測試過程可能碰到的風險進行估計，制定出相應的應對策略。

六、測試的設計及測試用例

    1.基於需求的測試方法

  RBT是基於需求的測試方法，會使得測試更加有效，因為他使測試專注於質量問題產生的根源。

  基於需求的測試時一種最根本的軟體測試，重點關注以下兩大關鍵問題

  （1）驗證需求是否正確、完整、無二義性，並且邏輯一致

  （2) 要從‘黑盒‘的角度，設計出充分並且必要的測試集，以保證設計和程式碼都能完全符合需求。

      2.等價類劃分法

        等價類是指某個輸入域的集合，在這個集合中每個輸入條件都是等效的。

        等價類劃分法人為，如果使用等價類中的一個條件作為測試資料進行測試不能發現程式的缺陷，那麼使用等價類中的其他條件進行測試也不能發現錯誤。

        等價類是典型的黑盒測試方法，不需要考慮程式的內部結構，只需要考慮程式的輸入規格即可。

       分類兩大等價類  ：1.有效等價類：滿足條件的，2.無效等價類：不滿足條件的

        等價類分法雖然簡單易用，但是沒有對組合情況進行充分的考慮，需要結合其他測試用例設計的方法進行補充。

       3.邊界值分析法

        假設大多數的錯誤發生在各種輸入條件的邊界上，如果在邊界附近的取值不會導致錯誤，那麼其他取值導致出錯的可能性也很小。

        邊界值分析法的優點是簡單易用，只需要考慮單個輸入的邊界附近的值，並且這種方法在很多時候是非常有效的揭露錯誤的方法。但是他們跟等價類劃分的方法一樣沒有考慮輸入直接的組合情況，因此需要進一步結合其他測試用例設計方法。

    4.等價值+邊界值

    通常結合等價類劃分和邊界值分析法，對軟體的相關輸入域進行分析，常見的分析域包括整數，實數，字串和字元，日期，時間，貨幣等。

    5.基本路徑分析法

      基本路徑分析法一般使用在白盒測試中，用於覆蓋程式分支路徑，但是在一些黑盒測試中也能使用。

      基本路徑分析法的重點在於覆蓋流程，確保讓程式體現所有可能的邏輯。但是這種方法也存在一定的缺點，就是基本路徑分析法只覆蓋一次流程，對於一些存在迴圈的流程沒有考慮。因此還需結合其他的測試用例設計方法進行考慮。例如錯誤猜測法，場景分析法。

    6.因果圖法

         因果圖是一種簡化了的邏輯圖，能直觀地表明程式輸入的條件和輸出的動作之間的相互關係。因果圖法是藉助圖形來設計測試用例的一種系統方法，特別適用於被測試程式具有多種輸入條件、程式的輸出又依賴於輸入條件的各種情況。

         因果圖法設計測試用例步驟

         1、分析所有可能的輸入和可能的輸出

         2、找出輸入與輸出之間的對應關係

         3、畫出因果圖。

         4、把因果圖轉化成判定表

        5、把判定表對應到每一個測試用例

       通過畫因果圖能更加清楚輸入條件之間的邏輯關係，以及輸入與輸出之間的關係。缺點需要畫圖和轉換成判定表，對於比較複雜的額輸入和輸出會需要花費大量的時間。

    7.場景設計法

        現在的軟體大部分是由事件觸發控制流程的，事件觸發時的情景就是所謂的場景。在測試用例設計過程中，通過描述事件觸發時的情景，可以有效激發測試人員的設計思維，同時對測試用例的理解和執行也有很大的幫助。

        場景設計法需要測試人員充分發揮對使用者實際業務場景的想象。

    8、錯誤猜測法

        錯誤猜測法用過基於經驗和直覺推測程式中可能發生的各種錯誤，有針對性地設計測試用例。因為測試本質上並不是一門非常嚴謹的學科，測試人員的經驗和直覺能對這種不嚴謹性作出很好的補充。

最重要的是思考和分析測試物件的各個方面，多參考以前發現Bug的相關資料、總結的經驗，個人多考慮異常的情況，反面的情況。特殊的輸入，以一個攻擊者的態度物件程式。

   9.正交表

         正交表法是一種有效減少測試用例個數的設計方法。

         正交表設計測試用例的步驟

       （1）確定有哪些因素。例如，姓名，性別，狀態，三個因素

         (2) 每個因素有哪幾個水平。水平是指輸入條件的引數，例如上面姓名就有填寫與不填寫兩個水平

       （3) 選擇一個合適的正交表

 舉例：即假設有姓名，性別，狀態 三個因素， 每個因素分別都有兩個水平分別為 填，不填，男，女，啟用，未啟用

即可以使用正交表L4（2^3） 4表示需要執行四個用例，3表示因素數，2表示水平數

這個正交表如下  0表示一種水平  1表示另外一種水平   

  0 0 0     ： 第一條用例：填  男  啟用

  0 1 1      ：第二條   ：  填  女 不啟用

  1 0 1      ： 第三條 ： 不填   男  不啟用

  1 1 0      :  第四條  :   不填   女  啟用

如果不用正交表 那麼則需要執行8條，就不一一寫了

應用正交表進行測試的難點是查詢合適的正交表。

地址：http://support.sas.com/techsup/technote/ts723_Designs.txt

10、利用均勻實驗法設計測試用例

    利用均勻實驗法設計測試用例與利用正交表法類似，同樣需要經過分析輸入條件和引數、選擇合適的均勻表、影射因素和水平，轉換成測試用例等幾個步驟。

11.組合覆蓋與PICT的使用

      組合覆蓋法是另外一種有效減少測試用例個數的測試用例設計方法。根據覆蓋程度不同，可分為單因素覆蓋，成對組合覆蓋，三三組合覆蓋。成對組合覆蓋最常用。

       成對組合覆蓋要求任意兩個因素（輸入條件）的所有水平組合至少要被覆蓋一次。

        PICT就是實現了組合覆蓋的演算法。

        PICT的使用：

        PICT接收一個純文字，然後輸出測試用例集合

        格式如下

        NAME :  VALUE1, VALUE2,VALUE3....

       通過PICT > PICT "text.txt"  > "output.txt' 即可倒出測試用例

12.分類樹和TESTONA的使用

         通過分類樹把測試物件的整個輸入域分割成獨立的類。

         使用分類樹方法，對於測試人員來說最重要的資訊來源是測試物件的功能規格說明

         它把測試用例設計轉變成一個組合若干結構化和系統化的測試物件組成部分的過程-使其容易把握，理解，也易於文件化。

    步驟：

          1、識別出測試物件並分析輸入空間

          2、對測試物件的輸入空間進行分類

          3、畫出分類樹，組合成測試用例

          分類樹設計測試用例的核心思想就是分類樹的構建，而TESTONA就是一個設計分類樹的工具。

13.測試用例的粒度

    （1）測試用例寫的過於複雜或詳細，會帶來兩個問題，一個是效率問題，另一個是維護成本問題

    （2）測試用例寫的過於簡單，則可能失去測試用例的意義。

七、測試的執行

      需求的分析和檢查、測試的計劃、測試用例的準備，都是為了執行測試準備的。

       1、測試用例的合理選擇

           （1）對於第一次執行的測試，一個基本的測試用例選擇策略是：先執行基本的測試用例，在執行復雜的測試用例；先執行優先順序高的測試用例，再執行優先順序低的測試用例。

            （2）對於迴歸測試的測試用例選擇複雜一點。

      2、測試的分工與資源利用

            測試的分工能避免測試人員的思維侷限性，同一個用例不同人來執行，可能會發現不同的問題。

       3.  測試環境的搭建

            （1）徐璈使用大量資料，如容量測試，壓力測試

            （2）外部硬體裝置

            （3）多種作業系統

            （4）部署多臺機器

            （5）網路裝置、網路環境配置

      4.BVT測試與冒煙測試

        BVT測試，也叫編譯檢查測試，主要檢查原始碼是否能正確編譯成一個新的、完整可用的版本。如果BVT測試不通過，則測試人員不能拿到新的版本進行測試。

        冒煙測試，就是在一個編譯版本出來後，先執行他的最基本的功能，如果醉簡單的執行都有錯誤，那麼測試人員就沒有必要進行下一步的深入測試。冒煙測試的測試用例應該是隨著開發的深入而不斷演進的。

        BVT測試和冒煙測試的目的是檢查程式是否完整，是否實現了最基本的可測試性要求。能減少測試人員不必要的工作量。BVT測試和冒煙測試時所用正式測試執行之前的第一個步驟。

八、測試的記錄和跟蹤

    1.Bug質量衡量：作為一個測試人員，一定要把Bug描述清晰。

    2.錄入一個合格的bug報告一定要包括以下內容  

             1.發現問題的版本：有助於開發人員分析和總結問題出現的集中程度

             2.問題出現的環境 ：作業系統環境，軟體配置環境等等

             3. 問題重現步驟 ：儘量把操作步驟縮減到必須要執行才能重新錯誤的幾個步驟

             4.預期行為的描述 ：有預期才有錯誤

             5.錯誤行為的描述  

    3.Bug報告注意的問題

             1、不要有錯別字  2、不要把幾個Bug錄入同一個問題區域中 3.附加必要的截圖和檔案

    4.跟蹤一個Bug的生命週期

                New: 新發現的Bug，未經評審決定是否指派給開發人員進行修改

                Open：確認是bug，並且認為需要進行修改，指派給相應的開發人員

                Fixed:開發人員進行修改後標識成修改狀態，有待測試人員的迴歸測試驗證

                Rejected：認為不是Bug拒絕修改

                Delay：暫時不能（不需要）修改，延後修改

                Closed，迴歸驗證通過，Bug關閉

                Reopen：經驗證Bug依舊存在，重新開啟。

迴歸測試

 重複執行相同的測試很多遍

基於風險的迴歸測試

本質是評估系統不同部分蘊含的風險，並專注於測試那些最高風險的地方。這個地方可能讓習慣的某些部分缺乏充分的測試，甚至完全不測，但是他保證了這樣的風險是最低的。

九、測試總結和報告

1 。缺陷分類報告 可分為

       缺陷型別分佈報告 ：缺陷的型別分佈情況，一般用餅圖柱狀圖。

       缺陷區域分佈報告 ：不同功能模組出現的情況，餅圖，柱狀圖

       缺陷狀態分佈報告：描述缺陷中各種狀態的比例情況，例如open eixed closed分別佔了百分之多少

2.缺陷趨勢報告

       主要描述一段時間內的缺陷情況

3.經典缺陷與bug模式

     對缺陷進行總結歸納

    經典缺陷滿足條件：重複出現，經常出現 ，能代表某種型別的錯誤 能通過相對固定的測試方法或手段來發現這些錯誤。

    提煉Bug模式

       （1）分析缺陷報告，找出經常出現的bug型別

        (2）分析bug的根源，找到Bug產生的深層次原因

      （3）分析找到Bug的方法，總結如何才能每次都發現這種型別的Bug

狀態遷移圖

一個功能的狀態比較多的情況下使用

步驟

1.畫出狀態遷移圖

2.列出狀態 -事件表

3.得到狀態轉換樹

4.推出測試路徑

5.根據測試路徑寫測試用例