专栏首页测试技术圈性能工具之代码级性能测试工具ContiPerf

性能工具之代码级性能测试工具ContiPerf

前言

做性能的同学一定遇到过这样的场景:应用级别的性能测试发现一个操作的响应时间很长,然后要花费很多时间去逐级排查,最后却发现罪魁祸首是代码中某个实现低效的底层算法。这种自上而下的逐级排查定位的方法,效率通常都很低,代价也很高。所以,我们就需要在项目早期,对一些关键算法进行代码级别的性能测试,以防止此类在代码层面就可以被发现的性能问题,遗留到最后的系统性能测试阶段才被发现。但是,从实际执行的层面来讲,代码级性能测试并不存在严格意义上的测试工具,通常的做法是:改造现有的单元测试框架

而最常使用的改造方法是:

  • 将原本只会执行一次的单元测试用例连续执行 n 次,这个 n 的取值范围通常是 2000~5000;
  • 统计执行 n 次的平均时间。如果这个平均时间比较长(也就是单次函数调用时间比较长)的话,比如已经达到了秒级,那么通常情况下这个被测函数的实现逻辑一定需要优化。

这里之所以采用执行 n 次的方式,是因为函数执行时间往往是毫秒级的,单次执行的误差会比较大,所以采用多次执行取平均值的做法。

那么有没有现成的这样的测试工具呢?

当然也是有的,比如今天我们介绍的主角-- ContiPerf

ContiPerf 简介

ContiPerf 是一个轻量级的测试工具,基于JUnit 4 开发,可用于效率测试等。可以指定在线程数量和执行次数,通过限制最大时间和平均执行时间来进行性能测试。

官网地址:https://sourceforge.net/p/contiperf/wiki/Home

ContiPerf 使用

接下来我们一起来实践一个例子,

首先,加入 pom 依赖包:

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>

        <!--引入 ContiPerf 测试工具-->
        <dependency>
            <groupId>org.databene</groupId>
            <artifactId>contiperf</artifactId>
            <version>2.3.4</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency><dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <scope>test</scope>
    </dependency>

这里为了演示,编写了一个简单的测试接口: UnitTestService.java

/**
 * 测试接口类
 * @author zuozewei
 *
 */
public interface UnitTestService {

    public String process(String msg);

}

实现类:UnitTestServiceImpl.java

@Service
public class UnitTestServiceImpl implements UnitTestService {

    /**
     * 为了测试,这里直接返回传入的值
     */
    @Override
    public String process(String msg) {
        // TODO Auto-generated method stub
        return msg;
    }
}

编写 UnitTestServiceTest 测试类,进入 ContiPerfRule。

/**
 * 编写接口性能测试类
 * @author zuozewei
 *
 */
@RunWith(SpringRunner.class)
@SpringBootTest //SpringBootTest 是springboot 用于测试的注解,可指定启动类或者测试环境等,这里直接默认。
public class UnitTestServiceTest {

    @Autowired
    UnitTestService testService;

    // 引入 ContiPerf 进行性能测试
    @Rule
    public ContiPerfRule contiPerfRule = new ContiPerfRule();

    @Test
    @PerfTest(invocations = 10000,threads = 100) //100个线程 执行10000次
    public void test() {
        String msg = "this is a test";
        String result = testService.process(msg);
        //断言 是否和预期一致
        Assert.assertEquals(msg,result);
    }
}

注意: @Rule 是J unit 提供的一个扩展接口注解,其接口类为:org.junit.rules.MethodRule,注意在 Junit5 中,已经被 TestRule 所替代了。也可以通过对类指定 @PerfTest 和 @Required,表示类中方法的默认设置。 @PerfTest注解:

  • invocations:执行次数n,与线程数量无关,默认值为1
  • threads:线程池数量n,并发执行n个线程
  • duration:重复执行时间n,测试至少执行n毫秒

