（三）白盒测试的测试用例设计
白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有6种:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。
为了提高测试的效率，应选择最少的测试用例来满足指定的覆盖标准。
1.语句覆盖
语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。
2.判定覆盖
判定覆盖又称为分支覆盖。它是指选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次（即判定的每个分支至少经过一次）。
3.条件覆盖
在软件设计过程中，一个判定往往由多个条件组成，判定覆盖仅考虑了判定的结果而没有考虑每个条件的可能结果。
条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中的每个条件的所有可能结果至少出现一次。
4.判定/条件覆盖
判定/条件覆盖是指选择足够的测试用例。使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果至少出现一次。
显然，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖标准。在某些程序的测试中，如果选择得好，判定覆盖、条件覆盖和判定/条件覆盖可以使用相同的最少的测试用例。
5.条件组合覆盖
在条件覆盖中考虑了判定中每个条件的所有可能结果，但并未考虑条件的组合情况。条件组合覆盖是指选择足够的测试用例，使得运行这些测试用例时，每个判定中条件结果的所有可能组合至少出现一次。
由于条件组合覆盖使每个判定中条件结果的所有可能组合都至少出现一次，因此判定本身的所有可能结果也一定至少出现一次，同时也使每个条件的所有可能结果至少出现一次。因此，条件组合覆盖是上述5种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都被覆盖。
6.路径覆盖
路径覆盖是指选择足够的测试用例，使得运行这些测试用例时，程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路至少经过一次）。
路径覆盖实际上是考虑了程序中各种判定结果的所有可能组合，但它并未考虑判定中的条件结果的组合，因此它是一种比较强的覆盖标准，但并不能代替条件覆盖和条件组合覆盖。
（四）黑盒测试的测试用例设计简介
黑盒测试是根据规格说明所规定的功能来设计测试用例，它不考虑程序中的内部结构和处理过程。常用的黑盒测试技术有等价类划分、边值分析、错误猜测等。
1.等价类划分
前面已经讲过，不能穷举所有可能的输入数据来进行测试，所以只能选取少量有代表性的输入数据，来揭露尽可能多的程序错误。
这里首先要介绍一个有效的输入数据和无效的输入数据。有效的输入数据是指符合规格说明要求的合理的输入数据，它主要用来检验程序是否实现了规格说明中的功能。无效的输入数据是指不符合规格说明要求的不合理或非法的输入数据，它主要用来检验程序是否做了规格说明以外的事。
如果把所有可能的输入数据（有效的和无效的）划分成若干个等价类，那么可以合理地做出假定:如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误;反之，如果一个输入数据不能检测出某个错误，那么等价类中其他输入数据也不能发现这一错误（除非这个等价类的某个子集还属于另一等价类）。
等价类划分方法首先把输入数据划分成若干个有效等价类和若干个无效等价类，然后设计测试用例覆盖这些等价类。
2.边值分析
大量的实践说明，程序中在处理边界情况时出错的概率比较大，因此设计一些测试用例，使程序运行在边界情况附近，这样揭露程序中错误的可能性就更大。
所谓边界条件是指相对于输入与输出等价类直接在其边界上，或稍高于其边界，或稍低于其边界的这些状态条件。
使用等价类划分方法设计测试用例时，原则上讲，等价类中的任一输入数据都可作为该等价类的代表用作测试用例。而边值分析则是专门挑选那些位于边界附近的值作为测试用例。由于边值分析方法所设计的测试用例，更有可能发现程序中的错误，因此经常把边值分析方法与其他设计测试用例方法结合起来使用。
3.错误猜测
错误猜测是一种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例的方法。这种方法没有机械的执行步骤，主要依靠直觉和经验。
四、软件维护
软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期，它是在软件交付使用后，为了改正软件中隐藏的错误，或者为了使软件适应新的环境，或者为了扩充和完善软件的功能或性能而修改软件的过程。一个软件的开发时间可能需要一两年，但它的使用时间可能要几年或几十年，而整个使用期都可能需要进行软件维护，所以软件维护的代价是很大的，而且维护的代价还在逐年上升，据1994年Software Engineering Encyclopedia记载，在整个软件生存周期所花费的代价中，20世纪80年代末用于软件维护的代价约为75%到90年代初为90%。因此，如何提高软件维护的效率、降低维护的代价成为十分重要的问题。
（一）软件维护的分类
根据引用软件维护的原因，软件维护通常可分成改正性维护、适应性维护、完善性维护、预防性维护。
1.改正性维护
由于程序正确性证明尚未得到圆满的解决，软件测试又不可能找出程序中的所有错误，因此，在交付使用的软件中都可能隐藏着某些尚未被发现的错误，而这些错误在某种使用环境下会暴露出来。改正性维护就是在使用过程中发现了隐藏的错误后，为了诊断和改正这些隐藏错误而修改软件的活动。
2.适应性维护
由于计算机的发展非常迅速，新的机型、新的操作系统、新的软件系统不断地涌现，为了适应计算机的飞速发展，可能要更正在运行的软件的运行环境，如新的机型、数据库管理系统等。适应性维护就是为了适应变化了的环境而修改软件的活动。
3.完善性维
护用户在使用软件的过程中，随着业务的发展，常常希望扩充原有软件的功能，或者希望改进原有的功能或性能，以满足用户的新要求，完善性维护就是为了扩充或完善原有软件的功能或性能而修改软件的活动。
4.预防性维护
软件维护活动主要是上述三类维护，另有一类维护称为预防性维护，它是为了提高软件的可维护性和可靠性，为未来的进一步改进打下基础而修改软件的活动。
据有关资料统计，在整个软件维护活动中，改正性维护约占20%，适应性维护约占25%，完善性维护约占50%以上，其他维护约占4%。
（二）与软件维护有关的问题
软件维护人员通常不是该软件的开发人员，这给软件维护带来很大的困难，特别是有些软件在开发时没有遵循软件开发的准则，没有开发方法的支持，维护这样的软件就更困难。下面列举一些与软件维护有关的问题。
（1）要维护一个软件，首先要理解它。而理解别人的程序通常是非常困难的，尤其是对软件配置（指各种文档）不齐的软件，理解起来更为困难。
（2）需要维护的软件往往缺少合格的文档，或者文档资料不齐，甚至没有文档。在软件维护中，合格的文档十分重要，它有助于理解被维护的软件。合格的文档不仅要完整正确地反映开发过程各阶段的工作结果，而且应该容易理解并应程序源代码一致。而错误的文档会把对程序的理解引入歧途。
（3）在软件维护时，不要指望得到原来开发该软件的人员的帮助。开发人员开发完一个软件后，往往去从事另一软件的开发，甚至已调离开发单位。即使原先的开发人员还在，也可能因为相隔时间太久而遗忘了实现的细节。
（4）多数软件在设计时没有考虑今后的修改，给软件的修改带来困难，而且在修改软件时容易带来新的差错。对那些缺乏模块独立性和非结构化的程序来说，更是如此。
（5）软件维护通常不是一件吸引人的工作。从事维护工作常使维护人员感到缺乏成就感。这也严重影响维护工作，从而导致维护质量的不高。
可以看出，上述的有些问题都与被维护的质量密切相关，所以在开发软件时，要认真写好各类文档，并且应注意提高软件的可维护性，这样可在很大程序上缓解软件维护的困难。
（三）可维护性
软件可维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件可维护性的因素有可理解性、可测试性和可修改性。
1.可理解性
2.可测试性
可测试性是指测试和诊断软件（主要指程序）中错误的难易程度。
测试主要是发现软件中的错误，而诊断错误的性质和出错的位置通常是调试的任务。
提高软件可测试性的措施有:书写详细正确的文档，采用良好的程序结构，使用测试工具和调试工具，保存以前的测试过程和测试用例等等。
3.可修改性
可修改性是指修改软件（主要指程序）的难易程度。
在修改程序时经常会发生这样的情况:修改程序中某个错误的同时又产生新的错误（由程序的修改引起的），或者在程序中增加了某个功能的同时，原先的某些功能不能正常执行。这主要是因为程序中各成分之间存在着许多联系，当程序中某处修改时，这个修改可能会影响到程序的其他部分。如果修改程序时稍有考虑不周，就会出现上述顾此失彼的情况。因此，如果一处修改所涉及到的范围越少，发生上述情况的概率也越小，其可修改性也越好。
在软件设计中我们介绍的那些设计准则都是影响可修改性的因素，如信息隐蔽原则、模块独立、模块间联系的低耦合高内聚等等。
（四）软件维护活动流程
凡是需要软件维护，都应有一个软件维护的申请报告。改正性维护的申请报告应完整地描述导致错误的环境，包括输入数据、错误清单以及有关的材料。适应性维护或完善性维护的申请报告应提供一份简短的需求说明书。维护申请书由维护管理员和系统管理员审批。并指明所需修改的性质，申请修改的优先级，所需的工作量等。
维护活动的第一步是确定维护的类型，若是改正性维护，则要估计错误的严重程度，对严重的错误，则马上分派人员执行维护任务;对不严重的错误，则可将其暂时保存，在以后适当时候再进行改正。若是适应性维护或完善性维护，则要根据其优先级来决定维护的先后次序，优先级高的维护则马上开始，优先级低的可暂时保存，以便统筹安排。适应性维护或完善性维护的过程相当于一个小的开发过程，它同样要经历需求分析、设计、编码、测试等阶段。
不管是哪种维护，有些工作是每种维护活动都必须做的，如在修改程序代码的同时还要修改（如有必要）相应的需求说明文档、设计文档等，还要进行回归测试和软件配置复审等。
