传统的测试左移
简单说,左移软件测试就是将开发周期看作从左到右的一条直线。在旧模式中,测试仅在这条直线的最右边发挥作用。认识到这一瓶颈,我们现在希望将测试的开始位置尽量左移。左移是在软件交付过程中尽早发现和防止缺陷的一种实践方法,目的是尽量在软件开发生命周期中尽早将测试任务左移,以提高产品质量。左移测试意味着在软件开发过程的早期阶段进行测试。
测试左移的优缺点
测试左移理论上的优点:
成本本身就是将测试左移的主要动机之一,据估算,超过一半的软件缺陷可以在需求挖掘阶段被发现,只有不到10%的缺陷出现在生命周期的开发阶段,在产品投入生产后消除缺陷的成本将是需求挖掘阶段的100倍以上 更高的自动化效率,左移可以提高自动测试的能力。测试自动化的主要好处包括:显著减少人为错误、扩展测试范围(可以同时进行多个测试)、测试人员能够专注于更有趣、更有意义的任务、减少生产问题 更快的软件交付效率越早发现缺陷、越能快速修复它们。如果您能在生产周期的早期发现缺陷,便可以更快地修复它们。从而:大大缩短两次产品发布之间的时间间隔,提高软件质量
测试左移理论上的缺点:
极高的测试基建要求,测试左移对代码扫描、质量度量、接口用例自动化、完善的测试用例、数据工厂、测试环境等都有较高要求,需要在具有一定基建能力下才能完善测试左移 很多团队所处的生命周期不适用,对于初创团队、创新团队、快速迭代团队等团队不一定适用于测试左移,上述团队在绝大部分 容忍度较高的互联网行业,对于部分用户体感不通的互联网业务,用户能够容忍小的问题上线,只要快速修复即可,该业务有时候大家更加看重的是快速发现问题,而不是在线下做到尽善尽美
云音乐测试左移的痛点
开发以为:
* 测试左移完全是工作的转移,变成了纯是开发做测试
测试以为:
* 测试左移,工作全是开发的,但是出问题测试也都要担责
当我们讨论这个痛点之前,我们一定绕不过去的一个问题就是:开发测试比 ,目前的测试左移是我们主动选择的结果还是被动选择的结果
结论:以目前云音乐的开发测试比,我们很难完全支持所有业务,此处涉及组织敏感数据,细节不在此处展开
行业内会是什么样
局部的测试左移:
极致服务端录制回放 https://help.aliyun.com/document_detail/62635.html 导购、交易特色录制回放方案 封版模式,服务端开发自测,同时通过客户端测试兜底
我期望的测试左移是什么
理想的测试左移:
事前
技术方案评审 核心p0、p1的接口自动化 场景自动化录制回放 特定场景的UI自动化
事中
中心化的客户端卡口(crash、舆情中心化卡口、高危组件识别兜底、包产物检查等) P0场景回归兜底(约1000个测试用例) P1场景回归兜底(约3000个测试用例) 核心财报埋点卡口兜底
事后
强大的染色能力,重点项目的上线,相关功能逐步灰度上线,灰度的功能能够全量隔离并单独监控,比如针对改动功能用户的舆情、crash等能单独识别 强大的中心化crash、舆情、slo监控处理群 资损监控
通过事前、事中、事后的方式,显著的提升确定性、提高质量,同时也能减少测试左移,研发的体感,避免工作量的转移
测试用例自动化的完善
进一步的覆盖率提升
测试左移一定需要具有强大的自动化用例,通过稳定、准确、覆盖率高的自动化测试用例提高整体线下质量。这里涉及到服务端测试用例与客户端测试用例,目前根据业界自动化成熟度在服务端自动化要求会更加高,需要涉及绝大部分场景,客户端这块主要用于稳定性自动化与核心用例回归兜底
服务端自动化提升
目前从行业内技术发展看,服务端的自动化技术已经较成熟,不管是接口测试还是引流自动化,服务端自动化具有几个优点
稳定性高,在接口不大规模改动的前提下,服务端自动化在执行过程中有较高的成功率 成本相对较低,接口自动化主要是rpc接口的请求以及返回值的教研,通过gotest等接口测试平台,编写服务端自动化的成本相对较低,通过引流回放的成本更低 较好管理,服务端接口的用例基本以研发接口为主,整体用例场景较好管理
首先是服务端测试用例的提升,平台这块主要希望服用gotest接口测试平台,核心2个关键次:稳定、覆盖率高
针对稳定,周维度跟进,连续两周稳定性不达标,@对应质量组长跟进,并提醒改进 针对覆盖率,中心化度量覆盖率,通过分析ox平台和goapi平台的接口数,并将各业务存量接口未导入goAPI的集中导入
最终期望 3分:服务端线下接口覆盖率达到95%,CI用例通过率95%;代码覆盖率:50% 5分:服务端线下接口覆盖率达到99%,CI用例通过率99%;代码覆盖率:60%;
服务端自动化长远方案:加强引流平台的建设,通过线上流量录制回放,并做好线上流量的用例、场景管理,进一步减少自动化用例成本
客户端自动化提升
目前从行业内技术发展看,客户端的自动化技术相对还需要突破,行业内经常听说某团队维护几万的服务端自动化脚本,但是很少听说某团队维护超过1000以上的客户端脚本,客户端自动化具有以下特点:
具有明显的中心化特征,不管是什么团队,最终客户端代码的实现都是通过中心化发版来上线,因此非常适合集中做monkey、内存泄漏等中心化稳定性操作 自动化稳定性相对不高,维护成本相对较高,因为前端UI界面变化较块,客户端脚本成功率普遍显著低于服务端
客户端中短期方案:
中心化的monkey、内存泄漏测试,通过中心化运作,通过monkey、内存泄漏等方案,集中发现问题 中心化的P0测试用例回归,测试用例不追求大而全,保障核心场景自动化没问题 长期方案:目前行业内针对瀑布流、自定义动态生成有较好的客户端成功率
瀑布流场景:
瀑布流场景用户操作简单,核心功能主要为上滑与下滑,自动化运行简单,可以通过UI自动化执行上滑下滑,然后通过截图,图像对比进行校验,成功率较高,即使是千人千面也可以通过mock规避相关个性化问题,因此后续涉及瀑布流场景建议UI自动化突破
自定义动态生成场景:
自定义动态下发场景,客户端最终的界面是通过服务端约定协议自动生成的,因此只要和客户端引擎、协议打通,最终的界面是确定的,UI自动化可以针对协议编写自动化脚本,稳定性方面可以极大的规避之前UI界面变动导致的成功率较低的问题
强大的客户端卡口能力
客户端是绝大部分功能上线交付消费者的中心节点,集中做好客户端的功能保障,在很大程度上能形成中心化的兜底,规避较多的重大问题。因此云音乐主要在测试用例三层兜底、版本流程发布管控上做了较大投入
版本发布三层兜底
云音乐客户端版本版本发布设定三层兜底,首先是P00用例,只出为最核心的关键用例集,只要在涉及到发布,包产物有变动,都需要执行一次关键核心用例集
然后是P0用例,大概1000条左右,按照正常冻结集成时间,一天内执行完,主要包含日常回归的主要用例,每个模块的主流程
最后是P1用例,大概3000条左右,主要包含每个模块其他额外的分支场景,该用例需要执行3天,且不需要考虑用户有修改代码,每次只执行一次
通过三层兜底,我们客户端实现了核心功能只要改动都做好了回归,分之场景一定周期也能做到全量回归,通过分级做到了成本与回归面的统一
版本流程优化
通过版本发布的checklist流程化,保障每次包的发出,不会出现较大的问题,让每次包产物的变化得到性能、功能、埋点、稳定性等方面的验证
强大的监控能力
当前面所有的测试、兜底都完成后,还是会有问题泄漏,因此我们也需要有良好的问题发现能力,避免质量显著下降
事前-监控设计
我们希望重点项目上线前默认都是有监控的,带着监控上线的功能才更加具有确定性
服务端系统需要关注:
GoAPI巡检监控 SLO监控 pylon 埋点监控 哨兵监控 Nydus监控 / Kafka监控 NDC监控 舆情监控
前端监控需要关注:
Corona监控 舆情监控 H5巡检监控 RN巡检监控
同时发布要分批次,并做好分批次监控观察
事中-重点项目染色
1、重点项目-关联标记(项目自定义标记,自定义流量标记x-proj-tag)
2、服务端链路监控告警区分:大前端请求API透传标记+网关请求流量打标+脚手架中间件透传标记+应用日志监控SDK上报流量标记+监控平台通过流量标记区分监控告警内容
3、客户端监控告警区分:大前端日志异常和崩溃上报带上业务自定义标记
事后-中心化监控处理
监控的效果需要可被观测,因此分级的重要的报警都会被集中到中心化群里被所有人观测,提高处理者处理的压力和动力
结语
以上就是我对测试左移的一些理解,也包含了挺多测试右移的思想。主要适用于风险适中的业务,对涉及资金类、电商核心流程等需要谨慎看待
最后
更多岗位,可进入网易招聘官网查看 https://hr.163.com/
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...