标签 单元测试 下的文章

手把手教你使用ANTLR和Go实现一门DSL语言(第三部分):建立和验证语义模型

本文永久链接 – https://tonybai.com/2022/05/27/an-example-of-implement-dsl-using-antlr-and-go-part3

在前面的系列文章中,我们为气象学家们设计了一门名为Tdat的DSL,使用ANTLR的文法规则编写了Tdat的文法,基于该文法生成了Tdat的语法解析器代码并初步验证了文法的正确性,Tdat可以成功将我们编写的Tdat语法代码样例解析为一颗内存中的树结构。

此时此刻,我们编写的DSL语法代码还无法按预期工作,因为缺少执行语义。在这篇文章中,我们就来为这门DSL建立语义模型,并单独对这个语义模型进行验证。

让我们的语法示例能真正按预期run起来!

一. 什么是语义模型

通过前面的文章,我们了解到:文法只是形式化了DSL的语法结构,即在语法树中是如何表现的,而这一切与语义无关。而所谓语义,就是当用这个语法写的代码执行时,它会做什么

相同的语法,即便生成相同的语法树,那么由于对语法树的解释方法不同,语义就会不同。下面是Martin Fowler在其《领域特定语言》一书中的一个例子:

我们看到对同一语法写成的代码:5+3,如果语义模型不同,那么执行结果就不会相同:如果按加法语义解释语法树,我们得到的代码执行结果为8;如果按连接语义解释语法树,我们得到的代码执行结果为53。

那么语义模型究竟表现为何种形式呢?通常来说语义模型也是内存中的一个或一些特定的数据结构,这个数据结构存在的目的就是表述语义,对语句的执行逻辑进行制导

比如:《使用ANTLR和Go实现DSL入门》一文中的那个csv2map例子,其语义模型就存储在CSVMapListener这个结构体中的一个map结构(见下面的cm字段)和切片结构(见下面的headers)中了:

// github.com/bigwhite/experiments/tree/master/antlr/csv2map/csv_listener.go

type CSVMapListener struct {
    *parser.BaseCSVListener
    headers []string
    cm      []map[string]string
    fields  []string // a slice of fields in current row
}

csv2map通过遍历生成的语法树提取信息填充构造了cm和headers这两个字段,后续的代码执行都是基于这两个字段中存储的信息。

到这里有童鞋可能会问:是不是对所有DSL都要单独提取和组装一个语义模型出来呢?至少Martin Fowler建议这么做,这样做的最大好处就是将语法解析与语义执行这两个阶段解耦,然后语义模型可以单独拿出来测试与验证,无需依赖语法解析过程。

我个人觉得对于稍大一些的non-trivial的DSL来说,将语义模型分离出来还是很必要的,否则语义执行与语法解析的耦合会让DSL的实现难于理解、难于维护,同样也难于测试验证。

对于一些简单的DSL来说,其语法树自身就可以看作是一个语义模型,在这样的情况下,语法树的遍历过程将伴随着语句语义的执行,下面就是一个典型的以语法树为语义执行模型的例子(改编自这篇文章中的例子),例子文法如下:

// Calc.g4
grammar Calc;

// Rules
start : expression EOF;

expression
   : expression op=('*'|'/') expression # MulDiv
   | expression op=('+'|'-') expression # AddSub
   | NUMBER                             # Number
   ;

// Tokens
MUL: '*';
DIV: '/';
ADD: '+';
SUB: '-';
NUMBER: [0-9]+;
WHITESPACE: [ \r\n\t]+ -> skip;

基于该文法生成Parser代码后,我们实现一个语法树的Listener:

// calc/calc_listener_impl.go

type calcListener struct {
    *parser.BaseCalcListener
    stack []int
}

... ...

func (l *calcListener) ExitMulDiv(c *parser.MulDivContext) {
    right, left := l.pop(), l.pop()

    switch c.GetOp().GetTokenType() {
    case parser.CalcParserMUL:
        l.push(left * right)
    case parser.CalcParserDIV:
        l.push(left / right)
    default:
        panic(fmt.Sprintf("unexpected op: %s", c.GetOp().GetText()))
    }
}

func (l *calcListener) ExitAddSub(c *parser.AddSubContext) {
    right, left := l.pop(), l.pop()

    switch c.GetOp().GetTokenType() {
    case parser.CalcParserADD:
        l.push(left + right)
    case parser.CalcParserSUB:
        l.push(left - right)
    default:
        panic(fmt.Sprintf("unexpected op: %s", c.GetOp().GetText()))
    }
}

func (l *calcListener) ExitNumber(c *parser.NumberContext) {
    i, err := strconv.Atoi(c.GetText())
    if err != nil {
        panic(err.Error())
    }

    l.push(i)
}

这段代码直接将Parser建立的语法树当成了二叉表达式树(binary expression tree,叶子节点是操作数,其他节点为操作符)了,然后通过表达式树求值算法(借由一个stack)实现代码的求值语义,看下面驱动求值的main函数代码:

// calc/main.go

// calc takes a string expression and returns the evaluated result.
func calc(input string) int {
    // Setup the input
    is := antlr.NewInputStream(input)

    // Create the Lexer
    lexer := parser.NewCalcLexer(is)
    stream := antlr.NewCommonTokenStream(lexer, antlr.TokenDefaultChannel)

    // Create the Parser
    p := parser.NewCalcParser(stream)

    // Finally parse the expression (by walking the tree)
    var listener calcListener
    antlr.ParseTreeWalkerDefault.Walk(&listener, p.Start())

    return listener.pop()
}

func main() {
    println(calc("1 + 2 * 3"))  // 7
    println(calc("12 * 3 / 6")) // 6
}

通过上述代码,我们可以很清晰地看到这个例子直接将源码解析后建立的语法树作为语义模型了,这就让语义模型与解析后的语法树的结构产生了紧耦合,一旦语法变更,语法树结构发生变化,就会直接影响语义模型的执行,语义模型的实现也要随之变更。

