CRM客戶關(guān)系管理系統(tǒng)測試計劃

1、CRM(客戶關(guān)系管理系統(tǒng))測試計劃文檔修訂記錄版本號變化狀態(tài)簡要說明日期變更人批準(zhǔn)日期批準(zhǔn)人V1.0C變化狀態(tài)：C=創(chuàng)立，A=增加，M=修改，D=刪除 HYPERLINK l _TOC_250045 概述4 HYPERLINK l _TOC_250044 目的4 HYPERLINK l _TOC_250043 背景介紹4 HYPERLINK l _TOC_250042 測試計劃讀者圍4 HYPERLINK l _TOC_250041 測試基本容4 HYPERLINK l _TOC_250040 測試環(huán)境4 HYPERLINK l _TOC_250039 測試工具5 HYPERLINK l _T

2、OC_250038 測試圍5 HYPERLINK l _TOC_250037 測試對象5 HYPERLINK l _TOC_250036 需要測試的特性5 HYPERLINK l _TOC_250035 不需要測試的特性6 HYPERLINK l _TOC_250034 測試用例設(shè)計6 HYPERLINK l _TOC_250033 測試用例相關(guān)約定6 HYPERLINK l _TOC_250032 衡量測試用例設(shè)計的質(zhì)量標(biāo)準(zhǔn)7 HYPERLINK l _TOC_250031 系統(tǒng)性7 HYPERLINK l _TOC_250030 連貫性7 HYPERLINK l _TOC_250029 相

3、關(guān)性7 HYPERLINK l _TOC_250028 全面性7 HYPERLINK l _TOC_250027 3.2.5.正確性8 HYPERLINK l _TOC_250026 符合正常業(yè)務(wù)慣例8 HYPERLINK l _TOC_250025 容錯性（健壯性）8 HYPERLINK l _TOC_250024 實施計劃8 HYPERLINK l _TOC_250023 測試進(jìn)度安排8 HYPERLINK l _TOC_250022 測試人員安排以及職責(zé)9輸出要求10 HYPERLINK l _TOC_250021 測試方法10 HYPERLINK l _TOC_250020 黑盒測試方

4、法10 HYPERLINK l _TOC_250019 等價類劃分法10 HYPERLINK l _TOC_250018 邊界值分析法10 HYPERLINK l _TOC_250017 因果圖法11 HYPERLINK l _TOC_250016 功能圖法11 HYPERLINK l _TOC_250015 錯誤推測法11 HYPERLINK l _TOC_250014 正交實驗設(shè)計方法11 HYPERLINK l _TOC_250013 接口間測試12 HYPERLINK l _TOC_250012 數(shù)據(jù)庫測試12 HYPERLINK l _TOC_250011 可理解（操作）性12 HY

5、PERLINK l _TOC_250010 可移植性12 HYPERLINK l _TOC_250009 軟件測試的一些準(zhǔn)則12 HYPERLINK l _TOC_250008 測試的各項標(biāo)準(zhǔn)13 HYPERLINK l _TOC_250007 測試項通/失敗的標(biāo)準(zhǔn)13 HYPERLINK l _TOC_250006 中斷測試和恢復(fù)測試的判斷標(biāo)準(zhǔn)13 HYPERLINK l _TOC_250005 缺陷跟蹤14 HYPERLINK l _TOC_250004 缺陷類型14 HYPERLINK l _TOC_250003 缺陷管理流程圖14 HYPERLINK l _TOC_250002 缺陷嚴(yán)

6、重程度和優(yōu)先等級16 HYPERLINK l _TOC_250001 測試報告18 HYPERLINK l _TOC_250000 風(fēng)險及應(yīng)急措施18概述目的CRM 系統(tǒng)“CRM 系統(tǒng)-系統(tǒng)測試計劃”文檔有助于實現(xiàn)以下目標(biāo)：CRM列出測試用例編寫的相關(guān)約定CRMCRM文件中所規(guī)定的容可以作為對測試過程完備性的對照檢查表，將會提高測試過程的每個階段的能見度，極提高測試工作的可管理性。背景介紹客戶關(guān)系管理系統(tǒng)是一種嶄新的、國際領(lǐng)先的、以客戶為中心的企業(yè)管理理論、商業(yè)運(yùn)作模式、也是一種以信息技術(shù)為手段、有效提高企業(yè)受益、客戶滿意度、雇員生產(chǎn)力的具體軟件和實現(xiàn)方法，是一套集理念、組織、流程、技術(shù)為一體

