文中為了更加形象的描述每個階段，用小b的整個測試經歷來講述。
當然，小b剛開始也是乙個測試菜鳥。剛進入專案後，基本上每天的工作就是：測試用例—>提交bug—>回歸bug。開始還挺新鮮，一段時間後有天晚上突然驚醒，抓住乙隻蟑螂大吼：臥槽，尼瑪這也太無聊，太沒有技術含量了吧！難道我以後的工作就是每天幹這個嗎！當然，吼完後也跟其他人一樣把蟑螂弄死後繼續睡覺。
那一年，小b是23歲，不幸的是真的被他言中了，他以後很長很長的一段時間都是在幹這個（直到現在）。不過，幸運的是，他再也不覺得幹這個是浪費青春了。不過這些都是後話，第二天上班後，小b就決心有所改變了。
當然，第二天的工作依然是重複昨天的故事，不過小b在這個過程中發現了乙個問題：每次提交bug後開發還要跟自己確認環境，甚至再給開發演示一遍。這樣經常被打斷，效率也太低了，特別是自己也不太確認bug是怎麼出來的時候。難怪以前經常任務完不成要加班的。
如果每次提交bug後，開發都能不用來找自己該多好啊？為了這個目標：小b開始進入了第二個階段。過程就是每次發現乙個bug都去想如何提交上去後就讓開發不再找自己了。
為了達到這個目標：小b做了如下事情（具體細節就不講了）；
1、熟悉對應功能的需求，因為經常有些問題自己也不確認是不是問題。熟悉了需求，了解了為什麼需要這個功能，給客戶帶來的價值是什麼。
2、看研發的設計文件，學習裡面的業務邏輯，這樣發現乙個bug後就能過大概判斷是怎樣產生的，然後也能夠更快的復現以及必現這個bug。
這個階段經歷了1年多的時間，而且也經歷了很多痛苦的過程，比如：因為需要學習和自己嘗試去排查問題，導致很多非必現的bug最後重現不出來了，還因此被老大說了幾次；另外就是因為文件看不懂去厚著臉皮找開發被鄙視和拒絕了很多次（作為乙個有自尊的人心裡還是很難受的）；還有就是加班比以前更多了。
不過，付出終有回報。一年後，基本上80%的bug開發都不再找自己 了，更重要的是得到了開發的認可，這個開發的認可應該是一年來得到的最大收穫吧。因為得到開發的認可後，感覺後面整個測試工作都非常輕鬆了，開發也願意配合。
人總是貪婪的，在嚐到甜頭後，總是想得到更多，小b也不例外（請小b原諒我這樣說你）；於是，小b想是不是可以做的更多一點呢？要是能自己去排查和定位問題原因的話，應該更爽吧！而且前面學習了一些業務知識後，對於產品也有了一定的理解。為了達成這個目標，小b又做了如下事情（細節同上不講）：
1、自己發現的每個問題都嘗試去定位，並且對自己的定位過程全部記錄下來。定位不下去了再去找對應的開發（已經有了上面的一些排查和重現問題的基礎），開發也很樂意（因為節省了開發定位問題的時間）。一邊看著開發定位，一邊跟開發去請教（虛心的請教大部分開發也是很樂意賜教的 ）。然後將開發的定位過程同時記錄下來，等開發確認原因後。再跑過去跟開發一起回顧下整個定位過程，看看自己因為缺失什麼技能而沒有定位出來。
2、缺失的技能就主動去學習，其實無非就是對業務更加熟悉，然後掌握對應開發的一些除錯方法。同時也跟著開發一起去看**（慶幸的是測試能夠去看開發的**，以及跟開發的關係搞好了）。
3、下次碰到類似的問題就將以前總結的一些方法用上；
4、定期的梳理和總結自己的定位問題方法，形成自己的一套完善的定位問題過程，並且增加熟練度。
這個階段又經歷了一年多，過程同樣的痛苦的，很多次想要放棄，特別是需要自己去硬著頭皮看**還看不懂的時候。而且時間花費的比以前更多了。堅持下來後，結果自然還是不錯了。30%的bug自己能直接告訴開發大概是那塊出問題了，比如：某個地方的返回沒有判斷，記憶體沒有釋放等等一些基本的問題。當然，萬事開頭難，經過一年多後自己至少養成了自己去定位問題的習慣，而且在不斷的進步中（這個算是經歷的第三個階段吧）。
能自己定位一些問題，這些已經開始讓團隊的其他人員開始羨慕了，內心自然也開始膨脹，人性的貪婪也再次在這裡體現出來，小b居然開始想去自己修復bug。這是不是越界了？不過既然是他自己的選擇，我們暫且不去關注有沒有必要，一起看看小b接下來又幹了什麼事情吧！
1、深入學習開發的語言，並且用該語言寫一些小的測試工具來提高測試效率，通過具體的任務來學習編碼知識。
2、學習整個設計架構，並且嘗試用自己的理解對整個架構進行分析。
3、去分析和審核開發對應修改的**，並且試圖找出開發修改不合理的地方。
4、對於自己定位出來的bug，自己去主動給一些修復的建議，並且最後看看開發修改bug的思路跟自己的差別是什麼？
5、自己在另外的地方去寫fix的**，然後跟開發進行對比，不斷的找差距。
這個過程經歷了差不多兩年的時間，過程的艱辛估計只有小b自己知道，感興趣的同學可以自己去體驗下。不過總算是小有所成，小b自己也親自fix了5個bug（直接將自己修改後的**發給開發），其中只有1個bug是修改的有問題的（我們將這個階段稱為第四個階段）。
好吧，到現在為止，差不多整整過了五年的時間。小b也從乙個熱血青年變成了乙個快奔三的人了。也從當時的測試新手變成了目前測試團隊的大牛之一。因為對於團隊的重要性，工資待遇方面也有了很大的提高。
按照道理來說，小b應該很滿足了，畢竟自己也被其他人當成大牛來膜拜了，雖然自己的大部分工作依然是測試用例（不同是用例都是自己分析和設計的）—> 發現bug—>定位bug—>回歸bug（有時候自己也去fix乙個bug，不過這部分不是自己的主要工作）。人性的貪婪再次在這裡表現的淋漓盡致，小b下一步打算去幫助開發一起去做缺陷預防，比如：提取一些共性的問題，然後思考如何去避免和及時的發現這樣的問題。
原文就講到這裡，我總結一下小b的經歷，前後大概4個階段。
第一階段：菜鳥階段
測試用例—提交bug—回歸bug，甚至提的bug還要和開發進一步進行確認。
第二階段：定位問題階段
這裡不單單的能夠找到bug，還能定位bug到**層面。
第三階段：fix bug
這個就厲害了，能夠修復**中的邏輯缺陷。
第四階段：缺陷預防
這個更厲害了，能夠用豐富的測試經驗以及對bug的敏感性來定製方案，從而避免某一類或者某些通用性的bug產生。可謂將缺陷消滅在萌芽之中。
從測試小白到測試架構師之路 軟體及其開發過程的了解
今天終於抽出來時間，記錄下個人成長哈，既然進入到軟體行業，就必須對軟體相關知識進行了解，話不多說直接進度正題。一 軟體的含義 1.1能夠完成預定功能和效能的 可執行的指令 電腦程式 1.2使得程式能夠適當的操作資訊的資料結構 1.3描述程式的操作和使用的文件 軟體 程式 資料 庫 文件 服務 二 軟...
從功能測試到效能測試的轉型之路
引子 以下內容選自 小強軟體測試瘋狂講義 一書 正文很快課程就要開始了，整個課程設計的非常科學，有課程開始前，需要自己去主動學習的基礎知識，都一一列出來了，自己只要根據上面的要點，進行學習就行了。在學習過程中很多知識都會結合實際的工作專案來講，這種學以致用的方法，特別能讓學員眼前一亮，而且特別容易理...
從可測試的軟體到自容錯的軟體
一直我為軟體的整合 測試深受其苦，幾十萬行的軟體尚且如此，乙個更加龐大的系統又該如何。即使我們增強了單元測試的力度，同樣不能解決有效整合的問題，換句話說就是，即使分系統測試通過，還是不能保證系統更好的整合。以前我一直有個隱約的想法，軟體系統也應該提供模擬 的功能，在 容器中執行之後，基本就可以可靠的...