part03 软件测试过程管理

《part03 软件测试过程管理》由会员分享，可在线阅读，更多相关《part03 软件测试过程管理（106页珍藏版）》请在金锄头文库上搜索。

1、软件测试工程师培训,软件测试过程管理,主要内容,软件测试生命周期 软件测试模式 软件测试过程 软件测试组织与管理,1、软件测试生命周期,开发生命周期,需求分析,设计定义,程序编制,维护,建立,建立,建立,修改,测试生命周期,测试计划,缺陷跟踪,越早测试越好,2、软件测试模式,3、测试过程,(1)测试计划的目标,收集并组织测试计划信 息 将软件细化为可检验的 测试需求 建立测试计划,测试计划：定义测试需求,定义,测 试 需 求,根据用户需求定义并完善测试 需求，以作为整个测试的标准,测试计划：考虑测试内容,系统功能 用户界面 系统性能 加载测试 强化测试 容量测试 配置测试 安装测试,(2)测试

2、设计的目标,定义自动测试过程 选择适当的测试用例 组织测试过程信息，并 传递给测试开发人员,测试设计：定制测试过程,定制,测试设计：选择测试用例,定制,测 试 过 程,选择,测 试 用 例,(3)测试开发的目标,建立可重用的自动测试 维护测试对于测试需求 的可跟踪性,测试开发技术：编程,优势： 具有较大的灵活性 缺点： 编码过程复杂,测试开发技术：录制,优势： 操作简单、快捷 缺点： 灵活性较差,测试开发技术,脚本生成自动化，并可根据需要修改,(4)测试执行的目标,执行测试 检查测试结果 研究并组织测试结果以 便评估 维护缺陷记录,测试执行的步骤：单元,缺 陷 跟 踪,测试执行的步骤：模块,组

3、,合,测,试,缺 陷 跟 踪,测试执行的步骤：集成,组合测试,组合测试,组合测试,组合测试,集成测试,缺 陷 跟 踪,测试执行的步骤：试运行,系统联调,缺 陷 跟 踪,测试执行的步骤：维护,系统维护 二次开发 项目更新,单元测试,组合测试,集成测试,系统联调,回归测试,缺 陷 跟 踪,(5)测试评估的目标,提交量化的测试覆盖域 及缺陷跟踪报告 评估软件质量,测试评估的内容：覆盖域,哪些测试需求经过了测试 哪些需求通过了测试 我们的工作进度及效率如何,测试评估的内容：缺陷,我们发现了哪些缺陷 我们解决了哪些缺陷 遗留缺陷对软件有何影响,测试评估:综合评价,合格!,应用程序,4.软件测试组织与管理

4、,4.1、测试管理的目的 4.2、测试管理中的PDCA 4.3、测试管理控制对象的管理 4.4、测试流程控制和管理 4.5、统计分析和决策支持 4.6、软件测试过程组织,4.1、测试管理的目的,通过对产品的整个测试流程进行控制和管理，提高企业软件测试的管理水平； 灌输和强化企业的管理理念； 确保开发产品的质量； 进一步提高企业的市场竞争能力,4.2、测试管理中的PDCA,P：测试计划 D：测试案例及测试步骤的设计 C：测试实施和错误跟踪 A：测试总结与报告,4.3、测试管理控制对象的管理,测试管理控制对象（测试文档）包含的内容： 测试计划 测试案例 各案例的具体测试步骤 问题报告 测试总结报告

5、,4.3、测试管理控制对象的管理,软件测试文件描述要执行的软件测试及测试的结果 测试文件的编写是测试工作规范化的一个组成部分 开始于需求分析阶段、使用于整个生命周期中,测试计划,内容：详细规定测试的要求，包括测试的目的、方法和步骤。 时间：从需求分析阶段开始时间编写，到软件设计阶段结束时完成,测试报告,内容：测试结果的说明及结果分析、对软件的评价性意见 时间：测试阶段,测试文档的使用,验证需求的正确性 检验测试资源 明确任务的风险 生成测试用例 评价测试结果 再测试 决定测试的有效性,4.4、测试流程控制和管理,严格约束和控制整个产品的测试周期 测试人员与其他人员的交流均在该流程中体现,4.5

