對需求分析

轉 http://www.javashuo.com/article/p-vbymrgqn-gw.html

案例 《挖掘管理價值：企業軟件項目管理實戰》一2.3　需求分析過程

 軟件測試人員如何作好需求分析

一、什麼是測試需求分析

                                                                                                               

         測試需求分析：一、分析需求的可行性

                              二、分析測試點：將需求分析拆分紅一個個的功能點

 

         拿到需求----測試需求分析-----編寫測試計劃/編寫測試用例-----執行測試-----編寫測試報告

 

二、測試需求分析點

 

通常能夠從三個方面去考慮：

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

　　二、非功能性需求--用戶可能不能明確告訴你的一些需求，好比

             2.1業務需求：

　　　　　　業務流程，業務規則描述是否清楚，是否按照流程圖就能夠正常的執行，有沒有缺乏的節點？

                       隱性需求，直接看到的軟件並無將所有的業務顯示出來，經過什麼步驟進入到什麼頁面，什麼頁面顯示什麼樣的內容，分析業務

　　　　　　 的重要性：實際的業務中每個業務系統解決了什麼問題，達到了什麼目的，業務的表如今功能上，依託功能來表現業務。

 

             2.二、性能需求：有明確性能的需求（顯性需求），如淘寶0點8分到5點7分有500用戶使用，沒有性能需求（隱性需求）

 

              2.三、環境需求：系統運行環境的需求分析

 

             2.四、安全性需求：用戶登陸（權限）、密碼加密、非敏感行業，隱性需求

 

              2.五、界面需求：用戶交互、UI

 

               2.六、可靠性需求：運行過程當中出錯的風險，軟件的數據準確性、流程完整性

　　　　這塊的內容並不 是說用戶須要，而是說不知道須要作成什麼樣的，咱們不能不作，作了只會對本身受益。要否則等到後期用戶使用感受這慢，那不爽，那倒黴的仍是是本身；

　　三、限制條件--在需求分析中須要考慮一些條件約束，規則等，好比客戶的約束，行業的約束，法律的約束以及本身的約束等，用戶典型的操做行爲有哪些？經常使用的功能是什麼，操做時長等。

 

 

三、測試需求分析技巧

            一、熟悉需求，明確測試範圍：定義測試範圍

            二、定義流程：肯定流程是什麼樣子的，來分析業務，檢測出核心功能首要進行測試

            三、二次溝通：與需求分析師/產品經理溝通

            四、細化：軟件流程、區分核心、非核心模塊

            五、依據流程生成場景模型

            六、結合場景進行測試數據設計：依據的測試手段都是合理有效的。減小沒必要要的時間等浪費

 

測試人員在閱讀需求文檔或看demo時，要能回籤以下問題：

　　一、系統要實現哪些功能，這些功能的輸入，輸出，操做步驟是什麼。

　　二、系統中業務流程，業務規則描述是否清楚，是否按照流程圖就能夠正常的執行，有沒有缺乏的節點。

　　三、系統涉及的用戶有哪些，用戶都具有什麼樣的權限。

　　四、系統對於非功能性的需求有哪些？這些需求描述是否完整，有明確的指標。

　　五、系統的運行環境描述是否完整，按照這個環境是否能搭建出測試環境。

　　六、用戶典型的操做行爲有哪些？經常使用的功能是什麼，操做時長等。

　　以上這些問題的答案若是在文檔或demo中沒法找到答案，就須要跟項目經理進行溝通來了解這些信息。

　　測試需求分析的步驟

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

　　a) 瞭解清楚項目發起的緣由，是爲了解決用戶的什麼問題。

　　b) 當前的解決方案是否是最優的，爲何會這樣作？

　　2 、業務模型法：

　　a) 考慮本項目與外部系統的交互，劃分系統邊界（除了本項目的需求中要求作的事情，其餘的均可以是外部系統，本系統和外部系統之間的交互就是系統的邊界），能夠參考系統分析說明書。

　　b) 肯定測試範圍和關注點。系統的邊界是測試的重點，特別須要關注邊界交互時的數據交互。

　　3 、業務場景法：

　　a) 考慮用例的調用者；考慮每個用例提供的服務是供哪些外部用例或者系統調用，找出全部的調用者。調用的前提、約束都要考慮。每個調用均可以考慮成一個大的業務流程。（通常和外部有交互的用例出錯的機率比較大，須要重點關注）

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

　　4 、功能分解法

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

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

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

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

　　e). 編輯約束：功能的細節，在功能執行時，對輸入數據項目的一些約束性條件，好比只能輸入數字。

　　f). 參數需求：功能的細節，在功能中，須要根據參數設置不一樣，進行不一樣處理的細節。

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

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

　　先看一段關於日誌文件的需求描述以下：「軟件要將全部的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間、訪問結束時間、訪問者的IP地址這三個信息做爲一條日誌記錄。要求以天爲單位天天生成一個訪問記錄日誌文件。

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

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

　　一、訪問者

　　二、訪問記錄

　　三、日誌文件

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

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

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

　　需求描述中提到了天天要生成一個日誌文件，從文件建立時間屬性來看，天天有24小時，到底從何時開始建立文件，從0點開始仍是從幾點開始，沒有描述出來。

　　---從文件名屬性來看，如何命名日誌文件，需求中也沒有說起。從存放位置屬性來看，日誌文件存放在什麼地方也沒有說明。是否是全部的日誌文件都存放在應用程序同一子目錄下？

　　---從文件格式屬性來看，首先日誌文件是以文本方式存儲仍是以二進制格式存儲？再者，文件的內容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行做爲分隔仍是以其餘字符做爲分隔？都沒有描述。

　　---從文件內容屬性來分析，除了存放上述描述的內容外，是否還能夠保存其餘內容，若是不能保存其餘內容的話，需求描述中應該加上一句」日誌文件中只能存儲訪問記錄信息，不得儲存其餘記錄信息「。

　　---從文件大小屬性來分析，日誌文件的大小有沒有限制？若是某天處於訪問高峯期，訪問特別多，是否須要將日誌文件分拆成多個是一個須要考慮的問題。

　　---從文件權限屬性來分析，日誌文件是否機器上的全部用戶均可以訪問仍是隻有特定的用戶能夠訪問？文件是否須要設置權限是一個須要考慮的問題。

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

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

　　1)首先，對於需求文檔的檢查主要是兩個方面：

　　---檢查需求文檔描述的正確性，這裏存在兩個問題，一是用戶是否真的能正確地描述本身的需求，二是需求人 員是否真的能正確地理解需求。另外，還有一個用戶的需求是否符合行業規範的問題，若是不符合，那麼是否要確認--這裏存在一個隱患，用戶可能會在開發的後 期忽然要求他們本身要走行業規範，讓你的需求變更，因此要事先明確好。

　　---檢查需求文檔描述的準確性。主要是考慮文檔中是否存在描述的模糊的地方，對於本身不清楚的問題必定要明確。這個時候是要保證需求的可測試性--個人意思是說保證需求是能夠徹底爲測試工做服務的。

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

　　固然，這個階段所設計的測試用例是不夠完善的，只能涵蓋某些內容，可是我認爲這些用例不只僅所有都是功能測試用例，並且在整個項目中都將有效。 。

　　3)當項目緊時，沒法寫出需求文檔，咱們的作法就是：從網上找跟該項目類似的一些資料進行整理，須要是幫助咱們理解業務，而後項目經理組織會議討論該系統作成什麼樣，要實現哪些功能，測試人員要充分參與交流，將本身理解的狀況表達出來，不能只是被動地去聽。