x模型

针对v模型的改进

解决交接和频繁集成的周期问题

探索式测试

不进行事先计划

w模型

双v模型

及时了解项目风险，及早制定对应方案

局限性

开发过程是串行的，不能支持迭代开发模型

 v模型

目前使用最广泛

强调软件开发的协作和速度

反应测试活动和分析设计的关系

将软件的验证和实现有机的结合起来

明确界定测试过程有不同阶段

明确测试的不同阶段与研发过程每个阶段的对应关系

 瀑布模型的优缺点

传统的瀑布模型

传统的瀑布开发模式，也是最早出现的软件开发模型

按测试手段分类

根据测试对象的可见度：黑盒测试、 白盒测试

根据状态：静态测试、动态测试

执行方式：手工测试、自动化测试

黑盒测试：

不考虑程序内部结构和内部特性下，通过相关暴露出的接口，对程序进行测试。

只检查程序的功能是否按照需求规定，正常使用；

程序是否能输入数据，并产生正确的输出信息；

不考虑内部的逻辑；

一般针对软件外面的界面，可见的功能；

从用户的视角，通过不同数据事件，通过输出结果进行判断；

优点：

1．容易实施，不需要关注内部的实现

2．更贴近用户的使用角度

缺点：

1．测试覆盖率较低，一般只能覆盖到代码量的不到40%

2．针对黑盒的自动化测试，复用率较低，维护成本较高。因：产品活动增/删（更新）

黑盒测试主要测试什么 ？

1．是否有不正确或遗漏的功能？

2．在接口上，输入是否能正确的接受？能否输出正确的结果？

3．是否有数据结构错误或外部信息（例如数据文件）访问错误？

4．性能上是否能够满足要求

系统测试阶段  用黑盒测试比较多

黑盒测试的主要设计方法

等价类划分法：针对程序的输入条件进行分类，输入典型的数据

边界值分析法：特殊的边界数据，测试代码的边界状态

错误推测法：基于经验，直觉，判断错误的地方；特殊字符，文件不存在

因果图法：根据输入输出看做原因和结果，形成因果图。（因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。）

正交试验分析法：选出代表性的数据，作为输入数据

状态迁移图法：软件审批的过程，各种状态迁移

流程分析法：处理程序逻辑执行的路径

白盒测试（结构化测试，透明盒测试）：逻辑可见，逻辑覆盖率

主要的逻辑单位：            

语句覆盖：保证每条语句至少执行一次

分支（判定）：保证每条分支至少执行一次

条件：条件表达式，至少计算一次  

条件组合：所有不同条件的组合情况

路径：程序中，每个可能的路径至少执行一次

优点

1．迫使测试人员去仔细思考软件的实现，理解原理

2．可以检测代码中的每条分支和路径

3．揭示隐藏在代码中的错误

4．对代码的测试比较彻底

缺点

1．昂贵。

2．无法检测代码中遗漏的路径和数据敏感性错误

3．不能直接验证需求的正确性

白盒测试的主要测试方法

1、代码检测法：桌面检查、代码走查/审查

2、静态结构分析法：使用测试工具分析内部结构

3、静态质量度量法：根据标准的质量模型为基准，制造度量模型进行评估

4、逻辑覆盖法：语句、条件、条件组合、分支（判定）、路径、条件和判定的组合覆盖

5、基本路径测试法：分析圈复杂度

【灰盒测试】

定义：介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现

【静态测试】

定义：

静态测试是指无需执行检测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率

方式：

互审(不正式)<-走查->会议（正式）

【动态测试】

定义：

动态测试是指通过运行检查程序，检查运行结果与预期结果的差异，并分析运行效率，正确性和健壮性等，黑盒测试的主要测试方法，主要是动态测试。白盒测试的主要测试方法，是静态测试。

【手工测试】

定义：

由专门的测试人员从用户视角来验证软件是否满足设计要求的行为，更实用针对深度的测试和强调主观判断的测试。比如众包和探索式测试

【自动化测试】

定义：

使用单独的测试工具软件控制测试的自动化执行以及对预期的结果进行自动检查，比如单元、接口和性能测试等

手工测试vs自动化测试：

1、易发现缺陷 高效率、速度快

2、容易实施 高复用性

