您的位置:首页 > 其它

【总结】软件测试基础总结

2015-10-05 16:38 330 查看
一 第一章

软件定义:程序+数据+文档

软件危机:落后的软件生产方式无法满足迅速增长的计算机软需

求,从而导致软件开发与维护过程中出现严重问题。

软件工程: 方法+工具+过程

软件生命周期模型: 瀑布模型,v模型,迭代模型

软件生命周期: 定义—设计—实施—测试—部署—运行—维护

二 第二章

软件测试的定义:是对软件需求分析,设计,编码的最终复查的一系

列过程,是软件质量保证的关键步骤。

软件测试的目的:1.尽可能发现并改正被测软件中的错误,提高软件的可靠性

2.为了保证软件的质量

软件测试原则:1.显示缺陷的存在

2.穷尽测试是不可能的

3.测试尽早介入

4.缺陷群集性

5.杀虫剂桲论

6.测试活动依赖测试背景

7.不存在缺陷的谬论

软件测试流程:1.测试计划和控制

2.测试需求分析和用例设计

3.实现和执行测试用例

4.评估出口准则和报告

5.测试活动结束

控制:资源整合

风险分析

三 第三章

基于生命周期的软件测试的过程:

需求分析—测试计划—用例设计—执行用例—缺陷追踪—测试报告

生命周期各阶段测试内容:

1.需求阶段 确认定义的需求复合机构要求

2.设计和编程阶段 验证设计的程序实现了需求

3.测试和安装阶段 检查实现的系统符合系统规格说明书

4.维护阶段 重新测试确定改变的部分和未改变的部分能继续工作

测试计划:

内容:描述测试活动的范围、方法、资源和进度的文档

对象:测试项、被测特性、测试任务、任务执行者、各种可能风险

作用:有效预防计划的风险,保障计划的顺利实施

测试准入原则:

各方面资源准备就绪

测试准出原则:

软件各模块正常运行

风险:

定义:测试活动中所有可预测或者不可预测的对测试进度发生影响的因素

目的:保证测试按预期执行

四 第四章

测试分类:

是否关心内部结构: 开发过程级别:

白盒测试 单元测试

黑盒测试 集成测试

灰盒测试 系统测试

验收测试

是否执行程序: 执行过程是否需要人工干预:

静态测试 手工测试

动态测试 自动化测试

测试实施组织:

开发测试

用户测试

第三方测试

五 第五章

缺陷的定义:

一般符合下列五个规则之一,就是缺陷:

软件未实现产品说明书要求的功能

软件出现了产品说明书指明不应该出现的错误

软件实现了产品说明书未提到的功能

软件未实现产品说明书虽未明确提及但应该实现的目标

软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好

软件缺陷原因:

1.需求定义不完善,甚至没有需求文档

2.人员之间的沟通交流不够

3.软件需求的不断变化

4.软件复杂程度高,缺陷很难避免

5.开发人员能力有限

6.开发人员出现编码错误

7.不符合文档编制和编码规定

8.工期短任务中开发和测试工作不充分

9.文档编制错误

软件缺陷描述

1. 可追踪信息

2. 缺陷的基本信息

3. 缺陷的详细描述

4. 测试环境说明

5. 必要的附件

6. 从统计的角度出发

5C原则:

(Correct)准确 (Clear )清晰 (Consistent)一致

(Concise)简洁 (Complete)

软件缺陷报告

主要内容:

问题报告编号 标题 报告人 报告日期 程序的名称 版本号 配置 缺陷的类型 严重性 优先级 关键词 缺陷描述

重现步骤 结果对比

六 第六章

V模型:不同测试阶段和开发过程期间各阶段的对应关系

优点:

1. 既有底层测试又有高层测试。底层:单元测试。高层:系统测试。

2. 将开发阶段清楚的表现出来,便于控制开发的过程。当所有阶段都结束时,软件开发结束了

缺点:

