100+ 表格，要疯。。。

代码中限制某个 IP 和用户能访问。明天就是那些 IP 和用户。

如果靠预知，请告诉我明天的彩票号码

不准备感觉答不对几道。。。

teardown 吧。teardown 的时候把你排查的时候要看的东西记录下来就行。
现在做的接口项目，我把重试机制直接干掉了，感觉没啥必要。如果报错，肯定是哪里有了问题，没必要重试。（当然不同项目可能不一样）
PS：接口测试，默认稳定。

找好赛道，测试不虚菜鸟开发的。

时刻准备拥抱变化，比如末日降临

我就喜欢这种前端校验的系统，轻松越过验证，可以搞一堆问题出来。

就是搜索框把九宫格键盘调出来，同时按三个键，多点几次就闪退了。
也不一定要同时，反正就瞎点个十几下~

试了下，IOS13.7 上也重现了。

我目前也在用这个，没有对 agileTC 做啥改动（就加了个按 F2 的快捷键修改主文件夹目录名）。
大的测试集，通过左边主文件夹给拆分了，所以一般测试集就一个人的（团队规模小也是一个原因）。缺点就是主文件夹有点多，空了把他这个自动展开全部给改改，这个功能我有点受不了。

测试地位严重依赖产品或者项目。
项目和产品越重要，他的测试越受重视。
出个问题都没人关心的项目，拿测试来有啥用呢？
相反，出个问题损失商誉，直接金钱损失，甚至直接导致拳头产品失败的项目，要是老板不重视测试，就等着现实教做人吧。

工资 2000 的，培训班不屑于介绍。。。

楼上的大叔们，我觉得我永远 18 岁。

请正确区分测试用例和 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，反馈了一下，最终没搞。