难道性能测试只能通过工具来做？

大部分情况下，用工具做会简单很多。写代码也可以，但你要写不少代码，比性能自动化多不少。而性能测试对于工具的要求其实比较通用，所以大部分工具本身可以满足，不需要从零写代码。

另外，性能测试工具，一般指的是发起压力的工具（如 jmeter）。实际完成性能测试，还需要监控排查的工具（如 jprofile、grafana）。你说的死锁什么的，要通过监控工具来找。

性能测试需要掌握一些什么？

你这个要了解的是 “性能测试怎么做” ，相当于一些基本概念和理论。楼上说了不少文章，可以去看看。

作为一个突然被告知做接口的性能测试的小白，有点不知道怎么下手了

想系统入门一个东西，不要靠搜索引擎。搜索引擎可以找到的是最热门的，但不一定是最系统的。一般技巧都是热门，但概念理论都不热门。所以你需要的是找一些系统点的课程或者书去学习。

上次（2019 年）参加广州测试沙龙分享后最大的感触，就是大团队做的事情和我们小团队的很不一样

小团队做得好且愿意出来分享的真的很少。下半年广州计划再来一次沙龙，有兴趣来分享下么？

这个我觉得不用担忧，你有一线大厂背景，不至于找不到工作，只是怎么找到适合自己（特别是薪酬待遇和发展空间）得花点时间。只是提醒一个点，要留意下除了使用大厂的提供的工具外，也留意下，即使不使用大厂给的，自己用外部开源工具也可以搞起来就行。一般外面其它中小厂面试大厂出来的，会特别关注这个。

另外，你如果后面计划是转开发，建议一开始就做开发。测开和开发虽然都会做开发相关工作，但测开关注的是整体方案和是否满足团队需要，要能给几百上千的测试团队乃至研发团队提效，相对更偏广度；开发会面临更多的系统复杂度和业务频繁变化挑战，要给千万甚至过亿用户提供服务，做到高可用和高性能，偏深度。两者往后走差别会越来越大。有可能到时候你的测开经历，到时候找开发岗位，会不如走开发好找。

不知道你 offer 是否会参与业务测试，还是专注做工具平台。如果是后者，估计你找业务测试也不一定好找，因为这方面经验比较少。有机会还是尽量也参与下业务吧，业务才是根本。

从你的需求看，你不满足于模拟，对真实度要求很高。说实话，这么高的真实度，除了真实在那个地点有一个网点外，别无它法。然后手机能请求的，电脑一定也可以。这样就不局限于手机，可以看各家云厂商的机房都有分布在哪些城市的，在各个城市的机房都开一个虚拟机，当做当地网点。不过机房网络和移动网络的路由还是有差异的，无法真正做到一致。

但我觉得你是否可以换一个思路，不一定要主动发现（说实话，日活高的话，主动发现和监控发现差别也不过几十秒，甚至只要几秒。从发现问题角度，没啥差别，这几秒你也不可能完成回滚或者重新上线），而是在影响更小的情况下完成数据采集，以及快速响应解决问题？

如果按这个思路，数据采集可以这么做：
结合地域流量控制的灰度发布，只放指定城市（可以通过 ip 过滤）的 xx% 流量，看监控数据是否有波动预警

解决问题可以这么做：
多准备几家 CDN 厂商，发布时同时发布。日常流量策略优先给在当地表现好的厂商，少量给表现一般一些的（作为监控手段），如果发现监控有问题，立马调整流量策略，增大到其他备份 CDN 厂商的比例。

还有后续吗？比如有找开发协助操作什么，开发有真的协助了吗？

你这个表达对于内部对背景情况啥的都清楚的可能有用，但对于对你经历一无所知的面试官或者外人，真的是一头雾水。。。比如为啥会有黑名单这个功能，使用场景是啥，要解决啥问题，和前端 Element-UI 框架又有啥关系？你这里只是一个 List 的循环，和你提到的 BFS 广度优先算法遍历节点作为引擎驱动各种 Action 事件 ，又有啥关系？你第二段介绍只是让问题增多，并没有解答疑惑。

我们的 UI 自动化框架，有个设备白名单功能（别人做的哈，我只是拿来做示例），也很简单，只有白名单上有记录 udid 的设备才跑自动化，逻辑实现复杂度也不高。但要让其他人（比如面试官）能了解清楚，我会这么介绍：

