原文：
測試一般是放在系統完成後進行測試，但今天，卻常常聽到資深開發人員勸導新人們：“測試是開發的第一步”這句話如何理解呢？如果從日本人發明的巴克質量管理的方式去理解，大概是指每一個環節交給下一級時都應該進行測試。有些測試對後面的操作沒有太大的影響，如圖片不漂亮，菜單不合理，布局很難看之類；而另一些，卻直接讓下一級無法開始工作，象用例不清晰；用例自相矛盾；組件內部錯誤；框架不合理等等。固然，一級級把關，可以把質量提高到至少一個檔次以上；但就每一個環節而言，仍然是在開發的最後階段。所以，看來本人的水平還是不到家，"測試是開發的第一步"難以理解，唯一可理解的就是規范先行，文檔先行，文檔規范化總應該是在編碼以前，這也是QA的主要內容；大概這還多少算解釋得通。這樣，測試和規范兩樣東西就重合起來了，從嚴格角度看，測試就是測試，規范歸入規范，還是從模塊（項目）後的測試開始理解吧；所以所有關於編程和文檔、設計規范的內容本人全部不納入測試討論范圍。或者說，我們重點放在QC上，而不是著眼於規范的QA，盡管那也非常重要。
單元測試(Unit test)：是針對模塊組件或方法的測試。在本人的操作中，一般是開發員工作范圍內的測試；在具備組件接口規范的情況下，一般需要做一個測試工具模擬調用環境，編寫測試實例，通過斷點情況監視模塊實際工作是否正常。一股采用這種方式開發的單一功能模塊質量都是非常高的。但是如果沒有統一的模塊規范，那麼開發與測試的工作量接近一比一；但如果模塊是按統一的標准開發的，那麼同一套測試套件就可以用到各個模件上，從而節省了測試時間。本人認為這屬於開發部門工作范圍內的測試，與QA/QC部門沒有什麼大的關系，事實上，在這一層次的用例也不是QC可以做到和理解的。
白箱測試：在理解內部流程的情況下針對邏輯流程設計測試實例，目的是找出極限邊緣以及內在的邏輯錯誤。單元測試中白箱測試的比例很高，（原因不難理解，還有誰比作者自已更理解模塊的構造流程的？）。
黑箱測試：這是QC部門的主要工作。黑箱測試主要在於編寫測試實例。不過在實際操作中，都是把最不懂技術的成員分配做測試，最高技術水平就是會用VSS，所以也就別指望編什麼測試實例。所謂的黑箱測試，常常是對著菜單按鈕，這個按下去，噢，有東西出來了，對的，打個勾——其實，這時侯的實例就是一個個按下去然後看看有沒有輸出，而且只限於界面方面，內在的部分和邊緣情況大概是不用指望的。但據作者所知，在CMM達到四以上的國外軟件公司中，黑箱測試是對軟件評價的最主要方式，通過合適的測試實例，除了最常見的可用性測試外，還包括壓力測試，和怪用測試（Monkey test)。
壓力測試：評價一個系統極限可以承受的壓力是多少，同時在超負荷後的的響應情況；同時，在極限狀況下，一些平時不太出現的bug也會浮現出來。所以，這個測試作者認為不應該單獨由QC部門進行，而應該由開發部門與QC部門聯合進行。理想的系統在極限測試狀況下就算響應不及，也不至於當機，並在負荷恢復正常後一段時間內可以恢復正常運轉。這時當初對windows惡評的原因之一：象網站一旦超出100-200個concurrent,windows不但罷工還死掉了；不得不重啟系統（當然，windows任意硬重啟都能死魚翻生，大多數情況下吧，也屬一種難能可貴的優點）；而linux在超出負荷後一般情況下下降曲線不至於太明顯——不過這也不是絕對的，作者就發現一旦linux在極限狀態下進入內存抖動時，死相和windows差不了多少；所以內存不至於耗干是 Linux可靠性能超過Windows的重要因素。
回歸測試；在修改其中一個模塊後看其他模塊有什麼問題。作者認為這個測試是過程化程序的觀念產物，在模塊化軟件中相互耦合程度低，而且服從統一的調動協議，是不是修改真是自家裡的事情，和他人（模塊）沒有半點相干。
整體測試：把不同的模塊連結後，看看聯合工作情況如何。這實際上是對接口協議的測試。作者認為是可以作為接口互動部分的設計一部分工作，沒有必要擺出來作為流程之一。同理還有系統測試，反正最後整個系統運行起來是什麼情況。看似大，但如果前面已經做到好好的，這裡如果出問題那才叫怪呢！
Alpha測試：放任內部成員胡作非為的測試；
Beta測試：讓全世界的壞人都胡作非為的測試。
過了這一關後，大概應該可以了吧？？在歐洲美國日本的規范的軟件公司大概是可以了。但在中國可不見得，許多時侯業務需求人員會蹦出來說：“不是這個樣子的！”早的時侯他不知上那裡去了！或者“加上另一個什麼功能吧？”，早的時侯他大概是睡覺了。大家伙兒前面做的事情，就沖這兩句話就全廢了,全部事情得從中間某個環節重來，這才叫惡夢。這時，與其順著他們老哥胡說八道跑，不如找出合同來一條條地仔細頒下去。
