自動化單元測試要點 軟件測試
用單元測試的框架MSTEST，做單元測試，集成測試快1年了，總結一下工作中學到都東西。
單元測試，集成測試有什么用?
1. 改進產品質量
軟件測試，很多時候圍繞著兩個問題：
Verification和Validation，常說的雙V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software?
單元測試，更多的是Verification。所以有時候經過我單元測試和集成測試以后的功能模塊，在交給其他同事做功能測試的時候，依然會有一些 BUG，這時候開發可能會埋怨我測試得不夠完全，諸如此類。但是其實很多時候，我的關注點是單個方法的功能、行為，沒有站到更高的位置來測試這個模塊。對于這樣的問題，開發和測試應該互相體諒，我本人也會提高自身的水平。希望在單元測試和集成測試中也加入更多關于Validation的思考。
有一個提法叫Tests as Specification，單元測試本身其實就是模擬某個模塊的使用者(其他的程序)來進行測試。很多時候我寫的測試代碼也是其他開發人員的參考，尤其在一些事實上或者只是號稱自己是敏捷開發的組織里面，測試代碼有可能成為詳細設計的替代品，因為有可能根本沒有詳細設計文檔。
單元測試的另一個工作就是發現并且定位BUG。對于BUG的定位和重現，在單元測試代碼的編寫過程中，每個Assert語句后面都要加上盡可能詳細的信息，例如導致這個Assert語句失敗的每個參數值，期望結果，實際結果等，這些信息可以幫助開發和測試快速定位問題，減少不必要的DEBUG時間。
2. 降低項目的風險
軟件測試，其實是用有限來驗證無限的一個過程，很多時候做什么樣的測試，做到什么樣的程度，很多時候都跟風險有關系。
作為產品的安全網，各種測試在項目中都扮演著重要的角色。例如，中美交互的幾十個Web Service接口的回歸測試，現在有若干個測試，每天定時做回歸測試，因為沒人知道在美國的服務器會發生什么事情;對于中國的Web Service，在上線前都會通過回歸測試，才部署上線。還有全站的Platform Service接口，每次上線前都需要在做回歸測試。軟件測試的另一個有趣的結論就是：測試只能證明軟件有BUG，但是無論什么樣的測試，都不能證明被測軟件是沒有BUG的。問題出來了，我做完回歸測試，都通過了，但是我卻不能證明這個軟件是沒有BUG的。其實每次上線，團隊都承擔著風險，只不過這樣的風險在完成回歸測試之后，大家上線的信心增加，風險明顯地減小。
什么樣的測試才是好的測試?
1. 容易運行
什么樣的單元測試是容易運行?答案很簡單，自動化的單元測試就是容易運行的測試。如果一批測試在運行之前每次都需要重裝系統然后還要找一大堆需要依賴的軟件來裝上，最后還要輸入奇怪的命令才能運行，那么就不是一個好的測試(本人真的見過這樣的測試，囧)。個人認為，配置好的持續集成系統，可以實現很好的自動化測試;如果沒有一個完善的CI，那么一個one click的自動化測試運行也是一個較好的選擇。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
