1. 軟件測試的生命周期

軟件測試貫穿于軟件的整個生命周期，針對這句話我們?起來看?下軟件測試是如何貫穿軟件的整個生命周期。
軟件測試的?命周期是指測試流程，這個流程是按照?定順序執?的?系列特定的步驟，去保證產品質量符合需求。在軟件測試?命周期流程中，每個活動都按照計劃的系統的執?。每個階段有不同的?標和交付產物

各階段具體內容：

需求分析	測試計劃	測試設計與開發	測試執?	測試評估	上線	運?維護
???度：軟件需求是否合理 技術?度：技術上是否可?，是否還有優化空間 測試?度：是否存在業務邏輯錯誤、冗余、沖突等問題	制定測試計劃：什么時候開發測試，什么時候結束測試，耗時多久	參考需求?檔、技術?檔等編寫測試?例 寫測試?檔，明確標注使?到的測試?法，測試?具，測試形式等等	充分利?測試?例和測試?具對項?盡可能做到全??的測試覆蓋	測試是否通過，本次測試是否有遺留的BUG，最終測試?員需要產出?個測試報告	項?測試結束后，將項?發布到線上環境，測試?員需求跟蹤上線并測試線上環境下軟件的運?是否正確	測試?員需要參與項?的實施?作。測試?員對項?產品的業務和操作?常了解，加上測試?員 的溝通表達能??般都?較強，所以測試?員可以參與??使?軟件的培訓，在試運?項?時收集問題并及時反饋給相關負責?

2. BUG

2.1 bug的概念

