随着全球化贸易的进一步加深，不少互联网产品为了引入更大体量的用户体验并使用产品而开启了“出海之旅”。直接降低用户购买门槛的多币种支付，变成了产品必需品。如果说语言翻译是产品国际化的第一步，那么多币种支付能力的搭建就是紧随其后的第二步。

随着迭代的更替，业务数据数据越来越庞大、复杂，日常测试中，JSON数据存在每次id都变化、数组顺序变化、坐标发生变化、json中包转义json等现象，现有的JSON对比工具无法解决所有问题。业务线需要做对比，必须对数据进行特殊处理，未来数据结构发生变化，维护成本高。

基于此，我们决定开发一款通用的，能够支持个性化对比需求，拓展性好的JSON对比工具，来解决业务线日常测试中的JSON对比的难题。

本文结合群核科技技术类项目管理流程，浅谈下技术项目特有的一些挑战点及对应的解决方案。

关于软件的可用性测试大家并不陌生，可用性测试是评估软件/产品体验质量（是否易用、高效、令人满意）的常见手段，是体验度量的重要手段之一。

常见的可用性测试可大致分为两类：

不面向用户的可用性测试-用户模型法

用户模型是使用数学模型来模拟人机交互，其原理是认定用户使用产品都是有目标的，而大的目标有可以拆分为若干小目标，通过模型计算达成目标的所需时间。该方法无法适用于用户测试，在人机交互领域著名的预测模型是GOMS模型。

面向用户的可用性测试—用户调查法

用户调查是通过对用户进行访谈，手段多样，包含问卷调查、用户访谈、焦点小组、观察法、绩效测量、启发式评估等，这其中，使用更多也更为人熟知是问卷调查。

问卷调查相对于其他手段的好处在其调研结果更为客观，可信度较强，且问卷的创建经过了信效度和灵敏度测试，结果更具备说服力。

随着产品的不停迭代以及新旧产品的更替，有些产品一旦转入维护状态，测试工作就会变得相当棘手，保障老旧服务的稳定运行也就遇到了瓶颈。

JTBD全称Jobs To Be Done，中文翻译为待办任务（或待完成工作），也有人称其为“焦糖布丁理论”。是由哈佛大学教授Clay christansen于2003年提出，一种洞察用户需求的模型及理论，被认为是颠覆性创新的理论基础。JTBD中的一些概念并不是全新的，但它确实是一个少有的可用于产品创新的系统性研究框架。

从催逼盯，到串推破的进化；从点线面，到突破认知的格局；做认为对的事，心态定乾坤。

数据保存是Web端工具的基础功能，一般在产品和技术框架设计之初就已经确定了数据保存的方式，后续不太会频繁更改。

正因为如此，在日常需求迭代中，设计师很容易忽略数据保存的过程，也很少质疑当前的保存机制是否合理，但是当需要设计新模块或产品时就会对保存有疑惑。

此外，保存也是一个受技术限制较大的领域，设计师需要对保存的技术类型有基础认知，因为它会影响保存生效的逻辑和交互形式。 本文将会基于个人经验，从设计表现和技术实现的角度聊聊Web端工具的数据保存。

SaaS业务设计本质上属于B端产品设计， 但是房企业务因行业属性的独特性也带来了设计层面的差异性。笔者将自己在房产业务的设计心路分享跟大家，一方面希望帮助大家一定程度上了解面向大型B端地产客户的SaaS业务，另一方面也希望从“设计支撑”及“设计赋能”2个维度为大家带来新鲜的视角。

接口自动化是一种能提高服务回归效率，保证服务稳定性的重要方式。但是对很多做接口自动化的测试来说，往往痛苦大于快乐。主要问题还是在于接口自动化的校验。

写校验成本较高。很多接口响应字段可能非常多，结构体复杂，要做到详细校验编写成本很高。而越详细的校验，维护成本也越高。测试数据的变动，开发的改造，往往能让人崩溃。

校验不够详细。很多接口case为了急于求成没有写返回校验，或者校验深度不够，这会导致接口自动化流于形式，不能发挥真正的作用；

基于此，希望有一个快速编写接口响应校验的方法，要求简单、便捷、有效、可维护性高。

本以为接口自动化大家都在做，通用的响应校验网上应该有很多现成的，但是找了下却没有找到满意的。通用的json校验有，但是接口响应未必都是json格式的。DeepDiff在功能上基本满足要求，但是它是python的，而本人需要的是java的。

基于此，就考虑自己封装出一个基于java的通用的接口响应校验方法，降低接口响应校验的编写和维护成本。

对于以技术为核心竞争力的公司，往往会存在一些技术科研或技术实验室的团队，在主产品稳定后，避免不了要将实验室研究的其他技术进行孵化，衍生出新的产品来扩展新市场，完善公司更大的版图。技术创新通常分为2类，一类是成熟技术的改革，另一类是新兴技术的诞生，其中成熟技术的改革在一般公司更为普遍。

Litmus由测试效能开发，用于检测代码质量的平台。

Litmus支持代码异味、重复代码、复杂度、单元测试成功率、单元测试覆盖率等指标的获取。只有提测的代码质量越高，我们交付的产品的质量才有可能越高。

本文结合酷家乐施工图中台的实操案例，介绍规模化敏捷Scrum@Scale中Scrum of Scrums的协作经验。

本篇文章总结了交互新人在初工作过程中可能面临的疑惑与问题，并结合自身经历总结了相关设计经验，希望能够帮助新人设计师快速上手B端设计，游刃有余的应对工作中面临的各种机遇与挑战。

酷家乐有一套自己的UI自动化框架--Hades，其主要以puppeteer与playwright为核心进行了二次封装改造，并整合了许多酷家乐设计工具前端api。使得UI自动化对canvas交互、前端性能测试有比较好的支持。

除了能力上的扩展以外，Hades还有一个显著特点是:它将puppeteer/playwright中的api都代理到一个pyBell对象上，使得我们无需关注browser、page、element等对象，大大简化了用例编写的难度。

“抓重点”还是“好设计”？系统化思维辅助设计实现。