一、軟體測試的生命週期

需求分析–>測試計劃–>測試設計、測試開發–>測試執行 -->測試評估

二、軟體測試&軟體開發生命週期

• 需求階段
  測試人員瞭解需求，對需求進行分解，得出測試需求

• 計劃階段
  根據需求編寫測試計劃/測試方案

• 設計階段
  測試人員適當瞭解設計，對於設計測試用例是很有幫助的，測試人員搭建測試用例框架，根據需求和設計編寫一部分測試用例

• 編碼階段
  測試人員一般是不需要編碼的，但已經編碼的模組，專業的白盒測試人員可以計劃執行單元測試，完善、細化測試用例以及調整計劃和方案

• 測試階段
  測試階段是軟體測試人員最為重要的工作階段，根據測試用例和計劃執行測試，在執行的過程中記錄、管理缺陷，測試完成後編寫測試報告

• 執行維護
  測試人員需要參與專案的實施工作，測試人員對專案產品的業務和操作非常瞭解，加上測試人員的溝通表達能力一般都比較強，所以測試人員可以參與使用者使用軟體的培訓，在試執行專案時收集問題並及時反饋給相關負責人

三、如何描述一個Bug

1.概述

介面、效能缺陷、建議類問題，不影響操作功能的執行，可以優化效能的方案等，如：錯別字、介面格式不規範，頁面顯示重疊、不該顯示的要隱藏、描述不清楚、提示語丟失、文字排列不整齊、游標位置不正確、使用者體驗感受不好、可以優化效能的方案等（此類問題在測試初期較多，優先程度較低，在測試後期出現較少，應及時處理）

2.bug的生命週期

每個公司，每一個工具對bug生命週期的定義都是不一致的，下面僅是常見的例子

• New：發現新的bug，未經評審決定是否指派給開發人員進行修改
• Open：確認是bug，並且認為需要進行修改，指派給相應的開發人員
• Fixed：開發人員進行修改後表示成修改狀態，有待測試人員的迴歸測試驗證
• Rejected：如果認為不是bug，則拒絕修改
• Delay：如果認為暫時不需要修改或暫時不能修改，則延後修改
• Closed：修改狀態的Bug經測試人員迴歸測試驗證通過，則關閉bug
• Reopen：如果經驗證Bug仍然存在，則需要重新開啟Bug，開發人員重新修改
  無效的Bug：open->closed open-rejected-closed

缺陷狀態變更流程每個專案團隊的實際做法可能不大一樣，並且需要結合實際的開發流程和協作流程來使用
例如：測試人員新發現bug，必須由測試組長評審後才決定是否Open並分派給開發人員，測試人員Open的Bug可以直接分派給對應的程式模組負責人，也可以要求都先統一提交給開發主管，由開發主管稽核後再決定是否分派給開發人員進行修改，Bug的跟蹤以及狀態變更應該遵循一些基本原則

• 測試人員對每一個缺陷的修改必須重新取一個包含更改後的程式碼的新版本進行迴歸測試，確保相同的問題不再出現，才能關閉缺陷
• 對於拒絕修改和延遲修改的bug，需要經過包含測試人員代表和開發人員代表、使用者方面的代表（或代表使用者角度的人）的評審

四、如何開始第一次測試

作為一個菜鳥在進入測試團隊開始第一次測試的時候，我們需要做很多的準備
1.閱讀所有專案有關的文件，包括：需求文件、設計文件、使用者手冊
2.儘可能參加各種會議，瞭解專案的背景、人員組成、儘可能的瞭解需求和業務，特別針對業務專業性較強的專案，例如銀行業務，需要了解各種業務知識，如一二三類賬戶等、存款、貸款等
3.熟悉專案所使用的測試管理工具、配置管理工具，獲取對應的地址和登入方式
4.閱讀已有的測試方案和測試案例
5.閱讀舊有的bug庫，瞭解系統功能，尤其重要的是和現有的測試團隊保持一致的故障定級原則
6.瞭解公司的規範需求，特別是用例編寫、用例執行規範、bug提交規範、測試工具工具使用規範等
在瞭解了以上準備工作後，第一次測試工作到來了，我們需要與測試組長確認具體的工作內容：
1.測試的計劃是什麼？
2.測試的內容是什麼？test case有多少？安排了幾天執行？有沒有自由測試的時間？
3.我要測試的內容開發人員是誰？需求人員是誰？
4.分配給我的測試內容是否需要特殊的測試資源？資源是否滿足需要？
在我們確認了以上內容之後，就可以開始測試的執行了

五、測試的執行和Bug管理

現在我們開始進行測試了
（1）開啟待測試的系統
（2）開啟測試管理工具用例模組，開始執行用例
（3）發現bug，進行復現並確認bug的復現步驟
（4）記錄bug
（5）溝通bug
（6）驗證以前提交的bug
（7）確認本次測試完成
（8）編寫測試報告
執行測試時處理要做到測試用例和需求的覆蓋外，還要有臨時發揮的能力，根據自己的經驗，對測試的感悟，以及隨機測試可以發現很多根據測試用例無法發現的缺陷
不能拘泥於測試用例或者已經有的測試方法，在測試執行過程中，=要不斷總結測試方法和測試故障模型，真正優秀的測試人員在執行測試時是想著做，做著想，這樣的測試效果才好，尤其是在測試過程中，對程式的處理相當瞭解的情況下，測試的思路會更加清晰和全面

六、如何發現更多的bug

1.軟體測試同樣存在二八原則，80%的故障集中於20%的模組，如果某部分問題比較多，加強測試廣度和深度
2.開發人員也存在二八原則，80%的故障集中於20%的開發人員，如果某些開發人員的bug較多，加強他開發模組的測試和深度
3.多進行逆向思維和發散性的思維
4.不要侷限於用例和需求文件
5.儘早介入專案，不要等到開發的差不多了再介入專案

七、產生爭執怎麼辦（處理人際關係）

能讓開發人員解決最多bug的測試人員是最優秀的測試人員
在測試工作中，最常遇到的是和開發人員的PK，作為測試經理還會和專案經理、產品經理的PK進度、質量
作為一名測試人員，一般會遇到以下幾種情況

• 這不是bug
• 這個bug的級別太高了
• bug影響不大，暫不修改

遇到爭執不要怕，記住批判性思維：清楚–準確、切題–深刻，有意義，有邏輯性–公正、全面

• 先檢查自身，是否bug描述不清楚
• 站在使用者角度考慮問題應該讓開發人員瞭解到bug對使用者可能造成的困擾，這樣才能促使開發人員更加積極、高質量的修改bug，在爭執時，可以問一問：如果你是使用者，你可以接收麼？
• bug定級要有理有據
• 提高自身的技術和業務水平，不光要提出問題，最好也能提出解決方案
• 開發人員不接受時，不要爭吵