1、1.测试计划1.1 测试计划编写条件测试计划（Testing plan），描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。在 测 试 项 目 之 初 就 要 制 定 相 应 的 测 试 计 划 。 接 下 来 谈 下 如 何 编 写 测 试 计 划 问 题 。1 为 什 么 要 编 写 测 试 计 划 ？ 1） 领 导 能 够 根 据 测 试 计 划 做 宏 观 调 空 ， 进 行 相 应 资 源 配 置 等 ； 2） 测 试 人 员 能 够 了 解 整 个 项 目 测 试
2、情 况 以 及 项 目 测 试 不 同 阶 段 的 所 要 进 行 的 工 作 等 ；3） 便 于 其 他 人 员 了 解 测 试 人 员 的 工 作 内 容 ， 进 行 有 关 配 合 工 作 2 什 么 时 间 开 始 编 写 测 试 计 划 ？（ 测 试 需 求 分 析 前 总 体 测 试 计 划 书 测 试 需 求 分 析 后 详 细 测 试 计 划 书 ） 3 由 谁 来 编 写 测 试 计 划 ？ 具 有 丰 富 经 验 的 项 目 测 试 负 责 人 4 测 试 计 划 编 写 6 要 素 ？ （ 5W1H） 1） why为 什 么 要 进 行 这 些 测 试 ； 2) what
3、测 试 哪 些 方 面 ， 不 同 阶 段 的 工 作 内 容 ； 3) when测 试 不 同 阶 段 的 起 止 时 间 ； 4) where相 应 文 档 ， 缺 陷 的 存 放 位 置 ， 测 试 环 境 等 ； 5) who项 目 有 关 人 员 组 成 ， 安 排 哪 些 测 试 人 员 进 行 测 试 6) how如 何 去 做 ， 使 用 哪 些 测 试 工 具 以 及 测 试 方 法 进 行 测 试 。注 意 事 项 ：1 测 试 计 划 不 一 定 要 尽 善 尽 美 ， 但 一 定 要 切 合 实 际 ， 要 根 据 项 目 特 点 、 公 司 实 际 情况 来 编 制
4、， 不 能 脱 离 实 际 情 况 ； 2 测 试 计 划 一 旦 制 定 下 来 ， 并 不 就 是 一 层 不 变 的 ， 世 界 万 事 万 物 时 时 刻 刻 都 在 变 化 ，软 件 需 求 、 软 件 开 发 、 人 员 流 动 等 都 在 时 刻 发 生 着 变 化 ， 测 试 计 划 也 要 根 据 实 际 情 况 的变 化 而 不 断 进 行 调 整 ， 以 满 足 实 际 测 试 要 求 3 测 试 计 划 要 能 从 宏 观 上 反 映 项 目 的 测 试 任 务 、 测 试 阶 段 、 资 源 需 求 等 ， 不 一 定 要太 过 详 细 评 审 总 结1.计 划 评
5、审 测 试 计 划 编 写 完 成 后 ， 一 般 要 对 测 试 计 划 的 正 确 性 、 全 面 性 以 及 可 行 性 等 进 行 评 审 ，评 审 人 员 的 组 成 包 括 软 件 开 发 人 、 营 销 人 员 、 测 试 负 责 人 以 及 其 他 有 关 项 目 负 责 人 。 2.计 划 总 结 项 目 完 成 后 ， 应 该 对 计 划 的 执 行 情 况 进 行 评 审 ， 看 有 哪 些 不 合 理 的 地 方 ， 以 便 为 编写 下 一 个 项 目 测 试 计 划 做 经 验 积 累 。2.测试用例评审2.1 测试用例测试用例就是一个文档，描述输入、动作、或者时间
6、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。定 义测 试 需 求 收 集 完 毕 后 ， 开 始 测 试 设 计 。 设 计 测 试 用 例 需 要 考 虑 以 下 问 题 ： 编 辑 本 段测 试 用 例 的 基 本 格 式软 件 测 试 用 例 的 基 本 要 素 包 括 测 试 用 例 编 号 、 测 试 标 题 、 重 要 级 别 、 测 试 输 入 、操 作 步 骤 、 预 期 结 果 ， 下 面 逐 一 介 绍 。 用 例 编 号测 试 用 例 的 编 号 有 一 定 的 规 则 ， 比 如 系 统 测 试 用 例 的 编 号 这 样 定 义 规 则 ： PRO
7、JECT1-ST-001 ， 命 名 规 则 是 项 目 名 称 测 试 阶 段 类 型 （ 系 统 测 试 阶 段 ） 编 号 。 定义 测 试 用 例 编 号 ， 便 于 查 找 测 试 用 例 ， 便 于 测 试 用 例 的 跟 踪 。 测 试 标 题对 测 试 用 例 的 描 述 ， 测 试 用 例 标 题 应 该 清 楚 表 达 测 试 用 例 的 用 途 。 比 如 “ 测 试用 户 登 录 时 输 入 错 误 密 码 时 ， 软 件 的 响 应 情 况 ” 。 重 要 级 别定 义 测 试 用 例 的 优 先 级 别 ， 可 以 笼 统 的 分 为 “ 高 ” 和 “ 低 ” 两
8、 个 级 别 。 一 般 来 说 ， 如 果 软 件 需 求 的 优 先 级 为 “ 高 ” ， 那 么 针 对 该 需 求 的 测 试 用 例 优 先级 也 为 “ 高 ” ； 反 之 亦 然 ， 测 试 输 入提 供 测 试 执 行 中 的 各 种 输 入 条 件 。 根 据 需 求 中 的 输 入 条 件 ， 确 定 测 试 用 例 的 输 入 。测 试 用 例 的 输 入 对 软 件 需 求 当 中 的 输 入 有 很 大 的 依 赖 性 ， 如 果 软 件 需 求 中 没 有 很 好 的 定义 需 求 的 输 入 ， 那 么 测 试 用 例 设 计 中 会 遇 到 很 大 的 障 碍
9、 。 操 作 步 骤提 供 测 试 执 行 过 程 的 步 骤 。 对 于 复 杂 的 测 试 用 例 ， 测 试 用 例 的 输 入 需 要 分 为 几 个 步骤 完 成 ， 这 部 分 内 容 在 操 作 步 骤 中 详 细 列 出 。 预 期 结 果提 供 测 试 执 行 的 预 期 结 果 ， 预 期 结 果 应 该 根 据 软 件 需 求 中 的 输 出 得 出 。 如 果 在 实 际测 试 过 程 中 ， 得 到 的 实 际 测 试 结 果 与 预 期 结 果 不 符 ， 那 么 测 试 不 通 过 ； 反 之 则 测 试 通 过 。2.2 测试用例评审首先要清楚内部评审的定义，是
10、测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。如果是测试组内部的评审，应该着重于：1. 测试用例本身的描述是否清晰，是否存在二义性2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下3.是否针对需求跟踪矩阵，覆盖了所有的软件需求，4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。测试用例评审如何去做呢？测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。评审的内容有以下几个方面：1) 用
11、例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。2) 优先极安排是否合理。3) 是否覆盖测试需求上的所有功能点。4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。5) 是否已经删除了冗余的用例。6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用 2&8 法则，那就是 4倍于正面用例的数量，毕竟一个健壮的软件，其中 80%的代码都是在“保护”20% 的功能实现。7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。个人认为，一个“健康”的测试用例至少要通过前 5 个标准。5、评审的方式1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。2) 通用邮件与相关人员沟通3) 通用 IM 工具直接与相关人员交流方式只是手段，得到其它人员对于用例的反馈信息才是目的。无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。