定義：?個計算機bug指在計算機程序中存在的?個錯誤(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，這些bug使程序?法正確的運?。Bug產?于程序的源代碼或者程序設計階段的疏忽或者錯誤
準確的來說：

1. ?當且僅當規格說明是存在的并且正確，程序與規格說明之間的不匹配才是錯誤。
2. 當需求規格說明書沒有提到的功能，判斷標準以最終??為準：當程序沒有實現其最終用戶合理預期的功能要求時，就是軟件錯誤。

?2.2 描述bug的要素

為什么描述bug還有要素要求？

在?理學上說，?們在編寫?檔的時候，經常會出現??想表達的和寫出來的內容往往南轅北轍

bug描述：瀏覽器打開鏈接失敗

該描述下，沒有明確說明哪個瀏覽器，失敗的具體表現是什么，對于開發?員來說?法捕捉到更多有效的信息，會造成溝通效率低下，?作質量低下等問題

?描述bug的基本要素：問題出現的版本、問題出現的環境、問題出現的步驟、預期結果、實際結果（這五個是必需的，但不限于這些~）

例如如下案例：

可以看到這個是不同瀏覽器打開的登錄界面，界面同時提供了掃碼登錄，但谷歌瀏覽器打開，登錄界面遮住了二維碼，這就是一個bug，那該如何描述這個bug呢？

問題出現的版本：谷歌瀏覽器版本 123.0.6312.123（正式版本） （64 位）
問題出現的環境：Windows家庭版 問題出現的步驟：

1. 打開谷歌瀏覽器，輸??址https://www.101ed......
2. 等待首頁頁面渲染完成

預期結果：?維碼與登陸模塊不會出現遮擋，?維碼可以正常掃描

實際結果：?維碼被登陸模塊遮擋，?維碼掃描失敗

2.3 bug級別

通過定義bug的級別，能夠明確看出問題的嚴重程度。?作中開發?員通常需要按照bug的級別來分配優先級來處理bug，除此之外，通過bug級別也能夠體現出開發?員的開發質量。

bug級別?般分為：崩潰、嚴重、?般、次要

崩潰	嚴重	?般	次要
阻礙開發或測試?作的問題；造成系統崩潰、死機、死循環，導致數據庫數據丟失，與數據庫連接錯 誤，主要功能喪失，基本模塊缺失等問題。如：代碼錯誤、死循環、數據庫發?死鎖、重要的?級菜單 功能不能使?等（該問題在測試中較少出現，?旦出現應?即中?當前版本測試）。	系統主要功能部分喪失、數據庫保存調用錯誤、用戶數據丟失，?級功能菜單不能使用但是不影響其他 功能的測試。功能設計與需求嚴重不符，模塊?法啟動或調?，程序重啟、?動退出，關聯程序間調? 沖突，安全問題、穩定性等。如：軟件中數據保存后數據庫中顯示錯誤，??所要求的功能缺失，程序接?錯誤，數值計算統計錯誤等（該等級問題出現在不影響其他功能測試的情況下可以繼續該版本測 試）。	功能沒有完全實現但是不影響使?，功能菜單存在缺陷但不會影響系統穩定性。如：操作時間?、查詢時間?、格式錯誤、邊界條件錯誤，刪除沒有確認框、數據庫表中字段過多等(該問題實際測試中存在最多）	界?、性能缺陷，建議類問題，不影響操作功能的執?，可以優化性能的?案等。如：錯別字、界?格 式不規范，??顯?重疊、不該顯?的要隱藏，描述不清楚，提?語丟失，?字排列不整?，光標位置 不正確，??體驗感受不好，可以優化性能的?案等（此類問題在測試初期較多，優先程度較低；在測 試后期出現較少，應及時處理）

?2.4 bug的生命周期

測試?員在執?測試的過程中如有發現bug，需要在對應的bug管理平臺來創建bug（bug?命起源），創建好的bug需要被開發?員修復，以及測試?員的持續跟蹤和測試。

• New:新發現的Bug，未經評審決定是否指派給開發?員進?修改。
• Open：確認是Bug，并且認為需要進?修改，指派給相應的開發?員。
• Fixed:開發?員進?修改后標識成修改狀態，有待測試?員的回歸測試驗證。
• Rejected：如果認為不是Bug，則拒絕修改。
• Delay:如果認為暫時不需要修改或暫時不能修改，則延后修改。
• Closed：修改狀態的Bug經測試?員的回歸測斌驗證通過，則關閉Bug。
• Reopen：如果經驗證Bug仍然存在，則需要重新打開Bug，開發?員重新修改。

?效的bug：open->closed open-rejected-closed

2.5 與開發產生爭執怎么辦（很重要哦）

在測試?作中，最常遇到的是和開發?員的PK，作為測試經理還會和項?經理、產品經理的PK進度、質量。作為?名測試?員，?般會遇到以下幾種情況：

遇到爭執不要怕，要理性的分析和反饋問題。

2.5.1 先檢查自身，是否bug描述不清楚

如果能正確地、高質量地錄??個Bug，那么基本上已經成功地與開發?員溝通了一大半的關于Bug的信息。但是總有“書難達意”的時候，這時就需要測試?員主動與開發?員進?溝通了。 如果測試?員發現在寫完?個缺陷后，好像還有很多關于Bug的信息沒有表達出來，或者很難用書?語?表達出來時，就應該在提交Bug后，?上找相關的程序員解釋剛才錄?的Bug，確保程序員明白Bug描述的意思，而不要等待開發?員找自己了解更多的信息。

2.5.2 站在用戶角度考慮并拋出問題

站在用戶?度考慮問題 應該讓開發?員了解到Bug對用戶可能造成的困擾，這樣才能促使開發?員 更加積極地、高質量地修改Bug。在爭執時，可以問?句：如果你是用戶，你可以接受么？

2.5.3 BUG定級要有理有據

BUG定級時，不僅要參考BUG級別，還要考慮BUG是否會影響到流程，往往用戶的BUG級別和我們的是有區別的，需站在用戶的角度考慮定位級別。同時需要將bug定級描述文檔拿出來，然后將bug的表現和bug定級描述文檔進行匹配，說服程序猿。

2.5.4 提高自身技術和業務水平，做到不僅能提出問題，最好也能給出解決方案

提???的業務和技術水平，不但要做到能提出問題，還能夠提出解決問題的思路。這樣才能更讓?信服。 在?作中，你會發現同?個bug，資深測試?程師提出和初級測試?程師提出，兩者的結果完全不同，兩者最?的差別是資深測試?程師往往會提出解決方案。而長此以往，權威性逐漸的建立起來，那么開發?員看到bug的第?反應，就是這是?個bug，而不是這是?個bug嗎？

注意：可以給出解決?案，但是不能喧賓奪主，命令式讓開發?員按照自己的想法來修改。

2.5.5 bug評審

如果確實是bug，友好溝通不能解決問題，那么就召開bug評審。

bug評審主要解決兩個問題：

1. 決定如何處理bug
2. 分析缺陷產?的原因，找出預防的對策

bug評審至少需要項目組各個方面的代表參加：

1）測試代表

測試代表主要從Bug的具體表現、嚴重程度等方面提供信息，并提出自己對Bug的處理意見。需要注意的是，測試?員不應該?味地要求對Bug進?修改，因為修改可能帶來回歸的風險，同時帶來的是回歸測試的?作量，如果時間?較緊迫，修改后剩余的時間若不足以做?次有效的回歸測試，可能不修改是個明智的選擇。

2）開發代表

開發代表主要從修改缺陷的難度和風險出發，考慮缺陷修改需要付出的代價，以及可能影響的范圍、可能引發的風險等，如果決定要修改，還要討論出修改的初步方案。

3）產品代表

產品代表主要從產品的整體計劃、用戶的要求等方面對缺陷的修改必要性、缺陷修改的時間和版本提出自己的意見。