测试基础知识总结

软件测试基础知识回顾

1.软件生命周期：定义为开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

周期：定义（问题的定义及规划）→设计(软件设计)→实施（程序编码）→测试（软件测试）→部署→运行→维护

                         ↑

                       需求分析

生命周期模型包括瀑布模型、快速原型模型、迭代模型

2.V模型

 

 

3.Web三层结构：用户界面表现层，业务逻辑层，数据访问层。

4.软件测试的目的：发现缺陷，提高质量；验证是否满足需求；建立软件质量的信心。

5.软件测试原则：测试显示缺陷的存在（测试可以证明存在缺陷但不能证明不存在缺陷）；

                     尽测试是不可能的；

                     测试尽早介入（可减少经费）；

                     缺陷集群性（80—20原则。80%以上的错误产生与20%的模块内）；

                     杀虫剂悖论（抗药性）；

                     测试活动依赖于测试背景（测试背景不同测试活动不同）；

                     不存在缺陷的谬论；

6.回归测试用相同的测试用例重新测试发现并改正过错误的程序。

7. 软件测试工作最为重要的是：测试流程方法；测试工具；测试人员素质。

8.测试过程：测试计划和控制；测试需求分析和测试用例；实现和执行测试用例；评估出口准则和报告；测试活动结束。

9.软件测试的分类：是否关心内部结构-黑，白，灰盒测试；开发过程级别-单元测试，集成测试，系统测试，验收测试；是否执行程序-静态测试和动态测试；是否需要人工干预-手动测试，自动化测试；测试实施组织-开发测试，用户测试，第三方测试。

10.缺陷管理的一般流程：

11.测试流程：提取测试需求→制定测试计划→制定测试策略和方案→开展测试设计→执行测试用例→分析测试结果。

 

 

 

 

 

 

 

六章

1.软件测试模型：V模型，W模型，H模型。

  V模型软件测试测策略即包括低层测试又包括高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户需求。强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试 

V模型具有一定的缺陷，因此提出了W模型，W模型补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；以增加软件测试个阶段中应同步进行的验证和确认活动。

由于V模型和W模型都没有很好的体现测试流程的完整性且在现在测试中相应的测试之间不存在严格的次序关系，提出了H模型，H模型强调测试是独立的，只要测试准备完成，就可以执行测试

2.软件测试的管理流程：提取测试需求---制定测试计划---制定测试策略和方案----开展测试计划----执行测试用例---分析测试结果

   流程图：                     测试需求                        

                                测试计划                             

                                 
 
 

     
     

      
      
回归测试
     
     
                                 测试设计                              

                                测试执行                              

                              测试记录                               

     
 
 

     
     

      
      
缺陷追踪
     
     
                                  分析                                

                                测试完毕                                

                               总结                              

测试阶段目标的检测：代码审查，单元测试，集成测试，功能测试，系统测试，验收测试

软件测试文档的概念：描述要执行的软甲测试和测试的结果，用来记录，描述，展示测试过程中一系列测试信息的处理过程，通过书面或图示的形式对软件测试过程中的活动或结果进行描述，定义及报告，记载了整个测试的过程和结果。

软件测试文档的作用：提高测试过程的能见度，文档化能规范测试问题的反馈，提高测试效率，便于团队之间的交流与合作，测试文档是测试人员经验提升的最好途径，有利于项目测试的监控作用，有利于测试工作的展开。

七章

静态测试：指不执行程序代码而寻找代码中的错误或评估程序代码的过程。

对象：各种与软件相关的有必要进行测试的产物，比如各类文档，源代码。。。。

同行评审：审查，小组评审，走查和同级桌查，临时评审，软件评审指导书。

需求规则说明书测试：一般采用逐行阅读说明书以发现缺陷的方式，在需求规格说明书整体或部分完成后立即开展。

代码检查：是“白盒”测试的一种静态测试方法，（如代码审查，桌面检查，代码走查和技术审查），是众多软件测试中发现软件缺陷最有效的方法之一。主要检查代码和设计的一致性，代码对标准的遵循，代码的可读性，代码的逻辑表达正确性，代码结构的合理性。

