OpenHarmony本地代码和接口覆盖率可视化操作梳理

这篇具有很好参考价值的文章主要介绍了OpenHarmony本地代码和接口覆盖率可视化操作梳理。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一. 修改gn文件,编译执行测试套

1. 修改业务侧BUILD.gn文件,增加编译选项

2.设置lcov统计“branch coverage”的方法

3. 编译测试版本+目标用例

4. 在windows下搭建执行环境,执行测试用例

5. 查看测试生成gcda文件

二. 使用本地代码覆盖率脚本

7. 修改python脚本中的路径

8. 执行脚本

 三 . 本地接口覆盖率脚本使用

9. 检查接口覆盖率的必要文件路径

10. 修改localCoverage/interfaceCoverage/get_innerkits_json.py到对应路径:

11. 执行python get_innerkits_json.py

12. 修改localcoverage/interfaceCoverage/interfaceCoverage_gcov_lcov.py

13. 执行python interfaceCoverage_gcov_lcov.py

14.查看报告

 四. 使用命令行生成本地代码覆盖率(步骤二也可手动操作,已完成步骤二可忽略此步)

1. 将生成的.gcda合并到.o/.gcno文件夹中

2. 生成info文件

3. 去除非本模块信息

 4. 生成可视化数据


一. 修改gn文件,编译执行测试套

1. 修改业务侧BUILD.gn文件,增加编译选项

涉及到自己子系统的BUILD.gn中cflags或cfalgs_cc及idflags都需要加--coverage字段

C:OpenHarmony本地代码和接口覆盖率可视化操作梳理

C++:

cflags_cc = [

“--coverage”,

]

2.设置lcov统计“branch coverage”的方法(若不需要分支覆盖率,可忽略此步骤)

Lcov(1.10及往后)默认是关闭 分支覆盖率的。 

若要locv生成分支branch信息、输出基本块,需要修改/etc/lcovrc或~/.lcovrc文件,修改如下配置:

vi /etc/lcovrc
# Specify if branch coverage data should be collected andprocessed.

lcov_branch_coverage = 1                             //去掉注释,值改为1
# Include branch coverage datadisplay (can be disabled by the --no-branch-coverage option of genhtml)

genhtml_branch_coverage = 1                         //去掉注释,值改为1.

3. 编译测试版本+目标用例

./build.sh --product-name rk3568 --ccache --target-cpu arm64
./build.sh --product-name rk3568 --ccache --target-cpu arm64 --build-target make_test 

tips: make_test为编译全部测试用例,也可编译指定测试用例

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 OpenHarmony本地代码和接口覆盖率可视化操作梳理

Tips:如何检查覆盖率版本是否编译成功?

编译完成后需要在out/产品(rk3568)/obj/目录下,根据源码目录查找到对应的C/C++文件的gcno,说明覆盖率插桩成功

4. 在windows下搭建执行环境,执行测试用例

Windows环境搭建可参考官方文档:

test_developertest: Development self-test framework | 开发者自测试框架

执行测试用例前可检查设备是否在线,start.bat中执行list,若显示online则设备在线。若设备离线,可在config文件夹中的user_config.xml文件中添加port和sn号。

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 还需要在user_config.xml文件配置用例路径(可参考以上搭建执行环境官方文档)

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 tips: <testcase>标签表示是否需要编译用例;<dir>标签表示测试用例查找路径。若不配置,覆盖率文件会自动生成在设备侧的对应源码的编译路径下

在windows坏境下启动测试框架developtest/start.bat

执行测试用例,这里以account子系统中的account_event_provider_test为例

run -t UT -ts account_event_provider_test -cov coverage

tips: -t [TESTTYPE]: 指定测试用例类型,有UT,MST,ST,PERF,FUZZ,BENCHMARK等。(必选参数)-tp [TESTPART]: 指定部件,可独立使用。-tm [TESTMODULE]: 指定模块,不可独立使用,需结合-tp指定上级部件使用。-ts [TESTSUITE]: 指定测试套,可独立使用。-tc [TESTCASE]: 指定测试用例,不可独立使用,需结合-ts指定上级测试套使用。-h : 帮助命令。

