《微軟的軟件測試之道》讀書筆記

《微軟的軟件測試之道》讀書筆記

第一部分  關於微軟
    第1章  微軟的軟件工程

        偏重於產品獨立發佈的模式通常稱爲PUM（Product Unit Manager）即產品部門經理模式。

    
    第2章  微軟的軟件測試工程師

        測試工程師的主要職責：制定測試計劃、設計測試用例、分析缺陷的根本原因、參與程序代碼的審查和產品設計的審查、開發測試自動化程序

        我們（微軟）在軟件測試上面臨着兩種挑戰：一是我們要培養測試工程師成爲被測試的產品領域的專家； 二是培訓他們怎樣去測試。
        
        SDET培訓路線圖
        
        測試職種的發展道路： 測試架構師(一種角色而非一個職位) 、測試獨立貢獻者

        成爲管理人員並不意味着升職(這是一個“平級”的變化)

        
    第3章  工程生命週期
        微軟的軟件工程：
               瀑布模式：  圖 3-1
               螺旋模式：  圖 3-1
               敏捷開發
               里程碑模式  圖 3-2
               圖 3-5 軟件生命週期的工作流程


第二部分  關於測試
    第4章  軟件測試用例設計的實用方法

        實踐良好的軟件設計和測試設計 --> 軟件設計包括制定計劃和解決難題

        測試設計和好的軟件設計有很多相似處，甚至可以說，和好的設計都有相似之處。測試設計需要從計劃和問題解決方面來決定做哪些測試，

以及哪種測試在驗證功能和確認錯誤路徑處理得當上是最有效的。測試設計中最重要的方面之一是能預見用戶的需要和期望，然後創建能夠恰當地

處理這些需要的測試。良好的測試設計通常從對軟件設計的審查或批評開始。通常，對待設計審查和對待代碼審查是很相似的，也就是設計者對設計

進行解釋，參與者提出問題並提供反饋。一個好的設計審查會對所有主要的設計決策中的各種備選方案做深度比較。比較的目的是要就建立什麼、

怎樣去建立、還有更重要的，如何去測試它們等方面，達成共識。良好的設計和良好的執行在成功的軟件開發工程中佔舉足輕重的地位。

        
        使用測試（設計）模式
                測試模式共享的常用形式是模板。測試設計模板包括10個屬性：名稱、問題、分析、設計、預言、用例、缺陷和侷限、相關的模式
                基於模板的測試設計方法：交流測試想法、加速測試設計進程、構建測試設計的知識庫
         
        估計測試時間 --> 測試需要多少時間?
               估計一個功能或是應用程序的測試時間的方法：拷貝開發時間。

        如果某個開發任務計劃需要一個人工作兩週，那麼估計寫自動化測試和描述手工測試用例也需要一個人工作兩週。這在實際實踐中只是一個

出發點，因爲有太多因素可以影響到測試的進程，所以在估計測試時間時應該把這些因素都考慮在內。        

        如果需求（功能規格）寫得不好或沒有，那麼最好的測試設計的出發點就是問問題。如果程序已經可以運行，那麼最好的測試設計的方法就是

運行程序。
        很多在測試過程中被錯過了的軟件缺陷都是因爲測試人員沒有問足夠多的問題或者他們沒有問對問題。問問題是測試設計階段獲得需要的

知識以進行檢查的最好的方法。

         好的測試策略：一個測試策略引導着測試設計，而且可以爲測試團隊的測試設計提供方向。

         思考可測試性：早點思考可測試性。 可測試性是指軟件可以被完全有效測試的程度。
                       測試人員可以用來提高可測試性的最普遍方法是在需求或設計評審中簡單地問，“我們怎麼來測試這個東西?”
                       一種提高軟件可測試性的簡單模式：SOCK-->簡單、可見、可控制、知識

        測試設計規格說明： 測試設計規格說明描述了測試過程中的方法和意圖，所以它就成爲整個測試過程的不可分割的一部分並貫穿整個產品的

生命週期。

         
        數據測試--用好的和壞的：測試用例一般包括驗證測試（使用期望的輸入來驗證產品功能的測試）和錯誤避免測試（使用預期之外的數據來檢驗

產品是否適當處理的測試）

         
        在測試用例設計中要考慮的其他因素：進度，資源以及質量是可以影響軟件測試的依賴屬性。

 
        黑盒測試和白盒測試： 

        黑盒測試：一種設計測試用例的方法。不需要知道任何關於應用程序內部是如何實現各種功能的知識。根據一個應用程序的用戶只關心這個應用

程序是否滿足了他們的需求，而不關心這個應用程序是如何被設計和實現的原理，黑盒測試的方法是一個有效的方法去模仿和預估用戶會如何使用這個

