其实我是建议用 java 的同学尝试下 kotlin，这个语言还是很棒的。他在语法上比 Python 还强大。
不过选择语言是次要的，选择生态最重要。公司要用 Spark、Flink，你就得老老实实的用 jvm 系列的语言。公司用 TensorFlow 就得老老实实的用 Python 或者 Go。

你这 Uiautomatorviewer 是自己改造的吧。先获取父层控件的定位，然后再根据相对坐标进行定位就可以了。父窗体的坐标结合屏幕宽度的三分之一来动态计算你想要控件的坐标。这种方式通用性好，技术实现成本最低。其他的 oc 图像识别也可以考虑，不过复杂了。appium 的最新版本的 client 支持图形识别的。

对的，大厂的外包其实不如创业公司的普通测试。因为没有办法接触源代码只能进行普通的黑盒测试，长此以往容易形成不好的工作习惯。

日期那个 bug 的确诡异，我觉得不用强求自己吧。虽然可以马后炮的总结是边界值问题，但是这类问题不应该由测试发现问题，责任不在你的。

第二个 4G 的问题，4G 和 wifi 的网络路由是不一样的，应该是 dns 或者 cdn 的问题，是公司服务部署问题，不太像弱网问题。

定位问题的确是弱网问题

总体感觉你在这些事情没能体现出积极推动问题解决的良好态度，也没体现出解决问题定位出问题根源的能力，所以给公司留下了一个不好的印象，而公司也不懂这些问题细节，从表面上判断就会容易得出不称职的表现。

技术能力问题你可以多关注你报名的课程，上课的时候我也重点讲解下你这个场景和测试方法。而态度问题你需要在工作中多领悟找到解决问题的正确办法，积极沟通总结，给出问题的定性解答，而不是坐等结果。

8.0 的 bug，需要打补丁。建议还是换个低版本测试吧

• AI 虚火

• 大数据应用非常成熟

• hadoop spark

• ai 算法 调参 优化 很难找工作的

• ai 应用

• 算法测试 数据测试 更受重用

RestAssured Swagger yapi

专业能力 + 管理能力 短板会一定程度制约发展。两个方向都可以考虑

• 角色融合是大趋势
• QA 价值不变，但是 QA 是谁来承担是依靠实力决定的

测试开发工程师不等于懂 web 开发的测试工程师。

• toB 的测试地位更高
• toB 与 toC 的区别是国内的主要区别
• 外企也分两种情况 fb google 互联网公司 传统的 IBM Oracle 公司

去外面面试测试下自己的能力

• 投简历 内推
• 技术题 算法 数据结构 leecode
• 项目经验 技术深度
• 情商测试、价值观

深入去解决好具体的业务问题
不要脱离业务
深入业务场景

• 组建 L3 团队

• 提升质量，调整版本发布节奏

• 裁员潮在全行业都会有

• 提升能力

• 能力发展速度跟不上年龄增长速度
• 价值发挥要从个人扩大到团队
• 三年的经验用了十年
• 技术深度、职业发展高度都是可以继续往上走

年薪 100w，精通 devops 的专家。最怕的是 30 岁以后增长的只有年龄和体重。

• 场景覆盖
• 更多业务数据分析与断言

我觉得就是能力不行吧，跟年龄大小无关。你具备了自动化的知识但是不具备真正的自动化能力，知行合一没达到。未达到这个能力又拿到了这个薪水我觉得全靠你的年龄在顶着。别人在乎年龄的因素多是在乎一个人未在对应的年龄里具备对应的能力，年龄越大公司的期望能力也会越高。

我觉得你可以多结交几个经验丰富的朋友多跟别人交流学习下，自己的团队也可以招聘个优秀的新人让他带起来成长节奏

每个店铺都这样吗

header 也是接口传参的一部分，比如 cookie 就是 header 的其中之一，所以 header 也是一个重要的输入源。要不要传需要看你的业务需要。我的建议是抓包分析下，并尽量全部传递。这种传递不是要你每个用例都挂上一遍，而是借助于框架的机制做下封装即可。

