1樓：川石資訊
一、測試規格分析準備
測試需求分析主要是從測試型別和功能互動方面進行分析，所以前期需要對測試型別、開發特性和功能集合進行標識。
測試型別劃分見表6-26
測試需求分析主要是從測試型別和功能互動方面進行分析，所以前期需要對測試型別、開發特性和功能集合進行標識。
測試特性劃分見表6-27：
接下來需求確定每個測試階段需要使用的測試型別，具體見表6-28：
二、測試型別分析
測試型別分析是對每個功能點就不同測試型別的角度進行分析，即從不同的角度分析該功能特性的測試內容，見表6-29。
這裡需要注意的是，每種測試型別都應該分析到，當然這個例子中我們只寫了一部分測試型別，但實際分析過程中不能這樣，必須把每種測試型別都分析到。同時還需要控制分析粒度，盡量保持每個規格所對應的檢查點應該是適當的，其粒度應該是差別不大的，如果在分析過程中有多人參與，那麼也需要保持粒度一致。
關於測試規格編號的規則為：測試階段-測試型別-序號，測試型別必須在測試規格編號中體現出來，如果同乙個測試型別可以分解出很多不同的初始測試規格，那麼使用一組序號來標識。
三、功能互動分析
功能互動分析主要是分析功能之間的時序關係影響和共享關係影響。時序影響主要包括功能之間的順序關係和互動關係，共享關係主要包括共享資料和共享資源的影響。分析的結果見表6-30。
2樓：
盡可能多的了解業務，然後在需求分析會議上掃除盡可能多的不確定部分，盡可能多的讓開發了解到哪些功能，哪些邊界，哪些沒寫明的需求你會覆蓋到，甚至盡可能的把用例或者驗收用例在開發開始開發前發出來.
你前面做的越多，你後面測的越少，這就叫以會議驅動開發，或者，你改動幾個詞，也可以說我們BDD了 :)
3樓：西邊人
你首先要明白需求分析的目的，以及整個測試過程中需求分析的重要性。
例如，比方說乙個計算平方根的程式，如果輸入乙個大於或等於零的數，程式可以給出乙個結果；如果輸入乙個小於零的數，程式將指出輸入錯誤。讀過《軟體測試的藝術》一書的工程師都會立即聯想到邊界值。對數值零進行測試；對零非常接近的負數進行測試，這就是兩個具體的測試需求。
在乙個更加複雜的程式中，你可以將打算測試的專案做成乙個列表。但是，這些測試需求都不會確定具體的測試資料。例如，乙個銀行交易程式，乙個測試需求是試圖支付客戶的金額為負數，另乙個測試需求是交易中的客戶並不存在，等等。
你有一系列這樣的測試需求，它們並沒有指出具體的數值或資料，如客戶的姓名。
測試的下一步是選擇滿足這些測試需求的輸入值 / 測試資料。乙個簡單的測試用例可能會同時滿足好幾個測試需求。乙個用例能同時滿足好幾個測試需求，當然是最理想的情況，但是這樣做的代價較高。
另外一種方法是為每乙個測試需求設計乙個單獨的測試用例，就可以不必考慮那些複雜的測試用例，但是這些相對簡單的測試用例發現缺陷的能力就會有所下降。
這裡有乙個測試需求的例項：對乙個雜湊表的插入操作進行測試，有以下這些測試需求：
1. 插入乙個新的條目
2. 插入失敗－條目已經存在
3. 插入失敗－表已滿
4. 雜湊表在插入前為空
這些就是測試需求，而非測試用例，因為它們沒有對被插入元素進行描述。另外你也不能馬上就著手書寫用例，就好象軟體需求完成後不能立即進行編碼一樣。還需要對測試需求進行評審，確保正確和沒有需求遺漏。
4樓：羅谷婷
我們舉個例子來說明吧：有一段關於日誌檔案的需求描述如下：「軟體要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間、訪問結束時間、訪問者的IP位址這三個資訊作為一條日誌記錄。
要求以天為單位每天生成乙個訪問記錄日誌檔案。
在這段需求描述中，我們首先要想象自己是日誌模組的開發者，根據這段需求描述，是否能夠開發出日誌模組來呢？日誌檔案要記錄的資訊內容上面都提到了：訪問開始時間、結束時間、IP位址。
乍一看好像可以根據這個需求描述進行開發。
但仔細來分析一下這段需求的話，就會發現並不是想象的那樣樂觀。先找出需求中涉及的三個顯性元素：
1、訪問者
2、訪問記錄
3、日誌檔案
首先對訪問者和訪問記錄這兩個元素進行分析，先看訪問者有那些屬性，除了描述中提及的訪問時間和IP位址外，訪問者還有那些屬性呢？顯然訪問者的訪問內容是最重要的屬性，僅記錄訪問時間和訪問者的IP位址是否足夠呢，從日誌能分析出什麼有用的資訊呢？從時間資訊上最多只能看出那段時間訪問的人數較多，得到使用者的時間分布規律，但很難對使用者的行為有深入的分析，只有知道訪問者在訪問那些內容才能得到更有價值的資訊。
象Web伺服器軟體要記錄下訪問的URL資訊以便知道訪問者訪問的內容，所以訪問記錄中遺漏了關於訪問內容的資訊。
從訪問記錄這個元素來分析，訪問記錄主要屬性是記錄格式，每條記錄是以什麼格式來記錄呢？沒有描述出來。有經驗的開發者就知道日誌記錄格式是乙個很重要的問題，因為日誌記錄的分析一般是需要使用專門的分析軟體或者寫專門的分析程式來分析的。
如何設計合理的記錄格式來利用已有的日誌分析軟體來進行分析是首要考慮的問題。
再對日誌檔案這個元素進行分析，先看看日誌檔案有那些屬性，首先日誌檔案具有檔名，還有存放位置，檔案格式，檔案內容、檔案建立時間、檔案大小、檔案許可權等屬性。
需求描述中提到了每天要生成乙個日誌檔案，從檔案建立時間屬性來看，每天有24小時，到底從什麼時候開始建立檔案，從0點開始還是從幾點開始，沒有描述出來。
---從檔名屬性來看，如何命名日誌檔案，需求中也沒有提及。從存放位置屬性來看，日誌檔案存放在什麼地方也沒有說明。是不是所有的日誌檔案都存放在應用程式同一子目錄下？
---從檔案格式屬性來看，首先日誌檔案是以文字方式儲存還是以二進位制格式儲存？再者，檔案的內容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行作為分隔還是以其他字元作為分隔？都沒有描述。
---從檔案內容屬性來分析，除了存放上述描述的內容外，是否還可以儲存其他內容，如果不能儲存其他內容的話，需求描述中應該加上一句」日誌檔案中只能儲存訪問記錄資訊，不得儲存其他記錄資訊「。
---從檔案大小屬性來分析，日誌檔案的大小有沒有限制？如果某天處於訪問高峰期，訪問特別多，是否需要將日誌檔案分拆成多個是乙個需要考慮的問題。
---從檔案許可權屬性來分析，日誌檔案是否機器上的所有使用者都可以訪問還是只有特定的使用者可以訪問？檔案是否需要設定許可權是乙個需要考慮的問題。
所以在對上述需求描述進行分析後，你會發現需求描述中有很多的問題沒有描述清楚。也許有人會有疑問，如果將所有上面說到的問題都描述出來的話會不會工作量太大了？僅從需求分析的角度來講，需求規格描述得較細的話確實會增大很多任務作量，但從整個開發過程來看，需求描述完整的話，後續階段的開發產生歧義和遺漏的可能性就很小，實際上後續階段節約的時間會大大超過需求所多花的時間。
上面只是個簡單的例子，關於測試人員在需求階段需要做哪些工作？需求分析包含哪些步驟和工作，限於篇幅就不再贅述了，大家可以參考下這篇文章 測試人員如何做測試需求分析
測試工程師如何做好軟體測試？
獨獨 用心，我也不能說自己做的很好，所以只能說自己的看法。首先用心的熟悉需求的業餘背景知識，還有業務邏輯。然後反覆的去思考，設計使自己的用例沒有缺漏。最後提高自己的技術吧，技術越好，你可以採用的方法就越多。 軟體測試藝術 建議你可以看一下 google測試之道 這本書，看看google測試工程師是如...
如何做需求分析？
誰禿誰知道 使用者需求的分析，通常分為定性和定量。資料分析和問卷調查都屬於定量，到線下與使用者面談是屬於定性，如果僅僅通過資料分析，那需要有很強的洞察力，建議是將這兩類分析方法相互結合。比如，在做資料分析的時候，你只看到乙個想象的模型，當你接觸使用者之後，能把你想象的事情跟實際情況聯合在一起，兩者是...
如何做專案需求分析？
朱大斌 要更好的掌握專案需求管理的方法 工具 技術及流程，推薦IIBA BABOK V3的書，是市面上受認可度最高的需求管理的書籍。也可餐看PMI的需求管理的書 最近在學習PMI出的 Project business analysis practice guide。感覺這個書不錯，方法，步驟，工具和...