一、测试理论

3.1 你们原来项目的测试流程是怎么样的?

我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。 

1、需求了解分析阶段 我们的 SE 会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议， 我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等， 产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。

2、测试准备阶段 会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块， 然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，分析测试点， 以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审， 评审完后进行修改测试用例。

3、测试执行阶段 开发人员编写好代码之后，我们会把代码包通过 Jelkins 部署到测试环境提测，进行 SIT 测试， 在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测，在执行测试的过程中， 我们如果发现 bug 就会用 tapd(或者禅道)记录并且提交 bug，也会进行 bug 复测，以及回归测试， 每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试 4-5 轮之后会达到上线要求， 当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后， 由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告， 总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中， 我们会跑自动化用例来进行回归测试。

3.2 如果需求不明确的话你怎么办?

需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求， 才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。

3.3 有哪些需要评审，哪些人在

1、 xmind 思维导图评审，主要是测试人员 2、测试用例需要评审，测试人员，开发人员，产品人员 3、需求文档，项目组所有的人员，都会到场

3.4 有没有写过测试计划，具体包括哪些内容?

参考答案 1： 测试计划内容： (1)目的和范围 (2)规程 (3)测试方案和方法 (4)测试的准入和准出 (5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排 (7)交付件 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 15 参考答案 2 我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度， 后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来， 负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。

3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法?

原来我们用例包含 测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果 黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、 流程分析法、状态迁移法、异常分析法。 常用的：等价类、边界值、判定表、流程分析法、错误推测法。 等价类是指某个输入域的子集合，在该子集合中， 各个输入数据对于揭露程序中的错误都是等效的， 并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部 输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件， 就可以用少量代表性的测试数据取得较好的测试结果， 等价类划分可有两种不同的情况有效等价类和无效等价类。 边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输 出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可 以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输 出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为 测试数据，而不是选取等价类中的典型值或任意值作为测试数据。 对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误 的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为 测试用例。 前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的 联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况， 但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类， 他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。 因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。

3.6 TestLink 工具使用?

(1)创建用户，并给新创建的用户指定权限。 (2)创建测试用例，对测试用例进行增、删、改、查 (3)把测试用例关联到对应的测试计划中。 (4)把测试用例指派给对应的测试人员。 (5)对应的测试人员，查看被指派的测试用例，并执行测试用例。

3.7 如何提交一个好的 BUG

对 BUG 有一个清晰明了的描述； 详细描述 BUG 重现的步骤 对于产生 BUG 的环境进行描述； 提交 BUG 相关的图片和日志; 定位好 BUG 的等级； 将预期结果与实际结果进行对比。

3.8 提 bug 需要注意哪些问题?

1) 不要急着提交，先跟开发说明 bug 的情况，定位分析下 bug。 是前端问题还是后端问题再去提交 bug。 2) 简单明了的概括 bug 标题，清晰的描述 bug 重现步骤，分析 bug 和预期正确结果，附加 bug 的截 图或者日志。描述 bug 的时候。 3) 在不能确认该情况是否为 bug 的时候，可以请教其他人。 4) 提交完 bug 以后，后面还要跟踪 bug 修复情况。

3.9 bug 怎么管理的，bug 的生命周期或者是 bug 的状态

原来 bug 是用禅道来管理的 原来我们公司 bug，提交 bug 直接给对应的开发人员，对应开发人员修复完成，交给测试复测， 复测通过关闭 bug，不通过打回给对应开发。 提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成， 标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。

3.10 提交 bug 包含哪些内容

所属产品、所属模块、所属项目、影响版本、指派人员 截止日期、严重程度、优先级、bug 类型、bug 环境 Bug 标题、重现步骤、附件

3.11 你提交的 bug，开发不认可怎么办?

首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭 bug。 如果是 bug 再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日 志，确定这是一个 bug 之后我就去跟开发说明白，并且给他看 bug 重现的截图以及日志，如果开发还 是不认可的话我就跟产品或项目经理说明白情况。

3.12 对应无法重现 bug，应该怎么处理?