这次虽然是彩蛋，其实也带来了一个对测试和 QA 很严重的挑战，“开发者往代码里下毒如何办？”

问题描述

无论是处于好心的彩蛋，还是恶意的留后门，或者是无意间留下的 bug，都会给人类埋下一枚巨大的地雷。这类的问题其实在质量的历史上曾经出现过很多次类似的问题，千年虫、int 类型溢出、md5 碰撞等问题，基本上阿里、腾讯、百度、京东等大大小小的公司的公司都经历过。这类 bug 的特征就是，在时间、环境、数据量变化的前提下会一定概率发生错乱，与其上考验的是测试能力，还不如说考验的是开发者架构能力。

我先抛出几个类似的历史上的严重质量威胁给大家做个参考，因为一时找不到对应的新闻和源代码分析了，所以就简单记录下大概的事情。后面再补充完善细节。

常见的类似问题

• 千年虫问题（暴露年龄了。。。）
• Linux 源代码后门提交问题，有不明身份的人伪装开发者提交一段暗藏后门的代码给 linux，结果被发现。
• mac 后门问题，开发者写错了一个符号， 把==写成了=，或者 if else 里少写了{}导致分支走向错误。
• vue 依赖的组件后门事件，不明组织社工开源开发者，窃取帐号后故意在升级中加入挖矿或窃取比特币的逻辑
• int 类型溢出，当公司的业务量上升后，会超过 int 类型可以表达的范围出错，这个问题几乎 BAT 都被坑过
• MD5 碰撞问题，因为 hash 算法设计问题导致会有一定概率重复，导致账号和订单可能会存在串号和信息读取错误等。

解决思路

我提几个预防这类问题的方法

对 changelog 和 diff 做 code review

这是个常规的办法，不过考虑到全世界人类使用的开源项目和 lib 数量已经超百万级别，我觉得靠人已经没办法做到了。只能挑重点的项目，以及依赖开源项目自己完善的管理。当年就有黑客伪装开发者提 merge request 给 linux 项目想暴露一个后门，幸好被 linux 开源项目组的人发现并禁止了。如果没有 review 机制，大家可以想象有多可怕，全世界的服务器都可能会被不明组织入侵。而 vue 依赖的组件后门事件则没这么幸运了，导致了爆发

关注未被覆盖的代码覆盖率和特性

这个是更有效的发现方法，为什么这么说那。大家知道每家公司的工程师都喜欢在自己的 app 里保留一个调试的后门页面。如果有的时候配置错了就会暴露，比如淘宝和微博就暴露过。这说明了什么那，在正常的功能之外还故意隐藏了一些后门，这些后门的代码其实就隐藏在 app 中，只是大家常规情况下看不到，只要触发了特定的条件就会出现。这既可能是特型开关，也可能是无意留下的开启地狱之门的钥匙。借助于对代码做模型分析和代码路径统计，其实就可以找出来所有隐藏的功能。

源代码智能分析

学术界和黑客界也有一些不错的工具在批量分析开源项目的各种代码分支和数据流走向，尝试发现一些异常问题，我在百度的时候也遇到有项目组在研究这个。大概的做法就是分析所有的代码可能走向，可以是静态代码分析也可能是动态调试技术。尝试分析所有的可能路径，然后判断什么样的输入会带来什么样的问题。这个比较学术，难度挺高。工业界还没有大规模应用，sonarqube 只是一个通用的规则列表，发现的问题还达不到这个深度。不过的确也是一个方向，可能自动发现很多代码问题。也许 sonarqube 可能会越来越能接近这个目标。

人类社会的发展是要重度依赖计算机的，而计算的正确性如何保证是一个任重道远的事情。如何提前发现这类的问题那，欢迎测试行业的同学们多积极的思考。

这个活动下周三开始。一周的时间收集问题

经典问题，到时候一起聊

ai 那个 topic 写上公司名吧，还不知道是哪家公司。