软件测试必问必背面试题

3、面试问题****

3.1、功能测试****

3.1.1、介绍一下你们的功能测试流程（基本工作流程）****

介绍测试测试流程，记得不能只罗列各个环节，要在一些重要或者你比较熟悉的环节进行适当的展开（说一些细节，具体可参考3 .1.2 测试流程详解）****

也可以结合项目进行介绍，参照2项目介绍。****

总体流程：****

测试需求分析---测试点提取（xmind）-----编写测试计划及评审----编写测试用例及评审---执行测试用例（开发提交测试后）-----发现缺陷通过禅道提交-----回归测试及bug验证（开发提测新的版本）-----测试报告编写及评审****

3 .1.2 、软件测试流程详解（说说你们的测试流程）****

1. 测试需求分析****

理解需求，会用软件系统，分解功能点，在依照功能点提取测试点（等价类，边界值，因果图。。。。）

使用xmind（相互独立，完全穷尽）

2. 测试计划（先了解测试的任务量才能制定测试计划）****

目的，背景，进度计划，人力资源，软  硬件资源，策略（方法，工具，测试类型），风险

通常是由测试经理/主管/组长来编写，测试人员要参与

3. 测试计划评审****

对测试计划的合理性进行评审，参与人员，测试人员，开发人员，产品经理，项目经理等

4. 测试设计（测试用例编写 ）****

依照测试点编写测试用例（等价类，边界值，因果图，错误推断法。。。）

excel编写，管理工具（禅道，testlink）

5. 用例评审****

测试人员讲解一下用例编写，产品经理，开发人员，测试人员，项目经理

会议评审

邮件评审（发邮件给相关人员，设定期限，反馈意见）

6. 开发提测（冒烟测试）****

快速检查，提测版本是否可用，有没有严重问题（致命，影响后续很多功能使用）

冒烟测试通过，进入到正式测试（执行用例）

冒烟测试不通过，打回（直接告诉开发人员，通过邮件附带冒烟测试报告）

7. 执行测试用例****

excel用例上执行，记录

管理工具（禅道，jira）

8. 提交bug****

通过缺陷管理工具（禅道，jira，bugzilla）

主要要素（标题，严重级别，环境，输入数据，操作步骤，实际结果，预期结果，指定修改人，优先级别，附件【图片，小视频】

9. 等待开发修改bug再次提测，修订测试用例，编写自动化脚本****

10. 验证bug，回归测试，提交bug****

bug验证通过，关闭；验证不通过，重新打开；

回归测试就是把之前测试的功能再测试一遍（主要以正向用例为主）

11. 经过几轮回归测试（通常一个迭代周期3~ 4 轮左右的回归测试）****

12. 编写测试分析报告****

目的，背景，分析 用例编写和执行情况（用例总数，执行数量，通过率），缺陷的统计分析（缺陷的严重级别分布，缺陷的状态分布，缺陷的模块分布，缺陷的类型，缺陷的提交人，缺陷的负责人。。。）

3.1.3 、介绍一下你们常用的测试用例设计方法****

参考：

我们常用的测试用例设计方法是等价类、边界值，因果图和错误推断法等。最常用的还是等价类划分和边界值法，等价类的划分可以让我们更全面的覆盖功能需求，避免遗漏，也能让我们用尽量少的测试用例来达到最好的测试效果，一般会划分有效等价类和无效等价类，有效等价类来自需求的描述，无效等价类还可以根据不同的角度再次划分，比如空，超长，不符合输入类型，特殊字符等，然后在每个等价类中分别提取部分取值去设计测试用例。

边界值的使用主要是因为在等价类的边界部分最容易出现问题，所以要在等价类的基础上重点使用边界值法来设计测试用例。

3.1. 4 、你在测试过程中遇到过的问题****

1. 提测质量差
问题描述：提测版本差，有些均未通过冒烟测试****

如何解决：****

通常需要测试的负责人去和项目经理或研发负责人沟通，要求开发人员在提交测试版本之前要进行必要的自测，提高冒烟测试通过率。****

