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