真是很期待啊，码豆要过期啦~~~

【功能模块】创建云测试项目【操作步骤&问题现象】1、填写服务器及部署相关信息后点击提交报错，返货远程服务异常！2、SSH能正常登录，并且实验服务器上部署的项目已正常启动【截图信息】【日志信息】（可选，上传日志内容或者附件）

测试用例编写规范1      用例总体规范【规则1.1】用例名称、测试步骤、预期结果为必填项，缺一不可。【规则1.2】用例名称、前置条件、测试步骤、预期结果描述中均不允许出现模糊或过于抽象的描述，导致引起歧义，也不允许出现过于按照产品界面显示菜单描述，导致在其他产品上继承使用时通用性差。【正例/反例】字段正例反例点评说明用例名称新建信息_新建按钮_单次点击通过左上角New Message新建用户界面上新建按钮的位置很容易变动，所以不宜用"左上角"这样的受约束的词定义。建议使用"新建按钮"这样比较客观的意义严谨的词。前置条件通信录中已经添加联系人　若后续测试步骤有依赖数据时，需要添加前置条件。如：测试短信编写功能，通信录没有保存联系人，则短信编辑界面不显示联系人列表。反例中未描述必要前置条件。测试步骤1、进入信息主界面2、点击新建信息按钮1、在New Message界面，通过左上角选择New message新建短信把操作步骤分割清楚，并且使用严谨的词。预期结果1、进入新建信息编辑界面，短信编辑界面显示收件人、收件人列表和短信内容输入框，界面显示符合UX设计规范要求。1、进入短信编辑明确需要关注的点和测试目的【规则1.3】测试用例之间相互独立，测试用例的测试行为不能依赖其它用例。【建议1.1】用例名称、预置条件、测试步骤、预期结果中不建议使用的模糊关键词，包括但不限于以下范围："等"，"可能"，"部分"，"有的"，"一定范围"，"适量"，"大约"，"一些"，"多个"，"多于"，"少于"，"左右"，"上下"。【建议1.2】测试用例验证目的明确、单一、检查点不宜过多，不建议超过3个。 2      用例命名规则【说明】用例名称应体现测试用例的测试目的或测试点。【规则2.1】“用例名称”要做到简洁，短小，不能包含模糊语句。不要超过40个字符；【规则2.2】“用例名称”需要简要说明用例意图，提炼关键预置条件、步骤和观察点；【规则2.3】“用例名称”在特性范围内唯一，不允许出现重复、包含、叠加的关系，或者仅有数字编号差异。【规则2.4】“用例名称”为中英文字符、数字、下划线、逗号，应尽量避免使用特殊字符，可以用“_”对名称进行分割【建议2.1】 “用例名称”建议采用动宾结构，例如：用例意图_预制条件_观察点，也可以通过“_”追加条件或原因； 【正例/反例】用例名称描述示例正例反例点评说明查询流量策略_非法参数_特殊字符使用包含特殊字符构造的非法参数来查询流量策略正例简洁、提炼关键预置条件，名称使用动宾结构且使用_进行分割，用例意图一目了然；反例中用例名称不够简洁，未对关键预置条件进行提炼分割查询流量策略_非法参数_特殊字符查询流量策略_非法参数_特殊字符@查询流量策略_非法参数_特殊字符#反例中用例名称含有特殊字符，且仅有特殊字符有差异，不符合等价类划分原则。  3      用例描述编写规则【说明】用例描述选填，是对用例的额外说明【建议3.1】建议描述测试目的，也可以进行额外的说明，例如用例的测试范围、测试模板等 4      前置条件编写规则【说明】前置条件是执行测试用例需要的"前提条件"，是测试步骤的先决条件。可以写需要的环境说明、参数设置、测试场景等。具有前置测试条件的测试步骤都应该归入“前置条件”部分进行描述，前置条件中的步骤并不关注其结果的验证，默认任务必须满足预期条件的要求方可开展用例步骤的测试。 【规则4.1】“前置条件”需详细、简洁说明执行测试前的准备事项：如被测对象所处状态、预置数据、预置条件等，杜绝无用、抽象的条件。【规则4.2】用例中的数据需要与处理逻辑分离，相关数据在前置条件中定义并在测试步骤中使用。【正例/反例】AIDL fuzz测试对Python和adb版本号有要求，需在预置条件中明确版本号要求正例反例点评说明1、XXX SDK正确安装2、python安装版本为python34以上3、adb版本为1.3.6以上XXX SDK、python及adb已正常安装反例中前置条件描述过于抽象，未明确标明依赖软件python及adb的版本要求，可能导致不兼容情况发生 【建议4.1】前置条件建议不超过3条，对于难以操作和实现的前置条件要明确操作方法。5      测试步骤编写规则【说明】测试步骤是对测试的“动作”的描述，应简要客观地描述测试的所需的实际操作。【正例/反例】用例名称描述示例正例反例点评说明使用XX工具，强行杀死A模块的进程创造条件，使得A模块异常。反例中未描述如何使A模块异常，不具备指导性拔掉A模块所在机器的网线创造条件，使得A模块异常。反例中未描述如何使A模块异常，不具备指导性【规则5.2】表述中禁止用含二义性、模糊的语句，避免使用概数，如“很多”、“一些”、“部分”等。【规则5.3】 步骤中有需要设置参数的一定要显示说明，不能只有“边界值”、“错误值”、“非法值”、“遍历所有字符”等简单描述。【规则5.4】用例的测试步骤建议在7步以内，超过7步的考虑拆分为多个用例；【建议5.1】测试步骤需尽可能详细，不要遗漏任何测试动作。【建议5.2】没有预期结果对应的测试步骤建议可以和上一步骤合并 6      预期结果编写规则【说明】预期结果是该测试用例针对对应检查点的描述。 【规则6.1】预期结果的描述尽量准确、具体、易确认、有代表性，测试人员可以清楚的判断测试失败还是成功，避免预期结果直接写无错误、无异常等笼统无法检查的描述。【正例/反例】预期结果描述示例正例反例点评说明A接口返回HTTP状态码200，返回值中status值为successA接口返回无异常反例中未描述如何确认A接口返回无异常，不易判断【规则6.2】影响用例最终结果的检查点，一定需要填写预期结果【规则6.3】预期结果中不能出现操作步骤，要将操作步骤和预期结果严格区分开7      用例编号规则【规则7.1】“用例编号”必须包含产品特性，使用特性树中一级特性，且需要使用英文名称；说明：特性作为测试关键资产，承载整个测试活动，以特性为用例集设计的最小单位，一个特性输出一份用例集，用例集由若干用例组成。 用例编号中包含产品特性的英文名称，可以更方便的表示用例所属特性，方便分类归纳。 【建议7.1】“用例编号”可包含产品子特性，使用特性树中的子特性，且需要使用英文名称，不强制要求产品子特性的层级数量，建议和特性树保持一致；【建议7.2】“用例编号”可采取“产品特性_产品子特性_序列号”的格式编写；【建议7.3】“用例编号”的序列号为三位十进制数，从001开始依次排序。如：001，002；【建议7.4】“用例编号”的分隔符可使用“.”号或“_”下划线。【建议7.5】“用例编号”的总长度建议小于40字符。8      测试用例等级选择规则序号级别说明10级最基本的功能验证，用例不宜过多，各模块尽量保证在10-20个，占比5%左右21级基本功能验证，可用于继承特性的基本功能验证、迭代验收前的基本功能验证等，占比20%左右32级重要特性验证，可用于测试版本（非回归版本）中功能测试，占比60%左右43级一般功能/非重要功能验证，包括对基本/重要功能的异常测试，占比10%～15%左右54级非常特殊输入、场景、阈值条件的用例，该级别用例不宜过多，占比0%～5%左右 9      测试类型选择规则【规则9.1】测试类型是创建用例的必选项，测试类型按照质量属性划分为功能性测试、性能测试、兼容性测试等。不同的测试类型验证不同的质量属性，可以发现不同类型的缺陷。 说明：本文档选择质量属性视角划分测试类型，划分参考来源于ISO 25010产品质量属性和华为公司ACT 15立方架构能力。测试类型分为两级，一级测试类型与质量属性对应，华为公司内部统一。二级测试类型由产品自行定制，本文档给出常用的二级测试类型，测试类型全景如下：测试类型全景：ISO 25010产品质量属性华为公司ACT 15立方架构能力（部分）测试类型（一级）测试类型（二级）　功能适应性功能性功能性　　　　功能正确性测试　　　功能交互测试　　　一致性测试性能效率性能性能　　　　性能规格测试　　　资源效率测试   网络性能测试　　　业务服务质量测试兼容性兼容性兼容性　　　　配套兼容性测试　　　互通测试易用性易用性易用性可靠性可靠性可靠性　　　　容错容灾测试　　　过载可靠性测试　　　耐力测试　　　可用性测试安全安全性安全性　　　　安全合规测试   抗攻击性测试　　　韧性测试　　　隐私测试可维护性可服务性可服务性　　　　可部署性测试　　　可维护性测试可移植性　　 10  用例文字表达通用规则【规则10.1】测试用例的表达必须使用相同的测试保留字。测试用例常见保留字列表：序号保留字其他不规范的说法1检查观察、查询、确认、查看2设置赋值、给予、标记3执行运行、操作4重复反复、循环注：本表的保留字仅是测试用例写作的一般用语。【规则10.2】测试用例的表达必须符合测试语法表达规则测试语法表达规则案例类别说明建议的语法举例操作类指执行一个特定操作或动作，主要是指测试执行步骤[操作者][动作][对象][参数]用户按键1234567890#*赋值类指设置某个对象的属性，主要指预置条件设置[对象][属性]为[参数]设置ICD业务字冠为1234567890#*检查类指检查某个对象的属性，主要指预期结果检查[对象][属性]为[参数]检查CTI成功收到的SP_Setup消息，消息中主叫号码139567890#*重复类当需要多次重复执行时重复步骤[X]到步骤[Y]，重复N次重复执行步骤（或流程）3~10，重复2次 【规则10.3】测试用例表达用词要求简洁说明：用例表达精确并不是描述越详细越好，描述复杂的用例可读性差，并且易造成理解上和操作上的困惑。用例表达的简结包括以下几个方面的要求：用例的执行步骤建议在7步以内，超过7步的考虑拆分为多个用例；测试执行的每一步描述中，如果有引用测试执行指导书中内容的，通过标记说明；对于产品技术、测试技术的基本知识和常识，不要在用例中描述；但对于较难理解和掌握的消息，建议在测试指导书中进行说明，不需在每个用例进行说明。举例：以下是一个完整的表达简洁的测试步骤：登录测试系统、切换至“资产”；选择资产树APP；点击“Config”按钮，切换至“PDU”页面；分别设置每页大小为10/30/50并点击左右分页按钮切换页面；填写跳转页面树，点击跳转页面按钮。 【规则10.4】测试用例表达用词要求易确认说明：易确认是针对预期结果而言的，指的是执行完成后根据预期结果能明确知道用例执行的结果是成功还是失败。目前主要的问题是测试用例中的检查点往往过多，因此在用例描述上过于含糊，从而使用例执行是成功还是失败无法确认。【正例/反例】正例反例点评说明检查XXX消息中参数YYY的取值为ZZZ检查消息流程正确反例中未明确消息流程如何判断是否正确检查XXX消息跟踪，跟踪消息全面，对以下关键字段：消息类型、长文件名的解析正确检查消息跟踪、解析正确反例中未明确如何跟踪消息是否全面 【规则10.5】测试用例编写禁用模糊词列表举例：很多、大量、少量、多次、设备无异常、随机、任意、一段时间、一会、一点、特殊、很长、较长、很短、较短、多个、几块、多条、多个、数次、变差、所有、大概、频繁、大约、反复、某些、计数正常、长时间、多端口、异常、错误信息、死循环、正常、最大、最小、非法报文、非法字符、超长、超小、超短、长包、短包、边界值、过低、过高、所有、全部、缺省、默认、各模块。  11  高质量用例八大特征1、验证单一功能2、执行相互独立3、意图表达准确4、易于理解维护5、量化用例数据6、体现产品特性7、准确指导操作8、步骤七步以内

