測試用例無疑在測試過程中起著舉足輕重的作用，好的測試用例讓測試人員在測試執行過程中心情愉悅，測試效率高，能發現更多的問題。
好的測試用例一般有如下幾個特點：清晰、簡潔、完整、適用性、針對性以及以維護性�？偨Y了我們公司的測試用例狀況，存在以下一些問題：
1．全case測試用例太過詳細、冗余，測試起來費時費神，而且發現不了什么問題，測試用例在清晰簡潔性方面存在問題，這還體現在交叉測試上，沖突事件太多，實際上很多都是等價的沖突，有限的時間，沒必要逐一確認；
2．同項目多個平臺升級（客戶升級）版本重復使用相同的測試用例，用例的針對性不強；
3．多國語言版本沒有針對性的測試用例（目前版本基本使用基本功能case或者客戶版本case，針對性不強），測試用例的完整性存在問題，這還體現在其他一些新的功能模塊，沒有相應的測試用例；
4．有的case看上去很美，寫的也十分詳細、面面俱到，但測試上卻發現不了什么問題，針對性方面存在問題；
5．受以上一些因素的影響，很多測試人員不愿意跑case，如果憑借經驗讓他們來測試，相同的時間他們能夠發現更多的問題，而跑case卻發現不了什么問題，也沒什么成就感——測試用例在適用性方面也存在問題；
6．測試用例更新不夠及時，目前主要是采用Excel表格形式來編寫測試用例，有時候測試用例的設計人員做了改動，則其他測試人員一般難以及時了解——測試用例在可維護性方面存在一定的問題！
綜合以上，我們的測試用例在清晰、簡潔、完整、實用性、針對性及可維護性等方面均在需要我們改經的空間。
在做改進之前先得再介紹下項目平臺特點，我們這邊的開發平臺都是MTK的老平臺，平臺相對比較穩定，之所以MTK能夠成就那么多黑手機，一個主要原因還不是平臺比較成熟、穩定，開發簡單，風險較低，呵呵。
比較穩定的平臺，每個功能模塊本身的問題并不多，我們所作的主要就是一個集成、系統測試，所以類似針對類似單元測試用的太過詳細的用例在這里就不適用了。
另一個原因就是我們的測試人員，大多數都具有1年以上手機測試經驗，當你把某個功能點告訴他的時候，要測試哪些內容，要注意哪些細節，他們都十分清楚，根本就不用羅里羅嗦那么多去描述。
改進措施：
鑒于以上原因，我們的軟件測試用例在優化調整工作主要從以下幾方面開展：
1．為了讓測試用例看起來更清晰、簡潔，同時給測試人員一定的彈性空間，在內容上有些項可以寫成checklist形式的；把太過詳細、冗余的測試用例去簡化，該刪除的刪除，該保留的保留，幾個詳細操作步驟能用一句話概括表達的就用一句話概括表達，在測試用例的檢查點方面，盡量只寫一兩個最主要的檢查點，其他很多無關緊要的檢查點全部刪掉（測試人員在測試過程中自然都會關注到）；
2．把過時的以及錯誤優化更正，新增加的功能點，在測試用例上及時覆蓋到，畢竟測試用例也是要與時俱進嘛；
3．同一個功能模塊的測試用例，把同一張表格中的功能性、交叉、性能效果幾方面的測試用例從不同角度進行分拆成不同在不同的表格中；
做到以上兩點，我們的測試用例基本上也就達到了清晰、簡潔、適用性以及針對性幾方面的要求了。至于可維護性，說實話，目前感覺用Excel表格的形式來做測維護及測試方面而言還是挺不錯的，Excel表格刪除、增加等都比較方面，測試時使用也比較方面，唯一的問題就是更新后，難以及時的體現出來。但似乎也沒有其他更好的測試管理工具，比如TD、TestLink也存在一定的缺陷。所以這塊，目前還是維持現狀了。
4．為了更快的檢查出軟件存在的一些主要問題，我們再增加一套checklist，以便不同階段使用。我覺得checklist還是非常重要的！
文章來源于領測軟件測試網 http://www.kjueaiud.com/
