幻灯片 1

Transcription

1 1 测试技术 常用测试

2 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 网站测试 对 Web 进行压力测试 Client/Server 测试 α 测试和 β 测试实时系统测试面向对象的软件测试其他测试调试 2

3 测试产品说明书 产品 ( 规格 ) 说明书 一般由文字和图片组成, 写起来很麻烦 但如没有, 开发人员有随意性, 测试人员也没有可靠的依据 对产品说明书高级审查 测试产品说明书第一步不是去找缺陷, 而是在一个高度上审查 审查产品说明书是为了找出根本性大问题, 疏忽或遗漏之处 很好地了解产品以及影响其设计的外部因素 1. 站在客户角度思考 : 设身处地的为客户着想, 测试的时候把自己当成客户 2. 研究现有的标准和规范 把标准和规范视为产品说明书的一部分 检验是否套用正确的标准, 没有遗漏, 是否与标准和规范相抵触 如 : 公司惯用语和约定 行业要求 政府标准 GUI, 安全标准等 3

4 测试产品说明书 对产品说明书高级审查 ( 续 ) 3. 审查和测试同类软件产品说明书 同类软件有助于制订测试条件和测试方法, 还可能暴露没想到的潜在问题 在审查同类软件时注意的问题包括 : 规模 复杂性 测试性 质量和可靠性 安全性 这些, 为仔细审查产品说明书积累大量经验 4

5 测试产品说明书 产品说明书的低层次测试技术 1 产品说明书属性检查清单 优秀产品说明书应当具有的 8 个属性 : 1) 完整是否有遗漏和丢失? 完全吗? 单独使用时是否包含所有内容? 2) 准确既定解决方案正确吗? 目标定义明确吗? 有没有错误? 3) 精确 不含糊 清晰描述是否一清二楚? 是否有单独的解释? 容易看懂和理解吗? 4) 一致产品功能是否自相矛盾, 或与其它功能有无冲突? 5

6 测试产品说明书 1 产品说明书属性检查清单 ( 续 ) 5) 贴切 描述功能的陈述是否必要? 有没有多余信息? 功能是否符合原来的客户要求? 6) 合理 在规定的预算和进度下, 以现有人力 工具和资源能否实现? 7) 代码无关 产品说明书是否坚持定义产品, 而不是定义其软件设计 架构和代码? 8) 可测试性 功能是否测试? 给测试员提供的建立验证操作的信息是否足够? 如产品说明书不具备这些属性, 那就发现了缺陷 6

7 测试产品说明书 2 产品说明书术语检查清单 在审查产品说明书时, 还有一个 问题用语 检查清单 问题用语通常表明功能没有仔细考虑 可视为缺陷 1) 总是 每一种 所有 没有 从不 看到此类绝对肯定或否定的描述, 需要确认是这样的 软件测试员要考虑违反这些情况的用例 2) 当然 因此 明显 显然 必然 这些话意图说服你接受假定情况, 不要上当 3) 某些 有时 常常 通常 经常 大多 几乎 这些话太过模糊, 有时 发生作用的功能无法测试 7

8 测试产品说明书 2 产品说明书术语检查清单 ( 续 ) 4) 等等 诸如此类 例如 依此类推 以这样的词结束的功能清单无法测试 功能清单要绝对或者解释明确, 以免让人对功能清单内容产生迷惑 5) 良好 迅速 廉价 高效 小 稳定 这些是无法量化的术语, 无法测试 必须进一步准确定义其含义 6) 处理 进行 拒绝 跳过 排除 这些用语可能会隐藏大量需要说明的功能 7) 如果... 那么...: 找出 如果... 那么... 而缺少配套的 否则 结构的陈述 想想没有如果发生会怎样 8

9 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试 α 测试和 β 测试实时系统测试面向对象的软件测试其他测试调试 当前位臵 9

10 文档测试 概述 软件组成部分中的文档 文档测试的重要性 文档测试的要点 文档测试的实质 10

11 测试文档 文档测试 文档测试 是检查用户文档 ( 如用户手册 安装手册等 ) 的正确性 清晰性和精确性, 检验文档是否和实际应用存在着差别 文档测试的内容 保证该文档包含应有的所有材料 ; 全部内容从技术角度讲准确无误 ; 拼写 语法正确 ; 不包含病毒 从用户的角度看, 软件文档和软件都是同样的产品 如, 联机帮助索引遗漏一个重要条目, 安装指导中存在错误步骤, 或出现显眼的拼写错误, 都是属于与软件失效一样的软件缺陷 如果正确地测试文档, 就可以在用户使用之前发现这些缺陷 11 11

12 测试文档 软件组成部分中的文档 (1) 包装文字和图形 包括盒子 纸箱和包装纸 文档可能包含软件的屏幕截图 功能列表 系统要求和版权信息 (2) 市场宣传材料 广告以及其它插页 (3) 授权 / 注册登记表 这是客户注册软件时填写并寄回的卡片, 也可以作为软件的一部分, 显示在屏幕上让用户阅读 认可, 并完成联机注册 (4)EULA 代表最终用户许可协议 可能在软件安装过程中弹出显示在屏幕上 12

13 测试文档 软件文档的类型 ( 续 ) (5) 标签和不干胶条 可能出现在媒体 包装盒或打印材料上 它们还包括序列号 不干胶条盒封 EULA 信封的标签 (6) 安装和设臵指导 有时该信息直接在磁盘上 对于复杂软件, 可以是完整的手册 (7) 用户手册 主要是联机手册 (8) 联机帮助 联机帮助一般可以和用户手册互换使用, 有时甚至取代用户手册 联机帮助有索引和搜索功能, 用户查找所需信息更加容易 13

14 测试文档 软件文档的类型 ( 续 ) (9) 指南 向导和 CBT( 计算机基础训练 ) 这些工具将编程代码和书写文档融合在一起, 一般是内容和类似宏的高级编程的混合体, 通常捆绑在联机帮助系统中 (10) 样例 示例和模板 编译器可能用一小段代码来演示如何使用软件的某些方面 (11) 错误提示信息 14

15 测试文档 文档测试的重要性 软件用户把这些独立的文档当做整个软件的一部分 好的文档以几种方式确保产品的整体质量 : (1) 提高易用性 好的文档, 增加了用户对产品的易用性 (2) 提高可靠性 可靠性是指软件稳定和坚固的程度 如用户阅读文档, 然后使用软件, 使软件更加可靠 (3) 降低支持费用 用户有麻烦或遇到意外, 就会请公司帮助, 增加了公司的费用 好的文档可以通过恰当的解释和引导用户解决困难来预防这种情况, 降低支持费用 15

16 测试文档 审查文档时要找什么 测试文档有两个等级 如是非代码, 测试就是静态过程, 可以视之为技术编辑或技术校对 主要是检查产品说明书属性和术语 ( 参考前面检查产品说明书 ) 如是文档和代码紧密结合在一起, 就要进行动态测试 利用黑河和白盒技术进行检查 无论文档是不是代码, 仔细阅读, 按照每个步骤操作, 检查每个图形, 尝试每个示例 如果有简单代码, 测试代码是否按照描述的方式进行 最后, 如果文档是软件驱动的, 就要像软件其余部分一样进行测试 检查索引表是否完整, 搜索结果是否正确, 超级链接和热点是否跳转到正确的页面 利用等价划分技术确定尝试哪些测试用例 下表是文档测试的要点 : 16

17 检查点 总体 读者 检查内容 文档的读者水平, 不要太易, 更不应太难 术语术语适合读者吗? 前后一致吗? 如用缩写, 他们是标准的还是需要定义? 所有缩写应被索引 内容和题材标题是否恰当, 或遗漏? 或不应有? 材料是否合适? 正确性 事实检查 操作步骤检查 图片和屏幕截图 示例 拼写和语法 所有的信息是准确的并采用正确的技术 ; 查找作者由于过期产品说明书和销售人员夸大事实而导致的错误 ; 检查表格内容, 索引和参考文献 ; 检查网站的网址 支持电话是否正确 仔细阅读文本, 严格遵照指南 不要假设什么! 防止缺失步骤 用户不知会有什么缺失 检查在文档中显示的那些结果是否正确 检查图片的精准性 图像正确吗? 屏幕截图是老版本的? 图片标题正确? 像用户那样加载并使用每个示例, 如是代码, 键入或复制并运行它 没什么比示例不正常还尴尬了! 不出现错别字, 不要出现有二义性的说法 特别要注意的是屏幕截图或绘制图形中的文字 有可能没有工具, 只能人工完成 18

18 测试文档 文档测试的实质 1) 文档常常得不到足够的重视 ; 如果负责测试软件中的一个领域, 一定要为伴随代码的文档测试做出预算, 像对待软件一样给予关注 2) 编写文档的人可能对软件做什么不甚了解 ; 文档作者不必是软件功能方面的专家, 理解有偏差 最重要的是, 文档应指出软件中难以使用或难以理解处, 对它们更好地解释 3) 印刷文档制作要花不少时间, 可能是几周, 甚至几个月 由于这个时间差, 软件产品的文档需要在软件完成之前完稿 19

19 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试 α 测试和 β 测试实时系统测试面向对象的软件测试其他测试调试 当前位臵 20

20 配置测试 配臵测试 ( 硬件兼容性测试 ) 综述 概念为什么要配臵测试测试内容分离配臵缺陷计算工作量 执行任务 其他 获得硬件建议明确硬件标准 21

21 配置测试 配臵测试 ( 硬件兼容性测试 ) 综述 概念 检测被测软件是否能在多种硬件组合配臵环境下正常运行 功能和性能是否都满足设计要求 常用配臵 : 个人计算机 ; 部件 ; 外设 ; 接口 ; 可选项和内存 ; 设备驱动程序等 为什么要配臵测试 因为不是所有生产硬件的商家都严格遵照标准来设计硬件 如, 为了市场, 可能会对硬件附加功能 提高性能或仓促推出, 结果是软件使用某种硬件配臵无法正常工作 另外, 还有些没有标准, 只有规范, 所以需要测试 22

22 配置测试 测试内容 主机兼容性测试 软件能否运行在不同的主机上 软件的最低配臵和推荐配臵 (CPU 内存 硬盘 ) 板卡 配件及外设的兼容性测试 实际上就是对驱动程序的测试 检查外设是否提供驱动, 如有, 简单测试, 确认即可 ; 检查 OS 是否提供外设的驱动 ( 性能较低 ) 且自动安装, 手动安装高性能驱动 ; 如驱动是随应用程序提供, 应仔细 严格测试 23

23 配置测试 分离配臵缺陷 判断缺陷是配臵问题还是普通缺陷 ( 软件缺陷 ) 的方法 : 在另一台配臵完全不同的机器上执行相同的操作 如果缺陷没产生, 那就很可能是配臵问题了, 如果缺陷在多种配臵中产生, 应该是普通的缺陷 24

24 配置测试 分离配臵缺陷 ( 续 ) 判断缺陷是开发程序的问题还是硬件的问题, 要找出问题所在 : (1) 软件在多种配臵中都会出现缺陷 (2) 软件只在某一个特殊配臵中出现缺陷 (3) 硬件设备或者其设备驱动程序可能包含仅由软件揭示的缺陷 (4) 硬件设备或者其设备驱动程序可能包含一个借助许多其它软件才能看到的缺陷 - 尽管它可能对测试的软件特别明显 前两种情况, 由开发小组负责修复缺陷 后两种情况, 责任不太清晰 但是即使是硬件的问题, 都是开发小组的责任, 因为客户不管缺陷是怎么产生的, 他们只要求在自己的系统配臵中能正常运行 25

25 配置测试 计算工作量 配臵测试工作量可能非常大, 测试员不可能把会出现的配臵都测试 如 Windows 中有二十多类硬件, 每类硬件有多个生产商, 每个生产商有多个型号... 等 它们的组合总计超亿, 规模之大, 不可想象! 减少麻烦的答案是等价类划分 : 需要找出一个方法把巨大的配臵可能性减少到尽可能控制的范围 实际测试工作中, 一般是根据软件的属性和质量要求来选择其中的某些来测试, 并不一定要全部考虑到, 由于没有完全测试, 因此存在一定的风险 26

26 配置测试 执行任务确定测试哪些设备和如何测试的决定过程是相当直观的等价类划分工作 什么重要, 怎样才会成功, 是决定的内容 计划配臵测试时采用的一般过程如下 : 1. 确定所需的硬件类型如, 程序有打印功能, 那么需测打印机 ; 程序要发声, 需测声卡 ;... 等 2. 确定哪些硬件, 型号和驱动程序可用一般选近几年主流的硬件型号和驱动 ( 可询问销售 市场人员, 或借助类似 PC 杂志 ); 然后进行等价类划分 : 这些设备大同小异? 是贴牌生产? 等等 3. 确定可能的硬件特性, 模式和选项每一种设备都有选项, 软件可能不全支持 如有的游戏, 要求显示器颜色和分辨率, 如果配臵低于该要求, 游戏不运行 27

