测试用例设计技巧

浅说 测试用例 给测试新手的 在此之前我搜集一些关于测试用例的知识 后来在我们的 QQ 群里专门定了一期讨论 来探讨测试用例 毕竟这是一个很大的话题 很难做到面面俱到 但我会尽量全面 用 通俗的语言来说测试用例 注 我们这里要说的测试用例指功能测试用例 一 什么是测试用例 一 什么是测试用例 测试用例是为某个特殊目标而编制的一组测试输入 执行条件以及预期结果 以便测试 某个程序路径或核实是否满足某个特定需求 通俗的讲 就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来 二 写测试用例有什么好处 二 写测试用例有什么好处 理清思路 避免遗漏 这里是我们认为最重要的一点 假如我们测试的项目大而复杂 我们可以把项目功能 细分 根据每一个功能通过编写用例的方式来整理我们测试系统的思路 避免遗漏掉要测 试的功能点 跟踪测试进展 通过编写测试用例 执行测试用例 我们可以很清楚的知道我们的测试进度 历史参考 在我们所做的项目中 也许会有很多功能是相同或相近的 我们对这类功能设计了测 试用例 便于以后我们遇到类似功能的时候可以做参考依据 重复性 我们测试一个系统不是一个人测一遍就算测完的 需要多人反复的进行测试 那么我 们就需要测试用例来规范和指导我们的测试行为 告诉领导 这事俺干过 不然别人怎么知道你测没测 测的全面不全面 拿测试用 例给他们看呗 俺就是照着这个干活 呵呵 三 测试用例的方法三 测试用例的方法 好吧 咱知道啥是测试用例了 也是知道为什么要写测试用例了 那到底应该怎么写 无从下手啊 我们在写测试用例之前 先学习几种方法 它是我们写测试用例的指导思想 1 等价类划分 在某个输入域的子集合 在该子集合中 各个输入数据对于揭露程序中的错误都是等 价的 假如有一个输入框要求输入 1 10000 个数 我们不可能用每一个数去试 我们输入 5 和输入 6 去验证和揭露输入框的错误可以看做是等价的 那么这个时候我们就可以随机 的抽取一些数据来进行验证 如 10 99 7777 等价类分 有效等价类和无效等价类 输入框要求输入 1 10000 的数 有效等价类 可以输入 1 10000 之间的数来验证 如 2 5 99 8495 无效等价类 可以输入 1 10000 之外的任意字符验证 如 20000 字母 下划线 特殊符号 空格 回车 2 边界值 边界值是对等价类的补充 测试工作经验告诉我们 大量的错误是出在输入输出的边 界价上 我们还拿上面的例子 一个输入框要求输入 1 10000 之间的数 我们要测它有没 有超出这个范围 如 0 1 2 1000 10001 等等 来判定是否超出了我们的范围 3 因果图 因果图方法最终生成的就是判定表 它适合于检查程序输入条件的各种组合情况 举 个例子 原因 A 0 B 0 结果我就可以判定 A B 确切的说他是一种因果关系思想 它 会无形中指导这我们的测试 当然了 我们为了以免遗漏 可以把系统中的因果关系用图 画出 不过系统大而复杂的话就是个体力活了 呵呵 4 错误推测法 基于经验和直觉推测出系统可能存在的错误 从而有针对性的设计测试用例的方法 5 其它 设计测试用例的方法有很多 我们常用就上面几种 其它的方法还有 状态迁移图 流程分析法 正交验证法等等 四 测试用例的格式与要素四 测试用例的格式与要素 一个测试用例应该包括 编号 标题 测试场景 测试步骤 预期结果 当然还可加入一些它选项 如 优先级 测试阶段 注 上面的格式取自 微软的软件测试之道 它并不一定适合你 我只是让大家对测试 格式有个了解 关于测试用例的存放管理 1 项目管理系统自带的用例管理 一般用例会与项目挂钩 有固定的格式 搜索 修改等 功能 使用起来非常方便 如 禅道项目管理 QC bugfree 等等都带的有用例管理功能 2 通过 world Excel 文档形式管理 这样的好处就是自己定义测试用例的格式 测试用例例子 基础知识了解的差不多了 下面来看一个具体的测试用例 我们会有更深刻的认识 注 这不是一个完整的测试用例 格式也不是固定必须这样的 你们可以根据自己的需求 编写设计测试用例 我们还需要知道的 关于测试用例的 一 我们在什么时候可以设计测试用例 当根据客户的需求整理出项目需求分析文档时 我们就可以根据需求文档来编写测试用 例了 但是 一般我们 国内大多小公司 项目需求文档都非常 简陋 所以 很难根据 需求文档设计测试用例 我们只有等到项目开发人员把项目开发出来 给我们系统文档 部署环境 数据库结构 如果系统牵涉到数据库的话 我们根绝这些文档来设计测试用例 二 测试用例的评审与更新 我们设计的测试用例设计完成之后 是否完整 是否符合系统 符合客户要求 对用例 做一个评审是必不可少 关于评审的方式 不同的公司有不同的流程 我们编写的测试用例也不是经过评审之后就不变了 随着需求的变更 功能的改进 测 试用例当然也需要更新和变动 三 什么情况下不适合写测试用例 文件时间 如果一个功能我很快就测试完了 而且只需要测试一遍 但我们设计测试用例时却比 较麻烦 花时间也长 这个时候就没必要编写测试用例了 需求变动大且频繁 需求的功能变动非常频繁 而且变动很大 之前编写的测试用例根本没法使用 必须 要重新编写 这个时候也没必要去设计测试用例了 项目时间不允许 这一项是不太厚道的做法 如果不是急需交付客户的话 尽量不要这样做 当然了 如果只是给客户展示或试用 可以在之后进行补充和完善测试用例 不要编写不完整或别人看不懂的测试用例 那样就没有意义了 个人闲聊内容 欢迎指正 四 停止软件测试的标准 语句覆盖最低不能小于 80 测试需求覆盖率达到 100 测试用例覆盖率达到 100 一 二级缺陷修复率达到 100 三 四级修复率达到 80 上面一句是再网上找的 不是标准 只是个参考 bug 等级 一级 非常严重的 bug 二级 严重的 bug 三级 一般性的 bug 四级 建议性问题 五 关于探索性测试 完全的执行测试用例时一件非常枯燥的事情 个人在执行测试用例时会做一些 其它 的非常规性的操作 看系统是否会有相应的处理和提示 我的一部分 bug 就是再这种非常 规操作下发现的 当然了真正的探索性测试需要对产品的深入了解 以及软件开发技术有一定的深度和 宽度 姑且把我们的探索性测试看成是瞎捣鼓吧 呵呵 六 交叉测试 有木有发现 当我们第一遍测试系统时 会非常认真 但要我们测试第二遍时 我们不 愿意像第一次那样认真的去测了 这不能说明我们不负责 而是每个人都有的心理现象 这个时候 我们可以和其它测试人员交换功能来测试 提高效率 而且更容易发现问题 七 测试的目的 1 我们让它做的它必须会做 2 我们不让它做的它必须不会做 可能你会发现有附加功能的时候 就是客户没有要求 我们加了这样的功能 可能加了 这点功能系统看上去会更好 这时怎么办 算问