程序可测性

什么是可测性?我的理解,可测性可以指代一个功能的测试切入点、验证点的多与寡,测试过程的简单与复杂。

测试切入点简单点说,就是能否更加全面地掌控数据的流转,举个例子,现有有一个类要测试,整个类

只给你暴露一个接口,你只能针对这一个接口给它输入验证它的输出,除此之外你无法获取更多信息,你不知道数据运算中间状态对不对、不知道过程有没有异常被错误捕捉、不知道数据有无完整落盘、不知道资源消耗是否不符预期……尤其是中间出现ABA的问题,是完全无法辨别的。这就是一个十分没有可测性的例子,是测试切入点太少,可验证性太差。

再举个例子,如果测试一个功能,你通过N步前置操作终于触发了这个功能,此时你还需要N步操作才能去验证这个功能是否正确,然而这个只是一个比较简单的功能,没有包含太多的复杂流程逻辑,那也是没有可测性,这是测试过程过于复杂,可操作性性低。

其实上面说的,都可以叫测试手段。不同的需求会导致不同的产品形态,不同的产品形态又会有不同的测试手段,测试手段的多与少就会影响可测性。

咱们改一下,对于一开始的那个类,如果它从只暴露单一接口改为提供多个debug接口,或者拆分功能让我们自己调用中间过程,或者提供了详细日志跟踪中间状态,可测性就有明显提高,这就是增加测试切入点;如果还是只暴露单一接口,有了自动化框架只需要简单添加配置文件就能自动灌数据验证结果,这就是降低测试过程复杂度。

这里列举一些增加可测性的方法:

  • 可验证性
    • 添加必要的日志
    • 因输入导致变更的点就是输出,输出全部可查看(正例:中间数据的落盘)
    • 提示信息可读,意义明确且唯一(反例:返回码意义不明确且多个不同错误用同一个返回码)
  • 可操作性
    • 简化测试准备和测试清理(正例:几个flag变量组合的条件判断,一键完成flag变量设置)
    • 测试过程有易用的配套工具
  • 可控制性
    • 所有影响输出的因素都可控(反例:多线程死锁,难以构造死锁现场;难以构造的内部错误)
    • 可直接控制中间状态的数据
  • 可分解性
    • 大系统中可以针对小模块独立测试
  • 可理解性
    • 文档明确且随时update
    • 提供修改背景和影响范围

QA拿到测试需求,在了解完需求背景和功能点后,最先要明白的就是可测性,尽量在case评审之前摆平可测性低的问题,这样测试过程才流畅。所以,反过来往往需要我们在case编写时就对被测对象有清晰的了解,才知道要怎么测它,而不是模模糊糊只有个概念,或者到了评审完case真正开始测试时发现不少case因为自己不了解细节而写得不到位(必须要抛弃觉得RD会指出case遗漏的侥幸心理)。

不测完我不吃饭

当然可测性还有更多的拓展意义,比如文档友好、接口清晰、模块解耦、数据可控blabla,甚至可以反过来指导RD编写具备可测性的代码,存在有效的中间过程记录,复杂流程适度拆分,让功能模块之间尽量做到职责单一,某种感觉上是软件工程在QA视角的映射

打赏
  • 版权声明: 本博客所有文章除特别声明外,著作权归作者所有。转载请注明出处!
  • Copyrights © 2017-2022 Zingphoy Han
  • 访问人数: | 浏览次数:

一块钱一个俯卧撑 O_O

微信