客户端应用中崩溃类型有多种，包括普通崩溃，主线程卡死，野指针崩溃，后台崩溃等等。当进程发生崩溃后系统会自动生成相应的崩溃信息，我们可以根据符号表解析崩溃日志，线上用户可以通过Bugly等第三方工具收集并解析堆栈。但是在解析的过程中大家可以发现解析一个崩溃日志操作非常繁琐，有时候出现解析失败的情况，甚至会解析错误。本文章主要介绍多个不同系统崩溃日志的解析方案。

电商行业，整个购物流程，离不开跟钱打交道，系统内也是门门道道，例如打款，对账等等业务，一旦涉及到钱的业务出现问题，都有可能造成严重的线上事故。

这部分的测试验证存在很多痛点，验证的过程主要依靠人工校验，涉及多个系统查询比对，耗时较长；此外在跨部门协作项目中，常常由于彼此对专业术语理解不一致，导致沟通成本较高。

本文重点分享转转QA在涉及钱款方面的业务场景测试中是如何解决上述测试痛点的？我们为什么要设计一套涉及打款校验的工具？它在实际应用中效果如何？

转转C2B回收业务，一句话概括就是从用户手中回收3C数码产品。

用户选择想要估价商品进行估价，如用户认为合理则可以将商品邮寄至平台，平台收货后进行质量检测，同时用户提供确切的报价，用户权衡觉得合理后，可以点击确认回收，平台将给用户进行打款。

那么如何有效提升用户下单量呢？报价合理的基础上，我们还需要给予用户一定的现金补贴，买家端称之为“满减券”, 而卖家端则是“满加券”， 后续都统称为“加价券”，卖家用户满足一定售出金额的时候平台会给用户额外进行一定比例或者固定金额的价格补贴。

接下来我们将详细讲一下加价券业务的演进历程。

Picasso是58同城推出的一款sketch设计稿智能解析工具，可将sketch设计稿自动解析成还原精准，可用度高的前端代码；从而提高前端开发效率，助力业务快速发展。

图像作为信息存储和展示的一种重要载体，其质量高低对信息表达和用户体验具有重大影响，图像质量评价(IQA)主要通过图像特征进行分析，评估出图像的优劣，在视频图像质量检测、推荐排序等领域有重要应用。本文主要介绍 IQA 技术在 58 同城业务中的算法实践。

这里所说的状态机，全名为确定性有穷状态自动机，也常被简称为有穷自动机，简写FSM。在软件领域中，被广泛应用，如编译，正则表达式识别，游戏开发。状态机维护一组状态集合，和事件集合，能够对特定的事件输入，作出状态流转，并执行相应的动作。

IP设计不仅仅停留在形象设计上，还需要丰富的表情和动作塑造性格，传递感情，赋予形象鲜活的生命力。

篇幅有限，信息太多，简约和丰富怎么取舍？学会脑补大法，让你的设计折叠进大脑中。

Spring Expression Language（简称 SpEL，Sp：Spring，EL：Expression Language）是一个支持运行时查询和操作对象图的强大的表达式语言。

在Spring产品组合中与我们常见的Beans 模块、Core 核心模块、Context 上下文模块一起组成了Spring 的核心容器，是表达式计算的基础，支持在运行时查询和操作对象，可以与基于XML和基于注解的Spring配置还有bean定义一起使用。

本文主要介绍zzcase脑图组件升级前后的对比，以及落地应用。

在我们的日常工作中，总会出现各种各样的“错误”和突发的“异常”。无论我们做了多少准备，多少测试，这些异常总会在某个时间点出现，如果处理不当或是不及时，往往还会导致其他新的问题出现。所以我们要时刻注意这些陷阱以及需要一套“最佳实践”来建立起一个完善的异常处理机制。那么我们如何快速、准确地定位异常的发生的地方，和一些简易的异常信息方便研发定位问题？下面跟随我来看一下转转中台是如何优雅地对异常进行统一的监控和上报处理的。

功能用例设计与接口用例设计，是独立存在的，功能用例主要是验证测试页面功能实现，接口用例主要是验证接口入参和出参；从页面上看，功能测试过程是包含接口测试的，但是从服务底层上看，有些逻辑实现是功能页面覆盖不到的。

在业务测试当中，经常会遇到类似的场景：

A：功能测试测完了，接口测完了吗？

B：接口测完了，接下来就等功能测试了……

C：冒烟主流程没有问题，有些场景需要功能和接口一起验证！

D：这个场景单接口验证不了，要结合页面功能一起测试……

以上几个场景算是在业务测试阶段比较常见的，可能还有很多其他的业务场景等等，但都能看得出来，接口测试和功能测试，是分层进行的，这也是近几年行业中常见的分层测试做法。那么接下来，我们一起来看看流程设计和功能设计思路吧。

用户满意度我们一直非常关注，从每个季度的满意度调研中可以看出租房用户对于使用效率、功能完善性、信息丰富度和真实性以及NPS都相对较低。那么基于用户满意度低的大背景，如何从体验层面提升租房用户的NPS呢？

本地服务（黄页）微聊代运营模式是指人工客服代替58平台上的商家与C端用户IM沟通聊天以获取商机（如用户联系方式、细粒度需求信息等），再将商机转交给商家，促进商家成单。我们基于58AI Lab自研的灵犀智能语音语义平台构建了智能客服商家版，将其应用在微聊代运营场景下，通过人机协作模式提高商机获取效率，打造了黄页商家智能聊天助手。这里的人机协作模式先后经历了三个阶段：在早期机器人效果较一般时，机器人和人工客服分时工作，即人工客服不上班时才由机器人接待用户咨询。在经过优化机器人效果较优时，先机器人再人工，即当用户来咨询商家时，白天先由机器人接待，若机器人能够聊出商机则结束会话，若不能再转接人工客服，晚上使用纯机器人接待。在机器人效果和人工很接近甚至超过人工时，使用纯机器人接待，人工客服去从事其他更复杂的工作。2021年年初，黄页商家智能聊天助手被商业化，以“微聊管家”命名随会员套餐一起打包售卖给商家，全年共计服务了数万个商家，为公司创造收入超过五千万元。当前，机器人的商机转化率（聊出商机的会话数/总会话数）已达到了人工客服的98%水平，我们实现了纯机器人接待，节省了数十名客服人力。

黄页商家智能聊天助手属于留资机器人，与以回答用户提问为主的QA问答机器人不同，留资机器人的主要任务是引导用户留下资料信息，不仅要做自动问答，还需要做多轮引导，技术挑战更大，对话策略更为复杂。我们在部分黄页类目下实践了基于强化学习的对话策略，商机转化率绝对提升了10%，本文主要分享我们基于强化学习的对话策略实践。

近半年我做过几十个官网需求，从定义每个官网从设计到开发走查会花费大量时间。因此，我总结了一套工作方法，1天时间就可以快速产出多个网页设计，本文将结合项目从设计提效角度与大家分享设计方法。

MySQL数据库读写分离，是提高服务质量的常用手段之一，而对于技术方案，有很多成熟开源框架或方案，例如：sharding-jdbc、spring中的AbstractRoutingDatasource、MySQL-Router等，而mysql-jdbc中的ReplicationConnection亦可支持。本文暂不对读写分离的技术选型做过多的分析，只是探索在使用druid作为数据源、结合ReplicationConnection做读写分离时，连接失效的原因，并找到一个简单有效的解决方案。