设计篇

第17回 测试项目的管理原则

软件开发项目的成败，取决于 “过程、人、技术” 这三方面的水平和协调，过程是基础、人是核心，而技术是保证，

三方面相互制约，又相互促进。哪一方面没能跟上，形成薄弱环节，项目成功的可能性就会变小。测试项目也不例外，需要从这三方面一起抓。特别是软件测试，流程定义的科学性与规范性、流程执行的严格性、人员的高度责任感等都是至关重要的。

其次，对如今测试项目的管理，要对软件开发有一个全局的、正确的认识，按照 V模型可以更好地理解需求和确认、设计实现和验证等之间的关系，详见 --> 第1回 V模型，我的完整诠释

再者，项目管理有三个要素——成本、进度和质量。对于软件测试项目的管理，成本和进度不应忽视，重视测试的策略以提高效率，随时跟踪项目尽量确保项目按计划执行。但更重要的是 “质量”，软件测试经理对产品质量负有更多的责任。

最后，软件测试项目的过程管理能否成功，还受到三个核心层面的影响，即项目组内环境、项目所处的组织环境、整个开发流程所控制的全局环境。这三个环境要素直接关系到软件项目的可控性。项目组管理与项目过程模型、组织支撑环境和项目管理接口是上述三个环境中各自的核心要素。

软件测试项目管理是软件工程的保护性活动。它先于任何测试活动之前而开始，且持续贯穿于整个测试项目的定义、计划和测试之中。为了保证测试项目过程的成功管理，在上述4点基本认识的基础上，坚持下列的测试项目管理原则是非常必要的:

1. 始终能够把质量放在第一位，测试工作的根本在于保证产品的质量，应该在测试小组中建立起“质量是企业生存之本”的观念，建立一套相适应的质量责任制度。
2. 可靠的需求。应当有一个经各方一致同意的、清楚的、完整的、详细的和切实可行的需求定义。 能够制定好测试策略、有计划地安排工作、系统的解决方案、制定合理的时间表。为测试计划、测试用例设计、测试执行（特别是系统测试）以及它们的评审等留出足够的时间，不应使用突击的办法来完成项目。
3. 足够重视测试计划，在测试计划里清楚地描述测试目标、测试范围、测试风险、测试手段和测试环境等。
4. 测试用例是测试执行的基础，测试用例设计前，要充分和开发人员、产品经理等讨论清楚，要进行集体审查，确保其高覆盖率。并注意其不断完善。
5. 要适当地引入测试自动化或测试工具，前期准备工作要充分，不能盲目。
6. 对测试环境不能掉以轻心，要和有关人员审查环境的软、硬件的配置。
7. 充分测试并尽早测试。每次改错或变更后，都应重新测试。项目计划中要为改错、再测试、变更留出足够时间。
8. 遇到问题，能准确地判断是技术问题还是流程问题，更关注流程上的问题，从而在根本上解决问题，而不是治标不治本。
9. 全程跟踪缺陷状态，及时对缺陷状态进行分析、清理。
10. 通用项目管理原则，如流畅的有效沟通、文档的一致性和及时性、项目的风险管理等。测试的风险更大，细心对待，需要有更及时地应对措施。

第18回 测试计划的有效性和全面性

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试) 进行考虑。
测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

• 基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。
• 基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

• 全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；
• 基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；
• 根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；
• 需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

• 优先级最高的需求功能
• 新增加的功能和编码改动较大的已有功能
• 容易出现问题的部分功能
• 过去测试不够充分的地方
• 经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

• 让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；
• 测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；
• 测试项目的输入、输出和质量标准，应与各方达成一致；
• 建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

第19回 测试资源的合理分配

测试资源的分配，不仅要考虑测试团队的构成，而且要考虑不同的所需要的人数和对人员的要求是不同的。其次，软件测试项目所需的人员和要求在各个阶段是不同的：

1. 在初期需要项目经理或测试组长介入进去，为测试项目提供总体方向、制定测试策略、测试计划，申请系统资源；
2. 在测试前期，需要一些比较资深的测试设计、开发人员，对被测软件的详细了解、测试评估、测试需求的分解，设计测试用例、开发测试脚本；
3. 在测试中期，主要是测试执行，要看测试自动化实现的程度，如果测试自动化程度高，人力的投入没有明显的增加；如果测试自动化程度低，测试执行的人员要求多，需要比较早的计划，保证足够的资源。
4. 在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。

一个有效的软件测试项目管理者（测试组长，QA经理或测试经理），在测试资源的分配上尽量做到合理，既不过于保守，浪费资源，也不过于激进，使资源的使用总是处于紧张状态，随时有“崩盘”的危险。所以，在资源分配和管理中，要做到：

