軟件測試需求分析

1、測試需求及需求分析伊薇亦2013年12月28號工作中的場景？問題漏測；測試設(shè)計(jì)不充分60%！測試出很多，還有這么多問題？這些問題怎么沒有考慮到？不知道如何站在客戶立場測試？客戶到底關(guān)心什么？需要做測試需求分析！很多公司現(xiàn)狀測試輸入測試對象分析測試用例設(shè)計(jì)（方案內(nèi)的）測試用例沒有測試需求分析過程測試經(jīng)理口頭分配測試方案任務(wù)不明確測試過程與結(jié)果缺乏質(zhì)量評估與控制測試對象分析側(cè)重測試方案內(nèi)部實(shí)現(xiàn)過多關(guān)注功能實(shí)現(xiàn)、產(chǎn)品質(zhì)量維度關(guān)注不全面沒有統(tǒng)一成熟的分析設(shè)計(jì)工程方法支撐測試過程中遇到的問題匯總 測試需求不充分，沒有明確的測試需求分析過程 產(chǎn)品質(zhì)量維度關(guān)注不全面，測試類型不完整 沒有測試規(guī)格，測試分解分

2、配比較隨意 責(zé)任主體不明確 沒有系統(tǒng)的工程方法或指導(dǎo) 沒有相應(yīng)的質(zhì)量評估原則 需求的定義 需求是用戶為解決一個(gè)或達(dá)到一個(gè)目標(biāo)所需要的一種能力條件。 或需求是一個(gè)系統(tǒng)或系統(tǒng)組成部分為滿足一個(gè)合同、標(biāo)準(zhǔn)、規(guī)則說明或其它正式規(guī)定的文件必須達(dá)到或具備的能力條件。 什么是測試需求1. 測試需求主要解決“測什么”的問題，即指明被測對象中什么需要測試2. 測試需求通常是以軟件開發(fā)需求為基礎(chǔ)進(jìn)行分析，通過對開發(fā)需求的細(xì)化和分解，形成可測試的內(nèi)容3. 測試需求應(yīng)全部覆蓋已定義的業(yè)務(wù)流程，以及功能和非功能方面的需求 Test Requirement=Test Condition=Test Specificatio

3、n 測試需求=測試條件=測試規(guī)格 業(yè)務(wù)需求與測試需求的關(guān)系 業(yè)務(wù)業(yè)務(wù)需求需求通常是指系統(tǒng)需要做什么 測試測試需求需求除了需要覆蓋系統(tǒng)應(yīng)該做什么外，還要覆蓋系統(tǒng)不應(yīng)該做什么。 測試測試需求需求是用來發(fā)現(xiàn)需求中存在的問題 為什么做測試需求分析？ 測試需求分析目的是：明確應(yīng)該測試什么。即明確測試需求，其核心是產(chǎn)品質(zhì)量。 產(chǎn)品質(zhì)量就是符合用戶的明確的或隱含的需求的程度。 需求文檔中的產(chǎn)品需求、系統(tǒng)設(shè)計(jì)需求是明確的需求 未在需求文檔中明確的隱含的用戶需求也是我們需要分析的，如用戶使用產(chǎn)品方式、感受等。 清晰把握測試需求！時(shí)刻關(guān)注產(chǎn)品質(zhì)量！測試需求分析的作用和重要性 測試需求提供一個(gè)測試應(yīng)用程序所必須的詳

4、細(xì)的描述。 軟件測試需求是開發(fā)測試用例的依據(jù) 確定測試完整性的一個(gè)基礎(chǔ) 確定測試工作的范圍 識別可做自動(dòng)化測試的策略 作為測試的方向標(biāo) 有助于保證測試的質(zhì)量與進(jìn)度 有助于進(jìn)行需求跟蹤 有利于測試管理 測試需求的特征一條有用的測試需求總是： 唯一的 精確的 有邊界的 可測試的 其它可能： 必要的前置條件 不涉及測試數(shù)據(jù) 測試需求分析內(nèi)容 測試需求的內(nèi)容：測試范圍、測試目標(biāo) 測試范圍：就是測試項(xiàng)目中，我們需要進(jìn)行開發(fā)生命周期的各個(gè)階段的測試，還是部分測試 測試目標(biāo)：系統(tǒng)的那些特性需要測試 測試需求的要點(diǎn)： 解決系統(tǒng)要測什么而不是描述如何測 測試需求包含：功能性需求和非功能性需求 功能性需求:系統(tǒng)功

