轉載請標明出處，原文地址：http://blog.csdn.net/w565911788/article/details/47660625

【測試深度】

（1）縱向測試，功能性需求->隱藏性需求，前臺功能->中介軟體->後臺程式, 介面->協議->程式碼->架構設計

（2）TDD、DDD、ATDD、BDD、CI：針對設計開發流程的方法論，要求開發人員能從使用者的需求出發，具有測試意識，自頂向下良好設計習慣

=> 易混淆：功能深度相關測試點

【測試廣度】橫向測試，功能、效能、安全、相容性、可靠性、易用性、資料庫

=> 易混淆：功能廣度相關測試點

冒煙測試、隨機測試、安裝測試

本地化測試、國際化測試

白盒測試、黑盒測試、灰盒測試

迴歸測試、驗收測試、接受測試、動態測試

自動化測試、探索測試、深度測試

靜態測試、單元測試、整合測試 、系統測試

健全測試、衰竭測試

負載測試、強迫測試 、壓力測試 、效能測試

可用性易用性測試、解除安裝測試 、恢復測試

安全測試、相容性測試

比較測試、可接受性 、邊界條件、等價劃分、因果圖

強力測試、裝配安裝 、隱藏資料

基於設計、文件測試 、域測試、介面測試、協議測試

逆向測試、非功能性測試、極限測試

【測試效率（自動化）】自動化測試實施，持續整合，測試工具開發，測試流程、測試架構設計。

測試開發和自動化測試：測試中的開發，開發測試工具、測試指令碼，一樣需要良好程式設計習慣、使用框架模型、工具API，是具有自測、持續整合和開發理論意識的測試人員。

=> 提升效率和避免人為過多參與，自動比手動更可靠。（如：我們自動化組約定指令碼方法名規範為小寫字母加下劃線，即便都不會用PascalCase和camelCase但也不能相信人為約定可以完全規範，不如寫個指令碼在持續整合時檢查方法名等規範，不通過就算build failed不進行後續操作，手工review太浪費時間，這就是自動化對效率和可靠性的意義。）

=> 階段狀態：“原始矇昧(純手工) => 輔助工具參與 => 高效工具高度參與 => 部分功能過程自動化 => 全面全過程自動化 => 高效高度自動化 => 自優化智慧自動化”

【測試的流程】

測試需求分析，然後設計測試方案和制定測試計劃，然後進行測試用例設計和具體的測試執行，然後是問題的跟蹤解決和測試報告輸出。後續：測試總結和改善、歷史測試結果的管理和分析挖掘。

【開發過程最常見的兩個問題】

（1）需求和開發脫節：

A. 使用者想要的功能沒有開發

B. 開發的功能並非使用者想要

C. 使用者和開發人員所說語言不同

=> 解決方案：

A. 使用BDD和ATDD可以解決需求和開發脫節的問題，都是從使用者的需求出發，保證程式實現效果與使用者需求一致

B. 這個過程可以使用基於BDD的自動化測試工具Cucumber[kjukAmbl]（黃瓜）

（2）開發和測試脫節：

A. 開發和測試被人為割裂

B. 從開發到測試周期過長

C. 測試自動化程度低

=> 解決方案：

A. 開發的"全過程"都要貫穿測試：單元測試，整合測試和系統測試

B. 測試需要自動化

C. 所有測試通過，開發才算完成

D. 持續整合，保證每一次整合系統都能執行

【CI持續整合（ContinuousIntegration）】

（1）持續提交程式碼(Check-in) ：一天之中多次提交

（2）持續構建程式碼 (Build)：保證在任何時刻程式碼是可以繼續開發的

（3）持續部署程式碼(Deploy)：保證始終有一個可以部署的版本

（4）持續測試程式碼 (Test): 每次提交均執行單元測試，每天一次或數次整合測試, 每天一次或數次系統測試

（5）持續整合工具：Jenkins

【TDD測試驅動開發（Test-DrivenDevelopment）】

（1）測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能程式碼之前，先編寫單元測試用例程式碼，測試程式碼確定需要編寫什麼產品程式碼。

（2）TDD的基本思路就是通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。

（3）TDD首先考慮使用需求（物件、功能、過程、介面等），主要是編寫測試用例框架對功能的過程和介面進行設計，而測試框架可以持續進行驗證。（持續整合）

（4）主要針對設計開發流程的方法論，要求具有測試意識、自頂向下良好設計習慣的開發。

【ATDD驗收測試驅動開發（AcceptanceTest Driven Development）】

（1）同屬於TDD，作為開發人員的職責，通過單元測試用例來驅動功能程式碼的實現。

（2）在準備實施一個功能或特性之前，首先團隊需要定義出期望的質量標準和驗收細則，以明確而且達成共識的驗收測試計劃（包含一系列測試場景）來驅動開發人員的TDD實踐和測試人員的測試指令碼開發。

（3）TDD基礎上更進一步，要求開發人員從使用者的需求出發，強調如何實現系統以及如何檢驗。

【BDD行為驅動開發（BehaviorDriven Development）】

（1）行為驅動開發是一種敏捷軟體開發的技術，它鼓勵軟體專案中的開發者、QA和非技術人員或商業參與者之間的協作。

（2）主要是從使用者的需求出發，強調系統行為。BDD最初是由Dan North在2003年命名，它包括驗收測試和客戶測試驅動等的極限程式設計的實踐，作為對測試驅動開發的迴應。

（3）常見工具Rspec、Cucumber等，Cucumber 是一個能夠理解用自然語言描述的測試用例的支援行為驅動開發（BDD）的自動化測試工具，用Ruby編寫，支援Java和·Net等多種開發語言。

【常見的自動化測試架構（方法論）】

