发布新日志

  • qtp访问数据库

    2011-03-23 13:51:52

    数据库,对任何一个系统来说,都是基础,所以qtp脚本自然不能避免和数据库打交道。

    首先我们需要在odbc数据源中定义一个系统dsn,配置我们的服务器名和用户名。

    然后我们就可以在dba中访问这个数据库了:建立数据库链接,查询或更新数据库数据内容。

    数据库的访问,无疑可以说是公共的,任何一个脚本只要向数据库发送请求,就需要写相同的脚本,完全可以把这部分内容进行抽取,形成公共函数调用。公共函数保存在 *.vbs文件中。

    '----------------------------------------------------------------
    '函数名:OpenConnection(DataSource)
    '参数说明:DataSource 数据源
    '作用:链接数据库
    '-----------------------------------------------------------------
    Function OpenConnection(DataSource)
    Dim cnn
    Set cnn = CreateObject("ADODB.Connection")
    If DataSource = "vcc" Then
            cnn.ConnectionString = "Provider=MSDASQL.1;Persist Security Info=true;User ID=vcctest;Password=vcc;Data Source=vcc"
    End If
    cnn.Open
    Set penConnection = cnn
    End Function

    '----------------------------------------------------------------
    '函数名:DataOperate(DataSource,sql,optype)
    '参数说明:DataSource 数据源,sql 删除sql语句记录,optype 操作类型“query”、“insert”、“update”、“delete”
    '作用:根据sql和datasource更新记录
    '-----------------------------------------------------------------
    Function DataOperate(DataSource,sql,optype)
    Dim cnn,rs
    cnn = OpenConnection(DataSource)
    Set rs = CreateObject("ADODB.RecordSet")
    rs.open sql,cnn,1,1
    DataOperate = null

    If ptype = "query" Then
    '   rs.open sql,cnn,1,1
       If not rs.eof Then
        DataOperate = rs.Fields(0).value
       End If
       rs.close
    elseif ptype = "insert" or ptype = "update" or ptype="delete" then
    '   rs.open sql,cnn,1,3
       rs.open "commit",cnn,1,1
    End If
    Set rs = nothing
    End Function

    ----单独的查询、更新、插入、删除函数---------

    '----------------------------------------------------------------
    '函数名:GetOne(DataSource,sql)
    '参数说明:DataSource 数据源,sql 查询sql语句
    '作用:根据sql和datasource获取一条查询记录
    '-----------------------------------------------------------------
    Function GetOne(DataSource,sql)
       Dim cnn,rs
       cnn = OpenConnection(DataSource)
       Set rs = CreateObject("ADODB.RecordSet")
       rs.open sql,cnn,1,1
       GetOne = null
       '如果结果集有记录,且不是指向结果集最后,rs.eof = false
       If not rs.eof Then
        GetOne = rs.Fields(0).value
       End If
       Set rs = nothing
    End Function

    '----------------------------------------------------------------
    '函数名:InsertOne(DataSource,sql)
    '参数说明:DataSource 数据源,sql 插入sql语句记录
    '作用:根据sql和datasource插入新记录
    '-----------------------------------------------------------------
    Function InsertOne(DataSource,sql)
       Dim cnn,rs
       cnn = OpenConnection(DataSource)
       rs = CreateObject("ADODB.RescordSet")
       rs.open sql,cnn,1,1
       rs.open "commit",cnn,1,1
       Set rs = nothing
    End Function

    '----------------------------------------------------------------
    '函数名:UpdateOne(DataSource,sql)
    '参数说明:DataSource 数据源,sql 更新sql语句记录
    '作用:根据sql和datasource更新记录
    '-----------------------------------------------------------------
    Function UpdateOne(DataSource,sql)
       Dim cnn,rs
       cnn = OpenConnection(DataSource)
       Set rs = createObject("ADODB.RecordSet")
       rs.open sql,cnn,1,1
       rs.open "commit",cnn,1,1
       Set rs = nothing
    End Function

    '----------------------------------------------------------------
    '函数名:DeteleOne(DataSource,sql)
    '参数说明:DataSource 数据源,sql 删除sql语句记录
    '作用:根据sql和datasource更新记录
    '-----------------------------------------------------------------
    Function DeleteOne(DataSource,sql)
       Dim cnn,rs
       cnn = OpenConnection(DataSource)
       Set rs = CreateObject("ADODB.RecordSet")
       rs.open sql,cnn,1,1
       rs.open "commit",cnn,1,1
       Set rs = nothing
    End Function


    转自 http://hi.baidu.com/hihelens/blog/item/4baee5247b8d052cd5074232.html
  • 快速划分测试用例的优先级(转自51)

    2008-12-09 16:19:55

    从未有足够的时间做所有我们需要做的事情,这是在软件项目,尤其在测试中的一个普通的话题。假使你在可用的有限时间内,你如何知道你的测试工作做的最好?你知道当应用程序发布时,总会有些遗漏的缺陷没有被发现。对于测试而言,目标是通过改进产品质量使风险减到最小,并且这可以部分的通过建造一套具体的测试用例来将应用程序按照它的速度完成等方法实现。

    IEEE Standard 610 (1990) 中定义测试用例为:

    1. 为一个为特定目标而开发一组测试输入,执行条件和的期望结果,例如测试某个程序路径或核实是否满足某个特定的需求。

    2.指定输入,预期结果和一组测试项的执行条件的文档 (IEEE Std 829-1983)

     当然,你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行,什么应该被执行,同时如果你有时间的话,什么又可以被执行?

     给你的测试用例划分优先级别

    你的应用程序不需要十全十美,但它必须迎合你目标用户的需求和期望。为了了解你项目的期望,你需要确定什么是应用程序中最重要的,目标和风险又是什么。

    Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题,她在文中注解到:“当我们在详细的计划,设计或编码之前沟通质量目标时,我们有一个更好的机会来避免在最后时刻的质量不匹配,那意味着迎合计划,弥补花费并且赢利将有一个更好的成功的机会。”

    为了测试计划的目的,在你项目版本的进度下,测试执行的组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分,我们要考虑每一个测试用例的优先级别。根据优先级别分组你的测试用例将帮助你决定不同类型的版本需要什么样的测试用例,因此计算需要的时间。如果你只有有限的时间,你可以查看什么是最合适。

    Ross Collard"Use Case Testing"一文中说:“测试用例的前10%15%可以发现75%90%的重要缺陷”。

    测试用例的优先级划分将帮助确定找出了这前10%15%的测试用例。

    如何划分测试用例的优先级别

    你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集?这个答案可能是不经常。停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时,分配优先级别是不容易,并且在项目期间里不一定是静止的。然而,我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书, 用例和其他一些关于你应用程序的目标行为和能力的信息源完成了建立测试用例。现在是时候来为每个测试用例分配一个优先级别了。

    测试用例的优先级别

    首先,你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说, 我们将用一个假设开始,那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。

    1 –小版本确认测试(Build Verification Tests (BVTs):也叫做“冒烟测试”,一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作,那么在执行这个优先的测试用例之前,试图做其他任何的测试都是没有意义的,因为他们大多数肯定要失败。

    2 – 高(Highs):最常执行以保证功能性是稳定的,目标的行为和能力可以正常的工作,和重要的错误和边界被测试的测试用例的集合。

    3 – 中(Mediums):这是使给出的功能区域或功能变得更详细,检查功能的多数方面包括边界,错误和配置测试的测试用例

    4 – 低(Lows):这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要,只是说他们在项目的生命期间里不是常常被运行,例如GUI,错误信息,可用性,压力和性能测试

    我们将测试用例分成4类:BVTs,高,中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟,优先级别将指出哪些测试用例被认为是需要更频繁的执行的,哪些又不是。

    怎样着手分配优先级别

    1) 随意地分配:

    基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法,前面这3 步将让你任意的分组测试用例,如果你也停下来思考每个测试用例的测试的内容,它们都将变的很重要。因此只需要:

    I)                     把你所有功能性验证(或基本路径(Happy Path))的测试标注为高优先级别

    II)                   把你所有错误和边界值或确认测试标注为中优先级别

    III)                  把你所有非功能性的测试(例如性能和可用性)标注为低优先级别.

    2) 提升和降级:

    并非所有的功能性测试都一样的重要,并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试,你想要检查这个功能的频率-考虑质量目标和你项目的需求。

    I)                     把功能性验证测试分为两组:重要和不是十分重要。

    II)                   将“不是十分重要”的能性验证测试降级为中优先级别

    III)                  把错误和边界测试分成两组:重要和不是十分重要

    IV)                将“重要”的错误和边界测试升级为高优先级别

    V)                  把非功能性测试分成两组:重要和不是十分重要

    VI)                把“重要”的非功能性测试升级为中优先级别

    VII)               针对每组高,中和低优先级别的测试用例,重复划分和升级/降级流程直到你达到一个点,可以在不同优先级别之间移动的测试用例的数量到最小。

    3) 识别小版本验证测试用例(Build Verification Tests):

    现在,为了确保小版本是可以测试的并准备好给小组其他成员开始测试,哪些测试用例是必须在每个小版本中都检查呢?

    I)                     将好优先级别的测试用例分成两组:严重和重要的

    II)                   将“严重”的高优先级的测试用例升级为BVT优先级

    注意:不要先识别BVT测试用例!BVT只是高优先级别测试用例的精选,它们已经被确定为对系统和测试是非常重要的。

    在这个流程的最后,就是要检查优先级别的百分比分布情况是:BVT10-15%,高为20-30%,,中为40-60%,低为10-15%

    在升级和降级测试用例时,需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的,对于用户日常的或月尾的活动而言,这种行为的严重性是如何。Robyn Brilliant在测试进度报告中提供了一个清单,你可以在考虑降级或升级测试用例的时候使用

    使用从一到五的一个刻度,从最严重到最少的严重程度,量化可靠性风险如下:

    I)               这个功能的失败将影响用户。

    II)             这个功能的失败将给公司造成重大的影响

    III)            这个功能的失败将引起一个潜在的延期给客户

    IV)          这个功能的失败对公司将有较小的影响

    V)            这个功能的失败没有任何影响

    这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。

    总结

    这是一个简化的划分测试用例优先级别过程的例子。然而,在快速组织测试用例和安排测试进度和工作量,及制订项目计划时需要完成哪些测试用例等方面,它可以给你很多帮助。

    记住,你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时,你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映,当它在解释并执行你的计划时,将使你的生活变得容易得多。

    最后,拥有划分了优先级别的测试用例也为你潜在的,待定的自动化项目给出了一个好的起点。比如,自动化BVT中的测试用例,度量收益,改进测试自动化,自动化高优先级的测试用例等方面。

  • 测试用例设计步骤(转)

    2008-12-09 14:41:51

    设计测试案例的时候,需要有清晰的测试思路,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程,而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤:

    1、测试需求分析

    从软件需求文档中,找出待测试软件/模块的需求,通过自己的分析、理解,整理成为测试需求,清楚被测试对象具有哪些功能。测试需求的特点是:包含软件需求,具有可测试性

    测试需求应该在软件需求基础上进行归纳、分类或细分,方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系,即一个或多个测试用例集对应一个测试需求。

    2、业务流程分析

    软件测试,不单纯是基于功能的黑盒测试,还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点,需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前,先画出软件的业务流程。如果设计文档中已经有业务流程设计,可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程,测试工程师应通过阅读设计文档,与开发人员交流,最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向,从而指导测试用例的设计。

    从业务流程上,应得到以下信息:

    A、                   主流程是什么

    B、                   条件备选流程是什么

    C、                   数据流向是什么

    D、                   关键的判断条件是什么

    3测试用例设计

    完成了测试需求分析和软件流程分析后,开始着手设计测试用例。测试用例设计的类型包括功能测试,边界测试,异常测试,性能测试,压力测试等。在用例设计中,除了功能测试用例外,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。

    黑盒测试的测试用例设计方法有:等价类划分、边界值划分、因果图分析和错误猜测,白盒测试的测试用例设计方法有:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法,结合前面的需求分析和软件流程分析进行设计:

    功能测试:测试某个功能是否满足需求的定义,功能是否正确,完备。

    适合的技术:由业务需求和设计说明导出的功能测试、等价类划分

    边界测试:对某个功能的边界情况进行测试。

              适合的技术:边界值划分

    异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。

              适合的技术:由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、

    性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。

             适合的技术:业务需求和设计说明导出的测试

    压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。

             

    4、测试用例评审

    测试用例设计完成后,为了确认测试过程和方法是否正确,是否有遗漏的测试点,需要进行测试用例的评审。

    测试用例评审一般是由测试leader安排,参加的人员包括:测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕,测试工程师根据评审结果,对测试用例进行修改,并记录修改日志。

     

    5、测试用例更新完善

    测试用例编写完成之后需要不断完善,软件产品新增功能或更新需求后,测试用例必须配套修改更新;在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。测试用例是“活”的,在软件的生命周期中不断更新与完善。

  • 从测试用例看测试的问题及变化(转)

    2008-12-09 14:23:58

    对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术,它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

    一、问题:

    许多测试类书籍中都有大幅的篇章介绍用例的设计方法,如等价类划分,边界值,错误推断,因果图等。但实际应用中这些理论却不能给我们很明确的行为指导,尤其是业务复杂,关联模块紧密,输入标准和输出结果间路径众多时,完全的遵循这些方法只能让我们在心理上得到一种满足,而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验(或习惯),希望能在这一个项目中更加规范,但多数情况下我们规范的只是“书写的规范”,在用例设计上以前存在的问题现在依旧。

    当好不容易用例基本完成,我们却发现面对随之而来的众多地区特性和新增需求,测试用例突然处于一种十分尴尬的境地:

    l         从此几乎很少被执行

    l         已经与程序的实现发生了冲突(界面变动,功能变动)

    l         执行用例发现的bug很少

    l         根本没有时间为新的功能需求增补用例

    l         有时间补充,但用例结构越来越乱,

    l         特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改,但特性与通行之间的数据或业务联系在用例中逐渐淡化)

    l         知道怎样执行这个用例,但它要说明什么呢?(多数用例给我们的感觉是只见树木,不见森林,只对某一功能,无法串起)

    通过上面的一系列问题可以看到,似乎测试用例给我们带来的问题远多于益处,也正是因为在实际过程中遇到的问题积累,导致我们有很充分的理由忽视或拒绝用例的应用。

    但没有用例或简略用例的编写我们又会舒服很多么?不言自明,谁也不想倒退发展吧。

    二、原因:

    事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现,究其原因我认为有如下几点:

    1、没有适合的规范

    “适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题,通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义,但它适合我们当前的项目么?

    每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语,进入公司或项目组后也会进一步学习相应的文档,例如怎样规范编写,怎样定义bug级别,软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时,又有多少人知道该怎样去写,怎样写算是好?

    在测试论坛中常能看到介绍用例编写方法的帖子,而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制,不管是结构还是方式都依赖于以往·的经验,我并不是说这样就是错误的,但不能总结成文的经验无法给予测试更多帮助。

    我们有太多经验,但却没有形成适合的规范。

    2、功能与业务的分离

    我们知道怎样列举一个输入框的用例,但却很少考虑说明这个输入框是用来做什么的,如果仔细分析不难发现,用例中这种功能与业务的分离越来越普遍也越来越明显。

    边界值、等价类划分、因果图,这些用例方法是一种高度提纯的方法,本身就很偏向于功能及代码,所以怎样编写业务的用例我们就从理论上失去了参考。

    复杂的业务会贯穿于整个软件,涉及众多功能点,里面组合的分支更不可胜数。测试用例务求简洁、明确,这一点也与业务“格格不入”。功能用例依赖程序界面,业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例,列举出众多的边界值、等价类。流程的操作只有凭借经验和理解,这时测试出的bug是最多的,但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)。正因为我们没有很好的积累业务上的用例,才使得我们感到执行用例时发现的bug不多。

    用例结构的划分一定程度上也造成了功能和业务的分离,依照界面模块建立文件夹,并在其中新建不同用例,这使得用例从结构上就很难联通起来。

    3、测试未能跟上变化

    变化!想象一下,当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候,测试又有什么举措呢?当地区特性,软件版本越来越多的时候,测试是否在积极响应呢?变化是我们面临的最大挑战,我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

    对需求和程序的变化测试人员的感受是非常深的,测试总是跟在需求和开发后面跑,使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作:尽快投入测试,尽快发现bug,而非从整体把握软件的质量情况,统筹策略。

    疲于应对的直接影响就是程序质量无法准确度量,进度无法控制,风险无法预估。用例与程序脱节,新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例,甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要,没有测试数据的保留,测试步骤和重点无法体现,新加功能与原来的程序逐渐“脱离”,可能还会出现相互违背的情况,但这我们却无法很快发现。

    永远是变化决定我们的下一步工作,这也是混乱的开始。

    三、可能的解决办法:

    在这里我希望以探讨的方式提出一些可能的解决办法,因为上面的问题也许在成熟的公司和项目组内很少遇到,而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式,最适合的就是最好的。

    1、测试驱动开发,用例指导结果,数据记录变化

    “测试驱动开发”(TDD)是一个比较新的概念,在网上可以看到很多介绍文章,它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean),“测试驱动开发的基本思想就是在开发功能代码之前,先编写测试代码”。可以看到,TDD是建立在“代码”级别的驱动,但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

    首先我们需要纠正一个态度,很多人认为黑盒测试的技术含量不高,可思考可拓展的内容不多,主要的工作就是用鼠标在那里瞎点,于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug80%以上都是黑盒测试发现的,手工操作软件仍是目前检验软件质量最有效的一种方法。

    如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起,以业务用例指导过程和结果。

    开发人员通常比较关注技术,对于业务上的理解容易忽视并出现偏差,而需求文档又不会很明确的指出应该实现怎样的结果,这使得从业务到功能出现一个“阅读上的障碍”,如果最后程序错误了还需返工,这样耗费的人力物力就非常大了。使用业务用例驱动开发,就是一个比较好的方法,同样这也需要运用测试中的各种方法,列举出业务流程里数据的等价类和边界值。

    业务用例的构造要先于程序实现,与需求和开发人员沟通一致,并以此作为一个基准,保证程序实现不会错,还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面,但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

    我们不仅要应对变化,还要记录变化,使测试用例成为对程序持续性的监控,数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的),使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享,最理想的情况就是建立一个“数据库”,每个业务用例都从“数据库”中取得输入数据和预期结果,这个数据只是针对业务入口和出口的,当程序内部设计变更时,保留的数据不会因此而作废。举一个例子,例如我的程序要从某种文件中读取数据并计算结果,一段时间后程序内部字段增加了,如果是以保存的文件附件方式提供数据,则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入,而不关心程序内部结构。

    再进一步的话“数据库”就开始涉及到程序内部的接口了,这需要开发人员的配合。

    2、为用例标明时间(版本)和优先级

    为测试用例标明时间或版本可以起到一种基准的作用,标明项目进度过程中的每一个阶段,使用例直接和需求基线、软件版本对应。同样这需要规范流程,也是对变更的一种确认和控制。或者可以为用例增加一个状态,指明这个用例目前是否与程序冲突,当程序变更时改变用例的状态,并更新用例版本。

    为测试用例标明优先级可以指出软件的测试重点、用例编写的重点,减少用例回归的时间,增加重点用例执行的次数,帮助项目组新人尽快了解需求,在自动化测试的初期也可以参考这个优先级录制脚本

    3、功能用例与业务用例分开组织

    将功能用例与业务用例分开组织,按照不同关注点列举执行路径。业务用例应在开发前或同期编写,帮助测试人员和开发人员明确业务,了解正确流程和错误流程。功能用例更依赖于程序界面的描述,但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug,也许与业务无关,但用户往往很容易这样操作(例如登录名,你是否考虑到很长的名字,或者用户的键盘有问题,总是敲入n多空格在里面,这与业务无关,但程序将会怎样处理?)。

    4、审核用例,结对编写

    测试组长或经理对用例进行审核可以做到用例的补充和校对,但一般情况下是很难做到的,我们可以采用另一种方法,就是结对编写测试用例(前提是你有两个以上的测试人员),内部审核。

    测试用例不是一个人编写一个人执行,它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”,同时也能拓展思维,加强测试重点的确认,小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理,提高组员的参与积极性。

    四、发展

    上面的这些解决方法只是一种建议,具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的,传统的黑盒测试并不是毫无新意,测试工作怎样适合我们而发展,将给予我们更多的思考。

  • 测试用例设计(全面,转自51)

    2008-12-09 14:10:28

    测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。51Testing软件测试网.q}y3{/?M8QVP

    $jcre }5p @154414测试用例(Test Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试
    脚本等,并形成文档。51Testing软件测试网.i([)khe E'ZNF
    51Testing软件测试网 x+R8p8T(a(NBd
    不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
    Y/vM)MCEexy|Z15441451Testing软件测试网s2m-g2PDl%cXi%@zN
    随着中国软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之,并有向第三方专业测试公司发展的趋势。51Testing软件测试网!J xiA/Of
    51Testing软件测试网0[%tM^9~L|7q.i6g
    要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。51Testing软件测试网gk?"o(M U5A-x'k
    51Testing软件测试网Xod(tY
    既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
    )zqm;h B;O0R.?pX/|15441451Testing软件测试网1mF.\pl6Fk`;J
    确定测试用例之所以很重要,原因有以下几方面。51Testing软件测试网l.hNEy"S#H*g

    O].t4@ |*M;Vl%r t154414测试用例构成了设计和制定测试过程的基础。51Testing软件测试网EQfO n
    测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,您对产品质量和测试流程也就越有信心。
    "[GSb$HseE154414判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明:“95 % 的关键测试用例已得以执行和验证”,远比“我们已完成 95 % 的测试”更有意义。51Testing软件测试网b!sCeA9xE
    测试工作量与测试用例的数量成比例。根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排。51Testing软件测试网5@ `_F(c:Fj2?"F%@f
    测试设计和开发的类型以及所需的资源主要都受控于测试用例。
    QlGXQq4s A$ip154414测试用例通常根据它们所关联关系的测试类型或测试需求来分类,而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例:51Testing软件测试网R~4]3Kr7Z'MW

    :D,pC(J_ ra }/}(D154414·一个测试用例用于证明该需求已经满足,通常称作正面测试用例;51Testing软件测试网m@S4{.I!g
    ·另一个测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例。51Testing软件测试网 i_ua ZHa3yJjN i
    51Testing软件测试网@p:Ee5ka4~
    51Testing软件测试网9m-Z'] ?zd2\Y+d {8m X
    一、测试用例是软件测试的核心51Testing软件测试网V:Myq#h ^

    5`/``9Vm ju6MXE154414软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
    .j&g%|.j[Z#D$O\o154414
    Bo VE-MN5T Tw E`154414影响软件测试的因素很多,例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的,无法避免。有些因素则是波动的、不稳定的,例如开发队伍是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪等影响,等等。如何保障软件测试质量的稳定?有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。51Testing软件测试网8v*PG ~ | ~7x+P?"s-eN

    LN,tZC4}ZrU154414因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导,是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。51Testing软件测试网B"Xz&X]LW A _4uT

    U%xCw(t'[154414二、编制测试用例
    Ul*Sdn(I15441451Testing软件测试网qTIG6[:SBIpn$}
    着重介绍一些编制测试用例的具体做法。
    pq)E,z,K4M t15441451Testing软件测试网S2@N)D,d FjM
    1、测试用例文档51Testing软件测试网8Uv1f0Koh~} {d*r

    2wH7R5K3d} o154414编写测试用例文档应有文档模板,须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
    :{6wLzRQ r-qqX154414软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。
    7d0k8} Zacg15441451Testing软件测试网pIP,M\Rvc[
    测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素:测试索引,测试环境,测试输入,测试操作,预期结果,评价标准。51Testing软件测试网j~zs6T

    $i4F v9a)A[F1544142、测试用例的设置
    (]G~!vf;i9nQs154414
    zm(]:h$S[hjUQg154414我们早期的测试用例是按功能设置用例。后来引进了路径分析法,按路径设置用例。目前演变为按功能、路径混合模式设置用例。
    *@c Y:``u3t y15441451Testing软件测试网"q/T)taL6X
    按功能测试是最简捷的,按用例规约遍历测试每一功能。
    e*fNJ I4XUli%L154414
    8a"@NfB F.k:^154414对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。没有严密的逻辑分析,产生遗漏是在所难免。路径分析是一个很好的方法,其最大的优点是在于可以避免漏测试。51Testing软件测试网rDO ew#G"k$f
    51Testing软件测试网G+}/i&G3x*Bs f
    但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块,这些模块相互有关联。再采用路径分析法,其路径数量成几何级增长,达5位数或更多,就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。
    6Bs Q r(H154414
    {qO.p&hO&a&I1544143、设计测试用例
    _1_*DD V(e6rJ;h154414
    f1Xk(GyMxPQ?154414测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例,应该参照用例规约(或设计规格说明书),根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能,覆盖率达100%。51Testing软件测试网\(o7mwm?

    p] ~2`*l4z:Q_154414设计备选事件和异常事件的用例,则要复杂和困难得多。例如,字典的代码是唯一的,不允许重复。测试需要验证:字典新增程序中已存在有关字典代码的约束,若出现代码重复必须报错,并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件,并同时尽量发现其中的软件缺陷。
    ,q7i9s u KQ/z154414
    RJ8A8R$^ `154414可以采用软件测试常用的基本方法:等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例,并最终实现暴露隐藏的缺陷,全凭测试设计人员的丰富经验和精心设计。51Testing软件测试网 d'D B[f,sw,G2h

    $b F t}5Do)_154414三、测试用例在软件测试中的作用51Testing软件测试网D0Zw%y#nkh

    b"[ OvWv"O1544141、指导测试的实施
    l}4T[1ce@:D15441451Testing软件测试网wk,IA2q,]
    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准,测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中,以便自动生成测试结果文档。
    ~d5HAcJGg*M15441451Testing软件测试网:ND9bmg1S |tMQ
    根据测试用例的测试等级,集成测试应测试那些用例,系统测试和回归测试又该测试那些用例,在设计测试用例时都已作明确规定,实施测试时测试人员不能随意作变动。
    yJ5o(NH3iv154414
    #yN-a%H V2D*s _\H1544142、规划测试数据的准备51Testing软件测试网oXJR$N)_#J

    /bo"Ea&m*{7y0KY154414在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。尤其象测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。
    i!V(F ]y[QDF154414除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据。51Testing软件测试网*I@ u&nkn-H Z&y

    uqDus#P+F{3a T1544143、编写测试脚本的"设计规格说明书"51Testing软件测试网Q[4Ai ~
    51Testing软件测试网j&D m$}b6WX
    为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例。
    3x)N]H&k}lm15441451Testing软件测试网u/v-JI!O!A r V
    4、评估测试结果的度量基准51Testing软件测试网co(K2]n6y g*{ y$^p"u
    51Testing软件测试网%q u8y1b t]
    完成测试实施后需要对测试结果进行评估,并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。以前统计基准是软件模块或功能点,显得过于粗糙。采用测试用例作度量基准更加准确、有效。51Testing软件测试网!p4uxUj2rv

    ?jD d3vsF!_]oj1544145、分析缺陷的标准51Testing软件测试网@Z W q]3}

    5ID9f;c2fv'D154414通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。51Testing软件测试网 j/I ha._b"f3YG

    ~7Zi,OUt!iv154414四、相关问题
    |T USGz@154414
    D-ylK`s:xF1544141、测试用例的评审
    3t xzOk-_bL15441451Testing软件测试网t.f%q j:f)R$VO2M
    测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审,需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成,也可邀请客户代表参加。51Testing软件测试网%Xc*EhP agvI

    \7n4W|3giM_0L1544142、测试用例的修改更新
    #q WMl;H!cu o154414
    F\ K|~154414测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故:第一、在测试过程中发现设计测试用例时考虑不周,需要完善;第二、在软件交付使用后反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成;第三、软件自身的新增功能以及软件版本的更新,测试用例也必须配套修改更新。
    )_ aoXh^D^15441451Testing软件测试网y o+u'A5S K @2x!i
    一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。51Testing软件测试网@0EC8EyF)|i
    51Testing软件测试网7AXw Eta:i,Ylb
    3、测试用例的管理软件51Testing软件测试网,O-p/hMO|!U
    51Testing软件测试网 _+w/A @&oA
    运用测试用例还需配备测试用例管理软件。它的主要功能有三个:第一、能将测试用例文档的关键内容,如编号、名称等等自动导入管理数据库,形成与测试用例文档完全对应的记录;第二、可供测试实施时及时输入测试情况;第三、最终实现自动生成测试结果文档,包含各测试度量值,测试覆盖表和测试通过或不通过的测试用例清单列表。51Testing软件测试网#gR4W8rF1@ C
    51Testing软件测试网;f5w#m2X&h0w1X4mY
    有了管理软件,测试人员无论是编写每日的测试工作日志、还是出软件测试报告,都会变得轻而易举。51Testing软件测试网 } Q&a u mR[
    51Testing软件测试网$u A2Nh._B%i;ZKu
    五、测试用例的设计51Testing软件测试网[)`+z!w9I

    $fxB w"b%d)J154414(一)白盒技术51Testing软件测试网@\u6l)Nj"z
    51Testing软件测试网u*{ vo4t K [
    白盒测试是结构测试,所以被测对象基本上是源程序,以程序的内部逻辑为基础设计测试用例。
    m2J`(fm q"?j1544141、逻辑覆盖
    uZ4V9gu`E154414程序内部的逻辑覆盖程度,当程序中有循环时,覆盖每条路径是不可能的,要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。下面根据图7-1所示的程序,分别讨论几种常用的覆盖技术。51Testing软件测试网`*l9wT+@
    (1)语句覆盖。51Testing软件测试网 tV%P.C:l(j2Rwl
    为了个提高发现错误的可能性,在测试时应该执行到程序中的每一个语句。语句覆盖是指设计足够的测试用例,使被测试程序中每个语句至少执行一次。51Testing软件测试网#B9EM~1c
    如图7-1是一个被测试程序流程图:
    FmW$JEh!f.w!s`n15441451Testing软件测试网;LPGUj3p9U @Dl H!u&R

    :E,d"Z!xf Z9_154414(2)判定覆盖。
    P@3K? m3^Wzx154414判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次“真”值和“假”值,从而使程序的每一个分支至少都通过一次,因此判定覆盖也称分支覆盖。51Testing软件测试网%k9Ukh0al7G
    (3)条件覆盖。
    f8?VR1V q154414条件覆盖是指设计足够的测试用例,使得判定表达式中每个条件的各种可能的值至少出现一次。51Testing软件测试网+y&DEFg9iz
    (4)判定/条件测试。
    P)|M$?HDb bj154414该覆盖标准指设计足够的测试用例,使得判定表达式的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次。
    r8_X*GB:}3Y%U154414(5)条件组合覆盖。51Testing软件测试网 K,~d6I]i^9~5Y E"s
    条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。51Testing软件测试网T[HD#p5ID,P5ko
    (6)路径覆盖。
    3jD k[E154414路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径。
    8J!v&MmL@k154414在实际的逻辑覆盖测试中,一般以条件组合覆盖为主设计测试用例,然后再补充部分用例,以达到路径覆盖测试标准。51Testing软件测试网/pa4CiU1e
    2.循环覆盖
    LKNl/w(o3e\%M1544143.基本路径测试51Testing软件测试网"buIF} p F/IK6J
    51Testing软件测试网a(|D d5G s"Ny'l
    51Testing软件测试网 r2V3DNw(E
    (二)黑盒技术51Testing软件测试网e @{Bt
    51Testing软件测试网-[ Y-Wc5r7|+\r`Sg
    1.等价类划分
    nz3V6U_154414(1)划分等价类。
    4p%p$aLbvp\154414①如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)。
    lz`h$k7L^154414②如果规定了输入数据的一组值,而且程序对不同的输入值做不同的处理,则每个允许输入值是一个合理等价类,此处还有一个不合理等价类(任何一个不允许的输入值)。51Testing软件测试网i"h2|5|z"V'|+| g}
    ③如果规定了输入数据必须遵循的规则,可确定一个合理等价类(符合规则)和若干个不合理等价类(从各种不同角度违反规则)。
    b%`X(V4a Ms q154414④如果已划分的等价类中各元素在程序中的处理方式不同,则应将此等价类进一步划分为更小的等价类。51Testing软件测试网|5js8^6}
    (2)确定测试用例。
    /U&Ixz_7g"S8}154414①为每一个等价类编号。51Testing软件测试网 aK QI-w5ZcI
    ②设计一个测试用例,使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步,直到所有合理等价类被测试用例覆盖。
    q&IU$znE$P1HZ154414③设计一个测试用例,使其只覆盖一个不合理等价类。51Testing软件测试网LDN s7NLe
    2.边界值分析
    Ck:D S }4C| w%U V7V154414使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表,而是将测试边界情况作为重点目标,选取正好等于、刚刚大于或刚刚小于边界值的测试数据。51Testing软件测试网p'y,_7pr Q+ye
    (1)如果输入条件规定了值的范围,可以选择正好等于边界值的数据作为合理的测试用例,同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1,100],可取0,1,100,101等值作为测试数据。51Testing软件测试网J!iN r*HZep
    (2)如果输入条件指出了输入数据的个数,则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如,一个输入文件可包括1--255个记录,则分别设计有1个记录、255个记录,以及0个记录的输入文件的测试用例。51Testing软件测试网o{6z3Zb0Vz$h
    (3) 对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。如,一个学生成绩管理系统规定,只能查询95--98级大学生的各科成绩,可以设计测试用例,使得查询范围内的某一届或四届学生的学生成绩,还需设计查询94级、99级学生成绩的测试用例(不合理输出等价类)。
    #e*k~kfvp154414由于输出值的边界不与输入值的边界相对应,所以要检查输出值的边界不一定可能,要产生超出输出值之外的结果也不一定能做到,但必要时还需试一试。
    8OO#qJI%IG qkC154414(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等),则应选取集合的第一个元素和最后一个元素作为测试用例。
    @y c?/t"P)A1544143.错误推测51Testing软件测试网 {;c0Rc*o PT
    在测试程序时,人们可能根据经验或直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的测试用例,这就是错误推测法。51Testing软件测试网)e3f:enPcL7o
    4.因果图51Testing软件测试网o.dp4H&y,`z*J
    等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能,而没有考虑多个输入数据的组合引起的错误。51Testing软件测试网WV(rns$S'Z+[Z
    5.综合策略
    K/uu*{-?cT/K154414每种方法都能设计出一组有用例子,用这组例子容易发现某种类型的错误,但可能不易发现另一类型的错误。因此在实际测试中,联合使用各种测试方法,形成综合策略,通常先用黑盒法设计基本的测试用例,再用白盒法补充一些必要的测试用例。51Testing软件测试网q5@2[Ui3XnN

    i%I q wl{.B154414六、测试用例设计的误区51Testing软件测试网!Q;~/i7d PMN4vC0b
    (来源:关河测试网)51Testing软件测试网bT TRA+{jhb0|(I

    'JSP_;`:^i154414·能发现到目前为止没有发现的缺陷的用例是好的用例;51Testing软件测试网;P;W U-IQ$O
    51Testing软件测试网| UP u|a
    首先要申明,其实这句话是十分有道理的,但我发现很多人都曲解了这句话的原意,一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去,忘记了测试的目的所在,这是十分可怕的。我倾向于将测试用例当作一个集合来认识,对它的评价也只能对测试用例的集合来进行,测试本身是一种“V&V”的活动,测试 需要保证以下两点:51Testing软件测试网9J0Ai_hP_

    D Y t*?Z*o W154414程序做了它应该做的事情51Testing软件测试网 {/h/h4[!D J
    程序没有做它不该做的事情51Testing软件测试网J([|v'yF&L
    因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应该针对单个的测试用例去评判好坏。
    }4o+p+~ K(Pg?15441451Testing软件测试网0HO*GZn F9q0x7b
    ·测试用例应该详细记录所有的操作信息,使一个没有接触过系统的人员也能进行测试;
    1{0xv6ZM.R154414
    3jb.Enj \ h154414不知道国内有没有公司真正做到这点,或者说,不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中,对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧,除了自己没人能够执行,写得太详细吧,消耗在测试用例维护(别忘了,测试用例是动态的,一旦测试环境、需求、设计、实现发生了变化,测试用例都需要相应发生变化)上的时间实在是太惊人,在目前国内大部分软件公司的测试资源都不足的情况下,恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人,甚至是测试工程师本身,全然不顾实际的资源情况,一定要写出“没有接触过系统的人员也能进行测试”的用例。
    fL~x!h0O*B154414
    r7mFQ&x8aS154414在讨论这个问题之前,我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷,测试活动本身也可以被看作是一个Project,也需要在给定的资源条件下尽可能达成目标,根据我个人的经验,大部分的国内软件公司在测试方面配备的资源都是不足够的,因此我们必须在测试计划阶段明确测试的目标,一切围绕测试的目标进行。
    (^:N%KT~U'F15441451Testing软件测试网q%J;k_6Nq \q
    除了资源上的约束外,测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻,那测试用例就没有必要太详细了,文档的作用本来就在于沟通,只要能达到沟通的目的就OK。在我担任测试经理的项目中,在测试计划阶段,一般给予测试设计30% - 40%左右的时间,测试设计工程师能够根据项目的需要自行确定用例的详细程度,在测试用例的评审阶段由参与评审的相关人对其把关。
    "xDg(Y2~;F0SN15441451Testing软件测试网.W^\1h:nU-N'z(E(l
    ·测试用例设计是一劳永逸的事情;51Testing软件测试网C#npHLP

    a6|$XPa E154414这句话摆在这里,我想没有一个人会认可,但在实际情况中,却经常能发现这种想法的影子。我曾经参与过一个项目,软件需求和设计已经变更了多次,但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措,间接的后果是测试用例成了废纸一堆,开发人员在多次被无效的缺陷报告打扰 后,对测试人员不屑一顾。51Testing软件测试网W)y-b|o6L
    51Testing软件测试网Yw%NTn$]~5T
    这个例子可能有些极端,但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的,测试用例文档是“活的”文档,这一点应该被测试工程师牢记。51Testing软件测试网)C,f Nb3i7`-A:d
    51Testing软件测试网#j%["v q5O-wXJ"cb
    ·测试用例不应该包含实际的数据;51Testing软件测试网6AR\R&F$DO{
    51Testing软件测试网8t-k ` K{s
    测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出,没有测试数据的用例最多只具有指导性的意义,不具有可执行性。当然,测试用例中包含输入数据会带来维护、与测试环境同步之类的问题,关于这一点,《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法,可以参考。51Testing软件测试网#C7Z[VT6s

    +xT/f?F:[,K m f"A3r^154414·测试用例中不需要明显的验证手段;51Testing软件测试网$J5_!j @'BV^
    51Testing软件测试网de/@7RCq+n;NA
    我见过很多测试工程师编写的测试用例中,“预期输出”仅描述为程序的可见行为,其实,“预期结果”的含义并不只是程序的可见行为。例如,对一个订货系统,输入订货数据,点击“确定”按钮后,系统提示“订货成功”,这样是不是一个完整的用例呢?是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢?显然不是。订货是否成功还需要查看相应的数据记录是否更新,因此,在这样的一个用例中,还应该包含对测试结果的显式的验证手段:在数据库中执行查询语句进行查询,看查询结果是否与预期的一致。51Testing软件测试网$O6I N(qv
    51Testing软件测试网7\4LYv8H(qU
    七、从用例中生成测试用例
    ^v j-vw y15441451Testing软件测试网3~]u-Cw_

    %w.ZiV$]#\p9ks154414用于功能性测试的测试用例来源于测试目标的用例。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定,这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
    s&|/C @l qKH154414
    7l/^0VZ:og154414例如,下图中经过用例的每条不同路径都反映了基本流和备选流,都用箭头来表示。基本流用直黑线来表示,是经过用例的最简单的路径。每个备选流自基本流开始,之后,备选流会在某个特定条件下执行。备选流可能会重新加入基本流中(备选流 1 和 3),还可能起源于另一个备选流(备选流 2),或者终止用例而不再重新加入某个流(备选流 2 和 4)。
    )oG(\3VIm154414
    7a6` [-vo`4`%d_15441451Testing软件测试网%M p4@s^_1C[
    用例的事件流示例51Testing软件测试网 h u L l q(XV

    ;S+f^_6Mr154414遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:51Testing软件测试网:X2Dy cge3}-TQ|
    51Testing软件测试网&G"l:?7_XZ
    场景 1     基本流             51Testing软件测试网*w!|W A1dz
    场景 2     基本流     备选流 1         
    &_O ~fJ|.~ p#@~154414场景 3     基本流     备选流 1     备选流 2     
    H2O v2o*g9~!_:M154414场景 4     基本流     备选流 3         51Testing软件测试网/N Ni(m0ic-Ugn%g0M
    场景 5     基本流     备选流 3     备选流 1     51Testing软件测试网V&^&c6z2@~
    场景 6     基本流     备选流 3     备选流 1     备选流 2
    4A:aNE;C154414场景 7     基本流     备选流 4         51Testing软件测试网O7sf Z?+|&S
    场景 8     基本流     备选流 3     备选流 4
    O5JOM S/NA154414
    !c7F)x5C)My"c J"G154414注:为方便起见,场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。51Testing软件测试网Y5?!@$^Zj*H
    51Testing软件测试网@xV[UWU
    生成每个场景的测试用例是通过确定某个特定条件来完成的,这个特定条件将导致特定用例场景的执行。51Testing软件测试网2Hj:P+_ClH

    F!t1\0gYd0@W FhZ#p154414例如,假定上图描述的用例对备选流 3 规定如下:51Testing软件测试网%Y'IkN8L!q7d*i
    51Testing软件测试网x Y.Q \o!@4Mvp/\i6u
    “如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额,则出现此事件流。系统将显示一则警告消息,之后重新加入基本流,再次执行上述步骤 2‘输入提款金额’,此时银行客户可以输入新的提款金额。”51Testing软件测试网ZO2`Bv)R Z v

    e \`9D x,H154414据此,可以开始确定需要用来执行备选流 3 的测试用例:51Testing软件测试网DG PnqQ5|
    51Testing软件测试网/L8{ I,s5{!U
    测试用例 ID     场景     条件     预期结果
    5_]4HxMP6i a b154414TC x     场景 4     步骤 2 - 提款金额 > 帐户余额     在步骤 2 处重新加入基本流
    P${v w0T{6X'z154414TC y     场景 4     步骤 2 - 提款金额 < 帐户余额     不执行备选流 3,执行基本流51Testing软件测试网M){;@8Jq [V+KG$R
    TC z     场景 4     步骤 2 - 提款金额 = 帐户余额     不执行备选流 3,执行基本流51Testing软件测试网;?E{q"@!^@9W

    SQkzo4{154414注:由于没有提供其他信息,以上显示的测试用例都非常简单。测试用例很少如此简单。
    ;JH5x?TF@:stz7W154414
    3dH x1f#Ou}n1\|"r154414下面是一个由用例生成测试用例的更符合实际情况的示例。
    -n QI/z+}h d15441451Testing软件测试网r;Lgn)vF2n

    H3h/g-c2_b8r154414示例:51Testing软件测试网 I{ H#HJY
    51Testing软件测试网k!QwB!l Iut0i{
    一台 ATM 机器的主角和用例。51Testing软件测试网-`D;u+\ bM
    51Testing软件测试网j8a8y$A9fA'r4ZH6hx3UI
    下表包含了上图中提款用例的基本流和某些备用流:51Testing软件测试网6pg*e x$\8d;S BOe

    6e0_)[mGi154414    本用例的开端是 ATM 处于准备就绪状态。
    J:}8vL'{B-|15441451Testing软件测试网b/ybuO
       1. 准备提款 - 客户将银行卡插入 ATM 机的读卡机。
    ;_9N/IbE(X7k2^8^154414       51Testing软件测试网O O5X&f)m ~W
       2. 验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码,并检查它是否属于可以接收的银行卡。
    3]6Lv"dvvLx.dj154414       
    s#E/xR*W'k154414   3. 输入 PIN - ATM 要求客户输入 PIN 码(4 位)51Testing软件测试网7Wx.@!S"n1r z+c
           
    q3`"w8Or(Q c154414   4. 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流,帐户是有效的而且 PIN 对此帐户来说正确无误。51Testing软件测试网.wW*NNc4MP:d
           51Testing软件测试网oM/}!D9f!HL
       5. ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中,银行客户通常选择“提款”。
    4[ R~7kp.r154414       51Testing软件测试网3gVXm\H
       6. 输入金额 - 要从 ATM 中提取的金额。对于此事件流,客户需选择预设的金额(10 美元、20 美元、50 美元或 100 美元)。51Testing软件测试网K b)wH0N-\R,_ {
           51Testing软件测试网*BC6U5oc[N'CTs$_
       7. 授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流,银行系统处于联机状态,而且对授权请求给予答复,批准完成提款过程,并且据此更新帐户余额。51Testing软件测试网vf0gr AG
           
    %P3Kb#Z-V&S+j O&j154414   8. 出钞 - 提供现金。51Testing软件测试网L!dI4tT z%J yy6Z
           51Testing软件测试网MoJJ&PM$|
       9. 返回银行卡 - 银行卡被返还。
    8`I7["gW;q5i9t154414       
    %{ P/@6O*kUh;[~154414  10. 收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。
    2p9i zLz:C/Tc15441451Testing软件测试网Z3R"coW R'g`%E A*}c
    用例结束时 ATM 又回到准备就绪状态。
    m*| \&JUWZ,X"`H ft154414 51Testing软件测试网$XHo'sF\+dU
    备选流 1 - 银行卡无效     在基本流步骤 2 中 - 验证银行卡,如果卡是无效的,则卡被退回,同时会通知相关消息。
    $yuB0x@,A154414备选流 2 - ATM 内没有现金     在基本流步骤 5 中 - ATM 选项,如果 ATM 内没有现金,则“提款”选项将无法使用。51Testing软件测试网%\:E4G3@&r(E
    备选流 3 - ATM 内现金不足     在基本流步骤 6 中- 输入金额,如果 ATM 机内金额少于请求提取的金额,则将显示一则适当的消息,并且在步骤 6 - 输入金额处重新加入基本流。
    t*l;lpq.w ~154414备选流 4 - PIN 有误     在基本流步骤 4 中- 验证帐户和 PIN,客户有三次机会输入 PIN。
    {5OxC4{ E0}154414
    9O`.[Mzgt,@154414如果 PIN 输入有误,ATM 将显示适当的消息;如果还存在输入机会,则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。
    u7rF3f] i?u7m A154414
    a.F~UkL5v:T154414如果最后一次尝试输入的 PIN 码仍然错误,则该卡将被 ATM 机保留,同时 ATM 返回到准备就绪状态,本用例终止。
    {*\Y y2c,d;G D154414备选流 5 - 帐户不存在     在基本流步骤 4 中 - 验证帐户和 PIN,如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款,则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。51Testing软件测试网0}+Mo~2D
    备选流 6 - 帐面金额不足     在基本流步骤 7 - 授权中,银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的金额,则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。
    ] h x j|k`h@154414备选流 7 - 达到每日最大的提款金额     在基本流步骤 7 - 授权中,银行系统返回的代码表明包括本提款请求在内,客户已经或将超过在 24 小时内允许提取的最多金额,则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。
    )s } R Q*An:Q154414备选流 x - 记录错误     如果在基本流步骤 10 - 收据中,记录无法更新,则 ATM 进入“安全模式”,在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。51Testing软件测试网$w} nSx/s Q~
    备选流 y - 退出     客户可随时决定终止交易(退出)。交易终止,银行卡随之退出。
    8aAV*@"I V:fC154414备选流 z - “翘起”     ATM 包含大量的传感器,用以监控各种功能,如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻,如果某个传感器被激活,则警报信号将发送给警方而且 ATM 进入“安全模式”,在此模式下所有功能都暂停使用,直到采取适当的重启/重新初始化的措施。
    &~MJaad/tN J15441451Testing软件测试网s|3h$_e,bC
    51Testing软件测试网:K4o E!?&K8?Vu
    在第一次迭代中,根据迭代计划,我们需要核实提款用例已经正确地实施。此时尚未实施整个用例,只实施了下面的事件流:51Testing软件测试网^dyG2`9Ns `ZXP

    O L2z0M0Z$x.n154414        * 基本流 - 提取预设金额(10 美元、20 美元、50 美元、100 美元)
    XG{V4jTSfRM)N154414        * 备选流 2 - ATM 内没有现金51Testing软件测试网-g(i"x,h R:fqI
            * 备选流 3 - ATM 内现金不足
    e9I;~y2cb I,x154414        * 备选流 4 - PIN 有误51Testing软件测试网 `e+{Vc;ZA:s
            * 备选流 5 - 帐户不存在/帐户类型有误
    ,`%h u5h7}6Q2O_154414        * 备选流 6 - 帐面金额不足 51Testing软件测试网+F7`7Yj;XkGu:A

    *wL:g8g@154414可以从这个用例生成下列场景
    Y/^"jTG9?6o154414场景 1 - 成功的提款     基本流     
    :D,O8u?*`-V154414场景 2 - ATM 内没有现金     基本流     备选流 251Testing软件测试网 A7JU:dumF'gi
    场景 3 - ATM 内现金不足     基本流     备选流 351Testing软件测试网g~8K&o5v F
    场景 4 - PIN 有误(还有输入机会)     基本流     备选流 4
    )})?n;bU]154414场景 5 - PIN 有误(不再有输入机会)     基本流     备选流 4
    7QI-_ I ~s154414场景 6 - 帐户不存在/帐户类型有误     基本流     备选流 5
    #Se |8l2ab d"zI0bQ154414场景 7 - 帐户余额不足     基本流     备选流 6
    ;n DMKv-z)}.G/z1nz15441451Testing软件测试网w n SDG,q,\
    注:为方便起见,备选流 3 和 6(场景 3 和 7)内的循环以及循环组合未纳入上表。
    'j%s*cLku)F~$M154414
    0P)`-C;V*n0S-e+^154414对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例 ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
    \I/SoCW G1qFLjn154414
    fB%]*`9sM(f5l4Z2DY154414通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流。下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。51Testing软件测试网ldyid9iU
    TC(测试用例)ID 号     场景/条件     PIN51Testing软件测试网*d!R8qBH-k
    51Testing软件测试网#`"U c|!gu)h'y]4K#t
     51Testing软件测试网q'ZNu"f,@(lXR
        帐号51Testing软件测试网-I Ms%T(sa8d

    8`:nv3]5JB5qX154414 
    D&Iq gx;J154414    输入的金额
    C b`Y*T+AG ]154414
    !j8M0] ps0d+d154414(或选择的金额)51Testing软件测试网,]n4m v[/W

    w?)j\tIXe GQ154414 
    .rQ/t ^h154414    帐面金额
    8j%y)l)Uf15441451Testing软件测试网#\F.Y _,TY
     
    g'L!V%k2D9`qC#S154414    ATM 内的金额51Testing软件测试网B[,Q*PK0E-jD Q9r

    ,iA8I5cl154414 51Testing软件测试网aA@B9g|T N1pb
        预期结果51Testing软件测试网RX0toM?+o0r(r
    CW1.     场景 1 - 成功的提款     V     V     V     V     V     成功的提款。51Testing软件测试网ai z-J$ep&i7v.QM8r
    CW2.     场景 2 - ATM 内没有现金     V     V     V     V     I     提款选项不可用,用例结束51Testing软件测试网Ef7ejEr\| h
    CW3.     场景 3 - ATM 内现金不足     V     V     V     V     I     警告消息,返回基本流步骤 6 - 输入金额
    kJx7aUt154414CW4.     场景 4 - PIN 有误(还有不止一次输入机会)     I 51Testing软件测试网,`'}%R`s
    51Testing软件测试网+b-P7E y(c Z2}
     
    $`t] wzm/A7h154414    V     n/a     V     V     警告消息,返回基本流步骤 4,输入 PIN51Testing软件测试网9Tq%C G#dJWD
    CW5.     场景 4 - PIN 有误(还有一次输入机会)     I 51Testing软件测试网#W"H8\:_vq-W0^$q
    51Testing软件测试网(B9nW Q(\O8DR_b.r w
     
    .P7\m9A`'}Y d7G&{154414    V     n/a     V     V     警告消息,返回基本流步骤 4,输入 PIN
    ^%~5k!Cm154414CW6.     场景 4 - PIN 有误(不再有输入机会)     I 51Testing软件测试网 h)x k5| | A

    MG2k.m9C2F+l:b154414 
    I Tf@rhO154414    V     n/a     V     V     警告消息,卡予保留,用例结束51Testing软件测试网 uK@j8{ ~ EK1G?i

    ([S&Cn~:m154414在上面的矩阵中,六个测试用例执行了四个场景。对于基本流,上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行,未发生任何偏差。基本流的全面测试必须包括负面测试用例,以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示(阴影单元格表明这种条件下需要执行备选流)。虽然 CW2 至 6 对于基本流而言都是负面测试用例,但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言,至少存在一个负面测试用例(CW1 - 基本流)。  
    g ^&h9Z uO/|4L"`.g1MV154414
    7A/FE_7M154414每个场景只具有一个正面测试用例和负面测试用例是不充分的,场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误,至少需要三个正面测试用例(以激活场景 4):51Testing软件测试网(nZ.S!L4kU CS~&I

    Z%O;fC|[154414    * 输入了错误的 PIN,但仍存在输入机会,此备选流重新加入基本流中的步骤 3 - 输入 PIN。51Testing软件测试网2nm8pW%vg
        * 输入了错误的 PIN,而且不再有输入机会,则此备选流将保留银行卡并终止用例。
    _5?[1} C`_9e1M154414    * 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。
    J@#G#O}D]15441451Testing软件测试网 S;MeEt z$p K
    注:在上面的矩阵中,无需为条件(数据)输入任何实际的值。以这种方式
    创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I(或此处采用的阴影单元格),这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格,这表明测试用例还不完全,如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。
    F)C5\2S_ W154414
    8w+R#`[sq dUo h154414一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。51Testing软件测试网!Rc;Vn%U`5b8Gt?1v _

    ny~ U:?154414测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据51Testing软件测试网9RZU f ]H U/g
    TC(测试用例)ID 号     场景/条件     PIN51Testing软件测试网(IC2I'zL'a'a l

    8` J G,t'k"P O-D} d$m154414 51Testing软件测试网v'dN&p*rd
        帐号
    ngN1V7Fi f154414
    _M.G%F|ID154414 
    5e$qL-}D&W.oGm{154414    输入的金额
    +cS$Q5zEj154414
    l%Gk&P'`!v]w154414(或选择的金额)51Testing软件测试网Sow^M!d9}

    vh'BrWL154414 
    6d`M]I154414    帐面金额51Testing软件测试网;FM$C2l sn
    51Testing软件测试网"V6OE2tz
     
    4R9n0~)^ @&L\154414    ATM 内的金额51Testing软件测试网 B8Y ]U9{vRu

    KYUl4}mR154414 51Testing软件测试网`5yq;^1w4^&F'\f
        预期结果
    e} Y-J@ \3g'X154414CW1.     场景 1 - 成功的提款     4987     809 - 498     50.00     500.00     2,000     成功的提款。帐户余额被更新为 450.00
    :yb-d Z7k S-IYpi"w#j154414CW2.     场景 2 - ATM 内没有现金     4987     809 - 498     100.00     500.00     0.00     提款选项不可用,用例结束
    "E,rA1z%kB? f;@,Y154414CW3.     场景 3 - ATM 内现金不足     4987     809 - 498     100.00     500.00     70.00     警告消息,返回基本流步骤 6 - 输入金额51Testing软件测试网CS zY,P
    CW4.     场景 4 - PIN 有误(还有不止一次输入机会)     4978 51Testing软件测试网 Rcj0t-L}F.`

    #\'Ik7Y)DkzG$g154414 51Testing软件测试网yTCf[eV bv5N
        809 - 498     n/a     500.00     2,000     警告消息,返回基本流步骤 4,输入 PIN
    3L @,Q)M O d154414CW5.     场景 4 - PIN 有误(还有一次输入机会)     497851Testing软件测试网OH&FB(hv

    ,D)Ws"q@u154414 
    S m5O _!~ l*pGh-g154414    809 - 498     n/a     500.00     2,000     警告消息,返回基本流步骤 4,输入 PIN
    }9QZ3MT154414CW6.     场景 4 - PIN 有误(不再有输入机会)     4978
    N"W0X7XC)Jv15441451Testing软件测试网i,x*m!C3P1B
     
    /PI+\U m.Z(lV154414    809 - 498     n/a     500.00     2,000     警告消息,卡予保留,用例结束51Testing软件测试网tu&X(CY
    51Testing软件测试网6g1yuG5lrMy!_
    以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括:51Testing软件测试网^~0_m9Wl` CH

    ;UOY/L+NH1L154414    * 场景 6 - 帐户不存在/帐户类型有误:未找到帐户或帐户不可用
    ]h {1`1P!T154414    * 场景 6 - 帐户不存在/帐户类型有误:禁止从该帐户中提款51Testing软件测试网"P#H2X2ww7V/{S
        * 场景 7 - 帐户余额不足:请求的金额超出帐面金额
    f#b$F]TzA K \-s154414
    %{QJ)N8WmI154414在将来的迭代中,当实施其他事件流时,在下列情况下将需要测试用例:
    8[.Qz9|:\ |v J;u154414
    [%e/N,m%sQ154414    * 无效卡(所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等)
    *D NGY`xG-sQ154414    * 无法读卡(读卡机堵塞、脱机或出现故障)
    -Q2N}'aC.H R5l154414    * 帐户已消户、冻结或由于其他方面原因而无法使用51Testing软件测试网%~%}g;B/WweDTt
        * ATM 内的现金不足或不能提供所请求的金额(与 CW3 不同,在 CW3 中只是一种币值不足,而不是所有币值都不足)51Testing软件测试网v0g*fuT:@&b
        * 无法联系银行系统以获得认可
    bKr`~&x;RG154414    * 银行网络离线或交易过程中断电
    :DEIb d15441451Testing软件测试网C,G/j\ Ed
    在确定功能性测试用例时,确保满足下列条件:51Testing软件测试网 _4jS.k ]yc

    hz]w3l'Z@0QH0B8e154414    * 已经为每个用例场景确定了充足的正面和负面测试用例。
    AL9\_:C'K-n;r]154414    * 测试用例可以处理用例所实施的所有业务规则,确保对于业务规则,无论是在内部、外部还是在边界条件/值上都存在测试用例。
    $vUM~-P/v154414    * 测试用例可以处理所有事件或动作排序(如在设计模型的序列图中确定的内容),还应能处理用户界面对象状态或条件。51Testing软件测试网,j6KU3P:o0SEZ
        * 测试用例可以处理为用例所指定的任何特殊需求,如最佳/最差性能,有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。 51Testing软件测试网gc8x L*| TfU6O
    51Testing软件测试网Z4Y+SZ1Z? E
    八、从补充规约中生成测试用例
    AjrkN$XBK o154414
    PY#[Cy8rJl r154414并不是所有的测试目标需求都将在用例中有所反映。非功能性需求(如性能、安全性和访问控制)以及配置要求等将会说明测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。51Testing软件测试网&B uT!YUF
    51Testing软件测试网 C`&k#f'{QbcG-a'~m
    关于如何生成这些其他测试用例的指南说明如下:
    %c9x1Yt#lyo15441451Testing软件测试网`lo,i2@;CY
        * 为
    性能测试生成测试用例
    };b$OE%exf154414    * 为安全性/访问控制测试生成测试用例51Testing软件测试网r3j&|E0aW7E
        * 为配置测试生成测试用例51Testing软件测试网0Y/X-o.A:H:dAF'h
        * 为安装测试生成测试用例
    T~vk)x(w"?$Y%h154414    * 为其他非功能性测试生成测试用例
    {w[0? o[15441451Testing软件测试网_5g&o!T9z0R7a
    为性能测试生成测试用例51Testing软件测试网SF)k,e4`7kR
    51Testing软件测试网.[({Yj+S Z&Wb)FR1N*D%^
    性能测试用例的主要输入是补充规约,补充规约中包含了非功能性需求(请参见工件:补充规约)。为性能测试生成测试用例时,请使用下列指南:
    F1xT5EZq`154414
    .M.kV7Y1ZE2N*ww O154414    * 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。
    0X6a;l!~.d2C@154414    * 对每个关键用例,都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例(请参见工件:工作量分析文档)。 51Testing软件测试网9V}m#R#@zb-a
    51Testing软件测试网vIR2?$t$ZR
    与功能性测试的测试用例类似,通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是:存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例,还有一个测试用例高于阈值。51Testing软件测试网c/pun&@yMkQ$x@
    51Testing软件测试网.]|H\%t'p+l
    除了以上性能标准以外,确保已确定影响响应时间的特定条件,包括:
    U8T7n$h'h154414
    -rz%[F u A'z;LY#k154414    * 数据库的大小 - 存在多少个记录?51Testing软件测试网X8DZfk V {
        * 工作量 - 同时执行操作的最终用户的数量和类型,以及要同时执行的事务的数量和类型51Testing软件测试网u6l zz C-~i
        * 环境特征(硬件、网件以及软件配置) 51Testing软件测试网I8N f5nW4n3T)};q Ut
    51Testing软件测试网\)IRN:{
    将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。
    z d NI!M!m}0qR15441451Testing软件测试网3I,H}h+Y*J1a:c
    以下是各种性能测试的一些示例:51Testing软件测试网n)nXq3\$_!g1{
    51Testing软件测试网A Y:a*f8b~_E
    对于
    负载测试51Testing软件测试网'e1G!|c9fOk/}
    TC(测试用例)ID 号     工作量     条件51Testing软件测试网P+lf.r s

    F6k0J/v ?i154414 
    $be G]*z.o1M'Tv"_154414    预期结果51Testing软件测试网 AP'[ u,f4rgm
    PCW1.     51Testing软件测试网7x;N4qh_9Fs jP
    51Testing软件测试网a FhEq] J
    151Testing软件测试网0AF Y]:^.G8x

    \!Mo/r@by+l154414(单个 ATM)51Testing软件测试网1| r O H} F } Y;V w)iA]
       
    7ae Y}~M15441451Testing软件测试网1O-MF,F%?,r
    完成提款交易51Testing软件测试网.K(D-L9m(|:o!CG:Uz
        全部交易(不依赖于主角的时间)在 20 秒之内完成51Testing软件测试网wz-sS'v#Ih;y&n
    PCW2.     51Testing软件测试网`B)]j!RK B

    jW)L b)TQ$XT1544142
    ;A1DvC3c y[154414
    8F;T+w!k x r:R y;{154414(1,000 个同时运行的 ATM)51Testing软件测试网G PcH(@'txI:y
       
    *r8|uC"S'f"\ X15441451Testing软件测试网HWw i]3oY
    完成提款交易
    9Q IS*@;J7ec154414    全部交易(不依赖于主角的时间)在 30 秒之内完成51Testing软件测试网jA-B B'I.E8L[
    PCW3.     51Testing软件测试网rj,AUotk5KZ

    (c,@8JMt~3A r1544143
    M8y3bTT`+S15441451Testing软件测试网5d(f$qQ2?{GD
    (10.000 个同时运行的 ATM)
    8@C y| a$F s-hRV-n154414    51Testing软件测试网O!o Uc H x

    n[yR5o3k'n{*T3R{154414完成提款交易
    %p5]4^Os'b G154414    全部交易(不依赖于主角的时间)在 50 秒之内完成
    ;xZKe!s&zh154414
    {9hg4E!P154414对于强度测试:
    (~ z8Ncxa154414TC(测试用例)ID 号     工作量     条件51Testing软件测试网hHz2O k-n7ZI
    51Testing软件测试网f d%@"e(c:@O c2l/C
     
    gzl0DXB7oU e154414    预期结果
    Cbf0V7X/n154414SCW1.    
    uJ@#[H.fw/?8x154414
    "w;Br1hk*gz f#F154414251Testing软件测试网#V-C:k:Dr4u2kZNr"W
    51Testing软件测试网4q\A2c@ x
    (1,000 个同时运行的 ATM)51Testing软件测试网"kYmHS-e1o%w[s
        51Testing软件测试网9HCF7gSi:u%^Y

    Z#kU2[tJ154414数据库锁定 - 2 个 ATM 请求同一帐户
    ,q DwN@ ZiL#`154414    ATM 请求排成队列
    .R mv,l8bQ@154414SCW2.    
    8|R8R jU4mFRk15441451Testing软件测试网V9H(zq+o OU
    2
    I
  • web测试经典总结(转)

    2008-12-01 10:37:58

     网络转载  作者不详
    "q]%k4@t KM154414  基于Web的系统测试在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

      在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。 一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。

      Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

      一、 功能测试
    Ogl5d ~9qY154414  1、链接测试 链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。 链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

      2、表单测试 当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

      3、Cookies测试 Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

      4、设计语言测试 Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

      5、数据库测试 在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。 在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

      二、 性能测试

      1、连接速度测试

      用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。 另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

      2、负载测试

      负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

      3、压力测试

      负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。 进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。

      三、 可用性测试

      1、导航测试 导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助? 在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。 导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。 Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。 
    \3uxtY$Qfxj3L154414
    /z5jj$W;W-~154414    2、图形测试 在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。

      图形测试的内容有:
    ?Z`c)f9qv;I154414  (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。 51Testing软件测试网#E,FEh U'LB
      (2)验证所有页面字体的风格是否一致。 51Testing软件测试网"LVS^LXLu^
      (3)背景颜色应该与字体颜色和前景颜色相搭配。
    oW$?4lh7w154414  (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。

      3、内容测试

      内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。

      4、整体界面测试

      整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致? 对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。 对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

      四、 客户端兼容性测试

      1、平台测试

      市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。 因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

      2、浏览器测试

      浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

      五、 安全性测试

      Web应用系统的安全性测试区域主要有:

      (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

      (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

      (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

      (4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

      (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

      六、总结

      本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测

  • web易漏测地方

    2008-12-01 10:33:01

    1.浏览器的后退按钮 

      提交表单一条已经成功提交的记录,back后再提交,看系统会如何处理。检查多次使用back健的情况在有back的地方,back,回到原来的页面,再back,重复几次,看是否会报错。

      2.通过修改URL中的参数,向服务器发起请求,看看会有什么样的结果

      利用一些工具,如http watch,可以记录和捕获向服务器发起的URL请求,然后修改其中的参数向服务器发起请求.该功能点可以和安全测试结合起来.

      3.对表单多次提交

      对提交按钮快速多次点击提交,看看会不会在数据库中形成多条记录.网速或响应快时,这点容易被遗漏,但用户的网络可能慢,很容易多次点击提交.如果前端做了处理,试试捕获在提交时生成的URL,绕过页面,再次对服务器发起请求,会有什么结果

      4.光标的跳转

      执行操作后,光标是否停留在合适的位置.如邮箱登录,输完用户名回车后,光标应该跳转到密码框内.细节问题,但是影响用户感受

      5.tab键是否功能正确

      和光标的跳转类似,特别是在有输入项时,查看tab键的焦点顺序是否正确

      6.对全角/半角符号的输入测试

      有输入项时,要考虑全/半角字条的输入,及GBK字符

  • 测试用例设计白皮书--判定表驱动分析方法(转)

    2008-11-27 10:34:41

    一.方法简介

    1.定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

    2.判定表的优点
            能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。
            在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

    3.“阅读指南”判定表

      

     


    1
    2
    3
    4
    5
    6
    7
    8
    问题
    觉得疲倦?
    Y
    Y
    Y
    Y
    N
    N
    N
    N
    感兴趣吗?
    Y
    Y
    N
    N
    Y
    Y
    N
    N
    糊涂吗?
    Y
    N
    Y
    N
    Y
    N
    Y
    N
    建议
    重读








    继续








    跳下一章








    休息









     

    4.判定表通常由四个部分组成如下图所示。

       

    1

            1)条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
            2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
            3)条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
            4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

    5.规则及规则合并
            1)规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
            2)化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。

  • 测试用例设计白皮书--正交实验设计方法(转)

    2008-11-27 10:33:22

     一、方法简介

      利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

      正交实验设计方法:依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法。类似的方法有:聚类分析方法,因子方法方法等。

      利用正交实验设计测试用例的步骤:

      1.提取功能说明,构造因子--状态表

      把影响实验指标的条件称为因子。而影响实验因子的条件叫因子的状态。利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态。对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求。这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据。确定因子与状态是设计测试用例的关键。因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

      2.加权筛选,生成因素分析表

      对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。

      3.利用正交表构造测试数据集

      正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。

      利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

      二、 实战演习

      暂无

  • 测试用例设计白皮书--功能图分析方法(转)

    2008-11-27 10:32:20

    一、方法简介

      一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的。必须用动态说明来补充功能说明。功能图方法是用功能图FD 形式化地表示程序的功能说明,并机械地生成功能图的测试用例。 功能图模型由状态迁移图和逻辑功能模型构成。状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态。逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。功能图方法其实是是一种黑盒白盒混合用例设计方法。

      (功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中的内容。逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法。该方法要求测试人员对程序的逻辑结构有清楚的了解。由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖。下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的。)

      1、功能图

      功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变。同时要依靠判定表或因果图表示的逻辑功能。例,一个简化的自动出纳机ATM的功能图。

      2、测试用例生成方法

      从功能图生成测试用例,得到的测试用例数是可接受的。 问题的关键的是如何从状态迁移图中选取测试用例。 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题(如白盒测试)问题了。

      3、测试用例生成规则

      为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则。在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复。但分辨一个状态迁移中的所有循环是有困难的。(其表示图形省略)。

      4、从功能图生成测试用例的过程

      1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例。局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。

      2)测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。

      3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例。结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

      5、测试用例的合成算法:采用条件构造树。

      二、实战演习

      暂无

  • 测试用例设计白皮书--边界值分析方法(转)

    2008-11-27 10:31:04

    一.方法简介

      1. 定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

      2. 与等价划分的区别

      1) 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。

      2) 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

      3. 边界值分析方法的考虑:

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

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

      4. 常见的边界值

      1) 对16-bit 的整数而言 32767 和 -32768 是边界

      2) 屏幕上光标在最左上、最右下位置

      3) 报表的第一行和最后一行

      4) 数组元素的第一个和最后一个

      5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

      5. 边界值分析

      1) 边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。

      例:测试计算平方根的函数

      --输入:实数

      --输出:实数

      --规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息"平方根非法-输入值小于0"并返回0;库函数Print-Line可以用来输出错误信息。

      2) 等价类划分:

      I.可以考虑作出如下划分:

      a、输入 (i)<0 和 (ii)>=0

      b、输出 (a)>=0 和 (b) Error

      II.测试用例有两个:

      a、输入4,输出2。对应于 (ii) 和 (a) 。

      b、输入-10,输出0和错误提示。对应于 (i) 和 (b) 。

      3) 边界值分析:

      划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0。由此得到以下测试用例:

      a、输入 {最小负实数}

      b、输入 {绝对值很小的负数}

      c、输入 0

      d、输入 {绝对值很小的正数}

      e、输入 {最大正实数}

      4) 通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

      5) 相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。

      6) 利用边界值作为测试数据

    边界值

    测试用例的设计思路

    字符

    起始-1个字符/结束+1个字符

    假设一个文本输入区域允许输入1个到255个 字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值。

    数值

    最小值-1/最大值+1

    假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、99999作为最大值;然后使用刚好小于5位和大于5位的 数值来作为边界条件。

    空间

    小于空余空间一点/大于满空间一点

    例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件。

    7) 内部边界值分析:

      在多数情况下,边界值条件是基于应用程序的功能设计而需要考虑的因素,可以从软件的规格说明或常识中得到,也是最终用户可以很容易发现问题的。然而,在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。

      内部边界值条件主要有下面几种:

      a) 数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。

    范围或值

    位(bit)

    0 或 1

    字节(byte)

    0 ~ 255

    字(word)

    0~65535(单字)或 0~4294967295(双字)

    千(K)

    1024

    兆(M)

    1048576

    吉(G)

    1073741824

       b) 字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

    字符

    ASCII码值

    字符

    ASCII码值

    空 (null)

    0

    A

    65

    空格 (space)

    32

    a

    97

    斜杠 ( / )

    47

    Z

    90

    0

    48

    z

    122

    冒号 ( : )

    58

    单引号 ( ‘ )

    96

    @

    64

     

     

      c) 其它边界值检验

      6. 基于边界值分析方法选择测试用例的原则

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

      例如,如果程序的规格说明中规定:"重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……"。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。

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

    比如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。

      3) 将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。

      例如,某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元",其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。

      再如一程序属于情报检索系统,要求每次"最少显示1条、最多显示4条情报摘要",这时我们应考虑的测试用例包括1和4,还应包括0和5等。

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

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

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

      .实战演习

      1.现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

     ① 标题:这一组只有一个记录,其内容为输出成绩报告的名字。

      ② 试卷各题标准答案记录:每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。

      ③ 每个学生的答卷描述:该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。

      ④ 学生人数不超过200,试题数不超过999。

      ⑤ 程序的输出有4个报告:

      a) 按学号排列的成绩单,列出每个学生的成绩、名次。

      b) 按学生成绩排序的成绩单。

      c) 平均分数及标准偏差的报告。

      d) 试题分析报告。按试题号排序,列出各题学生答对的百分比。

      解答:分别考虑输入条件和输出条件,以及边界条件。给出下表所示的输入条件及相应的测试用例。

      输出条件及相应的测试用例表。

      2.三角形问题的边界值分析测试用例

      在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100] 。

      

    测试用例

    a

    b

    c

    预期输出

    Test1

    Test2

    Test3

    Test4

    Test5

    60

    60

    60

    50

    50

    60

    60

    60

    50

    50

    1

    2

    60

    99

    100

    等腰三角形

    等腰三角形

    等边三角形

    等腰三角形

    非三角形

    Test6

    Test7

    Test8

    Test9

    60

    60

    50

    50

    1

    2

    99

    100

    60

    60

    50

    50

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

    Test10

    Test11

    Test12

    Test13

    1

    2

    99

    100

    60

    60

    50

    50

    60

    60

    50

    50

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

      3.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]

     




  • 测试用例设计白皮书--等价类划分方法(转)

    2008-11-27 10:27:44

    一.方法简介

      1.定义

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

      2.划分等价类:

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

      1)有效等价类

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

      2)无效等价类

      与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

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

      3.划分等价类的标准:

      1)完备测试、避免冗余;

      2)划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;

      3)并是整个集合:完备性;

      4)子集互不相交:保证一种形式的无冗余性;

      5)同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到"相同的执行路径"。

      4.划分等价类的方法

      1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100;

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

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

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

      例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。

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

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

      5.设计测试用例

      在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:

      1)为每一个等价类规定一个唯一的编号;

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

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

    二.实战演习

      1.某程序规定:"输入三个整数 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)

      覆盖无效等价类的测试用例:


    2.设有一个档案管理系统,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。

      1)划分等价类并编号,下表等价类划分的结果

    输入等价类

    有效等价类

    无效等价类

      日期的类型及长度

      ①6位数字字符

    ②有非数字字符

    ③少于6位数字字符

    ④多于6位数字字符

     年份范围

      ⑤在1990~2049之间

    ⑥小于1990
    ⑦大于2049

     月份范围

      ⑧在01~12之间

    ⑨等于00

    ⑩大于12

      2)设计测试用例,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计的测试用例如下:

      测试数据 期望结果 覆盖的有效等价类

    200211 输入有效 ①、⑤、⑧

      3)为每一个无效等价类设计一个测试用例,设计结果如下:

      测试数据 期望结果 覆盖的无效等价类

    95June 无效输入 ②

    20036 无效输入③

    2001006无效输入 ④

    198912 无效输入 ⑥

    200401 无效输入 ⑦

    200100 无效输入 ⑨

    200113 无效输入 ⑩

      3.NextDate 函数包含三个变量:month 、 day 和 year ,函数的输出为输入日期后一天的日期。 例如,输入为 2006年3月 7日,则函数的输出为 2006年3月8日 。要求输入变量 month 、 day 和 year 均为整数值,并且满足下列条件:

    ①1≤month≤12

    ②1≤day≤31

    ③1920≤year≤2050

      1)有效等价类为:

      

    M1={月份:1≤月份≤12}

    D1={日期:1≤日期≤31}

    Y1={年:1812≤年≤2012}

      2)若条件 ① ~ ③中任何一个条件失效,则 NextDate 函数都会产生一个输出,指明相应的变量超出取值范围,比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合, NextDate 函数将这些组合作统一的输出: " 无效输入日期 " 。其无效等价类为:

    M2={月份:月份<1}

    M3={月份:月份>12}

    D2={日期:日期<1}

    D3={日期:日期>31}

    Y2={年:年<1812}

    Y3={年:年>2012}

    弱一般等价类测试用例

    月份 日期 年 预期输出

    6 15 1912 1912年6月16日

      强一般等价类测试用例同弱一般等价类测试用例

      注:弱--有单缺陷假设;健壮--考虑了无效值

      (一)弱健壮等价类测

      

    用例ID 月份 日期 年 预期输出

    WR1 6 15 1912 1912年6月16日

    WR2 -1 15 1912 月份不在1~12中

    WR3 13 15 1912 月份不在1~12中

    WR4 6 -1 1912 日期不在1~31中

    WR5 6 32 1912 日期不在1~31中

    WR6 6 15 1811 年份不在1812~2012中

    WR7 6 15 2013 年份不在1812~2012中

      (二)强健壮等价类测试

      

    用例ID 月份 日期 年 预期输出

    SR1 -1 15 1912 月份不在1~12中

    SR2 6 -1 1912 日期不在1~31中

    SR3 6 15 1811 年份不在1812~2012中

    SR4 -1 -11912 两个无效一个有效

    SR5 6 -1 1811 两个无效一个有效

    SR6 -1 15 1811 两个无效一个有效

    SR7 -1 -11811 三个无效

      4.佣金问题等价类测试用例,它是根据佣金函数的输出值域定义等价类,来改进测试用例集合。

    输出销售额≤1000元 佣金10%

      1000<销售额≤1800 佣金=100+(销售额-1000)*15%

      销售额>1800 佣金=220+(销售额-1800)*20%

      测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金

      
    1 5 5 5 500 50

    2 15 15 15 1500 175

    3 25 25 25 2500 360

      根据输出域选择输入值,使落在输出域等价类内,可以结合弱健壮测试用例结合。


  • 测试用例设计白皮书--错误推测方法(转)

    2008-11-27 10:24:46

    一. 方法简介

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

      2. 错误推测方法的基本思想:

      列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

      1) 例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

      2) 例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:

      I.程序是否把空格作为回答

      II. 在回答记录中混有标准答案记录

      III.除了标题记录外,还有一些的记录最后一个字符即不是2也不是3

      IV.有两个学生的学号相同

      V. 试题数是负数。

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

      I.输入的线性表为空表;

      II. 表中只含有一个元素;

      III.输入表中所有元素已排好序;

      IV.输入表已按逆序排好;

      V. 输入表中部分或全部元素相同。

      二. 实战演习

       暂无

  • 测试用例设计白皮书--因果图方法(转)

    2008-11-27 10:23:45

    一. 方法简介

      1.定义:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

      2.因果图法产生的背景:

      等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

      如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

      3.因果图介绍

      1) 4种符号分别表示了规格说明中向4种因果关系。

      2) 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。

      3) Ci表示原因,通常置于图的左部;ei表示结果,通常在图的右部。Ci和ei均可取值0或1,0表示某状态不出现,1表示某状态出现。

      4. 因果图概念

      1) 关系

      ① 恒等:若ci是1,则ei也是1;否则ei为0。

      ② 非:若ci是1,则ei是0;否则ei是1。

      ③ 或:若c1或c2或c3是1,则ei是1;否则ei为0。“或”可有任意个输入。

      ④ 与:若c1和c2都是1,则ei为1;否则ei为0。“与”也可有任意个输入。

       2) 约束

      输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

      A.输入条件的约束有以下4类:

      ① E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。

      ② I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。

      ③ O约束(唯一);a和b必须有一个,且仅有1个为1。

      ④ R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。

      B.输出条件约束类型

      输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。

      5. 采用因果图法设计测试用例的步骤:

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

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

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

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

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

    二. 实战演习

      1. 某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息。

      解答:

      1) 根据题意,原因和结果如下:

      原因:

      1——第一列字符是A;

      2——第一列字符是B;

      3——第二列字符是一数字。

      结果:

      21——修改文件;

      22 ——给出信息L;

      23——给出信息M。

      2) 其对应的因果图如下:

      11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。

      3) 根据因果图建立判定表。

      表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。

      2. 有一个处理单价为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) 转换成判定表:

      4) 在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。

  • 测试用例设计白皮书--测试用例设计综合策略(转)

    2008-11-27 10:22:06

    1. Myers提出了使用各种测试方法的综合策略:

      1) 在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。

      2) 必要时用等价类划分方法补充一些测试用例。

      3) 用错误推测法再追加一些测试用例。

      4) 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。

      5) 如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

      2.测试用例的设计步骤

      1) 构造根据设计规格得出的基本功能测试用例;

      2) 边界值测试用例;

      3) 状态转换测试用例;

      4) 错误猜测测试用例;

      5) 异常测试用例;

      6) 性能测试用例;

      7) 压力测试用例。

      3.优化测试用例的方法

      1) 利用设计测试用例的8种方法不断的对测试用例进行分解与合并;

      2) 采用遗传算法理论进化测试用例;

      3) 在测试时利用发散思维构造测试用例

  • 测试用例设计白皮书--场景设计方法(转)

    2008-11-27 10:21:13

    一.方法简介

      现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

      基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。

      二.实战演习

      1. 例子描述

      下图所示是ATM例子的流程示意图。

      2.场景设计:下表所示是生成的场景。

    表3-8 场景设计

    场景1——成功提款

    基本流

     

    场景2——ATM内没有现金

    基本流

    备选流2

    场景3——ATM内现金不足

    基本流

    备选流3

    场景4——PIN有误(还有输入机会)

    基本流

    备选流4

    场景5——PIN有误(不再有输入机会)

    基本流

    备选流4

    场景6——账户不存在/账户类型有误

    基本流

    备选流5

    场景7——账户余额不足

    基本流

    备选流6

      注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。

    3.用例设计

      对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。

    表3-9 测试用例表

    TC(测试用例)ID号

    场景/条件

    PIN

    账号

    输入(或选择)的金额

    账面金额

    ATM内的金额

    预期结果

    CW1

    场景1:成功提款

    V

    V

    V

    V

    V

    成功提款

    CW2

    场景2:ATM内没有现金

    V

    V

    V

    V

    I

    提款选项不可用,用例结束

    CW3

    场景3:ATM内现金不足

    V

    V

    V

    V

    I

    警告消息,返回基本流步骤6,输入金额

    CW4

    场景4:PIN有误(还有不止一次输入机会)

    I

    V

    n/a

    V

    V

    警告消息,返回基本流步骤 4,输入 PIN

    CW5

    场景4:PIN有误(还有一次输入机会)

    I

    V

    n/a

    V

    V

    警告消息,返回基本流步骤 4,输入 PIN

    CW6

    场景4:PIN有误(不再有输入机会)

    I

    V

    n/a

    V

    V

    警告消息,卡予保留,用例结束

      4.数据设计

      一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

      测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。

      表3-10 测试用例表

    TC(测试用例)ID号

    场景/条件

    PIN

    账号

    输入(或选择)的金额(元)

    账面
    金额(元)

    ATM内的金额(元)

    预期结果

    CW1

    场景1:成功提款

    4987

    809-498

    50.00

    500.0

    2 000

    成功提款。账户余额被更新为450.00

    CW2

    场景2:ATM内没有现金

    4987

    809-498

    100.00

    500.0

    0.00

    提款选项不可用,用例结束

    CW3

    场景3:ATM内现金不足

    4987

    809-498

    100.00

    500.0

    70.00

    警告消息,返回基本流步骤6,输入金额

    CW4

    场景4:PIN有误(还有不止一次输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,返回基本流步骤4,输入PIN

    CW5

    场景4:PIN有误(还有一次输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,返回基本流步骤4,输入PIN

    CW6

    场景4:PIN有误(不再有输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,卡予保留,用例结束

     

  • 软件测试用例的设计

    2008-11-10 10:39:59

    是否每个测试用例(或每组相关的测试用例)都确定了初始的测试目标状态和测试数据状态?

    测试用例是否包含了所有单一的边界?

    测试用例是否包含了所有的业务数据流?

    是否所有的测试用例名称,ID都与测试工件命名约定一致?

    测试用例评审时需要参加的人员:项目经理,系统分析员,测试设计员,测试员

    3.2 用例库的更新维护

    随着软件项目的开发,用例库的数据随着项目的进展动态变化也是需要维护的,主要包括:不合适用例的修改、冗余用例的删除、测试用例的增加,并对进行的操作在备注中署名修改者以及修改时间和改动原因。

    4 测试用例实例

    该测试案例是以一个B/S结构的登录功能点位被测对象, 该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。

    功能描述如下:

    1. 用户在地址栏输入相应地址,要求显示登录界面;

    2. 输入用户名和密码,登录,系统自动校验,并给出相应提示信息;

    3. 如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息;

    4. 连续3次未通过验证时,自动关闭IE。

    表4-1 登录界面测试用例

    用例ID

    XXXX-XX-XX

    用例名称

    系统登录

    用例描述

    系统登录

    用户名存在、密码正确的情况下,进入系统

    页面信息包含:页面背景显示

    用户名和密码录入接口,输入数据后的登入系统接口

    用例入口

    打开IE,在地址栏输入相应地址

    进入该系统登录页面

     

    测试用例ID

    场景

    测试步骤

    预期结果

    备注

    TC1

    初始页面显示

    从用例入口处进入

    页面元素完整,显示与详细设计一致

     

    TC2

    用户名录入-验证

    输入已存在的用户:test

    输入成功

     

    TC3

    用户名-容错性验证

    输入:aaaaabbbbbcccccdddddeeeee

    输入到蓝色显示的字符时,系统拒绝输入

    输入数据超过规定长度范围

    TC4

    密码-密码录入

    输入与用户名相关联的数据:test

    输入成功

     

    TC5

    系统登录-成功

    TC2TC4,单击登录按钮

    登录系统成功

     

    TC6

    系统登录-用户名、密码校验

    没有输入用户名、密码,单击登录按钮

    系统登录失败,并提示:请检查用户名和密码的输入是否正确

     

    TC7

    系统登录-密码校验

    输入用户名,没有输入密码,单击登录按钮

    系统登录失败,并提示:需要输入密码

     

    TC8

    系统登录-密码有效性校验

    输入用户名,输入密码与用户名不一致,单击登录按钮

    系统登录失败,并提示:错误的密码

     

    TC9

    系统登录-输入有效性校验

    输入不存在的用户名、密码,单击登录按钮

    系统登录失败,并提示:用户名不存在

     

    TC10

    系统登录—安全校验

    连续3次未成功

    系统提示:您没有使用该系统的权限,请与管理员联系!

     

     

  • 编写测试用例方法心得体会 (转)

    2008-11-10 10:05:16

    一旦需求变更,也需要修改,这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗,别人看不懂,不能执行,那你要花费你的时间去解释,这就加大了测试的工作量。这也不是好的方法。

      第二个问题,刚开始做测试的时候,你是怎么学习写测试用例的?

      我之所以选择测试这个工作是因为:我毕业后,在第一家公司做技术支持,产品的问题很多,导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的,我选择了做测试,到了现在的公司。我刚做测试的时候,对测试一无所知,什么测试流程阿、文档阿都不知道,公司的测试和管理也不规范。对测试,大家都认为不就是拿个鼠标点来点去,谁都可以来做。为此,我经常上网查测试的资料,看看自己到底适合不适合做测试,测试到底是什么样的一个职业,怎么去规划自己的个人发展。其实要做好测试,真是不容易。不喜欢,真是不能做这个职业。

      现在想想自己刚开始写测试用例的时候,真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板,综合了几个,就形成了。我之所以不用公司原有的测试用例模板,是因为太不适用了。还好,公司没有严格要求必须要那个模板,只要适用就行。模板找好了,可是写就费劲了。对于刚做测试的新人,看似简单的一个填表工作,要写好真是不简单。一开始写的比较不自然,有些生搬硬套,而且还很慢。没有办法,那时候没有人指导我,全靠自己自学和领悟,所以那段日子很苦阿!多写几次后,就知道和领悟了,测试用例要根据测试大纲来写,测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向,而测试用例是指导怎么去执行测试。还好,我有编程的经验,所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例,才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多,不知道这样的回答是否是回答了这个问题。

      最后一个问题了,我尽量少写些,文字太多了大家看的也累,我写的也累。嘿嘿。^_^

      你对黑盒测试用例的编写的体会是什么?有什么好的版本或者标准吗?

      我的体会:

      1、测试用例要根据测试大纲来编写

      2、测试用例也要分测试项进行归类,这样比较好分析和阅读。如:业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

      3、编写测试用例要考虑各种情况,精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

      4、熟悉系统,对编写测试用例很有帮助。

      5、即使对测试很熟悉了,在时间非常紧的时候,编写测试用例还是很有必要和好处的。

      今天就想到那么些了,以后想到了在补充上了。我把我用的模板给你们粘贴一份上来,只能给你们做些参考,具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了,因为每个公司的都不太一样。


  • 编制良好的需求说明书8条原则

    2008-11-05 17:10:57

    1979年由Balzer和Goldman提出了作出良好规格说明的8条原则
    1. 功能与实现分离,即描述要“做什么”而不是“怎样实现”
    2. 要求使用面向处理的规格说明语言,讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应,来定义一个行为模型,从而得到“做什么”的规格说明。
    3. 如果目标软件只是一个大系统中的一个元素,那么整个大系统也包括在规格说明的描述中。描述该目标软件与系统的其他系统元素交互的方式。
    4. 规格说明必须包括系统运行的环境。
    5. 系统规格说明必须是一个认识的模型,而不是设计或实现的模型。
    6. 规格说明必须是可操作的。规格说明必须是充分完全和形式的,以便能够利用它决定对于任意给定的测试用例,已提出的实现方案是否都能满足规格说明。
    7. 规格说明必须容许不完备性并允许扩充。
    8. 规格说明必须局部化和松散的藕合。它所包含的信息必须局部化,这样当信息被修改时,只要修改某个的段落(理想情况)。同时,规格说明应被松散地构造(即藕合),以便能够很快容易地加入和删去一些段落。
Open Toolbar