最近碰到很多网络朋友在咨询生产性能故障问题，一般碰到的都是这样提问题的：
老师，我们的生产环境CPU使用率99%，是什么问题？
老师，我压力测试过程中响应时间一直在增大是什么问题？
老师，我们压力测试过程中，网页打开白屏是什么问题？
这个时候变成是我们在协助猜测套问题，引导咨询学生一步一步的说明问题原因，例如是测什么交易啊？是什么环境配置？出现什么状况等？然后在交流讨论过程中，他们才学会慢慢去看问题，有些监控资源命令还不大懂，例如我问了CPU使用情况如何，他们也不多用什么命令去监控，或者深一点的他们说CPU使用率不高，那是例如4C8G，这个时候，我又要套话，具体是4颗CPU 都使用率不高，还是平均使用率不高，或者某一颗CPU使用率100%，其他10%？----当然这个相对而言初学者是不懂怎么看，比较情有可原。
我想说的是：一般做为初学者，一下子公司让你们做压力测试，碰到问题多很正常，工具使用问题是一个大问题，环境资源是什么情况，不了解也是一个问题，测试思路对错也是一个大问题，反正说测就开刀，不管对错，问题出现了，找专业人士，劈头就如上发问，碰到脾气好的会耐心引导，碰到有个性的，直接不鸟你等等这纯属正常，又不认识，各有工作需要忙碌，怎么会无条件支持呢？所以为了减少提问题沟通成本，也减少双方的信息理解误差，建议各位朋友在提问题前，先想清楚，什么时候、什么环境（环境配置）、什么条件下、什么交易、什么类型的系统、什么类型的中间件、什么类型的数据库下、什么场景下等出席什么问题
例如，在测试环境下，压力测试100用户，响应时间很大
生产环境下，LINUX 服务器，MYSQL数据库，8C16G配置下，CPU使用率很高
生产环境下，LINUX服务器，应用服务器，TOMCAT 8.5 ，CPU使用率没办法上去，前端无法访问
测试环境下，接口压力测试，50线程并发压力测试10分钟，压测不上去，8C16G，tomcat8.5 ，CPU使用率很低等问题
当然如果有一定基础的测试人员，可以把错误信息截图，资源使用截图等等发给老师协助分析等这样更容易让双方在问题分析上达成共识，减少沟通成本。
案例如下：