10      用例文字表达通用规则【规则10.1】测试用例的表达必须使用相同的测试保留字。测试用例常见保留字列表：序号保留字其他不规范的说法1检查观察、查询、确认、查看2设置赋值、给予、标记3执行运行、操作4重复反复、循环注：本表的保留字仅是测试用例写作的一般用语。【规则10.2】测试用例的表达必须符合测试语法表达规则测试语法表达规则案例类别说明建议的语法举例操作类指执行一个特定操作或动作，主要是指测试执行步骤[操作者][动作][对象][参数]用户按键1234567890#*赋值类指设置某个对象的属性，主要指预置条件设置[对象][属性]为[参数]设置ICD业务字冠为1234567890#*检查类指检查某个对象的属性，主要指预期结果检查[对象][属性]为[参数]检查CTI成功收到的SP_Setup消息，消息中主叫号码139567890#*重复类当需要多次重复执行时重复步骤[X]到步骤[Y]，重复N次重复执行步骤（或流程）3~10，重复2次 【规则10.3】测试用例表达用词要求简洁说明：用例表达精确并不是描述越详细越好，描述复杂的用例可读性差，并且易造成理解上和操作上的困惑。用例表达的简结包括以下几个方面的要求：用例的执行步骤建议在7步以内，超过7步的考虑拆分为多个用例；测试执行的每一步描述中，如果有引用测试执行指导书中内容的，通过标记说明；对于产品技术、测试技术的基本知识和常识，不要在用例中描述；但对于较难理解和掌握的消息，建议在测试指导书中进行说明，不需在每个用例进行说明。举例：以下是一个完整的表达简洁的测试步骤：登录测试系统、切换至“资产”；选择资产树APP；点击“Config”按钮，切换至“PDU”页面；分别设置每页大小为10/30/50并点击左右分页按钮切换页面；填写跳转页面树，点击跳转页面按钮。 【规则10.4】测试用例表达用词要求易确认说明：易确认是针对预期结果而言的，指的是执行完成后根据预期结果能明确知道用例执行的结果是成功还是失败。目前主要的问题是测试用例中的检查点往往过多，因此在用例描述上过于含糊，从而使用例执行是成功还是失败无法确认。【正例/反例】正例反例点评说明检查XXX消息中参数YYY的取值为ZZZ检查消息流程正确反例中未明确消息流程如何判断是否正确检查XXX消息跟踪，跟踪消息全面，对以下关键字段：消息类型、长文件名的解析正确检查消息跟踪、解析正确反例中未明确如何跟踪消息是否全面 【规则10.5】测试用例编写禁用模糊词列表举例：很多、大量、少量、多次、设备无异常、随机、任意、一段时间、一会、一点、特殊、很长、较长、很短、较短、多个、几块、多条、多个、数次、变差、所有、大概、频繁、大约、反复、某些、计数正常、长时间、多端口、异常、错误信息、死循环、正常、最大、最小、非法报文、非法字符、超长、超小、超短、长包、短包、边界值、过低、过高、所有、全部、缺省、默认、各模块。

