关于性能测试的三个观念
最近和几个同事一起组织了一门ETP（Engineer Training Program）的课程，叫做Advanced Performance Testing。叫Advanced不是因为多么高深，而是因为这是一个多次的系列课程，而且里面结合了大量的实例和实践的经验，不希望只是泛泛的介绍。当然，这样叫还是会觉得有些大言不惭的，毕竟做性能测试久了，知道深浅。
最近在Weinberg（对，还是他，可见我读书多么慢）的《becoming a technical leader》书中看到一段话，提到他对于培训的一点心得，他对于成功与否的判断标准是受众在其后对于这个领域的关注度是提高了还是下降了。我也希望在我们这个系列的课程结束之后，大家对于这一块有了更多的认识和了解，也愿意去更深入的学习和实践。总之，希望会有一些帮助。
昨晚上完第一次overview的课后坐地铁回家，碰到一位来上课的同事，他对于我在课上提到的和性能测试相关的几个观念有一些印象。看来，简洁的归纳是有助于传播的，可能比一堆的checklist更容易让人记住和获取一些新的想法。这里也整理一下发出来供大家参考。
1. 精确和模糊
这是困扰很多性能测试人员的一个问题。因为基本上性能测试都需要得到一个精确的量化的结果，比如：
a. 系统可以支持10,000个并发连接
b. 每秒钟可以处理80封电子邮件
c. 可以支持3000人同时浏览网页
......
类似的数据可能出现在需求中，也可能出现在测试的结果里面。使得我们认为，相比功能测试或者稳定性测试而言，性能测试是一种要求精确的测试。
但是，真的是这样吗？ 试着回答下面这个问题：
一辆汽车开100公里需要多少汽油？
直觉上你会说不同的车不一样，对，这是好的开始，那好，就确定是某一台确定的车，不仅是型号，就是门口的某一台。
嗯，怎么样？开始犯难了吧，特别是如果你是一个严谨的人。因为你的大脑开始快速列出下列条件：
1. 坐几个人，带多重的物品？
2. 路况如何，是高速还是拥挤的市区？
3. 天气如何，温度如何，要开空调吗？
4. 驾驶习惯是怎样的？
......
还有很多，越有经验的人可以列出越多，想想F1调整一下尾翼的角度就可以改变下压力之类的事情。天哪，我要开一个长长的清单。
到现在，你还觉得性能测试是一个精确的测试吗？也许问题出在有太多的前置条件，它们或大或小的影响着测试的结果。
所以呢，我们应该怎么办？这是对很多新参与性能测试的人来说最难的问题，而不是那些看起来复杂的工具。大家常会问：我怎么知道该用什么样的sample？
关于这些前置条件，或者我们称之为假设（assumption），我把一些做法归为三个阶段。
Stage 1：做了假设却不知道自己做了假设
比如前面提到的那个油耗的问题，有人的做法是我就开100公里看看，得出来是多少就是多少，比如9L。然后我就告诉别人这个车的100公里油耗就是9L。
问题是这样的结果对你是OK，因为你有切身的体验，知道遇到的状况，可是测试的报告是要给别人，甚至你都无法直接面对或者沟通的人参考。这就会很容易误导别人，即便这不是你的本意，而且你自己也确定你是真实的记录了结果。这里的问题在于你并不清楚自己所做的假设，因为我们一直在做这样的假设。
Stage 2：做了过多的假设
“当路面平坦，无任何红绿灯，风速5km/h, 只有一名70kg的乘客，时速稳定在70km/h, 良好驾驶习惯，... ，的情况下， 油耗是7.1 L/100 km.”
这样可能很严谨，但是对你的报告的读者而言，这样的数据有多大意义，因为他们没有你那么幸运，有这么良好的环境。
Stage 3：做必要和合理的假设。
生活有时候是需要一些妥协和折衷，如果这些折衷是必要的和合理的。因为跳出来看，我们的测试需要提供有价值的信息，所以为了这样有价值的信息，做出必要的和合理的假设是可以接受的。
好吧，也许这不是你想要的答案，但它是我目前给自己的解释，和安慰。
2. 宏观和微观
这也是一个有趣的对立。在做性能测试，特别是整个产品的性能测试的时候，我们看到的是产品的核心功能和主要的大的功能模块，比如数据库、web服务器、核心的daemon等等。在脑海里，我们有一个架构图，哪怕你没有把它画出来。所以有时候，我们会想，性能测试对于产品的视角是宏观的，看大的组件，而不是具体的细节的东西。
果真是如此吗？看看下面的例子：
1. 把daemon的log级别改为debug （log_level从2改到5）之后，性能下降了差不多一半。
2. 关掉一个cache选项
3. 打开keepalive选项
4. 打开DNS反向查询
......
上面都是些细枝末节的设置，一个配置项而已，藏在DB的某张表或者某个ini里面。但是改变之后，得到的性能结果可能大不相同。这些都是我曾遇到过的例子，也是让我改变看法的一些经历。
Scott Barber（本人非常尊敬的性能测试方面的专家）在他的一篇文章里讨论了这个话题。
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 detail, 对，就是这个term。其实不光是这里说的测试，工作和生活中的很多事情都是一样，不是要不要关心细节，而是它是否critical。
那么，怎么区分一个细节是不是critical或者怎样找到critical的detail呢？
嗯...，这是个好问题，不过不好意思这个不是这里要讨论的范畴。
3. 项目和任务
性能测试本身肯定是一个任务，无论对于被安排去做这个的人，或者安排的人。但是它有时候也像一个项目，对于去做这件事情的人。为什么呢？
首先你需要和很多的人打交道。
产品经理或者客户：获取需求，设定目标。
QA manager/lead：讨论resource和schedule。包括需要的机器，环境，软件，还有整个计划。
开发人员：查找问题和调优等。
功能测试的owner： 性能测试人员可能不是什么功能都很懂。
Admin：Lab，网络，DB等等
其次，它是一个周期很长，跨度很大的工作。特别是对于一个比较大的产品而言。你需要准备详细的测试设计，包括目标、范围、可能的方法，以及上面提到的资源和时间计划；然后邀请很多人来评审这个计划；接下来要准备工具、环境和测试数据。然后是执行，记录分析结果。如果有问题还要反复的调整和regression。最后要整理报告，回答疑问。
说它是一个项目一来是因为上面的原因导致工作的复杂性，还有一些原因是因为性能测试带有评测的性质，因为你是在试图去度量、衡量或者评价一个东西，而且带有比较绝对的结果。这样导致性能测试不可避免的要引入一些权威性的问题，尽管你并不一定期望这样。这使得很多的东西就像一个其他项目一样，有期望管理和良好的外部沟通和协调的需要。所以有时候，更愿意把它作为一个小的项目来看待，这样或许可以做得更全面。