针对我们自己的tdat DSL,我们将采用语义模型与语法树分离的方式。下面我们就来看看tdat的语义模型。

二. 语义模型之表达式树

在本系列的第一篇文章中,我们介绍了Tdat这门DSL的语义特性,我们的语义模型就是要实现这些语义特性。我们回顾一下tdat文法中的核心产生式规则ruleLine:

ruleLine
    : ruleID ':' enumerableFunc '{' windowsRange conditionExpr '}' '=>' result ';'
    ;

在这个产生式规则中,影响语义计算的主要规则包括:conditionExpr、windowRange、enumableFunc和result上,而最复杂的又在conditionExpr这个规则上。这个规则本质上就是一组一元、算术、比较和逻辑表达式的混合计算,

那么,我们能否像上面calc那个例子那样将语法树直接用作语义模型呢?实现层面上是可以的。我们以下面这个复杂一些的conditionExpr表达式为例:

(($speed < 5) and (($temperature + 1) < 10)) or ((roundDown($speed) <= 10.0) and (roundUp($salinity) >= 500.0))

我们来对比一下直接将语法树作为语义模型与使用表达式树结构作为语义模型的差别:

通过上图,我们看到,语法树是为了解析语法而构建的,并非为表达式树计算而构建,如果我们直接基于语法树去做语义计算,一来要多遍历一些无关的符号节点(非红圈里的节点),有额外开销,影响性能;二来这里的tdat使用的conditionExpr并非标准二叉表达式树,我们需要自己设计表达式求值的算法;最后就是Martin Fowler提到的语法解析与语义模型耦合在一起的弊端了。在语义模型不变的情况下,一旦语法结构发生变更,影响的不仅仅是语法树的结构,语义模型的求值行为也要一并改动。

因此这里我们直接将语义模型与语法树分离,我们采用上图中下方的二叉表达式树作为主要语义模型。这样我们就可以单独建立实现和测试该语义模型了。