7、的整體解決方案，是一種旨在改善企業(yè)與客戶之間關(guān)系的新型管理機(jī)制。企業(yè)實施CRM 戰(zhàn)略本質(zhì)目標(biāo)是與那些有價值的客戶建立穩(wěn)定的長期雙贏關(guān)系，進(jìn)而為企業(yè)在幾樓的市場競爭中贏得優(yōu)勢。測試計劃讀者圍測試工程師，開發(fā)經(jīng)理，項目經(jīng)理，實施負(fù)責(zé)人測試基本容測試環(huán)境軟件環(huán)境（相關(guān)軟件、操作系統(tǒng)等）軟件環(huán)境（相關(guān)軟件、操作系統(tǒng)等）操作系統(tǒng)：Win7硬件環(huán)境CPU 處理器： i3-3220 3.3 GHz 存：4G系統(tǒng)類型：64 位操作系統(tǒng)軟件環(huán)境：CRM測試工具用途用途工具生產(chǎn)廠商/自產(chǎn)版本備注測試管理ALMHP11.5被測系統(tǒng)報告以及測試用例CRMWordN/AMicrosoft1.02007測試圍測試對象被測

8、系統(tǒng)為 CRM1.0 版本，使用 C+開發(fā)的。需要測試的特性添加線索查看線索搜索線索不需要測試的特性本次系統(tǒng)測試不需要包含的容：(2.3.2)之外的所有業(yè)務(wù)流程被刪除的功能被外包的功能測試用例設(shè)計測試用例相關(guān)約定在設(shè)計測試用例時，你需要定義程序的操作來確保程序的各方面都被測試到。為了確保清楚，準(zhǔn)確的捕獲到了完成一個操作所需要的所有行為，要滿足下面條件：全性測試、故障轉(zhuǎn)移測試、負(fù)載測試等。述待測試的功能特性或非功能特性。在組織和分類上，測試用例層次清楚、結(jié)構(gòu)合理。測試用例的層次與產(chǎn)品特性的結(jié)構(gòu)/層次相一致，或者與測試的目標(biāo)/子目標(biāo)的分類/層次相一致，并具有合理的優(yōu)先級或執(zhí)行順序。(User sc

9、enario)，也就是說果圖等方式列出來，找到相對應(yīng)的測試用例。通過工具測試，哪些方面不得不用手工測試，對不同手段的測試用例區(qū)別對待。樣的例外情況，如邊界條件、不正確的操作、錯誤的數(shù)據(jù)輸入等。沒有重復(fù)、冗余的測試用例，滿足相應(yīng)的行業(yè)標(biāo)準(zhǔn)等。衡量測試用例設(shè)計的質(zhì)量標(biāo)準(zhǔn)系統(tǒng)性它們之間的關(guān)系；對于模塊業(yè)務(wù)流程要能夠說明清楚子系統(tǒng)部功能、重要功能點以及它們之間的關(guān)系；連貫性系統(tǒng)之間是否有正確的接口；如果是依靠頁面，頁面是否正確；接口是否連貫相關(guān)性否有相應(yīng)變化，和后臺數(shù)據(jù)庫之間是否匹配當(dāng)某個產(chǎn)品增加某個功能時，其它相關(guān)產(chǎn)品是否有相應(yīng)措施全面性應(yīng)盡可能覆蓋程序的各種路徑應(yīng)盡可能覆蓋系統(tǒng)的各個業(yè)務(wù)應(yīng)考慮存在

