Larmy

现象：并发量比较大，服务端响应异常等情况下，脚本运行结束后，部分用户线程陷入无限循环，无法自动终止原因：HTTPSamplerBase类中执行readResponse方法时，读取inputStream时，可能出现空指针异常，未进行异常处理，导致无法跳出while循环。修复版本：HyperPacer3.0.1

性能测试和分析过程只是预防性能风险，而不是保证系统性能。应用系统上线后，面临的业务处理和数据是动态变化的，依赖的运行环境也会不稳定、老化，出现性能下降是正常的，什么时间什么场景下降到什么程度我们不能接受的，是系统管理和运维者需要关心的。我们不希望在出现这种问题之后采取解决，那样可能为时已晚，造成巨大损失，我们希望在问题出现之前就预测的到，然后采取预防性措施避免问题的出现。这就需要建立跟踪预警体系，

性能问题的解决往往牵扯到各种角色，需要各种角色的高效协作和互相认同才能得到较好的解决。做为性能测试人员，在向项目干系人报告时，就需要做到量身定做，对结果数据进行不同加工和展现，充分考虑汇报对象的角色，如果汇报对象是各种角色，要能让各种角色都能看的懂，各取所取。起码做到决策层能轻易知道系统的容量、吞吐量和资源投入，业务层知道关键业务场景覆盖到，而且响应时间是乐于接受的，实施运维人员知道保持这样的

软件需求可以分为功能性需求和非功能性需求，功能性需求往往是很明确的，功能测试更多的是关注与需求的符合度。性能属于非功能性需求，往往很模糊而且在项目初期被忽视。性能测试的目标和标准很难单方面去统一，不同层级有不同的认识和要求。ITIL是性能测试的基础，业务活动是性能测试的核心。从业务活动抽象出业务模型，形成控制流程，从ITIL结合系统实现形成系统架构，不同构件之间的数据交互和统计形成

对于大多数初创团队来说，资源有限，资金有限，技术有限，时间更有限，当务之急是最快的速度实现产品核心功能，发布到市场，获取用户，抢占市场至高点。对于产品质量的要求更多的偏重于功能正确性和操作流畅性，在产品获得用户认可，取得初步成功时才有可能获取更多的资源，增加产品研发运营投入。为了降低研发成本，加速研发效率，初创团队应该尽可能的选择成熟的、稳定可靠的技术框架，在开发过程中加强产品功能的自测，保证

国内部分系统Web页面都采用GBK做为编码，而一些国际化测试软件（如loadrunner、jmeter）一般使用UTF-8或者默认的ISO系列编码，导致录制的脚本中中文显示为乱码，以GBK编码post的数据，由于被测系统一般仍按GBK解码，无法识别编码而导致脚本执行结果不符合预期。HyperPacer解决了这个问题，在对Web页面编码的检测过程中，如果检测到是GB系列编码，自动完成跟UTF-8编码

敏捷开发中快速进行版本迭代和发布，已经成为大多数敏捷团队的工作常态。同时，保证每个版本软件功能运行性能不下降也是其基本目标，但是由于团队资源不足或者测试成本过高等原因，对于多数团队来说这一基本目标也只是美好的愿景。        其实，做到这一点也不难，对于核心代码建立单元级别的自动化性能测试，对于核心业务流程建立Web应用级别的自动化性能测试，在每次代码集成或发布的时候由构建系统自动运行测试

大多数运行在互联网上的系统，在用户浏览器和服务器数据交互过程中，对传输的敏感数据通过加密通道（如https）或者对数据进行加密编码后发送给服务器，这种处理保证了数据的安全性，但是给性能测试增加了难度。因为一般测试工具是通过录制生成测试脚本的，录制过程中拦截到的请求数据是浏览器已经加密编码过的，对测试人员来说是不可识别和加工的，那么就无法模拟更真实的压力测试。        解决办法是在录制过程

该报告汇总统计了包括猎聘、拉勾、智联、前程无忧、58同城、中华英才网等主流招聘网站近一周（2016.5.25-2016.6.01）发布的性能测试工程师的招聘信息，主要从对性能测试工程师的技能要求、岗位职责、薪酬待遇、工作经验要求等角度进行统计抽样，以便对性能测试工程师的职业现状做个概要分析。        该调查一共统计了全国近300家公司的招聘信息，收集数据时对于一些软性要求，如要有

优化软件性能之前，首先需要有正确的认识，软件性能本质上是一种主观的基于时间感知的用户体验，是资源消耗、逻辑处理、用户行为等综合作用的外在表现，脚痛医脚，头痛医头，没有包治百病的药，性能优化亦如是。再好的硬件解决不了应用软件设计和开发的问题，不能片面的将性能优化全部寄希望于硬件和系统层面。应用设计和开发的问题主要有两类，一是对硬件资源的利用不足，如过度的锁控制、线性资源依赖等，导致硬件资源闲置；

