本文讨论了软件优化中测试人员的价值，强调了客户端优化的必要性，并提出优化应被视为持续的过程，而非一次性任务。文章还指出，优化不仅涉及代码层面的改进，还需要考虑性能指标的量化和成本效益，以及避免过度优化。通过分析优化的不同方面，旨在为开发者和测试者提供全面的优化策略。
1．优化是开发的事，测试是测试员的事
很多时候，我们会认为优化仅仅是开发需要做的事，与测试人员无关。的确开发人员可以通过一些调优工具进行程序优化工程，但测试人员的作用仍是不可替代的。测试人员更能从客户的角度来看待问题，同时不必关心程序的实现方式，往往更能找出软件的热点问题，帮助提高软件系统的体验值。
2．优化主要是找出代码热点，修改代码提高响应
优化不仅仅是修改代码，而应该从整体上来考虑出一个良好的优化方案，包括程序接口、结构等。优化的落脚点最终还是在于找到热点代码，改进代码段，以期得到大大性能提升。
3．用降低服务器压力方式来提高用户访问速度
我们通常理解认为降低服务器的压力可以提高用户的访问速度，并将优化的重点投入到降低服务端的压力。在某种程度上讲是有道理的。但我们同时不能忽略的是用户的操作习惯，不同用户对同一功能要求的差异会带来不同的体验要求。降低服务器压力仅仅优化的一个方面。
由于感受软件性能的主体是人，不同的人对同样的软件有不同的主观感受。所以软件系统在不同的应用环境中，包括软件运行平台、网络环境等的差异，会表现出不同的软件性能。所以我们在做性能测试时需要深入分析不同应用环境下的性能要求和数据细节，力真去模拟相似的测试环境。
由于软件实际应用环境非常复杂，通过在试验室内无法真正有效的去模拟出这些环境，所以还需要去观察收集典型的实际应用环境。
4．客户端不需要优化，优化主要集中在服务器端
优化的重心在服务器端是可以理解的，但同时不能忽略的是客户端的优化。有时客户端的优化，比如优化客户端的算法，改变一下客户端访问服务端的方式/连接调用方式，会大大促进软件整体性能，同时比优化服务器端更有效。
5．把优化当成项目来做
优化并不是一次性的过程，好的写作方式和良好的结构设计都会对软件系统的性能起到帮助作用。在此基础上，我们考虑系统调优时，应该随着项目的发展积累来确定优化。有时可以仅仅错助于一些调化工具来进行，有时则需要制定一个详细的调化计划/目标来完成。
6．缺少性能量化指标和测试原则
很多时候，我们对代码优化常常是开发利用一个监控工具来分析调优，开发又通常关注于程序的CPU和Memory利用率上，缺少了一些可量化的指标和调优原则。性能指标的量化需要对软件功能或硬件主要指标进行可计算或可对比量化，比如一个用户请求需要的开销，包括网络，应用服务器，中间件，数据库等开销。硬件指标还包括软件运行所采用的硬件，如CPU，内存，硬盘，网络带宽等。没有这些基础性数据，准确的系统性能评估是无法完成的。
7．过度优化
实际过程中，我们还需要考虑软件优化的成本，避免过度优化。在优化时，我们要多考虑一下采用的优化方案：给系统带来了什么变化？有没有带来潜在的问题? 有没有使系统更趋于复杂？有没有让维护更困难？是不是解决大部分场景的要求？这些需要建立一个合理的优化目标，采用有效的优化方案。
附：
不要去计较一些小的效率上的得失, 在97%的情况下, 不成熟的优化是一切问题的根源
扫一扫
26
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
