王尘宇

右键“线程组” -> “添加” -> “取样器” -> “HTTP请求”, 输入“服务器名称或IP”，对应的端口号，http默认端口号80，可以不写。

以下请求为POST, 所有“方法”那选择“POST”，输入对应的路径，添加参数及值。

右键“线程组” -> “添加” -> “监听器” -> “察看结果数”, 添加“察看结果数”，以察看运行后的结果，如图所示。

数据补充完整后可点击菜单栏目中“启动”按钮以启动测试，如图所示。

运行结束后可在结果树中查看返回结果

简单来说，jmeter操作过程就是：

1、新建一个线程组

2、输入HTTP请求

3、设置一个或者多个断言，增加监听器

4、运行后查看结果树

 Linux常用命令举例：

   答：cd ..返回上一级目录；cd ../..返回上两级目录；ls查看目录中的文件；ls -F查看目录中的文件；ls -l显示文件和目录的详细资料；ls -a显示隐藏文件；tree 显示文件和目录由根目录开始的树形结构(1)；lstree显示文件和目录由根目录开始的树形结构(2)；mkdir dir1创建一个叫做’dir1′ 的目录’；mkdir dir1 dir2同时创建两个目录；find / -user user1搜索属于用户’user1′ 的文件和目录；mv dir1 new_dir重命名/移动 一个目录

 数据库常用SQL语句：

答：以常见的增、删、改、查为例：

[if !supportLists]1）[endif]增：插入指定列：insert into 表名(列1,列2,…,列n) values(值1,值2,…,值n);

插入所有列：insert into 表名 values(值1,值2,…,值n);

一次插入多行：insert into 表名 values

(值1,值2,…,值n),

(值1,值2,…,值n),

…

(值1,值2,…,值n);

2）删：delete from 表名 [where 条件]

3）改：update 表名 set 列1=新值1,列2=新值2,…,列n=新值n [where 条件];

4）查：查询部分列：select 列1,列2,…,列n from 表名 [where 条件];

查询所有列：select * from from 表名 [where 条件];

测试过程中遇到一个bug,开发不认为是bug如何解决？

     答：该问题是面试时常见问题，没有固定答案，但是该问题能够反映出测试人员在发现问题后，如何解决问题的能力，能够体现出候选人的主动解决问题的能力和思路，作为一名测试人员，发现并主动解决问题最为关键，这里列出几点，便于HR参考：

首先分析下到底会有哪些原因会导致开发不修改bug：

1、开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

2、工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况

3、当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因

4、另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

我们逐条分析并列出简单的解决方案：

[if !supportLists]1. [endif]针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点：

[if !supportLists]1）[endif]从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性。

[if !supportLists]2）[endif]可以和开发人员列举一个之前的类似问题，为开发提供参考。

[if !supportLists]3）[endif]产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

[if !supportLists]2. [endif]上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改。

[if !supportLists]3. [endif]修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案。

[if !supportLists]4. [endif]第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题。

bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。

 测试用例设计题：

（此处三个小问题是抖音项目组常问问题，这里主要考察候选人测试用例设计思路，测试用例设计的覆盖率，抖音项目组对测试用例覆盖率要求严格，覆盖率越高面试通过率越高）

回答此处问题时，结合APP测试的特点进行回答，针对APP测试专项测试如：手机操作系统iOS、安卓、兼容性、后台应用、通知、短信提醒、弱网、消息提醒等用例此处不做重复介绍，详细请见问题一，但是候选人在回答问题时需要答出，下面详细介绍点赞功能。

[if !supportLists]1）[endif]微信朋友圈点赞功能

功能类：1、首先检查朋友圈可见权限设置，针对不同的权限、好友关系设置哪些好友可见

[if !supportLists]2、[endif]设置单个好友可见时，发送一条朋友圈，对方好友是否可见；

[if !supportLists]3、[endif]可见之后是否有可展开的操作栏（其中包括点赞和评论）；

[if !supportLists]4、[endif]多次点击后操作栏是否能够重复展开或退回

