应用程序性能测试的艺术笔记

效率型指标：吞吐量（每秒点击数）和利用率（资源占用率2PerformanceDriven（性能驱动）--5%系统设计阶段缺少性能方面的考虑（考虑整体系统集成后的性能直到最后一刻才进行性能测试（性能测试越早越好对系统的容量或规模没有足够的考虑（最终用户的规模和分布对性能峰值预期偏低应用程序部署后需要支持多少最终用户？6个月后呢?12个月后?2年后部署后有多少用户?6个月后呢?12个月后?2年后?我需要提供什么类型的网络基础设施性能测试重点关注的方面确定服务器和网络的关键性指标工具厂商支持（通信协议认证模式概念验证（ProofofconceptPOC，证明其可行性，示范其原理效果（生成的编辑程度解决方案与负载测试工具（提供解决方案or内部执行设计合适的性能测试环境原则,性能测试环境需要注意的几个方面负载生产器能力：确保负载有足够的硬件资源（尽量保证硬件资源处于饱和状态IP负载均衡（IP地址不同进行负载分配需要实施“IP”技术（选择测试工具时，需要注意用户会话限制（每一个物理机器只能发起一个用户会话，如：mac验证等选择测试工具时，可以选择负载测试和功能测试任意组合的性能测试工具）不同的部署模式（网络环境）可用带宽（局域网和广域网的带宽，需要作为性能测试模型的考虑因素修改事务回放（性能测试工具通过修改事务的执行频率达到广域网的负载（最符合实际网络模拟（网络角度模拟广域网的网络环境外部连接（其他内部或者第系统的情况软件安装：测试环境中安装的第软件是否会互相一致性（保证所有相关人员对性能指标的理解保持一致性能指标制定需要提早制定（项目的早期阶段）（CIO（CTO（CFO）其他（开发人员，测试人员，基础设施组，最终用户可用性或者正常运行时间（应用程序任何时候处于可用状态并发性扩展性和吞吐（并发性根据80/20原则确定扩展性考虑时期，用户，专家级用户在单位时间内，创建的事务））SQl做到代码冻结（保证测试版本稳定识别并确认关键业务的事务（确定性能测试业务范围定义事务涉及的用户类型（多用户操作同一事务，使用量各有不同事务的模式是什么（局域网、广域网、互联网主动型事务还是型事务要测量什么（LR里面事务的概率用户是否反复登录（中，是否重复登录资源共享（与其他应用共享服务器、网络带宽等运行时返回数据（确认执行结果正确数据安全性（保证数据脱敏）负载测试（为达到性能目标而做的性能测试；最接近真实的使用场景渗透或稳定性或可靠性测试（长时间下的负载测试冒烟测试（测试（式（同一时间加压每个事务的基准测试（为每个事务建立一套性能数据基准每个事务的负载测试（确定每个事务需要的最大并发用户数或吞吐量单个事务的测试（出现问题时，启动，直到问题解决能的，比如数据库锁等资源的竞争；负载生成策略：递增或递减）混合事务测试（混合负载不达标时，启动，确认诊断结果和解决方案，知道解决a）CPUb）c）（e（aeCandle（IBM）准备负载环概念验证（Proofof个有里程碑意义的实作的原型。概念性驗證(ProofofConcept；POC)1種架構師(Architect)在销售环节中，POCPOC提供了一个在技术上评估针对目标程序的性能测试工具的机会（从技术角度验））评估（估算出编写所需要的时间，为以后的测试提供决策基准在目标应用程序上演示性能测试解决方案的能力（POC象形的展示了自动化测试工POC一览表：与客户共同制定一套成功或者退出标准，并以的形式确应用环境安装必要的软件，如服务器和网络理想的情况下，有一个独立的权限去POC过程中的程提供技术支持人员（了解程序的构架以及中间环节的工作原理并能解决技术性问题应用环境和被测程序的权限账号（至少准备两套权限用户，多用户操作（对比工具：Windiff、ExamDiffProfromprestoSoft、WinMerge）测试工具成功的运行，回放应用程序的事务，是评价POC通过的标，在性能测试项目中大部分的时间花费在获取需求、验证需求以及实现需求上才能，录制性能测试：每个事务需要半天的时数据收集：需要一天的时间（收集和（关键性能指标）KPI数据其他：决定是外部资源测试还是用内部资源来执试（取决于时间进度和自身资源制定测试环境设计方案（尽量接近真实环境，创建的时间要充分考虑确保性能测试中，不会受到其他用户的影响（防止对性能测试执行和结果造成影响确定事务的检查点，特别是一些特殊的监视要求（比如登陆、搜索检查您所选择的事务的输入、目标、运行时数据的需求（数据对于性能测试十分重要；要保证性能测试项目的时间框架内获取足够的准确的数据同时考虑数据的安全和

验证性能，并生能与测试目标对比的报团队成员以及汇报制度（建立专门的性能测试团队或有内部测试专家组成的团（大型公司；最起码要确保您有一位项目经理和足够的性能测试工程师技巧（常被忽略的问题方案预备了意外处理机制。考虑所有的配置模型（局域网，广域网把外部系统的考虑进去；外部可能是性能瓶颈的主要所在为目前的测试模型准备足够的负载生成能力负载生成的位置：本地、为被测应用程序和支持应用程序的软件准备足够的软件协配置（关键业务指标）KPI工（Checkpoint负载配置策：Bangupdown；：考虑是否使用IP技术；如果用，提前准备合法的IP根据服务器和网络KPI指标，确定性能软证实测试之前，进行预演测试；检查负载是否达标；确定测试环境配置正确（执行负载测试时，下一次负载测试前，执行重置数据库（保证性能基线负载测试中发现的问题，需要单独进试（考虑计划时，需要安排额外的时间渗透测试（疲劳测试）发现内存或者发现与高数据交互事务执行相关的问执行其他与性能无关的测试（配置不同的负载平衡性、容错灾备等数据收集（收集并备份所有在性能测试项目中生成的数据）根据报告模板将整理成文将最终结果作为基线数据并用于最终用户体验实时分析（密切观察（watchfulwaiting（能够每个所分配的用户数以及测试全过程中所分配的用户总数（可以实时观所有负载，以便能够检查负载是否过需要与任何已经作为性能测试一部分的服务器、应用服务器以及网络KPI所有相关性能测试结束后，测试工具可以性能供测试后分中位数是一组数据的中间值；比如 Nth统计学中的Nth百分比用于定义的采样比例；比如：40th百分比意味着选取所有事务中的性能“检查点”排序图，有助于分析事务中突出的问题所WebWindowsWebJMX最关注的两个指标：CPU负载需要的典型指标CPUKPI当一般级别应用服务器的不能提供的信