还没怀上

work life balance，很赞

拿到这么多 offer ，厉害。加油，继续追逐你的 dream 吧~

客气啦，和大牛比还差得远。

感谢大家支持

嗯嗯，也在内部争取一些管理的机会，不过也要看机遇。项目 owner 也是我的目标，但这个对业务的熟悉度和把控度会有更高的要求，还需要加把劲。

以前关注用户体验的公司，会要求研发团队的同学自己日常也需要用自家公司的产品，在用户角度去使用、感受自己测试产品的用户体验。这种情况下，其实比只是测试过程使用，能更容易感知和发现用户体验问题。

但现在好像越来越少了。

幸存者偏差吧。不见得每个人都会写，写了都会发出来。有时候愿意发出来，一般都是觉得写得不错的。

确实每一年不一定都有很多收获，也可能原地踏步，波澜不惊，甚至自己觉得在倒退。但写下来至少能让自己正视一下过去一年的自己，知道什么做得好（你会有自豪感）可以继续做，什么做得不好（你会很犹豫写不写甚至不想写），是突破还是避让。吾日三省吾身，做一下自省，会有助于你更清晰自己的现状，顺道思考下自己想要什么，接下来这一年可以做什么来达到自己的目标。

1.比如登录接口我是需要把 ” 登陆成功 “，” 密码错误 “，” 账号不存在 “这三种情况的接口都写一遍吗，有多少种异常就写多少次

看用例优先级，一般成功用例是必须要有的，异常的一般会需要造数据啥的，会复杂一些。建议先保障主流程，按主流程顺序调用各个接口并保证成功，再在这个基础上加上每个接口的异常场景。

2.前几天跟别人聊，人家说他们的自动化是，接口 UI 合在一个代码里。想问下那种是怎么做的？

既然都是代码，用不同的函数就可以调不同的库，进而做不同的事情吧。

3.我这种方法是不是不如测试平台好啊，是不是找个开源的测试平台我这些问题就都能解决啊？

个人也更建议你搞个开源的平台，写代码好处是方便，但缺点是对于没经验的新手，需要额外学习很多框架使用方式之类的知识才能用好。你现在应该最需要的应该还是快速出成果，哪个上手快、能满足就直接用，而不是从零建设。开源的接口测试平台挺多的，有些背后还是公司有专门团队维护的（比如 meterphere），可以找几个比较流行的试一下，找到一个好用的就开始用起来。反正代码开源，后面真的想改，也有办法改。

没有这方面经验，纯 YY，当做脑暴就好。

1、看楼主甲方这侧有多少资源，是否能重测。能重测最好是重测，掌控能力最强，但估计既然都找外包了，内部应该不会留这么多资源可以支撑重测。
2、无法完全重测，那就做抽验，可以以验收的名义让业务人员来试用下，相当于多把一道关。
3、通过看外包的用例设计、用例执行数据等来确认外包的测试范围情况。异常场景是否有考虑齐全，出过生产问题相关的范围是否有考虑到位，对于设计考虑比较齐全的部分外包同学给予一些嘉奖，促进大家做更全面的用例设计提高质量。
4、适当的考核机制给到外包质量压力，比如生产问题出现问题及级别达到一定程度，需要外包承担部分损失等。

1、你说的第一点，“线程数已经没有变化了”（这里我不太明白，因为 jmeter 是在开始的时候就要设置指定的线程数吗，这里设置了 30 个并发线程那肯定只能看到 30 的线程数）

jmeter 一样可以通过插件设定线程数上升策略的。一般压测策略，线程数应该是逐步上升，而不是一上来就达到最大值，这样更接近真实场景。

2、至于样本数的 failture，就是报的 connection time out

说明网络连接存在问题。

4、还有应用的 jvm 参数已经改过，相应增大到 2048m 没什么不一样，还是会出现这样 “暂停” 情况。所以当时就排除是应用 JVM 的问题。

你这个只是改了内存，jvm 还有很多参数的。比较明显影响并发性能的还有最大线程数。

5、后面做了测试，如果不使用域名进行压测的话，是不会出现样本数 “暂停” 的情况。直接对 IP 进行压测，不走 nginx 域名，直接压 ip，没什么问题。所以定位到 nginx 相关的一些配置问题，但修改 nginx 的性能配置还是没生效。目前还在调试排查中...

hmm，这方面信息超出你正文内容范畴了，没法给更好的建议，和运维保持沟通吧。

可以找下你所在城市的测试圈子问问，一般对质量比较关注的公司或者大厂，会有这些。

线上问题刨根问底这个你自己也可以做，不见得要找实现过的团队才能做。

从这 3 个图看：
1、出现这个情况的时候，线程数已经没有变化了，说明压测工具在全负荷运行，且每个线程都是收到返回后再会产生新的请求，即新的样本
2、从 tps 看，有出现 failture（原因图里没看到，不清楚），同时 response time 也挺大的（有不少在 3s 以上）。
3、没看到具体脚本内容，不确定有没有集合点之类的东西。

