社区 C 端质量体系建设思考？

询问一下 ChatGPT

1.1 社区端上功能

• Web 应用

• 原生应用

• 混合应用

基本了解一下端上技术栈也能帮我们在测试过程中有针对性的测试，同时为后续参与客户端 cr 做好准备 ，下面的具体案例中也能体现出来。

1.3 端上相关数据

通过质量大盘，用例平台和夜航星平台拉取的 2022 年社区的用例数，线下 bug 数、线上问题反馈数，这些数据能给我们在建设端上质量体系带来一定的参考价值。根据图中用例的占比和 bug 占比的趋势看，服务端用例发现 bug 率略低于客户端，分析发现服务端 bug 偏重逻辑，客户端一大部分都是 UI 交互相关，在提 bug 的颗粒度上有所区别。安卓端的 bug 数明显高于了 iOS 端，是不是说明了安卓端的质量要略差于 iOS 呢，因为受限于整年数据的无法精准下钻，只能在后续的版本迭代中观察注意。从反馈的线上问题来看，除了功能性 bug 以外，还有一部分是体验和兼容性问题很值得我们关注。iOS 的反馈问题数高于安卓，分析下来应该是线上问题反馈有一部分是内部反馈，因为内部同学使用 iOS 居多。

2022 年用例数

2022 各端 bug 数

2022 夜航星记录线上问题

2.1 功能测试

如图是一个产品质量模型，基于这些属性，结合用户、业务和产品特点等进行更深入的分析，以了解对质量的具体要求，哪些质量特性需要优先关注。例如社区的推荐流，属于内容消费类的功能，那么首先考虑的肯定是功能性可用，然后就是易用性（好不好用美不美观直接影响到了用户体验），接着就是要考虑兼容性、效率及性能等等。

最原始最有效的测试手段毋庸置疑到目前为止还是功能测试。作为专业的测试从业者都会有一套扎实的测试理论基础，也许会觉得这有啥可讲的呢～，但很多我们觉得理所应当的测试方法也恰恰是在一次又一次迭代中完善的。下面也是结合社区在端上测试实践及具体案例来总结一下端上的测试方法。

2.1.1 测试方法

在测试分析、设计、自动化测试中，会采用大量的测试方法和技术，但对于一个团队来说不一定掌握足够的测试方法和技术。另外，针对一个特定的项目或特定的功能，也不是把所有的测试方法都应用一遍，而是根据问题选择合适的方法。所以，针对测试方法和技术，也要做到知己知彼。

• 团队或团队成员目前掌握了哪些测试方法和技术？

• 当前项目采用什么样的测试方法和技术是更加合适的？

可以从不同层次、不同维度或角度去看。从高层次看，测试方法体现了方法论或流派。流派有基于逻辑分析的测试方法、基于上下文驱动的测试等；方法论有基于需求的方法，它涵盖了过去传统的黑盒方法（等价类划分、边界值分析等），而结构化方法涵盖了过去传统的白盒方法（语句覆盖、判定覆盖、条件覆盖等），但这样划分，在项目中没有多大的应用价值，而是根据方法的应用场景、技术特征来划分对应用者更有启发，例如以下划分。

• 基于直觉和经验的方法。

• 基于输入域的方法。

• 组合测试方法。

• 基于逻辑覆盖的方法。

• 基本路径测试方法。

• 基于故障模式的测试方法。

• 基于模型的测试方法。

• 模糊测试方法。

• 基于场景的测试方法。

在移动端的测试过程中，我们会发现它的复杂性越来越高，测试效率要比服务端低的多。因为是直接面向用户操作，那么就会涉及到不同机型不同系统，甚至是各种不同的操作手势和无法预知的用户行为，都会难以避免的出现测试遗漏。在这个过程中我们通过积累经验丰富我们的测试场景，结合线上监控尽可能的去发现并解决无法预知的问题。

那么具体会怎么去做呢？比如你拿到一个需求。需求分析 -> 用例设计 -> 测试 -> 验收（只列测试行为相关的），具体的用例设计方法就不列了，学过软工的都清楚。下面通过两个案例来讲一下。

• 案例 1

功能：优化负反馈选项，新增二三级类目

问题：返回三个标签时，第三个标签在 iOS 端无法点击。其余场景都正常。

