把重复的部分进行封装

快速见到效果，给出说服力

尝试用 BDD 的方式，勉强可以。看到需求，先构建自动化测试的步骤。做出来了，再补充具体的细节。

建议定义好测试的范围，例如把测试用例划分为几个级别：
P1 ： 冒烟测试
P2： 重要功能流程测试
P3： 分支功能测试
P4： 兼容性、UI 功能等

还在迭代开发阶段，P1、P2 的自动化用例执行的可能性会很高，因为每次发版可能都要执行一遍，所以做自动化的价值比较高；并且 P1、P2 的用例是比较少的，维护起来工作量也不会很高。总体来说，这些用例自动化的性价比很高。
P3、P4 设计界面、分支等功能调整的可能性是比较大的，而且用例数量也会很大，一旦有变动需要维护时，工作量也很高，因此可以先考虑不做这部分的自动化测试；

个人的体会： 自动化覆盖的功能越重要、 执行的频率越高， 价值就越大。

核心功能变动很少的，这部分可以考虑 UI 自动化掉，其他建议接口自动化

感觉还是要和业务有关，如果是重要业务就需要花时间去做，不然还是要以功能为主，保证新功能点的正常上线

两周是很正常的节奏，两周里面真正属于测试的时间也只有三天左右吧。还不确定会测试几轮。所以对效率和质量都会要求很高，需要分层的去保证质量。接口测试 + 持续集成 + 部分 UI 自动化 + 手工测试。没有自动化你们只会被累死或者背各种漏测的锅。