性能测试浅谈(2)

　　至于具体如何去设定，是需要同业务负责人(一般为PM)和技术负责人(一般为设计人员)共同确认的，业务负责人了解用户的实际需求和期望，技术负责人了解具体的实现，可以判断哪些是不可达到的要求。

　　一旦达成了共识，那么测试就要严格的按照标准去执行。

　　3.测试设计

　　主要从上面提到的几个方面进行分析，针对系统的特点设计出合理的测试场景。为了让测试结果更加准确，这里需要很细致的工作。如建立用户模型，只有知道真实的用户是如何对系统产生压力，才可以设计出有代表性的压力测试场景。这就涉及到很多信息，如用户群的分布、各类型用户用到的功能、用户的使用习惯、工作时间段、系统各模块压力分布等等。只有从多方面不断的积累这种数据，才会让压力场景更有意义。最后将设计场景转换成具体的用例。

　　测试数据的设计也是一个重点且容易出问题的地方。生成测试数据量达到未来预期数量只是最基础的一步，更需要考虑的是数据的分布是否合理，需要仔细的确认程序中使用到的各种查询条件，这些重点列的数值要尽可能的模拟真实的数据分布(数据统计信息、执行计划相关的内容，此处就不细说了)，否则测试的结果可能是无效的。

　　此外，性能测试执行过程中，需要监控收集的各种指标数据，也需要明确下来。

　　4.测试环境准备

　　部署测试环境，生成测试数据，环境预调优等等。预调优指根据系统的特点和自己的经验，提前对系统的各个方面做一些优化调整，避免测试执行过程中的无谓返工。比如一个高并发的系统，10000人在线，连接池和线程池的配置还用默认的，显然是会测出问题的。

　　5.测试执行、监控

　　准备测试脚本，执行之前设计好的各个用例，监控并收集需要的数据。出现问题时，切记要全面的保留事故现场、或者是能进行分析的数据。比如TOMCAT不再响应，不能只把这个现象记录下来，这对问题的排查定位是没有意义的，要保留所有相关的日志，导出线程转储和堆转储。

　　6.问题分析定位、调优

　　发现问题或者性能指标达不到预期，及时的分析定位，处理后重复测试过程。

　　性能问题通常是相互关联相互影响的，表面上看到的现象很可能不是根本问题，而是另一处出现问题后引起的反应。这就要求监控收集数据时要全面，从多方面多个角度去判断定位。

　　调优的过程其实也是一种平衡的过程，在系统的多个方面达到一个平衡即可。

　　7.性能报告

　　将测试过程中记录的各种数据汇总成报告，将各方面需要的结果清楚的展现出来。

　　上面所有内容中，如果排除技术上的问题，性能测试中最难做好的，就是用户模型(或者叫系统使用模型)的分析。它直接决定了压力测试场景是否能够有效的模拟真实世界压力，而正是这种对真实压力的模拟，才使性能测试有了更大的意义。可以说，性能测试做到一定程度，差距就体现在了模型建立上。

　　至于性能问题的分析、定位或者调优，很大程度是一种技术问题，需要多方面的专业知识。数据库、操作系统、网络、开发都是一个合格的性能测试人员需要拥有的技能，只有这样，才能从多角度全方位的去考虑分析问题。

　　当然，对于测试人员来说，技术能力只能排在第二号，测试思想才是最根本的。敏锐的嗅觉、严谨的逻辑、合理的推测、大胆的实践是一个合格测试工程师的必备要素。

　　模拟演练

　　写了一大堆，新手还是不知道如何去做。其实写本文的目的也不是讲具体操作，而是思想，思想。新手学性能测试，建议找一本从LOADRUNNER开讲的书比较好。如51TESTING上有连载的《性能测试从零开始》。

　　不过还是尽量说点具体些的内容吧。

　　普通BS架构的系统，一般都采用测试工具(如LR)直接录制手工操作的方式进行测试。这种方式简单有效，对测试人员要求不高。但在一些情况下，这种基于录制的方法可能无法完成，比如页面上有特殊控件、系统是CS架构、或者通讯的协议无法捕获等。这时就需要更复杂的测试方法，如手动编写模拟客户端的JAVA代码，而把测试工具当作一个调度控制台，去调度大量的虚拟用户线程执行编写好的代码。

　　现在假设有一个简易版的12306网站，JAVA实现，中间件为TOMCAT，数据库为SYBASE，没有集群处理(一切从简，只有查询和订票功能)。如何对它进行性能测试呢?

原文转自：http://www.uml.org.cn/Test/201306064.asp