1、Next Different 改變下一站 測試需求分析測試需求分析Next Different 改變下一站目錄測試需求概要測試需求概要 什么是什么是測試需求測試需求 測試需求的特征測試需求的特征 為什么需要測試需求為什么需要測試需求測試需求分析過程測試需求分析過程 測試需求采集測試需求采集 測試需求分析測試需求分析 測試需求評審測試需求評審2Next Different 改變下一站需求? 背景：馮大勇吃魚時嗓子被魚刺卡住了。現在正坐在椅子上候診。 大夫：（在桌上拿起一份掛號單，大聲的喊）馮大勇！ 馮大勇：（病怏怏的樣子，邊走邊咳嗽）我是。 大夫：怎么了？（低頭整理手中的資料，自言自語，并打手勢

2、，示意馮大勇坐下） 馮大勇：我.咳嗽.我今天.咳嗽. 大夫：不用說了，我知道了。（從桌子下面拿出一個大盒子，放在桌 子上） 我看你適合吃這種藥。這是本院獨家開創的哮喘新藥“咽喉糖漿”，療程短，見效快，一個療程吃3盒，平均每天只需花費3塊錢。給你先開6盒吧！（邊說邊開藥方） 馮大勇非常驚訝地瞪大眼睛并止不住地彎腰大聲咳嗽，以至于把魚刺都咳出來了。馮大勇從口里掏出一條巨型魚刺，遞給醫生。醫生見到魚刺先是吃驚，而后又非常尷尬。Next Different 改變下一站 測試需求主要解決“測什么”的問題 ，即細化被測對象。 測試需求通常是以軟件開發需求為基礎進行分析，通過對開發需求的細化和分解，形成可測

3、試的內容。 測試需求應全部覆蓋已定義的業務流程，以及功能和非功能方面的需求。4什么是測試需求？什么是測試需求？Next Different 改變下一站什么是需求 需求是產品必須完成的事以及必須具備的品質。分分類：類：顯式需求顯式需求：明確定義的一系列約束軟件實現的要求。隱式需求隱式需求：并不是需求設計人員特意隱藏，更多的是由理解人員對某方面專業知識，或對產品的業務了解程度有限導致的。5Next Different 改變下一站需求分析沒有做好的后果一般會有下列現象：浪費時間和資源來滿足用戶并不需要的需求（過度實現一些功能）總是需要比較長的時間來達成對產品設計的共識員工會厭倦因需求不斷被重新解釋而

4、導致的返工不穩定的產品，用戶的不滿意對我們未來的市場造成損失開發出來的產品技術上先進，但并不滿足用戶需求在產品設計，開發和測試對于用戶需求的解釋不一致未說明的或不正確的需求會導致員工與用戶間的不滿浪費時間，增加成本，使得在一些投標的項目中不能低價Next Different 改變下一站需求分析的重要性 如果你在編碼的時候發現某幾行有誤，那么改掉這幾行就行了。而如果在編碼階段發現需求有誤，那么你很可能需要改變所有代碼來適應新的需求 在需求階段消除問題的代價最小，而如果需求問題等到產品發布出去后才發現的話，那修復的成本就會N倍的增加。 穩定的需求是軟件開發的關鍵。有了穩定的需求，軟件開發工作可能從

5、結構設計到詳細設計到代碼到測試都會平穩順利的進行。開頭錯開頭錯-全盤錯全盤錯-全盤輸全盤輸Next Different 改變下一站如何進行需求分析 一般可以從三個方面去考慮：1.功能需求2.非功能性需求3.限制條件了Next Different 改變下一站功能性需求 功能性需求是產品必須完成的那些事，要求一定的功能和品質。例： 培訓機構的班主任可以給所在班級學員打考勤9Next Different 改變下一站非功能性需求 非功能性需求是產品必須具備的屬性或品質。諸如觀感、可用性、安全性和法律限制等。 例： 平臺用戶數為5萬人,每天登錄用戶數為1000左右，網絡的帶寬為100M帶寬。在工作時間根

6、據資料名稱條件進行搜索，可以在3秒內得到搜索結果。 這類需求通常在產品的功能確定之后，一旦知道了產品要做的事情，就可以確定它的行為方式，它需要具備什么品質以及它的響應速度、可用性、可讀性和安全性。10Next Different 改變下一站限定條件 限制條件是全局性的需求。它們可以是對項目本身的限制,或是對產品最終設計的限制。 例： 南京平臺必須在2010年開學的第一學期上線 客戶是在說，如果顧客不能在給定的時間前使用該產品，那么它就沒有什么用了。其效果是需求分析師必須對需求進行限制，只包括那些在最后期限前能夠提供最大價值的需求。Next Different 改變下一站需求分析的步驟 熟悉需求

7、背景及商業目標： 1) 了解清楚項目發起的原因，是為了解決用戶的什么問題。 2) 當前的解決方案是不是最優的，為什么會這樣做？Next Different 改變下一站 業務模型法：業務模型法： 1) 考慮本項目與外部系統的交互，劃分系統邊界（除了本項目的需求中要求做的事情，其他的都可以是外部系統，本系統和外部系統之間的交互就是系統的邊界），可以參考系統分析說明書。 2) 確定測試范圍和關注點。系統的邊界是測試的重點，特別需要關注邊界交互時的數據交互13Next Different 改變下一站需求審查點 易讀性 二義性 一致性 統一性 是否存在需求過度或不合理 Next Different 改變

8、下一站測試人員在需求階段應做哪些工作 用戶的需求是否恰當的描述用戶的需求是否恰當的描述 如果不恰當，那么是否要確認這里存在一個隱患，用戶可能會在開發的后期突然要求讓你的需求變動，所以要事先明確好 一.是用戶是否真的能正確地描述自己的需求； 二.是需求人員是否真的能正確地理解需求。 三.是需求文檔被正確的撰寫Next Different 改變下一站 制定的測試需求項必須是可核實的。即它們必須有一個可觀察、可評測的結果，無法核實的需求不是測試需求；即-期望輸出。 測試需求應指明滿足需求的正常的前提條件，同時也要指明不滿足需求時的出錯條件。 測試需求不涉及具體的測試數據，測試數據設計是測試設計(用例

9、設計)環節應解決的內容。16測試需求的特征測試需求的特征Next Different 改變下一站 軟件測試需求是開發測試用例的依據。 有助于保證測試的質量與進度。 測試需求是衡量測試覆蓋率的重要指標。17為什么需要測試需求為什么需要測試需求Next Different 改變下一站測試需求分析過程測試需求分析過程Next Different 改變下一站 a）對原始測試需求列表中列出的每一條開發需求，形成可測試的分層描述的測試要點； b）對步驟a）所確定的測試要點，分析測試執行時需要實施的測試類型； d）建立測試需求跟蹤矩陣，對測試需求進行管理。測試需求分析測試需求分析Next Different

10、 改變下一站 需求采集的過程是將軟件開發需求中的那些具有可測試性的需求或特性提取出來，形成原始測試需求。 一句話定義：可測試性是指這些提取的需求或特性必須存在一個可以明確預知的結果(期望輸出)，可以用某種方法對這個明確的結果進行判斷(實際輸出)、驗證，驗證是否符合文檔中的要求。 需求采集需求采集Next Different 改變下一站 需求采集的提取方法：a)通過列表的形式對軟件開發需求進行梳理，形成原始測試需求列表，列表的內容包括需求標識、原始測試需求描述、信息來源。b)需求標識：產品版本號/功能模塊版本號/LOGOc)將每一條軟件需求對應的開發文檔及章節號作為軟件需求標識。d)使用軟件需求

11、的簡述作為原始測試需求描述。e)軟件需求獲取的來源信息作為信息來源。需求采集需求采集Next Different 改變下一站 提取的原始測試需求中，可能存在重復和冗余，在提取原始測試需求過程中，可以通過以下方法整理原始測試需求：a）刪除：刪除原始測試需求表中重復的、冗余的含有包含關系的原始測試需求描述；b）細化：對太簡略的原始測試需求描述進行細化；c）合并：如果有類似的原測試始需求，在整理時需要對其進行合并。 需求采集需求采集Next Different 改變下一站“人力資源管理系統人力資源管理系統”原始測試需求表原始測試需求表序號序號軟件需求標識軟件需求標識原始測試需求描述原始測試需求描述信

12、息來源信息來源13.1.1基本信息管理增加員工信息人事部門招聘專員對于新招聘的職員信息可以錄入到HRMIS系統中，主要職員信息如下：姓名、性別、出生日期、政治面貌、文化水平、婚姻情況、家庭住址、身份證號、辦公電話、移動電話、緊急情況下的聯系人和聯系方式、畢業院校、入職時間、崗位及職責，其中，性別包含男、女兩個類別；婚姻情況包括未婚、已婚、離異三種情況 。 人力資源管理系統業務需求說明書刪除員工信息刪除需用戶確認，可以逐條刪除或多條一次刪除GB/T 17544-199823.2.2時間特性要求并發15個用戶，平均登錄時間小于10秒 人力資源管理系統業務需求說明書3隱含需求：在使用中操作錯誤的易恢