10、跨年、跨月的數(shù)據(jù)大量數(shù)據(jù)并發(fā)測試的準(zhǔn)備系統(tǒng)中各功能、業(yè)務(wù)的異常情況3.2.5.正確性輸入用戶實際數(shù)據(jù)以驗證系統(tǒng)是否滿足需求規(guī)格說明書的需求。測試用例中的測試點應(yīng)保證至少覆蓋需求規(guī)格說明書中的各項功能。符合正常業(yè)務(wù)慣例測試數(shù)據(jù)應(yīng)符合用戶實際工作業(yè)務(wù)流程兼顧各種業(yè)務(wù)變化的可能要符合當(dāng)前業(yè)務(wù)行業(yè)法律，法規(guī)。容錯性（健壯性）程序能夠接收正確數(shù)據(jù)輸入并且產(chǎn)生正確（預(yù)期）的輸出，輸入非法數(shù)據(jù)（不符合要求的數(shù)據(jù)、溢出數(shù)據(jù)等），程序應(yīng)能給出提示并進(jìn)行相應(yīng)處理。保清楚，準(zhǔn)確的捕獲到了完成一個操作所需要的所有行為，要滿足下面條件：每一步都用主動語態(tài)書寫，使用主動語態(tài)的好處是使得測試執(zhí)行人員實施計劃測試進(jìn)度安排里程

11、碑執(zhí)行者里程碑執(zhí)行者開始時間完成時間天數(shù)（天）需求分析CRM 系統(tǒng)業(yè)務(wù)分析編寫需求并導(dǎo)入 ALM編寫需求并導(dǎo)入 ALM測試用例設(shè)計設(shè)計測試用例用例評審ALM（ALM）測試執(zhí)行ALM 中創(chuàng)建測試集將測試計劃中案例添加到測試集第一輪測試執(zhí)行并提交缺陷以及測試報告第二輪測試執(zhí)行并提交缺陷以及測試報告項目總結(jié)報告系統(tǒng)測試的總結(jié)人員角色職責(zé)、任務(wù)編寫項目計劃，審核測試計劃，審批測試案例，項目進(jìn)人員角色職責(zé)、任務(wù)編寫項目計劃，審核測試計劃，審批測試案例，項目進(jìn)度追蹤管理，評估并防控風(fēng)險及問題的發(fā)生備注PMPA編寫測試計劃，評審案例，協(xié)助將案例導(dǎo)入ALM，管理測試過程，生成 QC 測試報告系統(tǒng)測試Owner

12、需求分析，設(shè)計測試用例，導(dǎo)入測試用例，執(zhí)行測試，記錄測試執(zhí)行日志，缺陷追蹤ALM OwnerCRM 業(yè)務(wù)人員SCM輸出要求測試計劃測試用例測試數(shù)據(jù)測試缺陷報告測試總結(jié)報告ALM Admin，管理 ALM 項目，用戶，完成所有和ALMPM 和 系統(tǒng)測試 OwnerALM熟練的掌握 CRM ， 安裝， CRM 系統(tǒng)詳細(xì)的需求（PM）負(fù)責(zé) CRM 環(huán)境，項目文檔的管理測試方法本次測試是 CRM 的系統(tǒng)測試，確保：黑盒測試方法等價類劃分法將所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個等價類。邊界值分析法指對輸入的邊界條件進(jìn)行分析，設(shè)計出針對邊界值的測試用例。因果圖法就是利用圖解法分析軟件輸入(原因

13、)和輸出條件(結(jié)果)之間的關(guān)系，以設(shè)計測試用例的方法。因果圖法適合于檢查程序輸入條件的多種情況的組合，并最終生成判定表，來獲得對應(yīng)的測試用例。功能圖法功能圖是描述程序狀態(tài)變化、轉(zhuǎn)移的過程，因為軟件運(yùn)行或操作的過程可以看作是其狀態(tài)不斷發(fā)生變化的過程。測試用例的設(shè)計就是如何覆蓋所有軟件表現(xiàn)出來的狀態(tài)，即在滿足輸入/輸出的一組條件下，軟件運(yùn)行是一系列有次序的、受控制的狀態(tài)變化過程。錯誤推測法推測法主要依賴經(jīng)驗、直覺來作出簡單的判斷甚至是猜測，給出可能存在缺陷的條件、場景等，在找到缺陷后，設(shè)計出相應(yīng)的測試用例。正交實驗設(shè)計方法主要步驟是：獨(dú)立的基本功能。取值可以看作水平，多個取值就存在多個水平。權(quán)值是

