2、测试面试题总结整理_foxqadb

测试面试题总结

功能测试

1.app和web测试的相同点和不同点 ***

相同点：
A.测试用例相同。
B.同样的测试方法：都会依据效果图来检查UI,根据需求文档测试功能。
C.都需要兼容性测试
D.都需要测试应用系统的稳定性。
不同点：
A.App的安装卸载测试（全新安装，升级安装，第三方工具安装，第三方工具卸载，直接卸载删除）,web没有安装卸载一说
B.app消息推送测试，手机授权测试，前后台切换。
C.App的中断测试：来电中断，短信中断，蓝牙，闹钟，拔插数据线，手机锁定，手机断电，手机问题（系统死机重启）。
D.兼容性测试：Web项目考虑不同内核的浏览器兼容，app需要考虑手机不同的操作系统（android/ios），不同的操作系统版本,不同机型，不同屏幕分辨率等。
E.网路测试：不同网络与运营商，目前我国有三大运营商如：电信，移动，联通，不同的网络制式，如：GSM,CDMA,3G，4G，5G等，在不好或无网络的情况下的APP行为。
F.app测试如果设备不足，可以考虑使用云测平台（百度云测，testin云测等）。
1
2
3
4
5
6
7
8
9
10
11
12

2.app测试的关注点/app测试一般测哪些东西 ***

功能测试，安装卸载测试，升级测试，安全性测试，消息推送，前后台切换，ui测试，兼容性测试，网络环境测试，性能测试，中断测试
1

3.web测试的关注点 ***

功能测试，兼容性测试，ui测试 ,安全性测试
1

4.如何确保测试用例覆盖所有需求点 /如何保证产品的质量**

测试用例覆盖率很难达到100%，越复杂的功能越难保证，只能说尽量提高测试覆盖率。

通过以下手段可以提高覆盖率：
1、编写测试用例前，检查相关需求、设计文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
2、然后整理成需要覆盖的功能列表或者思维导图，功能列表包含新增和修改功能点，性能需求也要列出来（因为要整理对应的性能测试用例）
3、需要对既有功能进行一个梳理（显性需求和隐形需求都要分析），还需要检查是否会与其他功能有交互，整理出影响点。
4、把功能列表发给组员，并找时间进行会议评审，主要对功能等进行查漏补缺。
5、最后才行进测试用例编写，注意编写规范。
6、编写完毕后，把测试用例发给组员，开会进行评审，主要对检查点、用例规范进行查漏补缺。
7、执行测试用例过程中，发现用例不完善或者错误，需对测试用例进行及时的修改与调优
8、测试完毕后对漏测的bug进行测试用例补充。
1
2
3
4
5
6
7
8
9
10
11

5.你提交bug的时候提交哪些内容？***

标题，复现步骤，预期结果，实际结果，测试环境，优先级，严重程度，指派给谁，所属模块，附件，缺陷类型
1

6.bug状态/bug流转过程 **

新建：刚发现的缺陷
已指派：已经由测试人员将缺陷指派给开发人员进行处理
已打开：开发人员正在修复缺陷
已修复：开发人员完成缺陷修复，还未进行回归测试
已拒绝：发开人员拒绝修复
已延期：对缺陷进行延缓处理
已关闭：由测试人员回归测试后，缺陷不存在了
重新打开：由测试人员回归测试后，发现缺陷任然存在

7.开发不认bug/如果你发现了一个bug，开发不认，怎么办？***

1.找开发沟通，看他为什么不认,可能有两种情况
2.第一种情况：开发可能说，产品改需求了，
	----我们需要找产品确认，如果是改了，根据新需求改用例，改完重新测试
	----                如果产品说没有改，把他们叫到一起，确认
3.第二种情况：需求没有改，双方理解的需求不一致，一起找产品确定，
	----开发理解的正确，根据新的理解改用例，改完重新测试
	----我们理解的正确，让开发改bug
1
2
3
4
5
6
7

8.bug不能复现咋办？ **

A.首先考虑环境问题，看是否能够还原原来的环境
B.尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现
C.与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面检查出问题
D.保留发生bug时的log，附加到提交的Bug中，希望可以通过log中找到一些蛛丝马迹。
E.查看代码，也许是代码变更，引起的Bug
F.遇到问题就要提，不能放过任何一个Bug，在提交的Bug描述中加上一句话，那就是复现概率，尝试20次，出现一次或尝试10次，交给开发，开发会根据Bug的复现概率，调整改Bug的优先级。
1
2
3
4
5
6

9.你在项目中最经典的BUG是什么？/你印象最深的一个bug ***

开放题，可以说涉及到前后端的问题,将定位饭分析的过程,之前讲过两个业务逻辑（processon上画过图）
比如
	小明在淘宝app 商品详情中 点击了添加购物车 ,然后进入购物车后发现购物车中没有该条商品.
