題外話
最近有點心浮氣躁，在幾個群里發過牢騷，有過埋怨，有過稚嫩，有過沖動，也砸了一個鍵盤，一個人晚上散過心，呵呵倒是讓不少朋友見笑了，仔細想想也許是一種蛻變，覺得自己還是很幼稚，不夠成熟，總是想留住年輕，不想這么快老掉，所以無時無刻的都在表現自己，仿佛向所有人說，我還小一樣，呵呵。
難得靜下來，整理下思路寫下這篇博文實屬不易，困境從不缺少，能走出困境的人，必有其過人之處，如果能將困境變為利境的人，必有其獨特的見解，或者是人生觀，或者是生活觀，或者是價值觀，總有和人不一樣的觀念。
古人云：達者，一日三省吾身。我不是什么達者，但卻能做到三日一省吾身，三日不能醒悟，四日或許就能恍然大悟，四日不能，五日也許就醍醐灌頂了，呵呵。非常感謝侯老師的提醒，也很感謝很多群友，同行的開導，若非如此，也許我還在泥足深陷。
原本計劃寫兩篇博文，一為用專業的眼光看待自己的工作，一為我個人的困境，既然現在困境有轉變的趨勢，不如一起寫了下來，作為新人之路系列博文的第五篇博文吧，我相信我的生活和工作都很普通，自然我所遇見的事情，會有很多人也會遇見，這也算是我將自己的一些心得共享吧，別人的始終是別人的，不要試圖完全照搬我的心得，只有自己的才是最好的，吸取百家所長，總結出自己的經驗，寫出自己的心得，那時才是提高了，一味的模仿永遠不能超越。
正文
最近的工作其實挺忙的，工作確實是測試，但是卻沒有用到測試上的技術，不管是工具，還是用例都沒有用到，只是測試，很多人都是如此，測試，只是測試。
其實測試不只是測試。
大家都知道測試的兩個發展方向，一為管理，一為技術，如果你發現你所在的測試工作沒有技術的影子，那你是否嘗試過從管理的角度來理解呢？
昨日將手上的一個項目從頭到尾測了一遍，整整8個小時，沒有測完，但確實很累，不斷的針對同一個功能點的不同可能性，晚上到家心里疲憊不堪，一點點不順心就大發脾氣，把一個外接鍵盤砸得稀爛還不解氣，又做了幾個俯臥撐，力氣發泄出去了，頭腦慢慢冷靜了，決定出去散散心，專往人少的地方走，環境安靜下來了，心也靜了下來，開始試著分析自己這段時間的情況，那是相當糟糕。
問題一，為什么如此急躁，怎么能不急躁
太過急躁，因為一些事情，我對自己的要求很嚴格，對自己的職業規劃也很嚴格，有個很明確的目標，最多5年達到什么什么程度，最好3年達到什么程度，仔細想一想其實，真的太急躁了。
針對這個問題，我告訴自己，“現在要做的，只是學習和積累，學習什么，學習技術，理論上的知識只能通過自己體會，學是學不來的，并且相對于理論，我的技術已經跟不上理論的成長腳步了，為了讓技術和理論平衡，所以應該學習技術，積累工作的經驗，工作的每一分每一秒都是一種經驗，如何安排工作的空閑時間，如何安排工作，不至于工作量分布不均勻一會強度很大一會強度很小，在和開發人員對Bug進行定位時也可以吸收相關經驗，比如，在界面刪除一個數據，但是數據庫中這條數據還存在，這時就可以根據經驗來判斷有可能該功能是虛擬刪除不是物理刪除，可以說每一個BUG都是一份經驗，區別只是你看見沒有，想到沒有。”如此想來，其實我要學的要做得還有很多，遠遠不是自己所想的沒有可以學的了，自己很厲害了，呵呵現在覺得這種想法很幼稚，學無止境啊，何況自己還是個初出茅廬的菜鳥呢。
測試行業所需要學習的東西實在太多太多，如何選擇學什么，單從工作角度來講，目前我工作的內容是WEB測試，工作的內容是功能黑盒測試，并且，接觸不到數據庫，這時，很明確了，我在前面的一篇博文中提及過，要向自動化提高，加之對QTP有一定的了解，但是不夠，那么很自然的選擇了QTP，不怕大家笑話，我只會QTP，但不會用QTP測試，好了，這是我的一個學習方向了。
第一個問題解決了，心也靜下來了，對以后至少2，3個月的日子不會再這般迷茫了，為什么是2，3個月？呵呵因為我自信啊，我認為2，3個月我能夠學會用QTP測試，當然不是精通。。。。第二個問題來了。
第二個問題，工作這么段時間，自己有沒有得到提高
相信也是大家閑暇時常常想起的，測試到底有木有前途，看看人家開發的工作，都是技術上的，項目完了人家的代碼能力實實在在提高了，技術水平實實在在掌握了，再看看自己，這個項目完了，自己了解的業務就都沒用了，雖然不是什么都沒學到，但是和開發一筆卻覺得自己學的太少，因為測試的基礎是業務，是需求，一個項目完了也就意味著你了解的業務沒用了，你了解的需求沒用了，即使你說再做相同的業務能夠容易上手，但假若業務跨度很大呢，這個項目是做管理的，下個項目是做商務的，對比看看現下的招聘內容，熟悉各種自動化工具，熟悉各種數據庫，熟悉各種語言，各種各樣的優先考慮，再來看看自己花了很多時間很多心力做完了一個項目，即使做得很好，你也會覺得自己還是沒有多大的提高，還是不能去應聘薪資高點的工作，你們有這種感覺嗎？
其實相對于開發人員顯性能力的提高，測試人員的提高很多是隱性的，單從技術的角度來講，測試員是拍馬也趕不上開發人員的進步的，這很容易理解，你的測試腳本如果比你的項目腳本還多的話。。呵呵呵可能嗎？
我來談談測試人員的隱性提高吧，在我們的測試過程中，即使是再枯燥的測試，也有可以學到的技術，這一點在昨日對整個系統做測試時，感觸很深。
其一，嚴謹性
就一般的測試而言，往往只是判斷功能是否能夠正常實現，但慢慢的你在工作中會發現有些缺陷，是分角色的，相同的功能，管理員是正確的，普通用戶是錯誤的，單獨點擊是正確的，執行了一個前提操作，再次點擊就是錯誤的，在工作中，隨著這樣的BUG的積累，你在測試的時候就會有意思的更嚴謹的去思考，哪怕即使是一個發布和編輯的功能，你都會考慮到除了單獨的測發布，編輯這兩條用例，還有發布后編輯和編輯后發布這樣的2條用例，你的測試工作將更加嚴謹。
其二，計劃性
在工作中，尤其是一個人負責一個項目的新人朋友，我相信沒有人指導的你們，很迷惑，對自己的工作沒有辦法做一個評估，對自己的工作量沒有辦法進行安排，工作閑得時候埋怨沒事做，工作大得時候埋怨太累，其實工作量是可以自我控制的，這個控制是相對的，即時是工作量很大的時候，你也應該先在自己的心里構建一個流程，畫上一幅畫，將這個系統的布局，功能點的分布都在心里過一遍，再開始有計劃的測試，哪些功能模塊是關聯起來的，哪些功能是獨立的，對于這個的掌握尤為重要，假若工作量為100.有效率的進行測試你的工作量就只有100，如果經驗豐富的話，比如你能夠確定某個表單是相同的，這里不會出現的錯誤，另一個地方絕對不會出現，因為都是用得同一張表單，那么你的實際工作量可能只有80，而如果你不能進行判斷，并且你甚至在開始測試前對整個系統都不在心里或紙上大致的分析下，那你的工作量很有可能是200，比如你在測試添加的時候，沒有測試到刪除，那么你測試刪除的時候就會再走一次添加，這就是無意義的工作量。所以計劃性很重要，并且只能在你工作中學習到。
其三，預見性和可分析性
這一點，有點不好講，還是舉個列子吧，測試同樣的一個功能模塊，測試員甲使用了10條測試數據，測試員乙使用了1條測試數據，都達到了相同的覆蓋率和測試效果，那么這里就可以看出測試員乙的測試數據更具備針對性，也就是測試員乙在測試時更具備預見性，相同的一個功能頁面，兩個輸入框，一個輸入框要求數字，一個輸入框要求字母，甲在測試第一個輸入框時考慮幾個方面但在對待第二個輸入框時只為了快速操作隨手輸入了幾個字母，這種情況經常發生吧，對嗎？而乙在測試時，數據是關聯的，即考慮了甲的輸入限定也考慮了第二個輸入框的限制，也就是乙的一組用例對應了2個輸入框，這種做法無疑讓你的每一份工作都有了應有的效益，也減少了你過多的工作量，這里實質上就是一個預見性和可分析性的工作經驗，乙在看見該功能模塊后，能夠預見各個功能模塊的關聯操作，并記錄好自己使用的測試數據，如果該測試數據到中途走不通了，就分析數據，尋找原因，這里就是一個針對性的測試，而甲所做得就是廣散網，缺少了針對性，自然，工作起來就很枯燥了，乙就不一樣，他的每一分工作時間都是在思考中的，每一個步驟，每一個操作都是有目的的有意義的。隨著我們工作的時間積累，這一點會越來越明顯，比如一個10年測試經驗的人絕對不會再去對一個輸入框做一系列的等價類邊界值劃分，他們只需要輸入幾個特殊的數據，就可以實現很好的覆蓋，對于一個有經驗的測試員，他所使用的每一個數據不說百分之百都有價值，但百分之八十都有可分析性，讓開發人員能夠從這些數據中快速定位Bug，這份能力減少的不僅僅是測試員的工作量也減少了開發人員的工作量。
其四，判斷力
作為測試員在判斷是否是Bug的時候是需要具備一定的判斷力的，最低要求能夠判斷這是不是缺陷，之前的博文中提及過，現在的很多開發人員已經在進行自測了，也就是單獨對功能點進行測試的時代正在蛻變，在我們尋找Bug的時候已經不能局限于點擊按鈕是否報錯，而應該從更深層次去定義缺陷，這里就需要足夠的判斷力，雖然我們常常說測試要從文檔開始進行，文檔測試通過后再來開發，但實際中很多時候測試人員的介入已經是在項目中期或者晚期，這個時候項目都快要完成了你再測試文檔也沒有多少用了，這個時候你就要根據實際情況考慮功能的合理性，也就是將文檔測試上得技巧運用在實際測試中，假如你判斷某個地方在設計的時候是有問題的，你就應該提出來，而不是他不報錯就可以了，比如一個頁面有兩個查看的功能一個名為查閱，一個名為查看，實現的功能和方式完全一樣，這個時候你可以很直接的要求只保留一個查看功能，這是對設計上的缺陷要有足夠的判斷力。另外在判斷缺陷嚴重程度和優先級也會在我們工作的過程中逐漸提高，剛接觸測試的時候，也許你認為只要是Bug都是萬惡的，都應該立即改掉，接觸一段時間后，你開始意識到有些Bug是可以滯后修改的，有些bug是可以允許的，熟練后你甚至會認為有些明顯是缺陷的地方是不需要管得，最直接的列子對于注冊用戶名和密碼，新人也許會糾結在需求不明中，用戶沒有限定數據類型，沒有限定長度，沒有一個標準怎么測？熟練后，就不會考慮這個問題，根據實際項目如果用戶對登錄本身并不重視，只是起一個登錄作用不需要做都少驗證，那么就可能只測一下正確能不能登錄，錯誤能不能登錄一些情況而不會過多的去考慮長度，數據類型，這些都需要判斷力，也正是我們測試的一種經驗，是我們在工作中可以提高的能力。
以上四點嚴謹性，計劃性，預見性和可分析性，還有判斷力，都是我認為在我們測試工作中每時每刻都在用，并且能隨時帶給我們好處的，如果是開發人員的經驗在于代碼等顯性的能力，那么測試員的經驗就在于這類隱形的能力。
有的人，工作一年，沒有一點進步，有的人一年后，效率和質量都有很大提高，這就是經驗，工作經驗并不一定等于工作年限，只是因為測試人員的能力很多都是隱形的，沒有辦法直觀看到，面試官只能通過工作年限來判斷一個人的工作經驗，這是一種測試職業不可避免的無奈，這一點在抱怨也沒有用的。
這是我問自己的第二個問題，在回憶了一遍昨日的整個工作情況后給自己做得總結，因為在回憶中發現其實原來這樣做可以省下很多工作量，其實這樣做能更好，原來還有這個地方沒有測到，就是這些其實和原來，讓我覺得提升的空間還有很多，測試的工作也不再是測試，而是對自己測試能力的提升，其實任何行業只要你發現了自己提升的痕跡，那么動力就這么簡單就來了。
第三個問題：淺談面試
其實這個問題比較私人了，主要是對自己的一種反省，平常生活中的點點滴滴都是值得我們細細品味的，前段時間參加了2次面試，都被刷下來了，這個結果我心理很清楚，所以也談不上失落，這里只是談一談對待面試的時候，我的心態，由于現實原因我十分明白自己面試的機會為0，當然這些現實原因我是在簡歷中有提到的，當接到面試電話的時候其實心里很驚訝，仔細看了一下對方的崗位要求發現自己一樣都不符合，唯一符合的就是對測試的了解，抱著好奇的心態也抱著學習的心態參加了這次面試，接待我的是一位聯想的面試官，這是我真正意義上的第一次面試，有點緊張，在交談中我發現其實面試沒有自己想得那么嚇人，整個氣氛還是很平和的，從面試官的交談中學習到了很多東西，也在回答面試官的問題時發現自己哪些地方不足，第一次面試主要讓自己了解到技術上得差距和經驗上得差距，也讓自己對面試不再那么緊張，第二次面試，是游戲測試員的職位，這次或許因為跨了行業，了解到的就更多了，我現在是在做WEB測試，對于游戲測試一竅不通，到場后先是一輪筆試，筆試上得題目看了后覺得對測試很不重視，近15道題，測試的只有2道，這時我心里有了點抵觸，我很喜歡測試這個職業，不希望去做測試機器，然后開始了面試，和面試官的交談中，發現項目測試和產品測試本質上的不同，項目一般相對產品較小，所以測試的時候整個流程都是很活得，特別是一個人一個項目，整個測試過程都是你一個人控制，非常的靈活，而產品測試不一樣，每一個環節都要求的非常嚴格，非常的死，這個死不是死板，而是牢固，在和面試官的經理交流中了解到，產品的測試如果不嚴格的控制和管理，那么如果一個小得細節忽略了，需要改動的就是整個所有的環節，如果一個用例沒有合格或者擅自改動了，那么影響的將是所有后續升級后續優化和后續相關用例的使用，不是不活，是不敢靈活，影響實在太大，風險實在太大，這是兩種完全不同的測試道路，同時也發現自己不適合走這條線路，我的思想很活躍，不會一成不變的去用別人的知識，我喜歡根據自己的實際情況對別人的技巧進行修改，整合，最后形成我自己的風格。
說了這么多，其實想表達的就一個，珍惜你的面試機會，也尊重你的面試官，對于得到面試機會卻不去面試的人，我只能為你惋惜，某種意義來講，面試經驗比工作經驗更加難得，人的一生能夠工作幾十年，而面試呢，一次面試算一個小時吧，你一生能面試幾十個小時呢？并且，面試官在和你交流的時候，你能從中學到很多東西，管中窺豹可見一斑，或許不能提高你的測試能力，但卻可以給你指明一條大概的方向，能夠排除掉你的一些不適合的道路，能夠縮小你的可選內容，呵呵其實有時候，可以選擇的東西多了也不好。
這里有我昨日思考的三個問題，也有我的答案，生活和工作本身就是一本書，而我們有的人是真的在讀書，從書里面學到很多知識和技巧，而有的人則是在翻書，或許翻書的日子過的比較快，一翻一天就過去了，而讀書的人往往要讀很久一天才會過去，但是。。。。呵呵。。你們明白中間的差距的。。。。