课程资源软件构造7代码改善

本章主要内容软件质量的特性协同构建开发者测试调试重构重点部分开发者测试的相关概念和技术软件质量的特性软件同时拥有外在的和内在的质量特性外在特性指的是该产品的⽤户所能够感受到的部分质量的外在特性是⽤户关⼼的唯⼀软件特性，指软件是否容易使⽤和正确运⾏内在特性软件内部结构、组织所体现出来的特性软件在代码层次上具有的特性正确性，指系统规范、设 ⽅⾯的错误的稀少程易⽤性（Usability），指⽤户学习和使⽤⼀个系统的容易程度适应性，指为特定的应⽤或者环境设计的系统，在不做修改的情况完整性，指系统阻⽌对程序或者数据进 验证或者不正 的⼒限 ⽤户例如：保证那些保存着并⾏数据的表格能够正确地并⾏修改，确保⽇期字段⼀定含有效的⽇期，等等精确性，指对于⼀个已经开发出的系统，输出结果的误差程度，尤其在精确性和正确性的不同在于，前者是⽤来判断系统完成⼯作的优劣程 提⾼性能，以及修正缺陷灵活性，指假如⼀个系统是为特定⽤途或者环境⽽设计的，那么当该系统被⽤于其他⽬的或者环境的时候，需要对系统做修改的程度可移植性，指为了在原来设计的特定环境之外运⾏，对系统所进⾏可重⽤性，指系统的某些部分可被应⽤到其他系统中的程度，以及可读性，指阅读并理解系统代码的难易程度，尤其是在细节语可测试性，指的是你可以进⾏何种程度的单元测试或者系统测试，以及在何种程度上验证系统是否符合需求可理解性，指在系统组织和细节语句的层次上理解整个系统的内在和外在特性并不能完全割裂开来在某些层次上，内在特性会影响某些外在特性某些特性强调软件要让⽤户⽤起来⽅便，⽽另⼀些特性则强调软件要让程序员 起来⽅便要让所有特性都能表现 是绝⽆可能的要弄清楚的问题是:哪⼀种特性是什么，什么时候这些特性之间会发⽣什么样的相互作⽤质量特性之间的典型关系明 ⽬标确定质量保证活动测试策略软件⼯程指南技术检查GeraldWeinberg和EdwardSchulman试验，以研究设⽴质量⽬标ྯ ؙਂ๋๋ ๋ ؙ144255115332234๋ 25313๋ 43541程序员有着较⾼的成功动机，他们会按所要求的⽬标去作，但是他们必须知ྯṈ ֗ྯ ྯ ྯᦡᦇ༄ᦡᦇ༄ᦡᦇ༄ᦡᦇ༄ྋਂդᎱ༄ ՈૡդᎱ༄ ྯၥᦶҁਂ

错误留在系统中的时间越长，将其除去所花的代价也越⼤能较早发现错误的⽅法将导致低的错误改正代价从总体上看，⼀步⽅法要⽐⼆步⽅法更为合算如⼈⼯检查，⼀步就可完成发现和改正错误的全过程如测试，在发现错误之后还需另外的⼯作以分析和改正错误需求>设计>对系统关键部分的正式设计检查使⽤快速原型化技术进⾏模块化或原型化代码阅读或检查L0:WhileTruedoendwhile||

Initially:Initially:THESTATE