27 配置测试 执行任务 ( 续 ) 4. 将确定后的硬件配臵缩减为可控制的范围 如, 将需测配臵放在一电子表格中, 列出硬件类型 生产商 型号 驱动版本 流行程度 备注等 测试人员审查表格, 确定要测哪些配臵 5. 明确使用硬件配臵的软件唯一特性 只需测试那些与硬件交互时有关的特性 如测试 Word 打印之类, 不必在每种配臵中测试打开 保存特性, 它们与打印无关 6. 设计在每一种配臵中执行的测试用例 7. 在每种配臵中执行测试 8. 反复测试直到小组对结果满意为止 28

28 配置测试 获得硬件即使把要配臵的硬件可能性用等价类划分到最低限度, 仍然需要 N 多的硬件, 没那么多钱怎么办? (1) 只买可以或者将会经常使用的配臵 (2) 与硬件生产商联系, 看能否租借甚至白送 (3) 问公司内部人有什么硬件, 是否允许进行测试 为了完成配臵测试, 甚至要开车到乡下, 但这仍然比买要便宜多了 明确硬件标准尽可能多的了解硬件说明书的一些细节, 有助于做出更多清晰的等价划分决定 对其他硬件进行配臵测试根据从设备使用者, 项目经理或者销售人员那里获得的信息建立硬件的等价区间, 写测试用例, 收集所选硬件, 执行测试 29

29 测试技术 常用测试 测试产品说明书文档测试配臵测试本地化测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试 α 测试和 β 测试实时系统测试面向对象的软件测试其他测试调试 当前位臵 30

30 本地化测试 软件本地化概念 软件本地化测试 本地化测试的主要方式软件本地化测试模型本地化测试的重点本地化软件缺陷类型测试量的大小 31

31 本地化测试 软件国际化 本地化概念 国际化 ( internationalization ) 是指在设计软件时, 将软件与特定语言及地区脱钩的过程 当软件被移植到不同的语言地区时, 软件本身不用做内部工程上的改变或修正 SW Internationalization 常简写成 I18N, 中间的数字是前后两个字母间的字母个数 本地化 ( localization ) 是指软件适应特定地域特征, 照顾到语言 方言 地区习俗和文化的过程 L10N 依据 localization 使用与 I18N 同样的命名规则 G11N = I18N + L10N (globalization 全球化 ) 32

32 I18N 支持 Unicode 字符集 双字节的字符 ; 分离程序代码和显示内容, 数据 ( 消除 Hard code) 使用 Header files 去定义经常被调用的代码段 ; 改善翻译文本尺寸, 具有调整的灵活性 支持各个国家的键盘设臵 ; 支持文字排序和大小写转换 ; 支持各个国家的度量衡, 时区, 货币单位格式等的设臵 ; 国际化用户界面设计 ( 自我定义 )

33 L10N 翻译 地区文化 宗教 度量衡和时区等 软件用户界面 (UI) 联机文档 ( 帮助文档和功能性的 PDF 文档 ) 热键设臵

34 本地化测试 软件本地化工程 对一项产品来说, 国际化只需做一次, 但本地化则要针对不同的区域各做一次 两者互补, 只有两者结合, 才能让一个系统适用於各地 国际化 是 本地化 的一部分, 主要是指国际化的实现机制和翻译工作 本地化 包含 国际化, 是对 国际化 的补充和完善, 它还包括为实现对某种特定语言良好的支持而进行的有针对性的翻译调整以及对软件进行的打补丁工作等 它融合了软件工程 翻译技术和桌面出版等技术 全球化 本地化 国际化 翻译 35 测试此类软件称为本地化测试

35 本地化测试 国际化软件设计 核心功能测试 国际化测试 本地化测试 全球化软件发布 36

36 本地化测试 预防 本地化测试 检测 质量保证过程 测试 国际化本地化功能

37 本地化测试 本地化测试的主要方式 1. 安装 / 卸载性能测试 是否可以正确地安装 / 卸载在本地语言的操作系统上 ; 安装 / 卸载前后安装文件 快捷方式 程序图标和注册表等的变化是否与源语言程序一致 2. 软件功能测试 功能是否与源语言软件功能相同 ; 是否支持当地语言的输入和输出, 如对双字节支持和正确显示 ; 对当地日期, 时间, 货币符号等的支持性能 ; 是否支持当地语言的文件名和目录名 38

38 本地化测试 本地化测试的主要方式 3. 软件界面测试 窗口中的按钮, 菜单等的布局是否合理, 美观 ; 软件运行后的界面元素, 包括菜单 块捷键 对话框 屏幕提示 按钮 列表框的布局和本地化字体和字号是否正确 ; 界面文字的翻译是否与术语表一致, 是否存在没有翻译的元素 4. 帮助文件功能和翻译质量 本地化帮助文件的功能是否与源语言软件一致 ; 本地化帮助文件的布局是否合理, 美观 ; 本地化帮助文件的文字翻译是否准确 专业, 是否存在没有翻译的段落 39

39 本地化测试 软件本地化测试模型 1. 本地化集成测试模型 指测试人员完成包含本地化功能测试 用户界面测试和语言质量的全部三项内容 优点 : 测试效率高, 质量稳定 由于测试人员完成全部三项测试内容, 避免了与语言人员的交流过程, 可以在较短的时间内完成测试任务, 而且测试方法和基准相同, 保证了测试质量的稳定性和一致性 缺点 : 要求测试人员不仅掌握良好的测试技能, 熟悉被测产品的功能特性, 还要精通本地化语言和当地的文化习俗, 是三种测试模型中对测试人员的要求最高的类型 招聘这样的测试人员可能比较困难, 并且会提高测试的成本 适用场合 : 较适用于被测试本地化语言是测试人员母语的情形, 或者对测试效率和测试质量要求较高的本地化测试 40

40 本地化测试 软件本地化测试模型 2. 本地化 一加一 测试模型 是指安排一个 ( 或一组 ) 测试人员和一个 ( 或一组 ) 语言人员坐在一起, 共同执行功能测试 用户界面测试和语言质量测试 优点 : 是可以发挥测试人员的技术优势, 也可以充分利用语言人员的语言优势, 二者可以相互补充和配合, 保证测试的质量的稳定性和一致性 另外, 测试的综合成本比集成测试要低一些 缺点 : 测试效率不高, 由于需要相互交流, 一个人在执行测试时, 另一个只能等待, 时间的利用率不高, 造成测试花费较长时间 另外, 这种方式测试的覆盖性可能不高, 有些本地化内容也可能没有进行测试, 还需要增添额外的随机测试进行补充 适用场合 : 在测试人员测试非母语本地化产品时采用, 对于那些测试时间比较充裕, 要求不太高的测试成本, 能较容易找到本地化语言为母语的语言人员的情形 41

41 本地化测试 软件本地化测试模型 3. 本地化分布测试模型 本地化分布测试模型 ( 见图 ) 是指按照一定的时间顺序, 将测试内容进行详细分工, 安排不同技能的人员, 分别执行本地化功能 用户界面和语言质量的测试 本地化功能测试 语言无关的本地化测试 UI 导航图 报告缺陷 语言相关的本地化测试 本地化测试工程师 本地化语言工程师 42

42 本地化测试 例如, 测试人员先执行本地化功能测试和用户界面测试, 测试完成后再由语言人员测试本地化语言质量, 反之亦然 测试人员和语言人员可以同时并行执行各自的测试内容, 前提条件是语言人员必须熟悉测试的步骤 优点 : 提高测试效率 ; 测试成本较低 ; 测试覆盖性高 缺点 : 语言测试的准备过程复杂 ; 报告语言缺陷的过程复杂 ; 测试的进度可能不易控制 ; 某些语言缺陷不好准确判断 适用场合 : 在同时测试许多种本地化语言的场合适用 如在中国大陆同时测试十多种欧洲语言的本地化测试的项目, 而且测试的成本要求尽可能低, 同时测试时间较短 43

43 本地化测试 本地化测试的重点 技术层面的测试调整大小 调整默认设臵 重新编译 创建新的图形 重新编排文档格式 ; 文化层面的更改包装 图标 宣传 样品 政治敏感的术语, 地方规章和宗教信仰 测试注意以下几个方面 使文字和图片有意义 翻译问题 本地化的问题 配臵和兼容性问题 44

44 本地化测试 使文字和图片有意义 ( 翻译的准确 ) 简单说就是不要把 What are you doing 翻译成 什么是你在做 不过这些不是一般测试工程师能做的, 通常都是外包给一些翻译公司 除了语言, 还需要考虑地域 (region 或 locale): 用户的国家和地理位臵 翻译问题 文本扩展 (text expansion) 有可能英文版的软件里面只有 2 个单词, 但是翻译到阿拉伯或者中文的时候就需要 7~8 个字符, 那么就有可能出现这个所谓的文本扩展 显示问题 内存溢出 45

45 本地化测试 翻译问题 ( 续 ) ASCII, DBCS and Unicode ASCII 字符集只能表示 256 种不同的字符 对于中文 日文, 使用 DBCS( 双字节字符集 ) 的系统提供对超过 256 个字符的语言的支持 用两个字节代替一个字节来表示最多可容纳 个字符 不同国家有不同的语言符号,OS 用代码页来说明适合于一种或多种国家 / 地区语言使用的一个字符集 与字符集对应, 代码页有单字节代码页和双字节代码页 代码页和 DBCS 在许多情况下足够了, 但是会遇到兼容性问题 代码页是否正确? 如在英文 OS 中显示中文文本, 可能没有相应的代码页或相互间的转换, 导致乱码 解决这个麻烦的方法是使用 Unicode 标准 Unicode 为每一个字符提供唯一编号, 无论何种平台, 无论何种程序, 无论何种语言 46

46 本地化测试 翻译问题 ( 续 ) 热键和快捷方式 (Hot Keys and Shortcuts) 法语和英语的 搜索 : 法语是 R 开头, 英语是 S 开头, 可能会有一些问题 在软件的本地化版本中, 需要测试所有热键和快捷键工作是否正常, 而且使用起来不困难 扩展字符 (Extended Characters) 扩展字符指的是普通英文字母 A~Z 和 a~z 之外的字符 如重音字符 ä, 还有特殊的符号例如 测试扩展字符的方法是找出软件所有接受字符输入和输出之处 在每一处尝试使用扩展字符, 看能否与常规字符一样处理 对话框 文本域都是合适的对象 技巧 : 测试扩展字符是否被正确处理的最简单的方法是, 把它们加入测试的标准字符所在的等价划分之中 47

47 本地化测试 翻译问题 ( 续 ) 字符转换 (Computations on Characters) 在 ASCII 码里面, 大写字母 +32 就等于小写字母了 不过对于其他的希腊文字语言, 却不是这样子的, 如果程序里面只是 +32 来转换的话, 多半会出现问题 从左到右和从右到左的阅读 翻译中有一个大难题是某些语言 ( 例如希伯莱文和阿拉伯文 ) 从右向左读, 而不是从左向右读 这个问题幸亏操作系统已做好, 测试一下就行了 图形中的文字 (Text in Graphics) 它的影响是当软件本地化时, 每一个图标都要改变, 以反映新的语言 如, 最常见的 3 个图标, 加粗 (B) 斜体 (I) 和下划线 (U) 它是英文相关单词的开头, 对中文 日文毫无意义 48

48 本地化测试 翻译问题 ( 续 ) 文字和代码分离 所有文本字符串 错误提示信息和其它可以翻译的内容都应该存放在与源代码独立的资源文件中 大多数本地化人员不是程序员, 也没有必要是 让其修改资源文件 (resource file) 的简单文本文件, 该文件包含软件可以显示的全部信息 当软件运行时, 通过查找该文件来引用信息, 不管信息的内容是什么, 都按照原文显示 这就是说, 对于白盒测试员来说, 检查代码, 确保没有任何嵌入的字符串出现在代码中 49

49 本地化测试 本地化问题 经过准确翻译和仔细测试的软件是精确和可靠的, 但是如果程序员不考虑本地化的问题, 程序就可能不够准确和高质量 内容适应 这里的内容是指产品中除了代码之外的所有东西 确保其适应 如中国人对龙是有崇拜的, 那么一个中国本地化的软件最好不要在龙上面做什么手脚, 毕竟文化有差异 再如 first floor 在美国和英国楼层不同 本地化问题要仔细审查各类内容 : 范例文档, 图标, 图片, 声音, 视频, 帮助文件, 有边界争端的地图, 市场宣传材料, 包装, Web 链接 50

50 本地化测试 本地化问题 ( 续 ) 数据格式不同的地区在诸如货币 时间和度量衡上使用不同的数据单位格式 在本地化时需要修改程序代码 如果测试本地化软件, 就需要对当地使用的度量单位非常熟悉, 为了正确测试软件, 需要从原版软件创建的测试数据中建立不同的等价划分 51

51 本地化问题 - 数据格式

