全程軟件測試之測試需求分析與計劃

時間 2019-11-29

原文原文鏈接

在項目啓動以後，就要着手軟件項目的計劃，包括軟件測試計劃。軟件測試計劃是整個開發計劃的組成部分，同時，它又依賴於軟件組織過程、項目的整體計劃、質量文化和方針。在測試計劃活動中，首先要確認測試目標、範圍和需求，其中"測試需求分析"是關鍵任務，而後在測試需求基礎上制定測試策略，並對測試任務、時間、資源、成本和風險等進行估算或評估。數據庫

不管什麼時候進行估算，咱們都是在預測將來，並會接受某種程度的不肯定性。軟件項目計劃的目標是提供一個框架，不斷收集信息，對不肯定性進行分析，將不肯定性的內容慢慢轉化爲肯定性的內容，該過程最終使得項目測試負責人可以對資源、成本及進度進行愈來癒合理、準確的估算。這些估算是軟件項目開始時在一個限定的時間框架內作出的，而且隨着項目的進展而不斷更新。因此，測試計劃強調的是一個過程，計劃（Planning）的過程，而不只僅是爲了一個文檔——"測試計劃書"（Test Plan）。編程

測試計劃活動過程伴隨着需求文檔的審查，而需求文檔的評審反過來也有利於測試計劃的制定。並且，測試計劃必須創建在軟件需求定義之上，爲軟件的質量需求驗證和確認活動的開展進行規劃和指導。瀏覽器

2.1 軟件測試的目標和基本需求 安全

在分析測試需求以前，先要肯定測試目標，而測試目標的肯定，取決於質量要求。雖然在理論上，對軟件質量的要求是比較明確的，但對不一樣的軟件開發項目，其質量要求是不同的。根據特定的質量要求，肯定測試目標。而後再根據測試目標，來分析測試需求。服務器

2.1.1 質量要求 網絡

關於什麼是軟件質量，本書在第1.1.1節進行了詳細討論，包括軟件產品的質量屬性，如功能性、易用性、性能、安全性、兼容性、可用性、可維護性、擴展性等。可是，僅僅根據這些質量屬性不夠，還要參考業務領域專業知識、行業標準、地方標準或其餘規範等，才能明確特定產品的質量要求。只有明確質量要求，才能明確測試目標。讓咱們先討論特定軟件產品的質量要求。數據結構

對質量的具體要求，能夠參考國際標準ISO/IEC 25030的相關描述，質量不只侷限於最終用戶的需求（一般指外部質量要求、軟件使用質量），還要考慮產品或項目的干係人（Stakeholders）的質量要求，包括組織的管理層、系統運維等，對軟件內部質量也有具體要求，包括軟件的可維護性、可擴充性等。從質量來看，用戶的需求會顯得更重要，咱們會在使用質量（Quality in Use）上有更多的關注，使用質量的具體要求見圖2-1。架構

手機也是你們熟悉的產品，不一樣的用戶羣對一部智能手機的要求也是不一樣的，如低檔手機和高檔手機有着不一樣的質量要求、老年人和年輕人對手機也有不一樣的指望，商務人士對手機也有一些特定的需求（如Blackberry的實實在在的全鍵盤）。低檔手機的質量要求以下。併發

通話正常、穩定。

通話質量要有必定保障。

待機時間長。

安全，電池不能發生爆炸。

外觀大氣美觀，不要過重。

通信錄、短信、鬧鐘等功能使用方便。

支持手寫輸入功能。

但對智能手機，對手感、用戶體驗、性能、外觀質感等有更高的要求。雖然不一樣的產品類型、不一樣的應用領域，功能的質量要求是有差別的，但通常來講，通用的功能質量要求以下。

程序安裝、啓動正常，有相應的提示框、錯誤提示等。

每項功能符合實際要求。

每一項功能能正常運行、輸出結果正確。

能處理各類不正常的操做，對異常數據的輸入能夠進行提示、容錯處理等。

系統的界面清晰、美觀。

菜單、按鈕操做正常、靈活，能處理一些異常操做。

能接受正確的數據輸入，如測試最大輸入的文字數、單雙字節、特殊符號等。

數據的輸出結果準確，格式清晰，能夠保存和讀取。

功能邏輯清楚，符合使用者習慣。

系統的各類狀態按照業務流程而變化，並保持穩定。

支持各類應用的環境。

能配合多種硬件周邊設備。

軟件升級後，能繼續支持舊版本的數據。

與外部應用系統的接口有效。

用戶界面（User Interface，UI）是和用戶進行交互的窗口。僅從這一點，就能夠清楚地知道用戶界面友好程度的重要性。用戶界面是否友好直接影響用戶對軟件產品或軟件服務的滿意度，即咱們常常提到的用戶體驗，用戶界面設計就是給用戶一個良好的體驗，不只使用軟件簡單、方便和明瞭，並且心情舒暢、愉悅。對於Web應用，更強調網頁內容和文字表述，但這些每每是開發人員容易忽視的地方。對於開發人員來講，注意力經常集中在功能的實現上。文字不只誤導用戶的操做或影響用戶的體驗，並且有時可能會引發法律方面的問題。測試人員應確保內容表達符合習慣，更專業、流暢，有時須要招聘1～2個語言學（文學、中文、英文、日文等）專業的人員參加測試隊伍。在UI上，主要的質量要求以下。

通用框架、浮動窗口和文字等總體上佈局合理、位置恰當。

文字沒有亂碼、換行正常，並且內容格式、順序正確。

文字標記和超連接能夠打開和跳轉成功。

色彩搭配要協調，要造成對比強烈的色彩效果，也要恰到好處。

之前面Google Talk做爲例子，其產品的質量要求必定會包括功能正確、性能好、易用，但這樣的質量要求還不夠明確，對設定測試目標幫助不大，還須要進一步分析其質量要求。對於功能，能夠逐條列出其主要功能，而後分析功能在質量上有沒有一些特定的要求。例如：

（1）支持語音、視頻通話，就要肯定語音、視頻通話的質量要求，是否支持電信級業務服務水平即嚴格的QoS標準（服務質量）？支持高清視頻（如720p、1080p等）通話嗎？視頻通話質量可以根據網絡情況可調整嗎？語音在延遲、回聲、噪音、顫音等上面有具體的質量要求嗎？視頻通話對帶寬最低限制是多少？

（2）是否支持基於行業標準的會話發起協議（SIP）？

（3）單擊姓名打開聊天窗口，可同時打開任意多個聊天窗口。可能就會問，最多能打開多少個窗口？有沒有性能問題？

（4）郵件、通信錄等涉及我的隱私，在安全性上有什麼要求？

（5）口令設置有哪些參數約束？這些約束可否保證其較高的安全性？

（6）好友列表有沒有限制（容量問題）？

（7）不一樣顏色的小球圖標及不一樣的符號表示好友的在線狀態，多少時間（如幾10、幾百毫秒，幾秒）刷新一次？

（8）正常鏈接狀況下，添加好友的時間是多少？

對應Google日曆，可能就簡單些，其質量要求和通常Web應用軟件的質量要求基本一致，主要體如今功能、性能、安全性、易用性等主要方面的同時，可能還會有下列的質量要求。

（1）功能：計算正確、顯示正常、邏輯合理等。

（2）性能：正常時每一個頁面刷新顯示時間不超過3秒，高峯時不超過10秒。

（3）安全性：登陸安全，被邀請人只能看到當前事件，不能查看他人的其餘事件等。

（4）易用性：日曆能在不一樣顯示方式之間方便、快捷切換，顯示內容也能根據不一樣方式改變、能支持"直接拖拽"操做日曆等。

爲了進一步理解產品質量要求，能夠看看你們熟悉的拼音輸入法有什麼具體的質量要求。《Windows軟件測試探祕》一書第6章就給出很好的實例，如表2-1所示。

2.1.2 測試目標

軟件測試的目標就是根據質量要求，逐項肯定、驗證軟件的實際表現，提供軟件產品完整的質量信息；同時，爲了幫助團隊向客戶提供一個高質量的軟件產品，軟件測試的目標就是更早地、儘量地將軟件產品或軟件系統中所存在的各類問題找出來，並促進各種開發人員儘快地解決問題。衡量測試目標的實現，就是經過測試覆蓋率來衡量，經過對測試結果的分析，來明確產品質量要求、功能點或代碼行（分支、條件等）的測試覆蓋率。例如：

需求項和功能點覆蓋率100%；

代碼行覆蓋率95%。

但針對具體項目或具體產品的測試目標，不只根據產品質量要求進一步明確測試目標，還要根據項目背景環境（如進度、預算等）、測試團隊能力和現有的技術來肯定測試目標。例如，預算和進度限制測試的充分性，包括是否有足夠的時間和資源去作兼容性測試、性能測試、安全性測試和可靠性測試等。即便對某項特定的測試，可以測試到什麼深度和廣度，都須要因地制宜地考量。由於從理論上講，但願該有的測試都作了，每項測試都能作到100%，但實際項目中，進度、資源、能力等都有限制，不可能達到理想的目標，也不必。例如單元測試，理想的目標是百分之百覆蓋代碼行、分支和條件，但在實際項目中，可能將單元測試的目標定爲代碼行的覆蓋率50%、60%或80%。

再舉一個例子。國際標準IEC 61508把系統安全完整性分爲0、一、二、3.和4等5個級別，而做爲《鐵路應用—通訊、信令和處理系統—控制和保護系統用軟件》歐洲標準50128:2011，根據安全完整性，肯定這一領域的軟件系統的測試目標，即要所完成的測試，如表2-2所示。