首先，我会多测几次，测了好多次都无法重现的话我就先把 bug 挂起，并且留意一下，看看往后的测 试中，如果在后面的测试中重现 bug 就激活，如果经过几个版本都还没发现的话就关闭 bug。

3.13 界面中的乱码可以是哪里导致的?

(1)数据库中的编码设置 (2)前端页面编码 (3)后台代码也会编码

3.14 bug 的级别有哪些，级别如何判断

1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行， 或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。 2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统 丢失了业务数据且可以恢复，一般业务数据出错。 3、一般：对业务有较小的影响，业务系统丧失了较少的业务功能， 例如：界面错误，打印或显示格式错误。 4、提示：对业务没有影响，不影响业务过程正常进行， 例如：辅助说明描述不清楚，提示不明确的错误提示。

3.15 测试中，如何判断是前端的 bug 还是后端的 bug 呢?

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。 1）请求接口 un 是否正确如果请求的接口 ur 错误，为前端的 bug 2）传参是否正确如果传参不正确，为前端的 bug 3）请求接口 u 和传参都正确，查看响应是否正确如果响应内容不正确，为后端 bug 4）也可以在浏览器控制台输入 js 代码调试进行分析

3.16 项目上线后发现 bug，测试人员应该怎么办

看严重级别：严重还是不严重 严重的：紧急变更上线  不严重：修复好后跟下个版本一起上线 用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。 测试人员：编写对应的测试用例、测试环境中重现 bug、提交 bug、 交给开发进行修复、修复完成 bug、进行 bug 的复测。 如果测试环境无法重现，可以导入生产环境的包到测试环境中测试， 还是不能复现，查看生产环境的日志去定位问题。

3.17 如何保证质量

(1)需求要吃透，多问，多去了解。 (2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。 (3)要有良好的测试执行：要求用例执行率达到 100%，多轮测试，进行探索性测试， 需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd) (4)不断的反思与提升。

3.18 产品是怎么上线的?

一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。 首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行 sql 文件， 对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块; 测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。 如果发现 bug，开发人员当场修复 bug，修复成功之后我们测试再复测，通过就可以正常上线 如果发现了 bug 开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性， 如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。 如果不严重，产品跟客户觉得可以上线，就正常上线。

二、app 测试

15.1 app 测试你具体怎么做的?

对于 App 这块，我们一般首先都先做功能，先保证功能过关是第一位，对于功能这块的话，基本都跟 Web 端是一样的。 除了功能之外，公司还要求做了一些专项测试，像：安装，卸载测试，兼容性测试，稳定性测试，性 能测试，弱网测试，交互性测试，都有测试过的，专项测试这块，我主要负责的是：兼容性测试，稳 定性测试，性能测试，弱网测试，交互性测试，这是我这边负责的。 像兼容性测试，公司有提供了差不多了 7-8 款的真机，像：华为，小米，三星， vivo， oppo 等这 些主流的机型都在真机想有测试过，其他的机型，公司用的是云测，云测平台我们用的 Testln 这个 平台，公司会给我们提供账号。 稳定性测试这块，用的 Monkey 命令工具去测的，主要就是通过 monkey 模拟用户发送一些伪随机时 间，看 app 是否有 Crash， ANR， Exception 等现象，一般都是在晚上的时候去执行 monkey 命令， 然后出报告，分析性能测试，用的 GT 工具结合 Android Studio 工具去检测 app 在手机上运行的时 候的 CPU，内存，电量，流量，启动时间，安装，卸载时间以及页面的响应时间。 弱网我们用的 fiddler 工具去进行模拟的，模拟 2G/3G/4G 等弱网场景，看 app 在弱网情况，功能是 否能正常使用。 交互性测试这块主要就是看 app 与其他应用程序之间的交互运行，以及与系统应用程序之间交互运行， 来回进行前后台切换，看是否会出现闪退，数据丢失等现象。

15.2 Web 测试与 app 测试区别?

