自动化测试解决方案

一、自动化测试背景

随着如今 5G 网络的广泛应用，网络系统的规模和复杂度日益提升，对于网络 设备的要求越来越高，网络设备的测试也面临新的挑战。
在设备的研发阶段，测试人员对于设备每个功能点往往需要做很多测试以验证 其完善性。不同的值要代入不同的场景进行测试。如果采用手工方式，一个测试用 例大概需要十几分钟甚至更长时间。而对于成百上千个测试用例来说，其工作量巨 大。，如果测试过程中出现错误，则需要反复调试，测试周期会更长。
在设备的Th产阶段，也需要对产品进行验证测试，以确保网络设备的Th产质量。 在这个过程中，产量、效率、质量等因素都需要考虑。测试人员既要保证测试结果 准确可靠，又要尽可能提高测试效率。而Th产线上的测试人员相较于研发部门的测 试工程师，其测试能力有限，对于较复杂的测试项，往往存在困难。
除了研发阶段和Th产阶段外，在网络设备Th命周期的其他很多环节也与测试息 息相关，同样面临各式各样的挑战。测试自动化成为应对该挑战的解决方案。企业 通过将大规模的复杂测试自动化，减少人工操作，实现人机之间的高效配合，从而 提升测试效率乃至缩短产品研发及制造等环节的时间，使产品更快面世。
信而泰基于网络测试领域多年的实践经验，结合客户需求，针对不同的测试场 景，可以提供不同的解决方案。对于测试用例数量多，重复性测试的场景，可以提 供基于脚本自动化测试方案；对于代码编写能力薄弱的测试人员，可以提供无代码 自动化测试方案；对于要将自动化测试集成到测试平台的场景，可以提供自动化集 成测试方案；对于缺乏网络基础知识和代码开发能力的客户，可以提供定制自动化 测试方案。本文将一一进行说明。

二、基于脚本自动化测试

2.1 测试场景

对于网络设备来说，会进行大量的迭代测试来保证产品功能和性能，这也是每 个产品质量保证不可或缺的一步。当网络设备的硬件更新时，需要进行性能测试， 确保新的硬件不会对性能造成负影响；当网络设备开发新的功能时，需要进行功能 测试，保证功能没有 Bug，设备可以正常使用；当发布新的软件版本时，需要进行 回归测试，确认新版本软件没有引入问题。每种情况都会涉及到大量测试用例，而 这些都还只是网络设备测试的一部分。比如交换机的 ACL 测试，要测试交换机是 否可以正确将报文与 ACL 规则进行匹配，过滤出特定的报文。交换机的 ACL 包括 permit/deny 两种动作，表示允许/拒绝；还定义了极其丰富的匹配项，例如，二 层以太网帧头信息（如源 MAC、目的 MAC、以太帧协议类型），三层报文信息
（如目的地址、协议类型），以及四层报文信息（如 TCP/UDP 端口号）等。假如 要测试 10 个涉及源 MAC 的 ACL，10 个涉及目的地址的 ACL，10 个涉及 TCP 端口 号的 ACL，并不是测试 30 次，而是需要将源 MAC、目的地址和 TCP 端口号组合 起来，测试 1000 次，这个工作量就不是简单的翻倍，而这仅是交换机功能测试中 的一项。
这一类测试存在的问题主要是：
1、测试用例数量多。测试用例涵盖的内容极其丰富，包括网络设备的功能和 性能，需要逐一进行测试；
2、测试用例重复执行。测试用例不是测试一次就完成了，同一个软件版本可 能就会测试多次，而一个网络设备，可能会发布几十个版本。
3、手工测试时间周期长。用手工的方式来进行测试工作，在一定的时间内能 进行测试工作是有限的，不可能 24 小时都在进行测试；
4、存在人工失误的可能性。人在执行测试操作的时候难免会出现一些错误， 如果未能及时发现，就会对测试结果和测试质量产Th影响。

2.2信而泰解决方案：提供 Tcl/Python API

