CMMI简介(2)

一、CMMI的起源

     随着人们对CMM研究的不断深入，其他学科也结合本系统的特点，陆续推出了自己的CMM模型。例如，人力资源能力成熟度模型、系统工程能力成熟度模型等等：
（1） SW-CMM (Software CMM) 软件CMM
（2） SE-CMM (System Engineering CMM) 系统工程CMM
（3） SA-CMM (Software Acquisition CMM) 软件采购CMM
（4） IPT-CMM (Integrated Product Team CMM) 集成产品群组CMM
（5） P-CMM (People CMM) 人力资源能力成熟度模型

     为了以示区别，国内外很多资料把CMM叫做SW-CMM。按照SEI原来的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0得实践反馈意见之后，在1999年完成准CMM2.0版本。但是，美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI。

      CMMI（Capability Maturity Model Integration）即能力成熟度集成模型，这也是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件采购方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。就软件而言，CMMI是SW-CMM的修订本。它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科学和更周密的优点。SEI在发表CMMI-SE/SW 1.0版时，宣布大约用两年的时间完成从CMM到CMMI的过渡。

CMMI项目更为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。

二、实施CMMI的意义

很多人认为，实施CMMI的意义在于项目工程走向世界，可以在西方国家接到订单。实际上，这只是我国企业实施CMMI的意义的很小一部分。

更为重要的意义则是，CMMI的实施能够提高我国企业的管理水平。降低企业的工程成本。事实表明，企业实施CMMI技术的投入都会得到丰厚的回报。据SEI统计，用于软件项目上的CMMI的投资，其回报率在5:1到8:1之间。由此可见，为什么这么多的企业纷纷实施CMMI项目管理技术。

      近年来，很多软件企业纷纷实施CMMI管理模式，这一方面反映了我国企业在进入WTO后的危机意识，以及与世界接轨的迫切愿望。另一方面则反映出我国软件企业在改进管理方法上所作的努力。但是CMMI到底能够为我们做什么呢？实际上这个问题对不同的人有不同的答案。对采购部门的人员来说，掌握了CMMI技术可以有目的地考察项目实施人员或公司的实施能力，从而保证所采购的项目能够顺利完成。对于项目经理来说，掌握CMMI技术能够提高自己的管理能力，从而能够使项目高质量，低成本，按期限地完成。对于企业老总来说，CMMI还能够引入科学的管理理念，提升企业的整体管理水平。

在美国，很多企业通过CMMI评估，一方面为了满足承包国防工程或一些大企业的工程的要求，另一方面也是为了提高企业自身的管理能力。美国政府的工程项目，绝大多数都要求承包商有一定的CMMI级别作为参加投标的资格。越来越多的大型企业开始要求其工程承包商具有一定的CMMI级别。级别高的企业在赢得项目的竞标中具有一定的优势。因此，如果没有CMMI的等级评估，企业就会失去很多商机。

三、CMMI的两种实施方法

      CMMI有两种不同的实施方法，不同的实施方法，其级别表示不同的内容。CMMI的一实施方法为连续式，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。而另一种实施方法为阶段性。它主要是衡量一个企业的成熟度，亦即是企业在项目实施上的综合实力。企业在进行评估时，一定要由评估师来挑选企业内部的任何项目，甚至于任何项目的任何部分。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够有一级。阶段性实施方法的难度要大一些。

虽然，CMMI的表述方式不同，但其实质内容是完全一样的。是同一种方法的两种不同的表述方式。企业在准备评估时要做的准备工作也是完全一样的。这些工作对企业的管理上的帮助也是一样的。因此，不管企业需要做什么样的评估，企业所获取的实惠应该是差别不大。具体要做连续性评估，还是做阶段性评估则要看企业对等级评估证书的具体要求。

四、CMMI可以帮助我们做什么

　　近年来，很多软件企业纷纷实施CMMI管理模式，不少企业如：东软，托普，华为等企业通过了三级或四级评估。 这一方面反映了我国企业在进入WTO后的危机意识，以及与世界接轨的迫切愿望。另一方面则反映出我国软件企业在改进管理方法上所作的努力。但是CMMI到底能够为我们做什么呢？实际上这个问题对不同的人有不同的答案。对采购部门的人员来说，掌握了CMMI技术可以有目的地考察项目实施人员或公司的实施能力，从而保证所采购的项目能够顺利完成。对于项目经理来说，掌握CMMI技术能够提高自己的项目管理能力， 从而能够使项目高质量，低成本，按期限地完成。 对于企业老总来说，CMMI技术不仅能够提升企业的管理水平，还能够引入科学的管理理念，提升企业的整体管理水平。

