首页 » 软件开发 » 基于CMMI的软件测试:过程改进与实践(过程测试裁剪软件项目),cmmi软件过程改进与评估。

基于CMMI的软件测试:过程改进与实践(过程测试裁剪软件项目),cmmi软件过程改进与评估。

雨夜梧桐 2024-07-24 03:26:45 软件开发 0

扫一扫用手机浏览

文章目录 [+]

CL1,已执行级:过程通过转换可识别的输入工作产品,产生可识别的输出工作产品。
能实现过程域的特定目标。

CL2,已管理级:过程作为已管理的过程被制度化。

CL3,已定义级:过程作为已定义的过程被制度化。

基于CMMI的软件测试:过程改进与实践(过程测试裁剪软件项目) 基于CMMI的软件测试:过程改进与实践(过程测试裁剪软件项目) 软件开发
(图片来自网络侵删)

CL4,量化管理级:过程作为量化管理的过程被制度化。

CL5,优化级:过程作为优化的过程被制度化。

基于CMMI的软件测试:过程改进与实践(过程测试裁剪软件项目) 基于CMMI的软件测试:过程改进与实践(过程测试裁剪软件项目) 软件开发
(图片来自网络侵删)

CMMI成熟度等级及与测试相关的过程域(截取标红部分为测试相关)

1.初始级

改进方向

建立项目管理过程,实施规范化管理,保障项目的承诺。
进行需求管理,建立客户与软件项目之间的共同理解,使项目真正反映客户的要求。
建立各种软件项目计划。
如:软件开发计划、配置管理计划、风险管理计划等。
开展软件质量保证活动

2.已管理级

过程与产品质量保证

过程与产品质量保证(Process and Product Quality Assurance)为项目管理者提供项目过程和相关产品的适当的可见性,从而为交付高质量的产品和服务提供支持。
在该过程域中,产品质量评估的客观性对项目的成功是至关重要的,可以通过设立独立的质量保证组或应用一些标准来达到这种客观性。
质量保证工作应尽早开始,在项目初期就应制定相应的计划、标准和规程

3. 已定义级

需求开发(Requirement Development):生成并分析客户、产品和产品组件的需求。
技术解决方案(Technical Solution):开发、设计和实现需求的解决方案。
产品集成(Product Integration):把产品组件组装成产品,保证产品正常工作,并把产品交付给用户。
验证(Verification):保证工作产品满足它们的指定需求。
确认(Validation):把产品或产品组件放到目标环境中时,它们可完成预期的用途。
组织过程焦点(Organizational Process Focus):在彻底理解一个组织当前过程和过程资产的弱点和优势的基础上,计划、实施和部署组织的过程改进活动

以上三个级别中,均提到软件质量保证、软件的验证及确认,均需要进行测试介入以保证软件质量,以达到满足软件能力要求。
验证,即确认初期软件需求;确认,即是在开发结束后对软件产品进行评估以确定其是否满足软件需求规格的要求。
基于CMMI的软件测试,就涵盖了这两方面的工作。
基于CMMI的软件测试过程其优点在于,将测试分为验证和确认两部分,涵盖了软件产品的整个生命周期,从工程过程的角度确保了软件产品的质量。

CMMI模型中测试角色的职责

软件测试组长权责:

制定测试计划安排测试工作提交测试报告控制产品质量

软件测试人员权责:

开发测试用例测试执行发现产品的问题,并跟踪其解决状况基于CMMI的软件测试如何实施?

很多通过CMMI3认证的企业都会成立一个组织,即PMO(项目管理办公室)。
由PMO来推行CMMI体系在企业中的施行。
如果没有这样的组织,测试负责人也可以自己研究CMMI,然后根据企业的实际情况进行裁剪,制定不同项目阶段需要出具的文档成果,以及使用的模板。

QA是quality assurance的缩写,也就是质量保证的意思

国内来说,各个组织对于QA和软件测试的定义是不同的

有的组织,QA = 软件测试。
有的组织,QA > 软件测试,除了测试以外还负责流程改进的工作。
有的组织,既有QA,也有软件测试。
QA负责流程,产品等方面的工作,软件测试则仅仅负责测试方面的工作。
CMMI过程裁剪(测试过程)

1.项目开始的估算是需要的,但可以简化估算的过程和文档,例如各种估算标准和报告。
测试计划可以简化,不必给出详细的项目过程计划,因为敏捷开发的项目过程几乎是没法计划的。

2.里程碑会议文档可以裁剪,项目监督控制文档可以裁剪。
但项目周报需要。

3.集成项目管理文档可以裁剪。
因为很多项目coding完成后,基本上也就完成了,集成的观念在很多项目过程中都被忽略,基本上很少有集成管理,集成测试的具体实施,结合项目报告需要。
可以作为经验总结放到公司的配置管理服务器上作为以后对该项目查询问题的一个文件材料。

4.基线建立文档可以裁剪,配置审计等相关配置管理文档可以裁剪。

5.风险管理相关文档可以裁剪为一个风险管理一览表文档进行跟踪管理。

6.度量部分可以裁剪,因为度量项需要根据项目开发过程中的各种文档和人员来搜集度量的数据,没有了文档度量数据可靠性没有可信度,所以可以裁剪。

7.决策分析和解决方案可以裁剪。

8.需求变更相关文档不能裁剪,并且应该加大需求变更管理力度。

9.需求管理相关文档可以裁剪,例如需求开发指南,需求开发文件等。

10.测试阶段,测试计划可以裁剪为一个简单的文档,测试用例不要裁剪,因为如果项目都是一个人做测试可以考虑将测试用例裁剪,改为测试操作过程记录。
但如果多个人参与,同一个人的测试操作记录重用性很差,所以多人参与测试的项目测试用例最好不要裁剪,Bug跟踪管理可以用Bug管理工具实现,测试报告不可以裁剪。

标签:

相关文章