我意思并不是说滞后到了具体用例设计才考虑策略，而是测试策略呈现的成果浓缩到了用例设计里。

一般这个风险和测试验证点考虑，其实在需求评审和技术方案评审的时候就会考虑的，只是基本很少会再单独弄一份文档或者文字来记录，而是直接融入到用例设计里，在用例评审的时候一并进行评审。至于测试策略会涉及到的其他事情（比如你提到的规划排期、需要其他人协助），一般会在估排期的时候就做，成果也会融入到排期和人力投入信息里。

测试策略还是很重要的，只是这个概念慢慢弱化到测试用例设计的过程中了，很少再单独提出来。

这个没有绝对数值，要具体看公司情况，有功能测试和工具开发 8:2 或者 5:5 的，也有直接纯工具平台开发不怎么做功能测试的。

如果只是因为 python 的开发工作少，可以考虑转 java 开发，不见得必须转测开。测开也不见得就固定用 python 的。

然后测试开发的发展路线，这块没有系统整理过，个人经历是先做业务测试，对测试领域和测试痛点有一定了解；然后做一些自动化，以及小的提效框架/工具开发，逐步涉猎开发；最后逐步变为专职的测试工具平台开发。

metersphere 就是基于 jmeter 封装的，推荐试试。

暂时没有落地，之前也只是预研学习。

过誉了，没那么厉害。。。只是打的久熟练一点而已。

目前还是以 ToC 为主，ToB 暂时还没涉及到。

完整方案可能不是很方便分享，大致思路是通过 atxserver 占用设备和连接设备，然后在对应的 jenkins job 里面通过指定设备的方式来执行 monkey 、ui 自动化这些。

还没怀上

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 ，强制输出总结文档，避免自己松懈。