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

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

并不是一成不变的，测试策略需要根据产品体量、产品形态、产品受众（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 的过程。

针对客户端、服务端，两者正常收发请求的场景来解释，一个 mock 平台关键流程如下：

1. 接受客户端的请求
2. 按照不同协议解析请求内容（http、https、rpc……）
3. 按照 mock 平台上配置好的规则，来决定如何应答客户端的请求
   • 可能是直接给客户端返回响应，这个响应是人工配置的规则组成的响应
   • 可能是将请求透传给服务端（你可以想象为，mock 平台假装成客户端来请求原本的服务端），获得服务端的响应，再按照人工配置的规则将响应的部分结构或者内容做调整，把这个经过处理的响应返回给客户端
4. 结束流程

对于用户来说可以感知不到 mock 平台的存在，而在网络请求链路上来看，mock 平台就是一个代理角色，是一个中间人（了解一下中间人攻击概念）。mitmproxy是一个经常用来做 mock 平台的代理。

但实际工作中也不应该只把 mock 平台当成是一个代理，mock 平台是围绕代理这个基本要素来扩展各种外围功能，包括但不仅限于：

• 拦截请求流量
  • 可实现流量录制与回放
  • 可实现流量实时扫描报警阻断，或转储流量待日后离线扫描或追溯
• 篡改请求&响应
  • 实现接口 Fuzz 测试
  • 实现 mock 测试（map local、map remote）

非常同意这一楼的观点。

这个项目更多是帖主展示自己的思考和技术，很值得肯定。
但是如果让我来用或者让我给其他同学推广，我其实不太情愿，这个平台从实用性上看还处于比较浅层的封装，从产品化的角度来看，我觉得更有实际意义的方向还是如何一站式或体系化地解决问题，而不是单纯把一个工具上升为一个平台。（不是在贬低帖主的平台，只是一些实际看到的经验）

对应不同的路径吧。

工作中发现有个很蛋疼的问题 -> 简单的脚本来提高效率降低难度 -> 发现周边大家都有这个问题 -> 把简单的脚本做得更加工程化，从脚本变成工具 -> 发现大部门也有这个问题 -> 把工具扩展成平台

上述情况一般在早期的阶段更多见，问题太多，大家各干各的，没有明显的测试中台概念。

调研业务线了解共性痛点 -> 针对内部具体痛点并参考业界做法来设计方案 -> 将方案平台化服务化 -> 在业务试点落地验证平台对问题的解决效果 -> 获得业务反馈，迭代平台 -> 平台更大范围的推广

上述情况是比较标准的中台做事方式，也是更加体系的做事办法，至少在逻辑上来说，上级会更加少挑战。

至此，已经回答了【你们会去尝试开发工具吗？都开发过哪些工具？一般是通过哪些方面思考？】第一个和第三个问题。

具体开发过哪些工具，这个看痛点，一些常见的列一下（只是我知道的，不代表是我做过的）：接口测试框架（且需要平台化）、度量大盘、监控平台、压测平台、造数平台、mock 平台、UI 自动化框架、云真机、遍历测试工具、各类测试能力平台、发布卡口平台…… 这里说的各种各样的平台它是没有固定形式的，要结合公司的研发体系才能决定它应该长什么样子。

诶，突然发现被点名了

个人已经面了三位数的候选人，社招也面试了超过一百位同学【但是我们部门依然非常缺人，详见 https://testerhome.com/topics/32296】，可以尝试回答这个问题。

因为这个问题很虚，所以每个面试官的理解都不一样，从我的角度看，应该期望候选人回答这么些东西：

一、你在测试建设时整体是什么思路？

预期全局建设完是什么样子，在期间你会先做什么后做什么，为什么选择这样的顺序。其实上面也有答案说了，测试常规的事情不外乎管控流程、提供标准、设计用例、建设监控报警、建设研发测试效能等方面的事情，但是具体到不同的团队现状，决策是不一样的。需要重点突出你的决策过程，呈现你的决策逻辑。你要说明你是如何识别出问题，如何分析问题，如何转化为你要做的事情，如何评判你这个事情做得好不好。

二、在这个过程中你自己的经验是什么？

这里的经验会是很泛的东西，可以是目标拆解经验、可以是沟通协作经验、可以是质量运营经验、可以是技术建设经验、可以是带团队经验，但不希望听你将太细的东西，比如具体到某个技术细节如何踩坑就真的没必要说了，说了也不会有什么加分。

三、你对你负责的测试领域，有没有思考过对应的发展路径

