按照线上页面的 PV、UV 排个序，首先最高的页面下几个最高的场景肯定是要做的，然后 QA、RD、PM 内部商讨，剩余长尾页面哪些要额外补充 UI 自动化

举个例子，比如说你的增量调用链最后是 B->C->D，你通过覆盖率拿到你测试后的调用链是 A->B->C->D->E->F ，这样不就能理解你的的测试已经覆盖了你的增量链路么？ 也就是判断子集的操作

同楼上
问题一：直觉上就是发压机的配置跟不上，如果你是用 PC 机发压，这个可能就更大了。建议关注一下发压机的配置，以及发压机在发压时候的资源占用情况。

问题二：可以先盘点一下，部署在两台不同的机器上会有什么差异

• 环境：机器配置（是否有一台的配置特别拉胯）、环境变量、
• 网络：不在一个局域网，是否距离比较远如异地机器
• 其他……（甚至可能是你在单台部署和两台部署时，没有控制好变量出现的差异）

问题三：具体要看业务逻辑实现，对于 “校验客户密码” 这种接口，应该是每次都要查询数据库，合理的代码实现不应该使用缓存

1. 我理解去不了所谓的【无关调用】，你想在静态分析技术中处理动态运行存在的问题，看着有点玄幻。要不就是你本身已经具备先验知识，比如你事先知道要关注的调用链上游会包含什么因素，那你就只关注这条子调用链即可，其他的不管。
2. 要判断【这条调用链有覆盖】，换个说法就是判断【覆盖路径 是否包含 调用链】，也就是调用链是覆盖链路的子集。具体怎么搞，那就看你的数据格式是怎么样的。

继续在这种地方呆着不走，除非你有什么难言之隐，不然就是对自己的未来不负责

我理解是一样的道理，算法在 monkey 上的作用就是决策下一步要点击哪个空间获得的 “收益” 更大，还是有可能直接给点 “返回按钮”。
我表达的意思是，这个手段在使用细节上还是有很多测试策略需要考虑的

我们内部有实现了一套差不多的玩意，我们管这叫 scheme 定向测试，只是说，可能定向过去的是一个原生页面、前端页面、内部其他技术制造的页面等。

其实有弊端：

1. 并非所有页面都能这样跳转，需要页面自身支持这样跳转才行。
2. 跳转本身所携带的参数是你在收集那一刻就被写死的，它缺少了动态的变化，跳转过去遍历测试一样会存在覆盖的死角。

不过还是有很多场景可以应用这种测试方式的，比如提高测试覆盖率、线下问题复现压测、某些特殊场景的定向测试。

如果要结合遍历测试来做，还需要预防跳转过去后，monkey 给你点到回退到其他页面了。

我觉得吧，能把大学那些数学课先捡起来（尤其是工作多年之后），就已经不是一件特别轻松的事情。

如果真的很轻松，要不就是天赋过人，要不就是基础确实稳扎稳打，要不就是学了点套路当调参侠自嗨

offer 中也有薪资开的比较高,越是工作年限比较久,越要知道下一份工作能得到什么,尤其在当下互联网环境,很难找到完美得工作,但是可以找到适合的自己工作.

表示这一点非常赞同，一定要看准赛道跳进去，跳进去之前又要充分考察这个公司、团队、岗位是否适合自己发挥。到这种时候 base 上差个两三 k 已经不是什么需要关注的问题了，主要还是考虑未来继续发展的空间。

对的，其实压测本来就是有两种目的，视不同场景：

• 目的一：要上一个活动，这个活动从产品侧估计会有 N 人参与，所以某些接口必须要能支持这种程度的压力，这种就是在上线前就有明确的压力预期（一般是 8/2 原则来评估），压测的主要目标是 check 接口能否达到这个预期
• 目的二：要上一个新功能，这个功能大家都不知道会有多少人用，是个船新的东西。这时需要旁敲侧击，比如有无类似的接口可以拿数据来参考，或者有个保底的用户人数，这时候压测的主要目标是看这个接口能承受的极限压力，先让大家知道这个接口能扛得住多少多少，然后在来评估是否合适上线

压测我以前做过一个总结，可以看我的博客做个参考。

如果产品不明白，那还是得耐心解释给他们听，其实这也是你在研发和产品之间制造自己影响力的机会，让大家觉得你知道得很多决策经常正确，那是一件好事。

所谓的熟练掌握 python，一般只需要系统把 python 学一次就够了，要求就是一个普通的想法能用 python 这个工具正确实现表达出来即可。并不会强制你掌握那种 blingbling 的、很 pythonic 的、很奇技淫巧的实现方式。

