功能测试与性能测试的区别
功能测试主要根据产品业务需求、产品行业特征、模拟用户操作方式来测试一个产品的特性以确定它们是否满足用户需求。
性能测试则是通过某种特定的方式对被测系统按照一定的测试策略进行施压，获取该系统的响应时间、运行 效率。资源利用情况等各项性能指标，来评价系统是否满足用户性能需求的过程。
通俗的说，功能测试用于确保软件系统做了正确的事情，性能测试则用于确保软件系统快速地完成任务。
如何理解软件性能
1.系统管理员眼中的软件性能
系统管理员作为系统软件的管理者，主要关注服务器的资源使用情况、系统的可扩展性、系统的最大支持用户量、系统的稳定性，以及系统可能出现的瓶颈、出现异常的情况下如何处理
2.研发人员眼中的软件性能
作为研发人员，主要关注软件系统架构的合理性、数据库的设计是否存在问题、代码是否存在性能方面的问题、内存使用方式是否正确、线程同步方式是否合理、是否存在不合理的资源竞争。
3.测试人员眼中的软件性能
测试人员是质量的把关者，在软件性能生命周期中占据至关重要的位置，软件性能测试工程师要对性能问题进行监控、分析及模拟实际使用过程中所出现的性能问题。还要跟各个角色做好沟通工作，对测试出的各种性能问题，要提供充分有力的数据，为后续的分析和定位性能问题、性能优化工作做好充分准备。
软件性能的生命周期
1.需求阶段的性能分析
在软件开发前期的需求分析阶段，需求分析师与客户业务人员沟通时，要明确提出各项性能指标，包括系统业务交易的使用频度、系统并发用户数、业务数据量评估等各项指标。然后对系统的响应时间、用户数和资源使用进行分析。
2.设计开发阶段的性能分析与验证
在设计阶段需要根据需求分析及设计规划，进行系统的规模分析和完整的性能分析，预估性能瓶颈点，提出解决方案，最后架构师、程序设计人员等角色进行评审验证并确认，保障性能目标的达成。
在开发阶段，需要根据设计方案，关注性能瓶颈点，进行相应的白盒测试，通过代码分析和评审的手段，确认性能瓶颈并解决，需要不断地分析和总结性能问题和解决方案，形成性能方面的代码编写规范，从而在研发阶段的早期就能确保把软件系统在性能方面的风险降到最低。
3 系统测试阶段的性能验证和分析
性能测试大致可分为单元性能测试、集成性能测试、系统性能测试、多套系统互联接口性能测试等。其中，系统性能测试是最常用、最为测试人员所熟悉的一种性能测试。
系统性能测试阶段过程：在系统功能被确认后，模拟真实生产环境进行软件系统的部署（包括硬件设备、操作系统、 络搭建、负载均衡部署、中间件部署、数据库部署等），然后根据前期的性能测试需求分析结果及测试策略定义的方法，模拟一定量的虚拟并发用户数，进行压力测试，同时监控分析系统是否满足预期的性能指标，识别性能可能出现的瓶颈点（应用代码、 络设备、硬件设备、操作系统、中间件配置、数据库等），并进行性能优化处理。调优后再进行复测，确保软件系统最终达到性能要求。
什么是性能测试
是不断的通过不同场景的系统表现去探究系统设计与资源消耗之间的平衡。
我们可以认为性能测试是：通过在测试环境下对系统或构件的性能进行探测，用以验证在生产环境下系统性能是否达到预估的性能需求，发现系统可能存在的性能瓶颈，进而改善优化并系统的性能，提高系统的可扩展性、稳定性。
从上面的描述可以看出，性能测试的主要工作包括：获得预估的性能需求、搭建测试环境、执行测试、分析测试结果。其中，最为重要两个工作是确定测试的目的、方案，并对结果进行分析。
性能测试的目的
验证系统是否满足预期需求;
验证系统在高压下的表现;
验证系统是否能持续稳定的运行;
探测系统的瓶颈和产生瓶颈的原因;
探测系统设计与资源之间的最佳平衡，改善并优化系统的性能。
如何做性能测试
1. 负载测试： 找到系统稳定时（或满足性能需求下）的最大吞吐量；（要有响应时间、成功率的限制，比如定义：99.9%的响应时间必须在1ms之内，平均响应时间在1ms以内，100%的请求成功）
2. 稳定性（通过浸泡测试soak test）： 以系统稳定时的最大吞吐量（或满足性能需求时的最大吞吐量），长时间对系统进行测试，以检查系统是否稳定
3. 压力测试： 找到系统极限值，系统瓶颈（系统崩溃临界值）（要求：响应时间可以变慢，但系统不能崩溃；）
（根据测试目的，选择是进行负载、压力、稳定性还是几种测试；）
4. 并发有两个概念：
多个用户同时进行相同操作，访问同一接口——单个业务接口并发；
多个用户同时访问系统，但进行不同的操作，访问不同的接口——系统级并发；
（在性能测试过程中，根据 具体场景和业务 选择合适的方案，一般第2种更符合实际场景。以上2种都需要进行测试；）
5. 测试流程： 确定测试目的与需求——根据需求与场景，梳理测试要点——根据测试目的，制定测试方案——准备测试环境与数据——测试执行（脚本或工具）——统计测试结果——分析结果——测试 告
PS：
1 .测试执行时，执行多次，取平均结果更为准确。
2. 单机并发不够时，采用多机分布式并发；
3. 测试过程，一定要尽可能模拟实际应用场景；
性能测试关注的指标
测试人员关注（单次业务相关指标）：
并发用户数
响应时间：TP（百分比分布统计）
吞吐量：tps/qps
成功率
失败率
开发人员关注（系统层面指标）：
1. Tomcat、数据库等；
2. 容量：系统能承载的最大访问量是多少？系统最大的业务处理量是多少？
3. 稳定性：是否支持7*24小时（一周）的业务访问？
运维人员关注（硬件资源相关指标 ）：
硬件资源消耗情况：CPU、内存、I/O读写速度、 络带宽等
性能结果分析
以下相关指标分析时需注意：
响应时间不要光看平均值，平均值不靠谱。要求最好定成：99.9%请求必须
响应时间要和吞吐量TPS/QPS挂钩；
系统的性能如果只看吞吐量，不看响应时间是没有意义的。我的系统可以顶10万请求，但是响应时间已经到了5秒钟，这样的系统已经不可用了，这样的吞吐量也是没有意义的。
当并发量（吞吐量）上涨的时候，系统会变得越来越不稳定，响应时间的波动也会越来越大，响应时间也会变得越来越慢，而吞吐率也越来越上不去（如上图所示），包括CPU的使用率情况也会如此。所以，当系统变得不稳定的时候，吞吐量已经没有意义了。吞吐量有意义的时候仅当系统稳定的时候。
所以，吞吐量的值必须有响应时间来卡。比如：TP99小于100ms的时候，系统可以承载的最大并发数是1000qps。这意味着，我们要不断的在不同的并发数上测试，以找到软件的最稳定时的最大吞吐量。
3. 响应时间吞吐量要和成功率挂钩
如果请求可以并发10w，但是成功率只有40%，那也没什么用。性能测试的失败率的容忍应该是非常低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊。
4. CPU、内存等硬件资源占比持续超过90%，说明性能存在瓶颈；
5. 带宽波动起伏很大，说明带宽受限；
术语
1. 响应时间
响应时间：“客户端呈现数据时间”+ 络传输时间+系统响应时间
响应时间受 络带宽、用户数、提交事务请求数和事务类型等的影响。
2. 并发用户数
指多个用户同时进行某一个业务交易的动作行为
3. 吞吐量
指单位时间内系统处理的客户请求数量。吞吐量是用来测量系统完成的工作量。
4. TPS（Transaction Second）
即每秒系统能够处理的交易或事务数量。它是衡量系统处理能力的重要指标。
5. 点击率
点击率即每秒用户向服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标。
“不成文”的性能需求定义
0.1-0.2s：用户认为得到的是即时的响应；
1-5s：能感觉到与信息的互动是基本畅通的。用户注意到了延迟，但是能感觉到计算机是按照指令正在“工作”中；
8s以上：用户会关注对话框。需要带有任务完成百分比的进度条或其他提示信息，在这长的等待时间后，用户的思维可能需要一定的时间来返回并继续刚才的任务，重新熟悉和适应任务，因此工作效率受到了影响；
调查表明：
在5秒内响应并呈现给用户的页面，用户会认为是最好的响应速度；
6~10秒，用户会认为是一般的响应速度；
超过10秒，用户会认为是差的响应速度
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！