码迷,mamicode.com
首页 > 其他好文 > 详细

软件测试

时间:2020-06-09 16:38:33      阅读:36      评论:0      收藏:0      [点我收藏+]

标签:快速   采集   导出   解决   项目开发   不能   提交   元素   提醒   

软件开发过程模型

分为三个模型分别为:瀑布模型、快速原型模型、螺旋模型

瀑布模型

1、瀑布模型是线性模型的一种,在所 有模型中占有重要地位,是所 有其他模型的一个基础。 

2、每一个阶段执行一次,按 线性顺序进行软件开发。

测试的切入点: 

测试阶段处于软件实现后,必 须在代码完成后留出足够的时 间给测试活动,否则将导致测 试不充分,很多问题到项目后 期才暴露

技术图片

 

优点:

开发的各个阶段比较清 晰。

强调早期计划及需求调 查。

适合需求稳定的产品开 发。

缺点:

开发的各个阶段比较清晰。

强调早期计划及需求调查。

适合需求稳定的产品开发。

依赖于早期的需求调查,不 适应需求的变化。

单一流程不可逆。 

风险往往延至后期才显露, 失去及早纠正的机会。

问题在项目后期才开始暴露。

前面未发现的错误会传递并扩散 到后面的阶段,可能导致项目失败。

改良:

沿用瀑布模型的线性思想,细化了各个阶段,在某些重要关注的阶段之间 掺入迭代的思想。

快熟原型模型

在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系 统的开发工作。
第一步是建造一个快速原型,实现用户与系统的交互,用户对原型进行评 价,进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要 求,开发人员可以确定用户的真正需求是什么。
第二步是在第一步的基础上开发出用户满意的软件产品。

技术图片

优点:

克服瀑布模型的缺点,更好地
满足用户的需求并减少由于软
件需求不明确带来的项目开发
风险。适合预先不能确切定义
需求的软件系统的开发。

缺点:

不适合大型系统的开发(适合 开发小型的、灵活性高的系 统)。前提要有一个展示性的 产品原型,因此在一定程度上 可能会限制开发人员的创新

螺旋模型螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相 符合,螺旋模型沿着螺旋线旋转,即在坐标的4个象限上分别表示了4个方 面的活动,如图所示:

制定计划、风险分析、实施开发、客户评估

技术图片

优点:

螺旋模型很大程度上是一种风
险驱动的方法体系,因为在每
个阶段之前及经常发生的循环
之前,都必须首先进行风险评
估。

缺点:

采用螺旋模型需要具有相当丰
富的风险评估经验和专门知识,
在风险较大的项目开发中, 如
果未能够及时标识风险,势必
造成重大损失。过多的迭代次
数会增加开发成本,延迟提交
时间

测试模型

测试模型也分为三种分别为:V模型、W模型、H模型

V模型:

• 需求分析
用户需求、业务需求、需求 规格说明书

• 概要设计
系统架构、模块划分、模块 与模块之间的接口。

• 详细设计
模块内部实现的逻辑和方法。

• 编码

实现上面的设计。

• 单元测试 

检测代码的开发是否符合详 细设计的要求。

• 集成测试

检测此前测试过的各组成部 分是否能完好地结合到一起。

• 系统测试 

检测已集成在一起的产品是 否符合系统规格说明书的要 求。

• 验收测试

检测产品是否符合最终用户 的需求。

技术图片

V模型的优点


– 测试V模型即包含了底层测试又包含了高层测试;

• 底层测试:检验源代码质量的测试,如:单元测试;

• 高层测试:检验整个系统的需要,如:系统测试;

– V模型清楚地标识出了软件开发的阶段。– 它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段, 每个阶段的工作都很明确,因此便于控制开发过程。当所有的阶

段都完成之后,该软件的开发过程也随之结束。

V模型的缺点

– V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段,程 序已经完成,错误已经产生,很多前期的错误一直到测试阶段才 发现,甚至无法发现,往往无从修改了。

– 同时实际的开发过程中,在需求阶段很难把用户的需求完全明确 下来,因此,当需求变更时将会导致阶段反复,而且都要重复需 求、设计、编码、测试等过程,返工量非常大,模型灵活性比较 低。

