有的新測試工程師會感覺很奇怪：測試環(huán)境大家一字排開，每天看大家做的事情都差不多，都是換版本，執(zhí)行測試用例，有問題就反饋給開發(fā)人員，然后打bug，驗證bug……為什么看起來大家做一樣的事情，彼此的薪酬會有差距，或者差距那么多？
你看到的只是表象，內(nèi)在的東西沒有看到。如果看不到內(nèi)在的東西，或者想不明白內(nèi)在的東西，只能說，你距離合格的測試工程師，還有很遠的距離。
執(zhí)行黑盒測試和測試員是有差距的，測試員和測試工程師是有差距的，測試工程師和高級測試工程師是有差距的。測試是有技術(shù)含量的，不是單純的工廠生產(chǎn)模式，大家都是進行的同樣的操作，輸出的都是同樣的產(chǎn)品——話又說回來，即使單純的工廠生產(chǎn)模式，因個人的差異，合格率也是不一樣的。
那么，貌似同樣的工作方法，彼此的差異點在那里?
一、輸出成果質(zhì)量
對執(zhí)行測試來說，輸出成果質(zhì)量是決定性的因素。在考核的角度，bug的遺漏率也是負面的，決定性的因素。舉個例子，幾個人執(zhí)行同樣的測試用例，面對同樣的測試任務：
A員工測試執(zhí)行用了3天，執(zhí)行100條測試用例，測試出了20個bug，完成測試任務。
B員工測試執(zhí)行用了5天，執(zhí)行100條測試用例，測試出了50個bug，完成測試任務。
C員工測試執(zhí)行用了3天，執(zhí)行100條測試用例，測試出了51個bug，完成測試任務。
如果你是老板，你會給這三個人同樣的工資么？或者，你會給誰較高的工資？
二、耐心
調(diào)試排查過程中，少不了出現(xiàn)開發(fā)人員提供臨時版本到測試環(huán)境調(diào)試，或者開發(fā)人員短時間內(nèi)提供多個版本進行測試的情況。面對這種情況，是很好的考驗測試人員耐心的時候。
同樣的測試反復的執(zhí)行，然后每次都有各種亂七八糟的問題，重復性的操作……人都會有惰性，可能最后一次的版本測試，很多前面測試執(zhí)行過的沒有問題的用例，會因為策略的修改或者開發(fā)人員拆東墻補西墻的解決方法，出現(xiàn)新的問題。
一次次的反復執(zhí)行，這種工作是很枯燥，結(jié)果也是因人而異。筆者遇到的更多的情況，是測試人員根據(jù)慣性因素，直接跳過測試用例，認為不會有問題——出現(xiàn)這種情況，測試人員是不是很委屈？自己這么辛苦，反復執(zhí)行了7、8次測試用例，每次都ok，誰知道最后一次有問題，最后還被k說漏測？
這種耐心和責任心，真的是因人而異。
三、責任心
責任心是任何職業(yè)崗位都要求的職業(yè)素養(yǎng)，在測試崗位的體現(xiàn)是什么？
針對bug，從開發(fā)的角度，必現(xiàn)的問題是最容易解決的問題，偶爾出現(xiàn)的，沒有必然出現(xiàn)條件的問題是痛苦的，拷機十天半個月才出現(xiàn)的問題是絕望的。那么對于測試人員來說：測試出必現(xiàn)的問題是很容易做到的事情和做出的成績。對于偶爾出現(xiàn)問題和長拷問題的責任心，是對測試人員的一個挑戰(zhàn)。
版本迭代快，在測試中不知道為什么出現(xiàn)了一個問題，然后開發(fā)人員要求復現(xiàn)，或者bug打出去兩天才過來要求查看現(xiàn)場，你怎么處理？
面臨下班，一個隨機的異常出現(xiàn)，你是選擇無視，還是繼續(xù)排查問題，嘗試各種操作組合，業(yè)務邏輯組合，把bug抓?。?/p>
一個模塊測試執(zhí)行差不多了，一個很詭異的現(xiàn)象出現(xiàn)。然后嘗試復現(xiàn)失敗，那么對這個現(xiàn)象是放過，還是追下去？
四、排查問題的能力
排查問題的能力依賴于對業(yè)務的理解能力，依賴于經(jīng)驗積累。這點老員工比新員工有 優(yōu)勢，但是差不多時間進入團隊的同事，對業(yè)務的熟悉各自有差異，這就是用心不用心做事的結(jié)果。
發(fā)現(xiàn)同樣一個bug，還是有幾個人，假設分別表現(xiàn)如下：
A人員用一個小時，請三個組的五個開發(fā)人員來看問題，然后定位出問題的責任人
B人員用兩個小時，被幾個組的開發(fā)人員推過來推過去，最后現(xiàn)象被破壞，需要自己復現(xiàn)
C人員用30分鐘，定位出是那個模塊哪個負責人的問題
D人員用10分鐘，指出問題點和責任人，并分析出原因是哪個地方的業(yè)務邏輯問題。
同樣的問題，如果你是老板，會給同樣的工資么？或者，你會給誰較高的工資？
五、回歸測試的覆蓋度
回歸測試的執(zhí)行，按照書本上的理想模式或職業(yè)憧憬中，應該是這個樣子：開發(fā)人員對提交修復的bug，填寫仔細的問題產(chǎn)生原因、修復策略方法以及回歸測試建議。測試人員根據(jù)開發(fā)人員填寫的信息，在測試用例庫中選取回歸測試用例，并執(zhí)行回歸測試用例。
但很多公司在實際執(zhí)行時，因種種現(xiàn)狀，回歸測試的深度和波及面，更多的會依賴于執(zhí)行回歸測試的人員的職業(yè)素質(zhì)：比如業(yè)務熟悉程度，比如責任心。
建立一個回歸測試的流程，對團隊的積累（軟件）和過程質(zhì)量控制的投入（硬件）的要求是比較高的。提高回歸測試質(zhì)量，最快速有效的方法，就是提高測試工程師的業(yè)務能力和自我的責任心（屬于末端反控，治標不治本的方法）。
面對同樣的回歸測試，還是有幾個人，假設分別表現(xiàn)如下：
A人員執(zhí)行了原bug中的復現(xiàn)步驟，然后宣布回歸完成
B人員執(zhí)行了原bug的步驟，并把同模塊的其他測試用例進行了一定的回歸測試
C人員執(zhí)行了原bug步驟，并根據(jù)系統(tǒng)架構(gòu)，把可能波及的點也做了回歸測試
同樣的問題，如果你是老板……？
?
六、敏捷測試模式的效率
這是最考驗測試工程師的測試任務。
在實際的工作中，除了正常的開發(fā)測試模型外，還有部分開發(fā)測試任務是臨時性、定制性、緊急性的測試任務，比如打標測試。
常規(guī)的測試，我們可以依賴于完整的測試策略和測試計劃、規(guī)格學習和討論、測試用例編寫評審、測試執(zhí)行、bug分析和各種控制方法。但是緊急測試，前端的交付件可能不夠全面，測試策略和測試用例也可能來不及構(gòu)建。所以更多的測試執(zhí)行和軟件質(zhì)量，就要求測試工程師對系統(tǒng)框架的熟悉情況，對各種測試工具的熟練應用，對測試策略和測試方法，測試環(huán)境構(gòu)建方面都了如指掌。
七、敏感度
敏感度是一個比較務虛的詞，同時也沒有特別具體的量化指標來考核。部分可借鑒的指標，比如bug遺漏率、測試用例補充數(shù)目、評審反饋問題數(shù)、案例編寫數(shù)目等。
借用上文說到的一個事情，就是不容易出現(xiàn)的問題點，一是需要責任心，另外就是需要敏感度。對系統(tǒng)的敏感度，對細節(jié)的敏感度。
舉個例子，圖像質(zhì)量的測試，彩色的圖像忽然變成黑白的，可能任何一個測試人員都能發(fā)現(xiàn)問題。但是每隔30秒，圖像忽然顫抖一下，可能就需要一定的敏感度。
比如聲音質(zhì)量測試，聲音輸出始終斷斷續(xù)續(xù)，可能每個測試人員都能發(fā)現(xiàn)，但是每隔一分鐘，有幾個字被“吃”掉，就需要依靠測試人員的敏感度和責任心。
?
八、業(yè)務熟練度
業(yè)務知識的掌握和理解程度，在產(chǎn)品線的測試團隊中，是根本，也是核心。在上述各種方面，已經(jīng)闡述過業(yè)務知識導致的測試人員差異性：輸出成果質(zhì)量、排查問題的能力、回歸測試覆蓋度、快速測試模式等等。
上面林林總總說了很多，但是還沒有概括全面。如果有疑問，我希望提問者能觀察大家彼此的差異點，然后嘗試總結(jié)，學習。
正向的看待這個疑問“為什么大家都是執(zhí)行，結(jié)果大家收入的差異性那么大？”，你意識到有差異性，然后提出問題，這是很好的第一步。大家需要做的是第二步：觀察學習高薪水的人，他們的做事方法和能力、業(yè)績。第三步：就是模仿學習。
自己發(fā)現(xiàn)問題，然后有良好的榜樣在身邊，也有明確的目標和途徑在身邊，這種提升能力和報酬的好機會，怎么能輕易放棄？
