• 用'setup 每次都会重开一个 session,但是用例不会依赖，
• 而用 setupclass 每次执行用例会一直使用一个 session，但是就会像你所说的用例依赖
• 我是用 setupclass+driver.get() 的方式刷新页面，既不会每次重启一个 session,也不会造成大量用例依赖

每次重启一个浏览器，那运行起来就太慢了
可以在每个用例的 tearDown 里面写个回到首页的处理（APP 同理）

为了不相互影响，可以每个用例都自启动一个浏览器进程；
如果要加快测试速度，可以用多进程并发执行。

你用 driver.get() 初始化的时候有没有遇到问题？

你的问题是 driver 进程 没有关闭，而不是关不关浏览器的问题

原则上:

1.每个用例是独立场景,要关闭浏览器；

事实上:
取决你的领导

这和领导有什么关系。。求指教

我带领我们公司自动化测试团队编写了分布式的 WEB UI 自动化测试框架，我来发表一下我的看法。
每个用例应该是要重启一次浏览器的，这样子做有弊有利。
弊端：
1、每次重启浏览器，会生成几十 MB 大小的缓存在硬盘，自动化测试用例过多的情况下会使得磁盘爆满，系统速度缓慢。
2、重启是需要时间的，重启的速度取决于电脑的速度，还有磁盘的 io，当然还有浏览器的类型。
3、重启会加大整个自动化测试程序的不稳定性，因为有的机器可能会关闭失败，当然我们采取的是分布式自动化测试，执行卡死的机器就直接略过，他的任务会被其他正常的机器取代。
4、driver 进程在重启过程中会不断增加，最后使得机器进程过多卡死，但是这点只需要通过简单的 taskkill 命令就可以解决了。
4、有些用例之间如果有衔接，重启的话可能会重复一些操作，以致于使得自动化测试脚本变多。
好处：
1、每个用例执行必然会在浏览器留下一些记录，特别是 cookie，比如你执行两个登陆操作，如果不重启浏览器，可能第二个用例登陆就登陆不了。
2、符合自动化测试用例设计的 用例原子性问题，用例和用例之间不存在干扰，不然可能会出现自动化测试结果的莫名其妙的问题。

当然随着测试理论的变化，这些会变，因为公司的自动化测试框架是分布式的，重启浏览器所损耗的时间只是小事情，我们自然也忽略时间的差异。

每次 quit driver 就对了，应该不会残留 driver 进程（不知道是不是我用的 firefox)，不然会出现很多奇怪的问题，时间的损耗可以尝试用其他方法补偿，重要的是必须保证用例的独立性和稳定性

setup driver.get('')
teardown 加个清理缓存