背景：我們
測試團隊包括業務測試團隊和測試工具開發部門（測試規劃部），近期，部門在討論
自動化測試考核的細節。我們的目標：通過工具提高
工作效率（提效），解決手工測試無法覆蓋的問題（有無）。討論的內容包括如何通過自動化
測試用例的個數和比例對測試設計和工具開發人員進行考核；工具的使用、推廣和工具需求的責任如何劃定等等。下面是關于個人觀點的郵件內容摘錄。
各位好：
如果我認識我的觀點正確，我會盡快提出來。大家在這樣的base上討論，成效會更多一些！
關于自動化測試用例個數/比例：
我們對自動化測試目標的理解完全一致：自動化的目標是提效和有無；自動化測試用例個數/比例的高低絕對不是我們的目標，也不是我們達到目標的手段和途徑。如果開始的理解出錯，只能一錯再錯，按個數和比例進行考核行不通！
軟件測試或 者測試工具開發的衡量，猶如衡量商品的價值?；旧蠜]有人按商品的長寬高、重量、數量、體積等衡量商品的價值，如果有的話，那是送快遞的（快遞也不直接考 核商品本身的價值）。工具和商品具有很大的相似性，都是凝結在其內在的無差別的人類勞動，對他們的衡量只能采用社會必要勞動時間！
具體來說，TestLink上很多測試用例只有標題，而總數有數千個。這種有數量而沒有內涵，完成這些數量只需要簡單的復制粘貼，不需要很多工作時間。如果這樣的做法可以獲取很高的考核分數，只能往錯誤的方向上引導團隊，久而久之會導致不良的工作風氣。
用例的個數和比例只能用在日常工作的進度報告上，不能用在績效考核上；只能定性，不可定量。而績效考核的內容則應該在員工付出的努力、付出努力而產生的成效等等！
在實施上，我建議：
對于業務測試，從功能模塊復雜度，人力資源/工作量評估等進行衡量。
對于測試研發，工具研發的難易程度，工作量等進行考慮。
社會必要勞動時間意味著，不同員工的工作效率有差別，同樣的工作量的價值也是不一致的，建議參考IBM/華為的PBC績效考核方式及其關聯的員工級別制度。細節需要完善。
關于工具的使用和需求的提出：
100%的測試團隊的責任。
1、使用 我們的工具都是專業工具，不像剃須刀和發卡那樣簡單易用，都需要專業知識，并需要耐心的付出精力。任何以工具不好用為借口的員工都有沒有靜心使用工具或能力不足的嫌疑。
如果測試團隊采取低效的方式進行工作，而規劃部有現成的工具并組織培訓推廣過，測試團隊的績效考核應該被扣分。
2、需求
如果測試團隊采取低效的方式進行工作，而不能主動向規劃部提出需求，且規劃部可以改進所述的工作方式時，測試團隊的績效考核應該被扣分。
關于工具的研發和培訓推廣：
100%的測試規劃部的責任。
1、研發
規劃部負有研發的責任。在熟悉的知識領域，盡快完成研發，滿足測試團隊的需求。在不熟悉的領域，需要調研學習，并盡快完成研發，滿足測試團隊的需求。
2、培訓推廣
規劃部負有培訓推廣的責任。開發的工具必須展現出來并進行積極的培訓。藏在深閨無人知，只能自己把玩的工具，應該扣績效考核的分數。
本文轉載自：http://loggingselenium.com/?p=350