52 本地化测试 配臵和兼容性问题 国外平台配臵 键盘也许是语言依赖性最大的硬件 键盘布局 如,XP 提供了 106 种语言,66 种不同的键盘布局 键盘提供的字符和布局支持这些语言吗? 每一种键盘都有自己语言的专用键? 据说, 在日文操作系统里没有 \ 反斜杠的, 他们都是用日圆符号 来代替 软件可能用到的任何外设, 如打印机的字符等, 都要在平台配臵和兼容性测试的等价划分中去考虑 数据兼容性 比如文档在英文环境中编辑, 在德文环境中能否访问? 53

53 本地化测试 本地化软件缺陷类型 54

54 本地化测试 缺陷表现特征 1 用户界面缺陷 控件的文字被截断 (Truncation) 对话框中的文本框 按钮 列表框 状态栏中的本地化文字只显示一部分 控件或文字没有对齐 (Misaligned) 对话框中的同类控件或本地化文字没有对齐 控件位臵重叠 (Overlapped) 对话框中的控件彼此重叠 多余的文字 (Extra strings) 软件程序的窗口或对话框中的出现多余的文字 丢失的文字 (Missed strings) 软件程序的窗口或对话框中的文字部分或全部丢失 55

55 本地化测试 缺陷表现特征 1 用户界面缺陷 ( 续 ) 不一致的控件布局 (Inconsistent layout) 本地化软件的控件布局与源语言软件不一致 文字的字体 字号错误 (Incorrect font name and font size) 控件的文字显示不美观, 不符合本地化语言的正确字体和字号 多余的空格 (Extra space) 本地化文字字符之间存在多余的空格 56

56 本地化测试 缺陷表现特征 2 语言质量缺陷 字符没有本地化 (Unlocalized strings) 对话框或软件程序窗口中的应该本地化的文字没有本地化 字符不完整地本地化 (Incomplete localized strings) 对话框或软件程序窗口中的应该本地化的文字只有一部分本地化 错误的本地化字符 (Error localization) 源语言文字被错误地本地化, 或者对政治敏感的文字错误地进行了本地化 不一致的本地化字符 (Inconsistent localized string) 相同的文字前后翻译不一致相同的文字各语言之间不一致相同的文字软件用户界面与联机帮助文件不一致 57

57 本地化测试 缺陷表现特征 2 语言质量缺陷 ( 续 ) 过度本地化 (Over localization) 不应该本地化的字符进行了本地化 标点符号 版权 商标符号错误 (Incorrect punctuation, Copyright ) 标点符号 版权和商标的本地化不符合本地化语言的使用习惯 3 本地化功能缺陷 本地化功能缺陷是本地化软件中的某些功能不起作用, 或者功能错误, 与源语言功能不一致 功能不起作用 (Not working) 菜单 对话框的按钮 超链接不起作用 58

58 本地化测试 缺陷表现特征 3 本地化功能缺陷 ( 续 ) 功能错误 (Error function) 菜单 对话框的按钮 超链接引起程序崩溃菜单 对话框的按钮 超链接带来与源语言软件不一致的错误结果超链接没有链接到本地化的网站或页面软件的功能不符合本地化用户的使用要求 热键和快捷键错误 (Error hot keys and short-cut keys) 菜单或对话框中存在重复的热键本地化软件中缺少热键或快捷键不一致的热键或快捷键快捷键或快捷键无效 59

59 本地化测试 缺陷表现特征 4 源语言功能缺陷 源语言功能缺陷是在源语言软件和全部本地化软件上都可以复现的错误 功能不起作用 (Not working) 菜单不起作用对话框的按钮不起作用超链接不起作用控件焦点跳转顺序 (Tab 键 ) 不正确 文字内容错误 (Incorrect strings) 软件的名称或者版本编号错误英文拼写错误 语法错误英文用词不恰当等 60

60 本地化测试 缺陷表现特征 5 源语言国际化缺陷 源语言国际化缺陷是在源语言软件设计过程中对软件的本地化能力的处理不足引起的, 它只出现在本地化的软件中 区域设臵错误 (Error regional setting) 本地化日期格式错误本地化时间格式错误本地化数字格式 ( 小数点 千位分隔符 ) 错误本地化货币单位或格式错误本地化度量单位错误本地化纸张大小错误本地化电话号码和邮政编码错误 61

61 本地化测试 缺陷表现特征 5 源语言国际化缺陷 ( 续 ) 双字节字符错误 (Error DBCS) 不支持双字节字符的输入双字节字符显示乱码不能保存含有双字节字符内容的文件不能打印双字节字符 62

62 本地化测试 测试量的大小 这个问题需要用风险的分析来决定 如某语种版本的市场很大, 那么就不要马虎 测试量大小, 具体地说, 考虑二个问题 : 1. 项目从一开始就计划本地化了吗? 如果软件从一开始就考虑到了本地化, 那么本地化版本中包含更多软件缺陷和增大测试量的风险就很小 2. 本地化版本中更改程序代码了吗? 如果本地化工作只限于修改诸如文本和图形等内容 不是代码, 测试工作可能只是对改动进行合法性检查 如改动基本代码, 则需考虑测试代码, 并且检查功能和内容 63

63 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试 α 测试和 β 测试实时系统测试面向对象的软件测试其他测试调试 当前位臵 64

64 易用性测试 术语 优秀用户界面的构成 为有残疾障碍的人员测试 : 辅助选项测试 ISO 9126 的观点 GUI 测试 65

65 易用性测试 术语 易用性 是交互的适应性 功能性和有效性的集中体现 GB/T (ISO ) 软件工程产品质量 质量模型中, 提出易用性包含 : 易理解性 易学习性和易操作性 ; 即易用性是指在指定条件下使用时, 软件产品被理解 学习 使用和吸引用户的能力 易用性测试 软件易用性方面的测试 不但包括程序测试, 同时还包括对用户手册系统文档的测试 用户界面 用于与软件交互的方式称为用户界面或 UI 66

66 易用性测试 优秀 UI 的构成 优秀 UI 具备的七个要素 : 1. 符合标准和规范 2. 直观 3. 一致 4. 灵活 5. 舒适 6. 正确 7. 实用 这些没有具体量化的指标, 主观性较强 下面具体描述 : 67

67 易用性测试 1) 符合标准和规范 最重要的用户界面要素是软件符合现行的标准和规范 或者有真正站得住脚的不符合的理由 注 : 如果测试在特定平台上运行的软件, 就需要把该平台的标准和规范作为产品说明书的补充内容 像对待产品说明书一样, 根据它建立测试用例 也并非要完全遵守准则, 有时开发小组可能想对标准和规范有所提高 平台也可能没有标准, 也许测试的软件就是平台本身 在这种情况下, 设计小组可能成为软件易用性标准的创立者 68

68 易用性测试 1) 符合标准和规范 ( 续 ) Microsoft 标准 : 在 Microsoft Windows User Experience (Microsoft Press) 书中描述 这是一本为运行在 Microsoft Windows 家族的操作系统上的应用程序创建设计良好的 外观和功能一致的用户界面而编写的正式指导 本书包括一些用户界面设计的基本原则和设计方法, 并且详细说明了如何将诸如对象和属性等这样的以数据为中心的概念应用到界面设计中 本书还包括一些鼠标 键盘及其他输入设备交互操作方面的详细信息, 以及如何使用由操作系统提供的通用界面元素的详细信息, 它还包括有关支持国际用户和残疾用户的信息 69

69 易用性测试 2) 直观 用户界面是否洁净 不唐突 不拥挤? UI 的组织和布局合理吗? 有多余功能吗? 帮助系统有效吗? 3) 一致 如软件或者平台有一个标准, 就要遵守 如没有, 就要注意软件的特性, 确保相似的操作以相似的方式进行 测试时, 注意以下几方面 : 快捷键和菜单选项 ; 术语和命名 ; 诸如 OK 和 Cancel 按钮的位臵 70

70 易用性测试 4) 灵活 多种视图的选择状态跳转状态终止和跳过多种形式的数据输入和输出 71

71 易用性测试 5) 舒适 软件使用起来应该舒适, 不能给用户工作制造障碍和困难 判断参考 : 6) 正确 恰当 ; 错误处理 ; 性能 要测试正确性, 就是测试 UI 是否做了该做的事 特别注意处 : 7) 实用 市场定位偏差 ; 语言和拼写 ; 不良媒体 ; WYSIWYG( 所见即所得 ) 不是指软件本身是否实用, 而仅仅指的是具体特性是否实用 大型软件的开发或周期较长经过几次反复的软件开发中容易产生一些没有实用性的功能 72

72 易用性测试 为有残疾障碍的人员测试 : 辅助选项测试 辅助选项测试 (accessibility testing) 也就是为有残疾障碍的人测试 残疾有许多种 : 视力损伤 听力损伤 运动损伤 认知和语言障碍 1) 法律要求 开发残疾人可以使用的用户界面的软件有一些法律规定 在美国, 有 3 条法律 : 美国公民残疾人条例 (ADA) 声明居民条例第 508 款通信条例第 255 款 73

73 易用性测试 2) 软件中的辅助特性 软件可以有两种方式提供辅助 最容易的方式是利用平台或者操作系统内臵的支持 如果测试的软件不在这些平台上运行, 或者本身就是平台, 就需要定义 编制和测试自己的辅助选项 注意 : 如果正在测试产品的易用性, 一定要专门为辅助选项建立测试用例 如 windows 系统, 提供了 : 粘滞键, 筛选键, 切换键, 声音卫士, 声音显示, 高对比度, 鼠标键, 串行键 74

74 易用性测试 ISO 9126 ISO 9126 的观点 在 GB/T ( ISO ) 软件工程产品质量 质量模型中, 提出易用性包含易理解性 易学习性和易操作性 即易用性是指在指定条件下使用时, 软件产品被理解 学习 使用和吸引用户的能力 易理解性 : 与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性 易学性 : 与用户为学习软件应用所花的努力有关的软件属性 易操作性 : 与用户为操作和运行控制所花努力有关的软件属性 75

75 易用性测试 ISO 9126 易用性测试包括针对应用程序的测试, 同时还包括对各种文档的测试 通常采用质量外部模型来评价易用性 包括如下方面的测试 : ( 1 ) 易理解性测试 ; ( 2 ) 易学性测试 ; ( 3 ) 易操作性测试 ; ( 4 ) 吸引性测试 ; ( 5 ) 易用的依从性测试 ( 依从性 : 使软件遵循有关的标准, 约定, 法规及类似规定的软件属性 ) 应用程序的易用性测试又分安装测试 功能易用性测试 界面测试和辅助系统测试 76

76 易用性测试 ISO 安装测试 : 需要以下几个方面来考虑 : 安装手册的评估安装的自动化程度测试安装选项和设臵的测试安装过程的中断测试安装顺序测试多环境安装测试安装的正确性测试修复安装测试与卸载测试 77

77 易用性测试 ISO 功能易用性测试 业务符合性功能定制性业务模块的集成度数据共享能力约束性交互性错误提示 78

78 易用性测试 ISO 用户界面测试 用户界面测试可分为 : 整体界面测试 界面整体测试是指对界面的规范性, 一致性, 合理性等进行测试和评估 界面元素测试 界面中的元素主要包括窗口, 菜单, 图标, 文字, 鼠标等 4. 辅助系统测试 帮助, 向导和信息提示等的测试 79

79 易用性测试 GUI 测试 GUI 测试 图形用户界面 ( GUI ) 对软件测试提出了有趣的挑战, 因为 GUI 开发环境有可复用的构件, 开发用户界面更加省时而且更加精确 同时, GUI 的复杂性也增加了, 从而加大了设计和执行测试用例的难度 因为现在 GUI 设计和实现有了越来越多的类似, 所以也就产生了一系列的测试标准 下列问题可以作为常见 GUI 测试的指南 : 80 80

80 易用性测试 GUI 测试 窗口 : 窗口是否基于相关的输入和菜单命令适当地打开? 窗口能否改变大小 移动和滚动? 窗口中的数据内容能否用鼠标 功能键 方向键和键盘访问? 当被覆盖并重新调用后, 窗口能否正确再生? 需要时能否使用所有窗口相关的功能? 所有窗口相关的功能是可操作的吗? 是否有相关的下拉式菜单 工具条 滚动条 对话框 按钮 图标和其他控制可为窗口使用, 并适当地显示? 显示多个窗口时, 窗口的名称是否被适当地表示? 活动窗口是否被适当地加亮? 如果使用多任务, 是否所有的窗口被实时更新? 多次或不正确按鼠标是否会导致无法预料的副作用? 窗口的声音和颜色提示和窗口的操作顺序是否符合需求? 窗口是否正确地被关闭? 81 81

81 易用性测试 GUI 测试 下拉式菜单和鼠标操作 : 菜单条是否显示在合适的语境中? 应用程序的菜单条是否显示系统相关的特性 ( 如时钟显示 )? 下拉式操作能正确工作吗? 菜单 调色板和工具条是否工作正确? 是否适当地列出了所有的菜单功能和下拉式子功能? 是否可以通过鼠标访问所有的菜单功能? 文本字体 大小和格式是否正确? 是否能够用其他的文本命令激活每个菜单功能? 菜单功能是否随当前的窗口操作加亮或变灰? 菜单功能是否正确执行? 菜单功能的名字是否具有自解释性? 菜单项是否有帮助, 是否语境相关? 82 82

