StarWest 2010 - Day 2 - 性能测试

I choose this tutorial for day 2.
TF - Software Performance Testing, by Dale Perry.

这个和第一天James Bach的Critical Thinking for Tester完全不是一样的菜，不过还算是明智的决定。害怕选错，因为是一整天，1/4的会议哦。

James 的session激烈精彩，催人思考。Dale的session则是有条不紊，波澜不惊。Dale现在本身就在SQE（STAR会议的组织者），算是比较 专职的培训讲师，所以这个session也和专门的培训一样系统有条理，但是不会有那么多spark，不过很多point还是不错，另外也是很好的梳理。
Dale大概50多岁，在业界工作三十年，以前做programmer，后来在IBM做过IT service方面的工作，然后来了SQE。经验是很丰富的，后面我有机会逮到Dale，单纯聊了快三十分钟，稍后再附上专访的内容。  ：）

刚 开始被Dale打击了，他问听的人有多少work for perf testing for more than 2 years, 有不少举手的，including me。然后他问你们这些人来听干什么，因为这个只是初级的课程。真想逃跑啊，不过翻了下handouts，觉得有货，淡定。

核心的内容是 讲了性能测试的四个阶段的主要工作和注意的问题，包括Plannin, preparation, execution和reporting。下面说一些我觉得比较有启发的东西。如果你对性能测试有兴趣，请找我拿slides，有PDF版，内容很全面， 和他讲的一样，而是使V5.0，呵呵。

关于上面的四个阶段，Dale的看法是应该放80%以上的时间在Planning和 preparation。如果这两个阶段做得够扎实，后面execution和reporting是piece of cake。个人部分同意，主要是前面的部分确实很重要，而且常被轻视。但是我觉得后面的execution和reporting也是比较重要，也有很多要 注意的地方，但是他的课程里面这两部分相当简略。

1. Performance testing is a team effort.
这 是很好的强调，特别是对于刚开始做性能测试的人。确实需要involve很多的stakeholders，比如DBA, sys admin, network admin, dev, management team, marketing, and also user if possible.
这set goal, plan, preparation和execution的阶段确实需要involve这些人。否则可能遇到问题，比如别人无法buy-in你的结果，甚至 challenge，或者是错误的测试，比如测DB很大的系统，但是DBA没有involve，很可能出问题。

2. 性能测试通常开始得太晚
这大概是常遇到的问题。我觉得他讲的有一个point很不错，性能测试，特别是早期的性能测试，除了去验证或者和目标比较之外，更直接的是avoid surprise。是的，特别是在做后续版本的产品的时候，大家的期望就是和上一版比没有surprise。

3. Performance goal and Business goal
Performance 的goal 可能是诸如测试每秒事务处理能力，吞吐量，相应时间和resource usage等等。而business的goal则是客户满意度，客户的使用效率，扩大市场占有率，time to market，less support call等。
两者不一样，但是也有关联。如果perf的goal达成了，并不代表business会成功，但是达不成，则 business很可能出问题。所以如何将两者link起来就很重要，对于对于management team报告的时候，需要转化成business相关的point。

4. 关于生产环境和测试环境
can the test lab reasonably represent the actual system?
是个好问题，测试本质上就是在模拟。问题是是否真实有价值，而不至于误导。
他讲到几个point，觉得之前思考得不够。
a. 环境和配置。product有的load balancer，firewall，proxy等等在lab有吗？网络的配置呢？
b. 通常lab的设备相比production要弱，特别是大型的项目，如果保证这种缩小是合理和有意义的。缩小多少倍比较合适，有些经验值，认为大于5 maybe比较合适。
c. 缩小的balance的问题。意思是说是不是等比的缩放。比如production有多台机器，每个的配置都不同的时候，如果在lab 缩放的时候硬件的比例不一致，会导致看到的bottleneck可能完全不一样。嗯，觉得这个是很好的point。缩放其实是很难的事情，比如还有关于 DB index的例子，多个表的index和一个表的就不太一样。

5. 关于scalability的问题。
我们功能常称之为sizing，就是在不同等级的硬件上的性能，也保护一些推测。
to be careful, 推测是已经很危险的事情。因为有很多东西并不是可以等比缩放的，这个很容易理解，比如CPU更强了，但是disk更大并没有帮助，如果是IO密集型。

6. not a number, but a range.
这 一点是我印象比较深刻的一点。通常我们在做性能测试的时候给出的是一个确定的值，当然是在很多的precondition下面给出的。其实我最近也意识 到，这样会有些问题，特别是需要compare的时候。因为绝对的数字就会有绝对的结果，而通常测试是有误差的，而且环境也不可能完全一样，这样测试结果 可能会产生误导。而如果用一个range，就会更合理。不错，学到了。

7. 关于sampling
这个always是performance testing中很key的一个部分，因为它直接影响到测出的数据。如果有在线的系统，可以采集实际的数据，这样很好，但是有很多要注意的问题，比如时区，不同的工作时段，重大的或者周期性的event。
Dale是stickyminds.com的性能测试的设计和实施者，所以他拿了很多其中的数据做例子，很详实和有说服力，不错，比空洞的讲理论要好。

8. 关于性能测试的类型
之前也了解了几种不同的类型和对应的特点。但是这次Dale的课里面是我见过总结得最全面的，而且几乎每一种他都有详细谈到。

后面有很多是performance test中很regular的东西，就不一一详述了。可以自己看slides。


OK, 最后说说my talk with Dale。
Dale在我看来比较typical的美国人，比较像美国大片里面美国大兵的style，我是步兵，请air force先轰炸一遍，然后侦察机告诉我信息，我获得必须的相应的装备，然后我做要去做的，do it。当然，这也是我个人的感受。
他说他有Irish，UK和German的血统，所以不得不能喝酒，呵呵。
和 他聊了一些关于lab simulation的问题，他的建议是针对我们的情况做几个不同level的HW，每个level可以做两个不同的配置。他很强调输出测试结果是一个 range这一点。后面聊到他是如何转做QA的。他说最开始他是做programer，写汇编，那个年代大概选择也不错，后面用smalltalk之类的 语言。然后到很多高级语言出来了，他反而觉得编程比较无聊，因为对底层的了解和控制变少了很多。后面去做consultant，然后做测试。测试让他觉得 always有新的东西，比较有乐趣，有很多不同的东西要学。不过早期的开发和consultant的经验觉得非常的有advantage。他提到一点关 于个人的提高，要持续的学习，他现在还在学新的东西。有句话觉得很有道理。My boss pay me the book, and I spend my personal time. 嗯，这样的年纪还有这样的心态，仰慕一下。还有一个体会是在全英文的环境里面英文会变好，和Dale聊天的三十分钟里面很自如，没有任何沟通的障碍。所以那些expose在全英文环境里面的人语言应该会进步很快。

Dale人很nice，其实我看到的所有的 presenter都是这样，之前Lee Copeland的一句话说的很到位，他觉得presenter做演讲，要当成是talking with friends in the living room。 所以所有的session都是气氛很好，问问题也不用举手，presenter会说，just shout it out。所以互动也不是问题，很好，要知道这些听众是来自几十个不同的国家，而且大家互相之间几乎都是初次见面。茶余饭后和很多不同的人两天，觉得很不错，这里不多写了，第二天就写到这里吧。