从业务需求看 Widget (小组件)技术架构
一、背景
最近团队做了一个小组件需求,从开发到上线出了不少问题。
需求内容大致是可以把图片加上一些元素放到小组件里展示,比如像一个相框、一个圆形徽章(电子吧唧)。有交互,比如轮播图片、点击使徽章旋转。
最近团队做了一个小组件需求,从开发到上线出了不少问题。
需求内容大致是可以把图片加上一些元素放到小组件里展示,比如像一个相框、一个圆形徽章(电子吧唧)。有交互,比如轮播图片、点击使徽章旋转。
对于大部分业务层面的需求,如果出问题,一般影响集中在:
基本是局部的业务损失。而清分结算系统一旦出问题,影响的是平台资金、商户收益、财务可信度。例如:
业务配置复杂,人工难免核查错漏,经常出现一些配置异常问题导致的线上问题。此外,一些偶发的问题,难以排查原因,可以通过巡检的方式检测到,然后立即处理,降低损失。
HashModifier 是一个文件hash修改工具,通过批量修改图片/视频文件的元数据(EXIF、IPTC、PNG 文本块等)来改变文件的 MD5 哈希值,同时保持文件的视觉内容完全不变。
Cookie Switch 是一个 Chrome 插件,为了解决同一浏览器中多个账号快速切换登录态的问题。
日常测试工作中,经常需要在多个账号之间来回切换,属于没什么意义的重复性劳动,反复登录退出账号实在效率低。
上一份工作是 TOB 的,现在干的是 TOC 的。两种不同的业务形态,测试工作的侧重点也会有所不同。
工作侧重点的不同的根源,当然就是来自业务本身:
| 维度 | TOC | TOB |
|---|---|---|
| 用户形态 | 个人消费者 | 企业等组织 |
| 发布节奏 | 快 | 慢 |
| 核心目标 | 增长、转化 | 稳定、交付 |
| 用户规模 | 大 | 有限 |
| 使用场景 | 多变 | 深度 |
| 需求特点 | 体验更重要 | 正确更重要 |
于是,测试目标就产生了区别: