單元二-任務(wù)一-將軟件需求轉(zhuǎn)化為測試需求.ppt

單元二、計劃測試工作,任務(wù)一、根據(jù)需求分析明確測試需求與任務(wù),能夠區(qū)分測試需求與軟件需求 能夠收集測試需求 了解測試需求的特征,能力目標(biāo),測試需求,定義：描述在你的應(yīng)用程序中哪些需要被測試，簡單來講就是一個測試的范圍。根據(jù)這個范圍再來擬制測試計劃 依據(jù)：軟件規(guī)格說明書、市場需求，產(chǎn)品本身的屬性 內(nèi)容：內(nèi)容就是需要被測試的“哪些”，這個“哪些”包括功能、性能與效率、易用性、配置、兼容性 測試需求通常是以軟件開發(fā)需求為基礎(chǔ)進(jìn)行分析，通過對開發(fā)需求的細(xì)化和分解，形成可測試的內(nèi)容。 測試需求應(yīng)全部覆蓋已定義的業(yè)務(wù)流程，以及功能和非功能方面的需求；,測試需求的特征,制定的測試需求項必須是可核實的。即，它們必須有一個可觀察、可評測的結(jié)果，無法核實的需求不是測試需求； 測試需求應(yīng)指明滿足需求的正常的前置條件，同時也要指明不滿足需求時的出錯條件； 測試需求不涉及具體的測試數(shù)據(jù)，測試數(shù)據(jù)設(shè)計是測試設(shè)計環(huán)節(jié)應(yīng)解決的內(nèi)容。,為什么需要測試需求,軟件測試需求是開發(fā)測試用例的依據(jù)。 有助于保證測試的質(zhì)量與進(jìn)度 。 測試需求是衡量測試覆蓋率的重要指標(biāo)。,1.把不直觀的需求-直觀的需求（用例/活動圖） 使得測試范圍可以度量（功能點的數(shù)量、功能項的數(shù)量）； 使得獨立的功能點其對應(yīng)的所有的處理分支可以度量； 使得該系統(tǒng)需要測試的業(yè)務(wù)場景可以度量 2.把不明確的需求-明確的需求 明確其功能點對應(yīng)的輸入、處理、輸出 3.把不能度量的需求-可度量的需求,測試需求分析要達(dá)到的目的,軟件需求：項目所要實現(xiàn)的功能以及要達(dá)到的性能，主要面向開發(fā)人員 測試需求：描述的是測試點，包括各個功能點，功能間的交互，硬件及軟件環(huán)境等，主要面向測試人員,軟件需求與測試需求的區(qū)別,需求分析：初步設(shè)想-原始需求-需求分析-需求規(guī)格：輸入、處理和輸出 測試需求分析：單功能點輸入處理輸出-業(yè)務(wù)流分析-全局-隱式需求挖掘 需求分析和測試需求分析兩者的過程是相反的,需求分析與測試需求分析的區(qū)別,測試需求分析過程,1.熟悉需求 2.需求項整理 3.提取出測試點 4.測試點細(xì)化 5.確定測試范圍 6.制定測試策略,測試需求分析的過程,需求采集,需求分析,需求采集,需求采集的過程是將軟件開發(fā)需求中的那些具有可測試性的需求或特性提取出來，形成原始測試需求。 可測試性是指這些提取的需求或特性必須存在一個可以明確預(yù)知的結(jié)果，可以用某種方法對這個明確的結(jié)果進(jìn)行判斷、驗證，驗證是否符合文檔中的要求。,需求采集,需求采集的提取方法： 通過列表的形式對軟件開發(fā)需求進(jìn)行梳理，形成原始測試需求列表，列表的內(nèi)容包括需求標(biāo)識、原始測試需求描述、信息來源。 將每一條軟件需求對應(yīng)的開發(fā)文檔及章節(jié)號作為軟件需求標(biāo)識。 使用軟件需求的簡述作為原始測試需求描述。 軟件需求獲取的來源信息 作為信息來源。,需求采集,提取的原始測試需求中，可能存在重復(fù)和冗余，在提取原始測試需求過程中，可以通過以下方法整理原始測試需求： 刪除：刪除原始測試需求表中重復(fù)的、冗余的含有包含關(guān)系的原始測試需求描述； 細(xì)化：對太簡略的原始測試需求描述進(jìn)行細(xì)化； 合并：如果有類似的原測試始需求，在整理時需要對其進(jìn)行合并。,需求采集內(nèi)容（1）,功能需求輸入方面 輸入來源是什么？ 輸入數(shù)據(jù)數(shù)量是幾個？ 如果有錯誤輸入，響應(yīng)是什么？ 什么是非法輸入？什么是無效輸入？ 功能需求處理方面 輸入數(shù)據(jù)的有效性檢測的流程是什么？ 操作的確切次序，包括各事件的時序是什么？ 對異常情況的回應(yīng)是什么？例如：溢出、通信失敗、錯誤處理,需求采集內(nèi)容（2）,功能需求結(jié)果輸出方面 輸出到何處（如瀏覽器，打印機(jī)，文件）？ 輸出的數(shù)量是多少？ 輸出的時序是什么樣的？ 對非法值的處理是什么樣的？ 功能需求性能需求方面 靜態(tài)量化可能包含：支持的終端數(shù)目，支持的同時使用的用戶數(shù)，處理的文件和記錄的數(shù)目，表和文件的大小 動態(tài)量化可能包含：在正?；蚍逯倒ぷ髁壳闆r下一個特定時間段處理事務(wù)或任務(wù)的數(shù)目及數(shù)據(jù)量。在正?；蚍逯倒ぷ髁壳闆r下處理某個事務(wù)或任務(wù)所占用系統(tǒng)資源的數(shù)量,需求采集內(nèi)容（3）,功能需求用戶接口方面 系統(tǒng)用戶顯示時要求的屏幕格式 頁面規(guī)劃及報告或菜單的內(nèi)容 輸入和輸出的相關(guān)時序 一些組合功能鍵的用法 功能需求硬件接口方面 描述軟件產(chǎn)品和系統(tǒng)硬件組件之間接口的邏輯特征 該功能運行支持哪些設(shè)備？怎樣支持這些設(shè)備和協(xié)議呢？,需求采集-舉例,測試需求分析的步驟,測試需求分析的步驟,a）對原始測試需求列表中列出的每一條開發(fā)需求，形成可測試的分層描述的測試要點； b）對步驟a）形成的每一條測試要點，確定軟件產(chǎn)品的質(zhì)量需求； c）對步驟b）所確定的質(zhì)量需求，分析測試執(zhí)行時需要實施的測試類型； d）建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。,Step1-測試要點分析（1）,測試要點是對原始測試需求表每一條開發(fā)需求的細(xì)化和分解，形成的可測試的分層描述的軟件需求。 對開發(fā)需求的細(xì)化和分解具體包括： 通過分析每條開發(fā)需求描述中的輸入、輸出、處理、限制、約束等，給出對應(yīng)的驗證內(nèi)容； 通過分析各個功能模塊之間的業(yè)務(wù)順序，和各個功能模塊之間傳遞的信息和數(shù)據(jù)（功能交互分析） ，對存在功能交互的功能項，給出對應(yīng)的驗證內(nèi)容。,Step1-測試要點分析 （2）,進(jìn)行細(xì)化和分解還需考慮： 需求的完整性，經(jīng)過分解獲得的需求必須能夠充分覆蓋軟件需求的各種特征（包括隱含的特征），每個需求必須可以獨立完成有意義的功能或功能組合，可以進(jìn)行單獨測試； 需求的規(guī)模，每個最低層次的需求能夠使用數(shù)量相當(dāng)?shù)臏y試用例來實現(xiàn)，也即測試的粒度是均勻的,Step2- 質(zhì)量特性分析,對每一條測試要點，確定所對應(yīng)的質(zhì)量子特性。,質(zhì)量特性定義,功能性 適合性：軟件產(chǎn)品為指定的任務(wù)和用戶目標(biāo)提供一組合適的功能的能力。 準(zhǔn)確性：軟件產(chǎn)品提供具有所需精度的正確或相符的結(jié)果或效果的能力。 可靠性 容錯性：在軟件出現(xiàn)故障或違反其指定接口的情況下，軟件產(chǎn)品維持規(guī)定的性能級別的能力。 易用性 易理解性：軟件產(chǎn)品使用戶能理解軟件是否合適以及如何能將軟件用于特定的任務(wù)和使用條件的能力。 易操作性：軟件產(chǎn)品使用戶能理解和操作它的能力。,分析質(zhì)量特性-舉例,分析質(zhì)量特性-舉例,Step3-分析測試類型(1),不同的質(zhì)量子特性可以確定出不同的測試內(nèi)容，這些測試內(nèi)容可以通過不同的測試類型來實施。 軟件測試可以劃分為以下測試類型：功能測試、安全性測試、接口測試、容量測試、完整性測試、結(jié)構(gòu)測試、用戶界面測試、負(fù)載測試、壓力測試、疲勞強(qiáng)度測試、恢復(fù)性測試、配置測試、兼容性測試、安裝測試等。 根據(jù)質(zhì)量子特性的定義，以及各測試類型的測試內(nèi)容，可以分析出質(zhì)量子特性與測試類型的對應(yīng)關(guān)系。,Step3-分析測試類型(2),質(zhì)量子特性和測試類型的對應(yīng)關(guān)系基準(zhǔn)表,功能測試：側(cè)重于驗證測試目標(biāo)預(yù)期功能，確保滿足提供所需的服務(wù)、方法或用例。針對不同測試目標(biāo)（包括單元、集成單元、應(yīng)用程序和系統(tǒng)）實施和執(zhí)行此測試。 完整性測試：側(cè)重于評估測試目標(biāo)的健壯性（防止故障）和語言、語法和資源用途的技術(shù)一致性。針對不同測試目標(biāo)（包括單元和集成單元）實施并執(zhí)行此測試。 容量測試：側(cè)重于驗證測試目標(biāo)處理大量數(shù)據(jù)的能力，可以是輸入和輸出或數(shù)據(jù)庫中駐留的數(shù)據(jù)。,安全性測試：側(cè)重于確保測試目標(biāo)數(shù)據(jù)只供預(yù)訂好的那些參與者訪問。針對各種測試目標(biāo)實施并執(zhí)行此測試。 接口測試：側(cè)重于驗證測試目標(biāo)的數(shù)據(jù)接口的正確性和對其設(shè)計的遵循性。 結(jié)構(gòu)測試：側(cè)重于評估測試目標(biāo)對其設(shè)計和形式的遵循性。通常，對支持web的應(yīng)用程序執(zhí)行此測試，以確保連接所有鏈接，顯示合適的內(nèi)容和未孤立任何內(nèi)容。,用戶界面測試：側(cè)重于驗證測試目標(biāo)預(yù)期功能，確保滿足提供所需的服務(wù)、方法或用例。針對不同測試目標(biāo)（包括單元、集成單元、應(yīng)用程序和系統(tǒng)）實施和執(zhí)行此測試。 完整性測試：側(cè)重于評估測試目標(biāo)的健壯性（防止故障）和語言、語法和資源用途的技術(shù)一致性。針對不同測試目標(biāo)（包括單元和集成單元）實施并執(zhí)行此測試。 容量測試：側(cè)重于驗證測試目標(biāo)處理大量數(shù)據(jù)的能力，可以是輸入和輸出或數(shù)據(jù)庫中駐留的數(shù)據(jù)。 安全性測試：側(cè)重于確保測試目標(biāo)數(shù)據(jù)只供預(yù)訂好的那些參與者訪問。針對各種測試目標(biāo)實施并執(zhí)行此測試。 接口測試：側(cè)重于驗證測試目標(biāo)的數(shù)據(jù)接口的正確性和對其設(shè)計的遵循性。 結(jié)構(gòu)測試：側(cè)重于評估測試目標(biāo)對其設(shè)計和形式的遵循性。通常，對支持web的應(yīng)用程序執(zhí)行此測試，以確保連接所有鏈接，顯示合適的內(nèi)容和未孤立任何內(nèi)容。,分析測試類型-舉例,分析測試類型-舉例,Step4-測試需求跟蹤矩陣(1),建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。將上述步驟分析、確定的開發(fā)需求、測試需求、測試類型填入測試跟蹤需求矩陣。 測試需求跟蹤矩陣為原始測試需求與測試要點的對應(yīng)關(guān)系表，格式如下：,Step4-測試需求跟蹤矩陣(2),建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。將上述步驟分析、確定的開發(fā)需求、測試需求、測試類型填入測試跟蹤需求矩陣。 通過測試需求跟蹤矩陣的方式對需求變更實施管理。軟件需求一旦發(fā)生變化，就要對需求跟蹤表進(jìn)行維護(hù)，啟動配置管理過程，將與軟件需求變更相關(guān)的內(nèi)容進(jìn)行同步變更。,測試需求跟蹤矩陣-舉例,增加 培訓(xùn) 信息,測試需求跟蹤矩陣-舉例,增加 培訓(xùn) 信息,測試需求評審,評審的內(nèi)容： 完整性審查：應(yīng)保證測試需求能充分覆蓋軟件需求的各種特征，重點關(guān)注功能要求、數(shù)據(jù)定義、接口定義、性能要求、安全性要求、可靠性要求、系統(tǒng)約束等方面，同時還應(yīng)關(guān)注是否覆蓋開發(fā)人員遺漏的、系統(tǒng)隱含的需求； 準(zhǔn)確性審查：應(yīng)保證所描述的內(nèi)容能夠得到相關(guān)各方的一致理解，各項測試需求之間沒有矛盾和沖突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設(shè)計的依據(jù)。,測試需求評審,評審的形式 相互評審、交叉評審：甲和乙在一個項目組，處在一個領(lǐng)域，但工作內(nèi)容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查。相互評審是最不正式的一種評審形式，但應(yīng)用方便、有效。 輪查：又稱分配審查方法，是一種異步評審方式。作者將需要評審的內(nèi)容發(fā)送給各位評審員，并收集他們的反饋意見。,測試需求評審,評審的形式 走查：作者將測試需求在現(xiàn)場向一組同事介紹，以收集大家的意見。希望參與評審的其他同事可以發(fā)現(xiàn)其中的錯誤，并能進(jìn)行現(xiàn)場討論。這種形式介于正式和非正式之間。 小組評審：通過正式的小組會議完成評審工作，是有計劃的和結(jié)構(gòu)化的評審方式。評審定義了評審會議中的各種角色和相應(yīng)的責(zé)任，所有參與者在評審會議的前幾天就拿到了評審材料，并對該材料進(jìn)行了獨立研究。,測試需求評審,評審的形式 審查