软件测试工程师面试题总结

基础问题

 

1、测试理论、流程

1、测试流程？工作怎么开展？

阶段	工作内容	说明
需求阶段	需求评审	产品经理组织，项目组全员和测试组长参与
	测试工作估时	用例设计、功能和接口测试（开发服和测试服）、专项测试（兼容、性能、安全）
开发和测试阶段	输出测试思路XMind	参考测试思路模板
	测试思路XMind内审	由测试组长牵头评审，审查测试思路的合理性与充分性
	评审测试思路XMind	测试工程师组织，项目组全员和测试组长参与
	输出自测用例	按约定的提测点的提测顺序输出
	输出完整用例	按约定的提测点的提测顺序输出
	评审测试用例	开发负责人和测试组长review
	执行用例	详细记录用例执行情况
	BUG验收和回归	BUG验收的时候要确保开发给出了修复的影响面
	回归测试	对复杂度较高的或通过率较低的提测内容进行回归测试
	专项测试	兼容测试，性能测试，安全测试
	整体冒烟测试	不允许出现主功能冒烟测试不通过的情况
发布阶段-测试服	配置测试	ToDoList中开发列出的修改或新增的配置，需要进行对应的测试
	冒烟测试	不允许出现主功能冒烟测试不通过的情况
	正式数据测试
	重点功能测试	不允许出现主功能冒烟测试不通过的情况
	输出上线确认书	各个负责人签名后提交纸质版给技术总监确认
发布阶段-正式服	配置测试
	冒烟测试
	发送上线邮件	发送项目组，抄送质控组，以及其他需要告知的人员
测试总结	测试总结	总结测试全生命周期各阶段测试情况，包括用例执行情况、软件缺陷情况、质量度量情况以及风险情况

2、项目开发中，开发模型？

敏捷开发模型。以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

2、测试文档相关

1、测试计划

测试计划一般包括以下一些方面：

1.测试背景。在进行测试项目前，先要清楚这个软件项目的背景介绍，还有项目设计了哪些参与人员，例如软硬件项目负责人等，参与人员的介绍及联系方式都需要记录清楚。

2.测试依据。主要包括了软件需求文档，软件规格书，软件设计文档，及其他参考产品等。

3.测试资源，在测试计划上详细写出每一项需求，例如测试设备需求，测试人员需求，测试环境需求等其他需求。

4.测试策略。在测试计划上详细写出采取的测试方法，搭建哪些测试环境，采取哪些测试工具以及测试管理工具，对人员进行培训等。

5.测试日程。主要包括了测试需求分析，测试用例编写，测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

2、测试用例

用例的构成要素为：测试用例编号、所属模块、用例类型、测试用例标题、关键词、优先级、前置条件、步骤、预期结果。

1. 测试用例编号：每个测试用例都有一个唯一编号
2. 所属模块：此测试用例测试的大模块。
3. 用例类型：包括功能测试、配置测试、兼容测试、性能测试、安全测试。
4. 测试用例标题：描述测试用例的语句。
5. 关键词：概括描述用例的测试目的，非必要字段。当无法直观地理解到测试用例的测试目的时，可以使用关键词辅助理解。
6. 优先级：按照测试用例的重要性来给不同的测试用例分级别。
7. 前置条件：执行此测试用例之前需满足的条件。
8. 步骤：测试人员执行用例需要进行的操作。
9. 预期结果：操作步骤的预期结果，包括界面的显示、业务数据、数据库数据、日志等等。

3、测试报告

从以下方面进行测试报告的编写：

1、测试背景说明
2、测试范围说明
3、测试环境说明
4、测试方法说明
5、测试结果与缺陷分析，主要从功能性能方面来分析
6、测试结论与建议
7、质量或风险评估

3、Bug定位与跟踪

1、bug如何定位

BUG类型：
   - 代码错误：逻辑错误，初步定位是前端问题或后端问题后，选择BUG类型为代码错误-前端或代码错误-后台，
