代码覆盖率
代码覆盖率是软件测试中一个重要的评价指标,主要是指程序运行过程中,被执行到的代码在总代码中的占比程度。
现在有很多插件可以实现这个功能,应用比较广的就是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里也好,目的都是成功记录数据。没有通用的万能方法,还是得因地制宜。在复杂的项目环境下,还是需要对原生代码进行适当的打桩修改的。