没有特意坚持学（特指比如每天背单词几分钟之类的），但有坚持用，避免自己技能退化。
用法嘛，包括系统改为全英文、多看国外开源框架相关英文文档、代码里日志和注释写全英文、尝试看英文电影不带中文字幕等。

至于作用，就是你可以领略到国外开源文档和技术文章的严谨性和全面性。同样的开源框架或工具，国内大部分文章偏实战，基本就是一句话的 why ，what ，然后大篇幅的 how 。国外 why、what 这些写得会清晰很多，也会有一些相互对比、数据说话，当然最好的还是官方文档，毕竟 why、what 这些作者自己是感受最深的。

PS：我的经历有个特殊的点，之前有在外企待过 2 年，经历过每周一次全英和老外的周会、内部全部邮件、文档（写和读）、软件全英文，所以那个时候已经逐渐克服了看英文文档困难症（学校做题一个阅读题基本不超过一千个单词，但实际你看文档过千是常态），听和说也不至于太生疏了。
当然这个是个人经历，暂时也没想到什么特别好的替代办法，也许可以考虑报下那种每天老外和你纯英电话聊十几分钟的？

正常 web 应用，服务端很多操作最后都会进行数据库落库，所以需要通过查询数据库确认落库数据是否正确（比如一个注册接口，注册成功那用户表就应该有记录这个用户的账号密码这方面的信息，没记录就是严重 bug 了）。
同时也会需要通过改一些数据库信息，进行一些场景的模拟。

不过用的大部分还是基础的增删改查，存储过程啥的基本也不大会涉及。

北京因为疫情原因取消了，不过除了深圳的线下，还会有不定期的线上 live 分享，敬请留意~

jenkins 执行的时候，执行的是当时拉下来的用例副本，正常情况下执行过程中不会再更新用例（更新代码）。所以我理解你说的问题应该不存在？

具体你的热点是怎么分享的，操作步骤说下？

你就想象要把步骤写得详细到另一个人按照你的步骤能把你的环境完全复现出来，文字说不清的可以用截图来说明。现在步骤信息还是太少。

都是面向对象，我理解两个语言在类和方法方面差异没那么大。

你说不能点出来，指的应该是 ide 的自动补全吧。python 是弱类型语言，所以不会要求声明时明确对象类型。java 是强类型语言，这个是一个差异。

但强弱类型的差异只是写法上的差异以及编译器是否能直接判断而已。不管哪个语言，你那个对象实际类型需要是 driver 这个是没有变的。pycharm 这类 ide 也很聪明，会通过你的代码去推断对象类型，进而给出对应的提示。你没给出提示，说明 ide 没能推断出类型（比如你用反射赋值的类型，就无法通过代码直接推断，得运行时才知道）。

PS：我看到一个没太理解的地方。你最上面的 BasePage 类，声明了 self.driver = driver 后，没见到哪里用到这个 self.driver 呀，HomePage 类也是一样。self 和 self.driver 是两个完全不同的对象。python 的 self 约等价于 java 的 this 。你写 java 也应该是 this.driver.findElement(xx) 吧？

testcase 里也用了 cls.driver.get("https://support.lenovo.com/us/en") 来调用 driver 子方法，为啥 page 类里就不这么用了呢？

AttributeError: 'NoneType' object has no attribute 'send_keys' ，说明你的 self.find_element(*loc) 返回 None ，等价于 Java 返回了 null 。
然后你就可以类比 java 的解决方法，看下为何这个找元素返回的是 None 了。一般来说，找元素找不到，应该会抛异常而不是直接返回 None 的。

说详细点，用 charles 抓包，charles 和手机上的详细配置是怎样的？

听起来像是有些关键配置没配对，所以抓不到。但这里信息量太少，猜不到是哪里有问题。

总结挺不错的，最关键的点都把控得很好，特别是商品模板的，很明确用户需要什么，而不仅仅是平台可以做什么，点赞！

对于 1，也认同你的观点。我说的核心点是自动化不能完全取代回归测试，所以不要以通过自动化完全取代回归测试为出发点开展自动化。
对于 2，我不是很认同。我觉得要做到是很有挑战，而且确实要非常准确评估，会非常难。但并非完全不可以。对于被测系统相对不是非常复杂，改动点不是非常巨大的情况下，大方向的评估还是可以做到的，这种评估本身其实也能让自己更好地缩小回归范围。至少可以避免开发做完改动，随口说一句 “影响范围：建议全功能都回归下” 时，自己很难做判断。