其实功能这块，app 测试与 Web 测试基本是一样，没有什么区别。(需求分析->提炼测试点>编写测试 用例->执行用例->提 Bug->复测，回归)等等的。 区别主要在于，web 端是 B/S 架构的，App 是 C/S 架构的，由于架构的不同，所以 web 端一般服务器 更新的时候，客户端不需要更新， 因为它是通过浏览器来访问的，服务器更新了，客户端也更新。app 服务端要更新,同时客户端软件 要进行升级更新，才算是新的版本。 对于 app 测试来讲，除了功能之外，更多的还要考虑一些专项测试，比如： Web 测试是基于浏览器的所以不必考虑安装卸载。而 app 是客户端的，则必须测试安装、更新、卸载 兼容性、稳定性、性能测试、弱网测试、交互性测试等等。 还有就是，对于兼容性这块，Web 端主要考虑是：不同的浏览器，不同的操作系统的兼容性接口。 而对于 app 测兼容性更多的考虑：不同的品牌机型，不同操作系统，不同手机屏幕大小，屏幕分辨率 性能方面也会有所不同：Web 端性能测试更多关注的后台的性能， app 的性能测试关注的是手机本身的资源的性能问题： 比如：CPU 内存，电量，流量，页面加载响应时间，软件启动时间等等 他们两个之间的区别差不多就这些吧。

15.3 常用的 adb 的命令?

adb start-serveradb kill-server adb devices adb -s 设备 ID install 路径/包名.apk adb -s 设备 ID shell pm list packages -3 adb -s 设备 ID uninstall com.baidu.BaiduMap #电脑端文件传输到手机上 adb -s 设备 ID push D:\路径文件\ sdcard\路径\ #手机上的文件传输到电脑端 adb -s 设备 ID pull \sdcard\路径\文件\D:\路径 #查看手机端的日志 adb logcat adb logcat -d #打印完所有的日志文件之后，退出 shell 终端 adb logcat -c #清除手机系统运行生成的日志文件 adb logcat -v time #需要打印日志详细时间的简单数据 adb logcat -d *:E #需要打印级别为 Eror 的信息 adb logcat -d *:E>D:\hello.log adb logcat -d *:l>D:\hello555.log #打印 1 以上级别的所有日志信息 adb logcat-d *:E | findstr cn.csdn.activity > D:/hello_error2.log 查看所有的手机软件包名 adb shell pm list package 查看第三方的手机软件包名 adb shell pm list package -3 查看后台运行的包名 adb shell am monitor 查看手机当前使用的内存情况，各个线程的内存占用情况 adb shell dumpsys meminfo 查看手机的电池信息 adb shell dumpsys batteryinfo 查看系统资源状态 adb shell top adb 命令录屏： adb shell screenrecord --time-imit 10/sdcard/demo.mp4 (10 表示录制 10 秒，默认是 180 秒)

15.4 adb 的作用的?

adb 其实是一个 android 调试桥，主要是用来监控手机设备的，实现手机端与电脑端的通信，通过 adb 来实现对手机的管控。比如：通过 adb 安装软件卸载软件，通过 adb 可以查看手机的资源使用情 况，可以查看 cpu 内存等资源。还通过 adb 实现手机端与电脑的文件的传输通过 adb 查看手机端 app 运行的日志，通过看日志来分析具体问题。

15.5 App 兼容性测试怎么做的?

