建议你的行动项里增加一个前置项：了解清楚压测的目的。

我说的新老对比，是假设目的已经明确是新老对比。你这里的目的至少从正文看，是不确定的。需要找给你分配任务的领导先沟通清楚这个目的，再做后面的事情。

方向不对，努力白费。在确认方向这件事情上不要含糊，不要凭自己主观推断，必须和任务分配人沟通清楚，最好是你自己按自己理解复述一遍并且分配人觉得没问题，这样来达成一致。要不后面事倍功半。

记录得挺详细的，点个赞。

关于你提的问题，按我目前了解尽量回答下：

1.梯度加压的最大并发量是根据什么设定的呢?还是 10-20-...100 递增或递减？

根据业务场景。比如秒杀场景，是一次性加压上去；如果是用户量逐渐增加的场景，一般是 10-20-30 这样增上去。梯度加压主要的目的是让系统的缓存机制能生效，这样压出来的结果相比没有梯度，会靠谱一些。

2.监控 CPU、内存使用情况：内存是一条横线，有什么意义？CPU 维持在 80%-90% 之间代表什么？

内存是一根横线，说明你这个场景里，系统资源里内存基本是一个相对恒定的值。CPU 保持在 80% 到 90% 说明 CPU 占用较高。综合看就是你这个场景下，系统进行的主要是计算密集型的逻辑。至于怎么判定这样的资源占用是否 OK，那就得结合你实际预计部署这个数据库服务的情况来判定了。

3.平均 Tps 为 7048.0%，对数据库压测来说是高还是低？（肯定比接口测试要高了）

首先，TPS 单位是没有% 的，TPS 是 Transactions per Second。至于是高还是低，需要你根据业务场景去评估，找项目组一起讨论沟通出一个基准值。没有基准值的情况下，这个很难评估。

附一个别人做得 mysql 的基准测试供参考：https://blog.csdn.net/qq_36357820/article/details/80079012

4.得到上述的压测结果后如何去进行分析？

性能分析的目标是找到什么原因导致性能没达到可满足业务需要的水平（目标值）。但你这里目标值都没有定下来，就直接去压，得到的只能是一个数据供以后参考（比如业务量增长到最后打到数据库 TPS 接近你这里的压测水平时，要考虑提前扩容啥的）。

5.我的测试场景是不是有缺失？测试步骤是否有问题？大家都是怎么做的？

首先，你的测试场景个人觉得是有点不够科学的。看似覆盖了增删改查 4 个场景，但里面没看出和这个 “数据库 mycat 分片” 的场景有什么关联。压测目的有点不大明确（到底是测试 mycat 数据库分片相比不分片性能提升的情况，还是测试新方案相比旧方案性能是否有提升，还是别的目的）。

如果是我，我会这么做：

1、先搞清楚压测的目的。个人理解应该最低要求是确认在典型业务场景中，新方案性能要高于旧方案，否则就没意义了。
2、根据压测目的设计测试方案。假如目的是上面说的新方案性能和旧方案对比，那首先需要评估实际业务使用上，数据库使用的典型场景是啥（最简单，执行频率 top10 的 sql 先拉出来看看，顺便也看看分片后 top10 的语句有多少获益），对应设计压测场景（频率高的、执行逻辑上会和分片关联比较大的，都需要纳入进来）。然后新老方案用一样的场景分别压一次，获取到两者的数据，再进行对比。

从报错信息看，报错的时候 jQuery 这个库应该还没初始化完毕，所以 jQuery 这个全局变量暂时还不存在。你可以配合增加一些等待页面加载完毕的函数（比如判断 document.readyState ）

另外，等待 ajax 结束我理解只是技术手段，因为除了 ajax 还有很多其他异步加载的手段。最终目的应该是等待某个你要操作的元素/控件加载完毕，再开始操作吧？如果是，可能对要操作的元素增加 selenium 的显式等待更合适一些。

PS：一楼这种评论让人反感，大家只是友情分享自己所知道的知识而已，没有义务或责任必须给你反馈的。而且工作忙起来没空回也很正常。既然是请教问题，请保持虚心请教的态度。

深有同感，要解决到绩效评估时评的很艰难的话，就得提前做好准备。

我的经验是不要等到评绩效的时候才关注大家的情况，而是日常就要关注，至少 1 个月自己盘一次，能梳理出一个绩效从高到低的排名。对于表现不是太符合预期的，及时进行沟通，避免到后面出 suprise 。

目前需要 @ 社区的管理员 申请，然后管理员会基于申请人的历史话题、回复情况进行审核，审核后开通建专栏的权限。

挺好的 bug 定位和思考，值得大家学习。

PS：千年虫实际上大部分系统都有做好提前防护了，也没有真正产生影响非常大的 bug 吧？

这不算卷吧，而是公司 Hold 不住了，要做精细化管理节约成本。所以光做效能不做业务的，都来做业务。

如果确实不想往业务测试负责人方向走，那就自己想办法跳呗（当然不推荐裸辞哈）。浑浑噩噩等赔偿这个，其实就是拿自己的青春前途去换那个不确定的裁员赔偿。到那个时候，你测开能力可能已经生疏了，也更难找测开的活了。

感谢支持，这其实也只是我个人的感悟，不一定绝对正确。能对大家有帮助就好。

嗯嗯，先适应点点点，然后再进一步熟悉吧。留意自己不要再进入前面这种 等着别人 的懵的状态就好。

点击你自己头像——话题 tab 就有

另外，帖子有人回复的话，右上角会增加通知的，只要养成常看通知的习惯，不会漏的。

