测试覆盖率 精准测试之覆盖

小小 · 2023年05月09日 · 4824 次阅读

原创:前京东工业 宛煜昕

代码覆盖率测试与测试覆盖率在软件工程中,存在着对代码覆盖测试和测试覆盖测试的混淆。

•代码覆盖测试是一种软件测试技术,用于衡量在运行测试时程序源代码中有多少被执行。这意味着代码覆盖测试衡量了程序源代码被测试的程度,它提供了关于测试期间哪些源代码组件被执行以及哪些部分没有被执行的详细信息。代码覆盖测试应该与测试覆盖测试区分开来,并且不应该互换使用。
•测试覆盖率是软件测试过程中执行的测试用例所覆盖的代码和功能需求等比例程度。测试覆盖率测试是一种定量的测试方法,用于衡量测试用例对被测试软件的覆盖程度。它通常由质量保证团队执行,以确保测试已覆盖多个规格文档,如功能需求规格、软件需求规格和用户需求规格等。与代码覆盖测试相比,测试覆盖率测试更加关注软件功能需求的覆盖程度,而不是代码执行的覆盖程度。
下面是代码覆盖和测试覆盖之间的关键区别:

是一种定量的度量方式 它在大多数情况下是定性的。
是一种白盒测试方法,测试人员检查和验证软件系统的内部工作方式,尤其是代码及其集成 是一种黑盒测试方法,测试软件的功能,不知道软件代码的内部结构及其实现方式。
一、覆盖率与测试策略
测试策略按测试过程一般分为单元测试、集成测试、系统测试和验收测试四大阶段;按软件内部工作过程又有白盒、灰盒、黑盒;从过程是否执行软件又可将测试方法分为静态和动态。这样白盒测试对应着软件测试过程中的单元测试,一般由开发人员完成,而灰盒测试与黑盒测试一般测试人员介入较多,对应着集成测试、系统测试和验收测试。
•代码覆盖率的测试策略主要包括:
1、选择合适的覆盖率标准:常见的覆盖率标准有语句覆盖率、分支覆盖率、条件覆盖率、路径覆盖率等,需要根据软件测试的需求和目标选择合适的覆盖率标准。
2、制定测试计划:制定测试计划是评估代码覆盖率的前提,测试计划需要根据需求文档、功能规格说明等,设计测试用例。
3、设计测试用例:针对不同的覆盖率标准,设计不同的测试用例,以达到对目标代码进行覆盖的目的。
4、执行测试用例:执行设计好的测试用例,记录测试结果。
5、计算覆盖率:使用相应的工具对目标代码进行覆盖率计算,得出代码覆盖率并进行分析。
代码覆盖率的测试策略主要是确保测试能够覆盖代码的所有执行路径和分支,以此来保证代码的正确性和可靠性。其中,包括以下几个方面:
1、语句覆盖:确保每一条代码语句都被测试至少执行一次。
2、分支覆盖:确保每个条件语句的每个分支都被测试至少执行一次。
3、条件覆盖:确保每个条件语句的每个条件都被测试至少执行一次,包括 true 和 false。
4、路径覆盖:确保代码中每个可能的执行路径都被测试至少执行一次,包括循环和递归等。
•测试覆盖率的测试策略主要包括:
1、定义测试目标:根据软件需求和设计文档,明确测试目标,确定需要覆盖的测试区域、度量,可以基于需求、功能规格说明、用例等不同的基础上进行度量,需要根据项目实际情况确定测试覆盖率的度量方法。
2、制定测试计划:制定测试计划是评估测试覆盖率的前提,测试计划需要根据需求文档、功能规格说明等,设计测试用例。
3、设计测试用例:设计覆盖测试目标的测试用例,确保每个测试点都能被覆盖。
4、执行测试用例:执行设计好的测试用例,记录测试结果。
5、收集和计算测试覆盖率:收集测试覆盖率数据,使用相应的工具对测试目标进行覆盖率计算,得出测试覆盖率并进行分析,找出测试覆盖率低的地方,进行补充测试。
测试覆盖率的测试策略则是确保测试能够覆盖所有的需求和功能点,以此来保证软件的功能完整性和一致性。其中,包括以下几个方面:
1、需求覆盖:确保每个需求都被测试至少一次。
2、功能覆盖:确保每个功能点都被测试至少一次,包括各种输入、输出、错误处理等。
3、接口覆盖:确保软件的各个接口都被测试至少一次,包括与其他系统的交互等。
4、性能覆盖:确保软件在各种负载和条件下的性能都被测试至少一次,包括并发、响应时间、资源利用等。

