个人观点：

比较稳定且需要重复测试的，可以用自动化。

不稳定但自动化测起来比人工快的（比如各种字段校验），也可以用自动化。

把你具体代码和哪里出错的，都贴下？看起来是你输出结果太多，导致没输出完就开始报错，所以混在一起了。

想了解下，你的项目到底是用的啥协议？基于 http 但 http body 内容是二进制数据（如 proto buffer），还是基于 tcp 的非 http 协议？

socket 只是程序里对网络通讯的统称，http 属于应用层，tcp 属于传输层。http 底层传输用的是 tcp 。

另外，大部分抓包工具是基于 http proxy 的，如果你的项目用的本身就不是 http ，那自然抓不到。

这个也还是挺流行的，好处是通过 orm 直接一个 model 层搞定数据库和后台管理系统，模式也比较简单易上手。目前测试平台比较流行的技术栈应该是 vue 前端 +spring boot 后端。

其实不用那么纠结，选一个持续去使用就好。不同的框架各有各的好处，做深了都很强大，而且对于大部分需求都能满足。不同的框架，背后思想其实也会有共通性，其中一个掌握透彻了，转其他的也不会太难。大部分框架流行的原因，主要是上手成本相对低同时通用性比较强，但不用花那么多时间在选型上，选个不至于太偏门，太难上手的就好。

个人感觉，过时的是用语言自带 GUI 框架这种形式。

目前比较流行是用 h5 ，一次开发覆盖全平台（手机客户端、电脑客户端、各种浏览器）。

打算自己写一点，他们打开 apk 就能进行自动化操作

这个” 写一点 “的概念有点模糊。具体是指脚本都写好，同事只需要一键执行和看结果？还是只写好基础函数，同事通过 apk 录制之类的手段生成脚本和执行？

从楼主的问题和二楼的回答来看，医生、律师、老师基本都是时间越长，经验越丰富，越吃香。楼主其实想问的是 测试会越老越吃香 吗？
我想到的答案是：不绝对。如果是普通一线的，基本不会，年轻的有冲劲、薪酬要求低，肯定更符合公司长期发展需要。但如果能持续上升，做到管理，甚至突破测试带整个研发、整个业务，那是可以干大半辈子的。

看到楼主发了很多和职业发展、长期规划有关的文章。做规划是好的，但也要做比较有把握的规划。10 年后的世界都已经很难预估了，何况一辈子？个人觉得，最能把控的规划是 1 年左右的规划，如果想要有远见一点，5 年我觉得已经是挺长的了。一辈子，想破脑袋其实也没啥用，还是先专注眼前吧。

看起来不错，开箱即用。

众口难调。。。

分享个小技巧，可以直接按住 ctrl 再点击，这样点击后就会在新标签页打开了，操作起来也比较方便。chrome 确认可行，其它浏览器没试过。

把你完整的用例贴上来吧，你这个描述没太完全知道你用例是怎么写的，也不好说应该怎么优化写法。

不过有个点想确认下，你有使用了 unittest 这类测试用例执行管理的框架么？如果没有，可以了解试用下。你说的这些问题只要按照这些框架的写法去写，都不应该会出现。

http://www.monitor.com/admin/

这个地址貌似被重定向到另外的站点了？

建议理清 A 和 B 的关系。如果耦合度低到能放在两个 job 分别构建部署，我理解其实也不大需要放在同一个 git 仓库里？

感谢分享，试用了下，挺不错的，代码块支持也不错。

目前社区是自己做了个额外的渲染页面，把渲染出来的 html 增加自定义 css ，来让公众号的样式看起来好一些，主要优点是确保 markdown 转 html 的转换语法和社区 web 界面是一样的（不同 markdown 渲染器，对于换行、空行等的识别会有点差异，容易造成格式问题）。

不过标题的样式目前只是通过字号和颜色区分，没有这个工具那么好看（第一级到第四级标题都有些不同，而且都挺不错）。后面可以参照下这个 css 优化下样式

1、触发回放时请求的 appName 为什么传入 unknown

这个是默认值，因为我们没有特意配置这个 app 的名称。

2、回放时，返回的 ID 还是递增的，没理解

不知道你具体是哪个 id ，方便发下具体的请求和返回报文么？

3、回放时，除传入的 traceId，其他参数传与不传返回的结果不一样，是在真实的应用中回放，都要带上参数，还是有其他方式可以，我理解这个录制应该是有把传参也录制了下来的，是不支持还是进行二次开发在回放时不需要传参

没太理解你的问题。回放时有两个地方有请求参数，一个是给 console 一个执行回放的请求（facade/api/repeat/unknown/192168015059156326967477410002ed），另一个是 console 执行回放时产生的给被测应用的请求。第二个给被测应用的请求里面的参数，console 会自动把它按照录制时一模一样地发出，没有提供可以调整的入口。

最近没怎么研究这个了，建议你到官方提下 issue 吧

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

至于作用，就是你可以领略到国外开源文档和技术文章的严谨性和全面性。同样的开源框架或工具，国内大部分文章偏实战，基本就是一句话的 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 评估风险不大后，直接快速上线，也是可行的？