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