---

提高冒烟测试的效率，可以采用自动化测试的方法，快速验证提测版本，遇到不合格的及时打回重新提测

2. 功能反复
问题描述：在上一个版本是OK的功能，在新版本中功能失常
解决方式：
对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟通过后，再交由测试
对小功能反复 ，没有有效的处理方式，测试这边可以做的是，加强测试，这个问题，在发布前夕好了很多，但问题仍然存在

3. 需求不明确，前后不一致
问题描述：需求不明确，特别在一些边界，各端统一上
解决方式：
由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。

4. 测试和开发信息不对称
问题描述：测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致
解决方式：
强调消息需要通知到测试，通常有关需求变更的会议都要有测试人员参加

5 . 测试的过程中，突然发现时间不够，应该如何去解决？****

****遇到这种情况在测试过程中很常见的，通常我们采用三种措施，一是通过加班来增加测试时间，二是和项目经理或测试经理沟通，从其他部门借调人员来临时帮助执行测试用例，三是与项目经理沟通，能否通过与客户协调，延长测试时间以保证软件的质量。

3.1. 5 、你们的缺陷等级如何划分的？****

我们的缺陷一般分为四个等级，致命级，严重级，一般级和轻微级。致命级指能够导致软件程序无法使用的缺陷，比如宕机，崩溃，手机APP的闪退，数据库死锁等。严重级别一般是指软件的主要功能存在缺陷或者非主要功能缺失等，影响用户的正常使用。一般级别是指非主要功能存在缺陷，但不影响用户正常使用，或者有替代的方案。轻微错误一般指的是界面或者文字图片的轻微显示错误等。

3.1. 6 、你们的项目团队有多少人？测试人员有几个？如何分工的？****

我们的项目团队大概20多人，其中测试人员4个，我们一般都是按照功能模块来进行分工的（有时候也会按照不能的测试类型来进行划分，比如功能测试，性能测试，自动化测试等。）

3.1. 7 、你们最近一个项目一共写了多少条测试用例？发现了多少个bug？****

我们最近的一个项目大概写了1000多条测试用例，一共4个人编写的，大概编写了两周左右的时间，因为在编写的过程中发现需求模糊的地方还需要和产品经理进行沟通。

一共发现了300多个bug，开始的轮次发现的缺陷会比较多一些，后面回归测试中逐渐减少，其中一般级别的bug数量最多。

3.1. 8 、你一天大概能写多少条测试用例？****

按照我目前的能力，依照系统的复杂度来看，通常一天可以写一百多条，如果是需求有模糊不清的地方或者业务比较复杂，可能写的会少一些，几十条吧。

3.1. 9 、你发现了一个bug，但开发人员不认可，你会怎么处理？****

如果我提交了一个bug，开发人员认为不是，那么我首先要再次确认一下这个bug是否存在，是否影响用户的实际使用，确认后，再去和开发人员进行沟通，讲清楚这个缺陷的复现步骤和对用户的影响，争取能够取得开发人员的认可，如果还是不能达成一致，那么我本着对用户负责的态度，需要将此bug的情况上报给测试经理和项目经理，由他们进行裁决。

3.1. 10 、一个不能复现的bug需要上报么？****

这个问题我们还真的遇到过，一般我们发现的bug都需要反正求证复现的步骤，确认百分百复现之后才会上报，但如果遇到比较严重的问题，虽然不能复现，但还是有一定的出现几率，那么我们也要进行上报，需要提交给开发人员进行定位或者观察，但这种bug我们一般会在缺陷报告中标明出现的频率，比如一个手机app闪退的bug，出现频率大概50%。

3.1.1 1 、你们的测试工作通常是在什么时候开展的？****

我们项目的测试工作一般是在需求阶段就会介入，参与需求的讨论，需求经过评审之后，我们就开始依照需求规格说明书进行测试用例的编写。

