与测试有缘

发布新日志

  • Good Enough Quality

    SpiderMan 发布于 2007-02-01 10:44:42

     http://www.csai.cn  作者:袁琳  来源:希赛网  2006年12月1日

      软件行业飞速发展,软件企业面临日趋激烈的市场竞争,常常面临这样的问题:
    如何不断推陈出新,保持持续的竞争力。
        如何在短时间内完成软件产品或软件项目的研发,最大化的满足客户需求。
        如何及时跟踪不断变化和升级的开发方法、技术实现方式,来提高研发效率。
        显然,这些问题反映出当前的软件开发模式越来越趋向于由市场驱动,软件企业需要不断适应市场变化、适应不断增长的用户需求、尽快研发并发布新产品、同时需要创造出高质量的软件产品。因此,对于软件开发来说,做好软件项目开发过程中时间、成本、质量的平衡尤为关键。软件开发的时间、成本是有限的,在给定的产品或项目背景下,如何控制软件发布质量、交付用户最满意的产品是一个巨大的挑战!
     
        很多人会说,在激烈的市场竞争面前,产品质量是企业的命脉,是重中之重,必须要保证软件产品的“零缺陷”,于是他们便挖空心思生搬硬套 6sigma、CMM… 结果导致软件开发过程过于形式化、官僚主义,软件创新迟缓、不能快速占领市场,产品交付给用户后,用户说:这不是我想要的!
     
        诚然,产品质量是企业生命的基石。不可否认,6sigma、CMM 是值得研究学习的科学理论,在军事航天、科研探索、大型电信领域都有非常成功的案例。但是,国内的众多中小企业面临巨大的市场竞争压力与内部发展创新的需要,还一味照搬6sigma,就值得反思了,是否有必要耗费大量时间、资源追求每百万个产品的不良品率少于3.4呢?
     
        我们总是期望某种软件开发模式或开发方法能够适用任何类型、特点的软件开发过程,能够开发出高质量的软件产品,可是每当我们实际应用时,却总是会发觉,理想与现实的巨大差距。所以,软件开发方式、质量控制原则的实用性更重要。必须针对不同的软件开发特点,制定不同的质量控制原则。
     
        随着各种敏捷开发方法及其它一些“轻量”开发方法的逐渐兴起,越来越多的软件组织意识到敏捷方法对于软件新产品开发有着良好的指导作用,在市场竞争中能够快速影响需求、缩短研发周期、及时放量发布,这样更有利于降低软件开发过程中的各种风险,通过不断与用户的沟通反馈,不断交付给用户满意的软件产品。越来越多的软件开发团队开始尝试各种敏捷实践,同时也在探索敏捷开发过程中的质量原则。在敏捷开发中,倡导质量Good Enough就OK,那么这个Enough到底是多少呢?在没有明确的原则的情况下,Good Enough  Quality(GEQ)概念滥用,满意质量常被用来为软件中明显存在的缺陷做辩解,甚至有人认为软件供应商在软件产品中保留臭虫(Bug)是一种蓄意行为甚至是聪明的策略,这无疑造成了很大误解。
     
        在2001年“敏捷联盟”建立之后不久,著名的软件测试科学家James Bach根据自己多年的实践经验和理论基础就针对不同软件开发的方法在满意质量的基础上提出了相应的质量原则。
        满意质量的原则进行了系统化定义,满意质量定义如下:
        (1)可带来足够的利益;
        (2)不存在致命性问题;
        (3)所带来的利益超过问题所造成的损失;
        (4)在当前条件下综合考虑所有因素后,进一步的改进所带来的损害大于其带来的帮助。
     
        同时,James Bach提供了一个用于评估GEQ的框架,该框架包括四个GEQ元素和六个GEQ视角,它们构成了一个提示问题集,可用来帮助相互沟通,或者帮助进行产品开发、产品改进、实现更好的实践活动等。GEQ框架的概要描述:
     
    GEQ元素(factor)
      四个元素基于GEQ的定义进行扩展,为评估软件产品质量。 
        1. 评估产品的利益
      鉴别——对于产品的受益人而 言具有什么已知利益或潜在利益?
      可能性——假设产品正如所设计的那样工作, 受益人有多大可能性会认识到每个利益?
      影响——对受益人而 言, 每个利益的期望程度如何?
      个体重要程度——从个体考虑, 哪些利益是完全不 可替代的?
      整体利益——作为一个整体且假设没有问题, 是否具有足够的利益以满足受益人? 
        2. 评估产品的问题
      鉴别——对于产品的受益人而 言具有什么已知问题或潜在问题?
      可能性——受益人有多大可能性会发现每个问题?
      影响——对受益人而 言, 每个问题的破坏程度如何?是否可以继续工作?
      个体重要程度——从个体考虑, 哪些问题是完全不 可接受的?
      整体问题——所有问题叠加在一起会怎样?是否有太多的非关键问题? 
        3. 评估产品质量
      整体质量——根据GEQ视角, 利益是否看来超值于问题?
      安全/完美边际值——如果需要或想要使利益超值于问题, 那么至少需要投入多少? 
        4. 评估改进产品的后勤问题
      策略——有哪些策略可用于改进产品?
      能力——具备 实现这些策略的能力吗?知道如何做吗?
      成本——改进工作需要多少成本或存在什么麻烦?是否充分利用了资源
      进度——能否立即开始或稍 后再改进?能否在可接受的时间范围内实现改进工作?
      利益——改进效果明确吗?有附加利益吗(如更好的士气)?
      问题——改进工作会有多大可能带来负面影响(例如, 引入错虫、损伤士气、占用其他项目资源)?

    GEQ视角(perspective)
      GEQ元素是评估软件产品质量的必要条件而不是充分条件。为了执行可靠的评估,还必须同时从六个关键视角来检查每个元素:
      1. 受益人——哪些人关于质量的意见起作用?(例如,项目团队、客户、商会、法院等)
      2. 关键目的——什么是必须达到的?(例如, 即时生存、利润、市场份额、客户满意度等)
      3. 时间尺度——质量改进成果的时间敏感性如何?(例如,立即、近期、长期、某个关键事件之后等)
      4. 替代物——本产品与替代物相比如何?(例如,竞争对手的产品、服9. 务或解决方案)
      5. 失败结果——如果质量比GEQ稍11. 差一些会怎样?是否需要对突发事件进行规划?
      6. 评估质量——评估本身的可信度如何?是否令人满意?

        满意质量不等于轻视和放弃软件产品的质量工作,它更强调用理性的思维去分析软件产品或软件项目面临的市场压力、风险状况、种种困境,对软件产品的质量做出理性的决策,而不是循规蹈矩、死板的、刻意执行一些被强制的行为。因此,满意质量被认为是实用主义、功利主义的产物,即倡导使软件开发公司在短期内快速开发出满足用户需求、令用户能够满意的产品,而不是一味的追求完美、追求软件质量的“零缺陷”。对软件公司来说,也应该是最实际的策略,能够有效把握时间、成本、质量等各方面的利益的平衡,满足用户需要的同时,创造最大化的价值。
        满意质量的思想已经开始不断被更多软件开发组织认可,很多软件企业开始尝试基于满意质量思想的各种实践,有些企业甚至鼓励尽早将产品投放市场,发布给用户,让用户参与Beta测试,由用户反馈试用过程中的各种体验和问题,这样企业在同用户在逐步的协作中不断提高质量和用户满意度,最终提供给用户满意的产品,同时也迅速占领市场,达到双赢的目的。

  • 如何评价测试人员的工作绩效?

    SpiderMan 发布于 2007-02-01 10:39:23


    Author:袁琳
    MSN:testwin@sohu.com


         随着国内软件测试行业的不断发展,软件测试工作更加深入、规范。其中对测试人员的绩效考核也越来越重要。目前,很多公司对测试人员的考核方面都不相同,有些公司仍然是以单纯的问题单数量来对测试人员进行评价,这样直接对测试人员工作方向产生误导,影响到测试人员工作的积极性和稳定性。因此,为了能够更好对测试过程进行管理,必须对测试人员有一个客观、全面的评价。下面是本人在工作中的一些体会希望能给大家带来一些启发:


    一、测试人员工作绩效评价的误区
    1、 仅从提交的问题单数量、测试执行用例数量来判断测试人员的好坏
    这种做法明显缺乏全面性。问题单的数量只是评估测试质量的一个方面,我们更需要看中实际的测试质量。这就需要考察问题单的质量、测试的难度、问题单的级别。
    例如:模块A很不稳定,潜在的问题数可能有100个,由测试人员甲负责测试,他一个月执行300个用例,提交50个问题单,发现30个有效问题,有10个严重问题;
    模块B比较稳定,潜在的问题数可能有20个,由测试人员乙负责测试,他一个月执行100个用例,提交20个问题单,发现18个有效问题,有8个严重问题;
    从上述测试执行结果来看,甲提交的问题单数量和执行用例数量都要远远高于乙,但是从测试的质量来看,模块B的遗留问题显然少于模块A,甲执行测试的充分性显然不如乙,从问题单质量来看,甲提交的问题单虽然很多,但近半数是非问题,做了无用功,还影响到开发人员对问题的定位所消耗的时间。
    因此,必须要走出用问题单数量、用例数量评价测试人员的误区。

    2、 对测试人员发现的问题的价值没有进行评估
    发现1个系统架构设计方面存在的缺陷和隐患,远比发现几个普通界面的显示问题要有价值的多。因此,在对测试人员进行评价时,必须区分不同问题的重要性和价值。

    3、 不重视测试文档的质量
    测试文档的质量往往是测试人员的测试水平的反映,只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告,说明测试的全面性和测试过程的质量。

    4、 不重视测试人员的综合能力
    首先,必须考察测试人员的责任心,如果一个测试人员工作不符责任,随意敷衍,即使提交的问题单数量多,也不能证明他测试的质量高。其次,需要关心测试人员的工作积极性,积极工作的态度不仅能带来很高的测试质量,还能提高整个团队的积极向上的风气。还有,测试人员的沟通能力,如果一个测试人员和开发人员对问题沟通交流不畅,甚至经常引发争执,这显然会影响测试工作的效率。


    二、建议对测试人员进行综合性的全面评价
    评价方法如下:

     

     




    三、总结
    综上所述,必须本着以测试质量为重、对测试负责的角度对测试人员绩效进行客观评价,同时也提高测试人员的质量意识。通过合理的绩效评价,让测试人员以积极的心态投入的测试工作中,保证测试工作的顺利进行。

     

  • 自动化测试的流程

    songfun 发布于 2007-01-31 14:08:37

    早上看到我们的学员发的一个贴子(http://bbs.51testing.com/thread-63522-1-1.html),是关于自动化测试流程的一些问题。我也参与了讨论,感觉还不错,呵呵,就整理了一下搬到博客上来,和大家一起分享、交流。

    ==============================================

    wssgily:

    我想请教几个自动化测试流程.

    请问大家,你们公司的自动化测试是什莫阶段开始介入的?
    自动化测试的入口和出口准则是怎样定义的?
    大家又是如何保证自动化测试的质量的?

    --------------------------------------------------------

    xiaonan:

    自动化测试是在测试执行阶段介入的.然后更多的用于后期的回归测试阶段.

    入口条件:
    其一:在制定测试方案时,觉得某部分功能测试,适合用自动化工具来完成.那么这部分用例就写的更加细致一点,等这部分用例已经完成.并达到了用例设计的标准,所有需求都已经完全覆盖到.
    其二:系统已趋于一个稳定的阶段,不会再有大的改动.
    达到这两个条件可以开始自动化测试.

    出口准则:
    所有用例全部被执行.测试报告已经通过评审.这部分可以和手工测试的要求相同.

    首先测试质量在于前期的准备,包括用例的质量啊.自动化测试也不例外.还有保证录制的脚本能正确执行用例的意思.所以要保证脚本的质量.

    --------------------------------------------------------
    wssgily:
     
    个人理解的是自动化应该在回归测试或者软件基本功能或者流程已经成型的条件下而且以后变动不大的情况下,就可以开始跑脚本了.

    如何保证质量:还是要看测试用例的质量,如果提高测试用例的质量,还是要看对SRS理解的程度有多深,能提取出多少个测试点来.然后把有效的测试点和质量特性和要验证的特性相结合,来写测试用例和提高覆盖率.

    个人认为自动化还是要看测试用例质量有多高的,还有就是前期准备相当重要.到最后实现起来就解决技术难点就行了.呵呵!

    欢迎大家讨论自动化流程方面的东西。
    --------------------------------------------------------
    songfun:
     
    自动化测试就和单元测试、集成测试、系统测试等阶段一样,都是一个独立而且完整的测试阶段。
    它要经历自动化测试计划、自动化测试设计、自动化测试实现和自动化测试执行四个阶段(这就是所谓的V模型)。

    楼上几位朋友所描述的是一个不完整、不规范的测试过程。这样的自动化测试实施起来的效果就不好说了。

    按阶段来看的话,它介于集成测试和系统测试之间,或者说是介于集成测试和确认测试之间,又或者贯穿于集成测试、确认测试和系统测试这个阶段(这就是所谓的H模型)。具体要视具体情况来制定。比如你们的集成测试是做到子系统间的集成,那么这个阶段已经可以引入自动化测试了,要注意的一点是这个自动化测试最好由独立的自动化测试团队来完成,使得项目进度不至于在关键路径上停留,可以并行开展。

    入口和出口准则相对比较容易。就像系统测试会进行系统预测试一样,自动化测试有自己的自动化测试用例,这部分的用例可能选取自系统测试用例或确认测试用例,而且很大一部分可能就是来自系统预测试的用例。通过执行这些用例可以获得出口的准则(这里只是指自动化测试活动的通过标准,不是软件系统的通过标准),就是:所有的自动化用例100%的得以执行,用例密度达到10cases/Kloc(这个数字只是举例而已)。而入口准则则是通过了冒烟测试(但是这不是绝对的,有可能是系统预测试之后)。
    这里要把冒烟测试、BVT测试和系统预测试几个概念弄清,冒烟测试一般是由开发人员执行的,可以没有测试用例,这种测试是带有随机性质的。BVT测试发生在每日构建中,通常正是由自动化测试工具来执行的。系统预测试由测试人员选取重要级别相对较高的系统测试用例来进行。
    之所以这样安排是因为:自动化测试能在人之前发现错误,避免浪费无味的人力资源。
    其实如果安排在系统预测试之后也是一种方案。它的意义在于:对于系统趋于稳定的时候适合采用这种方案。而前面的那种方案适合在测试用例相似性非常大的系统中开展。
    这里又要纠正一个误区:自动化测试并非只是适合在需要大量回归的测试执行时才需要的。比如我们现在只做两轮的测试,这种情况是否就一定不适合采用自动化测试?答案是否定的,假如我们的系统有如下的特征性还是可以采用自动化测试:测试用例具有极大的相似性。也就是说,可能测试的步骤都是一样的,只是输入参数的不同。假设我们现在有一千条测试用例,每个用例的步骤都是一样的,只是输入数据不同(也就是说等价类非常多),那么这种情况即使只做一轮的测试,没有回归,也还是可以采用自动化测试的。

    关键是要结合具体情况进行具体分析。不能盲目的把书本上、课堂上的知识照搬照套。企业需要能随机应变的工程师。

    至于说保证自动化的质量,那就不止是自动化本身的问题了。它取决于:人、技术、过程。好的过程需要有SEPG的参与,SQA的监督和指导。
    保证了三者,才能保证自动化的质量。
  • 开发出高性能的网站 (一) 20个客户端代码优化技巧

    pele 发布于 2007-01-08 13:33:05

    这个分为三部分的文章概述了一个直观的、省时省力的方法来提升访问网站的速度,这是基于网站性能有关的两个简单法则:


    • 尽可能的减少数据的传输量
    • 尽可能的减少数据的传输频率

    若使用得当,此两条法则会:


    • 提高网页的加载速度
    • 降低服务器使用的资源
    • 提高网络带宽利用率

    使用这些技巧来开发网站,不仅能够提高用户对一个网站或者是基于web的一个应用的满意度,更可以节约网站数据传输的成本。这篇文章所讲述的技术细节可帮助我们写出很好很实用的代码,从更广泛的角度来讲,这也将会给网站打造出良好的可用性基础。

    第一部分 – 20个客户端代码优化技巧


    为自己写代码,为使用而编译

    任何一个程序员都很清楚地知道,之所以不把自己所使用的代码作为最终的代码来交付是有它合理的原因的。写代码时最好要尽可能多写些注释,通过编排格式在最大程度上提高代码的可阅读性,同时避免过分的简洁不让晦涩的代码给日后的维护带来困难。之后,我们再使用编译器等把源代码转化成其他格式,一方面达到最优执行,另一方面可以防止反编译,以免造成源代码被剽窃。上述的这种模式其实也适用于网站的开发。具体做法是:先制作好网站和网页的源代码,再利用一些简单的技术(比如:减少空白区域,进行图片和脚本的优化,文件重命名等)把源代码减肥然后你就可以将准备好的网站和网页交付使用了。

    希望这种概念对于你来说并不突兀,因为起码你很有可能正是在您站点的副本上操作,而不是直接在正在运行的站点上作修改更新。如果你不是这样做的,那么请马上停止阅读本文,赶紧去给你的站点做个副本吧!无论您的网站的内容是静态的手册还是非常复杂的使用内容管理系统来驱动(CMS-driven)的应用,这都是唯一正确的开发网站的方式。你要是现在还不相信的话,那么我敢说很快的等到你损毁了网站的一些文件却发现难以恢复的时候你就信了。

    在建造网站时,您可能会把注意力放在导致下载速度降低的最大元凶—图片、二进制文件(如Flash等)上。减少GIF图片文件的颜色数、压缩JPEG图片文件的大小、优化SWF文件固然颇有裨益,其他大有帮助的方法也不能小觑。要记得网站性能法则中的第一条,我们得不断的努力以尽可能少地传输数据,不论它是markup文件、图片还是脚本。把精力放在减少(X)HTML、CSS和Javascrīpt文件的字节数上似乎是瞎忙乎,可是,这可能恰恰就是最应该注意的地方。

    在一个典型的网页加载过程中,(X)HTML文件是最先被浏览器读到的。既然这个文件决定了其他文件的关系,我们可以管这个文件叫主文件(host document)。浏览器一旦接收到这个主文件,便开始解析各种markup;一般在解析的同时,也会触发一系列对相关对象的请求,例如外部脚本、关联的样式表单、图片、或嵌入式Flash等等。这些CSS和Javascrīpt文件有可能继续触发一些对相关图片或脚本等的请求。这些对相关文件的请求排成队列的速度越快,它们到达浏览器的速度也就越快,从而越早的开始显示出页面来。了解了主文件的重要性,我们便知道把它尽快地传给浏览器并加以解析的重要性,因为尽管主文件本身相对来说整个传输量来说只是一小部分,它却能够严重地阻碍网页的加载速度。要明白,用户才不在乎你使用的字节数的多少,用户在乎的是时间!

    那么您具体需要怎么做才能作到最优传输的万全准备呢?一个基本的方法是减少空白区域,精简CSS和Javascrīpt,更改文件名,以及对要提交的代码也采用前述相同的策略,使之越简洁越好(Google 就是一个例子). 这些目前大家都熟知的通用技巧,在很多网站和一些书中比如Andy King的 《Speed up Your Site: Website Optimisation 》都能找到。本文则列出我们认为最有效的优化markup和代码的二十大技巧。当然,您可以手动来做部分优化,或者使用网页编辑器及工具来完成一些优化,当然还可以开发出您自己的精简工具。我们要向你介绍一个由Port80软件公司开发的工具w3compiler. 它几乎实现了下面将要提到的所有技巧,而且它也反映出在“真实”世界里代码优化任务的商业价值。接下来,我们来谈谈这些技巧!

    Markup优化

    典型的markup要么是手工编辑出来的,在非常紧凑,注重标准的格式基础上加入注释和空白区域(white space)的文件;要么是编辑器生成的,非常之肥胖,带有过分的格式编排及编辑器特有的通常用来控制结构的注释,甚至还会有不少重复的和没有用修饰或者代码。这两者都不是最优传输的情况。下列技巧既安全又容易,是减小文件尺寸的好方法:

    1、尽可能的除去空白区域

    一般而言,空白区域字符(空格、制表符、换行符等)都可以安全删除,但要避免修改pre, textarea, 及受CSS属性中white-space影响的标签。

    2、除去注释

    除了在客户端给IE和doctype声明的条件注释外,几乎所有的注释都可以安全去除掉。

    3、使用最短格式的颜色表示

    使用颜色时,不要一股脑的使用十六进制或全颜色名称(full color name),要尽可能根据实际情况使用最短格式的颜色表示。比如,一个为#ff0000 的颜色属性可以直接用red</code来说明,而lightgoldenrodyellow可以换成 #FAFAD2#FAFAD2

    4、 使用最短格式的字符表示

    和最短颜色表示一样,一些名称可以用最短字符来表示,我们可以用较短的数字来代替某些长长的字母。比如:&Egrave; 可以变成È。或者,偶尔这个方法反过来也行,比如:ð 如果变成&eth则可以省一个字节。不过,这个方法不太安全,而且成效有限。

    5、 除去无用的标签

    有些‘垃圾’markup,比如使用了多次的重复标签或者某些编辑器里用作广告的meta 标签,都可以安全地被删除。

    CSS优化


    CSS也有一套成熟而又简单的优化方法。实际上,时下大多数的CSS都较 (X)HTML更容易压缩。下面所列的技巧除了最后一条都是安全的。最后一条涉及到客户端的网页技术,可能会变得比较复杂。

    6、除去CSS中的空白区域

    相比起(X)HTML来,CSS对于空白区域没有那么敏感,所以除去空白区域便可以极大地减少CSS文件和style样式表区域的大小。

    7、 除去CSS注释

    如同除去markup代码中的注释一样,由于CSS中的注释对普通的最终用户来说并没有什么实用价值,所以也应该被除去。不过,如果考虑到较低级的浏览器,则在CSS中的style标签中的屏蔽注释信息不可以被除去。

    8. 使用最短格式来表示颜色值

    和HTML一样,CSS颜色也可以用词语或十六进制格式表示。注意,在CSS中这样做的效果会稍微明显一些。主要是因为CSS中支持3位的十六进制色值,例如对白色可用#fff 来表示。

    9、对CSS的规则进行合并、减少或删除

    CSS中的诸如字体大小、字体重量等规则往往可以使用一种单属性字体的速记注释方式来表示。使用得当的话,这个技巧可以让您把如下的规则:

    p {font-size: 36pt;
    font-family: Arial;
    line-height: 48pt;
    font-weight: bold;}


    改写成下面简短的形式:

    p{font:bold 36pt/48pt Arial;}

    如果继承方法使用得当的话,您还会发现在样式表单中的一些规则可以显著的减少或干脆删掉。到目前为止尚没有能自动移除规则的工具,所以只能通过手工调整CSS向导(Wizard)来进行这些工作。不过即将推出的w2compiler 2.0会有这个功能。

    10、对类和ID值进行重命名

    在CSS优化中最危险的动作可能是重命名类或ID值了。看看如下规则:

    .superSpecial {color: red; font-size: 36pt;}

    可将其更名为sS。而对ID值一样可以遵循这样的原则,例如对于:

    #firstParagraph {background-color: yellow;}

    则可将原来的 ”#firstParagraph” 重命名为 ”#fp”,并在整个文档中重复这一动作 。诚然,这样做可能会涉及到“标识-样式-脚本”互相依赖的问题:如果一个“tag”有一个ID值,而这个值又可能不但用于样式表,还可能用于脚本参考,甚至可能是一个链接目标地址。在这种情况下,您一旦修改了这个值,您就必须得保证对所有相关的脚本和链接参考都进行了相应的修改,包括其他文件中的这个值,所以千万要小心细致。

    改变类的值相对改变ID值来说,危险性小一些。因为经验告诉我们,比较起ID值来说,大多数Javascrīpt程序员都不太经常处理类的值。然而,改变类的名称来缩减CSS的尺寸也面临着和改变ID名称同样的问题,所以再次强调,要小心谨慎。

    请注意:最好不要更改名称属性,尤其是表单区域中的名称属性。因为这些数值也会被服务器端程序所操作。虽然不是不可能,但对多数的网站来讲,要计算好这些相互依赖关系是困难的。

    Javascrīpt优化


    越来越多的网站都依赖于Javascrīpt来生成导航菜单、表格确认和其他各种各样实用的东西。不足为奇,大多数这些代码都非常笨重,亟待优化。对Javascrīpt代码的很多优化技术同那些用于markup代码和CSS的技术很相似。不过,对Javascrīpt的优化必须更加小心翼翼,因为一旦操作有误,其后果可能不仅仅是显示变形,并且可能导致网页残缺不全。下面我们先来看看一些最简单明了的方法,然后再探讨那些需要小心操作的技巧。

    11. 除去Javascrīpt注释

    除了 注释,其他所有的 // or /* */ 注释都可以安全删除,因为 它们对于最终使用者来说没有任何意义(除非有人想了解您的脚本是如何工作的)。

    12.除去Javascrīpt中的空白区域

    有意思的是,除去Javascrīpt中的空白区域并不象想象的那么有用。一方面,像如下代码:

    x = x + 1;

    显然可以简短得写成

    x=x+1;

    然而,很多随便的Javascrīpt程序员会忘记在两行之间加上分号,这时空白区域的除去就会带来问题。比如,下面合法的Javascrīpt使用了暗示的(implied)分号:

    x=x+1
    y=y+1


    草率地删除了空白区域则会产生如下表达式:

    x=x+1y=y+1

    显然,错误就产生了。但如果您加上必需的分号,如下:

    x=x+1;y=y+1;

    则在字节数上并没有减少。然而在此,我们仍然鼓励这种格式的变化,因为对w3compiler Beta版的测试反馈中,很多人对‘看起来压缩了的’脚本非常满意(也许这是因为视觉上确认了对原始代码的格式转变)。他们也喜欢这种处理方法产生的另一个效果,那就是让交付的代码变得更难读。

    13.进行代码优化

    简单的方法如除去暗示的(implied)分号,某些情形下的变量声明或者空回车语句都可以进一步减少脚本代码。一些简略的表达方式也会产生很好的优化,例如:

    x=x+1;

    可以写成:

    x++;

    不过得小心谨慎,不然代码很容易出错。

    14.重命名用户自定义的变量和函数

    为了阅读方便,我们都知道在脚本中应该使用象sumTotal这样的变量而不是s。不过,考虑到下载的速度,sumTotal这个变量就显得冗长了。这个长度对于最终使用者来说没有意义,但对浏览器下载则是个负担。这个时候s就成为较好的选择了。先写好方便阅读的代码,然后再使用一些工具来处理以供交付。这种处理方式在这里再一次展示了其价值所在。将所有的名称都重新用一个或两个字母来命名将带来显著的改善。

    15.改写内建(built-in)对象

    长长用户变量名会造成Javascrīpt代码过长,除此之外,内建(built-in)对象(比如Window、Document、Navigator等)也是原因之一。例如:

    alert(window.navigator.appName);
    alert(window.navigator.appVersion);
    alert(window.navigator.userAgent);


    可以改写成如下简短的代码:

    w=window;n=w.navigator;a=alert;
    a(n.appName);
    a(n.appVersion);
    a(n.userAgent);


    如果这几个对象使用频繁的话,这样改写带来的好处就不言而喻了。事实上这些对象也的确经常被调用。然而我要提醒的是,如果Window或Navigator对象仅仅被使用了一次的话,这样的替换反而使代码变得更长。所以手工进行这种优化时要格外小心,不过好在目前市面的常用的Javascrīpt代码优化工具都已经考虑到这个因素了。

    这个技巧带来一个对象更名后脚本执行效率的问题:除了代码长短上带来的好处,这种改写更名实际上还会稍微的提高一点脚本执行的速度,因为这些对象将会被放在所有被调用对象中比较靠前的位置。Javascrīpt游戏开发程序员使用这个技巧已经有多年了,下载和执行速度都会有所提高,并且对本地浏览器的内存花销也会降低,可谓一石三鸟。

    文件方面的优化


    最后一类的优化技巧与文件和站点的组织有关。下面谈及的一些技巧可能会牵扯到服务器的调整和站点的重构。

    16.重命名用户访问不到的独立文件和目录

    一些站点往往包含有诸如SubHeaderAbout.gifrollover.js等是用户无法通过URL来访问的文件。它们通常都保存在一个标准名称的目录中,比如/images,因此我们常常会在markup代码中看到这样的句子:

    <img src="/images/SubHeaderAbout.gif">

    或者更糟糕的象

    <img src="../../../images/SubHeaderAbout.gif">

    既然这些文件从来都不会被访问到,对于最终使用者而言,方便不方便阅读便无关紧要。考虑下载速度的因素,上述句子改成下列形式更有意义:

    <img src="/0/a.gif">

    然而手工的文件和目录的修改工作量太大了,我们可以借助一些内容管理系统来完成相关的工作,比如将内容重命名成简短格式等。前面提到的w3compiler就有自动复制并且检查相互依赖关系的功能。如果使用得当,这个技巧会给引用这些文件的(X)HTML文件减肥不少,并且也让那些剽窃(X)HTML的人重新使用这些文件设置了重重障碍。

    17.使用URL rewriter来缩短所有的网页URL

    注意在刚才提到的技巧中并不建议对网页的文件名(例如 products.html)进行重命名。那样的话,则下面的标示:

    <a href="products.html">Products</a>

    就会变成

    <a href="p.html">Products</a>

    这背后的主要原因是读者会看到一个这样的URL: http://www.sitename.com/p.html相比起http://www.sitename.com/products.html来,后者比前者要来的更有意义、更好用的多。

    不过,在不牺牲网页URL原义的前提下,假如我们结合更名技巧和修改服务器配置的话,我们还是有可能从缩短文件名中得到收获。譬如,在源代码中把products.htmlp.htmll替换掉,之后再设立一个URL复写(rewrite)规则,由服务器端的一个类似复写模块的过滤器比如 来使用这个规则,从而再把这个URL扩展成一个较为用户友好的值。注意这个窍门,如果这个复写规则只执行‘外部’(external)重定向的话,新的URL仅仅会写在使用者浏览器的地址条处,因而会强迫浏览器重新请求该页。在此种情况下,文件本身没有被重命名,仅仅是在源代码中URL里使用了重命名的简短的文件名。

    由于这个技巧依赖于URL的复写,并且缺少对服务器端工具(如复写模块)的广泛接触渠道和理解,即使是象w3compiler之类的高级工具在目前也不推崇使用这个技巧。然而, 考虑到像Yahoo!这样的大型网站通过积极使用该技巧得到了显著的获益,这个技巧是不能够被忽视的,毕竟它给目录及文件名称都是非常具描述性的站点提供了明显的减肥(X)HTML文件的效果。

    18.除去或缩短文件扩展名

    想想看,其实有些情况下文件的扩展名并没有多大用处,比如.gif, .jpg, .js等。浏览器不会依赖这些扩展名来显示页面,而是在处理时使用MIME类的头信息(header)。了解了这一点,我们就可以把:

    <img src="images/SubHeaderAbout.gif">

    简化为:

    <img src="images/SubHeaderAbout">

    或是结合文件名目录名重命名,我们可以得到:

    <img src="/0/sA">.

    您可别乍一看这个结果就吓跑了, .sA.gif仍然是.sA.gif文件,只不过网页的访问者不知道罢了。

    不过,为了使用这个相对高级的技巧,您还需要对服务器来做一下修改。主要要做的工作是启用一个叫做“内容协商”(content negotiation)的东西。它可能是服务器自带的,也可能需要一个扩展(比如象Apache的mod_negotation 模块或者IIS里Port80的PageXchanger )来支持。这样做会有一个负面的影响,它可能会造成服务器性能的一点损失。然而,内容协商的功能所带来的好处远大于所付出的。干净利落的URL可让您的网站即安全又轻便,甚至还使得自适应的内容传递变成可能:根据访问者浏览器的功能和系统的设置来向他传输不同类型的图片或语言!更多的说明请参看同作者所著的 Towards Next Generation URLs 一文。

    注意:少了扩展名的URL不会降低您网站在搜索引擎上的排名。Port80软件和其他知名网站(如W3C网站)都使用此技术而没有负面效果。

    19. 重构<scrīpt><style> 调用方式来优化请求次数

    我们常常在一个HTML文件头中看到这样标记代码:

    <scrīpt src="/scrīpts/rollovers.js"></scrīpt>
    <scrīpt src="/scrīpts/validation.js"></scrīpt>
    <scrīpt src="/scrīpts/tracking.js"></scrīpt>


    大多数情况下,上述代码应该被简化成:

    <scrīpt src="/0/g.js"></scrīpt>

    其中g.js包含了所有供全局使用的函数。虽然把脚本文件分成三份对于维护来说是有道理的,但对于代码的传输则没有意义。单个的脚本下载要比三个分离的请求高效的多,并且这也同时简化了markup代码的长度。有趣的是,这个方法模仿了传统编程语言编译器的连接概念

    20.考虑代码级的cache能力

    提高网站性能中最重要的方法之一是提高缓冲能力(cacheability)。网页开发者对使用<meta> 标签来设置缓冲控制都很熟悉,可是撇开meta对代理的缓冲毫无用处不说,缓冲能力的真正价值是其对相关对象(比如图片或脚本)方面的应用。为了提高缓冲能力,您要考虑根据改变频率对相关对象进行分段,把更适合缓冲处理的东西放在某个目录中(比如:/cache或者/images/cache。一旦您按照这个方法来组织您的网站,添加缓冲控制规则就很容易了,这样你的网站就会向经常来的访问者“跳”出来。

    现在,您已经了解了20条有用的优化技巧来使您的网站变得更快。从单条来看它们可能没有很大的作用。可是把它们合起来使用的话,网站的传输能力便会有明显的提高。在下一篇文章中,我们将重点放在缓冲处理上。我们会解释缓冲如何经常会被错误使用,以及如何通过一些小小的改动来取得性能的显著提高。
Open Toolbar