原创 隊頭阻塞

隊頭阻塞 請求 - 應答 模式加劇了 HTTP 的性能問題,這就是著名的“隊頭阻塞”(Head-of-line blocking)。 當順序發送的請求序列中的一個請求因爲某種原因被阻塞時,在後面排隊的所有請求也一併被阻塞,會導致客戶端遲遲收

原创 網址的組成

URL的組成部分scheme:方案名 或者 協議名,比如http、https、ftp等host:主機名,可以是IP,或者域名port:端口號,有時候可以省略,瀏覽器等客戶端會依據 scheme 使用默認的端口號,例如 HTTP 的默認端口號

原创 HTTP的請求方法

常用的方法:gethead服務器不會返回請求的實體數據,只會傳回響應頭。可以看做是get方法的簡化版”或者“輕量版”,因爲它的響應頭與get完全相同。可以用在很多並不真正需要資源的場合,避免傳輸 body 數據的浪費。場景1:要檢查一個文件

原创 HTTP的請求和響應

HTTP 協議的請求報文和響應報文的結構基本相同: 起始行(start line) 頭部字段集合(header) 消息正文(entity) 其中,前兩部分又經常被合稱爲:請求頭 或者 響應頭 報文必須有 header,但可以沒有 bod

原创 Appium Desktop錄製測試用例

錄製的腳本,可以拷貝到文件,用Pycharm打開加了一個隱式等待 This sample code uses the Appium python client pip install Appium-Python-Client The

原创 Appium生態工具集合

adb命令 Appium Desktop:內嵌了Appium Server和Inspector的綜合工具 Appium Server:Appium的核心,命令行工具 Appium Clients:各種語言的客戶端封裝庫,用於連接Appiu

原创 查看端口是否被佔用

查看本機端口是否被佔用: netstat -ano | findstr "端口號" 找到該端口,看一下最後一列,是進程號pid 然後, tasklist | findstr "pid" 如果要殺掉,taskkill /T /F /PI

原创 HTTP筆記2

TCP/IP協議棧 OSI七層模型 七層 和 四層 的對應 關係 四層負載均衡所謂的“四層負載均衡”就是指工作在傳輸層上,基於 TCP/IP 協議的特性,例如 IP 地址、端口號等實現對後端服務器的負載均衡。 七層負載均衡所謂的“七層

原创 adb devices中查不到iTools android模擬器

adb devices中查不到iTools android模擬器 解決辦法:由於iTools android模擬器的ADB端口號是54001,所以在cmd中輸入“adb connect 127.0.0.1:54001”後,再輸入“adb d

原创 mysqlclient 1.3.13 or newer is required

Django開發,由sqlite3切換爲mysql已經僞裝過了, 遷移時,報錯:django.core.exceptions.ImproperlyConfigured: mysqlclient 1.3.13 or newer is req

原创 網站可擴展性架構設計

可擴展性:網站的架構設計能夠快速適應需求的變化,當需要增加新的功能實現時,對原有架構不需要做修改或者做很少的修改就能夠快速滿足新的業務需求。

原创 網站高性能架構設計

包含兩部分: 1.前端性能其本質就是通過各種技術手段去優化用戶實際感受到的前端頁面展現時間。 前端性能優化的方法是相對標準的,工具如PageSpeed、Yslow等,都能系統性地分析前端的性能問題,並給出對應的解決方案建議。 2.後端性能0

原创 性能測試調優案例

現象:100併發壓測時,發現cpu的sy值,loadaverage值比較高 備註:load average(負載):一段時間內,cpu正在處理 + 等待cpu處理 的進程數之和可以使用top命令查看1分鐘、5分鐘、10分鐘 一般關注5分鐘、

原创 網站伸縮性架構設計

可伸縮性:通過簡單地增加硬件配置而使服務處理能力呈線性增長的能力。比如:通過在應用服務器集羣中增加更多的節點,來提高整個集羣的處理能力。 網站的可伸縮性架構設計主要包含兩個層面的含義: 1.根據功能進行物理分離來實現伸縮2.物理分離後的單一

原创 測試工程師要懂網站架構設計

1.很多時候需要針對互聯網的架構來設計有針對性的測試2.另外對於互聯網的壓力測試以及結果分析也需要對架構知識有比較清楚的認識 #舉例:1.基於消息隊列的分佈式系統測試設計 01:可以從黑盒的角度,不考慮消息隊列02:正常情況下,A系統把數據