标签：软测 答案 用例 APP 接口 面试 测试 自动化 性能

一.软件热身题

第一印象，相对比较重要，考察软能力，比如表达能力，理解能力，协调能力

1.自我介绍
我叫，，，18年毕业于，从事软件测试两年，擅长接口测试，熟练使用python，sql，了解java，linux
2.介绍下你负责的公司项目

• 智能测试系统，把所有的测试用具进行线上管理，产生的数据进行分析处理，把主要的数据呈现出来，以供测试的优化。系统分为13个模块，我做的部分为治具管理，机台管理，程式管理，备品管理
• 现公司：互联网金融业务、银行核心、理财、保险

3.你有什么优点和缺点？

• 优势：分析能力较强，对业务的需求分析比较透彻，业务熟悉度和测试功底比较扎实，执行力、推动力、沟通协作能力比较强

4.在同一个项目组内，你认为你怎么做会比另外一名测试更加优秀？

• 业务熟悉度更高, 架构理解更深入, 代码能力要更好, 协调推动能力更强

5.你为什么离开上家公司？离职原因（这个会在最后问）
多经历一些，多进步一些，离家近一些

二.测试理论基础

基本能力，会的再多也不过分，不扎实的话就会拉低评价，毕竟大家都会，不会的话不算是一个合格的测试工程师了，不会问太多，但是大众化的要了解。

1.描述下你上个公司的测试流程？

• 需求评审
• 编写测试用例
• 评审测试用例
• 发起case评审，提供准入测试用例给开发
• 提测后先进行准入测试，不通过打回，通过则进入story测试，集成测试，系统测试，性能测试，稳定性测试，安全测试，（uat：客户在测试环境验收），生产验证，发布

2.请描述下bug的几个要素？

• 标题，前提条件、测试环境、操作步骤、预期结果、实际结果、严重等级、版本信息，出现概率，必要时附上截图、视频、日志等

3.白盒和黑盒的区别，你是怎么运用的？

• 白盒是从代码层进行测试，黑盒是对业务层进行测试。 白盒可以从单元测试、代码review、架构方面入手。
• 内部实现逻辑可以看代码，也可以请开发讲给你听，知道了怎么实现，能在设计用例时构造不同数据cover逻辑覆盖

4.你是如何做测试分析？

• 
• 如果是分析并制定测试内容，首先会根据需求文档，了解功能交互和规则，再去和开发讨论实现原理，通过交互和原理两个纬度进行分析，并确定测试内容。
• 如果是测试问题分析，出现问题后，首先会抓包，看看是后端返回的问题，还是前端代码或者请求的问题，如果后端涉及多个子系统，可以通过查看日志的方式看看具体是环境问题还是后端哪个子系统的问题。

5.如何设计测试用例？什么样子的测试用例是好用例？

• 需求分析，架构理解，覆盖功能、性能、安全等维度
• 功能拆解：aa的环境，bb的界面，用了cc的工具，做了dd的操作，达到了ee的效果
• 计用例原则上好的用例各有千秋（不外乎边界值，等价类，流程图，正交法，判定表等

6.功能测试在 beta 版本对外的上线标准是什么？

功能上线标准每个公司不一样，大致如下：

• 1.所有功能点(需求)都被用例覆盖到了
• 2.所有用例执行过至少一遍
• 3.所有发现的bug被修复并验证，做过regression了。
• 4.不能修复的记录了/关闭了/known issue了。
• 5.bug曲线区域平稳了

功能指标：

• Bug通过率 >＝95%
• 严重级别bug通过率＝100%
• case通过率 >＝95%
• p0和p1级别case通过率100%
• 自动化工具通过率达到标准
• 接口、安全、兼容、性能、稳定性达到要求
• 产品验收通过

三.测试管理题

1.如果项目周期很短，测试人力匮乏，你是怎么协调的？

• 依据代码review的结果和影响范围，对测试内容进行适当的裁剪。
• 借助自动化工具的支持，提高测试案例的执行效率。
• 调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。
• 必要的情况下加班

2.描述下你团队的测试分工

测试技术组和业务测试组：

• 测试技术组主要进行工具考研、工具开发和工具维护，为业务测试效率提升和基础建设做支撑。
• 业务测试组主要进行具体业务测试和工具的落地使用，具体测试内容覆盖功能、性能、兼容、稳定性、接口等

3.对于团队成员，你是如何打kpi的？

