申请开通专栏~ 感谢 @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 循环串行请求耗时长，你就上多线程或者异步，网上很多资料。

这种需求最好就是直接白盒测试，根据等价类划分和边界条件来区分 case，穷举遍历没有任何意义。好比我的代码逻辑是

int a,b,c;
c=a+b;

那无论你穷举出多少个 a 和 b，你不过就是在测试 java 的加法有无 bug，根本就是在做无效测试。

有一个问卷调查，包含 9 个小问题，每个问题有 A B C D 等多个不定项选项，每个问题的每个选项对应不同分数。

所以我觉得关注点并不是穷举 A B C D 分数总和（这个求总和可能就是一行代码而已，如果没有额外的条件分支，那一条 case 都过了），而是不同题目的 A B C D 这几个选项它本身映射的分数是否符合预期，以及几个关键的分数总和点和答题场景（如全对、全错、对错混合、部分题目没作答、全部题目没作答）

驱动我自己变化的，主要是周边工作环境和工作接触面的变化。

工作环境的变化：人外有人天外有天，无论是牛逼的前辈，还是变态的后浪，出现在身边的案例越来越多，反正明白的一点是 自己很菜 。自知之明确立下来，人就知道了自己的定位，自然会有动力去不断学习，只是这个学习的过程它本身是否高效而已（我觉得我是比较低效的 QAQ）。
@ 恒温 也提到，有些人 5 年的工作经验可能只是跟 1 年一样，有些人 1 年的工作经验就是实打实的 1 年甚至更多，如何衡量这个 “实打实”？自己问自己，对于这个业务或者事物，它的方方面面，无论是本职的，还是上下游，从 透彻->理解->熟悉->了解 列一下，就知道水平了。

• 透彻：有行业视野，能判断出什么是好什么是坏，能根据场景客观评价技术，看清趋势，灵活应用实践
• 理解：明白整个事物的逻辑，背景、解决的问题、技术细节都掌握，达到自己能把核心的东西做个简单版的地步，对不同替代方案的优缺点有一定了解
• 熟悉：知道这个事物的落地形式，有真正参与建设过，对单点细节有一定理解
• 了解：知道那么个概念，知道其所解决的问题，最好有使用过

（以上分类仅供参考，临时写的……）
避开重复劳动，在熟悉以及理解本职工作后，尽量去往上下游拓展，去 “偷师”。其实跟楼主说的【差别在于花了多少时间提升自己】意思是一样的。

工作接触面的变化：很多时候只有实践才能出真知，这个感同身受，有些东西说得很简单（它不一定是纯粹的技术），但是做起来非常复杂琐碎难处理，最后做出来的效果也因人而异。接触过不同的技术领域，如果把它们放在一起来对比看待，有时候会有新风景，或者说自己脑袋中会出现一个更全的图。这个 “图”，可以支撑你在不同的公司，按照这个 “图” 来一步一步完成建设。说白了，你的知识体系和经验会更加完整。对于创业公司来说，你这个 “图” 可以帮助公司识别哪些建设是最高优的，然后调动人力尽快拿到收益；对于成熟公司来说，你这个 “图” 可以帮助公司识别还欠缺什么需要建设或者完善，做到百尺竿头更进一步。

顶一下帖子，长期有效（至少是半年内）

好吧，首先楼主估计就是来打广告的……

看到帖子里提及 Fastbot 工具，确实好用，平时跟 Fastbot 团队同学往来十分密切，有多次出差约饭的经历，在 app 稳定性测试上，Fastbot 应该是市面公开最好用的工具之一了吧。不过外部公开的是超级阉割版，内部还有各种多机遍历、用户模拟、定向测试等高级特性，很多都是跟 Fastbot 服务端有直接通信的，算法模型直接放在服务端而非客户端，估计短时间也不会公开。

核心业务大都承载在移动 app（类游戏系列）时，如何做好回归测试，缩短测试周期，实现快速交付呢

