昨天舍友说她跟ilbe讲话了，呵呵，找了一些问题问他．然后就发现他很喜欢讲话的感 觉，估计是跟美女吧．
　　后来我出去跑步了，回来时他们还在聊，果真是小孩．然后他们就互加为好友了，聊了一大堆，他的头像果真是他女朋友的，长的很漂亮 哦．
　　然后我很无聊的跑去跟小健健讨论小春春是不是美女的问题，哎，也不能因为我逻辑不好，就又跑题了吧，最后还是被我逮住了．然后他 终于回了，她长的挺不错的．
　　额，后来跟reborn又聊了对于感恩的问题，发现自己很自私的认为别人对我做的都是理所当然，再这样下去．怎么死都不知道，所以要改 变．
　　西西，无聊吧，没什么中心的，不过是一晚上的事情．．．．

软件测试的起源与发展

https://www.itisedu.com/   2006-11-13 15:52:43   中科永联

软件测试的概念与定义       软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，那时软件规模都很小、复杂程度低 ，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故 障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。   　　直到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.&nb sp;”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为 目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a pro gram or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需 求或功能设计。他还把软件的质量定义为“符合要求”。他的思想的核心观点是：测试方法是试图验证软件是“工作的 ”，所谓“工作的”就是指软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确 性。软件测试业界把这种方法看作是的软件测试的第一类方法。   尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著 《The Art of Software Testing》）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的 ，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将 “验证软件是工作的”作为测试的目的， 非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过 程。 The process of executing a program or system with the intent of f inding errors.”这个定义，也被业界所认可，经常被引用。除此之外， Myers还给出了与测试相关的三个重要观点，那就是 ： 1、   测试是为了证明程序有错，而不是证明程序无错误；  2、   一个好的测试用例是在于它能发现至今未发现的错误； 3、   一个成功的测试是发现了至今未发现的错误的测试；     这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误 的。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查， 结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。Myers提出的“测试的目的是证伪”这 一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得 到了长足的发展。第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。   然而，对Glenford Myers先生“测试的目的是证伪”这一概念的理解也不能太过于片面。在很多软件工程学、软 件测试方面的书籍中都提到一个概念：“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”。这很容易让人们认为测试 人员就是“挑毛病”的，而由此带来诸多问题。大家熟悉的Ron Patton在《软件测试》（中文版由机械工业出版社出版，此书 是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试人员的目标是找到软件缺陷，尽可能早一些 ，并确保其得以修复。”这样的定义具有一定的片面性，带来的结果是： 1、 若测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现，测试活动往往会存在一定的随意性和盲目性； 2、 若有些软件企业接受了这样的方法，以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中，从左到右描述了基本的 开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关 系。       图 1-1   V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系 统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶 段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。   Evolutif公司针对V模型的缺陷，相对于V模型，提出了W模型的概念，W模型增加了软件各开发阶段中应同步进行的验证和确认活 动。如图1-2所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。     W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试 ，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和 确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测 试时间，加快项目进度。        但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动 也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。     软件测试工具的发展   进入上世纪90年代，软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时 间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低；并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测 试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试，但是这还是不能满足大多数软件项目的统一需要。于 是，很多测试实践者开始尝试开发商业的测试工具来支持测试，辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起 来。人们普遍意识到，工具不仅仅是有用的，而且要对今天的软件系统进行充分的测试，工具是必不可少的。测试工具可以进行部分的测试设 计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。测试工具的发展，大大提高了软件测试的自动化程度，让 测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。采用自动比较技术，还可以自动完成测试用例执行结果的 判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现 “ 夜间测试  ” 和 “ 无人测试 ” 。在大多数情况下，软件测试自动化可以减少开支，增加有限时间 内可执行的测试，在执行相同数量测试时节约测试时间。 而测试工具的选择和推广也越来越受到重视。   在软件测试工具平台方面，商业化的软件测试工具已经很多，如捕获/回放工具、Web测试工具、性能测试工具、测试管理工具、 代码测试工具等等，这些都有严格的版权限制且价格较为昂贵，但由于价格和版权的限制无法自由使用，当然，一些软件测试工具开发商对于 某些测试工具提供了Beta测试版本以供用户有限次数使用。幸运的是，在开放源码社区中也出现了许多软件测试工具，已得到广泛应用且相当 成熟和完善。

来源：51testing blog

An experienced programmer would probably agree at this point that
many of these 42 test cases represent common errors that might have
been made in developing this program, yet most of these errors probably
would go undetected if a random or ad hoc test-case-generation
method were used. Boundary-value analysis, if practiced correctly, is
one of the most useful test-case-design methods. However, it often is
used ineffectively because the technique, on the surface, sounds simple.
You should understand that boundary conditions may be very subtle
and, hence, identification of them requires a lot of thought.

An experienced programmer probably agree that the majority of the 42 test cases represent the common mistakes which are made during during the developing process. But if we generate test cases randomly or by any special methods, the majority mistakes will not be found. Being used correctly, bound-value analising is one of the most effective methods to desigh test cases. But usually this method is not used properly, because it sounds very simple. We should realize that the bound conditions are so subtle that it will take us some time to find them.

Trackback: https://tb.blog.csdn.net/TrackBack.aspx?PostId=543344