白盒测试技术

白盒测试技术工业和信息化部电子第五研究所中国赛宝实验室2023年2月2日陈能技课程大纲1白盒测试知识体系2如何开展实施白盒测试项目3静态白盒测试方法4动态白盒测试方法学习方法案例讲解+演练+讨论主题1白盒测试知识体系2如何开展实施白盒测试项目3静态白盒测试方法4动态白盒测试方法5持续集成一、白盒测试知识体系白盒测试的优势早期测试与白盒测试敏捷测试思想与白盒测试技术白盒测试工程师的技能要求黑盒测试的缺陷黑盒测试既不充分，而且效率也低。在系统完成之前，测试就无法开始，测试人员只有软件版本发布时才能拿到版本进行测试。Findbugsearly!Costeffective!白盒测试的优势尽早测试原则缺陷预防不治已病治未病，不治已乱治未乱。--《黄帝内经》克劳士比零缺陷第一次就把事情做对缺陷预防敏捷测试思想与白盒测试技术敏捷测试意味着质量观的变化，整个研发团队都要对质量负责敏捷开发SCRUMSCRUM强调以有节奏的流模式生产软件可预期的8小时工作日被视为专业素养和控制力的代表长度为30天的开发进程可以适用于大多数项目敏捷XP实践XP工作流程开始项目编写故事评估故事估计工作速率创建迭代计划修改迭代计划将故事分成任务选择任务选择合作伙伴编写单元测试获取最新的代码重构旧代码并进行测试编写新代码集成并运行单元测试重构新代码并进行测试签入新代码运行客户测试发布软件获得用户反馈评估工作速率结束项目规划策略迭代任务白盒测试工程师的技能要求主题1白盒测试知识体系2如何开展实施白盒测试项目3静态白盒测试方法4动态白盒测试方法5持续集成二、如何开展实施白盒测试项目白盒测试方案介绍试点项目选取策略分阶段实施过程白盒测试方案介绍持续集成持续质量度量

测试用例执行

自动化测试代码质量趋势监控代码质量度量角度：-代码量-文档量-冗余度-复杂度-代码问题、技术债务试点项目选取策略质量要求相对高的进度相对不紧迫资源相对充足（人的问题）小范围试验、逐步推广分阶段实施过程先静态、后动态，先代码审查、后单元测试小范围代码规则集、待习惯后、再逐步扩大代码审查：工具+人工接口测试自动化->细粒度单元测试持续集成框架搭建->持续质量度量平台搭建Google的测试策略谷歌采用70/20/10原则:70%小，20%中，10%大主题1白盒测试知识体系2如何开展实施白盒测试项目3静态白盒测试方法4动态白盒测试方法5持续集成三、静态白盒测试方法代码审查最佳实践代码自动化分析工具的应用如何结合工具分析与人工审查代码质量度量方法代码质量度量常用工具介绍代码审查最佳实践代码审查对成本的节省代码审查的目的评审制度的建立代码审查方法、原则、流程规范代码审查对成本的节省代码审查对成本的节省代码审查的目的1、设计合理性Review2、互为Backup

3、分享知识、设计、技术

4、代码可读性5、Code中的“地雷区”Review6、发现代码中的业务逻辑错误“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。评审对软件质量的作用IBM的第一个缺陷预防的研究包含了数百个应用程序，且历时超过3年。应用程序使用正式审查后，与那些只进行了测试的类似的应用程序相比，其工期更短、成本更低。20世纪70年代IBMIMS数据库产品，在审查之前，IMS测试组需要90天做3轮测试。而进行了审查之后，同样的测试周期缩短到30天，只做一轮测试。评审对软件质量的作用缺陷起源缺陷起源缺陷发现缺陷发现没有使用正式审查的缺陷起源点和发现点使用了正式审查的缺陷起源点和发现点评审对软件质量的作用测试前缺陷清除手段–审查（需求、架构、设计、代码及其他可交付成果）使用率：超过75%的系统和嵌入式应用程序超过35%的大型商业应用程序少于5%的Web和IT应用程序少于5%的小型应用程序（规模小于1000个功能点）缺陷清除效率范围：最小低于65%平均等于85%最大高于97%准备时间：超过3小时/审查参与者执行时间：超过4小时/参与者每次审查会议协同效应：嵌入式、系统、IT、军用软件相反指示：敏捷项目、规模小于500个功能点的小型项目数据来源：《软件质量经济学》3种相对正式的评审审查小组评审走查组织者企业级常由EPG、QA部门组织团队级，项目级通常由项目经理发起团队级，项目级通常由项目内发起主持人专职主持人，不能使作者可专职或由作者兼任通常是作者会前会议一定会召开评审前的会议会前会议通常很简单通常没有检查表一定有规范的检查表相对简单的检查表通常没有通用评审流程步骤

