澳门新浦京娱乐游戏Web端PHP代码函数覆盖率测试解决方案

1. 关于代码覆盖率

衡量代码覆盖率有很多种层次,比如行覆盖率,函数/方法覆盖率,类覆盖率,分支覆盖率等等。代码覆盖率也是衡量测试质量的一个重要标准,对于黑盒测试来说,如果你不确定自己的测试用例是否真正跑过了系统里面的每一行代码,在测试的完整性上总要打些折扣。因此,业界几乎对各种编程语言都有自己的一套代码覆盖率解决方案。世界上最美的语言PHP当然也不例外。PHPUnit和Spike
PHPCoverage提供了一套基于xdebug的代码覆盖率测试方案。在本文中,我将针对自己碰到的特定业务场景,讲述一下自己进行PHP代码函数覆盖率测试的解决方案。

 我们先要去官网下载下载php_xdebug.dll,2.将下载的php_xdebug.dll放到PHP的安装目录phpext下,然后在编辑php.ini文件

为什么需要Debugger?
很多PHP程序员调试使用echo、print_r()、var_dump()、printf()等,其实对
于有较丰富开发经验的程序员来说这些也已经足够了,他们往往可以在程序执行的过程中,通过输出特定变量的值可以判断程序执行是否正确,甚至效率高低也可以
看出来(当然可能还需要使用一些时间函数)。那么我们为什么还需要一个专门的调试程序来监控我们的程序运行呢?
这个问题的答案不妨留到后面来揭晓。
什么是Xdebug?
Xdebug是一个开放源代码的PHP程序调试器(即一个Debug工具),可以用来跟踪,调试和分析PHP程序的运行状况。
如何安装Xdebug?: 1. 打开
Win:Windows binaries版本
  Linux:source
得到一个dll文件(win)或运行安装文件(linux)
2. 安装
Win:将下载的dll文件放到相应的目录中。比如我的就放D:xamppphpext下面;
Linux:执行安装文件 tar -xvzf xdebug-2.1.2.tgz
cd  xdebug-2.1.2
phpize
(如果phpize没有这个command,需要安装一次phpize。phpize可以让php支持扩展模块)安装phpize:sudo
apt-get install php5-dev
如果安装了继续进行下面命令
./configure
make
make install
会有这个界面

2. 业务背景

假设我们在线开发了一个网站,交给业务测试的同事去进行功能测试。那他们是怎么测试的呢?通常情况下,无非是开发人员把网站部署好了,然后测试人员把网上所有功能都试用一遍,包括一些异常使用情况。对于业务测试来说,只要我把所有的功能点都测了,把所有异常使用情况也测到了,那就完成了。但是对于开发来说,我比较好奇的是,你是否把我写的所有代码都跑到了?会不会存在一些代码,只有在很特殊的情况下才能触发,而你从来没有测到过这些情况?这时,可能就需要代码覆盖率来出马了。

其实我首先想到了xdebug来测试覆盖率,只需要两三个函数即可,如下:

xdebug_start_code_coverage(); //开始收集代码行覆盖情况

xdebug_get_code_coverage(); //获取截至目前所跑过的代码文件名和行号

xdebug_stop_code_coverage(); //停止收集代码行覆盖情况

xdebug提供的接口可以用于测试行覆盖率,这是否能满足要求呢?其实,行覆盖率颗粒度有点细,实际项目中,开发人员可能会对代码进行微调。比如,这次测试,你跑过了A.php文件的第10行,但是我有一天对A.php进行了微调,在A.php第9行和第10行之间又加了两行代码。于是,原来的第10行变为了第12行,而xdebug的行覆盖信息只记录了行号……这样之前的数据岂不是不准确了么。。。考虑再三,我觉得函数覆盖是个不错的颗粒度。在相对成熟的项目中,很少有大规模函数变动的情况。不过问题是,xdebug并没有提供函数覆盖的接口。

于是,我们现在碰到的场景是:

【1】希望测到某次测试中所覆盖的所有函数列表,知道这个项目总共有多少个函数,计算一下覆盖率是否足够高。

【2】测试完成之后,要生成一份覆盖率报告,将代码的覆盖情况可视化。

【3】完整测试的流程如下:

澳门新浦京娱乐游戏 1

其中插桩的意思是在测试执行之前的一些准备工作。

 代码如下