9      测试类型选择规则【规则9.1】测试类型是创建用例的必选项，测试类型按照质量属性划分为功能性测试、性能测试、兼容性测试等。不同的测试类型验证不同的质量属性，可以发现不同类型的缺陷。 说明：本文档选择质量属性视角划分测试类型，划分参考来源于ISO 25010产品质量属性和华为公司ACT 15立方架构能力。测试类型分为两级，一级测试类型与质量属性对应，华为公司内部统一。二级测试类型由产品自行定制，本文档给出常用的二级测试类型，测试类型全景如下：测试类型全景：ISO 25010产品质量属性华为公司ACT 15立方架构能力（部分）测试类型（一级）测试类型（二级）　功能适应性功能性功能性　　　　功能正确性测试　　　功能交互测试　　　一致性测试性能效率性能性能　　　　性能规格测试　　　资源效率测试   网络性能测试　　　业务服务质量测试兼容性兼容性兼容性　　　　配套兼容性测试　　　互通测试易用性易用性易用性可靠性可靠性可靠性　　　　容错容灾测试　　　过载可靠性测试　　　耐力测试　　　可用性测试安全安全性安全性　　　　安全合规测试   抗攻击性测试　　　韧性测试　　　隐私测试可维护性可服务性可服务性　　　　可部署性测试　　　可维护性测试可移植性　　 

