BUG

1. BUG名词解释：软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能或者性能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效

   1. 没有做它应该做的事情。

   2. 做了不该做的事。

   3. 做一些它没有提到的事情。

   4. 没有做它没有提到但应该做的事情。

   5. 它很难理解，难以使用，运行缓慢，或者——在软件测试人员看来——最终用户会认为它完全不正确

2. 软件测试的定义：对软件产品进行充分测试，尽早找出其中的缺陷，并督促相关人员进行修复

Bug类型

Bug频率

Bug评测

1. severity（严重程度）

   • blocker：系统无法执行。常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误， 如服务器500错误。
   • critical：主要功能存在缺陷，但不会影响系统的稳定性。常见的有功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。
   • major：界面、性能缺陷、兼容性。常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。
   • minor/trivial：易用性及建议性问题

2. Priority（优先级）

   • immediate：马上解决
   • urgent：急需解决
   • high：高度重视，有时间要马上解决
   • low：在系统发布前解决，或可以不用解决

Bug的状态

Bug起源

Bug来源

Bug根源

测试驱动开发（TDD）

软件测试模型

V模型

• 不难看出，在V模型中，只是把测试作为编码之后的一个阶段，并没有在需求开发阶段就进入测试。这也算是他的一个缺点了。

W模型

• 可以看出，W模型增加了软件开发的阶段中应同步进行的验证和确认活动，W模型有两个V字模型组成，分别代表测试与开发过程。在这里，测试的对象就不仅仅是程序。需求和设计等同样需要进行测试，测试和开发是一起进行的。

H模型

• 测试流程：

  • 测试准备活动：测试计划、测试设计、测试开发
  • 测试执行活动：测试运行、测试评估

• 测试不仅仅是测试执行，还包括其他活动

• 测试是一个独立流程，贯穿产品整个周期，与其他流程并发进行

• 测试要尽早准备，尽早执行

软件测试的实质

九大原则

1. 完全测试一个程序是不可能的。

2. 软件测试是一种基于风险的实践。

3. 测试不能显示没有bug。

4. 发现的错误越多，错误就越多

5. 并不是所有发现的bug都会被修复。

6. 很难说bug什么时候是真正的bug。

7. 规格说明不是最终的

8. 软件测试人员不是项目中最受欢迎的成员。

9. 软件测试是一个严格的技术专业。

软件测试的误区

1. 如果发布出去的软件有质量问题，都是软件测试人员的错

2. 软件测试技术要求不高，至少比编程容易多了

3. 有时间就多测试一点，没时间就少测试一点

4. 软件测试是测试人员的事，与开发人员无关

5. 根据软件开发瀑布模型，软件测试是开发后期的一个阶段

软件测试的分类

1. 黑盒测试和白盒测试

   • 黑盒测试：功能测试、数据驱动测试
   • 白盒测试：结构测试、逻辑驱动测试

2. 静态测试和动态测试

   • 静态测试：互审、走查、审查会议
   • 动态测试：运行程序

3. 自动测试和手工测试

4. 单元测试，集成测试，系统测试，验收测试的区别

   

测试动态阶段（SDLC）

测试与调试

• 测试发展的初期，测试就是调试，而现在测试是一个系统化工程化的概念，调试的范畴更小

• 调试不属于测试，是编码阶段的工作，由程序员完成；调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，其目的却完全不同

• 而测试由测试员或程序员完成

• 测试是为了找出软件中存在的缺陷；而调试是为了解决存在的缺陷

• 成功的测试发现了错误的症状，从而引起调试的进行

verification(验证) 与 validation(确认)

• Verification是验证，是通过提供客观证据证明规定的要求是否得到满足，也就是说，输入与输出的比较

• Validation是确认，是在验证的基础上，对预期的使用和应用要求是否得到满足，也就是说，在确认时，应考虑使用和应用的条件范围要远远大于输入时确定的范围。一般是由客户或代表客户的人执行

SQA（Software Quality Assurance）

1. SQA是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活动

2. SQA与软件测试的关系

   • SQA是管理工作、审查对象是流程、强调预防为主
   • 测试是技术实施工作、测试对象是产品、主要是以事后检查（文档、程序）为主
   • SQA指导测试、监控测试
   • 测试为SQA提供依据
   • 测试是SQA的一个环节、一个手段

ISO与CMM/CMMI

• ISO是通用的国际标准，适用于各类组织

