本话题暂不探讨是否有必要编写详细的测试用例，在确定要交付详细的测试用例这个前提下，分享如何更高效地完成测试用例的编写。
对齐测试用例需求
首先、明确要完成的测试用例文档目标要求，模板、范围、粒度等。
- 用例文档使用者：测试人员
- 用例文档范围：覆盖产品所有需求
- 用例模板内容：编号、模块、子模块、测试功能点、预置条件、数据、步骤、预期结果、优先级、用例类型、关联需求、(编写人、更新时间、执行人、状态、执行时间、执行结果)
- 测试用例粒度：所有功能的正反用例
- 测试用例验收负责人：活久见(对齐目标)
快速了解产品
最快的速度熟悉产品业务背景与技术架构，从而勾勒出测试用例整体框架。任何一款产品，最终都能映射到【横向扩展】+【纵向分层】的组合模式下来完成用例覆盖。
横向业务扩展
是指产品辅平来看，总共有哪些业务场景，提供了哪些能力，即产品最上层的功能全景。
纵向架构分层
是指从产品的技术架构层面来分析，当前产品可以宏观上分为几层，以便于在用例验证是从不同层次上进行验证和用例覆盖。
以某云的大数据云平台为例，大数据云平台的核心是集群。大数据云平台集群是由一个或多个虚拟机实例组成的Hadoop、Flink、ZooKeeper集群。以Hadoop为例，每个虚拟机实例上通常都运行了一些daemon进程(例如，NameNode、DataNode、ResouceManager和NodeManager)，集群上还可安装各类大数据服务组件(例如：HBase、Hive、Presto、Spark等)。
大数据云平台的横向核心业务功能全景线路图(以Hadoop集群为例)，其核心流程有：Hadoop集群创建->集群管理->大数据组件管理->虚拟主机管理-> ... ->Hadoop集群释放;功能全景如图1所示：
大数据云平台功能全景
大数据云平台的纵向核心架构分层简化为以下四层，如图2：
- 最顶层：大数据云平台的门户控制台界面【UI】
- 次顶层：大数据云平台的门户后端API【OpenApi】
- 次底层：大数据云平台的服务端【大数据服务组件】
- 最底层：大数据云平台的基础设施【云服务器】
大数据云平台架构图
快速制定方案
用例覆盖范围
从产品业务功能全景出发，围绕PRD(Product Requirement Document)、结合纵向架构层次，用例无死角全面覆盖产品(论范围)。
(1) 水平方向拓宽【宽度】，围绕它的产品的主生命周期由大模块至小模块、主功能至次要功能逐步扩展枝叶，借用鱼骨图梳理(如下图3)或Xmind脑图来整理。先梳理内部，然后梳理外部对接的服务或产品场景(如：消息中心、费用中心、告警中心、文档中心、数据开发等等)。
(2) 横向扩展发散完成后，开始纵向挖掘【深度】，比如，大数据云平台核心架构分为四层，每一层都需要拆开了看：
- 最顶层：UI层端对端用例走查(如前面所述)，从顶层UI操作测试除了验UI结果、还要确保底层集群服务器上的实际结果与界面显示一致
- 次顶层：第二层是门户后端Api，直接调用OpenApi的相关测试用例覆盖
- 次底层：直接操作使用或强干预Hadoop集群服务组件、检验整个大数据云平台的质量;由于大数据平台上的服务组件非常多(有三十多)，除了单个服务使用外，更要多个常用服务组件搭配组合验证
- 最底层：直接操作使用或强干预服务器层(增、删、停、重启、扩、缩、升、网络、磁盘、软件配置等)，检验整个大数据云平台的质量
到目前为此，大数据云平台整个Hadoop集群的测试用例全部范围梳理完毕。
用例设计方法
从测试类型出发，有功能与非功能测试用例覆盖。本次不需要交付非功能用例，因此不展开;功能性用例设计方法：
- 等价类划分法(正等价类、负等价类)
- 边界值分析法(边界内、边界外)
- 判定表分析法
- 因果图
- 错误推测法
用例编写原则
- 拆分原则：全文制定统一的边界。比如：以模块为边界、当不同模块之间有关联互动时、预置条件作为分界线，预置条件里的内容放在上游模块验证。
- 优先级原则：【创建】【查看】【使用(启停等)】【修改】【删除】为序 【主场景】优先、【次要场景】其次 【正例】优先、【反例】其次
- 基础原则：用例无重复、无遗漏， 单一性原则、即一个用例仅覆盖一个场景清晰的步骤、明确的预期结果不存在二义性 反复执行结果相同
快速编写小妙招
制定统一标准
以某云大数据云平台产品为例，很多需求功能统一要求，为此设计一套标准化用例：
- 比如：创建新增的页面，表单输入项，需求约束统一要求(是否必填、长度限制、字符要求)，设计一套标准化用例，供其他页面复用。
- 比如：每个模块的权限测试用例，设计统一标准用例;
- 比如：所有的OpenApi测试，都是针对返回码200、400、401、403、405、500的场景测试;
- 比如：大数据平台服务30多个，每个服务是不同的，但操作是类似：添加、启动、停止、修改配置、部署，为此设计统一标准用例 (此刻你是否有一种代码重构的既视感，定义一个标准的方法、供大家反复调用)。
提取公共组件
以某云大数据云平台产品为例，其中包含了10个以上的列表页面，对于每个列表都有分页组件、筛选、搜索、排序，这些公共组件的用例抽为【公共组件用例】，设计一套标准化用例，相关页面复用即可。
注意：统一标准用例中，可变的项用{ABC}来替换，比如：在集群查看列表中筛选集群状态时，把统一标准用例中的{ABC}替换成{集群状态}即可。
批量编写与自动生成
在用例编写过程中，发现很多情况除了{某名称或字段}不同，其它都是一样的，此时可以批量编写(如：借助Sublime或直接传变量用代码生成)，这样也可以大大提高编写效率。
在编写OpenApi相关测试用例时，直接定义出一套OpenApi标准用例，以QA设计出的标准用例为模板，然后编写代码生成用例，通过读取OpenApi的Json文件，快速生成71个Api的测试用例，近1000条详细测试用例，高效。
活用全文替换
编写用例时，QA人员一定要用统一语言文字或格式，一来是给阅读的人方便、二来是方便查找替换，即通过全文查找替换能 快速维护用例。
有一次需求变更：由原来的一级菜单A001下二级菜单B002，变为了一级C001下D002;由于在整个产品的用例中，从一级菜单进入二级菜单，全部都使用：A001->B002这种格式，本次需求变更，直接全文查找替换一键完成。
前边提到过设计了多套统一标准用例，新的页面复用时，直接替换变量内容，生成当前用例。又或者需求变更的刚好是统一标准用例的内容，活用全文查找替换、一分钟搞定用例维护。
总之，必须要总结一套自己的方法来应对这么庞大的编写工作量，否则在短期的时间内无法完工。而高效编写用例的秒招，离不开可复用、找共性、提炼统一标准，借用一些手段或工具自动生成。
结尾送君一句话：划清领域边界、高复用、低耦合。
