《软件自动化测试高级实践》培训之性能测试部分引起的反思

这几天参加了中程在线的《软件自动化测试高级实践》培训，三天的培训内容，在课程内容列表中倒是看到了很多，但实际的培训中却仅仅是被一带而过，没有实质性的去讲每一块的内容。

当然，三天的培训并非空洞，从性能测试的如何展开到最后的性能测试报告形成，方方面面的东西都有所提及，只是迫于时间上的问题，大部分的东西还是没有深入的去讲解，倒是拿回来的资料里有很多东西值得我们去参考，去深思。

首先，从性能测试的流程上来讲整体的流程与我们现有的性能测试的过程基本一致，但是人家比我们做的更细化，这里就出现了一个为什么。为什么人家会比 我们细化？客观上来讲，我们的时间不允许，往往是接到任务的时候就一个星期的时间，仅仅是从相干人员那里拿到了口头的业务陈述，再结合上对系统架构的了解 以及之前的经验，立马动手就展开了脚本编写，场景设计与场景执行，往往是测试的很不充分，也往往是一种评估的结果，无法真实仿真，也无法提供强有力的依据 或者说是调优方案来阐述最后的测试结果。但从主观上来说，我们其实并没有对性能这块东西引起重视，往往在项目测试的时候只考虑了功能的完整性，而忽略了另 一种用户感受，那就是性能。

其次，性能测试计划过程部分；性能测试计划？很多时候没有。为什么？时间、资源都没有规划，也没有个预期的目标，那我们怎么去做好这样的一场性能测 试。走到哪里算哪里，这样的性能测试没有意义。也引出了另一层问题，我们的性能测试往往是一个人在做，而不是TeamWork导致很多时候，只要自己知道 该干啥了就行，定期的汇报相关的情况，没有人会关心实际的过程中有些什么样的问题存在，有哪些东西是我们需要配合执行的。

再次，性能测试的场景设计及执行包括脚本，往往这部分是我们做的最好的，也是很多人都关注的点，因为这个可以看到工作的实效，而且让人很有成就感， 看到那些图形上的跳动曲线，很多人就乐了，原来性能测试就是这么回事。当然这样理解也无可厚非，性能测试本来就没什么复杂或者说隐秘的。因而越来越多的人 开始研究工具，各种各样的性能测试工具，把工具玩的那个顺溜啊，但是一到实际的性能测试Team里，却会发现原来自己只是个玩工具的，其实Robot也会 干这事，根本用不着咱。

第四，性能测试结果的收集和分析，这部分的东西说实话，很恼人。要收集什么？收集到了这些东西让我看到了啥？这些东西表示什么意思啊？诸如此类的问 题往往层出不穷。我们先撇开这些不谈，反过来想，我们性能测试的目的是什么，为了保证产品或者项目的性能需求，那性能需求这部分东西要依靠什么去达到 呢？1）硬件的支撑（CPU、MEM、存储）；2）系统环境的支撑（OS、中间件、web容器、网络）；3）应用系统的支撑。既然需要这么些东西来支撑我 们的系统，那么我们再沿着这些东西去看我们最后的监控也好，收集也好，那些结果不就是要让我们去看这些支撑的东西的情况吗？

最后，性能测试调优，这块东西其实已经不能仅仅归属于性能测试这一块了，可以逐渐的向前推，一直推到系统架构设计的时候。这个阶段更多的是依靠经 验，就像一个房子，连房屋的结构都没搭好，你再怎么去给下面垒基石，它也不可能给你承受更多的楼层，同样的在系统架构设计的时候就必须先设想好我们未来的 产品面向群是怎么样的，可能会有多少的用户量，才能进行好的架构的设计。系统的架构做完了，那我们就需要来规划应用的架构，什么样的应用能适合于我们的系 统要求，同样的要和我们的系统架构相吻合，不能说房子只靠结构顶着，底下几层的砖块要这么彻，基石要怎么打，必然会影响到你的未来楼层数。做好这些之后就 看我们的代码质量了，当然这些东西都是些经验上的东西，不是一句话两句话能说明白的，这里面所涉及的东西，需要我们长期的积累，也需要一个Team去完 成，没有任何人能把所有的这些涉及模块都吃透（那样的人或许是存在的吧，但是至少目前我没见到过）。

赘述了这么多，其实关键就是大家平时多去积累，考虑功能的同时要带有对性能的想法，改变现在的工作状态。

个人浅见，有不足之处还希望指正。