。。。

哈哈哈哈哈哈哈哈哈哈哈

保护我方输出

code 测试用例除了 excel，yaml 还能放哪里

年轻人不要太武断！搞测试自动化确实可以 codeless，最正确的姿势是，分任务，喝咖啡，跟进度，喝咖啡，看报告，其他事情嘛，找专业人员来做，找对人，出点钱。。。

搞测试自动化，写代码、coding 测试用例是最正确的姿势，其他都是死路一条，毋庸置疑！

codeless 会让一些不会代码的人被卷。
code or codeless 说白了只是一个工具而已，死不死是针对的人。
开发任务很重的时候，还让人写一些自动化测试代码，反正我不愿意。

codeless 是很多老板的需求，期望达到节约用人成本，效果好的目的，所以出现了很多开源或商业化的工具、平台，但遗憾的是现在的技术还不支持这个目标，比如之前国外有款工具宣称自动应对元素的变化，本质上是录制时候存了多种定位方式，一种找不到就尝试换一种，这个效果能应对的场景也很有限。

code or codeless 各有优缺点吧，看团队人员能力；不过从个人发展来看，肯定是用 code 好

反正我们的测试平台的自动化部分只是提供一个运行自动化测试的界面，以及看测试进度和结果，实际的测试用例还是用代码写的，主要就是代码自由度高，方便

井底之蛙

可以做那个写 codeless 工具的测试，不可以做那个用 codeless 的测试

理想丰满、现实骨感。
1、让内部测开或者自动化测试同学在 “测试平台” 上录入 http API, 组装 http 请求...稍微有点自尊的人内心可能会说：这特马不还是点点点吗，在 web 上点点点
2、让点点点或者外包同学在 “测试平台” 搞，你觉得让 对 http, 接口、服务调用链、中间价等概念都没一定了解的人，能干好接口的测试吗。 不是给了菜谱 就能烧出美味
3、另外，再啰嗦一句：作为测试开发，想要拿高薪，不要脱离代码，保持代码手感很重要。不然出去一面试，问个简单的原理，写个简单的算法就会卡壳了

1、老板的需求不是 codeless, 老板的需求是秀肌肉、秀部门实力、讲故事
2、虽然我不赞成在 web 上 “点点点” 自动化，但通过测试平台，通过 web 的方式展示测试数据，追溯测试数据、可视化测试数据、 通过测试大数据形成质量度量...是非常认同的

写代码最灵活，也最容易接触底层，了解更全面。可以理解为是最正统的方式。

但不代表每个人都必须要这么高的灵活度和深入度，对企业或者公司来说，招少数人写平台或框架，多数人直接基于这块写用例，性价比更高。现在行业还没完全提高到随便一个测试人员都能直接 coding 写自动化用例的水平，会 coding 和不会 coding 还是有成本差异的。

个人观点：正统方向要有，但也不能一刀切。只要能帮助团队提高效率的，都是好框架。好框架不等于需要百年长青、面面俱到，能解决当下问题就很足够了。

PS：就算 coding ，也要有相对统一的规范才好协作的。开发有各种比较明确具体的分层架构（MVC、MVVC 等），而且都是业内相对通用，换家公司还能继续用的。但测试这块目前太少了，基本都是各家自己定，而且内部还不一定能全员都理解和用对。缺少统一架构的 coding ，维护起来比天然就能统一写法的平台或框架，更痛苦呀。

我长期呆在深井，眼界低。
来，你快带我飞...

这位同学思考有深度，出去月薪 50K+ 没问题

只有这句：

正统方向要有，但也不能一刀切。只要能帮助团队提高效率的，都是好框架

正确的废话

我这句是针对你前面的 搞测试自动化，写代码、coding 测试用例是最正确的姿势 才特意补充的。

你这句话我的理解是，只要不是用写代码、coding 的姿势搞测试自动化，就不是好方法，死路一条。
我想表达的是：就算用的不是写代码或者 coding 的姿势搞自动化，只要能有效果提高效率的就是好方法。

直白点说就是，我不认同你的观点。

这就像开发中的 low-code 理念。

我自己的团队，我是主推 coding 写自动化测试用例的，一个方便灵活，二个是能提升团队的技术水平。测试平台写用例，宣传的时候很美好，用起来就火葬场了。说真的，没有一定技术能力的测试，不了解自己测试产品的技术实现，设计用例的覆盖度真的能去到很高吗？

