論基于qtp的金融軟件自動化測試框架

基于QTP的金融軟件自動化測試框架何謂自動化測試框架呢？我認為它就是一個關于自動化測試總體設計規(guī)劃和一個關于設計細節(jié)的規(guī)范，同時我認為自動化測試框架至少應該包含下面三個部分：測試工具使用規(guī)范、業(yè)務功能模塊分解、測試數(shù)據(jù)分離與管理。圖1.自動化測試框架草圖下面分別對這三個方面進行簡單的闡述，不只針對回歸測試，大家可以把系統(tǒng)測試也考慮進去，希望能起到拋磚引玉的作用。我呢，經(jīng)驗不多參加工作才一年，可能有些看法比較偏頗或者錯誤，希望大家不吝指教。 測試工具使用規(guī)范 先談談規(guī)范化的必要性(引用來源51Testing)腳本的生成方式就兩種，一種是自寫腳本，一種是錄制生成。腳本不管錄制也好，還是手寫也好，選擇的時候應該以腳本模擬程序真實有效為準，結合項目進度，開發(fā)難易程度等因素考慮。而腳本的開發(fā)也需要符合一種規(guī)范，也可以說是一種習慣，因為腳本不只是開發(fā)者一個人看，測試執(zhí)行人員也需要看，這就要求可讀性和可維護性提高；故而開發(fā)時應該考慮這層因素，規(guī)范一下。綜合起來可以得到以下結論：1. 手寫可讀性好，流程清晰，檢查點截取含義明確。業(yè)務級的代碼讀起來總比協(xié)議級的代碼更易讓人理解，手寫可能花費更多時間，但是也更容易維護，必要時可建立一個腳本庫。而錄制生成的代碼大多沒有維護的價值，現(xiàn)炒現(xiàn)賣。2. 其次，業(yè)務邏輯稍微復雜一點的系統(tǒng)單憑錄制是不可能檢查到絕大部分異常的，只有手工書寫的時候邊寫邊思考可能會發(fā)生哪些異常，才能使腳本更具邏輯性、完整性和健壯性，給業(yè)務流程控制提供一個好的依據(jù)。 其次是如何做，做些什么規(guī)范1. 在做框架設計定義的時候，需要定義好代碼規(guī)范，如變量名稱定義規(guī)則、注釋規(guī)則、變量聲明規(guī)范、循環(huán)時間和次數(shù)上限、等待時間的處理方法、單個Action和腳本的大小限制等等，這些都是同C/C+、JAVA等程序員寫代碼的要求如出一轍，規(guī)范就是為了方便統(tǒng)一管理。2. 工具應用規(guī)范的制定，如：對象庫管理方式、關聯(lián)的驅動腳本和批處理、測試工具的設置（如Active Screen，Run mode等）、測試結果存放分析、數(shù)據(jù)源管理維護、場景錯誤恢復和資源、環(huán)境定義等等。3. 并不是所有進行自動化測試的人員技術和經(jīng)驗都在一個層次上，所以在設計框架的時候需要對于一些疑難或者可能會出現(xiàn)麻煩的地方事先進行說明或者做出培訓計劃。這是風險規(guī)避的一條途徑。4. 明確測試目標，規(guī)定對數(shù)據(jù)檢查的程度和測試目的，F(xiàn)AT、ST還是UAT，否則在UAT階段仔細校驗數(shù)據(jù)，工作量就非常大了，當然如果有ST測試的腳本基礎倒是也不會花很多工夫，只是有些公司用QTP都是單只做UAT的。對象庫集中管理，為同一系統(tǒng)所有腳本提供共享庫抑或不共享，這是8.2以前留下的習慣，其實在9.0、9.2來說也是可以考慮的。 測試腳本存儲和運行管理有時候，我們沒有（公司沒有提供）QC/TD來管理我們的自動化測試（當然其他的自動化測試管理工具我也沒有見過、用過，就以QC/TD為例吧），而有時候我們擁有管理工具卻缺少必要的主策略和網(wǎng)絡協(xié)議（可能會出現(xiàn)這種情況吧），這就導致了QTP自動化測試管理的多樣性；當然多數(shù)情況下，用得起QTP的也是能用得起QC/TD的，呵呵。1. 有QC/TD作為我們的測試腳本存儲和運行管理（拋開需求和缺陷管理不說）的時候，我們的自動化測試流程管理顯得簡單的多。腳本編寫、存儲、測試實驗室業(yè)務流程的建立、測試執(zhí)行和結果分析等等。一般情況下，這些規(guī)則之需要簡單的口述即可，當然一定需要闡明的話也是很簡單的，只是需要結合我們要說的其他幾個部分來敘述，這里不再贅述。2. 對于沒有QC/TD的情況，可能大家見過很多管理方式，類如FTP、共享磁盤等等；一個共同的要點就是“共享”。如果一個系統(tǒng)或項目有多個自動化腳本設計者協(xié)同工作，而大家各自為戰(zhàn)把腳本存儲在自己的私人空間里就會產生很不好的效果。因為整個系統(tǒng)的測試被割裂，很多需要關聯(lián)的業(yè)務流程就無法組合，尤其對于金融軟件來說，功能測試也好、回歸測試也好，這樣自動化就成了一個擺設：它無法覆蓋很多的關聯(lián)性很強的業(yè)務流程。其次，在本地空間存儲有一個潛在的安全隱患，因為可能由于誤操作或者磁盤的損壞導致一個月的工作付諸東流。而共享服務目錄和FTP器一般都是相對比較穩(wěn)定的。最后，本地測試執(zhí)行要覆蓋不同的業(yè)務流程一般需要使用一個驅動腳本，由它來指引流程的走向，負責數(shù)據(jù)文件的獲取并且完成測試結果的定點存放。這個腳本一般可能都比較喜歡用VBS吧（我見到的都是）。3. 本地存儲，QC/TD上執(zhí)行是行不通的，想法也很愚昧，呵呵；而在QC/TD上存儲、拿到本地執(zhí)行也許是一種變通的法子，可以解決局域網(wǎng)網(wǎng)絡協(xié)議和安全策略對QC/TD的封殺；但是在網(wǎng)絡協(xié)議和安全策略正常的情況下，這種方法也是不可取的，因為這樣遠沒有QC/TD管理起來方便。非要這么做的只有一種可能：那就是QC/TD只是作為存儲工具，浪費啊，呵呵；堅持這種做法的大約會是很老的前輩了，因為以往QC/TD和QTP的功能沒有像現(xiàn)在9.0、9.2這么全面，要求很高的技術，這些前輩在這種條件下練就一身好技術，有了技術當然可以和測試管理工具抗衡了，呵呵，不知道怎么表達，反正沒有笑話的意思，表見怪哈。其實無論使用共享磁盤管理還是使用QC/TD管理都是可以的，只是QC/TD提供了一種比較省事的方法而已，當然，代價是昂貴的license，在本地運行管理相對來說需要更強的技術和更為細致的規(guī)劃設計，二者效果是一樣的。 業(yè)務功能模塊劃分熟悉一個應用系統(tǒng)的業(yè)務流程是非常關鍵的，因這為不僅在方法上給我們帶來很大的便利，而且從根本上將，我們做自動化（回歸）測試，多數(shù)都是為了某些個系統(tǒng)核心業(yè)務的完整性和正確性作保證，這當然要求我們精通“業(yè)務”。明確一個較為龐大的業(yè)務系統(tǒng)的業(yè)務流程不是件容易的事情，在多數(shù)情況下需要將精通的業(yè)務的同事拉進來參與我們的流程制定、選取和覆蓋設計。對業(yè)務模塊的精確劃分是我們完成一份高效的自動化測試的良好基礎，否則，我們的自動化可能為雜亂無章，甚至徒勞無功。那么業(yè)務模塊劃分的準則和依據(jù)到底是什么呢？不同的系統(tǒng)有著不同的標準，下面飲用一個案例對金融系統(tǒng)做個粗略的介紹。對金融系統(tǒng)來說，我們進行業(yè)務分解和設計業(yè)務流程的時候需要做如下要求：1. 較為模塊化的設計，避免重復的腳本，減少建立或維護腳本的成本。 2. 在應用軟件開發(fā)的同時，就可以同步進行腳本建立的動作，而且當應用軟件功能變動時，只需要修改業(yè)務功能腳本。 3. 由于應用軟件的功能已經(jīng)被分解成獨立的業(yè)務功能腳本，測試人員可以隨意組合業(yè)務功能腳本成為更復雜多樣的測試個案。 4. 測試輸入數(shù)據(jù)與驗證數(shù)據(jù)與腳本分開，儲存在另外的檔案，如純文字文件或 Excel 文件，測試人員可以更容易修改與維護。 5. 加強錯誤處理合結果分析判斷，讓腳本更有彈性。 當然這樣做也會帶來一定的額外開銷，但是這些都是必須的，自動化本身就是需要結合良好的管理以犧牲人力成本來贏得時間的，針對一些缺點我做一下簡單的注釋：1. 在編寫業(yè)務功能腳本時，需要精通測試工具腳本語言的工程師：其實很多公司都有實力尋找這樣的人，因為VBS本身相對比較簡單，雖然自動化測試還沒有在整個中國全面興起，但是有著豐富自動化測試經(jīng)驗的測試人員已經(jīng)非常多了。2. 每個Action都會有自己的輸入輸出參數(shù)，需要用文檔統(tǒng)一維護，控制變更：這的確增加了一些工作量，但是對測試本身的規(guī)范來說，是一大進步。3. 測試人員除了要維護測試計劃之外，還要另外維護數(shù)據(jù)文件：同上。4. 對測試工具以及腳本語言來說，使用數(shù)據(jù)文件可能也要注意數(shù)據(jù)文件的格式。 這個分解結果來自51Testing上的一位同仁，我在做完興業(yè)銀行自動化之后做總結的時候無意發(fā)現(xiàn)了這段話，猿糞哪！與我的想法不謀而和，呵呵，所以當時就Copy下來了，并非有意剽竊，如果侵犯了這位仁兄，敬請原諒！這里修改了一些地方，我覺得這是金融尤其是銀行業(yè)務分解的一個經(jīng)典，也算是一個不大不小的標準吧，可能并不能適用于所有系統(tǒng)，但是對銀行來說，還是很實用的。下面以興業(yè)銀行交易處理中心項目自動化測試為例，看看這份業(yè)務分解和腳本規(guī)范會帶來什么樣的效果。（注：附件文檔乃非正式發(fā)布文檔，系個人私有，不牽涉興業(yè)銀行商業(yè)秘密，諸位放心?。┫到y(tǒng)說明：前臺Teller（銀行柜員操作界面）、電子驗印系統(tǒng)（印章校驗）、Integrator（信息管道）、工作流系統(tǒng)（IBM的FileNet）、后臺交易集中處理系統(tǒng)（中間業(yè)務平臺）、核心（聯(lián)想亞信的FTS）等?？紤]金融系統(tǒng)的安全性，所有交易流程的處理采用獨占的方式，后臺界面交易處理按交易優(yōu)先級次、時間先后進行，同等條件下FileNet隨機分配，所以自動化的難度相當?shù)拇?。交易功能分解按照操作員崗位職責劃分為前臺柜員，CPC（中間業(yè)務平臺）的錄入崗、審核崗、報文審核崗、異常處理崗、監(jiān)控崗等部分。實際應用：這樣的框架設計會帶來什么結果呢？我們來計算一下：1. 前臺發(fā)起的交易大約有60多個，每個交易的典型業(yè)務覆蓋需要大約20個流程，這樣共計1200個測試流程；2. 每個測試流程除去操作員登陸、簽退之后大約有10個腳本，這樣如果沒有采取公用的話，每個健全的腳本應該在200行左右，不計算重復的測試流程，總的腳本的行數(shù)應該是：10*200*60=行； 3. 但是采用了子模塊的公用，我們完整地寫了不到300個腳本（其中包含近百個10行以內的登陸、登出腳本），平均每個腳本只有不到100行，并且通文件系統(tǒng)操作覆蓋了所有的流程，即：300*100=30000行；4. 這樣可以清楚地看到，同樣覆蓋了1200個流程，我們節(jié)省了75%的腳本行數(shù)，減輕至少50%的工作量（考慮技術問題甚至80%），為QC/TD服務器也減輕了75%的存儲壓力，雖然在技術上帶來一定難度，但是也沒有產生多大的影響。如果在沒有外界壓力的情況下，這種框架設計是非常有效的。很明顯，稍微加大一些技術層面的工作量會給我們帶來很大的好處：1. 減少30%到50%甚至更多的腳本編寫的工作量，系統(tǒng)越大，有點越明顯。2. 后期維護難度和工作量在同一的管理下大幅度下降。3. 減輕了測試管理服務器的存儲壓力，對于QC/TD和QTP的license不多的企業(yè)和單位來說，統(tǒng)一協(xié)調運行、管理可以很大程度上減少由于license有限帶來的時效性不高的問題。剛才提到外界壓力，什么是外界壓力：我是你老大，我讓你寫1000個腳本你就不能偷懶寫900 數(shù)據(jù)分離和數(shù)據(jù)管理規(guī)范使用測試工具、規(guī)范開發(fā)腳本也許需要考慮的不是很多，業(yè)務分解也可以獲取大量的支持，但是相對這二者來說，數(shù)據(jù)分離和數(shù)據(jù)管理就需要綜合考慮了。對于類似銀行、保險、證券、信托等金融業(yè)務系統(tǒng)來說，數(shù)據(jù)量要求比較大而且對其準確性有著很高的要求，所以實現(xiàn)數(shù)據(jù)分離、管理就成了這個框架中最重要的一個點了。自動化測試中有一個很鮮明的概念叫“數(shù)據(jù)驅動”，事實上就是利用數(shù)據(jù)控制業(yè)務流程的走向，這是同前面提到的驅動腳本意思是相同的，只不過這兒說的數(shù)據(jù)是完全剝離開的，從腳本中獨立出來了。做到數(shù)據(jù)驅動不是很簡單的事情，因為這些金融業(yè)務系統(tǒng)的業(yè)務邏輯是非常復雜的，凡是接觸過這些業(yè)務的核心系統(tǒng)的朋友可能都有這個體會。為了完成數(shù)據(jù)驅動，我們必須熟知每一個我們要測試的業(yè)務節(jié)點的功能，這比性能測試對業(yè)務流程的掌握要高一些，同時還要掌握數(shù)據(jù)庫相關的表結構，當然其中最麻煩的就數(shù)表的關聯(lián)性了。熟悉了系統(tǒng)的需求、設計、數(shù)據(jù)庫表結構，聽起來可能有點危言聳聽，但是考慮到將來的使用，系統(tǒng)的不斷升級，我們花一些功夫還是值得的；一個上線了的核心業(yè)務系統(tǒng)一般不會在一兩年之內就淘汰的，金融業(yè)務的日新月異其實并不影響我們自動化測試的流程，一系列的升級和數(shù)據(jù)集中會體現(xiàn)出我們高質量腳本的價值所在。舉例來說，*保險公司一個養(yǎng)老險業(yè)務系統(tǒng)，無論業(yè)務需求怎么逐步更改，系統(tǒng)始終都會穩(wěn)固的擺在那兒；因為不到實在非廢棄不可的程度，誰愿意花費巨大的代價重新去做一個新的系統(tǒng)呢？為了保證對公眾業(yè)務的連貫性，一個系統(tǒng)始終會以改造升級的方式去運作。說這些無非就是想告訴大家，做一個優(yōu)秀的自動化個案，尤其在金融這個行業(yè)里，是值得的，絕對不會讓我們覺得浪費了太多精力而沒有實現(xiàn)他的價值。在外包公司，可以將這部分作為服務和系統(tǒng)開發(fā)成果的一部分移交到“甲方”；而在“甲方”，這些東西就可以直接應用于自己的運營測試。據(jù)我所知，很多公司在持續(xù)集成的時候配合LR、JUNIT等工具也使用了QUICKTEST PROFESSIONAL，大頻率的集成對我們的腳本的要求也是非常高的，如果做不好就會阻礙這部分工作。不花功夫去研究這些業(yè)務功能和數(shù)據(jù)邏輯會還有什么不利呢？從開篇的結果草圖可以看到，我將測試數(shù)據(jù)分為兩部分：動態(tài)部分和靜態(tài)部分。靜態(tài)數(shù)據(jù)是哪些呢：審核意見、客戶地址這些信息在Staging環(huán)境里是無關緊要的，后臺不會進行校驗，也不會影響到我們業(yè)務流程的走向，所以我們一般采用一些隨機函數(shù)將其帶過，還可以很大程度的上保證數(shù)據(jù)的唯一性。若是某個模塊不進行任何校驗，或者只有查詢之類的功能，抑或是一個不關緊要外圍（非核心）系統(tǒng)，我們大可以使用MI（HP）跟我們說的那樣Recording、Replaying。但是這樣的情況在金融業(yè)務系統(tǒng)里還是不占多數(shù)的。為什么我們不能使用固定那一條或幾條數(shù)據(jù)進行我們的測試呢，道理很簡單：1. 幾個數(shù)列的前幾項、十幾項規(guī)律看起來一樣但是后面各是什么樣誰能說得準呢？這么幾條數(shù)據(jù)校驗過去的系統(tǒng)拿到生產線上會不會出什么事故誰也不敢保證。我們在力所能及的范圍內盡可能減少這些事故發(fā)生的可能性就是我們的責任，也可以上升到職業(yè)道德上面去，嚇死人咧吧！2. 缺陷的修改往往會使用發(fā)現(xiàn)錯誤的那幾條數(shù)據(jù)進行校驗，或者就是針對這幾條數(shù)據(jù)修改了，怎么辦？如果還是用這么幾條數(shù)據(jù)來驗證，系統(tǒng)肯定還是好的；但是換幾條數(shù)據(jù)可能就不是那么回事了。我這兒不是詆毀編碼的蟈蟈們，這種情況我的確碰到過好幾次，呵呵。3. 有些人在某些地方喜歡將用過的數(shù)據(jù)UPDATE回頭，下次運行時繼續(xù)使用（我在做性能測試的時候就喜歡這樣，嘿嘿）。其實這樣做也是有一定的風險的，因為復雜的關聯(lián)性會讓你不小心漏掉某張表或者某個字段，這樣在運行的時候要么運行良好卻發(fā)現(xiàn)不了存在的缺陷，要么就出一些莫名其妙的問題讓你花費很多的時間去排查。那么多的觸發(fā)器，誰能保證面面俱到呢？當然有時為了進行復雜的操作我們必須去寫一些PROCEDURE、PACKAGE和JOB來配合我們的測試；有些人喜歡在腳本里直接調用這些過程或包，有些人喜歡用JOB與腳本并行操作。我屬于后者，我覺得在測試腳本里執(zhí)行浪費時間，但是并行可能會出現(xiàn)LOCK，需要計算時間耦合。這都是個人習慣問題，有問題大家可以評論哈。說了半天講的都是數(shù)據(jù)分離的必要性，到底怎么做呢？有沒有一個簡單的方法或者例子呢？莫急，聽我慢慢擺。我使用QTP第一個月（學習階段），傻乎乎的就把數(shù)據(jù)固定或者簡單地參數(shù)化一下以顯示我會這個功能，接下來我覺得這樣對流程性的測試很不利，于是就把數(shù)據(jù)寫到本地本文文件里，作為參數(shù)傳遞的方法。后來就考慮使用數(shù)據(jù)庫，建立本地數(shù)據(jù)源，直接向數(shù)據(jù)庫伸手了_，只是一下子就拋棄了EXCEL和TXT文件；過了很久才明白過來，本地文本可以拋棄，但是不拋棄卻另有好處。圖2. 測試數(shù)據(jù)使用流程如圖所示，從數(shù)