文章分析了 UAT 的特性以及在 UAT 中實現測試自動化的重要性，進而提出了一個結合應用 Shell 腳本和 STAX 語言實現的從自動化下載 Build， 安裝， 執行測試用例， 生成測試報告的自動化解決方案， 對其中每一個部分進行了具體的分析和實現。
UAT與測試自動化
UAT 全稱為 User Acceptance Test, 即用戶可接受測試，是IBM產品開發周期的重要一環,
處於產品的構造和功能性測試之間，其目的是驗證每天的構造(daily build)的可接受性，即能否在這個 build 上進行後續的功能性測試。由於 UAT 是測試環節的首要步驟，能夠儘快給開發人員提供測試結果，所以不管採用傳統的軟體開發模型，還是使用今天被廣泛接受的敏捷開發模式，UAT 在產品開發周期中所扮演的角色均非常重要。
傳統的 UAT 測試基本都是人工完成的，如產品的安裝，基本的配置，針對各個模塊的功能執行測試用例等等。這種人工的測試方法會有很多問題。首先就是會存在大量的重複性勞動。在目前的軟體產品開發過程當中，迭代式開發很常見。開發人員很可能會將已經完成部分功能的軟體產品交付測試人員測試，而在測試人員測試的過程中根據測試人員的反饋或者用戶需求的改變不斷完善產品。這樣一來一天可能會有3到5個版本的安裝文件產生，而測試人員需要針對每個版本的安裝文件執行 UAT 一系列操作，也就是說同樣的測試步驟可能要被重複執行3到 5次；其次就是對於大型項目而言，UAT 操作很耗費時間，一次UAT測試的時間可能從 2，3 個小時到 7，8 個小時，每天需要多種平台和多重類型的 build，重複性的操作對測試人員來說是個很大的負擔。
將 UAT 自動化，一方面無人職守的全自動化測試方案會使得 UAT 測試提供 24*7 的服務成為可能，自動檢測 build 的狀態，下載並進行安裝、配置，執行測試用例, 最後生成測試報告，減少了等待時間，加速了產品的測試過程，縮短了開發周期。另一方面，自動化程度的提高解放了測試人員，使得UAT測試人員可以有更多的時間進行一些提高測試覆蓋率，準確性方面的工作，更好的保證了測試質量。本文針對 UAT 的特點，提出了結合使用 Shell Script 和 STAF/STAX 的 UAT 自動化測試解決方案，具有簡便、輕量級、開發周期短、靈活性好等特點。結合 shell 腳本對 STAX 任務進行觸發並且設計一系列的調度機制使得自動化系統可以對資源進行合理調配，從而使得無人值守的全自動化測試成為可能。另外通過該方案的實施，能夠提高軟體測試環節中的自動化程度和測試用例的可復用程度，很大程度上提高了測試效率，縮短了測試周期。本文提出並分析了一個一般化的用戶可接受性測試包含的各個部分，提出的自動化解決方案適用於所有 web-based 的產品的下載、安裝部署、配置、功能測試。作為例子，文中將使用通過此方案在 IBM WebSphere Portal 產品的 UAT 測試當中的應用來對此方案進行分析。
  |