圈复杂度：最大上限为10，V（G）=m-n+p；或是 流程中的节点数+1.

软件质量：定义：概括地说，软件质量就是"软件与明确的和隐含的定义的需求相一致的程度"。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险(产品运行);可理解性、可维修性、灵活性、可测试性(产品修改);可移植性、可再用性、互运行性(产品转移)。

八章

“白盒“测试可分为静态测试和动态测试。

特点：1.将软件看成透明的盒子。2.查看代码功能+实现方式。3.确实测试内容和测试方法。

注意：调试！=白盒测试；一般只用于单元测试。

根据不同模块的重要程度，灵活选择以下六种覆盖标准:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。

语句覆盖每条语句至少执行一次。

判定覆盖每个判定的每个分支至少执行一次。

条件覆盖每个判定的每个条件应取到各种可能的值。 

判定/条件覆盖同时满足判定覆盖条件覆盖。

条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

路径覆盖使程序中每一条可能的路径至少执行一次。

“黑盒”测试：

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

划分等价类的方法:下面给出六条确定等价类的原则.

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

设计原则然后从划分出的等价类中按以下三个原则设计测试用例：

①为每一个等价类规定一个唯一的编号.

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止。

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

边界值分析法

边界值分析方法是对等价类划分方法的补充。

基于边界值分析方法选择测试用例的原则：

1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

3）根据规格说明的每个输出条件,使用前面的原则1）.

4）根据规格说明的每个输出条件,应用前面的原则2）.

5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

7）分析规格说明,找出其它可能的边界条件.

因果图方法

因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

利用因果图生成测试用例的基本步骤：

(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

(4) 把因果图转换为判定表.

(5) 把判定表的每一列拿出来作为依据,设计测试用例.

               测试用例设计概念：P308

测试用例的主要元素：测试环境，测试输入数据，测试执行步骤，预期测试结果。

单元测试：又称模块测试，是针对软件设计的最小单位---程序模块或功能模块，进行正确性检测的测试工作。

其目的在于坚持程序各模块中是否存在各种差错，是否正确的实现其功能，满足其性能和接口要求。

单元测试的内容：模块接口，局部数据结构，边界条件，独立路径，出错处理。

     
 
 

     
     

      
      
期望达到，实际很难
     
     
               要求;1.语句覆盖达到100%

     2.分之覆盖达到100%

    3.错误处理路径达到100%

   4.单元的软件特性覆盖（功能 性能 属性 设计约束 状态数目 分支的行数）

   5.各种数据特性覆盖（对实用额定数值 奇异数据值和边界值的计算进行检验）

集成测试：优点; 正确性高 目的性针对性强 定位快

单元测试
单元测试是对软件基本组成单元（软件设计的最小单位）进行正确性检验的测试工作，如函数、过程(function,procedure)或一个类的方法(method)。
集成测试：
集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。集成测试也叫组装测试、联合测试、子系统测试或部件测试。
系统测试：
系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际使用环境下，对计算机系统进行一系列的组装测试和确认测试的工作。

测试阶段测试方法                测试方法                                                              评估基准对应阶段

单元测试白盒测试            单元内部的数据结构，逻辑控制，异常处理等                                  逻辑覆盖率详设
  
集成测试灰盒测试             模块间接口以及模块组合后的整体功能                                      接口覆盖率设                   
系统测试黑盒测试                 整个系统对需求的符合度                                            测试用例对需求的覆盖率需求

集成测试方法

1.                一次性组装方式（大爆炸集成方法）        

2. 渐增式测试-----自顶向下集成测试方法  深度优先方法

                                     广度优先方法 

              ----自底向上集成测试方法

3. 混合渐增式集成测试方法

完成标志：

成功的执行了测试计划中规定的所有集成测试方法；

修正了所有发现的错误；

测试结果通过了专门小组的评审；

九章

自动化测试概念：实际上是将大量的重复性的测试工作交给计算机去完成，通常是实用自动化测试工具来模拟手动测试步骤；