测试 - 用例篇 - 细节狂魔
文章目錄
- 回顧一：上篇博客[軟件測試- 基礎(chǔ)篇 ](https://blog.csdn.net/DarkAndGrey/article/details/125318528?spm=1001.2014.3001.5502)
- 回顧二：[概念篇](https://blog.csdn.net/DarkAndGrey/article/details/125281778?spm=1001.2014.3001.5502)
- 1、什么是測試用例？
- 2、為什么軟件測試人員要寫測試用例？
- 軟件測試 - 用例篇
- 測試用例的基本要素
- 測試用例的設(shè)計方法
- 基于需求設(shè)計測試用例
- 總結(jié)
- 實戰(zhàn)案例 - 日歷系統(tǒng)
- 具體的設(shè)計測試用例的方法
- 等價類
- 邊界值
- 錯誤 猜測法
- 案例 - 水杯測試 - 培養(yǎng)的思維
- 場景設(shè)計法
- 因果圖法
- 正交排列 - 了解即可
- 3、測試用例的有效性
- 4、測試用例的粒度和評價 - 了解
- 測試用例的粒度
- 測試用例的評價
- 實戰(zhàn)測試用例：百度云盤的測試用例 - 自己可以參考這個寫一個。
- 百度云盤功能需求分析 - 粗略版
- 非功能性測試
回顧一：上篇博客軟件測試- 基礎(chǔ)篇
上篇博客最主要的問題有三個
1、軟件測試的流程是什么？【生命周期】
?
2、如何描述一個bug？
3、因為一個BUG 和 開發(fā)人起沖突該怎么做？
?
回顧二：概念篇
1、什么是測試用例？
向被測系統(tǒng)發(fā)送的一組集合。
這個集合中包含：測試環(huán)境，測試數(shù)據(jù)，測試步驟，預(yù)期結(jié)果。
?
2、為什么軟件測試人員要寫測試用例？
你給產(chǎn)品給我，我直接拿著產(chǎn)品測試，不是一樣可以的嘛。
我為什么要哦去寫測試用例呢？
而且看過前面幾篇測試=博客的朋友，就會發(fā)現(xiàn)我給的測試用例，真的讓我們?nèi)?#xff0c;估計沒有一兩個小時的時間，是寫不了那么完整的！
也就是數(shù)寫一個測試用例是非常耗時的！
?
回到最初的問題：我為什么要花那么多時間去寫測試用例？
1、測試用例是測試執(zhí)行的依據(jù)
?
2、測試用例可以復(fù)用，在進行回歸測試的時候
看 新添加/修改后 的功能，是否對其它功能有影響？
既然是對就舊功能測試，那么原先的測試用例，就不用重新編寫，直接拿來用！
?
3、測試用例可以衡量需求的覆蓋率
f首先，我們的測試用例是根據(jù)需求來寫的，有了測試用例之后，你對照著需求，就可以進行查漏補缺。
簡單來說：就是查看 需要測試的需求，是否都被被測試了。
如果你不寫測試用例，東一測，西一測，你很容就把自己給測昏了。
有了測試用例，你測完一項，就標(biāo)記一項，這樣你側(cè)漏的概率非常低。
檢查起來，也很快！直接看測試項后面有沒有已測試的標(biāo)記就可以了
?
4、后人可以借鑒
這么說：我們寫過的測試用例，不止是存儲在自己的電腦，公司也會有備份/記錄。
即便你跳槽，活著不干了。這份記錄依舊在公司里存著。
新人來了，就可以借鑒你的了。
?
5、手工測試用例是自動化測試的依據(jù)
自動化測試，就是把手工測試用例，用代碼寫成腳本。
讓電腦代替人來做測試這件事，從而空出一些人手去做其它的事情。
加快項目的開發(fā)效率！
還是那句話：能讓電腦多做一些事，就讓它多做一些！
?
軟件測試 - 用例篇
上一篇博客講述的是一次基本的測試過程。
在我們開始做了一段時間基礎(chǔ)測試，熟悉了業(yè)務(wù)之后，往往會分配來寫測試用例，并且在日常測試中，有時也需要補充測試用例到現(xiàn)有的案例庫中。
?
在這里我們將回答以下問題
1、測試用例的基本要素
2、測試用例的設(shè)計方法
3、測試用例的有效性
4、測試用例的粒度和評價
簡單來說：這篇博客就開始教大家怎么去寫一個測試案例！
?
測試用例的基本要素
其實測試用例的基本要素就是 測試用例的 定義/概念：
測試用例（Test Case）是為了實施測試而向被測試的系統(tǒng)提供的一組集合，這組集合包含：測試環(huán)境、操作步驟、測試數(shù)據(jù)、預(yù)期結(jié)果等要素。
好的測試用例是一個不熟悉業(yè)務(wù)的人也能依據(jù)用例來很快的進行測試評價測試用例的標(biāo)準(zhǔn)：對比好壞用例的評價標(biāo)準(zhǔn)
?
用例表達(dá)清楚，無二義性。。
用例可操作性強。
用例的輸入與輸出明確。一條用例只有一個預(yù)期結(jié)果。
用例的可維護性好。
用例對需求的覆蓋率高。
?
測試用例的設(shè)計方法
PS：講解順序不是按照上米南的順序來的。
基于需求設(shè)計測試用例
我們在講需求的時候，說過：需求是測試人員進行測試的依據(jù)。；
當(dāng)我們測試人員拿到需求之后，需要分析需求，驗證需求的合理性與正確性。
隨后，從需求中提取出測試項，再去根據(jù)測試項進行進一步的細(xì)份，提取出測試點，編寫測試用例。
?
有看過上篇博文的朋友，應(yīng)該都知道我給本文做了一個“鋪墊案例：《QQ登錄測試用例》”。
雖然我們書寫測試用例的時候是從軟件功能上入手的，但是當(dāng)我們進行測試的時候，最先引入眼簾的是 程序界面。
因此，我們測試一般是從軟件界面開始進行測試。
也就是觀察界面是否符合 UI（User Interface - 用戶界面）的設(shè)計稿。
這個設(shè)計稿，你可以理解為是軟件的靜態(tài)頁面，也說是前端程序員的 頁面模板。
前端程序員就是按照 UI 的 設(shè)計稿 進行 頁面設(shè)計的。
?
軟件頁面測試完成之后，就是驗證軟件的功能。
我們可以把業(yè)務(wù)相關(guān)的功能串起來進行測試。
比如：
緊接著，就是針對一個功能的不同輸入 與 其相應(yīng)的輸出 ，進行測試。
隨后就是 功能之間的交互性 與 異常功能的測試
?
還有一些比較難的測試項
比如：實現(xiàn)功能所用到的算法，也是需要進行驗證的。
然后，就是從易用性，兼容性性能等幾個方面去考慮
?
總結(jié)
當(dāng)我們進行設(shè)計 測試用例 的時候，我們應(yīng)該從以下這幾個點入手：
1、界面測試
2、驗證軟件的功能，把業(yè)務(wù)相關(guān)的功能串起來進行測試【每個功能都需要測試】
3、一個功能的不同輸入 與其 相對應(yīng)的不同的輸出。
4、功能之間的交互性
5、異常功能的測試
6、功能所用到的算法，也需要進行驗證
7、從易用性，兼容性性能等幾個方面去考慮
簡單來說：設(shè)計一個合格的測試用例，就是從一個軟件的外在到內(nèi)在的進一步分析，分析出一個個測試項。再通過這些測試項細(xì)化出一個個測試點，而測試點又可以分情況處理【即：對測試點進一步細(xì)分】。
一至六，都是針對 功能性 進行測試。
唯有 第七條 是針對非功能性測試。
有的人可能覺得有點糊，你確定是在講 “基于需求設(shè)計測試用例”嘛？
兄弟們，學(xué)習(xí)測試，需要探索性思維。
你也可以理解為是一種發(fā)散思維，從不同的角度，將內(nèi)容給聯(lián)系起來。
你們之所以感覺有點糊，不是你們沒有看懂，而是你沒有捅破“那一層膜”！
膜：就是你們要主動思考 兩樣?xùn)|西的關(guān)聯(lián)之處。
下面我就來給你們“開個光”！
那 界面 來說：
界面的功能和排版，都需要符合大眾的需求。
比如：支付寶
我們在打開支付寶的時候，通常都是為了出示支付嘛，或者是收款碼，進行首付款。
因此，我們希望已進入支付寶，我們就能看到 這兩個功能。
如果兩個功能可以合并在一起，那最好。
支付寶也是這么去做的：當(dāng)我們打開支付寶的時候，馬上就能發(fā)現(xiàn)收付款的功能圖案
點擊它，我們首先進入是付款碼，因為花錢 比 收錢的日子要多。
而且，工資什么的，都是直接進行銀行卡轉(zhuǎn)賬的。
因此，默認(rèn)顯示 付款碼是很合理的！
而且，你想要收款的時候，就在付款碼的下面，是有一個收款碼的選項的。
以上這一些，都是根據(jù)用戶的需求（習(xí)慣），衍生出來的。
而我們需要測試的地方，也就是這里。
我們點擊這個收付款，首先進入的是不是付款碼的界面？
這就是一個測試點啊！
為什么要測？為了符合用戶的需求啊！
?
其它的6個點，其實你們仔細(xì)想想。
結(jié)合前面講解的例子，就都能發(fā)現(xiàn)，它們都是符合用戶需求（習(xí)慣）的。
?
這不就是根據(jù)需求來設(shè)計測試用例嘛？？？
想通了，你在閱讀后面的內(nèi)容就會輕松很多！
再次強調(diào)：學(xué)習(xí)測試，重要思維。
多去思考 軟件功能 與 用戶之間的聯(lián)系，這樣才能幫助你的測試生源。
?
實戰(zhàn)案例 - 日歷系統(tǒng)
上面都是一些功能性的測試，還有一些非功能性測試，這里我們這是書寫一下。
易用性，兼容性，性能，安全性，可移植性，可維護性。
非功能性測試 就是測試在軟件本身有的功能之上做的一些限制。
比如：
QQ用戶登錄測試用例中的，關(guān)于登錄操作的測試。
即使 用戶登錄操作是可以進行登錄的。
而非功能測試，就比如：拿性能來說
其實這句話?“非功能性測試 就是測試在軟件本身有的功能之上做的一些限制。”
還可以這么去理解：
這里的限制，你可以理解為是一種 要求 / 指標(biāo)。
這么說吧：“非功能性測試”就是為了提升用戶的體驗；對軟件的執(zhí)行沒有影響。
需要注意的是：上面提到這些非功能性的測試（易用性，兼容性，性能，安全性，可移植性，可維護性），不是所有的，都要測試！
?
不同的應(yīng)用軟件 對于 以上 非功能性的要求 是 不一樣的！！！
比如：
1、面向客戶端的軟件：【畫圖板，office，Word，xmind】
這種軟件對 性能，安全性要求不高。
但是對于 兼容性，可移植性，穩(wěn)定性要求較高。
理由很簡單，因為是面向客戶端的，也就是 1v1 的服務(wù)。
面向一個客戶的服務(wù)軟件。
這么說吧：在你的電腦上，是訪問不到我電腦的的畫圖板的。
不存在用戶之間的交互，1 v 1 服務(wù)。
既然是 1 v 1 服務(wù)，軟件只需要滿足你一個人的需求即可，因此對性能的要求肯定不高。
?
其次，不存在客戶端與服務(wù)器之間的交互，也就不存在中間人攻擊的說法。
因此對于 安全性 的要求也不高
?
另外，這都是辦公必備軟件，因此必須在不同類型的系統(tǒng)上，都能安裝運行。
因此對于 兼容性 的要求，比較高。
?
還有就是，我發(fā)送給你的 Word，office 之類的文件，只要對方也安裝了相應(yīng)的文件，也能打開使用。因此對于可移植性的要求也是比較高的。
?
既然這些軟件都是公辦必備軟件，肯定是會被頻繁使用的。
因此，對于軟件的 穩(wěn)定性 要求就比較高！你這軟件不能用著用著就崩了，別人的數(shù)據(jù)怎么辦！！！
2、面向企業(yè)內(nèi)部的軟件
比如：飛Q，飛書（字節(jié)跳動）。。。。這種用于企業(yè)內(nèi)部員工使用的交流軟件。
因為這種類型的軟件，只是針對自己公司的內(nèi)部人員使用。
公司可以統(tǒng)一電腦的操作系統(tǒng)，因此對于 系統(tǒng)的兼容性要求不高
公司內(nèi)部的人員，其實不是很多。
別看著幾千人，其實對于計算機來說也就那樣。
因此對于 性能的要求 也不是很高。
?
但是對于功能性，可靠性的要求高。
因為是公司內(nèi)部人員使用，那么肯定是用來 互傳文件，互相溝通之類。
至少需要滿足 員工 的一些日常操作。
因此對于功能性的要求高。
?
對于傳文件，肯定是要求不能發(fā)生 傳輸殘缺/丟包 的情況！！！
文件里都是代碼，缺胳膊少腿，誰知道是哪里少了點什么？？？
因此對于 可靠性的要求 是比較高的！
3、大型的商用軟件
比如：微信，QQ
別邊看它們是免費使用的。。。
你想想會員和各種鉆，還有超級版本的（更貴的）。你敢說你沒往里面砸一分錢？
另外，用戶基數(shù)多，說明流量多，廣告商就會投資，讓 QQ/微信 投放 他們的廣告.
這是要給騰訊錢的！！！
也就是說：我們都在直接或間接的 為騰訊賺錢！
奈何自己不花錢的是真的香，廣告商的錢又不是我們的錢。。。
?
這種大型商用軟件對 非功能性 的 各個方面要求都很高。
你這么想：用戶多，對軟件的性能的要求就高。不然請求一多，服務(wù)器根本處理不過來。
?
另外，對于這種大型商用軟件，尤其用戶基數(shù)特別大的軟件。
它不可能說，要求必須是某某系統(tǒng)，才能安裝吧？這不是在 “作死”嘛！
擺明就是想損失用戶。
因此，想這種大型商用軟件 對于 兼容性的要求，就很高。
巴不得什么設(shè)備都能裝它們的軟件，這些都是錢啊！
啊。不。這些都是衣食父母啊！！
?
接著，像QQ 和 微信 這種交流軟件，對于 可靠性的要求也很高。
總不能，我給 A 發(fā)消息，結(jié)果B收到了。
萬一聊天內(nèi)容特別勁爆，發(fā)錯人就很尷尬！
另外，聊著聊著就丟包，數(shù)據(jù)無法進行傳輸，也是不好的。
?
同時對 可移植性 和 安全性 的要求，同樣也很高。
可移植性 體現(xiàn)在 我們在換手機之后，進行軟件搬家的時候，把軟件從一個系統(tǒng)到另一個系統(tǒng)的難易程度。
?
對于安全性，這是最好理解。
每個人的聊天信息都屬于個人隱私，沒有人愿意說給一個外人看。
另外，現(xiàn)在的 QQ號/微信 多數(shù)都是和游戲賬號綁定的。
如果QQ號被盜，那么這些綁定的“財產(chǎn)”也就沒了。
?
具體的設(shè)計測試用例的方法
等價類
根據(jù)輸入（特殊情況下，才考慮輸出），把輸入劃分成若干個等價類，從每一個等價類當(dāng)中選擇測試用例進行測試。
如果這個測試用例，測試通過了。
我們就說這個測試用例代表的等價類測試通過。
我來舉個例子，幫助你們來了解 等價類。
等價類，就是把同一個事物進行劃分。
比如：
這里有 3只狗：哈士奇，阿拉斯加，薩摩耶，它們都是犬類動物，也就是狗吧？
此時我們就可以將它們劃分到 狗，這一類里面。
那么，問題就來了：狗這一類，難道只有這3種品種嗎？
答案肯定不是，種類還有很多！
雖然種類繁多，但是狗的習(xí)性基本是一致的。
我們可以通過對 幾只共性很強的狗 進行試驗，而得出的結(jié)果基本上是可以代表絕大部分的犬類，
?
這也是 等價類 目的：
通過將相同類型的事物，劃分成一個類（等價類）。
從中提出幾個典型的案例進行測試，其測試的結(jié)果就能代表 這個等價類中 的 絕大部分情況的測試結(jié)果。
簡單來說：等價類能夠幫助我們解決測試用例 無法進行窮舉的情況
下面，我們再來舉個例子，了解一下 等價類的應(yīng)用場景。
?
邊界值
不知道大家還記不記得：在 冒泡排序，選擇排序中，有兩層for循環(huán)。
忘記了的，可以參考這篇文章Common Sort - 常見的幾種排序 與 不常見的幾種排序
里面循環(huán)變量是從0開始自增，但小于 length - 1的。
其實這里 array.length -1 ，就是邊界值，為了防止數(shù)組越界，導(dǎo)致代碼崩潰
而我們測試中的邊界值，是 輸入 和 輸出 的邊界。
我們要針對 輸入 和 輸出 的 邊界 進行 測試用例的設(shè)計。
tips (建議)：等價類 和 邊界值 結(jié)合在一起進行測試用例的設(shè)計。
因為 等價類 的 測試用例中，就包含著 邊界值 測試用例。
只不過在等價類中是分離開的，有效等價類 和 無效等價類。
?
錯誤 猜測法
注意！不是瞎猜！！！
而是根據(jù) 測試人員的經(jīng)驗 和 知識 的 積累，來猜測某一塊功能有問題。
隨后，有針對性的進行測試用例的編寫。
說白了：就是程序員的經(jīng)驗之談。
?
有的朋友可能就會有疑問：你覺得我像是有經(jīng)驗的佬嘛。。。
其實！我們是有經(jīng)驗的！！！
因為我們一直在使用各種 APP，打游戲，聽音樂，看小說等等。。。。
我們具有使用經(jīng)驗，也就是用戶體驗軟件的經(jīng)驗。
我們很容易就能 get 到 用戶的需求有哪些，因為我們也是用戶。
也就是說：我們至少擁有用戶的經(jīng)驗。
而我們?nèi)鄙俚氖?#xff1a;站在測試的角度去看待需求的經(jīng)驗。
錯誤 猜測法，有點類似于 探索性測試。
針對性比較強，比較依賴測試人員個人的水平。
比如：
1、搜索查詢框 - 空格
在某個 軟件/網(wǎng)頁 中，搜索關(guān)鍵字的時候，而且這個關(guān)鍵字，在服務(wù)器的數(shù)據(jù)庫中是有對應(yīng)的數(shù)據(jù)的。
只要我們在關(guān)鍵字的左右兩側(cè)敲一個空格（關(guān)鍵字 ：“空格 + 奧特曼 + 空格”），就搜索不到。
因為這兩個空格，導(dǎo)致原本可以搜索到的數(shù)據(jù)，現(xiàn)在搜索不到了。
在Java中，String類型有一個方法 trim()，可以去除 字符串 前后的 空格。
由這個問題引申出另外一個問題：字符串中間的空格是否要去掉？
答案：不能！
中間的空格，一般是用戶刻意敲的，可能具有實際的意義。
而兩側(cè)的空格，可能是用戶誤敲的，沒有實際的意義。
?
2、搜索查詢出的信息：500條
每一頁展示 100 條，共展示5頁。
但是發(fā)現(xiàn)不同的頁面上有相同的數(shù)據(jù)，數(shù)據(jù)ID也是一樣的。
一般查詢到的結(jié)果，是需要經(jīng)過排序的。
排序的條件，暫且忽略。反正，就是根據(jù)某種唯一的參數(shù)進行排序。
比如：數(shù)據(jù)ID
?
下面我們來分析一下：
?
案例 - 水杯測試 - 培養(yǎng)的思維
這是一個在美團面試中被提到的面試題。
PS：由于題目沒有給出 到底是那種水杯，牽扯的范圍很廣。
因此，我們這個案例不是 全面（覆蓋性不強）。
?
場景設(shè)計法
很多軟件不同的場景， 都是基于不同事件的觸發(fā)。
不同事件的觸發(fā)，會導(dǎo)致場景走向不同的 時間流 / 場景。
?
前面講的 錯誤猜測法，等價類 和 邊界值，都是針對某一個孤立的功能去進行設(shè)計。
?
而場景設(shè)計法 就是把不同的功能點 給串起來了，形成一個場景。
需要注意的是：不同的功能點有不同的輸出，不同的輸出就會導(dǎo)致不同的測試場景。
下面，我們來通過一個例子來加深對場景設(shè)計法的理解。
場景分析法，還可以認(rèn)為是將一個功能集成模塊 給 拆分成一個個單獨功能模塊，進行設(shè)計測試用例。
?
因果圖法
面試會問，但是在實際工作中用的很少。
即便是在工作中用到了，你可能都沒有意識到自己使用了因果圖法。
因果圖法，與其說是 一種指導(dǎo)思想；
不如說是：在我們經(jīng)過大量測試之后，具有了一定的測試經(jīng)驗，總結(jié)出來的 測試方法。
和前面 錯誤猜測法 是類似的，都是經(jīng)驗之談。
首先，因果圖 是 一種邏輯圖，它具有 恒等，與，或，非 邏輯。
用因果圖來設(shè)計測試用例，就叫做因果圖法。
因果圖法的使用場景：
下面我們再來分析因果圖中所包含的那些邏輯。
下面我們來看一下：因果圖法 設(shè)計測試用例 的 步驟
1、分析出所有的輸入和輸出
‘2、找出輸入和輸出之間的組合關(guān)系
3、根據(jù)關(guān)系畫出因果圖
4、根據(jù)因果圖畫出判定表
5、根據(jù)判定表寫出測試用例
‘?
下面我們來通過一個例子，來加深對這五個步驟的印象’
?
正交排列 - 了解即可
顧名思義：就是根據(jù)正交性來設(shè)計測試用例的。
它是從大量的實驗（測試）數(shù)據(jù)中根據(jù)正交原則 取出最優(yōu)的數(shù)據(jù)的組合。
然后，根據(jù)最優(yōu)數(shù)據(jù)組合 實驗的結(jié)果 來分析整個測試的結(jié)果。
?
詳細(xì)來說：
全稱正交試驗設(shè)計(Orthogonal experimentaldesign)是研究多因素多水平的一種設(shè)計方法，它是根據(jù)正交性，由試驗因素的全部水平組合中挑選出部分有代表性的點進行試驗，通過對這部分試驗結(jié)果的分析了解全面試驗的情況，找出最優(yōu)的水平組合。正交試驗設(shè)計是一種基于正交表的、高效率、快速、經(jīng)濟的試驗
?
因素（Factor）：在一項試驗(測試)中，凡欲考察的變量稱為因素（變量）
水平（位級）（Level）：在試驗（測試）范圍內(nèi)，因素被考察的值稱為水平（變量的取值）
正交排列的運用場景
因果法設(shè)計用例太多怎么辦？
正交法的目的是為了減少用例數(shù)目。用盡量少的用例覆蓋輸入的兩兩組合。
正交表的構(gòu)成：
行數(shù)(Runs)：正交表中的行的個數(shù)，即試驗的次數(shù),用N代表。
因素數(shù)(Factors)：正交表中列的個數(shù)，用C代表。
水平數(shù)(Levels)：任何單個因素能夠取得的值的最大個數(shù)。正交表中的包含的值為從0到數(shù)“水平數(shù)-1”或從1到“水平數(shù)”，用T代表。
正交表的表示形式： L=行數(shù)(水平數(shù)*因素數(shù)) L=N(TC)
正交表的兩條性質(zhì)：
每一列中各數(shù)字出現(xiàn)的次數(shù)都一樣多。
任何兩列中的各有序數(shù)對出現(xiàn)的次數(shù)都一樣多。
正交法設(shè)計測試用例的步驟：
1、有哪些因素（變量）
2、每個因素有哪幾個水平（變量的取值）
3、選擇一個合適的正交表
4、把變量的值映射到表中
5、把每一行的各因素水平的組合作為一個測試用例
6、加上你認(rèn)為可疑且沒有在表中出現(xiàn)的用例組合
案例:
繼續(xù)以注冊為例（類似工具可以使用微軟的PICT工具）：
1、因素：姓名、郵箱、密碼、確認(rèn)密碼、驗證碼
2、水平：填寫、不填寫
3、表中的因素數(shù)=5；
表中至每個因素數(shù)的水平數(shù)=2
行數(shù)取最少的一個，即試驗次數(shù)最少的一個
L=N(TC)=(2-1)*5+1=6(25) N=Cx(T-1)+1
L=6(25)
N試驗次數(shù)
T水平數(shù)
C因素數(shù)
選擇正交表，這里選擇了L6_2_5。正交表不是隨便選擇的，而是設(shè)計好的
4、生成測試用例
思路：因素取值為填寫時：正交按取值個數(shù)5-3-2-1（5已全了，3，2，1任意排列）進行排列，實驗次
數(shù)不夠用取值為填寫個數(shù)為2或3任意組合，但要滿足正交的二條性質(zhì)。
5、增補測試用例
姓名、郵箱、密碼、確認(rèn)密碼、驗證碼都不填寫
?
3、測試用例的有效性
1、測試用例對應(yīng)的功能已刪除，不可操作了。
這個測試用例沒有用了，沒有意義了。
微信剛出來時與QQ可互發(fā)消息，下一個版本后就不可以發(fā)消息。
2、執(zhí)行一條測試用例未發(fā)現(xiàn)BUG，實際該處有BUG
蘋果7手機微信添加了mobile單車小程序，掃碼不能開鎖，只能使用mobile APP開鎖，測試用例未涉及到蘋果7微信小程序掃碼開鎖
測試遺漏 / 測試用例覆蓋率不高
換句話來說：就是測試用例的有效的范圍沒有包含到該情況。
4、執(zhí)行一條測試用例發(fā)現(xiàn)了BUG
蘋果7手機微信添加了mobile單車小程序，用例已寫到了蘋果7微信添加mobile小程序掃碼開鎖，問題被發(fā)現(xiàn)。
測用用例的有效性的范圍包含了這個點。
5、執(zhí)行一條測試用例未發(fā)現(xiàn)BUG，實際該處BUG已修改
蘋果7手機微信添加了mobile單車小程序掃碼開鎖，可以正常開鎖。
測用用例的有效性的范圍包含了這個點，并且實際效果達(dá)到了預(yù)期的效果。
?
4、測試用例的粒度和評價 - 了解
測試用例的粒度
好的測試用例是一個不熟悉業(yè)務(wù)的人也能依據(jù)用例來很快的進行測試
粒度：指測試用例編寫的詳細(xì)程度.
測試用例可以寫得很簡單，也可以寫得很復(fù)雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內(nèi)容，如探索性測試中的測試設(shè)計，僅會指出需要測試產(chǎn)品的哪些要素、需要達(dá)到的質(zhì)量目標(biāo)、需要使用的測試方法等。
而最復(fù)雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項數(shù)據(jù)，期待的結(jié)果及檢驗的方法， 具體到界面元素的操作步驟，指定測試的方法和工具等。
(1)測試用例寫得過于復(fù)雜或詳細(xì)，會帶來兩個問題：一個是效率問題，另一個是維護成本問題。另外，測試用例設(shè)計得過于詳細(xì)，留給測試執(zhí)行人員的思考空間就比較少，容易限制測試人員的思維。
?
(2)測試用例寫得過于簡單，則可能失去了測試周例的意義。過于簡單的測試用例設(shè)計其實并沒有進行“設(shè)計”，只是把需要測試的功能模塊記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設(shè)計的本質(zhì)應(yīng)該是在設(shè)計的過程中理解需求，檢驗需求，并把對軟件系統(tǒng)的測試方法的思路記錄下來，以便指導(dǎo)將來的測試。
?
大多數(shù)測試團隊編寫的測試用例的粒度介于兩者之間。而如何把握好粒度是測試用例設(shè)計的關(guān)鍵，也將影響測試用例設(shè)計的效率和效果。應(yīng)該根據(jù)項目的實際情況、測試資源情況來決定設(shè)計出怎樣粒度的測試用例。
?
主要考慮可以參考如下內(nèi)容：
產(chǎn)品的質(zhì)量要求
項目對用例的要求
測試時間和資源是否充分
但是不管用例怎么簡化，都不應(yīng)該省略.
?
測試用例的評價
測試用例設(shè)計出來了，如何提高測試用例設(shè)計的質(zhì)量？就像軟件產(chǎn)品需要通過各種手段來保證質(zhì)量一樣，測試用例的質(zhì)量保證也需要綜合使用各種手段和方法。評審分為正式和非正式評審。
同行評審
用戶檢查
項目組評審
（1）測試用例的檢查可以有多種方式 但是最敏捷的應(yīng)當(dāng)屬臨時的同行評審。同行評審，尤其是臨時的同行評審，應(yīng)該演變成類似結(jié)對編程一樣的方式。從而體現(xiàn)敏捷的“個體和交互比過程和工具更有價值”，要強調(diào)測試用例設(shè)計者之間的思想碰撞，通過討論、協(xié)作來完成測試用例的設(shè)計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設(shè)計測試用例。
?
（2）除了同行評審，還應(yīng)該盡量引入用戶參與到測試用例的設(shè)計中來，讓用戶參與評審，從而體現(xiàn)敏捷的“顧客的協(xié)作比合同談判更有價值”這一原則。這里顧客的含義比較廣泛，關(guān)鍵在于如何定義測試，如果測試是對產(chǎn)品的批判，則顧客應(yīng)該指最終用戶或顧客代表（在內(nèi)部可以是市場人員或領(lǐng)域?qū)＜?#xff09;；如果測試是被定義為對開發(fā)提供幫助和支持，那么顧客顯然就是程序員了。
?
(3) 由測試負(fù)責(zé)人組織協(xié)調(diào)開展會議，用例編寫人對用例進行講解，參會人員有異議的當(dāng)場提出。
?
實戰(zhàn)測試用例：百度云盤的測試用例 - 自己可以參考這個寫一個。
百度云盤功能需求分析 - 粗略版
注意在文件傳輸模塊中，對于下載測試項中的 不同文件格式，我們并沒有說清楚很模糊。
下面我們再來看一下，對它的補充、
?
非功能性測試
總結(jié)
以上是生活随笔為你收集整理的测试 - 用例篇 - 细节狂魔的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Latex符号对照表
- 下一篇： Servlet菜鸟教程