一开始看还懵了一下，按照面向接口压测的思路，一般不会把用户在浏览器上请求的模式拎出来说，而是直接按照业务链路的思维去梳理。后来看完之后就理解了，本质上工具的核心卖点是 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 里。

豆瓣读书搜索 “测试”，选接近或超过 8 分，且评分人数超过 100 人的书看

就是常规的被职场毒打

文章的标题格式好像还可以优化一下，标题和正文混在一起了。

首先，全链路测试是一种低成本的测试方式，如 app 端到端的测试，app 上点几下，直接看 app 的反应是否符合预期。这样直接忽略中间链路的测试，一方面它非常高效，所见即所得，门槛非常低，更容易铺人力来规模化；另一方面也有确实存在很多风险隐患，测试不够精细导致一些潜在问题没有发现。整体来说，它适合在人力不足时追求高测试 ROI，或业务相对简单的阶段。很多时候也是需求开始测试的首选方式。

帖主说的接口全链路测试，个人理解和 app 端到端的测试是同一类的，只是从点击操作 app 换成发接口请求，确实存在帖主总结的各种问题，本质上还是在于中间过程要追到多精细，以及能否意识到对旁路的各种影响。

全链路测试不是银弹，但是没它，好像也不太行。

1. 海外的本地化；简单说是文本翻译，特约要考虑文字排版长度等事项
2. 海外网络测试；海外当地的网络跟国内不是一个概念，具体我也不太懂，有些国家有公共 wifi，有些国家移动网络烂到爆，海外网络直接影响使用体验
3. 海外机型系统；跟国内厂商魔改 ROM 可能存在很大差距，海内海外即使是同一个厂商的同一个系统，也会有些区别
4. 海外站点有没有回访海内的域名、有没有敏感词；可选项，涉及数据安全隐私问题，大公司估计比较关注，因为一不小心来个海外舆论风险可能就彻底寄了
5. 剩下的基本和海内产品同样测试了……

尝试谷歌了一下 test case driven development，搜不出这个概念，老外似乎也不这么叫，应该就是楼主公司的内部叫法，结合上下文猜测就是说 TDD 吧