软件测试面试必问I真题+答案I功能测试篇

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

介绍测试测试流程，记得不能只罗列各个环节，要在一些重要或者你比较熟悉的环节进行适当的展开

也可以结合项目进行介绍

总体流程：

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

• 测试需求分析

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

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

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

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

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

• 测试计划评审

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

1. 测试用例包含哪些组成部分

测试用例的核心如下：

用例名称

前置条件：比如完成这个用例的前提是登录某账号，或者先新建一个表格等

测试步骤

参数：比如同一条用例，可以测试不同的数据，比如中英文，数字，特殊字符等

预期结果

优先级：紧急、一般紧急、不紧急

是否自动化：是、否（因为自动化后，后续回归阶段就不需要手动执行了，节省时间）

测试结果：通过、未通过、跳过

• 用例评审

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

会议评审

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

• 开发提测（冒烟测试）

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

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

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

• 执行测试用例

excel用例上执行，记录

管理工具（禅道，jira）

• 提交bug

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

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

1. 等待开发修改bug再次提测，修订测试用例，编写自动化脚本
2. 验证bug，回归测试，提交bug

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

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

1. 经过几轮回归测试（通常一个迭代周期3~4轮左右的回归测试）
2. 编写测试分析报告

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

二.介绍一下你们常用的测试用例设计方法 

参考：

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

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

三.你在测试过程中遇到过的问题 

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

如何解决：

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

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

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

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

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

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

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

四.你们的缺陷等级如何划分的？ 

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

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

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

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

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

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

七.你一天大概能写多少条测试用例？ 

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

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

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

九.一个不能复现的bug需要上报么？ 

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

十.你们的测试工作通常是在什么时候开展的？ 

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

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

十一.你们项目的迭代周期一般多长时间？ 

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

最后感谢每一个认真阅读我文章的朋友，整理了一大波资料和学习包，大家如果需要的话可以直接抱走~