開發高質量的
測試用例是QA的基本
工作。高質量的測試用例是既有高覆蓋性又有高可執行性，當兩者不可兼得時，它有最佳平衡點。本文不討論如何取得最佳平衡，只關注采用何種 分析方法 來提高測試用例的覆蓋率。
# f5 p6 K9 u, J2 F( @: W" S8 X T5 p3 P9 T1 q. s4 G 首先來說，分析分為兩個步驟，首先以不同得角度切分系統，使得它成為更簡單得模塊，第二是把不同得模塊想象成一個黑盒子，對這個黑盒子做類似于
單元測試得分析。
# X6 ]. s" { D) T$ t9 u& h3 L" K' k' g7 { k& |' x 1. 從不同得角度把系統分為不同得模塊
, v$ {( H3 i1 g, f: }8 ] 這里存在兩種思路
% F" D( P0 {5 F7 D% B2 u$ M; u( y, J( l: [; ~ 對系統進行完整得劃分
$ L# [% Y1 X, M 軟件是復雜的。軟件開發者面對這種復雜性采用的經典的方法瀑布模型，也就是從上到下，逐漸細分，大模塊包括小模塊，小模塊包括更小的模塊。對于
軟件測試來說，很自然的，我們也可以采用這種方法。但是，這還是遠遠不夠的。我們還要從更多的角度切入系統，從不同的角度把系統切分成一塊一塊的，然后進行測試。
4 v& M, ?0 w& J V4 w2 P! c1 q- v* V/ M6 | i 比如遙控器的例子。我們就可以從下面一些方面來劃分系統
* z l% a2 D# G$ e 1）功能。
% {& D0 J) d* w 這個劃分非常直觀，Spec上肯定會明確指明遙控器假設有3個功能，開關機，+-調臺，+-調音。對每個功能我們測試它能否正常工作。當然我們也會注意到邊界情況：當音量滿的時候，加音量。。。
& R* w$ U2 h7 Q. P4 a3 W, M, G4 { 2）狀態
U5 P8 K6 h' n5 `& `. i7 F1 U Spec上沒有說明遙控器的狀態，但我們應該能分析得出遙控器有下面的狀態
1 f1 Q0 f# x! g& v! l& {. | ? 關機，開機，正在調臺，正在調音
, }: p8 c8 N4 g- U 現在我們可以列一個matrix，測試在每種狀態下執行上面的任意一種
操作系統的反應。注意，這個時候，你就要把你自己當成用戶，因為這些情況都不會在spec里詳細的說明的。比如在關機狀態下調音，竟然開機了。這個顯然就是bug。
( A3 s; j$ K" d8 V& e- p 3）按鍵序列
) h( {2 \9 I: F' ~7 H( G+ r 現在我們走得更遠。我們把遙控器看作具有按鈕得一個玩意兒，然后輸入任意一個序列看是否會出現異常情況，是否會讓程序不正常得工作。這里不需要分任何得分析方法。這是一個很好得切入點。另外一個例子是，在測試
web application時，做一個爬蟲程序去點擊頁面上得任何link。
2 D# ~2 Z" P! m; I% l* N# 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& \ 尋找某個特定得切面
: d: ]9 f) \6 J 上面得劃分系統可以看作 對整個系統得一種 分離方法，劃分方法得結果是把測試對象分成不同得一塊一塊。而“特定得切面”則只是描述了測試對象得一個面，它不存在劃分系統得問題。還是上面得例子，比如“長按按鈕”就是一個“特定得切面”。
$ V5 d7 l! W8 L! V, b1 F3 s2 U5 ]9 [/ C ”長按Power按鈕“是一個測試得關注點，“長按volumn+”也是這樣得一個關注點，如果在系統中多處存在這樣得相似得關注點，那么就構成了一個面，比如在這里是每個按鈕都存在“長按按鈕”這樣一種可能，那么“長按按鈕”這就可以看作系統得一個切面。對于這樣一個切面，如果把它分散在每個功能測試case里，顯然不是好主意。最好得方法是把它拿出來作為一個單獨得testcase。
4 e3 g8 O" N) v% K3 n2 G2 i T& ` 再舉一個例子是，“維護數據完整性” 是一個切面。很多系統都有用戶這個對象，很多
其他得對象都會引用到它。對于引用已經刪除得對象就是一個容易出問題得地方。那么就把“刪除用戶”作為一個切面拿出來，對每一個相關得對象進行測試。這樣一個切面是非常好得testcase。
4 v# R6 T- e: N3 O$ P& ^" I6 ?5 {" ^# P7 q- k 說到這里，你可能會發現這其實是面向方面編程(AOP)得概念。bingo！確實如此，好得思想方法在哪里都會閃光啊~_*.
, a" c4 r% d$ z1 B7 o' A/ I2 R0 X2 L3 K7 |) W" X" F/ U/ Q2 g5 h$ q" { 2. 功能單元測試
' i% G8 ]& s% W( e& D6 G% ? 面對一個比較小得功能單元，設計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 如果把某個功能想象成一個黑盒子，那么這個黑盒子任何時候得輸出可以用下面得三個參數來確定（輸入，狀態，參數）。這種方法可以對功能進行詳盡得測試。
/ }% D* y' V$ v1 Q P u! R" @" k% c) K 2）黑盒子得生命周期
$ J9 A- U) a7 @' A& j! F" Z 盒子不是憑空出現的，它也不是在真空之中。在它的生命周期中，有那些東西能影響它？它的初始化，重啟動，關閉。。。
# A) [0 _+ \" w+ w4 r6 \9 T2 E( ^ 3）GUI測試
% ?* |1 O. `% H, Y 一個功能單元可能有GUI，那么他們也應該在這里測試。我們以GUI測試為例，GUI有它自己的特點
9 M0 ^2 ~0 j) K* V9 h7 T4 h, ]0 @ 1. GUI很容易變化
2 o3 j# J3 V# A m6 ? 2. GUI一般不容易錯，因為GUI不包含復雜的邏輯
1 L0 T z" c( a! | 3. GUI的錯誤很容易看出來， 很多GUI問題其實看一下就知道了，比如字體不對
" q- h$ P1 ^. j 4. GUI難以描述。GUI涉及的內容很多顏色，布局，字體。。。
. F9 L: ]' l9 q2 X" { ? 所以對于GUI的測試用例，應該給出一個關鍵點，而不用給出具體的描述。比如“檢查label字體”比“字體是宋體，大小11，斜體“要好，當然除非特別要求
2 Q& @#