应该是站在设计的角度保证产品的可测性会更好些吧

分离指的是测试脚本与测试数据，而不是测试脚本与控件信息。本文混淆概念了。

移动硬盘盒，采用卡扣设计，方便组装和维修，反例是采用螺钉，而且是不同型号的螺钉。
软件中的控件，有没有 AutomationID 都行，但有了就方便开展自动化测试。

软件自动化测试很少考虑硬件层 (CPU 多核)，场景也不会以硬件开销 (CPU 密集型) 进行划分。不建议个人尝试实现多线程执行自动化测试，坑较多

同意 19 楼

这个帖子提出了使用多线程执行自动化测试的问题：https://testerhome.com/topics/30536

UI 自动化测试是模拟手工测试。
问下手工测试人员是怎么做的。

放心，都有！
按摩椅，仰卧板，有氧单车，桑拿房，游泳池，电影院，足球场等，一个都不会少！
后期跟进的项目是微型软件产业园，诚邀贵司共同入驻，让您以及所有尊贵的业主们，实现出了家门就能上班的梦想！

为什么要用 vue3 和 ts 当然是更快更好用，composition-api 更加适合大项目，ts 的可靠性和可维护性更高

哦？“改邪归正” 啦？哈哈哈

虽然可能我用不到这些特性，但并不影响我以后出去面试的时候吹牛逼

哦！“矢志不渝” 啊！哈哈哈

界面挺清爽，看来你必定下了番功夫啊！😸

想发力 UI 自动化，看冗长枯燥的教程很难让自己做到持之以恒，拿真实的项目实操就不同了。工作中没这种机会的话，可以到 GitHub 上找到 testerhome 这个开源项目，clone 下来，本地搭个 testerhome 站点作为测试环境。

这样做好处不止以下几点：

1. 锻炼独立搭建测试环境能力
2. 个人独占测试环境
3. 本地环境出问题方便调试
4. 学习都是基于实战演练，不空洞乏味
5. 遇到问题可及时到社区求助
6. 发现 bug 可向社区提报，“反哺” 社区

我看过很多代码，基本上一个函数中，有效代码或者主路径代码大概在 60%-80% 之间

这大概也是你拍脑袋的，哈哈哈

能举个栗子吗？

1 楼和 5 楼是同一个人的解答，我倾向同意 1 楼不同意 5 楼。
确切说我同意的是 1 楼这句 “logout 为什么要得到一个 LoginPage 对象呢，哪里要用这个返回值”。别人都是努力让模块间解耦，你的做法刚好相反，是在强行引入耦合。明确职责范围划分，login 方法做到点击 login 按钮就够了，不该返回 mainpage 对象。logout 方法同理。
testcase 层分别引用 loginpage 和 mainpage。测试登录，先调用 loginpage 提供的 login 方法，再调用 mainpage 提供的结果验证方法，这种做法是不是更清晰明了些？

都执行一遍，会产生重复劳动，这可以通过管理手段避免。
几年前我对这种问题产生这么个想法，可以把所有工作内容看做个方格 (未必是绝对四方形)，就需要考虑 “横向” 还是 “纵向” 划分任务更合理的问题 (对应比如按子系统还是测试阶段划分)，某些情况下混合着来更好，但要注意重复覆盖问题。

该工具可以为特定 Bug自动生成修复程序，然后将其提交给工程师批准并部署到生产中。

看来一时半会儿人工智能还是取代不了工人智力

自动修复 bug = 自动开发软件，开发也省了

没觉得这里有问题啊。认定开发做这些跟本次需求是否相关，有标准可依吗？

如何定义 “私自夹带代码”？
无法定义就无法认定，那还谈什么解决。

满纸荒唐言，一把辛酸泪！
都云作者痴，谁解其中味？

测试小工具哪家强，我司测开部门堪称王！
做的测试平台落不了地，测试框架没人用，测试脚本如屎山，部门价值该如何体现？没错，体现在做了一大堆小工具！
举个栗子！测试人员需要将产品某文件夹下部分文件删除，其中包含有隐藏文件，每次都要手工经过几个步骤开启显示隐藏文件，很麻烦！一键显示隐藏文件小工具横空出世！将过去需要 20 秒才能完成的操作成功降到 2 秒，效率提升 10 倍！也就是 1000%！肥肠的芳便！

我本来想说工具方面学习 postman 进阶用法啦、学习 SoapUI 啦、抓包工具学习 Fiddler 或 Charles 啦、编写脚本学习 requests 啦、接口鉴权弄懂 cookie session token 啦之类。感觉这样照本学习不太容易让自己做到持之以恒，我更建议找个项目直接实战学习。
没有项目可以用来实战？找开源项目啊，testerhome 开源，适合当靶子！到 GitHub 上 fork 下，本地搭个 testerhome 当测试环境。
实战时遇到技术难题搞不定？这时候再通过上边说的找答案，为解决问题学习效率更高。当然，到咱们 T 社学习效率同样更高，这里有很多精华文章 (都不是我写的) 和问答帖，学起来，“师 T 长技以测 T” : )

基于 UI 的自动化测试，业内需求可能不多，很多人都发出了 UI 自动化测试做不了甚至做了无用的声音，也有少部分人为其平反，@ycwdaaaa 高飞和我这方面观点相似都是平反者，当然也有其他方面观点不太一致。你若能继续深入这方面做下去当然很好，毕竟符合自己的兴趣和经验，若机会不成全，做接口自动化测试或性能测试其实也都不错，技术人嘛，深度广度都要兼顾对吧

哦，这就是个更靠近开发技术的问题了，我开发技术一般，但我知道社区里开发和测试都好的人@chenhengjie123，我们请教下他？

所以你的意思是你之所以做不到马上停止某单派送，是因为你不知道该单是被哪个小哥领走了，是吗？生活中我们都可以根据单号查到是哪个小哥派送的，他的手机号等信息，还不是因为派单领单时登记关联上了小哥的信息，模仿学习下，是不是可以解决你目前的问题？

就像快递小哥正在送单途中，不可能打个电话说你现在就立即停止派送，你不再被困了你自由了！有两种做法。1，把货物带回仓库然后滚吧，数据库软件中叫事物回滚；2，送完这单咱们的合同就 cancel，自动化测试工具中叫 cancel after current...