二、覆盖率的基本应用
•使用代码覆盖测试的好处是可以高效且具体的代码检查,并有高质量代码,还能提高代码的清晰度和信任度。
这里有一些不错的技巧,如:使用自动化代码覆盖率测量工具,使用自动化单元测试生成工具,编写全面的测试用例,编写优先测试,定期审查代码覆盖率结果,将代码覆盖测试集成到软件开发周期中,注意边界情况,持续重构代码。
而一些"陷阱"需要注意,如:视角不足,较高的时间成本,解释的挑战。
•下面主要说下使用测试覆盖测试,
在测试时会有这样一些担心,如:无止境的、没有范围的,代码的改动或调整一个需求,需要全量回归测试,代码中的调用、业务间、功能模块间的关联关系、影响范围不清楚,某个功能或功能点是否需要测试,测试的进展、程度如何等等的问题。
举个例子:需求是查询 id 与展示 id 相关数据的功能,进一步分析要做(开发)id 输入框,【查询】按钮,显示的列表,涉及 1 个查询接口(HTTP),查库(数据库)的话,需要 1 条 SQL 语句。
开发后得到前端 id 输入框,【查询】按钮和结果列表,

后端是通过一个查询方法调到数据库得到数据,显示在前端页面。

应用测试覆盖率
1、建立测试范围,这里简单些了,只是功能的,

2、需求分析、用例设计、执行、提 bug 等,就是执行测试的过程,
3、得到功能测试的结果。

这么看上去没什么问题,双相的追溯(需求、用例、缺陷)已经是全覆盖了,那怕在算上接口,但也仅仅是功能上的覆盖,可能部分逻辑会有遗漏,如:代码等层面上的覆盖,
代码中要有对查询 id 的判断,可能部分判断会有遗漏,因为仅从功能或黑盒测试来讲,不知道这个判断是否执行。
这时测试覆盖是要由测试需求和测试用例的覆盖或已执行代码的覆盖表示。建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析的基础上。
•改善这一情况,结合代码覆盖率工具,
在"2、需求分析、用例设计、执行、提 bug 等,就是执行测试的过程"中加入,弥补这一缺失,覆盖率的表格也需要优化下,

表格中类名、方法名的覆盖率结果可根据情况得出,如:覆盖率的计算由浅入深来说一般从功能、功能点、接口、代码中类、方法等得到,如:两个功能、三个功能点,以功能点为覆盖,覆盖率公式为(至少执行一次的功能点 / 功能点总数)* 100% = (1 / 1)*100%,查询按钮的覆盖率为 100%
注:测试结果是否通过,不单是看覆盖率,还要通过测试用例的执行,缺陷的关闭等情况来决定。

三、覆盖率的可视化
通过完全手工绘制已经有了初步概念,考虑些许情况,这种已经不能满足于此。
面对复杂的业务系统,经验已经把业务功能、逻辑关系等相关知识点深深的印在当事人的脑子里,而要沉淀、展示于旁人,这就是一个让人很头疼的问题,就像告诉一个人从哪里到哪里一样,讲的人清楚,但听得人却有些一头雾水,此时如果有个地图就一目了然了。

通过一些维度的图形展示,谁都可以直观、更好的加深对系统的了解。"知识库"中保存着涉及到的功能、接口等信息。简单实现,现在有了共享表格,可以直接维护上去,形式是哪种并不重要,主要是掌握了方法。
•链路关系
像这样,业务系统 - 页面 - 功能 - 接口 - 代码(拓扑图),业务系统 - 页面 - 功能 - 接口 - 架构(拓扑图)。

·功能层面
实现方式上比如可以像文件目录那样实现一颗树,某个页面下有哪些功能,功能中有哪些接口,而接口中有代码的类、方法及覆盖率等信息。