W模型

技术图片

W模型的优点:

开发强调测试伴随着整个软 件开发周期,而且测试的对 象不仅仅是程序,需求和概 要设计同样要测试;
更早地接入测试,可以发现 开发初期的缺陷,那么可以 用更加低的成本进行缺陷修 复。
同样是分阶段的工作,便于 控制项目过程。
W模型的缺点:
依赖于软件开发和软件测试依 然保持一前一后的线性关系, 依然无法支持迭代、自发性和 需求等变更调整;
对于当前很多项目,在执行的 过程中根本不产生文档,那么 W模型基本无法适用;
使用起来技术复杂度很高,对 于需求和设计的测试要求很高, 实践起来困难

H模型

• 测试流程

– 测试准备:所有测试执行活动的准备;判断是否到测试就绪点;

– 测试就绪点:测试准入准则,即是否可以开始执行测试的条件;

– 测试执行:具体的执行测试的程序。

• 其他流程

– 具体开发中的流程,如:设计流程

技术图片

H模型的优点:

开发的H模型揭示了软件测试除测 试执行外,还有很多工作;

软件测试完全独立,贯穿整个生 命周期,且与其他流程并发进行;

软件测试活动可以尽早准备、尽 早执行,具有很强的灵活性;

软件测试可以根据被测物的不同 而分层次、分阶段、分次序的执 行,同时也是可以被迭代的。

H模型的缺点:

管理型要求高:由于模型很灵活,必 须要定义清晰的规则和管理制度,否 则测试过程将非常难以管理和控制; 

技能要求高:H模型要求能够很好的定 义每个迭代的规模,不能太大也不能 太小; 

测试就绪点分析困难:测试很多时候, 你并不知道测试准备到什么时候是合 适的,就绪点在哪里,就绪点的标准 是什么,这就对后续的测试执行的启 动带来很大困难; 

对于整个项目组的人员要求非常高: 在很好的规范制度下,大家都能高效 的工作,否则容易混乱。例如:你分 了一个小的迭代,但是因为人员技能 不足,使得无法有效完成,那么整个 项目就会受到很大的干扰。

软件测试分类(图):

技术图片

 边界值

边界值就是对一个数两边的值进行测试,比如99的边界值100和98进行测试,若没有提示错误就是发生错误。

举个例子

一个计算机提示的错误就是99到-99的内容,测试就是测试两个数的边界值,若提示错误表示没有问题,若没有则有错误。

因果图与判定表

因果图法是一种利用图解法分析输入的各种组合情况,从 而设计测试用例的方法,它适合于检查程序输入条件的各 种组合情况
• 特点:

• 考虑输入条件的相互制约及组合关系

• 考虑输出条件对输入条件的依赖关系

因果图的核心

• 因果图法比较适合输入条件比较多的情况,测试所有的输入条件的排列组合。 所谓的原因就是输入,所谓的结果就是输出。

• 因果图的“因”——输入条件

• 因果图的“果”——输出结果
• 因果图法要注意考虑:

• 所有输入/输出条件的相互制约关系以及组合关系

• 输出结果对输入条件的依赖关系,也就是什么样的输入组合会产生怎样 的输出结果,即“因果关系”

因果图中的基本符号

• 通常在因果图中用Ci表示原因,用Ei表示结果,各结点表示 状态,可取值“0”或“1”。“0”表示某状态不出现, “1”表示某状态出现。

技术图片

因果图中的约束条件

技术图片

因果图法基本步骤

• 利用因果图导出测试用例需要经过以下几个步骤:

• ① 找出所有的原因,原因即输入条件或输入条件的等价类。

• ② 找出所有的结果,结果即输出条件。

• ③ 明确所有输入条件之间的制约关系以及组合关系。

• 哪些条件不能组合到一起,哪些条件可以组合到一起

• ④ 明确所有输出条件之间的制约关系以及组合关系。

• 哪些输出结果不能同时输出,哪些输出结果可以同时输出

• ⑤ 找出什么样的输入条件组合会产生哪种输出结果

• ⑥ 把因果图转换成判定表/决策表。

