1. 程式人生 > >Verification和Validation傻傻分不清楚?

Verification和Validation傻傻分不清楚?

本文轉自:http://www.eetop.cn/blog/html/28/1561828-6339384.html

Verification:相比Validation,確認產品功能、服務或系統是否符合規則、要求、規範和強制條件,通常是還沒有面向客戶的內部過程,看有沒有“把事情做對”

Validation:相比Verification,要確保產品功能、服務或系統能夠滿足客戶或其他利益相關者的需求,通常測試對外部客戶的接受度和適應度,即“做對的事情”

 

稱Verification和Validation為兩兄弟,這麼說靠不靠譜呢?Doug Amos試圖來講明白這個事情,但Brian Bailey認為他還做的不夠。

 

在今年的DVCon上,Doug Amos代表Mentor做了相關話題的演講。Doug Amos是一個非常罕見的人才,他知道如何在將幽默、教學和營銷同時融入到一場演講中,同時又能將三者剝離乾淨,讓聽者清楚地知道他們身處哪一個聆聽模式中。遺憾的是這樣一個人才卻要退休了,以後江湖中只剩下傳說。

 

Amos的演講談到了Verification和Validation的差異,也認為我們這一行以後會有非常多的工作會相當依賴Validation技術。不過對於能源、保密性和安全性這三個新興領域,以及越來越多的軟體出現,都使Validation變得更加複雜

 

演講中,他介紹了各種有名的兄弟關係,比如尤文和皇室以及傑克遜兄弟。他很幽默地將兩兄弟聯絡到各種需要在工具或是流程中發生的任務。舉個例子,傑克遜兄弟就像是在和諧工作的多引擎,而哈利和威廉就像驗證和形式驗證兩兄弟。

 

演講透露出一個強烈的資訊,Amos認為,真正會阻礙到我們的,其實是大量的軟體內容。不過整合硬體和軟體也很艱難,越來越多的軟體進入了我們的系統,整合進去的硬體多會依賴軟體。更煩人的是專案節點到來時營銷人員都會發了瘋地催你。 

 

Amos指出,目前幾乎沒有一些統一的標準來幫助解決軟硬體協同的問題,每個公司都只能想辦法按照自己的方式去解決。不過他們都是基於FPGA原型

去設計的,因為這是唯一具有足夠的速度和精讀來執行大量軟體的硬體平臺

 

現在來看看Amos是如何定義驗證的:

 

 

圖1.Verification和Validation對比

 

Amos這樣來描述這張圖片,當你買了一件襯衫,怎麼樣來看襯衫好不好呢?首先我們會看這件襯衣質量合格嗎,是不是有兩個相同長度的袖子,尺寸合適嗎,顏色是我要的嗎,鈕釦有沒有少一顆,這些都可以理解為你在去驗證(Verify)這件襯衣。而Validation則更像是看這件襯衣是否合適自己,我喜歡它嗎,有沒有覺得自己變得更加帥氣了,顏色跟我的眸色配嗎,約會時會不會有加分。再比如說,考慮買一輛車,這輛車我開起來舒不舒服?現在有一個技術是在汽車模型中通過眼前的電視螢幕來模擬真實的駕駛體驗,這些都是很重要的事情。

  

Verification和Validation已經不僅僅是普通兩兄弟的關係這麼簡單了,Brian Bailey認為他們更像是童年時因為一些悲慘的遭遇而被迫分開的同卵雙胞胎,而那次遭遇就是約束下的隨機激勵(constrained random stimulus)。因為約束下的隨機化雖然使得Verification在許多方面變得自動化,並將定向測試的生成轉換成為機器驅動(machine-driven)的方法,但是在轉向隨機化遍歷的同時,Verification也忽略了它有Validation這位兄弟,因此“襯衫最終合不合身”在Verification看來並不那麼重要……

 

因為約束隨機化的存在,Verification往往帶來的是一個重複的過於關注瑣碎細節的模型,甚至會帶給人混亂。Verification如此關注於瑣碎的細節,卻不能夠為我們帶來一個完整的模型。所以呢,在Validation缺席的情況下,我們依然不會知道這件“檢驗合格”的襯衫能不能“合體”。不過謝天謝地,現在我們至少可以部分解決這個問題了。在演講中,Amos提到了行動式激勵(Portable Stimulus),就像很多人去展示行動式激勵一樣,它將測試從一個平臺移植到了另一個平臺。這項技術已經做得非常不錯了,但是仍然忽略了幾個關鍵點:

 

第一,行動式激勵是非常抽象的。它往往是定義一個硬體或是軟體的抽象層,可以使驗證環境能夠以使用者最省力的方式去與暫存器,驅動器或是軟體堆疊的任何層次進行通訊。然而聽說這種方式不會成為第一版本的行業標準,這是非常遺憾的。

 

 

第二,行動式激勵定義了一個產品真正應該做成什麼樣子。在襯衫的這個例子中,它將去定義“適合”的含義,因為這是系統級驗證的主要目標。假設鈕釦問題處於模組級驗證中,並且整體的結構已經成功完成,這個時候我們就會去問,它是否適合於用途,這既是Verification也是Validation

 

第三,當涉及到計算機資源時,約束的隨機必定是迄今為止定義的最低效的方法。隨著系統變得越來越複雜,非常多的時間被花費在研究測試平臺在做什麼為什麼要這樣做。行動式激勵修復了許多這些問題。因為它生成的每一個測試都是有用的,鑑於Validation任務的重要性,這是非常關鍵的。當我們需要確定系統是否能夠在指定時間內同時執行任務A和B時,那些沒有和系統內部相連線的隨意的測試是我們不能承受的。

 

其實現在我們距離制定Validation的標準已經越來越近了,以及Verification和Validation如何在相互幫助中共同發揮作用。Verification和Validation可以說是兩兄弟,或許有時一個比另一個作用更大一些,不過相比於去比較他們誰的作用更大,不如把重心放在讓他們相互結合,緊密聯絡在一起

 

原文來自於Semiengineering“Verification and Validation Brothers”

https://semiengineering.com/verification-and-validation-brothers/