根據資料和經驗總結。
要求：命名：
命名規則和風格統
一、規範；
命名清晰明確，不冗餘，不模糊；
有意義：清晰和有意義的命名比簡略而模糊的命名更應受到青睞；
功能職責明確：功能盡量單一；
充分理由：不要隨便有新功能就增加新介面；無意義的介面只會增加維護的難度；
將功能層和策略層分開：
功能是基礎資料，不易變；
策略是表層資料，易變——策略可以使用
引數修改；
低耦合：減少不同介面間的依賴。
乙個介面不應隨著另乙個介面的變化而變化；
乙個介面不應以某幾個介面為前提而存在。
完備性：
考慮各種引數變化的情況；
考慮各種引數為
default或為0
的情況；
可擴充套件性：為以後可能會增加的引數預留餘地，盡量不要寫死；
引數不超過5個；
從做到右，按照引數容易變化的程度排列；
盡量提供預設值；
若超過5
個，把相似的資料放入到乙個
json
或list
等資料結構中；
禁止隨意擴充套件：理由見「功能」部分；
引數盡量是原生資料結構，少用對平台依賴的資料結構。
分析角度：明確角度，不要一會以角色設計，一會以功能設計。
必要資訊：
初始資訊
初始化是否完畢
初始化完畢後的基本資訊（如：
list
或dict
的長度——可以看出是否為0）
中間資訊
資料來源是否變動
資料長度是否改變（需要視重要程度決定是否需列印該資訊）
返回資訊
是否成功？
失敗原因？
如何設計介面？
眾所周知，介面是提供給其他模組或者系統使用的一種約定或者規範。因此介面必須要保 證足夠的穩定性和易用性。這是設計介面的基本要求。介面必須相對穩定，否則將導致介面的使用者和提供者為了適應新介面而不斷修改介面 的實現，可能重複進行無用功，嚴重時影響整個軟體開發進度。那麼如何保證設計的介面相 對穩定呢？首...
如何進行介面測試？如何設計介面測試用例？
1 引數入參型別校驗 入參型別與介面文件保持一致。2 引數必填項校驗 必填項不為空 null 3 引數長度 a 介面文件記錄的資料庫長度 b 需求文件要求的字段長度 4 引數取值範圍 a 列舉值，需校驗每個列舉值。特別是不同列舉值對應不同場景的情況 b 有限定範圍，可用邊界值進行設計測試用例。如密碼...
介面測試如何設計測試用例
介面測試一般考慮入參形式的變化和介面的業務邏輯,一般設計介面測試用例採用等價 類邊界值 場景法居多 介面測試設計測試用例的思路如下 1 介面業務邏輯測試?正例 介面邏輯測試是指根據業務邏輯 輸入引數 輸出值的描述,對正常輸入情況下 所得的輸出值是否正確的測試,也就是測試對外提供的介面服務是否正常工作...