8      测试用例等级选择规则序号级别说明10级最基本的功能验证，用例不宜过多，各模块尽量保证在10-20个，占比5%左右21级基本功能验证，可用于继承特性的基本功能验证、迭代验收前的基本功能验证等，占比20%左右32级重要特性验证，可用于测试版本（非回归版本）中功能测试，占比60%左右43级一般功能/非重要功能验证，包括对基本/重要功能的异常测试，占比10%～15%左右54级非常特殊输入、场景、阈值条件的用例，该级别用例不宜过多，占比0%～5%左右

7      用例编号规则【规则7.1】“用例编号”必须包含产品特性，使用特性树中一级特性，且需要使用英文名称；说明：特性作为测试关键资产，承载整个测试活动，以特性为用例集设计的最小单位，一个特性输出一份用例集，用例集由若干用例组成。 用例编号中包含产品特性的英文名称，可以更方便的表示用例所属特性，方便分类归纳。 【建议7.1】“用例编号”可包含产品子特性，可以使用特性树中的子特性。 建议用例编号为英文、数字、下划线、点组成，不强制要求产品子特性的层级数量，建议和特性树保持一致；【建议7.2】“用例编号”可采取“产品特性_产品子特性_序列号”的格式编写；【建议7.3】“用例编号”的序列号为三位十进制数，从001开始依次排序。如：001，002；【建议7.4】“用例编号”的分隔符可使用“.”号或“_”下划线。【建议7.5】“用例编号”的总长度建议小于40字符。

6      预期结果编写规则【说明】预期结果是该测试用例针对对应检查点的描述。 【规则6.1】预期结果的描述尽量准确、具体、易确认、有代表性，测试人员可以清楚的判断测试失败还是成功，避免预期结果直接写无错误、无异常等笼统无法检查的描述。【正例/反例】预期结果描述示例正例反例点评说明A接口返回HTTP状态码200，返回值中status值为successA接口返回无异常反例中未描述如何确认A接口返回无异常，不易判断【规则6.2】影响用例最终结果的检查点，一定需要填写预期结果【规则6.3】预期结果中不能出现操作步骤，要将操作步骤和预期结果严格区分开

5      测试步骤编写规则【说明】测试步骤是对测试的“动作”的描述，应简要客观地描述测试的所需的实际操作。【正例/反例】用例名称描述示例正例反例点评说明使用XX工具，强行杀死A模块的进程创造条件，使得A模块异常。反例中未描述如何使A模块异常，不具备指导性拔掉A模块所在机器的网线创造条件，使得A模块异常。反例中未描述如何使A模块异常，不具备指导性【规则5.2】表述中禁止用含二义性、模糊的语句，避免使用概数，如“很多”、“一些”、“部分”等。【规则5.3】 步骤中有需要设置参数的一定要显示说明，不能只有“边界值”、“错误值”、“非法值”、“遍历所有字符”等简单描述。【规则5.4】用例的测试步骤建议在7步以内，超过7步的考虑拆分为多个用例；【建议5.1】测试步骤需尽可能详细，不要遗漏任何测试动作。【建议5.2】没有预期结果对应的测试步骤建议可以和上一步骤合并

