自动化测试设计规范V1.0
(仅供内部使用） For internal use only
Prepared by
拟制 Reviewed by 评审人
孟咏喜 00137435 顾江00118951 张杰飞 00101597
Approved by
批准 Authorized by
签发
Date 日期 Date 日期
yyyy-mm-dd yyyy-mm-dd
陈玉梅 37906
Date 日期 Date 日期
2010-12-16 2010-12-15
Huawei Technologies
Co., Ltd. 华为技术有限公司
All rights reserved 版权所有 侵权必究
Revision record 修订记录
1 前言
本规范适用于指导基于AutoSpace自动化测试平台的自动化测试设计活动，目的是通过规范性指导提升自动化测试设计质量。
自动化测试设计的活动流程如图所示：
自动化测试设计活动角色主要分为两种： 自动化设计人员（如TSE、测试骨干）
负责自动化用例设计前的设计活动，包括自动化测试分析、AW设计、数据规划、测试工程设计等 自动化测试工程师
负责自动化用例设计
本文将按照自动化测试设计流程，分别介绍各个活动的设计规范和指导原则。
2 自动化测试分析
自动化测试分析过程，重点分析产品特性哪些适合自动化、哪些特性应优先实现自动化。 适合自动化的范围包括：
1. 产品特性相对比较稳定，变化不是非常大
2. 产品特性重要程度高，每轮版本测试、回归测试基本都是必测的 3. 自动化投入成本在接受范围内，最好已有技术储备
通过如上三个维度分析自动化实现的优先级，应优先实现投入产出比收益明显的产品特性，即自动化较易于实现、且需要频繁测试的重要特性。
3 AW设计
AW是自动化用例设计的基础，应易于理解、好用，便于测试人员快速掌握，降低学习成本，提高用例设计效率。
AW设计的基本原则是基于业务进行抽象、设计粒度合理，尽可能覆盖自动化用例。 对于底层AW（如协议AW），应封装为类似“开户”、“用户认证”、“拨号”等业务逻辑，降低用例设计难度和接口变更时对用例的影响，提升自动化用例的重用性。
3.1 可用性
3.1.1
AW及AW参数命名清晰，有明确的含义
AW命名要简洁、易懂，便于测试人员一眼便知其大概含义，降低学习成本。 AW命名格式可参考：
同样，AW参数命名应易于理解，例如：手机型号 3.1.2
AW命名风格应统一，避免中英文混用
不规范示例：
3.1.3
AW及AW参数应定义别名
AW和AW参数定义别名（Alias），避免因修改AW或AW参数而引起自动化用例脚本不兼容性问题。别名建议英文化，同时命名含义明确，便于AW开发实现。 规范示例：
3.1 可用性
3.1.1
AW及AW参数命名清晰，有明确的含义
AW命名要简洁、易懂，便于测试人员一眼便知其大概含义，降低学习成本。 AW命名格式可参考：
同样，AW参数命名应易于理解，例如：手机型号 3.1.2
AW命名风格应统一，避免中英文混用
不规范示例：
3.1.3
AW及AW参数应定义别名
AW和AW参数定义别名（Alias），避免因修改AW或AW参数而引起自动化用例脚本不兼容性问题。别名建议英文化，同时命名含义明确，便于AW开发实现。 规范示例：
2015-11-10
华为机密，未经许可不得扩散 第5页, 共28页
不规范示例：
3.1.4
AW及AW参数说明信息应尽量详细
AW及AW参数说明信息应尽量详细，方便指导测试设计人员快速掌握AW的使用，降低AW的学习成本。 规范示例：
图：AW说明信息规范样例
2015-11-10
华为机密，未经许可不得扩散 第6页, 共28页
图：AW参数说明信息规范样例
3.1.5 例如：
AW参数 “预期结果”，建议用“成功”、“失败”作为参数值，而不是数字“0”、“1” 规范示例：
AW参数值建议采用人性化的语言描述
不规范示例：
3.1.6
AW参数值有多个取值时，应置为枚举值
AW参数有多个取值时，应在ValuePool中设置枚举值，便于用例设计时快速选择。 规范示例：
2015-11-10
华为机密，未经许可不得扩散 第7页, 共28页
图：AW参数置为枚举值示例
图：用例设计时AW参数值的选择示例
3.1.7 AW参数的常用值应设置为默认值
若AW参数值有常用值，应将常用值设置为AW参数的默认值，减少用例设计的AW参数值输入，提高用例设计效率。 规范示例：
3.1.8
AW参数可通过分组，保证参数结构的清晰
规范示例：
2015-11-10
华为机密，未经许可不得扩散
第8页, 共28页
3.1.9
AW可通过分组，保证AW结构的清晰
按照产品特性对AW进行合理分组保持结构清晰，让自动化用例设计时方便选择AW。 规范示例：
3.1.10 正确区分“必填”和“可填”的AW参数
AW参数中，有的参数值不允许为空即必须填写，有的参数填写是可选的。在AW设计时，AW参数应正确设置“Can Empty”选项值，明确该参数是否必填。 规范示例：
2015-11-10
华为机密，未经许可不得扩散 第9页, 共28页
图：AW参数置为不允许为空的示例
图：用例设计时必填和可填参数以图标区分的示例
3.1.11 AW参数个数不宜太多，可将复杂参数设计为外挂参数
AW参数个数不宜太多，否则用例设计时填写AW参数值很不方便。
复杂的AW参数可设计为外挂参数，通过外挂对话框辅助输入。
规范示例：
图： AW参数置为外挂参数示例
2015-11-10
华为机密，未经许可不得扩散 第10页, 共28页
图： 用例设计时通过外挂对话框辅助参数输入的示例
3.2 Logic封装
业务封装的基本原则：基于业务封装，Logic参数应体现业务，屏蔽具体底层实现细节。 业务逻辑封装的好处：
Logic体现测试的业务，测试人员设计用例时不用关心底层细节、上手容易 Logic参数一般不多，测试人员设计用例方便，提高用例设计效率
业务或接口变更时，往往只要修改Logic内部逻辑，而不用维护大量的自动化用例
脚本，提升自动化用例的重用性
规范示例：
示例1：
2015-11-10
华为机密，未经许可不得扩散 第11页, 共28页
图：基于协议的业务封装示例
示例1中将Soap协议细节封装在Logic，Logic对外的参数是ServiceID、ServiceName等业务参数，测试人员不用关心Soap协议的WSDL文件、Soap消息体的结构等内部细节。
示例2：
图：基于Web控件基本操作的业务封装示例
示例2中将Web控件的基本操作封装在Logic中，Logic对外的参数是控件名称、日期等业务参数，测试人员在用例设计时不用关心每个控件的基本操作，减少用例步骤，降2015-11-10
华为机密，未经许可不得扩散 第12页, 共28页
低用例设计难度，提升用例的重用性。
不规范示例：
示例中业务逻辑参数没有体现业务，仍是协议层面的实现细节。
示例中，Logic的参数体现的仍是底层协议细节，封装粒度不合理，应该基于业务进行抽象和封装。
3.3 公共AW使用
公共AW使用应遵循两个基本原则：
尽量使用AutoSpace平台提供的公共AW，避免重复设计和开发
公共AW应使用引用方式，不应将公共AW直接合并到自定义AW文件中
公共AW采用引用方式的好处有：
引用的公共AW无法编辑，避免误操作
公共AW升级时可自动升级，无需手工升级
规范示例：
2015-11-10
华为机密，未经许可不得扩散 第13页, 共28页
不规范示例：
4 数据规划
根据产品特性，应事先规划自动化测试需要的基础业务数据。这些预先规划好的数据，可以在测试环境搭建时预置到被测系统中。
自动化用例设计时可直接使用这些数据，简化用例的数据准备，一定程度上可提高用例执行效率。
数据规划举例：
一个网上银行系统，实现用户之间的汇款业务。用户分为两种：
VIP用户：汇款不收手续费
普通用户：汇款收手续费
2015-11-10
华为机密，未经许可不得扩散 第14页, 共28页
用户信息定义如下：
自动化测试设计时，应考虑普通用户和普通用户、普通用户和VIP用户、VIP用户和 VIP用户之间的汇款是否正确扣手续费用。 因此，我们可以规划如下基础的用户数据：
5 测试工程设计
测试工程是自动化执行需要的所有文件的集合，包括：AW定义文件、Replace文件、AW实现体文件、外挂文件、AW实现体的配置文件等。
5.1 所有工程文件应放在工程目录中
规范示例：
5.2 工程文件的路径应置为相对路径
工程文件的路径应设置为相对路径，且相对于工程目录。 规范示例：
图：工程目录下所有文件都置为相对路径示例
图：AW实现体文件置为相对路径的示例
图：参数外挂文件置为相对路径的示例
5.3 Repalce文件定义
测试环境的数据（如IP地址、端口号等）、基础业务数据，可以作为全局变量定义在Replace文件中。用例设计时使用这些变量，实现用例脚本和数据分离，提升用例的重用性。
定义的变量应易于理解、好用，方便自动化用例设计。
5.3.1 变量命名应清晰、有明确含义
Replace变量命名规则为：VAR_xxx
其中xxx为变量名称，其命名应清晰、有明确含义。 规范示例：
5.3.2
变量含义说明应清晰、易懂
变量定义时应给出变量的含义说明，要求清晰、易懂，方便自动化用例设计时正确使用。
规范示例：
5.3.3
变量较多时，应通过分组保证结构清晰
按照环境部件、业务数据类型，对Replace变量进行合理分组，保持结构清晰、提高文件的维护效率。 规范示例：
6 自动化用例设计
自动化用例设计应遵循四个基本原则：
6.1 用例的独立性
6.1.1
用例申请的资源应在本用例的Aftershell中及时释放，避免用例间的干扰
用例常见的申请或改变的资源类型包括：
注：资源释放应放在用例的AfterShell中，不建议在下一个用例的Preshell中。因为AfterShell中的AW执行失败后仍执行后续AW，会将用例间的影响降到最低。
规范示例：
不规范示例：
例如：后置脚本不应该放在Preshell中
6.1.2
如果有类似“初始化环境”AW可保证用例独立性，该AW应放在每个用例PreShell的第一个步骤
如果类似“初始化环境”AW可保证用例独立性，则用例的AfterShell可以不释放本用例申请的资源。但类似“初始化环境”AW必须放在每个用例PreShell的第一个步骤。 规范示例：
6.1.3 用例特性的资源申请必须在本用例特性中的AfterShell中及时释放
若特性下所有用例的部分资源申请相同，可以在用例特性的Preshell中申请，无需在特性下每个用例中重复申请和释放，以提高用例执行效率。
此时，必须在用例特性的AfterShell及时释放资源，避免不同用例特性间的干扰。
6.1.4 用例设计时应尽量避免修改预先规划的测试数据
建议用例设计时应尽量避免修改预先规划的测试数据。
如修改了预先规划的测试数据，需要在Aftershell中对用例预置条件、被测系统执行过程中修改或产生的数据进行恢复
6.1.5 Shell AW尽量避免使用cd命令，防止因当前路径更改导致后续用例执行失败
不规范示例：
6.2 用例的重用性
6.2.1
环境数据 (如IP、Port等)应使用变量，不允许直接使用常量
环境数据建议在AutoSpace的Replace文件中定义为全局变量，用例设计时使用变量引用环境数据。
不允许在自动化测试用例中使用与测试环境相关的常量字符串，如“10.71.97.32” 规范示例：
环境数据定义为全局变量，用例设计时使用变量
不规范示例：
6.2.2
文件应使用相对路径，避免使用绝对路径
对于本地文件，建议存放在测试工程目录中。
用例中的文件路径应使用相对路径，避免换为另一台机器时出现文件找不到的问题。 规范示例：
不规范示例：
6.2.3
基于业务将实现特定功能的一组AW封装为业务逻辑（Logic），降低接口变更对用例的影响
基于业务，将底层AW（如协议AW）封装为类似“开户”、“用户认证”、“拨号”等业务逻辑，降低用例设计难度和接口变更时对用例的影响。 规范示例：
例如：“登录页面校验”Logic基于业务将底层的HTTP协议交互、消息处理等进行封装。
当HTTP协议消息值有变更时，只需要修改“登录页面校验”Logic，无需批量修改自动化用例脚本，自动化用例重用性较高。
不规范示例：
6.3 用例的可读性
6.3.1
通过添加必要的注释、合理分组、业务逻辑封装，保证用例结构的清晰
规范示例：
图1: 用例步骤添加注释
图2: 用例步骤添加分组
图3: 基于业务进行逻辑封装
不规范示例：
6.3.2 预置条件、测试步骤、后置脚本应正确写到用例的Preshell、CaseStep、AfterShell
前置条件、测试步骤、后置脚本应正确放在PreShell、CaseStep、AfterShell页面中，与文本用例保持一致，保证用例结构清晰。
不规范示例：
不建议将用例的预置条件、测试步骤、后置脚本全填写在一处（如Preshell）。
6.4 用例的健壮性
6.4.1 用例包含多AW集时，应使用“同步点AW”做好同步
模拟不同实体（如主叫、被叫）时会用到多个AW集并发执行。
建议通过“同步点设置”和“同步点等待”AW做好AW集的同步，避免因异步导致用例执行的不稳定
规范示例：
6.4.2 尽量避免使用时延性AW
时延性AW，如启动xxx服务，可能存在该AW执行完，但服务还未完全启动好。尽量避免这类时延性AW。
如果某些场景需要，建议添加一个校验AW，如通过定时检查等方法确认时延AW效果是否达到，避免因受机器速度、测试环境等影响导致自动化执行的不稳定性。
6.5 用例的变量
6.5.1 使用全局变量时，建议以$开头
局部变量以$开头，例如：$RecvMessage。建议全局变量和局部变量引用方式统一，全局变量也采用$开头，例如：$VAR_RequestUrl_cc
规范示例：
6.5.2 准确定义和使用变量作用域
变量作用域有三种，定义规范如下：
6.5.3 变量命名应清晰、有明确含义
例如：$VAR_PortalServer_IP、&RecvMessage、$SessionID
6.5.4 避免只定义而不使用变量，即&和$变量应成对出现
例如：一个AW输出变量&SessionID，后续应该有$SessionID引用该变量。 避免只定义而不使用的冗余变量。
6.6 用例的结果检查
6.6.1 尽量使用AW的返回值或输出参数作为检查点，不建议将日志列为关键检查项
常见的检查项主要包括：
1. 数据库检查
2. 话单检查
3. 响应消息内容检查
AW的结果检查应尽可能全面，用例执行失败时应在第一个可以检查出失败的AW上，降低用例执行失败后问题定位的难度。
6.6.2 如果日志规范并将日志作为检查项时，建议遵守如下规则
1. 在日志匹配的过程中建议遇到“！”、引号、等号之类等特殊字符，建议使用转义
符号\。
例如：grep "addDomains reply\!read m_ret = 0" $VAR_ENIPHOME/log/user/* |wc -l;
2. 不到万不得已不匹配调试日志；
3. 匹配的关键字必须是独有的；
4. cat命名中需加上管道命令grep，目的是减少数据传入，提高用例执行效率
自动化测试设计规范V1.0
(仅供内部使用） For internal use only
Prepared by
拟制 Reviewed by 评审人
孟咏喜 00137435 顾江00118951 张杰飞 00101597
Approved by
批准 Authorized by
签发
Date 日期 Date 日期
yyyy-mm-dd yyyy-mm-dd
陈玉梅 37906
Date 日期 Date 日期
2010-12-16 2010-12-15
Huawei Technologies
Co., Ltd. 华为技术有限公司
All rights reserved 版权所有 侵权必究
Revision record 修订记录
1 前言
本规范适用于指导基于AutoSpace自动化测试平台的自动化测试设计活动，目的是通过规范性指导提升自动化测试设计质量。
自动化测试设计的活动流程如图所示：
自动化测试设计活动角色主要分为两种： 自动化设计人员（如TSE、测试骨干）
负责自动化用例设计前的设计活动，包括自动化测试分析、AW设计、数据规划、测试工程设计等 自动化测试工程师
负责自动化用例设计
本文将按照自动化测试设计流程，分别介绍各个活动的设计规范和指导原则。
2 自动化测试分析
自动化测试分析过程，重点分析产品特性哪些适合自动化、哪些特性应优先实现自动化。 适合自动化的范围包括：
1. 产品特性相对比较稳定，变化不是非常大
2. 产品特性重要程度高，每轮版本测试、回归测试基本都是必测的 3. 自动化投入成本在接受范围内，最好已有技术储备
通过如上三个维度分析自动化实现的优先级，应优先实现投入产出比收益明显的产品特性，即自动化较易于实现、且需要频繁测试的重要特性。
3 AW设计
AW是自动化用例设计的基础，应易于理解、好用，便于测试人员快速掌握，降低学习成本，提高用例设计效率。
AW设计的基本原则是基于业务进行抽象、设计粒度合理，尽可能覆盖自动化用例。 对于底层AW（如协议AW），应封装为类似“开户”、“用户认证”、“拨号”等业务逻辑，降低用例设计难度和接口变更时对用例的影响，提升自动化用例的重用性。
3.1 可用性
3.1.1
AW及AW参数命名清晰，有明确的含义
AW命名要简洁、易懂，便于测试人员一眼便知其大概含义，降低学习成本。 AW命名格式可参考：
同样，AW参数命名应易于理解，例如：手机型号 3.1.2
AW命名风格应统一，避免中英文混用
不规范示例：
3.1.3
AW及AW参数应定义别名
AW和AW参数定义别名（Alias），避免因修改AW或AW参数而引起自动化用例脚本不兼容性问题。别名建议英文化，同时命名含义明确，便于AW开发实现。 规范示例：
3.1 可用性
3.1.1
AW及AW参数命名清晰，有明确的含义
AW命名要简洁、易懂，便于测试人员一眼便知其大概含义，降低学习成本。 AW命名格式可参考：
同样，AW参数命名应易于理解，例如：手机型号 3.1.2
AW命名风格应统一，避免中英文混用
不规范示例：
3.1.3
AW及AW参数应定义别名
AW和AW参数定义别名（Alias），避免因修改AW或AW参数而引起自动化用例脚本不兼容性问题。别名建议英文化，同时命名含义明确，便于AW开发实现。 规范示例：
2015-11-10
华为机密，未经许可不得扩散 第5页, 共28页
不规范示例：
3.1.4
AW及AW参数说明信息应尽量详细
AW及AW参数说明信息应尽量详细，方便指导测试设计人员快速掌握AW的使用，降低AW的学习成本。 规范示例：
图：AW说明信息规范样例
2015-11-10
华为机密，未经许可不得扩散 第6页, 共28页
图：AW参数说明信息规范样例
3.1.5 例如：
AW参数 “预期结果”，建议用“成功”、“失败”作为参数值，而不是数字“0”、“1” 规范示例：
AW参数值建议采用人性化的语言描述
不规范示例：
3.1.6
AW参数值有多个取值时，应置为枚举值
AW参数有多个取值时，应在ValuePool中设置枚举值，便于用例设计时快速选择。 规范示例：
2015-11-10
华为机密，未经许可不得扩散 第7页, 共28页
图：AW参数置为枚举值示例
图：用例设计时AW参数值的选择示例
3.1.7 AW参数的常用值应设置为默认值
若AW参数值有常用值，应将常用值设置为AW参数的默认值，减少用例设计的AW参数值输入，提高用例设计效率。 规范示例：
3.1.8
AW参数可通过分组，保证参数结构的清晰
规范示例：
2015-11-10
华为机密，未经许可不得扩散
第8页, 共28页
3.1.9
AW可通过分组，保证AW结构的清晰
按照产品特性对AW进行合理分组保持结构清晰，让自动化用例设计时方便选择AW。 规范示例：
3.1.10 正确区分“必填”和“可填”的AW参数
AW参数中，有的参数值不允许为空即必须填写，有的参数填写是可选的。在AW设计时，AW参数应正确设置“Can Empty”选项值，明确该参数是否必填。 规范示例：
2015-11-10
华为机密，未经许可不得扩散 第9页, 共28页
图：AW参数置为不允许为空的示例
图：用例设计时必填和可填参数以图标区分的示例
3.1.11 AW参数个数不宜太多，可将复杂参数设计为外挂参数
AW参数个数不宜太多，否则用例设计时填写AW参数值很不方便。
复杂的AW参数可设计为外挂参数，通过外挂对话框辅助输入。
规范示例：
图： AW参数置为外挂参数示例
2015-11-10
华为机密，未经许可不得扩散 第10页, 共28页
图： 用例设计时通过外挂对话框辅助参数输入的示例
3.2 Logic封装
业务封装的基本原则：基于业务封装，Logic参数应体现业务，屏蔽具体底层实现细节。 业务逻辑封装的好处：
Logic体现测试的业务，测试人员设计用例时不用关心底层细节、上手容易 Logic参数一般不多，测试人员设计用例方便，提高用例设计效率
业务或接口变更时，往往只要修改Logic内部逻辑，而不用维护大量的自动化用例
脚本，提升自动化用例的重用性
规范示例：
示例1：
2015-11-10
华为机密，未经许可不得扩散 第11页, 共28页
图：基于协议的业务封装示例
示例1中将Soap协议细节封装在Logic，Logic对外的参数是ServiceID、ServiceName等业务参数，测试人员不用关心Soap协议的WSDL文件、Soap消息体的结构等内部细节。
示例2：
图：基于Web控件基本操作的业务封装示例
示例2中将Web控件的基本操作封装在Logic中，Logic对外的参数是控件名称、日期等业务参数，测试人员在用例设计时不用关心每个控件的基本操作，减少用例步骤，降2015-11-10
华为机密，未经许可不得扩散 第12页, 共28页
低用例设计难度，提升用例的重用性。
不规范示例：
示例中业务逻辑参数没有体现业务，仍是协议层面的实现细节。
示例中，Logic的参数体现的仍是底层协议细节，封装粒度不合理，应该基于业务进行抽象和封装。
3.3 公共AW使用
公共AW使用应遵循两个基本原则：
尽量使用AutoSpace平台提供的公共AW，避免重复设计和开发
公共AW应使用引用方式，不应将公共AW直接合并到自定义AW文件中
公共AW采用引用方式的好处有：
引用的公共AW无法编辑，避免误操作
公共AW升级时可自动升级，无需手工升级
规范示例：
2015-11-10
华为机密，未经许可不得扩散 第13页, 共28页
不规范示例：
4 数据规划
根据产品特性，应事先规划自动化测试需要的基础业务数据。这些预先规划好的数据，可以在测试环境搭建时预置到被测系统中。
自动化用例设计时可直接使用这些数据，简化用例的数据准备，一定程度上可提高用例执行效率。
数据规划举例：
一个网上银行系统，实现用户之间的汇款业务。用户分为两种：
VIP用户：汇款不收手续费
普通用户：汇款收手续费
2015-11-10
华为机密，未经许可不得扩散 第14页, 共28页
用户信息定义如下：
自动化测试设计时，应考虑普通用户和普通用户、普通用户和VIP用户、VIP用户和 VIP用户之间的汇款是否正确扣手续费用。 因此，我们可以规划如下基础的用户数据：
5 测试工程设计
测试工程是自动化执行需要的所有文件的集合，包括：AW定义文件、Replace文件、AW实现体文件、外挂文件、AW实现体的配置文件等。
5.1 所有工程文件应放在工程目录中
规范示例：
5.2 工程文件的路径应置为相对路径
工程文件的路径应设置为相对路径，且相对于工程目录。 规范示例：
图：工程目录下所有文件都置为相对路径示例
图：AW实现体文件置为相对路径的示例
图：参数外挂文件置为相对路径的示例
5.3 Repalce文件定义
测试环境的数据（如IP地址、端口号等）、基础业务数据，可以作为全局变量定义在Replace文件中。用例设计时使用这些变量，实现用例脚本和数据分离，提升用例的重用性。
定义的变量应易于理解、好用，方便自动化用例设计。
5.3.1 变量命名应清晰、有明确含义
Replace变量命名规则为：VAR_xxx
其中xxx为变量名称，其命名应清晰、有明确含义。 规范示例：
5.3.2
变量含义说明应清晰、易懂
变量定义时应给出变量的含义说明，要求清晰、易懂，方便自动化用例设计时正确使用。
规范示例：
5.3.3
变量较多时，应通过分组保证结构清晰
按照环境部件、业务数据类型，对Replace变量进行合理分组，保持结构清晰、提高文件的维护效率。 规范示例：
6 自动化用例设计
自动化用例设计应遵循四个基本原则：
6.1 用例的独立性
6.1.1
用例申请的资源应在本用例的Aftershell中及时释放，避免用例间的干扰
用例常见的申请或改变的资源类型包括：
注：资源释放应放在用例的AfterShell中，不建议在下一个用例的Preshell中。因为AfterShell中的AW执行失败后仍执行后续AW，会将用例间的影响降到最低。
规范示例：
不规范示例：
例如：后置脚本不应该放在Preshell中
6.1.2
如果有类似“初始化环境”AW可保证用例独立性，该AW应放在每个用例PreShell的第一个步骤
如果类似“初始化环境”AW可保证用例独立性，则用例的AfterShell可以不释放本用例申请的资源。但类似“初始化环境”AW必须放在每个用例PreShell的第一个步骤。 规范示例：
6.1.3 用例特性的资源申请必须在本用例特性中的AfterShell中及时释放
若特性下所有用例的部分资源申请相同，可以在用例特性的Preshell中申请，无需在特性下每个用例中重复申请和释放，以提高用例执行效率。
此时，必须在用例特性的AfterShell及时释放资源，避免不同用例特性间的干扰。
6.1.4 用例设计时应尽量避免修改预先规划的测试数据
建议用例设计时应尽量避免修改预先规划的测试数据。
如修改了预先规划的测试数据，需要在Aftershell中对用例预置条件、被测系统执行过程中修改或产生的数据进行恢复
6.1.5 Shell AW尽量避免使用cd命令，防止因当前路径更改导致后续用例执行失败
不规范示例：
6.2 用例的重用性
6.2.1
环境数据 (如IP、Port等)应使用变量，不允许直接使用常量
环境数据建议在AutoSpace的Replace文件中定义为全局变量，用例设计时使用变量引用环境数据。
不允许在自动化测试用例中使用与测试环境相关的常量字符串，如“10.71.97.32” 规范示例：
环境数据定义为全局变量，用例设计时使用变量
不规范示例：
6.2.2
文件应使用相对路径，避免使用绝对路径
对于本地文件，建议存放在测试工程目录中。
用例中的文件路径应使用相对路径，避免换为另一台机器时出现文件找不到的问题。 规范示例：
不规范示例：
6.2.3
基于业务将实现特定功能的一组AW封装为业务逻辑（Logic），降低接口变更对用例的影响
基于业务，将底层AW（如协议AW）封装为类似“开户”、“用户认证”、“拨号”等业务逻辑，降低用例设计难度和接口变更时对用例的影响。 规范示例：
例如：“登录页面校验”Logic基于业务将底层的HTTP协议交互、消息处理等进行封装。
当HTTP协议消息值有变更时，只需要修改“登录页面校验”Logic，无需批量修改自动化用例脚本，自动化用例重用性较高。
不规范示例：
6.3 用例的可读性
6.3.1
通过添加必要的注释、合理分组、业务逻辑封装，保证用例结构的清晰
规范示例：
图1: 用例步骤添加注释
图2: 用例步骤添加分组
图3: 基于业务进行逻辑封装
不规范示例：
6.3.2 预置条件、测试步骤、后置脚本应正确写到用例的Preshell、CaseStep、AfterShell
前置条件、测试步骤、后置脚本应正确放在PreShell、CaseStep、AfterShell页面中，与文本用例保持一致，保证用例结构清晰。
不规范示例：
不建议将用例的预置条件、测试步骤、后置脚本全填写在一处（如Preshell）。
6.4 用例的健壮性
6.4.1 用例包含多AW集时，应使用“同步点AW”做好同步
模拟不同实体（如主叫、被叫）时会用到多个AW集并发执行。
建议通过“同步点设置”和“同步点等待”AW做好AW集的同步，避免因异步导致用例执行的不稳定
规范示例：
6.4.2 尽量避免使用时延性AW
时延性AW，如启动xxx服务，可能存在该AW执行完，但服务还未完全启动好。尽量避免这类时延性AW。
如果某些场景需要，建议添加一个校验AW，如通过定时检查等方法确认时延AW效果是否达到，避免因受机器速度、测试环境等影响导致自动化执行的不稳定性。
6.5 用例的变量
6.5.1 使用全局变量时，建议以$开头
局部变量以$开头，例如：$RecvMessage。建议全局变量和局部变量引用方式统一，全局变量也采用$开头，例如：$VAR_RequestUrl_cc
规范示例：
6.5.2 准确定义和使用变量作用域
变量作用域有三种，定义规范如下：
6.5.3 变量命名应清晰、有明确含义
例如：$VAR_PortalServer_IP、&RecvMessage、$SessionID
6.5.4 避免只定义而不使用变量，即&和$变量应成对出现
例如：一个AW输出变量&SessionID，后续应该有$SessionID引用该变量。 避免只定义而不使用的冗余变量。
6.6 用例的结果检查
6.6.1 尽量使用AW的返回值或输出参数作为检查点，不建议将日志列为关键检查项
常见的检查项主要包括：
1. 数据库检查
2. 话单检查
3. 响应消息内容检查
AW的结果检查应尽可能全面，用例执行失败时应在第一个可以检查出失败的AW上，降低用例执行失败后问题定位的难度。
6.6.2 如果日志规范并将日志作为检查项时，建议遵守如下规则
1. 在日志匹配的过程中建议遇到“！”、引号、等号之类等特殊字符，建议使用转义
符号\。
例如：grep "addDomains reply\!read m_ret = 0" $VAR_ENIPHOME/log/user/* |wc -l;
2. 不到万不得已不匹配调试日志；
3. 匹配的关键字必须是独有的；
4. cat命名中需加上管道命令grep，目的是减少数据传入，提高用例执行效率