其实不仅仅是 python，对所有的编程语言都是一样，它们都只是我们的编程工具，只是说你追究到库源码实现、编译器虚拟机实现层面上，在某些特定场景下能帮助你解决问题和优化代码。单纯从测试开发的岗位来说，除非个人爱好或者工作面试需求，不然也不是非得到那种深度。

当然，多看别人的代码，尤其是高效优美的代码（github 高 star 项目），对自己还是非常有帮助的。

mark，这个周末拉到家里的电脑认真阅读一下源码~ 看看能不能给找几个 bug hhhhhhh

申请开通专栏~ 感谢 @simple

曾经在企业里作为乙方对内部的网站系统搞过 4 个多月的渗透测试（或者叫安全测试更合理，因为不够专业），简单分享一下如何入门：

1. OWASP 一定要看，每年都会有 OWASP 出台的 top10 安全风险，这些是说明安全问题重要性的重要依据
2. 安全细分方向十分多，我猜楼主应该是问 web 方向（其他方向我也不懂，太深），先了解常用工具，burpsuite、owasp zap、sqlmap 等，要自行采集，网上一搜很多博客、github 也一吨开源工具
3. 理解基本安全概念和安全漏洞类型，一定要理解，不然永远都是 script kiddie，鄙视链最底端，以下是部分列举：sql 注入、XSS、CSRF、水平与垂直越权、敏感信息泄露、命令注入、路径遍历、文件上传…… 理解这些安全漏洞的典型成因（如何写这些漏洞出来）以及带来的危害（怎么用这些漏洞搞事情）
4. 找地方实战，建议本地搭建开源的环境进行训练OWASP juice shop
5. 往下就是各种实战去精进技巧和意识，加深对各类测试工具和漏洞的理解，做更多白盒审计来挖掘漏洞，学习更多安全领域技术，不断变强……（我本人到第 4 步就没再往下了）

一个接口做不做压测，是应该测试人员自己判断 ，还是听开发说呢？

结论：产品、开发、测试共同判断。
如果这个接口有历史数据，可以基于历史数据来分析接口重要性，再判断是否要压测。
如果这个接口没有历史数据，是新增接口，最正确的方式都是产品、开发、测试三方一同判断。或者某方判断出结论后，正式地（会议、邮件均可，至少有书面记录性质的东西）跟其他方同步并征求意见最终确定下来（这样做的原因，是出问题一起背锅……）。

应该怎么判断一个接口做不做压测？

1. 有历史数据就基于历史数据判断重要性或者优先级
2. 如果没有历史数据，要预估新接口的 QPS 和对应的服务器资源。如果 QPS 达到某个阈值就考虑压测，阈值要根据业务和历史压测其他接口的情况去判断
3. 产品核心功能相关的接口一定要压测（除非真的没人力，而且预期没有负载压力）
4. 测试直觉……（这个接口 tmd 肯定在压测时有严重 bug，那就压它证明自己）

2 楼已经回答得很好，我补充一下个人的观点。从面试官的角度来问，其实本质上是考察你对整个业务的熟悉程度，面试官可能想从一个相对系统的视角来看看你有没有梳理过整个业务逻辑，所以才会问这种问题（我也偶尔会这样问，住）。

ok，知道面试官的目的，我觉得就可以针对性回答。
一些猥琐加分技巧：我们的目标是要让面试官能通过我们的口头描述，让他 “自认为” 理解了业务；同时为了让他听得开心，让他觉得自己的理解力好强，所以我们还要找重点去说，并围绕这个重点做深入。

综上，回答方式可以这样：

1. 先从典型的用户场景出发，描述整个系统在各个环节上偏户侧的输入输出，这是为了让面试官理解业务形态
2. 从系统外部数据入口出发，对场景分割上下游等不同环节，将系统拆成 A->B->C->D 等简明流程（一定要注意抹去技术细节，有些很繁杂的业务互相调用，说出来会加深面试官理解难度，反而让面试官觉得你说不清楚没有条理）
3. 逐个解释 A、B、C、D 各自干了什么事情，以及挑里面的一两个难点升华一下（这是为了突出你对技术细节的关注，如果了解够多，还可以说说业界一般是怎么解决这种问题）

以上。

一些点：