3、创造性、灵活性 覆盖丰富易度量

4、覆盖量化难 准确、可靠

5、重复测试率低 不知疲劳

6、不一致性，可靠性低 机械，发现缺陷率低

7、人力资源依赖 一次性投入较大

软检测试分类：

单元测试：单元测试就是对一个代码模块进行测试，一般都是开发做的，

集成测试：在单元测试完成的基础上，针对已经完成单元测试的那些模块，并把它们组装成更高一级的模块和子系统，针对这些子系统进行的一个集成

系统测试：在集成系统的基础上，把他作为整个计算机系统的一个部分，与系统中其他部分结合起来运行。更多的是用真实的运行环境

验收测试：也称交付测试，针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准。

1.软件测试的分类

(1)按软件测试阶段分类：单元测试、集成测试、系统测试、验收测试

 a.单元测试：对软件中的最小可测试单元进行检查和验证。(注意单元的概念)

  单元测试原则：

     1.尽可能保证各个测试用例是相互独立的。(尽量避免在测试类中调用其他的依赖类)

     2.一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。 (结对测试，单元测试要求测试人员对要测试的程序有一定的了解)

 单元测试的益处：

       1.尽早发现缺陷； (敏捷测试   TDD：先编写单元测试，再编写程序代码)

       2.有利于重构  

       3.简化集成 (保证最小单元模块的稳定性，为集成测试打好基础)    

       4.文档  (代码级文档：尽可能的减少文本文档 )

       5.用于设计                                                

单元测试限制：

      1.不可能覆盖所有的执行路径，发现所有路径的错误

      2.每一行代码 一般需要3~5行测试代码才能完成单元测试，存在投入和产出的一个平衡

b. 集成测试：在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动

    集成测试的主要实施方案：

       Bigbang（一次性集成，大爆炸）：把大部分的开发模块都耦合起来，形成一个完整的软件系统，然后一起做软件测试。

        自顶向下：递增的组装软件结构，从主程序开始，从控制层，逐层向下测试。

         自底向上（最常用）：最底层的模块开始，向上逐层测试。优点：更好锁定有问题的地方。

         核心系统集成：先对核心部分测试

         高频集成：每隔一段时间，就对现有代码进行集成测试。

    单元和集成区别：

        测试对象不同（单元：软件基本单元；集成：模块与子系统）

        测试依据不同（单元：软件详细设计；集成：概要设计）            

        测试方法不同 （集成：接口；单元：单元的类）

   系统测试：是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件的问题，保证系统的正常运行。

   关注点：

   关注系统本身的使用、

   关注系统与其他系统间的连通、

   关注系统在不同压力下的表现、

   关注系统在真实环境下的表现

  系统测试和集成测试

   1.测试对象不同：

      集成：由通过了单元测试的各个模块集成起来的构件；                            

      系统：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统。

      2.测试时间：

           集成测试介于单元测试和系统测试之间，系统测试在集成测试之后

      3.测试内容：

           集成：各个单元模块之间的接口

           系统：整个系统完整的功能

       4.测试角度：

            集成：偏于技术；

            系统：偏于业务

  验收测试：

        确定系统是否满足验收标准 用户验收测试和运行验收测试、合同和规范验收、alpha测试（开发者环境）、beta测试（用户环境）

1.软件测试的定义

  早期定义：软件测试是对程序能够按预期运行建立起一种信心。

  经典定义：测试是为发现错误而执行程序的过程。

  IEEE(规范定义)：使用人工或自动的手段来运行或测量软件系统的过程，以检测软件系统是否满足规定的要求，并找出与预期结果之间的差异。

2.软件测试的对象

软件需求，概要设计，详细设计，源代码，可运行程序，可运行环境。

3. 软件测试的五大要素及两大目标

五大要素：

质量(最为核心)

人员(决定因素,决定技术，流程，资源的配置使用)

技术(手段)【测试技术，方法，测试工具】

资源【测试所需的硬件，网络环境，测试数据，测试生命周期，测试时间】

流程(测试标准，规范)【测试计划，测试用例，测试执行，报告】

目标:

   1.提升测试覆盖率

   2.提升测试效率