6、、统计分析和决策支持,通过建立测试数据库，进行合理的统计分析和数据挖掘 使项目管理者全面了解产品开发的进度、质量及问题的聚焦等，为决策提供支持 对测试人员及其他相关人员进行考核 在问题库中查找类似问题的解决方法,4.6、软件测试的过程及组织,4.6.1、测试阶段 4.6.2、测试方法的应用 4.6.3、测试人员的组织 4.6.4、软件测试文件,4.6.1、测试阶段,准备工作 划分阶段 代码会审 单元测试 集成测试 验收测试,4.6.1.1、准备工作,全面熟悉系统 编写测试计划 设计测试用例,4.6.1.2、划分阶段,代码审查 单元测试 集成测试 验收测试,4.6.1.3、代码会审,参加人员：程

7、序员、程序设计人员、测试人员 目的：通过阅读、讨论与争论促使问题 的暴露 活动：代码会审会,4.6.1.4、单元测试,参加人员：软件程序员、测试人员 目的：发现模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误 活动：采用结构测试辅之以功能测试,4.6.1.5、集成测试,参加人员：测试人员 目的：发现与接口有关的问题 活动：将模块组装起来同时进行测试,4.6.1.6、验收测试,参加人员：用户人员、测试人员 目的：向未来的用户表明系统能够像预定要求那样工作 活动：与用户共同验证软件的有效性,4.6.2、测试方法的应用,单元测试基本上是把白盒法与黑盒法结合使用，具体做法有两种： 用黑

8、盒法提出一批测试用例，然后用白盒法做验证，若发现用黑盒法产生的用例未能满足所需的覆盖标准，则用白盒法增补新的用例满足它 先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充,4.6.2、测试方法的应用,集成测试及其后的测试阶段，一般采用黑盒方法其步骤为： 用边值分析法和等价分类法提出基本的测试用例 用猜测法补充新的测试用例 如果在程序的功能说明中含有输入条件的组合，则在一开始就用因果图法，然后再按以上1、2两步进行,4.6.2、测试方法的应用,4.6.3、测试人员的组织,4.6.4.1、需求审查阶段 4.6.4.2、设计评审阶段 4.6.4.3、程序测试阶段,4.

9、6.4.1、需求审查阶段,组长 系统分析员 软件开发管理者 软件设计、开发人员 测试人员 用户,4.6.4.2、设计评审阶段,组长 系统分析员 软件设计人员 测试负责人,4.6.4.3、程序测试,组长：负责整个测试的计划、组织工作 测试人员：运行测试并记录测试结果,4.6.4、软件测试文档,测试文档的类型 测试文档的使用,4.6.4、软件测试文档,国家标准软件产品开发文件编制指南 测试计划 测试分析报告,4.6.4、软件测试文档,国家标准计算机软件文件编制规范 测试计划 测试设计说明 测试用例说明 测试规程说明 测试项传递报告 测试日志 测试事件报告 测试总结报告,5、准确估算与进度安排,5.

10、1、统计数据 5.2、致使估算不准确的几个主要因素分析 5.3、软件估算方法 5.4、进度安排方法 5.5、在测试过程中人员、过程和产品的平衡 5.6、小结,5.1、 Standish Group的统计数据,STANDISH GROUP 报告 超过预算 所占比例 低于 20% 14.5% 21 - 50% 31.5% 51 - 100% 29.6% 101 - 200% 10.2% 201 - 400% 8.8% 高于 400% 4.4%,5.1、 Standish Group的统计数据,STANDISH GROUP 报告 超时 所占比例 低于 20% 14.9% 21 - 50% 18.3%

