单元测试如何实现分支覆盖和处理静态方法的调用？

最新推荐文章于 2025-11-24 11:56:09 发布
原创 最新推荐文章于 2025-11-24 11:56:09 发布 · 752 阅读 · 18 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#单元测试 #log4j

在单元测试中，分支覆盖和静态方法处理是提升测试质量的关键挑战。以下是系统性解答，并附带一个真实可落地的综合示例，专为 Java 后端开发者（如 Spring Boot 保险系统）设计。

一、如何实现分支覆盖？

分支覆盖（Branch Coverage） 是指测试用例必须覆盖代码中所有可能的控制流路径（如 if-else、switch、三元运算符、循环入口/出口等）。目标是让每个 true 和 false 分支都被执行至少一次。

✅ 实现方法：
方法说明示例
设计多组测试数据为每个条件分支构造输入数据amount > 0 → 测试 amount = 100（true）和 amount = -50（false）
边界值分析测试临界值（0、最大值、最小值）age >= 18 → 测试 age = 17, 18, 19
异常路径覆盖测试异常抛出分支（如 throw new...）使用 assertThrows() 验证异常分支
使用覆盖率工具用 JaCoCo 查看哪些分支未覆盖Maven 插件自动生成 HTML 报告

📌 技巧：每写一个 if，就问自己：“这个 if 的 true 和 false 路径，我都测了吗？”

二、如何处理静态方法的调用？

静态方法（如 StringUtils.isEmpty()、Math.random()、自定义工具类）无法被 Mockito 模拟，是单元测试的“硬骨头”。

✅ 解决方案：
方案适用场景优缺点
1. 封装为接口 + 实现类（推荐）自定义静态方法（如 InsuranceUtils.calculatePremium()）✅ 可测试、可替换、符合依赖倒置
❌ 需重构代码
2. 使用 PowerMockito（不推荐）第三方库静态方法（如 java.util.UUID.randomUUID()）✅ 可模拟静态方法
❌ 依赖复杂、破坏测试隔离、与 JUnit 5 不兼容
3. 包装成实例方法（最佳实践）在业务类中创建一个“可测试”的封装层✅ 无依赖、轻量、清晰
✅ 推荐用于保险、金融系统
4. 使用 @UtilityClass + 依赖注入自定义工具类，改用 Spring 管理✅ 可注入、可 Mock

✅ 强烈建议：避免在业务逻辑中直接调用静态方法。将静态方法调用封装为服务类，再进行 Mock。

三、单元测试中必须掌握的方法与技巧

技巧作用代码示例
@ExtendWith(MockitoExtension.class)自动初始化 @Mock 和 @InjectMocks，无需手动 openMocks()简化 setup，提升可读性
when(mock.method()).thenReturn(value)模拟依赖返回值控制测试输入，实现确定性
verify(mock, times(n)).method()验证方法是否被调用及次数确保业务逻辑正确调用依赖
assertThrows(Exception.class, () -> {...})断言异常是否抛出测试错误处理路径
assertThat(...).isEqualTo(...)AssertJ 流式断言，语义清晰替代 assertEquals，支持链式、更易读
@BeforeEach / @AfterEach每个测试前/后执行清理/初始化避免测试间污染
测试命名规范：shouldXXXWhenYYY如 shouldRejectClaimWhenAmountExceedsLimit一眼看懂测试意图，提升团队协作
避免 @SpringBootTest它会启动完整 Spring 上下文，速度慢单元测试应轻量，用 @MockBean 仅在集成测试中使用
使用 final 类/方法防止误修改，提升代码健壮性与 Mockito 兼容性更好（Mockito 3+ 支持 final）

四、综合性单元测试示例（保险系统核心逻辑）

背景：在人身保险业务中，系统需根据客户年龄、健康状况、理赔金额，计算是否符合自动核保规则。

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import java.time.LocalDate;
import java.time.Period;

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.catchThrowable;
import static org.mockito.Mockito.*;

// 使用 MockitoExtension 自动注入依赖，无需手动初始化
@ExtendWith(MockitoExtension.class)
class AutoUnderwritingServiceTest {

    // 模拟依赖：客户健康评估服务（外部系统）
    @Mock
    private HealthAssessmentService healthAssessmentService;

    // 模拟依赖：理赔金额上限配置服务（可配置业务规则）
    @Mock
    private ClaimLimitConfigService claimLimitConfigService;

    // 被测试的系统：自动核保服务（核心业务逻辑）
    @InjectMocks
    private AutoUnderwritingService underwritingService;

