测试设计和开发

《测试设计和开发》由会员分享，可在线阅读，更多相关《测试设计和开发（34页珍藏版）》请在金锄头文库上搜索。

1、1软 件 测 试 技 术2第三章 测试设计和开发 3.1 测试设计流程 3.2 总体设计 3.3 开发测试用例 3.4 评审测试用例33.1 测试设计流程测试设计活动的输入是测试计划，测试计划应该 说明将用到的方法和测试工作的范围。 测试设计活动的输出是将在系统测试和确认测试 中使用的评审过的测试用例集合。43.2 总体设计 定义设计目标清楚地说明每项测试的目标使每项测试的目的单一，可以对应到规格说明书中 的一项需求 只说明测试将完成什么工作，而不是说明如何完成定义输入说明 定义测试环境和配置 编写测试设计文挡53.3 开发测试用例什么是测试用例？ 测试用例是为特定目标开发的测试输入、执 行条

2、件和预期结果的集合。 3.3.1 了解测试用例什么是好的测试用例？ 好的测试用例必须清晰地定义一个或多个期 望的结果和测试通过和失败标准。 好的测试用例应该容易发现软件错误、且有 可重复性、没有冗余。6测试用例的作用 指导测试的实施 作为编写测试脚本的“设计规格说明书” 评估测试结果的度量基准 分析缺陷的标准7什么是测试过程？ IEEE将测试过程定义为“说明执行一系列测 试用例的步骤。 测试过程是为了评估一系列功能而进行软件 项分析的步骤” 。3.3.2 定义详细测试过程测试用例和测试过程的区别？测试过程是由一系列的测试用例组成的。 83.3.3 定义预期结果 测试过程的每一步都需要明确预期的

3、结果。 预期结果的来源： 项目专家或其他方面的专家将知道如何确定 输出结果 用户文档可以包含一些用户场景范例 需求文档也可以提供必要的信息 其他相关文档也可以提供相关线索 最终用户也许能够描述所期望的响应结果9测试用例文档由简介和测试用例两部分组 成。简介部分描述了测试目的、测试范围 、定义术语、参考文档、概述等。测试用 例部分逐一列示各测试用例。 测试用例的基本元素：测试索引，测试环 境，测试输入，测试操作，预期结果，评 价标准。3.3.4 测试用例内容10最简单的测试用例也将包含：用例编号、 输入、期望结果、实际结果。 测试用 例ID输入预期结果实际结果测试统计利率贷款 期限 (年)贷款

4、金额 (元)月 支 付总 支 付总 利 息月 支 付总 支 付总 利 息通过 /失 败测试 日期测试 人员TC- 0018%3080000587.01TC- 0028.5%3080000615.13TC- 0038.5%1580000787.7911测试的一项基本原则是：被测试的系统始 终应该处于一种已知的状态。因此测试用 例往往需要说明初始条件。说明测试用例ID： TC-001 软件版本： 子系统： 用户名字段测试 操作系统： 测试人员姓名： 测试日期： 初始设置1打开注册会话框2在用户名字段放入字符“王”3确保所有其他输入字段为空输入1将光标置于用户名字段2输入字符“帅”预期结果用户名字段

5、出现字符“王帅”实际结果 通过 失败3.3.5测试用例设计的基本原则 测试用例的代表性：能够代表并覆盖各种合理 的和不合理、合法的和非法的、边界的和越界 的、以及极限的输入数据、操作和环境设置等 ; 测试结果的可判定性：即测试执行结果的正确 性是可判定的，每一个测试用例都应有相应的 期望结果； 测试结果的可再现性：即对同样的测试用例， 系统的执行结果应当是相同的。123.3.6测试用例的特征最有可能抓住错误的；不是重复的、多余的；一组相似测试用例中最有效的；不要太简单，也不要太复杂。1314测试用例越详细越好？15时间要求 测试时间是否充足？ 执行者 测试执行者对系统的了解程度？ 建议程度 将

6、测试用例交给其他人执行时不需要 过多的解释。16样例 登录需求： 用户名长度为6至10位（含6位和10位） 用户名由字符（a-z、A-Z）和数字（0-9）组 成 不能为空、空格和特殊字符 密码规则同用户名规则17简单 能够正确处理用户登录一般 输入正确的用户名和口令可以进入系统 输入用户名或口令错误无法进入系统18详细操作步骤预期结果 输入正确的用户名和口令（均为6位），点击OK按 钮进入系统输入正确的用户名和口令（均为10位） ，点击OK 按钮进入系统输入正确的用户名和口令（均为6至8位之间）， 进入系统用户名为空，提示输入用户名 不能进入系统 用户名为空格，提示无效用户名 不能进入系统 用

