客服团队如何在多台真实安卓手机上复现问题

一个实用支持工作流程，可将特定设备的Android投诉转化为可重复的案例、证据包和有用的工程移交。

为什么支持团队保留不止一台安卓手机

客户可以准确地描述故障，但支持团队仍然无法重现故障。应用程序版本可能是正确的，但问题只出现在一个制造商构建、Android版本、显示屏尺寸、权限状态、语言、网络或电池策略上。单一参考手机无法代表该范围。这就是为什么移动支持团队经常保留一小组真正的安卓手机，即使工程部门已经使用模拟器和自动化测试。

目标不是拥有每个模型。而是保持足够的覆盖率，以快速回答三个问题：团队是否可以复制报告，什么条件触发了报告，以及哪些证据可以让工程人员继续工作而不重复整个支持对话？AWS Device Farm同样将客户支持代表与开发人员和QA团队一起识别，并将实际设备交互描述为调试和复制客户问题的手段。

• 认证、付款、通知、权限、摄像头、蓝牙和后台处理失败。
• 在特定屏幕密度、字体缩放、语言或导航模式下崩溃的布局。
• 与安卓版本或制造商固件相关的升级或安装问题。
• 仅在网络更改、App 后台运行、电池限制或中断后才会出现的问题。
• 客户报告需要在升级前提供屏幕截图、简短录音、设备详细信息和准确的复制步骤。

在选择手机之前，请收集最低限度的保护壳数据。

不要先点击随机手机开始。首先，将支持对话转换为可测试的案例。缺少的入库数据浪费的时间比物理设备设置还多，因为团队无法区分设备特定的缺陷和帐户、构建、网络或过期数据问题。

如果客户无法提供所有信息，请记录所不知道的内容，而不是默默填补空白。支持团队仍然可以测试已知路径，但工程团队应该能够看到哪些假设被做出了。切勿要求客户发送密码、付款详细信息、身份证件、私人消息或与之无关的个人文件。

从客户证据中构建一个小型设备矩阵

一个有用的支持台是基于客户实际使用的设备，而不是一个充满吸引力的旗舰手机架子。从分析、故障报告、票据数量和收入关键细分市场开始。选择一款低端设备、一个常见的中端型号、一部最近的旗舰手机，以及任何在未解决的情况下反复出现的制造商或安卓版本。

1. 从可靠的产品数据中导出顶级设备型号和Android版本。
2. 按制造商固件、性能级别、屏幕特性和操作系统版本将类似设备分组。
3. 选择覆盖重要案例最大份额的最小物理集。
4. 只有当票据或产品风险足以证明维护成本合理时，才应添加模型。
5. 每季度回顾矩阵，并淘汰不再代表有意义流量或风险的设备。

三到六台电话台通常比一个大型未维护的收藏品更有用。更广泛的兼容性仍然可以运行到云服务。本地台用于快速交互式复制、支持演示和重复使用相同设备的情况。有关物理设置，请参阅低成本安卓设备实验室指南。

整理多台电话支持台

每部手机都需要一个稳定的身份。给它一个短代码，在物理上贴上标签，并记录其型号、Android版本、上次重置日期、电池状况、连接方法、安装的测试构建和分配的测试帐户。当几部手机共享一台电脑时，请使用可靠的电缆和带电源的USB集线器；不稳定的电源和损坏的电缆可能会导致看起来像应用程序缺陷的故障。

控制多个安卓手机当团队需要比较屏幕、在设备之间移动或重复授权设置步骤时，从一个共同的工作区开始。 铟莱彩投屏，设备可以从一个Windows或macOS工作站上可见，因此操作员花费的接听电话时间更少，比较案例状态的时间更多。分组对于分离干净的基线、活跃的支持案例、低端设备和等待重置的手机很有用。

• 保留一个已知良好的基准设备进行比较。
• 尽可能使用带有合成数据的专用测试帐户。
• 在前一个状态可能会影响结果的情况下，在案例之间重置 app 数据。
• 在每个屏幕截图或案例备注中都清楚地显示电话代码。
• 记录充电、USB、Wi-Fi 和温度状况，这些状况会影响测试。

运行一个受控的复制过程

通往有用的结果的最快途径通常是受控的比较，而不是大量同时进行的操作。从最接近匹配的设备开始，重现客户的初始状态。运行报告的步骤一次，不要改变任何内容。如果出现问题，重复它以确认频率。如果没有出现问题，一次更改一个变量：网络、权限、语言、应用程序数据、安卓版本、制造商、字体大小或电池策略。

1. 创建案例卡，其中包含电话代码、App 构建、帐户类型、网络、语言和启动屏幕。
2. 在最近的匹配手机上复述客户的具体步骤。
3. 在已知良好的基准手机上重复相同的步骤。
4. 仅更改一个疑似条件，然后重新运行该路径。
5. 当触发器被隔离或达到商定的尝试限制时，停止。
6. 写下成功和失败的尝试；负面证据会缩小下一次调查范围。