不管是企业用户还是软件供应商，都有个公共目标：取得（业务、技术、产品、销售、事业）成功，更少的资源做更多的事情。在实现目标的道路上，不同角色采取的策略不同，结果可能也不同，以实施全面性能管理前后对比为例进行阐释：管理者：实施前：主观的认为项目肯定能按期交工，如约履行项目合同，找不到悲观的理由，结果是项目做的坎坎坷坷，历经波折，感觉不会再爱了实施后：熟知关键风险点，注重提高资源利

随着互联网的大众化以及Web应用软件向互联互通方向的拓展，随便一个Web应用几乎都伴随着大数据量处理或者高并发访问，动辄几十万用户量或者几百G数据量，都已经是稀松平常的事了。大数据量和高并发访问的特点给Web应用软件带来了更多的性能问题，性能问题已经成为决定Web应用成败的关键风险，所以有效的性能管理对消除性能风险至关重要。传统模式下，性能问题的解决往往涉及诸多角色协同和应对多种陌生的技术

性能是个日常生活中我们广泛提及的词语，比如买计算机、买车，我们都会问“性能怎么样？”，我们都期望到手的东西性价比是最高的。对于不同的东西，性能代表的意义也不尽相同，比如计算机的性能，通常是指运行程序的速度和能运行程序的规模，汽车的性能通常是指动力和能达到的加速度。上网的时候，我们也会经常抱怨“这网站的速度真慢，性能真差！”，做为一个IT人，我们都知道一个网站的背后，是一整套软硬件系统的高度集成。如

人们的日常生活、工作、娱乐已经离不开各种软件系统，软件系统的功能和性能相辅相成。软件系统的功能再强大，但是如果性能让用户感到不满或沮丧，就已经失去了可靠性和可用性，很难想象这样的系统会有用户愿意坚持使用并买单，性能已成为考量这些系统成功与否的关键因素。        提起软件性能，大部人首先想到的可能是响应速度、并发人数。比如我们的系统响应速度都很快，都在3秒内，我们的系统能支持1000用户并

用户有角色之分，有业务人员，运维人员，管理人员等。不同角色的用户有不同的关注点，我们要站在不同用户的角度考虑性能问题。业务人员不关心系统吞吐量、网络带宽、点击率等，他们只在乎良好的操作体验，运维人员更关心系统的资源消耗，管理人员更关心系统能否实现预期管理目标，降低成本，创造利润，这些都可以归结为用户体验。为了保障用户体验，我们得有和用户一致的目标。在系统交付用户前，我们需要模拟用户操作，对系统性能

性能问题是伴随着软件开发、实施及运维过程产生的，每个过程都可能引入不同的性能问题，问题发现的越早，越容易解决，成本越低，投产后才去发现问题，有可能导致灾难性的后果，导致大量的返工和重构，原有的问题不能完全解决，还可能引入更多新的问题，成为一个恶性循环。所以理想的情况是从项目立项开始，就进行性能相关工作，性能评估过程伴随软件开发、实施及运维过程，对系统性能进行和开发及实施到运维周期一致的全生命周期管

确定合适的性能管理过程后，在每个阶段就会有不同的性能测试定义和标准。比如单元级别的性能测试，需要测试每个类或方法的执行时间和资源消耗，接口级别的性能测试，需要测试每个组件执行调用花费的时间和资源消耗，系统级别的性能测试需要模拟预期真实用户的行为来识别和消除应用或系统性能潜在的瓶颈，用户级别的性能测试需要模拟预期真实用户的业务场景来评估用户体验。目前绝大多数公司的性能过程管理只能做到系统性能测试和用

性能测试的过程是生产和收集评估数据的过程，测试过程会产生大量的各种测试数据，这些数据是评估我们是否达到性能目标的依据。我们不光要对数据进行汇总和统计分析，还要对数据本身进行去伪存真。错误的测试数据会产生错误的分析结果，掩盖掉存在的问题，造成错误的判断。分析系统性能不是简单的根据测试结果数据出图表，编写报告，而是首先对结果数据进行有效性分析，如果有效性不足，就要找到原因，调整测试过程，得到更加有效的

性能测试是对系统整体处理能力进行验证、度量、评价和确认的过程，整体处理能力包括可承受的负载、资源的消耗、用户体验以及可靠性等。全面的性能测试不光贯穿软件开发的整个过程，还包括系统上线后的运维、升级过程。性能测试的主要目的是预防和预测性能风险，而不是保证性能质量，性能质量的保证要靠各种资源和人员的有效配合和协同。有效的性能测试是在资源投入、用户体验等方面达到一种平衡，所以要有精确有效的度量。性能

结合软件能力成熟度模型，我们可以将性能管理(设计、开发、测试）能力归结为四个阶段：初始级、定义级、集成级、优化级。此分类适用于评价组织能力，也适用于评价组织内部的项目团队能力。

通过工具自动获取Oracle awr测试报告