Java：测量远程脚本测试的代码覆盖率 [英] Java: measure code coverage for remote scripting tests

问题描述

我们有一个应用程序部署在 JBoss 5.1， JDK 1.6。
我们还有用 PowerShell 编写的脚本进行测试。这些脚本使用Web服务访问应用程序。
我想查看脚本的代码覆盖率。有任何想法吗？
我看到的大多数工具都是检查 JUnit 测试覆盖率而我不是看看我们如何使用它们。

We have an application which is deployed on JBoss 5.1, JDK 1.6. We also have scripts written in PowerShell for testing. These scripts access the application using a web-service. I would like to check the code coverage of the scripts. Any ideas? Most of the tools I saw are checking a JUnit test coverage and I don't see how we can use them.

推荐答案

AFAIK，所有代码覆盖工具都使用相同的概念（我将省略报告和检查部分）：

AFAIK, all code coverage tools use the same concept (I'll omit the reporting and checking part):

1. 首先检验代码（即放置标记）。


2. 然后运行测试以执行已检测的代码（以激活标记和收集数据）。

第二步，常见的用例确实是运行JUnit测试但是你的测试不需要是JUnit测试。实际上，它们甚至不必自动化。

For the second step, the common use case is indeed to run JUnit tests but your tests don't have to be JUnit tests. Actually, they don't even have to be automated.

并且检测代码不必在单元测试的上下文中执行，它可以被打包在WAR / EAR中并部署在容器上（这只需要更多工作）。

And the instrumented code doesn't have to be executed in the context of a unit test, it can be packaged in a WAR/EAR and deployed on a container (this will just require a bit more work).

对于Cobertura，这是我们在常见问题解答：

For Cobertura, this is what we can read in the Frequently Asked Questions:

< h2>使用Cobertura和Web应用程序

我有自动测试，使用
HttpUnit / HtmlUnit / Empirix / Rational
机器人，可以我用Cobertura？

是的！这个过程涉及多一点
，但概念是一样的。
第一个工具是你编译的
类。然后创建您的war文件。
然后将war文件部署到
应用程序服务器（Tomcat，JBoss，
WebLogic，WebSphere等）中。现在运行
你的测试。

Yes! The process is a bit more involved, but the concept is the same. First instrument your compiled classes. Then create your war file. Then deploy the war file into your application server (Tomcat, JBoss, WebLogic, WebSphere, etc). Now run your tests.

当你的类被访问时，
将在
上创建一个cobertura.ser文件磁盘。您可能需要挖掘
位才能找到它。 Cobertura将这个
文件放在它认为是
当前工作目录的文件中。通常
这是
应用程序服务器从
启动的目录（例如，C：\ Tomcat \ bin）注意：
此文件不是写入磁盘
，直到应用程序服务器退出。
请参阅下文，了解如何解决此问题。

As your classes are accessed, they will create a "cobertura.ser" file on the disk. You may need to dig around a bit to find it. Cobertura puts this file in what it considers to be the current working directory. Typically this is the directory that the application server was started from (for example, C:\Tomcat\bin) Note: This file is not written to the disk until the application server exits. See below for how to work around this.

现在你知道了在
cobertura.ser文件的位置，你应该
修改你的部署步骤，以便
将原来的cobertura.ser移动到

应用程序中的相应目录服务器，然后在完成测试后将其移回
。然后运行
cobertura-report。

Now that you know where the cobertura.ser file is, you should modify your deploy step so that it moves the original cobertura.ser to the appropriate directory in your application server, and then moves it back when finished testing. Then run cobertura-report.

[...]

对于Emma，这就是文档所说的：

For Emma, this is what the documentation says:

3.11。如何在{WebLogic，Websphere，Tomcat，JBoss，...}中使用EMMA？

首先，你几乎没有机会能够在完整的J2EE容器中使用动态模式（emmarun）。原因在于许多J2EE特性需要在EMMA工具类加载器之外进行专门的类加载。服务器可能运行正常，但您可能无法获得覆盖数据。

First of all, there is little chance that you will be able to use the on-the-fly mode (emmarun) with a full-blown J2EE container. The reason lies in the fact that many J2EE features require specialized classloading that will happen outside of EMMA instrumenting classloader. The server might run fine, but you will likely get no coverage data.

因此，正确的过程是在部署之前检测您的类（离线模式）。离线检测始终遵循相同的compile / instrument / package / deploy / get coverage / generate报告序列。请按照以下步骤操作：

Thus, the correct procedure is to instrument your classes prior to deployment (offline mode). Offline instrumentation always follows the same compile/instrument/package/deploy/get coverage/generate reports sequence. Follow these steps:

1. 使用EMMA的instr工具来检测所需的类。这可以在打包之前作为后编译步骤完成。但是，许多用户还发现让EMMA直接处理他们的罐子（就地，使用覆盖模式，或者通过在全文模式下创建所有内容的单独的检测副本）很方便;


2. 正常进行J2EE打包，但不要将emma.jar包含在此级别的lib中，即.war，.ear等;


3. 找到使用的JRE通过容器将emma.jar复制到其/ lib / ext目录中。如果这是不可能的，请将emma.jar添加到服务器类路径中（以特定于服务器的方式）;


4. 部署已检测的类，.jars，.wars，.ears等，并进行练习/通过客户端测试用例或以交互方式或以其中任何一种方式测试J2EE应用程序;


5. 获取覆盖转储文件，您有三个选项描述在什么选项中控制何时EMMA转储运行时覆盖数据？强烈建议您使用带有v2.1中提供的ctl工具的coverage.get控制命令。

1. use EMMA's instr tool to instrument the desired classes. This can be done as a post-compilation step, before packaging. However, many users also find it convenient to let EMMA process their jars directly (either in-place, using overwrite mode, or by creating separate instrumented copies of everything, in fullcopy mode);
2. do your J2EE packaging as normal, but do not include emma.jar as a lib at this level, that is, within your .war, .ear, etc;
3. locate whichever JRE is used by the container and copy emma.jar into its /lib/ext directory. If that is impossible, add emma.jar to the server classpath (in a server-specific way);
4. deploy your instrumented classes, .jars, .wars, .ears, etc and exercise/test your J2EE application via your client-side testcases or interactively or whichever way you do it;
5. to get a coverage dump file, you have three options described in What options exist to control when EMMA dumps runtime coverage data?. It is highly recommended that you use coverage.get control command with the ctl tool available in v2.1.

对于clover，请查看使用分布式应用程序页面。

For clover, check the Working with Distributed Applications page.

这篇关于Java：测量远程脚本测试的代码覆盖率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！