Python + Selenium结合 unittest 测试框架

如果你是学习网络爬虫，那么到这里就不用再继续看了。如果你是做自动化测试，那么接下来才是重点。

关于 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 格式的测试报告。

如果运行速度过慢，可以引入多线程或者多进程结合浏览器的无头模式加快用例的运行速度。

同时也可以将运行代码与持续集成结合。