用感觉还是要用，但感觉有一个平衡点的问题。个人更倾向于优先从测试方案上进行调整，感觉这样子人力成本也降到最低

所以感觉是否引入设计模式，本质还是看自动化测试方案是怎么设计的。

常常会忘记了测试的原本目的

通常发生这种情况，就是在做的是 “测试自动化”，920 条 case，有多少是存在重复的呢？这种重复，从测试目的来说是真的必要的么？

我觉得自动化本质的目的是降低成本，这样弄 不是更复杂了么？

感谢，确实是可以。没有一点基础背景，都想不到有这种方式。至于做 ui 自动化的话，有实践指导么？

appium 有个 appium-mac-driver 项目，但是 appium 上面介绍只有支持 android、iOS、windows app。也没有具体测试 mac app 的例子

已经支持 ios 13 了，看更新

最后有做了么？

是否用 PO 模式，以及该模式是否有价值，还是取决于具体自动化落地的场景。如果自动化用例场景多，且包含关系复杂，就比较适合吧。不过个人倾向于从自动化测试用例着手，设计的自动化用例应该要相互独立，且交集少。这样不仅可以减少脚本数量，也没必要弄得太过于复杂。欢迎讨论

你小程序启动有快捷方式吗？ 还是先启动微信，再搜索小程序名称，然后打开

同样遇到这个问题，很奇怪。之前环境还正常的

执行 sh ./Scripts/bootstrap.sh 时候出现了 ERROR in ./js/app.js Module parse failed: 这个有遇到的吗？

同样出现错误
Exception in thread "main" java.util.NoSuchElementException: last of empty ListBuffer
at scala.collection.mutable.ListBuffer.last(ListBuffer.scala:401)
at com.testerhome.appcrawler.DataRecord.last(DataRecord.scala:40)
at com.testerhome.appcrawler.Crawler.doElementAction(Crawler.scala:985)
at com.testerhome.appcrawler.Crawler.runStartupScript(Crawler.scala:238)
at com.testerhome.appcrawler.Crawler.start(Crawler.scala:152)
at com.testerhome.appcrawler.AppCrawler$.startCrawl(AppCrawler.scala:344)
at com.testerhome.appcrawler.AppCrawler$.parseParams(AppCrawler.scala:312)
at com.testerhome.appcrawler.AppCrawler$.main(AppCrawler.scala:92)
at com.testerhome.appcrawler.AppCrawler.main(AppCrawler.scala)

这工具没更新了么？

出现 Freeze 应该是由于 APP 非常驻应用引起，当跑起来后应用变成后台，系统会将其冻结掉。所以可以试试将测试 APP 做成常驻应用。有试过的朋友，欢迎讨论~，回头有空我再试试