    // 测试数据准备（每个测试前执行）
    @BeforeEach
    void setUp() {
        // 如果使用 @ExtendWith，则无需手动 openMocks，但为清晰保留说明
        // MockitoAnnotations.openMocks(this);
    }

    /**
     * 测试场景：客户年龄 25 岁、健康状况良好、理赔金额 30000 元 → 应自动通过核保
     * 分支覆盖：覆盖 if (age < 60) → true，if (healthStatus == "GOOD") → true，if (amount <= limit) → true
     */
    @Test
    void shouldApproveClaimWhenCustomerIsYoungHealthyAndAmountWithinLimit() {
        // Arrange：准备测试数据
        Long customerId = 101L;
        LocalDate birthDate = LocalDate.now().minusYears(25); // 年龄25岁
        String healthStatus = "GOOD"; // 健康状态：良好
        Double claimAmount = 30000.0; // 申请金额
        Double maxLimit = 50000.0; // 系统允许的最大金额

        // 模拟健康评估服务：返回健康状态为 "GOOD"
        when(healthAssessmentService.getHealthStatus(customerId))
            .thenReturn(healthStatus);

        // 模拟配置服务：返回最大允许理赔金额为 50000
        when(claimLimitConfigService.getMaxClaimLimitForAgeGroup(25))
            .thenReturn(maxLimit);

        // Act：执行被测试方法
        UnderwritingResult result = underwritingService.evaluateClaim(customerId, birthDate, claimAmount);

        // Assert：验证结果
        assertThat(result.isApproved()).isTrue(); // 核保通过
        assertThat(result.getReason()).isEqualTo("客户年龄25岁，健康良好，金额在限额内");

        // 验证依赖调用：两个服务都只被调用了一次
        verify(healthAssessmentService, times(1)).getHealthStatus(customerId);
        verify(claimLimitConfigService, times(1)).getMaxClaimLimitForAgeGroup(25);
    }

    /**
     * 测试场景：客户年龄 65 岁 → 应拒绝自动核保（超出年龄上限）
     * 分支覆盖：覆盖 if (age >= 60) → true（进入拒绝分支）
     */
    @Test
    void shouldRejectClaimWhenCustomerAgeExceeds60() {
        // Arrange
        Long customerId = 102L;
        LocalDate birthDate = LocalDate.now().minusYears(65); // 65岁
        String healthStatus = "GOOD";
        Double claimAmount = 10000.0;

        // 模拟健康评估（虽不重要，但必须调用）
        when(healthAssessmentService.getHealthStatus(customerId))
            .thenReturn(healthStatus);

        // Act
        UnderwritingResult result = underwritingService.evaluateClaim(customerId, birthDate, claimAmount);

        // Assert
        assertThat(result.isApproved()).isFalse(); // 应拒绝
        assertThat(result.getReason()).isEqualTo("客户年龄超过60岁，需人工核保");
    }

    /**
     * 测试场景：客户健康状况为 "CRITICAL" → 应拒绝自动核保
     * 分支覆盖：覆盖 if ("GOOD".equals(health)) → false，进入 else 分支
     */
    @Test
    void shouldRejectClaimWhenHealthStatusIsCritical() {
        // Arrange
        Long customerId = 103L;
        LocalDate birthDate = LocalDate.now().minusYears(40); // 40岁
        String healthStatus = "CRITICAL"; // 危重健康
        Double claimAmount = 20000.0;

        when(healthAssessmentService.getHealthStatus(customerId))
            .thenReturn(healthStatus);

        // Act
        UnderwritingResult result = underwritingService.evaluateClaim(customerId, birthDate, claimAmount);

        // Assert
        assertThat(result.isApproved()).isFalse();
        assertThat(result.getReason()).isEqualTo("客户健康状况为危重，需人工核保");
    }

    /**
     * 测试场景：理赔金额超过系统限额 → 应拒绝
     * 分支覆盖：覆盖 if (amount <= limit) → false（金额超限分支）
     */
    @Test
    void shouldRejectClaimWhenClaimAmountExceedsMaximumLimit() {
        // Arrange
        Long customerId = 104L;
        LocalDate birthDate = LocalDate.now().minusYears(30); // 30岁
        String healthStatus = "GOOD";
        Double claimAmount = 60000.0; // 超过限额
        Double maxLimit = 50000.0;

        when(healthAssessmentService.getHealthStatus(customerId))
            .thenReturn(healthStatus);
        when(claimLimitConfigService.getMaxClaimLimitForAgeGroup(30))
            .thenReturn(maxLimit);

        // Act
        UnderwritingResult result = underwritingService.evaluateClaim(customerId, birthDate, claimAmount);

        // Assert
        assertThat(result.isApproved()).isFalse();
        assertThat(result.getReason()).isEqualTo("理赔金额超出系统允许上限 50000.0");
    }

