項目產(chǎn)品系統(tǒng)測試計劃

1、XXXXXX測試中心xxxx系統(tǒng)測試計劃文檔號:密級：內(nèi)部版本號：2.0XXXXXX測試中心XXXX系統(tǒng)測試計劃XXXXXX系統(tǒng)系統(tǒng)測試計劃撰寫：審核：XXXXXX測試中心日期：XXXX年8月變更記錄A1.4增加測試后需要提父的測試文檔M4.2修改測試工具名稱及版本M全部更新目錄及頁眉頁腳注：變更分三種：A增加，M 修改，D刪除目錄1 前言41.1 目的4.1.2 術(shù)語定義4.1.3 測試參考文檔5.1.4 測試提交文檔5.2 測試進度與工作量6.3 測試啟停標準7.4 測試資源8.4.1 人力資源8.4.2 測試環(huán)境8.4.3 測試工具9.5 測試策略9.5.1 功能測試1.05.2 數(shù)據(jù)和

2、數(shù)據(jù)庫完整性測試1.05.3 用戶界面測試1.15.4 安全性和訪問控制測試125.5 性能測試1.35.6 故障轉(zhuǎn)移和恢復(fù)測試135.7 回歸測試1.55.8 安裝測試1.66 測試風險分析及優(yōu)先級176.1 測試風險1.76.2 功能模塊測試優(yōu)先級18、八、亠1刖言項目名稱：XXX系統(tǒng)V2.0，以下簡稱XXXX系統(tǒng)XXX系統(tǒng)V2.0主要包括xxxx系統(tǒng)服務(wù)器、xxxx系統(tǒng)Web服務(wù)器，是一種無客戶端的純Web模式交流 平臺，適合廣域網(wǎng)上提供客戶服務(wù)和咨詢服務(wù)辦公模式。XXXX系統(tǒng)是為了支持M2M網(wǎng)站系統(tǒng)的在線客服功能，實現(xiàn)M2M網(wǎng)站訪客與網(wǎng)站管理員進行在線交流。同時xxxx系統(tǒng)也是網(wǎng)上交互

3、平臺，實現(xiàn)即時交流、咨詢和服務(wù)等。實現(xiàn)了網(wǎng)上即時客服功能，實現(xiàn)了企業(yè)產(chǎn)品的售前、售后服務(wù)功能，由原來電話咨詢服務(wù)轉(zhuǎn)為網(wǎng)上在線咨詢和服務(wù)模式，為企業(yè)節(jié)省了服務(wù)費用，同時也為用戶咨詢和服務(wù)帶來方便。1.1目的本測試計劃的編寫目的在于使測試人員更好地執(zhí)行測試工作，它說明了測試工作的各項要求和性能指標，明確測試任務(wù)，闡述實用范圍及背景，提供維護人員解決問題所需的條件，形成本系統(tǒng)的質(zhì)量記 錄,為以后工作提供參考資料。本測試報告的預(yù)期讀者是XXX系統(tǒng)即時辦公系統(tǒng)的軟件開發(fā)人員、項目管理人員、研發(fā)管理人員、測試經(jīng)理、測試人員、維護人員。12術(shù)語定義XMPP 協(xié)議：XMPP （ Extensible Mess

4、ageing and Presenee Protocol :可擴展信息與存在協(xié)議）是目前主流的四種IM （I nsta nt Messagi ng，即時信息）協(xié)議之一，其他三種分別為：即時信息和空間協(xié)議（IMPP）、空間和即時信息協(xié)議（PRIM）、會話啟動協(xié)議（SIP）。在這四種協(xié)議中，XMPP是最靈活的。XMPP是一種基于XML的協(xié)議，它繼承了在XML環(huán)境中靈活的發(fā)展性。因此，基于XMPP的應(yīng)用具有超強的可擴展性。經(jīng)過擴展以后的XMPP可以通過發(fā)送擴展的信息來處理用戶的需求，以及在XMPP的頂端建立如內(nèi)容發(fā)布系統(tǒng)和基于地址的服務(wù)等應(yīng)用程序。而且，XMPP包含了針對服務(wù)器端的軟件協(xié)議，使之能與

