錯誤推斷法：是根據經驗或直覺推測可能存在的各種錯誤。

正則表達式：通常被用來檢索、替換哪些符號某個規則的文本（如手機號碼、郵箱）

因果圖：適合檢查程序輸入各個條件的各種組合情況。因果圖轉為判定表。一般使用在輸入條件的的各種組合

判定表：與因果圖結合使用

大綱法：拆分系統模塊（一般原型圖已經拆分） 主要用在測試計劃

正交法：一般不用這種方式測試（因為太過繁瑣，需要將所有輸入和結果進行組合）

（借鑒別人的打油詩，僅供參考）

所有輸入選等價

給定範圍加邊界

條件孤立想判定

指定常量取正交

跨界操作流程法

多種狀態遷移圖

條件組合出因果

測試充分全覆蓋

多種方法不唯一

測試用例優先順序劃分

高 ：用戶經常執行的業務邏輯操作，涉及金錢的功能等

中 ：用例多數包括邊界值、逆向邏輯等

低 ：很少被用戶執行的操作

下面是目錄，可以根據自己的需求來選擇性閱讀哈

→→測試用例是什麼？

→→測試用例有什麼必備的方面？

→→寫測試用例的方法有哪些？

→→測試用例怎麼寫？

→→測試用例用什麼寫？

1.測試用例是什麼？

測試用例是指對一項特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。簡單地認為，測試用例是為某個特殊目標而編製的一組測試輸入、執行條件以及預期結果，用於核實是否滿足某個特定軟體需求

2.測試用例有什麼必備的方面？

編寫測試用例的八大要素有：用例編號，所屬模塊，測試標題，重要級別，前置條件，測試輸入，操作步驟，預期結果

3.寫測試用例的方法有哪些？

知道了什麼是測試用例，那該怎麼寫測試用例呢？不著急，先來學習一下測試用例的方法有哪些

（1） 等價類劃分

原作者：xuping511_to

原文鏈接：https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#

來源：百度文庫

將測試中所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。然後從每個部分中選取具有代表性的數據當做測試用例進行合理的分類，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性

舉個栗子：輸入框要求輸入1-100的數

有效等價類：可以輸入1-100之間的數來驗證，如：2、6……99

無效等價類：可以輸入1-100之外的任意字元驗證，如：250、字母、下劃線、特殊符號、空格、回車.....

（2） 邊界值

原作者：xuping511_to

原文鏈接：https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#

來源：百度文庫

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

實踐告訴我們：大量的錯誤是出在輸入輸出的邊界價上。我們還拿上面的例子，一個輸入框要求輸入1-100之間的數。我們要測它有沒有超出這個範圍，如：0、-1、-2、10、101.....等等，來判定是否超出了我們的範圍。

（3）因果圖

用圖解的方法表示輸入的各種組合關係，寫出判定表，從而設計相應的測試用例。最終生成的就是判定表，它適合於檢查程序輸入條件的各種組合情況。

原文鏈接：https://www.docin.com/p-2173458956.html

原作者：邊雄剛

原文出處：豆丁

例子：有一個處理單價為5角錢的飲料的自動售貨機軟體測試用例的設計。其規格說明如下：若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅燈亮，這時在投入1元硬幣並押下按鈕後，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還5角硬幣。

解析：如題可知，可分析出原因和結果

原因：

1. 售貨機有零錢找

2. 投入1元硬幣

3. 投入5角硬幣

4. 按下橙汁按鈕

5. 按下啤酒按鈕

結果：

10.售貨機【零錢找完】燈亮

11.退還1元硬幣

12.退還5角硬幣

13.送出橙汁飲料

14.送出啤酒飲料

中間結點：

6.選商品

7.應該找零錢

8.能夠找零錢

9.錢已付清

如下所示↓：畫出因果圖（原因結點列在左邊，所有結果結點列在右邊，中間節點表示處理的中間狀態）

（4） 錯誤推測法

基於經驗和直覺推測出系統可能存在的錯誤，從而有針對性的設計測試用例的方法

（5） 其它方法

除了上面幾種常用的，其它的方法還有：狀態遷移圖、流程分析法、正交驗證法等等

我在逛博客園的時候看到一首打油詩，我覺得非常合適：

所有輸入選等價

給定範圍加邊界

條件孤立想判定

指定常量取正交

跨界操作流程法

多種狀態遷移圖

條件組合出因果

4.測試用例怎麼寫？

當~當~當~終於來到重頭戲了，讓我們來看看怎麼寫一個合格的測試用例吧

用例編號：唯一標識用例的序號。一般是數字或者模塊字母+數字組合。如：L001，L表示登錄，001表示用例序號

所屬模塊：所測功能模塊的名稱，如：登錄模塊

用例名稱：就是這個用例是什麼意思。如：輸入賬號

前置條件：前置條件可以保障後面的測試步驟正常進行，可以理解為執行當前用例的前提條件。比如：只有註冊過的用戶才能登錄

測試輸入：用例執行期間輸入的外部信息。根據用例的種類不同，測試輸入也有所不同。包括數據、圖片、手工操作、文件、資料庫記錄等類型

測試步驟：詳細完整的把你測試的過程描述出來

預期結果：對當前用例的輸出做一個預期值。預期結果是根據軟體需求所得出的，相當於一個衡量標準。在實際測試過程中，得到的實際測試結果與預期結果不符，那麼測試不通過；反之則測試通過。

實際結果：實際測出來的結果（可能會和預期結果不符）

另外，有些公司可能會要求在用例後面添加優先順序、用例人員姓名、測試日期、用例修改日期、測試結果（Pass、Fail、Block）等等，這個得根據公司的會實際情況來看

我根據上面的登錄頁面寫了一個登錄模塊的測試用例，如下表所示，你們可以參考一下：

PS：都看到這裡了，真的不考慮給這麼用心的我

@可樂豆

一個點贊、關注嗎？(*?▽?*)

5.測試用例用什麼寫？

測試用例可以以Word或者Excel的方式呈現，主要用到的工具有禪道、testlink等等

---

另外，網上有很多軟體測試的模板。（本來這裡有一個博客園模板的鏈接，知乎告訴我違規了，想要的可以私我，當然你們也可以去博客園自己找）

對了，關於軟體測試的學習路線，可以看一下我之前寫的文章，裡面非常詳細的寫了軟體測試的技術學習路線和每個階段該具體該學什麼：2020最全軟體測試學習路線和資料分享

好了，終於寫完了這篇文章。如果你喜歡這篇文章就請點贊關注一下@可樂豆吧。總之，關注可樂，入股不虧~(筆芯)後續，可樂也會發布關於軟體測試的相關文章

---

安裝卸載測試？

安裝程序是第三方的還是自己寫的？

第三方的簡單，好的情況他都處理好了，只要確保調用正常就可以。案例檢查配置文件需要修改的地方是不是配置正確。

自己寫的要測的就多了。

一 界面

一共幾個界面，界面元素，位置，文字，是否有效

二 安裝

1.預設安裝

安裝完成後啟動成功

拷貝的文件位置正確，數量正確，文件完整，許可權正確

創建文件成功，位置正確，內容正確，許可權正確

鏈接文件創建成功，鏈接正確，許可權正確

註冊表修改成功，內容正確

安裝日誌無報錯

2.自定義安裝

安裝路徑創建成功

自定義配置正確

3.安裝失敗

錯誤處理：許可權不足，空間不足，文件拷貝不全……安裝日誌內容正確

手動取消，退回上一步，退出安裝程序，清除已安裝文件

4.再次安裝，覆蓋已有文件或升級已有文件

三 卸載

目標文件已刪除

註冊表內容修改成功

卸載日誌內容正確

另外，如圖，存在幫助，調用幫助成功

就測試案例來說，明確測試目的，測試點是否已覆蓋，測試步驟明確可操作，測試結果明確可驗證，必要時輔助測試數據

再複雜一些，說明所使用的測試方法，測試工具，自製腳步……

最終目的，使其他測試人員能復現整個測試過程，查找沒有覆蓋的測試點，優化測試數據，測試方法，測試工具，更有效的保證軟體質量

---

哈嘍我來了 感謝邀請！！

在企業的實際工作當中，為了提高測試的覆蓋率，提高測試過程的可追溯性，我們往往需要通過需求分析從而編寫大量的測試用例，看似簡單的測試用例其實隱藏著眾多邏輯和技巧在內，寫出一份優質的測試用例能夠大大的提高測試質量，從而發現更多的BUG，寫好測試用例其實並不容易！

下面我來說說到底如何編寫一個測試用例呢？步驟是怎麼樣的？作為測試新人，如何實現測試用例的設計一直是大家共同的困惑，在工作中我們該如何展開測試用例的編寫工作呢？我們先來梳理一個測試用例的設計步驟。

　　前提:　　再去編寫測試用例之前我們要對我們的項目需求進行了解，按照什麼順序測試，去測什麼？覆蓋哪些內容和需求都要自己心裡有數，作為測試用例的編寫者不僅瞭解要有工作當中常見的測試用例編寫方法，同時需要了解被測軟體的設計、功能規格說明、用戶試用場景以及程序/模塊的結構。 步驟： 1、測試需求分析需求分析就是要弄清楚用戶需要的是什麼功能，用戶會怎樣使用系統。這樣我們測試的時候才能更加清楚的知道系統該怎麼樣運行，才能更好的設計測試用例，才能更好的測試。測試需求分析是測試工作的第一步，經過需求分析，對原始需求列表中列出的每一個需求點，找到我們需要測試的測試要點；針對所確定的測試要點，分析測試執行時對應的測試方案/方法。

2、業務流程分析

　　分析完需求後，明確每一個功能的業務處理流程，不同的功能點作業務的組合，以及項目的隱式需求。如遇複雜的測試用例設計前，先畫出軟體的業務流程。　　從業務流程上，應得到以下信息： A、 主流程是什麼? B、 條件備選流程是什麼? C、 數據流向是什麼? D、 關鍵的判斷條件是什麼?

例如：app測試流程及業務流程

3、測試用例設計

　　完成以上兩步則可進行測試用例設計，功能測試用例，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。

4.編寫完成後自我檢查以及部門內部評審

5.測試用例更新完善　　測試用例編寫完成之後需要不斷完善，如遇需求更改或功能新增時，測試用例必須配套修改更新，同時在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善;在軟體交付使用後客戶反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。

好的測試用例是怎麼樣的？

　　一.質量屬性

　　1.正確性：確保測試標題描述部分的內容正確性。

　　2.經濟性：只為確定需要的目的設計相應的測試步驟

　　3.適應性：既能適應短期需要，又能考慮長遠需要。

　　4.可追蹤性：用例能追蹤到一個具體的需求。

　　5.自我清理性：單個用例不會影響整個測試環境，即用例執行完了可以恢復原有的測試環境。

　　二.結構化和可測試性

　　1.含有規範的測試標題和編號。

　　2.含有一個確定的測試某一個特定需求的目的。

　　3.含有關於測試方法的描述。

　　4.指定條件信息-環境、數據、預置的條件測試、安全入口等。

　　5.含有操作步驟和預期結果。

　　6.陳述任何輔助證據，例如截圖報告並確保這些東西妥善保存。

　　7.確保測試環境的乾淨（即用例不會影響整個環境）。

　　8.描述時使用主動語氣結構。

　　9.操作步驟不要超過15步

　　10.確保單個用例測試執行時用時不超過20分鐘。

　　11.自動化腳本用例添加必要的注釋，比如目的、輸入和期望結果。

　　12.如果可能，建議提供可選擇性的預置條件測試。

　　13.用例之間的先後順序是否跟業務流程一致，即用例在業務流程中的彼此順序關係是否合理。

　　三.配置管理

　　1.採用命名和編號規範歸檔。

　　2.保存為特定的格式，文件類型。

　　3.用例版本是否與當前被測試軟體版本一致（對應）。

　　4.包含用例需要的相應測試對象，如特定資料庫。

　　5.存檔閱讀。

　　6.存檔時按角色控制訪問方式

希望可以幫到題主有什麼問題私信我，還有免費資料可以領取！

---

測試用例組成部分一般是：前置條件，測試步驟，期望結果，用例等級，用例類型等等。

具體要怎麼寫就太寬泛了，一般是根據需求點去寫，靈活運用等價類劃分、邊界值分析、組合覆蓋、邏輯推斷、業務路徑覆蓋等等設計方法，並在測試中不斷完善和新增……

---

推薦閱讀：