記得我剛工作的時候，還完全不明白測試是怎麼回事，現在要說測試倒也能一套一套的說了。
測試分很多種，UT，IT，AT，場景測試...
還可以這麼分，自測，他測，依據測試設計書測試，Free測試...
UT可以利用很多工具，比如NUnit+代碼測試覆蓋率工具。
NUnit，廣受好評，可以過濾掉大量的bug，不過我在工作中運用不多。
代碼測試覆蓋率工具，可以統計出有多少分支會被跑到，有多少分支沒被跑到，可以一目瞭然的看出來，分支走沒走全。
IT，結合測試，但目前我工作中的IT沒有達到結合測試的目的，本來是應該跟系統中的其他業務進行連接，測本身業務的同時測試兩者之間的聯繫，能發現些業務設計衝突，矛盾的問題，早發現，早根治。
AT，驗收測試，只是關注功能實現，用戶使用，不會注意小的細節
場景測試，整個系統內部關聯業務關聯一起測試，驗證數據流，業務流有沒有問題，有沒有設計漏洞，有沒有接口設計錯誤等。
爲了保證質量，測試一般都會進行幾輪，所有的Case都會在修正bug的基礎之上來全面測試。但其實在不知道bug是怎麼樣修改的情況下，如果開發人員改完自測沒有做好，埋下了雷，想要掃出來，還是挺困難的。
近幾天公司總是在說測試，用了那麼多工時，卻沒有發現那麼多問題，在最終用戶那裏還是出現瞭如此之多的bug，天天分析爲什麼，以及對策，還要加強場景測試。不過個人覺得，這個時侯，做場景測試，沒有什麼必要，因爲這些bug都是在IT放過，或者在集成埋下，再不然改bug造成bug，無非也就是這幾種，跟場景沒有什麼關係，雖然在最終客戶那裏，發現的bug，操作都很簡單，也都是基本邏輯，出錯是不能原諒的，但都基本不是業務間的bug，而是內部bug。爲什麼會歸咎於場景測試不夠呢，因爲在用戶使用看來，就是那幾個場景，沒有什麼特殊的，但其實，操作簡單，數據複雜，每天假設有100次某一個操作，這100次的數據都是不一樣的，所以纔會出錯，而這100次的數據，在IT的時候，沒有進行數據設計，沒有詳盡的說明，沒有人想到，測到，就變成bug，影響到了用戶評價。如果非要歸因於測試，還是一個原因，數據不夠多樣，沒有想到會出現此類數據。最終還是歸咎到人，測試人員水平不夠...
前幾天看人月神話，裏面有一句話，雖然軟件工程管理在不斷的探討人和管理，一直想拋開人的因素，或者不讓人成爲主要因素，但每隔一段時間，就還是會返回到人是根本因素這個結論上。
測試當然也是不能跟人分割開的，測試人員的資質，水平，經驗都決定了測試結果的好壞，發現bug的多少，有效bug的多少，最終決定項目的質量。
那麼，怎麼才能讓一個剛進入項目的人測出問題來？
首要條件是這個人，要有興趣去了解項目是在做什麼。也就是我們說的進行深入的業務學習
其次，要有一個系統的觀念，哪些是測試重點，哪些可以後面再細摳。一般每個階段的測試目的也是不一樣的，所以，每個階段對某些問題的重視程度也是不一樣的。
接着，劃分完測試重點，當然就是設計測試用例，編寫測試式樣書，這個階段需要特別注意，不是任何人都可以寫測試式樣書，詳略要得當，做到簡明扼要不是一件容易的事，而且同時要將所有的排列組合都列出來，衡量哪些要寫，哪些能讓人發散思維
但是，僅僅通過測試用例，測試式樣書來保證測試的質量是不夠的，這時候就跟人有很大的關係了，如果測試人員有相關項目經驗，自然會想到一些可能出錯的地方，通過free測試來挖出bug，如果測試人員沒有相關經驗，也許就會抓着一句話研究半天，最終還是沒找到重點。這時就需要人去引導，而不是讓他們自己去研究，可以通過討論，把不明白的先弄明白，就我個人看來，如果文檔寫的好，能引發共鳴，能讓人從測試中理解業務，能讓人發散思維，這樣對人的幫助是很大的，可能測完一遍，測試人員就能明白業務目的，流程等，自己就能想到要測什麼。系統的寫測試式樣書也是一個待研究的課題。