建议优先学习你工作上用得到的相关工具吧，selenium 跑个 demo ，做个笔记记录下来，便于后续工作上用到可以快速捡起来就可以了。

工作上用不到，很多东西你比较难接触到，虚拟项目和实际项目还是有很大差异的。比如之前社区有挺多同学提问那些基于 vue 或者 react 写的控件，selenium api 直接操作没有效果，这类不在实际项目里面用，不一定会遇到。

hmm，不确定这个问题提问时，面试官想了解的是全貌，还是单纯被测项目的信息？

如果是全貌，这里用类似 STAR 法则去分点说明，挺全面的，逻辑也很清晰。成果描述稍微优化下，尽量写比较实在的东西，而不是那么虚的东西，会好一些。

如果是单纯想被测项目信息，考察对项目的熟悉程度，可能还是稍微有所欠缺。上面对项目的介绍有点简单，听起来像是纯搬运产品介绍文案的内容，没能看出从你作为测试人员角度，对这个项目的一些思考理解（比如这个项目最具价值的功能是什么，它的价值是什么，为什么是最，你用到了什么手段保障这个价值可以交付给客户而不受质量问题拖累）。

PS：主观题自动批改，客观题教师在线阅卷的功能 ，这里是写反了？客观题不是更容易做自动批改么？

所以，哪里可以实践使用 Selenium 的项目吖?

日常你测试的 web 站点相关用例，有改为用 selenium 来帮助你完成它吗？如果没有，可以从这里实践起来。很多所谓的高级技巧，其实就是当项目复杂到一定程度时演进出来的技巧。项目复杂度没上来，学这些其实不大容易理解和代入。

其实我是基于安全方面进行考虑的，当时我在写接口用例，然后我就想如果前端/后端都按数据库设计来进行的话是不是很大一个程度提高了系统的安全性（如：SQL 注入，只要对每个传参类型和长度进行校验，就能很大的把 SQL 注入难度提升一个级别。）所以我当时的理解就是所有的接口都必须做长度和类型的校验，最好和数据库设计的字段保持一致。

你说的这个想法，是有具体实例佐证么？有的话，可以分享下？

以我对 sql 注入的了解，通过这种方式去防范有点 隔靴搔痒 的味道。sql 注入防范的核心是在数据解析 sql 的位置，防范用户原始输入值带有 sql 关键字引发 sql 查询实际作用和设计目的产生很大的差异，进而泄漏一些不应该出现的数据。比如很常见的 sql 注入参数输入值：1 or 1 = 1，长度一点都不算长，类型也只是一个很普通的字符串，但里面带有 sql 关键字 or 、= ，会引发 sql 语义变化，所以需要进行防范。而且这类防范，mybatis、jpa 等常见的数据库连接框架，写法规范的情况下已经自动进行防范了，从接口规范层面通过字符类型 + 长度去防范，个人觉得实在没有必要，也不一定能起到实质性的防范效果。

建议先别定规范，定一下协作机制就好。

人少的话，其实沟通成本也不高，有些事情同步到位就可以了。规范很多时候是人多了，某些重要事项做事方式不统一，引起的额外沟通成本比较高，才需要以规范形式定下来的。

接口传参长度和数据类型应该与数据库设计的对应字段保持一致

楼主可以分享下你要测的接口参数是什么，对应设计的测试用例大概是什么，哪些用例执行失败引发这个帖子的思考么？

如果从上面这个文字意思上看，这个接口和数据库长度、类型保持一致的限制有点死，一旦长度要变化（比如需求有改动），服务端代码 + 数据库 DML 都得改，略麻烦。一般来说，数据库字段长度限制会设置得比实际业务规定长一些，避免后面改大还得改 DML 走审批流程那么麻烦。而且常用的 varchar 变长字段类型是按实际内容占用存储空间的，这个长度设大一点，不会引起什么副作用。有时候偷懒会直接不设置接口的校验，直接交给数据库来限制（大于字段定义长度，数据库会直接无法入库，返回失败，但一般这种情况不好给明确指示用户是超出长度，只能后台查日志看出，所以说是偷懒）