像兼容性这块当时，我们主要用真机测试为主，公司当时使用提供大概 7、8 款机型吧， 我记得像华为荣耀系列两款，例外小米机型有选择 2 款，还有就是像 vivo， oppo 当时都有测过, 对了还有三星等这些系列机型上都有做过真机测试。 真机这块，像系统版本主要覆盖的系统其中 6.0\7.0\8.0 为主, 5.0 以下公司当时都不要求测， 对于其他的机型覆盖不到位，我们都是通过云测进行覆盖的，云测这边，我们公司用的 testin 这个云测平台，公司有提供账号给我们只要登录上去，然后把 apk 上传上去，之后选择机型要测试的 机型，当时我们在云测测试有差不多有 60 款多款机型吧，主要是市面上流程的主流机型，每个系列 都会选个几款，如果用真机测了的就不在选择了，然后做一些相关的配置，云测平台上主要帮我们做 了智能遍历，安装，启动，运行，卸载，初始化， Monkey 测试相关的测试，不过 monkey 一般都是 通过真机测的，云测平台没有测过，配置好了之后，提交测试就可以了，一般提交测试之后，需要几 个小时就会出报告。然后分报告，主看遍历，安装，启动，运行，卸载，初始化相关哪些机型有出问 题，对于出问题的机型，一般会先补测一下，如果还有问题，我们项目组一般会向公司申请真机再真 机进行复测，如果真机复测有问题，就通过利用 adb logcat 查看错误日志，分析具体的问题所在。 其实我们做兼容性测试主要就是看软件在不同机型，不同系统版本下能不能正常安装，卸载是否 能正常启动，运行，初始化，我们都把各个功能都进行运行一遍，主要就是跑下主流程，看有不有问 题。例外，就是看软件在不同屏幕大小，不同的分辨率的手机下显示是否正常，有不有拉伸，显示不 全，或者显不清晰的等问题。 当时我们兼容性就这么做测。

15.6 App 稳定怎么做的?

Monkey 怎么用(App 稳定测试)? 稳定性这块，我们当时用的是 SDK 自动的一个 Monkey 工具进行测试的，其实 Monkey 工具主要通过 模拟用户发送伪随机时间去操作软件，通过执行 Monkey 命令，它会自动出报告，执行测试大概在 10 万次，每个动作的间隔时间 250ms，主要就是看软件长时间，随机乱操作的情况，是否会出现异常， 闪退，崩溃等现象。 一般我都是在下班的时间晚上时间执行 Monkey 命令，并把生成的报告导出到电脑端，大概需要 6、7 小时，第二天早上看报告，分析报告，如果出现问题，一般利用上次执行的那个种子值，再进行执行 命令进行复测一下， 像 monkey 命令： adb shell monkey -p com.xy.android.junit -s 种子值 --throttle 250 --ignore -crashes --ignore -timeouts -monitor-native-crashes -v -v 100000 > E:\monkey_log\monkey_log.txt 这里主要关注几个点，1、指定种子值 2、忽路一些异常，保证能正常执行完成 3、设置间隔时间 4、配置一些时间比例 5、然后就是执行的次数。 对于报告怎么分析这块，主要看有不有 CRASH(崩溃)，ANR(超时无响应)， Exception(异常)等的情 况像看有不有空指针异常( NullPointException)啊，0OM 等现象啊等等， 找到 CRASH 崩溃 ANR 超时无响应 Exception 异常的位置，看出现错误的上一个动作是什么，什么做 了什么动作导致错误出现。异常信息会详细的指出哪个 Activity 出现了问题，甚至于哪个函数出问 题了，具体哪个位置。然后把报告中出现的日志信息截图发给开发，开发修复完成之后，我们会根据 种子值在进行复测一下。 稳定性这块我们当时就是这么做的。 我在运行 monkey 发现过很多的问题我就简单的说几个问题，举个例子在查看 monkey 运行日志中 (1) com.androidserver.am.NativeCrashListener.run(NativeCrashListener.java：129) 属于本地监听代码导致的崩溃，手机监听代码导致的崩溃，他是手机产生的原因，不是代码的原因不 做处理。 (2) ∥Short Msg:java.lang.IllegalArgumentException 传参异常：需要一个 stng 类型，给我一个 int 类型 (3) ∥Short Msg:java.lang.NullPointerException 空指针异常 (4) ∥Short Msg:Native crash 本地代码导致的奔溃 (5) (com.koudaizhekou.tbk/com.uzmap.pkg.EntranceActivity) 超时无响应 等等等……

15.7 App 弱网测试怎么做的 ?

