近年来，随着国内金融市场对软件产品需求的日益剧增，金融企业对软件产品质量要求越来越高，质量保障工作被寄予了更多的关注和支持，软件测试的标准化、体系化建设受到行业内越来越多的重视。目前，金融行业的许多业务已经完成了从线下实体交易到线上交易的转变，利用在线交易平台完成了包括互联网证券登记结算、信息化证券交易等的功能，并朝着金融科技、智慧券商的方向发展。随着金融供给侧结构性改革的发展，及同业服务重心的下沉及竞争的加剧，“短、平、 快”的业务迭代模式逐步成为主流，对科技的研发效能提出了较高的要求，有效提高软件测试效率、保障产品质量，成为当前产品研发的重点工作。那么怎么提高软件测试质量？这是本文探讨的出发点。
借鉴“100％以缺陷为核心”的开发管理经验，缺陷管理是改进软件过程最好的切入点，软件企业的开发过程可以100％由缺陷管理来驱动。
图1 缺陷管理驱动的软件开发环境
第一阶段：缺陷数据收集
针对软件缺陷度量需要对在软件生命周期各个阶段中按照缺陷产生的所在过程来分类。作为缺陷度量基础的缺陷分类方法基于软件过程的原则，提供了唯一的、非冗余的属性定义的标准，提供了度量和分析的基础。在缺陷管理过程中与本次度量有关的相关因素和它们的值，如表1和表2所示。
表1 缺陷相关因素及对应值
注意：此处缺陷类型是以该缺陷对系统整体造成的影响，或与需求说明不相符合的程度作为划分依据，优先级表示该缺陷需要修改的紧迫程度，它与缺陷类型有一对多的关系。总体上优先级从类型A开始逐渐降低，例如A1和B1都属于优先级为1的级别。总之，缺陷类型和缺陷优先级定义的出发点不同，前者是对缺陷的划分，后者是给缺陷一个定位，以提醒相关的修改人员及时修改。
表2 缺陷分类编号及说明
第二阶段：数据分析与改进
进行完数据收集，对数据结果进行归类分析和度量运算。根据项目经验和实际情况，本文总结了如下缺陷度量指标对数据进行分析：
开发人员熟练程度分析
为了方便而快捷地获得开发人员的熟练程度，需要利用基本度量的以下信息：开发时间周期T，开发的代码行数L ，某开发人员在不同时间开发不同功能块(按照详细设计中的功能点划分)时的缺陷数。所有这些信息都来自度量数据库。首先计算开发人员的缺陷率DBR (Developer Bug Ratio)
DBR =该阶段缺陷总数/某人该阶段开发代码行数L ①
这里用某一时期某开发人员缺陷总个数与该阶段代码行数的比值来表示该开发人员的缺陷率。这只是一个粗略的计算，不能充分反映开发人员的熟练程度，为了充分反映开发人员的熟练程度，对不同开发人员的缺陷级别(defect Level)进行估算。
定义1 缺陷类型权值向量W，其中各元素WX 代表缺陷类型X 对应的权值：
W = (WA1 ， WA2 ， ⋯，WA7 ， WB 1 ， ⋯， WB4 ，WC1 ， ⋯，WC5 ， WD1 ， ⋯，WD6 ，W E1 ，W E2 ) = (5.6， 5.5， ⋯， 5， 4.3， ⋯， 4，3.4， ⋯， 3， 2.5， ⋯，2， 6.1， 6.2) ②
在向量W 中，作为最后一个缺陷类型E，虽然它不是产生于程序员本身，而是由于系统在前期设计的不足或者存在的错误导致，但这些缺陷如果在程序开发的后期才被发现，那么修改的成本将会很高，因此将它的权值设为最高。
定义2 缺陷数量向量N，代表某一编码人员被检查出的所有类型缺陷数量，按照缺陷类型依次排列，其中每个元素的值NX对应发现该类型X缺陷的个数，值为0表示未发现该类型的缺陷。N = (NA1 ， NA2 ， ⋯，NA7 ， NB1 ， ⋯， NB4 ， NC1 ， ⋯， NC5 ， ND1 ， ⋯，ND6 ， N E1 ，NE2 )
定义3 缺陷数量加权值，代表某一编码人员被检查出的所有类型缺陷数量的加权值。PersonA_BL = [N，W ] ③
向量N与W 的内积表示该开发人员的不同类型缺陷数(N中元素值)与对应权值(W 中元素值)的乘积相加。这是从质量的角度去衡量该人员的编码质量，可以作为该开发人员熟练程度的标志，式③显然比式①更具有说服力(值越小熟练程度越高) 。
例如，某一编码人员被检查出的缺陷数量向量为
N = (2， 0， ⋯， 1，3， ⋯， 0， 1， ⋯， 4， 2， ⋯， 0， 0， 0)
其缺陷数量的加权值为：
PersonA_BL = [N，W ] = 2 ×5. 6 + 5 + 3 ×4. 3 + 4 + 4 ×3 + 2 ×2.5 = 50.1
测试人员的熟练程度分析
以测试人员的测试效率( Tester Efficiency， TE)作为测试人员的熟练程度的标志。例如，某一测试人员检查出的缺陷数量向量为
N = (5， 3， ⋯， 3，6， ⋯， 3， 6， ⋯， 4， 2， ⋯， 3， 1， 0)
PersonB_TE = [N，W ] /T = 146. 8/2 = 73. 4 ④向量N与W 的内积表示该测试人员测试出的不同缺陷类型数(N中元素值)与对应权值(W 中元素值)的乘积之和，再除以本次测试的周期，作为测试人员的熟练程度。这里抛开单纯从缺陷个数的角度去衡量测试人员熟练程度的不足，而从测试效率的角度来进行分析。从式④中可以看到，影响测试人员熟练程度的因素有两个：（1）测试出不同类型缺陷中权值大的缺陷数所占比重；（2）本次测试所经历周期的长短，最终的结果与（1）呈正比，与（2）呈反比。显然如果测试出的缺陷中权值大的部分占的比重大，同时经历的周期比原来的短，则最终PersonB_TE的值会增大，反之将会减小，从而可以比较准确地反映该测试人员的熟练程度(值越大该测试人员的熟练程度越高) 。
项目进展状况分析
为了分析项目的进展情况，根据基本度量数据，以星期为单位绘制某一阶段缺陷状态跟踪图。在图2中显示了分别处于新发现、正在修改、待确认、修改完毕四种状态下A、B类缺陷的跟踪曲线。它们分别是：(1)每个报告区间新发现的该类缺陷数；(2)每个报告区间处于正在修改状态的该类缺陷数；(3)每个报告区间等待确认修改结果的该类缺陷数；(4)每个报告区间已经修改完毕的该类缺陷数。总体上来说：四条曲线之间没有确定的线性关系，但是它们之间有密切的关系，随着项目开发的延续，它们之间表现出一种迭代关联的关系。任何阶段修改完毕的缺陷数小于或等于前一阶段待确认的缺陷数；当某阶段修改完毕的缺陷数大于新发现的缺陷数同时待确认的缺陷数保持基本稳定时，图中相应的处于正在修改状态的缺陷曲线呈下降趋势，反之将会呈上升趋势；而处于修改状态的缺陷代表目前剩余的工作量，同时它的走势可以作为产品成熟程度的标志，当处于修改状态的缺陷呈上升趋势时，说明产品质量问题严重，将导致项目后期预算增加、工作量增大，并且项目可能延期。图中显示近期缺陷修改完成的比率相对稳定，同时新发现的该类缺陷数量处于一种相对收缩的趋势，项目进展正常。这里只列出A、B类缺陷是因为少量低级别的缺陷是可以允许的，它们对项目实施的进度不会产生太大的影响，而A、B类缺陷是必须考虑的，在实际项目中并不是所有的缺陷都必须得到修改。
图2 A、B类缺陷状态分析
当在分析这些度量数据时，应该把它们和项目的进度结合起来考虑，因为在项目实施的过程中，如果测试工作进展缓慢，或因为赶进度而忽略某些测试步骤同样会导致处于修改状态的缺陷处于明显的下降的趋势，也就是说导致图2现象的原因不是唯一的，所以在实际中应该予以区分。
代码质量分析
为了评估代码的质量，从代码走查阶段的基本度量数据中导出的缺陷权值密度Bugs Weight/KSLOC ( Kilo Source Lines of Code)——模块中每千行代码的缺陷权值作为导出度量（缺陷权值比缺陷数更有说服力）。
Bugs Weight=[N，W]
例如，某千行代码中发现A4缺陷2个，B1缺陷4个，B2缺陷1个，B3缺陷3，C1缺陷1个，那么该段代码的缺陷权值密度为：
Bugs Weight=5.3×2+4.3×4+4.2×1+4.1×3+3.4×1=47.7
绘制到图3作为指示器，根据历史数据，假定最高阈值为100和最低阈值20 。在图3中Mod6的缺陷率已超出最高阈值线，对该模块的代码需要作进一步检查分析，找出异常的原因。因为缺陷率的大小和测试缺陷所用的方法有关，较低的缺陷率可能源自低效的检查过程，比如没有做好检查的前期准备；有时较高的缺陷率可能是因为该阶段投入检查的资源比较多，如额外的时间投入，或者使用了更为先进的测试工具。所以在对代码检查的同时对该阶段的测试方法同样应该进行检查，最后才能做出准确的判断。
图3 缺陷权值密度分析
通过跟踪设计和代码走查阶段的缺陷数和缺陷类型，可以尽可能早地获得有关产品质量的信息，以控制图的形式监控缺陷排除过程中项目的稳定性。当超出预定的阈值范围时，必须及时展开调查，并且提出可行的改进方案。总之，项目进展是否正常，主要看该阶段开发人员的效率、测试人员的效率与历史数据的偏差是否在预期的阈值区间内。同样如果缺陷的加权走势趋向开放，而项目已经接近交付期限，说明项目开发的某些环节存在严重问题，需要及时调整相关的人员或者检查前期的设计和开发是否存在较大的缺陷。
缺陷增长模型分析
接下来将使用缺陷增长模型作进一步的分析。这时候可以通过增加人手解决这个问题，但是问题是为什么要这么做，到底如何做出调整措施以保证项目进度安排及减少产品风险，需要从数据中得到更多信息。因此主要分析三类缺陷即A、B、C类缺陷的增长曲线，如图4：
图表2 图4 A、B、C三类曲线的增长图
该图显示了很有层理的三类缺陷单独的增长曲线，观察图4A类和C类缺陷的增长势头慢慢变缓，而且这两类缺陷对应的曲线逐渐稳定，但是B类缺陷的增长曲线却没有稳定的预兆。A类缺陷曲线的延缓点大约在32天，C类缺陷曲线的延缓点大约在25天，但是B类缺陷曲线在45天延缓点还未出现在增长曲线上。根据图3-3显示，C类缺陷曲线所反应的软件代码质量比较稳定，并且这类缺陷比A类缺陷曲线稳定得更快些。另一方面，A类缺陷曲线大约在随后的一个星期内趋于稳定。但是，B类缺陷曲线并没有很快趋于稳定。从图4中分析A类、B类和C类缺陷的增长曲线，可以得出结论：产品暴露出某些设计方面的不足和大量接口方面的缺陷。因此项目经理仅仅加强当前测试和开发人力是不够的，这只对提高代码质量有用。B类接口缺陷曲线暴露问题最多，它的数目远远超过其它两类缺陷。为了着重解决产品这个方面的缺陷，项目经理不仅需要增加人手，而且需要改变技术方针并调整针对B类缺陷的测试策略。
例如加强接口设计、增加设计评审来减少该种缺陷的数量，以起到软件质量保证的目的。如果发现软件A类功能方面产生的问题比较多，那么就可以通过加强软件设计阶段中的审查活动来保证软件的质量。无论是某时刻的缺陷类型分布图还是某个开发阶段内的缺陷类型与增长曲线结合的分析图，都能为软件设计者、开发者、管理者提供决策方面的支持。
第三阶段：过程改进
对于软件开发过程而言，根据度量的分析报告，管理者基于度量数据做出决策。这些决策可能包括滚动计划，纠正活动，或不作改变就通过。对于软件维护阶段，管理者可以根据数据来分析产品的质量状况和开发人员的解决效率，提高产品的维护体系。
实施缺陷管理进行过程改进需要组织、资金和人员多方面的支持，否则会陷入“只进行分析，不进行改进”的误区，同时还应保证对过程改进活动进行监控和跟踪。本文的缺陷跟踪度量主要针对测试阶段，包括单元测试、集成测试和系统测试。测试作为项目开发的最后一环，错误、延时、疏忽等都可能在测试阶段表现出来，如何有序管理和分析各种问题对质量控制和过程改进非常重要。
声明：本文来自CAICT金融科技，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
