公司:酷家乐
以房产业务为例分享SaaS业务设计心路
SaaS业务设计本质上属于B端产品设计, 但是房企业务因行业属性的独特性也带来了设计层面的差异性。笔者将自己在房产业务的设计心路分享跟大家,一方面希望帮助大家一定程度上了解面向大型B端地产客户的SaaS业务,另一方面也希望从“设计支撑”及“设计赋能”2个维度为大家带来新鲜的视角。
同事这样做接口校验,两天就完成了OKR
接口自动化是一种能提高服务回归效率,保证服务稳定性的重要方式。但是对很多做接口自动化的测试来说,往往痛苦大于快乐。主要问题还是在于接口自动化的校验。
写校验成本较高。很多接口响应字段可能非常多,结构体复杂,要做到详细校验编写成本很高。而越详细的校验,维护成本也越高。测试数据的变动,开发的改造,往往能让人崩溃。
校验不够详细。很多接口case为了急于求成没有写返回校验,或者校验深度不够,这会导致接口自动化流于形式,不能发挥真正的作用;
基于此,希望有一个快速编写接口响应校验的方法,要求简单、便捷、有效、可维护性高。
本以为接口自动化大家都在做,通用的响应校验网上应该有很多现成的,但是找了下却没有找到满意的。通用的json校验有,但是接口响应未必都是json格式的。DeepDiff在功能上基本满足要求,但是它是python的,而本人需要的是java的。
基于此,就考虑自己封装出一个基于java的通用的接口响应校验方法,降低接口响应校验的编写和维护成本。
如何设计B端技术创新型产品
对于以技术为核心竞争力的公司,往往会存在一些技术科研或技术实验室的团队,在主产品稳定后,避免不了要将实验室研究的其他技术进行孵化,衍生出新的产品来扩展新市场,完善公司更大的版图。技术创新通常分为2类,一类是成熟技术的改革,另一类是新兴技术的诞生,其中成熟技术的改革在一般公司更为普遍。
代码检测利器“利特莫斯”之优化血泪史
Litmus由测试效能开发,用于检测代码质量的平台。
Litmus支持代码异味、重复代码、复杂度、单元测试成功率、单元测试覆盖率等指标的获取。只有提测的代码质量越高,我们交付的产品的质量才有可能越高。
规模化敏捷-SoS(Scrum of Scrums)在某中台产研团队的协作实践
本文结合酷家乐施工图中台的实操案例,介绍规模化敏捷Scrum@Scale中Scrum of Scrums的协作经验。
B端设计经验总结-帮助新人快速上手
本篇文章总结了交互新人在初工作过程中可能面临的疑惑与问题,并结合自身经历总结了相关设计经验,希望能够帮助新人设计师快速上手B端设计,游刃有余的应对工作中面临的各种机遇与挑战。
Xpath封装还能这么玩?
酷家乐有一套自己的UI自动化框架--Hades,其主要以puppeteer与playwright为核心进行了二次封装改造,并整合了许多酷家乐设计工具前端api。使得UI自动化对canvas交互、前端性能测试有比较好的支持。
除了能力上的扩展以外,Hades还有一个显著特点是:它将puppeteer/playwright中的api都代理到一个pyBell对象上,使得我们无需关注browser、page、element等对象,大大简化了用例编写的难度。
系统化思维如何辅助设计实现
“抓重点”还是“好设计”?系统化思维辅助设计实现。
Scrum plus项目制 —— 双轨并行的酷家乐特色产研实践
敏捷Scrum与传统的项目制运作能否双轨并行?来看看酷家乐如何用双轨运作来保障产研目标达成的。
服务端低代码实现和设计思路
在理解了服务端低代码平台设计实现的基础上,能够让大家更好的使用低代码平台扩展出更多的能力,丰富工具的打造,知道什么时候可以使用,如何使用。
kuta将来可能会走向内部开源,可以帮助kuta后来开发者对前面搭建的kuta架构有个高度概括的认识,在目前kuta中间层的基础上,扩展出更多的低代码能力,丰富目前kuta低代码平台所支持的功能。
秩序之美(上)-浅析栅格系统
现如今随着设备尺寸的多种多样,产品在设计过程中需要适配到更多尺寸,布局方案与栅格系统的搭配使用,可以很好的做到跨平台跨尺寸适配,极大的提升设计效率。之前有小伙伴分享过适配选型的文章中也提到过栅格,大家可以回顾一下【Web产品的适配设计选型】。
其实,绝大多数的设计师都知道栅格很重要,市面上很多企业级系统也都在用栅格系统去规范化信息内容的排版布局,但很多设计师直接面对结论大多是一知半解,自己做设计时有些无从下手。
作者浏览了大量文章结合工作中的经验总结分享给大家,希望能帮助理解栅格系统的本质,并能举一反三应用在产品设计中,首先从基础的栅格系统解析开始吧。
突袭演练实战经验
随着酷家乐业务快速成长,用户对于服务的稳定性要求也越来越高,再加上业务复杂度与日俱增,发生线上故障时,由于缺失合理预案、研发人员缺少应急经验,各种报警满天飞,导致自乱阵脚,延长故障持续时间,导致故障无法快速止血。
系统是否健壮?是否有完善且合理的应急预案?研发人员是否掌握基础应急止血能力?能否根据问题现状快速定位出故障根因?等等一系列问题需要有合理的手段和方法,早于线上故障发生前,进行锻炼和验证。
基于需求产出进行效能度量的探索
什么是研发效能?如何对研发效能进行度量?
这些是我们在产研效能改进及提升过程中会碰到的一个基础性问题,不同的理论提出了不同的思路,我们从需求角度提出了一些效能度量的思路,并在酷家乐选取了随机的敏捷组进行了小范围的验证,具体见下文。
基于图像机器学习的自动化应用
在UI自动化的运行过程中,截取图片,对当前图片进行处理,定位&校验元素。
分库分表迁移测试实践
一、背景随着公司的业务规模逐渐扩大,用户量和业务的复杂度日益增加,各业务组需要把统一库中业务相关的表迁移到自
集群整体迁移测试策略实践
云原生给各中小公司工程效率带来了很大的便利,多家云厂商的架构体系不完全相同,在选择云厂商以及业务上云的过程中,整体的集群切换会是一个比较复杂的课题。
酷家乐在2022年初进行了一次整体集群切割,实际的切换过程由于前期的认真准备和各项策略的实施取得了符合预期的效果。本文期望给做整体集群切换的质量团队做一个分享。
机房切割可能在自有机房和公有云之间的迁移,或者公有云间的迁移。酷家乐碰到的场景是在公有云之间做迁移,文中姑且描述为A云到B云的切换,A云为旧生产集群,B云为新集群。
集群迁移涉及到工作面非常多,选出部分关键内容进行分享。