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

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

一个核心项目，首先在公司里是受到老板关心和重视的；然后你要真的投入进去，在项目里起到主导作用。这个主导作用，不一定是画各种架构图或者写代码，或者做接口设计，而是参与从孵化到上线的每一个关键会议的技术讨论。同时在认真思考后，对现有的技术方案提出质疑和建议。不管自己的建议是否生效，至少自己是真正动脑子想过的。如果你做甩手掌柜，个人认为你不太可能在日新月异的技术行业，成为一个优秀的 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 吧

原来还有个概念叫 MVT 模式 …… 涨知识了

如果只是浅层使用，两个框架的使用手感其实没有多大区别，与其浪费时间在框架学习的纠结上，还不如挑一个先学起来，很多是一通万通的。

回到两个框架上：

• flask 更合适是开发小网站（典型的小网站可以是一个 py 文件直接搞定），可能是因为其路由管理比较分散所以没那么合适开发大型复杂网站（当然还是可以用来开发大型网站）
• django 是企业内部常规选择，如果你非要挑一个让你安心一点，那就直接 django 吧。

如果要追究到很严谨的技术选型，我自己也没研究过两个的底层区别。

原则：利用有限的人力做收益最高的事情。

• 最高优先级：保证需求质量，保住质量基本线，让质量不成为产品增长的阻碍
• 高优先级：人数增长到一定规模后，引入相对规范的流程（需求、测试接入、上线、报警处理、线上反馈等流程），保证合作效率不随着人口增加而迅速降低
• 中等优先级：建设线上监控报警，做好基本灰度流程，质量从灰度、线上收口（设想一下，如果你要踢一场球赛，而球队只有一个成员，这个人放在哪里合适？当然是放在龙门前，这时挡球效率最高）
• 次要优先级：开始考虑更多效率提升上的事情，如测试效率、排查效率……
• 次次要优先级：提效从单点开始上升到面……
• 正无穷阶段……

并不是一成不变的，测试策略需要根据产品体量、产品形态、产品受众（toB、toC、toD）等各种因素调整，上面说的是比较常规的 toC 产品，还是要看实际情况。

具体帖子 https://testerhome.com/topics/33088；

我在逛这个地址时看到 https://testerhome.com/topics/last。不过现在我已经申请加入了社团，帖子已经能回答了。这个问题我之前也遇到过几次，应该是稳定复现的，漏了一些鉴权逻辑。

问题 2 和问题 3 没什么意见，感觉蛮合理。那这样看就是一个 bug 了。

看了研发的目标，我理解意思就是用 java 重写一个定时任务，来取代之前那套 php 的流程。或者更清楚地说，研发的目标后续是下面三个：

1. 更改语言技术栈，php 改为 java
2. 将回写流程简化
3. 优化回写 sql

如果上面的理解没错，我个人认为可以这样考虑：

1. 功能测试 —— 验证流程是否正常；测试环境下把 crontab 的触发时间缩短，先人工看流程通不通，回写空数据、少量数据、大量数据的情况下是否正确，可以直接拿新老任务做 diff 对比着看结果。
2. 异常测试 —— 构造一些异常场景；比如上一次定时任务触发失败是否使得下一次定时任务异常、java 获取 redis 数据失败（网络超时、redis 宕机）、redis 数据结构或数据值异常（异常数据）、回写数据到数据库失败（磁盘满、数据库超时、数据库宕机、网络超时）、回写流程中间发生异常，以上还要楼主继续细化。
3. 性能测试 —— 看你的性能测试是什么目标，有没有必要做；待遍历的 redis 集合过大怎样、回写的数据量过大怎样、存不存在大量并发回写的情况……（潜藏各类超时、高负载的场景）
4. 安全测试 —— 这个比较玄幻，比如定时任务触发的是一个接口服务还是什么，这个接口有没有做好鉴权防止被别人乱调用，回写用的 sql 有没有注入漏洞……
5. 其他……比如是否存在数据库主从同步的问题等等，要看模块结构的设计再增加一些考虑点

以上是考虑稍微多一些的建议，可以按照实际情况做删减或补充，不一定要搞得很复杂。

我甚至怀疑楼主的问题是翻译网站机翻过来的…… 语文表述和标点断句让人无法理解想要说什么

结合了帖主的各种回复，大概明白帖主想拿到什么答案，我尝试补充一下答案。

首先，从帖主所在的团队来看，是属于成熟稳定的团队，但是帖主没说研发人数和版本周期，我从上下文去看，应该是一个迭代很慢的平台产品，而且整体质量比较高。在这种情况下，研发自己写单测保障质量，那基本可以等价理解为研发具备充足的时间来自己保障质量，这个业务产品的迭代交付压力小。

从这样的背景来看，测试应该要做的是什么？还是结合实际分析现状和痛点，我下面给一些思路但不能照搬。

1. 质量是不是真的非常好，它到底还有没有风险点？ —— 要弄清楚这个问题，一个方向是正向梳理全量业务场景，利用业务经验和测试标准体系（功能、性能、容量、容灾、兼容、安全……）去判断；另一个方向是负向基于线上问题来定位风险，反推建设目标。好，假设这两个点都没什么可以做的，这个系统真的就稳定得一匹，那还有另一条路。

2. 研发自己做质量保障，有没有什么难题，能否为他们提效？ —— 比如让研发更简单地测试，让研发更直观地了解质量……说白了就是要造工具造平台造框架为研发服务，提高研发效能。具体能做些啥社区有 N 个帖子讨论过，就不展开了。好，假设这个也没得做，那就要回答一下自己待在这里到底是图什么，公司组织对你的期望是什么，需要你解决的问题是什么，这里面你真正能解决的问题又是什么……如果这些你自己答不出来，可能要考虑一下后路，除非你的人力成本性价比很高……

同样的问题变着花样能问很多次，可以参考这个帖子：https://testerhome.com/topics/32404

“体系化” 和 “一站式” 不完全是两个概念，“体系化” 是一种思想，而 “一站式” 只是一个表象或者一种实现，一起谈容易出现误解。

自动化平台确实就应该先做好自动化，但是在这个探讨语境中，我认为自动化平台最重要的不仅仅是自动化，用例管理、与 CICD 系统的集成或被集成等其他很多外围功能，也是平台的生命线。之所以这样说，是因为观察过实际工作，大家不会因为一件好像不是那么重要的事而不断给自己的工作引入复杂度（比如我要在代码 Merge 时跑个自动化，我不希望还要切到 CICD 其他平台看这看那的，我只需要一个测试结论）。所以 “体系化” 这里可以指代系统被外界集成的可行性和复杂度，甚至是信息信噪比（假设日常工作是围绕 CICD 来开展，以被集成到 CICD 作为设计目标 “之一”）。

另外，个人理解自动化是一个上层概念，它代表某种提效的手段，那么就底层就可以引入更多能力来让自动化做得更好，如 Mock 就是一个很大加分项。不过需要谨慎看待，实际工作中要结合内部已有的能力来建设就会少人喷一些……

而 “一站式”，更多时候像是在搞重复建设，卷其他部门，实际工作中见到好多这种皮包平台，把别人做好的能力拉过来集成包装一下就美其名曰是效率提升，实际上没有任何实际额外内容在里面，随着内部平台的大一统治理肯定会被干掉。

所以个人建议是帖主可以考虑围绕着自动化场景去引入更多能力，这些能力应该能让自动化做得更高效更准确更舒服，也是从 1 到 100 的过程。