网站响应速度多长时间普通页面报告异常活动

网页响应时间 指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“ TTLB ” (Time to laster byte) ，意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。

响应时间的计算模型：

响应时间 =网络传输时间（请求）+服务器处理时间（一层或是多层）+网络传输时间（响应）+页面前段解析时间

简化的 浏览器响应时间的计算模型 ：

浏览器响应时间 = 服务器响应时间 + 页面装载时间 + 页面渲染时间

页面渲染时间 主要包含两个部分：

页面渲染时间 = 脚本执行时间 + 浏览器引擎渲染时间

2-5-10原则

当用户在2秒以内得到响应时，会感觉系统的响应很快；

当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；

当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；

而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

2秒首页 ，5秒普通页面， 10秒~复杂查询页面。

在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定。

个人和企业建站，服务器的性能影响着车开的快不快。比如运算速度，传输速度这个直接影响着每毫秒可以处理多少数据，这个就类似你插个U盘进电脑，读写速度。像香港服务器100M大带宽直连，测试网络质量好坏意味这高速公路有多少条道。

网络速度决定了道路的质量，比如柏油路，水泥路，黄泥路这个基本上不考虑，目前都是光纤光纤的质量差别并不会很大，如果访问速度不好的话，会让网站加载非常慢。在选择服务商时，首先一定要选择有保障的，方便日常维护。其次就是就要看服务器的稳定性，服务器出现宕机的情况不少见。那服务器的网络和带宽质量究竟如何来测试呢

服务器网络质量如何测试

1、网络线路质量

玩网络游戏，你得知道服务器用的是什么线路，不同的网络线路代表的服务器的带宽是不同的，避免线路的质量不稳定的情况。比如服务器是电信区，使用联通线路，定受影响。选择机房的带宽选骨干线路，速度快，稳定性强。首先看机房到企业建站之间要经过多少个路由，接入的路由设备离骨干网的位置，条数越少越好。

2、服务器网络稳定性

Ping测试。通过本机的PING命令进行持续ping，通过查看丢包率、最大值、最小值等数据来分析机房的网络品质和带宽质量。

第1种方法：常见的ping命令。

在电脑中点击开始，运行，然后输入CMD打开DOS命令窗口。然后输入网站网址，或者服务器的IP地址，格式为ping域名，或者pingIP。使用ping命令后，会反馈一个结果，这个结果基本包括了以下几个信息。

Time，这个是响应时间，时间越小越好，国内服务器响应时间一般在20-60ms之间。

TTL，这个可以判断相关的操作系统，TTL=119，则表示是XP系统，不过这个现在一般不准，毕竟服务器可以修改注册表TTL类型。数据包发送信息，这个里面有个丢包率，数值越小越好，正常都是显示丢失0。丢包严重的话，哪怕一直连接，效率也不行。

第2种方法：tracert命令。

测试方法与ping命令类似，只是将ping换成tracert，不过这个命令可以用来检测终端用户到服务器机房的跳数及响应时间，换句话说，就是可以测试出服务器与全国客户的连接速度。显示时间也是以Ms为单位，时间越短越好。

第3种方法：比网站加载速度。

可以利用WhichLoadsFasterFastSoft工具测试一下打开网站速度。就是上网，在浏览器中让两个真实的网页显示出来，反应的结果就是两个网站真实打开速度对比。

第4种方法：网站速度测试工具。

使用GTmetrixgtmetrix有丰富的测量结果，能够提供相关的网站速度提升建议，站长可以根据这些建议优化站点。然后再逐一找到加载速度变慢的原因。此外，还有一点就是带宽的选择。关于带宽服务器一般有共享和独享两种选择，若本身是普通的网站使用共享的带宽是可以的，但若是对带宽要求高的行业选择独享带宽。

3、服务器带宽测试

测试其下载速度。通过运营商区域分段测试，看看最大下载多大速率，就可以查看到其实际带宽的速度、安全性和稳定性。

我们知道，一个网站如果在好几秒都打不开，那么基本上都会没有耐心，会关闭页面，而这无形当中就是流失了用户。但总体来看，企业主租用服务器一般只需要从四个方面入手，分别是售后服务、服务器的稳定性、带宽资源以及价格，如果这四个方向把握准确，以上就是租用服务器前对网络质量测试方法，希望对站长有一定的帮助。

1 可以用专用工具测试，例如：

Netperf（wwwnetperforg）：网络性能测试。主要针对基于TCP或

UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即批量数据传输（bulk data

transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统

发送数据，以及另外一个系统能够以多块的速度接收数据。Netperf工具以client/server方式工作。

server端是netserver，用来侦听来自client端的连接，client端是 netperf，用来向server发起网络测试。

2 自己写代码测试，参考：

http://kmplayeriteyecom/blog/673226。

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。

　　正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。

　　一些测试方法主要分以下几种：

　　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如：宕机、应用异常中止等)。

　　Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

　　Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

　　另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称(如：lr_rendzvous("same");)在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

　　稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

　　根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能)，估算最终并发用户人数。

　　场景设计思想：

　　从稳定性测试场景的设计意义，应分多种情况考虑：

　　针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

　　1)场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

　　2)场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

