话题公司 › 有赞

公司:有赞

关联话题: youzan

有赞(Youzan,原名口袋通)是总部位于中国杭州的电商平台,全名为杭州有赞科技有限公司。于2012年11月27日在贝塔咖啡馆孵化成立。公司创始人兼CEO白鸦。于2018年4月在港股上市,被称为“微信生态第一股”。2019年8月8日,有赞方面宣布获得百度3000万美元的投资。 2020年5月28日,百度投资有赞完成交割。2020年11月,推出国际版产品AllValue。

有赞页面级E2E测试探索-页面比对

页面级测试是Web测试的重要组成部分,主要关注用户界面展示、交互及用户体验,页面级测试往往涉及复杂的用户交互,页面比对的思路是传统UIA的一种补充,聚焦前端交互、样式回归,解决需要人工设置断言的问题,且维护相对简单,降低自动化测试维护成本。

基于Fuzzing和ChatGPT结合的AI自动化测试实践

自动化测试是测试活动中常见的一种质量保障手段,结合Fuzzing的思路,可用于识别程序中的潜在漏洞。笔者在使用ChatGPT的过程中,发现它拥有强大的语义理解和文本生成能力,如果将其运用于自动化测试的编写,将是一种不错的提效手段。

Kylin4 在有赞业务场景下的深度实践

本文介绍了Kylin4在有赞业务场景中的多方面功能与性能优化。实现基于Cube的查询限流提高集群稳定性,解决Parquet倾斜、优化范围查询提升查询性能。优化类加载解决高并发下性能问题,全面提升系统稳定性与性能。

《有赞SaaS工作手册》暨 SaaS创业十年的一些教训和经验总结

中国的SaaS行业有着行业阶段早、基础人才不足等特点,可参考的资料较少。有赞侥幸作为这行业的先行者积累了一些经验和教训,本文档起于2022年10月,由有赞参谋部负责编辑,以“方法论”视角为主(不包括实践中我们的使命愿景以及业务战略/策略选择),目的是为了“把业务常识/知识变成组织通识”帮助同事们提升日常协作沟通的效率。

技术探索-网页打不开排查指南(上)

日常我们在浏览某个网页的时候,可能会遇到打不开的问题,技术支持在处理工单问题时也会遇到此类问题,今天我们就来讲下网页打不开问题背后的逻辑,也就是网页浏览在 Windows 系统层面的生效流程,这样当遇到问题后才能更全面、更效率的去解决。

DataX在有赞大数据平台的实践

随着有赞的业务发展,数据同步的场景越来越多,主要是 MySQL、Hive 与文本文件之间的数据同步,Sqoop 已经不能完全满足需求。在2017年初,我们已经无法忍受 Sqoop 给我们带来的折磨,准备改造我们的数据同步工具。

数据降本利器:无用数据下线自动化

离线存在大量零散的无用数据,人工治理成本很高。有赞是如何识别并自动化下线的呢?

有赞移动助手App 本地抓包方案

我们在移动助手 App 集成了本地抓包的功能,在测试抓包,线上问题排查等场景发挥着重要的作用。

有赞微商城-Android 组件化方案

本文主要介绍了有赞微商城 Android 组件化的一些思路和实现。

浅谈 Android Dex 文件

本文介绍了 Java 代码转化为 Dex 文件的步骤和 Dex 文件的格式,以及在 Tinker 热修复技术方案中的使用。

有赞实时计算 Flink 1.13 升级实践

随着有赞实时计算业务场景全部以Flink SQL的方式接入,对有赞现有的引擎版本—Flink 1.10的SQL能力提出了越来越多无法满足的需求以及可以优化的功能点。目前有赞的Flink SQL是在Yarn上运行,但是在公司应用容器化的背景下,可以统一使用公司K8S资源池,同时考虑到任务之间的隔离性以及任务的弹性调度,Flink SQL任务K8S化是必须进行的,所以我们也希望通过这次升级直接利社区的on K8S能力,直接将FlinkSQL集群迁移到K8S上。特别是社区在Flink 1.13中on Native K8S能力的支持完善,为了紧跟社区同时提升有赞实时计算引擎的能力,经过一些列调研,我们决定将有赞实时计算引擎由Flink 1.10升级到Flink 1.13.2。

JVM和机器规格调优在有赞的实践

本文介绍了有赞如何通过JVM、机器规格和参数调优,实现提升稳定性和降低成本的双重收益。

有赞数据中台建设实践

介绍了有赞的数据中台产生的背景和建设思路。

高频问题的“生命周期”

高频问题在技术支持岗位管理中有哪些“生命周期”呢?我将其分为四个阶段:问题暴露阶段、信息传递阶段、问题解决阶段、问题回顾阶段。

有赞线上拨测系统实践(一)

有赞现有的线上保障手段可分为运维层面、产品层面、安全层面、服务层面和测试层面等维度。本文重点介绍我们在测试层面的实践。

探索实践—如何寻找相似问题?

在有赞,技术支持日常工作中最重要的内容是快速解决商家问题,通常线上发生问题后我们将会根据影响商家数、影响范围、影响场景做级别区分。但商家在遇到问题时候,不同商家反馈的现象描述也存在区别、接待处理的人员也是来自不同业务线。这里会导致技术支持在查看问题工单,在对影响范围的判断上比较滞后,下面我们就来探索如何从不同问题中找出相似问题。

首先在判断 2 个现象描述是否为同一问题时候,通过模块是没办法区分的,比如营销玩法-优惠券,关于优惠券的问题会非常多,无法具体场景的区分。不可能是优惠券场景的都有问题,那么我们只有从不同工单中的描述内容中去进行字符串匹配。

Home - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-05 14:40
浙ICP备14020137号-1 $Map of visitor$