2020-03-04 18:24:59 KamRoseLee 阅读数 80
  • 软件测试基础

          主要讲解软件测基础信息,包括如下内容: *  软件测试的发展 * 软件测试定义、目标、原则 * 软件测试模型(V模型、W模型、H模型等)      * 软件测试准入准出的标准(包括缺陷的生命周期、测试用例的相关属性字段) * 测试方法的分类 * 白盒测试(语句、条件、判定、条件/判定、条件组合、路径等覆盖) * 黑盒测试(等价类、边界值、因果图)       通过该系列课程,能达到对软件测试有一个简单的认识,知道通过一些方法来分析需求,编写测试用例,来管理缺陷,有一个简单的测试流程体系,知道如何测试、如何编写测试用例等。

    2444 人正在学习 去看看 王恩龙

1.软件测试的目的 

软件测试是以发现软件的存在的故障或缺陷,并藉此对软件的质量进行度量。为达此目的,测试活动的目标是最大可能的找出最多的错误。 
测试是从假定软 件含有缺陷和故障的假设而进行的,实现这个目标的关键是科学合理设计出最能 暴露问题的测试用例。
测试是程序执行过程,并限于执行处理有限的测试用例与情形,并发现了错误;
检测软件是否满足软件定义的各种需求目标;
执行的测试用例发现了未曾发现的错误,实现成功的测试。

2.  软件测试的原则

依据软件测试的目的,归纳出一些测试的原则。
尽早和及时的进行测试。测试活动应从软件产品开发初始阶段就开始;
测试用例要由测试数据与预期结果两部分组成,并包括测试前置条件或 后置条件;
测试根据其需求和风险,可由专业测试者进行或程序开发者自行检测;
需要严格执行测试计划,并排除测试工作随意性;
充分注意测试中的集群效应,经验表明软件约 80%的错误仅与 20%的 程序有关;
应对测试结果作核查,存档测试计划、测试用例、缺陷统计和分析报告等文档,为软件维护提供资料及条件。

3.软件测试基本测试原理

软件测试产生发展已达 40 多年,经过长期地实践,总结归纳出了一些基本 的测试原理与测试特性准则,并被业界普遍接受和遵循,对测试的设计、执行和 管理均具有工程的指导意义。
原理 1:测试可以证明缺陷存在,但不能证明缺陷不存在
测试可以证明软件系统(产品)是失败的,即说明软件中有缺陷。但测试不 能证明软件中没有缺陷。适当的软件测试可以减少测试对象中的隐藏缺陷。即使 在测试中没有发现失效,也不能证明其没有缺陷。
原理 2:穷尽测试是不可能的
测试若考虑所有可能的输入值及其组合,并结合所有的前置条件进行穷尽测 试是不可能的。实际测试过程中,对软件测试基本上是抽样测试。因此,必须根 据风险和优先级,控制测试工作量。
原理 3:测试活动应尽早开始
在软件生命周期中,测试活动应尽早实施,,并聚焦于定义的目标上,这样 可以尽早的发现缺陷。
原理 4:缺陷集群性
在通常情况下,缺陷并不是平均而是集群分布的,大多数的缺陷只存在于测 试对象的极小部分中。因此,如在一个地方发现了较多缺陷,通常在附近会有更 多的缺陷,这就是所谓的缺陷集群性,也就经常所说的‘8/2 现象’,80%的缺 陷集中在 20%的程序模块中。因此,在测试中,应机动灵活地应用这个原理。
原理 5:杀虫剂悖论
若同样的测试用例被一再重复执行,则会减少测试的有效性。先前没有发现的缺陷反复使用同样的测试用例也不会被重新发现。因此,为了维护测试的有效 性,战胜这种“抗药性”,应对测试用例进行修正或更新。这样软件中未被测试 过的部分或先前没有被使用过的输入组合会被重新执行,从而发现更多的缺陷。
原理 6:测试依赖于测试内容
测试必须与应用系统的运行环境及使用中固有的风险相适应。因此,没有两个系统可以完全相同的方式进行测试。对于每个软件系统,测试出口准则等应依据其使用的环境分别量体定制。例如,对安全起关键作用的系统与一个电商应用系统所要求的测试是不尽相同的。
原理 7:没有失效就是有用的系统是一种谬论
测试找到了导致失效的 Bug、并修正了缺陷,并不能保证整个系统达到了用 户的预期要求和需要。因此说,没有发现失效就是有用的系统是一种谬论。

4.测试特性准则

对任何软件(产品)系统都存在有限的充分测试集合
若一个软件系统在一个测试数据(测试用例)集合上的测试是充分的, 那么再测试执行一些测试用例也是充分的,这一特性称作测试的单调性
即使对软件所有的组成成分都进行了充分测试,也并不能表明整体软件 系统的测试已经充分,这一特性称作测试的非复合性
即使对软件系统整体的测试是充分的,也并不能证明软件系统中各组成 成分都已得到了充分测试,这个特性称作测试的非分解性
软件测试的充分性应与软件需求与软件实现相关软件越复杂,测试数据需用就越多,这一特性称为测试的复杂性
测试越多,进一步测试所获充分性增长就越少,这一特性称作测试回报 递减率
软件测试的特性准则对测试的设计与执行均具有工程指导意义。

2017-12-22 18:30:54 sinat_30260285 阅读数 216
  • 软件测试基础

          主要讲解软件测基础信息,包括如下内容: *  软件测试的发展 * 软件测试定义、目标、原则 * 软件测试模型(V模型、W模型、H模型等)      * 软件测试准入准出的标准(包括缺陷的生命周期、测试用例的相关属性字段) * 测试方法的分类 * 白盒测试(语句、条件、判定、条件/判定、条件组合、路径等覆盖) * 黑盒测试(等价类、边界值、因果图)       通过该系列课程,能达到对软件测试有一个简单的认识,知道通过一些方法来分析需求,编写测试用例,来管理缺陷,有一个简单的测试流程体系,知道如何测试、如何编写测试用例等。

    2444 人正在学习 去看看 王恩龙

软件测试的基本原则是站在用户的角度,对产品进行全面测试,

尽早、尽可能多地发现Bug, 并负责跟踪和分析产品中的问题,对不足之处提出质疑和改进意见。

零缺陷(Zero-Bug) 是一种理念.

足够好(Good-Enough)是测试的基本原则

软件测试过程中,应注意和遵循的具体原则,可以概括为十大项:

1. 所有测试的标准都是建立在“用户需求”之上。

正如我们所知,软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求,所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响,系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。

2.软件测试必须基于“质量第一”的思想去开展各项工作.

当时间和质量冲突时,时间要服从质量。质量的理念和文化(如零缺陷的“第一次就把事情做对”)同样是软件测试工作的基础。

3.事先定义好产品的“质量标准”。

有了质量标准,才能依据测试的结果对产品的质量进行正确的分析和评估,例如,进行性能测试前,应定义好产品性能的相关的各种指标。同样,测试用例应确定预期输出结果,如果无法确定测试结果,则无法进行校验。

4.软件项目一启动,软件测试同时开始.

而不是等程序写完,才开始进行测试。在代码完成之前,测试人员要参与需求分析、系统或程序设计的审查工作,而且要准备测试计划、测试用例、测试脚本和测试环境,测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后开始。

应当把“尽早和不断地测试”作为测试人员的座右铭。

5.穷举测试是不可能的。

甚至一个大小适度的程序,其路径排列的数量也非常大,因此,在测试中不可能运行路径的每一种组合,然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。

6.  第三方进行测试会更客观,更有效。

程序员应避免测试自己的程序,为达到最佳的效果,应由第三方来进行测试。测试是带有 ”挑剔性” 的行为,心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。

7.软件测试计划是做好软件测试工作的前提。

在进行实际测试之前,应制定良好的、切实可行的测试计划并严格执行,特别要确定测试策略和测试目标。

8.测试用例是设计出来的,不是写出来的.

要根据测试的目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多地发现错误,提高程序的可靠性。除了检查程序是否做了应该做的事,还要看程序是否做了不该做的事;不仅应选用合理的输入数据,对于非法的输入也要设计测试用例进行测试。

9.不可将测试用例置之度外,排除随意性。

特别是对于做了修改之后的程序进行重新测试时,如不严格执行测试用例,将有可能忽略由修改错误而引起的大量的新错误。所以,回归测试的关联性也应引起充分的注意,有相当一部分最终发现的错误是在早期测试结果中遗漏的。

10.对发现错误较多的程序段,应进行更深入的测试。

一般来说,一段程序中已发现的错误数越多,其中存在的错误概率也就越大。错误集中发生的现象,可能和程序员的编程水平和习惯有很大的关系。