介绍会议？1.计划阶段3.准备阶段2.介绍会议YN7.跟踪阶段6.返工阶段YN第三小时会议？4.Review会议5.第三小时会议

入口准则出口准则同行评审常见问题没有评审计划专家选择不合适没有充分的准备评审会议偏离主题和重点评审会议中过多争论占用大量时间问题修改后跟踪不力

XX评审CHECKLIST

1、*****************************2、*****************************3、*****************************此处键入姓名此处键入姓名

没有使用CheckList作为指导代码审查方法流程组织：CMMIvs.敏捷审查范围筛选人工+工具CMMI代码审查流程准备代码审查进入条件：代码更改集已通过单元测试代码审查会议进入条件：代码标准、威胁模型代码审查活动：NameCorrectnessCodeRelevance（功能相关、无无用代码）ExtensibilityMinimalCodeComplexity

AlgorithmicComplexityCodeSecurityCodeReviewWorkItem（代码审查工作项记录）代码审查检查单模板：CodeReviewChecklist.dotMSFforCMMIProcessImprovement谨慎的使用审查中问题的发现率作为考评标准在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。敏捷CodeReview流程Code

Review协作过程1）先由代码的开发人员向检查人员进行大体的介绍，包括设计思想、数据结构、程序代码结构介绍等。2）双方进行讨论、交流。3）检查人员单独进一步进行CodeReview，并记录Review结果和建议。4）由检查人员和开发人员一起，检查人员反馈Code

Review结果，并和开发人员一起讨论改进方法，重构。5）最后把可重用的Code

Review的经验总结编码规范，或者记录到“地雷区”中。便于整个团队复用经验。MSFforAgileSoftwareDevelopment进入条件：Areviewerfamiliarwiththecodeareaisavailable.代码审查活动：NameCorrectnessCodeRelevance（功能相关、无无用代码）ExtensibilityMinimalCodeComplexityAlgorithmicComplexityCodeSecurityFixReviewChanges（修改评审需要修复的问题）审查前的代码开发者准备因为代码开发者需要重新考虑，并解释注释过程中所发生的更改，所以代码开发者需要在评审开始之前就找出许多缺陷，以让评审变得更加有效。代码开发者在评审之前要先注释他们的源代码。代码审查人员组织形式开发组长负责制对小组所有成员的代码质量负责开发组长的开发任务不要太多，以便有精力去指导其他成员的设计，并且复查他们的代码项目经理或QA进行抽查成员互助制每个组员的代码签入前必须请求一位组员进行代码审查审查者与被审查者对审查的代码共同拥有质量职责代码审查的范围定义每次审查的代码量增量代码审查最近一次迭代开发的代码专题性的代码审查（安全、性能等）基于风险筛选审查重点系统关键模块业务较复杂的模块代码复杂度高的模块代码审查范围--每次审查的代码量根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降。随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。增量CodeReviewReview应该持续进行，每次一部分，对于新增的需求、新增的代码、修改的部分实行增量审查代码审查的效率问题每小时超过400LOC的评审速度会降低效率。花足够的时间进行适当缓慢的评审，但是不要超过60-90分钟大约60

分钟后，评审者就会感到疲劳，于是就不会找到额外的缺陷了。基于风险筛选审查重点系统关键模块、业务较复杂的模块从业务需求重要度、优先级出发筛选缺陷率较高的模块从历史缺陷数据出发筛选代码复杂度高的模块从代码实现的复杂度（圈复杂度）度量出发筛选把工具引入到代码审查流程中把工具引入到代码审查流程中编程规范编程规范通常包括：数据类型检查代码缩进换行命名规范注释规范…CodeReview-类型检查 在Java中，下面的语句虽然符合类型检查规则，但是会在运行时失败，抛出一个ArrayStoreException异常: Object[]objs=newString[1]; objs[0]=newObject();CodeReview-类型检查CodeReview-风格检查常见工具 C/C++：PC-Lint、PRQAC/C++、CppLint JAVA：PMD、CheckStyle .NET：StyleCop、FxCop风格检查更加挑剔，也更加注重空格、缩进、命名、注释、程序结构这些表面的东西。风格检查程序所展示的错误往往都是影响代码的可读性和可维护性的问题。好的代码编写风格能让代码变得“赏心悦目”增强代码的可读性和可维护性并且能促进项目组基于代码的沟通。