当设备已经分开时，请勿使用同步输入。权限对话框、加载缓慢、键盘或更新提示可能会将相同的点击传递到不同的控制器。共享操作只有在每个选定的手机都明显处于相同的安全状态时才有用。否则，请单独操作设备，并保留您试图理解的差异。

创建一个证据包，工程人员可以重播

一个有用的交接足够小，可以快速审查，足够完整，可以重播。一张票应该连接环境、步骤、观察到的结果、预期结果和支持证据。屏幕截图证明了静态状态；简短的屏幕录制证明了时间和顺序；日志解释了界面无法显示的内容。这些都不取代其他内容。

给文件命名时，请注明票证ID、电话代码、版本号和时间戳。接管过程应让工程师在几分钟内理解故障，无需打开多个聊天线程。有关更广泛的QA工作流程，请参阅用于移动应用程序测试的Android屏幕映象。

选择本地电话、模拟器或云设备服务

这些工具解决了不同的覆盖问题。本地电话台不能取代云设备农场，云实验室也不能消除支持团队旁边熟悉的手机的价值。选择能够忠实地复制条件的最便宜的环境。

一个实际的顺序是先用模拟器进行快速的无效性检查，用本地手机检查可能的真实设备原因，如果模型丢失或需要更广泛的确认，则使用云设备。在PC或Mac上进行Android屏幕映象当支持需要直接对本地电话进行视觉控制，而不是对分布式企业车队进行策略管理时，它是最有用的。

在复制过程中保护客户数据

如果流程不小心，实际设备故障诊断可能会暴露个人信息。默认情况下，使用合成帐户和测试数据。如果确实需要生产数据，请获得适当的授权，限制访问权限，仅捕获案例所需的内容，并遵循公司的保留政策。AWS同样警告其设备服务用户不要输入帐户凭据、个人信息或其他安全敏感详细信息，因为会话可能会产生日志和视频。

• 切勿将客户的密码、付款信息、身份验证令牌、私人照片或身份证件复制到实验室手机中。
• 在附上证据之前，请模糊或裁剪与之无关的姓名、消息、电子邮件地址和帐号。
• 根据环境将测试帐户分开，并根据公司政策轮换凭证。
• 在保留期结束时，删除屏幕截图、录音、日志、下载文件和应用程序数据。
• 记录在政策要求审计记录时，谁访问了敏感案例以及为什么。

使用三部手机试用工作流程

不要从购买一墙的手机开始。选择一个定期支持案例类别和三个代表性设备：已知良好基线、最常见的客户手机和对比鲜明的低端或特定制造商的手机。运行工作流程两周，然后决定是否需要另一个设备或云服务来解决试点人员无法处理的案例。

1. 选择十张最近因设备不确定性而延误的票。
2. 定义所需的输入字段和一个单个证据包模板。
3. 给三个手机贴上标签，并准备好带有干净测试帐户的手机。
4. 跟踪到首次有意义的重复、澄清循环、升级接受和未解决的设备差距的时间。
5. 回顾哪种手机或环境条件实际上改变了结果。
6. 只有当证据表明存在重复的覆盖差距时才应扩大。

要验证的结果很简单：支持工程师应该能够接收一个案例，选择一个合适的电话，重播路径，并提供一个独立的接管，而无需搜索几个无关的系统。如果共享的本地工作区有助于该试点，莱彩投屏可以从一个Windows或macOS计算机上保持所选的安卓手机可见并可控。

常见问题

支持团队需要多少部安卓手机？

从实际票据和使用数据中选择三到六部手机开始。只有在重复且重要的案例无法由当前矩阵或偶尔的云会话覆盖时才添加设备。

是否应支持重现每个客户报告？

不。优先考虑严重程度、受影响的用户、业务影响、安全风险、复发情况以及重现是否会改变下一步行动。设备实验室是一个决策工具，而不是每次都重现模糊的投诉的要求。

同步控制能否同时在所有手机上复制一个错误？

只有当设备明显处于相同状态且操作安全时。一旦时间、对话框、权限、键盘或布局不同，请单独操作手机。差异是证据，而不是盲目点击的东西。

LaiCai是否取代了移动设备管理平台？

不。莱彩投屏是一个本地视觉控制和工作流程工具。需要零接触注册、政策执行、应用程序分发、库存或远程擦除的分布式企业车队应使用适当的MDM或EMM系统。

来源

• AWS设备农场常见问题解答
• AWS设备农场开发者指南
• OpenText移动和Web功能测试实验室
• 三星远程测试实验室
• 谷歌Android企业支持指南