測試的目標要有具體的指標，能夠被度量，在測試執行結束以前或以後，可以判斷測試目標是否被達到。對各項質量要求的驗證達到什麼程度，可以給出數字描述的就儘可能給出，從功能、性到安全性、兼容性等逐項給出明確的目標。

2.1.3 基本的測試需求

先談軟件產品的功能測試需求。在功能測試中，不只要完成業務邏輯的驗證，還要進行用戶界面和輸入空間的驗證。例如，在討論軟件測試方法時，常常談到黑盒方法的等價類劃分、邊界值分析、決策表、因果分析等方法，實際上這些只是功能測試的冰山一角，不只要對輸入空間進行驗證，並且還要對用戶界面、業務邏輯等進行驗證。總之，爲了更全面地驗證或評估軟件功能的質量，須要在各個層次（單元、接口和系統）和各個方面（代碼、文檔和系統）進行測試。也就是說，在功能測試中，不光要進行不一樣層次的測試，還要針對不一樣空間或領域進行相應的測試。歸納起來，功能測試的需求包括下列這些內容。

（1）單元之間調用、函數之間調用的各類參數的數據測試。

（2）系統的不一樣輸入、結果輸出的數據測試。

（3）數據庫默認值、數據備份和恢復的測試。

（4）系統各個界面的驗證。

（5）用戶操做的易用性、用戶體驗的測試。

（6）單元邏輯、算法的測試，如經過代碼評審發現算法問題。

（7）系統的業務邏輯驗證，如端到端的測試。

（8）文檔的驗證，包括用戶手冊、安裝文檔逐行逐字的驗證。

（9）各種關鍵代碼的評審。

（10）功能的錯誤操做、異常操做的測試。

（11）功能一致性、多功能互操做的測試。

若是系統只是知足了功能要求，沒有知足一些非功能特性（性能、安全性等）要求，仍是不能知足客戶的需求，不能得到用戶的信任。如某個網站功能（註冊、信息查詢等）齊全，也能夠被訪問，可是，每打開一個頁面都須要兩分鐘。結果，用戶不能忍受，不再會訪問這個網站。這種非功能性的需求知足和功能性的需求知足一樣重要。

爲了驗證系統是否符合非功能特性的質量需求而進行的測試是系統非功能性測試。非功能性測試需求覆蓋軟件系統的全部質量屬性，包括性能、安全性、可靠性、兼容性、易維護性和可移植性等，它們存在對應的關係，如圖2-2所示。

但每一類測試可能須要單獨考慮，性能測試和兼容性測試、安全性測試都不同，考慮的着眼點不同。例如，性能測試的目的之一就是爲了驗證當前系統實際所具備的性能。若是實際性能達不到系統使用的需求，就須要改進設計，優化算法或程序代碼，直至達到要求。除了以上的目的以外，性能測試還能夠進一步分爲基準測試和規劃測試，具體分析以下。

對於新創建的系統，測試人員並不瞭解某些具體的性能指標，因此性能測試的首要任務就是獲取這些指標的標準值，而後基於由這些標準值所設定的基準，進一步制定產品性能改進計劃，也就是性能指標的變動需求計劃。

產品最終要被部署到運行環境中，在部署以前要進行規劃，例如，根據用戶的數量或數據負載來決定服務器的選型和數量，若是10萬個用戶須要4臺雙核CPU、內存4GB的服務器，若是是100萬個用戶是否須要16臺雙核CPU、內存8GB的服務器等。這些規劃的數據依賴於性能的規劃測試。

容量測試能夠看作是性能測試的一種，或者認爲系統的容量是系統的性能指標之一。如某個Web站點能夠支持多少個併發用戶、網絡在線會議系統中與會者的人數。若是實際容量已知足要求，就能幫助用戶創建對產品的信心。若是不能知足要求，就應該尋求新的解決方案，以提升系統的容量。若一時沒有新的解決方案，就有必要在產品發佈說明上明確容量上的限制，避免引發軟件產品使用的糾紛。

概念：

（1）負載測試（Load Test），也稱壓力測試（Stress test）、強度測試。負載測試經過模擬實際應用的軟硬件環境及用戶使用過程的系統負荷，逐漸加載或一次性加載，長時間或超大負荷地運行軟件，以測試系統的穩定性，並試圖找出系統性能的瓶頸和異常的地方等。經過負載測試，也能夠肯定系統的正常工做條件、極限條件等，並瞭解系統可靠性等，從而提升軟件系統的可靠性、穩定性，減小系統的宕機時間。

（2）性能測試（Performance test），經過測試肯定系統運行特性的性能指標數據，如數據吞吐量、響應時間、CPU使用率等。性能測試能夠分爲3類：

驗證測試，針對系統驗證事先（如產品規格說明書）已定義的性能指標；

基準測試，就是在系統標準配置下得到有關的系統指標數據，其測試結果應具備高度的一致性、標準性，可做爲未來性能改進的基準線；

規劃測試，是爲軟件部署而進行的測試，即在多種特定的環境下，得到系統不一樣性能的指標，從而決定在系統部署時採用什麼樣的軟、硬件配置。

（3）容量測試（Capacity test），預先分析出反映軟件系統應用特徵的某項指標的極限值，瞭解該軟件系統的承載能力或提供服務的能力。系統在極限值狀態下，主要功能還能正常運行。容量測試還將肯定測試對象在給定時間內可以持續處理的最大負載（數據量、事件規模等）。容量測試能夠看做負載測試和性能測試的組合。

（4）安全性測試（Security test），檢驗系統權限設置的有效性，防範非法入侵的能力，數據備份和恢復的能力等。例如，測試人員能夠假扮非法入侵者，試圖採用各類辦法突破系統防線，修改權限或存取權限以外的數據。

（5）容錯測試（Recovery test），檢查軟件在異常條件下是否具備防禦性的措施或者恢復某種災難性破壞的手段或能力。容錯性測試包括兩個方面：

輸入異常數據或進行異常操做，以檢驗系統的保護性。若是系統的容錯性好，系統只給出提示或內部消化掉，不會致使系統出錯甚至崩潰；

災難恢復性測試。經過各類手段，讓軟件強制性地發生故障，而後驗證系統已保存的用戶數據是否丟失，系統和數據是否能儘快恢復或在指定時間間隔內恢復。

對於自動恢復，需驗證從新初始化、檢查點、數據恢復和從新啓動等機制的正確性；對於人工干預的恢復系統，還需估測平均修復時間，肯定其是否在可接受的範圍內。容錯測試和故障轉移（fail-over）、可用性測試等有直接的關係。

2.2 項目的測試需求

在掌控了軟件項目的背景，瞭解了產品的質量要求和軟件測試的基本需求以後，同時，測試人員也會閱讀相關軟件需求文檔，參與需求評審。在這些基礎之上，能夠進行測試的需求分析，即包括下面這些工做：

明確測試範圍，瞭解哪些功能點要測試、哪些功能點不須要測試；

知道哪些測試目標優先級高、哪些目標優先級低；

要完成哪些相應的測試任務才能確保目標的實現。

而後才能估算測試的工做量，安排測試的資源和進度。測試需求分析是測試設計和開發測試用例的基礎，測試需求分析得越細，對測試用例的設計質量的幫助越大，詳細的測試需求仍是衡量測試覆蓋率的主要依據。只有在作好測試需求的基礎上，才能規劃項目所需的資源、時間以及所存在的風險等。

2.2.1 測試需求分析的基本方法

不管是功能測試，仍是非功能性測試，其測試需求的分析都有如下兩個基本的出發點。

（1）從客戶角度進行分析：經過業務流程、業務數據、業務操做等分析，明確要驗證的功能、數據、場景等內容，從而肯定業務方面的測試需求。

（2）從技術角度分析：經過研究系統架構設計、數據庫設計、代碼實現等，分析其技術特色，瞭解設計和實現要求，包括系統穩定可靠、分層處理、接口集成、數據結構、性能等方面的測試需求。

若是有完善的需求文檔（如產品功能規格說明書），那麼功能測試需求能夠根據需求文檔，再結合前面分析和本身的業務知識等，比較容易肯定功能測試的需求。若是缺少完善的需求文檔，就須要藉助啓發式分析方法，從系統業務目標、結構、功能、數據、運行平臺、操做等多方面進行綜合分析，瞭解測試需求，並經過和用戶、業務人員、產品經理或產品設計人員、開發人員等溝通，逐步讓測試需求清晰起來。

業務目標：全部要作的功能特性都不能違背該系統要達到的業務目標，多問問如何更好地達到這些業務目標，如何驗證是否實現這些業務目標？

系統結構：產品是如何構成的？系統有哪些組件、模塊？模塊之間有什麼樣的關係？有哪些接口？各個組件又包含了哪些信息？

系統功能：產品能作哪些事、處理哪些業務？處理某些業務時由哪些功能來支撐、造成怎樣的處理過程？處理哪些錯誤類型？有哪些UI來呈現這些功能？

系統數據：產品處理哪些數據？最終輸出哪些用戶想要的結果？哪些數據是正常的？又有哪些異常的數據？輸入數據如何被轉化、傳遞的？這中間有哪些過渡性數據？輸出數據格式有什麼要求？輸出數據存儲在哪裏？

系統運行的平臺：系統運行在什麼硬件上？什麼操做系統？有什麼特殊的環境配置？是否依賴第三方組件？

系統操做：有哪些操做角色？在什麼場景下使用？不一樣角色、場景有什麼不一樣？有哪些是交集的？

