| 以文本方式查看主题 - 曙海教育集团论坛 (http://peixun0.cn/bbs/index.asp) -- 软件测试 (http://peixun0.cn/bbs/list.asp?boardid=70) ---- 提高测试用例覆盖率的分析方法 (http://peixun0.cn/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& @# |