建立一个性能测试策略

建立一个性能测试策略是第一步,也是最重要的一步性能测试。它可以帮助你定义:

• 性能测试范围
• 负载的政策
• 的服务水平协议(sla)和服务水平目标(SLOs)

永远不可能测试所有,因此有意识的决定,专注的深度和强度测试是必需的。通常,最富有成效的10 - 15%的测试场景揭开75 - 90%的重大问题。

基于风险的测试

风险评估提供了一种机制,通过这种机制可以优先测试工作。它帮助确定直接最激烈和最深的测试工作和故意去轻(节约资源更强烈的场景)。基于风险的测试可以更快地识别一些重要的问题/早在这个过程中通过帮助关注测试系统的风险方面。

对于大多数系统,性能和鲁棒性问题发生在这些领域:

• 资源密集型的特点
• 时间关键/敏感的使用
• 可能的瓶颈(基于内部架构/实现)
• 客户/用户的影响,包括可见性

• 以前的历史缺陷(观察指出在其他类似系统在现场操作)
• 新的/修改的特性和功能
• 大量需求(频繁使用的功能)
• 特性集的复杂性
• 异常

• 麻烦的(例如,不建立/维护)系统组件
• 平台维护

这是一个由行业专家的问题列表罗斯羽衣甘蓝帮助您识别不同的性能风险:

情境观点

• 哪些领域系统的操作,如果他们有性能不足,最影响底线(收入/利润)?
• 系统的使用可能会消耗一个高水平的系统资源/事件,不管事件发生的频率?资源消耗应该是重要的对于每一个事件,而不是高总因为事件经常发生,因此事件的总数是很高的。
• 系统的哪些方面可以最低限度检测性能没有鲁莽地增加风险,为了节省测试资源的地区需要重测试吗?

系统视图

• 哪些系统使用时间关键/敏感吗?
• 它使用是最受欢迎的(例如,经常发生)?
• 它使用最明显的(例如,高能见度)?
• 什么情况下可能会导致大量需求对系统从外部用户(例如,远程游客到一个公共网站不是内部员工)?
• 系统中有什么明显的复杂的功能(例如,异常处理)?
• 有什么领域,不成熟的新技术已经被使用,或未知的/未经实验的方法吗?
• 还有其他背景应用程序共享相同的基础设施,它们将影响或显著争夺系统资源(例如,共享服务器)?

直觉和经验

• 我们能从现有系统的行为所取代,如工作负载/性能特征?我们如何运用这些信息来测试新系统?
• 是和其他类似的情况下你的经验吗?哪些特性,设计风格、子系统、组件或系统方面通常遇到性能问题?如果你没有经验与其他类似的系统,跳过这个问题。
• 你的组合因素被回答前面的问题应该得到高的测试优先级?同时活动可能会发生什么,造成沉重的负荷/压力系统吗?
• 根据你的理解系统架构和支持基础设施,可能的瓶颈在哪里?

要求观点

• 在什么情况下沉重的内部需求可能(例如,通过一个网站的内部员工)?
• 数据库归档的政策是什么?数据加/年的比例是什么?
• 系统需要7个小时,24小时,等等?
• 有维护任务运行在业务时间?

这些问题的答案将有助于确定:

• 需要测试的区域
• 测试类型需要验证应用程序的性能

组件测试

一旦所需的功能区域性能测试已确定,de-compose业务步骤展示技术组件的技术流程。

为什么要分成业务操作组件?因为目标是测试性能处于初期阶段,列出所有重要组成部分将帮助定义一个性能测试自动化的策略。一旦一个组件被编码,测试分别测量:

• 组件的响应时间
• 最大电话/第二组件可以处理

此外,组件测试支持JMS、api、服务信息等,使场景很容易创建和维护。这种策略的另一个主要优点是,组件的接口是不太可能影响技术更新。一旦创建一个组件的场景,它可以包含在构建过程,反馈当前的构建可以接受的性能。

每次冲刺后,需要测试组装应用程序通过运行真实用户测试(使用多个组件)。即使被测试的组件,它是强制性的措施:

• 系统行为与几个业务流程并行运行
• 真正的用户响应时间
• 大小/架构的可用性
• 缓存策略

测试工作变得更加复杂和项目的进展时间表。一开始,重点是应用程序的质量,然后集中在目标环境,体系结构和网络。这意味着性能测试目标将取决于项目的时间表。

性能测试环境

被测试的系统必须正确配置,结果可用于生产系统。环境和测试策略开发期间setup-related考虑应该是首选。这里有几个:

• 哪些数据被使用?它是真实的生产数据,人工生成的数据,还是选择随机记录?匹配的数据量产量预测吗?如果不是,有什么区别?
• 用户是如何定义的?账户设置为每个虚拟用户与适当的安全权利,还是一个管理员ID被重用?
• 有什么区别的生产和测试环境吗?如果测试系统是生产的一个子集,可以整个负载或只是部分负载模拟?

重要的是,测试环境尽可能反映生产环境(可能还存在一些差异,这是可以接受的)。即使测试与实际生产数据在生产环境中执行,这只会代表一个时刻。其他条件/因素需要考虑。

设计一个测试计划

测试计划文档描述性能的策略。它应该包括:

• 性能风险评估强调性能要求
• 性能建模:解释(s)的逻辑计算负载的不同政策
• 翻译的主要用户的旅程到组件
• 描述所有其他用户与特定的思考时间旅行/业务事务指标
• 数据集(s)
• SLA (s)
• 描述每个测试被执行验证的性能
• 测试环境

测试计划是一个关键构件的一个设计良好的和执行性能测试策略,作为证据,一个团队满意占重要作用表现在最终的终端用户体验。

在许多情况下,项目团队确保交付性能测试计划的一部分功能在规划和开发周期要求他们工作的一部分准备好了的定义。虽然每个专题报道或用例可能不需要相同级别的性能测试,使思维过程硬要求完成导致更好的系统和一种改进的心态对端到端质量的团队交付。

下一个步骤

这是本系列的第二篇文章包括四部分,侧重于实际指导现代性能测试:

第1部分- - - - - -一个实际的介绍性能测试

第2部分-建立一个性能测试策略

第3部分- - - - - -建模性能测试

第4部分- - - - - -执行性能测试

这篇文章最初发表在2018年1月和2021年7月被刷新。