像上图下方那样的一个典型的二叉表达式树可由一个逆波兰表达式(Reverse Polish notation)构建而成,构建算法可以参考《数据结构与算法分析:C语言描述(原书第2版》的4.2.2小节。

下面我就来简单说说这个表达式树的构建与求值实现。

我们先来建立一个二叉Tree数据结构:

// tdat/semantic/semantic.go

// semantic tree
type Tree interface {
    GetParent() Tree
    SetParent(Tree)
    GetValue() Value
    SetLeftChild(Tree) Tree
    GetLeftChild() Tree
    SetRightChild(Tree) Tree
    GetRightChild() Tree
}

type Value interface {
    Type() string
    Value() interface{}
}

// Node is an implementation of Tree
// and each node can be seen as a tree
type Node struct {
    V Value
    l *Node // left node
    r *Node // right node
    p *Node // parent node
}

我们建立了一个二叉树的接口类型,并提供了用于实现该接口类型的结构体类型Node。每个Node是Tree中的一个节点,它自身也可以被看成是一个Tree。树中每个Node都有一个Value,Value也是一个接口类型,它共有四种实现:

  • BinaryOperator

二元运算符,包括:二元算术运算符(+、-、*、/、%等)、关系运算符(>、<、>=、<=、==等)和二元逻辑运算符(and与or)。

  • UnaryOperator

一元运算符/内置函数,包括:roundUp、roundDown、abs等,可扩展。

  • Variable

用于表示数据指标,比如:speed、temperature等。

  • Literal

字面值,比如:10、3.1415、”hello”,通常做右值,或与Varible通过二元算术运算符构成表达式。

BinaryOperator和UnaryOperator都属于操作符,而Variable和Literal都属于操作数。这样,一个表达式树就是以操作数为叶子节点,以操作符为其他节点的树。由于树最多是二元操作符,所以表达式树正好是一个二叉树,一元运算符的操作数默认放置在左子节点处。

上面提到过,我们可以基于逆波兰表达式来构建出这样的一棵表达式树,下面就是基于逆波兰表达式构建这棵Tree的实现:

// semantic/semantic.go

// construct a tree based on a reversePolishExpr
func NewFrom(reversePolishExpr []Value) Tree {
    var s Stack[Tree]
    for _, v := range reversePolishExpr {
        switch v.Type() {
        case "literal", "variable":
            s.Push(&Node{
                V: v,
            })
        case "binop":
            rchild, lchild := s.Pop(), s.Pop()
            n := &Node{
                V: v,
            }
            n.SetLeftChild(lchild)
            n.SetRightChild(rchild)
            s.Push(n)
        case "unaryop":
            lchild := s.Pop()
            n := &Node{
                V: v,
            }
            n.SetLeftChild(lchild)
            s.Push(n)
        }

    }
    first := s.Pop()
    root := &Node{}
    root.SetLeftChild(first)
    return root
}

在这份实现中,我们借由一个stack缓存子树结点。我们从左向右逐一读取逆波兰表达式中的操作符或操作数:

  • 如果读出来的Value是操作数(literal或variable),则将该操作数打包成一个Node(可理解为子树),压到栈中;
  • 如果读出来的Value是一个二元操作符,则将从栈中出栈两个节点,分别作为二元操作符节点的左右节点,合并后的子树再压到栈中;
  • 如果读出来的Value是一个一元操作符,则从栈中弹出一个节点,作为一元操作符节点的左节点,合并后的子树再压到栈中。
  • 栈中最后存放的就是树的最顶层操作符节点,将该节点弹出后作为Root节点的左子节点,表达式树的构造就结束了。而这个Root节点与众不同的特征是其parent为nil(遍历树时会用到)。

构建后的这棵Tree究竟长啥样呢?我们可以通过Dump函数来查看:

func printPrefix(level int) {
    for i := 0; i < level; i++ {
        if i == level-1 {
            fmt.Printf(" |---")
        } else {
            fmt.Printf("     ")
        }
    }
}

func Dump(t Tree, order string) {
    var f = func(n *Node, level int) {
        if n == nil {
            return
        }

        printPrefix(level)

        if n.p == nil {
            // root node
            fmt.Printf("[root]()\n")
        } else {
            fmt.Printf("[%s](%v)\n", n.V.Type(), n.V.Value())
        }
    }

    switch order {
    default:
        // preorder
        preOrderTraverse(t.(*Node), 0, f, nil)
    case "inorder":
        inOrderTraverse(t.(*Node), 0, f, nil)
    case "postorder":
        postOrderTraverse(t.(*Node), 0, f, nil)
    }
}

Dump基于树的遍历,提供了以前序(preOrder)、中序(inOrder)和后序(postOrder)遍历方式输出Tree的各个Node的特性。树的遍历是树的基本操作, 以前序遍历为例,看看遍历的实现:

// pre order traverse
func preOrderTraverse(t *Node, level int, enterF func(*Node, int), exitF func(*Node, int)) {
    if t == nil {
        return
    }

    if enterF != nil {
        enterF(t, level) // traverse this node
    }

    // traverse left children
    preOrderTraverse(t.l, level+1, enterF, exitF)

    // traverse right children
    preOrderTraverse(t.r, level+1, enterF, exitF)

    if exitF != nil {
        exitF(t, level) // traverse this node again
    }
}

这里借鉴了ANTLR语法解析树的“思路”,在遍历每个Node时都提供enterF和exitF的回调,用于用户自定义遍历Node时的行为。了解了原理后,我们看看基于下面逆波兰表达式:

speed,50,<,temperature,1,+,4,<,and,salinity,roundDown,600,<=,ph,roundUp,8.0,>,or,or

构建的Tree的样子如下:

[root]()
 |---[binop](or)
      |---[binop](and)
           |---[binop](<)
                |---[variable](speed)
                |---[literal](50)
           |---[binop](<)
                |---[binop](+)
                     |---[variable](temperature)
                     |---[literal](1)
                |---[literal](4)
      |---[binop](or)
           |---[binop](<=)
                |---[unaryop](roundDown)
                     |---[variable](salinity)
                |---[literal](600)
           |---[binop](>)
                |---[unaryop](roundUp)
                     |---[variable](ph)
                |---[literal](8)

一旦Tree构建完毕,我们就可以基于该Tree进行求值了。下面是求值函数Evaluate的实现:

func Evaluate(t Tree, m map[string]interface{}) (result bool, err error) {
    var s Stack[Value]

    defer func() {
        // extract error from panic
        if x := recover(); x != nil {
            result, err = false, fmt.Errorf("eval error: %v", x)
            return
        }
    }()

    var exitF = func(n *Node, level int) {
        if n == nil {
            return
        }

        if n.p == nil {
            // root node
            return
        }   

        v := n.GetValue()
        switch v.Type() {
        case "binop":
            rhs, lhs := s.Pop(), s.Pop()
            s.Push(evalBinaryOpExpr(v.Value().(string), lhs, rhs))
        case "unaryop":
            lhs := s.Pop()
            s.Push(evalUnaryOpExpr(v.Value().(string), lhs))
        case "literal":
            s.Push(v)
        case "variable":
            name := v.Value().(string)
            value, ok := m[name]
            if !ok {
                panic(fmt.Sprintf("not found variable: %s", name))
            }

            // use the value in map to replace variable
            s.Push(&Literal{
                Val: value,
            })
        }
    }

    preOrderTraverse(t.(*Node), 0, nil, exitF)
    result = s.Pop().Value().(bool)
    return
}

虽然这里用的是preOrderTraverse,但我们是在exitF回调中做的计算,因此这里等价于一个标准的树的后序遍历。每当遇到操作数,就入栈;当操作数为variable时,在输入参数中map中查找该variable是否存在,如存在,则将值压入栈。每当遇到操作符,则将操作数弹栈计算后,再入栈。如此,最终栈内仅保存一个值,就是这个表达式树的计算结果。

三. 验证语义模型之表达式树

前面说过,语义模型与语法树分离后,我们可以对语义模型进行单独测试,下面就是一个简单的基于表驱动的对表达式树的单元测试

// tdat/semantic/semantic_test.go

func TestNewFrom(t *testing.T) {
    //($speed < 50) and (($temperature + 1) < 4) or ((roundDown($salinity) <= 600.0) or (roundUp($ph) > 8.0))
    // speed,50,<,temperature,1,+,4,<,and,salinity,roundDown,600,<=,ph,roundUp,8.0,>,or,or
    var reversePolishExpr []Value

    reversePolishExpr = append(reversePolishExpr, newVariable("speed"))
    reversePolishExpr = append(reversePolishExpr, newLiteral(50))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("<"))
    reversePolishExpr = append(reversePolishExpr, newVariable("temperature"))
    reversePolishExpr = append(reversePolishExpr, newLiteral(1))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("+"))
    reversePolishExpr = append(reversePolishExpr, newLiteral(4))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("<"))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("and"))
    reversePolishExpr = append(reversePolishExpr, newVariable("salinity"))
    reversePolishExpr = append(reversePolishExpr, newUnaryOperator("roundDown"))
    reversePolishExpr = append(reversePolishExpr, newLiteral(600.0))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("<="))
    reversePolishExpr = append(reversePolishExpr, newVariable("ph"))
    reversePolishExpr = append(reversePolishExpr, newUnaryOperator("roundUp"))
    reversePolishExpr = append(reversePolishExpr, newLiteral(8.0))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator(">"))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("or"))
    reversePolishExpr = append(reversePolishExpr, newBinaryOperator("or"))

    tree := NewFrom(reversePolishExpr)
    Dump(tree, "preorder")

    // test table
    var cases = []struct {
        id       string
        m        map[string]interface{}
        expected bool
    }{
        //($speed < 50) and (($temperature + 1) < 4) or ((roundDown($salinity) <= 600.0) or (roundUp($ph) > 8.0))
        {
            id: "0001",
            m: map[string]interface{}{
                "speed":       30,
                "temperature": 6,
                "salinity":    700.0,
                "ph":          7.0,
            },
            expected: false,
        },
        {
            id: "0002",
            m: map[string]interface{}{
                "speed":       30,
                "temperature": 1,
                "salinity":    500.0,
                "ph":          7.0,
            },
            expected: true,
        },
        {
            id: "0003",
            m: map[string]interface{}{
                "speed":       60,
                "temperature": 10,
                "salinity":    700.0,
                "ph":          9.0,
            },
            expected: true,
        },
        {
            id: "0004",
            m: map[string]interface{}{
                "speed":       30,
                "temperature": 1,
                "salinity":    700.0,
                "ph":          9.0,
            },
            expected: true,
        },
    }

    for _, caze := range cases {
        r, err := Evaluate(tree, caze.m)
        if err != nil {
            t.Errorf("[case %s]: want nil, actual %s", caze.id, err.Error())
        }
        if r != caze.expected {
            t.Errorf("[case %s]: want %v, actual %v", caze.id, caze.expected, r)
        }
    }
}

