軟體測試：V模型/X模型/H模型
在軟體測試方面，V模型是最廣為人知的模型，儘管很多富有實際經驗的測試人員還是不太熟悉V模型，或者其它的模型。V模型已存在了很長時間，和瀑布開發模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質疑。在《軟體測試：不可忽略的階段》中已經詳細討論了V模型，這裡只作一個概要的介紹。
V模型中的過程從左到右，描述了基本的開發過程和測試行為。V模型的價值在於它非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係。
user posted image
在V模型中，單元測試是基於程式碼的測試，最初由開發人員執行，以驗證其可執行程式程式碼的各個部分是否已達到了預期的功能要求；
整合測試驗證了2個或多個單元之間的整合是否正確，並有針對性地對詳細設計中所定義的各單元之間的介面進行檢查；
在所有單元測試和整合測試完成後，系統測試開始以客戶環境模擬系統的執行，以驗證系統是否達到了在概要設計中所定義的功能和效能；
最後，當技術部門完成了所有測試工作後，由業務專家或使用者進行驗收測試，以確保產品能真正符合使用者業務上的需要。
儘管很多人對V模型表示了否定，但很少有人真正詳細地討論這些問題。Brian Marick（《The Craft of Software Testing (Prentice Hall, 1995)》一書的作者）曾如此表示。在STAR2000 (Software Testing Analysis and Review) 東部會議上，Marick曾經和Dorothy Graham（本系列文章的另一位作者）進行過一場論爭，並在其個人網站www.testing.com上對V模型提出過一些中肯的反對意見。
X模型
Marick曾提出過一些觀點和意見，其中首先是Marick不建議要建立一個替代模型。這裡我很冒昧地引用了一些 Marick的想法，並重新經過組織，形成了“X模型”。其實並不是為了和V模型相對應而選擇這樣的名字，而是由於其它一些原因：X通常代表未知，而 Marick也認為他的觀點並不足以支撐一個模型的完整描述，但其中已經有一個模型所需要的一些主要內容，其中也包括了象探索性測試（exploratory testing）這樣的亮點。我還需要在使用文字方面也向Marick道歉，因為認同Marick觀點的無疑大多屬於X一代（X一代）。另外，我勾畫了一張X形狀的示意圖，我相信該圖能夠很好地以另一種表達形式來體現Marick的觀點。
由於X模型從沒有被文件化，其內容一開始需要從在V模型的相關內容中進行推斷，這在Marick的相關文章中已有體現。這裡關於X模型的論述比較簡短，因為它還沒有完全從文字上成為V模型的全面擴充套件，而且我不想在這裡重複在《軟體測試：不可忽略的階段》文章中所提到的很多測試技術的概念。
Marick對V模型的最主要批評是V模型無法引導專案的全部過程。他認為一個模型必須能處理開發的所有方面，包括交接，頻繁重複的整合，以及需求文件的缺乏等等。
解決交接和頻繁整合的週期的問題
Marick 認為一個模型不應該規定那些和當前所公認的實踐不一致的行為。我也很認同這一點。X模型的左邊描述的是針對單獨程式片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過整合最終合成為可執行的程式。(右上半部分），這些可執行程式還需要進行測試。已通過整合測試的成品可以進行封版並提交給使用者，也可以作為更大規模和範圍內整合的一部分。多根並行的曲線表示變更可以在各個部分發生。
由上圖中可見，X模型還定位了探索性測試（右下方）。這是不進行事先計劃的特殊型別的測試，諸如“我這麼測一下結果會怎麼樣？”，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。Marick雖然沒有對此進行明確的說明，但一定很樂意看到該方法的界定。
然而，關注於這樣的低級別的行為可能會引起不同的議論。一個模型和一個單獨的專案計劃有所不同。模型不應該描述每個專案的具體細節，模型應該對專案進行指導和支援。當然，程式碼的交接也可以簡單地認為是一種整合的形式。而V模型也並沒有限制各種建立週期的發生次數。
H模型
h模型的示意圖僅僅演示了在整個生產週期中，某個（測試）層次上的一次測試“微迴圈”。圖中的“其他流程”可以是任意的開發流程，例如設計流程和編碼流程，也可以是其他非開發流程，甚至是測試流程自身。向上的三
角箭頭表示，在某個時間點，由於“其他流程”的進展而（由於先後關係）引發或者（由於因果關係）觸發了測試就緒點，這個時候，只要測試準備活動完成，測試執行活動就可以（或者說，需要）進行了。
概括而言，h模型揭示了
1、 軟體測試不僅僅指測試的執行，還包括很多其他的活動；
2、 軟體測試是一個獨立的流程，貫穿產品的整個週期，與其他流程併發的進行；
3、 軟體測試要儘早準備，儘早執行；
4、 軟體測試根據被測物的不同是分層次的，不同層次的測試活動可以是按照某個次序先後進行的，也可能是反覆的。
採用h測試模型的三個理由
1、有利於測試的分工，從而降低成本，提高效率。
首先，h模型強調軟體測試準備和測試執行分離。準備階段和執行階段有不同的測試活動，例如，測試準備活動，包括測試需求分析、測試計劃、測試分析、測試編碼、測試驗證等等，而測試執行活動，則包括測試執行、測試報
告、測試分析等等。準備階段和執行階段有不同的工作側重點，不同的測試活動也需要不同的知識和技能。顯而易見，測試的設計人員比執行人員有更高的能力要求，不同的崗位可以聘用不同的人員。如果一個測試設計人員同時
被指派去執行測試，那既是人力資源的浪費，也可能挫傷設計人員的創造性合積極性。所以，軟體測試分工帶來的第一個直接好處就是降低人力成本。第二個直接好處就是提高效率。分工帶來的間接的長期的好處是，軟體測試可
以成為一個有職業前景的職位，這有利於吸引人才以此作為自己的職業生涯，從而形成軟體測試領域的人力積累和良性迴圈。
2、有利於認識到測試的複雜性，從而贏得重視和尊重。
H模型可以促使人們充分認識到軟體測試的複雜性。這兒的複雜不是指技術上的複雜，而是指過程上的複雜。正如傳統的軟體開發被簡化為程式設計一樣，軟體測試也常常被簡化為執行一下被測的軟體，觀察是否有異常的執行結果
。軟體測試也有不同的階段，有不同的活動，而且這些階段和活動要被組成一個系統才能有效的運作。沒有組織的，非結構化的軟體測試除了浪費時間和金錢外，幾乎不可能有實質性的產出。認識到複雜性才可能得到足夠的重視
和必要的尊重。重視主要來自於管理層，而尊重則主要來自於平行的其它流程的人員，例如程式設計人員。儘管測試流程是一個獨立的流程，但它必須被置於整個軟體生產的流程系統中，作為一個有機的組成部分，並與其它流程有效
的互動，才可能發揮作用。
3、有利於瞭解測試投入的去向，從而得到測試效益的公正評判。
第三個理由與一個長期存在的“測試怪圈”有關。測試經理總是抱怨測試上投入不夠；測試人員要麼被看作是“無所事事”，要麼被看作“忙而無功”；而管理層則因為測試上的投入沒有一個可視的結果而拒絕加大投入；更糟
糕的是，使用者在投訴軟體的質量問題，組織的聲譽和利潤都每況愈下。H模型並不能扭轉這種糟糕的局面，但它有助於跟蹤測試投入的流向，例如，在各個測試活動上的投入分別有多少，比例是否合理，哪些是用於測試準備的，
而如果由於其它流程的差錯導致重做準備，那麼浪費的投入有多少。在h模型中，測試是一個有組織的、結構化的獨立流程，既保證了自身的有序和結構清晰，也保證了流程之間的“介面”清晰。這樣，軟體測試就不是一筆糊塗
帳，才可能得到公正的投入-產出的評判，軟體測試才可能避免成為“出氣筒”和“替罪羊”的“宿命”。
相關推薦
軟體測試：V模型/X模型/H模型
X模型的目標是彌補V模型的一些缺陷。X模型真的能解決測試過程各方面的問題，例如交接、經常性的整合？ 在軟體測試方面，V模型是最廣為人知的模型，儘管很多富有實際經驗的測試人員還是不太熟悉V模型，或者其它的模型。V模型已存在了很長時間，和瀑布開發模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質疑。在《
軟體測試中的V、W、H模型
V模型 主要反映測試活動與分析和設計的關係。 V模型的策略既包括低層測試又包括了高層測試，低層測試是為了原始碼的正確性，高層測試是為了使整個系統滿足使用者的需求。 是一種最基礎的模型，其他模型都是從這個模型演化來的。 缺點：把測試作為編碼之後的最後一
軟體測試：等價類劃分舉例
假 設 商 店 貨 品 價 格 (R) 皆 不 大 於 100 元 （ 且 為 整 數 ） ， 若 顧 客 付 款 在 100 元 內 (P) ， 求 找 給 顧 客 之 最 少 貨幣 個（張） 數 ？ （ 貨 幣 面 值 50 元 (N50) ， 10 元 (N10) ， 5 元 (N5) ， 1 元 (N
[已解決]軟體測試：Jmeter執行錯誤
2017/07/14 18:25:49 INFO - jmeter.threads.JMeterThread: Thread finished: 執行緒組 1-19 2017/07/14 18:25:50 INFO - jmeter.threads.JMeterThr
百度軟體測試：一面
一、專案 1、資料量 2、執行時間 3、有沒有用並行框架 二、java 1、解釋一下多型和過載 2、static final與final的不同 三、資料結構 1、反轉單鏈表，並考慮存在環的情況，環在中間的位置 四、計算機網路 1、TCP斷開連線過程（4次）以及time_wa
軟體測試過程模型特點（V模型 W模型 X模型 H模型）
1.V模型： V模型和瀑布模型有一些共同的特性，V模型中的過程從左到右，描述了基本的開發 過程和測試行為。 優點：V模型的價值在於它非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係。 侷限性：（測試介入太晚） 把測試作為編碼
軟體測試系列之軟體測試過程模型V,W,H,X等
在軟體開發的不斷實踐過程中，人們積累經驗教訓，預估未來發展，總結出了很多的開發模型，比較典型的開發模型有，邊做邊改模型，瀑布模型，快速原型模型、螺旋模型，增量模型，演化模型，噴泉模型，智慧模型，混合模型還有RAD模型以及最近比較流行的，基於網路的面向物件的模型——RUP（RationalUnifiedProc
軟體測試過程模型：V模型 W模型 H模型
軟體測試過程模型：V模型 W模型 H模型 1.軟體測試過程模型－V模型是軟體開發瀑布模型的變種，主要反映測試活動與分析和設計的關係；51Testing軟體測試網侷限性：把測試作為編碼之後的最後一個活動，需求分析等前期產生的錯誤直到後期的驗收測試才能發現軟體測試過程模型－
【軟體測試】對比V模型、W模型、H模型，簡述他們各自的特點
V模型： 測試活動的展開次序正好與開發的次序相反，動態測試的行為與開發行為相對應。忽略了測試的物件不應該僅僅包括程式，沒有明確指出對需求、設計的測試。 W模型： 補充了V模型中忽略的內容，強調
軟體測試的分類--敏捷測試：基於指令碼的測試-SBT、探索式測試（ET）、基於風險的測試--RBT、基於模型的測試--MBT
敏捷測試：Agile Testing--遵循敏捷宣言的一種測試實踐 個體與互動 重於 過程和工具 可用的軟體 重於 完備的文件 客戶協作 重於 合同談判 響應變化 重於 遵循計劃
軟體測試模型——V模型 & W模型
軟體測試的V模型 以“編碼”為黃金分割線，將整個過程分為開發和測試，並且開發和測試之間是序列的關係 單元測試：是模組測試，驗證軟體的基本組成單位的正確性，是白盒測試 整合測試：是模組間的測試，測試介面（軟體各模組之間的介面和軟體與硬體之間的介面）是否正
軟體測試模型——V模型
每次看書看過之後或者工作使用某技術，感覺自己好像明白了一些什麼，但是一兩月過後，總是記不得看了什麼，現在僅將自己看過/工作中使用知識/技術做個整理；（就是當成筆記本用了） 測試模型——V模型 V模型是最廣為認知的模型 最早由Paul Rook在20世紀80年代提出 V
【軟體測試】測試工程師。你工作中最常用的幾種質量管理模型
企業常見的幾種技術質量管理模型 工作久了的軟體測試工程師基本都有自己的工作套路了，他們或多或少會將這種套路傳授給其他人，今天給大家分享的就是總結了一些測試精英的工作方法，看看他們在工作中是如何進行軟體測質量管理的 一 過程方法的管理 過程方法對我們的影響是最基礎的，我們日常發生的“想、說、寫、做”等
軟體工程：專案需求分析與建議-NABCD模型的個人認知
N：（need 需求） 我們在自己的手機上或電腦上查詢檔案時，往往因為檔案數量的眾多，型別的繁瑣從而使我們的尋找非常的困難，因此一款簡單便捷的查詢格式型別的軟體（尤其是在電腦上）變得尤為重要。 A：（Approach 做法） 為了解決部分人群的需求，我們有獨有的方法，更加有效
軟體工程：軟體過程模型分析總結
瀑布模型 描述：每個軟體過程順序銜接、一次性通過，最常用。 優點：由文件和風險驅動，利於提高大型專案開發的質量和效率。 缺點：建設週期長、風險大、難以滿足使用者需求。 適用場合：需求明確且很少變
使用功能點估算模型評估軟體測試的工作量
功能點分析法應用在軟體測試中，它最核心的價值究竟是什麼呢? 讓我們先看看軟體開發，這是跟測試離得最近的工作型別。開發工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用UML語言，藉助類似於Rose這樣的工具，繪製一些UC圖、類圖、ER圖等 最近有位同事問我，“天彤你搞這個功能點分析演算法，主要目
tensorflow學習系列六：mnist從訓練儲存模型再到載入模型測試
通過前面幾個系列的學習對tensorflow有了一個漸漸親切的感覺，本文主要是從tensorflow模型訓練與驗證的模型進行實踐一遍，以至於我們能夠通過tensorflow的訓練有一個整體的概念。下面主要是從訓練到儲存模型，然後載入模型進行預測。# -*- codin
軟體測試——PIE模型
1、Bug的型別： Fault：靜態存在於軟體中的缺陷，如code寫錯了。 Error：軟體執行時，執行到fault觸發產生錯誤的中間狀態。 Failure：Error傳不到軟體外部，使得使用者或測試人員觀測到失效的行為。 2、Pie模型的三個必要條件： （1）E
軟體測試中常用的幾種模型
我們一般會遇到的有V模型和W模型 以及X模型 和H模型 接下來看概念圖，看圖和結合概念使你更好到得理解 V模型:模型是一個著名的、以測試為驅動的開發模型，該模型強調開發過程中測試貫穿始終，是瀑布模型的
軟體測試過程模型-W模型
W模型 •概述 –又稱“雙V模型” –由Evolutif公司提出，相對於V模型，W模型增加了軟體開發各階段中同步進行的驗證和確認活動。 –基於兩個原則