• CMM是美国军方为评价软件供应商的质量水平，委托SEI开发的一个评价模型，只用于软件业

• CMM更详细，更专业

• ISO只建立了一个可接受水平，而CMM是一个具有五个水平的评估工具

• ISO聚焦于供应商和用户间的关系，而CMM更关注软件的开发过程

测试计划与测试用例

测试用例

• 因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试

• 测试用例的定义：

  • 满足特定目的的测试数据、测试代码、测试规程的集合
  • 是发现软件缺陷的最小测试执行单元

  • 有特殊的书写标准和基本原则

    

良好测试用例的特征

• 可以最大程度、最高效率地找出软件隐藏的缺陷；可以最大程度地满足测试覆盖要求

• 既不过分复杂、也不能过分简单

• 使软件缺陷的表现可以清楚的判定

  • 测试用例包含期望的正确的结果
  • 待查的输出结果或文件必须简单明了

• 不包含重复的测试用例

• 测试用例内容清晰、格式一致、分类组织

测试用例设计生成的基本准则

• 测试用例的代表性：能够代表并覆盖各种合理的和不合理、 合法的和非法的、边界的和越界的、以及极限的输入数据、 操作和环境设置等;

• 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；

• 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的

单元测试

• 定义：单元测试是对软件基本组成单元进行的测试

• 时机：一般在代码完成后由开发人员完成，QA（质量评价)人员辅助

• 内容
  

单元测试的策略

• 黑盒测试

• 白盒测试

  • 静态白盒测试：代码检查

    1. 走查：采用讲解、讨论和模拟运行的方式进行的查找错误的活动
    2. 审查：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表
    3. 评审：通常在审查会后进行，审查小组根据记录和报告进行评估

  • 动态白盒测试
    

    

黑盒测试

等价类划分方法

1. 在每一个等价类中取一个数据作为测试的输入条件，使用少量代表性的测试数据取得较好的测试结果

2. 等价类划分：

   • 有效等价类：对程序来说合理的、有意义的输入数据构成的集合
   • 无效等价类：与有效等价类定义相反

3. 设计用例既要考虑有效等价类，也要考虑无效等价类

4. 步骤

   1. 建立等价类表，列出所有划分出的等价类
      • |输入条件|有效等价类|无效等价类
        |-|-|-|
        |…|…|…
        |…|…|…
   2. 设计一个新的用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复直到所有有效等价类均被测试用例所覆盖
   3. 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

边界值分析方法

1. 使等价类的每个边界都要作为测试条件

2. 步骤：

   1. 确定边界情况

   2. 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

      一般情况，一个边界可以给出3个边界测试用例，自身+左右值

错误推测方法

通过经验和直觉推测出程序的错误所在

判定表驱动分析方法

1. 判定表通常由五个部分组成：
   

2. 步骤：

   1. 列出所有的条件桩和动作桩
   2. 确定规则的个数，假如有n个条件桩，每个条件桩有两个取值（Y，N），故有$2^n$种规则
   3. 填入条件项
   4. 填入动作项。得到原始判定表
   5. 根据原始判定表的规则，设计测试用例，要求覆盖所有的原始判定表的规则（一条规则至少一个测试用例）

因果图方法

1. 借助图的方式，设计测试用例，被测数据有多种输入条件，输出结果依赖于输入条件的组合

2. 步骤：

   1. 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符
   2. 分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的关系，根据这些关系画出因果图
   3. 将因果图转换为判定表
   4. 把判定表的每一列拿出来作为依据，设计测试用例

3. 约束

   • E约束（异）：a和b至多有一个可能为1，即a和b不能同时为1
   • I约束（或）：a、b和c中至少有一个为1，即a、b和c不能同时为0
   • O约束（唯一）：a和b有且只有一个为1
   • R约束（要求）：a是1时，b必须是1

4. 例子

   • 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
     

场景法

1. 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流

2. 步骤：

   1. 设计场景：通过用例的主事件流和备选事件流的组合给出不同的场景
   2. 设计测试用例覆盖场景
   3. 根据测试用例标准给出具体的测试数据

白盒测试

ControlFlow-testing

逻辑分支覆盖法

• 语句覆盖
  1. 设计若干个测试用例，运行被测程序，使得每一个可执行语句至少执行一次，最弱的逻辑覆盖
     
• 判定覆盖
  1. 使得程序每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖
     
     
