軟體測試人員如何做好需求分析

釋出時間: 2013-5-17 15:34    作者: 未知    來源: 51Testing軟體測試網採編 

字型: 小 中 大  |上一篇下一篇 |列印  |我要投稿  |推薦標籤：需求分析需求管理軟體測試

　　什麼是需求

　　需求是產品必須完成的事以及必須具備的品質。

　　功能性需求

　　功能性需求是產品必須完成的那些事，要求一定的功能和品質。

　　例子：培訓機構的班主任可以給所在班級學員打考勤

　　非功能性需求

　　非功能性需求是產品必須具備的屬性或品質。諸如觀感、可用性、安全性和法律限制等。

　　例子： 平臺使用者數為5萬人，每天登入使用者數為10000左右，網路的頻寬為100M頻寬。在工作

　　這類需求通常在產品的功能確定之後（但並非總是如此）。也就是說，一旦知道了產品要做的事情，就可以確定它的行為方式，它需要具備什麼品質以及它的響應速度、可用性、可讀性和安全性。

　　限制條件

　　限制條件是全域性性的需求。它們可以是對專案本身的限制，或是對產品最終設計的限制。

　　例子：南京平臺必須在2010年開學的第一學期上線

　　客戶是在說，如果顧客不能在給定的時間前使用該產品，那麼它就沒有什麼用了。其效果是，需求分析師必須對需求進行限制，只包括那些在最後期限前能夠提供最大價值的需求。

　　需求分析的重要性

　　背景：馮大勇吃魚時嗓子被魚刺卡住了。現在正坐在椅子上候診。
　　      大夫：（在桌上拿起一份掛號單，大聲的喊）馮大勇！
          馮大勇：（病怏怏的樣子，邊走邊咳嗽）我是。
　　      大夫：怎麼了？（低頭整理手中的資料，自言自語，並打手勢，示意馮大勇坐下）
　　      馮大勇：我．．．（咳嗽）．．．我今天．．．（咳嗽）
　　      大夫：不用說了，我知道了。（從桌子下面拿出一個大盒子，放在桌子上）我看你適合吃這種藥。這是本院獨家開創的哮喘新葯“咽喉糖漿”，療程短，見效快，一個療程吃3盒，平均每天只需花費3塊錢。給你先開6盒吧！（邊說邊開藥方）
　　      馮大勇非常驚訝地瞪大眼睛並止不住地彎腰大聲咳嗽，以至於把魚刺都咳出來了。馮大勇從口裡掏出一條巨型魚刺，遞給醫生。醫生見到魚刺先是吃驚，而後又非常尷尬。

　　醫生不瞭解病人的需求就用藥，是草菅人命；銷售員不瞭解客戶的需求就進行推銷，不僅自己要徒勞無功地浪費很多口舌，更重要的是完不成銷售的目標。給客戶推銷軟體產品，也相當於醫生給病人治病，應當首先充分、全面地瞭解客戶的需求所在、期望所在，然後才能帶給他一個完美的解決方案。

　　需求分析沒有做好的後果一般會有下列現象：

　　1、浪費時間和資源來滿足使用者並不需要的需求（過度實現一些功能）；

　　2、開發出來的產品技術上先進，但不滿足使用者需求；

　　3、總是需要比較長的時間來達成對產品設計的共識；

　　4、在產品設計，開發和測試工作中對於使用者需求的解釋不一致；

　　5、員工會厭倦因需求不斷被重新解釋而導致的返工；

　　6、未說明的或不正確的需求會導致員工與使用者間的不滿；

　　7、不穩定的產品，使用者的不滿意對我們未來的市場造成損失；

　　8、浪費時間，增加成本，使得在一些投標的專案中不能低價；

　　1、如果你在編碼的時候發現某幾行有誤，那麼改掉這幾行就行了。而如果在編碼階段發現需求有誤，那麼你很可能需要改變所有程式碼來適應新的需求

　　2、在需求階段消除問題的代價最小，而如果需求問題等到產品釋出出去後才發現的話，那修復的成本就會N倍的增加。

　　3、穩定的需求是軟體開發的關鍵。有了穩定的需求，軟體開發工作可能從結構設計到詳細設計到程式碼到測試都會平穩順利的進行。

