標題：提高測試用例覆蓋率的分析方法

1樓

wangxinxin 發(fā)表于：2010-12-15 11:58:06

開發(fā)高質(zhì)量的測試用例是QA的基本工作。高質(zhì)量的測試用例是既有高覆蓋性又有高可執(zhí)行性，當兩者不可兼得時，它有最佳平衡點。本文不討論如何取得最佳平衡，只關注采用何種分析方法來提高測試用例的覆蓋率。
3 P9 T1 q. s4 G
首先來說，分析分為兩個步驟，首先以不同得角度切分系統(tǒng)，使得它成為更簡單得模塊，第二是把不同得模塊想象成一個黑盒子，對這個黑盒子做類似于單元測試得分析。
& h3 L" K' k' g7 {  k& |' x
1. 從不同得角度把系統(tǒng)分為不同得模塊
這里存在兩種思路

對系統(tǒng)進行完整得劃分
軟件是復雜的。軟件開發(fā)者面對這種復雜性采用的經(jīng)典的方法瀑布模型，也就是從上到下，逐漸細分，大模塊包括小模塊，小模塊包括更小的模塊。對于軟件測試來說，很自然的，我們也可以采用這種方法。但是，這還是遠遠不夠的。我們還要從更多的角度切入系統(tǒng)，從不同的角度把系統(tǒng)切分成一塊一塊的，然后進行測試。
2 P! c1 q- v* V/ M6 |  i
比如遙控器的例子。我們就可以從下面一些方面來劃分系統(tǒng)
1）功能。% {& D0 J) d* w
這個劃分非常直觀，Spec上肯定會明確指明遙控器假設有3個功能，開關機，+-調(diào)臺，+-調(diào)音。對每個功能我們測試它能否正常工作。當然我們也會注意到邊界情況：當音量滿的時候，加音量。。。& R* w$ U2 h7 Q. P4 a3 W, M, G4 {
2）狀態(tài)
Spec上沒有說明遙控器的狀態(tài)，但我們應該能分析得出遙控器有下面的狀態(tài)1 f1 Q0 f# x! g& v! l& {. |  ?
關機，開機，正在調(diào)臺，正在調(diào)音
現(xiàn)在我們可以列一個matrix，測試在每種狀態(tài)下執(zhí)行上面的任意一種操作系統(tǒng)的反應。注意，這個時候，你就要把你自己當成用戶，因為這些情況都不會在spec里詳細的說明的。比如在關機狀態(tài)下調(diào)音，竟然開機了。這個顯然就是bug。( A3 s; j$ K" d8 V& e- p
3）按鍵序列) h( {2 \9 I: F' ~7 H( G+ r
現(xiàn)在我們走得更遠。我們把遙控器看作具有按鈕得一個玩意兒，然后輸入任意一個序列看是否會出現(xiàn)異常情況，是否會讓程序不正常得工作。這里不需要分任何得分析方法。這是一個很好得切入點。另外一個例子是，在測試web application時，做一個爬蟲程序去點擊頁面上得任何link。
# J1 A  q* z, E5 g% v8 D
通過這些不同得劃分，testcase得覆蓋率可以得到有效得提高。. M/ J5 P4 b  h  d( A3 K( s$ W
: X( P1 G- h; d5 W" k( O7 D0 S
需要注意一點是，不同得劃分肯定會帶來testcase得冗余。在劃分1）時，有測試開關機得case，在劃分2）時，顯然也會有這樣得case。這是不可避免得，也沒有關系。$ Y4 a" D3 S8 C0 s& r1 m, d
% {- P) N  a& O. ?# X1 X& \
尋找某個特定得切面
上面得劃分系統(tǒng)可以看作對整個系統(tǒng)得一種分離方法，劃分方法得結(jié)果是把測試對象分成不同得一塊一塊。而“特定得切面”則只是描述了測試對象得一個面，它不存在劃分系統(tǒng)得問題。還是上面得例子，比如“長按按鈕”就是一個“特定得切面”。

”長按Power按鈕“是一個測試得關注點，“長按volumn+”也是這樣得一個關注點，如果在系統(tǒng)中多處存在這樣得相似得關注點，那么就構(gòu)成了一個面，比如在這里是每個按鈕都存在“長按按鈕”這樣一種可能，那么“長按按鈕”這就可以看作系統(tǒng)得一個切面。對于這樣一個切面，如果把它分散在每個功能測試case里，顯然不是好主意。最好得方法是把它拿出來作為一個單獨得testcase。

再舉一個例子是，“維護數(shù)據(jù)完整性” 是一個切面。很多系統(tǒng)都有用戶這個對象，很多其他得對象都會引用到它。對于引用已經(jīng)刪除得對象就是一個容易出問題得地方。那么就把“刪除用戶”作為一個切面拿出來，對每一個相關得對象進行測試。這樣一個切面是非常好得testcase。
" I6 ?5 {" ^# P7 q- k
說到這里，你可能會發(fā)現(xiàn)這其實是面向方面編程(AOP)得概念。bingo！確實如此，好得思想方法在哪里都會閃光啊~_*.
/ I2 R0 X2 L3 K7 |) W
" X" F/ U/ Q2 g5 h$ q" {
2. 功能單元測試
面對一個比較小得功能單元，設計testcase就容易得多了。因為功能單元千差萬別，所以我僅僅寫一些相對通用得思路。9 h3 l5 }3 e+ K; v, e2 K6 [
. Q% d5 g( ~  w, w
1）從4個可能變化的要素入手：輸入，輸出，參數(shù)和狀態(tài)。+ {1 P/ B; n' h3 W$ _4 s/ i
如果把某個功能想象成一個黑盒子，那么這個黑盒子任何時候得輸出可以用下面得三個參數(shù)來確定（輸入，狀態(tài)，參數(shù)）。這種方法可以對功能進行詳盡得測試。

2）黑盒子得生命周期$ J9 A- U) a7 @' A& j! F" Z
盒子不是憑空出現(xiàn)的，它也不是在真空之中。在它的生命周期中，有那些東西能影響它？它的初始化，重啟動，關閉。。。
+ w4 r6 \9 T2 E( ^
3）GUI測試% ?* |1 O. `% H, Y
一個功能單元可能有GUI，那么他們也應該在這里測試。我們以GUI測試為例，GUI有它自己的特點
1. GUI很容易變化2 o3 j# J3 V# A  m6 ?
2. GUI一般不容易錯，因為GUI不包含復雜的邏輯
3. GUI的錯誤很容易看出來，很多GUI問題其實看一下就知道了，比如字體不對
4. GUI難以描述。GUI涉及的內(nèi)容很多顏色，布局，字體。。。
所以對于GUI的測試用例，應該給出一個關鍵點，而不用給出具體的描述。比如“檢查label字體”比“字體是宋體，大小11，斜體“要好，當然除非特別要求2 Q& @#

共1 條記錄, 每頁顯示 10 條, 頁簽: [1]