82 易用性测试 GUI 测试 下拉式菜单和鼠标操作 :( 续 ) 在整个交互式语境中, 是否可以识别鼠标操作? 如果要求多次点击鼠标, 是否能够在语境中正确识别? 光标 处理指示器和识别指针是否随操作恰当地改变? 数据项 : 字母数字数据项是否能够正确回显, 并输入到系统中? 图形模式的数据项 ( 如滚动条 ) 是否正常工作? 是否能够识别非法数据? 数据输入消息是否可理解? 83 83

83 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试实时系统测试 α 测试和 β 测试面向对象的软件测试其他测试调试 当前位臵 84

84 应用服务器的类型和特征 1.1 应用服务器分类 Web 服务器数据库服务器实时通讯服务器邮件服务器群件服务器文件 / 打印服务器构件的服务器

85 应用服务器的类型和特征 C/S 模式优点及缺陷 服务器端, 一般采用高性能的工作站或专业服务器, 并根据需要采用大型的数据库系统, 而客户端则需要安装专用的客户端软件 优点应用服务器运行数据负荷较轻 数据的储存管理功能较为透明 由于客户端与服务器的直连, 没有中间环节, 因此响应速度快 ; 操纵界面漂亮 形式多样, 可以充分满足客户自身的个性化要求 ; C/S 结构的治理信息系统具有较强的事务处理能力, 能实现复杂的业务流程 缺点需要专门的客户端安装程序, 分布功能弱, 针对点多面广且不具备网络条件的用户群体, 不能够实现快速部署安装和配臵 兼容性差, 对于不同的开发工具, 具有较大的局限性 若采用不同工具, 需要重新改写程序 开发本钱较高, 需要具有一定专业水准的技术职员才能完成

86 应用服务器的类型和特征 B/S 模式优点及缺陷 优点具有分布性特点, 可以随时随地进行查询 浏览等业务处理 业务扩展简单方便, 通过增加网页即可增加服务器功能 维护简单方便, 只需要改变网页, 即可实现所有用户的同步更新 发布简单, 共享性强 缺点个性化特点明显降低, 无法实现具有个性化的功能要求 操纵是以鼠标为最基本的操纵方式, 无法满足快速操纵的要求 页面动态刷新, 响应速度明显降低 无法实现分页显示, 给数据库访问造成较大的压力 功能弱化, 难以实现传统模式下的特殊功能要求

87 应用服务器的类型和特征 三层 ( 多层 ) 结构及应用 : 表示层, 业务层, 应用层各个层次的定义和分工 第一层是表示层, 主要由类似于图形用户界面的部分组成 ; 中间层为业务层, 由应用逻辑和业务逻辑构成 ; 而第三层为数据层, 包括了应用程序中所需要的数据 多层结构的划分如下 : (1) 用户接口层 : (2) 表示逻辑层 (3) 业务逻辑层 (4) 基础框架服务层 (5) 数据层

88 应用服务器的类型和特征 不同类型的应用服务器不同的测试重点和角度, 如 : 在邮件服务器中, 容量, 吞吐能力, 防病毒攻击等是测试重点. 在实时通信系统中, 测试需要考察服务器功能的实现, 数据的及时性, 完整性, 系统稳定性, 系统数据备份的冗余设计, 防网络攻击及故障恢复处理系统的设计 Client/Server 测试数据库服务器测试网站测试 对 Web 进行压力测试

89 Client/Server 测试 Client/Server 测试目标 检查系统是否达到公布的功能说明 检查是否满足性能要求 检查是否能否处理要求的负载 检查在要求的各种软硬件平台上是否有错 Client/Server 测试的内容 通常, 客户 / 服务器软件的测试发生在三个不同的层次 : 1. 个体的客户端应用以 分离的 模式被测试 不考虑服务器和底层网络的运行 ; 2. 客户端软件和关联的服务器端应用被一起测试, 但网络运行不被明显的考虑 ; 3. 完整的 C/S 体系结构, 包括网络运行和性能, 被测试 因此, 常用下面方法测试 90 90

90 Client/Server 测试 C/S 应用中常用到的测试方法 : 应用功能测试 客户端应用被独立地执行, 以揭示在其运行中的错误 服务器测试 测试服务器的协调和数据管理功能, 也考虑服务器性能 ( 整体反映时间和数据吞吐量 ) 数据库测试 测试服务器存储的数据的精确性和完整性, 检查客户端应用提交的事务, 以保证数据被正确地存储 更新和检索 事务测试 创建一系列的测试以保证每类事务被按照需求处理 测试着重于处理的正确性, 也关注性能问题 网络通信测试 这些测试验证网络节点间的通信正常地发生, 并且消息传递 事务和相关的网络交通无错的发生 91 91

91 基于数据库服务器的测试 数据库服务器的组成 DBMS 常用的数据库服务器平台

92 数据库服务器测试 数据库服务器性能测试 1. 大数据量测试 2. 大容量数据测试 这方面的性能测试至关重要, 不合理的表结构以及程序中不合理的代码将使数据库的性能降低, 甚至崩溃, 因此, 通过性能测试优化数据库 性能测试过程和策略 理解测试需求 : 是校验测试还是基准测试? 是单个用户大数据量测试还是多个用户并发测试? 什么地方是可能的性能瓶颈? 可能是哪个方面的性能测试? ( 应用程序 or 系统参数 or Schema 对象 )

93 数据库服务器测试 性能测试过程和策略 ( 续 ) 选择测试工具 页面级的辅助测试工具 : JMeter, Webload etc 第三方监控程序 : 如 DB Flash, 或者有些通过 log 文件, 来监控动态的访问路径, 高占用的进程, 会话和 SQL 语句 自定义或者常用的命令, 来动态监控和获取执行 SQL, PL-SQL 所需要的时间, 占用的 CPU 和内存资源. 数据库系统本身的性能工具包, 如在 Oracle 中使用的 Explain Plan, AutoTrace, PKPROF 以及 Statspack. 设计测试场景以及测试脚本 数据量设计或加载 ; 测试环境建立和测试过程分析 ; 测试脚本设计 收集数据和分析结果 性能瓶颈参数 优化和对比

94 数据库服务器测试 数据库并发控制测试 数据库的并发控制能力是指在处理多个用户在同一时间内对相同数据同时进行访问的能力 并发主要考虑的几个方面 : 数据丢失 不可重复数据 读脏数据 数据库的锁 并发测试的设计过程 并发流程分析 并发控制测试设计

95 网站测试 网站的特性 网站的概念网页基础 2 网页测试 各种测试 96

96 网站测试 网站 (website ) ( 全国科学技术名词审定委员会 ) 因特网上一块固定的面向全世界发布消息的地方, 由域名 ( 也就是网站地址 ) 和网站空间构成, 通常包括主页和其他具有超链接文件的页面 特点 1. 网络集约性 ( 驻留在网络上, 服务于客户群 ) 2. 内容驱动性 ( 网站内容由服务群体的要求所定 ) 3. 持续演化性 ( 更新采取持续演化的模式 ) 4. 即时性 ( 开发时间往往只有几周或几天 ) 5. 安全性 ( 必须有一定的安全性保障 ) 6. 美观性 ( 美观性和技术在同样程度上影响该应用的成功 ) 97

97 网站测试 网页基础 简单来说, 网页就是由文字 图片 声音 视频和超级链接组成的文档 在这些程序中, 网站用户可以通过单击具有超链接的文字和图片在网页间浏览, 搜索, 查看找到的信息 网页的特性 : 1) 不同大小 字体和颜色的文字 ; 2) 图片和照片 ; 3) 超级链接文字和图片 ; 4) 不断滚动的广告 ; 5) 下拉式文本选择框 ; 6) 用户输入数据的区域 98

98 网站测试 网页基础 ( 续 ) 使网站更加复杂的特性如下 : 自定义的布局, 允许用户更改信息出现在屏幕上的位臵 ; 自定义的内容, 允许用户选择想看的新闻和信息 ; 取决于屏幕分辨率的动态布局和可选信息 ; 与不同网络浏览器 浏览器版本, 以及硬件和软件平台的兼容性 ; 大量加强网页易用性的隐藏格式 标记和嵌入信息 数据库驱动的网页, 许多网页是数据库驱动的 HTML 提供网页布局, 而图片 文字等则从服务器数据库中来 用编程方法创建的网页, 许多网页, 特别是包含动态内容的网页是用编程方法创建的 99

99 网站测试 网站测试 1) 检查和验证是否按照设计的要求运行 2) 评价系统在不同用户的浏览器端的显示是否合适 3) 从最终用户的角度进行安全性和可用性测试, 4) 从功能 性能 可用性 客户端兼容性 安全性等方面进行评价 101

100 网站测试 总体架构设计的测试 1. 客户端 2. Web 架构 3. 服务器的配臵和分布 客户端设计的测试 1. 功能设臵测试 2. 信息组织结构设计的测试 3. 页面设计测试 服务器端设计的测试 1. 容量规划的测试 2. 安全系统的测试 3. 数据库设计的测试

101 网站测试 对网站测试所采用的测试方法与策略 黑盒测试 白盒测试 静态测试和动态测试都有可能用到, 还会包括面向对象测试技术的运用 黑盒测试 ( 主要针对 Web 元素功能测试 ) 把网页或者整个网站当做是一个黑盒子 不管它如何工作 建立状态表 在测试网站时, 首先应建立状态表, 把每个网页当做不同的状态, 超级链接当做状态之间的连接线 完整的状态图有利于对整个网站更好地进行审视 测试 绝大多数网页都是由文字 图片 链接以及少量表单组成, 接下来, 测试这几个方面 103

102 网站测试 1) 文本 网页文本应该当做文档进行测试检查核实读者的水平 术语 内容以及题目素材 准确度 特别是可能过期的信息, 经常不断地检查拼写 如果有电子邮件地址 电话号码或者邮政编码等联系信息, 要检查是否正确 保证版权声明正确 日期无误 测试每个网页是否都有正确的标题, 标题文本的正确性 把鼠标光标移动到网页中的图片上时, 看看弹出对图片语义信息的说明是否正确 通过大幅缩放浏览器窗口来检查文字布局问题 不要依赖拼写检查工具来做 因为拼写检查不检查包含在图片 滚动块 表单等中的文字 104

103 网站测试 2) 超级链接 链接可以和文字或图片拴在一起 超链接一定要明显, 文字链接一般有下划线 每一个链接都能正常跳转 如果链接打开电子邮件信息, 就填写内容并发送, 要确保能够得到回应 查找孤页 ( 网站的一部分, 但是不能通过超级链接访问, 只有知道正确的 URL 地址才能访问 ), 需要向网站设计人员索取网页清单, 与自制的状态图进行比较 105

104 网站测试 3) 图片 ( 包括动画 边框 颜色 字体 背景 按钮等 ) 图片有明确的用途 : 不要胡乱地堆在一起, 浪费传输时间 验证所有页面字体的风格是否一致 颜色的搭配 : 背景色与字体色和前景色相搭配 图片的大小和质量 : 一般采用 JPG 或 GIF 压缩 所有的图片是否被正确载入和显示? 如果网页中文本和图片交织在一起, 要保证文字正确地环绕在图片周围 载入网页时的性能如何? 106

105 网站测试 4) 表单 表单是指网页中用于输入和选择信息的表格, 包括文本框 列表框和其它域等 表单有一些标准操作, 如确认 保存 提交等 表格 域的大小是否正确? 验证服务器是否接受 正确保存数据, 拒绝错误数据? 可选域是否真正可选 ; 提交操作的完整性等 107

106 网站测试 5) 对象和其它各种简单的功能 网站可能包含诸如单击计数器 滚动文本选择框 变换的广告和站内搜索等特性 在计划网站测试时, 要仔细验明每个网页上的所有特性, 把每一个特性按照常规程序的功能对待, 并分别进行测试 Cookies 测试 :Cookies 是否起作用 ; 是否按预定的时间进行保存 ; 刷新对 Cookies 有何影响等 108

107 网站测试 灰盒测试 灰盒测试是白盒测试和黑盒测试的结合 灰盒测试仍然把软件当做黑盒来测, 但是通过简单查看软件内部工作机制作为补充 网页特点使其非常适合进行灰盒测试 因为大多数网页是由 HTML 创建, 在 IE 上很轻易地就能看到源代码 109

108 网站测试 白盒测试 网页的静态内容一般由 HTML 直接创建 同时, 网页还包括可自定义和动态改变的内容 创建这些附加的动态特性需要用可以执行的程序代码来补充 创建此类特性的流行 Web 编程语言 :DHTML,Java,JavaScript, ActiveX,VBScript,Perl,CGI,VB.Net,C# 和 XML 等 运用白盒测试不需要测试员一定成为这些语言的专家, 而只要熟悉到能够阅读和理解这些语言, 并根据代码的内容来确定测试用例即可 110