执行过程中可在设备中查看(tips: 此步是为了查看覆盖率文件是否生成)

hdc_std shell在设备的data/test/obj查看

OpenHarmony本地代码和接口覆盖率可视化操作梳理

5. 查看测试生成gcda文件

执行完毕后设备中的gcda会pull到test/developertest/reports/coverage中

OpenHarmony本地代码和接口覆盖率可视化操作梳理

OpenHarmony本地代码和接口覆盖率可视化操作梳理

Tips:(1)若在步骤3中生成gcda文件,但是在reports中没有生成coverage,检查coverage outpath是否配置正确

(2)在reports在建立coverage/data/cxx/测试套名,然后手动将对应obj目录pull到coverage/data/cxx/测试套名 目录下即可

  • 二. 使用本地代码覆盖率脚本

6. 将localCoverage目录解压并挪至编译机的test目录

localCoverage的python脚本已上传至gitee,链接如下:

本地代码和接口覆盖率: 用于本地代码和接口覆盖率的python脚本

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 将步骤4中生成的coverage文件夹复制到localCoverage/codeCoverage/results目录下

OpenHarmony本地代码和接口覆盖率可视化操作梳理

解压完之后执行

dos2unix test/localCoverage/codeCoverage/codeCoverage_gcov_lcov.py

7. 修改python脚本中的路径

打开localCoverage/codeCoverage/ codeCoverage_gcov_lcov.py

修改CODEPATH至代码根目录

修改OUTPUT路径,此处产品名为rk3568

OpenHarmony本地代码和接口覆盖率可视化操作梳理

修改llvm-cov工具的路径:修改codeCoverage目录下的llvm-gcov.sh文件为(可通过在源码路径下搜索find . -name “llvm-cov”即可)

Llvm-gcov.sh文件格式如果是dos,请改成unix(dos2unix llvm-gcov.sh)

exec /home/cjj/open/prebuilts/clang/ohos/linux-x86_64/llvm/bin/llvm-cov gcov "$@"

8. 执行脚本

在test/localCoverage/codeCoverage目录下执行python codeCoverage_gcov_lcov.py即可

若出现下图中错误(若无错误可忽略直接查看报告)

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 可单独运行“single_test**”后面的命令:

lcov -c -b /home/cjj/open/out/rk3568 -d  /home/cjj/open/test/localCoverage/codeCoverage/results/coverage/data/cxx/AccountEventProviderTest/obj/base/account --gcov-tool /home/cjj/open/test/localCoverage/codeCoverage/llvm-gcov.sh -o /home/cjj/open/test/localCoverage/codeCoverage/results/coverage/reports/cxx/single_test/AccountEventProviderTest/account_output.info --ignore-errors source,gcov

若运行后出现need tool ...llvm-gcov.sh

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 则可为llvm-gcov.sh赋予执行权限:chmod 777 llvm-gcov.sh

重新执行

lcov -c -b /home/cjj/open/out/rk3568 -d  /home/cjj/open/test/localCoverage/codeCoverage/results/coverage/data/cxx/AccountEventProviderTest/obj/base/account --gcov-tool /home/cjj/open/test/localCoverage/codeCoverage/llvm-gcov.sh -o /home/cjj/open/test/localCoverage/codeCoverage/results/coverage/reports/cxx/single_test/AccountEventProviderTest/account_output.info --ignore-errors source,gcov

若出现以下错误

OpenHarmony本地代码和接口覆盖率可视化操作梳理

可执行dos2unix llvm-gcov.sh,将DOS格式文本文件转换成Unix格式

重新运行上述lcov -c -b...脚本直到出现

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 然后再执行

python codeCoverage_gcov_lcov.py

查看报告:在codeCoverage/results/coverage/reports/cxx/html下生成可视化报告,打开index.html即可查看。

 OpenHarmony本地代码和接口覆盖率可视化操作梳理

 OpenHarmony本地代码和接口覆盖率可视化操作梳理

 三 . 本地接口覆盖率脚本使用