拿到这个需求去测时，按照我们的经验，标签返回数 2、3、4 都会去测，然后大概率就是每个标签数中随机点击一两个测试一下接口传参及客户端功能。作为一个在原有功能基础上优化的小需求很容易忽视不会更详细的去测。很简单的一个全排列组合的算术，负反馈「不感兴趣」下全部点一遍就是（2+3+4）*2=18 次。那么当我们纯黑盒去测时，这个还属于有限可接受的数量级去全排列组合测，当遇到指数级的场景呢？这时候我们想到的是结合白盒，这个其实在去年的一篇博客中我也举过服务端的一个案例就是结合白盒去设计用例。可以看到下面 iOS 有问题的这段代码，就是行列的判断错误，导致在返回 3 个标签时，因为通过 column 字段去判断的话因为第二行第二列没数据，走到第一个判断条件 contentH=itemY，就会导致无法点击。

• 案例 2

功能：社区用户私信

问题：消息列表露出的不是收到的最新消息，而是自己发的最新消息

排查下来发现是因为本地时间调快了 5 分钟，落本地数据库时，自己发出去的消息对于接收到的消息来说是晚于对方消息的，那么在消息中心露出最新一条消息时就不能按照时间戳了。一般在测试过程中时我们设计的各种 case 逻辑基本都是基于正常时间的状态下测试的。但遇到这种和时间有关联的功能时，我们是很有必要去考虑本地时间不准的场景。

• 改进及后续 action

案例一，有限集的场景尽可能的多覆盖，可以像服务端一样去多了解客户端代码逻辑，尝试去 CR 客户端代码，同时更应该多体验多探索。这就是客户端和服务端比较大的一个区别，很多时候无法穷举所有的场景。

案例二，一些非平常用户习惯的场景很容易引发各种问题，对于我们排查问题也是带来了很大的困扰。通过这个案例也可以看出客户端的场景复杂度，或者在用例设计时比较依赖于测试、产品、开发的经验。

我们可以从三个大方向入手来补充我们的 case：

1. 传统的用例设计方法，参考等价类划分法、边界值法、因果图法、正交实验法等等

2. 结合白盒，通过熟悉了解客户端代码补充用例

3. 积累了解不同的用户习惯，根据不同的业务特点考虑其他可能影响因素

2.2.2 兼容性测试

关于得物 App 的兼容性测试，主要测试软件（APK、IPA）。所谓兼容性测试就是保证 App 在各种不同的手机品牌型号和各种不同的操作系统上能正常运行使用。也同时包括屏幕的分辨率、不同的网络环境。一般需要覆盖以下这些场景：

• 不同的操作系统，主流的 Android 和 ios 系统，包括华为的鸿蒙系统

• 各种系统版本

• 不同的手机品牌

• 各种手机分辨率

• 网络环境：WiFi、5G、4G、甚至是弱网环境

• 更细节点还可以测试不同的系统语言、不同的系统字体大小、系统权限等

（1）社区实践

在我们日常测试过程中，大家肯定会有疑问就是市面上有这么多品牌机型和系统，我们怎么在这快节奏的迭代中去挑选覆盖。这里我们使用得物 App 的手机品牌占比、系统占比以 DPM 线上监控数据为依据。

比如在社区我们会在每个版本提供当前线上占比高的机型和系统，UI 改动大的需求都会要求去测兼容性，其余场景自己酌情考虑。

（2）兼容提效

手工的兼容性测试方案基本没有更多的提效空间，通过工具平台能力来提效的思路有以下几个方向。

• 智能推荐

占比高的设备及系统可以接入 DPM 平台做智能推荐达到支持实时更新（目前社区算是实现了第一版，直接给出 top10 的，后续可以结合云真机平台使用）。

• 得物云真机 - 效能组实现

可以搭建 top5 的设备及系统支持同步执行同一套 UI 自动化脚本，同时可以引入支持图像算法来判断不同机型不同系统相同页面的 UI 是否一致。

得物云真机可以支持测试使用，同时可以考虑支持同步操作多态机器来测试兼容性。

• 引入 AI 测试，简单了解了下市面上的 AI 测试框架，目前看来真要落地使用还是有段距离。

（3）第三方平台

使用 testin 平台去测试我们没有的机型 or 系统，提供 testin 兼容性测试用例，让第三方测试团队帮忙覆盖更多的机型系统。

2.2.3 探索性测试

探索性测试（Exploratory Testing）是软件测试方法的一种，它的特点为在进行测试时，同时探索开发更多不同型态的测试方式，以便改善测试流程。当软件开始测试流程后，一般测试者会使用预先设立好的测试案例来进行程式测试，而探索性测试就是为了弥补传统的案例测试的缺点而产生。

