1、鍵入文字測試理論培訓資料測試理論培訓資料鍵入文字錯誤猜測異常分析狀態遷移流程分析正交試驗法判定法 因果圖 輸出域覆蓋輸入域覆蓋邊界值 等價類 黑盒白盒程序插裝邏輯覆蓋信息流分析數據流分析控制流分析其他 處理過程條件組合輸入輸出整體特性內部實現動態分析靜態分析SRS HLD LLD GUIDB 編碼 調試 白盒 灰盒 黑盒軟件質量流程技術組織開發技術測試技術UTITST分析設計編碼ISO9001 CMM 6 西格瑪質量體系瀑布模型螺旋模型RUP 模型IPD 模型V&V 模型常見的項目組織結構需求管理配置管理同行評審缺陷管理鍵入文字鍵入文字鍵入文字需求分析SRS 評審SRS 基線化系統測試

2、的計劃設計和實現ST 計劃ST 方案ST 用例概要設計HLD 評審HLD 基線化詳細設計LLD 評審LLD 基線化編碼代碼走查UT 執行IT 執行ST 執行集成測試的計劃設計和實現IT 計劃IT 方案IT 用例單元測試的計劃設計和實現UT 計劃UT 方案UT 用例鍵入文字需求分析SRS 評審SRS 基線化系統測試的計劃設計和實現ST 計劃ST 方案ST 用例概要設計HLD 評審HLD 基線化詳細設計LLD 評審LLD 基線化編碼代碼走查UT 執行IT 執行ST 執行集成測試的計劃設計和實現IT 計劃IT 方案IT 用例單元測試的計劃設計和實現UT 計劃UT 方案UT 用例鍵入文字測測 試試 基

3、基 礎礎7軟軟 件件 質質 量量10測測 試試 方方 法法18V&V 模型（測試過程）模型（測試過程）21單單 元元 測測 試試23集集 成成 測測 試試29系系 統統 測測 試試37測測 試試 覆覆 蓋蓋 率率49測測 試試 用用 例例 舉舉 例例51同同 行行 評評 審審53配配 置置 & 需需 求求 管管 理理56缺缺 陷陷 管管 理理58SQLSQL SERVERSERVER61測試工具總結測試工具總結67第一階段英語單詞總結第一階段英語單詞總結84復習問題總結復習問題總結88鍵入文字測測 試試 基基 礎礎1、 軟件測試的目的：驗證（表達軟件能夠工作） 檢測（發現錯誤）

4、 預防（管 理質量）a 是否更好的為軟件使用者（用戶）服務；b 是否更好的為公司其他人員服務，提高軟件的質量。2、 測試執行：單元測試（UT 執行）：一個測試用例的測試執行； 集成測試（IT 執行）：一個測試用例集的測試執行； 系統測試（ST 執行）：不同測試階段的測試執行。這幾句話是什么意思，覺得不是很有針對性？3、 回歸測試的目的：a. 驗證錯誤是否修復；b. 檢測對代碼的修改是否引入了新的錯誤。5、 軟件測試的主要工作：a. 檢視代碼，評審開發文檔；b. 進行測試設計，寫作測試文檔（測試計劃、測試方案、測試用例等） ；c. 執行測試，發現軟件缺陷，提交缺陷報告，并確認缺陷最終得到了修正；

5、d. 通過測試度量軟件質量。 6、 軟件危機的出現主要表現在：a. 由于缺乏大型軟件開發經驗和軟件開發數據積累，開發工作計劃很難制定； b. 開發早期需求分析不夠明確，造成開發后期矛盾集中暴露；鍵入文字 c. 不遵循開發規范，開發文檔不完整，軟件難以維護； d. 缺乏嚴密有效的軟件質量檢測手段，交付給用戶的軟件質量差。7、 軟件危機的后果：a. 軟件質量不高，很難穩定；b. 軟件項目延期，進度無法控制；c. 成本增加，無法控制預算。8、 軟件危機的根源：a. 根據摩爾定律，硬件發展很快，相應對軟件系統的期望越來越高； b. 軟件系統復雜性提高，需多人合作； c. 軟件開發是人的智力活動，無法用

6、已有的產業工程方法來組織管理。9、 軟件生命周期的各個階段：計劃 需求分析 設計 編碼 測試 運行 評價10、 設計：概要設計（HLD）：在設計階段把各項需求轉換成相應的體系結構，每一部分是功能明確的模塊； 詳細設計（LLD）：對每個模塊要完成的工作進行具體的描述。11、 軟件研發相關要素：人員、過程、工具。12、 軟件項目組人員組成：分析人員、設計人員、開發人員、測試人員、配置管理人員、SQA（質量保證人員） ；13、 軟件研發流程類型：瀑布模型、螺旋模型、RVPRUP 流程、IPD 流程。鍵入文字14、 軟件研發中幾個重要的過程：需求管理；配置管理；缺陷管理；同行評審。15、 常見的引入缺

7、陷的原因：a. 開發過程缺乏有效的溝通，或者沒有進行溝通； b. 軟件復雜度越來越高； c. 編程中產生錯誤； d. 需求不斷變更； e. 項目進度的壓力； f. 不重視開發文檔；g. 軟件開發工具本身隱藏的問題。等等 鍵入文字軟軟 件件 質質 量量軟件質量管理體系：軟件質量管理體系：軟件質量管理體系： ISO9000（2000 版） CMM 六西格瑪ISO 9000 ISO 9004 核心黃素ISO9000：2000 版標準版標準ISO9000：制定管理理念和原則ISO9001：標準對組織質量管理體系必須履行的要求做了明確的規定，是對產品要求的進一進補充。 （梳心）ISO9004：是組織進行

