很多人可能不知道，其實(shí)ui設(shè)計(jì)是比較復(fù)雜的，需要后臺(tái)接口多次進(jìn)行測(cè)試。那后臺(tái)接口測(cè)試ui設(shè)計(jì)包括哪些內(nèi)容呢?還有，什么情況下開展接口測(cè)試?下面就一起跟小編來了解一下相關(guān)的內(nèi)容吧。

　　后臺(tái)接口測(cè)試ui設(shè)計(jì)包括哪些內(nèi)容

　　針對(duì)輸入設(shè)計(jì)

　　(1)數(shù)值型：如果參數(shù)規(guī)定了值的范圍，則需要考慮等價(jià)類取值范圍內(nèi)、取值范圍外，取值的邊界，如有需要，可能會(huì)遍歷取值范圍內(nèi)的各個(gè)值。

　　例如檢查權(quán)限的接口：TaskChecker.checkTask(int taskID) taskID的取值范圍是1-35，那么設(shè)計(jì)時(shí)考慮：

　　●1-35范圍內(nèi)和范圍外的值;

　　●1-35的邊界：0，1,35,36;

　　●類型的特殊值：-1,0

　　●數(shù)據(jù)類型的邊界值：int的最小值最大值;

　　●因?yàn)?-35代碼的權(quán)限ID不同，可能需要遍歷1-35的每個(gè)值。

　　常見問題和風(fēng)險(xiǎn)：

　　●特殊值處理不當(dāng)導(dǎo)致程序異常退出;

　　●類型邊界溢出

　　●取值范圍外未返回正確的錯(cuò)誤信息等

后臺(tái)接口測(cè)試ui設(shè)計(jì)

　　(2)字符串型：字符串型的參數(shù)，主要考慮字符串的長(zhǎng)度和內(nèi)容

　　例如接口轉(zhuǎn)換設(shè)置鬧鐘的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考慮：

　　●長(zhǎng)度為4位，比4位少，比4位多;

　　●邊界值：String的最大長(zhǎng)度;

　　●特殊值：空字符;

　　●字符串內(nèi)容可考慮類型：數(shù)字，非數(shù)字;

　　●特殊字符。

　　●如果是輸入用戶輸入且其他用戶可見的內(nèi)容，則還需要考慮敏感字是否被正常過濾。

　　可能出現(xiàn)的問題和風(fēng)險(xiǎn)：

　　●傳入非特定類型程序異常退出

　　●超長(zhǎng)字符未進(jìn)行處理，導(dǎo)致存儲(chǔ)、顯示等異常

　　●其他用戶可見設(shè)置的敏感字

　　(3)數(shù)組或鏈表類型

　　例如批量提交任務(wù)的接口submitTask(int[] taskID)，參數(shù)用例設(shè)計(jì)考慮：

　　●正常取值：1-5個(gè)權(quán)限，范圍外：6個(gè)權(quán)限;

　　●邊界值：1-35的邊界值，請(qǐng)求允許最大最小值;

　　●特殊值：0個(gè);

　　●合法ID和不合法的;

　　●重復(fù)的ID等。

　　可能存在的問題和風(fēng)險(xiǎn)：

　　●0個(gè)item時(shí)程序異常退出;

　　●重復(fù)的item處理時(shí)未去重導(dǎo)致結(jié)果異常等。

　　針對(duì)ui邏輯設(shè)計(jì)

　　(1)約束條件分析

　　意義在于：用戶進(jìn)行操作時(shí)，在該操作的前端可以已經(jīng)進(jìn)行了約束條件的限制，故用戶無法直接觸發(fā)請(qǐng)求該接口。但是實(shí)際上，如果有其他手段：例如UI有bug或者通過技術(shù)手段直接調(diào)用接口，那么接口是否針對(duì)這些條件進(jìn)行了限制就尤為重要。

　　例如常見的例子：要兌換5Q幣需要200積分，但是我積分不足，所以兌換按鈕是灰色無法點(diǎn)擊的狀態(tài)，正常用戶是無法操作的，但是兌換其實(shí)是調(diào)后臺(tái)的一個(gè)接口，如果繞過頁面按鈕的限制，直接調(diào)用后臺(tái)接口兌換呢?是否可以兌換?預(yù)期當(dāng)然是不能兌換的。因此積分這個(gè)數(shù)值限制就需要針對(duì)接口進(jìn)行測(cè)試，并且非常重要。

　　常見的問題和風(fēng)險(xiǎn)：約束條件判斷不足，導(dǎo)致用戶可通過特殊手段獲取利益

　　(2)操作對(duì)象分析：對(duì)象分析主要是針對(duì)合法和不合法對(duì)象進(jìn)行操作。A用戶不能查看到B用戶的用戶信息。

　　(3)狀態(tài)轉(zhuǎn)換分析