5、能、業(yè)務(wù)流程、界面、系統(tǒng)安裝等 非功能性需求：性能要求、安全性要求、兼容性要求、移植要求 需求分析通常步驟 1、通過列表的形式對軟件開發(fā)需求進(jìn)行梳理，形成原始測試需求列表，列表的內(nèi)容包括需求標(biāo)識、原始測試需求描述、信息來源。 2、將每一條軟件需求對應(yīng)的開發(fā)文檔及章節(jié)號作為軟件需求標(biāo)識。 3、使用軟件需求的簡述作為原始測試需求描述。 4、軟件需求獲取的來源信息作為信息來源。 5、提取的原始測試需求中，可能存在重復(fù)和冗余，在提取原始測試需求過程中，可以通過以下方法整理原始測試需求： 刪除：刪除原始測試需求表中重復(fù)的、冗余的含有包含關(guān)系的原始測試需求描述； 細(xì)化：對太簡略的原始測試需求描述進(jìn)行細(xì)化；

6、 合并：如果有類似的原測試始需求，在整理時(shí)需要對其進(jìn)行合并。方法參考1、強(qiáng)調(diào)測試需求分析分析過程和結(jié)果分開，產(chǎn)生測試需求需要問自己，“這些功能假設(shè)要做什么？如果做了這些，我如何才能知道”，和開發(fā)進(jìn)行交流的思路來源于以下事實(shí)：有些規(guī)格并沒有寫在SRS中，而是停留在開發(fā)人員的腦中，特別是用戶使用的方式等等。2、電子表格是支撐測試分析設(shè)計(jì)的主要工具測試設(shè)計(jì)的工具選擇并非一定要有專門的工具支撐，只要能將測試設(shè)計(jì)活動(dòng)通過工具串起來，相互之間的繼承和依賴關(guān)系能夠表達(dá)出來即可。3、測試劃分提出測試劃分概念，明確了每個(gè)測試方案的輸入和測試方案之間的接口。類似于開發(fā)的系統(tǒng)規(guī)格分解過程。4、測試類型測試類型是擴(kuò)展

7、測試覆蓋的重要方法，業(yè)界公司都強(qiáng)調(diào)建立自己的測試類型庫。長時(shí)間以來，有經(jīng)驗(yàn)的測試設(shè)計(jì)人員都認(rèn)可，并且維持著不同的測試類型列表 。軟件需求分析 可行性和緊迫程度，近期需求和遠(yuǎn)期需求，分析的主要工作包括： 通過啟發(fā)、誘導(dǎo)、深層次的溝通與交流，獲取用戶潛在需求 分析行業(yè)的規(guī)則、規(guī)范，分析用戶需求的合理性 編寫分析報(bào)告并獲得用戶認(rèn)可 將用戶需求做階段性的截止，否則系統(tǒng)設(shè)計(jì)將無所適從，并增加系統(tǒng)設(shè)計(jì)的風(fēng)險(xiǎn)和隱患。 如果需求變更，則需要進(jìn)行變更控制如何分析測試需求測試需求分析考慮的因素 測試階段 待測軟件的特性 測試焦點(diǎn) 測試需求優(yōu)先級 測試需求的覆蓋率與覆蓋程度一、測試階段 系統(tǒng)測試階段側(cè)重于技術(shù)層面，

