軟體測試：基礎篇

2019 年 10 月 6 日
筆記

軟體測試：基礎篇

本節主要內容 – 軟體測試的生命周期 – 如何描述一個bug – 如何定義bug的級別 – bug的生命周期 – 如何開始第一次測試 – 測試的執行和bug的發現 – 產生爭執怎麼辦

軟體測試的生命周期

軟體測試的生命周期生命周期需求階段 —> 測試計劃 —> 測試設計、測試開發 —> 測試執行 —> 測試評估

每個測試階段的分析 – 需求階段 -測試人員了解需求、對需求進行分解，得出測試需求。 – 計劃階段 -根據需求編寫測試計劃、測試方案。 – 設計階段 -測試人員適當的了解設計，對於設計測試用例是很有幫助的，測試人員搭建測試用例框架，根據需求和設計，編寫一部分測試用例。編寫測試用例的同時也是對需求進行的一個測試。 – 編碼階段 -測試人員一般是不需要編碼的，但已經編碼的模組，專業的白盒測試人員可以計劃執行單元測試，完善、細化測試用例以及調整測試計劃和方案。 – 測試階段 -測試階段是軟體測試人員最為重要的工作階段，根據測試用例和計劃執行測試，在執行的過程中記錄、管理缺陷，測試完成後編寫測試報告。編寫測試報告是為了對缺陷進行分析。 – 運行維護 -測試人員需要參與項目的實施工作。

一個合格的 bug 描述應包括哪些部分

應包括以下部分： 1. 發現問題的版本開發人員需要知道出現問題的版本，才能夠獲取對應版本的程式碼來重現故障。並且版本的標識也有利於統計和分析每個版本的品質。 2. 問題出現的環境環境分為硬體環境和軟體環境，如果是web項目，需要描述瀏覽器版本，客戶機作業系統等，如果是app項目，需要描述型、解析度、作業系統版本等。詳細的環境描述有利於故障的定位。 3. 錯誤重現的步驟描述問題重現的最短步驟。 4. 預期行為的描述要讓開發人員指導怎麼樣才是正確的，尤其要以用戶的角度來描述程式的行為是怎樣的。如果是依據需求提出的故障，能寫明需求的來源是最好的。 5. 錯誤行為的描述描述錯誤的現象。crash等可以上傳log，UI問題可以有截圖。 6. 不要把多個bug放到一起在無法確認是同一段程式碼造成的故障時，不要將bug放在一起提交

如何定義bug的級別

bug的定義每個公司都不一致，在定義級別之前需要查看公司規範。

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

最後，測試人員將出現的以上缺陷全部提交到缺陷管理系統上。有些公司將bug的級別定義為A、B、C、D、E這5種。

bug 的生命周期

即從出現到消亡的過程。測試人員應該跟蹤一個bug的整個生命周期，從New到Closed的所有狀態。 BUG狀態轉換圖

New：新發現的Bug，交給指派的開發人員進行相應的修改。
Open：開發負責人確認是Bug，並且認為需要修改，指派給相應的開發人員。
Fixed：開發人員進行修改後標示成修改狀態，有待測試人員的回歸測試驗證。
Rejected：如果認為不是Bug，則拒絕修改。
Delay：如果認為暫時不需要修改或暫時不能修改，則延後修改。
Closed：修改Bug的狀態經測試人員的回歸測試通過後，關閉Bug。
Reopen：如果經驗證的Bug仍然存在，則需要重新打開Bug，開發人員重新修改。

如何開始第一次測試

準備工作 1. 閱讀所有項目有關的文檔（需求文檔、設計文檔、用戶手冊）。 2. 了解項目的背景、人員組成、儘可能的了解需求和業務。 3. 熟悉項目所使用的測試管理工具、配置管理工具，獲取對應的地址和登錄方式。 4. 閱讀已有的測試方案和測試用例。 5. 閱讀舊有的bug庫，了解系統功能。 6. 了解公司的規範要求，特別是用例編寫規範、用例執行規範、bug提交規範、測試工具工具使用規範等。

確認具體的工作內容（向測試組長） 1. 測試計劃是什麼？ 2. 測試內容是什麼？時間？ 3. 我要測試的內容開發人員是誰？需求人員是誰？ 4. 我的測試內容是否需要特殊的測試資源？資源是否滿足？

測試執行和BUG管理

開始測試 1. 打開測試管理工具用例模組，開始執行用例； 2. 發現bug，進行復現並確認bug的復現步驟； 3. 記錄bug； 4. 溝通bug； 5. 驗證已提交的bug； 6. 確認本次測試完成； 7. 編寫測試報告。

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

產生爭執怎麼辦

在測試過程中，最常遇到的是和開發人員的PK，作為一名測試人員，一般會遇到以下集中情況： – 這個不是bug – 這個bug的級別太高了 – bug影響不大，暫不修改

遇到爭執時不要怕，做法有： 1. 先檢查自身，bug描述的是否不清楚。 2. 站在用戶角度考慮問題，應該讓開發人員了解到bug對用戶可能造成的困擾，這樣才能促使開發人員更加積極地、高品質地修改bug。 3. bug定級要有理有據：BUG定級時，不僅要參考BUG級別，還要考慮BUG是否會影響到流程，往往用戶的BUG級別和我們的是有區別的，需站在用戶的角度定考慮定位級別。 4. 提高自身的技術和業務水平：不光要提出問題，最好也能提出解決方案。 5. 開發人員不接受時，不要爭吵：可能你已經經過了多輪溝通，但是開發人員仍然拒不接受，此時可以發起bug評審。缺陷的評審應該包括以下兩個層面：

本文轉自：https://blog.csdn.net/bit666888/article/details/81061007