或者
	小明在淘宝app中 支付了一笔订单(微信支付), 然后发现 本应该订单依然还在 待支付中, 待发货中没有该笔订单, 而小明的账户上的钱已经被扣除了.

自己编类似的bug，然后给出分析和定位问题的过程

最终问题是哪里的，你是怎么定位出来的
1
2
3
4
5
6
7
8
9

10.用例评审的流程，通过的规则/审核内容是什么 *

两轮：内部评审，外部评审（产品，开发）

评审内容：
1.用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
2.优先级安排是否合理。
3.是否覆盖测试需求上的所有功能点
4.用例是否具有很好可执行性.例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法
5.是否已经删除了冗余的用例
6.是否包含充分的负面测试用例（反例）。充分的定义，如果在这里使用2/8法则，那就是4倍于正面用例的量，毕竟一个健壮的软件,其中80％的代码都是在“保护”20％的功能实现
7.是否从用户层面来设计用户使用场景和使用流程的测试用例
8.是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
9.用例是否按照公司规定模板进行编写

用例评审的检查项（不用背）：
1.用例是否按照公司定义的模板进行编写
2.用例的本身描述是否清晰，是否存在歧义
3.用例内容是否正确，是否与需求目标一致
4.用例的期望结果是否确定，唯一
5.操作步骤应与描述一致
6.是否覆盖了所有需求 **
7.用例是否冗余 ** 
8.是否具有可执行性
9.是否是从用户层面来设计用户使用场景和使用流程的测试用例
10.场景测试用例是否覆盖最复杂的业务流程
11.是否包含正面，反面的用例  **
12.对于系统自动生成的输出项是否注明了生成规则
13.测试用例应包含对中间和后台数据的检查
14.是否有正确的名称和编号
15.是否标明优先级
16.是否包含配置信息：测试环境，数据，前置条件，用户授权等
17.测试步骤应具体，清晰
18.自动化测试脚本必须带有注解（包括：目的，输入，期望结果等）
19.非功能测试需求或不可测试需求是否再用例中列出并说明
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

11.你们公司测试计划谁写？有哪些内容 *

一般是测试经理/测试组长写，
测试目的，测试资源，测试范围，测试风险（重点），人员分工（重点），测试策略，测试准则，测试进度（重点），测试输出
1
2

12.v模型和w模型 **

13.测试用例（case）/测试点该怎么写（给定业务说测试点，比如水杯测试点，抖音评论/发红包/转账/朋友圈点赞/登录测试点）

分析：可以从  功能，性能，ui，易用性，安全，兼容性，app专项测试（如果是移动端项目的话）  这七方面展开说，采用总分的形式说，先说可以从五方面考虑，再每个方面细说，结合设计测试用例的方法

- 微信红包：
--功能-单个红包：				
1、红包金额为空、0、0.01、200.00、200.01、199.99、200
2、留言输入数字、字母、汉字、特殊字符
3、留言长度
4、留言复制粘贴
5、表情选择收藏表情、其他表情
6、删除表情、重新选择表情
7、选择支付方式 零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数
8、使用指纹确认付款（正确的、错误的指纹）
9、使用密码确认付款（正确的、错误的密码）
10、红包成功发送后 相应支付方式中钱数减少（减少金额与红包金额一致）
11、接受者能看到红包具体信息，红包金额、留言、表情均能正确显示
12、红包被拆开后显示已领取，领取者零钱中增加正确金额，再次领取只能查看红包信息
13、发红包者自己领红包
14、红包24小时未被领取提示红包被退回，相应支付方式中钱数增加（增加金额与红包金额一致），对方不能领红包

-- 功能-群发红包-普通红包：（只写了与单个红包不同的地方）
1、红包个数 为空、0、001、100、99、101
2、红包拆开每个金额一样 均为发红包时设置的单个金额对应的钱数
3、红包被拆时，有相应提示
4、发红包者自己领红包
5、红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加

-- 群发红包-拼手气红包：
1、红包总额/红包个数<0.01
2、红包每个人拆开金额不同，总金额与发红包设置的总额一致
3、红包24小时内拆完后显示最佳手气
4、红包24小时内未被拆完不显示最佳手气

兼容性：安卓、苹果 不同型号版本手机
UI测试：界面无错别字，风格统一, 和设计图保持一致
中断测试：不同应用之间切换、断网、来电、短信、低电量、手机没电
网络测试：2g/3g/4g/5g  WiFi 移动联通电信  弱网  无网　　


