理论思想篇

第1回 V模型，我的完整诠释

万事开头难，第一回起头自然比较难，我选择了“V模型，我的完整诠释”作为开始。因为，软件测试的思想方法是建立在软件开发过程模型（思想）基础之上，例如测试驱动开发来源于敏捷开发思想。在这里，也是假定V模型是大家更好理解软件测试思想和方法的基础。

现在谈V模型，是否落后于时代？不一定，实际许多软件过程思想是相通的，例如迭代模型、增量模型和螺旋模型都可以归为“分阶段开发”思想这一类。极限编程（XP）对于现在Internet服务模式的软件开发很有效，也只适合软件开发的小团队。V模型适合企业级的软件开发，它更清楚地揭示了软件开发过程的特性及其本质。

V模型是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。

下面通过对这种模型的水平和垂直的关联和比较分析，理解软件开发和测试的关系，理解V模型具有面向客户、效率高、质量预防意识等特点，能帮助我们建立一套更有效的、更具有可操作性的软件开发过程。

1．从水平对应关系看

左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动——审核的过程，也就是静态的测试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。如：

• 需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并策划测试活动。
• 当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上是要花去很多时间。
• 当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。
• 在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量、减少成本。

从中可以看出，V模型使我们能清楚地看到质量保证活动和项目同时展开, 项目一启动，软件测试的工作也就启动了,避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。

2．从垂直方向看

水平虚线上部表明，其需求分析、定义和验收测试等主要工作是面向用户，要和用户进行充分的沟通和交流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，主要是由工程师、技术人员完成。

从垂直方向看，越在下面，白盒测试方法使用越多，到了集成、系统测试，更多是将白盒测试方法和黑盒测试方法结合起来使用，形成灰盒测试方法。而在验收测试过程中，由于用户一般要参与，使用黑盒测试方法。

第2回 究竟什么是软件测试？

在G.J.Myers的经典著作《软件测试之艺术》（The Art of Software Testing）中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。除此之外，G.J.Myers还给出了与测试相关的三个重要观点，那就是：

1. 测试是为了证明程序有错，而不是证明程序无错误；
2. 一个好的测试用例是在于它能发现至今未发现的错误；
3. 一个成功的测试是发现了至今未发现的错误的测试。

实际上，这里暗示了“软件测试”在不同侧面上的含义，也就决定了对软件测试不同的定义和不同的理解。根据作者多年的经验和理解，软件测试的不同视野，概括为如下5类：

• 软件测试的狭义论和广义论——静态和动态的测试
• 软件测试的辨证论——正向思维和反向思维
• 软件测试的风险论——测试是评估
• 软件测试的经济学观点——为盈利而测试
• 软件测试的标准论——验证和确认

1. 软件测试的狭义论和广义论

G.J.Myers所给出了测试定义——“程序测试是为了发现错误而执行程序的过程”，实际是一个狭义的概念，因为他认为测试是执行程序的过程，也就是传统意义上的测试——在代码完成后，通过运行程序来发现程序代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统需求、发现设计上的问题，把需求、发现设计上的问题遗留到后期，这样就会可能造成设计、编程的部分返工。增加软件开发的成本、延长开发的周期等。需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。这种狭义论是受软件开发瀑布模型影响。

正是为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。

延伸后的软件测试，被认为是一种软件测试的广义概念。这就引出软件测试的两个概念“静态测试”和“动态测试”，如 测试方法的辩证统一 （1）所述，这样就由静态测试和动态测试构成一个全过程的、完整的软件测试，而且静态测试显得更为重要。

2.软件测试的辨证论

G.J.Myers的第2个观点“测试是为了证明程序有错，而不是证明程序无错误”，引出了软件测试的另外一个争论，软件测试究竟是证明所有软件的功能特性是正确的呢？还是其反向思维——对软件系统进行各种试探和攻击，找出软件系统中不正常或不工作的地方呢？从我个人理解，这两个方面都有一定道理，前者（证明所有软件的功能特性是正确的）是从质量保证的角度来思考软件测试，后者（证明程序有错）从软件测试的直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，我们认为，测试不是为了证明所有的功能可以正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的地方。也就是说，测试的一般工作就是发现缺陷 (detect bug)，即在软件开发过程中，分析、设计与编码等工作都是建设性的，而测试是带有“破坏性”的工作。