5、另一個進行通話，這使得開發(fā)者更容易建立客戶應(yīng)用程序或給一個配好系統(tǒng)添加功能。XXXXXX測試中心xxxx系統(tǒng)測試計劃13測試參考文檔F表列出了制定測試計劃時所使用的文檔，并標明了各文檔的可用性:表1-1測試參考文檔文檔已創(chuàng)建或可用已被接收或已經(jīng)過復(fù)審作者或來源備注xxxx系統(tǒng)即時辦公系統(tǒng)需求規(guī)格說明書可用已被接收XXXxxxx系統(tǒng)Express V2.0開發(fā)計劃可用已被接收XXX測試提交文檔XXX系統(tǒng)V2.0系統(tǒng)結(jié)題驗收測試報告(XXXX系統(tǒng)V2.0質(zhì)量分析報告xxxx系統(tǒng)V2.0性能測試報告xxxx系統(tǒng)V2.0問題報告xxxx系統(tǒng)V2.0系統(tǒng)測試用例xxxx系統(tǒng)V2.0系統(tǒng)測試報告xxxx系

6、統(tǒng)V2.0系統(tǒng)測試分析報告xxxx系統(tǒng)V2.0性能測試計劃xxxx系統(tǒng)V2.0系統(tǒng)測試計劃XXXXXX測試中心-7xxxx系統(tǒng)測試計劃XXXXXX測試中心xxxx系統(tǒng)測試計劃2測試進度與工作量表2-1測試進度與工作量估計表測試活動計劃開始日期計劃結(jié)束日期工作量估計工作成果測試準備XXXX7-25XXXX-7-315個工作日測試計劃、測試用例功能測試XXXX-8-1xxxx-8-86個工作日功能測試總結(jié)回歸測試XXXX-8-11xxxx-8-133個工作日測試記錄及BUG提交其它類型測試XXXX-8-14xxxx-8-152個工作日測試記錄及BUG提交性能測試XXXX-8-18xxxx-8-23

7、5個工作日性能測試報告安裝測試XXXX-8-24xxxx-8-262個工作日提交安裝程序其他XXXX-8-27xxxx-9-024個工作日測試分析報告編寫相尖結(jié) 題文檔其它類型測試包括：數(shù)據(jù)庫和數(shù)據(jù)完整性能測試、安全性和訪問控制測試、故障轉(zhuǎn)移和XXXXXX測試中心XXXX系統(tǒng)測試計劃XXXXXX測試中心xxxx系統(tǒng)測試計劃3測試啟停標準表3-1系統(tǒng)測試開始、停止標準表測試階段開始標準停止標準系統(tǒng)測試模塊的單元測試結(jié)束，達到單元測試停止標準。(1) 按照系統(tǒng)測試計劃，完成了系統(tǒng)測試。(2) 達到了確認準則中尖于系統(tǒng)測試所規(guī)定的覆蓋率(達到100% )的要求。(3) 系統(tǒng)滿足產(chǎn)品需求規(guī)格說明書的要

8、求。(4) 缺陷狀態(tài)為closed或later狀態(tài)。(5) 在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復(fù)率達到標準。(6) 系統(tǒng)測試的缺陷密度(個/KLOC)需要符合組織級質(zhì)量目標中要求并達到項目控制范圍。XXXXXX測試中心-11 -XXXX系統(tǒng)測試計劃4測試資源4.1人力資源下表列出了此項目的人員配備計劃。表4測試人員需求表角色所推薦的最少資源具體職責說明功能測試員2人撰寫測試計劃（總體）、撰寫測試小組 工作規(guī)范、設(shè)計TD庫結(jié)構(gòu)、檢杳組 內(nèi)工作、撰寫測試分析報告、分析測 試需求、設(shè)計測試用例、執(zhí)行測試工 作、撰寫測試記錄、撰寫測試總結(jié)性能測試員1人撰寫性能測試分析報告、執(zhí)行性能測試 工

9、作、撰寫性能測試記錄、撰寫性能測試總結(jié)4.2測試環(huán)境表4-2測試環(huán)境說明表軟件環(huán)境（相尖軟件、操作系統(tǒng)等）服務(wù)器端:操作系統(tǒng)：Win dows XP + SP2mysql5,Tomcat5.5.25 , JDK1.6.03 版本客戶端：XXXXXX測試中心xxxx系統(tǒng)測試計劃操作系統(tǒng)：Win dows XP + SP2瀏覽器：Microsoft IE6.0硬件環(huán)境（網(wǎng)絡(luò)、設(shè)備等）服務(wù)器配置：PC 機配置:Intel(R) Pentium(R) 4 CPU 1.60GHz ，1.00GB 內(nèi)存客戶端配置：PC 機配置:Intel(R) Pentium(R) 4 CPU 1.60GHz 1.00G

10、B 內(nèi)存網(wǎng)絡(luò)環(huán)境采用10/100M辦公網(wǎng)4.3測試工具F表列出了測試使用的工具。表4-3測試工具使用表用途工具生產(chǎn)廠商/自產(chǎn)版本BUG管理TestDirector8.0Mercury In teractive8.0文檔書寫Officer 2003/2007Microsoft2007配冒管理工目TortoiseSVN開源1.3.5測試管理工具TestDirector8.0Mercury In teractive8.0自動化測試工具LoadRu nn er8.0HP8.0幵發(fā)IDEEclipse3.2免費3.25測試策略測試策略提供了對測試對象進行測試的推薦方法。對于每種測試，都應(yīng)提供測試說明，并

11、解釋其實施的原因。制定測試策略時所考慮的主要事項有：將要使用的技術(shù)以及判斷測試除此之外，測試還只應(yīng)在安何時完成的標準。下面列出了在進行每項測試時需考慮的事項， 全的環(huán)境中使用已知的、有控制的數(shù)據(jù)庫來執(zhí)行。5.1功能測試對測試對象的功能測試應(yīng)側(cè)重于所有可直接追蹤到用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的測試需求。這種測試的目標是核實數(shù)據(jù)的接受、處理和檢索是否正確，以及業(yè)務(wù)規(guī)則的實施是否恰當。此類測試基于黑盒技術(shù)，該技術(shù)通過圖形用戶界面（GUI ）與應(yīng)用程序進行交互，并對交互的輸出或結(jié)果進行分析，以此來核實應(yīng)用程序及其內(nèi)部進程。以下為各種應(yīng)用程序列出了推薦使用的測試概要：表5-1功能測試策略測試目標確保測試的功

12、能正常測試范圍xxvxL統(tǒng)所有模塊技術(shù)利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例、用例流或功能，以核實以下內(nèi)容：在使用有效數(shù)據(jù)時得到預(yù)期的結(jié)果。在使用無效數(shù)據(jù)時顯示相應(yīng)的錯誤消息或警告消息。各業(yè)務(wù)規(guī)則都得到了正確的應(yīng)用。開始標準模塊功能完成，提交測試完成標準所有缺陷已經(jīng)被修復(fù)測試重點和優(yōu)先級需考慮的特殊事項確定或說明那些將對功能測試的實施和執(zhí)行造成影響的事項或因素（內(nèi)部的或1、部的）5.2數(shù)據(jù)和數(shù)據(jù)庫完整性測試要在XXXX系統(tǒng)中，數(shù)據(jù)庫和數(shù)據(jù)庫進程應(yīng)作為一個子系統(tǒng)來進行測試。在測試這些子系統(tǒng)時，不應(yīng)將測試對象的用戶界面用作數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng)還需要進行深入的研究，以確定可以支持以下測試的工