另外，不知道你们后端使用什么语言框架做开发，如果用的 spring ，类型和长度这类比较死的限制，复杂度不高，甚至在写接口定义代码的时候就可以完成了。

数据类型：数据类型这个 spring 是自动根据服务端设定的参数数据类型转换的。比如类型是字符串，那接口不管传字符串的 0 和数字的 0，框架都会自动转为字符串的 0。但如果类型是数字，传了个转不了数字的字符串（比如 a ），框架会自动报错拦截。

长度限制：接入 JSR 303 框架，给要限制的参数加上 @Size(min, max) 注解就可以了（可以参考 https://www.jianshu.com/p/d2ddd856cce2 ）

要写全挺多的，上面也列了不少。

从楼主上面信息看，测试团队应该还比较新甚至只有 1 个人，那要规范的应该主要不是测试（才 1 个人用的规范性价比不高），而是测试的合作方。推荐可以优先写比如项目流程规范、提测规范、缺陷等级规范这类涉及合作团队的部分，减少不规范的合作形式引起的额外成本。

完整看完了，很有收获。对于 35+ 的问题视角，也很有参考意义。

这个问题没太看懂，保障测试质量指的是保障测试团队的工作质量，还是指项目中的质量保障？不知道当时面试的上下文，所以没太理解这个问题到底想问什么。

另外，可以也分享下你一般给出的回答是什么？

不好意思，确实我之前逻辑不够严谨。在服务端没有达到满负荷（即服务端每个处理线程都在工作中没有闲置，也是我们俗称的性能拐点）时，确实是压测工具的线程数增加，响应时间不变，tps 增加。

我其实核心不认同的应该是 线程数=并发 这个观点。我对这个观点的理解是：针对正文里的 登录接口能够承受秒级 1000 并发 ，就应该用假设 1 里面的 1000 个线程去发起压力，并要求响应时间达标。

在我的经验里，一般在线程数在比目标 tps 低不少的时候，系统就可以达到目标 tps 了。真要用和用户数一样的线程数去压且不考虑思考时间（现在越来越少人用这个了），容易给到过大的压力。

如果实在无法改变，那就先保持一致吧。

我一般的做法是，把产品的性能需求想办法转换为 tps+rt 目标指标，然后再去拿这个来和开发运维沟通以及出报告。一般其他角色只要觉得你的转换思路听起来是靠谱的，那他们也不会说你非得怎么怎么样，毕竟这个不是他们专业范畴，一讲深他们其实也就听不懂了。

一般不是业务和产品喜欢用并发用户数 +rt，开发运维喜欢用 tps+rt 吗？你意思是现在开发和运维也喜欢用并发用户数了？

一般高并发（线程）才能达到高 tps

这个结论和我日常认知差异有点大，建议你试试用 10 个线程去测试某个逻辑比较简单的接口，然后换 100 个线程再测一次，对比看下 10 个线程下的 tps ，和 100 线程下的 tps ，差异会不会很大？

个人理解，专业的性能测试人员，应该要用 TPS + 响应时间 来描述服务端性能。包括要达到的性能目标以及实际测试出来的性能结果。

• 先来解析下你正文里这两个看起来好像等价的假设：

假设并发理解为线程的话，1000 线程持续执行 60 秒，结果理论上应该产出 60000 条数据才符合需求

其实你这句话里面带有一个预设条件，就是每个请求的响应时间大约是 1 秒。要满足这个场景，性能需要达到 tps = 1000 + 响应时间 = 1s

假设并发理解为 TPS 的话，可能花 30 个线程就可以达到 1000tps 执行 60 秒，结果也能产出 60000 条数据

而从你这句话来倒推，30 个线程能达到 1000 tps ，意味着平均每个线程每秒得产生 33 tps，意味着接口的响应时间必须控制在 1/33（约为 0.03）秒左右。要满足这个场景，性能需要达到 tps = 1000 + 响应时间 = 0.03s

