● 在規劃中，將來的2～3年內使所有的應用系統上線都必須有數字化的測試數據作為依據。
2.公司應用系統的情況
由于保險公司的業務種類繁多，同時在經過了幾十年的經營后，公司內的應用系統從早期的終端方式到現代的J2EE和.NET等應有盡有，魚龍混雜。IT部門已經建立的3年規劃，即在未來的3年時間內將所有終端和C/S方式的應用轉換成B/S架構，但當前仍然需要對這些舊應用系統進行維護，以保證業務的順利進行。對于開發部門來說，目前新應用開發基本上已經以B/S架構為主，主要是基于J2EE架構的Web HTTP應用和部分Window.NET Form的應用。
3.公司軟件測試現狀
企業機構在做測試自動化選型時一定要考慮清楚企業內部哪些部分可以實施自動化、哪些部分暫不實施自動化、哪些部分僅在某幾個項目做自動化試點。切忌匆忙上馬或盲目否定，缺乏實事求是的理性思考。
測試部門目前僅負責系統測試和對用戶驗證測試進行管理，對于之前的單元測試和集成測試主要由開發團隊中劃分出的一部分臨時測試人員完成。由于缺乏監測手段，測試部門也無法收集和確定集成測試和單元測試的完成情況，在整個軟件測試過程中，業務需求是由開發部門通過Rational RequisitePro進行管理，但測試需求目前尚沒有提出要求，測試案例主要通過在公司公用的文件服務器中的目錄管理方式管理，對測試中缺陷流程等管理主要依靠郵件的流轉進行處理。目前90%以上的測試是通過Excel和Word等測試案例文檔來完成，測試人員對軟件測試自動化的認識僅停留在“記錄+回放”的認識上。
4.可供選擇的方案
方案A: A公司可以采用美科利(Mercury)公司產品為主的軟件測試自動化方案。
● 依照原先的郵件流轉過程配置TestDirector缺陷管理流程，為每個保險業務的開發小組和測試團隊分配相應的用戶許可證，取消原有郵件方式。
● 部署Mercury Quick Test Professional，以便完成應用程序相關功能測試。
● 部署Mercury Load-Runner。從測試團隊中分化出專職的性能測試自動化工程師和小組，和業務部門協調，建立A公司應用系統上線性能指標，通過LoadRunner給出測試指標。
● 建議A公司成立專門的質量控制部門，對TestDirector中的數據定期進行分析，建立相關質量模型，以便于企業量化管理和過程改進。
方案B: A公司也可以采用IBM Rational產品為主的軟件測試自動化方案。
● 采用Rational Test manager來進行整個測試流程的管理，為相關開發和測試小組成員分配相應權限，改變以前通過郵件以及Word、Excel文檔管理測試的工作方式。
● 部署Rational Robot，用它來完成功能相關的測試工作以及新版本發布時的冒煙測試。此外，Rational Robot也能較好地完成性能相關測試。統一的操作方式降低了工具的學習周期和培訓帶來的大筆開銷。
● 部署Rational Purify plus，使測試工作前移到開發階段。由于Purify plus能較好地支持白盒測試，編程人員在編碼階段引入的錯誤能盡早被檢測到，這大幅降低了后期測試的開銷。
● 建議A公司成立專門的質量控制部門，對Test manager中的數據定期進行分析，建立相關質量模型，以便于企業量化管理和過程改進。
方案C: A公司也可以采用開源軟件為主的軟件測試自動化方案。
● 采用Bugzilla來進行Bug跟蹤管理，采用Bugzilla Test Runner進行測試用例管理，采用CVS進行測試資源的配置管理。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
