l

2014年6月3日 星期二

白箱測試與黑箱測試(下)

June 02 08:32~10:16

image

最近談到「黑箱」會讓人想到立法院XD。

 

黑箱測試(black-box testing)又稱為功能測試(functional testing),顧名思義就是把待測物(程式碼)放在一個黑色盒子裡面,測試者在看不到待測物內部結構的情況之下執行測試工作。因為不知道待測物內部結構,只能以控制輸入資料為主要的測試途徑。因此黑箱測試又稱為資料驅動測試(data-driven testing)輸入/輸出驅動測試(input/output driven testing)

***

上集提到的白箱測試,由於測試者可以看到程式碼,因此可以依據程式邏輯來決定測試資料的輸入值要如何設計。黑箱測試由於看不到程式碼,因此只能依據規格(specification)來設計測試案例。這觀念很直覺、簡單、重要,但實際上卻經常被忽略。Teddy有個開發Android App的朋友經常被公司的測試人員測出「bug」而要求他改功能,回報bug的原因是他的App與其他類似iPhone上的App有著不一樣的操作方式,而測試人員「自己覺得」iPhone上的App「比較好用」,因此「判定」朋友所開發的Android App「有bug」。

看到這樣的bug,朋友當然很氣,因為他只是按照「需求」所要求的去開發,測試人員在執行黑箱測試的時候,並沒有參考需求來測試,而是依據「自己的經驗、感覺、喜好」,在內心中自己創造出一份關於需求的規格。這份測試人員心中的規格,當然與開發人員心中的規格不一致,因此所謂的「bug」就此產生。

其實這也不能怪測試人員不依據「規格」來測試產品,因為大部分的產品都沒有非常明確、詳盡的「規格」,因此存在著很多「模糊空間」。

開發人員:手機聯絡人資料要能夠匯出…嗯,把它匯出成XML格式的文字檔好了。

測試人員:手機聯絡人資料要能夠匯出…什麼,XML文字檔!這是什麼鬼,客戶怎麼可能看得懂?人家iPhone都可以把聯絡人資料備份到雲端,這樣做才對啊。讓我回報一個bug來修正我們產品問題。

測試人員內心獨白:能找出這樣的bug,我真是百年難得一見的練武測試奇才啊。

開發人員:靠…近一點仔細看這個bug,備份到雲端這是新需求吧,我們只是匯出手機聯絡人資料而已耶,這是哪個天才回報的「bug」啊!

開發人員內心獨白:我的棍子哩!

***

鄉民甲:既然黑箱測試是依靠控制輸入資料,把所有可能的輸入值都測過一遍不就好了?

Teddy:理論上是這樣沒錯,但是因為輸入資料的可能性太多,因此如果要用「暴力法」來執行黑箱測試會花太多時間,可能到測試者往生之後的1000年測試案例都還沒跑完挑眉質疑

寫到這裡補充一點關於白箱與黑箱測試的「殘酷現實」:

  • 白箱:用暴力法來測試每一條程式執行路徑是行不通的(exhaustive path testing is not possible)
  • 黑箱:用暴力法來測試所有的輸入值是行不通的(exhaustive input testing is not possible)

因為用暴力法來測試所有可能的程式行為是行不通的(會耗費非常、非常久的時間),在討論需要多少測試案例才足夠的問題時,白箱測試就衍生出了Teddy在上集介紹的各種測試涵蓋率,開發團隊可以藉由訂定各種不同測試涵蓋率的標準來判定測試案例是否足夠。至於黑箱測試面對著是龐大的輸入資料範圍,因此黑箱測試案例的設計焦點則是關注於如何簡化各種可能的輸入資料,設計出「具有代表性」又比較可能找出bug的測試案例。

有幾種設計黑箱測試案例的常見技巧:

  • 等價劃分(equivalence partitioning)把輸入資料劃分成幾個不同的區域,每個區域具有相同的特性。例如,原本的輸入資料範圍是「全人類」,目前地球有超過70億人口,可能性太多。因此,可以把「全人類」依據人種分成黑人、白人、黃人、紅人等,在每種人之間最少挑一筆資料出來測。也可以依據國家、地區、性別、年齡等條件去劃分。
  • 邊界值分析(boundary value analysis):害蟲通常會躲在角落(邊界)的地方,程式的bug也容易出現在資料邊界處,例如一個接受整數的函數,當輸入值大於或等於最大正整數、小於或等於最小正整數,會不會出問題?
  • 狀態機測試(state-based testing):有些功能具有很清楚的狀態,例如販賣機、提款機、遙控器等,只要能夠畫出這些功能的狀態圖,依據狀態去測試即可。有上過Teddy的〈設計模式這樣學就會了:入門實作班〉的學員們,應該還記得Teddy在介紹State模式的時候提過,畫出State Transition Diagram之後可以依此實作與測試State模式。

螢幕截圖 2014-06-02 09.56.01

 

  • 劇本測試 (scenario-based testing):依據Use Case或是story來測試功能是否正常(迷之音:看起來可以動就好了啊挑眉質疑)。

***

最後請問鄉民們一個問題:「從黑箱測試的角度來看,如果系統很難測怎麼辦?」

如果黑箱測試很難測,通常表示不容易控制與觀察待測程式的狀態,因此可以設計專供測試或診斷問題所使用的特殊介面。以Android手機為例,測試者有時需要將系統切換到所謂的「工程模式」,才比較容易測出問題。

***

友藏內心獨白:黑箱要規格。

沒有留言:

張貼留言