上面這些分析，更可能是從測試對象自己來進行分析，還包括用戶角色分析、用戶行爲分析、用戶場景分析等。咱們還能夠經過以下一些其餘方面的資料，幫助咱們更好地完成測試的需求分析。

對競爭產品進行對比分析，明確測試的重點。

質量存在哪些風險，包括安全性漏洞等。

對過去相似產品或本產品上個版本所發現的缺陷進行分析，總結缺陷出現的規律，看看有沒有漏掉的測試需求。

在易用性、用戶體驗上有什麼特別的需求須要驗證？

管理者或市場部門有沒有事先特定的聲明？

有沒有相應的行業規範、特許質量標準？

測試需求分析過程，能夠從質量要求出發，來展開測試需求分析，如從功能、性能、安全性、兼容性等各個質量要求出發，不斷細化其內容，挖掘其對應的測試需求，覆蓋質量要求。也能夠從開發需求（如產品功能特性點、敏捷開發的用戶故事）出發，針對每一條開發需求造成已分解的測試項，結合質量要求，這些測試項再擴展爲測試任務，這些測試任務包括了具體的功能性測試任務和非功能性測試任務。在整理測試需求時，須要分類、細化、合併並按照優先級進行排序，造成測試需求列表，

2.2.2 測試需求的分析技術

在軟件測試需求分析過程當中，能夠採用有效的問題分析技術來幫助咱們提升測試需求的有效性和工做效率。從測試需求分析來看，咱們力求經過與各相關干係人的溝通，收集足夠的、有價值的信息或數據，藉助下列途徑來達到良好的分析效果。

（1）經過提煉，抓住主要線索，或做爲總體來進行分析，使測試需求分析簡單化。

（2）經過業務需求或功能層次的整理，使測試需求分析結構化、層次化。

（3）經過繪製業務流程圖、數據流程圖等，使測試需求分析可視化。

（4）經過類比、隱喻，增強用戶需求的理解，更好地轉化爲測試需求。

在測試需求的分析中，能採用靜態分析技術與動態分析技術、定性分析技術和定量分析技術，其中以靜態分析技術、定性分析技術爲主，但產品性能、用戶行爲分析和用戶體驗分析等也常採用定量分析技術。有時，會採用綜合分析技術、模型分析技術等。

在測試需求分析時，產品自己每每處於需求分析和設計過程當中，靜態分析技術是經常使用的分析技術。靜態分析技術包括以下。

經過系統建模語言（SysML）的需求圖，能夠更好地分析各項需求之間的關係，比較容易肯定測試需求的邊界。

經過狀態圖、活動圖更容易列出的測試場景，瞭解狀態轉換的路徑和條件，哪些是重要測試場景等。

實體關係圖能夠明確測試的具體對象（實體）及其之間的關係，進行相關分析。

魚骨圖法、思惟導圖等，有一個清晰的分析思惟過程，迅速展開測試需求，隨時補充測試需求等。

代碼複雜度靜態分析工具，代碼越複雜，測試的投入也須要越多。

還能夠用一些普通工具，如檢查表。

腦力激盪法，讓你們發散思惟，相互啓發，讓任何測試需求不會被錯過。

而動態分析技術應用相對少一些，但在一些應用場景的分析中仍是有幫助的，如前面提到的競爭對手產品分析，這是一種動態分析技術，經過操做競爭對手產品，全面瞭解相同業務的需求，在功能、邏輯、界面等各個方面深刻挖掘測試需求。一樣道理，需求原型分析技術——基於開發已構建的原型來進行測試需求分析，更能直觀地理解產品，進而有助於測試需求的分析，達到相似效果。能夠採用仿真技術、模擬技術、角色扮演等手段，也能幫助測試需求的分析。

2.2.3 功能測試範圍分析

在分析測試範圍時，通常先進行功能測試的範圍分析，而後再進行非功能性測試的範圍分析。對於功能測試，能夠藉助業務流程圖、功能框圖等來幫助咱們進行測試的需求分析。在面向對象的軟件開發中，也可藉助UML用例圖、活動圖、協做圖和狀態圖來進行功能測試範圍分析。這裏經過前述兩個實例簡單地說明如何作功能測試的需求分析。

1．Google Talk客戶端軟件

基本功能測試須要根據具體功能的邏輯、黑盒測試方法等進行測試用例的設計，並考慮用戶的習慣思惟，把功能劃分紅以下若干個模塊。

登陸與註銷。

主面板功能設置。

文字聊天。

語音聊天。

用戶設置。

消息/呼叫的提示。

文件與語音郵件發送。

而後按模塊分別進行分析，但同時也要明確系統的邊界，以及各個模塊之間是否存在關聯關係、互操做性等。讓咱們首先快速分析一下各個模塊的測試需求。

安裝與卸載。安裝的界面檢查、正常安裝、中途退出、操做邏輯檢查等。卸載後檢查用戶數據是否被刪、有無遺留文件、對其餘應用程序運行是否產生影響。

註冊、登陸與註銷。用戶註冊Google帳號，在客戶端登陸，其餘好友能看到其登陸後上線和註銷後下線等相關狀態信息。

好友管理。能夠方便地添加、刪除好友，Google Talk會自動將最常聯繫的好友排在列表的最上面，也能夠用查找框快速地查找好友。

文字聊天。聊天窗口分菜單、消息顯示、消息輸入幾個部分，Talk的功能相對簡單，重點要求是方便地在用戶之間傳遞消息，以及不一樣輸入語言的正確顯示。

語音通話。分爲呼叫、通話、結束三個階段。要求控制反應靈敏，語音清晰連續。

郵件管理。Talk 和Gmail作到了很好的整合，聊天記錄也能夠保存在Gmail郵件服務器上，在客戶端咱們重點只看郵件提醒的功能。

2．Google日曆的測試範圍

Google日曆的功能能夠分爲4部分——日曆頁面顯示、事件（包括各類活動、會議和待辦事項等）添加功能、搜索功能和選項設置，如圖2-3所示。測試關鍵點在於確保Google日曆的組件可以準確、安全、無錯誤地實現事件定製及瀏覽、預定提醒、日曆共享、個性化設定等功能。而對某個具體功能的測試，其測試範圍通常包括輸入、編輯、查詢、顯示等。如在數據輸入方面，要測試最大輸入的文字數、雙字節文字、特殊符號等各類狀況，還要測試輸入區域支持複製、粘貼等操做。

對於Web的功能分析，也能夠從頁面幀結構、佈局來進行分析。例如Google日曆的顯示區域設定爲如下4個子區域。

頂部是搜索框和協做分享。

左邊區域，快速建立事件、日曆、個人日曆和其餘日曆等。

右邊上面區域，按日、周、月等方式瀏覽活動，打印以及設置。

右邊大區域就是日曆顯示和操做的主區域。

如圖2-4所示。在顯示上，要測試日曆和各個分類框架顯示格式是否正確，排序是否正確，文字標記和超連接是否能夠打開和跳轉成功。重點要測試右邊的主顯示和操做區域，要求在輸入不少且很長的待辦事項的狀況下，顯示內容能夠自動換行，字符沒有亂碼和截斷，相互之間的日、周、月、年表單之間相互跳轉沒有問題。

在進一步進行功能分析後，能夠了解更具體的功能測試範圍。

（1）登陸，是最基本的功能需求，對用戶身份進行合法性驗證，對各類登陸模式的安全性驗證，包括Cookie和Session的有效期驗證。

（2）活動定製功能。

定製會議後，能正確顯示。

循環會議能夠成功指定與顯示。

會議能夠被成功修改。

跨日會議的準確性，以及夏令時的準確顯示。

與其餘日曆的兼容，如導入/導出數據是否正常。

（3）提醒功能。根據活動的設置，系統可以在活動以前發送提醒到Google alk、電子郵件地址、移動設備等。

（4）共享功能。能夠根據用戶的權限設置來決定是否讓他人看到本身的日曆。

（5）時間表能將用戶所注意或關心事件的時間和用戶的我的行事整合起來，直接瞭解效率手冊中的重要活動，並可查看朋友的效率手冊、俱樂部的效率手冊、運動隊的比賽日程以及其餘更多內容。按照合併視圖或欄視圖方式顯示。

3．通常性的Web測試項目

（1）用戶登陸，登陸的用戶名、口令可否保存？口令忘了，可否找回來？容許登陸失敗的次數是否有限制？口令字符有沒有嚴格要求（如長度、大小寫、特殊字符）？是否硬性規定通過一段時間後必須改變口令？

（2）站點地圖和導航條。每一個網站都須要站點地圖，讓用戶一看就能瞭解網絡內容，並且當新用戶在網站中迷失方向時，站點地圖能夠引導用戶進行瀏覽，找到所想訪問的內容。須要驗證站點地圖每個連接是否存在並且正確，有沒有涵蓋站點上全部內容的連接。是否每一個頁面都有導航條? 導航條是否一致、直觀?

（3）連接，去正確地方，即連接地址正確，並能顯示正常、天然，不要給人忽然的感受。

（4）表單，各項輸入是必需的、合理的，各項操做正常，對於錯誤的輸入有準確、適當的提示，並完成最後的提交。提交後，返回提交內容的顯示，使用戶放心。如用戶經過表單進行註冊，能輸入用戶名、口令、地址、電話、愛好等各類信息，當格式、內容不對或不符時，及時給予提示，在用戶提交信息後，進一步檢查各項內容的正確性，而後寫入數據庫、返回註冊成功的消息。

（5）數據校驗，根據業務規則和流程對用戶輸入數據進行校驗，是許多系統不可缺乏的。經過列表選擇、規則提示或在線幫助，能很好解決這問題。

