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

低代码的本质是应用场景的极致抽象并且模板化的过程，其实没准大家写代码的时候就有这思维。
固化的测试方法先天就适合模板化。
个人觉得平台能提供 “用到的技术模板”、“测试方法模板”、“业务模板”、“流程模板” 这几个模板服务，让用户可以方便定制自己的测试流程，查询调用封装好的业务，自动 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/

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

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

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

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

发个风险邮件完事儿。测试报告不用自己写的，也没人看，自动生成了。

用的最多的是流水线和 xmind，其他都和代码一起管理了。