探索性测试这个词是由 Cem Kaner 在 1983 年提出。他将探索性测试定义为：一种强调个人自由与责任的测试方法，让独立的测试者可以借由不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时的改善专案达到相辅相成的效果。

（1）社区实践

探索性测试主张学习，强调同时展开测试设计、执行、并从结果中获得反馈，从而持续优化测试。这里在社区实践过程中更是结合了集思广益，大家扮演不同的用户角色去体验探索自己不熟悉的功能。功能的负责人会简单介绍一下功能的特性，下面就是靠大家快速学习该功能、即兴发挥、动态调整测试策略，去发现一些因被思维固化或者数据差别等各种原因出现的遗漏。在过去一年的实践中，我们也发现了很多有效 bug，在去年也是因此避免了一个线上资损问题的扩大。

2.2.4 用户体验

在社区是会鼓励大家多体验得物 App，包括在 OKR 中也是会制定对应的目标，白冰冰的凝视也会每天提醒大家前一天的社区使用时长。体验问题我们在 RDC 上有专门的任务看板来记录跟进优化进度，可以看到 Q1 提了 46 个体验问题。

2.2.5 测试工具

端上测试也会用到很多辅助工具来帮助我们更有效的去测试，比如常用的抓包工具，adb 命令，ideviceinstaller 命令，安卓调试工具 Flipper，iOS 视图工具 Lookin 等。这节不介绍 UI 自动化和性能工具，只介绍一些社区在功能测试中使用到的工具。

（1）内部开发者工具

常用的

• 环境切换

• ab 值修改，这里介绍下 ab 一键改为所有实验或者对照组的功能，可以一定程度上的测试到遗漏的实验或者交叉实验的功能影响

• 缓存修改，这个功能可以方便大家不用一直去卸载重装去测缓存类的功能

1. 安卓，开发者工具 -> 交易 go -> MMKV

2. iOS，开发者工具 -> 沙盒 -> Library -> Preferences -> com.siwuai.duapp.plist

（2）开源主流工具

• 抓包代理类：Charles、fiddler、wireshark 等

1. 可以查看接口请求参数

2. mock 接口

3. 弱网模拟等

• 安卓 adb  官方文档->>

Android 调试桥 （adb） 是一种功能多样的命令行工具，可让您与设备进行通信。adb 命令可用于执行各种设备操作，例如安装和调试应用。

• ideviceinstaller 官方文档->>

1. 常用于 iOS 的快速装包 ideviceinstaller --install <file>

• 安卓调试工具 Filpper

1. 涉及到客户端数据库相关的可以使用该工具来辅助验证。

2. 还有缓存修改、日志查看、路由跳转、图像等详细功能查看之前写的博客。

• iOS 视图工具 Lookin 官方文档->>

Lookin 可以查看与修改 iOS App 里的 UI 对象，类似于 Xcode 自带的 UI Inspector 工具，或另一款叫做 Reveal 的软件。

2.2.6 问题排查

客户端出现了问题，排查的思路和服务端有所区别。因为考虑到一些交互场景会和手机型号、系统等影响，一般都需要清晰了解到反馈问题用户的客户端版本、手机设备及系统相关信息。这里一般的排查思路：首先是按照用户描述的问题，查看该功能是否是必现问题，如果不是然后再去尽可能的使用和用户一样的手机及系统去操作。无法复现的问题，这时候我们也可以通过 DPM 去查看用户的行为路径（有点类似于服务端的 trace2.0）。

这里举个通过用户行为路径定位到问题的案例

问题：收到关注的人更新内容 push，点进去后 landing 到了推荐流。（功能应该是 landing 关注流并且把更新的动态内容强插到第一位）

排查过程：

• 查看是否是必现的普遍性问题及功能 bug - 不是

• 查看是否为兼容性问题，使用对应的客户端版本及手机系统 - 未复现

• 查看日志，确认实验组和对应时间的 push 记录，确保用户反馈问题的真实性，结果发现实验是对的，push 记录也有，但从日志分析的确是没有调用关注流接口  - 未复现

• 查看用户在该时间段内的操作路径，试着按照同样的操作去复现 - 成功复现

如截图从行为路径可以看出，用户先是冷启 app，在 lauch 页面直接压后台，然后过了段时间后通过 push 唤起 app。试着复现，经过反复测试验证，发现在冷启后出现广告页时马上压后台，然后再点击收到的个性化推荐 push，就能稳定复现该问题。排查下来因为这时候 app 需要把上次未执行完的冷启动代码执行完，导致推送的跳转逻辑不执行。