其实这个问题是从第一个问题里细化出来的，要答好这个问题，是脱离不开对业界的对标和团队实际情况的理解，这个问题之所以单拎出来说，就是要体现你作为某个事情的整体负责人，到底对这个事情的理解和把控程度是多少，说服面试官招你进来你能找资源排除困难去把这个事情独立自主地完成。

当然还是有一些回答技巧，虚的问题对应虚的回答，如果你不知道面试官要问你什么，你可以先说一些你想展开说的点，让他顺着你的思路去追问你。

• QPS（Queries Per Second）：每秒的用户访问量（也有叫 RPS 的）
• TPS（Transcations Per Second）：每秒的 Transcations 数量（Transcation 是一个抽象概念所以不好用中文直翻，可以类比事务，个人理解是业务单个分支的完整流程，而完整的业务流程可能是多个分支一同完成）

QPS is basically similar to TPS, but the difference is that a single visit to a page forms a TPS; however, a page request may generate multiple requests to the server, which can be included in the “QPS”.

上述出自链接。

在搞明白概念的区别之后，再来看术语的应用场景。性能测试关注点是性能上，所以只要把性能解释清楚就好，在不同的公司，无论对与错，无论术语用得专不专业，只要大家都知道在说同一个东西其实也还好。

回到问题上，性能测试关注的是性能，而制造性能压力一般来源于并发访问量和能使用的资源，所以我们要描述压力大小，就相当于要描述并发量以及提供给系统的资源量。

TPS 和 QPS 对比，按照老外的解释，TPS 是一个更内部更拆解的概念，在业务足够简单的情况下它可以跟 QPS 等价；QPS 是更面向用户的概念，它把整个系统看成整体，不管你系统内部怎么运作，现在每秒多一个访问过来那就是 QPS 加一，更直观更好理解也更容易统计，所以我推荐用 QPS 来表示并发或者压力程度，当然单纯说 QPS 是没用的，还要加上请求正常响应比例等条件的约束才有实际分析意义，就不展开扯了。

还有一个很重要的点，要区分好线程数和 QPS 两个概念，个人感觉之所以会把线程数等价于 QPS，可能是习惯将 Jmeter 世界里的概念搬到其他场景来。因为 Jmeter 实现发压是基于多线程模型，不严谨地说就是一个线程发一个请求，很古老的 I/O 模型，在当时可能是很好的方案，但现在看来会有局限。对比与 Locust、Gatling、K6 等更新一代的压测工具，使用更高效的 I/O 模型更有利于榨干发压机的性能，这个时候就再也不是一个线程等价一个请求。所以，不能用线程数来代表并发，而是用该以实际发了多少请求给服务器来统计并发。这篇文章写得很好建议阅读。

特意了解一下财经支付同学的质量保障工作，同样也是 mock、沙盒支付、支付白名单 这几种手段。支付服务端是 go，公司内部有流量回放服务应用在支付测试上，不过仅限于线下环境，没看到线上有做特别的测试动作。
不过恒捷那个思路确实合理，可以在监控报警上面多做建设，或者尝试做做线上支付定期的接口巡检？

1. 应该是工具误报，因为工具一般是靠判断 response 中是否有回显 script 标签内的内容，这刚好这里的后端把内容重新吐了回来
2. 实际上也算是一个安全问题，如果线上环境也是这样的抛错，就相当于把服务器的敏感信息暴露出来（用了什么组件，详细报错信息），这些是不应该返回给用户的。

还会有这个话题的下一篇文章吗？期待看到更多具体的实践细节做法

如果楼主确定了定居在石家庄不考虑其他二三线城市的话，那最重要的还是心态吧。

1. 明确后续的生活方式，盘点好预想中的收入来源有哪些（工资、副业、投资……），以及不同生活质量需要达到多少收入水平
2. 明确上面的条件后再来考虑工作，如果单纯测试岗位很明显是死路一条，那就是求变。测试开发如果太难找，那转开发其实没那么难，早期自己辛苦一点尽快熟练业务需要的那套技术脚手架就可以快速适应岗位（不然没啥工作经验的毕业生实习生为什么也能做开发）。关键还是看工资预期，要放低心态不要设置过高预期……

比较好奇，对线上支付接口做拨测的目的是什么？
个人感觉，似乎除了验证自家服务在不同地区节点的性能之外没有更多的结论。
在依赖第三方支付接口的情况下，别人对拨测的响应速度无法控制，咱最多只能帮别人发现问题这样子？
如果不打算连带第三方支付接口一起验证，那确实是 mock 掉第三方支付接口即能达到目的。

