软件测试面试题(一)——测试基础

1.软件的生命周期都有哪些阶段,常见的软件生命 周期模型/h3>

软件生命周期:是指一个计算机软件从功能确定、设计,到开发成功投入使用,并在使用中不断地修改、增补和完善,直到停止该软件使用的全过程。
生命周期从收到应用软件开始算起,到该软件不再使用为止,有这几方面内容:初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测试、维护、升级、再测试、逐步淘汰等。
常见的软件生命周期模型:瀑布模型、迭代模型、快速原型模型、螺旋模型

2.什么是版本控制,常用的版本控制系统有哪些/h3>

版本控制是一种软件工程技巧,在开发过程中、确保由不同人所编辑的同一文件都得到更新及历史记录的保存。
Git,是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。
SVN是一个开源代码的版本控制系统,采用了分支管理系统。

3.软件测试与软件开发之间的关系

项目规划阶段:负责从单元测试到系统测试的整个测试阶段的监控。
需求分析阶段:确定测试需求的分析、系统测试计划的制定、评审后成为管理项目。测试需求分析是对产品生命周期中测试所需求的资源、配置、每阶段评判通过的规约;系统测试计划则是依据软件的需求规格说明书,制定测试计划和设计相应的测试用例。
详细设计和概要设计阶段:确保集成测试计划和单元测试计划完成。
编码阶段:由开发人员进行自己负责部分的代码测试。在项目较大时,由专人进行编码阶段的测试任务。
测试阶段(单元、集成、系统测试):依据测试代码进行测试,并提交相应的测试状态报告和测试结束报告。
开发和测试是一个有机的整体。在产品发布之前,开发和测试是循环进行的。测出的缺陷要经开发人员修改后继续测试。在开发的同时,测试经理开始编写测试用例,测试文档要参考开发文档,所以开发和测试是不可分割的,少任何一个都不行
从角色方面看,像理论和实验的关系,开发人员通过自己的想象创造出一套思想,之后测试人员在对他进行检验、证伪、开发人员再修改的过程,从而不断丰富产品,从方法方面看,是归纳和演绎的关系,一个要掌握大量技术,一个要不断的从实力中去学习。
开发和测试是相辅相成,密不可分的。一个符合用户需求的产品是开发和测试共同努力的结果。

4.常见的测试模型有哪些

V模型仅把测试放在编码的后一个阶段,忽视了测试对需求分析,系统设计的验证
W模型测试与开发同时进行,增加了开发与测试的同步性,但缺少了迭代的灵活性
H模型将测试功能独立出来,有第三方去测试。
X模型进行探索性测试,有经验的人员获取到测试用例之外的bug

5.请根据V模型概述测试人员在需求定义、设计阶段、编码阶段、集成阶段的工作任务和相应产生的文档。

需求定义阶段:提取测试需求并形成测试需求文档、根据提取的测试需求和项目计划进行测试计划的拟定,测试计划文档。
设计阶段:根据测试需求拟定方案文档;根据测试方案制定测试用例,并形成测试用例文档。
编码阶段:执行测试并形成测试用例文档。
系统集成阶段:测试总结报告,阶段问题统计报告,测试问题报告

6.编写测试计划的目的

使测试工作顺利进行,使项目参与人员沟通更加舒畅,使测试工更加系统化。

7.编写测试计划六步骤

why——为什么要进行这些测试
what——测试哪些方面、不同阶段的工作内容
when——测试不同阶段的起始时间
where——相应文档、缺陷存在的位置、测试环境等
who——项目有关人员组成、安排哪些测试人员进行测试
how——如何去做,使用哪些测试工具以及测试方法进行测试。

8.项目版本执行过程中,测试人员如何把控测试进度

在系统测试过程中,及时了解测试进度,跟踪BUG提交,修复及验情况以及系统的拷机情况。

9.测试人员在开发过程中的任务是什么吗

寻找Bug;避免软件开发过程中的缺陷;衡量软件品质;关注用户需求。
总的目标是确保软件质量。

10.软件测试种类

