成都wap网站建设,wordpress散开式,公司网站设计有哪些使用技巧呢,个人能申请网站吗一#xff0c;项目简介 在移动端项目测试过程中#xff0c;尤其是发版前的回归测试阶段#xff0c;会遇到这样的情况#xff0c;在测试过程中测试不断地发现问题#xff0c;开发就进行修改#xff0c;然后打包测试。而测试完成后呢#xff0c;业务测试同学想知道整个回归…一项目简介 在移动端项目测试过程中尤其是发版前的回归测试阶段会遇到这样的情况在测试过程中测试不断地发现问题开发就进行修改然后打包测试。而测试完成后呢业务测试同学想知道整个回归测试阶段的覆盖率情况但是针对每次不同的打包会根据对应的版本生成相应的报告不同版本的覆盖率执行如何进行合并呢 在网上搜索了一下jacoco本身有jacoco merge功能但是只针对同一版本的如果版本变化了也就意味着类有变化那这个类在老版本中所有的覆盖率数据就会被丢掉。这样一来必须会丢失一些版本中的覆盖率数据同时如果函数有变化则这个函数调用链路上的所有功能就要重新测试原来的覆盖率数据就要丢弃。综合考虑无法直接使用jacoco merge来进行跨版本的覆盖率数据合并这就要求我们自己开发一套覆盖率合并方案。 二覆盖率合并方案介绍
1网上方案调研 通过调研网上现有的jacoco覆盖率合并方案得到了一些思路但是没有切实可行的方案。参考文档 基于 Jacoco 的二次开发【解决不同版本 exec 数据合并问题】 https://testerhome.com/topics/30776 jacoco的多次代码提交merge分析 https://chowdera.com/2022/195/202207130538134324.html 写给android同学的代码覆盖率讲解 https://www.jianshu.com/p/97caec282998 JaCoCo探针策略原理及案例总结 https://bbs.huaweicloud.com/blogs/274224
2自研合并方案 针对业务同学的要求需要对同一分支不同版本的多次打包产生的覆盖率数据进行合并不同分支的合并起来意义不大。但合并过程中也涉及到众多处理逻辑现在将整体方案流程介绍如下 介绍
1对比要合并的版本先按版本合并覆盖率数据文件找出diff的函数列表
2通过diff函数列表查询调用链路找到其影响的上游函数列表组成受影响的函数列表。
3对受影响的函数列表找到其在老版本中的行号去掉对应的行号的覆盖率信息。
4根据diff函数列表找到其所在类中的位置没有变化的函数列表以及位置变化的函数列表。
5针对位置没有变化的函数列表将旧版本中的覆盖率信息写入到合并后的覆盖率文件中
6针对位置有变化的函数列表将旧版本中的覆盖行号校正为新版本中类的对应的行号写回覆盖率文件中。
7循环处理所有需要合并的版本覆盖率数据文件生成最终的覆盖率文件。
三Android 跨版本覆盖率合并 针对Android系统的跨版本覆盖率合并diff函数可以通过git提供的功能来实现查询类中函数的起始位置由主站的同学提供的解析kotlin和java文件的功能来解析。而最重要的就是对覆盖率数据文件EC的处理。主站同学提供的jacoco-parser.jar工具用来解析覆盖率ec文件覆盖的行号而无法修改EC文件而我们的需要对EC文件进行处理。
1EC文件的处理 这样的处理没有办法直接通过java代码或是python来处理只能开发一个单独的工具来操作EC文件。所以就优化了主站同学的jacoco-parser.jar引用jacoco插件来处理EC文件最终生成的工具是jacoco-parser2.0.jar.
2版本合并时函数处理
合并版本的时候需要处理的函数信息有如下几类 diff函数及其在调用链路中影响到的函数列表 diff函数所在类位置没有变化的函数列表 diff函数所在类位置有变化需要在新版本中修正行号的函数列表。
具体的处理流程如下 为了与先前的覆盖率生成功能保持一致节省相关操作故将此功能放到了Android Agent上以服务的形式对精准测试平台提供服务。
3精准测试平台合并覆盖率 为了让测试同学来合并覆盖率操作需要在精准测试平台上添加合并覆盖率的操作通过精准测试平台向Agent发送消息同时借助于原来的生成覆盖率报告的逻辑生成最终的合并后的覆盖率报告。最终的流程如下所示 当得到了合并后的最终all-merged.ec文件后就可以根据项目的其他信息如当前分支对比分支最新的构建号等生成合并后的全量及增量覆盖率报告。
四iOS 跨版本覆盖率合并 iOS端的覆盖率合并相对于Android端容易一些因为iOS生成报告之前会生成一个info文件处理这个文件比EC文件简单多了。整体合并方案就是对比两个版本的info文件根据diff函数列表位置变化的函数列表进行处理。
1iOS跨版本合并流程 通过上面的处理以及对比合并后的覆盖率报告发现一个问题合并后的覆盖率报告行覆盖率没有问题但是方法覆盖率不正确也是不能直接对数据进行处理的。需要一定的逻辑处理才行经过调研后可以从下面的方式来进行。
2iOS Swift跨版本覆盖率合并方法合并 目前的功能暂时不对覆盖率合并后的文件进行校正的根据业务同学在使用过程中是否需要这个指标如果需要在Agent上添加相应的功能即可。
其中的合并两个info文件的操作是自研的代码来处理的主要思路是 先以最新的版本的info文件为基础分别使用sed获取其中的文件以覆盖率信息 再从旧的版本的info文件中找到相应的文件的覆盖率信息 按不同的情况如新文件中有旧的文件中没有旧的文件中有新的文件中没有两个文件中都有进行合并行覆盖率数据 最后将合并后的info文件写入新文件再拷贝成较大的版本的文件循环合并所有版本
这种方法没有错误但是当info文件中的文件信息过多时如60多万行数据时速度就非常慢差不多要一个多小时才行。
有什么办法可以优化一下吗
1通过在网上搜索相关资料找到lcov的使用文档https://blog.csdn.net/qq_36614557/article/details/120264262
文档中说可以使用-a参数 合并两个lcov生成的文件如下所示 2通过两次详细搜索合并方法如下
lcov -a test1.info -a test2.info -o allreport.info
经过验证合并结果达到了预期而合并速度快的不是一个数据级非常开心
3在生成iOS覆盖率报告是生成的info文件命令 xcrun llvm-cov export procpathKima --instr-profileprocpathcoverage_merged.profdata -use-color --formatlcov procpathallreport_commitid.info
完全符合要求。 于是合并info文件的函数变成如下所示比原来的简单了太多了 def newMergeTwoInfoFile(self,srcinfofile,destinfofile):使用llcov -a 合并归并多个lcov生成的info文件:param srcinfofile::param destinfofile::return:newinfofiledestinfofile[0:destinfofile.rindex(/)1]merged_report.infoif os.path.exists(srcinfofile) and os.path.exists(destinfofile):mergecmdself.lcovcmd -a srcinfofile -a destinfofile -o newinfofileos.system(mergecmd)#将删除过覆盖率数据的info文件更名为老的文件rmcmdrm -rf destinfofileos.system(rmcmd)mvcmdmv newinfofile destinfofileos.system(mvcmd)else:print(要合并的两个info文件srcinfofile,destinfofile不存在)
最终的合并覆盖率报告执行时间也由原来的一个小时二十多分钟降低到了二十多分钟
3精准测试平台iOS覆盖率合并方案 由于在容器上无法处理iOS覆盖率报告所以只能根据keep构建号把覆盖率数据文件profraw上传到Agent上来处理。iOS Agent需要做大量对覆盖率数据处理生成info文件合并info文件的操作。其中对函数的过滤和处理使用的是经过二次开发的工具drafter,这个工具可以根据文件来返回文件中的函数列表包括起始位置。
五总结
覆盖率跨版本合并正常情况下是不允许的这也是为什么jacoco就不支持的原因。因为类一旦变化了类中函数的位置函数内容都会变化同时其调用函数也会受到影响。极端的情况就是函数中的逻辑变化了先前与这个函数相关的所有操作都要重新测试。
1Android中的覆盖率数据是通过探针来控制覆盖情况的如果多个探针同时控制一个覆盖逻辑的话上面的覆盖率行号的修改就会出错由于探针和行号不是一一对应的所以很难根据探针准确地修改行号的覆盖情况。现在的合并方案虽然比直接jacoco merge更加准确一些但是也不完全准确。
2iOS覆盖率的合并其实是对Info文件做了处理针对覆盖的行号的后面的数字做了处理如原行号覆盖为0改成1还好理解。如果原来行号覆盖数据是2要合并的是3合并后改成了5。这个5在报告中如何渲染的呢其实没有太搞明白。现在info文件信息解读网上也不多。
六常见问题 在实际使用过程中增加了对项目Module模块的覆盖率的收集生成的测试报告显然比原来的更加全面了但出现了两个问题
1覆盖率收集的Pod相关的文件生成报告的时候找不到文件 由于项目和Module的调用会出现一些Pod中的头文件信息这是因为主代码与pod module交互的接口或是过度等。但是生成覆盖率报告的时候在源项目中是找不到对应的文件的所以genhtml报告时会因文件找不到出错。
解决方案在生成覆盖率报告info文件后过滤掉info文件中与pod相关的文件及其覆盖率信息以保证生成html报告时不会出错文件找不到的问题。
2iOS覆盖率合并的时候合并版本与项目分支对应的版本不同会出现文件找不到 在进行覆盖率的合并的时候由于创建覆盖率任务与生成报告时间间隔内如果开发有提交代码早期的更新项目的逻辑是拉出对应分支最新 的版本可能造成新版本修改了文件老版本的覆盖率报告找不到文件。
解决方案在生成合并覆盖率合并报告时先获取要合并覆盖率报告任务的最新版本号将项目切到这个版本再生成报告。生成完成后再切回分支的最新版本防止影响其他的操作。
