企业培训_测试用例设计培训

2020年2月19日 测试用例设计方法 方建康 问题 1 许多书籍上大篇幅教受的 等价类划分 边界值 错误推断 因果图 等 大家应该运用的很少 2 好不容易完成用例的编写 可随之而来的新特性加入 让现有的用例非常尴尬 3 很多用例几乎很少去执行 因为它们已经与实际程序脱节了 4 执行现有的测试用例发现的Bug很少 5 没有时间为新特性补偿新的用例 就算有时间补充但现有结构非常乱 不知道从何入手 我们的测试用例设计方法出问题了 那么原因何在呢 可能的解决办法 1 测试驱动开发 用例指导结果 数据记录变化 别误会 这里说的 测试驱动开发 是黑盒测试中进行的 并不是指单元测试中的测试驱动开发 有80 的Bug是在黑盒测试阶段发现的 所以黑盒测试显得非常重要 不要说黑盒测试没有技术含量 那是因为你没有真正投入黑盒测试中 如何进行测试驱动开发 以业务用例指导过程和结果 开发人员比较关注技术 在业务上的理解自然容易偏差 需求文档不会很明确指出具体的功能实现 使得业务到功能会出现一个比较大的阅读障碍 开发容易出错的地方 就是测试人员应该关注的地方 业务用例的构造应该先于程序的实现 与需求和开发人员沟通一致 并以此作为基准 业务用例可以不关注界面的实现 但一定要有数据支持 明确业务用例的输入和输出 为此建立一套数据池 业务功能的变化带来的测试 可以用数据池中的数据来进行验证 2 为测试用例标明时间 版本 和优先级 正如我们的TMS的设计思想 为用例创建时间 版本 机制可以起到一种基准作用 标明项目进度过程中的每个阶段 使用例直接和需求基线 软件版本对应 也可以给用例新增一个状态 指明这个用例是否与当前程序版本冲突 当程序变更时可以改变用例状态 这样一来可以及时提醒到测试人员 该是更新测试用例的时候了 为测试用例新增优先级可以指出软件的测试重点 用例编程重点 减少用例回归时间 增加重点用例的执行次数 还可以帮助新人尽快了解需求和被测系统 对与自动化测试来讲也可以参考这个优先级来录制脚本 当然这一点早已经在项目组中实施了 希望继续努力 持续下去 3 功能用例与业务用例分开组织 业务用例应该在开发前或同期编写 帮助测试人员和开发人员明确业务 了解正确流程和错误流程 功能用例依赖程序界面的描述 但功能用例并不等于使用说明 对某些模块的等价类划分 边界值测试会发现很多严重的Bug 也许与业务用例毫无关系 但用户往往很容易这样操作 例如 登录名测试 你是否考虑到很长的名字 或者用户键盘有问题 总是敲入n多空格 这与业务无关但程序会怎样处理呢 4 审核用例 结对编写 测试主管或经理对测试用例的审核 可以做到对用例的校对和补充 但一般情况下 领导都比较忙 很难做到对每个项目用例的审阅 我们可以采取另一种方法 结对编写测试用例 当然前提是至少要有2个测试人员 测试用例不是一个人编写一个人执行 它需要其他测试人员都能读懂且明白目标所指 结对编写可以减少个人的 偏好习惯 同时能拓展思维 加强测试重点的确认 小组内部达到统一 这样也减轻了测试主管或经理对用例管理的工作量同时也提高了组员参与的积极性 上面的解决方法只是种建议具体怎样实施应依据项目而定 还谈测试用例基本要素 我们要求用例需要符合以下特征 最有可能抓住错误 不重复 多余 一组相似测试用例中最有效的 不要太简单 也不要太复杂 易扩展 重用性好 经验很重要 唯有相当充分的项目经验 才能设计出如上要求的测试用例来 不过我们可以共同努力 将其视为我们的用例设计的终极目标 我们在通往终极目标的道路上 用例设计的着眼点 当然我们需要介绍测试用例的设计方法 等价类划分 边界值等等 但是好多课程都有介绍过 太过枯燥 我们还是来些实际例子 等价类划分的办法是把程序的输入域划分成若干部分 然后从每个部分中选取少数代表性数据当作测试用例 每个部分视为一个等价类 测试用例设计方法 等价类划分 定义 举例 测试两个参数的值相加后的结果是否正确 其中 输入的数值在 99到99之间大于99或小于 99的输入应被拒绝 并显示错误信息 一步一步划分等价类 步骤1 计算等价类的数量 依据测试需求我们可以分为3个等价类 1个有效等价类 2个无效等价类 有效数据等价类就是 由那些对程序的规格说明有意义的 合理的输入数据所构成的集合 无效数据等价类就是 那些对程序的规格说明不合理的或无意义的输入数据所构成的集合 99 99 1 2 3 无效等价类数值 99 有效等价类 99 数值 99 无效等价类数值 99 一步一步划分等价类 步骤2 建立等价类表 把程序中所有的等价类建立等价类表 以便在编写测试用例的时候有所依据 步骤3 确定测试用例 为等价类表中的每一个等价类分配一个唯一的编号 设计一个新的测试用例 使它能够尽量覆盖尚未覆盖的有效等价类 一步一步划分等价类 步骤4 看看是否可以细化等价类 在测试 99 数值 99 的这个等价类区间的时候 我们会发现如10 40 20 30和 30 30 这类的正数相加 正数负数相加 负数相加也是不同的等价区间 因此我们可以使用更多的等价类划分 99 99 1 2 3 无效等价类数值 99 有效等价类 99 数值 0 无效等价类数值 99 4 0 有效等价类0 数值 99 根据以上等价类划分的结果 得出下表的等价类表 一步一步划分等价类 步骤5 好吧 最终的测试用例应该是这样的 根据上面划分的4个等价类 我们至少需要有5个测试用例 等价类方法设计测试用例的核心思想应该就如此了 当然题目很小实践性并不大 在实际的项目中大家再自由发挥 希望对大家有帮助 来个小测试 Windows文件名可以包含除了 和 之外的任意字符 文件名长度是1 255个字符 这样的需求 等价类该如何划分呢 等价区间有 合法字符 非法字符 合法长度的名称 过长名称和过短名称 测试用例设计方法 边界值分析 边界值分析法是一种补充等价划分的测试用例设计技术 它不是选择等价类的任意元素 而是选择等价类边界的测试用例 定义 设计原则 1 如果输入条件规定了取值范围 应以该范围的边界内及刚刚超范围的边界外的值作为测试用例 如以a和b为边界 测试用例应当包含a和b及略大于a和略小于b的值 2 若规定了值的个数 分别以最大 最小个数及稍小于最小 稍大于最大个数作为测试用例 3 如果程序规格说明中提到的输入或输出域是个有序的集合 如顺序文件 表格等 就应注意选取有序集的第一个和最后一个元素作为测试用例 4 分析规格说明 找出其他的可能边界条件 举例 我们根据边界值分析的方法来看看如何对边界值进行测试 99 99 98 100 100 98 由于允许输入的数值在 99到99之间 所以我们可以把 99和99看作两个边界值 我们测试的时候可以取紧邻边界值的数值和边界值本身作为输入 来个小测试 某程序对用户输入的字符是根据字符的ASCII码来进行处理的 程序有以下限制 文本框只接受用户输入字符A Z和a z 这样的需求 使用边界值怎样编写用例呢 应该在非法区间中包含ASCII表中这些字符前后的值 和 边界值分析 补充 默认 空白 空值 零值和无 比如在文本框中 不是没有输入正确的信息 而是根本没有输入任何内容 但是按下Enter键 这种情况在产品说明书中常常忽略 程序员也经常遗忘 但是在实际使用中却时有发生 好的软件会处理这种情况 它通常将输入内容默认为合法边界内的最小值 或者合法区间内某个合理值 或者返回错误提示信息 在编写测试用例的时候 就应该将这种情况考虑进去 碰到经验不足的程序员 偶尔就有意外收获哦 测试用例设计方法 测试方法的选择 当然 我们并没有介绍完所有的测试用例设计方法 错误推断 因果图 场景法 等 这些内容大家可以下来再进一步研究 我们接下来需要了解下用例设计方法的选择策略 1 首先进行等价类划分 包括输入条件和输出条件的等价划分 将无限测试变成有限测试 这是减少工作量和提高测试效率的最有效方法 2 在任何情况下都必须使用边界值分析方法 经验表明用这种方法设计出测试用例发现程序错误的能力最强 3 对照程序逻辑 检查已设计出的测试用例的逻辑覆盖程度 如果没有达到要求的覆盖标准 应当再补充足够的测试用例 4 对于业务流清晰的系统 可以利用场景法贯穿整个测试案例过程 在案例中综合使用各种测试方法 测试用例设计编写原则 1 完整的考虑系统业务 对系统的业务流程能够完整说明 系统由多少子系统构成及它们之间的关系 对模块来讲要说明其主要功能点以及与其他模块之间的关系 2 考虑系统业务的连贯性 需要考虑系统业务的走向 说明清楚当前业务的上一个业务点与下一个业务点的衔接关系 说明清楚数据的流向及变化 3 全面考虑系统的测试点 a 尽可能覆盖程序的各种路径 如果可以做到的话 b 尽可能覆盖系统的各个业务 尽我们最大的可能做到 c 应该考虑大量数据的并发测试 d 应该考虑各种功能或是业务的异常情况 e 应该考虑系统用户界面的有好性及易用性 4 注意用例编写的正确性 按照需求规格说明书来进行用例编写工作 切忌不要异想天开的胡乱编写 编写出来的用例要具有指导性 5 需要符合正常的业务习惯 a 测试数据应该符合用户实际的工作业务流 b 应该考虑用户的使用习惯 测试用例需要设计到这方面的内容 6 测试用例数据与实际数据高度仿真 测试数据需要与实际用户的交互数据设计一致或达到高度仿真 比如电话号码 地址 用户名 密码等等 7 用例需要考虑到容错性 系统有数据交互的功能点必须考虑到程序的健壮性 用例设计应该考虑到非法输入 数据溢出等情况 测试用例设计需要关注的点 1 对功能的检查 a 功能是否齐全b 功能是否多余c 功能是否可以合并或细分d 业务流程和实际流程是否一致e 各个流程数据传递是否正确f 模块功能是否与SRS及概要设计相符g 键盘和鼠标的配合是否能完成所有操作 原则上需要界面支持全键盘操作 2 面向用户考虑 a 操作方便性 如按键次数是否最少 鼠标移动是否最短 展现的界面控件组合 排列是否合理b 易用性 好的软件是可以不需要用户手册的 简单易学也是测试用例考虑的范围c 智能化考虑 如智能提示 智能升级 智能容错等等d 提示信息简洁易懂 错误提示信息能简明阐述问题原因以及处理方法e 能否记录操作的初始环境 无需用户每次都进行初始化设置f 数据处理过