Redis内核单元测试框架

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
简介: 本文将对Redis内核单元测试框架进行基本的解析,并对如何编写测试用例进行基本的讲解。

在修改Redis内核之后,第一步我们需要做的就是添加或者对应的单元测试用例来进行基本的单元测试。本文将对Redis内核单元测试框架进行基本的解析,并对如何编写测试用例进行基本的讲解。

单元测试框架流程

Redis单元测试框架是基于tcl sh脚本实现的,其启动的方式为runtest [options]。
每一类的测试case写在单独的测试文件中,测试文件列表写入到test_server中all_tests列表中。
在启动测试时,会以server模式启动一个测试服务器,再启动多个测试客户端与之通信。由测试服务器会给空闲的测试服务端发送测试任务,参数为测试用例所在脚本文件名,由测试客户端执行对应的测试用例。详细的流程图如下:
redis_runtest

1. processOptions

对选项进行解析,其中默认的模式是server模式,进入test_server_main函数; 若带了client选项则进入test_client_main函数.

2. test_server_main

  1. 内部维护了一系列当前的测试客户端状态列表;
  2. accept_test_clients 创建一个socket fd,侦听来自测试客户端的消息;
  3. 按照传入的参数,以runtest --client的方式启动n个测试client;

3. test_client_main

启动测试客户端,往测试服务器的fd上发送ready消息,开启客户端与服务端的交互流程;

4. 客户端与服务端的交互

  1. 客户端启动后,往测试服务器fd上发送ready消息;
  2. 服务端收到客户端ready或done事件后,检查所有的测试集,若还有测试任务未完成,则使用signal_idle_client方法往测试客户端发送测试任务,即"run 测试用例脚本文件名"消息;
  3. 客户端收到run消息后,调用execute_tests $data方法执行测试用例脚本文件;
  4. 客户端执行完测试case脚本后,往服务端发送done事件。再次进入第2步;

测试用例编写

1. 增加测试用例

新建一个测试用例文件,比如dummy.tcl,将之加入到test_helper.tcl的all_tests列表里

set ::all_tests {
    unit/auth
    ...
    unit/dummy
    ...
}

这样启动测试的时候,会自动执行unit/dummy.tcl里面的测试用例;

2. 测试用例文件

每个测试用例文件里面可以包含多个start_server的部分,每个start_server都会启动一个redis实例。
每个start_server内部包含多个test函数模块,每个test函数对应一个测试用例。
例子:auth.tcl

start_server {tags {"auth"}} {
    test {AUTH fails if there is no password configured server side} {
        catch {r auth foo} err
        set _ $err
    } {ERR*no password*}
}

start_server {tags {"auth"} overrides {requirepass foobar}} {
    test {AUTH fails when a wrong password is given} {
        catch {r auth wrong!} err
        set _ $err
    } {ERR*invalid password}

    test {Arbitrary command gives an error when AUTH is required} {
        catch {r set foo bar} err
        set _ $err
    } {NOAUTH*}

    test {AUTH succeeds when the right password is given} {
        r auth foobar
    } {OK}

    test {Once AUTH succeeded we can actually send commands to the server} {
        r set foo 100
        r incr foo
    } {101}
}

3. 启动redis实例

启动单个实例

使用start_server可以启动一个redis实例. 启动的时候接受三种类型的参数:

  1. config: redis server的配置文件名,文件放到tests/assets目录下;
  2. override: 覆盖配置文件中的某个具体配置;
  3. tags: 该server的标示,一般用于log输出;
    启动一个redis实例的例子可以见上一节的auth.tcl.

启动多个实例

在进行主从同步测试,集群测试的时候,需要同时起多个redis实例,直接在一个test_server内部,再执行test_server即可。
例子:

start_server {tags {"repl"}} {
    start_server {} {
        test {First server should have role slave after SLAVEOF} {
            r -1 slaveof [srv 0 host] [srv 0 port]
            after 1000
            s -1 role
        } {slave}
    }
}

4. 执行redis命令

测试case中执行redis命令用r函数.(s函数与r函数类似,只是s函数会从info中提取返回值)

proc r {args} {
    set level 0
    if {[string is integer [lindex $args 0]]} {
        set level [lindex $args 0]
        set args [lrange $args 1 end]
    }
    [srv $level "client"] {*}$args
}

当同时启动多个redis实例时,使用r函数的第一个参数,标示具体在哪个实例上执行对应的命令。0为当前redis实例,-1为上一个启动的redis实例,以此类推。例如:

start_server {tags {"repl"}} {
    r set mykey foo

    start_server {} {
        test {Second server should have role master at first} {
            s role
        } {master}

        test {SLAVEOF should start with link status "down"} {
            r slaveof [srv -1 host] [srv -1 port]
            s master_link_status
        } {down}
    }
}

