python爬蟲蟲師
Ⅰ 《Selenium2自動化測試實戰基於python語言》epub下載在線閱讀全文,求百度網盤雲資源
《Selenium 2自動化測試實戰》(蟲師)電子書網盤下載免費在線閱讀
鏈接: https://pan..com/s/10-u3cNcxi8pZlq2FEpkv4A
書名:Selenium 2自動化測試實戰
作者:蟲師
豆瓣評分:8.1
出版社:電子工業出版社
出版年份:2016-1-1
頁數:324
內容簡介:
《Selenium 2自動化測試實戰——基於Python語言》共分 14 章。第 1 章是自動化測試相關基礎知識的介紹;第 2 章到第 10 章是《Selenium 2自動化測試實戰——基於Python語言》的重點,循 序漸進地介紹了自動化測試所用到的技術;第 11 章通過一個具體的項目綜合運用了前面章節所介紹 的技術與技巧;第 12 章到第 14 章選取了當前最熱門的技術進行了介紹,旨在擴展測試人員的綜合技 術能力。 《Selenium 2自動化測試實戰——基於Python語言》的寫作目的並不是為了簡單地告訴讀者如何使用一個自動化測試工具,而是希望讀者在學習
《Selenium 2自動化測試實戰——基於Python語言》的內容後能夠提高綜合的技術高度與寬度,從而擺脫簡單的手工測試,向高級測試工程師的道路 邁進。
Ⅱ 【網路爬蟲教學】蟲師終極武器之Chromium定製開發系列(六)
Hi,大家好,歡迎大家觀看由IT貓之家打造的【網路爬蟲教學】蟲師終極武器之Chromium定製開發系列教學文章的第六篇,如果您是第一次觀看本系列教程,請先移步到 這里 看完前面的文章後再回來哦!大家在學習的過程中,有任何疑問可以留言或加入我們的QQ技術交流群進行探討: 544185435
前言
前面我們已經實現了多個FP重點檢測對象的介面隨機化,事實上只要完成這些介面的重寫就足以應付大多網站了,不過我們既然要定製就做足全套吧,在FP檢測腳本中,尚且還有一些也算是較為重要的判斷依據,如:系統字體檢測、瀏覽器插件(plugins) 檢測、以及非人為觸發事件檢測isTrusted等。
FontStyle 隨機化的實現
由於每台設備的字體可能存在差異等原因使得第三方服務可以輕松的通過獲取字體來判斷請求的客戶端是否為同一客戶端,我們知道Chromium為了規避安全的風險,不對JS提供太多的可用許可權,比如字體讀取,JS本不具備這種檢測許可權,但FP巧妙的利用了字體的(長、寬、描邊)等屬性來精確的判斷出客戶端是否包含了哪些字體,最終導出一串哈希值以便於作為有力的憑證,另除了這種方式,FP還通過Flash介面來調用字體進行判斷(需瀏覽器支持)
對於系統字體介面的隨機,我們可以從傳入的font-Style著手,在之前的Canvas隨機方案中,我們有做過類似的操作,就直接篡改傳入的Style,而對於字體我們也是可以這么乾的,只需將其替換成指定的字體即可。
要想實現該介面的隨機化,我們首先得要搞懂網站對這個介面的檢測是如何實現的以及它是如何運作的,而最好最直接的方法就是直接從目標網站分析並找到答案,我們可以打開 browserleaks 然後在關鍵處下斷點,從上圖我們可以看到它預設了一堆的常見字體。
從上圖,我們可以看到一串:mmm₹▁₺ꜽ�₸׆ẞॿmmmmmmmlli 這樣的字元,在我接觸過的腳本中它們都會以這種形式作為檢測的基準,至於為何一定要用這給字元串,大家可以參考下這篇文章,這位大佬已經解釋得很清楚: JavaScript/CSS Font Detector | JavaScript / CSS 字體檢測器
從圖中我們可以看出,它每次循環都會通過介面style.fontFamily來為當前標簽設置字體並獲取其寬度與高度,進而與原始的字體進行一一比對,一旦不相等則表示該字體存在,通過該方法幾乎可以100%的測得准確結果,而我們要想實現該介面的隨機化,可以考慮從兩個點著手,首先,就像前面說的,介面每次都會通過 style.fontFamily 來設置字體,那麼我們完全可以在這里進行篡改,只要保證每次傳入的字體都不一致,則表示肯定會與結果有出入從而達到了隨機化的目的,其二,既然它是通過字體的寬度與高度來判斷是否成立的,那麼我們也可以hook該介面返回隨機偏移的數值,從而達到隨機化的目的。
通過API查詢,我們可以很方便的找到該介面的路徑,我們只需按自己的需求實現隨機化即可,在這,我建議大家直接修改它的頭文件,因為我嘗試修改cc文件並未成功,當然大家也可以自行嘗試,萬一是我操作姿勢不對呢,啊哈哈….
plugins 介面隨機化的實現
事實上,單單依賴這個插件指紋,服務端是無法判斷出是否同一客戶端的,也就是說只要完成前面的所有指紋偽造,基本上可以瞞天過海了,但為了滿足部分強迫症的看官,我還是有必要將這個給拉出來講解了。
我們直接在控制台中輸入:navigator.plugins,來看看這個插件到底包含了什麼
我們可以看到,基本上 navigator.plugins 的子項包含了:四個欄位以及2個對象(事實上是一個對象),而事實上我們瀏覽器里的這個對象基本上都是一樣的,所以我開頭說可以忽略掉這個介面,我們可以查看每個子項,可以發現它的欄位是一樣的,同樣包含了: name、 filename 、 description 、 MimeType ;那麼這樣就好辦了,直接從以上的欄位著手即可。
通過API查詢,我們定位到這個 navigator.plugins 的介面位於:third_party\blink\renderer\moles\plugins目錄下,我們只需對其實現隨機化即可。
上圖是插件隨機化後的效果,經過篡改:String DOMPlugin::name()、String DOMPlugin::filename()、String DOMPlugin::description()我們可以很輕松的便實現了該介面的隨機化。
介面事件觸發之底層篡改大法
在FP腳本檢測的過程中,還有一項作為檢測最為重要的評判指標 「isTrusted」,之所以將它留到最後講,是為了體現它的價值與其重要性,該欄位通常會出現在事件被觸發的時,它也是唯一的一個不可直接通過JS語法進行篡改的欄位,也就是說前面介紹的所有介面其實我們都是可以通過JS去篡改的,(篡改是沒問題,但不見得一定能用,因為部分網站是有針對這個進行檢測的),而這個 「isTrusted 」則是例外。
我們來看看上圖,我們隨便定義了一個滑鼠事件以及坐標的事件,然後我們可以發現,它們都攜帶了一個「 isTrusted 」的欄位,並且它的值為false,通過上圖我們可以發現,這個介面並不能重寫,因為它是只讀的,覆蓋不了,而我也有嘗試過在茫茫網海中尋找可通過JS改寫的方案,最終都以失敗告終,當然,也有老外告訴我,它們可以通過配合擴展插件去實現,但必須得藉助debugger來實現,並且無法取消彈窗,而這方法我也嘗試過,是成功了,但是及其耗資源,所以我才打算將其以基於底層的方式實現。
我們再來看看真實觸發事件的情況,我們從上圖中可以看出,當我們以真實滑鼠去觸發它, 「 isTrusted 」 是為真的,而部分網站以該欄位作為判斷的依舊,從而判斷你是否為機器人;事實上這個介面並不屬於是否同一客戶端的判斷范疇,而是為了校驗客戶端是否人為發起的請求。
Event 介面的isTrusted是一個 Boolean 類型的只讀屬性.當事件由用戶操作生成時為true,由腳本創建或修改,或通過調用 EventTarget.dispatchEvent 生成,為false;從這里我們可以看到通過腳本創建或者修改的都會返回false,從而我們可以更加肯定這個欄位是肯定會被網站作為重要的判斷依舊的。
通過API我們順藤摸瓜的找到了介面的路徑,並將其篡改為true,而,因為所有的事件(如:MouseEvent、PointEvent) 都是派生與event ,所以一旦在其根源修改了,所有的事件都勢必會返回真,從而達到我們想要的目的。
最後,附上一張篡改後的效果圖,以表示成功。
作者寄語
感謝大家一直閱讀本系列文章,到本文為止,我們已經實現了FP里的大部分檢測,而通過這些屬性的偽造,我們已經可以在大部分網站上執行了,而由於介面都是隨機的,所以網站無法確認是否為同一客戶端,從而達到了真正的匿名效果;但部分網站還是採用的Cookie形式來記錄的,所以,我們也可以通過隱身模式或者通過第三方擴展來屏蔽。另外,請大家不要再私下問我怎麼不完全把介面暴露出來,之類的話,首先,一旦方法暴露,勢必會遭到第三方網站進行特徵收集,沒有什麼是絕對的,收集過多的數據,照樣可以判斷你是機器人,或者直接屏蔽你的瀏覽器,其二,研究是需要時間與精力的,如果大家都是抱著做伸手黨的心思來討要結果,那麼您可能找錯方向了,天天研究頭發都白了,你伸下手就想要,有這么好的事歡迎留言告訴我,我也想要;最後如果大家有業務需求可以找我合作,JS逆向或瀏覽器定製均可。
Ⅲ Python寫靜態HTML
因為近期工作需要,常常要將測試結果/數據統計、匯總和展示,因此會有寫靜態HTML的需求,本文記錄下python寫靜態HTML的小技巧
靈感時來源於unittest測試框架最常用的報告插件: HTMLTestRunner ,該插件本身基於python2且已經更新了,好在 @蟲師 一直在維護和更新這個插件,使得它能繼續被大家所使用,了解詳情請移步: SeldomQA/HTMLTestRunner
回到HTMLTestRunner報告插件,閱讀源碼發現,作者只用了一個python文件便巧妙的將寫HTML、頁面繪制和數據嵌入搞定了。進一步分析可以看到,作者先是在Template基類中定義了測試報告的HTML結構模板和各個模塊/表格模板,然後再以格式化輸入的形式給每一個模板中填充目標數據,再將填充好的模板以格式化輸入的形式填充到HTML結構模板中,最後再將所有內容寫成一個HTML文件即可。
可以看到,這樣的設計其實優點在於非常小巧和輕量,缺點在於可維護和可移植性差,數據量小還尚可,不太適合大量數據的統計和繪制。
這種設計的關鍵在於建模板,然後 按需 填充數據,最後再寫HTML,通常我的做法是:
Ⅳ 【Python】【壓力測試】Locust壓力測試工具
性能測試參數
熟悉 Apache ab 工具的同學都知道,它是沒有界面的,通過命令行執行。 Locust 同樣也提供的命令行運行,好處就是更節省客戶端資源。
啟動參數:
--no-web 表示不使用Web界面運行測試。
-c 設置虛擬用戶數。
-r 設置每秒啟動虛擬用戶數。
-t 設置設置運行時間。
出現的報錯及解決辦法:
使用Locust進行性能測試,Locust no-web模式執行命令locust -f zkxl_verify_ locust.py --host= https://www..com --no-web -c 10 -r 2 -t 1m
提示locust: error: unrecognized arguments: --no-web -c
參考locust官方文檔 https://docs.locust.io/en/latest/running-locust-without-web-ui.html?highlight=no-web
將命令參數--no-web 更改為 --headless,將命令中指定用戶並發數的參數 -c 改為 -u,即更改命令為:locust -f zkxl_verify_ locust.py --host= https://www..com --headless -u 10 -r 2 -t 1m 即可.
locust的測試數據可以保存到CSV文件中,有兩種方法可以進行此操作:
首先,通過Web UI運行Locust時,可以在「Download Data」選項卡下得到CSV文件。
其次,可以使用標簽運行Locust,該標簽將定期保存兩個CSV文件。如果計劃使用--no-web標簽以自動化方式運行Locust
文件將被命名為example_response_times.csv 和 example_stats.csv (使用--csv=example)並記錄Locust構建的信息。
如果你想要更快(慢)的寫入速度,也可以自動以寫入頻率:
此數據將寫入兩個文件,並將_response_times.csv和_stats.csv添加到你提供的名稱中:
和
打開命令提示符(或Linux終端),輸入 locust --help 。
參考: 官方文檔
一旦單台機器不夠模擬足夠多的用戶時,Locust支持運行在多台機器中進行壓力測試。
為了實現這個,你應該在 master 模式中使用 --master 標記來啟用一個 Locust 實例。這個實例將會運行你啟動測試的 Locust 交互網站並查看實時統計數據。master 節點的機器自身不會模擬任何用戶。相反,你必須使用 --slave 標記啟動一台到多台 Locustslave 機器節點,與標記 --master-host 一起使用(指出master機器的IP/hostname)。
常用的做法是在一台獨立的機器中運行master,在slave機器中每個處理器內核運行一個slave實例。
在 master 模式下啟動 Locust:
在每個 slave 中執行(192.168.0.14 替換為你 msater 的IP):
參數
--master
設置 Locust 為 master 模式。網頁交互會在這台節點機器中運行。
--slave
設置 Locust 為 slave 模式。
--master-host=X.X.X.X
可選項,與 --slave 一起結合使用,用於設置 master 模式下的 master 機器的IP/hostname(默認設置為127.0.0.1)
--master-port=5557
可選項,與 --slave 一起結合使用,用於設置 master 模式下的 master 機器中 Locust 的埠(默認為5557)。注意,locust 將會使用這個指定的埠號,同時指定埠+1的號也會被佔用。因此,5557 會被使用,Locust將會使用 5557 和 5558。
--master-bind-host=X.X.X.X`
可選項,與 --master 一起結合使用。決定在 master 模式下將會綁定什麼網路介面。默認設置為*(所有可用的介面)。
--master-bind-port=5557
可選項,與 --master 一起結合使用。決定哪個網路埠 master 模式將會監聽。默認設置為 5557。注意 Locust 會使用指定的埠號,同時指定埠+1的號也會被佔用。因此,5557 會被使用,Locust 將會使用 5557 和 5558。
--expect-slaves=X
在 no-web 模式下啟動 master 時使用。master 將等待X連接節點在測試開始之前連接。
如下圖,我啟動了一個 master 和兩個 slave,由兩個 slave 來向被測試系統發送請求。
client屬性:
TaskSet類:實現了虛擬用戶所執行任務的調度演算法,包括規劃任務執行順序(schele_task)、挑選下一個任務(execute_next_task)、執行任務(execute_task)、休眠等待(wait)、中斷控制(interrupt)等等。
在此基礎上,我們就可以在TaskSet子類中採用非常簡潔的方式來描述虛擬用戶的業務測試場景,對虛擬用戶的所有行為(任務)進行組織和描述,並可以對不同任務的權重進行配置。
在TaskSet子類中定義任務信息時,可以採取兩種方式, @task 裝飾器和 tasks 屬性。
@task(1)中的數字表示任務的執行頻率,數值越大表示執行的頻率越高
採用tasks屬性定義任務:
tasks = {test_job1:1, test_job2:2}中,test_job1:1,test_job2:2表示事件執行的頻率,即test_job2的執行頻率是test_job1的兩倍
on_start函數是在Taskset子類中使用比較頻繁的函數。在正式執行測試前執行一次,主要用於完成一些初始化的工作。
例如,當測試某個搜索功能,而該搜索功能又要求必須為登錄態的時候,就可以先在on_start中進行登錄操作,HttpLocust使用到了requests.Session,因此後續所有任務執行過程中就都具有登錄態了
在TaskSequence類中,[email protected]_task()可以用來控制任務的執行順序;裡面的數值越小執行越靠前;
在Taskset類中,內置WAIT_TIME功能,它用於確定模擬用戶在執行任務之間將等待多長時間。Locust提供了一些內置的函數,返回一些常用的wait_time方法。
1、 between(min,max)函數 :用得比較多的函數
wait_time = between(3.0, 10.5):任務之間等待的時間是3到10.5秒之間的任意時間
還可以用任意函數來定義等待時間, 比如平均1秒的等待時間
wait_time = lambda self: random.expovariate(1) 1000
2、 constant(number) 函數:
wait_time=constant(3):任務之間等待的時候是3秒鍾,且等待的時候不能超過任務運行的總時間,也就是在執行py文件時設置的時間
3、 constant_pacing(number) *函數:
wait_time=constant_pacing(3):所以任務每隔3秒執行,但是當到達運行的總時間時,任務運行結束;
現實中有很多任務其實也是有嵌套結構的,比如用戶打開一個網頁首頁後,用戶可能會不喜歡這個網頁直接離開,或者喜歡就留下來,留下來的話,可以選擇看書、聽音樂、或者離開;
在有Taskset嵌套的情況下,執行子任務時, 通過 self.interrupt() 來終止子任務的執行, 來回到父任務類中執行, 否則子任務會一直執行;
在上一頁的案例中,在stay這個類中,對interrupt()方法的調用是非常重要的,這可以讓一個用戶跳出stay這個類有機會執行leave這個任務,否則他一旦進入stay任務就會一直在看書或者聽音樂而難以自拔。
在進行介面多用戶並發測試時,數據的重復使用可能會造成腳本的失敗,那麼需要對用戶數據進行參數化來使腳本運行成功。
已登錄功能為例:
創建 login_user() 方法,定義登錄字典 users , 通過randint 隨機獲取字典中的用戶數據。
在 login() 登錄任務中,調用 login_user() 方法實現 隨機用戶的登錄。
在此我們舉出網路搜索的例子,假設每個人搜索的內容是不相同的;那麼我們可以假設把數據放到隊列中,然後從隊列中依次把數據取出來;
可以利用python中Queue隊列來進行處理;
Queue的種類 :
Queue.Queue(maxsize=0):先進先出隊列
Queue.LifoQueue(maxsize=0):後進先出隊列
Queue.PriorityQueue(maxsize=0):構造一個優先隊列
參數maxsize是個整數,指明了隊列中能存放的數據個數的上限。一旦達到上限,插入會導致阻塞,直到隊列中的數據被消費掉。如果maxsize小於或者等於0,隊列大小沒有限制
Queue的基本方法 :
個別情況下測試數據可重復使用,因此我們可以把參數化數據定義為一個列表,在列表中取出數據;
在某些請求中,需要攜帶之前response中提取的參數,常見場景就是session_id。Python中可用通過re正則匹配,對於返回的html頁面,可用採用lxml庫來定位獲取需要的參數;
我們以Phpwind登陸的來進行舉例,在登陸的介面中需要把token參數傳給伺服器,token的值由頁的介面返回;
方法一:使用正則表達式
方法二:採用lxml庫來定位獲取需要的參數
技術點:
1、導模塊:lxml模塊
2、etree.HTML() 從返回html頁面獲取html文件的dom結構
3、xpath() 獲取token的xpath路徑
catch_response = True :布爾類型,如果設置為 True, 允許該請求被標記為失敗。
通過 client.get() 方法發送請求,將整個請求的給 response, 通過 response.status_code 得請求響應的 HTTP 狀態碼。如果不為 200 則通過 response.failure('Failed!') 列印失敗!
參考文章:
https://www.jianshu.com/p/a48f4af81e67
https://www.cnblogs.com/fnng/p/6081798.html
http://class.itest.info/locust 【蟲師】
https://cloud.tencent.com/developer/article/1594240 【官方文檔的中文翻譯】
Ⅳ 《Selenium2自動化測試實戰基於Python語言》epub下載在線閱讀,求百度網盤雲資源
《Selenium3自動化測試實戰——基於Python語言》(蟲師)電子書網盤下載免費在線閱讀
資源鏈接:
鏈接: https://pan..com/s/1XbV04rpaStpEO5d3je2RsA
書名:Selenium3自動化測試實戰——基於Python語言
作者:蟲師
豆瓣評分:7.0
出版社:電子工業出版社
出版年份:2019-7
頁數:272
內容簡介:
《Selenium3自動化測試實戰——基於Python語言》共分 14章,第 1章介紹了自動化測試相關的基礎知識。第 2章到第 10章是本書的重點,從環境搭建,到 WebDriver API介紹,再到單元測試框架的使用,循序漸進地介紹了自動化測試所用到的知識,最後再通過項目將這些知識串聯起來。第 11章詳細介紹了如何使用 Jenkins配置自動化測試項目。第 12章到第 14章介紹了移動自動化測試工具 appium的使用。
《Selenium3自動化測試實戰——基於Python語言》的寫作目的並不是簡單地告訴讀者如何使用一個自動化測試工具,而是希望讀者在學習本書的內容後能夠提升技術高度、拓展技術寬度,從而擺脫簡單的手工測試,向高級測試工程師邁進。