测试基础

izzj

软件测试的概念与定义

　软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。

　直到1957年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的活动。由于一直存在着“为了让我们看到产品在工作，就得将测试工作往后推一点” 的思想，潜意识里对测试的目的就理解为“使自己确信产品能工作”。测试活动始终后于开发的活动，测试通常被做为软件生命周期中最后一项活动而进行。当时也缺乏有效的测试方法，主要依靠“错误推测 Error Guessing”来寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。

　到了20世纪70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考软件开发流程的问题，尽管对“软件测试”的真正含义还缺乏共识，但这一词条已经频繁出现，一些软件测试的探索者们建议在软件生命周期的开始阶段就根据需求制订测试计划，这时也涌现出一批软件测试的宗师，Bill Hetzel 博士就是其中的领导者。1972年，软件测试领域的先驱Bill Hetzel博士（代表论著《The Complete Guide to Software Testing》），在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。在1973年，他首先给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行。Establish confidence that a program does what it is supposed to do. ”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。他的思想的核心观点是：测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。软件测试业界把这种方法看作是的软件测试的第一类方法。

　尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过程。The process of executing a program or system with the intent of finding errors.”这个定义，也被业界所认可，经常被引用。除此之外， Myers还给出了与测试相关的三个重要观点，那就是：

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

这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误的。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。Myers提出的“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。
　　
　然而，对Glenford Myers先生“测试的目的是证伪”这一概念的理解也不能太过于片面。在很多软件工程学、软件测试方面的书籍中都提到一个概念：“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”。这很容易让人们认为测试人员就是“挑毛病”的，而由此带来诸多问题。大家熟悉的Ron Patton在《软件测试》（中文版由机械工业出版社出版，此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试人员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”这样的定义具有一定的片面性，带来的结果是：

若测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现，测试活动往往会存在一定的随意性和盲目性；
• 若有些软件企业接受了这样的方法，以Bug数量来做为考核测试人员业绩的唯一指标，也不太科学。

总的来说，第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行，并通过。在软件行业中一般把第一类方法奉为主流和行业标准。第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。

　而第二类测试方法与需求和设计没有必然的关联，更强调测试人员发挥主观能动性，用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。这种方法往往能够发现系统中存在的更多缺陷。

　到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》（Complete Guide of Software Testing）一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准（IEEE/ANSI ），1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

　软件测试成熟度

　随着软件产业界对软件过程的不断研究，美国工业界和政府部门开始认识到，软件过程能力的不断改进才是增进软件开发组织的开发能力和提高软件质量的第一要素。在这种背景下，由美国卡内基-梅隆大学软件工程研究所（SEI）研制并推出了软件能力成熟度模型SW-CMM，CMM逐渐成为了评估软件开发过程的管理以及工程能力的标准。从80年代中期开始，软件生产开始进入以个体软件过程PSP(Personal Software Process)、过程成熟度模型CMM和群组软件过程TSP(Team Software Process)为标志的、以过程为中心的第二阶段。

　但是令人遗憾的是，CMM 没有充分的定义软件测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，在 KPA 中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。仅在第三级的软件产品工程（SPE）KPA中提及软件测试职能，但对于如何有效提高机构的测试能力和水平没有提供相应指导，无疑是一种不足。为此，许多研究机构和测试服务机构从不同角度出发提出有关软件测试方面的能力成熟度模型，作为SEI-CMM的有效补充，比较有代表性的包括：美国国防部提出一个CMM软件评估和测试KPA建议；Gelper博士提出一个测试支持模型（TSM）评估测试小组所处环境对于他们的支持程度；Burgess/Drabick I.T.I.公司提出的测试能力成熟度模型（Testing Capability Maturity Model）则提供了与CMM完全一样的5级模型。Burnstein博士提出了测试成熟度模型（TMM），依据CMM的框架提出测试的5个不同级别，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。 TMM 测试成熟度分解为 5 级别，关注于 5 个成熟度级别递增：

