2023备战金三银四，Python自动化软件测试面试宝典合集（十三）

14.2 性能测试流程是怎么样的?

例外一种问法：简单介绍下你们公司的性能测试流程是怎么样的?

我们那个项目的性能做得不多，公司要求也不严格。

对于流程这块，首先就要对整个系统进行详细的分析，确定基本的测试范围，看下系统的哪些业务是

需要做性能测试的，还有就是做那方面的性能测试，对于我们那个项目，当时就做了几个业务做了些

简单的井发压测(稳定性)这块，像登录的，搜索查询，下单，还有就是购物车里面的几个接口都有做

过，然后就是对各个业务场景进行详细的场景分析与设计，确定每个业务场景的并发数，是否需要设

置集合点啊，压测时间是多长，还有各个业务场景的性能指标等等，场景设计这块基本上都是老大跟

产品哪个一起弄的，我参与的不是太多。

上面把个场景设置好了之后，提交给我们，我们就是根据老大设置好的那些场景编写了基本的性能测

试用例，其实做性能测试，我觉得前期最关键的还是业务场景一定要设计好，后期我们主要的任务就93

是准备各自任务需要用到的一些测试数据，搭建好测试环境，还有就是测试脚本设计与开发，执行，

并生出测试报告，对于测试结果我们一般会简单的做个分析，如果没有什么问题，基本后期就写一个

性能测试报告。流程大概就是这样的。

14.3 你们性能观察哪些指标，大概指标范围是怎么样的。

对于指标这块，业务方面的指标主要有：并发数，90%用户的平均响应时间

错误率，吞吐量/吞吐率这些，例外还需要关注服务器资源的使用情况，像：CPU 的使用率、内存的

占有率，磁盘 IO，网络。

我们那个项目当时只针对，登录，搜索查询，下订单，购物车相关接口，支付等业务做了些简单的并

发，压测这块，指标大概是这样的：

单基准业务并发测试登录，注册，查询 1s 以内，下订单，购物车相关接口，支付 2s 以内，混合业务

性能：5s 以内

响应时间：登录，注册业务<2s 之内查询，下订单，购物车，支付业务<3s

充值，提现，查看充值日志，查看提现日志业务查询标的，<3s

投标，申请借款<5s

错误率：0

吞吐量/吞吐率：200 左右请求/sec

CPU：80%以内

内存：80%以内

I/O： %util<=80%，%nowait<=20%

%util: 磁盘一秒中有百分之多少的时间用于 I/O 操作，

% nowait：磁盘等待处理时间占比

带宽：<=系统带宽的 30%，无丢包，无延迟，无阻塞

14.4 这个测试的环境配置，如转速度

租用的服务器，一台数据库服务器，一台后端服务器

8 核 16G 网络带宽 1000M，2.5GHZ 磁盘 15000pm 转数

14.5 性能测试计划有哪些内容

写过，主要是时间进度安排与工作安排，主要是环境，测试任务，测试需求，测试方法与策略，测试

环境准备，测试通过的标准。

比如说原来我们一个项目性能测试时做了 5 天，那我们计划是，测试策略与用例编写一天，测试准备

需要 1 天，测试执行 2 天，报告总结 1 天。94

14.6 有没有写过性能测试报告，具体包括哪些内容

性能测试报告，需要每次 Jmeter 压测完成的 html 报告的数据跟 nmon 工具监控的数据，整理出一份

性能测试报告，性能测试报告，主要包含：

1，测试资源(环境，测试数据，表里面需要多少数据，测试工具)

2，测试设计(测试业务，测试类型，测试时间，并发用户数)

3，测试分析(每一个场景都需要分析)

4，测试结论(能不能上线，不上线的原因)

5，优化和建议

6，测试通过的标准，平均响应时间<5s，资源利用率<75%，事务失败率<5%

14.7 什么是内存泄漏，什么是内存溢出？

内存泄漏：

是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进

程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少

获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。

内存溢出：OOM

