字节软件测试岗二面：APP测试问题被虐哭了，直到看到这些知识点

本文链接：https://blog.csdn.net/AI_Green/article/details/119765317

APP测试一直是大厂软件测试问到的一个重点细节，下面我来给大家展示一下大厂关于APP测试经常会问到的一些问题，以及解析。想象一下当你遇到面试官问到你这些问题时，你是否也能够对答如流哦！

字节软件测试岗二面：APP测试问题被虐哭了，直到看到这些知识点

注意，注意啦！小编花了几天时间总结出了web 测试，接口测试，App 测试，管理工具，等等核心知识点。需要的朋友可以在公众号：【伤心的辣条】获取软件测试学习核心知识点。无偿喔！

字节软件测试岗二面：APP测试问题被虐哭了，直到看到这些知识点

APP测试面试真题及解析：

手机app兼容性测试：主要是针对android各个系统版本进行测试，及测试屏幕分辨率进行测试；
说说会用哪些抓包工具？怎么用的？
解析：比如fiddler，主要用来做app抓包使用，先在fiddler客户端做好各项配置，端口设置为8888，然后在手机上设置代理，就可以抓包了，主要看的是服务器返回的值、还能够修改传入参数、传出的参数、模拟网络延时，去构造不同场景。
什么是alpha测试和beta测试？
解析：alpha测试：在公司场地，由员工主导的测试行为；beta测试：在客户场地，由客户主导进行的测试。
简单介绍一下Android SDK中自带的几个工具/命令的功能？
解析：ddms：Dalvik Debug Monitor Service，是 Android 开发环境中的Dalvik[虚拟机]调试监控服务。
monkey：Android中的一个命令行工具，可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。
uiautomator：UIAutomator是Eclipse自带的用于UI自动化测试工具，可仿真APP上的单击、滑动、输入文本等操作。
monitor：同uiautomator
adb：ADB的全称为Android Debug Bridge，就是起到调试桥的作用。通过ADB我们可以在Eclipse中方面通过DDMS来调试Android程序，就是debug工具。

二，以京东首页为例，设计用例框架。（注意框架设计逻辑，区域划分，专看项测试等，不需要详细用例，需要查看 PC 可直接和辨识管提要求）

字节软件测试岗二面：APP测试问题被虐哭了，直到看到这些知识点

三，如何测试购买下单和退货流程

产品经理设计了单品优惠，组合优惠，订单优惠，优惠券优惠（优惠券优惠包含通用券，定向券，满减券，折扣券）和礼品卡，其中礼品卡上需要单独购买的。请问如何测试购买下单和退货流程，需要注意什么？（包含数据存储）

四，什么是 sql 注入，什么是XSS跨站脚本攻击，什么是跨站请求伪造？

1、SQL注入

原理:SQL注入就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。SQL注入漏洞到底是以怎样的形式进行攻击的呢，接下来将以一个简单的实例来进行介绍。

比如在一个登陆界面，有两个文本框分别用来输入用户名和密码，当用户点了登录按钮的时候，会对输入的用户名和密码进行验证。
字节软件测试岗二面：APP测试问题被虐哭了，直到看到这些知识点

2、XSS跨站脚本攻击

原理：XSS(Cross Site Scripting)跨站脚本攻击指攻击者在网页中嵌入客户端脚本(例如JavaScript)，当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的，比如获取用户的Cookie，导航到恶意网站，携带木马等。

向网页中注入恶意脚本在用户浏览网页时在用户浏览器中执行恶意脚本的攻击方式。跨站脚本攻击分有两种形式：反射型攻击（诱使用户点击一个嵌入恶意脚本的链接以达到攻击的目标，目前有很多攻击者利用论坛、微博发布含有恶意脚本的 URL 就属于这种方式）持久型攻击（将恶意脚本提交到被攻击网站的数据库中，用户浏览网页时，恶意脚本从数据库中被加载到页面执行，QQ 邮箱的早期版本就曾经被利用作为持久型跨站脚本攻击的平台）。

3、跨站点请求伪造

原理：CSRF（ Cross-site request forgery ）尽管听起来很像XSS跨站脚本攻击，但是它于XSS完全不同。XSS是利用站点内的信任用户，而CSRF则是通过伪装来自受信任用户的请求来利用受信任的站点，从而在并未授权的情况下执行在权限保护之下的操作。与XSS相比，CSRF攻击不大流行和难以防范，所以比XSS更具危险性。

CSRF 攻击是攻击者通过跨站请求，以合法的用户身份进行非法操作（如转账或发帖等）。CSRF 的原理是利用浏览器的 Cookie 或服务器的 Session，盗取用户身份，防范 CSRF 的主要手段是识别请求者的身份。

五，给你一个网站怎么开展测试？

1、首先，查找需求说明、网站设计 m 等相关文档，分析测试需求。

2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

3、设计测试用例：功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。

4、提交功能的测试

多媒体元素是否可以正确加载和显示。

多语言支持是否能够正确显示选择的语言等。

5、界面测试可以包括但不限于以下几个方面：

页面是否风格统一，美观；页面布局是否合理，重点内容和热点内容是否突出；控件是否正常使用；对于必须但为安装的空间，是否提供自动下载并安装的功能;文字检查

6、性能测试一般从以下两个方面考虑：

压力测试；负载测试；强度测试

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。

7、安全性测试：

1 基本的登录功能的检查 2 是否存在溢出错误，导致系统崩溃或者权限泄露 3 相关开发语言的常见安全性问题检查，例如 SQL 注入等。4 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持

8、兼容性测试

根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性

9、开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。

六，电商支付模块的测试如何展开？

先看下流程图，是否对流程图有些了解，不仅仅是做支付功能相关测试才去搞清楚其中的流程，做其他的测试一样也要搞清楚流程，只有搞清楚流程，才能更好的评估其中的风险，才能有利于测试用例的设计。当然流程图中只是提到了商户与第三方是如何交互的，同样商户内部处理的流程也要有所了解及数据怎么存储的，涉及到哪些DB也要清楚。

字节软件测试岗二面：APP测试问题被虐哭了，直到看到这些知识点

这个支付流程图里面就涉及到了第三方支付接口：

下单接口：商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。（下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结果。）

支付接口：调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台通知交互模式。（结果分为两路返回：一路为前台在return_url页面跳转显示支付结果；一路为后台在notify_url收到支付结果通知后进行响应。）

退款接口：调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起退款处理。（退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查询结果。）

单笔订单查询接口：根据订单号查询单笔订单信息和状态。

退款订单查询接口：调用第三方支付的退款接口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。

测试过程中需要注意的主要测试点及异常场景：

首先要保证接口都能正常调用；

生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；

生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付

生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币

异步通知屏蔽，同步有效，进行支付，同步能够正常到账

同步设置无效，异步有效，进行支付，异步能够正常到账

同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，一般有时间或次数的限制）

针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号–方便与第三方对账和问题排查、订单金额、订单状态等）

如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性

如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证