• 条件覆盖
  1. 使得每个判断的每个条件可能的取值至少执行一次
     
• 判定-条件覆盖
  1. 使每个判定中每个条件所有可能结果至少出现一次，每个判定本身的判定结果也至少出现一次
     
• 复合判定
  
• 条件组合覆盖
  1. 使得每个判断的所有可能的条件取值组合至少执行一次
  2. 显然满足条件组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定-条件覆盖
     

路径法

• 流图
  

• 路径覆盖

  1. 保证程序中每条可能的路径都至少执行一次

  2. 路径表达式
     

• 基本（独立）路径测试法

  1. 独立路径：从入口到出口的路径，至少经历一个从未走过的边

     缺点：简化循环结构

  2. 步骤

     1. 根据程序的逻辑结构画出程序框图

     2. 根据程序框图导出流图

        

     3. 计算流图G的环路复杂度

     4. 确定只包含独立路径的基本路径集
     5. 设计测试用例
  3. 环复杂度计算法：
     1. 流图的区域数量应该对应环复杂度
     2. 流图的环复杂度V(G)=E-N+2，E为流图中边数量，N为流图中节点数量
     3. V(G)=P+1，P为流图中的判断节点数量

DataFlow-testing

填补路径和分支测试的缝隙

数据对象类别

• Defined, Created, Initialized
• Killed, Undefined, Released
• Used:
  • Used in a calculation
  • Used in a predicate

Defined Objects

• 一个对象(例如变量)是被定义的当:
  • 出现在数据声明中
  • 被赋值
  • 是一个文件被打开
  • 被动态分配

Used Objects

• 一个对象是被使用的当其是计算或谓词的一部分
  • 用于计算的对象（C-use）
  • 用于谓词的对象（P-use）

du Path Segments

• A du Path is a path segment such that if the last link has a use of X, then the path is simple and definition clear

• A def-use association is a triple (x, d, u), where:

  • x is a variable
  • d is a node containing a definition of x

  • u is either a statement or predicate node containing a use of x,

    and there is a sub-path in the flow graph from d to u with no other definition of x between d and u.

    

Data-Flow Testing Strategies

• All du Paths(ADUP)

  • ADUP是最强的数据流测试策略之一

  • ADUP要求从每个变量的每个定义到该定义的每次使用的每个du path都要在某个测试下执行All du Paths策略(ADUP)。

• All Uses(AU)

• Others not covered in this course …

集成测试

集成策略

• 自顶向下
• 自底向上
• 混合策略
• 关键现行
• Function-at-a-time
• Big bang（大棒模式）

集成测试的模式：渐增式测试模式与非渐增式测试模式

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式

• 大棒集成方法

  因为所有的模块一次集成的，所以很 难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何 系统中使用，适合在规模较小的应用系 统中使用。

渐增式测试模式：把下一个要测试的模块同已经测试好的 模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试

• 自顶向下集成测试

  • 桩程序/桩模块，也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口

  • 优缺点：

    • 早期验证主要功能
    • 需要桩程序、上层模块接口错误发现早，底层关键模块错误发现晚

• 自底向上集成测试

  • 驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果

  • 优缺点：底层模块接口错误发现早，需要驱动程序、后期验证主要功能

• 混合策略模式

  对软件结构中较上层，使用的是“自顶向下”法；对软件架构中较下层，使用的是“自底向上”法，两者相结合

• Critical-first 测试

  首先集成最关键的组件

  • 保证最重要的模块优先工作
  • 可能很难整合

• Function-at-a-time 测试

  同时集成执行一个功能所需的所有模块

  • 简化测试
  • 推迟功能间的交互与集成

系统测试

功能测试

在集成测试结束之后，依据系统的需求规格说明书和产品功能说明书对系统的整体功能进行的全面测试，称为功能测试

回归测试

对修正缺陷后的软件进行再次的测试，不仅测试被修复的软件缺陷是否已经解决，还要测试软件旧有的功能与非功能是否满足要求

冒烟测试

具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率

压力测试

压力测试是在一种需要反常数量、频率或资源的方式下，执行可重复的负载测试或强度测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。