　　為什麼要做需求分析

　　1、“決策性”--要不要做這個產品，通過對市場需求的分析來決策專案是否需要立項；

　　2、“方向性”--良好的需求分析可以對專案人員明確方向，讓專案成員知道下面應該如何實施；

　　3、“策略性”--既然知道了為什麼要做需求分析，就需要了解什麼是需求分析，及如何做。需求分析並不是簡單的對與錯，比如說做一個產品，“做技術最先進的軟體，還是做最好賣的軟體”，這個需求有錯嗎，沒有，只能說需要從不同的地方去考慮，去定位。

如何進行需求分析

　　“ 需求分析”不代表“使用者要求什麼就是什麼”也不代表“我們能做什麼就做什麼”，做為需求人員，在進行需求分析的時候，首先應該明白使用者的需求，然後再加上自己的分析處理過程，知道哪些我們現在能做，哪些我們做不了，哪些我們咬咬牙齒能做，需求人員在做需求分析的時候不能一味的成為客戶的傳話筒，要有自己的分析。

　　一般可以從三個方面去考慮：

　　1、功能需求--產品應該完成哪些功能，即向用戶提供的功能，一般來說這個都是比較硬性的標準；

　　2、非功能性需求--使用者可能不能明確告訴你的一些需求，比如說效能達到什麼要求，可靠性方面，響應時間，擴充套件性，效能方面等，這塊的內容並不是說使用者需要，而是說不知道需要做成什麼樣的，我們不能不做，做了只會對自己受益。要不然等到後期使用者使用感覺這慢，那不爽，那倒黴的還是是自己；

　　3、限制條件--在需求分析中需要考慮一些條件約束，規則等，比如客戶的約束，行業的約束，法律的約束以及自己的約束等，這些都需要在需求分析考慮清楚，要不然做出一款白人狂毆黑人的遊戲給黑人玩，那就慘了……

　　測試需求分析的步驟

　　1 、 熟悉需求背景及商業目標：

　　a) 瞭解清楚專案發起的原因，是為了解決使用者的什麼問題。

　　b) 當前的解決方案是不是最優的，為什麼會這樣做？

　　2 、業務模型法：

　　a) 考慮本專案與外部系統的互動，劃分系統邊界（除了本專案的需求中要求做的事情，其他的都可以是外部系統，本系統和外部系統之間的互動就是系統的邊界），可以參考系統分析說明書。

　　b) 確定測試範圍和關注點。系統的邊界是測試的重點，特別需要關注邊界互動時的資料互動。

　　3 、業務場景法：

　　a) 考慮用例的呼叫者；考慮每一個用例提供的服務是供哪些外部用例或者系統呼叫，找出所有的呼叫者。呼叫的前提、約束都要考慮。每一個呼叫都可以考慮成一個大的業務流程。（一般和外部有互動的用例出錯的概率比較大，需要重點關注）

　　b) 考慮系統內部各個用例之間的互動，形成內部業務流程圖。需要分析每個用例之間的約束關係、執行條件，組織出各種業務流程圖。

　　4 、功能分解法

　　a). 業務功能：與使用者實際業務直接相關的功能 或細節。

　　b). 輔助功能：輔助完成業務功能的一些功能或者是細節，比如，設定過濾條件。

　　c). 資料約束：功能的細節，主要是用於控制在執行功能時，資料的顯示範圍、資料之間的關係等。

　　d). 易用性需求：功能的細節，產品中必須提供了，便於功能操作使用的一些細節，比如快捷鍵就是典型的易用性需求。

　　e). 編輯約束：功能的細節，在功能執行時，對輸入資料專案的一些約束性條件，比如只能輸入數字。

　　f). 引數需求：功能的細節，在功能中，需要根據引數設定不同，進行不同處理的細節。

　　g). 許可權需求：功能的細節，這裡的許可權是指在功能的執行過程，根據根據不同的許可權進行不同處理的，不包括直接限制某個功能的許可權。

　　某日，老師在課堂上想考考學生們的智商，就問一個男孩：“樹上有十隻鳥，開槍打死一隻，還剩幾隻？”

