搜索
功能测试：功能指的是在一般条件下软件系统能够为用户做什么，能够满足用户什么样的需求。性能测试：性能就是在空间和时间资源有限的条件下，软件系统还能不能工作。区别：软件性能和功能区别的实质是，软件功能焦点在于软件“做什么”，关注软件物质“主体”发生的“事件”；而软件性能则关注于软件物质“做得如何”，这是综合“空间”和“时间”考虑的方案（资源和速度），表现为软件对“空间”和“时间”的敏感度。认识到性能的这个基本特征对于性能测试人员非常重要，性能测试就属于软件系统级测试，其最终目的是验证用户的性能需求是否达到，在这个目标下，性能测试还常常用来做：（1）识别系统瓶颈和产生瓶颈的原因；（2）最优化和调整平台的配置（包括硬件和软件）来达到最高的性能；（3）判断一个新的模块是否对整个系统的性能有影响。性能指标：用户关注的性能指标包括响应时间，资源占用：CPU占用率、内存使用率、磁盘I/O、网络I/O，计算性能；资源的利用和回收，启动时间、伸缩性、稳定性。响应时间（Responsetime）响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间隔，看起来很简单，但其实在这段响应时间内，软件系统在幕后经过了一系列的处理工作，贯穿了整个系统节点。根据“管辖区域”不同，响应时间可以细分为：（1）服务器端响应时间，这个时间指的是服务器完成交易请求执行的时间，不包括客户端到服务器端的反应（请求和耗费在网络上的通信时间），这个服务器端响应时间可以度量服务器的处理能力。（2）网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时间。（3）客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端Web应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端Web应用来说，比如Javaapplet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注意的一个地方。那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上。吞吐量（Throughput）：指软件系统在每单位时间内能处理多少个事务/请求/单位数据等。但它的定义比较灵活，在不同的场景下有不同的诠释，比如数据库的吞吐量指的是单位时间内，不同SQL语句的执行数量，网络的吞吐量指的是单位时间内在网络上传输的数据流量。资源使用率（Resourceutilization）：常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O。点击数（Hitspersecond）点击数是衡量WebServer处理能力的一个很有用的指标。点击数不是我们通常理解的用户鼠标点击次数，而是按照客户端向WebServer发起了多少次http请求计算的，一次鼠标可能触发多个http请求，这需要结合具体的Web系统实现来计算。并发用户数（Concurrentusers）并发用户数用来度量服务器并发容量和同步协调能力。在客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同的是，它大多是占用套接字、句柄等操作系统资源。另外，度量软件系统的性能指标还有系统恢复时间等，其实凡是用户有关资源和时间的要求都可以被视作性能指标，都可以作为软件系统的度量，而性能测试就是为了验证这些性能指标是否被满足。计算性能；计算性能是用户最关心的一个指标，即软件系统有多快。完成用户典型操作，比如业务的交易计算，数据的增、删、改、查时间是不是在用户可以接受的范围内。资源的利用和回收；资源包括硬件和软件资源，硬件资源包括客户端硬件、服务器硬件和网络硬件；软件资源包括操作系统、中间件和数据库等。运行软件系统需要使用到的服务器内存数量，对于整个系统的性能表现是至关重要的。因此，软件系统能否在运行时有效地使用和释放内存是我们考察软件性能的一个重要因素。在评价一个系统性能的时候，要特别关注这个系统对内存的使用。如果内存不够大，CPU就不能把全部的数据和程序放到内存里，只好放一部分在内存，一部分放在硬盘中，现用现取，而读取内存和读取硬盘数据的速度要差好几个数量级，这就大大影响了计算机的工作效率。启动时间；用户希望系统进入正常工作状态的时间越短越好，不同软件系统启动时间会不同，J2EE系统在第一次启动的时候一般会比较慢，因为期间涉及缓存的加载、JSP页面的编译、Javaclass编译成机器指令等。所以在第一次启动应用感到非常慢是比较正常的，这也是J2EE或者Java应用的一个特点。而C/C++程序直接运行的是二进制机器代码，启动速度就要快一些。伸缩性；伸缩性是分析系统性能经常被忽略的一个方面。比如一个系统在50个并发用户访问的时候表现正常，但是当并发用户达到1000的时候，系统表现如何？随着并发用户的增加，平均响应时间逐渐稳定下来。稳定性用户希望自己的软件系统是千里马，而不是黑马。千里马是一直跑得快，黑马是短时间内跑得快。满足用户性能需求解决方案内存泄露：程序在运行过程中无法释放不再需要的内存空间，导致系统无内存可用，甚至系统崩溃。具体来讲，当用户程序在运行过程中需要动态获得内存时，操作系统总是从堆（heap）上分配相应的空间给应用，分配的结果是将该堆内存的起始地址通过指针返回给应用。应用程序使用完这块内存后，应通过系统调用主动通知操作系统回收这些堆内存以便重用。但是，如果由于设计缺陷导致在某些情况下程序没有主动地通知到操作系统，而后应用又失去了对这块内存的引用时，则该堆内存块将成为既不受程序控制，又不能被系统回收重用的“孤儿”内存，这便是我们所指的内存泄漏。做性能测试的大部分工作都是为了寻找这个瓶颈到底在何处。对于性能测试来说，预期输出就是用户的性能需求，一份明确的性能需求是成功性能测试的先决条件。pareto原则应用于软件测试，也包括性能测试，即性能测试发现的错误中的80%很可能集中在20%的程序模块中。性能问题从以下三方面考虑：1、软件系统设计的架构及技术平台软件在设计阶段一旦决定采用哪种架构和技术，其性能也就注定只能在一定的范围内变动了。这就是“先天”因素。比如一个删除/增加数据的业务操作，如果用户对时间非常苛刻，密集型计算、在线的大数据量统计和分析等应用，这些场景通常J2EE不能够很好地解决，使用C++或者其他平台搭建会更合理些。如果在这些场景下硬要采用J2EE架构，那么开发和设计人员如何绞尽脑汁，优化设计和程序，也不会满足用户的性能要求。2、中间件的设置和优化这里的中间件是广义的中间件，是应用程序调用的第三方软件，包括操作系统、数据库、Web服务器、消息服务器等。我们不能改变中间件的程序，只能通过调优手段来提高它所支持的软件系统的性能。3、硬件的配置这里包括服务器硬件配置和网络环境。服务器硬件包括内存、CPU等，网络环境有交换机、路由器等。选择性能测试案例时应遵循的原则：（1）基本且常用的比如，一个E-mail系统，基本且常用的功能有注册、登录、收邮件、查询邮件，用户使用这些功能的频率较高，要做性能测试。而高级查询、过滤器、邮件列表等功能被使用的次数较少，就可以不做性能测试，或者进行性能测试的优先级低一些。（2）对响应时间要求苛刻的如金融和电信等对实时性要求比较高的系统，比如电信系统中，从拨号到经过基站、核心网，再到被叫手机响铃，整个系统的处理时间应该在用户能接受的范围内。这些功能细分，就是性能测试中的事务(transaction)。性能测试开始的必要条件是软件系统已经处于一个比较稳定的状态，系统架构、主要代码、中间件等都不再有大的变化，否则会给性能测试带来很大的风险。性能测试方法：负载测试：负载测试指的是最常见的验证一般性能需求而进行的性能测试负载测试主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解：（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。压力测试压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。负载测试关心的是用户规则和需求，压力测试关心的是软件系统本身。并发测试验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。基准测试当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。稳定性测试测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。可恢复测试测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。提示：每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。性能测试质量度量下面是部分度量的方法：（1）性能测试耗费的资源，包括时间、人力、物力。（2）性能测试中发现的bug数目，以及各自的级别。（3）软件系统交付用户，在生产环境运行后发现的性能bug数目、级别。GAME（A）性能测试过程模型：G：Goal，目标A：Analysis，分析M：Metrics，度量E：Execution，执行（A）：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式。Goal（定义目标）制定一个明确而详细的测试目标是性能测试开始的第一步，也是性能测试成功的关键。本步骤的开始时间：需求获取阶段本步骤的输入：性能需求意向本步骤的输出：明确的性能测试目标和性能测试策略常规的性能测试目标有以下几种：（1）度量最终用户响应时间查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设我们想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。（2）定义最优的硬件配置检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，您可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。例如，您可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异：配置1：1.2GHz、1GBRAM配置2：1.2GHz、2GBRAM配置3：2.4GHz