白盒测试能做什么?

最近和学员们讨论白盒测试,大家都觉得很陌生很远,而且技术难度大,应该是开发做的吧?今天我们先撇开白盒测试需要的技术手段,先讨论一下白盒测试如何保证产品的质量。

首先,我们先思考一个问题。比如一个产品测试A写了500条用例,而测试B只写了200条用例。那如何评判和证明是A还是B的测试用例覆盖率更高呢?

有同学回答:通过bug数来衡量。这是一个好的想法,但是我觉得还是不够严谨。很多时候产品的bug并不是测试用例发现的,而是随机测试或者fuzzing 测试发现的。完全通过bug来衡量测试用例的覆盖率有作弊嫌疑。另外,假设200个用例覆盖的场景发现了2个bug,而500个用例仅覆盖了部分200个用例的覆盖的场景和另外一些场景,但是500个用例只发现了1个bug。那能证明200个用例的覆盖率就高于500个吗?显然不行的,我们还需要更加科学的方式和硬性的指标。

那么,我们看一下白盒测试,白盒测试的第一步是对被测试的代码进行instrument(俗称:打桩)。打桩其实就是对每一行代码和每一个函数进行标记,然后再重新编译。第二步就是执行所有的测试用例(包括:自动化和功能的用例),这里请注意,不是仅仅跑自动化的用例或者单元测试用例,还包括功能测试用例。当所有的测试用例都跑完后,再通过代码覆盖率工具将覆盖率计算出来。那么,这份代码覆盖率就是所有测试用例的代码覆盖率,通过这份代码覆盖率能够准确的衡量测试用例对产品的功能的覆盖。

一般情况下,通过查看代码覆盖率,将未覆盖的代码片段,再有针对性的设计测试用例进行覆盖。尽可能的覆盖所有产品代码。当然,一些try catch或者异常场景可能也是没有办法覆盖的。通常情况下,函数覆盖率需要达到80%以上,行覆盖率需要达到70%以上

另外,函数覆盖率即是达到了90%,也并不能说明测试用例就完美了。有一些多线程,互斥的场景仅通过函数覆盖率是没法完全保证的,还需要更多测试的经验。

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/paischool/article/details/89174965