8、持續改進的指南標準。八項質量管理原則： 一以顧客為中心：組織依存于其顧客，因此，組織應理解顧客當前的和未來的需求， 滿足顧客要求并爭取趕超顧客期望。ISO 9001鍵入文字二領導作用： 領導者將本組織的宗旨.方向和內部環境編統一起來，并創造使員工能 夠充參與實現組織目標的環境。三全員參與： 各級人員是組織之本，只有他們的充分參與，才能使他們的才干為組 織帶來最大的收益。四過程方法： 將相關的資源和活動作為過程進行管理，可以更高效地得到期望的結 果。 五 管理系統方法：針對設定的目標，識別.理解并管理一個由相互關聯的過程的過程 所組成的體系，有助于提高組織的有效性和效率。六 持續改進：持續改進是

9、組織的一個永恒的目標。七 基于事實的決策方法：對數據和信息的邏輯分析或直覺判斷是有效決策的基礎。八 互利的供方關系：通過互利的關系，增強組織及其供方創造價值的能力。其中與軟件產品產品優其相關有：（一.三.六.七項）1、 軟件質量的定義：一個實體的所有特性，基于這些特性可以滿足明顯的或隱含的需求。而質量就是實體基于這些特性滿足需求的程度。2、 軟件質量的三個層次：a. 符合需求規格；b. 符合用戶顯示需求； c. 符合用戶實際需求。3、 影響軟件質量的因素：流程、技術、組織。流程：一組活動（活動是否都是必須的；活動角色之間的關系）過程：一組將輸入轉化為輸出的相關聯或相互作用的活動。4、 八項質量

10、管理原則的意義：a. 是質量管理的理論基礎； b用高度概括易于理解的語言所表述的質量管理的最基本，最通用的一般性規律； c. 為組織建立質量管理體系提供了理論依據；鍵入文字 d. 是組織的領導者有效的實施質量管理工作必須遵循的原則。5、CMM 軟件質量成熟度模型 CMM(capabillty Maturity Moelel)由于美國軟件工程研究所（SEI）受美國國防部委托立項。開發人：Watts Humphrey.1991 年推出 CMM1.0 版，1993 年提出 CMM1.1 版現在開發 CMMI（CMM Integration）軟件能力成熟度模型軟件能力成熟度模型 CMM（提唱過程決定質

11、量）（提唱過程決定質量） 持續改進過程 可預測的過程 管理變更 標準.一致的過程 產品過程質量 紀律的過程 集成工程過程 項目管理CMM1 級級特點：（個人英雄主義）特點：（個人英雄主義）A 項目的成功依賴于一個非常優秀的項目經理的團隊。B 無法重復以往成功的實踐。C 缺乏基本配置管理1 初始級初始級 initial不可預測并且缺控制2 可重復級可重復級 Repeatable可重復以前的主要經驗3 已定義級已定義級 Definded過程被描述，并得到良好理解4 已管理級已管理級 Managed過程被描述，并得到良好理解5 優化級優化級關注過程改進鍵入文字可視度：可視度：整個過程不可預測，不可見

12、，不可控。 （過程管理非常混亂）CMM2 級級特點：（有紀律）特點：（有紀律）能夠重復以前成功的經驗和實踐。引入合理需求變更（需求管理）測試與開發分離，整個過程能力可概為有紀律的。可視度可視度原始需求需求分析設計編碼測試產品CMM3 級級特點：（有過程，經過同行評審）特點：（有過程，經過同行評審）組織中有一個專門負責組織的標準軟件過程。 （SEPG）可視度可視度同 CMM2 但整個過程是標準和一致的。CMM4 級特點級特點特點：（量化管理）特點：（量化管理）過程能力是可預防的，因為過程是已測量的并在可測的范圍內運行。組織能定量地預測過程和產品質量方面趨勢。軟件產品具有可預測的高質量。可視度可視

13、度同 CMM3 但整個過程是可預測的。CMM5 級特點級特點特點：（改進過程本身）特點：（改進過程本身）通過缺陷來發現過程的不足。新的開發技術觸使改進過程。可視度可視度同 CMM￥級整個是以改進的。CMM1：初始級，Inltial，不可預測并且缺乏控制； CMM2：可重復級：Repeatable，可重復以前的主要經驗；（關鍵過程區域：需求管理；軟件項目計劃；軟件項目跟蹤和監督；軟件子鍵入文字合同管理；軟件質量保證；軟件配置管理。 ） CMM3：已定義級：Defined，過程被描述，并得到良好理解；（關鍵過程區域：組織過程定義；組織過程焦點；培訓大綱；集成軟件管理；軟件產品工程；組際協調；同行評

14、審。 ）CMM4：已管理級：Managed，過程被測量并受控；（關鍵過程區域：定量的過程管理；軟件質量管理。 ）CMM5：優化級，Optimizing，關注過程改進。（關鍵過程區域：缺陷預防；技術變更管理；過程變更管理。 ）7、 CMM 的用途：a. 評估組用來識別組織中的強處和弱處； b. 評價組用來識別選擇不同的業務承包商的風險和監督合同； c. 管理者用來了解其組織的能力，并了解為了提高其能力成熟度而進行軟件過程改進所需進行的活動； d. 技術人員和過程改進組用來作為指南，指導他們在組織中定義和改進軟件過程。8、 ISO9001 和 CMM 的關系： 相似點：強調管理、過程、規范化和文檔

