只是字面上说"我们要规范流程，我们要明确需求，我们要文档.."可不能使所有人信服，仍然有一些人认为这些不重要，或者认为在 "浪费时间"，那么我们看看下面的图就会理解，这些对我们有多么的重要了。

    我们做测试的最终目的都是保证质量，那么什么样的质量才算我们的目标，或者说我们要达到什么样的质量保证才算达标？有没有这样一个指标去衡量呢？

    软件质量的定义：一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。而质量就是实体基于这些特性满足需求的程度。

    软件质量的三个层次：a. 符合需求规格；b. 符合用户显示需求；c. 符合用户实际需求。

1. ISO9000 软件质量管理体系
2. CMM(Capabillty Maturity Moelel)软件质量成熟度模型  
3. 六西格马管理法
4. 软件质量模型(6大特性27子特性)

1. ISO9000 软件质量管理体系

     ISO9000：2000版标准

     ISO9000：制定管理理念和原则

     ISO9001：标准对组织质量管理体系必须履行的要求做了明确的规定，是对产品要求的进一进补充。（核心）

     ISO9004：是组织进行持续改进的指南标准。

     八项质量管理原则：

      一．以顾客为中心：组织依存于其顾客，因此，组织应理解顾客当前的和未来的需求，满足顾客要求并争取赶超顾客期望。

      二．领导作用： 领导者将本组织的宗旨.方向和内部环境编统一起来，并创造使员工能够充参与实现组织目标的环境。

      三．全员参与：  各级人员是组织之本，只有他们的充分参与，才能使他们的才干为组织带来最大的收益。

      四．过程方法： 将相关的资源和活动作为过程进行管理，可以更高效地得到期望的结果。

      五．管理系统方法：针对设定的目标，识别.理解并管理一个由相互关联的过程的过程所组成的体系，有助于提高组织的有效性和效率。

      六．持续改进：持续改进是组织的一个永恒的目标。

      七．基于事实的决策方法：对数据和信息的逻辑分析或直觉判断是有效决策的基础。

      八．互利的供方关系：通过互利的关系，增强组织及其供方创造价值的能力。

      其中与软件产品产品优其相关有：（一.三.六.七项）

2. CMM(Capabillty Maturity Moelel)软件质量成熟度模型 

    由于美国软件工程研究所（SEI）受美国国防部委托立项。
    开发人：Watts Humphrey.
    1991年推出CMM1.0版，1993年提出CMM1.1版
    现在开发CMMI（CMM Integration）
    软件能力成熟度模型CMM（提唱过程决定质量）

   1.CMM1级
   特点：（个人英雄主义）
   A项目的成功依赖于一个非常优秀的项目经理的团队。
   B无法重复以往成功的实践。
   C缺乏基本配置管理
   可视度：
   整个过程不可预测，不可见，不可控。（过程管理非常混乱）

   2.CMM2级
   特点：（有纪律）
   能够重复以前成功的经验和实践。
   引入合理需求变更（需求管理）
   测试与开发分离，整个过程能力可概为有纪律的。
   可视度
   原始需求——需求分析——设计——编码——测试——产品

   3.CMM3级
   特点：（有过程，经过同行评审）
   组织中有一个专门负责组织的标准软件过程。（SEPG）
   可视度
   同CMM2但整个过程是标准和一致的。

   4.CMM4级特点
   特点：（量化管理）
   过程能力是可预防的，因为过程是已测量的并在可测的范围内运行。组织能定量地预测过程和产品质量方面趋势。软件产品具有可预测的高质量。
   可视度
   同CMM3但整个过程是可预测的。

   5.CMM5级特点
   特点：（改进过程本身）
   通过缺陷来发现过程的不足。
   新的开发技术触使改进过程。
   可视度
   同CMM4级整个是以改进的。

   CMM的用途：a. 评估组用来识别组织中的强处和弱处；
             b. 评价组用来识别选择不同的业务承包商的风险和监督合同；
             c. 管理者用来了解其组织的能力，并了解为了提高其能力成熟度而进行软件过程改进所需进行的活动；
             d. 技术人员和过程改进组用来作为指南，指导他们在组织中定义和改进软件过程。

   ISO9001和CMM的关系与区别：
    相似点：强调管理、过程、规范化和文档化；
    不同点：CMM把焦点对准软件；ISO9001的范围包括：硬件、软件、流程性材料和服务；
    两者关系：CMM2级与ISO9001强相关；CMM的每个关键过程域至少按某种解释与ISO9001弱相关。

