軟件測試工作中碰到的三個問題 軟件測試工具
1、測試數據÷運行數據的互不影響
在做測試時,通常都須要生成測試數據,在測試運行完后又要進行測試數據的刪除責任,當測試和運行用的是同一個庫的狀況下就很隨意涌現測試數據和運行數據相互影響的景象,這個時分在寫測試的時分就要特別的注重了,既不能讓運行數據影響了測試的后果,又不能讓測試數據影響到了運行數據。
通常來說,為了處理這個問題,會采取測試庫和運行庫離開的方法,采取這種方法的狀況下就對比簡樸了,不過有些時分還是挺費事的,終究要創立數據、刪除數據。
還有一種特別的狀況,例如一個這樣的名目:
名目已經上線運行了,這個時分做了一個新的流程,在擺布了新的流程到運行環境后,通常須要在運行環境中測試一下,這個時分問題就涌現了,測試數據和運行數據并行,這個時分就要缺乏的琢磨測試數據和運行數據的互不影響。
當然,上面的項主旨狀況是一個對比特別的狀況,就像有些冤家說的,名目計劃的好的話是會有測試環境和運行環境的不同的,測試環境須要和運行環境完整一致,在有新增的貨色須要擺布到運行環境時先在測試環境進行測試,測試沒問題后再通過晉級腳本擺布到運行環境中。
這些方法確鑿是能夠處理測試數據÷運行數據的相互影響的問題,不過認為還是有些的費事,認為假如有一個工具能夠資助防止測試數據÷運行數據的相互影響,同時又能夠讓你在寫測試的時分很隨意的創立測試數據,又不必擔憂其余測試數據或運行數據對它形成影響,最后測試數據又能夠平安的被消除,^_^,有個這樣的工具就好了。。。。。。。。。
或許說大家在實踐中遇到測試數據÷運行數據并行的狀況下會怎樣辦呢?……
2、單元測試
始終以來都實施TDD,不過發明我做單元測試的方法依然不準確,只管在測試的基礎準則——“測試肯定狀況下單元的履行能否和預期一致“上是準確的,但進行單元測試的方法并不準確,就像有的冤家所說,我做的是集成測試,由于我做單元測試時會去把該單元依靠的其余的對象所須要的貨色也去進行模仿,這樣說起來能夠過于生澀了,舉個例子吧:
有一個效勞類,該效勞類依靠一個Dao類,通過Dao從數據庫中獲取相干的信息落后行處理,我以前做單元測試的做法就是首先發生出測試數據,由Dao先將測試數據進行耐久,之后再通過調用效勞類的方法去履行,“肯定的狀況“通常都是由測試數據來掌握,這點沒什么不對,就是掌握所測試的單元的輸出。
測試的基礎準則都是檢討在肯定的輸出的狀況下輸出能否契合預期,作為單元測試而言上面的做法不準確的中央就是去發生測試數據并由Dao先耐久,其實作為單元測試而言,只須要測試以后對象履行的準確性,也就是說它已經假如了它所依靠的其余的對象發生的后果,這樣的單元測試才是有意義的,而且也變得更隨意寫了,之前我所采取的那種測試其實是集成測試……
這樣說了后其實就很隨意理解單元測試了,依然是上面的效勞類,它的單元測試的寫法應當是去Mock出Dao履行的后果,當然,這個時分就要模仿Dao在返回幾種狀況下效勞的履行狀況了,這個是正常的,就是去掌握效勞的輸出,這樣能夠看到,其真實單元測試中是不會涌現多少測試數據的狀況的,除了 Dao,而且也不必去關切其所依靠的對象的履行的準確與否,以及所依靠的對象是不是還依靠別的對象,能夠保障測試的規模就是本單元。^_^
原文轉自:http://www.anti-gravitydesign.com