测试用例设计-场景法

9/9测试用例设计-场景法（个人见解与学习）时间：2010-11-19编写人时间修复时间龙文2010-11-192010-12-9名目1、引言 32、基本测试 32.1、测试优缺点 32.2、黑盒功能测试分解法 32.3、个人简介篇 33、场景法用例 41、什么是场景法？ 42、场景法特点 43.1、基本流 63.2、分支流 63.3、验证流 73.4、异常 73.4.1、个人简介 74、场景法用例设计 7文档中红色字体的为理解的重点 黄色背景的为个人简介和思路同时提出：这里只是说明一组方法。简略如何使用，可以结合自己的标准来做。1、引言 文档属于个人的见解，个人看法。由于我当时看到同样的一个项目，一个软件需求。就是使用方法不一样；我们就写的用例掩盖率就消失了这么多的偏差。2、基本测试如依据如下的方法去分解：功能测试、界面测试、性能测试、平安测试、数据库测试等等测试2.1、测试优缺点能够依据软件的功能块，一组一组的来做相应的模块测试。但对整体业务场景考虑的不是很好，可能遗漏模块A与模块B之间的用例，由于该方法是从软件本身动身。实际做测试时需要考虑的不是软件本身，还有对应的系统场景等情况。不容易做回归测试，一旦回归需要考虑到用例的回归量。。后续测试时间会很长。2.2、黑盒功能测试分解法在任何情况下都必须使用边界分析发，阅历表明用这种方法设计出的测试用例发现程序错误的能力最强（边界法）必要时用等价类划分方法补充一些测试用例（等价类法）用错误推测法再追加一些测试用例（错误推测法）如果程序的功能说明中含有输入条件的组合情况，则已开头可选用因果图法（因果图法）对比程序规律，检查已设计出的测试用例的规律掩盖程度，如果没有达到要求的掩盖标准，应当再补充足够的测试用例（功能图）其实这个阅历就是方法，以上是一套方法。。2.3、个人简介篇上面的做法其实需要我们前期对功能的分解细密，在后期考虑到执行或者回归的时候。支配妥当，不然每次回归或者执行测试都需要执行那么多用例，人员支配上不行，时间上也是不允许。通俗点来解释：

基本流：就是正常的，正确场景

备选流：分支流+中断3、场景法用例1、什么是场景法？ 现在的软件几乎都是用大事触发来掌握流程的，大事触发时的情景便形成了场景，而同一大事不同的触发挨次和处理结果就形成大事流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出大事触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。（由此会产生很多组场景）2、场景法特点 测试用例的设计方法不是单独存在的，简略到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是特别重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试掩盖度，这就需要专心掌握这些方法的原理，积累更多的测试阅历，以有效提高测试水平 例如：（2010年软件评测师考试最后一题）可以看看上面的场景法设计用例图形，其实在每个功能里面是可以生产N多条用例。以上的功能就是实现了一个公文的发送过程。引用软件评测考试题基本流备选流是依据功能规律上的分解（满足基本的需求功能）对业务上异常情况的处理还未考虑（满足：中心层、省市层、地区层消失的异常情况。此处未考虑中心层和地区层如果消失异常。这个文件也是无法下达的。。）平常对界面，控件的验证未做考虑（如：验证下拉框中数据，验证搜寻功能的列表显示）也如网站测试依据场景流程考虑可分为： 基本流、分支流、异常流、验证流等划分方式以下截图说明：3.1、基本流 主要是编写一个功能的正常的测试用例，当然日后开发人员也可以使用该用例做功能验证或者是冒烟，测试方面回归测试可做验证。其实每个人使用的时候写法是不同的，基本场景就是正常的操作登录。如：上面例子中的基本流（A流程和B流程）后期开发可以使用这个基本流程来验证他们的开发质量，当作冒烟测试用例使用。保证我们测试的产品基本的功能规律是通的，不会消失很多用例堵塞，提高了我们在用例执行时的质量。3.2、分支流除了正常操作以外程序做的处理，需要程序做非法推断处理的，比如输入输出错误或者不满足规章的测试用例。如：上面例子中的备选流 其实如果在后期做回归的时候对用例的处理量会有一个优先级别的划分，而此处可在前几轮回归的时候多多的关注程序的推断规律。这个也就是功能实现是否完善前期第一轮做测试也可以把重点放在这里处理，由于冒烟测试开发会做一组或者几组猜测试。侧重点也就是对程序基本功能的验证，完善功能实现。如：前几轮做测试可能多关注功能实现，这里的用例就是测试的中心3.3、验证流 此处和界面测试有点相像主要分：整体界面测试、界面元素测试、控件操作验证过整体界面测试：就是去验证整体的界面是否和设计图全都界面元素测试：这个一般在做网站时候需要，比如查看HTML的网页元素是否加载完成或者是理解网页中是否缺少这个元素。（一般加载图片的时候，无法正常显示）控件操作验证：如对控件能否操作、操作是否正常的验证。一般会检查下拉框，输入框。至于操作提交是否正确，这个属于实现的功能应该放在分支里面去验证这个功能。在这里做出验证，关键是对整体的界面验证，或者是功能修改以后，一些控件没法使用。3.4、异常整体的去考虑场景上对功能的影响，特意的去构造一些异常的场景。这部分用例可能不会去关注，也有些会很难去捕获。但是站在客户和测试的角度这些用例是肯定会存在的，只是我们这些用例执行的优先级别会放低，也就是执行难度大。需要考虑到很多外界因素和实际执行环境。包括测试数据的筹备时，会把很多执行难度大的用例放在日后去做处理。如：上面的这个公文发布流程中，它可能存在的异常情况1、公文发布在中心层就消失了某些情况？2、公文发布到省市层，消失了删除、修改等情况？3.4.1、个人简介可以把属于数据的验证放在这里，其实测试的时候有很多地方需要对数据进行验证。比如我们删除数据以后，前端虽然相应了我们的删除操作，也删除成功。但是我们在做处理的时刻需要去检查数据情况，而当时环境又不允许，在异常里放上这么一组用例。可以做到后续执行时去验证数据。4、场景法用例设计测试用例设计方法依据不同的规章可以将测试用例分为四个部分：场景用例（用户场景）、系统用例（用户场景的细化）、功能用例（基于业务规章、界面）、设计指标（基于环境、性能、平安等）。◆用户场景用例：依据用户的实际操作与业务规律设计用例，不必涉及很简单的操作或规律，把用户最常用的、正常的操作流程作为一个场景设计测试用例◆系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。◆功能用例：用于验证各功能点的业务规章，包括界面元素和各功能的业务规章验证。主要针对单个功能点。◆设计指标：系统所需要达到的各级指标。主要包含环境、性能、平安等方面的指标。第一步：用户场景用例（关键字：模拟用户实际操作）描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景，这类的用例不宜过多。其次步：系统各角色的系统用例将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。系统用例命名原则：正常（异常、分支）流程_描述第三步：功能用例描述单点功能的规律规章及页面元素，分层描述规律规章，对规律规章细化可直接作为用例的操作步骤描述。第四步：设计指标设计指标包含三种类型的用例：环境测试用例、性能测试用例、平安性用例。环境测试用例可依照操作系统版本，扫瞄器版本不同划分为多个用例。每个用例下可直接调用已有的用户场景用例、系统用例、功能用例，可无须单独编写用例。4、用例设计规章规章如下：1）每个用例需要选择优先级，分为高、中、低三种。每个用例需要关联项目。2）需要特别强调的