201042284353软件测试的十个认识误区

2 整体认识上重开发而轻测试
有人曾作过这样的调查 , 如果将整个软件项目 制 作 过 程 中 的 各种活动按重要程度进行排序 , 结果软件测试几乎从未 名 列 前 茅 过 。 另外 , 如果在软件项目面临着时间压力 , 必须加快研制速度的 情况下 , 通常软件测试会成为换取项目进度的牺牲品 。 由 此 可 见 测试在人们心目中的地位 , 重开发而轻测试是软件开发 中 颇 为 普 遍的一种现象 。 有研究数据显示 , 国外软件开发机构 40% 的工作量花在软件 测试上 , 软件测试费用占软件项目总费用的 30%～50% 。 而根据对 国际著名 IT 企业的统计 , 它 们 的 软 件 测 试 费 用 占 整 个 软 件 工 程 所有研发费用的 50% 以上 。 对 测 试 的 重 视 更 体 现 在 人 员 的 配 置 上 , 微 软 在 开 发 Windows 2000 产 品 的 过 程 中 , 项 目 经 理 约 占 250 人 , 开发人员约为 1700 多人 , 但其内部的测试人员就多达 3200 人。 只 有 整 个 业 界 ,上 从 管 理 层 下 到 具 体 的 测 试 人 员 ,都 真 正 地 从认识上重视起软件测试来 , 才有可能建立起规范的测 试 体 系 , 软件产品的质量也才能得到保证 。
bug , 如果软件测试直到项目生命周 期 的 后 期 才 予 以 考 虑 , 那 么 修
改软件的代价就会很昂贵 , 付出的代价要大得多 。
4 测试工作不需要成立专门的测试组
软件测试工作是很复杂的一件工作, 因此要很好地完成项 目 , 必须成立专门的测试组 。 测试组能力的高低 会 极 大 地 影 响 测 试工作的成败 , 没有一个合格的 、 积极的测试小组 , 测 试 就 不 可 能 成功实现 。 以前在软件开发中 , 测试人员往往隶属于开发团队 , 由 开发人员兼职担任测试工作 , 这对测试非常不利 。 把测试作为新手的一个过渡工作对测试 本 身 是 一 种 伤 害 , 最 终导致测试越来越薄弱 , 效果越来越差 。 对一个 系 统 进 行 有 效 的 测试所需要的技能绝对不比进行软件开发需要的 少 , 一 个 测 试 者 必须既明白被测软件系统的概念又要会使用工程 中 的 那 些 工 具 。 要做到这一点需要有几年以上的编程经验 , 前期 的 开 发 经 验 可 以 帮助对软件开发过程有较深入的理解, 从而更好地完成测试工 作。
3 测试只是项目活动结束之前的一个独立阶段
随 着 软 件 产 品 越 来 越 大 ,复 杂 性 越 来 越 高 ,测 试 工 作 已 不 再 是项目活动结束之前的一个独立阶段 。 开发完成之后再着手软件测试是人们普遍存在 的 认 识 误 区 。 现代的测试应该贯穿于整个软件项目生命周期的各个阶 段 , 测 试 计划应该早在需求分析阶段就开始制定 , 这样可以有效 地 克 服 测 试的盲目性 , 提高测试效率 。 早期的 bug 可 能 会 导 致 后 期 的 多 个
(5) 智 能 答 疑 系 统 , 实 现 对 关 键 词 的 提 问 进 行 智 能 搜 索 、 关 键
词标的维护 、 问题的整理等功能 。
4 总结
当今时代是一个信息共享的时代和信息大爆 炸 的 时 代 , 校 园 有 了 校 园 网 ,我 们 应 该 充 分 挖 掘 它 的 积 极 因 素 ,让 教 师 和 学 生 通 过校园网这一个技术平台更好的为我们的教育服务 。 提高教学效 果和学习效率 。 达到目的 , 或者项目小组将发布质量欠佳的产品 。 事实上 , 也不需 要对所有的软件缺陷进行修复 , 其原因是多方面的 :(1 ) 没 有 足 够 的 时 间 ,任 何 一 个 项 目 的 开 发 都 有 一 定 的 时 间 限 制 ,在 进 度 压 力 下要修复所有软件缺陷常常是难以实现的 ;(2 ) 有 些 看 起 来 的 缺 陷其实并不算真正的软件缺陷 ;(3 ) 修复的风险太大 , 软 件 本 身 是 脆弱的 , 修复一个软件缺陷可能会导致其他软件缺陷 出 现 。 在 紧 迫的产品发布进度压力之下 , 修改软件将冒很大的风险 。 (4 ) 不值 得修复 , 不常出现的软件缺陷和在不常用功能中出现 的 软 件 缺 陷 可以放过 , 用户有办法预防或避免的软件缺陷通常也 不 用 修 复 , 这些要归结为商业风险决策 。
1 引言
随着信息技术和互联网应用的迅速推广普及 , 计 算 机 的 应 用 领域在不断扩大 , 软件产品已经渗透到人类生活的各个 环 节 。 随 着竞争的日趋激烈 , 软件开发组织越来越认识到软件质 量 的 重 要 性 , 只有高质量的产品才能在竞争中取胜 。 软件测试作 为 发 现 软 件中错误和缺陷的一种主要手段 , 已经引起了软件产品 用 户 和 软 件开发人员越来越多的关注 。 但是 , 人们对软件项目的 测 试 工 作 常常存在一些认识上的误区 , 下面就总结列举 10 条 这 样 的 认 识 误区 。
(2) 建立一个异步讨论的电子布告牌 BBS 系统或电子邮件系
统 ,教 师 定 期 或 不 定 期 的 设 计 一 些 综 合 性 的 问 题 ,设 计 能 够 将 讨 论一步步引向深入等后续问题 , 让学生进行讨论 , 学生各抒 己 见 , 对于学生在讨论过程中的表现, 最后由教师做出恰如其分的评 ( 上接第 149 页 ) 采用新的语言 、 先进的开发方式 、 完善的开发过程 , 固然可 以 减 少 错 误 的 引 入 ,但 是 不 可 能 完 全 杜 绝 软 件 中 的 错 误 ,穷 尽 的 测 试 是 不 可 能 的,要 找 出 软 件 中 的 所 有 缺 陷 也 是 行 不 通 的 ,软 件 产 品 的 " 零缺陷 (zero-bug )" 只是一种理想状态 。 实际上 " 足够好 (good-e! nough)" 才是测试应遵循 的 原 则 。 这 种 原 则 就 是 一 种 权 衡 投 入 和 产 出 比 的 原 则 :不 充 分 的 测 试 是 不 负 责 任 的 ;过 分 的 测 试 是 一 种 资源的浪费 , 同样也是一种不负责任的表现 。 著名的 20-80 原 理 也同样适用于软件测试领域 。 一般情况下 , 用 20% 的测试用例可 以 发 现 80% 的 缺 陷 , 而 要 发 现 其 他 20% 的 缺 陷 , 则 要 用 80% 的 测 试用例 , 且只有通过用户的大范围 、 长时间使用后才会曝露 出 来 。 因此也没有必要消耗过多的资源来测试 。 其 实 ,不 同 的 系 统 有 着 不 同 的 质 量 要 求 ,对 于 质 量 要 求 严 格 的系统 , 可能需要进行长时间的 、 全面的测试 , 尽可能地挖 掘 系 统 中的缺陷 。 然而对于质量要求不是很严格的系统 , 系统 是 允 许 出 现错误的, 测试的目的是使系统的缺陷数量降到可接受的范围 内。
!#$
为了满足学生有目的的自己学习 , 对课程所要 求 的 目 标 在 教 学设计中英又明确的交待, 以便血渗透了解学习内容的轻重主 次 。 学习目标可以设计在功能条中 。 为了及时地检验学生的学习 效 果 ,在 教 学 设 计 中 应 该 在 每 节 之 后 提 供 给 学 生 自 测 题 ,自 测 题 能够根据学生的答案进行判断正误并给出相应的解释 , 对 学 生 掌 握的情况能够及时地反馈 。
价。
(3) 建立一个资源丰富பைடு நூலகம்学科资源库 。 实现按学科和媒体类型
共同组织资源 、 多种资源检索方式 、 开放性的资源库 、 资 源 的 审 核 等功能 。 提供相关内容的精品资源和参考资料 , 尤其 是 数 字 图 书 馆 , 学生能够根据自己的需要找到自己需要的内容和相关资料 。
(4) 完 善 的 评 测 系 统 , 实 现 试 题 的 录 入 与 审 核 、 手 工 作 业 的 布
置 、自 动 布 置 作 业 、 联 机 作 业 和 考 试 、 考 试 、 作 业 的 横 向 和 纵 向 分 析等功能 。
3.3 交互式 、 协作式学习环境的设计 (1) 建立一个网上师生同步讨论在线聊天系统 。 教师在讨论的
过程中能够对学生提出的问题进行及时地回答 ; 善于发 现 每 位 学 生通过发言暴露出来的对概念的模糊与不准确之处并及时用学 生适合的方式给与指出 ; 讨论偏离教学内容或纠缠于枝 节 问 题 时 及时加以正确的引导 。
6 测试是可以穷尽的 , 找到的 缺 陷 越 多 , 则 尚 未 发
现的缺陷数就越少
事 实 上 ,对 于 软 件 来 讲 ,还 不 存 在 可 以 解 决 任 何 问 题 的 "银 弹 " 那样的东西 。 不论采用什么技术和方法 , 软件中仍然会有错 。 ( 下转第 176 页 )
收稿日期 :2006-03-28 作 者 简 介 : 苏 正 泉 (1972- ), 男 , 解 放 军 信 息 工 程 大 学 计 算 机 及 应 用 专 业 , 工 作 期 间 一 直 从 事 软 件 研 发 , 系 统 管 理 和 数 据 库 管 理 。 研究方向 : 软件开发 、 系统管理 、 数据库管理 。
5 软件测试就是程序测试 , 测试发现了错误就说明 是程序员所编写的程序有问题
在 实 际 的 测 试 工 作 中 ,测 试 发 现 了 错 误 ,人 们 就 常 常 认 为 是 程序员所编写的程序有问题 , 这未免太冤枉程序 员 了 。 在 软 件 项 目开发的整个过程中, 前一阶段工作中发生的问题如未及时解 决 , 很自然地要影响到下一个阶段 。 表现在程序 中 的 缺 陷 可 能 是 设计阶段甚至于需求分析阶段的问题所致 , 大多 数 软 件 缺 陷 并 非 来自编码过程 , 从小项目到大项目基本上都如此 。 即 使 是 针 对 源 程序所进行的测试所发现的故障 , 其根源也可能 存 在 于 软 件 开 发 前期的各个阶段 。 据美国一家公司的统计表明 , 在 查 找 出 的 软 件 错 误 中 , 属 于 需 求 分 析 和 软 件 设 计 的 错 误 约 占 64% , 属 于 程 序 编 写的错误仅占 36% 。 因此不能简单地把程序中的错误全都归罪于 程序员 。
10 Mis23456s7834i39 7: 7;5 <:=7>865 T5s7i39 ,- ./012-3451 67589:15; ,</::; := >?@919A8B589:1 8/0 C0:D;0E A F0D4G;9< := H/915IJ09K912 100091IH/915L A?s768@7AM98/ 91<B05A912 0ND51A9:1 := <:@D480B 5DD;9<589:1 =90;?I 8/0 A:=8O5B0 DB:?4<8A /5P0 5;B05?Q D0108B580? 8: 05</ 5AD0<8 := /4@51 ;9=0R S/0 A:=8O5B0 ?0P0;:D@018 :B2519T589:1A 1:O 91<B05A912;Q B05;9T0 8/0 9@D:B851<0 := A:=8O5B0 345;98Q @:B0 51? @:B0R ,:=8O5B0 80A8912 9A 51 0AA01895; D5B8 := 8/0 A:=8O5B0 0129100B912R J0912 5 @591 @08/:? := ?9A<:P0B912 8/0 A:=8O5B0 0BB:B 51? ?0=0<8I 98 /5A 5;B05?Q <54A0? @:B0 51? @:B0 5880189:1 := A:=8O5B0 DB:?4<8 4A0B 51? A:=8O5B0 ?0P0;:D0BRJ48 8/0 D0:D;0 :=801 /5P0 A:@0 @9A41?0BA851?912 8: 8/0 A:=8O5B0 80A8912R S/0 D5D0B ?9A<4AA0A 51? A4@@5B9T0? 8/0A0 @9A41?0BA851?912 B5C >:64sA ,:=8O5B0 S0A8912UV9A41?0BA851?912UJ0A8 CB5<89<0
软件测试的 !" 个认识误区
苏正泉 ( 国家行政学院信息技术部 , 北京 100091 ) 摘要 : 随着计算机应用领域的不断扩大 , 软件产品已经渗透到人类生活的各个环节 , 软件开发组织越来越认识到软件质量的重要性 。 软件测试是软件工程中必不可少的一个环节 , 它作为发现软件中错误和缺陷的一种主要手段 , 已经引起了软件产品用户和软件开发人员 越来越多的关注 。 但是人们对软件项目的测试工作常常存在一些认识上的误区 。 本文探讨并总结了这些认识上的误区 。 关键词 : 软件测试 ; 认识误区 ; 最佳实践 中图法分类号 :TP311 文献标识码 :A 文章编号 :1009-3044(2006)14-0149-01