如果是前后端都需要跟进修复的BUG，则选择BUG类型为代码错误。
   - 需求问题：未明确或不合理的需求。
   - 界面优化：页面字体大小不统一、排列不整齐，必填项未做标识；字体乱码，字段错误等。
   - 配置相关：如web服务器或者数据库服务器配置等问题，或者程序配置有误而引起的问题。
   - 安全相关：安全测试发现的BUG。
   - 性能问题：性能测试发现的BUG，或单个接口开发服环境超过300ms、正式服超过200ms。
   - 遗留问题：正式服发现的、用户反馈的问题。
   - 设计缺陷：接口设计和模型设计等系统设计不合理、考虑不周而引起的问题，或建议修改的地方。

2、bug优先级

 严重等级：

严重等级	定义	说明
1	崩溃阻塞	系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
2	严重	影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
3	一般	界面、性能缺陷、兼容性。
4	轻微	易用性及建议性问题。
？	不确定	不明确时可选，需要知会测试组负责人。

优先级：

优先级等级	说明
1	需要立即解决
2	当天修复，不允许过夜
3	24小时内修复
4	24小时内修复，风险较小的BUG
？	不明确时可选，需要知会测试组负责人

3、如何区分前后端bug

前台的bug通常是功能、界面和兼容性等有关；

后台的bug与逻辑、性能和安全性有关。

与数据相关的错误、排序问题大多是后台问题；

对于APP页面toast提示可能是后台给的，可能是APP给的。

通过抓包工具来进行抓包分析。

大多数的浏览器都有自带的抓包插件，如 FireFox 的 FireBug 插件，Chrome、360急速模式、搜狗高速模式自带的 DevelopTools 插件（F12开启），在 NetWork 中可以看到当前页面发送的每一个http请求。请求接口、传参、响应三部分来判断Bug，另外，也可以在浏览器的控制台进行js代码调试定位。

4、如何提交一个高质量的bug

创建BUG时，测试工程师必须保证已经找到稳定重现的步骤。并按照以下要求描述bug：

  - 包含步骤、结果、期望；

   - 步骤描述要清晰直观，尽量直接采用用例的步骤；

   - 结果尽量附图说明，并将重点位置标识出来；

   - 说明期望的结果，以及需要开发、产品反馈的信息等等。

5、提交一个bug，但开发认为不是bug，怎么处理

开发人员说不是bug，有2种情况，
1、需求不确定
可以找来产品经理进行确认需不需要改动，三方商量确定好后再看要不要改。
2、这种情况不可能发生，所以不需要修改
这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

6、碰到复现率低的bug如何处理

1. 仔细检查是否是自己的执行步骤，或者误操作导致的bug，提交给相关人员
2. 通过日志相关信息处理，提交相关开发人员
3. 通过截图方式尽量复现当时的情景
4. 和相关测试人员商议，确定bug的优先级与开发沟通，猜测可能出现问题的地方，在代码中设桩，添加状态打印信息，进行有针对性的测试。
5. 考虑采用自动化，进行压力测试，测试过程中注意收集log信息，统计bug出现的概率。
6. 关注发布后的用户反馈，跟进bug

7、印象深刻的bug?问题产生的原因？

在用安卓手机进行app中上传头像的测试时，个人信息上传头像成功了，但是换成苹果手机时，头像上传失败。通过分析得知该功能前端代码与不同系统、不同版本间的不兼容。测试时应该要充分测试足够的系统，版本，机型的兼容性。

8、线上出现bug如何处理 

线上问题的处理是测试工程师的一项重要的职责。测试人员要尽可能的保证问题在上线前发现并解决，万一问题遗漏上线，测试人员也要积极处理，保障业务系统的正常运行。

通过线上问题的处理，既可以让我们了解项目代码中的问题并修复，又可以让我们找到项目组的流程、管理、技术等各方面的短板来补齐，这样才能成为一名优秀的测试工程师。

开发人员修复Bug之后，测试人员需要反思。
 

4、计算网络技术