所以，加上响应时间这个指标后，你能明确看出来，这两个场景下对服务端的性能要求其实差了 33 倍了吧？

• 至于为啥大家会喜欢用线程数，我觉得里面有一些历史因素。

以前 LR 类似 JMeter 线程数的东西叫做 virtualUser（虚拟用户），意思是这个就是虚拟有多少个用户在使用。同时为了让这些用户表现更符合实际情况，还会有需要在每个操作之间加入 thinkTime（思考时间，实际就是固定的等待时长）。所以我只需要评估高峰期大概系统会有多少个用户来用，正常用户习惯每次操作之间间隔多久，就可以把这个场景直接输入到性能测试工具里，直接作为性能场景使用了。

但随着时间推移，这个思考时间越来越少人用或者考虑，因为不管设定多少都很难靠谱，而且思考时间差 1 秒，实际发起的压力就会有很大差异。但虚拟用户转变为线程数继续留在了 Jmeter 里，所以大家会习惯继续这么称呼，毕竟老板和产品更能听懂 “并发用户数” 这类词。但实际上只要稍微想细一点，就会发现不精确，因为这个场景下，线程和实际用户的核心差异是，线程得到响应后会立即再次发起请求，但实际用户谁有空没事做会一直不间断给你发请求呢。

因此，一个合格的性能测试工程师，应该能做好翻译工作，把老板和产品的想法，转换为专业的性能指标，应用到性能测试里。

哦哦，OK。

嗯嗯，大概理解了。你们的术语用法有点特别。

你这里的灰度测试目的是发现由于测试环境差异引发的问题的，这种我们一般称之为 “预发布测试（为发布做准备的测试）”。预发布环境用的是线上数据，也和线上环境在同一个机房环境，但入口是只有公司内网可以进入，外部用户进不来，测试期间用的也是测试人员自己的账号，而非外部用户的账号，保障就算出问题，对外部用户影响也为零。

预发布在互联网里面很常见，也很有效（能有效验证开发发布时做的各个配置项改动是否都合理到位，且由于环境完整，有些涉及第三方系统的测试也可以完整进行）。大部分在测试排期时就会单独排出来预发布测试阶段的。

而我们一般说的 “灰度测试/灰度发布”，指的是在线上环境只更新少量节点结合流量控制，做到只有小规模用户使用新版本的效果。如果出问题，会真的影响外部用户，只是用户规模会比全量小很多（一般 5%-50% 不等，可以自行控制）。详细的你可以搜索引擎看看。

方便把你项目其他无关信息精简掉，只留下能重现问题的最小项目内容，打个包或者上传 github 仓库后发一下不？

我这边没遇到过你这两个报错，不好评估。

这帖子正文看的云里雾里。。。

楼主到底是想问值不值得去，还是想问灰度是不是就可以解决发版晚的问题？

如果是前者，这个主要看你自己，有些业务性质决定确实只能放深夜发版，你很难改变业务，只能自己。

如果是后者，建议楼主先把你们家的灰度是怎么做的说清楚。正常灰度发布是按天算的，否则灰度的量不够，不具备代表性。而楼主这种感觉不像是正常的灰度。

感觉楼主这几个问题有点奇怪。楼主理解的灰度发布是什么？

我理解的灰度发布本质上是小规模线上新版本测试，降低出线上问题的影响用户数，进而降低线上问题引起的损失。它和我们日常主动做的回归测试完全是两码事，出问题是切切实实影响用户的线上问题。

在灰度发布的时候如果把问题都修复好的话，那全量出问题的概率确实是会降低，但 “不容易” 这个用词我觉得不妥，好像有了灰度发布后线上很难出问题一样。这个和灰度的量有多少，很大关系。

