軟件測試的生命周期

軟件測試貫穿軟件的整個生命周期。

軟件測試的生命周期是指測試流程，這個流程是按照?定順序執行的?系列特定的步驟，去保證產品質量符合需求。在軟件測試生命周期流程中，每個活動都按照計劃的系統的執行。每個階段有不同的?標和交付產物。

各階段具體內容：

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

Bug

Bug 的概念

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

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

描述 Bug 的要素

為什么描述 Bug 還有要素要求？因為人們在編寫?檔的時候，經常會出現自己想表達的內容和寫出來的內容南轅北轍的現象。

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

**描述Bug的基本要素：問題出現的版本、問題出現的環境、問題出現的步驟、預期結果、實際結果。**

1. 問題出現的版本：

開發人員需要知道出現問題的版本，才能夠獲取對應版本的代碼來重現故障，并且版本的標識也有利于統計和分析每個版本的質量。

2. 問題出現的環境：

環境分為硬件環境和軟件環境，如果是 web 項目，需要描述瀏覽器版本，客戶機操作系統等；如果是 app 項目，需要描述機型、分辨率、操作系統版本等。詳細的環境描述有利于故障的定位。

3. 問題出現的步驟：

描述問題重現的最短步驟。

4. 預期結果：

要讓開發人員指導怎么樣才是正確的，尤其要以用戶的角度來描述程序的行為是怎樣的。如果是依據需求提出的故障，能寫明需求的來源是最好的。

要相信：測試人員是最懂需求的。

5. 實際結果：

描述問題實際出現的現象。

注意：

• 某些公司會有一些其他的要求，例如故障的分類：功能故障，界面故障，兼容性故障等。有些有優先級的分類，嚴重影響測試需要開發人員優先修改的，可以設置優先級為高。
• 不要把多個 Bug 放到一起：在無法確認是同一段代碼造成的故障時，不要將 Bug 放在一起提交。

案例

1. 問題出現的版本：?歌瀏覽器版本 133.0.6943.127（正式版本） （64 位）
2. 問題出現的環境：Windows 11 專業版
3. 問題出現的步驟：
   1. 打開谷歌瀏覽器
   2. 輸入網址：https://www.101eduyun.com/sunrise/login/login.do
   3. 等待頁面第一個背景圖上的二維碼渲染完成
4. 預期結果：小程序二維碼不會被登錄模塊遮擋，二維碼可以正常掃描
5. 實際結果：小程序二維碼被登錄模塊遮擋，二維碼不可以正常掃描

Bug 級別

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

**Bug 級別的定義每個公司都不一致，在定義級別之前需要查看公司規范。**?般分為：崩潰、嚴重、?般、次要。

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

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

與開發產生爭執怎么辦？【高頻面試題】

在測試工作中，最常遇到的是測試人員和開發人員的 PK，測試經理還會和項?經理、產品經理的 PK 進度、質量。作為?名測試人員，要理性處理與開發人員的沖突。

先檢查自身，Bug 是否描述的不清楚

如果能正確地、?質量地錄入?個 Bug，那么基本上已經成功地與開發人員溝通了?大半的關于 Bug 的信息。但是總會有“書難達意”的時候，這時就需要測試人員主動與開發人員進行溝通了。

如果測試人員發現在寫完?個缺陷后，好像還有很多關于 Bug 的信息沒有表達出來，或者很難用書?語言表達出來時，就應該在提交 Bug 后，?上找相關的程序員解釋剛才錄入的 Bug，確保程序員明? Bug 描述的意思，而不要等到開發人員找自己了解更多的信息。

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

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

Bug 的定級要有理有據

Bug 定級時，不僅要參考 Bug 定級描述文檔，還要考慮 Bug 是否會影響到流程，往往用戶的 Bug 級別和我們的是有區別的，需站在用戶的角度定考慮定位級別。

提?自身技術和業務水平，做到不僅能提出問題，還能構給出解決的思路或方案

能夠提出問題，并給出解決問題的思路或方案，這樣會讓人更加信服。

在工作中，資深測試工程師和初級測試工程師提出的同?個 Bug，兩者的結果完全不同，最大的差別是資深測試工程師往往會提出解決方案。而?此以往，權威性逐漸的建立起來，開發人員看到 Bug 的第?反應，就是這是?個 Bug，而不是這是?個 Bug嗎？

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