## 軟件開發過程模型 在軟件開發的七年實踐中，人們總結了很多軟件開發模型用來描述和表示一個復雜的開發過程，如：  軟件測試與軟件的開發模式有著緊密的聯系，作為一名測試人員，應該充分理解軟件的開發模式，以便找準自己在其中的位置，從而發揮自身的價值。 ### 1 瀑布模型  1、是線性模型的一種，在所有模型中占有重要地位，是所有其他模型的一個基礎。 2、每一個階段執行一次，按線性順序進行軟件開發。 測試的切入點： 測試階段處于軟件實現后，必須在代碼完成后留出足夠的時間給測試活動，否則將導致測試不充分，很多問題到項目后期才暴露 #### 瀑布模型的優缺點 優點： 1 開發的各個階段比較清晰。 2 強調早期計劃及需求調查。 3 適合需求穩定的產品開發。 缺點： 依賴于早期的需求調查，不適應需求的變化。 單一流程不可逆。 風險往往延至后期才顯露，失去及早糾正的機會。 問題在項目后期才開始暴露。 前面未發現的錯誤會傳遞并擴散到后面的階段，可能導致項目失敗。 改良： 沿用瀑布模型的線性思想，細化了各個階段，在某些重要關注的階段之間摻入迭代的思想。 ### 2 快速原型模型 在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。 第一步是建造一個快速原型，實現用戶與系統的交互，用戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足用戶的要求，開發人員可以確定用戶的真正需求是什么。 第二步是在第一步的基礎上開發出用戶滿意的軟件產品。  #### 快速原型模型的優缺點 優點： 克服瀑布模型的缺點，更好地滿足用戶的需求并減少由于軟件需求不明確帶來的項目開發風險。適合預先不能確切定義需求的軟件系統的開發。 缺點： 不適合大型系統的開發（適合開發小型的、靈活性高的系統）。前提要有一個展示性的產品原型，因此在一定程度上可能會限制開發人員的創新。 ### 3螺旋模型 螺旋模型將開發過程分為幾個螺旋周期，每個螺旋周期大致和瀑布模型相符合，螺旋模型沿著螺旋線旋轉，即在坐標的4個象限上分別表示了4個方面的活動，如圖所示：制定計劃，風險分析，實施開發，客戶評估  ## 軟件測試簡介 每個系統的成型，上線都離不開測試,軟件測試是伴隨著軟件的產生而產生的。早期的軟件開發過程中軟件規模都很小、復雜程度低,軟件開發的過程混亂無序、相當隨意,測試的含義比較狹窄,開發人員將測試等同于“調試”,目的是糾正軟件中已經知道的故障,常常由開發人員自己完成這部分的工作。對測試的投入極少,測試介入也晚,常常是等到形成代碼,產品已經基本完成時才進行測試。到了上世紀80年代初期,軟件和IT行業進入了大發展,軟件趨向大型化、高復雜度,軟件的質量越來越重要。軟件測試概念 要點 1 軟件測試與軟件工程息息相關，軟件測試是軟件工程組成中不可或缺的一部分。 2 在軟件工程、項目管理、質量管理得到規范化應用的企業，軟件測試也會進行得比較順利，軟件測試發揮的價值也會更大。 3 要關注軟件工程、質量管理以及配置管理與軟件測試的關系；在不同的開發模式下，如何進行軟件測試。 ## 軟件測試的歷史及定義 * **1957年之前－調試為主(Debugging Oriented)** * **1957–1978－證明為主(Demonstration Oriented)** * **1979–1982－破壞為主(Destruction Oriented)** * **1983–1987－評估為主(Evaluation Oriented)** * **1988–至今－預防為主(Prevention Oriented)** 調試為主 20世紀50年代，計算機剛誕生不久，只有科學家級別的人才會去編程，需求和程序本身也遠遠沒有現在這么復雜多變，相當于開發人員一人承擔需求分析，設計，開發，測試等所有工作，當然也不會有人去區分調試和測試。然而嚴謹的科學家們已經在開始思考 “怎么知道程序滿足了需求？”這類問題了。證明為主 1957年，Charles Baker在他的一本書中對調試和測試進行了區分： 調試(Debug)：確保程序做了程序員想它做的事情 測試(Testing)：確保程序解決了它該解決的問題 這是軟件測試史上一個重要的里程碑，它標志測試終于自立門戶師出有名了。當時計算機應用的數量，成本和復雜性都大幅度提升，隨之而來的經濟風險也大大增加，測試就顯得很有必要了，這個時期測試的主要目就是確認軟件是滿足需求的，也就是我們常說的“做了該做的事情”。 破壞為主 1979年，《軟件測試的藝術》 (The Art of Software Testing)第一版問世，這本書是測試界的經典之作。書中給出了軟件測試的經典定義： 測試是為發現錯誤而執行程序的過程。 這個觀點較之前證明為主的思路，是一個很大的進步。我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會使測試更加全面，更容易發現問題。 評估為主1983年，美國國家標準局提出了測試界很有名的兩個名詞：驗證(Verification)和確認(Validation)。人們提出了在軟件生命周期中使用分析，評審，測試來評估產品的理論。軟件測試工程在這個時期得到了快速的發展：出現測試經理(test manager)，測試分析師(test analyst)等職稱 開展正式的國際性測試會議和活動 發表大量測試刊物發布相關國際標準以上種種都預示著：軟件測試正作為一門獨立的，專業的，具有影響力的工程學發展起來了。 預防為主 預防為主是當下軟件測試的主流思想之一。STEP(Systematic Test and Evaluation Process)是最早的一個以預防為主的生命周期模型，STEP認為測試與開發是并行的，整個測試的生命周期也是由計劃，分析，設計，開發，執行和維護組成，也就是說，測試不是在編碼完成后才開始介入，而是貫穿于整個軟件生命周期。我們都知道，沒有100%完美的軟件，零缺陷是不可能的，所以我們要做的是：盡量早的介入，盡量早的發現這些明顯的或隱藏的bug，發現得越早，修復起來的成本越低，產生的風險也越小 ## 軟件測試的測試對象： 軟件測試的對象不僅僅是程序測試,軟件測試的對象包括：程序、數據、文檔。目標程序和源程序都屬于程序。 ## 五大要素和兩個目標：  五大要素有：質量、人員、資源、流程、技術。 其中最主要的是軟件質量，其他四個要素都是為質量服務的。 其次是人員，決定了技術，資源，流程，以及配置和使用。 技術包含了：軟件測試技術、軟件測試方法、使用的工具。技術是手段。 流程：測試計劃，測試用例，測試執行，測試報告。有一些進入進出的標準（規范性，對軟件測試做一個規范的要求）。 資源：測試所需要的硬件設備、網絡環境、測試設備、測試時間（周期）。 注意：人不是資源。 目標： ①提升測試覆蓋率-> 能夠有效的保證軟件的質量 ②提升測試效率->能夠使我們更好地完成軟件測試 ## 軟件測試所遵循的原則 一、測試顯示缺陷的存在，但不能證明系統不存在缺陷。 經過軟件測試，可以發現軟件中的故障；但是經過軟件測試，不能保證軟件就沒有故障了。 二、窮盡測試是不可能的，應設定及時終止的條件。 三、測試應該盡早進行  四、缺陷具備群集特性 越是發現問題多的模塊，越是需要重點測試的對象 五、測試的殺蟲劑悖論 在測試中，如果采用同樣的測試用例，同樣的測試方法。多次重復的測試某一個模塊，最后就不能再發現新的缺陷。所以說，測試用例和測試方法應該不定期的評審修改，并且增加不同的測試方法和用例來測試不同的部分，從而更多的發現軟件的缺陷。 六、測試的二八原則 測試時間和資源往往是有限的，要找出所有的缺陷是不可能的，這時我們需要遵循二八原則。 把80%的時間或者資源用在20%的重點模塊上，重點測試模塊中20%的重要模塊。來達到測試效率和資源配置的最佳的比例。 七、測試活動依賴于測試背景 針對不同的測試背景針對的活動是不同的，比如：電信級的軟件對性能、大并發量的訪問會有更高的要求。而金融，銀行系統相關的軟件，對安全性能要求更高。 ## 設計系統測試計劃需要參考的項目文擋有哪些？ 【軟件需求】是軟件開發之前做好的，軟件開發是根據這個做的，那么軟件測試自然也需要參考該文件 【迭代計劃】是軟件的某個周期的計劃，自然也需要參考 【可行性】是軟件開發前做好，用于證明該計劃可行的，沒有必要參考 ## 測試的目的 （1）測試是程序的執行過程，目的在于發現錯誤； （2）一個好的測試用例在于能發現至今未發現的錯誤； （3）一個成功的測試是發現了至今未發現的錯誤的測試； ## 測試模型 隨著測試過程的管理和發展，測試人員通過大量的實踐，從而總結出了不少測試模型，如常見的V模型、W模型、H模型等。這些模型與開發緊密結合，對測試活動進行了抽象，成為了測試過程管理的重要參考依據。 ### V模型 簡介： RAD（Rap Application Development，快速應用開發）模型是軟件開發過程中的一個重要模型，由于其模型構圖形似字母V，所以又稱軟件測試的V模型，V模型大體可以劃分為以下幾個不同的階段步驟：需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。 要點 1 V模型是最具有代表意義的測試模型，最早是由Paul Rook在20世紀80年代后期提出，由英國國家計算機中心文獻中發布，旨在改進軟件開發的效率和效果； 2 V模型推出之前，人們通常把測試過程作為在需求分析、概要設計、詳細設計、編碼全部完成之后的一個階段，盡管當時已經出現了測試工作會占用這個項目周期一半的時間，但是大多數人認為測試只是一個收尾工作；V模型在這個時候推出，就是為了改變之前行業的普遍認識。 3 V模型本身是軟件開發中瀑布模型的變種，它反映了測試活動與分析和設計的關系。 4 V模型標明了測試過程中本身存在的不同階段，從左到右，描述了開發過程和測試過程間的階段對應關系。  1需求分析：用戶需求、業務需求、需求規格說明書 2概要設計：系統架構、模塊劃分、模塊與模塊之間的接口。 3 詳細設計：模塊內部實現的邏輯和方法。 4編碼：實現上面的設計。 5單元測試：檢測代碼的開發是否符合詳細設計的要求。 6集成測試：檢測此前測試過的各組成部分是否能完好地結合到一起。 7系統測試：檢測已集成在一起的產品是否符合系統規格說明書的要求。 8驗收測試：檢測產品是否符合最終用戶的需求。 #### V模型的優點 測試V模型即包含了底層測試又包含了高層測試； 底層測試：檢驗源代碼質量的測試，如：單元測試； 高層測試：檢驗整個系統的需要，如：系統測試； V模型清楚地標識出了軟件開發的階段。 它采用自頂向下逐步求精的方式把整個開發過程分成不同的階段，每個階段的工作都很明確，因此便于控制開發過程。當所有的階段都完成之后，該軟件的開發過程也隨之結束。 #### V模型的缺點 V模型一大缺點正是它自身的順序性所導致的。到了測試階段，程序已經完成，錯誤已經產生，很多前期的錯誤一直到測試階段才發現，甚至無法發現，往往無從修改了。 同時實際的開發過程中，在需求階段很難把用戶的需求完全明確下來，因此，當需求變更時將會導致階段反復，而且都要重復需求、設計、編碼、測試等過程，返工量非常大，模型靈活性比較低。 #### V模型改進  ### W模型 ?IEEE std1012-1998《軟件驗證和確認（V&V）》的原則中提出了在軟件的需求和設計階段也應有測試活動，并且提出了相應的原則； ?W模型由Evolutif公司提出：開發一個V，測試一個V，組合的W模型； ?測試伴隨著整個軟件開發周期，并且測試的對象不僅僅是程序，需求和設計同樣要測試。  #### W模型的優點： 開發強調測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求和概要設計同樣要測試； 更早地接入測試，可以發現開發初期的缺陷，那么可以用更加低的成本進行缺陷修復。 同樣是分階段的工作，便于控制項目過程。 #### W模型的缺點： 依賴于軟件開發和軟件測試依然保持一前一后的線性關系，依然無法支持迭代、自發性和需求等變更調整； 對于當前很多項目，在執行的過程中根本不產生文檔，那么W模型基本無法適用； 使用起來技術復雜度很高，對于需求和設計的測試要求很高，實踐起來困難。 ### H模型 #### ?H模型誕生背景 人們發現雖然軟件開發中需求、設計、編碼等活動被分階段執行、但是實踐中，他們并不是完全串行的，它們之間更多時候是交叉進行的，更多的是迭代執行。 為了解決上面的問題，有專家專門提出了H模型，它將測試活動完全獨立出來，形成一個完全獨立的流程，同時將測試準備和測試執行也清晰表現出來。 #### 測試流程 測試準備：所有測試執行活動的準備；判斷是否到測試就緒點； 測試就緒點：測試準入準則，即是否可以開始執行測試的條件； 測試執行：具體的執行測試的程序。 其他流程 具體開發中的流程，如：設計流程  #### H模型優缺點 H模型的優點： 開發的H模型揭示了軟件測試除測試執行外，還有很多工作； 軟件測試完全獨立，貫穿整個生命周期，且與其他流程并發進行； 軟件測試活動可以盡早準備、盡早執行，具有很強的靈活性； 軟件測試可以根據被測物的不同而分層次、分階段、分次序的執行，同時也是可以被迭代的。 H模型的缺點： 管理型要求高：由于模型很靈活，必須要定義清晰的規則和管理制度，否則測試過程將非常難以管理和控制； 技能要求高：H模型要求能夠很好的定義每個迭代的規模，不能太大也不能太小； 測試就緒點分析困難：測試很多時候，你并不知道測試準備到什么時候是合適的，就緒點在哪里，就緒點的標準是什么，這就對后續的測試執行的啟動帶來很大困難； 對于整個項目組的人員要求非常高：在很好的規范制度下，大家都能高效的工作，否則容易混亂。例如：你分了一個小的迭代，但是因為人員技能不足，使得無法有效完成，那么整個項目就會受到很大的干擾。