S（situation，情景）：随着 UI 自动化逐步推进，有的组已经建立起了 Jenkins 定时跑 UI 自动化的 job 。但由于目前自动化脚本主要适配的是固定机型（不同机型下 UI 布局会有一些变化，导致不稳定，兼容工作量不少，所以暂时先针对固定机型调优），而这个 Jenkins 有时候会接多个手机（有的用于跑 monkey，有的用于跑性能等）。当时 UI 自动化框架为了简便，driver 对象是自动生成，用例直接使用的。生成时会从已连接机器中随机选择对应平台的机器，缺少指定机器的能力，有时候会由于跑到了其他机器，UI 布局有差异，导致脚本不稳定。
T（task，任务）：因此，经过和各个组沟通，确认通过设备白名单的方式提供这种能力。白名单可以让自动化框架只选择里面的设备运行，如果设备未连接，直接失败。
A（action，行动）：在配置文件中，增加一个白名单配置项，类型为 list ，值为设备的 udid 。框架在初始化全局的 driver 对象前，增加一个确认是否有指定白名单的步骤。如果有，那就只使用白名单的。如果白名单只有一台，那就直接用。如果有多台，那就选里面有实际连上的其中一台。
R（result，结果）：各组只需要增加一个配置项，和升级框架版本，就可以进行指定设备跑自动化，UI 自动化也不再出现由于跑在不同机器上导致不稳定的问题。

这个没研究过。不过我自己也用的 10.15.7 ，好像没怎么看到有升级弹窗骚扰。刚看了下，设置里好像可以关掉升级检查的，你可以试试？

你的签名是怎么签的？没看懂自签名具体是什么意思。

感谢提供信息。话说 ios 14.6 系统好像有自动下载更新的开关了，我理解关掉就可以了？

这个好像要调整系统时间，骗过过期时间验证？

这个代码片段看不出啥，有点一头雾水。而且从这个函数倒推， blackElements 的值有点怪怪的，可能是 text ，也可能是 id ，甚至可能是 xpath 。

可以完整点说下不？对于怎么完整地表述一件事，可以参考 STAR 法则。

也分享个我之前遇到的情况及解决方案，供参考：

当机器连接比较久的时候，发现会由于打开控制界面自动创建输入法的 websocket 通讯，导致 adb 连接整个卡住（运行 adb shell 都卡在那里），影响到屏幕会没有加载的情况。（特别明显的界面特征是，想获取设备的应用列表都获取不到）

解决方案是去掉了自动创建输入法通讯这个代码，要输入的时候手动点【修复输入法】来手动创建。

如果这些都能做到，对一年经验来说能力绝对不差，不应该面试如此不顺。

可以 show 一些封装的例子或者你的总结笔记看看不？

有的，有兴趣来试试？可以直接简历发我邮箱，chenhengjie@lizhi.fm

按照你给的这个数，对于普通直播应该是很够用的。倒是要看看会不会有非微信直播组件做的直播路径必经功能（如进房、出房、心跳保活、公屏信息收发），如果有，要评估下是否扛得住。

赞！

额，从描述上看你们用的整个视频直播都是微信提供的组件，那你这个压力测试，是要试试压力到多大能把微信直播组件拉胯吗？个人理解一般提供这类服务的第三方组件都会有内置的限流策略，达到阈值就直接卡掉了，而不是等真的组件被某一个租户的压力压垮。

另外你括号外面和括号里面是两个完全没啥关系的问题，一个是功能，一个是性能。建议先描述清楚你要测试的到底是什么？

这个支付宝是正式 appstore 的支付宝么？如果是，那 webview 的调试端口估计都是关着的，没法直接访问。

可以问下支付宝那边的技术支持，看有没有提供这方面的一些方案？微信小程序好像是对应提供了一个测试工具的，支付宝不大清楚有没有。

以下文字可能有点直接，请静下心看下：

1、不知道你有没有总结过自己面试哪里不行？30 多家没有一家 offer，这里面一定有你自己的原因。

2、你正文都是提环境怎么不适合，但没有提过自己怎么尝试去改变环境？（闷头自学属于改变自己，不是改变环境，这个要认清。虽然毕业一年不要求能改变环境，但连尝试都没试过，说明你自己态度上还是略消极）

3、学了不用就忘，忘了又重新学，不用还是得忘 ，你笔记有做好记录么？有梳理总结吗？如果有，就算学了不用，到用的时候根据你的笔记应该是可以非常快速就用起来的。如果做不到，那就是你笔记没写好，连自己都没法用起来。我现在有时候弄东西，偶尔还是得查自己以前发的帖子才能回忆起某些关键点，但也比从零开始快多了。

4、我应该把握金九银十跑路吗，不知道是不是我个人感觉，社招好像已经没太明显的金九银十这样的规律了。其次，你想要换，也没必要等金九银十呀，找到合适的就去面呗。先提升自己水平到能拿到 offer ，再纠结是不是现在适合走。offer 都拿不到就别纠结走不走了

