★ 杭州和利時自動化有限公司 方壘,邊濤
摘要:自動化測試在行業中的重要性和優勢是顯而易見的。本文介紹了在工業軟件的自動化測試探索中,如何克服被測對象提出的挑戰,從而摸索且實踐出的一套適合工業軟件的自動化測試解決方案,并對解決方案中的優秀實踐進行了介紹。
關鍵詞:自動化測試;工業控制軟件
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-),女,陜西榆林人,工程師,碩士,現任杭州和利時自動化有限公司西安分公司資深軟件測試工程師,從事測試及自動化測試工作。