【测试】
一、用例编写
前期需求理解很重要，这是编写测试用例的第一步，好的测试用例将让测试事半功倍。
- 覆盖基本的功能（需求上需要的）；
- 尽可能多的分支流（常规操作）；
- 尽可能多的异常流（非常规操作）
- 新功能对原有功能影响的相关范围回归用例；
- 执行步骤简单易懂，描述清晰，旨在达到到换个人可执行的程度；
二、app测试
- 翻页：翻页是经常出现的问题的一个地方，问题现象：
- 传参错误，导致拿不到数据或者数据重复；（案例：小视频翻页是传参lastId，这个id传入的并不是当前页的最后一个，导致后一页数据和前一页有重复）
- 无更多数据，但一直显示加载中；
- 无更多数据，前端未做处理，还能去触发翻页调用接口；
- tab切换：滑动切换和点击tab切换，边界要测试，可能出现滑动不了的情况，可能出现滑过去滑不回的情况；(主播主页)
- H5和native间的跳转要留意多层嵌套，可能出现死循环（案例：小视频播放页进入个人主页）
- 视频测试的话关注native-h5跳转，声音是否关闭；切后台、锁屏，音频停止；返回到视频播放页，音频恢复。
- 适配保证每个系统覆盖，屏幕大小；关注截断展示，换行展示，多观察小屏手机；
- 易用性、流畅性：按钮点击区域（返回按钮）、列表滑动、翻页
- 暴力测试，是否crash、卡死？（频繁进出直播间、播放页；多次锁屏、切后台）
- 性能观察，必要的测试场景：
- 页面加载完成时间；
- 视频播放；
- 图片改动，减少压缩提高分辨率；
- 观察参数：
- 页面进入白屏到渲染时间；
- CPU、内存、耗电、流量
- 权限问题：悬浮窗、录音、相机/相册。实例：
- 未开启拍照权限时点击录制按钮crash；
- （android）未开启悬浮窗时跳转webview，webview盖住了悬浮提示 ；
三、数据问题
- 前后台同步：例如后台新增或者修改，评论、点赞，或者内容信息；
- 状态：后台操作下架后前端仍然展示的，可能没触发缓存或者没实时；
- 数据展示：例如前端显示10条，但实际站展示了8条，后台频繁操作数据状态，服务端过滤逻辑不完善
四、版本控制
针对某些需求需要做版本控制（例如直播间左侧运营位），这些在设计评审时要确定是谁来做，并达成约定
- 服务端做：老接口新字段、新数据
- 客户端做：新版本才支持的，例如直播间新加的运营位，只有新版本才识别的subType
- 不需要做版本控制的，则必须要回归老包，确保新功能在老包上正常，例如安卓 apk（旧包要更新apk）
【发布】
一、checklist
- 本次发布功能（重要）
- 应用
- 发布顺序
- 是否有依赖（如果有外部依赖一定要和依赖方沟通好）
- 发布前/后数据准备
二、发现问题怎么办？
杜绝隐藏，及时暴漏，通知项目经理、测试leader、产品，评估问题影响：
- 可接受的（重要不紧急/不重要不紧急）作为遗留问题后续修复发布；
- 必须修复的，且修复成本低的打回修复后再发布；
- 必须修复的，但修复成本大，提前申请延期发布，尽量赶上当次发布；
三、未能按时发布怎么办？
发布日会有一个最终发布时间节点，提前会预估是否能按时发布，如果可能超过发布时间，提前邮件申请延后发布。
【排期】
- 根据需求评估测试范围，可能简单的需求实际影响的范围较大，预留的测试时间需要多一点（原创、加V）
- 资源紧张的情况下需求评估优先级；
- 测试排期并不能完全对照开发的时间来，可能有的需求开发起来简单（字段加减），但测试范围大，按实情考虑；
- 一般按照冒烟、功能（一轮）、bug fixed、适配、回归的时间来排，通常功能测试和bug fixed验证同步进行；
网友评论