性能测试计划VS测试实践

 许多人说,面向过程的工作是成功的关键。虽然我非常赞成这个说法,但我总是纳闷为什么人们对于性能测试的7个要点并没有特别关注,而这7个要点能左右性能测试项目的成败。

  当一个测试人员被分配到性能测试项目组,项目经理会让他/她做的第一件事就是着手准备测试计划。但在测试计划的准备阶段,测试经理及其属下在准备文档时通常会掉以轻心,文档的大部分内容要么是从以前的项目中复制过来的,要么是从网上找来的任意模板;对测试计划中提到的需求说明不予任何关注就直接转移到下一阶段了。不可否认的是:作为公司流程标准中的必须项,测试计划通常只流于形式;因此它从来没有真正用于连接项目的执行。

  我想说的是,用来准备测试计划的时间是整个项目实施期间非常有价值的部分。但不幸的是,所有这些多半都只是在理论上说说,很少用于实践。因此测试人员通常不会把测试活动和测试计划紧密的结合到一起,因为每个测试计划的实施都会受与此过程相关的费用影响,而且他们认为测试计划会延缓测试活动。

  这无疑是一件坏事,但即使你否定了这个项目计划阶段—若测试工程师在项目执行阶段认真遵循性能测试的7个要点,我觉得我们还是能在最后看到希望。

  7个要点:

  1、知道SLA指的是什么。

SLA 服务等级协议

定义

  

  

SLA:Service-Level Agreement的缩写,意思是服务等级协议。

  服务等级协议是关于网络服务供应商和客户间的一份合同,其中定义了服务类型、服务质量和客户付款等术语。

  SLA: SoftWare License Agreement的缩写,意思也可为软件许可协议,像著名的GPL,BSD等均为典型代表.

  SLA: Second Language Acquisition的缩写,意思是第二语言习得。

项目

  典型的SLA 包括以下项目:

  分配给客户的最小带宽;

  客户带宽极限;

  能同时服务的客户数目;

  在可能影响用户行为的网络变化之前的通知安排;

  拨入访问可用性;

  运用统计学;

  服务供应商支持的最小网络利用性能,如99.9%有效工作时间或每天最多为1分钟的停机时间。

  各类客户的流量优先权;

  客户技术支持和服务;

  惩罚规定,为服务供应商不能满足 SLA 需求所指定。

要求

  按照 SLA 要求,服务供应商采用多种技术和解决方案去监控和管理网络性能及流量,以满足 SLP 中的相关需求,并产生对应的客户结果报告。

  另一方面,客户本身也提出了自己的技术及解决方案去监控邻居的流量和服务,以确保提供他们答应的传送服务项目。

  SLA概念已被大量企业所采纳,作为公司 IT 部门的内部服务。大型企业的 IT 部门都规范了一套服务等级协议,以衡量、确认他们的客户(企业其他部门的用户)服务,有时也与外部网络供应商提供的服务进行比较。

编辑本段服务水平协议

定义

  SLA 服务水平协议(简称:SLA,全称:service level agreement)是在一定开销下为保障服务的性能和可靠性,服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。

内容

  一个完整的SLA同时也是一个合法的文档,包括所涉及的当事人、协定条款(包含应用程序和支持的服务)、违约的处罚、费用和仲裁机构、政策、修改条款、报告形式和双方的义务等。同样服务提供商可以对用户在工作负荷和资源使用方面进行规定。

保障

  传统上,SLA包含了对服务有效性的保障,譬如对故障解决时间、服务超时等的保证。但是随着更多的商业应用在Internet的广泛开展,越来越需要SLA对性能(如响应时间)作出保障。这种需要将会随着越来越多的商业在Internet 的开展而重要起来。实际上,SLA的保障是以一系列的服务水平目标(SLO)的形式定义的。服务水平目标是一个或多个有限定的服务组件的测量的组合。一个SLO被实现是指那些有限定的组件的测量值在限定范围里。SLO有所谓的操作时段,在这个时间范围内,SLO必须被实现。但是由于Internet的统计特性,不可能任何时候都能实现这些保障。因此SLA一般都有实现时间段和实现比例。实现比例被定义为SLA必须实现的时间与实现时段的比值。例如:在工作负荷<100 transaction/s前提下,早上8点到下午5点服务响应时间<85ms,服务有效率>95%,在一个月内的总体实现比例 <97%。

  2、了解真实用户的使用模式。

  3、知道如何加载服务器。

  4、知道负荷服务器的最大负荷量。

  5、明白自动化测试需要包含哪些类型。

  6、了解你的测试工具以最大化其功能。

  7、了解你的测试环境。

  你只要在脑海中牢牢记住这些要点是专业范畴内的一部分。你既不需要把这些归档,也不用把它们交付客户,你只需要实践。因为最后,客户既不会想知道你的负载测试计划有多好或多坏,也不会因你遵循的标准不同而生气,相反,客户在意的是你提交的结果的准确度和这些统计资料对改善应用程序的性能有多大帮助。相信我,深入了解这些要点的每个方面并认真执行,对得到负载测试的真实结果肯定会有所帮助。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-29 04:40:35

性能测试计划VS测试实践的相关文章

性能测试知多少---性能测试计划

