页面性能规范

页面性能规范篇一：web 性能测试基本性能指标web 性能测试基本性能指标 （1）客户发送请求 （3）web server 向 DB获取数据；（4）web ser(转载于: 小 龙文档 网:页面性能规范)ver生成用户的 object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中） 。 1.事务（Transaction） b server 向 DB获取数据-生成用户的 object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。 2.请求响应时间 请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB” ，即“time to last byte“，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒” 。一个公式可以表示：响应时间网络响应时间+应用程序响应时间。标准可参考国外的 3/5/10原则： （1）在 3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的” ； （2）在 35秒钟内，页面给予用户响应并有所显示，可认为是“好的” ； （3）在 510秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的” ； （4）超过 10秒就让人有点不耐烦了，用户很可能不会继续等待下去； 3、事务响应时间 事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数. 4.并发用户数 并发一般分为 2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的 操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。 可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发” 。对于 WEB性能测试而言，这 2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。用户并发数量：关于用户并发的数量，有 2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把 5.吞吐量指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率. 6、 TPS（transaction per second） 每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标. 7、点击率 每秒钟用户向 WEB服务器提 交的 HTTP请求数.这个指标是 WEB应用特有的一个指标:WEB 应用是“请求-响应“模式,用户发出一次申请,服务器就要处理一次,所以点击是 WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和 TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个 HTTP请求. 8.资源利用率 指的是对不同的系统资源的使用程度, 例如服务器的 CPU利用率,磁盘利用率等.资源利用率是分析系WEB 性能测试中,更根据需要采集相应的参数进行分析。通用指标（指 Web应用服务器、数据库服务器必需测试项) Web 服务器指标 数据库服务器性能指标 系统的瓶颈定义稳定系统的资源状态通俗理解： 日访问量 常用页面最大并发数 同时在线人数 访问相应时间 案例： 一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略) 一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本) 一种则需要测试服务器能否接受 10万用户同时在线操作，如果是用 IIS做应用服务器的话，单台可承受的最大并发数不可能达到 10万级，那就必须要使用集 群，通过多台机器做负载均衡来实现；如果是用 websphere之类的应用服务器的话，单台可承受的最大并发数可以达到 10万级，但为性能考虑还是必须要 使用集群，通过多台机器做负载均衡来实现；通常有 1个简单的计算方式，1 个连接产生 1个 session，每个session在服务器上有个内存空间大小的 设置，在 NT上是3M，那么 10万并发就需要 300G内 用户同时在线，跟 10万个并发数是完全不同的 2个概念。这个楼上已经说了。但如何做这个转换将 10万时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这 2个数据的比例就是你同时在线用户数据） ，一般 1台双CPU、2G 内存的服务器上可支持的最大并发数不超过 500个（这个状态下大部分操作都是超时报错而且服务 器很容易宕机，其实没什么实际意义） ，可正常使用（单步非大数据量操作等待时间不超过 20秒）的最大并发数不超过 300个。假设你的 10万同时在线用户转 换的并发数是 9000个，那么你最少需要这样的机器 18台，建议不少于 30台。当然，你要是买个大型服务器，里面装有 200个 CPU、256G 的内存，千 兆光纤带宽，就算是 10万个并发用户，那速度，也绝对是嗖嗖的。另外暴寒 1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿 1个系统来压一下看看，可能会出现以下情况： 1、服务器宕机； 2、客户端宕机； 3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误； 4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到 10K，这个速度接近 1个 64K的 MODEM上网的速度；另外以上分析 1、服务器方面：上面说的那样的 PC SERVER需要 50台； 2、网络方面：按每个用户 50K，那至少 5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的；务器至少需要 10台 4CPU、16G 内存的机器；4、如果有 CORBA，那至少再准备 10台 4CPU、16G 内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个 1000万的资金投入，肯定搞不定。 这样的门户系统，由于有用户权限，所以并不象 jackie所说大多是静态页面。但只要是多服务器的集群，那么我们就可以通过 1台机器的测试结果来计算多 台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，比如带宽、速度、延迟等。但如果都是在 1台机器上变化，那我们只能做一些指标上的计 算，可以从这些指标上简单判断一下是否不可行，比如 10万并发用户却只有 1根百兆带宽，那我们可以计算出每个用户只有 1K带宽，这显然是不可行的。但实际 的结果还是需要测试了才知道，毕竟系统压力和用户数量不是线性变化的。 这一类系统的普遍的成熟的使用，以及很多软件在方案设计后就能够大致估算出系统的性能特点，都导致了系统在软件性能方面调优的比例并不大（当然不完全排 除后期针对某些代码和配置进行优化后性能的进一步提高） ，更多的都是从硬件方面来考虑，比如增加内存、硬盘做RAID、增加带宽、甚至增加机器等。 网络技术中的 10M 带宽指的是以位计算， 就是 10M bit /秒 ，而下载时的速度看到的是以字节（Byte）计算的，所以 10M带宽换算成字节理论上最快下载速度为： M Byte/秒! 篇二：Web 测试规范Web 测试规范 前言：本文基于 Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器下显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。 本文将 web 测试分为 8 大部分： ? 功能测试 ? 性能测试（包括负载和压力测试） ? 用户界面测试 ? 兼容性测试 ? 安全性测试 ? 接口测试 ? 故障恢复测试 ? 安装/反安装测试 1 功能测试 ? 概述：确保测试的功能正常，如导航，数据输入，处理、检索是否正确，以及业务规则的实施是 否恰当。即对交互的输出或结果进行分析，以此来核实应用程序及其内部进程,这是目前的测试重点。 ? 目标：利用有效的和无效的数据来执行各个用例流程，以核实以下内容： ? 在使用有效数据时得到预期的结果 ? 在使用无效数据时显示相应的错误消息或警告消息。单一界面测试的参考表格如下： 具体功能测试参考表格如下： 注：除测试所提供的功能外，还需添加 Cookies测试 参考如下： Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies访问了某一个应用系统时，Web 服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 如果 Web应用系统使用了 Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括 Cookies是否起作用，是否按预定的时间进行保存，刷新对 Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。 采取措施： 1.采用黑盒测试：采用上面提到的方法进行测试 2.采用查看 cookies的软件进行（初步的想法） 可以选择采用的软件:IECookiesView 或者 Cookies Manager 链接测试 链接是 Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL地址才能访问。 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web应用系统的所有页面开发完成之后进行链接测试。 采取措施：采用自动检测网站链接的软件来进行。 推荐软件：Xenu Link Sleuth 免费 绿色免安装软件 或者 HTML Link Validator 共享（30 天试用） 表单测试 当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。 当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。 数据库测试 在 Web应用技术中，数据库起着重要的作用，数据库为 Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。 在使用了数据库的 Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。 采取措施：已经结合到表单测试和内容测试中去了! 应用程序特定的功能需求 最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。 采取措施：深刻理解需求说明文档，手工测试为主。说明：功能测试可以尝试 Mercury公司的 WinRunner(功能自动化测试工具)和 QuickTest Professional，不过因为具体需求和实际操作的不同，自动化测试实施困难，目前主要还是手工测试为主！ 2 性能测试 ? 概述：主要是对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评 测的目标是核实性能需求是否都已满足。 ? 目标：核实下列情况下的性能行为： ? 正常的预期工作量 ? 预期的最繁重工作量 ? 需考虑的特殊事项： ? 可创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。 ? 最好使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。 ? 应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。其 所用的数据库应该是实际大小或相同缩放比例的数据库。 ? 多用户不同网络条件下的连接速度是否满足要求 篇三：前端性能优化方案前端优化方案 1. 提升页面静态资源加载速度 .1 减少 Http请求 .1 项目首页、访问量非常大的页面有自己单独 css内容 . 1 移除重复的脚本及样式，统一网站资源（js 库、css库）的使用。 . 2 整理优化并合并现 css文件及 js文件，将所有的 css文件以及 js文件 分为 base、common、page 三层 .2 压缩静态资源文件，减少文件体积大小 .2 采用 CSS Sprites技术将页面内所有背景小图标整合到一张图片。 2 不要在 HTML使用太多大图像 . 2 采用开源工具来压缩减小 css及 js文件体积 . 2 内嵌图像。 .3 静态资源尽量合并到少数几个域名访问，减少 DNS查询 3 2. 加快页面的渲染展示速度 .3 Css 和 js文件的位置 . 3 规范 img标签的使用 .3 精简页面标签，减少 DOM元素 . 4 规范 Css代码 .4 3. 服务器端静态资源访问优化 .4 服务器部署时通过 web服务器及应用服务集群配置，让静态资源通过 web 服务器提供访问，提高静态资源并发访问效率 . 4 通过在 web服务器配置静态资源的缓存以及压缩策略，提高用户访问速度. . 4 通过第三方网络静态资源缓存服务(CDN)，提高网站访问速度，提升用户访 问体验。 . 4 1. 提升页面静态资源加载速度 减少 Http请求 项目首页、访问量非常大的页面有自己单独 css内容 静态页面生成时直接生成到文件中，动态文件的话在模板文件中 include。 移除重复的脚本及样式，统一网站资源（js 库、css库）的使用。整理优化并合并现 css文件及 js文件，将所有的 css文件以及 js文件分为 base、common、page 三层 其中 base是全站通用的，部署在上；common 的为某业务系统全局使用，page 的则为单独页面使用，这两部分部署在业务系统中。在整理优化过程中，去掉无用的 css样式以及 js脚本程序 base 类别的 css及 js统一放到 res项目中统一维护。页面中不允许出现 onclick或 onblur或其他方式的js小句子的使用，所有的标签事件定义及绑定以及其他 js代码均要基于 res中提供的统一 Jquery框架，并放到在整个页面的底部。 所有项目的 css以及 js文件必须放置到项目根目录下的 css以及 js目录下，这样的目的是方便代码上传时进行压缩处理。 压缩静态资源文件，减少文件体积大小 采用 CSS Sprites技术将页面内所有背景小图标整合到一张图片。 通过 css中 background-position来定位背景图。把多张图片组合成一个单一的形象。整体大小相同,但减少HTTP请求的数量加快页面，但是原则是大图的大小不能超多 100k。 不要在 HTML使用太多大图像 图片切图尽量少和小，按所需的规格来切。切完后的图片文件不能太大，必须要压缩，且尽可能的压缩到最小。首页等页面的图片尽量调用小图。 采用开源工具来压缩减小 css及 js文件体积 在上传发布时使用开源工具（Closure Compiler，该工具压缩的 js是类似于 jquery一样，不可逆）将 js文件进行一定的压缩。 考虑采用第三方的服务器端的压缩并合并访问技术，例如 Minify等，合并对多个 js或者多个 js的访问请求。（这部分待同意研究后考虑决定采用何种压缩工具） 所有项目代码上传发布时，使用 Closure Compiler工具将项目指定的 css目录、js 目录下 的 css文件以及 js文件进行压缩（压缩完成后要求保持文件名不变） 。内嵌图像。 用 data:URL scheme的方式把图片内容代码直接嵌入html代码中，这样会增大 html代码的体积，改进的方式是把内嵌图片嵌入到 css中（css 被缓存） ，这样就会更好的减少 http请求数而且不增大 html的体积。这种方式适用于不经常变化的背景图等。 静态资源尽量合并到少数几个域名访问，减少 DNS查询 页面程序所调用的静态资源，应该尽可能来自于仅仅少数几个域名访问。 2. 加快页面的渲染展示速度 Css 和 js文件的位置 Css 文件必须放在 header中 无论是 HTML还是 XHTML还是 CSS都是解释型的语言，而非编译型的。所以 CSS到上方的话，那么浏览器解析结构的时候，就已经可以对页面进行渲染。这样就不会出现页面结构光秃秃的先出来，然后 CSS渲染，页面又突然华丽起来这种页面浏览体验了。 把 Js文件放到 HTML最下面 a) 原因一：脚本一般是用来于用户交互的。所以如果页面还没有加载完毕时加载 js 是不正确的做法，比如 js里如果对页面的某以特定元素绑定事件或者修