3.六西格马的管理办法（强调组织能力）
  本质：全面质量管理，不仅仅是质量提高手段

4.软件质量模型（六大特性27子特性）

    功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力。包括：适合性；准确性；互操作性；保密安全性；功能性的依从性。
    可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。包括：成熟性；容错性；易恢复性；可靠性的依从性。
    易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。包括：易理解性；易学性；易操作性；吸引性；易用性的依从性。
    效  率：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。包括：时间特性；资源利用性；效率依从性。
    维护性：软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应。包括：易分析性；易改变性；稳定性；易测试性；维护性的依从性。
    可移植性：软件产品从一种环境迁移到另外一种环境的能力。包括：适应性；易安装性；共存性；易替换性；可移植性的依从性。

  下图为软件测试全景图:

    以上是我们针对软件开发过程我们要进行的测试工作，对于老手来说这些已经非常熟悉了，新手看的越来越迷茫，没关系，我再发一张图，我们来一步一步对软件测试工作进行分析,如下图：

    首先从软件质量开始，一切围绕软件质量去开展我们的测试。软件技术、组织、流程是软件质量的铁三角。软件质量体系是软件开发的依据标准，软件开发的标准流程有大爆炸式开发、边写边改的原始模型、瀑布模型、螺旋模型、RUP模型、IPD模型等..；软件测试模型主要以双V模型为主。针对软件开发的SRS（需求规格说明书）、HLD（概要设计说明书）、LLD（详细设计说明书）进行需求评审，建立SRS、HLD、LLD基线，并以SRS做为ST（系统测试）的入口准则，进行ST计划、ST设计、ST实现（测试用例、测试规约、预测试项的编写）、ST执行；以HLD做为IT（集成测试）的入口准则，进行进行IT计划、IT设计、IT实现（IT测试用例、IT测试规程的编写）、IT执行；以LLD做为UT（单元测试）的入口准则，进行进行UT计划、UT设计、UT实现（UT测试用例、UT测试规程的编写）、UT执行；

       System Testing--系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

      Integration Testing--集成测试：也叫组装测试、联合测试、部件测试、子系统测试。集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有大爆炸、自顶向下、自底向上、三明治、基干、基于功能等等。

      Unit Testing--单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

      一般来讲，系统测试是黑盒测试范畴，把被测对象看做是一个黑盒子（看不到内部构造），根据SRS去测试它的功能（显示需求、隐式需求、特殊需求等..）评价ST测试的标准也是看测试用例对SRS的覆盖度。而单元测试则相对于系统测试则不关注它的功能，而是判断程序的逻辑覆盖率，也就是说把被测对象看做一个白盒子、透明盒子、玻璃盒子。我们能清楚的看到它的内部构造，我们评价UT测试的标准则是看Unit Test Case(单元测试用例)对程序的逻辑覆盖度。那么IT则是借于ST和UT之间的测试，主要关注于模块间，模块内部，模块于子模块的接口覆盖率，它就像一个灰盒子，我们能看到的只有齿轮于齿轮间的咬合，而不是去分析齿轮内部构造，也不必要测试它到底能完成什么功能。
      

1.   软件测试的目的：

    证明（表达软件能够工作）→ 检测（发现错误）→ 预防（管理质量）

2.软件测试的主要工作：

    a. 检视代码，评审开发文档；

    b. 进行测试设计，写作测试文档（测试计划、测试方案、测试用例等）；

    c. 执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正；

    d. 通过测试度量软件质量。

  根据以上的知识点进行知识架构的搭建，一步一步细化填充我们的测试框架.

是否需要进行软件测试取决于软件开发过程是否存在缺陷，前期的缺陷导致缺陷放大，使软件质量度低，进度、成本无法控制异常的庞大。从而得出的结论是：要尽早测试，尽早的发现问题。

软件危机的出现主要表现在：

1.         由于缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定；

2.         开发早期需求分析不够明确，造成开发后期矛盾集中暴露；

3.         不遵循开发规范，开发文档不完整，软件难以维护；

4.         缺乏严密有效的软件质量检测手段，交付给用户的软件质量差。

下图是软件危机关系图：