2018-05-07 21:50:25 amoscn 阅读数 170
  • 软件测试基础

          主要讲解软件测基础信息,包括如下内容: *  软件测试的发展 * 软件测试定义、目标、原则 * 软件测试模型(V模型、W模型、H模型等)      * 软件测试准入准出的标准(包括缺陷的生命周期、测试用例的相关属性字段) * 测试方法的分类 * 白盒测试(语句、条件、判定、条件/判定、条件组合、路径等覆盖) * 黑盒测试(等价类、边界值、因果图)       通过该系列课程,能达到对软件测试有一个简单的认识,知道通过一些方法来分析需求,编写测试用例,来管理缺陷,有一个简单的测试流程体系,知道如何测试、如何编写测试用例等。

    2444 人正在学习 去看看 王恩龙

所有的测试软件测试都应追溯到用户需求

这是因为软件测试的目的是使用户完成预定的任务,并满足用户的需求,而软件测试的所揭示的缺陷和错误使软件达不到用户的目标,满足不了用户的需求。

应当将“尽早地和不断地进行软件测试”作为软件测试者的座右铭

测试需求贯穿整个软件的生命周期,缺陷修复成本随着各个阶段的靠后而提升。从平时的醒目中已看出,需求阶段引入的bug不比设计阶段少,如何保证好需求的稳定有效已经至关重要。

完全测试是不可能地,测试需要终止

即Zero Bug与Good Enough;本条给我们灌输的是一种测试执行通过的标准。显示任何测试通过不可能达到0bug。那我们就应该达到Good Enough。这条原则是一种权衡投入/产出比的原则:测试既不能不充分也能过,我们需要制定测试通过标准和测试内容,比如:遗留的bug数&严重程度,测试用例的执行率&通过率等来解决上面的问题。

软件测试无法显示软件潜在的缺陷

进行测试时可以查找并报告发现的软件缺陷和错误,但是不能保证软件的缺陷和错误能全部找到,继续进一部测试可能还会找到一些,也就是说测试只能证明软件存在错误而不能证明软件没有错误。

充分注意测试中的集群现象

即80-20原则;这条主要想告诉我们的就是缺陷的集群现象,发现缺陷越多的模块就需要投入更多的人力精力去测试。

程序员应避免检查自己的程序

为了达到测试目的,应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。

尽量避免测试的随意性

制定严格的测试计划,并把测试时间安排的尽量宽松,有组织、有计划、有步骤的开展测试活动。

回归测试的关联性

回归测试的关联性一定要引起充分注意。修改一个错误而引起更多错误出现的现象并不少见。

关注程序不该做的事

检查程序应该完成哪些功能,这只是测试工作的一半,测试工作的另一半是,检查程序完成了哪些不应该完成的功能。

说明:文章大部分内容转载自:软件测试原则 - 吴卓扬

2019-11-25 20:04:04 qq_41569732 阅读数 113
  • 软件测试基础

          主要讲解软件测基础信息,包括如下内容: *  软件测试的发展 * 软件测试定义、目标、原则 * 软件测试模型(V模型、W模型、H模型等)      * 软件测试准入准出的标准(包括缺陷的生命周期、测试用例的相关属性字段) * 测试方法的分类 * 白盒测试(语句、条件、判定、条件/判定、条件组合、路径等覆盖) * 黑盒测试(等价类、边界值、因果图)       通过该系列课程,能达到对软件测试有一个简单的认识,知道通过一些方法来分析需求,编写测试用例,来管理缺陷,有一个简单的测试流程体系,知道如何测试、如何编写测试用例等。

    2444 人正在学习 去看看 王恩龙

记录 软件工程北大-软件测试技术课件

著名的软件错误案例研究

1、迪斯尼的狮子王

1994年秋天,迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏LionKing
Animated Storybook(狮子王动画故事书)。这次是迪斯尼公司首次进军游戏市场。他们进行了大力宣传促销。结果,销售额非常可观。该游戏成为孩子们那个夏季的“必买游戏”。后来却飞来横祸。12月26日,圣诞节后的一天,迪斯尼公司的客户支持部电话开始响个不停。很快,电话支持部门就淹没在愤怒的家长和哭诉玩不成游戏的孩子们的电话狂潮之中。报纸和电视中涌现了各种故事。

原因:迪斯尼公司没有对市场上投入使用的各种PC机型进行正确的测试。软件在少数系统中工作正常——例如迪斯尼的程序员用于开发游戏的系统——但在大众使用的常见系统中却不行。

没有在各种PC上正确的测试,软件只能在少数机器上正常运行。

兼容性测试

2、美国航天局火星基地登陆,1999

1999年12月3日,美国航天局的火星基地登陆飞船在试图登陆火星表面时失踪。错误修正委员会观测到故障,并认定出现误动作的原因极可能是某一个数据被意外更改。

大家一致声讨,问题为什么没有在内部测试时解决。

从理论上看,登陆计划是:当飞船降落在火星表面时,它将打开降落伞减缓飞船的下落速度。降落伞打开后的几秒种内,飞船的三条腿将迅速撑开,并在预定地点着陆。当飞船离地面1800米时,它将丢弃降落伞,点燃登陆推进器,在余下的高度缓缓降落地面。
美国航天局为了省钱,简化了确定何时关闭推进器的装置。为了替代其他太空船上使用的贵重雷达,他们在飞船的脚上装了一个廉价的触点开关,在计算机中设置一个数据位来关掉燃料。即,飞船的脚不“着地”,引擎就会着火。
错误修正委员会在测试中发现,当飞船的脚迅速撑开并准备着陆时,机械震动在大多数情况下也会触发着地开关,设置错误的数据位。设想飞船开始着陆时,计算机极有可能关闭推进器,而火星登陆飞船下坠1800米之后冲向地面,撞成碎片。

原因:登陆飞船经过了两个小组测试,其中一个小组测试飞船的脚落地过程,另一个小组测试此后的着陆过程。前一个小组不去注意着地数据位是否置位,后一个小组总是在开始测试之前重置计算机、清除数据位。双方独立工作很好,但从未在一起进行集成测试。

单个测试 从未在一起进行集成测试。

3、爱国者导弹防御系统,1991

​ 美国爱国者导弹防御系统是里根总统提出的主动战略防御(即星球大战)程序的缩略版本。它首次应用在海湾战争中对抗伊拉克飞毛腿导弹的防御战争中。尽管关于此系统的赞誉不绝于耳,但是它确实在几次对抗导弹战役中失利,其中一枚在沙特阿拉伯的多哈击毙28名美国士兵。

原因:存在一个软件缺陷。一个很小的系统时钟错误积累起来就可能拖延14小时,造成跟踪系统失去准确度。在多哈袭击战中,系统被拖延100多小时。

缺陷 错误的累积 一直积累 最终影响很大很大。

4、千年虫,大约1974

4、千年虫,大约1974
20世纪70年代某位程序员——假设他叫Dave——负责本公司的工资系统。他使用的计算机存储空间很小,迫使他尽量节省每一个字节。Dave自豪地将自己的程序压缩得比其他人都小。
他使用的其中一个办法是把4位数日期,例如1973缩减为2位数,例如73。因为工资系统极度依赖数据处理,Dave得以节省可观的存储空间。他认为只有在到达2000年时程序计算00或01这样的年份时才会出现问题。他知道这样会出问题,但是在25年之内程序肯定会更改或升级,而且眼前的任务比现在计划遥不可及的未来更加重要。
这一天毕竟是要到来的。1995年,Dave的程序仍然在使用,而Dave退休了,谁也不会想到进入程序检查2000年兼容问题,更不用说去修改了。
估计世界各地更换或升级类似Dave程序以解决原有2000年错误的费用以及超过数亿美元了。

尽可能节省空间 四位数日期 减为二位 到00年时程序计算会出错,还有几十年不要紧软件程序会升级修改的,眼前的任务要求更重要,那一天到了,00兼容问题。

软件测试的定义和目标

定义

软件测试:检测和评价软件以确定其质量的过程和方法,即评价软件或程序的属性和能力,以确定它是否满足所需结果的过程与方法。

软件测试可分为静态分析和动态测试:

只是检查和审阅 运行和使用软件

(1)进行静态分析时,不必运行软件,只是通过对源代码进行分析,检测程序的控制流和数据流,以及发现执行不到的“死代码”、无限循环、未初始化的变量、未使用的数据、重复定义的数据等;也可能包括对多种复杂性度量值的计算。静态分析虽然不能取代动态测试,但它是动态测试开始前有用的质量检测手段。
(2)动态测试技术借助于输入样例(即测试用例)来执行软件,一般又分为功能测试(即黑盒测试)以及结构测试(即白盒测试)。

From:《计算机科学技术百科全书》(第二版),张效祥主编,清华大学出版社,2005年11月。

目标

软件测试目标:
(1)预防错误
(2)发现错误

发现错误 预防错误

一般只有符合下列5个规则才叫软件错误:
1.软件未达到产品说明书标注的功能.
2.产品出现了产品说明书指明不会出现的错误.
3.软件功能超出产品说明书的范围.
4.软件未达到产品说明书虽未指出但应达到的目标.
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
From:《软件测试》,(美)Patton, R.著,北京:机械工业出版社,2002.2.

满足不了产品说明书的要求

软件测试与软件调试的区别

软件调试

软件调试:发现所编写软件中的错误,确定错误的位置并加以排除,使之能由计算机或相关软件正确理解与执行的方法与过程。

​ 在进行调试工作以前,首先要发现存在着某种错误的迹象。随后的调试过程通常分为两步:

(1)确定问题的性质并且找到该错误在软件中所处的位置;

(2)修正这一错误。

From:《计算机科学技术百科全书》(第二版),张效祥主编,清华大学出版社,2005年11月。

发现所编写程序错误,确定位置加以改正。

确定问题的性质找到错误位置,修正这一错误。

软件测试和软件调试的主要区别:

(1)测试从一个侧面证明程序员的“失败”,而调试是为了证明程序员的正确。
(2)测试以已知条件开始,使用预先定义的程序,且有预知的结果,不可预见的仅是程序是否通过测试。调试一般是以不可知的内部条件开始,除统计性调试外,结果是不可预见的。
(3)测试是有计划的,并要进行测试设计;而调试是不受时间约束的。
(4)测试是一个发现错误、改正错误、重新测试的过程;而调试是一个推理过程。
(5)测试的执行是有规律的,而调试的执行往往要求程序员进行必要推理以至知觉的“飞跃”。
(6)测试经常是由独立的测试组在不了解软件设计的条件下完成的;而调试必须由了解详细设计的程序员完成。
(7)大多数测试的执行和设计可由工具支持,而调试时,程序员能利用的工具主要是调试器。

证明 推理 调试器 未知

软件测试过程模型

在这里插入图片描述

软件测试过程所涉及的要素,以及这些要素之间的关系 。

环境:包括支持其运行的硬件、固件和软件;
被测对象模型:为了测试,形成被测对象的简化版本。不同的测试技术,对同一被测对象(程序),可产生不同的对象模型:
简化注重程序的控制结构---形成“白盒”测试
简化注重程序的处理过程---形成“黑盒”测试
错误模型:为了统一认识,定义“什么是错误”。

不同的测试,可产生不同的对象模型

控制结构 白盒测试

处理过程 黑盒测试

什么是错误?

几个关键性的概念:

错误 error

错误(error)是指“与所期望的设计之间的偏差,该偏差可能产生不期望的系统行为或失效”。

期望

失效 failure

失效(failure)是指“与所规约的系统执行之间的偏差”。失效是系统故障或错误的后果。

失效 系统故障 错误的后果

故障 fault

故障(fault)是指“导致错误或失效的不正常的条件”。故障可以是偶然性的或是系统性的。

故障 不正常或导致错误的条件

三者的关系

三者关系:
程序员编写程序,在这个过程中,他无意或有意地犯一个错误(error)。故障(fault)是一个或多个错误的表现。
当执行程序中那段有故障的代码时,就会引起失效(failure),导致程序出现不正确的状态,影响程序的输出结果。

一个个错误 表现故障了 引起失效

error fault failure

软件测试的原则

软件测试的原则
(1)所有的测试都应当追朔到用户需求。软件测试的目的在于发现错误,而从用户角度看,最严重的错误就是那些致使程序无法满足需求的错误。

无法满足需求的错误 这软件不能做到我想要的结果 解决我要解决的问题

(2)在测试工作开始前,要进行测试计划的设计。测试计划可以在需求分析一完成时开始,详细的测试用例定义可以在设计模型被确定后立即开始。

测试计划 需求分析 测试用例 设计模型

(3)测试应从小规模开始,逐步转向大规模。最初的测试通常放在单个程序模块上,测试焦点逐步转移到在集成的模块簇内寻找错误,最后在整个系统中寻找错误。

小 到 大 单个模块 集成模块 整个系统 找错误

(4)穷举测试是不可能的。一个大小适度的程序,其路径排列的数量是惊人的。

穷举测试是不可能的 适度的

(5)为了尽可能发现错误,应由独立的第三方来测试。

