編輯導語：軟件測試，是使用人工或自動的手段來運行或測定某個軟件系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。正確的“軟件設計”是完成一款好的軟件的前提和基礎，而設計驗證是判斷軟件設計正確與否的一個好方法。

提到對軟件的質量檢查，馬上想到的是“軟件測試”，軟件測試的目的主要是檢查“開發程序”是否符合“軟件設計”的要求，程序中是否有bug等，也就是說軟件測試是檢查完成軟件“是否滿足設計要求”的工作。

完成一款好的軟件首先要做到的是“軟件設計”是正確的、優秀的，如果軟件設計沒有做到正確和優秀，后面程序編寫的質量再好也沒有價值，設計是保證軟件正確和優秀的前提和基礎。

那么如何判斷軟件設計的結果是正確的、優秀的呢？這就要用到“設計驗證”的方法，設計驗證包括了“業務設計驗證”和“應用設計驗證”兩個部分。

下面重點談一下關于設計驗證的方法（軟件測試已有非常多的資料可以參考，省略）。

一、關于設計驗證

這里以設計企業信息系統的為例來說明設計驗證存在的意義。

大多數具有一定規模的企業信息系統都是定制的（因為沒有二家企業的經營管理模式是完全相同的），定制型系統不能像產品型系統一樣可以通過不斷地改進、完善、提升，每個系統都是唯一的存在。

因此，要想做到系統上線后不再進行大規模地返工、改造，就要盡可能地在投入開發前就通過驗證以獲得客戶對設計的認可。在進行詳細說明前先談兩個關于軟件設計驗證的問題。

1. 為什么要對設計結果進行驗證呢？

做過軟件的人（不論需求、設計、開發或是測試），都直接或間接地聽過這樣的事：開發前與客戶確認了需求、并且客戶也在確認書上簽字了，可系統上線后一試用，客戶經常會抱怨說：

1）抱怨舉例1

• 這個系統不是我想要的、這與事前溝通時想象的不一樣。
• 為什么操作這么費勁（輸入太繁瑣）、為什么要走這么多步才能完成一次輸入？
• 不用系統工作就夠忙的了，結果用了系統更忙了。
• 輸入的數據對我的工作沒有幫助，都是給領導輸入的…等等。

2）抱怨舉例2

• 數據計算有錯誤、頁面切換后xx標題就找不到了…
• 經常死機、系統不穩定、輸入xx數據后就進入了死循環…
• 系統反映太慢了，去廁所都回來了，一個頁面還沒打開…
• 頁面數據鏈接錯了，找不到相關的數據…等等。

這兩組舉例的不同之處在于：【舉例1】是軟件設計問題，【舉例2】是軟件測試問題。從客戶抱怨的內容可以看出設計驗證和軟件測試的不同，【舉例1】的設計問題在測試階段已經無法改變，通常它們也不是測試工程師的檢查對象。

【舉例2】的問題出在編程和測試的質量上，不屬于設計層面的問題?？梢钥闯鲆胫谱饕粋€好的軟件僅對開發結果進行軟件測試是不夠的，還要對設計階段的成果進行驗證。

上述舉例存在的問題如果沒有很好地解決，往往會造成在客戶企業中系統推廣受到阻力、難以執行，其結果可能有兩個：

1. 由于存在的問題太多不能推廣、最終軟件被擱置了；
2. 在領導的壓力下勉強推廣，但是運行一段時間后就會形成兩張皮：線上用系統做一套數據（給領導看）、線下用手工按照傳統方式再做一套數據（實際使用），這造成了時間、精力和成本的浪費，造成了用戶對信息系統導入有了不信感。

2. 設計驗證為什么不能與軟件測試工作一同進行呢？

要回答這個問題首先看一下其它的行業是如何做的，蓋房子、造機器、制衣服等行業能否等到完成后再檢查判斷設計方面是否有缺陷呢？

顯然是不可能的，因為“木已成舟”！因此這些行業通過圖紙（2D）、實物模型（用木材、塑料、金屬等制作）、或用電腦制成3D模型等，讓相關人直觀地看到按照設計制作完成后的產品效果。

