《軟件測試經驗與教訓》摘錄

　　　　最近拜讀了《軟件測試經驗與教訓》一書，其中給出的不少經驗和教訓都富有參考價值，摘錄了一些我的以爲比較有用的條目。與你們一塊兒分享學習。

• 迅速找出重要程序問題

        先測試通過變動的部分，後測試沒有變化的部分。

        先核心功能，後輔助功能。

        先能力，後可靠性。

        先常見狀況，後少見狀況

        先常見威脅，後罕見威脅。

        先影響大的問題，後影響小的問題。

        先最須要的部分，後沒有要求的部分。

        測試若是對產品、產品必須與之交互的軟件和硬件以及將使用軟件的人越瞭解，越有可能更快的找出重要問題。

 

• 黑盒測試

        爲了作好黑盒測試，就要了解用戶，瞭解他們的指望和需求，瞭解技術，瞭解軟件運行環境的配置，瞭解這個軟件要與之交互的其餘軟件，瞭解軟件必須管理的數據，瞭解開發過程等等。

 

• 經過會議、推到和參照發現需求

        需求文檔常常是不完整、不許確的。從如下三種途徑蒐集需求信息。

        1.會議，找出其有關質量的意見具備影響力的人，與他們交流，瞭解他們最關心什麼。

        2.推到，經過外推已知項目和產品其它信息，肯定什麼需求最重要。

        3.參照，發現顯示、隱式規格說明。

 

• 既要使用顯示規格說明，也要使用隱式規格說明

        顯示規格說明是一個有用的需求信息源，通過客戶的權威確認。隱式規格說明是沒有通過客戶權威確認的一個有用的需求信息源。

        隱式規格說明的形式：一、競爭對手的產品；二、相關產品；三、統一產品的老版本；四、項目團隊之間的電子郵件討論；五、顧客意見；六、圖形用戶界面風格指南；七、操做系統兼容性需求；八、測試本身的豐富經驗。

 

• 不要將試驗和測試混淆起來

        測試任何產品至少包含如下四種活動：一、配置，準備要測試的產品，將其置於正確的其實狀態。不然測試結果會受到不良變量的影響。二、運行，向產品輸入數據，向產品發命令，以某種方式與產品交互。三、觀察，收集有關產品行爲信息，輸出數據，系統總體狀態，與其餘產品的交互等方面的信息。四、評估，運用規則、推理或可檢測所觀察到數據中存在問題的機制。

 

• 運用試探法快速產生測試思路

        試探法是一種基於經驗作出猜想的方法。因爲可能的測試用例數量是無限的，所以要選出在所面臨的時間和預算約束條件下有小的少許測試用例。一組好的試探方法有助於很快地生成測試。採用試探法測試的一些例子：

        1.測試邊界。邊界更可能暴露規格說明的模糊問題。

        2.測試全部錯誤信息。錯誤處理代碼與主流功能代碼相比，通常比較弱。

        3.測試與程序員的配置不一樣的配置。

        4.運行比較南設置的測試。在其它條件相同的狀況下，易於設置的測試更有可能已經被執行過了。

        5.避免冗餘測試。若是某個測試其實是重複其它測試，就不會產生新價值。

 

• 若是遺漏一個問題，檢查這種遺漏是意外仍是策略的必然結果

        若是出現遺漏問題，須要思考出現問題是由於執行了好的測試策略，碰巧沒有發現這個特定問題？若是是這樣，能夠保持原有方針不變。可是若是遺漏程序錯誤是由於測試策略關注了錯的問題類型，能夠利用這個機會改進測試策略。

 

• 關注測試員、覆蓋率、潛在問題、活動和評估的組合測試手段

        測試五要素：

        1.測試員。

        2.覆蓋率。測試了那些哪些內容。

        3.潛在問題。測試的緣由。

        4.活動。如何測試。

        5.評估。怎樣斷定測試經過仍是不經過。

        測試手段不必定只涉及一種要素，也不該該這樣，全部的測試應該都要涉及五個要素。應該指望跨多個要素的更綜合的測試手段。

 

