软件测试课程论文

软件质量保证与测试技术 1 浅谈软件测试用例的设计 摘要摘要 软件测试在软件工程管理中所占比重越来越大 测试用例的设计是整个测试过程的基础 本文介绍了软件测试用例 的重要性和对软件发展的影响 详细介绍了软件功能测试用例的设计 并举例说明了如何应用白盒测试技术和黑盒测试 技术 关键词关键词 测试用例 白盒测试 黑盒测试 The design of software test case Abstract Software testing in software engineering management accounts for the proportion is more and more the test case design is the foundation of the whole testing process This paper introduces the importance of software test case and influence on the development of the software test case design process are introduced in detail and an example is given to illustrate how to apply black box and white box testing techniques Key words Test cases white box testing black box testing 1前言 软件测试是软件生存周期的一个重要组成部分 重视程度越来越高 软件测试是用来验证软件是否 能够完成所期望功能的唯一有效的方法 测试已不仅仅局限于软件开发中的一个阶段 它已开始贯穿整 个软件开发过程 进行测试的时间越早 整个软件开发成本下降就越多 软件测试用例就是设计一种 情况 软件程序在这种情况下 希望能够正常运行并且达到程序事先所设计的执行结果 测试用例由测 试输入数据和预期的输出结果两部分组成 软件测试用例的设计和执行是软件测试工作的核心 也是工 作量最大的任务之一 良好的测试用例设计过程能够提高测试用例的设计质量 便于跟踪测试用例的执 行结果 自动生成测试用例覆盖率报告 本文结合工作实践 阐述了应用白盒测试技术和黑盒测试技术进 行测试用例设计的方法 并对一些问题进行了详细的分析 2软件功能测试用例的设计 软件功能测试是对软件系统最基本的一类测试 功能测试用例即指软件产品在交付于用户前对其是 否达到事先所定义的用户需求规格说明书上说指定的产品功能要求进行测试的测试用例 它是站在用户 角度上 也是较重要的一类测试用例 2 1 设计原理 测试用例由测试输入数据和预期的输出结果两部分组成 在设计测试用例的输入条件中应包括合理 的输入条件和不合理的输入条件 人们往往倾向于过多地考虑合法的和期望的输入条件 以检查程序知 否做了它应该做的事情 而忽视了不合法的和预想不到的输入条件 如果开发出的软件遇到非法情况不 能做出适当的反应 会导致软件的失效 用不合理的输入条件测试程序时 会比合理的输入条件进行测 试能发现更多的错误 所以就软件功能测试而言 测试用例设计要从 4 个方面考虑 1 系统功能是否符合需求说明 2 系统功能是否完善 软件质量保证与测试技术 2 3 系统功能是否有作用 4 系统功能是否无错误 2 2 设计方法 测试用例的设计和编制是软件测试活动中最重要的 测试用例是测试工作的指导 是软件测试的必 须遵守的准则 更是软件测试质量稳定的根本保障 测试用例设计的目的就是将系统需求具体化 提取测试需求 通过可测试的方法对每个功能点进行 描述 测试用例设计的好坏直接关系到测试质量的高低 用最少的测试用例覆盖最全的功能点是测试用 例设计的目标 在测试用例的设计过程中 应用一个有效的测试用例模板对用例的管理 测试的执行具有十分重要 的作用 2 3 功能测试用例组成要素 1 用例场景 描述该测试用例所验证的需求用例 通常一个需求用例与多个测试用例对应 对每 个需求用例 有时可能需要两个或多个测试用例与其对应 一个测试用例描述正常工作流情况 另一个 或多个描述异常处理工作流 通常异常工作流的测试用例往往是正常工作流测试用例的几倍 2 测试用例序号 每个测试用例都有一个惟一的序列号 用于标识 3 测试用例描述 对测试内容的简单描述 让阅读者能够很快对这个测试用例有个大概的了解 4 前置条件 描述执行该测试用例需要满足什么条件 5 步骤 实现测试用例的各个操作 6 预期结果 每个测试步骤执行之后的预期结果 是建议需求验证是否被通过的标准 预期结果不 是在测试执行当中才被考虑的 应该在测试用例设计阶段由需求分析推导而得 7 注释 填写测试中应当注意的问题或者说明 注释不是必须填写的列 而其他列则是必须要填写 的 8 真实结果 每一个发布版本对应真实结果的一列 这一列里填写测试的真实结果 通过 失败 不 可测 跳过 如果测试用例执行失败 需要填写失败的详细结果 以及对应的缺陷号 注 真实结果 也可以在相应的测试报告中填写 3 白盒测试下的各种测试技术 白盒测试是根据程序的内部逻辑设计测试用例 常用的技术是逻辑覆盖 即用测试数据运行被测 程序时对程序逻辑的覆盖程度 主要覆盖标准有六种 语句覆盖 判定覆盖 条件覆盖 判定 条件覆 盖 条件组合覆盖 路径覆盖 白盒测试的优点是清楚所设计的测试用例在代码级上哪些地方被忽略 掉 帮助增大了代码的覆盖率 提高代码的质量 发现代码中隐藏的问题 缺点是程序运行时有很多 不同的路径 不能对其全部测试 而且测试基于代码 只能测试开发对错 而不能知道设计正确与否 就会漏掉一些功能需求 当系统庞大时 测试开销会非常大 图 1 为一个子程序的流程图 应用白盒测试技术对此子程序进行测试用例设计 软件质量保证与测试技术 3 1 应用语句覆盖技术 即每一条语句均执行一次 测试用例设计为 X 4 Y 2 Z 0 预期结果 X 3 2 应用判定覆盖技术 即每个判定的所有可能结果至少出现一次 根据图 1 选择测试路径 sacbd 和 sabed 下面两个测试用例可满足判定覆盖标准 测试数据 X 3 Y 3 Z 0 预期结果 X 1 执行 sacbd 路径 判定 a 为真 判定 b 为假 测试数据 X 1 Y 2 Z 1 预期结果 X 2 执行 sabed 路径 判定 a 为假 判定 b 为真 3 应用条件组合覆盖技术 即每个判定中条件结果的所有可能组合至少出现一次 图 1 的例子中 判定 a 中条件结果所有可能组合有 Y 1 Z 0 Y 1 Z 0 Y 1 Z 0 Y 1 Z 0 判定 b 中条件结果所有可能组合有 Y 2 X 1 Y 2 X 1 Y 2 X 1 Y 2 X 1 可以通过下面四个测试用例来满足条件组合覆盖标准 测试数据 X 4 Y 2 Z 0 预期结果 X 3 执行 sacbed 路径 覆盖条件组合 测试数据 X 1 Y 2 Z 1 预期结果 X 2 执行 sabed 路径 覆盖条件组合 测试数据 X 2 Y 1 Z 0 预期结果 X 3 执行 sabed 路径 覆盖条件组合 测试数据 X 1 Y 1 Z 1 预期结果 X 1 执行 sabd 路径 覆盖条件组合 通过应用不同的测试技术分析 可看出语句覆盖是一种很弱的覆盖标准 由于条件组合覆盖使每个 判定中条件结果的所有可能组合都至少出现一次 因此判定本身的所有可能结果也一定至少出现一次 同时也使每个条件的所有可能结果至少出现一次 条件组合覆盖是白盒测试前五种覆盖标准中最强的一 种 但也不能保证程序中所有可能的路径都覆盖 上述测试用例就没有经过 sacbd 路径 应用时要根据 软件质量保证与测试技术 4 实际需求和测试重点 选择合适的测试技术 提高测试有效性 4 黑盒测试 4 1 特点 黑盒测试是根据规格说明书所规定的功能来设计测试用例 不考虑程序的内部结构和处理过程 常 用的黑盒测试技术有等价类划分 边值分析 错误猜测 因果图等 整个测试基于需求文档 看是否能 满足需求文档中的所有要求 黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或 经验 适用于对系统的功能进行测试 黑盒测试的优点是比较简单 不需要了解程序内部的代码及实现 与软件的内部实现无关 从用户角度出发 且是基于软件开发文档 也能知道软件实现了文档中的哪些 功能 在做软件自动化测试时较为方便 黑盒测试的缺点是覆盖率较低 自动化测试的复用性较低 4 2 应用实例分析 下面以一个系统登录界面为被测对象 应用黑盒测试技术进行测试用例设计 1 实现功能 用户在浏览器地址栏输入相应地址 显示系统登录界面 输入用户名和密码 点击登录 系统自动 校验 给出相应提示信息 如果用户名或者密码任一信息未输入 登录后 系统给出相应提示信息 连 续三次未通过验证 自动关闭浏览器 2 设计输入信息 设计输入信息可包括用例名称 功能描述 用例入口及其他参考信息等 系统登录用例的设计输入 信息如表 1 所示 表 1 系统登录用例设计输入信息 用例 ID用例名称用例描述用例入口 1 系统登录用户名存在 密码正确的情况下 进入系统 页面信息包括 页面显示用户名和密码录入接口 输入数据后的登录系统 接口 打开浏览器 在地址栏输入相 应地址进入该系统登录页面 或运行操作路 3 设计测试用例 根据功能需求和详细设计说明 设计测试用例 如表 2 所示 测试用例的设计根据功能需求进行设计 用例之间不重复设计 专为特殊目标和功能而编制 每组用例都包括测试输入 测试步骤和预期结果 通过执 行测试用例来测试程序路径 核实其是否满足特定需求 测试用例的设计原则更趋向于针对软件产品的功能 业务规则和业务处理 因此对软件的每个特定功能径的测试构成了一个个测试用例 测试用例的设计数量取 决于其是否完成了功能需求的测试 是否完成了路径的测试 软件质量保证与测试技术 5 表 2 系统登录测试用例表 用例编号测试标题测试步骤预期结果备注 1 初始页面显示从测试用例入口处进入页面元素完整 显示界 面与详细设计一致 2 用户名录入 验证输入已存在的用户名 testcase 输入成功 3 用户名容错性验证输入 xxxxyyyyyzzzzzaaad 输入到下划线显示的字 符时 系统拒绝输入 输入数据超过规定 长度范围 4 密码 密码输入输入与用户名相关联的数 据 testcase 输入成功 5 系统登录 成功测试第二和第四个测试用 例通过后单击登录按钮 登录系统成功 6 系统登录 用户名 密码校验 没有输入用户名密码单击 登录按钮 系统登录失败 并提示 请检查用户名和密码输 入是否正确 用户名和密码不能 为空 7 系统登录 密码校验输入用户名 没有输入密 码单击登录按钮 系统登录失败 并提示 请输入密码 8 系统登录 密码有效 性 输入用户名 输入密码于 用户名不一致单击登录按 钮 系统登录失败 并提示 错误的密码 9 输入有效性验证输入不存在的用户名 密 码 单击登陆按钮 系统登录失败 并提示 用户名不存在 10 安全校验连续三次未登录成功系统提示 您没有使用 该系统的权限 请与系 统管理员联系 5 设计测试用例应注意的问题 测试工作实际上需要考虑两方面 一方面是正常调用的测试 也就是看程序是否能在正常调用下完 成基本功能 是最基本的测试职责 第二方面就是异常调用的测试 比如用户潜在的异常输入情况下的 测试 整体系统局部故障情况下该模块受影响状况的测试 频发的异常请求阻塞资源的模块稳定测试等 认识每段代码任务在整体项目中的地位和各种性能需求 有针对性的进行相关测试 并尽早发现和解决 问题 不同类别的软件 测试用例是不同的 针对诸如系统 工具 管理软件等的用户需求不统一 变化 更大 更快 因此要把测试数据和测试脚本从测试用例中划分出来 对于每个测试需求 在测试用例中都要考虑正面测试和负面测试条件下的测试 正面测试用于核实 行为是否正确或符合预期要求 负面测试用例代表不可接受的 异常的或意外的条件 它可用于核实测 试需求是否以非预期方式执行 对于测试的每个需求来说 至少要有一个正面测试用例和为数较多的负 面测试用例 以此来检查在异常情况下系统能否正常处理 或者用户进行了错误的操作时的友好提示等 每个测试用例必须清楚地阐述正在进行评估的用例 用例场景 测试目标或条件和预期结果 测试 用例在设计编制过程中要组织同级互查 完成编制后应组织评审 需获得通过才可以使用 软件质量保证与测试技术 6 测试的每个环节都要产生相应文档 测试计划 测试用例 测试报告 这三份文档成为最基本的资 源 应清晰表达意图 使得工作可见而且可控 6 结束语 影响软件测试的因素很多 例如软件本身的复杂程度 开发人员的素质 测试方法和技术的运用等 因为有些因素是客观存在的 有些因素则是波动的