1、測試流程：

測試編寫測試計劃→測試編寫測試用例，集合相關人員評審測試用例，開發編寫程式碼，轉測給測試，測試先進行冒煙測試，然後測試進入到測試階段，完成所有的缺陷修復之後，進行驗收測試，編寫測試報告，最後準備產品上線

2、測試用例的要素：

1.用例ID

2.用例名稱

3.測試目的

4.測試級別

5.參考資訊

6.測試環境

7.前提條件

8.測試步驟（通俗易懂，清晰明瞭）

9.預期結果

10.設計人員

3、測試用例編寫的注意事項：

與大家保持一致、 清晰明瞭、 易懂、 具體

4、BUG注意事項：

1、BUG標題一定要表達出問題的核心，看了標題就知道是什麼問題

2、BUG步驟要清晰明瞭，通俗易懂，步驟要非常詳細

3、提交BUG最好有問題的截圖

4、提交BUG最好有詳細的日誌資訊（主要針對的是後臺服務）

5、印象最深的BUG

6、如果你提交的BUG,開發不承認，你會怎麼辦？

7、需求文件裡面有什麼？

1、本次迭代的頁面互動圖

2、業務邏輯流程圖

3、關於業務邏輯的描述

8、一個功能，實際測試5天，給你3天的時間，你是否接受？

答：接受，但是我會評估這個工作量，如果評估下來，認為是4天的工作量，而不是3天的，那麼我會找你詳細的說明理由。

9、一個迭代多少天？具體每天的工作內容是什麼？

第一週：

週一：熟悉需求，評審需求，列計劃

週二：編寫測試用例

週三：評審測試用例，完善測試用例

週四&週五：編寫自動化測試case，等開發轉測，以及冒煙測試驗證

第二週：

週一：開始第一輪測試

週二：迴歸所有的bug，開始第二輪測試

週三：開啟系統測試，準備提交驗收測試

週四：編寫測試報告，準備上線前的工作

週五：跟蹤上線後的產品情況，然後專案內部覆盤

10、一個團隊裡面多少人？

pm:1 test:4 前端：2 後端：5 產品：1 總人數：13

預估工時：大多數時候,以天為單位

story的特性：

1、可以獨立的轉測

2、可以獨立的測試

3、有開始有結束

11、文件有哪些？

1、需求設計文件

2、測試計劃

3、測試用例

4、測試報告

5、開發技術方案

測試方案：

背景

整體測試思路

12、測試報告包含的點：

1、版本，參與人，測試周期

2、本次迭代功能測試結果

3、系統已有功能測試結果

4、核心流程測試結果

5、BUG整體情況

A、總的BUG數

B、已解決數

C、遺留的（必須要和管理層溝通，評估）

6、測試風險

7、測試結論