與對框架熟悉些的前輩討論，都說其原因是連線不穩定導致http請求無返回。這種http請求、連線不穩定的問題好像很難解決。
雖然前輩們都說是連線不穩定性導致，我們還是需要例行分析下，出現badstatusline相關的堆疊資訊如下，其中可以看到相關呼叫過程，
相關**如下所示，而且增加了日誌，badstatusline基本上都是這一種問題，邏輯不難分析，在解析http請求的響應狀態時沒有資料（1行都沒有）時沒法繼續了，就丟擲badstatusline問題，確實看起來和前輩們所述完全一致。
問題大概原因知道了，既然是連線不穩定，解決思路是在http請求的上層捕獲該異常，捕獲到後就重試，最大重試3次，實在不行再丟擲異常。
筆者是使用selenium3.4.3版本；檢視版本方法：通過檢視lib\site-packages\selenium中的__init__.py資訊即可知道；如果版本相同，可直接做相關修改；如果版本不同，作相應類似修改即可。
主要修改**lib\site-packages\selenium\webdriver\remote中的webdriver.py如下圖所示，
當然，前面也需要import一些包，如下圖
我們在解決過程中也遇到了不少坑，介紹下最重要的乙個坑，在關鍵**中，我們看到有time.sleep(0.5)，這個比較關鍵，如果沒有這個休眠立即重試，效果不是很好，如果這個休眠時間太長，比如5s，會導致很多關鍵字超時（大部分關鍵字預設超時時間是5s，通常大家設定的是10~20s），也就失去了我們失敗重試的初衷（初衷是想我們關鍵字執行成功）了。
因為badstatusline問題不是必現問題，所以驗證起來不是很方便，大家修改完webdriver.py後（修改前記得備份哦）可以把自動化測試跑起來，然後分析自動化測試的日誌看有沒有出現該問題，出現該問題後有沒有重試，重試後有沒有效果。
這裡簡單介紹windows中的分析方法，這時候我們可以通過命令來匹配具體出該問題的時間，再來分析html中的報告來觀察，命令：findstr /s /c:"badstatusline" $\*.xml ，$代表報告路徑。
經過驗證，這種方案已經解決大部分（80%以上）的badstatusline問題，這裡提供常見幾種關鍵字出現badstatusline問題的分析
tap關鍵字，retry後成功了
capture page screenshot關鍵字，retry後能夠看到截圖
log source關鍵字遇到badstatusline再也沒出現none了，也不會失敗了