15、化； 不同點：CMM 把焦點對準軟件；ISO9001 的范圍包括：硬件、軟件、流程性材料和服務； 兩者關系：CMM2 級與 ISO9001 強相關；CMM 的每個關鍵過程域至少按某種解釋與ISO9001 弱相關。六西格瑪管理法（強調組織能力）六西格瑪管理法（強調組織能力）本質：全面質量管理，而不僅僅是質量提高手段本質：全面質量管理，而不僅僅是質量提高手段六西格瑪實施方式：六西格瑪實施方式： DMAIC過程過程鍵入文字 推行控制系統推行控制系統 優化解決方案優化解決方案 研究資料，確定原因研究資料，確定原因 收集資料，尋找原因收集資料，尋找原因 提出問題，確定目標提出問題，確定目標9、 軟件質量

16、模型: 功能性：當軟件在指定條件下使用時，軟件產品提供滿足明確和隱含需求的功能的能力。包括：適合性；準確性；互操作性；保密安全性；功能性的依從性。 可靠性：在指定條件下使用時，軟件產品維持規定的性能級別的能力。包括：成熟性；容錯性；易恢復性；可靠性的依從性。 易用性：在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。包括：易理解性；易學性；易操作性；吸引性；易用性的依從性。 效 率：在規定條件下，相對于所用資源的數量，軟件產品可提供適當性能的能力。包括：時間特性；資源利用性；效率依從性。 維護性：軟件產品可被修改的能力。修改可能包括修正、改進或軟件對環境、需求和功能規格說明變化的

17、適應。包括：易分析性；易改變性；穩定性；易測1 定義 Define2 測量 Measure3 分析 Anslyse4 改進 Improre5 控制 cororol鍵入文字試性；維護性的依從性。 可移植性：軟件產品從一種環境遷移到另外一種環境的能力。包括：適應性；易安裝性；共存性；易替換性；可移植性的依從性。10、 軟件質量活動：軟件質量保證(SQA)和測試；SQA 從流程方面保證軟件的質量、測試從技術方面保證軟件的質量、只進行 SQA 或者只進行測試活動不一定能產生好的軟件質量。11、 SQA 的主要工作范圍： 指導并監督項目按照過程實施； 對項目進行度量、分析，增加項目的可視性； 審核工作產

18、品，評價工作產品和過程質量目標的復合度； 進行缺陷分析，缺陷預防活動，發現過程的缺陷，提供決策參考，促進過程改進。12、 度量：對事物屬性的量化表示；軟件度量：是指計算機軟件中范圍廣泛的測度，包括對軟件系統、構建或生命周期過程具有的某個給定屬性的度的一個定量測量。目的： 提高軟件生產率，縮短產品研發周期，降低研發成本、維護成本； 提高軟件產品質量，提高用戶滿意度； 為組織持續改進提供量化的指標和反饋。13、 軟件度量的作用：理解；預測；評估；改進。分類：規模；工作量；進度；質量 如何將度量的知識應用于實際工作中：建立測試工作的度量數據，目的是作為預測和改進的基礎（a. 熟悉需求：進度、工作量、

19、規模；b. 設計用例：工作效率、覆蓋率；c. 執行用例：工作效率、缺陷密度；）鍵入文字鍵入文字測測 試試 方方 法法1 1、 什么是白盒測試：什么是白盒測試： 白盒測試是依據被測軟件分析程序內部構造，并根據內部構造設計用例，來對內部控制流程進行測試，可完全不顧程序的整體共能實現情況； 白盒測試是基于程序結構的邏輯驅動測試； 白盒測試又可以被稱為玻璃盒測試、透明盒測試、開放盒測試、結構化測試、邏輯驅動測試。2 2、 為什么進行白盒測試：為什么進行白盒測試： 一般在測試前期進行，通過達到一定的邏輯覆蓋率指標，使得軟件內部邏輯控制結構上的問難題能基本得到消除； 能保證內部邏輯結構達到一定的覆蓋程度，

20、能夠給予軟件代碼質量更大的保證； 發現問題后解決問題的成本較低。3 3、 白盒測試的常用技術：白盒測試的常用技術： 靜態分析：控制流分析、數據流分析、信息流分析等； 動態分析：邏輯覆蓋測試（分支測試、路徑測試等） 、程序插裝等。4、 * *控制流相關概念：控制流相關概念：程序元素、控制流關系、控制流圖、控制流矩陣。 （步驟：5）5、 * *控制流分析能發現的問題：控制流分析能發現的問題：轉向并不存在的標號；沒有用的語句標號；從程序入口進入后無法達到的語句；不能達到停機語句的語句。6、 * *數據流相關概念數據流相關概念：數據的定義；數據的引用。 （步驟：3）7、 * *數據流分析的左右：數據流

21、分析的左右：分析代碼中關于數據定義和引用方面的錯誤；進行代碼優化。 （賦值語句運算效率高）鍵入文字8、 * *信息流分析：信息流分析：輸入變量和語句關系；語句和輸出變量關系；輸入和輸出變量管 理。 （步驟：4）9、 覆蓋率工具的作用：覆蓋率工具的作用： 分析被測試代碼控制結構，決定插裝位置； 實施插裝； 將插裝代碼重新編譯； 執行被測對象，根據插裝的監控哨信息統計覆蓋率。10、白盒測試的特點：白盒測試的特點： 測試人員需要了解軟件的實現； 可以檢測代碼中的每條分支和路徑； 解釋隱藏在代碼中的錯誤； 對代碼的測試比較徹底； 實現代碼結構上的優化； 白盒測試投入較大，成本高； 白盒測試不驗證規格的

