解读AFP和AEP

        随着软件行业的不断发展,IT管理者都试图解决一个问题,就是系统质量到底如何?面对这个问题,工业界和学术界都进行了大量研究,是否通过建立模型解决这个问题。最早的提出的是千行代码缺陷率,也就是根据一千行代码中有多少bug数,计算这个值。CMM也给出了5个级别对应的千行代码缺陷率,CMM1级为11.95‰,CMM5级的要达到0.32‰,CMM5级比CMM1级软件的质量要提高40倍左右。这种评价方法只是相对比较,对于一千行代码中到底有多少缺陷,无法证明。另外,由于大多数情况下采用黑盒测试方法,往往计算代码量有一定难度,例如,代码中引用的第三库或开源构件是否要计算,对于发现的各种缺陷,哪些属于代码引起的缺陷,黑盒测试人员很难定位。还有一个指标度量软件测试效果的公式,被业界认可,就是缺陷移除率/缺陷消除率,通过测试期间发现的缺陷数占比软件生命周期中被发现的缺陷比重来计算,这个计算难度在于软件生命周期中的缺陷数据采集,是一个持续和不断变化的过程,需要成熟组织有一套流程和规范,才可能实现该度量。

   

       是否通过构成软件的源代码来度量软件质量呢?CISQ(https://www.it-cisq.org/standards/)所制订的代码质量度量标准为检测和量化软件代码质量提供了依据。在全球软件开发、软件工程领域得到广泛应用,其标准成为业界认可的主要参考标准。

       CISQ的全称是Consortium for IT Software Quality,信息和软件质量联盟(CISQ™),是一个行业领导小组,负责制定从源代码自动测量软件大小和结构质量的国际标准。

        CISQ由对象管理组织® (Object Management Group®, OMG®)和卡耐基梅隆大学的软件工程研究院(Software Engineering Institute, SEI)共同组建。由CISQ设立的测量标准通常会经过OMG核准之后,才会对外发布作为行业标准。CISQ编写的标准使组织能够开发或获取软件密集型系统,以衡量软件对业务的操作风险,并估算所有权成本。

 

       CISQ发布了两个标准:Automated Function Points (简称AFP)和Automated Enhancement Points(简称AEP)。用来度量软件的安全性、可靠性、性能效率和可维护性。也就是六大质量特性中的3-4个可以通过源代码的质量可以度量。因为在国际国内标准的六大质量特性中,安全性被归并到功能性中,所以还不能称之为4大质量特性。但是CISQ已经把把安全性和兼容性提升为两大质量特性,形成了八大质量属性。国内标准是否变更,指日可待。

 

        在AFP中,可靠性被用29类缺陷类型所定义,用来衡量软件代码中包含中断、意外的非预期行为、不稳定、数据损坏、长时间恢复等问题。安全性用22类缺陷类型所定义,包括用来度量代码中的一个弱点多大程度上被利用,从而获得对系统的未授权访问,从而窃取数据、造成损害或其他恶意行为。例如:不正确的路径遍历、OS命令注入、XSS攻击、SQL注入、缓冲区溢出等比较严重的缺陷。性能效率用15类缺陷类型来定义,用来度量软件中包含多少脆弱点可能降低系统性能。例如:静态初始化、不可变的文本数据、复杂的读写存取等等。对于可维护性用20个脆弱点缺陷类型来定义,用于度量软件难以理解、难以维护的程度。例如跳转到switch语句之外,继承于过多的类、过度耦合等等。当然要度量,还需要对于代码功能点进行度量,不只是简单的使用代码行数,而是通过外输输入、外部输出和外部查询、内部逻辑文件、外部接口文件等综合度量软件产品的大小。该计算需要通过算法引擎扫描代码中的相应特征值获取。

 

        如果说AFP解决了代码质量度量问题,则AEP则是解决了由于需求变更导致的代码变更带来的代码质量变化。引入了工作复杂性(EC)、复杂性因子(CF)两个概念。工作复杂性是通过工件大小、注释数、算法复杂性、数据访问复杂性以及耦合度5个软件度量综合评估软件的环境复杂性。复杂性因子则是对计算对象,也就是功能点/工件变更的复杂性进行加权处理的计算因子。

        工件是一个纳入功能点计算的计算对象,主要是代码中的方法/函数。一个工件不属于另一个工件,避免重复计算。预处理指令不被视为工件。主要涉及到这些工件的添加、删除和修改。为了计算工作复杂性(EC),要考虑扇入、代码行数、注释行数,SQL涉及表数、子查询语句、update语句、group by语句,select语句返回的列数等等。对于每次变更,都要明确检索出AFP变化范围。

        AEP和AFP配合,实现了对软件代码质量的跟踪检测,从一个基准代码的质量多次迭代变化的代码质量变化过程,通过同一个口径去计算,在一定程度上反映了代码质量情况。关键是这种方法能够实现自动化,不需要长期跟踪软件测试情况,通过开发人员代码的提交、构建后能就评估代码质量,也符合当前日益流行的Devops理念,在持续集成和持续构建之间评估代码质量,给出量化依据。使管理者掌握软件代码质量的变化情况,进行风险感知和预警,把握变化。

 

       目前,市场上已经有商业工具可以支持。未来几个月,国产第一款用来评估软件代码质量的工具产品就可能面世,让我们期待国产软件的精彩。

 

(完)

发布了309 篇原创文章 · 获赞 31 · 访问量 6万+

猜你喜欢

转载自blog.csdn.net/manok/article/details/99689567