我从零距离接触性能测试到今天，也才一年多的时间，在这上面走过的路崎岖蜿蜒，个中滋味只可意会，不可言传。虽然我已经从入门到“放弃”了，但是我一直在思考和寻找，怎么样才能让性能测试不再看上去那么“高不可攀”。
性能测试其实就是测试的一种类别，那么相应的，它也是有一套标准流程的，无外乎就是需求分析、测试计划制定、测试执行、结果分析等几个环节。
所以，针对性能测试流程里的几个环节，我把自己换位到当初的小白，去思考自己当时最希望得到什么样的支持和帮助，再结合产品化的思维，思考出下面这样一个可以被拿来主义“的性能测试框架或指导性体系。
1、是什么？
性能测试里的常用基本概念、测试方法和标准流程的定义和解释；
2、做什么？
性能测试需求的分析方法，可以采用 checklist 的问题形式来帮助使用者得出对应需求所需要采用的性能测试种类，是压力测试，是稳定性测试，还是健壮性测试等等；
3、怎么做？
3.1 对应着上述第2步，得出来的具体的测试种类，每一种都有相应的测试方法说明，包括需要准备什么样的数据、步骤和如何选取相应的脚本进行修改或组装；
3.2 有一套对应的样例库，包含脚本（.usr）、参数化文件（.dat）、场景（.lrs），虽然说不可能百分之百通用或者套用，但至少在同类产品的性能测试中都能套用，它们都是相对独立、结构清晰的一个一个的数据包，便于更新和管理；
4、怎么样？
性能测试完成后，系统都会生成一个报告。针对常用的单分析图和组合分析图，有样图与我实际的图做对比，并告诉我这些数据图，分别代表着性能的哪些指标，这些指标的值，又分别代表着性能是好还是坏；
5、怎么办？
对于常见的性能问题，罗列出通用的解决方案，比如是应该检查并优化 SQL，还是应该修改服务端 Tomcat 的连接数大小等等。
如果能有这样一套产品化的性能测试框架，那么我想，性能测试这种大山对于大多数测试工程师来说，也就不那么”高不可攀“了，对吧？
具有指导性的作业文件、测试计划模板、独立的测试数据和测试脚本、分布式测试环境搭建脚本或手册、测试报告和相应的分析模板，能支撑一套完整的性能测试框架迅速落地，快速适应不同的项目，并且能让测试工程师以最小的学习代价完成性能测试任务。
不过，这么一套框架不是一朝一夕就能建立起来的，它必须是在性能测试工程师对理论有了很深入地理解，并通过多个项目的实战，从中总结、归纳而形成的一套方法论体系，再辅以相对独立的数据和脚本、计划模板、分析步骤和模板等相关工具。不断地打磨、优化和改进，才能形成一套不论是入门级的小白，还是进行中的老鸟，都可以轻松利用它登上高峰的这样一个产品。