CN103793315A

CN103793315A - 监视和改善软件开发质量

Info

Publication number: CN103793315A
Application number: CN201210419814.XA
Authority: CN
Inventors: P.王; X.叶; L.赵; W.赵; C.周
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2012-10-29
Filing date: 2012-10-29
Publication date: 2014-05-14
Anticipated expiration: 2032-10-29
Also published as: CN103793315B; US20140123110A1

Abstract

此处描述用于监视和改善软件开发质量的系统和方法。根据本公开的一方面，监视与源代码有关的监视任务的发生。编译和测试源代码以产生测试结果。分析测试结果。测试结果分析包括用于评价源代码的质量的质量分析。

Description

监视和改善软件开发质量

技术领域

本公开一般涉及软件开发，更具体地，涉及监视和改善软件开发的质量。

背景技术

开发软件产品是冗长的、劳动密集的过程，通常涉及来自不同的开发者和测试者的贡献。开发者对源代码做出频繁地改动，而测试者匆忙地安装软件包、执行回归测试并发现程序错误（bug）或缺陷（defect）。当测试者执行回归测试时，开发者签入（check-in）对于源代码的更多的改动以引入更多的特征。这会产生恶性循环，在该恶性循环中开发了越来越多的特征，而同时通过对源代码的改动引入了更多的缺陷。在这过程期间，没有人真正地准确知道当前产品质量是什么，以及该产品是否足以发行。最后，由于时间的限制可能发行具有没有处理的许多隐蔽缺陷的软件产品。当软件质量下滑时，错过最后期限，并且损失投资回收。

在软件工业的许多企业致力于改善他们的产品供应的质量并保证他们的产品满足最高的可能标准的过程中，他们执行持续的软件质量保证协议。ISO 9001标准和能力成熟度模型集成(CMMI)模型两者都是行业中用于保证开发项目的质量的普遍指导。CMMI指定企业的软件开发过程中的五级的组织和成熟度，每个级别具有对于将要获得的CMMI认证必须满足的一系列不同的要求。

诸如CMMI的现有标准和指导通常仅提供一般目标。通常不提供关于获得那些目标的细节，而必须由遵循该标准的企业开发所述细节。一般不存在用于评价产品的质量和使质量趋势可视化的已知的有效方法。因此难以预测风险和进度。诸如产品负责人（product owners）、开发管理者和质量工程师之类的项目干系人（stake holders）不能获得关于整体产品质量状态的定期更新。

因此期望提供用于评价、监视和/或改善软件质量的工具。

发明内容

利用将在下文中变得清楚的这些和其它优点与特征，通过参照以下详细描述的说明书和所附权利要求以及附图，可以获得进一步信息。

附图说明

在附图中示出一些实施例。附图中相同的参考标号指示相同的部分。

图1是示出示范性的质量监视系统的框图；

图2示出示范性的签入任务；

图3示出示范性的构建（build）报告；

图4示出示范性的基于时间的监视任务；

图5示出自动测试的示范性方法；

图6示出示范性的总结报告；

图7示出示范性的基于时间段的仪表盘（dashboard）；

图8示出另一示范性的基于时间段的仪表盘；以及

图9示出再一示范性的基于时间段的仪表盘。

具体实施方式

在下面的描述中，为了说明，具体数目、材料和配置被阐述以便提供本框架和方法的彻底理解，并且以便满足法定撰写的描述、实现和优选模式的要求。然而，本领域技术人员清楚地是，可以在没有具体示范性细节的情况下实现给出的框架和方法。在其他情况中，省略或简化公知的特征以使给出的框架和方法的示范性实施方式的描述清楚，并且从而更好地解释给出的框架和方法。此外，为便于理解，将某些方法步骤描绘为单独的步骤；然而，这些单独描绘的步骤不应该被解释为必须依赖次序或者其执行必须分离。

此处描述一种对于监视和改善软件质量的框架。在一个实现中，本框架通过定期地监视软件开发和/或测试的质量来提供软件项目的整体状态或质量的定期更新。不是仅在特征在最终的构建包中就绪以后才花费巨大的努力来查找和报告缺陷，本框架而是通过可以在整个软件开发过程期间频繁地运行的一系列过程(例如，编译检查、代码测验、单元测试、功能测试、代码覆盖分析、性能测试等等)以获得软件项目的第一手的健康状态来监视整体质量。

可以定期地提供一系列总结报告以报告所述过程的结果。可替换地，或附加地，可以提供基于时间段的仪表盘以呈现项目的概括或总结。如果项目的质量指数降到预定阈值之下，则可以通知项目干系人采取合适的行动。例如，仪表盘可以指示红光以对质量方面的显著下降发信号，从而提醒项目干系人采取行动来调节开发过程并使得质量回到正轨。将在以后几节里更详细地讨论这些和其它示范性特征。