他們可以利用圖紙、實物模型或是電腦3D模型進行反復的推演、驗證，以保證完成的產品達到預期的效果。

而在產品制造完成后到交付前的檢驗都是圍繞著“制造質量”為核心進行的（而非“設計質量”）。由于有多樣的驗證手段，所以建筑業、制造業很少出現制作完成后才發現設計有錯誤的現象。

建筑物或機器完成后發現嚴重的設計問題時要修改，甚至推到重來，軟件也是一樣的，完成的軟件出現了設計問題后，修改某一處，由于邏輯關聯就可能帶來其它地方的變動，造成連鎖變化。

如果是原則性的設計問題，就有可能需要重新構建系統，造成重大的損失。因此，設計完成后立即進行設計驗證是最有高效的方法，不但可以解決軟件設計問題、開發過程管理的可控性，還可以極大地提升客戶對未來完成系統的信任度和滿意度。

二、設計驗證的內容

設計驗證包括兩個部分：業務設計驗證、應用設計驗證，它們目的是是檢查“設計成果”是否滿足“客戶需求”。

1. 業務設計驗證（以下簡稱：業務驗證）

編寫一套業務數據，這套數據可以模擬某個業務處理場景的全過程，用這套數據將系統中要驗證的對象串聯起來，用以驗證業務設計的整體架構、業務流程、界面字段、數據關系、計算公式、管控規則等內容是否正確，確保系統中的業務邏輯、數據邏輯是正確的。

• 業務驗證保證了 “系統可用” 的最低要求。

2. 應用設計驗證（以下簡稱：應用驗證）

編寫一套系統運行的腳本，這個腳本可以模擬客戶的某個角色（如經理、會計、庫管員等）、或某個流程（采購、報銷、物流等）操作的運行全過程，用以驗證操作過程的每個細節是否合理、高效，讓用戶獲得最佳的體驗，包括：界面布局、操作效率、設計與角色工作的匹配度、智能化程度等。

• 應用驗證保證了 “系統好用” 的最高要求。

為了做對比，這里舉幾個典型的軟件測試內容：頁面顯示、操作功能（按鈕：增加、刪除、修改、保存、查詢…）、權限（身份驗證、操作權限）、流程流轉、報表打印、兼容性、可擴展性、穩定性、運行速度等?？梢钥闯鲕浖y試與設計驗證的關注點是不一樣的。

開發完成后的測試，不但要進行有測試用例，而且還應該測試業務用例和應用用例的內容，只有如此，才能交給客戶一份滿意的答卷。

注1：可能有人會說，我們使用“原型法”做的需求調研，還需要進行設計驗證碼？

這個說法是不對的，因為需求調研階段使用的原型法僅僅是確認了界面的基本內容、粗粒度的業務邏輯，而說到設計驗證，則必須是要有嚴格的目標、方法、標準和規范的，否則是不能得出設計結果正確、優秀的結論的。

注2：應用設計等同于UI和美工設計嗎？

UI、美工等工作都是構成應用設計的部分，但它們是輔助內容，不是核心內容。

三、設計驗證與軟件測試的關系

三個階段的檢查使用了三種用例形式，從前到后繼承疊加、最后驗證出綜合效果，這三者是包含關系，測試用例 ＞ 應用用例 ＞ 業務用例。三者各自包含的內容、三者之間的繼承關系如圖1所示：

圖1：三種用例之間的關系

1. 三個檢查的作用

1）業務驗證（對業務設計成果的推演）

以需求為依據，對業務的梳理、優化內容進行推演，重點在于對“業務邏輯、數據邏輯”的確認，是“內涵”。

2） 應用驗證（對應用設計成果的推演）

以業務用例的數據作為主線，加入系統功能（流程機制、高保真界面、功能按鈕等），進行用戶操作過程的合理性、友好性推演，重點在于“信息化環境”的確認，是“外表”。

3）軟件測試（對完成系統的測試）

軟件測試除去按照自有的測試用例（比如：功能、bug、性能、安全、集成等）進行檢查外，還要再加入前述兩個驗證用例的內容，以測試完成的系統是否可以準確地演出這個“劇本”。

2. 三個檢查的區別

1）業務驗證與應用驗證的區別

這兩者的區別從設計的目的上就可以看出來：

