单元测试---一个不应该存在的测试环节

        单元测试是目前动态测试过程中的一个重要环节。在具体测试活动中,要将被测单元中所调用的其它单元进行数据模拟或者功能模拟,以使被测单元不受其它单元所影响。单元测试的后继环节是集成测试,它同单元测试的主要区别就是不对入口单元中调用的其它单元进行模拟。

        然而,在测试实践中,很多测试人员抱怨单元测试没有用,或者直接省略掉单元测试环节。因为经常会发生这种情况:一个被测单元及其调用的单元在单元测试环节都通过了,可是在集成测试环节却不能通过。将问题及相关用例反馈到开发方后,开发方发现问题出现在某个在单元测试环境的“测试通过”的单元。于是问题来了,单元测试中的“测试通过”有意义吗?当然,很多人会说,同盖房子一样,即使所有建筑构件都没有问题,盖起来的房子也可能会塌呀!这不正说明集成测试的意义吗?这个说法看似很有道理,可深究起来却存在很大的问题。最主要的一个问题是:建筑构件之间是独立的,而被测单元同其所调用的单元却不是独立的。从设计及应用的角度来说,被调用的单元就是被测单元的一部分,而动态测试的根本目的就是检查二进制形式的代码是否同设计相符合。因此,被测单元及其所有被调单元如果在单元测试环节均测试通过,该单元就应该在集成测试环节通过。那问题到底出现在哪里呢?

        通过比对集成测试和单元测试二者在测试实践中的区别,可以发现区别就是是否对被调用单元进行模拟,当然也会涉及到一些后续影响。比如说输入项、输出项、用例集合、覆盖率等。而恰恰就是因为这个环节,造成单元测试结论“不准确”。因为无论是采用何种方法模拟,只要同被调用单元不完全一样,就不可能完全等同于被调用单元,这就导致了实际测试的单元并非真正的被测单元,而测试结果自然也就不是对被测单元的真实测试结果了。由此可知,测试人员抱怨是有道理的,在被测试单元中调用了其它单元的情况下,单元测试很可能是不准确的。

        更为合理的测试方式应该是将单元测试和集成测试混合为一个测试环节。首先由分析工具得出被测代码所有被测单元之间的调用关系树,该树有可能是多根树。然后从叶子结点开始测试,然后对枝干节点测试,最后对根节点测试。换句话说,就是仅仅做集成测试也就够了。如果仅仅做集成测试,很可能有人会担心会产生覆盖不够的问题。因为出于通用性方面的考虑,被调用单元一般会对调用单元所需要的处理逻辑进行了一定程度的泛化。而测试完成通常定义为覆盖率达到了预设目标,一般情况下是覆盖率达到100%。如果不将被调用单元进行模拟,很可能用例集的覆盖率达不到预设的目标。 既然单元测试这个环节都省略了,相应的用例的处理以及测试目标也都要随之调整。如果把叶子结点定义为最上层节点,把根节点定义为最下层节点,那么,由叶到根的测试顺序还有另外一层含义,就是在上级节点测试完成后,在进行测试下级节点时,要根据上层节点的用例集逆推出下级节点的一个用例子集合,当然在上级节点中的用例可能在下级节点中没有对应的用例,对于这样的用例,记录下该用例所能进行的覆盖,在对下级单元进行覆盖时,对这个的用例所设计的覆盖进行豁免,这样就可以避免测试不能正常完成的问题。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

plstudio1

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值