一、需求分析？
1.什么是需求
軟件產品必須完成的，以及必須具備的品質。
功能性需求：產品必須完成的那些事，要求一定的功能和品質。
例子：淘寶的用戶名登錄。
非功能性需求：產品必須具備的屬性和品質。諸如觀感、可用性、安全性和法律限制等。
例子：平台用戶數為5萬人，每天登錄用戶數為10000左右，網絡的寬帶為100M寬帶。在工作時間根據資料名稱條件進行搜索，可以在3秒內得到搜索結果。
一旦知道了產品要做的事情，就可以確定它的行為方式，它需要具備什么品質以及它的響應速度、可用性、可讀性和安全性。
限制條件：是全局性的需求。他們可以是對項目本身的限制，或是對產品最終設計的限制。
2.如何進行軟件測試需求分析
測試需求分析的主要目的：根據需求文檔提取測試點（測試執行的要點）---我都是用測試點做用例標題，根據測試點來編寫測試用例
測試需求分析的步驟：
1.熟悉需求背景及商業目標：
a)了解清楚項目發起的原因，是為了解決用戶的什么問題。
b)當前的解決方案是不是最優的，為什么會這樣做？
2.業務模型法：
a）考慮本項目與外部系統的交互、划分系統邊界（除了本項目的需求中要求做的事情，其他的都可以是外部系統，本系統和外部系統之間的交互就是系統的邊界），可以參考系統分析說明書。
b）確定測試范圍和關注點。系統的邊界是測試的重點，特別需要關注邊界交互時的數據交互。
3.業務場景法：
a)考慮用例的調用者；考慮每一個用例提供的服務時供哪些外部用例或者時系統調用，找出所有的調用者。調用的前提、約束都要考慮。每一個調用都可以考慮成一個大的業務流程。（一般和外部有交互的用例輸出的概率比較大，需要重點關注）
b)考慮系統內部各個用例之間的交互，形成內部業務流程圖。需求分析每個用例之間的約束關系、執行條件、組織出各種業務流程圖。
4 、功能分解法
a). 業務功能：與用戶實際業務直接相關的功能 或細節。
b). 輔助功能：輔助完成業務功能的一些功能或者是細節，比如，設置過濾條件。
c). 數據約束：功能的細節，主要是用於控制在執行功能時，數據的顯示范圍、數據之間的關系等。
d). 易用性需求：功能的細節，產品中必須提供，便於功能操作使用的一些細節，比如快捷鍵就是典型的易用性需求。
e). 編輯約束：功能的細節，在功能執行時，對輸入數據項目的一些約束性條件，比如只能輸入數字。
f). 參數需求：功能的細節，在功能中，需要根據參數設置不同，進行不同處理的細節。
g). 權限需求：功能的細節，這里的權限是指在功能的執行過程，根據不同的權限進行不同處理，不包括直接限制某個功能的權限
測試點分析：
- 通過分析需求描述的輸入、輸出、處理、限制、約束等，給出對應的驗證內容；（功能測試）
- 通過分析各個功能模塊之間的業務順序，和各個功能模塊之間傳遞的信息和數據，對存在功能交互的功能項，給出對應的驗證內容（功能交互測試）
- 考慮到分析的完整性，要充分覆蓋軟件需求的各種特征，包含隱形需求的驗證。比如界面的驗證，注冊賬號的唯一性驗證（界面、易用性、兼容性、安全性、性能壓力）
在另一個博主哪里看到了一篇需求分析，推薦給大家。
https://www.cnblogs.com/spring_net/archive/2008/09/10/1288100.html
二、用例編寫
用例：通過操作步驟來驗證某個需求是否符合預期的結果。
1.測試 用例的重要性
- 測試用例是軟件測試的核心。
- 評估測試結果的基准。
- 保證測試的時候不遺漏測試功能點，可以在測試人員疲憊的時候起到一個牽引的作用。
- 在編寫測試用例的過程，可以熟悉需求，對系統架構或者業務流程有一個整體的，深入的了解。
- 好的測試用例不僅方便自己和別人查看，而且能幫助設計的時候考慮的更周全，因此測試的用例的寫作和設計一樣，也是非常重要的。
2.測試用例的八大要素
a.用例編號：產品名—測試階段（st it ut）--測試項-xxx
b.測試項目：對應一個功能模塊（細分功能）
c.測試標題：直接對測試點進行細化得出，輸入內容+結果，同一功能模塊標題不能重復，也就是分析需求的測試點
d.重要級別：高/中/低
e.預置條件：需要滿足一些前提條件，否則用例無法執行
f.測試輸入：需要加工得到輸入信息，根據具體情況來設計（跟步驟結合起來一定要具體指導性意義）
g.輸入步驟：明確給出每個步驟的描述，執行人員可以根據該步驟完成執行工作
h.預期結果：根據預期輸出比實際結果，來判斷被測對象是否符合需求。（預期結果唯一，不能出現“是、否、或者“）
i.實際結果
測試用例變更一定要把之前的用例備份
個人建議
1. 如果公司只有你一個Tester，就沒必要寫測試用例了，寫測試點把，用思維導圖（如Xmind）。
2. 如果需求老是頻繁變化，測試用例的更新速度跟不上需求的變化速度，每天都在改用例。這樣無太多意義和價值，還是寫測試點把。
3. 如果項目比較趕，完全沒時間嚴格按照測試用例執行，寫測試點吧，提取關鍵要素，不過空閑時間的把用例補上。
4. 如果測試點已經能夠保證充分覆蓋了，測試用例的意義不大 。
5. 如何用更少的測試點，盡可能的充分考慮各種可能性呢？與用例設計方法、經驗、需求理解等等有關。我們要綜合運用等價類、邊界值、錯誤推測、場景法、因果圖等測試用例的設計方法。
寫測試用例從產品需求開始，先把需求轉為測試點，再根據測試點+用例設計方法+個人經驗+測試用例的八大要素去寫詳細用例。
3.測試用例評審
用例評審的流程
- 評審材料准備好（主要是測試用例、評審檢查清單）。
- 提前（2天）發布評審通知（OA通知、郵件、或者討論組發布信息），同時將評審材料發送給評審組成員，以節約溝通成本。 主要的參與評審人員：項目經理、測試負責人、測試人員、產品經理、開發人員、UI。
- 召開會議評審；針對評審用例檢查清單，評審過程中收集相關人員的反饋信息（既問題記錄清單），並在此基礎上進行測試用例更新，直到評審通過。
- 評審結束后，修改測試用例，並將修改后發送項目組人員查看，確認沒問題，存檔。
會議主持人：測試用例編寫人——測試人員講解用例+記錄（用例修改意見）