业余

如果自己的目标导向性很强，那就走目标驱动的方式，给自己一直定短期小目标，比如每个目标是学习 xxx，然后将它拆成几个子课题逐个突破。
如果自己的目标导向性一般，那就先上网找找 roadmap（别人整理好的学习路线图），然后从上面按顺序学习，或者挑自己感兴趣的去学习。
学习主要是将节奏，稳定的输入输出，剩下交给时间。

职场内

谦虚请教，多主动和 leader 一对一沟通，不停询问其对自己的看法和建议，不停做调整；学习如何去把一件事情做好，如何从 60 分做到 80 分再做到 90 分；学习怎么和别人友善顺畅地沟通，学习怎么抑制在沟通时不好的情绪表现等等

如果直接要答案，没办法给你，可以尝试给点思路。

【系统环境多多少少都会存在一些细微的差异性，导致部署的过程中，活着在试用的过程中零零碎碎的问题就显得很多】

我假设这里楼主已经把问题范围圈出来了，接下来要做的是，把这个很粗的定义细化。

• 正向思路：服务器环境差异究竟有哪些影响因素？如硬件规格、系统版本、程序版本、程序配置等，需要楼主去盘点……
• 逆向思路：在实际 ToB 的过程中，客户遇到的实际问题排查下来是什么原因，补充到你梳理的影响因素里面。

当你把影响质量的点都搞清楚后，就能去决策应该先优化什么，优化了之后预期有什么效果，这样就有了目标。另一方面，你需要在这里面找出一些可量化的点来评价你做事做到多少分，举个例子，假设运行环境中依赖程序版本会影响你系统的运行，那你要有个类似这样的指标 —— 系统可以正常兼容哪些程序版本，没兼容的是哪些。

比较常规的如一楼所说，测试先划定一个，再找研发评估对齐。
引入其他依据的话，可以是基于代码调用链上下游各 N 层来评估测试范围，这个评估步骤可以是人来做，也可以做成自动化。

希望楼主不要觉得我说话难听，忠言逆耳，其实楼主有些浮躁。
接这个例子说，用例数量 10 条和 100 条有本质区别，100 条和 1000 条区别更大，有很多问题是在一定体量之下才会出现（不然淘宝双十一天天卷架构卷压测是为了啥）。
举个例子，当你用例膨胀到几百条，你会出现很多维护成本问题（用例不稳定性，修改效率低）和很多统计度量问题（哪些用例失败率高，哪些用例经常发现 bug），就会让你在用例分级、运行策略、框架升级等各方面做更工作……这也仅仅是部分问题，越往后做，就要和各种奇怪的问题斗智斗勇，这时才是最锻炼人的，而不是写几百行代码就算是 ok 了。

一开始看还懵了一下，按照面向接口压测的思路，一般不会把用户在浏览器上请求的模式拎出来说，而是直接按照业务链路的思维去梳理。后来看完之后就理解了，本质上工具的核心卖点是 UI 操作化与录制，录制功能做到和多用户用浏览器一样的访问模式，对用户的要求更低（甚至不用具备链路业务梳理的能力）。

不过这样做压力测试会有局限性的：

1. 没有办法把后端链路拆分开来进行压测，除非后端很简单，不然压测粒度太粗也就不好定位问题；
2. 不是所有系统都会有前端页面，就没法录制了（不过工具本身应用定位就不是在这个场景，可以理解）
3. 个人感觉会有一些问题无法触达，因为不是所有流量都是由前端的用户访问直接产生的，有时候在链路内部会流量放大的机制（如内部的失败重试），极端场景下需要额外考虑

9 楼的逻辑有点问题，外包要是薪资高，那为什么还会分化出 “外包” 这种角色，“外包” 之所以产生，最大原因应该是企业希望降低人力成本吧？这些成本泛指培养成本、福利成本、违约成本……

回到正题，从楼主的描述中，薪资和工作内容都不太让人满意，现在又把离职摆出来了台面，大概率是要走的了，还是只能边做边找。不过大环境很一般，还是尽量放低薪资预期，看长远一些，优先考虑找一个能让自己在未来有竞争力的岗位吧。

回家随便找工作然后考公务员，看着更像是一个放弃治疗的选项，除非考虑成熟了，不然还是晋升，否则这 3 年工作经验基本浪费。

最近倒是面试了不少 “毕业” 的同学，确实日子不好过。
另外，欢迎对移动专项测试感兴趣的同学加入我们，有平台开发、移动端测开、性能&体验评测等岗位：https://testerhome.com/topics/32296

应该要明确一下，你表达的 “接口断言” 和 “数据库断言” 在这个上下文里具体是指什么？

我自己理解，帖主问的问题是：性能测试过程中每个请求是否需要看落库结果，来确保性能测试的逻辑正确性。

我的理解是：

1. 性能测试可以做结果断言，但不需要在测试过程中做，而是在性能测试结束后统一做断言。举个例子，电商抢购性能测试，最后通过日志和数据等对账完成断言，判断没有不符预期的情况，没必要在发生抢购的过程你还要浪费性能去做额外的事情。
2. 性能测试断言结果其实是次要的，因为性能和功能相对独立，很多时候只要功能测试是正常的，性能理论上就不出现逻辑问题（不过极端场景下，尤其是系统有复杂的上下游依赖，这个时候确实会出现功能不正确的表现）。所以一般来说功能测试通过了，性能测试基本都不关注 “结果是否正确”，因为功能测试已经给了结论。不过甲方爸爸要求给，那还是得给……

也是可以的，这算是具体测试下手的几个维度，但还是不太够，面试的时候问你这种问题，其实就想了解你的质量保障体系是否完备，所以从线下到线上到得回答一遍。

嘿嘿嘿