需求讨论主要是从测试人员的角度审查需求描述是否清晰，准确，是否可以编写用例进行测试。

3.1.1 2 、你们项目的迭代周期一般多长时间？****

项目初始时候的迭代周期一般长一些，大概一两个月，后面根据迭代的功能和修改的缺陷时间逐渐缩短，一般一两周一个迭代周期，项目上线前期甚至一周就一两个版本。我们这个项目大概迭代了10几个版本。

3.1.1 3 、你们使用什么来管理缺陷（bug）的？****

我们使用禅道来管理缺陷，禅道是一个开源的项目管理工具，可以用它来管理产品的需求，项目的任务，测试用例和跟踪bug，我们主要用它来管理测试用例和缺陷。

我们编写了测试用例，依照开发提交的版本进行测试用例的执行，执行的过程中发现bug会提交缺陷报告，开发修改后，我们会进行跟踪验证。

除了禅道，我还了解Bugzilla，Jira，Mantis等缺陷管理工具。

3.1.1 4 、测试计划和测试报告一般包含哪些内容？****

注：通常测试计划和测试报告是由测试组长/测试主管/测试经理来编写，但测试组或测试部内的主要测试人员也会参与编写，因此所有人都需要知道测试计划和测试报告的主要内容。****

参考：

我们项目的测试计划一般都是测试组长/主管来编写，我也会参与，主要包含测试的目的，测试的范围，测试的策略和方法，测试的软硬件环境，测试的进度安排和测试风险评估等。

测试报告是在整个项目测试完成之后进行编写，主要是统计和分析整个测试过程的活动和产生的数据，会统计测试用例的情况，比如一共编写了多少测试用例，执行了多少测试用例，通过了多少测试用例，每个测试人员编写了多少测试用例等。

还会统计和分析项目缺陷的情况，比如缺陷的状态，是否已经修改还是未修改，缺陷的严重级别，缺陷的高发点，项目当中哪个模块发现的bug比较多，通常缺陷的分布会符合二八定理，也就是百分之二十的模块发现了百分之八十的缺陷。

3.1.1 5 、电商平台的核心业务是什么？购物车如何进行测试？****

电商平台主要是个商品销售平台，所以商品的查找，加入购物车，结算并支付是电商平台的核心业务，也就是整个商品的购买流程。

购物车的测试主要考虑以下几个方面（掌握思路即可）：

界面测试，购物车中的商品信息显示是否正常，加入购物车后的商品价格是否显示正常

功能测试，

从商品详情页面是否可以加入商品到购物车

购物车页面打开的同时，在其他页面添加了商品，购物车刷新后，新的商品能否显示

若未登录，点击加入购物车，是否可以添加进购物车（缓存方式）或者会直接提示登录

在商品未选择的状态下，结算是否按钮为灰色无法点击

勾选商品后，结算按钮为可点击状态，

勾选商品后，自动计算商品的总价，价格是否正确

勾选商品后，点击结算按钮，进入确认清单的页面

在购物车中，可以修改商品的数量

在购物车中，修改商品的数量，最小和最大的数量是多少

在购物车中，可以将已加入的商品移除购物车

在购物车中，可以讲商品移入收藏夹，移入收藏夹后，商品在购物车中不显示

购物车中的商品是否显示优惠或促销信息

批量添加商品到购物车

在购物车中批量移除商品

最多可以加入多少种商品到购物车中

购物车中自营和第三方的商品分类是否正确

购物车中的商品是否可以更改商品的规格和促销种类

性能测试****

打开购物车页面要多久

最多可以添加多少商品到购物车中

批量添加商品和移除商品的速度如何

兼容性测试****

如果是web商城，测试在不同的浏览器上功能是否正常

如果是app，测试在不同手机品牌，不同操作系统版本和不同分辨率下的功能是否正常

3 .1.16 、购物车什么情况下生成一个订单？什么情况下会分拆多个订单？****

通常订单是在提交结算的时候生成，订单状态会有待付款，已付款，已发货。。。。

