【随笔】性能测试-测试套路

“给时间以文明,而不是给文明以时间“，最近被刘慈欣的《三体》严重洗脑，哈哈，干什么事都会上升到黑暗森林里去寻找答案，哎哎！

好久没有总结理论性的东西了，最近公司有性能测试培训，在测试培训资料的编写中发现很多理论性的东西需要一步步再次总结了，哎~~~~~~~人老了，变鱼了。下面进入正题：

注意：这里只提供大体思路，细节问题要具体问题具体分析，毕竟尽信书不如不读书,事情要留有自己思考的空间-_-!

把目前亲身经历的软件性能测试分了下类、大体三类：

1.交付项目性能测试

2.产品性能测试

3.基础中间件性能测试

交付项目的性能测试

交付项目目前广泛存在于银行、金融的外包项目以及互联网企业在自有产品基础上进行业务线研发的项目中，通常情况下甲方（客户方）会对项目提出性能需求，最常见的就是某某客户方要求说：系统要满足3000并发......测试通常会是一条由若干个服务器组成的业务线。这种时候，我们采取的大体策略是：

• 明确并发指标（短连接等同于TPS）

     客户关注的是每秒钟能支持多少人同时操作，所以这里可以与TPS等同。

• 确定测试环境

    测试环境的配置直接影响测试结论，为了减小测试误差尽量与生产环境配置相同或规模成线性比例。

• 明确测试场景

    这个与功能挂钩、如app或web页面中的首页、登陆、账户查询等。

产品性能测试

产品性能测试关注点不是某个客户的需求，而是满足市场上全部至少大多数用户的共有需求。性能测试的意义类似于产品适配说明书，把除了产品以外的所有条件都变成变量，只有产品是常量（把产品看成整体，毕竟产品本身也有各个参数配置）：

• 在不同外界配置下、产品标准配置下的性能表现。
• 在产品不同配置下、不同外界配置下产品的性能表现。如F5负载均衡，一套给app加密的系统等等。

基础中间件性能测试

基础中间件的性能测试大多发生在项目、产品设计过程中的技术选型阶段，或者架构部门自主研发中间件之后。比较趋近于架构的性能测试。

• 测试场景要考虑到正向、反向、灾备情况。
• 同时也要重点关注代码内队列、缓存、线程池等参数（虽然是配置，属于代码级别的配置）。
• 与产品性能测试雷同、不同配置下性能表现。
• 是否符合业务链场景的需求。

目前对测试岗位的要求越来越高，身兼多项责任的测试，重要的从宏观上看待自己的工作，用微观的技术去解决具体问题，不断抽象出属于自己的方法套路，在工作中不断打造属于自己的宇宙战舰。。。。。。。又是科幻了。