軟體開發流程(一)測試模型篇
「軟體工程」（Software Engineering）是軟體開發領域裡對工程方法的系統應用。
1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫「軟體危機」的對策。在那次會議上第一次提出了軟體工程（software engineering）這個概念。
研究和應用如何以系統性的、規格化的、可定量的程序化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。
它涉及到程式設計語言、資料庫、軟體開發工具、系統平台、標準、設計模式等方面。
ISO/IEC TR 19759:2015 Software Engineering — Guide to the software engineering body of knowledge (SWEBOK) ，
由軟體工程知識體係指南定義的15個知識領域：
l 軟體需求（Software Requirements）
l 軟體設計（Software Design）
l 軟體建構（Software Construction）
l 軟體測試（Software Testing）
l 軟體維護（Software Maintenance）
l 軟體配置管理（Software Configuration Management）
l 軟體工程管理（Software Engineering Management）
l 軟體工程流程（Software Engineering Process）
l 軟體工程模型與方法（Software Engineering Models and Methods）
l 軟體品質（Software Quality）
l 軟體工程專業實踐（Software Engineering Professional Practice）
l 軟體工程經濟學（Software Engineering Economics）
l 計算基礎（Computing Foundations）
l 數學基礎（Mathematical Foundations）
l 工程基礎（Engineering Foundations）
「軟體開發流程」（Software Development Process）
「軟體開發流程」是影響一個軟體開發速度與品質管理的重要項目。
l Waterfall 瀑布式開發 軟體開發流程與步驟的一種理論模式
由1970年温斯頓·羅伊斯（Winston Royce）提出完整的描述。
software development life cycle 軟體開發生命週期（SDLC）
Ø 缺點：
每一項目都須執行完畢後，才能接續下一項目依序進行，資源分配分散
SDLC耗費較多時間完成，若發生延遲會嚴重影響專案進度
已進行開發後，若需變更內容，須重新進行評估，依照上述步驟重新調整，缺乏靈活的應變性
Ø 優點：因流程嚴謹且重視文件撰寫，嚴格遵循瀑布流的軟體在結構穩定性與品質上非常優良
l V 模型
是一種延伸自瀑布模型的軟體開發過程，反應了測試活動與分析和設計的關聯性
由Paul Rook 在20 世紀80 年代後期提出的，目的是改進軟體開發的效率和效果。
由左側需求分析及設計對應右側測試項目，於專案前期規畫時增加測試計畫的對應，以利於控管規劃內容滿足測試及驗收的對應關係，使開發階段儘可能符合最終客戶的要求，提高開發效率及質量，減少發生錯誤及異動軟體內容的可能性，降低後期因調整產生的成本。
Ø 適用於：明確需求定義的軟體開發專案，可進行區分模組化的系統。
Ø 不適用於：需求變動性大、範圍難以確認或需多方協同開發方式的系統。
l W 模型
W模型由兩個V字型模型組成，分別代表測試與開發過程
由Evolutif公司提出，相對於V模型，W模型增加了軟件開發各階段中同步進行的驗證和確認。在生命週期的早期執行測試，測試階段於專案開發時程往前推移。
Ø 優點：測試與開發過程並行以利提前規避問題、可預估項目難度和降低測試風險
Ø 缺點：複雜的跟踪進度、需耗費較多測試資源
l H 模型
在H模型中，軟體測試的過程活動完全獨立，形成了一個完全獨立的流程，貫穿於整個產品的周期，與其他流程併發進行。
l 測試項目不僅包含開發內容，也可進行相關工作的驗證(例：環境、傳輸、連線、監控…等等)
l 將準備測試及執行測試的階段時間往前推移
l 依照受測目標的不同區分層次，不同層次的測試可按照順序先後進行，也可反覆進行
Ø 優點：靈活調整機動性高、專注一次性測試流程的評估和進行、可產出有效的測試軌跡以供追蹤、可利用於快速迭代開發方式
Ø 缺點：測試資源分配掌控較為複雜、於開發每個階段都需要安排測試項目、需要較為專業的測試人員進行
l X 模型
將單獨編碼和測試連結在一起，之後經過不斷的整併重新進行關聯性測試，重複上述流程直到完成開發內容後進行交付。整合後也可採取非測試計畫內的探索性測試。
是由Marick先提出的一些概念，而後RobF.Goldsmith先生在自己的文章里將其思想定義為X模型，X模型其目標是增量V模型的配套方法。
Ø 優點：將測試和開發時間重疊可提早發現問題、多面相測試方式可大幅降低風險、可利用於快速迭代開發方式
Ø 缺點：需耗費大量人力資源、依據整合的次數會增加測試時間、需要較為專業的測試人員進行
l X模型的(左邊)針對單獨的程式片段，建立測試計畫進行測試。
l X模型(右邊)將各片段整合成完整的內容後，再次建立測試計畫進行測試。
l 完成所有整合測試後，可進行封裝交付。
l 可執行探索性測試exploratory testing非計劃內的測試方式。
參考資料：
https://zh.wikipedia.org/wiki
https://www.iso.org/standard/67604.html
https://www.itread01.com/content/1547738306.html
