软件测试管理教程详解.ppt

缺陷度量—缺陷的发展趋势 新发现缺陷数量增长趋势和关闭缺陷数量的增长趋势 对于软件产品发布而言，发展趋势图是辅助决策的重要依据。 一般来说，软件发布的必要条件是新缺陷的数量增加呈下降趋势. 缺陷度量—缺陷的分布状况 缺陷分布状况图 有助于了解各版本中缺陷数量的分布 回归测试阶段中，缺陷分布可以直接反映出版本的质量状况 缺陷分布状况图有两种 一种是缺陷按模块的分布状况 评估各模块质量水平，开发难度。 从侧面反映出测试资源在各模块分布的情况 一种是缺陷按产生的根本原因的分布状况 3.5 缺陷管理系统 代表性的有： 开源软件Bugzilla、jira Compuware TrackRecord Rational ClearQuest 北京航空航天大学的QAMonitor 上海微创软件有限公司的BMS等 共同缺点： 没有充分利用缺陷数据，不能以一种主动的、精确量化的方式对软件缺陷进行预防并提供软件项目管理者所需的有关产品和过程的度量信息。 4. 管理一个测试小组 1.企业的测试策略 2.测试人员的组织 3.测试管理的实施 4.测试部门的评估 4.1 企业的测试策略 理念 用较低的代价实现有效的测试 不应为了追求完美的测试而不失一切代价 如何合理地减少测试工作量 减少冗余的测试 测试目标、达到的效果一样——冗余 “回归测试”中应避免冗余 减少无价值的测试 错误的目标、错误的方式 确定测试的优先主次 测试的经济学 “Too little testing is a crime—too much testing is a sin.” 4.2 测试人员的组织 如何组织测试人员 条件特别好的公司: 为每个开发人员分配一名测试人员。测试人员职业化程度很高，可以完成单元、集成和系统测试，能够实现开发与测试同步进行。 条件比较好的公司: 设置一个独立的测试小组，轮流参加各个项目的系统测试。单元、集成测试工作由开发小组承担。 条件一般的公司: 单元、集成测试由开发小组承担。系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。 条件比较差的公司: 开发人员一直兼任测试人员的角色，相互测试对方的程序。开发者测试自己的程序. 4.2 测试人员的组织 避免开发人员与测试人员产生矛盾 开发人员的注意事项： 不要敌视测试人员 不要轻视测试人员 测试人员的注意事项： 发现缺陷时不要嘲笑开发人员，别说他的程序烂。 在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。 请留意另一种极端：如果测试人员与开发人员的关系好，可能会在测试时“手下留情”，这对项目也是一种伤害。 4.3 测试管理的实施 测试管理中的PDCA P：测试计划 D：测试案例及测试步骤的设计 C：测试实施和错误跟踪 A：测试总结与报告 软件测试文件描述要执行的软件测试及测试的结果 测试文件的编写是测试工作规范化的一个组成部分 开始于需求分析阶段、使用于整个生命周期中 4.4 测试部门的评估 测试经理必须跟踪、监督和评估测试工作的实现，并在必要时进行改进。 评估测试人员的有效性 对测试人员的期望 评估测试人员测试工作的要点 评估测试组的有效性 角色和职责 行业知识、测试技巧和经验 评估测试组测试活动质量的几个方面 A. 评估测试人员的有效性 对测试人员的期望 遵守测试标准和测试过程 保持进度（提交各种产品的时间） 达到目标和完成指派的任务（为每人分配的任务必须形成文档，确定截止期限和完成目标） 控制预算（购买测试工具时） 评估测试人员测试工作的要点 行业知识 是否深入了解系统的功能 是否具备应用程序的行业领域的知识 技术知识 熟悉各种测试技术？ 熟悉测试工具? 技术能力 测试用例设计的如何？覆盖面、检错能力、检错深度 开发的测试脚本、测试工具质量如何? 能否用测试技术提高手头测试任务的测试效率? 交流能力 是否听取了来自需求人员、开发人员和其他测试人员的反馈意见？ 撰写的缺陷报告质量如何？ 缺陷相关的指标 发现缺陷的数量 发现缺陷在代码中的比例 发现缺陷的效率 发现缺陷的时间：主要缺陷是否发现太晚了？ 是否遗漏了缺陷? 缺陷类型：是否发现重要的缺陷？ 缺陷报告：是否标准化，是否易重现陷？ B. 评估测试组的有效性 定义角色和职责是否明确 是否定义并文档化测试组成员的角色和职责 是否将角色分配给了合适的人 是否有细致的任务描述：任务的构成、技术方法、时间表、费用、每个人的时间分配、使用的标准和流程 是否具有充分的测试技巧、行业知识和经验 行业知识：很重要 技术知识：了解技术平台和系统架构，自动测试的基本编写、理解性能和安装之类的问题 经验等级：初学者需要培训，可测试风险较低的部分。 专业测试人员和行业专家测试人员应该互相协作。 成功