★ 杭州和利時(shí)自動(dòng)化有限公司 方壘，邊濤

摘要：自動(dòng)化測試在行業(yè)中的重要性和優(yōu)勢是顯而易見(jiàn)的。本文介紹了在工業(yè)軟件的自動(dòng)化測試探索中，如何克服被測對象提出的挑戰，從而摸索且實(shí)踐出的一套適合工業(yè)軟件的自動(dòng)化測試解決方案，并對解決方案中的優(yōu)秀實(shí)踐進(jìn)行了介紹。

關(guān)鍵詞：自動(dòng)化測試；工業(yè)控制軟件

1　引言

軟件質(zhì)量需要測試，自動(dòng)化測試可以改善產(chǎn)品質(zhì)量，并保持高標準的代碼卓越性。

軟件測試的經(jīng)典定義是：在規定的條件下對程序進(jìn)行操作，以發(fā)現程序錯誤，衡量軟件質(zhì)量，并對其是否能滿(mǎn)足設計要求進(jìn)行評估的過(guò)程。自動(dòng)化測試通過(guò)讓機器代替人執行測試，自動(dòng)執行大量的測試用例，甚至完成某些手工測試無(wú)法完成的測試工作，從而達到資源優(yōu)化、提高產(chǎn)品質(zhì)量的目標。

在針對特殊行業(yè)軟件進(jìn)行自動(dòng)化測試探索過(guò)程中，遇到的困難點(diǎn)來(lái)自于兩個(gè)維度：一是被測試軟件自身的特點(diǎn)，對自動(dòng)化測試框架提出了挑戰；二是自動(dòng)化測試框架當前通用的難點(diǎn)，在被測試軟件中恰是難以覆蓋的重點(diǎn)。面對困難與挑戰，我們的自動(dòng)化測試團隊迎難而上，最終實(shí)踐出一套適合工業(yè)軟件的優(yōu)秀自動(dòng)化測試方案。

2　被測系統介紹

HOLLiAS MACS V6.5系列是和利時(shí)于2013年正式推出的第5代高可靠性DCS系統，設計過(guò)程中充分采用了安全系統的設計理念，吸取國際工業(yè)電子技術(shù)和工業(yè)控制技術(shù)的最新成果，嚴格遵循國際先進(jìn)的工業(yè)標準，采用全冗余、多重隔離、熱分析、容錯等可靠性設計技術(shù)，從而保證系統在復雜、惡劣的工業(yè)現場(chǎng)環(huán)境中能安穩長(cháng)滿(mǎn)優(yōu)地運行。

HOLLiAS MACS V6.5系統基于國際標準和行業(yè)規范進(jìn)行設計，集成了各行業(yè)的先進(jìn)控制算法平臺，可根據不同行業(yè)的自動(dòng)化控制需求，提供更專(zhuān)業(yè)全面的一體化解決方案，從而實(shí)現了生產(chǎn)、設備和安全三大目標的最佳協(xié)調，并幫助用戶(hù)實(shí)現產(chǎn)品全生命周期維護成本的最小化和設備投資回報的最大化。

HOLLiAS MACS V6.5系統是基于以太網(wǎng)和PROFIBUS-DP現場(chǎng)總線(xiàn)構架，可方便接入多種工業(yè)以太網(wǎng)和現場(chǎng)總線(xiàn)。

HOLLiAS MACS V6.5系統符合IEC 61131-3標準，集成了基于HART標準協(xié)議的AMS系統，并可集成SIS、PLC、MES、ERP等系統，同時(shí)提供了眾多知名廠(chǎng)家控制系統的驅動(dòng)接口，可實(shí)現智能現場(chǎng)儀表設備、控制系統、企業(yè)資源管理系統之間無(wú)縫信息流傳送，實(shí)現工廠(chǎng)智能化、管控一體化。

MACS V6.5系統主要由工程師站、操作員站、歷史站、通訊站、控制站等部件組成，控制網(wǎng)的網(wǎng)絡(luò )節點(diǎn)由控制站和I/O模塊構成。產(chǎn)品架構如圖1所示。

圖1 產(chǎn)品架構圖

3　工業(yè)軟件自動(dòng)化測試特點(diǎn)