1. 容易让人误解为测试是在开发完成之后的一个阶段。

2. 由于它的顺序性,当编码完成之后,正式进入测试时,这时发现的一些BUG可能不容易找到其根源,并且代码修改起来很困难。

3. 实际中,由于需求变更较大,导致要重复变更需求、设计、编码、测试。返工量大。

W模型:增加了软件开发阶段中应同步进行的验证和确认活动

基于“尽早的和不断的进行测试”的原则

测试过程主要内容:

优点:

1. 将测试贯穿到整个软件的生命周期中,且除了代码要测试,需求、设计等都要测试。

2. 更早的介入到软件开发中,能尽早的发现缺陷进行修复。

3. 测试与开发独立起来,并与开发并行。

缺点:

1. 对有些项目,开发过程中根本没有文档产生,故W模型无法使用。

2. 对于需求和设计的测试技术要求很高,实践起来很困难。

软件测试过程中的活动及内容

七 第七章

静态测试概念:是不实际运行被测软件,而只是静态地检查程序代码界面或文档中可能存在的错误的过程。

内容:

对于代码测试,主要测试代码是否符合相应的标准和规范。

对于界面测试,主要测试软件的实际界面与需求中的说明是否相符。

对于文档测试,主要测试用户手册和需求说明是否符合用户的实际需求。

常用方法:

最常用而且最主要的方法是同行评审。

同行评审概念:开发软件产品作者以外的其他人检查工作,已发现缺陷并寻找改进的机会

同行评审根据正式程度(由低到高)可以划分为5种评审方法:临时评审、桌面评审、走查、小组审查、审查。其中临时评审、桌面评审、走查无标准的流程,正式程度越高,发现的错误越多,成本也越高,一般这5种方法中使用最多的是临时评审

八 第八章

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

⑴白盒测试概念:又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法

① 逻辑覆盖概念:是一种以程序内部的逻辑结构为基础的测试方法,属于白盒测试

②逻辑覆盖种类:

a.语句覆盖:是最起码的测试要求,要求设计足够多的测试用例,使得每条语句至少被执行一次

b.判定覆盖:又叫分支覆盖,要求设计足够多的测试用例,使得程序中的每一个分支至少通过一次,即每一条分支语句的“真值”和“假值”都至少执行一次

c.条件覆盖:使程序中每个判定的每个条件的所有可能条件取值至少执行一次

d.判定/条件覆盖:设计若干个测试用例,运行被测程序,使程序中每个判定的每个条件的所有可能条件取值至少执行一次,同时每个判定的所有可能判定取值至少执行一次。即要求同时满足判定覆盖和条件覆盖

e.条件组合:设计若干个测试用例,运行被测程序,使程序中每一个判定的所有可能的条件取值组合至少执行一次

f.路径覆盖:设计若干个测试用例,运行被测程序,覆盖程序中的所有可能路径

⑵黑盒测试概念:把测试对象当作看不见内部的黑盒、在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性

黑盒测试方法:

①等价类划分法:

1、等价类可以划分为有效等价类和无效等价类。
  a.有效等价类
  有效等价类指对于程序规格说明来说,是合理的、有意义的输入数据构成的集合。有效等价类可以是一个,也可以是多个,根据系统的输入域划分若干部分,然后从每个部分中选取少数有代表性数据当做数据测试的测试用例,等价类是输入域的集合。
  b.无效等价类
  无效等价类和有效等价类相反,无效等价类是指对于软件规格说明而言,没有意义的、不合理的输入数据集合。
  2、等价类划分的方法和原则
  a.等价类划分的方法有:
  按区间划分。
  按数值划分。
  按数值集合划分。
  按限制条件或规划划分。
  按处理方式划分。
  b、等价类划分的原则:
  在输入条件规定的取值范围或值的个数的情况下,可以确定一个有效等价类和两个无效等价类。
  在规定了输入数据的一组值中(假定有n个值),并且程序要对每个输入值分别处理的情况下,可以确定n个有效等价类和一个无效等价类。