public

enumColor{red,green,blue}程序结构的问题CheckStyle、PMDpublic

finalStringgetColorString(finalColorc){Stringret="";switch(c){case

red:System.out.println("red");}returnret;}public

static

voidmain(String[]args){System.out.println("TheBritisharecoming"+revere(1));}public

staticStringrevere(intlights){Stringmanner="byland";

if(lights>0)if(lights==2)manner="bysea";elsemanner="";

returnmanner;}缩进的问题命名规范骆驼（Camel）帕斯卡（Pascal）匈牙利“匈牙利”法该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。例如所有的字符变量均以ch为前缀，若是指针变量则追加前缀p。如果一个变量由ppch开头，则表明它是指向字符指针的指针。“匈牙利”法的缺点“匈牙利”法最大的缺点是烦琐，例如 inti,j,k; floatx,y,z;倘若采用“匈牙利”命名规则，则应当写成 intiI,iJ,ik;//前缀i表示int类型 floatfX,fY,fZ;//前缀f表示float类型如此烦琐的程序会让绝大多数程序员无法忍受。骆驼式命名法正如它的名称所表示的那样，是指混合使用大小写字母来构成变量和函数的名字。例如，下面是分别用骆驼式命名法和下划线法命名的同一个函数：

printEmployeePaychecks()；

print_employee_paychecks()；

第一个函数名使用了骆驼式命名法--函数名中的每一个逻辑断点都有一个大写字母来标记；第二个函数名使用了下划线法函数名中的每一个逻辑断点都有一个下划线来标记。

骆驼式命名法近年来越来越流行了，在许多新的函数库和Microsoft

Windows这样的环境中，它使用得当相多。另一方面，下划线法是c出现后开始流行起来的，在许多旧的程序和UNIX这样的环境中，它的使用非常普遍。帕斯卡（Pascal）与骆驼命名法类似。只不过骆驼命名法是首字母小写，而帕斯卡命名法是首字母大写，如：publicvoidDisplayInfo();

stringUserName;

二者都是采用了帕斯卡命名法

在C#和JAVA中，以帕斯卡命名法和骆驼命名法居多。据考察，没有一种命名规则可以让所有的程序员赞同，程序设计教科书一般都不指定命名规则。命名规则对软件产品而言并不是“成败悠关”的事，我们不要花太多精力试图发明世界上最好的命名规则，而应当制定一种令大多数项目成员满意的命名规则，并在项目中贯彻实施。命名规范注释代码注释量检查注释风格文件注释类注释函数注释变量注释代码实现注释TODO注释SourceMonitorJava注释规范：/technetwork/java/javase/documentation/codeconventions-141999.html#385推荐阅读《TheElementsofJavaStyle》100页左右的关于Java编程风格的书官方标准：/technetwork/java/codeconvtoc-136057.html

练习应用CheckStyle、PMD等工具检查代码风格CodeReview–程序理解程序理解工具能帮助我们搞懂代码库中的大量代码，洞察程序运转之道，评审代码的设计架构等内容。集成开发环境（IDE）一般至少都包含某些程序理解功能，例如：“查找本方法的所有应用”。常用工具代码流程图：CodeVisualtoFlowchartUML与源代码双向工程，例如Green、Fujaba、Understand、RationalRose代码调用关系图：Understand、JDepend、JArchitectPMD的数据流分析视图Fujiaba能在UML视图和源代码之间来回转换JDepend识别包依赖Understand的”蝴蝶图”CodeReview-Bug查找BUG查找的目的不像风格检查那样抱怨格式方面的问题，而是根据“BUG惯用法”（规则）来描述代码中潜在的缺陷。常用工具：