• 一方面制定KPI的时候根据团队成员的职级和能力进行区分，制定合理且细化明确的指标，指标包含测试质量保证、测试效率提升、自动化事务、培训分享。
• 进行KPI考核的时候一方面依据KPI的指标达成度、达成时效打分，另一方面不在 KPI内的创新型事务会作为加分项。

四.移动测试相关

移动端的天下，一般都会问到

概念题：

1.描述下web测试和移动应用测试的相同点和区别？

• Web 测试和移动应用测试的共同点在于：都要覆盖接口、功能、兼容、性能、稳定和安全的测试。
• 差异点在于：兼容考虑的范围不一样，web重在PC系统和浏览器。移动重在机型分辨率和系统版本。 另外移动用户要考虑手机特性相关的影响，网络、冲突、耗电和流量。

2.你是如何做应用的兼容性测试的？

• 硬件兼容：机型、分辨率、系统、版本、网络
• 软件兼容：输入法键盘、相机、安全清理工具类
• 数据兼容：低升高、高降低的用户信息和数据的兼容，还有跨平台的数据兼容

3.请讲出客户端下 3 个常用的性能指标的名称与具体含义？

• cpu利用率
• 内存使用率
• 并发量：多个用户同时调用单个接口的相应时效
• 响应时间：用户从客户端发出请求，并得到响应，以及展示出来
• 加载速度：通俗的理解为页面内容显示的快慢。
• 电量：APP的耗电量。
• 流量：APP所消耗的流量

4.iOS应用和Android应用测试有什么侧重点？

• android运行基于虚拟机，ios则是沙盒机制
• android是真后台，ios是伪后台，所以安卓才会卡
• 分辨率：iOS 覆盖的分辨率和系统是有限的。
• 兼容性：Android 比较碎片化，覆盖的机型版本比iOS 更多android有各种定制rom，手机型号太多。
• 权限：安卓还要特别考虑权限，6.0是分水岭
• 应用安装渠道：安卓比较多

5.请讲述移动应用的灰度是怎么做的？

• 内部二维码下载
• 白名单用户方式
• 国内小市场先上，国外用 Google Play的 β版，默认开放5%
• 后台控制的方式，开放给一定比例的用户

实践题：

1.应用的闪退通常是什么原因造成的？如果应用闪退，Android 和 iOS 上是分别怎么抓取日志的？

• 内存超载
• 后端服务或动态链接库未找到
• 应用初始化时无法正确读取到用户数据
• 系统兼容问题

日志抓取：ios

• 通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash日志
• 通过Xcode从你的设备上获得崩溃日志
• 自己在程序中添加崩溃捕捉代码，如果应用集成第三方SDK，如百度统计

Android：

• 通过集成第三方SDK，如百度统计、友盟统计等
• 发版时使用加固工具，他们也会收集错误日志，如360加固
• 在程序中添加程序异常崩溃的捕捉代码，保存到本地文件中

2.请简述移动应用在升级安装时候应该考虑的场景？

• APP有新版本时，打开APP是否有更新提示。
• 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
• 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
• 不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。
• 删除老的APP，重新下载APP，能不能正常工作。
• 不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
• 检查在线跨版本升级能否成功，版本过老是否提示用户重装。
• 更新成功后，用户数据有没有丢失，各个配置项是否还原。

3.给你一个应用，请简述你会从哪些方面去测试？

• UI
  • 页面布局设计是否和产品原型一一致
  • 页面文案是否正确
• 功能
  • 正向功能验证
  • 单个功能项验证
  • 交互验证
  • 接口验证
• 性能
  • 服务端的性能
  • APP客户端性能
• 安全
  • 注入攻击
  • 加密
  • 权限
• 兼容
  • app：平台，厂商，系统版本，分辨率
  • web：浏览器，分辨率
  • 关注内容：页面展示正确，功能正确
• 易用
  • 功能操作是否简单
  • 页面布局是否合理
  • 提示语相关信息是否容易理解
• app要点：
  • 网络
  • 中断
  • 系统权限
• web要点：
  • 链接测试
  • 多个浏览器同时访问

4.请描述下微信朋友圈发小视频的用例设计？

• 功能：

入口图标的标识度

进入和退出操作简易度

取景框大小

拍景和自拍切换

视频的像素限制

视频的时长限制

发送的进度提示

• 性能：

发送的时间

操作是否卡顿

• 兼容：

不同机型分辨率

不同系统版本

不同网络情况

不同流量情况

5.如果让你来测试扫码支付，你会考虑哪些场景？

