没有明确的性能测试目标，没有测试需求，没有测试策略。但这却偏偏又是性能测试，所以称之为尴尬的性能测试。性能测试，在很多人眼里，就是扔给你个LoadRunner，给你的URL链接，然后再给你个性能测试报告的模板，最后告诉你，给你一个星期，或者说在XX号前把报告交给我。
于是乎，我们的性能测试工程师一拿到LoadRunner和URL就开始性能测试的旅程。这趟旅程不知道终点在哪（没有明确的测试目标），也不知道该怎么走（没有测试策略），既然开始了这趟旅程（老板任务已经下来了），就硬着头皮上吧（反正手里有这个万能的LoadRunner）。
脚本篇-我们的性能测试工程师虽然是初出茅庐，但是由于经常逛论坛和看资料，还是懂一点LoadRunner的测试流程。于是就用LoadRunner强大的录制功能，录制了基本脚本。接下来在脚本中参数化参数，插入事务，插入集合点，等等增强脚本，忙得是不亦乐乎。在迭代了几次回放后，没有报错。脚本就这样完成了。
场景篇-脚本完成后，开始准备设置场景的参数。没有做任何的基准测试和容量测试（这两者的概念还是后来得知的），测试报告上说要求多少个用户，持续多少时间，就填上相应的参数。作为性能测试，总归要监控服务器的性能，一开始我们的性能工程师是用他们的头儿推荐的方法：用操作系统自带的性能工具来监控服务器的性能。他的理由是：LoadRunner是装在测试机的，用测试机来监控服务器的数据，会存在网络上的延时而不准确。“用了LoadRunner，为什么不相信LoadRunner？如果用系统自带的性能工具来监控，为什么不请100个民工一起点，或许这样的效果更好，更真实。”一位测友的的原话，有点嘲。
分析篇-其实对这位性能工程师来说，根本就不存在着分析这个环节，他所要做的工作就是把平均响应时间，90%的平均响应时间，和服务器的一些性能数据，比如CPU %processor time等等全部塞进他们头儿给的性能测试报告中，点下了邮件的“发送”。完成了一次尴尬的性能测试的旅程。
后记：用自嘲的语气回忆了自己一开始做性能测试时的经历。有点嘲，有点尴尬。不过我觉得这种尴尬的性能测试存在于很多公司，或许你就有和我一样的经历，一样的体会。尴尬的性能测试，究竟是谁之过呢？没有明确的测试目标的性能测试，我们究竟该怎么做呢？值得我们深思……