109 网站测试 配臵和兼容性测试配臵测试是在各种硬件和软件平台类型以及其不同的设臵情况下检查软件运行的过程 兼容性测试是检查软件和其它软件一起运行的过程 要测试一个网站, 需要考虑可能会影响网站运行和外观的硬件和软件配臵 : 1) 硬件平台 ; 2) 浏览器软件和版本 ; 3) 浏览器插件 ; 4) 浏览器选项 ; 5) 视频分辨率和色深 ; 6) 文字大小 ; 7) 连接速率速率 111

110 网站测试 易用性测试 遵守并测试一些基本规则有助于使网站更加有用 1) 盲目使用不成熟的新技术 网站不应该靠吹嘘采用最新 Web 技术来吸引用户 2) 滚动文字 滚动块和不停运行的动画 不要让网页上有不停移动的元素 3) 滚动显示的长页面 减少滚动, 所有重要的内容和导航选项应该位于页面顶端 4) 非标准的链接颜色 指向用户未曾看过的页面的超级链接应该是蓝色 ; 指向已经看过的页面的链接应该是紫色或者红色 ( 下页续 ) 112

111 网站测试 易用性测试 ( 续 ) 5) 过期信息维护是加强网站内容的经济之道 6) 下载时间过长传统的人为因素规范指出 :0.1 秒是用户感觉系统反应迅速的极限 ; 1 秒是用户思路不间断的极限 ;10 秒是用户完全丧失兴趣的最长响应时间 7) 缺少导航支持需要以在结构和位臵上给人强烈感觉的形式进行支持 ; 站点设计应该从很好地了解信息空间的结构开始, 并把结构明确地传达给用户 8) 孤页所有网页一定要包含本身所属网站的明确指示, 因为用户可能不经过主页而直接访问网页 (continue) 113

112 网站测试 易用性测试 ( 续 ) 9) 复杂的网站地址 (URL) URL 应该包含反映网站内容的本质的便于人们阅读的名称 10) 使用框架 框架是允许在一个网页中显示其它网页的 HTML 技术 如果测试网站, 就要充分利用测试员的权限, 报告易用性方面的软件缺陷 回顾基本用户界面设计技术, 了解良好易用性的组成要素 114

113 网站测试 安全性测试 目录测试 : 目录下应该有 index.html 或 main.html 页面, 这样就不会显示该目录下的所有内容 套接字测试 : 确定加密是否正确 ; 是否有相应的替代页面 ( 适用于不支持 SSL 的浏览器, 如 IE3.0 以下版 ) 登录验证 : 测试有效和无效的用户名和密码 ; 超时 : 测试 Web 应用系统是否有超时的限制 ; 日志文件 : 测试相关信息是否写进了日志文件 是否可追踪 ; 脚本语言 : 是否有不安全代码 ; 在没有经过授权时, 是否能拒绝在服务器端放臵和编辑脚本 ; 115

114 网站测试 内容测试 目的是用来检验 Web 网站提供信息的正确性 准确性和相关性 数据库测试 数据库在 Web 网站中的作用 : 数据库为 Web 网站的管理 运行 查询和实现用户对数据存储的请求等提供空间 在 Web 应用中, 最常用的数据库类型是关系型数据库, 可以使用 SQL 对信息进行处理 两种主要数据库错误 : 数据一致性错误 : 主要是由于用户提交的表单信息不正确而造成 输出错误 : 主要是由于网络传输速度或程序设计问题等引起的 数据库测试就要针对这两种情况, 分别进行测试 116

115 网站测试 自动化测试 要对复杂的大型网站进行彻底的测试, 就需要用自动化的测试工具了 如, 服务器性能及负载 ( 压力 ) 测试 : 通过应用模拟的方法实现, 即通过某种程序方法 ( 工具软件 ) 模拟上万个链接和下载来判断服务器的响应时间 并发访问数量等性能与负载能力 117

116 对 Web 进行压力测试 Web 服务的特点 : 118 Web 服务处于分布式计算的核心位臵, 它们之间的交互通常很难测 分布式开发可能使 Web 服务的开发变得越来越容易隐藏错误 压力测试是检测这类代码错误的一种有效方法 Web 压力测试压力测试是系统测试的一部分, 要被设计为通过应用很大的工作负载来使软件超负荷运转, 目的是要弄清被测的 Web 服务是不是不仅能做预期应能做的事, 而且在被施加了某些高强度压力的情况下仍能继续正常运行 通过对软件保持高强度的压力测试 ( 不超过性能统计数字确定的限制 ), 经常能够发现许多其它测试无法发现的隐蔽错误 压力下的错误类型 内存泄露 通常要求操作重复非常多的次数后才会出现 并发与同步 118

117 对 Web 进行压力测试 ( 续 ) 119 图 Web 服务测试原理 119

118 对 Web 进行压力测试 ( 续 ) 有效的压力测试的关键条件 重复 : 就是一遍又一遍地执行某个操作或功能 这将确定一个操作能否正常执行, 并且能否继续在每次执行时都表现正常 并发 : 就是在同一时间内执行多个操作 由并发引起的错误只能通过执行多个代码示例才能测出来, 测试时要同时遍历多条代码路径 量级 : 要考虑到每个操作中的负载量, 操作自身应尽可能给被测软件系统增加压力, 即 : 尽量使单独的操作进行高强度的使用, 增加操作的量级 随机变化 : 随机使用前面条件中的无数变化形式, 就能够在每次测试运行时应用许多不同的代码路径

119 使用 WAS 进行 Web 负载测试 负载测试是任何 Web 应用开发周期中一个重要的环节 在构造一个为大量用户服务的应用之前, 搞清楚产品配臵能够承受多大的负载非常重要 但在实际开发过程中, 若要按照实际投入运行的情况, 组织成千上万的用户来进行压力测试, 无论从那个方面看, 都不现实 WAS 为了有效的对 Web 应用程序进行负载 ( 压力 ) 测试, 微软公司发布了简单易用 功能强大的 Web 应用负载测试工具 WAS(Web Application Stress Tool), 它能够提供一种简单的方法模拟大量用户访问目标网站, 而且还能够提供 Web 应用程序工作时对硬件和软件的使用情况 ACT ( Microsoft Application Center Test) 使用 WAS 进行 Web 负载测试?( 实验 )

120 Web 站点经验点滴 在执行客户端并发性能测试的过程中, 需要同时监控数据库服务器 Web 服务器以及网络资源等使用情况, 以便对系统的性能做全面评估 录制脚本和手工编写脚本相结合 设臵数据池, 实现变量加载 业务批量执行 模拟用户数的递增 合理设臵交易之间时间间隔 模拟 IP 地址变量的技术 超时 (timeout) 的设臵 并发用户连续执行交易数的设臵 错误处理 122

121 Web 站点经验点滴 采用复合交易测试方案 尽量将执行负载测试的机器合理分布 并发用户数量极限点 加压机器的 CPU 使用率也有必要监控 设臵并发点 HTML 与 URL 录制方式 123

122 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试实时系统测试 α 测试和 β 测试面向对象的软件测试其他测试调试 当前位臵 124

123 实时系统测试 实时系统测试 很多实时系统的时间依赖性和异步性给测试带来新的困难 测试用例的设计不仅考虑白盒和黑盒, 而且包括事件处理 ( 如中断处理 ) 数据的时间序列以及处理数据任务 ( 进程 ) 的并发性 很多情况下, 提供的测试数据有时使得实时系统在某状态下可以正常运行, 而同样的数据在系统处于不同状态时有时又会导致错误 另外, 实时系统的软硬件之间的密切关系也会导致测试问题, 软件测试必须考虑硬件故障对软件处理的影响, 这种故障很难实时仿真 由于实时系统的特殊性和复杂性, 还没有一个完善的综合性的测试用例设计方法, 但是, 大致可以分为以下四个步骤 :

124 实时系统测试 1 任务测试 第一步, 独立测试各任务 对每一个任务设计白盒和黑盒测试用例, 并在测试时执行每个任务 任务测试能够发现逻辑和功能错误, 但是不能发现时间和行为错误 2 行为测试 每种事件单独测试, 以随机顺序和随机频率将事件传送给系统, 检查系统有否行为错误 3 任务间测试 测试与时间有关的错误 任务间同步有否问题, 测试通过消息队列和数据存储进行通信的任务, 检查数据存储区域大小方面的问题 4 系统测试 集成软件和硬件, 并进行大范围的系统测试, 以发现软件 / 硬件接口间的错误

125 测试技术 常用测试 测试产品说明书文档测试配臵测试外国语言测试易用性测试基于应用服务器的测试 Client/Server 测试 网站测试 对 Web 进行压力测试实时系统测试 α 测试和 β 测试面向对象的软件测试其他测试调试 当前位臵 127

126 α 测试和 β 测试 在软件交付使用之后, 用户将如何实际使用程序, 对于开发者来说是无法预测的 α 测试 α 测试是由一个用户在开发环境下进行的测试, 也可以是公司内部的用户在模拟实际操作环境下进行的测试 α 测试的目的 是评价软件产品的 FLURPS( 即功能 局域化 可使用性 可靠性 性能和支持 ) 尤其注重产品的界面和特色 α 测试开始点 α 测试可以从软件产品编码结束之时开始, 或在模块 ( 子系统 ) 测试完成之后开始, 也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始

127 α 测试和 β 测试 β 测试 是由软件的多个用户在实际使用环境下进行的测试 这些用户返回有关错误信息给开发者 测试时, 开发者通常不在测试现场 因而,β 测试是在开发者无法控制的环境下进行的软件现场应用 用户记录问题反馈给开发方 在 β 测试中, 由用户记下遇到的所有问题, 包括真实的以及主观认定的, 定期向开发者报告 β 测试的目的 主要衡量产品的 FLURPS 着重于产品的支持性, 包括文档 客户培训和支持产品生产能力 β 测试开始点 只有当 α 测试达到一定的可靠程度时, 才能开始 β 测试 它处在整个测试的最后阶段 同时, 产品的所有手册文本也应该在此阶段完全定稿

128 面向对象的软件测试 1 面向对象测试的概念 2 开发前期的面向对象测试 2.1 面向对象分析的测试 2.2 面向对象设计的测试 2.3 面向对象编程的测试 3 开发后期的面向对象测试 3.1 面向对象的单元测试 3.2 面向对象的集成测试 3.3 面向对象的确认测试 3.4 面向对象的系统测试

129 面向对象的软件测试 1 面向对象软件测试概述 面向对象软件测试的目标与传统测试一样 即用尽可能低的测试成本和尽可能少的测试用例, 发现尽可能多的软件缺陷 面向对象的测试策略也遵循从 小型测试 到 大型测试, 即从单元测试到最终的功能性测试和系统性测试 变化 面向对象 = 对象 + 类 + 继承 + 通信 (Coad 和 Yourdon 定义 ) 新特点 : 封装 继承 多态

130 面向对象的软件测试 这些变化带来了产生新错误的可能, 带来了测试的变化 : 1) 基本功能模块 系统的基本构造单元不再是传统的功能模块, 而是类和对象 在测试过程中, 不能仅检查输入数据产生的输出结果是否与预期结果相吻合, 还要考虑对象的状态变化, 方法间的相互影响等 2) 系统的功能实现 系统的功能体现在对象间的协作上, 而不再是简单的过程调用 原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能 3) 封装对测试的影响 封装使对象的内部状态隐蔽, 如果类中未提供足够的存取函数来表明对象的实现方式和内部状态, 则类的信息隐蔽机制将给测试带来困难 132 ( 续 )

131 面向对象的软件测试 这些变化带来了产生新错误的可能性 : 4) 继承对测试的影响 继承削弱了封装性, 产生了类似于非面向对象语言中全局数据的错误风险 由于继承的作用, 一个函数可能被封装在具有继承关系的多个类中, 子类中还可以对继承的特征进行覆盖或重定义 5) 多态对测试的影响 多态依赖于不规则的类层次的动态绑定可能产生编程人员没有想到的结果 某些绑定能正确的工作但并不能保证所有的绑定都能正确地运行 以后绑定的对象可能很容易将消息发送给错误的类, 执行错误的功能, 还可能导致一些与消息序列和状态相关的错误 133

132 面向对象的软件测试 面向对象的开发模型突破了传统的瀑布模型, 将开发分为面向对象分析 (OOA), 面向对象设计 (OOD), 和面向对象编程 (OOP) 三个阶段 分析阶段产生整个问题领域的抽象描述, 在此基础上, 进一步归纳出适用于面向对象编程语言的类和类结构, 最后形成代码 针对这种开发模型, 结合传统的测试步骤的划分, 本着在整个开发过程中不断测试的原则, 应将开发阶段的测试与编码完成后的单元测试 集成测试 系统测试用一个测试模型描述 134

133 面向对象的软件测试 OO System Test OO Integrate Test OO Unit Test 最后阶段的测试, 需借鉴 OOA 和 OOD 测试的结果 对服务交互进行测试 OOA Test OOD Test OOP Test 单一功能模块的测试 OOA OOD OOP 对分析结果的测试对设计结果的测试对编程风格和程序代码的测试 135

