軟件測試是軟件工程的一個范疇，它作為軟件工程的一部分，隨著軟件生產的產業化運作應運而生。從20世紀70年代開始，隨著計算機技術的飛速發展，計算機軟件在整個社會系統中的地位也越來越重要，而計算機軟件開 發的規模和復雜度也隨著其需求和重要度的增加而急速上升。在過去的20年里，對軟件測試的最初認識只是“證明程序的正確性”，而后一系列的軟件測試理論和方法被逐漸的提出，在1983年由IEEE提出了目前比較認可的軟件測試定義，即：“為了檢驗某個應用系統的過程是否滿足規定的需求，并了解預期結果和實際結果之間的差異，而使用手工和/或自動化手段來運行并驗證這一過程”。按照這個定義，軟件測試的目的是監測和排除缺陷，以確保軟件產品在可用性，功能性，可操作性等多方面滿足軟件需求。

從上世紀90年開始，產業界開始意識到被動的以監測和發現錯誤為目的的軟件測試無法避免軟件開發過程中由于軟件需求和設計等方面的缺陷所帶來的巨大風險，所以在整個產業界開始從軟件質量控制（SQC, Software Quality Control）開始轉移到軟件質量保證（SQA, Software Quality Assurance），從而使軟件測試從單純的缺陷檢測和發現覆蓋到整個軟件開發過程，同時軟件測試的流程和軟件測試技術也成為了獨立研究的方向。我們已經了解到一個典型的軟件過程可以分為測試需求分析，測試設計，測試執行，缺陷和配置管理過程等許多個不同的階段。在軟件測試技術方面也已經被細化為單元測試，集成測試，系統測試，用戶驗收測試等不同的測試技術。

 

隨軟件測試技術的發展和測試流程管理的需求，實現軟件測試自動化的趨勢已經不可逆轉了。目前，軟件測試自動化主要集中在軟件測試流程的管理自動化，和動態測試的自動化，如功能測試自動化和性能測試自動化方面，還有是少部分的靜態測試，如代碼走查，它們常常比較容易從開發過程剝離出來。

 

相比于手工測試，測試自動化的優勢是明顯的。首先自動化測試可以提高測試效率，使測試人員更加專注于新的測試模塊的建立和開發，從而提高測試覆蓋率；其次，自動化測試使測試資產的管理數字化，并使測試資產得以在整個測試生命周期內得到復用，這個特點在功能測試和回歸測試中尤其具有意義；此外，通過測試流程的自動化管理使機構可以通過流程的關鍵績效指標（KPI, Key Performance Indicator）來衡量測試過程的有效性，從而實現了從軟件質量保證向軟件質量管理（SQM, Software Quality Management）的進化。根據Oppenheimer Funds的調查，在2001年前后的3年中，全球范圍內由于采用了測試自動化手段所實現的投資回報率（ROI, Return Of Investment）更高達1500％。

 

      那么，對于一個企業用戶來說，什么樣的軟件測試自動化方案將是他們所最需要的呢？在回答這個問題之前，首先我們必須注意到，作為企業用戶，在企業內部通常存在許多不同種類的應用平臺，應用開發技術也不盡相同，甚至在一個應用中可能就跨越了多種平臺；或由于開發時期的不同，可能導致同一應用的不同版本之間也存在技術差異。同時對于開發工作本身也可能多種形式，由內部團隊開發或是開發外包等等。所以軟件測試本身對于這些企業的QA和測試部門來說無疑是一個巨大的挑戰，他們考慮選擇軟件測試自動化的最根本出發點就是為了降低這些挑戰可能帶來的軟件產品質量和上線周期等方面的風險。根據筆者和不同企業用戶的溝通和交流，他們的自動化需求往往更多的集中在：

n         自動化軟件測試管理流程，以達到始終一致的軟件質量和可量化的，可衡量的測試過程管理。

n         通過實現測試自動化，以提高測試案例的復用和實現內部標準化，從而提高測試效率。

      但同時，企業用戶也將綜合考慮測試自動化給當前的企業部門與部門間的合作以及現有的工作流程所帶來的沖擊，在軟件測試自動化過程中也往往選擇“進化”（Evolution）方式，而不是“革命”的(Revolution)方式。

     

企業在實現測試自動化過程中，一個有趣的現象是絕大多數的中國企業用戶會選擇在企業內部（In-House）實現測試自動化，他們希望參與這個自動化的過程，并且更加在乎自己來建立并管理這個自動化流程；他們不僅限于通過軟件測試自動化來滿足上述需求，而且希望通過自動化過程的實施也到達學習和提高團隊測試技能的目的。與此相比，不在少數的歐美企業用戶他們可能會選擇測試自動化平臺托管服務（Hosted Service），或者外包（OutSourcing），離岸（Off-Shore）和派遣（Staffing）等多種方式相結合來實現，對他們來說，更加注重的是軟件測試自動化所帶來的結果，而非自動化過程本身。

 

      在我們已經了解到的大多數的企業用戶對軟件測試自動化的需求之后，再來看看他們又是如何對軟件測試自動化的方案進行選型的：