13、具和技術(shù)。表5-2數(shù)據(jù)和數(shù)據(jù)庫完整性測試策略測試目標確保數(shù)據(jù)訪問方法和進程正常運行、確保數(shù)據(jù)一致性測試范圍xxxx系統(tǒng)所有功能模塊技術(shù)檢杳數(shù)據(jù)庫，確保數(shù)據(jù)已按預(yù)期的方式填充，并且所有的數(shù)據(jù)庫事件已正常發(fā)生；或者檢杳所返回的數(shù)據(jù)，確 保正當?shù)睦碛蓹z索到了正確的數(shù)據(jù)開始標準數(shù)據(jù)庫可正常運行、測試版本已經(jīng)提交測試完成標準所有的數(shù)據(jù)庫訪問方法和進程都按照設(shè)計的方式運行，數(shù)據(jù)沒 有遭到損壞。所計劃的測試已全部執(zhí)行。發(fā)現(xiàn)的缺陷已全部解決。測試重點和優(yōu)先級需考慮的特殊事項確保數(shù)據(jù)的一致性和完整性5.3用戶界面測試用戶界面測試用于核實用戶與軟件之間的交互。 用戶界面測試的目標是確保用戶界面會 通過測試對象的功

14、能來為用戶提供相應(yīng)的訪問或瀏覽功能。 用戶界面測試還可確保界面中的 對象按照預(yù)期的方式運行，并符合公司或行業(yè)的標準。表53用戶界面測試策略測試目標通過測試進行的瀏覽可正確反映業(yè)務(wù)的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪 問方法（Tab鍵、鼠標移動和快捷鍵）的使用。窗口的對象和特征（例如，菜單、大小、位置、狀態(tài)和中心）都符合標準。測試范圍xxxx系統(tǒng)所有功能模塊技術(shù)為每個窗口創(chuàng)建或修改測試，以核實各個應(yīng)用程序窗口和對象 都可正確地進行瀏覽，并處于正常的對象狀態(tài)。開始標準測試版本已經(jīng)提交測試XXXXXX測試中心-15xxxx系統(tǒng)測試計劃XXXXXX測試中心xxxx

