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

完成一款好的軟件首先要做到的是“軟件設計”是正確的、優(yōu)秀的，如果軟件設計沒有做到正確和優(yōu)秀，后面程序編寫的質量再好也沒有價值，設計是保證軟件正確和優(yōu)秀的前提和基礎。那么如何判斷軟件設計的結果是正確的、優(yōu)秀的呢？這就要用到“設計驗證”的方法，設計驗證包括了“業(yè)務設計驗證”和“應用設計驗證”兩個部分。

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

1.關于設計驗證

這里以設計企業(yè)信息系統(tǒng)的為例來說明設計驗證存在的意義。
大多數(shù)具有一定規(guī)模的企業(yè)信息系統(tǒng)都是定制的（因為沒有二家企業(yè)的經營管理模式是完全相同的），定制型系統(tǒng)不能像產品型系統(tǒng)一樣可以通過不斷地改進、完善、提升，每個系統(tǒng)都是唯一的存在，因此，要想做到系統(tǒng)上線后不再進行大規(guī)模地返工、改造，就要盡可能地在投入開發(fā)前就通過驗證以獲得客戶對設計的認可。在進行詳細說明前先談兩個關于軟件設計驗證的問題。

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

做過軟件的人（不論需求、設計、開發(fā)或是測試），都直接或間接地聽過這樣的事：開發(fā)前與客戶確認了需求、并且客戶也在確認書上簽字了，可系統(tǒng)上線后一試用，客戶經常會抱怨說：
【抱怨舉例1】
□這個系統(tǒng)不是我想要的、這與事前溝通時想象的不一樣。
□為什么操作這么費勁（輸入太繁瑣）、為什么要走這么多步才能完成一次輸入？
□不用系統(tǒng)工作就夠忙的了，結果用了系統(tǒng)更忙了。
□輸入的數(shù)據對我的工作沒有幫助，都是給領導輸入的…等等.

【抱怨舉例2】
□數(shù)據計算有錯誤、頁面切換后xx標題就找不到了…
□經常死機、系統(tǒng)不穩(wěn)定、輸入xx數(shù)據后就進入了死循環(huán)…
□系統(tǒng)反映太慢了，去廁所都回來了，一個頁面還沒打開…
□頁面數(shù)據鏈接錯了，找不到相關的數(shù)據…等等。

這兩組舉例的不同之處在于：【舉例1】是軟件設計問題，【舉例2】是軟件測試問題。
從客戶抱怨的內容可以看出設計驗證和軟件測試的不同，【舉例1】的設計問題在測試階段已經無法改變，通常它們也不是測試工程師的檢查對象。【舉例2】的問題出在編程和測試的質量上，不屬于設計層面的問題。可以看出要想制作一個好的軟件僅對開發(fā)結果進行軟件測試是不夠的，還要對設計階段的成果進行驗證。

上述舉例存在的問題如果沒有很好地解決，往往會造成在客戶企業(yè)中系統(tǒng)推廣受到阻力、難以執(zhí)行，其結果可能有兩個：
□一是由于存在的問題太多不能推廣、最終軟件被擱置了；
□二是在領導的壓力下勉強推廣，但是運行一段時間后就會形成兩張皮：線上用系統(tǒng)做一套數(shù)據（給領導看）、線下用手工按照傳統(tǒng)方式再做一套數(shù)據（實際使用），這造成了時間、精力和成本的浪費，造成了用戶對信息系統(tǒng)導入有了不信感。

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