1. 指程序申请内存时，没有足够的内存供申请者使用 1M 实际要占用 2M 内存，

就说分配的内存不够，导致内存溢出

2. 给了你一块存储 int 类型数据的存储空间，但是你却存储 long 类型的数据

3. 长期出现内存泄漏，导致系统内存越用越少，最终导致内存不够用，导致系统崩溃，出现 OOM

14.8 吞吐量，吞吐率

吞吐量：KB

指在一次性能测试过程中网络上传输的数据量的总和(单位应该 KB)也可以这样说，

在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器

承受的压力。

并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑：

90%用户的平均响应时间、错误率、吞吐量/吞吐量、CPU、内存、磁盘 I/O、网络的占用情况，

还有服务器的配置。

吞吐率：

吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它

是衡量网络性能的重要指标。95

12s 800M 数

800 * 1024 / 12 = 66666 KB/sec

通常情况下，吞吐率用“字节数秒”来衡量，当然，也可以用“请求数/秒”来衡量;

14.9 吞吐量与吞吐率跟负载有什么关系?

吞吐量/率和负载之间的关系:

1、上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比;

2、平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动;

3、下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比;

总结：吞吐量/率干不过负载!!！

14.10 当你服务器满了之后，你们吞吐量和响应时间怎么变化的

吞吐量会所有下降，响应时间会变长

14.11 你们的 TPS 的指标是什么估算的?

假设一个系统的业务有登录、浏览帖子、发送新帖、回复帖子，访问高峰是上午 10 点，日访问高峰

PV 约 5208(含登录 1300、浏览 2706、发帖 526、回帖 676)，系统响应时间要求小于 3 秒，试计算此

系统的 TPS 以及并发数。

如果分析业务量的数据是以 PV 来统计的，我们需要把 PV 转化为 TPS。

PV 的统计一般可以通过监控埋点或者统计访问日志统计得出。

说到 PV 还有个特殊的情况，叫 PeakY，指一天中 PV 数达到的高峰 PV 值。

通过一些监控系统，也可以直观看到统计数据。

实际上一个 PV 即一次对服务器的客户请求，可能还包含了很多资源请求，比如图片、样式 JS 信息、

文字等。而浏览器具有资源缓存功能，下次访问同样资源将不会再从远程服务器上下载，这大大加快

了响应速度。如果我们使用代理服务器访问外网资源时，多数代理服务器也会缓存这些静态数据。也

就是说浏览器与服务器之间的动态数据的 Size 会小于静态数据。

所以浏览器是否缓存了静态数据对性能测试影响明显。我们在做性能测试时，其中就有许多用户可能

是新用户，在他们的浏览器上还没有缓存这些静态数据，为了更准确的模拟用户请求，我们有必要不

缓存这些静态内容.所以性能测试中是否缓存访问的静态资源要根据业务情况而定。

本例中，我们把一个请求放在一个事务中来统计服务器的响应时间。这么说，一个 PV 即是一个

事务(每秒的 PV 量并不直接等同于 TPS，因为一次客户请求可能包含了很多资源请求。如果我们不关

心页面刷新时请求资源的耗时，此时我们就把每秒 PV 数等同于 TPS)，比如一个功能页面(浏览帖子)

每秒会有 10 个 PV，那么此功能的 TPS 即为 10。96

估算 TPS：

业务量一般要取系统业务高峰的值，才能代表系统的实际处理能力，系统在 10 点的访问高峰 PV 约

5208，那么这个时段的 TPS = 5208/3600 ≈ 1.45 吗?

答案是否定的，因为在一小时内的吞吐量未必是平均的。

如果我们采集到的业务量数据能够细分到每分钟，TPS 就越准确。如果不能，可以按照二八原则。即

80%的业务在 20%的时间内完成，TPS=(5208*80%)/(3600*20%)≈5.8

估算并发数：

1、由 TPS 进行估算

2、由在线活动用户数估算

3、根据经验估算

方法 1：由 TPS 进行估算