第三方来测试 独立的

(6)在一般情况下,在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的bug, 而系统测试又能找出其余一些bug,最后剩下的bug可能只能在用户的大范围、长时间的使用后才会暴露。因此测试只能保证尽可能多地发现错误,无法保证能够发现所有的错误。

尽早找出错误

软件测试技术

黑盒测试

黑盒测试:
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。

功能 数据驱动 测试 已知功能来测试检测功能正常使用

不考虑程序内部结构 内部特性 直接根据功能来测试

程序功能是否正常使用 接收输入数据产生正确的输出

​ 黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等,主要用于软件确认测试。
​ “黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

等价类划分 边界值分析 黑盒测试 软件确认测试

穷举输入方测试 尽可能多的输入 测试 合法的 不合法 输入

黑盒测试试图发现以下错误类型:
(1)功能不对或遗漏;
(2)界面错误;
(3)数据结构或外部数据库访问的错误;
(4)性能错误;
(5)初始化和终止错误.

功能不对 遗漏 界面 数据结构 访问数据库 性能 初始化 终止

问题:黑盒测试依据是什么?

白盒测试

白盒测试:

​ 白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能.
​ 白盒测试的主要方法有逻辑覆盖、基本路径测试等,主要用于软件验证。

问题:白盒测试依据什么?

结构 逻辑驱动 知道内部工作过程 测试来检测产品内部动作

程序中每条通路是否按预定要求正确工作。

逻辑覆盖 基本路径测试 用于软件验证

白盒测试技术

依据程序的逻辑结构-白盒测试技术

(1)关于建立被测对象模型

​ 控制流程图:一种表示程序控制结构的图形工具,其基本元素是节点、判定、过程块。
其中:过程块是既不能由判定、也不能由节点分开的一组程序语句;
​ 判定:是一个程序点,此处控制流可以分叉;
​ 节点:是一个程序点,此处控制流可以结合。
​ 、在这里插入图片描述

例如:以下为一个程序流程图,其中该例子中有两个判断,
每个判断都包含复合条件的逻辑表达式。

在这里插入图片描述

在这里插入图片描述

(2)各种测试方法

该控制流程图有4条不同的路径。4条路径可表示为:
L1(a→c→e)简写ace 、L2(a→b→d)简写abd
L3(a→b→e)简写abe 、L4(a→c→d)简写acd
 路径测试(PX):执行所有可能的穿过程序的控制
流程路径。
一般来说,这一测试严格地限制为所有可能的入口/出
口路径。如果遵循这一规定,则我们说达到了100%路径覆盖
率。在路径测试中,该策略是最强的,但一般是不可实现的。
针对该例子,要想实现路径覆盖,可选择以下一组测试
用例(规定测试用例的设计格式为:【输入的(A,B,X),
输出的(A,B,X)】)。

在这里插入图片描述

语句测试(P1):至少执行程序中所有语句一次。

如果遵循这一规定,则我们说达到了100%语句覆盖率(用C1表达)。
在该例子中,只要设计一种能通过路径ace的测试用例,
就覆盖了所有的语句。所以可选择测试用例如下:
【(2,0,4),(2,0,3)】 覆盖L1
语句覆盖是最弱的逻辑覆盖准则。

问题:就该程序而言,如果两个判断的逻辑运算写错,

例如,第一个判断中的逻辑运算符“∧”错写成了“∨”,或
者第二个判断中的逻辑运算符“∨”错写成了“∧”,利用上面
的测试用例,仍可覆盖其中2个语句,而发现不了判断中逻辑
运算符出现的错误。

 分支测试(P2):至少执行程序中每一分支一次。如果
遵循这一规定,则我们说达到了100%分支覆盖率(用C2表示)。
分支覆盖是一种比语句覆盖稍强的逻辑覆盖。但若程序中
分支的判定是由几个条件联合构成时,它未必能发现每个条件
的错误。
例如对于以上例子,如果选择路径L1和L2,就可得到实现
分支覆盖的测试用例:
【(2,0,4),(2,0,3)】 覆盖L1
【(1,1,1),(1,1,1)】 覆盖L2
如果选择路径L3和L4,还可得另一组可用的测试用例:
【(2,1,1),(2,1,2)】 覆盖L3
【(3,0,3),(3,1,1)】 覆盖L4
问题:分支覆盖还不能保证一定能查出在判断的条件中存
在的错误。例如,在该例子中,若第二个分支X>1错写成X<1,
利用上述两组测试用例进行测试,无法查出这一错误。因此,
需要更强的逻辑覆盖准则去检验判定的内部条件。

 条件组合测试