要回答這個問題首先看一下其它的行業(yè)是如何做的。
蓋房子、造機器、制衣服等行業(yè)能否等到完成后再檢查判斷設計方面是否有缺陷呢？顯然是不可能的，因為“木已成舟”！因此這些行業(yè)通過圖紙（2D）、實物模型（用木材、塑料、金屬等制作）、或用電腦制成3D模型等，讓相關人直觀地看到按照設計制作完成后的產品效果。他們可以利用圖紙、實物模型或是電腦3D模型進行反復的推演、驗證，以保證完成的產品達到預期的效果。而在產品制造完成后到交付前的檢驗都是圍繞著“制造質量”為核心進行的（而非“設計質量”）。由于有多樣的驗證手段，所以建筑業(yè)、制造業(yè)很少出現(xiàn)制作完成后才發(fā)現(xiàn)設計有錯誤的現(xiàn)象。

建筑物或機器完成后發(fā)現(xiàn)嚴重的設計問題時要修改，甚至推到重來，軟件也是一樣的，完成的軟件出現(xiàn)了設計問題后，修改某一處，由于邏輯關聯(lián)就可能帶來其它地方的變動，造成連鎖變化。如果是原則性的設計問題，就有可能需要重新構建系統(tǒng)，造成重大的損失。

因此，設計完成后立即進行設計驗證是最有高效的方法，不但可以解決軟件設計問題、開發(fā)過程管理的可控性，還可以極大地提升客戶對未來完成系統(tǒng)的信任度和滿意度。

2.設計驗證的內容

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

1） 業(yè)務設計驗證（以下簡稱：業(yè)務驗證）
編寫一套業(yè)務數(shù)據，這套數(shù)據可以模擬某個業(yè)務處理場景的全過程，用這套數(shù)據將系統(tǒng)中要驗證的對象串聯(lián)起來，用以驗證業(yè)務設計的整體架構、業(yè)務流程、界面字段、數(shù)據關系、計算公式、管控規(guī)則等內容是否正確，確保系統(tǒng)中的業(yè)務邏輯、數(shù)據邏輯是正確的。
■業(yè)務驗證保證了 “系統(tǒng)可用” 的最低要求。

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

為了做對比，這里舉幾個典型的軟件測試內容：
頁面顯示、操作功能（按鈕：增加、刪除、修改、保存、查詢…）、權限（身份驗證、操作權限）、流程流轉、報表打印、兼容性、可擴展性、穩(wěn)定性、運行速度等。可以看出軟件測試與設計驗證的關注點是不一樣的。
開發(fā)完成后的測試，不但要進行有測試用例，而且還應該測試業(yè)務用例和應用用例的內容，只有如此，才能交給客戶一份滿意的答卷。

注1：可能有人會說，我們使用“原型法”做的需求調研，還需要進行設計驗證碼？
這個說法是不對的，因為需求調研階段使用的原型法僅僅是確認了界面的基本內容、粗粒度的業(yè)務邏輯，而說到設計驗證，則必須是要有嚴格的目標、方法、標準和規(guī)范的，否則是不能得出設計結果正確、優(yōu)秀的結論的。

注2：應用設計等同于UI和美工設計嗎？
UI、美工等工作都是構成應用設計的部分，但它們是輔助內容，不是核心內容。

3.設計驗證與軟件測試的關系

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

圖1 三種用例之間的關系

1）三個檢查的作用

（1）業(yè)務驗證（對業(yè)務設計成果的推演）
以需求為依據，對業(yè)務的梳理、優(yōu)化內容進行推演，重點在于對“業(yè)務邏輯、數(shù)據邏輯”的確認，是“內涵”；

（2） 應用驗證（對應用設計成果的推演）
以業(yè)務用例的數(shù)據作為主線，加入系統(tǒng)功能（流程機制、高保真界面、功能按鈕等），進行用戶操作過程的合理性、友好性推演，重點在于“信息化環(huán)境”的確認，是“外表”；

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

2）三個檢查的區(qū)別

（1）業(yè)務驗證與應用驗證的區(qū)別
這兩者的區(qū)別從設計的目的上就可以看出來
□業(yè)務設計決定了系統(tǒng)的主體、內涵，業(yè)務正確保證了系統(tǒng)核心價值的存在。
□應用設計決定了系統(tǒng)易操作性、功能的智能化，用信息化手段提升客戶的工作效率等。
用戶對業(yè)務價值的感受是通過操作界面來獲得的，因此，應用設計的不好用，用戶就感受不到業(yè)務設計的價值了（因為他不想用）。

