csdn論壇上，有人問如何考核測試人員，我回了幾個帖子，下面就是我回帖的內容，可以代表我對此事的一些看法。
一： 測試人員的工作評價比較的難辦，因為測試人員沒有具體的工作產品產出。
測試人員一般做的也就是測試用例的編寫和測試缺陷的提交。而這些可以說都不是看技術，而且看職業道德。所以我更多的認為，測試人員最重要的是責任心，是想做測試而不是開發什麼的。乙個測試人員提出1個問題或提出10個，對軟體最終的質量影響可能並不像大家想的那麼嚴重。 如果真的要考核，只能從工作產品考核，提交的缺陷不可能做為考核的目標，因為分配的模組、測試人員的視角、開發人員的技術差異等都可能會造成相當大的振盪。所以通常都是從測試用例的角度來進行評價。 這樣可以換個角度來說關於測試用例。
測試用例可以說是最變幻莫測的東西，因為至今沒有乙個嚴格的標準和理論來闡示測試用例的編寫（記住，是測試用例， 不是別的什麼）。而且測試是軟體工程收尾的工作，很難有大的時間和精力去編寫詳細的測試用例，但簡略的用例根本用不上，只能提供乙個大概的思路。並不合適考核的條件和標準。 所以真的想考核，可以，把你們單位的各種關係理順，完全按照軟體工程的方式一點一點的來（rup，cmm等都可以，因為裡面的工作都很容易度量），如果不是按照這樣，憑空的說考核測試人員，還不如經理直接拍腦門決定好了。
二： 上面說的多，但中心只有乙個：想考核，就必須有乙個可以比較的標準，所以首先要想好自己的公司是否存在這麼乙個東西。如果沒有，還是不要考核好了。 用bug數考核測試人員，就像用**行數考核程式設計師一樣可笑。
測試應該可以說都是在摸著石頭過河，有理論，但實際很難做。 所以我一再強調測試人員的責任心，因為測試工作本身幾乎無法度量，就像你寫的，做乙個小時和做8個小時從工作成果上並不能很好的體現出來。 為什麼沒幾個願意做測試，因為測試即幸苦又無聊，工資也比較少，成果還總被忽視。 其實誰做的多少、好壞，大家心裡都有桿秤，只要在獎懲的時候，經理能做到一碗水端平，即使沒有實際的比較標準，大家也不會過多的說什麼。 管理對的是人，不是機器，不要妄圖制定乙個完美的標準，即使有，還會有人不服氣的。 只要心中無愧，做什麼隨便讓別人去說好了。
四： 前兩天才看到有人在討論測試用例寫的時機，覺得很有道理。
如果按照標準的軟體流程，測試人員可以參與到需求、設計階段，測試用例當然比較的容易寫。 但現在更多的情況，是程式開發完畢了，才交給測試人員，這樣如果寫用例，一是時間的問題，二是對程式不一定熟悉。所以說真的，寫測試用例有些不和適宜。 而最常見的是測試完畢後補測試用例（嗯，怎麼和程式設計師一樣了，鄙視自己和大家，哈哈），這樣一般都是為了應付上面和客戶用的，只能說是乙個總結，因為問題都找出來了，自然容易按照問題寫用例，可以比較的完美。 所以我建議寫測試思路，特別是有多業務流程的時候，這樣做不容易遺漏。
至於那種白痴照著做都可以發現問題的測試用例，反正我們是沒有這個時間和精力，而且很多的時候，覺得測試都是一門藝術（再鄙視自己一次），發現問題更多是直覺（也許是錯誤的操作），這些都是用例無法表達的。 如果真要寫，可以寫乙個簡單的，隨著測試的展開，對程式的熟悉認識再逐漸的補充。這樣測試的差不多了，用例也基本寫好了。 測試用例其實最難掌握的就是乙個度，寫到多詳細，而這一般和測試時間呈線性關係。
原創 如何有效的考核測試人員
原創 如何有效的考核測試人員 當前國內很多公司對測試存在普通的認識不足，經常聽到許多公司拿bug的數量來考核測試人員的唯一方法，哪麼我要說 測試人員的考核不是僅僅看bug的！如何有效的考核測試人員？好的考核能激勵測試人員，提高工作效率 相反 不公正 的考核，則會降低工作效率,引起測試人員的不滿！本文...
測試人員的考核評定
專業技能 1.知識面 網路，資料庫 軟體工程，作業系統 語言 2.是否掌握了新的和 工作 相關的知識 3.業務熟悉程度。綜合素質 1.職業操守，對於公司規章制度，保密制度的執 況等 2.工作態度 是否認真，積極，主動，努力 3.學習 能力 對於新技術，業務知識的學習 4.溝通及語言表達能力 5.團隊...
如何有效的對測試人員進行業績考核
鄙人從事軟體測試好幾年了，也一直為該問題困擾，每次專案作完了，感覺大家都表現還馬馬虎虎。但是專案卻感覺總不是那麼完美，既然存在問題，說明測試人員的考核做的不到位，所以最近痛定思痛，也諮詢了一些在微軟和ibm做測試的朋友，結合自己多年來的實踐，得出如下核心考核指標，和大家共享。測試人員主要是三個方面。...