　　男孩反問：“是無聲槍麼？”

　　“不是。”

　　“槍聲有多大？”

　　“80~100分貝。”

　　“那就是說會震的耳朵疼？”

　　“是。”

　　“在這個城市裡打鳥犯不犯法？”

　　'不犯。“

　　“您確定那隻鳥真的被打死啦？”

　　“確定。”老師已經不耐煩了，“拜託，你告訴我還剩幾隻就行了，OK？”

　　“OK。鳥裡有沒有聾子？”

　　“沒有。”

　　“有沒有關在籠子裡的？”

　　“沒有。”

　　“邊上還有沒有其他的樹，樹上還有沒有其他鳥？”

　　“沒有。”

　　“方圓十里呢？”

　　“就這麼一棵樹！”

　　“有沒有殘疾或餓的飛不動的鳥？”

　　“沒有，都身體倍棒。”

　　“算不算懷孕肚子裡的小鳥？”

　　“都是公的。”

　　“都不可能懷孕？”

　　“………，決不可能。”

　　“打鳥的人眼裡有沒有花？保證是十隻？”

　　“沒有花，就十隻。”

　　老師腦門上的汗已經流下來了，下課鈴響起，但男孩仍繼續問：“有沒有傻的不怕死的？”

　　“都怕死。”

　　“有沒有因為情侶被打中，自己留下來的？”

　　“笨蛋，之前不是說都是公的嘛！”

　　“同志可不可以啊！”

　　“…………，性取向都很正常！”

　　“會不會一槍打死兩隻？”

　　“不會。”

　　“一槍打死三隻呢？”

　　“不會。”

　　“四隻呢？”

　　“更不會！”

　　“五隻呢？”

　　“絕對不會！！！”

　　“那六隻總有可能吧？”

　　“除非你他媽的是豬生的才有可能！”

　　“…好吧，那麼所有的鳥都可以自由活動麼？”

　　“完全可以。”

　　“它們受到驚嚇起飛時會不會驚慌失措而互相撞上？”

　　“不會，每隻鳥都裝有衛星導航系統，而且可以自動飛行。”

　　“恩，如果您的回答沒有騙人，”學生滿懷信心的回答，“打死的鳥要是掛在樹上沒掉下來，那麼就剩一隻，如果掉下來，就一隻不剩。”

舉例說明如何進行測試需求分析

　　先看一段關於日誌檔案的需求描述如下：“軟體要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間、訪問結束時間、訪問者的IP地址這三個資訊作為一條日誌記錄。要求以天為單位每天生成一個訪問記錄日誌檔案。

　　在這段需求描述中，我們首先要想象自己是日誌模組的開發者，根據這段需求描述，是否能夠開發出日誌模組來呢？日誌檔案要記錄的資訊內容上面都提到了：訪問開始時間、結束時間、IP地址。乍一看好像可以根據這個需求描述進行開發。

　　但仔細來分析一下這段需求的話，就會發現並不是想象的那樣樂觀。先找出需求中涉及的三個顯性元素：

　　1、訪問者

　　2、訪問記錄

　　3、日誌檔案

　　首先對訪問者和訪問記錄這兩個元素進行分析，先看訪問者有那些屬性，除了描述中提及的訪問時間和IP地址外，訪問者還有那些屬性呢？顯然訪問者的訪問內容是最重要的屬性，僅記錄訪問時間和訪問者的IP地址是否足夠呢，從日誌能分析出什麼有用的資訊呢？從時間資訊上最多隻能看出那段時間訪問的人數較多，得到使用者的時間分佈規律，但很難對使用者的行為有深入的分析，只有知道訪問者在訪問那些內容才能得到更有價值的資訊。象Web伺服器軟體要記錄下訪問的URL資訊以便知道訪問者訪問的內容，所以訪問記錄中遺漏了關於訪問內容的資訊。

　　從訪問記錄這個元素來分析，訪問記錄主要屬性是記錄格式，每條記錄是以什麼格式來記錄呢？沒有描述出來。有經驗的開發者就知道日誌記錄格式是一個很重要的問題，因為日誌記錄的分析一般是需要使用專門的分析軟體或者寫專門的分析程式來分析的。如何設計合理的記錄格式來利用已有的日誌分析軟體來進行分析是首要考慮的問題。