一般来说同一个商家的商品会生成一个订单，多个商家的商品会拆分成多个订单。

但如果是同一个商家的商品分属不同的发货仓库也会自动拆分成多个订单，订单金额也会依据商品价格自动分拆。

3.1.1 7 、登录功能如何设计测试用例？****

功能测试(Function Test)

1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）

2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）

3、登录成功后能否跳转到正确的页面（低）

4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）

5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）

6、记住账号的功能

7、登录失败后，不能记录密码的功能

8、账号和密码前后有空格的处理

9、密码是否加密显示（星号圆点等）

10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确

12、输入密码的时候，大写键盘开启的时候要有提示信息。

13、什么都不输入，点击提交按钮，看提示信息。（非空检查）

界面测试(UI Test)

1、布局是否合理，2个Testbox 和一个按钮是否对齐

2、Testbox和按钮的长度，高度是否复合要求

3、界面的设计风格是否与UI的设计风格统一

4、界面中的文字简洁易懂，没有错别字。

性能测试(Performance Test)

1、打开登录页面，需要几秒

2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过5秒

安全性测试(Security Test)

1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)

2、账号和密码是否通过加密的方式，发送给Web服务器

3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript验证

4、账号和密码的输入框，应该屏蔽SQL注入攻击

5、账号和密码的的输入框，应该禁止输入脚本（防止XSS攻击）

6、错误登录的次数限制（防止暴力破解）

7、考虑是否支持多用户在同一机器上登录；

8、考虑一用户在多台机器上登录

可用性测试(Usability Test)

1、是否可以全用键盘操作，是否有快捷键

2、输入账号，密码后按回车，是否可以登录

3、输入框是否可以以Tab键切换

兼容性测试（Compatibility Test）

1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）

2、不同的平台是否能正常工作，比如Windows, Mac

3、移动设备上是否正常工作，比如iPhone, Android

4、不同的分辨率

3.1.1 8 、给你一个带广告图案的纸杯，如何进行测试？****

1.杯子特性：  
(1)杯子的容量：能装多少升水，空杯，半杯，满杯  
(2)杯子的型状：圆型，上面口大，下面小。  
(3)杯子的材料：纸杯  
(4)杯子的抗摔能力：风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏 (5)杯子的耐温性：装冷水，冰水，热水 

2.广告图案：  
(1)广告内容与图案碰水是否会掉色  
(2)广告内容与图案是否正当  
(3)广告内容与图案是否轻易剥落  
三影响范围：  
1.可用性：  
(1)装进液体多久后会漏水  
(2)装进热水多久后可以变温，装进冰水多久后可以融化  
2.安全性：  
(1)装进不同液体，是否会有化学反应。比如：可乐，咖啡等饮料  
(2)装进热水杯子是不是会变型和异味

3.性能：  
(1)不同人群是否能适合杯子的型状，包括握杯的感觉和喝水的感觉  
(2)不同人群是否能接受杯子的广告内容与图案  
以上是我从设计用例思想方面考虑到的用例。真正接口测试用例的设计还要通过阅读代码，挖掘更深层次的相关背景来补充测试用例。功能测试职员会从哪几个方面设计呢。请多指教！  
总之，一个好的测试用例具有较高的发现某个尚未发现的错误的可能性，一个成功的测试用例能够发现某个尚未发现的错误。

3.1.1 9 、电梯如何进行测试****

需求测试：  查看电梯使用说明书、安全说明书等

界面测试：  查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。 
4.报警装置是否可用。 
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。 
8.上升途中的响应。 
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来； 

      2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。 

9.是否有手机信号

10.按错楼层号码，再次点击是否可以取消选择

可靠性：  
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。 
3.点击当前楼层号码
4.多次点击同一楼层号码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时报警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：

看电梯在最大负载下平稳运行的最长时间

3.1. 20 、支付如何进行测试****

从金额上： 包括正常金额的支付，最小值的支付，最大值的支付，错误金额的输入（包括超限的金额、格式错误的金额、不允许使用的货币等等）；

