测试计划

  1. 需求
  2. 提取测试点
  3. 编写测试用例

测试用例

测试用例的定义：

执行测试的依据，将测试的操作步骤进行以文档的方式记录下来

测试用例的格式：

测试用例的模块 测试用例的编号 执行条件 测试输入 预期结果 实际结果

测试用例的模块：操作软件的一个大的菜单 命名以模块名称为主

测试用例的编号：命名以菜单下具体功能_数字

执行条件：操作的先决条件

测试输入：对具体的功能操作步骤

预期结果：以需求文档上的内容为主

实际结果：依据测试数据的内容输出后得到的结果可能与预期一致或者不一致

​

测试用例的特性：

代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。

针对性：对程序中的可能存在的错误有针对性地测试

可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果

可重现性：对同样的测试用例，系统的执行结果应当是相同的

测试用例的输入类型：

  1. 字母
  2. 数字
  3. 特殊符号
  4. 空字符
  5. 汉字

软件分类

OA：办公自动化

crm：客户管理系统

ERP：进销存系统

编写测试用例的时候3步骤走：

  1. 根据需求提取测试用例的测试点
  2. 根据测试点内容输入不同数据类型
  3. 得到不用结果来编写测试用例

测试方法(测试策略)

  1. 等价类划分法
  2. 边界值法
  3. 因果图法
  4. 正交法
  5. 场景法
  6. 错误推断法

测试评审的标准

  1. 测试用例的正确性测试用例不含有争议
  2. 测试用例是否冗余
  3. 测试用例的覆盖率
  4. 测试用例是否满足需求文档

评审的内容有以下几个方面

  1. 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
  2. 优先极安排是否合理。
  3. 是否覆盖测试需求上的所有功能点。
  4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确_期待结果是否有明显的验证方法。
  5. 是否已经删除了冗余的用例。
  6. 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
  7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。
  8. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