软件开发的生命周期

  1. 客户提出需求(概念)

  2. 根据客户的需求写出相对应的需求文档

  3. 前端设计效果图(原型图)

    后台开发人员设计与编写代码实现功能

    测试人员根据需求文档编写测试计划和测试用例

  4. 在后台开发实现功能后根据测试用例测试人员进行测试

  5. 开发完全结束后，测试人员进行整体测试，全面测试，测试成功后进入上线

  6. 软件上线后根据用户体验和实际效果进行小版本迭代

测试流程

  1. 在立项会上根据客户需求编写需求文档/规格说明书，UI设计原型图后台编码，测试人员编写测试计划和测试用例
  2. 随着开发的代码实现，测试进行测试评审
  3. 主要代码实现后测试人员先进行冒烟测试
  4. 代码实现后测试执行测试用例
  5. 根据执行的结果进行对应bug提交给相对于的开发人员让其修改代码
  6. 开发修改后测试人员进行回归测试

冒烟测试：在这个软件中主要功能实现后进行测试

回归测试：在开发人员修改后进行的同一个问题的测试

软件测试的分类

  1. 按阶段划分

    1. 单元测试：对一个模块测试

    2. 集成测试：对多个模块测试(有一定的关联)

    3. 系统测试：在软件编译后执行的整体测试

    4. 验收测试：对软件执行后的用户体验的测试

      ​ α 阿尔法测试：有一定的开发测试人员的测试 内测

      ​ β 贝塔测试： 只有用户参与的测试 公测

  2. 按是否运行程序划分

    1. 静态测试：UI设计图
    2. 动态测试：由执行代码过程中产生的问题

  3. 按是否查看源代码方式划分

    1. 黑盒测试：不看源代码结构 只关心外观和能否输入输出以及响应时间

      功能测试：界面 安装 兼容 易用

      性能测试：压力测试 负载测试 一般性能 稳定性测试

      ​ 压力测试：在同一时间内进行多个用户的访问 ​ 负载测试：在多个用户在一段时间的持续访问

    2. 白盒测试：只看代码结构以及代码实现方式

    3. 灰盒测试：介于黑盒和白盒之间一种

软件测试的原则

  1. 尽早原则
  2. 考虑意外情况和极端情况的发生
  3. 群集现象
  4. 测出问题能够复现问题
  5. 不要在短时间进行高效测试
  6. 回归测试的关联性
  7. 善于总结相关文档

测试工具

world文档 测试计划 测试用例 缺陷报告

接口工具 charles Fiddler postman

性能工具 Jmeter Loadrunner

bug管理工具 禅道 jira QTP

自动化管理工具 selenium appnium uptest pytest

云测工具 Testing

测试计划

  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. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤

测试计划

  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. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤

缺陷报告编写

缺陷严重程度划分：系统崩溃，严重，一般，次要，建议

修正优先级：高，中，低

Bug定级示例

1级，系统崩溃
定义：严重阻碍测试和开发工作
对应优先级：最高
具体可分为：

  1. 功能完全没有实现
  2. 应用闪退/崩溃无法运行
  3. 应用必现安全模式，无法运行
  4. 其他导致功能无法测试的问题

2级，至关重要
定义：非阻碍用例执行的严重问题
对应优先级：高
具体可分为：

  1. 简单操作应用闪退/崩溃，卡死
  2. 数据丢失
  3. 严重影响系统，自身功能无法运行
  4. 严重数值计算错误
  5. 数据库损坏或无法保存配置
  6. 安全性问题（包括数据加密等）

3级，主要
定义：功能存在缺陷，但不影响应用和系统的稳定性
对应优先级：中
具体可分为：

  1. 内存泄露（长时间不用的对象需要被回收，不被回收占内存）
  2. 功能实现逻辑覆盖不全面
  3. 非必现，但复现概率超过50%的闪退/崩溃和安全模式

4级，一般
定义：对应用熟悉度高才能感知到的问题，对应用基本功能实现无影响
对应优先级：中
具体可分为：

  1. 轻微数值计算错误
  2. 功能实现有误，与产品文档不完全贴切
  3. 用户简单操作，即可明显感知的UI问题

5级，较小
定义：界面，性能缺陷
对应优先级：低
具体可分为：

  1. 操作界面错误（提示显示规则，刷新规则是否与文档一致）
  2. 边界条件显示错误
  3. 提示信息和界面效果展示错误（包括未给出信息、信息提示错误等）
  4. 复现率低于5%的闪退/崩溃和安全模式
  5. 插件兼容和性能未优化问题
  6. 非正常操作导致UI显示异常

6级，建议
定义：对于产品的意见或者建议
对应优先级：低
具体可分为：

  1. 对于产品设计方面的意见和建议
  2. 对于产品界面优化方面的意见和建议
  3. 对于产品需要优化增强用户体验方面的意见和建议

Bug生命周期

新建 确认 解决 重新验证 关闭 重新打开

  1. 一个Bug由测试人员发现并提交，我们将状态标注为新建；

  2. 开发人员接收了该Bug，将Bug的状态改为已分配(Assigned)，表示已经认可；

  3. 开发人员解决了该Bug后，将Bug的状态修改为已解决，并发给测试人员回归测试；

  4. 测试人员对Bug进行回归测试，如果确实已经解决，就将Bug状态修改为关闭，否则的话则发给开发人员重新修改。

注意：Bug是可以“死而复生”的，以前版本已经关闭的Bug，如果新版本中重新出现，我们就需要将其状态修改为重新打开。