15、系統(tǒng)測試計劃完成標準成功地核實出各個窗口都與基準版本保持一致，合可 或符 接受標準。測試重點和優(yōu)先級需考慮的特殊事項并不是所有定制或第二方對象的特征都可訪問。5.4安全性和訪問控制測試安全性和訪問控制測試側(cè)重于安全性的兩個尖鍵方面：應(yīng)用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務(wù)功能的訪問。系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠程訪問。應(yīng)用程序級別的安全性可確保：在預(yù)期的安全性情況下只能訪問有限的數(shù)據(jù)。表5-4安全性和訪問控制測試策略測試目標應(yīng)用程序級別的數(shù)據(jù)安全性測試范圍xxxx系統(tǒng)安全技術(shù)應(yīng)用程序級別的安全性：確定并列出各用戶類型及其被授權(quán)訪問的功能或數(shù)據(jù)。為各用戶類型創(chuàng)建測試，并通過創(chuàng)建各用戶類型

16、所特有的事務(wù)來核實其權(quán)限。開始標準xxxx系統(tǒng)模塊提交完成標準各種已知的Actor類型都可訪冋相應(yīng)的功能或數(shù)據(jù)，而且所有事務(wù)都按照預(yù)期的方式運行，并在先刖的應(yīng)用程序功能測試中運行了所有的事務(wù)。測試重點和優(yōu)先級需考慮的特殊事項必須與相應(yīng)的網(wǎng)絡(luò)或系統(tǒng)管理員一直對系統(tǒng)訪問權(quán)進行檢杳和 討論。由于此測試可能是網(wǎng)絡(luò)管理可系統(tǒng)管理的職能，可能會不需要 執(zhí)行此測試。5.5性能測試性能評性能測試對響應(yīng)時間、事務(wù)處理速率和其他與時間相尖的需求進行評測和評估。測的目標是核實性能需求是否都已滿足。實施和執(zhí)行性能評測的目的是將測試對象的性能行為當作條件（例如工作量或硬件配置）的一種函數(shù)來進行評測和微調(diào)。注：以下所說的

17、事務(wù)是指邏輯業(yè)務(wù)事務(wù)”。這種事務(wù)被定義為將由系統(tǒng)的某個Actor通過使用測試對象來執(zhí)行的特定用例，添加或修改給定的合同。表5-5性能評測策略測試目標核實所指定的事務(wù)或業(yè)務(wù)功能在以下情況下的性能行為： 正常的預(yù)期工作量 預(yù)期的最繁重工作量測試范圍隊列消息、主題消息（并發(fā)訪問）技術(shù)使用代碼驅(qū)動樁的方式開始標準功能測試完成完成標準性能達到需求，無致命性能障礙測試重點和優(yōu)先級需考慮的特殊事項需要考慮到數(shù)據(jù)量的大小以及大數(shù)據(jù)量5.6故障轉(zhuǎn)移和恢復(fù)測試故障轉(zhuǎn)移和恢復(fù)測試可確保測試對象能成功完成轉(zhuǎn)移，并能從導(dǎo)致意外數(shù)據(jù)損失或數(shù)據(jù)完整性破壞的各種硬件、軟件和網(wǎng)絡(luò)故障中恢復(fù)。故障轉(zhuǎn)移測試可確保：對于必須持續(xù)運行

