★ 杭州和利时自动化有限公司 方垒，边涛

摘要：自动化测试在行业中的重要性和优势是显而易见的。本文介绍了在工业软件的自动化测试探索中，如何克服被测对象提出的挑战，从而摸索且实践出的一套适合工业软件的自动化测试解决方案，并对解决方案中的优秀实践进行了介绍。

关键词：自动化测试；工业控制软件

1　引言

软件质量需要测试，自动化测试可以改善产品质量，并保持高标准的代码卓越性。

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。自动化测试通过让机器代替人执行测试，自动执行大量的测试用例，甚至完成某些手工测试无法完成的测试工作，从而达到资源优化、提高产品质量的目标。

在针对特殊行业软件进行自动化测试探索过程中，遇到的困难点来自于两个维度：一是被测试软件自身的特点，对自动化测试框架提出了挑战；二是自动化测试框架当前通用的难点，在被测试软件中恰是难以覆盖的重点。面对困难与挑战，我们的自动化测试团队迎难而上，最终实践出一套适合工业软件的优秀自动化测试方案。

2　被测系统介绍

HOLLiAS MACS V6.5系列是和利时于2013年正式推出的第5代高可靠性DCS系统，设计过程中充分采用了安全系统的设计理念，吸取国际工业电子技术和工业控制技术的最新成果，严格遵循国际先进的工业标准，采用全冗余、多重隔离、热分析、容错等可靠性设计技术，从而保证系统在复杂、恶劣的工业现场环境中能安稳长满优地运行。

HOLLiAS MACS V6.5系统基于国际标准和行业规范进行设计，集成了各行业的先进控制算法平台，可根据不同行业的自动化控制需求，提供更专业全面的一体化解决方案，从而实现了生产、设备和安全三大目标的最佳协调，并帮助用户实现产品全生命周期维护成本的最小化和设备投资回报的最大化。

HOLLiAS MACS V6.5系统是基于以太网和PROFIBUS-DP现场总线构架，可方便接入多种工业以太网和现场总线。

HOLLiAS MACS V6.5系统符合IEC 61131-3标准，集成了基于HART标准协议的AMS系统，并可集成SIS、PLC、MES、ERP等系统，同时提供了众多知名厂家控制系统的驱动接口，可实现智能现场仪表设备、控制系统、企业资源管理系统之间无缝信息流传送，实现工厂智能化、管控一体化。

MACS V6.5系统主要由工程师站、操作员站、历史站、通讯站、控制站等部件组成，控制网的网络节点由控制站和I/O模块构成。产品架构如图1所示。

图1 产品架构图

3　工业软件自动化测试特点

与传统的桌面应用软件相比，上文介绍的工业软件有很多特点。从上到下的软硬件一体，在软件测试的过程中，需要考虑整体性。软件自身结构庞大，且处于分布式部署的模式，软件自身的各个模块间交互性非常强，在软件测试过程中，需要考虑交互性。除此以外，工业软件自身对实时性、安全性等的要求非常高，测试人员在测试过程中，同样需要考虑它的特性。那么，作为工业软件的自动化测试来说，定位既然是模拟手工测试人员的测试行为，那么，以上的所有工业软件特性在自动化测试框架的设计中，均需要考虑。

就自动化测试自身来讲，软件自动化测试的分层理论倡导不同层次（阶段）需要自动化，从底到顶的层次结构依次为：UT（单元测试）、接口层、UI（用户界面）层。

通过应用程序的UI来操作该应用程序的自动测试称为编码的UI测试（CUIT）。这些测试包括对UI控件的功能测试，可以验证整个应用程序（包括其用户界面）是否正常运行。编码的UI测试对于在用户界面中存在验证或其他逻辑的情况特别有用。

针对工业应用软件当前测试投入点，结合自动化测试UI层特性，设计出了一套适合工业软件的自动化测试框架。该测试框架既涵盖无人值守的自动化测试完整流程，包括从测试版本自动推送一直到最终的测试结果反馈，又在实践过程中纳入了当前软件行业非常多的优秀实践，并对此进行了改进和方案集成。以下将分别对优秀实践的应用做以说明。

4　优秀实践