澳门新浦京娱乐游戏 2

3. 函数覆盖率解决方案

(1)原理

xdebug天生提供了对行覆盖率的支持,我们要自己计算出函数覆盖率。函数覆盖率需要两点数据,一个是哪些函数被执行,一个是文件中总共有多少个函数。

文件中总共的函数量,由于我们不可能把所有函数都执行一遍,因此这部分只能通过代码静态扫描来实现。如果是在C++或者Java中,可能就需要词法分析工具了,然而在最美的语言PHP面前,我们完全不需要那么复杂。从PHP4.3开始,PHP
Zend
Engine中内置了tokenizer功能,帮助开发者做源码词法分析。我们只需要找到PHP中定义函数时所对应的词法规律,就可以轻松得到指定PHP文件中的全部函数了。

tokenizer定义的接口也十分简单:

array token_get_all (string $source)

该函数进行文件解析,将php源代码拆成由token组成的数组。

string token_name (int $token)

将整数形式的token转变为字符串形式。类似于C语言中的strerror函数。有了tokenizer,自己再根据php函数定义的规律和格式设计一个有限状态机,即可完成全量函数的解析。这部分代码,本人写了个比较简陋的,把它单独拿出来,仅供大家参考:PHPFunctionParser

求函数覆盖率的另外一个难点在于获取被执行的函数列表。这地方让我们走了一些弯路。一开始一个最简单的办法,我们既然通过xdebug拿到被执的行,可以通过行号来反推此行属于哪一个函数。然而每一次的请求获取的行号信息量是非常大的,如果一个求情执行了1000行,那就要进行1000次判断,效率上会比较差。调研了一番之后,发现xdebug提供了function
trace的功能,可以把一次请求中的函数调用关系获取到,只不过拿到了函数名字,却没办法得到它所在的文件。于是,再次调研一番,发现了Reflection,给定方法名和类名,可以反推出来它在哪个文件中定义。于是我们使用function
trace把函数调用关系暂存在一个临时文件中,然后通过文件解析,拿到执行的函数名(如果是类方法,则是“类名::函数名”的形式),再通过reflection机制反推出定义这个函数的文件即可。再次体会到了世界上最美语言的强大之处。

(2)插桩

为了降低使用门槛,我们尽可能少地改变PHP源代码为好。xdebug收集信息的原理是分别调用xdebug_start_code_coverage和xdebug_stop_code_coverage来控制覆盖率信息收集的开始和结束,因此不可避免地要改变源代码。此处我们的解决办法是,将xdebug_stop_code_coverage通过register_shutdown_function注册为php程序结束前必须要跑的一段程序(类似C语言的atexit函数),将其封装到一个文件中,然后在源代码第一行require这个文件即可。如果你的PHP框架是CodeIgniter这种所有请求都有一个统一入口index.php的框架,那就只需要改变这一个文件即可,对源代码只有一行的改动!实际上,目前基本上所有的PHP框架,都是以一个index.php文件作为所有请求的入口。

我们对源代码的改动只有入口文件index.php的第一行加入了一句话:

require_once "/file/path/to/phpcoverage.php"; ?>

而phpcoverage.php核心代码逻辑大致如下:

<?php
 ……
function xdebugPhpcoverageBeforeShutdown(){
 ……
 $lineCovData = xdebug_get_code_coverage();
 xdebug_stop_code_coverage();
 ……
 xdebug_stop_trace();
 ……
}
register_shutdown_function(‘xdebugPhpcoverageBeforeShutdown’);
……
xdebug_start_trace(……);
xdebug_start_code_coverage();
//备注:上面省略号表示非关键代码,这里就不展示了

(3)信息存储

我们的函数覆盖率测试有了思路,使用xdebug的function
trace获取一次请求中所有函数的调用关系,得到执行过的所有函数,输出到文件中,通过文件解析和reflection获得被执行的函数名和该函数所在文件。将这些信息存入数据库或文件即可。

之前试用Spike的时候,我们发现这些信息以xml格式存入文件,数据冗余度很高,导致几个测试下来,文件已经非常大了。这显然不是我们想看到的。因此在数据存储的时候,我们直接将数据做json格式的序列化,字符串形式存在文件中,大大减少了文件大小。与此同时,我们再通过请求来源的IP和日期作为分隔,分别存储不同的文件。这样,来自每个机器每天的请求数据都能一目了然,向着“精准”的方向又迈进了一步,可以对测试人员的每个请求做精确的监控。下图是我们在业务实践中搜集的部分数据文件截图:

