2、测试面试题总结整理

admin管理员组

文章数量:1568418

测试面试题总结

功能测试

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云测等）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最终问题是哪里的，你是怎么定位出来的

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.非功能测试需求或不可测试需求是否再用例中列出并说明

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

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

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.可以在购物车页面对宝贝进行管理。

-- 性能

本文标签： 面试题测试