　　再對日誌檔案這個元素進行分析，先看看日誌檔案有那些屬性，首先日誌檔案具有檔名，還有存放位置，檔案格式，檔案內容、檔案建立時間、檔案大小、檔案許可權等屬性。

　　需求描述中提到了每天要生成一個日誌檔案，從檔案建立時間屬性來看，每天有24小時，到底從什麼時候開始建立檔案，從0點開始還是從幾點開始，沒有描述出來。

　　---從檔名屬性來看，如何命名日誌檔案，需求中也沒有提及。從存放位置屬性來看，日誌檔案存放在什麼地方也沒有說明。是不是所有的日誌檔案都存放在應用程式同一子目錄下？

　　---從檔案格式屬性來看，首先日誌檔案是以文字方式儲存還是以二進位制格式儲存？再者，檔案的內容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行作為分隔還是以其他字元作為分隔？都沒有描述。

　　---從檔案內容屬性來分析，除了存放上述描述的內容外，是否還可以儲存其他內容，如果不能儲存其他內容的話，需求描述中應該加上一句”日誌檔案中只能儲存訪問記錄資訊，不得儲存其他記錄資訊“。

　　---從檔案大小屬性來分析，日誌檔案的大小有沒有限制？如果某天處於訪問高峰期，訪問特別多，是否需要將日誌檔案分拆成多個是一個需要考慮的問題。

　　---從檔案許可權屬性來分析，日誌檔案是否機器上的所有使用者都可以訪問還是隻有特定的使用者可以訪問？檔案是否需要設定許可權是一個需要考慮的問題。

　　所以在對上述需求描述進行分析後，你會發現需求描述中有很多的問題沒有描述清楚。也許有人會有疑問，如果將所有上面說到的問題都描述出來的話會不會工作量太大了？僅從需求分析的角度來講，需求規格描述得較細的話確實會增大很多工作量，但從整個開發過程來看，需求描述完整的話，後續階段的開發產生歧義和遺漏的可能性就很小，實際上後續階段節約的時間會大大超過需求所多花的時間。

　　測試人員在需求階段應做哪些工作

　　1)首先，測試用例和測試工作本身是不斷完善的，在開發過程的初期，可以認為是需求階段，或者沒有規範需求工作的設計階段。如果有一個比較明確的需求文件，可以在這個階段檢查完了需求文件以後開始設計測試用例。這裡，對於需求文件的檢查主要是兩個方面：

　　---檢查需求文件描述的正確性，測試人員要對於真實的系統所涉及的業務非常熟悉，比如一個簡單的財務軟體，那麼測試人員本身就要對會計工作熟悉，財務制度熟悉，在檢查需求文件的時候不要迷信所謂的”都是使用者真實的需求“，這裡存在兩個問題，一是使用者是否真的能正確地描述自己的需求，二是需求人員是否真的能正確地理解需求。另外，還有一個使用者的需求是否符合行業規範的問題，如果不符合，那麼是否要確認--這裡存在一個隱患，使用者可能會在開發的後期突然要求他們自己要走行業規範，讓你的需求變動，所以要事先明確好。

　　---檢查需求文件描述的準確性。主要是考慮文件中是否存在描述的模糊的地方，對於自己不清楚的問題一定要明確。這個時候是要保證需求的可測試性--我的意思是說保證需求是可以完全為測試工作服務的。

　　2)那麼在檢查完了需求之後，就可以開始設計測試用例了，在這個階段因為沒有開始設計工作，所以對於測試用例的考慮不能僅僅從介面出發，而應該從業務角度出發，從實際業務出發來設計測試用例。

　　當然，這個階段所設計的測試用例是不夠完善的，只能涵蓋某些內容，但是我認為這些用例不僅僅全部都是功能測試用例，而且在整個專案中都將有效。 。

　　3)不過，當缺少需求文件時，那就要發揮測試人員自己的能動性了，要主動的工作，而不是被動的等待。要自己嘗試著去熟悉實際業務，要儘量通過自己所能想到的方法來開展工作。