• 注意合理分配任务，明确规定每一个人在测试工作中的具体任务、职责和权限，每个组员都明确自己该做什么、怎么做、负什么责任、做好的标准是什么。做到人人心中有数，为保证和提高产品质量（或服务质量）提供基本的保证。
• 在安排任务时，尽量考虑每个人不同的技术特长、能力、性格、工作风格等，因为资源需求的估计依赖于工作量的估计和每个工程师的能力评估。
• 在不同的测试阶段，可以进行人员的相互调换，起到相互补充、相互督促/控制的作用。
• 人员的安排应该有一个提前量和余量（buffer，10%左右），因为一个合格的测试人员可能需要一个较长的培训、熟悉产品特性和适应测试流程的过程。
• 在做出最后安排决定之前，最好和每一个测试人员做一次沟通，达成共识。有良好的意识去关心组员，关注项目组员的情绪，以鼓励为主，不断激励员工，鼓舞士气，发挥每一位员工的潜力，注重团队的工作效率。

第20回 测试风险的管理

测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：

1. 质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
2. 测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
3. 需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
4. 质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
5. 测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
6. 测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
7. 有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
8. 回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

前面三种风险是可以避免的，而4）至7）的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。

针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

• 测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；
• 有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；
• 有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；

为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

• 在做资源、时间、成本等估算时，要留有余地，不要用到100%；
• 在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中；
• 对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继续下去；
• 制定文档标准，并建立一种机制，保证文档及时产生；
• 对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；
• 对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。

补充材料： 关于风险管理的方法

风险管理，一般可以分成5个步骤，即风险识别、风险分析、风险计划、风险控制以及风险跟踪。

1. 风险识别

风险识别是试图用系统化的方法来确定威胁项目计划的因素。识别方法包括风险检查表、头脑风暴会议、流程图分析以及与项目人员面谈等。前两种方法是比较常用的。风险检查表建立在以前开发类似的项目中曾经遇到的风险基础上，比如开发时利用了某种技术，那么有过这种技术开发经验的个人或者项目组就能指出他们在利用这种技术时遇到过的问题；头脑风暴会议可以围绕项目中有可能会出现哪些范围、进度、成本和质量方面的问题这一议题展开，讨论和列举出项目可能出现的风险。对不同的项目应该具体问题具体分析，识别出真正可能发生在该项目上的风险事件。

2. 风险分析

风险分析可以分为定性风险分析和定量风险分析。定性风险分析是评估已识别风险的影响和可能性的过程，以根据风险对项目目标可能的影响对风险进行排序。它在明确特定风险和指导风险应对方面十分重要。定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。

不同的风险发生后对项目造成的影响各不相同，主要有以下3个方面需要考虑：

• 风险的性质，即风险发生时可能产生的问题；
• 风险的范围，即风险的严重性及其总的分布；
• 风险的时间，即何时能感受到风险及风险维持多长时间。

据此确定风险估计的加权系数，得到项目的风险估计。然后通过对风险进行量化、选择和排序，可以知道哪些风险是必须要应对，哪些是可以接受，哪些是可以忽略。进行风险管理应该把主要精力集中在那些影响力大、影响范围广、概率高以及可能发生的阶段性的风险上。

3. 风险计划

制定风险行动计划，应考虑以下部分：责任、资源、时间、活动、应对措施、结果、负责人。建立示警的阈值是风险计划过程中的主要活动之一，阈值与项目中的量化目标紧密结合，定义了该目标的警告级别。
该阶段涉及到参考计划、基准计划和应急计划等不同类型的计划。

• 参考计划是用来与当前建议进行比较的参考点。
• 基准计划是建议的计划编制基础，是提出的项目实施的起始位置。
• 应急计划是建立在基准计划基础上的建议补充计划，包括启动意外情况应对措施的触发点。

在这一阶段有巩固与解释、选择与细化、支持与说服等特定的任务。

4. 风险控制方法

主要采用的应对方法有风险避免、风险弱化、风险承担和风险转移等。

• 风险避免：通过变更软件项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，采用更熟悉更成熟的技术、澄清不明确的需求、增加资源和时间、减少项目工作范围、避免不熟悉的分包商等。
• 风险弱化：将风险事件的概率或结果降低到一个可以接受的程度，当然降低概率更为有效。例如，选择更简单的开发流程、进行更多的系统测试、开发软件原型系统、增加备份设计等。
• 风险承担：表示接受风险，不改变项目计划(或没有合适的策略应付风险)，而考虑发生后如何应对。例如制定应急计划、风险应变程序，甚至仅仅进行应急储备和监控，发生紧急情况时随机应变。在实际中，如软件项目正在进行中，有一些人要离开项目组，可以制定应急计划，保障有后备人员可用，同时确定项目组成员离开的程序，以及交接的程序。
• 风险转移：不去消除风险，而是将软件项目风险的结果连同应对的权力转移给第三方(第三方应知晓有风险并有承受能力)。这也是一种事前的应对策略，例如签订不同种类的合同，或签订补偿性合同等。