8、軟件是否實(shí)現(xiàn)了功能。同一流程或角色執(zhí)行功能正確，具有相同特征的業(yè)務(wù)或角色都能執(zhí)行正確。 驗(yàn)收測試階段側(cè)重于業(yè)務(wù)層面，更注重于不同角色在同一功能上執(zhí)行是否正確二、待測軟件的特性 不同業(yè)務(wù)背景和應(yīng)用 安全性軟件安全（人身、重大財(cái)產(chǎn)） 電子商務(wù)網(wǎng)站壓力 ERP流程 驅(qū)動(dòng)程序兼容性 政府門戶法律、法規(guī)三、測試焦點(diǎn) 根據(jù)所測的功能點(diǎn)劃分的層次例如：界面、業(yè)務(wù)流、模塊化、數(shù)據(jù)、輸入域等 基于業(yè)務(wù)流的測試需求分析方法測試需求分析時(shí)需要列出以下類別：常用的或規(guī)定的業(yè)務(wù)流程各業(yè)務(wù)流程分支的遍歷明確規(guī)定不可使用的業(yè)務(wù)流程沒有明確規(guī)定但是應(yīng)該不可以執(zhí)行的業(yè)務(wù)流程其它異常或不符合規(guī)定的操作四、測試需求的優(yōu)先級 把握重

9、點(diǎn)、有的放矢 緩和測試風(fēng)險(xiǎn) 用戶需求軟件需求 有優(yōu)先級：則決定測試需求優(yōu)先級 無優(yōu)先級：則通過溝通，確定測試需求優(yōu)先級五、測試需求的覆蓋率與覆蓋程度 測試需求與軟件需求的對應(yīng)關(guān)系 覆蓋率=測試需求覆蓋點(diǎn)數(shù)/軟件需求功能點(diǎn)數(shù)*100%測試需求分析的步驟 1 、 熟悉需求背景及商業(yè)目標(biāo)： 了解清楚項(xiàng)目發(fā)起的原因，是為了解決用戶的什么問題。 當(dāng)前的解決方案是不是最優(yōu)的，為什么會這樣做？ 2 、業(yè)務(wù)模型法： 考慮本項(xiàng)目與外部系統(tǒng)的交互，劃分系統(tǒng)邊界（除了本項(xiàng)目的需求中要求做的事情，其他的都可以是外部系統(tǒng)，本系統(tǒng)和外部系統(tǒng)之間的交互就是系統(tǒng)的邊界），可以參考系統(tǒng)分析說明書。 確定測試范圍和關(guān)注點(diǎn)。系統(tǒng)的

10、邊界是測試的重點(diǎn)，特別需要關(guān)注邊界交互時(shí)的數(shù)據(jù)交互。 3、業(yè)務(wù)場景法： 考慮用例的調(diào)用者；考慮每一個(gè)用例提供的服務(wù)是供哪些外部用例或者系統(tǒng)調(diào)用，找出所有的調(diào)用者。調(diào)用的前提、約束都要考慮。每一個(gè)調(diào)用都可以考慮成一個(gè)大的業(yè)務(wù)流程。（一般和外部有交互的用例出錯(cuò)的概率比較大，需要重點(diǎn)關(guān)注） 考慮系統(tǒng)內(nèi)部各個(gè)用例之間的交互，形成內(nèi)部業(yè)務(wù)流程圖。需要分析每個(gè)用例之間的約束關(guān)系、執(zhí)行條件，組織出各種業(yè)務(wù)流程圖。 4、業(yè)務(wù)功能：與用戶實(shí)際業(yè)務(wù)直接相關(guān)的功能或細(xì)節(jié)。 輔助功能：輔助完成業(yè)務(wù)功能的一些功能或者是細(xì)節(jié)，比如，設(shè)置過濾條件。 數(shù)據(jù)約束：功能的細(xì)節(jié)，主要是用于控制在執(zhí)行功能時(shí)，數(shù)據(jù)的顯示范圍、數(shù)據(jù)之間

