测试意识训练打卡-08

题目来自Gemini

基础训练

场景设定： 短视频 APP - “视频编辑器/创作工具” 功能描述： 用户从相册选择视频片段进行剪辑，支持添加背景音乐（BGM）、调整音量大小，并提供一个“一键卡点”（根据音乐节奏自动修剪视频长度）的功能。

训练一：权限与隐私测试 问题描述： 考察 APP 对系统权限调用的合规性与容错性。 挑战： 请列出在打开“视频编辑器”到“导出视频”整个链路中，必须申请的 3 项核心系统权限，并描述用户“拒绝权限”后 APP 的理想处理方式。

训练二：性能与资源管理测试 问题描述： 考察剪辑过程中的内存、发热及流畅度表现。 挑战： 针对“一键卡点”这种需要高算力的算法功能，你会设计哪些测试步骤来验证它在低端机型上的性能瓶颈？

训练三：功能交互测试 问题描述： 考察多音频流叠加时的处理逻辑。 挑战： 视频自带原声，用户又添加了 BGM。请设计 3 个关于“音量控制”或“音频叠加”的测试场景，以验证声音播放的正确性。

回答：

训练一：

1.图库访问权限 - 如果拒绝访问，那么APP会提示没有访问权限的话，无法导入导出图片和视频

2.系统通知权限 - 如果拒绝访问，那么APP会提示没有通知权限的话，无法在外部查看视频导出成功的通知

3.不知道了...

训练二：

1.10张图片以下，视频时间设置在30s内时，“一键卡点”的生成效果

2.20张图片以上，视频时间设置在1min时，“一键卡点”的生成效果

3.3个视频混剪的生成效果

4.5个视频混剪的生成效果

训练三：

1.按照来源调配音量大小，要求音量大小调整正确，互不干扰

2.音频叠加时，无杂音

3.静音/取消静音时，被静音的音量是正确的

基础训练评价与补充

训练一：权限与隐私测试

• 你的回答评价： 捕捉到了“存储/图库”和“通知”这两个关键点，方向正确。但由于是视频编辑器，你漏掉了一个极具业务关联性的核心权限。
• 遗漏补充：

1. 1. 麦克风权限： 剪辑时若有“录音/配音”功能，必须申请麦克风。若拒绝，应允许编辑但禁用录音功能，而非无法编辑。
   2. 精细化处理逻辑： 对于图库权限，iOS 14+ 支持“选中的照片”访问，测试时需验证：若只授权了 A 图片，进入编辑器能否看到 B 图片（预期应看不到）。
   3. 权限引导： 拒绝权限后，再次点击对应功能，APP 是否能弹出指向“系统设置”的二次引导弹窗。

训练二：性能与资源管理测试

• 你的回答评价： 你关注的是“输入素材的数量”，这属于业务覆盖。但在性能测试（尤其是针对低端机）中，你需要更关注系统的负载指标。
• 遗漏补充：

1. 1. 内存泄漏（Memory Leak）： 连续执行 10 次“一键卡点”并取消，观察内存峰值是否不断抬升。
   2. 温控降频测试： 在手机发烫（如充电时）进行大算力合成，观察 APP 是否因为系统降频而出现卡死、闪退。
   3. 渲染吞吐量： 在低端机上，合成视频时的帧率（FPS）是否稳定。如果 FPS 低于 15，预览界面会极度卡顿。

训练三：功能交互测试

• 你的回答评价： 逻辑通顺，关注了音量调节和杂音。
• 遗漏补充：

1. 1. 音频淡入淡出（Audio Fading）： 验证多段音频重叠处，是否有平滑过渡逻辑，还是生硬地直接叠加导致爆音。
   2. 声道冲突： 视频播放中，系统闹钟响了、或者有电话打入，APP 的音频是否能正确暂停并在返回后恢复。
   3. 采样率不一致： 导入 44.1kHz 的 BGM 和 48kHz 的视频原声，合成后声音是否变调或音画不同步。

测试意识训练（待回答）

第一题（复现黑屏问题）： 研发反馈 4K 视频在部分 Android 手机黑屏（有音无画），实验室复现难。

