**
在我們的工作中，為了提高測試效率或者做出測試團隊的業績來，都不得不做很多的自動化，當然這包括測試環境搭建，測試資料構造，測試執行，壓力及安全測試等等，但是在各個階段中，應該怎麼樣做好自動化滿足我們的業務發展需要呢？今天主要談談單元和整合測試。
自動化投入產出比
乙個被簡化的公式:
自動化的收益 = 迭代次數 * 全手動執行成本 – 首次自動化成本 – 維護次數 * 維護成本
或者如果假設迭代次數和維護次數近視相等，這個在某些情況下可以成立，比如乙個比較新的產品：
自動化的收益 = 迭代次數 * (全手動執行成本 – 維護成本) – 首次自動化成本
對此公式,我們可以解讀一下:
實際上,這個公式的確被簡化了,原因是只是關注了其付出的時間,忽略了帶來的效果,比如給專案週期縮短上帶來的成效,對於質量保障的成效等等,對於專案週期上的評判則可以用以下公式:
縮短週期=手工測試時間-自動化測試時間
而且該週期都是針對同乙個已經被自動化的模組評估的.
此外,很多時候我們關注自動化對於質量的貢獻時,都是關注其發現了多少個bug,實際上自動化並不能幫我們發現更多的bug,都只是在原先預先設定好的程式上重複執行,所以根本不可能做到100%的自動化,測試人員的經驗，邏輯判斷和探索性的測試方法都不能被有效自動化.
什麼樣的專案適合做自動化?
通過上面的公式也可以看出:
什麼時候介入?
如果對於早期,開發設計還未穩定,介面還會經常變化,介面還未明確的情況下,是不適合做自動化的,即使做了,也會頻繁的修改,這個時候手工測試可能效率更高,能快速發現問題反饋給開發人員.而如果有了穩定的介面,明確的介面設計,明確的資料結構之後,自動化再介入可以自動化收益.
今天我們重點介紹一下單元測試,整合測試部分.
誰來寫單元測試
在乙個軟體工程團隊裡,的確沒有必要明確到底應該誰來寫,比較好的做法是依據團隊人員配置而定.單元測試普遍採用白盒測試的方法，離不開深入理解被測物件的**，同時還需要構造驅動模組、樁函式，因此開展單元測試需要較好的開發知識。從人員的知識結構、對**的熟悉程度考慮，開發人員具有一定的優勢,其最大的優點是快速，且能更好的實現。
但是從單元測試效果的角度考慮，保證測試組參與單元測試也有其優勢，這是因為：
首先，從目前國內企業普遍現狀來看，測試人員質量意識要高於開發人員，測試人員參與單元測試能夠提高測試質量。
其次，對被測系統越了解，測試才有可能越深入，測試人員參與單元測試，將使得測試人員能夠從**級熟悉被測系統，這對測試組後期整合測試和系統測試活動非常有幫助，可以很快速的評估影響範圍,進而可以非常準確的制定回歸測試策略,而不用滿盤回歸.
測試組以何種方式參與單元測試，應該結合人員配置情況來定。如果軟體組織測試資源充分，測試人員對開發人員的比例較高，那麼可以由測試人員獨立承擔部分重要模組的單元測試工作,比如微軟這樣的公司,開發測試比1:1,那麼測試人員就需要進行較為充分的單元測試;如果測試資源不足，測試人員對開發人員的比例較低，那麼單元測試的實現和執行由開發人員來完成,但測試組至少應該參與開發組的各相關設計文件評審，以及code review保證質量。
單元測試的現狀
可以把這種現狀結合業務情況來看分為兩種：
1）在業務快速發展迭代頻繁的團隊，追求高覆蓋的單元測試是一件奢侈而且不可取的事情，畢竟把單元測試做好的話可能需要寫比開發**還要多的測試**，這就需要持續的投入，包括人力和時間上，這也就是為什麼微軟有那麼多測試同學的原因，對於傳統軟體而言可能值得這樣的投入，也就是軟體測試工程中的正三角模型。
單元和整合測試並行開展
單元測試更側重於邏輯**片段，粒度更細，可能不同的開發人員各自寫自己那部分的方法，自己做方法的單元測試，若需要呼叫別人**或被呼叫時，就自己寫樁或者驅動函式，把對應的內容mock掉。單元測試不應該關注上層側重業務的case，也就是說每個user story應該只有少量的case用來做整合測試，把更細粒度的case應該放到單元測試中去做，這樣可以避免單元測試和整合測試的重複性工作，為了達到這樣很好的組合，就需要開發與測試同學密切配合，提前設計好產品並有文件化的設計資料。如果單元測試和整合測試能很好的區分並且履行好各自職責的話，這對於產品的質量一定能帶來非常積極的作用。
那問題來了：
1）這樣會不會延長專案週期呢？
在前期，框架不完善，大家對專案都不熟悉的情況下，要想做起來，必然會增加一定工期的，但是在各方面都比較成熟之後，特別是自動化case達到一定量之後，就會縮短專案工期。
2）如果單元測試開展的不夠好怎麼辦？
我想，在目前大多數網際網路公司，甚少有把單元測試做的好的，並且迫於較低的測試開發比，測試人員根本沒有精力來做單元測試，那在這種情況下，測試人員要想進一步保證**質量的話，就只有通過設計評審，靜態**掃瞄和code reivew來保證方法的質量，而測試人員可以把精力放到整合測試或介面測試上,只不過這個時候整合測試就需要把更多更細的case包含進去。
面對現實，隨機應變
最後我們不得不無奈的面對現實，如果真的沒辦法實現正三角形模型的測試架構的話，也不用過於學術化非要按照模型來做，但我們也要竭力避免讓系統測試成為我們最大的工作量和包袱。應google的一句話，大意是當軟體產品沒有bug的時候，說明它發布的晚了。這也指我們對於產品質量所做的一定妥協，為了業務快速往前，我們何不因此而變呢？
自動化測試，自動化測試框架，持續整合
基於espresso和dagger的自動化測試框架 測試框架可以使用android推薦的espresso.模擬資料可以使用dagger2,一種依賴注入框架.dagger2沒有使用反射,而是使用預生成 提高執行速度.基於espresso和dagger的自動化測試框架 持續整合與自動化測試，自動化測試框...
自動化測試之六 自動化測試模型
from selenium import webdriver chrome driver path r c users administrator envs selenuimautotest lib site packages selenium webdriver chrome chromedriv...
《自動化測試》之
不知道之前的selenium api 用法1，有沒有去練習，個人認為線性 還是要靠敲的，後面的模組化除了多敲還需要一定的程式設計思想去理解，今天下午不是很忙就給來這兒補充點selenium api 的例子，之所以選擇例項是因為直觀，容易理解，而不是理論去解釋具體的關鍵字用法。題外話，最近越發覺得ui...