测试用例设计.docx

《测试用例设计.docx》由会员分享，可在线阅读，更多相关《测试用例设计.docx（9页珍藏版）》请在第一文库网上搜索。

1、测试用例设计-场景法（个人见解与学习）时间：2022-11-19编写人时间修复时间龙文2022-11-192022-12-9名目1、弓I言32、基本测试32.1、 测试优缺点32.2、 黑盒功能测试分解法32.3、 个人简介篇32.4、 法用例41、什么是场景法？ 42、场景法特点43.1、 基本流63.2、 分支流63.3、 验证流73.4、 特别7、个人简介74、场景法用例设计7文档中红色字体的为理解的重点黄色背景的为个人简介和思路同时提出：这里只是说明一组方法。详细如何使用，可以结合自己的标准来做。1、引言文档属于个人的见解，个人看法。由于我当时看到同样的一个项目，一个软件需求。就是使用

2、方法不一样；我们就写的用例掩盖率就消失了这么多的偏差。2、基本测试如根据如下的方法去分解：功能测试、界面测试、性能测试、平安测试、数据库测试等等测试2、测试优缺点能够根据软件的功能块，一组一组的来做相应的模块测试。但对整体业务场景考虑的不是很好，可能遗漏模块A与模块B之间的用例，由于该方法是从软件本身动身。实际做测试时需要考虑的不是软件本身，还有对应的系统场景等状况。不简单做回归测试，一旦回归需要考虑到用例的回归量。后续测试时间会很长。2,2、黑盒功能测试分解法/在任何状况下都必需使用边界分析发，阅历表明用这种方法设计出的测试用例发觉程序错误的力量最强（边界法）/必要时用等价类划分方法补充一些

3、测试用例（等价类法）,用错误推想法再追加一些测试用例（错误推想法）/假如程序的功能说明中含有输入条件的组合状况，则已开头可选用因果图法（因果图法）,对比程序规律，检查已设计出的测试用例的规律掩盖程度，假如没有达到要求的掩盖标准，应再补充分够的测试用例（功能图）其实这个阅历就是方法，以上是一套方法。2.3、个人简介篇上面的做法其实需要我们前期对功能的分解细密，在后期考虑到执行或者回归的时候。支配妥当，不然每次回归或者执行测试都需要执行那么多用例，人员支配上不行，时间上也是不允许。通俗点来解释：基本流：就是正常的，正确场景备选流：分支流+中断3、场景法用例1、什么是场景法?现在的软件几乎都是用大事

4、触发来掌握流程的，大事触发时的情景便形成了场景，而同一大事不同的触发挨次和处理结果就形成大事流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出大事触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更简单理解和执行。（由此会产生许多组场景）使用用例场景设计测试.2、场景法特点测试用例的设计方法不是单独存在的，详细到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何采用这些黑盒方法是特别重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试掩盖度，这就需要仔细把握这些方法的原理，积累更多的测

5、试阅历，以有效提高测试水平例如：（2022年软件评测师考试最终一题）试 JS 一（15 分）阅读下列说明.至问题2.将解答埴入答题玳的对四校说明1三景法是羯盒测试祖的测试用例设口力法,目前多数软件系统廨用事件做缝来控制业务流程事件触发时的情景便形成了场景，场景的不同勉发顺序构成用例。场景法通过场景描述业务流程（包括基本流（基本流程）和备j （分支流程）设计用例遍历软件系统功能，验证其正确性。图】描述了简化的中心层、省市层、地区层三级的“公文流转”业务流程，表J描述了省市层（图1阴影部分）业务的基本流和备选流公文的状态包括：已下发、未下发、已接收、农接收。“公文流传”业务流程图rttewi地区依

6、接收、， , I 4 ，u2. ? I 1r igi*-Urlzrrr业务流编号基本流备选流保存新建公文修改新建公文删除新建薮图1 “公文流转”业务流程图表1省市层业务流描述一中心公文下发|省市层接收中心公文,夕下发到地区层新建公文百接下发行市届新建公文后发到地区层一对保存的省市同新建公文适当时下发到地反层修改省市层新建的公文而除省市层新建的公文2”0：年下半H软件评测部卜午试叁第2页（共6火），可以看看上面的场景法设计用例图形，其实在每个功能里面是可以生产N多条用例。以上的功能就是实现了一个公文的发送过程。引用软件评测考试题1、基本流备选流是根据功能规律上的分解（满意基本的需求功能）2、对业

7、务上特别状况的处理还未考虑（满意：中心层、省市层、地区层消失的特别状况。此处未考虑中心层和地区层假如消失特别。这个文件也是无法下达的。)3、平常对界面，控件的验证未做考虑(如：验证下拉框中数据，验证搜寻功能的列表显示)也如网站测试根据场景流程考虑可分为：基本流、分支流、特别流、验证流等划分方式以下截图说明：日6客户璃0828) 31 登录 (92) 301 受录(84)SQ01基本充程(3)田仁02分支充程(48)田仁03异常充程(25)田口。4 UIiiE(8)国仁)02退出(1)国仁)03受由(7)3.1、 基本流主要是编写一个功能的正常的测试用例，当然日后开发人员也可以使用该用例做功能验