按照测试阶段:单元测试、集成测试、系统测试、验收测试
按照测试技术:黑盒测试、白盒测试
按照软件质量特性:功能测试、性能测试
自动化程度:手工测试、自动化测试
测试类型:界面类测试、安全性测试、文档测试
其他分类:α测试、β测试、回归测试、随机测试

11.黑盒测试、白盒测试、单元测试、集成测试、系统测试和验收测试的区别与联系

黑盒测试不考虑系统内部的结构与特性,只考虑需求说明书。
白盒测试测试人员利用内部的结构以及相关信息设计或选择测试用例,对所有路径进行测试。
单元测试白盒测试的一种,对软件设计中的单元模块进行测试。
集成测试在单元测试的基础上,对单元模块的连接和组装进行测试。
系统测试在所有都考虑的情况下,对系统进行测试。
验收测试在第三方进行的确认软件满足需求的测试。

12.简述Bug管理或者用例管理工具,并描述其中一个工作流程

常用:testlink、QC、mantis、禅道、TAPD、JIRA
TAPD:产品创建(需求、计划、模块)、项目创建(PM排期、任务分解)、研发(编码、单元测试)、测试(测试计划、用例、执行
bug、报告等)

13.禅道和QC的区别

同作为缺陷管理工具。
QC在缺陷管理方面做得相对完善。提交bug页面:填写内容可以根据测试需求、不断修改添加新的字段。缺陷查看页面:可以根据自己选择需要呈现的字段,相对人性化可操作。每个显示的字段都可以进行筛选,实研发人员很快定位到属于自己的bug。缺陷查看页面,可以根据自己需要选择呈现的字段,相对人性化可操作,每个字段都可以进行筛选,页面还有注释功能,方便完善又人性化。
禅道设计面广,在缺陷管理方面略有欠缺。提交bug页面是非常清晰整洁的Web页面,但需要填写的字段没哟完全覆盖开发和测试人员的全部需求。

14.黑盒和白盒测试常用的测试方法有哪些/h3>

黑盒:等价类划分法、边界值分析法,因果图法和错误猜测法。
白盒:逻辑覆盖法,循环测试路径,基本路径测试。
例如:在一次输入多个条件的完整性查询中,首先利用等价类划分法确定一个或者多个结果通过的测试用例,确认多个结果不通过的测试用例,然后利用边界值分析法,对通过和未通过的测试用例进行扩展和补充。

15.简述黑盒和白盒测试的优缺点

黑盒测试的优点:

  • 比较简单,不需要了解程序内部代码以及实现
  • 与软件内部实现无关
  • 从用户角度,很容易的知道用户会用到哪些功能,会遇到哪些问题
  • 基于开发文档,所以也能知道软件实现了文档中的哪些功能
  • 在做软件自动化测试时较为方便

黑盒测试的缺点:

  • 不可能覆盖所有的代码,覆盖率低
  • 自动化测试复用低

白盒测试的优点:

  • 帮助软件测试人员增大代码的覆盖率,提高代码质量,发现代码中的隐藏问题

白盒测试的缺点:

  • 程序员运行会有很多不同的路径,不可能测试所有的运行路径;测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求;系统庞大时,测试开销会非常大。

16.能不能在没有产品说明书和需求文档的情况下进行黑盒测试的设计

能。
可以通过其他工作内容去代替产品说明书和需求文档。
根据客户的功能点整理测试需求追溯表。
根据开发人员整理的功能测试点开展项目跨部门讨论会,主要整理对功能点的认识和理解,测试人员整理用例需求疑问提交项目组或者产品。
邮件客户代表确认部分争议问题。
项目的Demo和部分已经开发的系统参考同行业和竞争对手的类似产品、交叉模块之间的测试。
咨询客户或者相关者

17.单元测试的策略有哪些,主要内容有哪些

逻辑覆盖,循环覆盖,同行评审,桌前检查,代码走查,代码评审,静态数据流分析

18.白盒测试逻辑覆盖有哪几种覆盖标准,覆盖率最高的是那种/h3>

语句覆盖、分支覆盖、条件覆盖、路径覆盖、分支条件覆盖。
覆盖率最高的是路径覆盖。

19.Beta测试和Alpha测试有什么区别/h3>