1、OSI七层模型？

       应用层：产生网络流量的程序

       表示层：传输之前是否进行加密或者压缩处理

       会话层：查看会话，查木马  netstat-n

       传输层：可靠传输、流量控制、不可靠传输

       网络层：负责选择最佳路径、规划ip地址

       数据链路层：帧的开始和结束、透明传输、差错校验

       物理层：接口标准、电器标准、如何更快传输数据

2、tcp三次握手？四次挥手？

客户端和服务端通信前要进行连接，“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。
从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。
第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。

TCP连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个ACK，此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个FIN段来关闭此方向上的连接。接收方发送ACK确认关闭连接。注意，接收到FIN报文的一方只能回复一个ACK, 它是无法马上返回对方一个FIN报文段的，因为结束数据传输的“指令”是上层应用层给出的，我只是一个“搬运工”，我无法了解“上层的意志”。

3、http/https协议区别？ 

1、HTTPS  协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https 。)

2、HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。

3、HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
 

5、linux系统操作使用

1、常用命令？查看日志？系统资源监控命令？

常用命令：

cd：切换目录

ls：列出当前目录的所有文件、文件夹（目录）信息

pwd：列出当前目录的路径

whoami:确认当前登录用户的身份

cp：复制文件或目录

mv：移动文件或目录

grep：在文件中查找关键词

find：查找文件

ps：查看进程

kill：结束进程

cat：查看文件内容

tar：打包

ifconfig:查看ip地址

ping:检查网络是否连通

mkdir :创建文件夹

touch：创建空文本文件

rm：删除

vi:创建文件或编辑

cp：复制文件或目录

mv：移动文件或目录

head:查看文件的前几行

tail ：查看文件的后几行

less ：查看当前文档内容

more：分页展示

chmod：更改目录和文件权限值

chown：更改文件或目录的属组或属主

6、数据库操作

1、增删改查sql编写

查看数据库：show detabases;                      使用数据库：use 数据库名；

创建数据库：create database 数据库名；     删除数据库：dorp database 数据库名；

创建表：create table 表名（列名1 类型 约束）；       删除表：dorp table 表名；

  修改表：alter table 表名 change 列名  列名 新类型；

查询表中所有的信息：select * from 表名； 

查询表中指定列的信息：select 列1，列2 from 表名；

条件查询：select 列.. from 表名 where 条件；

               

2、多表关联，左右连接查询

1、左连接  left join 或 left outer join

SQL语句：select * from student left join course on student.ID=course.ID

2、右连接  right join 或 right outer join

SQL语句：select * from student right join course on student.ID=course.ID

完全外连接  full join 或 full outer join

SQL语句：select * from student full join course on student.ID=course.ID

3、索引？存储过程？视图？

1.创建索引:

CREATE INDEX 索引名 on 表名

索引类似于一本书的目录，可以提高数据检索的效率，降低数据库的IO成本，索引的目的是为了更快速找到数据。

2.创建存储过程

CREATE PROCEDURE p_find()

存储过程是一段写好的SQL代码，它是存在数据库的目录中，外部程序可以直接调用数据库里面定义好的存储过程。

3.创建视图

CREATE VIEW v_find AS SELECT id;

视图(view)也被称作虚表，即虚拟的表，也就是说该表里面没有数据，他的数据是从别的基础表中获取的，是一组数据的逻辑表示；视图本身并不包含任何数据，它只包含映射到基表的一个查询语句，当基表数据发生变化，视图数据也随之变化；视图也是一张表，对于基础表的所有基础操作（增删改查），视图也适用。

 额外加分问题

1、Jmeter/postman

1、接口测试流程？你接口测试如何做的？

• 通过开发给的接口文档去了解接口有哪些内容，首先，接口文档应该包含以下内容：

1）接口说明
2）调用url
3）请求方法（get\post）
4）请求参数、参数类型、请求参数说明
5）返回参数说明

• 了解业务需求及业务流程

• 编辑接口用例

•  执行接口用例

1）接口用例写好后，用postman或jmeter、fiddler工具，进行接口测试

2、接口测试用例设计？关注点？

