在一般的軟件公司中，設計測試用例和編寫測試用例一直是測試人員一個非常重要的基本工作。
但是，很多軟件測試從業者或者說其他人總是會覺得，測試用例是沒有什麼必要編寫的。
軟件的研發流程是這樣的：
產品人員確定用戶需求->產品人員、開發人員、測試人員、UE人員等進行評審->開發人員進行設計與開發（測試設計並編寫用例->開發人員提交->測試人員按照需求和用例執行測試->上線發佈。
我認爲，測試用例是必須要編寫的。但是很多軟件測試從業人員認爲測試用例的編寫是無用功，因爲最後執行測試時經常和測試用例有很大的出入。其實造成這種現象的原因，我覺得主要的就是在需求評審階段沒有做好，開發、產品、UE對需求的理解不一樣，導致了後續需求的變動，甚至還有可能需求本身就不是很完善，因此在開發的過程中還在不斷地變更需求。
但其實這些原因，我們都可以把它們控制在可接受的範圍之內，當然，這主要是需求評審階段的內容。就個人而言，即使需求評審的流程非常完善，幾乎不會再有需求的變動了。在編寫測試用例時，爲了使用例有更高的覆蓋率，還是經常會發現需求的一些遺漏，及時溝通，提高效率。由此可見，編寫用例的過程更有助於測試人員理解需求。
測試用例就像是劇本或者是指揮棒，所以，編寫測試用例是必要的。但是在很多的互聯網公司，基本都走敏捷開發，產品迭代非常頻繁，這樣，測試人員執行測試的時間就非常短，更不用說編寫測試用例的時間，此時我們可以將測試用例簡化測試點。但是建議遇到比較複雜的流程時，還是能儘可能用測試用例來詳細描述。
其實也可以在編寫測試用例之前和準備執行測試時，找開發人員聊聊是如何實現這個功能的。這樣會很容易把握到測試的注意點，並可以體現在用例中。比如說，開發人員A曾經用某種方式做了某功能，出現了bug，現在開發人員B用了同樣方式實現了類似的功能，那麼之前的bug很有可能還會再次出現。
用例評審也是一個非常重要的階段，特別是一些很有經驗的軟件測試“老司機”，可以很快幫忙指出用例的遺漏點，有助於打開思路，儘可能多的覆蓋用戶場景。
值得注意的是用例評審的時候遇到不確定的情況，應立即記錄下來，結束後及時找相關人員確認，及時處理。