从流程上： 包括正常完成支付的流程，支付中断后继续支付的流程，支付中断后结束支付的流程，支付中断结束支付后再次支付的流程，单订单支付的流程，多订单合并支付的流程等等；

从使用的设备上：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；（这个可能是针对线下的支付）

从支付接口上：包括银行卡网银支付、支付宝支付、微信支付、百度钱包、京东支付等；

从产品容错性上：包括支付失败后如何补单或者退单、如何退款等；

从后台的账务处理上：成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。

3.1.21 、你们项目共有几套运行环境****

我们项目一般有4套环境，开发环境，测试环境，用户验收环境（UAT环境）和生产环境（线上环境，正式环境）

有的公司还会在测试环境和生产环境之间加上 灰度环境，这种环境和用户验收环境类似，需要和生产环境相似度比较高，主要用于在上生产环境之前验证整体功能的环境兼容性。

3 .1.22 、如何搭建测试环境？你会独立搭建测试环境么？****

注：被问到测试环境的时候需要注意当时的情境，因为测试环境一般有两种理解：

一种是我们测试人员自己使用的环境，通常是在windows下，安装和配置一些常用的软件，比如java环境，python环境，eclipse，jmeter，Loadrunner等。

还有一种是指服务端的软件运行环境，配置java运行环境，安装tomcat中间件，安装Mysql数据库，将web应用的war包放入webapps目录下，解压，重新启动tomcat服务器，就可以通过url访问我们的web软件了。

一般回答第一种就可以了，就说我们的环境和经常用到的软件都是我们自己安装的，问到第二种的时候就说我们服务端的环境部署有专门的运维人员来做。****

3 .1.23 、请问你们的测试退出或结束的标准是什么？你们系统上线后是如何组织测试的？****

我们公司的测试结束的标准是公司制定的质量标准，通常是：

1、 测试用例对需求功能点的覆盖达到100%

2、 测试用例执行率达到90%以上

3、 发现的致命、严重级别的缺陷修复率为100%（都得到修复）

4、 发现的一般和轻微的缺陷修复率达到90%（遗留的缺陷不能影响用户的正常使用，可以推迟到下一个版本进行修改）

5、 在最近一轮的回归测试中未发现致命和严重级别的缺陷。

系统上线之后就是正式的环境，一般我们会在上面做一些验证的工作，通过一个特定的账号跑一下主要流程，完成之后再把测试数据清掉。一般我们不在线上环境做太多的细致的功能测试工作，对应线上环境，我们会有一套用户验收环境（UAT环境），软硬件环境完全模仿线上环境，如果线上环境出现bug，我们会现在UAT环境和测试环境当中进行复现，如果不能复现再考虑线上环境和UAT环境的差异，进行排查定位。   

3 .1.24 、优惠券测试点有哪些？****

1、就比如在某宝上买东西，达到什么要求才能领取优惠券，不符合要求不能领取，然后一件商品需要到什么样的价格条件才可以使用优惠券

2、这个优惠券的使用周期是多久？达到什么样的要求能使用什么面额的优惠券（如5,10,20，50,99不等），过期了能不能使用都需要测试

3、能不能给别人使用，能不能叠加使用，使用过的优惠券还能不能继续使用，还有未使用和已使用的优惠券状态能不能区分，通常已使用的优惠券是置灰状态，这些都需要测试

4、还有就是现在网站正在做什么活动，然后购买某样商品可以打五折，优惠券能不能和其他活动一起使用

5、还有一个重点，就是购买了一件商品，使用了优惠券，然后退货，而这样商品的价格和使用了优惠券的价格不一致，那么退货后退款是按照优惠后的价格来推，那么这个优惠券能不能再次使用，这里就和需求规定有关

6、这个优惠券的后台功能，比如如何创建优惠券，设置优惠券的使用条件，使用的有效期，如何展示，和退款退货流程相关联等