4.1　边角测试集成方案

在自动化测试框架的设计中，ST环节定义为UI自动化测试，那么，分析现有无论是开源还是商用自动化测试工具，发现在对软件的UI层进行自动化测试时，均会面临无法识别软件自定义或二次开发的UI控件。在图形结果的验证中，也很难做到识别与验证，特别是在屏幕颜色进行闪变且图形实时变化的情况。如果要达到自动化完全模拟人工测试的操作及结果验证，那么以上的难点无法避免。

鉴于此，我们在ST测试框架中，除了对UI上的控件进行识别加入到测试代码的对象库中，框架中集成了另外一种完全不同测试思想的图形对象库。图形对象库的建立，使得对软件界面对象的操作和结果验证，依赖的不再是框架是否可以识别的组件，而是图形。对软件进行自动化测试代码编写过程中，图形对象的使用，可以克服自定义组件的困难，同样的，图形结果的验证问题迎刃而解。

图形识别的自动化测试作为一个补充的边角测试方法，与通用的基于组件识别的自动化测试框架集成，在做UI层自动化测试中，可测试范围进行了极大的扩充。

4.2　测试数据管理

对于自动化测试或传统手工测试来说，测试数据都是非常重要的资源，那么对于自动化测试项目来说，如何更好地管理测试数据，在自动化框架设计中也要考虑。

首先，采用测试代码与测试数据分离的设计模式。这种隔离的设计使得测试代码的结构非常清晰，而不是杂乱无章的混乱结构，更大的好处在于，测试数据的分离使得我们在自动测试代码中使用数据池的概念非常便于替换。测试代码的复杂度降低了，测试的有效性也更好发挥。

其次，通过配置文件灵活读取和替换测试数据。以上章节中提到，测试框架中的测试对象有一部分是图形对象，图形对象作为测试对象同时作为测试数据，如果得不到很好的管理，那么，在被测试软件发生部分界面变化时，维护的成本和工作量是非常巨大的。考虑到这个因素，设计采用了配置文件的方式，进行此类数据的组织、管理和调用。

最后，使用工具将测试数据资源进行管理。在软件开发的过程中，相信很多从事软件工作的同行，无论哪个角色，均会用到支持软件开发过程的大量工具。如团队管理使用进行流程管控的工具，开发人员需要用到版本控制工具等。随着Visual Studio产品线中Team Foundation Server组件的公布，使得微软开发团队在僵化的软件项目实践应用中取得了巨大进步。因此，在自动化测试项目组织和测试数据资源管理中，使用的是TFS，我们使用的是TFS的单server结构，单server的类型已满足自动化项目的使用。完成项目配置后的TFS如图2所示。

图2 TFS配置完成状态图

4.3　测试结果监视

自动化测试框架对于自动化部署是采用分布式的设计，那么，对于测试机集群的测试结果就需要进行统一整合，并在此基础上做出分析，使得测试人员定位错误的代价最小。

对于测试结果监视，我们的实现是通过控制中心，即自动化测试服务器将被测试机器的测试结果进行依次回收，回收至服务器本地后，首先进行测试结果的整合，将不同测试机的结果进行既定模板的整合，整合后，数据做两个方面的处理。一是将测试数据进行统计分析，从全局上掌握自动化测试的运行结果。二是详细分析，将每个自动化用例的测试结果进行丰富的多维度测试结果解析。

结果一主要支持管理人员及测试维护人员从全局上了解被测试产品测试质量。结果二的主要目的是提供测试维护人员对于失败进行详细及快速的定位。毕竟在自动化用例规模过大的时候，自动化的监视对象主要还是失败用例。自动化测试结果如图3所示。

图3 自动化测试结果展示图

4.4　自动化测试用例设计与测试代码质量保证

在我们的测试团队中，自动化测试用例代码的编写是多人协作开发的模式，对于如何保障用例本身的代码质量，我们做了很多尝试和努力，以两个实践中有效尝试为例，在该部分做个说明。

结构化代码设计，以便于更简单地复制和改写用例。测试代码由多人开发，在过程中，有很多重复性的代码，那么，将这些部分进行模块化处理，供公共调用，有效减少了测试代码量，维护代价非常小。