22、正確性。11、什么是黑盒測試：什么是黑盒測試： 黑盒測試把被測對象看成一個黑盒，只考慮其整體特性，不考慮其內部具體實現； 黑盒測試針對的被測對象可以是一個系統、一個子系統、一個模塊、一個子模塊、一個函數等。 黑盒測試又可以被稱為基于規格的測試。12、常見的黑盒測試類型：常見的黑盒測試類型：功能性測試；容量測試；負載測試；恢復性測試。13、*系統測試的時候，如果沒有 SRS 時，有兩類 BUG 無法發現：需求遺漏；需求偏差。14、黑盒測試的黑盒測試的優點優點：對于更大的代碼單元來說（子系統甚至系統級）比白盒測試效率要高； 測試人員不需要了解實現的細節，包括特定的編程語言； 從用戶的視角進行測試，

23、很容易被大家理解和接受； 有助于暴露任何規格不一致或鍵入文字有歧義的問題。15、黑盒測試的黑盒測試的缺點缺點： 沒有清晰的和簡明的規格，測試用例是很難設計的； 不能控制內部執行路徑，會有很多內部程序路徑沒有被測試到；不能直接針對特定的程序段，這些程序可能非常復雜（因此可能隱藏更多的問題） 。16、動態和靜態測試的分類依據在于：動態和靜態測試的分類依據在于：被測對象是否運行起來。17、手工靜態分析手工靜態分析同行評審：同行評審：正規檢視；技術評審；走查。評審對象：計 劃、需求文檔、設計圖、代碼等。18、自動化靜態分析：自動化靜態分析：靜態驗證；語法分析器；符號執行器。 自動化測試的限制（板書）：

24、自動化測試的限制（板書）： 自動化測試不具備想象力，不能夠檢查腳本中給定的觀察點之外的錯誤； 自動化測試只能提高測試效率，不能提高測試效果，不能發現比人工測試更多的問題；如被測對象不穩定，存在變動性的話不適合開展自動化測試，否則腳本的編寫和維護所耗費的時間可能遠大于人工測試； 只有手工測試積累到一定程度（提供更多的觀察點） ，才能做好自動化測試。鍵入文字V&V 模型（測試過程）模型（測試過程）1 1、 驗證與確認驗證與確認 V&VV&V：驗證（VERIFICATION）強調過程；確認（VALIDATION）強調 結果。2 2、 V&VV&V 告訴我們：告

25、訴我們： 盡早測試（盡早準備、盡早執行） ； 全面測試（文檔、代碼） 全過程測試（測試參與到開發過程中、對測試過程全稱跟蹤） 測試是獨立的、迭代的。3、 單元、集成、系統測試的比較：單元、集成、系統測試的比較：測試方法不同；考察范圍不同；評估基準不同。4、 回歸測試策略：回歸測試策略：完全重復測試；選擇性重復測試（覆蓋修改法；周邊影響法； 指標達成方法；選擇重要級別高的測試用例）5、 其他測試階段：其他測試階段：驗收測試；a(ALPHA)測試；B(BETA)測試。系統測試執行集成測試執行單元測試執行代碼審查需求分析SRS 評審SRS 基線化概要設計HLD 評審HLD 基線化詳細設計LLD 評審

26、LLD 基線化CODE系統測試計劃系統測試方案設計系統測試用例設計集成測試計劃集成測試方案設計集成測試用例設計單元測試計劃單元測試方案設計單元測試用例設計鍵入文字6、 主要的測試文檔：主要的測試文檔：測試計劃；測試方案；測試用例；測試規程；測試報告；測試日報。鍵入文字單單 元元 測測 試試1、 單元測試的目的：單元測試的目的：在于發現各模塊內部可能存在的各種錯誤主要是基于白盒測試。 驗證代碼是與設計相符合的； 發現設計和需求中存在的錯誤； 發現在編碼過程中引入的錯誤。 （和設計不相符 / 和設計相符，但是由于編碼疏漏引起）2、 孤立的測試策略：孤立的測試策略： 方法：不考慮每個模塊與其他模塊之

27、間的關系，為每個模塊設計樁模塊和驅動模塊。每個模塊進行獨立的單元測試。 優點：該方法是最簡單，最容易操作的。可以達到高的結構覆蓋率。該方法是純粹的單元測試。 缺點：樁函數和驅動函數工作量很大，效率低。3、 自頂向下的單元測試策略：自頂向下的單元測試策略： 方法：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊。其次對第二層進行測試，使用上面已測試的單元做驅動模塊。如此類推直到測試完所有模塊。 優點：可以節省驅動函數的開發工作量，測試效率較高。 缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復雜，并且開發和維護的成本將增加。4、 自底向上的單元測試策略：自底向上的單元測試策略： 方

28、法：先對模塊調用層次圖上最低層的模塊進行單元測試，模擬調用該模塊的模塊做驅動模塊。然后再對上面一層做單元測試，用下面已被測試過的模塊做樁模塊。以此類推，直到測試完所有模塊。 優點：可以節省樁函數的開發工作量，測試效率較高。 缺點：不是純粹的單元測試，底層函數的測試質量對上層函數的測試將產生很大的影響。5、 單元測試的四個階段：單元測試的四個階段： 測試計劃：完成單元測試計劃； 測試設計：完成單元測試方案；鍵入文字 測試實現：完成單元測試用例、單元測試規程、單元測試腳本及數據文件； 測試執行：執行單元測試用例，修改發現的問題并進行回歸測試，提交單元測試報告。 單元測試：樁單元測試：樁&驅

29、動舉例：驅動舉例：無論是單元測試還是集成測試都涉及到以下三個函數：主控函數：int ctrl(int x, int y)加法函數：int add(int x, int y)減法函數：int sub(int x, int y)注意：進行單元測試時，設計用例時依據的是 LLD；進行集成測試時，設計測試用例依據的是 HLD。下面給出來的是需要測試的實際的代碼。int ctrl(int x, int y)int temp=0;if(x=y) temp=add(x, y);else temp=sub(x, y);return temp;int add(int x, int y) return(x+y);