• 業務設計決定了系統的主體、內涵，業務正確保證了系統核心價值的存在；
• 應用設計決定了系統易操作性、功能的智能化，用信息化手段提升客戶的工作效率等。

用戶對業務價值的感受是通過操作界面來獲得的，因此，應用設計的不好用，用戶就感受不到業務設計的價值了（因為他不想用）。

2）設計驗證與軟件測試的區別

這兩者的區別從系統完成后的效果上就可以看出來：

• 設計驗證（業務&應用）：要證明的是“設計是按照需求進行的，設計是正確的”，但是無法保證后續軟件開發是否會出錯。設計做好了，會得到客戶的贊揚，提升滿意度，因為軟件的客戶價值絕大部分來源于設計。
• 軟件測試：要證明的是“軟件是按照設計編寫的，程序沒有錯”，但不保證軟件設計是否是正確的。

軟件測試的結果再好（假定100分），只是證明了軟件是按照設計開發的，客戶只會在設計正確的前提下給予表揚，因為客戶買的是業務設計和應用設計的價值，而軟件不出bug、性能良好、安全等不是購買的目的（是應該的?。?。相反，如果測試結果不好，所有的客戶反饋都是差的，因為無法使用，業務和應用價值再高也無法證明。

3. 軟件合格的標準

軟件開發完成在交給客戶前，到底要測試到什么程度呢？

關于這個的“度”的問題有不同的說法，其中強調“軟件不同于其它行業…”的說法也不在少數，但是有一個原則不論什么行業都是要遵守的，那就是交到客戶手中的產品原則上是不能有質量問題的，不論這個質量問題是設計造成的（業務、應用和技術）還是編寫程序造成的。

“沒有bug了，所以測試完成了”的說法是不正確的，測試完成的標準應該是：測試結果證明產品的開發完全符合設計要求。

按照這個標準做測試，不但要有測試用例，還必須有業務用例和應用用例，一定要記?。嚎蛻舻臐M意度是針對整個軟件的設計、開發和服務而言的，沒有“bug”不是軟件開發合同的內容。

另外，“測試結果”是不能直接用于驗證“客戶需求”的，而只能用于驗證“設計結果”，因為客戶需求都要經過多重的設計（業務、應用、技術）之后才能確定下來交付開發。

因此，測試開發是對軟件設計要求負責的，而不是對需求調研結果負責的。三個檢查的作用不同，效果不同，缺一不可。通常前兩個檢查沒有被重視（或做到不夠），所以完成的軟件即使是沒有bug也沒有獲得客戶的好評其原因就在于此。

四、由誰來做設計驗證

軟件測試用例通常是由測試工程師編寫的。那么設計驗證的用例由誰來做呢？回答是：需求工程師。當然前提條件是這名需求工程師參與了需求調研和軟件設計的工作。

設計的驗證用例，與軟件的測試用例視角不同、關注點不同、需要的知識和經驗不同、編寫的方法也不同，更重要的是設計驗證用例只有參與了調研和設計工作的人才能寫出來。

從上述的說明中可以看出，測試工程師是難以做出這樣的設計用例的，而且在時間上也不允許，相反，如果有了需求工程師編寫的設計用例，也會對測試工程師編寫測試用例提供很大的幫助。

設計驗證小結：

對于一名需求工程師來說，能夠寫出設計用例是一個比較高的要求，如果你做了需求收集、分析、業務和應用設計，但是沒有做設計驗證，那你就不敢說自己設計的正確、優秀，很可能設計是完全咬合不到一起的你也不知道，更不敢保證開發完成的軟件是可以讓客戶滿意的。

所以，作為一名合格的需求工程師，必須要掌握所設計驗證的方法，通過設計驗證，可以讓自己對設計的產品有一個整體的認知、查出問題，同時也讓客戶、程序員和測試工程師等相關人對要開發和完成的軟件有一個完整的認知。

能夠獨立地完成咨詢、調研、設計和驗證4個環節的需求工程師，才可以稱之為一名成熟的、合格的需求工程師。

以下兩篇本文，重點對業務設計驗證和應用設計驗證的方法進行說明。

本文由 @李鴻君 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議