上面是语义模型中最复杂的部分,但不是全部,还有windowRange、enumableFunc以及result,下面我们就来建立tdat的完整的语义模型。

四. 建立完整的语义模型

前面我们已经解决掉了语义模型中最复杂的部分:conditionExpr。下面我们就把完整的语义模型实现出来,我们定义一个Model结构体来表示语义模型:

// tdat/semantic/semantic.go

type WindowsRange struct {
    low  int
    high int
}

type Model struct {
    // conditionExpr
    t Tree

    // windowsRange
    wr WindowsRange

    // enumerableFunc
    ef string

    // result
    result []string
}

我们看到Model本质上就是conditionExpr、WindowsRange、enumerableFunc和result这几个影响执行结果的元素的聚合,因此Model的创建函数也比较简单:

func NewModel(reversePolishExpr []Value, wr WindowsRange, ef string, result []string) *Model {
    m := &Model{
        t:      NewFrom(reversePolishExpr),
        wr:     wr,
        ef:     ef,
        result: result,
    }
    return m
}

我们重点看一下Model的语义执行方法Exec:

// tdat/semantic/semantic.go

func (m *Model) Exec(metrics []map[string]interface{}) (map[string]interface{}, error) {
    var res []bool
    for i := m.wr.low - 1; i <= m.wr.high-1; i++ {
        r, err := Evaluate(m.t, metrics[i])
        if err != nil {
            return nil, err
        }
        res = append(res, r)
    }

    andRes := res[0]
    orRes := res[0]

    for i := 1; i < len(res); i++ {
        andRes = andRes && res[i]
        orRes = orRes || res[i]
    }

    switch m.ef {
    case "any":
        if orRes {
            return m.outputResult(metrics[0])
        }
        return nil, ErrNotMeetAny
    case "none":
        if andRes == false {
            return m.outputResult(metrics[0])
        }
        return nil, ErrNotMeetNone
    case "each":
        if andRes == true {
            return m.outputResult(metrics[0])
        }
        return nil, ErrNotMeetEach
    default:
        return nil, ErrNotSupportFunc
    }
}

这里的实现并非“性能最优”,但逻辑清晰:Exec会使用表达式树对迭代窗口(从low到high)中的每个元素进行求值,求值结果放入一个切片,然后再针对这个切片,求所有元素的逻辑与(andRes)与逻辑或(orRes),再结合enumerableFunc的类型综合判断出是否要输出最新的那条metric。

关于Model的验证与表达式树差不多,限于篇幅这里就不赘述了,大家可以参考semantic_test.go中的测试case demo。

五. 小结

在这一部分内容中,我们为DSL建立了语义模型,tdat语义模型的核心是表达式树,因此我们重点讲了基于逆波兰式创建表达式树的方法、表达式树的求值方法以及表达式树的验证。最后,我们建立了一个名为semantic.Model的完整模型。

在下一篇文章中,我们将讲解如何基于DSL的语法树提取逆波兰式,并组装语义模型,把DSL的前后端串起来,让我们的语法示例可以真正run起来。

本文中涉及的代码可以在这里下载 – https://github.com/bigwhite/experiments/tree/master/antlr/tdat 。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.18新特性前瞻:原生支持Fuzzing测试

本文永久链接 – https://tonybai.com/2021/12/01/first-class-fuzzing-in-go-1-18

今年6月初,Go官博发表了一篇名为《Fuzzing is Beta Ready》的文章,文中称gotip版本已经原生支持Fuzzing并开始了公测。这意味着Fuzzing将以一等公民(first-class citizen)的身份正式加入到即将于2022年2月发布的Go 1.18版本中:


图:关于add fuzz test的issue已经关闭并放入Go1.18里程碑

有了对Fuzzing技术的原生支持后,我相信会有更多代码经过Fuzzing测试,未来不久Go社区的Go代码的安全水平将会得到整体提升。本文我们就来简单聊聊Fuzzing这个Go 1.18版本的新特性。

注意:在Go 1.18版本Beta版发布前要想体验Fuzzing特性,需要自行安装gotip版本,安装方法如下:

$go install golang.org/dl/gotip@latest // go 1.17版本及以后使用go install。go 1.16及之前的版本用go get
$gotip download
$gotip version // 验证安装是否ok

为什么Go要支持Fuzzing

无论是在过去的单机时代,还是在今天的云计算时代,亦或是已经出现苗头的人工智能时代,安全都是程序员在构建软件过程中必不可少且日益重要的考量因素。

同时,安全也是Go语言设计者们在语言设计伊始就为Go设定的一个重要目标。在语言层面,Go提供了很多“安全保障”特性,比如:

  • 显式类型转换,不允许隐式转换;
  • 针对数组、切片的下标越界访问的检查;
  • 不安全代码隔离到unsafe包中,并提供安全使用unsafe包的几条rules;
  • go module构建模式内置包hash校验,放置恶意包对程序的攻击;
  • 雇佣安全专家,提供高质量且及时更新的crypto包,尽量防止使用第三方加解密包带来的不安全性;
  • 支持纯静态编译,避免动态连接到恶意动态库;
  • 原生提供方便测试的工具链,并支持测试覆盖率统计。
  • … …