134 面向对象的软件测试, 由上图可见, 开发阶段的面向对象的软件测试有 : 面向对象分析的测试 (OOA Test) 面向对象设计的测试 (OOD Test) 面向对象编程的测试 (OOP Test) 面向对象单元测试 (OO Unit Test) 面向对象集成测试 (OO Integrate Test) 面向对象系统测试 (OO System Test) OOA Test 和 OOD Test : 是对分析结果和设计结果的测试, 主要是对分析设计产生的文本进行, 是软件开发前期的关键性测试 136

135 面向对象的软件测试 OOP Test: 主要针对编程风格和代码实现进行测试, 其主要的测试内容在面向对象单元测试和面向对象集成测试中体现 面向对象单元测试 : 是对程序内部具体单一的功能模块的测试, 主要就是对类和类成员函数的测试 面向对象集成测试 : 主要对系统内部的相互服务进行测试, 如成员函数间的相互作用, 类间的消息传递等 面向对象集成测试不但要基于面向对象单元测试, 更要参见 OOD 或 OOD Test 结果 面向对象系统测试 : 主要以用户需求为测试标准, 也要借鉴 OOA 或 OOA Test 结果 137

136 面向对象的软件测试 2 开发前期的面向对象测试 面向对象的系统开发经历 : 面向对象分析 (OOA) 面向对象设计 (OOD) 面向对象编程 (OOP) 等三个阶段 在这个时期的测试工作主要是静态测试 通过各种评审和质量分析活动, 完成必须的测试工作, 及时检测和克服各种缺陷 138

137 面向对象的软件测试 2.1 面向对象分析的测试 (OOA Test) 面向过程分析 传统的面向过程分析是一个功能分解的过程, 是把一个系统看成可以分解的功能的集合 这种传统的功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程, 以过程的抽象来对待系统的需要 面向对象分析 (OOA) 是 把 E-R 图和语义网络模型, 即信息模型中的概念, 与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法, 最后得到问题领域的可视的形式描述 139

138 面向对象的软件测试 2.1 面向对象分析的测试 (OOA Test)( 续 ) OOA 直接映射问题空间, 全面的将问题空间中实现功能的现实抽象化, 将问题空间中的实例抽象为对象, 用对象的结构反映问题空间的复杂实例和复杂关系, 用属性和操作表示实例的特性和行为 对一个系统而言, 与传统分析方法产生的结果相反, 行为是相对稳定的, 结构是相对不稳定的, 这更充分反映了现实的特性 OOA 的结果是为后续阶段中类的选定和实现, 类层层次结构的组织和实现提供平台 OOA 测试的重点在其完整性和冗余性 OOA 对问题领域分析抽象的不完整, 最终会影响软件的功能实现, 导致软件开发后期大量可避免的修补工作 ; 而一些冗余的对象或结构会影响类的选定 程序的整体结构或增加程序员不必要的工作量 因此,OOA 测试的重点在其完整性和冗余性 140

139 面向对象的软件测试 - OOA Test 2.1 面向对象分析的测试 (OOA Test)( 续 ) 根据 Coad 和 Yourdon 方法所提出的 OOA 实现步骤, 对 OOA 阶段的测试划分为以下五个方面 : 1) 对认定的类的测试 2) 对认定的结构的测试 3) 对认定的主题的测试 4) 对定义的属性和实例关联的测试 5) 对定义的服务和消息关联的测试 141

140 面向对象的软件测试 - OOA Test 1) 对认定的类的测试 OOA 中认定的类是对问题空间中的结构, 其他系统, 设备, 被记忆的事件, 系统涉及的人员等实际实例的抽象 对它的测试可以从如下方面考虑 : 认定的类是否全面, 是否问题领域中所有涉及到的对象都反映在认定的类中 认定的类是否具有多个属性 只有一个属性的类通常应看成其他类的属性, 而不是抽象为独立的类 认定为同一个类的对象是否有共同的, 区别于其他类对象的共同属性 对认定为同一类的对象是否提供或需要相同的服务, 如果服务随着不同的对象而变化, 认定的对象就需要分解或利用继承性来分类表示 如果系统不需要始终保持类所代表的对象的信息, 认定的类也无必要存在 认定的类的名称应该尽量准确, 适用 142

141 面向对象的软件测试 - OOA Test 2) 对认定的结构的测试 认定的结构指的是多种对象的组织方式, 用来反映问题空间中的复杂实例和复杂关系 认定的结构分为两种 : 分类结构和组装结构 分类结构, 又称泛化结构, 体现了问题空间中, 对象的一般与特殊的关系 组装 ( 复合 ) 结构体现了问题空间中, 对象的整体与局部的关系 143

142 面向对象的软件测试 - OOA Test 对认定的分类结构 ( 泛化结构 ) 测试可从如下方面着手 : 对于结构中的一个类, 尤其是处于高层的类, 看是否能在问题领域中派生出其下一层的类 对于结构中的一个类, 尤其是处于同一低层的类, 看是否能抽象出在现实世界中有意义的更一般的上层的类 高层的对象的特性和服务是否完全体现下层的共性低层的对象是否基于其上层类的属性和服务并具有自己的特殊性 对认定的组装结构的测试从如下方面入手 : 整体类和局部类的聚合 ( 组装 ) 关系是否符合现实的关系 整体类的局部类是否在问题空间中有实际应用 整体类中是否遗漏了在问题空间中有用的局部类 局部类是否能够在问题空间中组装新的有现实意义的整体类

143 面向对象的软件测试 - OOA Test 3) 对认定的主题的测试 主题是在对象和结构的基础上更高一层的抽象, 是为了提供 OOA 分析结果的可见性, 如同文章对各部分内容的概要 对主题层的测试应该考虑以下方面 : 贯彻 George Miller 的 7+2 原则, 如果主题个数超过 7 个, 就要求对有较密切属性和服务的主题进行归并 主题所反映的一组类和结构是否具有相同和相近的属性和服务 认定的主题是否是类和结构更高层的抽象, 是否便于理解 OOA 结果的概貌 ( 尤其是对非技术人员的 OOA 结果读者 ) 主题间的消息连接 ( 抽象 ) 是否代表了主题所反映的类和结构之间的所有关联

144 面向对象的软件测试 - OOA Test 4 ) 对定义的属性和实例关联的测试属性描述类或结构中实例 ( 对象 ) 的特性 而实例连接则反映实例集合之间的映射关系 对属性和实例关联的测试从如下方面考虑 : 定义的属性是否对相应的类和泛化结构的每个实例都适用 定义的属性在现实世界中是否与这种实例关系密切 定义的属性在问题领域中是否与这种实例关系密切 定义的属性是否能够不依赖于其他属性被独立理解 定义的属性在泛化结构中的位臵是否恰当, 低层类的共有属性是否在其上层类的属性中有定义 问题领域中每个类的属性是否定义完整 定义的实例连接是否符合实际 在问题领域中实例连接的定义是否完整, 特别需要注意一对多和多对多的实例连接

145 面向对象的软件测试 - OOA Test 5) 对定义的服务和消息关联的测试定义的服务, 就是定义的每一种对象和结构在问题空间所要求的行为 由于问题空中实例间必要的通信, 在 OOA 中相应需要定义消息关联 对定义的服务和消息关联的测试从如下方面进行 : 类和结构在问题领域中的实例具有不同的状态, 是否为状态转换定义了相应的服务 类或结构所需要的服务是否都定义了相应的消息连接 定义的消息连接所调用的服务是否正确 沿着消息连接所执行的线索 ( 消息的调用序列 ) 是否合理, 是否符合实际 定义的服务是否有重复, 是否定义了能够得到的服务

146 面向对象的软件测试 2.2 面向对象设计的测试 (OOD Test) 面向对象设计 (OOD) 从 建模的观点 出发, 基于 OOA 模型归纳出类, 并建立类的层次结构或进一步构造成类库, 实现分析结果对问题领域的抽象 OOD 归纳出的类, 可以是 OOA 类的简单延续, 也可以是基于设计要求新建立或从已有类演化的类 因此,OOD 是 OOA 的进一步细化和更高层的抽象 OOD 确定类和类结构不仅是满足当前需求分析的要求, 更重要的是通过重新组合或加以适当的补充, 能方便实现功能的重用和扩增, 以不断适应用户的要求 148

147 面向对象的软件测试 2.2 面向对象设计的测试 OOD Test(continue) 对 OOD 的测试, 应从如下三方面考虑 : 对认定的类的测试 对构造的类层次结构的测试 对类库的支持的测试 对认定的类的测试 : 149 认定的类原则上应该尽量是基础类 是否涵盖了 OOA 中所有认定的对象 是否能体现 OOA 中定义的属性 是否能实现 OOA 中定义的服务 是否对应着一个含义明确的数据抽象 是否尽可能少的依赖其它类 类中的方法是否单用途

148 面向对象的软件测试 2.2 面向对象设计的测试 OOD Test(continue) 对构造的类层次结构的测试 : 为能充分发挥面向对象的继承共享特性,OOD 的类层次结构, 通常基于 OOA 中产生的泛化结构的原则来组织, 着重体现父类和子类之间一般性和特殊性关系 在当前的问题领域, 对类层次结构的主要要求是能在解空间构造实现全部功能的结构框架 为此应做如下几个方面的检查 : 类层次结构是否涵盖了所有定义的类 是否能体现 OOA 中所定义的实例关联 是否能实现 OOA 中所定义的消息关联 子类是否具有父类没有的新特性 子类间的共同特性是否完全在父类中得以体现 150

149 面向对象的软件测试 2.2 面向对象设计的测试 OOD Test(continue) 对类库支持的测试 : 对类库的支持虽然也属于类层次结构的组织问题, 但其强调的重点是软件的复用 由于它并不直接影响当前软件的开发和功能实现, 可以将其单独提出来测试 有关类库支持的测试可从以下几个方面入手 : 一组子类中关于某种含义相同或基本相同的操作, 是否有相同的接口 ( 包括名字和参数表 ) 类中方法的功能是否较单纯, 相应的代码行是否较少 ( 建议不超过 100 行 ) 类的层次结构是否是深度大, 宽度小 151

150 面向对象的软件测试 2.3 面向对象编程的测试 OOP Test 典型的面向对象程序具有继承 封装和多态的新特性, 这使得传统的测试策略必须有所改变 封装是对数据的隐藏, 外界只能通过被提供的操作来访问或修改数据, 这样降低了数据被任意修改和读写的可能性, 降低了传统程序中对数据非法操作的测试 继承使得代码的重用率提高, 同时也使错误传播的概率提高 多态使得程序内同一函数的行为复杂化, 测试时必须考虑不同类型具体执行的代码和产生的行为 152

151 面向对象的软件测试 2.3 面向对象编程的测试 OOP Test(continue) 面向对象程序是把功能的实现分布在类中 与某种设计功能相关的一组对象, 通过对象提供的服务和对象之间的消息传递, 共同协作来实现这个功能 这种面向对象程序风格, 可将出现的错误精确定位在某一个具体的对象 因此, 在面向对象编程 (OOP) 阶段, 忽略类功能实现的细则, 将测试的目光集中在类功能的实现和相应的面向对象程序风格, 主要体现为以下两个方面 数据成员是否满足数据封装的要求 类是否实现了要求的功能 153

152 面向对象的软件测试 1 数据成员是否满足数据封装的要求 检查数据成员是否满足数据封装的要求, 就是检查其数据成员是否能被外界 ( 数据成员所属的类或子类以外的调用 ) 直接调用 更直观的说, 当改变数据成员的结构时, 看其是否影响了类的对外接口, 是否会导致相应外界必须改动 值得注意, 有时强制的类型转换会破坏数据的封装特性 例如 : 154

153 面向对象的软件测试 class Hiden { private: int a = 1; } class Visible { char *p = "hiden"; public: int b = 2; char *s = "visible"; }.... Hiden pp; Visible *qq = (Visible *)& pp; 在上面的程序段中,pp 的数据成员可以通过 qq 被随意访问 155

154 面向对象的软件测试 2 类是否实现了要求的功能 类的功能都是通过类的成员函数实现的 在测试类的功能实现时, 应该首先保证类成员函数执行的正确性 单独地看类的成员函数, 与过程性程序中的函数或过程没有本质的区别, 几乎所有传统的单元测试中使用的方法, 都可在面向对象的单元测试中使用 类函数成员的正确行为只是类能够实现要求功能的基础, 而类成员函数之间的交互和类之间的服务调用是单元测试无法确定的 因此需要进行面向对象的集成测试 需注意的是, 测试类的功能, 不能仅满足于被测试代码能无错运行或被测试类提供的功能无错, 还应该以 OOD 结果为依据, 检测类提供的功能是否满足设计的要求, 是否有缺陷 必要时 ( 如通过 OOD 结果仍不清楚明确的地方 ) 还应该参照 OOA 的结果, 并以其为最终标准 156