5. 风险跟踪

在风险受到控制以后，我们要及时进行跟踪，做好风险跟踪：

• 监视风险的状况，例如风险是已经发生、仍然存在还是已经消失；
• 检查风险的对策是否有效、跟踪机制是否在运行；
• 不断识别新的风险并制定对策。

可以通过以下几种方法进行有效的风险跟踪：

• 风险审计：项目管理员应帮助项目组检查监控机制是否得到执行。项目经理应定期进行风险审核，尤其在项目关键处进行事件跟踪和主要风险因素跟踪．以进行
• 风险的再评估：对没有预计到的风险制定新的应对计划。
• 偏差分析：项目经理应定期与基准计划比较，分析成本和时间上的偏差。例如，未能按期完工、超出预算等都是潜在的问题。
• 技术指标分析：技术指标分析主要是比较原定技术指标和实际技术指标差异，例如，测试未能达到性能要求等。

第21回 测试用例设计方法的综合运用

测试用例是按一定的顺序执行的与测试目标相关的测试活动的描述，是确定“怎样”测试。测试用例被看作是有效发现软件缺陷的最小测试执行单元，也被视为软件的测试规格说明书。在测试工作中，测试用例的设计是非常重要的，是测试执行的正确性、有效性的基础。如何有效地设计测试用例，一直是测试人员所关注的问题；设计好测试用例，也是保证测试工作的最关键的因素之一。

设计测试用例，也分为白盒设计方法和黑盒设计方法。白盒设计方法又分为逻辑覆盖法和基本路径覆盖法，或者分为语句覆盖、判定覆盖、条件覆盖方法，而黑盒设计方法分为等价类划分法、边界值划分法、错误推测法、因果图法等。在实际测试用例设计过程中，不仅根据需要、场合单独使用这些方法，常常综合运用多个方法，使测试用例的设计更为有效。

1．判定-条件覆盖方法

判定-条件覆盖方法就是将两种白盒设计方法“判定覆盖”和“条件覆盖”结合起来的一种设计方法，它所设计的测试用例是判定覆盖的设计的测试用例和条件覆盖设计的设计的测试用例的交集，即设计足够精巧的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果也至少执行一次。

举个例子，源程序是：

Dim a,b as Integer

Dim c as Double

If （a > 0 and b > 0） Then

c = c/ a

End If

If （a>1 or c>1） Then

c=c+1

End If

c=b+c

则用两个测试用例（如表1）来覆盖了两个判定“P1=（a > 0 and b > 0）”和“P2 =（a>1 or c>1）”和四个条件“C1= a > 0”、“C2= b > 0”、“C3= a>1”和“C4= c>1”。

表1 判定-条件覆盖的测试用例

2．条件组合覆盖

条件组合覆盖的基本思想是：设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次，条件覆盖是简单地要求每个条件出现“真”与“假”两种结果，而条件组合覆盖是让这些结果的所有可能组合都至少出现一次。

按照条件组合覆盖的基本思想，针对8种组合条件，来设计所有能覆盖这些组合的设计用例，如表2所示。即使我们用四个测试用例覆盖了所有8种组合条件，但还不能保证所有的路径被执行，如这个例子少了一种路径，即P1= True, P2= false。

表2 条件组合覆盖的测试用例

3. 等价类划分法和边界值分析法的组合

数据测试是功能测试的主要内容，或者说功能测试最主要手段之一就是借助数据的输入/输出来判断功能能否正常运行。所以在测试用例的黑盒设计方法中，最常用的方法是等价类划分法、边界值分析法。

等价类划分方法的基本思想是设想用一组有限的数据去代表近似无限的数据，就是基于对输入或输出数据的评估将数据划分为两个或更多子集（如有效的和无效的数据集），从每个等价类中选择一定的代表值进行测试，来代表整个数据集的输入/输出。

边界值分析法就是在某个变量范围的边界上，验证独立的输入/输出是否正确的测试方法。因为实践证明，程序往往在输入/输出数据边界更容易发生错误，所以检查边界情况的测试用例是比较高效的，可以更快地查出错误。

但是，仅仅测试边界数据是不够的，正常区域内的数据也是需要测试的，而且对于那些非法的、无效的数据也需要测试，以测试系统的容错性。所以，必须采用等价类划分方法来对边界值分析法的补充。从另一个方面看，要划分数据的等价类，首先是要确定数据边界，也就是找出数据等价类的边界。所以，在实际测试用例设计工作中，将边界值分析法和等价类划分方法结合起来，先用边界值分析法确定数据边界，再用等价类划分方法得到等价的数据类，从而有效地设计出精而少的测试用例。

