【正文】 可以了。因為測試用例寫的太詳細，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。第二個問題，剛開始做測試的時候，你是怎么學習寫測試用例的？我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術支持，產(chǎn)品的問題很多，導致技術支持工作很辛苦、很累。為了讓用戶買到的產(chǎn)品的質(zhì)量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認為不就是拿個鼠標點來點去，誰都可以來做。為此，我經(jīng)常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學習寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。沒有辦法，那時候沒有人指導我，全靠自己自學和領悟，所以那段日子很苦阿！多寫幾次后，就知道和領悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導怎么去執(zhí)行測試。還好，我有編程的經(jīng)驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務才能去寫測試用例，才能更好的去測試。這也是我一點一點的領悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。最后一個問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？我的體會：１、測試用例要根據(jù)測試大綱來編寫２、測試用例也要分測試項進行歸類，這樣比較好分析和閱讀。如：業(yè)務流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。３、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務流程和風險高的地方。能分出測試優(yōu)先級別就最好了。４、熟悉系統(tǒng)，對編寫測試用例很有幫助。５、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。第五篇：編輯測試用例方法感言編輯測試用例方法感言編輯測試用例方法感言、一個測試用例要寫到什么程度才比較好?、剛開始做測試的時候，你是怎么學習寫測試用例的？、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？一個測試用例要寫到什么程度才比較好？這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來比較長阿，大家要有常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短到個月，然而測試通常都是在開發(fā)即將結(jié)束的時候才真正介入。測試就是個人負責。因此時間和人力資源對測試來說是完成測試工作的一個風險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務，把握重點業(yè)務和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關系，測試用例都是先寫重點的業(yè)務，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風險大的業(yè)務功能編寫測試用例。由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白?？上宜诘墓?，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的bug通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。第二個問題，剛開始做測試的時候，你是怎么學習寫測試用例的？我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術支持，產(chǎn)品的問題很多，導致技術支持工作很辛苦、很累。為了讓用戶買到的產(chǎn)品的質(zhì)量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認為不就是拿個鼠標點來點去，誰都可以來做。為此，我經(jīng)常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。://現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學習寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。沒有辦法，那時候沒有人指導我，全靠自己自學和領悟，所以那段日子很苦阿！多寫幾次后，就知道和領悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導怎么去執(zhí)行測試。還好，我有編程的經(jīng)驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務才能去寫測試用例，才能更好的去測試。這也是我一點一點的領悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？我的體會：、測試用例要根據(jù)測試大綱來編寫、測試用例也要分測試項進行歸類，這樣比較好分析和閱讀。如：業(yè)務流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務流程和風險高的地方。能分出測試優(yōu)先級別就最好了。、熟悉系統(tǒng)，對編寫測試用例很有幫助。、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。