軟件測試的模型都有哪些:詳解軟件測試模型

　　測試工具分享之一，測試模型

　　近來(lái)，常在軟件測試俱樂(lè )部里，跟一眾測試精英討論問(wèn)題。Kerry說(shuō)，你開(kāi)源工具用過(guò)不少，不如寫(xiě)篇博客，讓大家也少走些彎路。我應下來(lái)時(shí)，還不到十一，如今竟已是十一的最后一天，所以抓緊寫(xiě)點(diǎn)，省得又成了個(gè)大坑。

　　定義

　　動(dòng)筆前，猶豫好久。想來(lái)想去，所有工具都只是為了解決一個(gè)問(wèn)題，或是一時(shí)的問(wèn)題。但只有一個(gè)東西，從頭到尾，一直在用。那就是如何理解被測系統，找到測試點(diǎn)子。我盜用《the little black book of test design》中的說(shuō)法(讀書(shū)筆記，點(diǎn)我)，稱(chēng)其為測試模型。借用其定義如下，測試模型：盡可能列出可能發(fā)生的錯誤，或導致客戶(hù)不滿(mǎn)意之處，按照發(fā)生概率與嚴重程度排序，自上而下的進(jìn)行排查，即為測試。而幫助測試人員進(jìn)行更好的規劃與理解這一行為的抽象，即為測試模型。

　　JW圈圈模型

　　我們先來(lái)看James Whittaker的JW圈圈模型(因為原圖中模型為圓環(huán)套圓環(huán)，有此得名)。

　　為了理解圈圈模型，我們先要介紹一下背景。發(fā)明者James Whittaker在發(fā)明此模型時(shí)，正在微軟進(jìn)行Office的測試工作。因此，JW圈圈模型并未涉及到太過(guò)復雜的系統框架，或性能因素。而只是從單用戶(hù)，單一系統，單機出發(fā)，遍歷了四大影響該被測系統的因素。即：

　　用戶(hù)(行為：包括輸入)

　　存儲(如輸出)

　　操作系統(資源)

　　第三方庫(依賴(lài)性)。

　　試舉一例：也已windows上的軟件freemind為例，在freemind的插入圖片選項中，要求用戶(hù)輸入該圖片的路徑，即：用戶(hù)與存儲。測試點(diǎn)子包括：輸入一個(gè)存儲設備存在的圖片;不存在的圖片;網(wǎng)絡(luò )存儲設備的路徑。大家可以嘗試填寫(xiě)一個(gè)http://*/.jpg, freemind沒(méi)辦法處理此請求，而導致卡死。

　　JB啟發(fā)式模型

　　接下來(lái)，為James Bach的JB啟發(fā)式模型(原文為heuristic)：

　　為了理解JB啟發(fā)式模型，我們依然先來(lái)了解一下JB的背景。高中畢業(yè)后輟學(xué)，自學(xué)軟件與編程，21歲任Apple最年輕的軟件測試經(jīng)理，而后跟Cem Kaner，Michael Bolton一起，搞軟件測試培訓與咨詢(xún)。鄙視一切認證，鄙視一切教條，幾乎所有的東西都自成體系。通過(guò)對JB的了解，我推斷他是一個(gè)思維過(guò)分活躍與發(fā)散的人，很難從他的文章中尋找出一根明確的主線(xiàn)。也許就是這樣的人，才能找到大家找不到的Bug吧。

　　啟發(fā)式模型中，提到了一點(diǎn)，時(shí)間。這是我測試以來(lái)最常忽略的一個(gè)因素。以測試Chrome中內嵌的flash播放器為例。我們測試了：

　　點(diǎn)擊播放按鈕，進(jìn)行播放;

　　點(diǎn)擊暫停按鈕，視頻暫停;

　　再點(diǎn)擊播放，視頻繼續。