為什麼採用 STAF/STAX
STAF（Software Testing Automation Framework）是開源的自動化測試框架，封裝了不同平台和不同語言間通信的複雜性，提供了消息、互斥、同步、日誌等可復用的服務，使用戶可以在此基礎上構建自動化測試解決方案。STAX（STAF Execution Engine）是運行在 STAF 之上的可解析、執行 XML 格式任務的一種服務。STAF提供了兩種服務，一種是內部服務(Internal Service)，即它在內部封裝了一系列的常用服務供用戶使用, 包括時間操作，文件系統操作，變數操作等；另外一種是外部服務(External Service)，STAX 本身就是 STAF 的一種外部服務，可以通過 STAX 規定的 XML 格式來編寫 STAX 腳本，實現測試人員的測試步驟。
STAX 與傳統的測試腳本，如 Perl，Shell 等，相比較，存在以下優點：
下面清單所示的代碼片段說明了 STAX 任務的基本結構。
<function name="listDir" scope="local"> <function-prolog>This function lists entries of specified directory on the target machine</function-prolog> <function-list-args> <function-required-arg name="target">Hostname/IP address of the target machine </function-required-arg> <function-required-arg name="targetDirectory">Target directory </function-required-arg> </function-list-args> <sequence> <script>cmd = 'LIST DIRECTORY %s' % (targetDirectory) </script> <!-- Run the staf list directory command using the supplied arguments --> <stafcmd> <location>target</location> <service>'FS'</service> <request>cmd</request> </stafcmd> <return>STAFResult</return> </sequence> </function> |
根據上面的代碼，我們可以大致看出 STAX 腳本的語法格式：
首先定義此功能模塊的名字，在這裡是“listDir”，相當於傳統語言中的函數名。然後在<function-list-args>元素裡面將腳本需要定義的參數列舉出來，相當於傳統編程語言中僅能夠在函數內部使用的局部變數。如果下面還需要用到一些變數的時候，可以通過<script>元素來定義，如“cmd”變數，這裡定義為：LIST DIRECTORY %s' % (targetDirectory)，LIST DIRECOTRY 是STAF內部服務的一種，相當於DOS系統的dir命令或者linux系統的ls命令。“%s”是通配符，匹配的是後面括弧當中的targetDirectory變數的內容，而targetDirectory是在<function-list-args>元素當中定義的。接下來有一個<stafcmd>元素，這個元素有三個子元素：<location>，<service>和<request>。其中location元素指的是這個服務應用的目標機器，service元素表示的是該服務的名稱，這裡“FS”，即File Service，而request元素指的是具體的服務命令字元串，這裡是在前面定義過的變數cmd。
|
基於 STAF/STAX 的 UAT 自動化測試解決方案
通常一個UAT的測試流程包括以下幾個部分： 檢測Build狀態，下載Build，檢測測試機狀態，進行安裝，進行配置，執行一些測試用例來驗證各個部件的功能，生成測試報告。為了完全覆蓋以上的這幾個方面，基於STAF/STAX的UAT自動化測試解決方案主要包括以下幾個步驟：
第一步，檢測安裝文件的狀態
通常，對於一個成熟的軟體產品，每天都會有一個或者多個版本的build。這些build一旦生成便會被上傳到一台專門的伺服器上。當生成過程結束之後，測試人員就可以下載這個版本的build進行測試，而UAT測試是整個測試流程的起點。因此，最節約時間的做法就是當文件剛剛生成結束之後就開始UAT測試，所以需要自動化的方法來不斷檢測build生成過程是否結束，一旦生成結束，就可以馬上開始UAT操作。但是對於一個項目而言，UAT測試人員很難立即得到Build過程完成的信息，這有很多因素：
因此， 測試人員人工來檢測Build生成狀態有很大的難度。Build Team通常提供一些對外的服務來發布Build的信息，比如維護一個HTTP Server或者FTP Server來讓遠程用戶能直接通過這些服務來獲得Build的目錄結構以便於下載Build。在UAT的自動化方案中，就可以通過Shell腳本訪問這些服務來獲得Build的信息。比如對於如下的目錄結構。
就可以使用如下的shell腳本來獲得最新的Build的版本號：
while [ ! -s "./builds.html" ] do sleep $sleeptime #將所有Build所在的目錄存成一個文件待用 wget $Remote_realese_url -O ./builds.html" >> $LOG_BASEDIR/`date +%Y-%m-%d-%H`.log done #從保存的文件中提取最新的Build版本信息，這裡使用AWK在文件中來獲得最新版本信息 latestversion=`cat builds.html | awk -F"STARTPattern" '{print $2}' | awk -F"EndPattern" '{print $1}' | grep $VERSIONPATTERN | sort | tail -1` if [ ! -d "$BUILDS_DIR/$ latestversion " ]; then #在本地創建當前Build版本的目錄 mkdir $BUILDS_DIR/$ latestversion fi |
第二步，使用 Shell 下載 Build 並開始觸發後續 STAX 任務
伺服器端 build 生成結束之後，接下來是 build 下載的過程，這部分可以和步驟一結合在一起，一旦檢測到 build 正確生成，那麼馬上開始下載。Build 的下載可以使用shell腳本實時訪問，根據 Build 伺服器提供的不同服務介面使用不同的檢測 build 並下載 build 的方式，常用的有 FTP 方式，HTTP 方式或者 HTTPS 方式。在判斷Build存在，創建完相關的本地目錄之後，對於一個 Build 需要的所有文件，可以使用相應的命令來進行下載。最簡單的有 wget，ftp。 也可以寫一些相對複雜的shell腳本加強下載的穩定性，可靠性和靈活性。
檢測 Build 狀態和下載 Build 都是由 Unix Shell 腳本執行的，而此後的測試機狀態檢測以及以後的安裝都由 STAX 腳本來執行。那麼怎樣由 Unix shell 來執行 STAX 腳本呢，STAX 的事件機制使得它的任務可以由外部觸發，這個觸發的方法如下：
#Trigger STAX event echo "start" while [ "$parameterFileNumber" != "0" ] do echo "start a STAX event..." echo "kick off STAX event, file number is $parameterFileNumber" let "parameterFileNumber=$parameterFileNumber-1" STAF STAXServer.cn.ibm.com SEM POST EVENT "$eventName" sleep 600 echo "a STAX event was triggered successfully!" done echo "Kick off UAT finished!" |
第三步，檢測測試機狀態
對於一個成熟的企業及軟體產品來說，測試環境往往比較複雜，而在測試環境的搭建過程當中任何一個小的問題都有可能導致測試的失敗，這並不是軟體本身的問題，所以在開始執行測試流程之前如何檢測測試環境的正確性是十分重要的。針對這一環節，自動化解決方案如圖:
第四步，安裝軟體
在 UAT 測試流程當中，當 build 下載過程結束，環境檢測通過，接下來的就是軟體產品的測試，也是整個測試流程一個真正意義上的“起點”，如果在接下來的測試過程中出現問題，很有可能就是產品本身的問題。
首先，就是軟體的安裝，一般軟體的安裝往往分為靜默安裝和圖形界面安裝，針對這兩種不同的安裝方式，自動化測試解決方案如下：
安裝軟體的STAX腳本片段如下:
<stax> <function name="InstallWebSpherePortal"> <function-prolog>InstallWebSpherePortal</function-prolog> <function-list-args> </function-list-args> <sequence> <!-- Step 1. Mount build server --> <call function="'mountBuildServer'">target, mountServer, remoteMountPoint, localMountPoint</call> <!-- Step 2. Copy image and create dir--> <call function="'copyImage'">target,destinyDir,destinyFPDir,destinyFile, localMountPoint,buildPuiDir,buildPtfDir,buildPuiNum,buildPtfNum, buildZipFileName</call> <if expr="STAXResult == 0"> <call function="'writeLog'">[target, 'Success copy image files .']</call> </if> <!-- Step 3. Stop all servers--> <call function="'stopAllServers'">target,portalProfileRoot, WPSUsername,WPSPasswd, WASUsername,WASPasswd</call> <if expr="STAXResult == 0"> <call function="'writeLog'">[target, 'Stop all servers success !']</call> </else> </if> <!-- Step 4. Start to install--> <sequence> <call function="'StartInstall'">target,portalServerDir, setUpCmdLineDir,destinyDir, destinyFPDir,WPSPasswd, WASPasswd,portalConfigDir</call> <if expr="STAXResult == 0"> <call function="'writeLog'">[target, 'Fixpack install finish success !']</call> </if> </sequence> <return>0</return> </sequence> </function> </stax> |
第五步，對安裝好的軟體進行配置
一般來說，在軟體安裝結束之後需要進行一些基本的配置操作，如軟體調優，配置資料庫數據源, 配置安全性等。基本上在 IBM 產品中這些操作都有相同的特性，即首先修改配置文件，然後執行配置命令， 中間會涉及到一些停止或者啟動伺服器的操作。針對不同的軟體及操作系統，這些操作都可以結合事先寫好的 Shell 或者 Bat 腳本，然後通過 STAX 腳本來觸發這些腳本。與安裝軟體的過程類似，可以通過 STAX 任務實時監控整個過程的狀態並及時彙報給測試人員。這一步驟成功結束之後，自動進入下一個測試環節。對於很多產品來說，兩個基本的配置工作分別是進行資料庫的配置和安全性的配置，例如在 WebSphere Portal 產品中，資料庫遷移配置和 LDAP 的安全配置是不可缺少的兩個配置步驟，實現這種配置的 STAX 示例腳本如下:
<stax> <function name="enableSecurity" scope="local"> <function-prolog>'Enable security for the portal on the target machine'</function-prolog> <function-list-args> <!-- Define arguments--> </function-list-args> <sequence> <!-- Step 1. Stop Portal. --> <call function="'retrieveWasPortalStatus'">[target, portalProfileRoot, wasUserId, wasPassword]</call> <if expr="STAXResult == 0"> <sequence> <call function="'writeLog'">[target, 'Portal is already started, begin to stop it...', 'user1']</call> <call function="'stopWasPortal'">[target, portalProfileRoot, wasUserId, wasPassword]</call> <if expr="STAXResult == 0"> <call function="'writeLog'">[target, 'Stop Portal successfully.', 'user1']</call> </if> </sequence> </if> <!-- Step 2. Run task --> <call function="'runConfigEngineTask'">[target, portalProfileRoot, 'wp-modify-ldap-security']</call> <if expr="STAXResult == 0"> <call function="'writeLog'">[target, 'Task wp-modify-ldap-security succeeded.', 'info']</call> </if> <!-- Step 3. Start portal --> <call function="'startWasPortal'">[target, portalProfileRoot]</call> <if expr="STAXResult == 0"> <sequence> <call function="'writeLog'">[target, 'Task EnableSecurity succeeded!', 'pass']</call> <return>0</return> </sequence> </if> </sequence> </function> </stax> |
<stax> <function name="DBTransfer" scope="local"> <function-prolog>'Transfer DB'</function-prolog> <function-list-args> <!-- Define arguments--> </function-list-args> <sequence> <!-- Step 1. Modify property files --> <call function="'MergeProperyFilesTool'"> [target, targetDirectory, targetFileName1, sourceFileName1, MergePropertyScript, domains1, append] </call> <call function="'MergeProperyFilesTool'"> [target, targetDirectory, targetFileName2, sourceFileName2, MergePropertyScript, domains2, append] </call> <!-- Step 2. Run task --> <call function="'runConfigEngineTask'">[target, portalProfileRoot, 'database-transfer']</call> <if expr="STAXResult == 0"> <call function="'writeLog'">[target, 'Task database-transfer succeed.', 'user1']</call> </if> <!-- Step 3. Start portal --> <call function="'startWasPortal'">[target, portalProfileRoot]</call> <if expr="STAXResult == 0"> <sequence> <call function="'writeLog'">[target, 'Task DBTranfer succeeded!', 'user1']</call> <return>0</return> </sequence> </if> </sequence> </function> </stax> |
第六步，執行RFT測試用例
在本文的開頭已經對 UAT 做了簡要的介紹，UAT 是保證一個新的版本的軟體或者軟體補丁產生之後，其基本的各個功能模塊能夠正常運行的測試環節。所以，在軟體安裝和配置工作結束之後，執行覆蓋軟體基本功能的測試用例，是很有必要的。
對於基於 Web 的產品,通常用RFT針對不同軟體的功能實現寫好測試腳本就已經能夠單獨運行。為了實現 UAT 的全部過程自動化，必須將這一部分同 STAX 腳本進行連接，用 STAX 觸發這些測試腳本並實時監控腳本的執行狀態。通過 STAX 來觸發 RFT 的 web 自動化腳本的任務示例如下：
<stax> <function name="runExampleRFTTest" scope="local"> <function-prolog>Runs a RFT testcase using LA</function-prolog> <function-list-args> <!-- Define arguments--> </function-list-args> <sequence> <!-- Run the RFT test on the RFT server --> <call function="'cafRunRFTTest'"> { 'rftServer' : target, 'properties' : mySuite, 'rftProjectArchive' : 'LWPServerGUI.zip', 'rftScript' : rftScript, 'rftScriptArgs' : rftArgs, 'maxExecutionTime': maxTime, 'browserName': browserType, 'browserPath': browserLocation, 'browserCommand': browserCmd, 'rftExecutionMode' : 'standalone' } </call> <script>(rftRunTestRC,rftRunTestCallResult) = STAXResult</script> <return>rftRunTestRC</return> </sequence> </function> </stax> |
第七步，生成測試報告和日誌
在所有的測試步驟結束之後，或者如果中途有環節出現測試錯誤，可以通過 STAF/STAX 生成一份測試報告併發送給測試人員，測試報告當中包括詳細的測試結果，失敗原因等等。試想一下，每天早上來上班的時候，一邊喝咖啡一邊打開郵箱，發現原來需要花費一天時間的工作已經在昨天夜裡執行完畢並且有一份完整的測試報告發送到郵箱，難道不是一件很愜意的事情嗎？
作為測試報告的來源，日誌是自動化測試任務的重要組成部分，一方面測試任務的開發人員可以利用日誌來調試腳本，另一方面，日誌作為測試報告的一部分使得測試任務的使用者了解測試任務執行結果以及執行過程信息。自動化腳本開發人員通過在腳本中調用 STAF/STAX 提供的 LOG Service 來生成純文本格式的任務日誌，較為方便。但其缺點在於不直觀，由於日誌本身的層次結構淹沒在海量的文本中，測試人員很難快速地找到自己想要了解的信息。針對這一缺點，我們把測試任務的結構自頂向下分為以下三個層次：
這樣，在任務執行的過程當中會有一份更加友好的日誌生成，包括各個步驟的執行情況，測試用例的通過情況等，日誌的概述結果就可以當作測試報告發送給測試者。生成的測試報告格式如下圖，這是一個基於HTML格式的報告。
下面所示的STAX代碼片斷提供了記錄日誌的函數writeLog，它接受日誌內容、日誌狀態、日誌類型等參數，向該任務的日誌目錄下的日誌文件中追加一條日誌。
<function name="writeLog" scope="local"> <function-list-args> <function-required-arg name="content"></function-required-arg> <function-optional-arg name="level" default="'info'"></function-optional-arg> <function-optional-arg name="type" default="'detail'"></function-optional-arg> <function-optional-arg name="state" default="'start'"></function-optional-arg> </function-list-args> <sequence> <script> displayLogName = 'Automation Runtime Text Output Log' #the actual name of the text log file. logFileName = '%s.txt' % STAXJobID #if content contains multiply lines, separate it from string import * lines = split(content, '\n') </script> <iterate in="lines" var="line"> <sequence> <if expr="type == 'testcase'"> <sequence> <script>line = '*TESTCASE %s:%s' % (state, line)</script> </sequence> <elseif expr="type == 'step'"> <script>line = '*STEP %s:%s' % (state, line)</script> </elseif> </if> <call function="'cafAppendJobOutputLog'">[target, 'local', line displayLogName, logFileName]</call> </sequence> </iterate> </sequence> </function> |
值得注意的是，為了進一步解析生成 HTML 日誌，我們把日誌的類型和狀態信息通過固定的標籤寫入了日誌之中：
*TESTCASE STATE TestcaseName *STEP STATE StepName |
對於一個確定的測試用例或者步驟，上述的標籤總是成對出現的，這樣才能保證能夠正確的解析到它們的邊界。LogHelper為一個 Python 類，它封裝了從文本日誌中解析層次信息後生成 html 格式日誌的細節，下圖為LogHelper類圖。
下面的代碼片斷為LogHelper類的核心方法parserLog方法。
def parseLog(self, logTxtFile): """ Parse the txt log file, information of testcases and steps will be assigned to the data field of this class.Translate the common txt lines to html and assign it to the htmlContent field. """ try: self._txtLogFileName = logTxtFile fp = open(self._txtLogFileName, 'r') except IOError, e: return (1, 'Open file %s failed' % logTxtFile) #use stacks to contain the parsed entries testcases = [] steps = [] for line in fp.readlines(): #remove the timestamp logInfo = line.strip().split('\t', 1)[-1] if logInfo.startswith('*TESTCASE') or logInfo.startswith('*STEP'): #it is a tag type,name = logInfo.split(':', 1) type,state = type.split(' ', 1) if type == '*TESTCASE': if state == 'start': testcases.append(name) self.addTestcase(name) else: testcases.pop() try: self.closeTestcase(name, state) except EntryNotFoundException, e: return (1, e.msg) else: if state == 'start': steps.append(name) try: self.addTestcaseStep(name, testcases[-1]) except EntryNotFoundException, e: return (1, e.msg) else: steps.pop() try: self.closeTestcaseStep(name, testcases[-1], state) except EntryNotFoundException, e: return (1, e.msg) fp.close() return (0, '') |
代碼下載 (code downloads)
單擊下載logHelper.py代碼
通過以上的步驟描述看出，測試人員所有的工作僅僅是制定測試任務，查看測試結果，而且測試任務僅僅需要制定一次就可以通過加入任務隊列的方式來重複執行，可見，這種基於STAF/STAX的UAT自動化測試解決方案極大程度上減少了測試人員的工作量，節約了測試人員寶貴的時間。
|
總結
以上闡述了基於STAF/STAX並結合使用Shell Script的UAT自動化解決方案，並且結合本團隊負責測試的逐個步驟進行了分析。根據UAT測試人員給予的反饋信息，這樣的一套全自動測試平台可以節約測試人員約80%的測試時間，極大提高了工作效率。同樣的方法結合使用shell腳本和STAX腳本可以實現很多日常工作中的自動化工作，在這方面，我們正在進行更多的嘗試。（責任編輯：A6）
[火星人 ] 結合使用 Shell 和 STAX 實現 UAT 測試的自動化已經有1161次圍觀
