软件测试基础习题及答案.docx
《软件测试基础习题及答案.docx》由会员分享，可在线阅读，更多相关《软件测试基础习题及答案.docx（18页珍藏版）》请在冰豆网上搜索。
软件测试基础习题及答案
1、软件测试的定义？
软件测试是一个过程或者一系列过程，用来确认计算和代码完成了其应该完成的功能，并且不执行其不应该有的操作。
2、软件测试的目标是什么？
是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，降低软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。
3、简单描述一下软件测试的原则？
所有的软件测试都应追溯到用户需求
应当把“尽早地和不断地进行软件测试”作为测试者的座右铭
GoodEnough原则
质量第一
充分注意测试中的群集现象
程序员应避免检查自己的程序
有据可依
尽量避免软件测试的随意性，要有预期结果
重视回归测试
妥善保存一切测试过程文档
4、软件测试中验证和确认的区别？
Verfication验证：
是保证软件正确实现特定功能的一系列活动和过程。
目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段设定的目标。
Validation确认：
是保证软件满足用户需求的一系列的活动和过程。
目的是在软件开发后保证与用户需求符合
5、软件测试按照测试的基本策略可分为哪两种并加以详细说明？
白盒测试：
白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
黑盒测试：
黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。
6、整个软件生命周期中，需要进行哪几项测试？
单元测试、集成测试、系统测试、验收测试
单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。
它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。
因此应用系统有一个设计很好的体系结构就显得尤为重要。
一个软件单元的正确性是相对于该单元的规约而言的。
因此，单元测试以被测试单位的规约为基准。
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
简述集成测试和系统测试的区别？
1、集成测试的主要依据是概要设计说明书，系统测试的主要依据是需求设计说明书
2、集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台，网络及相关的外设的测试
7、系统测试的策略有哪些？
功能测试，性能测试，可靠性测试，负载测试，易用性测试，强度测试，安全测试，配置测试，安装测试，卸载测试，文挡测试，容错性测试，界面测试，容量测试，兼容性测试，分布测试，可用性测试等。
8、文档测试主要包括哪些内容？
联机帮助文档或用户手册
指导和向导
安装、设置指南
示例及模板
错误提示信息
用于演示的图像和声音
授权/注册登记表及用户许可协议
软件的包装、广告宣传材料
9、停止测试的条件？
符合用户的需求
在一段时间内测试不出新缺陷
注：
在企业实际开发过程中，版本发布时会有遗留问题
10、测试的基本文档包括哪些？
•测试计划》：
指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
•《测试方案》：
指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
•《测试用例》：
指明为完成一个测试项的测试输入，预期结果，测试执行条件等因素的文档。
•《测试规程》：
指明执行测试时测试活动序列的文档。
•《测试报告》：
指明执行测试结果的文档。
11、简要的说明一下软件工程中的V模型？
12、为什么要开展测试工作？
#z6hv_dJXH#C364231因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。
在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况
13、测试团队在项目中的基本责任是什么？
1、发现软件程序、系统或产品中所有的问题
2、尽早地发现问题
3、督促和协助开发人员尽快地解决程序中的缺陷。
4、帮助项目管理人员制定合理的开发计划
5、对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、清楚地了解产品当前的质量状态。
6、帮助改善开发流程、提高产品的开发效率
7、促进程序编写的规范性、易读性、可维护性等。
14、软件缺陷的定义是什么？
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
15、软件错误的分类有哪些？
软件需求错误
功能和性能错误
软件结构错误
数据错误
实现和编码错误
软件集成错误
操作系统调用错误
测试定义和测试执行错误
16、一个优秀的测试工程师需要具备的素质有哪些？
⏹目标：
发现软件缺陷，并尽可能早些。
⏹探索精神，软件测试员不害怕进入陌生环境。
⏹障碍排除高手，善于发现问题的症结。
⏹追求完美，他们力求完美，但是知道无法企及时，不去强求。
⏹不懈努力，不停尝试，他们不会心存侥幸，而是尽一切可能去寻找。
⏹判断准确，要觉得测试内容，测试时间以及看到的内容是否是真正的软件缺陷。
⏹老练稳重，不害怕坏消息，知道怎样和不够老练的程序员合作。
⏹具有说服力，善于表达观点。
17、软件质量的定义是什么？
软件质量是软件产品特性的总和，满足明确或隐含要求的能力。
18、质量有哪6个特性？
1）功能性（functionality）：
制作的功能，达到设计规范和满足使用者需求的程度。
2）可靠性（reliability）：
在规定期限和条件下，仍能维持其性能水平的程度。
3）易使用性（usability）：
使用者学习、操作、准备输入、理解输出所作努力的程度。
4）效率（efficiency）：
软件执行某项功能所需的计算机资源（含时间）的有效程度。
5）可维护性（maintainability）：
当环境改变或软件发生错误时，执行修改所做努力的程度。
6）可移植性（portability）：
从一个电脑系统或环境移到另一个电脑或环境的难易程度。
19、CMMI的中文名称是什么，共分为几级？
软件能力成熟度模型集成，共分为5级
20、缺陷报告的定义是什么？
缺陷报告是用来解释预期结果和实际结果之间差距的文档，包含怎么样再现缺陷的场景
21、缺陷的来源有哪些？
⏹需求问题
⏹设计缺陷：
•功能问题
•系统和软件架构问题
⏹实现缺陷
•代码问题
⏹相容性问题
⏹测试问题
22、缺陷主要有哪些状态？
New：
测试人员提交新bug的状态标识
Open：
测试经理审核测试人员提交的bug，审核通过后将该bug状态改为open并提交给开发经理。
开发经理对bug进行审核并分配给对应的开发人员。
Fixed：
开发人员已修改bug并自测通过的标识，由开发人员修改为此状态
Closed：
测试验证bug并通过的标识，由测试人员修改为此状态
Rejected：
开发人员认为不是Bug、描述不清、重复、不采纳所提意见建议或者测试人员提错，从而拒绝的问题。
由Bug分配人或者开发人员来设置。
Later：
确认是bug，但此bug目前暂时无法解决且对产品影响不大，或无法重现的问题等，通过会议评审可以暂缓或放入下个版本再解决
Reopen：
测试人员验证bug未通过，修改为此状态
23、软件缺陷报告有哪些属性？
软件缺陷的属性：
缺陷标识：
缺陷的唯一标识，用于识别、跟踪、查下、排序、存储管理等，可以使用数字序号表示
标题：
对缺陷的概括性描述，方便列表、浏览、管理等。
详细描述：
包括前提、操作步骤、预期结果、实际结果等
环境：
缺陷发现时所处的测试环境，包括操作系统、浏览器等
所属项目/模块：
缺陷所属哪个具体的项目或模块，要求精确定位至模块、组件级
产品信息：
属于哪个版本等
状态：
缺陷一旦被发现之后，其被跟踪过程中所处的状态
严重程度：
因缺陷引起的故障对软件产品使用或某个质量特性的影响程度
优先级：
缺陷被修复的紧急程度或先后次序，主要取决于缺陷的严重程度、产品对业务的实际影响，需要考虑开发过程的需求（对测试进展的影响）、技术限制等因素
类型：
属于哪方面的缺陷，如：
功能、用户界面、性能、接口等
可能性：
缺陷产生的频率
缺陷提交人：
会和邮件地址联系起来
缺陷指定解决人：
来源：
缺陷产生的地方，如：
产品需求定义书、设计规格说明书、代码的具体组件或模块，数据库，在线帮助，用户手册等
产生原因：
产生缺陷的根本原因，包括过程、方法、工具、算法错误、沟通问题等，以寻求流程改进、完善编程规范和加强培训等，有助于缺陷预防。
构建包跟踪：
用户每日构建软件包跟踪，是新发现的缺陷还是回归缺陷，基准是上一个软件包
版本跟踪：
用户产品版本质量特性的跟踪，是新发现的缺陷还是回归缺陷，基准是上一个版本
提交时间：
修正时间：
验证时间：
24、书写缺陷报告的基本原则（5C原则）是什么？
1．Correct（准确）：
每个组成部分的描述准确，不会引起误解
2．Clear（清晰）：
每个组成部分的描述清晰，易于理解
3．Concise（简洁）：
只包含必不可少的信息，不包括任何多余的内容。
4．Complete（完整）：
包含复现该缺陷的完整步骤和其他本质信息。
5．Consistent（一致）：
按照一致的格式书写全部缺陷报告。
25、一般情况下，缺陷报告的组织结包括哪些内容？
（1）缺陷的标题
（2）缺陷的基本信息，包括以下几方面
1．测试的软件和硬件条件
2．测试的软件的版本
3．缺陷的类型
4．缺陷的严重程度
5．缺陷的优先级
（3）复现缺陷的操作步骤
（4）缺陷的实际结果描述
（5）缺陷的预期结果描述
（6）注释文字和截取的缺陷图像或log
26、缺陷报告需要注意的问题有哪些？
尽量避免出现错误
不要把几个bug录入到同一个id
添加必要的截图和文件
完成一个bug的录入后应进行检查
27,、一般缺陷严重等级如何划分，并描述每个严重等级对应的错误内容？
致命（可对应目前BUG体系中的“非常严重”）：
致命性问题主要为：
系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为：
○严重花屏
○内存泄漏
○用户数据丢失或破坏
○系统崩溃/死机/冻结
○模块无法启动或异常退出
○严重的数值计算错误
○功能设计与需求严重不符
○其它导致无法测试的错误
●严重（可对应目前BUG体系中的“严重”）
严重性问题主要为：
影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
具体基本上可分为：
○功能未实现
○功能错误
○系统刷新错误
○语音或数据通讯错误
○轻微的数值计算错误
○系统所提供的功能或服务受明显的影响
●一般（可对应于目前BUG体系中的“普通”）
一般性问题主要为：
界面、性能缺陷
具体基本上可分为：
○操作界面错误（包括数据窗口内列名定义、含义是否一致）
○边界条件下错误
○提示信息错误（包括未给出信息、信息提示错误等）
○长时间操作无进度提示
○系统未优化（性能问题）
○光标跳转设置不好，鼠标（光标）定位错误
●提示（可对应于目前BUG体系中的“轻微及建议”）
提示性问题主要为：
易用性及建议性问题
具体基本上可分为：
○界面格式等不规范
○辅助说明描述不清楚
○操作时未给用户提示
○可输入区域和只读区域没有明显的区分标志
○个别不影响产品理解的错别字
○文字排列不整齐等一些小问题
○建议
28、缺陷优先级常用的划分方法是什么？
P1立即解决：
缺陷导致系统几乎不能运行、使用或严重妨碍测试的执行，需立即修正、尽快修正；
P2高优先级：
缺陷严重，影响测试，需要优先考虑修正，如不超过24小时；
P3正常排队：
缺陷需要修正，但可以正常排队等待修正；
P4低优先级：
缺陷可以在开发人员有时间的时候被修正，如没有时间，可以不修正
29、列出一些控件的名称？
菜单、按钮、对话框、消息提示框、文本框、单选按钮、复选按钮、工具栏、悬浮框、托盘、下拉列表等。
30、测试用例的定义？
测试用例是一系列的测试步骤，用以帮助测试人员发现缺陷
描述测试用例设计的完整过程？
需求分析+需求变更的维护工作
根据需求，得出测试需求
设计测试方案，评审测试方案
测试方案通过评审后，设计测试用例，再对测试用例进行评审
测试用例的元素有哪些？
用例ID、标题、优先级、预置条件、操作步骤、预期结果等
31、测试用例设计的步骤？
软件测试用例的设计遵守下列4部曲：
1、制定测试用例设计的策略和思想，在测试方案中描述出来
2、设计测试用例的框架，也就是测试用例的结构
3、细节结构，逐步设计出具体的测试用例
4、通过测试用例的评审，不断优化测试用例
32、测试用例设计的基本思想是什么？
1、设计测试用例时，要寻求系统设计、功能设计的弱点。
测试用例需要确切地反映功能设计中可能存在的各种问题，而不要简单拷贝产品规格设计说明书的内容。
2、设计正面的测试用例，应该参照设计规格说明书，根据关联的功能、操作路径等设计。
而对孤立的功能则直接按功能设计测试用例。
基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
3、设计负面的、异常的测试用例，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷，这显得更为重要。
例如，在进行电子邮件地址校验的时候，考虑错误的、不合法的（如没有@符号的输入）或者带有异常字符（单引号、斜杠、双引号等）的电子邮件地址输入，尤其是在做web页面测试的时候，通常会出现因一些字符转义问题而造成异常情况。
33、测试用例执行的步骤有哪些？
a）审核测试内容ReviewContent.
b）准备测试环境PrepareEnvironment.
c）测试用例步骤执行Testcasestepexecution.
d）检查执行结果Conductresultcheck.
e）测试结果报告Testresultreport.
f）测试用例的更新Testcaseupdate.
34、黑盒测试用例设计有哪些方法？
等价类划分法、边界值分析法、因果图法、功能图法、错误推测法、正交实验设计法、场景设计法
35、按照覆盖度由低到高写出白盒测试用例设计的方法？
语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
36、写出全球化、国际化和本地化的简称和它们之间的关系？
全球化：
G11Nglobalization的简写
国际化：
I18Ninternationalization的简写
本地化：
L10Nlocalization的简写
全球化=国际化+本地化
37、国际化测试的特殊需求有哪些？
A.支持unicode字符集。
如建立用于本地字符编码（ANSI或OEM）和unicode之间变换的字符映射表，既可以处理类似于英文的单字节语言，又能处理类似于中文、日文等双字节或多字节语言。
B.支持不同时区的设定、显示和切换
C.分离程序代码和显示内容（文本、图片、对话框和按钮等）。
如建立资源文件（*.rc）来存储这些内容。
D.消除硬代码（指程序代码中所包含的一些特定的数据），而尽量使用变量处理，将数据存储在数据库或初始化文件中。
E.使用Headerfiles定义经常被调用的代码段。
F.弹出的窗口、按钮、菜单等的尺寸具有自动伸缩性或可灵活地调整，以适应不同语言显示文本的长度变化。
G.吃吃各个国家的键盘设置，但要统一热键。
H.支持文字排序和大小写转换。
I.支持各国家的度量衡、时间、货币单位等不同格式的显示方式。
J.支持颜色字体等自定义。
K.拥有国际化用户界面设计。
软件国际化的测试就是验证软件产品是否支持上述特性。
38、本地化测试的基本内容是什么？
A.功能性测试
B.数据格式测试
C.可用性测试
D.翻译验证测试
E.兼容性测试
F.文档测试
42、一套完整的测试应该由哪些阶段组成？
测试计划、测试设计与开发、测试实施、测试评审与测试结论
43、如何理解压力、负载、性能测试？
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试，增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。
而负载测试是压力相对较大的测试，主要是测试系统在一种或几种极限条件下的相应能力，是性能测试的重要部分。
100个用户对系统进行连续半个小时的访问可以看做压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看做是负载测试。
实际上压力测试和负载测试没有明显的区分。
测试人员应该站在关注整体性能的高度上来对系统进行测试。
44、所有的软件缺陷都能修复吗？
所有的软件缺陷都要修复吗?
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。
测试人员要做的是能够正确判断什么时候不能追求软件的完美。
对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定哪些缺陷要修复。
发生这种现象的主要原因如下：
没有足够的时间资源。
在任何一个项目中，通常情况下开发人员和测试人员都是不够用的。
而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入的新缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。
有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复
不是缺陷的缺陷。
我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间考虑再处理
最后要说的是，缺陷是否修改要由测试人员，项目经理，开发人员共同讨论来决定，不同角色的人员从不同的角度来思考，以做出正确的决定。
45、软件测试人员就是QA吗？
软件测试人员的职责是尽可能的找出软件缺陷，确保得以修复。
而QA主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。
测试人员的主要工作是测试，QA日常工作重要内容是检查与评审，测试工作也是QA的工作对象
软件测试和质量保证是相辅相成的关系，都是为了提高软件质量而工作。
46、如何编写提交给客户的测试报告？
随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。
很多人会问“我们可以把工作中的测试报告提供给客户吗？
”答案是否定的。
因为提供内部的测试报告，可能会让客户失去信心，甚至否定项目。
测试报告一般分为内部测试报告和外部测试报告。
内部测试报告是我们在测试工作中的项目文档。
反映了测试工作的实施情况。
一般外部测试报告要满足以下几个要求：
根据内部测试报告进行编写，一般可以摘录
不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没必要让客户知道
报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的
报告上面的内容尽量要真实可靠
整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告
总之，外部测试报告要小心谨慎地编写。
47、当开发人员说不是bug时，你该如何应付？
开发说不是bug，有两种情况，一种是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，三方商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候，我们可以先尽可能的说出是bug的依据是什么？
如果被用户发现或出了问题，会有什么不良结果？
开发人员可能会给你很多理由，你可以对他的解释进行反驳。
如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。
其实有些不是bug，只是一些建议性的问题，如果开发人员不改也没有太大的问题，如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认
升级会员 