單元測試： 單元測試是測試中的最基本的測試， 也是測試中的最小單元， 它的物件是函式物件，也可以包含輸入輸出， 針對的是函式功能或者函式的內部邏輯方面。 並不包含業務邏輯
介面測試： 介面是拋開介面而說， 介面封裝了介面對使用者提供功能， 而介面測試則是拋開了介面對介面的封裝和整合（介面提供的乙個功能中可能包含了多個介面）。 針對乙個介面實現的功能以及介面內部邏輯進行測試。 有的介面功能單一，有的介面功能複雜， 針對功能複雜的介面，可以按照其功能點拆分測試。 另外，就是介面之間的依賴性。 如果只是進行介面測試，如果有介面依賴性問題， 最好的方法是提前準備測試資料。 不建議將介面關聯在一起測試。介面應該是業務邏輯的最小單元。 介面可能包含了內部邏輯測試和介面功能測試。 但是個人認為介面功能測試不能稱之為功能測試， 因為這些功能是抽象的， 或者業務功能的最小單元。 個人理解的功能測試，應該是業務上的功能， 而不是介面功能。 當然只有介面功能正確的實現了，我們才有可能去整合業務功能
整合測試： 將乙個模組或幾個模組拼接起來，從而實現了系統的某些功能。 這些功能可能包含了乙個完整或者不完整的業務功能，這時候我們進行的測試可以稱之為功能測試。 我們是站在使用者的角度上去驗證功能是否正確，是否滿足使用者需求或者設計初衷。 如果把所有的模組集中起來進行測試，個人理解就是系統測試。 當然，我只是從功能方面出發。
系統測試： 所有的模組整合形成乙個完成的。 如果介面定義完善，並且測試充分， 如果時間不充足的情況下， 可以跳過整合測試。 整合測試實際是系統測試的乙個子集。 會涵蓋一些系統測試覆蓋不到的邏輯。 既然系統覆蓋不到的邏輯， 自然不會呈現在使用者面前。 當然筆者只是假設時間不足的情況。 如果時間足夠， 還是要一層一層的進行測試。 盡可能早的發現問題。 自上而下，每乙個種測試都是下乙個測試的基石。
介面功能測試
所以有必要詳細和認真了解下怎麼開展對介面的功能測試。所以梳理了以下介面功能測試 知識點參考來自於 1 json格式測試 通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試 如果傳遞非json的情況，這時候程式會不會正確的處理，返回相應的 error code 2 預設值測試 很多情況一些非...
Fidder功能介紹 介面測試
一 fiddler工具介紹 fiddler 是乙個http協議除錯 工具 1 是位於客戶端和伺服器的http 它能記錄所有客戶端和伺服器的http和https請求響應，進行截獲 重發 編輯 轉存等操作。2 允許監視 設定斷點，甚至修改輸入輸出資料，fiddler包含了乙個強大的基於事件指令碼的子系統...
測試 功能測試
測試最基本的就是看介面展示是否正確這一類測試。但是，這類測試如果功能點多的情況下，如何有效測試就是乙個問題。1 詳略得當的測試用例，可以用mindmanager去做，也可以用excel等。2 光有測試用例是不夠的，還要根據測試資料，設計測試策略。如 測試的服務端的先後 測試賬號的先後 測試功能的先後...