智能纸制笔记本，不过 7 号发起兑换到现在还处于审核中

安全 topic 比较深，从基础的安全测试思路，到各类专门的测试工具学习，再慢慢到专业的渗透测试人员（相对专业的安全测试还是得看乙方安全公司的人员，甲方企业安全更多是研发主导）。不知道市面上的课程讲得怎么样，个人感觉这个方向不好做，需要大量实操积累。而且在大公司内部，安全问题已经泛化成如何应对隐私安全监管等，至少我看到的兄弟质量团队也还在搞安全体系化建设，业界还没多少测试团队把这块做得很好（另外，监管的不确定性也注定做这块会比较疲倦）。

性能就比较成熟了，估计课程也很容易把它讲透，也很好学，至少体量不大的公司中，性能一般比安全的优先级更高（因为安全问题没人去揭发，所以显得危害没那么大）。

信息太少了看不懂，不知道这套东西设计出来的背景是什么，要解决什么问题，解决的核心思路是啥，整个流程跑起来是怎么样…… 期待帖主能补充一下

确实答的太局限，单纯吹牛逼的话，可以从版本周期出发：

需求提出 -> 技术评审 -> 测试设计 -> 研发自测 -> 测试介入 -> 灰度放量 -> 全量上线；这里面每个环节，从流程、效率、线下测试维度、线上质量等尝试回答吧，至少答出来在效果上看起来体系丰满一些。

一个核心项目，首先在公司里是受到老板关心和重视的；然后你要真的投入进去，在项目里起到主导作用。这个主导作用，不一定是画各种架构图或者写代码，或者做接口设计，而是参与从孵化到上线的每一个关键会议的技术讨论。同时在认真思考后，对现有的技术方案提出质疑和建议。不管自己的建议是否生效，至少自己是真正动脑子想过的。如果你做甩手掌柜，个人认为你不太可能在日新月异的技术行业，成为一个优秀的 leader。
但有一点要注意，你不能用自己的质疑去取代下属的决策。你可以提出一些不同的想法，但是不能因为你是 leader，就强制下属执行。而是多跟下属切磋，了解他们的想法，最终还是尊重团队的决策。通过这些思考、切磋和交流，在这个项目成功后，你跟别人聊这个项目，才能让人感觉你真的是其中的一份子。

这里说得好呀，一个好的管理者，管理确实很重要，但还是自身要有拿得出手的货。充分授权是一回事，但核心事情一定要深度参与到每个环节里去，理解事情的决策背景和逻辑，既有一个全局掌控又能在关键细节上有实在的把握。这样子的管理者后路很安全，即使哪天被干下来了，回到一线还是可以继续自由发挥。

业务测试的定义是什么？是点点点，还是综合把控业务质量？按照帖主"业务测试都是可随时取代的职位，并不能谈的上合不合格"字行里表现出来的意思，我理解指代最低端的点点点人员，下面也就按这个定义去回答。

1.如何做一位合格优秀的业务测试？
就是一个听话的测试外包，叫你干啥你就干啥，而且要给我执行好（管你加不加班那种）。

2.业务测试在一线城市有封顶薪资吗？
50w 也是封顶，200w 也是封顶，两者的绝对值差别太大，探讨 “封不封顶” 感觉没什么意义。问题不是有没有封顶，而是能不能达到。

3.业务测试如何去发展自身的特长，也就是职业发展？
强求技术热爱其实很扯淡，单 Testerhome 社区就这么多人，难道大家都可以热爱技术吗？必然不行。所以客观来看待，就是扬长避短。如果对技术不感冒，在保证自己技术能力不成为绝对短板拉胯的前提下，去避开需要强技术能力的工作。也不是除了技术之外就不能做其他，比如 PMO、PM、设计、市场、销售、运营，这些算转行了，还可以坐对技术要求没那么强的偏管理的位置……当然也可以说挑出舒适区自己去接更高技术要求的工作来挑战自我，这个就看结果带来的风险和你的收获预期，是不是匹配的。

4.如何让技术循循渐进的进步？
两条路线，一是正向梳理知识体系，网上很多成长路线图，对着自己一个一个板块地点亮，这里要求系统学习某些领域的知识，而不是看几篇博客或网文的程度；二是负向补充遗漏或欠缺的知识，在工作等实际场景中必然会遇到自己不了解的内容，那就按需去补充，可以体系地补也可以单点突击，就看你的学习目标。
剩下来的就是交给时间。

有条件当然自己申请域名买服务器搭建一个博客系统，无数现成能用的。
不自己从零搭建的话，github page 很多人用，就是国内访问速度很慢，图床不好的话图片经常裂开。
洋气一点的，用 Medium 或 Mirror 这些国外比较流行的博客网站。
接地气一些的，简书、知乎、头条、思否、博客园、掘金。
上古时期的，CS 某 N…… 全是广告，一点都不想看

手动点赞

已经用积分发起了一个奖品兑换，嘿嘿

在 testerhome 上划水了半年发团队的招聘帖，都没收到几份简历，太惨……

自己的渠道，主要是脉脉上加过来的各种猎头和公司 HR，以及朋友同事的推荐。

是不是应该都监控上，然后找到瓶颈是 nginx 还是数据库，再换算答案？

找以前负责这个项目的主要测试同学口头问清楚，就是最快速的

知行: 技术人的管理之路，我也是被人推荐的，刚开始看。

jenkins 日志里看到你命令行的用户名是 fsytest，控制台输出看到你用户是 root，可能是用户 PATH 的关系。也就是 pytest 安装在 root 用户的 PATH 下，但是没安装在 fsytest 用户的 PATH。
可以在 root 上用 which pytest 看看安装路径，然后把这个路径 export 到 fsytest 的 PATH 里。