開發不能有的心態：
不要妄自揣測誰會使用自己的應用，因為誰都有可能。
不要以為每個訪問者都和自己一樣精通計算機知識，他們或許對計算機知識一無所知。
不要樂觀地認為使用者會因為**導航體驗不佳而還能保持瀏覽的興趣，因為有很多競爭對手。
不要天真的以為自己了解所有使用者對於效能和資訊的終極需求。
上面的四句話，是對開發人員說的，但是對於測試人員來時一樣適用
測試三大心態
破壞心態
既然是找bug的，那就要挑刺，盡可能做到雞蛋裡挑骨頭，唯一需要關注的問題是怎麼處理與開發的關係，不然有的是與開發爭吵了。
第三方視角
作為一名測試，在很多時候從產品開發時就已經參與其中，所以對產品瞭如指掌。這會造成很多時候在測試的時候，會按照用例上面的步驟來。要知道，用例也有可能會有遺漏。把自己當成第三方，作為乙個陌生人來測試，效果會截然不同。
好奇心&興趣
好奇心就像你得到你個新玩具，然後不停的去玩。測試也一樣，在面對乙個新的產品，你要把它當成你心愛的玩具去研究，直到產品「壞了」為止。
興趣，也很重要，軟體測試有時候是乙個很繁瑣枯燥的工作，沒有興趣，就靜不下心來去測試，當把測試當成自己的興趣時，做什麼測試都會事半功倍的。
測試需要的最基本的一項技術：描述
測試的工作就是找bug，不管與開發的關係如何，但是只要是個bug，開發就要去解決。那麼問題來了，你如何去給開發描述這個bug呢？在描述一些bug，特別是某些奇怪bug的時候，是很難描述清楚的，造成的結果就是描述的bug測試明白，開發不理解，開發都要跑來問（開發人脾氣好啊）然後給演示，難道要每個bug都要演示一遍？所以清楚的描述bug就很重要了，語句既要簡單明瞭，又要通俗易懂，不然你懂了開發不懂也不是個事啊。這個就看語言的功底了。自我心得：記得剛開始幹測試的時候，實在不知道怎麼描述問題了，直接截圖，然後描述。但是有很多問題就是截圖也描述不清楚，記得有段時間開發常駐身邊，那個心情，後來就是在描述bug的時候，總是花費很多語句。有次開發給我說我描述的問題太臃腫了，讀起來太費時間，然後就開始寫得簡潔，開發又開始讀不懂了。總是在這兩個中間搖擺了很長時間，才有所改善。所以啊，描述bug，也不是個簡單的事啊，除非開發就坐在你對面。
外包中的「小事情」
談到外包 管理，不知別的cio認為最困難的是什麼？對我來說，在外包 管理環節當中，有乙個我一直沒有做得非常有體系的環節 人天的計算。我曾與一位業界前輩交流這個困擾，他說 做了10多年 it 怎麼可能連人天計算這種小事情都搞不定呢？不可否認，他說的有些道理，人天計算的確看起來像是 小事情 但是在專案展...
TCP UDP的小事情
沒有複雜的控制機制，面向無連線的通訊服務。常用於 包總量少的通訊 對傳輸 傳送 通訊 進行控制的協議。面向有連線的協議，只有在確認通訊對端存在時才會傳送資料，udp是對端不存在也會傳送。通過檢驗和 序列號 確認應答 重發控制 連線管理以及視窗控制等機制實現可靠的傳輸。通過序列號和確認應答提高tcp的...
小事情大道理（一）
最近發生了好多的事情，但每件事情都凸顯了我思想上的不成熟。之前我們 10期內部也就作品展出現的問題頭腦風暴，有點效果，但是甚微。昨天 9期的師哥師姐和我們一起頭腦風暴，通過出現的問題，刨根問底，分析每個人的潛在想法。歸根結底是我們沒有意識到公尺老師的價值。其實我知道公尺老師很重要，但重要的程度是多少...