編寫測試用例方法心得體會

2021-03-04 04:26:12 字數 2503 閱讀 8249

由安博測試空間技術中心提供

blueski推薦[2006-7-29]

出處:csdn blog

作者:微風拂面

編寫背景:

一直以來都不太想把技術方面的文章寫出來給大家看,乙個是怕寫作功底不好誤導哪些剛入門的測試同行,自己的表達能力有限,另一方面怕有的同行拿出去炒作,再者測試**論壇上關於測試用例的資料已經實在是多。但是看到同行紛紛都在問我測試用例的問題,都很想知道我寫測試用例的心得體會。我就抱著試試看的心態寫寫吧,希望測試的老前輩看見了,可以給我多提提建議。

在我的個人郵箱和msn上,通常同行都問我類似下面這樣的問題:

1、乙個測試用例要寫到什麼程度才比較好?

2、剛開始做測試的時候,你是怎麼學習寫測試用例的?

3、你對黑盒測試用例的編寫的體會是什麼?有什麼好的版本或者標準嗎?

對於測試用例,而我目前正在思考的問題是:怎麼寫出對公司有價值的測試用例,對公司來說,怎麼測試才是最有價值的測試?

下面先來分析第乙個問題吧:乙個測試用例要寫到什麼程度才比較好?

這個問題,沒有定語,沒有說是在什麼樣的乙個情況下,因此我這裡只能就我工作中碰到的情況說說了。說起來比較長阿,大家要有耐心看才行哈。^_^

在我測試工作中,碰上的測試型別我自己劃分成這麼4種:

^   對專案、產品的測試,測試的時候通常要考慮這個專案的週期和測試資源。我所在的公司,通常專案開發時間都很短4到5個月,然而測試通常都是在開發即將結束的時候才真正介入。測試就是1個人負責。

因此時間和人力資源對測試來說是完成測試工作的乙個風險。為此在這種情況下,我都是先熟悉系統的業務,把握重點業務和功能後,參考需求,把測試需求、測試計畫和測試大綱給制定好。由於時間關係,測試用例都是先寫重點的業務,也就是整合測試的測試用例。

另外測試用例是根據測試大綱來的。通常都是先挑最重要的測試項和風險大的業務功能編寫測試用例。由於測試用例是本人執行,所以測試用例可以寫的簡單些,但是一定要開發人員能夠看明白。

可惜我所在的公司,都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的bug通常不是在寫測試用例的時候發現的,而是在測試軟體的過程中,我在家睡覺前的思考和回家的路上思考出來的。

這就是手動測試的魅力,有些軟體的缺陷是在你使用軟體的一瞬間和思考的一剎那突然發現的。所以要我回答測試用例要寫到什麼程度才比較好,我覺的只要你所寫的測試用例在你的公司能夠順利的執行,不影響你的測試執行工作就可以了。因為測試用例寫的太詳細,你要花費時間和人力成本,這樣出來的測試用例是最好的也是最貴的,一旦需求變更,也需要修改,這時你會發現這種詳細的測試用例是最不掙錢的。

測試用例寫的太粗,別人看不懂,不能執行,那你要花費你的時間去解釋,這就加大了測試的工作量。這也不是好的方法。

第二個問題,剛開始做測試的時候,你是怎麼學習寫測試用例的?

我之所以選擇測試這個工作是因為:我畢業後,在第一家公司做技術支援,產品的問題很多,導致技術支援工作很辛苦、很累。為了讓使用者買到的產品的質量是好的,我選擇了做測試,到了現在的公司。

我剛做測試的時候,對測試一無所知,什麼測試流程阿、文件阿都不知道,公司的測試和管理也不規範。對測試,大家都認為不就是拿個滑鼠點來點去,誰都可以來做。為此,我經常上網查測試的資料,看看自己到底適合不適合做測試,測試到底是什麼樣的乙個職業,怎麼去規劃自己的個人發展。

其實要做好測試,真是不容易。不喜歡,真是不能做這個職業。

現在想想自己剛開始寫測試用例的時候,真是好笑。就像小孩子學習寫字一樣。先是在網上狂搜尋了一把測試用例的模板,綜合了幾個,就形成了。

我之所以不用公司原有的測試用例模板,是因為太不適用了。還好,公司沒有嚴格要求必須要那個模板,只要適用就行。模板找好了,可是寫就費勁了。

對於剛做測試的新人,看似簡單的乙個填表工作,要寫好真是不簡單。一開始寫的比較不自然,有些生搬硬套,而且還很慢。沒有辦法,那時候沒有人指導我,全靠自己自學和領悟,所以那段日子很苦阿!

多寫幾次後,就知道和領悟了,測試用例要根據測試大綱來寫,測試大綱要根據測試計畫來寫。測試大綱更多的是把握住測試項的方向,而測試用例是指導怎麼去執行測試。還好,我有程式設計的經驗,所以對我熟悉軟體幫了乙個很大的忙。

熟悉了軟體的業務才能去寫測試用例,才能更好的去測試。這也是我一點一點的領悟出來的。說了這麼多,不知道這樣的回答是否是回答了這個問題。

最後乙個問題了,我盡量少寫些,文字太多了大家看的也累,我寫的也累。嘿嘿。^_^

你對黑盒測試用例的編寫的體會是什麼?有什麼好的版本或者標準嗎?

我的體會:

1、測試用例要根據測試大綱來編寫

2、測試用例也要分測試項進行歸類,這樣比較好分析和閱讀。如:業務流程測試、安裝測試、功能測試、使用者友好性測試、相容性測試、效能測試、安全性測試等等。

3、編寫測試用例要考慮各種情況,精力主要集中在軟體的主要業務流程和風險高的地方。能分出測試優先級別就最好了。

4、熟悉系統,對編寫測試用例很有幫助。

5、即使對測試很熟悉了,在時間非常緊的時候,編寫測試用例還是很有必要和好處的。

今天就想到那麼些了,以後想到了在補充上了。我把我用的模板給你們貼上乙份上來,只能給你們做些參考,具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了,因為每個公司的都不太一樣。

測試用例編寫說明

測試用例編寫說明 1 一 什麼是測試用例 1 二 我們的測試原則 1 三 理解設計 1 四 構造測試用例的框架 2 五 充實用例內容 2 六 可玩性測試部分 3 七 易用性測試部分 3 八 後續維護更新 4 一 什麼是測試用例 為測試遊戲中某乙個或一組特定功能而制訂的測試方法,通常是關於該功能中若干...

導學案編寫心得體會

去冬以來,在上級領導部門的大力倡導下,學校積極開展新課改探索,營造了新課改的大環境。本學期,我們學校繼續大力推行學案式導學新的教學模式,努力使新課改進入深水區。我積極響應學校新課改的號召,踐行學案式導學課堂教學模式。在去冬今春經過一段時間的學習摸索之後,我獲益匪淺。為進一步推進課堂教學改革,提高單位...

測試用例設計方法培訓

等價類劃分是一種典型的黑盒測試方法。這一方法完全不考慮程式的內部結構,只依據程式的規格說明來設計測試用例。等價類是指某個輸入域的子集合。在該子集合中,各個輸入資料對於揭示程式中的錯誤都是等效的。等價類合理地假設 某個等價類的代表值,與該等價類的其他值,對於測試來說是等價的。因此,可以把全部的輸入資料...