轉自 http://www.oktest.me/p/317.html
在我們的工作中，為了提高測試效率或者做出測試團隊的業績來，都不得不做很多的自動化，當然這包括測試環境搭建，測試數據構造，測試執行，壓力及安全測試等等，但是在各個階段中，應該怎么樣做好自動化滿足我們的業務發展需要呢？今天主要談談單元和集成測試。
自動化投入產出比
一個被簡化的公式:
自動化的收益 = 迭代次數 * 全手動執行成本 – 首次自動化成本 – 維護次數 * 維護成本
或者如果假設迭代次數和維護次數近視相等，這個在某些情況下可以成立，比如一個比較新的產品：
自動化的收益 = 迭代次數 * (全手動執行成本 – 維護成本) – 首次自動化成本
對此公式,我們可以解讀一下:
- 自動化的收益與迭代次數成正比;
- 自動化收益可能為負,即維護成本和首次自動化成本比全手工執行成本還高的時候;
- 很多時候首次自動化成本並不比手工測試成本高,但是維護成本很高.
實際上,這個公式的確被簡化了,原因是只是關注了其付出的時間,忽略了帶來的效果,比如給項目周期縮短上帶來的成效,對於質量保障的成效等等,對於項目周期上的評判則可以用以下公式:
縮短周期=手工測試時間-自動化測試時間
而且該周期都是針對同一個已經被自動化的模塊評估的.
此外,很多時候我們關注自動化對於質量的貢獻時,都是關注其發現了多少個bug,實際上自動化並不能幫我們發現更多的bug,都只是在原先預先設定好的程序上重復執行,所以根本不可能做到100%的自動化,測試人員的經驗，邏輯判斷和探索性的測試方法都不能被有效自動化.
什么樣的項目適合做自動化?
通過上面的公式也可以看出:
- 一個快速發展,變更頻繁的項目不適合做過多的自動化,而處於后期維護階段,自動化收益會更高;
- 對於接口類的產品;
- 手工測試非常費時費力,甚至無法達到測試目的的項目,比如對於大數據量大並發下的壓力測試等.
什么時候介入?
如果對於早期,開發設計還未穩定,界面還會經常變化,接口還未明確的情況下,是不適合做自動化的,即使做了,也會頻繁的修改,這個時候手工測試可能效率更高,能快速發現問題反饋給開發人員.而如果有了穩定的界面,明確的接口設計,明確的數據結構之后,自動化再介入可以自動化收益.
今天我們重點介紹一下單元測試,集成測試部分.
誰來寫單元測試
在一個軟件工程團隊里,的確沒有必要明確到底應該誰來寫,比較好的做法是依據團隊人員配置而定.單元測試普遍采用白盒測試的方法，離不開深入理解被測對象的代碼，同時還需要構造驅動模塊、樁函數，因此開展單元測試需要較好的開發知識。從人員的知識結構、對代碼的熟悉程度考慮，開發人員具有一定的優勢,其最大的優點是快速，且能更好的實現。
但是從單元測試效果的角度考慮，保證測試組參與單元測試也有其優勢，這是因為：
首先，從目前國內企業普遍現狀來看，測試人員質量意識要高於開發人員，測試人員參與單元測試能夠提高測試質量。
其次，對被測系統越了解，測試才有可能越深入，測試人員參與單元測試，將使得測試人員能夠從代碼級熟悉被測系統，這對測試組后期集成測試和系統測試活動非常有幫助，可以很快速的評估影響范圍,進而可以非常准確的制定回歸測試策略,而不用滿盤回歸.
測試組以何種方式參與單元測試，應該結合人員配置情況來定。如果軟件組織測試資源充分，測試人員對開發人員的比例較高，那么可以由測試人員獨立承擔部分重要模塊的單元測試工作,比如微軟這樣的公司,開發測試比1:1,那么測試人員就需要進行較為充分的單元測試;如果測試資源不足，測試人員對開發人員的比例較低，那么單元測試的實現和執行由開發人員來完成,但測試組至少應該參與開發組的各相關設計文檔評審，以及code review保證質量。
單元測試的現狀
可以把這種現狀結合業務情況來看分為兩種：
1）在業務快速發展迭代頻繁的團隊，追求高覆蓋的單元測試是一件奢侈而且不可取的事情，畢竟把單元測試做好的話可能需要寫比開發代碼還要多的測試代碼，這就需要持續的投入，包括人力和時間上，這也就是為什么微軟有那么多測試同學的原因，對於傳統軟件而言可能值得這樣的投入，也就是軟件測試工程中的正三角模型。
2）而互聯網時代，短平快是贏得市場的重要理念，為了獲得快速的迭代，大家都沒有過度的追求單元測試的覆蓋率，但是我了解到在百度一些產品線，迭代並不頻繁的項目，還是有強制要求對單元測試的覆蓋率的，不達到標准是需要打回給開發繼續完善單測的，但是我們大多數公司要么是開發一點都不做或者做的不夠好，我想這是目前的窘況，這也給我們測試工作量帶來了很大的壓力，經常會為了項目按期上線加班加點做回歸。同時，也有些公司在區分單元測試和集成測試策略和范圍時就比較模糊，本應該單元測試解決的放到集成測試了，甚至是單元測試就按照集成測試的思路來做的，包含了很多業務很細的case，那么就成立下面這種情況，而且更多的就是這樣的現狀:
單元和集成測試並行開展
單元測試更側重於邏輯代碼片段，粒度更細，可能不同的開發人員各自寫自己那部分的方法，自己做方法的單元測試，若需要調用別人代碼或被調用時，就自己寫樁或者驅動函數，把對應的內容mock掉。單元測試不應該關注上層側重業務的case，也就是說每個user story應該只有少量的case用來做集成測試，把更細粒度的case應該放到單元測試中去做，這樣可以避免單元測試和集成測試的重復性工作，為了達到這樣很好的組合，就需要開發與測試同學密切配合，提前設計好產品並有文檔化的設計資料。如果單元測試和集成測試能很好的區分並且履行好各自職責的話，這對於產品的質量一定能帶來非常積極的作用。
那問題來了：
1）這樣會不會延長項目周期呢？
在前期，框架不完善，大家對項目都不熟悉的情況下，要想做起來，必然會增加一定工期的，但是在各方面都比較成熟之后，特別是自動化case達到一定量之后，就會縮短項目工期。
2）如果單元測試開展的不夠好怎么辦？
我想，在目前大多數互聯網公司，甚少有把單元測試做的好的，並且迫於較低的測試開發比，測試人員根本沒有精力來做單元測試，那在這種情況下，測試人員要想進一步保證代碼質量的話，就只有通過設計評審，靜態代碼掃描和code reivew來保證方法的質量，而測試人員可以把精力放到集成測試或接口測試上,只不過這個時候集成測試就需要把更多更細的case包含進去。
面對現實，隨機應變
最后我們不得不無奈的面對現實，如果真的沒辦法實現正三角形模型的測試架構的話，也不用過於學術化非要按照模型來做，但我們也要竭力避免讓系統測試成為我們最大的工作量和包袱。應Google的一句話，大意是當軟件產品沒有bug的時候，說明它發布的晚了。這也指我們對於產品質量所做的一定妥協，為了業務快速往前，我們何不因此而變呢？