行业资讯
分享专栏文章，携手打造高质量产品
当前位置：首页 > 行业资讯 > 【易迪森分享】基于CMMI的软件测试
【易迪森分享】基于CMMI的软件测试
发布时间：2022-06-30 浏览数：0



近几年来，软件行业受到市场疯狂追逐，地方政府以及各路资金蜂拥而至，大家都想将自身产业互联网化。而直到软件开发行业内出现越来越多的问题后，很多公司才开始冷静下来，开始审视在企业互联网、移动互联的过程中，究竟应该如何正确地对企业内容进行机器语言的设计，进行软件系统的开发。如何向规范的、有序的软件过程进行改进，是一大难题，到底该怎么做，CMMI给出了答案。本文主要针对CMMI过程管理中测试介入相关过程进行阐述。


一、初步认识CMMI：


CMMI( Capability Maturity Model Integration) 即能力成熟度模型集成，由CMM (Capability Maturity Model) 发展而来，它最早是应用于软件业的一个过程改进模型，为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。后来随着应用的推广和模型本身的发展，CMMI 逐渐演化成为一个被广泛应用的综合性过程改进模型。
  • CMMI指明该做什么，但没有指明如何做，它不是方法论，没有给出特定应用领域内的专门技术。
  • CMMI是从软件过程角度定义了成熟的软件过程的实践活动，但它并没有涉及到软件工程的所有方面，对于成熟的软件组织而言，人的因素和技术的因素也同样重要。
image

CMMI的成熟度等级；图片引自CSDN


二、CMMI能力等级：


能力等级（Capability Level, CL）是指在一个单独的过程域中执行的良好程度。CMMI包括6个能力等级：
CL0，不完整级：过程域的一个或多个目标没有被满足。
CL1，已执行级：过程通过转换可识别的输入工作产品，产生可识别的输出工作产品。能实现过程域的特定目标。
CL2，已管理级：过程作为已管理的过程被制度化。
CL3，已定义级：过程作为已定义的过程被制度化。
CL4，量化管理级：过程作为量化管理的过程被制度化。
CL5，优化级：过程作为优化的过程被制度化。









image




三、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，然后根据企业的实际情况进行裁剪，制定不同项目阶段需要出具的文档成果，以及使用的模板。
image
注：QA是quality assurance的缩写，也就是质量保证的意思。软件测试是software testing，主要指的是软件方面的测试。
国内来说，各个组织对于QA和软件测试的定义是不同的。
  • 有的组织，QA = 软件测试。
  • 有的组织，QA > 软件测试，除了测试以外还负责流程改进的工作。
  • 有的组织，既有QA，也有软件测试。QA负责流程，产品等方面的工作，软件测试则仅仅负责测试方面的工作。


六、CMMI过程裁剪：


1.项目开始的估算是需要的，但可以简化估算的过程和文档，例如各种估算标准和报告。测试计划可以简化，不必给出详细的项目过程计划，因为敏捷开发的项目过程几乎是没法计划的。
2.里程碑会议文档可以裁剪，项目监督控制文档可以裁剪。但项目周报需要。
3.集成项目管理文档可以裁剪。因为很多项目coding完成后，基本上也就完成了，集成的观念在很多项目过程中都被忽略，基本上很少有集成管理，集成测试的具体实施，结合项目报告需要。可以作为经验总结放到公司的配置管理服务器上作为以后对该项目查询问题的一个文件材料。
4.基线建立文档可以裁剪，配置审计等相关配置管理文档可以裁剪。
5.风险管理相关文档可以裁剪为一个风险管理一览表文档进行跟踪管理。
6.度量部分可以裁剪，因为度量项需要根据项目开发过程中的各种文档和人员来搜集度量的数据，没有了文档度量数据可靠性没有可信度，所以可以裁剪。
7.决策分析和解决方案可以裁剪。
8.需求变更相关文档不能裁剪，并且应该加大需求变更管理力度。 
9.需求管理相关文档可以裁剪，例如需求开发指南，需求开发文件等。 
10.测试阶段，测试计划可以裁剪为一个简单的文档，测试用例不要裁剪，因为如果项目都是一个人做测试可以考虑将测试用例裁剪，改为测试操作过程记录。但如果多个人参与，同一个人的测试操作记录重用性很差，所以多人参与测试的项目测试用例最好不要裁剪，Bug跟踪管理可以用Bug管理工具实现，测试报告不可以裁剪。
信息来源：易迪森技术部



上一篇：为什么“618”购物节持续时间越来越长了？
下一篇：五一将至，你“抢”到火车票了吗？
热门资讯