1
思考题
今天的内容有点多，我提几个思考题，你就当是对文章的回顾吧。你觉得企业选择性能工具应该考虑哪些方面呢？以及性能测试工具中是否必须做监控呢？
第一个问题：
大概会考虑怎么几个方面：
- 学习成本：对人员的水平要求，培训时间成本等；
- 脚本编写：能否录制测试脚本，是否支持GUI操作等；
- 安装部署成本：是否支持一键安装，是否支持docker等；
- 是否免费：开源工具一般都是免费的；但是很多收费工具也的确物有所值；
- 是否支持多协议：比如是否支持 HTTP 协议、RPC 协议等等
- 测试场景：是否有链路、场景编排管理，支持支持将请求编排成业务场景，即常见的一串联场景；
- 流量控制：支持纵向的，上下游链路的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向的；
- 压力控制：指压测时并发用户数、 TPS 的控制等；
- 数据驱动：大量的测试数据的参数化；
- 分布式支持：支持压力机集群；
- 测试报告：压测结果是否能够图形化展示，提供美观且丰富的测试报告；
- 二次开发的成本：由于时间或人力关系，也需要考虑二次开发成本；
- 性能开销：执行机开销、软件可靠性、执行效率、业务处理能力等。
....
第二个问题：
我觉得一个好的监控系统大概需要包括以下几个方面：
- 全栈系统监控是前提；
- 关注于整体应用的 SLA：主要从为用户服务的 API 来监控整个系统；
- 关联指标聚合：把有关联的系统及其指标聚合展示。主要是三层系统数据：基础层、平台中间件层和应用层。并提供一个全局的系统运行数据大盘，帮助快速找到系统瓶颈。
- 快速故障定位：快速定位问题需要对整个分布式系统做一个用户请求跟踪的 trace。
只有做到了上述的这些关键点才能是一个好的监控系统，而显然目前的测试工具监控是不满足的。
另外测试工具本身在做监控也有其局限性，如 jmeter 在压测量较大的情况下回传测试结果 Master 节点会成为容易成为瓶颈。
作者回复: 嗯，你说的很对。
我竟没有啥子可以补充的。
要测试一个在线运行的网站性能，应该使用什工具比较好？设置的被测网站的IP地址可以是公网IP吗？
作者回复:
使用什么工具取决于什么样的工具最适合应用场景。如果是HTTP协议的，那有很多工具都适用。没有谁比谁更好，只有哪个应用在团队中成本最低。
关于压力工具我从来不纠结，就算自己写一个多线程工具也无所谓，只要能让我看到TPS、响应时间、错误率之类的数据就可以。
从技术上说，不管是公网IP、内网IP，对性能测试的过程来说都无所谓，只要路由可达就可以测试。
只是用公网IP要考虑出口流量，以及架构上的各种网络设备，像WAF、SLB、广域网设备等。并且如果是按流量付费的带宽，还要先计算下费用。还有客户端如果也在公网上，还要考虑客户端的出口带宽。但是这些都和性能测试技术本身无关。
老师您好，“比如说压力策略，应该用一秒 Ramp up 10 个用户，还是 20 个用户，还是 100 个用户？这应该怎么判断呢？”可否回答一下，最近正在纠结这个问题，谢谢！
作者回复: 等你看到场景设计的那篇的时候，估计你就不会有这个疑问了
现在在公司做的还是不太顺利，概念不理解，大家对并发的不理解，这包括开发，产品，项目，部分运维可以理解；还有就是无理要求要求8000并发，这个怎么跟他们解释都无用，一说就是客户要求的，这8000并发发包出去就几g的流量了，真不明白他们怎么想的，这做技术的人一点基础都没有，真的很难工作
作者回复:
要是你职位高，可以强势一点沟通。如果从历史数据中算到并发度并不高。（就是拿当前的用户和业务的TPS做比对就可以知道并发度。）那完全可以算得出来。
现在不懂技术的人说的并发，大部分是说的在线。之前我算过一个要支持1000万基础用户（也就是数据库里总共只有1000万用户），再计算到日活，再计算到时、分、秒，才需要200TPS。
老师请教一个问题。关于事物的定义，假如有一个兑奖的活动，进去活动页面会请求三个接口，一个个人积分接口，一个是任务列表接口，还有一个是兑奖列表接口。在页面点击兑奖按钮会去请求兑奖接口，兑奖成功页面会去调用用户接口刷新用户当前积分。这样的情况应该怎么去定义事物？
作者回复:
这就是之前的一个文中所写的。
事务的定义取决于测试的目的：
- 如果你想测试的是单个接口的容量，那显然，一个接口一个事务，并且都是直接连接口就行了。但是要注意的是，其实在测试兑奖接口的时候，后面的几个接口也都会调到，所以这时会把后面几个接口都压了。这时，如果你的目标只是测试兑奖接口本身，并不想测试关联的其他接口，那就mock掉。
2. 如果你要测试的兑奖的这个流程，那显然是从兑奖接口进去。事务定义到兑奖整个流程上。
高老师，推荐几款监控Java语言接口和方法执行时间的工具，比响应时间细分到Java某个工程的jar包，我怎么监控这个jar包里的接口执行时间，方法执行时间，还有算法执行效率，等等
作者回复:
这有很多呀。像jvisualvm/jmc/arthus/btrace......。开源免费。
高老师，能否推荐一些性能测试这方面的书籍？
作者回复: 这个就比较麻烦了。除了写性能测试工具之外，性能测试基本上没有自己的书籍。
但是写工具也不算是完整的性能测试。
如果你要看的话，我建议你这样开。
OS、DB、存储、语言（java、go、python)、架构等各找一本性能相关的书看。比如说linux性能优化、java性能优化、mysql性能优化，这类的书。
第一个问题:
1、常规工具看测试场景需求:比如一般测试接口性能和找系统瓶颈，用jmeter，轻量开源可自定义扩展插件。如果业务整体场景流程基准测试并有要求输出完整报告，一般选loadrunner，毕竟图表好看，界面脚本录制方便，对局方（甲方认可工具）有说服力。
2、云平台测试选择（自建还是购买):
2.1权衡场景，公司是否业务需求到这量级，不为测试而测试。
2.2短期长期思考:短期或没成熟测试团队，可购买过渡，长期推荐自建，完成技术栈积累。
第二个问题:
推荐监控用专业监控去处理，避免监控与测试互相干扰，尤其流量方面。但是比如内部小流量业务平台，没完整监控体系，可以直接使用工具集成的~
作者回复: 理解的完全正确。
第一个问题：
企业选择性能测试工具无外乎两种策略，一是性价比优先，花最少的钱最快地完成最多最需要完成的任务，比如租用云压测平台，属于头痛医头，脚疼医脚的临时策略，小公司、发展初期公司等常采用的策略，可以快准稳完成压力测试。二是结合长期发展目标，分阶段规划测试工具购买及测试人员培养，甚至自己开发测试工具，积累并形成自己的压测能力。这个策略与公司测试人员以及测试团队能力也有很大的相关性。其实老师已经讲得很清楚了。
第二个问题，我个人认为不应该在测试工具中做监控。现在处于一个分工很细的世界，术业有专攻，专业人做专业事，一来可以保持工具的简洁，二来可以保持工具的通用性，增加使用的灵活性。当然这对做性能测试的人的能力要求就更高了。不过工作的乐趣不就在于此吗？
作者回复: 理解的非常到位。完全领会了精髓。
第一个问题：
首先需要根据企业的业务场景、目标选择合适的工具；
其次需要考虑工具的使用成本：资金成本，学习成本，人员成本，适用范围等；
然后还要看看是不是符合企业未来的发展方向，比如如果有需要，是否方便向后兼容，做成一个性能平台......
第二个问题：
对这一点没有太好的想法，只能说根据企业情况来吧，有时候你自己知道搭建全栈的监控，好处很多，但是现实往往不允许，，，这个真的很无奈.
作者回复: 面对现实，分析现实，改变现实，超脱现实。
我们单位基本用jemter来压测，主要的测试为接口级测试，接口基本为数据给出接口，属于查询类事务
作者回复: 测试目标如果明确，怎么实现都是阔以滴。
