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

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

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