7、户名小于6位，提示用户名太短 不能进入系统 3.3.6测试用例的组织和跟踪19在执行测试过程中，会遇到如下问题：计划执行哪些测试用例？执行需要多 少时间？一轮测试需要多少测试人员？能否挑出测试套装（相关测试用例子 集）来测试某些特性或软件部分？在执行测试用例时，能否记录哪些通 过？哪些失败；当前测试是否按计划进行？上次执行测试用例时通过的百分比是 多少？测试用例跟踪管理方式：测试用例追踪表20如果没有测试用例或者仅有简单的测试 功能描述，测试过程难以控制，测试结 果将毫无可靠性可言。 简单的测试用例可靠性低，重用性差， 可能导致不同人员理解不同。 详细的测试用例可靠性高，而且便于估 计执行所需

8、时间，易于控制。3.3.7 测试用例参数化21定义 参数化 是一个将测试数据与测试逻辑（步骤 ）分开，简化测试用例的过程； 方式是将用例中的一些输入、输出等 作为参数，数据则单独列出，在执行 时选择相应的数据执行。22为什么要参数化？ 没有将测试数据和测试逻辑分开的测试用 例可能显得非常庞大，不利于测试员理解 ，导致难以控制和执行； 通过将用例参数化，可以简化用例，使测 试用例逻辑清晰，数据与逻辑的关系明了 ，易于理解； 有利于提高测试用例的复用性；23哪些内容需要参数化？ 测试用例中需要通过使用不同数据来 重复执行测试的部分； 包括：输入（数据或操作等）输出（结果数据或预期结果等）24样例

9、登录步骤： 1、输入 2、输入 3、点击OK按钮结果： 25测试数据（一） “用户名”“口令”“预期结果”说明“user10”“pass10”进入系统正确的用户名和口令(6位)“user789”“pass789”进入系统正确的用户名和口令(7-9 位)“user000010”“pass000010”进入系统正确的用户名和口令(10 位)“”“pass”提示输入用户 名 不能进入系统用户名为空“空格”“pass”提示无效用户 名 不能进入系统用户名为空格26测试数据（二） “用户名”“口令”“预期结果”说明“user”“userpass”提示用户名太 短 不能进入系统用户名小于6位“user00

10、00011 ”“userpass”提示用户名太 长 不能进入系统用户名大于10位273.3.8 测试用例的意义使用测试用例的好处主要体现在以下几个方面： 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。 功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。 组织性有利于测试的组织； 功能覆盖确保功能不被遗漏； 重复性有利于测试的重复； 跟踪有利

11、于测试的跟踪； 测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；28293.3.9 黑盒测试与白盒测试比较黑盒测试主要是为了发现以下几类错误： 是否有不正确或遗漏的功能？ 在接口上，输入是否能正确的接受？能否输出正确的结 果？ 是否有数据结构错误或外部信息（例如数据文件）访问 错误？ 性能上是否能够满足要求？ 是否有初始化或终止性错误？30白盒测试则被程序员用来对程序模块进行检查，在检 查的过程中： 对程序模块的所有独立的执行路径至少测试一次 对所有的逻辑判定，取“真”与取“假”的两种情况都能至少 测试一次 在循环的边界和运行界限内执行循环体 测试内部数据结构的有效性31测试方

12、式特征依据测试人员测试驱动程 序 黑盒测试只关心软件的外 部表现，不关 心内部设计与 实现。软件需 求任何人（包 括开发人 员、独立 测试人员 和用户）一般无需编 写额外的 测试驱动 程序白盒测试关注软件的内部 设计与实现， 要跟踪源代码 的运行。设计文 档由开发人员 兼任测试 人员的角 色需要编写额 外的测试 驱动程序32白盒测试黑盒测试程序结构已知程序结构未知程序结构规模小规模测试大规模测试依据详细设计说明需求说明、概要设计说明面向程序结构输入输出接口/功能要求适用单元测试组装、系统测试测试人员开发人员专门测试人员/外部人员优点能够对程序内部的特定部 位进行覆盖能站在用户的立场上进行测试缺点无法检验程序的外部特性 不能检测对要求的遗漏不能测试程序内部特定部位 如果规格说明有误，则无法发 现333.4 评审测试用例复查测试用例时应该考虑的一些问题： 测试或测试组件完全针对的是需求中列出的功能 吗？ 测试组件是否覆盖了所有需求？ 有冗余的测试吗？ 每一个测试步骤都有清楚描述的预期结果吗？ 测试用例是否考虑了有效和无效的输入情况？34测试用例的优先级定义测试用例优先级主要考虑：必须测试什么功能 ？如果一些功能没被测试会出现什么后果？ 优先级1：这个测试必须执行 优先级2：如果时间允许，执行这个测试 优先级3：即使不执行这个测试，也不会导致大 的质量问题