n         選擇盡可能少的自動化產品覆蓋盡可能多的平臺，以降低產品投資和團隊的學習成本

n         測試流程管理自動化通常被優先考慮，以滿足為企業測試團隊提供流程管理支持的需求

n         在投資有限的情況下，性能測試自動化產品將優先于功能測試自動化被考慮

n         在考慮產品性價比的同時，產品的支持服務和售后服務的完善性也備受關注

n         趨向于選擇主流產品，以便于通過行業間交流甚至網絡等方式獲得更為廣泛的經驗和支持

n         對測試自動化方案的可擴展性提出要求，以滿足企業不斷發展的技術和業務需求

     

下面是一個典型的企業客戶實現其軟件測試自動化的案例。

 

      A公司是一家大型保險公司，擁有近20個城市的分公司，并在其中5個城市建立了IT支持中心。這些IT中心負責所有內部應用系統的開發和運維，同時負責管理IT集成商和第三方應用供應商。平均每年的上線應用數量在20個左右（新業務系統和原有業務系統的主要版本發布）。其開發團隊主要分布在2個城市，大約有300名左右，同時20％左右的項目是通過項目開發外包，或直接從第三方采購獲得。目前A公司的專職測試團隊人數不足30人，而且測試團隊的測試人員技能參差不齊，目前測試只是作為項目上線前的一道工序而已。在測試團隊內部也幾乎沒有自動化的手段，主要依靠手工測試；但在和研發部門的溝通等方面，都有明確的郵件往來規范和例會等既定的管理方式。由于已上線應用系統的問題，開發團隊必須分出一部分資源去維護和修復上線應用，而同時測試團隊的的測試成果和效率卻無法和這些應用質量掛鉤，也更無從談起對軟件質量的控制。A公司已經決定在軟件質量和測試方面進行投入，他們考慮：

1．               引進軟件測試流程管理的自動化，提高軟件測試過程的管理水平，使軟件測試和軟件開發一樣可被評估，被衡量。

2．               實現性能測試自動化，所有應用上線之前必須有應用性能風險評估報告和相關部門的確認

3．               逐步實現功能測試的自動化，在目前人員配置的情況下，把部分手工測試變成自動化測試，提高測試可信度，降低人為錯誤。

4．               通過軟件測試自動化，管理軟件測試中的案例，缺陷，報告等資產，進一步提升軟件測試的效率并建立測試基礎庫。

5．               在規劃中，將來的2－3年內使所有的應用系統上線都必須有數字化的測試數據作為依據。

 

      由于保險公司的業務種類繁多，同時在經過了幾十年的經營后，公司內的應用系統從早期的終端方式到現代的J2EE和.NET等應有盡有，龍蛇混雜。IT部門已經建立的3年規劃，即在未來的3年時間內將所有終端和C/S方式的應用轉換成B/S架構，但當前仍然需要對這些舊應用系統進行維護，以保證業務的順利進行。對于開發部門來說，目前新應用開發基本上已經以B/S架構為主，主要是基于J2EE架構的Web HTTP應用和部分Window .NET Form的應用。

 

測試部門目前僅負責系統測試和對用戶驗證測試進行管理，對于之前的單元測試和集成測試主要由開發團隊中劃分出的一部分臨時測試人員完成。由于缺乏監測手段，測試部門也無法收集和確定集成測試和單元測試的完成情況，在整個軟件測試過程中，業務需求是由開發部門通過Rational RequisitePro進行管理，但測試需求目前尚沒有提出要求，測試案例主要通過在公司公用的文件服務器中的目錄管理方式管理，對測試中缺陷流程等管理主要依靠郵件的流轉進行處理。目前90％以上的測試是通過Excel和Word等測試案例文檔來完成，測試人員對軟件測試自動化的認識僅停留在“記錄＋回放”的認識上。

     

通過多方多輪的評估和論證，以及經過各個廠商的現場演示，甚至包括為期1周左右的實際試用，A公司最終采用了一個以全球業務優化科技（BTO）領導者美科利（Mercury）公司產品為主的軟件測試自動化方案，在這個軟件測試自動化方案中同時考慮了集成A公司現有的資源和流程，盡量降低解決方案導入的初期門檻，同時根據要求在實施過程中也并非一步到位，而是通過制定的詳細的實施計劃，分步驟展開實施：

初期實施階段：

1．              部署Mercury Quality Center服務器。依照原先的郵件流轉過程配置其TestDirector的缺陷管理流程，為每個保險業務的開發小組和測試團隊分配相應的用戶許可證，首先要求所有正在測試和將要進行測試的項目都必須通過這一缺陷管理流程進行缺陷遞交和處理，原有郵件方式取消。并安排和培訓一名測試管理工程師負責接受測試流程的改進意見和負責流程優化工作，以逐步完善流程管理自動化。

