测试用例面试题
黑盒测试、白盒测试的基本概念
面试题目
- 级别: L1
- 知识模块: 测试用例设计
什么是黑盒测试,什么是白盒测试是特别容易被问到的一个问题。
公司
某金融公司
招聘类型
- 校招
题目解析
面试官主要考察内容为:
- 软件测试的基础理论熟悉程度。
解题思路:
-
说出黑盒测试和白盒测试相关的概念。
- 黑盒测试会把被测的软件看作是一个黑盒子,测试时不去关心盒子里面的代码结构和逻辑是什么样子的,只需要关心盒子的输入数据和输出结果。在黑盒测试当中,测试工程师会模拟用户的行为去使用产品,检查软件产品是否达到了用户的需求。
- 白盒测试也把被测的软件看作是一个盒子,但是需要考虑盒子的内部结构和逻辑。所以根据待测产品的内部实现细节来去设计测试用例的方法称为白盒测试。
-
列举出黑盒测试和白盒测试的使用场景。
- 黑盒测试方法能够真实地从用户角度来考察被测系统的功能性需求实现情况。在软件测试的各个阶段,如单元测试、集成测试、系统测试及验收测试等阶段中,黑盒测试都发挥着重要作用。尤其在系统测试和验收测试中,它的作用是其他测试方法无法取代的。
- 白盒测试是可以看到内部代码如何运作的,可通过测试来检测产品内部是否符合规定正常运行。它执行手段其实是不限的。既可以使用静态测试的方式,比如代码审查,代码扫描工具等等。
-
列举出黑盒测试和白盒测试的设计方法。
- 比较常用的黑盒测试方法有等价类划分法、边界值分析法、因果图法、判定表法、场景法、正交法等等。
- 语句覆盖、判断覆盖、条件覆盖、路径覆盖等等。
黑盒测试
将软件测试看作是一个黑盒子,不用关心内部的逻辑代码,只关心输入输出的结果。
适用于软件测试的各个功能需求阶段
常用的黑盒测试方法有:等价类划分法、边界值分析法、因果图法、判定表法、场景法、正交法等。
白盒测试
白盒测试需要关心程序的内部代码逻辑如何实现的,一般适用于单元测试阶段的代码检测,
测试形式包括动态运行代码测试和静态观察代码测试,
常用的测试方法有:语句覆盖、判定覆盖、条件覆盖、路径覆盖等。
答案
黑盒测试和白盒测试都是测试设计的方法。
黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现。它把被测试的程序当作一个黑盒子,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
白盒测试需要根据软件内部的逻辑结构分析来进行测试,是基于代码的测试。把被测程序当作盒子的话,它需要考虑盒子的内部结构和逻辑。测试人员通过阅读程序代码或者通过编写测试代码的方式来判断软件的质量。
两种测试方法分别适用与不同的测试场景。黑盒测试更多使用在系统测试和验收测试中。而白盒测试则是针对代码本身的测试,所以更多用在单元测试或者集成测试中。
拿到一个需求怎么去写测试用例
面试题目
- 级别: L1
- 知识模块: 测试用例设计
拿到一个需求怎么去写测试用例
公司
- 某金融公司
招聘类型
- 社招
- 校招
题目解析
编写测试用例是确保软件质量的重要环节。测试用例设计的目标是全面覆盖需求,验证软件在各种情况下的正确性和稳定性。
关键步骤:
- 理解需求文档:仔细阅读并理解需求文档,明确每个功能点和非功能需求(如性能、安全性等)。
- 识别功能点:列出需求中涉及的所有功能点,这些功能点将成为测试用例的基础。
- 确定测试范围:确定哪些部分需要测试,包括正向场景(正常操作)、逆向场景(异常操作)、边界条件和特殊情况。
- 使用测试设计方法:
- 需求覆盖:将需求与测试用例对应起来,确保每个需求都有相应的测试用例。
- 等价类划分:将输入条件划分为等价类,减少测试用例数量但保证覆盖面。
- 边界值分析:关注边界条件,确保系统在边界处的处理正确。
- 编写测试用例:每个测试用例应包括测试标题、前置条件、测试步骤、预期结果和实际结果等信息。
- 评审和完善:通过团队评审,确保测试用例的全面性和准确性,避免遗漏重要测试场景。
通过系统的测试用例设计,能够有效发现软件在不同条件下的潜在问题,确保所有功能点和场景均得到验证,从而提高软件的可靠性和用户体验。
答案
根据需求文档,识别功能点和边界条件,通过需求覆盖、等价类划分和边界值分析等方法设计测试用例,覆盖所有正常、异常和边界情况。
如何设计测试用例
面试题目
- 级别: L1
- 知识模块: 测试用例设计
设计测试用例
公司
- 小米
招聘类型
社招
题目解析
面试官主要考察内容为:
- 对软件测试基础知识的掌握情况。
- 能够根据工作中的场景设计出测试用例。
- 对测试用例的基本了解情况。
解题思路:
- 描述测试用例的基本组成部分。用例编号,用例标题,项目模块,优先级,前提条件,测试步骤,预期结果。
- 测试用例设计方法。等价类划分法、边界值法、因果图法、判定表法、场景法、错误推断法等。
- 设计测试用例要考虑的情况。用例的覆盖度,性能,安全等其他方面的维度。
- 从后期维护的角度阐述测试用例给的意义。写的测试用例描述的是否简介清晰
答案
测试用例的基本组成部分包括,用例编号,用例标题,项目模块,优先级,前提条件,测试步骤,预期结果。
使用用例设计方法对测试的功能点进行拆分,如常用的等价类划分、边界值法、因果图法、判定表法、场景法、错误推断法等。
在设计测试用例的过程中还要根据实际的项目考虑到用例的覆盖度,性能,安全等其他方面的维度。
还要考虑自己写的测试用例描述的是否简介清晰,为后期维护工作提供强力的支持。
给你⼀个⽹站你如何开展测试⼯作
面试题目
- 级别: L1
- 知识模块: 测试用例设计
给你⼀个⽹站你如何开展测试⼯作
公司
- 小米
招聘类型
社招
题目解析
面试官主要考察内容为:
- 对整个测试流程的理解程度
- 测试用例覆盖度是否全面
- 测试用例设计方法使用是否熟练
解题思路:
- 阐述整个软件测试的基本流程
- 对每个流程根据题目进行补充和丰富
- 根据网站的特点补充特殊的测试点
答案
- ⾸先查找需求说明、⽹站设计等相关⽂档,分析测试需求
- 制定测试计划,确定测试范围和测试策略,⼀般包括以下⼏个部分:功能性测,试界⾯测试,性能测试,数据库测试,安全性测试,兼容性测试
-
设计测试⽤例:
- 功能性测试可以包括,但不限于以下⼏个⽅⾯:
- 链接测试:链接是否正确跳转,是否存在空⻚⾯和⽆效⻚⾯,是否有不正确的出错信息返回等;
- 提交功能的测试;
- 多媒体元素是否可以正确加载和显示;
- 多语⾔⽀持是否能够正确显示选择的语⾔等
- 界⾯测试可以包括但不限于⼀下⼏个⽅⾯:
- ⻚⾯是否⻛格统⼀,美观。⻚⾯布局是否合理,重点内容和热点内容是否突出。控件是否正常使⽤。
- 对于必须但为安装的空间,是否提供⾃动下载并安装的功能。⽂字检查。
- 性能测试⼀般从以下两个⽅⾯考虑:压⼒测试,负载测试,强度测试 。
- 数据库测试要具体决定是否需要开展。数据库⼀般需要考虑连结性,对数据的存取操作,数据内容的验证等⽅⾯。
- 安全性测试:基本的登录功能的检查;是否存在溢出错误,导致系统崩溃或者权限泄露;
- 相关开发语⾔的常⻅安全性问题检查,例如 SQL 注⼊等;
- 如果需要⾼级的安全性测试,确定获得专业安全公司的帮助,外包测试,或者获取⽀持。
- 兼容性测试,根据需求说明的内容,确定⽀持的平台组合:浏览器的兼容性;操作系统的兼容性;软件平台的兼容性;数据库的兼容性。
- 开展测试,并记录缺陷。合理的安排调整测试进度,提前获取测试所需的资源,建⽴管理体系(例如,需求变更、⻛险、配置、测试⽂档、缺陷报告、⼈⼒资源等内容)
- 定期评审,对测试进⾏评估和总结,调整测试的内容。
- 功能性测试可以包括,但不限于以下⼏个⽅⾯:
没有需求⽂档,你会如何执⾏测试
面试题目
- 级别: L1
- 知识模块: 测试用例设计
没有需求⽂档,你会如何执⾏测试
公司
- 小米
招聘类型
社招
题目解析
面试官主要考察内容为:
- 沟通理解能力:能够有效的与相关人员沟通获取关键的项目去求和功能描述,能够通过沟通保持大家对需求的理解一致。
- 需求汇总能力和自主创造力:能够通过沟通理解,产出对应的测试计划。
- 测试计划和策略的分析能力:是否能够根据现有的信息和项目背景设计出有效的测试用例。
- 问题解决能力:能否及时的发现设计的测试计划以及用户提出的需求存在的潜在问题,与团队沟通合作解决问题。
解题思路:
- 梳理项目功能并产出测试相关问文档
- 对于团队内部的具体操作
- 对于客户的具体操作
- 根据项目考虑具体的针对性的测试点
答案
假如没有需求⽂档我会从以下⼀些⽅⾯着⼿:
- 根据客户的功能点整理测试需求追朔表
- 根据开发⼈员的 Software Specification List 整理我们的功能测试点
- 开展项⽬跨部⻔讨论会
- 测试⼈员整理⽤例需求疑问递交项⽬组和客户代表回复
- 项⽬内部⽤例评审
- 邮件和客户代表确认部分争议问题
- 项⽬ Demo 和部分已开发系统
- 参考同⾏业和竞争对⼿的类似产品
- 交叉模块的测试要注意
- 咨询客户部分需求疑问
你们公司是如何开展测试⽤例评审的?发现过什么问题
面试题目
- 级别: L1
- 知识模块: 测试用例设计
你们公司是如何开展测试⽤例评审的?发现过什么问题?
公司
- 小米
招聘类型
- 社招
题目解析
考察是否有真实工作经验。
答案
- ⽤例评审的过程:
- 会议形式开展,会提前发出初稿或会议邀约
- 先做简单的业务流程介绍
- 再按模块或业务流程进⾏讲解,⼀般重点放在核⼼业务上
- ⽤例评审后进⾏确认
- ⽤例评审时发现缺少测试点,和产品开发开会进⾏补充,再次修改后进⾏审核
- 结合项⽬补充案例:
- 例如:售后管理,取消服务单功能,在⽤户退货并发货后,再次点击取消服务单,这个场景没有测试,觉得没有必要 (场景上可以没有,但是实际有的功能)
测试用例怎么评审更高效
面试题目
- 级别: L1
- 知识模块: 测试用例设计
测试用例怎么评审更高效
公司
- 小米
招聘类型
社招
题目解析
- 提前分发测试用例文档:让评审人员有充分时间准备,减少评审会议时间。
- 明确评审目标和重点:集中讨论关键和复杂用例,提高评审效率。
- 分配明确的角色和职责:测试组长组织讨论,测试工程师记录问题,其他人员提出意见,确保每个环节有序进行。
- 利用工具:如 JIRA、禅道等,在线协作记录和跟踪问题,提高沟通和问题处理效率。
- 及时总结和更新:会后立即总结并更新测试用例,确保评审意见得到落实,提高测试用例质量。
答案
测试用例评审更高效的方法包括:提前分发测试用例文档,确保所有评审人员在会前充分准备;明确评审目标和重点,集中讨论关键和复杂用例;分配明确的角色和职责,如主持人、记录员、评审人员;利用工具进行在线协作,实时记录和跟踪问题;会后及时总结并更新用例,确保意见落实。
需求发⽣变化,你会如何处理
面试题目
- 级别: L1
- 知识模块: 测试用例设计
需求发⽣变化,你会如何处理
公司
- 小米
招聘类型
社招
题目解析
面试官主要考察内容为:
- 对于变化的管理能力
- 沟通和协商能力
- 变更影响分析能力
解题思路:
- 分需求变更内容是否进行测试情况阐述
- 评估工时
- 及时沟通调整工时,保证测试进度不受影响
答案
分两种情况:
- 本次需求变更的内容对应模块还没有进⾏测试
- 评估需求变更对应功模所带来的⼯时是否⼤于原来该模块的测试⼯时
- 如果超过原有模块的测试⼯时,影响测试计划则需要考虑以下⼏点,看是否的能在原计划的范围内内部消化:加班、协调资源、根据现有测试过的模块情况来分析是否可以调整⼀些测试时间、如果所有⽅式都已经考虑则反馈给测试负责⼈或项⽬经理来进⾏协商
- 本次需求变更的内容对应模块已经完成了测试
- 看是否的能在原计划的范围内内部消化:加班、协调资源、根据现有测试过的模块情况来分析是否可以调整⼀些测试时间、如果所有⽅式都已经考虑则反馈给测试负责⼈或项⽬经理来进⾏协商
- 是否可以裁减功能
- 是否可以延期实现
在需求评审时,通过哪几个角度来发现问题
面试题目
- 级别: L1
- 知识模块: 测试用例设计
在需求评审时,通过哪几个角度来发现问题?
公司
- 某金融公司
招聘类型
- 社招
题目解析
在需求评审的过程中通过以下 4 个通用的角度来进行问题的发现:
业务场景角度
用户故事方法论
站在用户的角度,考虑用户会遇到的各种情况,从各种情况的需求中去匹配查看是否有对应的场景描述及结果展示。
例子
比如,企业微信添加部门这个功能的需求评审,我们不能只考虑对应的部门可以添加成功,还需要考虑以下几点是否有相关说明:
- 在已有的部门下添加子部门,如何展示,对应层级关系/父子关系是否明确
- 对应修改部门的信息,是否子部门的关联相关信息也进行修改
- 删除部门的时候是否校验包含子部门及成员
- 是否有部门查询功能
业务流程图
根据用户的使用场景画出简单流程图,查看需求中是否对各种场景对应的路径、执行条件及约束关系 有明确、合理的定义。
系统交互角度
穷举系统
- 穷举系统,找出相关系统
开发和测试人员共同把控,把目前公司已有的系统都考虑一遍,对比当前需求,找出与其功能实现相关的系统服务。
产品只考虑前端交互,对应涉及后端多少个服务系统并不清楚,需要开发和测试人员找出涉及的系统;
例子
产品提出的需求对应只涉及当前 A、B 两个系统交互进行开发,但是测试时发现由于上下游系统未被考虑进需求,导致无法按需求的期望整体业务流转。
系统边界
每个系统都有自己侧重实现点,产品只考虑该功能页面实现效果,但是对应是哪个开发组进行该功能开发产品不清楚,这就会导致当前需求的划分系统边界问题。
如果系统边界划分不清晰会最后导致整个技术架构混乱,所以,在需求评审时,测试需要提出让技术架构保持一个内聚的结构。
例子
企业微信增加新需求,获取考勤系统中员工的考勤异常记录并发送给该员工。
但是不同的公司会有不同的考勤系统,对应企业微信如果实现该功能则需要兼容市面上所有主流的考勤系统,对应的难度直接增大。
其实这就是对应系统之间的边界没有划分清晰,定制化的业务逻辑不要放在系统中。
企业微信要实现考勤异常记录发送给员工,应该实现一个开放式接口,去规定好考勤异常记录的消息模版,不同公司的考勤系统导出异常数据,填入企业微信规定好的模版内即可。
系统明确对应功能,比如企业微信主要是进行数据的管理及消息传递的动作
侵入性
原有系统有某些数据相关特性约定,由于新业务需求改变了之前的一些数据约定或者需要愿系统做一个范围内的整改,这种情况就需要对该需求对系统原有设计的侵入性进行评估。
如果是非要对数据结构进行更改,则需要在设计的时候尽量与原有模块的数据进行解耦。
改动性
在需求评审的时候,需要对产品提出的需求所带来的改动进行必要性及改动量评估,有些需求由于产品经理不熟悉产品直接提出,但是有时对应产品有些公共通用组件就可以实现该需求。
所以,在产品提出需求时,需要对该需求的必要性进行评估。
有些需求,产品认为只是实现一个小的功能点按钮之类的,未考虑到技术实现会涉及到服务端多个模块,导致对该需求改动量评估过低的现象。
功能点角度
数据
有关需求中的数据内容,对应的约束是否比较全面,约束的条件是否规定的比较合理。
流程
需求中存在多种分支的逻辑情况时,对应的描述是否全面,是否覆盖了所有分支路径。
- 比如企业微信添加员工,在添加后是否自动邀请该员工使用企业微信,邀请和不邀请对应的分支逻辑具体是什么。
需求中对应功能存在多种状态时,对应功能的状态流转描述是否完整并且合理。
- 比如审批流,对应审批中、审批失败、审批驳回、再次审批这些状态的流转是否明确并且合理。
权限
需求对应的功能是否有对应权限描述。
比如审批这个功能,对应是销售权限的人员只能提交审批,经理级别的人员才能进行以及审批等等,对应每个功能的角色权限需要描述清楚。
项目角度
优先级
不是只要产品提出一个需求,就要进行开发上线,需要对该需求进行一个优先级的评估,是否为当前系统所必须;
如果有多个需求并发的话,需要对这些需求进行一个优先级排序。
deadline
需求不只是要排出对应的优先级,还需要对需求进行一个排期,对应开发周期及测试周期,还有最终的该需求的上线日期。
第三方系统对接确认
如果需求涉及到与第三方系统进行交互,则在需求评审时需要产品明确对接流程。
作为一个测试人员在开需求评审会时,大致需要通过以上几个通用角度来进行考虑。
答案
在需求评审时,从业务场景、系统交互、系统边界和项目角度四个方面进行问题发现,确保需求的完整性和可行性。
给你一个购物车界面,你怎么测试
面试题目
- 级别: L1
- 知识模块: 测试用例设计
给你一个购物车界面,你怎么测试
公司
- 某金融公司
招聘类型
- 社招
- 校招
题目解析
关于测试用例设计是做测试的同学必须要具备的技能。不管是出去面试,还是在平常的工作当中,可以熟练设计测试用例基本是对测试人员的一个基本要求。
比如在面试中我们被问到给你一个购物车界面,你怎么测试这样一个问题。应该咱们回答呢?
可以遵循以下的思路
对于购物车来说也是同样的思路。
首先第一步要做的就是需求分析。不管是在什么场景中,都应该明确需求之后,再开始进行测试用例的设计。
在面试中,这一步可以体现为与面试官聊一聊需求的细节。
重点需要把 3 个方向的内容确认清楚:
- 确认测试范围
- 确认功能点
- 确认功能流程
使用思维导图的形式来梳理
下面就按照上面思路来梳理购物车的测试点。
答案
界面测试
- 界面显示正常
- 界面布局合理美观
- 文案展示正确
功能测试
测试功能可以从这几个方面去考虑
具体的测试点比较多,请直接查看完整的思维导图。
易用性测试
- 快捷键功能是否支持
- 提示信息
- 操作引导
- 商品展示排序合理
兼容性测试
不同的产品在考虑兼容性测试的时候,方案是不一样的。
Web 产品的兼容需要重点考虑
- 浏览器
- 操作系统
- 分辨率
App 产品的兼容需要重点考虑
- 平台
- 厂商
- 设备型号
- 操作系统
- 分辨率
对于兼容性测试来说,需要保证在这些硬件环境中,产品的界面展示正确,功能可以正常使用。
性能测试
- 界面元素多次快速操作
- 响应时间
- 并发量
- CPU
- 内存
- App:耗电量、流量、压力测试
安全性测试
- 账号限制:登录超时、账号互踢
- 敏感信息加密传输
- 漏洞扫描
给你⼀个物件(花瓶、笔、桌⼦)怎么测试
面试题目
- 级别: L1
- 知识模块: 测试用例设计
给你⼀个物件(花瓶、笔、桌⼦)怎么测试
公司
- 小米
招聘类型
社招
题目解析
面试官主要考察内容为:
- 测试用例设计能力
- 问题解决能力
- 逻辑思维能力
- 沟通表达能力
解题思路:
- 先从全局观的角度讲每一个大维度讲出来
- 再对每一个维度进行详细的拓展补充
-
⽆论是哪个物件,都从以下⼏个维度出发设计,根据软件质量模型的八大特性进行阐述:
-
需求分析
- 界面测试
- 功能测试
- 易用性测试
- 兼容性测试
- 性能测试
- 安全性测试
答案
例如:如何测试⼀⽀笔?
- 需求分析
- 什么样的笔
- 界⾯测试
- 外观是否美观
- 笔壳上的标签是否容易脱落
- 笔壳上的字是否有笔相关的信息提示
- 笔壳上的字是否容易消失
- 功能测试
- 能否写字
- 书写是否流畅
- 携带是否漏⽔
- 笔盖能否正常拔卡,合上
- 笔尖的粗细对书写产⽣的影响
- 写的字,遇⽔是否会晕开
- 书写的字是否是速⼲的
- 书写的字是否是可擦的
- 在特殊的情况下,书写是否有影响,⽐如:⾼温,低温,⼲燥的书写介质,湿润的书写介质,⻓期不盖笔盖,对书写是否有影响,摔下是否能够正常使⽤。
- 易⽤性
- 是否便携
- 是否⽅便替换笔芯
- 笔外壳是否有塑胶圈,减少磨损使⽤者⼿
- 书写是否流畅
- 兼容性测试
- 是否可以装不同类型的笔芯,⽐如不同⼤⼩,不同⼚家
- 是否可以替换不同粗细的笔尖
- 是否可以在不同介质上书写
- 笔的尺⼨⼤⼩是否满⾜不同⼈群的要求
- 笔芯的颜⾊是否满⾜不同场合的要求
- 性能测试
- 可写字数上限
- 书写的字可以保存多⻓时间不褪⾊
- 笔尖在多⼤压⼒下会出墨
- 笔尖在多⼤压⼒下会损坏
- 笔壳在多⼤压⼒下会损耗
- 安全性
- 笔外壳材质的安全性
- 笔芯是否含有毒物质
- 笔芯过了保质期,是否会产⽣有毒物质
- 零件是否易拆解,容 易被⼩孩、⽼⼈误⻝
- 笔尖是否尖锐,容易伤⼈
如何测试⽀付业务
面试题目
- 级别: L1
- 知识模块: 测试用例设计
如何测试⽀付业务
公司
- 小米
招聘类型
社招
题目解析
测试支付接口需要考虑支付流程、异常情况处理、安全性等方面,编写详细的测试用例
答案
基于之前项⽬中做⽀付场景,当时测试的时候分成两种⽅式进⾏测试。由于我们的⽀付渠道:微信、⽀付 宝、银⾏任意选,没有开通测试接⼝,只能进⾏真实⽀付。
所以采⽤的第⼀种⽅式:在确认订单后修改订单⾦额为 1 分钱,测试⽀付成功后的跳转。其它异常情况正常测试即可:如余额不⾜、密码错误等。
基于接⼝测试层⾯,采⽤ mock 模拟接⼝的⽅式,模拟银⾏各种异常返回,检查我们系统对应响应处理是否正确即可。
优酷 app 的推送消息功能测试用例设计?
面试题目
- 级别: L1
- 知识模块: 测试用例设计
优酷 app 的推送消息功能测试用例设计?
公司
- 优酷外包
招聘类型
社招
题目解析
推送消息功能测试用例设计需要考虑消息推送的触发条件、推送内容、展示形式、点击跳转等多方面,覆盖各种场景和异常情况。
答案
优酷 app 的推送消息功能测试用例设计需考虑消息触发条件、内容、展示形式、点击跳转等,覆盖各种场景和异常情况,确保功能稳定可靠。
设计搜索功能测试用例?
面试题目
- 级别: L1
- 知识模块: 测试用例设计
设计搜索功能测试用例?这个输入框里面输什么是应该没有结果的。
公司
- 快手外包
招聘类型
社招
题目解析
这道题目主要考察面试者对搜索功能测试用例设计的能力和思维逻辑。
答案
输入框中输入一个不存在的关键字(如“&^%$!@”或随机生成的字符序列)应该没有结果。测试用例包括:输入不存在的商品名称、特定的特殊字符组合、空格、超长字符串等,验证系统正确返回“无结果”的提示,并且界面显示正常。
⽀付功能的测试点是什么
面试题目
- 级别: L1
- 知识模块: 测试用例设计
⽀付功能的测试点是什么?
公司
- 小米
招聘类型
社招
题目解析
测试支付接口需要考虑支付流程、异常情况处理、安全性等方面,编写详细的测试用例
答案
- 功能:
- ⽀付成功:
- 货到付款
- 银联⽀付(已绑卡、未绑卡)
- 财付通、⽀付宝、微信
- 不同商品合并显示总价⽀付
- ⽀付时获取最新价格进⾏⽀付
- 密码错误后再次输⼊正确密码⽀付
- 其他⽀付失败后重新选择⽀付
- ⽀付⾦额为 0.01
- 提交订单以后,接近 30 分钟时再次发起⽀付
- ⽀付失败:
- 密码输⼊错误
- 余额不⾜
- 微信使⽤不⼀致 APP 扫码
- ⽀付宝使⽤不⼀致 APP 扫码
- 扫码⽀付时取消
- ⽹络故障
- 账号被锁定
- 重复⽀付
- 倒计时 30 分钟后⽀付
- ⾦额 0
- 超过两位⼩数
- ⽀付成功:
- ⾮功能:UI 界⾯(⽕狐,欧朋,IE,⾕歌,苹果)、兼容性、易⽤性
手机投到平板上,手机连接框架的用例,一个框架调用一个框架测试用例
面试题目
- 级别: L1
- 知识模块: 测试用例设计
手机投到平板上,手机连接框架的用例,一个框架调用一个框架测试用例
公司
- 小米
招聘类型
社招
题目解析
测试手机投屏到平板并连接框架时,需要考虑设备间兼容性、传输稳定性、界面显示等方面
答案
手机投到平板上的过程涉及将手机屏幕内容投射到平板显示上,这通常通过无线技术(如 Miracast)或有线连接实现。在测试用例中,我们需要验证以下内容:
- 连接稳定性:测试手机与平板的连接是否稳定,避免出现断连或延迟。
- 显示效果:确保投射到平板上的内容与手机屏幕显示一致,包括分辨率、颜色和图像质量。
- 互动响应:测试在平板上进行的操作是否能够实时反映到手机上,包括触摸和手势操作。
- 框架兼容性:验证不同操作系统和设备之间的兼容性,确保框架在不同环境下正常工作。
测试用例通常会包括对这些功能的详细测试,以确保手机和平板之间的投屏过程无缝且可靠。
微信聊天文本的测试功能点
面试题目
- 级别: L1
- 知识模块: 测试用例设计
微信聊天文本的测试功能点
公司
- metaAPP
招聘类型
社招
题目解析
文本发送、接收、撤回、表情发送、链接点击等都是测试的功能点。
答案
微信聊天文本的测试功能点包括:
- 文本发送与接收:验证用户发送的文本消息能正确传输到对方并在聊天窗口中显示。
- 文本显示:确保消息内容在聊天窗口中显示正确,包括文本格式(如换行、表情、特殊字符)。
- 消息顺序:检查聊天记录中的消息顺序是否按照发送时间正确排列。
- 消息编辑与撤回:测试用户编辑或撤回已发送消息的功能,确保操作后消息内容更新或消失正确。
- 消息通知:验证收到新消息时,系统通知(如弹出通知、声音提醒)是否正常工作。
- 多设备同步:确保在不同设备上(如手机和电脑)查看聊天记录时,消息内容保持一致。
- 消息搜索:测试聊天记录中的文本搜索功能,确保用户能够通过关键词找到相关消息。
- 文字输入与编辑:检查输入框对不同输入法的支持和文字编辑功能是否正常,包括复制、粘贴和删除操作。
如果有一个页面特别卡顿,设想一下可能的原因
面试题目
- 级别: L1
- 知识模块: 测试用例设计
如果有一个页面特别卡顿,设想一下可能的原因?
公司
- 某金融公司
招聘类型
- 社招
题目解析
这类问题通常涉及性能分析和优化,是前端开发和测试中的一个常见问题。
主要原因和解析:
- 代码效率低下:页面上可能存在未优化的代码,如冗长的 JavaScript 逻辑、过多的 DOM 操作等,这些都会拖慢渲染速度。
- 资源过多或未优化:包括加载的图片、视频、CSS 和 JavaScript 文件等,如果这些资源体积过大或未压缩,会影响加载速度和性能。
- 网络延迟:如果页面依赖的资源需要从远程服务器加载,网络延迟或带宽不足会导致页面加载缓慢。
- 服务器性能不足:服务器响应时间过长或负载过高,会使页面加载速度受到影响。
- 前端性能瓶颈:浏览器的渲染性能可能成为瓶颈,尤其是在动画、特效或复杂的布局情况下。
解决思路:
针对不同原因,可以采取相应的优化措施,如代码优化、资源压缩、使用 CDN 加速、优化服务器性能和提高前端渲染效率等。对页面进行性能监控和分析也是必要的,以准确定位并解决问题。
答案
页面特别卡顿的可能原因包括:代码效率低下、资源过多或未优化(如图片、脚本等)、网络延迟、服务器性能不足或前端性能瓶颈。
如何保障测试⽤例的覆盖率
面试题目
- 级别: L1
- 知识模块: 测试用例设计
如何保障测试⽤例的覆盖率?
公司
- 小米
招聘类型
- 社招
题目解析
面试官主要考察内容为:
- 测试用例设计能力:如何设计测试用例能保证功能和需求都进行了测试(各种测试用例设计的方法掌握情况)
- 大局观覆盖场景是否全面:如测试支付接口需要考虑支付流程、异常情况处理、安全性等方面
- 用例的管理和追踪能力
- 能够根据项目重要性划分优先级
解题思路:
- 讲述自己设计测试用例的依据(熟悉项目、需求文档)
- 设计测试用例采用的方法
- 设计用例覆盖的场景
- 自己如何对测试用例进行管理
- 后续的用例处理流程
答案
- 需求分析:编写测试用例前,熟悉项目并分析需求文档,使用 XMind 进行测试点拆解,确保对需求的充分理解,并与产品和开发保持一致,明确显性和隐性需求。
- 设计测试用例:采用判定表、等价类、边界值、流程图等方法,确保测试用例的有效性。
- 覆盖度分析:根据项目场景从多个维度分析用例覆盖度,如测试支付接口需考虑支付流程、异常情况处理和安全性,编写详细用例。
- 缺陷管理:使用平台跟踪管理缺陷,确保需求和功能覆盖,生成测试报告识别覆盖率不足区域。
- 用例评审:定期组织用例评审,确保用例有效性和完整性,及时根据需求和功能变化更新用例,保证覆盖度。
- 风险分析和优先级:根据风险分析结果,重点关注高风险区域的测试覆盖,对低风险区域保证基本功能正常。
如何执⾏的兼容性测试
面试题目
- 级别: L1
- 知识模块: 测试用例设计
如何执⾏的兼容性测试
公司
- 小米
招聘类型
社招
题目解析
兼容性测试旨在验证软件在各种硬件、操作系统、浏览器和其他软件环境中的表现是否一致,确保用户无论使用何种平台都能获得良好的体验。
通过兼容性测试,能够发现并解决在不同环境下的软件问题,确保用户在各种平台上都能顺利使用软件,从而提升用户体验和软件的市场接受度。
答案
通过在多种设备、操作系统、浏览器和网络环境下测试软件,确保其在不同平台上表现一致并符合预期。
Web 兼容性测试
- ⾸先开展⼈⼯测试,测试⼯程师测试主流浏览器和常⽤操作系统测试主流程和主界⾯,看看主流程和主界⾯是否有问题,如果存在问题,那么记录下 bug 情况,以及浏览器型号和版本,以及操作系统,准确定位 bug 产⽣的原因,提交 bug,告知开发⼈员修改。
- 所有的主流设备都需要进⾏测试,只关注主流程和主界⾯,毕竟每个系统主流程和主界⾯不是很多,所以这个⼯作量还是可以承受的。
APP 兼容性测试
- APP 的兼容性测试和 Web 测试类似,⾸先开展⼈⼯测试,测试⼯程师借助测试设备对主流程和主功能,主界⾯进⾏测试;收集所有的能收集到的不同型号的测试设备测试主流程和主界⾯,看看主流程和主界⾯ 是否有问题,如果存在问题,综合考虑设备的使⽤率等因素,看看是否需要调整,如果需要,那么记录下 bug 情况以及测试设备的型号和操作系统,准确定位 bug 产⽣的原因,提交 bug,告知开发⼈员修改。
- 其次借助第三⽅测试⼯具,对于 APP 的兼容性测试,推荐的是百度众测平台和云测平台,我经常使⽤的是云测平台,这两款测试⼯具⾥⾯包含了安卓和 iOS 的测试;测试很⻬全,包括功能测试、深度兼容测试、性能测试、⽹络环境测试,还可以模拟海量⽤户测试,还可以导⼊⾃⼰编写的测试⽤例进⾏功能测试,⾥⾯还包括测试专家的测试,当然了找专家是要花钱滴。基本进⾏兼容性测试是不需要花钱的;测试⼯程师把打包好的 apk 或者 ipa ⽂件,上传到测试平台,选择需要测试的设备型号,开始任务即可;等待⼀段时间,在等待的时间你是不需要盯着的,你可以做其他的⼯作。测试完成后会⽣成⼀份测试报告,可以查看错误⻚⾯和错误⽇志,如果需要调整,那么提交 bug,告知程序员修改即可。
商品异常,库存没有了,无法购买,过期商品这些异常情况会在测试环境构造吗?
面试题目
- 级别: L1
- 知识模块: 测试用例设计
商品异常,库存没有了,无法购买,过期商品这些异常情况会在测试环境构造吗?
公司
- 优酷外包
招聘类型
社招
题目解析
在测试环境构造商品异常情况可以帮助发现潜在问题,但要注意不要影响正常业务。可以通过特定操作或配置来模拟这些异常情况。
答案
是的,我们会在测试环境构造商品异常情况,以便发现潜在问题,但需注意不要影响正常业务。可以通过特定操作或配置来模拟这些异常情况。
- 库存没有了:通过设置商品的库存为零或负值,测试系统是否能够正确识别并阻止用户进行购买,验证库存管理和前端提示功能。
- 无法购买:模拟用户在购买时遇到的各种问题(如网络中断、系统故障),确保系统能正确处理错误情况,并提供用户友好的提示。
- 过期商品:设置商品的过期时间,测试系统是否能够在商品过期后禁用购买功能,并确保过期商品不再出现在可购买列表中。
git
面试题目
- 级别: L1
-
知识模块: git
-
git 经常用的几个命令,怎么切分支,怎么解决冲突?请详细说明
公司
- 某金融公司
招聘类型
- 社招
- 校招
题目解析
面试官主要考察内容为:
- Git 基本操作熟练度
- 版本控制和分支管理能力
- 解决问题的能力
解题思路:
- 从克隆仓库开始,讲述整个 git 管理的流程以及用到的常用命令。
- 再阐述如何处理分支冲突
答案
常用命令
- 克隆项目
git clone 仓库名称
- 拉取代码
git pull
- 切出新分支
git checkout -b 分支名称
- 切换分支
git checkout 分支名称
- 提交代码
git add 被添加代码
git commit -m "提交记录信息"
# 合并远程主分支
git pull origin main
git push
解决冲突
- 在 push 代码之前,先拉取主分支代码,并进行 merge。
- 如果产生冲,那么通过 IDE 或者手动操作,解决冲突后再重新提交到自己分支。
- 成功提交到个人分支后。再通过 MR 合入主分支。