與傳統的桌面應用軟件相比，上文介紹的工業(yè)軟件有很多特點(diǎn)。從上到下的軟硬件一體，在軟件測試的過(guò)程中，需要考慮整體性。軟件自身結構龐大，且處于分布式部署的模式，軟件自身的各個(gè)模塊間交互性非常強，在軟件測試過(guò)程中，需要考慮交互性。除此以外，工業(yè)軟件自身對實(shí)時(shí)性、安全性等的要求非常高，測試人員在測試過(guò)程中，同樣需要考慮它的特性。那么，作為工業(yè)軟件的自動(dòng)化測試來(lái)說(shuō)，定位既然是模擬手工測試人員的測試行為，那么，以上的所有工業(yè)軟件特性在自動(dòng)化測試框架的設計中，均需要考慮。

就自動(dòng)化測試自身來(lái)講，軟件自動(dòng)化測試的分層理論倡導不同層次（階段）需要自動(dòng)化，從底到頂的層次結構依次為：UT（單元測試）、接口層、UI（用戶(hù)界面）層。

通過(guò)應用程序的UI來(lái)操作該應用程序的自動(dòng)測試稱(chēng)為編碼的UI測試（CUIT）。這些測試包括對UI控件的功能測試，可以驗證整個(gè)應用程序（包括其用戶(hù)界面）是否正常運行。編碼的UI測試對于在用戶(hù)界面中存在驗證或其他邏輯的情況特別有用。

針對工業(yè)應用軟件當前測試投入點(diǎn)，結合自動(dòng)化測試UI層特性，設計出了一套適合工業(yè)軟件的自動(dòng)化測試框架。該測試框架既涵蓋無(wú)人值守的自動(dòng)化測試完整流程，包括從測試版本自動(dòng)推送一直到最終的測試結果反饋，又在實(shí)踐過(guò)程中納入了當前軟件行業(yè)非常多的優(yōu)秀實(shí)踐，并對此進(jìn)行了改進(jìn)和方案集成。以下將分別對優(yōu)秀實(shí)踐的應用做以說(shuō)明。

4　優(yōu)秀實(shí)踐

4.1　邊角測試集成方案

在自動(dòng)化測試框架的設計中，ST環(huán)節定義為UI自動(dòng)化測試，那么，分析現有無(wú)論是開(kāi)源還是商用自動(dòng)化測試工具，發(fā)現在對軟件的UI層進(jìn)行自動(dòng)化測試時(shí)，均會(huì )面臨無(wú)法識別軟件自定義或二次開(kāi)發(fā)的UI控件。在圖形結果的驗證中，也很難做到識別與驗證，特別是在屏幕顏色進(jìn)行閃變且圖形實(shí)時(shí)變化的情況。如果要達到自動(dòng)化完全模擬人工測試的操作及結果驗證，那么以上的難點(diǎn)無(wú)法避免。

鑒于此，我們在ST測試框架中，除了對UI上的控件進(jìn)行識別加入到測試代碼的對象庫中，框架中集成了另外一種完全不同測試思想的圖形對象庫。圖形對象庫的建立，使得對軟件界面對象的操作和結果驗證，依賴(lài)的不再是框架是否可以識別的組件，而是圖形。對軟件進(jìn)行自動(dòng)化測試代碼編寫(xiě)過(guò)程中，圖形對象的使用，可以克服自定義組件的困難，同樣的，圖形結果的驗證問(wèn)題迎刃而解。

圖形識別的自動(dòng)化測試作為一個(gè)補充的邊角測試方法，與通用的基于組件識別的自動(dòng)化測試框架集成，在做UI層自動(dòng)化測試中，可測試范圍進(jìn)行了極大的擴充。

4.2　測試數據管理

對于自動(dòng)化測試或傳統手工測試來(lái)說(shuō)，測試數據都是非常重要的資源，那么對于自動(dòng)化測試項目來(lái)說(shuō)，如何更好地管理測試數據，在自動(dòng)化框架設計中也要考慮。

首先，采用測試代碼與測試數據分離的設計模式。這種隔離的設計使得測試代碼的結構非常清晰，而不是雜亂無(wú)章的混亂結構，更大的好處在于，測試數據的分離使得我們在自動(dòng)測試代碼中使用數據池的概念非常便于替換。測試代碼的復雜度降低了，測試的有效性也更好發(fā)揮。

其次，通過(guò)配置文件靈活讀取和替換測試數據。以上章節中提到，測試框架中的測試對象有一部分是圖形對象，圖形對象作為測試對象同時(shí)作為測試數據，如果得不到很好的管理，那么，在被測試軟件發(fā)生部分界面變化時(shí)，維護的成本和工作量是非常巨大的?？紤]到這個(gè)因素，設計采用了配置文件的方式，進(jìn)行此類(lèi)數據的組織、管理和調用。

