1、从是否关心内部结构来看
(1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。
(2)黑盒测试:又称为数据驱动测试,把测试对象当做看不见的黑盒,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性,它是站在使用软件或程序的角度,从输入数据与输出数据的对应关系出发进行的测试。
(3)灰盒测试:是一种综合测试法,它将“黑盒”测试与“白盒”测试结合在一起,是基于程序运行时的外部表现又结合内部逻辑结构来设计用例,执行程序并采集路径执行信息和外部用户接口结果的测试技术。
2、从是否执行代码看
(1)静态测试:指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试:是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能指标。
3、从开发过程级别看
(1)单元测试:又称模块测试,是针对软件设计的最小单位----程序模块或功能模块,进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错,是否能正确地实现了其功能,满足其性能和接口要求。
(2)集成测试:又叫组装测试或联合,是单元测试的多级扩展,是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系,以期望通过测试发现各软件单元接口之间存在的问题,最终把经过测试的单元组成符合设计要求的软件。
(3)系统测试:是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统,作为基于整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
在系统测试中,对于具体的测试类型有:
(1)功能测试:对软件需求规格说明书中的功能需求逐项进行的测试,以验证功能是否满足要求。
(2)性能测试:对软件需求规格说明书的功能需求逐项进行的测试,以验证功能是否满足要求。
(3)接口测试:对软件需求规格说明中的接口需求逐项进行的测试。
(4)人机交互界面测试:对所有人机交互界面提供的操作和显示界面进行的测试,以检验是否满足用户的需求。
(5)强度测试:强制软件运行在异常乃至发生故障的情况下(设计的极限状态到超出极限),验证软件可以运行到何种程序的测试。
(6)余量测试:对软件是否达到规格说明中要求的余量的测试。
(7)安全性测试:检验软件中已存在的安全性、安全保密性措施是否有效的测试,
(8)可靠性测试:在真实的或仿真的环境中,为做出软件可靠性估计而对软件进行的功能(其输入覆盖和环境覆盖一般大于普通的功能测试)
(9)恢复性测试:对有恢复或重置功能的软件的每一类导致恢复或重置的情况,逐一进行的测试。
(10)边界测试:对软件处在边界或端点情况下运行状态的测试。
(11)数据处理测试:对完成专门数据处理功能所进行的测试。
(12)安装性测试:对安装过程是否符合安装规程的测试,以发现安装过程中的错误。
(13)容量测试:检验软件的能力最高能达到什么程度的测试。
(14)互操作性测试:为验证不同软件之间的互操作能力而进行的测试。
(15)敏感性测试:为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
(16)标准符合性测试:验证软件与相关国家标准或规范(如军用标准、国家标准、行业标准及国际标准)一致性的测试。
(17)兼容性测试:验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。
(18)中文本地化测试:验证软件在不降低原有能力的条件下,处理中文能力的测试。
4、从执行过程是否需要人工干预来看
(1)手工测试:就是测试人员按照事先为覆盖被测软件需求而编写的测试用例,根据测试大纲中所描述的测试步骤和方法,手工地一个一个地输 入执行,包括与被测软件进行交互(如输入测试数据、记录测试结果等),然后观察测试结果,看被测程序是否存在问题,或在执行过程中是否会有一场发生,属于比较原始但是必须执行的一个步骤。
(2)自动化测试:实际上是将大量的重复性的测试工作交给计算机去完成,通常是使用自动化测试工具来模拟手动测试步骤,执行用某种程序设计语言编写的过程(全自动测试就是指在自动测试过程中,不需要人工干预,由程序自动完成测试的全过程;半自动测试就是指在自动测试过程中,需要手动输入测试用例或选择测试路径,再由自动测试程序按照人工指定的要求完成自动测试)
5、从测试实施组织看
(1)开发测试:开发人员进行的测试
(2)用户测试:用户方进行的测试
(3)第三方测试:有别于开发人员或用户进行的测试,由专业的第三方承担的测试,目的是为了保证测试工作的客观性
6、从测试所处的环境看
(1)阿尔法测试:是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试
(2)贝塔测试:是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本,并要求用户报告
扩展资料
软件测试的内容:
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围,建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ,包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人,以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具,得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南,建立测试跟踪过程,建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和报告结果
19 跟踪问题 / 错误,并解决它
20 如果有必要,重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
参考资料:百度百科-软件测试
软件测试的目标和准则是什么?有哪些测试方法?测试步骤有哪些
具体地讲,测试一般要达到下列目标:
1、确保产品完成了它所承诺或公布的功能,并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。
产品缺少明确的书面文档,是厂商一种短期行为的表现,也是一种不负责任的表现。所谓短期行为,是指缺少明确的书面文档既不利于产品最后的顺利交付,容易与用户发生矛盾,影响厂商的声誉和将来与用户的合作关系;同时也不利于产品的后期维护,也使厂商支出超额的用户培训和技术支持费用。从长期利益看,这是很不划算的。领测认为接触过的软件产品,很少有向方正这样大大的产品、薄薄的文档。
当然,书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难,也是最容易被忽略的。
最后,书面文档的不健全甚至不正确,也是测试工作中遇到的最大和最头痛的问题,它的直接后果是测试效率低下、测试目标不明确、测试范围不充分,从而导致最终测试的作用不能充分发挥、测试效果不理想。
2、 确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。
用户最关心的不是你的技术有多先进、功能有多强大,而是他能从这些技术、这些功能中得到多少好处。也就是说,用户关心的是他能从中取出多少,而不是你已经放进去多少。
3、 确保产品是健壮的和适应用户环境的
健壮性即稳定性,是产品质量的基本要求,尤其对于一个用于事务关键或时间关键的工作环境中。
另外就是不能假设用户的环境(某些项目可能除外),如:报业用户许多配置是比较低的,而且是和某些第三方产品同时使用的。
测试的原则---Good Enough
对于相对复杂的产品或系统来说,zero-bug是一种理想,good-enough是我们的原则。
Good-enough原则就是一种权衡投入/产出比的原则:不充分的测试是不负责任的;过分的测试是一种资源的浪费,同样也是一种不负责任的表现。我们的操作困难在于:如何界定什么样的测试是不充分的, 什么样的测试是过分的。目前状况唯一可用的答案是:制定最低测试通过标准和测试内容,然后具体问题具体分析。最明显的例子就是FIT3.0中文报版的产品测试。
测试的规律----木桶原理和80-20原则
1、木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现,测试应该是融于其中的补充检查手段,其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说,测试是提高产品质量的必要条件,也是提高产品质量最直接、最快捷的手段,但决不是一种根本手段。反过来说,如果将提高产品质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难。
2、 Bug的80-20原则。
一般情况下,在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug,而系统测试又能找出其余Bug中的80%,最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误,无法保证能够发现所有的错误。
软件测试的方法:
1、按是否查看程序内部结构分为:
(1)黑盒测试(black-box testing):只关心输入和输出的结果
(2)白盒测试(white-box testing):去研究里面的源代码和程序结构
2、按是否运行程序分为:
(1)静态测试(static testing):是指不实际运行被测软件,而只是静态地检查程序代码、界面或文档可能存在的错误的过程。
静态测试包括:
对于代码测试,主要是测试代码是否符合相应的标准和规范。
对于界面测试,主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试,主要测试用户手册和需求说明是否真正符合用户的实际需求。
(5)动态测试(dynamic testing),是指实际运行被测程序,输入相应的测试数据,检查输出结果和预期结果是否相符的过程
3、按阶段划分:
(1)单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。
桩模块(stud)是指模拟被测模块所调用的模块,驱动模块(driver)是指模拟被测模块的上级模块,驱动模块用来接收测试数据,启动被测模块并输出结果。
(2)集成测试(integration testing),是单元测试的下一阶段,是指将通过测试的单元模块组装成系统或子系统,再进行测试,重点测试不同模块的接口部门。
集成测试就是用来检查各个单元模块结合到一起能否协同配合,正常运行。
(3)系统测试(system testing),指的是将整个软件系统看做一个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试。
系统测试的主要依据是《系统需求规格说明书》文档。
(4)验收测试(acceptance testing),指的是在系统测试的后期,以用户测试为主,或有测试人员等质量保障人员共同参与的测试,它也是软件正式交给用户使用的最后一道工序。
验收测试又分为a测试和beta测试,其中a测试指的是由用户、 测试人员、开发人员等共同参与的内部测试,而beta测试指的是内测后的公测,即完全交给最终用户测试。
4、黑盒测试分为功能测试和性能测试:
1)功能测试(function testing),是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。
包括逻辑功能测试(logic function testing)
界面测试(UI testing)UI=User Interface
易用性测试(usability testing):是指从软件使用的合理性和方便性等角度对软件系统进行检查,来发现软件中不方便用户使用的地方。
兼容性测试(compatibility testing):包括硬件兼容性测试和软件兼容性测试
2)性能测试(performance testing)
软件的性能主要有时间性能和空间性能两种
时间性能:主要指软件的一个具体事务的响应时间(respond time)。
空间性能:主要指软件运行时所消耗的系统资源。
软件性能测试分为:
一般性能测试:指的是让被测系统在正常的软硬件环境下运行,不向其施加任何压力的性能测试。
稳定性测试也叫可靠性测试(reliability testing):是指连续运行被测系统检查系统运行时的稳定程度。
负载测试(load testing):是指让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的稳定性。
压力测试(stress testing):是指持续不断的给被测系统增加压力,直到将被测系统压垮为止,用来测试系统所能承受的最大压力。(Validate the system or software can allowed the biggest stress.)
5、其他测试类型:
回归测试(regression testing)是指对软件的新的版本测试时,重复执行上一个版本测试时的用例。(When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.)
冒烟测试(smoke testing),是指在对一个新版本进行大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。(validate the major function is deployed or not in software of system when a new build or release is implement.)
随机测试(random testing),是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。(means or all the test data is random, to validate the some edge bugs.)
软件测试包括的步骤:
1.制定测试计划;
2.设计测试用例、
3.实施测试(首先要搭建测试用环境)、
4.管理测试时发现的BUG、
5.测试完后(测试完,并且发现的BUG修正完)
6.要做测试报告(这样,该测试过程就算结束了,每种类型(单元测试、集成测试、系统测试、验证测试)的测试都是如此);
需求获取的常用方法有哪些?25.说明软件测试和调试的目的有何区别
需求获取的常用方法有哪些
1)用户访谈
用户访谈是一种最基本的需求获取手段,它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种,结构化是指分析人员按照——定准则事先准备好一系列问题,通过用户对问题的回答来获取有关目标软件方面的内容;非结构化则是只列以一个粗糙的想法,根据访谈的民体情况来进行发挥。
2)用户调查
在进行用户防谈时,由于很多关键人员的时间有限,不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此,就需要借助用户调杏的方法,通过精心设计要问的问题,然后下发到相关的人员手中,让他们填写,再从所填写的内容中获取系统的需求倍息,这样就可以克服上述的问题。
用户调查最大的不足就是缺乏灵活性,而且可能存在受调查人员不能很好表述自己想法的限制。
3)现场观摩
俗话说,百闻石如一见,对于许多较为复杂的流程和系统而言,是很难用自然语言表达清楚的。因此,为了能够对系统的需求获得全面的了解,实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所,一边观察,一边听客户讲解,甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是,在现场观摩过程中必须切记;建造软件系统不仅仅只是为了模拟客户的手下操作过程,还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。
4)文档考古
文档考古是指对历史存在的—些文档进行研究,从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说,就可以应用这种方法。
5)建立联合分析小组
在系统开发时,系统分析员和用户之间由于知识结构的差异,难免存在难逾越的交流鸿沟。
用广提供的需求信息,在系统分析员看来可能是零散和片面甚至无法理解的。因此,为了能够减少交流上的问题,就需要一个领域专家来帮助进行沟通,即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。
6)原型法
原型是在软件开发中被广泛使用的一种工具,在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看,考察某一方面的可行性。如算法的可行性,技术的可行性,或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现,可以让人们能够对一些具体问题进行基于文物的有效沟通,从而帮助人们尽早解决软件开发个存在的各种不确定性。
7)模型驱动
前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统,尤其是对于复杂的系统而言,它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏,可以采用模型驱动的方法。
8)基于上下文的方法
软件系统是作为一个整体存在的,它通过和环境的交互来解决用户的问题,满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境,因此,要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比,它更加注重用户在—定环境下表现出来的行为,通过分析用户的行为得到信息。
说明软件测试和调试的目的有何区别
1、目的不同
软件测试的目的是发现错误,至于找出错误的原因和错误发生的地方不是软件测试的任务,而是调试的任务.调试的目的是为了证明程序的正确,因此它必须不断地排除错误.它们的出发点不一样。前者是挑错,是一种挑剔过程,属于质盘保证活动。后者是排错,是一种排除过程,是编码活动的一部分.
2、任务不同
既然软件测试属于质量保证活动,因此它贯穿于整个开发过程.从需求分析开始,就要制订软件测试计划,软件设计时要设计系统软件测试、集成侧试用例,编码阶段要设计单元软件测试用例并进行单元软件测试,软件测试阶段要进行集成软件测试、系统软件测试等,直到产品交付。只要有修改就有软件测试,产品交付后同样。它是比较有规律的活动,有系统的方法、原则作指导。
而调试是编码活动的一部分,因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关,例如:解释型的开发工具可以交互式调试,编译型开发工具就很难较好地查错。当然它有一些启发式的方法,它是一种比较依赖开发人员经验的活动。
3、指导原则和方法不同
软件侧试是一种有规律的活动,有一系列软件软件测试的原则.其中主要是制订侧试计划,然后严格执行.其次是一种挑剔性行为,因此它不但要侧试软件应该做的,还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则,是一个推理过程。例如使用归纳法、演绎法、回溯法等。
软件测试的输出是预知的,其软件测试用例必须包括预期的结果,而调试的输出大多是不可预见的,需要调试者去解释、去发现产生的原因。
4、操作者
因为心理状态是软件测试程序的障碍,所以执行软件测试的人一般不是开发人员,以使软件测试更客观、更有效,而调试人员一般都是开发人员.
测量距离常用的3种方法是用工具测量,和什么测量和什么测量。
测量距离常用的三种方法是工具测量、步测、目测。
距离测量是指测量地面上两点连线长度的工作。通常需要测定的是水平距离,即两点连线投影在某水准面上的长度。它是确定地面点的平面位置的要素之一。是测量工作中最基本的任务之一。通常需要测定的是水平距离,即两点连线投影在某水准面上的长度。
在三角测量、导线测量、地形测量和工程测量等工作中都需要进行距离测量。距离测量的精度用相对误差(相对精度)表示。即距离测量的误差同该距离长度的比值,用分子为1的公式1/n表示。比值越小,距离测量的精度越高。距离测量常用的方法有量尺量距、视距测量、视差法测距和电磁波测距等
芯片功能的常用测试手段或方法几种?
下面以一种系统芯片的功能测试为例
一、【功能测试平台的构建】
(本设计的功能测试主要采用基于可编程器件建立测试平台。)
“成电之芯”主要有以下几类接口:36位的输入信号总线Input,用来为芯片提供初始输入激励;32位的初始化数据总线Initial_bus,用来为芯片提供DSP核程序、控制寄存器参数、脉压系数和滤波系数;48位的片外缓存数据总线IQ1和IQ2,用于将脉冲压缩的结果传送到片外缓存;28位的求模或取对数输出总线Log_out,用于输出脉冲压缩或滤波运算后的求模或取对数结果;56位的滤波结果输出FIR_I_OUT(28位)、FIR_Q_OUT(28位),用于输出MTI或MTD处理后的结果;16位的HD数据总线,用于输出DSP核处理后的结果。
根据基于可编程器件建立测试平台的设计思想,功能测试平台的构建方法如下:采用可编程逻辑器件进行输入激励的产生和输出响应的处理;采用ROM来实现DSP核程序、控制寄存器参数、脉压系数和滤波系数的存储;采用SRAM作为片外缓存。基本测试框图如图3所示。
根据“成电之芯”的要求,芯片需要外部提供136 k 32bit的存储空间为其提供脉压系数和滤波系数,同时需要其它的一些存储空间为芯片存储片外的DSP核程序和控制寄存器。
由于做MTD滤波时,每个相参处理间隔的数据量最大为2M深度,所以片外必须准备两片深度为2M,数据宽度为48位的SRAM作为芯片的片外缓存。
除此之外,芯片需要外界输入数据和控制信号,并且需要接收芯片的输出数据。这部分的功能可通过可编程逻辑器件来完成。
通过以上分析,CCOMP芯片功能测试平台选用了两片SST39VF3201来做它的片外初始化存储器、6片GS832018来做它的片外缓存、一片XC3S5000来产生它的时序控制信号以及和外部接口的控制逻辑、两片MT48LC4M32用做它的输出缓存、两片SST39VF3201来做它的输入数据存储器,另外还选用了一个AD和一个DA芯片来实现与外界的数据通信。实现框图如图4所示。
二、【测试平台的实现】
1软件的实现
根据“成电之芯”输入激励和输出响应的数据对比要求,编写了可综合的verilog代码。代码的设计完全按照“成电之芯”的时序要求实现。
2 硬件的实现
根据功能测试平台的实现框图进行了原理图和PCB的设计,最后设计完成了一个可对“成电之芯”进行功能测试的系统平台。实物图如图5所示。
软件测试基本理论?
软件测试概念:通过各种手段和测试工具,判断软件系统是否能够满足预期期望。
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.系统测试
E.验收测试
* 测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。
* 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
* 集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
* 系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
单元测试 (Unit Testing)
* 单元测试又称模块测试,是针对软件设计的最小单位 — 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1. 单元测试的内容
* 在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。
(1) 模块接口测试
* 在单元测试的开始,应对通过被测模块的数据流进行测试。测试项目包括:
– 调用本模块的输入参数是否正确;
– 本模块调用子模块时输入给子模块的参数是否正确;
– 全局量的定义在各模块中是否一致;
* 在做内外存交换时要考虑:
– 文件属性是否正确;
– OPEN与CLOSE语句是否正确;
– 缓冲区容量与记录长度是否匹配;
– 在进行读写操作之前是否打开了文件;
– 在结束文件处理时是否关闭了文件;
– 正文书写/输入错误,
– I/O错误是否检查并做了处理。
(2) 局部数据结构测试
* 不正确或不一致的数据类型说明
* 使用尚未赋值或尚未初始化的变量
* 错误的初始值或错误的缺省值
* 变量名拼写错或书写错
* 不一致的数据类型
* 全局数据对模块的影响
(3) 路径测试
* 选择适当的测试用例,对模块中重要的执行路径进行测试。
* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
* 对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
* 出错的描述是否难以理解
* 出错的描述是否能够对错误定位
* 显示的错误与实际的错误是否相符
* 对错误条件的处理正确与否
* 在对错误进行处理之前,错误条件是否已经引起系统的干预等
(5) 边界测试
* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。
* 如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。
2. 单元测试的步骤
* 模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。
– 驱动模块 (driver)
– 桩模块 (stub) —— 存根模块
* 如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。
* 对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。
集成测试(Integrated Testing)
* 集成测试 (集成测试、联合测试)
* 通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是:
– 在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
– 一个模块的功能是否会对另一个模块的功能产生不利的影响;
– 各个子功能组合起来,能否达到预期要求的父功能;
– 全局数据结构是否有问题;
– 单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。
在单元测试的同时可进行集成测试,
发现并排除在模块连接中可能出现
的问题,最终构成要求的软件系统。
* 子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
* 通常,把模块集成成为系统的方式有两种
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一种非增殖式组装方式。也叫做整体拼装。
* 使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。
2. 增殖式集成方式
* 这种集成方式又称渐增式集成
* 首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统
* 在集成的过程中边连接边测试,以发现连接过程中产生的问题
* 通过增殖逐步组装成为要求的软件系统。
(1) 自顶向下的增殖方式
* 这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。
* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
* 选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。
(2) 自底向上的增殖方式
* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
* 因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
* 一般来讲,一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
* 衍变的自顶向下的增殖测试
– 首先对输入/输出模块和引入新算法模块进行测试;
– 再自底向上组装成为功能相当完整且相对独立的子系统;
– 然后由主模块开始自顶向下进行增殖测试。
* 自底向上-自顶向下的增殖测试
– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
– 然后对含写操作的子系统做自顶向下的组装与测试。
* 回归测试
– 这种方式采取自顶向下的方式测试被修改的模块及其子模块;
– 然后将这一部分视为子系统,再自底向上测试。
关键模块问题
* 在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。
* 关键模块的特征:
① 满足某些软件需求;
② 在程序的模块结构中位于较高的层次(高层控制模块);
③ 较复杂、较易发生错误;
④ 有明确定义的性能要求。
确认测试(Validation Testing)
* 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
1. 进行有效性测试(黑盒测试)
* 有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。
* 首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。
* 通过实施预定的测试计划和测试步骤,确定
– 软件的特性是否与需求相符;
– 所有的文档都是正确且便于使用;
– 同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试
* 在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类:
– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。
– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
2. 软件配置复查
n 软件配置复查的目的是保证
u 软件配置的所有成分都齐全;
u 各方面的质量都符合要求;
u 具有维护阶段所必需的细节;
u 而且已经编排好分类的目录。
n 应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。
验收测试(Acceptance Testing)
* 在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。
* 验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。
* 由用户参加设计测试用例,使用生产中的实际数据进行测试。
* 在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
* 确认测试应交付的文档有:
– 确认测试分析报告
– 最终的用户手册和操作手册
– 项目开发总结报告。
系统测试(System Testing)
* 系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
* 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
软件测试的方法有哪些?
静态分析(规则检查,数据流分析,代码审查等)、单元测试、功能测试、压力测试、信息安全测试、开发/测试环境管理等。 parasoft这方面比较牛,你可以了解一下
软件测试方法?都有哪几种?
第一类测试方法是试图验证软件是“工作的”,所谓“工作的”就是指软件的功能是按照预先的设计执行的;而第二类测试方法则是设法证明软件是“不工作的”。
还有两大类:白盒法和黑盒法。
白盒法:你清楚程序的流程时,用不同的数据测试你程序的代码,验证程序的正确性,有:条件测试,路径测试,条件组合。。。。
白盒法用在程序开发阶段的前期。
黑盒法:主要用于程序开发阶段的后期,即程序的流程测试正确后,测试程序的结果。有什么因果法,边缘值法等。
具体你可以买本软件工程方面的书看看。
还有一下方法:
功能测试:可接受性测试:用户界面测试:探索或开放’型的测试:性能测试:回归测试:强力测试:集成与兼容性测试:装配/安装/配置测试:国际化支持测试:本地化语言测试:
这些都是测试的方法.
转载请注明出处51数据库 » 软件测试的常用手段 软件测试的方法一共有几种