北大青鸟测试功能测试用例设计.ppt

测试用例设计 即时贴程序 即时贴程序 程序演示 便签的数量最多为50个 便签标题字数最多为40个字节 便签的正文文字数量最多为200个 年份只能设置在1900－2100之间 用途简介 使用方法简介 如何测试？ * * 如何全面系统的组织测试 测试过程中遇到的问题 不知道是否较全面的测试了所有内容 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率 如果大家合作测试，会不会出现重复测试、同时定位相同问题的现象？ 如果我们发现问题，交给开发人员修改之后，过段时间再重新测试，是否能准确快速重新测试问题是否修改正确？ * * 测试用例设计 测试用例的基本概念 测试用例的设计和编写 测试用例的定义 测试用例就是记下我们要进行什么测试，进行测试的具体步骤，以及测试执行是否正确的标准 测试用例是一个包含输入和预期输出并与实际输出有关的标识 解决要测什么、怎么测和如何测的问题 测试用例的用途和目的 执行测试，发现缺陷 重复执行测试，重现缺陷 管理测试过程 回归测试，验证缺陷是否修复 测试用例的用途和目的 使测试更加方便的执行 提高测试效率 便于进行回归测试 使测试过程更方便管理 影响测试用例设计的主要因素 需求目标 用户实际使用场景 软件功能需求规格说明书 测试的方法 测试的对象 测试用例的编写原则 准确性 测试用例的设计确实符合测试需求，并且必须准确地说明测试的内容 简洁性 测试用例的设计中必须包含完成测试必要的步骤、要素，不需要加入多余的、可有可无的步骤、要素 测试用例的编写原则 可重用性 测试用例的设计要求测试是可控的，它能够使任何人在任何时间进行测试都能获得同样的结果 适用性 测试用例对于当前的测试环境和测试者而言是可以执行的 测试用例的编写原则 纯净性 不会因为执行该测试用例而影响其它测试用例的执行，用例中应说明如何将应用系统恢复到最初状态，而不影响后续测试的进行。 测试用例的编写格式 测试用例的编写有三种主要格式： Step-by-step（按步骤） Matrix（矩阵表） Automated script（自动化脚本） 前两种是测试用例最基本的格式，最后一种是自动执行前两种测试用例的软件脚本。 测试用例的编写格式 Step-by-step 测试用例的编写格式 Matrix 测试用例的编写格式 Automated script 取得航班表的行数 ItemCount=Window(航班预订).Dialog(航班表).WinList(从).GetItemsCount 随机选取其中一项 SelectItem=RandomNumber(0,ItemCount) 选择航班 Window(航班预订).Dialog(航班表).WinList(从).Select selectItem Window(航班预订).Dialog(航班表).WinButton(确定).Click Window(航班预订).Activate Window(航班预订).WinEdit(名称:).Set 123 输入名称 Window(航班预订).WinButton(插入订单(I)).Click 测试用例设计方法 黑盒测试方法 功能分解 等价类划分 边界值分析 因果图法 …… 测试用例设计方法 白盒测试方法 语句覆盖 分支覆盖 条件覆盖 …… 编写有效的测试用例 使用合理的语言 测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测试用例的输入和预期输出 避免含义混淆，方法：在操作步骤中采用动词+名词的结构，动词总是测试人员要做得事情，名词总是测试人员操作的对象、事物 制定命名规则，同一种事物只有一种名称 编写有效的测试用例 使用模板 编写测试用例更方便 提高测试用例的组织性 提供了标准 格式统一美观 有助于测试人员寻找信息 能够包括很多有关测试过程的选项 编写有效的测试用例 使用克隆（Cloning） 模仿某个测试用例来写别的测试用例 某些用户手册中的步骤、文字也可以被克隆 保存以前写过的测试用例，以便以后进行克隆 Matrixes测试用例也可以克隆，特别是在表结构相同的情况下，只需要改变一些列的名称和值就可以 编写有效的测试用例 测试用例的依赖关系 具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用例 考虑是否真的需要其他的测试的结果作为数据输入，如果是，那么测试必需是累积的。应尽量避免这种情况，以免让测试变得繁琐 保持测试用例依赖关系的正确性和一致性 以一种合理的顺序来安排测试用例的顺序 测试用例示例 1.测试用例标识 2.测试步骤 3.输入 4.预期输出