该文档用于指导社区测试人员开展版本测试策略的分析工作，测试策略模板获取可以联系QA-SIG组成员获取，如有疑问可通过社区网站SIG中心联系QA-SIG组Maintainer进行咨询。
用例设计规范
概述
该文档用于指导社区测试用例的编写，保障用例具备良好的可执行性、易读性和易维护性。
用例设计原则说明
用例设计原则是指在设计用例时需要遵循的一些基本原则，以确保用例的质量和有效性。以下是一些常见的用例设计原则：
可读性原则：用例应该易于阅读和理解，以便所有测试人员都能够理解用例的内容和目的。
完整性原则：用例应该包含所有必要的信息，包括测试环境组网信息，预置条件信息，测试以及操作对象，观察点等信息。
描述精准：测试用例描述内容清晰，测试步骤描述的操作清晰明确，无歧义，直接且准确地表达测试目的和预期结果，不同的测试人员对用例理解无差异。
可测试性原则：用例应该能执行，以便测试人员能够通过有效的方法执行用例。
原子化：测试用例的颗粒度要适宜，确保每个测试用例只针对一个验证点进行设计，避免将太多的验证点集成到一个用例。
可重用性原则：测试用例的存在就是为了验证和回归，因此可回归是用例的必要条件。同一条件下，不同人回归的结果应一致；在不同时间内，回归结果应一致；使用满足条件的任何数据，回归结果应一致。
用例字段规范说明
用例名称（必填项）
用例名称是测试目的的说明，需简要、准确的描述该用例的测试点，无二义性。
填写规则：
清晰准确，清晰描述测试目的或者测试内容，任何测试人员都能理解到测试点信息；
简洁明了，避免冗长和不必要的描述，通常标题应控制在20个字以内；
包含关键信息，应该涵盖主要的测试对象和测试内容；
唯一性，每个用例的标题应是唯一的，避免使用相同的标题，以确保每个用例的可识别性和可追踪性；
用例名称中不能带有* - / \“”‘’空格等特殊字符；
建议采用动宾结构方式（未说明用户信息的默认测试用户为管理员），例如：
操作员用户修改自定义管理员用户密码测试
用例编号（必填项）
用例编号用于唯一标志一个用例ID，便于检索和寻找用例。
填写规则：
用例编号由英文字母和数字以及下划线组成，编号使用“_” （下划线）连接特性名称和数字编号，用例编号分段组成为：特性_子特性_测试类型_编号。
注意：
英文单词首字母大写，非首字母小写；
缩写词各字母均大写；
用例编号只能是英文字母和数字，特殊字符只允许英文“_”；
只能以英文字母开头，不允许数字或者英文“_”开头；
编号用4位数字，从0001、0002开始，例如：
NetWork_DHCP_Function_0001
BIOS_Config_Reliable_0002
用例级别（必填项）
用例级别主要用于定义该用例的重要性以及测试应用场景。
填写规则：
严格按照如下要求定义用例级别，比如Level 0、Level 1、Level 2、Level 3。
| 测试用例等级 | 用例等级说明 |
|---|---|
| L0 | 门槛用例：可用于度量版本基础质量，版本转测试的门槛用例，确定该模块是否可以转测的用例，建议版本转测试前需执行。 划分依据： 1、该用例执行失败会导致重要功能无法运行； 2、用于确定当前模块是否可以准入测试； |
| L1 | 基本用例：该类用例用于验证系统特性的基础功能，衡量特性功能是否存在问题，建议每个转测版本执行。 划分依据： 1、所有功能的正确性验证； 2、重要功能的可靠性测试； 3、用户使用频率高的功能场景； |
| L2 | 重要用例：该部分用例用于验证系统所有的功能，衡量版本所有特性功能是否能正常运行。建议根据版本当前的测试阶段和验证策略进行执行，发布版本需要执行的用例。 划分依据： 1、所有功能的场景测试； 2、常用功能的非功能测试（可靠性测试、性能、兼容性、规格、可服务性等）； |
| L3 | 生僻：该类用例对应较生僻的预置条件和数据设置。版本不常用场景用例，根据版本测试阶段和验证策略进行执行，建议版本测试周期内至少执行一次。 划分依据： 1、极少使用功能的非功能测试； 2、用例依赖较复杂特性的预置条件； 3、非常规操作，生僻场景； |
自动化类型（选择填写）
用于标注测试用例是否已经实现自动化。
填写规则：
用例已实现自动化，并且自动化脚本代码以上到规定的代码仓的用例该字段标记为“TRUE”，其它情况下的字段标记为“FALSE”，新增用例默认选FALSE。
测试类型（必填项）
该字段用于表示测试用例类型，按照用例测试目的进行测试类型选择，常见分类如下表所示。
填写规则：
| Test Type | 测试类型 |
|---|---|
| Function test | 功能测试 |
| Compatibility test | 兼容性测试 |
| Protocol Conformance test | 协议一致性测试 |
| Performance test | 性能测试 |
| Scaling test | 扩缩容测试 |
| Pressure test | 压力测试 |
| Long-run test | 长时间测试 |
| Configuration test | 配置测试 |
| Recovery test | 恢复测试 |
| Fault injection test | 故障注入测试 |
| Installation test | 安装测试 |
| Traffic Control test | 流控测试 |
| Backup test | 备份测试 |
| Security test | 安全测试 |
| Usability test | 易用性测试 |
| Maintainability test | 可维护性测试 |
| QoS test | 服务质量测试 |
| Network topology test | 网络拓扑测试 |
| Interconnectivity test | 互联互通测试 |
| Stability test | 稳定性测试 |
| Serviceability test | 可服务性测试 |
| Reliability test | 可靠性测试 |
| Globalization test | 全球化测试 |
| Information test | 信息资料测试 |
| Energy efficiency test | 能效测试 |
预置条件（必填项）
预置条件用于描述用例执行的预置要求或前提条件，主要包括环境配置、组网信息等。
举例：
硬件配置要求，比如配置硬件型号信息、数量要求等要求（例如：环境至少安装2张PCIE网卡/环境至少安装1张RAID卡等）；
组网配置要求，比如网络地址需要配置成IPV6等要求；
测试步骤（必填项）
描述用例执行的具体步骤，用于指导测试人员进行测试执行。
填写规则：
测试步骤一般要包含主谓宾信息，清晰描述谁（管理员/操作员等）操作（设置/查询）什么对象（用户名称/网络模式），使用了相关命令的要明确命令信息和参数，使用了工具的在备注中说明工具操作方法和工具名称以及对应版本信息，并且说明工具获取方法。
补充说明：用例命令中携带的参数由于环境配置或者硬件槽位等差异会发生变化的需要动态获取，不能固化在用例描述中，同时命令中通过<>符号备注说明。
用例中的几种符号使用说明：
[]：一般代表菜单选项名称，表示该项为可选择或者可点击、可设置的菜单项。
<>：一般代表参数，表示该项内容需要用户输入。
举例：
管理员通过IPMI接口查看被测服务器的CPU传感器名称是否正确，以及传感器状态是否正确,有结果A:
''' ipmitool.exe -H <IP> -I lanplus -U <user> -P <password> -C xx xx xx '''
管理员通过redfish查看被测服务器的CPU传感器名称是否正确，以及传感器状态是否正确,有结果B:
''' Get https://<ip>/redfish/v1/Chassis/1/ThresholdSensors '''
管理员通过CLI查看被测服务器的CPU传感器名称是否正确，以及传感器状态是否正确,有结果C:
''' ipmcget -t sensor -d list '''
管理员通过带外IPMI命令查看被测服务器[VMM使能]选项,有结果A:
''' ipmitool.exe -H <ip> -I lanplus -U <user> -P <password> -C 17 raw xx xx '''
预期结果（必填项）
用于用例描述执行完成后期望得到的执行结果。
填写规则：
预期结果准确清晰描述测试步骤的执行预期结果，观察方法和观察点清晰，对于性能测试指标可量化；
每一个预期结果的观察点一般不能多于2个；
预期结果的编号使用大写字母，如A/B/C；
举例：
A）用户创建成功，通过新增user用户登录Web成功；
备注（选择填写）
用于对测试用例信息进行补充说明或者对测试步骤中使用的工具等信息进行补充说明。
用例语法规则
语法规则要求包括测试保留字使用规则和测试语法表达规则，是测试用例表达一致的基础。
规则 1：测试保留字使用规则，即测试用例的表达必须使用相同的测试保留字。
说明：测试保留字是测试用例表达中与特性无关，与技术无关，是所有测试用例都可能使用的测试用语特有的，表示测试条件预置、测试执行、观察点检查、结果验证的专门用词。下面给出建议的关键字用词列表：
测试用例保留字列表
| 保留字 | 说明 | 需统一的其它描述 |
|---|---|---|
| 设置 | 通用，泛指对系统的各种设置操作 | 配置、设置、更改、修改 |
| 删除 | 通用，泛指对系统设置的删除操作 | 清除 |
| 执行 | 通用 | |
| 重复 | 通用 | 反复 |
| 检查 | 通用 | 观察、查询、确认、查看、验证 |
| 如果 | 通用 | 假如 |
规则 2：测试语法表达规则，即测试用例的表达必须符合测试语法表达规则。
说明：测试用例的表达不仅同一个测试用例设计人员要保持一致的风格，而且要做到不同测试用例设计人员也采用同一风格，这样在交流、评审和测试执行都会更易于阅读和理解。包括语法表达规则和排版一致性。
语法规则列表如下：
语法分类建议表
| 类别 | 说明 | 建议的语法 | 举例 |
|---|---|---|---|
| 操作类 | 指执行一个特定操作或动作，主要是指测试执行步骤 | [动作][对象][参数] | xx设备发送XX响应消息 |
| 赋值类 | 指设置某个对象的属性，主要指预置条件 | 设置[对象][属性]为[参数] | 设置用户xx属性为yy |
| 检查类 | 指检查某个对象的属性，主要指预期结果 | 检查[对象][属性]是否[参数] | 检查xx消息中yy字段的值为01 |
| 重复类 | 当需要多次重复执行时 | 重复步骤[X]到步骤[Y] | 重复执行步骤1~步骤3 |
规则3：测试用例表达用词要求用词一致。
说明：用词一致主要目的是增加用例可读性和防止二义性，除了语法规则中的测试保留字以外，还有各类专有用词，即各功能特性中用到的与技术相关的用词。
规则4：测试用例表达用词要求精确。
说明：精确指的是测试用例中对必须的技术细节要表达清楚，明明白白告诉测试执行者应该做什么，如果做。在用例写作过程中，常犯的毛病是将自己清楚的细节隐含不明确写出来，结果使用例的可执行性较差，自己清楚如何执行，而其它测试人员却执行困难。
规则5：测试用例表达用词要求简洁。
用例表达的简结包括以下几个方面的要求：
用例的执行步骤建议在7步以内，超过7步的考虑拆分为多个用例；
测试执行的每一步描述中，如果有引用测试执行指导书中内容的，通过标记说明；
对于测试技术的基本知识和常识，不要在用例中描述；
测试用例中不要写无关冗余的内容。
规则6：测试用例表达用词要求易懂。
说明：易懂指的是测试用例得从用户角度来描述，采用易于理解的自然语言，而避免太过专业化的用语，以保证不同技术层面的测试人员都能容易理解。实际操作中，测试用例设计人员对被测试特性往往都有较深入的了解，因此习惯于使用专业性强的说法，导致对特性没有深入了解的测试人员理解起来困难。
规则7：测试用例表达用词要求易确认。
不易确认的测试用例描述举例：
检查操作正确；
问题：是检查什么操作，检查操作中的什么内容，预期的取值是什么都没有明确。测试执行者只能根据自己经验去决定正确还是错误，因此该描述是不易确认的。
检查消息流程正确；
问题：正确消息流程应该是怎样的，都应该检查消息中的哪些参数，也都没说明，因此该描述同样是不易确认执行结果的。
规则8：测试用例中的英语单词大小写要统一。
用例字段汇总
| 属性 | Property | 是否必填 |
|---|---|---|
| 名称 | Name | 是 |
| 编号 | Number | 是 |
| 级别 | Level | 是 |
| 自动化类型 | Automated | 是 |
| 测试类型 | Test Case Type | 是 |
| 预置条件 | Pretreatment Condition | 是 |
| 测试步骤 | Test Steps | 是 |
| 预期结果 | Expected Result | 是 |
| 备注 | Remark | 否 |
用例设计模板
用例设计模板参考：
用例_名称
定制BMC ACPI_State传感器事件
用例_编号
Customization_Event_ACPIState_0001
用例_级别
Level1
用例_测试类型
Function test
用例_自动化类型
FALSE
用例_预置条件
1、BMC正常运行；
2、OS处于下电状态；
用例_测试步骤
1、执行上电操作，查看BMC传感器事件，结果有 A）
ipmcset -d frucontrol -v 0
2、执行下电操作，查看BMC传感器事件，结果有 B）
ipmcset -d frucontrol -v 1
3、模拟ACPI寄存器读取失败的情况，查看BMC传感器事件，结果有 C）
mdbctl setprop set Scanner_PowerGd_0101 bmc.kepler.Scanner Status 1
用例_预期结果
A) 查询事件有产生S0/G0: working事件；
B) 查询事件有产生S5/G2: soft-off事件；
C) 查询事件有产生Unknown事件；
用例_备注