测试需求、用例设计、测试数据准备总结
毕业后从事软件测试工作1年有余，主要负责项目几个组件测试的用例设计。在整个用例设计过程中难免有些事物，写此博文，权当对工作的总结，以帮助自己和同行在用例设计工作的漏出，欢迎补充，不妥之处，欢迎指正。
用例设计的过程如下：
一、梳理规格文档/设计报告
在测试用例设计之前，研读相关规格文档，记录不明白的地方、不严谨的地方，简单画出总体流程图。然后再来一遍，仔细分析各个模块的功能，画出模块内流程图，找出所有功能，并列出主要测试点，梳理输入、输出、组件及周边系统状态。整个步骤的产出物如下：
- 文档不明白点
- 文档不严谨的地方
- 总体流程图
- 模块内流程图
- 功能点（主要测试点）
- 输入
- 输出
- 组件状态
- 周边系统状态
对于不明白的地方或者不严谨的地方，尽早找需求人员或者开发确认。 毕竟，模糊不清的地方，也可能是开发理解有歧义的地方，尽早发现缺陷，降低整个项目的成本。
二、测试需求梳理
基于组件/系统的流程图，根据已梳理的功能点，进行测试需求的梳理。在用例设计时，需要对输入、输出、组件/系统状态、周边系统状态、流程操作顺序等，几个要素进行覆盖，防止用例设计的漏出。
1. 输入，尤其是字段值的分析：常采用等价类划分法、边界值法、错误推断法，提取测试用例点，进行测试需求分析。
2. 输出：基于输入覆盖，检查是否所有的输出都进行了覆盖；对于没有覆盖的地方，进行测试需求覆盖。
3. 组件/周边系统状态：状态转移图进行状态的分析，提取测试用例点，进行测试需求分析。
4. 流程操作顺序：遍历所有流程，进行覆盖。对于有操作先后顺序要求的，更改顺序。
5. 基于业务知识、业务逻辑，在逻辑层面提取测试需求点。当然这一步需要对系统、行业需要有一定的知识积累。同时需要对同类系统，有一定的了解。
测试需求在模板中组织形式，通常有输入相同的放置在一起、输出同一属性放置在一起。这两种方式各适合不同的场景。
| 放置形式 | 适合场景 |
| 输入相同的放置在一起 | 输入者属或字段性多，输出值或者字段少 |
| 输出同一属性放置在一起 | 输入者属或字段性少，输出值或者字段多 |
三、 测试用例设计
测试用例的设计是根据测试需求进行的，如果测试需求分析得重复，测试用例设计可以按照测试需求按部就班的进行。但是，如果测试需求和测试用例不是同一个进行的，难免测试需求分析不够充分。这是，测试用例设计人员就应该按照“步骤二”的方法进行用例的设计。
测试用例的设计，需要符合以下几个标准：
1. 单个用例最小化原则
单个用例测试单个功能点，功能点不能拆分子功能点。主要有以下优点：
- 测试用例的覆盖边界定义更清晰
- 测试结果对产品问题的指向性更强
- 测试用例间的耦合度最低，彼此之间的干扰也就越低
上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。
2. 测试用例替代产品文档功能原则
产品代码和测试用例是能够一直准确地描述产品的功能的。因而好测试用例的执行，无需思考或者参考其他文件就能执行。
对于自动化测试用例（无论是API或者UI级别的）而言，代码在编写上也应该有别产品代码编写风格，可读性和描述性应该是重点考虑的内容。在测试代码中，当然可以引入面向对象、设计模式等优秀的设计思想，但是一定要适度使用，往往面向过程的编码方式更利于组织、阅读和描述。
3. 单次投入成本和多次投入成本的原则
测试的成本按其时间跨度和频率可以分为：单次投入成本和多次投入成本。
编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行（Scrum每个Sprint的开始阶段）的，虽然后期会有不断的调整，但绝大多数是在一开始的设计阶段就基本上成型了；自动化测试用例也是如此，它也属于是一次性投入。
测试用例（包括：手工和自动化测试用例）的执行则是多次投入成本，因为每出一个新版本Build时都要执行所有的测试用例（或者进行BVT测试仅执行高优先级的测试用例）、分析测试结果、调试失败测试用例、确定测试用例的失败原因（产品缺陷、测试用例缺陷、测试框架缺陷还是随机问题导致了测试用例的失败），以验证该版本整体质量是否达到了指定的标准。
一般用例的多次执行占用整个测试活动的时间的比率是比较大的。从而测试用例的设计便于测试的执行会节省测试活动的时间。
4. 使测试结果分析和调试最简单化原则
这条原则是实际上是上一条 - 单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调更简单，包括：用例日志、调试辅助信息输出等。往往在测试项目中，测试用例的编写人和最终的执行者是不同的团队的成员，甚至有个能测试的执行工作被采用外包的方式交给第三的团队去进行，这在当下也是非常流行的。因为测试用例的执行属于多次投入，测试人员要经常地去分析测试结果、调试测试用例，在这部分活动上的投入是相当可观的。
四、测试数据准备
测试用例设计之后，测试用例执行之前，需要进行测试脚本的编写以及测试数据的准备。测试脚本的编写及相关技能，在此不展开。测试数据、测试脚本之间的耦合性、依赖性尽量降低。
测试数据准备，尤其是同一个测试test的数据，不同字段最好不要用相同的数值，以免漏出“字段获取未按照预期的字段的值”。例如，字段a1和a2的值是分别从输入a和b获取的。如果测试数据准备时候，a和b的取值相同，开发引入bug a1的取值是b，是无法检测出来的。
参考
