编号V1.0_CR001_Case.001V1.0_CR001_Case.002V1.0_CR001_Case.003V1.0_CR001_Case.004V1.0_CR001_Case.005V1.0_CR001_Case.006V1.0_CR001_Case.007V1.0_CR001_Case.008测试点（简单描述，具体到按钮）目的功能描述 （功能做什么的？及此功能操作步骤）业务数据量在线数并发数V1.0_CR001_MixedCase.0011、在线数：取系统最高同时使用人数 2、并发数：在线数据的10%~100%不等（一般取在线数的10%~30%） （1、混合场景并发数的基数取 在线数的10%（范围 10%~30%）；2、混合场景中的每3、需求中有要测第三方的，请开发提供接口方可测试。接口测试的并发数和在线数相同 4、性能测试的最终测试内容需结合客户真实的应用场景，客户应用最多，使用最频繁的功能 5、根据二八原则，通常系统用户经常使用的功能模块大概占用系统整个功能模块数据的20% 6、测试点：菜单下面具体功能点，具体到页面按钮 7、业务数据量：如使用对象、上传/下载文件大小、查询相关数据量等…，没有请忽略 8、响应时间：对请求作出响应所需要的时间 网络传输时间：N1+N2+N3+N4 应用服务器处理时间：A1+A3 数据库服务器处理时间：A2 响应时间=N1+N2+N3+N4+A1+A3+A2 9、90%响应时间：所有业务所需要的时间90%的比例都比此值小的时间，也就是90%的数据中所拥10、事务成功率：事务通过数/（事务通过数+事务失败数） 事务通过数：在测试期间，系统一共11、TPS：有这个需求可以提，没有这个需求忽略（即系统每秒钟处理业务数。客户机向服务器发送数，最终利用这些信息来估计）比如：在100个并发用户的高峰期，“登录系统”处理能力至少达 12、备注：一些其它需求请备注 13、TPS计算方法： 按某系统去年全年处理“WEB登录”约 100 万笔，考虑到 3 年后登录量递增到每年 200万笔。 假设每年登录量集中在 8 个月，每个月 20 个工作日，每个工作日 8 小时，试采用 80～20 原理估算假设每年登录量集中在 8 个月，每个月 20 个工作日，每个工作日 8 小时，试采用 80～20 原理估算200万/8=25万/月 25万/20=1.25万/日 1.25万*80%/(8*20%*3600)=1.74TPS 14、性能测试点的选取： 1）、发生频率非常高的（如邮箱：登录、收发邮件等业务） 2）、关键程序非常高的（认为绝对不能出现问题的，如登录） 3）、资源占用非常严重的（引起I/O非常大的，如某个业务查询或提交时，检索出大量的数据记录 15、性能测试类型： 1）性能测试：这里指的是多用户并发性能测试； 2）容量测试：确定系统可处理的最大用户数； 90%响应时间（s）响应时间要求登录 Y在线X并发 ≦3s页面加载 Y在线X并发 ≦3s查询 Y在线X并发≦3s（和数据量有关；一般数据量小表结构简单的查询，要求90%响应时间≦3s）事务成功率内存平均使用率CPU平均使用率≧99%≧99%≧99%≧99%≧99%≧99%≧99%≧99%4G ≦80%8G ≦60%16G ≦40%32G ≦20%64G ≦10%2核 ≦80%4核 ≦70%6核 ≦60%8核 ≦50%16核 ≦20%调研情况线上真实使用情况，如测试环境、用户数据等表单提交 Y在线X并发 ≦3s（和表单数据有关；一般数据量小表结构简单的提交，要求90%响应时间≦3s）超过以上要求需要备注中注明原因≧99%≧99%≧99%≧99%中的每个测试点的并发数比例分配根据业务实际情况分析确定，并且≦单场景中对应测试点的并发中所拥有的峰值。90%响应时间，可能表述为75%、80%等 统一共正确处理的业务数 务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计至少达到100TPS或不等 理估算系统服务器高峰期“WEB登录”的吞吐量应达到怎样的一个处理能力 理估算系统服务器高峰期“WEB登录”的吞吐量应达到怎样的一个处理能力 据记录或需要向多个表存取数据等） 性能测试服务器性能测试类型备注需求评审三方确认的测试服务器配置、数量和来源，并明确如测试部现有资源不能满足或测试阶段项目冲突难以协调时的资源解决方案1.性能测试2.容量测试(选择此类型时，对应测试点可不填写在线数和并发数）3.容量测试只针对没有实际客户的标准化产品，项目周期允许情况下，可以选；此类测试的测试时间较长的并发数） 结束计时，以此来计算使用的时间和完成的事务个