5、我目前广州在职只有 6k，算正常吗，以我的了解，在广州，1 年经验，这个工资并不算很低。但我觉得你需要纠结的不是工资，而是自己的长期发展。这种情况下，建议你还是想好自己是想追求眼前的薪酬，还是未来的发展。当然好公司两者都会有，但如果没法两者兼顾，你得想好你的选择。

最后，回应主题，分享下我的经历。我当年毕业一年在工作中确实都还在点点点，但工作外也会自己写点程序辅助自己（比如写个爬虫帮我抢购 macbook 官翻版），并保持对技术的了解（以前在学校网络部做过，做过 web 网站开发，所以有点技术基础）。然后第二年很幸运凭借自己有 python 基础，比其他真的只会点点点的能力强一点，得以加入了一个测试工具开发小组做主力开发，并在各种找资料中了解到 appium ，加入社区，后续就逐步就深入代码往技术方向发展了。

看到前面提到外包，多回复一句：外包只是工作形式，面试更看重的是能力。一般的思维不是 这个是外包=这个就差，而是这个水平好像偏低->哦，原来一直在外包。

所以不要太纠结外包这个身份，只要你不纠结，面试官也不会纠结的。而且从简历上看，除了工作经历跳槽比较频繁（基本是 1 年 1 跳）外，倒没怎么看出是外包的。

好的简历怎么写，建议去知乎或者招聘相关公众号找找，应该都可以找到相关文章。个人理解，最基础的是要用 STAR 法则来写每一段经历，才能讲得足够清晰准确。现在的内容只有 STAR 里面的 Action ，其他三个都完全没提及。这类写法实在太常见了，所以有经验的面试官看到后，都会默认认为里面提到的其实都是 “能在辅助下运用” 水平，然后实际面试再抽 1-2 个确认下深度和掌握度，10 分钟内找不到亮点就可以结束了。

嗯嗯，所以要结合团队情况看。

写配置的其实也是有办法做成复用的，最常见的方案就是关键字驱动（比如 robot framework），可以用写用例的方式写函数封装。不过会有点感觉像是四不像，简单程度上比纯数据驱动会复杂一些，毕竟可以有控制语句了（if/else/while 等），灵活程度上又没有代码灵活，没有适合的 ide 配套写起来非常难受。

我是觉得，如果编程水平实在不行的，那就直接弄录制回放，甚至考虑下此时是否适合引入自动化。因为先不论自动化脚本编写难度如何，实际自动化总会遇到一些问题需要排查，而排查解决没有一定的编程基础，是搞不定的，容易直接卡住。这种情况下，要不有专门自动化团队有能力协助搞定这些问题，要不就通过培训 + 淘汰，提高团队这方面能力。

可以考虑让运维给你临时开几台虚拟主机，直接把压测工具和脚本放到 git 仓库，然后 clone 到机房主机。跑完后把报告数据拉到本地分析生成图表。也可以考虑直接部署个 meterphere 上去，直接 web 平台操作，不用拉来拉去。

公司内网到机房的带宽是有限的，而且如果中间有 CDN 之类的挡一下，你基本压不倒实际服务。

以下仅代表个人观点：
1、写 yml 配置形式。好处是实现简单，上手也简单，容易统一。缺点是灵活性容易受限，对于相对复杂的用例，写和调试相对麻烦，不好复用（不是复制粘贴，特指调用已有的某些步骤）。
2、直接写代码。好处是非常灵活，缺点也是过于灵活，没有好的规范容易乱。同时上手也相对难一些，需要有一些编程基础。

具体选哪个，核心看你们目前团队的编程水平。会编程的人多，第二种会更好，因为灵活性足够高，因此用例怎么多也不至于太乱。如果大部分不会编程，选第一种，甚至直接选录制回放生成脚本的可能更合适。

做的项目全部没有效果数据，看不出掌握程度和项目难度。比如自动化多少用例，通过率百分之多少，突破过什么难点，都没提。体现不出水平，默认认为水平不高，也看出总结归纳能力不强，有需要当一些项目负责人或小组长，会有点悬

见过一些 1-2 年的简历，写得也差不多，属于都会不精。3 年最好有一个精一点的，详细写下，突出深度。

建议你看看 chrome 开发者工具里的 lighthouse 和 performance ，注意不是直接看界面（这个东西还没简单到直接看界面就无师自通），而是去找相关的使用文档先了解下。这两个就是做前端性能检测相关的事情的。

另外，浏览器提示卡死这个现象，本身就基本上可以排除服务端原因。因为服务端再怎么慢，也只会导致请求超时（请求都是后台异步的，本质就是持续的等待），不会导致资源耗光引起浏览器认为卡住（个人理解应该是 UI 主线程卡住，没法响应任何用户操作事件）。同时也通过看浏览器 network 里面这个服务端请求的返回耗时，看是先返回，还是先卡住。