都是執行測試，差異點在那裡？
有的新測試工程師會感覺很奇怪：測試環境大家一字排開，每天看大家做的事情都差不多，都是換版本，執行測試用例，有問題就反饋給開發人員，然後打bug，驗證bug……為什麼看起來大家做一樣的事情，彼此的薪酬會有差距，或者差距那麼多？
你看到的只是表象，內在的東西沒有看到。如果看不到內在的東西，或者想不明白內在的東西，只能說，你距離合格的測試工程師，還有很遠的距離。
執行黑盒測試和測試員是有差距的，測試員和測試工程師是有差距的，測試工程師和高階測試工程師是有差距的。測試是有技術含量的，不是單純的工廠生產模式，大家都是進行的同樣的操作，輸出的都是同樣的產品——話又說回來，即使單純的工廠生產模式，因個人的差異，合格率也是不一樣的。
那麼，貌似同樣的工作方法，彼此的差異點在那裡?
一、輸出成果質量
對執行測試來說，輸出成果質量是決定性的因素。在考核的角度，bug的遺漏率也是負面的，決定性的因素。舉個例子，幾個人執行同樣的測試用例，面對同樣的測試任務：
a員工測試執行用了3天，執行100條測試用例，測試出了20個bug，完成測試任務。
b員工測試執行用了5天，執行100條測試用例，測試出了50個bug，完成測試任務。
c員工測試執行用了3天，執行100條測試用例，測試出了51個bug，完成測試任務。
如果你是老闆，你會給這三個人同樣的工資麼？或者，你會給誰較高的工資？
二、耐心
除錯排查過程中，少不了出現開發人員提供臨時版本到測試環境除錯，或者開發人員短時間內提供多個版本進行測試的情況。面對這種情況，是很好的考驗測試人員耐心的時候。
同樣的測試反覆的執行，然後每次都有各種亂七八糟的問題，重複性的操作……人都會有惰性，可能最後一次的版本測試，很多前面測試執行過的沒有問題的用例，會因為策略的修改或者開發人員拆東牆補西牆的解決方法，出現新的問題。
一次次的反覆執行，這種工作是很枯燥，結果也是因人而異。筆者遇到的更多的情況，是測試人員根據慣性因素，直接跳過測試用例，認為不會有問題——出現這種情況，測試人員是不是很委屈？自己這麼辛苦，反覆執行了7、8次測試用例，每次都ok，誰知道最後一次有問題，最後還被k說漏測？
這種耐心和責任心，真的是因人而異。
三、責任心
責任心是任何職業崗位都要求的職業素養，在測試崗位的體現是什麼？
針對bug，從開發的角度，必現的問題是最容易解決的問題，偶爾出現的，沒有必然出現條件的問題是痛苦的，拷機十天半個月才出現的問題是絕望的。那麼對於測試人員來說：測試出必現的問題是很容易做到的事情和做出的成績。對於偶爾出現問題和長拷問題的責任心，是對測試人員的乙個挑戰。
版本迭代快，在測試中不知道為什麼出現了乙個問題，然後開發人員要求復現，或者bug打出去兩天才過來要求檢視現場，你怎麼處理？
面臨下班，乙個隨機的異常出現，你是選擇無視，還是繼續排查問題，嘗試各種操作組合，業務邏輯組合，把bug抓住？
乙個模組測試執行差不多了，乙個很詭異的現象出現。然後嘗試復現失敗，那麼對這個現象是放過，還是追下去？
四、排查問題的能力
排查問題的能力依賴於對業務的理解能力，依賴於經驗積累。這點老員工比新員工有 優勢，但是差不多時間進入團隊的同事，對業務的熟悉各自有差異，這就是用心不用心做事的結果。
發現同樣乙個bug，還是有幾個人，假設分別表現如下：
a人員用乙個小時，請三個組的五個開發人員來看問題，然後定位出問題的責任人
b人員用兩個小時，被幾個組的開發人員推過來推過去，最後現象被破壞，需要自己復現
c人員用30分鐘，定位出是那個模組哪個負責人的問題
d人員用10分鐘，指出問題點和責任人，並分析出原因是哪個地方的業務邏輯問題。
同樣的問題，如果你是老闆，會給同樣的工資麼？或者，你會給誰較高的工資？
五、回歸測試的覆蓋度
回歸測試的執行，按照書本上的理想模式或職業憧憬中，應該是這個樣子：開發人員對提交修復的bug，填寫仔細的問題產生原因、修復策略方法以及回歸測試建議。測試人員根據開發人員填寫的資訊，在測試用例庫中選取回歸測試用例，並執行回歸測試用例。
建立乙個回歸測試的流程，對團隊的積累（軟體）和過程質量控制的投入（硬體）的要求是比較高的。提高回歸測試質量，最快速有效的方法，就是提高測試工程師的業務能力和自我的責任心（屬於末端反控，治標不治本的方法）。
面對同樣的回歸測試，還是有幾個人，假設分別表現如下：
a人員執行了原bug中的復現步驟，然後宣布回歸完成
b人員執行了原bug的步驟，並把同模組的其他測試用例進行了一定的回歸測試
c人員執行了原bug步驟，並根據系統架構，把可能波及的點也做了回歸測試
同樣的問題，如果你是老闆……？
六、敏捷測試模式的效率
這是最考驗測試工程師的測試任務。
在實際的工作中，除了正常的開發測試模型外，還有部分開發測試任務是臨時性、定製性、緊急性的測試任務，比如打標測試。
常規的測試，我們可以依賴於完整的測試策略和測試計畫、規格學習和討論、測試用例編寫評審、測試執行、bug分析和各種控制方法。但是緊急測試，前端的交付件可能不夠全面，測試策略和測試用例也可能來不及構建。所以更多的測試執行和軟體質量，就要求測試工程師對系統框架的熟悉情況，對各種測試工具的熟練應用，對測試策略和測試方法，測試環境構建方面都瞭如指掌。
七、敏感度
敏感度是乙個比較務虛的詞，同時也沒有特別具體的量化指標來考核。部分可借鑑的指標，比如bug遺漏率、測試用例補充數目、評審反饋問題數、案例編寫數目等。
借用上文說到的乙個事情，就是不容易出現的問題點，一是需要責任心，另外就是需要敏感度。對系統的敏感度，對細節的敏感度。
舉個例子，影象質量的測試，彩色的影象忽然變成黑白的，可能任何乙個測試人員都能發現問題。但是每隔30秒，影象忽然顫抖一下，可能就需要一定的敏感度。
比如聲音質量測試，聲音輸出始終斷斷續續，可能每個測試人員都能發現，但是每隔一分鐘，有幾個字被「吃」掉，就需要依靠測試人員的敏感度和責任心。
八、業務熟練度
業務知識的掌握和理解程度，在產品線的測試團隊中，是根本，也是核心。在上述各種方面，已經闡述過業務知識導致的測試人員差異性：輸出成果質量、排查問題的能力、回歸測試覆蓋度、快速測試模式等等。
上面林林總總說了很多，但是還沒有概括全面。如果有疑問，我希望提問者能觀察大家彼此的差異點，然後嘗試總結，學習。
正向的看待這個疑問「為什麼大家都是執行，結果大家收入的差異性那麼大？」，你意識到有差異性，然後提出問題，這是很好的第一步。大家需要做的是第二步：觀察學習高薪水的人，他們的做事方法和能力、業績。第三步：就是模仿學習。
自己發現問題，然後有良好的榜樣在身邊，也有明確的目標和途徑在身邊，這種提公升能力和報酬的好機會，怎麼能輕易放棄？
這些都是改進點
舉個例子 乙個單位的人出去旅遊，到機場了之後大家準備統一辦理登記卡，那麼這種事兒應該誰去做呢？讓領導去做，那是不合適的 讓前輩去做，也是不明智的 最應該去做的是新進人員。別提什麼 我又不是來打雜的 什麼什麼的，誰都是從打雜做起的，但有些人打雜打了沒幾天就能讓別人打雜了，但有些人打雜打了好幾年了，區別...
SeaJs與RequireJs執行差異
seajs與requirejs在模組的載入方面是沒有差異的，無論是requirejs在定義模組時定義的依賴模組，還是seajs在factory函式中require的依賴模組，在會在載入當前模組時被載入，非同步，並且順序不可控。差異在於factory函式執行的時機。為了增強對比，我們在定義依賴模組的時...
bash script 的執行方式差異
shell的執行方式有三種 1 sh scriptname 2 scriptname 3 source scriptname 使用前面的1，2種方式來下達指令碼時，該script都會使用乙個新的bash環境來執行指令碼內的指令，也就是說，使用這種執行方式時，其實script是在子程式的bash內執行...