模板
教程
环境
性能
功能
管理
我们一起聊聊性能测试是怎么一回事？(8)
发表于：2017-02-21来源：gitbook作者：靓汤点击数：
标签：性能测试
可以考虑一下几个方面： 测试数据（基础数据、业务数据）不多解释这个文章中有。 测试场景（基础场景、综合场景）场景一定要同业务过，看看是不是
可以考虑一下几个方面：
- 测试数据（基础数据、业务数据）不多解释这个文章中有。
- 测试场景（基础场景、综合场景）场景一定要同业务过，看看是不是真实的，或遗漏了。最好是用户，而非业务。
- 参数化策略（如何参数化、如何取数、数据用完后怎么办等，这个后面的Chat会分享）。
- 集合点策略（全部虚拟用户都到了在压，还是等到%XX就可以压，还是业务成功达到多少在压）。
- 检查点（又叫断言，判读事务是否成功）这是很多初学同学容易遗漏的。
- 环境（网络、服务器配置、防火墙等、中间件配置、定时任务频率、应用配置等）。
- 负载机情况，需要把负载机的监控纳入监控范围。（很多失败原因都是没有关注负载机情况导致测试走弯路）,这也是常见问题。需要特别说明的是“网络”这是也是遇到最多的问题。（可能负载机的网络带宽限制，导致无论怎么样压，压力都上不去，一直找不到原因）。
问：经常看到有很多同行或者同事做的性能场景很复杂(非综合场景)，需要很多步骤组成，写的脚本也很长，当然我本人没做过那么复杂的，不知道实际情况，所以我想问一下是不是实际上真的存在这么复杂场景的性能测试，或者这些很复杂的场景是否可以简化成对某个接口的测试？
答：脚本一定不要太长，能抽象一定抽象，太长自己看不到逻辑关系。所有我写脚本都会先写伪代码。建议大家也这么做，先设计表格，依照表格写伪代码。比如刚刚的场景用例设计表格。文字最好懂，代码不易懂。然后能抽象出去的就抽象出去。需要加的关键点都在场景设计和用例设计时一表格的形式列出来，专家也好评审。对于接口测试，你的思路是对的，我们可以拆解，但接口测试代替不了页面测试。