30、int sub(int x, int y) return(x-y);自頂向下單元測試策略自頂向下單元測試策略不同測試步驟中的驅動可以寫到一起，也可以分開寫，這里是寫到一起了。不同測試步驟中的驅動可以寫到一起，也可以分開寫，這里是寫到一起了。測試測試 ctrl 函數函數需要寫一個驅動和兩個樁。驅動函數驅動函數void driver()int ret=0;ret=ctrl(2,1); /xy鍵入文字if(ret=3) printf(“testcase JISUAN_UT_CTRL_001 pass”);else printf(“testcase JISUAN_UT_CTRL_001 fail”);

31、ret=ctrl(1,1); /x=yif(ret=2) printf(“testcase JISUAN_UT_CTRL_002 pass”);else printf(“testcase JISUAN_UT_CTRL_002 fail”);ret=ctrl(1,2); /x=y)鍵入文字 temp=stub_add(x, y);else temp=stub_sub(x, y);return temp;測試測試 add 函數函數 驅動函數驅動函數同測試 ctrl 函數時的驅動樁函數樁函數同測試 ctrl 函數時 sub 函數對應的樁修改代碼修改代碼int ctrl(int x, int y) i

32、nt temp=0;if(x=y) temp=add(x, y); if(x=2 & y=1 & temp=3) printf(“testcase JISUAN_UT_ADD_001 pass”); else printf(“testcase JISUAN_UT_ADD_001 fail”); if(x=1 & y=1 & temp=2) printf(“testcase JISUAN_UT_ADD_002 pass”); else printf(“testcase JISUAN_UT_ADD_002 fail”);else temp=stub_sub(x, y

33、);return temp;測試測試 sub 函數函數鍵入文字驅動函數驅動函數同測試 ctrl 函數時的驅動樁函數樁函數無鍵入文字 29修改代碼修改代碼int ctrl(int x, int y) int temp=0;if(x=y) temp=add(x, y);else temp=sub(x, y); if(x=1&y=2 & temp=-1) printf(“testcase JISUAN_UT_SUB_001 pass”); else printf(“testcase JISUAN_UT_SUB_001 fail”);return temp; 鍵入文字 30集集 成成

34、測測 試試一一 WhatWhat：什么是集成測試：什么是集成測試集成測試(Integration Testing) 集成測試也叫組裝測試、聯合測試、部件測試、子系統測試集成測試測什么 1.外部接口：各件吶在一起后表現的功能 2.內部接口：各件間的接口是否正確 集成蘇的目的驗證軟件的組建對概要設計說明書的符合度集成測試的評估基準： 接口覆蓋率 A.接口被測試到的百分比 B.接口的等價類、邊界值的覆蓋率二二 WhyWhy：為什么要做集成測試：為什么要做集成測試一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。雖然

35、已經有了 IT 和 ST，但 IT 和 UT、ST 關注點不一樣，它們互為補充反分解性公理：為一個被測模塊獲得的覆蓋并不能覆蓋他所調用的模塊。反組合性公理：對于一個模塊中的對各子模塊分別合適的測試包并不一定對作為一個整體的模塊合適三三 WhoWho：誰做集成測試：誰做集成測試開發人員做 A 優勢:一般來說，編程能力稍強鍵入文字 31 B 劣勢:Protect（就像變形金剛的汽車人） ，心理上不愿意否定自己的勞動成果，職責是保護程序測試人員做 A 優勢:Destroy（就像變形金剛的霸天虎） ，心理上追求完美，職責是挑刺、破壞程序 B 劣勢:目前的現狀，大部分 tester 編程能力不夠四四 W

36、henWhen：什么時候做集成測試：什么時候做集成測試4.1 集成測試所處的測試過程集成測試所處的測試過程 A.測試準備活動在開發活動時可以并行開展，如開始做 HLD 設計時就可以開始做 ITP了 B.測試執行活動在單元測試的基礎上進行五五. . WhereWhere：對什么部分做集成測試：對什么部分做集成測試子系統間集成（系統內集成）模塊間集成（子系統內集成）函數間集成（模塊內集成）六六. . HowHow：怎么做集成測試：怎么做集成測試6.1 測試過程的制定6.1.1 計劃根據 SVVP 制定 ITP6.1.2 設計根據 ITP 制定 IT 方案6.1.3 實現根據 IT 方案制定 IT

37、用例鍵入文字 326.1.4 執行根據 IT 用例進行集成測試，提交 Bug Report，回歸測試6.2 采用的測試方法6.2.1 灰盒測試隨集成層次不同，灰度隨之相應變化6.3 制定集成測試策略 Test Strategy6.3.1 根據被測對象（層次）選擇合適的策略11大爆炸集成大爆炸集成 BigBig BangBang 優點方法簡單、效率高缺點急于求成，成功率不高大海撈針，導致即使發現問題也難以定位（無法故障隔離）囫圇吞棗，許多內部接口的錯誤被漏測適用范圍小項目、維護型項目軟件結構不清晰的系統22自頂向下集成自頂向下集成 Top-DownTop-Down子策略深度優先（Depth-Fi

38、rst）廣度優先（Broadth-First）優點A.主控模塊（高層組件）得到較早驗證鍵入文字 33B.深度優先策略能夠較早驗證一個完整的功能，增強了開發信心C.基本不需要開發驅動，減少了這部分的工作量D.和高層設計順序一致，方便并行開展E.定位問題容易，支持故障隔離缺點A.需要開發大量的樁，工作量、成本太大B.底層變更可能導致測試推倒重來C.底層組件的驗證較晚，測試不充分適用范圍A.軟件結構清晰的系統B.高層接口變化小，底層接口變化大C.主控模塊風險大，需盡早驗證D.希望盡早看到系統一部分功能33自底向上集成自底向上集成 Bottom-UpBottom-Up優點A.底層組件得到較早驗證B.測

