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