图1是示出实现此处描述的框架的示范性的质量监视系统100的框图。系统100可以包括一个或多个计算机系统，为了说明目的图1仅示出一个计算机系统。虽然利用一个计算机系统101示出环境，但是应当理解也可以采用多于一个计算机系统或服务器，诸如服务器池，以及除服务器以外的计算机。

更详细地转向计算机系统101，它可以包括中央处理单元(CPU)104、非临时计算机可读介质106、显示设备108、输入设备110和输入输出接口121。非临时计算机可读介质106可以存储机器可执行指令、数据和各种程序（诸如操作系统(未示出)）以及用于实现此处描述的技术的软件质量监视单元107，它们全部都可以由CPU104处理。因而，计算机系统101是通用计算机系统，当该通用计算机系统运行机器可执行指令时变为专用计算机系统。可替换地，此处描述的质量监视系统可以实现为经由操作系统运行的软件产品或应用的一部分。该应用可以集成到现有的软件应用中，诸如现有应用的附件（add-on）或插件（plug-in），或作为单独的应用。现有的软件应用可以是软件应用的套装。应当注意，在一些实现中，软件质量监视单元107可以整体或部分地由不同的计算机系统作为主机。从而，此处描述的技术可以本地发生在计算机系统101上，或者可以发生在其他计算机系统中并向计算机系统101报告。

每个计算机程序可以实现为高级面向过程或面向对象的编程语言来实现，或者如果需要可以以汇编或机器语言来实现。该语言可以是编译或解释语言。机器可执行指令并不旨在局限于的任一特定编程语言及其实现。将理解的是，各种编程语言及其编码可以用来实现此处包含的公开的教导。

非临时计算机可读介质106可以是任何形式的存储设备，例如，半导体存储器件，诸如可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)以及闪速存储器件；硬盘，诸如内部硬盘和可移动盘，磁光盘，以及光盘只读存储器(CD-ROM)。

