1、軟件測試導論軟件測試相關概念定義、目的、對象、分類等軟件測試的定義 軟件測試（軟件測試（Software testingSoftware testing）是軟件生存期中的一）是軟件生存期中的一個重要階段，是軟件質量保證的關鍵步驟。通俗地講，個重要階段，是軟件質量保證的關鍵步驟。通俗地講，軟件測試就是在軟件投入運行前，對軟件需求分析、軟件測試就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼進行最終復審的活動。設計規格說明和編碼進行最終復審的活動。19831983年年IEEEIEEE提出的軟件工程術語中給軟件測試下的定提出的軟件工程術語中給軟件測試下的定義是：義是：“使用人工或自動的手段來

2、運行或測定某個軟使用人工或自動的手段來運行或測定某個軟件系統或系統部件的過程，其目的在于檢驗它是否滿件系統或系統部件的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差足規定的需求或弄清預期結果與實際結果之間的差別別”。軟件測試的意義v愛國者導彈防御系統 一個小的系統時鐘錯誤，導致在多哈襲擊戰中，系統被拖延100多個小時。 1991v美國航天局火星極地登陸 由于確定何時關閉推進器的程序中某一個數據位被意外修改，飛船在試圖登陸火星表面失蹤。 1999軟件測試的對象12345用戶需求用戶：我要什么？理解正確性理解正確性表達正確性表達正確性需求說明書需求分析員：我可以提供什么？

3、設計說明書設計員：我要軟件做什么？源程序程序員：我要要讓計算機怎么做？運行結果計算機：程序運行得到的結果理解正確性理解正確性設計正確性設計正確性表達正確性表達正確性理解正確性理解正確性編碼正確性編碼正確性運行正確性運行正確性輸入正確性輸入正確性相符合么？相符合么？軟件測試的目的基于不同的立場，存在著兩種完全不同的測試目的。從用戶（測試人員）的角度出發，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產品。 從軟件開發者的角度出發，則希望測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。 軟件測試的原則所有的測試都應可追溯到客

4、戶需求 窮舉測試是不可能的 嚴格執行測試計劃，排除測試的隨意性。應當對每一個測試結果做全面檢查。妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。黑盒測試基于軟件需求，而不是基于軟件內部設計和程序實現的測試方式。白盒測試基于軟件內部設計和程序實現的測試方式。單元測試主要測試軟件模塊的源代碼。一般由開發人員而非獨立測試人員來執行，因為測試者需要懂得該單元的設計與程序實現，測試者可能需要編寫額外的測試驅動程序。集成測試將一些“構件”集成一起時，測試它們能否正常運行。這里“構件”可以是程序模塊、客戶機服務器程序等等。功能測試測試軟件的功能是否符合功能性需求，通常采用黑盒測試方式。一

5、般由獨立測試人員執行。系統測試測試軟件系統是否符合所有需求，包括功能性需求與非功能性需求。一般由獨立測試人員執行，通常采用黑盒測試方式。回歸測試指錯誤被修正后或軟件功能、環境發生變化后進行的重新測試。回歸測試的困難在于不好確定哪些內容應當被重新測試。驗收測試由客戶或最終用戶執行，測試軟件系統是否符合需求規格說明書。軟件測試的分類軟件測試的分類負載測試測試軟件系統的最大負載，超出此負載軟件可能會失常。壓力測試概念上與負載測試相似，叫法不同。性能測試測試軟件在各種狀況下的性能，如在正常或最大負載下的狀況。易用性測試測試軟件是否易用，主觀性比較強。一般要根據很多用戶的測試反饋信息，才能評價易用性。安

6、裝與反安裝測試測試軟件在“全部、部分、升級”等狀況下的安裝/反安裝過程。恢復測試測試該系統從故障中恢復過來的能力。安全性測試測試該系統防止非法侵入的能力。兼容性測試測試該系統與其它軟件硬件兼容的能力。比較測試通過與同類產品比較，考察該系統的優點、缺點。Alpha 測試一種先期的用戶測試，此時系統剛剛開發完成。Beta測試一種后期的用戶測試，此時系統已經通過內部測試，大部分錯誤已經改正，即將正式發行。軟件測試方法測試用例設計、缺陷提交法則等測試人員相關素質打破沙鍋問到底1.探索精神：軟件測試員不會害怕進入陌生環境。2.故障排除能手：軟件測試員善于發現問題的癥結，喜歡猜謎。3.不懈努力：軟件測試員

