（3）信息存储
　　我们的函数覆盖率测试有了思路，使用xdebug的function trace获取一次请求中所有函数的调用关系，得到执行过的所有函数，输出到文件中，通过文件解析和reflection获得被执行的函数名和该函数所在文件。将这些信息存入数据库或文件即可。
　　之前试用Spike的时候，我们发现这些信息以xml格式存入文件，数据冗余度很高，导致几个测试下来，文件已经非常大了。这显然不是我们想看到的。因此在数据存储的时候，我们直接将数据做json格式的序列化，字符串形式存在文件中，大大减少了文件大小。与此同时，我们再通过请求来源的IP和日期作为分隔，分别存储不同的文件。这样，来自每个机器每天的请求数据都能一目了然，向着“”的方向又迈进了一步，可以对测试人员的每个请求做精确的监控。下图是我们在业务实践中搜集的部分数据文件截图：

　　这样，来自任何一个IP的每一次Web请求，它所覆盖的行和函数信息，都会被记录到文件中。对于一般的项目测试中，也只有几个测试人员在使用，所以不需要考虑一些性能问题。
　　4. 报告生成
　　上面讲了生成覆盖率数据的原理，不过我们至此获得的只是一份份的数据文件，如何汇总成一份完整的报告呢？这需要我们自己来写一段脚本解析刚才生成的数据文件了。我们的做法是借鉴了开源工具spike phpcoverage的模版，并加入自己的代码逻辑，特别是加入了该工具所不具有的函数覆盖率统计数据。我们自己测试的web页面生成的报告如下：

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

　　5. 总结
　　业务测试中做Web测试时，对代码的覆盖率是衡量测试质量的重要指标。我们希望通过此方法做到尽量地“”，测试执行完后可以精确看到哪一行代码被执行过，哪一行没被执行过。分析没被执行过的原因，从而改进测试用例。使用工具的流程也很简单，插桩=>测试=>搜集数据=>出报告。并且此解决方案大化地减少了对业务代码的影响，只需要改一行代码即可。即便中间出现了问题，也可以快速将代码恢复为原来的样子。让测试放心，让开发也放心。
　　不过，后还需要强调的一点是，并不是说覆盖了所有的代码，证明测试已经完整了。只不过没被覆盖的话，一定是不完整的。所以这个方案大的意义在于能够发现测试中一些遗漏的代码，找到一部分问题。其实，它也可以帮助新来的员工理解整个项目代码结构，我们可以清晰的知道，自己的每一次浏览器请求，到底在运行服务器上的哪些代码。