拜读，感谢分享！收获很大

正常讨论帖不要匿名行不。很好玩么

除了拖拽那个 (可能会限制测试思维，这个和业务需求还是有点不同)，其他都赞同。

低代码的本质是应用场景的极致抽象并且模板化的过程，其实没准大家写代码的时候就有这思维。
固化的测试方法先天就适合模板化。
个人觉得平台能提供 “用到的技术模板”、“测试方法模板”、“业务模板”、“流程模板” 这几个模板服务，让用户可以方便定制自己的测试流程，查询调用封装好的业务，自动 or 手动选择封装好的通用测试方法，结合技术模板，达到快速产出的目的，就算能用的平台。

看对 “点工” 这个概念的理解了。
如果点工只是不会代码的业务专家、领域专家，只要行业不死，东西是给人做的，就会一直辉煌下去。
如果点工只是增删改查的点点点，这玩意儿谁都能做，老早就不辉煌了。

个人觉得要不是业务不具备通用性，不好考察，测试人员跳槽，优先应该看业务理解。
对测试而言，技术只是锦上添花的，技术强，测试能力不一定强（也可能强得离谱，1 个打 10 个）。但是技术强，一定很好跳槽涨工资。

谁还不想多点钱呢？大家都是为了养家糊口，就不要互相伤害了。

1. 根据实际需要来
2. 内部接口能集成测试就集成测试，外部接口可以考虑 mock 辅助

上面恒捷回复已经很详细了。
我也建议你针对问题来切入。

规范这个东西，没整好就是束缚。而且这个很多时候会和考核牵扯上，初期往往弄得怨声载道的，需要从上到下的支持。

太 SB，反馈了一下，最终没搞。

太多了。。。各种安全规范、sonar 指标，这些东西看团队规模和公司的要求。

突然想起了两个人的项目组被强迫搞敏捷的故事。。。

1. 强迫自己给出多条观点
2. 给观点分类（平行、递进等）
3. 给分类的观点进行发散
4. 反向思考
5. 提炼总结

你主要是最近不想写代码吧。。。

大概率是越狱中了病毒。如果实在越狱了，不点不信任的链接，不下载未知的 app。

晃眼看成了孪生素数。。。哈哈，非物联网行业，第一次听说这个概念，学习了。

这不就是对用例执行顺序排序的过程么。。。

testng 个人觉得是标准做法。
用有向图判断强连通子图来检测循环依赖，区分顺序执行的方法列表和独立的方法列表。
独立方法列表可以考虑并发执行。

是的，目前兼容 apk，以后就说不准了

我们部门之前就有这个倾向，按了一年，因为组织架构调整，死灰复燃了。

学习下~
之前我也准备转到 agileTC，不过由于离职的太多，搁浅了。
另外由于项目要求必须向下兼容，所以目前 git 管理用例还行。

这里应该 H-G 吧。
另外整个流程不就是递归的吗？

加个约定俗成的缺陷类别就行了

路径去掉空格换行什么的试试

跑一下把请求返回以及对应的第三方请求返回录下来

1. 哪个顺手用哪个，我的经验是开发用啥我用啥，资源不够的时候好抓壮丁
2. 根据需要自己组合就行，哪儿有什么好不好的。。。你这和 java 好还是 python 好这个问题差不多
3. 涉及到第三方多的，一定要便于录制，比如自动录制 mock 数据什么的

我在 LeetCode 刷到过，原题及题解帮你找到了。
https://leetcode-cn.com/problems/department-highest-salary/solution/bu-men-gong-zi-zui-gao-de-yuan-gong-by-leetcode/

毕竟人都是活在预期中的。超出预期一次，就是压榨的开始~

流程跟不上研发节奏，标准化不接团队地气，没有形成团队共识。

这是流程化、标准化的工具的通病，很多流程化、标准化的工具，慢慢的被变化的团队结构和研发流程所遗弃或者选择性使用了。

根据实际情况来吧，有些公司或者个别领导，就要那些用不上自己也不看的玩意儿，或者蹭点数据去做汇报。
美其名曰：数据支撑。实际毛用没有。