（2）設計驗證與軟件測試的區(qū)別
這兩者的區(qū)別從系統(tǒng)完成后的效果上就可以看出來
□設計驗證（業(yè)務&應用）
要證明的是“設計是按照需求進行的，設計是正確的”，但是無法保證后續(xù)軟件開發(fā)是否會出錯。
設計做好了，會得到客戶的贊揚，提升滿意度，因為軟件的客戶價值絕大部分來源于設計。

□軟件測試
要證明的是“軟件是按照設計編寫的，程序沒有錯”，但不保證軟件設計是否是正確的。
軟件測試的結果再好（假定100分），只是證明了軟件是按照設計開發(fā)的，客戶只會在設計正確的前提下給予表揚，因為客戶買的是業(yè)務設計和應用設計的價值，而軟件不出bug、性能良好、安全等不是購買的目的（是應該的！）。相反，如果測試結果不好，所有的客戶反饋都是差的，因為無法使用，業(yè)務和應用價值再高也無法證明。

3）軟件合格的標準

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

“沒有bug了，所以測試完成了”的說法是不正確的，測試完成的標準應該是：測試結果證明產品的開發(fā)完全符合設計要求。按照這個標準做測試，不但要有測試用例，還必須有業(yè)務用例和應用用例，一定要記住：客戶的滿意度是針對整個軟件的設計、開發(fā)和服務而言的，沒有“bug”不是軟件開發(fā)合同的內容。

另外，“測試結果”是不能直接用于驗證“客戶需求”的，而只能用于驗證“設計結果”，因為客戶需求都要經過多重的設計（業(yè)務、應用、技術）之后才能確定下來交付開發(fā)。因此，測試開發(fā)是對軟件設計要求負責的，而不是對需求調研結果負責的。

三個檢查的作用不同，效果不同，缺一不可。通常前兩個檢查沒有被重視（或做到不夠），所以完成的軟件即使是沒有bug也沒有獲得客戶的好評其原因就在于此。

4.由誰來做設計驗證

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

設計的驗證用例，與軟件的測試用例視角不同、關注點不同、需要的知識和經驗不同、編寫的方法也不同，更重要的是設計驗證用例只有參與了調研和設計工作的人才能寫出來，從上述的說明中可以看出，測試工程師是難以做出這樣的設計用例的，而且在時間上也不允許，相反，如果有了需求工程師編寫的設計用例，也會對測試工程師編寫測試用例提供很大的幫助。

■設計驗證小結

對于一名需求工程師來說，能夠寫出設計用例是一個比較高的要求，如果你做了需求收集、分析、業(yè)務和應用設計，但是沒有做設計驗證，那你就不敢說自己設計的正確、優(yōu)秀，很可能設計是完全咬合不到一起的你也不知道，更不敢保證開發(fā)完成的軟件是可以讓客戶滿意的。所以，作為一名合格的需求工程師，必須要掌握所設計驗證的方法，通過設計驗證，可以讓自己對設計的產品有一個整體的認知、查出問題，同時也讓客戶、程序員和測試工程師等相關人對要開發(fā)和完成的軟件有一個完整的認知。
能夠獨立地完成咨詢、調研、設計和驗證4個環(huán)節(jié)的需求工程師，才可以稱之為一名成熟的、合格的需求工程師。

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

■本博文系列的下一篇：軟件開發(fā)質量的雙保險 — 2.業(yè)務設計驗證與業(yè)務用例

關于設計驗證的詳細說明，請參考《大話軟件工程—需求分析與軟件設計》一書。

總結

以上是生活随笔為你收集整理的软件开发质量的双保险 — 1.设计验证与软件测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。