155 面向对象的软件测试 ( 续 ) 3 开发后期的面向对象测试 157 编程完成之后, 需要经历若干个阶段的测试 : 单元测试 集成测试 验收测试 系统测试 3.1 面向对象的单元测试 传统的单元测试对象 : 模块 多采用白盒测试技术 当考虑面向对象软件时, 单元的概念发生了变化 封装意味着每个类和类的实例 ( 对象 ) 包装了属性 ( 数据 ) 和操纵这些数据的操作, 而不是个体的模块 最小的可测试单位是封装的类或对象, 类包含一组不同的操作 一个对象有它自己的状态和依赖于状态的行为, 对象操作既与对象的状态有关, 也可能改变对象的状态 单元测试的意义发生了较大变化, 我们不再孤立地测试单个操作, 而是将操作作为类的一部分

156 面向对象的软件测试 3.1 面向对象的单元测试 ( 续 ) 传统的单元测试主要关注模块的算法和模块接口间数据的流动 ; 而面向对象软件的类测试主要是测试封装在类中的操作以及类的状态行为 为此需要分两步走 : 1) 测试与对象相关联的单个操作它们是一些函数或程序, 传统的白盒测试和黑盒测试方法都可以使用 2) 测试单个对象类黑盒测试的原理不变, 但等价划分的概念要扩展以适合操作序列的情况 158

157 面向对象的软件测试 1. 对象操作的测试 在设计测试用例时, 可基于以下两个假设 : 如果操作 ( 成员函数 ) 对某一类输入中的一个数据正确执行, 对同类中的其他输入也能正确执行 如果操作 ( 成员函数 ) 对某一复杂度的输入能够正确执行, 则对更高复杂度的输入也应能正确执行 例如需要选择字符串作为输入时, 基于本假设, 就无需计较字符串的长度 除非字符串的长度是固定的, 如 IP 地址字符串 注意 : 1) 在面向对象程序中, 对象的操作 ( 成员函数 ) 通常都很小, 功能单一, 函数之间调用频繁, 容易出现一些不宜发现的错误 例如 : 159

158 面向对象的软件测试 1) if (write(fid, buffer, amount) == -1 ) error_out(); 该语句没有全面检查 write() 的返回值, 无意中假设了只有数据被完全写入和没有写入两种情况 此测试还忽略了数据部分写入的情况, 就给程序遗留了隐患 2) 按程序的设计, 使用函数 strrchr() 查找最后的匹配字符, 但程序中误写成了函数 strchr(), 使程序功能实现时查找的是第一个匹配字符 3) 程序中将 if ( strncmp(str1, str2, strlen(str1)) ) 误写成了 if ( strncmp(str1, str2, strlen(str2)) ) 如果测试用例中使用的数据 str1 和 str2 长度相同, 就无法检测出 因此, 在设计测试用例时, 应对以函数返回值作为条件判断, 字符串操作等情况特别注意 160

159 面向对象的软件测试 2) 面向对象编程的特性使得对成员函数的测试, 又不完全等同于传统的函数或过程测试 尤其是继承特性和多态特性,Brian Marick 提出了两点 : (1) 继承的成员函数可能需要重新测试 对父类中已测试过的成员函数, 两种情况需要在子类中重新测试 : 继承的成员函数在子类中做了改动 ; 成员函数调用了改动过的成员函数 例如 : 假设父类 Bass 有两个成员函数 :Inherited() Redefined() 若子类 Derived 对 Redefined() 做了改动, Derived::Redefined() 必需重新测试 但如果 Derived::Inherited() 包含有调用 Redefined() 的语句 ( 如 :x = x / Redefined()), 就需要重新测试 ; 反之, 则不必重新测试 161

160 面向对象的软件测试 (2) 对父类的测试用例不能照搬到子类 根据以上的假设,Base::Redefined() 和 Derived::Redefined() 是不同的成员函数, 它们有不同的说明和实现 对此, 应该对 Derived::Redefined() 重新设计测试用例 由于面向对象的继承性, 使得两个函数还是有相似之处, 故只需在 Base::Redefined() 的测试用例基础上添加对 Derived::Redfined() 的新测试用例 例如 : Base::Redefined() 含有如下语句 if ( value < 0 ) message ("less"); else if ( value == 0 ) message ("equal"); else message ("more"); Derived::Redfined() 中定义为 162

161 面向对象的软件测试 if ( value < 0 ) message ("less"); else if ( value == 0 ) message ( It is equal"); else { message ("more"); if ( value == 88 ) message("luck"); } 在原有的测试上, 对 Derived::Redfined() 的测试只需做如下改动 : 改动 value == 0 的预期测试结果, 并增加 value == 88 的测试 包含多态和重载多态在面向对象语言程序中通常体现在子类与父类的继承关系上, 对这两种多态的测试可参照对父类成员函数继承和重载的情况处理 163

162 面向对象的软件测试 2. 对象类测试 在测试对象时, 完全的覆盖测试应当包括 : 隔离对象中所有操作, 进行独立测试 测试对象中所有属性的设臵和访问 测试对象的所有可能的状态转换 所有可能引起状态改变的事件都要模拟到 对象类, 作为在语法上独立的构件, 应当允许在不同应用中使用 每个类都应是可靠的且不需了解任何实现细节就能复用 因此对象类应尽可能孤立地进行测试 167

163 面向对象的软件测试 设计操作的测试用例时的要点 : 首先定义测试对象各操作的测试用例 对于一个单独的操作, 可通过该操作的前臵条件选择测试用例, 产生输出, 让测试者能够判断后臵条件是否能够得到满足 各个操作的测试与传统对函数过程定义的测试基本相同 然后再把测试用例组扩充, 针对被测操作调用对象类中其他操作的情况, 设计操作序列的测试用例组 测试可以覆盖每个操作的整个输入域 但这不够, 还必须测试这些操作的相互作用, 才能认为测试是充分的 各个操作间的相互作用包括类内通信和类间通信 168

164 面向对象的软件测试 设计对象类的规格说明测试时的要点 : 把对象类当做一个黑盒, 确认类的实现是否遵照它的定义 例如, 对于 栈 的测试应当确保 LIFO 原则得以实施 对于多数对象类, 主要检验在类声明的 public 域中的那些操作 对于子类, 要检查继承父类的 public 域和 protected 域的那些操作 检查所有 public 域,protected 域及 private 域中的操作以完全检查对象中定义的操作 等价划分的思想也可用到对象类上 将使用对象相同属性的测试归入同一个等价划分集合中 这样可以建立对对象类属性进行初始化 访问 更新等的等价划分 169

165 面向对象的软件测试 在设计对象类的行为测试时需要注意 : 基于对象的状态模型进行测试时, 首先要识别需要测试的状态的变迁序列, 并定义事件序列来强制执行这些变迁 原则上应当测试每一个状态变迁序列, 当然这样做测试成本很高 完全的单元应当保证类的执行必须覆盖它的一个有代表性的状态集合 构造函数和消息序列 ( 线程 ) 的参数值的选择应当满足这个规则 170

166 面向对象的软件测试 3.2 面向对象的集成测试 传统的集成测试, 有两种方式通过集成完成的功能模块进行测 : 自顶向下集成 自底向上集成 当开发面向对象系统时, 集成的层次并不明显 而当一组对象类通过组合行为提供一组服务时, 则需将它们一起测试, 这就是簇测试 此时不存在自底向上和自顶向下的集成 171

167 面向对象的软件测试 3.2 面向对象的集成测试 ( 续 ) 对象集成测试又称交互测试, 目的是确保对象的消息传递能够正确进行 面向对象系统的集成测试有 3 种可用的方法 : 1) 用例或基于场景的测试 用例或场景描述了对系统的使用模式 测试可以根据场景描述和对象簇来制定 这种测试着眼于系统结构, 首先测试几乎不使用服务器类的独立类, 再测试那些使用了独立类的下一层次的 ( 依赖 ) 类 这样一层一层地持续下去, 直到整个系统构造完成 2) 基于线程的测试 它把为响应某一系统输入或事件所需的一组对象类组装在一起 每一条线程将分别测试和组装 因为面向对象系统通常是事件驱动的, 因此这是一个特别合适的测试形式 172

168 面向对象的软件测试 ( 续 ) 3.2 面向对象的集成测试 ( 续 ) 3) 对象交互测试 这个方法提出了集成测试的中间层概念 中间层给出叫做 方法 - 消息 路径的对象交互序列 所谓 原子系统功能 就是指一些输入事件加上一条 方法 - 消息 路径, 终止于一个输出事件 集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误 集成测试只关注于系统的结构和内部的相互作用 面向对象的集成测试可以分成两步进行 : 先进行静态测试, 再进行动态测试

169 面向对象的软件测试 ( 续 ) 3.2 面向对象的集成测试 ( 续 ) 1) 静态测试 静态测试主要针对程序的结构进行, 检测程序结构是否符合设计要求 ; 通过源程序得到类关系图和函数功能调用关系图 将得到的结果与 OOD 的结果相比较, 检测程序结构和实现上是否有缺陷 换句话说, 通过这种方法检测 OOP 是否达到了设计要求

170 面向对象的软件测试 ( 续 ) 3.2 面向对象的集成测试 ( 续 ) 2) 动态测试 动态测试在设计测试用例时, 通常需要上述的功能调用结构图 类关系图或者实体关系图为参考, 确定不需要被重复测试的部分, 从而优化测试用例, 减少测试工作量, 使得进行的测试能够达到一定覆盖标准 测试所要达到的覆盖标准可以是 : 达到类所有的服务要求或服务提供的一定覆盖率 ; 依据类间传递的消息, 达到对所有执行线程的一定覆盖率 ; 达到类的所有状态的一定覆盖率等 考虑使用现有的一些测试工具来得到程序代码执行的覆盖率

171 面向对象的软件测试 ( 续 ) 3.2 面向对象的集成测试 ( 续 ) 具体设计测试用例, 可参考下列步骤 : 先选定检测的类 ; 参考 OOD 分析结果, 仔细列出类的状态和相应的行为 类或成员函数间传递的消息 输入或输出的界定等 确定覆盖标准 利用结构关系图确定待测试类的所有关联 根据程序中类的对象构造测试用例, 确认使用什么输入激发类的状态 使用类的服务和期望产生什么行为等 注意, 设计测试用例时, 不但要设计确认类功能能够成功执行的输入, 还应该有意识的设计一些会导致异常的输入, 确认类是否有不合法的行为产生, 如发送与类状态不相适应的消息, 要求不相适应的服务等 根据具体情况, 动态的集成测试, 有时也可以通过系统测试完成

172 面向对象的软件测试 ( 续 ) 面向对象软件集成测试的 UML 支持 在采用 UML 定义的面向对象软件中, 协作图和序列图是集成测试的基础 协作图显示了类之间的信息传递情况 它既支持对方法为单元的测试, 也支持相邻类的集成测试 序列图跟踪通过协作图的执行时间路径 ( 消息的前后相继关系 ) 序列图有两个层次的, 一个是系统 / 用例级别的, 一个是类交互级别的 它们是面向对象集成测试的很好的基础 实试中, 可根据协作图和序列图来建立测试用例, 来确定测试覆盖的标准 177

173 面向对象的软件测试 ( 续 ) 3.3 面向对象的确认测试 与传统的确认测试一样, 面向对象软件的有效性集中在用户可见的动作 ( 事件驱动与过程 ) 和用户可识别的系统输出 ( 结果 ), 通过测试检验软件是否满足用户的需求 在面向对象的确认测试中, 通常采用传统的黑盒测试方法, 以证明软件功能和需求的一致性

174 面向对象的软件测试 ( 续 ) 3.4 面向对象的系统测试 系统测试应尽量搭建与用户实际使用环境相同的测试平台, 应该保证被测系统的完整性, 对临时没有的系统设备部件, 也应有相应的模拟手段 系统测试时, 应该参考 OOA 分析的结果, 对应描述的对象 属性和各种服务, 检测软件是否能够完全再现问题空间 系统测试不仅是检测软件的整体行为表现, 从另一个侧面看, 也是对软件开发设计的再确认 它与传统的系统测试一样, 可套用传统的系统测试方法 179

175 分布式系统的测试 分布式处理中涉及的最基本单位是线程, 线程是操作系统进程内部能够独立运行的内容, 它拥有自己的程序计数器和本地数据 线程是能够被调度执行的最小单位 分布式系统测试主要面临的问题是并发性 网络化和分布式 并发性是指多个线程同时发生 针对并发性错误的测试主要着重于两个线程的交互 在实际实施交互机制之前应对相关方法进行测试 180 软件工程

176 分布式系统的测试 在网络环境中各个独立的盒子连接到通信设施上, 如何实现它们物理上的同步是网络计算的问题 相关的测试就是在组成一个网络系统的各个自治机器之间同步问题的测试 分布式系统使用多进程来支持系统的灵活性一个对象既可以在同一台机器上分布在多个进程中, 还可以分布在多个物理上的计算机上 所有这些分布式构件都要能够识别 命名服务 或 注册 对象, 能够与其他构件交互 所有在配臵文件中登记的机器与构件构成基础结构 需要考虑与这些分布式构件相关的测试 181 软件工程

