软件质量保障
通信硕士,拥有3项发明专利。前字节跳动测试工程师,现就职于蚂蚁集团,工作重点为微服务测试、接口测试平台研发等
展开
-
全链路测试不是银弹
我们要正确看待全链路测试,不能迷信于全链路测试,觉得全链路测试通过就没啥问题了。要知道,全链路测试更多从业务角度出发,不能覆盖所有潜在异常场景,二者可以相辅相成,但对于日常自动化回归,我认为做好域内测试自动化才是底盘,全链路自动化没什么必要原创 2022-02-26 10:51:19 · 482 阅读 · 0 评论 -
基于全链路的测试分析实践
链路可以分为业务链路和调用链路,调用链路主要指从请求发起方到结果返回所途径各种服务/中间件产生的路径,可以理解为单系统[域]下的某一功能模块,例如淘宝添加购物车->提交订单->支付这个场景,就包含收单域/支付域/商服域/会员域等,所以全链路必然包含[微服务架构下]多个系统[域]的相互交互,而全链路信息流要素则首先需要集合内需要各个域的测试owner基于单域被测服务分析得出场景因子,全链路的测试场景理论上是单域测试因子的笛卡尔积,但是鉴于全链路场景的成本比较高,因此在全链路场景分析上也要结合等价类分析方法。原创 2024-03-25 07:15:00 · 1814 阅读 · 0 评论 -
阿里微服务质量保障系列:域内测试
进入阿里之前,我就职的公司所在部门的产品都是单体应用,例如第一家公司是做投顾平台的,第二家公司所在的团队是做在线教育的,负责的产品是内容生产平台。投顾平台这个产品是服务于券商投顾员工的,属于券商内部应用,用户量并不大。内容生产平台是为公司内部的QC团队使用的,用于录入K12资料内容,用户量其实也不算大。因此,用户量不大的情况,单体应用也是产品实现的最优解。而支付宝的用户量以亿级,单体架构已不适用,取而代之的是微服务架构,随着不同的团队结构也发生变化。下面用一张图可以展示出差异所在。原创 2024-04-06 12:58:17 · 759 阅读 · 0 评论 -
阿里微服务质量保障系列:故障演练
有损演练是指直接在线上真实业务环境注入异常进行演练,演练模拟的真实有效性高,为了平衡业务影响一般会选择最核心场景、在业务最低峰期做演练,而且演练频次相对较小,例如为了验证多活容灾能力的机房断网演练,一般是一个月一次的演练频次;故障演练就是这个背景下诞生的,沉淀通用的故障场景,以可控成本在线上故障重放,以持续性的演练和回归方式的运营来暴露问题,不断验证和推动系统、工具、流程、人员能力的提升,从而提前发现并修复可避免的重大问题,或通过验证故障发现手段、故障修复能力来达到缩短故障修复时长的作用。原创 2023-11-07 20:42:28 · 238 阅读 · 0 评论 -
阿里微服务质量保障系列:阿里变更三板斧
变更是指对线上系统的任何操作(如:发布、增加、修改或移除等),或其他对生产业务可能有影响的任何操作。基于阿里巴巴的历史经验,有一半以上的重大故障皆为变更触发,因此,变更过程的风险防御显得尤为重要,会直接关乎业务的稳定性。变更系统是指承载任何对线上生产环境变更操作的系统或工具。例如拥有控制台的白屏化系统/工具、压测/演练平台、黑屏脚本、开放出来的可触发变更操作的API、不以变更为主要功能和目标的平台/系统,如具备了对生产环境实施变更的功能,则相应的变更功能部分也视同变更系统对待等。原创 2023-10-29 10:53:20 · 512 阅读 · 0 评论 -
阿里微服务质量保障系列:性能监控最佳实践
通过将多个性能监控工具整合在一起,形成一个统一的监控平台,可以提高监控效率、监控精度、故障排查效率和可视化程度,从而帮助企业更好地了解其业务系统的运行情况,提高业务系统的稳定性和可靠性。前者维护成本低,容量弹性更大;基于全链路追踪生态,关联更多的指标、日志、事件、Profiling 等数据或工具,提升问题诊断或业务分析效率,才能更好的发挥全链路追踪的价值。很多大型企业,出于稳定性或数据安全等因素考虑,选择了多云部署,这种部署架构下,由于不同环境的网络隔离,以及基础设施的差异性,为运维人员带来了巨大的挑战。原创 2023-12-03 18:29:28 · 464 阅读 · 0 评论 -
阿里微服务质量保障系列:性能监控
什么是性能监控,以及性能监控的对象有哪些。伴随着突发流量、系统变更或代码腐化等因素,性能退化随时会发生。如在周年庆大促期间由于访问量暴涨导致请求超时无法下单;应用发布变更后,页面频繁卡顿导致客诉上升;线上系统运行一段时间后,突然发生OOM或连接打满拒绝访问。性能退化最直观的影响就是用户体验,比如打开一个商品详情页面的耗时从0.5s上升至3s,那么用户继续浏览的意愿度就会大幅下降。当性能进一步退化至超时阈值(比如5s),就会导致无法正常提供服务,影响服务可用性,进而带来巨额的业务损失或口碑崩坏。原创 2023-12-03 18:28:41 · 242 阅读 · 0 评论 -
阿里微服务质量保障系列:研发模式&发布策略
在实际运作中,大家都知道,feature分支虽然有效隔离了代码(减少相互影响),但由于集成不够频繁,如果项目持续周期长,则大大增加了feature分支到release分支集成过程中代码冲突的概率。为了解决发布时间长的问题,团队鼓励对于研发测试评估改动范围不大的feature使用持续发布的模式,即将feature分支在dev验证后,rebase主干分支代码后做SIT环境的集成测试&回归测试,测试通过后则推进预发、灰度、流程。它的发布过程是基于主干Master分支做的,因此没有在发布的过程中做相应地隔离。原创 2023-11-12 09:40:49 · 201 阅读 · 0 评论