弱网测试这块我用的 fiddler 工具做的，通过 fiddler 实现延迟发送数据或接收的数据的时间来限 制网络的下载速度和上传速度，从而达到模拟 2G\3G\4G 的移动网络的弱网场景，还有设置随机数来 模拟网络不稳定的情况。 操作：首先保证手机与电脑在同一个网络，然后在手机上，设置代理服务器，指定服务器为装了 fiddler 的电脑的 ip 地址，端口为 8888 然后就是在 fiddler 上设置上行，下行速率,实现对发送， 接受数据的进行网络延迟具体在 fiddler 的菜单上有一个 Rules -> CustomizeRules，打开 Fiddler 的 ScriptEditor 文件，在其中找到 m_SimulateMode 标志位，然后修改上行，下载的网络延迟时间 即可，具体设置参数的值 SE 那边有给到一个参考文档 2G 上行 440，下行 400， 3G 上行 100，下行 100 模拟网络不稳定的情况 生活当中，网络并不是固定不变，一般处于不稳定的状态，我们这个时候编写随机数来模拟网络 不稳定的情况 1，在 Customize Rules 文件中，写一个随机的数 static function randlnt(min，max){ return Math.round(Math，random()*(max-min)+min); } 2，在 Customize Rules 文件中，限制网络的参数修改成随机数 if (m_Simulate Modem){ // Delay sends by 300ms per KB uploaded.2kb/s oSession["request-trickle-delay"]=""+randlnt(1，20000); // Delay receives by 150ms per KB downloaded.2.5kb/s oSession["response-trickle-delay"]=""+randlnt(1，20000); 3，重新勾选 Rues-> Performance->勾选 Simulate Modem Speeds 弱网测试，看我们软件在弱网场景下是否会有丢包的现象，丢包率是否严重，页面是否能正 常展示，是否有空白页，数据是否有丢失，页面加载速度是否会严重影响用户体验。

15.8 App 的性能测试

内容要点： 指标：cpu，内存，电量，流量，FPS， 怎么测? cpu，内存，流量 android studio cpu 不能超过 10-20% 普通业务要求在 10%左右，核心的业务，尤其是一些绘图的业务， 要求在 20%左右。指标：SE 给到，竞品分析 内存主要看有内存泄露的情况，怎么看? 流量：一刷新使用软件，流量会逐渐增加 具体操作： 1，对于 cpu 内存，流量这 3 个指标，我们用的 android studio 来检测的，结合 sdk 里面的一个插 件 android Monitor，它可以帮我们试试检测 cpu，内存，流量的曲线图 2，这里我们需要开启手机端的开发者模式，还有 usb 调试模式，例外，开发给我们提供的 apk 包， 必须需要开启 debug 模式，开发开启之后打包给测试人员就可以了 3，主要就是对我们需要测的功能进行操作，然后实时查看图表，看他是否有内存 oom 内存泄漏，cpu 是否使用过高，是否有内存抖动，造成的卡顿等现象，是否有图片过大造成流量使用过大这些问题等， 是否有频繁使用流量，没有使用缓存等问题 4，像 fps 帧率是通过 adb 命令来测的，还有电量我们当时用的是手机自带的一个第三方软件测的? 

15.9 对于内存具体怎么测呢?

对于内存其实主要看有没有内存泄漏的问题 具体我们是这样做的： 1、首先我会频繁操作同一个业务，看他的内存和 cpu 是否逐步增长，最后稳定在一个固定大小的范 围，如果在频繁操作同一个业务，内存一直在增长，可能存在有内存泄漏问题，尝试手动 GC(手动回 收内存，因为内存泄漏，系统已经回收不了，所以尝试下手动回收内存)，内存明显或者断崖式的下 降，基本就可以判断有内存泄漏的现象 再通过 damp java 这个去分析，分析结果如果出现 leaked，就说明有了，里面可以找到是哪个对象， 截图提 bug， 2、使用 app 过程中，内存一直在增长，那基本可以判断有内存泄漏的情况，还有看是否有内存抖动 的现象：这里主要原因还是有因为大量小的对象频繁创建，频繁的回收内存，会导数 cpu 频繁使用， 造成 cpu 使用过大，造成 app 卡顿，导致内存碎片，内存泄漏等问题

15.10 对于 CPU 具体怎么测呢?

cpu 主要就是看有没有过高，有没有超过我们的指标范围 具体是这样做的： 首先频繁使用某一个业务，cpu 是否逐步增长，最后稳定在一个固定大小的范围，对于一把基础 业务，对 cpu 要求不高的业务，cpu 不能超过 10%，对于 cpu 要求比较高的，比如某个业务需要加载 地图，大量的图片，视频等的业务，或者需要做大量的数据统计分析的业务， 我们要求 cpu 不能超过 20%

15.11 对于流量具体怎么测?

a，首先看在没有操作功能业务的情况下，没操作流量不应该有，或者是流量使用不是很大，就几 KB 因为 app 肯能实时刷新消息，比如如果一个登陆，你就使用 1M 的流量，查询个图片使用 3-4M 的流量 图片，这个肯定流量使用过大 b，频繁操作同一个业务，流量一直在刷，说明没有使用缓存 如何处理：图片过大处理方法：图片压缩传输，要么降低图片分辨率，

15.12 对于 FPS 具体怎么测?

对于 Fps 帧率的问题，我们当时用的 adb 命令来测的 知识点拓展： Android 设备的屏幕刷新率为 60 帧/s，要保持画面流畅不卡顿，要求每一帧的时间不 超过 1000/60=16.6ms，这就是 16ms 的黄金准则， a. 打开手机：开发者选项-> profile GPU rendering -> in adb shell dumpsys gfxinfo(开启 GPU 渲染模式) b. 操作要测试的 apk C. cmd 窗口输入命令： adb shell dumpsys gfxinfo 包名 d. 得到一个矩阵数据，计算矩阵中帧率大于 16 的点所占比例，即为卡顿比 e. 通过 execl 进行表格处理可以直观的查看软件的流畅度

15.14 对于电量具体怎么测?

电量这一块，我们当时用的手机自带的第三方软件测的

15.15 App 交互性怎么做的?

交互性这块，主要从以下几个方面去考虑测试的是： 1. 看我们软件与其他应用软件的同时运行来回切换是否有问题 2. 看软件切换到后台一段时间，再切换到前端，或者前后台来回切换， 软件是否会有异常，比如：进程被杀死，或者切换到前端页面出现问题，或者页面数据丢失等等。 3. 看软件被在使用过程中被其他应用中断，或者其他意外情况中断，比如：来电，来短信，闹铃， 低电量测试等，还要注意手机端硬件上，如：待机，锁屏，插拔数据线，耳机等操作不会影响客户端。

15.16 App 的安装，卸载，更新测试具体从哪些方面考虑?

安装测试： 1. 正常安装测试，检查是否安装成功安装完成后，能否正常启动应用程序 2. 是否支持第三方安装，比如豌豆荚及 91 助手等工具可以正常安装及卸载程序 3. 检测在各大手机市场上下载，并直接安装，看是否能正常安装，安装完成之后，能否能正常启动。 4. 检测 APP 版本覆盖测试(先安装一个低版本，不卸载。然后再直接安装一个高版本，看是否会覆盖 低版本。(直接覆盖是否成功，卸载之后，再下载新版本，看是否能安装成功） 5. 检测版本回退(先装高版本，不卸载，直接再重新安装一个低版本，是否会覆盖高版本。 6. 检测在内存不足的情况下，去安装软件，系统应该会有提示 7. 在安装过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码符号、乱码等。 8. 检测在未允许外来程序的安装的情况下，安装软件是否会有提示信息 9. 如果软件需要用到网络，GPS 定位，联系人等其他系统应用程序的时候，安装 App 会有相应的提 示。在不允许的情况，软件是否能正常使用。 10. 安装完成后，是否对其他应用程序造成影响。 11. 多进程进行安装，是否安装成功。(同时安装多个软件，是否能正常安装) 12. 在不同型号、系统的手机进行安装。(兼容性) 13. 安装过程中，取消安装，再次重新安装，是否能正常安装。 14. 安装完成后，检查手机桌面能否添加快捷方式。(是否有快捷图标生成。) 卸载测试： 1. 正常卸载，软件是否能正常被卸载，相应的桌面图标是否会删除 2. 卸载之后，对应的文件是否删除干净，进入安装位置，去看下是否有残留的文件 3. 程序正在运行的时候，卸载程序，是否能正常卸载 4. 卸载过程中，取消卸载，看是否正常退出卸载程序，检查软件是否还能继续正常使 5. 在没用使用程序时，删除目录文件，看程序是否能运行。 6. 不同系统、硬件环境下进行卸载 7. 卸载成功后，是否对其他程序有影响 8. 卸载后再次安装，是否正常使用 9. 在卸载过程中，所有的提示信息必须是英文或者中文， 提示信息中不能出现代码是否有相关的提示信息 10. 卸载过程中，出现意外(比如手机关机，没电，查看信息，接打电话)，程序是否还能运行 11. 在卸载过程中，突然重启设备，再次访问程序，是否还能运行。 更新测试： 1. 当客户端有新版本时，提示更新 2. 非强制更新，可以取消更新，旧版本正常使用，下次使用软件时，仍然会出现更新提示 3. 强制更新，强制更新而用户没有更新时，退出客户端，下次启动，依然提示更新 4. 不卸载，更新，检查是否可以更新 5. 不卸载更新，检查资源同名文件如图片等是否更新成最新版本。 6. 非 wifi 网络下，提示是否更新，取消就加入待下载，wifi 下自动更新。

15.17 H5 界面怎么测试

基本功能测试：(浏览器、微信内置浏览器) 登陆 目前 H5 与 native 各个客户端都做了互通，所以大家在测试的时候要注意两点： A、若客户端已登录，那么进入 H5 后仍然是登录状态 B、若客户端未登录，进入 H5，点击对应按钮 OR 链接，如果需要登录，须拉起 native 登录。若取消 登录，是否可再次拉起登录，或者停留在的页面是否有对应的登录提示.。 ps：本次测试过程中就发现，第一次点击链接，可以拉起登录，第二次却不能 翻页遇到翻页加载的页面，需要注意内容为 1 页或者多页的情况。 A、数据分页加载时，注意后续页面请求数据的正确。 ps：这个需要注意在快速操作场景中，请求页数是不是依次递增，快速操作(如第 1 页尚未 loading 出来的时候仍然继续上拉操作)时是否发出去对应的请求了。 刷新与返回 A、下拉刷新是否仍然处于当前页面。 B、用户主动点击刷新按钮是否仍然处于当前页面 C、点击返回与 back 键，回退页面是否是期望页面 ps：本次测试过程中就发现，mtop 接口请求成功，但是 data 内无数据时，返回到的就是个空白页面， 无法正常发送请求。 H5 适配相关 H5 的适配其实比客户端的相对来说，要少一些，手机品牌之间的差异不大，所以不用太多关注，最 容易出现问题的是 android2.3 系统，这个要特别关注下: A. 大屏(如 720*1280，重点关注页面背景是否完全撑开页面，刷新是否有抖动) 小屏手机(如 320*480，重点关注下弹框样式和文案折行) B. android2.3、android4.X 随机找一个即可 C. ios5、ios6、ios7 体验相关 资源相关 A、页面中有图片的话，淘宝那边建议图片一般不大于 50kb，本着一个原则，尽量缩小图片 B、资源是否压缩、是否通过 CDN 加载 C、如何保证二次发布后有效更新。 流量 A、对于一些不会变化的图片，如游戏动画效果相关图片，不需要每次都请求的东西，做本地缓存 B、数据较多时是否做了分页加载。 页面展现时间 A、关注页面首屏加载时间 页面提示 A、弱网络下，数据加载较慢，是否有对应的 loading 提示 B、接口获取异常时，提示是否友好 C、刷新页面或者加载新内容时页面是否有抖动手机操作相关 A、锁屏之后展示页面 B.回退到后台之后，重新呼出在前端展示

15.18 你们之前是用什么手机什么版本做兼容性测试的?

有用到三星 note5 Android 6.0.1 三星 s6 Android 6.0.1 红米 1s Android 5.1 小米 5 Android 7.0 华为 mate9 Android 6.0 乐视 2 Android 6.0 华为 mate20 Android 9.0 三星 s8 Android 8.0 iphoneos ios 10.3.2 iphone ios 10.0.2 iphone ios 8.4.1 iPhone X ios 11.0

15.19 Android 跟 ios 测试有什么区别?

Android 和 ios 测试的共同点都需要进行界面测试、功能测试、兼容性测试、网络测试、交互性测试、 易用性专项测试、异常测试、安全专项测试以及权限测试。不同的是 Android 测试除了以上的测试 之外还要用 monkey 进行稳定性专项测试以及用 emmagee 或者 gt 进行性能专项测试。los 是用 itools 工具对功能进行测试：安装、传输文件以及查看日志。 从操作系统，安装卸载，按键操作，开发语言这几个方面去区分操作系统： android 操作系统较 多，iOS 较少只能升级不能降级，并目新的版本的资源库不能完全兼容旧版中系统中的应用，如果低 版本应用调用了高版本的资源库，可能会导致系统崩溃。 安装卸载测试，应用发布后：下载安卓包的平台和渠道很多：豌豆英、应用宝、360 手机助手等; iOS 主要有 App store、 iTunes，安全性会更高点 本地测试：安卓手机可以通过扫码或者直接安卓 APK 包安装测试包;iOS 要安装测试包必须绑定手机 的 id(证书)才可以安装 ipa 测试包 按键操作测试：安卓手机针对每一款手机有不一样的操作;苹果手机操作习惯单一 开发语言：虽然同样的业务安卓和 iOS 的展示形式和业务一致，但是底层全完不一样，安卓的应用是 有 java 语言实现的，iOS 用 OC 实现。

15.20 小程序怎么测试

1，小程序测试(多用第一人称，口语化表达，多讲一些，讲细一些，先宏观，在微观)参考面试问题 STAR 法则: 我们原来主要测试，几个方面，界面测试，功能测试，交互性测试，兼容性测试，安全测试， 易用性测试，异常测试，权限测试界面测试：主要是测试跟界面的原型图是否一致，同时我也要考虑不同屏幕大小跟分辨率 功能测试：跟所有的功能测试都是一样的，还有小程序有位置功能，检查下，微信小程序,附近中是 否能找到对应小程序，使用小程序是否记录， 交互性测试：要考虑跟微信的功能交互使用，比如说一些，卡包，支付等功，考虑跟手机固有功能交 互，比如说来电，短信等 兼容性测试：考虑跟微信不同版本的兼容，还有同时还要考虑不同手机厂商跟手机型号兼容，还要考 虑当微信清除缓存后，小程序还能否继续使用 安全测试：测试数据加密，包括 sql 与 xss 脚本攻击这块 易用性测试：考虑功能是否方便还用 异常测试：考虑断网，手机重启，关机的情况 权限测试：小程序继承微信权限，测试手机对微信权限，还要考虑微信对小程序授权，是否允许操作 原来我们测试阶段，上传小程序到微信小程序平台，上传到开发版本里面，通过扫描二维码去下载小 程序进行测试， 上线后，我们也要测试下，微信搜索小程序中能否搜索的到

15.21 公众号，小程序比 app 更火，你怎么看

小程序有安装包，一般控制在 1M 以内 1，基于微信大的平台，有流量的入口 2，不需要安装，操作更加方便

15.22 微信开发者工具如何使用

原来我们的下载一个微信开发者工具，导入开发给的小程序代码包，在输入开发给予的 appid，调试与测试小程序代码包， 如果真机测试，也可以扫描开发在微信开发者工具生成的二维码进行测试

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！