• 關注測試員的基於人員的測試手段

        以執行測試的人來區分的常見手段。

        用戶測試：將使用該產品的典型人員進行輸入測試。

        α測試：有測試小組執行的內部測試。

        β測試：利用不屬於開發機構而且是產品的目標時長成員的測試員實施的用戶測試。

        強力測試：利用祕書、程序員、時長開發人員和能夠找到的任何人所實施的內部測試。

        有關領域的專家測試：向軟件目標領域內的專家提供產品，並尋求反饋意見。

        成對測試：兩個測試員在一塊兒發現程序錯誤。

        自用測試：全公司使用並依靠本身軟件的試用版，一般要等到軟件足夠可靠可以實際使用時，纔像市場銷售。

 

• 關注測試內容的基於覆蓋率的測試手段

        功能測試：逐個測試每一個功能。

        特性或功能集成測試：一塊兒測試多個功能，以檢查功能在一塊兒執行的狀況。

        菜單瀏覽：遍歷GUI產品中全部菜單和對話框，使用每一個可用的選項。

        域測試：蒐集全部的輸入輸出變量，把其可能取值集合劃分爲等價類。以這個變量做爲輸入或輸出，測試涉及這個變量的每一個功能。

        等價類劃分：等價類是認爲等價的一組變量取值。一旦找出一個等價類，可只測試其一兩個成員。

        邊界測試：邊界值就是類的最小和最大值。在邊界測試中，要測試這些值，還要測試相鄰類的邊界值。

        最佳表明測試：等價類的最佳表明是暴露軟件中的錯誤的可能性方面至少與類中其它值同樣的值。但有時候不必定是數值，要根據具體問題選擇這個類的最佳表明。

        輸入字段測試大綱或矩陣：對於每組輸入字段，能夠開發一組至關標準的測試用例。

        用各類方式映射和測試編輯字段：能夠是手動輸入，或者拷貝或者其它等等。

        邏輯測試：試圖檢查程序中的全部邏輯關係，因果圖是一種用於設計大量基於邏輯測試的手段。

        基於狀態的測試：在基於狀態的測試中，每次都要經過通過大量狀態前移，並自洗檢查結果來檢驗程序。

        路徑測試：一條路徑包含測試員所執行的全部步驟，或程序爲了獲得正確狀態所經過的全部語句。路徑測試包括測試經過程序的不少條路徑。

        語句與分支覆蓋率：若是測試執行了程序中全部的語句，則達到了100%的語句覆蓋率。若是執行了全部語句和一個語句到另外一個語句之間的全部分支，則達到100%的語句和分支覆蓋率。設計本身的測試，達到高的語句與分支覆蓋率，

        配置覆蓋率：配置覆蓋率度量測試員已經運行的配置測試佔計劃運行的配置測試總數的百分比。

        基於規格說明的測試：這種測試關注驗證在規格說明中所作的有關產品的每一個事聲明。

        基於需求的測試：測試關注證實程序知足需求文檔中的全部需求。

        組合測試：相互組合兩個或更多便利。

 

• 關注測試緣由（基於風險測試）的基於問題的測試手段

        基於風險的測試至少有兩個主要含義。進行風險分析是爲了肯定下一步要作的測試。另外一個含義就是進行風險測試時爲了發現錯誤。

 

• 關注測試方法的基於活動的測試手段

        迴歸測試：迴歸測試涉及相同測試的重用，使得在軟件變動之後能夠從新執行。

        腳本測試：手工測試，採用由更高級的測試員編寫的測試過程步驟，通常由低級程序員執行。

        冒煙測試：這種反作用迴歸測試的目標，是證實新版本不值得測試。

        探索式測試：不斷建立並使用新測試。

        遊擊式測試：對程序快速，有力的攻擊。

        場景測試：這種測試涉及四個屬性，1.測試必須是現實的，反映客戶實際要作的事；2.測試應該是複合的，要以可以對程序構成必定挑戰的方式包含多個功能；3.應該可以容易並快速的顯示出程序是否經過測試；4.若是程序沒有經過測試，有關人員會強烈要求修改程序。

        安裝測試：以各類方式，在能夠安裝該軟件的不一樣類型系統上安裝該軟件。

        負載測試：在面臨不少資源要求的系統上運行，攻擊被測程序或系統。

        可靠性測試：測試須要持續必定的時間來暴露問題。

        性能測試：運行這些測試一般要肯定程序運行有多快，以便肯定是否須要優化。

 

