為什么要選擇軟件測試”并非出身名校的我，每每在面試中面臨著個問題時，總是覺得百感交集。測試對我就如同我歷經的求職過程——痛苦并快樂著。在品味它的過程中，我彷徨，迷茫，經歷著感情的低潮，這個過程不會很快樂，甚至是痛苦。同樣品味測試，有人拿駕馭它易如反掌折枝，不費吹灰之力;有人雖歷經波折，但最后總算苦盡甘來，嘗到“擁有”的甜美果實;但也有人即便吃盡苦中苦、用盡千方百計，終了卻仍與“它”擦身而過。結果永遠難以預測，我渴望快樂，那就要蛻變，意味著要經歷痛苦而漫長的磨練，意味著所有的一切都將從頭開始，一切都將變的陌生，但如果蛻變成功，那一刻就如同蝴蝶破繭而出的那一瞬間，美麗卻又讓人感動。一直以來對測試的認識存在誤區，認為測試的目標和價值就是在黑盒測試活動中找bug，但當測試經驗的逐漸的積累，重新回頭再重新審視測試，發現我所理解的測試逐漸浮現出它自身的價值，在這里我對自己的感悟和理解做了一個梳理，有不完整和理解不正確的地方，希望大家多多指教。

　　測試=重復+枯燥

　　也許我要講測試不過是每天重復一些操作來發現Bug(錯誤)。事實的確如此，哪怕是非常熱愛這項職業的人也承認它的枯燥。測試它是機械、枯燥、重復的過程，尤其是在項目接近尾聲的時候，修改測試，再修改再測試，像無法擺脫的輪回，有時候更像是一場與開發組不間斷的戰爭，不過，摒棄枯燥的外衣，測試本身有它的價值所在，它更讓人能從用戶的角度來考慮問題，更能深入了解程序開發過程中可能出現的問題，盡管可能一整天都為了一個很小的問題“循規蹈矩”地反復測試并撰寫測試文檔，這樣的重復將會是重要的積累。我喜歡新東方學校的徐小平新書《騎驢找馬》中的一句話：“重復做漢堡，就是麥當勞;重復煮咖啡，就是星巴克;重復教托福，就是俞敏洪;重復做好事，就是活雷鋒�！惫ぷ鞅旧淼臐M足也是來自于填補缺陷，測試亦是如此。

　　其實在現實的軟件測試環境中，沒有兩條測試路徑是完全相同的，沒有測試是可以精確的重復執行，就好像你不能精確的沿著你的足跡往回走，你可以很接近，但你總會有一點偏移。所以你無法確保其中某些因素會影響你下次的測試，重復測試也其實只是重復其它測試的某些方面，在以下某些方面重復的測試是非常有必要的：

　　1.重試：當你不確定一個測試在其它的時候是否被正確的執行時，這種情況的一種處理方法就是讓幾個測試員沿著同樣的測試說明執行測試，檢查他們是否得到相同的結果。

　　2.改變：當開發修改了一個測試中的重要部分，但同時保持其它部分不變時，即使這個測試的一部分元素是保持不變的，但對整個測試來說，它是新的，并且可能會引發新的行為。之所以會對一個測試作改變，那是因為雖然之前的測試涵蓋了某些方面，但涵蓋的范圍還不足夠。這個時候需要重復測試。

　　3.重要性：當可以通過重復測試發生的問題可能比其它檢測出來的問題更重要時，產品行為的重要性的結果是不一樣的，有時一個特殊的問題或者只要影響用戶一次就可能被認為難以接受的(“決不允許再次發生”的情況)。這并不意味著需要執行完全相同的測試，只要重復的測試包含可檢測出問題的足夠相似的元素就可以了(查看改變部分)。

　　4.舊問題：原有的問題在原有的環境中已經解決，但是將其應用到新的環境中時，然后會偶現，這是需要在新的環境中重復的測試。

　　測試= 沒有技術含量

　　踏上測試這條路的人何止千萬，但是不同的人對這個行業有不同的感嘆。有人嘆息成長為測試的高手猶如星星之火，難以燎原，有人在唏噓，測試毫無技術含量，也有人感嘆因為目的不同而踏入測試道路的人們，經過實踐的歷練，歲月的打磨，會有那么多不一樣的結果。

　　其實軟件測試并不是簡單，雖然它所進行的主要工作就是在軟件開發過程中的排錯。但是這種排錯的工作卻并非像我作為新人初涉入這個行業所了解那樣，僅僅是一個尋找bug的工作，任何人，都能找到出來，區別在于，熟手找到的速度和數量大于生手而已。它的根本原則是站在客戶/終端用戶的角度上來衡量和評價軟件產品的質量。如果不清楚客戶真正的需求，那么我們的工作也只不過是機械的勞作而已。我們需要將需求分解為可測的功能點，并且根據自己的思維去想，在有限的測試時間內，如何設計測試用例，能夠保證最佳有效的測試覆蓋，檢測出軟件產品中的種種功能及性能隱患。在這個過程中我們就像在掘寶，寶藏隱藏的越深，條件越復雜，級別越高，找到后，就會越開心。