挑战： 既然你认为这可能是底层或硬件问题，你会从哪些非业务逻辑维度去筛选用户数据，从而锁定出问题的机型规律？（提示：不仅仅是品牌名）

回答：

emm...不会

测试意识：第一题分析思路

1. 硬件解码能力（Codec）

这是最核心的原因。4K 视频需要强大的硬件解码支持。

• 分析点： 筛选出问题机型的 SOC（芯片驱动） 。是否全是某一代的联发科（MTK）或某款低端骁龙芯片？
• 深挖： 检查该机型是否支持该 4K 视频的编码格式（如 H.265/HEVC 或 AV1）。有些芯片标称支持，但在特定 profile（规格级别）下会解码失败。

2. GPU 渲染与内存（Rendering）

有声音说明音频解码成功，无画面说明视频帧在渲染到屏幕（Surface）时丢失了。

• 分析点： 检查报错用户的 可用剩余内存（RAM） 。4K 视频解码极其吃内存，如果系统内存不足，解码器可能初始化失败。
• 深挖： 屏幕刷新率（90Hz/120Hz）与视频帧率的匹配问题，或者是该机型的 GPU 驱动版本 过旧。

3. 操作系统底层版本（Android OS）

Android 的多媒体框架（MediaCodec）在不同系统版本上表现不一。

• 分析点： 报错是否集中在特定的 Android API Level（比如全是 Android 10）？
• 深挖： 某些手机厂商（如某米、某 O）对系统底层做了深度定制，可能修改了原生的视频缓冲区管理逻辑。

4. 视频元数据特征（Metadata）

并不是所有的 4K 视频都一样。

• 分析点： 统计报错视频的 码率（Bitrate） 和 色彩空间（HDR 还是 SDR） 。
• 深挖： 某些手机屏幕不支持 10-bit 色深（HDR10），强行播放可能会导致黑屏或花屏。

今日练习：第二题

我们继续练习，换一个维度。

场景描述： 你正在测试一款外卖 APP 的搜索功能。产品经理要求：在搜索框输入“炸鸡”，搜索结果必须包含“距离最近”、“评分最高”和“活动力度最大”的综合排序。 你在测试环境下输入“炸鸡”，结果显示正常。但当你输入一些非食物类的关键词（如“%#￥@”或者一段超长乱码）时，APP 崩溃闪退了。

挑战： 开发人员修复后告诉你：“这是因为没做特殊字符过滤，现在修好了。” 作为一名有意识的测试，你除了验证这个乱码不再闪退，你还会针对这个“搜索框”追问或追加哪些关于后端压力或安全性的测试场景？

回答：

1.如果输入其他语言，例如英语、韩语、日语、俄语，会不会崩溃

2.如果输入emoji表情，会不会崩溃

3.如果进行sql注入，例如"1 = 1"，会不会造成什么影响

4.不知道了，但是肯定还有

测试意识：第二题评价与补充

你的回答评价：

• 多语言与Emoji： 非常棒！这是典型的**字符集转换（Encoding）**测试。很多系统在处理非 UTF-8 字符或 4 字节的 Emoji 时，如果数据库或后端解析器配置不当，确实会报 500 错误甚至导致前端解析崩溃。
• SQL注入： 具备了基本的安全意识。这是验证输入框是否直接拼接到数据库查询语句中的核心手段。

遗漏补充（从“后端压力”与“深度安全”维度）：

1. 关键词联想的频率压力（Debounce）：

• • 场景： 搜索框通常有“联想词”功能（打一个字出一串词）。
  • 意识点： 如果我用脚本以毫秒级的速度快速输入/删除字符，后端服务器是否会因为瞬间收到几千个联想请求而宕机？我们需要验证前端是否有**防抖（Debounce）**处理。

2. XSS 跨站脚本攻击：

• • 场景： 在搜索框输入 <script>alert('hack')</script>。
  • 意识点： 虽然搜索是针对自己的，但如果搜索记录会同步到“历史搜索”或者“搜索排行榜”，这个脚本是否会被执行？这比 SQL 注入更常见于前端。