8、证或者是冒烟，测试方面回归测试可做验证。其实每个人使用的时候写法是不同的，基本场景就是正常的操作登录。如：上面例子中的基本流(A流程和B流程)后期开发可以使用这个基本流程来验证他们的开发质量，当作冒烟测试用例使用。保证我们测试的产品基本的功能规律是通的，不会消失许多用例堵塞，提高了我们在用例执行时的质量。3.2、 分支流除了正常操作以外程序做的处理，需要程序做非法推断处理的，比如输入输出错误或者不满意规章的测试用例。如：上面例子中的备选流其实假如在后期做回归的时候对用例的处理量会有一个优先级别的划分，而此处可在前儿轮回归的时候多多的关注程序的推断规律。这个也就是功能实现是否完善前期第一轮做测试

9、也可以把重点放在这里处理，由于冒烟测试开发会做一组或者几组猜测试。侧重点也就是对程序基本功能的验证，完善功能实现。如：前几轮做测试可能多关注功能实现，这里的用例就是测试的中心3.3、 验证流此处和界面测试有点相像主要分：整体界面测试、界面元素测试、控件操作验证过/ 整体界面测试：就是去验证整体的界面是否和设计图全都/ 界面元素测试：这个一般在做网站时候需要，比如查看HTML的网页元素是否加载完成或者是理解网页中是否缺少这个元素。（一般加载图片的时候，无法正常显示）/控件操作验证：如对控件能否操作、操作是否正常的验证。一般会检查下拉框，输入框。至于操作提交是否正确，这个属于实现的功能应放在分支里

10、面去验证这个功能。在这里做出验证，关键是对整体的界面验证，或者是功能修改以后，一些控件没法使用。3.4、 特别整体的去考虑场景上对功能的影响，特意的去构造一些特别的场景。这部分用例可能不会去关注，也有些会很难去捕获。但是站在客户和测试的角度这些用例是肯定会存在的，只是我们这些用例执行的优先级别会放低，也就是执行难度大。需要考虑到许多外界因素和实际执行环境。包括测试数据的预备时，会把许多执行难度大的用例放在日后去做处理。如：上面的这个公文发布流程中，它可能存在的特别状况1、公文发布在中心层就消失了某些状况？2、公文发布到省市层，消失了删除、修改等状况？、个人简介可以把属于数据的验证放在这里，其实

11、测试的时候有许多地方需要对数据进行验证。比如我们删除数据以后，前端虽然相应了我们的删除操作，也删除胜利。但是我们在做处理的时刻需要去检查数据状况，而当时环境又不允许，在特别里放上这么一组用例。可以做到后续执行时去验证数据。4、场景法用例设计测试用例设计方法根据不同的规章可以将测试用例分为四个部分：场景用例（用户场景）、系统用例（用户场景的细化）、功能用例（基于业务规章、界面）、设计指标（基于环境、性能、平安等）。 用户场景用例：根据用户的实际操作与业务规律设计用例，不必涉及很简单的操作或规律，把用户最常用的、正常的操作流程作为一个场景设计测试用例 系统用例：是用户场景的细化，包含正常场景、分支

12、场景和特别场景，是两个或多个有关联的功能组合而成的场景。 功能用例：用于验证各功能点的业务规章，包括界面元素和各功能的业务规章验证。主要针对单个功能点。 设计指标：系统所需要达到的各级指标。主要包含环境、性能、平安等方面的指标。第一步：用户场景用例（关键字：模拟用户实际操作）描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景，这类的用例不宜过多。其次步：系统各角色的系统用例将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、特别流程，分支流程，以场景的形式描述。系统用例命名原则：正常（特别、分支）

13、流程描述第三步：功能用例描述单点功能的规律规章及页面元素，分层描述规律规章，对规律规章细化可直接作为用例的操作步骤描述。第四步：设计指标设计指标包含三种类型的用例：环境测试用例、性能测试用例、平安性用例。环境测试用例可依照操作系统版本，扫瞄器版本不同划分为多个用例。每个用例下可直接调用已有的用户场景用例、系统用例、功能用例，可无须单独编写用例。4、用例设计规章规章如下:1）每个用例需要选择优先级，分为高、中、低三种。每个用例需要关联项目。2）需要特殊强调的是，用户场景用例，肯定要脱离系统供应功能，站在用户角度来设计用例，从用户实际可能的操作场景考虑。3）用户场景及系统用例的划分粒度。比如：注册登录，其本身也算一个用户场景，但不是用户关怀的业务目标，所以把其划分为系统用例中。4）系统用例与功能用例的划分粒度。功能点是测试用例设计的基本单位，是一个不行再细分的完整操作，可以基于一个表单或者多个表单，依照产品详细需求进行划分。系统用例侧重于场景，是两个或两个以上多个功能点的组合。