1.功能測試流程（工作流程）

需求分析 -- 測試點分析（xmind）-- 編寫測試計劃/用例及評審 -- 執行測試用例（開發提交測試）-- 發現缺陷通過缺陷管理工具提交 -- 回歸測試及bug驗證（開發提測新版本） -- 測試報告編寫及評審

• 測試計劃
  是指導整個測試過程的綱領性文件，主要回答 “為什么測、測什么、怎么測、誰來測、何時測、資源有哪些” 等宏觀問題，目標是確保測試活動有序、高效地進行，覆蓋項目的測試需求和質量目標。

• 測試用例
  是測試執行的具體依據，主要描述 “如何測試某個功能 / 場景”，包括輸入數據、操作步驟、預期結果等，目標是驗證軟件是否符合需求規格。

2.常用的測試用例設計方法

• 用等價類 + 邊界值覆蓋輸入驗證；
• 用場景法覆蓋業務流程；
• 用判定表處理多條件邏輯；
• 用錯誤推測法補充潛在缺陷。

3.項目團隊多少人？測試人員幾個？如何分工？

項目團隊大概xx人，測試人員xx人，我們一般按照功能模塊進行分工

4.最近一個項目一共寫了多少條用例？發現了多少個bug?

大概寫了xx條測試用例，一共xx人,編寫了xx時間，在編寫的過程中發現需求模糊的地方還需要和產品經理進行溝通。

一共發現了xx個bug,開始的輪次發現的缺陷會比較多一些，后面回歸測試中逐漸減少，其中一般級別的bug數量最多。

5.你一天大概寫多少條測試用例？

按照我目前的能力，按照系統的復雜度來看，通常一天可以寫一百多條，如果是需求有模糊不清的地方或者業務比較復雜，可能寫的少一些，幾十條。

6.如果你發現了一個bug，但開發人員不認可，你會怎么處理？

如果我提交了一個bug，開發人員認為不是，那么我首先要再次確認下這個bug是否存在，是否影響用戶的實際使用，確認后，在和開發人員進行溝通，講清楚這個缺陷的復現步驟和對用戶的影響，爭取能夠取得開發人員的認可。如果還是不能達成一致，那么我本著對用戶負責的態度，需要將此bug的情況上報給測試經理和項目經理，由他們進行裁決。

7.一個不能復現的bug需要上報嗎？

這個問題還真遇到過，一般發現的bug都需要反復求證復現的步驟，確認百分百復現后才上報，但遇到比較嚴重的問題，雖然不能復現，但還是有一定的出現幾率，那么我們也要上報，需要提交給開發人員進行定位或者觀察，但這種bug我們一般會在缺陷報告中標明出現的概率，比如 必現/大概率復現/小概率復現/僅出現一次。

8.測試工作通常是什么時候開展的？

項目的測試工作一般是在需求階段就會介入，參與需求的討論，需求經過評審之后，我們就開始依照需求進行測試用例的編寫。

需求討論主要是從測試人員的角度審查需求描述是否清晰，準確，是否可以編寫用例進行測試。

9.項目的迭代周期一般多長時間？

項目初始時迭代周期一般長一些，大概一兩個月，后面根據迭代的功能和修改的缺陷時間逐漸縮短，一般一兩周一個迭代周期，項目上線前期甚至一周幾個版本。每個月大概迭代十個版本。

10.使用什么管理缺陷的？

使用的pingcode/禪道，項目管理工具，可以用來管理產品的需求，項目的任務，測試用例和跟蹤bug，主要用來管理測試用例和缺陷（和需求）

編寫了測試用例，依照開發提交的版本進行測試用例的執行，執行的過程中發現bug會提交缺陷報告，開發修改后，進行跟蹤驗證。

常見的缺陷管理工具主要有以下這些：