因为 TPS=事务数/时间，假设所有的事务都来自不同的用户，那么并发数=事务数=TPS * 时间。

具体如下：

Vu(业务名称)=TPS(业务名称)*( Runtime+ ThinkTime)

其中，Vu(业务名称)表示此业务的虚拟用户数，即并发数。 RunTime 是测试程序/脚本运行一次所消

耗的时间，包括事务时间+非事务时间。 ThinkTime 是模拟用户思考或者填写表单消耗的时间。

下面是发帖动作的测试脚本伪代码(T、TT、AT 表示时间，单位为秒，AT 一般都是非常小的，包含在

事务时间中，可以忽略).Runtime=T1+...+T7; ThinkTime=TT1+TT2。

Login

Enter login page (进入登录页面)Tl=0.2

ThinkTime (思考时间)TT1=3

Declare login trans action (声明登录事务)T2=3

Commat formm (提交登录表单)

Assertlogin (检资登录是否成功)AT1

Enter default page(进入登录成功后的默认页)T3=0.2

Sender topic

Enter topic list (进入论坛列表)T4=0.2

Enter new page for topic (选入新帖编辑页面)T5=0.2

ThinkTime (思考时间)TT2=3

Declare newTopic transaction (声明新帖事务)T6=3

Commit fom (提交新帖)

Assert commit (查发帖是否成功)AT2

Enter topic list (提交新帖后进入论坛列表)T7=0.297

业内一般把 Think Time 设为 3 秒。测试需求中要求响应时间小于 3 秒，我们就以 3 秒为阀值

可得 Vu=TPS (RunTime + ThinkTime)=5.8*(T1+TT1+T2+T3+T4+T5+TT2+T6+T7)≈76

如果只计算事务时间，Vu=TPS*(T2+T3)=34.8≈35

可以看到两者之间的 Vu 数量相差巨大。由于一次迭代的时间会大于事务的响应时间，如果在估算时

不把非事务消耗的时间加入进去，计算出来的 12 个并发用户在测试执行时很有可能无法达到 TPS=5.8

的目标。

由于我们计算 Vu 时，使用的是系统 TPS(登录、浏览、发帖、回帖合计)，其中又以发帖业务消耗时

间最长，所以计算出来的 76 个并发数实际上是系统业务的总并发数，需要按比例分配到各个业务。

业务名称

高峰业务量

TPS

并发数

响应时间

事务成功率

登录

1300

1.44

20

<3 秒

>99%

浏览

2706

3.0

40

<3 秒

>99%

发帖

526

0.58

7

<3 秒

>99%

回帖

676

0.75

10

<3 秒

>99%

合计

5208

5.8

77

-

-

方法 2：在线活动用户数估算

1. 在线用户数的预估可以采取 20%的系统用户数.例如某个系统的系统用户数有 1000，则同时在线用

户数据有可能达到 200，或者预估 200 做参考。

在线用户数和并发用户数又存在着关系，即：平均并发用户数为 C=NLTL 为在线时长，T 为考核时长

例如考核时长为 1 天，即 8 小时，但是用户平均在线时长为 2 小时，则 c=n*2/8

n 为登录系统的用户数，L 为登录的时常。例如一个系统有 400 个用户登录，然后每个用户登录大概

停留 2 小时，则以一天 8 小时考核，算平均并发用户则为 C=400*2/8

答：我们系统的 TPS 当时是根据 PV 值来计算的，就是通过查看系统访问日志来获取每个业务功能每

天高峰期的 PV 值(也就是每天高峰期的时间段，有多少服务器的客户请求)，

当时的 PV 值大概在 5000 多

然后按照二八原则，即 80%的业务在 20%的时间内完成，TPS=(P80%)/(时间 20%)≈5.6。算出来大概

在 5.6。

[具体的指标都是 SE 跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算

方式，差不多是这样的……]

14.13 每人说一个项目接口，你设置多少并发

首先涉及到并发用户数可以从以下几个方面去做数据判断 98

1.系统用户数(注册用户数量)

