1 什么是 sql 注入，什么是跨站脚本，什么是跨站请求伪造？
SQL 注入攻击是注入攻击最常见的形式（此外还有 OS 注入攻击（Struts 2 的高危漏洞就是通过 OGNL 实施
OS 注入攻击导致的）），当服务器使用请求参数构造 SQL 语句时，恶意的 SQL 被嵌入到 SQL 中交给数据库执行。
SQL 注入攻击需要攻击者对数据库结构有所了解才能进行，攻击者想要获得表结构有多种方式：
（1）如果使用开源系统搭建网站，数据库结构也是公开的（目前有很多现成的系统可以直接搭建论坛，电商网
站，虽然方便快捷但是风险是必须要认真评估的）；
（2）错误回显（如果将服务器的错误信息直接显示在页面上，攻击者可以通过非法参数引发页面错误从而通过
错误信息了解数据库结构，Web 应用应当设置友好的错误页，一方面符合最小惊讶原则，一方面屏蔽掉可能给系统
带来危险的错误回显信息）；
（3）盲注。防范 SQL 注入攻击也可以采用消毒的方式，通过正则表达式对请求参数进行验证，此外，参数绑
定也是很好的手段，这样恶意的 SQL 会被当做 SQL 的参数而不是命令被执行，JDBC 中的 PreparedStatement 就
是支持参数绑定的语句对象，从性能和安全性上都明显优于 Statement。
XSS（CrossSiteScript，跨站脚本攻击）是向网页中注入恶意脚本在用户浏览网页时在用户浏览器中执行恶意
脚本的攻击方式。跨站脚本攻击分有两种形式：
反射型攻击（诱使用户点击一个嵌入恶意脚本的链接以达到攻击的目标，目前有很多攻击者利用论坛、微博发
布含有恶意脚本的 URL 就属于这种方式）
持久型攻击（将恶意脚本提交到被攻击网站的数据库中，用户浏览网页时，恶意脚本从数据库中被加载到页面
执行，QQ 邮箱的早期版本就曾经被利用作为持久型跨站脚本攻击的平台）。
CSRF 攻击（CrossSiteRequestForgery，跨站请求伪造）是攻击者通过跨站请求，以合法的用户身份进行非
法操作（如转账或发帖等）。CSRF 的原理是利用浏览器的 Cookie 或服务器的 Session，盗取用户身份，防范 CSRF 的主要手段是识别请求者的身份，主要有以下几种方式：
1）在表单中添加令牌（token） ；
2）验证码；
3）检查请求头中的 Referer（前面提到防图片盗链接也是用的这种方式）。
令牌和验证都具有一次消费性的特征，因此在原理上一致的，但是验证码是一种糟糕的用户体验，不是必要的
情况下不要轻易使用验证码，目前很多网站的做法是如果在短时间内多次提交一个表单未获得成功后才要求提供验
证码，这样会获得较好的用户体验。
2. 给你一个网站怎么开展测试？
a)首先，查找需求说明、网站设计等相关文档，分析测试需求。
b)制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测，试界面测试，性能测试，数
据库测试，安全性测试，.兼容性测试
c)设计测试用例：
功能性测试可以包括，但不限于以下几个方面：链接测试；链接是否正确跳转，是否存在空页面和无效页
面，是否有不正确的出错信息返回等；提交功能的测试；多媒体元素是否可以正确加载和显示；多语言支
持是否能够正确显示选择的语言等
界面测试可以包括但不限于一下几个方面：页面是否风格统一，美观。页面布局是否合理，重点内容和热
点内容是否突出。控件是否正常使用。对于必须但为安装的空间，是否提供自动下载并安装的功能。文字
检查。
性能测试一般从以下两个方面考虑：压力测试，负载测试，强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证
等方面。
安全性测试：基本的登录功能的检查；是否存在溢出错误，导致系统崩溃或者权限泄露；相关开发语言的
常见安全性问题检查，例如 SQL 注入等；如果需要高级的安全性测试，确定获得专业安全公司的帮助，外
包测试，或者获取支持。
兼容性测试，根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平
台的兼容性；数据库的兼容性。
d)开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求
变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
e)定期评审，对测试进行评估和总结，调整测试的内容。
3. 电商支付模块的测试如何展开？
支付流程里面就涉及到了第三方支付接口：
下单接口：商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。
下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结
生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的
金额对应的游戏币；
异步通知屏蔽，同步有效，进行支付，同步能够正常到账；
同步设置无效，异步有效，进行支付，异步能够正常到账；
同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点
时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收
到了成功的通知，如果第三方支付收到商户应答不是 ok 或超时，第三方支付就会认为通知失败，会在规定
的时间内持续调用 notify_url，一般有时间或次数的限制）；
针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号--方便与第三方对账和问题
排查、订单金额、订单状态等）；
果。）
支付接口：调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台
通知交互模式。（结果分为两路返回：一路为前台在 return_url 页面跳转显示支付结果；一路为后台在
notify_url 收到支付结果通知后进行响应。）
退款接口：调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起
退款处理。（退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查
询结果。）
单笔订单查询接口：根据订单号查询单笔订单信息和状态。退款订单查询接口：调用第三方支付的退款接
口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。
测试过程中需要注意的主要测试点及异常场景：
首先要保证接口都能正常调用；
生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；
生成一笔订单，复制订单号和金额，再次生成一笔订单，用 fiddler 设置断点，用第一笔已完成的订单号和
订单金额去替换现有的订单号和金额，无法完成支付；
如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的
验证以确保安全性；
如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；
4.如何开展兼容性测试？
（1）Web 兼容性测试
(a).首先开展人工测试，测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主界
面是否有问题，如果存在问题，那么记录下 bug 情况，以及浏览器型号和版本，以及操作系统，准确定位
bug 产生的原因，提交 bug，告知开发人员修改。所有的主流设备都需要进行测试，只关注主流程和主界
面，毕竟每个系统主流程和主界面不是很多，所以这个工作量还是可以承受的。
(b).其次借助第三方测试工具，目前我觉得比较好用的第三方 Web 测试工具有 IEtester（离线）、SuperPreview
（离线）和 Browsershots：browsershots.org（在线），一款可以测试 IE 的兼容，一款可以测试主流浏览
器的兼容，包括谷歌、火狐、Opera 等等。借助第三方测试工具，找到 bug 产生的位置，分析测试结果，
告知程序员调整。
（2）APP 兼容性测试
(a).APP 的兼容性测试和 Web 测试类似，首先开展人工测试，测试工程师借助测试设备对主流程和主功能，
主界面进行测试；收集所有的能收集到的不同型号的测试设备测试主流程和主界面，看看主流程和主界面
是否有问题，如果存在问题，综合考虑设备的使用率等因素，看看是否需要调整，如果需要，那么记录下
bug 情况以及测试设备的型号和操作系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。
(b).其次借助第三方测试工具，对于 APP 的兼容性测试，推荐的是百度众测平台和云测平台，我经常使用的是
云测平台，这两款测试工具里面包含了安卓和 iOS 的测试；测试很齐全，包括功能测试、深度兼容测试、
性能测试、网络环境测试，还可以模拟海量用户测试，，还可以导入自己编写的测试用例进行功能测试，里
面还包括测试专家的测试，当然了找专家是要花钱滴。基本进行兼容性测试是不需要花钱的；测试工程师
把打包好的 apk 或者 IPA 文件，上传到测试平台，选择需要测试的设备型号，开始任务即可；等待一段时
间，在等待的时间你是不需要盯着的，你可以做其他的工作。测试完成后会生成一份测试报告，可以查看
错误页面和错误日志，如果需要调整，那么提交 bug，告知程序员修改即可。
5.常用 HTTP 协议调试代理工具有什么？详细说明抓取 HTTPS 协议的设置过 程？
Fiddler 是一个http 协议调试代理工具
打开 Fiddler，进入 Tools-Options-HTTPS，配置允许抓取 HTTPS 连接和解析 HTTPS 流量然后选择要解释的
来源，设置是否忽略服务证书错误（这些操作做完之后，在浏览器方位IP:8888，安装证书就可以在浏览器抓取HTTPS
协议了）
进入 Tools-Options-Connections，保证打开启抓取 HTTPS 连接，然后默认端口按需求是或否需要修改，然后
点选允许远程计算机连接选项
6. APP 测试的内容主要包括哪些，如何开展？
功能测试：
1.业务逻辑正确性测试：依据：产品文档->测试用例编写
兼容性测试：
1.系统版本：Android:官方版本,定制版本;IOS：官方提供版本
2.分辨率：720 *1280 1080*1920
3.网络情况:2g 3g 4g 5g Wi-Fi
异常测试
1.热启动应用:应用在后台长时间待机;应用在后台待机过程中，手机重启
2.网络切换和中断恢复:网络切换;中断恢复：
3.电话信息中断恢复
升级，安装，卸载测试
1.升级测试：临近版本升级(1.0->1.1);跨版本(1.0->....->2.2)
2.安装测试：首次安装;覆盖安装(同版本，不同版本覆盖);卸载后安装
3.卸载测试：首次卸载;卸载安装后在卸载
健壮性测试
1.手机资源消耗：cpu，内存
2.流量消耗：图片，数据，视频
3.电量测试
4.崩溃恢复
7. 针对 App 的安装功能，写出测试点？
安装
1.正常安装测试，检查是否安装成功。
2.APP 版本覆盖测试。例如：先安装一个 1.0 版本的 APP,再安装一个高版本(1.1 版本)的APP，检查是否被覆
盖。
3.回退版本测试。例如：先装一个 2.0 版本的 APP,再安装一个 1.0 版本的 APP,正常情况下版本是可以回退的。
4.安装时内存不足，弹出提示。
5.根据安装手册操作，是否正确安装。
6.安装过程中的意外情况（强行断电、断网、来电话了、查看信息）等等，检查会发生的情况。
7.通过‘同步软件’，检查安装时是否同步些文件。安装了一
8.在不同型号、系统、屏幕大小、分辨率上的手机进行安装。
9.安装时是否识别有 SD 卡，并默认安装到 sd 卡中。
10.安装完成后，能否正常启动应用程序。
11.安装完成后，重启手机能否正常启动应用程序。
12.安装完成后，是否对其他应用程序造成影响。
13.安装完成后，能否添加快捷方式。
14.安装完成后，杀毒软件是否会对其当做病毒处理。
15.多进程进行安装，是否安装成功。
16.在安装过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。
17.安装之后，是否自动启动程序。
18.是否支持第三方安装。
19.在安装中点击取消。
卸载
1.用自己的卸载程序进行卸载，检查是否卸载干净。
2.用第三方工具，检查是否卸载干净。
3.在卸载过程中，点击取消按钮，看是否正常退出卸载程序，检查软件是否还能继续正常使用。
4.卸载过程中，出现意外（比如手机关机，没电，查看信息，接打电话），程序是否还能运行。
5.在卸载过程中，突然重启设备，再次访问程序，是否还能运行。
6.在没用使用程序时，删除目录文件，看程序是否能运行。
7.在使用过程中，直接删除目录文件，程序是否还能运行。
8.不同系统、硬件环境、网络环境下进行卸载。
9.卸载成功后，是否对其他程序有影响。
10.卸载后再次安装，是否正常使用。
11.在卸载过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。
更新
1.当客户端有新版本时，提示更新。
2.非强制更新，可以取消更新，旧版本正常使用，下次使用软件时，仍然会出现更新提示。
3.强制更新，强制更新而用户没有更新时，退出客户端，下次启动，依然提示更新。
4.不卸载更新，检查是否可以更新。
5.不卸载更新，检查资源同名文件如图片等是否更新成最新版本。
6.非 wifi 网络下，提示是否更新，取消就加入待下载，wifi 下自动更新。
8.常用的 ADB 命令？
adb --help /adb :看见帮助信息
adb start-server:启动 adb 服务
adb kill-server:关闭 adb 服务
adb devices:查看手机设备号
adb shell getprop ro.build.version.release:获取系统版本
adb push 电脑 手机
adb pull 手机 电脑
adb logcat |grep(unix) 包名
adb logcat |findstr(win) 包名
adb shell :进入 shell 命令行，可以操作 Linux 命令
adb shell dumpsyswindow windows |grep mFocusedApp:获取包名 启动名(win：adb shell dumpsyswindow
windows |findstr mFocusedApp)
adb install 路径/apk 文件:安装 apk 到手机上
adb uninstall 包名:卸载 app 从手机上
adb shell am start-W 包名/启动名:app 启动时间
9.在查看 logcat 命令日志时候怎么内容保存到本地文件？
输出重定向：logcat>> log_file_name
10. App 崩溃（闪退），可能是什么原因导致的？
缓存垃圾过多：由于安卓系统的特性,如果长时间不清理垃圾文件.会导致越来越卡.也会出现闪退情况.
运行的程序过多,导致内存不足
应用版本兼容问题：如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应
用闪退。解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后
安装旧版。
检查 APP 中访问网络的地方，组件中的 ImageView 是否可以正常的下载并显示到 app 页面上。
检查 APP 的 sdk 和手机的系统是否兼容。
在一些特定情况下的闪退,比如播放视频,在Android5.0 升级到Android6.0 的时候,有些系统 API老版本有,新版
本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.
11.如何测试监测 app 的内存使用、CPU 消耗、流量使用情况？
adb shell top
Android 应用性能测试通常包括：启动时间、内存、CPU、耗电量、流量、流畅度等
根据手机的使用应用频度和强度不同，可将应用使用强度分为如下几种状态：
空闲状态：指启动应用后，不做任何操作或切换到后台运行的情况称为空闲状态，该情况为应用对内存的
消耗是最小的。
中强度状态：该情况用户使用应用的强度和时间长短不确定，相对来说使用时长偏长。
高强度状态：该种情况为应用内高频率的使用，用户很少达到，跑 monkey 时可认为高强度状态，该种情
况常用来测试应用内存泄漏的情况测试时，可根据用户的操作习惯模拟应用使用频率和强度等级。
使用 adb 命令，手机连接电脑开启 USB 调试模式，进入 adbshell。
1）查看 CPU 占用率（
使用命令 top-m10-scpu（-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m 显
示最大数量），如下图：
参数含义：
PID：progressidentification，应用程序 ID
S: 进程的状态，其中 S 表示休眠，R 表示正在运行，Z 表示僵死状态，N 表示该进程优先值是负数。
#THR：程序当前所用的线程数
VSS：VirtualSet Size 虚拟耗用内存（包含共享库占用的内存）
RSS： ResidentSet Size 实际使用物理内存（包含共享库占用的内存）
UID：UserIdentification，用户身份 ID
Name:应用程序名称
在测试过程中，QA 需要关注对应包的 cpu 占用率，反复进行某个操作，cpu 占用过高且一直无法释放，此时
可能存在风险。如果你想筛选出你自己的应用的话可以用下面命令 top -d 3|grep packageName
（2）查看内存使用情况
dumpsys meminfo <package_name>或 dumpsys meminfo <package_id>
参数含义：
Naitve Heap Size: 从 mallinfo usmblks 获得，代表最大总共分配空间
Native Heap Alloc: 从 mallinfo uorblks 获得，总共分配空间
Native Heap Free: 从 mallinfo fordblks 获得，代表总共剩余空间
Native Heap Size 约等于 Native Heap Alloc +Native Heap Free
mallinfo 是一个 C 库， mallinfo 函数提供了各种各样的通过 C 的 malloc（）函数分配的内存的统计信息。
Dalvik HeapSize:从 Runtime totalMemory()获得，DalvikHeap 总共的内存大小。
Dalvik HeapAlloc: Runtime totalMemory()-freeMemory() ，DalvikHeap 分配的内存大小。
Dalvik Heap Free:从 Runtime freeMemory()获得，Dalvik Heap 剩余的内存大小。
Dalvik HeapSize 约等于 DalvikHeapAlloc +DalvikHeap Free
重点关注如下几个字段：
Native/Dalvik 的 Heap 信息中的 alloc ：具体在上面的第一行和第二行，它分别给出的是 JNI 层和 Java
层的内存分配情况，如果发现这个值一直增长，则代表程序可能出现了内存泄漏。
Total 的 PSS 信息：这个值就是你的应用真正占据的内存大小，通过这个信息，你可以轻松判别手机中哪些
程序占内存比较大了。