13、復性程序應對關鍵數據的操作給出警告或在執行前確認GB/T 17544-1998需求采集需求采集-舉例舉例Next Different 改變下一站測試需求分析測試需求分析Next Different 改變下一站 測試要點是對原始測試需求表每一條開發需求的細化和分解，形成的可測試的分層描述的軟件需求。 對開發需求的細化和分解具體包括：a）通過分析每條開發需求描述中的輸入、輸出、處理、限制、約束等，給出對應的驗證內容；b）通過分析各個功能模塊之間的業務順序，和各個功能模塊之間傳遞的信息和數據（功能交互分析） ，對存在功能交互的功能項，給出對應的驗證內容。 ）測試要點分析測試要點分析Next Diff

14、erent 改變下一站 功能交互分析 測試要點分析測試要點分析Next Different 改變下一站 進行細化和分解還需考慮：a）需求的完整性，經過分解獲得的需求必須能夠充分覆蓋軟件需求的各種特征（包括隱含的特征），每個需求必須可以獨立完成有意義的功能或功能組合，可以進行單獨測試；b）需求的規模，每個最低層次的需求能夠使用數量相當的測試用例來實現。測試要點分析測試要點分析Next Different 改變下一站測試要點分析測試要點分析-舉例舉例Next Different 改變下一站 不同的質量子特性可以確定出不同的測試內容，這些測試內容可以通過不同的測試類型來實施。 軟件測試可以劃分為以下

15、測試類型：功能測試、安全性測試、接口測試、容量測試、完整性測試、結構測試、用戶界面測試、負載測試、壓力測試、疲勞強度測試、恢復性測試、配置測試、兼容性測試、安裝測試等。 根據質量子特性的定義，以及各測試類型的測試內容，可以分析出質量子特性與測試類型的對應關系。 分析測試類型分析測試類型Next Different 改變下一站質量子特性和測試類型的對應關系基準表 分析測試類型分析測試類型Next Different 改變下一站分析測試類型分析測試類型-舉例舉例Next Different 改變下一站分析測試類型分析測試類型-舉例舉例Next Different 改變下一站 為了避免遺漏，在確定測

16、試類型時，還需考慮：a）文檔中是否包含測試類型相對應的情況的說明；b）列出的常見測試類型是否已完全覆蓋了被測軟件；c）被測軟件的某些特殊情況是否已包含在所列出的測試類型中。分析測試類型分析測試類型Next Different 改變下一站 建立測試需求跟蹤矩陣，對測試需求進行管理。將上述步驟分析、確定的開發需求、測試需求、測試類型填入測試跟蹤需求矩陣。 測試需求跟蹤矩陣為原始測試需求與測試要點的對應關系表，格式如下： 測試需求跟蹤矩陣測試需求跟蹤矩陣Next Different 改變下一站 建立測試需求跟蹤矩陣，對測試需求進行管理。將上述步驟分析、確定的開發需求、測試需求、測試類型填入測試跟蹤需

17、求矩陣。 通過測試需求跟蹤矩陣的方式對需求變更實施。軟件需求一旦發生變化，就要對需求跟蹤表進行維護，啟動配置管理過程，將與軟件需求變更相關的內容進行同步變更。 測試需求跟蹤矩陣測試需求跟蹤矩陣Next Different 改變下一站增加培訓信息測試需求跟蹤矩陣測試需求跟蹤矩陣-舉例舉例Next Different 改變下一站增加培訓信息測試需求跟蹤矩陣測試需求跟蹤矩陣-舉例舉例Next Different 改變下一站 測試需求跟蹤矩陣需要不斷的維護。 a）一方面，軟件需求一旦發生變化，應啟動配置管理過程，將與軟件需求變更相關的內容進行同步變更；b）另一方面，隨著測試工作的進行，會不斷添加新的跟

18、蹤內容，對跟蹤表進行擴展。例如，測試設計階段的測試用例、測試執行階段的測試記錄和測試缺陷都可以添加到跟蹤矩陣中。 測試需求跟蹤距陣測試需求跟蹤距陣Next Different 改變下一站 評審的內容： a）完整性審查：應保證測試需求能充分覆蓋軟件需求的各種特征，重點關注功能要求、數據定義、接口定義、性能要求、安全性要求、可靠性要求、系統約束等方面，同時還應關注是否覆蓋開發人員遺漏的、系統隱含的需求；b）準確性審查：應保證所描述的內容能夠得到關各方的一致理解，各項測試需求之間沒有矛盾和沖突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設計的依據。 測試需求評審測試需求評審Next Different 改變下一站評審的形式評審的形式a a）相互評審、交叉評審：）相互評審、交叉評審： 甲和乙在一個項目組，處在一個領域，但工作內容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查。相互評審是最不正式的一種評審形式，但應用方便、有效。測試需求評審測試需求評審Next Diff