测试用例设计-场景法

测试用例设计-场景法（个人见解与学习）时间：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、异常7、个人简介74、场景法用例设计7文档中红色字体的为理解的重点 黄色背景的为个人简介和思路同时提出：这里只是说明一组方法。具体如何使用，可以结合自己的标准来做。1、引言文档属于个人的见解，个人看法。因为我当时看到同样的一个项目，一个软件需求。就是使用方法不一样；我们就写的用例覆盖率就出现了这么多的偏差。2、基本测试如按照如下的方法去分解：功能测试、界面测试、性能测试、安全测试、数据库测试等等测试2.1、测试优缺点能够按照软件的功能块，一组一组的来做相应的模块测试。但对整体业务场景考虑的不是很好，可能遗漏模块A与模块B之间的用例，因为该方法是从软件本身出发。实际做测试时需要考虑的不是软件本身，还有对应的系统场景等情况。不容易做回归测试，一旦回归需要考虑到用例的回归量。后续测试时间会很长。2.2、黑盒功能测试分解法ü 在任何情况下都必须使用边界分析发，经验表明用这种方法设计出的测试用例发现程序错误的能力最强 （边界法）ü 必要时用等价类划分方法补充一些测试用例（等价类法） ü 用错误推测法再追加一些测试用例 （错误推测法）ü 如果程序的功能说明中含有输入条件的组合情况，则已开始可选用因果图法（因果图法） ü 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例 （功能图）其实这个经验就是方法，以上是一套方法。2.3、个人简介篇上面的做法其实需要我们前期对功能的分解细密，在后期考虑到执行或者回归的时候。安排妥当，不然每次回归或者执行测试都需要执行那么多用例，人员安排上不行，时间上也是不允许。通俗点来解释：基本流：就是正常的，正确场景备选流：分支流+中断3、场景法用例1、什么是场景法？现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。（由此会产生很多组场景）2、场景法特点测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平例如：（2010年软件评测师考试最后一题）可以看看上面的场景法设计用例图形，其实在每个功能里面是可以生产N多条用例。以上的功能就是实现了一个公文的发送过程。引用软件评测考试题1、 基本流备选流是按照功能逻辑上的分解（满足基本的需求功能）2、 对业务上异常情况的处理还未考虑（满足：中心层、省市层、地区层出现的异常情况。此处未考虑中心层和地区层如果出现异常。这个文件也是无法下达的。）3、 平常对界面，控件的验证未做考虑（如：验证下拉框中数据，验证搜索功能的列表显示）也如网站测试按照场景流程考虑可分为：基本流、分支流、异常流、验证流等划分方式以下截图说明：3.1、基本流主要是编写一个功能的正常的测试用例，当然日后开发人员也可以使用该用例做功能验证或者是冒烟，测试方面回归测试可做验证。其实每个人使用的时候写法是不同的，基本场景就是正常的操作登录。如：上面例子中的基本流（A流程和B流程）后期开发可以使用这个基本流程来验证他们的开发质量，当作冒烟测试用例使用。保证我们测试的产品基本的功能逻辑是通的，不会出现很多用例阻塞，提高了我们在用例执行时的质量。3.2、分支流除了正常操作以外程序做的处理，需要程序做非法判断处理的，比如输入输出错误或者不满足规则的测试用例。如：上面例子中的备选流其实如果在后期做回归的时候对用例的处理量会有一个优先级别的划分，而此处可在前几轮回归的时候多多的关注程序的判断逻辑。这个也就是功能实现是否完善前期第一轮做测试也可以把重点放在这里处理，因为冒烟测试开发会做一组或者几组预测试。侧重点也就是对程序基本功能的验证，完善功能实现。如：前几轮做测试可能多关注功能实现，这里的用例就是测试的中心3.3、验证流此处和界面测试有点相似主要分：整体界面测试、界面元素测试、控件操作验证过ü 整体界面测试：就是去验证整体的界面是否和设计图一致ü 界面元素测试：这个一般在做网站时候需要，比如查看HTML的网页元素是否加载完成或者是理解网页中是否缺少这个元素。（一般加载图片的时候，无法正常显示）ü 控件操作验证：如对控件能否操作、操作是否正常的验证。一般会检查下拉框，输入框。至于操作提交是否正确，这个属于实现的功能应该放在分支里面去验证这个功能。在这里做出验证，关键是对整体的界面验证，或者是功能修改以后，一些控件没法使用。3.4、异常整体的去考虑场景上对功能的影响，特意的去构造一些异常的场景。这部分用例可能不会去关注，也有些会很难去捕捉。但是站在客户和测试的角度这些用例是一定会存在的，只是我们这些用例执行的优先级别会放低，也就是执行难度大。需要考虑到很多外界因素和实际执行环境。包括测试数据的准备时，会把很多执行难度大的用例放在日后去做处理。如：上面的这个公文发布流程中，它可能存在的异常情况1、公文发布在中心层就出现了某些情况？2、公文发布到省市层，出现了删除、修改等情况？、个人简介可以把属于数据的验证放在这里，其实测试的时候有很多地方需要对数据进行验证。比如我们删除数据以后，前端虽然相应了我们的删除操作，也删除成功。但是我们在做处理的时刻需要去检查数据情况，而当时环境又不允许，在异常里放上这么一组用例。可以做到后续执行时去验证数据。4、场景法用例设计测试用例设计方法按照不同的规则可以将测试用例分为四个部分：场景用例（用户场景）、系统用例（用户场景的细化）、功能用例（基于业务规则、界面）、设计指标（基于环境、性能、安全等）。 用户场景用例：按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例 系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。 功能用例：用于验证各功能点的业务规则，包括界面元素和各功能的业务规则验证。主要针对单个功能点。 设计指标：系统所需要达到的各级指标。主要包含环境、性能、安全等方面的指标。第一步：用户场景用例（关键字：模拟用户实际操作）描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景，这类的用例不宜过多。第二步：系统各角色的系统用例将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。系统用例命名原则：正常（异常、分支）流程_描述第三步：功能用例描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。第四步：设计指标设计指标包含三种类型的用例：环境测试用例、性能测试用例、安全性用例。环境测试用例可依照操作系统版本，浏览器版本不同划分为多个用例。每个用例下可直接调用已有的用户场景用例、系统用例、功能用例，可无须单独编写用例。4、用例设计规则规则如下：1）每个用例需要选择优先级，分为高、中、低三种。每个用例需要关联项目。2）需要特别强调的是，用户场景用例，一定要脱离系统提供功能，站在用户角度来设计用例，从用户实际可能的操作场景考虑。3）用户场景及系统用例的划分粒度。比如：注册登录，其本身也算一个用户场景，但不是用户关心的业务目标，所以把其划分为系统用例中。4）系统用例与功能用例的划分粒度。功能点是测试用例设计的基本单位，是一个不可再细分的完整操作，可以基于一个表单或者多个表单，依照产品具体需求进行划分。系统用例侧重于场景，是两个或两个以上多个功能点的组合。