对于不同的应用领域，两者的比重是不一样的，如国防、航天、银行等软件系统，承受不了任何系统失效，因为一次系统的失效完全有可能导致灾难性的损失，所以强调前者以保证非常高的软件质量。而一般的软件服务应用则不同，强调后者，质量目标设置在“用户可接受水平”，不要国度追求质量，从而可以降低软件开发成本。作者建议，在我们实际操作中，可以分阶段实施不同的测试思想，在早期阶段集中在“证明程序有错”—— 发现Bug，后期集中在验证所有特性是否正常工作——降低风险，见作者的另外一篇讨论：测试执行中非常有效的策略

下面就是这两种观点的基本描述：

• 验证软件是验证软件是“工作的”，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其代表人物是软件测试领域的先驱Dr. Bill Hetzel （代表论著《The Complete Guide to Software Testing》)。
• 证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物就是上面多次提到的G.J.Myers。他强调，一个成功的测试必须是发现Bug Bug的测试，不然就没有价值。

3.软件测试的风险论

测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就是软件测试的风险论。软件测试自身的风险性是大家公认的，测试的覆盖度不能做到100％。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，“软件规格说明书（Specification/ Spec）”是其中的一个标准，但也不是唯一的，因为Spec中有些内容完全有可能是错误的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对Spec 去报Bug。但是，测试在大多数时间/情况下,是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢？

有人把开发比作打靶，目标明确，就是按照Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞；如果只捞大鱼（严重缺陷），网眼就可以大些、撒网区域相对比较集中（测试点集中在主要功能-major features）。如果想把大大小小的鱼捞上来，网眼就要小、普遍撒网，不放过任何一块区域（测试点遍及所有功能——all features）。

在“风险”论的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试可以完全看作是软件质量控制的过程。

对应这种观点，产生基于风险的测试策略，首先评估测试的风险，功能出问题的概率有多大？哪些是用户最常用的20％功能——Pareto原则（也叫80/20原则）？如果某个功能出问题，其对用户的影响有多大？然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的80％功能）就不是必要的，如果时间或经费不够，就暂时不做或少做。

4.软件测试的经济学观点

“一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。实际上，软件测试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商业性目标。同样，商业性目标是否正确，直接决定了企业是否盈利的结果。多数情况下，软件测试是在公司内的执行。正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅仅局陷于“和客户需求的一致性、适用性”，而且要增加其它的要求——“预算内、按时发布、易于维护”。

软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是 40～ 1000倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。

5. 软件测试的标准论

如果从标准论来看软件测试，可以定义为软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试 = V&V。

“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于，以Spec为标准进行软件测试活动，验证软件产品和Spec的一致性。

“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。相当于，保持对软件需求定义、设计的怀疑，一切从客户出发，理解客户的需求，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。

需要说明的是，软件测试的对象是产品（包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计文档、数据字典、程序包、用户文档等），而质量保证和管理的对象集中在软件开发的标准、流程和方法等。

第3回 软件测试和质量保证的关系

软件测试在软件生命周期中占据重要的地位，在传统的瀑布模型中，软件测试仅处于编码之后、运行维护阶段之前，是软件产品交付用户使用之前软件质量保证的最后手段。这是一种误导，我们已经在“ 第1回 V模型，我的完整诠释”作了很好说明，软件生命周期每一阶段中都应包含测试，从静态测试到动态测试，要求检验每一个阶段的成果是否符合质量要求和达到定义的目标，尽可能早的发现错误并加以修正。如果不在早期阶段进行测试，错误的不断扩散、积累常常会导致最后成品测试的巨大困难、开发周期的延长、开发成本的剧增等等。

事实上，对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，这些引入的错误需要通过测试来发现，软件中的错误密度也需要测试来进行估计。测试是所有工程学科的基本组成单元，是软件开发的重要部分，一直伴随着软件开发走过了半个多世纪。统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。而在软件开发的总成本中，用在测试上的开销要占30％到50％。

