image.png

Day 3 测试设计讲义

经过前面两天的课程内容，我们已经能够具备分析一个需求，通过其验收标准来确定测试范围，划分测试重点，然后根据分析的情况，编写测试用例，准备测试数据，执行测试用例并发现软件的缺陷，提交Bug。事实上这些已经是测试人员的常规操作了。

接下来我们重点要解决的问题是：如何对测试活动有一个“持续”的概念。或许大家还没有那么明确的概念：持续。当前互联网时代的软件行业，绝大多数的软件都是一个“持续”更新的状态，那么有一些功能就会被“持续”的测试，所以，虽然有了之前的方法和实践，我们依旧需要对测试实践进行详细的设计，这样能够接受“持续”带来的挑战。

最直接的“持续”活动，就是将软件测试实践“套路化”，给出文档，方便任何时候进行。这里的文档就是“测试计划”。

这里解决的主要问题如下：

如何保证你测试的功能接受重复测试（或者反复测试）而质量不受影响？
请问你们有测试评审么？如果有的话，评审都有哪些内容呢？
如何保证不同的人员对同一功能测试取得类似的测试效果？

0 主要内容

1 B4_方法策略
2 B5_测试场景
3 T2_测试计划

1 B4_方法策略

首先，我们接着前两天的内容继续。分析了测试的范围和重点以后，我们是直接开始编写测试用例了。但是实际上，我们没有探讨：方法策略。好的方法策略的选择，可以是测试活动变得可靠。

1.1 方法的作用

合理的方法，可以使得软件测试的执行变得更加有效，并且尽量的保证软件测试的执行不遗漏。在具体的项目中，合理的方法，可以使得漏测的缺陷减少。

如果没有确定方法，那么不同的测试人员，执行同一份测试，可能会选择不同的方法，那么带来的效果可能也不同，这样就把软件测试的结果寄托于“人”身上了，而并不是流程与节点，对于测试结果是不负责任的。

1.2 方法的选择

这里，我们首先来讨论一下方法的分类。

我们可能听过很多的说法：等价类、边界值、正交试验法等，还有说黑盒测试、白盒测试等，其实这样的讨论并不是在同一个层面上。我们先来澄清一下测试方法的分类。

按照对被测试对象的执行情况
- 手工测试
- 自动化测试：Automatic Testing
按照对被测试对象的观察视角
- 白盒测试：White Box Testing，研究源代码的内部结构，保证程序正确。
- 黑盒测试：Black Box Testing，不关注系统内部，只关注输入与输出。
- 灰盒测试：Grey Box Testing，介于上述两者之间。
按照对被测试对象的操作情况
- 动态测试：Dynamic Testing，被测试的系统需要运行起来。
- 静态测试：Static Testing，被测试的系统一定不能运行，检查代码和文档。
按照对被测试对象的质量维度
- 功能测试
- 性能测试
- 安全测试
- 兼容性测试
- 可用性测试
- 稳定性测试
- ……
按照对被测试对象的阶段划分
- 单元测试，Unit Testing，一般是开发人员对编写的类，方法进行测试
- 集成测试，Integration Testing，主要包括接口测试
- 系统测试，System Testing，传统的测试人员进行的功能、性能测试
- 验收测试，Acceptance Testing，由用户，或者模拟用户进行遍历测试
按照对被测试对象的系统结构
- 界面测试，UI Testing
- 接口测试，Interface Testing
- 数据库测试，Database Testing
- 业务逻辑测试，Business Testing
- 服务器测试，Server Testing
按照被测试对象的测试活动
- 回归测试，Regression Testing
- 冒烟测试，Smoke Testing
- 随机测试，Random Testing