如果你是學習網絡爬蟲，那麼到這裏就不用再繼續看了。如果你是做自動化測試，那麼接下來纔是重點。
關於 unittest 框架的用法，請參考Python 測試框架。
前面我們一直在講 Selenium 對各種操作的模擬，以及處理各種特殊頁面元素和結構。雖然通過 assert 語句增加了一些預期結果與實際結果的判斷，但是並未形成真正的自動化測試框架。
通過對 unittest 框架的理解，已經瞭解了 Python 中單元測試框架的用途。雖然 unittest 是單元測試框架，依然可以用於自動化測試，UI 自動化測試與單元測試都是一種自動化測試。unittest 的主要內容是如何編寫用例、組織用例、運行用例和運用測試固件，所有的測試都基於這些框架基礎。包括基於移動界面的自動化測試，以及基於接口層面的測試，都可以應用這些測試框架。
回顧一下 unittest 框架中的基本思想：
支持各種層面的自動化測試；
測試用例共享 setUp 初始化和 tearDown 清理代碼；
通過各種方式組織測試和規劃測試用例；
保持測試代碼與測試運行之間的的獨立性。
那麼如何使用 unittest 結合 Selenium 來實現自動化測試？
test fixture
在測試固件中的 setUp() 方法中加入瀏覽器初始化、配置初始化、數據庫連接等動作。
在 tearDown() 方法中退出瀏覽器、還原配置、斷開數據庫連接等。
或者其他需要在測試過程中清理和初始化的動作。
test case
測試用例儘可能保持代碼和數據的獨立性，畢竟 UI 自動化測試步驟非常複雜，用例之間的依賴會因某一個用例的失敗而導致與之相關的用例全部失敗。
測試用例儘可能保持可獨立執行狀態，可任意根據需要執行某個或者某類的測試用例。
UI 自動化測試因其受界面元素變化影響非常大，因此用例編寫儘量基於流程的測試，這也是 UI 自動化測試的意義所在。單個功能的測試用例過多，大量的手工用例被自動化會導致自動化測試代碼的維護量非常之大，這樣也是自動化測試失敗的根源。
儘量少或者不編寫關於導致流程失敗的逆向用例，逆向用例可能性過多。並且實際自動化測試的使用場景，是基於已完善的功能，檢查其沒有被新功能修改所影響。正向用例的意義更大。
謹慎選擇加入自動化測試的手工用例，但凡提自動化測試覆蓋度的團隊，自動化測試實施的失敗也就在三個月左右。一定要謹記，用例越多維護成本就越高。所以用例選擇一定要選擇高頻率、高優先級、非常重要的用例，有餘力再逐次添加。
如果選擇的流程自動化測試實現難度較高，建議推後自動化測試。並非要實現 100% 自動化測試，所以先以較易入手的測試流程加入。先易後難，團隊需要信心。
自動化測試，特別是 UI 自動化測試成功率低，主要原因集中於環境問題、團隊期望、維護成本等。其實很多時候核心問題都集中在測試用例的選擇上。不要想一蹴而就，在找到適合當前團隊的自動化策略後，逐步提高自動化測試覆蓋度，才能讓自動化測試達到提高團隊效率的作用。
test suite
通過 discover 加載和構建測試套件，由於我們在編寫用例的時候有可獨立運行的前提，所以不用在意用例的加載順序，如果非要加載順序建議好好研究一下 discover 的查找規則。
通過用例的不同命名方式（如產品類的測試用例使用 *product*.py），跳過規則（如 skipIf、skipUnless）等策略構建不同的測試套件。以期達到在冒煙測試、BVT 測試、兼容性測試、核心流程迴歸、線上巡檢等應用場景中都能快捷方便的選擇需要的測試套件。
test runner
藉助 HTMLTestRunner 或 Beautiful Report 等運行測試套件並展示 html 格式的測試報告。
如果運行速度過慢，可以引入多線程或者多進程結合瀏覽器的無頭模式加快用例的運行速度。
同時也可以將運行代碼與持續集成結合。