[]¬(PC0=CR0/

[](TURN=0--

协同构建涉及到多种技术协同构建的基本出发点：在⼯作中开发⼈员总会对某些错误点视⽽不见，⽽其他⼈不会有相同的盲点，所以开发⼈员让其他⼈来检查⾃⼰的⼯作包括结对编程、正式检查、⾮正式技术复查、⽂档阅读，以及其他让开发⼈员共同承担创建代码及其他⼯作产品责任的技术所有的协同构建技术都试图通过这样或那样的途径，将展⽰你⼯作的过程正式化，以便把错 出来有利于传授公司⽂化以及编程专业知识集体 适⽤于所有形式的协同构建众⼈检查与协⼒编写，可以使代码的质量变得更好。个⼈对项⽬所造成的影响更⼩了。总体上缺陷修正周期变短了在进⾏结对编程的时候，⼀位程序员敲代码，另外⼀位注意有没有出现错误，并考虑某些策略性的问题例如代码的编写是否正确，正在编写的代码是否所需等结对编程最初是由极限编程（ExtremeProgramming）所普及尝试对风格进⾏标准化以便程序员将精⼒集中到"本质"不掌握键盘的那个⼈应该分析代码，提前思考接下来的代码应该做些什么，对设计进⾏评估，并对如何测试代码做出计划正式检查（FORMAL详查(正式检查)是⼀种特殊的复查，种种迹象表明它在侦测缺陷⽅⾯特别有复查⼈贝要为详查会议做好预先准备，并且带来⼀份他们所发现的⼰知问题详查的⼀个关键特征就是每个⼈都要扮演某⼀个明确的⾓⾊：又能发现尽可能多的错误作者，直接参与设计或者代码的⼈，这种⼈在详查中扮演相对，同设计和代码有直接关系，但又不是作者的⼈记录员，将详查会议期间发现的错误，以及指派的任务记录下独⽴的详查通常能够捕捉到60%设计和代码的联合详查通常能够去除产品中70%到85%，甚⾄是详查还可以⽤来评估进度技术层⾯的⼯作是否已经完成？以及技术层⾯的⼯作是否完成计划 概述 准备每- 详查的⼀般步骤-续当记录员将错误的类型和严重程度记录下来之后，详查⼯作继详查的⼀般步骤-续列出每⼀个缺陷，包括它的类型和严重级别主持⼈将缺陷分配给某⼈来修复，这个⼈通常是作者得到任务的⼈负责修正列表中的每个缺陷主持⼈负责监督在详查过程中分配的返⼯任务与结对编程相⽐，其他类型的协作⽅法还没有积累⾜够的实践经⾛查（WALK-⾛查是⼀种很灵活的复查⽅式它可能如同⼀个在⽩板前⾯的随兴闲聊那样不正式也可以如同⼀个计划好的会议⼀样正式•可以肯定的是，⾛查会涉及两个或者 的⼈，进⾏设计或者•良好的⾛查可以得到与正式检查相类似的结果可以找到程序中20%到40%但是⼀般⽽⾔，⾛查远没有详查来得有效如果有个很⼤的复查团队，那么⾛查是⼀种不错的复查⽅式如果有其他组织的评审员参与进来，那么⾛查或许会更好NASA软件工NASA软件工个错误(Card代码阅读是详查和⾛查的另⼀种替代⽅案直接阅读原代码并从中找出错误同时你也从质量的⾓度对代码做出评价•在会议的准备阶段，代码的作者将源代码分发给代码阅读⼈员。这份代码 的长度在 ⾏到 ⾏之间，4000⾏是典型的长度。两个以上的⼈阅读代码。独⽴地进⾏代码阅读。 结束代码阅读之后，由代码的作者组织召开代码阅读会议代码的作者 识别出来的问题⼀⼀修正代码阅读与详查、⾛查之间的区别代码阅 地关注对代码进⾏的独⽴复查，⽽不是关注会议本⾝对于⼈员所处地理位置分散的情况，代码阅读尤其有价值公开演⽰（DOG-AND-PONY公开演⽰向客户展⽰软件产品的另⼀种复查形式公开演⽰的⽬的是向客户证明项⽬⼀切顺利此这是⼀种管理层的复查，⽽不是技术复查要改善技术品质应当依靠详查、⾛查或者代码阅读非正式复查（走查是是否是否是否非正式复查（走查是是否是否是否是是40%-45%-20%-协同开发实践往往能⽐测试发 的缺陷协同开发实践所发现错误的类型通常跟测试所发现的不同正式检查往往能⽐⾛查发 的缺陷正式检查可以应⽤在除代码之外的很多⼯作成果上，例如需求、结对编程拥有和详查相同的成本，并能产⽣质量相当的代码。测试是最常见的改善质量的活动⿊盒测试(black-boxtesting)，指的是测试者⽆法了解测试对象⽩盒测试(white-boxtesting)，指的是测试者清楚待测试对象内⽩盒测试通常由开发⼈员进⾏，⽽⿊盒测试则由专门的测试⼈单元测试(Unit将⼀个程序员或者⼀个开发团队所编写的，⼀个完整的类、⼦程序或者⼩程序，从完整的系统中 出来进⾏测试组件测试(Component将⼀个类、包、⼩程序或者其他程序元素，从⼀个更加完整的系统中 出来进⾏测试这些被测代码涉及到多个程序员或者多个团队常见的测试-续集成测试(Integration 回归测试(Regression系统测试(System通常包括单元测试、组件测试和集成测试有的时候还会包括回归测试和系统测试由专门的测试⼈员进⾏的测试主要包括beta测试、客户验收测试、性能测试、配置测试、平台测试、压⼒测试以及易⽤性测试等测试的特殊性测试的⽬标与其他开发活动背道⽽驰，测试的⽬标是找出错误测 不可能彻底证明程序中没有错误测试本⾝并不能改善软件的质量测试时要求你假设会在代码⾥⾯找到错误开发者测试所占的时间对每⼀项相关的需求进⾏测试，以确保需求都已经被对每⼀个相关的设计关注点进⾏测试，以确保设计已经被实现。⽤基础测试和数据流测试来补充测试⽤例使⽤⼀个检查表⾸先写测试⽤例最直接地，可以⽤这个结果来评估正在开发的产品的可靠性可以⽤于指导对软件的修正测试发现缺陷的记录有助于归纳出程序中最常见错误指引今后的技术复查活动，设计未来的测试⽤例开发者测试倾向于“⼲净测试开发⼈员往往去做⼀些检验代码能否⼯作的测试(⼲净测试，cleantests)，⽽不是做所有可能让代码失效的测试(肮脏测试，dirtytests)程序员坚信95%，事实上平均约50%-语句覆盖率->对程序的每种可能的情况都进⾏测试对程序的每⼀种可能的输⼊值，以及它们之间的所有可以想象 和地址都是20个字符长度，每⼀个字符有26个可选的字名字 2620(20个字符，每个字符有26种选择地址 2620(20个字符，每个字符有26种选择：1010(10个数字，每⼀个数字有10种选择2620*2620*1010由于进⾏完全测试实际上是不可能的，因此测试的窍门就在于选择那些最有可能找到错误的测试⽤例当规划测试的时候，要去除那些不会告诉你任何新情况的测试使⽤不同的⽅法来有效地覆盖程序基本情况2620*2620*1010以最⼩数量的测试⽤例覆盖所有路径（和⼀般意义的程序路径不同）最简单的⽅法就是算⼀算有多少条通过程序的路径，然后据此开发出能通过程序⾥每条路径的最少数量的测试⽤例基础测试⽤例最少数量的简单计算⽅法：对通过⼦程序的直路，开始的时候记遇到下⾯的每个关键字或者其等价物时加if、while、repeat、for、and以及or遇到每⼀个case语句就加1，如果case语句没有缺省情况，则再加1if(x<10)

⼦程序本⾝记}

遇到if记2（加1、由if控制的语句执⾏(x<2、由if控制的语句不执⾏(x>=//computenetpaytotalWithholdings=0;for(id=0;id<numEmployees;id++)

⼦程序本⾝记for语句记//computesocialsecuritywithholding,ifbelow if(m_employee[id]. ernmentRetirementWithheld< T_RETIREMENT){

if语句记ernmentRetirement= ernmentRetirement(m_employee[id]}//setdefaulttonoretirementcontributionRetirement=0;//determinediscretionaryemployeeretirementcontributionif(m_employee[id].WantsRetirement&&EligibleForRetirement(m_employee[id])){Retirement=GetRetirement(m_employee[id]

if语句记4&&记}grossPay=ComputeGrossPay(m_employee[id]//determineIRAcontributionalRetirement=if(

alRetirement(m_employee[id]))

if语句记alRetirement alRetirementContribution(m_employee[idRetirement,grossPay}//makeweeklywithholding=ComputeWithholding(m_employee[id]);netPay=grossPay-withholding- ernmentRetirementernmentRetirementPayEmployee(m_employee[id],netPay

//addthisemployee'spaychecktototalforaccountingtotalWithholdings=totalWithholdings+withholding;ernmentRetirementernmentRetirement=

ernmentRetirementtotalRetirement=totalRetirement}

SavePayRecords(totalWithholdings, ernmentRetirement,totalRetirement要覆盖所有的基本情况⾄少需要6这并不意味着任意6个测试⽤例都能覆盖所有的基本情况。注意那些导致你⽤例数量增加的关键字代码中的每⼀个关键字都描述了⾮真 情况因此，需要确保对每⼀种真的情况⾄少有⼀个测试⽤例，对每⼀种 情况也⾄少有⼀个测试⽤例覆盖例⼦中所有基本情况的测试⽤例12初始fornumEmployees<3ifm_employee[id].ernmentRetirementWith-held>=MAX_T_RETIREMENT4笫二个ifand之前的部分为假，结果为假notm_employee[id5笫二个ifand后半部分为notEligibleForRetirement(m_employee[id]6笫三个ifnotEligibleForalRetirement(m_employee[id测试覆盖率：⽤于确定测试所执⾏到的覆盖项的百分⽐。其中的覆盖项是指作为测试基础的⼀个⼊⼜或属性，⽐如语句、分⽀、条件等。测试覆盖率可以表⽰出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越⾼效果越好。但覆盖率不是⽬标，只是功能点覆盖率⼤致⽤于表⽰软件已经实现的功能与软件需要实现的功结构覆盖率包括语句覆盖率、判定覆盖率、条件覆盖率、判定条件覆盖率、组合覆盖率和路径覆盖率等。语句覆盖：选择⾜够多的测试⽤例，使得程序中的每个可执⾏语句⾄少执⾏⼀次。判定覆盖：通过执⾏⾜够的测试⽤例，使得程序中的每个判定⾄少都获得⼀次真值和假值，也就是使程序中的每个取真分⽀和取假分⽀⾄少均经历⼀次，也称为“分⽀覆盖”。条件覆盖：设计⾜够多的测试⽤例，使得程序中每个判定包含的每个条件的可能取值（真假）都⾄少满⾜⼀次。逻辑覆盖法（续判定/条件覆盖：设计⾜够多的测试⽤例，使得程序中每个判定包含的每个条件的所有情况（真/假）⾄少出现⼀次，并且每个判定本⾝的判定结果（真/假）也⾄少出现⼀次。——满⾜判定条件覆盖的测试⽤例⼀定同时满⾜判定覆盖和条件覆组合覆盖：通过执⾏⾜够的测试⽤例，使得程序中每个判定的所有可能的条件取值组合都⾄少出现⼀次。——满⾜组合覆盖的测试⽤例⼀定满⾜判定覆盖、条件覆盖和判定路径覆盖：设计⾜够多的测试⽤例，要求覆盖程序中所有可能的路逻辑覆盖法（续逻辑覆盖法（续void DoWork(intx,inty,int{intk=0,j=0; 语句块aif((x>3)&&(z<10)) k=x*y-j=sqrt(k); 语句块}if((x==4)||(y>5){j=x*y+10; j=j%3;}

语句块语句块语句块要实现DoWork函数的语句覆盖，只需设计⼀个测试⽤例就可以覆盖程序中的所有可执⾏语句。测试⽤例输⼊为：{x=4、y=5、z=5}程序执⾏的路径是：abd语句覆盖可以保证程序中的每个语句都得到执⾏，但发现例如在第⼀个判定((x>3)&&(z<10))中把&&错误的写成了“||”，这时仍使⽤该测试⽤例，则程序仍会按照流程图上的路径abd执⾏。可以说语句覆盖是最弱的逻辑覆盖准则。要实现DoWork函数的判定覆盖，需要设计两个测试⽤例。测试⽤例的输⼊为：{x=4、y=5、z=5}；{x=2、y=5、z=5}程序执⾏的路径分别是：abd；ace上述两个测试⽤例不仅满⾜了判定覆盖，同时还做到语句覆盖。从这点看似乎判定覆盖⽐语句覆盖更强⼀些，但仍然⽆法确定判定内部条件的错误。例如把第⼆个判定中的条件y>5错误写为y<5，使⽤上述测试⽤例，照样能按原路径执⾏⽽不影响结果。因此，需要有更强的逻辑覆盖准则去检验判定内的判定覆盖（续在实际程序代码中，⼀个判定中通常都包含若⼲条件。条件覆盖的⽬的是设计若⼲测试⽤例，在执⾏被测程序后，要使每个判定中每个条件的可能值⾄少满⾜⼀次。对DoWork函数的各个判定的各种条件取值加以标记。对于第⼀个判定x>3)&&(z<10条件x>3 取真值记为T1，取假值记为-条件z<10取真值记为T2，取假值记为-对于第⼆个判定((x==4)||(y>5))：条件x==4 取真值记为T3，取假值记为-条件y>5 取真值记为T4，取假值记为-条件覆盖（续根据条件覆盖的基本思想，要使上述4个条件可能产⽣的8种情况⾄少满⾜⼀次，设计测试⽤例如下：x=4、y=6、abdbdx=2、y=5分析：上⾯这组测试⽤例不但覆盖了4个条件的全部8种情况，⽽且将两个判定的4个分⽀b、c、d、e也同时覆盖了，即同时达到了条件覆盖和判定覆盖。条件覆盖（续说明：虽然前⾯的⼀组测试⽤例同时达到了条件覆盖和判定覆盖，但是，并不是说满⾜条件覆盖就⼀定能满⾜判定覆盖。如果设计了下表中的这组测试⽤例，则虽然满⾜了条件覆盖，但只是覆盖了程序中第⼀个判定的取假分⽀c和第⼆个判定的取真分⽀d，不满⾜判定覆盖的要求。x=2、y=6、x=4、y=5、判定条件覆盖实际上是将判定覆盖和条件覆盖结合起来的⼀种⽅法，即：设计⾜够的测试⽤例，使得判定中每个条件的所有可能取值⾄少满⾜⼀次，同时每个判定的可能结果也⾄少出现⼀次。根据判定条件覆盖的基本思想，只需设计以下两个测试⽤例便可以覆盖4个条件的8种取值以及4个判定分⽀。x=4、y=6、abdbdx=2、y=5、判定/条件覆盖（续分析：从表⾯上看，判定/条件覆盖测试了各个判定中的所有条件的取值，但实际上，编译器在检查含有多个条件的逻辑表达式时，某些情况下的某些条件将会被其它条件所掩盖。因此，判定/条件覆盖也不⼀定能够完全检查出逻辑表达式中的错误。例如：对于第⼀个判定(x>3)&&(z<10)来说，必须x>3和z<10这两个条件同时满⾜才能确定该判定为真。如果x>3为假，则编译器将不再检查z<10这个条件，那么即使这个条件有错也⽆法被发现。对于第⼆个判定(x==4)||(y>5)来说，若条件x==4满⾜，就认为该判定为真，这时将不会再检查y>5，那么同样也⽆法发现这个条件中的错误。组合覆盖的⽬的是要使设计的测试⽤例能覆盖每⼀个判定的所有可能的条件取值组合。对DoWork函数中的各个判定的条件取值组合加以标记：1、x>3,2、x>3,z>=103、x<=3,

记做T1T2记做T1-T2，第⼀个判定的取假分记做-T1T2，第⼀个判定的取假分4、x<=3,z>=10 记做-T1-T2，第⼀个判定的取假分5、x==4,y>56、x==4,y<=57、x!=4,y>58、x!=4,y<=5

记做T3T4，第⼆个判定的取真分记做T3-T4，第⼆个判定的取真分⽀记做-T3T4，第⼆个判定的取真分⽀记做-T3-T4，第⼆个判定的取假分组合覆盖（续根据组合覆盖的基本思想，设计测试⽤例如下：x=4、y=6、abd1和x=4、y=5、2和x=2、y=6、3和x=2、y=5、4和分析：上⾯这组测试⽤例覆盖了所有8种条件取值的组合，覆盖了所有判定的真假分⽀，但是却丢失了⼀条路径abe。前⾯提到的5种逻辑覆盖都未涉及到路径的覆盖。事实上，只有当程序中的每⼀条路径都受到了检验，才能使程序受到全⾯检验。路径覆盖的⽬的就是要使设计的测试⽤例能覆盖被测程序中所有可能的路径。根据路径覆盖的基本思想，在满⾜组合覆盖的测试⽤例中修改其中⼀个测试⽤例，则可以实现路径覆盖：x=4、y=6、abdx=4、y=5、x=2、y=5、x=5、y=5、路径覆盖（续分析：虽然前⾯⼀组测试⽤例满⾜了路径覆盖，但并没有覆盖程序中所有的条件组合（丢失了组合3和7），即满⾜路径覆盖的测试⽤例并不⼀定满⾜组合覆盖。对于⽐较简单的⼩程序，实现路径覆盖是可能做到的。但如果程序中出现较多判断和较多循环，可能的路径数⽬将会急剧增长，要在测试中覆盖所有的路径是⽆法实现的。为了解决这个难题，只有把覆盖路径数量压缩到⼀定的限度内，如程序中的循环体只执⾏⼀次。在实际测试中，即使对于路径数很有限的程序已经做到路径覆盖，仍在结构化的基础测试中考虑的主要是结构这种测试能够向你保证所有的代码都得到执⾏，但它并不能说明⾸先，对代码的执⾏的覆盖是分割进⾏的其次，对逻辑控制选择的覆盖也是分割进⾏的数据流测试基于如下观点：数据使⽤的出错⼏率⾄少不低于控制流BorisBeizer声称全部代码中⾄少有⼀半是数 和初始(Beizer编写数据流测试⽤例的关键编写数据流测试⽤例的关键是要对所有可能的定义-⼰定义已使⽤数据已经⽤于计算，或作为某⼦程序调⽤的⼀个参数，或者⽤于其⼰销毁已进⼊控制流已经进⼊⼀个⼦程序，但还没有使⽤该变量已退出在对变量产⽣影响之后，控制流⽴即退出⼦程序描述对变量进⾏某种操作之前或之后，控制流进⼊或退出某个⼦程序的正常的数据状态的组合正常的数据状态的组合是变量⼰定义，已经⼀次或多次使⽤，并且可⼰定义-⼰定已进⼊-已销⼰进⼊-已使已销毁-已销测试每⼀个变量的每⼀个定义（在每个变量被赋值的地⽅注：这是⼀个很弱的策略，因为如果你曾经尝试对每⼀⾏代