CRM系統測試-測試計劃/CRM系統測試-測試計劃版本：1.0XX組12/04/20131.概述31.1目的31.2背景介紹31.3測試計劃讀者范圍32.測試基本內容42.1測試環境42.2測試工具42.3測試范圍42.3.1測試對象42.3.2需要測試的特性4不需要測試的特性53.測試用例設計53.1測試用例相關約定53.2衡量測試用例設計的質量標準54.實施計劃64.1測試進度安排64.2測試人員安排以及職責74.3輸出要求75測試方法76.測試的各項標準86.1測試項通過/失敗的標準86.2中斷測試和恢復測試的判斷標準87.缺陷跟蹤97.1缺陷類型97.2缺陷管理流程圖97.3缺陷嚴重程度和優先等級107.測試報告128.風險及應急措施121.概述1.1目的CRM系統"CRM系統-系統測試計劃"文檔有助于實現以下目標：確定CRM系統的測試環境、測試工具、測試范圍列出測試用例編寫的相關約定確定所需資源并對CRM系統測試的工具進行估計列出CRM系統測試項目可交付元素文件中所規定的內容可以作為對測試過程完備性的對照檢查表,將會提高測試過程的每個階段的能見度,極大地提高測試工作的可管理性。1.2背景介紹客戶關系管理系統是一種嶄新的、國際領先的、以客戶為中心的企業管理理論、商業運作模式、也是一種以信息技術為手段、有效提高企業受益、客戶滿意度、雇員生產力的具體軟件和實現方法,是一套集理念、組織、流程、技術為一體的整體解決方案,是一種旨在改善企業與客戶之間關系的新型管理機制。企業實施CRM戰略本質目標是與那些有價值的客戶建立穩定的長期雙贏關系,進而為企業在幾樓的市場競爭中贏得優勢。1.3測試計劃讀者范圍測試工程師,開發經理,項目經理,實施負責人2.測試基本內容2.1測試環境軟件環境〔相關軟件、操作系統等操作系統：Win7硬件環境處理器：QEMUVirtualCPUVERSION2.29GHz內存：4G系統類型：64位操作系統軟件環境：CRM2.2測試工具用途工具生產廠商/自產版本備注測試管理ALMHP11.52被測系統CRMN/A1.0報告以及測試用例Excel/WordMicrosoft20132.3測試范圍2.3.1測試對象被測系統為CRM1.0版本,使用C++開發的。2.3.2需要測試的特性本次系統測試要求包含以下業務流程：添加線索導入與導出線索查看線索編輯線索刪除線索搜索線索2.3.3不需要測試的特性本次系統測試不需要包含的內容：上述業務流程<2.3.2>之外的所有業務流程被刪除的功能被外包的功能3.測試用例設計3.1測試用例相關約定在設計測試用例時,你需要定義程序的操作來確保程序的各方面都被測試到。為了確保清楚,準確的捕獲到了完成一個操作所需要的所有行為,要滿足下面條件：測試用例的目標清楚,并能滿足軟件質量的各個方面,包括功能測試、性能測試、安全性測試、故障轉移測試、負載測試等。設計思路正確、清晰。例如,通過序列圖、狀態圖、工作流程圖、數據流程圖等來描述待測試的功能特性或非功能特性。在組織和分類上,測試用例層次清楚、結構合理。測試用例的層次與產品特性的結構/層次相一致,或者與測試的目標/子目標的分類/層次相一致,并具有合理的優先級或執行順序。測試用例覆蓋所有測試點、覆蓋所有已知的用戶使用場景<Userscenario>,也就是說每個測試點都有相應數量的測試用例來覆蓋,而且將各種用戶使用場景通過矩陣或因果圖等方式列出來,找到相對應的測試用例。測試手段的區別對待。在設計測試用例時,就要全面考量測試的手段,哪些方面可以通過工具測試,哪些方面不得不用手工測試,對不同手段的測試用例區別對待。有充分的負面測試。作為測試用例,不僅要測試正確的輸入和操作,還要測試各種各樣的例外情況,如邊界條件、不正確的操作、錯誤的數據輸入等。沒有重復、冗余的測試用例,滿足相應的行業標準等。衡量測試用例設計的質量標準3.2.1系統性對于系統業務流程要能夠完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關系；對于模塊業務流程要能夠說明清楚子系統內部功能、重要功能點以及它們之間的關系；3.2.2連貫性對于系統業務流程來說,各個子系統之間是如何連接在一起,如果需要接口,各個子系統之間是否有正確的接口；如果是依靠頁面鏈接,頁面鏈接是否正確；對于模塊業務流程來說,同級模塊以及上下級模塊是如何構成一個子系統,其內部功能接口是否連貫3.2.3相關性考慮各個產品之間的相關性,當某個產品某個頁面的字段發生增刪改時,其它產品是否有相應變化,和后臺數據庫之間是否匹配當某個產品增加某個功能時,其它相關產品是否有相應措施3.2.4全面性應盡可能覆蓋程序的各種路徑應盡可能覆蓋系統的各個業務應考慮存在跨年、跨月的數據大量數據并發測試的準備系統中各功能、業務的異常情況3.2.5.正確性輸入用戶實際數據以驗證系統是否滿足需求規格說明書的需求。測試用例中的測試點應保證至少覆蓋需求規格說明書中的各項功能。3.2.6符合正常業務慣例測試數據應符合用戶實際工作業務流程兼顧各種業務變化的可能要符合當前業務行業法律,法規。3.2.7容錯性〔健壯性程序能夠接收正確數據輸入并且產生正確〔預期的輸出,輸入非法數據〔非法類型、不符合要求的數據、溢出數據等,程序應能給出提示并進行相應處理。在設計測試用例時,你需要定義程序的操作來確保程序的各方面都被測試到。為了確保清楚,準確的捕獲到了完成一個操作所需要的所有行為,要滿足下面條件：每一步都用主動語態書寫,使用主動語態的好處是使得測試執行人員4.實施計劃4.1測試進度安排本次測試的時間安排如下：里程碑執行者開始時間完成時間天數〔天需求分析楊斌12/1912/202CRM系統業務分析張慧媛12/2112/222編寫需求并導入ALM孟盼盼12/2312/231測試用例設計李貝貝12/2412/263設計測試用例張愛美12/2412/263用例評審小組12/2612/261導入ALM〔也可以直接在ALM錄入孟盼盼12/2612/261測試執行李貝貝王鵬12/2712/293ALM中創建測試集孟盼盼12/2712/293將測試計劃中案例添加到測試集孟盼盼12/2712/293第一輪測試執行并提交缺陷以及測試報告王鵬12/3012/301第二輪測試執行并提交缺陷以及測試報告任福運12/3112/311項目總結報告孫彥林12/3112/311系統測試的總結張愛美12/3112/3114.2測試人員安排以及職責人員角色職責、任務備注楊斌PM編寫項目計劃,審核測試計劃,審批測試案例,項目進度追蹤管理,評估并防控風險及問題的發生孫彥林PA編寫測試計劃,評審案例,協助將案例導入ALM,管理測試過程,生成QC測試報告李貝貝張愛美系統測試Owner需求分析,設計測試用例,導入測試用例,執行測試,記錄測試執行日志,缺陷追蹤夢盼盼王鵬ALMOwnerALMAdmin,管理ALM項目,用戶,完成所有和ALM相關的工作；配合PM和系統測試Owner完成所有在ALM的工作。張慧媛CRM業務人員熟練的掌握CRM,安裝,CRM系統詳細的需求〔PM任福運SCM負責CRM環境,項目文檔的管理4.3輸出要求《測試計劃》《測試用例》《測試數據》《測試缺陷報告》《測試總結報告》5測試方法本次測試是CRM的系統測試,確保：5.1黑盒測試方法5.1.1等價類劃分法將所有可能的輸入數據〔有效的和無效的劃分成若干個等價類。5.1.2邊界值分析法指對輸入的邊界條件進行分析,設計出針對邊界值的測試用例。5.1.3因果圖法就是利用圖解法分析軟件輸入<原因>和輸出條件<結果>之間的關系,以設計測試用例的方法。因果圖法適合于檢查程序輸入條件的多種情況的組合,并最終生成判定表,來獲得對應的測試用例。5.1.4功能圖法功能圖是描述程序狀態變化、轉移的過程,因為軟件運行或操作的過程可以看作是其狀態不斷發生變化的過程。測試用例的設計就是如何覆蓋所有軟件表現出來的狀態,即在滿足輸入/輸出的一組條件下,軟件運行是一系列有次序的、受控制的狀態變化過程。5.1.5錯誤推測法推測法主要依賴經驗、直覺來作出簡單的判斷甚至是猜測,給出可能存在缺陷的條件、場景等,在找到缺陷后,設計出相應的測試用例。5.1.6正交實驗設計方法主要步驟是：對軟件需求規格說明中的功能要求進行劃分<層層分解與展開>,分解成具體的、相對獨立的基本功能。根據基本功能的質量需求,找出影響其功能實現的操作對象和外部因素,每個因素的取值可以看作水平,多個取值就存在多個水平。確定待測試軟件中所有因素及其權值,這是測試用例設計的關鍵,確保全面、準確。權值是依據各因素的影響范圍、發生的頻率和質量的需求來確定的。加權篩選,生成因素分析表。利用正交表構造測試數據集,正交表的每一行,就是一條測試用例。考慮交互作用不可忽略的處理因素和不可混雜的原則,有交互作用的組合優先安排。利用正交實驗設計方法設計測試用例,可控制生成的測試用例數量,覆蓋率高且測試效率高。5.1.7接口間測試測試各個模塊相互間的協調和通信情況,數據輸入輸出的一致性和正確性。5.1.8數據庫測試依據數據庫設計規范對軟件系統的數據庫結構、數據表及其之間的數據調用關系進行測試。5.1.9可理解〔操作性理解和使用該系統的難易程度〔界面友好性。5.1.10可移植性在不同操作系統及硬件配置情況下的運行性。5.2軟件測試的一些準則軟件測試從不同的角度出發會派生出兩種不同的測試原則,從用戶的角度出發,就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷,從而考慮是否可以接受該產品,從開發者的角度出發,就是希望測試能表明軟件產品不存在錯誤,已經正確地實現了用戶的需求,確立人們對軟件質量的信心。為了達到上述的原則,那么需要注意以下幾點：