39、試初期可以并行集成，效率高C.由于驅動模塊是額外編寫的，對被測模塊的可測試性要求較低D.減少了開發樁的工作量E.定位問題容易，支持故障隔離缺點A.需要開發大量的驅動，工作量、成本同樣很高B.對高層的驗證太晚了，設計上的缺陷不能被及早發現C.集成到頂層后，對于底層異常將難以覆蓋。而使用樁將簡單得多鍵入文字 34適用范圍A.軟件結構清晰的系統B.底層接口穩定、或先被開發出來C.高層接口變化較頻繁44 三明治集成（分而治之策略）三明治集成（分而治之策略） 又分為傳統型和改進型又分為傳統型和改進型 SandwichSandwich優點融合了自頂向下和自底向上兩種策略的優點缺點中間層測試要么不充分，要么

40、測的充分但開發驅動和樁的工作量大適用范圍軟件結構清晰的系統基本都適合采用55基干集成（內核耦合度高）基干集成（內核耦合度高） BackboneBackbone結構與策略：內核（大爆炸）-應用子系統（自底向上）-控制子系統（自頂向下）優點具有三明治集成的優點缺點A.對系統結構的分析存在一定難度B.由于被測系統復雜，驅動和樁的開發工作量較大C.局部采用了大爆炸策略，存在大爆炸所有的缺點適用范圍嵌入式系統66分層集成（線性關系）分層集成（線性關系） LayersLayers集成方式A.層內集成鍵入文字 35策略非常靈活，可以是各種其他策略優缺點根據策略而變B.層間集成策略和優缺點同層內集成使用范圍有

41、明顯線性層次關系的系統77基于功能集成基于功能集成 Function-BasedFunction-Based優點A.可以盡早驗證關鍵組件的功能B.可能同時加入多個模塊，與大爆炸類似，效率較高C.和自頂向下一樣，驅動模塊的開發工作量不多缺點A.兼具大爆炸和自頂向下的缺點，比如對有些接口測試不充分，可能導致漏測B.可能會有較多的冗余測試適用范圍對功能的實現沒把握的產品88持續集成（高頻集成、每日集成）持續集成（高頻集成、每日集成） Continuous/High-frequencyContinuous/High-frequency優點A.錯誤能被較早發現，且容易定位B.開發和集成可以并行，效率高缺

42、點測試針對性不強，不容易發現有價值的問題適用范圍迭代開發、增量開發的產品鍵入文字 3699基于進度集成基于進度集成 Schedule-BasedSchedule-Based優點并行度高，能縮短項目進度缺點組件間缺乏整體性，無法有效集成開發驅動和樁的工作量難以估計由于進度原因，集成效果不好適用范圍進度很緊的項目1010基于風險集成基于風險集成 Risk-BasedRisk-Based優點風險大的模塊得到較早驗證，有助于系統的快速穩定缺點風險分析偏差導致集成重點的偏離適用范圍有些組件有較大的風險，需及早驗證以增強信心1111基于消息（事件）集成基于消息（事件）集成 Message-Based/Ev

43、ent-BasedMessage-Based/Event-Based優缺點與基于功能集成類似，適用面向對象系統1212基于使用集成基于使用集成 Use-BasedUse-Based優缺點與自底向上類似，適用面向對象系統1313基于基于 C/SC/S、B/SB/S 的集成的集成適用 C/S、B/S 結構的系統1414分布式集成分布式集成 DistributedDistributed ServicesServices適用分布式系統鍵入文字 37鍵入文字 38系系 統統 測測 試試 定義定義System Testing-是將已經集成好的軟件系統，作為整個計算機系統的一個元素，與計算機硬件、外設、某些

44、支持軟件、數據和人員等其他系統元素結合在一起，在實際運行使用的環境下，對計算機系統進行系列的測試活動； 對象對象鍵入文字 391.產品級-軟件+硬件2.項目級-軟件（也可能包含硬件） 完備性完備性如何保證系統測試的完備性？如何保證系統測試的完備性？1.盡可能所有需求都有對應的 Test Case;2.依據軟件的質量特性，以不同的角度，測試需求;3.依據不同的 Test Case、方法，構造不同的測試數據及處理過程;常用測試方法1.11.1 功能測試（功能）功能測試（功能）定義：function Testing-依據 SRS 和測試需求列表驗證產品的功能是否實現和是否符合產品需求規格目標：1.是

45、否有不正確或遺漏了的功能？2.功能是實現是否滿足用戶需求，和系統設計的隱式需求？3.輸入能否正確接受？能否正確輸出結果？1.21.2 性能測試（效率）性能測試（效率）定義：Performance Testing-測試該軟件在集成系統中的運行性能。 （大多使用工具測試）目標：度量系統相對與預定義目標的差距。實施：1.性能指標定義明確。2.構造性能測試研究數據。鍵入文字 403.構造不同的性能測試場景。4.執行性能測試 （一般90%就通過） 。5.性能分析。6.性能故障定位。7.性能優化。依據1.資源占用性。2.CPU 響應時間。區別：1.壓力測試-不強調施壓量，只檢查施壓的狀況。2.容量測試-強

46、調施壓，施了多少壓。3.性能測試-施壓后檢驗性能指標是否達到規定資源使用和響應時間的要求。1.2.1 資源方面（資源占用情況）CPU 使用情況。IO 使用情況。內存使用情況。信道使用事情。1.2.2 時間方面（CPU 響應時間）每個模塊執行時間百分比。一個模塊等待 IO 完成的百分比。指令隨時間的跟蹤路徑。每一組指令頁換入和換出的次數。系統反映時間。系統吞吐量，即每個單元的處理數量。鍵入文字 41所有主要指令的單元執行時間。1.31.3 壓力測試壓力測試/ /極限測試（可靠性）極限測試（可靠性）定義：Stress Testing-系統在其資源超符合的情況下表現。目標：在極限或者惡劣的環境下，系

