与测试有缘

发布新日志

  • Part 4 前述

    2009-03-05 20:57:23


    开发生命周期包括了从需求到代码比较分明的几个阶段。而测试生命周期,顾名思义,是与开发生命周期并行的一个可持续的流程。德明的可持续性改进流程则是被质量循环,原理,以及统计学技术溶入到软件测试中。
     
    测试生命周期的心理学提倡测试由非开发组织来实施,这样做的动机是,假若已经有了清晰定义好的需求,那么由第三方去验证这些需求将会更加有效。
     
    测试计划,它是软件测试的圣典,描述了测试目标,范围,策略方法,及其它详细信息。(现在到处都可以找到)指导如何写一份好测试计划的指引。
     
    在每一个阶段的生命周期都有两种最主要的质量保证验证方法,技术评审和软件测试。 技术评审是倾向于预防性的方法,它的作用是尽早的移除缺陷。软件测试则是验证实际的软件(是否符合需求)。
    本节的目的是:
    • 讨论测试生命周期是怎么样的一个并行活动。
    • 描述德明的流程改进是如何应用的
    • 讨论开发与测试生命周期的心理学
    • 讨论一个好测试的组成部分
    • 列出并描述技术评审与测试是怎么样的验证技巧

  • 软件测试与可持续性质量提高 第二部 生命周期测试评审 目录

    2009-03-03 23:36:55

    Special Notice: Copy rights belongs to original author, William E. Lewis.

    This Chinese translation can not be used in any commercial purposes without permission.

    注:原书版权归William E. Lewis所有,未经许可不可将译文用于任何商业用途。

     

    翻译不按原书顺序,挑着翻译。

    第二部 生命周期测试评审

    4.概述
    瀑布式开发方法
    分段式可持续改进方法
    测试生命周期的心理特点
    作为一个持续改进流程的软件测试
    测试圣典:软件测试计划
    写测试计划的主要步骤 :
        1.定义测试目标
        2.规划测试方法
        3.定义测试环境
        4.规划测试规范
        5.安排测试进度
        6.评审和批准测试计划
    测试计划的组成部分
    作为一个持续改进流程的技术评审
    技术评审的动机
    评审种类
    结构化走读
    正规检查
    参与角色
    有效评审的步骤: 
        1.评审流程的计划
        2.安排好评审时间
        3.规划好评审日程
        4.写个评审报告

    5.需求阶段的验证
        技术评审来测试需求
        正规检查和走读
        查验清单
        方法论的清单
        需求跟踪矩阵
        构建系统/接收的测试计划
    6.逻辑设计阶段的验证
        数据模型,流程模型,及他们的关系
        用技术评审来测试逻辑设计
        重定义系统/接收的测试计划
    7.结构设计阶段的验证
        用技术评审来测试结构设计
        集成测试的方法论
            第一步:识别单元的接口
            第二步:使接口更完整
            第三步:创造集成测试条件
            第四步:评估集成测试条件的完成性
    8.程序单元设计阶段的验证
        用技术评审来测试程序单元设计
        顺序
        选择
        重复
        创建单元测试用例
    9.代码阶段的验证
        用技术评审来测试代码
        执行测试计划
        单元测试
        集成测试
        系统测试
        接收测试
        缺陷记录
  • 打算翻译一下software testing and continuous quality improvement

    2009-03-03 23:28:38

    完成时间:不定

    有空就翻

    注:原书版权归原作者所有,译文可转载,但禁止商用。

  • [转贴]35岁之前成功的12条黄金法则

    2008-07-19 21:29:56

    第一章:一个目标

    一艘没有航行目标的船,任何方向的风都是逆风
    1、你为什么是穷人,第一点就是你没有立下成为富人的目标
    2、你的人生核心目标是什么?
    杰出人士与平庸之辈的根本差别并不是天赋、机遇,而在于有无目标。
    3、起跑领先一步,人生领先一大步:成功从选定目标开始
    4、贾金斯式的人永远不会成功
    为什么大多数人没有成功?真正能完成自己计划的人只有5%,大多数人不是将自己的目标舍弃,就是沦为缺乏行动的空想
    5、 如果你想在35岁以前成功,你一定在25至30岁之间确立好你的人生目标
    6、 每日、每月、每年都要问自己:我是否达到了自己定下的目标

    第二章:两个成功基点

    站好位置,调正心态,努力冲刺,35岁以前成功

    (一)人生定位
    1、 人怕入错行:你的核心竞争力是什么?
    2、 成功者找方法,失败者找借口
    3、 从三百六十行中选择你的最爱 , 人人都可以创业,但却不是人人都能创业成功
    4、 寻找自己的黄金宝地

    (二)永恒的真理:心态决定命运,35岁以前的心态决定你一生的命运
    1、 不满现状的人才能成为富翁
    2、 敢于梦想,勇于梦想,这个世界永远属于追梦的人
    3、 35岁以前不要怕,35岁以后不要悔
    4、 出身贫民,并非一辈子是贫民,只要你永远保持那颗进取的心。中国成功人士大多来自小地方
    5、 做一个积极的思维者
    6、 不要败给悲观的自己 ,有的人比你富有一千倍,他们也会比你聪明一千倍么?不会,他们只是年轻时心气比你高一千倍。
    人生的好多次失败,最后并不是败给别人,而是败给了悲观的自己。
    7、 成功者不过是爬起来比倒下去多一次
    8、 宁可去碰壁,也不要在家里面壁 ,克服你的失败、消极的心态
    (1) 找个地方喝点酒
    (2) 找个迪厅跳跳舞
    (3) 找帮朋友侃侃山
    (4) 积极行动起来

    第三章:三大技巧

    1、管理时间:你的时间在哪里,你的成就就在哪里。把一小时看成60分钟的人,比看作一小时的人多60倍
    2、你不理财,财不理你
    3、自我管理,游刃有余
    (1) 创业不怕本小,脑子一定要好
    (2) 可以开家特色店
    (3) 做别人不愿做的生意


    第四章:四项安身立命的理念

    35岁以前一定要形成个人风格
    1、做人优于做事 ,做事失败可以重来,做人失败却不能重来
    (1) 做人要讲义气
    (2) 永不气馁
    2、豁达的男人有财运,豁达的女人有帮夫运 , 35岁以前搞定婚姻生活
    3、忠诚的原则:35岁以前你还没有建立起忠诚美誉,这一缺点将要困扰你的一生
    4、把小事做细,但不要耍小聪明 ,中国人想做大事的人太多,而愿把小事做完美的人太少


    第五章:五分运气

    比尔·盖茨说:人生是不公平的,习惯去接受它吧
    1、人生的确有很多运气的成人:谋事在人,成事在天:中国的古训说明各占一半
    2、机会时常意外地降临,但属于那些不应决不放弃的人
    3、抓住人生的每一次机会 ,机会就像一只小鸟,如果你不抓住,它就会飞得无影无踪
    4、 者早一步,愚者晚一步

    第六章:六项要求

    1、智慧
    (1)别人可你以拿走你的一切,但拿不走你的智慧
    (2)巧妙运用自己的智慧
    (3)智者与愚者的区别
    2、勇气
    (1)勇气的力量有时会让你成为"超人"
    (2)敢于放弃,敢于"舍得"
    3、培养自己的"领导才能、领袖气质"
    (1) 激情感染别人
    (2) "三o七法则"实现领袖气质
    (3) 拍板决断能力
    (4) 人格魅力
    4、创造性:不要做循规蹈矩的人 ,25-35岁是人生最有创造性的阶段,很多成功人士也都产生在这一阶段
    5、明智
    (1) 知道自己的长处、短处,定向聚焦
    (2) 尽量在自己的熟悉的领域努力
    6、持之以恒的行动力:在你选定行业坚持十年,你一定会成为大赢家


    第七章:七分学习

    1、知识改变命运
    2、35岁以前学会你行业中必要的一切知识
    a) 每天淘汰你自己
    b) 在商言商
    3、太相信的书人,只能成为打工仔
    4、思考、实践、再思考、再实践


    第八章:八分交际

    朋友多了路好走
    1、智商很重要,情商更重要:35岁以前建立起人际关系网
    2、人脉即财脉:如何搞好人际关系
    3、交友有原则
    4、善于沟通:35岁以前要锻炼出自己的演讲才能


    第九章:九分习惯

    习惯的力量是惊人的,35岁以前养成的习惯决定着你的成功的大小
    1、积极思维的好习惯
    2、养成高效工作的好习惯
    (1) 办公室
    (2) 生活可以不拘小节,但要把工作做细
    (3) 学习聆听,不打断别人说话
    3、养成锻炼身体的好习惯
    4、广泛爱好的好习惯
    5、快速行动的好习惯

    第十章:十分自信

    1、自信是成功的精神支柱
    2、自信方能赢得别人的信任
    3、把自信建立在创造价值的基础上
    4、如何建立自信
    (1) 为自己确立目标
    (2) 发挥自己的长处
    (3) 做事要有计划
    (4) 做事不拖拉
    (5) 轻易不要放弃
    (6) 学会自我激励
    (7) 不要让自己成为别人


    第十一章 11个需要避开的成功陷阱

    1、只有功劳,没有苦劳
    2、不要"怀才不遇",而要寻找机遇
    3、不要想发横财
    4、不要为钱而工作,而让钱为你工作
    5、 盲目跟风,人云亦云,人做我也做
    6、 小富即安,不思进取,知足常乐
    7、 承认错误而非掩饰错误
    8、 脚踏实地而非想入非非
    9、 野心太大而不是信心十足
    10、反复跳槽不可取
    11、眼高手低
    12、不择手段


    第十二章 十二分努力

    没有人能随随便便成功
    1、小不是成功,大不是成功,由小变大才是成功
    2、中国社会进入微利时代:巧干+敢干+实干=成功
    3、努力尝试就有成功的可能
    4、做任何事情,尽最大努力
    5、把事情当成事业来做
    6、我看打工者
    7、祝你早日掘到第一桶金
  • [论坛] 代碼覆蓋率分析 [中文翻译0.1版]

    2008-05-06 00:47:15

    譯者按:
    在文中被標識了[***]為譯文不確定之處。
    若有指正之處,請發郵件到cnalexanderiii_gmail_com請把”_”換成郵箱的特殊符號。

    原文地址:
    http://www.bullseye.com/coverage.html
    作者:Steve Cornett
    譯者:AlexanderIII
    聯繫方式: http://www.51testing.com/?61747
                         cnalexanderiii_gmail_com





    代碼覆蓋率分析 [中文翻译0.1版]

    介绍

    代码覆盖率分析是
    在程序中寻找没有被用例测过的地方的流程;
    创建新的测试用例来增加覆盖率的流程;
    决定代码覆盖定量的量度方法,同时也是一种间接度量质量的方法的过程。

    它的另外一种使用方式是识别不会增加覆盖率的冗余用例,可由覆盖分析器来完成此过程。

    使用覆盖率分析,实际上是确保你的测试的质量,而不是確保实际产品的质量。一般情況下你也不會在對你發佈產品上運行測試的時候使用覆蓋分析器。覆蓋分析通常需要訪問到測試程序源代碼,以及會經常需要用特殊的命令來重編譯。

    本篇文章討論了向測試計劃增加覆蓋分析時所需要考慮的詳細內容。覆蓋率分析有著它的優點和缺點。你需要選擇採用哪些度量的方法。你要設定一個最低的覆蓋率來決定什麼時候停止分析覆蓋。覆蓋分析是一種測試的技術,但你不應該依賴於它的單獨使用。

    覆蓋分析有時候也叫“測試覆蓋分析”, 這兩種術語是同義的。在學術界裏,術語“測試覆蓋”使用得比較多,在測試業界裏的話,使用得多的就是術語“代碼覆蓋”。同樣的,覆蓋分析器有時候也被叫做“覆蓋監控器”。比較喜歡測試業界術語。

    結構測試與功能測試

    代碼覆蓋分析是一種結構測試技術(AKA玻璃盒测试和白盒测试)。结构化测试是以源代码的意图表现为依据来比较被测程序行为的。这就与以需求规格为依据去比较被测程序行为的功能测试(AKA 黑盒测试)形成对比。结构化测试检查程序是如何工作的,以及代码结构和逻辑方面的潜在缺陷。功能测试是不管程序内部如何运作的,它只检查及关心程序实现了什么。

    結構化測試通常也叫做路徑測試,那是因為你所創建的測試用例所經過的,就是程序路徑的結構。要注意的是,千萬不要把路徑測試和路徑覆蓋度量搞混了,下面章節會解釋。

    粗略的看上去,結構化測試似乎是不太穩妥的,它不能夠找到被遺漏的錯誤。可是(從功能測試方面來說),需求規格不存在,甚至很少是完整的這種事是真實的,尤其會發生在產品開發快結束的時,由於需求規格更新得慢,產品它自己會取代需求規格的作用了。在越接近發佈的時間,功能測試和結構化測試的區別就越模糊。

    前提

    在覆蓋分析的背後的一些最基本的假設,可以讓我們知道這種測試技術的長處和短處。下面列出了幾點最最基本的假設。


    • Bugs是和控制流相關的,你可以通過變換控制流的方法來找到Bugs[Beizer1990 p.60].比如說,一個程序員寫了"if (c)" 而不是 "if (!c)"
    • 你可以在不知道有什麼故障將會發生的情況下去找故障, 以及相信所有測試都是可信的,如果成功執行完這些測試,(沒有發現錯誤)就代表了程序的正確性[Morell1990]。測試人員明白一個正確程序會做些什麼,以及能夠識別與這些正確行為的差異。
    • 其它的假設包括了,可完成的規格,沒有遺漏的錯誤,和沒有運行不到的代碼。

      顯然,這些假設並不是一直都有效的。覆蓋分析可以找到一些疑似的bugs,但並不能夠找出所有的bugs. 覆蓋分析應用在要做許多判斷的應用程序上所得到的好處要比它應用在以數據為中心的程序(比如說數據庫應用)要多。

      基本的度量方法

      現在有很多的覆蓋度量方法,這裏所描述的只是一些基本的度量方法以及他們的優缺點。

      語句覆蓋

      這種度量報告是否每一條可執行語句都被測過了。它也同時可以被叫為,行覆蓋,段覆蓋[Ntafos1988]C1[Beizer1990 p.75],以及基本的塊覆蓋。基本塊覆蓋是和語句覆蓋是一樣的,除了它們測量的最基本代碼單位有所不同。基本塊覆蓋的基本單位是每一個非分支語句的序列。

      我不是太鼓勵去使用描述得不太準確的名字 C1。人們有時會使用C1去標識判定覆蓋。因此這個術語就存在了二義性了。

      這種度量的最主要好處就是直接應用到被測對象代碼裏,不需要再處理代碼。性能監視器[***]通常會使用這種度量。它的主要壞處就是它對一些控制結構不敏感。舉個下面的C/C++的代碼片段例子來說:

      int* p = NULL;
      if (condition)
      p = &variable;
      *p = 123;

      在沒有一個測試用例能夠走假分支的情況下,語句覆蓋仍然會認為這段代碼被完全覆蓋了。但事實上,只要if 條件能夠走到假分支的話,這段代碼就會失敗。這就是語句覆蓋的最大的缺點。If語句是非常普遍的。

      語句覆蓋並不報告循環是否達到了他們的停止條件情況,它只報告這個循環體是否被執行過。但在C,C++,和JAVA裡,這種限制會影響到包含了BREAK語句的循環。


      由於DO-WHILE循環不管怎麼樣都會執行至少一次,語句覆蓋會把它看作與非分支語句同類。語句覆蓋對邏輯操作符完全無視,它還不能夠區別連續的SWITCH標籤。

      和非判斷語句相比,測試用例一般情況下和判斷語句更加相關。你應該不會為了連續10句非分支語句寫10個單獨的測試用例吧?通常情況下,我們都只會用一個測試用例。舉個例子來講,有一個IF-ELSE語句,在THEN子句裡包含了一條語句,在ELSE子句裡包含了99條語句。當在走過了這兩個可能的路徑其中任何一條,語句覆蓋會給出相差很大的結果,要不是1%,要不就是99%。基本塊覆蓋就可以解決這個問題。

      在支持語句覆蓋比其它度量要好的一個論點就是bugs是均勻的頒在代碼中的,因此可執行語句被覆蓋的百分比,就可以反應到故障能夠找到的百分經。然而,我們最基本的四種假設其中之一說的就是,故障是和控制流相關的,並不是和計算相關。而且,我們可以合理的預期到程序員將會把分支數和語句數保持在一定的比例上。

      總之,計算性的語句影響這種度量的程度要比判定影響的程度要大。

      判定覆蓋

      這種度量報告的是在控制結構裏(例如IF語句和WHILE語句)的布爾表達式的真假值都被測過了。整個的布爾表達式被看成了一個單獨的真假判定,不管它裏面有沒有邏輯與或者邏輯非操作符。這種覆蓋還包括了SWITCH語句裏的CASE執行語句,EXCEPTION處理,以及中斷處理的覆蓋。

      它也被叫做分支覆蓋,all-edges(所有邊界?)覆蓋[Roper1994 p.58], 基本路徑覆蓋[Roper1994 p.48], C2 [Beizer1990 p.75], DDP覆蓋(判定路徑覆蓋)[Roper1994 p.39].“基本路徑”測試是選擇相應的路徑去滿足判定覆蓋。

      我不推薦使用C2這個描述不清楚的名字,它容易和術語C1搞混。


      這種覆蓋的優點就是簡單,以及沒有語句覆蓋的那些問題。缺點就是會由於布爾表達式裏面的short-circuit 操作符,而忽略掉一些分支。比如下面的C/C++/JAVA代碼段:

      if (condition1 && (condition2 || function1()))
          statement1;
      else
          statement2;

      在使用這種度量方法考慮覆蓋率分析的時候,可以完全不考慮調用function1()而達到完全覆蓋。當condition1和condition2都取真值的時候,整個表達式就真,當condition1為假的時候,整個表達式就為假。在這種情況下,short-circuit 操作符把調用function1排除在外。

      條件覆蓋

      條件覆蓋報告了每一個被邏輯非和邏輯與分開的布爾子表達式真假值的情況。條件覆蓋獨立的估量每個子表達式。
      這種度量與判定覆蓋相似,但對控制流的敏感性又比它強。但是,完全條件覆蓋並不能保證完全的判定覆蓋。比如下面的C++/JAVA代碼例子:

      bool f(bool e) { return false; }
      bool a[2] = { false, false };
      if (f(a && b)) ...
      if (a[int(a && b)]) ...
      if ((a && b) ? false : false) ...

      在上面的例子中,不管a和b的值取什麼,所有的IF語句都會走假分支。但是,如果你使用了所有的a和b值的組合去測試代碼,條件覆蓋會報告完全覆蓋的結果。

      多條件覆蓋

      多條件覆蓋是報告是否所有布爾子表達式的組合都出現了。在前面介紹條件覆蓋的時候,子表達式都是被邏輯與邏輯非分開的。
      如果想要達到對一個條件的多條件完全覆蓋的話,可以由這個條件的邏輯操作符真值表來獲得。

      對於有short-circuit操作符的語言來說,像C,C++,和JAVA,多條件覆蓋有一個優點就是它需要非常徹底的測試。對於這些語言來講,多條件覆蓋和條件覆蓋非常相像。

      這種度量的缺點就是決定所需最小測試用例集的過程是非常冗長的,尤其對於非常複雜的布爾表達式來說,更乏味。

      它的另一種缺點就是對於相似複雜度的條件,它們所需要的測試用例數相差可以相當的大。比如下面的兩個C/C++/JAVA條件的例子:

      1st  a && b && (c || (d && e))
      2nd  ((a || b) && (c || d)) && e

      為了得到完全的多條件覆蓋,第一個例子裏的條件需要6個測試用例,第二個需要11個。這兩個例子具有相同數量的操作數和操作符。
      下面是測試用例的列表。

        a && b && (c || (d && e))
      1. F    -     -     -    -
      2. T    F     -     -    -
      3. T    T     F     F    -
      4. T    T     F     T    F
      5. T    T     F     T    T
      6. T    T     T     -    -


          ((a || b) && (c || d)) && e
      1.   F    F      -    -      -
      2.   F    T      F    F      -  
      3.   F    T      F    T      F
      4.   F    T      F    T      T
      5.   F    T      T    -      F
      6.   F    T      T    -      T
      7.   T    -      F    F      -
      8.   T    -      F    T      F
      9.   T    -      F    T      T
      10.   T    -      T    -      F
      11.   T    -      T    -      T

      多條件覆蓋和條件覆蓋一樣不包括判定覆蓋。對於沒有short-circuit操作符的語言,比如VB和PASCAL,多條件覆蓋是一種有效的邏輯表達試的路徑覆蓋,它有一樣的優缺點。下面是VB的代碼例子。

      If a And b Then
      ...

      多條件覆蓋需要4個測試用例來覆蓋每一種A和B的組合真和假值。與路徑覆蓋一樣(?),它每增加一個邏輯操作符,測試用例所需要的數量就要增加一倍。

      條件/判定覆蓋

      條件/判定覆蓋是一種由條件覆蓋和判定覆蓋混在一起度量的方法。它簡單,沒有組成它的兩種度量的缺點。BullseyeCoverage量度的就是條件/判定覆蓋。

      改進型條件/判定覆蓋

      這種覆蓋也被叫為MC/DC和MCDC覆蓋。它需要足夠多的測試用例去驗證每個條件是可以影響到它所包括的判定結果。這種度量是由波音公司建立的,以及根據RCTA/DO-178B來開發航空軟件。

      對於C,C++,和JAVA來說,這種度量需要的測試用例與條件/判定覆蓋相同。改進型的條件/判定覆蓋是為了有邏輯操作符但不是short-circuit的語言而設計的。當在C,C++和JAVA中的short circuit 邏輯操作符的結果可以影響到它所包含的判定時,它們僅僅起評估條件的作用。

      在定義了這種度量的論文[Chilenski1994]中,章節"3.3 Extensions for short-circuit operators" 講了,"short-circuit操作符的使用,使得所有固定條件的需求與對不同條件影響的關係更加和諧"[***] 這篇論文裏使用的編程語言是ADA,它有非short circuit的邏輯操作符,也有shortcircuit的操作符。[***]

      路徑覆蓋

      這種度量報告的是每個FUNCTION裏面的每一個可能的路徑是否已經被走過了。路徑指的是從FUNCTION入口到出口的分支序列。
      它的另外一種叫法是斷言覆蓋。斷言覆蓋是把路徑看做邏輯條件的可能組合[Beizer1990 p.98]

      由於循環覆蓋介紹了無限制路徑數目的方法,所以這種度量只考慮有限次數循環的可能性。這種度量有很多種變化來應對多種循環。內部邊界值路徑測試考慮了循環的兩種可能性:0次重複,以及多於0次的重複[Ntafos1988]。對於DO-WHILE循環,就是一次循環與多於一次循環。

      路徑覆蓋的優點是需要非常彻底的測試。但它具有兩個非常嚴重的缺點。第一個,路徑的個數為分支數目的指數倍。比如,如果一個有10個IF語句的函數,它就有1024條路徑去測試。

      當加了一條IF語句時,它的路徑數就翻倍到了2048。第二個缺點就是,由於數據間的關係,它有很多的路徑是不可能被測試的。比如下面的C/C++代碼例子:


      if (success)
      statement1;
      statement2;
      if (success)
      statement3;

      從路徑測試的角度來看這段代碼,它就有四條路徑。但事實上,它只有兩個是可行的:SUCCESS等於假和SUCCESS等於真。

      研究學者已經研究出多種路徑覆蓋來對付數目具大的路徑。比如說,N長度子路徑覆蓋報告了你是否測試過了長度為N分支的每一個路徑。其它的衍变各類包括了線性代碼序列及跳轉[***]LCSAJ覆蓋, 數據流覆蓋。

      其它度量

      下面描述的是一些基本度量的變種和一些用得比較少的度量。

      功能覆蓋

      這個度量報告了你是否調用了每一個函數或者過程。它在初步測試中可以至少保證軟件的所有功能都得到一些覆蓋。主要簡單的測試可以快速的找出一些不足之處。BullseyeCoverage量度的是功能覆蓋。

      調用覆蓋

      這種度量報告的是你是否執行了每個函數的調用。這裏的假設是Bugs通常發生在模塊之間的接口處,它又叫做調用對覆蓋[***]。

      LCSAJ覆蓋

      這種是路徑覆蓋的一種變種,它考慮的是那些容易在程序代碼裏表現出來及不需要流圖的子路徑[Woodward1980]。一個LCSAJ是指一序列的源代碼按順序執行。
      這裏說的“linear”序列可以包含判定,只要在運行時控制流真的是從這一條語句到那一條語句斷續執行。子路徑是由這些連接著的LCSAJ們所構建的。研究學者
      通常把這種長度N的LCSAJ的路徑覆蓋比率叫做測試效力比率(TER)N+2。

      這種度量的好處就是它比判定覆蓋更加彻底,但避免了路徑覆蓋的測試用例的指數級數量問題。不好的方面就是它也不能夠避免那些不可行的路徑。




      數據流覆蓋

      這種路徑覆蓋的變種只考慮從分配的變量到後續參考的變量之間的子路徑的情況。它的優點就是它所考慮到的路徑都是和程序處理數據的方法直接相關。它第一個缺點是
      它並不包含判定覆蓋。另外一個缺點就是複雜。研究學者提出了幾種變種,但這幾種都是增加了它的複雜度的。比如說,這些改進了的度量方法因為計算語句中的變量的使用方法與在判定語句中的變量使用方法不同而不同,
      本地與全局變量的使用不同而不同。通過對代碼優化進行數據流分析,指針也會造成問題的產生。

      目標碼分支覆蓋

      這種度量報告了每個機器語言條件轉移命令是成功的轉移到分支了還是失敗了。這種度量給出的結果與編譯器更加相關而不是程序結構。造成這種情況的原因是編譯器的代碼生成和優化技術, 能夠生成可以承受相似的源代碼結構[***]。

      因為分支會被指令管道所中斷,所以有時候編譯器需要避免生成分支,而且要生成替代此分支的非分支指令序列。編譯器經常由於要讓函數少調用一些其它函數而要向函數裏內嵌一些代碼。如果此類函數包含了分支,那麼與源代碼比起來,它相應的機器碼就會非常明顯的增加了不少。

      你最好是針對原始的源代碼來進行充足的測試,因為它比目標碼更加與程序的需求相關。

      循環覆蓋

      這種度量報告了每個循環是否被執行了0次,1次,以及多於1次。對於DO-WHILE循環,循環覆蓋報告的是你是否執行了1次和超過1次。這種度量最有價值的地方就是它可以決定WHILE循環和FOR循環執行超過一次,這樣的信息其它度量是不能提供的。具我所知,只有GCT實現了這種度量。

      RACE覆蓋

      這種度量報告了是否多線程在同一時間執行了同樣的代碼。它可以幫助查到同時對資源存取這樣的問題。它對於多線程程序的測試是非常有用的,比如說在一個操作系統裏使用。 據我所知,只有GCT實現了這種度量。

      關係操作符覆蓋

      這種度量報告的是具有關係操作符(<,<=,>,>=)的時候,邊界值的情況。 它假想的是這些邊界測試用例查到一些差一(OFF-BY-ONE)錯誤,以及用了錯誤的關係操作符(比如,用<代替了正確的<=)

      下面舉個C/C++的例子來講:

      if (a < b)
      statement;

      關係操作符覆蓋報告是否有A==B的這種情況發生。如果A==B發生了,若程序也給出正確的反應,那你就可以知道此關係操作符是<=是錯的。到目前為止,我就只知道GCT是有實現這個度量的。

      弱轉換覆蓋[***](Weak Mutation Coverage)

      這種度量與關係操作符覆蓋相似,但它更具有概括性[Howden1982]。它所報告的是測試用例是否顯露了錯誤的操作符操作數的使用問題。首先,它會將程序表達式裏原有的操作符與變量用替身操作符與替身變量取代,比如說使用"-"號替代掉"+"號,然後它再報告這個被轉換掉的條件的覆蓋率。

      這種度量目前暫時還主要處於學術界中[譯者:此篇源文與譯文的年數相差較大,可能不太準確],它有多種不同的解釋[***]。而且在它可以具體應用之前,被測程序需要達到不少的特殊要求才行。同樣的,具我所知,它目前只在GCT中得到實現。

      表覆蓋

      這種度量講的是在某一數組中的每一個元素是否被引用了。這種方法對於被有限狀態機控制的程序非常有用。

      度量方法的比較

      當一個強的度量方法包含了另一個比較弱的度量方法時,你只能比較他們之間的相對的強處。

      • 判定覆蓋包括了語句覆蓋,原因是當執行過每一條分支的時候,肯定會導致每一條語句都被執行了。
      • 條件/判定覆蓋包括了判定覆蓋與條件覆蓋(這是由它們的定義得出來的)
      • 路徑覆蓋包括了判定覆蓋
      • 斷言覆蓋包括了路徑覆蓋和多條件覆蓋,以及其它大多數度量方法。

        學術界也認為強的度量方法包含了弱的度量方法。覆蓋度量方法是不能從數量上進行比較。

        發佈標準中的覆蓋率目標

        每一個項目都必須要根據可用的測試資源以及防止推遲發佈的重要性,來選擇一個可以作為發佈標準的覆蓋率最小值。
        很明顯的,和安全相關的軟件,它的覆蓋率就要有一個高一些的值。還有,你也可以把單元測試的覆蓋率最小通過值設置得比系統測試的要高。它這樣做的原因是低層次的代碼錯誤可以影響到很多高層的調用代碼。

        當你使用語句覆蓋,判定覆蓋,或者條件/判定覆蓋時,覆蓋率的最小通過值就可以設為80%~90%,甚至更高。也有另外的一些人覺得如果把它設置為低於100%的話,是不能夠保證質量的。但問題是,如果你真的設置了100%的目標,那麼你將會花費巨多的精力去獲取這個100%。

        假若我們可以把這同樣的精力放到另外的測試活動中,比如說正式的技術評審,它也許可以找到更多的Bugs。另一個要注意的是,不要把目標設為低於80%。

        中間的覆蓋率目標

        選擇一個中間的覆蓋率目標可以很有效的提高測試生產率。你最高的測試生產率發生在當你使用了最少精力找到了最多錯誤的時候。
        精力是由時間評估的,這時間包括了創建測試用例,把它們加到你的測試套件裏,以及運行它們的時間。你應該使用覆蓋率分析策略來儘快增加覆蓋率。
        這可以讓你更早的獲得找到失敗的最大概率。Figure 1闡明了高低測試生產率與相應覆蓋率。Figure 2闡明了相應的失敗發現比率。




        有一種可以較快增加覆蓋率的策略,它就是在追求更高的覆蓋率之前,先通過對整個測試程序進行一些簡單的覆蓋。你可以通過在早期的瀏覽被測程序的各個功能,來找到明顯的早期錯誤。比如,假設你的應用程序需要打印幾種類型的文檔,有一個bug使得程序的打印功能完全失效。如果一開始就每種類型的文檔都試著打印一份,你也許就可以很快的找到這個bug了。這樣就比通過針對一種類型的文檔而打印出很多同種類型的文檔進行彻底的測試要快得多。它的目的就是通過最少的測試,
        比較容易的找到早期程序的錯誤。

        下麵列出的覆蓋率目標順序就是這種策略的一種可行方案。
          
        1. 源代碼或者類的90%都可以調用至少一個函數[***]
        2. 調用至少90%的函數
        3. 每個函數至少獲得90%的條件/判定覆蓋率
        4. 獲得100%的條件/判定覆蓋率

          需要注意的是,我們並不需要在初始的目標中就要達到100%覆蓋。這樣就可以把最難的地方放在後面測試。這樣做是對維持高測試生產率,以及用最少精力獲得最多結果是很重要的。
          再者,還要注意要避免在定中間覆蓋率目標時使用弱度量方法,在定最終的發佈目標時使用強度量方法。如果這樣做的話,就會由弱度量方法的短處來決定推遲哪些測試用例。實際上應該把強度量方法應用在所有的目標上,以及可以根據每個測試用例的難度來決定哪些會被推遲。

          結束語

          覆蓋率分析是一種幫助把測試套件中的缝隙消除掉的結構化測試技術。當在沒有詳盡的需求規格的時候,它更能起到重要作用。對於C,C++,和JAVA來說,條件/判定覆蓋是最好的一種通用度量方法。如果把中間的覆蓋率目標(不管哪種類型)設置為100%,那麼它都將會降低測試的生產率。在發佈前,努力爭取達到語句,分支,或者條件覆蓋方法的80%~90%覆蓋吧!

          References

          Beizer1990 Beizer, Boris, "Software Testing Techniques", 2nd edition, New York: Van Nostrand Reinhold, 1990
          Chilenski1994 John Joseph Chilenski and Steven P. Miller, "Applicability of Modified Condition/Decision Coverage to Software Testing", Software Engineering Journal, September 1994, Vol. 9, No. 5, pp.193-200.
          RTCA/DO-178B, "Software Considerations in Airborne Systems and Equipment Certification", RCTA, December 1992, pp.31, 74.
          Howden1982 "Weak Mutation Testing and Completeness of Test Sets", IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379.
          McCabe1976 McCabe, Tom, "A Software Complexity Measure", IEEE Trans. Software Eng., Vol.2, No.6, December 1976, pp.308-320.
          Morell1990 Morell, Larry, "A Theory of Fault-Based Testing", IEEE Trans. Software Eng., Vol.16, No.8, August 1990, pp.844-857.
          Ntafos1988 Ntafos, Simeon,"A Comparison of Some Structural Testing Strategies", IEEE Trans. Software Eng., Vol.14, No.6, June 1988, pp.868-874.
          Roper1994 Roper, Marc, "Software Testing", London, McGraw-Hill Book Company, 1994
          Woodward1980 Woodward, M.R., Hedley, D. and Hennell, M.A., "Experience with Path Analysis and Testing of Programs", IEEE Transactions on Software Engineering, Vol. SE-6, No. 3, pp. 278-286, May 1980.

          [ 本帖最后由 AlexanderIII 于 2008-5-6 00:46 编辑 ]
        5. I'm back.

          2008-03-10 00:13:13

          there will be some translated articles again.

        6. [论坛] 粗制烂造了一把:《九“英”真经》

          2007-08-24 18:08:47

          《九“英”真经》

           

          通篇核心:“练”字诀

           

          筑基篇:单词量,音标,发音,这三方面核心是单词量,其它两个次重要。至少单词量要达到大学四级英语水平。

           

          听篇:

           

          电视,收音机里的英语频道。如果没有,请自己在网上下载相关英语电视剧节目,比如friends, sex and city, prison break等,纯当下班后的娱乐好了。

           

          说篇:

           

          提高说的能力的方法有几种

          1, 对着镜子自己给自己说进行英语对话,自问自答;(请确定周围没有人,要不,会被人当神经病,小心小心,比较适合在家里练)

          2, 与朋友面对面的讲,不要觉得朋友是中国人,和他说英语会觉得别扭,说多了就无所谓了;

          3, 找老外讲,女生比较方便点,有先天优势,哈,但要注意不要被泡走了,要不然国人GG会很伤心的,呵呵; 经常参加老外的活动PARTY(前提条件,经济没啥问题,酒吧里一小瓶酒也要三四十块);

          4, 找找周围的外语角,MS很多地方都有,比如说公园呀什么的;

          5, 还要注意经常照着英语报纸来大声朗读出来

           

          读篇:

           

          此‘读’非朗读,而为阅读;

           

          提高阅读能力的途径,没啥,你天天抽空看看国外网站,或者订点英语报纸呗,还能咋样?花时间看去!推荐:China Daily,一块钱一份,ShangHai Daily, 2元一份,上海小报摊都有得卖,深圳的就只有Shenzhen Daily喽。怀念在上海拿份Shanghai Daily蹲臭气熏天厕所的时光,哈哈。

           

          写篇:

           

          多写吧,能有啥办法?

          途径:和老外写邮件,多交流一下,有些啥问题让他们给你指出来。

           

           

          注意:坚持是成功最大的保障,如果坚持一个月就可以有效果了。

           

          当然这只是我个人的经验,如果谁有更好的方法,可以交流一下。

        7. 抱歉,最近忙,答应的东西要晚点出来了

          2007-08-20 21:03:43

          不好意思,争取早点搞定。
        8. 预告一下,应天网要求,准备写个英语学习的贴子

          2007-08-03 10:54:25

          到时候写得不好,不要骂人。

           

        9. 时间管理三招[转贴]

          2007-07-18 17:05:34

          转者按:在网上看到这个文章,对我最近的时间管理问题有指引作用,特转载过来给大家看看。

          Link: http://blog.run2me.com/runliu/archive/2005/08/19/9671.aspx

          作者:刘润

          时间管理三招

          Posted on 2005-08-19 00:21 刘润 阅读(84143) 评论(132)  编辑 收藏

          这两天给中软资源的员工们作了一个关于时间管理的演讲,强调对时间的管理基本上不是6-sigma的范畴,因为时间管理重要的不是如何从17分钟里面省出17秒来,而是这17分钟值不值得做,以及如何用17分钟省出17个小时来。

          我提出了以年为单位的时间管理,以天为单位的时间管理和以小时为单位的时间管理三个层次。

          以年为单位的时间管理

          每年一月份,我都会制定新的一年的行动计划,以及审视去年的实施情况(参见:2002 - 2003 - 2004)。这个计划的逻辑是:1)职业/生活目标,2)我的强项/弱项,3)具体的支持活动。只有制定了一年的计划,我才知道有朋友叫我去唱歌的时候是不是该拒绝,我才知道晚上是不是放弃看《康熙来了》而研读逻辑,我才知道要定期在当当上买书、做卓越的终生VIP。以年为单位的“有目标的”时间管理,帮我省下来的是若干月的时间。

          以天为单位的时间管理

          上帝给了每个人公平的每天三个八小时。第一个八小时大家都在工作,第二个八小时大家都在睡觉。人与人的区别都是第三个八小时创造出来的。如果你每天花3个小时上下班,2个小时吃早中晚饭,1个小时看电视,那你自由支配的时间就只剩2个小时了。你可能会非常节省的用它来陪女朋友看电影,健身或者唱歌,打打游戏。但是如果你从交通、睡觉、吃饭里分别省出一些时间花在学习上,你的学习进步将是惊人的。如果你把这些时间花在拓展交际、锻炼身体、参加公益,你的人脉增长将是同样惊人的。

          以小时为单位的时间管理

          我们和CPU一样都是分时系统,只不过芯片每秒分成上亿份,人类一小时分成四、五份。每一个时刻我们只能做一件事情,如果被打断再转回来的时候会有一定的时间浪费在回忆刚刚在做什么、做到哪里。我们需要锻炼在不同事务之间迅速切换的本领,这样就会更加有效的利用每一个小时的时间,在每一个时间片里100%的专注。这要借助工具,所以我一直在非常大的依赖于微软的Outlook和我的智能手机来管理我的每一个小时。把事情分为“轻重缓急”,按照规律去顺序处理。

          如果你不能以年的方式来管理时间,那么这样白白浪费掉的时间让以小时为单位的时间管理显得毫无意义。如果不能在每一个小时上有所节省,那么每年的时间也无法真正管理。这三种层次是缺一不可的。

        10. [论坛] 昨天和小胖聚餐了

          2007-06-16 17:50:42

          不容易呀,工作快半年了才出来吃第一次饭
          聊了不少东西

          要是还有在深圳的学员,和我联系一下,下次一块出来吃饭,交流一下。

        11. 终于~~提前转正了

          2007-05-22 19:56:26

          还好没有等到半年才给我转,要不真的是郁闷死了。

          继续加油!好好干!

          oh yeah~~~

        12. Top10 list of adjectives to describe software engineers at Google

          2007-04-17 09:19:01

        13. Global - Google has engineering offices (and, of course, customers) all over the world. So not only do we have engineers from everywhere, every engineer gets the chance to make software that will be as great in Singapore as it is in Finland.
        14. Comfortable - Engineers need to be comfortable to be effective...and Google gives us the equipment to be comfortable. And if our muscles get tight from sitting, we can get an on-site professional massage.
        15. Flexible - Getting work done is more important than what time we work.
        16. Unhampered - We're a company designed by engineers for engineers, so functional merit tends to outweigh other considerations at decision-making time.
        17. Entertained - We have lots of fun activities. Every winter, there's a company-wide ski trip. Every summer, there's an all-engineer picnic on the Santa Cruz beach boardwalk. Google has bought out theaters for opening days of films like Star Wars and Lord of the Rings.
        18. Listened to - Google has a very open environment and truly values each employee's opinions. Every Friday, there's a company-wide meeting where Larry and Sergey (our founders) report on significant events and have an open-to-all Q&A session.
        19. Stuffed - In most offices, Google provides free gourmet-quality breakfast, lunch, and dinner. If you come in too late to get breakfast (or you get hungry between meals), you can always head to the nearby mini-kitchen and grab some fruit, cereal, and tea (or crisps, chocolate, and espresso for the less healthily inclined).
        20. Cutting-edge - We have the audacious goal of organizing the world's information -- and to meet it, we've built the largest distributed computer system in the world and written some of the world's most widely-used software.
        21. High-impact - People in every country and every language use our products.
        22. Dependable - We try to keep a high bar for hiring, so you can depend on the ability of your teammates to handle most any engineering problem
        23.  

      1. don't know why

        2007-04-09 13:51:00

        suddenly, the feeling of missing friends in Shanghai is getting stronger and stronger inside of my heart.

        How are you?My friends!

      2. MS很久没更新过了,写两句

        2007-03-30 11:00:22

        今天在当搬运工,搬实验室机器。

        累坏了

         

      3. [论坛] 测试无界限 | pradeep.srajan

        2007-03-01 08:49:48

        http://testertested.blogspot.com/2007/02/there-is-no-four-and-six-in-testing.html

        这篇文章的作者所表达的意思就是指测试人员做测试的时候不要被边界值方法的固定思路所影响,而是要在脑袋里有一个概念-“测试无界限”。

        在文章末尾还给了一个JAMES BACH和MIKE KELLY做的一个边界值的教学录像,我看了,不错,对扩展测试人员的思路有好处。

        推荐强度:+++++++++++++++++++++....

        -----------

        3月2号修改了一个字,把“测试无边界”改成“测试无界限”

        感觉 这样子更好

      4. Happy Chinese New Year!

        2007-02-26 09:15:07

        gong xi fa cai!

        li shi dou lai!

      5. Sorry for the delay of the 2nd translation

        2007-02-10 00:30:16

        plz send back your comments to me.

        thank you

        AlexanderIII

      6. [论坛] 再谈谈性能测试vs负载测试[中文翻译]

        2007-02-10 00:22:18

        源文来源:http://agiletesting.blogspot.com/2005/04/more-on-performance-vs-load-testing.html

        作者:Grig Gheorghiu
        作者联系方式:http://agiletesting.blogspot.com/


        译者:AlexanderIII


        译文联系方式:

        cnalexanderiii@gmail.com

        http://blog.51testing.com/?61747

        相关文章连接:

        性能测试VS负载测试VS压力测试[中文翻译]


        [译者注]欢迎转载! 转载请尊重一下作者及译者,请把作者,译者及联系方式也转上,谢谢!同时如果有建议或者认为有什么不妥之处,欢迎来信交流,大家一起提高测试水平。
        在一些翻得不太准确的地方,本人在都打上了*号,请注意!

        []中的内容为本人自己为了中文意思的流畅性自行加入的,若造成与原文作者的意思有出入的,还请海涵!

        *禁止将内容用于商业用途!请在得到允许之后再进行,谢谢合作.


        [源文&译文内容]

        Thursday, April 14, 2005

        More on performance vs. load testing

        再谈谈性能测试vs负载测试

         

        I recently got some comments/questions related to my previous blog entry on performance vs. load vs. stress testing. Many people are still confused as to exactly what the difference is between performance and load testing. I've been thinking more about it and I'd like to propose the following question as a litmus test to distinguish between these two types of testing: are you actively profiling your application code and/or monitoring the server(s) running your application? If the answer is yes, then you're engaged in performance testing. If the answer is no, then what you're doing is load testing.
        最近我得到了一些关于先前发表在博客上的贴子“performance vs. load vs. stress testing”的意见和疑问。我发现仍然还有很多人对于这两个概念有所混淆。近来,我又仔细想了一下它们的区别,然后得到了用以下这个“试金石”的区分方法:

        你是否积极*的去剖析应用程序的代码和(或者)运行着程序的服务器(群的状况)?如果答案是“YES”,那你就是在进行性能测试。假若答案是“NO”,那就可以说明你所做的就是负载测试了。


        Another way to look at it is to see whether you're doing more of a white-box type testing as opposed to black-box testing. In the white-box approach, testers, developers, system administrators and DBAs work together in order to instrument the application code and the database queries (via specialized profilers for example), and the hardware/operating system of the server(s) running the application and the database (via monitoring tools such as vmstat, iostat, top or Windows PerfMon). All these activities belong to performance testing.
        另外一种可以分辨的方法就是看测试人员做的是白盒测试多还是黑盒测试多。在走白盒的路子的时候,测试人员,开发人员,系统管理员和DBA都要通力合作才可以使用工具来解决问题*,比如说通过使用特定的探测器*来识别应用代码及数据库查询,通过vmstat,iostat,top或者Windows PerfMon工具来监测运行了应用程序和数据库的服务器上的硬件及操作系统(资源数据*),所有的这些都属于性能测试。


        The black box approach is to run client load tools against the application in order to measure its responsiveness. Such tools range from lightweight, command-line driven tools such as httperf, openload, siege, Apache Flood, to more heavy duty tools such as OpenSTA, The Grinder, JMeter. This type of testing doesn't look at the internal behavīor of the application, nor does it monitor the hardware/OS resources on the server(s) hosting the application. If this sounds like the type of testing you're doing, then I call it load testing.
        黑盒的路子就是在客户端运行负载工具来看应用程序的反应如何。这类型的工具范围从功能少的命令行运行的工具,httperf,openload,siege,Apache Flood,到功能比较强大的工具OpenSTA,The Grinder,JMeter. 这种类型的测试不看应用程序的内部的运作,也不监视运行着被测试程序的服务器硬件及操作系统的资源情况。假如你所做的看上去和这种情况相似的话,那么我觉得它就可定义为负载测试。


        In practice though the 2 terms are often used interchangeably, and I am as guilty as anyone else of doing this, since I called one of my recent blog entries "HTTP performance testing with httperf, autobench and openload" instead of calling it more precisely "HTTP load testing". I didn't have access to the application code or the servers hosting the applications I tested, so I wasn't really doing performance testing, only load testing.
        然而,在实际中这两个术语又常常被互相的代替使用,就连我自己也有点心虚,因为我和其它人一样,在之前写的一篇文章"HTTP performance testing with httperf, autobench and openload"标题命名得不太准确,其实用"HTTP load testing"的话,反而会更准确点,因为我在里面又没有接触到代码,也没有接触到运行着被测程序的服务器。所以说,其实我并没有做性能测试,做的其实就是负载测试。


        I think part of the confusion is that no matter how you look at these two types of testing, they have one common element: the load testing part. Even when you're profiling the application and monitoring the servers (hence doing performance testing), you still need to run load tools against the application, so from that perspective you're doing load testing.
        我想混淆两者的部分原因是因为不管你对它们的看法是怎么样的,它们都有一个共同之处,就是负载测试的部分。即使你的确是正在分析*应用程序[代码51testing]和监视服务器(在做性能测试),但你仍然还是要使用负载工具给应用程序加压,所以从这一观点来讲,是可以讲你正在做负载测试。


        As far as I'm concerned, these definitions don't have much value in and of themselves. What matters most is to have a well-established procedure for tuning the application and the servers so that you can meet your users' or your business customers' requirements. This procedure will use elements of all the types of testing mentioned here and in my previous entry: load, performance and stress testing.
        到目前为止,我所提及到的这些定义其实都是没有什么太大的价值。实际上最应该关注的是为了可以达到你的用户或者你的商业客户的需求,而去调整应用程序及服务器的一个好流程。整个流程会涉及到的元素*包括了这篇文章及先前我写的那篇load performance and stress testing.里所讲过的所有测试类型的内容。


        Here's one example of such a procedure. Let's say you're developing a Web application with a database back-end that needs to support 100 concurrent users, with a response time of less than 3 seconds. How would you go about testing your application in order to make sure these requirements are met?
        我举个例子来讲讲这个流程。比如说你正在开发一个有数据库后台的WEB应用程序,要求它可以支持100个并发用户,反应时间要小于3秒。在这个情况下,你会怎么样测试这个程序,让它可以达到需求?


        1. Start with 1 Web/Application server connected to 1 Database server. If you can, put both servers behind a firewall, and if you're thinking about doing load balancing down the road, put the Web server behind the load balancer. This way you'll have one each of different devices that you'll use in a real production environment.
        1
        . 将一台Web或者一台Application服务器和一台数据库服务器连在一起。如果可以的话,可以把两个服务器放在一个防火墙后面。假如你想以后要应用负载平衡的技术的话,你可以考虑在Web服务器前放个负载平衡器。这种方法就可以让你在一种更贴近实际环境[的情况下进行测试了*51testing]

         

        2. Run a load test against the Web server, starting with 10 concurrent users, each user sending a total of 1000 requests to the server. Step up the number of users in increments of 10, until you reach 100 users.
        2
        . Web 服务器开始进行负载测试,先上10个并发用户,每个用户向服务器发1000个请求,然后再逐步1010个的增加并发用户,直到100个并发用户。


        3. While you're blasting the Web server, profile your application and your database to see if there are any hot spots in your code/SQL queries/stored procedures that you need to optimize. I realize I'm glossing over important details here, but this step is obviously highly dependent on your particular application.
        3.你可以在轰炸WEB服务器的时候[意指对WEB服务器加不同负载的整个过程],分析应用程序/SQL查询/存储过程*中是否存在需要优化改善的地方。我意识到在这一点有点过于强调了(*),这一步明显的取决于具体的项目(*)。


        Also monitor both servers (Web/App and Database) via command line utilities mentioned before (top, vmstat, iostat, netstat, Windows PerfMon). These utilities will let you know what's going on with the servers in terms of hardware resources. Also monitor the firewall and the load balancer (many times you can do this via SNMP) -- but these devices are not likely to be a bottleneck at this level, since they usualy can deal with thousands of connections before they hit a limit, assuming they're hardware-based and not software-based.
        同时还可以通过前面提到过的命令行工具(top,vmstat,iostat,netstat,Windows PerfMon)来监视web/appdatabase的服务器。这些工具可以让你了解服务器硬件资源的状况。同时也可以监视防火墙及负载平衡器[可以使用SNMP来做这种事],但由于这种设备具有很高的处理连接的能力,它们在这一层上并不会有瓶颈的问题出现,因此我们可以假设它们不是基于软件,而是基于硬件的。


        This is one of the most important steps in the whole procedure. It's not easy to make sense of the output of these monitoring tools, you need somebody who has a lot of experience in system/network architecture and administration. On Sun/Solaris platforms, there is a tool called the SE Performance Toolkit that tries to alleviate this task via built-in heuristics that kick in when certain thresholds are reached and tell you exactly what resource is being taxed.
        现在这一步就是整个流程中最重要的一环。要清楚的理解这些监控工具输出数据并不是一个容易的事情,这需要一些很有系统/网络 结构和管理经验的人的帮助。[让我挥挥小手,]举个例子来讲(译者注:让我想起51峰哥上课意气风发的挥挥小手,我就自己打上前面的[]里的内容了,呵呵!峰哥不要生气!)在SUN/SOLARIS平台上,就有一个叫SE Performance Toolkit的工具可以减轻这种痛苦。它可以通过内建的试探法*[启发式法?]当系统到极限的时候开始工作并告诉你具体承受着负载的资源情况*


        4. Let's say your Web server's reply rate starts to level off around 50 users. Now you have a repeatable condition that you know causes problems. All the profiling and monitoring you've done in step 3, should have already given you a good idea about hot spots in your applicationm about SQL queries that are not optimized properly, about resource status at the hardware/OS level.
        4
        . 唔。。。假设现在你的WEB服务器的回应速度已经平稳在50个用户的情况下*,你重现了一个会导致问题的环境条件*。通过上面的第三步的分析与监控,应该已经让你清楚的了解到你的应用程序内的问题点,没有被充分优化的SQL查询语句,以及硬件及操作系统的资源状况。
        At this point, the developers need to take back the profiling measurements and tune the code and the database queries. The system administrators can also increase server performance simply by throwing more hardware at the servers -- especially more RAM at the Web/App server in my experience, the more so if it's Java-based.
        到了这里,开发人员就需要取消*掉分析测量而开始调试代码及数据库的查询语句了。系统的管理员则同时可以通过简单的增加更多的硬件资源来提高服务器的性能,从我的经验上来看,特别要给WEB/APP服务器增加RAM,假如它是基于JAVA的则应该更多*
        5. Let's say the application/database code, as well as the hardware/OS environment have been tuned to the best of everybody's abilities. You re-run the load test from step 2 and now you're at 75 concurrent users before performance starts to degrade.
        5.
        好了,现在application/database代码,以及硬件/操作系统的环境都已经被调整得各个器件都发挥出它最大的功能了。然后你就应该从上面的第二步重新开始进行增加负载的测试,然后你就发现系统在性能开始下降前就,已经可以上到75个并发用户了。
        At this point, there's not much you can do with the existing setup. It's time to think about scaling the system horizontally, by adding other Web servers in a load-balanced Web server farm, or adding other database servers. Or maybe do content caching, for example with Apache mod_cache. Or maybe adding an external caching server such as Squid.
        在这一时刻,基于现在的这种优化过的硬件设备,你也没什么可以再做的了。也许是时候通过在负载平衡WEB服务器群组内增加其它的WEB服务器,或者增加其它的数据库服务器,也许还可以使用内容高速缓存技术(如使用Apache mod_cache),或者增加一个外部的高速缓存服务器(如Squid)等方法,来扩展一下你的系统了。
        One very important product of this whole procedure is that you now have a baseline number for your application for this given "staging" hardware environment. You can use the staging setup for nightly peformance testing runs that will tell you whether changes in your application/database code caused an increase or a decrease in performance.
        这整个的流程引出了一个非常重要的产物,就是一组在特定硬件条件下,针对你的应用程序基线化了的标准数值*。而你则可以通过每个阶段的设备来跑每晚的性能测试,而这个又可以让你得知你所改动的应用程序/数据库代码是否会引起性能上的消长*


        6. Repeat above steps in a "real" production environment before you actually launch your application.
        6.
        你可以在正式应用程序发布前,重复以上的步骤。
        All this discussion assumed you want to get performance/benchmarking numbers for your application. If you want to actually discover bugs and to see if your application fails and recovers gracefully, you need to do stress testing. Blast your Web server with double the number of users for example. Unplug network cables randomly (or shut down/restart switch ports via SNMP). Take out a disk from a RAID array. That kind of thing.
        这里所讨论的话题都是以你想得到你的应用程序的性能/基准的数值为假设,如果你是想要真正去发现bugs而且去看一下你的应用程序是不是可以在失效后,正常的恢复*,那么你所要做的是压力测试。比如说给你的WEB服务器加上两倍的用户数量,随机的拔掉网线(或者通过SNMP关掉/重启switch ports),从RAID阵列里拿个磁盘出来,等等。
        The conclusion? At the end of the day, it doesn't really matter what you call your testing, as long as you help your team deliver what it promised in terms of application functionality and performance. Performance testing in particular is more art than science, and many times the only way to make progress in optimizing and tuning the application and its environment is by trial-and-error and perseverance. Having lots of excellent open source tools also helps a lot.

        结尾了?其实到了最后,你将你的测试命名为什么都无关紧要,只要你可以帮助你们团队交付出曾经承诺过的功能及性能就行了。[说实在的,]性能测试是一种艺术活,而不是一种科学技术活。很多时候,能够使应用程序及它的运行环境的优化及调试,可以有所进展,只能靠持续不断的反复试验。同时一些优秀的开源工具也可以帮助很多。

        posted by Grig Gheorghiu at 3:20 PM

         

      7. Translation undergoing

        2007-01-23 23:23:34

        ;)

         

      8. 301/212>

        数据统计

        • 访问量: 14856
        • 日志数: 31
        • 图片数: 15
        • 书签数: 8
        • 建立时间: 2006-12-27
        • 更新时间: 2009-03-05

        RSS订阅

        Open Toolbar