（6）Cookie，在Web應用中處處可見，用來保存用戶註冊、訪問和其餘本地客戶端信息，所保存的信息要加密，並能及時更新。Cookie被刪除了，能被重建。

（7）Session，是否安全、穩定，並且佔用較少的資源。

（8）SSL、防火牆等的測試。使用了SSL，瀏覽器地址欄中URL的"http:"就變爲"https:"了，服務器的鏈接端口號則由80變爲433，應用程序接口API也要和頁面保持一致。防火牆支持更多的設置，包括代理、驗證方式、超時等。

（9）接口測試，與數據庫服務器、第三方產品接口（如電子商務網站信用卡驗證）的測試，包括接口錯誤代號和列表。

4．UI測試的需求

過度地使用粗體字、大字體和下畫線可能會讓用戶感到不舒服。

背景顏色使用不當，雖然美觀，但不易閱讀，內容閱讀纔是最重要的。一般來講，文字和背景對比較大比較適宜，背景淺淡則文字採用深顏色；背景深黑則文字採用亮色。對比要採用適當，和諧每每更容易被人接受。

每一張圖片都是必要的，位置和大小合適，採用了JPG和GIF格式，並且和文字吻合。

不要由於使用圖片而使窗口和段落排列古怪或者出現孤行。

表格顯示是否清晰，必要的數據可否在一個頁面顯示？翻頁、水平移動是否流暢等？表格裏的文字是否能折行且保持內容完整，或者使用表格欄寬度設置協調？

2.2.4 非功能性的系統測試需求

對於非功能性的系統測試，主要目的是驗證軟件系統的總體性能等是否知足其產品設計規格所指定的要求，涉及非功能性的質量需求有系統性能、安全性、兼容性、擴充性等的測試，可能還會涉及第三方產品的集成測試。對於每個應用軟件系統，非功能特性的質量需求都是存在的，這類測試需求會因不一樣的項目類型差別比較大，這些需求的程度、重要性不一樣，所以要求爲非功能性測試需求設置優先級，下面就作一個簡單的分析。

純客戶端軟件，如字處理軟件、下載軟件、媒體（音頻/視頻）播放軟件等在系統測試要求上是最低的，對性能、容錯性、穩定性等有必定的要求，如佔用較少的系統資源（CPU和內存），並且能運行在不一樣的操做系統上，通常分爲Windows、Linux和Mac等。在Windows上要支持Windows NT、Windows 2000、Windows XP和Windows Vista等。

純Web（B/S）應用系統，如門戶網站、我的博客網站、網絡信息服務等在系統測試上要求較高，特別強調性能和可用性，對安全性有必定的要求，主要是保證數據的備份和登陸權限。性能要求好，能夠容許大量併發用戶的訪問，並且用戶在任什麼時候刻均可以訪問，即每週7天，天天24小時（7×24）運行。

客戶端/服務器（C/S）應用系統，如郵件系統、羣件或工做流系統、即時消息系統等在系統測試需求上與Web應用系統接近，也可能出現大量併發訪問的用戶，但安全性相對好寫，客戶端是特定的開發軟件，相對於瀏覽器來講，對端口、協議等的限制比較容易作到。

大型複雜企業級系統涉及面廣、集成性強，包括B/S、C/S、數據庫、目錄服務、服務器集羣、XML接口等各個子系統。在系統測試需求上，這類系統要求最高，不管是在性能、可用性方面，仍是在安全性、可靠性等方面，都有很高的要求。

系統非功能性測試的需求在不一樣應用領域也體現較大差別。如網上銀行、信用卡服務等系統，其安全性、可用性和可靠性等多方面的測試相當重要，由於這方面的缺陷極可能會給用戶形成較大的損失。這些系統須要獲得充分的安全性測試、容錯性測試和負載測試。多數狀況下，還須要獨立第三方的安全認證。

而對於局域網內的企業級應用來講，有關權限控制、口令設置等安全性測試依然重要，但兼容性測試就相對簡單，由於能夠指定某些特定的硬件和軟件，如打印機只用HP LaserJet，操做系統和瀏覽器只用Windows XP和IE，無須對各類各樣的硬件和軟件進行兼容性測試。對於客戶端軟件，通常狀況下，性能不是問題，而容錯性、穩定性的測試則顯得重要些。

對於企業級應用系統來講，存在着不一樣的應用模式，其系統的架構也不同，能夠分爲"以功能爲中心、以數據庫爲中心和以業務邏輯（工做流）爲中心"等，在進行系統測試時，所設定的目標也有必定的區別。

以功能爲中心的系統，強調模塊化的低耦合性和高內聚性，這類系統的可擴充性、維護性要求很高。

以數據庫爲中心的系統，強調數據處理的性能、正確性和有效性，使數據具備良好的一致性和兼容性，同時，確保數據的安全性，包括數據的存儲、訪問控制、加密、備份和恢復等。

以應用邏輯（工做流）爲中心的系統，強調靈活、流暢和時間性，系統的可配置性強，接口規範，如採用XML統一各工做流構件的輸入和輸出。

除此以外，還有其餘一些因素的影響，如項目的週期性和依賴性等。若是項目是一次性的，對可擴充性、可移植性等要求低，而長期性的項目（產品開發）對可擴充性、可移植性要求就很高。

Google日曆其實是一種軟件服務，即屬於軟件即服務（Software as a Service，SaaS）的應用模式，對軟件運行的服務質量（QoS）也有很高的要求，須要支持7x24不間斷的服務。對於這樣的Web服務軟件，非功能性測試的需求涉及性能、安全性、容錯性、兼容性、可用性、可伸縮性等各個方面。

服務級別協議（SLA）指定了最低性能要求，以及未能知足此要求時必須提供的客戶支持級別和程度。與 QoS 要求同樣，服務級別要求源自業務要求，對要求的測試條件及不符合要求的構成條件均有明確規定，並表明着對部署系統必須達到的總體系統特性的擔保。服務級別協議被視爲合同，因此必須明確規定服務級別要求。如表2-3所示。下面側重性能、可用性、安全性和兼容性的測試需求討論，而對其餘非功能性屬性就不進行過多的討論，這並不意味着這些屬性就沒有測試需求，例如可維護性（即系統維護的容易程度）的測試需求也是不少的，包括系統監視、日誌文件、故障恢復、數據更新和備份等測試。

1．性能測試

性能測試分爲服務器端性能測試和客戶端性能測試，須要考慮"哪些負載（如併發用戶數200、400、1000等）、哪些基本配置（最低配置、標準配置等）須要進行性能測試"等測試需求。服務器端的性能測試還可進一步分爲基準性能測試、性能驗證測試、壓力測試、容量測試、可伸縮性測試等。

客戶端性能測試，須要對頁面顯示、刷新的時間進行測試得到相關性能指標數據，如在Google日曆中添加大批量的待辦事項，而後查看頁面瀏覽的響應時間。客戶端軟件性能測試，還要考察其運行時所佔有資源（如CPU、內存）狀況，佔有資源越少越好。

如Google Talk在好友數量以及對話窗口很是多的狀況下，CPU、內存的使用仍然處在一個合理的範圍內，如CPU使用率不超過20%（正常運行時間，不是軟件啓動的短暫時刻）。

網絡資源佔用，如Google Talk的語音佔帶寬大約24～32K（24000～32000bit/s）。

在較差的網絡條件下，語音與文字聊天能保持流暢。

移動應用app測試時，不只要測試其網絡流量，還要測其耗電量，耗電量和CPU的開銷也有關係。

在長時間運行（7×24小時）下，沒有內存泄漏等問題。

這些既是性能要求，也是性能測試需求，性能測試要覆蓋各項要求。

在服務器端，經過改變網絡帶寬或延遲、負載模式和大小，對一些關鍵業務（如Google日曆中登陸、提交新事項時、按月顯示、查詢等）進行測試，以獲取或驗證系統總體的性能指標。如系統要求在正常使用狀況下其響應時間爲3～5秒，即便在使用高峯期（如上下班時間）系統的響應時間也不該該超過15秒，這就意味至少要進行兩種場景——平均負載和高峯負載的性能測試。在對實際系統進行性能測試時，每每會結合其關鍵業務考慮其關鍵性能測試需求。

多人同時登陸（併發用戶活動）、設置活動時，頁面的響應速度要求在3秒以內。

經過頁面進行搜索時，查詢時間應控制在5秒之內。

設置共享時、用戶更新活動信息時，是否能快速同步，即在另外一共享好友處即刻顯示更新過的信息。

當活動/事件達到必定數量（200～1000）時，頁面響應速度要在5秒以內。

當循環會議較多時，頁面的處理速度正常（5秒以內）。

在哪些負載、測試周期（8個小時、24小時、7天等）的組合狀況下進行壓力測試。

壓力測試每每和容量測試結合起來，以測試系統的限制和故障恢復能力，如測試應用系統在長期高負載下會不會崩潰、在什麼狀況下會崩潰，並肯定系統能承受的最大負載（如最大鏈接數、併發用戶數等）。

可伸縮性一般要求在對部署體系結構的設計不作修改的狀況下增長資源以知足系統增長的容量，從而使系統容易支持來自現有用戶或擴大的用戶羣體的額外負載。可伸縮性測試也能夠歸爲性能測試，如在部署兩臺服務器時測試系統性能（容量，即最大負載），再部署四臺、八臺服務器時分別進行系統容量的測試，看其容量是否爲上次（兩臺、四臺）實驗值的兩倍或接近兩倍。若是是，系統就具備良好的可伸縮性。

