1、測試點與測試用例

測試點不等于測試用例，這是我們首先需要認(rèn)識到的。

問題1：這些測試點在內(nèi)容上有重復(fù)，存在冗余。

問題2：一些測試點的測試輸入不明確，不知道測試時要測試哪些。

問題3：總是在搭相似的環(huán)境，做類似的操作。

問題4：測試點描述得太粗，不知道是不是測對了。

測試點是測試者在測試時需要關(guān)注的地方。雖然我們在分析測試點時，會使用各種測試方法，但這些方法在思路和操作上都是不同的，一些方法得到的測試點要細(xì)一些、具體一些，一些方法得到的測試點粗一些、泛一些是非常正常的。另外，誰也不能保證這些測試點之間不會重復(fù)或是相互包含。如果我們的測試就是按照這樣一份粗細(xì)不一、深淺不明、關(guān)系不清的說明書來進(jìn)行的，又怎么不會陷入既冗余又不足的困境中呢？

而測試用例是在測試點“加工”的基礎(chǔ)上得到的。首先把測試點“去重”（去掉重復(fù)的內(nèi)容）、“合并”（把太細(xì)的測試點合并起來）、“細(xì)化”（把太泛的測試點說清楚、說具體），然后再確定各個測試點的測試條件、測試數(shù)據(jù)和輸出結(jié)果。

如果說測試點還只是一些散亂的測試思路的集合，那么測試用例就是一份真正能夠指導(dǎo)測試的測試說明書。

2、測試用例設(shè)計流程

1、創(chuàng)建測試用例模板

2、設(shè)計基礎(chǔ)測試用例

3、測試用例評審（內(nèi)審+外審）

4、補充測試用例

5、擴(kuò)展（探索性等）

3、編寫測試用例

1、首先確定一個標(biāo)準(zhǔn)的模板

一般包含以下幾項（可根據(jù)公司需要做裁剪或添加）：

用例編號 所屬模塊 用例標(biāo)題 優(yōu)先級 適用階段 前置條件 測試數(shù)據(jù) 操作步驟 預(yù)期結(jié)果 執(zhí)行結(jié)果 備注

2、測試用例標(biāo)題要是一個完整易懂的句子

能夠清晰表達(dá)測試用例的測試目的和關(guān)鍵測試要素，只有當(dāng)測試用例標(biāo)題是一個完整的句子時，讀者才能完整地了解這個測試用例的意圖。

用例標(biāo)題要求一句話簡單描述（在/當(dāng)。。。時候/之后/頁面，主語+謂語+賓語）

3、用條件而不是參數(shù)來描述測試用例標(biāo)題

如果你有對比就會發(fā)現(xiàn)，使用條件來作為測試用例標(biāo)題，和使用參數(shù)相比，前者更能突出設(shè)計這個測試用例的目標(biāo)，也易于讀者理解測試用例的設(shè)計意圖，也更易于維護(hù)?？梢姡诿枋鰷y試用例標(biāo)題時，更適合用條件，而不是參數(shù)。

參數(shù)更適合在測試用例模板中的測試數(shù)據(jù)部分體現(xiàn)，不要把它們羅列在測試用例標(biāo)題中。

4、如果一個用例中包含有多個參數(shù)，用例中應(yīng)該是每個參數(shù)的取值

我們在寫測試用例的時候，應(yīng)該對涉及的每個參數(shù)給出確定的值。

5、不要在測試用例中引用別的測試用例

引用測試用例會給后期用例的修改、維護(hù)和移植帶來麻煩。

我們會在測試用例中引用另外一個測試用例，在很大程度上是因為用例在執(zhí)行中存在先后關(guān)系，即測試用例2一定會在測試用例1之后執(zhí)行。這時我們可以考慮這樣來編寫測試用例：把測試用例1和測試用例2合并成一個大的測試用例?？梢园褱y試用例1的主要內(nèi)容放到測試用例2的預(yù)置條件中。

6、避免測試用例中包含過多的用戶接口細(xì)節(jié)

用例執(zhí)行者應(yīng)該是專業(yè)人士，測試用例不必寫得面面俱到。

7、明確測試步驟和預(yù)期結(jié)果的對應(yīng)關(guān)系

