下面手机助手UI自动化代码review的会议记录
1、会议内容：
（1）分享review代码过程中发现的问题
（2）review中的疑问以及讨论结果
2、 会议记录：
(1) 定义变量做循环，但是循环体中没有使用到该变量
实例：
image
预期修改为：
1. 初始循环变量
2. 循环体内累加变量
3. 增加累加结束循环的阈值
image
(2) assert语句中的get_text()直接使用
实例：
image
预期修改为：
1. 将get_text()方法的内容放到变量中，便于维护、查看代码
image
(3) 代码缩进问题，缩进了8个空格
实例：
image
预期修改为：
1. tab 4个空格（从notpad++上copy的py文件就会出现此情况）
image
(4) 代码冗余，if….else….在case中无影响
实例：
image
预期修改为：
1. tab 4个空格（从notpad++上copy的py文件就会出现此情况）
image
(5)
实例：使用try..except去判断设备管理弹窗
image
预期修改为：
1. 判断元素是否存在，存在时触发click（）方法
image
(6)
实例：变量命名无实质上的意义
image
预期修改为：
1. 根据实际情况，命名有意义，尽量不使用数字
(7)
实例：断言无效：根据text属性获取元素text，后面判断text的内容
image
预期修改为：
1. 必须通过元素控件获取text，再将获取的text内容进行校验
image
(8)
实例：代码多余现象：循环滑动下方无检查点
image
预期修改为：
1. case中尽量避免出现与case无关的代码，在自己review的时候需要删除
image
(9)
实例：assert不是用例的检查点
image
预期修改为：
1. 断言需要和检查点一一对应，不能出现assert的不是case的检查点情况
image
(10)
实例：需要转换类型时，未将需要转换的内容存放到变量，导致后续代码每次都加上需要转换的类型
image
预期修改为：
1. 将需要转化类型的内容存放到变量中，便于后续的使用
image
(11)
实例：初始化代码需要放到初始化api内
image
预期修改为：
1. 初始化代码需要放到公共api中
(12)
实例：无效case，任何情况下都会通过，需要拆分成两个case编写
image
预期修改为：
1. 需要拆分成两条case，单独进行验证
(13)
实例：case合并问题
image
预期修改为：
1. 合并case，既能覆盖到检查点，也能提高case执行效率
(14)
实例：case中与检查点无关断言过多
image
预期修改为：
1. case中的断言需要用在检查点上，其他与检查点无关的点不需要使用断言
(15)
实例：if –else语句使用中，无对else的检查
image
预期修改为：
1. 添加else的逻辑，增强代码对检查点的覆盖性
(16)
实例：case中无对检查点的断言
image
预期修改为：
1. 测试代码要对case检查点进行检查
(17)
实例：case检查点不充分
image
预期修改为：
1. 添加对case检查点的验证，足以验证该case的检查点
(18)
实例：缺少步骤操作的注释
image
预期修改为：
1. 加上对该代码的注释，增强代码可读性，便于维护代码
(19)
实例：case描述太简单，无预期结果
image
预期修改为：
1. 将case描述写的详细，将检查点表达出来，易于阅读、维护代码
image
(20)
实例：case中安装了非测试的助手包来验证检查点
image
预期修改为：
1. 只能使用被测试助手的包
(21)
实例：在桌面循环查找创建的快捷方式文件夹逻辑优化
image
预期修改为：
1. 通过使用range()函数的用法来优化重复操作
image
(22)
实例：点击服务端返回的tab或者模块，如服务端更改则case失败，如分类页下的仙侠更改
image
预期修改为：
1. 通过requests接口请求返回的数据来实现该类case的验证
image
(23)
实例：循环次数多次与只执行一次的情况相同
image
预期修改为：
1. 滑动一次即可，提高代码执行效率
(24)
实例：检查下载功能中对助手清除缓存
image
预期修改为：
1. 单独写检查下载功能的api，减少代码量
(25)
实例：判断条件可以直接用自有函数解决
image
预期修改为：
1. 使用自有函数abs()解决
3、 问题讨论：
(1) print()信息有没有必要封装？
讨论结果：不进行封装，需要将case中的print()删除或者注释掉
(2)要不要把home（）加入到teardown（）下面 ？
讨论结果：看具体case，如果需要的话将home()写在自己case中
(3)mock数据?
讨论结果：后期使用mock数据来解决通过服务端返回的信息的相关case。
(4)在跑自动化case之前要不要清除全部app?
讨论结果：后续会单独写两个api来验证下载功能，包括：清除机器内所有app以及单独卸载一款应用
(5)断言的msg需不要加上？
讨论结果：需要加上，而且必须写的尽可能的详细
(6)sleep()和wait_for_appearance()能不能一起使用？
讨论结果：能一起使用，具体case具体分析，尽量不用sleep。
(7)case描述中要不要加逻辑描述？
image
