- 掛牌上市企業
- 60秒人工響應
- 99.99%連通率
- 7*24h人工
- 故障100倍補償
怎么樣的測試用例才算是好的用例 |
| 發布時間: 2012/9/15 18:08:58 |
|
雖然我是一名測試新人，但是我自認為自己是一個很有想法的人，覺得測試用例對我來說應該不是什么問題，誰知道今天發生了一件事，讓我不得不重新審驗一下自己的想法，以及最重要的一點是，我要搞清楚怎么樣的用例才算是好的用例。 話說事情是這樣的，這次客戶有一些新的需求，比如說原來的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,他認為這不是問題，還是原來的話，只要每個功能點涉及到了就行了，不需要過于詳細，他認為我寫的用例過于詳細了，測試點過多。 談話談到這里，我已經徹底無法接受了，我認為的用例的編寫方法跟我們頭頭完全不一樣，我無法接受他的想法，更無法否認自己的做法，心底下我覺得我的用例并沒有問題，而且做得很對，但是我們頭頭要求我按照他的想法去修改我的用例，于是我很糾結~~~ 本文出自：億恩科技【www.zuiquanben.com】 |
0371-60135900
京公網安備41019702002023號
香港服務器租用
美國服務器租用
電信骨干機房
聯通骨干機房