18、的系統(tǒng)，一旦發(fā)生故障，備用系統(tǒng)就將不失時機地頂替”發(fā)生故 障的系統(tǒng)，以避免丟失任何數(shù)據(jù)或事務(wù)。恢復(fù)測試是一種對抗性的測試過程。在這種測試中，將把應(yīng)用程序或系統(tǒng)置于極端的條件下（或者是模擬的極端條件下），以產(chǎn)生故障（例如設(shè)備輸入/輸出（I/O）故障或無效的數(shù)據(jù)庫指針和尖鍵字）。然后調(diào)用恢復(fù)進程并監(jiān)測和檢查應(yīng)用程序和系統(tǒng)，核實應(yīng)用程序或XXXXXX測試中心XXXX系統(tǒng)測試計劃XXXXXX測試中心xxxx系統(tǒng)測試計劃系統(tǒng)和數(shù)據(jù)已得到了正確的恢復(fù)。表5-6故障轉(zhuǎn)移和恢復(fù)測試策略測試目標確保恢復(fù)進程（手工或自動）將數(shù)據(jù)庫、應(yīng)用程序和系統(tǒng)正確 地，灰復(fù)到預(yù)期的已知狀態(tài)。測試范圍xxxx系統(tǒng)全部模塊技術(shù)使用

19、為功能和業(yè)務(wù)周期創(chuàng)建的測試來創(chuàng)建一系列的事務(wù)。達到 預(yù)期的測試起點后，分別執(zhí)行或模擬以下操作：客戶機斷電：尖閉 PC機的電源。服務(wù)器斷電：模擬或啟動服務(wù)器的斷電過程。通過網(wǎng)絡(luò)服務(wù)器產(chǎn)生的中斷：斷開通信線路的連接或尖閉網(wǎng)絡(luò)服務(wù)器或路由器的電源。一日實現(xiàn)了上述情況（或模擬情況），就應(yīng)該執(zhí)行其他事務(wù)。而且一日達到第二個測試點狀態(tài)，就應(yīng)調(diào)用恢復(fù)過程。在測試不完整的周期時，所使用的技術(shù)與上述技術(shù)相冋，只 不過應(yīng)異常終止或提前終止數(shù)據(jù)庫進程本身。開始標準xxxx系統(tǒng)功能測試已經(jīng)結(jié)束完成標準在所有上述情況中，應(yīng)用程序、數(shù)據(jù)庫和系統(tǒng)應(yīng)該在恢復(fù)過程 完成時立即返回到一個已知的預(yù)期狀態(tài)。此狀態(tài)包括僅限于已知損壞的

20、字段、指針或尖鍵字范圍內(nèi)的數(shù)據(jù)損壞，以及表明進程或事務(wù)因中斷面未被完成的報表。測試重點和優(yōu)先級需考慮的特殊事項恢復(fù)測試會給其他操作帶來許多的麻煩。斷開纜線連接的方法（模擬斷電或通信中斷）可能并不可取或不可行。所以， 可能會需要采用其他方法，例如診斷性軟件工具。這吐測試應(yīng)該在工作時間之外或在一臺獨立的計算機上運行。5.7回歸測試回歸測試指在測試或其他活動中發(fā)現(xiàn)的缺陷經(jīng)過修改后重新測試。目的是驗證軟件缺陷得到了正確的修復(fù)，同時對系統(tǒng)的變更沒有影響以前的功能?；貧w測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進行多次回歸測試。當軟件中所含錯誤被發(fā)

21、現(xiàn)時，如果錯誤跟蹤與管理系統(tǒng)不夠完善，就可能會遺漏對這些錯誤的修改；而幵發(fā)者對錯誤理解的不夠透徹，也可能導(dǎo)致所做的修改只修正了錯誤的外在表現(xiàn)，而沒有修復(fù)錯誤本身，從而造成修改失敗；修改還有可能產(chǎn)生副作用從而導(dǎo)致軟件未被修改的部分產(chǎn)生 新的問題，使本來工作正常的功能產(chǎn)生錯誤。同樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。因此，每當軟件發(fā)生變化時，我們就必須重新測試現(xiàn)有的功能，以便確定修改是否達到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。同時，還需要補充新的測試用例來測試新的或被修改了的功能。為了驗證 修改的正確性及其影響就需要進行回

22、歸測試?；貧w測試策略分為完全重復(fù)性測試和選擇性重復(fù)測試。選擇性重復(fù)測試包括：覆蓋修改法、周邊影響法、指標達成法。安裝測試表5-7回歸測試策略測試目標檢驗已經(jīng)被發(fā)現(xiàn)的缺陷有沒有被正確的修改和修改過程中有沒 有引發(fā)新的缺陷。測試范圍xxxx系統(tǒng)所有功能模塊手工開發(fā)腳本或開發(fā)自動腳本，以驗證新版本的缺陷技術(shù)已經(jīng)被正確修復(fù)并且沒有造成新的缺陷。技術(shù)策略使用選擇性重復(fù)測試方法進行。開始標準提交修改后的版本完成標準xxxx系統(tǒng)所有Bug已經(jīng)修復(fù)沒有新的Bug產(chǎn)生。測試重點和優(yōu)先級需考慮的特殊事項安裝測試有兩個目的：第一個目的是確保該軟件在正?；虍惓Ｇ闆r下都能進行安裝，例如，進行首次、升級、完整的或自定義的

