由于web程序和(hé)一般的軟件開發不同，自動(dòng)化測試的效率和(hé)必要性一直較低，因此人工測試一直是web項目的最主要測試手段。

但這并不表示web項目就不需要進行自動(dòng)化測試。對于web項目而言，自動(dòng)化測試可(kě)以分為單元測試和(hé)功能測試。功能測試主要針對具體頁面進行測試，個(gè)人覺得意義不大，因為既然是針對具體頁面進行測試,采用人工測試的方式更為直接，高效，且靈活。因此以下(xià)主要針對單元測試進行讨論。

首先，由于web項目的特殊性，能夠進行單元測試的地方也不會很多。一般來說，單元測試會集中(zhōng)在業(yè)務邏輯層。

如(rú)果是很簡單的功能，那做單元測試的必要性就很低。一般來說，需要做單元測試的地方是：邏輯複雜的功能模塊。

代碼要能夠做單元測試，對程序的結構有一定的要求。首先，單元測試的模塊必須是個(gè)閉合的系統，有固定的輸入和(hé)輸出。因此在系統設計階段就應該進行充分的考慮：代碼的可(kě)測試性。

如(rú)何做到代碼的可(kě)測試性呢(ne)。主要有以下(xià)能力和(hé)技巧：

1 把（邏輯）複雜的問(wèn)題抽象為（數學）模型的能力，這也是最重要的一點。細節上如(rú)，将數據庫中(zhōng)的數據映射成程序中(zhōng)的數組，針對數組進行處理。

2 好的程序架構。即程序要模塊化。單元測試多是針對類或者函數進行。單元測試要求測試對象是個(gè)閉合的系統，如(rú)果你(nǐ)進行測試的程序塊和(hé)“外界”有着千絲萬縷的聯系，那你(nǐ)的程序必然是不可(kě)測試的。

3 因為web程序的特殊性，有時候，要做到完全閉合會很困難，或者說要花(huā)費很大的精力去改寫程序。那這時候，适當的用一些小技巧來實現可(kě)測試是必要的。因為測試的目的是為了保證産品質量，如(rú)果為了單元測試而延誤了工期，那就本末倒置了。具體實現上如(rú)，我們可(kě)以定義個(gè)環境常量，當這個(gè)環境常量等于測試模式的時候，就可(kě)以做一些特殊的處理。

ok，做到以上幾點，你(nǐ)的程序應該可(kě)以做單元測試了。進行單元測試的流程貫穿于整個(gè)項目的始終。可(kě)以參考如(rú)下(xià)：

A 開發人員在開發和(hé)測試過程中(zhōng)，要寫足夠的測試用例，測試用例應該包含各種有代表性的情況。在進入項目的測試階段的時候，這些測試用例就應該全部能運行通(tōng)過。

B 在A之後，程序多數還存在bug。這時候，如(rú)果發現新的bug（假定為bug1），那麼開發人員要根據産生bug1的情況，寫新的測試用例(bug1 test case).

然後修正bug1，并使測試用例bug1 test case運行通(tōng)過。同時請确保A中(zhōng)的所有測試用例也運行通(tōng)過。

C 再次發現新的bug（假定為bug2），然後開發人員重複類似于B中(zhōng)的流程。這個(gè)時候，請務必确保bug1 test case能運行通(tōng)過。這就是通(tōng)常我們提到的“回歸測試”，“回歸測試”能有效的避免在修正bug的過程中(zhōng)，産生新的bug。

最後，項目相關(guān)人員都應該意識到，人的大腦内存是有限的。如(rú)果你(nǐ)的項目含有複雜的邏輯，借助好的軟件工程方法，才能使程序得到有效的控制。引入單元測試，産品質量才有保證。