2.在线用户数(平均每天大概有多少个用户要访问该系统，可以从系统日志从获得)

3.并发用户数(高峰期的时候的在线用户数量)

三者之间的关系

1. 在线用户数的预估可以采取 20%的系统用户数。例如某个系统在系统用户数有 1000，则同时

在线用户数据有可能达到 200，或者预估 200 做参考

2. 在线用户数和并发用户数又存在着关系。即：平均并发用户数为 C=NUTL 为在线时长，

T 为考核时长例如考核时长为 1 天，即 8 小时，但是用户平均在线时长为 2 小时，则 c=n2/8

n 为登录系统的用户数，L 为登录的时常，例如一个系统有 400 个用户登录，然后每个用户登录

大概停留 2 小时，则以一天 8 小时考核，算平均并发用户则为 c=400*2/8

答：就拿登录接口来讲吧

我们的并发数是根据注册用户数量及每天在线用户数综合来估算的，我们系统当时注册用户数量

大概是在 70 多万的样子，不过这里其实有一些僵尸用户，真正的用户大概在 60%的样子，也就是差

不多，46 万多一点，通过查看系统访问日志，高峰期的时候每天在线数,用户数量大概差不多在 52000

多点吧，按 52000 估算，每个用户停留时间大概在 20 分钟左右，大概平均每天同时在线用户数量在

2145 多。其中登录业务的占比大概在 10%的样子，同时在登录的大概 80%的比例计算，登录接口大概

设置的并发数在 172 多的样子，查询业务的占比大概在 30%，查询接口大概设置的井发数在 510 的样

子，下单业务大概占比在 20%，下单接口的井发数设定在 345 的样子。

[具体的指标都是 SE 跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算

方式，差不多是这样的...]

14.14 你们吞吐量是多少，响应时间是多少，你设置了多少井发?

登录：吞吐量大概在 13.5/sec 响应时间<1s，设置的并发数 180 个并发数。

查询：吞吐量大概在 36/sec 响应时间<3s，设置的并发数 500 个并发数。

下单：吞吐量大根在 25.6/sec 响应时间<3s，设置的并发数 350 个并发。

14.15 做井发你们一般 cpu 和内存是多少?

cpu 大概在 60%多点，内存大概占比在 65%的样子

14.16 有没有做过稳定性测试

部分接口有做过稳定性测试。具体怎么做的?

稳定性测试主要就是看某个业务在高并发情况下是否能持续稳定运行嘛，当时大部分的核心业务都有

做过稳定性的，这个需是把并发数设置为峰值，然后循环次数设置为永远，例外要开启调度器，调度99

器中的持续时间设定为 3600 秒，让它持续压测 1 个小时。看下接口的各项性能指标的变化，是否在

预期的指标范围之内。

14.17 5000 个人抢购，只能 50 个人能抢到，你怎么设计并发数的

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为 4000

14.18 微信群里面发送红包，5000 个人群，只能 3000 个人能抢到，你怎么设计并发数的峰值

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为 4000

14.19 20 并发 40 次循环怎么做？

线程数设置 20 个，循环次数 40

14.20 我想从 200 慢慢加载到 300，到 400 怎么做

这个需要用到自定义线程组，自定义线程组最大的好处就在于做压测的时候，可以设置一些复杂的业

务场景，具体设置的话，就是.....

14.21 需要插入 500 条数据，你怎么插入

1、使用存储过程来实现

2、可以通过 JMeter 来实现，调用注册接口，线程数设置为 500，账号，密码可以通过 JMeter 中的

随机函数 randomString()，random()函数结合计数器来实现。

14.22 响应超时，你是怎么定位的

这里一般我会采用排查发，首先考虑软件优化问题，之后考虑硬件问题，思路大概是这样的

1、首先考虑中间件(tomcat，Apache 的连接数的问题)，可以尝试增加连接数，看是否变化。

2、例外还有就是数据库的连接数问可题，也可以尝试增加，看是否有变化。

3、要不就是看数据库的访问效率问题，这里要考虑数据库的操作是否添加索引，如果没有添加索引，