2．              部署Mercury QuickTest Professional。選擇Mercury QTP而非WinRunner和其它產品的考慮主要出于它對新應用平臺的廣泛支持性，和用戶的易學易用性，可以使測試團隊比較快的上手使用，并隨著為當前的項目建立和運行最初的自動化測試，獲得軟件測試自動化嘗試的信心。但目前對美科利（Mercury）建議的Business Process Testing不作考慮。

中期實施階段：

1．              通過Mercury集成Rational的需求管理工具RequisitePro，以實現測試需求的管理。并利用現有的Mercury Quality Center平臺引入測試案例管理流程，把所有基于Word和Excel的舊有案例，利用美科利（Mercury）提供的轉換工具導入到TestDirector中去，從而建立可被參考和追蹤的測試案例庫。同時由測試部門協調整個執行過程，對測試環境，測試數據，被測系統（SED）的調配實現統一管理，避免可能存在的各部門競爭測試資源的狀況。

2．              部署Mercury LoadRunner。從測試團隊中分化出專職的性能測試自動化工程師和小組。和業務部門協調，建立A公司應用系統上線性能指標。值得注意的是由于A公司的應用系統的地域分布性，在通過公司內網遠程執行LoadRunner測試案例時受到現有網絡帶寬的限制，很難達到測試成果。盡管美科利（Mercury）公司建議A公司引進美科利（Mercury）的Performance Center平臺以實現整合和遠程操控，由于公司預算和目前對性能測試的技能尚不足以建立整合平臺，A公司最終沒有采納。最后，由于性能測試通常是在業務應用經過了一輪的系統測試以后進行的，A公司決定把性能測試實驗室環境集中在一處，并不需要做性能測試的應用發布到該實驗室進行統一測試。

3．              對已經開始的功能測試自動化進行優化，從測試小組中篩選出自動化測試專家，負責A公司自動化測試庫的建立，進一步提升軟件測試自動化的價值。

長期實施階段：

1．              由于自動化測試管理的進行，測試缺陷和測試案例已被大量收集，過程也正在逐步優化。A公司考慮在Quality Center平臺上考慮實現“軟件質量門戶”的思想，即和公司應用軟件質量相關的信息都通過這個平臺來得到，相關的流程都可以通過這個平臺來實現。其中包括了作為一個質量門戶必須提供的針對軟件質量管理和軟件測試過程中不同人員角色所定義的視圖，衡量軟件質量和測試流程效率的關鍵績效指標（KPI），除測試過程管理以外的服務支持管理（如變更管理，配置管理，發布管理）等。

2．              考慮整合A公司的測試團隊和其它分布的非全職測試人員，整合各個團隊的測試經驗和資源，建立獨立的軟件質量管理和測試中心。

 

由于不同客戶在組織架構，員工素質以及流程管理水平等方面的不同，我們很難用一個實例來說明它的普遍適用性。然而大多數客戶完全獨立于廠商，獨立于技術的軟件測試自動化的需求和希望通過軟件測試自動化來達到的目的卻往往是具有共性的，而這種共性所提供給其它企業客戶的借鑒不是他們采用了那個平臺，利用了何種技術，而是實現軟件測試自動化的過程本身，以及在這個過程中所體現的具有普遍適應性的軟件質量管理和軟件測試的最佳實踐。

 

既然我們談到了軟件質量管理和軟件測試最佳實踐，很顯然這些最佳實踐本身并不依附于軟件測試自動化的，它更多是來自于比如ITIL（IT Infrastructure Library）框架，或來自于一些標準化，如CMM/CMMi中的關于SQA的KPA（Key Performance Area）。所以，我們說軟件測試自動化是一個必然趨勢，但對企業來說，它并不意味著是必須馬上啟動的項目，或者甚至所有企業都必須跟隨的唯一道路。

 

首先，一個企業實施測試自動化，絕對不是拍腦袋說干就能干好的，它不僅涉及測試工作本身流程上、組織結構上的調整與改進，甚至也包括需求、設計、開發、維護及配置管理等其他方面的配合。如果對這些必要的因素沒有考慮周全的化，必然在實施過程中會處處碰壁，既定的實施方案也無法開展。其次，盡管自動化測試可以降低人工測試的工作量，但并不能完全取代手工測試。100％的自動化測試只是一個理想目標，根據筆者的經驗即便一些如SAP, Oracle ERP等測試庫規劃十分完善的套件，其測試自動化率也不會超過70％。所以一味追求測試自動化只會給企業帶來運作成本的急劇上升。再次，比較測試自動化需要企業有相對規模的投入，對企業運作來說，投入回報率將是決定是否實施軟件測試自動化的最終指揮棒，筆者建議企業在決定實施軟件測試自動化之前，必須要求量化的投資回報分析。此外，軟件測試自動化并不就是采購強大的自動化軟件測試工具或自動化管理平臺，畢竟軟件質量的保證不是依靠產品或技術（Technology），而且更多的因素在與高素質的人員（People）和合理有效的流程（Process）。