或者可以采用类似知识图谱来构建一个结构化的语义知识库,页面、功能、接口信息,可视为实体 - 节点,而彼此间的关系既是连接的线。或者接口信息也可看做是属性值。

·代码关系调用层面
从接口下去就到了代码层面,可以看到某接口发起后,代码中各方法间的调用链路和其他数据分析结果,

这里不仅能看到单个接口中代码关系图,还能展示出不同的多个接口与代码的关联关系,

当关注到代码层面的覆盖后,好处很多,其中有可以更好帮助开发提高或约束代码质量,问题的定位找到等,比如:代码中有时判断会使用常量,而不是枚举或宏/全局变量。当然也可以看到执行的代码分支、关系,每条代码逻辑分支是否执行到等。
·应用/服务间调用层面
通过平台获取到的数据,不仅可以做功能、代码层面的覆盖,系统架构也可完成可视化的呈现,
比如:应用服务的环境模块拓扑图

应用/服务与中间件调用链的拓扑图

还是用查询功能举例,有时因为一些需要,该功能下使用了缓存。当第一次查询是直接从数据库中查询回来的数据,同时也在缓存中记录了该条数据,而在一定时间内再查询,实则是从缓存中查询回来的。同样的,如果只覆盖了功能,这里可能会有所遗漏,从功能来看,查询后数据是返回了,而至于是从数据库还是从缓存获取到的,就不得而知了。再有是获取到的数据可能未必是想要的,奇怪的是,为什么输入/请求的数据,功能、接口都是一样的,而返回的数据在一段时间后就发生了变化。中间发生了什么不清楚,真的是"黑盒子"。想要知道 SQL 语句,只能费劲的从日志、代码或 xml 中查找,还有等等的不便问题。
除此之外,还可以展示不同接口与数据库的关系

只要脑洞够大,通过数据还可以实现出很多覆盖,并呈现出各种可视化图形。

四、未来已来
使用数据驱动将抽象的字符、逻辑等等可视化展示,从而得到想要的效果,但这种效果无论是静态或动态产生的、主动或被动的等等,都会遇到时间的问题,而对时间有着强依赖的我们,无论采用哪种开发方式,即使在快,有着时间的限制和约束,这种苦恼始终会伴随着,在现实世界中目前是无法解决,但有了虚拟世界,现在叫元宇宙,那就不同了,里面有还原现实一切的 1 比 1 模型,在虚拟世界里,可以搭建出想要的系统,每一个环节,无论是从项目或需求、产品设计、开发、测试到生产等各方环节,都可以清晰、透明、可视的关注到,无论功能与非功能均可以进行模拟,原来的项目或开发周期可能要 1 年,而现在可能半年不到的时间,通过虚拟现实和增强现实技术进行交互,最终是通过空间换取时间从而得到这宝贵的经验,然后这种虚拟产物可以搬到现实世界进行应用,从而避免很多试错,也大大压缩、节省了时间。目前这种方式已经慢慢被应用到各个行业、领域,这种虚拟与现实的结合可以更好地服务我们的生活。
而人工智能(AI)在软件测试领域中的应用已经逐渐增多,影响也逐渐显现出来。
•对于代码覆盖测试,AI 可以帮助测试人员更快地生成测试用例并自动执行测试。AI 可以分析源代码并识别潜在的问题,然后自动生成测试用例。例如,可以使用 AI 来确定哪些代码路径需要测试以及如何最好地测试它们。这种自动化过程可以加快软件测试的速度并提高覆盖率。
•对于测试覆盖测试,AI 可以帮助测试人员更好地评估测试的效果。AI 可以分析测试结果并根据这些结果推断哪些测试用例提供了最佳的测试覆盖率,哪些测试用例需要进一步改进以提高覆盖率。这种数据驱动的方法可以帮助测试人员更好地优化测试计划,并在最短时间内提供最佳的测试覆盖率。
AI 在软件测试领域中的应用将对代码覆盖测试和测试覆盖测试产生积极的影响,帮助测试人员更好地评估软件的质量并提高测试效率。

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册