性能测试流程之我见

为什么需要性能测试：

根据Google的统计，如果网站打开慢每500毫秒，用户访问量将下降20%
根据Amazon统计，每慢100毫秒，交易额下降1%

HP对性能的提问：

Does the application respond quickly enough for the intended users?
对目标用户来说你的应用程序的响应时间足够快吗?

Will the application handle the expected user load and beyond?
你的应用程序能轻松应付那么多的用户负载吗？

Will the application handle the number of transactions required by the business?
你的应用程序能处理那么多业务所需的事务吗？

Is the application stable under expected and unexpected user loads?
在预期的用户压力下，你的应用程序足够稳定吗？在超出预期的用户压力下呢？

Are you sure that users will have a positive experience on go-live day?
你能确定用户在使用你的应用程序时会得到好的体验吗？

不同用户眼中的软件性能是什么：
普通软件使用者：用户操作软件的响应
软件研发人员：架构设计是否合理，是否有不合理的内存使用方式，是否存在不合理的线程同步方式，是否存在不合理的资源竞争
运维人员：资源利用率，系统稳定性：7*24？，系统容量

so，性能测试定义（按我的理解得出，大家有疑问可以提问交流）：
针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值

上述“既定值” —> 常用指标：
响应时间
并发用户数，吞吐量
每秒事物数，事物成功率
服务器资源使用

性能测试模型如下（套用pdca）：

项目性能指标获取：

1、旧有项目：项目原有性能指标，或者参考线上日志数据
2、新项目：立项数据预估，同类产品分析，如果这两种数据都没有，那就借鉴公司内部其他产品历史峰值数据

按照模型，接下来是场景设置
性能场景一般为如下分类：
基准场景：这里要做的是单业务的容量，为组合场景做准备，如登录，注册，支付等业务，测试每个业务单独的最大TPS。
组合场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个，如 组合场景 100个用户访问系统，首页访问50%，登录占30%，注册占10%，支付10%。
稳定性场景：长时间运行下，系统稳定的表现（我认为网上有些细分的疲劳测试，也属于这个范围）。
异常场景：做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的，比如宕数据库（主从库），负载均衡下宕系统应用，根据自己实际的业务来定义哪些异常项测试

剩下的操作就是环境部署，测试数据的准备，脚本编写，场景执行，数据监控-----这个但凡是做性能测试，都是基本功

问题排查及调休-----这个需要实际案例来结合讲解，后续再贴出