一個測試用例通常會包含好幾個測試步驟和多個預(yù)期結(jié)果。有時候不同的測試步驟可能會有相同的預(yù)期結(jié)果，為了描述簡便，很多測試用例作者會省略相同的預(yù)期結(jié)果。另外，也不是所有的測試步驟都有預(yù)期結(jié)果，一般是重要、關(guān)鍵的測試步驟才會有預(yù)期結(jié)果。這時我們可以在測試用例中，增加簡單的標(biāo)記來明確測試步驟和預(yù)期結(jié)果之間的對應(yīng)關(guān)系，讓測試執(zhí)行人員一目了然。

8、避免在測試步驟中使用籠統(tǒng)的詞

我們在描述測試步驟時，需要盡量避免那些籠統(tǒng)的表述方式，如“反復(fù)”、“長時間”、“大量”等。因為這樣描述，不同的測試執(zhí)行者的理解會有所不同。比如“反復(fù)”，有人會認(rèn)為執(zhí)行兩次就是反復(fù)了，有人可能會認(rèn)為要執(zhí)行至少10次，這樣就會造成測試執(zhí)行上的差異，很可能會達(dá)不到測試的效果。

例1：明確次數(shù)

問題：反復(fù)執(zhí)行接口up/down的操作

解決方法1：在測試用例中確定反復(fù)的具體次數(shù)。

修改1：反復(fù)執(zhí)行接口up/down操作100次。

解決方法2：也可以為測試用例確定一個反復(fù)的范圍。

修改2：反復(fù)執(zhí)行接口up/down操作至少100次。

解決方法3：如果反復(fù)多次執(zhí)行某個操作多次后，會出現(xiàn)某種特定的效果（例如內(nèi)存會升高到某個特別值），但是需要反復(fù)執(zhí)行多少次這樣的操作確并不確定，可以這樣描述。

修改3：反復(fù)執(zhí)行接口up/down操作，直至系統(tǒng)內(nèi)存值達(dá)到最大值的45%。

例2：明確時間

問題：系統(tǒng)長時間轉(zhuǎn)發(fā)HTTP業(yè)務(wù)

解決方法1：在測試用例中確定長時間的測試時長。

修改1：系統(tǒng)持續(xù)轉(zhuǎn)發(fā)HTTP業(yè)務(wù)24小時。

解決方法2：也可以為測試用例確定一個長時間的測試時間范圍。

修改2：系統(tǒng)持續(xù)轉(zhuǎn)發(fā)HTTP業(yè)務(wù)至少24小時。

例3：明確數(shù)量

問題：大量用戶同時連接服務(wù)器

解決方法1：需要確定大量的具體數(shù)量，如1000、2000。

修改1：2000個用戶同時連接服務(wù)器。

解決方法2：可以以產(chǎn)品規(guī)格作為大量的參照值，如滿規(guī)格、系統(tǒng)支持?jǐn)?shù)的50%。

修改2：滿規(guī)格用戶同時連接服務(wù)器。

4、測試用例評估

測試過程評估分析的對象是測試用例、測試方法和測試投入。

為什么進(jìn)行產(chǎn)品質(zhì)量評估還需要對測試過程進(jìn)行分析呢？試想對一個產(chǎn)品測試來說：

1、有充分完備的測試用例和沒有測試用例進(jìn)行隨機測試相比，哪一種測試的結(jié)果更可靠？

2、使用了多種測試方法與測試方法單一相比，哪一種測試結(jié)果更有助于進(jìn)行產(chǎn)品質(zhì)量評估？

3、有經(jīng)驗的測試人員、充足的測試投入與沒有經(jīng)驗的測試人員、測試投入不足相比，哪種測試情況更有利于測試目標(biāo)的實現(xiàn)呢？

可見，對測試過程進(jìn)行評估，對產(chǎn)品質(zhì)量評估而言十分重要。不僅如此，如果我們能夠在測試之前就對測試過程進(jìn)行計劃，還能幫助我們更好地進(jìn)行測試，更好地完成產(chǎn)品的測試目標(biāo)。

我們可以通過如下3個指標(biāo)來對“測試用例”進(jìn)行評估：

1、測試用例執(zhí)行率