1. 除非面试官问你数据库表的设计，否则不要说到那种粒度，因为没有必要，它不是重点
2. 注意整体条理性和清晰性，在细节和简洁上做选择，个人建议牺牲细节。面试就是要让面试官理解，而不是把面试官说懵
3. 这不是写文档般严谨的工作时序图，除非有纸笔现场画，否则真没必要讲得这么深这么晦涩

Get ~

是的，开放出来的 fastbot-android（只是开放并没开源），阉割得比较厉害，是内部测试能力整体表现最弱的版本。
另外fastbot-ios已经是正式开源了，应该是市面能找到的 top 工具之一，作为受益方给他们自来水一下。

回到整体，UI 自动化是真的累，而且要做到全覆盖真的不理性，也可以考虑 UI 自动化 +monkey，如果能使用 UI 自动化先定向走都一个路径，结合客户端一些页面操作的限制能力保证测试场景不会跳出，这个时候用 monkey 去遍历也是一个点。但这个思路依然无法完全解决上述的问题，只是算是手段之一，增加一下工具箱或者弹药箱的感觉。

这个意思是，把 app 的独立功能模块抽取出去单独测试这样？能举个例子感受一下吗？感觉这个是一个不错的思路，但本身如何识别功能独立也是一个很难的问题，尤其是在几百万行代码的项目中。

schema 我们是在测试和线上去收集的，schema 本身倒没问题都能用。比较局限的是，一条 schema 就代表跳转到页面所带的参数是固定的，除非针对一个页面收集了很多不同参数的 schema，否则测试参数输入就会比较少，质量说服力就会降低了

同 10 楼，面试官在面试你，同时也是你在面试面试官

我的理解是银行对资损防控上的谨慎，直觉上银行是直接管钱的，而互联网金融是间接操作钱（或许碰不到实际的钱，最终还是要去到银行？）。在用户体验上的评价是这样的，欢迎澄清一下区别

测试数据

这就是第一个难点，测试数据的缺失。虽然我们可以通过 mock 的手段，把自己的系统测试充分，但是全链路联调测试阶段和预发阶段都没有办法保证。这一点，其实还是非常影响发布信心的。

财经的 QA 会自己花钱在线上真实环境跑用例（转账、付款），最后再走退款流程把钱拿回来，也有在用流量回放、MockServer 等技术。

测试环境

对于老功能的回归，通常下游机构是没有义务配合你做回归测试的，所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办？这也是我们目前遇到的问题，没有一个稳定的测试环境，可以用来持续回归。

关于线上压测和回归，忘记之前从哪里听说的，银行那边会给个固定的压测 QPS 要求，如果超过这个 QPS 就算发压方（也就是我们）的事故。
吐槽一下，平时用个招行银行 app 转账还提示等待 10 秒，用支付宝和微信转账根本不存在这种等待，就是传统银行跟互联网的区别，背后就是新老技术架构、风险承担能力、成本结构的差异。

业务中台

当然这个时候，也给中台投入了专职测试了，要把中台的质量最厚，测试策略也调整为：中台功能测试 + 中台回归测试 + 上层业务回归测试（可评估）。目前还在试验中，其实也不清楚是不是有效果。

以前跟教育业务线的小伙伴交流过，他们比楼主更原始一些，部分教育线的业务中台甚至跟上层业务耦合在一起（也就是业务中台给不同业务做了一堆定制需求）。导致了但凡中台一改，很多业务都要跟着回归一遍，或者业务改了，中台要跟着改，互相坑。

他们的改进路线也比较明显，先让中台逐渐与上层业务解耦，解放测试人力，然后也是将部分 QA 挪到中台中做专项测试（其实很多业务线都是这样做，中台作为最核心的部分，不放人去做专项测试是不实际的，自己都方得都命）。

另一个点，正因为中台是通用且稳定的，意味着老逻辑改动频率低，所以中台更加适合做各种自动化回归（接口自动化、流量回放等），这个收益应该是比较显著的。

由于自己没怎么接触过这类 toB 业务，也就只能把一些道听途说的东西写上来。对于测试数据和测试环境，简单问了财经的 QA 同学，答复中没特别的信息，估计也是存在一样的问题。

这个回答下面一共有 467 个回答，我通过这样去请求，只会获取到 181 个回答，其他的回答就获取不到，如果把 467 设置为更大的值，获取到的还是 181 个回答

后端的防护性编程，为了防止前端传参过于离谱导致数据库压力过大，合理操作。你就自己设置一个合理 offset 分几次循环去请求就行了，也没必要非得一个请求拉下来所有回答。如果你嫌弃 for 循环串行请求耗时长，你就上多线程或者异步，网上很多资料。