1、什么是软件测试h4>
在需求正确的前提下,验证软件的功能是否满足用户的需求
目的: 保证和提高软件的质量,给用户交付一个高质量、高可用度的一个软件。
2、软件测试和研发的区别h4>
测试和调试的区别
测试 是测试人员确保程序做了它应该做的事情
调试 是程序开发人员确保程序做了它想要程序实现的功能
3、为什么做软件测试件测试人员需要具备哪些素质h4>
思维模式:发散性思维,逆向思维,敢于质疑
兴趣:对软件测试感兴趣
性格特征:好奇心、敏感、不浮躁、善于怀疑
能力:快速学习能力、沟通能力、文字能力、开发能力、责任感、抗压能力p>
4、软件测试岗位划分
按测试对象划分: WEB测试工程师、APP测试工程师、游戏测试工程师、嵌入式测试工程师
按是否手工: 手工测试、自动化测试
按测试分类: 功能测试、性能测试、安全测试等
5、软件测试的目的和原则
目的: 验证软件有或没有问题
原则: 以客户需求为中心,遵循软件测试的规范、流程、标准和要求
6、什么是软件需求h4>
满足用户的期望和规定的合同(标准、规范、流程)所需要的条件和权能,包含用户需求和软件需求
(1)用户需求
外部用户和内部用户,目标所需的功能,一般比较简略
(2)软件需求
又叫功能需求,由用户需求转化而成,是对用户需求的分析,形成比较详细的需求实现文档
软件需求是测试人员进行测试工作的基本依据
7、什么是BUGh4>
当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误
当没有修去规格说明书时,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是软件错误
软件Bug实际是软件产品没有达到预期设计目标,在软件内部存在的一种缺陷。在不影响用户和系统正常运行的情况下处于隐蔽状态,没有表现出来。当Bug发生运行错误时,轻者影响用户使用,重者会构成事故,造成损失或伤害。
软件缺陷分类等级 按其危害程度大致分为4类:
(1)致命缺陷:Bug一旦运行,造成系统奔溃或挂起、数据被破坏。
(2)严重错误:造成系统不稳定,产生错误结果,业务处理嫩合理无法实现。
(3)一般错误:用户在某一功能时出现错误,但不影响该功能的实现和系统的正常运行。
(4)细微错误:用户使用软件时,感觉不方便。(界面不规范、辅助说明描述不清楚、提示窗口文字)
8、Bug产生的原因
软件缺陷的产生主要是由软件产品的特点和开发过程决定的
(1)需求不清晰,但至设计目标偏离客户的需求,从而引起功能或产品特征上的缺陷。
(2)系统结构非常复杂,而又无法设计成一个很好的层次结构或组件结构,结果导致意想不到的问题或系统或系统或维护、扩充上的困难;即使设计成良好的面向对象的系统,由于对象、类太多,很难完成对各种对象、类相互作用的组合测试,而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
(3)对程序逻辑路径或数据范围的边界考虑不够周全,漏掉某些边界条件,造成容量或边界错误。
(4)对一些实时应用,要进行精心设计和技术处理,保证精确的时间同步,否则容易引起时间上不协调、不一致性带来的问题。
(5)没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题,从而存在系统上安全性、可靠性的隐患。
(6)系统运行环境的复杂,不仅用户使用的计算机环境千变万化,包括用户的各种操作方式或各种不同的输入数据,容易引起一些特定用户环境下的问题;在系统实际应用中,数据量很大,从而引起强度或负载问题。
(7)由于通信端口多、存取和加密手段的矛盾性等,会造成系统的安全性或适用性等问题。
(8)新技术的采用,可能涉及技术或系统兼容的问题,实现没有考虑到。
9、Bug的生命周期
新建bug—指派—已解决—待验证—关闭
10、如何描述一个Bug
(1)出现问题的版本(版本 )
(2)出现问题的环境
硬件环境:系统所在的硬件设备
软件环境:浏览器的版本、客户机操作系统等
(3)错误重现的步骤
执行测试测试用例时,出现错误的步骤 (便于开发人员按照步骤定位)
(4)预期行为的描述
需求期望的描述
(5)错误行为的描述
实际情况和预期情况不一致时的情况
(6)测试数据
出现缺陷时输入的数据
(7)bug的类型
功能错误:功能没有实现
界面优化:UI、用户界面
设计缺陷:开发、需求文档中的功能没有实现
(8)优先级
紧急
重要
一般
11、敏捷开发和敏捷测试
软件开发的5个模型: 瀑布模型、螺旋模型、迭代、增量、
敏捷开发: 轻文档、轻流程、重目标、重产出
敏捷开发 的最大特点是高度迭代,有周期性,并且能够及时、持续地响应客户的频繁反馈。
敏捷测试 即是不断修正质量指标,正确建立测试策略,确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
(1)强调从客户的角度,即从使用系统的用户角度,来测试系统。
(2)重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。
(3)建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。
敏捷测试与普通测试的区别
1.项目相当于开发与测试并行,项目整体时间较快。
2.模块提交较快,测试时较有压迫感。
3.工作任务划分清晰,工作效率较高。
4.项目规划要合理,不然测试时会出现复测的现象,加大工作量。
5.发现问题需跟紧,项目中人员都比较忙,问题很容易被遗忘。
6.耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7.发现BUG能够很快的解决,对相关的模块的测试影响比较小。
8.版本更换比较勤,影响到测试的速度。
9.要多与开发沟通。
10.要注意版本的更新情况。
11.测试人员几乎要参加整个项目组的所有会议。
12、软件测试V模型和W模型
V模型: 每个阶段的测试和相应阶段的开发是一一对应的,用户需求–验收测试、需求分析与系统–系统测试、概要设计–集成测试、详细设计–单元测试、编码。缺点: 测试在编码之后,如果需求分析和设计有错误,到后期才能发现,不利于风险的控制。
W模型: 又称为双V模型,明确指出了在开发的某个阶段,测试相应需要的工作。缺点: 阶段依赖性很强,每个阶段的开始都依赖于上一阶段的完成后才能开始,不是很灵活,不能适用于敏捷开发的模式。
13、软件开发的生命周期、软件测试的生命周期
软件开发的生命周期: 需求分析–计划–设计–编码–测试执行–运行维护
软件测试的生命周期: 需求分析–测试计划–测试设计、测试开发–测试执行–测试评估
14、什么是测试用例用例的常用设计方法
测试用例: 是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等。
基于需求的设计
(1)等价类划分法
将测试的范围划分成几个互不相交的子集,他们的并集是全集,从每个子集选出若干个有代表性的值作为测试用例。分为有效等价类和无效等价类
(2)边界值分析法
根据输入输出边界的一种测试方法,对于在区间min,max的值,测试用例可以记为:min,min+,max,max-。通常输入和输出等价类的边界,就是应着重测试的边界情况。
(3)错误推测法
在测试程序时,人们可以根据经验或直觉推测程序中可能存在的各种错误,从而有正对性地编写检查这些错误的测试用例的方法。(没有固定的形式,依靠的是经验和直觉)
(4)因果图法
因果图法最终生成的是判定表。它适合于检查程序输入条件的各种组合情况。
(5)正交表分析法
在各种因素相互独立的情况下,设计出一种特殊的表格,找出能以少数替代全面的测试用例。特殊表格称为正交表。
(6)场景分析法:指根据用户场景来模拟用户的操作步骤
15、什么是B/S结构是C/S结构h4>
c/s结构 是客户机/服务器结构。有两层和多层之分。
服务器端只需要安装个sql2000服务器,客户端安装应用程序,这是典型的两层结构。
客户端和服务器端安装的内容都不一样,服务器端的安装抱要大一些,这可能是多层结构。
B/S结构 就是只安装维护一个服务器(Server),而客户端采用浏览器(Browse)运行软件bai,即浏览器/服务器结构。
1、C/S与B/S结构模式
随着Internet获得愈来愈广泛的应用,原来基于LAN的企业 开始采用Internet技术
来构筑或改建自己的企业 ,即Intranet。于是,一种新的结构模式Browser/Server结构
应运而生,并且获得飞速发展, 成为众多厂家争相采用的一种技术。其实,B/S也是一种Clinet/Server结构,它以浏览器为客户端软件,Web Server为服务器软件。但相对C/S结构,它又具有许多独特的优点:
(1) B/S是一种跨平台的、一点对多点及多点对多点的应用软件结构,减少了开发人员在客户端的工作量,使他们可以把注意力集中到怎样合理地组织信息、提供客户服务上来。
(2) B/S具有统一的浏览器客户端软件,不仅节省了开发、维护客户端软件的时间与精力,而且方便了用户的使用。
(3) 在B/S结构中,客户端只需运行操作系统和Web浏览器,数据的查询、处理和表示都由服务器完成。和C/S结构的应用系统相比,客户端变得非常”瘦”。
(4) 可以透明地跨越异质 络、计算机平台,无缝地联合使用数据库、超文本、多媒体等多种形式的信息。
(5) B/S系统运行的Internet易于设置、使用和管理。
16、版本控制工具Git
17、软件测试的方法
1、从是否关心内部结构来看:
(1)白盒测试:有称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。
(2)黑盒测试:又称为数据驱动测试,把测试对象当作看不见的黑河,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求考虑,确定测试用例和推断测试结果的正确性。它是站在使用软件或程序的角度,从输入数据与输出数据的对应关系出发进行的测试。
(3)灰盒测试:是一种宗合测试法,它将“黑盒”测试与“白盒”测试结合在一起,是基于程序运行时的外部表现又结合内部逻辑结构来设计用例,执行程序并采集路径执行信息和外部用户接口结果的测试技术
2、从是否执行代码来看:
(1)静态测试:指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试:是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能指标。
3、从开发过程来看:
(1)单元测试:又称模块测试,是针对软件设计的最小单位—-程序模块或功能模块,进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错,是否能正确地实现了其功能,能满足其性能和接口要求。
(2)集成测试:又叫组装测试或联合,时单元测试的多级扩展,是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系,以期望通过测试发现各种软件单元接口之间存在的问题,最终把经过测试的单元组成符合设计要求的软件。
(3)系统测试:是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动,它是将已经集成好的软件系统作为基于整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
4、在系统测试中,对于具体的测试类型有:
(1)功能测试:对软件需求规格说明书中的功能需求进行的测试,以验证功能是否满足要求。
(2)性能测试:对软件需求规格说明书的功能需求逐项进行的测试,以验证功能是否满足要求。
(3)接口测试:对软件修去规格说明书中的接口需求逐项进行的测试。
(4)人机交互界面测试:对所有人机交互界面提供的操作和显示界面进行的测试,以检验是否满足用户的需求。
(5)强度测试:强制软件运行在异常乃至发生故障的情况下(设计的极限状态到超出极限),验证软件可以运行到何种程序的测试。
(6)余量测试:对软件是否达到规格说明书中要求的余量的测试。
(7)安全性测试:检验软件中已经存在的安全性、安全保密性措施是否有效的测试。
(8)可靠性测试:在真实的或仿真的环境中,为做出软件可靠性估计而对软件进行的功能(其输入覆盖和环境覆盖一般大于普通的功能测试)
(9)恢复性测试:对有恢复或重置功能的软件的每一类导致恢复或重置的情况,逐一进行的测试。
(10)边界测试:对软件处在边界或端点情况下运行状态的测试。
(11)数据处理测试:对完成专门数据处理功能所进行的测试。
(12)安装性测试:对安装过程是否符合安装规程的测试,以发现安装过程中的错误。
(13)容量测试:检验软件的能力最高达到什么程度的测试。
(14)互操作性测试:为验证不同软件之间的互操作能力而进行的测试。
(15)敏感性测试:为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
(16)标准符合性测试:验证软件与相关国家标准或规范(如军用标准、国家标准、行业标准及国际标准)一致性的测试。
(17)兼容性测试:验证软件在规定条件下与若干个实体共同使用或实现数据合适转换时能满足有关要求能力的测试。
(18)中文本地化测试:验证软件在不降低原有能力的条件下,处理中文能力的测试。
5、从执行过程中是否需要人工干预来看:
(1)手工测试:就是测试人员按照事先为覆盖被测软件需求而编写的测试用例,根据测试大纲中所描述的测试步骤和方法,手工地一个一个地输 入执行,包括与被测软件进行交互(如输入测试数据、记录测试结果等),然后观察测试结果,看被测程序是否存在问题,或在执行过程中是否会有一场发生,属于比较原始但是必须执行的一个步骤。
(2)自动化测试:实际上是将大量的重复性的测试工作交给计算机去完成,通常是使用自动化测试工具来模拟手动测试步骤,执行用某种程序设计语言编写的过程(全自动测试就是指在自动测试过程中,不需要人工干预,由程序自动完成测试的全过程;半自动测试就是指在自动测试过程中,需要手动输入测试用例或选择测试路径,再由自动测试程序按照人工指定的要求完成自动测试)
6、从测试实施组织看:
(1)开发测试:开发人员进行的测试
(2)用户测试:用户方进行的测试
(3)第三方测试:有别于开发人员或用户进行的测试,由专业的第三方承担的测试,目的是为了保证测试工作的客观性
7、从测试所处的环境看:
(1)阿尔法测试:是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试
(2)贝塔测试:是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本,并要求用户 告
18、软件测试的内容
软件测试的内容:
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对 告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围,建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ,包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人,以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具,得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南,建立测试跟踪过程,建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和 告结果
19 跟踪问题 / 错误,并解决它
20 如果有必要,重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!