14、依據(jù)各因素的影響圍、發(fā)生的頻率和質(zhì)量的需求來確定的。加權(quán)篩選，生成因素分析表。可忽略的處理因素和不可混雜的原則，有交互作用的組合優(yōu)先安排。效率高。接口間測試測試各個模塊相互間的協(xié)調(diào)和通信情況，數(shù)據(jù)輸入輸出的一致性和正確性。數(shù)據(jù)庫測試依據(jù)數(shù)據(jù)庫設(shè)計規(guī)對軟件系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)、數(shù)據(jù)表及其之間的數(shù)據(jù)調(diào)用關(guān)系進(jìn)行測試?？衫斫猓ú僮鳎┬岳斫夂褪褂迷撓到y(tǒng)的難易程度（界面友好性）?？梢浦残栽诓煌僮飨到y(tǒng)及硬件配置情況下的運(yùn)行性。軟件測試的一些準(zhǔn)則軟件測試從不同的角度出發(fā)會派生出兩種不同的測試原則，從用戶的角度出發(fā)，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產(chǎn)品， 從開發(fā)者的角

15、度出發(fā)，就是希望測試能表明軟件產(chǎn)品不存在錯誤，已經(jīng)正確地實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。為了達(dá)到上述的原則，那么需要注意以下幾點： 1程序員應(yīng)該避免檢查自己的程序，測試工作應(yīng)該由獨(dú)立的專業(yè)的軟件測試機(jī)構(gòu)來完。設(shè)計測試用例時應(yīng)該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況 要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。 4對測試錯誤結(jié)果一定要有一個確認(rèn)的過程，一般有AB 來 確 認(rèn) ， 嚴(yán) 重 的 錯 誤 可 以 召 開 評 審 會 進(jìn) 行 討 論 和 分 析 。6制定嚴(yán)格的測試計劃，并把測試時間安排的盡量寬松，不要希望在極短的時間完成一個高水平的測試。 7

16、回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象 并 不 少 見 。 8妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。測試的各項標(biāo)準(zhǔn)測試項通過/失敗的標(biāo)準(zhǔn)一般有“基于測試用例”和“基于缺陷密度”兩種評比準(zhǔn)則，在這里我們采用前者。準(zhǔn)則如下：95；90；3備選通過辦法：根據(jù)實際情況由軟件開發(fā)部門的經(jīng)理、項目經(jīng)理和測試負(fù)責(zé)人等共同討論確定本階段是否結(jié)束。中斷測試和恢復(fù)測試的判斷標(biāo)準(zhǔn)10010當(dāng)代碼不全時停止測試直至代碼全面恢復(fù)測試41/211/3缺陷跟蹤缺陷類型本次測試過程中缺陷的管理將在 ALM 中進(jìn)行，缺陷大致包含如下狀態(tài)：缺 陷 類 型

17、冗余代碼多兼 容 性 差 可操作性差界面不友好具體含義代碼冗余，即是編程時不必要的代碼段。軟件從某一環(huán)境轉(zhuǎn)移到另一環(huán)境后不能正常運(yùn)行軟件難以理解,不容易使用,運(yùn)行緩慢。最終用戶會認(rèn)為界面不好。與需求不一致軟件沒有實現(xiàn)產(chǎn)品規(guī)格說明所要求的功能模; 軟件實現(xiàn)了產(chǎn)品規(guī)格說明沒有提到的功能模塊可擴(kuò)展性差軟件在原有的功能上不容易實現(xiàn)新增其他新的功能。缺陷管理流程圖缺陷的狀態(tài)如上所示，通常缺陷的管理流程如下圖所示：否是否是缺陷嚴(yán)重程度和優(yōu)先等級缺陷嚴(yán)重程度：嚴(yán)重級別使用不方便的問題 嚴(yán)重程度描述1-Low1)容易給用戶誤解和歧義的提示；界面需要改進(jìn)的；對有疑慮的文檔，提出修改建議界面非關(guān)鍵信息錯誤微小的錯