对于上述情况，信而泰 Renix 平台提供 Tcl/Python API，便于测试人员进行自 动化脚本的编写，实现从手工方式到自动化测试的切换。根据测试用例，测试人员 调用相应的 API 进行测试脚本的编写，通过机器来执行测试步骤，完成网络设备的 自动化测试。另外，Renix 平台还提供 GUI to Tcl/Python 的功能，能够快速将客户 在图形界面配置和操作，另存为可执行的 Tcl/Python 脚本。
如下图，是一个自动化测试系统，主要对被测设备、测试设备、管理设备和测 试系统之间的网络连接进行说明。自动化测试管理系统通过运行测试脚本，由管理 网络控制 BigTao 测试仪对 N 台交换机进行测试。

方案的优势在于：
1、可以多个测试用例串行/并行测试。测试人员可以多个测试用例串行测试， 当测试资源不冲突的情况下，还可以多个测试用例并行测试，提高测试效率；
2、可以多台被测设备并行测试。在测试资源充足的条件下，测试人员可以多 台被测设备并行测试，进行批量测试，在有效时间内可以完成更多台设备的测试， 测试效率得以提高；
3、无间断测试，缩短测试的周期。通过机器运行脚本执行测试步骤，在测试 人员的休息时间或者非工作日，依然可以测试，做到 24 小时无间断测试，增加有 效测试时间，缩短测试的周期；

4、降低测试资源的投入。同等数量的测试用例，手工测试需要 4 人月，但是
自动化测试替代人工操作之后，可能只需要 1 人月，甚至更少工作量，可以节省不 少人力财力；
5、挺高测试结果的一致性。由于测试是自动执行的，每次测试步骤和测试配 置也是固定的，测试结果的一致性可以得到保障，不存在人为原因导致的结果误 差。
接下来会从 Tcl/Python API 的作用和功能、GUI To Tcl/Python 的使用、API 的架构和 API 帮助文档这几个方面进行介绍，更好熟悉和理解 API 的使用。

2.2.1Tcl/Python API

应用程序接口（API）作为自动化测试的基础，测试条件的预置、测试步骤的 设计与开发、测试结果的判断和输出，都需要测试仪提供的 API 来支持。而目前， Tcl/Python 作为热门的自动化测试开发语言， Renix 也提供了相应的 Tcl/Python API，用于控制信而泰测试仪表，来完成测试对象创建、对象属性配置和修改。
手工测试时，测试人员通过客户端软件连接测试仪，进行测试资源预约、流量 建立、启动测试、停止测试和保存测试结果。这些在图形界面的每一个操作都可以 通过相应的 API 去实现。测试人员需要做的就是选择相应的 API，完成自动化脚本 的编写，最后执行脚本，完成自动化测试。
通过 API 对信而泰测试仪的控制，可以实现对网络设备的基础流量测试、性能 测试和协议仿真测试。基础流量测试，如二层流量、IP 流量、TCP/UDP 流量、自 定义报文流量等；性能测试，如吞吐量测试、时延测试、丢包率测试、背靠背测试、 路由表容量测试、MAC 地址学习速率测试等；协议仿真测试，如 IGMP 协议测试、 VLAN 功能测试、OSPF 协议测试、ISIS 协议测试、BGP 协议测试、PIM-SM 测试、 802.1X 协议测试等。
有个问题需要注意，由于自动化语言每个版本之间会存在差异，如 Tcl8.4 版本 支持 TclX，而 Tcl 8.6 版本则不支持，所以目前 Renix 支持的情况如下：
Tcl API 支持的版本：Tcl/ITcl 8.4 和 Tcl/ITcl 8.5；

Python API 支持的版本：Python3.6*；
Renix 软件支持的操作系统：Windows Server 2012、Windows 7 及以上 下图是 Tcl 自动化脚本的示例，是用来测试仪表自环的两个端口的性能是否有
丢包或者存在乱序包。脚本设计思路：初始化 API—>占用端口—>配置流量—>订
阅统计—>启动测试—>停止测试—>分析统计—>判断结果。 导入需要用到的模块。

