yangkinki的个人空间_首页_51Testing软件测试网 - powered by X-Space

日历

« 2008-07-09  
  12345
6789101112
13141516171819
20212223242526
2728293031  

最新留言

统计信息

  • 访问量: 843
  • 日志数: 9
  • 建立时间: 2006-11-24
  • 更新时间: 2008-06-15

RSS订阅

我的最新日志

  • 测试用例设计方法例子

    2008-6-15

    测试用例设计方法例子

          一、等价类划分
      问:某程序规定:"输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)
      解:
          分析题目中给出和隐含的对输入条件的要求:
      (1)整数    (2)三个数    (3)非零数   (4)正数  
      (5)两边之和大于第三边     (6)等腰     (7)等边
       如果 a 、 b 、 c 满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一:
       1)如果不满足条件(5),则程序输出为 " 非三角形 " 。
       2)如果三条边相等即满足条件(7),则程序输出为 " 等边三角形 " 。
       3)如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰三角形 " 。
       4)如果三条边都不相等,则程序输出为 " 一般三角形 " 。
       列出等价类表并编号


       覆盖有效等价类的测试用例:
        a      b      c              覆盖等价类号码
        3      4      5             (1)--(7)
        4      4      5             (1)--(7),(8)
        4      5      5             (1)--(7),(9)   
        5      4      5             (1)--(7),(10)
        4      4      4             (1)--(7),(11)
       覆盖无效等价类的测试用例:

           二、边界值分析法
    NextDate函数的边界值分析测试用例
    在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050 。

    测试用例
    mouth
    day
    year
    预期输出
    Test1
    Test2
    Test3
    Test4
    Test5
    Test6
    Test7
    6
    6
    6
    6
    6
    6
    6
    15
    15
    15
    15
    15
    15
    15
    1911
    1912
    1913
    1975
    2049
    2050
    2051
    1911.6.16
    1912.6.16
    1913.6.16
    1975.6.16
    2049.6.16
    2050.6.16
    2051.6.16
    Test8
    Test9
    Test10
    Test11
    Test12
    Test13
    6
    6
    6
    6
    6
    6
    -1
    1
    2
    30
    31
    32
    2001
    2001
    2001
    2001
    2001
    2001
    day超出[1…31]
    2001.6.2
    2001.6.3
    2001.7.1
    输入日期超界
    day超出[1…31]
    Test14
    Test15
    Test16
    Test17
    Test18
    Test19
    -1
    1
    2
    11
    12
    13
    15
    15
    15
    15
    15
    15
    2001
    2001
    2001
    2001
    2001
    2001
    Mouth超出[1…12]
    2001.1.16
    2001.2.16
    2001.11.16
    2001.12.16
    Mouth超出[1…12]

     

           三、错误推测法
            测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

    I.          输入的线性表为空表;
    II.       表中只含有一个元素;
    III.     输入表中所有元素已排好序;
    IV.     输入表已按逆序排好;
    V.        输入表中部分或全部元素相同。
     
     
    四、因果图法
    有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。
    1) 分析这一段说明,列出原因和结果
    原因:
    1.售货机有零钱找
    2.投入1元硬币
    3.投入5角硬币
    4.押下橙汁按钮
    5.押下啤酒按钮
    结果:
    21.售货机〖零钱找完〗灯亮   
    22.退还1元硬币
    23.退还5角硬币             
    24.送出橙汁饮料
    25.送出啤酒饮料
    2)画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:
    11. 投入1元硬币且押下饮料按钮
                    12. 押下〖橙汁〗或〖啤酒〗的按钮
                    13. 应当找5角零钱并且售货机有零钱找
                    14. 钱已付清
    3)转换成判定表:
     
     
    五、判定表驱动分析方法
    问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,维修记录不全优先维修处理均已在别处有更严格的定义。请建立判定表。

    解答:

    ①确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

    ②列出所有的条件茬和动作桩:

     

    ③填入条件项。可从最后1行条件项开始,逐行向上填满。如第三行是:Y N Y N Y N Y N,第二行是:Y Y N N Y Y N N等等。 

    ④填入动作桩和动作顶。这样便得到形如图的初始判定表。

      1 2 3 4 5 6 7 8
    功率大于50马力吗? Y Y Y Y N N N N
    维修记录不全吗? Y Y N N Y Y N N
      运行超过10年吗? Y N Y N Y N Y N
    进行优先处理 x x X   X   X  
    作其他处理       X   x   x

    初始判定表

    ⑤化简。合并相似规则后得到图。

      1 2 3 4 5
    功率大于50马力吗? Y Y Y N N
    维修记录不全吗? Y N N - -
      运行超过10年吗? - Y N Y N
    进行优先处理 x x   X  
    作其他处理     x   x


  • 《软件测试的14种类型》

    2008-6-15

                           《软件测试的14种类型
      作者:啄木鸟(Sawin网站)

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。


    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。

    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

      

    2  软件测试的14种类型
      
    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。



    3  软件测试的14种类型
      比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?
    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。
  • 《黑盒测试的测试用例设计方法 》

    2008-6-15

    《黑盒测试的测试用例设计方法 》

    等价类划分

      是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

       1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

      有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

      无效等价类:与有效等价类的定义恰巧相反.

      设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

      2)划分等价类的方法:下面给出六条确定等价类的原则.

      ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

      ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

      ③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

      ④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

      ⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则).

      ⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

      3)设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

       输入条件 有效等价类 无效等价类
      ... ... ...
      ... ... ...

       然后从划分出的等价类中按以下三个原则设计测试用例:

      ①为每一个等价类规定一个唯一的编号.

      ②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

      ③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

    边界值分析法

      边界值分析方法是对等价类划分方法的补充.

    (1)边界值分析方法的考虑:

      长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    (2)基于边界值分析方法选择测试用例的原则:

      1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

      2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

      3)根据规格说明的每个输出条件,使用前面的原则1).

      4)根据规格说明的每个输出条件,应用前面的原则2).

      5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

      6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

      

      
      7)分析规格说明,找出其它可能的边界条件.

    错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

    因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型).
      因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

      利用因果图生成测试用例的基本步骤:

      (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

      (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

      (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

      (4) 把因果图转换为判定表.

      (5) 把判定表的每一列拿出来作为依据,设计测试用例.

      从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

      前面因果图方法中已经用到了判定表.判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

      判定表通常由四个部分组成.

      条件桩(Condition Stub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

      动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

      条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值.

      动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作.

      规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

      判定表的建立步骤:(根据软件规格说明)

      ①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有 种规则.

      ②列出所有的条件桩和动作桩.

      ③填入条件项.

      ④填入动作项.等到初始判定表.

      ⑤简化.合并相似规则(相同动作).

      B. Beizer 指出了适合使用判定表设计测试用例的条件:

      ①规格说明以判定表形式给出,或很容易转换成判定表.

      ②条件的排列顺序不会也不影响执行哪些操作.

      ③规则的排列顺序不会也不影响执行哪些操作.

      ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

      ⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

  • 快速测试与普通测试的区别

    2007-7-30

    快速测试与普通测试的区别
    http://www.csai.cn 作者:James Bach 来源:51testing论坛 2006年7月25日 发表评论 进入社区
    测试实践对于每个行业、每个公司、每个测试人员都是不一样的。但是大多数的测试项目在某些要素上是有共同之处的。让我们把那些有共性的要素称之为“普通测试”吧。在我们的经验中,普通测试包括根据某种规格说明书写一些测试用例。这些测试用例是松散地指导测试人员去测试一个产品的零散的计划或者过程。然后测试人员按照预期的那样在整个产品中执行那些测试用例,重复地,在项目过程中从头到尾地执行。

      快速测试与传统测试主要有以下几方面的区别:

      1. 首先,不浪费时间。最快速的行动是完全不行动。因此,在快速测试中,我们要消灭掉任何不必要的活动。比较起来,传统测试是比较臃肿的,随之也带来一定的混乱。当然,需要通过一些培训和经验来知道如何来对传统测试“瘦身”。一般地说,流线型的文档(应该是指大量的文档)和虔诚的测试是最容易发生风险的区域。不要因为别人告诉你重复是好的,你就来回的测同一个东西。确保你从每个测试中得到了好的、有价值的信息。要考虑每次测试活动的机会成本

      2.Mission。在快速测试中我们不是以Task为导向(如写测试用例),我们是以Mission为导向的。我们的目标可能是“快点找到重要的问题”。如果是这样,那么写测试用例可能不是最好的方式。另一方面,如果我们的目标是“使FDA听众满意”,那么我们不仅要写测试用例,还要按照指定的规格来写某几种测试用例。理解我们的Mission,然后估算一下我们的形势,并找到我们能朝着实现该目标立即开始执行的最快、最有用的行动。

      3.技巧。做好任何的测试都要求技巧。普通测试不重视测试技巧的重要性,它更多关注测试文档的格式而不是测试的健壮性。快速测试,就像我们描述的,强调测试技巧。它不是像用微波炉炸爆米花那样的机械技术,或者是在DMV(机动车管理部门)填表格。健壮的测试是非常重要的,因此我们练习批判性思维和试验设计技巧。一个测试新手不会在测试中做得很好,除非有一个在测试艺术、技艺上有较高造诣的资深测试人员来监督和指导。我们希望本站点的一些文章能够在这些技巧上帮助你。

      4.风险。普通测试关注功能和结构上的产品覆盖率。换句话说,如果产品能做什么,就测什么。快速测试更关注重要的问题。基于对产品的理解,找出那些我们认为的最可能发生并且发生后影响较大的问题。然后投入我们的主要精力来测试那些问题。快速测试往往意味着尽可能快的揭露最重要的信息。

      5.探索。快速测试也是快速学习,因此我们使用探索性测试。我们避免先写测试用例,除非有明确和强制性的要求。我们更喜欢让上一个测试影响我们的下一个测试。这是一个好事情,因为我们并没有被预先设计好的测试步骤所禁锢,而且让我们发现了更好的测试思想。让测试快速地执行的其它方式,例如很多的测试自动化,总是有着这样的风险――即使运行了大量的非常快速的测试也不能在产品中帮助你找到重要的问题。

      6.启发法。我们必须当心高估所测试的问题,因此我们使用启发法(简单的翻译成:拇指规则)来帮助我们避免思维短路,并且更快地测试。启发法本质上是反应――在某种意义上有偏差地反应――通常是帮助我们在正确地时间测试正确的东西。快速测试收集、记住并且练习使用有帮助的启发法。在普通测试中,启发法也有被使用,但是测试人员往往并不知道自己使用了这个方法,也不能完全地掌控这个方法。

      7.团队合作。快速测试意味着作弊。至少,我们做的事情在以前小学老师的眼中就是作弊:我们尽可能事先弄清楚事情,我们借用其它人的工作,我们使用我们能找到的任何资源和工具。例如,快速测试的一个重要的技术就是成对测试:两个人,一台电脑。这个思想在XP(极限编程)的实践中被证明是有效的,并且在测试工作中也很适用。在普通测试的经验中,测试人员通常安静、独自的工作,而不是像一群迅捷的狼在捕猎bugs。

      8.反省。我们的快速测试人员应该要经常问我们正在做什么和为什么这样做。我们要解析我们自己,并且讨论更好的测试策略和状况。
  • 白盒测试中的六种覆盖方法

    2007-7-30

    白盒测试中的六种覆盖方法
    http://www.csai.cn 作者:谷剑芳 来源:希赛网 2006年6月8日 

      摘要:白盒测试作为测试人员常用的一种测试方法,越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例,而是需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。因为对于不同复杂度的代码逻辑,可以衍生出许多种执行路径,只有适当的测试方法,才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

    白盒测试的概述

      由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的,因此我们要进行白盒测试。

      白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。

      白盒的测试用例需要做到:

    ·保证一个模块中的所有独立路径至少 被使用一次
    ·对所有逻辑值均需测试 true 和 false
    ·在上下边界及可操作范围内运行所有循环
    ·检查内部数据结构以确保其有效性

      白盒测试的目的:通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。

      白盒测试的特点:依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

      白盒测试的实施步骤:

    1.测试计划阶段:根据需求说明书,制定测试进度。
    2.测试设计阶段:依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。
    3.测试执行阶段:输入测试用例,得到测试结果。
    4.测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。

      白盒测试的方法:总体上分为静态方法和动态方法两大类。

      静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

      动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。

      白盒测试的优缺点

      1. 优点

    ·迫使测试人员去仔细思考软件的实现
    ·可以检测代码中的每条分支和路径
    ·揭示隐藏在代码中的错误
    ·对代码的测试比较彻底
    ·最优化

      2. 缺点

    ·昂贵
    ·无法检测代码中遗漏的路径和数据敏感性错误
    ·不验证规格的正确性

    六种覆盖方法

      首先为了下文的举例描述方便,这里先给出一张程序流程图。(本文以1995年软件设计师考试的一道考试题目为例,图中红色字母代表程序执行路径)。

      1、语句覆盖

      1)主要特点:语句覆盖是最起码的结构覆盖要求,语句覆盖要求设计足够多的测试用例,使得程序中每条语句至少被执行一次。

      2)用例设计:(如果此时将A路径上的语句1—〉T去掉,那么用例如下)

       X  Y  路径
     1  50  50  OBDE
     2  90  70  OBCE

      3)优点:可以很直观地从源代码得到测试用例,无须细分每条判定表达式。

      4)缺点:由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件和可能到达的隐式逻辑分支,是无法测试的。在本例中去掉了语句1—〉T去掉,那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支,那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行,而往往这种错误会经常出现。再如,在Do-While结构中,语句覆盖执行其中某一个条件分支。那么显然,语句覆盖对于多分支的逻辑运算是无法全面反映的,它只在乎运行一次,而不考虑其他情况。

      2、判定覆盖

      1)主要特点:判定覆盖又称为分支覆盖,它要求设计足够多的测试用例,使得程序中每个判定至少有一次为真值,有一次为假值,即:程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  50  50  OBDE
     3  90  70  OBCE

      3)优点:判定覆盖比语句覆盖要多几乎一倍的测试路径,当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。

      4)缺点:往往大部分的判定语句是由多个逻辑条件组合而成(如,判定语句中包含AND、OR、CASE),若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径。

      3、条件覆盖

      1)主要特点:条件覆盖要求设计足够多的测试用例,使得判定中的每个条件获得各种可能的结果,即每个条件至少有一次为真值,有一次为假值。

      2)用例设计:

       X  Y  路径
     1  90  70 OBC
     2 40   OBD

      3)优点:显然条件覆盖比判定覆盖,增加了对符合判定情况的测试,增加了测试路径。

      4)缺点:要达到条件覆盖,需要足够多的测试用例,但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果。

      4、判定/条件覆盖

      1)主要特点:设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  50  50  OBDE
     3  90  70  OBCE
     4  70  90  OBCE

      3)优点:判定/条件覆盖满足判定覆盖准则和条件覆盖准则,弥补了二者的不足。

      4)缺点:判定/条件覆盖准则的缺点是未考虑条件的组合情况。

      5、组合覆盖

      1)主要特点:要求设计足够多的测试用例,使得每个判定中条件结果的所有可能组合至少出现一次。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  90  70  OBCE
     3  90  30  OBDE
     4  70  90  OBCE
     5  30  90  OBDE
     6  70  70  OBDE
     7  50  50  OBDE

      3)优点:多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。

      4)缺点:线性地增加了测试用例的数量。

      6、路径覆盖

      1)主要特点:设计足够的测试用例,覆盖程序中所有可能的路径。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  50  50  OBDE
     3  90  70  OBCE
     4  70  90  OBCE

      3)优点:这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广。

      4)缺点:由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支选择等),那么需要设计大量、复杂的测试用例,使得工作量呈指数级增长。而在有些情况下,一些执行路径是不可能被执行的,如:
      If  (!A)B++;
      If  (!A)D--;

      这两个语句实际只包括了2条执行路径,即A为真或假时候对B和D的处理,真或假不可能都存在,而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率,而且大量的测试结果的累积,也为排错带来麻烦。

    总结

      白盒测试是一种被广泛使用的逻辑测试方法,是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性,尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径,即使穷举也未必会带来好运(穷举不能查出程序逻辑规则错误,不能查出数据相关错误,不能查出程序遗漏的路径)。

      那么正确使用白盒测试,就要先从代码分析入手,根据不同的代码逻辑规则、语句执行情况,选用适合的覆盖方法。任何一个高效的测试用例,都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果,而是尽可能全面地覆盖每一个逻辑路径。

  • 软件本地化测试类型解析与测试要领

    2007-7-30

    软件本地化测试类型解析与测试要领

    作者: 崔启亮  来源:本地化世界网  http://www.csai.cn  2005年10月31日

      软件本地化测试是在本地化的操作系统上对本地化的软件版本进行的测试。根据软件本地化项目的规模、测试阶段以及测试方法,本地化测试分为多种类型,每种类型都对软件本地化的质量进行检测和保证。为了提高测试的质量,保证测试的效率,不同类型的本地化测试需要使用不同的方法,掌握必要的测试技巧。本文主要选取本地化测试中具有代表性的测试类型进行分析,结合软件本地化项目的测试经验对其测试要领进行剖析。

      导航测试

      导航测试(Pilot Testing)是为了降低软件本地化的风险而进行的一种本地化测试。大型的全球化软件在完成国际化设计后,通常选择少量的典型语言进行软件的本地化,以此测试软件的可本地化能力,降低多种语言同时本地化的风险。

      导航测试尤其是用于数十种语言本地化的新开发的软件,导航测试版本的语言主要由语言市场的重要性和规模确定,也要考虑语言编码等的代表性。例如,德语市场是欧洲的重要市场,通常作为导航测试的首要单字节字符集语言。日语是亚洲重要的市场,可以作为双字节字符集语言代表。随着中国国内软件市场规模的增加,国际软件开发商逐渐对简体中文本地化提高重视程度,简体中文有望更多成为导航测试的首选语言。

      导航测试是软件本地化项目早期进行的探索性测试,需要在本地化操作系统上进行,测试的重点是软件的国际化能力和可本地化能力,包括与区域相关的特性的处理能力,也包括测试是否可以容易地进行本地化,减少硬编码等缺陷。由于导航测试在整个软件本地化过程中意义重大,而且导航测试的持续时间通常较短,另外由于是新开发的软件的本地化测试,测试人员对软件的功能和使用操作了解不多,因此,本地化公司通常需要在正是测试之前进行搜集和学习软件的相关资料,做好测试环境和人员的配备,配置具有丰富测试经验的工程师执行测试。

      可接受性测试

      本地化软件的可接受性测试(Build Acceptable Testing)也称作冒烟测试(Smoke Testing),是指对编译的软件本地化版本的主要特征进行基本测试,从而确定版本是否满足详细测试的条件。理论上,每个编译的本地化新版本在进行详细测试之前,都需要进行可接受性测试,以便早期发现软件版本的可测试性,避免不必要的时间浪费。

      注意,软件本地化版本的可接受性测试与软件公司为特定客户定制开发的原始语言软件在交付客户前的验收测试完全不同,验收测试主要确定软件的功能和性能是否达到了客户的需求,如果一切顺利,只进行一次验收测试就可以结束。

      本地化软件在编译后,编译工程师通常需要执行版本健全性检查(Build Sanity Check),确定本地化版本的内容和主要功能可以用于测试。而编译的本地化版本是否真的满足测试条件则还要通过独立的测试人员进行可接受性测试,它要求测试人员在较短的时间内完成,确定本地化的软件版本是否满足全面测试的要求,是否正确包含了应该本地化的部分。如果版本通过了可接受性测试,则可以进入软件全面详细测试阶段,反之,则需要重新编译本地化软件版本,直到通过可接受性测试。

      在进行本地化软件版本的可接受性测试时,需要配置正确的测试环境(软件和硬件),在本地化的操作系统上安装软件,确定是否可以正确安装。软件运行软件,确定软件包含了应该本地化的全部内容,并且主要功能正确。然后,卸载软件,保证软件可以彻底卸载。软件的完整性是需要注意的一个方面,通过使用文件和文件夹的比较工具软件,对比安装后的本地化软件和英文软件内容的异同,确定本地化的完整性。

      语言质量测试

      语言质量测试是软件本地化测试的重要组成部分,贯穿于本地化项目的各个阶段。语言质量测试的主要内容是软件界面和联机帮助等文档的翻译质量,包括正确性、完整性、专业性和一致性。

      为了保证语言测试的质量,应该安排本地化语言作为母语的软件测试工程师进行测试,同时请本地化翻译工程师提供必要的帮助。在测试之前,必须阅读和熟悉软件开发商提供的软件术语表(Glossary),了解软件翻译风格(Translation Style)的语言表达要求。

      由于软件的用户界面总是首先进行本地化,因此,本地化测试的初期的软件版本的语言质量测试主要以用户界面的语言质量为主,重点测试是否存在未翻译的内容,翻译的内容是否正确,是否符合软件术语表和翻译风格要求,是否符合母语表达方式,是否符合专业和行业的习惯用法。

      本地化项目后期要对联机帮助和相关文档(各种用户使用手册等)进行本地化,这个阶段的语言质量测试,除了对翻译的表达正确性和专业性进行测试之外,还有注意联机帮助文件和软件用户界面的一致性。如果对于某些软件专业术语的翻译存在疑问,需要报告一个翻译问题,请软件开发商审阅,如果确认是翻译错误,需要修改术语表和软件的翻译。

      关于本地化软件的语言质量测试,一个值得注意的问题是“过翻译”,就是软件中不应该翻译的内容(例如软件的名称等)如果进行了翻译,应该报告软件“过翻译”错误。

      用户界面测试

      本地化软件的用户界面测试(UI Testing),也称作外观测试(Cosmetic Testing)主要对软件的界面文字和控件布局(大小和位置)进行测试。用户界面至少包括软件的安装和卸载界面、软件的运行界面和软件的联机帮助界面。软件界面的主要组成元素包括窗口、对话框、菜单、工具栏、状态栏、屏幕提示文字等内容。

      用户界面的布局测试是本地化界面测试的重要内容,由于本地化的文字通常比原始开发语言长度增长,所以一类常见的本地化错误是软件界面上的文字显示不完整,例如,按钮文字只显示一部分。另一类常见的界面错误是对话框中的控件位置排列不整齐,大小不一致。

      相对于其他类型的本地化测试,用户界面测试可能是最简单的测试类型,软件测试工程师不需要过多的语言翻译知识和测试工具,但是由于软件的界面众多,而且某些对话框可能隐藏的比较深入,因此,软件测试工程师必须尽可能地熟悉被测试软件的使用方法,这样才能找出那些较为隐蔽的界面错误。另外,某个界面错误可能是一类错误,需要报告一个综合的错误,例如,软件安装界面的“上一步”或“下一步”按钮显示不完整,则可能所有安装对话框的同类按钮都存在相同的错误。

      功能测试

      原始语言开发的软件的功能测试主要测试软件的各项功能是否实现以及是否正确,而本地化软件的功能测试主要测试软件经过本地化后,软件的功能是否与源软件一致,是否存在因软件本地化而产生的功能错误,例如,某些功能失效或功能错误。

      本地化软件的功能测试相对于其他测试类型具有较大难度,由于大型软件的功能众多,而且有些功能不经常使用,可能需要多步组合操作才能完成,因此本地化软件的功能测试需要测试工程师熟悉软件的使用操作,对于容易产生本地化错误之处能够预测,以便减少软件测试的工作量,这就要求测试工程师具有丰富的本地化测试经验。

      除了某些菜单和按钮的本地化功能失效错误外,本地化软件的功能错误还包括软件的热键和快捷键错误,例如,菜单和按钮的热键与源软件不一致或者丢失热键。另外一类是排序错误,例如,排序的结果不符合本地化语言的习惯。

      发现本地化功能错误后,需要在源软件上进行相同的测试,如果源软件也存在相同的错误,则不属于本地化功能错误,而属于源软件的设计错误,需要报告源软件的功能错误。另外,如果同时进行多种本地化语言(例如,简体中文、繁体中文、日文和韩文)的测试,在一种语言上的功能错误也需要在其他语言版本上进行相同的测试,以确定该错误是单一语言特有的,还是许多本地化版本共有的错误。

      软件的测试类型数量众多,可谓五花八门,而软件本地化测试又具有其自身的特点,除以上常见的本地化测试类型外,还包括联机帮助测试、本地化能力测试等测试。不论何种类型的本地化测试,其最终测试目标都是尽早找出软件本地化错误,保证本地化软件与原始开发语言软件具有相同的功能。通过正确配置本地化测试环境,合理组织本地化测试人员,采用正确的本地化流程和测试工具,完善软件缺陷的报告和跟踪处理,有助于保证软件本地化测试的有效实现。

  • 国际化软件测试的特征分析

    2007-7-30

    国际化软件测试的特征分析

    归类: 软件测试 — gotoSQA admin @ 3:24 pm

    经济的全球化促进了软件产业的国际化,软件国际化生产和全球服务成为更多国际软件公司的发展策略。软件产品要获得更多的国际市场份额,必须进行软件国际化设计、开发、测试和服务。

    按照国际化要求生产的软件称为国际化软件,从实现技术和生产过程分析,国际化软件包括软件国际化和软件本地化两个相辅相成的环节。软件国际化保证软件具有“全球可用”的内在特征,而软件本地化可以满足目标市场的用户在语言、文化和功能的需要。

    国际化软件测试具有测试多方参与、跨国家 / 地区范围广、测试内容广泛、测试周期时效性强等特点。国际化软件测试的两个显著特征是缺陷跟踪工具驱动测试和项目里程碑驱动测试。

    国际化软件开发流程

    I18n process

    对于国际化软件而言,完整地开发周期将包括需求分析、国际化、本地化、发布和维护等过程。其中国际化包括设计、开发和测试等,在国际化的各个环节都要重视软件的本地化能力。

    国际化软件的开发流程包括开发国际化软件需要遵循软件工程的要求,分为需求分析、软件设计、软件编码、软件测试、质量保证、软件发布等过程。国际化软件的开发流程如下图所示:

    在需求分析阶段,既要考虑软件的功能需求,也要考虑软件的国际化需求。另外,为了缩短源语言开发的版本和本地化版本的发布时间间隔(甚至达到同步发布),国际化版本的开发应该与软件本地化过程同时进行。在测试方面,对国际化版本的国际化功能测试和对本地化版本的本地化测试尽可能同时进行,以便尽早发现和修改国际化设计错误。

    缺陷跟踪工具驱动的测试

    I18n tool

    国际化软件规模大、用户范围广、对质量的要求严格,所以软件测试过程中将发现和报告大量的软件缺陷。这些不同类型的软件缺陷分别由不同角色的项目成员负责处理,由于测试人员和开发人员可能分布在不同的国家和地区,因此,需要使用满足软件缺陷全球管理的软件缺陷跟踪( Defect Tracking System - DTS )系统。

    为了达到全球通用的目的,基于因特网的缺陷跟踪系统成为必选条件。借助全球的软件缺陷系统,软件项目团队的全体成员以软件缺陷跟踪系统为工作的参照物,如上图所示。测试人员向缺陷跟踪系统报告新 Bug ,在新版本上执行回归测试验证 Bug 是否正确修正;开发人员每天浏览属于自己需要处理的 Bug ,修正 Bug 后及时更新 Bug 的状态;项目经理根据缺陷跟踪系统的 Bug 分布信息,跟踪和控制软件开发过程;市场销售和技术支持人员根据缺陷跟踪系统的 Bug 状况,估计软件的发布期限。

    里程碑驱动的软件测试
    I18n milestones

    里程碑( Milestone )是项目实施过程的各个关键阶段,在国际化软件开发和测试项目中,里程碑表示软件开发和测试的标志性、阶段性临界点。软件开发过程有多个计划的里程碑,分别表示软件到各个阶段所具有的功能和完成的任务。

    从软件周期来讲,软件主要里程碑包括基本功能完成编码,软件完成 Alpha Build 和 Beta Build ,完成预发布 Build ( RC Build ),完成 RTM Build 。软件项目的里程碑示意图如右图所示。这些不同阶段的里程碑的测试内容不同,测试方法不同,每一个里程碑对应一个关键的软件项目阶段,时效性非常强,为了做到软件项目按照项目计划按时发布,要求软件测试人员做好准备,在软件测试计划和项目进度计划安排的时间,完成相应地测试任务。

    在软件编码完成后的里程碑应该完成基本功能测试(单元测试、集成测试),基本完成国际化测试,当软件完成本地化;在 Alpha 和 Beta 测试阶段开始本地化测试,结束国际化测试; RC Build 阶段完成本地化测试, RTM Build 阶段完成验收测试

  • 软件测试过程的度量

    2007-4-10

    软件测试过程的度量

    文章来源:卖烧烤的鱼博客 

    1)测试度量的作用(-)
       A:为制定测试计划时提供依据
        需要多长时间? 需要什么物质条件?  需要多少人,什么素质的人? 在规定的时间内能完成到什么程度?
        哪些模块及功能需要重点关注? 测试工作量占整个项目的比例? 测试结束后我们能达到什么样的目标 ?等等
    ( 这些数据是我们在项目启动过程中,制定测试计划,尤其在规划资源的过程中,一些必要的参考值。不同项目可能会有其特殊性,但从总体上看,他们还是有一些规律可寻的,过去的经验数据可以作为一个大概估算,如果项目经验丰富,那么可以从历史数据中找出和新项目 类似的情况,以能更为准确的完成计划。 )
      B: 提高测试流程可控性
        提高测试效率和质量
        提高测试人员的成就感

    2)在测试哪个过程做度量
    (产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段)
    我们需要在测试的几个关键阶段做度量,它们分别是:用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等,测试执行阶段很明显,即我们测试的各个过程,如集成测试、系统测试、性能测试、回归测试等,也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步,通过 FOA 我们可以获得很多为产品质量做贡献的度量,这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。

    3)测试度量的内容
    两种度量类型:
        A: 项目度量:规模、测试工作量、测试进度、测试生产率
        B: 质量度量:缺陷率(阶段)、缺陷排除率、可靠性等
    四个基本度量项:规模、工作量、进度、缺陷

    4) 测试用例设计阶段的度量
       A:规模 :测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
        B: 工作量 :文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
       C: 进度 :每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
        D: 缺陷 :评审过程中出现的错误数量、缺陷数量,级别

    5)测试执行阶段的度量:
    ? 测试用例执行率       ? 测试用例通过率
    ? 测试用例问题发现率     ? BUG数量
    ? BUG级别统计         ? BUG分布统计(模块)
    ? BUG分布统计(阶段)     ? BUG密度
    ? BUG关闭率          ? 人均BUG发现效率
    ? 测试用例执行工作量项目   ? 回归测试执行工作量
    ? 发布文档数量        ? 发布文档缺陷数量、级别
    ? 现场发现的BUG数量      ? 回归测试现场BUG的工作量
    ? 版本发布过程中的验证周期  ? 版本发布过程中的验证工作量
    ? 测试用例覆盖率       ? 功能的用户关注度
    ? 需求变化程度  

Open Toolbar