模組驅動測試、資料驅動測試、關鍵字驅動測試（“表格驅動測試”或“操作名測試”）、混合自動化測試、基於模型測試。

【模組驅動測試】

（1）來源於這樣一種程式設計策略，即遮蔽元件的內部實現，僅提供元件的對外抽象介面。如此下層的測試元件發生變動時，對上層自動化測試案例來說是透明的。

（2）使用獨立的小指令碼來對應待測試的模組、零件和子功能。這些不同層級的小指令碼按照一定規則組合成更大級別的測試，如此就實現了一個特定功能的自動化測試案例。

（3）模組驅動測試引入了抽象和封裝的原則，目的是提升自動化測試的可維護性和可擴充套件性。

【資料驅動測試】

（1）測試指令碼與測試資料放在同一個測試架構中，提供可重用的測試邏輯，目的是減少測試維護工作量和改善測試覆蓋率。

（2）測試輸入資料和測試結果資料都會被儲存在一個或者多個數據源、資料庫中，資料儲存格式和資料組織方式依賴於具體實現。

（3）測試資料與測試邏輯分離，當測試資料發生改變時，不會影響測試邏輯。同一個測試邏輯可以針對不同資料來進行測試，提高了測試邏輯的使用效率和可維護性。

【關鍵字驅動測試】

（1）也被稱為“表格驅動測試”或“操作名測試”，將自動化測試的建立過程分為兩個不同的階段：設計階段和實現階段。

（2）設計階段定義關鍵字：物件、行為、資料、檢查點等。

（3）實現階段依賴於具體使用的測試工具，自動化測試引擎提供設計階段定義的關鍵字，類似於“check”或“enter”，測試人員基於這些關鍵字來編寫測試案例，測試案例執行時會有一個驅動程式來讀取這些關鍵字，並執行相應的程式碼。

（4）優點：

A、在一個較長軟體維護週期內，顯著減少維護工作量，使得：測試案例簡潔、測試案列可讀性高、測試案列易於修改、新的測試案列可以很方便地複用已經存在的關鍵字

B、關鍵字可以跨越多個測試案例進行復用。

C、不依賴與某種語言或者某個工具。

D、讓員工集中精力在自己所擅長的地方，如：（設計）測試案列的構建需要專業領域知識-而不需要太多程式設計測試工具知識；（實現）關鍵字的實現需要豐富的測試工具、程式設計-而不需要太多的專業領域知識。

E、可以對自動化測試劃分抽象層級

（5）缺點：

A.建立自動化測試需要更長的時間

B.需要更長的學習、掌握週期

【混合自動化測試】

（1）該架構由核心資料驅動引擎、功能函式元件，以及支援庫所構成，由其他自動化測試框架綜合發展起來的，成功的自動化測試框架通常融合了“關鍵字驅動測試”和“資料驅動測試”。

（2）既擁有測試邏輯與測試資料相互分離的優點，又集成了關鍵字驅動的先進架構。

（3）這一架構會使得資料驅動指令碼更加簡潔，並減少執行時意外失敗的可能性。

（4）該架構可以實現一些純粹的“關鍵字驅動測試”難以實現的自動化測試任務。

【基於模型測試】

（1）目前只適合於功能不太複雜的軟體系統，適合於採用“基於模型設計”的軟體系統，在這種架構下，會有一個成熟的測試模型來描述測試資料的所有方面，以及測試案例和案例執行環境。通常這一測試模型是全部或者部分從待測試系統功能模型中提取出來的。

（2）測試模型描述了待測試系統的抽象行為，因此從測試模型中可以派生出功能測試案例。這些測試案例構成了抽象測試案例集，不過抽象測試案例集不能直接在待測試系統上執行。

（3）真正可以執行的測試案例集（可以與待測試系統進行互動），是從抽象測試案例集派生出來的。有些基於模型測試的測試工具，支援從模型（包含足夠資訊）產生可執行測試案例集，

（4）從模型派生出案例，可以有很多種方式，因此測試很多時候是依靠經驗去嘗試，並沒有固定的最佳方法。

（5）需要事先收集“測試需求、測試目標，使用者用例"因為他們包含待測試系統模型的資訊。測試案例集是從模型而非程式碼派生出來的，因此基於模型測試可以被視為某種黑盒測試。

【如何提高測試質量】

=> 理論實施：

（1）應用敏捷軟體測試等管理方法流程結合CMMI模型、ISO9126模型等對全過程質量進行管理

（2）制定合適的測試流程規範；

（3）制定合理的測試計劃；

（4）設計合適的測試方案；

（5）編寫的測試用例覆蓋到所有的需求；

（6）對測試執行過程進行監控；

（7）使用工具管理測試發現的缺陷；

（8）對缺陷進行統計分析，指導過程改進。

=> 措施：

（1）開展更加深入的測試，功能、介面、協議、白盒、資料庫

（2）開展更加全面的測試，功能、效能、安全。。。

（3）更加高效的測試，自動化測試的應用

（4）全團隊協作，產品、開發、測試、運維

（5）測試總結和改善、歷史測試結果的管理和分析挖掘

=> CMMI能力成熟度模型（20多個過程域，過程改進和能力評估）

（1）連續式：不完整、1已執行、2可重複管理、3已定義、4量化管理級、5優化級

（2）階段式：初始級、2可重複管理級、3已定義級、4量化管理級、5優化級

=> 經典ISO/IEC9126軟體質量模型

（1）三個不同的角度:外部質量、內部質量、使用的質量

（2）質量的6個型別：功能性、可靠性、易用性、效率、可維護性、可移植性

轉載請標明出處，原文地址：http://blog.csdn.net/w565911788/article/details/47660625