大家好，今天小編來為大家解答webservice測試依據(jù)這個問題，webservice還有人用嗎很多人還不知道，現(xiàn)在讓我們一起來看看吧！
web測試的主要測試點
web測試主要包括的測試方面：
1、通用指標。指Web應用服務器、數(shù)據(jù)庫服務器必需測試項，包括：處理器時間：指服務器CPU占用率，一般平均達到70%時，服務就接近飽和。可用內(nèi)存數(shù)：如果測試時發(fā)現(xiàn)內(nèi)存有變化情況也要注意，如果是內(nèi)存泄露則比較嚴重。物理磁盤讀寫時間。
2、Web服務器指標。平均每秒響應次數(shù)為總請求時間與秒數(shù)之比。平均每秒業(yè)務腳本的迭代次數(shù)。成功的請求和失敗的請求。成功的點擊次數(shù)和失敗的點擊次數(shù)。每秒點擊次數(shù)、每秒成功的點擊次數(shù)和每秒失敗的點擊次數(shù)。嘗試連接數(shù)。
3、數(shù)據(jù)庫服務器指標。用戶連接數(shù)，也就是數(shù)據(jù)庫的連接數(shù)量。數(shù)據(jù)庫死鎖量。數(shù)據(jù)庫緩存的命中情況。
webservice如何判斷是否發(fā)布成功
輸入測試地址，無報錯即為發(fā)布成功
如何評估數(shù)據(jù)適不適合放入Redis中
當項目中引入了Redis做分布式緩存，那么就會面臨這樣的問題：
哪些數(shù)據(jù)應該放到緩存中？依據(jù)是什么？緩存數(shù)據(jù)是采用主動刷新還是過期自動失效？如果采用過期自動失效，那么失效時間如何制定？正好這兩周我們項目做了相關的評估，把過程記錄下來和大家分享分享；當然過程中用到了很多“笨辦法”，如果你有更好的辦法，也希望能分享給我。
01.項目背景我們的項目是一個純服務平臺，也就是只提供接口服務，并沒有操作頁面的，項目的接口日調(diào)用量大約在200萬次，高峰期也就1000萬出頭，因為大部分接口是面向內(nèi)部系統(tǒng)的，所以大部分請求集中在工作日的9點到21點，高峰期的時候系統(tǒng)的QPS在300-400之間。
因為我們項目數(shù)據(jù)存儲使用的是MongoDB，理論上支撐這個量級的QPS應該是綽綽有余，但是我有這么幾點觀察和考慮：
MongoDB中雖然是整合好的數(shù)據(jù)，但是很多場景也不是單條查詢，夸張的時候一個接口可能會返回上百條數(shù)據(jù)，回參報文就有兩萬多行（不要問我能不能分頁返回......明確告訴你不能）；
MongoDB中雖然是整合好的數(shù)據(jù)，但是很多場景也不是單條查詢，夸張的時候一個接口可能會返回上百條數(shù)據(jù)，回參報文就有兩萬多行（不要問我能不能分頁返回......明確告訴你不能）；
目前項目99.95%的接口響應時間都在幾十到幾百毫秒，基本可以滿足業(yè)務的需要，但是還是有0.05%的請求會超過1s響應，偶爾甚至會達到5s、10s；
觀察這些響應時間長的請求，大部分時間消耗在查詢MongoDB上，但是當我將請求報文取出，再次手動調(diào)用接口的時候，依然是毫秒級返回；MongoDB的配置一般，時刻都有數(shù)據(jù)更新，而且我觀察過，響應時間長的這些接口，那個時間點請求量特別大；
MongoDB查詢偶爾會慢的原因我我還在確認，我現(xiàn)在能想到的原因比如：大量寫操作影響讀操作、鎖表、內(nèi)存小于索引大小等等，暫時就認為是當時那一刻MongoDB有壓力；我觀察過，響應時間長的這些接口，那個時間點請求量特別大，這一點就不在這里具體分析了。
雖然一萬次的請求只有四五次響應時間異常，但是隨著項目接入的請求越來越大，保不齊以后量變產(chǎn)生質(zhì)變，所以還是盡量將危機扼殺在搖籃里，所以果斷上了Redis做分布式緩存。
02.接口梳理下一步就是對生產(chǎn)環(huán)境現(xiàn)有接口進行統(tǒng)計和梳理，確定哪些接口是可以放到緩存中的，所以首先要對每一個接口的調(diào)用量有大概的統(tǒng)計，因為沒有接入日志平臺，所以我采用了最笨的辦法，一個一個接口的數(shù)嘛。
把工作日某一天全天的日志拉下來，我們四臺應用服務器，每天的日志大概1個G，還好還好；
通過EditPlus這個工具的【在文件中查找】的功能，查詢每個接口當天的調(diào)用量，已上線30個接口，有幾分鐘就統(tǒng)計出來了，反正是一次性的工作，索性就手動統(tǒng)計了；
一天也調(diào)不了幾次的接口，就直接忽略掉了，我基本上只把日調(diào)用量上萬的接口都留下來，進行下一步的分析。
03.字典表、配置類的數(shù)據(jù)這一類的數(shù)據(jù)是最適合放在緩存中的，因為更新頻率特別低，甚至有時候insert了之后就再也不做update，如果這類數(shù)據(jù)的調(diào)用量比較大，是一定要放到Redis中的；
至于緩存策略，可以在更新的時候雙寫數(shù)據(jù)庫和Redis，也可以采用自動失效的方式，當然這個失效時間可以放得比較長一些；針對我們項目，我采用的是半夜12點統(tǒng)一失效的策略，第一因為我們系統(tǒng)這類數(shù)據(jù)，是夜間通過ETL抽取過來的，每天同步一次，第二就是我們不怕緩存雪崩，沒有那么大的訪問量，夜間更沒有什么訪問量了。
04.明顯是熱點數(shù)據(jù)的數(shù)據(jù)有一類數(shù)據(jù)，很明顯就是熱點數(shù)據(jù)；
我們就有一個接口，雖然是業(yè)務數(shù)據(jù)，不過數(shù)據(jù)總量只有幾千條，但是每天的調(diào)用量大約在40萬，而且更新頻率不是很高，這類數(shù)據(jù)放入Redis中也就再適合不過了；至于緩存策略么，因為數(shù)據(jù)也是從其他系統(tǒng)同步過來的，根據(jù)數(shù)據(jù)同步的時間，我們最終采用一個小時的失效時間。
05.其余數(shù)據(jù)的評估
其實前兩種數(shù)據(jù)很容易就能評估出來，關鍵是這類數(shù)據(jù)的評估：
我們有一個接口日調(diào)用量20-30萬，量不大，但是查詢和處理邏輯比較復雜；
基礎數(shù)據(jù)量太大，無法把所有數(shù)據(jù)都放入Redis中；
無法把基礎數(shù)據(jù)直接放入Redis中，因為有多重查詢維度（條件）；
無法確定每條數(shù)據(jù)的調(diào)用頻率是怎么樣的，最悲觀的結果，每條數(shù)據(jù)當天只調(diào)用一次，這樣就沒有緩存的必要了。
但是咱也不能一拍腦袋就說：“調(diào)用量挺大的，直接放到Redis中吧”，或者“不好評估，算了吧，別放緩存了”，做任何一個決定還是需要有依據(jù)的，于是我是這樣做的：
Step1.把該接口當天的所有日志都找出來
幾十個日志文件肯定不能一個一個翻，要么就自己寫個程序把需要的數(shù)據(jù)扒出來，但是考慮到這個工作可能只做一次，我還是盡量節(jié)省一些時間吧。
依然使用EditPlus這個工具的【在文件中查找】的功能，在查詢結果框中【復制所有內(nèi)容】，花了兩分鐘，就把24萬條日志找出來了。
Step2.把數(shù)據(jù)導入到數(shù)據(jù)庫中進行下一步分析每一條日志大概是這樣的：
XXXX.log"(64190,95):2020-3-1716:44:10.092http-nio-8080-exec-5INFO包名.類名:請求參數(shù):args1={"字段1":"XXX","字段2":"YYY"}日志里面我只需要三個內(nèi)容：請求報文中的字段1和字段2，以及調(diào)用時間；怎么摘出來？寫個程序？當然沒問題，但是我懶呀，幾分鐘能做好的事情為什么話花幾十分鐘呢？而且這工作是一次性的，于是：
全文替換：[2020-3-17]替換成[/t2020-3-17]，也就是在時間戳前面加一個tab；
全文替換：[{"字段1":"]替換成[/t];
全文替換：[","字段2":"]替換成[/t];
全文替換：["}]替換成[]，也就是替換成空;
全選復制，粘貼到excel中，excel自動按照tab換列；
刪除不需要的列，只留字段1和字段2的內(nèi)容，以及時間戳；
這幾步操作用不了一分鐘。
Step3.調(diào)用頻率分析
當把數(shù)據(jù)進入到數(shù)據(jù)庫中，就根據(jù)我們的需要進行分析了；我們主要想知道，相同的入?yún)粫貜驼{(diào)用？每次調(diào)用間隔的時間是多少？一個SQL搞定：
當然調(diào)用間隔時間的統(tǒng)計，這里統(tǒng)計的不精確，具體我不解釋了，你們細品...
總之吧，全天24萬的調(diào)用量，其中10萬只調(diào)用了一次，14萬的數(shù)據(jù)會在短時間內(nèi)重復調(diào)用，有一些數(shù)據(jù)甚至會在幾分鐘之內(nèi)重復查詢幾十次，所以這個接口還是比較適合放入到Redis中的。
Step4.數(shù)據(jù)怎么存？
再說說我們的數(shù)據(jù)用什么格式保存到Redis中，一圖勝千言：
至于緩存更新策略嘛，我們依然使用設置失效時間的方式，根據(jù)數(shù)據(jù)同步的時間和調(diào)用統(tǒng)計結果，這個時間設置成15分鐘比較合適。
可以看到在這個評估過程中，我所有操作都保持了“能偷懶就偷懶”這個好習慣，保持高效，善用工具，節(jié)約不必要的時間，全部過程花了兩個小時，其中大部分時間是在數(shù)據(jù)導入，幾乎用了一個半小時，還好在這個過程中我還能做其他的工作。
我將持續(xù)分享Java開發(fā)、架構設計、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關注。web服務的5個步驟
包括服務的開發(fā)，測試，注冊，運行與調(diào)用。
okhttp測試工具是什么
是一個開源測試工具，通過soap/http來檢查、調(diào)用、實現(xiàn)WebService的功能/負載/符合性測試。
該工具既可作為一個單獨的測試軟件使用，也可利用插件集成到Eclipse，maven2.X，Netbeans和intellij中使用。把一個或多個測試套件組織成項目，每個測試套件包含一個或多個測試用例，每個測試用例包含一個或多個測試步驟，包括發(fā)送請求、接受響應、分析結果、改變測試執(zhí)行流程等。
關于webservice測試依據(jù)，webservice還有人用嗎的介紹到此結束，希望對大家有所幫助。