11、的關(guān)系等。 易用性需求：功能的細(xì)節(jié)，產(chǎn)品中必須提供了，便于功能操作使用的一些細(xì)節(jié)，比如快捷鍵就是典型的易用性需求。 編輯約束：功能的細(xì)節(jié)，在功能執(zhí)行時(shí)，對輸入數(shù)據(jù)項(xiàng)目的一些約束性條件，比如只能輸入數(shù)字。 參數(shù)需求：功能的細(xì)節(jié)，在功能中，需要根據(jù)參數(shù)設(shè)置不同，進(jìn)行不同處理的細(xì)節(jié)。 權(quán)限需求：功能的細(xì)節(jié)，這里的權(quán)限是指在功能的執(zhí)行過程，根據(jù)根據(jù)不同的權(quán)限進(jìn)行不同處理的，不包括直接限制某個(gè)功能的權(quán)限舉例：說明如何進(jìn)行測試需求分析先看一段關(guān)于日志文件的需求描述如下： “軟件要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時(shí)間、訪問結(jié)束時(shí)間、訪問者的IP地址這三個(gè)信息作為一條日志記錄。要求以天為單

12、位每天生成一個(gè)訪問記錄日志文件?！迸e例說明如何進(jìn)行測試需求分析（續(xù)1） 在這段需求描述中，我們首先要想象自己是日志模塊的開發(fā)者，根據(jù)這段需求描述，是否能夠開發(fā)出日志模塊來呢？日志文件要記錄的信息內(nèi)容上面都提到，包括：訪問開始時(shí)間、結(jié)束時(shí)間、IP地址。 好像可以根據(jù)這個(gè)需求描述進(jìn)行開發(fā)，但仔細(xì)來分析一下這段需求的話，就會發(fā)現(xiàn)并不是想象的那樣樂觀。先找出需求中涉及的三個(gè)顯性元素： 1、訪問者 2、訪問記錄 3、日志文件舉例說明如何進(jìn)行測試需求分析（續(xù)2） 首先對訪問者和訪問記錄這兩個(gè)元素進(jìn)行分析，先看訪問者有那些屬性，除了描述中提及的訪問時(shí)間和IP地址外，訪問者還有那些屬性呢？ 顯然訪問者的訪問內(nèi)

13、容是最重要的屬性，僅記錄訪問時(shí)間和訪問者的IP地址是否足夠呢，從日志能分析出什么有用的信息呢？從時(shí)間信息上最多只能看出那段時(shí)間訪問的人數(shù)較多，得到用戶的時(shí)間分布規(guī)律，但很難對用戶的行為有深入的分析，只有知道訪問者在訪問那些內(nèi)容才能得到更有價(jià)值的信息。 Web服務(wù)器軟件要記錄下訪問的URL信息以便知道訪問者訪問的內(nèi)容，所以訪問記錄中遺漏了關(guān)于訪問內(nèi)容的信息。舉例說明如何進(jìn)行測試需求分析（續(xù)3） 從訪問記錄這個(gè)元素來分析，訪問記錄主要屬性是記錄格式，每條記錄是以什么格式來記錄呢？沒有描述出來。 有經(jīng)驗(yàn)的開發(fā)者就知道日志記錄格式是一個(gè)很重要的問題，因?yàn)槿罩居涗浀姆治鲆话闶切枰褂脤ｉT的分析軟件或者寫

14、專門的分析程序來分析的。如何設(shè)計(jì)合理的記錄格式來利用已有的日志分析軟件來進(jìn)行分析是首要考慮的問題。 一般要對日志文件屬性進(jìn)行分析，應(yīng)該具有文件名，還有存放位置，文件格式，文件內(nèi)容、文件創(chuàng)建時(shí)間、文件大小、文件權(quán)限等屬性。舉例說明如何進(jìn)行測試需求分析（續(xù)4）時(shí)間點(diǎn)：需求描述中提到了每天要生成一個(gè)日志文件，從文件創(chuàng)建時(shí)間屬性來看，每天有24小時(shí)，到底從什么時(shí)候開始創(chuàng)建文件，從0點(diǎn)開始還是從幾點(diǎn)開始，沒有描述出來。文件命名：從文件名屬性來看，如何命名日志文件，需求中也沒有提及。文件位置：從存放位置屬性來看，日志文件存放在什么地方也沒有說明。是不是所有的日志文件都存放在應(yīng)用程序同一子目錄下？文件格式：

