建议你用 精准测试 这样的关键词来找资料，有不少公司有研究过根据代码变更记录倒推影响什么 api 接口的。不过目前基本没有直接可以拿来用的开源方案，都是公司内部自研。

已收藏~

不错，模块划分挺清晰的，加油。

提个小建议，代码里不大建议 hard code 一些设备序列号之类的信息，这样以后换设备之类的调整起来会很麻烦。建议至少抽离到配置文件，可以的话做到自动适配不用写死在框架或脚本里。

不明白为啥说带宽占用会过高？这个回传只是个很简单的数据回传，对带宽的占用比压测要低得多吧。

而且都用上 slave 了，想要提高并发能力直接增加 slave ，解决成本不是比改造这里更低，也更有效？

已删除。

不知道你这里的代理是啥代理？

我理解完全可以配置成用公司指定 wifi 时，这个 wifi 上的这个域名直接解析到测试环境的。这个配置完全不涉及任何代理相关的东西，只需要改 wifi 提供的 DNS 中的域名解析记录就好了。

具体邮件内容发下，我们确认下是不是社区系统发出的？

目前社区后台没有解绑 github 的功能，手动修数倒是可以，但主要是没太看懂你的目的是什么，不知道解绑是不是最佳方式。

如果你是想用现在的 github 账号再注册一个，那效果和现在这个有啥不同呢？

如果你是想直接删除账户而由于没有密码无法删除的话，我们可以协助操作删除，但删除后这个绑定的 github 账户能否再注册新账号可能还得测试下，以前没这么操作过。

问题是个好问题，怎么把团队气氛从产品质量是测试负责的，变成是整个团队负责的，感觉下面评论有点歪楼了，都在探讨测试背锅。。。

个人观点，这个需要让团队多看一些怎么提高质量的资料或者案例，让大家逐步意识到自己对提高质量也是能起到作用的。同时也需要测试主动出击，借助一些线上问题案例，去给产品、开发普及他们做些什么，可以更有助于保障质量，让他们明白 “质量内建” 的含义。一般团队这么大，应该也还是会有 1-2 个比较认同质量内建的，可以先从他们入手。

至于背锅吧，我是觉得每个线上问题都不大可能是一方的责任，肯定是多方都没做好造成的（以前看空难纪录片，里面也总是强调每一个空难，都不是一个失误就能造成的，都是一连串失误共同造成的结果），所以有锅一起背就好，其实一般锅也不会很大。如果说背个线上问题的锅就会被辞退，那我觉得这个团队也没啥必要久待了，几年前沸沸扬扬的 gitlab 删库线上问题，最后 gitlab 也没有辞退那哥们，反而是觉得花了这么大成本让他掌握了这种严重线上故障修复的技能，辞退太浪费了。

你可网上搜一下，wireshark 抓到包，根据包内容就可以知道走的是什么协议的。

有可能开发用的是封装好的框架，所以也接触不到底层用啥协议。

个人观点：

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

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

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

想了解下，你的项目到底是用的啥协议？基于 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 吧