縱觀海外軟件測試行業，從2001年起頭，測試人員及測試主管經常研究測試用例的編寫方法。以為編寫了測試用例就可以做好測試責任。其實不然。測試用例只是用來抵達測試掩飾和進行測試閱歷積累的一種手段。
我們部門從2002年起頭起頭測試用例的編寫責任，但直至2004年，測試用例對實際的測試責任并沒有帶來明顯的效果，反而造成責任量上的增加和資源糟踐。由于，一直以來，已經編寫好的測試用例并沒有細心地執行和掩護。這不是測試用例本身的問題，而是測試管理者的失誤!
為什么我們一直以來都對測試用例表現出不好的態度呢?
分析原因，有四：
1。首先是資源投入的問題。測試團隊的人數不夠，將直接引發責任量問題。而測試用例又是一件要求非常細致的責任。
2。開發測試用例所需要的技術知識。測試用例的設計離不開技術(只管在有些狀態下可以不需要)，但以后的測試團隊并沒有好的技術基礎(如編程閱歷，設計閱歷等)。另外，與開發組和產品需求規劃組的替換也不順暢。導致測試用例的設計很片面，且太過于主觀(純粹靠設計人員的閱歷)。
3。對測試用例的理解過于軟弱。為什么這么說呢?由于QC是一件非常復雜的責任，事情多且雜亂(特別是在開發流程不規范的組織中)，測試主管們很隨便掉進“為了設計而設計”的陷井。測試用例的編寫過程和質量，并不是“測試用例責任”的全部，測試用例的執行、掩護才是這項責任的重點。
4。測試主管們對測試用例的期望值過高。測試用例編寫出來了，也執行了。但它究竟是一份文檔，是死的，我們需要活用它。也就是說，測試用例還需要一個相配套的應用策略。比喻，對某個軟件版本的的測試，根據實際的項目狀態(如測試時限，人員及其水平，主旨軟件的品質等)對測試用例庫進行篩選和打包，這樣才能較好地實現測試用例的效果。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
