最近又有乙個專案完成，終於得空可以寫寫**，探索一下介面測試的奧秘。
由於筆者也是第一次嘗試寫介面自動化的指令碼，以前一直停止於ui自動化的層面，ui自動化響應時間慢，取元素之難，也是讓人嘆為觀止，雖然推出了各種優化工具，比如說，cucumer，rf等等的一些工具，簡化了ui自動化的難度，但是乙個iframe的修改從而引起不斷的調整頁面元素，甚至於一大段**重寫還是讓人難以避免，這也是筆者前段時間寫著寫著就不想寫的原因，付出與回報確實不成正比。
然後筆者時常需要到客戶現場做效能測試，從而接觸到了jmeter，使用jmeter進行壓力測試，也知道了壓力測試的核心，是對介面進行施壓，進而觀察記憶體、cpu、io等情況，對系統進行全方位的優化，把併發數從20推送到了100，也算是小有成就，然後想著用jmeter來實現介面自動化，卻發現好雖好，但是畢竟是壓力測試工具，是無法實現介面的聯動性的。我們正常工作的時候，會發現乙個問題，開發改動了乙個地方的**，從而引起了其他地方的**的變化，導致了線上bug的爆發，無口厚非，這個與架構師的架構師脫不開關係的，但是作為測試，卻也有難以逃脫的責任。然後筆者就放棄了jmeter，從而走向了介面測試的核心，httpclient
從應用層走向底層，果然是需要勇氣的，筆者封裝好了取介面的httpclient的**，又在設計模板，讀取excel的模板，並生成excel的測試報告，然後到了excel的時候，筆者想到，後台開發同學的**提交的時候是否每次可以寫上介面的名字，這樣，他們修改了**，我們也能從介面中獲知，到底涉及到了多少模組，甚至於說介面自動重新跑一邊。這個對於目前的專案或者我來說，可能是乙個前進的方向，筆者前段時間設想著取介面的方法，後來終於大徹大悟，明白了介面如何獲取，原先的想法是在伺服器端用**取到經過網絡卡的介面，從而捕捉到介面存放起來，當然，這是一條最為保險的方法，可惜實施起來，發現難度太大了，各種**分析完之後，卻未能實現一點點突破。然後筆者卻看到了開發同學的debug的日誌，發現其中有很多的.do內容，筆者立刻想到是不是開發同學所有寫的介面都會經過debug列印到日誌中的，後來發現開發同學確實是有這個習慣的，那麼，此時，監控網絡卡就變成了日誌分析，還有就是通過頁面分模組直接取介面，從兩方面來實現介面內容的完整性，這樣會比監控網絡卡更簡便點。更直接的，監控會不會影響伺服器的效能，這也是很大的問題。
介面測試 介面自動化測試
1 介面自動化到底關注哪些點？a.關注函式 類 方法 所提供的介面的可靠性 b.關注介面之間銜接的可靠性 c.關注介面引數的校驗 2 介面有哪幾種型別？a.http協議中 get post put delete input方法 b.目前自動化工具提供的有get和post兩種方法 3 用介面實現自動化...
介面測試自動化
前端介面向後端傳送api介面 api 可以理解為資料傳輸的通道 後端把 http請求的響應返回給前端 介面測試的工作流程 準備階段 拿到開發的介面文件 了解每個介面的引數及含義 了解被測試系統的業務流程 編寫介面測試用例 執行階段 測試用例 測試場景執行 測試資料 系統資料收集 分析階段 資料彙總 ...
UI自動化測試 介面測試等自動化測試策略
今天跟大家介紹ui測試 介面測試 單元測試主要內容，以及每種測試花費時間討論。ui測試 selenium ui測試是最接近軟體真實使用者使用行為的測試型別。通常是模擬真實使用者使用軟體的行為，即模擬使用者在軟體介面上的各種操作，並驗證這些操作對應的結果是否正確。介面測試 api測試 api測試，主要...