软件性能测试流程

软件性能测试过程，写作目的。本文从性能工程的角度提出了性能测试的过程和策略。接下来，我们将讨论在性能工程的需求阶段、设计阶段、实施阶段、产品部署阶段和维护阶段要执行的工作，以及要采用的相应策略。我目前正在调查的项目是一个内部网网站，包括：新闻、公告、上传和下载材料、视频播放、信息、投票和特殊事件。背景包括：用户管理、权限管理、布局设置和系统设置。对于投票，省市用户将被要求在一定时间内投票。我想问用户的是：1)估计有多少人在线访问网站，有多少人同时在线；2)功能的系统响应时间的可接受范围；3)系统支持的最大吞吐量是多少；4)用户经常使用的功能模块有哪些；5)用户常用的场景操作是什么；6)网站的高峰时间是什么时候？您为什么要执行性能测试？性能测试致力于降低应用程序、升级或修补程序部署中的风险。性能测试的核心原则是通过将生产过程中的工作负载应用于系统的部署来衡量系统性能和最终用户体验。结构良好的性能测试可以回答以下问题：应用程序能快速响应用户的需求吗？应用程序能否处理预期的用户负载并拥有剩余容量？应用程序能否处理业务所需的交易数量？在预期和意外的用户负载下，应用程序是否稳定？当用户实际使用软件时，是否有可能确保他们获得积极的体验？通过回答上述问题，性能测试可以量化不断变化的业务指标的影响。这反过来说明了部署的风险。一个有效的性能测试过程将帮助你做出更明智的发布决定，防止系统故障和解决可用性问题。性能测试通常包括五个阶段：测试计划、脚本创建、场景定义、场景操作和结果分析。测试计划：定义性能测试需求，例如并发用户的数量、典型的业务流程和所需的响应时间。脚本创建：将最终用户活动捕获到Vuser自动脚本中。场景定义：使用LoadRunnerController设置一个性能测试环境。场景运行：通过LoadRunnerController驱动、管理和监控性能测试。结果分析：使用LoadRunnerAnalysis创建图表和报告，并评估性能。性能测试问题及其相应的人员、性能测试需求的来源和性能测试需求的来源有三个方面：需求文档设计文档与客户沟通以确定性能测试需求的解决方案。在没有需求文档和设计文档的情况下，我们需要分析客户的业务使用情况，提出我们关心的性能测试需求，并通知业务人员。让业务人员判断我们的绩效要求是否能满足客户的真实需求。1。确定当前系统的业务使用情况：通过记录客户模块的使用情况，我们可以知道客户在一定时间内执行操作的具体情况。2.从不同角度理解用户性能：I)用户角度：响应时间：用户能够感受到的响应时间也是用户最重视的性能体验。建立响应时间原则：2/5/10原则2: 2秒用户会觉得这是一个很好的体验。在5: 5秒时，用户可能会觉得有一点点不同，好吧，更好。10: 10秒是用户能承受的最大限度。鉴于不同地区的网络环境，用户可以承受的响应时间限制为12-15秒。这部分需要与业务人员讨论。稳定性：系统长时间无错误运行的能力。验证方法：如果系统满负荷运行8小时，无论服务是否不可用，都会出现连接拒绝404，500错误。二)系统角度：延迟，系统资源使用延迟：包括数据库延迟和网络延迟。这部分需要与数据库管理员和系统部门人员讨论。系统资源使用率：服务器的CPU使用率是否为h内存使用量是只有几兆还是几十兆。三)开发人员的观点：从代码实现和数据库实现的角度考虑性能。看看这两个方面是否实现得足够好。3.了解真正的性能测试需求：I)确定项目的利益相关者：参考与项目相关的人员、开发人员、设计人员、需求者、业务人员和高层领导，了解他们对性能测试的考虑。(二)隐藏在“性能测试”背后的实际想法，例如：因为开发人员对完成的代码没有信心，不愿意进行修改，要求我们对他们所做的程序进行性能测试，或者因为设计人员使用了新技术，并且不低心，以及要求的性能测试等。建立性能测试目标。1.以“需求”为基础考虑系统是否需要测试以及性能测试的内容和范围。2.确定测试目标的经济考虑I)性能测试涉及多少人员？二)有多少人可以确定性能测试要求和制定性能测试计划？有多少人可以执行性能测试？Iii)这些人员需要投资多长时间？Iv)待开发系统的运行环境和设备，以及这些设备的配置对性能测试的影响，例如：对于tomcat4.1的应用服务器，jvm在其配置文件中的默认使用空间为64M，一台机器的内存为1G。我们将jvm的使用空间设置为512M，以影响性能测试。)内部人员不能满足性能测试要求。公司通过外部雇佣能负担多少？3.基于风险的测试目标决定了)如果系统不进行性能测试，会有什么风险，如果不能满足用户对性能指标的要求，会有什么风险。需要评估。二)如果进行了性能测试，将涉及多少风险、将进行多少投资以及需要评估多少风险。为了确定性能测试目标，我们需要确定系统的吞吐量和并发用户的数量。设计目标可以采用以下三种方式：确定在特定时间内有多少系统用户同时访问系统，以及访问系统的用户的典型操作是什么？哪个页面流量最大？系统在特定时间需要处理多少种用户场景？这些数据可以在系统服务器的日志文件中找到，也可以通过监控数据库的活动来获得。不同阶段的性能测试目标、设计阶段的性能测试目标、设计阶段的性能测试目标是调查系统是否满足预期的性能要求。开发阶段的性能测试目标1)将开发阶段的性能测试目标作为系统调优的参考：考虑每个开发阶段的性能是否能够达到标准，考虑当前阶段的性能瓶颈，以及性能瓶颈的原因是否在于数据库访问(SQL语句或存储过程写得不好)或其他原因。二)通过性能测试发现系统中存在的问题：通过模拟真实场景，可以发现现场测试中可能存在的问题，如：用户数量的突然增加，导致应用程序崩溃和服务器崩溃。产品部署阶段的性能测试目标为部署计划提供了参考，并确定了合适的硬件设备。虽然较高的设备可以获得商业利益，但应考虑客户的具体情况。系统维护阶段的性能测试目标是检查系统的可伸缩性：从系统的角度来看，当用户数量增加、业务量增加时，性能如何。性能测试计划的建立，性能测试计划建立前需要做的工作1。确定测试目标和要求的灵活性相对较大，并且与性能测试的成败有很大关系。2、了解现状)通过日志记录了解业务使用情况，在一定时间内，用户的操作情况。二)了解环境：包括网络条件、服务器条件、软硬件条件、应用服务器环境3.确定需要监控的指标：1)CPU利用率2)内存使用率。这里，应该优先监控应用服务器的性能指标。对于Tomcat或Weblogic，监视诸如JVM使用、连接池号、内存使用等信息。对于数据库，监视缓存命中率、索引使用情况和数据库连接数。用例和场景设计，用例和场景设计步骤：1。业务分析和分解；2.用例是根据业务确定的；3.根据不同的发生比例，不同的用例被分组到场景中；4.理解每个场景的实际含义(对场景进行测试并收集结果)；5.了解业务分布；根据业务确定用例；在设计用例时，根据前期收集的数据设计不同的场景形成用例；理解每个场景的实际含义，执行场景并收集结果数据。设置要监控的资源，设置要监控的资源主要有以下几个方面：1 .CPU利用率2。内存使用3。数据库监控4。JVM使用监控应该优先监控应用服务器的性能指标。对于Tomcat或Weblogic，监视诸如JVM使用、连接池号、内存使用等信息。对于数据库，缓存命中率、索引使用、数据库连接数和特定的监控指标应该由性能测试工程师根据性能要求来确定。系统性能测试的主要应用领域是验证能力和性能调整。1.验证能力包括：I)验证新系统以及新架构是否能满足用户需求。二)向用户提供性能测试报告，表明系统的性能满足预期的设计标准。三)确定新平台的产品架构，假设以前使用过ASP。net，或者使用j2ee平台来验证新的系统架构是否满足性能要求。这个需求不是由用户提出的，也不是由用户直接体验的，而是在架构设计过程中确定的一个指标。2.性能调优在系统开发的过程中，通过性能测试，我们可以了解当前系统的瓶颈(例如，数据库访问、SQL语句或存储过程写得不好，或者数据库设计做得不好，索引做得不好)。所选应用服务器存在问题，或者代码层、业务逻辑没有很好地实现，导致其性能缺陷。确保问题发生在应用层、数据库层和代码层。在实施阶段，影响性能的因素将按照以下顺序进行判断：1 .网络状况2。硬件设备3。系统/应用服务器/数据库配置4。数据库设计和数据库访问实现。业务程序实现，但在开发阶段优化性能时注意的顺序是：请多注意SQL级别和代码级别。对于实际在线运行的系统，请直接按照以上5点的顺序进行操作。注意：许多性能问题是由于应用服务器的不合理配置造成的。例如，tomcat4.1应用程序服务器没有修改其配置文件中的默认jvm使用空间。设计阶段性能测试的主要目的是验证您的体系结构。有两种方法可以验证：1 .如果系统架构有预期的性能目标，请验证当前架构是否能够满足预期的性能目标。2.系统架构是在先前架构的基础上修改的。进行了一项对比测试，以了解这两种体系结构的优势。实施阶段的性能测试实施阶段的性能测试的目的是定期验证系统性能，执行性能调整，并通过系统调整发现系统缺陷。产品部署阶段的性能测试在产品部署阶段，性能测试被视为验收测试的一部分。维护阶段的性能测试在维护阶段检查系统的可扩展性/定位系统的缺陷，并检查系统的可扩展性以定位系统的缺陷。系统稳定性的测量，为了验证系统的稳定性，我们需要对系统进行可靠性测量。在没有任何行业或国际标准来进行可靠性测量的情况下，我们无法获得准确的用户要求(用户无法提供系统稳定性的定量标准)。我们可以用以下方法来验证系统的稳定性。通过在性能测试期间获得系统稳定性数据来验证系统的稳定性：系统运行很长时间，观察其可用内存，以查看cpu利用率是否有任何显著变化。如果在长期使用过程中，cpu和内存没有显著变化，则可以认为系统是稳定的。响应时间：客户端从发送请求到收到应用程序响应的最后一个字节的时间长度。2.点击次数：对每个对象的请求，例如，一个页面由五部分组成，一个框架和四张图片，这被算作五次点击。3.页面请求：已经请求了一个页面，不管它包含多少对象。4.吞吐量：I)根据流量计算的吞吐量，用于衡量网络状况或应用服务器的处理能力。在指定的一段时间内，每秒钟进出的字节数。ii)通过点击次数来衡量吞吐量，在银行系统中使用每个固定时间段内的点击次数。5.并发用户：业务并发：200人同时在线。服务器并发：200个人同时向服务器发送请求。200个人同时进行提交操作，服务器收到多少请求。6.资源利用率：cpu利用率、内存利用率、磁盘输入输出状态等。性能测试中需要注意的问题，1。环境设计问题，2。其他需要注意的问题，环境设计问题，1。网络环境2、软件和硬件环境3、环境维护方案4、时间同步问题5和“镜像”环境时间同步问题：不同的服务器部署在不同的机器上。分析性能测试的响应时间时需要时间同步。时间通过日志进行比较，但是本地时间记录在日志中，这使得日志中记录的时间具有可比性，并且需要时间同步。同步方法：在UNIX操作系统上可以使用NTP协议进行时间同步，在windows系统上可以添加域进行时间同步。“镜像”环境的问题：当测试能力验证时，通常要求在现场进行，因为测试结果与应用服务器网络环境本身有很大关系。如果无法进行现场测试，则采用两种解决方案：1)尽可能模拟用户环境：包括网络条件和服务器条件；ii)与用户协商：进行现场测试。其他地方要注意，1。应用服务器的预热问题J2ee应用程序或。net应用程序现在将涉及本地编译过程。在第一次跑步中，第一次跑步的速度会很慢，第二次会更快。因为信息是从本地缓存中读取的，所以在应用服务器重新启动后，必须对其进行多次测试，然后在服务器预热后进行测试。否则，以前的结果无效。整个结果会有错误。2.在许多测试过程中，应用服务器的缓存功能被删除，或者缓存被清空。3.记录脚本时，应删除浏览器或客户端应用程序的缓存客户端和浏览器的缓存。确定最小用户负载的目的是充分掌握应用程序的性能不仅是在巨大的压力下，而且是在更理想的条件下。这很重要，因为应用程序通常在这些低负载条件下花费大部分时间。高峰操作通常很少见。确定最小用户负载的方法是从需求出发解决问题，了解服务分布，将服务分布划分为不同的场景，确定负载使用最小的场景。执行此场景并观察系统在此场景下的操作。性能测试的两个基本类别，初步测试初步测试：初步探索性测试，它使我们能够感受应用程序的性能并优化测试环境。正式测试有四个正式的性能度量，我们的分析基于这些度量。这些正式测试可以按类型分为以下几个子类：单实例压力测试、持久测试和架构测试。环境和测试参数(测试脚本、思考时间、采样方法等。)是根据初步测试结果设置的，对于任何特定的性能测试，这些因素必须保持不变。如果在特定的性能测试中修改了任何参数，我们将会破坏结果的可比性，并且必须重新执行测试。性能测