雖然我是一名測試新人，但是我自認爲自己是一個很有想法的人，覺得測試用例對我來說應該不是什麼問題，誰知道今天發生了一件事，讓我不得不重新審驗一下自己的想法，以及最重要的一點是，我要搞清楚怎麼樣的用例纔算是好的用例。
話說事情是這樣的，這次客戶有一些新的需求，比如說原來的merchant ID改成merchant code, TID改成終端serial_no, 在屏幕上增加VAT的輸出（以前只有base amount的輸出），當前時間增加秒級（之前只有日期，小時，分），金額中增加貨幣，如以前是1000，現在變成1000元等。
按我的想法是新需求就增加新的用例，用例中重點體現這些新加入或修改的內容是否正確，而按我們頭頭的想法卻是在舊的用例中修改，加入這些新的內容。
先說說爲什麼我覺得是增加新的用例，而不是在舊內容中更改，理由一，每次測試都應該有一個測試重點，不能每次都把所有的用例全都跑一遍，這樣測試人員會很累，像這次新增加或是修改的內容應該作爲新的一次測試重點，測試過程中只需要測這些新增或修改的內容，以及新增或修改部分可能會影響到的功能，不相關的用例可以不跑，因此用例應該體現出測試重點來。然而我們頭頭的意思是在原來的用例上修改，而且用例寫完了還得全部再跑一次所有的用例，因此我覺得很悲劇。目前我們的用例沒有任何層次性，一個項目對應一整套用例，如果有新需求就在原來的基礎上進行修改，按頭頭的意思是如果不對原來的用例進行修改，那麼會導致後面的測試無法按照用例來跑，因爲用例是舊的。
好吧，我承認我無法反駁這一點，舊的用例無法跑，或是新入職的測試人員想通過測試用例瞭解測試過程時可能會令他們感覺很迷茫，這些用例都不對嘛！可是我也無法說服自己每次增加一些新需求就得重新修改用例，純粹的copy->粘貼，沒有什麼技術含量，感覺好浪費時間，而且最重要的是下一次測試得全部測過一遍會讓我提不起幹活的勁頭，如果有一個很直接的目標，那麼很容易讓我有那種“OK，就是它了”的感覺，然後很有幹勁地直奔過去處理，但是假如有N多個目標，那麼這樣只會讓我覺得提不起勁，感覺沒有了目標，因此最後的結果還是重點測一下新增或修改部分，對於其他大多敷衍了事。
理由二，在原有的用例上修改的話意味着我得從頭覈對一次用例，看哪些需要修改就進行修改，這樣我的工作量便增大了，這讓我這種以追求效率爲目標的人很難受，換另一句話來說就是覺得浪費時間，按頭頭的想法是預算中給了你一週的時間，工作量不成問題，好吧，這點，我也沒法反駁，確實，時間是足夠的，但是問題在於我們不能因爲預算時間足夠就可以隨便浪費時間，如果有多餘的空閒時間我可以學習其他方面豈不是更好，不過這句話我可不敢跟頭頭說，人家請你來是幹活的，可不是學習的。
理由三，在寫舊的用例時，輸出數據不是所有的數據都列出來的，而是隻挑我認爲的重要的項才列出來，其他數據略過，當初覺得merchant ID, TID不重要，根本就沒列出來，而且當前時間也不列出來的，現在必須加入這些，那麼如果在舊用例上修改的話，意味着每個相關的用例都得加上這些，又是一個copy->粘貼的過程，如果是增加新用例，我可以在一個用例中把這些信息包括進去，這樣就省事多了，總的來說，還是時間問題。按我的意思是這些東西並不是那麼重要的，寫一個用例來查看就可以了，沒必要在每個相關用例上都增加進去，就算是以後新入職的人員寫用例也是將其作爲不重點信息，因此用例上沒有這些信息倒也不相干，既然如此，我增加一個用例來測試這些新增加/修改的內容就OK了，但是按頭頭的意思，寫用例時不需要把所有的項都列出來，挑重點項列出來沒問題，但是既然客戶提需求了，就必須把提到的都列出來了，而且他認爲這些新增加/修改的內容不能作爲一個測試點來看待，因此不能獨立成爲一個用例。
我問頭頭爲啥不能作爲一個測試點，這次的測試我在測試過程中肯定要查看這些內容是否正確的呀。而頭頭的回答是，只有與具體某個功能相聯繫才能作爲一個測試點，不能說你的測試點就是查看一下屏幕是否顯示正確，這不是一個測試點，只是一個測試點中的一個環節，聽到這裏我就開始迷茫了，這跟我認爲的測試用例完全不是同一回事了。
在我看來，用例是指導測試用的，那麼用例就應該體現我的測試過程，測試思想什麼的，比如說我測試的時候是這樣的，比如測試一個報表吧，有多個查詢條件，那麼第一步我會先查看一下這些查詢條件的顯示是否正確，比如說有彈出框選擇，那麼選擇完後在輸入框中顯示的內容是否跟我的選擇一致，這是一個測試點，然後再是點擊查詢按鈕查詢出來的結果是不是按照我的查詢條件得出的結果，這又是一個測試點，這裏就包含了兩個測試點，也就是說至少需要兩個用例。然後按照頭頭的想法是報表的功能是查詢功能，那麼只能是以某個查詢功能來寫用例，像我所說的第一個用例完全沒必要寫，第一個用例只是整個查詢過程的一個步驟，而不能作爲一個測試點。
正是因爲我跟頭頭理解的用例完全不一樣，於是我們的談話進而提升到討論什麼樣的用例是一個好的用例。
我剛做測試的時候，我的確是不懂怎麼寫用例，於是都是按照一個功能一個功能地去寫用例，就是我們頭頭說的那種，但是在測試過程中我就發現了一些現象，雖然每個功能都涉及到了，但是，1.有很多bug沒法找到相對應的用例，2.有時候一個用例對應N多個bug，3.有時候N多個用例對應一個bug，即一個步驟錯了，那麼所有包含該步驟的用例都fail了。4.有些用例寫得過於籠統，無法指導測試過程，也無法體現你的測試思路。於是針對各個問題，我的應付是，對於1，找不到bug的時候我就想一下這個bug是怎麼發現的，爲啥用例沒有，大部分時候是因爲缺少具體的測試點造成的，於是我就給這些bug新增測試點，對於2-4，總結了一下，大多也是因爲測試點的問題，於是我把用例改了，每個用例對應一個具體的測試點，針對有些很容易出現問題的地方，增加多一些測試點，這樣子把用例修改下來後，我發現無論是測試過程還是測試結果的執行都省事了，因爲測試標題寫的就是測試點，這樣我在測試過程中不需要看用例的具體步驟，我就知道該怎麼測了，就按照測試點跑一遍就OK，當然了，這需要你對系統熟悉了之後做的，如果不熟悉，還得看看步驟怎麼操作的。在執行測試結果的時候也很省事，我只要對應一下哪個測試點出了問題，就給它一個fail，沒問題的就給它pass。如果像之前的用例那樣，如果是某個步驟錯了，凡是含有該步驟的用例我都得給它一個fail，因此在執行的時候還得一個一個去看，好煩人地說。
結果我跟我們頭頭這麼一說，這下子就出問題了，他覺得我做事的方法不對，做事不是這麼做的，用例也不是這麼寫的，然後說了很多理由云云。
我問他說“一個好的用例不是應該是一個能發現bug的用例麼？”在我看來，“不管白用例黑用例，能測出bug的用例就是好用例”，他說是，但是不能爲了發現bug而修改用例，因爲寫用例之前是不知道哪裏會出現bug的，所以只能根據功能點來寫，把每個功能點涉及了就行了，你發現了bug之後再來修改用例，是因爲你知道這麼做會出現這個bug，但是這個過程就不對之類的云云。
針對上面測試過程中出現的4點問題，對於1，他覺得既然是因爲問題出現在有些缺少的項中，那麼就去修改用例，加上出現的bug的項就OK，沒必要增加新的測試點；對於2-4，他認爲這不是問題，還是原來的話，只要每個功能點涉及到了就行了，不需要過於詳細，他認爲我寫的用例過於詳細了，測試點過多。
談話談到這裏，我已經徹底無法接受了，我認爲的用例的編寫方法跟我們頭頭完全不一樣，我無法接受他的想法，更無法否認自己的做法，心底下我覺得我的用例並沒有問題，而且做得很對，但是我們頭頭要求我按照他的想法去修改我的用例，於是我很糾結～～～