1. 深入理解uc
不管是日常還是專案，都要對uc有充分的理解。uc是由開發人員來編寫的，在思維方式與側重點上會和測試人員有所偏差。有時候會出現這樣的情況：開發人員認為自己的uc已經寫得很詳細了，但是測試人員卻不知道如何測試。這時候就需要測試人員和開發溝通，直至充分理解uc。這樣以後的uc評審、設計評審、tc評審才會是有效果的，測試起來也會是心中有數的。
2. 有效的溝通
在這裡和大家分享我第一次測日常的乙個小插曲。拿到第乙個日常時，很開心，終於有事情做了!yeah！第乙個日常一般都是比較簡單的，目的在於熟悉流程，uc評審後覺得測試點也不多，只是改變幾個引數。但是在測試中，乙個異常分支就是無法測出結果，幾次三番的和開發爭論這個在他看來很細小問題，終於，他怒了：「新來的怎麼這麼難溝通」，很受打擊的一句評語！最後發現的問題很簡單：我們對於設計思想的認識是一致的，只是uc中的輸入格式沒有做特別的宣告，導致異常流無法測試。而之前我們的溝通之停留在設計思想上，並沒有關注格式。換一句話說，我們後來關於設計思想的溝通都是無效的，這段時間的產出也就是無效的。
3. 我們是owner
幾乎是剛來到**，就跟進了專案，當時就乙個感覺，會議特別多，一會是uc評審，一會是技術評審，然後又是測試設計評審，tc評審，立項，乙個乙個會議弄得我是頭暈腦脹。但是其中最大的迷惑是不知道自己參加這些會議室有什麼用處。看到師姐提出了很多問題，和開發pd交流，感覺自己像乙個局外人的一樣。那時的我應該是有點僥倖心理的：該怎麼測試，師姐會告訴我的，她弄懂了，我就弄懂了。所以就這樣局外的走過所有會議。但是第乙個專案或者日常會有師傅帶的，自己總有成長的一天，不可能一直這樣的局外人。我們的sao告訴我們，我們是owner，接到乙個專案或者日常的時候，你就是owner，是主人，而不是局外人。既然是owner，自己要對自己的專案或者日常負責，這個責任不止體現在測試中，應該是貫穿始終的，設計前你是owner：要充分理解uc；設計時你是owner：要對uc中的問題提出自己的看法，改善設計；開發中你是owner：設計mm圖，編寫tc；執行測試時你更是owner：細心、全面；上線後你還是owner：跟蹤運**況。
4. 及時沉澱
做完日常或者專案的業務內容及時沉澱，這樣可以為後來者鋪出一條道路來。自己在工作和學習中，遇到的問題和解決方法也要及時沉澱，以後別人遇到問題的時候，也可以幫助解決。這一點，不能說是自己的經驗，只能說是教訓，很明顯的一件事情，就是自己來到**四個月的時間才將自己的一些感想沉澱下來，以後會改正的。(*^__^*)
5. 每個階段明確自己的任務和目標
日常和專案可以分為不同的階段，要明確每個階段自己的任務和目標。第一次做專案時總是不知道自己要幹什麼，什麼時候畫mm圖，什麼時候該寫tc，這些都要師姐告訴我，如果她不告訴我的話，自己就會覺得很混亂，不知道自己要做什麼。所以以後列出測試計畫之後，自己也要有自己的計畫，明確自己的任務和目標，這樣以後的工作中自己是清晰的。
6. 關於肯定
第一次做專案的時候被，發現了乙個比較隱蔽的bug，被開發小小的肯定了一下，很是開心。雖然這樣的肯定只是他在bug的備註中標註了一下，但是對於我來說，是個不小的激勵哦。
7. 關於gba
首先解釋一下什麼是gba。gba即golden bug award，是每個q舉辦一次的bug評選活動,目的在於發現測試過程中的一些深層次，技術含量高的bug。在第乙個專案接近尾聲的時候，師兄讓我們從自己所提交的bug中找出自己認為有價值的bug來參選。終於在百淘的前一天，從自己所提交的三十幾個bug中挑選出來了乙個，很開心的是入圍了第一輪評選。雖然很清楚自己離gba還有很長的一段距離，但是能入圍也是對自己的肯定。能夠和各位前輩一起講述自己發現bug的過程，bug的意義，這段經歷很難得!
其實關於這個bug還有很多話想說，這個bug並不是**的問題，而是設計不合理導致的邏輯bug。如果在評審的前期，將自己置為owner,充分理解prd，那麼這個bug是可以防範在設計階段的，這樣，在後期也就不出現需求方、開發和測試一起重新評估這個bug，對設計和**做出更改的情況。這也算是乙個教訓吧，吸取教訓！！！
8. 關於介面人
autoamn自動化測試繼承和改進了tcommon，是珠聯璧合的又一利器。作為二號介面人，的我，要負責起全組的automan培訓。這樣是自己成長的乙個機會。很多人會問你問題，當你把這些問題解答的時候，自己自然就會得到成長。很珍惜這個機會。關於結果，等培訓結束後，再見分曉吧。
測試小白的測試心得
1 測試用例是測試工作的核心，寫測試用例的時候建議先提取測試點，再編寫測試用例。清晰且不容易遺漏。寫測試用例的過程中要不斷的調整，之前用例覆蓋到的測試點可以不寫，覆蓋率全且避免重複 2 測試資料要盡量真實。3 測試時考慮到了別人沒有考慮到的問題點，最好要去一一和產品確認溝通過 或者是發現了設計上有不...
菜鳥的測試心得
1 完善的需求文件，原型，概要設計文件 通過這些開發文件可以了解整個系統的架構。要實現的功能，及業務流程。為測試計畫中的測試要素和測試策略提供依據。在沒有詳細的開發文件時，可以項開發人員詢問，或參考先前的軟體版本。抓住業務流程。2 測試計畫的重要性 測試計畫從時間上進行了部署，明確的測試的重點和內容...
關於管理的心得
剛才讀了論研發團隊的建設 有點感觸，想在這裡也談談自己對管理的看法。雖然每個公司的管理大環境都不一樣，但是有兩種人的選擇在管理中起著至關重要的作用。我認為只要這兩種人的選擇正確，公司必然會健康發展。一種人是專案經理。專案經理作為公司的基層管理層，直接面對專案成員和客戶，是公司專案成敗的關鍵。選擇專案...