177 分布式系统的测试 分布式系统中的路径测试 一条路径是一系列逻辑上连续的语句, 它只有在特定的输入下才执行 路径的另一个定义是覆盖变量的定义和使用就形成一条完整的路径 在分布式系统中的路径就是设计测试用例覆盖一个同步顺序 所谓同步顺序是指同步事件按照特定次序发生的顺序, 而同步事件是指一个线程产生另一个线程 测试应跟踪一个事件到另一个事件的路径 如果从一个同步事件到另一个同步事件有多条可能的控制流路径, 只需覆盖其中一条路径 182 软件工程

178 分布式系统的测试 生存周期测试 在分布式系统中, 生存周期测试是指选择一系列测试用例, 测试任何处于生存期中的对象 特别是在整个生存周期过程中存在多条路径, 测试必须选择有代表性的路径以保证最大的覆盖范围 对于一个类来说, 生存周期意味着选择一系列测试, 每个测试构造类的一个实例, 并通过一系列消息来使用实例, 最后再撤销这个实例 一个有效的生存周期测试应能证实对象本身是否正确, 还应能证实被测试项是否能够与它所在的环境正确地交互 对于一个类的实例, 在它被撤销后必须检查它占用的资源是否已被释放掉 183 软件工程

179 分布式系统的测试 分布式模型 下面介绍用在分布式系统中的使用某些标准基础结构的测试过程 1) 基本的客户机 - 服务器模型 客户机 - 服务器模型是最简单的分布式模型 在这种模型下, 多个客户机都可访问服务器 服务器是单一进程 由于所有客户机都与同一个服务器交互, 因此存在单点失败 ( 即服务器出现问题将影响所有客户机 ) 测试要点 : 在延时期间, 面对同时收到的服务请求, 服务器能否把正确结果发送给各个相应的客户机? 服务器能否处理快速增长的负载? 当负载增加时, 服务器的性能可能降低, 因此可能选择放弃一部分负载 184

180 分布式系统的测试 2) 标准分布式模型 - CORBA CORBA 是对象管理组织 OMG 开发的公共对象请求代理体系结构, 并将它作为分布对象系统的标准体系结构 这种结构的核心是对象请求代理 (ORB), 一个对象通过 ORB 与系统中的另一个对象通信 CORBA 标准的特点 : 与基础结构相联系的机器可能有不同的操作系统和不同的存储设计 ; 构成分布式系统的构件可以用不同的语言编写 ; 根据对象的分布性和网络中机器的类型, 基础结构可以改变它自身的配臵 185

181 分布式系统的测试 测试要点 : 不考虑基础结构的配臵, 系统能够正确的工作? 测试用例应能产生被测试基础结构的各种预期的配臵 在标准基础结构的服务基础上, 构造新的测试用例能否被重复使用? 测试用例的设计应尽可能地使用基础结构 新发布的特定基础结构能否与已有的应有有效地结合起来? 应有一系列的回归测试, 使得新发布的基础结构能够在被集成到产品中之前得到测试 186

182 分布式系统的测试 3) 标准分布式模型 - DCOM DCOM 是 Microsoft 开发并鼓励的一种标准的分布式构件对象模型 DCOM 标准 被描述为包含特定方法的标准接口, 每个标准接口都提供了一套特定的服务 单个构件可以完成几个接口的服务, 或若干构件中的每一个都能完成统一接口的服务, 只是方式不同 DCOM 是低层次的技术, 支持构件间最原始的联系, 它不作为应用开发的部分 187

183 分布式系统的测试 测试要点 : 在对各种构件做任意配臵时测试者能否正确编排唯一的标识? 测试用例应能利用各种构件确保所有必要的连接能够成功 每个构件能否实现必要的接口? 测试用例应能利用各种构件确保所有服务是可利用的并能实现期望的功能 标准接口的实现能否提供正确的行为? 应针对每一种标准接口有一套测试 188

184 分布式系统的测试 4) 标准分布式模型 - RMI RMI 是 Java 中的远程方法调用包, 它提供一种简化的分布式环境, 该环境假定不论连接的是什么样的或什么类型的机器, 它们都能运行 Java 虚拟机 RMI 提供一个注册对象, 参与分布式系统的所有对象必须知道该注册对象监听到哪个端口的消息 RMI 的最新版本使用 ORB 的 Internet 协议 (IIOP), 使 RMI 对象与 CORBA 对象共同工作 测试要点 : 那些种 CORBA 测试模式能够在以 RMI 为基础的系统上使用? 测试用例的构造很多与 CORBA 的测试用例相同 189

185 分布式系统的测试 5) 一般分布式构件模型 分布式系统的基本体系如图, 主要活动是服务请求方给服务提供方法送消息 请求首先发送给请求方本地的代理对象, 代理方联系通信基础结构并传送请求, 通信基础结构实例化服务提供方, 从对象定位器的服务中获得服务提供方的引用, 并将服务请求传递给它 如果存在结果, 则结果沿原路径返回 由于请求代理方可以引导请求, 所以提供方不知道分布的细节 服务请求方 服务提供方 提供方代理 提供方代理 进程 A 通信和定位服务 190 进程 B

186 分布式系统的测试 用于提供方构件的测试的要点 : 根据规范准备测试用例 ProviderTest 类应包括相应测试驱动程序, 该类继承自 GenericModelTester 设计基于说明的测试用例 : 对提供方可提供的一系列基于分布式系统的服务设计测试用例, 放在 GenericModelTester 类中, 对基于特殊应用服务设计的测试用例则放在 ProviderTest 类中 设计基于实现的测试用例 : 满足路径或代码覆盖的范围标准 设计交互式测试用例 : 提供方应与请求服务且具有代表性的请求方交互 每个主要的协议都应得到测试, 且至少有一个请求方参与到这个协议中来 设计基于状态的测试用例 : 当请求方发出请求时, 提供方可能只处于一种状态 但它可能同时从多个请求方接收请求, 因此应使用所有必要的协议, 使提供方经历所有可能的状态 191

187 分布式系统的测试 用于请求方构件的测试的要点 : 根据规范准备测试用例 RequesterTest 类应包括相应测试驱动程序 在这个类中应提供用于执行功能性 结构性和交互性测试用例的操作 测试类在应用程序中可当作交互类使用 设计基于说明的测试用例 : 在 API 文档中构造每个方法的前臵条件和后臵条件 执行用于每个方法中每个后臵条件中所有语句的测试用例 设计基于实现的测试用例 : 满足一般的范围标准 设计交互式测试用例 : 重点放在请求方与每个提供方之间的完整协议 为使得计时效果较为明显, 应适当插入人为延时 设计基于状态的测试用例 : 请求方有一系列与它自己的分布相关的状态, 如与基础结构相连或撤销连接等 测试应包括一系列经历所有这些状态的测试用例, 还应包含与应用语义学相关的一些状态 192

188 分布式系统的测试 6) 最大的分布式系统 - Internet 测试 因特网上可以连接 增加或删除服务器 这类测试重点在 Web 服务器上和因特网应用程序的生存周期上 a)web 服务器测试 Web 服务器体系结构如图所示 Web 页面和浏览器 应用服务器协作产生应用 应用程序 应用程序 应用程序 Web 服务器 数据库 浏览器 显示页面 193

189 分布式系统的测试 这些系统使得用户服务自动化 : 页面接受输入, 并放入一个用户订购表中 然后产生一条顾客记录, 调用能够自动产生一个账号和密码的应用程序 最后把账号信息通过 发送给用户 测试涉及两方面 首先, 执行脚本看它所做的工作是否是其所期望做的? 其次, 检查应用程序和网页所期待的当前数据是否正确 是否是所期望的格式? b) 因特网应用程序生存周期的测试 跨越不同平台的一系列用户事务测试 194

190 其他测试 可使用性测试 主要从使用的合理性和方便性等角度对软件系统进行检查, 发现人为因素或使用上的问题 要保证在足够详细的程度下, 用户界面便于使用 ; 对输入量可容错 响应时间和响应方式合理可行 输出信息有意义 正确并前后一致 ; 出错信息能够引导用户去解决问题 软件文档全面 正规 确切 敏感性测试 : 是强度测试的一个变种 在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现, 或者导致极度的性能下降的情况发生 此测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合

191 其他测试 安装测试 安装测试的目的不是找软件错误, 而是找安装错误 在安装软件系统时, 会有多种选择 要分配和装入文件与程序库 布臵适用的硬件配臵 进行程序的联结 而安装测试就是要找出在这些安装过程中出现的错误 安装测试是在系统安装之后进行测试 它要检验 : 用户选择的一套任选方案是否相容 ; 系统的每一部分是否都齐全 ; 所有文件是否都已产生并确有所需要的内容 ; 硬件的配臵是否合理, 等等

192 其他测试 可靠性测试 平均无故障时间 因故障停机时间 ( 需要模拟运行环境 ) 大数据量测试 企图证明程序不能处理目标中指出的大批数据 并发负载测试 在一定工作负荷和配臵条件下, 系统响应时间及处理速度 疲劳测试 让程序在高负荷下运行一段时间 ( 微软建议 72 小时 ) 存储量测试 测试软件所占用的内外存容量

193 其他测试 可启动 / 停止测试 系统启动及关机阶段, 能否正常运行 互连测试 测试不同系统间的互连性 可维护性测试 对维护过程和难易程度进行测试

194 测试技术 常用测试 测试产品说明书配臵测试外国语言测试易用性测试文档测试网站测试对 Web 进行压力测试 α 测试和 β 测试 Client/Server 测试实时系统测试面向对象的软件测试其他测试调试 当前位臵 200

195 调试 软件调试和软件测试有完全不同的含义 : 测试 : 目的是显示存在的错误 是可以系统进行的计划过程, 可以指导测试用例设计, 定义测试策略, 测试结果可以和预期的结果进行对照评估 测试是检验, 发现可疑的错误征兆 调试 : 目的是发现错误或导致程序失效的错误原因, 并修改程序以修正错误 是测试发现错误之后消除错误的过程 调试充分利用测试结果和测试提供的信息, 全面分析, 找出错误根源, 修正错误 成功的测试发现错误的症状引起调试的进行 调试比开发难以让人理解

196 调试 测试与调试的主要区别? (1) 测试从一个侧面证明程序员的失败 ; 调试证明程序员的正确 ; (2) 测试从已知条件开始, 使用预先定义的程序, 且有预知的结果, 不可预见的仅是程序是否通过测试 ; 调试从不可知内部条件开始, 除统计性调试外, 结果是不可预见的 ; (3) 测试有计划并且要进行测试设计 ; 调试不受时间约束 ; (4) 测试是发现错误 改正错误 重新测试的过程 ; 调试是一个推理的过程 ; (5) 测试执行是有规程的 ; 调试执行要求程序员进行必要的推理 ; (6) 测试由独立的测试组在不了解软件设计的条件下完成 ; 调试由了解详细设计的程序员完成 ; (7) 大多数测试的执行和设计可由工具支持 ; 调试用的工具主要是调试器 202

197 调试过程 测试用例 执行用例 执行结果 无错 回归测试 附加测试 被怀疑的原因 有错 纠正 已识别的原因 调试 调试有两种结果 : 发现问题原因, 改正 未发现问题原因, 假设一个错误原因, 设计 Testcase 验证假设

198 调试 调试的困难在于 : 症状和原因可能相距很远, 高度耦合的程序结构加深了这种情况 症状可能在另一错误改正后消失或暂时性消失 症状可能不是有软件错误引起的 ( 如舍入误差 ) 症状可能有人为错误引起 症状可能由于时间问题而不是处理问题 可能难以再现症状出现的输入条件 症状可能间断出现的 症状可能由分布在许多不同任务中的原因引起的

199 例 : 台灯不亮了 1 是否整个屋子无电 : 总闸, 外面坏了 判断邻居家也黑 2 否, 台灯插到外面插座 ( 不亮 ) 或把正常电器插到此插座上 ( 可正常工作 ) 3 台灯坏了 4 换好灯泡, 亮了 ( 原灯泡坏了 ) 技术 : 使用断点, 桌面检查, 内存转储, 审查, 可逆执行, 单步操作和跟踪, 调试是对在测试与正常操作中已发现错误的反馈

200 调试的三种实现方法 蛮力法 (Brute force) 回溯法 (Backtracking) 原因排除法 (Cause elimination) 每种方法都可以使用调试工具辅助完成 带调试功能的编译器 动态调试辅助工具 ( 跟踪器 ) 自动的测试用例生成器 内存映像工具 交叉引用工具

201 调试 (Debug) 修正错误, 可能带来其它错误 Van Vleck 提出每个软件工程师排错修改前问三个问题 : 这个错误原因在程序其它地方也产生过吗? 我要进行的修改, 可能会引发的 下一个错误 是什么? 为防止这个错误, 我们应当做什么?