在规定输入数据必须遵守的规则的情况下,可以确定一个有效等价类和若干个无效等价类。
  在输入条件规定了输入值的集合或规定了“必须如何”的条件下,可以确定一个有效等价类和一个无效等价类。
  在确定已划分的等价类中各元素在程序处理中的方式不同的情况下,则应将该等价类进一步地划分为更小的等价类。
  3、等价类表的建立  
a、在分析需求规格说明的基础上划分等价类,列出等价类表,为每一个等价类规定一个唯一的编号。
b、将程序可能的输入数据分成若干个子集,从每个子集中选取一个有代表性的数据作为测试用例。等价类是某个输入域的子集,在该子集中的每个输入数据的作用都是等效的。
c、设计新的测试用例,使其尽可能多地覆盖未覆盖的有效等价类,按照这一步骤重复进行,直到所有的有效等价类都被覆盖为止。
d、设计新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,按照这一步骤重复进行,直到所有的无效等价类都被覆盖为止。
②边界值分析法:
边界值分析法(BVA,Boundary Value Analysis)是用于对输入或输出的边界值进行测试的一种黑盒测试方法。
边界值分析法和等价类划分法两者的区别:
前者专注于每个等价类的边界值,后者在等价类中随机选取一个测试点
边界值分析法仅用于考察正处于等价划分边界或边界附近的状态,考虑输出域边界产生的测试情况。
注意问题:
  1、选择边界值测试原则
  选择边界值测试主要考虑以下几条原则:
  a、如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数小一的数、比最大个数大一的数作为测试数据。
  b、如果输入条件规定了值的范围,则应取刚达到这个范围边界的值,以及刚刚超过这个范围边界的值作为测试输入数据。
  c、如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
  d、如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
  e、分析程序规格说明,找出其他可能的边界条件。
③因果图法 :
因果图法也是较常用的一种黑盒测试方法。
能直观地表明输入条件和输出动作之间的因果关系,比采用等价分类法的测试效率更高,但这种方法的操作步骤比较复杂。
  因果图法是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法。因果图法一般和判定表结合使用。因果图法最终生成的就是判定表。
  采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例,同时,还能指出程序规范中存在什么问题,鉴别和制作因果图。
1、关系符号
  a、恒等
恒等关系符号如图

恒等关系符号图
  b、非

   非关系符号如图

非关系符号图

c、或
   或关系符号如图

或关系符号图
  d、与
与关系符号如图

与关系符号图

通常在因果图中,用Ci表示原因,ei表示结果,Ci和ei的状态可用0或1表示,0表示某状态不出现,1表示某状态出现。
2、约束
  输入状态还存在着某些依赖关系,这种关系称为约束。
约束符号如图所示。

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,即a为1时,b不能为0。
  M约束(强制):若结果a为1,则结果b强制为0。
3、利用因果图导出测试用例的基本步骤
a、分析软件规格说明的描述中哪些是原因,哪些是结果。原因是输入或输入条件的等价类,结果是输出条件。给每个原因和结果并赋予一个标识符,根据这些关系,画出因果图。
  b、因果图上用一些记号表明约束条件或限制条件。
  c、对需求加以分析并把它们表示为因果图之间的关系图。
  d、把因果图转换成判定表。
  e、将判定表的每一列作为依据,设计测试用例。

④随机数法:
即测试用例的参数是随机数。它可以自动生成,因此自动化程度高。使用大量随机测试用例测试通过的程序会提高用户对程序的信心。但其关键在于随机数的规律是否符合使用实际
⑤猜错法:
错误推测法是基于以往的经验和直觉,参照以往的软件系统出现的错误,推测程序中所有可能存在的各种缺陷和错误,从而有针对性地设计测试用例。
错误推测法的基本思路是:列举出程序中所有可能的错误和容易发生错误的特殊情况,根据可能出现的错误情况选择测试用例。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: