一、測試用例留言板

要根據具體實現的功能需求和設計來寫具體的測試用例。
一般來說留言板功能分前臺顯示和后臺控制。
前臺主要是留言內容信息的顯示，顯示內容是否正確，布局效果，排序方式是否合理，用戶留言是否可正確操作，被屏蔽留言是否不顯示。
后臺主要是對留言記錄的控制，如屏蔽和解除屏蔽，回復留言，已審核或已查看。（這個要根據實際功能實現情況）

二、測試用例編寫

1. 某個用例的測試目的是什么

在進行接口測試腳本的編寫前，我們應該明確這批腳本的預期目標在哪里，是為了驗證什么內容。根據個人的經驗，一般會把接口用例分成三類：

單接口驗證：以驗證接口參數、權限、返回值為主，保證接口“能用”，這類用例一般在接口設計定稿后，配合Mock服務就可以完成用例編寫；場景邏輯驗證：以用戶場景為基礎，驗證接口間的參數傳遞及業務流程能夠正常流轉，用例復雜度較高，需要非常熟悉業務與接口之間的關系。這是接口測試最核心的價值。異常驗證：主要驗證參數異常、邏輯異常等情況下，接口是否能處理并給出友好的錯誤信息。通常情況下，關注參數異常的場景會比較多，可以用等價類、邊界值等方式來處理。需要注意的是多關注下異常的返回信息是什么，信息是否明確，提示是否友好等等。

2. 接口信息的來源

當我們明確好測試目標后，再開始編寫測試用例，會有更針對性的去設計測試數據和接口組合。接下來的問題是什么呢？去哪里確認你的接口信息是有效的？基本上有兩種路徑：

接口文檔：開發人員都不喜歡自己寫文檔，同時也很討厭別人不寫文檔。所以測試人員如何獲取一份真實有效的接口文檔是件比較麻煩的事。般團隊內都會有一個統一的接口文檔管理工具（如果沒有，就找開發多磨麿，讓他們弄個，并不難），我們需要關注接口文檔的有效性和及時性。現在也有很多的插件或者工具能夠幫助研發人員自動生成接口文檔，例如Swaager、apidoc等等。接口抓包：如果什么都沒有，那就自力更生，通過Fiddler之類的工具，通過抓包分析的方式來獲取接口，這類的場景如果較多的話，可以把Fiddler抓到的接口導出，然后寫個小程序，直接轉成接口平臺可以識別的腳本，效率會更高一些。

在獲取到接口信息后，需要與開發人員多交流，明確參數的意義及來源，以便我們針對性的做測試用例設計，這個環節不要過多的自己猜（很多測試人員經常會自己猜想），直接找開發問就好了。在這個接段，還要梳理并區分接口的重要程度和優先級。這樣就可以確認哪些接口優先設計用例，哪些接口可以先放放，在有限制的時間內，做最大價值的事。

3. 一些基本原則

拿到接口后，明確了參數說明，結合測試目標，我們就可以開始設計并編寫測試用例了。區別于功能測試用例，接口測試用例（腳本）一些原則需要注意：

自動化：好像是廢話，所有的用例應該是非交互試，最常見的就是Token之類的生成，需自動處理好（我見過每次執行用例前，需要自己手動生成Token再粘貼進去的腳本，特別是分環境執行的時候）。獨立性：每個用例應該是獨立的，沒有依賴的。需要在一個用例里處理好前置條件，而不是多個用例相互依賴。可重復：用例測試可重復執行，所以需要注意參數的生成方式。可持續性：如果代碼修改導致已有接口測試執行失敗，必須修復代碼問題或者測試代碼邏輯。

延伸閱讀：

三、什么叫測試用例

測試用例（Test Case）是為某個測試目標而編制的一組測試輸入、執行步驟以及預期結果的集合，以便測試某個程序的路徑或驗證軟件是否滿足某個特定需求。測試用例的概念包含以下幾個方面的特性：

1.目標：測試用例的目的是為了達到一定目標

2.作用：去驗證某個路徑或某個特定的需求

3.集合：表示測試用例由多個項組成：如輸入數據、步驟、預期結果等。

以上就是關于測試用例留言板怎么寫的內容希望對大家有幫助。