功能测试面试问题

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

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

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

2、你们的缺陷等级如何划分的？

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

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

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

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

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

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

5、你一天大概能写多少条测试用例？

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

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

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

7、一个不能复现的bug需要上报么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13、如何搭建测试环境？你会独立搭建测试环境么？

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

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

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

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

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

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

1. 测试用例对需求功能点的覆盖达到100%
2. 测试用例执行率达到90%以上
3. 发现的致命、严重级别的缺陷修复率为100%（都得到修复）
4. 发现的一般和轻微的缺陷修复率达到90%（遗留的缺陷不能影响用户的正常使用，可以推迟到下一个版本进行修改）
5. 在最近一轮的回归测试中未发现致命和严重级别的缺陷。

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