　　問(wèn)題來(lái)了，如果你點(diǎn)擊暫停，超過(guò)1小時(shí)，flash播放器會(huì )卡死，從而導致Chrome當前標簽卡死;firefox更過(guò)分，整個(gè)瀏覽器卡死。這個(gè)問(wèn)題嚴重了吧，我們測試登錄，輸入用戶(hù)名，輸入密碼，正確的，錯誤的，測了一大推。好了，問(wèn)題來(lái)了，輸入用戶(hù)名，停半小時(shí)，再輸入密碼，登錄失敗。以為自己已經(jīng)將所有測試可能性考慮過(guò)的同志們，傻眼了吧。

　　RBRA模型

　　接下來(lái)為Rex Black的風(fēng)險分析模型(Rex Black's Risk Analysis)。

　　我對RB知之甚少，只知道他從事多年軟件培訓與咨詢(xún)工作，著(zhù)有《Pragmatic software testing》一書(shū)，是ISTQB(國際軟件測試認證組織)的核心成員?？碦B的書(shū)時(shí)，正是我正進(jìn)行系統測試，總管一個(gè)由三個(gè)項目合成起來(lái)的系統?？梢詼y的地方太多，從哪里下手?如何排列優(yōu)先級?測到哪里為止?這些問(wèn)題，在讀到RB的風(fēng)險模型后，都一一獲得了解答。

　　以我所作的系統測試為例：風(fēng)險分析教會(huì )我先定義風(fēng)險，按照風(fēng)險排列優(yōu)先級與測試時(shí)長(cháng)。因此：我定義如下風(fēng)險：

　　低風(fēng)險：代碼改動(dòng)(包括缺陷修復與新功能)

　　中風(fēng)險：所有低風(fēng)險中，需要與其他模塊交互之處

　　高風(fēng)險：所有中風(fēng)險中，會(huì )影響到大量用戶(hù)之處

　　以此為標準，排列所有用戶(hù)故事，每個(gè)高風(fēng)險故事分配3小時(shí)，中風(fēng)險故事分配1小時(shí)，低風(fēng)險0.5小時(shí)。當系統測試結束時(shí)，我們只覆蓋了高、中風(fēng)險，而低風(fēng)險則完全沒(méi)有覆蓋。但發(fā)現的每一個(gè)問(wèn)題，都是必須要修復，否則便可能影響大量用戶(hù)的問(wèn)題。比起之前，RBRA模型產(chǎn)生的覆蓋更有針對性。就算本次系統測試并不成功，發(fā)布后用戶(hù)問(wèn)題過(guò)多，我們又可以將這些問(wèn)題分類(lèi)，定義為高風(fēng)險，以期下次去覆蓋。

　　我的RP人品模型

　　為了便于記憶，我將RBRA模型稍加改動(dòng)，便成了現今的人品模型。人品模型按照相關(guān)人(或角色)來(lái)劃分，將RBRA中原有的風(fēng)險，分配到各個(gè)角色下。即：由人及其需要出發(fā)，分析風(fēng)險。

　　例如：

　　在測試用戶(hù)界面時(shí)，

　　普通用戶(hù)用鼠標，

　　Geek則喜歡使用快捷鍵，

　　孩子喜歡亂點(diǎn)亂畫(huà)，

　　老年人則可能會(huì )將字體放到很大，

　　當用戶(hù)群體擴大到相當時(shí)，更要考慮某些方面有殘疾的人士(如：紅綠色盲等)

　　在測試功能時(shí)，也要考慮性格因素。如：

　　粗心的管理員可能忘記備份，

　　對于命令不熟悉的管理員可能誤刪配置文件等等。

　　人品模型的好處是它是自由的，發(fā)散的，何時(shí)何地都可以使用的。不需要死記硬背，不需要打印列表，三五個(gè)人，一塊白板，一只記號筆，即可提問(wèn)。如：

　　要是老板來(lái)用，他肯定會(huì )如何如何吧。

　　要是我爸來(lái)用，他肯定連什么都找不到吧。

　　要是讓我那粗心的小師弟用，他會(huì )如何如何吧。

　　要是我那geek師兄，一定會(huì )如何如何hack吧。

原文轉自：http://kjueaiud.com