9. 检查接口覆盖率的必要文件路径

接口覆盖率数据生成是依赖步骤二中代码覆盖率生成的info文件(ohos_codeCoverage.info)

10. 修改localCoverage/interfaceCoverage/get_innerkits_json.py到对应路径:

可直接修改为绝对路径:

OpenHarmony本地代码和接口覆盖率可视化操作梳理

11. 执行python get_innerkits_json.py

 检查out/rk3568/packages/phone/innerkits/ohos-arm64/kits_modules_info.json文件的存在

OpenHarmony本地代码和接口覆盖率可视化操作梳理

12. 修改localcoverage/interfaceCoverage/interfaceCoverage_gcov_lcov.py

修改脚本中的line3~9到对应路径:

OpenHarmony本地代码和接口覆盖率可视化操作梳理

13. 执行python interfaceCoverage_gcov_lcov.py

14.查看报告

在localCoverage/interfaceCoverage/results/coverage/interface_kits目录挪至本地,查看报告

 OpenHarmony本地代码和接口覆盖率可视化操作梳理

 四. 使用命令行生成本地代码覆盖率(步骤二也可手动操作,已完成步骤二可忽略此步)

1. 将生成的.gcda合并到.o/.gcno文件夹中

.o/.gcno文件路径一般为(可通过find . -name “*.gcno”查找)

Z:\home\cjj\open\out\rk3568\obj\base\account\os_account\services\accountmgr\src\AccountEventProviderTest

tips:gcda文件是执行测试测试用例,在设备上自动生成覆盖率数据文件,.o/.gcno文件是linux编译机上编译过程中生成的。

合并后,gcda,.o/.gcno文件在同一文件夹下

2. 生成info文件

解析gcda依赖特定的gcov版本,可通过-gcov-tool指定,手动创建llvm-gcov.sh文件

在源码根目录下创建文件夹local_tools

mkdir local_tools

创建llvm-gcov.sh文件:

cd local_tools/

touch llvm-gcov.sh

使用项目编译是使用的clang对应的llvm-cov版本,在文件中写入以下内容:

#!/usr/bin/env sh
exec /home/cjj/open/prebuilts/clang/ohos/linux-x86_64/llvm/bin/llvm-cov gcov "$@"

增加可执行权限:

chmod +x llvm-gcov.sh

生成info文件:

cd ~/open/out/rk3568/obj/base/account
lcov -d . -o cov_oa_all.info -c --gcov-tool ~/open/local_tools/llvm-gcov.sh

若直接用此时生成的info文件生成可视化数据,则包含了其他模块的统计信息

OpenHarmony本地代码和接口覆盖率可视化操作梳理

3. 去除非本模块信息

cov_oa_all.info包含了其他模块的统计信息,需要去除,使用-remove,根据实际情况设置

例如

lcov -o rm_cov_oa_all.info  --remove cov_oa_all.info  "*/third_party/*" "*/v1/*"

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 4. 生成可视化数据

genhtml -o result --ignore-errors source rm_cov_oa_all.info

OpenHarmony本地代码和接口覆盖率可视化操作梳理

 OpenHarmony本地代码和接口覆盖率可视化操作梳理

 OpenHarmony本地代码和接口覆盖率可视化操作梳理文章来源地址https://www.toymoban.com/news/detail-425428.html