11、 51 - 100% 20.0% 101 - 200% 34.5% 201 - 400% 11.2% 高于 400% 1.1%,5.1、 Standish Group的统计数据,Standish Group的统计数据表明软件项目 平均延误6-12个月 超出预算50%-100%,5.1、 Standish Group的统计数据,项目失败的原因 所占比例 1. 不完善的需求 14.1% 2. 缺乏用户的配合 12.4% 4. 资金的缺乏 10.6% 4. 不切实际的期望 9.9% 4. 缺乏公司高层的支持 9.3% 6. 需求的变化 8.7% 7. 无计划的进行开发 8.1% 8. 保持不需要的内

12、容 7.5% 9. 缺乏有经验的IT主管 6.2% 10. 技术力量薄弱 4.3% 其他 9.9%,5.2、致使估算不准确的几个 主要因素分析,估算进度由管理部门决定 项目启动时就已确定了发布日期 任务的估算基于有多少时间，而不是需要多少时间 任务的相互依赖关系不确定 在项目中忽略了意料之外的事情,5.3、软件估算方法,功能点和特性点 建设性的成本模型,5.4、进度安排方法,5.4.1、程序评价与评审方法和关键路径法 5.4.2、黄色粘贴法,5.4.1、程序评价与评审方法和关键路径法,输入： 分解产品功能 确定所有需要完成的任务 估算各个任务的工作量 确定任务间的依赖关系 给任务分配特殊的资源

13、 输出： 甘特图,5.4.2、黄色粘贴法,过程： 从完整的需求规格说明开始 将需求分为“必需需求”和“一般需求” 承诺只交付“必需需求”而不是“一般需求” 确定任务并产生初步估算 制订未来进度 根据实际信息进行调整 根据计划进度管理项目,5.4.2、黄色粘贴法,任务估算准则： 每项任务都应是短期的 使用80%的时间准则,5.5、在测试过程中人员、过程和产品的平衡,5.5.1、过程 5.5.2、人员 5.5.3、产品,5.5.1、过程,过程被忽略的原因： 忽略了商业目标和风险 不灵活 执行人员没有参加过程的制订 责任不明确 没有进行有效的沟通,5.5.1、过程,建立良好的软件开发过程： 创建“面

14、向过程”的氛围 建立一个与产品和商业目标相适应、灵活的书面过程 执行的人员主动参与过程的建立工作 确保书面过程的沟通与理解 确保过程的执行 过程要定期评审和修正，以提高过程的有效性,5.5.2、人员,CMM中人员能力成熟度模型的目的： “指导软件组织持续提高吸引、开发、激励、组织以及保留人才的能力，这些人才是软件开发组织稳步提高所必需的”,5.5.3、产品,项目事后剖析 筛选过程 根本原因分析,5.5、在测试过程中人员、过程和产品的平衡,对管理部门的要求： 理解与有效软件开发相关的问题 与解决问题的人员一起工作的承诺 想他人所想（员工和用户） 跟踪和责任,6、实现有效软件测试计划的方法,6.1

15、、软件测试能力的评估 6.2、软件测试策略的建立 6.3、软件测试方法的建立 6.4、软件测试技术的采用 6.5、小结,6.1、软件测试能力的评估,软件测试机构的8项标准： 计划 Test planning 培训 Training of testers 管理 Management support for testing 满意度 User satisfaction whth testing 过程 Use of testing process 经验 Efficient testing practices 工具 Use of test tools 质管 Quality control over te

16、st processes,6.2、软件测试策略的建立,4.2.1、系统开发生命周期中的测试成本 4.2.2、测试的结构化方法,软件测试策略的建立,不同类型的软件对不同质量特性的要求程度不同，如控制飞机起落架的软件、银行系统软件、停车场软件等，它们出现故障造成的后果不同 根据不同类型的软件分别确定测试需求 依据测试需求选取测试技术,软件测试策略的建立,影响测试需求的因素： 项目大小 预算 独特性 危险程度 修复故障所带来的费用,测试计划中对风险的确定,任务和目标 项目符合客户组织 项目符合提供者的组织 客户的感觉 工作流 规划管理 目标冲突 资源冲突 客户冲突 领导,测试计划中对风险的确定,规划管理人经验 规划的定义 决议驱动者 政治影响 合适的日期 诱人的技术 短期解决方案 组织管理 组织的稳定性 组织的