创建和占用测试端口 Port1、Port2。

配置流量的收发端口，配置流量的源和目的 MAC 地址。

创建和订阅 Stream Block 的统计。


开始测试，发送所有流量，10s 之后，停止测试。

根据获取到的统计结果进行分析，检查两条流量收发的包数是否相等；检查两 条流量是否有丢包；检查两条流量是否有乱序包。

根据分析的结果，做出判断，测试是 Pass 还是 Fail。

2.2.2GUI to Tcl/Python

GUI（Graphical User Interface）就是指图形用户界面，又称图形用户接口是 指采用图形方式显示的计算机操作用户界面，本文特指 Renix 客户端界面。GUI To Tcl/Python 目的在于将客户在 GUI 界面的配置和操作转化为可执行的自动化测试脚 本。以 GUI to Python 为例，功能的好处在于：测试人员在 GUI 界面的所有配置 为.xcfg 文件；非配置类的操作，如开始打流、停止打流、保存数据以及判断规则 等操作可以通过智能脚本去添加；这些操作和命令的调用代码就通过该功能自动编 写保存为 test.py 文件；脚本开发人员也可在Th成的脚本文件添加或修改测试步骤， 并可获取统计并分析统计结果给出测试结论。
如下图，就是通过 GUI to Python 功能保存的测试脚本，保存之后是一个 test.py 的脚本文件和 test.xcfg 的测试仪配置文件，测试时只要运行脚本文件即可。 脚本测试思路：加载配置文件—>上线测试端口—>订阅统计—>启动测试—>停 止测试—>分析统计—>判断结果。

2.2.3API 的基本架构

自动化测试的根本就是通过 API 去实现对测试仪的控制，Renix API 的设计是 采用面向对象的思想。像测试仪的管理 IP、端口号、槽位号等属性，有相应的类去 实现控制。端口作为测试最基础的资源，在端口类的基础上也衍Th出各种各样子类， 像建立流量、端口物理属性配置、报文捕获等类，两者之间属于继承关系。另外如 开始发流、停止发流、建立协议仿真等行为，Renix API 也提供了相应的类对其进 行控制。
整体来说，Renix API 采用面向对象的思想，命令简单，结构清晰；API 的数据 模型采用树状的继承关系；可由基本 API 加上相关命令参数完成对对象的操作；相 同的命令控制不同的板卡，应用于不同的测试场景，脚本的可重用性高。
如下图，是 API 的树形结构说明：

Sysentry：整个对象层次结构里的根对象，会自动创建，不需要在代码里显示
创建，但是可以通过代码修改它的属性；
Smart Scripter：智能脚本。用于对智能脚本控制的接口，创建完成之后可以 通过该接口对智能脚本的运行状态进行控制；

Port：Port 对象是 1 个逻辑实体对象，必须在代码里面显示创建，且要映射到
占用的信而泰测试仪上的物理端口才能使用；
ResultView：统计视图。必须在代码里显示创建，通过订阅查询器方式获取相 应的流或者协议的统计数据；
Interface：接口对象是一个逻辑接口，通过配置 Interface 的 MAC、IP 等信息， 与端口或协议进行绑定，进行测试
Stream Block：流量对象用来对测试流量进行配置和编辑的，根据不同的需求， 构造不同的业务流量进行测试
Capture：抓包捕获对象是同 Port 对象关联的，控制的是端口的捕获状态，以 及对捕获属性的相关操作
Protocol：用于对相关协议的控制，根据使用的协议调用相应的协议对象，对 协议参数进行配置以及协议状态的控制

2.2.4API 帮助文档