47、統的自我保護能力。主要驗證系統的可靠性。實施：1.同一時間，大量的用戶登陸。2.引入大量的操作。目的：1.是否存在內存泄露。2.驗證系統可靠性。3.測試后給予用戶一個明確的界定。區別：1.壓力測試-不強調施壓量，只檢查施壓的狀況。2.容量測試-強調施壓，施了多少壓。3.性能測試-施壓后檢驗性能指標是否達到規定資源使用和響應時間的要求。1.41.4 容量測試容量測試定義：volume Testing-使系統能夠承受超額的數據容量來發現它是否能夠正確處理。目標：1.測試系統容量是否滿足需求規定系統容量。2.若無規定系統容量可以通過此測試給出明確容量界定。實施：鍵入文字 421.構造一批大容量的測試

48、數據輸入到系統。2.對系統整體構造不同業務場景，反復執行。區別：1.壓力測試-不強調施壓量，只檢查施壓的狀況。2.容量測試-強調施壓，施了多少壓。 3.性能測試-施壓后檢驗性能指標是否達到規定資源使用和響應時間的要求。1.51.5 安全性測試（功能）安全性測試（功能）定義：Security Testing-驗證集成在系統內的保護機制能否在實際應用中保護系統不受到非法的侵入。目的：保證系統安全性，數據的完整性、保密性。1.5.1 數據完整性數據存儲的完整性。數據保密的完整性。保密性數據存儲的保密性。數據訪問的保密性。1.5.2 權限權限的分配權限的使用1.5.3 協議多在手機測試用到。鍵入文字

49、431.5.4 其他如 LOG.1.61.6 GUIGUI 測試（易用）測試（易用）定義：Graphical User Interface Testing-針對軟件系統的界面進行的測試。目標：1.界面實現與界面設計的吻合情況。(界面設計)2.確認界面處理的正確性。 （針對不同的控件分析）相關自動化測試工具1.WinRunner2.SilkTest3.QaRun 1.6.1 簡單界面元素定義：指功能和屬性相對比較單一的界面區域，即通常所指的各種控件。方法：主要關注他們的外觀、表現行為。1.6.2 組合類界面元素定義：一些復雜的界面元素，比如表格、各種文本編輯器等。方法：先將其分解為簡單的界面元素

50、，然后再進行處理。1.6.3 完整界面（窗口）定義：鍵入文字 44由一系列界面元素通過適當的形式組合而成的界面形式，最為常見的為各種窗口。包括各種對話框、單文檔窗口、多文檔窗口，多文檔子窗口等。方法：外觀、布局、行為。1.輸入類界面元素：與要考慮其外觀、輸入時的特性比如回顯、對齊原則、滾動原則等內容。2.輸出類界面元素：外觀。1.71.7 可用性測試（易用）可用性測試（易用）定義：Usability Testing-為檢測用戶在理解和使用系統方面到底有多好。目標：1.考慮產品是否符合實際應用情況。2.是否符合用戶習慣或特殊要求。3.操作方式是否方便合理、設備和用戶見交互信息是否準確易于理解、是

51、否遵從行業習慣、外觀/界面是否美觀等。一般關注的可用性問題：1.過分復雜的功能或指令。2.困難的安裝過程。3.錯誤信息過于簡單。4.用戶被迫去記太多信息。5.語法、格式和定義不一致。1.81.8 安裝測試安裝測試鍵入文字 45定義：根據軟件測試特性列表、軟件安裝、配置文檔，設計安裝過程的測試用例，發現軟件在安裝過程中的錯誤。被測對象：1.軟件本身。2.軟件安裝文檔。1.8.1 安裝測試前要檢查的工作1.安裝文檔是否齊全。2.安裝軟件的程序文件是否齊全。3.被測軟件的安裝文件是否齊全。4.軟件的安裝說明文檔是否齊全。5.檢查軟件的文件格式是否與安裝說明文檔中要求的文件格式相符。1.8.2 安裝測

52、試過程中的工作1.所有的預置數據是齊全。2.軟件環境配置是否合理。3.硬件環境配置是否合理。4.用戶選擇的一套任選方案是相容。5.安裝過程中：A.系統提供的缺省參數值進行安裝測試。B.指定由人工完成安裝過程，列出每一步安裝步驟所需的工作，并仔細檢查每一安裝步驟所完成工作的正確性。C.安裝測試過程中要設計異常的安裝測試用例，包括配置參數的異常、安裝選項和安裝路徑的異常。6.安裝文檔的測試。鍵入文字 461.8.3 安裝后要做的檢查工作1.所有文件是否都已產生并確有所需的內容。 A.程序文件的目錄是否正確產生。 B.各目錄及子目錄下的程序文件是否都正確產生。 C.是否存在無用的目錄、子目錄、程序文

53、件以及無用的子目錄。 D.目錄、子目錄、以及程序文件本身的權限是否正確。 E.對于 Windows 還要檢查與應用軟件相配套的動態鏈接庫文件齊全。2.安裝日志的檢查。3.安裝完成后，要進行程序的運行，聯結驗證。4.軟件的卸載測試。1.8.4 安裝測試中軟件的升級測試1.軟件通過重新安裝來達到升級的目的。2.通過 Patch 的方式實現軟件的升級。3.在線升級。1.91.9 配置測試配置測試定義：系統在各種軟硬件配置、不同參數配置下系統具有的功能和性能。目標：驗證全部配置的可操作性，有效性。1.101.10 異常測試異常測試/ /恢復性測試（可靠）恢復性測試（可靠）定義：容錯性測試。通過人工干預