• 關注測試是否經過的基於評估的測試手段

        評估手段描述肯定程序是否經過測試的方法，說明若是可以採集到必定的數據該如何評估。

 

 

• 不可重現程序錯誤是可重現的

        程序錯誤要在特定的條件下出現。若是遇到本身不能重現的程序錯誤，能夠嘗試找出條件是什麼。列舉了一些有助於思考的條件例子：1.程序錯誤可能有延遲效應；2.程序錯誤可能只是在安裝、使用產品或使用產品的特定功能時出現一次。3.程序錯誤可能依賴於特定的數據取值或被破壞了的數據庫。4.程序錯誤可能只在特定的時間點發生。5.缺陷可能依賴於特定順序執行一系列相關的任務。6.程序錯誤多是前面失效的殘餘。7.程序錯誤多是由被測應用程序與後臺運行的其餘軟件，或和與被測應用程序競爭訪問的軟件交互引發的。

 

• 有關測試策略要問的三個基本問題是」爲何擔憂？」、「誰關心」、「測試多少？」

        爲何擔憂？測試是昂貴的，除非測試策略解決足夠重要，須要花時間測試的問題，不然測試策略中不要包含活動。

        誰關心？只在測試策略中包含與他們利益有關的活動

        測試多少？到底打算實際測試多少？

 

• 實際測試計劃是指導測試過程的一套想法

 

• 所設計的測試計劃要符合本身的具體狀況

        測試計劃的目標，是所選的測試過程可以使測試控制在項目環境中，同時又能充分利用資源，完成本身的任務。給定五種資源和約束是：

        開發；產生將要測試的產品和系統。如何接收該產品？該產品的可測試性如何？

        需求；成功產品的評判準則。該產品的風險是什麼？有關質量誰的意見最重要？

        測試團隊；可以投入該產品測試的人員。有合適人選嗎？可以及時完成任務嗎？

        測試實驗室；使測試團隊可以完成測試任務的系統、工具和材料。有合適的設備嗎？程序錯誤跟蹤系統的狀態是否良好？

        任務；測試團隊必須按照客戶承認的成功標準解決的問題。快速找出重要問題?對質量作出準確評估？

 

• 利用測試計劃描述在測試策略、保障條件和工做產品上所作的選擇

        測試計劃必須描述三類選擇：

        1.策略。如何測試產品以快速找出重要問題？須要對哪些部分進行特殊測試？要運用什麼手段建立測試？當程序錯誤出現時怎樣識別？測試策略要規定測試項目與測試任務之間的關係。

        2.保障條件。如何利用資源實現測試策略？誰來測試？何時測試？要想成功須要什麼條件？

        3.工做產品。怎樣向客戶提供工做產品？如何跟蹤程序錯誤?須要編寫什麼測試文檔？須要編寫什麼報告？

 

• 測試策略要解釋測試

        好的測試策略是：

        1.與具體產品有關。

        2.關注風險。顯示測試過程當中能夠怎樣描述重要問題。

        3.多樣化。多樣化測試策略要包含各類不一樣的測試手段和方法。

        4.實用。測試策略必須能被執行。

 

• 根據產品的成熟度肯定測試策略

        項目初期，同情的測試。

        項目中期，積極地測試。

        項目末期，多樣地測試。

        項目最後，謹慎地測試。

        整體目標是隨着產品開發的進展，不斷地調整測試策略，使得產品開發整個過程當中，重要錯誤的發現率都保持比較高的水平。