众所周知，帮助文档为了测试人员更好的熟悉和掌握 API 的使用，Renix API 的帮助文档不仅有详细的说明（包括 API 的作用、API 的上层节点的说明和 API 相 关属性和参数的介绍），而且对于每个 API，有使用样例参考，Tcl 和 Python 语言 的 Demo 都有 。对于刚开始接触 Renix API 的测试人员来说，可以更加快速的上手 和测试。
如下图，是帮助文档对于 StreamTemplate API 的说明。它的 Upper Node 是 Port，意味着需要先建立 Port 这个对象，才能使用这个 API。API 参数主要有 Name、Enable、ROMTag、HostMesh 和 State 等，并且对参数的值的范围、默 认值和输入、输出进行说明。

如之前提到的，帮助文档提供 Tcl 和 Python 两种语言的用例使用参考。

三、无代码自动化测试

3.1 场景

对于网络设备制造厂商来说，和研发人员相比，产线测试人员的技术比较有限， 代码能力比较薄弱，有的甚至是完全不懂编程，所以在测试时大多通过手工方式进 行测试。比如对于 PON 设备的丢包测试，测试人员需要手工连接测试仪，建立流 量，手动开始/停止测试，测试完成之后还需要手动记录测试结果，而通常这类测 试需要循环测试，记录平均值。
此类测试痛点就很明显： 一、测试时间是有限。和研发测试阶段相比，产线测试的时间预留的比较短，
可能是 1 个小时，有的甚至更少；
二、测试种类设备数量多。测试设备的数量都不是简单的一台，都是一个批次 一个批次很多台设备进行测试；
三、反复性的测试。产线上的测试都属于比较基础的测试，需要反复执行，以 确保产品质量
四、产线测试效率较低。假如以手工的方式进行测试，一个人一台设备一台设 备进行测试，这样的测试效率是很影响产品出货量；
五、测试人员可能缺乏代码编程能力。对于产线测试人员的代码功底，用脚本 进行自动化测试是很大的挑战。

3.2 信而泰解决方案：提供 Smart Scripts

针对于此类情况，信而泰提供智能脚本工具（Smart Scripts）功能，来完成无 代码的自动化测试。测试人员根据测试用例的步骤，编辑智能脚本的相关命令，进 行图形化编程。如下图，通过在命令编辑器里面添加相应命令，可以对添加的命令 进行上移/下移/删除，完成之后就可以进行测试，包含的开始、停止、暂停和删除 等按钮可以实现对测试状态的控制。

方案的优势在于：
一、图形化编程。整个自动化测试可以是图形化操作，整个过程不用写一行代 码，就能完成自动化测试；
二、灵活控制测试步骤。通过 Smart Scripts 就可以灵活的控制测试流程，包 括循环、异常跳出和结果判断等都是可以实现的；
三、快捷Th成测试例。通过智能脚本编辑器，按照测试步骤，添加相关命令， 达到测试目的，快捷完成测试用例测试。

3.2.1智能脚本工具（Smart Scripts）

智能脚本工具是无代码的自动化测试用例编写和执行的解决方案。通过智能脚 本可以运行并查看自定义测试和基准测试（RFC2544、RFC2889、RFC3918 和非对 称测试）的状态。
通常的手工测试，如果是要循环对被测设备打流，需要一次次点击开始/停止 按钮，假如要进行数据分析的话，需要人为对测试结果进行比较。智能脚本提供的

循环语句、条件语句和判断语句，在循环测试和结果判断等场景中，有很好的应用。
在很大程度上节省测试的时间，也更加快捷的得出测试结论。 智能脚本编辑器拥有强大的命令功能，包括 8 大类：硬件类、控制类、流量类、
协议类、统计类、抓包类、工具类、其它基本命令。其中每一大类都包含丰富的操
作命令。

硬件类（Hardware）：主要用于对测试资源的管理，支持的命令有连接/断开
/关闭/重启机箱、预约/释放端口、端口上线/下线/自协商； 控制类（Control）：主要用于控制运行脚本的流程，包括 Break 、Continue 、
Else 、Else If 、Goto 、Group 、If 、Loop 和 While；
流量类（Stream）：主要是与流量相关的操作命令，包括导入流、发送指定 流、发送所有流、停止流、停止所有流、选择流量接收端口、启动流的 ARP/ND 学习和停止流的 ARP/ND 学习；

