關於 pytest Case 遇到重試的問題

起因

pytest 驅動測試套件 執行內容不詳，但是用例可以定義執行重試次數，一般需要 2-3 次才會執行成功。
來分析這個問題：
1.Ui 自動化來說，多重試會是把測試用例執行總時長拉長的元兇。
2.重試次數更多是用來 python 棧來完成對於介面冪等性問題驗證和應答次數驗證等。
冪等性問題 是多次請求結果一致。
一次性請求，後面多次發的失敗結果一致，並且後端接收一次。
應答次數比如打點次數>3 次，用這個 pytest 外掛化行為觸發 3 次或者大於 3 次都是良選。
所以初步判斷是健壯性不足（檢查點不夠良好和關鍵節點上文驗證條件在下文執行前沒有驗證）

UI 檢查點不夠良好

PS:注意這個問答本身不考慮建設一套完善記錄上下場景關係的回退處理異常和復位 Case 內部變數初始值等，也不會對 pytest 外掛本身進行改造和新增監聽器等條件，所以檢查點設定尤其重要。
從業務角度去改的，可以一步步改造得框架比較完善。
eg1：
登入頁面，賬號密碼驗證都 pass，點選登入，到達二級頁面。
因為網路問題和首次登入請求資料會較多，登入時會出現轉圈圈圖和提示登入中的文字，導致登入有可能會失敗。
這個場景執行次數設定多次 Ok，檢查點應該設定為登入後的場景內容，如果還是設定在登入頁面，會遇到接下來的 case 批次失敗。

那麼設定這個登入後場景內容是否足夠良好？
其實並不良好，因為預設了登入時會出現轉圈圈圖和提示登入中的文字。
透過業務分析，轉圈圈是動圖，提示登入文字是靜態的。
也就是在重式的時候，檢查點需要先判斷是否出現過登入文字。
到達二級目標頁面失敗，首要判斷條件是是否出現過登入文字，然後才判斷是否包含二級頁面的元素是否存在。
寫法上 xxxx_ele =find_element_ByXXX("值") 先判斷物件是否存在,判斷物件可操作屬性。
這樣一旦出現錯誤也可以快速判斷問題出現在哪裡。

eg2:
每個頁面有個重要得標記圖，每次進入頁面這個標記圖不一定是同一張會在固定幾張內切換（假定我們不能設定其他檢查點去繞開它）
如果是圖或者元素，action_click 不是單純用顯式等待,但可以定義檢索頻率。

# Demo程式碼，座標是在需要判斷得case得邏輯程式碼下面，abc是3個物件，都是透過dr.定位器查詢方式找到的。這個while找不到可以繼續找，f定義了一個執行次數，每次找不到f-=1,當f等於0就while自己退出了。
while(a or b or c or f):
    if action_click(a):
        print(f"操作的是{a}")
        break
    elif action_click(b):
        print(f"操作的是{b}")
        break
    elif action_click(c):
        print(f"操作的是{c}")
        break
    f-=1

這樣就能知道你目前記錄的是哪張圖，並且用例也具備擴充套件性。

判斷上文條件

上文就是你的操作上文，哪怕每個用例類物件的檔案都解耦了，還是會有源頭部分的。
面對這塊，最簡單是用資料庫（頻繁請求的 nosql 型別，比如 redis，固定存一次 mysql），不想用資料庫用記憶體形式如下：
caseB 上文是 caseA，如果 caseB 和 caseA 在一個檔案的同一個類裡面，在 caseA 邏輯程式碼開始的時候，臨時申請一個 self.上文標記物件=False（不用在類變數裡面先宣告在定義一個 None），在 caseA 關鍵位置,修改 self.上文標記物件 =True,caseB 邏輯程式碼開始得地方判斷這個類變數是 True 還是 False，在對用例進行不計算執行正確失敗計算和 return
caseB 上文是 caseA,如果不在一個檔案內，可以用一個全域性變數 只定義一個，這個全域性變數在 caseA 結尾修改，caseB 開頭時使用。
PS：內建函式 setup 屬於第一種，如果需要多個，就不夠靈活，所有檔案都需要用，就等於每個檔案都要寫。
pytest skip 函式有缺點，往往是一開始就決定了，可以用到對用例內容定義標籤，滿足這個標籤得進行執行。

如果這段看不明白，建議去補下語言結構基礎，不補還堅持寫 就和燒菜燒得不好堅持開餐館一樣，自己為難自己沒意思。

是否在同一個控制代碼內

每次出現開啟新窗體的把窗體控制代碼記錄到一個字典表裡面，在這個控制代碼的操作也記錄在連結串列裡，如果關閉了介面就刪除這個字典的控制代碼號，那麼裡面控制代碼操作資訊的 value 也被刪除了。

元素引用失敗

需要對元素用過 dr.定位器找到後先儲存起來，然後再透過 element.isDisplayed 等等手段來檢查

介面問題

介面需要需要執行多次，後面幾次會成功的。
如果在前提條件充足的情況下，執行介面 case,個人是沒遇到，除非是傳送無效等價類，伺服器對你做了踢掉處理。這個時候需要寫一個處理重鏈的函式。
這個我看看是否拿到問題需求，然後在補充寫。