（1）測試阻塞 - 試用例因為產(chǎn)品開發(fā)（一般是指缺陷）、測試（如測試環(huán)境不具備）等原因，無法被執(zhí)行的測試用例。

（2）未執(zhí)行 - 可以執(zhí)行，但是因為進(jìn)度、人力或其他原因等還沒有被執(zhí)行的測試用例。

2、測試用例執(zhí)行通過率

（1）首次執(zhí)行通過率 - 測試用例首次執(zhí)行通過率可以幫助我們評估開發(fā)版本的質(zhì)量，測試用例首次執(zhí)行通過率越高，說明開發(fā)的版本質(zhì)量不錯；相反，如果開發(fā)需要多次修復(fù)，最后才能使得測試用例執(zhí)行通過，說明版本質(zhì)量可能不高，產(chǎn)品在設(shè)計、編碼方面可能存在一些問題，即便是修復(fù)bug，在修復(fù)時引入新bug的風(fēng)險也會更大一些。

（2）累積通過率 - 測試用例累積執(zhí)行通過率可以幫助我們評估產(chǎn)品在發(fā)布時的質(zhì)量，一般說來，測試用例累積執(zhí)行通過率越高，說明當(dāng)前的版本質(zhì)量可能已經(jīng)達(dá)到了基本要求，可以考慮發(fā)布。

3、測試用例和非測試用例發(fā)現(xiàn)缺陷比

測試人員在按照測試用例執(zhí)行測試的時候，也會拋開測試用例，自我發(fā)揮，做些隨機測試。顯然，隨機測試也能發(fā)現(xiàn)缺陷，有時候甚至比測試用例更能發(fā)現(xiàn)產(chǎn)品缺陷，而且“突然一個靈感來了，然后去測試，并且真的發(fā)現(xiàn)了產(chǎn)品缺陷”的過程，會讓人很有成就感。因此在團(tuán)隊中，我們往往會鼓勵大家在執(zhí)行測試用例的時候適當(dāng)進(jìn)行一些探索性測試，挖掘bug，找找感覺。

我們希望“通過測試用例發(fā)現(xiàn)的缺陷”和“探索性測試，也就是非測試用例發(fā)現(xiàn)的缺陷”的比值能夠在一個合理的范圍內(nèi)。

5、跟蹤測試用例執(zhí)行情況

跟蹤測試執(zhí)行的目的有3個：

1、確保測試團(tuán)隊是按照測試策略來執(zhí)行測試的。

2、實時關(guān)注缺陷，通過缺陷分析來確認(rèn)測試策略是否合適，是否需要調(diào)整。

3、關(guān)注項目中的實時風(fēng)險，基于風(fēng)險來調(diào)整測試策略。

需要特別注意的是，按照優(yōu)先級來執(zhí)行測試用例，不是說我們一開始就只執(zhí)行高優(yōu)先級的測試用例，而不去執(zhí)行中、低優(yōu)先級的測試用例。

我們需要在測試剛開始的時候，對每個功能都執(zhí)行一些基礎(chǔ)性的測試用例，以確認(rèn)這些功能基本可用，不會阻塞后續(xù)的測試。

配置測試→功能測試→功能交互→業(yè)務(wù)流程測試

現(xiàn)在我邀請你進(jìn)入我們的軟件測試學(xué)習(xí)交流群：【746506216】，備注“入群”， 大家可以一起探討交流軟件測試，共同學(xué)習(xí)軟件測試技術(shù)、面試等軟件測試方方面面，還會有免費直播課，收獲更多測試技巧，我們一起進(jìn)階Python自動化測試/測試開發(fā)，走向高薪之路。

資源分享

最后感謝每一個認(rèn)真閱讀我文章的人，看著粉絲一路的上漲和關(guān)注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走…

軟件測試面試文檔

我們學(xué)習(xí)必然是為了找到高薪的工作，下面這些面試題是來自阿里、騰訊、字節(jié)等一線互聯(lián)網(wǎng)大廠最新的面試資料，并且有字節(jié)大佬給出了權(quán)威的解答，刷完這一套面試資料相信大家都能找到滿意的工作。

文章來源地址http://www.zghlxwxcb.cn/news/detail-401203.html

到了這里，關(guān)于測試用例要如何寫的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！