一、留言板測試用例

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

測試用例編寫

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

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

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

2. 接口信息的來源

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

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

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

3. 一些基本原則

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

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

延伸閱讀：

二、什么叫測試用例

測試用例（Test Case）是為某個測試目標而編制的一組測試輸入、執(zhí)行步驟以及預期結(jié)果的集合，以便測試某 個程序的路徑或驗證軟件是否滿足某個特定需求 測試用例的概念包含以下幾個方面的特性： 1.目標：測試用例的目的是為了達到一定目標 2.作用：去驗證某個路徑或某個特定的需求 3.集合：表示測試用例由多個項組成：如輸入數(shù)據(jù)、步驟、預期結(jié)果等。

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