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

時間 2019-11-14

原文原文鏈接

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

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

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

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

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

2.1.1 質量要求

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

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

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

? 通話正常、穩定。架構

? 通話質量要有必定保障。併發

? 待機時間長。 app

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

? 外觀大氣美觀，不要過重。

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

? 支持手寫輸入功能。

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

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

? 每項功能符合實際要求。

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

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

? 系統的界面清晰、美觀。

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

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

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

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

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

? 支持各類應用的環境。

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

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

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

用戶界面（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、1、2、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 5、iOS 6和iOS 7等。