自動化測試可行性分析報告.doc

XXXX客戶自動化測試可行性報告XXXX客戶網(wǎng)銀資金管理系統(tǒng)引入自動化測試的可行性分析報告版本：1.01. 概述1.1. 目的本文檔對XXXX客戶網(wǎng)銀資金管理系統(tǒng)項目引入自動化測試工具的可行性進行評估，為項目經(jīng)理提供決策參考。1.1 范圍本文檔描述了XXXX客戶項目情況、現(xiàn)有測試工作流程、自動化測試本身的一些情況，對測試工作量進行了估算，最后對估算結果進行了分析，并依此提出了一些建議。本文檔中討論的自動化測試工具主要是功能測試工具。1.2 術語定義本文檔涉及了幾款自動化測試工具：TestManager：IBM公司的測試管理工具，屬于Rational系列產(chǎn)品之一。Robot：IBM公司的性能測試工具，屬于Rational系列產(chǎn)品之一。RFT：Rational Function Tester，IBM公司的功能測試工具，屬于Rational系列產(chǎn)品之一。TestDirector：Mercury公司生產(chǎn)的測試管理工具。Loadrunner：Mercury公司生產(chǎn)的性能測試工具。QTP：QuickTest Professional，Mercury公司生產(chǎn)的功能測試工具。1.3 參考文檔2. 項目介紹2.1. 項目背景XXXX客戶網(wǎng)銀資金管理系統(tǒng)，是XXXX客戶為了加強銀行賬戶管理，提高資金利用效率而開發(fā)的一套資金管理系統(tǒng)。2.2. 項目開發(fā)、運行環(huán)境XXXX客戶網(wǎng)銀資金管理系統(tǒng)遵循的開發(fā)規(guī)范如下： 操作系統(tǒng)：Windows2003或者HP Unix或者SCO Unix或者AIX或者Solaris 數(shù)據(jù)庫平臺：Informix 9.0 J2EE應用服務器：Weblogic8.1.4 開發(fā)平臺：Eclipse（3.1以上版本）2.3. 項目進度項目的預定計劃如下：序號階段名稱工期開始時間結束日期1需求階段34工作日2006-5-102006-06-262開發(fā)階段64工作日2006-6-122006-9-73測試執(zhí)行階段48工作日2006-7-42006-9-72.4. 項目特點分析根據(jù)業(yè)務需求分析，業(yè)務量主要集中在銀行業(yè)務數(shù)據(jù)操作，包括銀行數(shù)據(jù)查詢，銀行業(yè)務數(shù)據(jù)變更，因為和銀行的交互集中在前置機上，且銀行數(shù)據(jù)量大，操作復雜，耗費時間長，所以系統(tǒng)在多用戶并發(fā)操作時，可能存在性能瓶頸。另外，由于XXXX客戶的分支機構眾多，操作人員多，數(shù)據(jù)量大，在多用戶并發(fā)操作時，性能和效率會有較大影響。3. 現(xiàn)有測試流程現(xiàn)有的測試流程按照階段劃分為測試設計階段和測試執(zhí)行階段。測試設計階段的主要工作是根據(jù)業(yè)務需求說明書和系統(tǒng)需求說明書來設計和編寫測試用例。根據(jù)以往的經(jīng)驗，將測試用例劃分成三個部分： 測試需求分析； 測試方案； 數(shù)據(jù)執(zhí)行步驟。測試執(zhí)行階段的主要手段是手工測試，如果項目有性能方面的需求，再通過Mercury公司的性能測試工具LoadRunner來進行性能方面的測試。手工測試時，要完成以下工作： 根據(jù)測試需求分析了解業(yè)務； 根據(jù)測試方案來執(zhí)行測試； 根據(jù)數(shù)據(jù)庫和詳細設計來驗證系統(tǒng)的具體實現(xiàn)； 根據(jù)測試結果補充、修正測試用例中的分析、測試方案部分。系統(tǒng)上線部署之前兩到三天，要進行內(nèi)部的驗收測試，其目的有兩個： 確認系統(tǒng)已經(jīng)準備就緒，預定功能已經(jīng)實現(xiàn)； 即將上線部署的軟件是正確的版本。主要通過重新搭建系統(tǒng)環(huán)境，重建數(shù)據(jù)庫表的形式來開始驗收測試。4. 自動化測試簡介隨著軟件開發(fā)技術和工具的提高，軟件工程和軟件過程實踐的推廣， 軟件測試日益得到重視和專業(yè)化。自動化測試更成為熱門話題。測試自動化就是充分利用市場已有的或自行開發(fā)的測試工具，全部或部分替代手工測試、完成手工測試無法完成的測試任務，以及相關的測試數(shù)據(jù)的記錄和測試報告的生成等。相對于手工測試而言，測試自動化通常具有速度快、執(zhí)行效率高、執(zhí)行過程受外界因素干擾小、測試結果準確等優(yōu)點，缺點是前期投入較大，所以在采用測試自動化之前應當做好相應的評估工作。4.1. 自動化測試的目的自動化測試的目的是通過自動執(zhí)行測試腳本，使測試人員在更短的時間內(nèi)能夠更快地完成更多的軟件測試，并提供以更高的頻率執(zhí)行測試的能力，從而有效降低測試成本、提高測試效率。4.2. 自動化測試的前提自動化測試有幾個前提： 測試人員的編程能力； 重用測試腳本的設計； 人機交互界面的早期凍結； 測試腳本開發(fā)的投入； 測試人員對測試工具的熟練程度。4.3. 自動化測試的優(yōu)勢和局限1,2自動化測試的優(yōu)勢： 對新版本執(zhí)行回歸測試對于產(chǎn)品型的軟件，每發(fā)布一個新的版本，其中大部分功能和界面都和上一個版本相似或完全相同，這部分功能特別適合于自動化測試， 從而可以讓測試達到測試每個特征的目的。 更多更頻繁的測試在回歸測試階段，如果是每天 / 每 2 天都要發(fā)布一個版本供測試人員測試，一個系統(tǒng)的功能點有幾千個上萬個，手工測試將是非常的耗時和繁瑣，而且非常的枯燥，這樣必然會使測試效率低下。完善的自動化測試可以替代測試人員的手工測試。 一致性和可重復性由于每次自動化測試運行的腳本是相同的，所以每次執(zhí)行的測試具有一致性，人是很難做到的。由于自動化測試的一致性，很容易發(fā)現(xiàn)被測軟件的任何改變。自動化測試替代手工測試的困難： 自動化測試的目的在于發(fā)現(xiàn)舊有缺陷，而手工測試的目的在于發(fā)現(xiàn)新缺陷。事實證明新缺陷越多，自動化測試失敗的幾率就越大。發(fā)現(xiàn)更多的新缺陷應該是手工測試的主要目的。測試專家 James Bach 總結得出， 85% 的缺陷靠手工發(fā)現(xiàn)，而自動化測試只能發(fā)現(xiàn) 15 的缺陷。 技術問題、組織問題、腳本維護自動化測試的推行，有很多阻力，比如組織是否重視， 是否成立這樣的測試團隊，是否有這樣的技術水平，對于測試腳本的維護工作量也挺大的，是否值得維護等等問題都必須考慮。4.4. 自動化測試工具對比3,4目前比較主流的自動化功能測試工具主要是Mercury公司的QTP、Winrunner，以及IBM公司的Rational Function Tester。下面對QTP和Rational Function Tester的功能來進行對比：功能指標Rational Function TesterQTP用戶界面與Eclipse集成獨立的GUI腳本語言JavaVBScript測試Web系統(tǒng)支持支持數(shù)據(jù)驅動內(nèi)建數(shù)據(jù)池從Excel中獲得數(shù)據(jù)檢查點支持支持腳本管理工具TestManagerTestDirector其它支持Business Process Testing（BPT）目前，我們測試人員對QTP比較熟悉，沒有使用過Rational Function Tester。就功能上來說，Rational Function Tester 和QTP差別不大。5. 測試工作量估算5.1. 手工測試工作量估算手工測試工作量的估算原則：根據(jù)業(yè)務和功能的復雜程度，以及以往項目的實際數(shù)據(jù)做參考，得出測試完成一遍的工作量。在整個項目測試周期中，測試小組會對整個系統(tǒng)進行兩到三輪的測試（一般是必須的）。根據(jù)以往項目的統(tǒng)計數(shù)據(jù)：每一輪手工測試的工作量是上一輪工作量的50，直到達到臨界值，即完成一輪手工測試的最小時間后，工作量不會再減小。項目統(tǒng)計數(shù)據(jù)還表明：手工測試中，后期的測試工作占到全部測試工作的4050。業(yè)務功能點測試完成的工作量（人日）一級功能二級功能第一輪第二輪第三輪系統(tǒng)管理職責管理2.0 1.0 0.5 用戶管理3.0 1.5 0.8 基礎設置機構類型設置1.0 0.5 0.3 機構設置1.0 0.5 0.3 幣種設置1.0 0.5 0.3 銀行類型設置1.0 0.5 0.3 賬戶用途設置1.5 0.8 0.4 賬戶擴展屬性設置1.0 0.5 0.3 業(yè)務類型設置3.0 1.5 0.8 賬戶管理開戶處理4.0 2.0 1.0 銷戶處理4.0 2.0 1.0 變更處理4.0 2.0 1.0 賬號升級申請3.0 1.5 0.8 凍結與解凍3.0 1.5 0.8 賬戶信息查詢2.0 1.0 0.5 資金清算支出資金申請5.0 2.5 1.3 歸集資金申請5.0 2.5 1.3 資金劃撥5.0 2.5 1.3 資金計劃行項目設置2.0 1.0 0.5 編制計劃2.0 1.0 0.5 審批計劃2.0 1.0 0.5 資金監(jiān)控賬戶當日余額查詢2.0 1.0 0.5 賬戶歷史余額查詢2.0 1.0 0.5 賬戶歷史流水查詢2.0 1.0 0.5 監(jiān)控項設置5.0 2.5 1.3 監(jiān)控報表和提醒3.0 1.5 0.8 銀企接口銀行指令查詢5.0 2.5 1.3 銀行指令維護5.0 2.5 1.3 自動歸集策略設置5.0 2.5 1.3 交易核對5.0 2.5 1.3 審批流審批設置4.0 2.0 1.0 權限轉移4.0 2.0 1.0 每輪合計工作量（人日）：97.5 48.8 24.4 用戶手冊5.0 驗收測試12.0 手工測試合計工作量：187.6人日按照4個測試資源計算，手工測試完成共需消耗187.6/446.9個工作日。與預定計劃的48個工作日的測試周期接近。后期的測試工作占測試工作的45左右。指標數(shù)值估算測試工作量187.6人日測試資源4人估算測試工作日187.6/446.9日計劃測試工作日48日后期測試工作量比例(48.8+24.4+12)/187.6=45對手工測試的工作量估算沒有考慮開發(fā)進度delay的因素。一旦開發(fā)進度delay，則第3輪手工測試將無法完成，只能把優(yōu)先級別較高的功能測試完成。開發(fā)進度delay的原因很大一部分來自需求變更。5.2. 引入自動化測試后工作量估算引入自動化測試工具后，手工測試的主要工作量將主要集中在第一輪測試，而自動化測試腳本也根據(jù)被測試功能和業(yè)務的復雜程度不同而不同。根據(jù)下表的統(tǒng)計數(shù)據(jù)，在自動化測試中采用數(shù)據(jù)驅動的方式，投入產(chǎn)出比比較合適。結構成本收益凈收益No Automation000Recording and Playback8.3112.7Data-driven structure using data pools8.4189.6Framework structure9.8155.2Framework / data-driven (hybrid) structure focusing on views of the application and using data pools11.6197.4 窗體底端根據(jù)業(yè)內(nèi)的統(tǒng)計數(shù)據(jù)，手工測試與自動化測試腳本編寫的工作量比例約為3:7，在不考慮需求變更的情況下，測試腳本的維護工作量為建立腳本工作量的1020，在估算時，取中間值15。引入自動化測試后工作量估算為：業(yè)務功能點測試完成的工作量（人日）一級功能二級功能手工測試自動化腳本腳本維護系統(tǒng)管理職責管理2.0 4.7 0.7 用戶管理3.0 7.0 1.1 基礎設置機構類型設置1.0 2.3 0.4 機構設置1.0 2.3 0.4 幣種設置1.0 2.3 0.4 銀行類型設置1.0 2.3 0.4 賬戶用途設置1.5 3.5 0.5 賬戶擴展屬性設置1.0 2.3 0.4 業(yè)務類型設置3.0 7.0 1.1 賬戶管理開戶處理4.0 9.3 1.4 銷戶處理4.0 9.3 1.4 變更處理4.0 9.3 1.4 賬號升級申請3.0 7.0 1.1 凍結與解凍3.0 7.0 1.1 賬戶信息查詢2.0 4.7 0.7 資金清算支出資金申請5.0 11.7 1.8 歸集資金申請5.0 11.7 1.8 資金劃撥5.0 11.7 1.8 資金計劃行項目設置2.0 4.7 0.7 編制計劃2.0 4.7 0.7 審批計劃2.0 4.7 0.7 資金監(jiān)控賬戶當日余額查詢2.0 4.7 0.7 賬戶歷史余額查詢2.0 4.7 0.7 賬戶歷史流水查詢2.0 4.7 0.7 監(jiān)控項設置5.0 11.7 1.8 監(jiān)控報表和提醒3.0 7.0 1.1 銀企接口銀行指令查詢5.0 11.7 1.8 銀行指令維護5.0 11.7 1.8 自動歸集策略設置5.0 11.7 1.8 交易核對5.0 11.7 1.8 審批流審批設置4.0 9.3 1.4 權限轉移4.0 9.3 1.4 每項合計工作量（人日）：97.5 227.5 34.1 用戶手冊5.0 驗收測試4.0 合計工作量：368.1人日在使用了自動化測試工具以后，驗收測試只需要搭建環(huán)境和數(shù)據(jù)初始化，效率提高了，測試工作量減小到4人日。計劃的測試資源為4個，計劃的測試工作日為48日，故計劃工作量為192人日。在未引入自動化測試工具以前，第二輪和第三輪及驗收測試的工作量合計為(48.8+24.4+12)=85.2人日，引入自動化測試以后，后期的測試工作量為(227.5+34.1+4)=256.6人日。指標公式數(shù)值計劃測試工作日48日計劃測試資源4人計劃測試工作總量48*4192人日替代的手工測試工作量48.8+24.4+1285.2人日估算自動化測試工作量227.5+34.1+4265.6人日估算測試工作總量368.1人日估算測試工作日368.1/492日估算測試周期2006年7月4日2006年11月8日上表的數(shù)據(jù)表明，實施自動化測試，在最好的情況下（不考慮學習曲線和需求變更），估算測試周期為2006年7月4日2006年11月8日，比預定計劃的項目開發(fā)完成時間晚2個月。5.3. 學習曲線、需求變更對工作量的影響根據(jù)項目管理的相關理論，學習曲線和需求變更將分別會增加30的工作量，考慮到對測試工具的了解程度，QTP的學習成本會少一些，估計為10，F(xiàn)unction Tester的學習成本將為30。估算測試工作量為：指標沒有需求變更有需求變更公式數(shù)值公式數(shù)值手工測試估算工作量187.6人日 187.6*(1+30%)243.9人日 使用自動化工具估算測試工作量QTP97.5+265.6*(1+10%)+5394.7人日 97.5*1.3+265.6*1.4+4502.6人日 RFT97.5+265.6*(1+30%)+5447.8日 97.5*1.3+265.6*1.6+5556.7人日 估算測試工作日QTP384.8/498.7日 490/4125.6日 RFT436.1/4111.9日 542.3/4139.2日 估算測試周期QTP2006年7月4日2006年11月17日2006年7月4日2006年12月26日RFT2006年7月4日2006年12月6日2006年7月4日2007年1月15日上表的估