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

《CRM客戶關(guān)系管理系統(tǒng)測試計(jì)劃.doc》由會員分享，可在線閱讀，更多相關(guān)《CRM客戶關(guān)系管理系統(tǒng)測試計(jì)劃.doc（17頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

______________________________________________________________________________________________________________ CRM(客戶關(guān)系管理系統(tǒng)) 測試計(jì)劃 文檔修訂記錄 版本號 變化狀態(tài) 簡要說明 日期 變更人 批準(zhǔn)日期 批準(zhǔn)人 V1.0 C 變化狀態(tài)：C=創(chuàng)立，A=增加，M=修改，D=刪除 1. 概述 4 1.1 目的 4 1.2 背景介紹 4 1.3 測試計(jì)劃讀者范圍 4 2. 測試基本內(nèi)容 4 2.1測試環(huán)境 4 2.2測試工具 5 2.3測試范圍 5 2.3.1 測試對象 5 2.3.2需要測試的特性 5 2.3.3不需要測試的特性 6 3. 測試用例設(shè)計(jì) 6 3.1 測試用例相關(guān)約定 6 3.2 衡量測試用例設(shè)計(jì)的質(zhì)量標(biāo)準(zhǔn) 7 3.2.1系統(tǒng)性 7 3.2.2連貫性 7 3.2.3相關(guān)性 7 3.2.4全面性 7 3.2.5.正確性 8 3.2.6符合正常業(yè)務(wù)慣例 8 3.2.7容錯性（健壯性） 8 4.實(shí)施計(jì)劃 8 4.1 測試進(jìn)度安排 8 4.2 測試人員安排以及職責(zé) 9 4.3 輸出要求 10 5 測試方法 10 5.1黑盒測試方法 10 5.1.1等價(jià)類劃分法 10 5.1.2邊界值分析法 10 5.1.3因果圖法 11 5.1.4功能圖法 11 5.1.5錯誤推測法 11 5.1.6正交實(shí)驗(yàn)設(shè)計(jì)方法 11 5.1.7接口間測試 12 5.1.8數(shù)據(jù)庫測試 12 5.1.9可理解（操作）性 12 5.1.10可移植性 12 5.2軟件測試的一些準(zhǔn)則 12 6. 測試的各項(xiàng)標(biāo)準(zhǔn) 13 6.1 測試項(xiàng)通過/失敗的標(biāo)準(zhǔn) 13 6.2 中斷測試和恢復(fù)測試的判斷標(biāo)準(zhǔn) 13 7. 缺陷跟蹤 14 7.1 缺陷類型 14 7.2 缺陷管理流程圖 14 7.3 缺陷嚴(yán)重程度和優(yōu)先等級 16 7. 測試報(bào)告 18 8. 風(fēng)險(xiǎn)及應(yīng)急措施 18 1. 概述 1.1 目的 CRM系統(tǒng)“CRM系統(tǒng)-系統(tǒng)測試計(jì)劃”文檔有助于實(shí)現(xiàn)以下目標(biāo)： l 確定CRM系統(tǒng)的測試環(huán)境、測試工具、測試范圍 l 列出測試用例編寫的相關(guān)約定 l 確定所需資源并對CRM系統(tǒng)測試的工具進(jìn)行估計(jì) l 列出CRM系統(tǒng)測試項(xiàng)目可交付元素 文件中所規(guī)定的內(nèi)容可以作為對測試過程完備性的對照檢查表，將會提高測試過程的每個(gè)階段的能見度，極大地提高測試工作的可管理性。 1.2 背景介紹 客戶關(guān)系管理系統(tǒng)是一種嶄新的、國際領(lǐng)先的、以客戶為中心的企業(yè)管理理論、商業(yè)運(yùn)作模式、也是一種以信息技術(shù)為手段、有效提高企業(yè)受益、客戶滿意度、雇員生產(chǎn)力的具體軟件和實(shí)現(xiàn)方法，是一套集理念、組織、流程、技術(shù)為一體的整體解決方案，是一種旨在改善企業(yè)與客戶之間關(guān)系的新型管理機(jī)制。企業(yè)實(shí)施CRM戰(zhàn)略本質(zhì)目標(biāo)是與那些有價(jià)值的客戶建立穩(wěn)定的長期雙贏關(guān)系，進(jìn)而為企業(yè)在幾樓的市場競爭中贏得優(yōu)勢。 1.3 測試計(jì)劃讀者范圍 測試工程師，開發(fā)經(jīng)理，項(xiàng)目經(jīng)理，實(shí)施負(fù)責(zé)人 2. 測試基本內(nèi)容 2.1測試環(huán)境 軟件環(huán)境（相關(guān)軟件、操作系統(tǒng)等） 操作系統(tǒng)：Win7 硬件環(huán)境 CPU處理器： i3-3220 @3.3 GHz 內(nèi)存：4G 系統(tǒng)類型：64位操作系統(tǒng) 軟件環(huán)境：CRM 2.2測試工具 用途 工具 生產(chǎn)廠商/自產(chǎn) 版本 備注 測試管理 ALM HP 11.5 被測系統(tǒng) CRM N/A 1.0 報(bào)告以及測試用例 Word Microsoft 2007 2.3測試范圍 2.3.1 測試對象 被測系統(tǒng)為CRM1.0版本，使用C++開發(fā)的。 2.3.2需要測試的特性 本次系統(tǒng)測試要求包含以下業(yè)務(wù)流程： 添加線索 導(dǎo)入與導(dǎo)出線索 查看線索 編輯線索 刪除線索 搜索線索 2.3.3不需要測試的特性 本次系統(tǒng)測試不需要包含的內(nèi)容： l 上述業(yè)務(wù)流程(2.3.2)之外的所有業(yè)務(wù)流程 l 被刪除的功能 l 被外包的功能 3. 測試用例設(shè)計(jì) 3.1 測試用例相關(guān)約定 在設(shè)計(jì)測試用例時(shí)，你需要定義程序的操作來確保程序的各方面都被測試到。為了確保清楚，準(zhǔn)確的捕獲到了完成一個(gè)操作所需要的所有行為，要滿足下面條件： 1) 測試用例的目標(biāo)清楚，并能滿足軟件質(zhì)量的各個(gè)方面，包括功能測試、性能測試、安全性測試、故障轉(zhuǎn)移測試、負(fù)載測試等。 2) 設(shè)計(jì)思路正確、清晰。例如，通過序列圖、狀態(tài)圖、工作流程圖、數(shù)據(jù)流程圖等來描述待測試的功能特性或非功能特性。 3) 在組織和分類上，測試用例層次清楚、結(jié)構(gòu)合理。測試用例的層次與產(chǎn)品特性的結(jié)構(gòu)/層次相一致，或者與測試的目標(biāo)/子目標(biāo)的分類/層次相一致，并具有合理的優(yōu)先級或執(zhí)行順序。 4) 測試用例覆蓋所有測試點(diǎn)、覆蓋所有已知的用戶使用場景(User scenario)，也就是說每個(gè)測試點(diǎn)都有相應(yīng)數(shù)量的測試用例來覆蓋，而且將各種用戶使用場景通過矩陣或因果圖等方式列出來，找到相對應(yīng)的測試用例。 5) 測試手段的區(qū)別對待。在設(shè)計(jì)測試用例時(shí)，就要全面考量測試的手段，哪些方面可以通過工具測試，哪些方面不得不用手工測試，對不同手段的測試用例區(qū)別對待。 6) 有充分的負(fù)面測試。作為測試用例，不僅要測試正確的輸入和操作，還要測試各種各樣的例外情況，如邊界條件、不正確的操作、錯誤的數(shù)據(jù)輸入等。 7) 沒有重復(fù)、冗余的測試用例，滿足相應(yīng)的行業(yè)標(biāo)準(zhǔn)等。 3.2 衡量測試用例設(shè)計(jì)的質(zhì)量標(biāo)準(zhǔn) 3.2.1系統(tǒng)性 1) 對于系統(tǒng)業(yè)務(wù)流程要能夠完整說明整個(gè)系統(tǒng)的業(yè)務(wù)需求、系統(tǒng)由幾個(gè)子系統(tǒng)組成以及它們之間的關(guān)系； 2) 對于模塊業(yè)務(wù)流程要能夠說明清楚子系統(tǒng)內(nèi)部功能、重要功能點(diǎn)以及它們之間的關(guān)系； 3.2.2連貫性 1) 對于系統(tǒng)業(yè)務(wù)流程來說，各個(gè)子系統(tǒng)之間是如何連接在一起，如果需要接口，各個(gè)子系統(tǒng)之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確； 2) 對于模塊業(yè)務(wù)流程來說，同級模塊以及上下級模塊是如何構(gòu)成一個(gè)子系統(tǒng)，其內(nèi)部功能接口是否連貫 3.2.3相關(guān)性 1) 考慮各個(gè)產(chǎn)品之間的相關(guān)性，當(dāng)某個(gè)產(chǎn)品某個(gè)頁面的字段發(fā)生增刪改時(shí)，其它產(chǎn)品是否有相應(yīng)變化，和后臺數(shù)據(jù)庫之間是否匹配 2) 當(dāng)某個(gè)產(chǎn)品增加某個(gè)功能時(shí)，其它相關(guān)產(chǎn)品是否有相應(yīng)措施 3.2.4全面性 1) 應(yīng)盡可能覆蓋程序的各種路徑 2) 應(yīng)盡可能覆蓋系統(tǒng)的各個(gè)業(yè)務(wù) 3) 應(yīng)考慮存在跨年、跨月的數(shù)據(jù) 4) 大量數(shù)據(jù)并發(fā)測試的準(zhǔn)備 5) 系統(tǒng)中各功能、業(yè)務(wù)的異常情況 3.2.5.正確性 1) 輸入用戶實(shí)際數(shù)據(jù)以驗(yàn)證系統(tǒng)是否滿足需求規(guī)格說明書的需求。 2) 測試用例中的測試點(diǎn)應(yīng)保證至少覆蓋需求規(guī)格說明書中的各項(xiàng)功能。 3.2.6符合正常業(yè)務(wù)慣例 1) 測試數(shù)據(jù)應(yīng)符合用戶實(shí)際工作業(yè)務(wù)流程 2) 兼顧各種業(yè)務(wù)變化的可能 3) 要符合當(dāng)前業(yè)務(wù)行業(yè)法律，法規(guī)。 3.2.7容錯性（健壯性） 1) 程序能夠接收正確數(shù)據(jù)輸入并且產(chǎn)生正確（預(yù)期）的輸出，輸入非法數(shù)據(jù)（非法類型、不符合要求的數(shù)據(jù)、溢出數(shù)據(jù)等），程序應(yīng)能給出提示并進(jìn)行相應(yīng)處理。 2) 在設(shè)計(jì)測試用例時(shí)，你需要定義程序的操作來確保程序的各方面都被測試到。為了確保清楚，準(zhǔn)確的捕獲到了完成一個(gè)操作所需要的所有行為，要滿足下面條件： 每一步都用主動語態(tài)書寫，使用主動語態(tài)的好處是使得測試執(zhí)行人員 4.實(shí)施計(jì)劃 4.1 測試進(jìn)度安排 本次測試的時(shí)間安排如下： 里程碑 執(zhí)行者 開始 時(shí)間 完成 時(shí)間 天數(shù)（天） 需求分析 CRM系統(tǒng)業(yè)務(wù)分析 編寫需求并導(dǎo)入ALM 測試用例設(shè)計(jì) 設(shè)計(jì)測試用例 用例評審 導(dǎo)入ALM（也可以直接在ALM錄入） 測試執(zhí)行 ALM中創(chuàng)建測試集 將測試計(jì)劃中案例添加到測試集 第一輪測試執(zhí)行并提交缺陷以及測試報(bào)告 第二輪測試執(zhí)行并提交缺陷以及測試報(bào)告 項(xiàng)目總結(jié)報(bào)告 系統(tǒng)測試的總結(jié) 4.2 測試人員安排以及職責(zé) 人員 角色 職責(zé)、任務(wù) 備注 PM 編寫項(xiàng)目計(jì)劃，審核測試計(jì)劃，審批測試案例，項(xiàng)目進(jìn)度追蹤管理，評估并防控風(fēng)險(xiǎn)及問題的發(fā)生 PA 編寫測試計(jì)劃，評審案例，協(xié)助將案例導(dǎo)入ALM，管理測試過程，生成QC測試報(bào)告 系統(tǒng)測試Owner 需求分析，設(shè)計(jì)測試用例，導(dǎo)入測試用例，執(zhí)行測試，記錄測試執(zhí)行日志，缺陷追蹤 ALM Owner ALM Admin，管理ALM項(xiàng)目，用戶，完成所有和ALM相關(guān)的工作； 配合PM 和 系統(tǒng)測試Owner完成所有在ALM的工作。 CRM業(yè)務(wù)人員 熟練的掌握CRM，安裝，CRM系統(tǒng)詳細(xì)的需求（PM） SCM 負(fù)責(zé)CRM環(huán)境，項(xiàng)目文檔的管理 4.3 輸出要求 《測試計(jì)劃》 《測試用例》 《測試數(shù)據(jù)》 《測試缺陷報(bào)告》 《測試總結(jié)報(bào)告》 5 測試方法 本次測試是CRM的系統(tǒng)測試，確保： 5.1黑盒測試方法 5.1.1等價(jià)類劃分法 將所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個(gè)等價(jià)類。 5.1.2邊界值分析法 指對輸入的邊界條件進(jìn)行分析，設(shè)計(jì)出針對邊界值的測試用例。 5.1.3因果圖法 就是利用圖解法分析軟件輸入(原因)和輸出條件(結(jié)果)之間的關(guān)系，以設(shè)計(jì)測試用例的方法。因果圖法適合于檢查程序輸入條件的多種情況的組合，并最終生成判定表，來獲得對應(yīng)的測試用例。 5.1.4功能圖法 功能圖是描述程序狀態(tài)變化、轉(zhuǎn)移的過程，因?yàn)檐浖\(yùn)行或操作的過程可以看作是其狀態(tài)不斷發(fā)生變化的過程。測試用例的設(shè)計(jì)就是如何覆蓋所有軟件表現(xiàn)出來的狀態(tài)，即在滿足輸入/輸出的一組條件下，軟件運(yùn)行是一系列有次序的、受控制的狀態(tài)變化過程。 5.1.5錯誤推測法 推測法主要依賴經(jīng)驗(yàn)、直覺來作出簡單的判斷甚至是猜測，給出可能存在缺陷的條件、場景等，在找到缺陷后，設(shè)計(jì)出相應(yīng)的測試用例。 5.1.6正交實(shí)驗(yàn)設(shè)計(jì)方法 主要步驟是： 1) 對軟件需求規(guī)格說明中的功能要求進(jìn)行劃分(層層分解與展開)，分解成具體的、相對獨(dú)立的基本功能。 2) 根據(jù)基本功能的質(zhì)量需求，找出影響其功能實(shí)現(xiàn)的操作對象和外部因素，每個(gè)因素的取值可以看作水平，多個(gè)取值就存在多個(gè)水平。 3) 確定待測試軟件中所有因素及其權(quán)值，這是測試用例設(shè)計(jì)的關(guān)鍵，確保全面、準(zhǔn)確。權(quán)值是依據(jù)各因素的影響范圍、發(fā)生的頻率和質(zhì)量的需求來確定的。 4) 加權(quán)篩選，生成因素分析表。 5) 利用正交表構(gòu)造測試數(shù)據(jù)集，正交表的每一行，就是一條測試用例?？紤]交互作用不可忽略的處理因素和不可混雜的原則，有交互作用的組合優(yōu)先安排。 6) 利用正交實(shí)驗(yàn)設(shè)計(jì)方法設(shè)計(jì)測試用例，可控制生成的測試用例數(shù)量，覆蓋率高且測試效率高。 5.1.7接口間測試 測試各個(gè)模塊相互間的協(xié)調(diào)和通信情況，數(shù)據(jù)輸入輸出的一致性和正確性。 5.1.8數(shù)據(jù)庫測試 依據(jù)數(shù)據(jù)庫設(shè)計(jì)規(guī)范對軟件系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)、數(shù)據(jù)表及其之間的數(shù)據(jù)調(diào)用關(guān)系進(jìn)行測試。 5.1.9可理解（操作）性 理解和使用該系統(tǒng)的難易程度（界面友好性）。 5.1.10可移植性 在不同操作系統(tǒng)及硬件配置情況下的運(yùn)行性。 5.2軟件測試的一些準(zhǔn)則 軟件測試從不同的角度出發(fā)會派生出兩種不同的測試原則，從用戶的角度出發(fā)，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產(chǎn)品，從開發(fā)者的角度出發(fā)，就是希望測試能表明軟件產(chǎn)品不存在錯誤，已經(jīng)正確地實(shí)現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。 為了達(dá)到上述的原則，那么需要注意以下幾點(diǎn)： 1．應(yīng)當(dāng)把“盡早和不斷的測試”作為開發(fā)者的座右銘 2．程序員應(yīng)該避免檢查自己的程序，測試工作應(yīng)該由獨(dú)立的專業(yè)的軟件測試機(jī)構(gòu)來完。 3．設(shè)計(jì)測試用例時(shí)應(yīng)該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。 4．一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。 5．對測試錯誤結(jié)果一定要有一個(gè)確認(rèn)的過程，一般有A測試出來的錯誤，一定要有一個(gè)B來確認(rèn)，嚴(yán)重的錯誤可以召開評審會進(jìn)行討論和分析。 6．制定嚴(yán)格的測試計(jì)劃，并把測試時(shí)間安排的盡量寬松，不要希望在極短的時(shí)間內(nèi)完成一個(gè)高水平的測試。 7．回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個(gè)錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。 8．妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。 6. 測試的各項(xiàng)標(biāo)準(zhǔn) 6.1 測試項(xiàng)通過/失敗的標(biāo)準(zhǔn) 一般有“基于測試用例”和“基于缺陷密度”兩種評比準(zhǔn)則，在這里我們采用前者。 準(zhǔn)則如下： l 功能性測試用例通過率達(dá)到95％； l 非功能性測試用例通過率達(dá)到90％； l 沒有高于優(yōu)先級 3以上的缺陷。 l 備選通過辦法： 根據(jù)實(shí)際情況由軟件開發(fā)部門的經(jīng)理、項(xiàng)目經(jīng)理和測試負(fù)責(zé)人等共同討論確定本階段是否結(jié)束。 6.2 中斷測試和恢復(fù)測試的判斷標(biāo)準(zhǔn) l 缺陷數(shù)量大于100時(shí)中斷測試直至缺陷修復(fù)到10時(shí)恢復(fù) l 當(dāng)代碼不全時(shí)停止測試直至代碼全面恢復(fù)測試 l 當(dāng)缺陷嚴(yán)重程度為4的個(gè)數(shù)超過總體缺陷的1/2時(shí)停止測試 l 當(dāng)缺陷優(yōu)先級為1的個(gè)數(shù)超過總體缺陷1/3時(shí)停止測試 7. 缺陷跟蹤 7.1 缺陷類型 本次測試過程中缺陷的管理將在ALM中進(jìn)行，缺陷大致包含如下狀態(tài)： 缺陷類型 具體含義 冗余代碼多 代碼冗余，即是編程時(shí)不必要的代碼段。 兼容性差 軟件從某一環(huán)境轉(zhuǎn)移到另一環(huán)境后不能正常運(yùn)行 可操作性差 軟件難以理解,不容易使用,運(yùn)行緩慢。 界面不友好 最終用戶會認(rèn)為界面不好。 與需求不一致 軟件沒有實(shí)現(xiàn)產(chǎn)品規(guī)格說明所要求的功能模塊; 軟件實(shí)現(xiàn)了產(chǎn)品規(guī)格說明沒有提到的功能模塊。 可擴(kuò)展性差 軟件在原有的功能上不容易實(shí)現(xiàn)新增其他新的功能。 7.2 缺陷管理流程圖 缺陷的狀態(tài)如上所示，通常缺陷的管理流程如下圖所示： 7.3 缺陷嚴(yán)重程度和優(yōu)先等級 缺陷嚴(yán)重程度： 嚴(yán)重級別 嚴(yán)重程度描述 1-Low 使用不方便的問題 對軟件的改進(jìn)建議： 1) 容易給用戶誤解和歧義的提示； 2) 界面需要改進(jìn)的； 3) 對有疑慮的文檔，提出修改建議 2-Medium 界面非關(guān)鍵信息錯誤 ?微小的錯誤，不會影響系統(tǒng)的功能 ?風(fēng)格不統(tǒng)一，包括相近流程的界面布局相異，相同的問題點(diǎn)提示信息相異，但對用戶的使用方法和使用習(xí)慣不造成影響（需求中明確的風(fēng)格要求除外）如幫助、提示信息不完整，有錯誤，但不影響用戶使用。 不正確的，但有使系統(tǒng)使用起來不太方便的錯誤： 1) 系統(tǒng)的提示語不明確，不簡明 2) 滾動條無效 3) 可編輯區(qū)和不可編輯區(qū)不明顯 4) 光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯誤 5) 上下翻頁，首尾頁定位錯誤 6) 界面不一致，或界面不正確 7) 日期或時(shí)間初始值錯誤（起止日期、時(shí)間沒有限定） 8) 按鈕或標(biāo)簽上有拼寫錯誤的單詞、不正確的大小寫 該問題是一個(gè)不準(zhǔn)確或容易誤解的行為，但不會引起下面（3、4、5級別）列出的問題 3-High 功能缺失或錯誤，界面關(guān)鍵信息錯誤 ?該問題增加了安裝、測試或用戶操作的復(fù)雜度或成本 ?該問題輕微降低了系統(tǒng)的性能，但系統(tǒng)仍然能工作 ?非核心功能實(shí)現(xiàn)不完整或不正確，但對系統(tǒng)影響很小，系統(tǒng)仍然能工作 ?業(yè)務(wù)流程對應(yīng)的功能未實(shí)現(xiàn)，但是有替代方法解決，不影響實(shí)際的使用 ?部署文檔描述不明確，增加部署難度 不正確的，但不會影響系統(tǒng)穩(wěn)定性的： 1) 過程調(diào)用或其它腳本錯誤 2) 系統(tǒng)刷新錯誤 3) 產(chǎn)生錯誤結(jié)果，如計(jì)算結(jié)果錯誤等 4) 功能的實(shí)現(xiàn)有問題。如在系統(tǒng)實(shí)現(xiàn)的界面上，一些可接受輸入的控件點(diǎn)擊后無作用，對數(shù)據(jù)庫的操作不能正確實(shí)現(xiàn) 5) 編碼時(shí)數(shù)據(jù)類型、長度定義錯誤的 6) 對用戶的使用有操作順序上的限制 7) 雖然正確性不受影響，但系統(tǒng)性能和響應(yīng)時(shí)間受到影響 4-Very High 導(dǎo)致系統(tǒng)崩潰、數(shù)據(jù)丟失、嚴(yán)重系統(tǒng)資源泄露，關(guān)鍵功能缺失或錯誤 ?該問題會嚴(yán)重降低系統(tǒng)的性能 ?業(yè)務(wù)流程不正確 ?需求實(shí)現(xiàn)不完整，設(shè)計(jì)實(shí)現(xiàn)上的缺陷，且無替代方法，如：設(shè)計(jì)了3條路上山，但是實(shí)際只有一條可以上 ?該問題不符合需求規(guī)格書 ?配置項(xiàng)設(shè)計(jì)錯誤，無法正常配置，或配置后，測試中出現(xiàn)與配置相關(guān)的錯誤 ?部署文檔錯誤，導(dǎo)致部署失敗 ?與其它網(wǎng)元的接口，調(diào)用或提供錯誤 ?申報(bào)信息提交錯誤，可繼續(xù)測試（如聯(lián)網(wǎng)申報(bào)、分類錯誤、亂碼、違禁信息），但影響應(yīng)用后續(xù)審核上線； 5-Urgent 必須馬上解決的，根據(jù)情況可以要求項(xiàng)目組立刻發(fā)布新版本，阻礙流程、系統(tǒng)崩潰導(dǎo)致開發(fā)或測試無法進(jìn)行或程序無法正常運(yùn)行的缺陷。 ?提交物缺失，導(dǎo)致測試、部署和維護(hù)無法正常進(jìn)行 ?需求未實(shí)現(xiàn) ?正常的操作，導(dǎo)致系統(tǒng)（進(jìn)程）崩潰 ?系統(tǒng)不能啟動或啟動后無法正常工作 ?系統(tǒng)（進(jìn)程）經(jīng)常自動崩潰（至少一天一次） 缺陷的優(yōu)先級： 優(yōu)先級 優(yōu)先級描述 1-Low 可能會修復(fù)，但是也能不修復(fù) 2-Medium 如果時(shí)間允許應(yīng)該修復(fù) 3-High 在產(chǎn)品發(fā)布前必須修復(fù) 4-Very High 盡快修復(fù) 5-Urgent 立即修復(fù)，停止進(jìn)一步測試 7. 測試報(bào)告 8. 風(fēng)險(xiǎn)及應(yīng)急措施 風(fēng)險(xiǎn)： 1) 人員流動風(fēng)險(xiǎn)：在項(xiàng)目進(jìn)行過程人員的流動導(dǎo)致的風(fēng)險(xiǎn)； 2) 人員過失風(fēng)險(xiǎn)：因測試人員在工作中不認(rèn)真，如測試用例執(zhí)行不徹底，結(jié)果填寫錯誤等； 3) 環(huán)境風(fēng)險(xiǎn)：在項(xiàng)目進(jìn)行過程中，由于測試環(huán)境的問題導(dǎo)致的錯誤及項(xiàng)目延期等問題； 4) 需求變更風(fēng)險(xiǎn)：由于需求的變更導(dǎo)致的測試在需求上發(fā)生的錯誤或遺漏； 5) 需求分析錯誤：因需求分析人員在需求分析中出現(xiàn)的理解錯誤，導(dǎo)致的一系列連帶錯誤； 6) 需求文檔缺失：測試人員沒有詳細(xì)設(shè)計(jì)說明書，導(dǎo)致測試在需求分析中出現(xiàn)錯誤； 7) 用例設(shè)計(jì)風(fēng)險(xiǎn)：測試人員在用例設(shè)計(jì)中出現(xiàn)不到位而導(dǎo)致的風(fēng)險(xiǎn)； 8) 自動化測試風(fēng)險(xiǎn)：因界面不穩(wěn)定而導(dǎo)致的自動化測試風(fēng)險(xiǎn)； 9) 硬件資源風(fēng)險(xiǎn)：因?yàn)閷y試硬件資源預(yù)估不足，導(dǎo)致的測試進(jìn)行中出現(xiàn)的資源緊張； 10) 版本控制：因測試過程中版本控制不足而導(dǎo)致的程序出現(xiàn)的混亂，出現(xiàn)不應(yīng)出現(xiàn)的問題； 11) 時(shí)間風(fēng)險(xiǎn)：因測試時(shí)間預(yù)估不足而導(dǎo)致的不能按時(shí)將項(xiàng)目交付； 12) 回歸風(fēng)險(xiǎn)：因回歸測試不徹底而發(fā)生的風(fēng)險(xiǎn)； 13) 環(huán)境改變風(fēng)險(xiǎn)：因測試環(huán)境和真實(shí)環(huán)境不一致，導(dǎo)致的測試不徹底； 14) 隱藏缺陷：因程序在測試運(yùn)行中沒有出現(xiàn)，而在特殊情況下出現(xiàn)的缺陷導(dǎo)致的風(fēng)險(xiǎn)； 解決方案： 1) 加強(qiáng)人員儲備，在項(xiàng)目組中人員互為替補(bǔ)，及時(shí)做好人員的補(bǔ)充； 2) 加強(qiáng)人員的監(jiān)督，優(yōu)化人員的監(jiān)督機(jī)制； 3) 對測試環(huán)境定期檢查，盡量避免出現(xiàn)的問題，同時(shí)，為項(xiàng)目中預(yù)留適當(dāng)時(shí)間來緩沖因出現(xiàn)的問題而導(dǎo)致的延期； 4) 在項(xiàng)目初期與客戶明確需求，避免需求的后期變更，同時(shí)，在項(xiàng)目計(jì)劃期留出緩沖時(shí)間； 5) 做好小組評審，爭取在問題的初期改正，如用例設(shè)計(jì)，需求分析等； 6) 加強(qiáng)測試中的信息交流，及時(shí)與客戶代表溝通，明確需求； 7) 與開發(fā)人員及時(shí)溝通，爭取界面的盡快穩(wěn)定，必要的話，取消部分自動化測試項(xiàng)目； 8) 對硬件資源的及時(shí)監(jiān)控，合理分析，爭取在問題出現(xiàn)前解決； 9) 明確版本控制，避免版本混亂； 10) 初期合理安排計(jì)劃，進(jìn)行過程中出現(xiàn)問題，盡量在不改變計(jì)劃的前提下通過其他措施趕工，如果確定不能按期完成，與項(xiàng)目經(jīng)理溝通； 11) 回歸測試盡量詳細(xì)； 12) 在測試環(huán)境的配置，爭取盡量與真實(shí)環(huán)境一致； 鼓勵測試人員發(fā)揮主觀能動性，提出可能出現(xiàn)的缺陷，完善測試過程。　 -可編輯修改-