三类人员 网站开发,做网站有必要用wordpress,深圳装修公司排名前十口碑,宿州保洁公司有哪些一、前言
本文作者提出了一种评价单元测试用例的质量的思路#xff0c;即判断用例是否达到测试的“四大目标”。掌握识别好的用例的能力#xff0c;可以帮助我们高效地写出高质量的测试用例。
评判冰箱的好坏#xff0c;并不需要有制造一台冰箱的能力。在开始写测试用例之…一、前言
本文作者提出了一种评价单元测试用例的质量的思路即判断用例是否达到测试的“四大目标”。掌握识别好的用例的能力可以帮助我们高效地写出高质量的测试用例。
评判冰箱的好坏并不需要有制造一台冰箱的能力。在开始写测试用例之前可以先掌握识别好的用例的能力这样可以避免我们自己花费大量的时间写出低质量的用例。要评价用例的质量好坏就看测试是否达到我们期望的目标。
二、测试的第一目标是“尽可能地”排除缺陷
当我们给系统增加功能时首先要保证增加的功能没有缺陷同时还要防止回归。“回归”(regression) 意指系统在增加了一些功能后一些旧的功能出现缺陷。测试用例是否最大范围地去挖掘了系统的缺陷最广为认知的手段就是计算测试覆盖率。但是关于覆盖率有一些认知需要澄清。 覆盖率高是不够的 测试覆盖率低就是系统的代码只有很少一部分被测试过了那些未测试的部分是好是坏不知道。但是测试覆盖率高却并不意味着测试质量高简单的例子就是无断言的测试用例覆盖率可以很高但是它跟没有测试几乎是一样的。不过还有更违反直觉的事实可以看一下一个简单的例子 listing 1
func IsStringLong(s string) bool {if len(s) 5 {return true}return false}func TestIsStringLong(t *testing.T) {got : IsStringLong(abc)assert.Equal(t, false, got)}被测代码一共 6 行测试覆盖到了 125 行覆盖率 50%. 然后我们测试代码不变被测代码简化一下 listing 2
func IsStringLong(s string) bool {return len(s) 5 }马上覆盖率就达到了 100%. 很显然这个 100% 的覆盖率并不充分它都没有测试 s 5 的情况。了解测试的同学马上会想到上面覆盖率的概念其实是覆盖率的一种叫行覆盖率(其实英文的 statement coverage 会更加确切)。另外一种覆盖率叫做分支覆盖率IsStringLong 有 2 个逻辑分支我们的测试代码只覆盖了其中一个为了充分测试我们要提供分支的覆盖率。 listing3
func TestIsStringLong(t *testing.T) {type args struct {s string}tests : []struct {name stringargs argswant bool}{{name: abcde results short,args: args{s: abcde,},want: false,},{name: abcdef results long,args: args{s: abcdef,},want: true,},}for _, tt : range tests {t.Run(tt.name, func(t *testing.T) {if got : IsStringLong(tt.args.s); got ! tt.want {t.Errorf(IsStringLong() %v, want %v, got, tt.want)}})}
}撒花我们测试了所有分支但是全部的分支覆盖率也存在问题我们来看另一个例子:
listing 4
type Recorder struct {Value string
}var recorder Recorder{}func IsStrLong(s string) bool {recorder.Value sreturn len(s) 5
}func TestIsStrLong(t *testing.T) {type args struct {s string}tests : []struct {name stringargs argswant bool}{{name: abcde results short,args: args{s: abcde,},want: false,},{name: abcdef results long,args: args{s: abcdef,},want: true,},}for _, tt : range tests {t.Run(tt.name, func(t *testing.T) {if got : IsStrLong(tt.args.s); got ! tt.want {t.Errorf(IsStrLong() %v, want %v, got, tt.want)}})}
}被测函数增加了一项功能记录最后一次调用的参数。测试代码不变同样还是 100% 的行覆盖和 100% 的分支覆盖但是 “recoreder 里是否有正确记录最后一次参数” 却无法得到保障。假设这段代码提交以后下个迭代某个开发失手删除了
recorder.Value s这一行测试流水线依然通过甚至因为全覆盖还会给你发个点赞的信息。但是项目上线后却可能因为这段记录丢了引发功能故障。解决上面的问题就是在断言阶段增加对 recorder.Value 的断言: listing 5
for _, tt : range tests {t.Run(tt.name, func(t *testing.T) {if got : IsStrLong(tt.args.s); got ! tt.want {t.Errorf(IsStrLong() %v, want %v, got, tt.want)}if recorder.Value ! tt.args.s {t.Errorf(IsStrLong() called but recorder.Value %v, want %v, recorder.Value, tt.args.s)}})变异测试可以辅助评价断言质量但是性能开销巨大 接着上面的例子listing 4 中我们看到一类断言不足但是覆盖率 100% 的用例这种情况我们可以用变异测试来检测。其大致原理是流水线在启动后随机修改被测代码而测试代码不变然后运行测试若用例依然能通过则预示着测试用例可能质量不高。以 listing 4 为例变异测试引擎生成的一个版本是删除了
recorder.Value s这一行代码对变异版本运行用例会发现用例通过则该用例的变异得分会低。而相同的变异版本 listing 5 中的用例会失败。
变异测试会对被测代码的语法树作各种变异要对每个变异版本进行测试其工作量是巨大的耗时可想而知。因此对整个代码库进行变异测试通常不适合放在对耗时要求较高的 CR 流水线上。可行的方法有:
-1.在定时流水线上对被测系统全量运行被测系统比较大时可以分模块进行。
-2.如果被测系统组织良好CR 流水线进准测试(分片测试)能力足够高则可以在 CR 流水线上对改动部分作变异测试。
实践建议 1.每次 CR 统计覆盖率特别是增量覆盖率, 覆盖率过低时阻挡合入。[1] 2.CR 的 reviewer 需注意断言是否充分合理相对变异测试负责任的高水平的 reviewer 效率更高。因此 CR 单的 change list 应该尽可能小这样 CR 通过才能尽可能快。 3.引入定时流水线分模块对代码库进行变异测试。这需要根据实际性能调整策略。
代码覆盖率高是不够的终极的覆盖
以 tRPC-Go 数据校验为例。tRPC-Go 有配套的数据校验工具其原理简单说就是在 proto 文件中增加 Message 各字段的校验规则在 tRPC 服务中引入校验拦截器在运行时拦截器会针对入参进行校验。 step 1 在 proto 中增加校验规则 // QueryCaseRecentExecsRequest 包含用例 id, 用来查询其最近 n 次执行记录, 最多查询最近 100 次记录。
message QueryCaseRecentExecsRequest {sint64 case_id 1;uint32 count 2[(validate.rules).uint32.lte 100];
}step 2 在服务的 trpc_go.yaml 中配置使用拦截器 server:filter:- validation
}step 3 在服务的 main.go 中注册拦截器 import (// ..._ git.code.oa.com/trpc-go/trpc-filter/validation
)func main() {// ...
}在服务的方法中就不需要再做这类校验了 func (s *XXXService) QueryCaseRecentExecs(ctx context.Context, req *proto.QueryCaseRecentExecsRequest, rsp *proto.QueryCaseRecentExecsReply) error {// 不再需要//if req.Count 100 {// return errors.New(count not allowed)//}result, err : s.CaseExecService.QueryRecentExecsByCaseID(ctx, req.CaseId, int(req.Count))if err ! nil {return err}rsp.CaseExecs pbconv.FromCaseExecs(result)return nil
}在这样的代码库中不管是 XXXService 还是 XXXService.CaseExecService (domain service) 都不需要对 count 进行拦截校验了。即使单测代码全覆盖我们也无法保证我们 step 1,2,3 都按照文档正确地配置了更进一步即使我们非常仔细地检查了配置也不能保证规则检查正确地生效了毕竟谁知道
git.code.oa.com/trpc-go/trpc-filter/validation有没有 bug这个问题的最终解决方案就是将服务部署起来向它发请求来确保参数校验确确实实生效了(接口测试或者端到端测试)。可能有的同学会有疑问“不要测试框架代码”这样的建议有错吗建议没错但那是针对单元测试的。但是我们的自己的产品在发布前不管是哪种原因产生的缺陷都应该尽量通过测试来排查出来框架不行就替换框架。产品出问题用户才不关心是开发者造成的还是框架造成的。请注意完整测试我们的系统并不是建议大家完整地测试我们用到的每一个框架每一个库而是测试我们系统的每个功能。[2]
三、测试的目标之二支撑重构
理想的测试用例应该只检验被测系统的输入输出(输出包含通常意义的返回值和一切副作用如上文提到的状态改变)而不应该关心系统到底是怎么实现这个功能的。这样当我们重构一段代码时我们只要针对修改后的功能代码运行原有的测试用例当用例通过时就证明我们的重构没有引入缺陷。如果你重构一段代码后发现原有的用例无法通过了但是我们自己对重构前后的功能一致非常有信心此时不得不“微调”一下用例来保证用例通过每当此时就应该意识到这些用例在支撑重构上做得不够好。功能不变的情况下通过改变实现而让测试用例失败的情况称之为误警(false alarm)或者叫假阳性(false positive). 熟悉 SRE 的同学对误警应该不会陌生。假阳性最好的类比就是医学上假阳性没病检验出病。事实上自动化测试跟医学检验非常相似医学检验的英文也叫 test有假阳性也有假阴性而且甚至都没有办法完全排除假阳性和假阴性的发生。
支撑重构做得不好的危害 1.就假阳性而言假阳性如果多了会麻痹大家对测试失败的认知导致团队成员忽略一些失败用例。这是也是 flakey test 的问题。 2.每次重构都要增加维护测试的开销这违背了自动化测试的初衷。内网上已经有开发在讨论做测试带来的“额外”负担该由谁承担之类的问题过大的负担会阻碍团队成员对自动化测试的接纳。当开发者把写用例当作一种不情愿的任务来完成时自动化测试的质量想必不会太好。 3.支撑重构做得不好往往意味着用例检验了功能以外的东西这其实在某种意义也是一种断言不当它反映了用例作者对测试的误解暗示着用例还可能有其他的问题。 支撑重构做得不好的重要信号是过度依赖 mock特别是那些在 mock 规则中还增加了调用顺序校验的。这也是为什么在各个场合中一些测试布道者偏爱基于输入输出的测试classical testing)而不是基于 mock 的测试(mockist testing)。但是有时候团队流水线对覆盖率有硬性质量红线使用 classical testing 无法达到那么高的覆盖率我们不得不做一些 mock 来通过质量红线。因此应该尽量避免设置过高的质量红线而应该培养团队成员的 testing sense, 程序员的价值就在这里。
先更新到这里下篇继续~ 优测测试平台简介 是一个为企业与开发者提供专业的测试工具和服务的平台沉淀十年产品测试经验提供终端测试、接口测试、性能测试、安全测试等多领域测试服务与产品协助客户提高效率降低成本保证产品质量。