因为客户端的多样性，给开发测试排查问题造成了很大的困难，当遇到难以复现的问题时，尽可能的还原用户一样的环境和用户行为，因为大家都明白所谓的非必现 bug 其实只是我们没有找到必现路径而已。比如之前还有遇到过因为用户开启了省电模式而引发的 h5 渲染加载问题，这个问题我们在各种设备上怎么也复现不出来，但只要打开了省电模式就很容易复现出来。

2.2 UI 自动化

说到 UI 自动化框架，大家多多少少都了解使用过一些，这里简单列几个相对比较流行的开源框架，做简单的对比介绍。同时也介绍一下社区现在使用的和目前在社区 UI 自动化的开展情况。

（1）自动化框架

（2）社区实践

社区也是从一开始的 appiumn 、airtest到如今统一使用内部自研的UI自动化平台 Teslalab 平台。

在社区，目前会按照各自负责的业务模块划分去编写 UI 自动化脚本，并绑定对应的 BVT case。每个版本绑定转测单，会统一在提测后+预发线上回归两个时间段去执行。目前使用下来的效果，通过自动化发现的bug主要集中在提测后的冒烟阶段，相当于代替手工提前做了核心功能的回归。

2.3 性能测试

客户端的性能和服务端的性能还是有很大的区别，从性能指标出发就有很大的不同。服务端基础指标：QPS、RT、CPU、内存等；客户端性能基础指标通常会关注：CPU、内存、FPS、秒开、视频卡帧率、耗电、耗流等。因为现在手机的配置越来越高，性能一般都是过剩的，大家也许会慢慢的不太关注这些指标。但在我们使用的过程中，是不是出现过在使用某个 app 时出现手机发烫、滑动某个页面不流畅等问题？其实这些都是性能问题，CPU 占用过高会使手机发烫卡顿，缓存数据不及时释放导致内存占用升高，FPS 过低导致页面滑动流畅度低等都会极大影响用户体验。性能测试一般都在功能测试验证完成后进行，不然过早的介入性能测试意义不大。

（1）常用的性能测试工具

2.4 稳定性测试

一款软件的好不好用，最基本的要求应该就属于稳定性。试想一下，当你在一款 app 上操作时，某些有流程性的用户行为，比如你要下单买东西，或者实名认证操作，进行到一半， app 突然 crash 了，这时候你的心情。根据业界的统计，app 闪退率越高，活跃用户下降趋势越明显，所以对于 app 进行稳定性测试至关重要。

说到稳定性测试，大家比较熟悉的就是 Monkey，常被用来做安卓端的随机压力测试。但考虑它不支持 iOS，还有就是会出现意想不到的跳出 app 的问题，在实践中放弃。在社区我们通过深度遍历的方式来测试稳定性，目前也是在实践过程中遇到了比如各种弹窗的干扰等，也是不断的优化改进中，包括在未来我们希望能做成一套通用的工具，支持在平常的业务测试过程中，只针对于自己负责的模块业务相关的页面去做一些随机性的交互测试。

（1）常用的稳定性测试工具

2.5 安全性测试

在移动互联网时代，智能机的普及使得 app 被广泛使用，应用的安全问题直接关系到公司和用户的切身利益。列举一些 App 容易出现的安全问题：

• 接口的明文通信，通过抓包工具可以直接获取到接口返回的敏感信息

• 没有接口验签或者验签被破解，造成接口拦截后数据篡改

• 用户隐私，登录密码，支付密码等敏感信息的明文保存或者展示

• app 所在的文件权限是否允许被其他 app 的读取

• apk 的逆向破解等

对于端上的质量体系建设，我们整个团队包括开发产品一起在做不断的努力。我们在满足于基础功能的测试同时，也是在不断的探索实践，通过各种工具手段，不同的测试思路来尽可能的保障 app 质量，并且也是不断的注重用户体验。有些已经起步做起来了，也是有了明显的收益比如兼容性测试、探索性测试、端上体验等；也有些做起来了，但目前还没有很明显的收益比如稳定性测试、UI 自动化；还有没有开始的安全性测试也是未来的考虑方向。

端上的测试远远不止于此，该篇文章也是结合社区现在端上测试现状做的经验总结分享，上述无论是哪一块内容都可以单独拎出来做一个专题去讨论，也是欢迎大家一起交流学习，可以直接在评论区留言，促进互相学习。

活动推荐

*文/ dhk

关注得物技术，每周一三五晚18:30更新技术干货