大型通用软件,在正式发布前,都需要执行Alpha和Bate测试,目的是从实际终端用户,对软件功能和性能进行测试,以发现可能最终用户才能发现的错误。
Alpha测试是由一个用户在开发环境下进行测试,主要是评价软件产品的功能、可使用性、可靠性、性能和支持。
Beta测试是在实际使用环境进行测试,在开发者无法控制的环境下进行测试。

20.测试结束的标准

第一类:测试超出了预期的时间
第二类:执行了所有的测试用例,但并没有发现故障
第三类:使用特定的测试用例设计方案作为判断停止测试的基础
第四类:正面指出测试停止的具体要求
第五类:单位时间内查出的故障数量决定是否停止测试

21.软件测试的原则

  • 尽早和不断地进行软件测试
  • 测试用例应由测试输入数据和对应的预期输出结果这两部分组成
  • 程序员应避免检查自己的程序
  • 设计测试用例时,应包括合理的输入条件和不合理的输入条件
  • 充分注意测试中的集群现象。测试后程序中残存的错误数目与该程序中已发现的错误数目成正比
  • 严格执行测试计划,排除测试的随意性
  • 应当对每一个测试结果做全面的检查
  • 妥善保存测试计划、测试用例、出错统计和最终的分析报告,为维护提供方便。

22.探索性测试是什么,应该怎么做

在需求文档不完善或者压根没有需求文档的情况下,根据经验进行摸索尝试性进行的测试,是测试是过程中形成的基本的思维性测试。

23.什么是冒烟测试,如何有效的开展冒烟测试

软件最基本的功能测试,通常由开发完成,只有冒烟点都通过的产品,交由测试,才会比较有意义
冒烟测试贯穿于测试的各个阶段,比如集成测试、系统测试等。

24.一条高质量的缺陷记录(Bug)应该具有哪些内容/h3>
  • 记录Bug产生的前提条件
  • 产生Bug的详细操作步骤
  • 截图,直观地展示问题,有效帮助开发快速定位问题

25.做好软件测试应该具备那些素质

  • 较好的技术能力
  • 对业务逻辑的理解
  • 良好的沟通能力
  • 解决和分析事情的能力

26.对软件测试的最大兴趣

  • 行业前景比较好
  • 测试做的时间越久,面临的困难和挑战也越多,解决问题的同时也提高了自身的能力
  • 自己的性格比较开朗外向,很容易跟产品和开发沟通,做起事情事半功倍

27.输入三个整数,判断是否构成三角形,针对此进行设计测试用例

  • 首先设计满足三角形的条件,输入的三个数必须大于0,且同时满足任意两边之和大于第三边
  • 设三条边是a、b、c
  • 则要满足的条件为a>0,b>0,c>0,a+b>c,a+c>b,b+c>a
    以此来设计即可。
    1.等价类划分:三角形三条边A、B、C的数据类型不同
    2.边界值分析:由于三角形的边长可以是正整数或正小数,所以就不对长度进行测试,那么边界值分析就不用了
    3.因果图法:三角形的三条边数据输入组合
    等价类:
    有效等价类:
    输入3个正整数或正小数:
    1、两数之和大于第三数
    3、两数相等,如A=B或B=C或C=A
    4、三数相等,如A=B=C
    无效等价类:
    2、两数之和不大于第三数
    5、三数不相等,如A!=B,B!=C,C!=A
    1、空
    2、负整数
    3、非数字
    4、少于三个数

28.什么是测试用例,测试用例的基本要素

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序或核实是否满足某个特定需求
测试用例的基本元素:测试索引、测试环境、测试输入、测试操作、预期结果、评价标准。

29.描述测试用例设计的完整过程

  • 根据需求文档、概要设计、测试计划、测试方案细分出个功能模块的测试项
  • 根据测试项、按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子项
  • 按照测试子项、根据测试用例的设计方法(因果图、边界值、等价类等的设计方法)书写测试用例。
    注意:
  • 选用合适的用例管理工具(word、Excel)
  • 用例一定要及时更新(补充新的想法、删除时的需求)
  • 做好用例分级
  • 做好用例评审、写用例之前可以征询相关人员的意见、如果评审通过可以参考其执行测试,如果未通过需要继续修改直到通过为止
  • 可以考虑结对编写
  • 要全面,包括功能、性能、兼容性、安全性、易用性、容错性等
  • 注意把握适当的颗粒度