在美国，很多企业通过CMMI评估一方面为了满足承包国防工程或一些大企业的工程的要求， 另一方面也是为了提高企业自身的管理能力。美国政府的工程项目，绝大多数都要求承包商具有一定的CMMI级别作为参加投标的资格。越来越多的大型企业业开始要求其工程承包商具有一定的CMMI级别。级别高的企业在赢得项目的竞标中具有一定的优势。 因此，如果没有CMMI的等级评估，企业就会失去很多商机。另一方面，企业通过CMMI评估也是为了提升企业内部的管理水平，降低企业的工程成本。企业在实施CMMI技术的投入都会得到丰厚的回报。据SEI统计，用于软件项目上的CMMI的投资，其回报率在5：1到8：1之间。由此可见，为什么这么多的企业纷纷实施CMMI项目管理技术。

五、CMMI的基本表述

如果一家企业对外宣称自己通过了CMMI三级评估，外行的人会觉得还不错，因为三级比二级要高。 内行的人则要问通过了三级什么？ 因为，CMMI有两种不同的表述方式，不同的表述方式，其级别表示不同的内容。CMMI的一种表述方式为连续表述，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。而另一种表述方式为阶段性。它主要是衡量一个企业的成熟度，也即是企业在项目实施上的综合实力。企业在进行评估时，一定要由评估师来挑选企业内部的任何项目，甚至于任何项目的任何部分。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够有一级。阶段性表述的难度要大一些。
　　虽然，CMMI的表述方式不同，但其实质内容是完全一样的。是同一种方法的两种不同的表达方式。企业在准备评估时要做的准备工作也是完全一样的。这些工作对企业的管理上的帮助也是一样的。因此，不能企业需要做什么样的评估，企业所获取的实惠应该是差别不大。具体要做连续性评估，还是做阶段性评估则是看企业对等级评估证书的具体要求。

六、CMMI的五个台阶

       台阶一：CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。

       台阶二：CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。

      台阶三：CMMI三级，定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。

      台阶四：CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。

       台阶五：CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。

      由上述的五个台阶我们可以看出，每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶。企业在实施CMMI的时候，路要一步一步地走。一般地讲，应该先从二级入手。在管理上下功夫。争取最终实现CMMI的第五级。

                                         (转自www.itisedu.com)

CMMI简介(1)

CMMI 的全称为：

Capability Maturity Model Integration，即能力成熟度模型集成。

CMMI是CMM模型的最新版本。

早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。

      自从1994 年SEI 正式发布软件CMM 以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：

      不能集中其不同过程改进的能力以取得更大成绩；
      要进行一些重复的培训、评估和改进活动，因而增加了许多成本；
      遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触。

      于是，希望整合不同CMM 模型的需求产生了。1997 年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM 和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。

     CMMI 与CMM 最大的不同点在于： CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。

     CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。

    而连续式表现方法则通过将CMMI 中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。

     这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。

CMMI各个进程的关键元素

CMMI自出道以来，它所达到的目标就没有变过，第一个是质量，第二个是时间表，第三就是要用最低的成本。

不过特别强调的是，CMMI不是传统的、仅局限于软件开发的生命周期，它应该被运用于更广泛的一个范畴——工程设计的生命周期。TSP的建立，也是为了支持CMMI的这样一个系统。　　

那么CMMI究竟是什么呢？它并不是一个过程，也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI，它就是各个进程的一个关键的元素，在很多领域里面一个集成的点。

它是这样的一个基本架构，能够用来度量你的有效性和实用性；能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。

软件测试工程师薪资调查

因修正错误而存在——软件测试工程师

