功能测试如何获得代码覆盖率？大佬解释得太详细了！

最新推荐文章于 2024-06-28 15:39:03 发布

程序员霄霄

最新推荐文章于 2024-06-28 15:39:03 发布

阅读量737

点赞数 24

分类专栏：软件测试文章标签：功能测试代码覆盖率软件测试自动化测试程序人生职场和发展

本文链接：https://blog.csdn.net/weixin_71807218/article/details/139293828

版权

软件测试专栏收录该内容

651 篇文章 16 订阅

订阅专栏

代码覆盖率

代码覆盖率是软件测试中一个重要的评价指标，主要是指程序运行过程中，被执行到的代码在总代码中的占比程度。

现在有很多插件可以实现这个功能，应用比较广的就是JaCoCo，虽然好久没更新了，类似Jetbrain旗下的IDE。默认提供了三种获得代码覆盖率的方式：Intellij IDEA、JaCoCo、Emma。

功能测试代码覆盖率

常规的代码覆盖率通常是在单元测试中，通过编写测试用例，然后执行对应的单元测试，获得代码覆盖率。当然，现在也有挺多自动化生成单元测试的工具，比如EvoSuite，Randoop等。

但是，对于用户交互性比较强的应用，比如Android应用，这种单纯的单元测试显然是满足不了需要的。功能测试就是在真实的使用环境下，人工或者模拟真人对应用进行测试，在这种场景下，生成的代码覆盖率定义其为功能覆盖率。

JaCoCo与Gradle获取功能测试代码覆盖率

常见获取覆盖率的方法分两种，一种是在源码中，以打桩的形式，收集覆盖率数据，针对性较强，但是需要深入源码，另一种是改写应用入口，通过instrument启动应用，记录应用执行期间全局的代码覆盖率。这里，主要针对第二种，主要内容分为两个主要部分：

覆盖率数据获取
覆盖率数据解析

具体实现

入口文件改写

这里需要添加一个新的入口，接收instrument指令，启动代码覆盖率记录功能，并启动原始应用的入口Activity。涉及的一些代码，网上到处都是，我找了一些改写了一下，除去了一些冗余的代码，也去掉了一些bug。

这里主要包括2个java文件，为了方便管理，我们就单独创建一个package、test，避免和原始代码混淆。

一个Instrument启动器，目的是方便通过instrument指令启动带有coverage记录功能的activity。


package test;


import android.app.Instrumentation;

import android.content.Intent;

import android.os.Bundle;

import android.util.Log;


import java.io.File;

import java.io.IOException;


public class JacocoInstrumentation extends Instrumentation {

public static String TAG = "JacocoInstrumentation:";

private Intent mIntent;


@Override

public void onCreate(Bundle bundle) {

Log.d(TAG, "onCreate(" + bundle + ")");

super.onCreate(bundle);

String DEFAULT_COVERAGE_FILE_PATH = getContext().getFilesDir().getPath() + "/coverage.ec";


File file = new File(DEFAULT_COVERAGE_FILE_PATH);

if (!file.exists()) {

try {

file.createNewFile();

} catch (IOException e) {

Log.d(TAG, "异常 : " + e);

e.printStackTrace();

}

}

mIntent = new Intent(getTargetContext(), InstrumentedActivity.class);

mIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

start();//调用onStart

}


@Override

public void onStart() {

Log.d(TAG, "onStart()");

super.onStart();

startActivitySync(mIntent);

}

//adb shell am instrument com.tachibana.downloader/test.JacocoInstrumentation

}

这个文件的主要功能有两点：

在/data/data/应用包名/files目录下创建coverage.ec，这个文件就是用来记录覆盖率数据的；
启动改写的Activity，这里是InstrumentedActivity。

为了不影响原始代码，创建一个原入口类的子类，实现记录覆盖率数据的功能，在实现目的的情况下，尽可能减少对原始代码的影响。


package test;


import android.util.Log;


import com.tachibana.downloader.ui.main.MainActivity;


import java.io.FileOutputStream;

import java.io.OutputStream;



public class InstrumentedActivity extends MainActivity {

public static String TAG = "InstrumentedActivity";


@Override

public void onDestroy() {

super.onDestroy();

Log.d(TAG, "onDestroy()");

generateCoverageReport();

}


private void generateCoverageReport() {

String DEFAULT_COVERAGE_FILE_PATH = getFilesDir().getPath() + "/coverage.ec";

Log.d(TAG, "generateCoverageReport():" + DEFAULT_COVERAGE_FILE_PATH);

try {

OutputStream out = new FileOutputStream(DEFAULT_COVERAGE_FILE_PATH, false);

Object agent = Class.forName("org.jacoco.agent.rt.RT")

.getMethod("getAgent")

.invoke(null);


out.write((byte[]) agent.getClass().getMethod("getExecutionData", boolean.class)

.invoke(agent, false));

out.close();

} catch (Exception e) {

Log.d(TAG, e.toString(), e);

}

}


}