4.软测的遵循原则:

  1.测试是为了发现错误而不是证明没错误

  2.穷尽测试是不可能的，应设定终止条件(无穷无尽的测试是不可能的，需很大代价;无论怎样测试，我们不可能发现软件的所有缺陷)

  3.测试尽早进行

  4.缺陷具有群集性(发现好多缺陷的模块，说明该模块存在没有被发现的缺陷)

  5.测试的杀虫剂悖论(应对测试用例，测试方法不定期的评审，添加新的测试用例或测试方法发现新的缺陷)

  6.测试的二八原则(80%的时间测试20%的重要模块)

  7.测试活动依赖于测试背景(如电信这块主要性能测试，银行啥的主要安全测试)

2.按测试手段来分类：

 - 按测试时对象的可见度：黑盒测试、白盒测试

- 根据状态：静态测试（不允许程序）、动态测试（运行程序）

 - 根据测试执行的方式：手工测试、自动化测试

2.1 黑盒测试：又称功能测试。将软件看成不能打开的盒子，在完全不考虑程序内部结构和特性的情况下，通过暴露出来的接口，对软件进行测试。只检查程序的功能是否能按照需求规格说明的规定正常使用

 - 优点：容易实施，不需要关注内部的实现

              更贴近用户的使用角度

 - 缺点：测试覆盖率较低，一般只能覆盖到代码量的不到40%

               针对黑盒的自动化测试，复用率较低，维护成本较高（因为功能总在变）。

- 黑盒测试主要测试/关注什么？

• 是否有不正确或遗漏的功能？

• 在接口上，输入是否能正确的接受？能否输出正确的结果？

• 是否有数据结构错误或外部信息（例如数据文件）访问错误？

• 性能上是否能够满足要求？
  

- 黑盒测试的主要设计方法

• 等价类划分法

• 边界值分析法：洽好等于、洽好大于、恰好小于

• 错误推测法：基于经验或直觉判断程序中可能出错的地方，从而针对性的设计用例的方法。比如界面输入的特殊字符、空值，处理文件时考虑文件不存在或文件超大等特殊情况

• 因果图法

• 正交试验分析法

• 状态迁移图法：例如“审批”功能的状态的迁移

• 流程分析法：通过梳理程序的逻辑执行的路径来设计测试用例的方法

2.2 白盒测试：又称结构测试或透明盒测试。针对程序的逻辑结构来设计测试用例。

 - 主要的逻辑单位：语句、条件、条件组合、分支、路径

 不同的逻辑单位有不同的覆盖方法。

 - 白盒测试的优点：

• 迫使测试人员去仔细思考软件的实现，理解原理

• 可以检测代码中的每条分支和路径

• 揭示隐藏在代码中的错误

• 对代码的测试比较彻底

 - 白盒测试的缺点

• 昂贵，因为需要做到较高的覆盖率

• 无法检测代码中遗漏的路径和数据敏感性错误

• 不能直接验证需求的正确性

 - 白盒测试的主要测试方法

• 代码检测法

• 静态结构分析法

• 静态质量度量法

• 逻辑覆盖法：语句覆盖、条件覆盖、条件组合覆盖、分支覆盖（判定覆盖）、路径覆盖、条件和判定的组合覆盖

• 基本路径测试法：在程序控制流图的基础上，通过分析控制构造的圈复杂度，导出基本可执行路径的集合，进而设计测试用例的方法

2.3 灰盒测试：介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现

2.4 静态测试：是指无需执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。

 - 静态测试的方式

• 互审

• 走查

• 会议

2.5 动态测试：动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。

2.6 手工测试：由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用于针对深度的测试或强调主观判断的测试。（众包测试、探索式测试）

2.7  自动化测试：使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查（单元测试、接口测试、性能测试等）

 - 手工测试vs自动化测试的优缺点

     手工测试：

• • 易发现缺陷

  • 容易实施

  • 创造性、灵活性

  • 覆盖量化难

  • 覆盖测试效率低

  • 不一致性、可靠性低

  • 人力资源依赖

自动化测试

• 高效率、速度快

• 高复用性

• 覆盖率容易度量

• 准确、可靠

• 不知疲劳

• 机械、发现缺陷率低

• 一次性投入较大
  

2-1软件测试阶段

软件测试的分类