1）类似模板

2）如何编写接口的用例？
其实接口的用例与功能测试的用例类似，下面简单的写下，比如说：
A功能测试，用例标题：
输入正确的用户名、密码规范，注册成功
用户名不规范，注册失败

 

3、http请求包含的内容？

1）请求(客户端->服务端[request]) 
    GET(请求的方式) /newcoder/hello.html(请求的目标资源) HTTP/1.1(请求采用的协议和版本号) 
    Accept: */*(客户端能接收的资源类型) 
    Accept-Language: en-us(客户端接收的语言类型) 
    Connection: Keep-Alive(维护客户端和服务端的连接关系) 
    Host: localhost:8080(连接的目标主机和端口号) 
    Referer: http://localhost/links.asp(告诉服务器我来自于哪里) 
    User-Agent: Mozilla/4.0(客户端版本号的名字) 
    Accept-Encoding: gzip, deflate(客户端能接收的压缩数据的类型) 
    If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT(缓存时间)  
    Cookie(客户端暂存服务端的信息) 
    Date: Tue, 11 Jul 2000 18:23:51 GMT(客户端请求服务端的时间)

2）响应(服务端->客户端[response])
    HTTP/1.1(响应采用的协议和版本号) 200(状态码) OK(描述信息)
    Location: http://www.baidu.com(服务端需要客户端访问的页面路径) 
    Server:apache tomcat(服务端的Web服务端名)
    Content-Encoding: gzip(服务端能够发送压缩编码类型) 
    Content-Length: 80(服务端发送的压缩数据的长度) 
    Content-Language: zh-cn(服务端发送的语言类型) 
    Content-Type: text/html; charset=GB2312(服务端发送的类型及采用的编码方式)
    Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT(服务端对该资源最后修改的时间)
    Refresh: 1;url=http://www.it315.org(服务端要求客户端1秒钟后，刷新，然后访问指定的页面路径)
    Content-Disposition: attachment; filename=aaa.zip(服务端要求客户端以下载文件的方式打开该文件)
    Transfer-Encoding: chunked(分块传递数据到客户端）  
    Set-Cookie:SS=Q0=5Lb_nQ; path=/search(服务端发送到客户端的暂存数据)
    Expires: -1//3种(服务端禁止客户端缓存页面数据)
    Cache-Control: no-cache(服务端禁止客户端缓存页面数据)  
    Pragma: no-cache(服务端禁止客户端缓存页面数据)   
    Connection: close(1.0)/(1.1)Keep-Alive(维护客户端和服务端的连接关系)  
    Date: Tue, 11 Jul 2000 18:23:51 GMT(服务端响应客户端的时间)

4、get、post方法区别？

• 最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。
• GET产生一个TCP数据包；POST产生两个TCP数据包。

  GET请求：浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

  POST请求：浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

• 1. GET与POST都有自己的语义，不能随便混用。

  2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

  3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

5、cookie、session、token理解？区别？

Cookie总时由用户客户端进行保存的，按其存储位置可分为：内存式Cookie和硬盘式Cookie。内存式Cookie存储在内存中，浏览器关闭后就会消失，因此也被称为非持久Cookie或会话Cookie。硬盘式Cookie保存在硬盘中，其不会随浏览器的关闭而消失，除非用户手工清理或到了过期时间，因此也被称为持久Cookie。

• Session和Cookie区别

1.Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。  

2.Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。

3.Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。

4.Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

• Session与Token的区别

1.token和session都是为了身份验证，session被翻译为会话，token被翻译为令牌。

2..身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全。

3.session和token都需要去管理过期时间。

4.时间与空间的博弈：session是空间换时间，而token是时间换空间。

• Cookie原理

Cookie定义了一些HTTP请求头和HTTP响应头，通过这些HTTP头信息使服务器可以与客户进行状态交互。客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，客户端会在请求信息中包含一个Cookie请求头，而服务器会根据这个请求头进行用户身份、状态等较验。

• Session原理

当你一次访问服务器的时候，服务器会在内存中开辟一块空间，返回唯一一把打开该空间的钥匙，再把这把钥匙返回到浏览器。当你第二次访问的时候浏览器会携带这把钥匙到服务器端打开对应的空间，如果该空间已经销毁又重新返回开辟一块新的空间返回新的钥匙到浏览器。

• Token原理

浏览器第一次访问服务器，根据传过来的唯一标识userId，服务端会通过一些算法，如常用的HMAC-SHA256算法，然后加一个密钥，生成一个token，然后通过BASE64编码一下之后将这个token发送给客户端；客户端将token保存起来，下次请求时，带着token，服务器收到请求后，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过，返回不通过信息。
 

2、fiddler抓包

1、fiddler在工作中的应用

• fiddler抓取手机应用数据包

1.安装fiddler，官网下载即可
2.安卓手机一部，能连接wifi
3.打开fiddler,点击tools,
打开Fiddler的Options菜单，进入"HTTPS"的TAB页面，依次配置如下选项：
1、勾选"Decrypt HTTPS traffic"选项
2、选择下拉列表的"from remote clients only"选项
3、勾选"Ignore server certificate errors"选项
4、通过"Actions"按钮选择"Export Root Certificate to Desktop"将证书导出到电脑桌面上，默认的文件名为"FiddlerRoot.cer"

 5.在"Connections"的TAB中，我们需要设置一个端口号，这个端口号就是手机端设置WIFI代理时自定义的端口，刚才我们设置了6666或8888，然后勾选"Allow remote computers to connect"选项，此时提示一定要重启Fiddler才能生效。

 6.cmd 查看自己电脑的无线网络IP地址
ipconfig 

7.保证fiddler 开启并设置好端口6666或8888， 用手机连接wifi 和电脑一直，设置手机代理

 

 8.把从fiddler中导出的证书，用QQ传输到手机端， 手机端需要安装刚才Fiddler导出的证书，首先把证书放入手机的内置或外置存储卡上，然后通过手机的"从存储设备安装"菜单安装证书。

 之后就可以在fiddler上抓取手机https的请求了。

• fiddler设置断点

1、选择fiddler菜单中Rules->Automatic Breakpoints->Before Requests，设置断点，也可以使用快捷键F11；

 2、如果底部显示一个红色标识，证明设置断点成功了

 3、设置断点后，会自动拦截所有网页，对于不需要修改数据包的链接，直接点击右侧绿色的Run to completion；或者直接修改数据包，修改完成后，点击Run to completion，fiddler会把拦截的网页发送到服务器，再继续拦截跳转的下一个网页

 4、进行完修改数据包等操作后，可取消断点，让fiddler继续抓包，选择菜单Rules->Automatic Breakpoints->Disabled，或按快捷键shift+F11

 5、取消断点前，会拦截最后一个数据包，此时再次点击run to completion，fiddler不再拦截网页，继续抓包

• 修改请求数据

1、在浏览器中输入需要抓取的数据，先不点击提交按钮

2、打开fiddler，制定规则（拦截请求会话）、清空控制面板Ctrl+X、开始抓起数据capturing

 

3、点击浏览器的数据提交按钮

4、在fiddler面板中一条条查看拦截的数据，寻找自己想要修改的数据会话

5、修改会话的textview数据

6、点击 “run to completion ”、对拦截的下一条请求数据执行run to completion 直到浏览器中响应数据出现。

 

• 修改响应数据

1、在浏览器中输入需要抓取的数据，先不点击提交按钮

2、打开fiddler，制定规则（拦截响应会话）、清空控制面板Ctrl+X、开始抓起数据capturing

 

3、点击浏览器的提交按钮

4、在响应数据面板中，将数据报解密，当响应数据修改完，还要将加密状态修改为初始值

 5.加密状态修改回初始值后，点击run to completion ，对每个拦截的响应会话执行run to completion ,直至响应完成。

2、抓取移动端的数据？https请求？ 

    （1）手机设置代理IP，连接到电脑

    （2）电脑打开接收远程数据包功能，设置端口号

•     （3）查看HTTP包在整个网络的活动，查看HTTP包的具体信息。

3、app专项测试

• abd?  monkey?   app日志抓取及分析

1.monkey的简单介绍
Monkey测试是Android app自动化测试的一种手段，Monkey测试本身非常简单，就是模拟用户的按键输入，触摸屏输入等，看设备是否出异常。
当Monkey程序在模拟器或设备运行的时候，如果用户出发了比如点击，触摸，手势或一些系统级别的事件的时候，它就会产生随机事件，所以可以用Monkey用随机重复的方法去测试app.
一般情况下单个app monkey 模拟测试10万次足矣。

2.以下是app monkey测试的详细步骤

1. 先进入cmd界面，输入adb devices，查看是否正常连接。
2. 输入adb logcat | findstr START 监控app,打开你要测试的app，cmd查看app的包名。cmp=右边的就是app的包名。
3. 输入adb logcat -c 先清除下logcat日志信息
4. 输入adb logcat -v time >F:\logcat.log
5. 输入adb shell monkey -p +app包名 -v 10000 >F:\monkey.log

3通过adb命令做回归测试
当开发修改问题后，需要做回归测试验证是否修改ok，此时测试人员需要使用上一次跑的monkey测试中的seed值做回归测试。
adb shell monkey -p +包名 -s +seed值 -v 10000
比如
adb shell monkey -p com.shanjian.originaldesign -s 1536629919450 -v10000

4.命令解析
-v 较少的日志信息
-v -v 较为丰富的日志信息
-v -v -v 最高级别的日志信息

5.monkey日志分析
当monkey测试时出现问题，此时我们需要分析定位问题，我们需要分析monkey日志
崩溃问题：在日志中搜索“Exception“
Monkey测试出现的异常的原因：
一般是两种原因导致的，一个是crash 程序崩溃，导致crash原因如下
a)、程序存在空指针
b)、cpu不足
c)、内存不足

另一种是ANR 程序无响应，导致anr无响应原因如下：
a)、线程阻塞
b)、cpu不足
c）、内存不足

查找分析原因：

1. 当monkey测试出现异常终止，请打开logcat日志搜索关键字‘anrin’,如果存在该关键字，说明app出现了ANR异常，我们需要把/data/anr目录下的trace.txt文件取下来。
2. 取下来trace.txt文件后，将出现问题的进程号对应的日志发给软件工程师定位，如果在logcat日志里没有搜索到’anrin’关键字，就搜索’nullpointer’异常关键字的上下日志，发给开发定位
3. 当出现ANR后，需要导出,步骤如下：
4. 输入adb shell
5. 输入cd /data/anr/
6. 输入ls
7. adb pull /data/anr d:\trace.txt
8. 在logcat将出现anr问题的进程号复制，然后在trace.txt文件里按ctrl+F 查找，粘贴进程号，查找对应的问题

• app弱网测试工具fiddler应用？

第一步：打开模拟弱网环境

第二步：打开配置文件

 

 第三步：修改配置参数  m_SimulateModem，修改后最好 Ctrl+S 保存一下

 第四步：修改好参数返回后需要再次打开弱网环境

 

• app性能测试工具PerfDog应用？

1、移动全平台iOS/Android性能测试、分析工具。主要用来收集APP的性能数据。

连接手机

安卓

• 使用数据线进行连接
• 下载手机助手电脑版，使手机连上电脑（注意要开启USB调试）
• 在PerfDog即可选择该设备

 

iPhone

• 下载爱思助手，使其连上iPhone
• 在PerfDog连接上该设备即可

手机性能数据收集步骤

1.手机连上电脑，在perfdog中选择已经连接好的收集
2.选择被测试的应用
3.手机上打开被测试的应用

 4.perfdog中选择需要收集的性能数据（右下角加号）

 5.点击录制按钮
6.可以在右上角点击标签，来区分性能测试场景

 7.录制结束后，将性能数据保存

分析性能数据

1. CPU：需要根据手机的配置来决定，一般情况下建议不超过10%即可。游戏除外
2. 内存：要根据应用情况以及手机配置来分析（此内存为运行内存，游戏软件另外考虑）
3. FPS：帧率，流畅度。一般的软件大概在30~40？游戏在60左右体验会较好
4. 网络：主要关注上下行的速度
5. 温度：一般来讲不超过40度。主要是使用过程中不能让用户觉得烫手。
6. 能耗：耗电量越少越好（主要也是看手机电池的大小）
    

• app兼容性如何进行测试？

APP兼容性的测试主要包含硬件设备兼容性、操作系统兼容性、分辨率兼容性、网络运营商兼容性、其他软件兼容性几个大类。

硬件兼容性

1. 测试对象：一般需覆盖市面上主流的手机厂商及各型号产品，可在百度等一些统计类的大数据网站获取最新的市场占有率排行，一般要考虑厂商、型号来组合挑选。
2. 测试环境：需要真机环境测试，可购置相应手机进行，或者在Testin、百度MTC、阿里MQC、腾讯WeTest等云测试平台进行。
3. 测试点：APP的安装/卸载，APP的正常运行

操作系统兼容性

1. 测试对象：需覆盖市面上主流的操作系统及各版本，可在统计网站获取最新的操作系统市场占有率，iOS直接挑选相应的操作系统，Android则根据Android系统版本和各厂商在其之上的定制版本做一些组合挑选（这里手机的挑选可以跟硬件兼容性一同交叉考虑）
2. 测试环境：iOS可通过模拟器进行，Android往往仍需要真机测试，若对厂商定制的操作系统考虑风险较小不进行测试，则也可通过模拟器进行。当然也可以同硬件兼容性一样在云测平台上进行测试。
3. 测试点：APP的安装/卸载，APP的正常运行，核心功能的回归

分辨率兼容性

1. 测试对象：需覆盖市面上主流的各种屏幕分辨率、屏幕尺寸。这里主要关注的是UI上对各种分辨率、屏幕尺寸的适配情况。
2. 测试环境：iOS可通过模拟器进行，Android往往仍需要真机测试，若对厂商定制的手机屏幕尺寸考虑风险较小不进行测试，则也可通过模拟器进行。
3. 测试点：APP的界面显示、排版等各类UI测试

网络运营商兼容性

1. 测试对象：在不同的网络制式、运营商下，APP能够正常工作。一般需要覆盖主流的网络运营商。
2. 测试环境：需要真机环境测试，需要连接各主流网络运营商提供的网络
3. 测试点：挑选核心包含网络请求的功能进行测试

与其他软件的兼容性

1. 测试对象：各主流的APP，可在各大应用市场获取APP的排行，按照分类、下载量等进行组合挑选
2. 测试环境：往往iOS、Android任选一款机型进行测试即可
3. 测试点：在已安装其他APP的前提下安装/卸载待测APP、在已运行其他APP的前提下运行待测AP、在已安装待测APP的前提下安装/卸载其他APP、在已运行待测APP的前提下运行其他APP

个人问题

• 一个优秀的测试工程师应具备什么样的素质？

1.持续不断的自我提高和总结      

不断总结、不断反思，才能持续进步

2.积极主动

只有当测试人员足够主动，项目进展才会更加神速

3.质疑精神    

永远不要理所当然认为是没问题的，问题都是深度挖掘出来的；你能做得多好，取决于你能思考多深！

4.良好沟通交流的能力    

良好的人际关系，将是任务开展强劲的推动力

5.强烈的责任感      

在其位，谋其政，认真做好自己的本职工作，对自己、对他人都要有责任心

• 作为测试，如何去保证软件产品质量？

考虑从以下方面提升软件质量：
1，项目流程的规范程度，包括需求管理、开发流程、测试流程
2，测试资源的充分程度，包括人（质与量）、时间、环境、工具等
3，测试技术的高度，如测试计划的合理性，用例设计的全面性、粒度、效率，以及测试执行的充分性