• 朱兆辉

  2017-03-14 22:24:14

  0 0

  测试不可能跟真实一样，贴近即可。重要的是测试结果要有意义，不要压力不够，也不要压力过度超过了最高的性能要求。通常测试麻烦在覆盖足够多种用例，还有用例之间比例恰当。加压力没它复杂，跟据需要増加就行了。有时候要设计一些特殊场景比如缓存未加载或突然失效，看看这时候能不能抗住期望的压力。不行的话再想想如何避免这样场景或改善这样场景下的抗压能力。

• 张继平

  2017-03-14 22:24:00

  0 0

  具体改如何设计和实施整个过程呢？这里划分了几个环节：［1］场景确定与压测脚本准备用户在注册时需要提交用户的姓名、手机号和手机验证码，之后提交申请即可，所以实际上用户申请注册只调用了一个API接口来完成（接口地址：http://www.此处马赛克.com/api_11.php?m=User

• 钟丽华

  2017-03-14 22:23:34

  0 0

  测试的思路一般来说，对于活动中的功能节点，测试过程中通常关注两点：1、单接口压测，提前暴露核心模块的问题2、多接口架构问题，场景压测尽量模拟真实用户行为，使得压测结果更有说服力测试的执行1、单接口压测——步步为营，逐渐迭代2、多接口压测——真实模拟，定位问题

• 李文海

  2017-03-14 22:22:33

  0 0

  性能测试模拟真实负载是比较困难的。性能测试与真实环境的对比，通常有这样一些点：1.客户端展现。如果是Web应用，客户端使用浏览器展现的，则一些的压力测试工具都不具备展现的功能，也就是说，只是模拟发送http请求到接收请求，而浏览器对html内容进行渲染的时间，是无法模拟的，这很可能是真实环境体验现测试结果不相同的地方。客户端展现要与真实环境相同，必须单独进行前端性能的分析。2.网络速率。性能测试时通常在局域网环境中，而真实的网络用户来自于全国甚至世界各地，其网络情况不一致，而且有很大的偶然性。除了对压测工具所在的机器进行一些网络限速之外，很难完全模拟到真实的网络负载情况。3.软硬件配置。软件配置比较容易做到与真实环境一致，但硬件配置通常比较难做到。像线上使用的一些负载均衡机器或者路由设备比较昂贵，不可能在测试环境采用完全一样的拓扑和集群，当然这些对测试结果影响通常可以分析到，不会有很大偏差，但这是一个无法完全与线上保持相同的点。4.数据分布。数据分布要做到与线上一致有3个难点，1是对新应用而言，根本没有线上数据，因此无从模拟，只能手动造数据，所以无法跟线上一致；2是即使是老的功能，线上数据因为商业机密等原因也未必能直接拿来作为测试数据；3是用户的访问路径，这点很难与线上做到一致。功能测试尚不能覆盖掉所有的用户操作路径，何况性能测试？以上四点，都是问题。因此性能测试很多情况下只能作为参考，用来发现明显的性能问题。如果要做到100的准确，还是要做线上的即时监控才行。

回答请先登录