软件接口设计原则

接口性能测试方案设计方法有哪些？要怎么去写？ 　　目录 　　一、 性能测试术语解释 　　二、 性能测试方法及目标 　　三、 性能需求分析 　　一、 性能测试术语解释 　　1. 响应时间 　　响应时间即从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。响应时间按软件的特点可以细分，比如对于一个 C/S 软件的响应时间可以细分为网络传输时间、应用服务器处理时间、数据库服务器处理时间。另外客户端自身也存在着解析时间、界面绘制呈现时间等问题。 　　响应时间主要是站在客户端角度来看的一个性能指标，它是用户最关心、并且容易感知到的一个性能指标。 　　2. 吞吐率 　　吞吐率指单位时间内系统处理用户的请求数，从业务角度看，吞吐率可以用每秒请求数、每秒事务数、每秒页面数、每秒查询数等单位来衡量。从网络角度看，吞吐率也可以用每秒字节数来衡量。 　　吞吐率主要站在服务端的角度来看的一个性能指标，它可以衡量整个系统的处理能力。对于集群或者云平台来说，吞吐率指标反映的是服务器集群对外整体能够承受的压力，该指标比用户数更容易对比。 　　备注：吞吐量 = 吞吐率 * 单位时间 　　3. 用户数 　　对于服务器集群或者云平台，几乎都是多用户系统，系统能提供给多少用户正常使用，也是一个非常重要的度量指标。我们把这些用户按照使用系统的时机不同，做如下区分。 　　系统用户数（System Users）：指系统能够存储的用户量。 　　在线用户数（Online Users）：指用户通过身份确认后，处于能正常使用状态的用户个数。 　　并发用户数（Concurrent users）：指在某个时间范围内，同时正在使用系统的用户个数。 　　严格并发用户数（Strictly the number of concurrent users）：指同一时刻都操作某个业务的用户数。 　　在性能测试过程中，我们要去模拟实际用户来发请求。但是为了让服务器产生更大的压力，我们模拟的用户操作和实际的用户操作存在一定的差异（比如模拟的用户请求比实际用户的请求更频繁），而且返种模拟的用户数和实际的用户数也难以相互换算。所以在度量服务器集群能力时，吞吐率指标比用户数指标更实用。 　　
　　二、 性能测试方法及目标 　　1. 性能测试方法 　　1.1 基准测试（Benchmark Testing） 　　基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试，目的在于量化响应时间、吞吐率的指标，便于后续比对。 　　方法是做多组不同场景的测试，观察结果，抽取出几个关键数据做好记录，用于以后进行性能对比和评价。 　　1.2 性能测试（Performance Testing） 　　通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。 　　特点： 　　（1） 主要目的是验证系统是否具有系统宣称的能力。 　　（2） 需要事先了解被测系统的典型场景，并具有确定的性能目标。 　　（3） 要求在已确定的环境下运行。 　　1.3 负载测试（Load Testing） 　　通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。 　　特点： 　　（1） 主要目的是找到系统处理能力的极限。 　　（2） 需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。 　　（3） 一般用来了解系统的性能容量，或是配合性能调优使用。 　　1.4 压力测试（Stress Testing） 　　测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。 　　特点： 　　（1） 主要目的是检查系统处于压力情况下应用的表现。 　　（2） 一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。 　　（3） 一般用于测试系统的稳定性。 　　1.5 配置测试（Configuration Testing） 　　通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。 　　特点： 　　（1） 主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。 　　（2） 一般在对系统性能状况有初步了解后进行。 　　（3） 一般用于性能调优和规划能力。 　　1.6 并发测试（Concurrency Testing） 　　通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 　　特点： 　　（1） 主要目的是发现系统中可能隐藏的并发访问时的问题。 　　（2） 主要系统可能存在的并发问题，例如系统中的内存泄露、线程锁和资源争用方面的问题。 　　（3） 可在在开发的各个阶段使用，需要相关的测试工具的配合和支持。 　　1.7 可靠性测试（Reliability Testing） 　　通过给系统加载一定的业务压力（例如资源在70%~90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。 　　特点： 　　（1） 主要目的是验证系统是否支持长期稳定的运行。 　　（2） 需要在压力下持续一段时间的运行。 　　（3） 需要系统的运行状况。 　　1.8 失效恢复测试（Failover Testing） 　　针对有冗余备份和负载均衡的系统设计的，可以用来检验如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。 　　特点： 　　（1） 主要目的是验证在局部故障的情况下，系统能否继续使用。 　　（2） 还需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。 　　（3） 一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。 　　2. 性能测试目标 　　概况来说，可分为4个方面： 　　2.1 能力验证 　　在系统测试或验收测试时，我们需要评估系统的能力，衡量系统的性能指标。系统的能力可以是容纳的并发用户数，也可能是系统的吞吐率；系统的性能指标可以是响应时间，也可以是选择 CPU、内存、磁盘、网络的使用情况。 　　特点： 　　（1） 要求在已确定的环境下进行。 　　（2） 需要根据典型场景设计测试方案和用例。 　　一般采用的方法是：性能测试、压力测试、可靠性测试、失效恢复测试。 　　2.2 能力规划 　　评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置，使得系统能够满足增长的用户数的需要。 　　特点： 　　（1） 属于一种探索性的测试 　　（2） 可被用来了解系统的性能以及获得扩展性能的方法，例如系统扩容规划。系统容量可以是用户容量，也可能是数据容量，或者是系统的吞吐量（系统的处理能力）。对于集群服务我们更多的是用吞吐率作为容量。 　　方法是①先对各子系统、组件进行性能测试，找出它们之间的最优配比；②然后再通过各环节的水平扩展，计算出整体的扩容机器配比。 　　一般采用的方法是：负载测试、压力测试、配置测试。 　　
　　2.3 性能调优 　　为了更好的发挥系统的潜能，定位系统的瓶颈，有针对性的进行系统优化。 　　方法是在进行系统调优时，我们需要做好基准测试，用以对比性能数据的变化，并反复调整系统软硬件的设置，以使系统发挥最优性能。当然在进行系统优化时，我们会选取关键的指标进行优化，返时可能要牺牲其他的性能指标。如果目标是优化响应时间，我们可能选取的策略是以空间换时间，以牺牲内存或扩大缓存为代价，还需要我们在各个性能指标中找到平衡点。 　　一般对系统的调整包括以下3个方面： 　　（1） 硬件环境的调整 　　（2） 系统设置的调整 　　（3） 应用级别的调整 　　一般采用的方法是：基准测试、负载测试、压力测试、配置测试和失效恢复测试。 　　2.4 发现缺陷 　　和其他测试一样，性能测试也可以发现缺陷。特别是严格并发访问时是否存在资源争夺导致的响应时间过慢，或大量用户访问时是否导致程序崩溃。 　　方法是设置集合点，实现严格并发用户访问；或者设置超大规模用户突发访问等这样的性能测试用例进行测试。 　　一般采用的方法是：并发测试。 　　三、 性能需求分析 　　1. 性能需求 　　1.1 功能规格说明书 　　1.2 系统设计文档 　　1.3 运营计划 　　1.4 用户行为分析记录 　　2. 性能关键点选取 　　主要从以下4个维度进行选取： 　　2.1 业务分析 　　确定被测接口是否属于关键业务接口或先分析出关键业务以及该业务所访问的接口。 　　2.2 统计分析 　　若接口系统访问行为存在日志分析记录，则直接访问量高的接口；否则根据接口发布类型，选择第3方日志分析工具间接。 　　（1） IIS日志分析工具：Log Parser 2.2 + Log Parser Lizard GUI 　　下载地址： 　　http://www.lizard-labs.com/log_parser_lizard.aspx 　　（2） Tomcat日志分析工具：AWStats v7.3 　　下载地址：http://www.awstats.org 　　（3） Nginx日志分析工具：GoAccess v0.9 　　若IIS或Tomcat等接口应用服务器使用Nginx进行负载，则日志访问量要以负载为准，因避免接口在Nginx设置缓存（即未进行透传）而导致统计不正确。 　　下载地址：http://www.goaccess.io 　　2.3 技术分析 　　（1） 逻辑实现复杂度高的接口（如判断分支过多或涉及CPU/IO密集型运算等） 　　（2） 对系统（内存、CPU、磁盘IO）及网络IO等硬件资源耗用高的接口 　　备注：若接口因逻辑修改而重构，则需重新分析。 　　2.4 运营分析 　　由于运营推广活动导致日访问突增高的接口。 　　备注：若运营计划调整，则需重新分析。 　　3. 性能指标描述 　　3.1 响应时间 　　在一般情况下，弱交互类接口平均响应时间不超过1秒，强交互类接口平均响应时间不超过200毫秒。 　　3.2 成功率 　　在一般情况下，接口响应成功率需达到99.99%以上。 　　3.3 系统资源 　　若为最佳负载，则系统CPU及内存使用率建议区间[50%，80%]，否则建议不超过50%。 　　3.4 处理能力 　　立项申请书明确要求：在XX压力下（并发数）TPS需达到XX或 接口系统可支撑XX万实时在线访问。 　　3.5 稳定性 　　在实际系统运行压力情况下，可稳定运行N*24(一般 N >= 7 )小时。 在高于实际系统运行压力1倍的情况下，可稳定运行12小时。 　　3.6 特性指标 　　例：Java类应用 FullGC 次数 <= 1次/天 　　感谢每一个认真阅读我文章的人！！！ 　　我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。欢迎大家下方名片加入群聊与我一起学习交流，如果在学习或工作中遇到问题可以直接进群询问，群里也会有大神帮忙解答。