测试用例设计方法

黑盒测试测试的测试用例设计方法有 等价类划分 边界值划分 因果图分析 和错误猜测 在这里 主要讨论的是黑盒测试的测试用例的设计方法 一 等价类划分 等价列划分设计方法是把所有可能的输入数据划分成若干部分 子集 然后从每一个子集中选取少量具有代表性的数据作为测试用例 测试某等价类 的代表值就等于对这一类其他其他值的测试 使用等价类划分方法设计测试用例主要有两个步骤 1 确定等价类 2 生成测试用例 1 划分等价类 等价类划分有两种不同的情况 有效等价类代表对程序的有效输入和无效 等价类代表不正确的输入值 设计时要同时考虑这两种等价类 下面是确定等 价类的原则 1 在输入条件规定了取值范围的情况下 则可以确立一个有效等价 类 在取值范围之内 和两个无效等价类 小于取值范围和大于 取值范围 例如 使用手机发送短信的时候 短信内容长度必 须在 70 个字符之内 则有效等价类 短信内容长度在 70 个字符 之内 无效等价类 短信内容长度为 0 短信内容长度大于 70 2 在输入条件规定了取值的个数的情况下 则可以确立一个有效等 价类 在取值个数范围之内 和两个无效等价类 小于取值个数 和大于取值个数 例如 一名学生一个学期可以选修一至五门 课程 则有效等价类为 1 学生选修课程 3 列出覆盖上述等价类的测试用例 如下表 5 00 this width 500 border 0 例 现有一个学生标准化考试批阅试卷 产生成绩报告的程序 其规格说明如下 程序的输入文件 由一些有 80 个字符的记录组成 所有记录分为 3 组 如图 500 this width 500 border 0 1 标题 改组只有一个记录 其内容是成绩报告的名字 2 各题的标准答案 每个记录均在第 80 个字符处标以数字 2 该组的记录 第一个记录 第 1 3 个字符为试题数 1 999 第 10 59 个字符是 1 50 题的标准答案 每个合法 字符表示一个答案 第二个记录 是第 51 100 题的标准答案 3 学生的答案 每个记录均在第 80 个字符处标以数字 3 每个学生的答卷在若干个记录中给出 学号 1 9 个字符 1 50 题的答案 10 59 当大于 50 题时 在第二 三 个记录中给出 学生人数不超过 200 试题数不超过 999 程序的输出有 4 个报告 a 按学号排列的成绩单 列出每个学生的成绩 名次 b 按学生成绩排序的成绩单 c 平均分数及标准偏差的报告 d 试题分析报告 按试题号排序 列出各题学生答对的百分比 解答一 采用边界值分析方法 分析和设计测试用例 分别考虑输入条件和输出条件 以及边界条 件 下表列出了输入条件及相应的测试用例 500 this width 500 border 0 下表为输出条件及相应的测试用例表 500 this width 500 border 0 解答二 采用错误推测法还可补充设计一些测试用例 1 程序是否把空格作为回答 2 在回答记录中混有标准答案记录 3 除了标题记录外 还有一些的记录最后一个字符即不是 2 也不是 3 4 有两个学生的学号相同 5 试题数是负数 例 第一列字符必须是 A 或 B 第二列字符必须是一个数字 在此情况下进行文件的修改 但如果 第一列字符不正确 则给出信息 L 如果第二列字符不是数字 则给出信息 M 解 1 画出因果关系表和因果图 500 this width 500 border 0 2 根据因果图建立判定表 按条件的各种组合情况产生对应的动作 原因 1 和原因 2 不能同时成立 故可排除这种情况 从判定表可设计出测试用例 6 个测试用例是所需的数据 前言 根据详细设计文档编写测试用例的目的不在于验证软件达到的功能 而在于验证 软件应该达到的功能 这样可以去除软件开发过程中的随意性 1 目的 统一测试用例编写的规范 以保证使用最有效的测试用例 保证测试质量 2 范围 适用于公司对产品的业务流程 功能测试测试用例的编写 范围 适用于公司对产品的业务流程 功能测试测试用例的编写 3 功能测试用例编写原则 3 1 单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能 由于是单个模块所以无法检验关联性 可能会牵扯到数据库的操作 例如 删除时 需要 查看数据库是否完全删除了数据 3 2 集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时 模块的连接是否正确 及数据的传递 是否正确 我们的软件中体现出来的是 是否正确调用界面 界面之间显示的数据是 否正确 特别是财务方面的 集成测试用例的编写过程中 经常将功能用例与业务流程用例混合编写 因为在集成 测试时很难将两者分开 4 业务流程测试用例编写原则 业务流程测试用例编写原则 4 1 集成测试业务流程用例的编写目的 集成测试业务流程用例的目的与集成测试功能用例的目的基本一样 在于验证数据 的正确性 及界面之间的数据传递的准确 无误 4 2 系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性 我们的软件体现为 手工数据与报表数据的一直性 用例与用例之间有着一定的关系 目的性十分明确 5 测试用例设计的原则测试用例设计的原则 系统测试业务流程用例可以参考系统测试业务流程用例可以参考 5 1 全面性 指编写的测试用例应该覆盖所有的详细设计文档描述的功能 5 1 1 数据库程序基本的增 删 改功能 增 改测试用例重点在于数据合法性 正确性的检验和提示信息的正确性的 检验 输入的数据可能有无限种组合 此时可以采用等价类划分和边界值法 删除的测试用例比较简单 只有操作没有数据的输入 但是应该在备注中注明 删除的限制条件 以及数据库中应该删除的表的情况 有条件限制时 测试用例应该 包含各种删除条件 必要时在添加或修改的测试用例后面或中见 紧跟删除的测试 用例 5 1 2 对于无输入的操作 应该详细描述其具体的操作步骤和结果 例如 选择商品 可以 通过多种途径进行 此时应具体描述程序从何处进入 通过何种操作 达到商品界面 对于报表的测试用例 最好紧跟在输入数据的后面 并且应该给出报表输出的数据的 界面图 含数据 对于不便书写测试用例的情况 应该在备注中说明 并写出可能的操作步骤 例 如 对于文件夹的拖动 说明左右拖还是上下拖 结果如何就可以了 5 1 3 单元测试用例的书写是使用一条数据 多种可能的情况考虑 但是对于其余各阶 段的测试用例 必须考虑多条数据时的情况 此时主用是针对新增多条数据后 进行 删 改 拖等情况的考虑 5 1 4 应考虑存在跨年 跨月的数据 5 2 正确性 包括数据的正确性和操作的正确性 首先保证测试用例的数据正确 其次预期的输出结果应该与测试数据发生的业 务吻合 操作的预期结果应该与程序发生的结果吻合 5 3 符合正常业务惯例 测试数据应符合用户实际工作业务流程 实际就是测试用例的先后顺序 先新增 后修改或删除 不能将删除放在第一位 5 4 仿真性仿真性 人名 地名 电话号码等应具有模拟功能 符合一般的命名惯例 不允许出现与知名人士 小 说中人物名等雷同情况 5 5 可操作性可操作性 测试用例中应写清测试的操作步骤 不同的操作步骤相对应的操作结果不同 达到的目的是 任 何人 均可以根据测试用例 单独进行测试 6 测试用例设计的方法测试用例设计的方法 6 1 等价类划分法 6 1 1 确定等价类的原则 6 1 1 1 如果输入条件决定了取值范围 或值的个数 则可以确立一个 有效 等价类和两个无效等价类 6 1 1 2 如果输入条件规定了输入值的集合 或者规定了 必须如何 的条件 此时可确 立一个有效等价类和一个无效等价类 6 1 1 3 如果输入条件是一个布尔量 则可以确定一个有效等价类和一个无效等价类 6 1 1 4 如果规定了输入数据的一组值 而且程序对每个输入值分别进行处理 此时可 为每一个输入值确立一个有效等价类 此外 针对这组值确立一个无效等价类 它是所有不允许输入值的集合 6 1 1 5 如果规定了输入数据必须遵守的规则 则可以确立一个有效等价类 符合规则 和若干个无效等价类 从不同的角度违反规则 6 1 1 6 如果确知 已划分的等价类中各元素在程序中的处理方式不同 则应将此等价 类进一步划分成更小的等价类 6 1 2 测试用例的选择原则 6 1 2 1 为每一个等价类规定一个唯一的编号 6 1 2 2 设计一个新的测试用例 使其尽可能多的覆盖尚未被覆盖的有效等价类 重复 这一步 直至所有的有效等价类都被覆盖过 6 1 2 3 设计一个新的测试用例 使其仅覆盖一个尚未被覆盖的无效等价类 重复这一 步 直至所有的无效等价类都被覆盖为止 6 2 边界值分析法 6 2 1 测试用例的选择原则 6 2 1 1 如果输入条件规定了值的范围 则应取刚达到这个范围的边界值 以及刚刚超 越这个边界范围的值作为测试输入数据 6 2 1 2 如果输入条件规定了值的个数 则用最大个数 最小个数 比最大多 1 比最 小的小 1 的数作为测试输入数据 6 2 1 3 根据详细设计说明书的每个输出条件 使用前面的原则 6 2 1 4 如果程序的详细设计说明书给出的输入输出域是有序集合 则应选取集合的每 一个元素和最后一个元素作为测试用列 6 2 1 5 如果程序中使用了一个内部数据结构 则应当选择这个内部数据结构的边界上 的值作为测试用例 6 2 1 6 分析详细设计说明书 找出其他可能的边界条件 7 测试用例编写格式细则测试用例编写格式细则 7 1 测试用例内容 7 1 1 具体实施可以采用 EXCEL 和图形相结合 可用 EXCEL 编写测试用例的同时插 入图形来加以说明 测试用例设计的内容可由 模块名 功能说明或图形说明 测试用例输入 应输出结果 实际输出结果 结论 BUG 编号 BUG 级别 8 部 分组成 7 2 测试用例表格格式 7 2 1 表格内容的字体为宋体 7 2 2 表格内容的字型为 12 号 8 BUG 级别级别 致命 严重 一般 测试用例的设计一般从分析需求设计说明书开始 了解开发人员设计这个 项目的思路 设计的要求 实现的功能等 最好有 use case 这样看起来更清 晰 软件测试的 W 模型 就要求测试与开发同步 在开发设计需求设计说明 书的时候就开始测试流程 一般情况下 讨论需求设计的时候需要测试主管或 者组员的参与 了解这个项目设计的总体情况 事实上 测试用例的编写一般 是在需求设计说明书定下来之后才真正的开始的 因为测试用例的内容要以需 求设计说明书为依据 设计说明书上没体现的功能 不需要在测试用例中体现 编写测试用例 这里指功能测试用例的编写 首先要做的就是设计测试 用例的模板 每个公司都有适合自己公司用例编写的模板 各有各的特点 测 试用例的格式包括 测试用例摘要 测试用例需求编号 一个需求设计说明书 可以分好几个用例编写 编写用例的日期 编写人员 编写日期 前置条件 准备数据等等 格式没有固定的要求 可以根据自己测试用例设计的思路 对 测试用例的格式作相应的改变 下面以一个登陆窗口为例 说说我设计登陆界 面的思路和方法 我把这个测试用例分为三层结构 表单测试 逻辑判断 业务流程 第一层 表单测试为最底层 最基础的 这部分的测试用例是对登陆窗 口这个界面的输入框 按钮功能 界面等最基本功能的测试 一般来说登陆用 户名和登陆用户密码是输入框的形式体现 那么 我们需要的是针对这两个输 入框进行功能的测试 这时 我们只要考虑这个输入框的功能 而不需要考虑 业务方面的内容 这样 我们考虑就是这个输入框的长度限制是多少 能否输 入特殊字符 能否输入全角字符 当然 登陆窗口还有其他按钮 例如登陆按 钮 退出按钮 界面设计等 这一层的测试用例只对他们最简单的功能的测试 我觉得这一层的测试用例对新开发项目很重要 也必须执行 因为这些是最基 本的功能保证 当项目进入维护阶段后 如果没有修改就不需要执行这部分的 测试了或者说把这层的用例优先级置为最低 时间不充足的情况就不用去执行 第二层 逻辑判断层 根据需求的设计 各功能之间的简单逻辑联系 以 登陆窗口为例 账号登录 账号和密码必须对应才能登录 否则登录失败 根 据这一点 我们就可以从这个要求设计这一层测试用例 例如 账号和密码不 一致时 账号为空时 密码为空时 账号密码对应时等等情况 输入这些情况 时 程序是作怎么样的逻辑控制的 控制是否正确 是否有相应的提示信息 我觉得 这一层的用例时最常规的一层 平时使用这个软件用经常碰到的一些 情况 在常规测试或修改这部分的功能之后 这一部分的测试用例也必须执行 第三层 业务流程层 这部分不关心软件的本身的基本功能 而是关心这 个软件的业务有没有实现 不同的需求就有不同的业务需求 以登陆窗口为例 就可能有不同的需求 可能用户要求停用的账号能够登录系统 可能要求登录 后不允许进行其他操作 也可能用户直接要求停用的用户账号不准登录系统 根据不同的业务需求 就有不同的业务流程 这样这层的测试用例 我们就只 要