如代码里展示的，我这里原始的入口类是com.tachibana.downloader.ui.main.MainActivity，我们继承这个Activity，并实现了一个generateCoverageReport方法，用来记录JaCoCo的数据，在这个Activity退出的时候，调用方法记录，实现覆盖率数据获取的功能。

这个函数也是从网上找的，从字面上来看，逻辑就是每次这个Activity的生命周期执行到onDestroy的时候，就记录一次数据，并且是覆盖式的记录。（对于覆盖式的记录，我是有点困惑的，这些数据是从应用启动就被一直存在内存，增量式增加还是记录在日志，每次调用这个方法的时候，jacoco去日志里面解析暂且认为这种方式没有问题吧，毕竟网上都是这么做的）。

这个Activity的作用也是2个：

记录ExecutionData，也就是覆盖率的原始数据；
Fake入口，继承了原始的入口Activity，在实现原始功能的同时，不影响原来代码。

AndroidManifest.xml改写

配置文件的改写主要分为3个部分：

增加权限，既然读写文件了，那读写文件的权限肯定是要有的：

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Activity索引，我们新建了一个Fake入口，需要将这个Activity加入配置文件中，就加在<application>标签下，和其他的Activity一样。

<activity
android:name="test.InstrumentedActivity"
android:label="InstrumentationActivity" />

配置Instrument，<instrumentation>标签与<application>标签同级，配置了才能通过adb指令执行到，需要自定义的属性有两个。name，就是上面写的那个，targetPackage，就是应用的包名，配置在AndroidManifest.xml里的那个。


<instrumentation

android:name="test.JacocoInstrumentation"

android:handleProfiling="true"

android:label="CoverageInstrumentation"

android:targetPackage="com.tachibana.downloader" />

build.gradle改写

这里的配置主要针对JaCoCo，在应用构建过程，生成JaCoCo必须的一些数据，以及获取ec文件后的转义处理。


apply plugin: 'com.android.application'

apply plugin: 'jacoco'//引用插件


jacoco {//插件版本设置

toolVersion = "0.8.5"

}

android {

compileSdkVersion 30

buildToolsVersion "30.0.1"


defaultConfig {

applicationId "com.morn.aaa"

minSdkVersion 23

targetSdkVersion 30

versionCode 1

versionName "1.0"


testInstrumentationRunnerArguments clearPackageData: 'true'//instrument设置

}


buildTypes {

debug {

testCoverageEnabled = true//JaCoCo功能启动

}

}

}

//ec文件解析函数

def coverageSourceDirs = [

'../app/src/main/java'

]

task jacocoTestReport(type: JacocoReport) {

group = "Reporting"

description = "Generate Jacoco coverage reports after running tests."

reports {

xml.enabled = true

html.enabled = true

csv.enable = true

}

classDirectories.from = fileTree(

dir: './build/intermediates/javac/debug',

excludes: ['**/R*.class',

'**/*$InjectAdapter.class',

'**/*$ModuleAdapter.class',

'**/*$ViewInjector*.class'

])

sourceDirectories.from = files(coverageSourceDirs)

executionData.from = files("$buildDir/outputs/code-coverage/connected/coverage.ec")


doFirst {

new File("$buildDir/intermediates/javac/").eachFileRecurse { file ->

if (file.name.contains('$$')) {

file.renameTo(file.path.replace('$$', '$'))

}

}

}

}



dependencies {

implementation fileTree(dir: "libs", include: ["*.jar"])

}

这是app/build.gradle的一个例子，关键部分我都加了注释。

得到ec文件之后，需要将Android设备下的ec文件，放置到$buildDir/outputs/code-coverage/connected/coverage.ec然后运行jacocoTestReport这个task，运行成功后会在$buildDir/reports/jacoco目录下生成根据eoverage.ec转义的html等文件，html目录下的index.html可以可视化展示代码覆盖率数据。

一些bug

jacoco.exec

W/System.err: java.io.FileNotFoundException: /jacoco.exec (Read-only file system)