30.一个有广告的纸杯子,请设计测试用例

测试项目:杯子
需求测试:查看杯子使用说明书界面测试,查看杯子外观
功能度:用水杯装水看漏不漏,水能不能被喝到
安全性:杯子有没有毒,或者细菌
可靠性:杯子从不同高度落下的损坏程度
可移植性:杯子在不同的地方、温度等环境下是否都可以正常使用兼容性,杯子是否能够容纳果汁,白水,酒精,汽油等。
易用性:杯子是否烫手、是否有防滑措施、是否方便引用
用户文档:使用手册是否对杯子的用法、限制、使用条件等有详细说明
疲劳测试:案例一:杯子盛上水放24小时检查泄露时间和情况;案例二:盛上汽油放24小时检查泄露时间和情况
压力测试:用针并在针上不断添加重量,看压强多大时会穿透跌落测试;杯子加包装(有填充物)在多高的情况下不破损
振动测试:检查产品能否应对恶劣的铁路公路航空运输

基本功能测试:

  • 硬度 是否达到设计标准
  • 界面测试(UI测试)
  • 易用性测试
  • 稳定性测试
  • 安全性测试
  • 本地化测试
  • 对设计的改进建议。能否标志已使用,使用者是谁

31.身份证号码输入框,怎么设计用例

  • 校验身份证号码的有效性(地址、生日期码,顺序码和校验15位和18位身份证号都是可用的)
  • 检验末尾是X的情况
  • 校验不足15位,16-17位和大于18位的情况
  • 如果是必填项,校验不输入的时候会不会有正确的提示
  • 如果不是必填项,则校验不输入的时候流程能否正确进行
  • 如果不是必填项,不输入的时候能否正确运行
  • 校验非数字的情况是否会有提示信息,全半角的情况

32.登录功能怎么设计测试用例

具体需求:
有一个登录页面,一个账号和一个密码输入框,一个提交按钮
了解需求:
登录界面是弹窗式还是直接在网页里;账号长度和密码强度(多少位,大小写敏感。特殊字符混搭等);界面美观是否有要求等
用例设计:

  • 功能设计:
    • 输入正确的账号密码,点击登录,是否能够正确登录(正常输入)
    • 输入错误的账号或者密码,验证登录会失败,并且提示相应的错误信息(错误校验)
    • 登录成功后能否跳转到正确的页面
    • 账号和密码如果太长或者太短,应该怎么处理(安全性、密码太短是否有提示)
    • 账号和密码中有特殊字符(比如空格)和其他非英文的情况(是否做了过滤)
    • 记住账号的功能
    • 登录失败后,不能记住密码的功能
    • 账号密码前后后空格的处理
    • 密码是否加密显示
    • 牵扯到验证码,还要考虑文字是否扭曲过度,导致辨认难度大,考虑颜色(色盲使用者)或换一个按钮是否好用
    • 登录页面中注册、忘记密码、登出用另一账号登录等链接是否正确
    • 输入密码时大写键盘开启的时候的提示信息
    • 什么都不输入,点击提交按钮,看提示信息
  • 界面测试
    • 布局是否合理,两个Textbox和一个按钮是否对齐
    • textbox 和按钮的长度、高度是否符合要求
    • 界面的设计风格是否与UI的设计风格统一
    • 界面中的文字简洁易懂,没有错别字
  • 性能测试
    • 打开登录界面,需要几秒
    • 输入正确的账号密码,登录跳转到新页面,不超过5秒
    • 登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)
    • 账户密码的验证,应该是服务端验证
    • 账号密码的输入框,应该屏蔽SQL注入攻击
    • 账号密码的输入框,应该禁止输入脚本
    • 错误登录的次数限制(防止暴力破解)
    • 考虑是否支持多用户在同一台机器上登录;
    • 考虑一用户在多台机器上等登录
  • 可用性测试
    • 是否可以全用键盘操作,是否有快捷键
    • 输入账号密码后按回车,是否可以登录
    • 输入框是否可以用Tab键切换
  • 兼容性测试
    • 主流的浏览器是否能显示正常以及功能正常(Chrome、IE、火狐、Safari)
    • 不同的平台是否能够正常工作,移动设备上能否正常工作
  • 本地化测试
    • 不同语言环境下显示是否正确
    • 软件辅助性测试是否向残疾人提供足够的辅助功能
    • 高对比度下是否正常显示(视力不好的人)