另外，code review 这个职责确实是开发本身的职责，但不代表测试不可以参与，或者测试不能用这个工具。有些改动不大，逻辑比较清晰的改动（比如 sql 查询条件加一个 isDel 的判断条件，或者加个 try catch 保障一些已知异常不至于让整个程序垮掉），通过 code review 评估风险不大后，直接快速上线，也是可行的？

感觉 why 这个层面说得很到位了，解决了一些实际场景存在的问题，思路也挺不错的。

期望关于平台完整的功能设计，可以说得更详细一些，配上一些截图说明更佳~

感觉最近社区有不少人突然意识到自己 30+ 了，感觉还在一线/还没转管理，比较焦虑。

其实可以反过来想下，自己 35 岁想要达到什么水平，现在继续这个状态是否能达到？如果可以，那保持就行。如果不行，那就要加把劲找下转机。

管理岗这个，要看公司和机遇，一般小公司机会会多一些。不过关键点还是你自己，包括团队协调能力、影响力等。能力强、表现出色，上面 leader 一走首选接班人就是你，就算不走，你自己做个 B 岗也能学习不少。

从大的 IT 行业来看，可能更多的 35+ 转管理前途会更宽广（更符合大部分公司的需要），但具体到每个人都是个体，也有 35+ 还在一线而且做得还非常不错的呀。

这个类比很有意思，不过也确实在理。

这种事都是高级开发，什么架构师的工作

可能说得直白点，这种思想才是阻碍你前进的最大原因。心里都想着最关键的、最有价值的都是别人的工作，那你自然只会去做不关键、价值不高的工作呀。实际大部分情况是，不是因为你有这个 tittle ，所以给你这个活，而是因为你表现出了能干这个活，别人才给你这个 tittle 。

测试就点点点就好了，整这么多概念，倒是给点实例，给点可行性的案例啊

建议看看社区里很受欢迎的这篇文章，里面的例子你应该会有点感觉：聊一聊职业发展

35 前对开发来说升级大多应该还是挺平稳的，那测试？

不知道这个结论怎么得出来的？至少我自己身边没感受到开发有这样的 “平稳” 气氛。

如果把测试看成只是检查质量，那确实价值不大。因为有没有你，质量都在那里，不升不降。

但如果把测试看成保障质量，那价值就不一样了。你能去让开发、产品提高质量，甚至参与到需求、技术设计中把控方向，减少故障损失成本，创造价值。别小看保障质量的价值，小则减少故障损失，大则简化和提炼需求及设计（简单本身也代表着出问题概率的减少）。最终能节省成本，以及缩短交付时间，间接增加收入（互联网行业，都是在抢速度，第一名可以获得很多额外红利）。

365 行，行行出状元，而且当你成为状元时，你可以选择的行当可能也更多了。当你深度和广度到一定程度时，你就发现你可以不只是局限在测试了，可以跨界到研发团队管理，甚至负责一个业务线。如果你的深度和广度不变，那永远是工具人，不至于没有价值，但可替代性很强，过几年就会被更年轻的人替代。

按影响程度定级，每个月统计各个级别的数量。看影响比较严重的级别个数是否在下降。

同时做好每次影响严重故障的复盘，落实改进措施。相比大的统计数据，找到根因、避免再犯更重要。

正统一点的手段，基础会比较扎实一些：
1、看招聘，各家公司测试工程师的岗位要求和内容描述，提取会被多次提到的项，了解下行业最需要的时候什么
2、看书，比如《全程软件测试》，对目前软件测试的方方面面有个大致的了解
3、基于 1、2，选择在项目中能用得上的技能或工具，重点突破，做出成果，踏出第一步

但耗时比较长，需要耐心和坚持。建议你直接跳到 3，找一个有价值的点单点突破，突破过程中你会发现你的广度和深度都会随着不断突破而扩大。

可是可能能力太低知识面不广，发现不了什么问题

你可以详细记录下自己在项目中的各个阶段的耗时（比如熟悉需求、设计用例、执行用例、输出报告等）及自己的熟练度，看看哪部分耗时长，熟练度不高。这就是你的潜力。也建议可以和你的老大沟通交流下，也许能得到一些启发。或者最简单，比较下自己的工作效率和组里面其他人相比，哪些方面比别人差，去学习提高。

看完这个简历，如果我是面试官，可能会问几个问题。你可以自己先想下是否都能答到面试官满意的水平，然后取舍它们是否需要按现在的描述继续留在简历里：