- 朋友圈点赞：
-- 功能测试
1.点赞后是否显示结果；
2.点赞后是否可以取消；
3.点赞取消后是否可以重复点赞；
4.共同好友点赞后，是否有消息提醒；
5.非共同好友点赞后，是否有消息提醒；
6.点击点赞人昵称，是否可以跳转到他/她的主页；
7.自己能否给自己点赞；
8.屏蔽了该用户，共同好友点赞是否提示；
9.点赞人有备注时，是否展示备注昵称；
10.点赞后删除好友，是否继续展示其点赞；

-- UI界面测试
1.界面是否简介美观；
2.点赞后动态特效是否正常显示；
3.朋友圈界面图片是否正常显示；
4.朋友圈界面文字是否正常显示；
-- 性能测试
1.点赞人数过多是否能正常显示；
2.同一时间点赞人数过多是否正常收到提示；、
-- 安全测试
1.发送部分可见的朋友圈，其余人不可见；
2.发送部分可见的朋友圈，点赞后共同好友不可见；
-- 弱网测试
1.弱网环境下，点赞是否成功；
2.弱网环境下，点赞的时间；
-- 易用性测试
发送部分可见，是否可以沿用上次的名单；


- 淘宝搜索框：
-- 功能测试：
1.输入可查到结果的正常关键字，检索到的内容、链接准确性
2.输入不可查到结果的关键字，有无错误信息提示
3.输入一些特殊的内容，如空字符、特殊字符等，可引入等价类划分的方法等
4.返回的商品结果排序：价格、销量、评价、综合
5.返回结果庞大时，限制第一页的输出量，需支持翻页
6.多选项搜索：关键字、品牌、产地、价格区间、 是否天猫、是否全国购
7.是否支持模糊搜索，支持通配符的查询
8.网速慢的情况下的搜索
9.搜索结果为空的情况
10.未登录情况和登录情况下的搜索（登录情况下，存储用户搜索的关键字、搜索习惯）

-- 性能测试：
1.压力测试：在不同开发用户数压力下的表现（评价指标如响应时间等）
2.负载测试：看极限能承载多大用户量同时正常使用
3.稳定性测试：常规压力下能保持多久持续稳定运行
4.内存测试：有无内存泄露现象
5.大数据量测试：如模拟从海量数据中搜索结果、搜索出的海量结果列示出来，如何表现等

-- 易用性测试：
1.交互界面的设计是否便于、易于使用
2.依据不同的查询结果会有相关的人性化提示，查不到时告知，查到时统计条数并告知，有疑似输入条件错误时提示可能正确的输入项等等处理
3.查询出的结果罗列有序，如按销量或其他排序综合，确保每次查询的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等
4.标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格隔开）等实用检索方式是否正常
5.输入搜索条件的空间风格设计、位置摆放是否醒目便于使用者注意到，有无快照等快捷查询方式等人性化设计

-- 兼容性：
1.Windows/Linux等各类操作系统下及各版本下的应用
2.IE/Fireox/Goolge/360/QQ/edge等各类浏览器下及各版本下、各种显示分辨率条件下的应用
3.SQL/ORACLE/MySQL等各类数据库存储下的兼容性测试
4.简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
5.iphone/ipad/安卓等各类移动应用平台下的兼容性测试
6.与个相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用

-- 安全性:
1.被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出，是否有安全控制设计
2.录入一些数据库查询的保留字符，如单引号、%等，造成查询SQL拼接出来的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等
3.通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患
4.对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制


- 购物车：
-- 界面测试
1.打开淘宝购物车页面后，页面的布局是否合理，是否完整。
2.不同卖家的商品在不同的table区域显示，区分明显。
3.页面的功能按钮可以正常显示。
4.商品的最下方显示失效宝贝。
5.页面的最低端显示“你可能喜欢”
6.向下滑动页面，在购物车顶端展示“购物车”。
7.购物车中如果存在有商品降价、库存不足、限购件数等，在商品详情的下面，会有对应的字体展示。

-- 基本功能
1.购物车页面的所有连接是否正常。
2.从商品信息页面添加的商品能显示在购物车中。
3.若未登录，点击购物车中的商品直接进行结算，则提示用户输入用户名和密码，或者提示用户进行注册。
4.若没有选择任何商品，点击结算，则提示用户“请添加要结算的商品”。
5.勾选商品后，已选商品的总价（和优惠满减活动）会显示。
6.勾选商品，点击结算按钮后，进去确认订单信息页面。
7.购物车页面中，可以对添加商品信息做信息的修改，并自动保存成功。
8.可以在购物车中重新修改商品规格。
9.购物车能添加的商品种类是有数量上限的。
10.结算的时候商品可以全选，选择底部的全选按钮。
11.可以在购物车页面对宝贝进行管理。

-- 性能功能易用安全界面
1.是否能一件批量付款
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135