至于现在测试行业一堆的测试平台拼装，说白了就是一部分人的 OKR 而已，所以现在很多测试人追求提升的都是技术能力，完全忘记了自己的老本行。至于测试开发这一神奇的岗位，我只想说，好好做 QA（QUALITY ASSURANCE，不用跟测试挂等号）不香吗？

看角度，如果是从写&执行的角度来说，直接上代码无疑是最自由的。如果是从管理和度量的角度，平台还是有优势，当然，前提是平台是个 “平台”，而不是 ppt，领导会去看你的代码？不，它只想看大盘。平台的定位不应该是一个代替 code 的自动化工具，而是整个团队研发流程的一个物理约束，具体支撑。退一步来讲，光说自动化，不管是 code 还是平台，都看人，牛逼的 code 也能整整齐齐；不牛逼的，平台也就乱七八糟。

测试开发的出现是有客观规律的，但是在国内弄得有点四不像。
google 定义的测试开发的代码能力不能低于开发，面试标准完全一致，在此之上还得具备测试的思维。
国内的测开要么是自动化测试，要么是搭平台，做工具，跟测试沾不到什么边。

code 和 codeless 不是 01 问题。外部环境决定生产力，对于测试平台来说，什么样的用户决定它需要具备什么样的功能。测试平台一般是测试人员使用，有会代码的和不会代码的，不会代码的希望能不写代码就实现自动化。测试平台有时候开发也会使用，虽然开发会代码，但是他们压根对写测试代码不感兴趣，也希望不写代码就能实现自动化。code 对于技术性测试来说是自由，codeless 对于非技术测试来说是刚需！二者缺一不可。

曾经，我也这么认为，然而在我们团队当下场景下，太难推广了

说实话，自动化用例写多了，让我写代码或者直接填 excel 我感觉都是差不多的，不说多的，自动化用例重复代码起码有 70% 吧

很多公司尝试过安排开发做自动化测试，他们也很有意愿和兴趣，但最终成效大都不是很理想。看来问题不是出在意愿兴趣上，而是出在别的方面，比如开发具备的测试思维理念不足，还有其他别的方面需要探究

评论很精彩

写测试脚本也没啥技术含量，倦了。不如写写平台，领导喜欢，自己技术还有提升

站的角度不一样，看的问题就不一样。
测试平台并不会让想要成长的人得不到成长；比如你可以选择参与平台的前后端开发，比如平台如果真的提高了自动化编写的效率，那么空出来的时间你可以做更有意义的方向研究；更何况天天写一些差不多的脚本，用差不多的技术，也不会让你有太好的成长。谁的简历里还没有个自动化测试，那么你比别人的优势又在哪里？

coding 测试脚本和开发自动化框架根本不是一回事，说实话，如果一个业务测试人员了解测试模块的系统架构，数据链路，看得懂开发的代码。我觉得他比不接触业务只会 coding 自动化脚本的人强多了。换句话说测试是用来找 bug 的，如何高效和高质量的找 bug 需要你对你测试的产品内部实现有深入的理解，而只会 coding 测试脚本的测试价值有那么大吗？

领导喜欢，能涨工资就得去做。
如果领导说写多少自动化脚本给多少钱，那我估计得天天 coding 脚本了。

我去！
评论精彩纷呈，
testerhome 社区藏龙卧虎

为努力实践和深度思考的同学们点赞 👍👍👍

脚本可以提高效率=减轻重复劳动=给自己省时间=可以摸鱼 薅老板，谁又能拒绝这种诱惑呢

只要不用我直接动手去做的都是好技术， selenium 也好 appium 也好按键精灵也好还是直接用 cmd 命令行，只要能高效解决当前实际问题，并且确保通用，以后出现这种任务可以直接套用 我就乐意去做

改进测试流程也能帮助提高效率，我也乐意，就是要跟人 PK，麻烦，还是写代码好

有些人善于改进流程，与人沟通，通过其他办法来提高效率，也是一种方法，没必要一棒子打死呀 ，相互借鉴学习嘛

降低自动化测试人员的技能要求，是自动化测试平台的主要目标。

code 还是 codeless ？ 那必然是 code ， codeless 的问题是成本问题，说白了，是现阶段的从业者很难达到，但这不是目标吗，测试行业正在转型。赶紧学习起来吧。