自动化代码的代码检视。通过代码的交叉检视，不仅能发现个人代码过程中的错误及不符合规范项，还能在检视别人的代码中提升自我。前提是我们的自动化团队形成了自己的自动化代码规范且包含了自动化用例设计指导原则等。当前，代码检视不能侧重于发现代码缺陷，它是一个监督项，可以使我们的团队不断提升自动化测试代码质量。

4.5　部署和管理

对于自动化测试当前耗时和可预见的未来用例及运行时长规模来说，自动化架构设计之初运行环境必须采用分布式部署，才能满足自动化构建时长的要求。因被测软件部署于Windows平台，设计使用PowerShell及PowerShell DSC来完成自动化测试整体的部署和管理。此设计具有强大的兼容性，完全兼容Windows平台上的其它调用，且基于平台具备很好的可扩展性，也可以进一步利用.NET Framework的强大功能。

在此特别需要说明一下的是PowerShell DSC。在集群机器管理中，通过使用PowerShell DSC保持自动化运行环境的可控和一致性，体现在操作系统和被测试应用软件上。通过它的使用同样降低了脚本的复杂度，可大幅度提高迭代速度。将环境从结构中分离出来，此类模型设计同样契合与DevOps理念。自动化测试部署如图4所示。

图4 自动化测试部署图

4.6　持续集成

自动化测试想要发挥最大化的价值，就不能不涉及持续集成。在不断迭代的被测试软件版本中，自动化测试的防护网持续拦截且保持测试标准的一致性，这是自动化测试的理想应用状态，因此，我们的自动化测试方案设计中关于持续集成的落地在此做一说明。

开发代码一旦入库，通过配置的版本构建，会经过持续自动化的质量保证环节。主要的构建步骤如图5所示。

图5 自动化测试持续构建图

4.7　TestOps的展望

新的理念与技术层出不穷，对于工业软件的自动化测试设计方案也是在不断接受新鲜事物的过程中集成、完善、逐步优化的。顾名思义，TestOps即测试运维。从测试的角度推动研发和运维，将测试落地到整个研发体系的关键岗位。它关注全生命周期的质量控制、测试过程接地气、关注环境及代码验证、关注质量统计分析及回溯。概念图如图6所示。

图6 TestOps概念图

在优秀的TestOps体系中，我们关于工业软件自动化测试框架的设计及整体的CI设计已经有部分优秀的实践活动进行了落地。但是将测试落地到整个研发体系的关键岗位，我们做得还不够，有很大提升空间。

例如如何让测试团队专注于提供基于被测软件的所有级别的测试，从低级到高级，从功能到集成，形成完整的测试体系。

例如环境与持续集成工具，虽然我们当前使用了一些工具用于环境快速部署和持续集成，但是优秀的工具不断更新，对于工具的使用，我们不仅要追求用得全面，更要追求用得优异。

例如多种静态、动态测试工具，只要适用且有效，都可以不断纳入我们的持续集成流程。

一个例如就是一个大的进步方向。相信通过不断的自我提升、自动化测试团队的提升，我们关于工业软件的测试体系会更完善、更高效。

参考文献：

[1] [英]格雷, 福斯特. 自动化测试最佳实践[M]. 北京: 机械工业出版社, 2013.

[2] 郭伟斌, 郭锡坤. 自动化测试的研究和探讨[J]. 电脑开发与应用, 2008, (12) : 10 – 12.

[3] [美]达斯汀, 加瑞特, 高夫. 自动化软件测试实施指南[M]. 北京: 机械工业出版社, 2010.

[4] 赵丽珍. 基于数据驱动的自动化测试平台设计[J]. 福建电脑, 2011, (02) : 135 – 136.

作者简介：

方　垒（1976-），男，江西赣州人，高级工程师，硕士，现任和利时集团联席总裁、杭州和利时自动化有限公司总裁兼首席技术官，长期从事工业自动化、信息化系统的产品技术研发及应用推广工作。

边　涛（1983-），女，陕西榆林人，工程师，硕士，现任杭州和利时自动化有限公司西安分公司资深软件测试工程师，从事测试及自动化测试工作。