33.好的测试用例有哪些特点

质量属性:

  • 正确性
  • 经济性
  • 可重复性
  • 适应性
  • 可追踪性
  • 自我清理性
  • 结构化和可测试性
  • 含有规范的标题和编号
  • 含有一个确定的测试某一个特定的需求的目的
  • 含有关于测试方法的描述
  • 指定安全信息-环境,数据,预制的条件测试,安全入口等
  • 陈述任何辅助证据
  • 确保测试环境干净
  • 操作步骤不超过15步
  • 确保单个测试用例执行时间不超过20分钟
  • 自动化脚本用例添加必要的注释,比如目的、输入和期望结果。
  • 如果可能,建议提供可选择性的预置条件测试。
  • 用例之间的先后顺序是否跟业务流程一致,即用例在业务流程中的彼此顺序关系是否合理。配置管理:
  • 采用命名和编号规范归档。保存为特定的格式,文件类型。
  • 用例版本是否与当前被测试软件版本一致((对应)。
  • 包含用例需要的相应测试对象,如特定数据库。
  • 存档阅读。
  • 存档时按角色控制访问方式当网络备份时存档。
  • 离线归档。

33.软件缺陷的生命周期

  • 测试人员提供新Bug入库,错误状态为New;
  • 高级测试人员验证错误,如果确认错误分配给响应的开发人员,设置状态为Open;
  • 如果不是错误,设置为Declined(拒绝状态)
  • 开发人员查询状态为Open的Bug,如果不是错误,则状态设置为Declined
  • 如果是Bug则修复状态设置为Fixed;
  • 不能解决的Bug,要留下文字说明及保持Open状态
  • 对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议才能通过认可。
  • 测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如设置Bug状态为Closed,如没有解决状态设为ReOpen

34.缺陷描述(报告单)中应该包含哪些内容

缺陷的标题,简要的描述、缺陷的类型、缺陷的详细描述步骤,缺陷的实际结果,预期结果、上传截图日志信息等
缺陷的等级以及需要指派给开发同事。

35.如何提高缺陷的记录质量

  • 通用UI要统一、准确;
  • 尽量使用业界惯用的表达术语和表达方式,尽量准确,体现专业化;
  • 每条缺陷用例只包括一个缺陷
  • 不可重现的缺陷也要报告
  • 明确指出缺陷类型;
  • 明确指出缺陷的严重等级和优先等级
  • 描述简介、准确、完整
  • 短行之间使用自动数字序号,使用相同的字号、字体、行间距
  • 每一个步骤尽量只记录一个操作
  • 确认步骤完整、准确、简短
  • 检查拼写或者语法缺陷
  • 尽量使用短语和短句,避免复杂句型
  • 缺陷描述内容

36.如果缺陷被提交之后开发人员认为不是问题怎么处理

  • 将问题提交到缺陷管理库里面进行备案
  • 要获取判断的依据和标准
    • 根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的问题,提供缺陷是否确认的直接依据
    • 如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否存在缺陷
    • 根据用户的一般使用习惯来确认是否缺陷
    • 与涉及人员、开发人员和客户等相关人员探讨,确认是否有缺陷
  • 合理的论述,向测试经理说明自己的判断理由
  • 等待测试经理做出最终决定。如果仍存在争议,可以通过公司政策所提供的的渠道,向上级反映,并由上级做出决定

37.图片验证码有什么作用

图形验证码是验证码的—种,有防止黑客对某一特定注册用户用程序暴力破解私人信息、恶意破解密码、刷票、论坛灌水的作用。
图形验证码是一种区分用户是计算机还是人的公共全自动程序。
验证码是现在很多网站通行的方式,由计算机生成并评判,但是只有人类才能解答。

来源:柒柒1275

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2022年9月17日
下一篇 2022年9月17日

相关推荐