一般规范的软件测试流程包括项目计划检查、测试计划创建、测试设计、执行测试、更新测试文档，而SQA的活动可总结为：协调度量、风险管理、文档检查、促进／协助流程改进、监察测试工作。它们的相同点在于二者都是贯穿整个软件开发生命周期的流程。

软件质量保证（SQA）的职能是向管理层提供正确的可视化的信息，从而促进与协助流程改进。SQA还充当测试工作的指导者和监督者，帮助软件测试建立质量标准、测试过程评审方法和测试流程，同时通过跟踪、审计和评审，及时发现软件测试过程中的问题，从而帮助改进测试或整个开发的流程等，因此有了SQA，测试工作就可以被客观的检查与评价，同时也可以协助测试流程的改进。

而测试为SQA提供数据和依据，帮助SQA更好地了解质量计划的执行情况、过程质量、产品质量和过程改进进展，从而使SQA更好地做好下一步工作。

它们的不同之处在于SQA侧重对流程中过程的管理与控制，是一项管理工作，侧重于流程和方法。而测试是对流程中各过程管理与控制策略的具体执行实施，其对象是软件产品（包括阶段性的产品），即测试是对软件产品的检验，是一项技术性的工作。测试，常常被认为是质量控制的最主要手段。但是，随着时间的推移，软件质量保证和软件质量控制之间的界限越来越模糊了，两者合二为一。也就是说，软件测试是SQA中的重要手段，SQA的主要功能在软件测试中得到体现，集中在静态测试中，两者的关系越来越紧密，已无法分开。

第4回 软件测试的目标

软件缺陷的产生主要是由软件产品的特点和开发过程决定的，如软件的需求经常不够明确，而且需求变化频繁，开发人员不太了解软件需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，产生的问题最多。同时，软件竞争非常厉害，技术日新月异，使用新的技术，也容易产生问题。而且对于不少软件企业，“争取时间上取胜”常常是其主要市场竞争策略之一，实现新功能、很酷的功能，被认为比质量更为重要，导致日程安排很紧，需求分析、设计等投入的时间和精力远远不够，也是产生软件错误的主要原因之一。

软件错误产生的原因可能还有其他一些原因，例如，软件设计文档不清楚，文档本身就存在错误，导致使用者产生更多的错误。还有沟通上的问题、开发人员的态度问题以及项目管理问题等。《微软开发者成功之路(之一)》概括为有以下七项主要原因：

1. 项目期限的压力
2. 产品的复杂度
3. 沟通不良
4. 开发人员的疲劳、压力或受到干扰
5. 缺乏足够的知识、技能和经验
6. 不了解客户的需求
7. 缺乏动力

这些原因，会引起下列主要领域的主要错误（缺陷）：

• 需求规格说明书（Requirement Specification or Functional Specification ）包含错误的需求、或漏掉一些需求, 或没有准确表达客户所需要的内容；
• 需求规格说明书中有些功能不可能或无法实现的；
• 系统设计(System Design)中的不合理性；
• 程序设计中的错误、程序代码中的问题，包括错误的算法、复杂的逻辑等。

若能及早排除软件开发中的错误，有效的减少后期工作的麻烦，就可以尽可能的避免付出高昂的代价，从而大大提高系统开发过程的效率。

软件测试的目标，就是为了更快、更早地将软件产品或软件系统中所存在的各种问题找出来，并促进开发各类人员尽快地解决问题，最终及时地向客户提供一个高质量的软件产品，使软件系统更好地满足用户的需求，同时满足软件组织自身的要求：

1. 用户的需求

• 能正常使用全部所需要的功能
• 功能强大，而且界面美观、易用、好用
• 内容健康，有益于生活和工作
• 用户的数据安全、受保护和兼容
• 及时得到新的产品或得到更完美的软件服务
• 软件可靠性很高，使用软件服务没有时间障碍

2. 软件企业的需求

• 软件质量是市场竞争的需要，质量好的软件是留住客户的最关键的手段之一，软件企业也必须依靠质量，才能立于不败之地；
• 高质量的软件可以大大降低“质量问题产生的成本”，增加公司的盈利；
• 软件已是国际化的市场，质量是进入国际市场的一个关键门坎；
• 容易维护、移植和扩充，以扩大市场或适应环境的变化。