　　如何完全界定有沒有技術含量，我也說不好，但是我認為對測試悟得越透，經驗越多，測試也就會做得越好，取得成效越好，從這個角度上講，測試是很需要能力的，這種能力我們也可以理解成“技術含量 ”， 在軟件開發過程中測試人員不僅需要具備技術能力，還需要具備溝通能力，懷疑精神，極強的洞察力，耐心，甚至是幽默感(在遇到狡辯的情況下，幽默的批評是很有幫助的)。所以所謂的技術含量在某種程度上并不完全是純粹的技術，更多時候是測試人員本身的素質。

　　測試+開發 = 不可調和的矛盾

　　在好的項目組中，和諧的測試和開發猶如一對好的矛和盾，相互制約又相互協調，在求職面試時，經常會遇到一個相同的問題，在測試項目或者產品的過程如何協調與開發人員的關系，即如何處理工作性質所帶來的開發和測試的矛盾。剛涉足測試時，我不能很好的體會到這種矛盾，只能淺層的想象測試是挑開發的毛病，開發當然也不樂意老讓人挑毛病，所以就有了矛盾。之后翻閱一些書籍，里面談到測試和開發的協調需要上升到一定的高度，即“雙贏”，就是大家共同的目標是一致的，就是維護好整個項目讓客戶打到最佳滿意度，這樣會這很大程度上避免一些“沖突”，實現工作中的雙贏，理論上這是個很好很和諧的概念，這樣回答面試官不加分也不至于扣分。

　　但是在實際操作中，很多現實因素會制約這種思想，比如其一：大家為了減少項目出錯的風險，卯足了勁去查bug，免不了有鉆牛角尖的情況發生，再要是同時開發人員會將bug的數量作為其考核的標準，那么測試和開發之間的“硝煙”是終日揮散不去的。其二：測試和開發獲取的信息的不平等抑或不一致，由于開發人員在整個項目開發過程中獲取的需求信息，需求變得信息，項目流程信息等比測試人員更廣泛或者時間上更快捷，導致與最終測試人員的思想不一致而產生一些錯報或者漏報的bug，倘若再加上溝通不善，會對整個項目進度和流程產生很大的影響;信息不一致則是開發和測試在理解需求上產生分歧，從需求階段就產生矛盾勢必會滿意至編碼階段和測試階段，解決這樣的矛盾的結果就是拖延項目的進度。

　　測試如矛，開發如盾，在初期，矛若知道盾之強弱，便可及時修補其弱點，那么這就首先要求開發和測試從項目出去就需要保持一個一致的狀態，無論從需求信息，需求變更信息，風險信息，技術瓶頸信息，項目難度信息，都需要保持同等及時的認知，這就需要測試和開發人員相互溝通得當及時。其次在處理bug的問題上，好習慣的測試人員會在開發之前撰寫case階段就根據自身經驗預測開發人員容易忽視的邏輯從而預先告知防止錯漏的發生。其三，對于bug的分析和爭議，測試人員應該多從用戶的可重現性，bug的風險性，解決bug所需要的時間和價值性價比等方面共同商榷，最后定奪一個處理bug的最佳方案，一個被提出的bug也并非只有解決，不解決和無效者幾種狀態，可以根據整個項目的情況來定奪它，目前不解決也不一定是永遠都不解決，最重要的是它對產品的影響力和投入的估計要得當適合，才能查出一個高性價比的產品，最終獲得收益的最大化，同時開發和測試也獲得了雙贏的局面。

　　以子之矛，攻子之盾，在古代或許是絕對的對立，但是對于測試和開發誰說一支好的矛一定要攻破盾，一支好的盾一定抵御得了任何矛，好的矛與好的盾，不斷的磨合和進步，終有一天會默契得強過任何矛盾，所向披靡。

　　我的測試 == 痛&&快樂

　　我的第一份實習工作是在一個外企做黑盒WEBGUI測試。剛剛進入軟件測試的我那個時候對軟件測試也一無所知，甚至一開始我的職位都是：測試執行人員。跟我一起奮斗的同伴們，每天都在不斷的自我抱怨中拿著那些別人寫好的測試用例，一遍一遍在同一個頁面上重復的點擊某個按鈕。大家都似乎認同一個道理：這就算測試運行自己寫或者別人寫的case，機械的像在碰運氣一樣的去尋找或許存在的bug。

　　我曾在心里質疑過自己的選擇，但是我最終還是覺得，即便是在這樣的環境里面，我能學到應該不止這些。我能做的應該也不止這樣，否則我的路在哪里人無法預料未來，只能把握現在。如果你想未來能走得更遠，更寬，那么今天就一定要努力。這也是我當時想的，并且努力去做的。其實喜歡與否，有的時候也在于你是否有興趣去探求，去思考和了解這個行業里面的浮在表面之外那些東西。不了解，就很難喜歡，不喜歡，又有什么機會會因為興趣而去努力呢或許，世界本來就是不公平的，在某些人的眼中，看別人瀟灑的談笑，自己卻要如此艱澀的生活著;或許，世界本來就是公平的，你善待了你的生命，虔誠的為了自己的理想去努力，即使不能碩果累累，取得的成績可圈可點，對于我的人生，痛并快樂著，這就已經足夠。