接到一個項目，一個大日常，跨很多應用，形成了標準的開發測試N：1，滿心歡喜覺得自己終于可以獨當一面了?？墒钱斈玫絅個UC的時候，就有種瞬間傻眼的感覺。
但是由于越覺得這個工程很龐大，越想早點開始啟動自己的工作，遂會好不容易找到一個突破口就急于開始寫用例。
剛冥思苦想出第一個文件夾的名字后，在這個模塊下，想到什么寫什么，想不出來的時候，又開始想第二個文件夾的名字，想下一個模塊要寫什么。當寫到第十幾個文件夾的時候突然想起第N個文件夾中好像少了一個用例，又每個文件夾，點開看里面的內容，回顧這個文件夾大致覆蓋了哪些用例，看看缺少的這個用例該怎么補。也許慶幸的是，找到了那個文件夾補充好這個用例，但是當你寫到第幾十個文件夾時，過了幾天以后，想到好像漏覆蓋了什么功能點，那可能不是就僅僅浪費幾分鐘去找這個文件夾，而是可能會花上大段的時間去回想自己寫了什么，這個時候的思路打斷就會讓你覺得不知道下一步該怎么走，思路越來越亂，下面的用例到底應該以什么緯度進行下去，還有多少的用例被遺漏掉了，什么用例是不需要寫，什么用例是需要覆蓋的，突然就會對用例有種不可控的感覺。
但是，如果一個測試人員對自己的用例都無法控制，那還有誰可以來了解用例的覆蓋度，用例的緯度。后面的回歸測試同學，如何來有序的進行回歸，用例的遷移該會是多么痛苦的一件事。
其實每個人的測試思路會不同，測試習慣也會不同，所以用例可能就會用不同的方式來寫。這些都固然沒錯，但是用例必須要有個緯度劃分，有個整體的一個流線。有利于測試，也有利于用例的review及評審，思維可以順著下來。
老人是一個很好的燈塔，他可以指引你怎么前進，有時候自己真的一點沒有頭緒的時候，可以看看以前的用例以怎樣的緯度劃分，找個較熟悉該應用的老大，問問如果是你，會怎么著手寫這些用例。千萬不要在自己沒有頭緒的時候就開始寫第一個用例，有可能會越寫越亂，寫到最后漏了一大片，冗余了一大片。先確定好用例大體以怎么樣的幾個大方向來寫，比如，按照應用來分，sell一塊，mickley一塊，forest一塊；按照測試順序，先后臺建類目，再前臺發布，等等。
確定一個方案還不夠的，這個只是個骨架，這些只是好讓你定好一級的文件夾名字。不要就開始寫用例了，要不然你定好了幾個文件夾名字后又會開始不知道怎么入手了，文件夾下要測試哪些東西呢？所以下面的測試設計很重要，列好幾個一級文件夾，對照UC看下一級文件夾是什么，一直設計到葉子文件夾要寫哪些功能點。最好可以進行測試設計評審，讓開發和老人一起評估下，有沒有測試用例覆蓋漏掉的點，這個時候修改方向，補充漏寫的點，很容易，一目了然。
雖然這可能會花去你一天的時間，你會覺得很可惜，但是這對后面的工作將會有很大的作用，對功能點已經比較熟悉，對用例編寫的思路也很清晰，只要對照設計一步一步往下寫就可以了，就不用說動不動就停下來絞盡腦汁在想要寫什么東西，尤其是對新人來說，對已有的用例也不熟悉，不知道到底應該寫哪些用例，需要測試哪些點，這個就尤為重要了。
300個用例并不可怕，但是不可控的100個用例就會讓人很昏頭轉向。定好方向，做好設計，建好層級，個個攻破，500個用例都將是可控的。