请正确区分测试用例和 UML 中的用例（需求用例）。

举个例子
1.测一个东西，要去看三台服务器的日志，写个工具直接一键呈现
2.每次调用都要自己保存，写个工具，调用自动保存
3.一些万年不变的批量验证修改，全部工具化
4.根据个人习惯，定制你爱不释手的工具

这些东西，小是小，但是真的好用，使用频率≈有了再也离不开的地步。（业务和流程不发生大变动的话）

递归应该也能做

综合楼上的一些思路，做了个 java 版。

public static String myUnzip(String testString){
        StringBuilder strb = new StringBuilder();
        int multi = 0;
        //倍数栈，记录每个子串的倍数
        Deque<Integer> stack_multi= new LinkedList<>();
        //子串栈，记录子串
        Deque<String> stack_strb= new LinkedList<>();
        char[] c=testString.toCharArray();
        for (int i = 0; i < c.length; i++) {
            if(c[i] >= '0' && c[i] <= '9'){//如果遇到数字，就记录到倍数multi，如果遇到连续的数字，就进位组合成更高位数的数字
                multi = multi * 10 + Integer.parseInt(c[i] + "");
            }else if(c[i]=='['){//如果遇到左中括号，倍数进倍数栈，同时把multi置为0，用来记录下一个子串的倍数,当前子串清空
                stack_multi.push(multi);
                stack_strb.push(strb.toString());//记录[]内与倍数倍子串同级的串，例如acd3[b]中的acd
                multi = 0;
                strb = new StringBuilder();
            }else if(c[i]==']'){//如果遇到右中括号，根据当前倍数拼接当前子串和同级的串，生成更外层[]中的子串
                StringBuilder tmp = new StringBuilder();
                int cur_multi = stack_multi.pop();//当前倍数
                for(int j = 0; j < cur_multi; j++){
                    tmp.append(strb);
                }
                strb = new StringBuilder(stack_strb.pop() + tmp);
            }else{//非数字和[]的情况，拼接
                strb.append(c[i]);
            }
        }
        return strb.toString();
    }

收藏，感谢分享

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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