测试用例

测试用例包含的内容

  • 优先级
  • 模块
  • 用例名称
  • 前置条件
  • 测试步骤
  • 预期结果
  • 实际结果

  • 执行人

    对一个物品设计用例，要考虑哪些维度？

  • 需求测试

  • 功能测试
  • 界面测试
  • 可靠性
  • 安全性
  • 可移植性
  • 兼容性
  • 易用性
  • 压力测试

    测试流程与计划

    常见的测试流程

  1. 理解测试需求文档
  2. 产品经理组织评审需求文档
  3. 交互设计师组织评审交互稿
  4. 视觉设计师组织评审视觉稿
  5. 编写测试计划
  6. 编写测试点、测试用例
  7. 组内评审测试用例
  8. 执行测试用例
  9. 输出测试报告
  10. 版本复盘会议

    制定测试计划的目的

  • 明确测试范围
  • 制定测试策略
  • 预估工作量
  • 分配测试资源
  • 测试进行可控，实时知道目前测试完成情况

  • 可以提别识别风险、当需求变更后要做出响应

    测试计划包含的内容

    前期准备

  • 分配测试资源

  • 准备测试工具

  • 准备测试数据

    测试范围

  • 被测对象

  • 主要测试内容

  • 明确测什么，不测什么

    测试策略-明确测试类型

  • 功能测试

  • 兼容性测试
  • 接口测试
  • 拓展测试
  • 交叉测试
  • 自动化测试

  • 性能测试

    确定以下几个时间

  • 验收时间

  • 提测时间
  • 测试时间

  • 发布时间

    确定以下几个内容

  • 版本改动范围

  • 影响范围，评估哪些模块需要回归
  • 正常送测范围
  • 是否有延期送测的内容

  • 是否有发布风险

    测试风险评估

  • 预估测试过程中可能存在的潜在风险，以及风险发生时的应对策略

    缺陷相关

    提交一个缺陷应包含的内容

  • 标题

  • 缺陷类型
  • 优先级
  • 影响模块
  • 标签
  • 严重程度
  • 出现频率
  • 环境配置
  • 操作步骤
  • 实际结果
  • 期望结果

  • 附件

    开发人员说着不是一个 bug，如何应对？

  • 首先，详细描述自己认为这是缺陷可能产生的风险和影响

  • 其次，询问开发认为不是 bug 的原因，自行判断开发讲的是否合情合理
  • 若无法判断，则查看需求文档、交互稿等内容，确认当前实现是否符合预期
  • 最后，可以叫上产品经理、项目经理共同讨论、评估

  • 注：作为测试一定要有自己的判断和立场，需要表面自己对这个问题的看法(严重程度、影响范围)

    版本紧急又重要，但有已知缺陷未修复，要发布如何处理？

    从几个维度去评估问题是否影响发布：

    1、出现概率

  • 是否必现？

  • 偶现的概率

  • 偶现概率低可以考虑延期修复

    2、影响范围

  • 出流程 or 异常场景

  • 主要功能 or 次要功能
  • 若是主流程，是否影响正常功能使用

  • 若是界面效果不如意，是否能接受？

    3、是否有规避措施

  • 技术上是否有规避手段

  • 交互上能否提醒用户执行某些操作来规避

  • 出现问题后能否友好提示

    4、项目层面

  • 发布时间是否可以延期

  • 发布的版本对内还是对外？
  • 开发能都快速解决问题？

  • 产品团队能否接受带问题发布

    总之

  • 若是必现，主流程/主要功能，使用频率较高，无法有效规避出现该问题的出现，解决成本较高，产品团队也不接受带问题发布的话，必须解决了再发布，即使项目再紧急，没有质量的发布也是得不到用户的认可的

  • 当然在实际情况中，还是要根据不同的情况进行判断的

  • 也有可能存在产品团队直接做决定，作为测试要提醒风险点和建议，不直接参与决策

    H5 测试点

    h5 兼容性测试

  • 系统：adnroid(6~11)、ios(10~14)

  • 分辨率：刘海屏、挖孔屏、全面屏、曲面屏
  • 品牌：苹果、小米、华为、vivo、oppo

  • 浏览器：手机系统浏览器、微信浏览器

    H5 测试关注的点

  • 刷新：下拉刷新、浏览器刷新

  • 返回：屏幕右滑、返回键、物理键、返回主屏幕、切换应用
  • 浏览器：微信内置、QQ 内置、手机内置浏览器、第三方浏览器
  • 网络：弱网、断网、正常网络、wifi
  • 手机：通知、来电、锁屏、横竖屏、权限
  • 性能：响应时间、耗电量、发热量、流量、分页加载、瀑布流加载