进入云原生时代后,Go语言成为了云原生基础设施与云原生服务的头部语言,由Go语言建造的基础设施、中间件以及应用服务支撑着这个世界的很多重要系统的运行,这些系统对安全性的要求不言而喻。尤其是在“输入”方面,这些系统都会被要求:无论用户使用什么本文数据、二进制数据,无论用户如何构造协议包、无论用户提供的文件包含何种内容,系统都应该是安全健壮的,不会因为用户的故意攻击而出现处理异常、被操控,甚至崩溃。

这就需要我们的系统面对任何输入的情况下都能正确处理,但传统的代码review、静态分析、人工测试和自动化的单元测试无法穷尽所有输入组合,尤其是难于模拟一些无效的、意料之外的、随机的、边缘的输入数据。

于是,Go社区的一些安全方面的专家就尝试将业界在解决这方面问题的优秀实践引入Go,Fuzzing技术就是其中最重要的一个

什么是Fuzzing?

说了这么半天,啥是Fuzzing

Fuzzing,又叫fuzz testing,中文叫做模糊测试或随机测试。其本质上是一种自动化测试技术,更具体一点,它是一种基于随机输入的自动化测试技术,常被用于发现处理用户输入的代码中存在的bug和问题。

在具体实现上,Fuzzing不需要像单元测试那样使用预先定义好的数据集作为程序输入,而是会通过数据构造引擎自行构造或基于开发人员提供的初始数据构造一些随机数据,并作为输入提供给我们的程序,然后监测程序是否出现panic、断言失败、无限循环等。这些构造出来的随机数据被称为语料(corpus)。另外Fuzz testing不是一次性执行的测试,如果不限制执行次数和执行时间,Fuzz testing会一直执行下去,因此它也是一种持续测试的技术。

Fuzzing技术形态最初的出现可追溯到以打孔卡承载的数据作为计算机输入的时代。那个时候开发人员经常从废纸篓里随便拿出几张打孔卡输入到自己的程序中来验证程序是否可以正确处理这些“随机”的输入。但Fuzzing测试作为一门技术理论走进广大开发者视野是始于1988年的Barton Miller教授的研究成果,

当时任教于威斯康星大学的Barton Miller教授在高级操作系统研究生班(CS736)上的一个秋季项目中运用了随机测试技术,他通过fuzzing对一个UNIX工具进行测试,为该工具自动生成随机输入和命令行参数。该项目旨在通过快速连续执行大量的随机输入来测试UNIX命令行程序的可靠性,直到它们崩溃。当时Miller团队能够使他们所测试的实用程序中的25%至33%崩溃。然后,他们对每个崩溃的程序进行调试,以确定原因,并对每个检测到的故障进行分类。1990年,Miller团队对外发表了这一成果。自那以后,Fuzzing技术便确定了自己独立的研究分支,并逐渐发展演化到今天。在过去的十多年中,Fuzzing测试的技术水平有了很大的提高,以AFL(american fuzzy lop)AFL++libFuzzergo-fuzzsyzkaller等开源项目为代表的Fuzzing项目已经被各种编程语言的开发人员应用于实践,并且取得了不错的“战绩”

Fuzzing是对其他形式的测试、代码审查和静态分析的补充,它通过生成一个有趣的输入语料库,而这些输入几乎不可能用手去想去写出来,因此极易被传统类型的测试所遗漏。Fuzzing可以帮助开发人员发现难以发现的稳定性、逻辑性甚至是安全性方面的错误,特别是当被测系统变得更加复杂时。

更为关键的,也是Fuzzing技术能够流行开来的原因是构建一个Fuzzing测试足够简单。有了上述Fuzzing相关开源工具和开源库的支持,Fuzzing test不再是需要专业知识才能成功使用的技术,并且现代Fuzzing引擎可以更有策略的、更快的、更有效地找到有用的输入语料。

Go对Fuzzing技术支持的简要回顾

说过将Fuzzing技术引入Go,我们不能不提到一个人,它就是Go goroutine调度器的作者、前Intel Black Belt级工程师,现Google工程师的Dmitry Vyukov,它也是Go语言首个fuzzing工具go-fuzz的作者。

2015年的GopherCon大会上,Dmitry Vyukov在其名为“[Go Dynamic Tools]”的presentation中就介绍了go-fuzz。我个人的gocmpp项目就是使用go-fuzz搭建的Fuzz test

之后,Dmitry Vyukov发现虽然通过第三方的fuzzing工具可以解决Go开发者关于Fuzzing的部分需求,但有很多功能特性是通过第三方工具无法实现的。2016年,Dmitry Vyukov在Go官方issue列表中创建“cmd/compile: coverage instrumentation for fuzzing”的issue归纳说明了这些问题,也是从那时开始,Dmitry Vyukov极力推进Fuzzing进入Go原生工具链的。

2017年,Dmitry Vyukov首次提出希望在Go工具链中原生支持Fuzzing的Proposal,并给出了为什么我们需要在Go工具链的支持下使Fuzzing成为Go开发的标准做法的原因

之后,Dmitry还开源了一个名为syzkaller的项目,该项目用Go语言实现了一个针对操作系统内核的Fuzzing引擎。

Dmitry虽然是goroutine调度器的开发者,也是Google员工,但他却不是Go语言团队的一员,也许正是因为这样,又或是Go核心团队对新特性保持的一贯的谨慎态度,该Dmitry的提议一直处理讨论与反馈的状态,直到2020年中旬,Go安全团队的Katie Hockman才正式发布了在Go中原生支持Fuzzing的新提案

新提案与Dmitry的提案的目标是相同的,都是期望在Go工具链中加入对Fuzzing的原生支持。不同的是,新提案中的API稍微复杂一些,新提案允许以编程方式设置初始语料库的种子语料,并支持字节字符串以外的输入类型,包括原生的基本数据类型(整型、浮点、字符串等)、复合数据类型(数组、map、结构体等)以及实现了BinaryMarshaler/BinaryUnmarshaler或TextMarshaler/TextUnmarshaler接口的自定义类型。