2．可用性測試

可用性是指系統正常運行的能力或程度，在必定程度上也是系統可靠性的表現，可用性測試就基本上等同於可靠性測試。可用性通常用正常向用戶提供軟件服務的時間佔總時間的百分比來表示，即：

可用性 = 正常運行時間 /（正常運行時間 + 非正常運行時間） 100%

系統非正常運行時間多是因爲硬件、軟件、網絡故障或任何其餘因素（如斷電）形成的，這些因素能讓系統中止工做，或鏈接中斷不能被訪問，或性能急劇下降不能使用軟件現有的服務等。

可用性指標通常要求達到4個或5個"9"，即99.99% 或99.999%。

若是可用性達到99.99%，對於一個整年不間斷（724的方式）運行的系統，意味着整年（525600分鐘）不能正常工做的時間只有52 分鐘，不到一個小時。

若是可用性達到99.999%，意味着整年不能正常工做的時間只有5 分鐘。

因此一個系統的可用性達到99.999%，基本能知足用戶的需求。固然，不一樣的應用系統，可用性要求是不同的，非實時性的信息系統或通常網站要求都很低，可能在99%和99.5%之間，而對一些軍事系統，則要求很高，如美國防空雷達系統整年失效時間不超過兩秒，可用性高達7個"9"之上，達99.999994%。

可用性測試就比較困難，不可能有足夠的時間來進行測試，就只能採用空間換時間的辦法，例如在高負載狀況下進行爲期一週或一個月的測試，以判斷其可靠性。其次，就是對提升可靠性的措施進行測試，如故障轉移的測試。

容錯處理系統可以處理異常、錯誤操做而不至於系統崩潰，從而可以提供系統的可用性。例如，業務處理過程當中中斷事務時，系統能保存當前狀態，程序能自動或提示重連，或在某個時刻能夠恢復操做。

3．安全性測試

安全性是一個複雜的主題，涉及部署系統的各個級別。安全性要求分析，包括肯定可能的或潛在的各種安全威脅和找處處理這些威脅的策略，即：

肯定關鍵（有形的和無形的）資產，並找到對這些資產的威脅；

肯定使組織暴露於可能帶來風險威脅的薄弱環節；

開發減輕組織風險的安全規劃。

分析安全要求應由軟件組織的各方面風險承擔者參與，包括管理員、業務分析師和信息技術人員等。一般，組織會指定一個安全結構設計師來領導安全措施的設計和實現。

安全性測試就是全面檢驗軟件在需求規格說明中規定的防止危險狀態措施的有效性和在每個危險狀態下的反應，對軟件設計中用於提升安全性的結構、算法、容錯、冗餘、中斷處理等方案進行鍼對性測試，並對安全性關鍵的軟件單元和軟件部件，單獨進行增強的測試，以確認其知足安全性需求。因此，安全性測試的需求點仍是比較多的，任務仍是比較重的，特別是對複雜的系統。這裏舉一些常見的需求點：

各類登陸模式的安全性驗證、對口令各類要求的測試；

用戶權限的驗證；

全部入口的驗證，即對數據輸入的驗證；

Cookie和Session的有效期驗證等特殊機制的驗證；

數據訪問權限設置驗證，如服務器上的目錄設置；

敏感數據加密、數據存儲安全性的驗證；

驗證系統的日誌文件是否獲得保護；

在異常條件下操做、錯誤操做，測試軟件以代表不會因可能的單個或多個輸入錯誤而致使不安全狀態；

其餘各類安全漏洞（如跨站點攻擊、SQL注入等）的檢查。

4．兼容性測試

兼容性測試需求是指明確要測試的兼容環境，考慮軟、硬件的兼容，就軟件兼容來講，不只要測試系統自身的版本兼容、用戶已有數據的兼容，還要測試與操做系統、應用平臺或瀏覽器、和其餘第三方系統以及第三方數據的兼容性。操做系統包括Windows、Mac、Solaris、Linux等，瀏覽器包括IE、FireFox、Chrome和Safari等，如表2-4所示，造成環境組合矩陣，更能明確兼容性測試需求。兼容性測試的組合不只僅侷限在操做系統、瀏覽器這兩個因素，還有其餘因素，如：

32位、64位CPU；

手機平臺 Android、iOS、Windows Phone；

支持不一樣的Internet鏈接速度；

是否支持SSL。

兼容性測試須要根據被測試應用的具體狀況決定。像Google日曆應用，支持移動平臺是必須的，並且日曆有較多的我的信息，須要支持SSL，但32位、64位CPU對其沒有什麼影響，不須要考慮。而對於像Google Talk這樣客戶端應用程序，就不須要考慮瀏覽器支持，並且不一樣的操做系統（Windows、Mac OS、iOS、Android等）有不一樣的應用程序，須要單獨處理，只是每類操做系統還有多個版本，如iOS有iOS 五、iOS 6和iOS 7等。

兼容性測試，不只是軟件系統之間兼容、和第三方系統之間的兼容，並且還需考慮系統版本之間的兼容，特別是用戶數據的兼容，數據兼容測試也是重要的需求。例如：

不一樣客戶端軟件（如Google Talk）版本和服務器系統的兼容，服務器上通常部署的都是最新版本，但客戶端就不必定；

新版本的軟件可以兼容之前各類版本產生的歷史數據，確保數據向上兼容，如Word 2013 可以正常打開以前多個Word版本（如Word 2003，Word 2007等）產生的用戶.doc文件。

2.3 測試工做量估算

在肯定了測試需求、明確了測試範圍以後，就須要明確測試任務，估算測試工做量。基於質量需求和測試的工做量、測試環境、產品發佈的設想時間等要求，就能夠肯定測試進度和所需的測試資源，或者基於現有的測試資源來決定測試的日程表。

在傳統開發模式中，測試工做量估算是測試計劃的基礎工做之一，但在敏捷開發中，雖然也強烈建議有一個測試計劃，但其測試計劃簡明扼要，主要是列出測試目標、測試邊界、測試點、主要的測試風險和注意事項等。其測試任務在迭代計劃（如Scrum的Sprint Planning）會議中和開發任務一併考慮，能夠採用Scrum估算撲克牌的方式來完成估算，這樣測試工做量估算主要依賴我的經驗、團隊溝通等完成。即便是採用這種方式，對下面內容瞭解以後，有一個科學估算的基礎，在敏捷開發中依舊會發揮做用。

2.3.1 工做量的估計

測試的工做量是根據測試範圍、測試任務和開發階段來肯定的。測試範圍和測試任務是測試工做量估算的主要依據。如何肯定測試範圍已在上一節作了充分的討論，能夠根據產品需求規格說明來決定。測試任務是由質量需求、測試目標來決定的，質量要求越高，越要進行更深、更充分的測試，迴歸測試的次數和頻率也要加大，天然，測試的工做量要增大。處在不一樣的開發階段，測試工做量的差別也挺大。新產品第一個版本的開發過程，相對於之後的版原本說，測試的工做量要大一些。但也不是絕對的，例如，第一個版本的功能較少，在第二、3個版本中，增長了較多的新功能，雖然新加的功能沒有第一個版本的功能多，可是在第二、3個版本的測試中，不只要完成新功能的測試，還要完成第一個版本的功能迴歸測試，以確保原有的功能正常。

在通常狀況下，一個項目要進行2～3次迴歸測試。因此，假定一輪（Round）功能測試須要100我的日（man-day），則完成一個項目全部的功能測試確定就不止100我的日，每每須要200～300多我的日。能夠採用如下公式計算：

W ＝ Wo + Wo ? R1 + Wo ? R2 + Wo ? R3

W爲總工做量，Wo爲一輪測試的工做量。

R1，R2，R3爲每輪的遞減係數。受不一樣的代碼質量、開發流程和測試周期等影響，R一、R二、R3的值是不一樣的。對於每個公司來講，能夠經過歷史積累的數據得到經驗值。

測試的工做量，還受自動化測試程度、編程質量、開發模式等多種因素影響。在這些影響的因素中，編程質量是主要的。編程質量越低，測試的重複次數（迴歸測試）就越多。迴歸測試的範圍，在這3次中可能各不相同，這取決於測試結果，即測試缺陷的分佈狀況。缺陷多且分佈很廣的話，全部的測試用例都要被再執行一遍。缺陷少且分佈比較集中，能夠選擇部分或少數的測試用例做爲迴歸測試所要執行的範圍。

在代碼質量相對較低的狀況下，假定R一、R二、R3的值分別爲80%、60%、40%，若一輪功能測試的工做量是100我的日，則總的測試工做量爲280我的日。若是代碼質量高，通常只須要進行兩輪的迴歸測試，R一、R2值也降爲60%、30%，則總的測試工做量爲190我的日，工做量減小了32%以上。

自動化程度越高，測試工做量就越低。由計算機運行的自動化腳本效率很高，能使執行實際測試的工做量大大下降。可是在不少狀況下，測試自動化並不能大幅度下降工做量，由於測試腳本開發的工做量很大。也就是說，將整體的測試工做量前移了，從測試執行階段移到測試腳本設計和開發的階段，整體工做量沒有明顯下降。同時，因爲自動化腳本能夠重複使用，並且機器能夠沒日沒夜地運行，迴歸測試就能夠頻繁進行，如天天能夠執行一次，這樣任何迴歸缺陷均可以即時發現，提升軟件產品的質量。

工做量的估計是比較複雜的，針對不一樣的應用領域、程序設計技術、編程語言等，其估算方法是不一樣的。其估算可能要基於一些假定或定義。

