Flash游戏项目测试经验总结
Flash游戏项目测试经验总结
　　由于最近一位朋友在找测试工程师方面的工作，面试中经常被问到以前的项目经验，所以拜托我帮她写一篇项目测试经验总结，上午草草完成，随便也发上来供大家交流。　　经验心得：　　目前本人负责测试一款Flash游戏―挖金矿，虽然此游戏在互联网上已经很流行，并且功能点相对于网络游戏而言不算很大，但通过执行测试直到项目结束测试，发现了很多对功能测试没有深刻认识的地方，现对这些问题进行总结，希望能通过此篇心得来跟大家进行沟通交流：　　● 从需求设计开始测试　　以前由于未深刻认识测试的整个流程，很理所当然地认为测试人员扮演重要角色的阶段是在开发人员提交测试版本的时候，但通过挖金矿的测试，发现测试人员其实在项目的需求分析阶段，就要根据自己的经验和分析对需求进行严格的审查。　　测试人员需要很认真地对待需求讨论，因为需求是整个项目的出发点，如果源头上出现问题的话，后续的设计、开发、测试也会相应地出现偏离。并且这种错误很难去发掘，往往在功能基本已经完成或者项目已经上线之后才能体现出来，因此测试人员在评审需求说明书的时候，就要开始细心地发现不足与需求缺陷，通过挖金矿的需求评审，本人总结的经验主要有：　　1）首先需要对项目的功能、游戏道具、道具效果如何叠加、游戏角色、项目性能资源指标进行具体的检查分析；　　2）在需求当中如果涉及到数据，就需要仔细检查是否写明了数据的格式、取值范围；　　3）如果功能之间有关联的话，要考虑到其中一个功能内容的修改会导致其关联功能哪些内容的相应变更，这样在编写测试用例的时候才能考虑全面；　　4）在进行需求评审时，多多考虑一些特殊场景，特别是游戏道具，比如买了强力药剂，则下一关的抓取速度会提高，但如果在游戏过程中抓取运气袋的时候，也随即到了强力药剂的时候，此时是应该出现叠加效果，使得抓取速度更快，还是应该给予玩家其他奖励；　　5）需求说明书中对于用户操作需要说明其业务流以及响应时间，整个项目的CPU占用、内存消耗等性能指标也需要说明，游戏的日志需要记录这些数值，便于测试人员在测试过程中进行检验。　　● 测试过程中细化思路　　在执行测试过程中，经常维护自己的测试用例也比较重要，因为在未进行测试时所编写的测试用例比较抽象，与开发人员的认识也存在差异，往往接触到测试版本之后，才会对项目有直观的认识，发现之前编写的测试用例考虑不够全面的地方。　　以这次挖金矿的测试来说，在中间的关卡中出现了游戏时间有所变快的bug，但自己在之前编写的用例中未完全考虑此种情况，只是主要到时间的数值是否符合需求的每个关卡120秒的要求，因此在涉及到时间的测试时，不但需要注意范围，也要注意其节奏是否正确，同时未考虑细致的地方，通过测试用例的补充，在测试后期总结时期，也便于让自己的测试思路变得更加缜密。　　● 测试需要考虑用户体验　　测试人员在进行测试时，不能完全止步于发现需求考虑不完善、功能缺陷、性能未达标的bug，测试的目的除了发现项目的缺陷之外，还需要对项目的整体质量情况进行评估。因此测试过程中还要注意到项目的用户体验、操作简便性方面的问题。　　还是以自己挖金矿的测试体验来做反面教材，在测试的后期组织其他客服人员进行体验，在收集的反馈意见中，对于甩出钩子的时延、说明文字的理解歧义问题比较多，说明当用户在操作游戏过程中，往往操作响应、界面展现是最关注的，说明测试人员在进行测试时，也需要关注此方面可能隐藏的问题。　　由于体验方面的问题属于比较主观的，在不同人眼中也会有产生争议的观点，但作为测试人员，对于此类问题也需要进行记录，建议放在组内或测试部中进行讨论，当问题达成共识的时候，可以由小组负责人进行汇总反映，通过这些问题的认识，帮助项目更贴近用户，也使得自己测试的视角更加广阔。　　● 理解版本配置管理
　　版本配置管理也属于测试部的工作内容，虽然配置管理不是由我负责，但通过别人的指导了解之后，也认识到管理好版本也是测试过程中的重要环节。版本配置管理其目的是为了防止版本出现混乱，同时也方便人员对版本的质量情况进行跟踪分析，我们公司的版本按照项目来进行划分，并且每个项目分为代码库和文档库两大类：
　　代码库
　　主要分为开发库、基线库、产品库。其中开发库供开发人员提交代码、基线库供测试人员获取测试版本、产品库为现网版本的整理，整个代码库的管理过程如下：
　　文档库
　　主要根据项目的流程来进行结构划分，主要有立项、计划、需求、开发、测试、发布、其他资料七个部分。
　　原帖地址：
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&2027人阅读
&&& 打基线就是给被打基线的东西加一个标识，然后在这些东西已经有了变化形成了新的版本后，还能看到打基线的时候这些东西的原来的样子，从而可以对其进行追踪和版本隔离。
在项目管理中，打基线主要是在项目进入另一个阶段时把上一阶段的东西打个标识，从而也作为下一阶段的开始。
&&& 在程序发布时打基线也是尤为重要，如果每次发布新版本时都打一个基线，那么可以做到版本回滚；查找特定版本的BUG；比较版本之间的差异；发布老版本等等。
通常版本控制软件都有实现打基线的功能。
而SVN又是如何来打基线?
其实SVN天生就可以根据一个修订版本号检出一个特定的修订版本，只不过如果你不嫌麻烦你可以用一个excel记录一下你当前发布程序时其主目录对应的修订号。这样在需要的时候可以根据这个修订号把当时的文档检出来。
但是通常在SVN上打基线还是通过“分支/标记”功能来实现的，在ecplise中的实现方式如下：
1。点击"window-&Open Perspective"，选择"SVN资源库研究"。
2。在界面左边部分的“SVN资源库”中选择要打基线的项目的根目录，右击鼠标，在弹出的菜单中选择“分支/标记”。
3。在“到URL”中填写你要把其基线打在什么目录，一般要改成其它目录，然后点击确定即可。
这样操作后其实是产生了一个分支，这个过程并不耗费SVN服务器的存储空间，因为其只是类似于物理链接的方式创建了了个对应于当前修订版本的链结，所以我们可以每发一个版本就打一次基线而不用担心SVN空间被耗光。
在下次需要用到该基线的时候只要把SVN中我们在上面第三步中填写在“到URL”目录检出即可。
但是基线是不能修改的，体现在SVN中就是你从基线目录中检出的文件如果做了修改，再提交就变成了一个于原先项目不同的分支版本。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：209758次
积分：2115
积分：2115
排名：第16073名
原创：72篇
转载：19篇
评论：41条
(1)(2)(3)(1)(1)(5)(67)(3)(2)(3)(1)(1)(1)A公司CMMI软件质量管理具体实施,mba企业管理论文_学术堂
| [ 学术堂-专业的论文学习平台 ]
您当前的位置： >
A公司CMMI软件质量管理具体实施时间： 来源：学术堂 所属分类：
本文字数：15185字
&&& 本篇论文目录导航：【第1部分】【第2部分】【第3部分】【第4部分】 A公司CMMI软件质量管理具体实施【第5部分】【第6部分】
　　第三章 A 公司基于 CMMI 的软件质量管理实施
　　3.1 CMMI 模型选定
　　A 公司从 2004 年开始较强烈的意识到企业在运作过程中竞争力越来越低，结合行业所处的大环境以及行业不断提升的准入规则和行业对软件质量，过程改进的迫切需求，开始着手挑选符合公司发展，增强公司竞争力的的框架和模型[11]。而此时也恰逢 CMMI在中国进入了一个飞速发展的时期，因此 A 公司经过多方权衡，启动了 CMMI 认证和实施 CMMI 项目质量管理的方案。
　　3.2 组织架构调整
　　3.2.1 增设质量部门
　　A 公司为了有效实施 CMMI 的项目质量管理，整合资源，降低人力成本，在组织架构方面调整最大的是在总经理下，增设了独立的质量中心，与开发中心并行。这样子权责更加清晰，有了一个统筹整个公司质量，实施质量的计划、控制、保证，并且可以真正落实质量管理的部门。
　　3.2.2 明确组织分工
　　A 公司依据 CMMI 的要求，重新梳理和规范了软件开发过重的规范和组织内结构及相关人员的角色，如下图 3-3
　　1、软件工程过程组（Software Engineering Process Group，简称 SEPG），成立为项目组指定项目过程，包括软件过程定义、软件过程维护与改进、软件过程的部署实施指导、软件过程财富的建立与维护[12]。其目的是提供过程上的指导，帮助项目组进行策划，从而让项目组可以更有效的工作，并且有效的执行过程。SEPG 主要由专家构成，由管理层任命，在关键实践中负责组织软件过程活动，而当项目与质量保证在过程理解上发生争持，SEPG 将作为最终的仲裁者。
　　2、软件工程组，主要由负责软件项目的需求分析，系统设计，程序编码，集成测试等活动的所有人员组成。其中需求分析人员主要进行市场调研、与客户进行交流沟通，获取软件项目需求，明确需求的边界和范围，并且对系统需求进行识别和分析。系统设计人员主要做的事情就是完成软件系统的设计，包括概要设计、详细设计，并且识别和评估风险，并且对软件项目的开发提出建议；程序编码人员，主要任务是协助项目经理，评估项目的开发任务和时间，制定和维护《项目开发计划表》；及时的与项目经理沟通和汇报工作进展，依照项目组制定的编码规范，按时按质的完成编码和单元测试工作；在集成测试阶段，积极配合测试人员，修正软件中暴露的缺陷，为系统正常上线做准备；系统测试人员主要任务是制定和执行《测试计划》以及《测试用例》，在预期时间内完成系统的测试，并且反馈测试意见和缺陷情况，确保软件系统的每个功能都符合需求预期，以及确保系统的可靠性和稳定性。
　　3、软件配置管理（Software Configuration Management，简称 SCM），应用于整个软件工程过程，贯穿于整个软件生命周期，负责软件项目开发过程中进行配置标识、组织和控制修改。软件配置管理对软件企业的管理人员和开发人员都有重要意义，它主要包括三部分内容：版本控制、变更控制、过程支持。
　　A 公司根据软件开发的特性将将软件配置划分为两个阶段，分别是计划阶段和开发维护阶段。其中计划阶段，只要项目经理制定项目开发计划之后，软件配置管理的活动就可以开展。只有在项目启动之初制定软件配置管理计划，才可以对软件生命周期中的所有关键活动进行有效的跟踪和记录。制定软件配置管理计划的过程如下：
　　1）配置控制委员会（Configuration Control Board，简称 CCB）确定项目的各开发策略和里程碑；2）配置管理员（Configuration Management Officer，简称 CMO）根据配置管理计划执行各项管理任务，并且定期的向 CCB 提交报告，列席 CCB 的例会；3）CCB 通过配置管理计划后，交予项目经理批准，进而发布实施。
　　在开发维护阶段是软件项目的主要阶段，其软件配置管理活动主要可以分为三层面：
　　1）主要由 CMO 完成管理和维护工作；2）由系统集成员（SIO）和开发人员（DEV）执行配置管理的策略。其中，SIO 负责生产和管理软件项目的内部和外部的发布版本，主要职责有：集成修改、构建系统、版本日常维护、构建外部发布版本；DEV 的职责是根据项目组内确定的软件配置管理计划和相应规定，依照软件配置管理工具的模型来完成既定的开发任务。
　　3）变更流程
　　以上三个软件配置管理活动的三个层面既相互独立又相互联系。软件配置管理过程中的核心流程如下：
　　1）CCB 设定初始基线；
&&& 2）CMO 根据软件配置管理规划，设置配置库和工作空间。
　　3）DEV 依照软件项目配置管理策略，根据分配的权限对资源进行访问，开展软件项目开发工作。
　　4）SIO 集成开发成果，并进行系统构建，推进版本演进；5）CCB 审核变更需求，划定新基线，确保版本正确。
　　除了以上的核心流程，还制定了在其他活动中不同角色的分工如下：
　　1）DEV 依照开发模型进行开发任务；
&&& 2）SIO 将项目成果归并，集成分支，以供测试或者发布；
&&& 3）CMO 定期提交审计报告，并在 CCB 例会中报告项目可能存在的问题和改进的方案；
&&& 4）在基线制定生效后，所有要对基线的变更，都必须提交变更申请并经过 CCB 的批准；
&&& 5）CCB 定期举行例会，并综合 CCB 成员所掌握的情况、CMO 的报告以及项目开发人员的请求，对软件项目配置管理计划作出修改。
　　4、软件质量保证组，主要负责软件项目的审核和验证工作，检查所有 SCM 活动和产品并及时更新 SCM 文档。CMMI 模型要求软件企业必须要建立质量保证（QA）角色，以便检查软件系统开发活动和项目管理活动是否与制定的过程策略标准一致。在 A 公司中，QA 主要由质量中心根据项目组的需要分配。QA 独立于项目组，保障评价的客观性。
　　3.3 完善过程与产品质量保证
　　3.3.1 完善质量管理体系
　　A 公司出现的这种项目延期与成本超支的情况，其实在很多项目型的软件公司，特别是外包型的软件公司中普遍存在，其归根结底，是对软件过程的把控出现了问题，更本质来说是对质量的关注程度不足。因此 A 公司在质量管理上，参照 CMMI 模型规定的关键过程域，建立了公司的质量管理体系的基本框架，其主要对质量管理的三个部分：质量规划、质量保证、质量控制以及持续改进做了规定。
　　3.3.1.1 质量规划
　　所谓的质量规划，就是要判断哪些质量标准与当前系统相关，并且决定应如何达到这些质量标准。A 公司在做质量规划的首要任务，是识别和梳理出公司软件项目开发的业务流程。在该业务流程识别出来后，EPG（工程过程组，Engineering Process Group）组织按照 CMMI 模型对它进行评价和分析。在具体的项目质量保证规划的制定上，A 公司制定了流程如下图 3-4：
　　在这个软件质量规划制定流程中，A 公司首先先明确项目的质量目标，并且将目标分解到每个工作包中，然后按照职责和分工，将工作包的质量目标落实到每个小组成员质量目标就是一个软件项目确立的量化数值或者类别。
　　3.3.1.2 质量保证
　　在软件项目开发周期中，质量保证贯穿于整个过程，它包括了指导和改进过程，保证所有的规定的准则和流程都得到落实，确保所有的问题都得到了及时的发现和处理。
　　质量保证被称为管理层的耳朵和眼镜（ears and eyes）[14]。A 公司在实施质量保证的措施主要有以下几方面：
　　1、建设有效 QA 组织
　　A 公司在早期的部门设置实施的是职能型的组织架构，每个项目组都会设置自己的QA 岗位。这种设置的优点是 QA 人员与项目组成员同属一个团队，容易深入到项目组中的具体工作，并且更容易从日常的工作中收集问题，更利于快速处理问题。但正如上面也提到这种职能型的组织架构他的缺点也是非常明显的，那就是每个项目组之间是相互独立的，每个项目组之间的交流和资源共享比较薄弱，因此造成了很多重复的工作，比如重复的进行过程、方法和工具的研究，而没有很好的借鉴其他团队的经验。鉴于在职能型组织架构中的很多缺点，A 公司设立了专门的质量中心来统筹和分配 QA 和 QC资源。QA 与项目组相对独立，行政上向质量部门汇报，在业务上向项目经理汇报。在这种组织架构上，QA 的工作绩效是由质量部门的总经理直接考核，项目经理可以对 QA的工作情况进行反馈，因此更有利于保证 QA 人员评价的客观性和公正性，有利于调用QA 人员的工作积极性，也有利于 QA 成员长期利益。在 QA 资源分配上，QA 资源的分配时根据具体项目的特点和需求，项目的工作量和进度需求而确定的。在通常情况下，A 公司规定了一个 QA 最多负责 5 个软件项目，平均来说，一个 QA 负责 3 个软件项目，这主要是综合了金融业软件的特点而制定的，这有利于资源合理分配和保证软件质量保证的实施是有效。在 A 公司中，QA 的职责包括：过程指导与评审、产品审计、过程改进与度量[15]。
　　在项目的初期，QA 要有效的辅助项目经理制定项目计划和项目质量计划，帮助项目进行估算，包括功能点估算和时间进度估算，设定质量目标，并且完成对项目组成员过程和规范培训；在项目过程中，QA 要有选择性的参与项目的技术评审，日常工作中要关注项目的进展，定期对项目的工作和过程做审计和评审；同时 QA 也承担度量数据的收集、统计和分析工作，用于支持管理决策。
　　2、规范质量保证活动组织
　　A 公司制定的质量保证活动的组织中，各个角色的职责定义如下：
　　1）PST：听取 SEPG 汇报，调配活动资源；
&&& 2）SEPG：审批和监控质量保证活动，对质量保证活动中出现问题予以支持和解决；
&&& 3）项目控制主管：为项目的质量保证活动提供资源，对 QA 报告和项目组报告中项目组不能解决的问题予以支持、解决并继续上报。对 QA 工作的客观评价；
&&& 4）项目负责人：按照公司质量体系文件要求实施，积极配合质量保证活动，跟踪项目实施过程中的质量保证活动（评审、代码检查等）；
&&& 5）项目组成员：按要求（公司文件、模版和计划等）实施并产生项目成果；
&&& 6）QA 经理：为项目的质量保证活动提供独立的 QA 资源，审阅 QA 报告，监督QA 工作，对 QA 报告中不能解决的问题予以支持、解决，对不能解决的问题继续上报；
&&& 7）QA：对项目组进行质量体系文件与本项目相关部分的应用培训，跟踪监督项目实施过程活动，检查项目成果是否符合规范、规定等要求，向 QA 经理、项目控制主管报告；
&&& 8）测试部（组）负责人：审阅测试管理员的报告，监督测试管理员工作，提供独立测试管理员资源；
&&& 9）测试管理员：来自公司测试部（组），协助项目组制定适合项目实际情况的测试方法和过程，参与项目的测试总体计划、测试方案、测试设计说明书、测试用例的编写和评审，参与测试实施，测试总结，负责测试过程中数据的收集统计和分析，积累测试过程的经验和方法，对测试过程负责；
&&& 10）测试负责人：按体系文件、项目计划和系统需求编制《测试计划》、《测试方案》，执行测试过程，发现测试缺陷并解决，确认各阶段的测试结果，对测试过程负责，提供《测试总结报告》；
&&& 11）SCM：负责项目实施过程中的软件配置管理活动，配合 QA 对软件配置管理活动的检查。
　　3、质量保证制定流程
　　1）制订《项目实施指导》
　　QA 根据已定义的项目生命周期阶段，以及《项目裁剪指导》、项目标准实施指导、公司相关程序文件和指导书等和项目负责人共同协商制订具体项目的《项目实施指导》。
　　《项目实施指导》必须经过 SEPG 的审批，具体参见《评审过程指导》。审批通过后形成基线，对纳入基线的《项目实施指导》的变更，按变更流程进行管理。
　　2）编写《质量保证计划》
　　QA 根据《项目总体计划》编制《质量保证计划》和相关检查表，内容必须与公司质量体系文件、项目计划相一致。计划的编制可参考《质量保证计划》模版，对具体项目而言，在项目启动时由 QA 和项目负责人协商确定。《质量保证计划》作为《项目总体计划》的附件，必须经过 QA 经理和项目控制主管的审批，具体参见《评审过程指导》。
　　为加强项目实施过程中项目组所有成员的质量意识，保证项目按质量体系文件规定的相关活动顺利开展，QA 在编制《质量保证计划》的同时，应按照项目启动会中确定的、质量体系文件中规定的与本项目相关部分内容对所有项目成员进行培训。
　　3）QA 监控与评审
　　QA 经理负责对公司所有项目的执行监控，对每一个项目均配置 QA 人员，QA 负责向 QA 经理和项目控制主管汇报。274）质量保证活动。
　　主要体现在参与项目不同阶段（如立项、里程碑、结项等）的检查与评审活动，确认项目实施过程是有计划的、完整的，关注：
　　●项目有明确计划过程，并已按要求定义项目软件生命周期、里程碑、基线等；
　　●项目实施各过程（如计划、需求、设计、配置管理等）已按体系文件规定要求执行；项目文档（如项目计划、需求分析过程记录）已采用公司体系文件定义相关表格；
　　●项目文档已具备完整性；
　　●项目各里程碑已按项目计划要求实施评审（包括评审过程和代码检验等），并对实施过程进行监控；
　　●项目评审活动中发现的问题（例如：文档、代码等）已明确并得到解决处理，监控缺陷解决过程；
　　●对需求，重点监控需求状态以及需求改变的数量，并填写相应记录表格；监控贯穿于整个项目工作产品的需求的一致性；
　　●监控项目软件配置管理过程，检查相关的配置项和报告，保证质量标准和完整性，组织基线审计；
　　●项目计划已按要求进行完整的过程跟踪与记录；
　　●按项目《质量保证计划》的要求，依照《项目实施指导》、《过程指导与检查表》，对项目进行产品审计和过程审计，制定并上报《QA 审计报告》。
　　1）质量保证活动记录
　　QA 检查表：QA 根据《项目实施指导》和《过程指导与检查表》对项目的实施过程和工作成果进行不定期检查，并做记录以便跟踪。对于具体项目而言，可能需要补充其它类型检查表，内容格式参考已有的检查表定义。每次检查结束后，QA 应将检查结果汇总，通知项目负责人、项目组成员及项目控制主管。
　　《QA 周报》：记录 QA 的工作内容，和发现的问题、处理过程的跟踪情况，并对工作量进行统计。
　　《QA 审计报告》：QA 根据《质量保证计划》中的规定，按时间要求参加项目质量保证活动，对项目的产品和过程进行审计，汇报审计结果，并对检查过程中发现的问题进行总结，提交 QA 经理、项目负责人、销售负责人和项目控制主管。
　　《客户满意度调查表》：QA 定期或不定期向客户发放《客户满意度调查表》，由客户填写，了解客户对项目的满意程度，每次调查结束后，QA 将结果提交 QA 经理、项目负责人、销售负责人和项目控制主管。
　　QA 总结报告：总结进行过的质量保证活动，由 QA 负责完成。根据特定的项目计划要求，对每个项目的质量保证活动进行总结，在项目结项时，QA 要将《QA 项目总结报告》以及 QA 活动的相关文档与项目相关结项文档一起归档保存。
　　QA 经理在年终时，应对所有 QA 的活动进行总结，汇报给 PST。
　　2）问题报告与处理
　　对于项目质量保证活动中发现的问题，首先与项目负责人沟通，在项目组内部解决，如在项目组内部不能解决的问题，采取逐级汇报：QA(项目负责人)&QA 经理（项目控制主管）&SEPG&总裁(总经理)；问题需要继续汇报原则是在每一级出现以下情况（其中之一）时：
　　●上一级没有达成解决办法；
　　●解决问题的时间周期不恰当、无法保障；
　　●解决方法有悖于自身的质量目标；总裁（总经理）对未解决的问题有豁免权。
　　3.3.1.3 质量控制
　　质量控制主要是用来监督工作进展以及检测需求是否已被满足的过程和方法。质量控制由一系列定义明确，针对产品的检查组成，其目的是在产品发布前对缺陷进行评审和排查。这些检查可以从质量规划中得到描述。一般情况下，质量控制包括代码检查，文档检查已经最终交付物检查。一般情况下，在软件生命周期中的每个里程碑都要执行文档和产品检查，以验证当前的这些文档和产品是否按照软件质量规划中说明的标准相符，确保提交给客户的最终交付物，包括需求文档，设计文档，构建代码，测试报告，用户指引，维护手册，都是按照规划的需求。
　　通常情况下，质量控制可以根据项目的级别安排不同的组织执行。对于较小项目通常是由软件质量部门协调质量控制人员来对软件项目功能和文档进行检查。对于较大型项目，则需要专门的设立控制委员会来负责质量控制。而该委员会要代表多方需求，因此由客户或者客户方代表、软件质量部门的成员以及项目的负责人组成。
　　质量控制的目的是为了检查缺陷以便得到修复，而质量保证是用于预防缺陷的发生。
　　所谓的检查，即意味着期待软件产品或者项目的缺陷可以被充分暴露出来，质量保证则更多的是一种管理手段，通过实施质量保证来阻止缺陷预防缺陷产生。
　　1、完善测试流程
　　软件测试是保证软件不偏离功能需求，质量需求的最直接的手段，通过软件测试，可以验证软件是否满足功能需求，发现软件缺陷以便修复。软件开发过程，其实是一个不断的需求明确和传达，再到实现的过程[16]，其中经历的每个环节都有可能会出现信息的失真，或者对某个需求理解的偏差，真正实现软件开发的是处于信息最末端的开发人员，而且不同的开发人员的能力也有所区别，因此在软件生命周期的每个阶段都可能不可避免缺陷的产生。就算在软件周期的每个阶段都进行严格的审查，但是这种审查也不能发现所有偏差和缺陷，此外在编码过程中也还会引入更多的新的问题。如果在软件准备交付客户进行投产前，没有将软件系统存在的绝大部分问题纠正，这样子系统是非常危险的。而且当代码的缺陷在正式投产之后才暴露的话，那么纠正这种缺陷的代价是非常大的，而且这种缺陷造成的影响也是无法评估的。
　　A 公司为了能够更好的进行软件测试，提高测试的整体效率以及降低软件项目的整体成本，在软件测试设置了原则：
　　1）没有所谓的完全测试概念，也就是说软件的缺陷毫无遗漏的找出来是不可能的。
　　这主要是因为软件项目的输入量大，输出结果多，软件分支多，缺乏对缺陷评价的客观标准；
&&& 2）测试无法暴露潜伏的软件缺陷，更不可能找到所有缺陷；
&&& 3）并非所有软件的缺陷都是可以修复的；当前软件项目开发过程中存在两种主流的软件测试模型，分别是V模型和X模型[17]。
　　V 模型是一个将测试定义为一个与软件开发过程是同等重要的过程，并非是软件缺陷的时候弥补行为。V 模型紧密的连接了开发和测试的关系，软件的测试流程，可以看做是软件开发过程的组成部分。整个软件开发的过程可以按照软件开发生命周期的次序划分为几个阶段：需求分析、系统设计（概要设计、详细设计）、编码与构建、测试（单元测试、集成测试、系统测试、验收测试）。每个阶段之间都紧密相扣，上一阶段的输出是后续阶段的输入。在 V 模型左侧是开发过程的每个阶段，右侧是代表测试流程。V 模型存在一定的缺陷，主要是因为他仅仅把测试的过程看做是需求分析和系统设计及编码之后的一个阶段，而忽略了测试对需求分析、系统设计的验证，让这类型的问题在验收测试阶段才被发现。
　　A 公司基于 CMMI 制定的测试流程，主要是在 V 模型的基础上，在需求分析完成之后增加了对需求分析测试；在系统设计阶段完成后增加了系统设计测试。这样子，A公司制定总的软件测试流程为：需求分析测试、系统设计测试、单元测试、集成测试、系统测试、验收测试。由于新增的两个测试都放在响应的阶段之后，有效的方式了在需求阶段和系统设计阶段的缺陷在验收阶段才发现，降低了缺陷修复的成本和风险，可以确保软件开发的质量的同事，缩短了开发的周期。
　　2、持续集成管理
　　在整个软件项目的开发生命周期，会伴随版本的迭代和持续的集成工作[18]。同时为了可以区分不同版本在整个软件生命周期中所处的位置，给软件项目的开发定义不同的里程碑，A 公司制定了以下软件版本：
　　1）Alpha 版&公司内部测试版本。Alpha 版本的特征是：软件的所有功能都基本上按照需求开发完成，并且开发人员已经对功能做好单元测试；所有功能都已经通过了质量部门的集成测试工作，并且该版本的功能在正式发布之前将不会再增减；在集成测试中发现的已有的软件缺陷，严重或以上级别的已全部修复并且通过回归测试确认；软件的性能可以通过数据定量的提供参考。
　　2）Beta 版&对外发布版本，Beta 版本的特征是：非严重性缺陷基本完成修复，并且通过了回归测试的验证；在一段时间内，新缺陷的出现率低于修正率；完成了测试计划中的每一项系统测试工作；所有最终交付的相关文件，包括用户指南，软件说明，版本说明等，都完成了最后的修正工作。
　　3）发布版&正式对外发布的版本，该版本的特征是：长时间内新缺陷的出现率低于修正率，并且这种情况一直稳定保持一段时间；质量部门完成了所有已修正缺陷的回归测试工作；在软件系统不影响客户使用的情况下，所有客户反馈都已妥善处理；所有交付客户的文件都已经准备就绪。
　　3.3.2 完善问题和缺陷管理体系
　　在软件项目实施过程中出现的各种问题大体可归为两类：问题和缺陷。
　　缺陷：特指实施项目阶段发现的各种技术性问题，缺陷主要来源于各种评审和测试；?
&&& 问题：特指实施项目阶段发现的各种管理性问题，非缺陷的都属于问题；
&&& 问题、缺陷均分类为四级：
　　严重(Critical)：可能导致项目停顿，需上报项目控制主管或 SCCB；
&&& 主要(Major)：可能影响项目的实施计划，需上报项目负责人；
&&& 次要(Minor)：不会影响项目的实施，由项目组成员协商解决；
&&& 轻微(Cosmetic)：由项目组成员自己解决。
　　3.3.2.1 问题和缺陷发现与登记
　　项目组中发现了问题和缺陷将问题和缺陷记录在缺陷管理工具中，由工具按缺陷流程进行管理，或记录在《缺陷统计分析表》，将发现的问题和缺陷提交给项目负责人，进行分配解决，并由发现人对问题和缺陷的解决情况进行跟踪直至关闭。
　　QA 在对项目进行质量保证工作时发现的问题和缺陷，在《QA 周报》中的 QA 活动记录表中进行记录，并将问题和缺陷反馈给项目负责人，对问题和缺陷的解决情况进行跟踪直至关闭。
　　对于测试过程中发现的缺陷，按照《测试指导》相关要求处理，记录在《缺陷统计分析表》。项目进行过程中的问题和缺陷通过评审或其他活动发现，问题和缺陷发现人有可能是：客户、项目成员、销售负责人、QA、项目控制主管等等。
　　3.3.2.2 问题和缺陷处理
　　项目负责人根据问题和缺陷性质、级别和影响范围等判断问题和缺陷的修改过程是否涉及已纳入基线的配置项更改：
　　涉及：进入《变更过程指导》，提交 SCCB，申请更改；SCCB 审批通过后，执行更改。
　　不涉及：由相关项目成员负责修正、处理；对问题和缺陷解决责任人不明确的，由项目负责人指定人员完成，同时项目负责人还应指定问题和缺陷验证人。
　　对于主要的问题和缺陷，项目负责人可根据具体情况制定解决方法和措施。
　　对于严重的问题和缺陷，项目负责人必须上报项目控制主管，项目控制主管根据问题和缺陷的性质及影响范围组织制定解决方案和措施。
　　问题和缺陷处理完成后，处理人将处理过程记录在缺陷管理工具中或《缺陷统计分析表》中进行记录，并提交验证人。
　　4.3.2.3 问题和缺陷验证
　　问题和缺陷处理完成后，验证人对修正结果进行验证，无误后，此问题和缺陷可正式关闭；反之，继续修正。
　　问题和缺陷验证完成后，验证人将验证结果记录在缺陷管理工具中或《缺陷统计分析表》中，并提交项目负责人。
　　3.3.2.3 问题和缺陷跟踪
　　项目负责人应跟踪问题和缺陷的处理过程，并记录缺陷管理工具中或《缺陷统计分析表》中。
　　为保证统计信息的全面性、完整性，所有问题和缺陷受理人在受理问题后，应及时通知项目负责人，由项目负责人对问题和缺陷处理过程的监控。
　　对于评审过程中发现的问题与缺陷，应按照《评审过程指导》的相关要求进行跟踪，并记录在缺陷管理工具中或《缺陷统计分析表》中。
　　对于测试过程中发现的缺陷，应按照《测试指导》的相关要求进行跟踪，并记录在缺陷管理工具中或《缺陷统计分析表》中。
　　对于项目实施的各阶段以及各个过程中发现的所有问题与缺陷，应在项目结项时进行汇总统计，由缺陷管理工具自动进行同进或《缺陷统计分析表》中进行统计。
　　3.4 完善配置管理
　　作为 CMMI 的 22 个过程域中的&配置管理&过程域，主要用于指导软件组织的度量过程，其目的是采用配置标识、配置控制和配置状态统计，以及配置审计来建立和维护软件产品的完整性，并且保证软件系统版本的可回溯性[19]。软件配置管理贯穿于整个软件项目生命周期。软件配置管理的基本流程如下图 3-8：
　　在 CMMI 中规定，配置管理可以分为&配置项和基线管理&、&变更控制管理&和&基线完整性&三个部分。
　　3.4.1 配置项和基线管理
　　配置管理的对象是配置项，而配置项是由一个或者多个文件组成的[20]。典型的配置项有：项目计划、需求规格说明书、概要设计说明书、详细设计说明书、源代码、测试计划、测试用例、测试数据、质量手册、用户手册、维护手册等。
　　基线指的是通过已经通过正式审核与同意，可作为下一步开发基础的配置项，如需求基线、计划基线、设计基线等。
　　标识基线：为了方便版本回滚，当项目进行到关键时期，需针对当前的配置项对做一次版本标签；频次：当项目中期目标达成或项目关键转折点或阶段成果告一段落时。
　　受控基线：对已定版的配置项纳入基线库，并对该配置项进行加锁，对该配置项进行受控管理。
　　发布基线：把已形成最终产品并将要进行发布的配置项纳入产品库，并建立基线。
　　配置管理库：包括开发库、测试库、基线库（受控库）和产品库。
　　开发库：在软件生命周期的某一阶段期间，存放与该开发活动相关的配置项及相关信息的库。
　　测试库：存放单元测试之后、系统测试结束之前的，与测试相关的配置项。
　　基线库：在软件生命周期的某一阶段结束时，存放作为阶段成果而释放的、与开发活动相关的配置项及相关信息的库。如果要修改已并入基线库的配置项，必须要参展《变更过程指导》进行。
　　产品库：产品正式提交用户前， SCM 在 PM 的指导下提取基线库中能构成最终产品的配置项。
　　在执行以上配置管理的过程中，涉及到的一些角色以及其职责有SCCB：审批配置项纳入基线库/产品库；审批基线库/产品库中配置项的变更申请，审批变更后的配置项纳入基线库/产品库；项目负责人：指导 SCM 开展配置管理活动；SCM：负责项目组配置管理库的配置管理活动并向相关人员提交相应的报告，制定《配置管理计划》，维护《配置项关系表》；项目组成员：执行《配置管理计划》中相关要求；项目归档管理员：负责项目结项归档或阶段归档的相关文档资料的统计和管理，确认并清点项目归档清单的一致性。
　　备份人：由项目负责人指定，负责对配置管理库进行备份，可以是 SCM 或项目组其他成员担任。
　　QA：在项目实施过程中监控项目的配置管理过程和报告，保证质量标准和完整性；验收时，与 SCM 及相关技术人员等进行基线审计活动，检查基线库中配置项的一致性和符合性，与其共同完成《配置审计报告》，同时还需填写《配置管理检查表》。
　　公司级配置管理员：接收项目 SCM 提交的配置管理相关报告，协调解决项目中配置管理出现的问题。
　　A 公司在软件配置管理的配置项和基线管理主要做的优化有：制定配置管理计划、设置配置管理库、发布过程控制、备份、配置状态监控和审计3.4.1.1 制定配置管理计划。
　　SCM 根据《项目总体计划》的要求制定《配置管理计划》，规定在项目开发过程中配置管理活动、要求等，作为《项目总体计划》的附件提交 SCCB 和控制主管审批，审批通过后方可纳入基线库。
　　1、流程
　　2、描述
　　项目启动时，项目负责人指定 SCM，确定项目组成员及其它相关人员对配置管理库的访问控制权限；? SCM与项目负责人商议确定配置管理工具、基线库的目录结构、配置项内容及其标识规范、基线等；SCM 建立配置管理环境，包括安装工具软件，建立开发库和基线库的工作区及其目录结构。
　　3.4.1.2 设置配置管理库
　　对于在项目开发过程中配置管理库的配置情况，各配置管理库相互之间的关联关系如图 3-10 所示：
　　1、开发库的管理
　　SCM 负责项目开发库的管理活动，包括：
　　1）SCM 对成员分配开发库的访问权限；
&&& 2）SCM 导入配置项到开发库；
&&& 3）项目组成员对配置项进行检出，检入和修改操作；
&&& 4）该配置项必须经过评审，然后提交 SCCB 审批，申请纳入基线库；若评审未通过，则继续对该配置项的修改；经评审的文档可以进入基线库，经评审的代码则首先纳入测试库；
&&& 5）SCM 监控以上配置活动。
　　2、测试库的管理
　　SCM 负责项目测试库的管理活动，包括：
　　1）SCM 对成员分配测试库的访问权限；
&&& 2）SCM 导入配置项到测试库；
&&& 3）项目组成员对配置项进行检出，检入和修改操作；
&&& 4）该配置项经过测试、评审，评审通过后提交 SCCB 审批，申请纳入基线库；若评审未通过，则继续对该配置项的测试、修改；
&&& 5）SCM 监控以上配置活动。
　　3、基线库的管理
　　SCM 负责项目基线库的管理活动，包括：
　　1）通过 SCCB 审批的配置项形成基线后，由 SCM 纳入基线库；
&&& 2）代码在确认测试前纳入基线库管理；
&&& 3）对基线库中配置项的修改必须得到 SCCB 审批通过后方可进行；
&&& 4）项目成果正式提交用户前，SCM 在 PM 的指导下从基线库中提取构成最终产品的配置项，建立产品库；
&&& 5）SCM 对以上的配置活动进行监控。对于时间跨度较长的项目，则要求 SCM 定期向项目归档管理员提交纳入基线库的配置项
　　3.4.1.3 发布过程控制
　　发布是指将软件项目开发活动所产生的最终成果，对外部客户予以公布和递交的活动[27]。发布可以是同一项目中的各个独立的软件产品的发布，如对公系统、清算系统；也可以是不同时期发布同一软件产品的不同版本，如增量模型中不同 Release 版本的发布活动。
　　1、发布相关的角色及职责。
　　A 公司对发布相关人员的角色的职责做了如下规定：
　　1）发布人：提供可用于发布的软件产品的负责人；
&&& 2）项目负责人：指导 SCM 完成发布，并对发布活动负责；
&&& 3）SCM：按照《配置管理计划》中对发布计划的指引，并由项目负责人指导，从基线库中提取构成最终产品的配置项，并纳入产品库。编写《软件发布通知》。检查成果并发给最终客户；对发布产品中的配置项完善性以产品一致性负责；
&&& 4）SCCB：审批将配置项从基线库进入产品库的活动；
&&& 5）QA： 与 SCM 及技术负责人等进行基线审计，共同完成《配置审计报告》。
　　2、发布流程
&&& 1）项目负责人根据发布计划，并结合实际的开发进度、测试结果、评审结果等同意本次发布；
&&& 2）发布人遵照发布计划从基线库里提取用于发布的各配置项；
&&& 3）SCM 与 QA 及技术负责人等进行基线审计，共同完成《配置审计报告》；
&&& 4）基线审计通过后，SCM 编写《软件发布通知》并提交 SCCB 进行审批；
&&& 5）《软件发布通知》经 SCCB 审批通过后，SCM 将通过审计的软件产品纳入产品库；
&&& 6）SCM 准备发布介质，进行介质测试检查；
&&& 7）发布人将软件产品及相关文档移交给接收人；
&&& 8）QA 监督整个过程的执行。
　　3.4.1.4 备份
　　配置管理库的备份：备份人按《配置管理计划》中的备份周期、备份内容的要求进行定期备份，同时填写《配置管理库备份记录》。
　　3.4.2 变更控制管理
　　所谓变更控制，就是因为范围或者需求做了新增或者改变，要对原系统作出添加或者调整的动作[28]；或者软件项目在应用中出现缺陷，需要修复。变更控制的目的是对变更进行管理。
　　A 公司根据变更对象所在的阶段，分为六种变更类型，分别是计划变更、需求变更、概要设计变更、详细设计变更、代码变更、其他变更。而根据变更的严重程度，又划分为四级，而起对应的变更处理流程可以由不同级别的 SCCB 审批进行。
　　严重 (Critical)：可能导致项目停顿，需上报项目控制主管或 SCCB；
&&& 主要 (Major)：可能影响项目的实施计划，需上报项目负责人；
&&& 次要 (Minor)：不会影响项目的实施，由项目组成员协商解决；
&&& 轻微 (Cosmetic)：由项目组成员自己解决。
　　3.4.2.1 变更流程
　　1、变更申请
　　1）由变更申请人提出变更请求，填写《变更处理记录表》，提交变更负责人；2）变更负责人组织分析变更可能影响的范围（如合同、经费、开发进度等），并完成《变更影响分析报告》；3）变更负责人对变更请求进行确认后，向 SCCB 提交变更申请；4）若变更负责人不同意变更，则将《变更处理记录表》归档，变更流程结束。
　　2、变更审批
　　1）变更负责人将《变更处理记录表》提交给 SCCB 审批；2）SCCB 根据变更分类、影响范围及紧急程度，按权限审批变更申请。(如对于计划相关的变更由项目控制主管审批，设计、构建相关的变更由项目负责人审批)；3）如若变更申请被审批通过，则进入更改执行活动；4）若审批没有通过，则由变更负责人将《变更处理记录表》归档，变更流程结束；5）若变更紧急，变更负责人可自己审批变更申请，立即组织进行变更活动。
　　3、更改执行
　　1）一旦变更请求经审批通过，变更负责人应分别指定更改执行人和更改验证人。
　　2）更改执行人依据《变更处理记录表》的要求进行变更，并填写《变更处理记录表》中更改部分的内容。对代码的更改需加注释以便追溯。
　　4、更改验证
　　1）更改完成后，更改验证人应对更改后的配置项及可能受影响的配置项进行验证确认；2）验证手段：对代码的更改必须进行回归测试，对重要文档的更改可能需要进行评审；3）更改验证人需填写《变更处理记录表》中验证部分的内容，确认更改生效。
　　5、SCCB 审批
　　变更验证通过后，必须经过 SCCB 审批同意后方可纳入基线库。对于变更紧急、变更负责人自行审批进行变更的情况，SCCB 要重点审批。
　　6、基线库的更新
　　SCCB 审批通过后，SCM 将变更后的配置项纳入基线库，并重新标识以区别于其原来状态。对变更的配置项，不得随意销毁其变更前的历史状态信息，以便追溯。
　　7、变更通知
　　SCM 完成基线库的更新后，发布《变更通知》，将变更信息及时通知给项目组成员及其他相关部门、人员。
　　3.4.2.2 变更跟踪
　　对于项目实施过程中发生的变更，项目负责人应将其记录在《基线计划及跟踪表》之&变更记录&中进行跟踪直至其关闭。
　　3.4.2.3 变更统计和分析
　　在项目结项时，项目负责人应对项目实施过程中所发生的变更进行统计与分析，并在《项目总结报告》中对变更进行总结。
　　3.4.3 基线完整性
　　A 公司中，QA 负责生成、保存和发布基线，包括：
　　根据 QPPO 和中间目标识别子过程需建立基线的属性
&&& 识别影响建立基线的属性的因素，并按因素的特性定义分档范围
&&& 抽取影响基线的子过程属性、因素按 Option 分档并按项目开始时间升序排序
&&& 将已经分档和排序的子过程属性历史数据用 mintab 判稳，详见-《统计分析工具的使用指南》中的 CP 值的判定，如果 CP 值满足现在组织级要求就生成基线，否则继续识别此子过程的其他属性继续判稳
&&& &第一版基线生成后保存并发布；维护产生的基线保存后，先对新旧版本进行能力基线分析再发布，分析方法详见--基线和模型维护流程的流程描述。
　　3.5 建立度量与分析机制
　　A 公司为规范和控制公司测量与分析过程与活动，支持管理信息、技术、项目或过程实施的需要，对软件开发生命周期中的质量、成本、进度等有关数据以及过程改进中的问题、进度等数据进行测量收集，以便作进一步的分析，为同类项目提供实施参考，为公司持续改进提供依据，以便达到过程持续改进的目的。
　　3.5.1 数据采集
　　A 公司质量体系相关文件规定了项目、过程改进、培训、供方等数据采集的方法和责任人，如项目数据由项目负责人负责组织收集，过程改进数据由公司 SEPG 负责组织收集，培训由培训管理员负责组织收集，其他由相关责任方负责组织收集。
　　对项目而言，测量与分析贯穿于软件开发的整个生命周期[30]，根据质量体系文件项目实施过程相关指导书（如《项目计划与跟踪指导》、《需求管理指导》、《测试指导》、《结项指导》等）及文档模版（如项目总体计划、阶段计划、阶段报告、项目总结报告、项目跟踪总表、项目分布表等）的规定，在项目实施过程各阶段应收集的测量数据如表 3-1：
　　对公司管理及过程改进而言，根据质量体系相关文件（如《培训管理程序》、《核心过程管理程序》、《持续改进程序》等）的有关规定，应收集的测量数据如表 3-2：
　　3.5.2 数据存储
　　1、收集数据和文档：PDDB 管理员根据《PDDB 特征数据清单》、《PDDB 文档入库清单》、《项目阶段管理统计表》、《周管理统计表》以及各计划与跟踪表的要求，收集所需的数据和文档资料。
　　2、提交 SEPG：PDDB 管理员将收集的数据和文档提交 SEPG 审计。
　　3、SEPG 审计：SEPG 对 PDDB 管理员收集的数据和文档进行审计，以保证数据和文档的有效性、正确性和典型性。如果 SEPG 对审计的内容有质疑，将要求 PDDB 管理员重新收集整理数据和文档后，再提交审计，直到审计通过为止。
　　4、数据和文档入库：PDDB 管理员将 SEPG 审计并确认的数据和文档转入 PDDB并且核对，确保入库数据和文档与项目组提供的一致性。
　　3.5.3 数据分析
　　依据质量体系相关文件规定，在项目阶段和结项时对项目数据进行统计和分析，并形成《项目阶段报告》、《项目总结报告》、《项目跟踪总表》及《项目分布表》等文档，在文档中以直观图等方式对采集的数据进行了分析；其他公司级的数据一般在年中和年底进行统计和分析，并出具相关报告，以供管理、改进和决策。
　　一般可采用的分析工具方法有：
　　1、直观显示和其他展示技术（例如，圆饼式图表、直方图、柱形图、雷达图、直线图、散列图或表格等）；2、适宜的描述性统计方式（例如，算术平均值、中位值或模等），一般做法是：检查规定的度量值的分布（如集中趋势、变化程度、非典型的离群值等），检查度量值之间的关系（如缺陷与生存周期状态或产品构件的对照关系等），按时间分析变更情况等；3、如果不可能或不必要检查每个数据元素，可采用抽样统计方式。
　　3.5.4 数据统计分析结果通告
　　按体系文件相关规定，测量分析的责任人应与相关人员共同讨论度量结果，以适当的形式向所有相关人员通报测量和分析活动的结果，以支持决策和采取纠正措施，并总结测量分析过程实施的经验教训，以改进测量分析过程[32]。
　　定期将测量分析报告和过程改进意见上报主管部门审批，并通报相关其他部门，以便采取相应的措施：
　　1、项目的测量分析报告以项目总结报告和项目分布表等形式在项目结项时报项目控制主管和项目委员会，审核通过后入 PDDB 库保存管理；
&&& 2、培训的测量分析报告每半年进行一次总结，报总经理办公会和相关部门，以便进行后半年的培训计划地制定；
&&& 3、过程改进的测量分析报告每季度以《过程改进问题跟踪表》形式报 PST 和相关人员；
&&& 4、顾客满意度调查统计分析报告每半年由市场部负责编制并报总经理办公会和相关部门；
&&& 5、其他统计分析报告按相关规定定期向主管部门和相关部门报送。
　　3.6 本章小结
　　本章详细介绍 A 公司基于 CMMI 的质量管理的实施细节，包括组织架构调整，同时根据 CMMI3 中有关质量管理的过程域的实施指导，完善过程与产品的质量保证，完善配置管理，建立和完善度量与分析机制。
相关内容推荐
相近论文：
上一篇： 下一篇：}