7、總是不停嘗試。他們可能會碰到轉瞬即逝或者難以重建的軟件缺陷；他們不會心存僥幸，而是盡一切可能去尋找。4.創造性：想出富有創意甚至超常的手段來尋找軟件缺陷。5.追求完美：他們力求完美，但是知道某些無法企及時，不去苛求，而是盡力接近目標。6.判斷準確：軟件測試員要決定測試內容、測試時間，以及看到的問題是否算作真正的缺陷。7.老練穩重：軟件測試員不害怕壞消息。8.說服力：軟件測試員要善于表達觀點，表明軟件缺陷為何必須修復，并通過實際演示力陳訴觀點。測試相關文檔測試計劃：指明范圍、方法、資源，以及相應測試活動的時間進度安排表的文檔。測試方案：指明為完成軟件或軟件集成特性的測試而進行的設計測試方法的細節

8、文檔。測試用例：指明為完成一個測試項的測試輸入、預期結果、預期執行條件等因素的文檔。測試報告：指明執行測試結果的文檔。什么是測試用例？所謂的測試用例就是將軟件測試的行為活動，做一個科學化的組織歸納。軟件測試是有組織性、步驟性和計劃性的，而設計軟件測試用例的目的，就是為了能將軟件測試的行為轉換為可管理的模式。軟件測試是軟件質量管理中最實際的行動，同時也是耗時最多的一項。基于時間因素的考慮，軟件測試行為必須能夠加以量化，才能進一步讓管理階層掌握所需要的測試過程，而測試用例就是將測試行為具體量化的方法之一。測試用例要素所屬模塊：按照不同的模塊進行測試，為測試用例分組；編號ID：測試用例的唯一性標志；

9、用例描述：簡單的語言描述所測試的內容，例如“設置廣播服務器網絡參數，并測試網絡連通性”；重要級別：高、中、低三級；、預置條件：就是執行當前測試用例的前提描述，如果不滿足這些條件，則無法進行測試；測試輸入：測試用例執行時，需要輸入的外部信息。例如：某一個文件，數據記錄等；操作步驟：執行當前測試用例所要經過的操作步驟，需要給出每一步操作的詳細描述，測試人員根據測試用例操作步驟，完成測試用例的執行預期結果：當前測試用例的預期輸出結果，用來與實際結果比較，如果相同則該測試用例通過，否則該測試用例失敗。測試結果：Pass、Fail、Block測試用例設計方法等價等價類劃類劃分法分法邊界邊界值分值分析法析

10、法場景場景法法錯誤錯誤推測推測法法因果因果圖法圖法判定判定表驅表驅動法動法正交正交試驗試驗設計設計法法功能功能圖法圖法等價類劃分法等價類劃分法等價類劃分等價類劃分法是把程序的輸入域劃分成若干部分，法是把程序的輸入域劃分成若干部分，然后然后從每個部分從每個部分中選取少數代表性數據當作測試用例中選取少數代表性數據當作測試用例。每。每一類的代表性數據在測試中的一類的代表性數據在測試中的作用等價于這一類作用等價于這一類中的中的其他值，也就是說，如果某一類中的一個例子發其他值，也就是說，如果某一類中的一個例子發現了現了錯誤錯誤，這一等價類中的其他例子也能發現同樣的錯誤；反之，這一等價類中的其他例子也能發

11、現同樣的錯誤；反之，如果，如果某一類中的一個例子沒有發現錯誤，則這一類中的某一類中的一個例子沒有發現錯誤，則這一類中的其他其他例子也不會查出例子也不會查出錯誤。錯誤。 邊界值分析法邊界值分析法由由測試工作的經驗得知，大量的錯誤是發生在輸入測試工作的經驗得知，大量的錯誤是發生在輸入或輸出或輸出范范圍的邊界上，而不是在輸入范圍的內部。因此圍的邊界上，而不是在輸入范圍的內部。因此針對針對各種邊界情各種邊界情況設計測試用例，可以查出更多的錯誤。況設計測試用例，可以查出更多的錯誤。 邊界值分析邊界值分析是一種補充等價劃分的測試用例設計技術是一種補充等價劃分的測試用例設計技術，它，它不不是選擇等價類的任意

12、元素，而是選擇等價類邊界是選擇等價類的任意元素，而是選擇等價類邊界的測試用例的測試用例。實踐證明為檢驗邊界附近的處理專門設計實踐證明為檢驗邊界附近的處理專門設計測試用例測試用例，常常取得，常常取得良好的測試效果。良好的測試效果。場景法場景法 現在現在的軟件幾乎都是用事件觸發來控制流程的，事件的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思序和處理結果就形成事件流。這種在軟件設計方面的思想也可引入到軟件測試中，可以比較生動地描繪出事件想也可引入到軟件測試中，可

