1. 沒有合適的規范：
大家都是來自不通的公司，在編寫測試用例時可能會帶著以前的習慣，我們也沒有在現在的項目中找到明確且合適的規范，于是只是根據自己以前的經驗復制，但這些有時候并不適合我們目前的項目。比如在測試UUM時，個人自己就犯著以前不好的測試思維和習慣。
改進方法：
指定合理的規范，統一大家思維，有待討論。
2. 功能與業務分離：
這個是在測試ES-iVision存在的問題，在測試系統時可能只關注了功能而沒有整體業務的把握測試，只注重了某個功能表單上單一的測試，而整個業務可能才是我們測試的重點。
改進方法：
功能用例和業務用例分開組織編寫。A）功能用例依據需求界面描述，根據等價類、邊界值、錯誤推斷編寫，必要時建立數據庫，存放測試數據，而這些測試用例都與業務無關。并且可以利用資源找到相關的測試用例，來補充我們設計的不足。B）業務測試用例關注的是表單的執行路徑，執行后在系統上產生的一系列反應。這個可依據需求在開發前或與開發同時進行。但此業務功能必須是開發確認正確的。
PS:以前我們在業務這塊有場景測試用例。如發文流程中有多流程時，分場景測試流程。
3. 測試跟不上變化：
開發人員在開發時可能會對需求進行調整，這個問題是在測試UUM時系統管理角色需求就進行調整，所以我們被動的只能跑在開發的后面，我們也做了許多不必要的工作。
改進方法：
有問題及時與開發討論，走在開發前面調整我們測試用例，測試進度。
4. 發布前輪詢很多版本：
某一產品在經過幾輪測試后，在發布前可能會為一兩個bug要輪詢很多版本，在輪詢時測試人員不可能再把所有功能、業務全部再過一遍，但是我們此時會對發布版本沒有信心，而再走一遍浪費時間精力。
改進方法：
文章來源于領測軟件測試網 http://www.kjueaiud.com/