在乙個交流討論會上，開發對我說：「測試給我的印象，就像是在雞蛋裡挑骨頭。」我聽後哈哈大笑，對他說：「如果雞蛋是新鮮的雞蛋，那不管我們怎麼挑，也不會挑出骨頭來；如果雞蛋變質了，或者將要孵化成小雞，不單是雞蛋裡挑骨頭，而且還是雞蛋裡挑雞毛了！。」
當然，這只是乙個玩笑，只是在這個玩笑的背後隱藏著開發對測試的誤解，也隱藏著測試工作的本質。我可以理解他對測試的看法，因為很多時候，我們對產品的質量要求都非常嚴格，除了基本功能測試外，還會做效能的調優測試、異常測試，基本功能的bug比較容易修改，而且有依可循；但是，效能調優和異常測試出來的問題就不那麼容易解決了。有時候，在效能調優時有些問題的修改甚至會關聯到整個流程的變動，改動多了，開發自然就會覺得煩；而且，工程上對效能也無乙個明確的需求，測試提出來的可以說是乙個完善的建議，改了肯定會完善產品，不改也不會受責難，開發會不明白測試為什麼偏偏那麼追求完美；有些異常測試，工程上出現的機率是1%，為了這1%而大動干戈，開發自然會問這是否值得。除了異常以外，連日誌的可讀性、規範性，還有介面的友好性、易用性，測試也會要求開發力盡完美；作為開發，他自然就會認為，功能實現了就好了，為什麼還有這麼多可有可無的講究？
不過，從測試的角度來看，問題就不一樣了，測試必須對產品的質量負責。首先，要確保功能滿足需求，功能有問題自然不能通過測試。其次，會考慮系統的效能和完善，在同類的產品中，大家都實現相同的功能，在功能上不同的廠家並沒有太大的差別，但是，效能就不一樣了，好的設計好的產品效能會高上好幾倍，在實際的執行中價值就體現出來了。再次，對於異常，在大多數的情況下自然不會出現異常，但是是否就可以確保永遠都不會出現異常呢？當然不是，即使是只有萬分之一的機會，異常也是會出現的，而且異常的出現往往會帶來災難性的後果，這又叫測試如何可以忽略呢？最後，對於非功能性的問題，比如有助於日常維護的日誌，客戶使用的介面，這些雖然不是什麼大問題，不修改也不影響功能的使用，但是卻影響到了產品的使用效果，直接影響到了客戶對產品的第一印象。
測試與開發，還真要相互理解，如果乙個產品在設計的時候就考慮得比較完善，在實現的時候確保質量，那麼，不管測試怎麼挑也不會在乙個新鮮的雞蛋裡挑出骨頭了；但是，如果雞蛋已經不是我們所期待雞蛋，骨頭自然會挑出一大堆。
另外，從另乙個角度來說，相對於其它測試人員來說，我的要求也真的太過完美，有時甚至有些苛刻。我自己也一直在思考乙個度的問題，測試肯定不可能發現所有的問題也不可能把產品測試得非常完美，但是也要保證產品的質量，在兩者之間應該有乙個平衡的度，只是這個度該如何去把握？
是否把雞蛋放在乙個籃子裡 多雲or單雲的思考
目錄 前言 主題 多雲不是銀彈 優劣分析 高可用方面 成本方面 易用性方面 功能方面 企業戰略方面 總結 本人一直專注於多雲架構的研究，經常與雲原廠人員進行溝通，對單雲和多雲有一些感觸，在這裡與大家分享下。多雲在很多方面有單雲不具備的優點，所以大約1年前我還一直以為自己堅持的多雲持續交付才是最先進最...
雞蛋裡挑骨頭 讀《浪潮之巔》
本書在業界的口碑很好，作者視角很大，不僅把 it 史的時間線梳理的很好，很多見解讀起來也給人頗多啟發。但仔細讀，還是會發現有很多地方值得推敲。其實，一家企業的成功與失敗，是有很多不確定因素的。還有一些細節，出現了前後矛盾 比如，在 p5 作者提到 資訊理論是整個現代通訊的基礎。而在 p13 結束語中...
測試網路是否連線
ios移動開發自然少不了網路的支援，下面我就來介紹下如何判斷現在該裝置是否連網。網路測試 新增reachability.h和reachability.m 新增systemconfiguration.framework框架 獲得連線狀態 reachability reach reachability ...