首先来说，分析分为两个步骤，首先以不同得角度切分系统，使得它成为更简单得模块，第二是把不同得模块想象成一个黑盒子，对这个黑盒子做类似于单元测试得分析。
1. 从不同得角度把系统分为不同得模块
这里存在两种思路
对系统进行完整得划分
软件是复杂的。软件开发者面对这种复杂性采用的经典的方法瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。对于软件测试来说，很自然的，我们也可以采用这种方法。但是，这还是远远不够的。我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，然后进行测试。
比如遥控器的例子。我们就可以从下面一些方面来划分系统
1）功能。
这个划分非常直观，Spec上肯定会明确指明遥控器假设有3个功能，开关机，+-调台，+-调音。对每个功能我们测试它能否正常工作。当然我们也会注意到边界情况：当音量满的时候，加音量。。。
2）状态
Spec上没有说明遥控器的状态，但我们应该能分析得出遥控器有下面的状态
关机，开机，正在调台，正在调音
现在我们可以列一个matrix，测试在每种状态下执行上面的任意一种操作系统的反应。注意，这个时候，你就要把你自己当成用户，因为这些情况都不会在spec里详细的说明的。比如在关机状态下调音，竟然开机了。这个显然就是bug。
3）按键序列
现在我们走得更远。我们把遥控器看作具有按钮得一个玩意儿，然后输入任意一个序列看是否会出现异常情况，是否会让程序不正常得工作。这里不需要分任何得分析方法。这是一个很好得切入点。另外一个例子是，在测试web application时，做一个爬虫程序去点击页面上得任何link。
通过这些不同得划分，testcase得覆盖率可以得到有效得提高。
需要注意一点是，不同得划分肯定会带来testcase得冗余。在划分1）时，有测试开关机得case，在划分2）时，显然也会有这样得case。这是不可避免得，也没有关系。
寻找某个特定得切面
上面得划分系统可以看作 对整个系统得一种 分离方法，划分方法得结果是把测试对象分成不同得一块一块。而“特定得切面”则只是描述了测试对象得一个面，它不存在划分系统得问题。还是上面得例子，比如“长按按钮”就是一个“特定得切面”。
”长按Power按钮“是一个测试得关注点，“长按volumn+”也是这样得一个关注点，如果在系统中多处存在这样得相似得关注点，那么就构成了一个面，比如在这里是每个按钮都存在“长按按钮”这样一种可能，那么“长按按钮”这就可以看作系统得一个切面。对于这样一个切面，如果把它分散在每个功能测试case里，显然不是好主意。最好得方法是把它拿出来作为一个单独得testcase。
再举一个例子是，“维护数据完整性” 是一个切面。很多系统都有用户这个对象，很多其他得对象都会引用到它。对于引用已经删除得对象就是一个容易出问题得地方。那么就把“删除用户”作为一个切面拿出来，对每一个相关得对象进行测试。这样一个切面是非常好得testcase。
说到这里，你可能会发现这其实是面向方面编程(AOP)得概念。bingo！确实如此，好得思想方法在哪里都会闪光啊~_*.
2. 功能单元测试
面对一个比较小得功能单元，设计testcase就容易得多了。因为功能单元千差万别，所以我仅仅写一些相对通用得思路。
1）从4个可能变化的要素入手：输入，输出，参数和状态。
如果把某个功能想象成一个黑盒子，那么这个黑盒子任何时候得输出可以用下面得三个参数来确定（输入，状态，参数）。这种方法可以对功能进行详尽得测试。
2）黑盒子得生命周期
盒子不是凭空出现的，它也不是在真空之中。在它的生命周期中，有那些东西能影响它？它的初始化，重启动，关闭。。。
3）GUI测试
一个功能单元可能有GUI，那么他们也应该在这里测试。我们以GUI测试为例，GUI有它自己的特点
1. GUI很容易变化
2. GUI一般不容易错，因为GUI不包含复杂的逻辑
3. GUI的错误很容易看出来， 很多GUI问题其实看一下就知道了，比如字体不对
4. GUI难以描述。GUI涉及的内容很多颜色，布局，字体。。。
所以对于GUI的测试用例，应该给出一个关键点，而不用给出具体的描述。比如“检查label字体”比“字体是宋体，大小11，斜体“要好，当然除非特别要求
此文来源于51testing博客,转载请注明出处
原始链接：http://www.51testing.com/?764/action_viewspace_itemid_11848.html