（1）效率假設，即測試隊伍的工做效率。對於功能測試，這主要依賴於應用的複雜度、窗口的個數、每一個窗口中的動做數目。對於容量測試，主要依賴於創建測試所需數據的工做量大小。

（2）測試假設，目的是驗證一個測試需求所需測試的動做數目，包括估計的每一個測試用例所用的時間。

（3）階段假定，指所處測試周期不一樣階段（測試設計、腳本開發、測試執行等）的劃分，包括時間的長短。

（4）複雜度假定，應用的複雜度指標和需求變化的影響程度決定了測試需求的維數。測試需求的維數越多，工做量就越大。

（5）風險假定。通常考慮各類因素影響下所存在的風險，將這些風險帶來的工做量設定爲估算工做量以外的10%～20%。

2.3.2 工做分解結構表方法

要作好測試工做量的估算，須要對測試任務進行細化，對每項測試任務進行分解，而後根據分解後的子任務進行估算。一般來講，分解的粒度越小，估算精度越高。能夠再加上10%～15%的浮動幅度，來肯定實際所需的測試工做量。比較專業的方法是工做分解結構表（WBS），它按如下3個步驟來完成。

（1）列出本項目須要完成的各項任務，如測試計劃、需求和設計評審、測試設計、腳本開發、測試執行等。

（2）對每一個任務進一步細分，可進行多層次的細分，直到不能細分爲止。如針對測試計劃，首先可細分爲：

肯定測試目標；

肯定測試範圍；

肯定測試資源和進度；

測試計劃寫做；

測試計劃評審。

"肯定測試範圍"還可再細分爲功能性測試範圍和非功能性測試範圍的分析。"測試計劃評審"能夠再分爲測試組內評審、項目組評審、公司質量保證小組評審和最終批准。

（3）列出須要完成的全部任務以後，根據任務的層次給任務進行編號，就造成了完整的工做分解結構表（如表2-5所示）。

WBS除了用表格的方式表達以外，還能夠採用結構圖的方式，那樣會更直觀、方便，如圖2-5所示。

當WBS完成以後，就擁有了制定日程安排、資源分配和預算編制的基礎信息，這樣不只可得到整體的測試工做量，還包括各個階段或各個任務的工做量，有利於資源分配和日程安排。因此，WBS方法不只適合工做量的估算，還適合日程安排、資源分配等計劃工做。

2.3.3 工做量估計的實例

結合Google日曆的功能點能夠看出，測試工做量與測試用例的數量成比例。根據全面且細化的測試用例，能夠更準確地估計測試周期各階段的時間安排。根據Google日曆的功能計算，測試用例數爲6×60 = 360例（以平均每一個大模塊60個用例來算）。除了測試用例數，還要考慮如下因素。

根據測試團隊和項目的具體狀況來算，如2.3.3節中的幾個假定：效率假設、測試假設和應用的維數等。

測試平臺、環境的不一樣組合，包括操做系統、瀏覽器、通訊協議、防火牆、代理服務器等的組合。

迴歸測試頻率和重複次數。

自動化測試的水平。

其餘特定的因素，增長10%～20%的餘量。

在Google日曆的測試中，作以下假定和分析。

全部人員爲中級軟件測試工程師的水平。

每一個測試用例設計時間爲20分鐘，包括評審、輸入到用例管理數據庫中等所用的時間。因此測試用例設計的時間爲120小時，即15我的日。

70%的測試用例能夠進行自動化測試，30%爲手工測試。即自動化測試用例數爲252例，手工測試用例數爲108例。

每位工程師天天可開發10個測試用例的測試腳本，包括調試。因此測試腳本開發的工做量爲26我的日。

要進行兩次的迴歸測試，R一、R2值爲70%、40%，則單平臺下手工運行的測試用例數爲108×(1＋70%＋40%) ＝ 227例。

對操做系統沒有影響，並且不考慮SSL的支持，只考慮瀏覽器IE6.0、IE7.0、Firefox1.五、Firefox2.0和代理服務器的影響。做爲交叉組合，共設爲4種。

也沒有必要在4種組合上運行全部的測試用例，兩種主要組合運行100%的手工測試用例，另外兩種組合運行50%的手工測試用例，即測試用例數爲原來的3倍，因此手工運行的測試用例數爲227 × 3 ＝ 681例。

假定每一個測試工程師天天能夠運行60個測試用例，即每一個測試用例的執行要用5分鐘，運行測試用例要用5個小時，另外3個小時用於處理缺陷報告和郵件、與開發人員溝通等。因此手工測試用例執行的時間爲12我的日。

自動化測試的運行都在晚上進行，工程師須要時間分析測試結果、修改腳本適應新的變化、作缺陷報告等，估計要5我的日。

這樣就估算出了功能測試的基本工做量，即15＋26+12+5=58我的日。

對系統測試的工做量，能夠按照一樣的方法進行，所不一樣的是系統測試幾乎是由測試工具完成的，工做量主要集中在環境構建、測試數據準備和結果分析等上面。表2-6給出了Google日曆所要的測試工做量。

2.4 測試資源需求

分析測試範圍以後，所須要的測試資源就比較清楚了。測試的資源需求，包括人力資源和軟、硬件資源。人力資源，側重如何組建測試團隊——項目測試組，而軟、硬件資源，對於不一樣的項目差別很大。這裏只討論通常的操做方法，設計測試環境的創建，將在第七、第9章進行詳細介紹。

若是將測試資源進行較爲詳細的分類，能夠概括爲如圖2-6所示。

1．人力資源需求

在完成了測試工做量的估算以後，軟件測試項目所需的人員數目就可以基本肯定了。軟件測試項目所需的人員和要求在各個階段是不一樣的。

（1）在初期，測試組長首先要介入進去，參與需求評審、肯定測試需求和測試範圍、制定測試策略和測試計劃等。

（2）在測試前期，須要一些比較資深的測試設計人員、測試腳本或測試工具開發人員參與或負責軟件測試需求的制定和分解、設計測試用例、開發測試腳本等工做。

（3）在測試中期，主要是測試的執行，測試需求的數量取決於測試自動化實現的程度。若是測試自動化程度高，人力的投入則不須要明顯的增長；若是測試自動化程度低，對執行測試的人員要求就比較多了。

（4）在測試後期，資深的測試人員能夠抽出部分時間去作新項目的準備工做。

2．測試環境資源

把創建全部必要的測試環境所需的計算機軟件資源和硬件資源合稱爲測試環境資源。硬件提供了一個支持操做系統、應用系統和測試工具等運行的基本平臺，軟件資源包括操做系統、第三方軟件產品、測試工具軟件等，具體以下。

硬件：交換機、路由器、負載均衡器（Load balance）、服務器、客戶端PC、攝像頭、特殊的顯示卡和聲卡、耳機、麥克風等。

支撐的系統軟件：Linux操做系統、Web服務器（如Apache）、中間件（如Tomcat、WebLogic）、數據庫系統軟件MySQL/Oracle等。

測試工具：JUnit、JMeter、Selenium、IBM-Rational Robot等。

2.5 測試里程碑和進度安排

軟件測試貫穿軟件產品開發的整個生命週期，從產品的需求分析審查到最後的驗收測試，直至軟件發佈。從測試實際的先後過程來看，軟件測試的過程是由一系列不一樣的測試階段組成的，這些階段主要有：需求分析審查、設計審查、單元測試、集成測試（組裝測試）、功能測試、系統測試、驗收測試、迴歸測試（維護）等。在軟件測試項目的計劃書中，須要給各個階段制定一個明確的開始和結束時間，這就是一般所說的日程進度表（schedule）。項目進度安排，實際上取決於測試工做量和現有的人力資源。當人力資源充足時，測試周期短；當人力資源較少時，測試周期就會長。

里程碑通常是項目中完成階段性工做的標誌，即用一個結論性的標誌來描述一個過程性任務明確的起止點，進度安排就是肯定里程碑的起止點。一個里程碑標誌着上一個階段結束、下一個階段開始，也就是定義當前階段完成的標準（Entry Criteria）和下一個新階段啓動的條件或前提（Entry Criteria）。里程碑具備很強的時序性，還具備下列特徵。

里程碑也是有層次的，在一個父里程碑的下一個層次中定義子里程碑。

不一樣類型的項目，里程碑可能不一樣。

不一樣規模項目的里程碑，其數量的多少不同，里程碑能夠合併或分解。

2.5.1 傳統測試

在軟件測試周期中，建議定義下列6個父里程碑。

（1）M1：需求分析和設計的審查。

（2）M2：測試計劃和設計。

（3）M3：代碼（包括單元測試）完成。

（4）M4：測試執行。

（5）M5：代碼凍結。

（6）M6：測試結束。

每一個里程碑再劃分爲子里程碑，若是項目週期很長，還能夠對每一個子里程碑進一步劃分爲更小的里程碑，以利於更有效的控制，如表2-7所示。

2.5.2 敏捷測試

在本書一開始的引言中，以Scrum爲例，簡要闡述了敏捷測試流程。而在敏捷測試項目中，如何明確測試的里程碑呢？萬變不離其宗，敏捷測試也須要從測試計劃到測試設計、再到執行，只是測試設計和執行的界限不那麼分明，測試設計和執行每每交替或並列地開展。在敏捷測試中，甚至能夠不須要測試用例，而是針對Use Case 或User Story直接進行驗證，並進行探索性測試。而節約出來的時間，用於開發相對穩定功能的自動化測試腳本，爲後期的迴歸測試服務。自動化測試腳本將代替測試用例，成爲軟件組織的財富。原有測試規範還要求進行兩輪迴歸測試，在敏捷測試中，只能進行一輪迴歸測試。綜合上述考慮，敏捷測試的實際操做流程如圖2-7所示，簡單有效。

