大家平常調侃開發，又去寫bug了，雖然是一句玩笑話，但是世界上真的存在沒有bug的程式嗎，不知道，最近看到乙個段子寫的特別的好，一天乙個程式設計師在加班加點的寫東西，然後佛看到了，對程式設計師說，看你很辛苦，天天加班加點的寫東西，我可以滿足你乙個願望，然後程式設計師就許願了，說，希望在我有生之年可以寫出乙個沒有bug的程式，然後這個程式設計師就得到了永生。這雖然是乙個段子，但細細品味，難道真的開發和測試就是水火不能相融嗎？
最近實在看不慣公司的開發流程了，因為剛上線了乙個版本，線上暴露出來的問題比較多，不得不暫停這版本的上線，發回重測試，糾其原因，我覺得需要從以下幾個方面分析
一，站在開發的角度來講，開發一直有新的開發任務，還要去改測試提交的問題，可能有些開發任務不是很明白，還有測試提交的bug可能描述的也不是很清楚，還要找問題，然後改問題，一般找到問題後就把這個bug改掉，至於涉及到的其他模組是否有影響，不管了，可能也不是自己開發的，看不明白，再就是時間丟給測試去測吧，到時候測出來再改吧，先完成自己其他的開發任務
二，站在測試的角度來講，提測後，要執行測試任務，發現bug,要不斷的重試多次，確定是個bug,然後分析原因，和開發溝通，確認是bug,然後提交給開發，催著開發改，改完之後打包再次驗證測試，而且每次發了以後，直接丟給測試，從來不會深入的多看幾影響的其他模組功能，看是否有其他影響，每次測試去問影響範圍，測試範圍的時候，就一句話，全量測試，但是測試同乙個東西天天測試，疲於重複繁瑣的工作，而且由於開發的懶，只改了一處或者就每改好發包，讓測試，這時候是很消耗時間的，而且效率低下，每發一次包，需要造好多資料再驗證，而且有些問題還不好重現，再就是回歸後，如果時間緊張，涉及其他的也懶得看，主要是因為也不知道涉及到哪些，影響到哪些，如果時間允許的話，當然可以去好好的測試一番，而且測試遇到最煩的不是這，而是發現乙個問題，給開發，開發說這我不知道，別人傳給我的，那誰傳給你的，你有得去找，乙個乙個找，等把對應的開發找出來的時候，黃花菜都涼了，他們只關係區域性，不關心整體，這也就是為什麼公司測試是最懂業務的，這就導致了乙個bug,頁面把底層的異常給拋到頁面了，每個人去呼叫底層方法，都懶得處理異常，遇到異常，一直往上拋，跑到最上面，沒處理好，直接就爆發出來了
三，站在產品的角度來講，因為客戶現場，千奇百怪的需求一堆，而且要頂著上級領導的壓力，不斷的創新，迎合快速響應市場的變化，不斷更改需求，所以需求是乙個變動的過程但是這個下來後開發要改，要重構，修改之前的，測試也要重新去測試，修改對應的用例，所以整體來講，源頭還是產品這塊，公司一定要加大產品投入，再設計產品的初期就把需求多想想，多思考，盡量變更較少，而不是一直再變，在產品開發的過程當中，如果再改需求，那帶來一連鎖的反應，造成後續的工作量是成倍增加的，
這是個矛盾體，怎麼解決，開發和測試不是仇人，不是對立面，一切的源頭都是產品這塊，但是產品也很無奈，客戶要求改如果開發強勢，產品不敢提需求，測試不敢提bug,試問那麼做出了的產品是乙個什麼樣子
其實我一直思考，怎麼提高工作效率，覺得其實產品不是測出來的，真的是管理起來的，如果乙個公司現在開發完產品就丟給測試，覺得自己的工作完成了，覺得出了問題都是測試沒有測出來，那麼這個團隊是有問題的，因為沒有形成良好的閉環，大家沒有質量意識，完全是靠別人，開發靠測試，產品也等著靠測試，那測試靠誰，只能不斷的提交自己的能力，不斷加班，上線擔驚受怕，就怕出問題，這樣是有問題的，整個專案流程是有問題的，不然的話，怎麼會出現專案管理這門學科，專門去研究呢。
不斷的測試，產品就會不斷的改進
什麼是軟體測試？關於軟體測試的定義，比較權威的是ieee在1983年提出的 使用人工或自動手段來執行或測定某個系統的過程，其目的在於檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。軟體測試的目的？第一 確認軟體的質量，確認你所期望軟體所做的事情和確認軟體以正確的方式來做了這件事情 第二...
軟體測試 產品的十大可用性原則
尼爾森的十大可用性原則是產品設計與使用者體驗設計的重要參考標準，值得深入研究與運用。一 狀態可見原則使用者在網頁上的任何操作，不論是單擊 滾動還是按下鍵盤，頁面應即時給出反饋。即時 是指，頁面響應時間 小於使用者能忍受的等待時間。二 環境貼切原則網頁的一切表現和表述，應該盡可能貼近使用者所在的環境 ...
產品 前後端 開發 測試的見解
首先自述一下，阿拉是一名程式設計師，當過專案的救急人員，也當過小小的網路黑客，混跡於傳統網際網路與移動網際網路多年，閱歷過多種開發模式，如 敏捷式開發 瀑布式開發。快速開發 反覆迭代，以最快速度達到使用者的需求。按照軟體開發流程，制定計畫 需求分析 軟體設計 程式編寫 軟體測試和執行維護等制定六個基...