澳门新浦京娱乐游戏 3

这样,来自任何一个IP的每一次Web请求,它所覆盖的行和函数信息,都会被记录到文件中。对于一般的项目测试中,也就只有几个测试人员在使用,所以不需要考虑一些性能问题。

[xdebug]
zend_extension =
“/home/ad/php/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so”
xdebug.auto_trace = on
xdebug.auto_profile = on
xdebug.collect_params = on
xdebug.collect_return = on
xdebug.profiler_enable = on
xdebug.trace_output_dir = “/home/ad/xdebug_log”
xdebug.profiler_output_dir = “/home/ad/xdebug_log”

cp modules/xdebug.so /usr/lib/php5/20090626+lfs
将xdebug.so文件移到php5下面
3. 编辑php.ini,加入下面几行:
 [Xdebug]
zend_extension=D:xamppphpextphp_xdebug.dll   (Win)
zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so(Linux)

4. 报告生成

上面讲了生成覆盖率数据的原理,不过我们至此获得的只是一份份的数据文件,如何汇总成一份完整的报告呢?这就需要我们自己来写一段脚本解析刚才生成的数据文件了。我们的做法是借鉴了开源工具spike
phpcoverage的模版,并加入自己的代码逻辑,特别是加入了该工具所不具有的函数覆盖率统计数据。我们自己测试的web页面生成的报告如下:

澳门新浦京娱乐游戏 4

图中可以看到每个文件的行覆盖率,函数覆盖率,还有总的覆盖率统计数据。如果需要更精确的数据,可以点进文件连接,查看到底覆盖的是哪些代码行(蓝色为覆盖,红色为未覆盖):

澳门新浦京娱乐游戏 5

4.重启Apache。
5.写一个test.php,内容为<?php phpinfo();
?>,如果输出的内容中有看到xdebug,说明安装配置成功。或者去/home/ad/xdebug_log下看看是不是日志已经出来了。

xdebug.profiler_enable=on
xdebug.trace_output_dir=”../Projects/xdebug”
xdebug.profiler_output_dir=”../Projects/xdebug”
后面的目录“../Projects/xdebug”为你想要放置Xdebug输出的数据文件的目录,可自由设置。
4. 重启Apache;
5.
写一个test.php,内容为,如果输出的内容中有看到xdebug,说明安装配置成功。如下图:

5. 总结

业务测试中做Web测试时,对代码的覆盖率是衡量测试质量的重要指标。我们希望通过此方法做到尽量地“精准”,测试执行完后可以精确看到哪一行代码被执行过,哪一行没被执行过。分析没被执行过的原因,从而改进测试用例。使用工具的流程也很简单,插桩=>测试=>搜集数据=>出报告。并且此解决方案最大化地减少了对业务代码的影响,只需要改一行代码即可。即便中间出现了问题,也可以快速将代码恢复为原来的样子。让测试放心,让开发也放心。

不过,最后还需要强调的一点是,并不是说覆盖了所有的代码,就证明测试已经完整了。只不过没被覆盖的话,一定是不完整的。所以这个方案最大的意义在于能够发现测试中一些遗漏的代码,找到一部分问题。其实,它也可以帮助新来的员工理解整个项目代码结构,我们可以清晰的知道,自己的每一次浏览器请求,到底在运行服务器上的哪些代码。

澳门新浦京娱乐游戏 6

澳门新浦京娱乐游戏 7

PHP Xdebug配置信息

现在我们来从最简单的程序调试开始一步步介绍Xdebug。
调试: 我们先写一个可以导致执行出错的程序,例如尝试包含一个不存在的文件。
testXdebug.php require_once(‘abc.php’);
?>
然后通过浏览器访问,我们惊奇地发现,出错信息变成了彩色的了:

Xdebug部分配置选项说明

澳门新浦京娱乐游戏 8

  xdebug.auto_trace = 1

不过除了样式改变,和我们平时打印的出错信息内容没什么不同,意义不大。好,我们继续改写程序:testXdebug2.php testXdebug();
function testXdebug() {
       require_once(‘abc.php’);
}
?>
输出信息:

  是否允许Xdebug跟踪函数调用,跟踪信息以文件形式存储,默认值为0

