前一段时间用RobotFramework+Appium实现了安卓的UI自动化，2个人+1个月，大概写了300多条的用例，需要大约4小时全部执行完成，用于版本上线前的回归测试；由于各种各样的原因，每次执行时，用例都不能全部正确通过，执行速度慢，稳定性差，受环境影响较大，维护成本高，UI自动化的缺点很多，但是也是学习成果。
自动化讲究思想：分层思想。由于所有的测试用例都需要优先登录系统，所以在做安卓UI自动化时，我们将系统登录和退出放在了RF的setup()和teardown()中，其他用例分为2层（测试页面元素和方法+用户逻辑）
最近在学习selenium的web测试，同样所有的测试用例都需要先登录系统，因此将登录和退出系统操作放在setUp和teardown中，如图，创建一个MyUnittest类，继承unittest.TestCase，有4个方法：
（1）setUp()：每个测试方法运行前运行，测试前的初始化工作。一条用例执行一次，若N次用例就执行N次，根据用例的数量来定。
（2）setUpClass()：每个class文件运行前运行，必须使用@classmethod装饰器进行修饰。
（3）tearDown()：每个测试方法运行结束后运行，测试后的清理工作。一条用例执行一次，若N次用例就执行N次。
（4）tearDownClass()：每个class文件运行结束后运行，必须使用@classmethod装饰器进行修饰。
在每个测试的class执行之前，执行setUpClass()用于打开浏览器和浏览器最大化；
在class中的每个测试方法执行之前，执行setUp()用于输入url；
在class中的每个测试方法执行结束之后，执行tearDown()用于刷新浏览器；
在每个测试的class执行结束之后，执行tearDownClass()用于退出浏览器。
接着将公共处理的事情写在BasePage里面，用于所有页面对象的继承，可以写的公共方法很多，大家按需要写。
然后，具体的每一个需要测试的页面需要继承BasePage，具体的页面属性和操作在这一层定义，如若出现UI的更改，只需要修改这一层的对象即可。
最后是测试用例，测试用例继承MyUnittest，执行顺序如上述所述，每个class中可以是相同的业务测试用例，如下是对登录页面的测试：
这样一个简单的UI框架的完成了。如果需要测试具体的业务操作，例如登录系统之后，对某个页面进行查询的测试，具体的页面属性和方法的编写这里就不列出了，测试用例同样是继承MyUnittest，并且先执行一次登录系统操作：
以上是近期的总结，还存在很多不足之处，路一步一步走，慢慢完善。