自动化测试设计规范V1

自动化测试设计规V1.0

(仅供部使用）

For internal use only

Prepared by

拟制玉梅37906 Date

日期

2010-12-15

Reviewed by

评审人孟咏喜00137435

顾江00118951

杰飞00101597

Date

日期

2010-12-16

Approved by

批准Date

日期

yyyy-mm-dd

Authorized by

签发

Date

日期

yyyy-mm-dd

Huawei Technologies Co., Ltd.

华为技术有限公司

All rights reserved 所有侵权必究

Revision record 修订记录

1 前言

本规适用于指导基于AutoSpace 自动化测试平台的自动化测试设计活动，目的是通过规性指导提升自动化测试设计质量。

自动化测试设计的活动流程如图所示：

自动化测试设计活动角色主要分为两种：

✧自动化设计人员（如TSE、测试骨干）

负责自动化用例设计前的设计活动，包括自动化测试分析、AW设计、数据规划、

测试工程设计等

✧自动化测试工程师

负责自动化用例设计

本文将按照自动化测试设计流程，分别介绍各个活动的设计规和指导原则。

2自动化测试分析

自动化测试分析过程，重点分析产品特性哪些适合自动化、哪些特性应优先实现自动化。

适合自动化的围包括：

1.产品特性相对比较稳定，变化不是非常大

2.产品特性重要程度高，每轮版本测试、回归测试基本都是必测的

3.自动化投入成本在接受围，最好已有技术储备

通过如上三个维度分析自动化实现的优先级，应优先实现投入产出比收益明显的产品特性，即自动化较易于实现、且需要频繁测试的重要特性。

3AW设计

AW是自动化用例设计的基础，应易于理解、好用，便于测试人员快速掌握，降低学习成本，提高用例设计效率。

AW设计的基本原则是基于业务进行抽象、设计粒度合理，尽可能覆盖自动化用例。

对于底层AW（如协议AW），应封装为类似“开户”、“用户认证”、“拨号”等业务逻辑，降低用例设计难度和接口变更时对用例的影响，提升自动化用例的重用性。

3.1可用性

3.1.1AW及AW参数命名清晰，有明确的含义

AW命名要简洁、易懂，便于测试人员一眼便知其大概含义，降低学习成本。

AW命名格式可参考：

命名格式举例说明

主语+ 动词+ 名词用户订购产品

动词+ 名词检查话单

名称+ 动词数据库检查、拨号

同样，AW参数命名应易于理解，例如：手机型号

3.1.2AW命名风格应统一，避免中英文混用

不规示例：

3.1.3AW及AW参数应定义别名

AW和AW参数定义别名（Alias），避免因修改AW或AW参数而引起自动化用例脚本不兼容性问题。别名建议英文化，同时命名含义明确，便于AW开发实现。

规示例：

不规示例：

3.1.4AW及AW参数说明信息应尽量详细

AW及AW参数说明信息应尽量详细，便指导测试设计人员快速掌握AW的使用，降低AW 的学习成本。

规示例：

图：AW说明信息规样例

图：AW参数说明信息规样例

3.1.5AW参数值建议采用人性化的语言描述

例如：

AW参数“预期结果”，建议用“成功”、“失败”作为参数值，而不是数字“0”、“1”规示例：

不规示例：

3.1.6AW参数值有多个取值时，应置为枚举值

AW参数有多个取值时，应在ValuePool中设置枚举值，便于用例设计时快速选择。规示例：

图：AW参数置为枚举值示例

图：用例设计时AW参数值的选择示例

3.1.7AW参数的常用值应设置为默认值

若AW参数值有常用值，应将常用值设置为AW参数的默认值，减少用例设计的AW参数值输入，提高用例设计效率。

规示例：

3.1.8AW参数可通过分组，保证参数结构的清晰

规示例：

3.1.9AW可通过分组，保证AW结构的清晰

按照产品特性对AW进行合理分组保持结构清晰，让自动化用例设计时便选择AW。

规示例：

3.1.10正确区分“必填”和“可填”的AW参数

AW参数中，有的参数值不允为空即必须填写，有的参数填写是可选的。在AW设计时，AW参数应正确设置“Can Empty”选项值，明确该参数是否必填。

规示例：

图：AW参数置为不允为空的示例

图：用例设计时必填和可填参数以图标区分的示例

3.1.11AW参数个数不宜太多，可将复杂参数设计为外挂参数

AW参数个数不宜太多，否则用例设计时填写AW参数值很不便。复杂的AW参数可设计为外挂参数，通过外挂对话框辅助输入。规示例：

图：AW参数置为外挂参数示例

图：用例设计时通过外挂对话框辅助参数输入的示例

3.2Logic封装

业务封装的基本原则：基于业务封装，Logic参数应体现业务，屏蔽具体底层实现细节。

业务逻辑封装的好处：

✧Logic体现测试的业务，测试人员设计用例时不用关心底层细节、上手容易

✧Logic参数一般不多，测试人员设计用例便，提高用例设计效率

✧业务或接口变更时，往往只要修改Logic部逻辑，而不用维护大量的自动化用例

脚本，提升自动化用例的重用性

规示例：

示例1：