• ⑦ 为判定表/决策表中的每一列表示的情况设计测试用例。

举个例子

技术图片

看上面的黑线表示:输入50然后充值五十输出给我们的内容是提示充值成功和退卡。

技术图片

把那些内容填入表格并用1表示填入。

测试报告

测试方法的选择

• 通常在确定测试方法时,有以下几条参考原则:
• (1)拿到一个测试任务时,先关注它的主要功能和业务流程、业务逻辑是否正确实现, 考虑使用场景法。

• (2)需要输入数据的地方,考虑采用等价类划分法,包括输入条件和输出条件的等价 划分,将无限测试变成有限测试。

• (3)在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错 误的能力最强。

• (4)如果程序的功能说明中含有输入条件的组合情况,则一开始就应考虑选用因果图 和判定表法。

测试用例的力度

• 测试用例可以写的很简单,也可以写的很复杂。

• 最简单的测试用例是测试的纲要,仅仅指出要测试的内容。

• 测试用例写的过于简单,则可能失去了测试用例的意义。过于简 单的测试用例设计其实并没有进行“设计”,只是需要把测试的 功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个 简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。

• 最复杂的测试用例则会指定输入的每项数据,期待的结果即检验 方法,具体到界面元素的操作步骤,指定测试的方法和工具等。

• 测试用例写得过于复杂或详细,会带来两个问题:一个是效率 问题,另一个是维护成本问题。另外,测试用例设计的过于详 细,留给测试执行人员的思考空间就比较少,容易限制测试人 员的思维。

缺陷报告

如图所示

技术图片

报告注意:不能一次性报告几条错误,报的的名字要用别名

技术图片

缺陷统计

• 对软件问题的功能域分布进行分析,找出系统的薄弱环节。

• 要详细采集每个功能模块或系统构件的缺陷数据,并按功能、错误类型、严重程度等分类。

• 二八定理:80%的软件问题总是发生在大约20%的功能模块中。

• 对缺陷的注入阶段的分布进行分析,并与历史数据相比较。应按不同的开发阶 段详细采集缺陷的数据。

• 应对软件缺陷类型进行分析,以便针对各自的特点,先修复严重缺陷。

• 应动态采集每个测试周期中发现的缺陷数,并有效地控制缺陷的修复率。

• 应密切观察缺陷的状态,并及时跟踪其状态的变化,以检查测试和开发人员的 工作情况。

SVN的使用

SVN优势

1.存储
SVN服务器既具有CVS所具有数据储存的优点,像是信息资源存储后会形成资源树结构,便于存储的同时,数据一般不会丢失,同时又拥有自己的特色。SVN是通过关系数据库及二进制的存储方式,同时解决了既往不能同时读写同一文件等问题,同时增添了自己特有的“零或一”原则。
2.速度
与人们初始的CVS相比,SVN在速度运行方面有很大提升。因为SVN服务器只支持少量的信息、资源传输,与其他系统相比,更支持的是离线模式,因此避免了网络拥挤现象的出现。
3.安全性
SVN是一种技术性更加安全的产品,实现了系统和控制两方面的结合。一方面可以将系统整体的安全功能有效地分布在分支系统中,进而保证分支系统能正常运行,从而使各分支系统能够互补,最终在系统整体性的安全性得以保障,通过均衡原则实现最终追求安全的目的。 
 

右键菜单

• TSVN通过右键菜单与Windows资源管理器集成,没有自己的窗口 界面

技术图片

创建版本库(一)

创建版本库是因为:可能有不同的人来操作同一个文件,有时我们需要查看这个操作 是谁完成的,或者想要回退到某一版本,则需要知道对应的版本是哪个。

技术图片

SVN图标

技术图片

删除

• “删除”仅是对客户端的文件进行操作,并不改变服务器上的内 容,需要执行“提交”操作才会将删除操作上传到服务器

• 将“删除”操作“提交”到服务器后,仅是从服务器的最新版本 中删除了此文件或文件夹,在历史版本中仍可找回此文件或文件 夹

软件测试

标签:快速   采集   导出   解决   项目开发   不能   提交   元素   提醒   

原文地址:https://www.cnblogs.com/jy81/p/13073162.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!