标签: software
相关帖子 |
版块 | 作者 | 回复/查看 | 最后发表 |
|---|
相关日志
-
- 分享 测试理念Methodologies for Software Testing
- guluxing
- 1 测试理念 Methodologies for Software Testing 1.1 测试的核心在于把握失效规律和失效影响 1.1.1 业界的两种测试理念 1 、第一类测试理念试图验证软件是按照预先的设计执行的 , 代表人物是软件测试领域的先驱 Dr. Bill Hetzel( 代表论著 The Complete Guide to Software Testing), 他在 1973 年给软件测试一个这样的定义 :" 就是建立一种信心 , 认为程序能够按预期的设想运行。 Establish confidence that a program does what it is supposed to do. " 后来在 1983 年他又将定义修订为 :" 评价一个程序和系统的特性或能力 , 并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a program or system. " 在他的定义中的 " 设想 " 和 " 预期的结果 " 其实就是我们现在所说的用户需求或功能设计。 基于正向验证理念建立的测试行业标准 :1990 年的 IEEE/ANSI 标准将软件测试进行了这样的定义 :" 就是在既定的状况条件下 , 运行一个系统或组建 , 观察记录结果 , 并对其某些方面进行评价的过程。 The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 " 这里 " 既定的状况 " 可理解为需求或设计。 2 、第二类测试理念重点是搜寻 bug, 代表人物是 Glenford J. Myers( 代表论著 The Art of Software Testing, 在当时 , 他认为测试是少数人才会的艺术 , 不是工艺 , 更不是科学或工程 ) 。他认为测试不应该着眼于验证软件是工作的 , 相反 , 应该首先认定软件是有错误的 , 然后去发现尽可能多的错误。 Myers 从人的心理学的角度论证 , 将 " 验证软件是工作的 " 作为测试的目的 , 非常不利于测试人员发现软件的错误。于是他于 1979 年提出了他对软件测试的定义 :" 就是以发现错误为目的而运行程序的过程。 The process of executing a program or system with the intent of finding errors." 简单地说就是验证软件是 " 不工作的 ", 或者说是有错误的。他甚至极端地认为 , 一个成功的测试必须是发现 Bug 的测试 , 不然就没有价值。 第二类软件测试理念在业界也很流行 , 受到很多学术界专家的支持。大家熟悉的 Ron Patton 在 软件测试 一书的第 10 页 , 有一个明确而简洁的定义 :" 软件测试员的目标是找到软件缺陷 , 尽可能早一些 , 并确保其得以修复。 " 我们公司以 Bug 数量来作为考核测试人员业绩的一项指标 , 其实就是接受了这样的理念。 “ 引用微软 ” 1.1.2 我的看法 : 测试是正向验证和风险排除两种理念的有效结合 实际上 , 微软等众多业界巨头都是这么做的 , 大家可以参考 51Testing 上的文章 微软的测试方法 。我们或多或少也是这么做的 , 只是没有从部门的角度明确提出这样的测试理念。 这里对这两种测试理念再对比一下 : 虽然两类软件测试理念总的目的都是为了产品的质量 , 但在思路、过程和测重点上有很大的差别 , 并各有利弊。 1 、正向验证的测试理念 : ** 优点 : 以需求、设计、协议等为依据 , 有利于界定测试工作的范畴 , 方便测试计划的安排。这一点对于大型软件的测试 , 尤其是在有限的时间和人力资源情况下显得格外重要。可以用较少的投入保证系统最基本的质量要素。 ** 缺点 : 如果理念是验证系统是可行的 , 通常只会从基本使用的层面进行验证 , 不容易发现缺陷 , 对可靠性要求很高的通信系统而言 , 如果只用这种测试理念 , 则是一种灾难 ! ** 应用 : 业界很多 MIS 系统及可靠性要求较低的系统都采纳了这种理念 ; 一些行业标准测试 ( 例如协议符合度测试、准入测试 ) 也运用了这种理念 ; 还有一些交给第三方、以应用为主的测试也基本是这种理念。我们 SDV 中半数以上的用例实际上也是基于验证而设计的。另外 , 我们可以看出 , 基于正向验证的测试由于测试依据和测试目标都非常明确 , 是可以较好地实现测试设计和测试执行的 , 也可以较好地分层测试 ( 这里先提一下 , 关于设计与执行分离、分层测试的整体 , 我们后面还会探讨 ) 。 2 、搜寻 bug 的测试理念 : ** 缺点 : 与需求和设计没有必然的关联 , 不利于界定测试工作的范畴 , 不方便测试计划的安排 , 测试活动的渐进性差一些。如果策划不当 , 测试活动很容易丢失重点 , 走入歧途。 ** 优点 : 第二类测试理念最大的优势是目标明确 , 容易发现 bug, 特别是 bug 数量考核牵引下 , 更容易发现较多 bug 。但要指出的是 :bug 发现是一个逆向思维过程 , 并没有非常明确的方法论可以参考。另外 , 可能会发现很多缺陷 , 但有些在实际场景发生概率很小 , 或者发生了影响也不大 , 这里非常关键的一个问题就是需要对行业产品的失效规律和失效影响进行专项积累 , 然后针对性设计用例进行测试。因此 , 个人认为 , 第二类理念与其说是搜寻 bug 的测试 , 还不如说是基于风险的测试 (RBT), 测试的目的不是发现最多的问题 , 而是解决系统在商用过程中的风险。质量 = 符合要求 ; 风险 = 失效概率 × 失效影响。关于失效规律和失效影响的更多描述和总结可以参考我 2005.2 输出的总结 : 从失效规律和失效影响看业务测试 。 附件 : 从失效规律和失效影响看业务测试 ** 应用 : 正向验证活动之后阶段性开展深入的专题测试或探索性测试 , 对可靠性要求很高的系统而言 , 这类测试活动的工作量会超越正向验证的工作量。质量上虽然无法向正向验证那样明确分层推进 ( 洋葱模型 ), 但也可以分领域逐渐给出专项稳定性评估。最关键的一点是 : 不要不分主次、盲目搜索所有可能的 bug, 而要结合商用的实际需求和场景 , 解决商用过程中最关键的风险。 1.2 测试的另一核心是对被测对象的准确把握 2003 年下半年开始 , 测试走向后端 ( 虽然我个人不太赞同这样做 ) 让我们的测试分析与设计技能日趋专业化 , 并在实际的测试工作中积累了无线产品较多的缺陷规律。我 2004 年输出了一整套测试分析设计方面的总结 , 包括 测试需求分析指南及 CHECKLIST 、 测试方案设计指南及 CHECKLIST 、 测试用例写作指南及 CHECKLIST 、 系统测试执行经验总结及 CHECKLIST 、 cBSC BETA 测试指导书 等 ;2005 年初输出了 从失效规律和失效影响看业务测试 , 自认为自己的测试技术经过 4 年的积累已基本走向 " 成熟 " 。问题 : 是否可以从此宣布自己可以做好测试了？事实并非如此。测试是有她的核心价值和核心技术含量 , 我们也可以凭这些核心技术自己去开一个不错的测试公司。但如果硬要将测试的核心价值和核心技术与整个研发过程分离开来 , 则测试的作用并不会得到最好的发挥。 1.2.1 一个测试设计闭环分析发现的例子 : 完美的设计 ≠ 完美的测试 某技术较好的 TSE 为一个 2.5K 左右、难度一般的特性设计了 100 个左右的用例 ( 相对代码规模和难度而言 , 用例规模偏大 ), 测试分析、设计、实现过程都堪称 " 完美 ", 因为过程规范、测试完备性很好 , 以往的测试经验 ( 因子 / 状态分析积累、缺陷规律等 ) 也得到了很好的继承 , 但这 100 个用例最终只发现了 3 个一般缺陷 , 而且只有 1 个是用例直接发现的。这个例子反映了我们的一个现状 : 我们的测试设计水平越来越高 , 积累的缺陷规律越来越丰富 , 设计的用例越来越大而全 , 但有效性越来越低 ! 而且 , 一个灾难性的后果就是 : 以前我们设计水平差的时候有时间将用例执行 2~3 遍 , 但现在每个版本的用例都执行不完 , 导致测试人员非常疲惫 , 最后效果还未必好。这个例子的问题在于 : 我们设计时是否考虑了特性的复杂度 ; 开发人员的能力准备度、过程规范度和前期测试的质量？我们完善的测试设计考虑了各种可能的情况 , 是否和特性在实际商用中面临的风险很好地结合了？ 1.2.2 自己经历的例子 : 被测对象分析是提高测试质量和效率的关键 CDMA 的经典版本 R02B03 2003 年初转测试时 , 我接手了一个近 2 万代码的 " 复杂 " 特性 , 测试设计是 WY 大侠做的 , 我审视之后觉得完备性不够 , 看不出整个用例的产生过程。于是和 WY 一起 , 基于 R01 的测试经验积累 , 用两周时间走了测试需求分析、测试设计的过程 ( 那时还没有 PTM 流程 , 测试类型等还在探索中 ), 设计了 240 个用例 ( 当然 , 肯定没有时间全部进行详细描述 ), 自认为堪称 " 完美 ", 而且一直将这个过程作为自己测试设计技能上了一个台阶的标志。但实际测试一个版本后发现 : 并没有自己想象的那么多缺陷。一个版本就基本稳定了 , 及时终止了测试活动。我测试设计时忽视了三个重要的事实 :R02 开发过程规范了很多 ; 开发人员的技能成长了很多 ; 早期的代码走读、 UT 、 IT 、 MST 等质量活动中 , 我们的优秀测试人员 WY 发挥了非常重要的作用 , 甚至直接负责了测试方案的写作和较多用例的执行。这些因素让很多可能成为风险的地方实际上并没有什么风险 , 让完美的测试设计不再那么有效。 附件 :06 年目标 , 提高用例有效性 ,CBSC 测试系统组年度规划 2006 附件 :CBSCV2R2C02 版本测试设计闭环分析 1.2.3 结论 : 对被测对象的深入分析和准确把握是测试的另一关键 关键的因素包括代码复杂度、开发人员的技能和经验准备度、开发流程规范度 , 以及早期质量活动 , 特别是前期测试的质量。有了这些 , 就可以判断风险的大小以及主要风险的所在 , 在保障基本功能验证通过的前提下 , 重点开展基于风险的测试活动。 再举回归测试的例子说明我的观点 : 如果开发修改问题单非常规范 , 合入前验证非常充分 ,99% 的都能回归测试通过。那么我会认为测试再做回归测试是不必要的。因为投入产出比非常小。即使 GA 后的版本 , 再去测试 100 个用例 , 也肯定不止发现一个问题 , 为什么还要再去回归呢？最多回归几个有风险的重点问题就行了。其它时间可以投入到其它有风险的地方 ( 这种地方总是有的 , 即使 GA 之后。测试只有停止标准 , 没有结束标准 , 关键看我们对投入产出的界定标准 ) 。这个时候 , 最完善的回归测试流程和回归测试设计意义都不大 , 因为我们面临的本来就是不太需要测试的系统。 我们不要小看对这个问题的认识 , 举一个例子 : 我们某新版本用例 8000 个 , 估计缺陷 3000 个 ( 平台变更产品 , 实际数据没有统计 ), 则回归测试用例 4500 左右 , 在整个版本测试工作中占的工作量很大 , 很显然不能用统一的策略来要求 , 而必须根据被测对象的情况进行分析 , 制定合适的测试策略 :SDV 阶段的回归可以简化 , 越到临近版本发布 , 越需要严格回归流程 , 原因很简单 :SVT 后测试活动很少 , 放过就直接流到网上 , 而 SDV 阶段问题很多 , 回归远不如执行新用例发现问题多 , 即使漏过去了 , 后面 SIT/SVT 也有较多的机会再发现。 实际上 , 即使我们积累的缺陷规律 , 也是基于开发团队现状的。同是控制器产品 , 我们表现出来的缺陷规律肯定和 E 公司有很大差异。具体来说 , 这个公司开发的某产品存在大量的协议兼容性问题 , 另外一个公司可能一点问题都没有 , 因为协议标准可能就是人家制定的。也就是说 : 我们积累了很久的核心竞争力未必是可以移植的 ! 不必因此而悲观 , 至少在公司的模式下 , 我们积累的东西是有用的。关键是我们要意识到 : 测试最核心的东西是动态的 , 是和整个研发过程和市场定位紧密捆绑的。单独从测试去强调独特价值、独特技术是不合适的 , 我们的使命就是和开发一起 , 研发符合市场定位和客户要求的产品。质量 = 符合要求 ,20 年前如此 ,20 年后还是如此 ; 但测试核心竞争力是动态变化的 , 唯一不变的是我们的应对原则 : 根据被测对象和测试团队情况制定合适的测试策略。 1.3 测试理念 : 测试 = 被测对象分析 + 失效规律把握 ; 测试策略是核心 从前两节的描述 , 可以简单总结为如下几点 : 1 、基本功能测试验证是测试的重要部分 , 即使没有发现多少问题 , 也是必要、有意义的 , 可以保障我们最基础的质量要求 , 没有这部分 , 即使发现和解决的 bug 再多 , 也无法对系统做出质量评估。 ( 顺便说一下 , 因标准清晰 , 这部分可以设计和分离 ) 2 、搜寻 bug 为目的的测试对通信系统而言是非常必要的 , 可以超越需求和设计的范围 , 但一定要基于实际应用场景、客户质量要求 , 以及被测对象的当前状况来确定风险 , 将我们掌握的缺陷规律和被测系统的特定风险有效结合 , 分专题开展基于风险的测试。这部分测试设计的依据和目标不是非常清晰 , 需要根据测试执行过程中发现的情况及时调整 , 参加的人员最好是开发、测试设计人员、测试执行人员以及维护人员一起 , 不适合设计与执行分离 , 类似微软 , 组织自由测试团队或 bug bash 团队的做法更合适。 3 、正向验证 + 基于风险的测试 , 我们可以给出完整的质量评估 : 系统在哪些情况下是 OK 的 , 在哪些情况下是存在潜在的风险的 , 以及风险的可控程度。通过这个评估支撑产品的发布 ; 并为后续维护及新迭代版本的开发、测试提供参考。 4 、正向验证活动可以比较好地规划、评估 ; 而基于风险的测试则难于规划和评估 , 但并不代表没有规律。开发人员的技能、过程规范度、前期测试情况等如果我们在前期参与较多 , 则可以较好地评估 , 一方面将风险更早地排除 , 另一方面也方便确定系统的遗留风险所在 ; 即使我们在早期投入不足 , 也可以通过开发的早期输出、结合 " 质量探针 "( 或叫抽样测试 ) 的方式来对被测对象做出基本评估 , 从而确定和调整测试策略。基于这点 , 我们一直认为每个版本的执行策略是应该不断调整的 , 而不是转测试时就能完全确定的。 5 、个人认为 : 测试策略是测试技术中最核心的一部分。测试 , 简单来说就是两个问题 : 测什么和怎么测 , 这都是策略的范畴。相对测试分析设计 , 测试策略更体现了这种动态性 ; 也能更举足轻重地影响测试的质量和效率。从这里也可以看出 , 测试管理和测试技术是分不开的 : 离开测试过程管理的技术理论没有意义 ; 而没有技术和丰富的经验也不可能做好测试管理。测试还没有达到科学或工程的定量程度 , 但也不是只有少数人才会的艺术 , 而是一门基于经验、可复制的工艺学科 , 只是还没有达到可以给出明确标准的批量复制程度。 1.4 测试理想 : 打造专业测试团队 , 成为产品研发中的核心支撑 我个人比较推崇微软的测试理念。不仅仅是因为个人的理念和微软比较接近 , 更重要的是 : 在微软 , 测试部门和测试人员有很高的地位。更准确的说 , 是测试在整个研发体系发挥了非常核心的作用 : 不仅是质量保障 , 还为开发活动、管理活动提供了最强的支撑 , 测试的价值得到了最好的体现。测试活动和开发活动高度结合 , 但丝毫没有影响测试价值的体现 , 反而可以测试驱动开发。 前面已经说过 , 测试最重要的就是两个问题 : 测什么和怎么测。这两个问题对质量和效率都有直接影响。测什么决定了质量 , 实际也决定了效率 : 如果能在深入分析的基础上大幅度减少测试用例 , 则测试效率提升可能比自动化还高。怎么测直接影响效率 , 也对质量有影响 , 实际上 , 系统越来越复杂 , 我们总有分析不清楚的时候 , 如果自动化平台足够强大 , 则我们多测一些也无妨 , 可以避免一些低级遗漏。策略是重要 , 但毕竟是基于经验的活动 , 总会有不完善的地方 , 工具和自动化这时可以进行很好的补充。 我的理想是测试能在质量保障、开发支撑、管理支撑发挥非常核心的作用 , 要达到这点 , 就要很好地解决前面说的两个问题 : 测什么和怎么测。也就是解决测试策略和测试平台问题。 测试策略方面 , 首先要对客户群的质量要求有很好的理解 , 并熟悉我们开发和测试团队的情况 , 然后给出我们各阶段的质量策略和测试重点 , 这点更多的是基于个人的经验和组织的积累 ( 组织过程资产、质量基线等 ), 不管组织如何积累 , 这个方面有经验的专家会起到非常核心的作用 , 就如任何好的管理实践积累都代替不了优秀的管理者一样。有什么样的专家 , 我们就会在研发团队中有什么样的声音。 关于测试平台和工具 , 这是我们大有可为的地方。我们目前还处于手工作坊模式 , 平台和工具建设非常不足 , 人力投入也严重不足 , 如果我们在自动化方面大力投入 , 建设较完善的自动化平台 , 一方面会减少我们的重复测试工作量 , 另一方面可以为开发活动提供很好的支撑 : 他们可以使用我们的测试平台和工具进行大量的早期测试活动。另外 , 如果我们能在需求 - 用例 - 缺陷之间用工具建立起有机联系 , 则整个研发的管理会更有效。因为研发的管理主体是质量的管理 , 而质量最核心的是缺陷的管理 , 如果我们更好地分析这些缺陷产生的原因 , 则能为开发和测试的改进提供更多的参考。 1.5 测试理念对测试管理和测试技术的影响 测试理念对测试管理和测试技术的发展有非常直接的影响。 1.5.1 设计与执行分离 : 从之前相持不下的争论就可以推论出 : 有些是适合分离的 ; 有些是不适合分离的。例如 , 基于功能验证的就是可以分离的。包括我们的功能测试、各种入网、协议测试等 , 这种情况不是以发现问题为主要目的 , 主要是证明系统是基本可行的。可以新员工或低级别员工执行。 探索性测试是不适合分离的 , 因为很简单 : 测试目标和评判标准不是非常清晰 ; 很多时候都要边尝试边决策下一步操作。 分离中的问题 : 测试设计本身是可以交接的 , 但对产品的熟悉是大家都需要知道的。否则 , 执行人员会对一些问题视而不见。这种产品知识高度专业化的领域 , 总体上不分离更为合适。当然 , 如果测试执行团队相对稳定 , 并有一定的产品知识储备 , 按技能进行适当分工是非常合理的做法。 结论 : 第一类观察点明确 , 可以分离 ; 第二类不建议分离 , 因为很多结果是未知的 , 只有发生了 , 综合分析才能判别是否是问题。总体来说 , 通信领域对产品知识本身要求很高 , 分离是不太合适的。 (E 有分离 ;N 不分离 ) 1.5.2 测试评价 :bug 是一个重要方面 , 但不是唯一依据 第一类 : 执行人员没有发现 bug 可能是开发质量好 , 或设计质量差 , 总体来说 , 应该从执行数量进行评价。但这里是假定执行人员都是按设计严格执行到位的。考评可以以执行用例数量为主 , 但要有回溯机制 ( 观察点有但执行遗漏 ) 和鼓励机制 ( 发现多少非观察点的问题 ) 。 第二类 : 关键是找出多少对系统满足商用有严重问题、且发生概率较高的大 bug 1.5.3 前期测试和后端扩展 为了更好地了解被测系统 , 更早地发现问题 , 产品测试更多参与前期测试是必然的模式。 解决方案从 E2E 提高产品准备度 , 加强后端也是必然的趋势。 1.5.4 开发测试要更好地融合 , 但保持独立的测试团队是非常必须的 从前面的描述 , 我们知道开发和测试需要更紧密地结合 , 但目前的情况下 , 保持独立的测试团队是非常必要的。要彻底组织融合 , 需要两个条件 : 1 、已有完善的测试平台 ; 2 、开发人员已有非常好的测试技能 , 并形成了较好的质量文化。 有了这些条件 , 基础能力提升了 , 其实组织结构就是次要的了。在此之前 , 我们最好保持独立的组织 , 促进核心能力的沉淀。
-
- 分享 深圳某外资Android/iOS/Windows phone/UI/.Net/Sr.development Manager紧急需求
- susan515
- 世界著名IT网络安全厂商。目前急需在深圳招聘下列职位,年薪比较有竞争力哦，有兴趣速速提交简历哦！：） -----Android Developers -----iOS Developers -----Windows Phone Developers -----.NET Developers -----QA Engineers -----UI Designer -----Software Development Manager -----Senior Software Engineer, Android - Shenzhen, China
-
- 分享 急招c++&SIP开发
- Icuxu
- What you need for this position: * Strong SIP and call control development experience. * Familiar with related RFCs * 5+ years of software development experience with C/C++ programming * Experience with Linux/Unix, multi threading, network * Strong analytical and communication skills * Ability to work independently and as part of a team * Knowledge of GUI development (Java, C#, Objective-C) or multi-media is a plus What you'll be doing: * Develop call control module for enterprise unified collaboration apps (IM, voice, video, etc) that run on various platforms (Windows, Mac, iOS, Android) 如果感兴趣可以把简历发送至 2574230585@qq.com
-
- 分享 海外南非項目- Huawei 急聘 software Engineer
- JingHR
- 海外南非項目- Huawei 急聘 software Engineer- 含交通及住宿 請寄簡歷到 jlai@firstpointgroup.com
版规|手机版|C114 ( 沪ICP备12002291号-1 )|联系我们 |网站地图
GMT+8, 2025-6-15 11:44 , Processed in 0.067737 second(s), 15 queries , Gzip On.
Copyright © 1999-2023 C114 All Rights Reserved