本文主要是介绍性能测试新手常犯错误总结（七）：你需要调优么，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
测试人员喜欢在得到某个达不到预期的性能结果后，进行一下“调优”。
PM有时也会布置任务，测试完成后“调一个优”。
一些人貌似有了这种观念：调优才使性能测试有意义、性能测试的目的就是调优、做调优才能显出测试人员的水平……
随着经验的增长和对性能更深入的认识，我越来越体会到调优是一个复杂的过程，不是动动嘴、改俩个参数这么简单，只有通过科学的方法和扎实的技能才能做好，以至于我使用这个词的频率越来越低，因为不敢轻易说出口……
在你再一次调优之前，先考虑以下几个问题：
为什么需要调优
如果问起这个问题，得到的回答通常是“因为性能不够好”，那么接下来我会问性能不好体现在哪里？你要调什么？希望得到什么结果？
如果你不能足够准确的回答第一个“体现在哪里”的问题，后两个也一定没有答案，所谓的调优自然也无从谈起。而这第一个问题的答案其实也就是定位的过程。
举一个小例子。如果我已经发现数据库较慢，通过进一步监控又发现了一个cache的spinlock contention这个指标超过了正常的范围。那么我会猜测可能是这块缓存的争用导致了数据库的运行状况变差，针对这个现象我知道可以通过将cache分区来减少争用，改变配置后再重新测试和监控，这就可以算是一次调优的尝试。
但如果你只停留在数据库慢的这个层面上，又怎么能进行调优呢？
所以，需要调优的一个前提是“定位到问题”或者“发现了瓶颈”。
又有人说了，没有问题为什么不能调优？没有问题，我们可以让系统变得更好！
但是，所谓的“更好”如何衡量？“好”到什么程度时不需要继续“好”了呢？
请记住，瓶颈永远存在，消灭了一个，就必然会引入另一个。
调优的目标也不是“没有瓶颈”，而是系统在其所承受的压力下，性能表现足够好，那就够了！
“足够好”其实也就是没有问题。
调优调什么
理解了上面的内容，这个问题的答案就很明显，调优必然是针对具体的问题或瓶颈。
而问题和瓶颈，指的是“性能不好”这个现象的直接原因，而不是那些不痛不痒的其他因素。
好比奥拓比奥迪跑得慢，最主要的问题在于发动机（不懂车，随便一说），而不是奥拓车的外型不够流线、轮胎抓地不够好……
如果把精力放在改善外型、轮胎这些方面上，确实会让奥拓变得更“快”，但是从原问题（比奥迪慢）上来看，这都是没有意义的。
至于如何准确的定位出问题，针对问题又如何下手，这就是技术能力，只能依靠不断的学习、长期的积累了。
不过依然存在一些比较科学的工作方法，可以让你尽快的抓住重点。如在系统运行正常时采集一份足够完整的性能指标作为基准，当出现状况时再次采集一份相同的指标，对比其中的差异，从差异处入手。
经常见到这种人，一听到数据库慢，直接加大内存分配、加缓存、加连接数、加大各种资源配置……典型的胡乱“调优”。
调优的层次
同一个问题，可能可以从多个方面进行处理。
一个慢SQL，优化的方式可能是加个索引、绑定缓存、改写SQL、表分区、甚至是升级硬件。
资源争用问题，既可以从配置层面进行优化、减小争用发生的机率，又可以从程序的实现方式上做改变、从源头上避免争用。
假设多种处理方式，都可以满足期望，那么应该从哪个层面下手呢？
这就需要考虑到工作量、效果、隐患等多种因素，当然也不排除几种优化共同作用。
调优有效么
这是一个工作方法是否科学的问题。
每一次试验，都需要能够验证是否有效。有效的保留，无效的则复原。
除了对原问题的验证，还必须确认对其他部分是否产生了副作用。理论上这就需要在每一次调优尝试后，进行一次足够全面的复测。
否则，很容易出现“拆东墙补西墙”的问题。
记住以下几个要点：
● 每次只改变一处。
● 每次改变后进行复测。有效的保留，无效的复原。
● 不断的迭代，直到达到预期。
只有真正理解调优的目的，并按照科学的方法行动，你的努力才会体现出价值。
这篇关于性能测试新手常犯错误总结（七）：你需要调优么的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
