編寫背景：
       今天上我那塊測試論壇的菜地看看去了，想把一些東西給規整規整，對其中的一個帖子發表了好長的感慨，大家有空可看看。^_^。

                                      開發階段遇到需求變更，測試用例如何控制！！！

案例描述：
 開發階段的測試用例如何設計

常遇到這類問題,開發階段的策劃案經常修改,程序也經常調整,而一份詳細的測試用例要花費幾倍的測試時間,好不容易完成了,只要策劃案子一修改,以前做的就白費了,部門很多人也不贊成寫測試用例,認為對于一個老測試員來說,這根本是不必要的,是只工作時間的浪費,而且以目前的工作量來說,根本沒有時間寫,對于不穩定的異變的程序來說,意義也不大,在這種環境中,如何推廣測試用例呢?測試用例的存在有何意義?sdlkfj8

我的回復：
今天回頭看了一下這個帖子，發現有這么幾點問題：

1、首先帖子的標題是：開發階段的測試用例如何設計

   沒看帖子內容，一看這個題目就覺得很奇怪，測試用例的設計和開發階段有什么關系。具體看了帖子內容后才明白，原來是，測試用例設計好后，在開發階段時出現需求變更，導致測試用例要進行變化的現象。

   建議樓主把帖子標題改成：開發階段遇到需求變更，測試用例如何控制。這樣帖子標題和內容更一一對應上。

2、在帖子的內容中，描述了如下的幾個觀點和現象：

   1）開發階段的策劃案經常修改,程序也經常調整,而一份詳細的測試用例要花費幾倍的測試時間,好不容易完成了,只要策劃案子一修改,以前做的就白費了。

   2）部門很多人也不贊成寫測試用例,認為對于一個老測試員來說,這根本是不必要的,是只工作時間的浪費，而且以目前的工作量來說,根本沒有時間寫,對于不穩定的異變的程序來說,意義也不大

   3）在這種環境中,如何推廣測試用例呢?測試用例的存在有何意義?

   我的觀點如下：

   對于第1個，開發階段需求會有變化；我在猜想，如果你的測試用例是關于黑盒/灰盒的測試用于系統測試階段的話，在開發階段需求發生變更，從結果上就可以知道，這個需求前期做的有問題，要么是用戶不明白自己要做什么，不然就是需求人員沒有搞懂用戶到底要做什么；之所以讓用例修改，禍根就是需求的變化不是人家開發惹得禍；要弄清楚病根到底在哪里，才好下藥。應對辦法，測試前期參與需求理解、從測試的角度去把需求中不明確的地方弄清楚；在寫測試用例的時候、盡量簡潔明了可以節省時間，這就是寫作技巧的能力了。

   如果你的測試用例是關于白盒的測試用于單元測試階段的話，這真的很慘，有一種花費了很高成本做好的東西拿出去賣，沒人買，被耍的感覺。我沒遇到這樣的現象，目前不知道是怎么應對的。

   對于第2個，部門很多人不贊成寫測試用例，原因是：浪費時間沒有必要，其次是沒有時間寫，最后就成了意義不大。我在想，做測試的如果沒有時間寫測試用例、來一個產品就隨便點點、想怎么用就怎么用，這叫測試嗎？這不叫測試，這叫試用。我看不想寫用例的根本原因一個是：懶，說白了就是對這個工作忽悠過就得了；在就是自己感覺對這個東西挺熟悉的，有經驗，不寫用例也可以點出問題來，這說明程序寫的很爛、試用都能用出一堆問題。有責任心的人，當測試過的產品在用戶那邊出現一堆問題的時候，就會自我反省那個地方漏測了，沒有寫用例的人往往會漏的很多。把測試用例看的那么沒有意義、那么不重要，我在想你們部門應該是個產品試用部門吧，還算不上真正的測試。

   對于第3個，我覺的很好玩也很奇怪，基于上面的1和2點，把測試用例看得那么不重要、那么沒有意義，為什么還要推廣呢，你自己都不認為很重要的東西想讓旁邊的人認為重要，很難、非常的困難。想要把一個好的東西介紹給人使用，首先自己要覺得它很有價值，然后要讓大家看到實實在在的價值和幫助、還有好處，這樣才會得到認同。不過我覺得你那的環境比較困難，從你上面的描述得出，非常的困難、不是一般的困難、是相當的困難。

   嘿嘿，寫了那么多，不知道能否對你有啟發，祝你好運了。^_^。

  最后回到正題，開發階段遇到需求變更，測試用例如何控制? 問題已經出現了，需求已經變了，該怎么辦？那只能修改測試用例咯，然后告訴具體負責人，需求變更已經影響到了測試的進度和工作，做好這方面的時間工期應對風險。

帖子地址：

http://bbs.testage.net/viewthread.php?tid=37275&pid=172303&page=1&extra=page%3D1