4      前置条件编写规则【说明】前置条件是执行测试用例需要的"前提条件"，是测试步骤的先决条件。可以写需要的环境说明、参数设置、测试场景等。具有前置测试条件的测试步骤都应该归入“前置条件”部分进行描述，前置条件中的步骤并不关注其结果的验证，默认任务必须满足预期条件的要求方可开展用例步骤的测试。 【规则4.1】“前置条件”需详细、简洁说明执行测试前的准备事项：如被测对象所处状态、预置数据、预置条件等，杜绝无用、抽象的条件。【规则4.2】用例中的数据需要与处理逻辑分离，相关数据在前置条件中定义并在测试步骤中使用。【正例/反例】AIDL fuzz测试对Python和adb版本号有要求，需在预置条件中明确版本号要求正例反例点评说明1、XXX SDK正确安装2、python安装版本为python34以上3、adb版本为1.3.6以上XXX SDK、python及adb已正常安装反例中前置条件描述过于抽象，未明确标明依赖软件python及adb的版本要求，可能导致不兼容情况发生 【建议4.1】前置条件建议不超过3条，对于难以操作和实现的前置条件要明确操作方法。

3      用例描述编写规则【说明】用例描述选填，是对用例的额外说明【建议3.1】建议描述测试目的，也可以进行额外的说明，例如用例的测试范围、测试模板等

2      用例命名规则【说明】用例名称应体现测试用例的测试目的或测试点。【规则2.1】“用例名称”要做到简洁，短小，不能包含模糊语句。不要超过40个字符；【规则2.2】“用例名称”需要简要说明用例意图，提炼关键预置条件、步骤和观察点；【规则2.3】“用例名称”在特性范围内唯一，不允许出现重复、包含、叠加的关系，或者仅有数字编号差异。【规则2.4】“用例名称”为中英文字符、数字、下划线、逗号，应尽量避免使用特殊字符，可以用“_”对名称进行分割【建议2.1】 “用例名称”建议采用动宾结构，例如：用例意图_预制条件_观察点，也可以通过“_”追加条件或原因； 【正例/反例】用例名称描述示例正例反例点评说明查询流量策略_非法参数_特殊字符使用包含特殊字符构造的非法参数来查询流量策略正例简洁、提炼关键预置条件，名称使用动宾结构且使用_进行分割，用例意图一目了然；反例中用例名称不够简洁，未对关键预置条件进行提炼分割查询流量策略_非法参数_特殊字符查询流量策略_非法参数_特殊字符@查询流量策略_非法参数_特殊字符#反例中用例名称含有特殊字符，且仅有特殊字符有差异，不符合等价类划分原则。  

1      用例总体规范【规则1.1】用例名称、测试步骤、预期结果为必填项，缺一不可。【规则1.2】用例名称、前置条件、测试步骤、预期结果描述中均不允许出现模糊或过于抽象的描述，导致引起歧义，也不允许出现过于按照产品界面显示菜单描述，导致在其他产品上继承使用时通用性差。【正例/反例】字段正例反例点评说明用例名称新建信息_新建按钮_单次点击通过左上角New Message新建用户界面上新建按钮的位置很容易变动，所以不宜用"左上角"这样的受约束的词定义。建议使用"新建按钮"这样比较客观的意义严谨的词。前置条件通信录中已经添加联系人　若后续测试步骤有依赖数据时，需要添加前置条件。如：测试短信编写功能，通信录没有保存联系人，则短信编辑界面不显示联系人列表。反例中未描述必要前置条件。测试步骤1、进入信息主界面2、点击新建信息按钮1、在New Message界面，通过左上角选择New message新建短信把操作步骤分割清楚，并且使用严谨的词。预期结果1、进入新建信息编辑界面，短信编辑界面显示收件人、收件人列表和短信内容输入框，界面显示符合UX设计规范要求。1、进入短信编辑明确需要关注的点和测试目的【规则1.3】测试用例之间相互独立，测试用例的测试行为不能依赖其它用例。【建议1.1】用例名称、预置条件、测试步骤、预期结果中不建议使用的模糊关键词，包括但不限于以下范围："等"，"可能"，"部分"，"有的"，"一定范围"，"适量"，"大约"，"一些"，"多个"，"多于"，"少于"，"左右"，"上下"。【建议1.2】测试用例验证目的明确、单一、检查点不宜过多，不建议超过3个。

