测试设计方法.doc

测试设计方法 stpe4011 version 1.0 25-1 sk u- _ 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page ii 使用权限使用权限 本文档只限 skc&c内部使用. 本文档的制作, 检查, 审批原件要保存 制作人制作人:金东旭（译）日期日期: 审核人审核人:尚彦学日期日期: 文档在skc&c内部的业务活动中使用。 审批人审批人:日期日期: 更新日志更新日志 1.0定义2003/11/01 更新编号更新页及内容制作日期 目录目录 1.序文序文.1 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page iii 1.1.目的目的 1 1.2.参照参照 1 2.设计向导设计向导.1 2.1.数据设计数据设计 1 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 1 1.序文序文 1.1.目的目的 已当前业务的需求定义结果为基础根据测试目的的不同开发测试case和测试数据。 提供详细的资料和执行测试计划 并且为了在同一标准下进行作业将向导想全体成员共 享. 1.2.参照参照 无 2.设计向导设计向导 2.1.数据设计数据设计 (1) 概要 已当前业务的需求定义结果为基础根据测试目的的不同开发测试case和测试数据 。 提供详细的资料和执行测试计划. 所有测试设计里面要 描述测试目的，期待结 果，测试对象程序功能及结果。 应用程序开发相关的测试设计步骤如下. -定义程序测试环境. -设计单元及集成测试. -设计系统测试. -设计uat. -定义测试资源需求. -检查测试设计. 测试设计步骤如下. 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 2 图图 1) 测试设计步骤测试设计步骤 (2) 设计 考虑事项 测试 设计时考虑项. -测试示例里面要包含期待的测试结果. 如果期待的测试结果没有问题也不能 保证其正确性。 -程序要不能由开发者或程序的运营部门的人来测试。程序开发者的目的是让 程序顺利运行，程序测试的目的是找出程序的错误。要意识到找出自己制作 或运营的程序中找到错误是很困难的。 -所有测试结果要仔细调查。偶尔会产生新的错误。 -制定不仅仅是正常的还有非正常的不明确的结果的测试用例。程序在正常的 环境下可以运行是否正常的确认之外，还要考虑程序在非正常环境下运行的 结果。 -不能假设没有错误。测试的目的是发现错误而不是描述程序功能. 成功的测试 用例是发现没有发现的错误。 (3) 设计 构成要素 测试设计要包含下列构成要素 测试目的 各 测试事件类别要测试什么要明确定义. 测试目的里面要描述要测试 的功能 及状态, 要符合上层的期待结果。考虑下列事项。 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 3 测试目的根据测试功能和测试事件的不同而不同。举例来说, 集成测试的 目的包含功能测试和功能间的接口测试。项目期间的风险评价对测试目的 地定义很有帮助。举例来说, 新技术的采用是为了测试这种新技术. 测试目的要与应用系统需求或系统设计相关联。根据测试目的不同，投入 测试的程度不同，测试目的要有客户和信息系统关联部门来检查。 测试时间的缩短，首先要给测试目的排好顺序。即不能完全测试的情况下 测试最重要的部分。 测试示例 测试示例里要把输入资料，预想结果，测试执行环境文档化。 测试示例设计 的 测试目的 及 测试技术为根据。这样的测试 示例可以重复，可统计，可记 录。而且将测试示例组化成可管理的单位. 这个是在测试阶段可以快速发现错 误的方法, 将关联的目的示例分组. 举例来说, 所有会员处理(例, 确认会员数, 追加的2次会员数的判定等)的 测试目的找出这样的活动之间的作用间错误， 通过执行一个测试循环。 测试team 组织 各 测试类别定义和描述测试team 的角色及责任. 为了执行这些角色有必要描 述描述责任和技术层面的角色/责任 矩阵并得到测试执行者的确认。 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 4 图图 1) 角色及责任矩阵角色及责任矩阵 12345 sp ssppp sppp sps ssspp ssspp ssssp ssps ssspp sssp ps 1: 2 : 3 : 4 : 5 : p : (primary) s : (secondary) 测试 脚本 意味着在线及一起处理测试进行的详细描述文档. 脚本里面将测试时执行的阶 段及示例文档化。举例来说, 测试脚本里面输入什么信息, 期望得到什么结果 的描述。脚本的目的是将测试分阶段让测试可持续有效的执行。 测试 过程 测试关联的所有假设(assumption)的记录, 测试示例里面文档化。要在测试战 略设立之前定义，在战略开发后要在测试设计里面反应. 假设里面包含机械性 能，测试环境等主要的假设。 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 5 (4) 测试 事件 什么测试事件为了什么程序的执行制定，各事件特征要对应测试 设计. 各测试 事件特征如下。 单元测试 事件 单元测试的焦点是程序或系统的小模块。这个是为了测试模块是否与功能要求 相对应。单元 测试在程序代码的检查后执行。 使用测试 示例的定义的数据， 测试各个模块, 比较期待结果和测试结果后记录. 如果符合期待结果的话进入 到开发库。 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 6 集成 测试 事件 集成测试是发现个别单元 测试执行后即成后出现的问题执行的行为。此测试 时发生在单元程序之间的接口及相互作用上，所以可以发现在单元测试阶段没 有发现的问题。 集成测试有下列3个目的. 应用程序 软件构成要素间接口妥当性分析 应用程序和外部实体间接口妥当性分析 设计明细书店对应妥当性分析 集成测试将集成的模块视为应用程序, 应用程序视为子系统, 子系统视为整个 应用程序 系统， 有几种测试组成。 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 7 系统 测试 事件 系统 测试是评价新功能和成果的多次测试。 系统测试是 确认应用程序的根本 目的及需求是否满足根据定义的步骤执行的行为. 所以系统测试包含从多种角 度对系统全面测试，所以是最难的测试，有效性测试，最终需求测试，大小及 压力测试, 安全及控制测试, 回归测试, 文档及步骤测试, 最终站点测试。 通过之前的测试事件的测试示例可以再使用。但是单元及集成测试期间没有测 试的文档，步骤，成果等追加的测试示例要在系统层面上开发出来. 系统 集成比一个或2个层度的系统侧面的测试事件不同需要判断多种特性所以 非常复杂。 系统 测试要测试有效性，成果，延续性等焦点为目的，是需求， 外包设计明细书的测试， 系统 测试不仅仅有单一的一个测试示例构成而是由 一个整体的场景构成。 下面是系统 测试例子： 系统的测试一个功能的 测试 示例 一定期间使用者完成的所有操作。 自动化或手动作业的应用程序模拟 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 8 用户 测试 事件 与系统测试相同用户测试的目的是判断软件系统是否满足业务目的地需求，客 户机信息系统组织需求，设计明细书描述内容是否实现。 但是与系统测试不同， 用户测试时客户机有影响力的信息系统个人来负责。 虽然用户测试的时候可以使用开发好的测试用例，但是为了负责人确认客户对 系统的期待可以追加测试用例。 通过用户测试可以判断系统是否适合实际业务环境。 这是客户判断系统是否 可使用，所以是最接近现实的。在用户测试的时候出现错误，如果不影响继续 测试则可以继续进行。 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 9 (5) 测试 方法 测试事件 或目的不同可采用下面的测试方法. 白盒测试(white-box test) 白盒测试方法评价程序路径的逻辑性的所以也叫路径测试. 即测试程序路径是 否与预想结果一致，此 模块或程序的逻辑路径假设已经知道。 测试 数据不仅仅根据程序明细书制作的还要评价程序的逻辑性。内部程序结 构及逻辑的知识要掌握. 白盒测试的的主要优点是 发现黑盒 测试之前可以发 现的问题。 白盒测试的缺点如下: 不能判断是否与程序明细书一致. 白盒测试的内部结构及设计不是重点所 以是否符合程序明细书就不判断。 无法知道路径. 没有寻找丢失的路径的方法. 数据的敏感性的错误无法捕获. 通过白盒测试可以有效的执行所有可能的路径。因为此测试要求天文数字般的 测试用例。结果性来看白盒技术是适用于最有效的一般技术. 白盒测试方法在测试示例 设计时考虑下列事项。 文章 coverage : 程序内部的所有文章最小化执行. 分支 coverage : 将测试示例的所有决定分支，结果假设制定。 状况 coverage : 将测试示例在讨论范围内各个情况都至少走一遍。 分支/状况 coverage : 测试示例将决定内地各个状况分支最少走一遍。分支 部分最少得到一个以上结果的前提下制定。 基本路径测试 : 测试示例依赖于程序明细书和独立的代码逻辑制作。 这样 的测试示例叫基本路径测试, 程序上制作可走所有路径的测试. 然后生成代 码结构的基础的复杂的矩阵。 黑盒 测试(black-box test) 测试设计方法测试设计方法 categorytechniqueclass技术设计阶段 文档编号 : stpe4011版本 : 1.0制作日期 : 2003. 11. 01 page 10 从数据测试的词方法焦点在于测试程序明细书的功能。 特别次方法通过组合 输入资料可以评价是否能得出期待的结果。 黑盒 测试 示例 设计是考虑下列事项: 等级分解 : 等级分解是将符合的数据和不符合的数据分别设定测试。 测试所有数据， 在有限的范围内测试的方法， 举例来说在以提供的范围 内本金（600,000 元 800,000 元)的分为下列 3 个等级。 600,000 元 以下(不符合) 600,000 元 800,000 元 (符合) 800,000 元 超过(不符合) 边界分析 : 提供的功能的投入/产出的边界为焦点开发测试示例的方法。 举例来说回归系统从 1.00 元 到 999,999.00 元 的话边界设计可以检查如下 项。 最下边界 + 1 或 -1 0.00 元 或 2.00 元 边界 (1.00 元, $999,999.00 元) 最上范围 + 1 或 -1 999,998.00 元 或 1,000,000.00 元 误差猜测 : 测试示例 测试执行者的直观及经验为基础开发。 incremental 测试(incremental test) 此方法测试 单元 测试好的模块之间的接口。将单元 测试好的模块依次追加组 合后测试。 incremental 测试 分为下列3个形态。 向下 测试 : 结构饼(structured chart) 内从最高点模块到最低点模块测试 向上 测试 : 结构饼(structured chart) 内从最低的模块到最高点模块测试 双向 测试 : 双向组合测试. 不能说哪个方法更好，但是双向测试容易使用。产出物在使用向上测试方法的 时候可以直接评价.向下测试时测试的产出物 实际从测试模块和其它模块之间得出(模拟的模块)。 使用向上测试的话产出物 是从被测试的模块当中直接得出。 向下测试的主要优点是提供测试基础的程序版本的维护。 事务 测试(thread test) 单元业务 集成是使用的此方法是 应用程序执行特定功能时测试单元业务的