测试基础 测试先知是什么

CKL的思考 · 2022年11月24日 · 最后由 今晚打老虎 回复于 2022年11月25日 · 4476 次阅读

如果你有去看测试相关的英文资料,会看到一个比较有意思的词:test oracle。非常的常见。这个词是什么意思呢?肯定不是数据库测试。多数情况下,会翻译成:测试先知。这是个什么东西?

01

在设计测试用例的时候,测试人员都会指定输入项和预期值。测试先知,指的就是这个预期值,也就是你认为正确的输出应该是什么,或者你判断测试用例执行通过的标准是什么。所有测试都离不开测试先知,它是应用任何测试技术都需要考虑的环节。它是一种识别潜在问题的启发式原则或机制。测试人员需要从不同关系人角度,设计多个测试先知来考察软件的行为。

测试人员需要非常清楚自己的情况,也就是自己所拥有的知识,包括产品知识、行业知识、测试技术、开发技术和计算机基础等。检查这些知识是为了在测试时能够快速和有效地确定所发现的问题是否是缺陷。即测试人员需要综合各种知识以构造一组测试先知,从而高效地识别产品缺陷。

很多人说,测试判定一个测试结果是否是缺陷,最可靠的依据不就是需求文档么?如果需求文档有明确的定义,那么这样的测试先知就是明确的,没什么好讨论的。仅仅靠需求文档,是否足够呢?

02

测试专家 Michael Bolton 和 James Bach 提出的识别和运用测试先知的想法列表,一共有七种,简称 HICCUPPS。

History(历史):软件的功能与它的历史行为一致,以保证用户的数据、技能、经验持续有效

笔者注:个人的经验是,在迭代测试前期,对于那些流程红结构发生变化的环节,要特别注意数据和功能的兼容性。例如某个功能需要去掉某个元素,那么历史数据如何处理,如何显示?如果增加一个字段,那么是否需要给个默认值?在业务数据流转的过程中,如果某个环节被取消了,那么前后的数据如何做好衔接?这都依赖于测试人员对业务的熟悉和深度的思考。

Image(愿景):软件的表现符合开发团队设定的期望,将精力集中在产品最有价值的属性上。

笔者注:这个对于传统模式下的研发测试人员,可能会有点陌生,但是对于熟悉敏捷研发和测试的人员,应该会非常熟悉,每个迭代的功能是否在原来的故事地图或者旅程地图上能够找到对应的规划?是否有些功能偏离了预期?这个也是需要测试人员关注的。

Comparable Products(可对比的产品):使用相似产品作为测试先知来评测当前产品。

笔者注:笔者曾经组织过团队内的测试对象竞品分析,获益匪浅,在同类竞品的测试过程中,我们可以提高对自身产品的认知,知道哪些功能或者操作能够获得用户的认可。如果你对某些测试对象不熟悉(特别是偏底层的技术型应用测试,例如网关、基础服务、流量跟踪等技术底层应用),找一款同类产品来验证和学习,是非常有效的方法。

Claims(声明):产品满足项目文档关于其功能和质量的论述,包含需求说明书、用户手册之类的文档

笔者注:这个就是测试先知的主要来源,在敏捷的环境下,我们需要更早的参与需求讨论,并且实例化,以便快速构造验证方案。

Users's Expecations(用户期望):测试人员站在用户的角度思考,以检查软件是否真正地为用户服务并达到了他们的期望

笔者注:产品经理很多时候并不会很高频的使用自己的系统,对功能的理解也不会特别深刻(我相信大部分测试都会比产品经理更熟悉产品本身,不论是操作还是流程),所以测试人员更应该从使用者的角度去尝试提出一些问题,并有能力去验证这些问题。

Product itself(产品本身):产品所拥有的功能和使用模式彼此一致

笔者注:这个更多的是关注产品的交互方式是否一致、风格是否一致。

Purpose(意图):产品能够体察并服务于用户的意图

笔者注:关注产品身本主要解决什么用户痛点。可以结合 KANO 模型对需求进行分类。

Statutes and Standards(法规和标准):建议测试人员研究产品相关的法令法规、行业标准、合同约定、技术标准等强制性法规,用它们作为测试先知来指导测试设计和评估。

笔者注:笔者有做海外项目经验,也协助过团队认证国家安全等保。所以有过相关的经验,特别是当你的产品需要出海,或者部署到特定区域,需要适当关注下。

03

通过了解 HICCUPPS,确认测试先知,有助到我们提前识别潜在问题,测试人员并不能依靠单一的测试先知去判断测试是否通过。测试先知本质是一种启发式方法,它提供了有效的检查策略,但不能发现所检查领域内的所有缺陷。

尽管我们有很多方式去丰富测试先知,但不支付足够的时间成本很难达到非常完美的程度(所有预期输出都在测试之前明确下来是需要很多时间成本投入的)。所以,我们可以结合之前提到的启发式测试策略,综合应用这些技巧,在测试活动正式开始前,做好准备工作,为测试活动的正式开展,做好准备。

可能很多人会疑惑,HICCUPPS 中的很多方法,更多的好像是产品经理的职责,为什么需要测试人员来承担呢?在职场中,笔者一直坚持:职责明确,边界模糊。很多事,能主动多做一点,就一定会多一份收获,会在将来给你带来意外之喜。笔者已经多次验证并体会到这种快乐了。

原文链接:https://mp.weixin.qq.com/s/qqBxwmJoVY7OYYFbl0FFAg

共收到 8 条回复 时间 点赞

测试后知是什么?测试中知是什么?测试不知是什么?测试知不知是什么?你知道吗?
不知是我认识有限还是理解能力不足,看到此文的第一想法是:这又是什么鬼东西蹦出来了?
各种各样的名词层出不穷,真正落到实处的却还是那些,搞这些花里胡哨是占用平台资源还是为了涨粉啊。

就是指预期结果啊,以后这个公众号的文章不要看了

看着这种文章,就吃不下饭

不知道这个文章哪里刺激到大家了。。翻译了一个名词,加上了自己的理解而以。。奇怪。

温华 回复

文章讨论的是这个预期结果怎么来,需要从哪些方面去确认,不仅仅是需求文档,而是需要考虑更多的内容。

这篇文章所阐述,在测试工程师用例设计环节和用例评审环节可能更突出文章阐述内容。这也是我所理解的测试工程师职业素养的软实力之一,尤其是职业生涯接触过多个产品团队,且各产品能力层次不齐的情况会更有体会在测试环节的流程压力,测试人员有足够的综合能力,可避开一部分的测试压力,并对最后的产品质量有一定帮助,但并不认同文中所说的时间成本,这跟对产品的理解深度和各业务层面的程度和思维理解的全面性有有关系,相当于同一场景不同测试人员理解的测试范围关联及相关结果预测。

test oracle,多年前的术语了,意为结果参照物,也就是预期结果,要骂就骂那些二货翻译吧,没有很好的为这个词的翻译找到抓手,也没有跟读者们拉通对齐,所以无法给大家的工作赋能……

槽神 回复

那是我反应过激了,唉,实在是对这种文章腻歪了,还不如来个输出 helloworld 的教程呢

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册