　　被測(cè)邏輯可以抽象成狀態(tài)機(jī)，各個(gè)狀態(tài)之間根據(jù)功能邏輯從一個(gè)狀態(tài)切換到另一個(gè)狀態(tài)。如果我們打亂了這個(gè)次序，從一個(gè)狀態(tài)切換到另一個(gè)不在它下一狀態(tài)集中的狀態(tài)，那么邏輯將會(huì)打亂，就會(huì)出現(xiàn)邏輯問題。

　　(4)時(shí)序分析

　　在一些復(fù)雜的活動(dòng)中，一個(gè)活動(dòng)是由一系列動(dòng)作按照指定順序進(jìn)行的，這些動(dòng)作形成一個(gè)動(dòng)作流，只有按照這個(gè)順序依次執(zhí)行，才能得到預(yù)期結(jié)果。

　　在正常的流程里，這些動(dòng)作是根據(jù)程序調(diào)用依次進(jìn)行的，并不會(huì)打亂，在接口測(cè)試時(shí)，需要考慮如果不安裝時(shí)序執(zhí)行，是否會(huì)出現(xiàn)問題。

　　常見的問題和風(fēng)險(xiǎn)：非順序執(zhí)行后，數(shù)據(jù)出現(xiàn)異常，可能還會(huì)出現(xiàn)程序其他異常通過打亂順序獲取利益

　　針對(duì)輸出設(shè)計(jì)

　　(1)針對(duì)輸出結(jié)果

　　接口處理正確的結(jié)果可能只有一個(gè)，但是錯(cuò)誤異常返回結(jié)果有很多情況很多值。如果知道返回結(jié)果有很多種，就可以針對(duì)不同結(jié)果設(shè)計(jì)用例。

　　常見問題和風(fēng)險(xiǎn)：

　　(1)錯(cuò)誤前端處理不足，導(dǎo)致前端異常;

　　(2)錯(cuò)誤提示處理不當(dāng)，導(dǎo)致用戶看到晦澀的錯(cuò)誤碼;

　　(3)錯(cuò)誤提示不當(dāng)，導(dǎo)致用戶不知道哪里出了問題，如何解決。

　　(2)接口超時(shí)

　　接口正常情況下是有返回的，那么如果接口不返回呢?也就是說接口超時(shí)后的處理也是測(cè)試

　　要考慮的部分。如果超時(shí)處理不當(dāng)，可能會(huì)引起以下問題：

　　(1)未進(jìn)行超時(shí)處理，導(dǎo)致整個(gè)流程阻塞

　　(2)超時(shí)后又收到接口返回，導(dǎo)致邏輯出現(xiàn)錯(cuò)亂

　　其他測(cè)試設(shè)計(jì)

　　(1)已廢棄接口測(cè)試

　　已廢棄協(xié)議，是指之前有定義，但是因?yàn)樾枨笞兏蚱渌?，目前版本不用。這些接口雖

　　然不再使用，但有可能代碼并沒有及時(shí)刪除。如果利用技術(shù)手段調(diào)用這些接口，可能獲取額

　　外利益。

　　(2)接口設(shè)計(jì)合理性分析

　　接口定義是否合理可以從以下幾個(gè)方面分析：

　　(1)接口字段是否冗余;

　　(2)接口是否冗余;

　　(3)接口是否返回了調(diào)用方期望得到的信息;

　　(4)接口定義是否可滿足所有調(diào)用需求;

　　(5)接口定義調(diào)用是否方便。

后臺(tái)接口測(cè)試ui設(shè)計(jì)

　　什么情況下開展接口測(cè)試？

　　1.項(xiàng)目處于開發(fā)階段，前后端聯(lián)調(diào)接口是否請(qǐng)求的通?(對(duì)應(yīng)數(shù)據(jù)庫增刪改查)--開發(fā)自測(cè)

　　2.有接口需求文檔，開發(fā)已完成聯(lián)調(diào)(可以轉(zhuǎn)測(cè))，功能測(cè)試展開之前

　　3.專項(xiàng)測(cè)試：如測(cè)流量大小，查看圖片壓縮大小，測(cè)試接口請(qǐng)求響應(yīng)時(shí)間

　　4.版本上線前，進(jìn)行整體回歸測(cè)試，查看接口是否有異常(如404等)。對(duì)準(zhǔn)備上線的版本進(jìn)行抓包，查看服務(wù)器地址是都正確

　　5.版本功能穩(wěn)定后，接口自動(dòng)化

　　6.還可以應(yīng)用在安全測(cè)試，性能測(cè)試領(lǐng)域等。

　　以上這些是小編給大家介紹的后臺(tái)接口測(cè)試ui設(shè)計(jì)包括哪些以及什么情況下開展接口測(cè)試的相關(guān)內(nèi)容，ui設(shè)計(jì)比較復(fù)雜，涉及的內(nèi)容比較多。想了解更多相關(guān)信息，可以繼續(xù)留意我們的網(wǎng)站。