觀點1： 單純以bug數量來衡量KPI是不可取的
測試人員希望開發團隊來一個水準差的。寫出足夠多的問題來讓測試提升bug數量。哈哈
觀點2：以結果願景為導向，在定義過程資料，最後看結果資料。
如果我們單純的拿人日，測試用例數量等等來衡量，那麼很容讓測試人員想方設法來糊弄。舉個例子，你能用代碼行數來評判開發人員的KPI嗎。顯然是可笑的。
評估測試團隊KPI次元應該是一個簡單直覺的可度量且可以細分的東東。
品質次元： 重要bug出現的數量。線上bug數量。 bug遺漏比率（和現有bug比較），用例覆寫率
效率次元：自動化程度，測試成本，周期，測試提前度。
團隊次元：管理，學習，成長
觀點3：需要資料，但不迷信資料
我們需要在一定的資料指導下來評判目前測試的品質。比如覆寫率，bug修複比率，bug走勢等等。 但是如果隻是以資料作為唯一标準，就錯了。要和團隊的環境，行業比對。
觀點4： 培養好的團隊氛圍和團隊成員認可度。
人人為了産品
觀點5：考核方面
需求覆寫率，不錯。 用例執行率，可以。 用例有效率。 線上bug數目。
需要數量，但要合理的設計數量标準。比如bug等級。優先級别和嚴重級别。 需求覆寫率，核心component的全覆寫。