在這樣的流程中，大框架也沒有什麼不一樣，並且各項測試件（測試計劃、需求、自動化腳本等）的評審仍是須要的，只是沒有明確的評審階段，測試是一個持續的質量反饋過程，階段性不那麼突出，但仍是能夠設定一些控制點，即里程碑：

（1）測試任務定義；

（2）測試計劃制定和評審經過；

（3）測試需求或測試點（或測試場景）列代表確和評審經過；

（4）驗收測試結束。

2.6 測試風險分析

在1.1.4節討論了測試的風險觀點，測試被定義爲"對軟件系統中潛在的各類風險進行評估的活動"，這意味着軟件測試有較高的風險，因此軟件測試的風險分析很是重要。軟件測試風險，就是要將測試範圍、測試過程當中的風險識別出來，肯定哪些是可避免的風險，哪些是不可避免的，對可避免的風險要儘可能採起措施去避免。

風險識別的有效方法是創建風險項目檢查表，按風險內容進行逐項檢查、逐個確認。對於測試的風險，能夠給出以下一個風險項目檢查表，如表2-8所示。

在測試風險分析中，逐項檢查，確認風險以後，要找出對策，以免風險產生或下降風險所帶來的影響。表2-9給出了軟件開發中常見的風險，說明這些風險發生的可能性、對測試的影響和影響程度以及如何進行預防和控制。

下面會針對本書的兩個典型案例給出簡單的風險分析。客戶端軟件的測試風險相對來講會低一些，因此不作討論。並且本書對軟件測試中廣泛存在的風險也不作討論。

1．Google Talk的幾個測試風險

若是基本功能方面的問題太多，將嚴重影響性能壓力測試的進度。

在第二輪測試後，產品應該基本無大的問題。開發要在第三輪測試開始前保證修復好全部已發現的主要問題。

多語言版的測試要求測試人員前期準備充分，測試人員對所測語言有可能不太瞭解，對該語言國家的使用習慣也不是很熟悉。

開發人員拿出產品的初版本時，要提供或與測試人員共同完成壓力測試工具的開發。

2．Google日曆的測試風險

（1）項目複雜度。因爲開始對項目的複雜度估計不足，致使項目後期的產品代碼不能按時完成，這樣勢必會影響到測試的環節。

（2）需求的變化。用戶的反饋、市場需求的變化會致使項目後期增長一些新的產品功能，這樣就會使產品不能按照原定的測試計劃完成，以至測試人員處於等待狀態中。

（3）服務器的升級。基於Web方式的產品，隨着不斷推出的新服務器產品（如Linux和Apache的版本升級），其兼容性須要驗證，並且其安全性、穩定性和性能等方面所受到的影響須要分析，在測試過程當中更換第三方產品的新版本，就要面臨這樣一個問題——是否要從新測試已測試的範圍。每每不會從頭再來，而是根據已定義的策略進行選擇性的測試。

（4）數據庫的升級。基於Web方式的產品，後臺通常都離不開數據庫的支持。若是測試過程當中遇到數據庫表結構的變化、版本升級（例如Oracle 9i升級到Oracle 10G），都會給測試過程帶來風險。例如，升級後的數據庫變得不穩定，有可能退回到原來的版本，影響測試甚至致使測試的失敗。

（5）測試環境的不穩定性。例如被測試的服務器不能被訪問，須要從新啓動和配置，這會佔用必定的時間。一旦不能訪問測試環境，測試人員不只無事可作，還經常會抱怨。這種狀況影響了測試人員的情緒，最終也影響了測試結果。

（6）國際化和本地化的影響。如支持哪些語言版本？國際化版本的測試策略和方法、翻譯公司是否能及時完成任務，以及翻譯是否準確也會帶來風險。

3．測試風險的控制方法

（1）根據風險發生的機率和帶來的影響肯定風險的優先級，而後採起措施避免那些能夠避免的風險。如測試環境不對，能夠事先列出要檢查的全部條目，在測試環境設置好後，由其餘人員按已列出條目逐條檢查。

（2）風險轉移。有些風險帶來的後果可能很是嚴重，可否經過一些方法，將它轉化爲其餘一些不會引發嚴重後果的低風險。如產品發佈前發現某個不是很重要的新功能給原有的功能帶來了一個嚴重的Bug，這時處理這個Bug所帶來的風險就很大。對策是去掉那個新功能，轉移這種風險。

（3）有些風險不可避免，就設法下降風險。如"程序中未發現的缺陷"這種風險老是存在，就要經過提升測試用例的覆蓋率來下降這種風險。

（4）爲了不、轉移或下降風險，事先要作好風險管理計劃。例如，把一些環節或邊界上有變化、難以控制的因素列入風險管理計劃中。

（5）對風險的處理還要制定一些應急的、有效的處理方案。例如，爲每一個關鍵性技術人員培養後備人員，作好人員流動的準備，採起一些措施確保人員一旦離開公司，項目不會受到嚴重影響，仍能夠繼續下去。對全部過程進行平常跟蹤，及時發現風險出現的徵兆，避免風險。

（6）在作計劃時，估算資源、時間、預算等要留有餘地，不要用到100%。

（7）制定文檔標準，並創建一種機制，保證文檔及時產生。對全部工做多進行互相審查，及時發現問題。

知識點:

風險管理的基本內容有兩項：風險評估和風險控制（如圖2-8所示）。

（1）風險評估，主要依據三個因素：風險描述、風險機率和風險影響。能夠從成本、進度及性能三個方面對風險進行評估，它是在創建在風險識別、風險分析和風險排序基礎上的。經過評估能夠肯定這些風險的特色或可能帶來的危害。

（2）風險控制，制定風險管理計劃和風險應急處理方案，來下降風險和消除風險。

2.7 制定有效的測試策略

爲了最大限度地下降測試風險，儘早地發現各類潛在的軟件缺陷，在測試實施以前，測試組必須肯定合適、有效的測試策略，並以此爲依據選定測試方法、測試工具和測試用例設計思想。經過制定測試策略來指導測試用例的設計、測試工具的選擇和執行，特別是能解決測試當中常常碰到的一些問題。良好的測試策略必將給軟件測試帶來事半功倍的效果，能夠充分利用有限的人力和物力資源，高效地完成測試目標。

測試策略描述當前測試項目的目標和所採用的測試方法，針對某個應用軟件系統或程序，具體的測試項目要達到的預期結果還包括在規定的時間內哪些測試內容要完成，軟件產品的特性或質量在哪些方面獲得確認。測試策略還要描述測試不一樣階段（單元測試、集成測試、系統測試）的測試對象、範圍和方法，以及每一個階段內所要進行的測試類型（功能測試、性能測試、壓力測試等）。其內容包括以下。

對測試的公正性、遵守的標準作一個說明，證實測試是客觀的，軟件功能要知足總體需求，實現正確，並與用戶文檔的描述保持一致。如聲明測試完成的標準是95%的測試用例經過而且兩個最高級別的缺陷所有被修正，用以計劃、實施及通報測試結果。

描述測試用例是什麼樣的，如何執行，用了什麼樣的數據，又如何執行後續的迴歸測試。

選定要使用的測試技術和工具。如採用了什麼工具，工具的來源是什麼，是否60%用Rational Robot自動測試、40%用手工測試。

根據經驗判斷和頭腦風暴，對以往測試中常常出現的問題加以考慮。又如採起一些發散性的思惟，每每能幫助找到新的測試途徑。

考慮影響資源分配的特殊狀況。例若有些測試必須在週末進行，有些測試必須經過遠程環境執行，有些測試須考慮與外部或硬件的接口。

爲了更好地肯定軟件測試策略，能夠試着問以下一些問題，在尋找這些答案的過程當中，也就找到了最佳的測試策略。

迴歸測試的範圍如何肯定？

如何利用可重複性的測試？

測試缺少可預見性，如何收集衡量測試結果的指標？

如何創建穩定的、模擬系統實際運行的測試環境？

如何從無窮的輸入數據中選擇合理的、有效的測試數據集？

如何增強靜態測試——規格說明書、設計文檔和程序代碼等的審查？

如何處理單元測試和集成測試的關係？

如何處理手工測試和自動化測試之間的平衡，使它們的互補性獲得發揮，使測試的效率和質量達到最佳狀態？

如何衡量這種測試策略的有效性？

1．測試策略制定的三項基本要素

軟件測試策略制定有三項基本要素：輸入、輸出和過程。

（1）輸入，做爲制定測試策略的依據，包括限制條件和已具備的資源：

所要求的軟、硬件的詳細說明，包括測試環境、測試工具等；

人力資源和測試進度的約束，包括測試組成員的角色和職責說明；

測試方法和衡量測試是否經過的標準；

被測軟件組件或系統的功能性和技術性需求文檔，及其變動請求的控制流程；

軟件系統所受到的其餘限制。

（2）輸出，制定策略的成果，即最終對所制定策略的定義或說明：

經過/失敗的準則和測試風險評估的結果；

已批准和簽署的測試策略文檔；

和測試策略相對應的測試計劃、測試用例的設計思想和思路。

（3）制定策略的過程。測試組分析需求，參與設計的討論，要求開發、編寫針對全部測試級別的測試策略，並和項目組一塊兒複審測試策略和測試計劃。測試策略應該覆蓋整個項目的生命週期，須要各種技術人員（系統架構師、數據庫管理員、編程人員等）參與。各種技術人員相互之間應多交流、討論，以保證制定正確的測試策略。

