1.這個conftest.py分路徑嗎？如果在TestCases下建這個包可以直接用嗎？
TestCases這裡有ModeA和ModeB，想在ModeA或ModeB下面用這個conftest.py裡面的，一樣全部都可以用。
看目錄結構，conftest.py是頂級目錄的。實際工作過程中，ModeA和ModeB是個獨立的模塊，這個獨立的模塊下有屬於自己的前置後置。如果ModeA和ModeB下面有5個模塊，把5個模塊的前置後置全部放在conftest.py裡面，會覺得太多也太繁瑣了，同樣存在問題。
conftest也支持包的層級，注意一定要是包。 為什麼命令行當中提示我引入失敗呢？
那是因為這個地方沒有創建成包的形式，一定要以Python包的形式創建：
在ModeA或ModeB下面同樣可以右鍵創建conftest，可以作為本模塊下的conftest，名字照樣是conftest，因為它只有一個名字。
2.在這個文件夾裡創建的conftest，可以針對本模塊做一些事情。
但是會存在一些問題，這個conftest和最外層的conftest，它有函數名稱是重複的。如果存在函數名稱重複，按照常規的思路，優先使用自己模塊下的conftest，相當於是在子級的conftest當中，對它去做重寫。
類和對象當中有學過，子類當中會覆蓋父類的同名函數。這裡本質上的意思是一樣的，雖然我沒有定義成類和對象。
如圖，有個和它重名的conftest，那麼在ModeB下面就用自己模塊下的conftest裡面的函數。
所以，它是允許分層創建的。也允許在外面放個大的conftest：
這個大的conftest裡面可以放ModeA和ModeB這樣的模塊裡面都涉及到的前置和後置。如果是ModeA或ModeB獨有的前置和後置，那麼就放在它們自己目錄下的conftest裡面就可以了。所以它是支持層級的。
3.一個文件夾下不宜放太多的.py文件，不然你會發現一個文件夾下的文件列表會很長。
具體怎麼放，視實際情況而定，切記不可死讀書。
二、pytest參數化pytest當中不能使用ddt。流程性質的東西，在pytest裡面叫做參數化。
1.pytest和ddt的方式很像，但是還是有區別的：@pytest.mark.parametrize("參數名",列表數據)
你看，它後面跟了2個變量，ddt當中只要跟一個變量就可以了。比如現在有好幾組數據，那在我們ddt當中用一個*號就可以解決它。但是這裡不行。
這裡最基本的用法是這樣的：
2.首先在這裡整個參數名，這個參數名的作用是什麼？因為你這個數據是要給測試用例用的。那麼這個參數名就是用來接收每一組數據，如果你這個列表當中有10組數據，那麼參數名就依次接收這10組數據。
參數名是放在測試用例當中的參數。列表數據就是那10組數據。
它是作為函數的參數傳進來的。
3.這個參數名能都叫data嗎？
當然可以。
4.運行的時候它告訴我搜集了多少測試用例，沒有報錯就證明沒問題。
要麼從文件開頭開始運行，要麼從文件結束開始運行。
5.為什麼會報錯？
登錄用例當中用到了pytest當中的fixture，access_web是我們的前置條件。它代表了它的返回值，我們有修改，但是我們在這個地方並沒有修改：
第一張圖，我們可以看到，搜集了8個用例，那就證明這樣的寫法是沒錯的。
6.接收下access_web。前置條件中返回的driver對象以及login的對象。
7.為什麼我這裡不是py開頭？
可以這樣設置：
8.在控制臺運行，如果有多個文件夾，是不是要先切換到當前的文件夾，再用pytest?
Terminal裡面直接是當前的工程路徑。和多個文件夾沒關係，是從當前路徑下面一層一層去找到對應的就行了。
三、重運行Web自動化中還重視重運行。
在調試的時候會發現用例有的時候能運行成功，有的時候它不能運行成功。Web自動化的用例，準確來說是不太穩定的。它和網頁網速、渲染的速度、伺服器的狀態和自己寫腳本的能力都有關係。這些都導致腳本不是特別穩定。
寫的每條測試用例應該在本地連續運行3-5次以上。如果沒有報錯，都能夠執行通過，那這種情況下才算在本地調試通過。但是在本地調試通過，不代表在其它的電腦上就一定能調試通過。這是個正常的現象，不要懷疑。
因為不同的電腦，環境也是不一樣的。但是你的腳本是一樣的，所以大家把代碼寫好放在其它伺服器上去運行的時候，還是需要有一個調試的過程。 但是你在本地調試通過後，再去其它的伺服器上調試，問題就會少很多，只有一些小問題需要調試下了。
針對這個現象，Web自動化中有個機制叫做重運行。重運行是專門針對失敗的測試用例去重新運行一下。
如果第一次有8個測試用例，運行成功後有2個失敗了。那麼這2個會重運行。
1.是在這個用例失敗後馬上重運行，還是等全部用例執行完成後再去把這些失敗的用例選出來再去運行？pytest它的重運行原則是當前這個用例失敗後馬上重運行。
它的重運行也是命令行，但是需要裝插件。插件的名稱是rerunfailures(翻譯為重運行失敗的用例)
安裝命令：pip install pytest-rerunfailures
四、出測試報告我想在jenkins上直接看到測試報告（方便測試經理或產品經理看這個項目的測試結果）。只需自己登錄jenkins上看下最新的測試結果數據。
1.xml就是給jenkins集成這樣的東西。我們可以進一步解析xml文件，接口測試中有一種數據表達方式就是xml，xml是用來存儲數據。我們拿到這樣的數據就可以解析。
第一，如果想二次定製更漂亮的測試報告，可以解析這個xml。
第二，外部的一些軟體想要獲取測試結果，放到別人的平臺上去。那就是通過xml的解析。
2.result log就是在控制臺中看到輸出的樣子。這個格式基本沒啥用。
3.Html和Htmltestrunner的區別是比較大的。
以上3種測試報告都有自己的命令格式。xml和result log這2種是自帶的，只有Html是需要安裝插件的。
命令：
pytest -m demo --reruns 2 --reruns-delay 5 -s --junitxml=Outputs/reports/report.xml --html=Outputs/a.html
怎麼寫命令，根據實際情況而定，有時候配置了pycharm後，命令也不一樣，所以不可死讀書。
命令的順序沒有要求，可隨便放。
相對路徑：相對於當前的工程。
不支持絕對路徑，只支持相對路徑。
出來的html報告是這個樣子的：路徑這個東西表達的方式也是相對路徑，因為我們運行的時候是在當前工程這個目錄下，所以相對的都是工程的路徑。
自己寫的logging也可以配置參數在這裡輸出日誌。
歡迎掃碼關注！