协议类：包括 Access 协议、Carrier Ethernet 协议、Routing 协议和 Switch 协
议。其中 Access 支持的协议有 DHCPv4、DHCPv6 、Dot1x、IGMP、L2TP、MLD 和 PPPoe。Carrier Ethernet 支持的协议有 802.1ag 、802.3ah 。Routing 支持的协 议有 BFD 、BGP、IS-IS、OSPFv2、OSPFv3、PIM 和 RIP 。Switch 支持的协议有 OVSDB。而每一种具体的协议又包括多种操作命令，比如 BGP 协议里的操作命令 包括建立/断开 BGP 连接、通告/撤销 BGP 路由等。其它协议里的各种操作命令也 是类似的；
统计类（Result）：主要是与统计结果相关的操作命令，包括有多页统计结果 时执行翻页操作、清除所有统计视图的结果和清除指定统计视图的结果；
抓包类（Capture）：是关于捕获报文的操作命令，包括所有端口或指定端口 上开始抓包、在所有端口或指定端口上停止抓包、终止捕获下载、下载 pcap 数据 到指定的路径；
工具类（Tool）：支持的命令主要包括 Sleep、验证统计值以确定命令成功或 失败、添加注释、在指定的目录下执行指定的命令和等待条件为真才执行；
其它基本命令（Core）：支持的命令主要包括开始/停止学习 ARP、保存结果、 保存配置文件、收集日志信息、开启/停止相应接口协议和所有接口开启/停止协议 测试，等等。
除此之外，在命令编辑器里面还可对命令进行删除、添加、上移、下移、命令 进行添加成组和命令进行循环等操作。通过对智能脚本里的不同命令进行组合来实 现客户复杂测试需求。如下图，是使用智能脚本工具来进行 OSPF 协议震荡测试。 先是上线端口，然后进行 APR 的学习，ARP 学习成功之后就开启 OSPF 协议，保 存相关测试结果，之后进行撤销 LSA 和通告 LSA 的操作，循环 12 次，通过此自动 化测试来测试路由震荡。

四、自动化集成测试

4.1 场景

对于网络设备制造商或者运营商，其使用的测试仪表不止一个厂家，但是对他 们而言，不管是出于测试平台的维护还是自动化脚本的编写，都只能是通过一个自 动化平台上去使用，运行一套自动化脚本，不可能存在多元化。当然，有的甚至会 将测试仪集成到自动化测试系统中，将网络设备的测试作为系统中的一部分，丰富

自动化测试系统的功能。因为很多的自动化语言之间是的兼容性都比较差，就会出
现测试系统是一种语言，测试仪表又是另外一种语言，两者之间如果需要结合的话 就存在一定困难。
此类情况痛点：
一、每个测试仪表厂家 API 存在差异。每个仪表厂商都有一套成熟的 API，互 相之间不可能兼容，引入新的测试仪表，原有的自动化测试脚本会调用不成功。
二、测试仪表的 API 与测试系统兼容性差。测试系统所使用的编译语言与 API
使用的语言自动化测试语言可能存在差异，相互之间不能够调用。

4.2 信而泰解决方案：提供高层 API 和 API 二次开发

针对于此类情况，信而泰可以基于基础的 Renix API，提供高层 API 和 API 的 二次开发，便于完成自动化测试。高层 API 的开发，需要客户的配合，只有提供测 试系统所需的 API 函数名称、功能和参数等相关信息，才能更好完成高层 API 的封 装。这样一来，就可以多家测试仪表厂商，使用同样的测试脚本进行测试。同样的， API 二次开发也是需要和客户进行交流，在明确客户需求的前提下，针对客户所需 的 API 在基础的 API 上进行二次开发。
如下图，很直观的表明高层 API 和 API 二次开发最重要的目的：提高与自动化 测试系统的兼容性。