PMD、FindBugs JTest、Coverity、Klocwork《MoreJavaPitfalls》EmptyCatchBlock: EmptyCatchBlockfindsinstanceswhereanexceptioniscaught,butnothingisdone.Inmostcircumstances,thisswallowsanexceptionwhichshouldeitherbeactedonorreported.Example: publicvoiddoSomething(){ try{ FileInputStreamfis=newFileInputStream("/tmp/bugger"); }catch(IOExceptionioe){ } }CodeReview-Bug查找PMD能检查出上面Java代码中“空的异常Catch块”的问题Stringastr="abcdefghijklmn";astr.replace("abc","123");System.out.println(astr);PMD、FindBugsFindBugs能检查出上述Java代码的潜在错误

inta=0;switch(a){case0:return0;case1:a=1;}returna;PMD可以发现其中潜在的错误doublei=0.0;while(i<10){

i+=0.1;

System.out.println(String.valueOf(i));

if(i==6.0){

System.out.println("OK!");

}}《Java编程规范》（第三版）

voidmethod1(Vectorvector){

for(inti=0;i<vector.size();i++)//Violation;//...}

voidmethod3(Strings){

if(s.startsWith("a")){//violation//...}}代码效率问题练习使用PMD、FindBugs检查代码错误推荐阅读CodeReview-安全审查静态的代码安全测试：主要是通过对源代码进行安全扫描，根据程序中数据流，控制流，语义等信息与软件安全规则库进行匹对，从中找出代码中潜在的安全漏洞。可以在编码阶段找出大部分可能存在安全风险的代码，这样开发人员可以在早期解决潜在的安全问题。工具CodeSecure、Yasca、FindBugs\

FindSecurityBugsFortify、AppScanSourcetry{Stringpwd=hashPassword(password);StringsqlString="SELECT*FROMdb_userWHEREusername='"+username+"'ANDpassword='"+pwd+"'";Statementstmt=connection.createStatement();ResultSetrs=stmt.executeQuery(sqlString);

if(!rs.next()){

throw

newSecurityException("Usernameorpasswordincorrect");}//Authenticated;proceed}finally{

try{connection.close();}catch(SQLExceptionx){//forwardtohandler}}importjava.io.FileReader;publicclassEightBall{ publicstaticvoidmain(Stringargs[])throwsException{ char[]buffer=newchar[1024]; Stringfilename=args[0]; try{ filename=""+(Integer.parseInt(filename)%3); }catch(Exceptione){ System.out.println("Invalidinput."); }

newFileReader(filename).read(buffer); System.out.println(buffer); }}FindSecurityBugs、FortifyFortify能找到上述代码的“路径操纵”问题Java安全编程标准TheCERTOracleSecureCodingStandardforJava/CodeReview-代码质量度量代码精简度继承深度类间耦合度圈复杂度可测试性可维护性…常用工具：Metrics、JavaNCSS、Testability-explorer、SourceMonitor、SonarLogiscope代码复杂度软件复杂性度量-圈复杂度复杂度计算公式为：M=V(G)=e–n+2其中：V(G)路径图的环形数目e=边的数目n=节点数目练习计算以下代码的圈复杂度：voidSort(intiRecordNum,intiType)1{2intx=0;3inty=0;4while(iRecordNum-->0)5{6If(iType==0)7 x=y+2;8else9If(iType==1)10x=y+10;11else12x=y+20;13}14}讨论如果检查出圈复杂度很高应该怎么办？软件复杂性度量--语法构造法基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。语法构造方法可以揭示程序中单独的语法构造和缺陷率之间的关系：缺陷率=0.15+0.23DOWHILE+0.22SELECT+0.07IF-THEN-ELSELogiscope软件复杂性度量--结构度量法Henry给出的结构复杂性定义：Cp=(扇入×扇出)2其中：扇入–调用外部模块的模块数扇出–被外部模块调用的次数JDepend、Understand、Metrics、Logiscope代码审查辅助工具（1）CodeCollaborator、Jupiter代码审查辅助工具（2）SourceMonitor、JavaNCSS…推荐阅读主题1白盒测试知识体系2如何开展实施白盒测试项目3静态白盒测试方法4动态白盒测试方法5持续集成四、动态白盒测试方法单元测试最佳实践单元测试用例设计的方法与技巧单元测试工具与框架的应用桩与驱动单元测试覆盖率分析代码性能测试代码内存泄漏测试WhyUnitTesting?Dynamicblack-boxtestingishighcost:1.It’sdifficultandsometimesimpossibletofigureoutexactlywhatcausedtheproblem.2.Somebugshideothers.立即测试vs单一测试TDD思想TDD把单元测试的地位提高到了史无前例的最高点，倡导测试先行、用测试驱动开发。测试是最好的设计，在编写代码之前就要把测试想好，这样在编写代码时才胸有成竹。XP中一个很核心的实践就是TDDTDD基本过程测试驱动开发的基本过程明确当前要完成的功能。可以记录成一个TODO列表。快速完成针对此功能的测试用例编写。测试代码编译不通过。编写对应的功能代码。测试通过。对代码进行重构，并保证测试通过。循环完成所有功能的开发。测试驱动开发的好处不断测试，提高软件质量不断重构，提高软件处理变化的能力在EmpiricalSoftwareEngineering杂志上首次发表的一篇研究报告声称：“看来TDD可以应用在多个领域中，并显著降低软件的缺陷密度，同时也不会明显降低开发团队的工作效率。”单元测试框架基于框架来编写单元测试代码会更方便、高效。常见的单元测试框架JUnit、TestNGJUnit单元测试建立JUnit单元测试JUnit3与JUnit4的区别断言类的使用TestCase、TestSuiteJUnit框架的AnnotationAnnotation含义@Test定义一个要测试的方法@Before在每一个测试之前都会被执行的方法，这个方法常常用来进行一些测试环境的准备，比喻说读入输入数据，初始化类@After与@Before进行对应，做一个清理工作@BeforeClass在所有的测试开始之前执行，这个方法在类运行的时候运行，而且只会运行一次，所以常常用来做一些所有的方法都要依赖到工作，比喻说，数据库的链接。@AfterClass与@BeforeClass进行对应，做一些类级别的清理工作@Ignore表明方法是被忽略的，这个方法非常实用，比喻你的方法已经修改，但是对应的测试方法还没有得到一致的修改的时候，可以忽略掉这个测试方法先。@Test(expected=IllegalArgumentException.class)检查测试方法是不是抛出了对应的异常@Test(timeout=100)如果方法的执行操作所耗费的毫秒数>100MS，那么方法失败。JUnit单元测试常见问题如何测试私有方法和字段？如何测试异常？如何测试代码执行效率？单元级别性能测试System.currentTimeMillis()、System.nanoTime()AOP编程实现方式代码执行效率度量TDD过程演练如何做到“Cleancodethatworks”？不可运行–可运行–重构代码覆盖率度量你的测试用例没有覆盖软件的哪些部分？哪些测试用例是冗余的？为了得到更好的覆盖率，如要添加哪些新的测试用例？覆盖率统计工具Emma、Cobertura、CoverlipseClover、PureCoverage正确看待覆盖率数据！数据驱动的单元测试参数化测试、数据与代码分离数据源Excel、XML、数据库数据驱动框架DDTUnit、Feed4JUnitDBUnit的应用DbUnit(/

)则是专门针对数据库测试的对JUnit的一个扩展，它可以将测试对象数据库置于一个测试轮回之间的状态。模拟框架驱动和桩的概念Stub和Mock为什么要做Mock？模拟框架应用EasyMock、Mockito、JMock驱动（driver）桩（stub）单元测试工具JTestRTRT工具与框架的区别我们需要这些工具吗？开发者测试的难点什么是合适的被测单元？如何找到合适的被测单元？如何提高被测单元的可测试性？何时停止测试？挑选合适的单元模块进行测试适合测试单元的标准： –高内聚、低耦合 –由1-3个开发人员完成，最好是1个 –不直接访问网络、数据库、文件系统单元测试用例设计单元测试既可以是白盒测试也可以是黑盒测试白盒（基于覆盖率的用例设计）语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖、基本路径覆盖等黑盒规格导出、等价类划分、边界值分析、错误推测、因果图等Right-BICEP方法Right--结果是否正确？B--是否所有的边界条件都是正确的？I--能查一下反向关联吗？C--能用其他手段交叉检查一下结果吗？E--是否可以强制错误条件发生？P--是否满足性能要求？

如何实施单元测试挑选单元测试范围分层的单元测试个人、组长、QA

“当你试图打印输出一些信息或调试一个表达式时，写一些测试代码来替代那些传统的方法。”-Martin

FowlerJava单元测试项目案例分析JPetStore单元测试代码分析集成测试集成的类型函数集成、类集成、组件集成、子系统集成集成测试策略大爆炸集成自顶向下集成自底向上集成三明治集成…单元测试与集成测试内存泄漏问题检测内存泄漏现象Java内存泄漏检测工具JconsoleJprofilerWASTPV监控JVM发现内存泄漏现象JConsole实时监控JVMJprofiler-JAVA代码执行效率监控分析Jprofiler–SQL性能TestMemJprofiler–内存泄漏检测案例主题1白盒测试知识体系2如何开展实施白盒测试项目3静态白盒测试方法4动态白盒测试方法5持续集成持续集成持续集成是一项软件开发实践，它鼓励团队成员频繁集成他们的工作，每次集成都通过自动化构建来验证。持续集成可用于确保你的软件一直是可以工作的，并且在几分钟内你就能够得到关于“你的修改是否破坏了系统”的反馈。

持续集成过程持续编译持续部署持续测试持续报告《持续集成:软件质量改进和风险降低之道》第18届Jolt震撼大奖图书从一个Java项目的持续集成系统和脚本看持续集成的基本步骤所有最新代码从配置管理工具中取出（checkout或者update）所有的代码从干净的状态开始编译将编译结果链接并部署，以备执行执行部署的应用并运行测试如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，我们认为这才是一次成功的构建MartinFowler持续集成标准流程持续编译持续检查持续验证持续部署持续基础设施持续报告持续编译持续编译是一个很朴素的想法，就是保证主线上的代码始终处于可编译的状态。但是这对于很多大中型团队来说却并非想当然的简单。这是因为很多团队并未采用集体代码所有权策略，导致存在依赖的团队的代码无法编译。针对这样的问题，一方面我们建议采用集体代码所有权；另一方面，对于确实因为安全原因需要隔离的代码应该明确边界、接口，很少存在大部分代码需要对大部分人保密的情况。持续检查持续检查的目的是保证代码风格一致，主要关注于代码的静态质量和内部质量，比如变量命名方式、大括号位置等等。大部分的现代集成开发环境（IDE）都具备实时检查代码质量的功能。为了保证主线上的代码质量能够达到一致的标准，应当在持续集成脚本中加入静态检查阶段。比如，Java的PMD、FindBugs等等。持续验证持续验证的目的是检查主线上的代码是否能够实现所要求的功能，或者已有的功能是否被破坏。在大部分的构建中，验证部分是耗时最长、成本最高的部分，但同时也是收益最大的部分。在这个阶段，我们看到的主要问题是验证不充分和验证时间过长。针对这样的问题，我们通常采用分层分级的持续集成策略。持续部署对于大型软件应用来说，部署往往是一个费时费力又容易出错的步骤，因为这里面涉及到数据迁移、版本兼容等各种棘手的问题。持续部署的思想是将这些工作标准化自动化，使其能够可靠地、自动地、快速地运行。持续基础设施集成现代大型软件开发，尤其是互联网应用开发中经常依赖于一些常见的基础设施——比如Spring、Tomcat、Database等等。这些基础设施发生变化的时候，我们应当及时地触发持续集成，以确保我们的系统是能够与新的基础设施一起工作的。持续报告报告是将持续集成的状态以适当的形式展现给干系人的基本手段。报告是持续集成的晴雨表，所以它必须直观、易懂，而且对关注点不同的角色展现不同的内容和粒度。比如，开发人员可能更关心错误的日志；项目经理可能更关心测试覆盖率；产品经理可能更关心持续集成通过率的趋势等等。持续集成的基本原则CreateaRepeatable,ReliableProcessforReleasingSoftware尽早集成、经常集成任何人都可以找一台干净的机器，做一次checkout动作，然后对系统执行一次完整的构建持续集成的目的是为了沟通-每个人都能看到进度（EveryoneCanSeeWhat'sHappening）持续集成工具与框架CruiseControlHudson、JenkinsTeamCitySonar持续质量度量平台Sonar的架构Sonar与持续集成框架的整合(SVN、Jenkins)Sonar的标准度量项基于Sonar构建Java质量度量平台代码分析与规则定制代码测试覆盖率度量评估质量趋势查看Sonar质量报告Sonar插件与生态系统质量的七个纬度IcdnuoltblveieetahtIcluodaculacltyuesdnatnrdwahtIwasrdgnieg.Thephaonmneal

pweorofthehmuanmnid.Itdeosn‘tmttaeri