软件测试——测试用例的设计方法

软件测试——测试用例的设计方法     软件测试

        测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳．目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一．

一、测试用例的几种设计方法

（一）、等价类划分
    等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类；如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。
（二）、边界值
    边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。
（三）、错误推测法
    错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。
（四）、因果图法
    因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。
    设计步骤：
    1）罗列出输入与输出；
    2）根据输入与输出画出因果图；
    3）标出约束跟限制；
    4）把因果图转化成判定表；
    5）根据判定表的每一列设计测试用例。
（五）、判定表驱动法
    判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。
    判定表包括条件桩、条件项、动作桩、动作项。
    条件桩：列出所有条件，次序无关；
    条件项：列出所对应条件的所有可能情况下的取值；
    动作桩：列出可能采取的操作，次序无关；
    动作项：列出条件项各种取值情况下采取的操作。
    设计步骤：
    1）确定规则个数，条件及各条件取值的组合；
    2）列出条件桩、动作桩；
    3）列出条件项；
    4）列出动作项；
    5）初始化判定表；
    6）规则简化、合并。
（六）、正交法
    当输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而减少测试用例数。
    设计步骤：
    1）确定因子并画出正交表草图；
    2）填充各因子的状态值；
    3）加权筛选；
    4）根据筛选过的正交表设计测试用例。
（七）、功能图法
    功能图法适合于用来设计程序的控制结构的测试用例。有顺序、选择、重复三种控制结构。
    设计步骤：
    1）画出功能图；
    2）生成局部测试用例；
    3）生成测试路径；
    4）合成测试用例。
（八）、场景法
    场景法特别适用于控制流清晰的系统。
    设计步骤：
    1）画出程序控制流图（如果不能直接画出控制流图，可先画出程序流程图，再把流程图转换成控制流图）；
    2）根据控制流图设计出场景；
    3）根据场景设计测试用例。
    中间可能会要计算环路复杂度V（G），计算公式如下：
    V（G）=e-n+2
    其中e是边的数目，n是结点的数目。

测试用例设计策略：
    1、任何都要用边界值法；
    2、用等价类划分补充测试用例；
    3、根据测试设计人员经验用错误推测法追加测试用例；
    4、根据程序逻辑追加逻辑测试用例；
    5、根据程序情况，选择使用因果图法设计测试用例。

测试用例设计步骤：
    1、根据设计规格设计基本的功能测试用例；
    2、边界值测试用例；
    3、状态转换测试用例；
    4、错误推测测试用例；
    5、异常测试用例；
    6、性能测试用例。

    另外还需反复利用八种测试用例设计方法对测试用例进行分解与合并，利用发散思维追加测试用例

二、测试用例设计方法场景VS功能

1、目的

　　站在用户的角度，以用户的使用逻辑及操作习惯为出发点，结合功能用例的设计方法，使用例设计更符合用户使用逻辑更具有可执行性，从而最大程度上覆盖用户需求。

　　2、使用者

　　用例设计、执行及热爱测试的人员

　　3、测试用例设计方法

　　按照不同的规则可以将测试用例分为四个部分：场景用例(用户场景)、系统用例(用户场景的细化)、功能用例(基于业务规则、界面)、设计指标(基于环境、性能、安全等)。

　　◆ 用户场景用例：按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例

　　◆ 系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。

　　◆ 功能用例：用于验证各功能点的业务规则，包括界面元素和各功能的业务规则验证。主要针对单个功能点。

　　◆ 设计指标：系统所需要达到的各级指标。主要包含环境、性能、安全等方面的指标。

　　第一步：用户场景用例(关键字：模拟用户实际操作)

　　描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景，这类的用例不宜过多。

　　第二步：系统各角色的系统用例

　　将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。

　　系统用例命名原则：正常(异常、分支)流程_描述

　　第三步：功能用例

　　描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。

　　第四步：设计指标

　　设计指标包含三种类型的用例：环境测试用例、性能测试用例、安全性用例。

　　环境测试用例可依照操作系统版本，浏览器版本不同划分为多个用例。每个用例下可直接调用已有的用户场景用例、系统用例、功能用例，可无须单独编写用例。

　　4、用例设计规则

　　规则如下：

　　1)每个用例需要选择优先级，分为高、中、低三种。

　　每个用例需要关联项目。

　　2)需要特别强调的是，用户场景用例，一定要脱离系统提供功能，站在用户角度来设计用例，从用户实际可能的操作场景考虑。

　　3)用户场景及系统用例的划分粒度。比如：注册登录，其本身也算一个用户场景，但不是用户关心的业务目标，所以把其划分为系统用例中。

4)系统用例与功能用例的划分粒度。功能点是测试用例设计的基本单位，是一个不可再细分的完整操作，可以基于一个表单或者多个表单，依照产品具体需求进行划分。系统用例侧重于场景，是两个或两个以上多个功能点的组合。

原文转自：http://www.ltesting.net