jmeter性能测试报告V1.0.xlsVIP

附录-性能测试指标 问题卡 （场景1）并发1000测试结果分析 场景设计 测试方案 更改履历 被测试系统简述 描述 在一定的配置环境下，测试应用的实际响应时间与要求的响应时间是否相符。主要来度量当前的配置是否能够满足应用的需要，响应时间应该在系统建设初期提出，测试只是来验证解决方案是否能够满足需要，如果不满足，通过测试查找问题在那里，帮助定位问题，最终满足需求。 配置环境包括：硬件、网络、软件配置、访问人员数量、操作或使用功能的一个典型场景。 典型场景如：假设该系统为订票系统，在2小时内，有1000人登录，有500人注册、订票，有400人订票，有100人查看订票情况、退票。 通过不断加大测试压力（如并发用户数），测试当前配置（资源的使用基本达到上线，响应时间还可以接受）的最大处理能力，从而确定什么样的配置能够提供最佳的性能级别。此指标需要测试得出，如果测试环境与实际环境不一致，可以通过此指标来帮助估算实际环境是否能够满足需要。如果测试环境就是实际环境，那么可以通过此指标来帮助决策未来系统的扩容方案。 测试系统是否能够稳定、可靠的长时间运行，是否能够满足上线的需要。主要通过一定的压力长时间的测试，以测试系统的资源分配、占用、释放等方面是否能正常处理，从而对系统是否可以切入正式的生产系统做出评价。如果测试环境和真实环境不一致，可以测试软件方面是否存在问题；最好在系统上线前，在实际环境下进行上线前测试，确保系统上线后能够正常运行。 测试软件的新版本是否会使得应用的响应时间受到负面的影响。这个指标的测试在应用系统增加新的应用后特别重要，一些系统往往运行的很好，但是增加了一些看起来是比较小的应用后，使系统的响应时间受到了严重的影响，整体的响应能力极大降低，严重的还会导致整个系统的瘫痪，这种情况必须引起重视，因为很多时候，测试人员只是单独对新增的应用进行测试（相当于增量测试），没有进行整体的衰退测试。 通过性能测试，找到压力和系统配置的一个趋势，从而对系统容量做出规划，确定当系统容量达到什么级别时需要对系统进行扩容。 通过测试，识别和确认引起系统性能降低的瓶颈。一般在系统运行一段时间后，发现系统应用的响应时间加长、资源占用过多等影响系统性能的问题，而实际上用户可能还没有达到系统规划的容量，这时候需要对系统进行压力测试，以期发现瓶颈究竟发生在那里（是软件、硬件、网络等）。有时，在上线前的性能测试因场景设计不合适，也会导致得出的结论有偏差。如系统刚上线初期，一般注册的用户比较多，注册功能使用的较多；当用户达到一定规模后，注册功能使用的就会减少，办理业务的功能会增多；另外，初期用户不熟练操作时的考虑时间会较长，熟练后考虑的时间就会缩短，这些都需要在场景设计时充分、全面考虑。 当前配置的最大处理能力(Configuration sizing) 衰退测试(Regression) 系统容量规划（Capacity planning） 产品评价（Product evaluation） 性能测试指标 稳定性(Acceptance)、可靠性（Reliability） 序号 被测试系统资源配置情况 资源名称 操作系统 主要参数配置情况 被测试系统的部署结构示意图 厂家型号（版本） 场景名称 测试目标 应用的响应时间（Application Response time） 瓶颈识别（Bottleneck identification） 简述 测试结果 1.2.1 场景设计 更改履历 Change History 序号 No. 发布版本 Issue 更改时间 Date 更改章节 Change Section 状态 Status 更改描述 Comments 更改申请号 Request No. V1.0 新建N 性能测试目标 测试主机 （个人PC机） Microsoft Windows XP Professional Service Pack 3 1.2.2 结论 测试问题卡 表格编号：FD207-测试类型代号-项目编号-两位流水号 项目编号： 序号 模块编号 错误现象 等级 类型 频率 时机 发现人/日期 修改人/日期 确认人/日期 确认结果 注： 1. “等级”是指错误等级，可分为A：严重影响系统运行；B：影响系统运行；C：不影响运行但必须修改；D：所提建议； 2. “频率”指错误出现频率，分为A：操作即出现；B：偶尔出现（n/m），其中n/m表示错误出现的频度，n代表错误出现次数，m代表为了再现该错误所进行的实际测试次数； 3. “时机”指错误出现时机，分为A：修改后出现；B：已发现但未修改正确；C：首次出现； 4. “类型”指错误的类型，分为A：功能错误；B：性能错误；C：可用性错误； QMS2005