3 .1.25 、在测试的工作中你有哪些印象深刻的bug么？****

通常会让你觉得或者面试官也同样觉得印象深刻的问题有几下几种情况：****

1.  bug比较严重，产生了比较严重的后果或者造成了比较大的影响，比如系统崩溃，app闪退这种。

2. bug比较难找，就是找到这个bug需要比较复杂，比较多的操作步骤，所以印象比较深刻

3. 大家都觉得最不应该出现bug的比方出现了bug，比如比较简单的功能或者之前已经测试过没有发现bug的功能。

案例参考：****

1. 我记得好像有这样一个bug，一般列表翻页功能都比较简单，很少出现问题，但我们当时就发现了这样一个问题，每次从首页点击下一页后，显示的依然还是第一页的内容，后来发现每次翻到下一页，页面都会快速刷新两次，经过和开发一起定位发现，出现bug的原因是在点击下一页的时候又触发了页面的查询功能，默认又显示首页了。对这个bug印象比较深刻主要是因为翻页功能出现的bug比较少

2. 我记得有这样一个bug印象比较深刻，就是做数据导出到excel的时候，其中的身份证号显示为科学记数法了，4.30E+19，后来发现主要原因是开发在导出到excel时没有对这个字段进行处理，excel中如果超过11为数字就会默认以科学记数法显示，如果显示正确，应该以文本的格式保存。

3 .1.26 、如何查看系统日志****

1. web端的日志通常保存在数据库中，可以通过连接测试数据库通过sql语句来进行log日志的查询，有的系统也会保存在服务器端，需要连接liunx系统进行查询

2. 手机端的如果是安卓系统可以通过adb命令来进行日志查看 adb logcat，也可以把日志抓取到本地来进行查看 adb logcat >c:\logcat.txt

3. 如果是苹果手机iOS端的，需要通过开发环境x-code进行查询，所以如果查询苹果手机的日志需要请开发人员协助

3 .1.27 、怎么判断一个bug是前端问题还是后端问题****

我们一般是通过抓包工具fiddler来抓取数据包来定位问题到底是前端还是后端的，

1. 如果请求没有发出去或者传入的参数有问题，就是前端的问题；

2. 如果前端传入参数和请求都没问题，后端返回的响应数据有问题，那就是后端的问题；

3. 如果前端传入参数和请求是正确的，后端返回的响应数据也是正确的，那么可能就是前端处理返回数据的问题。

3 .1.28 、在正式环境中发现了一个bug，应该如何处理********

1. 一般我们接到正式环境的bug，会先在我们的测试环境中进行确认，如果在测试环境中存在同样的bug，那么可能就是我们漏测，需要提交缺陷给开发人员进行修复，然后依照bug的级别和影响由领导来判断是否需要紧急发版。

1. 如果在我们的测试环境没有发现同样的bug，那么我们就需要和bug的发现者沟通，看看是在什么环境和场景下发生的bug，是否所有的线上环境都存在问题，那么可能就是兼容性的问题，我们也需要汇报给领导来确定是否需要紧急发版解决还是在后续的版本中再解决。

1. 找到和线上发现问题相同的手机，连接测试环境和正式环境都没有发现同样的问题，那可能就是用户手机的个例（就是只有那个用户的手机存在问题），可以让技术支持人员指导用户进行app的重新安装或者重新手机来解决

3 .1.29 、缺陷报告的主要要素有什么（你们怎么报告你们的bug）****

我们在报bug 或者说提交缺陷报告的时候主要包含bug的标题，要简单的描述一下bug的现象，bug的严重级别，bug的发现环境（web端和手机端），发现bug的操作步骤，预期结果和实际结果，如果有截图需要上传附件截图，如果是复现步骤比较复杂，我们还可以录制一个小的视频上传上去。

3 .1.30 、冒烟测试是什么，冒烟测试怎么做？****

1.冒烟测试是什么？

