测试萌新一个
目前对于公司的软件每次版本更新都得进行一个回归测试。在回归测试这一块想做成自动化测试，用来节省时间
目前是使用 weditor,但是都使用一步一步操作点击的，想着如果整个 app 都是这种一步一步点击来写，会相当花时间。所以想请教一下该怎么去架构这个东西
app，主要是关于一些写贴，浏览帖子等的一些基本功能
个人理解：自动化测试就是为了实现更简单、更少人力的回归测试；不清楚 weditor 这个工具是怎么实现回归的，如果是 APP 的话我了解到的无非就是两种：界面自动化与接口自动化；具体可以百度下 APP 自动化测试
看了下，weditor 是 atx 提供的用来获取界面元素信息，便于编写 UI 自动化中元素定位相关语句的工具。
目前主流的自动化，从如何编写脚本角度，会提供两种方式
一种是录制生成代码，比如 solopi 、appium desktop 都可以通过用户操作直接自动生成对应自动化代码。直接用这个生成出来的代码来执行，成功率一般也还好。
另二种是直接编写代码，比如使用 Page Object 模式定义各个页面及页面元素，然后用例里去操作这些页面元素进行自动化。好处是维护成本相对较低（重复的东西都会抽离封装），并且后面会越写越快（可以复用已有的代码），缺点是从零开始写用例来算，相比第一种写起来耗时会多一些。
看你提到 相当花时间 ，个人理解你应该是在使用第二种方法。但觉得用起来比较耗时。建议你可以也试试第一种方法？
另外，建议刚开始先不要弄太多用例，把最重要的用例做出来就好了。自动化耗时的大头不是编写，而是后续不断调优让它更快更稳定。
建议楼主先了解下自动化的引入参考，再实际调研下该产品是否符合准入条件或者说自动化所带来的价值是否值得，待确定这些后再去思考下自动化在产品上的最合适的具体实现方式；
最后应题：我理解的自动化就是将手动通过代码的形式来进行替代，然后集成来统一执行
weditor 只是为了辅助你写脚本 为了用例长期更好的维护 还是需要做好分层