5. 结果判断

结果判断有几种方式:

  • assert类:详见support/test.tcl
  • fail "comment": 失败
  • test函数最后一个参数,支持正则表达式。其匹配的对象是最后一条redis命令返回的结果。例如:
    test {AUTH fails when a wrong password is given} {
        catch {r auth wrong!} err
        set _ $err
    } {ERR*invalid password}

    test {Arbitrary command gives an error when AUTH is required} {
        catch {r set foo bar} err
        set _ $err
    } {NOAUTH*}

6. 同步等待函数

wait_for_condition {maxtries delay e else elsescript}函数可以同步等待指定条件被满足。例:

        test "Fixed AOF: Keyspace should contain values that were parseable" {
            set client [redis [dict get $srv host] [dict get $srv port]]
            wait_for_condition 50 100 {
                [catch {$client ping} e] == 0
            } else {
                fail "Loading DB is taking too much time."
            }
            assert_equal "hello" [$client get foo]
            assert_equal "" [$client get bar]
        }

7. 随机生成数据

start_write_load {host port seconds}函数可以不停的往实例中写入数据。

8. 一个稍复杂的例子

下面是一个主从同步的例子,作为这一节的结束和测试。

foreach dl {no yes} {
    start_server {tags {"repl"}} {
        set master [srv 0 client]
        $master config set repl-diskless-sync $dl
        set master_host [srv 0 host]
        set master_port [srv 0 port]
        set slaves {}
        set load_handle0 [start_write_load $master_host $master_port 3]
        set load_handle1 [start_write_load $master_host $master_port 5]
        set load_handle2 [start_write_load $master_host $master_port 20]
        set load_handle3 [start_write_load $master_host $master_port 8]
        set load_handle4 [start_write_load $master_host $master_port 4]
        start_server {} {
            lappend slaves [srv 0 client]
            start_server {} {
                lappend slaves [srv 0 client]
                start_server {} {
                    lappend slaves [srv 0 client]
                    test "Connect multiple slaves at the same time (issue #141), diskless=$dl" {
                        # Send SALVEOF commands to slaves
                        [lindex $slaves 0] slaveof $master_host $master_port
                        [lindex $slaves 1] slaveof $master_host $master_port
                        [lindex $slaves 2] slaveof $master_host $master_port

                        # Wait for all the three slaves to reach the "online"
                        # state from the POV of the master.
                        set retry 500
                        while {$retry} {
                            set info [r -3 info]
                            if {[string match {*slave0:*state=online*slave1:*state=online*slave2:*state=online*} $info]} {
                                break
                            } else {
                                incr retry -1
                                after 100
                            }
                        }
                        if {$retry == 0} {
                            error "assertion:Slaves not correctly synchronized"
                        }

                        # Wait that slaves acknowledge they are online so
                        # we are sure that DBSIZE and DEBUG DIGEST will not
                        # fail because of timing issues.
                        wait_for_condition 500 100 {
                            [lindex [[lindex $slaves 0] role] 3] eq {connected} &&
                            [lindex [[lindex $slaves 1] role] 3] eq {connected} &&
                            [lindex [[lindex $slaves 2] role] 3] eq {connected}
                        } else {
                            fail "Slaves still not connected after some time"
                        }

                        # Stop the write load
                        stop_write_load $load_handle0
                        stop_write_load $load_handle1
                        stop_write_load $load_handle2
                        stop_write_load $load_handle3
                        stop_write_load $load_handle4

                        # Make sure that slaves and master have same
                        # number of keys
                        wait_for_condition 500 100 {
                            [$master dbsize] == [[lindex $slaves 0] dbsize] &&
                            [$master dbsize] == [[lindex $slaves 1] dbsize] &&
                            [$master dbsize] == [[lindex $slaves 2] dbsize]
                        } else {
                            fail "Different number of keys between masted and slave after too long time."
                        }

                        # Check digests
                        set digest [$master debug digest]
                        set digest0 [[lindex $slaves 0] debug digest]
                        set digest1 [[lindex $slaves 1] debug digest]
                        set digest2 [[lindex $slaves 2] debug digest]
                        assert {$digest ne 0000000000000000000000000000000000000000}
                        assert {$digest eq $digest0}
                        assert {$digest eq $digest1}
                        assert {$digest eq $digest2}
                    }
               }
            }
        }
    }
}

总结