测试用例编写规范1      用例命名规则规则1.1“用例名称”要做到简洁，短小，不能包含模糊语句。不要超过60个字符；规则1.2“用例名称”需要简要说明用例意图，提炼关键预置条件、步骤和观察点；建议1.1 “用例名称”建议采用动宾结构，例如：用例意图_预制条件_观察点，也可以通过“_”追加条件或原因；建议1.3 “用例名称”在特性范围内唯一；建议1.3“用例名称”中应尽量避免使用标点符号，可以用“_”进行代替，如“查询流策略_非法参数_特殊字符”或最多使用一个“,”（英文逗号）。 2      执行方式选择规则规则2.1 执行方式表明该用例在执行时所使用的工具，默认为手工测试。 3      用例描述编写规则规则3.1  建议描述测试目的，也可以进行额外的说明，例如用例的测试范围、测试模板等 4      前置条件编写规则规则4.1 用例中的数据需要与处理逻辑分离，定义的数据在测试步骤中使用。规则4.2 前置条件需详细、简洁说明执行测试前的准备事项：如被测对象所处状态、预置数据、预置条件等。 5      测试步骤编写规则举例：创造条件，使得XX模块异常。不如描述为：使用YY工具，强行杀死XX模块的进程。或者：拔掉XX模块所在机器的网线。规则5.2 表述中禁止用含二义性、模糊的语句，避免使用概数，如“很多”、“一些”、“部分”等。建议5.1 测试步骤需尽可能详细，不要遗漏任何测试动作。建议5.2 描述必须使用相同的测试保留字，同一用词在所有步骤中保持一致。 6      预期结果编写规则规则6.1 预期结果的描述尽量准确、具体、易确认、有代表性，不要出现难以观察和判断的结果举例：如某个用例的预期结果A：而实际执行后结果为B，并且B也是正确的。这是不允许的。注意：这里说的执行结果不是指的观察点，一个用例可以有多个观察点 规则6.2 影响用例最终结果的检查点，一定需要填写预期结果 7      用例编号规则规则7.1“用例编号”必须包含产品特性，使用特性树中一级特性，且需要使用英文名称；说明：特性作为测试关键资产，承载整个测试活动，包括测试设计、测试策略、测试执行、测试评估等环节都以特性为维度开展，一般而言，特性名称等于场景责任田名称。以特性为用例集设计的最小单位，一个特性输出一份用例集，用例集由若干用例组成，按测试类型分别验证特性的功能、性能、可靠性等。 用例编号中包含产品特性的英文名称，可以更方便的表示用例所属特性，方便分类归纳。 建议7.1 “用例编号”可包含产品子特性，使用特性树中的子特性，且需要使用英文名称，不强制要求产品子特性的层级数量，建议和特性树保持一致；建议7.2 “用例编号”可采取“产品特性_产品子特性_序列号”的格式编写；建议7.3“用例编号”的序列号为三位十进制数，从001开始依次排序。如：001，002；建议7.4“用例编号”的分隔符可使用“.”号或“_”下划线。建议7.5“用例编号”的总长度建议小于40字符。8      测试用例等级选择规则序号级别说明10级最基本的功能验证，用例不宜过多，各模块尽量保证在10-20个，占比5%左右21级基本功能验证，可用于继承特性的基本功能验证、迭代验收前的基本功能验证等，占比20%左右32级重要特性验证，可用于测试版本（非回归版本）中功能测试，占比60%左右43级一般功能/非重要功能验证，包括对基本/重要功能的异常测试，占比10%～15%左右54级非常特殊输入、场景、阈值条件的用例，该级别用例不宜过多，占比0%～5%左右 9      测试类型选择规则规则9.1 测试类型是创建用例的必选项，测试类型按照质量属性划分为功能性测试、性能测试、兼容性测试等。不同的测试类型验证不同的质量属性，可以发现不同类型的缺陷。 说明：本文档选择质量属性视角划分测试类型，划分参考来源于ISO 25010产品质量属性和华为公司ACT 15立方架构能力。测试类型分为两级，一级测试类型与质量属性对应，华为公司内部统一。二级测试类型由产品自行定制，本文档给出常用的二级测试类型，测试类型全景如下：测试类型全景：ISO 25010产品质量属性华为公司ACT 15立方架构能力（部分）测试类型（一级）测试类型（二级）　功能适应性功能性功能性　　　　功能正确性测试　　　功能交互测试　　　一致性测试性能效率性能性能　　　　性能规格测试　　　资源效率测试   网络性能测试　　　业务服务质量测试兼容性兼容性兼容性　　　　配套兼容性测试　　　互通测试易用性易用性易用性可靠性可靠性可靠性　　　　容错容灾测试　　　过载可靠性测试　　　耐力测试　　　可用性测试安全安全性安全性　　　　安全合规测试   抗攻击性测试　　　韧性测试　　　隐私测试可维护性可服务性可服务性　　　　可部署性测试　　　可维护性测试可移植性　　 10  用例文字表达通用规则规则10.1 测试用例的表达必须使用相同的测试保留字。测试用例常见保留字列表：序号保留字其他不规范的说法1检查观察、查询、确认、查看2设置赋值、给予、标记3执行运行、操作4重复反复、循环注：本表的保留字仅是测试用例写作的一般用语。规则10.2 测试用例的表达必须符合测试语法表达规则测试语法表达规则案例类别说明建议的语法举例操作类指执行一个特定操作或动作，主要是指测试执行步骤[操作者][动作][对象][参数]用户按键1234567890#*赋值类指设置某个对象的属性，主要指预置条件设置[对象][属性]为[参数]设置ICD业务字冠为1234567890#*检查类指检查某个对象的属性，主要指预期结果检查[对象][属性]为[参数]检查CTI成功收到的SP_Setup消息，消息中主叫号码139567890#*重复类当需要多次重复执行时重复步骤[X]到步骤[Y]，重复N次重复执行步骤（或流程）3~10，重复2次 规则10.3 测试用例表达用词要求简洁说明：用例表达精确并不是描述越详细越好，描述复杂的用例可读性差，并且易造成理解上和操作上的困惑。用例表达的简结包括以下几个方面的要求：用例的执行步骤建议在7步以内，超过7步的考虑拆分为多个用例；测试执行的每一步描述中，如果有引用测试执行指导书中内容的，通过标记说明；对于产品技术、测试技术的基本知识和常识，不要在用例中描述；但对于较难理解和掌握的消息，建议在测试指导书中进行说明，不需在每个用例进行说明。举例：以下是一个完整的表达简洁的测试步骤：登录测试系统、切换至“资产”；选择资产树APP；点击“Config”按钮，切换至“PDU”页面；分别设置每页大小为10/30/50并点击左右分页按钮切换页面；填写跳转页面树，点击跳转页面按钮。 规则10.4 测试用例表达用词要求易确认说明：易确认是针对预期结果而言的，指的是执行完成后根据预期结果能明确知道用例执行的结果是成功还是失败。目前主要的问题是测试用例中的检查点往往过多，因此在用例描述上过于含糊，从而使用例执行是成功还是失败无法确认。举例：如下面的预期结果：检查消息流程正确。不如描述为：检查XXX消息中参数YYY的取值为ZZZ。如下面的预期结果：检查消息跟踪、解析正确。不如描述为：检查XXX消息跟踪，跟踪消息全面，对关键字段，如消息类型、长文件名的解析正确。 规则10.5 测试用例编写禁用模糊词列表举例：很多、大量、少量、多次、设备无异常、随机、任意、一段时间、一会、一点、特殊、很长、较长、很短、较短、多个、几块、多条、多个、数次、变差、所有、大概、频繁、大约、反复、某些、计数正常、长时间、多端口、异常、错误信息、死循环、正常、最大、最小、非法报文、非法字符、超长、超小、超短、长包、短包、边界值、过低、过高、所有、全部、缺省、默认、各模块。11  高质量用例八大特征1、验证单一功能2、执行相互独立3、意图表达准确4、易于理解维护5、量化用例数据6、体现产品特性7、准确指导操作8、步骤七步以内

                                                                  测试用例编写规范1      用例命名规则规则1.1“用例名称”要做到简洁，短小，不能包含模糊语句。不要超过60个字符；规则1.2“用例名称”需要简要说明用例意图，提炼关键预置条件、步骤和观察点；建议1.1 “用例名称”建议采用动宾结构，例如：用例意图_预制条件_观察点，也可以通过“_”追加条件或原因；建议1.3 “测试用例名称”在特性范围内唯一；建议1.3“测试用例名称”中应尽量避免使用标点符号，可以用“_”进行代替，如“查询流策略_非法参数_特殊字符”或最多使用一个“,”（英文逗号）。 2      执行方式选择规则规则2.1 执行方式表明该用例在执行时所使用的工具，默认为手工测试。 3      用例描述编写规则规则3.1  建议描述测试目的，也可以进行额外的说明，例如用例的测试范围、测试模板等 4      前置条件编写规则规则4.1 用例中的数据需要与处理逻辑分离，定义的数据在测试步骤中使用。规则4.2 前置条件需详细、简洁说明执行测试前的准备事项：如被测对象所处状态、预置数据、预置条件等。 5      测试步骤编写规则举例：创造条件，使得XX模块异常。不如描述为：使用YY工具，强行杀死XX模块的进程。或者：拔掉XX模块所在机器的网线。规则5.2 表述中禁止用含二义性、模糊的语句，避免使用概数，如“很多”、“一些”、“部分”等。建议5.1 测试步骤需尽可能详细，不要遗漏任何测试动作。建议5.2 描述必须使用相同的测试保留字，同一用词在所有步骤中保持一致。 6      预期结果编写规则规则6.1 预期结果的描述尽量准确、具体、易确认、有代表性，不要出现难以观察和判断的结果举例：如某个用例的预期结果A：而实际执行后结果为B，并且B也是正确的。这是不允许的。注意：这里说的执行结果不是指的观察点，一个用例可以有多个观察点 规则6.2 影响用例最终结果的检查点，一定需要填写预期结果 7      用例编号规则规则7.1“用例编号”必须包含产品特性，使用特性树中一级特性，且需要使用英文名称；说明：特性作为测试关键资产，承载整个测试活动，包括测试设计、测试策略、测试执行、测试评估等环节都以特性为维度开展，一般而言，特性名称等于场景责任田名称。以特性为用例集设计的最小单位，一个特性输出一份用例集，用例集由若干用例组成，按测试类型分别验证特性的功能、性能、可靠性等。 用例编号中包含产品特性的英文名称，可以更方便的表示用例所属特性，方便分类归纳。 建议7.1 “用例编号”可包含产品子特性，使用特性树中的子特性，且需要使用英文名称，不强制要求产品子特性的层级数量，建议和特性树保持一致；建议7.2 “用例编号”可采取“产品特性_产品子特性_序列号”的格式编写；建议7.3“用例编号”的序列号为三位十进制数，从001开始依次排序。如：001，002；建议7.4“测试用例编号”的分隔符可使用“.”号或“_”下划线。8      测试用例等级选择规则序号级别说明10级最基本的功能验证，用例不宜过多，各模块尽量保证在10-20个，占比5%左右21级基本功能验证，可用于继承特性的基本功能验证、迭代验收前的基本功能验证等，占比20%左右32级重要特性验证，可用于测试版本（非回归版本）中功能测试，占比60%左右43级一般功能/非重要功能验证，包括对基本/重要功能的异常测试，占比10%～15%左右54级非常特殊输入、场景、阈值条件的用例，该级别用例不宜过多，占比0%～5%左右 9      测试类型选择规则规则9.1 测试类型是创建用例的必选项，测试类型按照质量属性划分为功能性测试、性能测试、兼容性测试等。不同的测试类型验证不同的质量属性，可以发现不同类型的缺陷。 说明：本文档选择质量属性视角划分测试类型，划分参考来源于ISO 25010产品质量属性和华为公司ACT 15立方架构能力。测试类型分为两级，一级测试类型与质量属性对应，华为公司内部统一。二级测试类型由产品自行定制，本文档给出常用的二级测试类型，测试类型全景如下：测试类型全景：ISO 25010产品质量属性华为公司ACT 15立方架构能力（部分）测试类型（一级）测试类型（二级）　功能适应性功能性功能性　　　　功能正确性测试　　　功能交互测试　　　一致性测试性能效率性能性能　　　　性能规格测试　　　资源效率测试   网络性能测试　　　业务服务质量测试兼容性兼容性兼容性　　　　配套兼容性测试　　　互通测试易用性易用性易用性可靠性可靠性可靠性　　　　容错容灾测试　　　过载可靠性测试　　　耐力测试　　　可用性测试安全安全性安全性　　　　安全合规测试   抗攻击性测试　　　韧性测试　　　隐私测试可维护性可服务性可服务性　　　　可部署性测试　　　可维护性测试可移植性　　 10  用例文字表达通用规则规则10.1 测试用例的表达必须使用相同的测试保留字。测试用例常见保留字列表：序号保留字其他不规范的说法1检查观察、查询、确认、查看2设置赋值、给予、标记3执行运行、操作4重复反复、循环注：本表的保留字仅是测试用例写作的一般用语。规则10.2 测试用例的表达必须符合测试语法表达规则测试语法表达规则案例类别说明建议的语法举例操作类指执行一个特定操作或动作，主要是指测试执行步骤[操作者][动作][对象][参数]用户按键1234567890#*赋值类指设置某个对象的属性，主要指预置条件设置[对象][属性]为[参数]设置ICD业务字冠为1234567890#*检查类指检查某个对象的属性，主要指预期结果检查[对象][属性]为[参数]检查CTI成功收到的SP_Setup消息，消息中主叫号码139567890#*重复类当需要多次重复执行时重复步骤[X]到步骤[Y]，重复N次重复执行步骤（或流程）3~10，重复2次 规则10.3 测试用例表达用词要求简洁说明：用例表达精确并不是描述越详细越好，描述复杂的用例可读性差，并且易造成理解上和操作上的困惑。用例表达的简结包括以下几个方面的要求：用例的执行步骤建议在7步以内，超过7步的考虑拆分为多个用例；测试执行的每一步描述中，如果有引用测试执行指导书中内容的，通过标记说明；对于产品技术、测试技术的基本知识和常识，不要在用例中描述；但对于较难理解和掌握的消息，建议在测试指导书中进行说明，不需在每个用例进行说明。举例：以下是一个完整的表达简洁的测试步骤：登录测试系统、切换至“资产”；选择资产树APP；点击“Config”按钮，切换至“PDU”页面；分别设置每页大小为10/30/50并点击左右分页按钮切换页面；填写跳转页面树，点击跳转页面按钮。 规则10.4 测试用例表达用词要求易确认说明：易确认是针对预期结果而言的，指的是执行完成后根据预期结果能明确知道用例执行的结果是成功还是失败。目前主要的问题是测试用例中的检查点往往过多，因此在用例描述上过于含糊，从而使用例执行是成功还是失败无法确认。举例：如下面的预期结果：检查消息流程正确。不如描述为：检查XXX消息中参数YYY的取值为ZZZ。如下面的预期结果：检查消息跟踪、解析正确。不如描述为：检查XXX消息跟踪，跟踪消息全面，对关键字段，如消息类型、长文件名的解析正确。 规则10.5 测试用例编写禁用模糊词列表举例：很多、大量、少量、多次、设备无异常、随机、任意、一段时间、一会、一点、特殊、很长、较长、很短、较短、多个、几块、多条、多个、数次、变差、所有、大概、频繁、大约、反复、某些、计数正常、长时间、多端口、异常、错误信息、死循环、正常、最大、最小、非法报文、非法字符、超长、超小、超短、长包、短包、边界值、过低、过高、所有、全部、缺省、默认、各模块。11  高质量用例八大特征1、验证单一功能2、执行相互独立3、意图表达准确4、易于理解维护5、量化用例数据6、体现产品特性7、准确指导操作8、步骤七步以内