软件性能测试的本质(2)

　　这样可能很严谨，但是对你的报告的读者而言，这样的数据有多大意义，因为他们没有你这么幸运，有这么良好的环境。

　　三：做必要和合理的假设

　　生活有时候是需要一些妥协和折衷，如果这些折衷是必要的和合理的。因为跳出来看，我们的测试需要提供有价值的信息，所以为了这样有价值的信息，做出必要和合理的假设是可以接受的。

　　好吧，也许这不是你想要的答案，但它是我目前给自己的解释和安慰。

　　性能测试环境需要在严格独立监控下管理，尽量保持与真实生产环境的一致性能。

　　“精确”的测试数据

　　对于一个严谨的测试员，我们的测试结果的描述也相当精确，如：用户每个用户的访问时间为2.8729秒，10分钟系统处理请求8634个。我以前一直认为，只要我把测试环境描述的很详细，我的测试结果就是精确的。

　　实际上功能测试很容易得到测试结果，而性能测试很难得到精确的量化结果，我买了一辆汽车，开车去上班，去时车的各个功能非常正常，回来的时候车的功能也非常正常。我们通过功能测试很容易得出，这个车的功能没有问题。

　　那么性能测试呢?再来看耗油情况，我去时上耗油3.29升，回来时耗油3.42升，同样的一条路，同样的人开同样的车，那么是不一样的耗油结果?如果我再试一遍，可能情况还会有变化。所以，我们很难得到精确的数据，但是这丝毫不影响我们测试结果的参考价值。

　　“宏观/围观”的性能测试

　　这也是一个有趣的对立。在做性能测试，特别是整个产品的性能测试的时候，我们看到的是产品的核心功能和主要的大的功能模块，比如数据库、web服务器、核心的daemon等等。在脑海里，我们有一个架构图，哪怕你没有把它画出来。所以有时候，我们会想，性能测试对于产品的视角是宏观的，看大的组件，而不是具体的细节的东西。果真是如此吗?看看下面的例子：

　　1. 把daemon的log级别改为debug (log_level从2改到5)之后，性能下降了差不多一半。

　　2. 关掉一个cache选项

　　3. 打开keepalive选项

　　4. 打开DNS反向查询

　　.....

　　上面都是些细枝末节的设置，一个配置项而已，藏在DB的某张表或者某个ini里面。但是改变之后，得到的性能结果可能大不相同。这些都是否改变了我们以往的看法。

　　Scott Barber(性能测试方面的专家)在他的一篇文章里讨论了这个话题。

　　“Macro- and Micro-tests, macro strategies and micro-plans, macro-level application usage and micro-level usage implementation details, macro-level result summaries for executives and micro-level test results for developers... it sounds like a day in the life of a performance tester to me.”

　　摘自他为Software Test & Performance杂志写的一个系列文章，叫做Peak Performance，其中的2006年9月的一期，文章名是 Macro to Micro And Back Again Macro to Micro And Back Again，嗯，很好的诠释。

　　亚里士多德说世上的道理不是被讲一遍两遍而是成千上万遍，是的，因为Weinberg也讲了一遍，就在上面提到的那本书里面。请原谅我再次引用他的话，粉丝嘛。“Although it's necessary to have an overview of the problem, the big picture often turns on one critical detail.”

　　critical detail, 对，就是这个term。其实不光是这里说的测试，工作和生活中的很多事情都是一样，不是要不要关心细节，而是它是否critical。

　　那么，怎么区分一个细节是不是critical或者怎样找到critical的detail呢?

　　嗯...，这是个好问题，不过不好意思这个不是这里要讨论的范畴。

　　所以，你还认为性能测试只是学习如何使用性能工具么?它需要一个长期的个技术的积累，我们的路还很长。也许，我讲的不够本质，但性能测试这个领域，看到太多的新手在整天问工具的使用，学会了工具的使用就大言“我会(精通)性能测试!”。太多的公司叫新手的做性能测试，环境神马的也不提供，你找个工具对软件加压一下吧!哎~!这未免是太贬低“软件性能测试”了。

原文转自：http://www.uml.org.cn/Test/201301104.asp