Redis内核自动化测试框架可以同时启动多个测试客户端进行测试,其测试用例编写简便,测试效率高,使用起来非常方便。
该测试框架也可以很方便的改造成其它基于socket通信的服务的自动化测试框架。
简约,高效,这就是我对它的印象。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
17天前
|
人工智能 搜索推荐 数据管理
探索软件测试中的自动化测试框架选择与优化策略
本文深入探讨了在现代软件开发流程中,如何根据项目特性、团队技能和长期维护需求,精准选择合适的自动化测试框架。
68 8
|
23天前
|
人工智能 JavaScript 前端开发
自动化测试框架的演进与实践###
本文深入探讨了自动化测试框架从诞生至今的发展历程,重点分析了当前主流框架的优势与局限性,并结合实际案例,阐述了如何根据项目需求选择合适的自动化测试策略。文章还展望了未来自动化测试领域的技术趋势,为读者提供了宝贵的实践经验和前瞻性思考。 ###
|
1月前
|
人工智能 监控 测试技术
探索软件测试中的自动化框架选择与优化策略####
【10月更文挑战第21天】 本文深入剖析了软件测试领域面临的挑战,聚焦于自动化测试框架的选择与优化这一核心议题。不同于传统摘要的概述方式,本文将以一个虚拟案例“X项目”为线索,通过该项目从手动测试困境到自动化转型的成功历程,生动展现如何根据项目特性精准匹配自动化工具(如Selenium、Appium等),并结合CI/CD流程进行深度集成与持续优化,最终实现测试效率与质量的双重飞跃。读者将跟随“X项目”团队的视角,直观感受自动化框架选型的策略性思考及实践中的优化技巧,获得可借鉴的实战经验。 ####
36 0
|
12天前
|
Linux Shell 网络安全
Kali Linux系统Metasploit框架利用 HTA 文件进行渗透测试实验
本指南介绍如何利用 HTA 文件和 Metasploit 框架进行渗透测试。通过创建反向 shell、生成 HTA 文件、设置 HTTP 服务器和发送文件,最终实现对目标系统的控制。适用于教育目的,需合法授权。
46 9
Kali Linux系统Metasploit框架利用 HTA 文件进行渗透测试实验
|
18天前
|
安全 Ubuntu Linux
Metasploit Pro 4.22.6-2024111901 (Linux, Windows) - 专业渗透测试框架
Metasploit Pro 4.22.6-2024111901 (Linux, Windows) - 专业渗透测试框架
38 9
Metasploit Pro 4.22.6-2024111901 (Linux, Windows) - 专业渗透测试框架
|
26天前
|
Java 测试技术 API
探索软件测试中的自动化框架选择####
在当今快节奏的软件开发周期中,自动化测试已成为确保产品质量与加速产品迭代的关键策略。本文深入剖析了自动化测试的核心价值,对比分析了市场上主流的自动化测试框架,旨在为项目团队提供选型时的考量因素及实践指南,助力高效构建适应未来变化的自动化测试体系。 ####
|
22天前
|
Java 测试技术 API
探索软件测试中的自动化测试框架
本文深入探讨了自动化测试在软件开发中的重要性,并详细介绍了几种流行的自动化测试框架。通过比较它们的优缺点和适用场景,旨在为读者提供选择合适自动化测试工具的参考依据。
|
25天前
|
jenkins 测试技术 持续交付
自动化测试框架的搭建与实践
在软件开发领域,自动化测试是提升开发效率、确保软件质量的关键手段。本文将引导读者理解自动化测试的重要性,并介绍如何搭建一个基本的自动化测试框架。通过具体示例和步骤,我们将探索如何有效实施自动化测试策略,以实现软件开发流程的优化。
52 7
|
22天前
|
数据管理 jenkins 测试技术
自动化测试框架的设计与实现
在软件开发周期中,测试是确保产品质量的关键步骤。本文通过介绍自动化测试框架的设计原则、组件构成以及实现方法,旨在指导读者构建高效、可靠的自动化测试系统。文章不仅探讨了自动化测试的必要性和优势,还详细描述了框架搭建的具体步骤,包括工具选择、脚本开发、执行策略及结果分析等。此外,文章还强调了持续集成环境下自动化测试的重要性,并提供了实际案例分析,以帮助读者更好地理解和应用自动化测试框架。
|
23天前
|
监控 测试技术 定位技术
探索软件测试中的自动化测试框架选择与实施###
本文不概述传统意义上的摘要内容,而是直接以一段对话形式引入,旨在激发读者兴趣。想象一下,你是一名勇敢的探险家,面前摆满了各式各样的自动化测试工具地图,每张地图都指向未知的宝藏——高效、精准的软件测试领域。我们将一起踏上这段旅程,探讨如何根据项目特性选择合适的自动化测试框架,并分享实施过程中的关键步骤与避坑指南。 ###
32 4

相关产品

  • 云数据库 Tair(兼容 Redis)