　　针对每个版本或每次需求变更后，开发提交测试，在正式测试前，对产品或系统的一次简单的验证性测试，如果冒烟测试不通过，就打回重新提测。

2.冒烟测试的目的

　　为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在严重bug。

3.冒烟测试怎么做？

可以找1-2个人用比较短的时间（通常不超过一两个小时，视系统复杂程度而定）快速的验证一下系统的主要功能流程是否能跑通，最好的方法，设计出自动化测试脚本，每一次版本更新后都可以去执行脚本验证一下。

4.冒烟测试不通过如何通知开发人员****

通常有两种方式，一种是直接口头通知开发人员冒烟测试不通过，让开发人员重新打包提测新的版本，另一种是通过邮件的方式，将冒烟测试中发现的问题以报告的形式发给相关开发人员并抄送给领导知晓。

3 .1.31 、如何测试/说一下测试点系列问题****

这类的面试题通常都是问你一个熟悉的软件的功能或者实体的物体，问你如何进行测试，或者说一下测试点，考察你的发散性思维和逻辑表达能力****

这类问题的回答要记得一定要对被测对象有了解，然后依照功能，性能，兼容性，易用性，界面，安全性等方面进行测试点的述说，尽可能的多说（发散性思维），有条理的说（逻辑表达能力），上面有关登录，购物车，优惠券，支付，订单，电梯，纸杯等这里就不再重复，与下面要列的案例均属同一类型。****

1 . 微信发朋友圈如何测试****

功能测试****

1、朋友圈发送功能****

1）只发送文本****

a、考虑文本长度：1-1500字符（该数据为百度数据）、超出最大字符长度****

b、考虑文本类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；因为过长纯类型需要换行很容易出现超出边框问题，所以这里先考虑过长纯类型情况****

c、文本是否支持复制粘贴****

d、为空验证****

2）只发送图片****

a、本地相册选择/拍摄****

b、图片数量验证：1-9张图片、超出9张****

c、图片格式验证：常见图片格式jpg、png（以实际微信需求支持的格式为准）、动态gif图片、不支持的图片格式****

d、图片尺寸验证：最大700800像素(此为百度数据)、超出最大尺寸范围是否压缩***

e、图片大小验证：1-300kb（此为百度数据）、超出300kb****

f、图片的预览验证：点击支持预览大图、多张图片支持左右滑动预览****

g、图片的增删改操作****

h、为空验证****

3）只发送视频****

a、本地相册选择/拍摄****

b、视频秒数验证：1-10s，超出10s****

c、视频个数验证：1个，超出1个****

d、视频格式验证：支持的视频格式，例mp4、不支持的视频格式****

e、视频大小验证：苹果400kb以内、Android200-300kb（此为百度数据）、超出规定大小****

f、视频预览增删改操作****

g、为空验证****

4）发送文本+图片：输入满足要求的文本、图片进行一次验证****

5）发送文本+视频：输入满足要求的文本、视频进行一次验证****

6）发送图片+视频：不支持发送****

7）朋友圈发送内容是否有限制，例如涉及黄赌毒等敏感字****

8）所在位置****

a、不显示位置：发送到朋友圈动态不显示位置****

b、选择对应位置：搜索支持、自动定位、手动编辑****

C、点击取消，返回上一级页面****

9）谁可以看****

a、设置公开：所有朋友可见****

b、设置私密（仅自己可见）：自己查看朋友圈-可见、好友查看朋友圈-不可见****

c、设置部分可见（部分朋友可见）：选择的部分好友-可见、不被选择的好友-不可见、是否有人数上限****

d、设置不给谁看（选中的朋友不可见）：不被选中的朋友-可见、被选中的朋友-不可见、是否有人数上限****

e、点击取消，返回发送页面****

10）提醒谁看****

a、提醒单人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒****

b、是否有人数上限****

c、点击取消，返回发送页面****

11）同步QQ空间：默认不同步、同步到QQ空间****

12）取消发送朋友圈操作****

a、选择相机，点击取消，返回朋友圈页面****