这些要求的满足，最终体现在软件产品的质量上：

• 功能性，软件所实现的功能达到它的设计规范和满足用户需求的程度；
• 可用性，对于一个软件，用户学习、操作、准备输入和理解输出所作努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段；
• 可靠性，用户使用的根本，在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度；
• 性能，在指定条件下，用软件实现某种功能所需的计算机资源（包括内存大小、CPU占用时间等）的有效程度；
• 容量，系统的接受力、容纳或吸收的能力、或某项功能的最大量或最大限度，有时需要确定系统的特定需求的所能容纳的最大量、所能表现的最大值。如Web系统能承受多少并发用户访问、会议系统可以承受的与会人数等；
• 可测量性，系统某些特性可以通过一些量化的数据指标能描述其当前状态或理想状态；
• 可维护性，在一个运行软件中，当环境改变或软件发生错误时，进行相应修改所做努力的简易程度；
• 可维护性取决于理解软件、更改软件和测试软件的简易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。
• 兼容性，软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。兼容性表现在多个方面，如系统的软件和硬件的兼容性、软件的不同版本的系统、数据的兼容性；
• 可扩展性，指将来功能增加、系统扩充的难易程度或能力。

第5回 软件测试所面对的现实

测试始终是一个具有风险的工作，比如，现在越来越多地用“风险”概念来定义测试，测试被认为是

“理解并评估与发布的软件系统有关的利益和风险状况的过程”，测试的作用则是管理或转移系统失败的风险，以及如何尽大程度地消除给用户带来的不良影响。

测试工作为什么总存在风险呢？因为当我们测试某个应用系统或一个软件产品时，不可能把所有可能的情况都测试一遍。例如，即使对一个计算器程序，要测试的数字可以从0开始到一个很大的数，就算8位数字（99999999），仅仅测试其加法运算的可能情况就是1016，要完成这些测试，即使借助计算机，每秒完成10万个测试用例，一个测试人员穷其一生也完成不了，因为需要3100多年。如果再加上负数、减法、乘法、除法、括号以及它们的各种组合，所有全部可能的情况将是一个巨大的天文数字，所以完成全部可能的情况是不可想象的。

所以，我们必须不得不借助一些测试用例的设计方法，如边界值分析方法、等价类划分方法等来解决这个问题，选择样本数据，用极有限的、代表性的测试数据来代替实际的、巨大的测试数据。这些方法的应用是基于一个假设：如果程序在这些样本数据情况下运行正确，那么该程序也满足所有类似的数据。这种假设的存在，也就意味着一定的风险存在。对于简单的程序，这种风险很小，但是对越来越复杂的应用程序或软件系统，这种风险就越来越大。

即使完成了全部功能的测试，也很难完成所有用户的环境下的测试。测试的环境是有限的，而软件系统的实际运行环境是复杂的、千变万化的，不仅有不同的硬件（主板、CPU、内存、网卡、显示卡等）型号差异，而且还有操作系统及其版本、驱动程序及其版本、已安装的应用程序等的差异。完成各种用户环境下的软件测试，也是几乎不可能，即使可以实现，其成本也是巨大的，一般软件企业不堪重负。同样，系统的性能测试、有效性测试和可靠性测试等蕴含着较大的风险。例如，可靠性测试是通过模拟方法实现，不能在完全真实的情况下进行，如不可能对真实系统连续进行10或20年的不间断测试。

测试工作，除了始终所存在的风险之外，还会受到其他多方面的挑战，主要有：

• 测试不能提高质量，但软件产品发布后，缺陷较多，往往被认为是测试人员的错。在许多人的心目中，测试人员是防止缺陷的盾牌或最后一堵墙。实际上，所有的软件缺陷都是在需求分析、设计和编程时被注入进去的，注入的缺陷越多，被漏掉的缺陷可能性就越大。
• 测试人员的素质和待遇。国内还存在对测试理解的误区，如测试不需要技术或不需要过高的技术。在选用测试人才时，往往降低要求，所给的待遇也偏低，从而造成测试队伍的整体能力比较弱、工作热情比较低，对测试质量有较大的负面影响。
• 测试时间往往被压缩。虽然一旦软件项目启动，测试工作就开始，包括产品需求文档审查、产品规格说明书审查、测试计划/用例的设计等，但是软件测试的主要执行时间是在代码完成后。由于软件的日程估计往往不够准确，代码完成时间延迟经常会发生，但管理层又不想推迟整个产品的发布日期，结果测试时间首当其冲，测试周期被缩短，造成测试不够充分或已计划好的测试项目不能保质保量的完成。

