开发高质量的测试用例是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, b
1 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& @#