|
在应用程序的开发中，验证应用程序的性能几乎总处于次要的地位。请注意，我强调的是验证 应用程序的性能。应用程序的性能总是 首要考虑的因素，但开发周期中却很少包含对性能的验证。 由于种种原因，性能测试常被延迟到开发周期的后期。以我的经验，企业之所以在开发过程中不包含性能测试是因为，他们不知道对于正在进行开发的应用程序要期待什么。提出了一些（性能）指数，但这些指数是基于预期负载提出的。 发生下列两种情况之一时，性能测试就成为头等大事：
本月，我将介绍两种简单的性能测试技术，在上述两种情况中的任何一种发生前进行测试。 改进代码质量别错过 Andrew 的 讨论论坛，里面有关于代码语法、测试框架以及如何编写专注于质量的代码的帮助。 用 JUnitPerf 进行测试在软件开发的早期阶段，使用 JUnit 很容易确定基本的低端性能指数。JUnitPerf 框架能够将测试快速地转化为简单的负载测试，甚至压力测试。 可使用 JUnitPerf 创建两种测试类型： 恰当的时限测试JUnitPerf 例如，假设存在一个 Widget 应用程序，其中，特定的对于业务致关重要的方法（如 创建 清单 1. 简单的 widget 测试public class WidgetDAOImplTest extends TestCase {
private WidgetDAO dao;
public void testCreate() throws Exception{
IWidget wdgt = new Widget();
wdgt.setWidgetId(1000);
wdgt.setPartNumber("12-34-BBD");
try{
this.dao.createWidget(wdgt);
}catch(CreateException e){
TestCase.fail("CreateException thrown creating a Widget");
}
}
protected void setUp() throws Exception {
ApplicationContext context =
new ClassPathXmlApplicationContext("spring-config.xml");
this.dao = (WidgetDAO) context.getBean("widgetDAO");
}
}由于 JUnitPerf 是一个基于装饰器的框架，为了真正地驾驭它，必须提供一个 也可以选择传入一个 例如，在清单 2 中，我在运行 清单 2. 为生成 TimedTest 而实现的 suite 方法public static Test suite() {
long maxElapsedTime = 2000; //2 seconds
Test timedTest = new TimedTest(
new WidgetDAOImplTest("testCreate"), maxElapsedTime);
return timedTest;
}此测试通常在 JUnit 框架中运行 —— 现有的 Ant 任务、Eclipse 运行器等等，会像运行任何其他 JUnit 测试一样运行这个测试。惟一的不同是，该测试将发生在计时器的上下文中。 过度的负载测试与在测试场景中验证一个方法（或系列方法）的时间限制正好相反，JUnitPerf 也方便了负载测试。正如在 使用 清单 3 是用 清单 3. 为生成负载测试而实现的 suite 方法public static Test suite() {
int users = 10;
Timer timer = new ConstantTimer(100);
return new LoadTest(
new WidgetDAOImplTest("testCreate"),
users, timer);
}请注意， 用样式进行装饰装饰器并不局限于单个的装饰物。例如，在 Java? I/O 中，可以为 装饰可以有多个层次，JUnitPerf 的
我通过为一个标准 清单 4. 经装饰的负载和时限测试public static Test suite() {
int users = 10;
Timer timer = new ConstantTimer(100);
long maxElapsedTime = 2000;
return new TimedTest(new LoadTest(
new WidgetDAOImplTest("testCreate"), users, timer),
maxElapsedTime);
}正如您所看到的那样， 使用注意尽管 JUnitPerf 是一个性能测试框架，但也要先大致估计一下测试要设定的性能指数。这是由于所有由 JUnitPerf 装饰的测试都通过 JUnit 框架运行，所以就存在额外的消耗，特别是在利用 fixture 时。由于 JUnit 本身用一个 相应地，我经常创建使用我想要的 fixture 逻辑的测试，但也会运行一个空白测试来确定性能指数基线。这是一个大致的估计，但它必须作为基线添加到任何想要的测试限制中。 例如，如果运行一个由 fixture 逻辑（使用 DbUnit）装饰的空白测试用时 2.5 秒，那么您想要的所有测试限制都应将这一额外时间考虑在内 —— 这可以从清单 5 中的基准测试中看到： 清单 5. JUnitPerf 基准测试public class DBUnitSetUpBenchmarkTest extends DatabaseTestCase {
private WidgetDAO dao = null;
public void testNothing(){
//should be about 2.5 seconds
}
protected IDatabaseConnection getConnection() throws Exception {
Class driverClass = Class.forName("org.hsqldb.jdbcDriver");
Connection jdbcConnection =
DriverManager.getConnection(
"jdbc:hsqldb:hsql://127.0.0.1", "sa", "");
return new DatabaseConnection(jdbcConnection);
}
protected IDataSet getDataSet() throws Exception {
return new FlatXmlDataSet(new File("test/conf/seed.xml"));
}
protected void setUp() throws Exception {
super.setUp();
final ApplicationContext context =
new ClassPathXmlApplicationContext("spring-config.xml");
this.dao = (WidgetDAO) context.getBean("widgetDAO");
}
}请注意，清单 5 的测试样例 也请记住，测试时间将依赖于机器的配置而变化，同时也依赖于在执行 JUnitPerf 测试时运行的东西而变化。我经常发现，将 JUnitPerf 测试放到它们自己的分类中有助于将它们同标准测试隔离开。这意味着，在运行一个测试时不必每次都运行 JUnitPerf 测试，例如在一个 CI 环境中签入代码。我也会创建特定的 Ant 任务，从而只在精心策划的将性能测试考虑在内的场景或环境中运行这些测试。 试试吧！用 JUnitPerf 进行性能测试无疑是一门严格的科学，但在开发生命周期的早期，这是确定和监控应用程序代码的低端性能的极佳方式。另外，由于它是一个基于装饰器的 JUnit 扩展框架，所以可以很容易地用 JUnitPerf 装饰现有的 JUnit 测试。 想想您已经花了这么多时间来担心应用程序在负载下会怎样执行。用 JUnitPerf 进行性能测试可以为您减少担忧并节省时间，同时也确保了应用程序代码的质量。 参考资料学习
获得产品和技术
讨论
|
|
|
来自： bananarlily > 《IT》
