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