测试开发手册

如何做好测试计划

# 如何做好测试计划

# 测试计划的好处

  • 知道确切的测试范围，采取怎么样的测试策略
  • 预估具体的工作量和测试资源，每个人分工明确，不容易出现重复测试和漏测的情况
  • 测试进度是可控的，实时知道目前测试完成情况，能预估完成的时间节点
  • 可以提前识别潜在风险，当需求发生变化时，我们需要做出响应

# 测试计划内容

# 测试范围

内容：被测对象、主要测试内容

测试范围的确定通常是在测试需求分析完成后进行，确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，有助于在早期阶段就发现潜在的测试遗漏。

由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，测试范围需要明确测什么和不测什么。

# 测试策略

目的：测试策略需要明确先测什么后测什么和如何来测，要求明确测试的重点，以及各项测试的先后顺序。

比如：对用户登录模块来讲，「用户无法正常登录」和「用户无法重置密码」这两个潜在问题，按照优先级来先测「用户正常登录」，再测「用户重置密码」。

测试策略还需要说明，采用什么样的测试类型和测试方法，要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。

  • 功能测试

    • 应该根据测试需求分析的思维导图来设计
    • 主线业务的功能测试由于经常需要执行回归测试，需要考虑实施自动化测试，通常应该先实现主干业务流程的测试自动化
    • 还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案

  • 兼容性测试

    • 兼容性测试的测试，一般是在功能测试的后期
    • Web测试需要确定覆盖的浏览器类型和版本
    • 移动设备测试需要确定覆盖的设备类型和具体iOS/Android的版本
    • 确定需要覆盖的移动设备类型以及 iOS/Android 的版本列表：
      • 如果是既有产品，你可以通过大数据技术分析产品的历史数据得出 Top 30% 的移动设备以及 iOS/Android 的版本列表
      • 如果是一个全新的产品，你可以通过 TalkingData 这样的网站来查看目前主流的移动设备，分辨率大小

  • 性能测试

    • 对于性能测试，需要在明确了性能需求的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架
    • 性能需求：并发用户数、响应时间、事务吞吐量等
      比如：是直接在 API 级别发起压力测试，还是必须模拟终端用户行为进行基于协议的压力测试
    • 如果性能是背景数据敏感的场景，还需要确定背景数据量级与分布，并决定产生背景数据的技术方案
      比如：是通过 API 并发调用来产生测试数据，还是直接在数据库上做批量 insert 和 update 操作，或者是两种方式的结合
    • 性能测试的实施，是一个比较复杂的问题。首先，需要根据你想要解决的问题，确定性能测试的类型；然后，根据具体的性能测试类型开展测试
    • 性能测试步骤：
      • 先要根据业务场景来决定需要开发哪些单用户脚本
      • 脚本开发涉及的概念：思考时间、集合点、动态关联等等
      • 脚本开发完成后，你还要以脚本为单位组织测试场景
      • 场景定义：
        • 百分之多少的用户在做登录、百分之多少的用户在做查询
        • 每个用户的操作步骤之间需要等待多少时间、并发用户的增速是 5 秒一个，还是 5 秒 2 个等等
      • 具体的测试场景执行
        • 关键点：性能测试执行完成后性能测试报告的解读

# 测试资源

包含：测试人员、测试环境

需要明确的问题：谁来测、在哪里测

测试人员资源：

  • 测试工程师的数量
  • 测试工程师的个人经验和能力

规划好测试资源的前提：

  • 了解项目本身
  • 对测试团队的人员特点有清晰的把控，针对团队成员的实际情况去安排测试计划
  • 把具体的任务清晰地落实到每个人的身上，有利于建立清晰的责任机制，避免后续可能发生的扯皮

# 测试进度

主要内容：各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间

比如：版本接受测试（Build Acceptance Test）的工作量，冒烟测试（Smoke Test）的工作量，自动化脚本开发的工作量，缺陷修复的验证工作量，需要几轮回归测试、每一轮回归测试的工作量等等

不同模式下的测试进度：

  • 传统瀑布模型
    测试进度完全依赖于开发完成并递交测试版本的时间，如果开发提交测试版本发生了延误，那么在不裁剪测试需求的情况下，产品整体的上线时间就同样会延期

  • 敏捷模式
    测试活动贯穿于整个开发过程，测试工作会和开发工作同步进行
    比如：采用行为驱动开发（Behavior-Driven Development）模式，测试进度就不会完全依赖于开发递交可测试版本的时间

行为驱动开发：常说的 BDD，指的是可以通过自然语言书写非程序员可读的测试用例，并通过 StepDef 来关联基于自然语言的步骤描述和具体的业务操作，最典型的框架就是知名「Cucumber」。

# 测试风险预估

在制定测试计划时，要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略

存在测试风险的主要原因：

  • 需求变更
    比如：增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化
  • 开发延期
  • 发现重大缺陷
  • 人员变动

（完）