接口测试如何评估测试用例的有效性

Posted sysu_lluozh

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了接口测试如何评估测试用例的有效性相关的知识,希望对你有一定的参考价值。

一、定义

测试用例有两个比较关键的部分:

  1. 调用被测代码:例如RuleService.getLastRuleByClientId(ClientId)
  2. 进行结果Check:例如AssertEqual(OrderId,“ABCD1234”)

希望一组测试用例不仅能够“触发被测代码的各种分支”,还能够做好结果校验

  • 当业务代码出现问题的时候,测试用例可以发现这个问题,认为这一组测试用例是有效的
  • 当业务代码出现问题的时候,测试用例没能发现这个问题,认为这一组测试用例是无效的

对测试用例有效性的理论建模是:

测试有效性 = 被发现的问题数 / 出现问题的总数

二、目的

为什么要评估测试用例的有效性?

  • 这么多的CASE,花了大量时间和资源去运行,真能发现BUG吗?
  • CI做到90%的行覆盖率,能发现问题吗?
  • 测试用例越来越多,删一些会不会就发现不了问题了?
  • 怎么找出哪些为了覆盖而覆盖,发现不了真正问题的测试用例?

三、方法

测试用例有效性评估的方法?

基于故障复盘的模式成本太高,希望能够主动创造问题来评估测试用例的有效性

找到了一种衡量“测试有效性”的方法,变异测试(mutation testing)

变异测试的例子

用了一组测试用例(3个)去测试一个判断分支

为了证明这一组测试用例的有效性,向业务代码中注入**变异。**把b<100的条件改成了b<=10

可以认为:一组Success的测试用例,在其被测对象发生变化后(注入变异后),应该至少有一个失败。如果这组测试用例仍然全部Success,则这组测试用例的有效性不足

通过变异测试的方式:让注入变异后的业务代码作为“测试用例”,来测试“测试代码”

实现了多种规则,可以主动的注入下面这些变异

变异类型还有函数调用,比如:

  • 相似函数(getList 变 getWhiteList)
  • 多态函数(foo(xx, 0) 变 foo(xx))
  • 易错函数(parseBool 变 getBool)

四、如何评估

如何优雅的评估测试有效性?

为了全自动的进行测试有效性评估,做了一个变异机器人,其主要运作是:

  1. 往被测代码中写入一个BUG(即:变异)
  2. 执行测试
  3. 把测试结果和无变异时的测试结果做比对,判断是否有新的用例失败
  4. 重复1-3若干次,每次注入一个不同的Bug
  5. 统计该系统的“测试有效性”

变异机器人的优点:

  1. 防错上线
    变异是单独拉代码分支,且该代码分支永远不会上线,不影响生产

  2. 全自动
    只需要给出系统代码的git地址,即可进行评估,得到改进报告。

  3. 高效
    数小时即可完成一个系统的测试有效性评估。

  4. 扩展性
    该模式可以支持JAVA以及JAVA以外的多种语系。

  5. 适用性
    该方法不仅适用于单元测试,还适用于其他自动化测试,例如接口测试、功能测试、集成测试

变异机器人的使用门槛:

  1. 测试成功率
    只会选择通过率100%的测试用例,所对应的业务代码做变异注入

  2. 测试覆盖率
    只会注入被测试代码覆盖的业务代码,测试覆盖率越高,评估越准确

五、高配版变异机器人

高配版变异机器人拥有三大核心竞争力

分钟级的系统评估效率

为了保证评估的准确性,100个变异将会执行全量用例100遍,每次执行时间长是一大痛点

高配版变异机器人给出的解法:

  1. 并行注入
    基于代码覆盖率,识别UT之间的代码覆盖依赖关系,将独立的变异合并到一次自动化测试中
  2. 热部署
    基于字节码做更新,减少变异和部署的过程
  3. 精准测试
    基于UT代码覆盖信息,只运行和本次变异相关的UT(该方法不仅适用于UT,还适用于其他自动化测试,例如接口测试、功能测试、集成测试)

学习型注入经验库

为了避免“杀虫剂”效应,注入规则需要不断的完善
高配版变异机器人给出的解法:故障学习
基于故障学习算法,不断学习历史的代码BUG,并转化为注入经验

兼容不稳定环境

集成测试环境会存在一定的不稳定,难以判断用例失败是因为“发现变异”还是“环境出现问题”,导致测试有效性评估存在误差
高配版变异机器人给出的解法:

  1. 高频跑
    同样的变异跑10次,对多次结果进行统计分析,减少环境问题引起的偶发性问题
  2. 环境问题自动定位
    接入附属的日志服务,它会基于用例日志/系统错误日志构建的异常场景,自动学习“因环境问题导致的用例失败”,准确区分出用例是否发现变异

六、更多手段

更多的测试有效性度量手段

基于代码注入的测试有效性度量,只是其中的一种方法,我们日常会用到的方法有这么几种:

  • 代码注入:向代码注入变异,看测试用例是否能发现该问题
  • 内存注入:修改API接口的返回内容,看测试用例是否能发现该问题
  • 静态扫描:扫描测试代码里是否做了Assert等判断,看Assert场景与被测代码分支的关系

测试有效性可以作为基石,驱动很多事情向好发展:

  • 让测试用例变得更能发现问题
  • 让无效用例可被识别、清理
  • 创造一个让技术人员真正思考如何写好TestCase的质量文化
  • 测试左移与敏捷的前置条件

以上是关于接口测试如何评估测试用例的有效性的主要内容,如果未能解决你的问题,请参考以下文章

第二周学习总结

测试用例的理论知识

面试测试开发工程师:用例篇

如何编写接口测试用例?

软件测试——软件测试用例篇

编写测试用例常用的五种方法