条件组合测试是一种具有更强逻辑覆盖的测试。
条件组合测试,就是设计足够的测试用例,使每个判定
中的所有可能的条件取值组合至少执行一次。如果遵循这一
规定,则我们说就实现了条件组合覆盖。只要满足了条件组
合覆盖,就一定满足分支覆盖。
在条件组合覆盖技术发展过程中,最初,在设计测试用
例时,人们只考虑使分支中各个条件的所有可能结果至少出
现一次。但发现该测试技术未必能覆盖全部分支。例如,在
上图的例子中,程序段中有四个条件:A>1,B=0,A=2,X>1。
条件A>1 取真值标记为T1,取假值标记为F1
条件B=0 取真值标记为T2,取假值标记为F2
条件A=2 取真值标记为T3,取假值标记为F3
条件X>1 取真值标记为T4,取假值标记为F4
在设计测试用例时,要考虑如何选择测试用例实现T1、
F1、T2、F2、T3、F3、T4、F4的全部覆盖:

例如,可设计如下测试用例实现条件覆盖:
测 试 用 例 通过路径 条件取值 覆盖分支

【(1,0,3),(1,0,4)】 L3 F1 T2 F3 T4 b,e
【(2,1,1),(2,1,2)】 L3 T1 F2 T3 F4 b,e
从上面的测试用例,可以看到该组测试用例虽然实现了
判定中各条件的覆盖,但没有实现分支覆盖,因为该组测试
用例只覆盖了第一个判断的取假分支和第二个判断的取真分
支。为此,人们又进一步提出了条件组合覆盖技术。
例如,在该例子中,前一个判定有4种条件组合:
(1)(A>1),(B=0), 标记为 T1 、T2;
(2)(A>1),(B≠0),标记为 T1 、F2,;
(3)(A≤1),(B=0), 标记为 F1 、T2;
(4)(A≤1),(B≠0),标记为 F1 、F2;
后一个判定又有4种条件组合:
(5)(A=2), (X>1), 标记为 T3、T4;
(6)(A=2), ( X≤1),标记为 T3、F4;
(7)(A≠2),( X>1),标记为 F3、T4;
(8)(A≠2),( X≤1),标记为 F3、F4。

在这里插入图片描述

在这里插入图片描述

黑盒测试(功能测试)-依据软件行为的描述的测试

黑盒测试(功能测试)-依据软件行为的描述的测试

事务流测试技术

( 1 )基本概念:
事务:以用户的角度所见的一个工作单元。
一个事务由一系列操作组成。其中某些操作可含有系统执行成分,或含有设备执行成分,它们共同协作,完成用户的一项工作。
事务处理流程(图):系统行为的一种表示方法,为功 能测试建立了软件动作模式。其中使用了白盒测试中的一些概念,例如:操作(如下图1、3、6、5)、分支(下图2),节点(下图7),链(下图中 )等。

在这里插入图片描述

在这里插入图片描述

(3)测试步骤
第一步:获取事务流程图,即建立被测对象模型;
第二步:浏览与复审
主要对事务进行分类,为设计用例奠定基础;
第三步:用例设计
设计足够测试用例,实现基本事务覆盖。
     涉及:覆盖策略,事务选取等;
第四步:测试设备开发:
路径分析器,测试用例数据库,
测试执行调度器, …
第五步:测试执行;
第六步:测试结果比较。

等价类划分技术

等价类划分技术
(1) 基本概念
等价类:输入域的一个子集,在该子集中,各个输入
数据对于揭示程序中的错误都是等效的。即:以等价类中
的某代表值进行的测试,等价于对该类中其他取值的测试。
有效等价类:指那些对于软件的规格说明书而言,是
合理的、有意义的输入数据所构成的集合。
-用于实现功能和性能的测试。
无效等价类:指那些对于软件的规格说明书而言,是
不合理的、无意义的输入数据所构成的集合。
-用于测试那些所实现的功能和性能不符合规格说明
书的要求。

(2)等价类划分原则(指南)

在这里插入图片描述

如果输入条件是一个布尔量,则可以确定一个有效等价
类和一个无效等价类。
如果输入条件规定了输入值必须符合的条件,则可以确定
一个有效等价类(符合条件)和一个无效等价类(不符合条件)。
例如:“标识符是一字母打头的…串。” 则
字母打头的–为一个有效等价类,而
其余的–为一个无效等价类

