非常不错

不过，创建用例的时候，不能保留记录吗，每次，我都得重新设置字段？无法复用

当你被炒鱿鱼的时候，是不是也会很懵逼？

赶紧卷起来，管他要什么功能，越多越好

真的哦，我亲身经历，但凡还是问比较基础的，以及问你一些平时兴趣爱好，不跟你聊技术，不跟你聊工作内容，面试官，就是想尽快结束面试了

薪资区间，跨度好大，7k~12k

当面试官开始问比较基础的问题，比如：“你从你提的许多的 Bug 里挑一个最能体现你深度还有广度的一个 Bug 来？”

就说明面试官，对你之前的回答，不满意，想尽快结束面试。

总的来说，把提取的变量，保存到一个 csv / yaml（任意形式的数据格式），运行的时候把这些变量读取出来

准备：

1. 编写提取变量的语法，在数据驱动的时候，引用这个语法，让程序能够自动获取到该变量值，比如：$validate(变量名，哪里提取的值？)
2. 实现获取完变量值，自动保存到数据文件
3. 编写，使用变量的语法，如：${studentName}，并且程序能够对其识别

使用：

1. 数据驱动用例，使用该提取变量的语法（比如，后续接口需要用到 token，就可以在登录用例，提取 token，$validate('token', 'json.data.token')）
2. 程序开始之后，自动清空，储存数据变量的文件（达到初始化作用）
3. 程序自动识别提取变量的语法，进行提取后，自动储存（已储存：token: skj545qww1qw1sa2s)
4. 程序在用例执行之前，自动获取该数据变量文件，读出所有的变量，并转换为可用变量（即把数据文件格式的变量，保存到对象中，这样变量就成为一个属性了，obj = { token: skj545qww1qw1sa2s } ）
5. 需要用到变量的用例，使用变量，${xx 变量名 xxx}（比如，接口用例的 header: { token: ${token} }）
6. 程序自动识别，使用变量名的用例，自动去变量中寻找对应的变量名，并替换为变量值（自动替换为：token: skj545qww1qw1sa2s）

go 语言，发展前景不错，当然，能学一下 java 会更好，技多不压身嘛，同时也可以提高竞争力

你在写段子吗
“用户量也就一两个”
“每个版本几乎换一个产品”
“用户量增加了 5 个左右，都是熟人的用户量”

大佬，秒杀一切

可以，你做了补充

标准接口测试流程：

1. 根据接口文档，以及需求文档，编写测试用例（功能用例 + 业务用例）
2. 开发提测，进行冒烟测试
3. 校验必填项，组合参数
4. 校验返回值，是否符合预期结果
5. 校验各种业务场景的返回 code 码
6. 校验边界值
7. 校核数据
8. 性能测试

注意：接口测试，要符合需求，可以根据 UI 图进行测试，如果接口有遗漏的地方，要及时提 bug，哪些字段没有返回，哪些功能没有实现，缺了哪些接口

有没有一种可能，聊天记录是加密的？只不过会把聊天记录储存在企业本地。

是的，def int(self,name,level=logging.INFO,file = None):，，这里的 init，，不是 int，，好容易写错这里。

其实，就是，文字表达的时候，规范一下，罗列出来 1,2,3，，，这点提议是好的；

这篇文章，我总结了几个关键点：
1.“两条腿走路，会更稳。”
2.“每天执行的有效用例数不超过 100 个，那有什么意义呢？”
3.“如何设计接口业务场景，如何准备测试数据，如何设计有效的断言，才是接口测试的核心，而不是去追求所谓的接口覆盖率。”
4.“其中 “减少缺陷的出现” 可以通过测试前移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷”
5.“沉迷测试环节，不可忽视整体效能”
6.“应该庆幸测试的门槛越来越高，你才有更多的机会脱颖而出。”

第六点，我觉得，讲的真好，“海上风浪越大，鱼越值钱”

第五点那个，我觉得对于大部分测试人员，很难去实现，这个应该只有测试组长，测试主管级别的才能接触到吧。