　　所属门派：IT业
　　“假如存在没有任何错误的程序，那么世界也会不复存在。”
　　因错误而存在，因修正错误而存在，这就是软件测试工程师的存在之道。虽然测试不是解决错误的根本举措，但却是必须的手段。
    软件测试工程师（Software Testing Engineer）的主要工作职责是，理解产品的功能要求，并对其进行测试，检查软件有没有错误（Bug），决定软件是否具有稳定性（Robustness），写出相应的测试规范和测试案例。

简而言之，软件测试工程师在一家软件企业中担当的是“质量管理”角色，及时纠错及时更正，确保产品的正常运作。据有关调查数据表明，目前国内许多软件企业内部的测试人员和开发人员之比在1：5，与国外软件业1：1的比例还相去甚远。

　　门派技能：
　　软件测试工程师主要职责为：
　　1、负责项目/产品的测试工作，分析产品需求，建立测试环境和计划，保证产品质量以及测试工作的顺利进行；
　　2、按照软件工程规范和项目管理流程，实施、管理和知道软件开发不同阶段的各种测试，并提交测试报告。测试的计划安排包括人员安排、进度、使用的软硬件环境、测试的流程等；
　　3、提交测试报告，并撰写用户说明书；
　　4、参与软件测试技术和规范的改进和制定。

　　入门资质：
　　一般需要至少专科学历，一到两年测试工作经验。要熟悉软件的测试技术、方法、流程、测试文档，若想进一步提升，还要熟悉自动化测试的流程、管理及深层开发（包括测试框架等）；了解若干主流测试工具，如功能测试工具winrunner、quicktestpro，性能测试工具LoadRunner，配置管理工具TestDirecter, Visiual Source Safe等；熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP、PSP、TSP；了解软件工程，软件生命周期模型基础，了解软件配置管理；能够根据不同企业的产品特点，要求了解相应的开发测试方法。对于资深的软件测试人员，有些企业还要求其本身有自主开发测试工具的能力。
　　由于需要与开发人员及时沟通，因此作为一个出色的软件测试工程师，还需要有良好的沟通技巧以及优秀的言语表达能力，具备良好的团队合作精神。

　　入门经：
　　缜密的逻辑思维能力为了应对软件使用者千差万别的使用习惯和软件在使用过程中出现的各种现象，软件测试工程师应该具有逆向思维能力，能够以用户的角度出发，捕获一切可能性，对细节有不同寻常的关注能力。此外，软件测试工程师还要有穷追到底的精神，并且要善于沟通和撰写各类专业报告。
　　出色的沟通能力要成为优秀的软件测试工程师，要具备出色的沟通能力和表达能力，既能够和技术开发人员沟通无碍，又能用简洁明了的话语向客户、管理者等这些非技术人员阐述系统在哪些方面还有缺失有待改进。在同开发人员的沟通过程中，要注意沟通技巧，提高沟通效率，和开发人员保持良好的人际关系。当测试人员发现软件有问题时，不仅需要跟开发人员沟通，找到问题出在哪儿，阐述自己挑错的理由，有时候甚至要提出解决方案，直接参与前期需求和代码的修改。一个优秀的软件测试工程师能够适时地站在各自的立场上考虑、解释并解决问题，从而尽量避免冲突和对抗。
　　全面的技术能力作为软件测试工程师，虽然无须精通各种语言各类技术，但必须全面理解被测软件系统，明白该使用何种工具进行测试。要做到这一点一般需要有一定的编程经验，这些经验可以加深对软件开发过程的理解。
　　耐得住性子　软件测试工作是枯燥的，甚至重复性的，有时需要花费惊人的时间去分离、识别和分派一个错误，因此需要测试人员能静得下心耐得住性子。这个工作不容许有丝毫的心浮气躁。同时，逻辑严密但不乏重复成分的测试工作也容易使人倦怠，因此需要一定的自我督促能力。
　　规范测试流程公司不正规的测试流程，不标准的测试方法，将使软件测试人员终日陷入碌碌无为的点击按钮的不良状态中。

