一、 軟體開發模型
1 為什麼學習軟體開發模型
- 了解開發能夠更好的有針對性的做好測試。
2 什麼是軟體開發模型
- 軟體開發生命周期模型是軟體産品從最初構思到退役的過程。
3 常見的開發模型
- 大爆炸模型
- 邊寫邊改模型
- 瀑布模型
- 螺旋模型
- 靈活開發模型
3.1 大爆炸模型
3.1.1 直接沖過河去的模型
- 一大堆東西（人力和資金）放在一起，巨大的能量釋放，要麼産生了優秀的産品，要麼是一堆廢品。
3.1.2 特點
- 大爆炸模式是最簡單的軟體開發模式，計劃、進度安排和正規開發過程都幾乎沒有，所有精力都花在開發軟體和編寫代碼上；
- 一般，大爆炸模式幾乎沒有測試，即使有也要擠在産品釋出前，通常都會避免在此模式下進行測試。
3.2 邊寫邊改模型
3.2.1 摸着石頭過河的模型
- 項目小組在未刻意采用其他開發模式時預設的開發模式。
- 它在大爆炸模式基礎上更進了一步，至少考慮到了産品需求。
- 開發小組通常最初隻有粗略的想法，接着進行一些簡單的設計，然後開始漫長的來回編寫、測試和修改缺陷的過程，直到覺得足夠才釋出産品。
- 此種模式是測試期間最有可能碰到的模型。
3.2.2 特點
- 此種模式沒有計劃和文檔編制，項目能夠迅速展現成果，是以比較适合用完就扔的項目；
- 與大爆炸模式類似，測試在邊寫邊改模式中未特别強調，但是在編寫代碼和修複缺陷過程中舉足輕重；
- 軟體測試會陷入無休止的循環往複，因為每天都可能在測試新版本。
3.3 瀑布模型
3.3.1 制定周密計劃的模型
- 1970 年，溫斯頓•羅伊斯（WinstonRoyce）提出，直到 80 年代早期，它一直是唯一被廣泛采用的軟體開發模型。
- 采用瀑布模式的項目從最初的構思到最終産品要經過一系列步驟。每一個步驟結束時，寫好文檔，項目小組組織審查，并決定是否進入下一步。如果項目未準備好進入下一步，就停滞下來直到準備好。
3.3.2 特點
- 從測試的角度看來，瀑布模式比截至到目前為止的其他模式更有優勢。
- 瀑布模式所有一切都有完整細緻的說明。當軟體送出到測試小組時，所有細節都已确定并有文檔記錄，而且實作在軟體之中。由此，測試小組得以制定精确的計劃和進度。
- 測試對象非常明确，即程式。
- 在瀑布模型中，測試被認為是在軟體開發過程的後期階段進行的“一次性”活動，這帶來一個巨大的缺點，因為測試僅在最後進行，是以一些根本性問題可能出現在早期，但是直到準備釋出産品時才可能發現。
3.4 螺旋模型
3.4.1 計劃趕得上變化的模型
- 1988 年，Barry Boehm（巴利•玻姆）提出。
- 開始不必詳細定義所有細節，從小開始，定義重要功能，努力實作這些功能，接收客戶回報，然後進入下一階段，重複上述過程，直至得到最終産品。
- 特别适合于大型複雜系統。
3.4.2 特點
- 螺旋模式中包含了一點瀑布模式（分析、設計、開發和測試的步驟）、一點邊寫邊改模式（螺旋模式的每一次）和一點大爆炸模式（從外界觀察）。加上該模式發現問題早、成本低的特點，可以算做相當好的開發模式。
- 軟體測試員喜歡該模式。因為通過參與最初設計的設計階段，可以盡早地影響到産品，可以把産品的來龍去脈弄得很清楚；并且在項目末期，不至于最後一分鐘還在匆匆忙忙地進行全面測試。軟體測試員的測試一直都在進行，是以最後一步隻是一個驗證表面所有部分都沒有問題。
3.5 靈活開發模型
3.5.1 起源
- 另外一些名稱：如快速原型、極限程式設計或進化開發等。
- 2001 年初，在猶他州的 Snowbird，由于看到很多軟體開發團隊陷入了不斷增長的過程的泥潭，一批業界專家聚集在一起概括出了一些可以讓軟體開發團隊具有輕量化、快速工作、響應變化能力的價值觀和原則，他們稱自己為“靈活聯盟”。
3.5.2 靈活宣言
- 靈活聯盟在随後幾個月，他們建立了一份價值觀聲明，也就是靈活聯盟宣言。
- 這不是一份抽象的方法論集合，并沒有提供任何死闆僵化的開發方法和複雜的技術結構層次，而更像是一份針對客戶和開發個體的箴言警句集。
1、通過過程和工具了解個人和交流的作用
2、通過全面的文檔了解運作的軟體
3、通過合同和談判得到客戶的協作
4、在計劃的執行中做出對變更的響應
- 靈活開發的核心思想是：以人為本，适應變化。
3.5.3 特點
- 靈活開發提倡疊代式和增量式的開發模式，并強調測試在其中的重要作用。
- 靈活開發是以使用者為中心、以客戶需求為導向的開發過程，在此過程中随時做好“迎接變化”的準備，客戶是靈活的關鍵環節。
- 靈活開發沒有單一固定的開發方法或過程，很多快速的開發模式都可以看作是靈活。但這些模式都有三個共同點：依賴客戶的參與、測試驅動以及緊湊的疊代開發周期。
二、 軟體測試模型
1 為什麼學習測試模型
- 指導測試過程。
2 常見的測試模型
- V 模型
- W 模型
- H 模型
- X 模型
- 前置模型
- 靈活測試模型
2.1 V 模型
2.1.1 V 模型的提出和過程
- 1980 年，Paul Rook（保羅•洛克）提出，旨在改進瀑布模型的開發效率和效果。
- “V”的左端表示傳統的瀑布開發模型，而“V”的右端表明相應的測試階段。
2.1.2 優點
- V 模型明确地将測試分為不同的級别或階段。
- 每個階段都與開發的各階段相對應。
- V 模型的測試政策包括低層測試和高層測試，低層測試是為了源代碼的正确性，高層測試是為了整個系統滿足使用者的需求。
2.1.3 缺點
- 測試是開發之後的一個階段。實際應用中容易導緻需求階段的錯誤一直到最後系統測試階段才被發現。
- 測試的對象就是程式本身。忽視了測試活動對需求分析，系統設計等活動的驗證和确認的功能，直到後期的驗收測試才被發現。
- 過程是線性的、順序的，不能反複和疊代。
2.2 W 模型
2.2.1 W 模型的提出和過程
- 基于盡早和不斷測試的原則，W 模型既強調了測試方案設計，也強調了測試執行。
2.2.2 優點
- W 模型從 V 模型演化過來，實際上開發是 V，測試是并行的 V，測試與開發同步進行，有利于盡早地全面的發現問題。
- 測試伴随整個軟體開發周期。
- 測試的對象不僅僅是程式，需求、設計等同樣要測試。
2.2.3 缺點
- W 模型中，需求、設計、編碼等活動被視為串行的，同時，測試和開發活動也保持着一種線性的前後關系，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支援疊代的開發模型。
2.3 H 模型
2.3.1 H 模型的提出和過程
- 真正的測試級别之間不存在嚴格的次序關系，各階段間可以反複觸發、疊代、增量。為了解決 V 模型和 W 模型存在的問題，有專家提出了 H 模型。
2.3.2 特點
- 它将測試活動完全獨立出來，形成一個完全獨立的流程，将測試準備活動和測試執行活動清晰地展現出來。測試貫穿産品整個生命周期，與其他流程并發地進行。
- 軟體測試不僅僅指測試的執行，還包括很多其他的活動（計劃、需求分析、用例設計、環境搭建、送出缺陷、評估總結等）。
- 當某個測試時間點就緒時，軟體測試即從測試準備階段進入測試執行階段。
- 軟體測試要盡早準備，盡早執行。
- 軟體測試是根據被測物的不同而分層次進行的。不同層次的測試活動可以是按照某個次序先後進行的，但也可能是反複的。
2.4 靈活測試模型
2.4.1 極限程式設計
20 世紀 90 年代 Kent Beck 設計了一種名為極限程式設計（eXtreme Programming，XP）的新型軟體開發方法。
2.4.2 極限測試
- 為了滿足 XP 的流程和思想，開發人員使用了極限測試方法，該方法強調連續測試。
- 測試在 XP 中的地位非常重要，是以需要首先建立單元（子產品）測試和驗收測試，然後才能建立代碼庫。這種形式的測試稱為極限測試（eXtreme Testing，XT）。
- XP 模型需要客戶參與，高度依賴子產品的單元和驗收測試。
對任何一個遞增的代碼變更，開發人員都必須進行單元測試，以確定代碼庫滿足其規格說明的要求。
單元測試完成後，使用者進行驗收測試。
2.4.3 基于 XP 的項目的步驟
- 程式員與客戶會晤，決定産品需求并建立使用場景。客戶不在場時，程式員進行會晤，将需求分解為獨立的任務，并估計完成每項任務所需的時間。程式員向客戶送出任務清單和時間估計，并要求客戶産生一個功能優先級清單。
- 每一對程式員依據應用程式的規格說明，對其程式設計任務生成單元測試用例。
- 程式設計小組依據程式員具備的能力，将任務配置設定給結對的程式員。兩位程式員協同工作，在同一台機器開發代碼庫，對代碼進行實時檢查。所有代碼歸所有程式員所有。遵循一緻的系統隐喻，所有的代碼看上去都一緻。每一對程式員完成其任務，編寫出代碼庫。每一對程式員在所有單元測試通過之前，不斷修改和重測他們的代碼。所有的結對程式員每天都整合、內建他們的代碼庫。程式設計小組釋出應用程式的一個預覽版本。
- 客戶進行驗收測試，要麼确認該應用程式，要麼送出一份報告指出存在的 bug或不足。程式員在驗收測試成功的基礎上釋出一個産品版本。開發人員和程式設計小組可以随時接觸客戶，這樣可以快速、準确地解決問題。
- 程式員根據最新的經驗更新時間估計。
- 不允許加班。如果每周都全力工作了 25 小時，就不需要加班。在重大釋出前的一星期例外。
2.4.4 靈活測試的要點總結
- 靈活測試是協同測試的一種形式，程式員結對程式設計，程式員分飾測試員角色，靈活測試是連續測試。
- 靈活測試側重單元測試和驗收測試。單元測試的過程是先設計單元測試用例，然後進行編碼，之後執行測試。
- 靈活測試強調客戶參與，單元測試通過之後代碼內建到代碼庫中，再由客戶進行驗收測試。
2.5 測試模型的使用
- 不同的軟體生命周期模型需要使用不同的測試方法。
- 應盡可能地去應用模型中對項目有實用價值的方面，但不強行地為使用模型而使用模型，否則也沒實際意義。
- 各種模型可以适當結合。