白盒测试实践案例

自律小盾宇

已于 2022-06-12 20:18:45 修改

阅读量4.9k

点赞数 2

分类专栏：测试开发日记文章标签：测试覆盖率

于 2022-06-12 20:11:34 首次发布

本文链接：https://blog.csdn.net/warmwater18/article/details/125141730

版权

测试开发日记专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、什么是白盒测试？

简而言之就是测代码，关注程序内部逻辑

二、为什么要做⽩盒测试？

如何准确的评估影响面？

在迭代非常快、测试开发比非常高的情况下，如何迅速的支撑项目和需求？开发可能改动了一行代码，但测试可能需要回归至少0.5天，而白盒测试可以通过gitdiff功能迅速的判断影响范围。

可以提升测试效率

例如我们在设计⽤例时，经常会考虑到等价类边界值的设计⽅法，那么你的⽤例是3条，⼤于、等

于、⼩于，从代码实现层面上来说，可能只是⼀⾏，例如：if (xxx > xxx){业务逻辑处理}

那么基于代码测试，只需要完成⼀条⽤例，保证流程没有问题，再判断该代码if及">"的业务逻辑是

否正确

提升测试覆盖率

某些异常场景，很难通过功能测试覆盖全⾯，本⽂下⾯会举例说明

三、如何入门做白盒测试

没有接触过⽩盒测试⼩伙伴们，刚开始做⽩盒测试时，可能会觉得代码⾮常之多，⽆从下⼿。个⼈建议是：

1.⼀定要参加开发每⼀次codreview

从流程规范来说codreview也是必须要测试参与的。刚开始你可能会觉得很不适应，但是⾄少你可以从业务逻辑正确性（是否与需求⼀致）的这个⻆度去给出你的建议

2.开发每⼀次提测，都先去看提交的代码

或许你还是看不懂，但是你可以多做总结，并且要养成这样的习惯，熟能⽣巧，你的⾛读能⼒会慢慢提升，另外也不要觉得向开发请教是件很不好意思的事情〜不懂的直接问，会⽐⾃⼰看代码快很多哟〜

有的时候你会发现⼀件很尴尬的事情，开发同学代码忘记提交了==！本⼈就有遇到过〜所以避免这种事情，其实也省了测试的时间

3.清楚基本的java语法

⾄少你要有最基本的知识储备，例如if/else/switch这种逻辑判断；枚举、接⼝的概念；清楚开发项目的分层：Dao、Service、Controller

4.在做接⼝⾃动化脚本测试时，熟悉开发代码

在梳理我们需要测的接⼝时，去慢慢的熟悉开发的代码，⽽且可以⼀定程度上提升脚本覆盖的场景

四、⽩盒测试实践

那么下⾯会开始根据我之前的一些项⽬、⽇常需求，来举例说明⽩盒测试具体的实践

Idea的gitdiff功能

先来介绍下Idea的gitdiff功能使用，通过该功能对比发布分支和主干分支的差异，我们可以知道开发这一次提交的代码的改动及影响范围

注：如果你不知道代码改动的⼊⼝类，可以直接问开发

gitdiff实践举例

状态节点及业务流程关注点

以下为我编写的伪代码（实际的业务代码可能比这个例子复杂很多），拿订单取消的这个业务来举例

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的同时，会帮我们发现⼀些⽤例设计问题

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

自律小盾宇

关注

2
点赞
踩
25

收藏

觉得还不错? 一键收藏
2
评论
白盒测试实践案例

目录编辑一、什么是白盒测试？二、为什么要做⽩盒测试？如何准确的评估影响面？可以提升测试效率提升测试覆盖率三、如何入门做白盒测试四、⽩盒测试实践Idea的gitdiff功能 gitdiff实践举例状态节点及业务流程关注点通过代码提升测试覆盖率白盒测试介入的时间点简而言之就是测代码，关注程序内部逻辑在迭代非常快、测试开发比非常高的情况下，如何迅速的支撑项目和需求？开发可能改动了一行代码，但测试可能需要回归至少0.5天，而白盒测试可以通过gitdiff功能迅速的判断影响范围。例如我们在设计⽤例时，经常会考虑到等
复制链接

扫一扫