一、如何做好需求分析
1.測試需求分析的過程
- 根據需求規格提取獨立的功能點，確定測試範圍；
- 對獨立功能進行分析，確定各獨立功能的測試點；
- 對業務場景即功能組合進行分析，提供業務場景的測試點；
- 對非功能特性進行分析，瞭解需要測試的非功能特性；
- 針對系統級接口進行分析，瞭解被測試對象、測試規格。分析可測性，確定測試方法、工具。
具體見需求分析過程圖（如下：）
2. 測試需求分析需要考慮的一些問題和細節
問題：
- 已文檔化的需求是否被正確實現；
- 是否存在遺漏需求；
- 是否存在畫蛇添足的問題(實現了不存在於需求規格的需求)。
- 功能設計是否完整。避免出現流程不通的功能。
細節：
- 需求項與測試項關聯、與測試用例關聯（避免遺漏）；
- 區分出測試項的優先級（80/20法則）；
- （可以使用兩次80/20法則，將優先級快速分爲三個層次：5%、15%、80%） 針對可能存在的需求遺漏和疑似額外的實現，主動聯繫需求提出方，進行溝通並確認；
- 若需求項（測試項）可測試性差，及時反饋（涉及接口的，需要看到API，或接口文檔）。
3.額外的個人經驗：
- 在需求分析階段 熟悉需求
原型圖、需求說明書一起閱讀。在此，我們熟悉時要對比原型圖中的一些元素和UI圖中的元素，應是完全一致的。另在看需求說明書的過程中列出一個功能清單，包含功能模塊、子模塊、功能點、測試點。
- 總結需求
即總結需求中的功能及測試點，我們要熟悉到看UI圖上的某一功能，就知道該功能實現規則及測試點。 總結功能設計是否完成。
二、如何做好測試用例設計
1.測試用例描述
是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否滿足某個特定需求。
2.編寫測試用例的好處
進一步理解、細化需求； 理清測試點及測試思路，避免遺漏；
3. 用例包含的屬性
ID、所屬系統、功能模塊、重要性、用例標題、前置條件、步驟、測試數據、預期結果、測試記錄（通過、不通過、阻塞、無效）。
4.用例設計注意事項
用例標題需簡潔、明瞭、清晰的概括一個測試點。（用例標題要包含詳細的一個功能點。一條好的用例標題，只需看標題就知道怎麼去執行。）
用例標題關鍵字:
- 頁面檢查的用例標題關鍵字：查看、檢查；例：檢查某某頁面包含如下元素：（列出具體元素）；
- 功能實現類用例標題關鍵字：驗證……
- 文本框用例：驗證輸入框不能爲空；驗證輸入框最大可輸入N個字符；驗證某某輸入框支持漢字、英文、數字等輸入。
- 功能性用例：驗證商品下架後，不會在用戶端顯示；驗證購買某一商品（數量爲N ）後，庫存也要-N。
5.用例設計及評審注意事項
- 編寫用例時要覆蓋到所有功能，用例要描述清楚；
- 複用性、變更性強。
- 功能細節描述不清晰點需要記錄，向產品確認；
- 有不合理的功能需要記錄、確認；
- 評審時要提出自己覺得需求中設計不完善和不清楚的功能。
三、bug管理流程
1.Bug提交注意事項
（ps:寫bug注意事項 是因爲在項目經理向我們吐槽 說開發人員說某一些人bug描述看不懂簡直看不懂。而且描述各種口水話，讓我們在組內做個這方便的培訓。。好尷尬的。所以各位要注意了）
Bug標題描述需要 精簡、準確，刪除冗雜/無用描述，使用中性化語言（無任何偏激/幽默等修飾）。儘可能描述如何觸發的 bug，如何重現 bug，bug 的影響。有附件、日誌，儘可能貼上 截圖/關鍵日誌 進一步說明問題.
bug標題描述我們最好按照以下格式： 【某某功能模塊】某某子功能/頁面：某個功能顯示錯誤，顯示……。應顯示…… 例：功能/UI缺失的bug，直接寫成：【某某功能】某某頁面:‘某某功能’未實現/未生效；頁面缺少什麼。需求UI圖上有顯示。附上UI圖。像接口 一些特別複雜不好描述的，儘量把圖貼上 。 可以截圖的都把圖片貼上。另有多張圖片時，把所有圖片合在一張裏面再上傳。
2.Bug提交驗證流程
提交----各種bug（代碼錯誤、需求設計、建議、用戶體驗類的 等等）都要提交到公司的bug管理工具上，(備案備案)。
指派---直接指給對應的開發人員
驗證、關閉--開發人員解決後，進件驗證，驗證完成關閉（關閉時記錄備註 註明在哪個環境，哪個版本/包上回歸的，並寫明迴歸結果）。
不修復的bug處理:確認好不修復的原因(代碼錯誤、需求遺漏、設計實現困難、改動影響其他功能)-向產品、TL各個領導報備確認，指出影響範圍(這個時候多半遵循他們的意見)
四、業務測試方法
1. 業務測試的方法和實踐
a．站在用戶的角度
優秀的需求應該是站在用戶的角度來思考問題，是用戶能夠利用系統完成什麼，而不是系統自己完成。因此在需求理解時要多和軟件的最終用戶進行交流，瞭解他們的訴求，以便有針對性的進行測試。
b．重視全局，而非細節
工作重點應該是放在儘可能全面的收集需求要點、瞭解整體的業務流程、分析主體業務流程和重點業務流程等工作上。在獲得了系統的全貌之後，我們會發現原先在編寫功能測試用例對系統的認識是不充分的，這時要編寫的流程測試用例需要根據新的思路進行重新排列。
c．現場客戶
現場客戶隨時提供對需求細節的指導。如果沒有條件，可以定期的邀請用戶參加項目例會或安排和用戶交流等。另外在需求理解評審和測試設計評審會盡量邀請用戶參與。
2、業務測試學精必備的兩種能力
- 爲產品質量負責的能力。
- 爲產品體驗負責的能力。
五 總結
正常迭代需求、緊急需求的測試任務，我們都要有目的性的測試，不能盲目測試。測試時要思考從哪裏入手測試，一步一步的測完整。不能東測一下，西弄一下。測試時若是思路不是很清楚，先寫一個測試思維導圖，測一個點或是場景就記一個場景。覺得所有功能都全部測完的，再想一下拓展性、或是異常的場景進行測試。