b、进入朋友圈发送页面，选择文本图片，点击取消****

13）朋友圈当天发送次数是否有上限限制****

2、朋友圈浏览功能****

1）文本查看：****

a、过长文本内容是否隐藏，并支持查看全文****

b、右键选择复制、收藏、翻译****

c、url链接是否支持点击跳转网页****

2）图片查看****

a、小图右键支持收藏/编辑****

b、点击支持大图浏览****

c、选择发送给朋友、收藏、保存图片、编辑****

d、多张图片支持左右滑动浏览****

3）视频查看****

a、右键视频支持静音播放/搜藏****

b、点击视频播放按键支持播放视频****

c、选择发送给朋友、收藏、保存视频、编辑****

4）分享动态浏览：QQ空间/公众号文章/非腾讯产品分享后朋友圈是否正常显示****

5）赞：点赞、取消点赞****

6）评论****

a、评论长度：评论字数合理长度、评论超过字数上限****

b、评论类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；****

c、评论是否支持复制粘贴****

d、为空验证****

e、发表评论后删除****

f、评论回复操作****

7）删除朋友圈动态****

8）更换相册封面****

9）刷新是否正常获取新动态****

10）上滑是否加载更多****

界面 /易用性测试****

1、技术人员角度：页面布局设计是否跟产品原型图/ui效果图一致****

2、但除了考虑1之外，我们同样要考虑到用户使用：功能操作是否简便，页面布局排版风格是否美观合理，提示语相关信息是否易于理解****

中断测试****

1、主要考虑：a)核心功能  b)当前功能存在实时数据交换，例发朋友圈、浏览朋友圈进行中断，是否容易出现崩溃****

2、中断包括：前后台切换、锁屏解锁、断网重连、app切换、来电话/来短信中断、插拔耳机线/数据线****

网络测试****

1、三大运营商不同网络制式测试****

2、网络切换测试：WIFI/4G/3G/2G****

3、无网测试：对于缓存在本地的数据，部分朋友圈信息是否支持浏览****

4、弱网测试：****

a、延时：页面响应时间是否可接受、不同网络制式是否区分超时时长、出现请求超时，是否给予相应的提示****

b、丢包：有无超时重连机制、如果未响应，是否给予相应提示****

c、页面呈现的完整性验证****

兼容性测试****

1、Android手机端、苹果手机端、pad版（主流）功能界面显示是否正常****

2、各平台朋友圈展示数据是否一致****

安全测试****

发送朋友圈时，文本输入脚本代码，是否出现异常****

性能测试****

1、服务器性能测试****

可通过loadrunner/jmeter工具实现，主要关注TPS、响应时间、吞吐量、CPU、内存等****

2、app客户端性能测试****

可通过GT工具实现，运行时关注cpu、内存、流量、电量等占用率****

3、app压力稳定性测试****

通过monkey工具实现，频繁发送朋友圈，浏览朋友圈请求，是否容易发生崩溃****

2.微信朋友圈评论功能如何测

点击评论，评论框能够弹出或者打开****

输入正常的评论信息，点击提交看是否评论成功****

不填写任何内容点击提交看能否提交评论****

输入空格，点击提交看能否提交****

输入超过字数限制的评论，点击提交看是否成功****

输入表情等特殊符合，点击提交，看能够提交成功并正常显示****

输入评论内容，快速多次点击提交按钮，看是否会提交成功多个重复的信息****

针对评论是否能再进行评论****

针对评论的评论提交成功后，显示的位置是否正确****

能否多次发送重复的评论内容****

如果发的评论内容有敏感词汇是否能发送成功****

........****

3.朋友圈点赞功能如何测

****

4.视频直播软件测试

先说下直播的原理，就是把主播录制的视频，推送到服务器，在由服务器分发给观众观看。****

直播环节：推流端即主播客户端：采集、美颜处理、编码、推流****

服务端处理：转码、录制、截图、鉴黄****

播放器即观众客户端：拉流、解码、渲染****