注意:如果在已确定的等价类中各元素在软件中的处理方
式不同,则应根据需要对等价类进一步进行划分。

在这里插入图片描述
​ (3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

问题:为什么设计无效等价类的测试用例时仅包括一个未被覆盖的无效等价类?

因为某些程序中对某一输入错误的检查往往会屏蔽对其它输入错误的检查。因此设计无效等价类的测试用例时应该仅包括一个未被覆盖的无效等价类。

边界值分析

边界值分析
边界值分析是一种最常用的黑盒测试技术。因为测试工作经验表明,大量的错误经常发生在输入或输出范围的边界上。因此设计一些测试用例,使程序运行在边界情况附近,这样揭露错误的可能性比较大。

边界值分析 最常用 黑盒测试技术 大量的错误经常发生在输入或输出范围的边界上 设计一些测试用例 边界上 设计一些测试用例 揭露错误 可能性比较大

​ 使用边界值分析设计测试用例可遵循以下原则:
(1)如果某个输入条件规定了输入值的范围,则应选择正好等于边界值的数据,以及刚刚超过边界值的数据作为测试数据。
(2)如果某个输入条件规定了值的个数,则可用最大个数、最小个数、比最大个数多1、比最小个数少1的数作为测试数据。
(3)根据规格说明的每个输出条件,使用前面的原则(1)。
(4)根据规则说明的每个输出条件,使用前面的原则(2)。

(5)如果程序的规格说明中,输入域或输出域是一个有序集合,在实践中,则经常选取集合的第一个元素、最后一个元素以及典型元素作为测试用例。
(6)如果程序中使用了内部数据结构,则应选择这个内部数据结构的边界上的值作为测试用例。
(7)分析规则说明,找出其他可能的边界条件。

边界范围 超一点

因果图

因果图
因果图:是设计测试用例的一种工具,它着重检查各种输入条件的组合。例如,两个输入值的乘积超过了存储器的限制,程序将发生错误。等价划分和边界值分析够不能发现这类错误,因为它们未考虑输入情况的各种组合。
因果图的基本原理是通过画因果图,把用自然语言描述的功能说明转换为判定表,最后为判定表的每一列设计一个测试用例。

输入条件的组合 各种组合

判定表

参考资料

[1]-北京大学软件工程 http://www.icourses.cn/sCourse/course_6305.html

[2] 张海藩,吕云翔. 软件工程(第4版)[M]. 北京:人民邮电出版社,2013 软件工程

2004-10-29 09:40:00 cnlx 阅读数 1653
  • 软件测试基础

          主要讲解软件测基础信息,包括如下内容: *  软件测试的发展 * 软件测试定义、目标、原则 * 软件测试模型(V模型、W模型、H模型等)      * 软件测试准入准出的标准(包括缺陷的生命周期、测试用例的相关属性字段) * 测试方法的分类 * 白盒测试(语句、条件、判定、条件/判定、条件组合、路径等覆盖) * 黑盒测试(等价类、边界值、因果图)       通过该系列课程,能达到对软件测试有一个简单的认识,知道通过一些方法来分析需求,编写测试用例,来管理缺陷,有一个简单的测试流程体系,知道如何测试、如何编写测试用例等。

    2444 人正在学习 去看看 王恩龙
中国软件评测中心的测试原则就是从用户和开发者的角度出发进行软件产品测试的,通过我们的测试,可以为用户提供放心的产品,并对优秀的产品进行认证。
为了达到上述原则,需要注意:
1.应当把“尽早和不断的测试”作为开发者的座右铭
软件测试员的基本目标是发现软件缺陷,追求的是尽可能早的找出软件缺陷,必需确保的是找出的软件缺陷得以修补
2.程序员应该避免检查自己的程序,测试工作应该由独立的专业的软件测试机构来完成。
3.设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件,特殊情况下要制造极端状态和意外状态,比如网络异常中断、电源断电等情况。
4.一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。
5.对测试错误结果一定要有一个确认的过程,一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。
6.制定严格的测试计划,并把测试时间安排的尽量宽松,不要希望在极短的时间内完成一个高水平的测试。
7.回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多的错误出现的现象并不少见。
8.妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。

软件缺陷的原则

阅读数 664

没有更多推荐了,返回首页