Phase 0 ：测试和调试没有区别，初了支持调试外，测试没有其他目的 Phase 1 ：测试的目的是为了表明软件能够工作 Phase 2 ：测试的目的是为了表明软件不能够能够正常工作 Phase 3 ：测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度
• Phase 4 ： 测试不是行为，而是一种自觉的约束 (mental discipline) ，不用太多的测试投入产生低风险的软件上的 。

软件测试模型的演变

　软件测试模型与软件测试标准的研究也随着软件工程的发展而越来越深入，在２０世纪８０年代后期Paul Rook提出了著名的软件测试的V模型，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。在图1-1中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。


　V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

　Evolutif公司针对V模型的缺陷，相对于V模型，提出了W模型的概念，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。


　但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。

　

izzj

软件测试工具的发展

　进入上世纪90年代，软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低；并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试，但是这还是不能满足大多数软件项目的统一需要。于是，很多测试实践者开始尝试开发商业的测试工具来支持测试，辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起来。人们普遍意识到，工具不仅仅是有用的，而且要对今天的软件系统进行充分的测试，工具是必不可少的。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现 “ 夜间测试 ” 和 “ 无人测试 ” 。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。而测试工具的选择和推广也越来越受到重视。

　在软件测试工具平台方面，商业化的软件测试工具已经很多，如捕获/回放工具、Web测试工具、性能测试工具、测试管理工具、代码测试工具等等，这些都有严格的版权限制且价格较为昂贵，但由于价格和版权的限制无法自由使用，当然，一些软件测试工具开发商对于某些测试工具提供了Beta测试版本以供用户有限次数使用。幸运的是，在开放源码社区中也出现了许多软件测试工具，已得到广泛应用且相当成熟和完善。

izzj