让我们看一个简单的例子。假如一个输入数据是一个有限范围的整数，如学生成绩管理系统中的学生分数的输入（不计小数点）。这时，我们可以确定输入数据的最小值Nmin和最大值NMax，则有效的数据范围是Nmin≦N≦NMax ,如学生分数的输入范围是0≦N≦100，这个范围就是有效数据区域。除此之外，就是无效数据区域，即N <Nmin或N>NMax，如N <0或N>100。这时测试的数据从近乎无限的数据简化为5个输入数据，就是：

• 边界值两个：Nmin和NMax，如0和100
• 有效数据的等价输入值 Ni, 如75
• 无效数据的等价输入值两个：NLm1和NLm2, 如 -999和 999

为了得到更好的覆盖率，可以在最靠近边界取一些值，共四个，即：
Nmin +1，Nmin -1，NMax +1，NMax -1，如 -1，1，99，101

所以一个有效的测试数据集合是{-1，0，1，99，100，101}；更完整的测试数据集合是{-999，-1，0，1，75，99，100，101，999}。

4．因果图法和组合分析法

因果图法和组合分析可以看作测试用例黑盒设计方法的综合方法。因果图法就是一种利用图解法分析输入的各种组合情况，生成判定表，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。我们知道，即使各种单个输入条件可能出错的情况已经被排除了，但多个输入情况组合起来还是可能会出错。检验各种输入条件的组合并非一件很容易的事情，因为即使将所有的输入条件划分成等价类，它们之间的组合情况也相当多，因此，必须需要考虑采用一种适合于多种条件的组合，相应能产生多个动作的形式来进行测试用例的设计，这就是因果图法。

而组合分析是一种基于每对参数组合的测试技术，主要考虑参数之间的影响是主要的错误来源和大多数的错误起源于简单的参数组合。

5．功能图法

功能图法是一种黑盒和白盒混合用例设计方法，在功能图方法中，要用到逻辑覆盖和路径测试的概念和方法，这属于白盒设计方法；而确定输入数据序列以及相应的输出数据，则是黑盒设计方法。

我们知道，每个程序的功能通常由静态说明和动态说明组成，动态说明描述了输入数据的次序或者转移的次序；静态说明描述了输入条件和输出条件之间的对应关系。对于比较复杂的程序，由于大量的组合情况的存在，如果我们仅仅使用静态说明来组织测试往往是不够的，必须还要动态说明来补充。功能图法就是因此而产生的一种测试用例设计方法。

功能图法就是使用功能图形式化地表示程序地功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型组成。其中，状态迁移图用于表示输入数据序列以及相应的输出数据，由输入和当前的状态决定输出数据和后续状态； 逻辑功能模型用于表示再状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅仅由输入数据决定。测试用例测试由测试中经过的一系列的状态以及在每个状态中必须依靠输入/输出数据满足的一对条件组成。

第22回 测试用例的复审

测试用例的设计是整个软件测试工作的核心，测试用例反映对被测对象的质量要求和评估范围，决定测试的效率和测试自身的质量。

所以对测试用例的评审，就显得非常重要。测试用例设计完之后，要经过非正式和正式的复审和评审。在测试用例审查、评审过程中，主要检查下列内容：

• 测试用例设计的整体思路是否清晰，是否清楚系统的结构和逻辑从而使测试用例的结构或层次清晰，测试的优先级或先后次序是否合理；
• 测试用例设计的有效性，测试的重点是否突出，即是否抓住修改较大的地方、程序或系统的薄弱环节等；
• 测试用例的覆盖面，有没有考虑到产品使用中一些特别场景（scenario）、考虑到一些边界和接口的地方；
• 测试用例的描述，前提条件是否存在、步骤是否简明清楚、期望结果(Criteria)是否符合产品规格说明书或客户需要；
• 测试环境是否准确，测试用例有没有正确定义测试所需要的条件或环境；
• 测试用例的复用性和可维护性，良好的测试用例将会具有重复使用的功能, 保证测试的稳定性；
• 测试用例是否符合其他要求，如可管理性、易于自动化测试的转化等。

测试用例在评审后，根据评审意见做出修改，继续评审，直至通过评审。在以后的测试中，如果有些被发现的缺陷，没有测试用例，应及时添加新的测试用例或修改相应的测试用例。和软件缺陷相关的测试用例是更有效的测试用例，其执行的优先级也高。通过测试用例所发现的缺陷占所有软件缺陷的比值，是衡量测试用例质量和有效性的方法之一。