方案的优势在于：
一、高层 API 结构简单，层次清晰，方便用户对常用的测试场景进行快速配置；
二、底层 API 变动时，通过修改高层封装内部实现方式，确保测试脚本兼容；
三、高层 API 的这种结构从客户角度上来说，消除了各家测试仪器厂商指令的 差异；
四、脚本通用性很高，不必为每种仪表重复开发相同功能的测试脚本； 五、API 的二次开发，提高测试仪表与自动化测试系统的兼容性。

4.2.1高层 API

高层 API 是根据给定的测试功能需求对测试仪表繁琐的 API 调用进行封装，向 测试人员提供结构清晰、易于理解的控制使用仪表的接口。 对于测试人员来说， 高层 API 采用面向对象的方式，结构清晰，相比较于底层 API 需要掌握的复杂的对 象及参数配置要求，高层 API 可以通过可读性强的 API 命名规则和参数配置，方便 测试人员调用，可以更快捷、高效地实现自动化测试。
下图是对于 connect 这个高层 API 的介绍，包括这个 API 的目的是为了初始化 测试资源；API 的使用概述，用到的函数；最后就是对于每个函数的详细说明。

4.2.2API 的二次开发

API 的二次开发是指在底层 API 的基础上，在可执行的条件下，信而泰可以提 供代码级的支持，可以基于客户的测试系统所用的自动化语言开发一致的 API 接口， 便于集成到测试系统当中。API 的二次开发可以很好的解决与客户测试系统兼容性 的问题，目的就是去适配客户的测试系统。相比较修改测试系统和二次开发的工作 量，可以有效减少客户重新开发测试系统的工作量，并且也不会影响测试系统其余 的测试功能。
下图是 C# API 二次开发资料中对于 StreamAPI 使用方法的说明。StreamAPI 是用于管理流的类。 例如：添加，编辑，删除，复制，粘贴，重复等对流量的操 作都可以通过 Stream API 来实现

五、定制自动化测试

5.1 场景

对于有些公司或者科研院所来说，可能仅仅是因为项目原因，才会涉及到网络 设备的自动化测试。不管是对网络设备测试的认识还是自动化测试，基础知识可能 比较欠缺，无法完成网络设备自动化的测试。

此类情况的痛点
一、对于网络设备测试完全是属于零基础，不知道从何下手； 二、手工测试起来繁琐复杂，操作困难，而且需要掌握相关的网络知识； 三、 缺乏代码开发能力，无法完成自动化脚本的编写。

5.2 信而泰解决方案：提供自动化定制服务

针对于此类情况，信而泰可以提供整套自动化测试服务，包括从确认测试需求、 制定测试方案、编写测试脚本、定制开发自动化软件测试到Th成测试结果。完整的 自动化测试服务，大大节省了客户在测试上所耗费的时间和人力成本。
此类方案的优势在于： 一、定制化服务：提供专属的自动化测试服务 二、高性价比：引入竞争、降低采购成本； 三、国产自主：国产仪表，自主可控，软件自主研发
四、技术支持快速高效：7*24 小时技术服务，更有研发团队对代码级进行支 持。
如下图，是自动化测试测试服务流程图：

5.2.1确定测试需求

需要明确客户的需求，只有将测试需求确定下来，才能够更准确的开展自动化 工作，信而泰才能提供更好的测试服务。主要的沟通内容包括以下几个方面：和客 户沟通测试需要满足的要求，测试环境的要求，指标的要求等；需要达到的目的， 是要测试网络设备性能，还是对功能进行测试；要清楚客户需要呈现的结果，是对 于网络设备整体的测试，体现出网络设备的性能指标和功能的满足度，还是只是对 网络设备部分功能和性能进行测试。下图就是客户可能涉及到的相关需求。

5.2.2制定测试方案

明确测试需求之后，就需要制定测试方案。先是自动化测试语言的选择，信而 泰提供的 Python/Tcl API 是否就可以满足客户的测试需求，需不需要进行二次开 发；哪些测试用例需要进行测试；呈现给客户的结果是怎么样的形式，在软件界面 直接显示结果，还是通过测试报告的形式；是否需要开发自动化测试软件；整体测 试功能的计划等等，这些都是需要在测试方案中体现出的。下图是对于交换自动化
测试的工作计划表，对测试的整体情况进行把控，需要测试的用例、交付的时间等。

