测试过程与测试架构.pptx

测试过程与测试架构 议题 1 对比需求验证方式测试与缺陷大扫除方式测试2 对比V测试模型与W测试模式3 敏捷测试过程是降低了测试质量吗 4 不同测试类型在软件工程上的时间点 它山之石可以攻玉 微软在软件测试方面有很多值得一提的经验 这里有一点须要特别说明 尽管微软的方法已被微软的实践多次证明是成功的 非常有效的 但这并不意味着这些方法在中国的软件企业中有广泛的可行性 一种方法是否可行 还受到很多其他因素的影响 比如企业类型 微软是生产平台软件和通用软件产品的企业 企业管理体制 企业文化等等 两类经典的软件测试方法 在具体介绍微软的软件测试方法之前 我想首先从概念 或理念的层面上来理解究竟甚么是软件测试 目的是从中导出微软测试方法的理论根源 传统上认为软件测试的方法从总体上分为两类 第一类测试方法是试图验证软件是 工作的 所谓 工作的 就是指软件的功能是按照预先的设计执行的 而第二类测试方法则是设法证明软件是 不工作的 提出第一类方法的代表人物是软件测试领域的先驱Dr BillHetzel 代表论著 TheCompleteGuidetoSoftwareTesting 他曾于1972年6月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛 他首先在1973年给软件测试一个这样的定义 就是建立一种信心 认为程序能够按预期的设想运行 Establishconfidencethataprogramdoeswhatitissupposedtodo 后来在1983年他又将定义修订为 评价一个程序和系统的特性或能力 并确定它是否达到预期的结果 软件测试就是以此为目的的任何行为 Anyactivitiesaimedatevaluatinganattributeorcapabilityofaprogramorsystem 在他的定义中的 设想 和 预期的结果 其实就是我们现在所说的用户需求或功能设计 他还把软件的质量定义为 符合要求 第一类测试 第一类测试可以简单抽象地描述为这样的过程 在设计规定的环境下运行软件的功能 将其结果与用户需求或设计结果相比较 如果相符则测试通过 如果不相符则视为Bug 这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行 并通过 在软件行业中一般把第一类方法奉为主流和行业标准 1990年的IEEE ANSI标准将软件测试进行了这样的定义 就是在既定的状况条件下 运行一个系统或组建 观察记录结果 并对其某些方面进行评价的过程 Theprocessofoperatingasystemorcomponentunderspecifiedconditions observingorrecordingtheresults andmakinganevaluationofsomeaspectofthesystemorcomponent IEEE ANSI 1990 Std610 12 1990 这里所谓 既定的状况 也可理解为需求或设计 第二类测试方法 尽管如此 这一方法还是受到很多业界权威的质疑和挑战 代表人物是GlenfordJ Myers 代表论著 TheArtofSoftwareTesting 他认为测试不应该着眼于验证软件是工作的 相反应该首先认定软件是有错误的 然后去发现尽可能多的错误 他还从人的心理学的角度论证 将 验证软件是工作的 作为测试的目的 非常不利于测试人员发现软件的错误 于是他于1979年提出了他对软件测试的定义 就是以发现错误为目的而运行程序的过程 Theprocessofexecutingaprogramorsystemwiththeintentoffindingerrors 这就是软件测试的第二类方法 简单地说就是验证软件是 不工作的 或者说是有错误的 他甚至极端地认为 一个成功的测试必须是发现Bug的测试 不然就没有价值 这就如同一个病人 假定此人确有病 到医院做一项医疗检查 结果各项指标都正常 那说明该项医疗检查对于诊断该病人的病情是没有价值的 是失败的 我并不完全同意这一看法 第二类软件测试方法在业界也很流行 受到很多学术界专家的支持 大家熟悉的RonPatton在 软件测试 中文版由机械工业出版社出版 具说此书是目前国内测试新手入门的经典教材 一书的第10页 有一个明确而简洁的定义 软件测试员的目标是找到软件缺陷 尽可能早一些 并确保其得以修复 有些软件企业以Bug数量来作为考核测试人员业绩的一项指标 其实就是接受了这样的方法 两类方法的优劣对比 虽然软件测试总的目的是为了软件产品的质量 但很明显这两类测试方法在具体目标 或指导思想上截然相反 由此也决定了它们在思路 过程和测重点上有很大的差别 并各有利弊的 第一类测试方法以需求和设计为本 因此有利于界定测试工作的范畴 更便于部署测试的侧重点 加强针对性 这一点对于大型软件的测试 尤其是在有限的时间和人力资源情况下显得格外重要 而第二类测试方法与需求和设计没有必然的关联 如果计划管理不当 测试活动很容易丢失重点 走入歧途 第一类测试方法可以与软件的架构和软件开发的计划相配合 使软件测试活动逐层次的展开 从而使软件的功能和质量有计划地逐步完善和提高 关于测试的层次问题 我会在今后的讨论中专门介绍 第二类测试方法不具备这种过程的渐进性 第一类测试方法的缺点是缺乏灵活性 不利于测试人员主观能动性的发挥 正像Myers先生所说 不容易找到软件的错误 Bug 而这方面正是第二类测试方法的长处 微软的策略 正是因为认识到两类测试方法各有利弊 微软在软件测试活动中将两类方法结合起来 以第一类测试方法为基础和主要线索 阶段性地运用第二类测试方法 微软的第一类测试 微软的第一类测试总体上说分为三个步骤进行 审核需求和设计 设计测试 实施运行测试 审核需求与设计 第一类测试是以需求和设计为本来验证软件的正确性 大家很自然的想到 需求和设计本身也有正确性的问题 依据不正确的需求和设计不可能开发出正确的软件产品 测试也将是徒劳的 因此验证需求和设计是微软进行第一类测试的第一步 有必要指出的是 这里所说的需求和设计具体说来它一般包括 1 由项目经理根据用户要求 信息来源于市场部门 用户支持部门等等 而编写的需求文本 RequirementSpecification 2 由项目经理根据需求文本而编写的功能设计文本 FunctionalDesignSpecification 3 由开发人员根据功能文本而编写的实施设计文本 ImplementationDesignSpecification 微软的测试人员要参与所有这些文本的审核 作为测试人员 审核重点是检查文本对用户需求定义的完整性 严密性和功能设计的可测性 同时这种审核对于测试人员也是一种热身活动 使他们尽早地进入技术和业务状态 设计测试用例 第二步 测试人员要根据已审核通过的需求和设计编制测试计划 设计测试用例 在前面提到的三种文本中 功能设计文本是主要依据 原因很简单 这类测试关心的是软件是否能正确地实现功能 而不是这些功能如何被具体实施的 从这里大家可以看出这是典型的 黑盒测试 确实微软的测试主要是从用户角度进行的黑盒测试 这一步的完成就意味着 测试计划 和 测试用例设计 两个文本的完成 测试计划 文本主要阐述测试的范畴 领域 方法 工具 资源和计划时间表等等 测试用例设计 文本要列出测试用例 每个用例的设置 执行步骤和预期结果 测试的这两个文本也要被项目经理和开发人员审核 这样经过各种相互的审核 大家对项目形成了基本的共识 运行测试用例 第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段 从总体上说就是将上一步设计的测试用例按计划付诸实施的过程 这包括编写自动化测试程序 反复运行自动化测试程序 也包括阶段性执行手动测试用例 这一阶段的测试必须在周密的计划下进行 这正是第一类测试的特点和长处 这种计划性首先体现在开发和测试的相互协调配合 根据产品的架构和功能模块的依赖关系 按照项目的总体计划共同推进 从测试的过程来看 总是先运行或执行简单用例 然后再复杂用例 先验证单一的基本功能 再综合的端到端的功能 先发现解决表面的 影响面大的Bug 再深层的 不容易重现的Bug 因此随着项目开发和测试的进程 产品的功能不断完善 质量不断提高 这里有一点要特别指出 有很多测试用例是要反复运行的 特别是基本的自动化测试每一天 每一个Build上都要运行 尽管这些测试大多数情况下都是通过的 很少再发现新的Bug 但其价值是显而易见的 就是为了防止质量回归 可见Myers的理论在这里是不适用的 这一阶段测试人员还有一项繁琐但却很重要的工作 就是对已有的测试用例的维护 比如通常以下两种情况下要新增一些测试用例 一是对于当初测试设计不周全的领域 二是对于外部的Bug 比如从Beta客户报告来的 没有被现有测试用例所覆盖 当产品的功能设计出现更改时 在微软这是常事 所涉及的测试用例当然也要相应地修改 微软的第二类测试 微软的第二类测试是阶段性的 常常根据需要而带有随机性和突击性 对于这类测试 在微软有一个专门的名称 BugBash Bug大扫除 BugBash通常发生在项目开发各阶段 微软叫里程碑 的末期 比如Beta版发布前 划出一个专门的时间段 通常1 3天 在这期间所有参与项目的人员 集中全部精力 运用各方面的知识 尽全部智慧来搜寻项目的Bug 这是一个非常有意思的活动 但要组织好这样的活动并非易事 一般有以下要点 1 尽管这是一个测试活动 但参与者并不仅限于测试人员 项目经理 开发人员甚至于高层管理人员都应参加 如同全民动员 目的是要集思广益 2 要鼓励各部门 领域交叉搜索 因为新的思路和视角通常有助于发现更多的Bug 3 为调动积极性 增强趣味性 可以适当引入竞争机制 比如当活动结束时 评出发现Bug最多 发现最严重Bug的个人 给以物质和精神奖励 4 可以分专题展开 比如安全性 用户界面可用性 国际化和本地化等等 微软的第二类测试除了BugBash外 经常还有一些专业性的测试 最典型的是针对安全性攻击测试 一般会邀请公司内部 或业界的专家来搜寻产品的安全漏洞 以上从传统软件测试概念的角度 介绍了微软的策略和两类传统测试方法的具体做法 及其侧重点 这其实仅仅是一个基础 一个很原始的基础 软件测试在微软软件产品开发中的作用 地位远不是这些原始的方法所能达到的 也不是传统软件测试概念所函盖的 微软在软件测试方面有很多特有的做法 和概念上的突破 比如 软件测试的信息服务功能 以用户为中心的宏观质量体系 分级测试 项目的质量管理系统 Bug三方会审 测试自动化 和 软件测试的软硬件 部门 团队 人和基础设施 等等 ProductCycleModel 产品市场的定位 远景规划分析市场的调查和反馈用户需求总结制定项目范围确定开发资源 制定产品的市场定位设计规范书开发构架设计测试计划开发时间表 开发人员产品功能的开发测试人员进行功能性的测试UE UserEducation 写用户文档市场人员制订市场计划程序经理控制整体开发进度 集成测试功能测试全部完成程序到达 zerobug 使用说明内容完成最后校验 最终版本送交发行使用说明书提交发行市场营销及发布活动发行后勤准备售后服务及用户支持系统运行 ProcessOverview SpecReview Testing SoftwareLoc UALoc DesignSpec DogfoodBuilds Beta2B2TR RC1 M1 M3 M2 CC Beta ReleaseCandidate RC2 Beta1 Coding Planning RTM VisualFreeze TestRoadmap PlanningGetReadySpecreviewTestPlanTestCasesCoding Private Dogfoodbuilds MilestoneM1 M3UnitTestFeaturecrewtestCheck intestCodeCompleteAcceptancetestInternationalSufficientlytestingstartBetaBeta1 B1TR Beta2 B2TR UserScenariotestingLocalizationtestingstartZBBTriage ReleaseCandidate RCbuild RC1 RC2 TestpassBugbashFeatureSignoffTriageReleasetoManufacture RTM ExitCriteriaTestingsignoffServicePa