15、日志文件是以文本方式存儲還是以二進(jìn)制格式存儲？內(nèi)容格式：文件的內(nèi)容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行作為分隔還是以其他字符作為分隔？都沒有描述。其它內(nèi)容：從文件內(nèi)容屬性來分析，除了存放上述描述的內(nèi)容外，是否還可以保存其他內(nèi)容，如果不能保存其他內(nèi)容的話，需求描述中應(yīng)該加上一句“日志文件中只能存儲訪問記錄信息，不得儲存其他記錄信息”。文件大?。簭奈募笮傩詠矸治?，日志文件的大小有沒有限制？如果某天處于訪問高峰期，訪問特別多，是否需要將日志文件分拆成多個(gè)是一個(gè)需要考慮的問題。訪問屬性：從文件權(quán)限屬性來分析，日志文件是否機(jī)器上的所有用戶都可以訪問還是只有特定的用戶可以訪問？文件是

16、否需要設(shè)置權(quán)限是一個(gè)需要考慮的問題。舉例說明如何進(jìn)行測試需求分析（續(xù)5） 需求描述中有很多的問題沒有描述清楚。也許有人會有疑問，如果將所有上面說到的問題都描述出來的話會不會工作量太大了？ 僅從需求分析的角度來講，需求規(guī)格描述得較細(xì)的話確實(shí)會增大很多工作量，但從整個(gè)開發(fā)過程來看，需求描述完整的話，后續(xù)階段的開發(fā)產(chǎn)生歧義和遺漏的可能性就很小，實(shí)際上后續(xù)階段節(jié)約的時(shí)間會大大超過需求所多花的時(shí)間。舉例WEB應(yīng)用測試需求分析 界面要素分析 頁面鏈接：是否遺漏加鏈接，鏈接是否正確； 頁面表單：例如用戶填寫的出生日期與職業(yè)是否恰當(dāng)，填寫的所屬省份與所在城市是否匹配等。如果使用了默認(rèn)值，還要檢驗(yàn)?zāi)J(rèn)值的正確性

17、； 頁面控件：如下拉值，下拉選中后，再次點(diǎn)擊，選中焦點(diǎn)是否還在原來的下拉選項(xiàng)；如多選，單選是否正確；舉例WEB應(yīng)用測試需求分析方法（續(xù)） 頁面功能點(diǎn)分析 單個(gè)功能點(diǎn)的處理：正常操作、異常操作； 關(guān)聯(lián)功能處理：A刪除QQ中的好友B，在好友列表中就會去掉B的顯示；在B的好友列表中，也會去掉A的顯示；這點(diǎn)也通常稱為關(guān)聯(lián)測試點(diǎn)； 基于數(shù)據(jù)流的處理：商品庫存數(shù)量，不同客戶端訂購并支付成功減少，退貨成功后增加，在相關(guān)子系統(tǒng)的數(shù)據(jù)一致性舉例WEB應(yīng)用測試需求分析方法（續(xù)） 功能交互分析 交互的入口要鮮明； 交互的步驟要簡潔； 交互的結(jié)果要正確； 如答疑系統(tǒng)，當(dāng)某問題再次被學(xué)員追問，追問的問題必須有列表顯示，

18、助教可清晰區(qū)分追問的問題和非追問的問題，助教回答問題后，用戶可收到消息提醒；測試需求分析方法（1）業(yè)務(wù)流程分析：業(yè)務(wù)流逐漸細(xì)化為子業(yè)務(wù)流 常用的或規(guī)定的業(yè)務(wù)流程 ： 各業(yè)務(wù)流程分支的遍歷 明確規(guī)定不可使用的業(yè)務(wù)流程 沒有明確規(guī)定但是應(yīng)該不可以執(zhí)行的業(yè)務(wù)流程 提交答案異常判斷確認(rèn)是否提交提交成功是否測試需求分析方法（2）用戶場景分析 通常指事件觸發(fā)的場景。 如微信的測試，當(dāng)前賬號已經(jīng)登錄微信了，再用該賬號在其他地方登錄微信； 如答疑系統(tǒng)中，助教A正要領(lǐng)取某問題的時(shí)候，助教B搶先領(lǐng)取了該問題；測試需求分析方法（3） 不同角色的權(quán)限分析 技術(shù)實(shí)現(xiàn)原理上分析 系統(tǒng)邊界分析 非功能性的特征分析兼容性系統(tǒng)