2．基於測試技術的測試策略

著名的軟件測試專家Myers指出了使用各類測試方法的綜合策略。

在任何狀況下都要使用邊界值分析方法，由於爲邊界值分析方法所設計的測試用例能頗有效地發現軟件代碼的缺陷。

等價類劃分方法是對邊界值分析方法的有效補充。

若是軟件某些功能的輸入數據/條件存在多種組合狀況，則一開始就可選用因果圖法。

錯誤推測法能夠幫助追加一些比較特殊、不易直接推理出來的測試用例。

對照程序邏輯來審查已有測試用例的邏輯覆蓋程度。若是沒有達到要求的覆蓋率，則應當再增長一些測試用例。

儘管用戶更傾向於基於程序規格說明的功能測試，可是白盒測試能發現潛在的邏輯錯誤，而這種錯誤每每是功能測試發現不了的。

3．分階段的測試策略

嚴格地執行代碼複查，以保證在早期就發現問題，而不是在代碼發佈以後。

利用單元測試和集成測試，能夠儘早地發現更多的問題，並準備好自動化測試的BVT（Build Verification Test，軟件包驗證測試）。

須要創建一個正規的且自動化的冒煙測試，只有100%經過冒煙測試，才能進入下一個階段。

系統測試中，以每次發佈用戶基線爲結束標誌，用戶基線會增加，同時也會逐漸地要求一些更爲精確的性能測試。

不能忽略安全性測試、可用性測試、配置測試和數據完整性測試。

在功能性測試、安全性測試、配置測試中可進行一些探索性測試。

制定更爲詳細的UAT（用戶驗收測試）測試計劃，將其與測試腳本和培訓材料一塊兒提供給用戶，以幫助用戶快速提升並完成任務。

4．基於測試方案的綜合測試策略

（1）根據軟件產品或服務特性對客戶的使用價值以及特性失效所形成的損失，來肯定相應特性的測試優先級。產品特性的優先級越高，其被測試的時間越早，測試的力度也越大。

（2）要使用盡量少的測試用例，發現儘量多的程序錯誤。一次完整的軟件測試事後，若是程序中遺漏的（較）嚴重錯誤過多，則代表本次測試是不足的或失敗的，這意味着可能讓用戶承擔較大的利益損失風險。反過來講，若是過分測試，則又會浪費軟件企業自身的寶貴資源。因此，須要在以上兩點——風險和效率上進行權衡，找到一個最佳平衡點。

（3）測試策略應該儘可能的簡單、清晰，例如能夠在有限的白板上經過2～3行字和1～2個圖就描述出測試策略來，或者能夠經過一個簡短的會議（20～30分鐘），就能把測試策略解釋清楚。

（4）基於缺陷分析的測試策略。經過缺陷分析，能夠更好地瞭解開發人員的習慣，找到容易犯錯誤的地方，能夠更好地設計測試用例，更快地發現缺陷。也能夠從缺陷出發，反推回去，找到合適的測試策略。

5．測試策略的示例

在Google日曆的測試項目中，要考慮在瀏覽器和操做系統的不一樣組合下進行測試。最簡單的辦法就是完成全部組合的測試，如5個操做系統（Windows 2010 server、Windows 七、Windows 八、Mac 10.八、Linux）和7個瀏覽器（IE八、IE九、某個中文、Chrome、Firefox、Opera、Safari）的組合有近35種——由於有些組合是不多出如今實際的環境中。之前面所說的360個測試用例爲基礎，在各類環境上共要執行12 600多個測試用例，工做量太大。這時就須要根據操做系統和瀏覽器的市場佔有率、對測試用例的影響程度、缺陷分析的結論和經驗等，簡化或優化組合。從表2-10能夠看出，等價組合降到了8，只要執行大約2880個測試用例，測試的工做量大大減小。

針對Google日曆這樣的產品，還能夠制定針對功能性和用戶界面的測試策略。如按照Google日曆的功能劃分來設計測試用例，保證一系列的邏輯被有效地驗證。

輸入時間或活動的組合（不一樣長度和單雙字節的字符串長度）。

在相同的時間或活動在不一樣日曆裏面的顯示和跳轉（用戶界面）。

改變用戶的不一樣設置。

測試上述的功能在不一樣的分辨率和上述操做系統、瀏覽器的組合。

概念

（1）冒煙測試（Smoke Testing）是在代碼被檢查進入（check in）代碼庫以前對代碼修改進行驗證的流程或活動。在代碼複審（code reviews）以後，冒煙測試是識別和修正軟件缺陷的最有效方法。它能夠確認代碼的修改符合要求和指望，且不會形成軟件包構建的失敗。冒煙測試和自動化迴歸測試的腳本集一塊兒被用來測試那些高風險的功能或高容量的事務處理。

（2）BVT（Build Verification Test）是軟件包構造以後由測試工具（腳本）完成的驗證測試，用以確認基本功能正常，沒有出現嚴重的缺陷。BVT經過後，才進行手工測試，或者進一步的自動化測試。

2.8 完整生成測試計劃書

在軟件測試需求和測試範圍分析、工做量估計、測試資源和進度安排、測試風險評估、測試策略制定等工做作完以後，測試計劃也就基本大功告成了。測試計劃自己就是爲了解決測試目標、任務、方法、資源、進度和風險等問題，因此當這些問題被解決或找到相應的對策和處理措施以後，測試計劃剩下的工做就是寫好這個文檔，將上述內容描述清楚。有一點必須在這裏說明的是，測試計劃是一個過程，不只僅是"測試計劃書"這樣一個文檔，測試計劃會隨着狀況的變化不斷進行調整，以便於優化資源和進度安排，減小風險，提升測試效率，並及時修改"測試計劃書"。

在計劃書中，有些內容是介紹測試項目的背景、所採用的技術方法等的，這些內容僅僅做爲參考，但有些內容（如人員組成、日程安排）也能夠看做是一種結論，或者承諾，是必需要實施或達到的目標，如測試小組的結構和組成、測試項目的里程碑、面向解決方案的交付內容、項目標準、質量標準、相關分析報告等。測試計劃內容的焦點則集中在下列內容上。

（1）目標和範圍：包括產品特性、質量目標，各階段的測試對象、目標、範圍和限制。

（2）項目估算：根據歷史數據和採用恰當的評估技術，對測試工做量、所需資源（人力、時間、軟硬件環境）作出合理的估算。

（3）風險計劃：對測試可能存在的風險進行分析、識別，以及對風險的迴避、監控和管理。

（4）進度安排：分解項目工做結構，並採用時限圖、甘特圖等方法制定時間/資源表。

（5）資源配置：人員、硬件和軟件等資源的組織和分配包含每個階段和每個任務所須要的資源。人力資源是重點，並且與日程安排聯繫密切。當發生相似到了使用期限或者資源共享的時候，要及時更新這個計劃。

（6）跟蹤和控制機制：包括質量保證和控制、變化管理和控制等，明確如何準備去作一個問題報告以及如何去界定一個問題的性質，問題報告要包括問題的發現者和修改者，問題發生的頻率，是用什麼樣的測試用例測出該問題的，以及明確問題產生時的測試環境。

測試計劃書的內容也能夠按集成測試、系統測試、驗收測試等階段去組織。爲每個階段制定一個計劃書，還能夠爲每一個測試任務/目的（安全性測試、性能測試、可靠性測試等）制定特別的計劃書。

同時，能夠爲上述測試計劃書的每項內容制定一個具體實施的計劃，如將每一個階段的測試重點、範圍、所採用的方法、測試用例設計的思想、提交的內容等進行細化，供測試項目組的內部成員使用。對於一些重要的項目，會造成一系列的計劃書，如測試範圍/風險分析報告、測試標準工做計劃、資源和培訓計劃、風險管理計劃、測試實施計劃、質量保證計劃等。對於更爲詳細的要求，能夠參考國家標準《測試計劃（GB8567—88）》中制定的測試計劃通用模板。

2.9 小結

本章主要討論測試需求和如何建立有效的測試計劃。測試需求包括功能測試需求和非功能性測試需求，而非功能性測試需求包括性能、安全性、可靠性、兼容性、易維護性和可移植性等測試需求。對於非功能性測試需求，既要獨立考慮它們各自的特色和各自的測試需求，也要考慮它們之間的關係和相互影響，例如安全性和可靠性密切相關，越安全越可靠，越可靠越安全。而安全性會增長許多保護措施，每每會下降性能。在整個系統測試需求分析時，不只要考慮來自總體系統的測試需求，還要考慮系統數據、外部接口等測試需求，如圖2-9所示。

在測試計劃過程當中，主要作好下列各項工做。

肯定軟件功能性、非功能性的測試需求，以及各個階段的測試任務。

進行測試範圍分析，從而對測試工做量進行估算。工做量估算方法主要介紹工做分解結構表方法，並給出了實例。

測試資源需求、團隊組建，包括培訓。

測試里程碑和進度的安排。

對測試風險進行分析。

制定有效的測試策略。

最後完整地生成測試計劃書，進行計劃書的評審、跟蹤和及時修改，測試計劃是一個過程，不只僅是"測試計劃書"這樣一個文檔，測試計劃會隨着狀況的變化不斷進行調整，用以優化資源和進度安排，下降風險，提升測試效率。

——————本文節選自《全程軟件測試（第2版）》

可能您還對如下內容敢興趣：

ERP項目的效益分析

如何評價ERP項目的經濟效益？