最后，使用工具將測試數據資源進(jìn)行管理。在軟件開(kāi)發(fā)的過(guò)程中，相信很多從事軟件工作的同行，無(wú)論哪個(gè)角色，均會(huì )用到支持軟件開(kāi)發(fā)過(guò)程的大量工具。如團隊管理使用進(jìn)行流程管控的工具，開(kāi)發(fā)人員需要用到版本控制工具等。隨著(zhù)Visual Studio產(chǎn)品線(xiàn)中Team Foundation Server組件的公布，使得微軟開(kāi)發(fā)團隊在僵化的軟件項目實(shí)踐應用中取得了巨大進(jìn)步。因此，在自動(dòng)化測試項目組織和測試數據資源管理中，使用的是TFS，我們使用的是TFS的單server結構，單server的類(lèi)型已滿(mǎn)足自動(dòng)化項目的使用。完成項目配置后的TFS如圖2所示。

圖2 TFS配置完成狀態(tài)圖

4.3　測試結果監視

自動(dòng)化測試框架對于自動(dòng)化部署是采用分布式的設計，那么，對于測試機集群的測試結果就需要進(jìn)行統一整合，并在此基礎上做出分析，使得測試人員定位錯誤的代價(jià)最小。

對于測試結果監視，我們的實(shí)現是通過(guò)控制中心，即自動(dòng)化測試服務(wù)器將被測試機器的測試結果進(jìn)行依次回收，回收至服務(wù)器本地后，首先進(jìn)行測試結果的整合，將不同測試機的結果進(jìn)行既定模板的整合，整合后，數據做兩個(gè)方面的處理。一是將測試數據進(jìn)行統計分析，從全局上掌握自動(dòng)化測試的運行結果。二是詳細分析，將每個(gè)自動(dòng)化用例的測試結果進(jìn)行豐富的多維度測試結果解析。

結果一主要支持管理人員及測試維護人員從全局上了解被測試產(chǎn)品測試質(zhì)量。結果二的主要目的是提供測試維護人員對于失敗進(jìn)行詳細及快速的定位。畢竟在自動(dòng)化用例規模過(guò)大的時(shí)候，自動(dòng)化的監視對象主要還是失敗用例。自動(dòng)化測試結果如圖3所示。

圖3 自動(dòng)化測試結果展示圖

4.4　自動(dòng)化測試用例設計與測試代碼質(zhì)量保證

在我們的測試團隊中，自動(dòng)化測試用例代碼的編寫(xiě)是多人協(xié)作開(kāi)發(fā)的模式，對于如何保障用例本身的代碼質(zhì)量，我們做了很多嘗試和努力，以?xún)蓚€(gè)實(shí)踐中有效嘗試為例，在該部分做個(gè)說(shuō)明。

結構化代碼設計，以便于更簡(jiǎn)單地復制和改寫(xiě)用例。測試代碼由多人開(kāi)發(fā)，在過(guò)程中，有很多重復性的代碼，那么，將這些部分進(jìn)行模塊化處理，供公共調用，有效減少了測試代碼量，維護代價(jià)非常小。

自動(dòng)化代碼的代碼檢視。通過(guò)代碼的交叉檢視，不僅能發(fā)現個(gè)人代碼過(guò)程中的錯誤及不符合規范項，還能在檢視別人的代碼中提升自我。前提是我們的自動(dòng)化團隊形成了自己的自動(dòng)化代碼規范且包含了自動(dòng)化用例設計指導原則等。當前，代碼檢視不能側重于發(fā)現代碼缺陷，它是一個(gè)監督項，可以使我們的團隊不斷提升自動(dòng)化測試代碼質(zhì)量。

4.5　部署和管理

對于自動(dòng)化測試當前耗時(shí)和可預見(jiàn)的未來(lái)用例及運行時(shí)長(cháng)規模來(lái)說(shuō)，自動(dòng)化架構設計之初運行環(huán)境必須采用分布式部署，才能滿(mǎn)足自動(dòng)化構建時(shí)長(cháng)的要求。因被測軟件部署于Windows平臺，設計使用PowerShell及PowerShell DSC來(lái)完成自動(dòng)化測試整體的部署和管理。此設計具有強大的兼容性，完全兼容Windows平臺上的其它調用，且基于平臺具備很好的可擴展性，也可以進(jìn)一步利用.NET Framework的強大功能。

