同樣是測試人員，做著可能相同的工作，作出的結果也可能大致相同。那麼以什麼作為你工作更加專業的區分呢?測試的工作用例編寫，測試執行，bug上報，以及功能點測試完成度控制。這些方面都可以體現我們的勞動價值。
測試用例的編寫——當別人不願意編寫測試用例，甚至覺得編寫用例是浪費時間時，倘若你體會到了用例編寫在測試過程中帶來的功能點覆蓋的全面性。那麼你就站在了比他人更高的高度。細到用例的每條，當別人只是簡單的劃分出這是某個測試點，而你已經清晰的知道這個測試點是使用什麼方法劃分出來的測試點-例如邊界值，等價類，因果圖。那麼你的確要比那些簡單羅列測試點的人技能上要更高一些。當別人還因為測試功能點未全面，而在趕工期忙碌時，倘若你能夠很坦然的根據自己的測試用例通過率確定已測試功能的質量時，你就會知道你站在了更高的臺階上。這些都是理論，測試用例要寫的好，要覆蓋面全，那是需要思考的，是絕對全心投入的思考。是一種創作，不是你拷貝策劃案裡的條目就能夠理清的。而是通過把策劃案中的功能點不斷的劃分，直至精確到某個輸入和輸出結果。這是一個急需要腦力勞動的過程，一方面要肯定策劃案中的正確的內容，另外一方面要考慮這些正常的內容是否存在何種異常的操作，而任何一個異常的內容都是不允許沒有輸出結果的。
測試的執行——不是所有的用例都會精確到點選滑鼠左右鍵。所以測試執行的速度反應著一個測試人員基本功的紮實程度。同樣是一個功能我們會發現，熟悉系統的測試人員在執行測試過程中往往比不熟悉系統的測試人員快。但是不熟悉系統本身就是測試人員自身的素質問題。沒有任何藉口，既然你是做這個的，那麼允許你開始的懵懂，卻不允許你一而再，再而三的愚蠢。想要比別人突出，那麼好好熟悉你得系統，最好做到別人知道的你清楚，別人不知道的你知道。
bug的上報——其實就是把bug的出現方法和具體出現導致的問題說清楚的過程。語言要簡潔，但是不能簡潔到別人看不懂。要步驟分明，要在執行測試過程中不斷嘗試，直至把bug的重現過程縮短到最短。可能會浪費你很多時間，但是你要看到這個的另外一個好處。當別的測試員跟程式人員重現bug，總是找不到重點步驟時，你已經深刻理解到要獲得程式人員的重視，bug的步驟越短，越是能夠得到程式人員的讚許。這個讚許積蓄到一定時間就成了你自負的資本。測試結果的彙報也很重要，清晰而明瞭的告訴程式人員或者測試主管，用例的執行情況，需要解決的問題-最好指出你問題在用例內的出處。這樣有便於程式人員養成檢視你用例的習慣。一般用例生成和程式實現是同步進行的，在這個過程中，如果程式人員發現你用例內有的測試點而自己沒有實現，那麼可以節省很多時間。當他多次出現你用例有的內容，他沒有實現到時這種深刻的記憶將驅使他檢查你的用例。
測試時間點的把控——根據測試用例中測試點的執行難易程式，以及測試用例中測試點的條數可以初步判定功能點的測試完成時間。最初這個是需要積累的，當用例達到某個數量，當用例難度與其它用例執行難度可進行比較時就很容易把控時間點。最好的時間把控不是預期3天而實際只測試1天半，也不是預期3天實際測試了5天。最好的時間點應該控制在半個工作日內。測試點的時間把控對於測試人員來說也很重要。有時如果為了進度需要寧可多幾個人一起來完成測試，也不可以因為時間點的問題導致版本釋出延遲。
另，以上純屬個人閒暇時間的總結，不具有參考價值。有興趣的朋友可以看下，覺得說的不好的也言論自由。但是拒絕個人人身攻擊。畢竟這裡寫這個的也是新手，段段兩年測齡，打擊新人的積極性的話，不算用以讓自己看起來很自負的好方法。