1．應當把"盡早和不斷的測試"作為開發者的座右銘

2．程序員應該避免檢查自己的程序,測試工作應該由獨立的專業的軟件測試機構來完。

3．設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件,特殊情況要制造極端狀態和意外狀態,比如網絡異常中斷、電源斷電等情況。

4．一定要注意測試中的錯誤集中發生現象,這和程序員的編程水平和習慣有很大的關系。

5．對測試錯誤結果一定要有一個確認的過程,一般有A測試出來的錯誤,一定要有一個B來確認,嚴重的錯誤可以召開評審會進行討論和分析。

6．制定嚴格的測試計劃,并把測試時間安排的盡量寬松,不要希望在極短的時間內完成一個高水平的測試。

7．回歸測試的關聯性一定要引起充分的注意,修改一個錯誤而引起更多的錯誤出現的現象并不少見。

8．妥善保存一切測試過程文檔,意義是不言而喻的,測試的重現性往往要靠測試文檔。6.測試的各項標準6.1測試項通過/失敗的標準一般有"基于測試用例"和"基于缺陷密度"兩種評比準則,在這里我們采用前者。準則如下：功能性測試用例通過率達到95％；非功能性測試用例通過率達到90％；沒有高于優先級3以上的缺陷。備選通過辦法：根據實際情況由軟件開發部門的經理、項目經理和測試負責人等共同討論確定本階段是否結束。6.2中斷測試和恢復測試的判斷標準缺陷數量大于100時中斷測試直至缺陷修復到10時恢復當代碼不全時停止測試直至代碼全面恢復測試當缺陷嚴重程度為4的個數超過總體缺陷的1/2時停止測試當缺陷優先級為1的個數超過總體缺陷1/3時停止測試7.缺陷跟蹤7.1缺陷類型本次測試過程中缺陷的管理將在ALM中進行,缺陷大致包含如下狀態：缺陷類型具體含義冗余代碼多代碼冗余,即是編程時不必要的代碼段。兼容性差軟件從某一環境轉移到另一環境后不能正常運行可操作性差軟件難以理解,不容易使用,運行緩慢。界面不友好最終用戶會認為界面不好。與需求不一致軟件沒有實現產品規格說明所要求的功能模塊;軟件實現了產品規格說明沒有提到的功能模塊。可擴展性差軟件在原有的功能上不容易實現新增其他新的功能。7.2缺陷管理流程圖缺陷的狀態如上所示,通常缺陷的管理流程如下圖所示：7.3缺陷嚴重程度和優先等級缺陷嚴重程度：嚴重級別嚴重程度描述1-Low使用不方便的問題對軟件的改進建議：容易給用戶誤解和歧義的提示；界面需要改進的；對有疑慮的文檔,提出修改建議2-Medium界面非關鍵信息錯誤?微小的錯誤,不會影響系統的功能?風格不統一,包括相近流程的界面布局相異,相同的問題點提示信息相異,但對用戶的使用方法和使用習慣不造成影響〔需求中明確的風格要求除外如幫助、提示信息不完整,有錯誤,但不影響用戶使用。不正確的,但有使系統使用起來不太方便的錯誤：系統的提示語不明確,不簡明滾動條無效可編輯區和不可編輯區不明顯光標跳轉設置不好,鼠標〔光標定位錯誤上下翻頁,首尾頁定位錯誤界面不一致,或界面不正確日期或時間初始值錯誤〔起止日期、時間沒有限定按鈕或標簽上有拼寫錯誤的單詞、不正確的大小寫該問題是一個不準確或容易誤解的行為,但不會引起下面〔3、4、5級別列出的問題3-High功能缺失或錯誤,界面關鍵信息錯誤?該問題增加了安裝、測試或用戶操作的復雜度或成本?該問題輕微降低了系統的性能,但系統仍然能工作?非核心功能實現不完整或不正確,但對系統影響很小,系統仍然能工作?業務流程對應的功能未實現,但是有替代方法解決,不影響實際的使用?部署文檔描述不明確,增加部署難度不正確的,但不會影響系統穩定性的：過程調用或其它腳本錯誤系統刷新錯誤產生錯誤結果,如計算結果錯誤等功能的實現有問題。如在系統實現的界面上,一些可接受輸入的控件點擊后無作用,對數據庫的操作不能正確實現編碼時數據類型、長度定義錯誤的對用戶的使用有操作順序上的限制雖然正確性不受影響,但系統性能和響應時間受到影響4-VeryHigh導致系統崩潰、數據丟失、嚴重系統資源泄露,關鍵功能缺失或錯誤?該問題會嚴重降低系統的性能?業務流程不正確?需求實現不完整,設計實現上的缺陷,且無替代方法,如：設計了3條路上山,但是實際只有一條可以上?該問題不符合需求規格書?配置項設計錯誤,無法正常配置,或配置后,測試中出現與配置相關的錯誤?部署文檔錯誤,導致部署失敗?與其它網元的接口,調用或提供錯誤?申報信息提交錯誤,可繼續測試〔如聯網申報、分類錯誤、亂碼、違禁信息,但影響應用后續審核上線；5-Urgent必須馬上解決的,根據情況可以要求項目組立刻發布新版本,阻礙流程、系統崩潰導致開發或測試無法進行或程序無法正常運行的缺陷。?提交物缺失,導致測試、部署和維護無法正常進行?需求未實現?正常的操作,導致系統〔進程崩潰?系統不能啟動或啟動后無法正常工作?系統〔進程經常自動崩潰〔至少一天一次缺陷的優先級：優先級優先級描述1-Low可能會修復,但是也能不修復2-Medium如果時間允許應該修復3-High在產品發布前必須修復4-VeryHigh盡快修復5-Urgent立即修復,停止進一步測試7