到了这里,关于OpenHarmony本地代码和接口覆盖率可视化操作梳理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Google代码覆盖率最佳实践

    软件质量保障: 所寫即所思|一个阿里质量人对测试的所感所悟。 谷歌一直倡导的领域之一是使用代码覆盖率数据评估风险并识别测试中的真空。然而,代码覆盖率的价值一直是个争议的话题。每次聊到代码覆盖率时,似乎都会引发无尽的争论。由于大家固守自己阵营,所以

    2024年01月16日
    浏览(53)
  • 单元测试——测试代码功能及代码覆盖率

    目录 目录 前言 一、单元测试是什么? 二、前置准备  三、测试代码  四、示例  五:单元测试覆盖率 单元测试的写法不固定,这里以我自己的一种写法为例,算是很简单的一种写法           单元测试其实就是写一些测试函数,测试代码的功能是否正常运行,一般如果

    2024年02月07日
    浏览(40)
  • Python:代码覆盖率工具coverage

    简介 :覆盖率测量通常用于衡量测试的有效性。它可以显示您的代码的哪些部分正在被测试执行,哪些不是。coverage是一个测量 Python 程序代码覆盖率的工具。它监视您的程序,注意代码的哪些部分已被执行,然后分析源代码以识别可能已执行但未执行的代码。 安装: 官方文

    2024年02月09日
    浏览(35)
  • Python代码覆盖率分析工具Coverage

    目录 简介 安装 命令行中使用 调用API使用 Coverage是一个Python代码覆盖率分析工具,它可以用于衡量Python测试代码的质量。通过给代码执行带来的覆盖率数据,Coverage可以帮助开发人员找出被回归测试代码中的漏洞,并且指明哪些代码没有被测试到。 Coverage可以让你知道:哪些

    2024年02月11日
    浏览(38)
  • Lombok导致代码单元测试覆盖率崩塌

    Lombok 由于其使用的便利性, 目前流传非常广泛。甚至有呼声希望其能被Java官方引入,成为JDK的一部分。 当然凡事都有两面性,Lombok的引入也是有代价的。一时注释一时爽,结果导致代码在不知不觉中翻了好几倍。 例如以下几个简单的注解,背后是N多个自动生成的方法: @Da

    2024年02月07日
    浏览(43)
  • 如何有效保证Java代码单元测试覆盖率

    我们在实际项目开发过程中,不同level的童鞋由于专业技能的层次不同,导致在参与实际开发的业务代码中经常会出现各种bug,项目管理中好的pm或许会给充足的时间来让开发童鞋们定位修复这些bug,也有各种客观原因的PM不会在项目中预留这些时间,往往就需要开发自己通过

    2023年04月17日
    浏览(49)
  • 单元测试必备:Asp.Net Core代码覆盖率实战,打造可靠应用 !

    在前几章我们深度讲解了单元测试和集成测试的基础知识,这一章我们来讲解一下 代码覆盖率 ,代码覆盖率是单元测试运行的 度量值 ,覆盖率通常以百分比表示,用于衡量代码被测试覆盖的程度,帮助开发人员评估测试用例的质量和代码的健壮性。常见的覆盖率包括语句覆盖

    2024年04月23日
    浏览(47)
  • cmake + gtest安装使用 C++单元测试 gcov locv代码覆盖率

    CMakeLists.txt速查简单编写 打开–g3 选项,去掉-O2以上级别的代码优化选项;否则编译器会对代码做一些优化,例如行合并,从而影响行覆盖率结果; 这里我比较懒就没有加 加到test目录下的CMakeLists.txt即可 , 其中代码编译完之后会在test/CMakeFiles/test.dir/ 生成test.cpp.gcno文件, 在运

    2024年02月05日
    浏览(41)
  • 【项目实战】使用Maven插件(jacoco-maven-plugin),实现生成代码覆盖率报告

    jacoco-maven-plugin是一个Maven插件,用于生成代码覆盖率报告。 它可以帮助您了解您的代码中哪些部分已经被测试覆盖,哪些部分需要更多的测试。 注意,jacoco-maven-plugin 需要 Java 1.5 或更高版本才能运行。 要使用jacoco-maven-plugin,需要在Maven项目中添加以下配置:

    2024年02月15日
    浏览(46)
  • springboot项目使用Junit5 + mockito + jacoco 实现单元测试以及代码覆盖率检查

    在创建springboot项目时会默认添加spring-boot-starter-test依赖,其中已经包含了junit、mockito依赖,根据springboot版本的不同junit和mockito的版本也会有所不同 先说一下各自功能: junit只说一点,junt4和junit5的注解不同,使用方式略有差异,其他不赘述了,基本用法都懂。 mockito是mock的

    2023年04月23日
    浏览(58)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包