由于第一段话和第二段话的逻辑看起来很奇怪，没有能完全理解，上面已经有人说了，你的问题其实不是测试问题，而是本身服务端实现就存在已知的性能问题，和你做性能测试没有关系，问题在线上已经验证出来了，接下来应该是排查修改。

下面尝试回答你的两个问题。

问题 1：如何在测试环境去模拟这种数据量较大的情况测试

1. 解法一：在测试环境伪造同样负载程度的数据，要关注数据类型分布，数据量比例一致（注意，并不线上 1000w 条数据线下就要 1000w 条数据，线上线下配置往往不对等）等问题；数据伪造的方式，有脚本批量生成、线上导流脱敏生成，一般需要待测试标志方便后续清理，或者影子库的方式去处理。
2. 解法二：如果数据量级不好伪造，那就重新搭另一个测试环境。这个新测试环境的硬件配置要更差，差到在较小测试数据量级时已经出现性能问题，也是另一种思路。

问题 2：测试标准怎么定

我假设你说的是性能测试标准，一般主要关注以下维度：

• 响应时长维度：文字意思
• 响应正确率维度：文字意思
• 机器资源维度：cpu、内存、I/O（可以泛化到缓存和数据库的速度）、网络带宽

思路是，在一定时长范围内，满足 xx% 响应率，能压到多少 QPS，这个 QPS 是否达到预定目标，在压测过程中有没有发现资源问题……具体数值，要从线上历史数据去分析预测，与研发和产品商讨确定。具体可以看看服务端压测怎么做。

好的测开，确实还是得从业务中走出来，对业务痛点有亲身摸爬滚打经历，再慢慢走到中台化服务化

感觉是精力分配转移了，年纪越大越清楚想要什么，精力管理得越来越好，鸡毛蒜皮的事已经不入脑了

不错，很明确自己的学习路径，继续加油，做到学以致用，实践到工作里加深理解（当然不要盲目实践）

• 一方面，小厂由于体量小多数可能还是以业务生存为主，在具体方向深度上大多数时候是打不过大厂的，所以小厂看起来无法满足楼主的需要。
• 另一方面，大厂对于楼主年龄的候选人，应该会有两种方向的要求。要不是能带团队在某个领域方向上发展壮大，做到细分领域的 top（团队带领者），这个方向显著的要求大概是具备较好的视野、规划能力、管理能力；要不就是有非常强的个人能力可以解决大家都解决不了的技术问题（个人贡献者），专一在某技术领域上发展为没有任何人能替代的资深专家。或许楼主可以想一想自己比较适合哪个方向吧，毕竟时间对于楼主来说越来越宝贵，时间花在刀刃上，让自己的能力模型符合大厂的理想，可能会更有利。

至于技术深度方面上，可能得有标杆基线才能去评价深度，比如领域内大家一般都做成啥样，有些什么地方大家可能没做，这样去评估可能目标性更强。
有些时候太钻牛角尖确实不是一件好事，“够用就好” 和 “深挖到最底层” 并不就是一个贬义一个褒义，还是要区分场景去看待。如果在一个快速发展的地方，“够用就好” 是一个理智的行为，强行挖深度会带来负面效果，最直接的表现可能就是自嗨和闭门造车。“深挖到最底层” 要看周围环境是否允许，当然如果是业余深挖是鼓励的，工作上去花时间深挖，就真的要权衡 ROI 了，可能有更多更重要的事情自己装看不见，挑活不想干。有时候老板可能也不好意思挑战，要自己意识到不合适。

我看下来有些疑问（好奇）

1. 作者个人定位是什么？专精的哪个领域范畴？之所以这样问，是看到楼主快 40 了，还有在切换新领域（最近在被老板逼着看编解码的算法，想的是超越 GOOGLE 开源），挑战新方向是好事，但经常在个人的历史经验清零的状态下面对工作，不好发挥出独特的价值，很容易被扣帽子说 “工作年限与能力不匹配”。
2. 作者希望待在一个什么团队，觉得团队对自己的要求是什么，自己希望从团队里获取的是什么，又觉得能给团队带来的是什么？
3. 年纪大经历多，确实不会再愿意做简单的事情，那找到一个合适的长期做下去的岗位的阻碍是什么？是个人原因还是外部原因？频繁跳槽我理解是进来后做的事情跟进来前了解的对不上。

在豆瓣慢慢蹲大佬的新书