软件测试.docx
- 文档编号:29235145
- 上传时间:2023-07-21
- 格式:DOCX
- 页数:14
- 大小:26.25KB
软件测试.docx
《软件测试.docx》由会员分享,可在线阅读,更多相关《软件测试.docx(14页珍藏版)》请在冰豆网上搜索。
软件测试
Ss 常见的测试用例设计方法都有哪些?
请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1.等价类划分
常见的软件测试面试题划分等价类:
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
2.边界值分析法
边界值分析方法是对等价类划分方法的补充。
测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3.错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.
错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结。
还有,输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况。
可选择这些情况下的例子作为测试用例.
4.因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图(逻辑模型).因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.
5.正交表分析法
有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
6.场景分析方法
指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。
您认为做好测试用例设计工作的关键是什么?
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
详细的描述一个测试活动完整的过程。
1.项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:
需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。
项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。
然后sqa进入项目,开始进行统计和跟踪
2.开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。
测试人员完成测试计划文档,测试计划包括的内容上面有描述。
3.测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。
此两份文档成为测试人员撰写测试用例的补充材料。
4.测试用例完成后,测试和开发需要进行评审。
5.测试人员搭建环境
6.开发人员提交第一个版本,可能存在未完成功能,需要说明。
测试人员进行测试,发现bug后提交给bugzilla。
7.开发提交第二个版本,包括bugfix以及增加了部分功能,测试人员进行测试。
8.重复上面的工作,一般是3-4个版本后bug数量减少,达到出货的要求。
9.如果有客户反馈的问题,需要测试人员协助重现以及回归测试。
以往是否曾经从事过性能测试工作?
请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试,主要测试该软件在同时管理大量终端的情况下,在响应时间,cpu/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试,主要是测试软交换系统在有大量呼叫的情况下,响应时间,呼叫成功率,cpu/磁盘/内存等参数是否满足设计要求。
您在从事性能测试工作时,是否使用过一些测试工具?
如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中,使用的mimic来模拟终端,能够大量的节省成本。
测试软交换系统的时候,使用的prolab来模拟终端并发送呼叫软交换,他完成了同时数百人才能完成的摘机拨号工作,主要工作原理是产生一些符合要求的ip包并发送给软交换系统,同时对软交换系统的回应进行处理,决定下一步动作。
您认为性能测试工作的目的是什么?
做好性能测试工作的关键是什么?
主要是保障在大量用户的情况下,服务能正常使用。
在您以往的工作中,一条软件缺陷(或者叫bug)记录都包含了哪些内容?
如何提交高质量的软件缺陷(bug)记录?
1.在传统的bugzilla中,bug描述应该包括以下的信息
2.和bug产生对应的软件版本
3.开发的接口人员
4.bug的优先级
5.bug的严重程度
6.bug可能属于的模块,如果不能确认,可以用开发人员来判断
7.bug标题,需要清晰的描述现象
8.bug描述,需要尽量给出重新bug的步骤
9.bug附件中能给出相关的日志和截图。
高质量的bug记录就是指很容易理解的bug记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。
主流软件测试工具介绍
测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具,另外还有用于测试管理(测试流程管理、缺陷跟踪管理、测试用例管理)的工具,这些产品主要是MercuryInteractive(MI)、Segue、IBMRational、Compuware和Empirix等公司的产品,而MI公司的产品占了主流。
白盒测试工具
白盒测试工具一般是针对代码进行测试,测试中发现的缺陷可以定位到代码级,根据测试工具原理的不同,又可以分为静态测试工具和动态测试工具。
静态测试工具:
直接对代码进行分析,不需要运行代码,也不需要对代码编译链接,生成可执行文件。
静态测试工具一般是对代码进行语法扫描,找出不符合编码规范的地方,根据某种质量模型评价代码的质量,生成系统的调用关系图等。
静态测试工具的代表有:
Telelogic公司的Logiscope软件;PR公司的PRQA软件。
动态测试工具:
动态测试工具与静态测试工具不同,动态测试工具的一般采用"插桩"的方式,向代码生成的可执行文件中插入一些监测代码,用来统计程序运行时的数据。
其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。
动态测试工具的代表有:
Compuware公司的DevPartner软件;Rational公司的Purify系列等。
黑盒测试工具
黑盒测试工具适用于黑盒测试的场合,黑盒测试工具包括功能测试工具和性能测试工具。
黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback),模拟用户的操作,然后将被测系统的输出记录下来同预先给定的标准结果比较。
黑盒测试工具可以大大减轻黑盒测试的工作量,在迭代开发的过程中,能够很好地进行回归测试。
黑盒测试工具的代表有:
Rational公司的TeamTest、Robot;Compuware公司的QACenter。
性能测试工具
专用于性能测试的工具包括有:
Radview公司的WebLoad;Microsoft公司的 WebStress等工具;针对数据库测试的TestBytes;对应用性能进行优化的EcoScope等工具。
MercuryInteractive的LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。
LoadRunner的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。
测试管理工具
测试管理工具用于对测试进行管理。
一般而言,测试管理工具对测试计划、测试用例、测试实施进行管理,并且,测试管理工具还包括对缺陷的跟踪管理。
测试管理工具的代表有:
Rational公司的TestManager;Compureware公司的TrackRecord;MercuryInteractive公司的TestDirector等软件。
软件测试工具就是通过一些工具能够使软件的一些简单问题直观的显示在读者的面前,这样能使测试人员更好的找出软件错误的所在。
软件测试工具也分为自动化软件测试工具和测试管理工具。
软件测试工具存在的价值是为了提高测试效率,用软件来代替一些人工输入。
测试管理工具是为了复用测试用例,提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。
目前国际上主要分为三类软件测试工具:
Mercury测试工具Rational测试工具Segue测试工具占有市场90%以上
常用的软件测试工具分为:
[开源测试工具]:
开源测试管理工具:
Bugfree、Bugzilla、TestLink、mantis
开源功能自动化测试工具:
Watir、Selenium、MaxQ、WebInject
开源性能自动化测试工具:
Jmeter、OpenSTA、DBMonster、TPTEST、WebApplicationLoadSimulator
[TestDirector]:
企业级测试管理工具,也是业界第一个基于Web的测试管理系统。
[QualityCenter]:
基于Web的测试管理工具,可以组织和管理应用程序测试流程的所有阶段,包括指定测试需求、计划测试、执行测试和跟踪缺陷。
[QuickTestProfessional]:
用于创建功能和回归测试。
[LoadRunner]:
预测系统行为和性能的负载测试工具。
[其他工具与自动化测试框架]:
RationalFunctionalTester、BorlandSilk系列工具、WinRunner、Robot等。
国内介绍软件测试工具比较好的网站为:
51Testing软件测试论坛
国内免费软件测试工具有:
AutoRunner和TestCenter。
软件开发和使用的历史给我们留下了许多由于软件缺陷而导致的巨大财力、物力损失的经验教训。
作为测试工程师,我们必须采取强有力的检测措施来检测未发现的隐藏的缺陷。
生产软件的最终目的是为了满足客户需求,软件测试以客户需求作为评判软件质量的标准,认为软件缺陷的具体含义包括下面几个因素:
1、 软件未达到客户需求的功能和性能;
2、 软件超出客户需求的范围;
3、 软件出现客户需求不能容忍的错误;
4、 软件的使用未能符合客户的习惯和工作环境。
考虑到设计等方面的因素,软件缺陷还应包括软件设计不符合规范,未能在特定的条件(资金、范围等)达到最佳等。
值得注意的是,软件缺陷不单单是运行时出现的问题,软件测试并不仅限于是程序提交之后。
目前国内几乎看不到完整准确的客户需求说明书,加之客户的需求时时在变,完美的测试是不可能存在的。
作为一个优异的测试人员,追求软件质量的完美固然是我们的宗旨,但是明确软件测试现实与理想的差距,在软件测试中学会取舍和让步,对软件测试是有百益而无一弊的。
以下是一些软件测试的常识,对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。
1、 测试不是完全的
由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,即便是一个极其简单的程序,想要穷尽所有逻辑路径,所有输入数据和验证所有结果都是非常困难的一件事情。
例如,求两个整数的最大公约数,其输入信息为两个整数。
如果我们将整个整数域的数字进行一番测试的话,从其数目的无限性我们便可证明这样的测试在实际生活中是行不通的。
为此作为软件测试,我们一般采用等价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为了精简测试复杂性的一条必经之道。
2、 测试具有免疫性(软件缺陷免疫性)
软件缺陷和病毒一样具有可怕的“免疫性”,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺陷就更加困难。
根据数学上的概率论可推出这一结论。
假设一个50000行的程序中有500个软件缺陷并且这些缺陷是均匀分布的,则每100行可以找到一个软件缺陷。
假设测试人员用某种方法花在查找软件缺陷的精力为X小时/100行。
照此推算,软件存在500个缺陷时,查找一个软件缺陷需要X小时,当软件只存在5个错误时,每查找一个软件缺陷需要100X小时。
实践证明,实际的测试过程比上面的假设更为苛刻,为此测试人员必须更换不同的测试方式和测试数据。
该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能多的采用多种途径进行测试。
3、 测试是“泛型概念”(全程测试)
软件测试并不仅存于是程序完成之后。
需求缺陷、设计缺陷也是软件缺陷,而“软件缺陷具有生育能力”,如果单纯地将程序设计阶段后的测试工作称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大,这非常不利于保证软件质量。
4、 80-20原则
80%的软件缺陷常常存在软件20%的空间里。
如果想使软件测试更有效率,我们应该常常留意其高危多发“地段”。
因此这一原则对软件测试人员提高测试效率和缺陷发现有着重大意义。
根据这个原则,测试人员可以避免漫无目的地到处搜寻,很快找出较多的缺陷。
80-20原则还有另一种情况:
在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免80%的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的80%,最后的4%的软件缺陷可能只有在系统交付使用后经过大范围、长时间使用后才会暴露出来。
因为软件测试只能保证尽可能多地发现软件缺陷,无法保证能够发现所有的软件缺陷。
80-20原则还能反映到软件测试的自动化方面,实践证明80%的软件缺陷可以借助人工测试而发现,20%的软件缺陷可以借助自动化测试来发现。
由于二者间具有部分交叉,因此尚有5%左右的软件缺陷需要通过其他方式进行发现和修正。
5、 为了效益而测试
我们为什么要实施软件测试?
实施软件测试是为了提高项目的质量,最终得以提高项目的总体效益。
为此不难得出在实施软件测试的过程中,我们应该掌握的度。
片面地追求都必然会损害软件测试存在的价值和意义。
一般来说,在软件测试中应该尽量地保持软件测试的简单性,切勿将软件测试过度复杂化,keepitsimplebutnottoosimple。
6、 缺陷的必然性
软件测试过程中,错误是有关联性的,并不是所有的软件缺陷都能够得以修复。
某些软件缺陷虽然能够修复但在修复的过程中难免会引入新的软件缺陷。
很多软件缺陷之间是相互矛盾的,一个矛盾消失必然会引发另一个矛盾的产生。
比如,在解决通用性的缺陷后往往会带来执行效率上的缺陷。
再者,在缺陷修复过程中,由于时间、成本等方面的限制,我们无法有效、完整地修复所有的软件缺陷。
因此评估软件缺陷的重要度、影响范围,选择一个折中的方案或是从非软件因素考虑软件缺陷成为了我们在面对软件缺陷时一个必须直面的事实。
7、 软件测试必须有预期结果
没有预期结果的测试是不可理喻的。
软件缺陷是经过对比而得出来的。
正如没有标准无法进行度量一样。
如果我们事先不知道或是无法肯定预期的结果,必然无法了解测试正确性。
犹如盲人摸象,凭借测试人员自身的感觉去评判软件缺陷的发生,其结果往往是把似是而非的东西作为正确的结果来判断,因此常常出现误测的现象。
8、 软件测试的意义
软件测试的目的并不单单是为了发现缺陷这么简单。
古语说得好,“不知道历史的人必然会重蹈覆辙”,没有对软件测试结果进行认真的分析,我们就无法了解缺陷发生的原因和应对措施,不得不耗费大量的人力和物力来再次查找软件缺陷。
1.软件测试的目的是尽可能多的找出软件的缺陷。
(Y)
2.Beta测试是验收测试的一种。
(Y)
3.验收测试是由最终用户来实施的。
(N)
4.项目立项前测试人员不需要提交任何工件。
(Y)
5.单元测试能发现约80%的软件缺陷。
(Y)
6.代码评审是检查源代码是否达到模块设计的要求。
(N)
7.自底向上集成需要测试员编写驱动程序。
(Y)
8.负载测试是验证要检验的系统的能力最高能达到什么程度。
(N)
9.测试人员要坚持原则,缺陷未修复完坚决不予通过。
(N)
10.代码评审员一般由测试员担任。
(N)
11.我们可以人为的使得软件不存在配置问题。
(N)
12.集成测试计划在需求分析阶段末提交。
(N)
二、选折
1.软件验收测试的合格通过准则是:
(ABCD)
A.软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。
B.所有测试项没有残余一级、二级和三级错误。
C.立项审批表、需求分析文档、设计文档和编码实现一致。
D.验收测试工件齐全。
2.软件测试计划评审会需要哪些人员参加?
(ABCD)
A.项目经理
B.SQA负责人
C.配置负责人
D.测试组
3.下列关于alpha测试的描述中正确的是:
(AD)
A.alpha测试需要用户代表参加
B.alpha测试不需要用户代表参加
C.alpha测试是系统测试的一种
D.alpha测试是验收测试的一种
4.测试设计员的职责有:
(BC)
A.制定测试计划
B.设计测试用例
C.设计测试过程、脚本
D.评估测试活动
5.软件实施活动的进入准则是:
(ABC)
A.需求工件已经被基线化
B.详细设计工件已经被基线化
C.构架工件已经被基线化
D.项目阶段成果已经被基线化
三、添空
1.软件验收测试包括:
正式验收测试,alpha测试,beta测试。
2.系统测试的策略有:
功能测试,性能测试,可靠性测试,负载测试,易用性测试,强度测试,安全测试,配置测试,安装测试,卸载测试,文挡测试,故障恢复测试,界面测试,容量测试,兼容性测试,分布测试,可用性测试,(有的可以合在一起,分开写只要写出15就满分哦)
3.设计系统测试计划需要参考的项目文挡有:
软件测试计划,软件需求工件和迭代计划。
4.对面向过程的系统采用的集成策略有:
自顶向下,自底向上两种。
5.(这题出的有问题哦,详细的5步骤为~~)通过画因果图来写测试用例的步骤为:
(1)分析软件规格说明描述中,哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符。
(2)分析软件规格说明描述中的语义,找出原因与结果之间,原因与原因之间对应的是什么关系?
根据这些关系,画出因果图。
(3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现。
为表明这些特殊情况,在因果图上用一些记号标明约束或限制条件。
(4)把因果图转换成判定表。
(5)把判定表的每一列拿出来作为依据,设计测试用例。
四、简答(资料是搜集整理的,感谢前辈的解题)无
1.区别阶段评审的与同行评审
同行评审目的:
发现小规模工作产品的错误,只要是找错误;
阶段评审目的:
评审模块阶段作品的正确性可行性及完整性
同行评审人数:
3-7人人员必须经过同行评审会议的培训,由SQA指导
阶段评审人数:
5人左右评审人必须是专家具有系统评审资格
同行评审内容:
内容小一般文档< 40页,代码<500行
验证码:
换一张
上一页1...-1-1-1-1-1-1-1...-1下一页
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试