
if(OrderStatusEnum.Cancel.getCode()){
    return "订单已取消";
}else if(OrderStatusEnum.Paid.getCode() && OrderStatusEnum.ToBePaid.getCode()){
    return "订单取消成功";
}else{
    "订单已发货，请申请售后";
}

首先我们的测试用例如下：

当你进行测试的时候，你需要走这样至少4条测试用例，如果你的系统业务非常复杂，那么可能存在造一条订单数据非常复杂，你需要配置各种前置数据，例如商品、库存等等，如果不巧碰到了上游的问题阻塞了流程，那么就阻塞了测试进度。而从代码层面来说，可能只是不同的枚举类型的判断逻辑，所以通过代码进行测试，可以提升一定的测试效率

那么我们的关注点有哪些？

if/else的判断逻辑全面性

接口的幂等性，已取消的订单直接幂等处理返回成功

通过代码提升测试覆盖率

上⽂有说到，某些业务场景，是⾮常难通过功能测试覆盖到的，特别是一些中间件相关问题，例如以下的一些问题：

案例一：Jedis连接池泄漏

Jedis jedis = pool.getResource().set(redisKey,value)

代码的问题：

使用Jedis未关闭连接池，会导致连接池泄漏。这个问题比较难以通过功能测试去发现，一般在性能测试才会暴露这个问题，如果当前项目正好是不需要进行性能测试的，那么就比较容易出现漏测的情况

正确的代码：

注意要在finally关闭连接池


private void getJedis(){
    Jedis Jedis = jedisPool.getResource();
    return jedis;
}
 
public String get(String key){
    String value = null;
    try(Jedis Jedis = getJedis()){
        value = jedis.get(key);
        return value;
    }catch (Exception e) {
        log.error("redis exception"){
            return value;
        }
    }finally {
        jedis.close();
    }
    
}

案例二：Kafka异常消息处理

在消息中间件的代码中，我们需要关注异常的消息是否有在finally内进行处理，如果异常的消息不做处理，会导致消息堆积


while (true) {
        val records = consumer.poll(Duration.of(1L, ChronoUnit.SECONDS))
        records.forEach {
            try {
                logger.info("receive testcase: ${it.value()}")
                EngineContext.runHistoryId = it.key().toLong()
                val testcase = parser.parse(it.value())
                testEngine.executeTestPlan(testcase)
            } catch (e: Exception) {
                e.printStackTrace()
            } finally {
                consumer.commitAsync()
            }
        }
    }

白盒测试介入的时间点

未提测的时候，提前开始看开发的代码，提前发现⼀些编码问题，不⽤到正式测试才发现测试完成之后发布之前，开发⼀般会做code review

正式测试之前做⽐较有优势，发现开发编码bug的同时，会帮我们发现⼀些⽤例设计问题

以上就是我的经验分享，因为公司的很多代码和案例不方便贴出来，所以案例有些少。如果有写的不对的地方，欢迎小伙伴们来指正、交流～

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/831692