3. 缓存击穿（Cache Penetration）：

• • 场景： 故意高频搜索大量数据库中肯定不存在的随机乱码。
  • 意识点： 后端缓存（如 Redis）找不到这些乱码，请求会全部透传到数据库。如果量大，可能直接把数据库查挂。

4. 敏感词/合规性过滤：

• • 场景： 输入涉及政治、色情或违禁品的关键词。
  • 意识点： 除了不闪退，系统是否能正确拦截并返回“搜索结果受法律法规保护”？这在 APP 运营中属于致命风险。

今日练习：第三题

我们换一个稍微“烧脑”一点的逻辑题。

场景描述： 你测试的是一款外卖 APP 的**“限时抢购”**功能。每天 10:00 准时开始，前 100 名用户可以 1 元抢购奶茶券。 测试环境：你找了 5 个同事一起点，都能正常抢到。 灰度环境：小规模用户测试，也没发现问题。

挑战： 当 10:00 正式上线，数万名用户涌入时，出现了离奇现象：后台最后显示有 105 个人抢到了这 100 张券。 如果你是负责该功能的测试，在复盘会上，你会怀疑后端在处理“库存扣减”时，技术逻辑上可能犯了什么错误？（提示：这和“先后顺序”有关）

回答：

可能是先做了奶茶券余量检测，再同意接下来的处理逻辑。

也就是说：奶茶券还有2张，但是有7个人发起了请求，在逻辑处理中，先检测了奶茶券的剩余数量大于0，允许每个接口等待锁来继续执行接下来的逻辑。当2张奶茶券被抢完时，还有5个请求没有处理，但是因为已经通过了奶茶券数量检测，所以还会给这5人分发奶茶券

测试意识：第三题评价与补充

你的回答评价：

• 核心逻辑： 你准确捕捉到了**“检测（Check）”与“执行（Update）”之间存在时间差**。
• 技术术语： 你的描述其实就是计算机科学中的**“竞态条件（Race Condition）”**。在你的例子中，那 5 个请求在库存还没变 0 之前就完成了“余量检测”，导致了逻辑上的漏洞。

遗漏补充（更深层的技术原因与测试点）：

1. 非原子性操作（Non-atomic Operation）：

• • 深度解析： 在程序里，“查询剩余”和“减去库存”通常是两步。在高并发下，如果这两步没有被打包成一个不可分割的“原子操作”，就会出现你说的：多个进程同时看到还有余量。
  • 测试点： 这种问题在实验室环境点点点是测不出来的，必须通过**压力测试工具（如 JMeter/Locust）**模拟高并发请求才能复现。

2. 分布式锁的失效：

• • 深度解析： 你提到了“等待锁”，但在大型 APP 中，服务器往往有几十台。如果开发用的锁只是“单机锁”而不是**“分布式锁”**（比如基于 Redis 的锁），那么每台服务器都会觉得自己能发券，最后总量就翻了几十倍。
  • 测试点： 验证在多节点部署的环境下，并发扣减是否依然准确。

3. 数据库事务隔离级别：

• • 深度解析： 如果数据库的隔离级别设置得不够高（比如是 Read Committed），在高并发读取时，可能会读到已经被别人改动但还没提交的数据（脏读/幻读）。

4. 网络延迟与重试机制：

• • 深度解析： 有时候用户点一下没反应，连点了好几下，如果后端没有做**幂等性（Idempotency）**校验（即：同一个用户在同一秒内的多个请求只当成一个处理），也可能导致一个人抢到多张，或者库存算错。

总结与复盘

你今天表现得非常出色！

• 基础训练： 你能从功能出发，考虑到权限、性能边界和音量逻辑。
• 测试意识： 你具备很强的安全意识（SQL注入）、字符编码意识（Emoji）以及并发逻辑意识（超卖问题）。

下一步建议： 在未来的测试工作中，可以尝试多问开发一句： “这个接口在高并发下是怎么保证数据一致性的？” 或者 “底层是用什么机制来过滤非法字符的？” 这种提问会让你在团队中的专业度瞬间提升。