mark，感觉前置话术挺重要的而且固定，如果 ai 听得懂很稳定的话是很值得分享的，至于需求那就五花八门了。顺便借楼问下，有没有那个论坛专门分享类似成功案例的

调接口登录，拿 token、cookie 就完事了，不用浪费生命在这个上面

内容划分得细，就说明还是得具体问题具体分析，具体业务具体分析，容错率低的业务只能做预防，容错率高的就可以做预警，毕竟灰度发布做好了比多招十个测试效果都好

好帖，多来一些这种分享测试理论方法在业务场景中的实践和成果的文章。
想起前段时间几个测试技术无用的帖子就呵呵。。。过年了心情好，不然高低整两句

可以把自己不住的房子拿出去出租啊，我想一个月怎么也得有个万八千吧

为了挤出时间看看简历，同时缓解尴尬的气氛

virtualxposed

开权限自己设置

15k/人/月除以 60，这是什么操作。。。

很好奇如果是内测包上了生产，线上验收的时候发现不了吗，不太信哦？我还是觉得有人埋雷的解释更靠谱。。。。

安卓 7 以上版本安装了微信 7 以上版本，无法用 fiddler 抓包，社区里有大佬详细解释的文章，可以看看。
可以用 httpcanary 之类的工具抓包。

我最开始也想做个接口测试平台，功能一大堆，结果用不起来，后面闲着就做了很多 devops 的工具放在平台上，比如批量推送，根据 jira 自动推送，自动搭建环境等等都是些小玩意，结果用的人很多，再后来改进了下原来的接口测试功能，把它变成了个执行 shell 命令的东西，就变得很火热了，因为测试经常要使用 curl 来调接口，这个平台能保存命令就比 xshell 方便。总结下来我觉着只有解决了别人的需求，工具才能得到推广。

脱离场景只对接口做自动化，虽然很省事，但是用例维护后期起来很麻烦。二个是在数据库构造数据就要在用例里写 sql，表结构一变化脚本大概率就要 gg。我曾经 2000 多个用例因为表结构变化全部 gg，写了个处理字符串的方法把多的字段剔除，少的补上，但我的用例全部是基于构造数据的 sql 设计的，sql 都变了用例可靠性还有多少，无法再维护。
失败的经验一大堆，总结起来就一句话，产品如果不配做自动化咋样都做不起来。

新手有机会得学习下怎么部署，如果你们不是物联网最好不要转实施，没前途，物联网的话可以考虑考虑，老油条的话看情况看心情喽。

不是有 beanshell 断言吗，写代码呗

看了下，官方推荐教材软件评测师教程是 2004 年出版的，我很无语。。。相应的软件设计师教程都出到第五版了，最新的 2018 年出版，感觉这个含金量差距有点大

期待新增个打开以前报告的入口。