在此特別需要說(shuō)明一下的是PowerShell DSC。在集群機器管理中，通過(guò)使用PowerShell DSC保持自動(dòng)化運行環(huán)境的可控和一致性，體現在操作系統和被測試應用軟件上。通過(guò)它的使用同樣降低了腳本的復雜度，可大幅度提高迭代速度。將環(huán)境從結構中分離出來(lái)，此類(lèi)模型設計同樣契合與DevOps理念。自動(dòng)化測試部署如圖4所示。

圖4 自動(dòng)化測試部署圖

4.6　持續集成

自動(dòng)化測試想要發(fā)揮最大化的價(jià)值，就不能不涉及持續集成。在不斷迭代的被測試軟件版本中，自動(dòng)化測試的防護網(wǎng)持續攔截且保持測試標準的一致性，這是自動(dòng)化測試的理想應用狀態(tài)，因此，我們的自動(dòng)化測試方案設計中關(guān)于持續集成的落地在此做一說(shuō)明。

開(kāi)發(fā)代碼一旦入庫，通過(guò)配置的版本構建，會(huì )經(jīng)過(guò)持續自動(dòng)化的質(zhì)量保證環(huán)節。主要的構建步驟如圖5所示。

圖5 自動(dòng)化測試持續構建圖

4.7　TestOps的展望

新的理念與技術(shù)層出不窮，對于工業(yè)軟件的自動(dòng)化測試設計方案也是在不斷接受新鮮事物的過(guò)程中集成、完善、逐步優(yōu)化的。顧名思義，TestOps即測試運維。從測試的角度推動(dòng)研發(fā)和運維，將測試落地到整個(gè)研發(fā)體系的關(guān)鍵崗位。它關(guān)注全生命周期的質(zhì)量控制、測試過(guò)程接地氣、關(guān)注環(huán)境及代碼驗證、關(guān)注質(zhì)量統計分析及回溯。概念圖如圖6所示。

圖6 TestOps概念圖

在優(yōu)秀的TestOps體系中，我們關(guān)于工業(yè)軟件自動(dòng)化測試框架的設計及整體的CI設計已經(jīng)有部分優(yōu)秀的實(shí)踐活動(dòng)進(jìn)行了落地。但是將測試落地到整個(gè)研發(fā)體系的關(guān)鍵崗位，我們做得還不夠，有很大提升空間。

例如如何讓測試團隊專(zhuān)注于提供基于被測軟件的所有級別的測試，從低級到高級，從功能到集成，形成完整的測試體系。

例如環(huán)境與持續集成工具，雖然我們當前使用了一些工具用于環(huán)境快速部署和持續集成，但是優(yōu)秀的工具不斷更新，對于工具的使用，我們不僅要追求用得全面，更要追求用得優(yōu)異。

例如多種靜態(tài)、動(dòng)態(tài)測試工具，只要適用且有效，都可以不斷納入我們的持續集成流程。

一個(gè)例如就是一個(gè)大的進(jìn)步方向。相信通過(guò)不斷的自我提升、自動(dòng)化測試團隊的提升，我們關(guān)于工業(yè)軟件的測試體系會(huì )更完善、更高效。

參考文獻：

[1] [英]格雷, 福斯特. 自動(dòng)化測試最佳實(shí)踐[M]. 北京: 機械工業(yè)出版社, 2013.

[2] 郭偉斌, 郭錫坤. 自動(dòng)化測試的研究和探討[J]. 電腦開(kāi)發(fā)與應用, 2008, (12) : 10 – 12.

[3] [美]達斯汀, 加瑞特, 高夫. 自動(dòng)化軟件測試實(shí)施指南[M]. 北京: 機械工業(yè)出版社, 2010.

[4] 趙麗珍. 基于數據驅動(dòng)的自動(dòng)化測試平臺設計[J]. 福建電腦, 2011, (02) : 135 – 136.

作者簡(jiǎn)介：

方　壘（1976-），男，江西贛州人，高級工程師，碩士，現任和利時(shí)集團聯(lián)席總裁、杭州和利時(shí)自動(dòng)化有限公司總裁兼首席技術(shù)官，長(cháng)期從事工業(yè)自動(dòng)化、信息化系統的產(chǎn)品技術(shù)研發(fā)及應用推廣工作。

邊　濤（1983-），女，陜西榆林人，工程師，碩士，現任杭州和利時(shí)自動(dòng)化有限公司西安分公司資深軟件測試工程師，從事測試及自動(dòng)化測試工作。