• 稳定性测试，也叫可靠性测试（reliability testing）， 是指连续运行被测系统，检查系统运行时的稳定程度。

  • 我们通常用mtbf（mean time between failure,即错误发生的平均时间间隔）来衡量系统的稳定性， mtbf越大，系统的稳定性越强
  • 稳定性测试的方法也很简单，即采用24*7（24小时 * 7天）的方式让系统不间断运行，至于具体运行多少天，是一周还是一个月，视项目的实际情况而定。
  • 在选定压力下，系统持续运行24小时来检测稳定性情况，检测系统的必要性能指标

• 破坏性加压测试：通常是指持续不断的给被测系统增加压力，直到将被测系统压垮为止（让问题与薄弱环节快速暴露出来）。 用来测试系统所能承受的最大压力。

压力测试工具——LoadRunner

1. Virtual User Generator 创建脚本

   • 创建脚本，选择协议
   • 录制脚本
   • 编辑脚本
   • 检查修改脚本是否有误

2. 中央控制器（Controller）来调度虚拟用户

   • 创建Scenario，选择脚本
   • 设置机器虚拟用户数
   • 设置Schedule
   • 如果模拟多机测试，设置Ip Spoofer

3. 运行脚本

   • 分析scenario

4. 分析测试结果

容量测试

容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

性能测试

通过测试确定系统运行期间的性能表现与性能数据， 得到如：CPU使用的效率、运行速度、响应时间、占有系统资源等方面的系统数据

安全性测试

• 安全性测试是检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。 例如：
  • 想方设法截取或破译口令；
  • 专门开发软件来破坏系统的保护机制；
  • 故意导致系统失败，企图趁恢复之机非法进入；
  • 试图通过浏览非保密数据，推导所需信息等等

可靠性测试

可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。

容错性测试

容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统

验收测试

在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段,也称为交付测试

• 前提：系统或软件产品已通过了系统测试的软件系统。

• 测试内容：验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助， 并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、 操作手册等）测试等几个方面的内容。

• α测试和β测试

  • α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

  • 经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善

软件本地化测试

• 软件国际化（SW Internationalization，第一个字母与最后一个字母间有18个字母，I18N）

  • 软件国际化是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化传统，使创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。

• 软件本地化（SW Localization，L与N间有10个字母， L10N）

  • 软件本地化是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。

• 软件全球化（G11N）

  • G11N = I18N + L10N（全球化 = 国际化 + 本地化）
  • 国际化要方便本地化

  • 首先是国际化，国际化是核心，本地化在国际化基础之上完成

    

软件配置管理

是指通过执行版本控制、变更控制等规程，以及使用合适地配置管理软件，来保证所有配置项地完整性和可跟踪性

软件配置

• 软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项，软件配置项是配置管理的基本单位

  • 软件配置项可以是：

    1. 与合同、过程、计划和产品有关的文档和数据
    2. 源代码、目标代码和可执行代码
    3. 相关产品，包括软件工具、库内的可利用软件、外购软件及用户提供的软件

  • 版本是某一配置项的已标识了的实例。也可以说，不可变的源对象经质量检查合格后所形成的新的相对稳定的格局（配置）称为软件版本

  • 版本控制就是管理在整个软件生存周期中建立起来的某一配置项的不同版本

• 基线指一个配置项在其生存周期的某一特定时间，被正式表明、固定并经正式批准的阶段性版本，又称里程碑

• 配置控制组/委员会是指一组负责评估和审批配置项变更的人员，以确保所有的变更都是经过审核的

• 配置状态统计是软件配置管理的一个要素，由有效管理所需的记录和报告信息组成。这些信息包括经核准的配置标识表、需要变更的配置状态和实施经审核的变更状态。

配置管理过程

1. 制定配置管理计划

   配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划

2. 配置库管理

   配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等

3. 版本控制

   在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象

4. 变更控制

   在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。

5. 配置审计

   为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一

软件维护

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程

改正性维护

• 在软件交付使用后，因开发阶段的问题以及测试得不彻底、不完全，必然会有部分隐藏得错误遗留到运行阶段。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护

适应性维护

• 在使用过程中，

  • 外部环境（新的硬、软件配置）
  • 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）
    可能发生变化

• 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护

完善性维护

• 在软件的使用过程中，用户往往会对软件提出的新的功能与性能要求

• 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性

• 这种情况下进行的维护活动叫做完善性维护

预防性维护

• 预防性维护即软件再工程，是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础

• 采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护

结构化维护VS非结构化维护

• 如果采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档，这样维护会相对容易，被称为结构化的维护

• 如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，被称为非结构化的维护