关于性能测试的那些事

之前有做过几次做性能测试,略有心得和大家分享一下

从测试需求开始,到完成测试,都需要经过很多阶段

首先是测试需求,要评估测试需求是否合理,并不是所有的性能测试需求都需要直接来安排测试,而是评估下是否需要做本次性能测试。  产品提出需要做性能测试是基于用户的考虑, 如果确定要进行性能测试,就需要评估性能测试的方案。包括环境搭建、逻辑了解、数据准备、测试过程、问题定位、修改优化、回归、出报告的时间。需要强调的是,性能测试开始的时间一定是功能测试已经通过了。否则进行性能测试会存在修改功能逻辑导致性能发生变化,性能测试就没有任何指导意义了。

测试服务器的搭建和打压环境的搭建。测试环境可以有开发来搭建。原则上测试服务器配置不能高于线上服务器的配置,且测试服务器部署的服务要尽量接近线上服务器。

了解整个性能测试的业务逻辑。一般需要了解请求个数,请求参数含义等。除此之外,在这里要强调几个新手容易忽视的问题:就是打压测试服务器时,要和线上服务器做明确隔离。不要简单认为所有的请求都是指向测试服务器,就认为是只向测试服务器打压。

性能测试的难点在于对被测系统的理解,在于对测试点的分析。为了实现测试的思想,可以有多种方法,手段永远只是辅助的,只有思想才是根本的。工具更不等于性能测试,不要以为会用LR就懂了性能测试,那只是最低级的测试执行。也不要以为会调几个参数就懂了性能测试,那同样是个比较低的层次。

调优等技术不是性能测试的主要目的,好的性能也不是调出来的。测试人员一定要明白自己存在的价值所在,所谓的“技术”只是为了达成自己测试目的的一些手段。

如何证明测试结果的有效性,其实是个很难的问题,值得花费时间去认真思考。这个过程涉及到一些很重要的内容,如用户模型的建立,后续会有专门的文章。

性能测试是一个需要不断改进的过程,每一次只需尽量的做到更好,多做一点点以前没有想到的东西。经过不断的积累,你会发现自己对性能测试有了更深的认识。

性能测试是产品的一个重要测试项目,是保证产品质量和用户体验的保障,特别是近几年,移动端产品的爆发,在app性能测试、app功能测试等方面,需要更多的投入,希望这些有所帮助。

TestBird - 手游和App自动化测试平台

时间: 2024-08-02 01:09:20

关于性能测试的那些事的相关文章

关于性能测试应该知道的一些事(转载)

1 怎样的性能测试结果才是有效的 1.1 错误观点 性能测试工具运行一定用户数都成功,则表示该服务器能支持这么多用户数.这是错误的. 解答: A.        因为一次有效的测试结果,不只用户都运行成功,同时需要保证访问一个页面或一次交易的响应时间在合理范围.“2-5-8原则”,简单说,就是当用户访问一 个页面或一次交易能够在2秒以内得到响应时,会感觉系统的响应很快:当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以:当用户在5-8秒以内 得到响应时,会感觉系统的响应速度很慢,但是还可

loadrunner实战篇 - 客户关系管理系统性能测试

系统介绍                                                             图1(客户关系管理系统模块关系图) 需求分析 一.性能指标 性能指标分析,根据客户需求与本系统相结合,用户希望模块能满足下表所列的性能指标. 图2(性能指标) 很明显,上面的需求是不具可操作性的,这就像和客户谈需求一样,客户只是很简单地描述了需求,而如果仅仅从上面这个简单的表格来进行性能测试,是很难的一件事情,并且很可能测试出来的结果与实际结果存在很大的差距,这样就需

soapui接口性能测试(二)---- 模拟不同类型的负载

SoapUI中提供的不同负载策略允许您模拟各种类型的负载,随时间的变化,您可以在许多条件下轻松测试目标服务的性能.由于SoapUI还允许您同时运行多个LoadTests(参见下文的示例),可以使用LoadTests的组合来进一步断言您的服务的行为.从LoadTest窗口中的Strategy工具栏中选择所需的LoadTest策略: 我们来看看可用的不同负载策略,看看如何使用它们来进行不同类型的负载/性能测试. 简单的策略 - 基准,负载和SOAK测试 简单策略运行指定数量的线程,每次运行之间具有指

