如何通过自动化随着时间的推移增加测试覆盖率
Posted 隔壁王书
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何通过自动化随着时间的推移增加测试覆盖率相关的知识,希望对你有一定的参考价值。
当涉及到软件质量时,我们希望尽可能多地以人工测试代码,实际上,对于每个测试周期,重要的是要考虑多种策略来衡量测试覆盖率,并将系统部署到位。
测试覆盖率是测试质量的度量之一,它告诉我们被测试的应用程序有多少已经过测试。你可以把它想象成打扫房子的地板。想象一下,如果我的清扫范围标准只包括清扫卧室。按照这个标准,如果我打扫了100%的卧室,那是否意味着整个房子是干净的?不,因为还有厨房,餐厅,浴室…你懂的!因此,必须始终小心测试覆盖率,认识到有时它有局限性。
测试覆盖率用于定义软件的某些部分,以便用测试覆盖它们。它还告诉我们何时进行了充分的测试,让我们知道还需要测试什么(从而扩大覆盖范围),并帮助我们定量地了解测试的范围。这是一个很好的衡量标准,即使有 100% 的测试覆盖率,我们也不能保证我们的应用程序 100% 没有错误。
有很多方法可以考虑测试覆盖率。在这里,我们将检查代码覆盖率、面向数据的覆盖率以及测试人员可以使用的大量其他技术。
代码覆盖率
代码覆盖率是衡量测试覆盖率最常用的指标。它测量测试用例覆盖的行数,报告代码中的行总数和测试执行的行数。本质上,它是测试套件运行时程序源代码的执行程度。代码覆盖率越高,未被发现的bug进入生产的可能性就越小。这种测量也可以分解为不同的层次;不仅包括代码行,还包括分支、逻辑构造函数内部的决策等。
面向数据的覆盖
在面向数据的覆盖范围中,有输入和输出参数,每个参数都有自己的域(它们可以拥有的可能值的范围)。如果考虑所有的可能性,你会得到一个笛卡尔积,因为可以测试每一个可能的组合。
其他类型的保险
除了前面提到的方法之外,还有其他几种方法可以涵盖正在测试的产品,如状态机、决策表、决策树、等价划分和边界值等。每种技术都有“错误理论”的支持。错误理论考虑了程序员犯下的典型错误。例如,等价分区和边界值考虑了使用“<”而不是“<=”的错误,误解了业务逻辑等。
此外,还有其他类型的测试覆盖率与代码行或输入测试数据无关。我们必须涵盖的一点是移动碎片化:我们是否涵盖了主要的移动设备、操作系统和屏幕尺寸?当谈到浏览器和操作系统时,我们必须考虑我们的web系统在操作系统和浏览器的任何组合中的行为,以及我们应该测试多少个组合。最后,我们必须考虑测试环境、上下文等。
制定计划以优化长期覆盖范围
假设我们在不同的浏览器上测试不同的特性,并且用不同的测试套件组织了不同的测试用例,每个测试套件都有自己的优先级。我们需要针对所有浏览器执行最关键的命令,但其余的,我们可以决定在不同的浏览器上执行。我们永远不能保证我们已经完成了测试,但是当时间紧迫时,必须明智地尽最大努力降低风险。
结论
测试覆盖标准非常有用,但它们并不能保证任何事情。一些标准与其他标准相关,我们需要使用最适合我们需求的模块,还要考虑每个模块的优先级,并根据优先级和复杂性定义每个模块的覆盖范围。最后,我们可以应用长期覆盖率标准来优化测试覆盖率。
演示工具:www.eolinker.com
以上是关于如何通过自动化随着时间的推移增加测试覆盖率的主要内容,如果未能解决你的问题,请参考以下文章
swift spritekit 随着游戏时间的推移增加重力?