笔者的思考:测试左移,意味着测试思维的转变,我们需要从需求文档中脱离出来,从更广泛的视角来思考测试策略,从技术驱动转变成价值驱动。 而在测试左移的实践中,测试人员需要尝试去理解需求的业务价值,站在用户的角度去思考问题,理解用户的使用习惯、使用场景等信息。 业务价值可能比较抽象,似乎不是那么好理解,况且要跟具体的测试活动对应起来更是有些难度,在具体的实践过程中,我们团队的具体做法有几下几步: 1. 回顾、总结:针对线上的收集和反馈出来的数据,定期和产品团队进行沟通、探讨,改进产品设计,优化业务价值。 理解业务指标并不是一件容易的事,需要测试人员对被测试的产品有深度的了解,参与业务对上话。 03 思维上的转变 从基于文档的功能测试,到基于业务的价值测试,需要做更多思维上的转换,从单一的测试角色中走出来,我们的目标不再是高效地发现缺陷(发现缺陷很重要,但不是最重要的),而是快速交付适当质量的业务价值
在上篇的反模式中,有提到一个点:沉迷发现缺陷,忽视缺陷预防,有读者留言说:不通过BUG数量等量化数据,那么如何界定测试人员的价值或者贡献?本文聊聊自己对于测试价值的思考。 01 需求端的价值:从质量构建和缺陷预防的角度看,测试人员需要尽早地介入,了解需求。 04 个人价值体现:为了完好的完成以上团队层面的价值,测试人员个人要也需要具备一些突出的能力,形成一定的leadership,进而影响团队,体现自己的价值。 缺陷定位能力:同样一个缺陷,有的测试人员只能在页面上截个图,有的测试人员可以追踪日志、分析代码,甚至给出解决方案(这点笔者并不提倡)。你觉得哪个测试更有价值? 做好测试该做的事,讲好测试该有的故事,才能真实地体现测试人员的价值。
在上篇的反模式中,有提到一个点:沉迷发现缺陷,忽视缺陷预防,有读者留言说:不通过BUG数量等量化数据,那么如何界定测试人员的价值或者贡献?本文聊聊自己对于测试价值的思考。 01 需求端的价值:从质量构建和缺陷预防的角度看,测试人员需要尽早地介入,了解需求。 04 个人价值体现:为了完好的完成以上团队层面的价值,测试人员个人要也需要具备一些突出的能力,形成一定的leadership,进而影响团队,体现自己的价值。 缺陷定位能力:同样一个缺陷,有的测试人员只能在页面上截个图,有的测试人员可以追踪日志、分析代码,甚至给出解决方案(这点笔者并不提倡)。你觉得哪个测试更有价值? 做好测试该做的事,讲好测试该有的故事,才能真实地体现测试人员的价值。
写这篇文章的初衷来源于朋友圈CC的动态:“今年很多写测试工具平台没有成就业务价值的同学,被落入自由市场了”。我俩在评论区交流了下性能测试如何成就业务价值的问题。 基于我和CC的交流的内容,接下来谈谈性能测试如何创造业务价值,我会通过几个问题来阐述我的观点。 性能测试出现的初衷 先思考一个问题:我们开展性能测试的初衷或者说需求从何而来? 性能测试创造了什么价值 接着上文继续聊,用户有反馈,财务有诉求,业务遇到了痛点,怎么办?想办法解决问题! 性能测试创造价值的前提 前面我提到了技术是为业务目标达成提供支撑和效率工具,性能测试可以直接或间接创造业务价值,但并不是说有工具就能创造正向的价值。 正如我和CC交流的对话: CCTester 回复 老张:我觉得性能测试只要做起来还是在成就业务价值的。
QA的价值体现 by:授客 QQ:1033553122 1. 缺陷挖掘价值 QA人员一个很重要的价值就是在尽可能短的时间内找出尽可能多的缺陷。 百度案例: *案例1.白色情人节 说明:因为大部分电商交易支付对这“色情”两个词进行了过滤,结果导致涉及这个词的交易无法交易,损失几百万 *案例2.地图规则测试 说明:沃尔玛的规则 :5公里内出现两家沃尔玛 *案例3.手机百度几大业务跳转规则 说明:百度几大业务之间跳转存在缺陷,百度百科和百度搜索无法友好的跳转,测试业务的同学直接给李彦宏发了一份邮件,但是李没回关于这个bug 从业务逻辑的角度进行测试设计 业务逻辑(业务实体,实体完整性约束,业务规则,业务流程,业务流程启动器) 上述,案例1,案例2中的缺陷可以说是业务规则问题 2. 这就好比漏雨的屋顶,如果你仅是用水桶或脸盆去装下雨天屋顶漏下来的雨滴,那将是件很痛苦的事情,因为随时都可能下雨,而且永无止境,装水这件事也就永远无法结束…… 对比测试也是一样的,缺陷一直都会有,你永远找不完
测试就不能做点什么改变这种被动的现状吗?有,你需要践行测试左移和测试右移。 不管是测试左移还是测试右移,都是为产品质量服务。不要把提测认为是测试活动的开始,上线是测试活动的结束,更不要认为质量只是测试同学需要关注的。 ? 二 测试左移 1 是什么? ; 对于测试左移,进行了相应的尝试后,也发现了测试左移实践的问题: 测试要求提供概要设计、接口文档; 测试要求单元测试必须通过; 测试干预需求设计; 很多人都认为是测试在要求完成一些没必要的事情,测试在干预我的工作 ; 优秀的测试用例; 合理的测试计划; 合适的自动化; 适当的探索式测试; 开发自测(TDD、BDD,测试提供更好的用例、技术支持); 尽早的测试; 团队质量意识的培养; 对于测试左移,也需要一个重要的基础 相比较,测试左移的价值更高,尽早发现并解决问题,成本更低。
敏捷测试是敏捷开发方法论中的一部分,它强调快速响应变化、持续交付价值以及通过迭代和增量的方式改进软件。敏捷测试不仅改变了传统的测试方式,而且对整个软件开发生命周期产生了积极的影响。 而需求不明白的情况下很难定制一份具体详细的测试计划,当然随着时间的推移,我们也需要不断的更新优化,根据业务价值交付顺序灵活调整计划。 敏捷测试的价值一、加快上市时间,缩短价值交付周期敏捷测试可以帮助加快上市时间(Time-to-Market),从而缩短价值交付的周期。 首先,敏捷把产品开发划分为多次迭代,并且在每次迭代交付潜在可用的、有价值的产品给客户,没有经过测试的产品不能发布给客户。 敏捷测试确保每次迭代都有测试活动,从而保证每次迭代的有价值输出都是经过测试的,以便尽早达到发布条件,让最终用户尽快得到最小可行产品(Minimum Viable Product,MVP),尽快获取业务价值
原文链接 本文节选自霍格沃兹测试开发学社内部教材如果把测试简单分为两类,那么就是客户端测试和服务端测试。移动端的测试包括 UI 测试,兼容性测试等,服务端测试包括接口测试。 图片接口测试的价值服务端非常复杂,就像下图的阿里核心链路图,包含大约 150 个组件,组件与组件之间进行交互,形成了密集的后端网络。 UI 测试无法覆盖这么复杂的组件交互网络,所以要绕过客户端,直接使用接口测试对服务端进行测试。图片接口测试的体系对行业的各种测试进行分层,越往上,发现 bug 的时间越晚,成本越高。 接口测试(Service)相比 UI 测试,可以更早发现问题,更快的质量反馈;同理,单元测试(Unit)相比接口测试,可以更早发现问题,更快的质量反馈,花费的成本更低。 分层测试:图片客户端测试与服务端测试的关系虽然接口测试覆盖面广,但是也不能使用接口测试替代客户端测试。UI 测试涉及到了用户体验的问题,这部分是无法用接口测试进行替代的。
但是现实的情况很多时候并不是这样的,往往是测试开发团队会开发很多的工具,也会做很多的自动化测试,业务团队的测试人员并没有感到轻松,随着产品的体系越来越大的时候,这种压力会递增式的增加,在这个过程中,就得需要重新来思考自动化测试的价值和质量内建这部分 而测试效率,就是通过测试技术的手段来提升测试效率。 它的核心思想是金字塔的底部测试提供快速反馈,随着测试层级的上移,测试速度会变的慢而且测试范围会扩大。 回归到自动化测试本身,应该首先追求质量而不是数量。现实往往是追求数量而忽略本身。 所以这个过程中自动化测试需要注意的是测试场景的覆盖率,而不是自动化测试代码的覆盖率,过于追求自动化测试代码的覆盖率是非常脆弱的,而且具备伪命题,即使自动化测试代码100%的覆盖率又能代表什么了? 针对如上阐述的,自动化测试的价值具体为: 回归测试,批量的回归测试任务让自动化测试去承担 持续部署后快速验证被测服务的可测试性 线上环境以及预发布环境部署后快速的验证系统的可用性 自动化测试的核心本质就是让自动化测试回归产品质量的本质
考虑到SDLC每个阶段的业务期望,持续测试提供了对风险的定量评估,以及在SDLC的下一阶段进行之前帮助降低这些风险的可操作任务。目标是消除无意义的测试,并产生真正推动开发组织成功发布的增值任务。 持续测试——提供了三个主要的业务优势。 首先,连续测试是驱动SDLC决策中心系统的工件。连续的测试将核心业务功能作为一个支撑,在软件中表达和实现。 第二,持续测试建立了一个安全网,允许软件开发人员更快地将新特性推向市场。使用受信任的测试套件,确保依赖的应用程序组件和相关功能的完整性,开发人员可以立即评估代码更改的影响。 第三,持续测试允许管理者做出更好的权衡决策。从商业的角度来看,以创新的软件首先进入市场,实现一个可微的竞争优势,驱动着股东价值。然而,软件开发是一项复杂的工作。 这是股东价值的巨大损失。此外,看看经历过多次值得关注的软件故障的组织,很明显,市场会更积极地惩罚重复犯错误的人。惯犯的股票价格平均下跌了-5.68%,相当于负的26.5亿美元的市值损失。
如果我们提到手动测试,通常会低估手动测试的范围,这是一个很大的误解,自动化的目的是节省测试人员的时间来编写更好,更高效的测试脚本。手动测试依然会在业界盛行。 自动化测试和机器学习颇具潜力,给测试人员带来了很多机会。但是迄今为止,手动测试在测试软件方面的能力到底如何?进行软件测试时作为手动测试的弱点是什么? 探索性测试:测试方法包括同步学习,测试设计和测试执行。 回归测试:在进行任何新更改后测试整个应用程序。 随着数字发现越来越以移动设备为中心,准备好进行回归测试的移动网页至关重要。 跨浏览器测试:测试以确保您的Web应用程序可在不同屏幕尺寸的各种设备上通过不同的浏览器运行。 局限于测试用例 软件测试基于测试用例。通过有效的测试用例,产品保持了良好的质量,但并非总是如此。 测试用例数并不意味着它们可以保证质量。 测试用例可以保持统计,但是您不能盲目地依赖它们。测试是一个不断学习和适应的过程。因此,必需要在测试用例之外探索产品。
据科技资讯网TechInsider 2015年8月18日报道,部分人工智能科学家认为图灵测试几乎毫无价值,而且还使得人们背离了真正的人工智能科学。 图灵测试是以著名计算机科学家艾伦•图灵的名字命名的。 图灵在1950年的一篇论文中提出图灵测试,其内容是:如果计算机能在5分钟内回答由人类测试者提出的一系列问题,且其超过30%的回答让测试者误认为是人类所答,则计算机通过测试。 但后来质疑者通过测试,认为该程序并不真正具备通过图灵测试的能力,而是依赖于幽默和误导性回答去迷惑测试者,并经常重复提供一些令人费解的回答。 人工智能领域的奠基人之一马文•明斯基也反对以通过图灵测试为导向,并明确反对一项名为“罗布纳竞赛奖”的图灵测试活动。 罗素表示,现在人工智能领域的大部分科研人员都不会以通过图灵测试为研究目标。 而纽约大学的马库斯这针对以上重点设计了一系列测试,其中一项测试要求机器能够理解大多数人都可以理解的“语法模棱两可的句子”。马库斯希望新的测试可以激励研究人员开发出能够更深入理解世界的机器。
测试团队如何降本增效 对测试同学来说,质量是团队的安全线,也是最高目标。在保障交付质量的前提下达到降本增效的目标,我个人认为可以分为短期和长期两个阶段来开展实践。 比如以前接口测试都是手动执行,提升效率则可以采用自动化的方式;以前准备测试数据都是手动写SQL去一条一条插入数据,提升效率则可以考虑流量录制或者通过存储过程的方式去预埋数据,这样效率也会提高。 、沟通确认信息、跨部门资源协调; 在日常工作中,其实真正的编码和测试所耗费的时间并不多,更多的时间耗费在了确认需求、需求变更带来的返工、服务报错排查定位、准备测试数据、以及各种各样的沟通协调和会议中。 ,比如提测冒烟、单元测试等; 质量内建:通过流程规范宣讲以及以身作则的带头实践,要求各个角色实时对软件的质量负责,减少因为前期风险不可控而导致后期的修复成本增加,进而浪费大量资源; 环境治理:测试环境的稳定性是一个被大家忽略的环节 ,但这是我们所有测试活动开展的基础。
测试团队如何降本增效 对测试同学来说,质量是团队的安全线,也是最高目标。在保障交付质量的前提下达到降本增效的目标,我个人认为可以分为短期和长期两个阶段来开展实践。 比如以前接口测试都是手动执行,提升效率则可以采用自动化的方式;以前准备测试数据都是手动写SQL去一条一条插入数据,提升效率则可以考虑流量录制或者通过存储过程的方式去预埋数据,这样效率也会提高。 、沟通确认信息、跨部门资源协调; 在日常工作中,其实真正的编码和测试所耗费的时间并不多,更多的时间耗费在了确认需求、需求变更带来的返工、服务报错排查定位、准备测试数据、以及各种各样的沟通协调和会议中。 ,比如提测冒烟、单元测试等; 质量内建:通过流程规范宣讲以及以身作则的带头实践,要求各个角色实时对软件的质量负责,减少因为前期风险不可控而导致后期的修复成本增加,进而浪费大量资源; 环境治理:测试环境的稳定性是一个被大家忽略的环节 ,但这是我们所有测试活动开展的基础。
思考:各位每个迭代花几天去输出的测试用例价值到底在哪里? 那么今天我们就一起来分析一下,价值输出!大家在留言区积极轰炸! 按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。 尤其是测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。 除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据 4.反应测试进度测试人员开始按照测试用例的描述测试 每过完一个用例标记完成;这样测试也知道自己做过哪些操作,避免没有目的随机测试。 而已有相应测试用例,则反映实施测试或变更处理存在问题。 测试用例可以用来衡量一个项目测试质量。测试用例的健壮性,完整性,覆盖程度等,都对项目测试质量有影响。 因此在平时的测试流程中,编写测试用例就是测试过程中很重要的一步,每一个测试工程师都需要并且非常熟练的编写测试用例 能在编写测试用例中尽可能的覆盖任何异常的测试点;如何能编写优秀的测试用例,就需要测试人员掌握更多的用例编写技巧以及思考出更多的测试点
简介做测试的过程中,对于一些不容易构造、不容易获取的对象,用一个虚拟的对象来替代它,来达到相同的效果,这个虚拟的对象就是 Mock。 当做测试的时候,如果后端某些接口还不成熟、所依赖的接口不稳定或者所依赖的接口为第三方接口、构造依赖的接口数据太复杂等等这些问题的时候,可以用 Mock 的方式先虚拟这些接口返回来代替真正的接口返回。 Mock 测试的场景前后端数据交互第三方系统数据交互硬件设备解耦** **Mock 测试的价值与意义不依赖第三方数据节省工作量节省联调** **Mock 核心要素** **匹配规则匹配规则就是要确定到底要对哪个接口 具体要篡改成什么样子就需要根据设计的测试用例来确定了。比如要验证的是前端内容展示的场景,那根据等价类,边界值,就需要设计很多不同的展示内容。比如超长的,比如不同类型的内容。 总结Mock 测试的场景Mock 测试的价值与意义Mock 核心要素
二、价值与效能维度:外部彰显价值,内部提升效率对外价值宣示 业务对齐:测试活动不仅是技术保障,还要能展示直接支撑业务目标。例如,上市版本按时交付并满足合规要求,测试团队就是价值的守护者。 通过构建涵盖价值与效能、质量、成本、客户与流程的全方位测试价值体系,我们能够将测试活动转化为企业的核心竞争力。这不仅需要技术和工具的升级,更需要思维方式和管理理念的转变。 作为测试管理者,我们的使命是在确保软件质量的基础上,不断探索和创造新的价值,将测试打造成为推动业务成功的重要引擎,真正实现从“质量成本”到“质量价值”的转变。 软件测试不再是成本中心,而是价值创造的引擎。通过建立以价值与效能、质量、成本、客户与流程为四个支点的测试管理体系,可以实现以下目标: 对外:清晰展示测试如何支撑业务成功,提升组织影响力。 当我们真正能把“质量成本”转化为“质量价值”,测试团队不再只是“守门员”,而是企业面向未来的“价值创造者”。
在这一模式下,测试人员的角色与传统瀑布模型有着显著不同,从“缺陷发现者”向“质量保障者”和“业务风险防控者”转型,价值定位更加多元与战略化。 在敏捷迭代中,快速适应需求变化,保证测试可持续执行。二、敏捷开发中测试人员的核心价值1.提升开发质量、降低缺陷成本敏捷强调迭代交付,缺陷早期发现成本远低于后期修复。 ;持续参与迭代计划与风险评估,指导开发优先级决策;推动团队知识共享,文档化业务流程、测试矩阵和缺陷模式;结合自动化与探索性测试,覆盖核心功能和高风险场景;量化测试贡献,通过缺陷发现率、回归覆盖率和上线缺陷减少等指标体现价值 他们的价值体现在:提升迭代交付质量,降低缺陷成本;加快迭代速度,支持快速业务响应;驱动团队协作,提高整体质量意识;通过自动化和持续改进,实现测试效率最大化。 敏捷测试的核心目标,是在短周期、高频迭代的环境中,通过科学方法和技术手段,以最小投入获取最大价值,保障业务稳定和用户体验。
传统测试策略制定 → 挑战:经验依赖/资源浪费/效率低下/价值不明确 → AI驱动测试策略优化 → 优势:数据驱动/资源优化/效率提升/价值明确 你是否在测试策略制定中遇到过资源分配不合理、测试重点不明确 ,避免资源浪费 效率提升:提高测试的效率和速度,缩短测试周期 质量改进:提高测试的效果和质量,确保软件质量 成本降低:降低测试成本和质量成本 风险控制:识别和控制测试风险,确保产品稳定发布 价值实现:实现测试的价值 测试重点不明确:测试重点和优先级不明确,导致测试覆盖不均衡 效率低下:测试效率低下,难以满足快速迭代的开发需求 价值不明确:测试的价值和效果难以量化和评估 适应性差:难以适应快速变化的市场需求和复杂的软件系统 你认为AI技术在哪些测试资源分配场景中最有应用价值? 你认为AI技术在哪些测试覆盖策略优化场景中最有应用价值?
测试没有发现缺陷,存在两种情况:1. 没有深入的测试2. 研发交付的质量高。 针对没有深入的测试这种场景,在《迭代测试发现不了问题,怎么办》一文中做过探讨,有几点针对性的措施,这里不再展开。 本文重点讨论第二种情况,业务需求明确,研发个人能力强,做过充分的自测,交付质量很好,经过几个迭代的测试,发现的缺陷较少或者没有,那这个人提交的代码还要不要测试?测试人员的投入是否还有价值。 02、从测试人员的角度看 结合个人的经历和思考,我觉得第二种情况的测试投入还是必要的。测试的价值不仅仅是发现缺陷,至少还有以下几点直观的价值: a. 建立测试资产:测试设计、测试用例等测试过程资产的沉淀还是非常有必要的。如果不投入测试资源,对应的需求分析和用例都将缺失,后续如果其他人想要介入,就缺少对应的IT资产。 b. 05、不要轻视测试 这话其实很没说服力,当下的多数情况,测试还是总被轻视。但作为测试人,我还是要想多说些。