性能01篇-如何胜任性能测试工程师岗位

谈到性能测试,很多人都能说出一大堆关于性能测试的指标等等,但真正的去做性能的测试,测试工程师里也就只有10%的性能测试工程师能够真正会做吧! 下面小梦就和大家讨论一下性能的那些事! 首先,作为一个性能工程师需要掌握哪些技能呢? 1.能搭建一个稳定.可重复使用的测试环境,能够保证测试结果的正确:保证达到测试执行的技术需求:保证得到正确的.可重复的以及易理解的测试结果. 2.掌握测试工具:市场上的性能测试工具实在太多了.比如:LoadRunner.Jmeter.Web Page Test.Bench

入门级----黑盒测试、白盒测试、手工测试、自动化测试、探索性测试、单元测试、性能测试、数据库性能、压力测试、安全性测试、SQL注入、缓冲区溢出、环境测试

黑盒测试 黑盒测试把产品软件当成是一个黑箱子,只有出口和入口,测试过程中只要知道往黑盒中输入什么东西,知道黑盒会出来什么结果就可以了,不需要了解黑箱子里面是如果做的. 即测试人员不用费神去理解软件里面的具体构成和原理,只要像用户一样看待产品就可以了. 例如银行转账功能,不需要知道转账的具体实现代码是怎样工作的,只需要把自己想象成各种类型的用户,模拟多种转账情况看系统是否能正常转账即可. 但是仅仅像用户一样去测试又是不够的.如果只做黑盒测试,必然是存在一定的风险的. 例如某个安全性较高的软件系统,

【转载】关于烂代码的那些事

http://kb.cnblogs.com/page/526768/ ============上篇============ 1. 摘要 最近写了不少代码,review了不少代码,也做了不少重构,总之是对着烂代码工作了几周.为了抒发一下这几周里好几次到达崩溃边缘的情绪,我决定写一篇文章谈一谈烂代码的那些事.这里是上篇,谈一谈烂代码产生的原因和现象. 2. 写烂代码很容易 刚入程序员这行的时候经常听到一个观点:你要把精力放在ABCD(需求文档/功能设计/架构设计/理解原理)上,写代码只是把想法翻译成

性能测试结果分析

转自网络 性能测试工程师基本上都能够掌握利用测试工具来作负载.压力测试,但多数人对怎样去分析工具收集到的测试结果感到无从下手,下面我就把个人工作中的体会和收集到的有关资料整理出来,希望能对大家分析测试结果有所帮助. 分析原则: 1. 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点) 2. 查找瓶颈时按以下顺序,由易到难. 服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(

聊聊测试管理的那些事之管事篇

管理:管人+管事. 说到管理,其实就是团队,没有团队,就谈不上管理.个人理解,对个人而言,更多应该是计划,而非管理.做管理的时间并不长,或者说很短,可能很多地方理解的有问题.写这篇文章也是为了能更多的与大家交流,也是记录下在目前这个阶段我的理解.(本文均以在创业型公司工作为背景),全篇分为管事篇跟管人篇. 管事篇 一.测试的工作流程. 关于这个点,其实网络上一搜一大堆,大体都差不多,需求分析,测试计划,设计测试用例,评审用例,执行测试,缺陷管理,定版,发布.但是,我认为作为一个测试leader,

关于烂代码的那些事(中)

1. 摘要 这是烂代码系列的第二篇,在文章中我会跟大家讨论一下如何尽可能高效和客观的评价代码的优劣. 在发布了关于烂代码的那些事(上)之后,发现这篇文章竟然意外的很受欢迎,很多人也描(tu)述(cao)了各自代码中这样或者那样的问题. 最近部门在组织bootcamp,正好我负责培训代码质量部分,在培训课程中让大家花了不少时间去讨论.改进.完善自己的代码.虽然刚毕业的同学对于代 码质量都很用心,但最终呈现出来的质量仍然没能达到“十分优秀”的程度. 究其原因,主要是不了解好的代码“应该”是什么样的.