1、说点真实的一些事情吧，其实我们这些测试虽然深入不了这个性能测试，但是还是知道工具的线程数和真实的并发不能相等。真实情况往往是测试人员对接的是甲方的一些非技术人员，他们也不会理线程数是不是就是并发数~，实际情况就是很多人都是为了出一份报告给到领导或者需要这样一份报告，但是他们又不会很专业的来进行对性能测试深入。大概就是我们按他们的要求和想法进行一次 “性能测试”，给出的结果能让他们认为是正确的就行了。
2、其实这个项目是这样的，我们的服务器都是在内网，然后这个系统是一个 APP，客户端通过外网访问，我们就利用 nginx 做一个代理，客户端外网访问--》我们公司外网地址--》nginx--》--》应用服务器
3、一般都是入口带宽，上传类操作基本为 0 呢
PS：其实自己也想做得更专业~但现实是甲方的人员也只是想糊弄过去让项目能正式上线。

你也有使用这个平台吗，我实在找不到这个平台可以在那里单独维护元素

我觉得也挺那个的吧，假设我现在的场景就是你说的复制每一条用例进行维护，如果我写了 10 条用例，然后前端修改了某个登录元素位置，那我就要把 10 条用例的这个登录元素位置都修改一遍...

不是这样呢，同样的操作就可以用数据驱动，这也是自动化的一个核心思路啊

1、500 用户指的就是 500 线程数，不是在线人数或者 TPS 是 500， 甲方想要的就是 500 个线程数并发一段时间内，在这段时间产生的平均带宽是多少。
2、服务器不放在云（例如：阿里云）上也是云厂商的带宽吗？服务器放在内网，然后是通过 internet（网线，宽带？反正服务器是在内网）进行接收发送数据。
3、有道理啊，那按这个业务场景，我是不是考虑压的是前端页面 + 后台接口产生的流量情况？（因为后台的接口全是返回的是字符串数据格式）
按第三点的场景来说，数据库服务器的数据给到应用服务器是内网上产生的带宽，而应用服务器产生的数据是给到 nginx 服务器，也是内网产生的带宽...，只有 nginx 发送给客户端的数据是要经过外网的一个传输，是不是可以认为 nginx 服务器的产生的带宽就是甲方需要的带宽呢~
PS 太细节了，带宽的基本单位是 b（比特）
网速（速率）的基本单位是 B（字节）
1B=8b（1 字节=8 比特）
现在我有 50000KB/S，即带宽为（50000/1024）MB/S * 8= 390M b/s

，这方面知识比较薄弱，不知道是合起来算，还是说要找到对应的服务器瓶颈再进行换算。

看前端开发人员开发素养，因为有时候不加一些标签对实现并没太大影响。

卧槽，喷神光临，受宠若惊！

对呢，我不是说这个问题是 SQL 注入，我只是想表达如果限制了长度就不会出现这种 “数据过度暴露” 的安全问题~

之前遇见过的一些安全问题，虽然问题是不太大，但确实是一个安全隐患。接口要求传参数，zbdw（int）,zbdh（int）。后传入参数 zbdw=njdhs>'',zbdh='1',发送请求后，接口返回的数据把对应的实例、表，字段都暴露

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

但是开发人员说用另外的一种方式也能有效的解决 SQL 注入的问题，不需要在接口上对每个传参做校验。经过产品、开发和测试人员的会议沟通后我们达成了一点意见，就是重要的功能或者有必要的字段就必须做长度校验，类型校验的话在接口实现时候定义变量和数据库设计保持一致。但是问题又来了，那些接口需要我们就比较难定义，或者说什么样的接口是一定要做长度校验的呢？（既然开发人员也说有另外的方法对安全问题进行拦截，我觉得我当时考虑的问题就已经解决了）

第二点，我们采用也是 springboot 架构。也和你说的一样，当时开发人员人为写死的话不够灵活，如果数据库字段改变后需要修改写死的地方~

看了楼上的一位同学的说法~，我也在考虑我这样的用例设计是不是真的是过度设计了~。纠结…

你的意思是，这些长度、类型我都要进行测试，但是如果程序上不出大问题就允以放行是吗

哈哈，是一种工作方式。但是我是想搞懂这些东西有没有必要做，不搞懂可能对以后的工作效率有一定的影响。

嗯嗯，应该和产品、开发人员进行会议讨论，但是团队还是有一些模糊的理解。比如我们都约定好，只对一些有业务修改的接口做长度的校验限制，但是那些接口需要我们就比较难定义，或者说什么样的接口是一定要做长度校验的呢？（因为我之前的认为都是所有接口都是必须做长度校验）

当然在前端/客户端做校验是必须的，但我这边是考虑到接口安全性的问题，担心如果不接后端的验证会后比较多的安全问题。

en~,我先来解析一下第三点，这里并不是要求开发人员写代码去到数据库找到对应的字段来进行校验，其实在做数据库设计的时候设计人员就把对应的数据字段对应的长度和类型设计好，所以我的意思是要求开发人员实现接口的时候，对应的数据类型和长度要和数据库设计的保持一致。

第二点的话，我和开发人员沟通后，他们也说是采用 validator 做简单的校验，但是如果做长度校验的话很多地方都会写死。这个他们当时也是认为太不灵活，如果用此方法，后面修改对应的字段长度的话会涉及很多地方的修改。

这样的吗，因为我觉得做这两类校验对接口的安全方面有较大的保障~

但我觉得接口层面做了这两个校验会把很大一部分的安全问题都拦截了啊，所以我觉得是有必要的，当然从功能层面上考虑确实是增加了开发人员的工作量~

这句话太偏太大了，给到任何角色这句话都是适用的。我还是认为测试人员做好自己的本职工作，像楼主提到的无所谓黑测白测，能保证上线阶段不出现问题就是好测试，至于如何提高系统的测试质量，应该是由测试人员的质量占大部分因素。系统的质量可以说是测试人员细心和测试技术决定。

受益良好

你是用 GUI 模式进行并发监控的吗，有没可能是 GUI 模式在大并发的情况下会出现描绘聚合和汇总图时候出现的异常。可以采用非 GUI 模式进行压测，压出报错后再把结果验证一下，聚合图和 TPS 图是否能对得上

昨天做了一次测试，绕过了 NGINX 只对一台应用服务器进行压测，持续进行了 2 小时候后还是有 404 和 500 的一个报错。监控相关资源，应用服务器的资源在 cpu40% 左右,io 2%,mem20%,数据库 cpu60% 左右,io 0%,mem5%

ip 访问限制是指什么吗？压力机只有一台，应用服务器有 2 台（其中一台应用和 nginx 放一起），数据库一台。应用服务都正常运行，应用服务日志是没有报错的（tomcat 日志），所以我就一直怀疑是不是服务器的问题，但不好定位是资源问题还是像 3 楼、4 楼同学所说的网关还是 ip 出现问题，我该如何排查是否是这两个问题导致的呢

网关配置？请问一下怎么定位是不是这个问题呢