这应该是JaCoCo库包的一些问题，由于Android平台的特殊性导致的，JaCoCo的开发者也没提出明确的解决方案。但是，不影响我们这里要求的功能。

切页面闪退

网上一些例子中会出现切换Activity，应用闪退的问题。我一开始也是照着这个例子来的，也出现了这个问题，分析是代码思路有问题，一是只有由Instrument开启的Activity才设置了listener，二是，切换Activity会调用finish方法，直接就结束了应用。反正我一通删删删之后，可以正常运行了。

Instrument命令无反应

可能是targetPackage配置的问题，有些时候AndroidManifest.xml里设置的package不一定是实际安装时应用的package名。


<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="org.glucosio.android">

······

<instrumentation

android:name="test.JacocoInstrumentation"

android:handleProfiling="true"

android:label="CoverageInstrumentation"

android:targetPackage="org.glucosio.android.daily" />//实际安装的包名变化了

</manifest>

比如这个例子，在构建文件build.gradle里面对debug和release版本的包名做了修改，所以，实际安装的时候，应用对应的包名并不是AndroidManifest.xml里配置的那样。

解决方案就是编译完知道真实的包名后再配置，还有，在AS里面，targetPackage属性无论配置正确与否都会飘红报错，但是，这并不影响编译运行。

启动应用闪退

在设置了假入口类，并通过Instrument启动的时候，可能会遇到应用启动闪退的情况，这是因为很多应用会改写Theme，然后Fake入口类继承的真实入口类需要对应的Theme配置，这里出现了配置，或者资源不兼容的情况，造成了闪退。


<activity

android:name=".activity.SplashActivity"

android:label="@string/app_name"

android:theme="@style/SplashTheme">

<intent-filter>

<action android:name="android.intent.action.MAIN" />


<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

<meta-data

android:name="android.app.shortcuts"

android:resource="@xml/shortcuts" />

</activity>


<activity

android:name="test.InstrumentedActivity"

android:label="@string/app_name"

android:theme="@style/SplashTheme">

<meta-data

android:name="android.app.shortcuts"

android:resource="@xml/shortcuts" />

</activity>

上面例子里的InstrumentedActivity就是继承了真实入口类SplashActivity的Fake入口类。

解决方案，继承一切真实入口类可以被继承的属性，比如theme什么的，这样在FakeActivity实例化加载资源的时候，可以避免出现资源申请失败的问题，防止出现应用启动闪退的现象。

进阶

本方法的主要功能就是generateCoverageReport，所以，何时调用，是最主要的问题。

最理想的状态，在测试退出的时候调用，写入一次，节省时间，性能也高。但是大多数场景下，这种情况是行不通的。以下我整理几个场景，以及解决方案，提供参考：

入口类是一次性的，比如加载页面、广告页面等等；
入口类显性调用，指定了Activity跳转的目标类名，无法重回我们重写的Fake入口类。

以下可以提供一些解决方案：

Application的onTerminate()方法重写，在这里打桩调用记录函数，但是Application的生命周期监听在不同设备上有区别，貌似只在模拟器上有用；
BaseActivity的onDestroy()方法重写，一般大型的Android项目都会有一个自定义的顶级Activity，重写销毁监听函数，在这里打桩，这样每次Activity退出都会记录一次数据，当然，这也是在其子类重写但没有覆盖父类这个操作的情况下；
MainActivity的onDestroy()方法重写，这种方法是最保险的方法，这里的MainActivity指代应用首页对应的Activity。虽然，很多时候这个MainActivity不一定是入口类，但是只要在测试的时候能够最终回到MainActivity所在的页面，然后通过Android的回退键退出，调用onDestrooy()记录数据。

总结

通过JaCoCo记录覆盖率的核心是调用记录函数，重点是保证记录函数能被成功调用。所以，Instrument也好，Service也好，直接写在原来的Activity里也好，目的都是成功记录数据。没有通用的万能方法，还是得因地制宜。在复杂的项目环境下，还是需要对原生代码进行适当的打桩修改的。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！

程序员霄霄

关注

24
点赞
踩
20

收藏

觉得还不错? 一键收藏
0
评论
功能测试如何获得代码覆盖率？大佬解释得太详细了！

通过JaCoCo记录覆盖率的核心是调用记录函数，重点是保证记录函数能被成功调用。所以，Instrument也好，Service也好，直接写在原来的Activity里也好，目的都是成功记录数据。没有通用的万能方法，还是得因地制宜。在复杂的项目环境下，还是需要对原生代码进行适当的打桩修改的。行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，
复制链接

扫一扫