测试用例设计—场景法.docVIP

测试用例设计-场景法（个人见解与学习） 时间：2010-11-19 编写人 时间 修复时间 龙文 2010-11-19 2010-12-9 目录 1、引言 3 2、基本测试 3 2.1、测试优缺点 3 2.2、黑盒功能测试分解法 3 2.3、个人简介篇 3 3、场景法用例 4 1、什么是场景法？ 4 2、场景法特点 4 3.1、基本流 6 3.2、分支流 6 3.3、验证流 7 3.4、异常 7 3.4.1、个人简介 7 4、场景法用例设计 7 文档中红色字体的为理解的重点 黄色背景的为个人简介和思路 同时提出：这里只是说明一组方法。具体如何使用，可以结合自己的标准来做。 1、引言 文档属于个人的见解，个人看法。因为我当时看到同样的一个项目，一个软件需求。就是使用方法不一样；我们就写的用例覆盖率就出现了这么多的偏差。 2、基本测试 如按照如下的方法去分解： 功能测试、界面测试、性能测试、安全测试、数据库测试等等测试 2.1、测试优缺点 能够按照软件的功能块，一组一组的来做相应的模块测试。但对整体业务场景考虑的不是很好，可能遗漏模块A与模块B之间的用例，因为该方法是从软件本身出发。实际做测试时需要考虑的不是软件本身，还有对应的系统场景等情况。不容易做回归测试，一旦回归需要考虑到用例的回归量。。后续测试时间会很长。 2.2、黑盒功能测试分解法 在任何情况下都必须使用边界分析发，经验表明用这种方法设计出的测试用例发现程序错误的能力最强 （边界法） 必要时用等价类划分方法补充一些测试用例（等价类法） 用错误推测法再追加一些测试用例 （错误推测法） 如果程序的功能说明中含有输入条件的组合情况，则已开始可选用因果图法（因果图法） 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例 （功能图） 其实这个经验就是方法，以上是一套方法。。 2.3、个人简介篇 上面的做法其实需要我们前期对功能的分解细密，在后期考虑到执行或者回归的时候。安排妥当，不然每次回归或者执行测试都需要执行那么多用例，人员安排上不行，时间上也是不允许。 通俗点来解释：基本流：就是正常的，正确场景备选流： 3、场景法用例 1、什么是场景法？ 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。 2、场景法特点 测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平 可以看看上面的场景法设计用例图形，其实在每个功能里面是可以生产N多条用例。 以上的功能就是实现了一个公文的发送过程。 引用软件评测考试题 基本流备选流是按照功能逻辑上的分解（满足基本的需求功能） 对业务上异常情况的处理还未考虑（满足：中心层、省市层、地区层出现的异常情况。此处未考虑中心层和地区层如果出现异常。这个文件也是无法下达的。。） 平常对界面，控件的验证未做考虑（如：验证下拉框中数据，验证有哪些信誉好的足球投注网站功能的列表显示） 也如网站测试按照场景流程考虑可分为： 基本流、分支流、异常流、验证流等划分方式 以下截图说明： 3.1、基本流 主要是编写一个功能的正常的测试用例，当然日后开发人员也可以使用该用例做功能验证或者是冒烟，测试方面回归测试可做验证。其实每个人使用的时候写法是不同的，基本场景就是正常的操作登录。 如：上面例子中的基本流（A流程和B流程） 后期开发可以使用这个基本流程来验证他们的开发质量，当作冒烟测试用例使用。保证我们测试的产品基本的功能逻辑是通的，不会出现很多用例阻塞，提高了我们在用例执行时的质量。 3.2、分支流 除了正常操作以外程序做的处理，需要程序做非法判断处理的，比如输入输出错误或者不满足规则的测试用例。 如：上面例子中的备选流 其实如果在后期做回归的时候对用例的处理量会有一个优先级别的划分，而此处可在前几轮回归的时候多多的关注程序的判断逻辑。这个也就是功能实现是否完善 前期第一轮做测试也可以把重点放在这里处理，因为冒烟测试开发会做一组或者几组预测试。 侧重点也就是