那看起来还是 pycharm 的问题。

换个 pycharm 版本，卸载重装再试试吧。

重装 pycharm 还是一样的报错么？

试过换成命令行直接执行，不使用 pycharm 不？

具体怎么搞定的，可以帖子正文末尾补充分享下，方便以后其他人遇到类似问题时查阅？

分享下我自己的理解：
1、冒烟测试（走通主流程）
2、线下功能及逻辑测试（完整验证功能方面的问题，含异常分支逻辑；一般测试环境一轮、预发环境一轮）
3、线下非功能测试（如性能专项测试、关键服务异常的降级策略等，根据测试策略来定）
4、线上验证（发布后线上验证主流程无问题）

我测试的时候，功能和逻辑测试一般是放在一起的，毕竟验证功能的正确性就绕不开逻辑的验证，拆开感觉有点怪怪的。

没有代码细节，只能根据报错信息给个排查方向：

报错信息是说这些 css、js 文件，由于请求获取文件时，返回的 mine type 为 text/html ，且开启了严格 mine 检查机制，所以由于这个类型并非有效的 js/css 文件 mine 类型，这个资源被拒绝应用了。

mine type 具体体现为，network 标签里这些文件资源请求的 response header 里的 content-type 。正常 js 应该是 text/javascript ，css 应该是 text/css 。content-type 一般会被 web 服务器自行根据扩展名进行处理，你这里没有正常处理，有可能是你这个服务对静态资源返回的配置有问题，或者放的位置不对，可以根据这个方向排查下。

如果没有思路，麻烦提供更详细的一些项目配置信息，可以的话最好直接把可重现问题的项目最小源码放到 github 仓库，方便其他人帮你查看。

@debugtalk 看看？

末尾看到欢迎 PR ，但文章里除了 coca 仓库地址外，没见到这个 linkediff 项目地址，是漏贴了？

如果你要测试的是 api 连接工具里对这些认证的支持是否 OK，可以自己写代码建个使用这类型认证的单独接口来测，或者找开发协助弄个接口给你。

话说，这和测试数据没啥关系呀。。。

专题学习里的看书/课程，本身就是一种系统性学习。

如果是说自己作为测试工程师的整体技能需要系统性学习，那可以把这个事情作为一个专题去看测试工程师能力要求相关书籍，梳理出整体技能要求体系，然后再按目前需要做进一步的专题学习。

工作中的学习和学校的学习相比，“学以致用” 比 “循序渐进” 要为重要，因为大部分专业领域的知识到达一定广度和深度后，都是很庞大的，直白点说就是学不完，或者学完不用你就忘了，相当于白学。

1、个人觉得，学习并不见得专门学习的事情才叫学习，工作中接触的一些新领域也是学习，所以日常还是养成一些写工作总结的习惯，记录下来才是自己知识，要不就忘了。

2、工作之外的学习，我一般分两类

2.1 资讯类学习。主要是上下班路上刷一些技术文章查看来学习。通过 rss 聚合一些技术社区的文章，进行查看和学习。这种只需要有个印象，一般不会特意做笔记，觉得好的朋友圈分享下或者收藏下记录下来就好，主要是避免脱节。

2.2 专题学习。这个主要是看自己综合工作内容以及接触的资讯来做比较专题的学习。比如工作上遇到高并发类的问题，处理起来发现自己对高并发了解不够深入，就会去找一些相关课程和书籍系统学习高并发相关知识，并在过程中按照自己理解的结果写学习笔记，方便后续有需要进行查阅。学习资料上，个人不大喜欢通过视频形式学习，讲师的速度有点慢容易走神，比较习惯文章型学习资料，所以主要看书、极客时间课程、官方指南文档等为主。

你太抬举我了，我的文章水平离指导人还差得远。。。

欢迎入行~新入行接触东西，懵逼状态是正常的，关于改变现状这个，几个建议：

1、做好手上被分配的任务。比如导师说熟悉客户端两个模块功能，记录思维导图。那你这个工作自己评价有做到 100 分了么？写完的导图有没有给导师看看，给些优化意见建议？

2、主动解决问题。对于影响自己进度的关键问题，养成主动去解决问题，而不是等着问题被解决的习惯。比如你两天都在等账号申请，而你账号申请的目的是看文档。是不是可以找导师帮忙导出一下这些文档给你看看，或者和导师主动提出你想了解这方面知识，看导师是否有时间给你讲解？

3、沉下心，不要太慌。你现在懵逼主要是因为手上暂时没明确的测试任务，趁这个时候多了解下一些项目流程的东西（怎么了解参照建议 2），有任务开干后，相信你应该就不会懵逼了。

这个没有绝对的谁做更合适的，属于比较模糊一点的地带。产品角度一样可以觉得这个属于线上测试的一部分，所以应该测试人员负责准备。就看最后谁强势一些，能说服另一方去负责这个事情。

我之前呆的公司，这类账号一般产品联合商务去搞定（毕竟有些涉及公司内部资料，还得找公司领导申请），搞定后把相关账号信息同步给开发测试进行配置。

你的客户端（mac 电脑）是有公网 ip，在公网可直接访问的么？一般要穿过公网访问内网的机器，得配置 NAT 之类的东西的。

两台 Mac 可以 ping 通，那这两台 mac 是在同一个内部网络，还是都在公网？

看什么外部系统。

如果是有公共账号可以共用的，测试提供也问题不大，反正有了之后就可以持续用了。

但如果是涉及个人信息不方便共用的，那一般得自己搞定，或者内部征集愿意提供账号的志愿者协助，毕竟这个涉及个人隐私。