你这个不是测试环境维护，明明只是代码版本维护。。。我们测试环境里面的数据是测试维护，测试环境的库表之类的开发来维护。至于代码版本，测试有需要就测试自己维护，开发想自测就自己去构建一个

防御性编程了解一下

2020 年的时候谷歌还是有测试开发。但我们没有叫做 qe 的岗位，或者说没有相当于国内手工测试的岗位

就是随时可以当半个开发用，擅长自动化测试。涉及 cicd，部署，灰度，等等的测试

在没有外部依赖的情况下，全链路是有用的。但是如果有很多外部依赖，外部依赖不稳定，或者本身测试环境数据不稳定的情况下，都会对全链路造成影响。另外这个所谓的全链路，其实就是端到端的意思？E2E 测试？

所以之前买了高价票的亏了就亏了咯？

assert A==B, "如果断言失败那么你会看到这条信息"。assert 的第二个参数里面填上你的响应，断言失败会自动把这个响应打出来

测试下单接口的时候应该先调用前两个接口，再用生成的数据调用下单接口。因为万一前面接口的结果变了，你直接构造的数据没变，实际上就漏测了

如果你们用的是 protobuf，有数据字段约束，自然也可以根据反射知道字段类型来生成数据。至于有些字段长有些字段短，自然需要生成器读取某个配置文件，让他知道哪些字段该怎么生成

有时间限制吗？没有那慢慢跑慢慢造就是了。如果有时间限制，那你要考虑一下大数据量的瓶颈应该是文件写入，所以其实也是有一个极限速度的

python 可以写 web 服务器
还可以写联邦学习，fateai 了解一下
简单来说就是想快速原型可以试试 python

你这个 var 是中间变量值，要传递出去无非就是调用 fun4 的时候当作参数传进去。或者在类 A 里面加个类变量存这个 var，然后 fun4 里面拿去用。

你这个描述让人疑惑的地方是，又说 fun2 是框架源码你改不了，另一边你第一条回复又说类 A 你能改，到底哪里能改哪里不能改你自己都说不清楚。。

selenium, docker, k8s, jenkins, gitlab CI/CD

你说要测这个导航系统吧，但是给的 api 全是这么底层的，明明只要开放一点接口就能做到的事情，非要从底层 api 堆叠回本应该提供的接口，何苦呢。

而且如果提供真正的公有接口，测试能把从接口到实际 ui 显示都给测了。现在这样你只能测 ui，出问题你还是得再 debug 确定问题是接口数据，还是画 ui 的时候出得问题，自己给自己添麻烦

docker k8s.说真的我觉得测试没什么新兴的技术，你就按开发的新兴技术去找就好了

什么叫 “在生产环境经常有数据不准确的情况发生”？是逻辑错误还是啥？

学开发，然后开发转测试算降维打击。但如果先学测试，测试转开发就得两个都学一遍

不是持续集成，只要有代码进库，自动就会去跑测试的吗？

测试是为了质量和速度。质量自然是少 bug。速度，是提交的代码到实际发布中间的距离。如果测试足够快，覆盖率够高，而且我们对测试的覆盖率有信心，发布就会很方便和快，甚至可以做自动化发布。比如最开始没有测试的时候，开发要自己跑手动测试，手动发布，而且因为是手动，其实很容易错。所以每个星期能发一版。而且开发要自测某个新写的 feature 会不会把其他 feature 炸掉也很麻烦。但如果有足够的自动化测试，自测就会很简单，一个命令，出去喝杯茶什么的，回来就可以了。发布也可以自动化，然后就能做到每天，甚至不断发版。

谷歌的 sde 和测试，面试内容是一样的就算法题，你说呢

额，不追 nba。。

在西雅图谷歌，找不到对象可能要回国了

除了找对象，一切都很好

对公司来说代码不应该安全级别高，生产环境的数据才是应该保护好的

我觉得测试最重要的还是对你要测的产品有所提升，无论是产品的质量，还是开发组的效率，其实都可以靠测试的

1. 产品 release 周期多少，能不能继续缩短？自动化 release 吗？
2. 测试对 feature 的覆盖度？或者测试对生产环境的覆盖度？
3. 测试要跑多久？能不能再提高？

不清楚你们产品和测试的规模，所以也很难继续想更多的细节

可以试着把不确定的项目转化为确定的方向，或者把不确定的项目的某些部分，转变成确定方向的问题