18、誤，不會影響系統(tǒng)的功能風(fēng)格不統(tǒng)一，包括相近流程的界面布局相異，相同的問題點提示信息相異，但對用戶的使用方法和使用習(xí)慣不造成影響（需求中明確的風(fēng)格要求除外）如幫助、提示信息不完整，有錯誤，但不影響用戶使用。不正確的，但有使系統(tǒng)使用起來不太方便的錯誤：系統(tǒng)的提示語不明確，不簡明2-Medium滾動條無效可編輯區(qū)和不可編輯區(qū)不明顯光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯誤上下翻頁，首尾頁定位錯誤界面不一致，或界面不正確日期或時間初始值錯誤（起止日期、時間沒有限定）按鈕或標(biāo)簽上有拼寫錯誤的單詞、不正確的大小寫該問題是一個不準(zhǔn)確或容易誤解的行為，但不會引起下面（3、4、5 別）列出的問題功能缺失或錯誤，界面

19、關(guān)鍵信息錯誤該問題增加了安裝、測試或用戶操作的復(fù)雜度或成本3-High該問題輕微降低了系統(tǒng)的性能，但系統(tǒng)仍然能工作4-Very High部署文檔描述不明確，增加部署難度不正確的，但不會影響系統(tǒng)穩(wěn)定性的：過程調(diào)用或其它腳本錯誤系統(tǒng)刷新錯誤產(chǎn)生錯誤結(jié)果，如計算結(jié)果錯誤等點擊后無作用，對數(shù)據(jù)庫的操作不能正確實現(xiàn)編碼時數(shù)據(jù)類型、長度定義錯誤的對用戶的使用有操作順序上的限制雖然正確性不受影響，但系統(tǒng)性能和響應(yīng)時間受到影響導(dǎo)致系統(tǒng)崩潰、數(shù)據(jù)丟失、嚴(yán)重系統(tǒng)資源泄露，關(guān)鍵功能缺失或錯誤該問題會嚴(yán)重降低系統(tǒng)的性能業(yè)務(wù)流程不正確需現(xiàn)不完整，設(shè)計實現(xiàn)上的缺陷，且無替代方法，如：設(shè)計了3 條路山，但是實際只有一條可以

20、上該問題不符合需求規(guī)格書配置項設(shè)計錯誤，無常配置，或配置后，測試中出現(xiàn)與配置相關(guān)的錯誤部署文檔錯誤，導(dǎo)致部署失敗與其它網(wǎng)元的接口，調(diào)用或提供錯誤申報信息提交錯誤，可繼續(xù)測試（如聯(lián)網(wǎng)申報、分類錯誤、亂碼、違禁信息），但影響應(yīng)用后續(xù)審核上線；必須馬上解決的，根據(jù)情況可以要求項目組立刻發(fā)布新版本，阻礙流程、系統(tǒng)崩潰導(dǎo)致開發(fā)或測試無法進(jìn)行或程序無常運(yùn)行的缺陷。提交物缺失，導(dǎo)致測試、部署和維護(hù)無常進(jìn)行5-Urgent需求未實現(xiàn)正常的操作，導(dǎo)致系統(tǒng)（進(jìn)程）崩潰系統(tǒng)不能啟動或啟動后無常工作系統(tǒng)（進(jìn)程）經(jīng)常自動崩潰（至少一天一次）缺陷的優(yōu)先級：優(yōu)先級優(yōu)先級優(yōu)先級描述1-Low1-Low可能會修復(fù)，但是也能不修復(fù)2-Medium如果時間允許應(yīng)該修復(fù)3-High在產(chǎn)品發(fā)布前必須修復(fù)4-V