目錄
一.軟件測試的生命周期
二.bug是什么？
三.如何描述一個bug？
四.bug的級別
五.bug的生命周期
六.測試與開發產生爭執怎么辦？（重要！！！）
一.軟件測試的生命周期
軟件測試人員不僅要具備開發能力、測試能力，最好具有一定的產品分析能力
需求分析：測試人員進行技術可行性的分析，業務是否會出現邏輯沖突導致用戶的流失（例如購物車本來最多能存放50件商品，現在改成最能只能存放10件），再根據產品分析分析出購物車允許存放數量應該增加而不是減少
測試計劃：顧名思義，計劃時間內容
測試設計與開發：根據需求、技術文檔等編寫測試用例（方法+工具+形式）
測試執行：開始測試
測試評估：測試執行結束后，不能認為項目100%的問題都被發現了。評估一下當前項目測試是否通過，測試了項目的哪些方面，是否會有遺留的bug
運行維護：產品上線以后，及時發現問題，也正因此軟件測試人員一般也是最了解產品的人員，一般演示會議也是由軟測人員來進行
上線（本地寫的代碼提交到碼云上/部署到服務器上，稱為上線流程）：
實際工作中，分為4個流程 “ 沙盒->小流量->全流量->全線上 ”
因為上線過程中可能存在問題，線下測試沒有問題線上可能會出現問題（例如模塊、單元的沖突）
- 沙盒：企業內部的線上環境測試，可以供內部人員進行測試
- 小流量：部分線上真實用戶可以使用到，測試人員要在線上手動測試，還要觀察有沒有錯誤日志（游戲內測）
- 全流量：所有的真實用戶都可以用到（游戲demo，未完全優化好的產品）
- 全線上：上線前的所有測試流程全部完畢，可以上架steam（doge）
二.bug是什么？
定義：?個計算機bug指在計算機程序中存在的?個錯誤(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，這些bug使程序?法正確的運?。Bug產?于程序的源代碼或者程序設計階段的疏忽或者錯誤。
1.當且僅當規格說明是存在的并且正確，程序與規格說明之間的不匹配才是錯誤。
一切都要以需求出發，即驗證軟件產品的特性是否符合用戶的需求；根據用戶需求創造出的測試用例，如果測試執行后獲得的結果與預期不符，那么就能稱為一個bug
2.當需求規格說明書沒有提到的功能，判斷標準以最終??為準：當程序沒有實現其最終??合理預期的功能要求時，就是軟件錯誤。
就比如一個界面做得不好看，字體太小但用戶群以老年人為主；這種時候倘若規格說明書中沒有明確提到，那么我們還是以用戶需求為主
三.如何描述一個bug？
bug描述：瀏覽器打開鏈接失敗
該描述下，沒有明確說明哪個瀏覽器，失敗的具體表現是什么，對于開發?員來說?法捕捉到更多有效的信息，會造成溝通效率低下，?作質量低下等問題。
描述bug的基本要素：問題出現的版本、問題出現的環境、問題出現的步驟、預期結果、實際結果
版本和環境沒有強區分，就算把瀏覽器版本寫在環境里也是可以的，只要能夠給上關鍵信息供工作人員去復現可以實現，但也不能說把軟件版本寫在環境里
四.bug的級別
通過定義bug的級別，能夠明確看出問題的嚴重程度。?作中開發?員通常需要按照bug的級別來分配 優先級來處理bug，除此之外，通過bug級別也能夠體現出開發?員的開發質量。
bug級別?般分為：崩潰、嚴重、?般、次要（有些公司可能會用P0、P1、P2、P3代替）
- 崩潰：阻礙開發或測試的問題，造成閃退、死循環等……
- 嚴重：主要功能部分喪失（例如一款購物軟件，可以打開軟件以及添加商品到購物車，但無法下單支付）
- 一般：功能沒有完全實現但是不影響使用（例如一款搜索引擎，必須完整打出想要搜索的內容才能搜索出結果，沒有搜索關鍵詞）
- 次要：界面、性能缺陷（搶票的時候提示搶票的人太多了，無法進行搶票）
定義bug的級別意義在哪？
1）評估程序員的開發能力
2）年終獎評定
3）bug修復的優先級
五.bug的生命周期
測試?員在執?測試的過程中如有發現bug，需要在對應的bug管理平臺來創建bug（bug?命起 源），創建好的bug需要被開發?員修復，以及測試?員的持續跟蹤和測試。
- New:新發現的Bug，未經評審決定是否指派給開發?員進?修改。
- Open：確認是Bug，并且認為需要進?修改，指派給相應的開發?員。
- Fixed:開發?員進?修改后標識成修改狀態，有待測試?員的回歸測試驗證。
- Rejected：如果認為不是Bug，則拒絕修改。
- Delay:如果認為暫時不需要修改或暫時不能修改，則延后修改。
- Closed：修改狀態的Bug經測試?員的回歸測試驗證通過，則關閉Bug。
- Reopen：如果經驗證Bug仍然存在，則需要重新打開Bug，開發?員重新修改。
無效的bug：open->closedopen->rejected->closed
如果時間急迫，bug又是次要級別的時候，可以和無效bug同樣的處理方式
六.測試與開發產生爭執怎么辦？（重要！！！）
1.先檢查??，是否bug描述不清楚
反省自己，是不是測試的時候出現了誤操作、bug描述不夠清晰
2.站在用戶角度考慮問題
功能正常只是測試的一部分，還需要考慮用戶的使用感受
但也要三思而后行，如果鉆牛角尖提出太多bug容易讓開發人員惱火
3.bug定級要有理有據
一個次要bug定級定了嚴重，包會讓開發人員感到難受的（畢竟和開發人員的年終獎有關）
4.提高自身技術，做到不僅能解決問題還能給出解決方案
5.bug評審
如果一個bug是會嚴重影響到用戶體驗的，但開發人員拒不修改，這個時候就可以召開bug評審了
至少要有測試代表、開發代表以及產品代表三方面參加
主要解決如何處理問題、分析缺陷產生的原因并找出預防對策
——學習筆記)