上一章节中我们对性能的需求进行了分析,知道了测试对象,了解了测试需求,那么下面就需要制定一份详细的计划,来规划和指导性能测试工作的进行.为了使你对性能测试计划更清晰明白,这里以测试计划的格式来描述.   一.简介   简介部分就不用过多描述了,无非项目的背景,进行此次性能测试的原因,以及性能测试覆盖的范围等等,几乎所有项目文档都在开端对项目进行简单的阐述.   二.性能测试需求   寻找的被测试对象和压力点 要测试的对象不是凭空想象出来,而是经过分析与系统数据收集得到.下取几个典型的压力点 登录

《精通软件性能测试与LoadRunner最佳实战》—第2章2.3节性能测试计划

2.3 性能测试计划精通软件性能测试与LoadRunner最佳实战性能测试计划是性能测试的重要过程.在对客户提出的需求经过认真分析后,作为性能测试管理人员,需要编写的第一份文档就是性能测试计划,性能测试计划非常重要,在性能测试计划中,需要阐述产品.项目的背景,将前期的需要测试性能需求明确,并落实到文档中.指出性能测试可参考的一些文档,并将这些文档的作者.编写时间.获取途径逐一列出,形成一个表格,这些文档包括:用户需求规格说明书.会议纪要(内部讨论.与客户讨论等最终确定的关于性能测试内容)等性能测

EQueue性能测试计划

1.发送消息吞吐量的测试: 1)单台producer单个进程的发送消息tps 2)单台producer多个进程的发送消息tps 3)单台broker的接收消息tps,由于单台producer可能压不满,所以需要可能两台producer来发消息 2.消费消息吞吐量的测试: 1)单台consumer消费消息的tps 2)两台consumer消费消息的tps 3.同时发送和接收消息的吞吐量.消费延迟的测试: 1)单台producer发送消息,单台consumer消费消息 2)两台producer发送消

新旧MacBook性能跑分测试对比

  此前关于2016年款MacBook的多项性能评测中,相比较前代提升8%-15%之间,但是在实际使用中这种性能提升又带来了多大的感官体验? 为此外媒AppleInsider在进行SSD写入速度.GeekBench 3处理器跑分.Cinebench的CPU和GPU渲染测试和Google Octane网页浏览性能等常规测试后在最新版的Lightroom中导出已经完成编辑的图片,结果显示新款MacBook时间要快14%. 随后外媒又运行了Final Cut跑分BruceX,测试新旧两款设备在视频编辑

三张图看遍Linux 性能监控、测试、优化工具

三张图看遍Linux 性能监控.测试.优化工具 Linux 平台上的性能工具有很多,眼花缭乱,长期的摸索和经验发现最好用的还是那些久经考验的.简单的小工具.系统性能专家 Brendan D. Gregg 在最近的 LinuxCon NA 2014 大会上更新了他那个有名的关于 Linux 性能方面的 talk (Linux Performance Tools) 和幻灯片. 和 Brendan 去年的 talk 比较,今年增加了测试和优化两部分.下面的三张图片分别总结了 Linux 各个子系统以及

测试计划与测试方案的区别

计划:属于组织管理层面的文档,从组织管理的角度对测试活动进行规划: 方案:属于技术层面的文档,从技术的角度对测试活动进行规划. 测试计划: 对测试全过程的组织.资源.原则等进行规定和约束,并制定测试全过程各个阶段的任务分配以及时间进度安排,并提出对各项任务的评估,风险分析和管理需求. 测试方案: 描述需要测试的特性,测试的方法,测试环境的规划,测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案. 测试方案需要在测试计划的指导下进行,测试计划提出"做什么",而测试方案明确&qu

《腾讯iOS测试实践》一一第3章 iOS兼容性测试 3.1 引言

第3章 iOS兼容性测试 3.1 引言 苹果公司每年都有两个引人注意的大动作:一是发布新系统,二是发布新机型.无论是发布新系统还是发布新机型,都会让iPhone平台上的研发团队忙于兼容适配的工作.作为iPhone平台上的测试人员,对苹果公司每年放的大招都要有招架之术.很多不了解情况的人会认为苹果公司的机型比较少.系统发布也不频繁,应该不会有太多涉及适配的问题,而实际情况并非如此.每发布一个系统和机型,都会伴随大量的技术实现或者硬件变革,用户在感受机型与系统更新带来全新体验的同时,背后需要开发人员

Booking.com的A/B测试实践

我们希望通过客户的观点来驱动我们的产品开发,而经过实验证明的各种假设则是探索客户观点的最佳手段.目前,在阿姆斯特丹举办的OSCON大会上,来自于booking.com的首席设计师Stuart Frisby为与会者讲述了他们如何在产品开发中大量应用A/B测试实践的情况. A/B测试是一种通过比较某个指定特性不同版本的差异,以理解哪一个版本的效果更好的一种行为.但要正确地实践A/B测试,需要满足一些前提条件. 每个特性都需要进行完整的测试,但这种测试必须是原子性的.如果你不能做到每次测试只针对一项变

《腾讯iOS测试实践》一一1.2 工程效率

1.2 工程效率 总体来说,工程效率就是研发效率(包含测试效率).这里我们会把测试效率单独提出来进行说明,因为这是与测试工程师相关度最大的工作.研发效率,其实就是让产品上线的时间更快(在品质有保障的前提下),大多数时候是说与研发流程相关的(不局限于敏捷流程,Feature Team研发模型),例如包含但不局限于以下活动.需求评审:需求评审机制以及更新通知,避免需求有改动而没有及时同步到相关角色.代码质量:静态代码扫描,千行代码缺陷率等.架构评审:代码架构的讨论以及评审.Bug流程:Bug生命周期