• 卡的类型（一类户：借记卡、信用卡、各个开户行）
• 二类户：虚拟账户如微信里的零钱账户、支付宝的余额宝、电子账户
• 二维码的商户类型（微信、支付宝、汇宜、银联）
• 支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）
• 退款（退款入口、退款进度、退款结果）
• 对账：资金流动（我方扣款数额正确，对方收款数额正确）数额及时效
• 支付结果展示、交易明细
• 支付接口安全性、接口的性能
• 异常情况（卡异常、余额不足）
• 连续扫码支付，每天的扫码支付次数限制及数额限制
• 二维码有效期
• 有无相机权限
• 前后置摄像头
• 像素低端的手机能否扫码成功
• 兼容性（不同手机厂商自带相机功能实现不一致）

6.如何测试一个应用的登录场景

• 性能：响应时间、并发量
• 安全性：加密传输
• 各种登录方式优先级
• 不同设备之间切换登录方式
• 登录的有效时长

服务端测试：

1.请问你们公司是如何做接口测试的？

• 接口规范拿到
• 设计接口测试用例
• 发送的数据格式
• 返回的数据格式
• 了解接口实现逻辑，实现逻辑覆盖
• 接口能并发执行吗：采用工具或者自写代码来验证，HTTP接口一般SoapUI， Jmeter， Fiddler， Postman等都能验证，自己写更好。web service接口一般要写代码来调用。根据测试用例自动化
• 发现问题跟功能测试一样，该报bug报bug，该跟踪状态跟踪状态

2.接口测试质量评估标准是什么？

• 接口表现与接口文档的一致性
• 请求参数：必选和非必选、长度、字符类型、为空、缺失、组合、重复
• 返回参数：正常和异常
• 性能，1000以内并发时小于3s

3.请问你们公司是如何做性能测试的？请讲诉性能测试的相关指标？

• 拿到测试需求，确定测试软硬件环境/测试指标

• 使用测试工具(Loadrunner, jmeter)录制或者编写测试代码，逐步加压，直到测试目的达成

• 调优（一般都是开发的事）

  相关指标：

• 服务器系统资源方面 CPU占用率，内存占用率 磁盘的读写指标

• 网络的占用情况 基础吞吐率

• 事务处理速度 如平均登录时间，操作平均响应时间等

4.压力测试和负载测试的区别

• 一个（压力测试）扔给你指定数目稻草，看你有没有问题；一个（负载测试）是按一定量给你身上加草，直到试出你的最大极限，把最后一根草给你压死了，那你的最大负载就是这一根草之前的量。
• 压力测试是在高负载情况下对系统的稳定性进行测试。是在高负载（大数据量、大量并发用户等）下的测试，观察系统在峰值使用情况下的表现，从而发现系统的功能隐患。
• 负载测试：多用户，用户数渐增，持续同时发同一业务请求，产出最大TPS
• 压力测试：多用户，资源使用饱和，持续同时发同一业务请求，产出系统瓶颈或使用极限

5.服务器中一般要监控哪些数据，如何监控的，怎么从监控数据中发现问题？

• CPU， 内存， 网络， I/O， 数据库。等等。 一般用工具监控，另外Windows上有性能监视器
• 基础监控和应用监控。基础监控包括机器是否死机，cpu，内存，磁盘使用率等
• 应用监控包括日志监控、端口监控、进程数监控等

发现问题：

• 一般要关注阈值，比如CPU利用率超过85%，说明server压力太大了

6.假设系统A调用系统B，我把B的接口都mock了，进行性能测试，这样有什么好处和坏处？

• 好处是去掉的依赖，可以在B没有好之前测试A，并且B的任何改动/错误/失效不会影响我测试A
• 坏处是真实性能要比测出来的性能差， 性能指标不准确。 因为Mock的服务再真也不能代替真实服务

7.有一天早上打车高峰，滴滴服务端挂了大概30分钟，工程师抢修之后，马上上线，之后又挂了，请问有哪些原因会造成这个情况？

• 还是考测试思维， 一定记得先确认需求，再定性，定量。 一般都要反问， 服务器是哪个服务器？后端应用服务器？数据服务器？缓存系统服务器？中间件服务器？文件系统服务器？
• 不说就自己假定一个， 然后第一次挂第二次挂分开说，先问有没有错误码，日志有吗，有就看日志，没有就猜 是应用服务器挂了啊，是不是高峰期顶不住这么大并发访问啊？是数据库服务器啊，是不是频繁读写受不了啊，读写有分开吗？同步还是异步啊
• 第二次挂，可能更多了，是不是代码弄错了，改坏了
• 服务器内存不够
• 服务器超出负载
• 并发量太大
• 遇到恶意攻击