@Required注解:

  • @Required(throughput = 20):要求每秒至少执行20个测试;
  • @Required(average = 50):要求平均执行时间不超过50ms;
  • @Required(median = 45):要求所有执行的50%不超过45ms;
  • @Required(max = 2000):要求没有测试超过2s;
  • @Required(totalTime = 5000):要求总的执行时间不超过5s;
  • @Required(percentile90 = 3000):要求90%的测试不超过3s;
  • @Required(percentile95 = 5000):要求95%的测试不超过5s;
  • @Required(percentile99 = 10000):要求99%的测试不超过10s;
  • @Required(percentiles = “66:200,96:500”):要求66%的测试不超过200ms,96%的测试不超过500ms。

运行测试,控制台会生成结果:

com.zuozewei.springbootcontiperfdemo.service.UnitTestServiceTest.test
samples: 10000
max:     331
average: 33.3522
median:  30

同时访问:target/contiperf-report/index.html,会生成图表:

注意:图表需要科学上网才能显示 图表中的指标:

  • Execution time: 执行时间
  • Throughput: TPS
  • Min. latency: 最小响应时间
  • Average latency: 平均响应时间
  • Median: 响应时间中位数
  • 90%: 90%响应时间范围
  • Max latency: 最大响应时间

小结

这里主要是对 Junit 和 ContiPerf 的使用简单的示例,在单元测试阶段的时候考虑做这种代码级性能测试,肯定会提高 ROI(投入产出比)的,而且代价非常小,希望本文对各位同学都能有所启发。

示例代码:

https://github.com/7DGroup/JMeter-examples/tree/master/contiperf/springboot-contiperf-demo

参考资料: [1]:https://sourceforge.net/p/contiperf/wiki/Home [2]:软件测试52讲 茹炳晟

本文分享自微信公众号 - V社 北京社(SoftwareTesters)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 使用fasttext来构建你的第一个文本分类器

    最近在做一些意图识别方面的工作,所以尝试一下用 fasttext 做一个文本分类器,学习记录如下。

    呼延十
  • 测试STM32远程乒乓升级,基于GPRS模块AT指令TCP透传方式,MQTT通信控制升级

      这节和上一节的功能一样(只不过上节是利用Wi-Fi模块,这节是利用GPRS模块)

    杨奉武
  • 测试开发者盛宴!WeTest邀您一同参加2019 MTSC移动测试开发大会

    ? 导读   MTSC2019 中国移动互联网测试开发大会(Mobile Testing Summit China)由国内最大的测试开发技术社区之一 Tes...

    WeTest质量开放平台团队
  • JavaScript测试教程-part 2:引入 Enzyme 并测试 React 组件[每日前端夜话0xE8]

    在本教程的第一篇中,我们简要介绍了单元测试的基础。这次要更进一步,使用 Enzyme 库测试 React。这样可以使你的程序将更加可靠,并且更加容易避免回归。我...

    疯狂的技术宅
  • ProxySQL Cluster +PXC 高可用集群的搭建

    https://blog.51cto.com/lee90/2299815 # 开启web监控页面

    二狗不要跑
  • Laravel中APP_KEY起什么作用

    传送门:https://segmentfault.com/q/1010000009773300

    咪啪咪啪
  • pytorch-Train-Val-Test划分(上)

    本节介绍的是Train/Val/Test部分的划分,合理的划分会有效地减少under-fitting和over-fitting现象。

    用户6719124
  • 移动端自动化测试-远程设备调度

    “云测” 是近几年业内的热词, 不仅仅商用的云测平台越来越多,各大厂也早早的着手构建适合自己的云测平台上 ,经常可以听到相关的分享,十分精彩,受益匪浅...

    测试开发社区
  • Mars 测试报告

    本测试报告,是在我自己的电脑上用jmeter测出来的, 所有接口都是配置的300个线程循环10次,报告中所展示的数据都是测了3次,取的中位数

    用户2409793
  • SGM-Nets:第一个将SGM与深度学习结合的网络

    本文将对2017年的CVPR会议文章《SGM-Nets: Semi-global matching with neural networks》进行简介,该论文作...

    OpenCV学堂

扫码关注云+社区

领取腾讯云代金券