关于软件测试的浅谈.docx
- 文档编号:3992522
- 上传时间:2022-11-27
- 格式:DOCX
- 页数:29
- 大小:40.67KB
关于软件测试的浅谈.docx
《关于软件测试的浅谈.docx》由会员分享,可在线阅读,更多相关《关于软件测试的浅谈.docx(29页珍藏版)》请在冰豆网上搜索。
关于软件测试的浅谈
毕业设计任务书
设计(论文)
题目
关于软件测试的浅谈
选题时间
完成时间
论文(设计)字数
2万字
关键词
软件测试,测试过程
设计(论文)题目来源、理论和实际意义:
首先对测试人员的职业素质和职业道德要求都非常高,因为每一个测试人员掌握公司的产品的致命是最多的。
尤其是测试报告的一些内容,他要比任何开发人员要知道多,所以非常需要每个测试人员的职业道德。
除了对测试人员的职业技能要求外,还要对测试人员的职业素质的要求。
不能因为这几天心情好,工作情况就非常好,发现的问题就多;或因为这几天心情非常差,发现的问题就少。
这样就会严重影响产品的质量,带来的后果是严重的。
测试工作一定要保持一种平常的心态,与开发人员沟通的时一定要掌握技巧。
人是软件企业的立足之本。
了解参与项目开发人员的心理活动,对于项目管理者来说,可以顺势利导,消除不良的人为因素,提高团队的凝聚力和工作能力,从而提高开发效率。
设计(论文)的主要内容:
摘要………………………………………………………………… 2
关键词……………………………………………………… 2
绪论.…………………………………………………………………… 2
一. 软件测试的概念………………………………………………… 3
1.1 什么是软件测试………………………………………… 2
1.2软件测试的定义…………………………………………2
1.3. 软件测试的目的……………………………………………2
1.4. 软件测试的分类………………………………………… 2
1.5 软件测试的原则 …………………………………… 2
1.6 软件测试停止的标准………………………………………… 3
1.7软件测试的概述…………………………………………3
1.8软件测试的内容…………………………………………4
二. 软件测试的流程与策略……………………………………………4
2.1 单元测试…………………………………………………………4
2.2 集成测试………………………………………………………………5
2.3 确认测试……………………………………………………………… 5
2.4 系统测试…………………………………………………………………5
2.5 验收测试…………………………………………………………………7
三.自动化测试技术基础……………………………………………………8
3.1自动化测试概念 ..........................................9
3.1.1自动化测试 .......................................... 9
3.1.2自动化测试的优点 .................................... 9
3.1.3自动化测试的局限性 ................................. 11
3.2自动化测试的适用范围 ....................................... 12
四.简要解析软件测试的认识误区……………………… ………… 13
五.结束语………………………………………………………………… 13
六.参考文献…………………………………………………………… 14
摘要
本文从介绍软件测试的概念入手,简单的阐述了软件测试的目的,方法及其重要性,然后简单分析了软件测试的过程,以及软件测试的几大误区。
关键词
软件测试,测试过程。
绪论
软件测试在全球的发展是不平衡的,在发达国家和地区,软件测试已经成了一个产业,而在中国,可能还算不上一个真正的产业,这与中国整体软件的发展水平是一致的,因为我国整体的软件产业水平和软件发达国家水平相比有较大的差距,而作为软件产业重要一环的软件测试,必然有不小的差距。
不过,目前正在快速发展阶段。
中国软件企业在软件测试方面与国际水准仍存在较大差距,主要体现在测试意识以及测试理论的 研究、大型测试工具软件的开发以及从业人员数量等方面。
首先 ,在认识上重开发 、轻测试 ,没有认识到:
软件项目的如期完成不仅取决于开发人员,更取决于测试人员;其次,测试理论和测试方法并没有全面的掌握没有将测试同公司目前的开发流程紧密的绑定起来,大部分的软件测试工作没有明确的目标和可量化的质量要求,对质量的控制基本上靠测试人员自己的经验和责任;另外,缺少自动化工具的支持,软件测试基本停留在手工进行的功能性测试上,大部分是在软件开发的后期介入。
在技术支持过程中将会给相同的问题做几百次或上千次更有甚者要做上万次技术支持。
也就是说测试人员和开发人员多用一份力量和多用份心思去做产品,至少给公司减少了几个或几十个技术支持人员,只是这项就会带来巨大的利润,这就说明了软件测试在软件行业的重要性。
团队一直强调“软件测试人员一定要低调做事”,尤其是软件测试是永远发现不完所有潜在的问题,所以测试的重点必须放在基本功能,但也不能不去发现逻辑问题和界面等方面的问题。
尤其做软件测试这项对人员的素质要求特别高,在有限的时间里尽最大努力地发现最多问题并促进和协助开发人员解决问题。
软件测试工作不但对软件质量起了一定的保证作用,也是降低产品成本和缩短软件开发周期的重要措施。
一.软件测试的概念
测试涉及我们生活的各个方面,它是个非常广泛的概念。
测试是随着现代化发展而产生的。
软件测试,它是软件工程的一部分。
测试活动是一项工程性的活动,而不是一项简单的、孤立的活动。
1.1什么是软件测试
软件测试的典型说法
一个好的测试是指很可能找到尚未发现的错误的测试;
一个成功的测试是指发现了至今未发现的错误的测试。
这种说法明确指出“寻找错误”是软件测试的目的。
1.2软件测试的定义 (1983)
使用人工和自动的手段来运行过测试某个系统的过程,其目的在于它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
软件测试使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它
是否满足规定的需求或弄清预期结果与实际结果之间的差别。
它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness) 完全度(completeness)和质量(quality)的软件过程;是SQA(software quality assurance)的重要子域。
(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进;
(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性;
(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法。
这种定义提出了软件测试是以是否满足需求为目标。
1.3. 软件测试的目的
测试的目的是最大限度地找出最多的错误。
软件测试的目的是查找程序中的故障,并力求设计出最能暴露故障的测试方案,从而合理地设计测试用例。
证明、检测和预防已经成为一个良好测试的目标。
1.4. 软件测试的分类
从实际用户使用的角度考虑,软件测试一般采用黑盒测试;从程序内部的设计结构出发,软件测试一般采用白盒测试。
从是否运行被测程序的角度考虑,软件测试一般分为静态测试和动态测试。
1.4.1常用分类
从是否需要执行被测软件的角度可分为:
-静态测试
-动态测试
从测试是否针对系统的内部结构和具体实现算法的角度来看,可分为:
-白盒测试
-黑盒测试
1.4.2黑盒测试和白盒测试
1、黑盒测试和白盒测试
黑盒测试指的是把被测软件看作是一个黑盒子,我们不去关心盒子里面的结构是什么样子,只关心软件的输入数据和输出结果。
黑盒测试方法是在程序接口上进行测试,主要是为了发现以下错误:
•是否有不正确或遗漏了的功能?
•在接口上,输入能否正确地接受?
能否输出正确的结果?
•是否有数据结构错误或外部信息(例如数据文件)访问错误?
•性能上是否能够满足要求?
•是否有初始化或终止性错误?
用黑盒测试发现程序中的错误,必须在所有可能的输入条件和输出条件中确定测试数据,来检查程序是否都能产生正确的输出。
但这是不可能的。
n假设一个程序P有输入量X和Y及输出量Z。
在字长为32位的计算机上运行。
若X、Y取整数,按黑盒方法进行穷举测试:
n可能采用的测试数据组:
232×232=264
n如果测试一组数据需要1毫秒,一年工作365×24小时,完成所有测试需5亿年。
黑盒测试的测试用例设计
•等价划分法
•边界值法
•错误推测法
•因果图法
1.等价类划分
1>等价类划分是一种典型的黑盒测试方法,使用这一方法时,完全不考虑程序的内部结构只依据程序的规格说明来设计测试用例。
2>等价类划分方法把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每一部分中选取少数有代表性的数据做为测试用例。
3>使用这一方法设计测试用例要经历划分等价类(列出等价类表)和选取测试用例两步。
4>划分等价类等价类是指某个输入域的子集合。
在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。
测试某等价类的代表值就等价于对这一类其它值的测试。
等价类的划分有两种不同的情况:
①有效等价类:
是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。
②无效等价类:
是指对于程序的规格说明来说,是不合理的,无意义的输入数据构成的集合。
在设计测试用例时,要同时考虑有效等价类和无效等价类的设计。
划分等价类的原则
(1)如果输入条件规定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类。
n例如,在程序的规格说明中,对输入条件有一句话:
“„„项数可以从1到999„„”则有效等价类是“1≤项数≤999”两个无效等价类是“项数<1”或“项数>999”。
(2)如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件, 这时可确立一个有效等价类和一个无效等价类。
例如, 在Pascal语言中对变量标识符规定为“以字母打头的„„串”。
那么所有以字母打头的构成有效等价类, 而不在此集合内(不以字母打头)的归于无效等价类。
(3) 如果输入条件是一个布尔量, 则可以确定一个有效等价类和一个无效等价类。
(4) 如果规定了输入数据的一组值, 而且程序要对每个输入值分别进行处理。
这时可为 每一个输入值确立一个有效等价类, 此外针对这组值确立一个无效等价类, 它是所有不允许的输入值的集合。
2.边界值分析
•边界值分析也是一种黑盒测试方法, 是对等价类划分方法的补充。
•人们从长期的测试工作经验得知, 大量的错误是发生在输入或输出范围的边界上, 而不是在输入范围的内部。
因此针对各种边界情况设计测试用例, 可以查出更多的错误。
比如, 在做三角形计算时, 要输入三角形的三个边长:
A、B和C。
我们应注意到这三个数值应当满足
A>0、B>0、C>0、
A+B>C、A+C>B、B+C>A, 才能构成三角形。
但如果把六个不等式中的任何一个大于号“>”错写成大于等于号“≥”, 那就不能构成三角形。
问题恰出现在容易被疏忽的边界附近。
这里所说的边界是指, 相当于输入等价类和输出等价类而言, 稍高于其边界值及稍低于其边界值的一些特定情况。
使用边界值分析方法设计测试用例, 首先应确定边界情况。
应当选取正好等于, 刚刚大于, 或刚刚小于边界的值做为测试数据, 而不是选取等价类中的典型值或任意值做为测试数据。
3.错误推测法
• 人们也可以靠经验和直觉推测程序中可能存在的各种错误, 从而有针对性地编写检查这些错误的例子。
这就是错误推测法。
•错误推测法的基本想法是:
列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据它们选择测试用例。
4.因果图 因果图的适用范围
如果在测试时必须考虑输入条件的各种组合, 可使用一种适合于描述对于多种条件的组合, 相应产生多个动作的形式来设计测试用例, 这就需要利用因果图。
因果图方法最终生成的就是判定表。
它适合于检查程序输入条件的各种组合情况。
(1) 分析软件规格说明描述中, 哪些是原因 (即输入条件或输入条件的等价类), 哪些是结果 (即输出条件), 并给每个原因和结果赋予一个标识符。
(2) 分析软件规格说明描述中的语义, 找出原因与结果之间, 原因与原因之间对应的是什么关系?
根据这些关系, 画出因果图。
(3) 由于语法或环境限制, 有些原因与原因之间, 原因与结果之间的组合情况不可能出现。
为表明这些特殊情况, 在因果图上用一些记号标明约束或限制条件。
(4) 把因果图转换成判定表。
(5) 把判定表的每一列拿出来作为依据, 设计测试用例。
白盒测试
指的是把盒子盖打开, 去研究里面的源代码和程序结构。
白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 按照程序内部的结构测试程序, 检验程序中的每条通路是否都有能按预定要求正确工作, 而不顾它的功能。
使用被测单元内部如何工作的信息, 允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例, 对程序的逻辑路径进行测试。
基于一个应用代码的内部逻辑知识, 测试是基于覆盖全部代码、分支、路径、条件。
白盒测试的主要方法:
•逻辑驱动测试 •基本路径测试 主要用于软件验证。
使用程序设计的控制结构导出测试用例。
逻辑驱动测试:
主要是测试覆盖率, 以程序内在逻辑结构为基础的测试。
包括以下6种类型:
•语句覆盖
•判断覆盖
•条件覆盖
•判定-条件覆盖
•条件组合覆盖
•路径覆盖
白盒测试的主要目的
• 保证一个模块中的所有独立路径至少被执行一次;
•对所有的逻辑值均需要测试真、假两个分支;
•在上下边界及可操作范围内运行所有循环;
•检查内部数据结构以确保其有效性
白盒测试的实施方案
在开发阶段
要保证产品的质量, 产品的生产过程应该遵循一定的行业标准。
软件产品也是同样, 没有标准可依自然谈不上质量的好坏。
所有关心软件开发质量的组织、单位, 都要定义或了解软件的质量标准、模型。
其好处是保证公司实践的均匀性, 产品的可维护性、可靠性以及可移植性等。
在测试阶段
与软件产品的开发过程一样, 测试过程也需要有一定的准则, 来指导、度量、评价软件测试过程的质量。
定义测试准则
为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束测试阶段。
准则必须是客观的, 可量化的元素, 而不能是经验或感觉。
根据应用的准则和项目相关的约束, 项目领导可以定义使用的度量方法, 和要达到的覆盖率。
度量测试的有效性、完整性
对每个测试的测试覆盖信息和累计信息, 用图形方式显示覆盖比率, 并根据测试运行情况实时更新, 随时显示新的测试所反映的测试覆盖情况。
允许所有的测试运行依据其有效性进行管理, 用户可以减少不适用于非回归测试的测试的过程。
概念:
1.语句覆盖:
语句覆盖就是设计若干个测试用例, 运行被测试程序, 使得每一条可执行语句至少执行一次;
2.判定覆盖(也称为分支覆盖):
设计若干个测试用例, 运行所测程序, 使程序中每个判断的取真分支和取假分支至少执行一次;
3.条件覆盖:
设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的每个可能取值至少执行一次;
4.判定-条件覆盖:
设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的所有可能取值至少执行一次, 并且每个可能的判断结果也至少执行一次, 换句话说, 即是要求各个判断的所有可能的条件取值组合至少执行一次;
5.条件组合测试:
设计足够多的测试用例, 运行所测程序, 使程序中每个判断的所有可能的条件取值组合至少执行一次;
6.路径测试:
设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径
1.4.3静态测试
是指不实际运行被测软件, 而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。
其中包括代码测试、界面测试和文档测试3个方面。
对于代码测试, 主要测试代码是否符合相应的标准和规范。
对于界面测试, 主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试, 主要测试用户手册和需求说明是否符合用户的实际要求。
1.4.4动态测试
是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程。
所以, 我们判断一个测试属于动态还是静态测试 , 唯一的标准就是看是否运行程序。
单元测试
是指对软件中的最小可测试单元进行检测和验证。
1、什么时候进行单元测试?
通常在程序员编码以后, 代码已经通过编译后进行单元测试, 而且在前期就应该做一些准备工作, 比如撰写单元测试计划、编写单元测试用例等。
千万不要等到项目后期再进行单元测试, 那样就失去了检查代码、预防缺陷的意义了。
2、由谁来进行单元测试?
单元测试一般由白盒测试工程师或开发人员来测试。
如果由开发人员来测试, 最好做到交叉测试, 避免1个人只测试自己的代码。
3、单元测试的依据是什么?
单元测试依据主要有两个, 一个事源程序本身, 包括代码和注释;还有一个是项目的《详细设计》文档。
4、如何进行单元测试?
主要用白盒测试方法, 一般先静态检查代码是否符合规范, 然后动态地运行代码, 检查其实际运行结果。
当然检查运行结果是否正确是一个最基本的要求, 我们还要检查很多项, 比如程序的容错处理, 程序的边界值处理等。
集成测试
集成测试(也叫组装测试或联合测试)是在单元测试的基础上, 将所有模块按照设计要求集成为系统或子系统, 并进行测试。
如果是集成为子系统, 也可以叫做部件测试。
目的
当单个模块集成为系统的过程中, 软件仍然可能出现问题。
比如:
•穿越模块接口的数据是否丢失;
•一个模块功能的实现可能破坏了另一个模块的功能; •子功能组合之后不一定可以达到预期的功能; •全局数据可能被异常修改;
•单个模块的误差被放大到了不能接受的地步。
因此, 需要在模块集成的时候进行整体测试以发现上面可能出现的问题。
必要性
单元测试仅仅保证了模块的局部正确性。
而系统测试一般在整个系统完成之后进行, 错误难以定位。
集成测试具有以下不可替代性:
• 单元测试不彻底, 对于模块间接口信息内容的正确性, 相互调用关系是否符合设计无能为力。
必须依靠集成测试来保证。
•和系统测试相比较, 集成测试从程序结构出发, 目的性, 针对性更强。
发现问题的效率高。
•较容易测试特殊的处理流程。
•定位也比较准确, 迅速。
集成测试的可重复性强, 错误发生后容易定位。
联调和集成测试的区别
(1)
集成和联调都是对系统的装配过程, 不过属于不同的级别。
集成测试
• 测试人员在开发人员的协助下, 制定集成测试计划;
•集成测试主要关注的是接口上消息覆盖, 异常流程, 性能指标等深入测试。
•集成测试是分层次的, 一个模块集成测试后, 可以按照计划进行下一个模块的集成或者更高级别的集成。
•当集成测试完成之后就可以开始联调了。
联调:
一般是指软件系统和硬件平台之间的联调。
可以认为是最高级别的集成测试。
•开发经理在开发测试人员的协助下, 制定系统联调计划。
•相关人员将已通过集成测试的软件系统和硬件平台集成在一起, 构成将交付的系统, 并调通系统的基本功能。
使用系统预测试项来确定基本功能是否都已经实现。
•通过系统联调调通后的版本提交系统预测试组进行系统预测试。
• 在系统的规模比较小比较简单的时候, 可以考虑忽略集成测试而直接进行联调。
但是当系统的规模较大的时候, 跳过集成测试会带来问题难以发现, 难以定位的问题。
完整的测试流程:
单元测试->集成测试->联调->系统预测试->系统测试 集成测试的层次和阶段
集成测试需要分层次, 分阶段完成。
一般情况下, 分层次阶段可以按照以下规律:
•第一个层次是组件测试。
为后继测试提供更加好的原料。
如果系统的一些组件已经充分被测试过,可以跳过这些组件。
•第二个层次是做好集成测试规划:
考虑人力,物力时间测试的重点等。
找出关键的部分,以此作为主线进行计划和资源安排。
•按照计划,把集成测试划分成为不同的阶段,明确各个阶段的主要任务确定任务完成的标记。
集成,单元和系统测试的关联
(1)
•单元测试是针对模块内部功能的白盒测试。
需要辅助测试代码才可以进行测试。
•集成测试也叫:
组装测试,子系统测试,部件测试等。
比如对于模块A进行集成的时候,需要把相关模块一起结合起来才可以进行。
集成测试是注重功能和性能测试的黑盒测试。
•系统测试是将提交的完整软件版本作为一个系统的元素,和硬件、持软件、人员等结合起来,尽可能地模拟实际运行环境进行测试。
测试用例通过系统的需求说明书得到,需要在实际的运行环境下测试。
集成测试的基本方案
可以根据集成测试时组装模块的方式把集成测试方案分成两大类:
一次性集成测试方式
增殖式集成测试方式
•自顶向下方式
•自底向上方式
•混合增殖方式
集成测试的实施
集成测试的方法和步骤
•首先确定子系统有哪些模块组成,保证这些模块都进行过单元测试.
•由开发人员组装这些模块,生成子系统,并保证在此子系统中,各个模块的功能尽可能发挥出来。
•测试前, 以一个关键模块为核心设计测试用例。
以功能和性能为主线, 注重模块间的接口。
•搭建必要的测试环境, 按照所写的测试用例, 进行模块连接的充分测试。
•记录测试结果, 总结测试问题。
集成测试工作的主要内容
• 测试主要依据材料:
概要设计说明书。
•集成测试计划的制定:
包括集成测试进度安排, 人员分配, 测试用例设计。
•集成测试计划的评审。
•集成测试过程:
包括测试过程记录, 问题记录, 问题定位和解决, 问题回归。
•集成测试报告的编写:
包括测试总结, 测试活动评估和测试问题分类统计和分析。
集成测试计划的影响因素
制定集成测试计划的时候, 应该考虑如下因素:
•采用何种系统集成方法来进行集成测试。
•集成测试过程中连接各个模块的顺序。
•模块代码编制和测试进度是否与集成测试的顺序一致。
•测试过程中是否需要专门的硬件设备。
列出各个模块的编制、测试计划表, 标明每个模块单元测试完成的日期、首次集成测试的日期, 需要的测试用例等。
同时考虑测试所需特殊设备的日期情况。
留出时间余量。
集成测试计划的编制
编制之前最好能够明确把握被测试对象
一般需要作以下工作:
•集成测试人员安排
•集成测试方案确定
•集成测试计划的编写
•集成测试的准备工作 系统测试:
System Testing
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 关于 软件 测试 浅谈