全量发布测试时间是否能大大缩短 不知道你这里的 全量发布测试时间 具体是啥时间？如果是指上线前的测试时间，我理解灰度并不是决定能否大大缩短的核心因素，核心因素应该是对出质量问题的容忍度，或者说可以接受出多大程度的质量问题。测试阶段在模拟环境进行，就是为了把出问题造成的损失降低为零（都是自家人自家数据），而灰度阶段出问题，这个损失并不为零，只是规模相对全量可以小一些。所以如果对质量问题容忍度高，允许一些规模相对不大的质量问题出现，那部分测试内容可以直接挪到灰度发布阶段由线上用户做小白鼠验证，这样是可以缩短测试阶段耗时的（测试内容少了），但如果容忍度不高，那测试内容很难挪到直接在灰度阶段验证，那就很难减少了。

1、每次查询，是基于当前页面的全部 html 来进行查询的。iframe 是比较特殊的标签，在 webdriver 里面一个 iframe 就相当于一个独立的页面，没法跨 iframe 查看里面的 html 内容，所以需要用 switch 语句才能切换 iframe 。

2、你这里面 aa 和 bb 都在同一个 iframe 标签里，所以不需要切换 iframe ，直接查就好了。

不知道楼主除了从怎么做场景模拟的角度外，有没有考虑过分析这类故障出现的原因？

我们以前类似这种测试环境没问题，一到线上大数据量就扛不住的情况，大多是 sql 本身写得不好，没命中索引引起全表查询导致。测试环境数据量少，所以全表查也没多慢。线上有些大表是千万级数据的，全表查一下就 gg 了，不仅接口响应超时，还可能由于占住了连接数，导致数据库很快连接数资源就被用尽，引起所有查库操作卡住的大问题。

如果楼主是类似情况，可以考虑在测试环境做一下所有实际执行 sql 的监控及检测。现在有一些 sql 检测工具是可以直接自动分析出 sql 的执行是不是会引起全表查询的（或者简单点，拿到线上库里分析下执行计划，也可以看出查询数据量情况），只要查询量达到一定量级，有性能风险的，都直接做预警，要求优化后才能上线。印象中 mtsc 大会上唯品会、微众银行也有类似这样的 sql 性能检测实践经验分享。

我们之前的监测预警有点简单暴力，主要是通过定期统计数据库落库数据来做的。

支付相关检测指标大概有：最近 5 分钟的支付发起数、支付成功数、支付失败数。每个指标除了绝对值，还会在曲线图中展示前一天的曲线和今天的曲线。这些指标的数据来源都是实时查询数据库里的数据（为了这个专门弄了个监控系统专用从库），有一个专门的大盘界面可以直接看到所有指标当前值及预警情况。

预警机制：失败数绝对值达到一定数量会直接自动电话预警（这种一般说明是出现严重故障了），成功数/发起数差值百分比达到一定程度会发消息预警。每个预警在大盘里会记录持续时长、跟进人这类信息。

另外，当时因为比较关注线上质量，还弄了一个专门的监控室，招专人排班 7x24 小时值班看大盘指标及预警数据，如果判断认为问题比较严重，人工通知检测指标对应的负责人（大盘系统里每个指标都会登记负责人信息）去排查确认。

从声网的建立初始就有了对可用性的投入，到现在已经成为了内部的标准与体系（见下图）。

这里的图好像没了？

hmm，做第三方支付服务的监测会比较麻烦，建议优先建设好预警机制，再补充主动检测机制。

你说的这两个，实际实施会遇到一些难点：

1、UI 自动化，有可能支付环节的输入密码都会做一些安全限制避免系统自动输入，这个会提高 UI 自动化的成本。

2、第三方提供测试账号这个，测试环境可能还可能提供。线上正式环境，三方支付一般只是中间商，背后他们还会再连接很多级的第三方系统直到银行的系统，基本上不可能存在能打通全链路的测试账号。

这种可以做的，不过这样只校验到自己的系统，可能作用不是特别大。

按我之前的经验，一般支付系统最常见的线上问题是外部第三方渠道的问题（比如他们要维护或者出线上问题导致链路不通，然后需要调整配置把这个渠道的流量比例降低到 0），自家系统出了上线变更或者基础设施负荷太大处理不过来外，相对比较少出问题。