基礎

測試流程

1)需求研讀：

• 通讀需求了解需求整體內容，然后精讀需求理解需求的每?個業務邏輯，每?句話的意思。
• 在研讀需求過程中的記錄問題，然后通過百度，AI?具，CSDN社區，咨詢朋友，同事，解決遇到的需求問題。
• 如果還有解決不了的問題抽時間和業務溝通，在需求評審之前，盡量把需求吃透

2)需求評審：

• 三?評審，產品主講，主要講解需求中的重點，難點，開發、測試、?起溝通討論問題

3)測試計劃：

• 測試計劃?般由測試經理或者測試組?或者測試經驗豐富的?編寫
• 寫測試計劃之前?般要和開發負責?和業務溝通下，開發提測時間和業務要求的上線時間，根據這兩個時間，確定我們有多少時間編寫案例，多少時間進?測試，做?輪測試，每輪測試做多久
• 測試計劃內容：測試開始時間，結束時間，?員配置，資源配置，測試的標準、?險（需求變動，bug太多，?員調動，測試環境和實際環境不?致）

4)分析需求編寫測試?綱:

• 根據最終版需求，使?xmind(思維導圖)編寫出每個模塊的測試點即編寫測試?綱

5)編寫案例：

• 根據測試?綱，使?多種設計?法設計案例。?如等價類，邊界值，場景法，異常分析法，錯誤推斷法等等，將測試點轉化成具體的測試步驟

6)案例評審：

• 測試主講，產品開發?起參加，查缺補漏 ，同時做好評審會議記錄，會后補充修改案例

7)冒煙測試：

• 主要功能是否可以使?

8)系統集成測試：

• 執?測試?例，?例執?通過就pass，有問題就提交bug ，跟蹤bug，驗證bug

9)回歸測試：

• 缺陷多的模塊、新增模塊、重點模塊進?回歸、根據個?經驗

10)驗收測試:

缺陷管理流程、缺陷狀態

1. 發現bug通過管理?具jira提交給開發
2. 如果是bug，開發修改完成后更改bug狀態為已解決。重新指派給測試
3. 由測試?員進?驗證，確認修改正確，關閉bug
4. 如果不是bug，退回給測試?員并描述退回原因，或為設計如此，或為外部原因，或者不能重現。
5. 驗證未通過的bug重新激活，開發?員繼續修改，直?驗證通過，關閉bug

缺陷單狀態

標題，重現步驟、附件（視頻、log?志、截圖、canlog?志）、嚴重等級、優先級、版本，所屬模塊等等

• 標題：缺陷標題通常需要簡明扼要地描述缺陷所涉及的問題，開發快速了解缺陷的性質
• 重現步驟：能夠幫助開發?員理解問題的真正原因，如果重現步驟能夠詳細清晰地描述，開發?員就可以快速定位和修復缺陷，節省不必要的溝通
• 附件：讓開發更快地獲取到必要信息。例如，截圖、錄屏、?志等多媒體素材能夠有效地幫助缺陷處理?員定位問題，避免不必要的溝通和確認環節。

如何設計測試案例

• 設計測試案例最重要的是要先讀懂需求，只有充分理解了需求，才能寫出全?的有?的測試?例
• 通讀需求了解需求整體內容，然后精讀需求理解需求的每?個業務邏輯，每?句話的意思。在研讀需
• 求過程中的記錄問題，然后通過百度，AI?具，CSDN社區，咨詢朋友，同事，解決遇到的需求問題。
• 如果還有解決不了的問題抽時間和產品溝通，在需求評審之前，盡量把需求吃透

除了需規上已經覆蓋到的場景之外

• 我們還需要需要多參考借鑒其他同類產品中做的好的優秀的功能，多站在??實際使?的?度，多從交互?向考慮設計測試?例
• 然后針對每個模塊先設計流程的?例，包括正流程和異常流程，再根據業務規則設計各種場景?例，
• 再針對欄位，ui，提?信息設計對應的?例，當然涉及到模塊之間的交互場景都要設計到在設計測試?例的時候會結合案例設計?法（等價類，邊界值，場景法、錯誤推測法、異常分析等）進?設計

舉個例?:語?控制空調

• ?先，設計正常調節溫度的流程?例，然后再設計調節溫度低于最低穩定、?于最?溫度、吹腳、吹臉、或者腳臉同時吹、電量低開啟空調、空調切換到舒適模式、切換到節能模式、切換到通?模式、?區同步開啟和未開啟狀態下，跨?區控制空調等等?例，最后還要設計ui界?檢查和提?語的?例
• 調節溫度的案例設計可以采?等價類，邊界值的?法，?如溫度在16~32，有效等價類16度-32度， ?效等價?于16度和?于32度，在這個基礎之上可以?邊界測試下溫度的邊界15，16，32，33

異常分析法： ?絡異常、斷電、??

測試報告包括哪些內容

每?輪測試執?完成之后編寫測試報告

主要包含：

1. 測試?員，被測?機系統版本號，測試時?；
2. 測試內容（被測模塊）；
3. 執??例數；
4. 發現bug 數，其中嚴重的多少條，?般的多少條，輕微的多少條；
5. 是否還有遺留 bug；是否有?險，?險點在哪?；
6. 還有測試結果，通過或者不通過

提交?個bug開發不承認怎么辦

開發如果不承認?般有兩種情況,第?需求中沒有要求，第?開發沒有復現出你提交的bug

第?種情況，需求中沒有提到，那我?般會站在??的?度考慮，是否真的會有這樣的場景，如果有

的話，那我先和開發溝通，曉之以理，動之以情，?般開發都會配合修改的，如果還是不修改的話，

那?般會把情況和業務進?溝通，最終由業務?師進?定奪

第?種情況，可能是開發復現的步驟不對，那這個時候我們就給給他復現?遍，如果復現確實存在問

題，開發?般會承認

如果我們??也不能復現，那有可能這個bug是?個偶現的bug，針對偶現的bug,?般我們會盡可能多

的執??遍，找出出現的原因，或者概率，然后也會去找出當時的?志，結合分析問題。如果?直復

現不了，那我們?般會記錄這個bug然后每個版本都會進?驗證（?般跟蹤5-10個版本）

迭代項?制定執?案例的策略是什么？

?先，要選擇本輪迭代新增和修改的案例其次，要選擇本輪迭代內容相關聯的案例，?如修改了?速??的，就會把?速??的案例都回歸?

遍，（開發?般會給影響性評估表，我們也會根據??的經驗判斷影響性）

然后，還要把所有的模塊的流程案例和主要邏輯案例執??遍