　　晋阶易筋经：
　　初级测试工程师
　　入门级，具有一些手工测试经验，开发测试脚本并开始熟悉测试生存周期和测试技术；
　　测试工程师
　　能够独立编写自动测试脚本程序并担任测试编程初期的领导工作，进一步拓展编程语言、操作系统、网络与数据库方面的技能；
　　高级测试工程师
　　帮助开发或维护测试或编程标准与过程，负责同级的评审，并能够指导初级的测试工程师；
　　Team Leader
　　一般具有5年左右工作经验，负责管理一个小团队。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，能够为用户提供支持与演示；
　　测试经理
　　能够担当测试领域内的整个开发生存周期业务，能够为用户提供交互和大量演示，负责项目成本、进度安排、计划和人员分工；
　　计划经理
　　具有多年纯熟的开发与支持（测试/质量保证）活动方面的经验，管理从事若干项目的人员以及整个开发生存周期，负责把握项目方向与盈亏责任。

　　秘传“薪”经：
　　薪资黄金点
　　软件测试工程师在IT行业中越来越受到重视，其薪资也节节高升。

测试工程师的起薪从2000～5000元/月不等，若有四年工作经验的话，薪资在8000元/月左右，具体视不同地域、不同性质企业、测试工程师的不同能力而定。一般工作5～8年的软件测试工程师的薪资是刚出道时的新手的一倍，而10年以上工作经验的软件测试工程师薪资却走了下坡路，和5～8年的从业者持平甚至有些企业开出了略低的薪资，看来这行的折旧率较高。
　　软件测试行业的从业者7成左右都拥有本科学历，本科学历的从业者的薪资约为大专学历从业者的1.33倍左右，而硕士学历的从业者薪资起点明显高于本科学历从业者，约为后者的1.49倍。一般外语能力精通者的薪资为平均薪资的1.29倍左右，熟练者为平均薪资的1.09倍，值得注意的是，深圳、杭州和大连的外语能力精通者的薪资均超出平均薪资不少，其中杭州的外语能力精通者的薪资是平均薪资的1.79倍。
　　以3.5年左右从业工作经验的软件测试工程师的各地薪资情况来看：
　　深圳地区的平均年薪是全国各城市最高的，超出7万元，其中外商独资欧美企业的年薪为7.8万元，国营企业的年薪紧随其后，超过了7.3万元，合资/合作非欧美企业的年薪较低，约为6万。
　　北京地区该职位的平均年薪逾5.8万元；其中外商独资企业的年薪为全国之最，将近8.5万元，而其余各类型企业的年薪都在5～6万元左右。
　　广州地区该职位的平均年薪约为4.5万元；其中外商独资欧美企业的年薪最高，达到了7万元；合资/合作欧美企业也能拿到6.2万元的平均年薪，合资/合作非欧美企业就较逊色，年薪不到4万元。
　　上海地区软件测试工程师的平均年薪为6.3万元，欧美独资和欧美合资的薪资不相上下，分别为7.9万和7.7万元。国营企业略高于平均线，达到6.5万元，其余各类企业则都表现平平。
　　杭州地区该职位的平均年薪达到了5.5万元；其中外商独资欧美企业和合资/合资欧美企业的年薪相当，均为6.9万元，国营企业的薪资也颇吸引人，超过了5.9万元，民营/私企和合资/合作非欧美企业的年薪均不到5万元。
　　大连地区该职位的平均年薪为3.8万元；其中外商独资企业和合资/合作欧美企业的年薪均超过了4.7万元；国营企业的软件测试工程师的年薪也近4万元左右，而民营/私企和合资/合作非欧美企业的年薪则相对较低。

　　福利
　　上海地区的软件测试工程师享有的带薪年假是全国各地最多的，一年中平均有10天，北京、广州、大连均为8天，杭州和深圳相对较少，为6天。
　　以上这些地区在软件测试的培训方面都做得不错，基本上均有6成以上的从业者可享受到公司提供的培训计划，但上海的软件工程师的培训比例不到5成。杭州和深圳两地的培训是全国各地区最出色的，逼近8成。
　　深圳、上海均有2成的从业者可享受房贴或者补充住房公积金，大连和北京则有3成以上的从业者可享受公司的房贴或者补充住房公积金，广州更是达到了4成以上，而杭州此项福利的比例较低，仅为1成。

                                          (转自blog.sina.com.cn/cqi)

软件测试的起源与发展

软件测试的概念与定义
     软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。
　　直到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还给出了与测试相关的三个重要观点，那就是：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测试版本以供用户有限次数使用。幸运的是，在开放源码社区中也出现了许多软件测试工具，已得到广泛应用且相当成熟和完善。