54、手段產生異常，能檢驗系統的容錯、恢復能力，是系統可靠鍵入文字 47性評價的重要手段。異常處理1.系統自動處理。2.人工干預處理。注意1.系統的異常還與系統的指標測試有關，當系統的服務能力大于系統的設計指標時，也屬于系統的異常情況。2.系統的可靠性是設計出來的，而不是測試出來的。測試出的數據有助于為我們進一步的系統優化設計積累經驗，設計和測試是一個相互反饋的過程。1.111.11 備份測試（可靠）備份測試（可靠）恢復性測試的一個補充，驗證軟件或硬件失敗中備份他數據的能力。1.121.12 健壯性測試（可靠）健壯性測試（可靠）Robustness Testing 用于測試系統在故障時，是否能夠自動

55、恢復或者忽略故障繼續運行。1.131.13 文檔測試文檔測試Documentation Testing 測試文檔的正確性，保證操作手冊的過程能夠正常工作。1.141.14 在線幫助測試在線幫助測試Online Help Testing 檢測時實在線幫助的可靠性和正確性。1.151.15 網絡測試網絡測試網絡環境下和其他設備對接，進行系統功能、性能與指標方面的測試，保證對接的正確性。1.161.16 穩定性測試穩定性測試在一定負荷情況下能持續運行的時間。鍵入文字 482 2 系統測試測試過程系統測試測試過程2.12.1 計劃階段計劃階段明確 what 目標、why 測試目的、when 可控時間、

56、where 測試范圍、how 如何開展.主要活動有：參與開發人員軟件需求的分析，SRS 評審，通過后寫 ST 計劃，進行 ST 計劃評審。入口準則：SRS 完成并確定需求規格基線輸入：SRS|SDP|SVVP出口準則：ST 計劃評審通過輸出：2.22.2 設計階段設計階段主要活動有：組織人員依據測試計劃編寫測試方案，并進行系統方案的評審入口準則： ST 計劃評審通過輸入： ST 計劃|SRS出口準則： ST 方案評審通過輸出： ST 方案2.32.3 實現階段實現階段主要活動有：組織人員依據 ST 方案編寫測試用例、測試規程及預測試項，并對其進行評審入口準則： ST 方案評審通過輸入： ST

57、計劃|SRS|ST 方案出口準則： 測試用例、測試規程及預測試項評審通過輸出： 測試用例、測試規程及預測試項鍵入文字 492.42.4 執行階段執行階段主要活動有：組織測試執行活動、負責缺陷報告返回給開發部門修改、組織進行測試報告的編寫、組織進行測試報告的評審入口準則： 測試用例、測試規程及預測試項的評審通過輸入： ST 計劃|ST 方案|ST 用例|ST 規程|ST 預測試項出口準則： ST 報告評審并通過輸出： ST 預測試報告|ST 測試報告|缺陷報告測測 試試 覆覆 蓋蓋 率率1、 覆蓋率概念：覆蓋率概念： 覆蓋率是用來度量測試完整性的一個手段。覆蓋率是測試技術有效性的一個度量。覆蓋率

58、=（至少被執行一次的 item 數）/item 的總數； 覆蓋率大體可以劃分為兩大類：邏輯覆蓋和功能覆蓋； 測試用例設計不能一味追求覆蓋率，因為測試成本雖覆蓋率的增加而增加。2、 邏輯覆蓋主要類型：邏輯覆蓋主要類型：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、路徑覆蓋。3、 語句覆蓋率：語句覆蓋率：（Statement Coverage） ，在測試時運行被測程序后，程序中被執行到的可執行語句的比率； 語句覆蓋率 = （至少被執行一次的語句數量）/（可執行的語句總數）4、 分支覆蓋率：分支覆蓋率：（Branch Coverage）也叫判定覆蓋（Decision Coverage） ，它的含鍵入

59、文字 50義是：在測試時運行被測程序后，程序中所有判斷語句的取真分支和取假分支被執行到的比率；判定覆蓋率=（判定結果被評價的次數）/（判定結果的總數）5、 條件覆蓋率：條件覆蓋率：（Condition Coverage）的含義是，在測試時運行被測程序后，所有判斷語句中每個條件的可能取值（真值和假值）出現過的比率；條件覆蓋率=（條件操作數值至少被評價一次的數量）/（條件操作數值的總數）6、 分支分支-條件覆蓋率：條件覆蓋率：（Branch Condition Coverage）也叫判定條件覆蓋（Decision Condition Coverage） ，它的含義是，在測試時運行被測程序后，所有判

60、斷語句中每個條件的所有可能值（為真為假）和每個判斷本身的判定結果（為真為假）出現的比率；分支條件覆蓋率=（條件操作樹枝或判定結果至少被評價一次的數量）/（條件操作數值總數+判定結果總數）7、 路徑覆蓋率：路徑覆蓋率：（Path Coverage）的含義是，在測試時運行被測程序后，程序中所有可能的路徑被執行過的比率；路徑覆蓋率=（至少被執行到一次的路徑數）/（總的路徑數）8、 其他覆蓋率：其他覆蓋率：功能覆蓋率；面向對象的覆蓋率；函數覆蓋；指令塊覆蓋；判定路徑覆蓋。鍵入文字 51測測 試試 用用 例例 舉舉 例例測試用例編號BOSS_ ST_ MARKETING_NEW_01P重要級別高（還有“較高、中、較低、低”幾個等級）測試項目新增營銷記錄測試標題新增 10 元的營銷記錄用例類型基本事件（對應還有“備選事