1. Jira?：由 Atlassian 開發的商業級項目與事務跟蹤工具，可用于軟件開發、缺陷管理、需求追蹤等領域。其能創建、跟蹤多種事務類型，支持自定義事務生命周期、狀態，擁有豐富的報告和儀表板，并且可以與 Git、Jenkins 等工具集成，有大量插件來滿足多樣化需求，適合中大型開發團隊，特別是對缺陷流程場景要求復雜的團隊。
2. PingCode?：這是國內市場占有率較高的研發項目管理工具，具備成熟的缺陷管理能力。它可以收集來自 App、web/H5 網站等渠道的 Bug 問題，支持成員、角色等設置，還能關聯需求、測試任務和主流開發者工具，同時可生成缺陷平均生命周期、致命缺陷占比等豐富報表，適合汽車電子、互聯網等多行業的中大型團隊使用。
3. Bugzilla?：由 Mozilla 公司提供的開源免費缺陷跟蹤工具，能管理缺陷從提交、修復到關閉的完整生命周期，有強大的檢索功能，支持自定義字段與權限管理，但安裝過程較為繁瑣，適合預算有限卻注重流程管控的團隊。
4. Worktile?：屬于靈活性較強的項目管理工具，雖不是專門針對缺陷管理，但國內很多中小團隊會用它進行缺陷管理。其可以通過定制看板和任務列表維護缺陷管理流程，支持詳盡的缺陷屬性設置和豐富的數據報表，此外還能滿足企業 OKR 管理、審批等多種工具化管理需求。
5. Mantis?：基于 web 的 Php+Mysql 開源缺陷管理平臺，安裝和操作都比較方便，也有截圖功能，報表功能較為強大，可通過漢化包進行漢化，適合小型到中型規模的團隊。
6. TestRail?：由德國 Gurock Software 公司開發，是一款領先的測試用例管理工具，能提供測試用例管理、測試執行、結果追蹤和測試報告等功能，還可以與 Jira、Bugzilla 等多種第三方工具集成，使缺陷跟蹤流程更加順暢。
7. 板栗看板?：可視化缺陷協作與修復工具，通過任務卡片、看板與甘特圖視圖結合來展示缺陷處理狀態，支持責任人指派與提醒設置，還能以進度熱力圖等多視角呈現，適合中小型敏捷團隊以及多角色聯合修復場景。
8. YouTrack?：由 JetBrains 出品的專業缺陷工具，將缺陷管理和知識庫、時間追蹤、Scrum 板等功能集成在一起，快捷鍵支持強大，界面響應速度較快。

11.測試計劃和測試報告一般包含哪些內容？

注：通常測試計劃和測試報告是由測試組長/主管/經理編寫，但測試組或測試組內的主要測試人員也會參與編寫，因此所有人都需要知道測試計劃和測試報告的主要內容。

參考：

測試計劃一般包含測試的目的，測試的范圍，測試的策略和方法，測試的軟硬件環境，測試的進度安排和測試風險評估等。

測試報告是在整個項目測試完成之后進行編寫，主要時統計和分析整個測試過程的活動和產生的數據，會統計測試用例的情況，比如一共編寫了多少測試用例，執行了多少測試用例，通過了多少測試用例，每個測試人員編寫了多少測試用例等。

還會統計和分析項目缺陷的情況，比如缺陷的狀態，是否已經修改還是未修改，缺陷的嚴重級別，缺陷的高發點， 項目當中哪個模塊發現的bug比較多，通常缺陷的分別會符合二八定理，也就是百分之二十的模塊發現了百分之八十的缺陷。

12.怎么看待測試價值？

測試的核心價值是發現問題、預防問題，幫助產品質量穩步提升。它不是簡單的‘點點點’，而是理解需求、模擬用戶、用邏輯和策略提前發現風險。好的測試是降本增效的關鍵環節。

13.如何判斷哪些用例適合做自動化？

優先選擇操作固定、邏輯穩定、重復頻次高的用例自動化。頻繁變動或視覺判斷類場景就不適合。

14.項目馬上要上線了，突然發現一個bug，做為測試要如何做？

如果項目馬上要上線時發現了bug,我會立即確認并復現，把復現步驟、環境、日志、截圖/錄屏記錄清楚；然后迅速評估嚴重性：若影響核心流程、數據或安全就判為阻塞，必須暫停上線并修復，否則評估是否可以做臨時規避或記錄為已知問題后上線。接著第一時間同步項目、開發，提供影響分析和處理建議（延遲上線/熱修復/上線后修復并寫明風險）；如果決定修復，我會配合開發定位并在修復后立即驗證并做針對性回歸，上線時執行冒煙測試驗證并準備回滾預案。最后上線后做問題根因分析，補充用例和優化預發布流程，避免復發。