1.測試用例評審的流程是什麼？

目的：主要是為了開展測試用例評審工作提供指引，規範測試用例管理工作。

流程：

測試用例是否按照公司定義的模板進行編寫的；

測試用例的本身的描述是否清晰，是否存在二義性；操作步驟應與描述是否相一致；

測試用例是否覆蓋了所有的需求；測試用例是否具有可執行性

測試用例應有正確的名稱和編號,測試用例應標註有執行的優先順序。

2.怎樣分析效能測試結果？

1、檢視聚合報告和伺服器的資源使用圖，檢查響應時間，事務成功率，CPU，記憶體和IO使用率是否達到要求，如果出錯率達到了總請求數的3%，我們會檢查是什麼原因導致的，修改好後，重新測試；

2、如果出現了效能瓶頸，比如響應時間，或者CPU使用率不達標，我們會從伺服器上匯出日誌，分析是哪個地方導致響應時間過長，如果分析不出來，就叫上開發一起討論，確定問題後，就提單給開發修復，修復好了就進行迴歸測試。

3.請說幾個常見的狀態碼？

200：請求傳送成功。

302：代表重定向。

400：客戶端傳送的請求語法錯誤。

401：請問的頁面沒有授權。

403：沒有許可權訪問這個頁面。

404：沒有這個頁面。

500：伺服器內部異常。

4.請描述下介面測試與UI測試是如何協同測試的？

1、有一部分是重疊的，Ui測試是通過前端寫的介面，是來呼叫介面的，而介面測試是直接呼叫介面。

2、排除前端的處理邏輯與呼叫的正確性，在理論上介面測試是可以覆蓋所有的Ui測試，但實際中，如介面層覆蓋所有的業務流，在Ui上只測試前端的邏輯，而最終的結果會忽視很多原有的功能點，導致了Ui測試的不充分，那麼會存在人多分工且時間充分的時候可以嘗試介面去做業務流的全覆蓋，否則不要輕易的去嘗試。

5.你們專案最佳的併發使用者數是多少？

我們當時做到1500個併發使用者的時候，查詢功能的響應時間超過了效能指標2秒多，原因是有幾個表的索引建得不合理導致的，我們當時做到1500併發使用者後，就沒再繼續增加使用者量了

6.如何判斷網路是否存在瓶頸？

在效能測試結束之後，我們會根據效能測試的結果，檢視在整個效能測試過程中，網路的吞吐量是多 少，如果網路的吞吐量佔到了伺服器的70%以上，我們就認為網路存在瓶頸，通常會增加頻寬或者壓縮傳輸資料。

7.如何判斷響應時間不達標

響應時間不達標的話，我們會根據效能測試結果先檢檢視下是否是伺服器頻寬存在問題，如果頻寬存在瓶頸，則會考慮增加頻寬或者壓縮傳輸資料，如果頻寬沒有問題的話，我們會從伺服器上匯出日誌，開

8.如何判斷CPU使用率不達標

CPU使用率不達標，我們會從伺服器上匯出日誌，分析是哪個地方導致CPU使用率不達標，如果分析不出來，就叫上開發一起討論，確定問題後，就提單給開發修復，修復好了就進行迴歸測試。

9.App常見崩潰的原因？

1、裝置碎片化：由於裝置極具多樣性，App在不同的裝置上可能有不同表現形式。

2、寬頻限制：寬頻不佳的的網路對APP所需的快速響應時間不夠。

3、網路的變化：不同網路間的切換可能會影響App的穩定性。

4、記憶體管理：可能記憶體過低，或非是授權的記憶體位置的使用可能會導致App失敗。

10.你在專案中最經典的BUG是什麼？

1、相容性問題，在ie瀏覽器，提交訂單按鈕可以點選，到了谷歌，火狐就不能了。

2、查詢訂單頁面，根據條件篩選的結果不是想要的結果，還有某些欄位的值沒有顯示出來，或者顯示錯誤。（因為開發從庫表取值有誤）

3、付款成功後，訂單狀態一直不翻轉為交易成功。（因為程式碼沒有正確獲取庫表中付款成功記錄的狀態碼）