51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2603|回复: 0

【转】性能测试十问:测试经理篇

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:12
  • 签到天数: 918 天

    连续签到: 3 天

    [LV.10]测试总司令

    发表于 2016-6-22 11:23:25 | 显示全部楼层 |阅读模式

    现状

    • 测试经理不知道性能测试人员在做什么
    • 不知道性能测试进展如何
    • 不知道性能测试是否有效
    • 不知道如何协助性能测试人员

    本文目的

    • 了解性能测试的进展,更好的控制整个测试流程
    • 了解性能测试的质量

    十问

    • 性能测试何时介入
    • 性能测试的过程是怎样的
    • 是否有必要提起性能测试
    • 性能测试有哪些类型
    • 如何分析性能需求
    • 如何衡量性能
    • 性能测试(不)能做什么
    • 如何检验性能测试的质量

    Q1、性能测试何时介入

    开发生命周期中的性能测试

    • 单元测试

    代码层面的测试。写完一块代码,对代码的执行效率、内存使用、资源占用等情况进行测试,由开发人员完成。

    • 组件/服务/接口测试

      此层面的测试,通常是针对一个已完成的公用功能,此功能向外提供服务或者接口。既可以是代码级别的测试,也可以是不涉及代码的调用测试(如webservice接口),应由测试人员完成。

    • 系统测试

      整个系统已经实现,通过模拟用户的使用对系统进行测试。我们做的性能测试主要就是这个,由测试人员完成。

    • 生产环境测试

      在系统测试通过的基础上,构建出更完整的生产环境。比如一个生产环境,部属多个系统,这些系统共同使用时可能会相互影响,需要考虑到此种情况进行测试。

    系统测试中,何时介入呢

    • 稳定版

    → 进入太晚,进度无法保证

    → 可能会影响到功能测试

    这是测试负责人最害怕的,即测试晚期发现性能问题,修改涉及面较大,造成功能测试返工。

    • 尽早

    → 流程可跑通

    → 数据无严重问题

    等到稳定版再进入是不靠谱的,要尽早。

    尽早到什么时候,性能测试需要哪些流程和数据呢?关注性能方案中的用户模型。

    Q2、性能测试的过程是怎样的

    敏捷方式的最大特点就是不断确认、不断修正、多次迭代。

    在传统方式的测试过程中,经常出现的问题恰恰是缺少了敏捷思想中的确认过程,导致了测试方向偏离、测试有效性不够

    当前进展到哪个阶段?

    • 文档

    步骤1~3

    • 执行

    步骤4~7

    在传统方式中,可以很简单的将过程分为文档和执行两部分。文档过程很容易被检查,问题主要是在执行过程,这个过程有可能对测试经理是不可见的。

    考虑这个问题:如果一次性能测试,没有提起任何问题,是否在性能报告之前的执行过程是不可知的?

    如果现有的工作方式确实存在这个问题,该如何解决呢?

    这就需要依靠性能测试执行过程规范和检查制度,请继续往后看。

    Q3、是否有必要提起性能测试?

    • 新项目

    目前基本都需要进行性能测试。

    • 新版本(哪些变化可能涉及性能)→ 用户量

    用户数的增加,如推广使用、知名度提高。

    → 数据量

    数据量的增加,如分布式部属变成集中式部属。

    → 实现改变

    架构实现的变化,如音视频点播系统更换了流媒体服务器。

    测试负责人的疑问主要是新版本需不需要再做一次性能测试?比如只新增加了一个功能。

    抛开上面提到的3个方面,新增功能或模块可能会引起性能测试用户模型的变化。如果经过确认,用户模型无需变化,那自然也没必要重新测试。如果用户模型确实发生了改变,其实我觉得是有必要再次执行测试的,毕竟性能测试也算是一种自动化的测试,就应该能够持续性的运行。

    只不过我们现在的问题是,性能测试的复用性太低,基于HTTP请求的脚本很容易失效,测试环境也总需要重新搭建,这些因素导致了性能测试的成本和投入变大,即使只是增加了一个小功能,可能也需要重头来做一次性能测试。如果有办法改变这个状况,那么每次新版本只要补充一下相关的测试代码就可以了。

    我的想法是,性能测试要向组件/服务/接口级别靠近(见Q1),越接近底层,可复用性也就越高。另外,企业级虚拟化的建设一定要跟上,这样才不会在测试环境上浪费时间。

    Q4、性能测试有哪些类型

    • 基准测试

    比如单用户的测试或者在无数据条件下的测试,目的是提供一个标准供后续测试比对。

    • 负载测试

    向系统施加一定的压力,一般最大压力的20%或者日常使用压力即可,确保系统可正常运转。

    • 压力测试

    向系统施加预期最大压力,测试系统在繁忙状态下的性能表现。

    • 容量测试

    不断的增大对系统的压力,直至出现瓶颈。用于探测系统的瓶颈,为系统的发展提供重要信息。

    • 稳定性测试

    长时间运行的稳定情况。

    还有很多其他类型的测试,这里只是列出了几种最常用到的,术语的定义可能也和其他资料有些差别,比如负载和压力,不过无关紧要。

    这里需要注意的一点,在负载、压力和容量测试中,测试的依据都是用户模型,只有用户模型准确,测试的结果才会有意义。

    提起性能测试,需要做那种测试呢?

    一般来说,除了容量测试,其他几种都是要做的,这是得到有效测试结果的必备过程。容量测试,属于获取“额外信息”的测试,不过这种测试其实是非常有价值的,很多资料都把它列为了必做之一。

    稳定性测试需要运行多长时间?

    之所以会有这个疑问,其实是因为测试人员提供的结果数据没有说服力,不是证明了系统可以长期稳定运行,而只是下了个系统稳定的结论。

    我也总和性能测试人员强调,测试的结果是要用数据来证明的,不是说测完了下一个通过的结论就可以了,这样自然要被测试经理、开发经理怀疑(尤其是你是一个新人)。

    如果能够提供各种详尽的数据,比如测试运行12小时内,操作系统的资源利用情况、应用中间件内部的资源利用情况、甚至是程序内部的一些性能指标等等,如果这些指标足够代表系统的性能,且它们的表现是非常平稳的,那么完全可以从这个趋势推断出,即使系统运行更长的时间也将是稳定的。

    反之,如果不提供数据,而只是描述测试运行了3天,那么自然会有“3天够不够长”的疑问,只有通过“足够长”的运行时间才能减少人们的顾虑。

    Q5、如何分析性能需求

    性能相关需求一般由需求人员提供,测试负责人是这些需求的第一个把关人。针对这些需求,测试负责人可以分析哪些内容呢?

    是否全面

    • 用户角度

    → 能不能

    → 快不快

    • 业务角度

    → 吞吐量、TPS、每小时完成工作量

    → 处理压力的方式

    如12306购票,当压力太大的时候,是让所有人都能得到非常慢的服务,还是保证一部分人可以正常使用、另外的人停止服务?

    • 技术角度

    → 是否使用了某些有潜在风险的技术

    → 系统内部的一些资源

    • 其他角度

    → 比如系统拥有者,要求服务器资源利用率60%左右,想想为什么?

    是否有效

    • 可行性

    要求发送短信后能即时到达。这就是不可行的需求,因为涉及到运营商的网络。

    • 可量化

    邮件发出后,较短的时间内到达。

    是否灵活

    • 需求vs.期望

    → 需求是必须要达到的。比如发送即时消息,必须保证没有丢失,这时可能就要有一个到达率的指标,如果达不到100%,那就是不合格。

    → 期望是灵活的,比如页面响应时间3s以内,这就是一个期望,不会因为最后是3.2s而影响结论或者导致延期发布。

    Q6、如何衡量性能

    性能的评价标准

    • 用户感受

    用户实际的感受是最权威的评价标准。

    • 明确的性能指标

    但大多数情况无法用实际感受来进行衡量,所以我们需要能够有效代替“感受”的数据,也就是各种性能指标。

    性能指标一般有哪些

    • 响应时间

    业务类web系统一般主要耗时在服务端,所以通常获取请求的响应时间即可,这是不涉及到客户端展现的。

    • 页面展现时间

    互联网网站通常最关注展现时间,一般有更具体的指标如首屏展现时间。大家用一用淘宝或者京东就能理解了。

    • 吞吐量
    • TPS

    业务上的需求,比如百度一定会有每秒钟处理多少万次搜索请求这类的指标。

    • 特定需求的评估标准

    如上面举的例子,消息到达率。

    这些对性能的评价标准,应该在测试设计时就明确下来,测试负责人可对此进行检查。

    有一点需要注意的是,性能指标是否可检测。通用的指标如页面响应时间很容易获取,所有的测试工具都可以做到。但一些特殊的指标,尤其是涉及到客户端的,可能会存在技术上的问题。比如即时通讯软件的测试中,要求最大压力时,发送信息能够在1s内到达。那么这个到达时间如何获取呢?如果没有提前做好准备,在测试执行时很可能会遇到问题,而测试人员遇到这个问题,很有可能会选择忽视它,只顾把压力加上去就算测完了。

    Q7、性能测试(不)能做什么

    web系统性能测试

    最常见的目的是模拟用户的实际行为,获取用户的感受。

    如何模拟用户的实际行为

    建立用户模型。即用户做什么操作、操作路径是什么、操作频率……

    如何建立用户模型

    • 常用业务
    • 性能敏感业务
    • 关键业务
    • 特殊关注

    这里只是用户模型覆盖度的问题,实际使用的用户模型还需要很多其他信息才能建立起来。

    测试负责人需要重点关注和确认用户模型的建立。

    性能测试的覆盖率

    由上可知,性能测试只能覆盖系统的一部分功能。不要指望所有和性能相关的问题都由性能测试来发现。

    性能测试最最想发现的是瓶颈,而不是缺陷。

    我比较害怕听到这样的话,“生产环境的一个操作很慢,去做下性能测试吧”。

    Q8、如何检验性能测试的质量

    执行过程

    • 建立执行规范

    明确定义执行过程各检查点需要的输出物

    • 指派检查人员

    根据执行规范进行检查

    • 输出执行记录

    测试人员都知道,设计的用例和实际的执行总是不一样的。性能测试更是如此,调整参数重新运行脚本也是一次执行,这些信息必须有清晰的记录。

    • 持续交互确认

    性能报告

    • 让数据证明结论,而不是下结论

    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-28 17:19 , Processed in 0.067947 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表