总之，测试工作所面临的挑战比较大，有时可以说是严峻的，但是，只要我们敢于面对现实，坚持测试原则，就能克服困难，运用正确的、更有效的测试方法和工具，保证足够的测试和测试的质量。

第6回 软件测试的十大原则

原则是最重要的，方法应该在这个原则指导下进行。软件测试的基本原则是站在用户的角度，对产品进行全面测试，尽早、尽可能多地发现Bug, 并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。

零缺陷(Zero-Bug) 是一种理念，足够好（Good-Enough）是测试的基本原则。

在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项：

1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
2. 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。质量的理念和文化（如零缺陷的“第一次就把事情做对”）同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。
7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。
10. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。错误集中发生的现象，可能和程序员的编程水平和习惯有很大的关系。

第7回 软件测试方法的应用之道

测试工作的质量，首先取决于先进的质量理念和文化，坚持质量第一的原则，其次，就是取决于对各种测试方法有着辩证统一的理解和正确地、有效地的运用。在这一回，将探讨软件测试方法的应用之道。在次之前，实际上，我们对测试方法的应用之道，已做了较多的讨论，详见：

测试方法的辩证统一

这里对测试方法的应用进行全面系统的总结，使大家更好地理解和掌握测试方法应用之道。

第8回 测试的三维空间

软件测试是一个过程，是哲学思想在软件工程中的运用，更是质量目标的扩展和延伸。软件测试构成了具有丰富内容的三维空间。

1. 测试目标— 质量特性的验证

• 正确性测试 (Correctness testing) 或功能性测试：是基于产品功能规格说明书、从用户角度针对产品特定的功能和特性所进行的验证活动，以确认每个功能是否得到完整的实现，用户能否正常使用这些功能。功能测试一般要在完成集成测试后进行，而且是针对应用系统、在实际运行环境下而进行的测试。
• 性能测试（Performance testing）：是测试在一定条件下系统行为表现，是否在设计的性能指标范围内。如测试网站在并发用户数为10、100、1000、10000等情况下，页面的响应时间是否在3秒或5秒内，响应时间最长是否不超过15秒或30秒。性能测试不同于负载测试（Stress/load testing），性能测试是在定义的各种条件下去衡量系统的有关性能指标，而负载测试只测试在一些极端条件下，系统还能否正常工作，或加载到系统崩溃而找出系统性能的瓶颈，所以也可以和性能测试结合起来做。
• 可靠性测试（Reliability testing）：是评估软件在运行时的可靠性，即通过测试确认平均无故障时间（MTTF, Mean Time To Failure）或最初平均寿命，即故障发生前平均工作时间（MTTFF, Mean-Time -TO-First-Failure）。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。可靠性测试，一般伴随着强壮性测试（Robustness/strong testing）。
• 安全性测试（Safety or Security testing）：是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力，以检验系统有能力使可能存在来自于内/外部的伤害或损害的风险限制在可接受的水平内。软件可靠性要求，通常包括了安全性的要求。但是软件的可靠性不能完全取代软件的安全性，因为安全性还涉及到数据加密、保密、存取权限等方面的要求。
• 容错性测试（Tolerance testing）：是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动。容错性测试看作由系统异常处理测试和恢复测试组成。
• 恢复测试 (Recovery testing)，在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统和数据的能力测试，包括确定软件系统的平均修复时间（MTTR，Mean Time to Repair）。
• 兼容性测试 (Compatibility testing)，测试在各种的硬件/软件/操作系统/网络环境下的软件表现，包括硬件接口、软件新旧版本兼容、已存在数据的兼容能力。

2. 测试方法 — 哲学的思考