[if !supportLists]5、[endif]点赞功能：UI检查，是否有点赞图标，点赞提示，评论图标，评论提示

[if !supportLists]6、[endif]点击点赞图标后，图标是否有点赞成功提示；

[if !supportLists]7、[endif]点赞成功后点赞提示是否变为取消点赞；

[if !supportLists]8、[endif]点赞成功后是否在该条朋友圈下有点赞人姓名及图标；

[if !supportLists]9、[endif]点赞成功后，是否在被点赞人朋友圈处出现被点赞数统计提示；

[if !supportLists]10、[endif]被点赞人点击被点赞的提示后，页面是否跳转至被点赞朋友圈处，并显示已点赞的好友图标；

[if !supportLists]11、[endif]设置多个好友可见时，重复点赞步骤后，被点赞人查看个人朋友圈，是否能够展示所有点赞人的图标，统计数量；

[if !supportLists]12、[endif]若多个好友同时点赞，被点赞人收到赞时页面展示是否按照点赞时顺序排序；

[if !supportLists]13、[endif]多个人同时点赞时，顺序如何排序。

[if !supportLists]14、[endif]若其余几位点赞人之间不互为好友关系，是否能够看到对方点赞情况。

[if !supportLists]15、[endif]若有个别人员是好友关系，能否通过点赞的头像进入对方信息；

[if !supportLists]16、[endif]点赞之后该条赞能否一直保持

[if !supportLists]17、[endif]若该条朋友圈被删除，点赞的讯息是否也被删除

[if !supportLists]18、[endif]取消点赞，只能对已点赞的朋友圈进行取消点赞；

[if !supportLists]19、[endif]在已点赞的朋友圈下点击操作栏，是否弹出取消点赞的图表及提示

[if !supportLists]20、[endif]点击取消后是否提示已取消点赞；

[if !supportLists]21、[endif]取消的点赞后是否可以再次点赞；

[if !supportLists]22、[endif]取消点赞后是否会通知被点赞人；

[if !supportLists]23、[endif]设置朋友圈可见限制，当被点赞人收获很多赞之后，关闭朋友圈可见，那么被点赞人是否能够看到自己收获点赞统计，其点赞好友是否能够看到已点赞的信息；

（以上用例仅为参考，若有不足之处可以增加补充，完善用例）

 场景问题解决：

如果在购物平台上选购了物品，并且成功支付，但在“我的订单”中没有查到该笔订单，此时怎么处理？

（该问题旨在考察候选人在面临场景问题时的处理问题能力，并且如何准确定位问题，解决问题的思路，答案不固定）

答：测试人员发现问题后，先确认该问题是否满足需求，若在需求要求下，则：

1.重现问题：如果是测试环境，可以再做一笔订单，详细记录该笔订单讯息，检查该问题是否为偶发性问题，此处分两种情况：

[if !supportLists]1）[endif]若该笔订单能够查到，则需判断，没有找到订单的那笔有可能是偶发现象，需明确记录；

[if !supportLists]2）[endif]若该笔订单还是无法找到，则需确定是前端还是后端问题。

[if !supportLists]2. [endif]排查问题：若为web类测试，通过开发者工具查看界面返回结果，若“我的订单”中有返回值，但在页面中没有展示，需找前端同事确认是否是做数据处理时没有展示结果；若“我的订单”中没有返回值，有可能是数据没有传给前端，需确认是否是接口没有返回或数据传输丢失。此时可以通过检查数据库对应表格、或者用抓包工具检查接口是否报错。若为APP类测试，通过抓包工具检查接口返回，同时检查数据库中对应表，是否有存储该笔数据。

[if !supportLists]3. [endif]确认是前端或后端问题后，可以截图发送给对应同事确认问题，并将该问题提交至缺陷管理工具中，并及时跟踪问题。若问题较严重并短期内无法解决，需及时与负责人，项目经理联系，及时汇报该问题。

[if !supportLists]4. [endif]若该问题为偶发问题，需记录该笔订单详细情况，并在后期测试中重点关注，若经过几个迭代后该问题没有再次出现，则可降低该问题等级，但仍需留意。