软件工程模型 　谈起测试学，不得不讨论一下软件工程模型，因为测试学与软件工程学的发展依依相关，相辅相成。另外对于比较先进的测试理念，测试工程师应该贯穿于软件工程的整体过程之中。 　瀑布模型 　这个模型大概是现在最经典的软件工程模型，业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。 但是这个模型存在着比较严重的问题： 　1，不可反复，不适应与需求变更处理：由于瀑布模型从业务建模到部署一脉相承，不可以回复。现代软件项目中需求变更是无处不存在的：唯一不变的就是需求变更。而运用这种模型，只要项目需求发生变化，就要打翻重新进行系统分析，概要设计，详细设计… 　2，用户很难在项目初期了解项目状态：由于用户在项目初期很难提出自己的需求，他们有时候也不知道该做些啥？而利用瀑布模型只有到编码结束，用户才可以看到正正他们所需要的产品，而初期这些产品往往是他们所了解不全的，需要补充的，客户往往在这个时期推翻他们的需求，要求另立需求，这样往往给客户方，需求方带来比较麻烦的结果。 　迭代模型和螺旋模型： 　这两个模型往往在概念上区别不明显，许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级，从最基础的进行分析，设计，编码，测试，然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形，进行需求变更和下一轮的建议，由于初期开发工作比较少，用户又可以在产品初期提出相对可观的下一轮的需求，所以这样的模型往往利于现在软件公司产品的开发，著名的RUP工具每一项都遵循迭代的思想。 　测试模型 　V模型 　单元测试相对于编码进行，这一步往往由测试人员来执行； 　集成测试相对于详细设计，他将模块由上到下，由下到上进行逐步的集成。以测试模块与模块，类与类之间的关联性； 　系统测试是相对于总体设计而言的，测试人员站在用户的角度对系统进行全面的测试工作； 　接收测试是用户对产品进行测试，一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试；Beta测试往往是指定客户对公司进行测试，是系统推出市场之前，测试阶段推出的第二个版本。 　V模型可以运用于瀑布模型和迭代模型 　X模型 　X模型是将软件系统分为罗干模块，对每个模块进行单元，集成以及系统测试，然后统一对模块进行集成测试，这种测试方法目前软件行业处于淘汰趋势。 　前置模型 　图示中所列出的是面向对象的前置模型，其他编成方法的前置模型大小意，就是将测试贯穿于软件开发的全部过程。在需求，设计和编码阶段对产生的工件进行复审，提出自己的建议和意见。对于前置软件测试法，bug在软件前期就可以发现从而降低软件开发成本。 　不利用前置方法的bug曲线。 　利用前置方法的bug曲线,bug在开始之前就能够被发现。 　软件测试方法 白盒 黑盒 动态 就是利用KDE的调试功能逐步调试程序，进行测试 就是普通所说的通过人工或者自动方法进行测试 静态 即test review 就是对需求，设计工件进行审核 软件测试步骤 　测试计划 　书写测试用例 　开发测试代码 　开展测试工作（往往需要进行几次轮测包括测试和复测，每次对于测试中的bug，要求开发人员给与明确答复修改完毕，非法bug以及下一版中解决） 　2 评估测试 　软件测试类型 　1.数据和数据库完整性测试 　在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。 　2.功能测试 　对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要： 　3.UI测试 　用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化测试。 　4.性能测试 　4.1负载测试： 　负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 　4.2强度测试 　是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 　4.3容量测试 　容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。 　4.4基准测试 　与已知系统的比较 　4.5竞争测试 　软件竞争使用各种资源（数据纪录，内存等） 　5. 安全性和访问控制测试 　安全性和访问控制测试侧重于安全性的两个关键方面： 　应用程序级别的安全性，包括对数据或业务功能的访问 　系统级别的安全性，包括对系统的登录或远程访问。 　应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一” 能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。 系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。 　6.故障转移和恢复测试 　可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。 故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。 　恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。 　7.配置测试 　配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本。OS版本等） 　8.安装测试 　安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。 　9.本地化测试 　又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。 　10.文字测试 　测试文字是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否由出入等等，包括图片文字 　11.分辨率测试 　测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试 　12发布测试 　主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试 　12.1说明书测试 　主要为语言检查，功能检查，图片检查 　语言检查：检查说明书语言是否正确，用词是否易于理解； 　功能检查：功能是否描述完全，或者描述了并没有的功能等； 　图片检查:：检查图片是否正确 　12.2宣传材料测试 　主要测试产品中的附带的宣传材料中的语言，描述功能，图片 　12.3帮助文件测试 　帮助文件是否正确，易懂，是否人性化 　12.4广告用语 　产品出公司前的广告材料文字，功能，图片，人性化的检查 　软件测试曲线 　大家都知道软件的bug是不可能为零的，它一般随着时间的推移bug数逼近于零，用一个曲线图表示： 　这里横坐标是时间，纵坐标是还没有发现的bugs数。项目开始之前bug为无穷大，随着时间的推移，bug趋于零但是不会等于零。 　由于bug不会等于零，难道产品就不发布了吗？还有一种bug可以确定产品发布时间。 　横坐标为时间，纵坐标是已经发现的bugs数，当这个曲线趋于平稳，也就是说它的斜率趋于零的时候，这个产品就可以发布了。 　软件的杀虫剂现象 　由于测试人员的思路不尽相同，每个人测试的侧重点不同，由于都按照测试用例进行测试，但是测试用例一般仅描述系统的一些基本测试项，不会将所有的测试用例方方面面都写到，有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日，第一天到第四天报出许多bug,但从第五天开始几乎报不出啥 bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差，只能说，该产品已经对A产生了抗药性，这就是测试学中的杀虫剂现象。用图表示： 　所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作，以避免杀虫剂现象产生。

izzj

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

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

　　实际上，这里暗示了“软件测试”在不同侧面上的含义，也就决定了对软件测试不同的定义和不同的理解。根据作者多年的经验和理解，软件测试的不同视野，概括为如下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的一致性。

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

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

　　软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，

　　其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

　　来源:http://tb.blog.csdn.net/TrackBack.aspx?PostId=982259

119139107

很全很详细  
谢谢楼主
收藏了
学习中。。。。

echo22200

Thanks

tesn

thanks  very  much!!!!

qzai

谢谢楼主
好好学习