不过Go fuzzing没有如预期加入到Go 1.17版本中,再继续打磨了半年后,Go 1.18版本正式接受了原生支持Fuzzing这个特性,Fuzzing成为Go的“一等公民”。

如何使用成为Go“一等公民”的Fuzzing

作为普通Go开发人员,我们无需关心Fuzzing引擎是如何实现的,我们只需根据Go提供的Fuzzing API使用就好了。前面也提到过了,Fuzzing技术之所以可以流行到现在,更多也是因为其使用起来十分简单。

Go 1.18将fuzz testing纳入了go test工具链,与单元测试、性能基准测试等一起成为了Go原生测试工具链中的重要成员。

go fuzzing test的测试用例与普通的测试用例(TestXxx)、性能基准测试(BenchmarkXxx)等一样放在xx_test.go中,只不过用例对应的函数名样式换为了FuzzXxx了。一个简单的Fuzzing test用例如下:

func FuzzXxx(f *testing.F) {
    // 设置种子语料(可选)

    // 执行Fuzzing
    f.Fuzz(func(t *testing.T, b []byte) {
        //... ...
    })
}

我们通过go test -fuzz命令即可执行所有xx_test.go中以Fuzz为前缀的Fuzz testing用例。不过这里要注意的是go test -fuzz会先进行普通TestXxx的用例执行,之后才会执行FuzzXxx。

我们看到:每个FuzzXxx函数的参数列表是固定的,fuzzing在testing包中新增了一个F结构体类型,其与testing.T、testing.B是类似的,用于表示一次Fuzzing test的执行,结构体变量中存储了此次fuzzing test执行的上下文信息。

FuzzXxx函数的最主要只能就是调用testing.F的Fuzz方法对目标函数/方法执行测试。testing.F的Fuzz方法接受一个函数类型的参数,按照fuzzing提案的说明,该函数的第一个参数必须是*testing.T,后面可以是多个输入参数,且输入参数的类型不局限于传统的byte切片,还可以是上面提到过的原生的基本数据类型(整型、浮点、字符串等)、复合数据类型(数组、map、结构体等)以及实现了BinaryMarshaler/BinaryUnmarshaler或TextMarshaler/TextUnmarshaler接口的自定义类型。

Fuzz方法会根据目标所需的输入参数类型生成fuzzing后的数据,并将这些数据作为输入参数传给其参数代表的函数。

Go开发人员也可以通过testing.F的Add方法为fuzzing过程提供初始的种子语料(seed corpus),后续fuzzing test会基于这些种子语料进行fuzzing,虽然这不是必须的,但提供与目标处理逻辑相关的种子语料,可能会加速被测目标中问题的暴露。

当然我们也可以不通过testing.F的Add方法来提供种子语料,go fuzzing还允许你通过文件的形式为每个FuzzXxx函数提供种子语料,以FuzzXxx为例,我们可以在testdata/fuzz/FuzzXxx目录下以文件的形式放置其初始语料,比如:

// testdata/fuzz/FuzzXxx/corpus1
go test fuzz v1
[]byte("ABC\xa8\x8c\xb3G\xfc")

在这个种子语料文件中,第一行go test fuzz v1是go fuzzing要求的文件头,用于标识这是一个种子语料文件,并且使用的编解码器的版本为v1。而下面的一行则是种子语料,其实这行就是一个go代码的片段,fuzzing工具会将其解码后直接作为输入赋值给被测目标。后续的fuzzing过程也是基于这个种子语料的。注意:种子语料可以有很多个,不同语料单独放置在一行中即可。目前,这个种子语料文件需要手工编辑,后续go团队可能会提供相关工具以方便对种子语料文件的编辑,尤其是针对一些二进制数据的种子语料。

下面我们用一个例子来看看如何使用go原生fuzzing。我这里还以我的gocmpp项目为例,对项目中的Submit消息的Unpack方法进行fuzz testing。

我们先来看不提供初始种子语料的情况。

不提供初始种子语料

虽说FuzzXxx测试用例可以与普通用例TestXxx放在一个xxx_test.go文件中,但例子中为了着重强调我们是在写Fuzz testing用例,我们将FuzzXxxx函数放在submit_fuzz_test.go中,下面是不显式提供初始种子语料的FuzzSubmit:

// submit_fuzz_test.go

//go:build go1.18
// +build go1.18

package cmpp_test

import (
    "testing"

    cmpp "github.com/bigwhite/gocmpp"
)

func FuzzSubmit(f *testing.F) {
    f.Fuzz(func(t *testing.T, data []byte) {
        p := &cmpp.Cmpp2SubmitReqPkt{}
        _ = p.Unpack(data)
    })
}

我们看到,为了兼容go 1.18之前的版本,我们使用build指示符来告诉编译器这个文件只在go 1.18及后续版本才参与编译,这样go 1.17及之前的版本会ignore这个源文件。

使用下面命令我们来运行一下这个fuzz test:

$gotip test -v -fuzz  .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
=== FUZZ  FuzzSubmit
fuzz: elapsed: 0s, gathering baseline coverage: 0/38 completed
fuzz: elapsed: 0s, gathering baseline coverage: 38/38 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 403378 (134408/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 6s, execs: 800451 (132348/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 9s, execs: 1104435 (101366/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 12s, execs: 1346809 (80789/sec), new interesting: 0 (total: 38)
fuzz: elapsed: 15s, execs: 1718297 (123747/sec), new interesting: 1 (total: 39)
^Cfuzz: elapsed: 16s, execs: 1771361 (92170/sec), new interesting: 1 (total: 39)
--- PASS: FuzzSubmit (15.59s)
PASS
ok      github.com/bigwhite/gocmpp  15.607s

通过上面的执行我们得到几点信息;

  • gotip test -fuzz会先进行普通TestXxx的用例执行,之后才会执行FuzzXxx。

  • fuzz testing默认会一直执行下去,直到遇到crash。如果要限制fuzz testing的执行时间,可以使用-fuzztime,比如下面的命令允许fuzz testing只执行10s:

$gotip test -v  -fuzztime 10s -fuzz .
  • 覆盖率引导的fuzzing

我们看到:测试输出内容中包含“gathering baseline coverage字样”,这里要告诉大家的是,go fuzzing使用的是一种名为“覆盖率引导的fuzzing(coverage-guided fuzzing)”。我们知道Fuzzing测试使用的是随机生成的随机数据对被测目标进行测试,如果仅仅是用凭空随机的方式生成的输入很难有效找到边缘情况,当今大多数现代的fuzzing工具都是用了coverage-guided fuzzing的引擎来驱动测试,它可以确定新生成的语料是否能覆盖到新的代码路径。Dmitry在“Fuzzing support for Go”一文中曾经对coverage-guided fuzzing的引擎的工作逻辑做过如下描述:

从一些(可能是空的)输入的语料库开始
for {
    从语料库中随机选择一个输入
    对输入进行变异(mutate)
    执行变异后的输入并收集代码覆盖率
    如果该输入给出了新的覆盖率,则将其添加到语料库中
}

收集代码覆盖率数据和检测一个输入”给出新的覆盖率”并非易事,这也是为什么很多第三方fuzzing工具难于实现的原因,而加入到go原生工具链中,这些特性可借助Go编译器以及已有的设施来完成。

  • 缓存新加入的语料

在上面go test -fuzz执行过程中,新生成的可以覆盖新代码路径的语料放置在哪里了呢?Go fuzzing会将其缓存在cache路径下,我在本机的gocache路径下发现如下与fuzz有关的内容:

//GOCACHE="/Users/tonybai/Library/Caches/go-build"

$ls /Users/tonybai/Library/Caches/go-build/fuzz/github.com/bigwhite/gocmpp/FuzzSubmit
01e40385855b3d317d42bf7ba4a9118702d867492fe2cd52bc84e554769480e5
06ba4bdb19de593e669c642987e270fe2488d4d58ecd712db136a3e011071253
086eabebec22d361087ce571571d86b1cbe1ad3e713f981473275f2c8fa64f09
... ...

go fuzzing会为每个FuzzXxx函数建立对应的语料缓存。目前fuzz cache的默认路径为$GOCACHE/fuzz/包路径/FuzzXxx,后续可能会提供环境变量或cmd option,以允许开发人员自定义fuzzing语料的缓存路径。

前面我们说过,fuzzing test默认会一直执行下去,如果不限制执行次数和执行时间,执行Fuzzing test的机器要有足够的存储才行。而要想清理过多的fuzz缓存,用gotip clean -cache是不行的,需要为clean加上-fuzzcache才可以清除fuzz的cache。

使用Add方法提供种子语料

下面是通过testing.F的Add方法为fuzzing test提供种子语料的例子:

//go:build go1.18
// +build go1.18

package cmpp_test

import (
    "testing"

    cmpp "github.com/bigwhite/gocmpp"
)

func FuzzSubmit(f *testing.F) {
    data := []byte{
        0x00, 0x00, 0x00, 0xbd, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x17, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x74, 0x65, 0x73, 0x74, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x02, 0x31, 0x33, 0x35, 0x30, 0x30, 0x30, 0x30, 0x32, 0x36, 0x39, 0x36, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x39, 0x30, 0x30, 0x30, 0x30,
        0x31, 0x30, 0x32, 0x31, 0x30, 0x00, 0x00, 0x00, 0x00, 0x31, 0x35, 0x31, 0x31, 0x30, 0x35, 0x31,
        0x33, 0x31, 0x35, 0x35, 0x35, 0x31, 0x30, 0x31, 0x2b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x39, 0x30, 0x30, 0x30, 0x30,
        0x31, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x01, 0x31, 0x33, 0x35, 0x30, 0x30, 0x30, 0x30, 0x32, 0x36, 0x39, 0x36, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1e, 0x6d, 0x4b, 0x8b, 0xd5, 0x00, 0x67, 0x00, 0x6f, 0x00,
        0x63, 0x00, 0x6d, 0x00, 0x70, 0x00, 0x70, 0x00, 0x20, 0x00, 0x73, 0x00, 0x75, 0x00, 0x62, 0x00,
        0x6d, 0x00, 0x69, 0x00, 0x74, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    }
    f.Add(data[8:])
    f.Fuzz(func(t *testing.T, data []byte) {
        p := &cmpp.Cmpp2SubmitReqPkt{}
        _ = p.Unpack(data)
    })
}

在上面代码中,我们使用了一个正确的cmpp2 submit消息包的数据作为种子语料,后续fuzzing会基于该语料做mutate,生成其他语料对Submit的Unpack方法进行测试。执行该fuzz test的输出与不设置种子语料的输出差别不大:

$gotip test -fuzz .
fuzz: elapsed: 0s, gathering baseline coverage: 0/1 completed
fuzz: elapsed: 0s, gathering baseline coverage: 1/1 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 395490 (131760/sec), new interesting: 20 (total: 20)
fuzz: elapsed: 6s, execs: 795164 (133251/sec), new interesting: 22 (total: 22)
fuzz: elapsed: 9s, execs: 1106761 (103875/sec), new interesting: 22 (total: 22)
^Cfuzz: elapsed: 11s, execs: 1281577 (92654/sec), new interesting: 22 (total: 22)
PASS
ok      github.com/bigwhite/gocmpp  10.917s

使用testdata/fuzz/FuzzXxx目录提供种子语料

除了通过Add方法添加种子语料外,我们还可以在项目的testdata/fuzz/FuzzXxx目录下为FuzzXxx用例提供种子语料:

$tree testdata
testdata
└── fuzz
    └── FuzzSubmit
        └── corpus1

$cat testdata/fuzz/FuzzSubmit/corpus1
go test fuzz v1
[]byte("ABC\xa8\x8c\xb3G\xfc")

我们把FuzzSubmit代码恢复为不带有Add的形式:

func FuzzSubmit(f *testing.F) {
    f.Fuzz(func(t *testing.T, data []byte) {
        p := &cmpp.Cmpp2SubmitReqPkt{}
        _ = p.Unpack(data)
    })
}

执行这一用例,输出入下结果:

$gotip test -fuzz .
fuzz: elapsed: 0s, gathering baseline coverage: 0/23 completed
fuzz: elapsed: 0s, gathering baseline coverage: 23/23 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 355689 (118485/sec), new interesting: 3 (total: 25)
fuzz: elapsed: 6s, execs: 623934 (89390/sec), new interesting: 5 (total: 27)
fuzz: elapsed: 9s, execs: 756400 (44154/sec), new interesting: 5 (total: 27)
^Cfuzz: elapsed: 10s, execs: 771910 (28387/sec), new interesting: 5 (total: 27)
PASS
ok      github.com/bigwhite/gocmpp  9.564s

模拟crash

Fuzzing技术作为其他测试的一种补充,可以用于发现代码中潜在的不易被发现的问题,但这一过程有时候也是很漫长的。因此在这里我们模拟一个crash的产生来看看:当fuzzing test过程中发现代码bug时,fuzzing都做了那些事情。

我们在被测方法Unpack中故意放置了一个panic语句:

// submit.go
func (p *Cmpp2SubmitReqPkt) Unpack(data []byte) error {
    ... ...
    panic("panic for fuzz demo")
    ... ...
}

这样,当fuzzing test执行到这里时Unpack方法就会panic,而fuzzing会生成crash报告并终止fuzz testing执行。

但要注意的是:go test -fuzz是先运行TestXxx,然后再运行FuzzXxx的,如果在TestXxx中发生了panic,那么go fuzzing是不会生成crash报告的。另外还有一点要格外注意:go fuzzing将种子语料作为输入时出现的panic也是不会生成crash报告的,因为,此时对数据的fuzzing还没有真正开始。因此,这里我们使用上面那个不带有种子语料的FuzzSubmit。

好了,我们执行一下fuzzing test:

$gotip test -fuzz .
fuzz: elapsed: 0s, gathering baseline coverage: 0/27 completed
fuzz: minimizing 148-byte crash file
fuzz: elapsed: 0s, gathering baseline coverage: 0/27 completed
--- FAIL: FuzzSubmit (0.03s)
    --- FAIL: FuzzSubmit (0.00s)
        testing.go:1319: panic: panic for fuzz demo
            goroutine 49 [running]:
            runtime/debug.Stack()
                /Users/tonybai/sdk/gotip/src/runtime/debug/stack.go:24 +0x90
            testing.tRunner.func1()
                /Users/tonybai/sdk/gotip/src/testing/testing.go:1319 +0x1f2
            panic({0x11ca860, 0x1241148})
                /Users/tonybai/sdk/gotip/src/runtime/panic.go:838 +0x207
            github.com/bigwhite/gocmpp.(*Cmpp2SubmitReqPkt).Unpack(0xc00025a5a0, {0xc000024400, 0x1, 0x80})
                /Users/tonybai/Go/src/github.com/bigwhite/gocmpp/submit.go:262 +0x625
            github.com/bigwhite/gocmpp_test.FuzzSubmit.func1(0x0?, {0xc000024400, 0x1, 0x80})
                /Users/tonybai/Go/src/github.com/bigwhite/gocmpp/submit_fuzz_test.go:32 +0x45
            reflect.Value.call({0x11ccf40?, 0x12111c8?, 0x13?}, {0x1200df5, 0x4}, {0xc000217080, 0x2, 0x2?})
                /Users/tonybai/sdk/gotip/src/reflect/value.go:543 +0x814
            reflect.Value.Call({0x11ccf40?, 0x12111c8?, 0x10f9980?}, {0xc000217080, 0x2, 0x2})
                /Users/tonybai/sdk/gotip/src/reflect/value.go:339 +0xbf
            testing.(*F).Fuzz.func1.1(0x0?)
                /Users/tonybai/sdk/gotip/src/testing/fuzz.go:327 +0x20b
            testing.tRunner(0xc000201860, 0xc0003a0900)
                /Users/tonybai/sdk/gotip/src/testing/testing.go:1409 +0x102
            created by testing.(*F).Fuzz.func1
                /Users/tonybai/sdk/gotip/src/testing/fuzz.go:316 +0x5b8

    Crash written to testdata/fuzz/FuzzSubmit/582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4
    To re-run:
    go test github.com/bigwhite/gocmpp -run=FuzzSubmit/582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4
FAIL
exit status 1
FAIL    github.com/bigwhite/gocmpp  0.037s

我们看到go fuzzing在执行第一个测试时就发生了crash,fuzzing将crash输出了crash报告,并将引发这一crash的语料放入了testdata/fuzz/FuzzSubmit目录下:

$tree testdata
testdata
└── fuzz
    └── FuzzSubmit
        └── 582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4

查看一下引发crash的语料:

$cat testdata/fuzz/FuzzSubmit/582528ddfad69eb57775199a43e0f9fd5c94bba343ce7bb6724d4ebafe311ed4
go test fuzz v1
[]byte("0")

如果是真实的fuzz测试引发了crash,我们可以将该语料提取出来,建立针对它的TestXxx或为现有TestXxx添加一条测试数据来验证目标方法是否真实存在缺陷,如果的确存在缺陷,我们就需要修复它,并在修复后再次运行TestXxx,以保证我们的修复是有效的。

小结

在即将到来的Go 1.18中,Go fuzzing将正式成为Go的“一等公民”,Go将原生支持Fuzzing。不过Go fuzzing刚刚加入,可能还存在各种问题,根据以往经验,在2-3个版本后,go fuzzing必将成熟稳定起来,到那时,Gopher们就又拥有了一柄挖掘潜在bug和安全问题的利器了。

参考资料


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强,欢迎大家加入!

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats