中關于測試用例改進問題

目前我們設計的測試用例只是表面上的呈現，對測試指導的作用不是很大，我們思想里也認為測試用例編寫只是在熟悉系統的過程，在測試時測試用例會被我們撇在一邊。個人總結一下原因和改進方法：

　　1.  沒有合適的規范：

　　大家都是來自不通的公司，在編寫測試用例時可能會帶著以前的習慣，我們也沒有在現在的項目中找到明確且合適的規范，于是只是根據自己以前的經驗復制，但這些有時候并不適合我們目前的項目。比如在測試UUM時，個人自己就犯著以前不好的測試思維和習慣。

　　改進方法：

　　指定合理的規范，統一大家思維，有待討論。

　　2.  功能與業務分離：

　　這個是在測試ES-iVision存在的問題，在測試系統時可能只關注了功能而沒有整體業務的把握測試，只注重了某個功能表單上單一的測試，而整個業務可能才是我們測試的重點。

　　改進方法：

　　功能用例和業務用例分開組織編寫。A）功能用例依據需求界面描述，根據等價類、邊界值、錯誤推斷編寫，必要時建立數據庫，存放測試數據，而這些測試用例都與業務無關。并且可以利用資源找到相關的測試用例，來補充我們設計的不足。B）業務測試用例關注的是表單的執行路徑，執行后在系統上產生的一系列反應。這個可依據需求在開發前或與開發同時進行。但此業務功能必須是開發確認正確的。

　　PS:以前我們在業務這塊有場景測試用例。如發文流程中有多流程時，分場景測試流程。

　　3.  測試跟不上變化：

　　開發人員在開發時可能會對需求進行調整，這個問題是在測試UUM時系統管理角色需求就進行調整，所以我們被動的只能跑在開發的后面，我們也做了許多不必要的工作。

　　改進方法：

　　有問題及時與開發討論，走在開發前面調整我們測試用例，測試進度。

　　4.  發布前輪詢很多版本：

　　某一產品在經過幾輪測試后，在發布前可能會為一兩個bug要輪詢很多版本，在輪詢時測試人員不可能再把所有功能、業務全部再過一遍，但是我們此時會對發布版本沒有信心，而再走一遍浪費時間精力。

　　改進方法：

　　用用例標明測試優先級。這個是在oa1.9中用到的，但可能在后期執行時沒有執行。所有在編寫測試用時標示優先級，把系統的重點劃分出來，在發布前多次輪詢版本中只要檢查優先級高的就可。

　　5.  用例審核力度不夠：

　　編寫的測試用例無人評審，這也是我們在編寫測試用例的隨意性、懶惰性滋生，草草了事，沒有覆蓋全部功能點、業務點。導致產品在發布后存在意想不到的缺陷。

　　改進方法：

　　測試用例編寫完成后增強評審，先是小組里討論，然后再外部評審。

　　6.  易忽略問題：

　　在執行設計測試用例執行測試，我們可能會忽略很多問題，如系統有安裝包的安裝測試、界面上一些細節什么的。

　　改進方法：

　　在網絡上查找相關文檔

原文轉自：http://www.kjueaiud.com