<ul id="is4kg"></ul> <abbr id="is4kg"></abbr> <ul id="is4kg"></ul> | 以文本方式查看主題 - 曙海教育集團論壇 (http://www.hufushizhe.com/bbs/index.asp) -- 軟件測試 (http://www.hufushizhe.com/bbs/list.asp?boardid=70) ---- 提高測試用例覆蓋率的分析方法 (http://www.hufushizhe.com/bbs/dispbbs.asp?boardid=70&id=2654) |
| -- 作者：wangxinxin -- 發布時間：2010-12-15 11:58:06 -- 提高測試用例覆蓋率的分析方法 開發高質量的測試用例是QA的基本工作。高質量的測試用例是既有高覆蓋性又有高可執行性，當兩者不可兼得時，它有最佳平衡點。本文不討論如何取得最佳平衡，只關注采用何種 分析方法 來提高測試用例的覆蓋率。 3 P9 T1 q. s4 G 首先來說，分析分為兩個步驟，首先以不同得角度切分系統，使得它成為更簡單得模塊，第二是把不同得模塊想象成一個黑盒子，對這個黑盒子做類似于單元測試得分析。 & h3 L" K\' k\' g7 { k& |\' x 1. 從不同得角度把系統分為不同得模塊 這里存在兩種思路 對系統進行完整得劃分 軟件是復雜的。軟件開發者面對這種復雜性采用的經典的方法瀑布模型，也就是從上到下，逐漸細分，大模塊包括小模塊，小模塊包括更小的模塊。對于軟件測試來說，很自然的，我們也可以采用這種方法。但是，這還是遠遠不夠的。我們還要從更多的角度切入系統，從不同的角度把系統切分成一塊一塊的，然后進行測試。 2 P! c1 q- v* V/ M6 | i 比如遙控器的例子。我們就可以從下面一些方面來劃分系統 1）功能。% {& D0 J) d* w 這個劃分非常直觀，Spec上肯定會明確指明遙控器假設有3個功能，開關機，+-調臺，+-調音。對每個功能我們測試它能否正常工作。當然我們也會注意到邊界情況：當音量滿的時候，加音量。。。& R* w$ U2 h7 Q. P4 a3 W, M, G4 { 2）狀態 Spec上沒有說明遙控器的狀態，但我們應該能分析得出遙控器有下面的狀態1 f1 Q0 f# x! g& v! l& {. | ? 關機，開機，正在調臺，正在調音 現在我們可以列一個matrix，測試在每種狀態下執行上面的任意一種操作系統的反應。注意，這個時候，你就要把你自己當成用戶，因為這些情況都不會在spec里詳細的說明的。比如在關機狀態下調音，竟然開機了。這個顯然就是bug。( A3 s; j$ K" d8 V& e- p 3）按鍵序列) h( {2 \\9 I: F\' ~7 H( G+ r 現在我們走得更遠。我們把遙控器看作具有按鈕得一個玩意兒，然后輸入任意一個序列看是否會出現異常情況，是否會讓程序不正常得工作。這里不需要分任何得分析方法。這是一個很好得切入點。另外一個例子是，在測試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& \\ 尋找某個特定得切面 上面得劃分系統可以看作 對整個系統得一種 分離方法，劃分方法得結果是把測試對象分成不同得一塊一塊。而“特定得切面”則只是描述了測試對象得一個面，它不存在劃分系統得問題。還是上面得例子，比如“長按按鈕”就是一個“特定得切面”。 ”長按Power按鈕“是一個測試得關注點，“長按volumn+”也是這樣得一個關注點，如果在系統中多處存在這樣得相似得關注點，那么就構成了一個面，比如在這里是每個按鈕都存在“長按按鈕”這樣一種可能，那么“長按按鈕”這就可以看作系統得一個切面。對于這樣一個切面，如果把它分散在每個功能測試case里，顯然不是好主意。最好得方法是把它拿出來作為一個單獨得testcase。 再舉一個例子是，“維護數據完整性” 是一個切面。很多系統都有用戶這個對象，很多其他得對象都會引用到它。對于引用已經刪除得對象就是一個容易出問題得地方。那么就把“刪除用戶”作為一個切面拿出來，對每一個相關得對象進行測試。這樣一個切面是非常好得testcase。 " I6 ?5 {" ^# P7 q- k 說到這里，你可能會發現這其實是面向方面編程(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個可能變化的要素入手：輸入，輸出，參數和狀態。+ {1 P/ B; n\' h3 W$ _4 s/ i 如果把某個功能想象成一個黑盒子，那么這個黑盒子任何時候得輸出可以用下面得三個參數來確定（輸入，狀態，參數）。這種方法可以對功能進行詳盡得測試。 2）黑盒子得生命周期$ J9 A- U) a7 @\' A& j! F" Z 盒子不是憑空出現的，它也不是在真空之中。在它的生命周期中，有那些東西能影響它？它的初始化，重啟動，關閉。。。 + 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涉及的內容很多顏色，布局，字體。。。 所以對于GUI的測試用例，應該給出一個關鍵點，而不用給出具體的描述。比如“檢查label字體”比“字體是宋體，大小11，斜體“要好，當然除非特別要求2 Q& @# |