五.自动化相关

加分项，这一块包括，自动化一些理念和自动化的工具使用

理念和概念：

1.如何看待自动化和手动测试？怎样的一个比例才是健康的？

• 项目较成熟时自动化比例可适当提高。开发并维护自动化case成本较高，所以不是自动化比例越高越好。要根据具体的项目及项目所处的阶段来定。投入产出比要先评估好。

2.你们公司的自动化投入产出比怎样？效益怎样？

• 自动化和业务测试人力1:5
• 自动化测试发现新bug的效益很低，主要用在回归测试上，减少测试工作量。接口测试可就不一样了，可以小步快跑，也可以集团作战。

3.自动化测试用例的覆盖率多少？

• 拿金融产品的自动化来讲，大概覆盖33%左右

4.完整运行一次自动化用例需要多久时间？

• Google说它们分钟级或者秒级别， 为毛我们都是小时级别

5.什么是分层自动化？

• 金字塔结构， 最底层UnitTest，往上接口API/集成起来的service， 最上面UI自动化

6.你的测试数据是怎么准备的？

• 写在脚本里/外部文件（excel， XML）/数据库， 逼格逐级提升

7.测试脚本的维护成本是怎么样的？

• 不坏就不要修
• 终身追责，谁污染谁治理

8.工具使用

9.接口自动化时上一次执行的数据如何清理掉？（如开户或注册，同一个账号只能使用一次，如何清洗数据能让case下次继续跑？提供新的数据？mock？mock的层级，mock过多的话等同于未做测试）

WebDriver 相关：

1.请问你的定位策略是什么？

• ID， Clas， CSS， XPath， jquery脚本， 总之能不麻烦开发就不麻烦开发

2.请问如何实现用例失败或者异常时候需要截图？

• 框架自带， python+webdriver里是get_screenshot_as_file，
  一般写一个装饰器，放在要执行的类上，try， catch下

3.请问如何分布式执行webdriver用例？

两种策略：

• 1.利用Jenkins等，部署部分代码到多个机器上执行
• 2.RemoteWebDriver

4.如何在脚本中执行 JavaScript 代码？

• driver.execute_scripts(‘脚本’)

移动应用相关：

1.Appium 的定位策略有哪些？

• driver.find_element_by_id() –元素的 resrouce-id 属性
• driver.find_element_by_AccessibilityId() – content-desc属性，替代以前的name。
• driver.find_element_by_xpath() –比css定位慢
• driver.find_element_by_class_name() –元素的 class 属性
• driver.find_element_by_css_selector()
• driver.find_element_by_link_text() –链接元素的全部显示文字
• driver.find_element_by_tag_name() –元素的标签名
• driver.find_element_by_partial_link_text() –链接元素的部分显示文字

2.请简述Appium的原理

• Appium是C/S架构的，更像是一个proxy，连接其被测移动平台和测试脚本。
• appium是基于 webdriver 协议添加对移动设备自化api扩展而成的。

3.iOS 和 Android 的 UI 自动化的原理是什么？

• iOS 9.3 and above: Apple’s XCUITest
• iOS 9.3 and lower: Apple’s UIAutomation
• Android 4.2+: Google’s UiAutomator/UiAutomator2
• Android 2.3+: Google’s Instrumentation. (Instrumentation support is provided by bundling a separate project, Selendroid)

4.当定位策略都失败的时候，你该怎么做？

• 80%是你元素定位的不对
• 那么多定位方法，一个不行换另外一个
• 直接不能定位，先定位父元素，再循环找子元素。
• 一般来说XPATH都能定位到，无非是可阅读性不强。
• 真的全部失效，请求开发帮你改个元素属性好了。

5.请问Monkey测试的优缺点？

6.如果使用monkey发现了一个毕现闪退，请问怎么使用monkey重现它？

Jmeter

1.你用jmeter做什么测试？

• 接口，性能。

2.如果有一个登录接口需要服务端返回参数，再带着这个参数去请求才能完成登录，用jmeter 怎么做

• 可以利用Regular Expression Extractor传参

标签：软测,答案,用例,APP,接口,面试,测试,自动化,性能
来源： https://blog.csdn.net/DAYTOYdxz/article/details/113914566

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。