5.2.3编写测试脚本

测试脚本的编写在自动化测试工作中尤为重要，会占用开发人员比较多的时间。 每一项测试用例都对应一个测试脚本，开发人员的工作可以看做是将测试用例的步 骤用脚本语言进行翻译，完成自动化脚本编写，通过机器去一步一步执行测试。另 外，对测试结果通过或者失败的判断也是脚本中很关键的部分，测试结果的 Pass

或者 Fail 就是通过脚本中的判断条件去决定的，所以逻辑清晰明了的判断条件，更
有利于测试人员对于网络设备性能指标和功能满足度的测试。 如下图是编写的部分测试用例。对于每个功能点和性能点都有脚本进行测试。
像 RIPv2 的涉及的功能点比较多，所以会有多个脚本去对其进行测试。

如下图是编写的测试脚本。脚本编写的思路一般先是对于常用变量的初始化， 包括机箱的 IP，测试时长，测试流量的源和目的 MAC 等；接着就是对于占用测试 资源；然后是建立测试流量，根据不通测试用例建立不同的业务流量；然后是订阅 统计之后，开始进行发流测试，等待流量发送完成之后停止测试；最后就是获取统 计结果数据，对结果进行判断

5.2.4开发自动化测试软件

开发自动化测试软件。可以实现对被测设备（交换机）和测试仪进行统一的管 理，包括下发被测设备的配置、绑定被测设备和测试仪端口等操作。很多手工测试， 都需要测试人员先对被测设备进行配置，然后才能操作测试仪表进行测试。

自动化测试软件可以实现对测试脚本的批量管理。选择脚本所在的文件夹，测
试脚本自动被索引出来，将需要测试的脚本与测试端口进行绑定之后，就可以进行 批量测试。多个脚本可以串行测试，在测试资源不冲突的情况下，还可以实现多线 程测试，多个测试脚本并行测试，测试效率更加高效。

自动化测试软件还具备失败重跑的功能，对于成功和失败的测试脚本都有统计， 并且在测试界面还有相关测试步骤的体现，当测试过程中出现 Fail 之后，可以很直 观的看到测试失败的原因

自动化软件可以实现对测试结果的汇总，Th成测试报告。Th成的测试报告格式
是 Word、Excel 和是其余格式。并且报告里面的内容可以根据客户的需求进行定 制化设计。报告的标题、测试人员等内容也都是可以进行修改的。
Word 报告：报告中通过 3 个方面记录测试结果，第一是测试概要，描述此次 测试的相关情况；第二是测试结果描述，包括测试结论（汇总）、通过的测试用例、 未通过的测试用例和改进及建议，记录测试的相关结果；第三是详细测试用例执行 情况，记录每个测试用例的名称、用例内容、执行过程和执行结果。
如下图，是一次防火墙测试的 Word 报告，在此次测试中总共测试 8 个脚本，
6 个用例测试通过，2 个用例测试失败，测试通过和失败的用例分开记录在报告中。 在详细测试用例执行情况，记录第一个测试用例的名称是 1_default.tcl，用例内容： 测试默认禁止原则，执行过程中的 log 记录，以及执行结果是 Pass，Pass 的判断 就是 Port1 不能 Ping 同 Port2，Port 收不到 Ping 包。

Excel 结果报告：报告对测试结果进行汇总，包括 Pass 的脚本数量，Fail 的脚
本数量，通过率，总执行时间，以及每个脚本的名称、测试目的、测试步骤、预期 结序、测试结论等等都会在报告中进行记录。
如下图，是一次防火墙测试的 Excel 结果报告，总共测试 6 个测试用例，6 个 用例测试成功，0 个用例测试失败，总共的测试时长为 11 分钟 28 秒，并且每个脚 本的目的、步骤、预期结果、测试结论等都记录在报告中。