19、響應(yīng)性能特性測試需求分析步驟 對測試依據(jù)進(jìn)行分析，列出的每一條開發(fā)需求對應(yīng)的測試需求； 對上面步驟形成的每一條測試需求點(diǎn)，軟件內(nèi)部/外部質(zhì)量模型來確定軟件產(chǎn)品的質(zhì)量需求； 對上面步驟所確定的質(zhì)量需求，分析測試執(zhí)行時(shí)需要實(shí)施的測試類型； 建立測試需求跟蹤矩陣，對測試需求進(jìn)行管理。測試需求分析（1） 測試需求分析是對軟件需求中每一條開發(fā)需求的細(xì)化和分解，形成的可測試的分層描述的軟件測試需求。 對開發(fā)需求的細(xì)化和分解具體包括： 通過分析每條開發(fā)需求描述中的輸入、輸出、處理、限制、約束等，給出對應(yīng)的驗(yàn)證內(nèi)容； 通過分析各個(gè)功能模塊之間的業(yè)務(wù)順序，和各個(gè)功能模塊之間傳遞的信息和數(shù)據(jù)（功能交互分析） ，對

20、存在功能交互的功能項(xiàng)，給出對應(yīng)的驗(yàn)證內(nèi)容。 進(jìn)行細(xì)化和分解還需考慮： 需求的完整性，經(jīng)過分解獲得的需求必須能夠充分覆蓋軟件需求的各種特征（包括隱含的特征），每個(gè)需求必須可以獨(dú)立完成有意義的功能或功能組合，可以進(jìn)行單獨(dú)測試； 需求的規(guī)模，每個(gè)最低層次的需求能夠使用數(shù)量相當(dāng)?shù)臏y試用例來實(shí)現(xiàn)，也即測試的粒度是均勻的測試需求分析-舉例原始需求描述標(biāo)識測試需求一條完整的培訓(xùn)信息包括培訓(xùn)的主題、證書、內(nèi)容、起止時(shí)間、費(fèi)用、地點(diǎn)、機(jī)構(gòu)，其中培訓(xùn)的主題、內(nèi)容、起止時(shí)間、費(fèi)用、機(jī)構(gòu)為必填項(xiàng)。培訓(xùn)的起始時(shí)間不能晚于截止時(shí)間，培訓(xùn)費(fèi)用精確到元角分。每一個(gè)輸入項(xiàng)的數(shù)據(jù)規(guī)格在數(shù)據(jù)字典中可以得到。1輸入符合字典要求的各信

21、息后執(zhí)行保存，檢查保存是否成功；2檢查每個(gè)輸入項(xiàng)的數(shù)據(jù)長度是否遵循數(shù)據(jù)字典的要求；3檢查每個(gè)輸入項(xiàng)的數(shù)據(jù)類型是否遵循數(shù)據(jù)字典的要求；4檢查“培訓(xùn)費(fèi)用”是否滿足規(guī)定的精度要求；5檢查在培訓(xùn)的起止時(shí)間早晚于截止時(shí)間時(shí)，所增加的記錄是否保存成功；6檢查“培訓(xùn)主題”、“培訓(xùn)內(nèi)容”、“起止時(shí)間”、“培訓(xùn)費(fèi)用”、“培訓(xùn)機(jī)構(gòu)”是否為必填項(xiàng)；7驗(yàn)證系統(tǒng)對數(shù)據(jù)重復(fù)的檢查。8針對頁面中文字、表單、圖片、表格等元素，檢查每個(gè)頁面各元素的位置是否協(xié)調(diào)，各元素的顏色是否協(xié)調(diào)，各元素的大小比例是否協(xié)調(diào)；9頁面信息內(nèi)容顯示是否完整；10檢查是否有功能標(biāo)識，功能標(biāo)識是否準(zhǔn)確、清晰；11最大化、最小化、還原、切換、移動(dòng)窗口時(shí)是否能正常的顯示頁面。分析質(zhì)量特性-舉例質(zhì)量特性對應(yīng)表原始需求