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
我们可能听过很多的说法：等价类、边界值、正交试验法等，还有说黑盒测试、
1.3 方法的使用
实际上，大部分的项目中的日常测试，使用的是黑盒或者灰盒测试，而我们常说的黑盒测试方法，例如等价类，边界值就属于主要使用的过程。
一般来说：等价类、边界值和流程法这三个是被用的最多的测试方法。主要用来：准备测试数据。
2 B5_测试场景
2.1 什么场景
场景，Scenario，指的是行为，用户的实际使用行为。测试场景，就是在测试的过程中，模拟的用户的使用行为。
以登录作为栗子：
- 用户打开浏览器首次登录
- 用户在不同的浏览器同时登录
- 用户在不同的设备同时登录
- 用户在已经登录的浏览器打开登录页面
- 用户退出以后，不关闭浏览器，直接重新登录
- 用户……
2.2 场景的描述
需要注意的是，场景的描述，不能带有“预期结果”。很多测试的初学者在一开始是区分不清楚场景的概念，在编写场景的时候，往往会添加上“预期结果”。例如：用户打开浏览器首次登录成功登录。这样一来，编写的已经不再是测试场景，而是测试用例了。请注意，这样是不对的。
场景的描述，需要讲明白：用户的具体行为。
2.3 场景的设计
场景的设计，其实并不会非常复杂，但是往往有遗漏，我们来谈一下具体的设计方法。
首先，需要从最“正常”的用户使用着手，这也是最重要的，最常用的地方。需要参考和针对的点就是：测试重点。把所有的测试重点的地方，依次分析用户可能的行为，并一一列出来。
其次，类似和雷同的场景，应该汇总在一起，作为一个场景来编写。
最后，仔细考虑“不正常”的用户有可能的使用方式，包括：
- 错误操作
- 错误流程
- 意外情况
3 T2_测试计划
3.1 测试计划的作用
“凡事预则立，不预则废”。测试计划的作用其实无需多言，已经非常明确。任何事情都需要有一个计划。测试当然也是不例外的。
- 测试计划是评审的对象
- 测试计划是规范的体现
- 测试计划是提升的依据
3.2 测试计划的格式
测试计划的具体格式，在不同的团队和不同的项目组，一般是有差别的，目前国内外都没有非常明确的格式。我们这里推荐的测试计划，是与前面的内容相关的。包括以下几个方面：
- 测试目的
- 需求描述
- 测试范围
- 测试重点
- 策略方法
- 测试场景
是不是看上去非常眼熟？因为就是之前的内容，放到一起。
3.3 如何使用测试计划
测试计划是需要在测试实践开始之前，针对某一个需求来编写的。注意：一个测试计划，只针对一个需求。这是敏捷测试团队的一般情况。
编写好测试计划以后，一般需要经过一个评审过程。后续的测试行为，会在测试计划的基础上做改动，并持续使用。
不同的测试人员，针对同一份测试计划，需要做出同样的测试执行。
此外，禅道目前还没有测试计划的功能，这一点值得期待。但是TAPD是有测试计划的功能的。
- 相关学习