1、使用过 java 开发 web 项目，详细说明下是什么样的项目，使用什么框架，你在里面具体负责哪些模块，详细说下它的设计？
2、你的 java 开发 web 项目经验，在你实际的测试中有起到怎样的帮助，举个具体例子说明下？
3、你这里提到有 UI 、接口自动化的熟练掌握，那具体在哪些项目里有应用，效果如何？你在里面具体负责什么？
4、掌握一定的 SQL 语句，那比如现在有两个 xx 表，我要找到 xxx ，写下对应的 sql 查询语句？
5、熟练掌握 java 基础，那如果满分 5 分，你觉得自己的 java 水平大概多少分，为什么？
6、熟练使用 fiddler 抓包，能否说明下如果要用 fiddler 抓取 https 的请求，怎么配置？有没有遇到过配置后还是抓不到 https 包的场景，如果有，你理解为何抓不到？
（都是确认简历上你写的经验，实际深度怎样）

7、你最近经历的项目是哪个，能不能以最近一个需求作为例子，详细说下你当时是怎么做测试分析的，这个项目的核心点是什么，质量风险集中在哪里，你是怎么对应应对的？
8、现在有个 xx 场景，请设计一下它的测试用例？
9、你对你的未来职业规划大概是怎样的，有没有想过 3 年后自己要达到怎样的水平？
10、对于这个 3 年后目标，你目前有在做怎样的努力，比如近期有在学习什么？
（相对通用的场景，看你是怎么做测试的，以及对自己未来怎么思考。特别是你中间还有做过产品助理，转过方向）

PS：对于项目经验，核心点是写项目内容、你负责的内容、最后的成果（比如上线后 0 故障；建立起 100+ 自动化用例，缩短测试时间 xx%；通过云服务器的有效管理，环境稳定性提升 xx%；或者别的你觉得是亮点的结果）。前两个是铺垫，拉不开差距，成果才是关键，才能让别人知道你做到什么程度，是芸芸众生还是与众不同。当然这个成果也不要夸大，要不问到发现是假消息，效果更差。

合伙或者创业，我理解都是大家奔着一个梦想、一个长期的目标一起去努力，去改变世界。比如阿里的” 让世界没有难做的生意 “。

但你这里提供的信息完全没提及这个目标，” 一起搞事情 “也没说清楚搞什么事情，那别人怎么会愿意和你合伙或者合作呢？

坦白说，这介绍太简略了，吸引力真不强。至少需要把这个饼花清楚一点，好吃一点？

建议可以说详细点，具体怎样的软件定制（业务未来），对这个测试小伙伴期望是什么（个人发展），大致能给到的待遇或者期权如何（薪酬回报）？

如果要爬这个元素树，思路上可以把这个 xml 当做 html 源码，给 bs4 去捞取有效数据。

个人更建议先抓包看看情况，如果没有加解密，或者虽然用 https 但没有做强证书校验，不妨考虑直接抓包后模拟请求获取数据。一般网络接口返回的数据直接就是 json 格式，非常容易解析，比你 app 绕个圈好很多，而且不用去处理持续滚动等场景。

666，前 3 行还以为是脉脉平均水平，最后反转好大。。。

楼主可以拐个弯，既然一个 case 可以有多个 api ，那是否也可以只有 1 个 api ？单 api 针对不同输入，是否可以变为多个 case ，每个 case 只有一个 step ，即只调用一个 api ？

至于 testsuite ，代表测试套件，或者叫用例组。面向的场景是一次性要执行多个用例（比如要执行所有单接口用例）。

1、感觉楼主是类似安全爆破的思维，把可能的组合和场景都列出逐一执行。顺着这个思维可以参考 @ 测试小书童 的文章，了解下 all pairs 的组合思想，在能找到尽可能多的问题前提下减少组合数量
2、但也建议楼主可以从另一个角度来看。一个是这个接口的 100+ 用例，成本不低，但执行后是否有发现有价值的问题？另一个是，有些校验会不会其实代码里已经用很简单的方式写了，或者其实风险不大（比如起始结束时间，是否直接透传给了 model 层拼接形成查询语句）？

个人经验：
1、现在框架的封装性很强的，开发一个注解就能设定默认值、最基础的校验规则，为了这个做接口测试的单一字段校验（空值、类型不一致、长度不符合等），性价比不高，更建议通过 review 确认。可以了解下 swagger 注解和 JSR303 ，看楼主给的接口文档应该就是 swagger-ui 生成的。
2、分页如果用了合适的框架和正确的用法，基本不会有低级错误存在的可能性（如溢出页会报错）。同样可以通过 review 确认。
3、参数组合在查询类接口，最终其实还是组合成了 sql 进行查询。所以确认组合 sql 的部分逻辑有没有问题（比如用 AND 还是用 OR ），基本风险就控制住了。也是 review 可以确认或者去掉那些风险不高的组合的。

日志中没看出 test_b 有执行通过呀。
貌似这个插件文档里，没提及它具备自动追溯依赖用例并自动执行的能力吧？