學習編寫測試用例心得與體會

2021-06-18 10:22:57 字數 1467 閱讀 9032

做為乙個不專業的測試人員,我常常會思考這些問題:

1、測試用例寫到什麼程度是好的?

2、你是怎麼學習寫測試用例的?

對於測試用例,而我目前正在思考的問題是:

怎麼寫出對公司有價值的測試用例,對公司來說,怎麼測試才是最有價值的測試?測試應該思考哪些問題?

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

這個問題,沒有定語,沒有說是在什麼樣的乙個情況下,因此我這裡只能就我工作中碰到的情況說說了。

在我測試工作中,碰上的測試型別我自己劃分成這麼2種:專案的測試,產品特殊化個性化的測試;

專案的測試指的是我所測試的**是乙個專案,是共大家共同使用的。

產品個性化測試指的是我所測試的**是某一部分使用者或在使用產品時,提出了特殊的功能,針對這些新功能,對產品針對使用者進行了個別修改和優化,提高了使用者體驗度。

對專案的測試,測試的時候通常要考慮這個專案的週期和測試資源。測試就是1個人負責,因此時間和人力資源對測試來說是完成測試工作的乙個風險,我常常擔心測試完成以後還要很多顯而易見的bug;為此在這種情況下,應該首先都是先熟悉系統的業務,跟程式設計人員溝通,把握重點業務和功能後,把測試重點功能點和用例文件制定好。由於時間關係,測試用例都是先寫重點的測試功能點;另外測試用例是根據**基本功能點來寫的。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的bug通常不是在寫測試用例的時候發現的,而是在測試**的過程中,其他時間思考出來的,這就是手動測試的魅力。有些**的缺陷是在你使用**的一瞬間和思考的一剎那突然發現的。

所以要我回答測試用例要寫到什麼程度才比較好,我覺的只要你所寫的測試用例在你的公司能夠順利的執行,不影響你的測試執行工作就可以了。

因為測試用例寫的太詳細,你要花費時間和人力成本,這樣出來的測試用例是最好的也是最貴的,一旦需求變更,也需要修改,這時你會發現這種詳細的測試用例是最不掙錢的。測試用例寫的太粗,別人看不懂,不能執行,那你要花費你的時間去解釋,這就加大了測試的工作量。這也不是好的方法。所以我有些時候覺得這樣也挺好的,不過時間充裕的話我覺得還是應該把測試用例完完整整寫好;

下面先來分析第二個問題吧:剛做測試,你是怎麼學習寫測試用例的?

我剛做測試的時候,對測試一無所知,什麼測試流程、文件都不知道;對測試,大家都認為不就是拿個滑鼠點來點去,誰都可以來做。為此,我經常上網查測試的資料,看看自己到底適合不適合做測試,測試到底是什麼樣的乙個職業,怎麼去規劃自己的個人發展。其實要做好測試,真是不容易,不喜歡,真是不能做這個職業。

在想想自己剛開始寫測試用例的時候,真是好笑。不會寫就像小孩子學習寫字一樣。先是在網上狂搜尋了一把測試用例的模板,綜合了幾個,就形成了。模板找好了,可是寫就費勁了。對於剛做測試的新人,看似簡單的乙個填表工作,要寫好真是不簡單。一開始寫的比較不自然,有些生搬硬套,而且還很慢。不過還好,總有人指導我,雖然有些嚴厲,但是仔細想想這些都是為了自己更好的成長;

多寫幾次後,就知道和領悟了,再加上之前我有程式設計的經驗,所以測試起來也就稍微順手一些,測試完成乙個功能點以後一定要進行反覆的測試,測試一定要細心,認真,多思考。

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

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

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

在我的個人郵箱和msn上,通常同行都問我類似下面這樣的問題 乙個 用例 要寫到什麼程度才比較好?剛開始做測試的時候,你是怎麼 學習 寫測試用例的?你對 黑盒測試 用例的編寫的體會是什麼?有什麼好的版本或者標準嗎?對於測試用例,而我目前正在思考的問題是 怎麼寫出對公司有價值的測試用例,對公司來說,怎麼...

測試用例(四)測試用例編寫

一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集,來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋,覆蓋了更多的可能資料,以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來,但它不是從乙個等價類中任選乙個例子作為代表,而是...