澳门新浦京娱乐游戏 9

  collect_params = 1

发现了什么? Xdebug跟踪代码的执行,找到了出错的函数testXdebug()。
我们把代码再写得复杂一些: 
testXdebug3.php 复制代码 代码如下:
testXdebug();
function testXdebug() {
       requireFile();   
}
function requireFile() {
       require_once(‘abc.php’);
}
?>

  是否允许Xdebug跟踪函数参数,默认值为0

输出信息:

  xdebug.collect_return = 1

澳门新浦京娱乐游戏 10

  是否允许Xdebug跟踪函数返回值,默认值为0

也就是说Xdebug具有类似于Java的Exception的“跟踪回溯”的功能,可以根据程序的执行一步步跟踪到出错的具体位置,哪怕程序中的调用很复杂,我们也可以通过这个功能来理清代码关系,迅速定位,快速排错。

  xdebug.profiler_enable = 1

其实PHP函数debug_backtrace()也有类似的功能,但是要注意debug_backtrace()函数只在PHP4.3.0之后版本及PHP5中才生效。这个函数是PHP开发团队在PHP5中新增的函数,然后又反向移植到PHP4.3中。

  打开xdebug的性能分析器,以文件形式存储,这项配置是不能以ini_set()函数配置的,默认值为0

如何利用Xdebug测试脚本执行时间 测试某段脚本的执行时间,通常我们都需要用到microtime()函数来确定当前时间。例如PHP手册上的例子:
复制代码 代码如下:
/**
* Simple function to replicate PHP 5 behaviour
*/
function microtime_float()
{
      list($usec, $sec) = explode(” “, microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
// Sleep for a while
usleep(100);
$time_end = microtime_float();
$time = $time_end – $time_start;
echo “Did nothing in $time secondsn”;
?>

  xdebug.profiler_output_dir

但是microtime()返回的值是微秒数及绝对时间戳(例如“0.03520000
1153122275”),没有可读性。所以如上程序,我们需要另外写一个函数microtime_float(),来将两者相加。
Xdebug自带了一个函数xdebug_time_index()来显示时间。
如何测定脚本占用的内存?
有时候我们想知道程序执行到某个特定阶段时到底占用了多大内存,为此PHP提供了函数memory_get_usage()。这个函数只有当PHP编译时使用了-enable-memory-limit参数时才有效。 

  性能分析文件的存放位置,默认值为/tmp

Xdebug同样提供了一个函数xdebug_memory_usage()来实现这样的功能,另外xdebug还提供了一个xdebug_peak_memory_usage()函数来查看内存占用的峰值。

  xdebug.profiler_output_name

如何检测代码中的不足?

  性能分析文件的命名规则,默认值为cachegrind.out.%p

有时候代码没有明显的编写错误,没有显示任何错误信息(如error、warning、notice等),但是这不表明代码就是正确无误的。有时候可能某段代码执行时间过长,占用内存过多以致于影响整个系统的效率,我们没有办法直接看出来是哪部份代码出了问题。这时候我们希望把代码的每个阶段的运行情况都监控起来,写到日志文件中去,运行一段时间后再进行分析,找到问题所在。
回忆一下,之前我们编辑php.ini文件
加入 [Xdebug]
xdebug.profiler_enable=on
xdebug.trace_output_dir=”I:Projectsxdebug”
xdebug.profiler_output_dir=”I:Projectsxdebug”

  xdebug.trace_output_dir

这几行,目的就在于把执行情况的分析文件写入到”../Projects/xdebug”目录中去(你可以替换成任何你想设定的目录)。如果你执行某段程序后,再打开相应的目录,可以发现生成了一堆文件,例如cachegrind.out.1169585776这种格式命名的文件。这些就是Xdebug生成的分析文件。用编辑器打开你可以看到很多程序运行的相关细节信息,

  函数调用跟踪信息输出文件目录,默认值为/tmp

最后:

  xdebug.trace_output_name

Xdebug提供了各种自带的函数,并对已有的某些PHP函数进行覆写,可以方便地用于调试排错;Xdebug还可以跟踪程序的运行,通过对日志文件的分析,我们可以迅速找到程序运行的瓶颈所在,提高程序效率,从而提高整个系统的性能。

  函数调用跟踪信息输出文件命名规则,默认为trace.%c

设置选项

Category

Setting

Description

 

日志

xdebug.trace_output_dir

日志追踪输出目录

xdebug.trace_output_name

日志文件名,xdebug提供了一系列的标识符,生成相应格式的文件名,具体请参考官网

xdebug.trace_options

记录添加到文件中方式:1 = 追加(如果存在该文件). 0 (default) =
覆盖(如果存在该文件)

显示数据

xdebug.collect_params

非零值 = 控制function的参数显示选项

  • 0 = 不显示.
  • 1 = 参数类型,值  (例如:array(9)).
  • 2 = 同上1,只是在CLI模式下略微有区别
  • 3 = 所有变量内容
  • 4 = 所有变量内容和变量名(例如:array(0 => 9)).

xdebug.collect_return

1 = 显示function返回值. Default 0 不显示

xdebug.collect_vars

1 =
显示当前作用域使用了哪些变量,显示变量名,该选项不会记录变量的值,如果需要,使用xdebug.collect_params

xdebug.collect_assignments

1 = 添加一行显示变量赋值(若为1,形如$a = 1;这类Assignment
Expression会在trace文件里显示)

格式

xdebug.trace_format

  • 0 = 人可读. 从左至右每列分别表示:时间点, 内存, 内存差
    (需要设置xdebug.show_mem_delta=1), 等级, 函数名,函数参数
    (需要设置,xdebug.collect_params=1,只要是非零),
    当前代码行所在文件名 , 行号.
  • 1 = 机器可读[1]. 需要借助第三方app,例如:xdebug trace file
    parser 或者 xdebug trace viewer
  • 2 = html格式 即table,用browser打开,显示table

xdebug.show_mem_delta

1 = 显示每次函数调用内存消耗(内存差)

行为 

xdebug.auto_trace

1 = 打开自动追踪.
(追踪方式有2种,一种是自动追踪,所有php脚本运行时,都会产生trace文件;另一种是触发方式追踪,如下)

xdebug.trace_enable_trigger[2]

1 = 使用 XDEBUG_TRACE GET/POST 触发追踪, 或者通过设置cookie
XDEBUG_TRACE.
为了避免每次请求时,都会生成相应trace追踪文件,你需要把auto_trace设置为0

注:该特性只在2.2+版本才能设置
 [xdebug-general] Re: Is trace_enable_trigger defunct? 

限制

xdebug.var_display_max_depth

数组和对象元素显示深度:主要用在数组嵌套,对象属性嵌套时,显示几级的元素内容.
Default 3.

xdebug.var_display_max_data

变量值为字符串时显示多长. Default 512.

xdebug.var_display_max_children

数组和对象元素显示的个数. Default 128

一些自定义函数

Function Description
void xdebug_enable() 手动打开,相当于xdebug.default_enable=on
void var_dump() 覆写php提供的var_dump,出错时,显示函数堆栈信息,(前提:php.ini里html_errors为1),使用xdebug.overload_var_dump 设置是否覆写
void xdebug_start_trace( 
string trace_file_path 
[, integer options] )
手动控制需要追踪的代码段
trace_file_path :文件路径(相对或绝对,若为空).如果为空,或者不传参, 使用xdebug.trace_output_dir设置的目录
options :

  • XDEBUG_TRACE_APPEND: 1 = 追加文件内容末尾, 0 = 覆写该文件
  • XDEBUG_TRACE_COMPUTERIZED:
    • 2 =同 xdebug.trace_format=1 .
  • XDEBUG_TRACE_HTML: 4 = 输出HTML表格,浏览器打开为一table
void xdebug_stop_trace() 停止追踪,代码追踪在该行停止
string xdebug_get_tracefile_name() 获得输出文件名,与 xdebug.auto_trace配合使用.
void xdebug_var_dump([mixed var[,…]])  输出变量详细信息,相当于php里的var_dump,具体显示请看这里
xdebug.show_local_vars  默认为0,不显示;非零时,在php执行出错时,显示出错代码所在作用域所有本地变量(注:这会产生大量信息,因此默认是closed),具体显示差别如下图[3]
array xdebug_get_declared_vars() 显示当前作用域中已声明的变量
array xdebug_get_code_coverage() 显示某一段代码内,代码执行到哪些行[4]

发表评论

电子邮件地址不会被公开。 必填项已用*标注