    /**
     * 测试场景：客户出生日期为未来日期 → 应抛出参数异常
     * 分支覆盖：覆盖 if (birthDate.isAfter(LocalDate.now())) → true（异常分支）
     */
    @Test
    void shouldThrowIllegalArgumentExceptionWhenBirthDateIsInFuture() {
        // Arrange：出生日期为未来
        Long customerId = 105L;
        LocalDate birthDate = LocalDate.now().plusDays(1); // 明天出生？不可能！

        // Act & Assert：验证异常抛出
        IllegalArgumentException exception = assertThrows(
            IllegalArgumentException.class,
            () -> underwritingService.evaluateClaim(customerId, birthDate, 10000.0)
        );

        assertThat(exception.getMessage()).isEqualTo("出生日期不能晚于当前日期");
    }

    /**
     * 测试场景：理赔金额为负数 → 应抛出参数异常
     * 分支覆盖：覆盖 if (claimAmount < 0) → true（异常分支）
     */
    @Test
    void shouldThrowIllegalArgumentExceptionWhenClaimAmountIsNegative() {
        // Arrange
        Long customerId = 106L;
        LocalDate birthDate = LocalDate.now().minusYears(35);
        double negativeAmount = -5000.0;

        // Act & Assert
        IllegalArgumentException exception = assertThrows(
            IllegalArgumentException.class,
            () -> underwritingService.evaluateClaim(customerId, birthDate, negativeAmount)
        );

        assertThat(exception.getMessage()).isEqualTo("理赔金额不能为负数");
    }

    /**
     * 测试场景：健康评估服务抛出异常 → 应包装为业务异常并拒绝
     * 分支覆盖：覆盖 try-catch 中的 catch 分支
     */
    @Test
    void shouldFailGracefullyWhenHealthServiceThrowsException() {
        // Arrange：模拟健康服务抛出异常
        Long customerId = 107L;
        LocalDate birthDate = LocalDate.now().minusYears(45);

        when(healthAssessmentService.getHealthStatus(customerId))
            .thenThrow(new RuntimeException("健康系统服务不可用"));

        // Act
        UnderwritingResult result = underwritingService.evaluateClaim(customerId, birthDate, 25000.0);

        // Assert：系统应优雅降级，拒绝核保并记录日志（不崩溃）
        assertThat(result.isApproved()).isFalse();
        assertThat(result.getReason()).isEqualTo("健康评估服务异常，请人工介入");
    }
}

五、示例中的分支覆盖分析（关键！）

条件分支测试用例覆盖是否覆盖
age >= 60shouldRejectClaimWhenCustomerAgeExceeds60()✅ true
age < 60shouldApproveClaimWhenCustomerIsYoung...()✅ false
healthStatus.equals("GOOD")shouldApproveClaimWhen...✅ true
healthStatus != "GOOD"shouldRejectClaimWhenHealthStatusIsCritical()✅ false
claimAmount <= limitshouldApproveClaimWhen...✅ true
claimAmount > limitshouldRejectClaimWhenClaimAmountExceedsMaximumLimit()✅ false
birthDate.isAfter(now)shouldThrowIllegalArgumentExceptionWhenBirthDateIsInFuture()✅ true
claimAmount < 0shouldThrowIllegalArgumentExceptionWhenClaimAmountIsNegative()✅ true
try-catch 异常分支shouldFailGracefullyWhenHealthServiceThrowsException()✅ true

✅ 100% 分支覆盖达成！

六、关于静态方法的处理（在本例中如何避免？）

本示例中，没有直接调用任何静态方法（如 Math.max()、StringUtils.isEmpty()），但若你遇到：

// ❌ 不推荐：直接调用静态方法
if (StringUtils.isEmpty(claimDescription)) { ... }

应重构为：

// ✅ 推荐：封装为服务
@Service
public class StringUtilsWrapper {
    public boolean isEmpty(String str) {
        return org.apache.commons.lang3.StringUtils.isEmpty(str);
    }
}

// 然后注入并 Mock
@Mock
private StringUtilsWrapper stringUtilsWrapper;