测试的方法技术，经过多年的发展，已经相当成熟，方法比较多。如白盒测试方法 (White-box test) 、灰盒测试方法(Gray-box test)和黑盒测试方法(Black-box test)，就是一种哲学思想在软件测试中的体现和延伸。从哲学观点看，分析问题和解决问题的方法有两种：白盒子方法和黑盒子方法。如果我们对被测的对象/世界（软件）认知很少，可以不用了解其内部结构，完全只关注其外部的变化，如外部的输入、外部作用或被测的对象所处的条件以及被测的对象输出的结果，就可以完成测试，这就是黑盒测试方法。随着对被测的对象的认知越来越多，就可以采用灰盒测试方法；当我们完全认知被测的对象时，就可以用白盒测试方法。也见： 测试方法的辩证统一 （1）和 第7回 软件测试方法的应用之道。

3. 测试阶段 － 生命周期的显现

随着软件开发的生命周期所包含的活动——进程的不断推进，测试与之对应，也划分了不同的测试阶段，包括单元测试、集成测试、系统测试和验收测试等，我们将在后面陆续讨论。

第9回 验证和确认——缺一不可

在软件测试中不仅要检查程序是否出错、程序是否和软件产品的设计规格说明书一致，而且还要检验所实现的正确功能是否就是客户或用户所需要的功能，两者缺一不可，这两部分活动构成了一个完整的测试活动。这就是软件测试中有名的V&V，即Verification和Validation。实际上，在整个软件开发生命周期，Verification和Validation每时每刻都存在着。

1. 验证——Verification

Verification，翻译为“验证”，也可以译为“检验”，即验证或检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明，软件相关产品与所有生命周期活动（需求分析、设计、编程、测试等）的要求（如正确性、完整性、一致性、准确性等）相一致。

验证是否满足生命周期过程中的标准、实践和约定；验证为判断每一个生命周期活动是否已经完成，以及是否可以启动其他生命周期活动建立一个新的基准。

在 ISO9000 中，“验证”的严格定义是：验证是通过检查和提供客观证据，表明规定要求已经满足的认可。“验证”强调的是“规定规格要求”

2. 有效性确认——Validation

Validation，翻译为“确认”，但更准确地翻译，应该是“有效性确认”，这种有效性确认要求更高，要能保证所生产的软件可追溯到用户需求的一系列活动。确认过程提供证据，表明软件是否满足客户需求（指分配给软件的系统需求），并解决了相应问题。
在 ISO9000 中，“确认”的严格定义是： 确认：是通过检查和提供客观证据，表明一些针对某一特定预期用途的要求已经满足的认可。“确认”强调的是“预期用途的要求”

3. 两者的区别和联系

为了更好地理解这两个测试活动的区别，可以概括地说，验证（Verification）是检验开发出来的软件产品和设计规格书的一致性，即是否满足软件厂商的生产要求。但设计规格书本身就可能有问题、存在错误，所以即使软件产品中某个功能实现的结果和设计规格书完全一致，但所设计的功能不是用户所需要的，依然是软件严重的缺陷。因为设计规格书很有可能一开始就对用户的某个需求理解错了，所以仅仅进行验证（Verification）测试还是不充分的，所以还需要进行性确认（Validation）测试。确认（Validation）就是检验产品功能的有效性，即是否满足用户的真正需求。

这就是BOEHM对V＆V的最著名又最简单的解释是

• Verification：Are we building the product right？是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容
• Validation： Are we building the right product? 是否构造了正确的软件？即是否正在做用户真正所需要的事。

我们还可以给出在目的、对象、参与人员和时机等各个方面的区别和联系。

目的：

• 验证的目的是证实设计阶段输出是否确保设计阶段输入要求；
• 确认的目的是通过产品确认设计是否满足使用要求。

对象：

• 验证的对象是设计输出文件，计算书或样品等；
• 确认的对象是最终产品（样品）。

参与人员：

• 验证的参与人员通常是设计部门；
• 确认的参与人员必须包括使用者或能代表使用要求的人员。

时机：

• 验证的时机是设计适当阶段，一般是设计阶段输出形成结果时；
• 确认的时机是成功的设计验证后，一般针对最终产品，也可分阶段确认。