不过，Fastbot 只是用来做稳定性测试，换而言之它只能断言崩溃卡死问题（如果 app 本身接了 apm 那就更好），无法识别 UI 层面甚至白屏黑屏的问题。
这种这么范的问题，妄想通过加一个工具就能解决，第一个还是先从流程上解决沟通效率问题，流程顺了各自分工明确了效率就会高起来。
UI 自动化用来做回归测试，绝大多数就是一个谎言，现阶段大多数公司甚至大厂，UI 自动化本质上只是一个定向遍历的驱动器。除了少量的核心 case 能用 UI 自动化做最基本的检测外（往往这种检测的断言还很粗犷，起不到效果），要想拓展 UI 自动化的应用范围和效果，其实还需要非常多配套设施，除了 UI 自动化框架本身，最核心的点是：一、降低 UI 自动化编写维护员成本；二、提高 UI 自动化断言准确性。在字节跳动内部也就是还在各种探索的阶段……

可现在的环境里面 QA 是越来越多能化，啥都要做。心里也想着我到底在干嘛？

多能化是一件好事，至少代表这 QA 这个原本是从研发职能中分离出来的岗位本身具备越来越多的核心价值。老生常谈，社会要求 T 字型人才，先专后广，也就是你得现有一个苟起来的方向，然后再往上下游拓展。至于这个方向是什么，要不参考你自己的技术爱好，要不就你手头现在负责的工作方向。

随后便开始想我到底想要什么工作，如果不是 QA 那么转岗还来得及嘛？希望大家给点意见，QA 能干多久？

我身边有 QA 转 RD、RD 转 QA、QA 转 PMO 的各种案例，很多时候转变序列不应该是你日常工作翻天覆地式的变化，它一般是从你日常工作中顺其自然切换过去的。比如 QA 转 RD，那必须是你还是 QA 角色时就承担了很多开发工作，在开发方向有一定积累，你才有可能实现 QA 转 RD，其他转职同理。
QA 能干多久？这个看人，如果自己没信心也没动力持续学习持续进步持续沉淀，说实话，35 岁的坎不是空穴来风。否则 35 岁只会是一个数字，只要你的价值跟得上年龄的发展，比如一个同事（某大厂多年技术专家、也在某手机厂带过上百人的部门）就已经超越 35 岁，但不妨碍别人混得风生水起。

看看你公司缺什么，哪个最痛。从上面的大平台里细拆小方向，先做小的东西把坑位占住，然后从小的慢慢拓展到大的不就成了么？
关键还是你要对现状掌握得很明白，毕竟我不了解你们内部情况，就只能给你瞎枚举一下了

1、留在这公司，子公司目前是没有测开的，未来可能有机会上位（领导的饼）

领导画的饼多数时候要自己判断，按照我的经验，领导很少会说谎，但是一般会把某种东西稍微夸大一些，所以就需要有自己的判断。

2、在 HR 业务线继续沉淀下去（继续完善 HR 体系，解决 HR 痛点，提效）

HR 业务线我自己没接触过，但是直觉上这个方向的业务简单且不具备足够的探索空间。之所以这样说，是因为我了解到的这类内部 ERP 系统，流程和技术似乎都很成熟了，做到天花板那就是做成 toB，由于系统业务特性问题用户体量有限访问量有限信息反馈也很慢。换而言之，单纯从技术角度看的话，天花板低。我的建议是不要留在 HR 业务线，商城业务线显然是一个更有利的业务线。

3、喊领导说换商城业务线？（前脚刚拒绝后脚又答应，这也太什么了。。。）

无可厚非，找领导说清楚原因，给他上下文让他明白你为什么当时要这样说，做得了领导应该还是能有正确的判断……

4、尝试一下跳槽，自己是自信但又不自信的人，面试又会怯场，学历硬伤，工作经验也才 3 年多，怕出去后找到的比原来的还差。。。

外面的世界很大，我建议时不时出去看看。你可以把面试当成是与面试官的技术交流，又不是非得面了就一定要去，面试和工作是不冲突的，先找一些自己确定不会去的公司练练手拿拿感觉，再去更有意愿的公司试一试（不过机会一定要珍惜，因为有些公司面过了但不去是会有冷却时间的），offer 不满意就不去，说不定分分钟涨幅 40% 呢？

公司内部有几百个平台，随便举一些测试开发方向的，任何一个厚度都足够以年为单位。
移动端：apm 平台、云真机平台、monkey 工具、ui 自动化框架、录制回放平台、性能数据追踪分析平台……
服务端：压测平台、流量回放侧事平台、测试环境、数据构造平台、接口测试智能化技术、Fuzz、自动监控与运维……

顶一个

投他！

收到 ~ 简历蛮合适的，这边联系 HR 在一周内发起一面，一般一二面加起来大概花一周多时间，比较快