根据上面的信息分析：
1、样本数没增大说明存在等待，而结合上面说的第一点，等待的原因有可能是在等待服务端的返回，也有可能是脚本本身有等待类逻辑（常见的有集合点）
2、如果是服务端在等待，且楼主说了物理资源消耗不大（CPU、disk 不大，内存和网络未知但一般不至于出问题），可以排除是服务器本身物理资源不足，但有可能是分配给程序的资源不足。这个可以看程序相关的监控（如 java 应用的话，看 jvm 参数）
3、楼主图一有提到当样本增加停止时，被测服务的 cpu、tomcat 也下降，如果确实如此的话，说明样本增加停止时压力是降低了，有可能不是服务端处理慢（这种情况下资源消耗不应该下降），而是压测工具自己在等待。这个需要具体分析脚本里有没有什么 wait 相关逻辑（比如集合点之类的）

如果上面的分析思路都发现走不通，建议补充一些数据：
1、tps 图里面失败的具体原因贴一下
2、压测过程里，同一时间被测系统的相关监控指标曲线也给一下
3、整个脚本参数脱敏后发一下，看有没有什么和等待有关的配置

FluentWait 这个第一次知道，学习了。

这个看团队的代码规范要求吧。我们一般要求保持 set 方法的纯粹（毕竟没多少人会想到你在对象的 set 方法里做固定的数据转换操作），这类数据转换逻辑可以通过私有方法封装来避免和业务逻辑揉在一块，但不会直接改写 set 方法做转换。这种写法藏得太深了。

很有条理的总结，看得出楼主是个逻辑思维很强的人。提点小建议，感觉楼主的目标还是比较多的，而且 21 年基本都没达到。建议再聚合一下（比如 java 学习体系里加上一些 java 经典书籍的阅读；学习输出的文档也可以直接发布到自己公众号等地方），降低每个目标任务的完成成本？

另外，一个人独立完成特别容易因为情绪波动、工作压力太大等原因 “给自己放个假”，然后就不了了之。看楼主刚好也在带团队，可以看有没有志同道合的组个小群，每个周期要发自己的成果总结，这样倒推给自己每个任务一个周期性的小 deadline ，强制输出总结文档，避免自己松懈。

这个主要还是习惯问题。override 别人的方法前，要先了解清楚这个方法是干嘛的，override 是不是最佳实现方式，特别是 override 后原来已有的功能是否有重新提供，没有的话是否要通过调用原来父类方法来提供原有的能力。

看楼主这个 setattr 方法的最终实现，实际就是插入了个如果是密码就哈希后再写入的动作。这个动作为何要放在 orm 对象的 set 内部这么深的位置，而非在业务逻辑代码里写 account.password = hashlib.md5(password.encode(encoding='UTF-8')).hexdigest() ？

你可以看看 AgileTC ，开源的 xmind 用例管理平台。当时做得和这个差不多。

学习了。

不过，这个感觉还是指标不治本，只能更及时发现网络断开然后自动重连，但还是会低概率影响自动化执行？建议可以找运维沟通下看为啥 wifi 会连不上，解决一下，或者改为用有线网络。

很实用的功能，赞！

大致看了下，你说的这些问题，其实技术上都可以解决，只是需要多一些额外的兼容处理而已。

其实难点倒不是这些兼容处理，而是你的写法是不是团队的统一写法。如果每个人都有自己的习惯写法且差异较大很难统一，这个才是最难的。xmind 是很自由的，而很多传统的用例管理系统格式并没有这么自由，习惯 xmind 的团队很容易由于 xmind 的自由各自形成自己的写用例风格或者叫思维风格。这种风格本身和规范冲突还是比较大的，而且说实话，只要这种自由风格不会引起协作问题，其实也没太大必要去统一规范增加协作成本。

我之前呆过的一家公司，1.0 版本的用例管理是走 xmind 转传统用例格式的方式的，结果因为每个人风格差异太大且转换后没法类似 xmind 那样超级自由地编辑（互联网公司，执行用例的时候需求调整所以用例需要对应调整，非常常见），基本除了上传后自动统计用例数量和通过率数据有点用外，基本没人在上面直接写/执行用例。最后 2.0 版本直接改成在线 xmind 编辑，让大家基本不怎么需要调整习惯，才真正落地。

没在项目里用，因为 google 官方是用于 c++ 这类语言的，我们用 java 差异比较大，所以没有用。

学习了。

很详细的说明，感谢！

以前曾经做过类似的，规范 xmind 写法实现 xmind 转传统用例格式。但实际使用发现，要让大家的 xmind 格式统一非常困难。大家用 xmind 的目的是通过脑图减少用例中的重复编写成本，提高编写效率，xmind 更多是思路的体现，而非固定按传统用例的 前置条件 - 操作步骤 - 预期结果 这种写法。

好奇问下贵司这种强格式规范要求，实际推行的时候测试人员接受度高吗？