　　测试方法：采用1)Ramp Up-Load all Vusers simultaneously

　　2)Duration-Run Indefinitely

　　3)在Sechedule-勾选Initalize all Vusers before Run

　　容错性测试：通过模拟一些非正常情况(如：服务器突然断电、网络时断时续、服务器硬盘空间不足等)，验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统)，还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

　　问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

　　测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标(如：事务响应时间、最大并发用户数等)。

　　评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

　　评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。

　　评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。

　　评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

　　问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。

　　该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

随手机对人们生活中的影响越来越大，App测试工作逐渐被众人所知。从一开始的众包到现在的自动化探索，手机测试上的技术发展也是日新月异。

App测试相比以往传统的软甲测试相关要复杂的多且困难的多。

基于工作经验，我将如何做好app的测试归结为如下内容。

(1)   非功能测试

app测试的一个重要方面是app的非功能需求。移动app在推出市场或进行进一步开发前，测试人员有一定的职责做该类需求的跟踪工作。

早期开发阶段要进行的第一个测试应该是实用性测试。通常是由alpha用户或同事进行的。走进一家咖啡馆或餐厅，问问里面的人他们的app使用情况。让他们看看现阶段开发的第一个版本并收集反馈，看看用户是否能很好地使用新功能，以便得出第一印象。

(2)   功能测试

每项开发的新功能都需要进行测试。app测试中功能测试是一个重要方面。测试人员应该要进行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮、提交订单看看会发生什么，测试员还必须执行更多功能的app测试。

除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动Webapp。根据开发策略和结构，品质管理测试专家需找出最适合他们环境的自动化工具。

(3)   客户端性能测试

一个App做的好不好，不仅仅只反应在功能上。被测的app在中低端机上的性能表现也很重要。比如：一个很好玩的游戏或应用，只能在高端机上流畅运行，在中低端机上卡的不行，也不会取得好的口碑。

关于App的性能测试，我们比较关注的参数有：CPU，内存，耗电量，流量，FPS。同时也需关注一下App的安装耗时和启动耗时。

目前大家可能比较困惑的一个问题，多高的CPU，内存，耗电量，流量，FPS才算是符合发布的值呢？这里可以告诉大家，可以参考精品游戏的一些数值，将自己研发的app与业内精品的app数据做对比。

(4)   适配兼容测试

App在经过功能测试后，也需对其进行适配兼容测试需要检查的项主要有以下几点：

(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常；

(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常；

我们在实际测试中，常常会遇到下列问题：

(a) 在某个平牌某个系统上，app安装不上；

(b) 在某个平牌某个系统上，app无法拉起；

(c) 在某个平牌某个系统上，app拉起后无响应或拉起后黑屏、花屏；

(d) 在某个平牌某个系统上，app无法顺利卸载；

（WeTest腾讯质量开放平台）这个产品可以实现多款热门机型的适配兼容测试。

(5)   弱网络测试

App在使用的过程中，难免会遇到弱网络环境，例如在公车上、在地铁里。在这种情况下，常常会出现网络抖动、上行或下行超时，导致应用中出现丢包。

作为一个测试人员，我们要对app在上线前做一定场景的弱网络环境模型，并查看app在弱网络环境下是否存在某些未知的问题。下面是我们常用的弱网络环境场景：

(a) 3G弱网络信号场景模拟；

(b) 市区低速移动场景模拟；

(c) 郊区高速移动场景模拟；

(d) 请求回应超时_上行超时场景模拟；

(e) 请求回应超时_下行超时场景模拟；

(f) 网络抖动场景模拟；

(6)   耗电量测试

App在手机上的表现，除了功能外，app是否耗电，也是测试过程中重点要关注的一项。手机设备在满电的时候，这个App能玩多久；App每小时的耗电是多少；App在某个场景挂机10分钟耗电量是多少；这些都是我们平时在耗电量测试中比较关注的点。

(7)   协议测试

模拟客户端直接发送协议包给服务器，看看服务器是否有一定的校验，认不认客户端发过来的数据。协议测试，主要是为了处理用户发送恶意协议到服务器，骗过服务器的校验。

(8) 安全测试

App在上线前，都需要做详细的安全测试。安全测试主要为了检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。

(9) 服务器性能测试

服务器性能测试，主要包含单机容量测试和24小时稳定性测试。单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标。

这个可以在WeTest入口预约。

(10) 服务器容灾测试

服务器容灾测试，主要指某个服务进程奔溃掉后，是否具有自行恢复能力。比如游戏逻辑进程消失后，是否会自动拉起；memcached崩溃时，是否会重新启动，是否会对所有玩家有影响。这些都是app测试过程中需要考虑的因素。

(11) 中断测试

针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法，如：App在前台和后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。测试电话，短信，彩信，微博或其他通知进来时app的反应。

(12) 上线后期的舆情跟踪

新的app上线后，用户对此应用的评价，存在哪些测试期间未察觉的Bug，论坛上对于该应用热门的帖子有哪些，应用商店中该应用的口碑如何等，都是app在上线后，测试人员需要关注的点。若需要测试期间未发现的Bug，需要新测试服进行确认并根据该问题的修复。