時間如指縫滑過的風，還沒來得及察覺，就已流逝，不知不覺做測試工作快一年了，從沒有專案
經驗到em，從em到hrs，從hrs到crm，從crm到cb...迷惘過，也失落過，但就在這迷惘與失落的同時，自己也在慢慢的成長……
從erp資訊員到軟體測試：
我以前一直過著與世無爭的生活，只要能吃飽，就算天塌下來也無所謂，大學畢業做了一年多的erp，工作很輕鬆，當時也很樂意做這樣的工作（可那時我忽略了一件事：我，是男人）……時間如牆上的蝸牛，雖然爬的慢，可一刻都沒停止過，再回頭只能看到牆上的那道淡淡的白色「軌跡」，某年某月（保密）與戀愛十一年的她分手了，堅貞的情感，最終抵擋不住金錢的**，曾經自己的公主拜倒在別人的腳下……
沒有痛，因為心已麻木，沒有哭，因為有雨，有人說淚水可以泡軟人的脊梁，如果你甘願墮落，我頹廢了將近2個月，又有人說淚水可以讓人變的堅強，如果你不向現實低頭。只要有風吹過，淚水總有幹的時候，漸漸的我開始思考，漸漸的開始發現，錢對男人是多麼的重要，於是我辭職了，考察了很多行業以後，我選擇了軟體測試，因為它的前景，也因為自己的特性，於是我向測試邁出了第一步：參加測試培訓，培訓的過程除了聽、記、問、實踐以外也沒什麼可說的……
對面試班駁的記憶
第一次面試失敗原因：1、學了後面忘了前面，沒有及時回顧以前的知識2、緊張是最大的障礙，記得那次問的問題很簡單，但是很多平時脫口而出的知識點，這時候卻怎麼也想不起來，主要問了以下幾部分內容：osi七層結構、白盒和黑盒測試有什麼異同，編寫用例有哪些方法，軟體測試生命週期，軟體開發模式有哪些，如何提交缺陷，linux常用命令有哪些，sql語句：增、刪、改、查、建立檢視、建立儲存過程等，軟體測試需要哪些素質，你以前工作還不錯，現在為什麼選擇測試，你認為你做測試工作的優勢是什麼？總之問了很多，不過問題都不難
失敗後，我採取的對策；買了個可隨身攜帶的小本子，花了一下午時間總結一下面試中問過的問題，晚上又到網上查了很多面試中可能問到的問題，一一記錄下來，後來又花了2天時間把所有學習中的重要知識點記錄下來，再後來的2天我出現在了秦淮河邊，手裡拿著那個小本子（後來送朋友了）.....
第二次面試：失敗原因對待遇問題回答的失敗：
第一輪筆試，考的是開發的試卷c/c++，c佔10% c++佔60%，智力題30%，因為沒學過c++，所以c++都是根著自己的推想答題的，c語言只有2題，乙個選擇題乙個程式設計題（考了指標）智力題總共4題，比較簡單都做對了，具體題目記不清了（面試結束回家等通知，回家的路上買了本c++從入門到精通）
第二輪測試王經理面試：問了很多測試方面的問題，都是對答如流，但後來問了2個開發的問題，乙個物件導向語言的，剛好看到過，回答上了，還有個是架構方面的，沒回答上來，我說不好意思我不會（後來才知道，勇敢的承認自己不會要比亂回答好的多）面試的過程很愉快，面試結束後，王經理說，請稍等一下，人事部陳經理有些人事方面的問題要問一下
第三輪人事陳經理面試：開始問了一些問題：怎樣做好測試，為什麼選擇測試行業，等等都回答的很好，最後聊到薪水的時候，陳經理問：假如我們公司錄用你，你期望的月薪是多少？我說：作為乙個測試新人來講，測試經驗對我來說很重要，薪水多少並不重要（犯了個巨大的錯誤，對薪水要求過低會給對方造成缺乏自信的誤解）陳經理說：「薪水不重要，那公司不給薪水你也願意做嗎？怎麼可能？」聽到這句話，我知道＇成功的母親＇又來看我了．
失敗後，我採取的對策：記錄下人事問的問題，修改了下對薪水問題的回答：測試經驗的積累對於乙個測試新人來講無疑是最大的財富，但人要生存，又必需有經濟收入，我期望的薪水就是經驗財富與物質財富的平衡點：月薪***（回答的時候面帶笑容，語速不能太快，最好能像和朋友聊天一樣），當天又到網上查了很多面試陷阱
第三次面試，成功的開始，成功原因對基本知識的掌握、自信、禮儀
第一輪上機面試：參與面試的共六個人，公司直接給個系統，讓我們開始測試，然後寫份測試報告，時間2個小時
這是我第一次接觸真實專案的上機操作，緊張是難免的，但是很快就進入狀態，首先看了下測試說明（缺陷提交規範），然後開始看需求
文件，看完後，開啟系統，開啟需要測試模組的每個功能模組，粗略看下有哪些功能，然後進入了漫長的測試（沒有用例，只能通過自己對系統的理解去測，再次說明需求理解對測試的重要性）房間裡只剩下6個相對靜止的人……
時間不因為我們的「靜止」而靜止，終於上機時間到了，把測試報告提交到指定資料夾下，當時測試說明中明確規定，以姓名_日期.txt命名報告， 可開啟資料夾，有word，有execl，有的命名格式也不對……
上機結束了，大家自我感覺都很不錯，當時我表現的並不好，找了23個bug，第3，這時經理和我們講，你們要是沒什麼疑問就先回去等訊息吧，我把椅子還原到原來位子，因為是最後乙個走，和經理說了聲：**經理，謝謝您，再見，然後又和另外一位在辦公室的員工說了聲再見，然後隨手把門輕輕的帶上
第三天，6個人中只有2個人接到**面試通知，其中有乙個是我
又過了2天，**面試開始了，有點緊張，但問的問題基本上都回答上來了，**面試結束前，問了下，請問經理您貴姓，他說他姓王，我說謝謝您王經理，希望以後有機會向您學習測試經驗（可以不失時機的表達一下自己對學習的渴望，語氣要誠懇）
又過了2天，接到經理打給我的**，面試通過了，6個人只有乙個通過
成功經驗：1、熟悉系統，不錯發bug，嚴格按要求做（當然公司有什麼不合理的地方可以提建議）
2、禮儀、禮貌（一般比較正規的公司都會注意到這些細節）
3、學會總結，不要讓自己在同乙個地方跌倒
下面總結一下測試新人，怎樣快速找出系統的不足或缺陷
1、閱讀需求文件，深入了解系統，磨刀不誤砍柴工，不要還沒弄清需求就開測了，（乙個星期前，公司剛進乙個新人，td上檢視了下他們發的bug，發現好幾個是需求不明確誤發的）心想：原來是這個系統啊，專案實訓的時候做過和這個類似的專案，於是就把實訓的系統需求硬生生的搬到當前系統來，這樣做的風險太大，因為每個系統的需求都不一樣，不能生搬硬套，打個比方：假設要你製造一輛轎車，你以前製造過普桑，就把你製造普桑的技術拿去製造林肯，這樣做顯然不合適。熟悉系統（一般公司都會有系統熟悉情況考核）所以請一定要認真的閱讀需求文件（有的公司叫產品定義）
2、熟悉測試用例，這是測試執行的乙個導向，要想快速高效率的執行用例，必須在熟悉系統的同時，熟悉用例，熟悉每條用例覆蓋的需求，這樣執行起來才能事半功倍
3、記住自己在工作中扮演的角色是測試而不是開發 。珍惜時間，避免不必要的浪費。作為乙個測試新人來講，剛開始接觸專案，有很多時候發現bug，只是知道它的表象特徵，卻無法弄清這個缺陷是由什麼引起的，這裡就存在乙個誤區，花過多的時間去尋找原因，因為受個人所學習知識和經驗上的限制，有的缺陷很難短時間內找到產生原因，與其這樣浪費時間，不如將bug重現給開發看一下，讓開發找原因，那樣即不耽誤下面的測試也能在短時間內找出原因，從根本上解決bug。
4、一旦發現缺陷，應立刻提交。有幾種情況：測試就像是一場優勝劣汰的戰鬥，你的動作慢了，成果就是別人的了。
1）作為乙個測試新人來講，測試的第一步，可能是從執行用例開始，而成功的用例（專案剛開始時）可以發現很多系統中存在的問題，同一條case裡的不同step就可能發現多個bug，那麼對於這樣的情況，我們要做的是：發現就提交，不要等到所有step都執行完再提交。那樣說不定已經被別人提交了。
2）『拋開』需求說明書（即不用看需求說明書，對需求也特別熟悉），以快取勝。假設你和同事同時發現了個bug（雙方都不知道對方在提交），而你對需求不熟悉，不太確信是個bug，然後又去翻需求，翻完回來再提交，結果這時候同事已經提交了，那麼不好意思，你的bug只能作closed_nbug處理了，如果一定要加上乙個批註，那麼將是，重複提交（測試新人，備註裡不建議加測試建議（即怎樣修改可以避免此缺陷），因為有可能會對開發產生誤導）特別說明：1）速度和效率同時考慮，盡量別發錯bug；2）公平競爭，還要考慮團隊合作，在別人的測試模組發現bug，建議告知對方提，與同事交流的時候，同事講到的缺陷，而缺陷管理
工具中沒提，應該讓對方提交上去
5、新版本發布：
1）驗證fixed缺陷，如果驗證通過了，把狀態改為closed（關閉的時候一定要加個備註，（比如：某月某日某版本驗證通過。）對於開發修改了，但是與需求有出入的，且與測試經理確認可以這樣修改時，備註建議這樣寫：某月某日某版本驗證通過，修改為……），如果沒通過改為open（同樣加個備註：某月某日某版本驗證未通過），這裡存在乙個誤區，有的人會把狀態改為reopen，如果是公司要求的，那無可厚非，如果沒有要求，建議改為open，因為reopen是已經確認修改並且該bug已經改為closed狀態後，才需要修改為reopen狀態的。（有很多公司是不允許出現reopen狀態的（針對開發），一旦出現，開發此模組的程式設計師績效可能會被大打折扣，我現在所在的公司就是這樣的）
2）冒下煙確保主流程暢通，然後再進行功能測試，著重測試有修改的或者與所修改模組有呼叫關係的模組和發現bug比較多的模組（公司發布版本會郵件通知修改的模組與修復的bug），未改動的模組建議做個流程測試。特別說明：主流程走不通，應立刻msn給專案負責人（組長或經理，如果有本專案msn群，直接在群裡講就可以了）
6、如果版本未更新，
1)建議著重進行業務邏輯方面測試，在電腦上以文件形式畫出簡單的業務邏輯圖，重點說明：一定 要盡量考慮所有的情況，因為這樣的bug要麼就沒有，一旦有就是high
2)建議進行環境測試（當然要根據需求測試相應的環境）
3)嚴格核對需求文件，防止需求遺漏
7、嚴格按照缺陷提交說明提交bug，因為這有可能涉及bug的統計問題，（一般公司的缺陷描述：系統名稱_功能模組，缺陷描述，要具體問題具體對待）
優先順序和嚴重程度不要誇大也不要降低，實事求是，因為這與開發和測試的績效考評有掛鉤，要是誇大缺陷，會影響開發的績效考評，降低會影響自己的績效考評，建議：系統級（影響流程）和跳黃頁（報伺服器錯誤的，這類缺陷有的是伺服器配置錯誤導致，建議先檢查配置後提交）建議為高，功能實現建議為中，介面易用，或者不影響系統使用的其他問題建議為低，具體級別公司會有規定，如果沒有規定，可按照以上建議劃分。
8、測試沒有空閒。專案在不同階段，會有些時間很『空閒』。建議：
1）把測試管理工具中的缺陷分類匯出，總結一下哪些模組容易產生哪些缺陷，重點看一下自己沒發現或沒有考慮到的缺陷，有多餘時間可以看一下closed_nbug、bydesign、rejected、deferred的缺陷
寫給軟體測試新人 如何快速提高自己的測試能力？
隨著銀行業務的快速發展 新興網際網路金融業態的興起，科技資訊軟體的更新迭代速度日新月異，使用者對軟體質量 使用者體驗也有了更高的要求，而規範 有效的測試是保證軟體質量的重要環節。軟體質量的提公升，首先是要形成一套行之有效的測試體系，但光有體系遠遠不夠，還需要具備相關技能的人員來執行 落實體系。目前，...
我的測試生活感悟1
有些天沒有更新部落格了，有的時候想到一些東西，打算把它寫下來時發現時間不夠，有時寫著寫著發現自己開始長篇大論，原本一兩句話可以說清楚的事情，非要用幾個段落來描述。當我看完一本幾百頁的書時，真正記住的原文內容不會很多，通過自己總結，大約可以用10句話來描述。因此，我打算用一種簡潔的 無廢話的方式記錄一...
測試新人的目標管理
畢業進入測試行業快一年了，經歷了學生到職業人士的轉變，經歷了軟體測試空白到一定積累的轉變，突然一天 有點迷茫，我該走向 甚是迷茫，因為接觸的東西太零散了。和師哥聊了一會兒，目標最重要。那麼又如何分解目標呢？軟體測試從大方面可以分為幾大領域測試 功能測試，效能測試，自動化，探索性測試，安全性測試。作為...