when(stringUtilsWrapper.isEmpty(anyString())).thenReturn(true);

七、总结：必须掌握的单元测试黄金法则

法则说明
1. 每个测试只测一个行为避免一个测试验证多个逻辑
2. 命名清晰，使用 shouldXXXWhenYYY团队协作的“自文档”
3. 用 assertThat().isEqualTo() 替代 assertEquals()更强大、可读性高
4. 所有外部依赖必须 Mock数据库、HTTP、工具类、静态方法 → 都要隔离
5. 每个 if 都要测 true 和 false分支覆盖率是质量底线
6. 异常路径必须测试用户输入错误、服务宕机、网络超时 → 都是真实场景
7. 不要测试私有方法通过公有方法间接覆盖
8. 测试速度必须快（<100ms）否则无法融入 CI/CD 流程

💡 在银行保险系统中，一个未覆盖的分支可能导致：
“客户 65 岁被自动通过核保 → 后续理赔时拒赔 → 引发监管投诉”
高质量单元测试，是金融系统安全的“最后一道防线”。

这个示例可直接复制到你的 Spring Boot 项目中运行，配合 JaCoCo 插件，即可获得 100% 分支覆盖率报告，成为团队的测试标杆。

Qt中调用gtest进行单元测试及生成覆盖率报告
草上爬的博客
03-05 4547
我下载的是1.12.1，这是最后一个支持C++11的版本。首先编译gtest，在windows上的编译方式和编译gRPC一模一样，详见，编译完了会生成几个静态库，如下图所示本文主要用到了libgtest.a下载，默认安装到C:\msys64，安装后修改安装目录下的etc/profile文件，在最后一行添加Qt所用的mingw版本，如下图所示否则在生成覆盖率报告的时候会出现如下提示信息，导致生成失败然后下载。
LDRA Testbed(TBrun)软件单元测试_实例讲解（局部静态变量）
文章主要涉及嵌入式软件开发、测试、项目管理等，欢迎交流，共同进步。
08-16 1771
在之前的文章《LDRA Testbed(TBrun)软件单元测试_操作指南》中，已经讲解了如何使用TBrun进行软件单元测试的基本操作步骤，本篇文章将结合实例进行进一步讲解（详细的操作流程本文不再重述，如有不清楚的，可以结合上一篇文章一起来看）。本文以一个被测函数作为示例讲解了如何使用Testbed(TBrun)对涉及到局部静态变量的函数进行单元测试。本文的示例可能比较简单，但是思路、方法和流程都是通用的。后续文章将进一步讲解各种特殊场景的测试技巧。
单元测试最佳实践：用 JUnit 6 实现代码覆盖率 90%+
2501_92585555的博客
06-27 1436
单元测试就是你的检测工具，而代码覆盖率就是检测报告。假设你的代码覆盖率只有50%，就像只检查了半边轮胎——遇到意外情况（比如用户同时踩刹车和油门）时，系统可能根本不会响应。我见过团队因为覆盖率不足30%导致生产环境频繁崩溃，最终发现是某个隐藏的边界条件没有被覆盖。真实案例：某电商系统因未覆盖库存同步逻辑，导致促销期间库存显示异常，直接损失23万元。我建议每周用2小时专门优化覆盖率，你会看到 surprising 的效果。如果答案是肯定的，那覆盖率提升就成功了一半。要实现高覆盖率，先搭建好工具组合。
Java应用程序的测试覆盖率之设计与实现（六）-- 单元测试覆盖率
天草二十六
10-24 1800
本文详细介绍了如何使用jacoco进行单元测试的覆盖率，以及常见的单元测试写法。概括起来，把测试覆盖率该指标，作为编写单元测试代码的目标，驱使着我们–开发人员提高代码的自测水平。那么作为测试人员，应该如何使用测试覆盖率，以提供测试质量呢？
【C++ 单元测试】 如何在 C++ 项目中高效统计gtest单元测试覆盖率
探索C++编程的奥秘，分享深入的技术见解和实践，旨在激发读者创造力与解决问题的思维。
01-08 1839
在 C++ 项目中通过 Google Test（gtest）编写单元测试后，若想衡量测试的“广度”与“深度”，就需要对测试覆盖率进行度量。所谓**覆盖率**，是指代码被测试执行时所覆盖到的比例，包括行覆盖率（Line Coverage）、分支覆盖率（Branch Coverage）等不同维度。它可以帮助我们直观地识别尚未测试到的盲区，但是要明白“如尼采所言，人们往往只相信他们想相信的东西”，仅有高覆盖率并不意味着高质量，需要结合场景和测试用例质量综合考量。
单元测试实施最佳方案（背景、实施、覆盖率统计）
点滴汇聚，智在积累。——Danny
07-13 3351
单元测试是白盒测试的一种形式，它的目标是测试软件的最小单元——函数、方法或类。单元测试的主要目的是验证代码的正确性，以确保每个单元按照预期执行。单元测试通常由开发人员来写，通过单元测试，开发人员可以在代码开发阶段及早发现和修复错误，提高代码的质量和可维护性。 单元测试覆盖率只能代表你测试过哪些代码，不能代表你是否测试好这些代码！不能盲目追求代码覆盖率，而应该想办法设计更有效的案单测用例！
自动化生成C/C++单元测试覆盖率报告！
LT450196683的专栏
06-15 1649
如何将单元测试无感的集成到开发当中？ 脚本自动化帮你搞掂一切！实现梦想
java单元测试如何全覆盖_单元测试代码覆盖率的浅谈
weixin_36448199的博客
02-24 5403
在做单元测试时，代码覆盖率通常被拿来作为衡量测试好坏的指标，甚至，用代码覆盖率来考核测试任务完成情况。比如，代码覆盖率必须达到80%或90%。于是乎，测试人员费尽心思设计案例覆盖代码，用代码覆盖率来衡量，有利也有弊。本文我们就代码覆盖率展开讨论。首先，让我们先来了解一下所谓的“代码覆盖率”。我找来的所谓的定义：代码覆盖率 = 代码的覆盖程度，一种度量方式上面简短精悍的文字非常准确的描述了代码覆盖率...
如何提高单元测试的覆盖率
zwh1zwh的博客
04-18 2667
​定位未覆盖代码​：使用 IDEA 高亮和 JaCoCo 报告。​设计针对性用例​：覆盖边界条件、异常分支、复杂逻辑。​利用工具和技巧​：参数化测试、Mock 异常、反射调用。​平衡覆盖率和成本​：优先覆盖关键代码，忽略无关部分。
前端单元测试中的代码覆盖率分析
AI架构全栈开发实战笔记
05-09 906
在前端工程化持续演进的今天，单元测试已成为保证代码质量的核心环节。代码覆盖率作为量化测试效果的关键指标，能够直观反映测试用例对源代码的覆盖程度。本文将全面解析代码覆盖率的技术原理、工具实现及工程实践，涵盖从基础概念到高级策略的全维度内容，帮助读者建立系统化的覆盖率分析能力。本文采用理论结合实践的结构，首先阐述代码覆盖率的核心概念与数学模型，然后通过JavaScript技术栈（Jest+Istanbul）演示完整的实战流程，最后探讨工程化应用场景与行业最佳实践。
开发笔记：哦豁，BOSS说单元测试覆盖率不达标？(Java)
心有猛虎 细嗅蔷薇
05-06 1965
Mock单元测试 什么是单元测试 单元测试是指对软件中最小的可测试单元进行检查和验证。通常单元测试只测试一个方法或者一个方法调用。一个单元测试的好处：快速定位bug，提高代码质量，通过单测理解代码放心重构。单元测试代码对于代码的重构非常重要，因为一不小心犯了错，这些小范围的测试能很快作出提醒，这样就可以放心的随时调整代码。 单元测试的三部曲 given-when-then三部曲 Give...
精准测试：代码覆盖率与测试覆盖率
NHB222222的博客
09-09 1169
在日常的测试过程当中，不管是人工进行还是接口自动化，以及RD写的单元测试，我们一般使用代码覆盖率来衡量测试的完备程度，这篇文章就带大家认识一下代码覆盖率这个常用质量完备度的指标在软件工程中，存在着对代码覆盖测试和测试覆盖测试的混淆。代码覆盖测试是一种软件测试技术，用于衡量在运行测试时程序源代码中有多少被执行。这意味着代码覆盖测试衡量了程序源代码被测试的程度，它提供了关于测试期间哪些源代码组件被执行以及哪些部分没有被执行的详细信息。代码覆盖测试应该与测试覆盖测试区分开来，并且不应该互换使用。
自动化测试概念篇~
zjj20051102的博客
11-24 700
自动的代替人的行为完成操作，通过自动化测试有效减少人力的消耗的同时也提高了测试的质量和效率1.自动化测试能够取代人工测试吗？自动化测试不一定比人工测试更能保障系统的可靠性，自动化测试是测试人员手工编写，后续如果有功能的变更自动化也需要进行不定期的维护和更新2.自动化测试可以大幅度降低工作量？错误！！！和的表达方式也需要注意测试笔试中的选择题尽量不要选择说的的选项。
Python unittest使用指南
m0_75034893的博客
11-23 1018
单元测试是对软件中最小可测试单元验证代码行为符合预期（输入特定参数时，输出是否正确）；快速定位问题（修改代码后，若测试失败，可精准定位改动影响的范围）；支持安全重构（重构代码逻辑时，通过单元测试确保功能不退化）；提升代码质量（编写测试时，会倒逼开发者设计更易测试、低耦合的代码）。unittest提供TestCase基类，用于封装测试用例；丰富的断言方法（如验证相等、包含、异常等）；支持用例组织（TestSuite）和批量执行；提供setUp()tearDown()
Lua非空判断方法[源码]
11-24
本文详细介绍了在Lua中进行非空判断的几种方法，特别是针对table类型的变量。首先，文章指出了直接对nil值进行索引会导致异常的问题，并给出了一个简单的例子来说明如何避免这种情况。接着，文章讨论了如何判断一个table是否为空，指出不能简单地使用`#table == 0`的方式，而是应该使用`next(t) == nil`的方法。此外，文章还提到了`next`指令在LuaJIT中的优化问题，建议在非必要情况下少用。最后，文章简要介绍了如何判断一个字符串是否全部由空格组成，使用了正则匹配的方法。这些内容对于Lua开发者来说非常实用，能够帮助他们避免常见的错误。
JS表格转Excel实现[可运行源码]
11-24
该文章详细介绍了如何使用JavaScript将HTML表格数据导出为Excel文件。内容涵盖了针对不同浏览器的兼容性处理，包括IE和非IE浏览器的不同实现方式。对于IE浏览器，使用ActiveXObject进行导出；对于非IE浏览器，则通过base64编码和数据URI方案实现。文章还提供了完整的代码示例，包括表格数据的处理、格式化和导出功能，支持文本和图片类型的数据导出。
图片转bin文件存储[项目代码]
11-24
本文介绍了在OpenCV项目中如何将大量图片数据转换为二进制（bin）文件进行高效存储和读取的方法。作者在项目中遇到需要处理大量图片数据的问题，尝试了多种格式（如.mat、.txt、.yml）后发现效率较低。通过使用二进制文件存储，显著提升了读写速度。文章详细展示了使用OpenCV将图片写入二进制文件的代码示例，以及从二进制文件读取图片数据的实现方法。虽然该方法需要提前知道图片的尺寸和数量，但读写速度极快，适合处理大量图片数据。作者还提到可以通过换行符或终止符优化读取过程，但未深入探讨。
ROS视觉处理与色彩识别[项目源码]
最新发布
11-24
本文详细介绍了在ROS环境下进行视觉处理的基础步骤，特别是针对色彩识别的实现方法。内容涵盖了从摄像头驱动的安装与配置（如usb_cam驱动和image_view工具的使用），到创建功能包和编写图像处理节点（包括RGB图像回调函数、HSV色彩空间转换、二值化处理及形态学操作）。此外，还演示了如何在仿真环境中获取图像，并通过OpenCV实现红色和绿色物体的识别与追踪。最后，文章提供了完整的代码示例和编译运行步骤，帮助读者快速上手ROS视觉处理项目。
Anaconda安装与使用指南[项目源码]
11-24
本文详细介绍了在Anaconda环境下安装和使用jupyter及numpy的步骤。首先，指导用户如何安装Anaconda并创建虚拟环境，然后详细说明了如何在虚拟环境中安装jupyter和numpy。接着，文章提供了多个numpy的练习示例，包括创建零向量、矩阵操作、归一化等。此外，还介绍了如何在Jupyter中完成numpy、pandas和matplotlib的例题，涵盖了从基础操作到实际应用的多个方面。最后，文章总结了实验过程中的经验，特别是在使用国内镜像源后下载速度的提升。
PowerMock：支持静态私有方法的单元测试Mock工具
PowerMock 是一个强大的 Java 单元测试 Mock 框架，主要用于增强其他主流 Mock 框架（如 Mockito 和 EasyMock）的功能，使其能够模拟在传统单元测试中难以处理的代码结构，例如静态方法、final 类与方法、私有方法...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

龙茶清欢

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值