23、安這通常是指運行大量為功能測試制定裝。異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權(quán)限等。 第二個目的是核實軟件在安裝后可立即正常運行。的測試。表5-8安裝測試策略測試目標核實在以下情況下，測試對象可正確地安裝到各種所需的硬件 配胃中：首次安裝：以前從未安裝過“XX系統(tǒng)的新計算機更新安裝：以前 安裝過相冋版本的系統(tǒng)的計算機以前安裝過XXXX系統(tǒng)較早版本的計算機測試范圍xxxx系統(tǒng)的安裝程序技術(shù)啟動或執(zhí)行安裝。使用預(yù)先確疋的功能測試腳本子集來運仃事務(wù)。開始標準xxxx系統(tǒng)的完整安裝包已經(jīng)提交完成標準xxxx系統(tǒng)事務(wù)成功執(zhí)行，沒有出現(xiàn)任何故障。測試重點和優(yōu)先級需考慮的特殊事項應(yīng)該選擇xxxx系統(tǒng)的哪些事

24、務(wù)才能準確地測試出xxxx系統(tǒng)應(yīng)用程序已經(jīng)成功安裝，而且沒有遺漏主要的軟件構(gòu)件。6測試風險分析及優(yōu)先級6.1測試風險1、交付日期由于開發(fā)人員未能在計劃規(guī)定的日期內(nèi)交付被測試對象，可能會導(dǎo)致測試計劃時間的滯后，影響到整個項目進度?；蛘哂捎诮桓度掌诘臏螅斐蓽y試時間的縮減，影響測試工作質(zhì)量。規(guī)避方法：開發(fā)人員盡可能的在計劃規(guī)定的日期內(nèi)交付被測對象。如果交付的被測試對象確實需要延后，應(yīng)該得到項目組長、開發(fā)經(jīng)理、QA的認可，并且盡可能的保證測試工程時間。2、測試需求XXXXXX測試中心XXXX系統(tǒng)測試計劃XXXXXX測試中心xxxx系統(tǒng)測試計劃在開發(fā)人員提供的測試需求中，可能會存在需求點的遺漏、需求

25、指標的估算不足或者過于的遠離實際， 項目過程中測試需求的變更等，這些可能會造成測試的不充分或者測試時間、資源的浪費。規(guī)避方法：在將測試需求提交給開發(fā)人員前，應(yīng)該確保需求中各項指標數(shù)據(jù)與實際測試過程中誤差盡可能的小。最好不要隨意的進行需求的變更，否則造成測試過程管理上的混亂。如果需要對測試需求進行變更，應(yīng)該得到項目組長、開發(fā)經(jīng)理、QA的認可。3、測試范圍由于開發(fā)過程中模塊的開發(fā)范圍優(yōu)先級別的不一致，造成測試不能連貫性，這樣會對測試人員在進行測試用例編寫過程中，不能很好的將前后模塊完成的對應(yīng)起來，導(dǎo)致測試的范圍缺乏必要的 廣度，造成測試的不充分。規(guī)避方法：在測試人員指定好測試范圍后，開發(fā)人員能夠提供必要的支持，對測試人員劃定的測試范圍進行評審和建議。4、人員的能力由于開發(fā)過程中，項目需要利用到很多的不同的技術(shù)做支撐。而測試人員不可能去對每一門技術(shù)做到如數(shù)家珍，面面俱到，這就涉及到一個測試工作的深度問題。由于測試人員自身的業(yè)務(wù)技術(shù)知 識不夠也會影響到測試質(zhì)量。規(guī)避辦法：在測試之前開發(fā)人員能夠?qū)⑾嗉饧夹g(shù)做一些簡單講解，提供一些相尖技術(shù)資料，并對可能會出現(xiàn)的問題，能給出一些指導(dǎo)性的建議。測試人員盡可能的有目的、有計劃的、有針對的盡 快提高自己的業(yè)務(wù)素質(zhì)。5、測試環(huán)