计算机系统101可以包括输入设备110(例如，键盘或鼠标)和显示设备108(例如，监视器或屏幕)。显示设备108可以用来显示通过软件质量监视单元107生成的分析结果(例如，总结报告、仪表盘等等)。此外，计算机系统101还可以包括用于使用通信链路(例如，电话线、无线网络链路、有线网络链路或电缆网)与网络交换数据的诸如通信卡或设备(例如，调制解调器和/或网络适配器)之类的其他设备，以及其他支持电路(例如，高速缓存、电源、时钟电路、通信总线等等）。此外，可以通过专用集成电路补充上述中的任何一个，或者可以通过专用集成电路合并上述中的任何一个。

计算机系统101可以通过一个或多个中间网络使用到一个或多个远程客户端系统的逻辑连接在网络环境中操作。这些网络一般表示任何协议、适配器、组件、以及与有线和/或无线通信网络关联的其它通用的基础设施。根据在不同的实现中的情形，这种网络可以在范围和本质上是全球的、区域的、本地的和/或个人的。

远程客户端系统(未示出)可以是，例如，个人计算机、移动设备、个人数字助理(PDA)、服务器、路由器、网络PC、对等设备或其他公用网络节点，并且通常包括上面相对于计算机系统101描述的多数或全部元件。远程客户端系统还可以包括非临时计算机可读存储介质或存储器件(未示出)的一个或多个实例。非临时计算机可读存储介质可以包括适用于通过网络与软件质量监视单元107交互的客户端应用或用户界面(例如，图形用户界面)。客户端应用可以是互联网浏览器、瘦客户端（thin client）或任何其他合适的应用。这种交互的示例包括对报告或仪表盘的请求。随后，客户端应用可以向计算机系统101转发这些请求以用于运行。

在一个实现中，软件质量监视单元107耦接到软件配置管理(SCM)系统130(或与SCM系统130接口连接)。可以通过远程计算机系统或相同的计算机系统101实现SCM系统130。SCM系统130跟踪并控制软件中的改动。更具体地，可以将SCM系统130设计为捕捉、存储和管理访问并提供对于软件源文件、设计和类似文件的版本控制。SCM系统130的示例包括SourceSafe、源代码控制系统(SCCS)或PVCS系统，但不局限于此。

软件质量监视单元107可以被设计为与SCM系统130一起工作以监视软件项目的整体质量。在一个实现中，软件质量监视单元107从SCM系统130接收软件项目文件、通过一系列编译和测试过程估计项目的整体质量以及向项目干系人(例如，开发者、测试者、负责人、工程师等等）报告评价的结果。有益地，不是仅在特征在最终的软件产品中就绪以后才花费巨大的资源查找和报告缺陷，而是在项目的开发过程期间提供关于项目的当前状态的定期更新。

根据一个实现，软件质量监视单元107使用监视任务来实现编译和测试过程。在一个实施例中，监视任务可以包括签入任务和基于时间的任务。可以由不同的事件触发这些监视任务。例如，每当开发者向SCM系统130“签入”新改动时就可以触发签入任务。可以通过时间事件触发基于时间的任务。例如，可以以规定时间间隔或在预定时间触发基于时间的任务。还可以当软件项目的安装包就绪或可用于安装时触发基于时间的任务。还可以使用具有不同的触发事件的其他类型的监视任务。

触发事件可以启动自动编译和构建过程以及相应的监视任务。取决于监视任务的类型，可以执行一系列不同的测试。例如，签入任务可能涉及更少的广度测试(例如，仅单元测试)，而基于时间的任务可能涉及更多的广度测试。作为示例，对监视任务的测试可以包括代码覆盖分析、功能测试、质量检验、单元测试，以及其他类型测试，但是不局限于此。对于基于安装包的任务，测试可以包括功能测试、性能测试以及其他类型的测试，但是不局限于此。一旦测试完成，例如，系统可以通过计算质量指数和/或在报告或仪表盘中总结测试结果来估计测试结果。系统可以在数据库中存储测试和/或评价结果，并且还向相应的项目干系人发送通知。当接收通知时，项目干系人可以立即修复与软件项目有关的任何检测到的故障或缺陷。将在以下部分中提供这些和其它示范性特征的更多细节。

图2示出用于监视并报告软件项目的整体质量的示范性的签入任务(或过程流)200。当开发者(或任何其他用户)向SCM系统130提交改动时签入任务200从202开始。

在204，在已经由SCM系统130接受改动之后，自动地编译或“构建”软件项目以考虑对源代码的新改动。然后在单个软件项目模块上执行一个或多个单元测试。单元测试被设计为运用源代码的各个单元，或一个或多个程序模块的集合，以便确定他们满足可靠性要求。单元测试的结果可以存储在数据文件214中，诸如可扩展标记语言(XML)文件。应当理解，也可以使用其它类型的文件格式。

在206，以合适的文件格式呈现测试结果和任何其他相关信息用于通知。取决于将要发送的通知类型，数据文件214被转换为合适格式的通知文件216。在一些实现中，通知是电子邮件、网页、传真文档、弹出显示窗口、文本消息、私有的社交网络消息和/或通过定制的客户端应用(例如，移动设备应用)发送的通知的形式。在一个实现中，通知文件216包括可以使用网络浏览器、电子邮件软件应用或任何其他软件程序查看的超级文本标志语言(HTML)文件。应当理解，还可以使用诸如富文本格式(RTF)或可移植文档格式(PDF)之类的其他类型标准文件格式。

图3示出示范性的构建报告(或通知文件)216。如所示，构建状态302和通用信息304可以包括在构建报告中。例如，构建状态302包括软件区域名（area name）、构建或测试的成功/失败状态、改动列表标识符、提交标识符、签入日期以及做出的改动和执行的测试的描述。通用信息304可以包括报告产生的时间、操作系统以及在其中执行编译的机器的型号。通过沿着各种维数来过滤数据文件214中的信息，还可以在报告中提供其他类型的信息。

再次参考图2，在208，向各个项目干系人自动地发送通知。在一个实现中，以电子邮件218的形式发送通知。还可以提供其他形式的通知。示范性项目干系人包括测试者、开发者、程序员、工程师、产品设计者、负责人等等。每当检测到缺陷，通知可以提醒各个项目干系人以便采取任何必需的行动。例如，可以促使开发者立即修复缺陷以避免引入更多严重的问题。在其它情况下，由于检测到的缺陷，项目经理可以决定停止发布用于内部使用或演示的项目。

在210，将测试结果传送到数据库文件。在一个实现中，包含结果的数据文件214(例如，XML文件)转换为数据库文件220。数据库文件220以与数据库(DB)222兼容的格式存储测试结果。例如，数据库文件220可以是结构化查询语言(SQL)文件。可以使用工业标准关系数据库管理系统(RDBMS)实现DB222，不过也可接受其他实现。在一个实现中，数据库可以是微软SQL服务器(Microsoft SQL server)。在212，生成的数据库文件220存储在数据库222中用于将来访问或检索。

图4示出更广泛的示范性的基于时间的监视任务400。可以通过时间事件和软件项目的安装包的可用性来触发基于时间的监视任务400。例如，可以以规定时间间隔(例如，每晚、每日、每周等等）或当任何人对SCM系统130签入改动的可能性更小时在预定时间(例如，午夜、周末或假日)触发基于时间的任务400。还可以当软件项目的安装包对安装就绪时触发基于时间的任务。安装包的就绪使涉及安装的问题最小化并因此减少错误警告故障。

在402，在任务400开始之后，更新来自SCM系统130的源代码。可以通过诸如基于Java的CruiseControl(或Cruise Control.NET)系统的自动构建系统来启动更新。也可以使用诸如SVN，MS Build、Code Project、Jenkins或其他非基于Java的系统之类的其他自动构建系统。自动构建系统可以实现为守护进程（daemon process）以对于对源代码的改动连续地(或周期性地)检查SCM系统。在一个实现中，自动构建系统触发SCM客户端应用以从SCM系统130下载源代码的最近的版本。

在404，自动构建系统将更新的源代码构建(或编译)成为可执行程序。

在406，在更新的源代码(或目标代码)上执行静态代码分析(或静态程序分析)。当SCM系统客户端完成源代码的更新时可以通过自动构建系统调用这种静态代码分析。静态代码分析是对被执行的软件的分析但不实际上运行从该软件构建的程序，而利用给定的一系列测试用例来实际上运行程序被称为动态测试。例如，动态测试包括功能测试和性能测试。静态测试便于通过确定他们是否是可构建、可部署并满足给定规范来验证应用。

在一个实现中，通过使用静态代码分析器工具，诸如Cppcheck、FindBugs、FlexPMD等等来执行静态代码分析。应当理解，也可以使用其它类型的工具。静态代码分析器工具可以在诸如C/C++、Java，Flex、Pascal、Fortran等等的一种或多种编程语言中检查非标准代码。例如，CppCheck可以用来检查C/C++代码的质量，Find Bugs用于检查Java代码的质量，而FlexPMD用于检查Flex代码的质量。可以对于每个静态代码分析器工具指定代码范围以执行分析。代码分析的结果可以保存在数据文件(例如，XML文件)中。

在408，在更新的源代码上执行单元测试。在单元测试期间，可以在源代码的各个单元或者一个或多个程序模块的集合上执行一个或多个单元测试。单元测试试图测试源代码的可靠性，而不是功能性问题。在一个实现中，在406中静态代码分析完成之后通过自动构建系统启动单元测试。单元测试的结果和相关信息可以记录在数据文件(例如，XML文件)里。这种信息的示例包括单元测试的数目、通过率、代码语言等等，但是不局限于此。

在410，分析代码覆盖。“代码覆盖”描述源代码已经被测试的程度。例如，代码覆盖数据可以指示已经通过单元测试覆盖的源码文件、单元或模块的数目。可以以若干级别（包括在单元测试期间运行的行、分支或方法）收集代码覆盖数据。所得到的代码覆盖数据可以存储在数据文件中，并且用于生成报告，例如，该报告示出目标软件需要执行更多测试。

在416，自动构建系统将来自各个测试(例如，静态代码分析、单元测试、代码覆盖分析等等）的结果和其它相关信息合并并格式化。例如，可以通过将包含信息的数据文件(例如，XML文件)添加到单个数据文件中来合并信息。可以将信息格式化成为总结报告436。

信息可选地包括功能测试结果412和/或性能测试结果414。在一些实现中，测试管理工具用于执行功能和/或性能测试以便获得结果(412和414)。测试管理工具可以用来管理并监视测试用例、项目任务，自动或人工测试、环境和/或缺陷(或bug）。例如，测试管理工具可以用来驱动(或开始)目标机器、设计和/或运行工作流、安装软件构建、运行自动功能和性能测试等等。示范性测试管理工具包括SAP的自动化系统测试运行（Automation SystemTest Execution）、HP Quality Center、IBM Rational Quality Manager等等。测试管理工具可以存在于相同的计算机系统101中(如图1所述)或者在可通信地耦接到计算机系统101的远程服务器中。

图5示出自动测试的示范性方法500。可以通过如上所述的测试管理工具实现此方法500。可以与参照图4描述的基于时间的监视任务400同时地执行自动测试方法500。每当软件项目的新构建和/或安装包可用时方法500可以启动。

参照图5，在504，测试管理工具接收构建信息文件。在一个实施例中，独立应用监视安装包的可用性。一旦安装包就绪，独立应用就刷新构建信息文件。用于监视和刷新构建信息的其他技术也可以使用。在一个实现中，构建信息文件存储最近的构建包编号和安装包位置。还可以包括其他信息。

在506，测试管理工具审查（inspect）构建信息文件以检测对构建的任何改动。如果检测到改动并且安装包可用，则测试管理工具触发一个或多个构建有关的任务。构建有关的任务可以包括用于实现自动测试的步骤508到步骤516。还可以触发诸如客户端软件安装的其他构建有关的任务。

在508，测试管理工具在检测到改动之后安装软件项目的新构建。

在510，测试管理工具运行一个或多个自动测试。自动测试可以是动态测试。例如，自动测试可以包括一个或多个自动功能和/或性能测试。

在一个实现中，测试管理工具运行一个或多个自动功能测试。功能测试试图验证软件代码的指定功能或动作是否满足设计要求。例如，可以通过将输入参数供给软件区域并且检查输出结果来测试功能。可以由测试者设计和编写这种测试，并且可以持续数小时。此外，可以同时测试不同的区域。

可替换地，或在其组合中，测试管理工具可以执行一个或多个自动性能测试。性能试验通常确定在特定工作负荷下系统的响应、稳定和/或可靠的程度。性能测试可能花费很长时间来运行，测试的范围可能仅局限于非常典型的场景以迅速获得最近构建的性能测试结果。此外，可以在若干机器上并行执行性能测试以提高效率。

在512，测试管理工具在一个或多个日志文件中存储自动测试的结果。例如，可以根据测试运行的日期在不同的文件夹中分类日志文件。

在514，分析结果。在一个实现中，以每日(或定期)为基础分析结果。例如，可以运行软件应用(例如，Java应用、性能测试驱动器等等)以执行自动的结果分析任务。应用可以解析来自各个日志文件夹的最近的日志文件并分析结果。例如，应用可以确定通过（pass）和/或失败的测试的用例数目。应用然后可以将总结信息写入到综合数据文件(例如、XML文件)用于临时存储。总结信息还可以包括其他测试相关信息，诸如构建信息、机器配置信息、测试时间、测试结果(例如，操作、第90个百分点的时间花费等等)，等等。总结信息可以存储在用于每个各自的软件区域的数据库的每个行中。

在一个实现中，数据库包括来自关于先前的产品的先前测试的数据，该数据可以用作用于评价当前项目的测试结果的基准数据。例如，可以运行软件应用(例如，Java应用)以生成每日的性能报告。应用可以访问数据库以检索基准数据和最近的测试结果，并且比较他们以确定处于测试中的当前软件项目的性能。如果当前项目的性能比基准情况慢一个预定阈值(例如，10%)，则可以将它认为是“失败”。相反地，如果相对性能快一个预定阈值，则将它认为是“通过”。在下面的表1中示出示范性每日性能报告：

区域	状态	备注
			Xcelsius Client SWF	通过
Xcelsius Enterprise BEx	失败	ADAPT0056263
			Xcelsius Enterprise MS OLAP	失败	ADAPT005054
Xcelsius Enterprise Oracle	通过

表1

在516，测试管理工具察看是否测试了软件项目的全部区域。如果没有完成全部测试，则方法500继续进行以对于下一区域安装新构建。自动测试步骤508-516可以重复若干次迭代并且对于多个用户重复。如果全部测试完成，则方法500结束。包括总结信息的功能和性能测试结果可以通信发送到计算机系统101以便被包括在总结报告436中。

图6示出示范性的总结报告436。可以定期地生成总结报告以提供项目状态的频繁更新。示范性的总结报告436显示多种测试的测试结果，诸如静态代码分析610的代码质量结果、单元测试612的通过/失败率(或通过/失败数目)以及自动测试620的通过/失败率(或通过/失败数目)。还可以将诸如安装状态和改动列表标识符之类的其他信息包括在总结报告436中。通过从更全面的视角呈现软件质量，将激励测试者和开发者在全部特征就绪之前的早期修复质量方面的任何缺陷。

可替换地，或在其组合中，总结报告436可以是仪表盘，诸如图7，图8和图9中示出的那些，稍后将更详细地对其进行描述。可以向项目干系人定期地(例如，每月或每季度）发送仪表盘以报告软件项目的整体质量趋势。例如，这种定期报告可以指示软件团队是否正在随时间完成更好的作业，或者某些事情是否出错并且需要调整。当质量指数分数处于“红区”中时仪表盘可以提醒项目干系人以做出迅速的调整以便使它回到正轨。

继续参考图4，在418，总结报告436可以被转换为通知文件438(例如，HTML电子邮件)，然后通知文件438在418被发送给各自的项目干系人。例如，可以经由简单邮件传送协议(SMTP)服务或任何其他通信服务发送通知。可以定制通知文件438以仅呈现与特定项目干系人有关的数据。它还可以包括一个或多个链接以呈现项目干系人可能偶而感兴趣的其他数据或细节。

在420，在数据库440中保存总结报告436用于将来的检索和分析。例如，这可以通过使用诸如Apache Ant SQL任务的命令行工具来获得。任何其他工具也可以用于管理数据库440。

在一个实现中，从数据库440检索总结报告436以生成仪表盘来向项目干系人软件项目通知当前状态或整体质量。仪表盘可以包括不同元件，以便使用例如合适的软件质量指示符、关键性能指示符(KPI)、度量、趋势、图形、数据可视化和交互来呈现数据的聚集视图。例如，在最高级别，仪表盘可以包括用户界面(UI)或仪表盘面板。在面板之内可能存在对应于第二高级别的一个或多个视图区。视图区包括便于数据可视化的一个或多个视觉组件。提供其他类型的组件或元件也可以是有用的。取决于设计，视图区可以包括具有不同视觉组件的子视图区。仪表盘还可以提供有不同的特征或功能。例如，可以提供用于执行“如果...会怎样（what if）”分析和数据的动态可视化的诸如下拉菜单、滑块和命令按钮的组件或元件以使得用户在运行时能进行交互。可以相信的是，仪表盘的使用使得能够快速理解数据以便于更好和更有效的做出决定。在一个实施例中，仪表盘设计应用是SAP

BusinessObjects^TMXcelsius

Enterprise。其他类型的仪表盘设计应用也可以使用。例如，仪表盘设计应用可以是SAP

Visual Composer。

图7示出示范性的基于时间段的仪表盘700。仪表盘700呈现一个或多个质量图形，其示出预定日期范围内软件项目每天的质量趋势。具体地，每个质量图形702可以表示软件组件通过(即满足预定义标准)的次数或它被测试的总数。

在一个实现中，仪表盘700还包括用于指示软件项目的健康的质量指数704。例如，质量指数704可以是从0到100范围内的数字值，其中100是最好。它可以使用预定义公式通过组合质量加权轴(例如，代码违例、代码复杂性、风格违例、测试覆盖、文档覆盖等等）来导出。质量指数704可以用来评价和对软件项目的质量定等级，和/或示出项目的整体质量是否随时间(例如，星期或月)改善的趋势。质量指数704可以被包括在总结报告和/或仪表盘中以提醒项目干系人如果质量降到预定级别之下则采取行动。它也可以被用作用于决定是否启动、终止或发布项目的基础。

图8示出另一示范性的基于时间段的仪表盘800。仪表盘800提供用户界面组件802a至802b(例如，文本框或下拉式菜单)以允许用户分别选择质量图形的具体开始和结束日期。用户还可以选择呈现质量图形和指示符的时间段范围(例如，两个月或三个月)。可以在不同的图形中分开地呈现用于每个类型测试(例如，单元测试，静态代码分析、自动测试等等）的质量图形804a至804c。此外，一个或多个不同类型的图形(例如，线形图、柱状图、圆饼图等等）可以用来显示测试结果。通过提供项目的质量的整体视图，多个项目干系人可以看到在指定时间段内的数据的趋势。这允许他们在那些问题成为难题之前做出决定并对问题作出反应。

在一个实现中，仪表盘800包括质量指数(QI)的图形表示810。QI图形表示可以是显示软件项目的瞬时质量指数分数的量表（gauge）。当指针811旋转到红区812，从而指示QI分数已经降到预定级别之下时，可以警告各自的项目干系人采取合适的行动。应当理解其他类型的图形表示也可以使用。

可以提供类似图形表示(814和818)以呈现可以用来导出整体QI分数的瞬时开发者(DEV)和软件测试者(ST)质量分数，如稍后将更详细地描述的。此外，可以提供图表(830和840)(例如，直方图)以显示用于计算DEV和ST质量分数的不同组件或区域的值。还可以提供用户界面组件822(例如，下拉式菜单、文本框等等）以允许用户指定收集数据以计算这些QI、DEV和ST分数的日期。

图9示出另一示范性的基于时间段的仪表盘900。如所示，提供显示瞬时QI、DEV和ST质量分数的图形表示(810、814和818)。此外，提供图形直线图910以显示QI、DEV和ST分数在时间段内的趋势。更进一步的，图表(例如，表格)(830和840)用于显示用于计算DEV和ST质量分数的不同组件或区域的值。

如先前叙述，可以基于开发者(DEV)质量分数和软件测试者(ST)质量分数导出整体QI指数。基于一个或多个源代码度量导出开发者(DEV)质量分数。例如，可以基于代码违例的数目、代码复杂性、重复覆盖、代码覆盖和/或文档信息的加权组合导出DEV质量分数。还可以考虑诸如风格违例的源代码质量的其他度量。可以使用通过，例如，计算机系统101实现的前述的技术来获得(或从数据库检索)用于计算这些源代码度量的数据。

在一个实现中，DEV质量分数至少部分地基于代码违例分数(代码,Coding)，另外被称为代码符合指数。代码违例是指偏离接受的代码标准。这种代码标准可以包括内部定义的标准、业内广泛应用的标准或例如，由开发者和/或客户对于给定软件开发计划具体定义的标准。取决于严重级别，代码违例可以分类成为不同组。这种类别包括在严重级别方面渐增的“Blocked（阻断）”(B)、“Critical（关键）”(C)、“Serious（严重）”(S)、“Moderate（中等）”(M)和“Info（信息）”(I)。应当理解还可以分配其他分类标签。

可以对于每个严重级别合计分类的代码违例以提供相应的违例计数。为了计算代码违例分数(Coding)，可以根据有效的(或可运行的)代码行(ValidCodeLines)的总数来加权并归一化这些违例计数，如下：

Coding=(B×10+C×5+S×3+M×1+I×1)/ValidCodeLines ------(1)

如由上面的等式(1)所示，越严重的代码违例(例如，Blocked)可以分配相对较高的权重(例如，10)，因为他们对代码质量具有更大的影响。相反地，越不严重的代码违例(例如，Info)分配相对较低的权重(例如，1)，因为他们对代码质量具有更小的影响。

在一个实现中，DEV质量分数至少部分地基于代码复杂性分数(复杂性,Complexity)。代码复杂性可以由圈复杂性(或条件复杂性)测量，其直接测量贯穿（through）程序的源代码的线性独立路径的数目。取决于测量的线性独立路径的数目，源代码段可以分类成为不同级别的代码复杂性。示范性类别包括，例如，Complexity>30、Complexity>20、Complexity>10、Complexity>1等等。还可以分配其他分类标签。

可以对于每个类别合计代码段的数目以提供相应的复杂性计数。这些复杂性计数然后可以根据有效的或可执行代码行(ValidCodeLines)的总数来加权并归一化以计算代码复杂性分数(Complexity)，如下:

Complexity=(Complexity>30×10+Complexity>20×5+Complexity>10×3+Complexity>1×1)/ValidCodeLines ---------(2)

如由上面的等式(2)所示，越复杂的代码段(例如，Complexity>30)可以分配相对较高的权重(例如，10)，因为他们更影响代码质量。例如，由于具有高复杂性的代码有引起缺陷的倾向，所以他们难以维持。相反地，越不复杂的代码段(例如，Complexity>1)分配相对较低的权重(例如，1)，因为他们对代码质量具有更小的影响。

在一个实现中，DEV质量分数至少部分地基于重复覆盖分数(重复,Duplication)。“重复代码”是指在程序之内发生不止一次的源代码的序列。不期望重复源代码。例如，重复源代码是仅几行或几个字符不同的、很长的重复代码段，这使得难以迅速地理解它们以及它们的目的。重复覆盖分数(Duplication)可以通过除以有效或可执行代码行(ValidCodeLines)的总数以将重复代码行(DuplicatedLines)的总数归一化来计算，具体如下：

Duplication=DuplicatedLines/ValidCodeLines --------------(3)

在一些实现中，DEV质量分数至少部分地基于代码覆盖分数(单元测试，UnitTest)。如上所述，代码覆盖描述源代码已经测试的程度。例如，可以按照百分比量化代码覆盖(COV)。可以通过计算COV和测试成功率(SUC)的加权组合来确定代码覆盖分数(UnitTest)，如下：

UnitTest=0.7×COV+0.3×SUC --------------(4)

在一些实现中，DEV质量分数至少部分地基于文档分数(文档,Document)。源代码文档是被写入的注释，用于识别或解释源代码的功能、例程、数据结构，对象类或变量。可以通过找到已经文档化的应用编程接口(API)的百分比(documented_API_Percentage)来确定文档分数：

Document=documented_API_Percentage --------------(5)

一旦已经确定了这些源代码度量，可以通过将源代码度量组合到全局测量中来计算DEV质量分数(X)，如下：

X=100-35×Coding-25×(1-Test)-15×Complexity-15×Duplications–10×(1-Document)---------------(6)

如所示，相对较高的权重(例如，35)分配给被认为更影响源代码的质量的源代码度量(例如，Coding)。DEV质量分数的范围可以是从0到100，100是最好的质量分数。应当理解，还可以实现其他范围(例如，0到1000)。假设其他权重值也可以用于度量。

更具体地，可以如下计算DEV质量分数(X)：

X = 100 - \frac{a 1 \times 10 + a 2 \times 5 + a 3 \times + a 4}{f} \times 35 - (1 - (b 1 \times 70 % + b 2 \times 30 %)) \times 25 - \frac{c 1 \times 10 + c 2 \times 5 + c 3 \times 3 + c 4}{f} \times 15 - \frac{d}{f} \times 15 - (1 - e) \times 10 - - - (7)

其中a1=Blocked代码问题的数目

a2=Critical代码问题的数目

a3=Serious代码问题的数目

a4=Moderate代码问题的数目

b1＝单元测试代码覆盖(%）

b2=单元测试成功率(%）

c1＝Complexity>30的源代码的数目

c2=Complexity>20的源代码的数目

c3=Complexity>10的源代码的数目

c4=Complexity>1的源代码的数目

d=重复代码行的数目

e=文档化的API百分比(％）

f＝有效代码行的数目

可以基于诸如功能测试度量(功能，Functional)和性能测试度量(性能，Performance)之类的一个或多个自动测试度量导出软件测试者(ST)质量分数。可以使用通过，例如，计算机系统101实现的前述的技术来获得(或从数据库检索)用于计算这些自动测试度量的数据。

在一个实现中，通过计算代码覆盖(COV)和测试成功率(SUC)的加权组合来确定功能测试度量(Functional)，如下：

Functional=0.6×COV+0.4×SUC --------------(8)

可以通过计算与基线相比的性能变量增量(DELTA)和测试成功率(SUC)的加权组合来确定性能测试度量(Performance)，如下：

Performance=0.6×DELTA+0.4×SUC--------------(9)

一旦获得自动测试度量，可以通过计算这些度量的加权组合来确定ST质量分数(Y)，如下：

Y=60×Functional+40×Performance -------(10)

更具体地，可以如下计算ST质量分数(Y)：

Y=(a1×70%+a2×30%)x60+(b1×60%+b2×40%)×40----------(11)

其中a1＝功能测试代码覆盖(%）

a2=功能测试成功率(%）

b1=与基线相比的性能变量增量(%）

b2=性能测试成功率(%）

然后可以通过确定DEV和ST质量分数的加权组合来计算整体质量指数(QI)，如下：

QI=X×60%+Y×40%----------------(12)

虽然已经在具体结构特征和/或方法步骤的语言中描述了一个或多个上述实现，但是将理解，可以在没有所述具体特征或步骤的情况下实践其他实现。相反地，所述具体特征和步骤被公开为一个或多个实现的优选形式。

Claims

1.一种用于监视和改善软件开发质量的方法，包括：

监视与源代码有关的监视任务的发生；

编译源代码；

测试源代码以产生测试结果；以及

分析测试结果，其中分析测试结果包括用于评价源代码的质量的质量分析。

2.如权利要求1所述的方法，还包括计算与测试结果相对应的质量指数。

3.如权利要求1所述的方法，其中所述监视任务包括签入任务或基于时间的任务。

4.如权利要求3所述的方法，其中所述签入任务是当由开发者签入对源代码的新改动时触发的。

5.如权利要求3所述的方法，其中所述基于时间的任务是以规定时间间隔、在预定时间或当安装包对于安装可用时触发的。

6.如权利要求1所述的方法，还包括向项目干系人发送测试结果的通知。

7.如权利要求6所述的方法，其中所述通知是电子邮件、网页、传真文档、弹出显示窗口、文本消息、私有的社交网络消息或定制客户端应用的形式。

8.如权利要求1所述的方法，还包括：

将测试结果转换为数据库文件；以及

在数据库中存储数据库文件。

9.如权利要求8所述的方法，其中所述数据库包括来自先前的产品的先前测试的数据库文件作为用于评价当前产品的基准数据。

10.如权利要求1所述的方法，其中编译源代码包括使用自动构建系统将源代码更新成为可执行程序。

11.如权利要求10所述的方法，其中所述自动构建系统包括基于Java的系统或非基于Java的系统。

12.如权利要求1所述的方法，其中测试源代码包括：

执行静态代码分析；

执行单元测试；

执行代码覆盖分析；

将来自测试和分析的结果和相关信息合并成为单个数据文件；以及

将单个数据文件格式化成为总结报告。

13.如权利要求12所述的方法，其中所述相关信息包括功能测试结果和性能测试结果。

14.如权利要求12所述的方法，其中所述总结报告包括仪表盘或通知文件。

15.如权利要求14所述的方法，其中所述仪表盘包括用于指示软件开发的健康的质量指数。

16.如权利要求15所述的方法，其中所述质量指数是基于加权的开发者质量分数和加权的软件测试者质量分数导出的。

17.一种具有存储在其上的程序代码的非临时计算机可读介质，所述程序代码由计算机运行以进行下述步骤：

监视与源代码有关的监视任务的发生；

编译源代码；

测试源代码以产生测试结果；以及

18.如权利要求7所述的非临时计算机可读介质，其中编译源代码包括：

执行静态代码分析；

执行单元测试；

执行代码覆盖分析；

将单个数据文件格式化成为总结报告。

19.一种系统，包括：

非临时存储设备，用于存储计算机可读程序代码；以及

处理器，与存储设备通信，该处理器利用计算机可读程序代码可操作以进行如下步骤：

监视与源代码有关的监视任务的发生；

编译源代码；

测试源代码以产生测试结果；以及

20.如权利要求19所述的系统，其中编译源代码包括：

执行静态代码分析；

执行单元测试；

执行代码覆盖分析；

将单个数据文件格式化成为总结报告。