產品。另一方面，單純的黑盒測試方法也經常會導致過度測試一個應用程序的某些部分而對另一些部分沒有足夠的測試。

        

        白盒測試：通過對應用程序內部代碼或者用戶看不到的模式進行分析，並以此設計測試用例。單一憑藉白盒測試方法設計的測試用例一般

                          都非常詳盡，但無一例外的總是會錯過關鍵的終端用戶使用場景。

        

        解決這個設計測試用例的兩難處境就是使用灰盒測試。設計測試首先是從用戶關心的角度出發的（黑盒測試），然後再利用白盒測試方法保證
        測試用例能夠有效並全面的覆蓋被測對象。

        測試工程師需要從兩個方面進行測試：用戶角度 和 確定應用程序的正確性角度。爲了能夠有效涵蓋這兩個角度，必須考慮使用黑盒測試和

                                                                    白盒測試兩個方法。

        
        探索性測試(微軟)：探索性測試是一種手工測試方法，每一步的測試和驗證都是基於前一步的操作。
                                       結對測試 --> 探索性測試方法。

    第5章  功能測試相關技術

        功能測試的需求：探索性測試--主要關注於行爲測試。 然而探索性測試總的來說不能適應大型複雜的項目，或是任務非常關鍵的軟件。

        使用黑盒方法進行軟件行爲測試，僅能企及所有測試能夠覆蓋範圍的35%～65%之間。 從用戶界面出發進行軟件行爲測試的確很重要，
        但如果它被用作唯一或主要的測試途徑，我們就很有可能浪費時間在效果不佳的測試上，並且會漏過產品的某些重要的領域。

                        圖 5-1 演示黑盒測試有效性的文氏圖

        三角形測試： 大多數測試工程師只寫了一個針對合法整型值導致非法三角形的測試、一個針對等邊三角形的測試、一個針對不規則三角形的

                              測試、一個針對等腰三角形的測試。這四個測試僅僅覆蓋了軟件中最關鍵路徑的50%而已。
        
        等價類劃分
                等價類劃分，簡單地說就是一種工具，使得測試工程師能夠以系統化的方式評估一個功能點中每個參數的輸入和輸出變量。不過，

        要等價類劃分技術發揮出最大功效，就要求我們針對特定系統的上下文中的每個參數的變量數據實施全面的分析。所以在設計測試之前，

        有必要仔細爲每個輸入和輸出參數涉及的變量數據實施解耦和建模以將其模塑成分離的合法及非法分類子集。

        等價類測試的導出：  創建每個合法分類子集的合集，直到測試取遍合法分類的所有子集爲止； 再對非法數據子集依次評估。
        等價類劃分技術的整體效率主要依賴於測試人員的變量分解能力。(把變量數據建模爲等價類子集需要對給定上下文環境系統的認識和理解。)
                  
        變量分解：等價類劃分中最困難、且最具挑戰性的方面是把數據分解爲唯一合法和非法類子集。

        強化實踐：在每一個等價類數據集合中使用多個元素來增加覆蓋的寬度並減少錯誤功能的可能性。(一個等價類內抽取多個元素，以增加覆蓋寬度)

                      

                      把數據分解爲在合法和非法類中的離散集合的四個啓發式方法：值的範圍、變量相似組、唯一值、特殊值。
                      範圍： 在數據的鄰近集合中最小值和最大值間的任何數據點應產生相同的結果。
                          例子：假設要從1到999間輸入一個整數。合法的等價類是 >=1 和 <=999       

                                                                                      非法的等價類範圍是 <1 和 >999的整數

                      

                      組：只要元素被等價地處理，那麼元素組是允許的。

                          例子：車輛的類型決定了徵稅的類別，包括：卡車、小汽車、摩托車、房車、拖車等。屬於相同的徵稅類別，那麼這個元素組認爲

                                     是等價的。

                             
                      唯一值：在類或子集中的數據可能以不同於同一類或子集中的其他數據的方式被處理。
                          例子：數據 1月19日，2038，3:14:07在處理時間日期數據的應用中是唯一的。它應被分解爲離散的子集。
                      
                      特殊值：條件必須提供或必須不被提供。
                          例子：在SMTP協議中，字符"@"是一個特殊字符，不應該作爲E-mail名稱或域名的一部分。
            
            等價類劃分實戰 ---> 幫助你更好地理解如何把參數變量劃分爲離散的合法和非法數據子集。  
            參數子集分析
            等價類劃分測試
            等價類劃分小結

            邊界值分析---->最著名的功能性測試技術
            邊界值分析：一個全新的公式(用於基本邊界值分析的測試數量可以用4n+1來計算(或者6n+1 包括邊界最小值-1 和 最大值+1) )，n等於獨立

                                 參數的個數。結合公式，可以更好地估計所需邊界測試的數量，可提供更廣泛的測試集合。

            邊界值分析是個以介於特定邊界值上下的數據作爲研究目標的功能性技術。歷史經驗和遞歸問題的根本原因分析表明異常總是發生在獨立輸入

    輸出參數的邊界條件附近。對處在邊界條件的變量進行系統分析增加測試的有效性，提供更優的信息，增加檢測特定類缺陷的可能性。這種缺陷

    可能在早期測試周期中，源於輸入或輸出參數的線性變化。

    
    組合分析
            一個參數的輸出狀態取決於輸入參數可變狀態的各種組合。
            爲了系統地測試幾個相關參數可變狀態間的相互作用，相對其他可選策略而言，組合分析是最優方法。

    第6章  結構測試技術

        塊測試
        決策測試
        條件測試
        基礎路徑測試

    第7章  用代碼複雜度分析風險

    第8章  基於模型的測試

第三部分  測試工具和系統
    第9章  缺陷和測試用例管理

    第10章  測試自動化

    第11章  非功能測試

    第12章  其他工具

    第13章  用戶反饋系統

    第14章  測試“軟件加服務”

第四部分  關於未來
    第15章  今天解決明天的問題

    第16章  建設未來

注：
        微軟的軟件測試之道  How we test software at Microsoft    Alan Page  Ken Johnston  BJ Rollison著 機械工業出版社 2009