技术开发 频道

提高测试用例覆盖率的分析方法

【IT168 技术文章】

    开发高质量的测试用例 是测试工程师的基本工作。那什么才算是高质量的测试用例呢?——高质量的测试用例是既有高覆盖性又有高可执行性,当两者不可兼得时,它有非常好的平衡点。本文不讨论如何取得非常好的平衡,只关注采用何种分析方法来提高测试用例的覆盖率。

    首先来说,分析分为两个步骤,首先以不同得角度切分系统,使得它成为更简单的模块,第二是把不同的模块想象成一个黑盒子,对这个黑盒子做以下分析。

    1. 从不同得角度把系统分为不同得模块

    这里存在两种思路

    1.1 对系统进行完整得划分

    软件是复杂的。软件开发者面对这种复杂性采用的经典的方法瀑布模型,也就是从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块。对于软件测试来说,很自然的,我们也可以采用这种方法。但是,这还是远远不够的。我们还要从更多的角度切入系统,从不同的角度把系统切分成一块一块的,然后进行测试。

    比如遥控器的例子。我们就可以从下面一些方面来划分系统

    1 )功能。

    这个划分非常直观, Spec 上肯定会明确指明遥控器假设有 3 个功能,开关机, +- 调台, +- 调音。对每个功能我们测试它能否正常工作。当然我们也会注意到边界情况:当音量满的时候,加音量...

    2 )状态

    Spec 上没有说明遥控器的状态,但我们应该能分析得出遥控器有下面的状态

    关机,开机,正在调台,正在调音

    现在我们可以列一个 matrix ,测试在每种状态下执行上面的任意一种操作系统的反应。注意,这个时候,你就要把你自己当成用户,因为这些情况都不会在 spec 里详细的说明的。比如在关机状态下调音,竟然开机了。这个显然就是bug 。

    3 )按键序列

    现在我们走得更远。我们把遥控器看作具有按钮得一个玩意儿,然后输入任意一个序列看是否会出现异常情况,是否会让程序不正常得工作。这里不需要分任何得分析方法。这是一个很好得切入点。另外一个例子是,在测试 web application 时,做一个爬虫程序去点击页面上得任何 link 。

    通过这些不同得划分, testcase 的覆盖率可以得到有效得提高。

    需要注意一点是,不同得划分肯定会带来 testcase 得冗余。在划分 1 )时,有测试开关机得 case ,在划分 2 )时,显然也会有这样得 case 。这是不可避免得,也没有关系。

    1.2 寻找某个特定得切面

    上面得划分系统可以看作对整个系统得一种分离方法,划分方法得结果是把测试对象分成不同得一块一块。而 “ 特定得切面 ” 则只是描述了测试对象得一个面,它不存在划分系统得问题。还是上面得例子,比如 “ 长按按钮 ” 就是一个 “ 特定得切面 ” 。

    “长按 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 ,斜体 “ 要好,当然除非特别要求。如果有特别的要求,应该依据具体的需求来进行设计。

 

0
相关文章