13、以比較生動地描繪出事件觸發時的情景，有利于測試設計者設計測試用例，同時觸發時的情景，有利于測試設計者設計測試用例，同時使測試用例更容易理解和執行。使測試用例更容易理解和執行。用例用例場景用來描述流經用例的路徑，從用例開始到結場景用來描述流經用例的路徑，從用例開始到結束遍歷這條路徑上所有基本流和備選流。束遍歷這條路徑上所有基本流和備選流。軟件缺陷bug五級規范七級規范（bugzilla嚴重級別，Severity）bugzilla優先級（Priority）問題級別描述問題嚴重等級級別定義描述1導致系統崩潰、死機；出現不可挽救的數據丟失或損壞、內存泄露；blocker中斷缺陷Blocks debel

14、opment and/or testing work.妨礙開發和測試，非常嚴重。例如：程序不能運行起來，服務不能啟動，或啟動以后立刻崩潰。P12導致程序模塊丟失或未實現；軟件錯誤導致數據丟失；用戶需求未實現；critical臨界缺陷crashes,loss of data,severe memory leak.軟件崩潰、丟失數據或嚴重的內存泄漏等。例如：本應7*24小時運行的程序在運行一天以后崩潰、錄像服務丟失錄像數據等。P23發現影響被測功能正確實現的問題；major較嚴重缺陷major loss of function.功能主體受損失。例如：原本設計的一個功能不能實現或實現得不好，或影響實

15、際使用效果的缺陷。P3normal普通缺陷for an application crash or other issue.4一般性錯誤或者功能實現不完善等； minor次要缺陷minor loss of function,or other problem where easy workaround is present.功能受到較小的影響；或其他問題，可以通過簡單的方法解決；例如：較小功能按鈕的失效等。P4trivial輕微缺陷cosmetic problem like misspelled words or misaligned text .只存在于表面的問題，比如錯別字、拼寫錯誤或界面對齊

16、不好等。5一些建議性的錯誤；enhancement測試建議Request for enhancement.要求新增的功能，或者測試的建議。P5Bug描述要素bug六要素錄入要求范例摘要必選項。簡要、準確、完整的描述錯誤實質。需要注明出現問題的模塊、頁面以及按鈕名稱等，異常情況需在摘要后加上“（異常）”，建議類的問題需要在摘要后加上“（建議）”加以區分。摘要：（異常）客戶端-錄像回放，錄像下載過程中，異常停止下載。重建必選項。有層次的簡述出現bug的操作步驟。要求完整記錄與bug出現有關的操作，描述完畢后可根據重建的內容自行操作一遍以確認無誤。重建：客戶端，錄像下載，11月28日18:00以后選

17、擇70多個錄像文件開始下載，進行老化測試。11月29日早晨發現，客戶端上顯示停留在一個錄像文件下載0%的進度，是正在下載的狀態，但無下載速度，且沒有再本地生成文件。概率可選項。用于區分問題的出現概率。不寫時，出現概率應為默認的100%，如果并非每次都出現或者是異常問題一定要注明，可用百分比來表述，如兩次重現操作中有一次可以出現該問題，則概率為50%。概率：測試過程中在單臺客戶端出現三次。隔離可選項。用于區分問題的重要程度，并能幫助開發定位問題。無法隔離的bug和可以很容易隔離的bug對于項目的重要程度是不一樣的。隔離：停止不下載的文件，重新選擇一個錄像文件開始下載以后可以正常繼續。分析可選項。

18、記錄個人在測試中的分析過程，通過邏輯性的語言描述猜測問題可能出現的原因或相關聯產生的問題等。分析：經抓包分析，錄像服務器沒有收到ack，可能因此導致此下載會話異常沒有開始且沒有斷開。附件可選項。盡可能的記錄圖片、dump文件（異常崩潰時必須有）、抓包文件等附件，附件可以幫助測試人員盡可能全面的向開發人員描述問題，降低溝通成本。附件：錄像異常停止下載.jpg，錄像異常停止下載.pcapBug描述的5C原則Correct： (準確) 每個要素的描述準確，不會引起誤解；Clear： (清晰) 每個組成部分的描述清晰，易于理解；Concise： (簡潔) 只包含必不可少的信息，不包含任何容易冗余信息，如操作過程中與bug的出現無關的操作步驟。Complete： (完整) 包含重現缺陷的完整步驟，和其他本質信息。Consistent： (一致)按照一致的格式書寫全部的缺陷模塊。如客戶端-錄像回放-錄像下載，或服務器-會話服務器-會話保活。性能測試性能測試通常會使用特定的測試工具，來模擬超常的數據量、負載等，監測系統的各項性能指標，性能測試通常會使用特定的測試工具，來模擬超常的數據量、負載等，監測系統的各項性能指標，如如CPUCPU和內存的使用情況、響應時間、反應速