1. 按测试阶段来分类：单元测试、集成测试、系统测试、验收测试

    1.1单元测试：对软件中最小可测试单元进行检查和验证

    - 单元测试的原则：

• 尽可能保证各个测试用例是互相独立的：避免在一个测试类中调用其他的依赖的类

• 一般由代码的开发人员来实施，用以检验所开发的代码是否符合自己的设计要求。

- 单元测试的益处：

• 能尽早的发现缺陷

• 有利于重构

• 简化集成：通过单元测试保障了最小模块的稳定性和正确性，为之后的集成测试奠定了基础

• 减少文档

• 用于设计

- 单元测试的限制

• 不可能覆盖所有的执行路径，所以不可能保证捕捉到所有的路径错误

• 每一行功能代码，一般需要3~5行测试代码才能完成单元测试。所以存在投入和产出的一个平衡。

- 单元测试框架： JUnit、nunit、PHPUnit、CPPUnit

1.2 集成测试：在单元测试的基础上，测试在将所有的软件单元按照概要设计的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。/测试的是已经经过单元测试的单元模块集成的更高一级的模块或子系统之间的接口。

- 集成测试的主要实施方案

• Big Bang （一次性集成）

• 自顶向下：从主程序开始，延控制层逐层向下测试

• 自底向上：从最底层模块开始，逐层向上组装测试。（比较好的锁定软件问题所在位置）

• 核心系统集成：从核心系统扩展到外围

• 高频集成

1.3 集成测试&单元测试的区别

• 测试对象不同：单元测试针对软件基本单元，集成测试针对单元测试过的模块组装成的模块或子系统，主要针对模块与模块间的接口

• 测试的依据不同：单元测试主要依据软件的详细设计；集成测试主要针对软件的概要设计

• 测试的方法不同：单元测试只关心单元内部；集成测试主要关注模块间接口的集成

1.4 系统测试：将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。（一般要做功能测试、性能测试、稳定性测试等多种测试类型的测试）

 - 关注点

• 关注系统本身的使用

• 关注系统与其他相关系统间连通

• 关注系统在不同使用压力下的表现：例如，大并发量、达到极限内存时软件的表现

• 关注系统在真实使用环境下的表现

1.5系统测试&集成测试的区别

• 测试对象不同

  集成测试：由通过了单元测试的各个模块所集成起来的组件

  系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持的软件、系统操作人员等整个系统

• 测试时间

  集成测试介于单元测试和系统测试之间测试

  系统测试在集成测试之后

• 测试内容

  集成测试：各个单元模块之间的接口

  系统测试：整个系统的功能和性能

• 测试角度

  集成测试：偏于技术角度的验证

  系统测试：偏于业务角度的验证

1.6 验收测试：也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。

 - 细分

• 用户验收测试

• 运行验收测试

• 合同和规范验收测试

• alpha测试：开发者所提供的环境下运行的测试

• Beta测试：在用户提供的环境下运行的测试

• （验收测试驱动开发：在敏捷开发中的应用）
  

1-1软件测试概要

测试：为了发现产品（软件）的问题而操作产品（软件）的过程。/

           测试是为了发现错误而执行程序的过程。 - Myers，1979

           使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。 - IEEE定义（ISO/IEC/IEEE 29119）

软件测试的测试对象：软件研发周期的方方面面。软件需求、软件概要设计、软件详细设计、软件运行环境、软件源代码、可运行程序。

五大要素（质量、人员、资源、流程、技术）和两个目标（保证质量：提高测试覆盖率、提升测试效率）

软件测试所遵循的原则：

1. 测试显示缺陷的存在，但不能证明系统不存在缺陷

2. 穷尽测试是不可能的，应设定及时终止的条件

3. 测试应该尽早进行

4. 缺陷具备群集特性：越是发现问题多的模块，越存在更多未发现的问题。

5. 测试的杀虫剂悖论：测试用例、测试方法需要及时更新，不定期评审和修改

6. 测试的二八原则：因为时间和资源有限，把80%的时间用在20%的重点模块上，重点测试软件的重要模块

7. 测试活动依赖于测试背景：如，电信更看重性能和大并发量；金融更看重安全性
   

回顾总结：

A/B测试：

冒烟测试：