可以让开发优化下数据库的访问速度，添加索引，或者优化 sql 语句。

4、再一个就可以尝试考虑后台代码的架构设计是否合理，代码算法是否足够优化。

5、如果以上问题都不能解决，那么只能考虑增加服务器的 CPU 内存，或者增加网络带宽，看响应时

间是否可以得到优化。

大概的思路差不多就是这样的吧。

14.23 压测返回数据报错，你怎么去定位的

1、如果是所有请求的数据报错，那肯定是脚本问题，认真检查脚本参数。100

2、如果只是部分请求报错，那估计是性能可题了。

14.24 你理解的性能调优是什么?

响应时间过长(排除法) -用户体验不好

1，网络情况(提升带宽)

2，服务器资源情况

3，中间件类型

4，中间件的连接数

5，代码质量问题

6，数据库类型 mysql--Redis

7，数据库连接数

8，sql 语句执行时间

show full PROCESSLIST

查看哪些 sql 语句运行比慢

1、看表是否建立索引

2、运行 sql 语句是否需要 sq 优化

9，索引命中率

低于 0.1%比较好，低于 0.01%分配比校多，适当减少缓存空间大小

show GLOBAL STATUS like "key——read%"

Key_reads=568

Key_read_requests=1329114

Key_cache_miss_rate=key_reads/key_read_requests=0.000427=0.04%

show VARIABLES like "key_buffer_size" #查看缓存空间大小

set GLOBAL key_buffer_size=8000000

#设置缓存空间大小

10，sleep 过多

show GLOBAL VARIABLES like "wait timeout%"

show GLOBAL VARIABLES like "interactive timeout%"

set GLOBAL interactive_timeout= 30

set GLOBAL wait_timeout=30

11，临时表空间大小

性能排优一些方面：

1，排除法

2，很多问题，都是同一个问题导致，需要一个个去排除优化，解决101

资源使用率不足：(系统薄弱的位置)

1，用户量较少

2，网络问题

3，中间件连接数不够

4，代码质量问题

5，数据库问题

资源使用率过高：(系统会崩溃)

1，用户量比较大

2，中间件连接数太大

3，代码质量问题

4，数据库问题

14.25 如果要做万并发，你怎么做

那我们就需要考虑分布式压测，那需要准备几台测试机，

master 机器要设置。。。。

奴隶机要设置。。。。。

也可以租用云测平台进行测试

14.26 如果用户并发要慢慢加载，你怎么设置的

设置并发数的时候，我们会设置启动时间，比如说设置 50 个并发用户数就是 50 个线程组，

启动时间会设置成 10 秒，让用户慢慢启动起来

14.27 并发用户数跟响应时间与吞吐的关系

1，并发用户数越多，响应时间越长

2，并发用户数越多，吞吐量会一直，增加，增加到一个临界点(系统瓶颈后)，不再增加，有少许的

回落

十五、app 测试

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

对于 App 这块，我们一般首先都先做功能，先保证功能过关是第一位，对于功能这块的话，基本都跟

Web 端是一样的。

除了功能之外，公司还要求做了一些专项测试，像：安装，卸载测试，兼容性测试，稳定性测试，性

能测试，弱网测试，交互性测试，都有测试过的，专项测试这块，我主要负责的是：兼容性测试，稳102

定性测试，性能测试，弱网测试，交互性测试，这是我这边负责的。

像兼容性测试，公司有提供了差不多了 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-server103

adb 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

运行的日志，通过看日志来分析具体问题。104

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、忽路一些异常，保证能正常执行完成 105

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

模拟网络不稳定的情况

生活当中，网络并不是固定不变，一般处于不稳定的状态，我们这个时候编写随机数来模拟网络

不稳定的情况106

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

弱网测试，看我们软件在弱网场景下是否会有丢包的现象，丢包率是否严重，页面是否能正

常展示，是否有空白页，数据是否有丢失，页面加载速度是否会严重影响用户体验。