测试三大难题之一 “测试充分性” 的应对策略

科技   2024-06-26 07:36   上海  

在《软件测试三大难题:我们必须面对和解决》文章中提到三大难题,前面已经讨论了《测试三大难题之一“Test Oracle”的应对策略》。下面讨论第2大难题“测试充分性”。
之前提到灵魂之问:“测试可以结束了吗?”,如果回答“结束了”,是不是说明测完了、软件没有问题了?但我们“不能保证没有问题”,那就说明有问题,那就测试没结束,还可以继续测下去。
类似的,《软件测试灵魂三问,如何怼回去?》中的第一问就是:为什么这个 Bug 测不出来?”,我们不能总是用 “测试著名原则:测试是不能穷尽的” 作为挡箭牌,如果那样,漏掉任何一个Bug,咱们测试人员都有借口,那么又如何保证质量呢?
在商业软件中,或面对具有一定规模(几万或几十万、几百万行代码)的软件时,我们无法证明软件没有问题,那就意味着软件常常带着缺陷被发布出去。那么如何保证质量呢?
这就是通过测试充分性来保证,即使有缺陷被遗漏(没有被发现),那也是隐藏很深、对用户影响很低的缺陷。通过良好的测试充分性将风险降到最低。
谈到“测试充分性”,许多同学首先会想到设计,设计足够的测试用例来保证,其实是错了,测试充分性能否得到保证,不是测试设计的问题,而是测试需求分析问题,因为测试需求分析是确定要测什么——即明确测试范围、测试项等
测试的确做不到100%,测试充分性是相对的,取决于测试目标。想达到什么样的测试目标(结果),就从测试目标出发;测试目标需要明确测试等充分性(测试覆盖率),而想达到什么水平的测试充分性,就需要从你如何定义测试充分性出发。
测试充分性包含三个层次的:代码层次的测试充分性、系统(功能/非功能)层次的测试充分性、业务层次的测试充分性,而“业务层次的测试充分性”最具决定性的。
正如软件测试三大难题:我们必须面对和解决》一文中说,代码测试覆盖率的数据是不靠谱的,我经常对同学或学员说,不要看覆盖率的数据,而是要看开发写的单元测试代码未来有了LLM生成测试代码,也许会好一些)。而且仅仅看行覆盖率、分支覆盖率也是不够的,还需要看变量/参数的取值(边界值、异常值等)、变量的定义和引用等。
系统层次的测试充分性带有主观性。我最喜欢举的例子就是,某系统有5大功能,我写5个测试用例,就能做到功能测试覆盖率100%,但这样的度量显然没有意义。如果让功能测试覆盖率有意义,那么我们如何做呢?留一个问题让你自己好好想一想。非功能性测试,往往也是许多团队的弱项,虽然都会做性能测试、压力测试等,但没有衡量其测试覆盖率。
测试经理常常被挑战的,还是那灵魂一问 “如何说明测试可以结束了?”、“测得如何?”,许多测试经理会说,某某功能我们测了,系统性能我们也测了,但上层其实不关心你测了哪些功能、哪些非功能特性,他们更关心业务表现如何、业务有没有受到影响或改进,这就是前面说到的 “业务层次的测试充分性”。那么,如何度量业务层次的测试充分性?国际标准、国家标准似乎都没有提到这点,就连之前号称 “业务驱动测试管理”的TMap模型,也没有很好谈到这个问题。你会怎么考虑或度量?这是留给你的第二个问题😄
概括起来,测试充分性应对策略:
  • 明确什么是测试充分性,包括上面提到的三个层次
  • 对具体的项目,明确其测试目标
  • 以终为始去做好测试分析
  • 基于风险的测试策略是必须的
  • 设计、执行实现基于测试分析的测试目标。
  • 持续改进,不断提升测试分析能力

如果真正想了解如何应对测试充分性,你可以看《全程软件测试(第3版)》,或找机会好好和你聊聊测试分析。

软件工程3.0时代
由于大模型(LLM)正在改变着千行百业,软件工程(SE)更是首当其冲,迎来软件工程3.0新时代:模型驱动研发、模型驱动运维。本公众号将致力于研究SE3.0时代的软件研发新范式、理论与方法,介绍SE3.0时代的工具与实践。
 最新文章