測試人員對架構的關注

QA對架構的評估時，可以考慮整體設計在正常及異常情況下，是否仍然通用。

例子1：異常情況下暴露出了架構設計的弊端

根據專案架構選擇測試策略

測試中發現的bug數

個別公司會以bug數作為QA的KPI考核的一部分，甚至有時面試官甚至直接問過去發現的bug數情況。當然無可厚非，同一個專案，發現bug多的QA肯定比發現bug少的QA能力要強，但僅僅以bug來考察qa是否真的“公正”？

個人認為：qa剛接觸一個專案時，發現比過去多得多的bug時，此時恰恰證明了該QA的能力。但隨著越來越深入的接觸和把控專案，此時的bug數就應該有所下降了(比如通過質量分析會，典型bug分析，及測試之前的流程把控等等)。確切的說，bug數應該呈下降趨勢：

當開發測試比例達到10+時，如何控制專案質量

當一個測試不但要扛起整個業務的測試，而且面臨十幾個開發人員時，提高開發人員的自測能力就顯得尤為重要了。在專案中，可採用的措施： 1） 專案分級，抽取出小改動點中的免測專案。 2） 定期質量分析。典型bug分析 + 避免方法。 3） 自測檢查點 4） 推上線流程 5） 測試分支，部署持續整合 6） 監控檢測上線後的質量

對專案流程的持續推進

1） 第三方專案依賴要求

依賴方：

(P1)第三方系統有問題，不能直接導致本系統不可用

 (P2)有相應的監控/日誌等 當第三方有問題時，及時發現

1） 本身 服務/ 介面 可承受的qps

2)    每次接入第三方， 控制其呼叫 情況（qps,頻率）

3）  服務/介面 掛掉時， 對 運營系統本身影響範圍

4）  記錄所有 接入 第三方 的情況（誰，怎麼用的）

5）  告知第三方 如果  呼叫情況有變，及時周知

2） 專案報告

測試總結報告；

質量分析報告；

自測通過率；

典型bug拎出來；

3） 流程推進&優化

分支管理&環境環境；

規範制定與推進（介面規範；日誌規範；第三方系統依賴；需求變動；上線流程等等）

用例管理&bug管理；

提測流程；

上線流程（上線時間點，程式碼review，上線檢查點，檢查迴歸，測試資料清理，回滾方案）

上線checklist

自主釋出專案