理论思想篇1

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

 

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

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

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

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

<!--[if !vml]--><!--[endif]-->

图

 

<!--[if !supportLists]-->1． <!--[endif]-->从水平对应关系看

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

<!--[if !supportLists]-->l         <!--[endif]-->需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并策划测试活动。

<!--[if !supportLists]-->l         <!--[endif]-->当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上是要花去很多时间。

<!--[if !supportLists]-->l         <!--[endif]-->当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。

<!--[if !supportLists]-->l         <!--[endif]-->在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量、减少成本。

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

 

<!--[if !supportLists]-->2． <!--[endif]-->从垂直方向看

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

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

 

第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），仅仅测试其加法运算的可能情况就是10¹⁶，要

 

完成这些测试，即使借助计算机，每秒完成10万个测试用例，一个测试人员穷其一生也完成

 

不了，因为需要3100多年。如果再加上负数、减法、乘法、除法、括号以及它们的各种组

 

合，所有全部可能的情况将是一个巨大的天文数字，所以完成全部可能的情况是不可想象

 

的。

 

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

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

 

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

l         测试不能提高质量，但软件产品发布后，缺陷较多，往往被认为是测试人员的错。在许多人的心目中，测试人员是防止缺陷的盾牌或最后一堵墙。实际上，所有的软件缺陷都是在需求分析、设计和编程时被注入进去的，注入的缺陷越多，被漏掉的缺陷可能性就越大。

l         测试人员的素质和待遇。国内还存在对测试理解的误区，如测试不需要技术或不需要过高的技术。在选用测试人才时，往往降低要求，所给的待遇也偏低，从而造成测试队伍的整体能力比较弱、工作热情比较低，对测试质量有较大的负面影响。

 

l         测试时间往往被压缩。虽然一旦软件项目启动，测试工作就开始，包括产品需求文档审查、产品规格说明书审查、测试计划/用例的设计等，但是软件测试的主要执行时间是在代码完成后。由于软件的日程估计往往不够准确，代码完成时间延迟经常会发生，但管理层又不想推迟整个产品的发布日期，结果测试时间首当其冲，测试周期被缩短，造成测试不够充分或已计划好的测试项目不能保质保量的完成。

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