做了多年的研發工程師，在所處的環境中，所接觸的開發人員中很少有看重對自己**進行測試這項工作的。大多研發人員往往是寫好了**執行起來，簡單做下測試，甚至不去測試就拋給介面使用者或者質量管理人員。而且理由很充分「沒時間...；我覺得應該沒問題...；這種簡單的事讓專職人員去測試，否則浪費自己的時間....」從這些話首先該否定的是其人的職業素養，還有就是設計的**結構不好測試，或者根本就寫不出好的測試demo。
記得我們曾經的團隊開始強調測試是在工程漸漸龐大，模組逐漸細化，人員參與較多時。因為每每在聯合除錯時，總是相關人員的噩夢，往往每個人都會被系統的某個bug打斷現有工作，還時不時會出現互相埋怨互相推脫bug責任的情況出現，等定位出bug再分到具體的人頭上。乙個bug牽扯到乙個團隊，算一筆賬，這個團隊有6個人，假設在自己的模組中每人平均出現5個bug，這樣在系統中就有30個bug出現，可能在測試過程中每個人會被中斷30次去協助他人定位bug，這種對乙個bug而言，非相關人員產生的中斷打擾和時間浪費是明顯和巨大的。當然，我只是舉個例子，現實中也許不會這麼極端，往往是兩三個人會出現這種協作情況。但是對相關人員這也是不可忍受的。
怎麼辦呢？引入單元測試，反對聲很大，其中原因主要有兩個：1.如果不和別人的模組一塊聯合，沒法做測試；2.要自己模擬某種操作還要造資料太浪費時間；第一種情況說白了就是寫不出單元測試，在你做這個埋怨時先看看自己設計的程式，我想如果你如果嚴格做到了高內聚，低耦合；業務和功能分離；或者經典的mvc模型，怎麼會做不了單元測試；第二種情況完全就是撿了芝麻丟了西瓜的典型表現，就拿我剛才舉的例子而言，你把時間成本都浪費到後期的聯合除錯和定位bug責任人，甚至到了質量部門再因為各種邊界測試，壓力測試找你上門。
最終我們的團隊還是沒有強制單元測試，也許有程式架構的問題，也許有專案週期太緊張的問題，但是我覺得更多的是大多數人沒有認識到單元測試對乙個大系統重要性，甚至寫好程式自我測試都做不到，自信到總是來來回回的不停發布新的fix版本。
也許是我深受其害，也許是我很在意別人對我程式的看法，我盡量要求自己在寫**時做好單元測試，在完成程式時自己多測測，多執行，多點點。因為我覺得這樣當我提交自己的模組，自己的程式時心裡才踏實，不然還真是「擔驚受怕」。
coderzh的技術部落格
開發團隊測試的難與易
做了多年的研發工程師，在所處的環境中，所接觸的開發人員中很少有看重對自己 進行測試這項工作的。大多研發人員往往是寫好了 執行起來，簡單做下測試，甚至不去測試就拋給介面使用者或者質量管理人員。而且理由很充分 沒時間.我覺得應該沒問題.這種簡單的事讓專職人員去測試，否則浪費自己的時間.從這些話首先該否定...
軟體測試中開發團隊和測試團隊的職責
開發團隊職責 1.在開發時，對軟體特徵完成單元測試 2.為測試團隊準備好專案部署以供測試 3.在將待測試模組 部件發給測試團隊進行測試之前，首先應該進行整合測試 冒煙測試 4.在需要時，幫助測試員評估測試結果並辨別缺陷，以確保提交到缺陷追蹤系統的報告準確性 5.修正缺陷追蹤系統中的缺陷 6.對缺陷追...
知易行難與信難行易
知易行難與信難行易 紅朝儒生 2016 2 26 關鍵字 知易行難 信難行易 簡介 知易行難，信難行易。吾很羨慕記憶力強的人。一本書，吾看一遍之後，再看一遍，會發現不少內容上次似乎沒有看過 看第三遍時還有這種感覺。還好吾看書還算不懶，所以多少總能記住一些。過目不忘倒是不奢望，啥時能記住大半也很滿意了...