软件测试整理.docx
- 文档编号:4389644
- 上传时间:2023-05-07
- 格式:DOCX
- 页数:15
- 大小:173.98KB
软件测试整理.docx
《软件测试整理.docx》由会员分享,可在线阅读,更多相关《软件测试整理.docx(15页珍藏版)》请在冰点文库上搜索。
软件测试整理
软件测试整理
软件测试:
软件质量保证的关键元素,代表了规约、设计和编码的最终检查。
SQA:
质量保证是一个活动,它向所有有关的人提供证据以确立质量功能正在按需求运行的信心。
并提供开发出满足使用要求产品的软件过程的能力证据.
BUG:
软件使用过程中所出现的任何一个可疑问题或者导致软件不能符合设计要求或满足消费者需要的问题。
错误:
也即是软件bug或缺陷Defect
黑盒测试:
指的是把被测得软件看作是一个黑盒子,我们不去关心盒子里面的结构是什么样子的,只关心软件的输入数据和输出结果。
白盒测试:
又叫做玻璃盒测试(GlassBoxTesting)。
在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫作白盒测试。
功能测试:
按照软件的功能或特性逐个进行测试。
性能测试:
用来测试软件在系统中的运行性能,性能测试可以发生在测试过程的所有步骤中。
压力测试:
在各种极限情况下对产品进行测试(如很多人同时使用该软件,或者反复运行该软件),以检查产品的长期稳定性。
2、测试的目的:
a、从用户的角度出发,希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可接受该产品。
b、从软件开发者的角度出发,验证该软件已正确地实现了用户的要求并且证明软件的功能和性能与需求。
c、为了能够给开发人员或程序经理提供反馈信息,并为风险评估准备所需要信息。
d、保证整个软件开发过程是高质量的。
测试的原则:
尽早和不断的测试。
测试前要认定被测试软件有错。
预先确定被测试软件的测试结果。
测试工作应该由独立的专业的软件测试机构来完成。
测试要以软件需求规格说明书为标准。
测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
对测试错误结果一定要有一个确认的过程。
制定严格的测试计划,排除测试的随意性。
回归测试的关联性--修改一个错误而引起更多的错误出现的现象并不少见。
完全测试程序是不可能的。
并非所有软件缺陷都能修复应当对每一个测试结果做全面检查。
测试对象:
需求规格说明、概要设计规格说明、详细设计规格说明、源程序。
3、什么是V模型?
简述V模型在软件测试过程中的作用,以及在V模型中各个测试阶段和开发过程的对应关系:
参见下图:
V模型中的过程从左到右,描述了基本的开发过程和测试行为;明确标明了测试过程中存在的不同级别;体现了测试阶段和开发过程期间各阶段的对应关系
4、软件测试的分类:
从代码的特性角度出发分覆盖性测试;从用户的使用角度出发使用测试;按是否查看源代码的角度分白盒测试和黑盒测试;按是否使用工具分为手工测试和自动测试;按代码是否执行分为静态测试和动态测试;按测试阶段分为单元测试,集成测试,系统测试和验收测试。
5、比较传统软件测试过程与Rational软件测试过程的异同点:
传统的软件测试流程一般是先在软件开发过程中进行少量的单元测试,然后在整个软件开发结束阶段,集中进行大量的测试,包括功能和性能的集成测试和系统测试。
随着开发的软件项目越来越复杂。
而Rational软件测试过程则强调尽早测试、连续测试、自动化测试
6、软件测试分为如下几个阶段:
需求分析、测试计划、测试设计、测试环境搭建、测试执行、测试记录、缺陷管理、软件评估、测试维护。
7、软件运行时产生的错误就是BUG?
答:
不对,bug是软件缺陷,在软件运行过程中产生的错误有可能是其他原因引起的,不一定是bug。
8、如何判断一个问题是否是BUG?
答:
确定范围,确定确实是这个问题,确定描述问题时的准确性
9、解释为什么测试只能检测错误的存在而不能检测它的不存在:
当我们开发测试用例进行测试时如果出现错误我们可以判断相应错误存在,但如果运行通过并不能说错误不存在,因为这并不表示其他的用例不会产生错误。
由于测试的不完备性,我们不能验证错误的不存在
10、自动化测试:
主要是指利用软件测试工具提供完整的软件测试流程的支持和各种测试的自动化实现。
11、为什么不能彻底测试一个软件?
为什么在不同发现错误的阶段,费用有很大的不同:
一个软件的所有输入可能非常大,在有限的时间里不可能对所有的情况进行枚举测试。
在不同的阶段发现缺陷,修复费用是不同的。
越晚发现修复费用越高。
这是由于在后期发现缺陷要修改软件的相关联模块越多甚至软件的体系结构要重新设计,这将导致费用急剧增加。
12、影响软件测试的效率有哪些:
影响测试效率的因素很多,除了测试方法之外,主要因素还有人为因素、软件类型、错误类型、测试充分度等等。
第二章
1、测试计划:
测试计划应该作为测试的起始步骤和重要环节。
大致包括:
产品基本情况调研,测试需求说明,测试策略和记录,测试资源配置,计划表,问题跟踪报告,测试计划的评审,结果等。
测试计划概要说明测试组的任务和职责,测试目标、测试设计活动、测试环境准备、测试风险和偶发事件以及可接受的彻底测试的程序。
测试环境:
硬件、软件、网络和设施的需求等。
测试环境计划应确定访问和使用测试环境的各种人员及其数量,以保证计划足够数量的计算机适应这种要求。
测试风险:
测试中可能出现问题的风险
测试流程:
测试计划、测试设计、测试实施、测试执行、测试评估。
2、测试计划阶段包括哪些活动:
所有的出错可能性、性能(Performance)问题、软件的兼容性(Compatibility)等
3、测试计划的用途有哪些?
一个好的测试计划应该起到哪些作用:
1)提高测试工作的效率以及准确性,让测试工作有条理,有计划的进行,避免测试的“事件驱动”。
2)使测试工作与整个开发活动更好的融合。
3)规避风险,使资源和变更事先作为一个可控制的风险。
4、目前测试过程中都使用哪些测试策略,如何在测试中应用它们:
测试策略是关于如何测试系统的正式描述,要求开发针对所有测试级别的测试策略。
测试小组分析需求,编写测试策略并且和项目小组一起复审计划。
测试计划应该包括测试用例和条件,测试环境,与任务相关的测试,通过对失败的准则和测试风险评估。
测试进度表将识别出所有要求成功的测试成果,活动的进度和资源要求。
5、对Windows操作系统附件中的计算器程序进行测试,请参照测试计划模版,制订其完整的测试计划:
参照书中所给的测试实例编写完整的测试计划
6、按照软件需求分析与设计的方法,对Windows操作系统附件中的计算器程序进行测试需求分析与设计:
参照书中所给的测试实例编写完整的测试需求分析与设计。
7、执行第6题中设计的测试用例,完成测试报告,并对测试结果进行分析与评估:
提示:
参照书中所给的测试实例完成测试报告
8、怎样制定软件测试计划:
作为测试人员,在制定测试计划之前,应该很好的掌握测试需求,这是软件测试的第一步。
而测试需求有耐于开发人员提供完整的需求文档和接口文档。
根据需求文档中描述的每个功能项目的输入,处理过程和输出,来设计测试用例。
除此之外,软件测试人员还要很好的与软件开发人员,项目经理进行沟通和交流,了解软件实现的主要功能是什么,并记录收集到的信息。
与技术支持人员交流,他们是最贴近用户的人,通过交流可以获取第一手的用户使用感觉,在制定测试计划时会更加贴近用户。
测试过程中,还要考虑到测试用例的优先级。
一般情况下,测试人员要优先测试级别高的需求项,按照级别的先后顺序进行测试,这样一来,如果进度不允许,就放弃测试级别低的需求项。
9、确定测试范围的步骤:
•测试组审查系统需求或使用的用例。
•测试组可以审查设计文档系统。
•测试工程师评审任务说明,确定关键系统功能和高风险系统功能。
•测试工程师必须对系统有一个清晰的定义并理解系统需求或使用的用例,这样才能够确定测试目标、测试目的和测试策略。
•需要确定用于项目的自动测试工具。
•将测试参数形成文档,其中包括确定测试目标、测试目的和测试策略时所做的所有假设。
还需将先决事件、文档及支持各种测试活动的产品罗列出来。
•确定系统验收准则,估计测试风险,制订降低风险的计划。
10、如果要测试一个电子商务网站,如何搭建测试环境提示:
从硬件环境、软件环境、网络等方面考虑搭建测试环境。
11、10题中如何确定测试风险以及怎样管理该测试风险:
提示:
从软件测试的七类风险考虑枚举可能的风险
12、TestManager的工作流程有哪些:
TestManager工作流程支持了RUP定义的5个主要的测试活动,它们是一个软件工程过程:
测试计划、测试设计、测试实施、测试执行、测试评估
13、什么是一个Rational项目:
通过RationalAdministrator创建的项目,管理测试用户、用户组等信息。
该测试项目可直接连接其他相关软件。
有RationalTestManager管理测试等,RationalRobot功能性能测试,RationalClearQuest缺陷管理,RFT功能测试,RPT性能测试,等等。
14、RationalAdministrator的功能有哪些:
RationalAdministrator创建和管理项目,配置项目信息。
如指定资产信息、配置对应需求、配置对应模型、配性缺陷管理数据库等。
15、为什么要向项目中添加用户和组:
这是因为对于一个软件测试项目有不同的测试人
员,他们有不同的权限,通过添加管理用户组、用户来规范管理不同人员的权限。
16、一个不属于任何组的用户被授予什么样的权限:
授予普通public权限。
第三章
1、测试需求:
测试需求通俗的讲,就是定义对产品项目所要测试的内容
测试用例:
是关于具体测试步骤的文档,它描述了测试的输入参数、条件、配置以及预期的输出结果等
单元测试:
单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。
通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
集成测试:
集成测试,也叫组装测试或联合测试。
在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。
系统测试:
是将经过测试的子系统装配成一个完整系统来测试。
它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
验收测试:
是部署软件之前的最后一个测试操作。
验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
回归测试:
为了验证修改的正确性及其影响
冒烟测试:
描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。
2、怎么确定测试需求:
测试阶段需求分析更注重于技术层面,即软件是否实现了需求所示的功能;针对待测软件的特性差异,除了需要确保要求实现的基本功能正确之外,各种业务软件还需要达到各自的一些非功能性标准;明确测试焦点,对所测的功能进行分析、分解,进行着重于某一方面的测试;明确测试的优先级;测试的覆盖率和覆盖程度。
3、怎么设计测试用例?
如何评估测试用例的好坏:
好的测试用例的特点:
完整、准确、简洁、清晰、可维护性、适当性、可复用性
4、分别解释什么是白盒测试、黑盒测试,以及他们之间的关系:
白盒测试:
又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。
黑盒测试:
也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
5、什么是驱动模块和桩模块?
为下面的函数构造一个驱动模块、并至少设计3条测试用例。
桩模块:
为被测模块编制一些模拟其下级模块功能的“替身”模块,以代替被测模块的接口,接受或传递被测模块的数据,这些专供测试用的“假”模块称为被测模块的桩模块。
驱动模块在大多数场合称为“主程序”,它接收测试数据并将这些数据传递到被测试模块。
intmain()
{
inta,b,c;
cin>>a>>b;
c=divide(a,b);
cout< } 测试用例a,b分别取: 1,0;1,2;4,2等用例均可 6、什么是覆盖评测? 覆盖评测的类型有哪些: 覆盖评测是动态分析方法,通过程序执行过程中覆盖的比例来分析软件。 常用六种覆盖方法: 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖、路径覆盖。 7、基于需求的测试覆盖如何计算: 测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。 如果一个测试需求已经跟软件需求存在着一对一或一对多的对应关系,可以说测试需求已经覆盖了该功能点. 8、基于代码的测试覆盖如何计算: 执行代码占总代码比例。 9、主要的性能评测有哪些? 分别详细予以说明: 性能测试是为描述测试对象与性能相关的特征并对其进行评价,而实施和执行的一类测试。 基准测试: -比较新的或未知测试对象与已知参照标准(如现有软件或评测标准)的性能。 争用测试: -核实测试对象对于多个主角对相同资源(数据记录、内存等)的请求的处理是否可以接受。 性能配置: -核实在操作条件保持不变的情况下,测试对象在使用不同配置时其性能行为的可接受性。 负载测试: -核实在保持配置不变的情况下,测试对象在不同操作条件(如不同用户数、事务数等)下性能行为的可接受性。 强度测试: -核实测试对象性能行为在异常或极端条件(如资源减少或用户数过多)之下的可接受性。 10、单元测试、集成测试、系统测试、验收测试之间有什么联系: 结合概念、内容、方法、过程、目的比较这四者之间的关系与联系。 11、什么是冒烟测试,为什么要进行冒烟测试: 在软件中,“冒烟测试”这一术语描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。 在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法。 冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。 12、市场常用的测试软件有哪些? 他们各有什么特点? IBM测试工具: RationalTestManager,Robot,ClearQuest,PurifyPlus,RFT,RPT等;MI公司: loadRunner,QTP,winRunner 13、写出下列输入中需要测试的边界值: (1)、一个文件最多允许输入255个字符。 (2)、一个文本框允许输入0至100之间的实数 (3)、在软盘中保存文件。 (1)255、256, (2)100、101、0、-1, 19、简述Junit进行单元测试的原则与特征: 编写原则: A、是简化测试的编写,这种简化包括测试框架的学习和实际测试单元的编写。 B、是使测试单元保持持久性。 C、是可以利用既有的测试来编写相关的测试。 特征: A、使用断言方法判断期望值和实际值差异,返回Boolean值。 B、测试驱动设备使用共同的初始化变量或者实例。 C、测试包结构便于组织和集成运行。 D、支持图型交互模式和文本交互模式。 第四章 1、什么是测试的实施,测试实施包括哪些方面? 以及如何实施测试: 实施测试用例是通过创建一个测试脚本并建立测试脚本与测试用例的关联来实现。 包括测试开发、测试环境搭建。 通过创建测试脚本、用例、套件来实施测试。 2、测试脚本、测试用例以及测试套件之间有什么关系联系? 详细阐述如何实施这些测试: 测试脚本是最基本的,包括自动脚本、手工脚本;测试用例可有多个脚本组成;而测试套件既可以包括测试用例也可以包括测试脚本。 这些测试的实施方法参见书本。 8、比较RationalRobot与RationalFunctionalTester、RationalPerformanceTester的异同点以及各自优缺点: 提示: Robot主要用于功能测试、性能测试;RFT用于功能测试;RPT用于web性能测试。 从这些角度分别比较各自优缺点。 9、需求测试主要可以测试哪些种类的错误: 测试需求对应于软件需求,1) 与待测软件相关的各种文档资料。 如软件需求规格、用例、界面设计、项目会议以及与客户沟通时所做的需求记录、或其他的相关的技术文档等。 2) 与客户或软件开发人员的沟通。 3) 产品的背景资料。 如待测软件业务领域的知识等。 4) 其他。 如果以旧系统为原型,以全新的架构方式来设计或完善软件,那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。 10、设计测试的意义是什么: 设计测试是为了更好的完成测试,使测试有条理的进行。 明确测什么? 怎么测? 谁来测? 多少人? 等策略。 11、测试安全漏洞故障与测试软件缺陷是否有什么不同: 不同,一般测试软件缺陷故障包括安全漏洞故障。 安全漏洞是在用户输入时不按照正确的输入,利用系统不能对这些输入进行处理或安全处理,引起安全漏洞实现攻击。 有时这些安全漏洞在正常输入时并不会产生缺陷或者错误。 而软件缺陷故障通常是系统在运行是产生错误。 这两者是有明显区别的。 但缺陷故障也可以包括测试安全漏洞故障。 第五章 1.简述软件测试执行过程: 2.简述软件测试缺陷跟踪过程: 3、如何执行软件测试,包括手工测试脚本、自动测试脚本、用例、套件的执行: 执行测试的目的是确保整个系统按既定意图运行。 系统集成员在各迭代中编译并链接系统。 每个迭代都需要测试增加的功能,并重复执行以前版本测试过的所有测试用例(回归测试)。 测试的执行活动包含了测试实施的执行,以确保系统功能的正确性。 提示: 脚本、用例、套件的执行过程必须亲自试验完成要求。 5、评估测试的好坏: 测试的主要度量方法包括覆盖度量和质量度量。 测试覆盖用于评价测试的完备性,是通过测试需求覆盖和测试用例的覆盖或已执行代码的覆盖表示的。 质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的度量。 质量建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析基础之上。 6、某程序读入三个整数值,这三个整数值表示三角形的三条边长。 该程序打印信息标明三角形是不等边三角形、等腰三角形或等边三角形。 开发一个测试用例集测试该程序: 设计测试用例集需覆盖所有路径,即用例集中有满足不等边三角形、等腰三角形、等边三角形、非三角形。 如: a: 1、2、3;b: 2、3、4;c: 3、3、4;d: 3、3、3. 7、设计和实现第六题描述的问题(带有适当的错误处理)。 从程序中导出流图,并用基本路径测试方法开发保证测试所有程序语句的测试用例。 执行测试用例并显示结果: voidjudgeTri { inta,b,c; cin>>a>>b>>c; if(! (a+b>c&&a+c>b&&b+c>a)) cout<<“a,b,c不能构成三角形”; else { if(a==b==c) cout<<“等边三角形”; elseif(a==b||a==c||b==c) cout<<“等腰三角形”; else cout<<“不等边三角形”;}} 执行上题中给出的测试用例,分析路径覆盖。 流图如下 9、测试脚本、测试用例、测试套件的执行有什么区别联系: 按照书中TestManager教程认真设计执行测试脚本、测试用例、测试套件比较他们之间的区别联系。 测试脚本是最基本的,包括自动脚本、手工脚本;测试用例可有多个脚本组成;而测试套件既可以包括测试用例也可以包括测试脚本。 10、为什么不能测试一个软件? 即便可能是非常小的程序穷尽测试是否能够保证程序100%正确: 软件测试只能测试错误缺陷的存在,不能测试错误缺陷的不存在。 即使是很小的软件也不能。 这也是由于测试的不完备性确定的。 第六章 1、简述软件测试评估的具体内容: 测试评估活动的目的是统计和分析测试结果,确定是否达到软件发布的标准。 具体内容包括以下几方面: 确定实际测试执行的有效性。 测试执行是否完全? 执行失败是否因为不符合前置条件? 分析测试输出以确定结果。 在执行测试过程中,查看测试结果报告中的数据来检验该执行是否是可接受的查看统计后的结果以检查对测试计划、测试输入、配置等的覆盖程度。 2、简述软件测试评估的方法并简述几种评测方法原则内容以及如何实施: 测试的主要度量方法包括覆盖度量和质量度量。 测试覆盖用于评价测试的完备性,是通过测试需求 覆盖和测试用例的覆盖或已执行代码的覆盖表示的。 质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的度量。 质量建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析基础之上。 3、测试用例、测试输入、软件缺陷之间的关系是什么 6、缺陷的来源与影响: 缺陷主要来源于需求阶段、设计阶段、编码阶段。 越在前期产生的缺陷维护费用越高。 7、缺陷的种类有哪些? 并通过对实际案例的测试,分析缺陷都是软件开发生命周期的哪个阶段产生的: 缺陷的分类方法很多。 以下是常用分类方法: putnam: 需求缺陷、设计缺陷、文档缺陷、算法缺陷、界面缺陷、性能缺陷。 thayer: 以软件过程反馈的问题报告作为错误分类法,有计算错误、逻辑错误、I/O错误、数据加工错误等。 缺陷正交分类: 赋值、检验、算法、时序、接口、功能、关联。 8、缺陷管理报告单包括哪些内容、具有什么特点: 缺陷名字、ID、状态、来源、类别、所属项目、优先级、严重程度、发现者、关键字、描述、症状等。 在试验中必须认真填写每种缺陷。 5、简述缺陷的管理流程: 10、发现缺陷的方法有哪些: 通过各个阶段各种测试方法来发现缺陷。 在整个软件开发生命周期中对于不同阶段的不同测试来寻找缺陷。 如单元测试、集成测试、系统测试、验收测试。 以及其他针对性测试如功能测试、性能测试、随机测试、冒烟测试等。 11、缺陷的分类有何意义? 如何预防缺陷: 缺陷分类有利于缺陷管理和修复,避免重复也可更好的预防缺陷。 预防缺陷应贯穿于整个软件开发生命周期。 12、列举至少三种安全漏洞故障: 安全漏洞在软件开发过程中经常产生。 如: 缓冲区溢出、SQL注入、跨站脚本攻击、DOS、会话攻击等。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 整理