通常大家做web 应用程序的时候会有哪些操作呢？今天就来看看常见的web 应用程序的常见操作。
Web 应用程序性能测试核心步骤
1：识别测试环境。确定物理测试环境和生产环境，以及测试团队可用的工具和资源。物理环境包括硬件、软件和网络配置。在一开始就对整个测试环境有一个彻底的理解，可以使测试设计和计划更有效，并帮助您在项目早期识别测试挑战。在某些情况下，这个过程必须在整个项目生命周期中周期性地重新审视。
2：确定性能验收标准。确定响应时间、吞吐量和资源利用目标和约束。通常，响应时间是用户关注的问题，吞吐量是业务关注的问题，而资源利用是系统关注的问题。此外，确定那些目标和约束可能无法捕捉到的项目成功标准;例如，使用性能测试来评估哪种配置设置组合将产生最理想的性能特征。
3：计划和设计测试。确定关键场景，确定代表性用户之间的可变性，以及如何模拟可变性，定义测试数据，并建立要收集的度量标准。将这些信息整合到一个或多个要实现、执行和分析的系统使用模型中。
4：配置测试环境。准备好测试环境、工具和必要的资源，以便在特性和组件可用于测试时执行每个策略。确保测试环境在必要时用于资源监控。
5：实施测试设计。根据测试设计开发性能测试。
6：执行测试。运行和监视测试。验证测试、测试数据和结果收集。在监视测试和测试环境的同时，执行已验证的测试以进行分析。
7：分析结果，报告，并重新测试。合并和共享结果数据。单独或作为跨职能团队分析数据。重新确定其余测试的优先级，并根据需要重新执行它们。当所有的度量值都在可接受的范围内，没有违反设置的阈值，并且收集了所有所需的信息时，您就已经在特定配置上完成了特定场景的测试。
接下来详细分析这些操作步骤
一：识别测试环境
执行性能测试的环境，以及执行性能测试所需的工具和相关硬件，构成了测试环境。在理想情况下，如果目标是确定生产应用程序的性能特征，那么测试环境是生产环境的精确复制，但是增加了负载生成和资源监视工具。生产环境的精确复制并不常见。
在决定执行什么性能测试和测试多大负载时，测试条件下应用程序的硬件、软件和网络配置与实际生产条件下的相似程度通常是一个重要的考虑因素。重要的是要记住，影响性能测试的不仅仅是物理和软件环境，还有测试本身的目标。通常，性能测试应用于提议的新硬件基础结构，以验证新硬件将解决现有性能问题的假设。
识别测试环境的关键因素是完全理解测试环境和生产环境之间的相似点和不同点。需要考虑的关键因素有
硬件
配置
机器硬件(处理器、RAM等)
网络
网络架构和最终用户位置
负载平衡的影响
集群和DNS配置
工具
负载生成工具的限制
环境影响监测工具
软件
在共享或虚拟环境中安装或运行的其他软件
软件许可限制或差异
存储容量和种子数据量
日志级别
外部因素
网络中附加流量的数量和类型
计划或批处理、更新或备份
与其他系统的交互
注意事项
在描述测试环境时，考虑以下关键点:
尽管很少有性能测试人员会安装、配置和管理被测试的应用程序，但是对于测试人员来说，访问服务器和软件或访问管理员是有益的。
确定应用程序必须使用的数据量和类型，以模拟实际情况。
识别关键的系统组件。是否有任何系统组件存在已知的性能问题?是否存在超出您测试控制范围的集成点?
结识IT人员。您可能需要它们的支持来执行一些任务，例如监视整体网络流量和配置负载生成工具以模拟实际数量的Internet Protocol (IP)地址。
检查负载均衡器的配置。
使用DNS验证名称解析。这可能会导致打开数据库连接时出现明显的延迟。
验证防火墙、DNS、路由等对生成的负载的处理是否与通常在生产环境中遇到的负载类似。
让系统管理员在测试环境中设置资源监控软件、诊断工具和其他实用程序通常是合适的。
二：确定性能验收标准
在开发生命周期的早期开始确定应用程序所需的性能特征通常是有意义的。要做到这一点，最简单的方法就是注意用户和涉众将性能特征等同于良好的性能。这些注释可以在以后进行量化。
经常与用户或涉众的满意度相关的特征类别通常包括:
响应时间。例如，产品目录必须在3秒内显示。
吞吐量。例如，系统必须支持每秒25个图书订单。
资源利用率。例如，处理器利用率不超过75%。设置目标时需要考虑的其他重要资源是内存、磁盘输入/输出(I/O)和网络I/O。
注意事项
在确定性能标准时，应考虑以下要点:
业务需求
用户期望
合同义务
法规遵从性标准和行业标准
服务水平协议
资源利用目标
各种各样的、现实的工作负载模型
预期负载条件的整个范围
系统应力条件
整个场景和组件活动
主要绩效指标
应用程序的以前版本
竞争对手的应用程序
优化目标
安全因素、增长空间和可伸缩性
时间表，人员配备，预算，资源和其他优先事项
三：计划和设计测试
计划和设计性能测试包括识别关键的使用场景，确定用户之间的适当可变性，识别和生成测试数据，以及指定要收集的度量。最终，这些项目将为工作负载和工作负载概要文件提供基础。
当以描述生产性能为目的设计和计划测试时，您的目标应该是创建真实世界的模拟，以便提供可靠的数据，使您的组织能够做出明智的业务决策。真实世界的测试设计将显著增加结果数据的相关性和有用性。
应用程序的关键使用场景通常在确定应用程序所需的性能特征的过程中浮出水面。如果您的测试项目不是这样，您将需要显式地确定对脚本最有价值的使用场景。在确定关键使用场景时，请考虑以下因素:
合同约定的使用场景
性能测试目标所暗示或强制的使用场景
最常见的使用场景
关键业务使用场景
性能密集型使用场景
技术关注的使用场景
涉众关注的使用场景
高可视性使用场景
当正确地识别、捕获和报告指标时，指标将提供有关应用程序性能与所需性能特征之间的比较情况的信息。此外，度量可以帮助您确定应用程序中的问题区域和瓶颈。
在测试设计期间识别与性能验收标准相关的度量标准是有用的，这样在实现测试设计时，收集这些度量标准的方法可以集成到测试中。在确定度量时，使用特定的期望特征或与这些特征直接或间接相关的指标。
注意事项
在计划和设计测试时，请考虑以下要点:
现实的测试设计对系统控制之外的依赖关系非常敏感，例如人、网络活动和与应用程序交互的其他系统。
现实的测试设计是基于你期望在现实世界中发现的东西，而不是理论或预测。
现实的测试设计产生更可信的结果，从而提高性能测试的价值。
组件级性能测试是实际测试的组成部分。
实际的测试设计实现起来可能更加昂贵和耗时，但是它们为业务和涉众提供了更高的准确性。
从不现实的测试中推断性能结果会随着系统范围的增加而产生破坏性的不准确性，并且经常导致糟糕的决策。
让开发人员和管理员参与到确定哪些指标可能增加价值的过程中，以及哪种方法最好地将这些指标的捕获集成到测试中。
小心让您的工具影响您的测试设计。更好的测试几乎总是基于可以执行的假设来设计测试，然后在这个假设被证明是错误的时候调整测试或工具，而不是基于您没有访问工具来执行测试的假设而不设计特定的测试。
真实的测试设计包括:
逼真地模拟用户延迟和思考时间，这对测试的准确性至关重要。
用户放弃，如果用户可能出于任何原因放弃任务。
常见的用户错误。
四：配置测试环境
在特性和组件可用于测试之前，为测试设计实现和测试执行准备好测试环境、工具和资源，可以显著增加在这些特性和组件可用期间可以完成的测试量。
负载生成和应用程序监视工具的启动和运行几乎不像人们期望的那样容易。无论问题是由于设置孤立的网络环境、购买硬件、协调用于IP欺骗的专用IP地址库，还是监控软件和服务器操作系统之间的版本兼容性，问题似乎总是从某个地方产生的。尽早开始，以确保在开始测试之前问题已经解决。
此外，计划在整个项目中定期重新配置、更新、添加或以其他方式增强负载生成环境和相关工具。即使被测试的应用程序保持不变，负载生成工具正常工作，您希望收集的指标也可能会发生变化。这通常意味着对监视工具进行某种程度的更改或添加。
注意事项
在配置测试环境时，请考虑以下关键点:
确定在负载生成器达到瓶颈之前可以生成多少负载。通常，负载生成器首先在内存中遇到瓶颈，然后在处理器中遇到瓶颈。
虽然这看起来像是一种常识性的实践，但验证系统时钟在收集资源数据的所有机器上都是同步的是很重要的。这样做可以节省大量的时间，并防止您不得不完全处理数据，并在同步系统时钟后重复测试。
验证硬件组件(如交换机和网卡)负载测试执行的准确性。例如，全双工模式运行正确，用户时延和带宽仿真正确。
验证与负载均衡配置中的服务器集群相关的负载测试执行的准确性。考虑使用负载测试技术，以避免由于客户端和服务器使用相同的IP地址而导致的相关性。大多数负载生成工具提供了跨负载测试生成器模拟不同IP地址使用的能力。
在负载测试期间，在负载均衡配置的服务器之间监视资源利用率(CPU、网络、内存、磁盘和每次的事务)，以验证负载是分布的。
五：实施测试设计
创建可执行性能测试的细节是非常特定于工具的。无论您使用的工具是什么，创建性能测试通常都涉及到编写单个使用场景的脚本，然后增强该场景，并将其与其他场景结合起来，以最终表示完整的工作负载模型。
负载生成工具不可避免地落后于不断发展的技术和实践。工具创建者只能构建对最突出的技术的支持，即使这样，在构建支持之前，这些技术必须变得突出。这通常意味着性能测试项目所涉及的最大挑战是实现第一个相对真实的测试，通常以这样一种方式模拟用户，即被测试的应用程序无法合理地区分模拟用户和真实用户。为此做好计划，当它花费的时间比预期的要长很多时，不要感到惊讶。
注意事项
在实施测试设计时，考虑以下关键点:
确保正确地实现测试数据提要。测试数据提要是数据库、文本文件、内存变量或电子表格形式的数据存储库，用于在负载测试期间模拟参数替换。例如，即使应用程序数据库测试存储库包含完整的产品集，您的负载测试可能只需要模拟用户由于涉及新产品或营销活动的场景而购买的产品的子集。测试数据提要可能是生产数据存储库的一个子集。
确保在数据库和其他应用程序组件中正确实现应用程序数据提要。应用程序数据提要是被测试的应用程序所使用的数据存储库，例如产品或订单数据库。由负载测试脚本运行的关键用户场景可能使用此数据的子集。
确保正确地实现了事务验证。Web服务器报告了许多事务成功，但是它们不能正确地完成。验证的例子有，插入的数据库条目行数正确，返回的产品信息，以html数据形式返回给客户端的正确内容等等。
确保正确处理隐藏字段或其他特殊数据。这是指Web服务器返回的需要在后续请求中重新提交的数据，如会话ID或产品ID，在将其传递给下一个请求之前需要递增。
验证关键性能指标(kpi)的监控。
增加相关指标，以方便明确业务表现。
如果请求接受参数，请确保参数数据正确地填充了变量和/或唯一数据，以避免任何服务器端缓存。
如果该工具不能自动执行此操作，请考虑在测试脚本中为请求添加包装器，以测量请求响应时间。
通常值得花时间使脚本与设计的测试相匹配，而不是更改设计的测试以节省编写脚本的时间。
为了测试或验证脚本开发，可以根据预期评估从执行的测试中收集的输出数据，从而获得重要的价值。
六：执行测试
执行测试是大多数人在考虑性能测试时所设想的。测试执行的过程、流和技术细节非常依赖于您的工具、环境和项目上下文，这是有意义的。即便如此，在执行测试时，仍有一些相当普遍的任务和注意事项需要牢记。
目前可用的许多与性能测试相关的培训都将测试执行视为启动测试并监视它以确保测试看起来像预期的那样运行。实际上，这项活动远比单击一个按钮并监视机器要复杂得多。
测试执行可以被看作是以下子任务的组合:
与团队协调测试执行和监控。
验证测试、配置以及环境和数据的状态。
开始测试执行。
在测试运行时，监视并验证脚本、系统和数据。
在测试完成后，快速检查测试结果，以发现测试有缺陷的明显迹象。
存档测试、测试数据、结果和其他必要的信息，以便稍后在需要时重复测试。
记录开始和结束时间、结果数据的名称，等等。这将允许您在测试完成后按顺序识别您的数据。
当您准备开始测试执行时，值得花时间仔细检查以下项目:
验证测试环境是否与您所期望的和/或为其设计测试的配置相匹配。
确保测试和测试环境都为度量收集正确地配置了。
在运行实际测试之前，执行一个快速烟雾测试，以确保测试脚本和远程性能计数器正常工作。在性能测试的上下文中，烟雾测试的目的是确定应用程序是否能够在短时间内在正常负载条件下成功地执行其所有操作。
重置系统(除非您的场景需要这样做)并开始正式的测试执行。
确保测试脚本的执行代表了您想要模拟的工作负载模型。
确保将测试配置为收集此时感兴趣的关键性能和业务指标。
注意事项
在执行测试时，请考虑以下要点:
验证数据更新的测试执行，例如已经完成的数据库中的订单。
验证负载测试脚本是否使用了正确的数据值，例如产品和订单标识符，以便真实地模拟业务场景。
只要可能，将每个测试执行周期限制在1到2天。在每个周期结束后回顾并重新调整优先级。
如果可能的话，将每个测试执行三次。请注意，加载动态链接库(Dynamic-Link Libraries, dll)、填充服务器端缓存或初始化被测代码所需的脚本和其他资源都会影响首次测试的结果。如果第二次和第三次迭代的结果不是高度相似，那么再次执行测试。试着确定是什么因素造成了这种差异。
在执行过程中观察您的测试，并密切注意您觉得不寻常的任何行为。你的直觉通常是正确的，或者至少是有价值的指标。
如果您使用的是共享的测试环境，那么无论您计划多早进行测试，在启动测试(或开始当天的测试)之前，都要给团队30分钟和5分钟的警告。此外，当你连续执行任务的时间不超过一个小时时，要通知团队，这样你就不会妨碍他们完成任务。
在生成负载时，不要在负载生成机器上处理数据、编写报告或绘制图表，因为这可能会影响测试结果。
在测试期间关闭负载生成机器上的任何活动病毒扫描，以最大限度地减少无意中扭曲测试结果的可能性。
在生成负载时，在测试执行期间从负载生成环境之外的机器手动访问系统，这样您就可以在稍后的时间将您的观察结果与结果数据进行比较。
记住要适当地模拟加速和冷却阶段。
不要因为应用程序脚本编译、Web服务器缓存构建或其他类似原因而放弃第一次迭代。相反，单独测量这个迭代，这样您就可以知道在系统范围内重新启动后的第一个用户可以期望什么。
测试执行永远不会真正结束，但最终您将达到特定测试的收益递减点。当您停止获得有价值的信息时，请转到其他测试。
如果您觉得在理解观察到的问题方面没有取得进展，那么消除一个或多个变量或潜在原因，然后再次运行测试可能会更有效。
七：分析结果，报告，并重新测试
管理人员和利益相关者需要的不仅仅是各种测试的结果，他们还需要结论，以及支持这些结论的综合数据。技术团队成员需要的不仅仅是结果——他们还需要分析、比较以及获得结果背后的细节。所有类型的团队成员都可以从更频繁地共享性能结果中获得价值。
在报告结果之前，必须对数据进行分析。在分析性能测试返回的数据时，请考虑以下要点:
单独分析数据，并作为协作、跨职能技术团队的一部分进行分析。
分析捕获的数据，并将结果与度量的可接受或预期水平进行比较，以确定正在测试的应用程序的性能是趋向于性能目标还是偏离性能目标。
如果测试失败，通常需要进行诊断和调优活动。
如果您修复了任何瓶颈，请重复测试以验证修复。
性能测试结果通常使团队能够深入分析组件，并通过适当的测试设计和使用分析将信息与现实世界关联起来。
性能测试结果应该支持知情的体系结构和业务决策。
通常，分析将揭示，为了完全理解特定测试的结果，需要在随后的测试执行周期中捕获额外的度量。
立即共享测试结果，并将原始数据提供给整个团队。
与数据的使用者交谈，以验证测试是否达到了预期的结果，以及数据的含义是否与您认为的相同。
如果结果不代表定义测试要确定的内容，则修改测试以获得新的、更好的或不同的信息。
使用当前结果为下一次测试设置优先级。
频繁地收集指标会产生大量的数据。尽管减少数据量很诱人，但在使用数据减少技术时始终要谨慎，因为有价值的数据可能会丢失。
大多数报告分为以下两类:
技术报告
测试的描述，包括工作负载模型和测试环境。
易于消化的数据，最少的预处理。
获得完整的数据集和测试条件。
观察、关注、问题和合作请求的简短陈述。
项目干系人报告
与结果相关的标准。
最相关数据的直观、可视化表示。
根据标准对图表或图表进行简要的口头总结。
直观的、可视化的工作负载模型和测试环境表示。
访问相关的技术报告，完整的数据集和测试条件。
观察、关注和建议的摘要。
有效报道的关键是以快速、简单和直观的方式向目标受众呈现感兴趣的信息。以下是取得有效报告的基本原则:
早报告，常报告。
视觉上的报告。
直观的报告。
使用正确的统计数据。
正确合并数据。
有效地总结数据。
为目标受众定制。
使用有力而真实的语言，进行简洁的口头总结。
使数据对涉众可用。
过滤掉不必要的数据。
如果报告中间结果，包括优先级、关注点和接下来几个测试执行周期的块。
总结
性能测试涉及一组发生在项目不同阶段的公共核心活动。每个活动都有特定的特点和要完成的任务。这些活动已经被发现存在于作者和评审人员经历过的每一个经过深思熟虑的成功的性能测试项目中——或者至少已经成为一个主动的、基于风险的决定的一部分，以省略其中一个活动。详细地理解每个活动，然后以最适合项目上下文的方式应用活动，这是很重要的。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
